AWS Certified CloudOps Engineer - Associate (SOA-C03) #10 Domain 4-1 네트워킹: VPC 운영과 연결 트러블슈팅
#9까지 배포,자동화 도메인을 마쳤습니다. 네 번째 도메인은 네트워킹과 콘텐츠 전송(18%)입니다. 운영에서 네트워킹 문항은 대부분 “연결이 안 된다"로 시작합니다. 그래서 이 글의 목표는 VPC 구성 요소를 외우는 것이 아니라, 연결 실패를 어디부터 어떤 순서로 짚는지 운영 절차를 잡는 것입니다.
VPC 구성 요소 빠른 정리 #
| 요소 | 역할 |
|---|---|
| Subnet | VPC를 AZ별로 나눈 IP 구간. 퍼블릭,프라이빗 |
| Route Table | 트래픽이 어디로 갈지 결정 |
| Internet Gateway(IGW) | VPC ↔ 인터넷 양방향 |
| NAT Gateway | 프라이빗 서브넷의 아웃바운드 인터넷(인바운드 차단) |
| Security Group | 인스턴스(ENI) 단위 방화벽 |
| NACL | 서브넷 단위 방화벽 |
퍼블릭 서브넷과 프라이빗 서브넷의 차이는 단 하나입니다. 라우팅 테이블에 IGW로 가는 경로(0.0.0.0/0 → igw)가 있는가입니다. 인스턴스에 퍼블릭 IP가 있어도 라우팅이 없으면 인터넷에 못 나갑니다.
보안 그룹 vs NACL #
연결 트러블슈팅의 절반이 이 둘입니다. 차이를 정확히 알아야 합니다.
| 항목 | Security Group | NACL |
|---|---|---|
| 적용 단위 | 인스턴스(ENI) | 서브넷 |
| 상태 | Stateful(나간 응답 자동 허용) | Stateless(응답도 규칙 필요) |
| 규칙 | 허용(allow)만 | 허용,거부(deny) 모두 |
| 평가 | 모든 규칙 종합 | 번호 순서대로 |
가장 중요한 차이는 상태성입니다. 보안 그룹은 stateful이라 인바운드를 허용하면 그 응답 아웃바운드는 자동 허용입니다. NACL은 stateless라 인바운드와 아웃바운드(특히 임시 포트 1024〜65535)를 둘 다 열어야 합니다. “보안 그룹은 맞게 열었는데 NACL 때문에 응답이 막힌다"는 단골 시나리오의 핵심이 이 stateless 임시 포트입니다.
프라이빗 서브넷의 외부 연결 #
프라이빗 인스턴스가 외부와 통신하는 경로는 둘입니다.
| 목적 | 수단 |
|---|---|
| 인터넷으로 아웃바운드(패치,외부 API) | NAT Gateway |
| AWS 서비스에 사설 연결(S3,DynamoDB,SSM 등) | VPC 엔드포인트 |
VPC 엔드포인트 #
| 종류 | 대상 | 동작 |
|---|---|---|
| Gateway 엔드포인트 | S3, DynamoDB | 라우팅 테이블에 경로 추가(무료) |
| Interface 엔드포인트(PrivateLink) | 대부분의 서비스(SSM,ECR 등) | ENI로 사설 IP 제공(유료) |
엔드포인트의 효용은 트래픽이 인터넷을 거치지 않는 것입니다. 비용(NAT 데이터 처리비 절감)과 보안 양쪽에서 답이 됩니다. “프라이빗 인스턴스가 S3에 접근하는데 NAT 비용을 줄여라"는 답이 S3 Gateway 엔드포인트, “#8의 SSM이 프라이빗에서 안 된다"는 답이 Interface 엔드포인트입니다.
VPC 간 연결 #
| 수단 | 언제 |
|---|---|
| VPC Peering | 두 VPC를 1:1 연결. 전이(transitive) 안 됨 |
| Transit Gateway | 여러 VPC,온프레미스를 허브로 연결. 대규모 |
| Site-to-Site VPN | 온프레미스 ↔ VPC(인터넷 경유, 암호화) |
| Direct Connect | 온프레미스 ↔ AWS 전용 회선(낮은 지연,안정) |
핵심 함정은 피어링은 전이되지 않는다는 점입니다. A-B, B-C가 피어링돼 있어도 A는 C와 통신 못 합니다. “VPC가 늘어나 메시 연결이 복잡하다"는 답이 Transit Gateway입니다.
연결 트러블슈팅 순서 #
“인스턴스에 접속이 안 된다"를 만났을 때, 운영에서 점검하는 순서는 대체로 다음입니다.
- 라우팅 테이블: 목적지로 가는 경로가 있는가(IGW,NAT,엔드포인트)
- 보안 그룹: 인바운드에 해당 포트,소스가 허용돼 있는가
- NACL: 인바운드,아웃바운드(임시 포트 포함)가 막혀 있지 않은가
- 퍼블릭 IP / DNS: 퍼블릭 접근이면 퍼블릭 IP,DNS 확인
- OS 방화벽: 인스턴스 안 iptables 등
진단 도구도 함께 기억해 둘 만합니다.
- VPC Flow Logs: ENI,서브넷,VPC의 트래픽을 기록. 허용(ACCEPT),거부(REJECT)를 보여 줘 어디서 막혔는지 단서
- Reachability Analyzer: 출발지와 목적지를 지정하면 경로상 무엇이 막는지 정적으로 분석
- Network Access Analyzer: 의도치 않은 네트워크 경로(노출)를 점검
“트래픽이 거부되는데 보안 그룹,NACL 중 무엇 때문인지 모르겠다"는 답이 VPC Flow Logs(REJECT 확인), “두 자원 간 연결 가능 여부를 미리 검증하라"는 Reachability Analyzer입니다.
시험 출제 패턴 #
- 퍼블릭인데 인터넷이 안 됨 → 라우팅 테이블의 IGW 경로 확인
- 보안 그룹은 열었는데 응답이 막힘 → NACL 임시 포트(stateless)
- 프라이빗에서 S3 접근, NAT 비용 절감 → S3 Gateway 엔드포인트
- 프라이빗에서 SSM,ECR 사설 연결 → Interface 엔드포인트
- VPC가 많아 연결이 복잡 → Transit Gateway(피어링은 비전이)
- 어디서 트래픽이 막히는지 모름 → VPC Flow Logs(REJECT)
- 연결 가능 여부 사전 검증 → Reachability Analyzer
자주 만나는 함정 #
1) 보안 그룹과 NACL을 같은 것으로 봄 #
SG는 인스턴스 단위,stateful,allow만, NACL은 서브넷 단위,stateless,allow/deny입니다. NACL은 응답 포트까지 열어야 합니다.
2) 피어링이 전이된다고 생각 #
A-B-C 피어링이 있어도 A-C는 직접 피어링하거나 Transit Gateway를 써야 합니다.
3) NAT Gateway로 인바운드가 된다고 오해 #
NAT는 아웃바운드 전용입니다. 외부에서 프라이빗으로 들어오는 인바운드는 NAT로 안 됩니다.
4) 엔드포인트 없이 SSM이 프라이빗에서 된다고 가정 #
인터넷,NAT가 없으면 프라이빗 인스턴스의 SSM,ECR은 Interface 엔드포인트가 필요합니다.
정리 #
이번 글에서 잡은 것:
- 퍼블릭,프라이빗의 차이는 라우팅 테이블의 IGW 경로 유무
- 보안 그룹(인스턴스,stateful,allow) vs NACL(서브넷,stateless,allow/deny). NACL은 임시 포트까지
- 프라이빗 외부 연결은 NAT(인터넷 아웃바운드)와 VPC 엔드포인트(AWS 사설 연결). Gateway(S3,DynamoDB,무료) vs Interface(PrivateLink)
- VPC 간은 피어링(비전이),Transit Gateway(허브), 온프레미스는 VPN,Direct Connect
- 트러블슈팅은 라우팅 → SG → NACL → 퍼블릭 IP → OS 순. Flow Logs,Reachability Analyzer로 진단
다음: Domain 4-2 Route 53과 CloudFront #
VPC 내부 연결을 잡았으니, 다음은 DNS와 콘텐츠 전송입니다.
#11 Domain 4-2 네트워킹: Route 53,CloudFront,전송 운영에서는 Route 53 레코드와 라우팅 정책, 헬스체크, CloudFront 캐싱과 오리진 구성, TLS 인증서(ACM), 그리고 콘텐츠 전송 트러블슈팅까지 정리하겠습니다.