티스토리 뷰
Amazon VPC(Virtual Private Cloud)
Amazon VPC(Virtual Private Cloud)는 사용자 정의로 구성된 가상의 프라이빗 클라우드 네트워크를 말한다. 마치 자신만의 데이터 센터에서 네트워크 환경을 구성하는 것처럼 원하는대로 사설망을 구축하여 부여된 IP 대역을 분할하여 사용할 수 있다. Amazon EC2 인스턴스와 같은 AWS 리소스를 VPC에서 실행할 수 있다.

VPC는 하나의 리전마다 독립적으로 구성된다. 예를 들어, 서울 리전에 VPC를 생성했다면 생성한 VPC는 서울 리전에만 있으며, 다른 리전에는 없다. 그리고 리전 내에서 다수의 VPC를 생성해도 서로 독립적으로 분리된다.
VPC에는 다음과 같은 구성 요소가 있다.
- 서브넷
- 인터넷 게이트웨이
- NACL/보안그룹
- 라우트 테이블
- NAT Instance/NAT Gateway
- Bastion Host
- VPC Endpoint
사설망과 NAT
Amazon VPC를 이해하는데 다음 사전 지식들을 알 필요가 있다.
공인 IP 주소와 사설 IP 주소
공인 IP 주소(Public IP Address)는 전 세계에서 고유한 IP 주소로, 네트워크 간의 통신에서 사용할 때 사용하는 IP 주소이다. 공인 IP 주소는 ISP나 공인 IP 주소 할당 기관을 통해 할당받을 수 있다.
사설 IP 주소(Private IP Address)는 외부에 공개되지 않은 사설 네트워크에서 사용하기 위한 IP 주소이다. 사설 IP 주소의 할당 주체는 일반적으로 라우터이다. 할당받은 사설 IP 주소는 해당 호스트가 속한 사설 네트워크상에서만 유효한 주소로, 다른 네트워크상의 사설 IP 주소와 중복될 수 있다.
NAT(Network Address Translation)
NAT은 IP를 변환하는 기술을 말한다. 주로 네트워크 내부에서 사용되는 사설 IP 주소와 네트워크 외부에서 사용되는 공인 IP 주소를 변환하는데 사용한다. 현재 많이 사용하고 있는 대표적인 NAT 기술은 NAPT(Network Address Port Translation)이다.
NAPT 기술에 대해서는 TCP/IP모델(TCP/IP 4계층) 블로그에서 자세히 확인할 수 있다.
서브넷

Amazon VPC라는 하나의 독립된 클라우드 네트워크에도 서브넷을 이용하여 분리된 네트워크로 구성할 수 있다. 서브넷은 VPC 내 별도로 나누어진 네트워크로 하나의 가용 영역에 종속적으로 위치한다. 서브넷은 VPC 네트워크 환경 구성에 따라 퍼블릭 서브넷과 프라이빗 서브넷으로 분류할 수 있다.
- 퍼블릭 서브넷: 인터넷 구간과 연결되어 있어 외부 인터넷 통신이 가능한 네트워크 영역
- 안에 위치한 인스턴스에 퍼블릭 IP 부여 가능
- 웹서버, 애플리케이션 서버 등 유저에게 노출되어야 하는 인프라를 둠
- 프라이빗 서브넷: 인터넷 구간과 연결되지 않은 폐쇄적인 네트워크 영역
- 외부 인터넷으로 오가는 경로가 없음
- 퍼블릭 IP 부여 불가능
- 데이터베이스, 로직 서버 등 외부에 노출될 필요가 없는 인프라를 둠
IP CIDR

