IGW

IGW의 가장 핵심적인 역할은 VPC 내의 리소스와 인터넷 간의 양방향 통신 경로를 제공하는 것이다. 이는 라우팅 테이블을 통해 구현되며, IGW를 대상으로 하는 라우팅 규칙이 설정된 서브넷의 리소스만 인터넷과 통신할 수 있다.

구체적으로, 관리자는 VPC의 라우팅 테이블에 특정 규칙을 추가하여 트래픽의 흐름을 제어한다. 인터넷으로 나가는 트래픽(아웃바운드)의 경우, 목적지가 0.0.0.0/0(모든 IPv4 주소)인 트래픽을 IGW를 대상(target)으로 보내는 라우팅 항목을 생성한다. 반대로, 인터넷에서 들어오는 트래픽(인바운드)은 IGW를 통해 VPC 내의 인스턴스로 전달된다. 이때 인스턴스는 퍼블릭 IP 주소 또는 탄력적 IP 주소를 가지고 있어야 외부에서 식별되고 접근될 수 있다[1].

이 라우팅 메커니즘은 서브넷 단위로 세밀하게 제어할 수 있어 아키텍처 설계에 유연성을 제공한다. 예를 들어, 웹 서버를 배치하는 퍼블릭 서브넷의 라우팅 테이블에는 IGW에 대한 라우팅 규칙이 존재하지만, 데이터베이스 서버가 위치한 프라이빗 서브넷의 라우팅 테이블에는 해당 규칙이 없도록 구성한다. 이를 통해 데이터베이스 계층은 인터넷에 직접 노출되지 않으면서도 필요한 아웃바운드 연결(예: 소프트웨어 업데이트)은 NAT 게이트웨이 등을 통해 간접적으로 수행할 수 있다.

IGW는 VPC 내의 리소스가 인터넷과 통신할 수 있게 하는 완전 관리형 서비스이다. 이 서비스의 핵심 특징 중 하나는 탄력적이고 자동화된 수평적 확장성을 제공한다는 점이다.

사용자가 IGW를 생성하고 VPC에 연결하면, AWS가 자동으로 필요한 네트워크 인프라의 용량을 관리한다. 사용자는 IGW의 대역폭이나 처리 성능을 사전에 예측하거나 수동으로 조정할 필요가 없다. IGW는 연결된 인스턴스로부터의 트래픽 양에 따라 자동으로 확장되며, 이는 탄력적 IP 주소를 사용하는 EC2 인스턴스나 로드 밸런서 등 모든 퍼블릭 리소스에 적용된다. 예를 들어, 웹 서버의 트래픽이 갑자기 증가하더라도 IGW는 이를 처리하기 위해 백엔드에서 자원을 추가로 할당한다.

이러한 설계는 사용자에게 몇 가지 중요한 이점을 제공한다. 첫째, 사용자는 네트워크 게이트웨이의 용량 계획이나 성능 튜닝에 대한 운영 부담에서 벗어날 수 있다. 둘째, IGW는 AWS의 글로벌 네트워크 인프라를 기반으로 하므로, 매우 높은 수준의 가용성과 내구성을 보장한다. 단일 장애점이 되지 않도록 설계되어 있으며, 사용자는 별도의 고가용성 구성을 신경 쓸 필요가 없다. 마지막으로, 사용량에 따른 종량제 과금 모델로 운영되므로, 최대 용량을 기준으로 선결제하거나 유휴 자원에 대한 비용을 지불하지 않아도 된다.

IGW 자체는 상태 저장(stateful) 방화벽 기능을 제공하지 않는다. 따라서 VPC 내 리소스로의 인바운드 트래픽과 아웃바운드 트래픽을 제어하기 위해서는 보안 그룹과 네트워크 ACL을 함께 사용해야 한다. 이 두 계층의 보안 메커니즘은 상호 보완적으로 작동하여 네트워크 보안을 강화한다.

