VPC

CIDR은 Classless Inter-Domain Routing의 약자로, IP 주소를 더 유연하고 효율적으로 할당하고 표현하는 방법입니다.

CIDR 개념

IP 주소와 네트워크 마스크를 / 뒤에 숫자로 표시
예: 192.168.1.0/24
- 여기서 /24는 네트워크 부분이 24비트임을 의미
- 즉, 255.255.255.0 서브넷 마스크와 동일
CIDR 표기법으로 IP 주소 블록(네트워크 범위)를 간단히 표현할 수 있어요.

CIDR 구성

IP 주소: IPv4 주소, 예) 192.168.0.0
프리픽스 길이: / 뒤 숫자, 네트워크 부분 비트 수
호스트 주소 부분: 나머지 비트, 네트워크 내 개별 장비 주소 지정

예시

CIDR네트워크 마스크호스트 수(대략)설명

192.168.1.0/24	255.255.255.0	256 (254 usable)	한 서브넷에 254개 장비 가능
10.0.0.0/16	255.255.0.0	65,536	대규모 네트워크 블록
172.16.0.0/12	255.240.0.0	약 1백만	중형 네트워크
0.0.0.0/0	-	전체 인터넷 주소 범위	모든 IP 주소 의미 (기본 라우트)

CIDR의 장점

IP 주소 낭비 감소
유연한 서브네팅 및 라우팅 정책 수립 가능
라우팅 테이블 크기 감소 (aggregated route 지원)

Public IP vs Private IP

구분 Public IP Private IP

정의	인터넷 상에서 유일하게 할당된 IP 주소	사설 네트워크 내에서만 사용되는 IP 주소
접근성	전 세계 어디서나 인터넷을 통해 접근 가능	같은 사설 네트워크나 VPN을 통해서만 접근 가능
범위	인터넷 서비스 제공자(ISP)나 클라우드에서 할당됨	다음 세 가지 범위 내에서 할당됨: - 10.0.0.0 – 10.255.255.255 - 172.16.0.0 – 172.31.255.255 - 192.168.0.0 – 192.168.255.255
용도	웹서버, 퍼블릭 API, 라우터 등 인터넷 서비스 제공	내부 네트워크 장비, 사내 서버, 프린터 등 내부 자원 연결
예시	52.14.72.123, 8.8.8.8	192.168.1.10, 10.0.0.5
비용	일반적으로 ISP나 클라우드 사업자가 관리 및 비용 발생	무료, 네트워크 내부에서 자유롭게 사용 가능
보안	인터넷에 직접 노출돼 공격 위험 있음	외부에 직접 노출되지 않아 상대적으로 안전

추가 설명

Private IP는 NAT(Network Address Translation) 장비(예: 라우터, 인터넷 게이트웨이)를 통해 Public IP와 통신 가능
AWS 같은 클라우드 환경에서는 VPC 내에서 Private IP를 사용하고, 인터넷 접근이 필요하면 Elastic IP(Public IP)를 할당함

AWS에서 VPC(Virtual Private Cloud)는 가상 네트워크 공간을 만들어 AWS 리소스(EC2, RDS 등)를 안전하게 격리하고 운영할 수 있게 해주는 서비스입니다.

VPC란?

AWS 클라우드 내 사용자 전용 논리적 격리 네트워크
IP 주소 범위(CIDR)를 지정해 서브넷을 나누고, 라우팅, 게이트웨이, 보안 설정 가능
온프레미스 데이터센터와 연결하거나 인터넷과 통신하도록 설계 가능

VPC 주요 구성 요소

구성 요소설명

CIDR 블록	VPC에 할당된 IP 주소 범위 (예: 10.0.0.0/16)
서브넷	VPC 내 IP 주소를 더 작은 네트워크 단위로 분할
인터넷 게이트웨이 (IGW)	VPC와 인터넷 간 양방향 통신을 위한 게이트웨이
NAT 게이트웨이	Private 서브넷의 리소스가 인터넷에 나갈 수 있게 하는 서비스
라우팅 테이블	네트워크 트래픽의 경로를 지정
보안 그룹	인스턴스 수준에서 들어오고 나가는 트래픽 제어
네트워크 ACL	서브넷 수준에서 트래픽을 제어하는 방화벽
VPC 피어링	서로 다른 VPC 간의 네트워크 연결

VPC 종류

퍼블릭 서브넷: 인터넷 게이트웨이가 연결되어 있어 인터넷 접근 가능
프라이빗 서브넷: 인터넷에 직접 노출되지 않고, NAT 게이트웨이를 통해서만 인터넷 접근 가능

VPC 활용 예

웹 서버는 퍼블릭 서브넷에 배치
데이터베이스는 프라이빗 서브넷에 배치해 보안 강화
온프레미스와 VPN 연결해 하이브리드 클라우드 구성

AWS VPC에서 예약하는 5개의 IP 주소

IP 주소 예시 (10.0.0.0/24 기준)용도

10.0.0.0	네트워크 주소 (네트워크 자체 식별용)
10.0.0.1	VPC 라우터용 (AWS 내부 관리)
10.0.0.2	Amazon-provided DNS (예: 내부 DNS 해석용)
10.0.0.3	AWS 예약 (미래 확장용)
10.0.0.255	브로드캐스트 주소 (VPC는 브로드캐스트 미지원하여 예약됨)

서브넷 크기와 사용 가능한 IP 수 계산법

서브넷 크기(CIDR)전체 IP 개수예약 IP 개수실제 사용 가능한 IP 개수

/27	32	5	27
/26	64	5	59

예시: EC2 인스턴스 29대를 배치하고 싶을 때

/27 (32 IP) → 32 - 5 = 27 IP 할당 가능 → 29개 인스턴스는 불가능
/26 (64 IP) → 64 - 5 = 59 IP 할당 가능 → 29개 인스턴스 충분히 가능

요약

AWS VPC에서는 항상 각 서브넷당 5개의 IP 주소를 예약하여 할당 불가
인스턴스 수에 맞춰 서브넷 크기를 적절히 선택해야 함
필요한 IP 수보다 충분히 여유 있게 서브넷 CIDR 설계 권장

AWS에서 **Internet Gateway (IGW)**는 VPC를 인터넷과 연결해 주는 핵심 네트워크 컴포넌트입니다.

Internet Gateway란?

역할:
- VPC 내 리소스가 인터넷으로 나가고, 인터넷에서 VPC 내 퍼블릭 IP가 할당된 리소스로 들어오는 트래픽을 가능하게 함
특징:
- 완전관리형, AWS가 제공하는 서비스
- 하나의 VPC당 최대 1개의 IGW 연결 가능
- 가용 영역(AZ) 구분 없이 VPC 전체에 적용됨

Internet Gateway 주요 기능

기능설명

양방향 통신 지원	인터넷과 VPC 간 트래픽 송수신 가능
퍼블릭 IP와 연결	퍼블릭 서브넷 내 퍼블릭 IP 가진 리소스가 인터넷과 통신 가능
NAT와는 다름	NAT는 프라이빗 서브넷의 아웃바운드 인터넷 접근 지원 (인바운드는 불가)

Internet Gateway 연결 및 라우팅

퍼블릭 서브넷의 라우팅 테이블에 IGW를 대상으로 하는 경로(예: 0.0.0.0/0 → igw-xxxxxxxx)가 있어야 인터넷 접근 가능
IGW는 VPC의 인터넷 출입구 역할을 하며, NAT 게이트웨이와는 다르게 퍼블릭 IP가 있어야 외부에서 직접 접근 가능

