AWS VPC를 사용한다면 알아야 할 네트워크 기초 지식

BackEnd🌱/Etc

AWS VPC를 사용한다면 알아야 할 네트워크 기초 지식

dkswnkk 2024. 4. 24. 22:04

개요

AWS를 사용하거나 다른 인프라 구조를 많이 살펴보다 보면 VPC(Virtual Private Cloud) 구조를 자주 접하게 됩니다. 이러한 VPC 구조를 이해하기 위해서는 네트워크 기초 지식이 꽤 많이 필요한데요, 이번 게시글에서는 AWS를 사용할 때 VPC의 개념과 관련 용어들에 대해 자세히 한번 살펴보도록 하겠습니다. 이번 게시글을 완독하고 나면 아래 이미지와 같은 구조를 이해할 수 있습니다.

Amazon VPC(Virtual Private Cloud)란 무엇일까?

Amazon VPC는 사용자가 정의하는 AWS 계정 전용의 가상 네트워크입니다. 사용자는 VPC 내에서 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워크 환경을 직접 구성할 수 있으며, 이를 통해 AWS 클라우드 내에서 자신만의 독립적인 네트워크 환경을 구축할 수 있습니다. 그리고 VPC는 사용자가 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사한 구조를 가지고 있어, AWS의 확장 가능한 인프라를 활용할 수 있다는 장점이 있습니다.

내용을 더 알아보기 위해서는 사전에 IP, 서브넷, 서브넷 마스크, CIDR, 서브네팅에 대한 내용을 사전 학습해야 합니다. 따라서 이 용어들 먼저 정리하고 가겠습니다.

IP 주소(IP Address)

IP 주소는 인터넷에 연결된 모든 장치(컴퓨터, 서버, 스마트폰 등)를 고유하게 식별할 수 있는 주소입니다. 일반적으로 192.168.1.100과 같이 마침표로 구분된 4개의 숫자로 표현되며, 점으로 분리된 10진수 형식으로 표시합니다. 그리고 이를 32비트 이진수로 표현하면 11000000.10101000.00000001.01100100와 같이 표현할 수 있습니다. 각 옥텟(octet)은 8비트로 구성되어 있습니다.

이진수 체계는 0과 1로만 수를 표현하는 방식으로, IP 주소의 이진수 표현은 네트워크 장비들이 IP 주소를 인식하고 통신하는 데 필수적입니다. IP 주소는 총 32비트로 구성되어 있으며, 1비트가 2 임에 따라 2^32, 약 43억 개의 고유한 주소를 가지게 됩니다.

https://www.networkacademy.io/ccna/ip-subnetting/converting-ip-addresses-into-binary

IP 주소는 네트워크 ID와 호스트 ID로 구성됩니다. 네트워크 ID는 전 세계적(국가나 지역)으로 고유하게 할당된 식별자로 해당 IP 주소가 어느 네트워크에 속하는지 알려줍니다. 따라서 네트워크 ID가 같다면 해당 IP 주소가 같은 국가나 지역에 속한다는 것을 알 수 있습니다. 그리고 호스트 ID는 개별 호스트를 식별하기 위해 사용되며, 이를 통해 네트워크 내의 각 장치들을 고유하게 구분할 수 있습니다.

예를 들어, IP주소 172.16.0.100을 살펴보면 네트워크 ID는 172.16.0 호스트 ID는 100입니다. 따라서 172.1.6.0으로 시작하는 172.16.0.x의 IP 주소를 가진 장치들은 모두 같은 네트워크에 속해 있다고 볼 수 있습니다.

IP 주소의 클래스 구분

클래스 기반 IP 주소 할당 방식은 1981년부터 1993년까지 인터넷에서 사용되었던 IP 주소 체계로써 이 방식은 IPv4 주소 공간을 A, B, C, D, E 클래스로 나누어 할당하는 방법입니다. IP 주소는 이전에 봤듯이 이진수로 표현하면 32비트로 구성되어 있고, 이를 8비트씩 4개의 옥텟(Octet)으로 나눌 수 있습니다. 각 옥텟은 0부터 255까지의 범위를 가지므로, 총 256개의 값을 표현할 수 있습니다.