보안 그룹은 인스턴스 수준의 가상 방화벽 역할을 한다. 기본적으로 모든 인바운드 트래픽을 차단하며, 명시적으로 허용 규칙을 추가해야만 트래픽이 통과할 수 있다. 보안 그룹은 상태 저장적이어서, 허용된 아웃바운드 트래픽에 대한 응답은 자동으로 인바운드로 허용된다. 반면, 네트워크 ACL은 서브넷 수준에서 작동하는 무상태(stateless) 필터링 계층이다. 서브넷 전체에 적용되는 규칙 목록을 가지고 있으며, 인바운드와 아웃바운드 트래픽에 대해 별도의 명시적 허용/거부 규칙을 정의해야 한다.

이 두 보안 계층은 다음과 같이 연동되어 작동한다. IGW를 통해 들어오는 외부 트래픽은 먼저 서브넷의 네트워크 ACL 인바운드 규칙을 평가받는다. 통과한 트래픽은 대상 인스턴스에 연결된 보안 그룹의 인바운드 규칙을 다시 평가받는다. 두 단계 모두에서 허용되어야만 인스턴스에 도달할 수 있다. 아웃바운드 트래픽의 경우 순서가 반대이다. 인스턴스의 보안 그룹 아웃바운드 규칙을 먼저 통과한 후, 서브넷의 네트워크 ACL 아웃바운드 규칙을 통과해야 IGW로 나갈 수 있다.

이러한 다층 방어 구조는 보안 강화에 유리하다. 예를 들어, 네트워크 ACL에서 특정 IP 대역을 차단하면 해당 서브넷 내 모든 인스턴스에 대한 접근이 일괄 차단된다. 반면, 특정 인스턴스에만 세밀한 접근 제어를 적용하려면 보안 그룹 규칙을 사용한다. IGW를 통한 트래픽은 항상 이 두 필터링 계층을 거치므로, 두 보안 메커니즘의 규칙을 신중하게 구성해야 의도한 대로 통신이 이루어진다.

IGW는 VPC에 연결되어야만 기능을 수행할 수 있다. 사용자는 AWS Management Console, AWS CLI 또는 AWS SDK를 통해 IGW를 생성한 후, 특정 VPC에 명시적으로 연결(Attach)하는 작업을 수행해야 한다. 하나의 IGW는 한 번에 하나의 VPC에만 연결될 수 있으며, 하나의 VPC는 동시에 하나의 IGW만 연결할 수 있다. 이 연결은 논리적이며, IGW는 VPC의 네트워크 경계 밖에 위치한 관리형 AWS 구성 요소로 작동한다.

IGW가 VPC에 연결된 후, 인스턴스가 인터넷과 통신하려면 라우팅 테이블을 올바르게 구성해야 한다. 각 서브넷은 하나의 라우팅 테이블과 연결된다. 퍼블릭 서브넷에 위치한 인스턴스가 인터넷과 양방향 통신을 하려면, 해당 서브넷의 라우팅 테이블에 인터넷 바운드 트래픽(0.0.0.0/0)을 대상으로 하는 경로(Route)를 생성하고, 그 목적지를 연결된 IGW로 지정해야 한다. 이 경로는 VPC 내부 트래픽을 위한 로컬 경로와 함께 존재한다.

라우팅 테이블 구성은 다음과 같은 예시를 가진다.

이 구성이 완료되면, 해당 라우팅 테이블이 연결된 서브넷은 퍼블릭 서브넷이 된다. 반면, 인터넷 게이트웨이를 향하는 경로(0.0.0.0/0)가 라우팅 테이블에 없는 서브넷은 프라이빗 서브넷으로 분류된다. 프라이빗 서브넷의 인스턴스는 IGW를 통해 인터넷에 직접 접근할 수 없다.