퍼블릭 서브넷 예시

VPC CIDR: 10.0.0.0/16
퍼블릭 서브넷: 10.0.1.0/24 (IGW 라우팅 포함)
프라이빗 서브넷: 10.0.2.0/24 (NAT 게이트웨이 통해 인터넷 접근)

AWS Bastion Host는 VPC 내부의 프라이빗 서브넷에 있는 인스턴스에 보안적으로 접근하기 위해 퍼블릭 서브넷에 배치하는 중간 관문 서버입니다.
쉽게 말해, 인터넷 → Bastion Host → Private 서버 이렇게 들어가는 안전한 경유지입니다.

1. 개념

위치: 퍼블릭 서브넷 (인터넷 게이트웨이 통해 접근 가능)
역할: Private Subnet의 EC2, DB 등 외부에서 직접 접근 불가한 리소스에 SSH/RDP 연결 제공
접속 방식:
1. 사용자는 Bastion Host로 먼저 접속
2. Bastion Host에서 Private Subnet 인스턴스로 내부 네트워크를 통해 접속

2. 특징

항목 설명

보안 강화	외부에서 Private Subnet 직접 접근 차단
단일 진입점	관리자가 들어오는 경로를 한 곳으로 집중
접근 제어	보안 그룹 & 네트워크 ACL로 접속 IP 제한
로깅	세션 로깅, MFA 적용 가능
임시 사용 가능	필요 시 생성 후 종료하여 보안 유지

3. 구성 예시

[Internet]
   │ SSH/RDP
[Internet Gateway]
   │
[Public Subnet] → Bastion Host (EC2, Public IP)
   │ Internal Network
[Private Subnet] → App Server, DB Server

퍼블릭 서브넷: Bastion Host (EC2 + Public IP)
프라이빗 서브넷: 앱 서버, DB (Private IP만 있음)
라우팅: 퍼블릭 서브넷은 IGW, 프라이빗 서브넷은 NAT Gateway 또는 없음

4. AWS에서 Bastion Host 보안 모범 사례

SSH 포트(22) 제한
- 관리자 고정 IP만 허용
프라이빗 서버 보안 그룹 제한
- Bastion Host SG만 허용
IAM + MFA 적용
세션 로깅 (CloudWatch Logs, SSM Session Manager 활용)
필요 시만 운영 (임시 Bastion Host 생성 → 작업 완료 후 삭제)

5. Bastion Host 대안

AWS Systems Manager – Session Manager
- SSH 포트 개방 없이 EC2에 접속 가능
- Bastion Host 불필요
- CloudTrail/CloudWatch를 통한 완전한 세션 로깅

NAT Instance는 AWS에서 프라이빗 서브넷에 있는 리소스들이 아웃바운드로만 인터넷에 접근할 수 있도록 해주는 EC2 기반 NAT 서버입니다.
쉽게 말해, “프라이빗 서버가 인터넷으로 나가는 우체국” 역할을 하는 EC2 인스턴스입니다.

1. 개념

NAT = Network Address Translation
NAT Instance = AWS에서 EC2를 직접 구성해 NAT 기능을 수행하도록 만든 것
사용 목적: 프라이빗 서브넷에 있는 서버들이 보안상 직접 인터넷과 통신하지 않고, NAT Instance를 통해 패키지 업데이트나 API 호출 등을 하도록 함
인바운드 트래픽 차단: 인터넷 → 프라이빗 서버 직접 접근 불가
아웃바운드 트래픽 허용: 프라이빗 서버 → 인터넷 가능

2. 구성 예시

[Private Subnet] App Server → (Private IP)
   │
   │ 내부 라우팅
   ▼
[Public Subnet] NAT Instance (EC2, Public IP)
   │
   ▼
[Internet Gateway] → 인터넷

Private Subnet: App/DB 서버, Public IP 없음
Public Subnet: NAT Instance (EC2), Public IP 있음
라우팅: 프라이빗 서브넷 라우팅 테이블의 0.0.0.0/0 → NAT Instance 지정

3. NAT Instance 특징

항목 설명

EC2 기반	직접 생성/관리해야 함
보안 그룹	아웃바운드만 허용, 인바운드는 내부 요청에 대한 응답만
대역폭 제한	EC2 인스턴스 타입에 따라 성능 달라짐
확장성 부족	수동으로 스케일 업/아웃 필요
고가용성 직접 구성	멀티 AZ 장애 대비를 직접 설정해야 함

4. NAT Instance 보안 설정 모범 사례

소스/대상 체크 비활성화
- NAT Instance는 다른 인스턴스의 트래픽을 전달하므로 Source/Destination Check를 꺼야 함
보안 그룹
- 인바운드: 프라이빗 서브넷 IP 범위만 허용
- 아웃바운드: 모든 트래픽 허용(필요에 따라 제한 가능)
OS 업데이트 주기적으로 (보안 패치 필수)

5. NAT Instance vs NAT Gateway

비교 항목 NAT Instance NAT Gateway

관리 방식	수동 (EC2 관리 필요)	완전 관리형 (AWS 관리)
성능	EC2 타입에 의존	최대 45Gbps, 자동 스케일
가용성	직접 HA 구성	AZ 내 자동 가용성
비용	EC2 요금 + 데이터 전송료	시간당 요금 + 데이터 전송료
보안	보안 그룹, NACL 직접 구성	NACL로만 제한 가능

📌 정리:

NAT Instance는 유연성이 있지만 관리 부담이 크고, 성능/확장성에서 한계가 있습니다.
AWS 모범 사례에서는 현재 대부분 NAT Gateway를 권장합니다.
하지만 특수한 커스터마이징(예: 트래픽 로깅, 특정 방화벽 룰 적용)이 필요하면 NAT Instance를 씁니다.

NAT Gateway는 AWS에서 제공하는 완전 관리형(Managed) NAT 서비스로,
프라이빗 서브넷에 있는 리소스들이 아웃바운드로만 인터넷에 접근할 수 있도록 해주는 서비스입니다.
즉, **“운영자가 직접 EC2로 NAT를 만들 필요 없는 자동 확장형 인터넷 출구”**라고 생각하면 됩니다.

1. 개념

NAT = Network Address Translation
NAT Gateway = AWS에서 관리하는 NAT 장치 (서버가 아님)
주요 역할:
- 프라이빗 서브넷 → 인터넷(아웃바운드) 허용
- 인터넷 → 프라이빗 서브넷(인바운드) 차단
확장/성능 관리 필요 없음 — AWS가 자동으로 처리

2. 구성 예시

[Private Subnet] App Server → (Private IP)
   │
   │ 내부 라우팅
   ▼
[Public Subnet] NAT Gateway (Public IP)
   │
   ▼
[Internet Gateway] → 인터넷

Private Subnet: App/DB 서버, Public IP 없음
Public Subnet: NAT Gateway, Elastic IP 할당
라우팅: 프라이빗 서브넷의 0.0.0.0/0 → NAT Gateway로 설정

3. NAT Gateway 특징

항목 설명

관리형 서비스	인스턴스 운영/패치 불필요
고성능	최대 45Gbps, 자동 확장
고가용성	AZ 내 자동 가용성
AZ별 배포 필요	멀티 AZ 구성 시 각 AZ에 NAT Gateway 생성
Elastic IP 필요	퍼블릭 NAT Gateway의 경우 필수
과금 방식	시간당 요금 + 데이터 처리량 요금

