AWS Certified Solutions Architect - Associate (SAA-C03) #4 Domain 1-3 안전한 아키텍처: VPC 보안
#3 KMS와 암호화에서 데이터 자체를 보호했다면, 이번에는 그 데이터가 오가는 네트워크 경계를 다룹니다. VPC 보안은 SAA에서 거의 모든 아키텍처 문항에 깔리는 토대입니다. “private 서브넷의 DB에 어떻게 접근하는가”, “인터넷을 타지 않고 S3에 닿게 하라” 같은 요구사항이 모두 여기서 갈립니다.
보안 그룹 vs 네트워크 ACL #
VPC에는 두 층의 방화벽이 있습니다. 이 둘의 차이는 시험에 거의 항상 나옵니다.
| 항목 | 보안 그룹 (Security Group) | 네트워크 ACL (NACL) |
|---|---|---|
| 동작 단위 | 인스턴스(ENI) 레벨 | 서브넷 레벨 |
| 상태 | Stateful (응답 자동 허용) | Stateless (응답도 규칙 필요) |
| 규칙 종류 | 허용(Allow)만 | 허용 + 거부(Deny) |
| 규칙 평가 | 모든 규칙 종합 | 번호 순서대로, 첫 일치 적용 |
| 기본값 | 인바운드 차단, 아웃바운드 허용 | 기본 NACL은 전부 허용 |
Stateful vs Stateless가 핵심 #
보안 그룹은 stateful입니다. 인바운드를 허용하면 그에 대한 응답(아웃바운드)은 규칙 없이도 자동 허용됩니다. 반대로 NACL은 stateless라, 들어오는 트래픽을 허용해도 나가는 응답을 위한 규칙을 따로 열어야 합니다. 이때 응답은 임시 포트(ephemeral port, 보통 1024~65535)로 나가므로, NACL에서 이 포트 범위의 아웃바운드를 막으면 통신이 끊깁니다.
Deny가 필요하면 NACL #
보안 그룹은 허용 규칙만 만들 수 있습니다. “특정 IP 하나를 차단하라"는 요구사항은 보안 그룹으로 불가능하고, NACL의 Deny 규칙으로 처리합니다. 시험에서 “악성 IP 차단”, “특정 대역 거부"가 나오면 NACL이 답입니다.
VPC Endpoint: 인터넷을 타지 않는 접근 #
private 서브넷의 인스턴스가 S3 같은 AWS 서비스에 접근할 때, 인터넷 게이트웨이나 NAT를 거치면 트래픽이 AWS 네트워크를 벗어났다 돌아옵니다. VPC Endpoint는 트래픽을 AWS 내부에 둔 채 서비스에 닿게 합니다. 두 종류가 있습니다.
| 종류 | 대상 | 동작 | 비용 |
|---|---|---|---|
| Gateway Endpoint | S3, DynamoDB 둘뿐 | 라우트 테이블에 경로 추가 | 무료 |
| Interface Endpoint | 대부분의 AWS 서비스 | 서브넷에 ENI(사설 IP) 생성 | 시간당 + 데이터 요금 |
가장 자주 틀리는 지점은 Gateway Endpoint가 S3와 DynamoDB 전용이라는 것입니다. SQS,KMS,Systems Manager 같은 다른 서비스에 사설로 접근하려면 Interface Endpoint를 써야 합니다. Interface Endpoint는 내부적으로 PrivateLink 기술을 사용합니다.
PrivateLink: 내 서비스를 사설로 노출 #
PrivateLink는 VPC 피어링 없이, 인터넷을 거치지 않고 서비스를 다른 VPC에 노출하는 방법입니다. 구조는 이렇습니다.
- 서비스 제공자(provider)는 서비스를 Network Load Balancer 뒤에 두고 Endpoint Service로 등록합니다.
- 소비자(consumer)는 자기 VPC에 Interface Endpoint를 만들어 그 서비스에 연결합니다.
- 두 VPC의 CIDR이 겹쳐도 되고, 양쪽 네트워크가 직접 라우팅되지 않습니다.
“SaaS 형태로 우리 서비스를 고객 VPC에 제공하되, 피어링이나 공인 노출 없이"라는 요구사항이 나오면 PrivateLink가 정답입니다. VPC 피어링이 두 VPC 전체를 라우팅으로 연결하는 것과 달리, PrivateLink는 특정 서비스 하나만 노출합니다.
VPC 피어링과의 구분 #
| 방법 | 연결 범위 | 특징 |
|---|---|---|
| VPC 피어링 | VPC 전체 ↔ VPC 전체 | 1:1, 비전이적, CIDR 겹침 불가 |
| PrivateLink | 특정 서비스만 | CIDR 겹쳐도 됨, 단방향 노출 |
| Transit Gateway | 다수 VPC 허브 | 많은 VPC를 중앙에서 연결 |
VPC 피어링은 전이되지 않습니다. A-B, B-C가 피어링돼 있어도 A는 C에 직접 닿지 못합니다. 다수 VPC를 엮어야 하면 Transit Gateway가 답입니다.
private 인스턴스에 접근하기: 배스천 vs Session Manager #
private 서브넷의 인스턴스에 관리자가 접속하는 두 방식이 있습니다.
- 배스천 호스트(Bastion / Jump box). public 서브넷에 점프 서버를 두고, 거기서 private 인스턴스로 SSH합니다. 배스천에 인바운드 SSH(22)를 열어야 하므로 공격 표면이 생깁니다.
- Systems Manager Session Manager. 배스천 없이, 인바운드 포트를 전혀 열지 않고 IAM 권한으로 셸에 접속합니다. SSH 키 관리도 필요 없고 접속 기록이 남습니다.
시험에서 “인바운드 포트를 열지 않고 안전하게 private 인스턴스에 접근"이라는 단서가 나오면 Session Manager가 현대적인 정답입니다.
VPC Flow Logs #
VPC Flow Logs는 ENI를 드나드는 IP 트래픽의 메타데이터(출발/목적지 IP,포트, 프로토콜, 허용/거부 여부, 바이트 수)를 CloudWatch Logs나 S3로 보냅니다. 보안 감사와 트래픽 문제 추적에 씁니다.
중요한 한계: Flow Logs는 패킷의 내용(payload)은 담지 않습니다. “어떤 데이터가 오갔는지"가 아니라 “누가 누구와 어떤 포트로 통신했고 허용/거부됐는지"만 봅니다. 패킷 내용까지 봐야 하면 Traffic Mirroring이 필요합니다.
시험 출제 패턴 #
- “특정 IP를 차단하라.” → NACL의 Deny 규칙(보안 그룹은 Deny 불가)
- “보안 그룹은 stateful한가 stateless한가?” → Stateful(응답 자동 허용). NACL은 stateless
- “private 인스턴스가 인터넷 없이 S3에 접근.” → Gateway Endpoint(무료)
- “private 인스턴스가 SQS/KMS에 사설로 접근.” → Interface Endpoint(PrivateLink)
- “우리 서비스를 고객 VPC에 피어링 없이 제공.” → PrivateLink + NLB
- “다수 VPC를 중앙에서 연결.” → Transit Gateway
- “인바운드 포트 없이 private 인스턴스 접속.” → Session Manager
- “네트워크 트래픽 흐름 감사.” → VPC Flow Logs
자주 만나는 함정 #
1) 보안 그룹으로 Deny를 만들려 한다 #
보안 그룹은 허용 규칙만 있습니다. 차단은 NACL입니다.
2) NACL을 stateful로 취급 #
NACL은 stateless라 응답 트래픽의 임시 포트를 따로 열어야 합니다. 인바운드만 열고 아웃바운드를 막으면 통신이 끊깁니다.
3) Gateway Endpoint로 모든 서비스에 접근하려 한다 #
Gateway Endpoint는 S3와 DynamoDB 전용입니다. 나머지는 Interface Endpoint입니다.
4) VPC 피어링이 전이된다고 생각 #
피어링은 비전이적입니다. A-B-C가 있어도 A는 C에 직접 못 닿습니다.
5) Flow Logs로 패킷 내용을 본다 #
Flow Logs는 메타데이터만 봅니다. 내용 캡처는 Traffic Mirroring입니다.
정리 #
이번 글에서 잡은 것:
- 보안 그룹. 인스턴스 레벨, stateful, 허용만. NACL. 서브넷 레벨, stateless, 허용+거부, 순서 평가
- **차단(Deny)**이 필요하면 NACL. 보안 그룹으로는 불가
- Gateway Endpoint. S3,DynamoDB 전용,무료. Interface Endpoint. 그 외 서비스, PrivateLink 기반
- PrivateLink. 피어링 없이 특정 서비스만 사설 노출. 피어링은 비전이적, TGW는 다수 VPC 허브
- private 접속. 배스천 대신 Session Manager(인바운드 포트 불필요)
- Flow Logs. 트래픽 메타데이터 감사(내용은 미포함)
다음: Domain 1-4 WAF,Shield,Cognito #
네트워크 경계를 잡았으니, 보안 도메인의 마지막으로 애플리케이션 계층 보호와 사용자 인증을 다룹니다.
#5 Domain 1-4 WAF,Shield,Cognito,Secrets Manager에서는 WAF의 웹 ACL과 규칙, Shield Standard와 Advanced의 차이, Cognito User Pool과 Identity Pool의 역할 구분, 그리고 Secrets Manager와 Parameter Store의 비교까지 정리하겠습니다.