인터넷 게이트웨이(IGW)는 VPC 내 인스턴스에 퍼블릭 IP 주소를 할당하는 기능을 직접 수행하지는 않는다. 대신, 퍼블릭 IP 주소를 보유한 인스턴스가 인터넷과 양방향으로 통신할 수 있도록 하는 통로 역할을 한다. 퍼블릭 IP 주소는 EC2 인스턴스 생성 시 자동 할당되거나, 탄력적 IP 주소를 명시적으로 연결하는 방식으로 부여받는다.

IGW는 이 퍼블릭 IP 주소를 사용하는 트래픽의 라우팅을 담당한다. 인스턴스에서 인터넷으로 나가는 트래픽은 IGW를 경유하며, 이때 소스 IP 주소가 인스턴스의 퍼블릭 IP 주소로 변환된다[2]. 반대로, 인터넷에서 해당 퍼블릭 IP 주소로 향하는 들어오는 트래픽은 IGW를 통해 VPC 내의 목적지 인스턴스로 전달된다. 따라서 인스턴스가 인터넷과 통신하려면 반드시 퍼블릭 IP 주소를 가지고 있어야 하며, 동시에 해당 인스턴스가 위치한 서브넷의 라우팅 테이블이 인터넷 바운드 트래픽(0.0.0.0/0)을 IGW로 보내도록 구성되어 있어야 한다.

퍼블릭 IP 주소 없이 IGW만 존재하는 경우, 인스턴스는 인터넷에서 접근할 수 없으며 인터넷으로 나가는 트래픽도 발신할 수 없다. 아래 표는 퍼블릭 IP 주소의 존재 여부와 IGW 라우팅에 따른 통신 가능 여부를 요약한 것이다.

결론적으로, IGW와 퍼블릭 IP 주소는 별개의 개념이지만, VPC 내 리소스가 인터넷과 완전한 양방향 통신을 하기 위해서는 두 요소가 모두 필수적으로 구성되어야 한다. IGW는 게이트웨이 자체이며, 퍼블릭 IP 주소는 통신에 사용되는 실제 주소이다.

IGW를 생성하고 VPC에 연결하는 과정은 AWS Management Console, AWS CLI, 또는 AWS CloudFormation과 같은 인프라스트럭처 자동화 도구를 통해 수행할 수 있다. 일반적으로 콘솔을 통한 작업은 다음과 같은 단계로 이루어진다.

먼저 AWS Management Console의 VPC 대시보드에서 '인터넷 게이트웨이' 섹션으로 이동하여 '인터넷 게이트웨이 생성' 버튼을 클릭한다. 생성 시 이름 태그를 지정하여 식별성을 높일 수 있다. 생성된 IGW는 초기 상태가 '분리됨'으로 표시되며, 이를 사용하려면 반드시 특정 VPC에 명시적으로 연결해야 한다.

연결 과정은 생성된 IGW를 선택한 후 '작업' 메뉴에서 '인터넷 게이트웨이 연결'을 클하여 수행한다. 드롭다운 목록에서 IGW를 연결할 대상 VPC를 선택하면 연결이 완료된다. 연결 후 IGW의 상태는 '연결됨'으로 변경된다. 한 IGW는 동시에 하나의 VPC에만 연결할 수 있으며, VPC 하나는 최대 하나의 IGW만 가질 수 있다[4].

연결만으로는 인스턴스가 인터넷과 통신할 수 없다. 마지막이자 가장 중요한 단계는 VPC 내 해당 서브넷의 라우팅 테이블을 구성하여, 인터넷 바운드 트래픽(0.0.0.0/0)의 대상(Target)을 새로 연결한 IGW로 지정하는 것이다. 이 라우팅 규칙이 적용된 서브넷을 일반적으로 '퍼블릭 서브넷'이라고 부른다.

라우팅 테이블은 VPC 내 서브넷의 트래픽이 어디로 향할지 결정하는 규칙의 집합이다. 인터넷 게이트웨이(IGW)를 통해 인터넷으로 나가는 트래픽을 허용하려면, 해당 서브넷과 연결된 라우팅 테이블에 명시적인 경로를 추가해야 한다.

