AWS VPC CIDR

AWS 네트워크 기본

그림으로 알아보는 AWS 네트워크 기본

written by tiaz0128

클라우드도 결국은 근원은 데이터센터 입니다. 데이터 센터를 기준으로 AWS의 네트워크 구성이 어떻게 이루어져있는지 살펴보겠습니다.

AZ(Availability Zone)

하나 이상의 데이터센터가 모이면 ‘가용영역’이라 합니다. 각 가용역역은 내결함성을 갖도록 설계되어 있으며, 재해에 대비하기 위해 다른 가용영역과 지리적으로 떨어진 곳에 위치 합니다. 각 가용용역은 프라이빗 링크를 통해 다른 가용영역과 연결되어 있습니다.

특정 가용영역의 위치를 사용자는 알수 없으며, 하나의 가용영역에 쏠림을 방지하기 위해 같은 가용영역 AZ a라고 해도 실제 위치는 사용자별로 달라질 수 있습니다.

Availability Zone

Region

리전(Region)은 최소 두 개 이상의 가용용역으로 구성되어 있습니다. 2024년 기준의 33개의 리전이 존재합니다. 현재 한국에는 하나의 리전, 서울 리전(ap-northeast-2)이 존재하고 가용영역은 4개가 존재하고 있습니다.

Region

VPC (Virtual Private Cloud)

AWS에 사용자가 구성하는 가상 네트워크 입니다. AWS의 계정 전용의 격리된 사설 IP 대역을 구성 할 수 있습니다. 기본적으로 리전당 최대 5개의 VPC를 구성할 수 있습니다.

사설 IP 대역은 아래와 같은 IP 범위를 뜻합니다. VPC는 하나의 사설 IP 대역을 보유하고, 이를 Subnet 단위로 다시 쪼개서 사용 할 수 있습니다.

10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

vpc

Subnet

VPC가 가지는 사설 IP 대역의 일부분을 논리적으로 분할한 영역 입니다. 하나의 서브넷(Subnet)은 반드시 하나의 AZ에 위치하게 됩니다. 서브넷 생성시 다음의 세가지를 반드시 설정해야 합니다.

Subnet

CIDR (Classless Inter-Domain Routing)

특정 IP 주소 또는 여러 IP 대역을 표현하는 방법을 의미합니다. 일반적인 IP와 달리 뒤에 뭔가 더 붙어 있는 형태를 가집니다. 이는 IP 주소와 Prefix 길이를 뜻합니다. IP 주소 체계를 이해하면 CIDR를 읽는 방법은 간단합니다.

[IP 주소]/[Prefix 길이]

10.0.0.0/16
192.168.1.0/24

IP 주소 체계

초기 컴퓨터들은 1byte가 꼭 8bit를 의미하지 않았기 때문에 8개의 비트를 명확하게 표현하기 위한 용어로 옥텟(Octet)이 있습니다.

IP 주소는 3개의 구분자 . 을 기준으로 크게 4개의 숫자로 구성되어 있습니다. 그리고 각 숫자 하나 하나를 옥텟이라 부릅니다. 즉 이 숫자 하나가 8bit라는 뜻입니다. 이게 어떤 의미일까요?

$Octet = 8bit = 2^8 = 256$

IP 주소는 0을 포함해서 255까지의 값을 가질 수 있는 4개의 숫자로 구성되어 있습니다. 8bit가 4개 이므로 32bit를 이용해서 컴퓨터의 인터넷 주소를 표현 할 수 있는 체계를 의미합니다. 그래서 약 42억개의 IP를 표현 가능하며 이를 정확히는 IPv4라 합니다.

$\text{IPv4} = 8bit * 4 = 32bit = 2^{32} = 4,294,967,296$

비트로 본 CIDR

이제 CIDR 10.0.0.0/16를 비트로 쪼개서 보겠습니다. IP 주소를 비트로 표현하면 아래와 같습니다.

10.0.0.0 / 16

00001010.00000000.00000000.00000000 / 16

