🔥 Internet Gateway: 외부로 나가는 유일한 길

AWS 공식 문서는 Internet Gateway를 "horizontally scaled, redundant, and highly available"라고 적는다. 한국어로는 "수평 확장 구조를 쓰고, 중복 구성을 갖추고, 높은 가용성을 제공한다"는 뜻이다. 처음 읽으면 마케팅 문장으로 받아들이기 쉬웠다. 이게 정확히 어떤 뜻인지 안 건 한참 뒤, 어떤 동료가 "IGW를 어느 AZ에 두느냐"고 물었을 때다. 그 질문이 잘못된 질문이라는 걸 설명하다가, IGW가 그동안 내가 막연히 상상해 온 '박스'가 아니라는 사실을 다시 짚었다.

지난 편에서 라우팅 테이블 한 카드의 안쪽을 봤다. 0.0.0.0/0 행에서는 target 칸에 igw-...가 가장 자주 들어간다. 이제 그 igw가 정확히 무엇이고, 무엇을 맡고, 무엇은 맡지 않는지 바로 짚는다.

IGW는 박스가 아니다: 그냥 그어지는 객체다

처음 IGW를 배울 때 내 머릿속에 먼저 떠오른 건 NAT Gateway나 ALB 같은 자원이었다. AZ를 정해서 띄우고, 트래픽이 늘어나면 사이즈를 키우고, 가끔 fail-over도 신경 써야 하는 자원. 그래서 멀티-AZ 구성에서 IGW도 두 개 띄워야 하나, 같은 질문을 했다.

답은 아니다. IGW는 VPC마다 하나만 연결하는 논리 자원이다. 운영자는 AZ를 고르지 않고 인스턴스 타입도 고르지 않으며 사이즈도 조정하지 않는다. AWS가 수평 확장과 이중화를 맡으니 사용자는 가용성과 대역폭을 따로 챙기지 않는다. 공식 문서의 그 표현이 정확히 그 의미다(verified 2026-04-25, VPC Internet Gateway 사용자 가이드).

콘솔에서 Create internet gateway를 누르면 igw-xxxxxxxxxxxxxxxxx ID 하나를 만들고, 다음 화면에서 VPC 하나와 연결하면 절차가 끝난다. attach라는 말은 IGW를 그 VPC 경계와 잇는 동작을 가리킨다. 박스를 특정 AZ에 두는 그림보다 VPC와 인터넷 사이 경계에 선 하나를 잇는 그림이 실제 구조에 가깝다.

이 구조를 기준으로 보면 IGW에서 바로 확인할 핵심은 둘이다. 운영자는 IGW에서 AZ 배치를 고르지 않고, AWS는 IGW 자체 사용료도 받지 않는다. IGW 자체를 만들고 attach하는 일에는 시간당 과금이 붙지 않는다. 다음 단락이 이어 받겠지만, IGW를 통과하는 트래픽과 그 트래픽이 들고 다니는 공인 IPv4 주소에는 별도 가격이 따로 붙는다.

IGW가 하는 일은 한 가지다: 1:1 NAT

IGW가 맡는 일은 단순하다. VPC 안 인스턴스가 인터넷으로 패킷을 내보낼 때 AWS는 source 주소에 적힌 private IPv4를 바깥에서 식별할 수 있는 public IPv4로 바꾸고, 응답이 돌아오면 그 public 주소를 다시 private 주소로 되돌린 뒤 패킷을 인스턴스로 보낸다. AWS 문서는 이 동작을 "논리적으로 1:1 NAT를 제공한다"라고 적는다(verified 2026-04-25).

키워드는 one-to-one이다. private 주소 하나에는 public 주소 하나가 짝을 이룬다. NAT Gateway나 가정용 공유기가 여러 private 주소를 공인 주소 하나로 모으는 방식과는 구조가 다르다. 그래서 인스턴스 한 대마다 공인 IPv4 한 개가 따라붙고, 바깥에서는 각 인스턴스를 주소 기준으로 따로 구분한다. 반대로, 공인 IPv4를 받지 못한 인스턴스는 IGW 앞까지 아무리 라우트가 깔려 있어도 source 주소를 갈아 끼울 짝이 없어 패킷이 그냥 멈춘다.