이러한 IP 주소는 A, B, C, D, E 클래스로 구분되며, 각 클래스는 네트워크 ID와 호스트 ID의 범위가 다르게 설정되어 있습니다.

https://ee2ee2.tistory.com/entry/Network-IP-%ED%81%B4%EB%9E%98%EC%8A%A4ABC-class%EB%9E%80

각 클래스에 대한 설명은 다음과 같습니다.

A 클래스
- A 클래스 IP 주소의 첫 번째 옥텟 범위는 1부터 126까지로, 이진수로 표현하면 00000001(1) ~ 01111110(126)입니다.
- 첫 번째 옥텟의 비트가 0으로 고정됩니다. 따라서 표현할 수 있는 범위는 첫 옥텟이 1 ~ 126 사이의 숫자로 시작합니다.
- A 클래스에서 네트워크 ID는 첫 번째 옥텟(8비트)으로 구성되며, 호스트 ID는 나머지 3개 옥텟(24비트)으로 구성됩니다.
- 호스트 ID는 24비트로, 2^24 = 16,777,216개의 호스트를 수용할 수 있습니다.
B 클래스
- B 클래스 IP 주소의 첫 번째 옥텟 범위는 128부터 191까지로, 이진수로 표현하면 10000000(128) ~ 10111111(191)입니다.
- 첫 번째 옥텟의 두 번째 비트가 10으로 고정됩니다. 따라서 표현할 수 있는 범위는 첫 옥텟이 128 ~ 291 사이의 숫자로 시작합니다.
- B 클래스에서 네트워크 ID는 처음 2개 옥텟(16비트)으로 구성되며, 호스트 ID는 마지막 2개 옥텟(16비트)으로 구성됩니다.
- 호스트 ID는 16비트로, 2^16 = 65,536개의 호스트를 수용할 수 있습니다.
C 클래스
- C 클래스 IP 주소의 첫 번째 옥텟 범위는 192부터 223까지로, 이진수로 표현하면 11000000(192) ~ 11011111(223)입니다.
- 첫 번째 옥텟의 세 번째 비트가 110으로 고정됩니다. 따라서 표현할 수 있는 범위는 첫 옥텟이 192 ~ 223 사이의 숫자로 시작합니다.
- C 클래스에서 네트워크 ID는 처음 3개 옥텟(24비트)으로 구성되며, 호스트 ID는 마지막 1개 옥텟(8비트)으로 구성됩니다.
- 호스트 ID는 8비트로, 2^8 = 256개의 호스트를 수용할 수 있습니다.
D 클래스
- D 클래스 IP 주소의 첫 번째 옥텟 범위는 224부터 239까지로, 이진수로 표현하면 11100000(224) ~ 11101111(239)입니다.
- 첫 번째 옥텟의 네 번째 비트가 1110으로 고정됩니다. 따라서 표현할 수 있는 범위는 224.0.0.0 ~ 239.255.255.255가 됩니다.
- D 클래스는 멀티캐스트용 주소 대역으로 사용되며, 멀티캐스트는 한 대의 송신자가 다수의 수신자에게 데이터를 전송하는 방식입니다.
E 클래스
- E 클래스 IP 주소의 첫 번째 옥텟 범위는 240부터 255까지로, 이진수로 표현하면 11110000(240) ~ 11111111(255)입니다.
- 첫 번째 옥텟의 네 번째 비트가 1111로 고정됩니다. 따라서 표현할 수 있는 범위는 240.0.0.0 ~ 255.255.255.255가 됩니다.
- E 클래스는 연구용으로 예약된 주소 대역입니다.

여기서 유의할 점이 있는데, IP 주소에는 실제 호스트 주소로 사용할 수 없는 두 가지 유형의 주소인 네트워크 주소와 브로드캐스트 주소가 존재합니다. 네트워크 주소는 호스트 ID가 모두 0인 주소로 표현되며, 해당 네트워크를 식별하는 데 사용됩니다. 브로드캐스트 주소는 호스트 ID가 모두 1인 주소로 표현되며, 네트워크의 모든 호스트로 데이터를 전송하는 통로로 사용됩니다.