4. NAT Gateway 종류

종류설명

Public NAT Gateway	퍼블릭 서브넷에 위치, Elastic IP 사용, 인터넷으로 나가는 트래픽 처리
Private NAT Gateway	VPC 내부 전용 통신용 (인터넷 X), 다른 VPC나 온프레미스로의 트래픽 처리

5. NAT Instance vs NAT Gateway 비교

항목 NAT Instance NAT Gateway

관리 방식	직접 관리(EC2)	완전 관리형
성능	인스턴스 타입 의존	최대 45Gbps, 자동 확장
가용성	직접 구성	AZ 내 자동
보안 그룹 사용	가능	불가능(NACL만 적용)
커스터마이징	가능	제한적
비용	EC2 요금 + 데이터 요금	시간당 요금 + 데이터 요금

6. 사용 시 주의 사항

AZ 마다 하나씩 배치: NAT Gateway는 AZ에 종속적 → 다른 AZ의 NAT Gateway로 라우팅 불가
비용 고려: 소규모 트래픽에서는 NAT Instance가 더 저렴할 수 있음
Egress 전용: 인바운드 연결 불가능 (프라이빗 서버에 직접 접근 불가)
라우팅 테이블: 프라이빗 서브넷의 0.0.0.0/0을 NAT Gateway로 지정해야 함

📌 정리:

성능과 안정성이 중요하면 NAT Gateway
저비용·커스터마이징이 필요하면 NAT Instance
AWS 권장: 대부분의 경우 NAT Gateway 사용

AWS에서 Security Group과 **Network ACL(NACL)**은 모두 **네트워크 접근 제어(Access Control)**를 위한 도구지만,
적용 범위·방식·상태 유지 여부에서 큰 차이가 있습니다.

1. Security Groups (SG)

인스턴스 단위 방화벽 — EC2, RDS, Lambda ENI 등 개별 리소스에 직접 적용

상태 저장(Stateful): 인바운드 허용 시, 해당 연결의 아웃바운드는 자동 허용
허용 규칙만 설정 가능: Deny 불가능 (암묵적으로 나머지는 거부)
대상: 인스턴스(ENI) 수준
규칙: IP, CIDR, 다른 SG 참조 가능
동적 변경: 규칙 변경 시 즉시 적용

예시:

웹 서버 인스턴스: Inbound: 80/443 from 0.0.0.0/0, Outbound: All
DB 서버 인스턴스: Inbound: 3306 from WebServerSG, Outbound: All

2. Network ACL (NACL)

서브넷 단위 방화벽 — VPC 서브넷 레벨에서 트래픽 필터링

상태 비저장(Stateless): 인바운드 허용 시, 아웃바운드도 별도로 허용해야 함
허용(Allow) + 거부(Deny) 규칙 모두 가능
규칙 순서 존재: 번호 낮은 규칙부터 평가
적용 범위: 서브넷 전체에 적용
용도: 서브넷 차원에서 블랙리스트/화이트리스트 설정

예시:

Public Subnet NACL: Inbound Allow 80/443 from 0.0.0.0/0, Deny 22 from 0.0.0.0/0
Private Subnet NACL: Inbound Allow 3306 from 10.0.0.0/16

3. 비교 표

항목 Security Group NACL

적용 범위	ENI(인스턴스) 단위	서브넷 단위
상태 저장 여부	Stateful	Stateless
허용/거부	Allow만	Allow & Deny
평가 순서	모든 규칙 평가, 매칭 시 허용	규칙 번호 순서대로 평가
기본 동작	모든 인바운드 차단, 아웃바운드 허용	모든 인바운드/아웃바운드 허용
주요 사용 사례	인스턴스별 접근 제어	서브넷 단위 트래픽 필터링, 거부 규칙 필요할 때

4. AWS 권장 사용 패턴

SG: 세밀한 인스턴스 레벨 접근 제어 (화이트리스트 방식)
NACL: 서브넷 레벨에서 추가적인 보안 계층 (특히 Deny 규칙 필요 시)
조합 사용 예시:
- Public Subnet: NACL로 기본 포트 차단 + SG로 세부 인스턴스 접근 제어
- Private Subnet: NACL로 외부 접근 전면 차단, SG로 내부 서비스 연결 허용

📌 비유로 기억하기

Security Group → "아파트 현관문" (세대별)
NACL → "아파트 단지 입구 경비" (단지 전체)

AWS의 Default NACL은 VPC 생성 시 자동으로 만들어지는 기본 서브넷 네트워크 접근 제어 목록입니다.
특징은 **"모든 트래픽 허용"**이라는 점입니다.

1. Default NACL의 기본 규칙

인바운드 규칙: Rule #100 → Allow 0.0.0.0/0, All ports
아웃바운드 규칙: Rule #100 → Allow 0.0.0.0/0, All ports
즉, 모든 인바운드/아웃바운드 트래픽 허용
거부(Deny) 규칙 없음

2. 특징

항목 설명

자동 생성	VPC 생성 시 Default NACL도 함께 생성
서브넷 자동 연결	새로 만든 서브넷은 기본적으로 Default NACL과 연결됨
모든 트래픽 허용	Allow all inbound/outbound
수정 가능	규칙 변경 가능 (단, 삭제 불가)
Stateless	상태 비저장 → 인바운드/아웃바운드 각각 설정해야 함

3. 변경 시 주의점

Default NACL을 수정해서 Deny 규칙 추가 가능하지만, 서브넷 전체 트래픽에 영향을 주므로 신중해야 함.
Default NACL이 아닌 Custom NACL을 만들어 적용하는 게 더 안전.
잘못 설정하면 해당 서브넷의 인스턴스가 외부와 통신 불가 상태가 될 수 있음.

4. 시험/면접 포인트

Default NACL = 모든 트래픽 허용
NACL은 Stateless, SG는 Stateful
새 서브넷 → 자동으로 Default NACL 연결

Ephemeral Ports는 네트워크 통신에서 클라이언트가 서버와 연결할 때 일시적으로 사용하는 임시 포트 번호를 말합니다.
주로 응답(Reply) 트래픽을 받을 때 사용됩니다.

1. 왜 필요한가?

서버는 서비스 포트를 고정(예: HTTP 80, HTTPS 443)
클라이언트가 서버에 요청을 보낼 때,
- **출발지 포트(Source Port)**는 임시로 선택 (Ephemeral Port)
- 응답은 같은 포트로 돌아옴
여러 연결을 동시에 할 수 있도록 각 연결마다 고유한 포트를 부여

2. 일반적인 범위

운영체제별 기본 Ephemeral Port 범위:

OS 범위 개수

Linux (기본)	32768–60999	28232
Windows Server 2008+	49152–65535	16384
AWS Security Group/NACL 예시	1024–65535	64512

AWS에서 NACL 구성 시 Ephemeral Port 범위를 허용해야 외부 서버 응답을 받을 수 있습니다.
예: 인바운드 규칙에서 1024–65535 허용.

3. 통신 예시

클라이언트(출발지 포트 51000) → 서버(목적지 포트 443)
서버(출발지 포트 443) → 클라이언트(목적지 포트 51000)
여기서 51000이 Ephemeral Port

4. AWS에서의 실무 포인트

NACL은 Stateless이므로,
- 아웃바운드 요청이 80/443 포트로 나갔다면,
- 인바운드에서 Ephemeral Port 범위를 허용해야 응답 가능.
Security Group은 Stateful이라 별도 허용 필요 없음.

