AWS에서 VPC 암호화 제어(VPC encryption controls)를 공개하면서, “VPC 내부 및 리전 내 VPC 간” 트래픽에 대해 전송 중 암호화(encryption in transit)를 감사(audit)하고, 최종적으로 강제(enforce)까지 걸 수 있게 됐습니다.
문서/감사 대응 관점에서 특히 좋은 점은, 스프레드시트로 네트워크 경로별 암호화 여부를 추적하던 작업을 VPC 단위의 중앙 통제로 가져올 수 있다는 점입니다.

1) 동작 개념
VPC 암호화 제어는 운영 모드가 두 가지입니다.
- 모니터링(Monitor): 트래픽 흐름을 감사해서 평문(암호화 안 됨)이 섞여 있는지 찾는 단계입니다. 이때 VPC Flow Logs에
encryption-status필드가 추가되어, 트래픽이 Nitro 하드웨어 암호화인지, TLS인지, 둘 다인지 확인할 수 있습니다. - 적용(Enforce): 암호화가 안 된 트래픽을 차단하도록 강제하는 단계입니다. 기존 VPC는 반드시 Monitor로 시작하고, 평문 트래픽이 없다는 확신이 생겼을 때 Enforce로 전환하는 흐름이 권장됩니다.
또 하나 중요한 제약이 있습니다. VPC 하나당 VPC 암호화 제어는 1개만 연결되는 1:1 구조입니다.
2) 사전 준비
실제 적용 전에 저는 아래 항목부터 확인했습니다.
- Nitro 기반 여부 점검
Nitro 기반 인스턴스는 네트워크 계층(L3)에서 하드웨어 기반 암호화가 가능하고, Nitro가 아닌 경우에는 동일 조건을 만족하지 못할 수 있습니다. AWS 블로그 데모에서도 Nitro 기반(m7g.medium)과 비 Nitro(t4g.medium)를 섞어 차이를 보여줍니다. - 예외(Exclusion)가 필요한 리소스 존재 여부
트래픽이 AWS 네트워크 바깥으로 나가는 성격의 리소스(예: Internet Gateway, NAT Gateway)는 암호화를 지원하지 않아 예외 설정 대상이 될 수 있습니다. - Transit Gateway를 쓰는 환경인지
VPC들이 Transit Gateway로 연결된 구성이라면, VPC 쪽만이 아니라 Transit Gateway 쪽 설정/권한 이슈도 함께 봐야 합니다. 특히 CloudFormation으로 만들 때 추가 IAM 권한이 필요하다는 점이 문서/블로그에 명시돼 있습니다.
3) Monitor 모드로 VPC 암호화 제어 생성
콘솔에서 생성

AWS 콘솔에서 VPC → “VPC 암호화 제어” 탭으로 이동해 암호화 제어 생성을 누르는 방식입니다. 기존 VPC는 Monitor로 시작해야 하고, 신규 VPC는 생성 시점에 Enforce로도 가져갈 수 있다고 안내합니다.
CLI로 생성
AWS 블로그에 나온 그대로 CLI로도 생성할 수 있습니다.
aws ec2 create-vpc-encryption-control --vpc-id vpc-123456789
4) VPC Flow Logs에 encryption-status를 붙여서 “평문 트래픽” 찾기