192.168.10.0은 192.168.10 네트워크 자체를 가리키는 네트워크 주소
192.168.10.255는 192.168.10 네트워크의 브로드캐스트 주소

이처럼 네트워크 주소와 브로드캐스트 주소는 IP 주소 체계에서 특별한 용도로 사용되므로, 실제 호스트 주소로 사용할 수 없습니다. 일반적으로 사용자들은 네트워크 주소와 브로드캐스트 주소를 제외한 범위인 192.168.10.1 ~ 192.168.10.254 사이의 주소를 할당받아 사용하게 되며, 그중 192.168.10.1은 보통 공유기(라우터)가 사용하는 주소가 됩니다.

서브넷(Subnet)과 서브네팅(Subnettin)

IPv4 주소 체계는 43억 개의 IP 주소를 가지고 있어 충분할 것으로 보였지만, 인터넷의 급격한 성장으로 인해 결국 IP 주소 부족 문제가 발생했습니다. 기존의 IP 클래스 단위로 IP를 나누어 사용자에게 할당하는 방법은 매우 비효율 적이었는데, 클래스 B 영역(65,546개 IP)을 할당받은 기업은 2^16-2개의 IP를 사용 가능하지만 실제로는 10,000개의 IP만 사용한다면, 나머지 약 55,000개의 IP가 사용되지 않고 점유만 되어 IP가 낭비되는 문제가 생겼기 때문입니다. 그렇다고 10,000개의 IP를 사용하는 이 기업에게 클래스 C 영역(256개 IP)을 할당할 수도 없었습니다.

따라서 클래스로만 네트워크를 분류하는 것은 비효율적이라는 결론이 나왔고, 좀 더 적절한 단위로 네트워크를 분할해야 할 필요성을 느끼게 되었습니다. 그리고 이러한 이유로 인해서 서브넷의 개념이 탄생하게 되었습니다.

서브넷(Subnet)은 하나의 네트워크가 분할되어 나눠진 작은 네트워크를 의미하며, 네트워크를 운영 중인 서비스의 규모에 맞게 분할하기 위한 기술로 낭비되는 IP 주소 자원을 최소화하려는 것이 주된 목적입니다. 그리고 이렇게 네트워크를 분할하는 과정을 서브네팅(Subnettin)이라고 하며, 서브네팅은 서브넷 마스크(Subnet Mask)를 통하여 수행될 수 있습니다.

서브넷 마스크(Subnet Mask)

서브넷 마스크는 IP 주소를 네트워크 주소와 호스트 주소로 나누는 데 사용됩니다. IP 주소와 마찬가지로 32비트 이진수로 표현되며, 일반적으로 255.255.255.0과 같은 형식으로 표기하여 이를 통해 네트워크와 호스트 부분을 명확하게 구분 지을 수 있습니다.

서브넷 마스크가 IP와 표현이 다른 점은 서브넷 마스크는 연속된 1과 연속된 0으로 구성되어 있다는 점입니다. 예를 들어,

10011111.11011111.11110011.00000000과 같이 중간에 1과 0이 섞여 있는 형태는 가질 수 없고,
11111111.11111111.11111100.00000000처럼 연속된 1 다음에 연속된 0이 따르는 형태만 가능합니다.

앞서 서브넷 마스크는 네트워크 구분과 호스트 부분을 명확하게 구분 지어 준다고 했는데 위 이미지를 보면 보이듯이 서브넷 마스크 옥텟(1바이트)이 255면 네트워크 아이디를 가리키게 됩니다. 따라서 아주 간단하게 IP 주소와 서브넷 마스크를 이용해서 이 IP가 어느 클래스에 속하는지 알 수 있습니다. 예를 들어 IP주소 205.0.1.129와 서브넷 마스크 255.255.255.128을 사용하는 경우, 이 IP 주소는 205.0.1.129 ~ 205.0.1.255 범위의 네트워크에 속한다는 것을 알 수 있습니다.

CIDR(Classless Inter Domain Routing)을 사용한 서브넷 마스크 간소화

CIDR은 1993년에 도입된 클래스 없는 도메인 라우팅 기법으로, IP 주소 할당을 보다 유연하게 관리할 수 있게 해 줍니다. 위에서 배운 서브넷 마스크를 CIDR 표기법을 사용하여 더욱 간소화해서 표현할 수 있습니다.