IP CIDR는 네트워크에 할당할 수 있는 IP 주소 범위를 표현하는 방법이다. Amazon VPC는 내부에 생성할 서브넷의 IP 주소 범위를 할당하기 위해 IP CIDR를 가지고 있으며, VPC 내 생성된 서브넷도 VPC의 IP CIDR에서 분할된 IP CIDR를 가지고 있다. 따라서 서브넷에 생성되는 자원은 IP CIDR 범위 안에 IP 주소를 할당받을 수 있다. 위 그림처럼 VPC_A가 10.1.0.0/16의 CIDR로 할당되어 있고, 내부에 Subnet-001~003까지 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24의 IP CIDR로 분리되어 있는 것을 확인할 수 있다.
서브넷 CIDR 블록 크기 조정
AWS에서 서브넷에 허용된 블록 크기는 /16 서브넷 마스크(IP 주소 65,535개) ~ /28 서브넷 마스크(IP 주소 16개)를 지원하고 있다. 각 서브넷 CIDR 블록에서 첫 4개의 IP 주소와 마지막 IP 주소는 사용자가 사용할 수 없으므로 EC2 인스턴스 등의 리소스에 할당할 수 없다. 예를 들어, 10.1.0.0/24 CIDR 블록의 서브넷에서는 다음 5개의 IP 주소가 예약되어 있다. 그러면 해당 서브넷은 251(256 - 5)개의 IP를 사용할 수 있다.
- 10.1.0.0: 네트워크 주소
- 10.1.0.1: AWS에서 VPC 라우터용으로 예약한 주소
- 10.1.0.2: DNS 서버의 IP 주소(기본 VPC 네트워크 범위에 2를 더한 주소)
- 10.1.0.3: AWS에서 앞으로 사용하려고 예약한 주소
- 10.1.0.255: 네트워크 브래드캐스트 주소. VPC에서는 브로드캐스트를 지원하지 않으므로, 이 주소를 예약.
가상 라우터(VPC Router)와 라우팅 테이블

VPC Router는 VPC 내부의 가상 라우터(Virtual Rotuer)로, 서브넷의 기본 게이트웨이 주소(10.0.1.0/24 IP CIDR라면 10.0.1.1)가 가상 라우터의 역할을 수행한다. 즉, 모든 서브넷의 트래픽은 외부로 나갈 때 이 IP를 통해 VPC Router에 패킷을 전달하고, VPC 라우터는 라우팅 테이블을 기반으로 다음 홉(예: IGW, 다른 서브넷)으로 전달한다. Amazon VPC 생성 시 자동으로 생성되어 별도로 관리할 필요가 없고, 라우팅 테이블만 관리가 가능하다.
라우팅 테이블은 VPC 라우터에서 트래픽이 어디로 가야할지 알려주는 이정표이다. VPC 생성 시 자동으로 하나의 기본 라우팅 테이블을 제공하고, 다른 라우팅 테이블과 명시적으로 연결되지 않은 모든 서브넷의 라우팅을 제어한다. 별도의 라우팅 테이블을 생성하고, 서브넷과 연결(attach)하여 서브넷마다 라우팅 테이블을 가질 수 있다. 구성요소로 다음과 같다.
- 목적지(Destination): 트래픽을 이동할 대상 IP 주소(대상 CIDR)의 범위
- 타깃(Target): 트래픽을 실제로 보내줄 대상(게이트웽, 네트워크 인터페이스 등)
- 논리적 리소스의 아이디로 표현(예: 인터넷 게이트웨이의 경우 IGW-xxxxxx)
- 타깃 대상에서 로컬은 VPC 내부 간 통신을 의미하며, 특수한 목적을 수행하는 인터넷 게이트웨이나 NAT 게이트 웨이 등을 타깃 대상으로 지정할 수 있다.

0.0.0.0/0은 서브넷 마스크가 0이기 때문에 모든 비트가 호스트 비트이기 때문에 모든 IP와 매칭된다. 하지만, 매칭이 두 개 이상 될 경우에는 가장 명확한 대상으로 보내준다. 예를 들어, 10.0.1.231, 10.0.2.18 등의 IP를 가진 트래픽들이 들어왔다면 가장 매칭이 되는 로컬로 보내준다.
보안 그룹과 NACL
Amazon VPC는 보안 그룹(Security Group)과 NACL(Network Access Control List) 같은 가상의 방화벽(firewall) 기능을 제공하여 서브넷과 생성된 자원에 대한 트래픽을 보호할 수 있다. IP Range(CIDR) 블록, 프로토콜, 포트 번호, 접두사 목록 등을 정의하여 허용(allow)과 거부(deny)를 결정하는 인바운드(inbound)와 아웃바운드(outbound) 보안 규칙을 만들 수 있다.
보안 그룹과 NACL 차이점
보안 그룹과 네트워크 ACL은 송수신 트래픽을 통제한다는 점에서 비슷하지만 다음 차이점이 있다.
트래픽 접근 제어 대상

