2023. 4. 20. 01:48ㆍBACKEND/AWS
VPC 학습을 위해 데모 VPC, 서브넷, 라우팅 테이블 인터넷 게이트웨이 등을 구성하는 것이 본 포스팅의 목표입니다.
안녕하세요. 지난 AWS VPC, 제대로 이해하기와 AWS VPC, 제대로 이해하기 1: Hands-O에 이어
VPC Demo 환경을 제작하고자 합니다.
제작할 구조는 아래와 같습니다.
NAT Gateway를 사용해서 VPC-A의 Private Instance가 밖으로 향하는 Internet 연결을 할 수 있게 설정하고,
새로운 VPC인 VPC-B를 생성하여 VPC Peering을 통해 서로 연결됨을 증명합니다.
NAT Gateway
: Network Address Translation, 네트워크 주소 변환 서비스
프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만,
외부 서비스에서는 연결할 수 없도록 NAT 게이트웨이를 사용할 수 있습니다.
즉, NAT 게이트웨이를 통해서 프라이빗 인스턴스에서 인터넷으로 요청은 가능하되,
인터넷에서 프라이빗 인스턴스로의 요청은 불가하도록 만들 수 있습니다.
NAT Gateway는 인스턴스의 소스 IP 주소를 각 타입에 따라 NAT Gateway의 IP 주소로 변경합니다.
- Public NAT Gateway: NAT 게이트웨이의 탄력적 IP 주소
- Private NAT Gateway: NAT 게이트웨이의 프라이빗 IPv4 주소
또, 인스턴스에 응답 트래픽을 전송할 때 NAT 디바이스는 주소를 원래 소스 IP 주소로 다시 변환합니다.
NAT 게이트웨이를 만들 때 다음 연결 유형 중 하나를 지정합니다.
Public Type
: (Default) 트래픽을 NAT Gateway에서 VPC용 Internet Gateway로 라우팅
Public Subnet에서 Public NAT 게이트웨이를 생성하고, 생성 시 탄력적 IP 주소를 NAT 게이트웨이와 연결해야 합니다.
혹은, Public NAT Gateway를 사용하여 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있는데, 이 경우에는 NAT Gateway에서 Transit Gateway 또는 Virtual Private Gateway(가상 프라이빗 게이트웨이)를 통해 트래픽을 라우팅합니다.
Private Type
: Private Subnet의 인스턴스는 Private NAT Gateway를 통해 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있습니다.
트래픽을 NAT Gateway에서 Transit Gateway 또는 Virtual Private Gateway(가상 프라이빗 게이트웨이)를 통해 트래픽을 라우팅할 수 있습니다. 해당 타입에서는 탄력적 IP 주소를 프라이빗 NAT 게이트웨이에 연결할 수 없습니다.
Private NAT Gateway를 사용하여 VPC에 인터넷 게이트웨이를 연결할 수 있지만,
Private NAT Gateway에서 Internet Gateway로 트래픽을 라우팅하는 경우 Internet Gateway가 트래픽을 삭제합니다.
Hand-On
지난 포스팅 AWS VPC, 제대로 이해하기 1: Hands-On 에서 구축한 데모를 확장해서 NAT Gateway를 설정하여 외부 인터넷으로 접근할 수 있게끔 설정해보겠습니다.
Check Inaccessible Internet
NAT Gateway를 설정하기 전, Private Instance에 인터넷 액세스가 없다는 것을 먼저 확인하겠습니다.
지난 데모에서 생성한 Private Subnet에는 인터넷 액세스가 없습니다.
때문에 Public Subnet에 위치한 EC2 인스턴스에서 SSH 접근을 한 후 ping 명령어를 입력해도 응답이 없습니다.
만약, ping 연결이 되었다면 아래와 같은 요청에 응답 정보를 확인할 수 있었을텐데,
위에서는 그 어떤 응답 정보를 띄우질 않고 있습니다.
# ping request 성공 시
[ec2-user@ip-10-0-1-21 ~]$ ping google.com
PING google.com (142.251.42.206) 56(84) bytes of data.
64 bytes from nrt12s47-in-f14.1e100.net (142.251.42.206): icmp_seq=1 ttl=45 time=28.6 ms
64 bytes from nrt12s47-in-f14.1e100.net (142.251.42.206): icmp_seq=2 ttl=45 time=27.8 ms
64 bytes from nrt12s47-in-f14.1e100.net (142.251.42.206): icmp_seq=3 ttl=45 time=27.7 ms
64 bytes from nrt12s47-in-f14.1e100.net (142.251.42.206): icmp_seq=4 ttl=45 time=27.7 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
Private EC2에서 인터넷 연결을 위해 NAT Gateway를 설정해보도록 하겠습니다.
2. Create NAT Gateway Instance
먼저, NAT Gateway를 생성합니다.
NAT Gateway는 Public Subnet에 위치해야 합니다.
아래와 같은 설정을 진행했습니다.
Name : demo-NAT-gw
Subnet : PublicSubnetA
Connectivity Types : Public
Elastic IP : Allocate Elastic IP를 클릭하여 Elastic IP를 새로 생성 후 설정
간단한 과정을 통해 NAT Gateway를 연결했는데요.
여기서 짚고 가야할 부분은 NAT Gateway는 이미 인터넷과 연결되어 있다는 점입니다.
Internet Gateway를 Public Subnet에 연결해둔 상태이기 때문입니다.
3. Setting Private Subnet Route
Private Subnet 내에 있는 EC2 인스턴스가 해당 NAT Gateway에 접근해야 합니다.
이를 위해 Private Subnet의 Route Table을 수정합니다.
Destination이 0.0.0.0/0이면 Target을 NAT gateway로 향하게끔 설정합니다.
이렇게 PrivateSubnet의 네트워크가 NAT Gateway를 통해 인터넷 연결이 되게끔 설정했습니다.
그럼 마지막으로, 접근이 잘되는지 확인해보도록 하겠습니다.
4. Access Internet from Private Subnet
PrivateSubnet 내의 EC2에 직접 접속할 수 없기 때문에,
PublicSubnet 하위의 Bastion Host를 통해 접근 후 확인합니다.
NAT Gateway를 설정하기 전과는 다르게, 위와 같이 ping 연결을 성공적으로 수행하는 것을 확인할 수 있습니다.
VPC Peering
VPC Peering은 AWS 네트워크를 통해 VPC 간의 연결을 프라이빗하게 연결합니다.
AWS 네트워크를 통해 연결하고 싶을 때 사용하며, 다양한 리전과 계정에서 VPC를 생성할 수 있습니다.
VPC Peering를 사용하는 목적은 VPC가 모두 같은 네트워크에서 작동하도록 만들기 위함입니다.
VPC 네트워크 CIDR가 겹치지 않도록 반드시 주의해야 합니다.
두 VPC 연결 시 CIDR가 겹치면 통신 불가하기 때문입니다.
VPC Peering은 다른 계정 간(Cross Account) 혹은, 리전 간 (Cross Region)에도 가능합니다.
보안그룹 설정 시, 동일 리전의 계정 간 Peered VPC에서 보안 그룹을 참조할 수도 있습니다.
CIDR이나 IP를 소스로 가질 필요가 없이 보안 그룹을 참조할 수도 있기 때문에 편리하게 관리할 수 있습니다.
NOT transitive, 전이 불가
VPC 피어링은 두 VPC 간에 발생하며 전이되지 않습니다.
VPC A, B, C가 있을 때 통신 가능 여부
A -⭕️-> B: A와 B는 Peering 연결 생성 → 통신 가능
B -⭕️-> C: B와 C는 Peering 연결 생성 → 통신 가능
A -❌-> C: A와 C는 Peering 연결 없음 → 통신 불가
- A와 C의 VPC 피어링 연결을 활성화해야 둘이 통신 가능
- A와 B가 연결, B와 C가 연결되었다고 해서 A와 C가 연결되는 것은 아님
지금부터 VPC Peerin 연결을 생성해보도록 하겠습니다.
지금까지 생성한 VPC 데모에 VPC-B와 그 내부에 서브넷 B를 생성하고, PeeredInstance를 생성하여 연결합니다.
아래 단계를 통해 위의 구성을 생성하겠습니다.
1. VPC-B 구성
- 1-1. VPC-B 생성
2. VPC Peering 생성
3. VPC Route Table
4. Access EC2 Instance in VPC-B
참고로, 3 번째는 각 VPC의 Route Table을 수정합니다.
이처럼 VPC Peering을 위해서는 VPC Peering를 활성뿐만 아니라,
VPC 서브넷 상의 Route Table도 업데이트해서 EC2 인스턴스가 서로 통신할 수 있게 해야 합니다.
1. VPC-B 구성
먼저, VPC-A 와 Peering Connection할 VPC-B 환경을 구성합니다.
VPC를 생성하고, Subnet과 EC2 Instance를 제작합니다.
New VPC
Name: VPC-B
CIDR: 10.1.0.0/16
VPC-B의 Subnet
Name: PrivateSubnetB
CIDR: 10.1.0.0/24
1-1. VPC-B 생성
먼저, 아래와 같은 조건의 새로운 VPC를 생성합니다.
Name: VPC-B
CIDR: 10.1.0.0/16
1-2. VPC-B Subnet 생성
다음으로, VPC-B에 위치할 VPC Subnet을 아래의 조건으로 생성합니다.
Name: PrivateSubnetB
CIDR : 10.1.0.0/24
Subnet 생성 시 CIDR를 설정했는데요.
VPC-A와 Peering 할 예정이기 때문에 절대 IP 대역이 겹쳐서는 안되게끔 설정해야 합니다.
1-3. VPC-B EC2 Instance 생성
이제, 해당 Subnet에 위치할 EC2 Instance를 생성합니다.
보시다시피, VPC-B와 PrivateSubnetB 서브넷을 지정하여 생성한 것을 확인할 수 있습니다.
다음으로 넘어가기 전에, 먼저 두 서버 사이에 연결이 불가한 것을 확인해보겠습니다.
VPC가 독립된 두 네트워크라는 점을 다시 한 번 확인할 수 있었습니다.
2. VPC Peering 생성
이제 VPC Peering 연결을 생성해보겠습니다.
이름은 DemoPeeringConnection으로 하며, Requester를 VPC-A, Accepter를 VPC-B로 지정합니다.
설정 시, 두 VPC 간의 CIDR 영역이 겹치지 않기 때문에 성공적으로 Peering Connection을 생성할 수 있었습니다.
같은 계정으로 요청했기 때문에 해당 계정에서 바로 Accept Request를 클릭합니다.
이렇게 해도 Route Table을 설정하지 않으면 연결이 되지 않는데요.
VPC Subnet 각각의 Route Table를 같이 수정해야 합니다.
3. VPC Route Table
Peering 연결의 마지막 단계인 Route Table 설정입니다.
Peering Connection을 생성한 후 Route table이 서로를 허용하게 설정되어 있어야 합니다.
그렇지 않으면, 두 VPC 간에 연결을 할 수 없습니다.
3-1. VPC-A Route Table 설정
먼저, VPC-A의 Route Table을 설정합니다.
VPC-B의 CIDR에 해당하는 10.1.0.0/16의 요청을 2.에서 생성한 DemoPeeringConnection과 연결합니다.
3-2. VPC-B Route Table 설정
먼저 보기 쉽게 VPC-B의 Default Route Table 이름을 수정해줍니다.
VPCBRouteTable로 변경하겠습니다.
따로 Subnet Route Table을 생성하지 않고 기본 Route Table을 사용했습니다.
그 후, VPCBRouteTable의 Rules를 수정합니다.
VPC-A의 CIDR에 해당하는 10.0.0.0/16의 요청을 2.에서 생성한 DemoPeeringConnection과 연결합니다.
4. Access EC2 Instance in VPC-B
이제 VPC-A의 Bastion Host에서 VPC-B의 EC2 Instance로 연결을 시도해보겠습니다.
1-3에서 연결에 실패했던 것과는 다르게, Peering 설정 후에는 성공적으로 접속한 것을 확인할 수 있습니다.
연결에 성공했다는 것은 Peering Connection으로 두 VPC가 연결된 상태임을 확인할 수 있습니다.
'BACKEND > AWS' 카테고리의 다른 글
| AWS로 구성하는 Cloud-native Microservice Architectures (2) | 2023.05.06 |
|---|---|
| AWS Lambda, 어렵지 않게 이해하기: Thumbnail Demo (0) | 2023.04.21 |
| AWS VPC, 제대로 이해하기 1: Hands-On (0) | 2023.04.18 |
| AWS VPC, 제대로 이해하기 1 (0) | 2023.04.17 |
| AWS S3, 제대로 이해하기 - Replication & Event Notification (0) | 2023.03.26 |
Backend Software Engineer
𝐒𝐮𝐧 · 𝙂𝙮𝙚𝙤𝙣𝙜𝙨𝙪𝙣 𝙋𝙖𝙧𝙠