여기에서 CIDR의 Prefix 길이 16의 의미는 ‘IP주소 중에서 앞에 있는 16개 비트를 고정시키겠다’는 의미입니다. 아래의 비트 중 앞자리 16개는 고정된 주소이며 나머지 뒤에 있는 비트는 변경 가능하다는 의미를 표현한 값입니다.

00001010.00000000.00000000.00000000 / 16
-------- --------

Subnet : CIDR 설정

이제 실제 CIDR를 VPC와 서브넷에 적용시켜 보겠습니다.

CIDR

VPC - 10.0.0.0/16

VPC의 CIDR의 Prefix 길이는 16으로 앞에 16bit를 고정한 10.0.0.0 IP 주소 범위를 사용하겠다는 의미 입니다. 해당 VPC는 IP 주소 32bit 중에서 16bit를 고정하고 나머지 16개를 사용하므로 65536개의 IP를 가질 수 있습니다.

$2^{16} = 65536 = \text{앞에 두덩이는 고정. 나머지 두 덩이(16bit)는 사용 가능}$

서브넷

해당 VPC에 속하는 서브넷은 앞에 IP 두 덩어리는 고정되고, 나머지 주소는 서브넷의 CIDR로 사용 할 수 있습니다. 여기서는 각 서브넷의 Prefix 길이를 24로 범위를 지정해봤습니다. 그러면 8개의 비트만 쓸수 있으니 256개의 IP를 사용 할 수 있는 서브넷이 됩니다.

$2^{8} = 256 = \text{Subnet은 256개의 IP를 사용할 수 있는 범위를 뜻함}$

CIDR Prefix 길이

AWS에서 VPC와 서브넷이 가질수 있는 CIDR Prefix 길이는 16 ~ 28의 사이에 값만 가질 수 있습니다. 따라서 VPC의 모든 IP를 통째로 사용하는 서브넷을 만들수 있고 /24보다 더 큰 Prefix 길이로 지정 가능합니다.

CIDR 계산기

8의 배수가 아닌 어려운 CIDR 계산은 CIDR to IPv4 Conversion와 같은 CIDR 계산기를 사용하시길 바랍니다.

예약 주소

하지만 실제로 AWS에서 사용 가능한 IP는 5개를 제외하고 계산해줘야 합니다.

Route Table

라우트 테이블(Route Table)은 VPC 내에서 네트워크 트래픽을 어디로 보낼지 결정하는 규칙의 집합입니다. 라우트 테이블은 실제로 서브넷과 연동됩니다. 서브넷은 반드시 하나의 라우트 테이블에 연결 되어 있어야 합니다. 반대로 하나의 라우트 테이블을 여러 서브넷이 함께 사용하는 것은 가능합니다.

Route Table

> 그림 1. 서브넷과 Route Table

local

CIDR 10.0.0.0/16를 가지는 VPC를 대상으로 라우트 테이블을 생성하면, 기본적으로 VPC IP 범위에 해당하는 범위를 기본 라우팅 경로로 가지며 이를 local로 표기합니다. 이 로컬 경로는 수정하거나 삭제는 불가능 합니다.

Destination Target
10.0.0.0/16 local

기본으로 로컬 경로가 생성되고 수정/삭제가 불가능 하다는 의미는 아래와 같습니다.

위의 그림 1.을 기준으로 서로 다른 Subnet에 존재하는 EC2 인스턴스 A와 B는 문제없이 통신이 가능합니다. 각 서브넷은 서로 다른 라우트 테이블과 연결되어 있지만, 기본 로컬 경로는 반드시 존재하기 때문입니다.

이건 가능한가?

그렇다면 질문입니다. 라우트 테이블에는 위와 같이 로컬 경로만 만들어져 있는 상황입니다.

정답은 ‘둘다 불가능’ 입니다. 이유가 뭔지 하나씩 알아봅시다.

Private Subnet & Public Subnet

VPC의 정의에 대해서 다시 봅시다.

AWS에 사용자가 구성하는 가상 네트워크 입니다. AWS의 계정 전용의 격리된 사설 IP 대역을 구성 할 수 있습니다.