📌 시험/면접 포인트

Ephemeral Port는 클라이언트 측 임시 포트
NACL은 반드시 Ephemeral Port 범위도 허용해야 함
범위 OS마다 다르지만, AWS 예시로는 1024–65535가 자주 사용됨

Security Group vs NACL

특징 Security Group (SG) Network ACL (NACL)

적용 범위	EC2 인스턴스 레벨	Subnet 레벨
상태(State)	Stateful Inbound 허용 시 Outbound 자동 허용	Stateless Inbound/Outbound 각각 규칙 작성 필요
기본 동작	모든 트래픽 거부 후, 명시적으로 허용만 설정	모든 트래픽 허용(Default NACL) 또는 거부(Custom NACL)
규칙 방향	Inbound / Outbound 구분	Inbound / Outbound 구분
허용/거부	허용만 가능 (DENY 불가)	허용(ALLOW) / 거부(DENY) 모두 가능
평가 순서	모든 규칙 평가 후 허용/거부 결정	Rule Number 순서대로 평가, 첫 매칭 규칙이 적용
포트 범위	지정 가능, Ephemeral Port 자동 처리	Ephemeral Port 직접 허용 필요
사용 목적	인스턴스별 접근 제어	Subnet 전체 접근 제어
적용 개수	인스턴스당 여러 SG 적용 가능	서브넷당 하나의 NACL만 적용 가능

쉽게 이해하는 차이점

SG = 인스턴스의 "보안문" (Stateful → 들어왔으면 나갈 때 자동 허용)
NACL = 서브넷 입구의 "검문소" (Stateless → 들어올 때, 나갈 때 각각 검사)

실무 적용 패턴

NACL → Subnet 단위의 기본 보안 경계
예: 인터넷에서 DB Subnet 접근 차단
SG → 인스턴스 단위의 세부 접근 제어
예: Web 서버는 80/443 허용, DB 서버는 3306만 허용

VPC Peering은 두 개의 VPC 간에 프라이빗 네트워크 트래픽을 주고받을 수 있도록 연결하는 AWS 네트워크 기능입니다.
쉽게 말해, 서로 다른 VPC를 마치 한 네트워크처럼 연결하는 거예요.

VPC Peering 특징

양방향 통신 가능 (Private IP 기반)
서로 다른 계정, 리전 간에도 연결 가능 (단, 지원 여부 확인)
인터넷 게이트웨이, VPN, Direct Connect 필요 없음
중앙 허브 역할 불가 → Peering은 Point-to-Point라서 Transit Gateway처럼 다중 VPC 간 자동 라우팅은 안 됨
보안 그룹 규칙에서 피어 VPC CIDR 범위를 참조 가능

작동 방식

VPC A에서 VPC B로 Peering 연결 요청
VPC B에서 승인
각 VPC의 Route Table에 상대방 VPC CIDR 추가
SG/NACL에서 허용 규칙 설정

구성 예시

VPC-A (10.0.0.0/16) <-- Peering --> VPC-B (192.168.0.0/16)

VPC-A의 EC2가 192.168.x.x로 접근 가능
VPC-B의 EC2가 10.x.x.x로 접근 가능

제한 사항

전이적(Transitive) 라우팅 불가
예: A-B, B-C 피어링이 있어도 A → C 직접 통신 안 됨
중복 CIDR 불가
IPv4/IPv6 둘 다 가능하지만 각각 설정 필요
Peering 연결에는 대역폭 제한이 없지만, VPC 엔드포인트 서비스, NAT, 인터넷 게이트웨이 트래픽은 통과 불가

실무 팁

다수의 VPC를 연결해야 하면 Transit Gateway 고려
다른 계정과 Peering 시 IAM 권한 필요
라우팅 테이블, SG, NACL 모두 확인해야 정상 통신 가능

VPC Endpoints (AWS PrivateLink) 핵심 요약

AWS 서비스는 기본적으로 퍼블릭 인터넷에 노출되어 있음
- 모든 서비스는 공용 URL로 접근 가능
VPC Endpoints (AWS PrivateLink)
- 퍼블릭 인터넷이 아닌 프라이빗 네트워크를 통해 AWS 서비스에 연결 가능
- 서비스와 VPC 간 직접 연결(ENI 기반) 제공
- NAT Gateway, Internet Gateway 없이도 AWS 서비스 접속 가능
특징
- 수평적 확장(horizontal scaling) 및 중복성(redundancy) 내장
- 안정적이고 고가용성 보장
문제 발생 시 점검 사항
- VPC의 DNS 설정 (DNS Resolution) 확인
- 관련 서브넷의 라우팅 테이블(Route Table) 설정 확인

AWS VPC Endpoint 유형

1. Interface Endpoint (AWS PrivateLink 기반)

VPC 내 특정 서브넷에 ENI(Elastic Network Interface, 사설 IP) 생성
ENI가 AWS 서비스 접속용 프라이빗 엔드포인트 역할
반드시 Security Group 연결 필요 → 트래픽 제어 가능
대부분의 AWS 서비스 지원 (Lambda, SNS, Kinesis 등)
비용 발생: 시간당 요금 + 데이터 처리량 GB당 요금

2. Gateway Endpoint

VPC 라우팅 테이블에 대상 서비스용 게이트웨이 생성
라우팅 테이블에 경로 추가하여 서비스 접속
보안 그룹 적용 불가 (라우팅 기반 접근)
지원 서비스 제한적: S3, DynamoDB 전용
무료 제공 (사용량, 시간과 무관)

한눈에 비교

구분 Interface Endpoint Gateway Endpoint

리소스 유형	ENI (사설 IP)	라우팅 게이트웨이
보안 그룹 사용	가능	불가능
지원 서비스	대부분 AWS 서비스	S3, DynamoDB
비용	시간+데이터 처리량 요금 발생	무료
라우팅 방식	ENI 직접 연결	라우팅 테이블에 경로 추가

Gateway Endpoint vs Interface Endpoint for S3

구분Gateway EndpointInterface Endpoint

주 사용처	대부분의 경우, S3 접근에 기본적으로 권장	온프레미스 네트워크(Site-to-Site VPN, Direct Connect), 다른 VPC 또는 리전에서 접근할 때 선호
비용	무료	시간 및 데이터 처리량에 따른 비용 발생
구성 방식	라우팅 테이블에 게이트웨이 추가	VPC 내 서브넷에 ENI(프라이빗 IP) 생성 및 SG 적용 필요
지원 환경	동일 VPC 내 또는 Peering된 VPC 내에서 효율적	온프레미스, 멀티 VPC, 멀티 리전 등 복잡한 네트워크 환경에서 유용
보안 그룹 적용 여부	불가	가능 (보안 그룹으로 세밀한 트래픽 제어 가능)

결론

시험 문제에서는 S3에는 Gateway Endpoint가 기본 정답인 경우가 많음
복잡한 네트워크 환경(다른 VPC, 온프레미스, 리전 간)에서는 Interface Endpoint 사용 권장

VPC Flow Logs 개요

VPC Flow Logs는 VPC 내 네트워크 인터페이스(ENI)를 통해 오가는 IP 트래픽 정보를 캡처하는 기능입니다.
트래픽 흐름을 기록하여 모니터링, 보안 감사, 문제 해결에 도움을 줌

종류

대상 설명

VPC Flow Logs	VPC 전체 수준에서 트래픽 캡처
Subnet Flow Logs	특정 서브넷 단위에서 캡처
ENI Flow Logs	특정 ENI(네트워크 인터페이스) 수준에서 캡처