예를 들어 IP 주소가 192.168.0.1/24라면 /24는 32비트 주소 중 앞의 24비트가 네트워크 주소로 사용되며, 나머지 8비트는 호스트 주소로 사용됩니다. 따라서 일반적인 서브넷 마스크 255.255.255.0과 동일한 네트워킹 효과를 나타냅니다.

CIDR 표기법을 사용하면 IP 주소 입력이 더 간결해지는데 기존에 192.168.1.17과 255.255.255.0을 함께 사용했던 것을 192.168.1.17/24로 더 간결하게 표현할 수 있습니다. 따라서 서브넷 정보를 표현하는 데 필요한 데이터 크기를 4바이트에서 6비트로 대폭 줄여 네트워크 리소스를 절약할 수 있게 되었고, CIDR을 통해 IP 주소의 클래스를 명확하게 식별할 수 있습니다.

10.10.10.10/8은 A 클래스 네트워크
172.16.1.10/16은 B 클래스 네트워크
192.168.100.10/24는 C 클래스 네트워크

CIDR 표기법을 이해하면 /? 수에 따라 할당받을 수 있는 IP 주소의 개수를 손쉽게 파악할 수 있습니다.

서브네팅(Subnetting)

서브네팅은 IP 주소를 효과적으로 분할하여 사용하는 기법입니다. 예를 들어 100개의 호스트만 필요로 하는 기업이 클래스 C IP 주소 192.168.10.0/24를 할당받았다고 가정해 봅시다. 이 주소 범위는 원래 256개(2^8)의 호스트를 수용할 수 있지만, 이 기업에게는 150개 이상의 호스트가 남아도는 셈이 됩니다. 따라서 이 주소 범위를 효율적으로 사용하기 위해 128개와 128개의 주소를 포함하는 두 개의 서브넷으로 분할할 수 있습니다.

256개의 주소를 절반으로 나누는 작업을 진행해 봅시다.

128개씩 두 개의 서브넷을 나누기 위해 호스트 ID의 가장 왼쪽 비트를 서브넷 구분 비트로 설정해야 합니다. 이 비트 값에 따라 IP 주소의 호스트 부분이 두 개의 구역으로 분할되는데, 이 구분은 호스트 ID의 이진 값에 따라 결정됩니다.

이 비트의 값에 따라 호스트 ID 범위가 다음과 같이 두 부분으로 나뉘어집니다.

.00000000 ~ .01111111 (0 ~ 127)
.10000000 ~ .11111111 (128 ~ 255)

즉 호스트 ID 맨 왼쪽 비트가 0이냐 1이냐에 따라 서브넷이 두 개로 분리되게 됩니다. 따라서 서브넷 구분 비트가 2^7(128) 값을 기준으로 할 때, IP 주소는 다음과 같습니다.

이렇게 절반으로 나눈 한 서브넷 부분을 이제 회사에게 할당하고 나머지도 필요한 곳에 분배하면 됩니다. 하지만 이때 위에서 유의했듯이 각각의 서브넷에서 실제로 사용할 수 있는 IP 주소는 네트워크 주소와 브로드캐스트 주소를 제외한 범위입니다. 따라서 사용 가능한 IP 주소는 다음과 같습니다.

첫 번째 서브넷: 192.168.10.1 ~ 192.168.10.126
두 번째 서브넷: 192.168.10.129 ~ 192.168.10.254

이렇게 서브네팅을 통해 한 서브넷을 특정 기업에 할당하고, 나머지 서브넷은 다른 필요한 곳에 효율적으로 분배할 수 있습니다.

AWS VPC

이제 드디어 용어 정리가 끝났으니 진짜 AWS VPC에 대해서 알아봅시다. 구축하는 과정부터 하나하나 살펴보겠습니다.

