1. AWS의 리전 가용 영역
대규모의 서버 컴퓨터를 모아 둔 곳으로, 한 곳에 몰아두면 다음과 같은 단점이 존재한다.
- 자연 재해가 발생할 경우 모든 서비스가 마비됨
- 모든 자원이 북미에 있다면, 반대편인 아시아는 멀기 때문에 서비스가 느림
위의 두 가지 문제를 해결하고자 서비스를 위한 자원들을 여러 곳에 분산하여 배치해둔 것이다.

위의 그림에서 보이듯이 전세계 곳곳에 분산되어 있고, 대한민국에도 하나의 리전이 있다.
가용영역은 리전을 한 번 더 분산하여 배치한 것이라고 생각하면 된다.
2. VPC(Virtual Private Cloud)란?
우선 VPC를 공부하기 전에 서브네팅, 라우팅, IP 클래스 등의 대한 내용 선학습이 필요하다.
컴퓨터네트워크 과목을 수강했었기에 바로 VPC 이해를 위한 공부를 시작했고, 기억이 안나는 것들은 그 때마다 아래의 블로그에서 찾아보며 공부하였다.
🌐 IP 클래스 · 서브넷 마스크 · 서브넷팅 계산법 💯 총정리
아이피(IP) 정리 IP(Internet Protocol) 란 인터넷에 연결되어 있는 모든 장치들(컴퓨터, 서버 장비, 스마트폰 등)을 식별할 수 있도록 각각의 장비에게 부여되는 고유 주소이다. 아이피(ip)는 일반적으
inpa.tistory.com
VPC는 AWS 클라우드 내에서 사용자에게 할당된 논리적으로 격리된 가상 네트워크 공간으로, 데이터 센터의 네트워크를 직접 구상하듯 IP 대역, 서브넷, 라우팅 테이블, 게이트웨이를 직접 제어할 수 있다. 또한, 다른 사용자의 네트워크와 분리되어 있으므로 보안성이 뛰어나다는 장점이 있다.
AWS는 모든 서비스에 VPC를 적용하도록 강제하고 있으며, 대부분의 AWS 서비스가 VPC에 의존적이기 때문에 VPC에 대한 이해가 필수적으로 필요하다.
VPC는 가상의 네트워크 영역이기에 사설 아이피 주소를 가지게 되어, 사설 IP 대역에 맞추어 설계해야하며, 사용하는 사설 IP 대역은 아래와 같다.
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
그리고, 하나의 리전 안에서 VPC를 여러 개 생성할 때 DNS IP를 잡지 못하는 에러가 발생하지 않도록 서로 아이피는 겹치면 안된다. 예를 들면 172.31.0.0/16으로 기본 VPC가 생성되어 있다면 172.31 네트워크 IP 주소를 피해서 생성해야한다. 또한, AWS에서는 /16~/28 비트의 서브넷 마스크만을 허용한다.
그리고 VPC에서 한 번 설정된 IP 대역은 수정할 수 없으며, 각각의 VPC는 독립적이기 때문에 서로 통신할 수 없다. 통신을 하려면 VPC 피어링(peering) 서비스를 통해 VPC 간 트래픽을 라우팅할 수 있도록 설정해야한다.
3. 서브넷 (Subnet)
VPC가 논리적인 범위라면, 서브넷은 VPC의 IP 주소를 나누어 리소스가 배치되는 물리적인 주소 범위이다.
서브넷은 VPC안에서 실제로 리소스가 생성될 수 있는 네트워크 영역으로, EC2, RDS와 같은 리소스를 생성할 수 있다. 하나의 가용영역 내부에서 여러 서브넷을 생성할 수 있지만, 여러 가용영역에 거쳐 서브넷을 생성할 순 없다.
아래의 5가지 IP는 AWS의 관리 IP로서 사용자가 사용할 수 없는 주소이다.
| 10.0.0.0 | 네트워크 주소 (Network ID) |
| 10.0.0.1 | AWS에서 VPC 라우터용으로 예약 (Default Gateway) |
| 10.0.0.2 | DNS 서버 주소 DNS 서버의 IP 주소는 기본 VPC 네트워크 범위에 2를 더한 주소. CIDR 블록이 여러 개인 VPC의 경우, DNS 서버의 IP 주소가 기본 CIDR에 위치하게 된다. |
| 10.0.0.3 | AWS에서 앞으로 사용하려고 예약한 주소 |
| 10.0.0.255 | 네트워크 브로드캐스트 주소 |
호스트 범위의 첫 번째 주소는 네트워크 주소이고, 마지막 주소는 브로드캐스트 주소로서 사용할 수 없는데, 이에 3개가 추가되어 총 5개의 IP를 사용할 수 없다.
이 서브넷은 다시 Public Subnet과 Private Subnet으로 나뉘어진다.
- Public Subnet: 인터넷에 접근 가능한 Subnet으로, VPC 외부 / 내부와 통신
- Private Subnet: 인터넷에 접근 불가능한 Subnet으로, VPC 내부에서만 통신
따라서, Public Subnet에 존재하는 인스턴스는 인터넷에 연결되어 외부와 양방향 트래피을 주고 받을 수 있지만, Private Subnet은 외부에 노출도어 있지 않기에 접근할 수 없다. 그렇기에, Private Subnet에 주로 민감한 데이터 정보들을 저장해 보안을 강화하는 식으로 설계를 한다.
공용 아이피 주소는 공유기에만 할당이되고, 공유기에 연결한 디바이스들은 사설 아이피 대역을 받게 된다. 외부 인터넷은 공유기로 먼저 데이터를 보내고, 공유기는 포트를 통해 각 디바이스들을 구분하여 데이터를 보내주게 된다. 따라서, 외부 네트워크의 디바이스는 공유기를 거쳐 데이터를 보내야하는데, 공유기가 이상한 데이터를 버려준다면 보안성 측면에서 좋다.
만약 데이터 업데이트에 인터넷 연결이 필수라면 NAT Gateway를 통해 Private Subnet 내부의 인스턴스들이 인터넷에 연결이 가능하도록 할 수 있다.