주요 기능 및 활용

AWS 관리형 인터페이스 트래픽도 캡처 가능
- 예: ELB, RDS, ElastiCache, Redshift, WorkSpaces, NAT Gateway, Transit Gateway 등
트래픽 흐름 데이터를 아래로 전송 가능:
- Amazon S3 (장기 저장)
- Amazon CloudWatch Logs (실시간 모니터링)
- Amazon Kinesis Data Firehose (분석, 처리 파이프라인)
문제 해결 및 보안 분석에 필수적인 데이터 제공
- 연결 실패 원인, 비정상 트래픽 탐지, 규칙 위반 등
Flow Log 데이터 항목 (예시)

필드 설명

version	로그 형식 버전
srcaddr	출발지 IP 주소
dstaddr	목적지 IP 주소
srcport	출발지 포트
dstport	목적지 포트
protocol	프로토콜 (TCP, UDP 등)
packets	패킷 수
bytes	바이트 수
action	ACCEPT or REJECT
log-status	성공/오류 상태

AWS Site-to-Site VPN – 주요 구성 요소

1. Virtual Private Gateway (VGW)

역할: AWS 쪽 VPN 집중 장치(VPN concentrator) 역할을 함.
위치: VPN 연결을 만들고 싶은 VPC에 생성하여 연결.
라우팅: 고객 게이트웨이(CGW)에서 들어오는 암호화된 트래픽을 해제하고 VPC 내부로 라우팅.
ASN(Autonomous System Number) 설정 가능:
- VGW 생성 시 BGP용 ASN을 직접 지정 가능.
- 온프레미스 쪽 BGP ASN과 충돌을 피하거나, 특정 라우팅 설계를 위해 사용.

2. Customer Gateway (CGW)

역할: 온프레미스 측 VPN 종단 장치.
형태:
- 하드웨어 장치 (라우터, 방화벽 등)
- 또는 소프트웨어 기반 VPN 애플리케이션 (데이터센터나 사무실 서버에 설치)
공인 IP 필요: AWS와 연결하려면 정적(Static)이고 라우팅 가능한 공인 IP 주소가 있어야 함.
설정:
- AWS에서 기기별 VPN 설정 파일을 제공.
- AWS 지원 VPN 장치 목록 참고 가능.

✅ 구성 흐름

VGW: AWS에서 관리, VPC 내부에 존재.
CGW: 사용자가 소유, 온프레미스에 위치.
둘 사이를 IPsec 기반 2개의 터널로 연결 (고가용성).
라우팅은 BGP(동적 라우팅) 또는 정적 라우팅 중 선택 가능.

AWS Site-to-Site VPN Connections – 핵심 사항

1. Customer Gateway Device (온프레미스 VPN 장치)

IP 주소 선택
- 공인(Internet-routable) IP 주소를 사용해야 함.
- 만약 VPN 장치가 NAT 장치 뒤에 위치하고, NAT Traversal(NAT-T)이 활성화되어 있다면
  → NAT 장치의 공인 IP 주소를 사용.

2. 라우트 전파(Route Propagation) 활성화

왜 필요한가?
- Virtual Private Gateway(VGW)에서 받은 라우팅 정보를 VPC 라우트 테이블에 자동으로 반영하기 위해.
설정 방법
- VGW와 연결된 서브넷의 라우트 테이블에서 Route Propagation 옵션을 활성화.

3. 온프레미스에서 EC2 인스턴스 핑(Ping) 테스트

ICMP 프로토콜 허용 필요:
- EC2 보안 그룹(SG) 인바운드 규칙에 ICMP (Echo Request) 허용 추가.
- 예: Type: All ICMP - IPv4, Source: 온프레미스 IP 또는 CIDR.

✅ 정리

CGW IP 주소: 공인 IP 또는 NAT-T 사용 시 NAT 장치의 공인 IP.
VGW 쪽: Route Propagation 활성화.
EC2 접근: Security Group에 ICMP 허용.

AWS Site-to-Site VPN – 다중 사이트 연결 특징

1. 여러 지점 간 안전한 통신

여러 VPN 연결을 구성하면 여러 온프레미스 지점 간에 암호화된 안전한 통신 가능.
예: 본사 ↔ AWS ↔ 지사, 데이터센터 간 연동.

2. 저비용 허브-앤-스포크(Hub-and-Spoke) 모델

VGW를 중앙 허브로 사용.
각 지점(스포크)이 VGW에 VPN 연결.
저비용으로 기본(primary) 또는 보조(secondary) 네트워크 연결 구성 가능.
단, VPN이므로 인터넷 경유 → 지연(latency)과 대역폭 제한 고려 필요.

3. 구성 방법

동일한 VGW에 여러 개의 VPN 연결 생성.
동적 라우팅(BGP) 사용해 경로 자동 교환.
각 VPC 라우트 테이블에 적절한 라우팅 규칙 구성.
모든 지점이 서로 통신할 수 있도록 경로 확인 및 보안그룹/네트워크 ACL 조정.

💡 핵심 포인트

VGW = 중앙 허브
각 지점 CGW = 스포크
VPN은 인터넷을 통해 연결되므로 암호화(IPsec) 필수.
고가용성을 위해 다중 터널 + BGP 권장.

AWS Direct Connect (DX)

1. 개념

전용 전용선을 이용해 온프레미스 네트워크 ↔ AWS VPC를 **전용(private)**으로 연결.
인터넷을 거치지 않음 → 더 안정적이고 예측 가능한 네트워크 품질 제공.

2. 연결 방식

고객 데이터센터(DC)와 AWS Direct Connect Location 사이에 전용 회선 구축 필요.
VPC에 Virtual Private Gateway(VGW) 설정.
동일한 연결에서 **퍼블릭 리소스(S3)**와 프라이빗 리소스(EC2) 모두 접근 가능.

3. 주요 활용 사례

대용량 데이터 전송 시 대역폭 증가 & 비용 절감.
(예: 빅데이터 분석, 대규모 백업, 미디어 전송)
실시간 데이터 처리 애플리케이션에 필요한 안정적이고 일관된 네트워크 성능.
하이브리드 환경 구축 (온프레미스 + 클라우드 통합 환경).
IPv4, IPv6 모두 지원.

Direct Connect Gateway (DX Gateway)

필요성

Direct Connect(DX) 연결은 기본적으로 같은 리전의 하나의 VPC에만 직접 연결 가능.
여러 리전의 여러 VPC에 연결하려면 Direct Connect Gateway 필요.

AWS Direct Connect – 연결 유형

1. 전용 연결 (Dedicated Connections)

대역폭: 1 Gbps, 10 Gbps, 100 Gbps.
특징:
- 고객 전용 물리적 이더넷 포트 제공.
- AWS에 먼저 요청 → AWS Direct Connect 파트너와 협력하여 개통.
사용 사례:
- 대규모 트래픽 전송, 안정적이고 장기적인 전용 네트워크 필요 시.

2. 호스팅 연결 (Hosted Connections)

대역폭: 50 Mbps ~ 10 Gbps.
- 일부 AWS Direct Connect 파트너에서는 1, 2, 5, 10 Gbps도 제공.
특징:
- Direct Connect 파트너를 통해 요청.
- 필요 시 용량을 온디맨드로 증감 가능.
- 다중 고객이 동일 물리 포트를 공유(논리적 분할).
사용 사례:
- 초기 비용 절감, 빠른 구축, 변동 트래픽 대응.

