# Amazon Virtual Private Cloud에 대한 보안 책임 관리
AWS은 클라우드 보안을 가장 중요하게 생각합니다. AWS 고객으로서 여러분은 가장 높은 보안 요구 사항을 충족하기 위해 설계된 데이터 센터 및 네트워크 아키텍처의 혜택을 받게 됩니다.
보안은 AWS와 여러분의 공동 책임입니다. [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)은 이 사항을 클라우드*의* 보안 및 클라우드 *내* 보안으로 설명합니다.
+ **클라우드의 보안**: AWS는 AWS클라우드에서 AWS서비스를 실행하는 인프라를 보호할 책임이 있습니다. AWS는 안전하게 사용할 수 있는 서비스 또한 제공합니다. 타사 감사자는 [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)의 일환으로 보안 효과를 정기적으로 테스트하고 검증합니다. Amazon Virtual Private Cloud에 적용되는 규정 준수 프로그램에 대한 자세한 내용은 [규정 준수 프로그램 제공 범위 내 AWS 서비스](https://aws.amazon.com/compliance/services-in-scope/)를 참조하세요.
+ **클라우드 내 보안** – 귀하의 책임은 귀하가 사용하는 AWS 서비스에 의해 결정됩니다. 또한 귀하는 귀사의 데이터 민감도, 귀사의 요구 사항, 관련 법률 및 규정을 비롯한 기타 요소에 대해서도 책임이 있습니다.
이 설명서는 Amazon VPC를 사용할 때 공동 책임 모델을 적용하는 방법을 이해하는 데 도움이 됩니다. 다음 주제에서는 보안 및 규정 준수 목적에 맞게 Amazon VPC를 구성하는 방법을 보여줍니다. 또한 Amazon VPC 리소스를 모니터링하고 보호하는 데 도움이 되는 다른 AWS 서비스를 사용하는 방법을 배우게 됩니다.
**Topics**
+ [Amazon Virtual Private Cloud에서 데이터 보호 보장](data-protection.md)
+ [전송 중 VPC 암호화 적용](vpc-encryption-controls.md)
+ [Amazon VPC용 자격 증명 및 액세스 관리](security-iam.md)
+ [Amazon VPC의 인프라 보안](infrastructure-security.md)
+ [보안 그룹을 사용하여 AWS 리소스에 대한 트래픽 제어](vpc-security-groups.md)
+ [네트워크 액세스 제어 목록으로 서브넷 트래픽 제어](vpc-network-acls.md)
+ [Amazon Virtual Private Cloud에서의 복원성](disaster-recovery-resiliency.md)
+ [Amazon Virtual Private Cloud에 대한 규정 준수 확인](VPC-compliance.md)
+ [VPC 및 서브넷에 대한 퍼블릭 액세스 차단](security-vpc-bpa.md)
+ [VPC에 대한 보안 모범 사례](vpc-security-best-practices.md)
# Amazon Virtual Private Cloud에서 데이터 보호 보장
AWS [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)은 Amazon Virtual Private Cloud의 데이터 보호에 적용됩니다. 이 모델에서 설명하는 것처럼 AWS는 모든 AWS 클라우드를 실행하는 글로벌 인프라를 보호할 책임이 있습니다. 사용자는 이 인프라에 호스팅되는 콘텐츠에 대한 통제 권한을 유지할 책임이 있습니다. 사용하는 AWS 서비스의 보안 구성과 관리 태스크에 대한 책임도 사용자에게 있습니다. 데이터 프라이버시에 관한 자세한 내용은 [데이터 프라이버시 FAQ](https://aws.amazon.com/compliance/data-privacy-faq/)를 참조하세요. 유럽의 데이터 보호에 대한 자세한 내용은 *AWS보안 블로그*의 [AWS공동 책임 모델 및 GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) 블로그 게시물을 참조하세요.
데이터를 보호하려면 AWS 계정자격 증명을 보호하고 AWS IAM Identity Center또는 AWS Identity and Access Management(IAM)를 통해 개별 사용자 계정을 설정하는 것이 좋습니다. 이렇게 하면 개별 사용자에게 자신의 직무를 충실히 이행하는 데 필요한 권한만 부여됩니다. 또한 다음과 같은 방법으로 데이터를 보호하는 것이 좋습니다.
+ 각 계정에 다중 인증(MFA)을 사용합니다.
+ SSL/TLS를 사용하여 AWS리소스와 통신하세요. TLS 1.2는 필수이며 TLS 1.3을 권장합니다.
+ AWS CloudTrail으로 API 및 사용자 활동 로깅을 설정하세요. AWS 활동 캡처에 CloudTrail 추적을 사용하는 방법에 대한 자세한 내용은 *AWS CloudTrail사용 설명서*의 [CloudTrail 추적 작업](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)을 참조하세요.
+ AWS 암호화 솔루션을 AWS 서비스내의 모든 기본 보안 컨트롤과 함께 사용하세요.
+ Amazon S3에 저장된 민감한 데이터를 검색하고 보호하는 데 도움이 되는 Amazon Macie와 같은 고급 관리형 보안 서비스를 사용합니다.
+ 명령줄 인터페이스 또는 API를 통해 AWS에 액세스할 때 FIPS 140-3 검증된 암호화 모듈이 필요한 경우, FIPS 엔드포인트를 사용합니다. 사용 가능한 FIPS 엔드포인트에 대한 자세한 내용은 [연방 정보 처리 표준(FIPS) 140-3](https://aws.amazon.com/compliance/fips/)을 참조하세요.
고객의 이메일 주소와 같은 기밀 정보나 중요한 정보는 태그나 **이름** 필드와 같은 자유 형식 텍스트 필드에 입력하지 않는 것이 좋습니다. 여기에는 Amazon VPC 또는 기타 AWS 서비스에서 콘솔, API, AWS CLI 또는 AWS SDK를 사용하여 작업하는 경우가 포함됩니다. 이름에 사용되는 태그 또는 자유 형식 텍스트 필드에 입력하는 모든 데이터는 청구 또는 진단 로그에 사용될 수 있습니다. 외부 서버에 URL을 제공할 때 해당 서버에 대한 요청을 검증하기 위해 자격 증명을 URL에 포함해서는 안 됩니다.
# Amazon VPC에서 인터네트워크 트래픽 프라이버시 보장
Amazon Virtual Private Cloud는 가상 프라이빗 클라우드(VPC)의 보안을 강화하고 모니터링하는 데 사용할 수 있는 여러 기능을 제공합니다.
+ **보안 그룹**: 보안 그룹은 리소스 수준(예: EC2 인스턴스)에서 특정 인바운드 및 아웃바운드 트래픽을 허용합니다. 인스턴스를 시작할 때 하나 이상의 보안 그룹과 연결할 수 있습니다. VPC의 각 인스턴스는 서로 다른 보안 그룹 세트에 속할 수 있습니다. 인스턴스를 시작할 때 보안 그룹을 지정하지 않을 경우 해당 VPC에 대해 인스턴스는 기본 보안 그룹과 자동으로 연결됩니다. 자세한 내용은 [보안 그룹](vpc-security-groups.md) 단원을 참조하세요.
+ **네트워크 액세스 제어 목록(ACL)**: 네트워크 ACL은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부합니다. 자세한 내용은 [네트워크 액세스 제어 목록으로 서브넷 트래픽 제어](vpc-network-acls.md) 단원을 참조하세요.
+ **흐름 로그**: 흐름 로그는 VPC의 네트워크 인터페이스에서 양방향으로 이동하는 IP 트래픽에 대한 정보를 캡처합니다. VPC, 서브넷 또는 개별 네트워크 인터페이스에 대한 흐름 로그를 생성할 수 있습니다. 흐름 로그 데이터는 CloudWatch Logs 또는 Amazon S3에 게시되며 과도하게 제한하거나 과도하게 허용하는 보안 그룹과 네트워크 ACL 규칙을 진단하는 데 도움이 됩니다. 자세한 내용은 [VPC 흐름 로그를 사용하여 IP 트래픽 로깅](flow-logs.md) 단원을 참조하세요.
+ **트래픽 미러링**: Amazon EC2 인스턴스의 탄력적 네트워크 인터페이스에서 네트워크 트래픽을 복사할 수 있습니다. 그런 다음 트래픽을 대역 외 보안 및 모니터링 어플라이언스에 보낼 수 있습니다. 자세한 내용은 [트래픽 미러링 안내서](https://docs.aws.amazon.com/vpc/latest/mirroring/)를 참조하세요.
# 전송 중 VPC 암호화 적용
VPC 암호화 제어는 트래픽 흐름의 암호화 상태를 모니터링하기 위한 신뢰할 수 있는 중앙 집중식 제어를 제공하고, 일반 텍스트 통신을 허용하는 리소스를 식별하고, 최종적으로 리전의 VPC 내부 및 전체에서 전송 중 암호화를 적용하는 메커니즘을 제공하는 보안 및 규정 준수 기능입니다.
VPC 암호화 제어는 애플리케이션 계층 암호화와 AWS Nitro System 하드웨어의 내장 전송 중 암호화 기능을 모두 사용하여 암호화 적용을 보장합니다. 또한 이 기능은 기본 하드웨어 계층 암호화를 최신 Nitro 인스턴스를 넘어 Fargate, Application Load Balancer, Transit Gateways 등의 다른 AWS 서비스로 확장합니다.
이 기능은 모든 트래픽의 암호화 상태를 파악하고 제어하려는 사용자를 위해 설계되었습니다. 특히 HIPAA, FedRamp, PCI DSS와 같은 규정 준수 표준을 충족하기 위해 데이터 암호화가 중요한 산업에서 유용합니다. 보안 관리자와 클라우드 아키텍트는 이를 사용하여 AWS 환경 전체에서 전송 중 암호화 정책을 중앙에서 적용할 수 있습니다.
이 기능은 모니터링 모드와 적용 모드의 두 가지 모드에서 사용할 수 있습니다.
## 암호화 제어 모드
**모니터링 모드**
모니터링 모드에서 암호화 제어는 VPC 내부 및 VPC 전체 AWS 리소스 간 트래픽 흐름의 암호화 상태에 대한 가시성을 제공합니다. 또한 전송 중 암호화를 적용하지 않는 VPC 리소스를 식별하는 데도 도움이 됩니다. 트래픽이 암호화되었는지 여부를 알려주는 보강 필드(`encryption-status`)를 내보내도록 VPC 흐름 로그를 구성할 수 있습니다. 콘솔 또는 `GetVpcResourcesBlockingEncryptionEnforcement` 명령을 사용하여 전송 중 암호화를 적용하지 않는 리소스를 식별할 수도 있습니다.
**참고**
기존 VPC는 먼저 모니터링 모드에서만 활성화할 수 있습니다. 이를 통해 일반 텍스트 트래픽을 허용하거나 허용할 수 있는 리소스를 파악할 수 있습니다. 이러한 리소스가 암호화를 적용하기 시작(또는 해당 리소스에 대한 제외 항목을 생성)한 후에만 VPC에서 적용 모드를 켤 수 있습니다.
**적용 모드**
적용 모드에서는 VPC 암호화 제어가 VPC 경계 내에서 암호화되지 않은 트래픽을 허용하는 기능 또는 서비스를 사용하지 못하도록 합니다. 기존 VPC에서는 적용 모드에서 암호화 제어를 직접 활성화할 수 없습니다. 먼저 모니터링 모드에서 암호화 제어를 켜고, 규정을 준수하지 않는 리소스를 식별 및 수정하여 전송 중 암호화를 적용한 다음 적용 모드를 켜야 합니다. 그러나 새 VPC의 경우 생성 중에 적용 모드에서 암호화 제어를 켤 수 있습니다.
적용 모드가 활성화되면 기본 내장 암호화 또는 인터넷 게이트웨이 등을 지원하지 않는 이전 EC2 인스턴스와 같이 암호화되지 않은 VPC 리소스를 생성하거나 연결할 수 없습니다. 암호화가 적용된 VPC에서 규정을 준수하지 않는 리소스를 실행하려면 해당 리소스에 대한 제외 항목을 생성해야 합니다.
## 트래픽 흐름의 암호화 상태 모니터링
VPC 흐름 로그의 `encryption-status` 필드를 사용하여 VPC 내 트래픽 흐름의 암호화 상태를 감사할 수 있습니다. 다음과 같은 값을 가질 수 있습니다.
+ `0` = 암호화되지 않음
+ `1` = Nitro로 암호화됨(VPC 암호화 제어에서 관리)
+ `2` = 애플리케이션으로 암호화됨
+ AWS 서비스에 대한 인터페이스 엔드포인트의 TCP 포트 443에서의 흐름 \$1
+ 게이트웨이 엔드포인트의 TCP 포트 443에서의 흐름 \$1
+ VPC 엔드포인트를 통해 암호화된 Redshift 클러스터로의 흐름 \$1\$1
+ `3` = Nitro와 애플리케이션 모두로 암호화됨
+ `(-)` = 암호화 상태 알 수 없음 또는 VPC 암호화 제어 꺼짐
**참고:**
\$1 인터페이스 및 게이트웨이 엔드포인트의 경우 AWS는 암호화 상태를 확인하기 위해 패킷 데이터를 살펴보지 않고, 대신 사용된 포트를 기반으로 암호화 상태를 추정합니다.
\$1\$1 지정된 AWS 관리형 엔드포인트의 경우 AWS는 서비스 구성의 TLS 요구 사항에 따라 암호화 상태를 확인합니다.
**VPC 흐름 로그 제한 사항**
+ VPC 암호화 제어에 대한 흐름 로그를 활성화하려면 encryption-status 필드가 포함된 새 흐름 로그를 수동으로 생성해야 합니다. encryption-status 필드는 기존 흐름 로그에 자동으로 추가되지 않습니다.
+ 흐름 로그에 더 자세한 내용을 포함하려면 흐름 로그에 \$1\$1traffic-path\$1 및 \$1\$1flow-direction\$1 필드를 추가하는 것이 좋습니다.
예제:
```
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-12345678901234567 \
--traffic-type ALL \
--log-group-name my-flow-logs \
--deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs
--log-format '${encryption-status} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${traffic-path} ${flow-direction} ${reject-reason}'
```
## VPC 암호화 제어 제외 항목
VPC 암호화 제어 적용 모드에서는 VPC의 모든 리소스에 암호화를 적용해야 합니다. 이렇게 하면 리전의 AWS 내에서 암호화가 보장됩니다. 그러나 사용자가 종단 간 암호화를 구성하고 유지 관리하는 AWS의 네트워크 외부에서 연결을 허용하는 인터넷 게이트웨이, NAT 게이트웨이 또는 가상 프라이빗 게이트웨이와 같은 리소스가 있을 수 있습니다. 암호화가 적용된 VPC에서 이러한 리소스를 실행하기 위해 리소스 제외 항목을 생성할 수 있습니다. 제외 항목은 고객이 암호화 유지 관리(일반적으로 애플리케이션 계층)를 담당하는 리소스에 대해 감사 가능한 예외를 생성합니다.
VPC 암호화 제어에서 지원되는 제외 항목은 단 8개입니다. VPC에 이러한 리소스가 있고 적용 모드로 전환하려는 경우, 모니터링 모드에서 적용 모드로 전환할 때 이러한 제외 항목을 추가해야 합니다. 다른 리소스는 제외할 수 없습니다. 이러한 리소스에 대한 제외 항목을 생성하여 VPC를 적용 모드로 마이그레이션할 수 있습니다. 이러한 리소스 간 트래픽 흐름의 암호화에 대한 책임은 사용자에게 있습니다.
+ 인터넷 게이트웨이
+ NAT 게이트웨이
+ 외부 전용 인터넷 게이트웨이
+ 암호화가 적용되지 않은 VPC에 대한 VPC 피어링 연결(자세한 시나리오는 VPC 피어링 지원 섹션 참조)
+ 가상 프라이빗 게이트웨이
+ VPC 내 Lambda 함수
+ VPC Lattice
+ Elastic File System
## 워크플로 구현
1. **모니터링 활성화** - 모니터링 모드에서 VPC 암호화 제어를 생성합니다.
1. **트래픽 분석** - 흐름 로그를 검토하여 트래픽 흐름의 암호화 상태를 모니터링합니다.
1. **리소스 분석** - 콘솔 또는 `GetVpcResourcesBlockingEncryptionEnforcement` 명령을 사용하여 전송 중 암호화를 적용하지 않는 리소스를 식별합니다.
1. **준비 [선택 사항]** - 적용 모드를 켜려는 경우 리소스 마이그레이션 및 필수 제외 항목을 계획합니다.
1. **적용 [선택 사항]** - 필수 제외 항목이 구성된 적용 모드로 전환합니다.
1. **감사** - 흐름 로그를 통해 지속적인 규정 준수 모니터링을 수행합니다.
자세한 설정 지침은 블로그 [VPC 암호화 제어 기능 소개: 리전 내 VPC 간 및 VPC 내 전송 중 암호화 적용](https://aws.amazon.com/blogs/aws/introducing-vpc-encryption-controls-enforce-encryption-in-transit-within-and-across-vpcs-in-a-region)을 참조하세요.
## VPC 암호화 제어 상태
VPC 암호화 제어는 다음 상태 중 하나일 수 있습니다.
**creating**
VPC 암호화 제어가 VPC에서 생성되고 있습니다.
**modify-in-progress**
VPC 암호화 제어가 VPC에서 수정되고 있습니다.
**삭제 중**
VPC 암호화 제어가 VPC에서 삭제되고 있습니다.
**available**
VPC 암호화 제어가 VPC에 모니터링 모드 또는 적용 모드를 성공적으로 구현했습니다.
## AWS 서비스 지원 및 호환성
암호화 규정을 준수하려면 리소스가 하드웨어 계층 또는 애플리케이션 계층에서 전송 중 암호화를 항상 적용해야 합니다. 대부분의 리소스의 경우 별도의 조치가 필요하지 않습니다.
### 자동 규정 준수를 제공하는 서비스
PrivateLink에서 지원하는 대부분의 AWS 서비스(교차 리전 PrivateLinks 포함)는 애플리케이션 계층에서 암호화된 트래픽을 허용합니다. 이러한 리소스를 변경할 필요는 없습니다. AWS는 애플리케이션 계층 암호화되지 않은 트래픽을 자동으로 차단합니다. Redshift 클러스터(프로비저닝 및 서버리스 모두 - 기본 리소스를 수동으로 마이그레이션해야 함) 등 몇 가지 예외가 있습니다.
### 자동으로 마이그레이션되는 리소스
Network Load Balancer, Application Load Balancer, Fargate 클러스터, EKS 컨트롤 플레인은 모니터링 모드를 켜면 암호화를 기본적으로 지원하는 하드웨어로 자동으로 마이그레이션됩니다. 이러한 리소스를 수정할 필요는 없습니다. AWS는 마이그레이션을 자동으로 처리합니다.
### 수동 마이그레이션이 필요한 리소스
특정 VPC 리소스 및 서비스에서는 기본 인스턴스 유형을 선택해야 합니다. 모든 최신 EC2 인스턴스는 전송 중 암호화를 지원합니다. 서비스에서 이미 최신 EC2 인스턴스를 사용하는 경우 변경할 필요가 없습니다. 콘솔 또는 GetVpcResourcesBlockingEncryptionEnforcement 명령을 사용하여 이러한 서비스에서 이전 인스턴스를 사용하고 있는지 확인할 수 있습니다. 이러한 리소스를 확인한 경우 Nitro System 하드웨어의 기본 암호화를 지원하는 최신 EC2 인스턴스로 업그레이드해야 합니다. 이러한 서비스에는 EC2 인스턴스, Auto Scaling 그룹, RDS(모든 데이터베이스 및 Document-DB), 프로비저닝된 Elasticache, Amazon Redshift 프로비저닝 클러스터, EKS, ECS-EC2, 프로비저닝된 OpenSearch, EMR이 포함됩니다.
**호환되는 리소스:**
다음 리소스는 VPC 암호화 제어와 호환됩니다.
+ [Nitro 기반 EC2 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit)
+ Network Load Balancer(제한 있음)
+ Application Load Balancers
+ AWS Fargate 클러스터
+ Amazon Elastic Kubernetes Service(EKS)
+ Amazon EC2 Auto Scaling 그룹
+ Amazon Relational Database Service(RDS - 모든 데이터베이스)
+ Amazon ElastiCache 노드 기반 클러스터
+ Amazon Redshift 프로비저닝된 클러스터 및 서버리스 클러스터
+ Amazon Elastic Container Service(ECS) - EC2 컨테이너 인스턴스
+ Amazon OpenSearch Service
+ Amazon Elastic MapReduce(EMR)
+ Amazon Managed Streaming for Apache Kafka(Amazon MSK)
+ VPC 암호화 제어는 PrivateLink를 통해 액세스하는 모든 AWS 서비스에 대해 애플리케이션 계층에서 암호화를 적용합니다. 애플리케이션 계층에서 암호화되지 않은 모든 트래픽은 적용 모드에서 암호화 제어를 사용하여 VPC 내에서 호스팅되는 PrivateLink 엔드포인트에 의해 차단됩니다.
### 서비스별 제한 사항
**Network Load Balancer 제한 사항**
TLS 구성: 포함된 VPC에서 암호화 제어를 적용하는 경우, TLS 리스너를 사용하여 암호화 및 복호화 작업을 로드 밸런서로 오프로드할 수 없습니다. 그러나 TLS 암호화 및 복호화를 수행하도록 대상을 구성할 수는 있습니다.
**Redshift 프로비저닝 및 서버리스**
고객은 기존 클러스터/엔드포인트가 있는 VPC에서 적용 모드로 이동할 수 없습니다. Redshift에서 VPC 암호화 제어를 사용하려면 스냅샷에서 클러스터 또는 네임스페이스를 복원해야 합니다. 프로비저닝된 클러스터의 경우 기존 Redshift 클러스터의 스냅샷을 생성한 다음 클러스터 스냅샷에서 복원 작업을 사용하여 스냅샷에서 복원하세요. 서버리스의 경우 기존 네임스페이스의 스냅샷을 생성한 다음 서버리스 작업 그룹에서 스냅샷에서 복원 작업을 사용하여 스냅샷에서 복원하세요. 스냅샷 및 복원 프로세스를 수행하지 않으면 기존 클러스터 또는 네임스페이스에서 VPC 암호화 제어를 활성화할 수 없습니다. 스냅샷 생성에 대해서는 [Amazon Redshift documentation](https://docs.aws.amazon.com/redshift/latest/mgmt/welcome.html)을 참조하세요.
**Amazon MSK(Managed streaming for Apache Kafka)**
이 기능은 자체 VPC 내 4.1 버전의 새 클러스터에서 지원됩니다. 다음 단계는 MSK에서 VPC 암호화를 사용하는 데 도움이 됩니다.
+ 고객이 다른 MSK 클러스터가 없는 VPC에서 VPC 암호화를 활성화합니다.
+ 고객이 Kafka 버전이 4.1이고 instancetype이 M7g인 클러스터를 생성합니다.
### 리전 및 영역 제한 사항
+ **로컬 영역 서브넷**: 적용 모드에서 지원되지 않으므로 VPC에서 삭제해야 합니다.
### VPC 피어링 지원
두 VPC 간의 VPC 피어링을 통한 전송 중 암호화를 보장하려면 두 VPC가 동일한 리전에 있어야 하며 제외 사항 없이 적용 모드에서 암호화 제어가 켜져 있어야 합니다. 암호화가 적용된 VPC를 다른 리전에 상주하거나 적용 모드(제외 항목 없음)에서 암호화 제어가 활성화되지 않은 다른 VPC와 피어링하려면 피어링 제외 항목을 생성해야 합니다.
두 VPC가 적용 모드이고 서로 피어링하는 경우 모드를 적용에서 모니터링으로 변경할 수 없습니다. VPC 암호화 제어 모드를 모니터링으로 수정하기 전에 먼저 피어링 제외 항목을 생성해야 합니다.
### Transit Gateway 암호화 지원
암호화 제어가 켜져 있는 VPC 간의 트래픽을 암호화하려면 Transit Gateway에서 암호화 지원을 명시적으로 활성화해야 합니다. 기존 Transit Gateway에서 암호화를 활성화해도 기존 트래픽 흐름은 중단되지 않으며 VPC 연결은 암호화된 경로로 원활하게 자동으로 마이그레이션됩니다. Transit Gateway를 통해 적용 모드(제외 항목 없음)에 있는 두 VPC 간의 트래픽은 100% 암호화된 경로를 통과합니다. 또한 Transit Gateway의 암호화를 사용하면 서로 다른 암호화 제어 모드에 있는 두 VPC도 연결할 수 있습니다. 암호화가 적용되지 않은 VPC에 연결된 VPC에서 암호화 제어를 적용하려는 경우 이를 사용해야 합니다. 이러한 시나리오에서는 암호화가 적용된 VPC 내의 모든 트래픽(VPC 간 트래픽을 포함)이 암호화됩니다. VPC 간 트래픽은 암호화가 적용된 VPC의 리소스와 Transit Gateway 간에 암호화됩니다. 그 외에도 암호화는 미적용 VPC에서 트래픽이 전송되는 리소스에 따라 달라지며 암호화가 보장되지 않습니다(VPC가 적용 모드가 아니기 때문). 모든 VPC는 동일한 리전에 있어야 합니다([여기에서](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-encryption-support.html) 세부 정보 참조).
![\[암호화 제어 상태가 다른 VPC 간의 트래픽 흐름\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/vpc-enc-control-arch.png)
+ 이 다이어그램에서 VPC 1, VPC 2, VPC3은 암호화 제어가 적용 모드로 설정되어 있으며, 모니터링 모드에서 실행되는 암호화 제어가 있는 VPC 4에 연결되어 있습니다.
+ VPC1, VPC2, VPC3 간의 모든 트래픽은 암호화됩니다.
+ 자세히 설명하면, VPC 1의 리소스와 VPC 4의 리소스 간의 모든 트래픽은 Nitro System 하드웨어에서 제공하는 암호화를 사용하여 Transit Gateway까지 암호화됩니다. 그 외에도 암호화 상태는 VPC 4의 리소스에 따라 달라지며 암호화가 보장되지 않습니다.
Transit Gateway 암호화 지원에 대한 자세한 내용은 [Transit Gateway 설명서](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-encryption-support.html)를 참조하세요.
## 가격 책정
요금에 관한 자세한 내용은 [Amazon VPC 요금](https://aws.amazon.com/vpc/pricing/)을 참조하세요.
## AWS CLI 명령 참조
### 설정 및 구성
+ [aws ec2 create-vpc-encryption-control](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpc-encryption-control.html)
+ [aws ec2 modify-vpc-encryption-control](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-vpc-encryption-control.html)
+ [aws ec2 tgw modify-transit-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-transit-gateway.html)
### 모니터링 및 문제 해결
+ [aws ec2 describe-vpc-encryption-controls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpc-encryption-controls.html)
+ [aws ec2 get-vpc-resources-blocking-encryption-enforcement](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-vpc-resources-blocking-encryption-enforcement.html)
+ [aws ec2 create-flow-logs](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-flow-logs.html)
+ [aws ec2 describe-flow-logs](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-flow-logs.html)
+ [aws logs query](https://docs.aws.amazon.com/cli/latest/reference/logs/query.html)
### 정리
+ [aws ec2 delete-vpc-encryption-control](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-vpc-encryption-control.html)
## 추가 리소스
자세한 설정 지침은 블로그 [VPC 암호화 제어 기능 소개: 리전 내 VPC 간 및 VPC 내 전송 중 암호화 적용](https://aws.amazon.com/blogs/aws/introducing-vpc-encryption-controls-enforce-encryption-in-transit-within-and-across-vpcs-in-a-region)을 참조하세요.
API에 대한 자세한 내용은 [EC2 API 참조 안내서](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.html)를 참조하세요.
# Amazon VPC용 자격 증명 및 액세스 관리
AWS Identity and Access Management(IAM)는 관리자가 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있도록 지원하는 AWS 서비스입니다. IAM 관리자는 어떤 사용자가 Amazon VPC 리소스를 사용할 수 있는 *인증*(로그인) 및 *권한*(권한 있음)을 받을 수 있는지를 제어합니다. IAM은 추가 비용 없이 사용할 수 있는 AWS 서비스입니다.
**Topics**
+ [대상](#security_iam_audience)
+ [ID로 인증](#security_iam_authentication)
+ [정책을 사용하여 액세스 관리](#security_iam_access-manage)
+ [Amazon VPC가 IAM과 작동하는 방식](security_iam_service-with-iam.md)
+ [Amazon VPC 정책 예시](vpc-policy-examples.md)
+ [Amazon VPC 자격 증명 및 액세스 문제 해결](security_iam_troubleshoot.md)
+ [Amazon Virtual Private Cloud에 대한 AWS 관리형 정책](security-iam-awsmanpol.md)
+ [VPC에 서비스 링크 역할 사용](using-service-linked-roles.md)
## 대상
AWS Identity and Access Management(IAM)를 사용하는 방법은 Amazon VPC에서 수행하는 작업에 따라 달라집니다.
**서비스 사용자** – Amazon VPC 서비스를 사용하여 작업을 수행하는 경우 필요한 자격 증명과 권한을 관리자가 제공합니다. 다른 Amazon VPC 기능을 사용하여 작업을 수행한다면 추가 권한이 필요할 수 있습니다. 액세스 권한 관리 방식을 이해하면 적절한 권한을 관리자에게 요청할 수 있습니다. Amazon VPC의 기능에 액세스할 수 없다면 [Amazon VPC 자격 증명 및 액세스 문제 해결](security_iam_troubleshoot.md)를 참조하세요.
**서비스 관리자** – 회사에서 Amazon VPC 리소스를 책임지고 있다면 사용하는 서비스에 대한 완전한 액세스 권한이 있을 것입니다. 서비스 관리자는 직원이 액세스해야 하는 Amazon VPC 기능과 리소스를 결정합니다. IAM 관리자에게 요청을 제출하여 서비스 사용자의 권한을 변경합니다. 이 페이지의 정보를 검토하여 IAM의 기본 개념을 이해하십시오. 회사가 Amazon VPC에서 IAM을 사용하는 방법에 대해 자세히 알아보려면 [Amazon VPC가 IAM과 작동하는 방식](security_iam_service-with-iam.md)을 참조하세요.
**IAM 관리자** - IAM 관리자라면 Amazon VPC에 대한 액세스 권한 관리 정책 작성 방법을 자세히 알고 싶을 것입니다. 정책 예시를 보려면 [Amazon VPC 정책 예시](vpc-policy-examples.md)를 참조하세요.
## ID로 인증
인증은 ID 자격 증명을 사용하여 AWS에 로그인하는 방식입니다. AWS 계정 루트 사용자이나 IAM 사용자로, 또는 IAM 역할을 수임하여 인증(에 로그인)받아야 합니다.
AWS IAM Identity Center(IAM Identity Center), Single Sign-On 인증 또는 Google/Facebook 자격 증명과 같은 자격 증명 소스의 자격 증명을 사용하여 페더레이션 ID로 로그인할 수 있습니다. 로그인하는 방법에 대한 자세한 내용은 *AWS Sign-In사용 설명서*의 [AWS 계정에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 섹션을 참조하세요.
프로그래밍 방식 액세스를 위해 AWS는 요청에 암호화 방식으로 서명할 수 있는 SDK 및 CLI를 제공합니다. 자세한 내용은 *IAM 사용 설명서*의 [API 요청용 AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) 섹션을 참조하세요.
### AWS 계정 루트 사용자
AWS 계정을 생성하는 경우에는 모든 AWS 서비스 서비스와 리소스에 대한 완전한 액세스 권한이 있는 AWS 계정 *루트 사용자*라는 단일 로그인 ID로 시작합니다. 일상적인 태스크에 루트 사용자를 사용하지 않을 것을 강력히 권장합니다. 루트 사용자가 필요한 작업 목록은 *IAM 사용자 설명서*의 [루트 사용자 자격 증명이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)을 참조하세요.
### IAM 사용자 및 그룹
*[IAM 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*는 단일 개인 또는 애플리케이션에 대한 특정 권한을 가진 ID입니다. 장기 자격 증명이 있는 IAM 사용자 대신 임시 자격 증명을 사용하는 것이 좋습니다. 자세한 내용은 *IAM 사용 설명서*에서 [임시 자격 증명을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 제공업체와의 페더레이션을 사용하도록 요구](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)를 참조하세요.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)은 IAM 사용자 모음을 지정하고 대규모 사용자 집합에 대한 관리 권한을 더 쉽게 만듭니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM 사용자 사용 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) 섹션을 참조하세요.
### IAM 역할
*[IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*은 임시 자격 증명을 제공하는 특정 권한이 있는 자격 증명입니다. [사용자에서 IAM 역할(콘솔)로 전환](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)하거나 AWS CLI 또는 AWS API 작업을 직접적으로 호출하여 역할을 수임할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [역할 수임 방법](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)을 참조하세요.
IAM 역할은 페더레이션 사용자 액세스, 임시 IAM 사용자 권한, 교차 계정 액세스, 교차 서비스 액세스 및 Amazon EC2에서 실행되는 애플리케이션에 유용합니다. 자세한 내용은 *IAM 사용 설명서*의 [교차 계정 리소스 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)를 참조하세요.
## 정책을 사용하여 액세스 관리
정책을 생성하고 AWS ID 또는 리소스에 연결하여 AWS에서 내 액세스를 제어합니다. 정책은 자격 증명이나 리소스와 연결될 때 해당 권한을 정의합니다. AWS는 보안 주체가 요청을 보낼 때 이러한 정책을 평가합니다. 대부분의 정책은 AWS에 JSON 문서로 저장됩니다. JSON 정책 문서에 대한 자세한 내용은 *IAM 사용 설명서*의 [JSON 정책 개요](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) 섹션을 참조하세요.
정책을 사용하여 관리자는 어떤 **보안 주체**가 어떤 **리소스**에 대해 어떤 **조건**에서 **작업**을 수행할 수 있는지 정의하여 누가 무엇을 액세스할 수 있는지 지정합니다.
기본적으로 사용자 및 역할에는 어떠한 권한도 없습니다. IAM 관리자는 IAM 정책을 생성하고 사용자가 수임할 수 있는 역할에 추가합니다. IAM 정책은 작업을 수행하기 위해 사용하는 방법과 관계없이 작업에 대한 권한을 정의합니다.
### ID 기반 정책
ID 기반 정책은 ID(사용자, 사용자 그룹 또는 역할)에 연결하는 JSON 권한 정책 문서입니다. 이러한 정책은 자격 증명이 수행할 수 있는 작업, 대상 리소스 및 이에 관한 조건을 제어합니다. ID 기반 정책을 생성하는 방법을 알아보려면 *IAM 사용 설명서*에서 [고객 관리형 정책으로 사용자 지정 IAM 권한 정의](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)를 참조하세요.
ID 기반 정책은 *인라인 정책*(단일 ID에 직접 포함) 또는 *관리형 정책*(여러 ID에 연결된 독립 실행형 정책)일 수 있습니다. 관리형 정책 또는 인라인 정책을 선택하는 방법을 알아보려면 *IAM 사용 설명서*의 [관리형 정책 및 인라인 정책 중에서 선택](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) 섹션을 참조하세요.
### 리소스 기반 정책
리소스 기반 정책은 리소스에 연결하는 JSON 정책 설명서입니다. 예를 들어 IAM *역할 신뢰 정책* 및 Amazon S3 *버킷 정책*이 있습니다. 리소스 기반 정책을 지원하는 서비스에서 서비스 관리자는 이러한 정책을 사용하여 특정 리소스에 대한 액세스를 통제할 수 있습니다. 리소스 기반 정책에서 [보안 주체를 지정](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)해야 합니다.
리소스 기반 정책은 해당 서비스에 있는 인라인 정책입니다. 리소스 기반 정책에서는 IAM의 AWS 관리형 정책을 사용할 수 없습니다.
### 액세스 제어 목록(ACL)
액세스 제어 목록(ACL)은 어떤 위탁자(계정 멤버, 사용자 또는 역할)가 리소스에 액세스할 수 있는 권한을 가지고 있는지를 제어합니다. ACLs는 JSON 정책 문서 형식을 사용하지 않지만 리소스 기반 정책과 유사합니다.
Amazon S3, AWS WAF 및 Amazon VPC는 ACL을 지원하는 대표적인 서비스입니다. ACL에 관한 자세한 내용은 *Amazon Simple Storage Service 개발자 가이드*의 [액세스 제어 목록(ACL) 개요](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)를 참조하세요.
### 기타 정책 유형
AWS는 이러한 정책 타입이 부여하는 최대 권한을 설정할 수 있는 추가 정책 타입을 지지합니다.
+ **권한 경계** - ID 기반 정책에서 IAM 엔터티에 부여할 수 있는 최대 권한을 설정합니다. 자세한 정보는 *IAM 사용 설명서*의 [IAM 엔터티의 권한 범위](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)를 참조하세요.
+ **서비스 제어 정책(SCP)** - AWS Organizations내 조직 또는 조직 단위에 대한 최대 권한을 지정합니다. 자세한 내용은 AWS Organizations사용 설명서의 [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 참조하세요.**
+ **리소스 제어 정책(RCP)** – 계정의 리소스에 사용할 수 있는 최대 권한을 설정합니다. 자세한 내용은 *AWS Organizations사용 설명서*의 [리소스 제어 정책(RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)을 참조하세요.
+ **세션 정책** – 역할 또는 페더레이션 사용자에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. 자세한 내용은 *IAM 사용 설명서*의 [세션 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)을 참조하세요.
### 여러 정책 유형
여러 정책 유형이 요청에 적용되는 경우, 결과 권한은 이해하기가 더 복잡합니다. 여러 정책 유형이 관련될 때 AWS가 요청을 허용할지 여부를 결정하는 방법을 알아보려면 *IAM 사용 설명서*의 [정책 평가 로직](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)을 참조하세요.
# Amazon VPC가 IAM과 작동하는 방식
IAM을 사용하여 Amazon VPC에 대한 액세스를 관리하기 전에 Amazon VPC에서 사용할 수 있는 IAM 기능을 이해해야 합니다. Amazon VPC 및 기타 AWS 서비스에서 IAM을 사용하는 방법을 개괄적으로 알아보려면 *IAM 사용 설명서*의 [IAM으로 작업하는 AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하세요.
**Topics**
+ [작업](#security_iam_service-with-iam-id-based-policies-actions)
+ [리소스](#security_iam_service-with-iam-id-based-policies-resources)
+ [조건 키](#security_iam_service-with-iam-id-based-policies-conditionkeys)
+ [Amazon VPC 리소스 기반 정책](#security_iam_service-with-iam-resource-based-policies)
+ [태그 기반 권한 부여](#security_iam_service-with-iam-tags)
+ [IAM 역할](#security_iam_service-with-iam-roles)
IAM 자격 증명 기반 정책을 사용하면 허용 또는 거부된 작업을 지정할 수 있습니다. 일부 작업의 경우 작업이 허용 또는 거부되는 리소스 및 조건을 지정할 수 있습니다. Amazon VPC는 특정 작업, 리소스 및 조건 키를 지원합니다. JSON 정책에서 사용하는 모든 요소에 대해 알아보려면 *IAM 사용자 설명서*의 [IAM JSON 정책 요소 참조](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)를 참조하세요.
## 작업
관리자는 AWSJSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지를 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
JSON 정책의 `Action`요소는 정책에서 액세스를 허용하거나 거부하는 데 사용할 수 있는 작업을 설명합니다. 연결된 작업을 수행할 수 있는 권한을 부여하기 위한 정책에 작업을 포함하세요.
Amazon VPC는 API 네임스페이스를 Amazon EC2와 공유합니다. Amazon VPC의 정책 작업은 작업 앞에 `ec2:` 접두사를 사용합니다. 예를 들어 `CreateVpc` API 작업을 사용하여 사용자에게 VPC를 생성할 수 있는 권한을 부여하려면 `ec2:CreateVpc` 작업에 대한 액세스 권한을 부여합니다. 정책 설명에는 `Action` 또는 `NotAction` 요소가 반드시 추가되어야 합니다.
단일 명령문에서 여러 작업을 지정하려면 다음 예시와 같이 쉼표로 구분합니다.
```
"Action": [
"ec2:action1",
"ec2:action2"
]
```
와일드카드(\$1)를 사용하여 여러 작업을 지정할 수 있습니다. 예를 들어, `Describe`라는 단어로 시작하는 모든 작업을 지정하려면 다음 작업을 포함합니다.
```
"Action": "ec2:Describe*"
```
Amazon VPC 작업 목록을 보려면 *서비스 승인 참조*의 [Amazon EC2에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-actions-as-permissions)을 참조하세요.
## 리소스
관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지를 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
`Resource` JSON 정책 요소는 작업이 적용되는 하나 이상의 객체를 지정합니다. 모범 사례에 따라 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)을 사용하여 리소스를 지정합니다. 리소스 수준 권한을 지원하지 않는 작업의 경우, 와일드카드(\$1)를 사용하여 해당 문이 모든 리소스에 적용됨을 나타냅니다.
```
"Resource": "*"
```
VPC 리소스에는 다음 예시와 같이 ARN이 있습니다.
```
arn:${Partition}:ec2:${Region}:${Account}:vpc/${VpcId}
```
예를 들어, 명령문에서 `vpc-1234567890abcdef0` VPC를 지정하려면 다음 예시에 표시된 ARN을 사용합니다.
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:vpc/vpc-1234567890abcdef0"
```
특정 리전에서 특정 계정에 속하는 모든 VPC를 지정하려면 와일드카드(\$1)를 사용합니다.
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:vpc/*"
```
리소스 생성 작업과 같은 일부 Amazon VPC 작업은 특정 리소스에서 수행할 수 없습니다. 이러한 경우 와일드카드(\$1)를 사용해야 합니다.
```
"Resource": "*"
```
다양한 Amazon EC2 API 작업에는 여러 리소스가 관여합니다. 단일 문에서 여러 리소스를 지정하려면 ARN을 쉼표로 구분합니다.
```
"Resource": [
"resource1",
"resource2"
]
```
Amazon VPC 리소스 유형 및 해당 ARN 목록을 보려면 *서비스 승인 참조*의 [Amazon EC2에서 정의한 리소스 유형](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-resources-for-iam-policies)을 참조하세요.
## 조건 키
관리자는 AWSJSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지를 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
`Condition` 요소는 정의된 기준에 따라 문이 실행되는 시기를 지정합니다. 같음(equals) 또는 미만(less than)과 같은 [조건 연산자](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)를 사용하여 정책의 조건을 요청의 값과 일치시키는 조건식을 생성할 수 있습니다. 모든 AWS 전역 조건 키를 보려면 *IAM 사용자 설명서*의 [AWS 전역 조건 컨텍스트 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)를 참조하세요.
모든 Amazon EC2 작업은 `aws:RequestedRegion` 및 `ec2:Region` 조건 키를 지원합니다. 자세한 내용은 [예: 특정 리전에 대한 액세스 제한](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region)을 참조하세요.
Amazon VPC는 자체 조건 키 세트를 정의하며 일부 전역 조건 키 사용도 지원합니다. Amazon VPC 조건 키 목록을 보려면 *서비스 승인 참조*의 [Amazon EC2에 사용되는 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-policy-keys)를 참조하세요. 조건 키를 사용할 수 있는 작업과 리소스를 알아보려면 [Amazon EC2에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-actions-as-permissions)을 참조하세요.
## Amazon VPC 리소스 기반 정책
리소스 기반 정책은 지정된 보안 주체가 Amazon VPC 리소스에 대해 수행할 수 있는 작업 및 관련 조건을 지정하는 JSON 정책 문서입니다.
교차 계정 액세스를 활성화하려는 경우 전체 계정이나 다른 계정의 IAM 개체를 [리소스 기반 정책의 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)로 지정할 수 있습니다. 리소스 기반 정책에 교차 계정 위탁자를 추가하는 것은 트러스트 관계 설정의 절반밖에 되지 않는다는 것을 유념하세요. 위탁자와 리소스가 다른 AWS 계정에 있는 경우 위탁자 엔터티가 리소스에 액세스할 권한도 부여해야 합니다. 엔터티에 자격 증명 기반 정책을 연결하여 권한을 부여합니다. 하지만 리소스 기반 정책이 동일 계정의 위탁자에 액세스를 부여하는 경우 추가 자격 증명 기반 정책이 필요하지 않습니다. 자세한 내용은 IAM 사용 설명서**의 [교차 계정 리소스 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)를 참조하세요.
## 태그 기반 권한 부여
태그를 Amazon VPC 리소스에 연결하거나 요청을 통해 태그를 전달할 수 있습니다. 태그를 기반으로 액세스를 제어하려면 조건 키를 사용하여 정책의 [조건 요소](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)에 태그 정보를 제공합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [생성 시 리소스 태깅에 대한 권한 부여](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/supported-iam-actions-tagging.html)를 참조하세요.
리소스의 태그를 기반으로 리소스에 대한 액세스를 제한하는 자격 증명 기반 정책의 예시는 [특정 VPC로 인스턴스 시작](vpc-policy-examples.md#subnet-ami-example-iam)에서 확인할 수 있습니다.
## IAM 역할
[IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)은 특정 권한을 가지고 있는 AWS 계정 내 엔터티입니다.
### 임시 자격 증명 사용
임시 자격 증명을 사용하여 페더레이션을 통해 로그인하거나, IAM 역할을 맡거나, 교차 계정 역할을 맡을 수 있습니다. [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) 또는 [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) 같은 AWS STS API 작업을 호출하여 임시 보안 자격 증명을 가져옵니다.
Amazon VPC는 임시 자격 증명 사용을 지원합니다.
### 서비스 연결 역할
[서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)을 사용하면 AWS 서비스에서 다른 서비스의 리소스에 액세스하여 사용자 대신 작업을 완료할 수 있습니다. 서비스 연결 역할은 IAM 계정에 나타나고 서비스가 소유합니다. IAM 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집은 할 수 없습니다.
[전송 게이트웨이](https://docs.aws.amazon.com/vpc/latest/tgw/service-linked-roles.html)는 서비스 연결 역할을 지원합니다.
### 서비스 역할
이 기능을 사용하면 서비스가 사용자를 대신하여 [서비스 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)을 수임할 수 있습니다. 이 역할을 사용하면 서비스가 다른 서비스의 리소스에 액세스해 사용자를 대신해 작업을 완료할 수 있습니다. 서비스 역할은 IAM 계정에 나타나고, 해당 계정이 소유합니다. 즉, IAM 관리자가 이 역할에 대한 권한을 변경할 수 있습니다. 그러나 권한을 변경하면 서비스의 기능이 손상될 수 있습니다.
Amazon VPC는 흐름 로그에 대한 서비스 역할을 지원합니다. 흐름 로그를 만들 때 흐름 로그 서비스에서 CloudWatch Logs에 액세스할 수 있는 역할을 선택해야 합니다. 자세한 내용은 [CloudWatch Logs에 흐름 로그를 게시하는 IAM 역할](flow-logs-iam-role.md) 단원을 참조하세요.
# Amazon VPC 정책 예시
기본적으로 IAM 역할은 VPC 리소스를 생성하거나 수정할 수 있는 권한이 없습니다. 또한 AWS Management Console, AWS CLI 또는 AWS API를 사용해 태스크를 수행할 수 없습니다. IAM 관리자는 지정된 리소스에서 특정 API 작업을 수행할 수 있는 권한을 역할에 부여하는 IAM 정책을 생성해야 합니다. 그런 다음 관리자는 해당 권한이 필요한 IAM 역할에 이러한 정책을 연결해야 합니다.
이러한 예시 JSON 정책 문서를 사용하여 IAM 자격 증명 기반 정책을 생성하는 방법을 알아보려면 *IAM 사용 설명서*의 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)을 참조하세요.
**Topics**
+ [정책 모범 사례](#security_iam_service-with-iam-policy-best-practices)
+ [Amazon VPC 콘솔 사용](#security_iam_id-based-policy-examples-console)
+ [퍼블릭 서브넷이 포함된 VPC 만들기](#vpc-public-subnet-iam)
+ [VPC 리소스 수정 및 삭제](#modify-vpc-resources-iam)
+ [보안 그룹 관리](#vpc-security-groups-iam)
+ [보안 그룹 규칙 관리](#vpc-security-group-rules-iam)
+ [특정 서브넷으로 인스턴스 시작](#subnet-sg-example-iam)
+ [특정 VPC로 인스턴스 시작](#subnet-ami-example-iam)
+ [VPC 및 서브넷에 대한 퍼블릭 액세스 차단](#vpc-bpa-example-iam)
+ [추가 Amazon VPC 정책 예시](#security-iam-additional-examples)
## 정책 모범 사례
ID 기반 정책에 따라 계정에서 사용자가 Amazon VPC 리소스를 생성, 액세스 또는 삭제할 수 있는지 여부가 결정됩니다. 이 작업으로 인해 AWS 계정에 비용이 발생할 수 있습니다. ID 기반 정책을 생성하거나 편집할 때는 다음 지침과 권장 사항을 따르세요.
+ **AWS 관리형 정책으로 시작하고 최소 권한을 향해 나아가기** - 사용자 및 워크로드에 권한 부여를 시작하려면 많은 일반 사용 사례에 대한 권한을 부여하는 *AWS관리형 정책*을 사용합니다. AWS 계정에서 사용할 수 있습니다. 사용 사례에 고유한 AWS고객 관리형 정책을 정의하여 권한을 줄이는 것이 좋습니다. 자세한 내용은 *IAM 사용 설명서*의 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) 또는 [AWS직무에 대한 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)을 참조하세요.
+ **최소 권한 적용** – IAM 정책을 사용하여 권한을 설정하는 경우, 작업을 수행하는 데 필요한 권한만 부여합니다. 이렇게 하려면 *최소 권한*으로 알려진 특정 조건에서 특정 리소스에 대해 수행할 수 있는 작업을 정의합니다. IAM을 사용하여 권한을 적용하는 방법에 대한 자세한 정보는 *IAM 사용 설명서*에 있는 [IAM의 정책 및 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)을 참조하세요.
+ **IAM 정책의 조건을 사용하여 액세스 추가 제한** – 정책에 조건을 추가하여 작업 및 리소스에 대한 액세스를 제한할 수 있습니다. 예를 들어, SSL을 사용하여 모든 요청을 전송해야 한다고 지정하는 정책 조건을 작성할 수 있습니다. CloudFormation와 같이, 특정 AWS 서비스를 통해 사용되는 경우에만 서비스 작업에 대한 액세스 권한을 부여할 수도 있습니다. 자세한 내용은 *IAM 사용자 설명서*의 [IAM JSON 정책 요소: 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)을 참조하세요.
+ **IAM Access Analyzer를 통해 IAM 정책을 확인하여 안전하고 기능적인 권한 보장** - IAM Access Analyzer에서는 IAM 정책 언어(JSON)와 모범 사례가 정책에서 준수되도록 새로운 및 기존 정책을 확인합니다. IAM Access Analyzer는 100개 이상의 정책 확인 항목과 실행 가능한 추천을 제공하여 안전하고 기능적인 정책을 작성하도록 돕습니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM Access Analyzer에서 정책 검증](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)을 참조하세요.
+ **다중 인증(MFA) 필요** – AWS 계정에 IAM 사용자 또는 루트 사용자가 필요한 시나리오가 있는 경우, 추가 보안을 위해 MFA를 설정합니다. API 작업을 직접적으로 호출할 때 MFA가 필요하면 정책에 MFA 조건을 추가합니다. 자세한 내용은 *IAM 사용 설명서*의 [MFA를 통한 보안 API 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)를 참조하세요.
IAM의 모범 사례에 대한 자세한 내용은 *IAM 사용 설명서*의 [IAM의 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)를 참조하세요.
## Amazon VPC 콘솔 사용
Amazon VPC 콘솔에 액세스하려면 최소한의 권한 집합이 있어야 합니다. 이러한 권한은 AWS 계정에서 Amazon VPC 리소스에 대한 세부 정보를 나열하고 볼 수 있도록 허용해야 합니다. 최소 필수 권한보다 더 제한적인 자격 증명 기반 정책을 만들면 콘솔이 해당 정책에 연결된 개체(IAM 역할)에 대해 의도대로 작동하지 않습니다.
다음 정책은 VPC 콘솔에 리소스를 나열할 수 있는 권한을 역할에 부여하지만 리소스를 생성, 업데이트 또는 삭제할 수는 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeAccountAttributes",
"ec2:DescribeAddresses",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeClassicLinkInstances",
"ec2:DescribeClientVpnEndpoints",
"ec2:DescribeCustomerGateways",
"ec2:DescribeDhcpOptions",
"ec2:DescribeEgressOnlyInternetGateways",
"ec2:DescribeFlowLogs",
"ec2:DescribeInternetGateways",
"ec2:DescribeManagedPrefixLists",
"ec2:DescribeMovingAddresses",
"ec2:DescribeNatGateways",
"ec2:DescribeNetworkAcls",
"ec2:DescribeNetworkInterfaceAttribute",
"ec2:DescribeNetworkInterfacePermissions",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribePrefixLists",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroupReferences",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeStaleSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeTrafficMirrorFilters",
"ec2:DescribeTrafficMirrorSessions",
"ec2:DescribeTrafficMirrorTargets",
"ec2:DescribeTransitGateways",
"ec2:DescribeTransitGatewayVpcAttachments",
"ec2:DescribeTransitGatewayRouteTables",
"ec2:DescribeVpcAttribute",
"ec2:DescribeVpcClassicLink",
"ec2:DescribeVpcClassicLinkDnsSupport",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcEndpointConnectionNotifications",
"ec2:DescribeVpcEndpointConnections",
"ec2:DescribeVpcEndpointServiceConfigurations",
"ec2:DescribeVpcEndpointServicePermissions",
"ec2:DescribeVpcEndpointServices",
"ec2:DescribeVpcPeeringConnections",
"ec2:DescribeVpcs",
"ec2:DescribeVpnConnections",
"ec2:DescribeVpnGateways",
"ec2:GetManagedPrefixListAssociations",
"ec2:GetManagedPrefixListEntries"
],
"Resource": "*"
}
]
}
```
------
AWS CLI 또는 AWS API만 호출하는 역할에는 최소 콘솔 권한을 허용할 필요가 없습니다. 그 대신, 역할이 수행해야 하는 API 작업과 일치하는 작업에만 액세스를 허용합니다.
## 퍼블릭 서브넷이 포함된 VPC 만들기
다음 예시에서는 역할이 VPC, 서브넷, 라우팅 테이블 및 인터넷 게이트웨이를 만들 수 있도록 설정합니다. 또한 역할은 인터넷 게이트웨이를 VPC에 연결하고 라우팅 테이블에 라우팅을 생성할 수 있습니다. `ec2:ModifyVpcAttribute` 작업을 통해 역할은 VPC로 시작된 각 인스턴스가 DNS 호스트 이름을 수신할 수 있도록 VPC에 대한 DNS 호스트 이름을 활성화합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:CreateVpc",
"ec2:CreateSubnet",
"ec2:DescribeAvailabilityZones",
"ec2:CreateRouteTable",
"ec2:CreateRoute",
"ec2:CreateInternetGateway",
"ec2:AttachInternetGateway",
"ec2:AssociateRouteTable",
"ec2:ModifyVpcAttribute"
],
"Resource": "*"
}
]
}
```
------
또한 위의 정책은 역할이 Amazon VPC 콘솔에서 VPC를 생성할 수 있도록 허용합니다.
## VPC 리소스 수정 및 삭제
역할이 수정하거나 삭제할 수 있는 VPC 리소스를 제어할 수 있습니다. 예를 들어 역할은 다음 정책을 통해 `Purpose=Test` 태그가 있는 라우팅 테이블에서 작업하고 삭제할 수 있습니다. 또한 이 정책은 역할이 `Purpose=Test` 태그가 있는 인터넷 게이트웨이를 삭제할 수만 있도록 지정합니다. 역할은 이 태그가 없는 라우팅 테이블 또는 인터넷 게이트웨이를 사용할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DeleteInternetGateway",
"Resource": "arn:aws:ec2:*:*:internet-gateway/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Purpose": "Test"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteRouteTable",
"ec2:CreateRoute",
"ec2:ReplaceRoute",
"ec2:DeleteRoute"
],
"Resource": "arn:aws:ec2:*:*:route-table/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Purpose": "Test"
}
}
}
]
}
```
------
## 보안 그룹 관리
다음 정책을 사용하여 역할은 보안 그룹을 관리할 수 있습니다. 첫 번째 문을 통해 역할은 `Stack=test` 태그가 있는 모든 보안 그룹을 삭제할 수 있고 `Stack=test` 태그가 있는 모든 보안 그룹에 대한 인바운드 및 아웃바운드 규칙을 관리할 수 있습니다. 두 번째 문은 역할이 `Stack=Test` 태그로 만든 보안 그룹에 태그를 지정하도록 요구합니다. 세 번째 문을 통해 역할은 보안 그룹을 만들 때 태그를 생성할 수 있습니다. 네 번째 문을 통해 역할은 모든 보안 그룹 및 보안 그룹 규칙을 볼 수 있습니다. 다섯 번째 문을 통해 역할은 VPC에서 보안 그룹을 생성할 수 있습니다.
**참고**
AWS CloudFormation 서비스에서 이 정책을 사용하여 필수 태그가 있는 보안 그룹을 생성할 수 없습니다. 태그가 필요한 `ec2:CreateSecurityGroup` 작업에서 조건을 제거하면 정책이 작동합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress",
"ec2:RevokeSecurityGroupEgress",
"ec2:DeleteSecurityGroup",
"ec2:ModifySecurityGroupRules",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress"
],
"Resource": "arn:aws:ec2:*:*:security-group/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Stack": "test"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:CreateSecurityGroup",
"Resource": "arn:aws:ec2:*:*:security-group/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Stack": "test"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "Stack"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:security-group/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateSecurityGroup"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:CreateSecurityGroup",
"Resource": "arn:aws:ec2:*:*:vpc/*"
}
]
}
```
------
역할이 인스턴스와 연결된 보안 그룹을 변경할 수 있도록 하려면 정책에 `ec2:ModifyInstanceAttribute` 작업을 추가합니다.
역할이 네트워크 인터페이스의 보안 그룹을 변경할 수 있도록 하려면 정책에 `ec2:ModifyNetworkInterfaceAttribute` 작업을 추가합니다.
## 보안 그룹 규칙 관리
다음 정책은 역할이 모든 보안 그룹 및 보안 그룹 규칙을 조회하고 특정 VPC의 보안 그룹에 대한 인바운드 및 아웃바운드 규칙을 추가 및 제거하며 지정된 VPC에 대한 규칙 설명을 수정할 권한을 부여합니다. 첫 번째 문은 `ec2:Vpc` 조건 키를 사용하여 특정 VPC 대한 권한 범위를 지정할 수 있습니다.
두 번째 문은 역할에 모든 보안 그룹, 보안 그룹 규칙 및 태그를 설명하는 권한을 부여합니다. 이를 통해 역할은 보안 그룹 규칙을 수정하기 위해 볼 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupIngress",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:RevokeSecurityGroupEgress",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress",
"ec2:ModifySecurityGroupRules"
],
"Resource": "arn:aws:ec2:us-east-1:123456789012:security-group/*",
"Condition": {
"ArnEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-1:123456789012:vpc/vpc-1234567890abcdef0"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:ModifySecurityGroupRules"
],
"Resource": "arn:aws:ec2:us-east-1:123456789012:security-group-rule/*"
}
]
}
```
------
## 특정 서브넷으로 인스턴스 시작
다음 정책은 역할에 인스턴스를 특정 서브넷으로 시작하고 요청에 특정 보안 그룹을 사용하는 권한을 부여합니다. 이 정책에서는 서브넷에 대한 ARN과 보안 그룹에 대한 ARN을 지정하여 이런 권한을 부여합니다. 역할이 다른 서브넷으로 인스턴스를 시작하거나 다른 보안 그룹을 사용하여 시작하려고 하면 (또 다른 정책 또는 설명문에서 역할에 그런 권한을 부여하지 않는 한) 요청이 실패하게 됩니다.
또한, 이 정책에서는 네트워크 인터페이스 리소스를 사용할 권한도 부여합니다. 서브넷으로 시작할 때 기본적으로 `RunInstances` 요청은 기본 네트워크 인터페이스를 생성하므로, 역할은 인스턴스를 시작할 때 이 리소스를 생성할 권한이 필요합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-*",
"arn:aws:ec2:us-east-1:123456789012:instance/*",
"arn:aws:ec2:us-east-1:123456789012:subnet/subnet-1234567890abcdef0",
"arn:aws:ec2:us-east-1:123456789012:network-interface/*",
"arn:aws:ec2:us-east-1:123456789012:volume/*",
"arn:aws:ec2:us-east-1:123456789012:key-pair/*",
"arn:aws:ec2:us-east-1:123456789012:security-group/sg-0abcdef1234567890"
]
}
]
}
```
------
## 특정 VPC로 인스턴스 시작
다음 정책에서는 역할에 특정 VPC 내에 있는 임의의 서브넷으로 인스턴스를 시작하는 권한을 부여합니다. 이 정책에서는 조건 키(`ec2:Vpc`)를 서브넷 리소스에 적용함으로써 이런 권한을 부여합니다.
또한, 이 정책에서는 역할에 "`department=dev`" 태그가 있는 AMI만 사용하여 인스턴스를 시작하는 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:123456789012:subnet/*",
"Condition": {
"ArnEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-1:123456789012:vpc/vpc-1234567890abcdef0"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1::image/ami-*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/department": "dev"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:123456789012:instance/*",
"arn:aws:ec2:us-east-1:123456789012:volume/*",
"arn:aws:ec2:us-east-1:123456789012:network-interface/*",
"arn:aws:ec2:us-east-1:123456789012:key-pair/*",
"arn:aws:ec2:us-east-1:123456789012:security-group/*"
]
}
]
}
```
------
## VPC 및 서브넷에 대한 퍼블릭 액세스 차단
다음 정책 예제에서는 VPC 및 서브넷의 리소스에 대한 퍼블릭 액세스를 차단할 수 있도록 [VPC 퍼블릭 액세스 차단(BPA) 기능](security-vpc-bpa.md)으로 작업할 수 있는 권한을 역할에 부여합니다.
예제 1 - VPC BPA 계정 전체 설정 및 VPC BPA 제외 항목에 대한 읽기 전용 액세스를 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VPCBPAReadOnlyAccess",
"Action": [
"ec2:DescribeVpcBlockPublicAccessOptions",
"ec2:DescribeVpcBlockPublicAccessExclusions"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
예제 2 - VPC BPA 계정 전체 설정 및 VPC BPA 제외 항목에 대한 전체 읽기 및 쓰기 액세스를 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VPCBPAFullAccess",
"Action": [
"ec2:DescribeVpcBlockPublicAccessOptions",
"ec2:DescribeVpcBlockPublicAccessExclusions",
"ec2:ModifyVpcBlockPublicAccessOptions",
"ec2:CreateVpcBlockPublicAccessExclusion",
"ec2:ModifyVpcBlockPublicAccessExclusion",
"ec2:DeleteVpcBlockPublicAccessExclusion"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
예제 3 - VPC BPA 설정 수정 및 제외 항목 생성을 제외한 모든 EC2 API에 대한 액세스를 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2FullAccess",
"Action": [
"ec2:*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "VPCBPAPartialAccess",
"Action": [
"ec2:ModifyVpcBlockPublicAccessOptions",
"ec2:CreateVpcBlockPublicAccessExclusion"
],
"Effect": "Deny",
"Resource": "*"
}
]
}
```
------
## 추가 Amazon VPC 정책 예시
다음 문서에서 Amazon VPC와 관련된 추가 IAM 정책 예시를 확인할 수 있습니다.
+ [관리형 접두사 목록](managed-prefix-lists.md#managed-prefix-lists-iam)
+ [트래픽 미러링](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-security.html)
+ [전송 게이트웨이](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-authentication-access-control.html#tgw-example-iam-policies)
+ [VPC 엔드포인트 및 VPC 엔드포인트 서비스(AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/security_iam_id-based-policy-examples.html)
+ [VPC 피어링](https://docs.aws.amazon.com/vpc/latest/peering/security-iam.html)
# Amazon VPC 자격 증명 및 액세스 문제 해결
다음 정보를 사용하여 Amazon VPC 및 IAM으로 작업할 때 발생할 수 있는 일반적인 문제를 진단하고 수정할 수 있습니다.
**Topics**
+ [Amazon VPC에서 작업을 수행할 권한이 없음](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole을 수행하도록 인증되지 않음](#security_iam_troubleshoot-passrole)
+ [내 AWS 계정 외부의 사용자가 내 Amazon VPC 리소스에 액세스할 수 있도록 허용하려고 합니다.](#security_iam_troubleshoot-cross-account-access)
## Amazon VPC에서 작업을 수행할 권한이 없음
AWS Management Console에서 작업을 수행할 권한이 없다는 메시지가 나타나는 경우 관리자에게 문의하여 도움을 받아야 합니다. 관리자는 로그인 보안 인증 정보를 제공한 사람입니다.
다음 오류 예는 `mateojackson` IAM 사용자가 콘솔을 사용하여 서브넷에 대한 세부 정보를 보려고 하지만 `ec2:DescribeSubnets` 권한이 없는 IAM 역할에 속하는 경우에 발생합니다.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: ec2:DescribeSubnets on resource: subnet-id
```
이 경우 Mateo는 관리자에게 정책을 업데이트하여 자신에게 서브넷에 대한 액세스를 허용하도록 요청합니다.
## iam:PassRole을 수행하도록 인증되지 않음
`iam:PassRole` 작업을 수행할 수 있는 권한이 없다는 오류가 수신되면 Amazon VPC에 역할을 전달할 수 있도록 정책을 업데이트해야 합니다.
일부 AWS 서비스에서는 새로운 서비스 역할 또는 서비스 연결 역할을 생성하는 대신 해당 서비스에 기존 역할을 전달할 수 있습니다. 이렇게 하려면 사용자가 서비스에 역할을 전달할 수 있는 권한을 가지고 있어야 합니다.
다음 예시 오류는 `marymajor`라는 IAM 사용자가 콘솔을 사용하여 Amazon VPC에서 작업을 수행하려고 하는 경우에 발생합니다. 하지만 작업을 수행하려면 서비스 역할이 부여한 권한이 서비스에 있어야 합니다. Mary는 서비스에 역할을 전달할 수 있는 권한을 가지고 있지 않습니다.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
이 경우, Mary가 `iam:PassRole`작업을 수행할 수 있도록 Mary의 정책을 업데이트해야 합니다.
도움이 필요한 경우 AWS 관리자에게 문의하세요. 관리자는 로그인 자격 증명을 제공한 사람입니다.
## 내 AWS 계정 외부의 사용자가 내 Amazon VPC 리소스에 액세스할 수 있도록 허용하려고 합니다.
다른 계정의 사용자 또는 조직 외부의 사람이 리소스에 액세스하는 데 사용할 수 있는 역할을 생성할 수 있습니다. 역할을 수임할 신뢰할 수 있는 사람을 지정할 수 있습니다. 리소스 기반 정책 또는 액세스 제어 목록(ACL)을 지원하는 서비스의 경우, 이러한 정책을 사용하여 다른 사람에게 리소스에 대한 액세스 권한을 부여할 수 있습니다.
자세히 알아보려면 다음을 참조하세요.
+ Amazon VPC에서 이러한 기능을 지원하는지 여부를 알아보려면 [Amazon VPC가 IAM과 작동하는 방식](security_iam_service-with-iam.md)을 참조하세요.
+ 소유하고 있는 AWS 계정의 리소스에 대한 액세스 권한을 제공하는 방법을 알아보려면 *IAM 사용 설명서*의 [자신이 소유한 다른 AWS 계정의 IAM 사용자에 대한 액세스 권한 제공](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)을 참조하세요.
+ 리소스에 대한 액세스 권한을 서드 파티 AWS 계정에게 제공하는 방법을 알아보려면 *IAM 사용 설명서*의 [서드 파티가 소유한 AWS 계정에 대한 액세스 제공](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)을 참조하세요.
+ ID 페더레이션을 통해 액세스 권한을 제공하는 방법을 알아보려면 *IAM 사용 설명서*의 [외부에서 인증된 사용자에게 액세스 권한 제공(ID 페더레이션)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)을 참조하세요.
+ 교차 계정 액세스에 대한 역할과 리소스 기반 정책 사용의 차이점을 알아보려면 *IAM 사용 설명서*의 [IAM의 크로스 계정 리소스 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)를 참조하세요.
# Amazon Virtual Private Cloud에 대한 AWS 관리형 정책
AWS 관리형 정책은 AWS에 의해 생성되고 관리되는 독립 실행형 정책입니다. AWS 관리형 정책은 사용자, 그룹 및 역할에 권한 할당을 시작할 수 있도록 많은 일반 사용 사례에 대한 권한을 제공하도록 설계되었습니다.
AWS 관리형 정책은 모든 AWS 고객이 사용할 수 있기 때문에 특정 사용 사례에 대해 최소 권한을 부여하지 않을 수 있습니다. 사용 사례에 고유한 [고객 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)을 정의하여 권한을 줄이는 것이 좋습니다.
AWS 관리형 정책에서 정의한 권한은 변경할 수 없습니다. 만약 AWS가 AWS 관리형 정책에 정의된 권한을 업데이트할 경우 정책이 연결되어 있는 모든 보안 주체 ID(사용자, 그룹 및 역할)에도 업데이트가 적용됩니다. 새 AWS 서비스을(를) 시작하거나 새 API 작업을 기존 서비스에 이용하는 경우, AWS가 AWS 관리형 정책을 업데이트할 가능성이 높습니다.
자세한 내용은 *IAM 사용 설명서*의 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)을 참조하세요.
## AWS 관리형 정책: AmazonVPCFullAccess
`AmazonVPCFullAccess` 정책을 IAM 자격 증명에 연결할 수 있습니다. 이 정책은 Amazon VPC 대한 전체 액세스를 허용하는 권한을 부여합니다.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*에서 [AmazonVPCFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonVPCFullAccess.html)를 참조하세요.
## AWS 관리형 정책: AmazonVPCReadOnlyAccess
`AmazonVPCReadOnlyAccess` 정책을 IAM 자격 증명에 연결할 수 있습니다. 이 정책은 Amazon VPC 대한 읽기 전용 액세스를 허용하는 권한을 부여합니다.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*에서 [AmazonVPCReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonVPCReadOnlyAccess.html)를 참조하세요.
## AWS 관리형 정책: AmazonVPCCrossAccountNetworkInterfaceOperations
`AmazonVPCCrossAccountNetworkInterfaceOperations` 정책을 IAM ID에 연결할 수 있습니다. 이 정책은 ID가 네트워크 인터페이스를 만들어 교차 계정 리소스에 연결할 수 있는 권한을 부여합니다.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*에서 [AmazonVPCCrossAccountNetworkInterfaceOperations](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonVPCCrossAccountNetworkInterfaceOperations.html)를 참조하세요.
## AWS 관리형 정책: AWSServiceRoleForNATGateway
`AWSServiceRoleForNATGateway` 정책을 IAM ID에 연결할 수 있습니다. 이 정책은 자격 증명이 사용자를 대신하여 리전 NAT 게이트웨이를 자동으로 규모 조정할 수 있는 권한을 부여합니다.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*의 [AWSServiceRoleForNATGateway](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForNATGateway.html)를 참조하세요.
## AWS 관리형 정책에 대한 Amazon VPC 업데이트
이 서비스가 2021년 3월에 이러한 변경 사항을 추적하기 시작한 이후 Amazon VPC용 AWS 관리형 정책 업데이트에 대한 세부 정보를 확인합니다.
| 변경 사항 | 설명 | 날짜 |
| --- | --- | --- |
| [AWS 관리형 정책: AmazonVPCFullAccess](#security-iam-awsmanpol-AmazonVPCFullAccess) - 기존 정책에 대한 업데이트 | IPAM이 관리형 접두사 목록을 수정하고 읽을 수 있도록 AWSIPAMServiceRolePolicy 관리형 정책(ec2:ModifyManagedPrefixList, ec2:DescribeManagedPrefixLists 및 ec2:GetManagedPrefixListEntries)에 작업을 추가했습니다. | 2025년 10월 31일 |
| [AWS 관리형 정책: AWSServiceRoleForNATGateway](#security-iam-awsmanpol-AWSServiceRoleForNATGateway) - 새 정책 | 새로운 AWSServiceRoleForNATGateway 정책은 자격 증명이 리전 NAT 게이트웨이를 자동으로 규모 조정할 수 있도록 허용합니다. | 2025년 11월 19일 |
| [AWS 관리형 정책: AmazonVPCFullAccess](#security-iam-awsmanpol-AmazonVPCFullAccess) - 기존 정책 업데이트 | VPC와 보안 그룹 연결을 연결, 연결 해제 및 볼 수 있는 AssociateSecurityGroupVpc, DescribeSecurityGroupVpcAssociations 및 DisassociateSecurityGroupVpc 작업이 추가되었습니다. | 2024년 12월 9일 |
| [AWS 관리형 정책: AmazonVPCReadOnlyAccess](#security-iam-awsmanpol-AmazonVPCReadOnlyAccess) - 기존 정책 업데이트 | VPC와 보안 그룹 연결을 볼 수 있는 DescribeSecurityGroupVpcAssociations 작업이 추가되었습니다. | 2024년 12월 9일 |
| [AWS 관리형 정책: AmazonVPCFullAccess](#security-iam-awsmanpol-AmazonVPCFullAccess) -기존 정책 업데이트 | VPC에서 사용할 수 있는 보안 그룹을 가져올 수 있는 GetSecurityGroupsForVpc 작업이 추가되었습니다. | 2024년 2월 8일 |
| [AWS 관리형 정책: AmazonVPCReadOnlyAccess](#security-iam-awsmanpol-AmazonVPCReadOnlyAccess) -기존 정책 업데이트 | VPC에서 사용할 수 있는 보안 그룹을 가져올 수 있는 GetSecurityGroupsForVpc 작업이 추가되었습니다. | 2024년 2월 8일 |
| [AWS 관리형 정책: AmazonVPCCrossAccountNetworkInterfaceOperations](#security-iam-awsmanpol-AmazonVPCCrossAccountNetworkInterfaceOperations) -기존 정책 업데이트 | AssignIpv6Addresses 및 UnassignIpv6Addresses 작업이 추가되었으며, 이를 통해 네트워크 인터페이스와 연결된 IPv6 주소를 관리할 수 있습니다. | 2023년 9월 25일 |
| [AWS 관리형 정책: AmazonVPCReadOnlyAccess](#security-iam-awsmanpol-AmazonVPCReadOnlyAccess) - 기존 정책 업데이트 | [보안 그룹 규칙](security-group-rules.md)을 볼 수 있는 DescribeSecurityGroupRules 작업이 추가되었습니다. | 2021년 8월 2일 |
| [AWS 관리형 정책: AmazonVPCFullAccess](#security-iam-awsmanpol-AmazonVPCFullAccess) - 기존 정책 업데이트 | [보안 그룹 규칙](security-group-rules.md)을 보고 수정할 수 있는 DescribeSecurityGroupRules 및 ModifySecurityGroupRules 작업이 추가되었습니다. | 2021년 8월 2일 |
| [AWS 관리형 정책: AmazonVPCFullAccess](#security-iam-awsmanpol-AmazonVPCFullAccess) - 기존 정책 업데이트 | 통신업체 게이트웨이, IPv6 풀, 로컬 게이트웨이 및 로컬 게이트웨이 라우팅 테이블에 대한 작업이 추가되었습니다. | 2021년 6월 23일 |
| [AWS 관리형 정책: AmazonVPCReadOnlyAccess](#security-iam-awsmanpol-AmazonVPCReadOnlyAccess) - 기존 정책 업데이트 | 통신업체 게이트웨이, IPv6 풀, 로컬 게이트웨이 및 로컬 게이트웨이 라우팅 테이블에 대한 작업이 추가되었습니다. | 2021년 6월 23일 |
# VPC에 서비스 링크 역할 사용
Amazon VPC는 AWS Identity and Access Management(IAM) [서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)을 사용합니다. 서비스 연결 역할은 VPC에 직접 연결되는 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 VPC에서 사전 정의되며 서비스에서 사용자를 대신하여 다른 AWS 서비스를 호출하기 위해 필요한 모든 권한을 포함합니다.
서비스 연결 역할을 사용하면 필요한 권한을 수동으로 추가할 필요가 없으므로 VPC를 더 쉽게 설정할 수 있습니다. VPC에서 서비스 연결 역할의 권한을 정의하므로 별도로 정의되지 않는 한 VPC만 해당 역할을 수임할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔터티에 연결할 수 없습니다.
먼저 관련 리소스를 삭제한 후에만 서비스 연결 역할을 삭제할 수 있습니다. 이렇게 하면 리소스에 대한 액세스 권한을 실수로 삭제할 수 없기 때문에 VPC 리소스가 보호됩니다.
서비스 연결 역할을 지원하는 기타 서비스에 대한 자세한 내용은 [AWS IAM으로 작업하는 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾으세요. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예** 링크를 선택합니다.
## VPC에 대한 서비스 연결 역할 권한
VPC는 **AWSServiceRoleForNATGateway**라는 서비스 연결 역할을 사용합니다. 이 서비스 연결 역할을 사용하면 Amazon VPC가 사용자를 대신하여 탄력적 IP 주소를 할당하여 리전 NAT 게이트웨이를 자동으로 규모 조정하고, 요청 시 기존 탄력적 IP를 리전 NAT 게이트웨이에 연결 및 연결 해제하고, 네트워크 인터페이스를 설명하여 새 가용 영역으로 자동으로 확장할 기존 인프라를 식별할 수 있습니다.
AWSServiceRoleForNATGateway 서비스 연결 역할은 역할을 수임하기 위해 다음 서비스를 신뢰합니다.
+ `ec2-nat-gateway.amazonaws.com`
AWSNATGatewayServiceRolePolicy라는 역할 권한 정책은 VPC가 지정된 리소스에 대해 다음 작업을 수행할 수 있도록 허용합니다.
+ 작업: `AllocateAddress`는 서비스 관리형 EIP에 대해 사용자를 대신하여 EIP를 할당합니다. 서비스 관리형 EIP는 서비스 관리형 태그 및 ReleaseAddress를 사용하여 후속 태그 지정을 자동으로 처리합니다.
+ 작업: `AssociateAddress`는 기존 탄력적 IP 주소에 대해 요청에 따라 해당 주소를 리전 NA 게이트웨이에 수동으로 연결합니다.
+ 작업: `DisassociateAddress`는 기존 탄력적 IP 주소에 대해 요청에 따라 해당 주소를 리전 NAT 게이트웨이에서 제거합니다.
+ 작업: `DescribeAddresses`는 연결된 고객 제공 EIP에서 퍼블릭 IP 주소 정보를 가져옵니다.
+ 작업: `DescribeNetworkInterface`는 기존 네트워크 인터페이스에 대해 인프라가 상주하는 가용 영역을 자동으로 식별하여 새 영역으로 자동으로 스케일 아웃합니다.
사용자, 그룹 또는 역할이 서비스 연결 역할을 생성, 편집 또는 삭제할 수 있도록 사용 권한을 구성해야 합니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)을 참조하세요.
## VPC에 대한 서비스 연결 역할 생성
서비스 연결 역할은 수동으로 생성할 필요가 없습니다. AWS Management Console, AWS CLI 또는 AWS API에서 ‘리전’ 가용 모드로 NAT 게이트웨이를 생성하면 VPC가 서비스 연결 역할을 생성합니다.
**중요**
이러한 서비스 연결 역할은 해당 역할이 지원하는 기능을 사용하는 다른 서비스에서 작업을 완료했을 경우 계정에 나타날 수 있습니다. 또한 VPC 서비스가 서비스 연결 역할을 지원하기 시작한 2017년 1월 1일 이전에 이 서비스를 사용 중이었다면 VPC가 사용자 계정에 AWSServiceRoleForNATGateway 역할을 이미 생성했습니다. 자세한 내용은 [내 AWS 계정에 표시되는 새 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)을 참조하세요.
이 서비스 연결 역할을 삭제했다가 다시 생성해야 하는 경우 동일한 프로세스를 사용하여 계정에서 역할을 다시 생성할 수 있습니다. ‘리전’ 가용 모드로 NAT 게이트웨이를 생성하면 VPC가 서비스 연결 역할을 다시 생성합니다.
IAM 콘솔에서 **AWSServiceRoleForNATGateway** 사용 사례를 사용하여 서비스 연결 역할을 생성할 수도 있습니다. AWS CLI 또는 AWS API에서 `ec2-nat-gateway.amazonaws.com` 서비스 이름의 서비스 연결 역할을 생성합니다. 자세한 내용은 *IAM 사용자 설명서*의 [서비스 연결 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)을 참조하세요. 이 서비스 연결 역할을 삭제하면 동일한 프로세스를 사용하여 역할을 다시 생성할 수 있습니다.
## VPC에 대한 서비스 연결 역할 편집
VPC는 AWSServiceRoleForNATGateway 서비스 연결 역할을 편집하도록 허용하지 않습니다. 서비스 연결 역할을 생성한 후에는 다양한 개체가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. 하지만 IAM을 사용하여 역할의 설명을 편집할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)을 참조하세요.
## VPC에 대한 서비스 연결 역할 삭제
서비스 연결 역할이 필요한 기능 또는 서비스가 더 이상 필요 없는 경우에는 해당 역할을 삭제할 것을 권합니다. 이렇게 하면 적극적으로 모니터링하거나 유지 관리하지 않은 미사용 엔터티가 없습니다. 단, 서비스 연결 역할에 대한 리소스를 먼저 정리해야 수동으로 삭제할 수 있습니다.
**참고**
리소스를 삭제하려 할 때 VPC 서비스가 역할을 사용 중이면 삭제에 실패할 수 있습니다. 이 문제가 발생하면 몇 분 기다렸다가 작업을 다시 시도하세요.
**AWSServiceRoleForNATGateway에서 사용하는 VPC 리소스를 삭제하는 방법**
+ 배포된 모든 리전에서 모든 리전 NAT 게이트웨이를 삭제합니다.
**IAM을 사용하여 수동으로 서비스 연결 역할을 삭제하려면 다음을 수행하세요.**
IAM 콘솔, AWS CLI 또는 AWS API를 사용하여 AWSServiceRoleForNATGateway 서비스 연결 역할을 삭제합니다. 자세한 내용은 IAM 사용 설명서의 [서비스 연결 역할 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)**를 참조하십시오.
## VPC 서비스 연결 역할이 지원되는 리전
VPC는 서비스가 제공되는 모든 리전에서 서비스 연결 역할 사용을 지원합니다. 자세한 내용은 [AWS 리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html) 섹션을 참조하세요.
VPC는 서비스가 제공되는 모든 리전에서 서비스 연결 역할 사용을 지원하지 않습니다. 다음 리전에서 AWSServiceRoleForNATGateway 역할을 사용할 수 있습니다.
| 리전 이름 | 리전 자격 증명 | VPC에서 지원 |
| --- | --- | --- |
| 미국 동부(버지니아 북부) | us-east-1 | 예 |
| 미국 동부(오하이오) | us-east-2 | 예 |
| 미국 서부(캘리포니아 북부) | us-west-1 | 예 |
| 미국 서부(오리건) | us-west-2 | 예 |
| 아프리카(케이프타운) | af-south-1 | 예 |
| 아시아 태평양(홍콩) | ap-east-1 | 예 |
| 아시아 태평양(타이베이) | ap-east-2 | 예 |
| 아시아 태평양(자카르타) | ap-southeast-3 | 예 |
| 아시아 태평양(뭄바이) | ap-south-1 | 예 |
| 아시아 태평양(하이데라바드) | ap-south-2 | 예 |
| 아시아 태평양(오사카) | ap-northeast-3 | 예 |
| 아시아 태평양(서울) | ap-northeast-2 | 예 |
| 아시아 태평양(싱가포르) | ap-southeast-1 | 예 |
| 아시아 태평양(시드니) | ap-southeast-2 | 예 |
| 아시아 태평양(도쿄) | ap-northeast-1 | 예 |
| 아시아 태평양(멜버른) | ap-southeast-4 | 예 |
| 아시아 태평양(말레이시아) | ap-southeast-5 | 예 |
| 아시아 태평양(뉴질랜드) | ap-southeast-6 | 예 |
| 아시아 태평양(태국) | ap-southeast-7 | 예 |
| 캐나다(중부) | ca-central-1 | 예 |
| 캐나다 서부(캘거리) | ca-west-1 | 예 |
| 유럽(프랑크푸르트) | eu-central-1 | 예 |
| 유럽(취리히) | eu-central-2 | 예 |
| 유럽(아일랜드) | eu-west-1 | 예 |
| 유럽(런던) | eu-west-2 | 예 |
| 유럽(밀라노) | eu-south-1 | 예 |
| 유럽(스페인) | eu-south-2 | 예 |
| 유럽(파리) | eu-west-3 | 예 |
| 유럽(스톡홀름) | eu-north-1 | 예 |
| 이스라엘(텔아비브) | il-central-1 | 예 |
| 중동(바레인) | me-south-1 | 예 |
| 중동(UAE) | me-central-1 | 예 |
| 중동(사우디아라비아) | me-west-1 | 예 |
| 멕시코(중부) | mx-central-1 | 예 |
| 남아메리카(상파울루) | sa-east-1 | 예 |
| AWS GovCloud(미국 동부) | us-gov-east-1 | 아니요 |
| AWS GovCloud(미국 서부) | us-gov-west-1 | 아니요 |
# Amazon VPC의 인프라 보안
관리형 서비스인 Amazon Virtual Private Cloud는 AWS 글로벌 네트워크 보안으로 보호됩니다. AWS 보안 서비스와 AWS의 인프라 보호 방법에 대한 자세한 내용은 [AWS 클라우드 보안](https://aws.amazon.com/security/)을 참조하세요. 인프라 보안에 대한 모범 사례를 사용하여 AWS 환경을 설계하려면 *보안 원칙 AWS Well‐Architected Framework*의 [인프라 보호](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)를 참조하세요.
AWS에서 게시한 API 호출을 사용하여 네트워크를 통해 Amazon VPC에 액세스합니다. 클라이언트는 다음을 지원해야 합니다.
+ Transport Layer Security(TLS). TLS 1.2는 필수이며 TLS 1.3을 권장합니다.
+ DHE(Ephemeral Diffie-Hellman) 또는 ECDHE(Elliptic Curve Ephemeral Diffie-Hellman)와 같은 완전 전송 보안(PFS)이 포함된 암호 제품군. Java 7 이상의 최신 시스템은 대부분 이러한 모드를 지원합니다.
## 네트워크 격리
가상 프라이빗 클라우드(VPC)는 AWS 클라우드에서 논리적으로 격리된 고유한 영역의 가상 네트워크입니다. 별도의 VPC를 사용하여 워크로드별 또는 조직체별로 인프라를 격리합니다.
서브넷은 VPC의 IP 주소 범위입니다. 인스턴스를 시작할 때 VPC의 서브넷에서 인스턴스를 시작합니다. 서브넷을 사용하여 단일 VPC 내의 애플리케이션 티어(예: 웹, 애플리케이션 및 데이터베이스)를 격리합니다. 인터넷에서 직접 액세스하면 안 되는 경우 프라이빗 서브넷을 인스턴스에 사용합니다.
[AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/)를 사용하여 VPC의 리소스에서 프라이빗 IP 주소를 사용하여 AWS 서비스에 연결하고 서비스를 VPC 직접 호스팅된 것처럼 이용하도록 할 수 있습니다. 따라서 AWS 서비스에 액세스하기 위해 인터넷 게이트웨이나 NAT 장치를 사용할 필요가 없습니다.
## 네트워크 트래픽 제어
EC2 인스턴스와 같은 VPC의 네트워크 트래픽을 제어하기 위해 다음 옵션을 고려해 보세요.
+ [보안 그룹](vpc-security-groups.md)을 VPC에 대한 네트워크 액세스를 제어하는 기본 메커니즘으로 활용합니다. 필요한 경우 [네트워크 ACL](vpc-network-acls.md)을 사용하여 상태 비저장의 거친 네트워크 제어를 제공합니다. 보안 그룹은 상태 저장 패킷 필터링을 수행하고 다른 보안 그룹을 참조하는 규칙을 만들 수 있기 때문에 네트워크 ACL보다 다재다능합니다. 네트워크 ACL은 보조 제어 장치(예: 트래픽의 특정 하위 집합 거부) 또는 상위 수준의 서브넷 가드레일로 효과를 발휘할 수 있습니다. 또한 네트워크 ACL은 전체 서브넷에 적용되므로 인스턴스가 올바른 보안 그룹 없이 시작될 경우 이를 심층 방어 기능으로 사용할 수 있습니다.
+ 인터넷에서 직접 액세스하면 안 되는 경우 프라이빗 서브넷을 인스턴스에 사용합니다. 프라이빗 서브넷에 있는 인스턴스에서 인터넷에 엑세스하려면 배스천 호스트 또는 NAT 게이트웨이를 사용합니다.
+ 연결 요구 사항을 지원하기 위해 최소 네트워크 경로로 서브넷 [라우팅 테이블](VPC_Route_Tables.md)을 구성합니다.
+ 보안 그룹 또는 네트워크 인터페이스를 추가로 사용하여 일반 애플리케이션 트래픽과 별도로 Amazon EC2 인스턴스 관리 트래픽을 제어하고 감사하는 방법을 고려해 보세요. 따라서 변경 제어를 위한 특별한 IAM 정책을 고객이 구현할 수 있으므로 보안 그룹 규칙 또는 자동화된 규칙 확인 스크립트의 변경 사항을 감사하기가 쉬워집니다. 또한 네트워크 인터페이스가 여럿이면 호스트 기반 라우팅 정책을 생성하거나 서브넷에 할당된 네트워크 인터페이스에 따라 다양한 VPC 서브넷 라우팅 규칙을 활용하는 기능 등 네트워크 트래픽 제어의 옵션이 늘어납니다.
+ AWS Virtual Private Network 또는 Direct Connect를 사용하여 원격 네트워크에서 VPC로 프라이빗 연결을 설정합니다. 자세한 내용은 [네트워크-Amazon VPC 연결 옵션](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)을 참조하세요.
+ [VPC 흐름 로그](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)를 사용하여 인스턴스에 도달하는 트래픽을 모니터링합니다.
+ [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)를 사용하여 인스턴스에서 의도하지 않게 네트워크에 액세스할 수 있는지 확인합니다.
+ [AWS Network Firewall](network-firewall.md)을 사용하여 VPC의 서브넷을 일반적인 네트워크 위협으로부터 보호합니다.
## 보안 그룹 및 네트워크 ACL 비교
다음 표는 보안 그룹과 네트워크 ACL의 근본적인 차이를 요약한 것입니다.
| 기능 | 보안 그룹 | 네트워크 ACL |
| --- | --- | --- |
| 작업 수준 | 인스턴스 수준 | 서브넷 수준 |
| 범위 | 보안 그룹과 연결된 모든 인스턴스에 적용됨 | 연결된 서브넷의 모든 인스턴스에 적용됨 |
| 규칙 타입 | 규칙만 허용 | 규칙 허용 및 거부 |
| 규칙 평가 | 트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가 | 트래픽과 일치하는 항목이 발견될 때까지 규칙을 오름차순으로 평가 |
| 트래픽 반환 | 자동 허용(상태 저장) | 허용 명시 필요(상태 비저장) |
다음 다이어그램은 보안 그룹과 네트워크 ACL에서 제공하는 보안 계층을 보여 줍니다. 예를 들어, 인터넷 게이트웨이의 트래픽은 라우팅 테이블의 라우팅을 사용하여 적절한 서브넷에 라우팅됩니다. 서브넷과 연결된 네트워크 ACL 규칙은 서브넷에 허용되는 트래픽 유형을 제어합니다. 인스턴스와 연결된 보안 그룹 규칙은 인스턴스에 허용되는 트래픽 유형을 제어합니다.
![\[트래픽은 보안 그룹과 네트워크 ACL을 통해 제어됨\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/security-comparison.png)
보안 그룹만 사용하여 인스턴스를 보호할 수 있습니다. 그러나 네트워크 ACL을 추가 방어 계층으로 추가할 수 있습니다. 자세한 내용은 [예: 서브넷의 인스턴스에 대한 액세스 제어](nacl-examples.md) 단원을 참조하세요.
# 보안 그룹을 사용하여 AWS 리소스에 대한 트래픽 제어
*보안 그룹*은 연결된 리소스에 도달하고 나갈 수 있는 트래픽을 제어합니다. 예를 들어 보안 그룹을 EC2 인스턴스와 연결하면 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어합니다.
VPC를 생성할 경우 VPC는 기본 보안 그룹과 함께 제공됩니다. 각각 고유한 인바운드 및 아웃바운드 규칙이 있는 추가 보안 그룹을 생성할 수 있습니다. 각 인바운드 규칙에 대해 소스, 포트 범위 및 프로토콜을 지정할 수 있습니다. 각 아웃바운드 규칙에 대해 대상, 포트 범위 및 프로토콜을 지정할 수 있습니다.
다음 다이어그램은 서브넷, 인터넷 게이트웨이 및 보안 그룹이 있는 VPC를 보여줍니다. 이 서브넷에는 EC2 인스턴스가 포함되어 있습니다. 보안 그룹은 인스턴스에 할당됩니다. 보안 그룹은 가상 방화벽의 기능을 수행합니다. 인스턴스에 연결되는 트래픽은 보안 그룹 규칙에서 허용되는 트래픽이 유일합니다. 예를 들어, 보안 그룹에 해당 네트워크에서 인스턴스로 이동하는 ICMP 트래픽을 허용하는 규칙이 포함되어 있는 경우 컴퓨터에서 인스턴스를 ping할 수 있습니다. 보안 그룹에 SSH 트래픽을 허용하는 규칙이 포함되어 있지 않은 경우에는 SSH를 사용하여 인스턴스에 연결할 수 없습니다.
![\[서브넷 2개, 보안 그룹 2개, 서로 다른 보안 그룹과 연결된 서브넷의 서버가 있는 VPC\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/security-group-overview.png)
**Topics**
+ [보안 그룹 기본 사항](#security-group-basics)
+ [보안 그룹 예시](#security-group-example-details)
+ [보안 그룹 규칙](security-group-rules.md)
+ [기본 보안 그룹](default-security-group.md)
+ [보안 그룹 생성](creating-security-groups.md)
+ [보안 그룹 규칙 구성](working-with-security-group-rules.md)
+ [보안 그룹 삭제](deleting-security-groups.md)
+ [보안 그룹을 여러 VPC와 연결](security-group-assoc.md)
+ [AWS Organizations와 보안 그룹 공유](security-group-sharing.md)
**가격 책정**
보안 그룹을 사용해도 추가 요금이 부과되지 않습니다.
## 보안 그룹 기본 사항
+ [보안 그룹 VPC 연결 기능](security-group-assoc.md)을 사용하여 보안 그룹을 동일한 리전의 다른 VPC에 연결하는 경우, 보안 그룹을 동일한 VPC에서 생성된 리소스 또는 다른 VPC의 리소스에 할당할 수 있습니다. 단일 리소스에 여러 개의 보안 그룹을 할당할 수도 있습니다.
+ 보안 그룹을 생성할 때 이름과 설명을 제공해야 합니다. 다음 규칙이 적용됩니다.
+ 보안 그룹 이름은 VPC 내에서 고유해야 합니다.
+ 보안 그룹 이름은 대/소문자를 구분하지 않습니다.
+ 이름과 설명은 최대 255자일 수 있습니다.
+ 이름과 설명은 다음과 같은 문자로 제한됩니다. a-z, A-Z, 0-9, 공백 및 .\$1-:/()\$1,@[]\$1=&;\$1\$1\$1\$1\$1
+ 이름에 후행 공백이 포함되어 있으면 이름 끝의 공백을 자릅니다. 예를 들어 이름에 “테스트 보안 그룹 ”을 입력하면 “테스트 보안 그룹”으로 저장됩니다.
+ 보안 그룹 이름은 `sg-`로 시작할 수 없습니다.
+ 보안 그룹은 상태가 저장됩니다. 예를 들어 사용자가 인스턴스에서 요청을 전송하면 해당 요청의 응답 트래픽은 인바운드 보안 그룹 규칙에 관계없이 인스턴스에 도달할 수 있습니다. 허용된 인바운드 트래픽에 대한 응답은 아웃바운드 규칙에 관계없이 인스턴스를 떠날 수 있습니다.
+ 보안 그룹은 다음에서 송수신되는 트래픽을 필터링하지 않습니다.
+ Amazon Domain Name Services(DNS)
+ Amazon Dynamic Host Configuration Protocol(DHCP)
+ Amazon EC2 인스턴스 메타데이터
+ Amazon ECS 태스크 메타데이터 엔드포인트
+ Windows 인스턴스에 대한 라이선스 활성화
+ Amazon Time Sync Service
+ 기본 VPC 라우터에서 사용하는 예약된 IP 주소
+ VPC당 생성할 수 있는 보안 그룹의 개수, 각 보안 그룹에 추가할 수 있는 규칙의 개수, 그리고 네트워크 인터페이스에 연결할 수 있는 보안 그룹의 개수에는 할당량이 있습니다. 자세한 내용은 [Amazon VPC 할당량](amazon-vpc-limits.md) 단원을 참조하세요.
**모범 사례**
+ 특정 IAM 보안 주체에만 보안 그룹을 생성 및 수정하는 권한을 부여합니다.
+ 오류 위험을 줄이려면 필요한 최소 보안 그룹 수를 생성합니다. 각 보안 그룹을 사용하여 함수 및 보안 요구 사항이 비슷한 리소스에 대한 액세스 권한을 관리합니다.
+ EC2 인스턴스에 액세스할 수 있도록 포트 22(SSH) 또는 3389(RDP)에 대한 인바운드 규칙을 추가하는 경우 특정 IP 주소 범위만 권한을 부여합니다. 0.0.0.0/0(IPv4)과 ::/(IPv6)를 지정하면 누구든지 지정된 프로토콜을 사용하여 모든 IP 주소에서 인스턴스에 액세스할 수 있게 됩니다.
+ 큰 포트 범위를 열지 마세요. 각 포트를 통한 액세스 권한이 해당 포트를 필요로 하는 원본 또는 대상으로 제한되도록 하세요.
+ 보안 그룹과 비슷한 규칙으로 네트워크 ACL을 생성하여 VPC에 추가 보안 계층을 추가해 보세요. 보안 그룹과 네트워크 ACL의 차이에 대한 자세한 정보는 [보안 그룹 및 네트워크 ACL 비교](infrastructure-security.md#VPC_Security_Comparison) 단원을 참조하세요.
## 보안 그룹 예시
다음 다이어그램에서는 보안 그룹과 서브넷이 각각 2개인 VPC를 보여줍니다. 서브넷 A의 인스턴스는 연결 요구 사항이 동일한 보안 그룹 1과 연결됩니다. 서브넷 B의 인스턴스는 연결 요구 사항이 동일한 보안 그룹 2와 연결됩니다. 보안 그룹 규칙에서는 다음의 트래픽이 허용됩니다.
+ 보안 그룹 1의 첫 번째 인바운드 규칙은 지정된 주소 범위(예: 자체 네트워크의 범위)에서 서브넷 A의 인스턴스로 이동하는 SSH 트래픽을 허용합니다.
+ 보안 그룹 1의 두 번째 인바운드 규칙에서는 서브넷 A의 인스턴스가 프로토콜과 포트를 사용하여 상호 간에 통신하는 것이 허용됩니다.
+ 보안 그룹 2의 첫 번째 인바운드 규칙에서는 서브넷 B의 인스턴스가 프로토콜과 포트를 사용하여 상호 간에 통신하는 것이 허용됩니다.
+ 보안 그룹 2의 두 번째 인바운드 규칙에서는 서브넷 A의 인스턴스가 SSH를 사용하여 서브넷 B의 인스턴스와 통신하는 것이 허용됩니다.
+ 두 보안 그룹 모두 모든 트래픽을 허용하는 기본 아웃바운드 규칙을 사용합니다.
![\[두 개의 서브넷에 두 개의 보안 그룹 및 서버가 포함된 VPC 서브넷 A의 서버는 보안 그룹 1과 연결되어 있습니다. 서브넷 B의 서버는 보안 그룹 2와 연결되어 있습니다.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/security-group-details.png)
# 보안 그룹 규칙
보안 그룹의 규칙은 보안 그룹과 연결된 리소스에 도달하도록 허용된 인바운드 트래픽을 제어합니다. 인스턴스에서 나갈 수 있는 아웃바운드 트래픽을 제어합니다.
보안 그룹의 규칙을 추가하거나 제거할 수 있습니다(인바운드 또는 아웃바운드 액세스 *권한 부여* 또는 *취소*라고도 함). 규칙은 인바운드 트래픽(수신)이나 아웃바운드 트래픽(송신)에 적용됩니다. 특정 소스 또는 대상에 대한 액세스 권한을 부여할 수 있습니다.
**Topics**
+ [보안 그룹 규칙 기본 사항](#security-group-rule-characteristics)
+ [보안 그룹 규칙의 구성 요소](#security-group-rule-components)
+ [보안 그룹 참조](#security-group-referencing)
+ [보안 그룹 크기](#security-group-size)
+ [무효 보안 그룹 규칙](#vpc-stale-security-group-rules)
## 보안 그룹 규칙 기본 사항
다음은 보안 그룹 규칙의 특징입니다.
+ 허용 규칙을 지정할 수 있지만 거부 규칙은 지정할 수 없습니다.
+ 보안 그룹을 처음 만들 때 인바운드 규칙이 없습니다. 따라서 보안 그룹에 인바운드 규칙을 추가하기 전에는 어떤 인바운드 트래픽도 허용되지 않습니다.
+ 보안 그룹을 처음 생성하면 리소스의 모든 아웃바운드 트래픽을 허용하는 아웃바운드 규칙이 있습니다. 규칙을 제거할 수 있으며 특정 아웃바운드 트래픽만 허용하는 아웃바운드 규칙을 추가할 수 있습니다. 보안 그룹에 아웃바운드 규칙이 없는 경우 어떤 아웃바운드 트래픽도 허용되지 않습니다.
+ 여러 보안 그룹을 리소스와 연결하면 각 보안 그룹의 규칙이 집계되어 액세스 허용 여부를 결정하는 데 사용되는 단일 규칙 집합을 형성합니다.
+ 규칙을 추가, 업데이트 또는 제거할 때 변경 사항은 보안 그룹과 연결된 모든 리소스에 자동으로 적용됩니다. 지침은 [보안 그룹 규칙 구성](working-with-security-group-rules.md) 단원을 참조하세요.
+ 일부 규칙 변경 사항이 미치는 효과는 트래픽의 추적 방법에 따라 다를 수 있습니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [연결 추적](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)을 참조하세요.
+ 보안 그룹 규칙을 생성하면 AWS에서는 규칙에 고유한 ID가 할당됩니다. API 또는 CLI를 사용하여 규칙을 수정하거나 삭제할 때 규칙의 ID를 사용할 수 있습니다.
**제한 사항**
보안 그룹은 'VPC\$12 IP 주소'(*Amazon Route 53 개발자 안내서*의 [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) 참조) 또는 [AmazonProvidedDNS](DHCPOptionSet.md)라고 하는 Route 53 Resolver와 주고받는 DNS 요청을 차단할 수 없습니다. Route 53 Resolver를 통해 DNS 요청을 필터링하려면 [Route 53 Resolver DNS 방화벽](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html)을 사용하세요.
## 보안 그룹 규칙의 구성 요소
다음은 인바운드 및 아웃바운드 보안 그룹 규칙의 구성 요소입니다.
+ **프로토콜**: 허용할 프로토콜. 가장 일반적인 프로토콜은 6(TCP), 17(UDP) 및 1(ICMP)입니다.
+ **포트 범위**: TCP, UDP 또는 사용자 지정 프로토콜의 경우 허용할 포트의 범위. 단일 포트 번호(예: `22`) 또는 포트 번호의 범위(예: `7000-8000`)를 지정할 수 있습니다.
+ **ICMP 유형 및 코드**: ICMP의 경우, ICMP 유형과 코드. 예를 들어 ICMP 에코 요청에 대해 유형 8을 사용하고 ICMPv6 에코 요청에 대해 유형 128을 입력합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [ping/ICMP 규칙](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html#sg-rules-ping)을 참조하세요.
+ **소스 또는 대상**: 허용할 트래픽에 대한 소스(인바운드 규칙) 또는 대상(아웃바운드 규칙)입니다. 다음 중 하나를 지정하세요.
+ 단일 IPv4 주소. `/32` 접두사 길이를 사용해야 합니다. 예: `203.0.113.1/32`.
+ 단일 IPv6 주소. `/128` 접두사 길이를 사용해야 합니다. 예: `2001:db8:1234:1a00::123/128`.
+ CIDR 블록 표기법으로 표시된 IPv4 주소의 범위. 예를 들어 `203.0.113.0/24`입니다.
+ CIDR 블록 표기법으로 표시된 IPv6 주소의 범위. 예를 들어 `2001:db8:1234:1a00::/64`입니다.
+ 접두사 목록의 ID. 예를 들어 `pl-1234abc1234abc123`입니다. 자세한 내용은 [관리형 접두사 목록](managed-prefix-lists.md) 섹션을 참조하세요.
+ 보안 그룹의 ID. 예를 들어 `sg-1234567890abcdef0`입니다. 자세한 내용은 [보안 그룹 참조](#security-group-referencing) 단원을 참조하세요.
+ **(선택 사항) 설명**: 나중에 쉽게 식별할 수 있도록 규칙에 대한 설명을 입력할 수 있습니다. 설명 길이는 최대 255자입니다. 허용되는 문자는 a-z, A-Z, 0-9, 공백 및 .\$1-:/()\$1,@[]\$1=;\$1\$1\$1\$1\$1입니다.
예제는 *Amazon EC2 사용 설명서*의 [다양한 사용 사례의 보안 그룹 규칙](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html)을 참조하세요.
## 보안 그룹 참조
보안 그룹을 규칙의 소스 또는 대상으로 지정할 경우 규칙은 보안 그룹과 연결된 모든 인스턴스에 영향을 줍니다. 인스턴스는 인스턴스의 프라이빗 IP 주소를 사용하여 지정된 프로토콜 및 포트를 통해 지정된 방향으로 통신할 수 있습니다.
예를 들어 다음은 보안 그룹 sg-0abcdef1234567890을(를) 참조하는 보안 그룹에 대한 인바운드 규칙을 나타냅니다. 이 규칙에서는 sg-0abcdef1234567890과(와) 연결된 인스턴스에서 발생한 인바운드 SSH 트래픽이 허용됩니다.
| 소스 | 프로토콜 | 포트 범위 |
| --- | --- | --- |
| sg-0abcdef1234567890 | TCP | 22 |
보안 그룹 규칙에서 보안 그룹을 참조할 때 다음 사항에 유의하세요.
+ 다음 중 하나에 해당하는 경우 다른 보안 그룹의 인바운드 규칙에서 보안 그룹을 참조할 수 있습니다.
+ 보안 그룹이 동일한 VPC에 연결되어 있습니다.
+ 보안 그룹이 연결된 VPC 간에 피어링 연결이 있습니다.
+ 보안 그룹이 연결된 VPC 간에 전송 게이트웨이가 있습니다.
+ 다음 중 하나에 해당하는 경우 아웃바운드 규칙에서 보안 그룹을 참조할 수 있습니다.
+ 보안 그룹이 동일한 VPC에 연결되어 있습니다.
+ 보안 그룹이 연결된 VPC 간에 피어링 연결이 있습니다.
+ 참조된 보안 그룹의 규칙은 해당 그룹을 참조하는 보안 그룹에 추가되지 않습니다.
+ 인바운드 규칙의 경우 보안 그룹과 연결된 EC2 인스턴스는 참조된 보안 그룹과 연결된 EC2 인스턴스의 네트워크 인터페이스에 할당된 프라이빗 IP 주소로부터 인바운드 트래픽을 수신할 수 있습니다.
+ 아웃바운드 규칙의 경우 보안 그룹과 연결된 EC2 인스턴스는 참조된 보안 그룹과 연결된 EC2 인스턴스의 네트워크 인터페이스에 할당된 프라이빗 IP 주소로 아웃바운드 트래픽을 보낼 수 있습니다.
+ `AuthorizeSecurityGroupIngress`, `AuthorizeSecurityGroupEgress`, `RevokeSecurityGroupIngress` 및 `RevokeSecurityGroupEgress` 작업에서는 참조된 보안 그룹에 대해 권한을 부여하지 않습니다. 보안 그룹이 존재하는지 여부만 확인합니다. 이 결과는 다음과 같습니다.
+ 이러한 작업에 대해 IAM 정책에서 참조된 보안 그룹을 지정하는 것은 아무런 효과가 없습니다.
+ 참조된 보안 그룹을 다른 계정이 소유한 경우 소유자 계정은 이러한 작업에 대한 CloudTrail 이벤트를 수신하지 않습니다.
**제한**
미들박스 어플라이언스를 통해 서로 다른 서브넷에 있는 두 인스턴스 간의 트래픽을 전달하도록 경로를 구성하는 경우 두 인스턴스에 대한 보안 그룹이 인스턴스 간에 트래픽이 흐르도록 허용해야 합니다. 각 인스턴스의 보안 그룹은 다른 인스턴스의 프라이빗 IP 주소 또는 다른 인스턴스가 포함된 서브넷의 CIDR 범위를 소스로 참조해야 합니다. 다른 인스턴스의 보안 그룹을 소스로 참조하면 인스턴스 간에 트래픽이 흐를 수 없습니다.
**예제**
다음 다이어그램은 두 개의 가용 영역에 있는 서브넷, 인터넷 게이트웨이 및 Application Load Balancer가 있는 VPC를 보여 줍니다. 각 가용 영역에는 웹 서버용 퍼블릭 서브넷과 데이터베이스 서버용 프라이빗 서브넷이 있습니다. 로드 밸런서, 웹 서버 및 데이터베이스 서버에는 별도의 보안 그룹이 있습니다. 다음 보안 그룹 규칙을 생성하여 트래픽을 허용하세요.
+ 인터넷의 HTTP 및 HTTPS 트래픽을 허용하도록 로드 밸런서 보안 그룹에 규칙을 추가합니다. 소스는 0.0.0.0/0.입니다.
+ 로드 밸런서의 HTTP 및 HTTPS 트래픽만 허용하도록 웹 서버의 보안 그룹에 규칙을 추가합니다. 소스는 로드 밸런서에 대한 보안 그룹입니다.
+ 웹 서버의 데이터베이스 요청을 허용하도록 데이터베이스 서버의 보안 그룹에 규칙을 추가합니다. 소스는 웹 서버에 대한 보안 그룹입니다.
![\[웹 및 DB 서버, 보안 그룹, 인터넷 게이트웨이, 로드 밸런서가 있는 아키텍처\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/security-group-referencing.png)
## 보안 그룹 크기
소스 또는 대상의 유형에 따라 각 규칙이 보안 그룹당 가질 수 있는 최대 규칙 수에 포함되는 방식이 결정됩니다.
+ CIDR 블록을 참조하는 규칙은 하나의 규칙으로 계산됩니다.
+ 다른 보안 그룹을 참조하는 규칙은 참조된 보안 그룹의 크기와 상관없이 하나의 규칙으로 계산됩니다.
+ 고객이 관리하는 접두사 목록을 참조하는 규칙은 접두사 목록의 최대 크기로 계산됩니다. 예를 들어 접두사 목록의 최대 크기가 20인 경우 이 접두사 목록을 참조하는 규칙은 20개의 규칙으로 계산됩니다.
+ AWS 관리형 접두사 목록을 참조하는 규칙은 접두사 목록의 가중치로 계산됩니다. 예를 들어 접두사 목록의 가중치가 10인 경우 이 접두사 목록을 참조하는 규칙은 10개의 규칙으로 계산됩니다. 자세한 내용은 [사용 가능한 AWS 관리형 접두사 목록](working-with-aws-managed-prefix-lists.md#available-aws-managed-prefix-lists) 단원을 참조하세요.
## 무효 보안 그룹 규칙
VPC에 다른 VPC와의 VPC 피어링 연결이 있는 경우 또는 다른 계정에 의해 공유된 VPC를 사용하는 경우 VPC의 보안 그룹 규칙은 해당 피어 VPC 또는 공유 VPC의 보안 그룹을 참조할 수 있습니다. 이를 통해 참조된 보안 그룹과 연결된 리소스가 참조하는 보안 그룹과 연결된 리소스와 서로 통신할 수 있습니다. 자세한 내용은 *Amazon VPC 피어링 가이드*의 [피어 VPC 보안 그룹을 참조하도록 보안 그룹 업데이트](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html)를 참조하세요.
피어 VPC 또는 공유 VPC의 보안 그룹을 참조하는 보안 그룹 규칙이 있고 공유 VPC의 보안 그룹이 삭제되거나 VPC 피어링 연결이 삭제된 경우 보안 그룹 규칙은 무효로 표시됩니다. 다른 보안 그룹 규칙과 같은 방법으로 무효 보안 그룹 규칙을 삭제할 수 있습니다.
# VPC에 대한 기본 보안 그룹
기본 VPC와 사용자가 생성한 VPC는 기본 보안 그룹과 함께 제공됩니다. 기본 보안 그룹의 이름은 “default“입니다.
기본 보안 그룹을 사용하는 대신 특정 리소스 또는 리소스 그룹에 대한 보안 그룹을 만드는 것이 좋습니다. 단, 일부 리소스는 생성 시점에 보안 그룹을 연결하지 않으면 기본 보안 그룹이 연결됩니다. 예를 들어 EC2 인스턴스를 시작할 때 보안 그룹을 지정하지 않은 경우 인스턴스는 그 VPC의 기본 보안 그룹과 연결됩니다.
## 기본 보안 그룹 기본 사항
+ 기본 보안 그룹에 대한 규칙을 변경할 수 있습니다.
+ 기본 보안 그룹을 삭제할 수 없습니다. 기본 보안 그룹을 삭제하려고 하면 `Client.CannotDelete`라는 오류 코드가 반환됩니다.
## 기본 규칙
다음 표에서는 기본 보안 그룹의 기본 인바운드 규칙을 설명합니다.
| 소스 | 프로토콜 | 포트 범위 | 설명 |
| --- | --- | --- | --- |
| sg-1234567890abcdef0 | 모두 | 모두 | 이 보안 그룹에 할당된 모든 리소스로부터의 인바운드 트래픽을 허용합니다. 소스는 보안 그룹의 ID입니다. |
다음 표에서는 기본 보안 그룹의 기본 아웃바운드 규칙을 설명합니다.
| Destination | 프로토콜 | 포트 범위 | 설명 |
| --- | --- | --- | --- |
| 0.0.0.0/0 | 모두 | 모두 | 모든 아웃바운드 IPv4 트래픽을 허용합니다. |
| ::/0 | 모두 | 모두 | 모든 아웃바운드 IPv6 트래픽을 허용합니다. 이 규칙은 VPC에 연결된 IPv6 CIDR 블록이 있는 경우에만 추가됩니다. |
## 예제
다음 다이어그램은 기본 보안 그룹, 인터넷 게이트웨이 및 NAT 게이트웨이가 있는 VPC를 보여 줍니다. 기본 보안에는 기본 규칙만 포함되며 VPC에서 실행되는 두 개의 EC2 인스턴스와 연결됩니다. 이 시나리오에서 각 인스턴스는 모든 포트 및 프로토콜에서 다른 인스턴스로부터 인바운드 트래픽을 수신할 수 있습니다. 기본 규칙에서는 인스턴스가 인터넷 게이트웨이 또는 NAT 게이트웨이로부터 트래픽을 수신하는 것이 허용되지 않습니다. 인스턴스에서 반드시 추가 트래픽을 수신해야 하는 경우 필수 규칙이 있는 보안 그룹을 만들고 새 보안 그룹을 기본 보안 그룹 대신 인스턴스에 연결하는 것을 권장합니다.
![\[서브넷 2개, 기본 보안 그룹, EC2 인스턴스 2개, 인터넷 게이트웨이, NAT 게이트웨이가 있는 VPC\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/default-security-group.png)
# VPC의 보안 그룹을 생성
가상 프라이빗 클라우드(VPC)에는 기본 보안 그룹이 제공됩니다. 추가 보안 그룹을 생성할 수 있습니다. 보안 그룹은 해당 보안 그룹이 생성된 VPC의 리소스에서만 사용할 수 있습니다.
기본적으로 처음에 새 보안 그룹에는 리소스에서 나가는 모든 트래픽을 허용하는 아웃바운드 규칙만 적용됩니다. 인바운드 트래픽을 사용하거나 아웃바운드 트래픽을 제한하려면 규칙을 추가해야 합니다. 보안 그룹을 생성할 때나 나중에 규칙을 추가할 수 있습니다. 자세한 내용은 [보안 그룹 규칙](security-group-rules.md) 단원을 참조하세요.
**필수 권한**
시작하기 전에 필수 권한을 받았는지 확인하세요. 자세한 내용은 다음 자료를 참조하세요.
+ [보안 그룹 관리](vpc-policy-examples.md#vpc-security-groups-iam)
+ [보안 그룹 규칙 관리](vpc-policy-examples.md#vpc-security-group-rules-iam)
**콘솔을 사용하여 보안 그룹을 생성하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Security groups**를 선택합니다.
1. **보안 그룹 생성**을 선택합니다.
1. 보안 그룹의 이름과 설명을 입력합니다. 보안 그룹을 생성한 후에는 보안 그룹에 대한 이름과 설명을 변경할 수 없습니다.
1. **VPC**에서는 보안 그룹을 연결할 리소스를 생성할 VPC를 선택합니다.
1. (선택 사항) 인바운드 규칙을 추가하려면 **인바운드 규칙**을 선택합니다. 각 규칙에 대해 **규칙 추가**를 선택하고 프로토콜, 포트 및 소스를 지정합니다. 자세한 내용은 [보안 그룹 규칙 구성](working-with-security-group-rules.md) 단원을 참조하세요.
1. (선택 사항) 아웃바운드 규칙을 추가하려면 **아웃바운드 규칙**을 선택합니다. 각 규칙에 대해 **규칙 추가**를 선택하고 프로토콜, 포트 및 대상을 지정합니다.
1. (선택 사항) 태그를 추가하려면 **Add new tag**(새 태그 추가)를 선택하고 태그 키와 태그 값을 입력합니다.
1. **보안 그룹 생성**을 선택합니다.
**AWS CLI를 사용하여 보안 그룹을 생성하려면**
[create-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-security-group.html) 명령을 사용합니다.
또는 기존 보안 그룹을 복사하여 새 보안 그룹을 생성할 수도 있습니다. 보안 그룹을 복사하면 원래 보안 그룹과 동일한 인바운드 및 아웃바운드 규칙을 자동으로 추가하고 원래 보안 그룹과 동일한 VPC를 사용합니다. 새 보안 그룹의 이름과 설명을 입력할 수 있습니다. 필요에 따라 다른 VPC를 선택하고 필요에 따라 인바운드 및 아웃바운드 규칙을 수정할 수 있습니다. 그러나 보안 그룹을 한 리전에서 다른 리전으로 복사할 수 없습니다.
**기존 보안 그룹을 기준으로 보안 그룹을 생성하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Security groups**를 선택합니다.
1. 보안 그룹을 선택합니다.
1. **작업**, **새 보안 그룹에 복사**를 선택합니다.
1. 보안 그룹의 이름과 설명을 입력합니다.
1. (선택 사항) 필요한 경우 다른 VPC를 선택합니다.
1. (선택 사항) 필요에 따라 보안 그룹 규칙을 추가, 제거 또는 편집합니다.
1. **보안 그룹 생성**을 선택합니다.
# 보안 그룹 규칙 구성
보안 그룹을 생성한 후 해당 보안 그룹 규칙을 추가, 업데이트 및 삭제할 수 있습니다. 규칙을 추가, 업데이트 또는 삭제하면 변경 내용이 보안 그룹과 연결된 모든 리소스에 자동으로 적용됩니다.
**필수 권한**
시작하기 전에 필요한 권한이 있는지 확인하세요. 자세한 내용은 [보안 그룹 규칙 관리](vpc-policy-examples.md#vpc-security-group-rules-iam) 섹션을 참조하세요.
**포트 및 프로토콜**
+ 콘솔에서 사전 정의된 유형을 선택하면 **프로토콜** 및 **포트 범위**가 지정됩니다. 포트 범위를 입력하려면 **사용자 지정 TCP** 또는 **사용자 지정 UDP** 중 하나를 선택해야 합니다.
+ AWS CLI에서 `--protocol` 및 `--port` 옵션을 사용하여 단일 포트가 있는 단일 규칙을 추가할 수 있습니다. 여러 규칙 또는 포트 범위가 있는 규칙을 추가하려면 `--ip-permissions` 옵션을 대신 사용합니다.
**소스 및 대상**
+ 콘솔에서 다음을 인바운드 규칙의 소스 또는 아웃바운드 규칙의 대상으로 지정할 수 있습니다.
+ **사용자 지정** - IPv4 CIDR 블록, IPv6 CIDR 블록, 보안 그룹 또는 접두사 목록.
+ **Anywhere-IPv4** – 0.0.0.0/0 IPv4 CIDR 블록.
+ **Anywhere-IPv6** – ::/0 IPv6 CIDR 블록.
+ **내 IP**: 로컬 컴퓨터의 퍼블릭 IPv4 주소.
+ AWS CLI에서 `--cidr` 옵션을 사용하여 IPv4 CIDR 블록을 지정하거나 `--source-group` 옵션을 사용하여 보안 그룹을 지정할 수 있습니다. 접두사 목록 또는 IPv6 CIDR 블록을 지정하려면 `--ip-permissions` 옵션을 사용합니다.
**주의**
**Anywhere-IPv4**를 선택하면 모든 IPv4 주소의 트래픽이 허용됩니다. **Anywhere-IPv6**을 선택하면 모든 IPv6 주소의 트래픽이 허용됩니다. 리소스에 액세스해야 하는 특정 IP 주소 범위에만 권한을 부여하는 것이 가장 좋습니다.
**콘솔을 사용하여 보안 그룹 규칙을 구성하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Security groups**를 선택합니다.
1. 보안 그룹을 선택합니다.
1. 인바운드 규칙을 편집하려면 **작업** 또는 **인바운드 규칙** 탭에서 **인바운드 규칙 편집**을 선택합니다.
1. 규칙을 추가하려면 **규칙 추가**를 선택한 다음 규칙의 유형, 프로토콜, 포트 및 소스를 입력합니다.
유형이 TCP 또는 UDP인 경우 허용할 포트 범위를 입력해야 합니다. 사용자 지정 ICMP의 경우 **프로토콜(Protocol)**에서 ICMP 유형 이름을 선택하고, 해당되는 경우 **포트 범위(Port range)**에서 코드 이름을 선택해야 합니다. 다른 유형에 대해 프로토콜과 포트 범위가 구성됩니다.
1. 규칙을 업데이트하려면 필요에 따라 프로토콜, 설명 및 소스를 변경합니다. 하지만 소스 유형을 변경할 수는 없습니다. 예를 들어 소스가 IPv4 CIDR 블록인 경우 IPv6 CIDR 블록, 접두사 목록 또는 보안 그룹을 지정할 수 없습니다.
1. 규칙을 삭제하려면 해당 **삭제** 버튼을 선택합니다.
1. 아웃바운드 규칙을 편집하려면 **작업** 또는 **아웃바운드 규칙** 탭에서 **아웃바운드 규칙 편집**을 선택합니다.
1. 규칙을 추가하려면 **규칙 추가**를 선택한 다음 규칙의 유형, 프로토콜, 포트 및 대상을 입력합니다. 또한 설명을 입력할 수 있습니다(선택 사항).
유형이 TCP 또는 UDP인 경우 허용할 포트 범위를 입력해야 합니다. 사용자 지정 ICMP의 경우 **프로토콜(Protocol)**에서 ICMP 유형 이름을 선택하고, 해당되는 경우 **포트 범위(Port range)**에서 코드 이름을 선택해야 합니다. 다른 유형에 대해 프로토콜과 포트 범위가 구성됩니다.
1. 규칙을 업데이트하려면 필요에 따라 프로토콜, 설명 및 소스를 변경합니다. 하지만 소스 유형을 변경할 수는 없습니다. 예를 들어 소스가 IPv4 CIDR 블록인 경우 IPv6 CIDR 블록, 접두사 목록 또는 보안 그룹을 지정할 수 없습니다.
1. 규칙을 삭제하려면 해당 **삭제** 버튼을 선택합니다.
1. **규칙 저장**을 선택합니다.
**AWS CLI를 사용하여 보안 그룹 규칙 구성**
+ **추가** - [authorize-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-ingress.html) 및 [authorize-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-egress.html) 명령을 사용합니다.
+ **제거** - [revoke-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-ingress.html) 및 [revoke-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-egress.html) 명령을 사용합니다.
+ **수정** - [modify-security-group-rules](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-security-group-rules.html), [update-security-group-rule-descriptions-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/update-security-group-rule-descriptions-ingress.html) 및 [update-security-group-rule-descriptions-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/update-security-group-rule-descriptions-egress.html) 명령을 사용합니다.
# 보안 그룹 삭제
생성한 보안 그룹 사용을 완료하면 이를 삭제할 수 있습니다.
**요구 사항**
+ 보안 그룹은 어떤 리소스와도 연결할 수 없습니다.
+ 보안 그룹은 다른 보안 그룹의 규칙에서 참조할 수 없습니다.
+ 보안 그룹은 VPC의 기본 보안 그룹이 될 수 없습니다.
**콘솔을 사용하여 보안 그룹을 삭제하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Security groups**를 선택합니다.
1. 보안 그룹을 선택한 다음 **작업**, **보안 그룹 삭제**를 선택합니다.
1. 보안 그룹을 둘 이상 선택하면 확인 메시지가 표시됩니다. 일부 보안 그룹을 삭제할 수 없는 경우 각 보안 그룹의 상태가 표시되어 삭제 여부를 나타냅니다. 삭제를 확인하려면 **삭제**를 누릅니다.
1. **삭제**를 선택합니다.
**AWS CLI를 사용하여 보안 그룹을 삭제하려면**
[delete-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-security-group.html) 명령을 사용합니다.
# 보안 그룹을 여러 VPC와 연결
네트워크 보안 요구 사항을 공유하는 여러 VPC에서 워크로드를 실행하는 경우 보안 그룹 VPC 연결 기능을 사용하여 보안 그룹을 동일한 리전의 여러 VPC와 연결할 수 있습니다. 이를 통해 계정의 여러 VPC에 대한 보안 그룹을 한 곳에서 관리하고 유지할 수 있습니다.
![\[두 VPC가 연결되어 있는 보안 그룹의 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/sec-group-vpc-assoc.png)
위의 다이어그램은 두 개의 VPC가 있는 AWS 계정 A를 보여줍니다. 각 VPC에는 프라이빗 서브넷에서 실행되는 워크로드가 있습니다. 이 경우 VPC A 및 B의 서브넷에 있는 워크로드들은 동일한 네트워크 트래픽 요구 사항을 공유하므로 계정 A는 보안 그룹 VPC 연결 기능을 사용하여 VPC A의 보안 그룹을 VPC B와 연결할 수 있습니다. 연결된 보안 그룹에 대한 모든 업데이트는 VPC B 서브넷의 워크로드에 대한 트래픽에 자동으로 적용됩니다.
**보안 그룹 VPC 연결 기능의 요구 사항**
+ 보안 그룹을 VPC와 연결하려면 VPC를 소유하거나 VPC 서브넷 중 하나를 공유해야 합니다.
+ VPC와 보안 그룹이 동일한 AWS 리전에 있어야 합니다.
+ 기본 보안 그룹을 다른 VPC와 연결하거나 보안 그룹을 기본 VPC와 연결할 수 없습니다.
+ 보안 그룹 소유자와 VPC 소유자 모두 보안 그룹 VPC 연결을 볼 수 있습니다.
**이 기능을 지원하는 서비스**
+ Amazon API Gateway(REST API만 해당)
+ AWS Auto Scaling
+ CloudFormation
+ Amazon EC2
+ Amazon EFS
+ Amazon EKS
+ Amazon FSx
+ AWS PrivateLink
+ Amazon Route 53
+ Elastic Load Balancing
+ Application Load Balancer
+ Network Load Balancer
## 보안 그룹을 다른 VPC에 연결
이 섹션에서는 AWS Management Console 및 AWS CLI를 사용하여 보안 그룹을 VPC와 연결하는 방법을 설명합니다.
------
#### [ AWS Management Console ]
**보안 그룹을 다른 VPC와 연결하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **보안 그룹**을 선택합니다.
1. 보안 그룹을 선택하여 세부 정보를 표시합니다.
1. **VPC 연결** 탭을 선택합니다.
1. **VPC 연결**을 선택합니다.
1. **VPC ID**에서 보안 그룹과 연결할 VPC를 선택합니다.
1. **VPC 연결**을 선택합니다.
------
#### [ Command line ]
**보안 그룹을 다른 VPC와 연결하려면**
1. [associate-security-group-vpc](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/associate-security-group-vpc.html)를 사용하여 VPC 연결을 생성합니다.
1. [describe-security-group-vpc-associations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-security-group-vpc-associations.html)를 사용하여 VPC 연결의 상태를 확인하고 상태가 `associated`가 될 때까지 기다립니다.
------
이제 VPC가 보안 그룹과 연결됩니다.
VPC를 보안 그룹과 연결한 후에는 [VPC에서 인스턴스를 시작하고 이 새 보안 그룹을 선택](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html)하거나 [기존 보안 그룹 규칙에서 이 보안 그룹을 참조](security-group-rules.md#security-group-referencing)하는 등의 작업을 할 수 있습니다.
## 다른 VPC에서 보안 그룹 연결 해제
이 섹션에서는 AWS Management Console 및 AWS CLI를 사용하여 VPC에서 보안 그룹을 연결 해제하는 방법을 설명합니다. 보안 그룹을 삭제하는 것이 목표인 경우 이 작업을 수행할 수 있습니다. 연결된 보안 그룹은 삭제할 수 없습니다. 연결된 VPC에서 보안 그룹을 사용하는 네트워크 인터페이스가 없는 경우에만 해당 보안 그룹을 연결 해제할 수 있습니다.
------
#### [ AWS Management Console ]
**VPC에서 보안 그룹을 연결 해제하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **보안 그룹**을 선택합니다.
1. 보안 그룹을 선택하여 세부 정보를 표시합니다.
1. **VPC 연결** 탭을 선택합니다.
1. **VPC 연결 해제**를 선택합니다.
1. **VPC ID**에서 보안 그룹과의 연결을 해제할 VPC를 선택합니다.
1. **VPC 연결 해제**를 선택합니다.
1. VPC 연결 탭에서 연결 해제 **상태**를 확인하고 상태가 `disassociated`가 될 때까지 기다립니다.
------
#### [ Command line ]
**VPC에서 보안 그룹을 연결 해제하려면**
1. [disassociate-security-group-vpc](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/disassociate-security-group-vpc.html)를 사용하여 VPC 연결을 연결 해제합니다.
1. [describe-security-group-vpc-associations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-security-group-vpc-associations.html)를 사용하여 VPC 연결 해제의 상태를 확인하고 상태가 `disassociated`가 될 때까지 기다립니다.
------
이제 VPC가 보안 그룹과 연결 해제됩니다.
# AWS Organizations와 보안 그룹 공유
공유 보안 그룹 기능을 사용하면 보안 그룹을 동일한 AWS 리전 내의 다른 AWS Organizations 계정과 공유하고 해당 계정에서 보안 그룹을 사용할 수 있도록 만들 수 있습니다.
다음 다이어그램은 공유 보안 그룹 기능을 사용하여 AWS Organizations의 계정 전체에서 보안 그룹 관리를 간소화하는 방법을 보여줍니다.
![\[보안 그룹을 공유 VPC 서브넷의 다른 계정과 공유하는 것을 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/sec-group-sharing.png)
이 다이어그램은 동일한 조직의 일부인 세 개의 계정을 보여줍니다. 계정 A는 계정 B 및 C와 VPC 서브넷을 공유합니다. 계정 A는 공유 보안 그룹 기능을 사용하여 계정 B 및 C와 보안 그룹을 공유합니다. 계속해서 계정 B 및 C는 공유 서브넷에서 인스턴스를 시작할 때 해당 보안 그룹을 사용합니다. 이렇게 하면 계정 A가 보안 그룹을 관리할 수 있으며 보안 그룹에 대한 모든 업데이트는 계정 B 및 C가 공유 VPC 서브넷에서 실행한 리소스에 적용됩니다.
**공유 보안 그룹 기능의 요구 사항**
+ 이 기능은 AWS Organizations에서 동일한 조직에 있는 계정에서만 사용할 수 있습니다. AWS Organizations에서 [리소스 공유](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html)를 활성화해야 합니다.
+ 보안 그룹을 공유하는 계정은 VPC와 보안 그룹을 모두 소유해야 합니다.
+ 기본 보안 그룹은 공유할 수 없습니다.
+ 기본 VPC에 있는 보안 그룹은 공유할 수 없습니다.
+ 참가자 계정은 공유 VPC에서 보안 그룹을 생성할 수 있지만 해당 보안 그룹은 공유할 수는 없습니다.
+ IAM 보안 주체가 AWS RAM과 보안 그룹을 공유하려면 최소 권한 세트가 필요합니다. `AmazonEC2FullAccess` 및 `AWSResourceAccessManagerFullAccess` 관리형 IAM 정책을 사용하여 IAM 보안 주체가 공유 보안 기능을 공유하고 사용하는 데 필요한 권한을 갖추게 해야 합니다. 사용자 지정 IAM 정책을 사용하는 경우 `c2:PutResourcePolicy` 및 `ec2:DeleteResourcePolicy` 작업이 필요합니다. 이는 권한 전용 IAM 작업입니다. IAM 보안 주체에게 이러한 권한이 부여되지 않은 경우 AWS RAM을 사용하여 보안 그룹을 공유하려고 할 때 오류가 발생합니다.
**이 기능을 지원하는 서비스**
+ Amazon API Gateway
+ Amazon EC2
+ Amazon ECS
+ Amazon EFS
+ Amazon EKS
+ Amazon EMR
+ Amazon FSx
+ Amazon ElastiCache
+ AWS Elastic Beanstalk
+ AWS Glue
+ Amazon MQ
+ Amazon SageMaker AI
+ Elastic Load Balancing
+ Application Load Balancer
+ Network Load Balancer
**이 기능이 기존 할당량에 미치는 영향**
[보안 그룹 할당량](amazon-vpc-limits.md#vpc-limits-security-groups)이 적용됩니다. 그러나 '네트워크 인터페이스당 보안 그룹' 할당량의 경우 참가자가 탄력적 네트워크 인터페이스(ENI)에서 소유 그룹과 공유 그룹을 모두 사용하는 경우 소유자 및 참자자의 최소 할당량이 적용됩니다.
할당량이 이 기능의 영향을 받는 방식을 보여주는 예:
+ 소유자 계정 할당량: 인터페이스당 보안 그룹 4개
+ 참가자 계정 할당량: 인터페이스당 보안 그룹 5개.
+ 소유자는 그룹 SG-O1, SG-O2, SG-O3, SG-O4, SG-O5를 참가자와 공유합니다. 참가자는 이미 VPC에 SG-P1, SG-P2, SG-P3, SG-P4, SG-P5의 자체 그룹이 있습니다.
+ 참가자가 ENI를 생성하고 소유 그룹만 사용하는 경우 할당량에 해당하므로 5개 보안 그룹(SG-P1, SG-P2, SG-P3, SG-P4, SG-P5)을 모두 연결할 수 있습니다.
+ 참가자가 ENI를 생성하고 ENI에서 공유 그룹을 사용하는 경우 최대 4개의 그룹만 연결할 수 있습니다. 이 경우 이러한 ENI의 할당량은 소유자 및 참가자의 최소 할당량입니다. 가능한 유효한 구성은 다음과 같습니다.
+ SG-O1, SG-P1, SG-P2, SG-P3
+ SG-O1, SG-O2, SG-O3, SG-O4
## 보안 그룹 공유
이 섹션에서는 AWS Management Console 및 AWS CLI를 사용하여 조직의 다른 계정과 보안 그룹을 공유하는 방법을 설명합니다.
------
#### [ AWS Management Console ]
**보안 그룹을 공유하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **보안 그룹**을 선택합니다.
1. 보안 그룹을 선택하여 세부 정보를 표시합니다.
1. **공유** 탭을 선택합니다.
1. **보안 그룹 공유**를 선택합니다.
1. **리소스 공유 생성**을 선택합니다. 그러면 AWS RAM 콘솔이 열립니다. 이 콘솔에서 보안 그룹에 대한 리소스 공유를 생성합니다.
1. 리소스 공유의 **이름**을 입력합니다.
1. **리소스 - 선택 사항**에서 **보안 그룹**을 선택합니다.
1. 보안 그룹을 선택합니다. 보안 그룹은 기본 보안 그룹일 수 없으며 기본 VPC와 연결할 수 없습니다.
1. **다음**을 선택합니다.
1. 보안 주체가 수행하도록 허용할 작업을 검토하고 **다음**을 선택합니다.
1. **보안 주체 - 선택 사항** 아래에서 **조직 내에서만 공유 허용**을 선택합니다.
1. **보안 주체**에서 다음 보안 주체 유형 중 하나를 선택하고 적절한 숫자를 입력합니다.
+ **AWS 계정**: 조직에 있는 계정의 계정 번호입니다.
+ **조직**: AWS Organizations ID입니다.
+ **조직 단위(OU)**: 조직에 있는 OU의 ID입니다.
+ **IAM 역할**: IAM 역할의 ARN입니다. 역할을 생성한 계정은 이 리소스 공유를 생성하는 계정과 동일한 조직의 멤버여야 합니다.
+ **IAM 사용자**: IAM 사용자의 ARN입니다. 사용자를 생성한 계정은 이 리소스 공유를 생성하는 계정과 동일한 조직의 멤버여야 합니다.
+ **서비스 보안 주체**: 보안 그룹을 서비스 보안 주체와 공유할 수 없습니다.
1. **추가**를 선택합니다.
1. **다음**을 선택합니다.
1. **리소스 공유 생성**을 선택합니다.
1. **공유 리소스**에서 `Associated` **상태**가 표시될 때까지 기다립니다. 보안 그룹 연결에 실패하는 경우 위에 나열된 제한 사항 중 하나 때문일 수 있습니다. 보안 그룹의 세부 정보를 표시하고 세부 정보 페이지의 **공유** 탭에서 보안 그룹을 공유할 수 없는 이유와 관련된 메시지를 확인합니다.
1. VPC 콘솔 보안 그룹 목록으로 돌아갑니다.
1. 공유한 보안 그룹을 선택합니다.
1. **공유** 탭을 선택합니다. AWS RAM 리소스가 여기에 표시되어야 합니다. 그렇지 않으면 리소스 공유 생성이 실패한 것이며 다시 생성해야 할 수 있습니다.
------
#### [ Command line ]
**보안 그룹을 공유하려면**
1. 먼저와 AWS RAM과 공유하려는 보안 그룹에 대한 리소스 공유를 생성해야 합니다. AWS CLI를 사용하여 AWS RAM과의 리소스 공유를 생성하는 방법에 대한 단계는 *AWS RAM 사용 설명서*의 [AWS RAM에서 리소스 공유 생성](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html)을 참조하세요.
1. 생성된 리소스 공유 연결을 보려면 [get-resource-share-associations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/get-resource-share-associations.html)를 사용합니다.
------
이제 보안 그룹이 공유됩니다. 동일한 VPC 내의 공유 서브넷에서 [EC2 인스턴스를 시작](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html)할 때 보안 그룹을 선택할 수 있습니다.
## 보안 그룹 공유 중지
이 섹션에서는 AWS Management Console 및 AWS CLI를 사용하여 조직의 다른 계정과 공유한 보안 그룹의 공유를 중지하는 방법을 설명합니다.
------
#### [ AWS Management Console ]
**보안 그룹 공유를 중지하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **보안 그룹**을 선택합니다.
1. 보안 그룹을 선택하여 세부 정보를 표시합니다.
1. **공유** 탭을 선택합니다.
1. 보안 그룹 리소스 공유를 선택하고 **공유 중지**를 선택합니다.
1. **예, 공유 중지**를 선택합니다.
------
#### [ Command line ]
**보안 그룹 공유를 중지하려면**
[delete-resource-share](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-resource-share.html)를 사용하여 리소스 공유를 삭제합니다.
------
보안 그룹이 더 이상 공유되지 않습니다. 소유자가 보안 그룹 공유를 중지하면 다음 규칙이 적용됩니다.
+ 기존 참가자의 탄력적 네트워크 인터페이스(ENI)는 공유되지 않은 보안 그룹에 대한 모든 보안 그룹 규칙 업데이트를 계속 가져옵니다. 공유를 해제하면 참가자가 공유되지 않은 그룹과의 새 연결을 생성할 수 없습니다.
+ 참가자는 더 이상 공유되지 않은 보안 그룹을 자신이 소유한 ENI와 연결할 수 없습니다.
+ 참가자는 공유되지 않은 보안 그룹과 여전히 연결되어 있는 ENI를 설명하고 삭제할 수 있습니다.
+ 참가자에게 공유되지 않은 보안 그룹과 연결된 ENI가 여전히 있는 경우 소유자는 공유되지 않은 보안 그룹을 삭제할 수 없습니다. 소유자는 참가자가 모든 ENI에서 보안 그룹의 연결을 해제(제거)한 후에만 보안 그룹을 삭제할 수 있습니다.
+ 참가자는 공유되지 않은 보안 그룹과 연결된 ENI를 사용하여 새 EC2 인스턴스를 시작할 수 없습니다.
# 네트워크 액세스 제어 목록으로 서브넷 트래픽 제어
*네트워크 액세스 제어 목록(ACL)*은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부합니다. VPC에 대한 기본 네트워크 ACL을 사용하거나 보안 그룹에 대한 규칙과 유사한 규칙을 사용하여 VPC에 대한 사용자 지정 네트워크 ACL을 생성하여 VPC에 보안 계층을 추가할 수 있습니다.
네트워크 ACL을 사용해도 추가 요금이 부과되지 않습니다.
다음 다이어그램에서는 서브넷이 2개인 VPC를 보여줍니다. 각 서브넷에 네트워크 ACL이 있습니다. 트래픽이 VPC로 들어오면(예: 피어링된 VPC, VPN 연결 또는 인터넷의 트래픽) 라우터에서 트래픽을 대상으로 보냅니다. 네트워크 ACL A에서는 서브넷 1로 향하는 트래픽 중 서브넷 1로 들어가도록 허용되는 트래픽과 서브넷 1 외부 위치로 향하는 트래픽 중 서브넷 1에서 나가도록 허용되는 트래픽을 결정합니다. 마찬가지로, 네트워크 ACL B에서는 서브넷 2에 들어오고 나갈 수 있는 트래픽을 결정합니다.
![\[서브넷 2개와 각 서브넷의 네트워크 ACL이 있는 VPC.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/network-acl.png)
보안 그룹과 네트워크 ACL의 차이점에 대한 자세한 내용은 [보안 그룹 및 네트워크 ACL 비교](infrastructure-security.md#VPC_Security_Comparison)를 참조하세요.
**Topics**
+ [네트워크 ACL 기본 사항](#nacl-basics)
+ [네트워크 ACL 규칙](nacl-rules.md)
+ [VPC의 기본 네트워크 ACL](default-network-acl.md)
+ [VPC의 사용자 지정 네트워크 ACL](custom-network-acl.md)
+ [경로 MTU 검색 및 네트워크 ACL](path_mtu_discovery.md)
+ [VPC에 대한 네트워크 ACL 만들기](create-network-acl.md)
+ [VPC에 대한 네트워크 ACL 연결 관리](network-acl-associations.md)
+ [VPC의 네트워크 ACL 삭제](delete-network-acl.md)
+ [예: 서브넷의 인스턴스에 대한 액세스 제어](nacl-examples.md)
## 네트워크 ACL 기본 사항
다음은 시작하기 전에 네트워크 ACL에 대해 알아야 할 기본 사항입니다.
**네트워크 ACL 연결**
+ VPC에 있는 각 서브넷을 네트워크 ACL과 연결해야 합니다. 서브넷을 네트워크 ACL에 명시적으로 연결하지 않을 경우, 서브넷은 [기본 네트워크 ACL](default-network-acl.md)에 자동적으로 연결됩니다.
+ [사용자 지정 네트워크 ACL](custom-network-acl.md)을 생성하고 서브넷과 연결하여 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부할 수 있습니다.
+ 네트워크 ACL을 여러 서브넷과 연결할 수 있습니다. 그러나 서브넷은 한 번에 하나의 네트워크 ACL에만 연결할 수 있습니다. 네트워크 ACL을 서브넷과 연결하면 이전 연결은 제거됩니다.
**네트워크 ACL 규칙**
+ 네트워크 ACL에는 인바운드 규칙과 아웃바운드 규칙이 있습니다. [네트워크 ACL당 보유할 수 있는 규칙 수에는 할당량(또는 제한)이 있습니다](amazon-vpc-limits.md#vpc-limits-nacls). 각 규칙에서는 트래픽을 허용하거나 거부할 수 있습니다. 각 규칙에는 1부터 32766까지 번호가 있습니다. 규칙은 트래픽 허용 또는 거부가 결정될 때 가장 낮은 번호의 규칙부터 순서대로 평가됩니다. 트래픽이 규칙과 일치하면 규칙이 적용되며 추가 규칙은 평가되지 않습니다. 필요한 경우 나중에 새 규칙을 삽입할 수 있도록 증분 방식으로(예: 10 또는 100 단위씩 증분) 규칙을 생성하여 시작하는 것이 좋습니다.
+ 네트워크 ACL 규칙은 트래픽이 서브넷 내에서 라우팅될 때가 아니라 서브넷에 들어오고 나갈 때 평가됩니다.
+ NACL은 **상태 비저장 목록이므로 이전에 전송했거나 수신한 트래픽에 대한 정보가 저장되지 않습니다. 예를 들어, 서브넷에 대한 특정 인바운드 트래픽을 허용하는 NACL 규칙을 생성하는 경우 해당 트래픽에 대한 응답이 자동으로 허용되지 않습니다. 이는 보안 그룹의 작동 방식과 대조적입니다. 보안 그룹은 **상태 저장 그룹이므로 이전에 전송했거나 수신한 트래픽에 대한 정보가 저장됩니다. 예를 들어, 보안 그룹이 EC2 인스턴스에 대한 인바운드 트래픽을 허용하는 경우 아웃바운드 보안 그룹 규칙에 관계없이 응답이 자동으로 허용됩니다.
**제한 사항**
+ 네트워크 ACL에 대한 할당량(제한이라고도 함)이 있습니다. 자세한 내용은 [네트워크 ACL](amazon-vpc-limits.md#vpc-limits-nacls) 섹션을 참조하세요.
+ 네트워크 ACL은 Route 53 Resolver(VPC\$12 IP 주소 또는 AmazonProvidedDNS라고도 함)에서 송수신되는 DNS 요청을 차단할 수 없습니다. Route 53 Resolver를 통해 DNS 요청을 필터링하려면 [Route 53 Resolver DNS 방화벽](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html)을 활성화할 수 있습니다.
+ 네트워크 ACL은 인스턴스 메타데이터 서비스(IMDS)에 대한 트래픽을 차단할 수 없습니다. IMDS에 대한 액세스를 관리하려면 **Amazon EC2 사용 설명서의 [인스턴스 메타데이터 옵션 구성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)을 참조하세요.
+ 네트워크 ACL은 다음에서 송수신되는 트래픽을 필터링하지 않습니다.
+ Amazon Domain Name Services(DNS)
+ Amazon Dynamic Host Configuration Protocol(DHCP)
+ Amazon EC2 인스턴스 메타데이터
+ Amazon ECS 태스크 메타데이터 엔드포인트
+ Windows 인스턴스에 대한 라이선스 활성화
+ Amazon Time Sync Service
+ 기본 VPC 라우터에서 사용하는 예약된 IP 주소
# 네트워크 ACL 규칙
기본 네트워크 ACL에 규칙을 추가 또는 제거하거나, VPC에 대한 네트워크 ACL을 추가로 생성할 수 있습니다. 네트워크 ACL에서 규칙을 추가하거나 제거할 때 네트워크 ACL이 연결되어 있는 서브넷에 변경 사항이 자동으로 적용됩니다.
다음은 네트워크 ACL 규칙 중 일부입니다.
+ **규칙 번호**. 번호가 가장 낮은 규칙부터 평가됩니다. 규칙에 일치하는 트래픽이 있으면 이와 모순되는 상위 규칙이 있더라도 적용됩니다.
+ **유형**. 트래픽 유형(예: SSH)입니다. 모든 트래픽 또는 사용자 지정 범위를 지정할 수도 있습니다.
+ **프로토콜** . 표준 프로토콜 번호를 가진 어떤 프로토콜이든 지정할 수 있습니다. 자세한 내용은 [프로토콜 번호](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)를 참조하세요. ICMP를 프로토콜로 지정하면 ICMP 유형과 코드 중 일부 또는 전부를 지정할 수 있습니다.
+ **포트 범위**. 트래픽에 대한 수신 포트 또는 포트 범위입니다. 예를 들어, HTTP 트래픽의 경우 80입니다.
+ **소스**: . [인바운드 규칙만 해당] 트래픽의 소스(CIDR 범위)입니다.
+ **대상** [아웃바운드 규칙만 해당] 트래픽의 대상(CIDR 범위)입니다.
+ **허용/거부**. 지정된 트래픽을 *허용* 또는 *거부* 할지 여부입니다.
예시 규칙은 [예: 서브넷의 인스턴스에 대한 액세스 제어](nacl-examples.md) 섹션을 참조하세요.
## 고려 사항
+ 네트워크 ACL당 규칙 수에 대한 할당량(제한이라고도 함)이 있습니다. 자세한 내용은 [Amazon VPC 할당량](amazon-vpc-limits.md) 섹션을 참조하세요.
+ ACL에서 규칙을 추가하거나 삭제할 때 ACL과 연관된 서브넷이 변경될 수 있습니다. 변경 사항은 잠시 후 적용됩니다.
+ 명령줄 도구 또는 Amazon EC2 API를 사용하여 규칙을 추가하면 CIDR 범위가 표준 형식으로 자동 수정됩니다. 예를 들어 CIDR 범위에 `100.68.0.18/18`을 지정하면 `100.68.0.0/18` CIDR 범위를 가진 규칙이 작성됩니다.
+ 다양한 포트를 열어야 하지만, 거부하려는 범위에 속하는 특정 포트가 있는 경우 거부 규칙을 추가할 수 있습니다. 거부 규칙에는 더 넓은 범위의 포트 트래픽을 허용하는 규칙보다 적은 수를 지정해야 합니다.
+ 네트워크 ACL에서 규칙을 동시에 추가하고 삭제하는 경우 주의해야 합니다. 인바운드 또는 아웃바운드 규칙을 삭제한 다음 허용된 항목보다 많은 새 항목을 추가하면([Amazon VPC 할당량](amazon-vpc-limits.md) 참조) 삭제하도록 선택한 항목이 제거되고 새 항목이 추가되지 *않습니다*. 이로 인해 예기치 않은 연결 문제가 발생하고 VPC에 대한 액세스가 차단될 수 있습니다.
# VPC의 기본 네트워크 ACL
가상 프라이빗 클라우드(VPC)에는 기본 네트워크 ACL이 자동으로 제공됩니다. 기본 네트워크 ACL은 연결된 서브넷 안팎으로 전송되는 트래픽 흐름을 모두 허용하도록 구성되어 있습니다. 각 네트워크 ACL에는 규칙 번호가 별표(\$1)로 되어 있는 규칙도 포함되어 있습니다. 이러한 규칙은 패킷이 번호가 매겨진 다른 어떤 규칙과도 일치하지 않을 경우에는 거부되도록 되어 있습니다.
규칙을 추가하거나 번호가 매겨진 기본 규칙을 제거하여 기본 네트워크 ACL을 수정할 수 있습니다. 규칙 번호가 별표인 규칙은 삭제할 수 없습니다.
**기본 인바운드 규칙**
다음 표에서는 기본 네트워크 ACL의 기본 인바운드 규칙을 보여줍니다. IPv6에 대한 규칙은 연결된 IPv6 CIDR 블록으로 VPC를 생성하거나 IPv6 CIDR 블록을 VPC와 연결하는 경우에만 추가됩니다. 하지만 기본 네트워크 ACL의 인바운드 규칙을 수정한 경우 IPv6 블록을 VPC에 연결할 때 모든 인바운드 IPv6 트래픽을 허용하는 규칙이 추가되지는 않습니다.
| 규칙 \$1 | 유형 | 프로토콜 | 포트 범위 | 소스 | 허용/거부 |
| --- | --- | --- | --- | --- | --- |
| 100 | 모든 IPv4 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 허용 |
| 101 | 모든 IPv6 트래픽 | 모두 | 모두 | ::/0 | 허용 |
| \$1 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | DENY |
| \$1 | 모든 IPv6 트래픽 | 모두 | 모두 | ::/0 | DENY |
**기본 아웃바운드 규칙**
다음 표에서는 기본 네트워크 ACL의 기본 아웃바운드 규칙을 보여줍니다. IPv6에 대한 규칙은 연결된 IPv6 CIDR 블록으로 VPC를 생성하거나 IPv6 CIDR 블록을 VPC와 연결하는 경우에만 추가됩니다. 하지만 기본 네트워크 ACL의 아웃바운드 규칙을 수정한 경우 IPv6 블록을 VPC에 연결할 때 모든 아웃바운드 IPv6 트래픽을 허용하는 규칙이 추가되지는 않습니다.
| 규칙 \$1 | 유형 | 프로토콜 | 포트 범위 | 대상 주소 | 허용/거부 |
| --- | --- | --- | --- | --- | --- |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 허용 |
| 101 | 모든 IPv6 트래픽 | 모두 | 모두 | ::/0 | 허용 |
| \$1 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | DENY |
| \$1 | 모든 IPv6 트래픽 | 모두 | 모두 | ::/0 | DENY |
# VPC의 사용자 지정 네트워크 ACL
사용자 지정 네트워크 ACL을 생성하고 서브넷과 연결하여 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부할 수 있습니다. 자세한 내용은 [VPC에 대한 네트워크 ACL 만들기](create-network-acl.md) 섹션을 참조하세요.
각 네트워크 ACL에는 규칙 번호가 별표(\$1)로 된 기본 인바운드 규칙과 기본 아웃바운드 규칙이 포함되어 있습니다. 이러한 규칙은 패킷이 다른 어떤 규칙과도 일치하지 않을 경우에는 거부되도록 되어 있습니다.
규칙을 추가하거나 제거하여 네트워크 ACL을 수정할 수 있습니다. 규칙 번호가 별표인 규칙은 삭제할 수 없습니다.
추가하는 모든 규칙에 대해 응답 트래픽을 허용하는 인바운드 또는 아웃바운드 규칙이 있어야 합니다. 적절한 휘발성 포트 범위를 선택하는 방법에 대한 자세한 내용은 [휘발성 포트](#nacl-ephemeral-ports) 단원을 참조하세요.
**인바운드 규칙의 예**
다음 표에는 네트워크 ACL의 인바운드 규칙 예가 나와 있습니다. IPv6에 대한 규칙은 VPC에 연결된 IPv6 CIDR 블록이 있는 경우에만 추가됩니다. IPv4 및 IPv6 트래픽은 각각 개별적으로 평가됩니다. 따라서 IPv4 트래픽에 대한 규칙은 IPv6 트래픽에 적용되지 않습니다. 해당하는 IPv4 규칙 옆에 IPv6 규칙을 추가하거나, 마지막 IPv4 규칙 뒤에 IPv6 규칙을 추가할 수 있습니다.
패킷이 서브넷에 도달할 때, 이를 서브넷이 연결되어 있는 네트워크 ACL의 인바운드 규칙을 기준으로(번호가 가장 빠른 규칙부터 시작) 평가합니다. 예를 들어 HTTPS 포트(443)로 전송되는 IPv4 트래픽이 있다고 가정해 보겠습니다. 그런데 패킷이 규칙 100 또는 105와 일치하지 않고 서브넷으로의 트래픽을 허용하는 규칙 110과 일치합니다. 패킷이 포트 139(NetBIOS)로 전송되는 경우 번호가 매겨진 어떠한 규칙과도 일치하지 않으므로 IPv4 트래픽에 대한 \$1 규칙이 최종적으로 해당 패킷을 거부합니다.
| 규칙 \$1 | 유형 | 프로토콜 | 포트 범위 | 소스 | 허용/거부 | 설명 |
| --- | --- | --- | --- | --- | --- | --- |
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | 허용 | 어떤 IPv4 주소에서 이루어지는 인바운드 HTTP 트래픽도 모두 허용 |
| 105 | HTTP | TCP | 80 | ::/0 | 허용 | 어떤 IPv6 주소에서 이루어지는 인바운드 HTTP 트래픽도 모두 허용 |
| 110 | HTTPS | TCP | 443 | 0.0.0.0/0 | 허용 | 어떤 IPv4 주소에서 이루어지는 인바운드 HTTPS 트래픽도 모두 허용 |
| 115 | HTTPS | TCP | 443 | ::/0 | 허용 | 어떤 IPv6 주소에서 이루어지는 인바운드 HTTPS 트래픽도 모두 허용 |
| 120 | SSH | TCP | 22 | *192.0.2.0/24* | 허용 | 홈 네트워크의 퍼블릭 IPv4 주소 범위로부터의 인바운드 SSH 트래픽 허용(인터넷 게이트웨이를 통해) |
| 140 | 사용자 지정 TCP | TCP | *32768-65535* | 0.0.0.0/0 | 허용 | 인터넷으로부터의 인바운드 리턴 IPv4 트래픽 허용(서브넷에서 시작되는 요청에 대해). |
| 145 | 사용자 지정 TCP | TCP | *32768-65535* | ::/0 | 허용 | 인터넷으로부터의 인바운드 리턴 IPv6 트래픽 허용(서브넷에서 시작되는 요청에 대해). |
| \$1 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | DENY | 이전 규칙에서 아직 처리하지 않은 모든 인바운드 IPv4 트래픽 거부(수정 불가) |
| \$1 | 모든 트래픽 | 모두 | 모두 | ::/0 | DENY | 이전 규칙에서 아직 처리하지 않은 모든 인바운드 IPv6 트래픽 거부(수정 불가) |
**아웃바운드 규칙의 예**
다음 표에는 사용자 지정 네트워크 ACL의 아웃바운드 규칙 예가 나와 있습니다. IPv6에 대한 규칙은 VPC에 연결된 IPv6 CIDR 블록이 있는 경우에만 추가됩니다. IPv4 및 IPv6 트래픽은 각각 개별적으로 평가됩니다. 따라서 IPv4 트래픽에 대한 규칙은 IPv6 트래픽에 적용되지 않습니다. 해당하는 IPv4 규칙 옆에 IPv6 규칙을 추가하거나, 마지막 IPv4 규칙 뒤에 IPv6 규칙을 추가할 수 있습니다.
| 규칙 \$1 | 유형 | 프로토콜 | 포트 범위 | 대상 주소 | 허용/거부 | 설명 |
| --- | --- | --- | --- | --- | --- | --- |
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | 허용 | 서브넷에서 인터넷으로의 아웃바운드 IPv4 HTTP 트래픽 허용 |
| 105 | HTTP | TCP | 80 | ::/0 | 허용 | 서브넷에서 인터넷으로의 아웃바운드 IPv6 HTTP 트래픽 허용 |
| 110 | HTTPS | TCP | 443 | 0.0.0.0/0 | 허용 | 서브넷에서 인터넷으로의 아웃바운드 IPv4 HTTPS 트래픽 허용 |
| 115 | HTTPS | TCP | 443 | ::/0 | 허용 | 서브넷에서 인터넷으로의 아웃바운드 IPv6 HTTPS 트래픽 허용 |
| 120 | 사용자 지정 TCP | TCP | *1024-65535* | *192.0.2.0/24* | 허용 | 홈 네트워크로에서 전송되는 SSH 트래픽에 대한 아웃바운드 응답을 허용합니다. |
| 140 | 사용자 지정 TCP | TCP | *32768-65535* | 0.0.0.0/0 | 허용 | 인터넷에서 클라이언트에 대한 아웃바운드 IPv4 응답 허용(예: 웹 페이지 제공). |
| 145 | 사용자 지정 TCP | TCP | *32768-65535* | ::/0 | 허용 | 인터넷에서 클라이언트에 대한 아웃바운드 IPv6 응답 허용(예: 웹 페이지 제공). |
| \$1 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | DENY | 이전 규칙에서 아직 처리하지 않은 모든 아웃바운드 IPv4 트래픽을 거부합니다. |
| \$1 | 모든 트래픽 | 모두 | 모두 | ::/0 | DENY | 이전 규칙에서 아직 처리하지 않은 모든 아웃바운드 IPv6 트래픽을 거부합니다. |
## 휘발성 포트
이전 단원에서 예로 든 네트워크 ACL에는 32768-65535 범위의 휘발성 포트가 사용됩니다. 하지만 사용하거나 통신하는 클라이언트의 유형에 따라 다른 범위의 네트워크 ACL을 사용할 수 있습니다.
요청을 시작하는 클라이언트가 휘발성 포트 범위를 선택합니다. 범위는 클라이언트의 운영 체제에 따라 다릅니다.
+ 다수의 Linux 커널(Amazon Linux 커널 포함)이 포트 32768-61000을 사용합니다.
+ Elastic Load Balancing에서 시작된 요청은 포트 1024-65535를 사용합니다.
+ Windows Server 2003까지의 Windows 운영 체제에서는 포트 1025-5000을 사용합니다.
+ Windows Server 2008 이상 버전은 포트 49152-65535를 사용합니다.
+ NAT 게이트웨이는 포트 1024-65535를 사용합니다.
+ AWS Lambda 함수는 포트 1024-65535를 사용합니다.
예를 들어, 인터넷을 통해 Windows 10 클라이언트로부터 VPC에 있는 웹 서버로 요청이 수신되는 경우, 네트워크 ACL에는 포트 49152-65535로 트래픽을 전달할 수 있도록 하는 아웃바운드 규칙이 있어야 합니다.
VPC의 인스턴스가 요청을 시작하는 클라이언트인 경우, 사용자의 네트워크 ACL에는 인스턴스의 운영 체제별로 휘발성 포트로 트래픽을 전달할 수 있도록 하는 인바운드 규칙이 있어야 합니다.
실제로는 VPC에서 퍼블릭 쪽 인스턴스로 향하는 트래픽을 시작할 수도 있는 다양한 유형의 클라이언트를 포괄하기 위해, 휘발성 포트 1024-65535를 열 수 있습니다. 하지만 그 범위 내에 있는 악성 포트의 트래픽을 거부하기 위한 규칙을 ACL에 추가할 수도 있습니다. 광범위한 임시 포트를 여는 허용 규칙보다 거부 규칙을 먼저 테이블에 배치해야 합니다.
## 사용자 지정 네트워크 ACL 및 기타 AWS 서비스
사용자 지정 네트워크 ACL을 생성하는 경우 다른 AWS 서비스를 사용하여 생성하는 리소스에 미칠 수 있는 영향에 주의해야 합니다.
Elastic Load Balancing을 사용하는 경우 사용자의 백엔드 인스턴스에 대한 서브넷에 소스가 `0.0.0.0/0` 또는 서브넷의 CIDR인 모든 트래픽에 대해 *거부* 규칙을 추가한 네트워크 ACL이 있으면 로드 밸런서가 인스턴스에 대한 상태 확인을 수행할 수 없습니다. 로드 밸런서 및 백엔드 인스턴스에 권장되는 네트워크 ACL 규칙에 대한 자세한 내용은 다음을 참조하세요.
+ [Application Load Balancer를 위한 네트워크 ACL](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html)
+ [Network Load Balancer를 위한 네트워크 ACL](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#network-acls)
+ [Classic Load Balancer를 위한 네트워크 ACL](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-vpc-network-acls.html)
## 연결 문제 해결
Reachability Analyzer는 정적 구성 분석 도구입니다. Reachability Analyzer를 사용하여 VPC의 두 리소스 간 네트워크 연결성을 분석하고 디버깅할 수 있습니다. Reachability Analyzer에서는 연결할 수 있는 경우 이러한 리소스 간 가상 경로에 대한 홉별 세부 정보가 생성되고, 그렇지 않다면 차단 구성 요소가 식별됩니다. 예를 들면 누락되거나 잘못 구성된 네트워크 ACL 규칙이 식별될 수 있습니다.
자세한 내용은 [Reachability Analyzer 사용 설명서](https://docs.aws.amazon.com/vpc/latest/reachability/)를 참조하세요.
# 경로 MTU 검색 및 네트워크 ACL
경로 MTU 검색을 사용하여 두 디바이스 간의 경로 MTU를 확인할 수 있습니다. 경로 MTU는 발신 호스트와 수신 호스트 간의 경로에서 지원되는 최대 패킷 사이즈입니다.
IPv4의 경우 호스트가 수신 호스트의 MTU 또는 경로를 따르는 디바이스의 MTU보다 큰 패킷을 전송하는 경우 수신 호스트 또는 디바이스가 패킷을 삭제한 다음 `Destination Unreachable: Fragmentation Needed and Don't Fragment was Set`(유형 3, 코드 4)과 같은 ICMP 메시지를 반환합니다. 이렇게 하면 전송 호스트에 페이로드를 여러 개의 작은 패킷으로 분할한 다음 다시 전송하도록 지시합니다.
IPv6 프로토콜은 네트워크의 조각화를 지원하지 않습니다. 호스트가 수신 호스트의 MTU 또는 경로를 따르는 디바이스의 MTU보다 큰 패킷을 전송하는 경우 수신 호스트 또는 디바이스가 패킷을 삭제한 다음 `ICMPv6 Packet Too Big (PTB)`(유형 2)과 같은 ICMP 메시지를 반환합니다. 이렇게 하면 전송 호스트에 페이로드를 여러 개의 작은 패킷으로 분할한 다음 다시 전송하도록 지시합니다.
서브넷에 있는 호스트 간의 최대 MTU(전송 단위)가 다르거나 인스턴스가 인터넷을 통해 피어와 통신하는 경우 인바운드 및 아웃바운드 네트워크 ACL 규칙을 추가해야 합니다. 이렇게 하면 경로 MTU 검색이 올바르게 작동하고 패킷 손실을 방지할 수 있습니다. 유형에 대해 **사용자 지정 ICMP 규칙**을 선택하고 포트 범위(유형 3, 코드 4)에 대해 **대상에 연결할 수 없음**, **조각화 필요, DF 플래그 설정**을 선택합니다. traceroute를 사용할 경우에는 다음 규칙도 추가합니다. 즉, 유형에 **사용자 지정 ICMP 규칙**, 포트 범위에 **시간 초과**, **TTL 전송 만료**(유형 11, 코드 0)를 선택합니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [EC2 인스턴스에 대한 네트워크 MTU(최대 전송 단위)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html)를 참조하세요.
# VPC에 대한 네트워크 ACL 만들기
다음 태스크는 네트워크 ACL을 생성하고, 네트워크 ACL에 규칙을 추가한 다음, 네트워크 ACL을 서브넷과 연결하는 방법을 보여줍니다.
**Topics**
+ [1단계: 네트워크 ACL 생성](#CreateACL)
+ [2단계: 규칙 추가](#Rules)
+ [3단계: 서브넷을 네트워크 ACL과 연결](#NetworkACL)
+ [(선택 사항) Firewall Manager를 사용하여 네트워크 ACL 관리](#nacls-using-firewall-manager)
## 1단계: 네트워크 ACL 생성
VPC에 대한 사용자 지정 네트워크 ACL을 생성할 수 있습니다. 사용자 지정 네트워크 ACL의 초기 규칙은 모든 인바운드 및 아웃바운드 트래픽을 차단합니다. 새 사용자 지정 네트워크 ACL은 기본적으로 서브넷과 연결되지 않으며, 따라서 서브넷과 명시적으로 연결해야 합니다.
**콘솔을 사용하여 네트워크 ACL을 생성하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Network ACLs**를 선택합니다.
1. **네트워크 ACL 생성**을 선택합니다.
1. (선택 사항) **이름**에 네트워크 ACL의 이름을 입력합니다.
1. **VPC**에서 VPC를 선택합니다.
1. (선택 사항) **태그**에서 **태그 추가**를 선택하고 태그 키와 태그 값을 입력합니다.
1. **네트워크 ACL 생성**을 선택합니다.
**명령줄을 사용하여 네트워크 ACL을 생성하려면**
+ [create-network-acl](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-network-acl.html)(AWS CLI)
+ [New-EC2NetworkAcl](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2NetworkAcl.html)(AWS Tools for Windows PowerShell)
## 2단계: 규칙 추가
인바운드 또는 아웃바운드 트래픽을 허용하거나 거부하는 규칙을 추가할 수 있습니다.
규칙은 가장 낮은 번호의 규칙부터 시작해서 순서대로 처리됩니다. 순차 번호(101, 102, 103)를 사용하는 대신 규칙 번호 간에 간격을 두는 것이 좋습니다(예: 100, 200, 300). 그러면 기존 규칙의 번호를 다시 매길 필요 없이 새 규칙을 더 쉽게 추가할 수 있습니다.
Amazon EC2 API 또는 명령줄 도구를 사용하는 경우에는 규칙을 수정할 수 없습니다. 규칙을 추가 및 삭제할 수만 있습니다. Amazon VPC 콘솔을 사용하는 경우에는 기존 규칙의 항목을 수정할 수 있습니다. 콘솔은 기존 규칙을 제거하고 새 규칙을 추가합니다. ACL에서 규칙의 순서를 변경할 필요가 있는 경우에는 새 규칙 번호와 함께 새 규칙을 추가한 후에 원래 규칙은 삭제해야 합니다.
**콘솔을 사용하여 네트워크 ACL에 규칙을 추가하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Network ACLs**를 선택합니다.
1. 네트워크 ACL을 선택합니다.
1. 인바운드 규칙을 추가하려면 다음을 수행합니다.
1. **인바운드 규칙** 탭을 선택합니다.
1. **인바운드 규칙 편집**, **새 규칙 추가**를 차례로 선택합니다.
1. 아직 사용되지 않은 규칙 번호, 유형, 프로토콜, 포트 범위, 소스, 그리고 트래픽을 허용할지 아니면 거부할지 여부를 입력합니다. 일부 유형의 경우 프로토콜과 포트를 입력합니다. 포트 범위를 입력하라는 메시지가 표시되면 포트 번호 또는 포트 범위(예: 49152\$165535)를 입력합니다.
목록에 없는 프로토콜을 사용하려면 유형에서 **사용자 지정 프로토콜**을 선택한 다음 프로토콜을 선택합니다. 자세한 내용은 [IANA 프로토콜 번호](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)를 참조하세요.
1. **변경 사항 저장**을 선택합니다.
1. 아웃바운드 규칙을 추가하려면 다음을 수행합니다.
1. **Outbound rules**(아웃바운드 규칙) 탭을 선택합니다.
1. **아웃바운드 규칙 편집**, **새 규칙 추가**를 차례로 선택합니다.
1. 아직 사용되지 않은 규칙 번호, 유형, 프로토콜, 포트 범위, 소스, 그리고 트래픽을 허용할지 아니면 거부할지 여부를 입력합니다. 일부 유형의 경우 프로토콜과 포트를 입력합니다. 포트 범위를 입력하라는 메시지가 표시되면 포트 번호 또는 포트 범위(예: 49152\$165535)를 입력합니다.
목록에 없는 프로토콜을 사용하려면 유형에서 **사용자 지정 프로토콜**을 선택한 다음 프로토콜을 선택합니다. 자세한 내용은 [IANA 프로토콜 번호](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)를 참조하세요.
1. **변경 사항 저장**을 선택합니다.
**명령줄을 사용하여 네트워크 ACL에 새 규칙을 추가하려면**
+ [create-network-acl-entry](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-network-acl-entry.html)(AWS CLI)
+ [New-EC2NetworkAclEntry](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2NetworkAclEntry.html)(AWS Tools for Windows PowerShell)
**명령줄을 사용하여 네트워크 ACL의 규칙을 바꾸려면**
+ [replace-network-acl-entry](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-network-acl-entry.html)(AWS CLI)
+ [Set-EC2NetworkAclEntry](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2NetworkAclEntry.html)(AWS Tools for Windows PowerShell)
**명령줄을 사용하여 네트워크 ACL에서 규칙을 삭제하려면**
+ [delete-network-acl-entry](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-network-acl-entry.html)(AWS CLI)
+ [Remove-EC2NetworkAclEntry](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2NetworkAclEntry.html)(AWS Tools for Windows PowerShell)
## 3단계: 서브넷을 네트워크 ACL과 연결
특정 서브넷에 네트워크 ACL의 규칙을 적용하려면 서브넷을 네트워크 ACL과 연결해야 합니다. 네트워크 ACL을 여러 서브넷과 연결할 수 있습니다. 그러나 서브넷은 하나의 네트워크 ACL에만 연결될 수 있습니다. 기본적으로, 특정 ACL과 연결되지 않은 서브넷은 기본 네트워크 ACL과 연결됩니다.
**서브넷을 네트워크 ACL과 연결하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Network ACLs**를 선택한 후 네트워크 ACL을 선택합니다.
1. 세부 정보 창의 [**Subnet Associations**] 탭에서 [**Edit**]를 선택합니다. 네트워크 ACL과 연결할 서브넷에 대한 [**Associate**] 확인란을 선택한 후 [**Save**]를 선택합니다.
## (선택 사항) Firewall Manager를 사용하여 네트워크 ACL 관리
AWS Firewall Manager는 여러 계정과 리소스 간에 네트워크 ACL 관리 및 유지 관리 작업을 간소화합니다. Firewall Manager를 사용하여 조직의 계정 및 서브넷을 모니터링하고 정의한 네트워크 ACL 구성을 자동으로 적용할 수 있습니다. Firewall Manager는 조직 전체를 보호해야 하거나 중앙 관리자 계정으로 자동 보호할 새 서브넷을 자주 추가하는 경우에 특히 유용합니다.
Firewall Manager 네트워크 ACL 정책을 사용하면 단일 관리자 계정을 사용하여 조직 전체에서 사용하는 네트워크 ACL에 정의하려는 최소 규칙 세트를 구성, 모니터링 및 관리할 수 있습니다. 조직의 어떤 계정과 서브넷이 Firewall Manager 정책 범위 내에 속하는지 지정합니다. Firewall Manager는 범위 내 서브넷에 대한 네트워크 ACL의 규정 준수 상태를 보고하며, 규정에 부합하지 않는 네트워크 ACL을 자동으로 수정하도록 Firewall Manager를 구성할 수 있습니다.
자세한 내용은 *AWS Firewall Manager 개발자 가이드*에서 다음 리소스를 참조하세요.
+ [AWS Firewall Manager 사전 조건](https://docs.aws.amazon.com/waf/latest/developerguide/fms-prereq.html)
+ [AWS Firewall Manager 네트워크 ACL 정책 설정](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-network-acl.html)
+ [Firewall Manager로 네트워크 ACL 정책 사용](https://docs.aws.amazon.com/waf/latest/developerguide/network-acl-policies.html)
# VPC에 대한 네트워크 ACL 연결 관리
각 서브넷은 하나의 네트워크 ACL에 연결됩니다. 서브넷을 처음 생성하면 생성된 서브넷이 VPC의 기본 네트워크 ACL과 연결됩니다. 사용자 지정 네트워크 ACL을 생성한 후 하나 이상의 서브넷에 연결하여 이전 네트워크 ACL 연결을 대체할 수 있습니다.
**Topics**
+ [네트워크 ACL 연결 설명](#describe-network-acl-association)
+ [네트워크 ACL과 연결된 서브넷 변경](#DisassociateNetworkACL)
+ [서브넷과 연결된 네트워크 ACL 변경](#ChangeNetworkACL)
## 네트워크 ACL 연결 설명
서브넷과 연결된 네트워크 ACL을 설명할 수 있으며, 네트워크 ACL과 연결된 서브넷을 설명할 수도 있습니다.
**콘솔을 사용하여 서브넷과 연결된 네트워크 ACL을 설명하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Subnets**를 선택합니다.
1. 서브넷을 선택합니다.
1. **네트워크 ACL** 탭을 선택합니다.
**AWS CLI를 사용하여 서브넷과 연결된 네트워크 ACL을 설명하려면**
지정된 서브넷과 연결된 네트워크 ACL을 나열하려면 다음 [describe-network-acls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-acls.html) 명령을 사용합니다.
```
aws ec2 describe-network-acls --filters Name=association.subnet-id,Values=subnet-0d2d1b81e0bc9c6d4 --query NetworkAcls[*].NetworkAclId
```
다음은 예제 출력입니다.
```
[
"acl-03701d1f82d8c3fd6"
]
```
**콘솔을 사용하여 네트워크 ACL과 연결된 서브넷을 설명하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Network ACLs**를 선택합니다.
1. 네트워크 ACL을 선택합니다.
1. **서브넷 연결** 탭을 선택합니다.
**AWS CLI를 사용하여 네트워크 ACL과 연결된 서브넷을 설명하려면**
지정된 네트워크 ACL과 연결된 서브넷을 나열하려면 다음 [describe-network-acls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-acls.html) 명령을 사용합니다.
```
aws ec2 describe-network-acls --network-acl-ids acl-060415a18fcc9afde --query NetworkAcls[*].Associations[].SubnetId
```
다음은 예제 출력입니다.
```
[
"subnet-0d2d1b81e0bc9c6d4",
"subnet-0e990c67809773b19",
"subnet-0eb17d85f5dfd33b1",
"subnet-0e01d500780bb7468"
]
```
## 네트워크 ACL과 연결된 서브넷 변경
서브넷에서 사용자 지정 네트워크 ACL을 연결 해제할 수 있습니다. 서브넷과 사용자 지정 네트워크 ACL의 연결이 끊어지면 VPC의 기본 네트워크 ACL과 자동으로 연결됩니다. 이 변경 사항은 잠시 후 적용됩니다.
**네트워크 ACL과 연결된 서브넷을 변경하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Network ACLs**를 선택합니다.
1. 네트워크 ACL을 선택합니다.
1. **작업**, **서브넷 연결 편집**을 차례로 선택합니다.
1. **선택한 서브넷**에서 해당 서브넷을 제거합니다.
1. **변경 사항 저장**을 선택합니다.
## 서브넷과 연결된 네트워크 ACL 변경
서브넷과 연결되어 있는 네트워크 ACL을 변경할 수 있습니다. 예를 들어 서브넷을 생성하면 생성된 서브넷이 처음에는 VPC의 기본 네트워크 ACL과 연결됩니다. 사용자 지정 네트워크 ACL을 생성하는 경우 네트워크 ACL을 하나 이상의 서브넷과 연결하여 네트워크 ACL 규칙을 적용합니다.
서브넷의 네트워크 ACL을 변경하면 잠시 후에 변경 사항이 적용됩니다.
**서브넷과 연결된 네트워크 ACL을 변경하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Subnets**를 선택합니다.
1. 서브넷을 선택합니다.
1. **작업**, **네트워크 ACL 연결 편집**을 차례로 선택합니다.
1. **네트워크 ACL ID**에서 서브넷과 연결할 네트워크 ACL을 선택하고, 선택한 네트워크 ACL의 인바운드 및 아웃바운드 규칙을 검토합니다.
1. **저장**을 선택합니다.
**명령줄을 사용하여 네트워크 ACL 연결을 바꾸려면**
+ [replace-network-acl-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-network-acl-association.html)(AWS CLI)
+ [Set-EC2NetworkAclAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2NetworkAclAssociation.html)(AWS Tools for Windows PowerShell)
# VPC의 네트워크 ACL 삭제
사용을 마친 네트워크 ACL을 삭제할 수 있습니다. 서브넷이 연결되어 있는 네트워크 ACL은 삭제할 수 없습니다. 기본 네트워크 ACL은 삭제할 수 없습니다.
**콘솔을 사용하여 네트워크 ACL에서 서브넷 연결을 제거하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Network ACLs**를 선택합니다. **다음과 연결** 열에 각 네트워크 ACL에 연결된 서브넷의 수가 표시됩니다. 이 열은 연결된 서브넷이 없는 경우 `-`입니다.
1. 네트워크 ACL을 선택합니다.
1. **작업**, **서브넷 연결 편집**을 차례로 선택합니다.
1. 서브넷 연결을 제거합니다.
1. **변경 사항 저장**을 선택합니다.
**명령줄을 사용하여 연결을 포함한 네트워크 ACL을 설명하려면**
+ [describe-network-acls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-acls.html)(AWS CLI)
+ [Get-EC2NetworkAcl](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2NetworkAcl.html)(AWS Tools for Windows PowerShell)
**명령줄을 사용하여 네트워크 ACL 연결을 바꾸려면**
+ [replace-network-acl-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-network-acl-association.html)(AWS CLI)
+ [Set-EC2NetworkAclAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2NetworkAclAssociation.html)(AWS Tools for Windows PowerShell)
**콘솔을 사용하여 네트워크 ACL을 삭제하려면**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **Network ACLs**를 선택합니다.
1. 네트워크 ACL을 선택합니다.
1. **작업**, **네트워크 ACL 삭제**를 차례로 선택합니다.
1. 확인 메시지가 나타나면 **delete**을 입력한 다음 **삭제**를 선택합니다.
**명령줄을 사용하여 네트워크 ACL을 삭제하려면**
+ [delete-network-acl](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-network-acl.html)(AWS CLI)
+ [Remove-EC2NetworkAcl](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2NetworkAcl.html)(AWS Tools for Windows PowerShell)
# 예: 서브넷의 인스턴스에 대한 액세스 제어
이 예에서는 서브넷의 인스턴스가 서로 통신할 수 있으며, 신뢰할 수 있는 원격 컴퓨터가 관리 태스크를 수행할 목적으로 해당 인스턴스에 액세스할 수 있습니다. 원격 컴퓨터는 다이어그램에 나와 있는 것처럼 로컬 네트워크의 컴퓨터이거나 다른 서브넷 또는 VPC의 인스턴스일 수 있습니다. 서브넷에 대한 네트워크 ACL 규칙과 인스턴스에 대한 보안 그룹 규칙은 원격 컴퓨터의 IP 주소로부터의 액세스를 허용합니다. 인터넷 또는 다른 네트워크로부터의 다른 모든 트래픽은 거부됩니다.
![\[보안 그룹 및 NACL 사용\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/nacl-example-diagram.png)
네트워크 ACL을 사용하면, 네트워크 ACL을 방어의 백업 계층으로 사용하면서 인스턴스에 대한 보안 그룹 또는 보안 그룹 규칙을 변경할 수 있는 유연성을 얻을 수 있습니다. 예를 들어 출처에 관계없이 인바운드 SSH 액세스를 허용하도록 보안 그룹을 실수로 업데이트했지만 네트워크 ACL이 원격 컴퓨터의 IP 주소 범위로부터의 액세스만 허용하는 경우, 네트워크 ACL은 다른 IP 주소로부터의 인바운드 SSH 트래픽을 거부합니다.
## 네트워크 ACL 규칙
다음은 서브넷과 연결된 네트워크 ACL의 인바운드 규칙 예입니다. 이들 규칙은 서브넷의 모든 인스턴스에 적용됩니다.
| 규칙 \$1 | 유형 | 프로토콜 | 포트 범위 | 소스 | 허용/거부 | 설명 |
| --- | --- | --- | --- | --- | --- | --- |
| 100 | SSH | TCP | 22 | 172.31.1.2/32 | 허용 | 원격 컴퓨터로부터의 인바운드 트래픽을 허용합니다. |
| \$1 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | DENY | 다른 모든 인바운드 트래픽을 거부합니다. |
다음은 서브넷과 연결된 네트워크 ACL의 아웃바운드 규칙 예입니다. 네트워크 ACL은 상태가 저장되지 않습니다. 따라서 인바운드 트래픽에 대한 응답을 허용하는 규칙을 포함해야 합니다.
| 규칙 \$1 | 유형 | 프로토콜 | 포트 범위 | 대상 주소 | 허용/거부 | 설명 |
| --- | --- | --- | --- | --- | --- | --- |
| 100 | 사용자 지정 TCP | TCP | 1024-65535 | 172.31.1.2/32 | 허용 | 원격 컴퓨터에 대한 아웃바운드 응답을 허용합니다. |
| \$1 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | DENY | 다른 모든 아웃바운드 트래픽을 거부합니다. |
## 보안 그룹 규칙
다음은 인스턴스에 연결된 보안 그룹에 대한 인바운드 규칙 예입니다. 이들 규칙은 보안 그룹과 연결된 모든 인스턴스에 적용됩니다. 인스턴스와 연결된 키 페어의 프라이빗 키가 있는 사용자는 원격 컴퓨터에서 SSH를 사용하여 이 인스턴스에 연결할 수 있습니다.
| 프로토콜 유형 | 프로토콜 | 포트 범위 | 소스 | 설명 |
| --- | --- | --- | --- | --- |
| 모든 트래픽 | 모두 | 모두 | sg-1234567890abcdef0 | 이 보안 그룹과 연결된 인스턴스 간의 통신을 허용합니다. |
| SSH | TCP | 22 | 172.31.1.2/32 | 원격 컴퓨터로부터의 인바운드 SSH 액세스를 허용합니다. |
다음은 인스턴스에 연결된 보안 그룹에 대한 아웃바운드 규칙 예입니다. 보안 그룹은 상태가 저장됩니다. 따라서 인바운드 트래픽에 대한 응답을 허용하는 규칙은 필요하지 않습니다.
| 프로토콜 유형 | 프로토콜 | 포트 범위 | 대상 주소 | 설명 |
| --- | --- | --- | --- | --- |
| 모든 트래픽 | 모두 | 모두 | sg-1234567890abcdef0 | 이 보안 그룹과 연결된 인스턴스 간의 통신을 허용합니다. |
## 네트워크 ACL과 보안 그룹 간의 차이점
다음 표는 보안 그룹과 네트워크 ACL의 근본적인 차이를 요약한 것입니다.
| 기능 | 네트워크 ACL | 보안 그룹 |
| --- | --- | --- |
| 작업 수준 | 서브넷 수준 | 인스턴스 수준 |
| 범위 | 연결된 서브넷의 모든 인스턴스에 적용됨 | 보안 그룹과 연결된 모든 인스턴스에 적용됨 |
| 규칙 타입 | 규칙 허용 및 거부 | 규칙만 허용 |
| 규칙 평가 | 트래픽과 일치하는 항목이 발견될 때까지 규칙을 오름차순으로 평가합니다. | 트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가 |
| 트래픽 반환 | 허용 명시 필요(상태 비저장) | 자동 허용(상태 저장) |
# Amazon Virtual Private Cloud에서의 복원성
AWS 글로벌 인프라는 AWS 리전 및 가용 영역을 중심으로 구축됩니다. AWS 리전에서는 짧은 대기 시간, 높은 처리량, 높은 중복성을 갖춘 네트워크를 사용하여 연결된 물리적으로 분리되고 격리된 다수의 가용 영역을 제공합니다. 가용 영역을 사용하면 중단 없이 영역 간에 자동으로 장애 극복 조치가 이루어지는 애플리케이션 및 데이터베이스를 설계하고 운영할 수 있습니다. 가용 영역은 기존의 단일 또는 다중 데이터 센터 인프라보다 가용성, 내결함성, 확장성이 뛰어납니다.
AWS 리전 리전은 기본 구성 요소로, 각각 물리적으로 분리되고 격리된 여러 가용 영역이 있는 별개의 지리적 위치를 나타냅니다. 이러한 가용 영역은 짧은 지연 시간, 높은 처리량 및 높은 중복성을 갖춘 네트워킹 패브릭을 통해 연결되므로 가용 영역 간에 원활한 통신과 데이터 전송이 가능합니다.
가용 영역 아키텍처는 기존의 단일 또는 다중 데이터 센터 설정보다 훨씬 더 강력하고 내결함성을 갖도록 설계되었기 때문에 주요 차별화 요소입니다. 리전 내의 여러 가용 영역에 리소스를 분산하여 서비스 중단 없이 애플리케이션과 데이터베이스가 영역 간에 자동으로 장애 조치되도록 설계할 수 있습니다. 이러한 수준의 중복성과 고가용성은 미션 크리티컬 워크로드의 핵심 요구 사항이며, 이를 통해 조직은 복원력이 뛰어난 클라우드 네이티브 솔루션을 구축할 수 있습니다.
또한 AWS 인프라의 규모와 글로벌 지원 범위를 통해 고객은 애플리케이션을 최종 사용자에게 더 가깝게 배포하여 지연 시간을 줄이고 전반적인 사용자 경험을 개선할 수 있습니다. 전 세계 여러 리전을 사용할 수 있기 때문에 고객은 특정 규제 및 비즈니스 요구 사항에 따라 필요한 지리적 경계 내에서 데이터를 저장하고 처리할 수 있으므로 효과적인 데이터 주권 실현과 규정 준수가 가능합니다.
AWS 글로벌 인프라를 활용하여 조직은 변화하는 요건과 진화하는 비즈니스 요구에 유연하게 적응할 수 있는 고가용성, 내결함성, 확장성을 갖춘 클라우드 환경을 설계할 수 있습니다. 이러한 견고한 기반은 최신 클라우드 기반 애플리케이션 및 서비스를 성공적으로 구현하기 위한 핵심 지원 요소입니다.
AWS 리전 및 가용 영역에 대한 자세한 정보는 [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)를 참조하세요.
워크로드의 복원력 요구 사항을 충족하도록 VPC를 구성할 수 있습니다. 자세한 내용은 다음 자료를 참조하세요.
+ [복원력 패턴 및 장단점 이해](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)(AWS 아키텍처 블로그)
+ [네트워크 토폴로지 계획](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)(AWS Well-Architected 프레임워크)
+ [Amazon Virtual Private Cloud 연결 옵션](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)(AWS 백서)
# Amazon Virtual Private Cloud에 대한 규정 준수 확인
AWS 서비스가 특정 규정 준수 프로그램의 범위에 포함되는지 알아보려면 [규정 준수 프로그램 제공 범위 내 AWS 서비스](https://aws.amazon.com/compliance/services-in-scope/)를 참조하고 관심 있는 규정 준수 프로그램을 선택합니다. 일반적인 정보는 [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)을 참조하세요.
AWS Artifact를 사용하여 타사 감사 보고서를 다운로드할 수 있습니다. 자세한 내용은 [AWS Artifact에서 보고서 다운로드](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)를 참조하세요.
AWS 서비스 사용 시 규정 준수 책임은 데이터의 민감도, 회사의 규정 준수 목표 및 관련 법률 및 규정에 따라 결정됩니다. AWS 서비스 사용 시 규정 준수 책임에 대한 자세한 내용은 [AWS 보안 설명서](https://docs.aws.amazon.com/security/) 참조하세요.
# VPC 및 서브넷에 대한 퍼블릭 액세스 차단
VPC 퍼블릭 액세스 차단(BPA)은 전체 AWS 계정에서 권한을 사용하여 VPC 리소스에 대한 퍼블릭 인터넷 액세스를 차단할 수 있는 중앙 집중식 보안 기능으로, 보안 요구 사항을 준수하는 동시에 특정 예외 및 감사 기능에 대한 유연성을 제공합니다.
VPC BPA 기능에는 다음과 같은 모드가 있습니다.
+ **양방향**: 이 리전의 인터넷 게이트웨이 및 송신 전용 인터넷 게이트웨이(제외된 VPC 및 서브넷 제외)를 오가는 모든 트래픽이 차단됩니다.
+ **수신 전용**: 이 리전의 VPC에 대한 모든 인터넷 트래픽(제외된 VPC 또는 서브넷 제외)이 차단됩니다. NAT 게이트웨이 및 송신 전용 인터넷 게이트웨이를 오가는 트래픽만 허용되는데, 이러한 게이트웨이는 아웃바운드 연결만 설정되도록 허용하기 때문입니다.
차단하지 않으려는 트래픽에 대해서는 이 기능의 "제외 항목"을 생성할 수도 있습니다. 제외 항목은 계정의 VPC BPA 모드에서는 제외하고 양방향 또는 송신 전용 액세스를 허용하는 단일 VPC 또는 서브넷에 적용할 수 있는 모드입니다.
제외 항목에는 다음 모드 중 하나를 사용할 수 있습니다.
+ **양방향**: 제외된 VPC 및 서브넷을 오가는 모든 인터넷 트래픽이 허용됩니다.
+ **송신 전용**: 제외된 VPC 및 서브넷의 아웃바운드 인터넷 트래픽만 허용됩니다. 제외된 VPC 및 서브넷으로의 인바운드 인터넷 트래픽은 차단됩니다. 이 모드는 VPC BPA가 양방향으로 설정된 경우에만 적용됩니다.
**Topics**
+ [VPC BPA 기본 사항](security-vpc-bpa-basics.md)
+ [VPC BPA의 영향 평가 및 VPC BPA 모니터링](security-vpc-bpa-assess-impact-main.md)
+ [고급 예제](security-vpc-bpa-example.md)
# VPC BPA 기본 사항
이 섹션에서는 VPC BPA를 지원하는 서비스와 이를 사용하는 방법을 포함하여 VPC BPA에 대한 중요한 세부 정보를 다룹니다.
**Topics**
+ [리전별 가용성](#security-vpc-bpa-reg-avail)
+ [AWS 서비스 영향 및 지원](#security-vpc-bpa-service-support)
+ [VPC BPA 제한 사항](#security-vpc-bpa-limits)
+ [IAM 정책을 사용하여 VPC BPA에 대한 액세스 제어](#security-vpc-bpa-iam-example)
+ [계정에 대해 VPC BPA 양방향 모드 활성화](#security-vpc-bpa-enable-bidir)
+ [VPC BPA 모드를 수신 전용으로 변경](#security-vpc-bpa-ingress-only)
+ [제외 항목 생성 및 삭제](#security-vpc-bpa-exclusions)
+ [조직 수준에서 VPC BPA 활성화](#security-vpc-bpa-exclusions-orgs)
## 리전별 가용성
VPC BPA는 GovCloud 및 중국 리전을 포함한 모든 상용 [AWS 리전](https://aws.amazon.com//about-aws/global-infrastructure/regions_az/)에서 사용할 수 있습니다.
이 설명서에서는 VPC BPA와 함께 Network Access Analyzer 및 Reachability Analyzer를 사용하는 방법에 대한 정보도 확인할 수 있습니다. Network Access Analyzer 및 Reachability Analyzer는 일부 상용 리전에서 사용할 수 없습니다. Network Access Analyzer 및 Reachability Analyzer의 리전별 가용성에 대한 자세한 내용은 *Network Access Analyzer 설명서*의 [제한 사항](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/how-network-access-analyzer-works.html#analyzer-limitations) 및 *Reachability Analyzer 설명서*의 [고려 사항](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html#considerations)을 참조하세요.
## AWS 서비스 영향 및 지원
다음 리소스 및 서비스는 VPC BPA를 지원하며 이러한 서비스 및 리소스로의 트래픽은 VPC BPA의 영향을 받습니다.
+ **인터넷 게이트웨이**: 모든 인바운드 및 아웃바운드 트래픽이 차단됩니다.
+ **송신 전용 인터넷 게이트웨이**: 모든 아웃바운드 트래픽이 차단됩니다. 송신 전용 인터넷 게이트웨이는 인바운드 트래픽을 허용하지 않습니다.
+ **Gateway Load Balancer(GWLB)**: GWLB 엔드포인트가 포함된 서브넷이 제외되더라도 모든 인바운드 및 아웃바운드 트래픽이 차단됩니다.
+ **NAT 게이트웨이**: 모든 인바운드 및 아웃바운드 트래픽이 차단됩니다. NAT 게이트웨이에는 인터넷 연결을 위한 인터넷 게이트웨이가 필요합니다.
+ **인터넷 연결 Network Load Balancer**: 모든 인바운드 및 아웃바운드 트래픽이 차단됩니다. 인터넷 연결 Network Load Balancer에는 인터넷 연결을 위한 인터넷 게이트웨이가 필요합니다.
+ **인터넷 연결 Application Load Balancer**: 모든 인바운드 및 아웃바운드 트래픽이 차단됩니다. 인터넷 연결 Application Load Balancer에는 인터넷 연결을 위한 인터넷 게이트웨이가 필요합니다.
+ **Amazon CloudFront VPC 오리진**: 모든 인바운드 및 아웃바운드 트래픽이 차단됩니다.
+ **Direct Connect**: 퍼블릭 가상 인터페이스(퍼블릭 IPv4 또는 글로벌 유니캐스트 IPv6 주소)를 사용하는 모든 인바운드 및 아웃바운드 트래픽이 차단됩니다. 이 트래픽은 연결에 인터넷 게이트웨이(또는 송신 전용 인터넷 게이트웨이)를 사용합니다.
+ **AWS Global Accelerator**: 인터넷에서 대상에 액세스할 수 있는지 여부에 관계없이 VPC에 대한 인바운드 트래픽이 차단됩니다.
+ **AWS Network Firewall**: 방화벽 엔드포인트가 포함된 서브넷이 제외되더라도 모든 인바운드 및 아웃바운드 트래픽이 차단됩니다.
+ **AWS Wavelength 통신 사업자 게이트웨이**: 모든 인바운드 및 아웃바운드 트래픽이 차단됩니다.
다음 서비스 및 리소스에 대한 트래픽과 같은 프라이빗 연결과 관련된 트래픽은 VPC BPA에 의해 차단되거나 영향을 받지 않습니다.
+ AWS Client VPN
+ AWS CloudWAN
+ AWS Outposts 로컬 게이트웨이
+ AWS Site-to-Site VPN
+ Transit Gateway
+ AWS Verified Access
**중요**
서브넷의 EC2 인스턴스에서 실행되는 어플라이언스(예: 타사 보안 또는 모니터링 도구)를 통해 수신 및 발신 트래픽을 라우팅하는 경우 VPC BPA를 사용할 때 이 서브넷은 트래픽의 흐름에서 제외되어야 합니다. 인터넷 게이트웨이가 아닌 어플라이언스 서브넷으로 트래픽을 보내는 다른 서브넷은 제외 대상으로 추가할 필요가 없습니다.
VPC의 리소스로부터 VPC에서 실행되는 다른 서비스(예: Route 53 Resolver 또는 )로 비공개로 전송되는 트래픽은 VPC의 인터넷 게이트웨이를 통과하지 않으므로 BPA가 켜져 있더라도 허용됩니다. 이러한 서비스는 사용자를 대신하여 VPC 외부의 리소스에 요청을 할 수 있으며(예: DNS 쿼리를 해결하기 위한 요청), 다른 보안 제어 수단을 통해 완화하지 않는 경우 VPC 내의 리소스 활동에 대한 정보를 노출할 수 있습니다.
## VPC BPA 제한 사항
VPC BPA 수신 전용 모드는 NAT 게이트웨이 및 송신 전용 인터넷 게이트웨이가 허용되지 않는 로컬 영역(LZ)에서는 지원되지 않습니다.
## IAM 정책을 사용하여 VPC BPA에 대한 액세스 제어
VPC BPA 기능에 대한 액세스를 허용/거부하는 IAM 정책의 예는 [VPC 및 서브넷에 대한 퍼블릭 액세스 차단](vpc-policy-examples.md#vpc-bpa-example-iam) 섹션을 참조하세요.
## 계정에 대해 VPC BPA 양방향 모드 활성화
VPC BPA 양방향 모드는 이 리전의 인터넷 게이트웨이 및 송신 전용 인터넷 게이트웨이(제외된 VPC 및 서브넷 제외)를 오가는 모든 트래픽을 차단합니다. 제외 항목에 관한 자세한 내용은 [제외 항목 생성 및 삭제](#security-vpc-bpa-exclusions) 섹션을 참조하세요.
**중요**
프로덕션 계정에서 VPC BPA를 활성화하기 전에 인터넷 액세스가 필요한 워크로드를 철저히 검토하는 것이 좋습니다.
**참고**
계정의 VPC 및 서브넷에서 VPC BPA를 활성화하려면 VPC 및 서브넷을 소유해야 합니다.
현재 다른 계정과 VPC 서브넷을 공유하는 경우 서브넷 소유자가 적용한 VPC BPA 모드가 참가자 트래픽에도 적용되지만 참가자는 공유 서브넷에 영향을 미치는 VPC BPA 설정을 제어할 수 없습니다.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **설정**을 선택합니다.
1. **퍼블릭 액세스 설정 편집**을 선택합니다.
1. **퍼블릭 액세스 차단 켜기** 및 **양방향**을 선택한 다음 **변경 사항 저장**을 선택합니다.
1. **상태**가 **켜기**로 변경될 때까지 기다립니다. VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
이제 VPC BPA 양방향 모드가 켜져 있습니다.
------
#### [ AWS CLI ]
1. VPC BPA 켜기:
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-bidirectional
```
VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
1. VPC BPA 상태 보기:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-options
```
------
## VPC BPA 모드를 수신 전용으로 변경
VPC BPA 수신 전용 모드는 이 리전의 VPC에 대한 모든 인터넷 트래픽(제외된 VPC 또는 서브넷 제외)을 차단합니다. NAT 게이트웨이 및 송신 전용 인터넷 게이트웨이를 오가는 트래픽만 허용되는데, 이러한 게이트웨이는 아웃바운드 연결만 설정되도록 허용하기 때문입니다.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **설정**을 선택합니다.
1. **퍼블릭 액세스 설정 편집**을 선택합니다.
1. 방향을 **수신 전용**으로 변경합니다.
1. 변경 사항을 저장하고 상태가 업데이트될 때까지 기다립니다. VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
------
#### [ AWS CLI ]
1. VPC BPA 차단 방향 수정:
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-ingress
```
VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
1. VPC BPA 상태 보기:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-options
```
------
## 제외 항목 생성 및 삭제
VPC BPA 제외 항목은 계정의 VPC BPA 모드에서는 제외하고 양방향 또는 송신 전용 액세스를 허용하는 단일 VPC 또는 서브넷에 적용할 수 있는 모드입니다. 계정에서 VPC BPA가 활성화되지 않은 경우에도 VPC 및 서브넷에 대한 VPC BPA 제외 항목을 생성하여 VPC BPA가 켜져 있을 때 제외 항목에 대한 트래픽 중단이 없도록 할 수 있습니다. VPC에 대한 제외는 VPC의 모든 서브넷에 자동으로 적용됩니다.
최대 50개의 제외 항목을 생성할 수 있습니다. 한도 증가 요청에 대한 자세한 내용은 [Amazon VPC 할당량](amazon-vpc-limits.md)의 *계정별 VPC BPA 제외 항목*을 참조하세요.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **설정**을 선택합니다.
1. **퍼블릭 액세스 차단** 탭의 **제외** 항목 아래에서 다음 중 하나를 수행합니다.
+ 제외를 삭제하려면 제외를 선택한 다음 **작업** > **제외 삭제**를 선택합니다.
+ 제외를 생성하려면 **제외 생성**을 선택하고 다음 단계를 계속합니다.
1. 차단 방향을 선택합니다.
+ **양방향**: 제외된 VPC 및 서브넷을 오가는 모든 인터넷 트래픽을 허용합니다.
+ **송신 전용**: 제외된 VPC 및 서브넷의 아웃바운드 인터넷 트래픽을 허용합니다. 제외된 VPC 및 서브넷으로의 인바운드 인터넷 트래픽을 차단합니다. 이 설정은 VPC BPA가 **양방향**으로 설정된 경우에 적용됩니다.
1. VPC 또는 서브넷을 선택합니다.
1. **제외 항목 생성**을 선택합니다.
1. **제외 상태**가 **활성**으로 변경될 때까지 기다립니다. 변경 사항을 보려면 제외 항목 테이블을 새로 고쳐야 할 수 있습니다.
제외 항목이 생성되었습니다.
------
#### [ AWS CLI ]
1. 제외 항목 허용 방향 수정:
```
aws ec2 --region us-east-2 create-vpc-block-public-access-exclusion --subnet-id subnet-id --internet-gateway-exclusion-mode allow-bidirectional
```
1. 제외 상태가 업데이트되는 데 시간이 걸릴 수 있습니다. 제외 항목의 상태를 보려면:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-exclusions --exclusion-ids exclusion-id
```
------
## 조직 수준에서 VPC BPA 활성화
AWS Organizations를 사용하여 조직의 계정을 관리하는 경우 [AWS Organizations 선언적 정책](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_declarative.html)을 사용하여 조직의 계정에 VPC BPA를 적용할 수 있습니다. VPC BPA 선언적 정책에 대한 자세한 내용은 *AWS Organizations 사용 설명서*의 [지원되는 선언적 정책](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-vpc-block-public-access)을 참조하세요.
**참고**
VPC BPA 선언적 정책을 사용하여 제외 허용 여부를 구성할 수 있지만 정책으로 제외를 생성할 수는 없습니다. 제외를 생성하려면 VPC를 소유한 계정에서 해당 제외를 생성해야 합니다. VPC BPA 제외에 대한 자세한 내용은 [제외 항목 생성 및 삭제](#security-vpc-bpa-exclusions) 섹션을 참조하세요.
VPC BPA 선언적 정책이 활성화된 경우 **퍼블릭 액세스 차단** 설정에서 **선언적 정책으로 관리됨**이 표시되며 계정 수준에서는 VPC BPA 설정을 수정할 수 없습니다.
# VPC BPA의 영향 평가 및 VPC BPA 모니터링
이 섹션에는 VPC BPA를 켜기 전에 VPC BPA의 영향을 평가하고 VPC BPA를 켠 후에 트래픽이 차단되는지 모니터링하는 방법에 대한 정보가 포함되어 있습니다.
**Topics**
+ [Network Access Analyzer를 사용하여 VPC BPA의 영향 평가](#security-vpc-bpa-assess-impact)
+ [흐름 로그를 사용하여 VPC BPA 영향 모니터링](#security-vpc-bpa-fl)
+ [CloudTrail을 사용하여 제외 항목 삭제 추적](#security-vpc-bpa-cloudtrail)
+ [Reachability Analyzer를 사용하여 연결이 차단되었는지 확인](#security-vpc-bpa-verify-RA)
## Network Access Analyzer를 사용하여 VPC BPA의 영향 평가
이 섹션에서는 VPC BPA를 활성화하여 액세스를 차단하기 *전*에 Network Access Analyzer를 사용하여 인터넷 게이트웨이를 사용하는 계정의 리소스를 확인하는 방법을 살펴봅니다. 이 분석을 사용하여 계정에서 VPC BPA를 켜고 트래픽을 차단할 때의 영향을 파악할 수 있습니다.
**참고**
Network Access Analyzer는 IPv6을 지원하지 않으므로 송신 전용 인터넷 게이트웨이 아웃바운드 IPv6 트래픽에 대한 VPC BPA의 잠재적 영향 확인에 사용할 수 없습니다.
Network Access Analyzer를 사용하여 수행하는 분석에는 요금이 부과됩니다. 자세한 내용을 알아보려면 *Network Access Analyzer Guide(Network Access Analyzer 설명서)*의 [가격](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html#pricing)을 참조하세요.
Network Access Analyzer의 리전별 가용성에 대한 자세한 내용은 *Network Access Analyzer 설명서*의 [제한 사항](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/how-network-access-analyzer-works.html#analyzer-limitations)을 참조하세요.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/networkinsights/](https://console.aws.amazon.com/networkinsights/)에서 AWS Network Insights 콘솔을 엽니다.
1. **Network Access Analyzer**를 선택합니다.
1. **네트워크 액세스 범위 생성**을 선택합니다.
1. **VPC 퍼블릭 액세스 차단의 영향 평가**를 선택하고 **다음**을 선택합니다.
1. 템플릿은 이미 계정의 인터넷 게이트웨이를 오가는 트래픽을 분석하도록 구성되어 있습니다. **소스** 및 **대상**에서 이를 확인할 수 있습니다.
1. **다음**을 선택합니다.
1. **네트워크 액세스 범위 생성**을 선택합니다.
1. 방금 생성한 범위를 선택하고 **분석**을 선택합니다.
1. 분석이 완료될 때까지 기다립니다.
1. 분석 결과를 확인합니다. **분석 결과** 아래의 각 행에는 패킷이 네트워크에서 계정의 인터넷 게이트웨이를 들어오고 나갈 때 거칠 수 있는 네트워크 경로가 표시됩니다. 이 경우 VPC BPA를 켜고 이러한 분석 결과에 나타나는 VPC 및/또는 서브넷 중 VPC BPA 제외 항목으로 구성된 것이 없는 경우 해당 VPC 및 서브넷으로의 트래픽이 제한됩니다.
1. 각 분석 결과를 확인하여 VPC BPA가 VPC의 리소스에 미치는 영향을 파악합니다.
영향 분석이 완료되었습니다.
------
#### [ AWS CLI ]
1. 네트워크 액세스 범위 생성:
```
aws ec2 create-network-insights-access-scope --region us-east-2 --match-paths "Source={ResourceStatement={ResourceTypes=["AWS::EC2::InternetGateway"]}}" "Destination={ResourceStatement={ResourceTypes=["AWS::EC2::InternetGateway"]}}"
```
1. 범위 분석 시작:
```
aws ec2 start-network-insights-access-scope-analysis --region us-east-2 --network-insights-access-scope-id nis-id
```
1. 분석 결과 가져오기:
```
aws ec2 get-network-insights-access-scope-analysis-findings --region us-east-2 --network-insights-access-scope-analysis-id nisa-0aa383a1938f94cd1 --max-items 1
```
결과는 계정의 모든 VPC에서 인터넷 게이트웨이를 들어오고 나가는 트래픽을 보여줍니다. 결과는 "분석 결과"로 구성됩니다. "FindingId": "AnalysisFinding-1"은 이것이 분석의 첫 번째 결과임을 나타냅니다. 여러 분석 결과가 있는 경우 각 분석 결과는 VPC BPA를 켜면 영향을 받는 트래픽 흐름을 나타냅니다. 첫 번째 분석 결과는 인터넷 게이트웨이("SequenceNumber": 1)에서 시작된 트래픽이 NACL("SequenceNumber": 2)을 거쳐 보안 그룹("SequenceNumber": 3)으로 전달되고 인스턴스("SequenceNumber": 4)에서 종료된 것을 보여줍니다.
1. 분석 결과를 확인하여 VPC BPA가 VPC의 리소스에 미치는 영향을 파악합니다.
영향 분석이 완료되었습니다.
------
## 흐름 로그를 사용하여 VPC BPA 영향 모니터링
VPC 흐름 로그는 VPC의 탄력적 네트워크 인터페이스에서 전송되고 수신되는 IP 트래픽에 대한 정보를 수집할 수 있는 기능입니다. 이 기능을 사용하여 VPC BPA가 인스턴스 네트워크 인터페이스에 도달하지 못하도록 차단한 트래픽을 모니터링할 수 있습니다.
[흐름 로그 작업](working-with-flow-logs.md)의 단계에 따라 VPC에 대한 흐름 로그를 생성합니다.
흐름 로그를 생성할 때 `reject-reason` 필드가 포함된 사용자 지정 형식을 사용해야 합니다.
흐름 로그를 볼 때 VPC BPA로 인해 ENI에 대한 트래픽이 거부된 경우 흐름 로그 항목에 `reject-reason`이 `BPA`로 표시됩니다.
VPC 흐름 로그의 표준 [제한 사항](flow-logs-limitations.md) 외에도 VPC BPA와 관련된 다음 제한 사항에 유의하세요.
+ VPC BPA의 흐름 로그에는 [건너뛴 레코드](flow-logs-records-examples.md#flow-log-example-no-data)가 포함되지 않습니다.
+ 흐름 로그에 `bytes` 필드를 포함하더라도 VPC BPA의 흐름 로그에는 [`bytes`](flow-log-records.md#flow-logs-fields)가 포함되지 않습니다.
## CloudTrail을 사용하여 제외 항목 삭제 추적
이 섹션에서는 AWS CloudTrail을 사용하여 VPC BPA 제외 항목 삭제를 모니터링하고 추적하는 방법을 설명합니다.
------
#### [ AWS Management Console ]
[https://console.aws.amazon.com/cloudtrailv2/](https://console.aws.amazon.com/cloudtrailv2/)의 AWS CloudTrail 콘솔에서 **리소스 유형** > `AWS::EC2::VPCBlockPublicAccessExclusion`을 조회하면 **CloudTrail 이벤트 기록**의 삭제된 제외 항목을 볼 수 있습니다.
------
#### [ AWS CLI ]
`lookup-events` 명령을 사용하여 제외 항목 삭제와 관련된 이벤트를 볼 수 있습니다.
```
aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::EC2::VPCBlockPublicAccessExclusion
```
------
## Reachability Analyzer를 사용하여 연결이 차단되었는지 확인
[VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)를 사용하면 VPC BPA 설정을 포함한 지정된 네트워크 구성에서 특정 네트워크 경로에 도달할 수 있는지 여부를 평가할 수 있습니다.
Reachability Analyzer의 리전별 가용성에 대한 자세한 내용은 *Reachability Analyzer 설명서*의 [고려 사항](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html#considerations)을 참조하세요.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/networkinsights/home#ReachabilityAnalyzer](https://console.aws.amazon.com/networkinsights/home#ReachabilityAnalyzer)에서 AWS Network Insights 콘솔을 엽니다.
1. **경로 생성 및 분석**을 클릭합니다.
1. **소스 유형**에서 **인터넷 게이트웨이**를 선택하고 **소스 드롭다운**에서 트래픽을 차단할 인터넷 게이트웨이를 선택합니다.
1. **대상 유형**에서 **인스턴스**를 선택하고 **대상** 드롭다운에서 트래픽을 차단할 인스턴스를 선택합니다.
1. **경로 생성 및 분석**을 클릭합니다.
1. 분석이 완료될 때까지 기다립니다. 몇 분 정도 걸릴 수 있습니다.
1. 완료되면 **연결성 상태**가 **연결할 수 없음**으로 나타나야 하고 **경로 세부 정보**에 이 연결성 문제의 원인이 `VPC_BLOCK_PUBLIC_ACCESS_ENABLED `로 표시됩니다.
------
#### [ AWS CLI ]
1. 소스의 트래픽을 차단하려는 인터넷 게이트웨이의 ID와 대상의 트래픽을 차단하려는 인스턴스의 ID를 사용하여 네트워크 경로를 생성합니다.
```
aws ec2 --region us-east-2 create-network-insights-path --source igw-id --destination instance-id --protocol TCP
```
1. 네트워크 경로에 대한 분석 시작:
```
aws ec2 --region us-east-2 start-network-insights-analysis --network-insights-path-id nip-id
```
1. 분석 결과 검색:
```
aws ec2 --region us-east-2 describe-network-insights-analyses --network-insights-analysis-ids nia-id
```
1. 연결성이 부족한 경우 `VPC_BLOCK_PUBLIC_ACCESS_ENABLED`가 `ExplanationCode`인지 확인합니다.
------
# 고급 예제
이 섹션에는 VPC 퍼블릭 액세스 차단 기능이 다양한 시나리오에서 작동하는 방식을 이해하는 데 도움이 되는 고급 예제가 포함되어 있습니다. 각 시나리오는 이전 시나리오를 기반으로 구축되므로 순서대로 단계를 완료하는 것이 중요합니다.
**중요**
프로덕션 계정에서 이 예제를 실행하지 마세요. 프로덕션 계정에서 VPC BPA를 활성화하기 전에 인터넷 액세스가 필요한 워크로드를 철저히 검토하는 것이 좋습니다.
**참고**
VPC BPA 기능을 완전히 이해하려면 계정에 특정 리소스가 필요합니다. 이 섹션에서는 이 기능의 작동 방식을 완전히 이해하는 데 필요한 리소스를 프로비저닝하는 데 사용할 수 있는 CloudFormation 템플릿을 제공합니다. CloudFormation 템플릿을 사용하여 프로비저닝하는 리소스와 Network Access Analyzer 및 Reachability Analyzer로 수행하는 분석에는 관련된 비용이 있습니다. 이 섹션의 템플릿을 사용하는 경우 이 예제를 완료한 후 정리 단계를 완료해야 합니다.
**Topics**
+ [CloudFormation 템플릿 배포(선택)](#security-vpc-bpa-example-deploy-cfn)
+ [Network Access Analyzer를 사용하여 VPC BPA의 영향 확인](#vpc-bpa-naa)
+ [시나리오 1 - VPC BPA가 켜져 있지 않은 인스턴스에 연결](#vpc-bpa-scenario-1-connect-scen1)
+ [시나리오 2 - 양방향 모드에서 VPC BPA 켜기](#vpc-bpa-scenario-1-connect-scen2)
+ [시나리오 3 - VPC BPA 모드를 수신 전용으로 변경](#vpc-bpa-scenario-3)
+ [시나리오 4 - 제외 생성](#vpc-bpa-scenario-4)
+ [시나리오 5 - 제외 모드 수정](#vpc-bpa-scenario-5)
+ [시나리오 6 - VPC BPA 모드 수정](#vpc-bpa-scenario-6)
+ [정리](#vpc-bpa-scenario-cleanup)
## CloudFormation 템플릿 배포(선택)
이 기능의 작동 방식을 확인하려면 VPC, 서브넷, 인스턴스 및 기타 리소스가 필요합니다. 이 데모를 더 쉽게 완료할 수 있도록 이 데모의 시나리오에 필요한 리소스를 빠르게 준비하는 데 사용할 수 있는 CloudFormation 템플릿을 아래에 제공했습니다. 이 단계는 선택 사항이며이 섹션의 시나리오에서 다이어그램을 볼 수 있습니다.
**참고**
NAT 게이트웨이 및 퍼블릭 IPv4 주소의 비용과 같이 CloudFormation 템플릿을 사용하여 이 섹션에서 생성하는 리소스에는 관련된 비용이 있습니다. 과도한 비용이 발생하지 않도록 정리 단계를 완료하여 이 예제를 위해 생성된 모든 리소스를 제거해야 합니다.
이 CloudFormation 템플릿은 VPC BPA에 필요한 기본 리소스를 생성하지만 VPC BPA 기능 자체는 활성화하지 않습니다. 여기에 배포된 리소스는 VPC BPA 기능을 별도로 활성화하도록 선택한 후 이를 이해하고 테스트하는 데 도움이 됩니다.
이 템플릿은 계정에 다음 리소스를 생성합니다.
+ 외부 전용 인터넷 게이트웨이
+ 인터넷 게이트웨이
+ NAT 게이트웨이
+ 퍼블릭 서브넷 2개
+ 프라이빗 서브넷 1개
+ 퍼블릭 및 프라이빗 IPv4 주소가 있는 EC2 인스턴스 2개
+ IPv6 주소 및 프라이빗 IPv4 주소가 있는 EC2 인스턴스 1개
+ 프라이빗 IPv4 주소만 있는 EC2 인스턴스 1개
+ SSH 및 ICMP 인바운드 트래픽이 허용되고 모든 아웃바운드 트래픽이 허용되는 보안 그룹
+ VPC 흐름 로그
+ 서브넷 B의 EC2 Instance Connect 엔드포인트 1개
아래 템플릿을 복사하여 .yaml 파일로 저장합니다.
```
AWSTemplateFormatVersion: '2010-09-09'
Description: Creates a VPC with public and private subnets, NAT gateway, and EC2 instances for VPC BPA.
Parameters:
InstanceAMI:
Description: ID of the Amazone Machine Image (AMI) to use with the instances launched by this template
Type: AWS::EC2::Image::Id
InstanceType:
Description: EC2 Instance type to use with the instances launched by this template
Type: String
Default: t2.micro
Resources:
# VPC
VPCBPA:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsHostnames: true
EnableDnsSupport: true
InstanceTenancy: default
Tags:
- Key: Name
Value: VPC BPA
# VPC IPv6 CIDR
VPCBPAIpv6CidrBlock:
Type: AWS::EC2::VPCCidrBlock
Properties:
VpcId: !Ref VPCBPA
AmazonProvidedIpv6CidrBlock: true
# EC2 Key Pair
VPCBPAKeyPair:
Type: AWS::EC2::KeyPair
Properties:
KeyName: vpc-bpa-key
# Internet Gateway
VPCBPAInternetGateway:
Type: AWS::EC2::InternetGateway
Properties:
Tags:
- Key: Name
Value: VPC BPA Internet Gateway
VPCBPAInternetGatewayAttachment:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
VpcId: !Ref VPCBPA
InternetGatewayId: !Ref VPCBPAInternetGateway
# Egress-Only Internet Gateway
VPCBPAEgressOnlyInternetGateway:
Type: AWS::EC2::EgressOnlyInternetGateway
Properties:
VpcId: !Ref VPCBPA
# Subnets
VPCBPAPublicSubnetA:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPCBPA
CidrBlock: 10.0.1.0/24
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: VPC BPA Public Subnet A
VPCBPAPublicSubnetB:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPCBPA
CidrBlock: 10.0.2.0/24
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: VPC BPA Public Subnet B
VPCBPAPrivateSubnetC:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPCBPA
CidrBlock: 10.0.3.0/24
MapPublicIpOnLaunch: false
Ipv6CidrBlock: !Select [0, !GetAtt VPCBPA.Ipv6CidrBlocks]
AssignIpv6AddressOnCreation: true
Tags:
- Key: Name
Value: VPC BPA Private Subnet C
# NAT Gateway
VPCBPANATGateway:
Type: AWS::EC2::NatGateway
Properties:
AllocationId: !GetAtt VPCBPANATGatewayEIP.AllocationId
SubnetId: !Ref VPCBPAPublicSubnetB
Tags:
- Key: Name
Value: VPC BPA NAT Gateway
VPCBPANATGatewayEIP:
Type: AWS::EC2::EIP
Properties:
Domain: vpc
Tags:
- Key: Name
Value: VPC BPA NAT Gateway EIP
# Route Tables
VPCBPAPublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPCBPA
Tags:
- Key: Name
Value: VPC BPA Public Route Table
VPCBPAPublicRoute:
Type: AWS::EC2::Route
DependsOn: VPCBPAInternetGatewayAttachment
Properties:
RouteTableId: !Ref VPCBPAPublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref VPCBPAInternetGateway
VPCBPAPublicSubnetARouteTableAssoc:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref VPCBPAPublicSubnetA
RouteTableId: !Ref VPCBPAPublicRouteTable
VPCBPAPublicSubnetBRouteTableAssoc:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref VPCBPAPublicSubnetB
RouteTableId: !Ref VPCBPAPublicRouteTable
VPCBPAPrivateRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPCBPA
Tags:
- Key: Name
Value: VPC BPA Private Route Table
VPCBPAPrivateRoute:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref VPCBPAPrivateRouteTable
DestinationCidrBlock: 0.0.0.0/0
NatGatewayId: !Ref VPCBPANATGateway
VPCBPAPrivateSubnetCRoute:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref VPCBPAPrivateRouteTable
DestinationIpv6CidrBlock: ::/0
EgressOnlyInternetGatewayId: !Ref VPCBPAEgressOnlyInternetGateway
VPCBPAPrivateSubnetCRouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref VPCBPAPrivateSubnetC
RouteTableId: !Ref VPCBPAPrivateRouteTable
# EC2 Instances Security Group
VPCBPAInstancesSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupName: VPC BPA Instances Security Group
GroupDescription: Allow SSH and ICMP access
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 22
ToPort: 22
CidrIp: 0.0.0.0/0
- IpProtocol: icmp
FromPort: -1
ToPort: -1
CidrIp: 0.0.0.0/0
VpcId: !Ref VPCBPA
Tags:
- Key: Name
Value: VPC BPA Instances Security Group
# EC2 Instances
VPCBPAInstanceA:
Type: AWS::EC2::Instance
Properties:
ImageId: !Ref InstanceAMI
InstanceType: t2.micro
KeyName: !Ref VPCBPAKeyPair
SubnetId: !Ref VPCBPAPublicSubnetA
SecurityGroupIds:
- !Ref VPCBPAInstancesSecurityGroup
Tags:
- Key: Name
Value: VPC BPA Instance A
VPCBPAInstanceB:
Type: AWS::EC2::Instance
Properties:
ImageId: !Ref InstanceAMI
InstanceType: !Ref InstanceType
KeyName: !Ref VPCBPAKeyPair
SubnetId: !Ref VPCBPAPublicSubnetB
SecurityGroupIds:
- !Ref VPCBPAInstancesSecurityGroup
Tags:
- Key: Name
Value: VPC BPA Instance B
VPCBPAInstanceC:
Type: AWS::EC2::Instance
Properties:
ImageId: !Ref InstanceAMI
InstanceType: !Ref InstanceType
KeyName: !Ref VPCBPAKeyPair
SubnetId: !Ref VPCBPAPrivateSubnetC
SecurityGroupIds:
- !Ref VPCBPAInstancesSecurityGroup
Tags:
- Key: Name
Value: VPC BPA Instance C
VPCBPAInstanceD:
Type: AWS::EC2::Instance
Properties:
ImageId: !Ref InstanceAMI
InstanceType: !Ref InstanceType
KeyName: !Ref VPCBPAKeyPair
NetworkInterfaces:
- DeviceIndex: '0'
GroupSet:
- !Ref VPCBPAInstancesSecurityGroup
SubnetId: !Ref VPCBPAPrivateSubnetC
Ipv6AddressCount: 1
Tags:
- Key: Name
Value: VPC BPA Instance D
# Flow Logs IAM Role
VPCBPAFlowLogRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: vpc-flow-logs.amazonaws.com
Action: 'sts:AssumeRole'
Tags:
- Key: Name
Value: VPC BPA Flow Logs Role
VPCBPAFlowLogPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: VPC-BPA-FlowLogsPolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- 'logs:CreateLogGroup'
- 'logs:CreateLogStream'
- 'logs:PutLogEvents'
- 'logs:DescribeLogGroups'
- 'logs:DescribeLogStreams'
Resource: '*'
Roles:
- !Ref VPCBPAFlowLogRole
# Flow Logs
VPCBPAFlowLog:
Type: AWS::EC2::FlowLog
Properties:
ResourceId: !Ref VPCBPA
ResourceType: VPC
TrafficType: ALL
LogDestinationType: cloud-watch-logs
LogGroupName: /aws/vpc-flow-logs/VPC-BPA
DeliverLogsPermissionArn: !GetAtt VPCBPAFlowLogRole.Arn
LogFormat: '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${vpc-id} ${subnet-id} ${instance-id} ${tcp-flags} ${type} ${pkt-srcaddr} ${pkt-dstaddr} ${region} ${az-id} ${sublocation-type} ${sublocation-id} ${pkt-src-aws-service} ${pkt-dst-aws-service} ${flow-direction} ${traffic-path} ${reject-reason}'
Tags:
- Key: Name
Value: VPC BPA Flow Logs
# EC2 Instance Connect Endpoint
VPCBPAEC2InstanceConnectEndpoint:
Type: AWS::EC2::InstanceConnectEndpoint
Properties:
SecurityGroupIds:
- !Ref VPCBPAInstancesSecurityGroup
SubnetId: !Ref VPCBPAPublicSubnetB
Outputs:
VPCBPAVPCId:
Description: A reference to the created VPC
Value: !Ref VPCBPA
Export:
Name: vpc-id
VPCBPAPublicSubnetAId:
Description: The ID of the public subnet A
Value: !Ref VPCBPAPublicSubnetA
VPCBPAPublicSubnetAName:
Description: The name of the public subnet A
Value: VPC BPA Public Subnet A
VPCBPAPublicSubnetBId:
Description: The ID of the public subnet B
Value: !Ref VPCBPAPublicSubnetB
VPCBPAPublicSubnetBName:
Description: The name of the public subnet B
Value: VPC BPA Public Subnet B
VPCBPAPrivateSubnetCId:
Description: The ID of the private subnet C
Value: !Ref VPCBPAPrivateSubnetC
VPCBPAPrivateSubnetCName:
Description: The name of the private subnet C
Value: VPC BPA Private Subnet C
VPCBPAInstanceAId:
Description: The ID of instance A
Value: !Ref VPCBPAInstanceA
VPCBPAInstanceBId:
Description: The ID of instance B
Value: !Ref VPCBPAInstanceB
VPCBPAInstanceCId:
Description: The ID of instance C
Value: !Ref VPCBPAInstanceC
VPCBPAInstanceDId:
Description: The ID of instance D
Value: !Ref VPCBPAInstanceD
```
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/cloudformation/](https://console.aws.amazon.com/cloudformation/)에서 CloudFormation 콘솔을 엽니다.
1. **스택 생성**을 선택하고 .yaml 템플릿 파일을 업로드합니다.
1. 단계를 진행하여 템플릿을 시작합니다. [이미지 ID](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html)와 [인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)(예: t2.micro)을 입력해야 합니다. 또한 CloudFormation에서 흐름 로그를 생성하고 CloudWatch에 로깅할 수 있는 권한이 있는 IAM 역할을 생성하도록 허용해야 합니다.
1. 스택이 시작되면 **이벤트** 탭을 표시하여 진행 상황을 확인하고 계속하기 전에 스택이 완료되었는지 확인합니다.
------
#### [ AWS CLI ]
1. 다음 명령을 실행하여 CloudFormation 스택을 생성합니다.
```
aws cloudformation create-stack --stack-name VPC-BPA-stack --template-body file://sampletemplate.yaml --capabilities CAPABILITY_IAM --region us-east-2
```
출력:
```
{
"StackId": "arn:aws:cloudformation:us-east-2:470889052923:stack/VPC-BPA-stack/8a7a2cc0-8001-11ef-b196-06386a84b72f"
}
```
1. 진행 상황을 확인하고 계속하기 전에 스택이 완료되었는지 확인합니다.
```
aws cloudformation describe-stack-events --stack-name VPC-BPA-stack --region us-east-2
```
------
## Network Access Analyzer를 사용하여 VPC BPA의 영향 확인
이 섹션에서는 Network Access Analyzer를 사용하여 인터넷 게이트웨이를 사용하는 계정의 리소스를 확인합니다. 이 분석을 사용하여 계정에서 VPC BPA를 켜고 트래픽을 차단할 때의 영향을 파악할 수 있습니다.
Network Access Analyzer의 리전별 가용성에 대한 자세한 내용은 *Network Access Analyzer 설명서*의 [제한 사항](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/how-network-access-analyzer-works.html#analyzer-limitations)을 참조하세요.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/networkinsights/](https://console.aws.amazon.com/networkinsights/)에서 AWS Network Insights 콘솔을 엽니다.
1. **Network Access Analyzer**를 선택합니다.
1. **네트워크 액세스 범위 생성**을 선택합니다.
1. **VPC 퍼블릭 액세스 차단의 영향 평가**를 선택하고 **다음**을 선택합니다.
1. 템플릿은 이미 계정의 인터넷 게이트웨이를 오가는 트래픽을 분석하도록 구성되어 있습니다. **소스** 및 **대상**에서 이를 확인할 수 있습니다.
1. **다음**을 선택합니다.
1. **네트워크 액세스 범위 생성**을 선택합니다.
1. 방금 생성한 범위를 선택하고 **분석**을 선택합니다.
1. 분석이 완료될 때까지 기다립니다.
1. 분석 결과를 확인합니다. **분석 결과** 아래의 각 행에는 패킷이 네트워크에서 계정의 인터넷 게이트웨이를 들어오고 나갈 때 거칠 수 있는 네트워크 경로가 표시됩니다. 이 경우 VPC BPA를 켜고 이러한 분석 결과에 나타나는 VPC 및/또는 서브넷 중 VPC BPA 제외 항목으로 구성된 것이 없는 경우 해당 VPC 및 서브넷으로의 트래픽이 제한됩니다.
1. 각 분석 결과를 확인하여 VPC BPA가 VPC의 리소스에 미치는 영향을 파악합니다.
영향 분석이 완료되었습니다.
------
#### [ AWS CLI ]
1. 네트워크 액세스 범위 생성:
```
aws ec2 create-network-insights-access-scope --match-paths "Source={ResourceStatement={ResourceTypes=["AWS::EC2::InternetGateway"]}}" "Destination={ResourceStatement={ResourceTypes=["AWS::EC2::InternetGateway"]}}" --region us-east-2
```
출력:
```
{
"NetworkInsightsAccessScope": {
"NetworkInsightsAccessScopeId": "nis-04cad3c4b3a1d5e3e",
"NetworkInsightsAccessScopeArn": "arn:aws:ec2:us-east-2:470889052923:network-insights-access-scope/nis-04cad3c4b3a1d5e3e",
"CreatedDate": "2024-09-30T15:55:53.171000+00:00",
"UpdatedDate": "2024-09-30T15:55:53.171000+00:00"
},
"NetworkInsightsAccessScopeContent": {
"NetworkInsightsAccessScopeId": "nis-04cad3c4b3a1d5e3e",
"MatchPaths": [
{
"Source": {
"ResourceStatement": {
"ResourceTypes": [
"AWS::EC2::InternetGateway"
]
}
}
},
{
"Destination": {
"ResourceStatement": {
"ResourceTypes": [
"AWS::EC2::InternetGateway"
]
}
}
}
]
}
}
```
1. 범위 분석 시작:
```
aws ec2 start-network-insights-access-scope-analysis --network-insights-access-scope-id nis-04cad3c4b3a1d5e3e --region us-east-2
```
출력:
```
{
"NetworkInsightsAccessScopeAnalysis": {
"NetworkInsightsAccessScopeAnalysisId": "nisa-0aa383a1938f94cd1",
"NetworkInsightsAccessScopeAnalysisArn": "arn:aws:ec2:us-east-2:470889052923:network-insights-access-scope-analysis/nisa-0aa383a1938f94cd",
"NetworkInsightsAccessScopeId": "nis-04cad3c4b3a1d5e3e",
"Status": "running",
"StartDate": "2024-09-30T15:56:59.109000+00:00",
"AnalyzedEniCount": 0
}
}
```
1. 분석 결과 가져오기:
```
aws ec2 get-network-insights-access-scope-analysis-findings --network-insights-access-scope-analysis-id nisa-0aa383a1938f94cd1 --region us-east-2 --max-items 1
```
출력:
```
{
"AnalysisFindings": [
{
"NetworkInsightsAccessScopeAnalysisId": "nisa-0aa383a1938f94cd1",
"NetworkInsightsAccessScopeId": "nis-04cad3c4b3a1d5e3e",
"FindingId": "AnalysisFinding-1",
"FindingComponents": [
{
"SequenceNumber": 1,
"Component": {
"Id": "igw-04a5344b4e30486f1",
"Arn": "arn:aws:ec2:us-east-2:470889052923:internet-gateway/igw-04a5344b4e30486f1",
"Name": "VPC BPA Internet Gateway"
},
"OutboundHeader": {
"DestinationAddresses": [
"10.0.1.85/32"
]
},
"InboundHeader": {
"DestinationAddresses": [
"10.0.1.85/32"
],
"DestinationPortRanges": [
{
"From": 22,
"To": 22
}
],
"Protocol": "6",
"SourceAddresses": [
"0.0.0.0/5",
"100.0.0.0/10",
"96.0.0.0/6"
],
"SourcePortRanges": [
{
"From": 0,
"To": 65535
}
]
},
"Vpc": {
"Id": "vpc-0762547ec48b6888d",
"Arn": "arn:aws:ec2:us-east-2:470889052923:vpc/vpc-0762547ec48b6888d",
"Name": "VPC BPA"
}
},
{
"SequenceNumber": 2,
"AclRule": {
"Cidr": "0.0.0.0/0",
"Egress": false,
"Protocol": "all",
"RuleAction": "allow",
"RuleNumber": 100
},
"Component": {
"Id": "acl-06194fc3a4a03040b",
"Arn": "arn:aws:ec2:us-east-2:470889052923:network-acl/acl-06194fc3a4a03040b"
}
},
{
"SequenceNumber": 3,
"Component": {
"Id": "sg-093dde06415d03924",
"Arn": "arn:aws:ec2:us-east-2:470889052923:security-group/sg-093dde06415d03924",
"Name": "VPC BPA Instances Security Group"
},
"SecurityGroupRule": {
"Cidr": "0.0.0.0/0",
"Direction": "ingress",
"PortRange": {
"From": 22,
"To": 22
},
"Protocol": "tcp"
}
},
{
"SequenceNumber": 4,
"AttachedTo": {
"Id": "i-058db34f9a0997895",
"Arn": "arn:aws:ec2:us-east-2:470889052923:instance/i-058db34f9a0997895",
"Name": "VPC BPA Instance A"
},
"Component": {
"Id": "eni-0fa23f2766f03b286",
"Arn": "arn:aws:ec2:us-east-2:470889052923:network-interface/eni-0fa23f2766f03b286"
},
"InboundHeader": {
"DestinationAddresses": [
"10.0.1.85/32"
],
"DestinationPortRanges": [
{
"From": 22,
"To": 22
}
],
"Protocol": "6",
"SourceAddresses": [
"0.0.0.0/5",
"100.0.0.0/10",
"96.0.0.0/6"
],
"SourcePortRanges": [
{
"From": 0,
"To": 65535
}
]
},
"Subnet": {
"Id": "subnet-035d235a762eeed04",
"Arn": "arn:aws:ec2:us-east-2:470889052923:subnet/subnet-035d235a762eeed04",
"Name": "VPC BPA Public Subnet A"
},
"Vpc": {
"Id": "vpc-0762547ec48b6888d",
"Arn": "arn:aws:ec2:us-east-2:470889052923:vpc/vpc-0762547ec48b6888d",
"Name": "VPC BPA"
}
}
]
}
],
"AnalysisStatus": "succeeded",
"NetworkInsightsAccessScopeAnalysisId": "nisa-0aa383a1938f94cd1",
"NextToken": "eyJOZXh0VG9rZW4iOiBudWxsLCAiYm90b190cnVuY2F0ZV9hbW91bnQiOiAxfQ=="
}
```
결과는 계정의 모든 VPC에서 인터넷 게이트웨이를 들어오고 나가는 트래픽을 보여줍니다. 결과는 "분석 결과"로 구성됩니다. "FindingId": "AnalysisFinding-1"은 이것이 분석의 첫 번째 결과임을 나타냅니다. 여러 분석 결과가 있는 경우 각 분석 결과는 VPC BPA를 켜면 영향을 받는 트래픽 흐름을 나타냅니다. 첫 번째 분석 결과는 인터넷 게이트웨이("SequenceNumber": 1)에서 시작된 트래픽이 NACL("SequenceNumber": 2)을 거쳐 보안 그룹("SequenceNumber": 3)으로 전달되고 인스턴스("SequenceNumber": 4)에서 종료된 것을 보여줍니다.
1. 분석 결과를 확인하여 VPC BPA가 VPC의 리소스에 미치는 영향을 파악합니다.
영향 분석이 완료되었습니다.
------
## 시나리오 1 - VPC BPA가 켜져 있지 않은 인스턴스에 연결
이 단원에서는 인터넷 게이트웨이를 통해 인터넷에서 퍼블릭 서브넷 A 및 B의 EC2 인스턴스에 연결할 수 있으므로 인바운드 트래픽과 아웃바운드 트래픽을 모두 허용합니다. 프라이빗 서브넷의 인스턴스 C와 D는 NAT 게이트웨이 또는 송신 전용 인터넷 게이트웨이를 통해 아웃바운드 트래픽을 시작할 수 있지만 인터넷에서 직접 연결할 수는 없습니다. 이 설정은 일부 리소스에 대한 인터넷 액세스를 제공하는 동시에 다른 리소스를 보호합니다. 이 설정의 목적은 기준을 설정하고 VPC BPA를 활성화하기 전에 모든 인스턴스에 연결할 수 있는지 확인하기 위해 모든 인스턴스에 연결하고 퍼블릭 IP 주소를 ping합니다.
VPC BPA가 켜져 있지 않은 VPC의 다이어그램:
![\[VPC BPA가 활성화되지 않은 VPC를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/vpc-bpa-1.png)
### 1.1 인스턴스에 연결
이 섹션의 단계에 따라 VPC BPA가 꺼져 있는 인스턴스에 연결하여 문제 없이 연결할 수 있는지 확인합니다. 이 예제의 CloudFormation으로 생성된 모든 인스턴스에는 "VPC BPA Instance A"와 같은 이름이 있습니다.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 인스턴스 A 세부 정보를 엽니다.
1. **EC2 Instance Connect** > **EC2 Instance Connect 엔드포인트를 사용하여 연결** 옵션을 통해 인스턴스 A에 연결합니다.
1. **연결**을 선택합니다. 인스턴스에 성공적으로 연결되면 www.amazon.com을 ping하여 인터넷으로 아웃바운드 요청을 보낼 수 있는지 확인합니다.
1. 인스턴스 A에 연결할 때와 동일한 방법을 사용하여 인스턴스 B, C, D에 연결하고 ping www.amazon.com을 통해 인터넷으로 아웃바운드 요청을 보낼 수 있는지 테스트합니다.
------
#### [ AWS CLI ]
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 A를 ping하여 인바운드 트래픽 확인:
```
ping 18.225.8.244
```
출력:
```
Pinging 18.225.8.244 with 32 bytes of data:
Reply from 18.225.8.244: bytes=32 time=51ms TTL=110
Reply from 18.225.8.244: bytes=32 time=61ms TTL=110
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~_ ####_ Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
/ /
/m/'
Last login: Fri Sep 27 18:27:57 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING www-amazon-com.customer.fastly.net (18.65.233.187) 56(84) bytes of data.
64 bytes from 18.65.233.187 (18.65.233.187): icmp_seq=15 ttl=58 time=2.06 ms
64 bytes from 18.65.233.187 (18.65.233.187): icmp_seq=16 ttl=58 time=2.26 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 B를 ping하여 인바운드 트래픽 확인:
```
ping 3.18.106.198
```
출력:
```
Pinging 3.18.106.198 with 32 bytes of data:
Reply from 3.18.106.198: bytes=32 time=83ms TTL=110
Reply from 3.18.106.198: bytes=32 time=54ms TTL=110
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-08552a0774b5c8f72 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available.
Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
/ /
/m/'
Last login: Fri Sep 27 18:12:27 2024 from 3.16.146.5
[ec2-user@ip-10-0-2-98 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=1 ttl=249 time=1.55 ms
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=2 ttl=249 time=1.67 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
1. 인스턴스 C에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available.
Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
/ /
/m/'
Last login: Thu Sep 19 20:31:26 2024 from 10.0.2.86
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=1 ttl=248 time=1.75 ms
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=2 ttl=248 time=1.97 ms
64 bytes from server-3-160-24-26.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=3 ttl=248 time=1.08 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
1. 인스턴스 D에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
출력:
```
The authenticity of host '10.0.3.59 can't be established.
ECDSA key fingerprint is SHA256:c4naBCqbC61/cExDyccEproNU+1HHSpMSzl2J6cOtIZA8g.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.3.59' (ECDSA) to the list of known hosts.
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
_/ _/
_/m/'
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:ee00:7:49a5:5fd4:b121 (2600:9000:25f3:ee00:7:49a5:5fd4:b121)) 56 data bytes
64 bytes from 2600:9000:25f3:ee00:7:49a5:5fd4:b121 (2600:9000:25f3:ee00:7:49a5:5fd4:b121): icmp_seq=1 ttl=58 time=1.19 ms
64 bytes from 2600:9000:25f3:ee00:7:49a5:5fd4:b121 (2600:9000:25f3:ee00:7:49a5:5fd4:b121): icmp_seq=2 ttl=58 time=1.38 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
------
## 시나리오 2 - 양방향 모드에서 VPC BPA 켜기
이 섹션에서는 VPC BPA를 켜고 계정의 인터넷 게이트웨이에서 들어오고 나가는 트래픽을 차단합니다.
BPA 양방향 모드가 켜져 있는 VPC의 다이어그램:
![\[VPC BPA 양방향이 활성화된 VPC를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/vpc-bpa-2.png)
### 2.1 VPC BPA 양방향 모드 활성화
이 섹션을 완료하여 VPC BPA를 활성화합니다. VPC BPA 양방향 모드는 이 리전의 인터넷 게이트웨이 및 송신 전용 인터넷 게이트웨이(제외된 VPC 및 서브넷 제외)를 오가는 모든 트래픽을 차단합니다.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **설정**을 선택합니다.
1. **퍼블릭 액세스 설정 편집**을 선택합니다.
1. **퍼블릭 액세스 차단 켜기** 및 **양방향**을 선택한 다음 **변경 사항 저장**을 선택합니다.
1. **상태**가 **켜기**로 변경될 때까지 기다립니다. VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
이제 VPC BPA가 켜져 있습니다.
------
#### [ AWS CLI ]
1. modify-vpc-block-public-access-options 명령을 사용하여 VPC BPA 켜기:
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-bidirectional
```
VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
1. VPC BPA 상태 보기:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-options
```
------
### 2.2 인스턴스에 연결
이 섹션을 완료하여 인스턴스에 연결합니다.
------
#### [ AWS Management Console ]
1. 시나리오 1에서와 같이 인스턴스 A 및 인스턴스 B의 퍼블릭 IPv4 주소를 ping합니다. 트래픽이 차단되는지 확인합니다.
1. 시나리오 1에서와 같이**EC2 Instance Connect** > **EC2 Instance Connect 엔드포인트를 사용하여 연결** 옵션을 통해 인스턴스 A에 연결합니다. 엔드포인트 옵션을 사용해야 합니다.
1. **연결**을 선택합니다. 인스턴스에 연결되면 ping www.amazon.com을 수행합니다. 모든 아웃바운드 트래픽이 차단되는지 확인합니다.
1. 인스턴스 A에 연결할 때와 동일한 방법을 사용하여 인스턴스 B, C, D에 연결하고 인터넷으로 아웃바운드 요청을 보낼 수 있는지 테스트합니다. 모든 아웃바운드 트래픽이 차단되는지 확인합니다.
------
#### [ AWS CLI ]
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 A를 ping하여 인바운드 트래픽 확인:
```
ping 18.225.8.244
```
출력:
```
Pinging 18.225.8.244 with 32 bytes of data:
Request timed out.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
출력:
```
The authenticity of host '10.0.1.85' can't be established.
ECDSA key fingerprint is SHA256:3zo/gSss+HAZ+7eTyWlOB/Ke04IM+hadjsoLJeRTWBk.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.1.85' (ECDSA) to the list of known hosts.
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~_ ####_ Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
/ /
/m/'
Last login: Fri Sep 27 14:16:53 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 B를 ping하여 인바운드 트래픽 확인:
```
ping 3.18.106.198
```
출력:
```
Pinging 3.18.106.198 with 32 bytes of data:
Request timed out.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-08552a0774b5c8f72 --region us-east-2 --connection-type eice
```
출력:
```
The authenticity of host '10.0.2.98' can't be established.
ECDSA key fingerprint is SHA256:0IjXKKyVlDthcCfI0IPIJMUiItAOLYKRNLGTYURnFXo.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.2.98' (ECDSA) to the list of known hosts.
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
/ /
/m/'
Last login: Fri Sep 27 14:18:16 2024 from 3.16.146.5
[ec2-user@ip-10-0-2-98 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 인스턴스 C에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
/ /
/m/'
Last login: Tue Sep 24 15:17:56 2024 from 10.0.2.86
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 인스턴스 D에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
_/ _/
_/m/'
Last login: Fri Sep 27 16:42:01 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:8200:7:49a5:5fd4:b121 (2600:9000:25f3:8200:7:49a5:5fd4:b121)) 56 data bytes
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
------
### 2.3 선택 사항: Reachability Analyzer를 사용하여 연결이 차단되었는지 확인
[VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)를 사용하면 VPC BPA 설정을 포함한 지정된 네트워크 구성에서 특정 네트워크 경로에 도달할 수 있는지 여부를 파악할 수 있습니다. 이 예제에서는 이전에 시도한 것과 동일한 네트워크 경로를 분석하여 VPC BPA가 연결이 실패하는 이유인지 확인합니다.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/networkinsights/home#ReachabilityAnalyzer](https://console.aws.amazon.com/networkinsights/home#ReachabilityAnalyzer)에서 Network Insights 콘솔로 이동합니다.
1. **경로 생성 및 분석**을 클릭합니다.
1. **소스 유형**에서 **인터넷 게이트웨이**를 선택하고 **소스** 드롭다운에서 인터넷 게이트웨이에 태그가 지정된 **VPC BPA 인터넷 게이트웨이**를 선택합니다.
1. **대상 유형**에서 **인스턴스**를 선택하고 **대상** 드롭다운에서 **VPC BPA 인스턴스 A**로 태그가 지정된 인스턴스를 선택합니다.
1. **경로 생성 및 분석**을 클릭합니다.
1. 분석이 완료될 때까지 기다립니다. 몇 분 정도 걸릴 수 있습니다.
1. 완료되면 **연결성 상태**가 **연결할 수 없음**으로 나타나야 하고 **경로 세부 정보**에 `VPC_BLOCK_PUBLIC_ACCESS_ENABLED`가 원인으로 표시되어야 합니다.
------
#### [ AWS CLI ]
1. 인터넷 게이트웨이에 태그가 지정된 VPC BPA 인터넷 게이트웨이의 ID와 인스턴스에 태그가 지정된 VPC BPA 인스턴스 A의 ID를 사용하여 네트워크 경로 생성:
```
aws ec2 --region us-east-2 create-network-insights-path --source igw-id --destination instance-id --protocol TCP
```
1. 네트워크 경로에 대한 분석 시작:
```
aws ec2 --region us-east-2 start-network-insights-analysis --network-insights-path-id nip-id
```
1. 분석 결과 검색:
```
aws ec2 --region us-east-2 describe-network-insights-analyses --network-insights-analysis-ids nia-id
```
1. 연결성이 부족한 경우 `VPC_BLOCK_PUBLIC_ACCESS_ENABLED`가 `ExplanationCode`인지 확인합니다.
------
[흐름 로그를 사용하여 VPC BPA 영향 모니터링](security-vpc-bpa-assess-impact-main.md#security-vpc-bpa-fl)도 가능합니다.
## 시나리오 3 - VPC BPA 모드를 수신 전용으로 변경
이 섹션에서는 VPC BPA 트래픽 방향을 변경하고 NAT 게이트웨이 또는 송신 전용 인터넷 게이트웨이를 사용하는 트래픽만 허용합니다. BPA는 인터넷 게이트웨이를 통한 인바운드 트래픽을 차단하므로 퍼블릭 서브넷의 EC2 인스턴스 A와 B는 인터넷을 통해 연결할 수 없습니다. 프라이빗 서브넷의 인스턴스 C와 D는 NAT 게이트웨이와 송신 전용 인터넷 게이트웨이를 통해 아웃바운드 트래픽을 시작할 수 있으므로 인터넷에 계속 연결할 수 있습니다.
BPA 수신 전용 모드가 켜져 있는 VPC의 다이어그램:
![\[VPC BPA 수신 전용이 활성화된 VPC를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/vpc-bpa-3.png)
### 3.1 모드를 수신 전용으로 변경
이 섹션을 완료하여 모드를 변경합니다.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **설정**을 선택합니다.
1. **퍼블릭 액세스 차단** 탭에서 **퍼블릭 액세스 설정 편집**을 선택합니다.
1. VPC 콘솔에서 퍼블릭 액세스 설정을 수정하고 방향을 **수신 전용**으로 변경합니다.
1. 변경 사항을 저장하고 상태가 업데이트될 때까지 기다립니다. VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
------
#### [ AWS CLI ]
1. VPC BPA 모드 수정:
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-ingress
```
VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
1. VPC BPA 상태 보기:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-options
```
------
### 3.2 인스턴스에 연결
이 섹션을 완료하여 인스턴스에 연결합니다.
------
#### [ AWS Management Console ]
1. 시나리오 1에서와 같이 인스턴스 A 및 인스턴스 B의 퍼블릭 IPv4 주소를 ping합니다. 트래픽이 차단되는지 확인합니다.
1. 시나리오 1에서와 같이 EC2 Instance Connect를 사용하여 인스턴스 A 및 B에 연결하고 www.amazon.com을 ping합니다. 인스턴스 A 또는 B에서는 인터넷의 퍼블릭 사이트를 ping할 수 없으며 트래픽이 차단되는지 확인합니다.
1. 시나리오 1에서와 같이 EC2 Instance Connect를 사용하여 인스턴스 C 및 D에 연결하고 www.amazon.com을 ping합니다. 인스턴스 C 또는 D에서는 인터넷의 퍼블릭 사이트를 ping할 수 있으며 트래픽이 허용되는지 확인합니다.
------
#### [ AWS CLI ]
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 A를 ping하여 인바운드 트래픽 확인:
```
ping 18.225.8.244
```
출력:
```
Pinging 18.225.8.244 with 32 bytes of data:
Request timed out.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
출력:
```
The authenticity of host '10.0.1.85' can't be established.
ECDSA key fingerprint is SHA256:3zo/gSss+HAZ+7eTyWlOB/Ke04IM+hadjsoLJeRTWBk.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.1.85' (ECDSA) to the list of known hosts.
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~_ ####_ Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
/ /
/m/'
Last login: Fri Sep 27 14:16:53 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 B를 ping하여 인바운드 트래픽 확인:
```
ping 3.18.106.198
```
출력:
```
Pinging 3.18.106.198 with 32 bytes of data:
Request timed out.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-08552a0774b5c8f72 --region us-east-2 --connection-type eice
```
출력:
```
The authenticity of host '10.0.2.98 ' can't be established.
ECDSA key fingerprint is SHA256:0IjXKKyVlDthcCfI0IPIJMUiItAOLYKRNLGTYURnFXo.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.2.98' (ECDSA) to the list of known hosts.
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
_/ /
/m/'
Last login: Fri Sep 27 14:18:16 2024 from 3.16.146.5
[ec2-user@ip-10-0-2-98 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 인스턴스 C에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Tue Sep 24 15:28:09 2024 from 10.0.2.86
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=1 ttl=248 time=1.84 ms
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=2 ttl=248 time=1.40 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
1. 인스턴스 D에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 16:48:38 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:5800:7:49a5:5fd4:b121 (2600:9000:25f3:5800:7:49a5:5fd4:b121)) 56 data bytes
64 bytes from 2600:9000:25f3:5800:7:49a5:5fd4:b121 (2600:9000:25f3:5800:7:49a5:5fd4:b121): icmp_seq=14 ttl=58 time=1.47 ms
64 bytes from 2600:9000:25f3:5800:7:49a5:5fd4:b121 (2600:9000:25f3:5800:7:49a5:5fd4:b121): icmp_seq=16 ttl=58 time=1.59 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
------
## 시나리오 4 - 제외 생성
이 섹션에서는 제외 항목을 생성합니다. 그러면 VPC BPA는 제외 항목 *없이* 서브넷의 트래픽만 차단합니다. VPC BPA 제외 항목은 계정의 VPC BPA 모드에서는 제외하고 양방향 또는 송신 전용 액세스를 허용하는 단일 VPC 또는 서브넷에 적용할 수 있는 모드입니다. 계정에서 VPC BPA가 활성화되지 않은 경우에도 VPC 및 서브넷에 대한 VPC BPA 제외 항목을 생성하여 VPC BPA가 켜져 있을 때 제외 항목에 대한 트래픽 중단이 없도록 할 수 있습니다.
이 예제에서는 VPC BPA가 제외 항목의 트래픽에 어떤 영향을 미치는지 보여주기 위해 서브넷 A에 대한 제외 항목을 생성합니다.
BPA 수신 전용 모드가 켜져 있는 VPC와 양방향 모드가 켜져 있는 서브넷 A의 다이어그램:
![\[제외 항목을 포함하는 수신 전용 모드의 VPC BPA가 있는 VPC를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/vpc-bpa-4.png)
### 4.1 서브넷 A에 대한 제외 항목 생성
이 섹션을 완료하여 제외 항목을 생성합니다. VPC BPA 제외 항목은 계정의 VPC BPA 모드에서는 제외하고 양방향 또는 송신 전용 액세스를 허용하는 단일 VPC 또는 서브넷에 적용할 수 있는 모드입니다. 계정에서 VPC BPA가 활성화되지 않은 경우에도 VPC 및 서브넷에 대한 VPC BPA 제외 항목을 생성하여 VPC BPA가 켜져 있을 때 제외 항목에 대한 트래픽 중단이 없도록 할 수 있습니다.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **설정**을 선택합니다.
1. **퍼블릭 액세스 차단** 탭의 **제외 항목**에서 **제외 항목 생성**을 선택합니다.
1. **VPC BPA 퍼블릭 서브넷 A**를 선택하고 **양방향** 허용 방향이 선택되었는지 확인한 다음 **제외 항목 생성**을 선택합니다.
1. **제외 상태**가 **활성**으로 변경될 때까지 기다립니다. 변경 사항을 보려면 제외 항목 테이블을 새로 고쳐야 할 수 있습니다.
제외 항목이 생성되었습니다.
------
#### [ AWS CLI ]
1. 제외 항목 허용 방향 수정:
```
aws ec2 --region us-east-2 create-vpc-block-public-access-exclusion --subnet-id subnet-id --internet-gateway-exclusion-mode allow-bidirectional
```
1. 제외 상태가 업데이트되는 데 시간이 걸릴 수 있습니다. 제외 항목의 상태를 보려면:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-exclusions --exclusion-ids exclusion-id
```
------
### 4.2 인스턴스에 연결
이 섹션을 완료하여 인스턴스에 연결합니다.
------
#### [ AWS Management Console ]
1. 인스턴스 A의 퍼블릭 IPv4 주소를 ping합니다. 트래픽이 허용되는지 확인합니다.
1. 인스턴스 B의 퍼블릭 IPv4 주소를 ping합니다. 트래픽이 차단되는지 확인합니다.
1. 시나리오 1에서와 같이 EC2 Instance Connect를 사용하여 인스턴스 A에 연결하고 www.amazon.com을 ping합니다. 인스턴스 A에서는 인터넷의 퍼블릭 사이트를 ping할 수 있으며 트래픽이 허용되는지 확인합니다.
1. 시나리오 1에서와 같이 EC2 Instance Connect를 사용하여 인스턴스 B에 연결하고 www.amazon.com을 ping합니다. 인스턴스 B에서는 인터넷의 퍼블릭 사이트를 ping할 수 없으며 트래픽이 차단되는지 확인합니다.
1. 시나리오 1에서와 같이 EC2 Instance Connect를 사용하여 인스턴스 C 및 D에 연결하고 www.amazon.com을 ping합니다. 인스턴스 C 또는 D에서는 인터넷의 퍼블릭 사이트를 ping할 수 있으며 트래픽이 허용되는지 확인합니다.
------
#### [ AWS CLI ]
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 A를 ping하여 인바운드 트래픽 확인:
```
ping 18.225.8.244
```
출력:
```
Pinging 18.225.8.244 with 32 bytes of data:
Reply from 18.225.8.244: bytes=32 time=51ms TTL=110
Reply from 18.225.8.244: bytes=32 time=61ms TTL=110
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~_ ####_ Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
/ /
/m/'
Last login: Fri Sep 27 17:58:12 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=1 ttl=249 time=1.03 ms
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=2 ttl=249 time=1.72 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 B를 ping하여 인바운드 트래픽 확인:
```
ping 3.18.106.198
```
출력:
```
Pinging 3.18.106.198 with 32 bytes of data:
Request timed out.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-08552a0774b5c8f72 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
_/ /
/m/'
Last login: Fri Sep 27 18:12:03 2024 from 3.16.146.5
[ec2-user@ip-10-0-2-98 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 인스턴스 C에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
출력
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
_/ /
/m/'
Last login: Tue Sep 24 15:28:09 2024 from 10.0.2.86
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=1 ttl=248 time=1.84 ms
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=2 ttl=248 time=1.40 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
1. 인스턴스 D에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
출력
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:00:52 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(g2600-141f-4000-059a-0000-0000-0000-3bd4.deploy.static.akamaitechnologies.com (2600:141f:4000:59a::3bd4)) 56 data bytes
64 bytes from g2600-141f-4000-059a-0000-0000-0000-3bd4.deploy.static.akamaitechnologies.com (2600:141f:4000:59a::3bd4): icmp_seq=1 ttl=48 time=15.9 ms
64 bytes from g2600-141f-4000-059a-0000-0000-0000-3bd4.deploy.static.akamaitechnologies.com (2600:141f:4000:59a::3bd4): icmp_seq=2 ttl=48 time=15.8 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
------
### 4.3 선택 사항: Reachability Analyzer와의 연결 확인
이제 시나리오 2의 Reachability Analyzer에서 생성된 것과 동일한 네트워크 경로를 사용하여 새 분석을 실행할 수 있습니다. 퍼블릭 서브넷 A에 대한 제외 항목이 생성되었으므로 경로에 연결할 수 있는지 확인합니다.
Reachability Analyzer의 리전별 가용성에 대한 자세한 내용은 *Reachability Analyzer 설명서*의 [고려 사항](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html#considerations)을 참조하세요.
------
#### [ AWS Management Console ]
1. Network Insights 콘솔의 이전에 생성한 네트워크 경로에서 **분석 재실행**을 클릭합니다.
1. 분석이 완료될 때까지 기다립니다. 몇 분 정도 걸릴 수 있습니다.
1. 이제 경로가 **연결 가능**인지 확인합니다.
------
#### [ AWS CLI ]
1. 이전에 생성한 네트워크 경로 ID를 사용하여 새 분석 시작:
```
aws ec2 --region us-east-2 start-network-insights-analysis --network-insights-path-id nip-id
```
1. 분석 결과 검색:
```
aws ec2 --region us-east-2 describe-network-insights-analyses --network-insights-analysis-ids nia-id
```
1. `VPC_BLOCK_PUBLIC_ACCESS_ENABLED` 설명 코드가 더 이상 존재하지 않는지 확인합니다.
------
## 시나리오 5 - 제외 모드 수정
이 섹션에서는 제외 항목의 허용 트래픽 방향을 변경하여 VPC BPA에 어떤 영향을 미치는지 확인합니다.
**참고**
이 시나리오에서는 제외 모드를 송신 전용으로 변경합니다. 이렇게 하면 서브넷 A의 송신 전용 제외가 아웃바운드 트래픽을 허용하지 않으므로 아웃바운드 트래픽 허용을 예상한다면 불합리한 선택이 됩니다. 그러나 계정 수준 BPA는 수신 전용이므로 송신 전용 제외는 무시되고, 서브넷 A의 인터넷 게이트웨이로의 라우팅은 VPC BPA에 의해 제한되어 아웃바운드 트래픽을 차단합니다. 서브넷 A에서 아웃바운드 트래픽을 활성화하려면 VPC BPA를 양방향 모드로 전환해야 합니다.
BPA 수신 전용 모드가 켜져 있는 VPC와 송신 전용 모드가 켜져 있는 서브넷 A 제외 항목의 다이어그램:
![\[수신 전용 모드의 VPC BPA가 있어 NAT 게이트웨이를 통해 아웃바운드 트래픽이 허용되는 VPC를 보여 주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/vpc-bpa-5.png)
### 5.1 제외 항목 허용 방향을 송신 전용으로 변경
이 섹션을 완료하여 제외 항목 허용 방향을 변경합니다.
------
#### [ AWS Management Console ]
1. 시나리오 4에서 생성한 제외 항목을 편집하고 허용 방향을 **송신 전용**으로 변경합니다.
1. **변경 사항 저장**을 선택합니다.
1. **제외** 상태가 **활성**으로 변경될 때까지 기다립니다. VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다. 변경 사항을 보려면 제외 항목 테이블을 새로 고쳐야 할 수 있습니다.
------
#### [ AWS CLI ]
1. 제외 항목 허용 방향 수정:
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-exclusion --exclusion-id exclusion-id --internet-gateway-exclusion-mode allow-egress
```
VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
1. 제외 상태가 업데이트되는 데 시간이 걸릴 수 있습니다. 제외 항목의 상태를 보려면:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-exclusion
```
------
### 5.2 인스턴스에 연결
이 섹션을 완료하여 인스턴스에 연결합니다.
------
#### [ AWS Management Console ]
1. 인스턴스 A 및 B의 퍼블릭 IPv4 주소를 ping합니다. 트래픽이 차단되는지 확인합니다.
1. 시나리오 1에서와 같이 EC2 Instance Connect를 사용하여 인스턴스 A 및 B에 연결하고 www.amazon.com을 ping합니다. 인스턴스 A 또는 B에서는 인터넷의 퍼블릭 사이트를 ping할 수 없으며 트래픽이 차단되는지 확인합니다.
1. 시나리오 1에서와 같이 EC2 Instance Connect를 사용하여 인스턴스 C 및 D에 연결하고 www.amazon.com을 ping합니다. 인스턴스 C 또는 D에서는 인터넷의 퍼블릭 사이트를 ping할 수 있으며 트래픽이 허용되는지 확인합니다.
------
#### [ AWS CLI ]
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 A를 ping하여 인바운드 트래픽 확인:
```
ping 18.225.8.244
```
출력:
```
Pinging 18.225.8.244 with 32 bytes of data:
Request timed out.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:09:55 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 B를 ping하여 인바운드 트래픽 확인:
```
ping 3.18.106.198
```
출력:
```
Pinging 3.18.106.198 with 32 bytes of data:
Request timed out.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:09:55 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 인스턴스 C에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:00:31 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:a600:7:49a5:5fd4:b121 (2600:9000:25f3:a600:7:49a5:5fd4:b121)) 56 data bytes
64 bytes from 2600:9000:25f3:a600:7:49a5:5fd4:b121 (2600:9000:25f3:a600:7:49a5:5fd4:b121): icmp_seq=1 ttl=58 time=1.51 ms
64 bytes from 2600:9000:25f3:a600:7:49a5:5fd4:b121 (2600:9000:25f3:a600:7:49a5:5fd4:b121): icmp_seq=2 ttl=58 time=1.49 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
1. 인스턴스 D에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:13:55 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(2606:2cc0::374 (2606:2cc0::374)) 56 data bytes
64 bytes from 2606:2cc0::374 (2606:2cc0::374): icmp_seq=1 ttl=58 time=1.21 ms
64 bytes from 2606:2cc0::374 (2606:2cc0::374): icmp_seq=2 ttl=58 time=1.51 ms
```
ping이 성공하며 트래픽이 차단되지 않는지 확인합니다.
------
## 시나리오 6 - VPC BPA 모드 수정
이 섹션에서는 VPC BPA 차단 방향을 변경하여 트래픽에 미치는 영향을 알아봅니다. 이 시나리오에서 양방향 모드로 활성화된 VPC BPA는 시나리오 1과 마찬가지로 모든 트래픽을 차단합니다. 제외 항목에 NAT 게이트웨이 또는 송신 전용 인터넷 게이트웨이에 대한 액세스 권한이 없는 경우 트래픽이 차단됩니다.
BPA 양방향 모드가 켜져 있는 VPC와 송신 전용 모드가 켜져 있는 서브넷 A의 다이어그램:
![\[수신 전용 모드의 VPC BPA가 있어 NAT 게이트웨이를 통해 아웃바운드 트래픽이 허용되는 VPC를 보여 주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/vpc-bpa-6.png)
### 6.1 VPC BPA를 양방향 모드로 변경
이 섹션을 완료하여 VPC BPA 모드를 변경합니다.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **설정**을 선택합니다.
1. **퍼블릭 액세스 설정 편집**을 선택합니다.
1. 차단 방향을 **양방향**으로 변경한 다음 **변경 사항 저장**을 선택합니다.
1. **상태**가 **켜기**로 변경될 때까지 기다립니다. VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
------
#### [ AWS CLI ]
1. VPC BPA 차단 방향 수정:
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-bidirectional
```
VPC BPA 설정이 적용되고 상태가 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.
1. VPC BPA 상태 보기:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-options
```
------
### 6.2 인스턴스에 연결
이 섹션을 완료하여 인스턴스에 연결합니다.
------
#### [ AWS Management Console ]
1. 인스턴스 A 및 B의 퍼블릭 IPv4 주소를 ping합니다. 트래픽이 차단되는지 확인합니다.
1. 시나리오 1에서와 같이 EC2 Instance Connect를 사용하여 인스턴스 A 및 B에 연결하고 www.amazon.com을 ping합니다. 인스턴스 A 또는 B에서는 인터넷의 퍼블릭 사이트를 ping할 수 없으며 트래픽이 차단되는지 확인합니다.
1. 시나리오 1에서와 같이 EC2 Instance Connect를 사용하여 인스턴스 C 및 D에 연결하고 www.amazon.com을 ping합니다. 인스턴스 C 또는 D에서는 인터넷의 퍼블릭 사이트를 ping할 수 없으며 트래픽이 차단되는지 확인합니다.
------
#### [ AWS CLI ]
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 A를 ping하여 인바운드 트래픽 확인:
```
ping 18.225.8.244
```
출력:
```
Pinging 18.225.8.244 with 32 bytes of data:
Request timed out.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:17:44 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 퍼블릭 IPv4 주소를 사용하여 인스턴스 A를 ping하여 인바운드 트래픽 확인:
```
ping 3.18.106.198
```
출력:
```
Pinging 3.18.106.198 with 32 bytes of data:
Request timed out.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 프라이빗 IPv4 주소를 사용하여 연결하고 아웃바운드 트래픽 확인:
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:09:55 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 인스턴스 C에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:19:45 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:6200:7:49a5:5fd4:b121 (2600:9000:25f3:6200:7:49a5:5fd4:b121)) 56 data bytes
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
1. 인스턴스 D에 연결합니다. ping할 퍼블릭 IP 주소가 없으므로 EC2 Instance Connect를 사용하여 연결한 다음 인스턴스에서 퍼블릭 IP를 ping하여 아웃바운드 트래픽을 확인합니다.
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
출력:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:20:58 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:b400:7:49a5:5fd4:b121 (2600:9000:25f3:b400:7:49a5:5fd4:b121)) 56 data bytes
```
ping이 실패하고 트래픽이 차단되는지 확인합니다.
------
## 정리
이 섹션에서는 이 고급 예제에서 생성한 모든 리소스를 삭제합니다. 계정에서 생성된 리소스에 대한 과도한 추가 요금을 방지하려면 리소스를 정리하는 것이 중요합니다.
### CloudFormation 리소스 삭제
이 섹션을 완료하여 CloudFormation 템플릿으로 생성한 리소스를 삭제합니다.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/cloudformation/](https://console.aws.amazon.com/cloudformation/)에서 CloudFormation 콘솔을 엽니다.
1. VPC BPA 스택을 선택합니다.
1. **삭제**를 선택합니다.
1. 스택 삭제를 시작한 후 **이벤트** 탭을 표시하여 진행 상황을 확인하고 스택이 삭제되었는지 확인합니다. [스택을 강제로 삭제](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)해야 스택이 완전히 삭제될 수 있습니다.
------
#### [ AWS CLI ]
1. CloudFormation 스택을 삭제합니다. [스택을 강제로 삭제](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)해야 스택이 완전히 삭제될 수 있습니다.
```
aws cloudformation delete-stack --stack-name VPC-BPA-stack --region us-east-2
```
1. 진행 상황을 보고 스택이 삭제되었는지 확인합니다.
```
aws cloudformation describe-stack-events --stack-name VPC-BPA-stack --region us-east-2
```
------
### CloudTrail을 사용하여 제외 항목 삭제 추적
이 섹션의 단계에 따라 AWS CloudTrail을 사용하여 제외 항목 삭제를 추적합니다. 제외 항목을 삭제하면 CloudTrail 항목이 나타납니다.
------
#### [ AWS Management Console ]
[https://console.aws.amazon.com/cloudtrailv2/](https://console.aws.amazon.com/cloudtrailv2/)의 AWS CloudTrail 콘솔에서 **리소스 유형** > **AWS::EC2::VPCBlockPublicAccessExclusion**을 조회하면 CloudTrail 이벤트 기록에서 삭제된 제외 항목을 볼 수 있습니다.
------
#### [ AWS CLI ]
lookup-events 명령을 사용하여 제외 항목 삭제와 관련된 이벤트를 볼 수 있습니다.
```
aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::EC2::VPCBlockPublicAccessExclusion
```
------
고급 예제가 완료되었습니다.
# VPC에 대한 보안 모범 사례
다음 모범 사례는 일반적인 지침이며 완벽한 보안 솔루션을 나타내지는 않습니다. 이러한 모범 사례는 사용자의 환경에 적절하지 않거나 충분하지 않을 수 있으므로 규정이 아닌 참고용으로만 사용하세요.
+ VPC에 서브넷을 추가하여 애플리케이션을 호스팅하는 경우 여러 가용 영역에 서브넷을 생성합니다. 가용 영역은 AWS 리전에 중복 전원, 네트워킹 및 연결이 있는 하나 이상의 개별 데이터 센터입니다. 여러 가용 영역을 사용하면 프로덕션 애플리케이션의 가용성, 내결함성 및 확장성이 향상됩니다.
+ 보안 그룹을 사용하여 서브넷의 EC2 인스턴스에 대한 트래픽을 제어합니다. 자세한 내용은 [보안 그룹](vpc-security-groups.md) 단원을 참조하세요.
+ 네트워크 ACL을 사용하여 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 제어합니다. 자세한 내용은 [네트워크 액세스 제어 목록으로 서브넷 트래픽 제어](vpc-network-acls.md) 단원을 참조하세요.
+ (AWS Identity and Access Management)(IAM) 아이덴티티 페더레이션, 사용자, 역할을 사용하여 VPC의 AWS 리소스에 대한 액세스를 관리합니다. 자세한 내용은 [Amazon VPC용 자격 증명 및 액세스 관리](security-iam.md) 단원을 참조하세요.
+ VPC 흐름 로그를 사용하여 VPC, 서브넷 또는 네스워크 인터페이스에서 양쪽에서 이동하는 IP 트래픽을 모니터링합니다. 자세한 내용은 [VPC 흐름 로그](flow-logs.md) 단원을 참조하세요.
+ Network Access Analyzer를 사용하여 VPC에서 리소스에 대한 의도하지 않은 네트워크 액세스를 식별합니다. 자세한 내용을 알아보려면 [Network Access Analyzer Guide](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/)(Network Access Analyzer 설명서)를 참조하세요.
+ AWS Network Firewall를 사용하여 인바운드 및 아웃바운드 트래픽을 필터링하여 VPC를 모니터링하고 보호합니다. 자세한 정보는 [AWS Network Firewall 안내서](https://docs.aws.amazon.com/network-firewall/latest/developerguide/)를 참조하세요.
+ Amazon GuardDuty로 AWS 환경 내 계정과 컨테이너, 워크로드, 데이터에 대한 잠재적인 위협을 탐지할 수 있습니다. 기본 위협 탐지에는 Amazon EC2 인스턴스와 관련된 VPC 흐름 로그 모니터링이 포함됩니다. 자세한 내용은 *Amazon GuardDuty 사용 설명서*의 [VPC 흐름 로그](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_data-sources.html#guardduty_vpc)를 참조하세요.
VPC 보안 관련된 대한 자주 하는 질문에 대한 답변은 [Amazon VPC FAQ](https://aws.amazon.com/vpc/faqs/)의 *보안 및 필터링*을 참조하세요.