VPC를 구축하기 위해서는 VPC의 IP 범위를 RFC1918이 정의한 사설 IP 대역에 맞추어야 합니다. 사설 IP는 인터넷 전체에 공개되지 않고 특정 사설 네트워크 내에서만 사용되는 IP 주소를 말하는데, 이를 회사의 운영 방식에 비유하면 이해하기 쉽습니다. 회사 내부에서만 사용되는 내선 번호가 사설 IP와 유사하며 회사 내부의 직원들 간 소통에서 사용됩니다. 그리고 회사가 외부의 사람들과 소통할 때는 공용 IP를 사용합니다. 이때 공용 IP는 회사의 도로명 주소와 같이 외부에서 회사의 네트워크 위치를 식별할 수 있게 해주는 고유한 식별자입니다.

사설 IP는 특정 범위의 값만 허용되며, 사용 가능한 사설 IP 대역은 다음과 같습니다.

10.0.0.0 ~ 10.255.255.255 (10.0.0.0/8): 이 범위는 대규모 네트워크에 적합하며, 큰 기업이나 조직에서 많이 사용됩니다.
172.16.0.0 ~ 172.31.255.255 (172.16.0.0/12): AWS에서 기본적으로 제공하는 VPC 설정에 사용되며, 중간 규모의 네트워크에 적합합니다.
192.168.0.0 ~ 192.168.255.255 (192.168.0.0/16): 주로 소규모 네트워크나 가정 네트워크에서 사용되는 범위입니다.

한번 설정된 IP 대역은 변경할 수 없으며 각 VPC는 특정 리전에 종속됩니다. VPC는 완전히 독립적으로 운영되기 때문에 다른 VPC와 통신을 원할 경우 VPC 피어링 서비스를 이용해야 합니다. 그리고 사설 IP 대역은 내부 통신용으로 설계되어 외부 인터넷과 직접 연결되지 않기 때문에 인터넷과 연결하려면 후에 알아볼 NAT(Network Address Translation)와 같은 기술을 통해 사설 IP를 공용 IP로 변환하는 과정이 필요합니다.

AWS Subnet

VPC를 만들었다면 다음 단계로 서브넷을 만들 수 있습니다. 서브넷은 VPC를 더 작은 네트워크 단위로 세분화하는 과정으로, 이를 통해 더 작은 IP 범위를 갖게 됩니다.

각 서브넷은 특정 가용 영역 안에 위치해야 하며 해당 영역에서는 RDS, EC2와 같은 리소스들을 배치할 수 있습니다. 그리고 AWS에서는 각 서브넷에 대해 5개의 IP 주소를 미리 예약해서 사용하고 있기 때문에 AWS VPN에서는 다음과 같은 IP 주소는 사용할 수 없습니다.

10.0.0.0: 네트워크 주소
10.0.0.1: VPC 라우터를 위해 예약됨
10.0.0.2: AWS 제공 DNS에 매핑을 위해 예약됨
10.0.0.3: 미래 사용을 위해 예약됨
10.0.0.255: 네트워크 브로드캐스트 주소. AWS는 VPC 내 브로드캐스트를 지원하지 않으므로 이 주소는 사용할 수 없음

예를 들어 EC2 인스턴스에 29개의 IP 주소가 필요한 경우, /27 크기의 서브넷(총 32개 IP 중 5개가 예약되어 실 사용 가능한 IP는 27개)으로는 부족합니다. 따라서 필요한 IP 수를 충족시키기 위해 최소 /26 크기의 서브넷(총 64개 IP 중 5개가 예약되어 실 사용 가능한 IP는 59개)을 선택해야 합니다.

라우팅 테이블과 라우터

라우터는 데이터의 목적지로서 작동하며, 라우팅 테이블은 각 목적지로 향하는 경로를 안내하는 역할을 합니다. 라우팅 테이블은 각 목적지로 향하는 경로를 안내하는 역할을 하며 데이터가 라우터에 도착하면 라우팅 테이블에 정의된 규칙에 따라 처리됩니다.

예를 들어 서브넷 A의 라우팅 테이블이 172.31.0.0/16 범위의 네트워크 요청을 로컬로만 처리하도록 설정되어 있다면, 해당 범위 내의 트래픽은 VPC 내부에서만 이동합니다. 외부로 나가는 트래픽은 이 라우팅 테이블로는 처리할 수 없으며, 이런 경우에는 인터넷 게이트웨이를 사용하여 외부 네트워크와의 연결을 가능하게 설정해야 합니다.