제가 이 기능을 가장 실무적으로 체감한 부분이 여기였습니다.
Monitor 모드를 켠 뒤, VPC Flow Logs 생성 시 로그 포맷에 ${encryption-status}를 추가하면, 트래픽이 어떤 방식으로 암호화되는지 한 번에 드러납니다.
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-123456789 \
--traffic-type ALL \
--log-destination-type s3 \
--log-destination arn:aws:s3:::vpc-flow-logs-012345678901/vpc-flow-logs/ \
--log-format '${flow-direction} ${traffic-path} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${encryption-status}'
encryption-status 값은 다음 의미를 가집니다.
- 0 : 평문(암호화 없음)
- 1 : Nitro에 의해 네트워크 계층(L3)에서 암호화
- 2 : 애플리케이션 계층(L7)에서 TLS/SSL(예: 443)
- 3 : Nitro(L3) + TLS(L7) 둘 다
- - : VPC 암호화 제어 미사용이거나 Flow Logs에 상태 정보가 없는 경우
운영 팁: 저는 여기서 0이 잡히는 흐름을 먼저 “리소스 단위”로 쪼개서, (a) Nitro 전환으로 풀 건지, (b) TLS로 풀 건지를 나눠 잡는 방식이 가장 깔끔했습니다.
5) Enforce를 막는(Non-compliant) 리소스 조회
Flow Logs로 “평문이 있다/없다”를 확인했다면, 다음은 무엇이 Enforce 전환을 막는지 확인하는 단계입니다. AWS는 콘솔에서도 보여주고, CLI도 제공합니다.
aws ec2 get-vpc-resources-blocking-encryption-enforcement --vpc-id vpc-123456789
AWS 블로그 예시에서는 Internet Gateway와 Nitro 기반이 아닌 인스턴스의 ENI가 비암호화 리소스로 리포팅됩니다.
6) 비암호화 리소스 수정 전략
여기서부터는 “모든 리소스가 암호화를 만족”해야 Enforce로 갈 수 있습니다.
AWS가 문서/블로그에서 명확히 말하는 핵심은 아래입니다.
6-1. 대부분의 AWS 서비스는 자동으로 따라옵니다
- PrivateLink / Gateway Endpoint로 접근하는 AWS 서비스는 TLS만 허용하며, TLS가 아니면 AWS가 트래픽을 차단한다고 설명합니다.
- NLB / ALB / Fargate / EKS 등은 Monitor를 켜면 Nitro 기반 하드웨어로 자동·점진적 마이그레이션이 진행되고, 사용자는 별도 조치가 필요 없다고 안내합니다.
6-2. 직접 손봐야 하는 대표 케이스: “인스턴스/노드 기반 리소스”
EC2 인스턴스, Auto Scaling 그룹, RDS(문서에 DocumentDB 포함), ElastiCache(노드 기반), Redshift(프로비저닝), ECS(EC2 capacity), MSK 프로비저닝, OpenSearch, EMR 등은 기본 인스턴스 선택이 필요할 수 있습니다.
특히 Redshift는 마이그레이션 시 스냅샷에서 새 클러스터/네임스페이스 생성이 필요하다고 명시돼 있어, 작업 계획에 꼭 반영하는 게 안전합니다.
6-3. 예외(Exclusion) 처리
Internet Gateway / NAT Gateway처럼 “AWS 네트워크 밖으로 나가는 흐름” 성격 때문에 암호화를 지원하지 않는 리소스는 예외 설정을 둘 수 있다고 안내합니다.
다만, 일부 리소스는 예외로 둘 수 없고 반드시 준수해야 한다는 점도 같이 명시돼 있습니다.
7) Enforce 모드로 전환

준비가 끝났다면 Enforce로 전환합니다.
aws ec2 modify-vpc-encryption-control --vpc-id vpc-123456789 --mode enforce
Enforce가 켜진 이후에는, 앞으로 생성되는 리소스가 호환되는 Nitro 기반에서만 생성되도록 강제되고, 잘못된 프로토콜/포트로 들어오는 비암호화 트래픽은 드롭된다고 설명합니다.
8) Transit Gateway를 쓴다면
Transit Gateway가 연결된 구성은 따로 챙길 게 있습니다.
- (영문 블로그 기준) VPC들이 Transit Gateway로 연결된 경우, VPC 쪽 Enforce만으로 끝나는 게 아니라 Transit Gateway에도 암호화 제어를 활성화해야 VPC 간 트래픽이 암호화된다고 설명합니다.
- (한글 블로그 기준) CloudFormation으로 Transit Gateway를 “암호화 활성화 상태”로 만들려면 ec2:ModifyTransitGateway 및 ec2:ModifyTransitGatewayOptions 권한이 추가로 필요하고, 이 권한이 없으면 생성 단계에서 스택이 실패할 수 있다고 명시돼 있습니다.
9) 요금/가용성 체크
- 한국 블로그 기준으로 2026년 3월 1일까지 무료라고 안내돼 있습니다. (이후 상세 요금은 VPC 요금 페이지에 업데이트 예정)
- 사용 가능한 리전 목록도 블로그에 구체적으로 나열돼 있으니, 운영 리전이 포함되는지 먼저 확인하는 게 좋습니다.