3. 구축 기간

일반적으로 1개월 이상 소요될 수 있음(특히 전용 연결).
호스팅 연결은 상대적으로 더 빠르게 구축 가능

AWS Direct Connect – 암호화(Encryption)

1. 기본 상태

Direct Connect는 **전송 중 데이터(data in transit)**를 기본적으로 암호화하지 않음.
전용선이기 때문에 외부 접근 위험은 낮지만, 완전한 보안을 위해 추가 암호화 고려 가능.

2. Direct Connect + VPN 조합

Direct Connect 연결 위에 **Site-to-Site VPN(IPsec)**을 구성하면:
- 암호화된(private + encrypted) 전송 경로 확보.
- 퍼블릭 인터넷이 아닌 DX 회선 위에서 IPsec 터널을 운용.
장점:
- 한 층 더 강화된 보안.
단점:
- 구성 복잡도 증가.
- 약간의 성능 저하(암호화 오버헤드).

💡 정리

DX만 사용 → 전용선 기반, 암호화 없음.
DX + VPN → 전용선 + IPsec 암호화(보안 강화)

1. High Resiliency for Critical Workloads

구성:
- 하나의 리전(Region)에 대해 여러 AWS Direct Connect Location에 각각 연결
2. Maximum Resiliency for Critical Workloads
- 구성:
  - 서로 다른 위치(Location)에 서로 다른 장치에 종단하는 별도의 연결 구축

Direct Connect 장애 대비(백업) 방법

Direct Connect 장애 시 대비책
1. 백업용 Direct Connect 연결 추가 구축 (비용이 많이 듦)
2. 또는 Site-to-Site VPN 연결을 백업 경로로 설정
  - VPN은 인터넷 기반이지만, 장애 시 빠르게 전환 가능
  - 비용 효율적이고 간편한 보완책

💡 정리

중요한 서비스라면 백업 연결은 필수!
비용과 운영 복잡도에 따라 VPN 백업 또는 이중 Direct Connect 선택 가능.

AWS Transit Gateway (TGW)

1. 주요 기능

수천 개의 VPC와 온프레미스 네트워크 간 트랜지티브(경유) 연결 지원.
허브-앤-스포크(Star) 아키텍처 형태로 중앙 집중형 네트워크 구성 가능.

2. 특성

리전 단위 리소스지만,
- 리전 간 피어링(Cross-Region Peering)도 지원해 글로벌 네트워크 구축 가능.
리소스 공유
- AWS Resource Access Manager(RAM)을 통해 크로스 계정 공유 가능.

3. 라우팅 및 연결

라우트 테이블을 사용해
- 어떤 VPC끼리 통신할지 세밀하게 제어 가능.
Direct Connect Gateway, Site-to-Site VPN과 연동 가능.
IP 멀티캐스트 지원 (AWS 내에서 유일한 서비스).

4. 활용 예시

복잡한 멀티 VPC 환경에서 중앙 허브 역할.
온프레미스 및 여러 리전 VPC 간 데이터 흐름 단순화 및 관리 용이.

Transit Gateway – Site-to-Site VPN ECMP (Equal-Cost Multi-Path Routing)

1. ECMP란?

Equal-Cost Multi-Path Routing의 약자.
여러 경로가 동일한 비용(대역폭, 지연시간 등)일 때,
패킷을 복수 경로에 분산하여 전송하는 라우팅 전략.

2. 적용 사례

Transit Gateway에 여러 개의 Site-to-Site VPN 연결을 만들어서
여러 VPN 터널을 통해 패킷을 분산 전송 가능.
이를 통해 VPN 연결 대역폭을 늘리고, 네트워크 효율 및 가용성 향상 가능.

3. 구성

VPC는 Transit Gateway에 붙어있고,
Transit Gateway는 복수의 VPN 연결을 통해 온프레미스(예: 172.16.0.0/16) 네트워크와 연결됨.
Transit Gateway가 ECMP를 사용해 여러 VPN 경로 중 하나를 선택하여 트래픽 분산.

💡 요약

ECMP 덕분에 VPN 연결 하나당 제한된 대역폭 문제를 여러 VPN 연결로 해결 가능.
네트워크 부하 분산 + 장애 시 빠른 대체 경로 확보.

AWS VPC – 트래픽 미러링 (Traffic Mirroring)

1. 개념

VPC 내에서 네트워크 트래픽을 캡처해서 다른 위치로 복제(미러링)하는 기능.
캡처한 트래픽을 보안 장비나 모니터링 시스템으로 보내서 분석 가능.

2. 동작 방식

소스(Source):
- 캡처 대상은 ENI (Elastic Network Interface).
- 인바운드/아웃바운드 트래픽 모두 캡처 가능.
대상(Target):
- 캡처된 트래픽을 받을 ENI 또는 Network Load Balancer (NLB).
소스와 대상은
- 같은 VPC 내에 있거나,
- VPC 피어링된 서로 다른 VPC에 있을 수 있음.

3. 주요 특징

모든 패킷을 캡처하거나, 관심있는 특정 패킷만 선택적으로 캡처 가능(패킷 크기 제한도 설정 가능).
캡처한 트래픽을 통해 다음과 같은 작업 수행:
- 콘텐츠 검사(Content inspection)
- 위협 탐지 및 필터링(Threat detection/filtering)
- 네트워크 모니터링 및 문제 해결 (Troubleshooting)

4. 활용 사례

보안 장비에 트래픽 전달하여 실시간 위협 분석.
네트워크 성능 및 장애 분석.
자동 스케일링 그룹에서 트래픽 상태 모니터링.

ipv6

1. 배경

IPv4는 약 43억 개의 IP 주소를 제공하도록 설계되었으나,
주소 고갈 문제 발생.
IPv6는 IPv4의 후속 프로토콜로 개발됨.

2. 특징

IPv6는 약 3.4 × 10³⁸ (340 언드레딕틸리언) 개의 주소를 제공하여 사실상 무한대에 가까운 주소 공간 확보.
AWS 내 모든 IPv6 주소는 공용(Public)이며, 인터넷 라우팅 가능 (사설 주소 범위 없음).

3. 주소 형식

IPv6 주소는 8개의 16진수(hexa) 세그먼트로 구성됨.
각 세그먼트는 4자리 16진수(0000~ffff)이며, 세그먼트는 콜론(:)으로 구분됨.

예시:

2001:db8:3333:4444:5555:6666:7777:8888
2001:db8:3333:4444:cccc:dddd:eeee:ffff

4. 축약 표기법

연속된 0은 ::로 축약 가능 (한 주소에 한 번만 사용 가능).

예시:

:: → 모든 8개 세그먼트가 0
2001:db8:: → 마지막 6개 세그먼트가 0
::1234:5678 → 처음 6개 세그먼트가 0
2001:db8::1234:5678 → 중간 4개 세그먼트가 0

💡 요약

항목 설명

IPv4 주소 수	약 43억 (고갈 중)
IPv6 주소 수	약 3.4 × 10³⁸ (사실상 무한)
주소 형식	8개의 16진수 세그먼트 (x:x:x:x:x:x:x:x)
주소 축약	연속된 0은 ::로 표현 가능

AWS VPC에서의 IPv6

1. IPv6 활성화

IPv4 cannot be disabled for your VPC and subnets

VPC에서 IPv6를 활성화할 수 있음.
활성화 시 **공용 IP 주소(public IPv6 주소)**가 할당됨.
IPv4와 IPv6를 동시에 사용하는 듀얼 스택(Dual-Stack) 모드 운영 가능.