보안 그룹은 인스턴스와 같은 자원 접근을 제어하며, 하나의 인스턴스에 하나 이상의 보안그룹을 설정할 수 있다. 설정된 인스턴스는 설정한 모든 보안그룹의 규칙을 적용된다. 그리고 위 그림처럼 보안그릅은 VPC 안에서 생성하고 관리한다.
네트워크 ACL은 서브넷 접근을 제어한다. 즉, 인스턴스 단위로 제어 불가능하고, 하나의 서브넷은 하나의 NACL만 연동 가능하지만, 하나의 NACL은 다양한 서브넷에 1:N 관계로 연동이 가능하다.
Stateful과 Stateless

보안 그룹은 이전 상태 정보를 기억하여 다음에 그 상태를 활용하는 스테이트풀(Stateful) 접근 통제를 수행한다. 즉, 인바운드 규칙에 따라 트래픽을 허용한 경우 정보를 기억하고 아웃바운드 규칙에 상관없이 자동으로 접근이 허용된다.
반면, 네트워크 ACL은 이전 상태 정보를 기억하지 않아 다음에 그 상태를 활용하지 않는 스테이트리스(Stateless) 접근 통제를 수행한다. 즉, 인바운드 규칙에 따라 트래픽을 허용했어도 아웃바운드 규칙으로 트래픽 허용 여부를 판단한다. 인바운드 정책과 아웃바운드 정책이 서로 무관하게 동작한다.
보통 클라이언트는 요청 시 포트는 임시 포트(Ephemeral Port)가 할당되는 경우가 많다. 따라서 NACL에서 아웃바운드 규칙은 고정 포트를 하기 보다는 임시 포트와 같은 포트 범위를 허용하는 것이 일반적이다.
- Linux 임시 포트 범위: 32768 ~ 61000
- Windows 임시 포트 범위: 1025 ~ 5000(XP), 49152 ~ 65535(Vista 이상부터)
허용 및 거부 정책

보안 그룹과 네트워크 ACL 모두 정책 테이블을 통해 트래픽 허용 여부를 결정한다.
보안 그룹의 정책 테이블은 허용 규칙만 나열하며 허용 규칙에 해당하지 않으면 자동 거부된다.
네트워크 ACL의 정책 테이블은 허용 규칙과 거부 규칙이 모두 존재하여 규칙 번호가 작은 순서부터 규칙을 순차적으로 확인하고 허용과 거부를 판단한다.
보안 그룹 실습

보안 그룹은 위 그림처럼 로드 밸런서용 보안 그룹을 만들고 EC2용 보안그룹을 만들어 로드 밸런서 보안 그룹에서 오는 모든 트래픽을 허용하도록 하면 로드 밸런서의 IP가 바뀌더라도 수정없이 계속 운영할 수 있다.


ALB(Application Load Balancer)는 불특정 다수에게 요청을 받아야하기 때문에 인바운드 규칙을 0.0.0.0/0 모든 IP에서 HTTP 80번 포트 요청을 받을 수 있도록 설정한다. 그리고 ALB에 생성된 보안 그룹을 적용한다.

ASG(AutoScaling Group)에서 사용하고 있는 보안 그룹은 모든 트래픽을 허용하는데 소스를 demo-alb-sg로 설정하여 해당 보안그룹에서 온 트래픽만 받도록 허용한다.


위 결과처럼 ALB로 직접 요청하는 경우에는 ALB -> 대상 그룹 -> ASG -> EC2로 요청이 잘전달되고, 응답이 오는 것을 확인할 수 있다. 반면, 소스를 ALB의 보안그룹으로 설정했기 때문에 외부에서 요청하는 경우에는 오른쪽 사진처럼 응답을 받을 수 없다.
Amazon VPC와 다른 네트워크 연결
Amazon VPC의 독립된 클라우드 네트워크에서 다른 네트워크와 연결하는 다양한 기능에 대해 알아보자.
인터넷 게이트웨이