4. 라우팅
각각의 Subnet은 서로 다른 네트워크 영역을 가지고 있기 때문에, 한 Subnet에서 다른 Subnet으로 가기 위해서는 Routing이 필요하다.
라우팅 테이블은 VPC 안에서 발생한 네트워크 요청을 처리하기 위해 어디로 트래픽을 전송해야하는지 알려주는 표지판 역할을 수행한다.
각 서브넷들은 이러한 라우팅 테이블을 가지고 있으며, 요청 발생시 이 라우팅 테이블을 사용해 목적지를 찾는다.
VPC 내부에 대해서는 디폴트로 Routing이 자동으로 생성되어 있어 별도의 설정 없이 한 Subnet에서 다른 Subnet으로 통신이 가능하다.

자신이 속한 Subnet이 아닌 Subnet으로 향할 때 Router를 거치게 된다.

서브넷이 라우팅 테이블을 가지고 있는 것을 확인할 수 있다.
5. 인터넷 게이트웨이
VPC는 기본적으로 격리된 네트워크 환경이므로, 인터넷과 VPC의 리소스와 통신을 활성화하기 위해서는 인터넷 게이트웨이가 필요하다.

생성한 Public Subnet을 실제 Public용으로 만들기 위해서는 인터넷 게이트웨이를 라우팅 테이블에 설정하고 등록해주어야 한다. 인터넷 게이트웨이에 연결되면 Public Subnet이고, 연결되어 있지 않으면 Private Subnet이라고 볼 수 있다.
6. 실습
1) VPC 실전 구성
리전을 서울로 변경하고 VPC를 생성한다.

추가적으로 설정에서 DNS 호스트 이름을 활성화한다.
2) Subnet 실전 구성
| ap-northeast-2a(AZ) | ap-northeast-2c(AZ) | |
| Public Subnet | 10.0.1.0/24 | 10.0.2.0/24 |
| Private Subnet | 10.0.3.0/25 | 10.0.4.0/25 |
위의 표처럼 2개의 가용범위를 Public Subnet 2개, Private Subnet 2개로 구성해본다.

위에서 만든 VPC를 선택한다.
![]() |
![]() |
![]() |
![]() |
위처럼 Public Subnet, Private Subnet을 각각 2개씩 만들었다.

성공적으로 4개의 서브넷이 만들어졌다.
두 개의 Public Subnet에 주소 자동 할당 활성화를 체크한다.
3) Subnet에 EC2 인스턴스 넣기


Private, Public Subnet에 각각 Instance를 1개씩 생성한다.

2개의 인스턴스가 생성되었다.
4) 인터넷 게이트웨이 설정
아래와 같이 인터넷 게이트웨이를 생성해준다.

아직 VPC에 연결하지 않았기에 상태는 Detached이다.

위에서 생성한 VPC에 이어서 연결해준다.

퍼블릭용 라우팅 테이블을 생성하여, 이전에 만든 public subnet들이 진짜 public용으로 설정되게 라우팅 설정을 완료한다.


기본(예)로 생성된 서브넷들은 기본적으로 private-table을 사용해서 인터넷에 접근하지 못하는 보안성을 확보하고, 외부와 연결이 필요한 서브넷들은 public-table을 따로 추가로 만들어서 넣어주면 된다.
이후에 public subnet 2개를 public routing table에 등록한다.

발생하는 모든 트래픽에 대해 10.0.0.0/16은 로컬로 보내고 이를 제외한 모든 트래픽은 외부 인터넷과 연결하도록 public-table을 편집해준다.

라우팅 테이블 연결 설정을 마치면 정말로 public 서브넷과 prviate 서브넷을 완성시킨 것이다.
아래 사진에서 보이듯 명시적으로 인터넷 게이트웨이를 연결한 라우팅 테이블에 등록함으로서 외부에 연결이 된 것이며, public-subnet 2개는 외부로 연결이 되었고, private-subnet 2개는 외부로 연결이 되어 있지 않다.

최종적으로 아래와 같은 구조를 지니게 된다.

7. 마무리하며
이번에 처음으로 AWS Cloud를 사용해서 VPC와 서브네팅, 마지막으로 인터넷 게이트웨이까지 연결을 해보았는데, 이론적으로 공부하여 새로운 사실들을 알긴 했는데, 이를 어떻게 배포에 실제로 사용할지는 아직 잘 모르겠다.
그래도 첫 시작을 했으니 더욱 공부해봐서 실제로 배포하고 운영해보며 실무적인 경험을 해보아야겠다. 그래도 생각보다 꽤 재밌어서 시간이 날 때마다 틈틈히 더 공부해보아야겠다.
'[INFRA] > [AWS CLOUD]' 카테고리의 다른 글
| [AWS CLOUD] IAM (2) | 2026.05.12 |
|---|---|
| [AWS CLOUD] EC2 (0) | 2026.05.10 |