2. 인스턴스 네트워크 구성

EC2 인스턴스는 최소한
- 사설 IPv4 주소(private IPv4)
- 공용 IPv6 주소(public IPv6)
  둘 다 할당받음.

3. 인터넷 연결

인스턴스는 IPv4 또는 IPv6 중 어느 프로토콜을 사용해도
인터넷 게이트웨이(Internet Gateway)를 통해 인터넷과 통신 가능.

💡 정리

항목 설명

IPv6 유형	공용 IPv6 주소
네트워크 모드	IPv4 + IPv6 듀얼 스택 지원
인터넷 연결	인터넷 게이트웨이 통해 IPv4/IPv6 모두 가능

Egress-only Internet Gateway (EOIGW)

1. 개념

IPv6 전용 인터넷 게이트웨이.
IPv6용 NAT Gateway와 비슷한 역할 수행.

2. 주요 기능

VPC 내 인스턴스가 IPv6를 통해 인터넷으로 나가는(아웃바운드) 트래픽은 허용.
반대로, 인터넷에서 인스턴스로 들어오는(인바운드) IPv6 연결은 차단.
즉, 인터넷에서 인스턴스에 직접 IPv6 연결을 시작하지 못하게 함.

3. 구성 시 주의사항

사용 시 반드시 **라우트 테이블(Route Table)**에
Egress-only Internet Gateway를 향하는 IPv6 경로를 추가해야 함.

💡 요약

항목 설명

용도	IPv6 전용 아웃바운드 인터넷 접속 지원
인바운드	인터넷에서 VPC 인스턴스로의 IPv6 연결 차단
라우팅	라우트 테이블에 EOIGW 경로 추가 필요

VPC 섹션 요약 (1/3)

1. CIDR – IP 범위

VPC는 IPv4와 IPv6 CIDR 블록 목록을 정의하여 IP 주소 공간을 설정.

2. VPC와 서브넷

VPC (Virtual Private Cloud): 가상 네트워크 환경.
서브넷: 특정 가용 영역(AZ)에 연결되며, 각 서브넷마다 별도의 CIDR을 가짐.

3. 인터넷 게이트웨이 (Internet Gateway, IGW)

VPC 수준에서 인터넷 접속을 지원하는 리소스.
IPv4와 IPv6 모두 인터넷 접근 가능하게 함.

4. 라우트 테이블 (Route Tables)

서브넷에서 IGW, VPC 피어링, VPC 엔드포인트 등으로 트래픽이 가도록
라우트 테이블을 편집하여 적절한 경로를 추가해야 함.

5. 바스천 호스트 (Bastion Host)

퍼블릭 서브넷에 위치한 EC2 인스턴스.
외부에서 SSH로 접속해, 프라이빗 서브넷 내 EC2 인스턴스에 SSH 접근 가능하도록 중계 역할.

6. NAT 인스턴스 (NAT Instances)

프라이빗 서브넷의 EC2 인스턴스에 인터넷 액세스 제공.
직접 설정, 퍼블릭 서브넷에 위치.
Source/Destination 체크 비활성화 필요.
구식 방식으로 현재는 NAT Gateway 사용 권장.

7. NAT 게이트웨이 (NAT Gateway)

AWS가 관리하는 서비스형 NAT.
프라이빗 서브넷의 EC2가 인터넷에 액세스할 때,
확장성 좋고 관리 편리함.
IPv4 대상 인터넷 연결에 사용.

VPC 섹션 요약 (2/3)

1. NACL (Network ACL)

스테이트리스(stateless) 방화벽.
서브넷 단위로 인바운드/아웃바운드 트래픽 제어.
임시 포트(Ephemeral Ports) 관련 규칙도 반드시 설정해야 함.

2. 보안 그룹 (Security Groups)

스테이트풀(stateful) 방화벽.
EC2 인스턴스 단위로 동작.

3. VPC 피어링 (VPC Peering)

서로 겹치지 않는 CIDR을 가진 두 VPC 간 연결.
비전이성(Non-transitive) 연결 (피어링을 통해 연결된 다른 VPC로는 트래픽 전달 불가).

4. VPC 엔드포인트 (VPC Endpoints)

VPC 내에서 AWS 서비스(S3, DynamoDB, CloudFormation, SSM 등)에
프라이빗 네트워크 경로로 접근 가능하게 함.

5. VPC 플로우 로그 (VPC Flow Logs)

VPC, 서브넷, ENI 수준에서 설정 가능.
ACCEPT 및 REJECT 트래픽 기록.
공격 식별, 트래픽 분석에 도움.
Athena, CloudWatch Logs Insights 등으로 분석 가능.

6. Site-to-Site VPN

온프레미스 데이터센터(Customer Gateway) ↔ VPC 내 Virtual Private Gateway 연결.
인터넷을 통해 IPsec VPN 연결 구축.

7. AWS VPN CloudHub

여러 지점을 연결하는 허브-앤-스포크 VPN 모델.
여러 온프레미스 사이트를 중앙 허브(VPC)로 연결.

VPC 섹션 요약 (3/3)

1. Direct Connect

VPC에 **Virtual Private Gateway(VGW)**를 설정하고,
AWS Direct Connect 위치에 전용 프라이빗 연결 구축.

2. Direct Connect Gateway

여러 리전에 분산된 여러 VPC에 대해
하나의 Direct Connect 연결을 통해 접속 가능하게 하는 글로벌 허브 역할.

3. AWS PrivateLink / VPC Endpoint Services

서비스 제공자 VPC에서 고객 VPC로 프라이빗 연결 제공.
VPC 피어링, 공용 인터넷, NAT 게이트웨이, 라우트 테이블 수정 불필요.
**Network Load Balancer(NLB)**와 ENI와 함께 사용해야 함.

4. ClassicLink

EC2-Classic 인스턴스를 VPC에 프라이빗하게 연결하는 기능.

5. Transit Gateway

VPC, VPN, Direct Connect 간의 트랜지티브 피어링(경유 연결) 지원.
복잡한 멀티 VPC 및 하이브리드 네트워크 환경에 적합.

6. 트래픽 미러링 (Traffic Mirroring)

ENI에서 네트워크 트래픽을 복사해 보안 분석 및 모니터링에 활용.

7. Egress-only Internet Gateway

IPv6 전용 NAT Gateway와 유사한 기능.
IPv6 아웃바운드 인터넷 접속은 허용하되, 인바운드 접속은 차단.

프라이빗 IP 사용 권장 이유 및 팁

1. 비용 절감 및 네트워크 성능 향상

퍼블릭 IP 대신 프라이빗 IP를 사용하면
- 데이터 전송 비용 절감
- 네트워크 지연(latency) 감소로 성능 개선

2. 가용성 대비 비용 최적화

같은 가용 영역(AZ) 내에서 리소스를 배치하면
- 비용 절감 효과 극대화 가능
- 단, 가용성(HA) 측면에서는 단점 발생 가능

💡 요약

비용과 성능을 중시한다면 프라이빗 IP + 동일 AZ 사용 추천
고가용성이 필요하면 여러 AZ에 분산 배치 고려

Egress 트래픽 비용 최소화 전략

1. 트래픽 종류

Egress 트래픽: AWS에서 외부(인터넷 등)로 나가는 아웃바운드 트래픽
Ingress 트래픽: 외부에서 AWS로 들어오는 인바운드 트래픽 (일반적으로 무료)