인터넷 게이트웨이는 VPC와 외부 인터넷 구간의 논리적인 연결이자 인터넷으로 나가는 관문이 되는 네트워킹 자원이다. Amazon VPC는 외부 인터넷 구간과 연결되지 않은 독립적인 네트워크이기 때문에 외부 인터넷 구간과 연결이 필요하면 인터넷 게이트웨이(igw-xxxxxx)를 통해 외부 인터넷과 통신할 수 있다. IPv4, IPv6 모두 지원하고, IPv4의 경우 NAT 역할도 인터넷 게이트웨이가 한다.
Amazon VPC에서 퍼블릭 서브넷을 구성할 경우 다음과 같은 단계를 수행한다.
- 인터넷 게이트웨이를 생성하고, Amazon VPC에 연결한다.
- 서브넷의 라우팅 테이블에서 타깃 대상을 인터넷 게이트웨이로 지정한다.
위처럼 구성하면 외부 인터넷에서 퍼블릭 서브넷의 EC2에 접근할 때 무조건 인터넷 게이트웨이를 거치게 된다. 반대로 서브넷의 EC2에서 외부로 나가기 전 VPC Router에서 라우팅 테이블을 통해 IP CIDR를 비교하고, 가장 매칭이 되는 것이 인터넷 게이트웨이인 경우에 인터넷 게이트웨이를 통해 외부 네트워크로 트래픽을 전달한다.
프라이빗 서브넷에 있는 EC2는 외부 인터넷으로 오가는 경로가 없기 때문에 VPC Router를 통해 같은 VPC 내 내부 리소스들만 접근할 수 있다.
NAT 게이트웨이

NAT 게이트웨이(Network Address Translation Gateway)는 외부 인터넷 구간과 단절된 독립된 프라이빗 서브넷에서 외부 인터넷으로 통신하는 관문 역할을 한다. NAT은 IP 주소를 변환하는 기능을 제공하며, 프라이빗 IP 주소를 퍼블릭 IP 주소로 변환하여 외부 인터넷 구간 통신 환경을 만든다.
위 그림처럼 Private Subnet에 있는 EC2 인스턴스가 NAT Gateway를 통해 외부로 통신하려면, Private Subnet의 라우팅 테이블에 0.0.0.0/0 경로의 Target으로 NAT Gateway를 설정해야 한다. 그러면 Private Subnet(Subnet-002)의 EC2 인스턴스가 외부 인터넷으로 요청하면 NAT Gateway가 Public Subnet(Subnet-001)에서 인터넷 게이트웨이를 통해 인터넷으로 요청을 전달한다. 외부 인터넷에서 응답이 올 때는 반대로 인터넷 게이트웨이 -> NAT Gateway -> Private Subnet으로 트래픽을 전달한다.
출처
[CloudNet@와 함께하는 AWS 네트워킹 입문] 보안 그룹과 네트워크 ACL
'기타 > AWS' 카테고리의 다른 글
| Terraform (1) | 2025.08.15 |
|---|---|
| K8S - 서비스 API 카테고리 (1) | 2025.07.24 |
| AWS CloudFormation으로 EKS 클러스터 생성 (2) | 2025.07.22 |
| EKS 기본 아키텍처 (2) | 2025.07.17 |
| Amazon ELB (0) | 2025.07.08 |
- Total
- Today
- Yesterday
- Redisson
- EKS
- mysql
- sql
- Synchronized
- TDD
- annotation
- Kafka
- 낙관적 락
- 분산 락
- 람다
- transaction
- 카프카
- spring webflux
- pessimistic lock
- 구름톤 챌린지
- 구름톤챌린지
- nginx
- 넥스트스탭
- nginx configuration
- redis session
- Java
- 트랜잭션
- socket
- 비관적 락
- NeXTSTEP
- jvm 메모리 구조
- mdcfilter
- postgresql
- spring session
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