즉 라우팅을 하는 이유는 VPC 내 서로 다른 서브넷 간의 통신을 가능하게 하기 위함으로 라우팅을 통해 VPC 내 서브넷에 할당된 리소스라면 어느 서브넷이든 다른 서브넷의 리소스와 자유롭게 통신을 할 수 있습니다.

인터넷 게이트웨이

인터넷 게이트웨이는 VPC와 인터넷 사이를 연결해 주는 관문 역할을 합니다. 예를 들어 서브넷 B의 라우팅 테이블에는 0.0.0.0/0으로 설정되어 있어 모든 트래픽이 인터넷 게이트웨이 A로 보내지도록 지시합니다. 라우팅 테이블은 우선 목적지 주소가 172.31.0.0/16과 일치하는지 확인하고 일치하지 않을 경우 모든 트래픽을 인터넷 게이트웨이 A로 라우팅 합니다.

인터넷과 직접 연결된 서브넷은 퍼블릭 서브넷이라 하며, 연결되지 않은 서브넷은 프라이빗 서브넷이라고 합니다. 인터넷 게이트웨이는 VPC의 리소스(ex. EC2 인스턴스)가 인터넷에 접속할 수 있도록 지원하며, 수평적으로 확장 가능하고 높은 가용성 및 중복성을 제공합니다. 인터넷 게이트웨이는 VPC와 별도로 생성되어야 하며, 한 VPC는 오직 하나의 인터넷 게이트웨이에만 연결될 수 있습니다.

네트워크 ACL과 보안그룹

네트워크 ACL(Network Access Control List)과 보안그룹(Security Group)은 VPC 내에서 인바운드 및 아웃바운드 트래픽에 대한 보안 정책을 설정하여 트래픽을 관리합니다. AWS 인프라에서 인바운드는 외부 사용자에서 AWS 자원으로 들어오는 트래픽을 의미하고, 아웃바운드는 AWS 자원에서 외부로 나가는 트래픽을 말합니다.

그런데 여기까지 봤을 때는 네트워크 ACL과 보안 그룹 모두 인바운드 규칙과 아웃바운드 규칙을 가지며 IP 주소와 프로토콜 그리고 포트 번호를 통해 대상을 식별하고 허용 여부를 판단하는 동일한 기능을 하는 것처럼 보입니다. 자세한 Security Group과 Network ACL의 차이점은 다음과 같습니다.

보안그룹(Security Group)

먼저 보안그룹은 상태 유지(Stateful) 방식으로 동작하여, 한 번 트래픽 허용이 이루어지면 해당 세션의 반환 트래픽도 자동으로 허용됩니다. 기본적으로 모든 인바운드 트래픽은 차단되어 있으며, 관리자는 필요한 트래픽만 허용하도록 설정할 수 있어 인스턴스 또는 서브넷 단위로 세밀한 트래픽 제어가 가능합니다.

연결이 한 번 허용되면 해당 세션의 반환 트래픽도 자동으로 허용하는데, 인바운드로 들어오는 트래픽에 대해 인바운드 규칙 확인 후 대상의 인스턴스 접근이 허용된다면, 그 상태 정보를 기억하고 있어서 아웃바운드로 되돌아갈 때(return traffic) 아웃바운드 규칙과 상관없이 허용됩니다. 따라서 보안 그룹은 허용 규칙만 존재하며 그 대상이 아닌 트래픽은 자동으로 거부됩니다.

기본적으로 모든 인바운드 트래픽은 차단되며, 관리자가 필요에 따라 특정 트래픽을 허용하도록 설정해야 합니다. 보안그룹은 각 인스턴스 또는 서브넷 단위로 적용할 수 있어 세밀한 트래픽 제어가 가능합니다.

네트워크 ACL

반면 네트워크 ACL은 상태 비저장(Stateless) 방식으로 작동하여, 인바운드 및 아웃바운드 규칙을 각각 독립적으로 처리합니다. 모든 트래픽이 기본적으로 허용되는 것이 아니기 때문에 관리자가 명시적으로 트래픽을 제한하거나 허용하는 규칙을 설정해야 합니다. 네트워크 ACL은 서브넷 단위로 적용되며 각 서브넷에는 하나의 ACL이 할당됩니다. 새 서브넷은 기본 네트워크 ACL로 설정되며 모든 트래픽을 허용하는 설정을 가지고 있습니다.