라우팅 테이블 구성은 일반적으로 다음 단계로 이루어진다. 먼저, 인터넷 게이트웨이(IGW)가 연결된 VPC의 라우팅 테이블을 선택하거나 새로 생성한다. 그런 다음, 대상(Destination)을 0.0.0.0/0(모든 IPv4 트래픽) 또는 ::/0(모든 IPv6 트래픽)으로 설정하고, 대상(Target)을 생성해 놓은 IGW의 ID로 지정하는 경로(Route)를 추가한다. 이 경로는 "퍼블릭 서브넷"의 인스턴스가 인터넷과 통신할 수 있는 권한을 부여한다.

이 구성은 반드시 IGW를 사용하려는 서브넷과만 연결되어야 한다. 프라이빗 서브넷은 일반적으로 이 라우팅 테이블과 연결하지 않으며, 대신 NAT 게이트웨이를 대상으로 하는 경로를 사용한다. 라우팅 테이블은 가장 구체적인 경로를 우선적으로 적용하므로, VPC 내부 주소 대역(10.0.0.0/16)에 대한 로컬 경로는 0.0.0.0/0 경로보다 항상 우선한다.

IGW 자체는 상태 저장(stateful) 패킷 검사를 수행하지 않으며, 모든 트래픽을 허용하는 통로 역할을 합니다. 따라서 VPC 내 리소스에 대한 네트워크 접근 제어는 반드시 다른 보안 메커니즘과 연동하여 구성해야 합니다.

주요 접근 제어 수단은 다음과 같습니다.

효과적인 보안을 위해 네트워크 ACL과 보안 그룹을 함께 사용하는 것이 권장됩니다. 네트워크 ACL은 서브넷 전체에 대한 광범위한 규칙(예: 특정 IP 대역 차단)을 설정하는 데 적합하고, 보안 그룹은 개별 인스턴스에 대한 세밀한 애플리케이션 포트 제어를 담당합니다. 최소 권한 원칙에 따라, 필요한 트래픽만 허용하도록 규칙을 엄격하게 구성해야 합니다.

IGW의 트래픽 흐름을 가시화하고 보안 위협을 탐지하기 위해서는 체계적인 모니터링과 로깅이 필수적이다. 주요 클라우드 제공업체들은 VPC 흐름 로그, CloudTrail (AWS 기준)과 같은 서비스를 통해 IGW를 통과하는 네트워크 패킷 및 관리 작업에 대한 상세 기록을 제공한다.

VPC 흐름 로그를 활성화하면 IGW를 포함한 특정 네트워크 인터페이스의 수신 및 발신 IP 트래픽 정보를 캡처할 수 있다. 이 로그는 허용 또는 거부된 트래픽, 프로토콜, 포트, 패킷 및 바이트 수를 기록하여 이상 징후나 비인가 접근 시도를 분석하는 데 활용된다. 예를 들어, 예상치 못한 지리적 위치에서의 접속 시도나 특정 포트에 대한 집중적인 스캔을 식별할 수 있다[6]. 한편, CloudTrail과 같은 관리 이벤트 로깅 서비스는 IGW 자체에 대한 생성, 연결, 삭제 등의 API 호출을 추적하여 구성 변경 내역과 작업자를 감사할 수 있게 한다.

효율적인 모니터링을 위해서는 이러한 로그 데이터를 Amazon CloudWatch, SIEM 솔루션 등 중앙 집중식 모니터링 플랫폼으로 전송하고 알림을 설정하는 것이 일반적이다. 다음은 주요 로그 유형과 그 목적을 정리한 표이다.

로그 데이터의 보존 기간과 저장소는 조직의 규정 준수 요구사항에 따라 설정해야 한다. 또한, 지속적으로 로그 패턴을 분석하고 알림 임계값을 조정함으로써 IGW를 통한 잠재적 공격 표면을 효과적으로 관리할 수 있다.