그래서 Subnet: Public과 Private의 진짜 차이에서 "라우트만으로는 부족하다"고 적은 대목과 여기 설명이 한 쌍을 이룬다. 라우팅 테이블에 0.0.0.0/0 → igw-…를 적어 둔 Subnet이라도, 그 위의 인스턴스가 공인 IPv4 또는 EIP를 받지 못했다면 IGW 쪽에서는 갈아 끼울 짝이 없다. 라우팅과 주소 부여는 별도 토글이라는 사실을 IGW 동작에서 한 번 더 확인하는 셈이다.

한 가지를 더 보자. IGW의 NAT는 stateless에 가깝다. IGW는 매핑 규칙에 따라 source와 destination 주소만 바꾸고, connection 단위 상태는 따로 들지 않는다. 그래서 inbound 허용 여부는 IGW가 아니라 NACL과 SG가 맡는다. IGW는 주소만 갈아 끼우고, 막거나 풀어 주는 결정에는 손을 대지 않는다.

공인 IPv4와 EIP: 두 줄짜리 청구서

이제 비용을 바로 보자. IGW 자체는 무료지만 인스턴스에 붙이는 공인 IPv4 주소에는 2024년 2월 1일부터 시간당 과금이 붙는다. $0.005/시간, 즉 한 달이면 약 $3.65, 한 해면 약 $43.8이다(verified 2026-04-25, AWS 블로그: Public IPv4 Address Charge). 청구서에서는 이 비용을 IGW가 아니라 IPv4 주소 항목으로 따로 청구한다.

이 과금은 부착 여부와 무관하다. 청구서 항목 이름은 둘로 나뉜다. PublicIPv4:InUseAddress는 ENI에 붙어 있는 공인 IPv4(첫 번째든 두 번째든) 한 개당 시간당 $0.005, PublicIPv4:IdleAddress는 어디에도 붙지 않은 채 풀에서 idle하게 들고 있는 EIP 한 개당 시간당 $0.005다. 둘 다 같은 요율이다. 인스턴스를 잠깐 stop해서 EIP가 detach 상태로 풀에 남아 있어도 시간당 시계는 같이 돈다는 뜻이다.

수치만 보면 작아도 합산하면 운영비가 빠르게 커진다. 실험용 인스턴스 100대에 공인 IPv4가 자동으로 붙어 있으면 한 달에 약 $365를 IPv4 주소 비용으로 더 낸다. 운영자는 2024년 2월 1일 이후 청구서에서 전날까지 없던 비용 항목을 바로 확인한다.

첫 글에서 다룬 '관리형이라는 말이 숨기는 비용' 얘기를 여기서 다시 확인한다. IGW는 박스도 없고 사이즈도 없고 AZ 선택도 없어서 손이 거의 안 가는 서비스처럼 느끼기 쉽다. 하지만 그 뒤에서 인터넷에 닿는 자원마다 공인 주소 비용이 시간당 추가로 붙는다. 콘솔은 이 비용 대목을 앞에 내세우지 않는다.

대응 패턴은 두 갈래다. 공인 IPv4가 꼭 필요한 인스턴스에만 주소를 주고, 나머지는 NAT Gateway나 VPC Endpoints로 묶어서 인터넷 노출을 낮춘다. NAT Gateway가 무료가 아니라는 함정은 뒤따르는 글에서 짚는다.

IPv6 전용 출구: egress-only IGW

IGW는 IPv4와 IPv6를 둘 다 다루지만, IPv6에는 다른 옵션이 하나 더 있다. egress-only Internet Gateway다. 이름이 답을 거의 다 한다. 안에서 밖으로는 통과시키되, 밖에서 안으로 처음 들어오는 흐름은 막는다.

효과만 보면 IPv6의 NAT Gateway에 가깝지만 동작 방식은 다르다. egress-only IGW는 stateful connection tracking을 하면서도 주소 변환은 하지 않는다. IPv6 주소가 어차피 전 세계적으로 유일하니 갈아 끼울 필요가 없기 때문이다. 그저 outbound로 나간 흐름만 응답을 받게 두고, inbound로 처음 들어오려는 시도는 차단한다(verified 2026-04-25, AWS Egress-Only Internet Gateway 가이드).