2. 비용 절감 팁

가능한 한 인터넷 트래픽을 AWS 내부 네트워크에서 처리하도록 설계해 비용 절감.
예) VPC 피어링, PrivateLink, Direct Connect 등 활용.

3. Direct Connect 비용 최적화

Direct Connect 위치(Location)가 AWS 리전과 같은 지역에 있을 경우
- Egress 네트워크 비용이 더 낮아짐.
따라서 리전 내에서 Direct Connect 위치 선정이 비용에 영향.

💡 요약

구분 특징 비용 영향

Egress (출구 트래픽)	AWS → 외부	비용 발생
Ingress (입구 트래픽)	외부 → AWS	일반적으로 무료
AWS 내부 처리	인터넷 대신 내부 네트워크 이용	비용 절감
Direct Connect 위치	리전 내 위치 선택 시 비용 감소	중요

S3 데이터 전송 가격 분석 (미국 기준)

1. S3 데이터 전송 요금

S3로 데이터 업로드(Ingress): 무료
S3 → 인터넷 (아웃바운드): 1GB당 $0.09

2. S3 Transfer Acceleration

전송 속도 향상: 50% ~ 500% 빠름
기본 데이터 전송 비용 외 추가 요금 부과
- 1GB당 +$0.04 ~ $0.08

3. S3 → CloudFront 전송

비용: 1GB당 $0.00 (무료)

4. CloudFront → 인터넷 전송

비용: 1GB당 $0.085 (S3 직접 전송보다 약간 저렴)
장점:
- 캐싱 기능으로 지연시간(latency) 감소
- S3 요청 비용도 7배 절감 가능

5. S3 크로스 리전 복제 (Cross Region Replication)

비용: 1GB당 $0.02

💡 요약

전송 경로 비용 (GB당) 비고

S3 Ingress (업로드)	무료	-
S3 → 인터넷	$0.09	기본 아웃바운드 비용
S3 Transfer Acceleration	+$0.04~$0.08	속도 향상 추가 비용
S3 → CloudFront	$0.00	무료
CloudFront → 인터넷	$0.085	캐싱 및 비용 절감 효과
S3 Cross Region Replication	$0.02	리전 간 복제 비용

가격 비교: NAT Gateway vs Gateway VPC Endpoint

항목 NAT Gateway Gateway VPC Endpoint

기본 개념	프라이빗 서브넷 EC2 인스턴스의 인터넷 아웃바운드 접속을 위한 NAT 서비스	VPC 내에서 AWS 서비스(S3, DynamoDB 등)에 사설 네트워크로 접속하는 엔드포인트
요금 구조	- 시간당 요금 발생 - GB당 데이터 처리 요금 발생	- GB당 데이터 처리 요금 발생 (시간당 요금 없음)
시간당 비용	약 $0.045 (미국 리전 기준, 변동 가능)	없음
데이터 처리 요금	약 $0.045 per GB (리전마다 다름)	약 $0.01~$0.02 per GB (서비스 및 리전에 따라 다름)
비용 영향	트래픽이 많으면 비용 급증 가능	트래픽이 많아도 상대적으로 저렴
추가 비용	NAT Gateway 장애 시 대체 NAT Gateway 구축 시 비용 증가 가능	없음

요약

NAT Gateway는 인터넷 아웃바운드 트래픽을 처리하며 시간당 요금과 데이터 처리 요금이 모두 발생, 비용이 상대적으로 높을 수 있음.
Gateway VPC Endpoint는 특정 AWS 서비스 접속에 특화되어 있으며 시간당 요금은 없고 데이터 처리 요금만 부과되어 비용 효율적임.

AWS 네트워크 보호

기본적인 보호 수단

네트워크 ACL (NACL)
- 서브넷 단위의 stateless 트래픽 필터링.
Amazon VPC 보안 그룹(Security Groups)
- EC2 인스턴스 단위의 stateful 방화벽.
AWS WAF (웹 애플리케이션 방화벽)
- 악성 요청(웹 공격) 차단.
AWS Shield 및 AWS Shield Advanced
- DDoS 공격 방어 서비스.
AWS Firewall Manager
- 여러 AWS 계정 및 리소스에 걸쳐 방화벽 정책 중앙 관리.

AWS Network Firewall

1. 개요

Amazon VPC 전체를 보호하는 네트워크 방화벽 서비스.
네트워크 계층 3부터 애플리케이션 계층 7까지 다계층 보호 제공.

2. 보호 대상 및 방향

다양한 트래픽 방향에서 검사 가능:
- VPC ↔ VPC 트래픽
- VPC → 인터넷 아웃바운드
- 인터넷 → VPC 인바운드
- Direct Connect 및 Site-to-Site VPN 간 트래픽
즉, 모든 네트워크 경로를 포괄적으로 보호.

3. 내부 구성 및 관리

AWS Network Firewall은 AWS Gateway Load Balancer를 내부적으로 사용해 트래픽을 처리.
방화벽 규칙은 AWS Firewall Manager를 통해 여러 VPC에 걸쳐 중앙 집중식으로 관리 및 적용 가능.

4. 활용 예시

프라이빗 서브넷 보호
온프레미스 데이터센터와 Direct Connect/VPN 연결 시 네트워크 보안 강화

💡 요약

특징 설명

보호 범위	VPC 전체, 다양한 트래픽 방향 (내부/외부)
계층 범위	L3 ~ L7 다계층 네트워크 보호
내부 구성	AWS Gateway Load Balancer 활용
중앙 관리	AWS Firewall Manager로 규칙 관리

AWS Network Firewall – 세밀한 제어 기능

1. 대규모 룰 지원

수천 개의 룰을 지원하여 매우 정교한 네트워크 필터링 가능.
예: 수만 개의 IP 주소 필터링.

2. 룰 조건 종류

IP 및 포트 기반 필터링 (예: 특정 IP 차단).
프로토콜 필터링 (예: 아웃바운드 SMB 프로토콜 차단).
Stateful 도메인 리스트 룰 그룹
- 특정 도메인에 대한 아웃바운드 트래픽만 허용 (예: *.mycorp.com, 서드파티 소프트웨어 저장소).
정규 표현식(Regex)을 사용한 일반적인 패턴 매칭.

3. 트래픽 처리

룰에 매칭되는 트래픽에 대해 허용(Allow), 차단(Drop), 알림(Alert) 동작 지정 가능.

4. 능동적 흐름 검사(Active Flow Inspection)

네트워크 위협에 대응하는 침입 방지 기능 포함.
Gateway Load Balancer와 유사하지만 AWS가 완전 관리.

5. 로그 관리

룰 매칭 로그를
- Amazon S3
- CloudWatch Logs
- Kinesis Data Firehose
  로 전송하여 중앙 집중식 모니터링 및 분석 가능.

💡 요약

기능 설명

룰 수	수천 개 이상 가능
필터링 대상	IP, 포트, 프로토콜, 도메인, 패턴(Regex)
트래픽 제어	허용 / 차단 / 알림
보안 기능	침입 방지(IPSec) 포함 능동적 흐름 검사
로그 전송	S3, CloudWatch, Kinesis Data Firehose

'AWS' 카테고리의 다른 글

more solution architect (0)	2025.08.12
Disaster Recovery Overview (3)	2025.08.12
AWS보안 및 암호화 (3)	2025.08.11
Iam - 고급 (3)	2025.08.10
AWS Organizations (0)	2025.08.10