여기서 핵심은 VPC는 ‘격리된 네트워크’라는 것 입니다. AWS에서 구성되는 VPC와 서브넷은 기본적으로 인터넷과 연결되어 있지 않은 격리된 환경입니다.

격리됐다는 이유는 간단 합니다. 라우트 테이블 어디에도 인터넷과 연결되는 경로가 나와있지 않기 때문입니다. 그림 1.에서 서브넷을 Private Subnet이라 명명한것도 AWS 내에서만 접근 가능한 서브넷이기 때문 입니다.

그렇다면 어떻게 격리된 VPC와 인터넷을 연결시킬 수 있을까요?

Internet Gateway

인터넷 게이트웨이(Internet Gateway)는 격리된 VPC와 인터넷을 연결해주는 중간 매개체 역할을 합니다. 아래와 같은 순서로 서브넷에 인터넷을 연결할 수 있습니다.

  1. 인터넷 게이트웨이를 생성
  2. 라우트 테이블에 인테넷 게이트웨이를 연결
  3. VPC 내 리소스에 공인 IP가 필요

Subnet

> 그림 2. 서브넷과 Internet Gateway

Route Table A

그림 2. Route Table A에는 아래와 같이 목적지(Destination)에 Default Routing을 의미하는 0.0.0.0/0를 인터넷 게이트웨이를 대상(Target)으로 설정하여, 가고자 하는 목적지가 라우트 테이블에 없는 경우 해당 라우팅 경로를 따르게 만듭니다.

Destination Target
10.0.0.0/16 local
0.0.0.0/0 igw-id

여기서는 기본적으로 통신 대상이 VPC 범위가 아닌 경우에는 인터넷 게이트로 연결되겠죠. 그러면 격리된 서브넷이 인터넷이 가능하게 됩니다. 이런 구성으로 이루어진 서브넷을 Public Subnet이라 합니다.

사실 서브넷은 기본적으로 격리되어있지만, ‘인터넷 게이트웨이로 라우팅이 가능한가’에 따라 Public / Private 서브넷으로 나눠질 뿐입니다.

NAT Gateway

여기서 하나 더 생각해봐야 할 것이 있습니다. ‘Private 서브넷은 인터넷 연결은 완전히 불가 한가?’ 이것은 NAT 게이트웨이(NAT Gateway)를 통해서 가능합니다.

  1. NAT 게이트웨이를 Public 서브넷 내 생성
  2. 라우트 테이블에 NAT 게이트웨이를 연결

NAT 게이트웨이는 Public 서브넷에 위치 합니다. 인터넷 게이트웨이와 연결된 서브넷이라는 뜻이겠죠? 여기서 Private IP를 Public IP로 변환 그 반대로도 변환하는 역할 수행합니다. Private 서브넷의 인스턴스들은 공인 IP가 없이도 NAT 게이트웨이를 통해 인터넷과 통신이 가능하게 됩니다.

NAT Gateway

> 그림 3. Private 서브넷과 NAT Gateway

Route Table B

그림 3. Route Table B에는 아래와 같이 목적지(Destination)에 0.0.0.0/0를 NAT 게이트웨이를 대상(Target)으로 설정합니다.

Destination Target
10.0.0.0/16 local
0.0.0.0/0 nat-gateway-id

Private 서브넷의 인스턴스들이 인터넷으로 아웃바운드 트래픽을 보낼 수 있게 하며, 반대로 인바운드 인터넷 트래픽으로부터 Private 서브넷의 인스턴스들에 직접 접근하지 못하게 보호하는 역할 또한 수행 합니다.

마무리

AWS의 가장 기본적인 Network 구성에 대해서 알아봤습니다. 핵심은 다음과 같습니다.

다음에는 해당 개념들을 실습해 볼수 있는 Bastion Host를 만들어 보면서 개념을 확인해 보겠습니다.

그리고 계속해서 위의 개념들과 연결되는 것들을 공부해보면 좋을듯 합니다.

AWS VPC CIDR
tiaz0128

Eat Sleep Coding.

Never Never Giveup.

💫 Python  |  BackEnd  |  Cloud Architect  |  DevOps