또 한 가지 차이. egress-only IGW는 게이트웨이 자체에 시간당 과금이 없다. NAT Gateway는 시간당 + GB당 이중 과금이지만, egress-only IGW는 IPv6 outbound용으로 만들어 두기만 하면 게이트웨이 비용이 0이다. IPv4용 NAT GW 개념을 IPv6에 그대로 적용하면 잘못된 그림이 되니, IPv6 dual-stack 워크로드에서 outbound-only 패턴은 이쪽이 자연스러운 선택지다.

언제 IGW를 만들지 말아야 하는가

두 번째로 볼 포인트는 '언제 이 서비스를 빼야 하는가'다. IGW에 적용하면 기준을 셋으로 압축할 수 있다.

첫째는 외부 인터넷으로 나갈 일이 사실상 사라진 워크로드다. 같은 계정의 다른 VPC, 같은 리전의 다른 자원, AWS 관리형 서비스 정도가 통신 상대의 전부라면 IGW를 만들 이유가 자체로 없다. AWS API 호출은 VPC Endpoints로 처리하고, 다른 VPC와는 VPC Peering이나 Transit Gateway로 잇는다. 이렇게 구성하면 인터넷에서 직접 닿는 경로를 운영자가 없앨 수 있다. 만들지 않은 게이트웨이는 잘못 설정될 일도 없다.

둘째, 트래픽이 바깥보다 온프레미스로 더 많이 간다면 IGW가 아닌 Site-to-Site VPN이나 Direct Connect 쪽이 더 자연스러운 1차 출구다. IGW로 인터넷에 나간 다음 그 위에서 다시 VPN을 잡는 우회는 회선 비용·지연·보안 모델 모두에서 이상한 구성이 된다. Hybrid는 hybrid 회선이 답이다.

셋째, 인스턴스가 인터넷으로 나가기만 하면 되고 인터넷에서 들어올 일은 없다면 IGW + 공인 IPv4보다 NAT Gateway 뒤에 두는 편이 보안 면에서 더 낫다. 공인 IPv4 주소를 주는 순간 외부 스캐너가 그 자원을 바로 찾을 수 있다. NAT Gateway 뒤에 두면 외부 스캐너는 그 인스턴스로 바로 들어오는 경로를 찾지 못한다. 단, 비용은 일률적으로 더 싸다고 말할 수 없다. NAT Gateway는 시간당 + GB당 이중 과금이라, 인스턴스가 적고 트래픽이 많으면 IGW + 공인 IPv4 모델이 오히려 저렴할 수도 있다. 그 산수는 뒤따르는 글에서 따져 본다.

세 경우 모두 핵심은 같다. IGW가 필요 없는 VPC에는 인터넷 경로를 미리 붙이지 않는다. AWS 콘솔이 default VPC에 IGW를 미리 붙여 두는 건 학습 시작을 쉽게 만드는 default일 뿐, 모든 워크로드의 권장 사항은 아니다. 내가 운영하는 VPC에서는 그 선 하나를 추가할 때마다 이유와 비용을 같이 확인한다.

한 칸에 숨은 비용

IGW는 박스형 장비가 아니라 VPC 경계에 연결하는 객체이고, 맡는 일도 1:1 NAT 하나다. 이 경로를 쓰려면 인스턴스 쪽에 공인 IPv4나 EIP를 따로 붙여야 하고, 그 주소 한 개에 2024년 2월 1일부터 시간당 $0.005 과금이 붙는다. 'IGW는 무료'라는 오래된 감각만 붙들면 청구서를 볼 때마다 비용 항목에서 바로 놀란다. 그 뒤에는 IGW를 붙일 때마다 함께 필요한 공인 IPv4 개수도 같이 센다. 이 계산을 먼저 하는 사람이 IGW를 제대로 이해한 운영자다.

참고 자료

• Enable internet access for a VPC using an internet gateway: Amazon VPC User Guide: IGW의 정의, 1:1 NAT, horizontally scaled·redundant·highly available 표현 출처.
• New: AWS Public IPv4 Address Charge + Public IP Insights: 2024-02-01 IPv4 시간당 과금 시작 발표 원문.
• Enable outbound IPv6 traffic using an egress-only internet gateway: Amazon VPC User Guide: egress-only IGW가 stateful이지만 주소 변환을 하지 않는다는 사실 출처.
• Elastic IP addresses: Amazon EC2 User Guide: EIP의 수명·요금 모델 정의.
• Amazon VPC Pricing: 시간당 과금이 InUseAddress·IdleAddress 두 항목으로 갈리는 사실 출처.