인바운드로 들어오는 트래픽에 대해 인바운드 규칙 확인 후에 대상이 허용된다고 해도 그 상태 정보를 기억하고 있지 않기 때문에 아웃바운드로 되돌아갈 때 아웃바운드 규칙에 따라 허용할지 거부할지를 결정하게 됩니다. 즉 허용 규칙과 거부 규칙이 둘 다 존재한다고 볼 수 있습니다.

네트워크 ACL은 서브넷 단위로만 적용되며 각 서브넷에는 하나의 네트워크 ACL이 할당됩니다. 새 서브넷은 기본적으로 기본 네트워크 ACL에 연결되며 기본 네트워크 ACL은 모든 인바운드 및 아웃바운드 트래픽을 허용하는 설정을 가지고 있습니다. AWS에서는 기본 네트워크 ACL을 수정하지 말고, 필요에 따라 사용자 지정 네트워크 ACL을 생성하여 사용하는 것을 권장하고 있으며, 네트워크 ACL과 보안그룹의 우선순위는 보안그룹이 더 높은 우선순위를 가져갑니다.

NAT 게이트웨이

NAT 게이트웨이는 프라이빗 서브넷의 인스턴스가 인터넷과 통신할 수 있도록 하는 핵심 리소스입니다. 인터넷은 공공 네트워크 구간으로 퍼블릭 IP 주소를 사용하지만, 프라이빗 서브넷의 인스턴스는 프라이빗 IP 주소를 사용하기 때문에 NAT 게이트웨이가 이러한 프라이빗 IP 주소를 퍼블릭 IP 주소로 변환하여 인터넷 접속을 가능하게 합니다.

여기서 NAT 게이트웨이는 한쪽 방향으로만 동작한다는 것에 주의해야 하는데, 프라이빗 서브넷에서 외부 인터넷으로 통신이 가능하지만 반대로 외부 인터넷에서 프라이빗 서브넷으로 통신은 불가능합니다. 이러한 구조를 통해 외부에서의 접근은 막고, 서브넷 내에 배치된 인스턴스들은 인터넷에 접근할 수 있도록 하여 보안을 높일 수 있습니다. 이와 달리 인터넷 게이트웨이는 퍼블릭 서브넷의 외부 인터넷 구간을 연결하는 역할을 하기 때문에 퍼블릭 서브넷과 인터넷 사이의 양방향 통신을 지원합니다.

프라이빗 서브넷의 인스턴스가 외부 인터넷에 접근하는 과정은 다음과 같습니다.

프라이빗 EC2 인스턴스가 프라이빗 IP 주소를 사용하여 라우터에 데이터를 전송합니다.
라우터는 프라이빗 라우팅 테이블을 참고하여 NAT 게이트웨이로 향하는 경로를 확인합니다.
NAT 게이트웨이는 프라이빗 IP 주소를 퍼블릭 IP 주소로 변환하고, 인터넷 게이트웨이를 거쳐 외부 인터넷으로 데이터를 전송합니다.
이때 사용자는 NAT 게이트웨이에서 변환한 퍼블릭 IP로 전달받습니다.

정리

IP, 서브넷, 서브넷 마스크, CIDR, 서브네팅과 같은 주요 네트워크 용어들에 대해 알아보았고, AWS에서 VPC를 구축하기 위해 사용되는 용어들에 대해서도 살펴보았습니다. 이제 아래의 이미지가 이해가 되시나요?

이 외에도 VPC 간 통신을 가능하게 하는 VPC 피어링, 온프레미스와의 연결을 지원하는 AWS Direct Connect, 그리고 VPC에서 발생하는 로그를 기록하는 VPC Flow Logs와 같은 서비스들도 존재합니다. 요런 용어들에 대해서도 이런 게 있구나 알아두면 좋을 것 같고, AWS SAA 자격증을 따기 위해 학습하시는 분이라면 VPC파트인 보안의 비중이 가장 높으니 조금 더 자세히 알아보시면 좋을 것 같습니다.

참고

저작자표시