Amazon VPC FAQ

Amazon VPC를 사용하면 Amazon Web Services(AWS) 클라우드에서 논리적으로 격리된 공간을 프로비저닝하고, 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. 자체 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워킹 환경을 완벽하게 제어할 수 있습니다. 또한, 기업 데이터 센터와 VPC 사이에 하드웨어 가상 프라이빗 네트워크(VPN) 연결을 생성하여, 기업 데이터 센터의 확장으로서 AWS 클라우드를 사용할 수 있습니다.

Amazon VPC용 네트워크 구성을 손쉽게 사용자 지정할 수 있습니다. 예를 들어, 인터넷에 액세스할 수 있는 웹 서버를 위해 퍼블릭 서브넷을 생성할 수 있으며, 인터넷 액세스가 없는 프라이빗 서브넷에 데이터베이스나 애플리케이션 서버와 같은 백엔드 시스템을 배치할 수 있습니다. 보안 그룹 및 네트워크 액세스 제어 목록을 포함한 다중 보안 계층을 활용하여 각 서브넷에서 Amazon EC2 인스턴스에 대한 액세스를 제어하도록 지원할 수 있습니다.

Amazon VPC는 기존 네트워크를 사용하던 고객에게 익숙한 여러 객체로 구성되어 있습니다.

• Virtual Private Cloud: AWS 클라우드 내 논리적으로 격리된 가상 네트워크입니다. 선택한 범위에서 VPC의 IP 주소 공간을 정의합니다.
• 서브넷: 격리된 리소스 그룹을 배치할 수 있는 VPC IP 주소 범위의 한 세그먼트입니다.
• 인터넷 게이트웨이: 인터넷에 연결되는 Amazon VPC 측 게이트웨이입니다.
• NAT 게이트웨이: 프라이빗 서브넷에 있는 리소스가 인터넷에 액세스할 수 있게 해주는 고가용성 관리형 네트워크 주소 변환(NAT) 서비스입니다.
• 가상 프라이빗 게이트웨이: VPN에 연결되는 Amazon VPC 측 게이트웨이입니다.
• 피어링 연결: 피어링 연결을 사용하여 프라이빗 IP 주소를 통해 피어링되는 두 VPC 간 트래픽을 라우팅할 수 있습니다.
• VPC 엔드포인트: 인터넷 게이트웨이, VPN, Network Address Translation(NAT) 디바이스 또는 방화벽 프록시를 사용하지 않고 AWS에서 호스팅되는 서비스에 VPC 내에서부터 비공개로 연결할 수 있습니다.
• 송신 전용 인터넷 게이트웨이: VPC에서 인터넷으로 IPv6 트래픽에 대하여 송신 전용 액세스를 제공하는 상태 저장 게이트웨이입니다.

바로 사용 가능한 기본 VPC에 AWS 리소스가 자동으로 프로비저닝됩니다. AWS Management Console의 Amazon VPC 페이지로 이동하여 [Start VPC Wizard]를 선택하면 추가 VPC를 만들 수 있습니다.

네트워크 아키텍처에 대한 네 가지 기본 옵션을 확인할 수 있습니다. 옵션을 선택한 다음, VPC와 서브넷의 크기 및 IP 주소 범위를 변경할 수 있습니다. Hardware VPN Access 옵션을 선택하면 네트워크 상에서 VPN 하드웨어의 IP 주소를 지정해야 합니다. 보조 IP 범위와 게이트웨이를 추가 또는 제거하거나 더 많은 서브넷을 IP 범위에 추가하도록 VPC를 변경할 수 있습니다.

네 가지 옵션은 다음과 같습니다.

1. 단일 퍼블릭 서브넷만 있는 Amazon VPC
2. 퍼블릭 및 프라이빗 서브넷이 있는 Amazon VPC
3. 퍼블릭 및 프라이빗 서브넷이 있고 AWS Site-to-Site VPN 액세스를 제공하는 Amazon VPC
4. 퍼블릭 서브넷만 있고 AWS Site-to-Site VPN 액세스를 제공하는 Amazon VPC

VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 또는 방화벽 프록시를 사용하지 않고도 VPN을 AWS에서 호스팅하는 서비스와 비공개로 연결할 수 있습니다. 엔드포인트는 수평적으로 확장 가능하며 가용성이 매우 뛰어난 가상 디바이스로서, VPC 내 인스턴스와 AWS 서비스 간에 통신을 허용합니다. Amazon VPC는 게이트웨이 유형 엔드포인트와 인터페이스 유형 엔드포인트라는 두 가지 유형의 엔드포인트를 제공합니다.

게이트웨이 유형 엔드포인트는 S3 및 DynamoDB를 비롯한 AWS 서비스에서만 이용할 수 있습니다. 이러한 엔드포인트는 사용자가 선택한 라우팅 테이블에 항목을 추가하고, 트래픽을 Amazon의 프라이빗 네트워크를 통해 지원되는 서비스로 라우팅합니다.

인터페이스 유형 엔드포인트는 AWS 서비스인 PrivateLink에서 지원하는 서비스, 자체 서비스 또는 SaaS 솔루션에 비공개로 연결할 수 있으며, Direct Connect를 통한 연결을 지원합니다. 앞으로 이러한 엔드포인트에서 더 많은 AWS 및 SaaS 솔루션을 지원할 예정입니다. 인터페이스 유형 엔드포인트의 요금은 VPC 요금 페이지를 참조하십시오.

VPC 자체를 생성 및 사용하는 데에는 별도의 비용이 없습니다. Amazon EC2와 같은 다른 Amazon Web Services 사용 요금의 경우, 데이터 전송 요금을 비롯하여 해당 리소스에 대해 명시된 요금이 적용됩니다. 선택 사항인 하드웨어 VPN 연결을 사용하여 VPC를 회사의 데이터 센터에 연결하는 경우, VPN 연결 시간(VPN 연결이 "사용 가능" 상태인 시간)당 요금이 부과됩니다. 1시간 미만으로 사용해도 1시간 사용 요금이 청구됩니다. VPN 연결을 통해 전송된 데이터는 표준 AWS 데이터 전송 요금이 청구됩니다. VPC-VPN 요금에 대한 자세한 정보는 Amazon VPC 제품 페이지의 요금 섹션을 참조하세요.

Amazon EC2와 같은 다른 Amazon Web Services에 대한 사용 요금에 대해서는 해당 리소스에 대해 명시된 요금이 적용됩니다. VPC의 인터넷 게이트웨이를 통해 Amazon S3와 같은 Amazon Web Services에 액세스하는 동안에는 데이터 전송 요금이 발생하지 않습니다.

VPN 연결을 통해 AWS 리소스에 액세스하면 인터넷 데이터 전송 요금이 청구됩니다.

Amazon VPC를 다음 대상에 연결할 수 있습니다.

• 인터넷 (인터넷 게이트웨이를 통해)
• AWS Site-to-Site VPN 연결을 사용하여 회사 데이터 센터 (가상 프라이빗 게이트웨이를 통해)
• 인터넷과 사용자의 회사 데이터 센터 모두 (인터넷 게이트웨이와 가상 프라이빗 게이트웨이를 모두 사용)
• 다른 AWS 서비스 (인터넷 게이트웨이, NAT, 가상 프라이빗 게이트웨이 또는 VPC 엔드포인트를 통해)
• 다른 Amazon VPC (VPC 피어링 연결을 통해)

퍼블릭 IP 주소가 없는 인스턴스는 다음 두 가지 방법 중 하나를 사용하여 인터넷에 액세스할 수 있습니다.

1. 퍼블릭 IP 주소가 없는 인스턴스는 NAT 게이트웨이 또는 NAT 인스턴스를 통해 트래픽을 라우팅하여 인터넷에 액세스할 수 있습니다. 이러한 인스턴스는 인터넷을 통과하기 위해 NAT 게이트웨이 또는 NAT 인스턴스의 퍼블릭 IP 주소를 사용합니다. NAT 게이트웨이 또는 NAT 인스턴스는 아웃바운드 통신을 허용하지만, 인터넷상에서 시스템이 프라이빗 주소의 인스턴스에 연결을 시도하는 것을 허용하지 않습니다.
2. 하드웨어 VPN 연결 또는 Direct Connect 연결이 지원되는 VPC의 경우, 인스턴스는 가상 프라이빗 게이트웨이의 인터넷 트래픽을 사용자의 기존 데이터 센터로 라우팅할 수 있습니다. 여기서 라우터 및 네트워크 보안/모니터링 디바이스를 통해 인터넷에 액세스할 수 있습니다.

아니요. 퍼블릭 IP 주소를 사용할 경우 AWS에서 호스팅되는 인스턴스와 서비스 간의 모든 통신에는 AWS의 프라이빗 네트워크가 사용됩니다. AWS 네트워크에서 생성되고 그 대상도 AWS 네트워크에 있는 패킷은 AWS 글로벌 네트워크를 벗어나지 않습니다. 단, AWS 중국 리전으로 들어오거나 나가는 트래픽은 예외입니다.

또한 데이터 센터 및 리전을 상호 연결하는 AWS 글로벌 네트워크를 통해 이동하는 모든 데이터는 보안 시설을 떠나기 전에 물리적 계층에서 자동으로 암호화됩니다. 예를 들어 모든 VPC 교차 리전 피어링 트래픽, 고객 또는 서비스 간 Transport Layer Security (TLS) 연결 등 추가적인 암호화 계층도 존재합니다. 

RFC 1918 또는 공개적으로 라우팅이 가능한 IP 범위를 비롯하여 모든 IPv4 주소 범위를 기본 CIDR 블록에 사용할 수 있습니다. 보조 CIDR 블록에는 특정 제약 조건이 적용됩니다. 공개적으로 라우팅이 가능한 IP 블록은 가상 프라이빗 게이트웨이를 통해서만 연결할 수 있으며, 인터넷 게이트웨이를 통해서는 인터넷상에서 액세스할 수 없습니다. AWS는 고객 소유 IP 주소 블록을 인터넷에 노출하지 않습니다. 관련 API를 호출하거나 AWS Management Console을 통해 최대 5개의 AWS 제공 또는 BYOIP IPv6 GUA CIDR 블록을 VPC에 할당할 수 있습니다.

VPC를 생성할 때 단일 Classless Internet Domain Routing(CIDR) IP 주소 범위를 기본 CIDR 블록으로 할당하며, VPC를 생성한 후 최대 4개의 보조 CIDR 블록을 추가할 수 있습니다. VPC 내의 서브넷은 사용자가 이 CIDR 범위에서 주소를 지정합니다. 겹치는 IP 주소 범위로 여러 VPC를 생성할 수는 있으나, 그런 경우 해당 VPC를 하드웨어 VPN 연결을 통해 일반 홈 네트워크에 연결하지 못하게 됩니다. 그러므로 겹치지 않는 IP 주소 범위를 사용하는 것이 좋습니다. 최대 5개의 Amazon 제공 또는 BYOIP IPv6 CIDR 블록을 VPC에 할당할 수 있습니다.

현재 Amazon VPC에서는 IPv4에 대해 5개의 IP 주소 범위(기본 1개와 보조 4개)를 지원합니다. 각 범위의 크기는 /28(CIDR 표기법)과 /16 사이가 될 수 있습니다. VPC의 IP 주소 범위는 기존 네트워크의 IP 주소 범위와 겹치지 않아야 합니다.

IPv6의 경우 VPC는 고정 크기 /56입니다(CIDR 표기법). VPC에는 IPv4 및 IPv6 CIDR 블록 둘 다 연결될 수 있습니다.

현재 VPC당 서브넷 200개를 생성할 수 있습니다. 더 생성하려는 경우 지원 센터에 사례를 제출하세요.

IPv4의 경우 서브넷의 최소 크기는 /28(또는 IP 주소 14개)입니다. 서브넷은 생성된 VPC보다 더 클 수 없습니다.

IPv6의 경우 서브넷 크기는 /64로 고정됩니다. 서브넷에는 IPv6 CIDR 블록 단 한 개만 할당할 수 있습니다.

다음에 해당하는 경우 어떤 IP 주소든 인스턴스에 할당할 수 있습니다.

• 연결된 서브넷의 IP 주소 범위에 포함될 때
• IP 네트워킹을 위해 Amazon이 예약한 것이 아닐 때
• 현재 다른 인터페이스에 할당되어 있지 않을 때

예. Amazon VPC에서는 탄력적 네트워크 인터페이스 또는 EC2 인스턴스에 하나 이상의 보조 프라이빗 IP 주소를 할당할 수 있습니다. 할당할 수 있는 보조 프라이빗 IP 주소의 수는 인스턴스 유형에 따라 다릅니다. 인스턴스 유형당 할당할 수 있는 보조 프라이빗 IP 주소 수에 대한 자세한 내용은 EC2 사용 설명서를 참조하세요.

다음과 같은 이유로 자체 보유한 IP 주소를 AWS에 가져올 수 있습니다.
IP 신뢰도: 많은 고객들은 자체 IP 주소의 신뢰도를 전략적 자산으로 간주하고 AWS에서 해당 IP를 리소스와 함께 사용하려고 합니다. 예를 들어 아웃바운드 이메일 MTA와 같은 서비스를 유지하고 높은 IP 신뢰도를 보유한 고객은 이제 IP 공간을 가져와서 기존의 성공적인 전송 성공률을 유지할 수 있습니다.

고객 화이트리스트: BYOIP를 사용하는 고객은 IP 주소 화이트리스트에 의존하는 워크로드를 새 IP 주소를 포함하는 화이트리스트의 재설정 없이 그대로 AWS로 옮길 수 있습니다.

하드 코딩된 종속성: 여러 고객이 IP를 디바이스에 하드 코딩하거나 IP에 대한 아키텍처 종속성을 가집니다. BYOIP를 사용하면 이러한 고객이 AWS로 자유롭게 마이그레이션할 수 있습니다.

규정 및 준수: 많은 고객은 규정 및 준수 이유로 인해 특정 IP를 사용해야 합니다. 이러한 IP도 BYOIP를 통해 자유롭게 사용할 수 있습니다.

온프레미스 IPv6 네트워크 정책: 많은 고객은 자체 온프레미스 네트워크에서 자신의 IPv6만 라우팅할 수 있습니다. 이런 고객은 VPC에 자체 IPv6 범위를 할당함에 따라 BYOIP를 통해 자유롭게 사용하고 인터넷 또는 직접 연결을 사용해 온프레미스 네트워크에 라우팅하도록 선택할 수 있습니다.

BYOIP 가용성에 대한 자세한 내용은 설명서를 참조하세요.

AWS IPAM은 다음 기능을 제공합니다.
 

• 대규모 네트워크에 대한 IP 주소 할당: IPAM은 구성 가능한 비즈니스 규칙을 기반으로 수백 개의 계정 및 VPC에 걸쳐 IP 주소 할당을 자동화할 수 있습니다.
   
• 네트워크의 IP 사용량 모니터링: IPAM은 IP 주소를 모니터링할 수 있으며, IPAM에서 네트워크 확장이 지연될 수 있는 IP 주소 소진이나 잘못된 라우팅이 발생할 수 있는 IP 주소 중복과 같은 잠재적 문제를 감지할 때 알림을 받을 수 있도록 설정할 수 있습니다.
   
• 네트워크 문제 해결: IPAM은 잘못된 IP 주소 구성 또는 기타 문제로 인해 연결 문제가 발생한 경우 신속하게 식별하는 데 도움이 될 수 있습니다.
   
• IP 주소 감사: IPAM은 자동으로 IP 주소 모니터링 데이터를 유지합니다(최대 3년). 이 기록 데이터를 사용하여 네트워크에 대한 소급 분석 및 감사를 수행할 수 있습니다.

다음은 IPAM의 핵심 구성 요소입니다.

• 영역이란 IPAM 내에서 가장 높은 수준의 컨테이너입니다. IPAM에는 두 가지 기본 영역이 포함되어 있습니다. 각 영역은 단일 네트워크의 IP 공간을 나타냅니다. 프라이빗 영역은 모든 프라이빗 공간을 위한 것입니다. 퍼블릭 영역은 모든 퍼블릭 공간을 위한 것입니다. 영역을 사용하면 IP 주소가 중복되거나 충돌하지 않으면서 연결되지 않은 여러 네트워크의 IP 주소를 재사용할 수 있습니다. 영역 내에서 IPAM 풀을 생성합니다.
   
• 풀이란 인접한 IP 주소 범위(또는 CIDR) 모음입니다. IPAM 풀을 사용하면 라우팅 및 보안 요구 사항에 따라 IP 주소를 구성할 수 있습니다. 최상위 풀 내에 여러 풀을 보유할 수 있습니다. 예를 들어 개발 및 프로덕션 애플리케이션에 대해 별도의 라우팅 및 보안 요구 사항이 있는 경우 각각의 풀을 생성할 수 있습니다. IPAM 풀 내에서 CIDR을 AWS 리소스에 할당할 수 있습니다.
• 할당이란 IPAM 풀에서 다른 리소스 또는 IPAM 풀로 CIDR을 배정하는 것입니다. VPC를 생성하고 VPC의 CIDR에 대한 IPAM 풀을 선택하면 CIDR은 프로비저닝된 CIDR에서 IPAM 풀로 할당됩니다. IPAM을 통해 할당을 모니터링하고 관리할 수 있습니다.

예. IPAM에서는 BYOIPv4 및 BYOIPv6 주소를 지원합니다. BYOIP는 사용자가 소유한 IP 주소를 AWS로 가져올 수 있는 EC2 기능입니다. IPAM을 사용하면 직접 프로비저닝하고 계정 및 조직 전반에 걸쳐 IP 주소 블록을 공유할 수 있습니다. IPv4를 사용하는 기존 BYOIP 고객은 풀을 IPAM로 마이그레이션하여 IP 관리를 간소화할 수 있습니다.

Amazon EC2 보안 그룹을 사용하여 Amazon VPC 내의 인스턴스 보안을 유지할 수 있습니다. VPC 내의 보안 그룹을 통해 각각의 Amazon EC2 인스턴스와의 인바운드 및 아웃바운드 네트워크 트래픽을 지정할 수 있습니다. 인스턴스에서 송신 또는 수신되도록 명시적으로 허용되지 않은 트래픽은 자동으로 거부됩니다.

보안 그룹에 더하여, 각 서브넷에 출입하는 네트워크 트래픽은 네트워크 ACL(액세스 제어 목록)를 통해 허용하거나 거부할 수 있습니다.

상태 저장 필터링은 요청의 오리진을 추적하며, 오리진 컴퓨터로 반환하라는 요청에 대한 회신을 자동으로 허용합니다. 예를 들어, 웹 서버에서 TCP 포트 80으로 인바운드 트래픽을 허용하는 상태 저장 필터는 보통 큰 수의 포트(예: 목적지 TCP 포트 63, 912)에서 반환 트래픽이 클라이언트와 웹 서버 간의 상태 저장 필터를 통과하도록 허용합니다. 이 필터링 디바이스는 소스 포트와 목적지 포트 수 및 IP 주소를 추적하는 상태 테이블을 관리합니다. 필터링 디바이스에 적용되는 유일한 규칙은 웹 서버에서 TCP 포트 80에 대한 인바운드 트래픽을 허용한다는 것입니다.

상태 비저장 필터링은 소스 또는 목적지 IP 주소와 목적지 포트만 검사하고, 트래픽이 새로운 요청인지 또는 요청에 대한 응답인지 여부는 무시합니다. 위의 예에서, 두 가지 규칙을 필터링 디바이스에 적용해야 합니다. 하나는 TCP 포트 80에서 웹 서버에 대한 인바운드 트래픽을 허용하는 것이며, 다른 하나는 웹 서버로부터 아웃바운드 트래픽을 허용하는 것입니다(TCP 포트 범위는 49, 65~152, 535).

VPC 흐름 로그는 VPC의 네트워크 인터페이스에서 송수신되는 IP 트래픽에 대한 정보를 캡처할 수 있는 기능입니다. 흐름 로그 데이터는 Amazon CloudWatch Logs 또는 Amazon S3에 게시할 수 있습니다. VPC 흐름 로그를 모니터링하여 네트워크 의존성 및 트래픽 패턴에 대한 운영 가시성을 얻고, 이상을 추적하며 데이터 유출을 예방하거나, 또는 네트워크 연결성 및 구성 문제를 해결할 수 있습니다. 흐름 로그의 강화된 메타데이터는 누가 TCP 연결을 시작했는지, NAT 게이트웨이 등의 중간 계층을 통과하는 트래픽의 실제 패킷 수준 출처 및 대상에 대한 추가적인 인사이트를 얻도록 지원합니다. 흐름 로그를 아카이빙하여 일반적인 규정 준수 요건을 충족할 수 있습니다. Amazon VPC 흐름 로그에 대한 자세한 내용은 설명서를 참조하세요.

예. Transit Gateway 또는 개별 Transit Gateway Attachment에 대한 VPC 흐름 로그를 생성할 수 있습니다. 이 기능을 사용하면 Transit Gateway에서 Transit Gateway를 통과하는 네트워크 흐름에 대한 소스/대상 IP, 포트, 프로토콜, 트래픽 카운터, 타임스탬프 및 다양한 메타데이터와 같은 자세한 정보를 내보낼 수 있습니다. Transit Gateway에 대한 Amazon VPC 흐름 로그 지원에 대해 자세히 알아보려면 설명서를 참조하세요.

CloudWatch Logs 또는 Amazon S3에 흐름 로그를 게시할 때 Vended 로그에 대한 데이터 수집 및 아카이빙 요금이 적용됩니다. 자세한 내용과 예는 Amazon CloudWatch 요금을 참조하세요. 또한 비용 할당 태그를 사용하여 흐름 로그를 게시하는 데 따른 요금을 추적할 수도 있습니다.

트래픽 미러링은 EC2 인스턴스용 탄력적 네트워크 인터페이스(ENI)에서 네트워크 패킷 캡처를 지원합니다. Amazon VPC Traffic Mirroring을 지원하는 EC2 인스턴스는 트래픽 미러링 설명서를 참조하세요.

고객은 Amazon VPC 흐름 로그를 사용하여 네트워크 흐름 로그를 수집, 저장 및 분석할 수 있습니다. 흐름 로그에 캡처되는 정보에는 허용 및 거부되는 트래픽, 원본 및 대상 IP 주소, 포트, 프로토콜 번호, 패킷 및 바이트 수, 작업(수락 또는 거절)에 대한 정보가 포함됩니다. 이 기능을 사용하면 연결 및 보안 문제를 해결할 수 있는 것은 물론, 네트워크 액세스 규칙이 예상대로 작동하도록 할 수 있습니다.

Amazon VPC 트래픽 미러링을 사용하면 페이로드 같은 실제 트래픽 콘텐츠를 분석하여 네트워크 트래픽을 좀 더 깊이 있게 파악할 수 있습니다. 이 기능은 실제 패킷을 분석하여 성능 문제의 근본 원인을 파악하거나, 정교한 네트워크 공격을 리버스 엔지니어링하거나, 내부자 침해 또는 손상된 워크로드를 감지 및 차단해야 하는 사용 사례를 위한 것입니다.

Amazon VPC는 현재 모든 Amazon EC2 리전 내 여러 가용 영역에서 사용할 수 있습니다.

IPv4 주소 지정이 필요한 인스턴스의 경우 VPC 내에서 실행할 수 있는 Amazon EC2 인스턴스 수에 제한이 없습니다. 단, VPC가 각 인스턴스에 할당된 IPv4 주소를 가지도록 적절한 크기로 설정되어야 합니다. 처음에는 한 번에 최대 20개의 Amazon EC2 인스턴스를 시작할 수 있도록 제한되며, VPC의 최대 크기는 /16(65,536 IP)입니다. 이러한 한도를 늘리려면 다음 양식을 작성해 주세요. IPv6 전용 인스턴스의 경우 /56의 VPC 크기는 Amazon EC2 인스턴스를 거의 무제한으로 시작할 수 있는 기능을 제공합니다.

VPC와 같은 리전 내에 등록된 Amazon VPC의 AMI를 사용할 수 있습니다. 예를 들어, us-east-1에 등록된 AMI를 us-east-1에 있는 VPC와 함께 사용할 수 있습니다. 자세한 내용은 Amazon EC2 리전 및 가용 영역 FAQ에서 확인할 수 있습니다.

예. VPC와 같은 리전에 위치해 있다면 Amazon EBS 스냅샷을 사용할 수 있습니다. 세부 정보는 Amazon EC2 리전 및 가용 영역 FAQ에서 확인할 수 있습니다.

AWS 계정이 2013년 3월 18일 이후에 생성된 경우, 기본 VPC에서 리소스를 시작할 수 있습니다. 어떤 리전에서 기본 VPC 기능 세트를 사용할 수 있는지 확인하려면 이 포럼 공지 사항을 참조하세요. 또한, 기재된 날짜 이전에 생성된 계정은 EC2 인스턴스를 시작한 적이 없거나 Amazon Elastic Load Balancing, Amazon RDS, Amazon ElastiCache 또는 Amazon Redshift 리소스를 프로비저닝한 적이 없는 리전 중 기본 VPC가 활성된 리전에서 기본 VPC를 사용할 수 있습니다.

EC2 사용 설명서에서 EC2-Classic과 EC2-VPC 차이점 섹션을 참조하세요.

예. 하지만 그 리전의 해당 계정에 EC2-Classic 리소스가 없는 경우에 한하여 기존 계정에 기본 VPC를 활성화할 수 있습니다. 또한, VPC에 의해 프로비저닝되지 않은 해당 리전의 모든 Elastic Load Balancer, Amazon RDS, Amazon ElastiCache, Amazon Redshift 리소스를 종료해야 합니다. 사용자의 계정에 기본 VPC가 구성된 후에는, Auto Scaling을 통해 시작된 인스턴스를 비롯하여 이후의 모든 리소스 작업은 기본 VPC에서 시작됩니다. 기존 계정을 기본 VPC로 구성하도록 요청하려면 Account and Billing -> Service: Account -> Category: Convert EC2 Classic to VPC로 이동하여 요청을 작성하십시오. 고객의 요청, 기존 AWS 서비스 및 EC2-Classic의 존재 여부를 검토한 후 다음 단계를 안내해 드리겠습니다.

AWS 리전 중 하나의 계정에서 EC2-Classic을 사용하도록 설정한 경우에만 이 변경의 영향을 받습니다. 콘솔 또는 describe-account-attributes 명령을 사용하여 AWS 리전에 대해 EC2-Classic을 사용하도록 설정했는지 여부를 확인할 수 있습니다. 자세한 내용은 이 문서를 참조하세요.

리전에서 EC2-Classic에 실행 중인 활성 AWS 리소스가 없는 경우 해당 리전에 대해 계정에서 EC2-Classic을 끄십시오. 리전에서 EC2-Classic을 끄면 해당 리전에서 기본 VPC를 시작할 수 있습니다. 이렇게 하려면 AWS Support Center(console.aws.amazon.com/support)로 이동하고 ‘사례 생성’을 선택한 다음 ‘유형’에서 ‘계정 및 결제 지원’, ‘범주’에서 ‘계정’을 선택한 다음 ‘EC2 Classic에서 VPC로 변환’을 선택하고 필요한 기타 세부 정보를 입력하고 ‘제출’을 선택합니다.

2021년 1월 1일 이후 EC2-Classic에 AWS 리소스(EC2 인스턴스, Amazon Relational Database, AWS Elastic Beanstalk, Amazon Redshift, AWS Data Pipeline, Amazon EMR, AWS OpsWorks)가 없는 모든 AWS 리전에 대해 2021년 10월 30일에 사용자의 계정에서 EC2-Classic을 자동으로 끕니다.

반면 EC2-Classic에서 실행 중인 AWS 리소스가 있는 경우에는 가능한 신속하게 Amazon VPC로의 마이그레이션을 계획해야 합니다. 2022년 8월 15일 이후에는 EC2-Classic 플랫폼에서 인스턴스 또는 AWS 서비스를 시작할 수 없습니다. 실행 중 상태의 모든 워크로드 또는 서비스는 2022년 8월 16일부터 EC2-Classic이 사용 중지되므로 EC2-Classic의 모든 AWS 서비스에 대한 액세스가 점차 손실됩니다.

후속 질문에서 AWS 리소스의 마이그레이션 가이드를 확인할 수 있습니다.

Amazon VPC는 AWS 계정과 논리적으로 격리되어 있어 AWS의 가상 네트워크 환경에 대한 완벽한 제어가 가능합니다. EC2-Classic 환경에서는 워크로드에서 다른 고객과 단일 플랫 네트워크를 공유합니다. Amazon VPC 환경에서는 EC2-Classic 환경과 비교해 자체 IP 주소 공간을 선택할 수 있는 기능, 퍼블릭 및 프라이빗 서브넷 구성, 라우팅 테이블 및 네트워크 게이트웨이 관리 등과 같은 여러 다른 이점을 제공합니다. 현재 EC2-Classic에서 사용할 수 있는 모든 서비스 및 인스턴스에 해당하는 서비스를 Amazon VPC 환경에서 사용할 수 있습니다. 또한 Amazon VPC에서는 EC2-Classic보다 다양한 최신의 인스턴스를 제공합니다. Amazon VPC에 대한 자세한 내용은 이 링크를 참조하세요.

리소스 마이그레이션에 도움을 주기 위해 아래에서 찾을 수 있는 플레이북과 빌드 솔루션을 게시했습니다. 마이그레이션하려면 VPC에서 EC2-Classic 리소스를 다시 생성해야 합니다. 먼저 이 스크립트를 사용하여 계정의 모든 리전에서 EC2-Classic에 프로비저닝된 모든 리소스를 식별할 수 있습니다. 그런 다음 아래에서 관련 AWS 리소스의 마이그레이션 가이드를 사용할 수 있습니다.

• Instances and Security Groups
• Classic Load Balancer
• Amazon Relational Database Service
• AWS Elastic Beanstalk
• Amazon Redshift(DC1 클러스터 마이그레이션용 및 기타 노드 유형 마이그레이션용)
• AWS Data Pipeline 
• Amazon EMR 
• AWS OpsWorks

위의 마이그레이션 가이드와 더불어 애플리케이션 마이그레이션을 간소화, 가속화 및 비용을 절감하는 리프트 앤 시프트(리호스팅) 솔루션인 AWS Application Migration Service(AWS MGN)도 제공합니다. AWS MGN에 대한 관련 리소스는 다음을 참조하십시오.

• AWS Application Migration Service 시작하기 
• AWS Application Migration Service 온디맨드 기술 교육
• AWS Application Migration Service 특징 및 기능을 자세히 살펴보기 위한 설명서
• 서비스 아키텍처 및 네트워크 아키텍처 동영상

EC2-Classic에서 VPC로의 단순한 개별 EC2 인스턴스 마이그레이션의 경우 AWS MGN 또는 인스턴스 마이그레이션 가이드 외에 ”AWS Systems Manager > 자동화“에서 “AWSSupport-MigrateEC2 ClassicToVPC“ 런북도 사용할 수 있습니다. 이 런북은 EC2-Classic에서 인스턴스의 AMI를 생성하고, VPC에서 AMI의 새 인스턴스를 생성하고, 선택적으로 EC2-Classic 인스턴스를 종료하여 EC2-Classic에서 VPC로 인스턴스를 마이그레이션하기 위해 필요한 단계를 자동화합니다.

질문이 있는 경우 AWS Premium Support를 통해 AWS Support 팀에 문의할 수 있습니다.

참고: 여러 AWS 리전에서 EC2-Classic에 실행 중인 AWS 리소스가 있는 경우에는 해당 리전에서 모든 리소스를 VPC로 마이그레이션한 직후 각 리전에서 EC2-Classic을 끄는 것이 좋습니다.

AWS에서는 2022년 8월 15일 사용 중지 날짜 전에 다음 두 가지 작업을 수행합니다.

• 2021년 10월 30일에 EC2-Classic 환경에 대한 3년 예약 인스턴스(RI) 및 1년 RI 실행을 중지합니다. 이미 EC2-Classic 환경에 있는 RI는 이때 영향을 받지 않습니다. 2022년 8월 15일 후 만료되도록 설정된 RI는 나머지 임대 기간 동안 Amazon VPC 환경을 사용하도록 수정해야 합니다. RI를 수정하는 방법에 대한 자세한 내용은 AWS 문서를 참조하세요.
• 2022년 8월 15일부터 EC2-Classic 환경에서 새 인스턴스(Spot 또는 온디맨드) 생성이 더 이상 허용되지 않습니다. 실행 중 상태의 모든 워크로드 또는 서비스는 2022년 8월 16일부터 EC2-Classic이 사용 중지되므로 EC2-Classic의 모든 AWS 서비스에 대한 액세스가 점차 손실됩니다.

네트워크 인터페이스는 동일한 계정의 VPC에 상주하는 인스턴스에만 연결할 수 있습니다.

VPC 피어링 연결 생성에 대한 비용은 없지만, 피어링 연결을 통한 데이터 전송 비용이 청구됩니다. 데이터 전송 요금은 EC2 요금 페이지의 데이터 전송 섹션을 참조하세요.

AWS는 VPC의 기존 인프라를 사용하여 VPC 피어링 연결을 생성합니다. 이는 게이트웨이도, VPN 연결도 아니며 개별적인 물리적 하드웨어에 의존하지 않습니다. 그러므로 통신 또는 대역폭 병목에 대한 단일 지점 장애가 없습니다.

리전 간 VPC 피어링은 현재 VPC를 지원하는 것과 동일한 수평적으로 확장되고 중복적이며 가용성이 높은 기술에서 운영됩니다. 리전 간 VPC 피어링 트래픽은 내장된 중복성 및 동적 대역폭 할당 기능을 지원하는 AWS 백본으로 이동합니다. 통신에 대한 단일 실패 지점이 없습니다.

리전 간 피어링 연결이 끊어지는 경우 트래픽이 인터넷을 통해 라우팅되지 않습니다.

피어링되는 VPC 내 인스턴스 간 대역폭은 동일한 VPC 내 인스턴스 간 대역폭과 같습니다. 참고: 배치 그룹은 피어링된 여러 VPC를 포괄할 수 있지만, 피어링된 VPC의 인스턴스 간에는 양방향 대역폭이 지원되지 않습니다. 배치 그룹에 대한 자세한 내용을 읽어보세요.

ClassicLink를 사용할 경우 추가 요금이 부과되지 않으며, 기존 가용 영역 간 데이터 전송 요금이 적용됩니다. 자세한 내용은 EC2 요금 페이지를 참조하세요.

서비스 사용자는 PrivateLink로 구동되는 서비스를 위해 인터페이스 유형 VPC 엔드포인트를 생성해야 합니다. 이러한 서비스 엔드포인트는 VPC 내 프라이빗 IP가 연결된 ENI(Elastic Network Interface)로 표시됩니다. 이러한 엔드포인트가 생성되면, 이 IP로 향하는 모든 트래픽이 비공개로 해당 AWS 서비스로 라우팅됩니다.

서비스 사용자는 서비스 앞단에 Network Load Balancer(NLB)를 설정하여 AWS PrivateLink에 서비스를 탑재할 수 있으며 NLB PrivateLink 서비스를 생성하여 NLB에 등록할 수 있습니다. 고객은 자신의 계정 및 IAM 역할을 허용한 후에 VPC 내에 엔드포인트를 설정하여 서비스에 연결할 수 있습니다.

Amazon Elastic Compute Cloud(EC2), Elastic Load Balancing(ELB), Kinesis Streams, Service Catalog, EC2 Systems Manager, Amazon SNS 및 AWS DataSync와 같은 AWS 서비스가 이 기능을 지원합니다. 많은 SaaS 솔루션도 이 기능을 지원합니다. AWS Marketplace에서 AWS PrivateLink가 지원되는 SaaS 제품에 대해 더 자세히 알아볼 수 있습니다.

VPC 한도에 대한 내용은 Amazon VPC 사용 설명서를 참조하세요.

예. AWS Support에 대한 자세한 정보는 여기를 클릭하세요.

ElasticFox는 공식적으로 더 이상 Amazon VPC를 관리하는 데 지원되지 않습니다. Amazon VPC 지원은 AWS API, 명령줄 도구, AWS Management Console 및 그 외 다양한 타사 유틸리티를 통해 사용할 수 있습니다.

리전 내 VPC 내부 및 VPC 간 트래픽 흐름에 대해 중앙집중식으로 암호화를 모니터링하고 강제할 수 있도록 해주는 보안 및 규정 준수 기능입니다. 자세한 내용은 여기에서 설명서를 참조하세요.

모니터 모드(가시성 확보, 평가 및 마이그레이션 시작용)와 강제 적용 모드(암호화되지 않은 트래픽 방지용)입니다.

특히 HIPAA, FedRamp, PCI DSS와 같은 표준 준수가 필요한 산업 분야의 보안 관리자와 클라우드 아키텍트를 위해 설계되었습니다.

VPC 암호화 제어는 애플리케이션 계층 암호화와 AWS Nitro System 하드웨어의 내장 암호화 기능을 모두 사용하여 암호화 적용을 보장합니다.

모니터 모드는 트래픽 흐름의 암호화 상태를 가시화하고, 규정을 준수하지 않는 리소스를 식별하며, VPC 흐름 로그에 암호화 상태 정보를 기록할 수 있게 합니다. 모니터 모드를 활성화하면 Network Load Balancer, Application Load Balancer, Fargate 클러스터, EKS 컨트롤 플레인과 같은 리소스는 암호화를 기본적으로 지원하는 하드웨어로 자동 및 점진적으로 마이그레이션됩니다.

다음 방법을 통해 가능합니다.

• 암호화 상태 필드가 포함된 VPC 흐름 로그
• 콘솔 대시보드
• GetVpcResourcesBlockingEncryptionEnforcement 명령

아니요, 암호화 상태 필드를 수동으로 추가하여 새로운 흐름 로그를 생성해야 합니다. 또한 트래픽 경로와 흐름 방향 필드를 추가하는 것이 좋습니다.

VPC가 강제 적용 모드로 전환되면, VPC 경계 내에서 암호화되지 않은 트래픽을 허용하는 리소스의 생성 또는 연결이 차단됩니다. 기본적으로 Nitro 암호화를 지원하지 않는 인스턴스는 실행할 수 없게 됩니다.

아니요, 먼저 다음 단계를 수행해야 합니다.

• 모니터 모드 활성화
• 규정을 준수하지 않는 리소스 식별
• 규정을 준수하지 않는 리소스에 대한 제외 항목 수정 또는 생성
• 그런 다음 강제 적용 모드로 전환

지원되는 8가지 예외 유형 중 하나를 사용하여 해당 리소스에 대한 예외를 생성해야 합니다. 지원되지 않는 리소스는 강제 모드를 활성화하기 전에 VPC 밖으로 마이그레이션하거나 삭제해야 합니다. 암호화 제어에서 지원되는 리소스의 경우, 강제 적용 모드를 켜기 전에 암호화 준수 인스턴스로 마이그레이션해야 합니다..

다음 단계를 따릅니다.

• 흐름 로그와 리소스 준수 상태 검토
• 필요한 리소스 마이그레이션 계획 수립
• 강제 적용 모드로 전환할 때 필요한 제외 항목 구성

네, 가능합니다. 다만, 두 VPC 간에 제외 항목 없이 VPC 피어링이 설정되어 있는 경우는 예외입니다. 이 경우, 두 VPC 간의 VPC 피어링을 먼저 삭제한 뒤 모니터 모드로 전환해야 합니다.

GetVPCResourcesBlockingEncrytionEnception 명령을 사용하여 집행을 차단할 리소스를 식별할 수 있습니다. 또는 콘솔을 사용하여 암호화되지 않은 리소스를 찾을 수 있습니다.

지원되는 제외 항목은 총 8가지입니다.

• 인터넷 게이트웨이
• NAT 게이트웨이
• 송신 전용 인터넷 게이트웨이
• 암호화 비적용 VPC로의 VPC 피어링 연결
• 가상 프라이빗 게이트웨이
• Lambda 함수
• VPC Lattice
• Elastic File System

0: 암호화되지 않음
1: Nitro 암호화됨
2: 애플리케이션 암호화됨
3: Nitro와 애플리케이션 모두 암호화됨
(-): 알 수 없음/VPC 암호화 제어 꺼짐

암호화 제어가 활성화된 VPC 간 트래픽을 암호화하려면 VPC 피어링 또는 Transit Gateway를 사용할 수 있습니다. Transit Gateway를 사용할 경우, 콘솔 또는 modify-transit-gateway 명령을 통해 암호화 지원을 명시적으로 활성화해야 합니다. Transit Gateway에서 암호화를 켜는 것 자체에는 별도 요금이 없지만, 해당 Transit Gateway와 연결된 모든 VPC에는 표준 VPC 암호화 제어 요금이 부과됩니다(해당 VPC에서 암호화 제어를 켰는지 여부와 관계없이).

‘modify-transit-gateway’ 명령을 사용하거나 AWS 콘솔을 통해 활성화할 수 있습니다. 암호화 제어가 활성화된 VPC 간 트래픽을 암호화하려면 Transit Gateway에서 암호화 지원을 명시적으로 켜야 합니다.

기존 TGW에서 암호화를 활성화해도 기존 트래픽 흐름에는 지장이 없으며, VPC 연결이 암호화된 경로로 마이그레이션되는 과정은 원활하고 자동으로 진행됩니다. Transit Gateway에서 암호화 지원을 활성화하면 VPC 간 트래픽을 암호화할 수 있습니다. 강제 적용 모드(제외 항목 없음)인 두 VPC 간 트래픽은 TGW를 통해 엔드 투 엔드 암호화됩니다. 또한 Transit Gateway에서의 암호화를 사용하면 서로 다른 암호화 제어 모드를 가진 두 VPC를 연결할 수도 있습니다.

경우에 따라 다릅니다. 강제 적용 모드(제외 항목 없음)인 두 VPC 간 트래픽은 TGW를 통해 엔드 투 엔드 암호화됩니다. 또한 Transit Gateway에서의 암호화를 사용하면 서로 다른 암호화 제어 모드를 가진 두 VPC를 연결할 수도 있습니다. 즉, 암호화가 적용되지 않은 VPC와 연결된 VPC에서 암호화 제어를 강제 적용하고 싶은 경우에 이 기능을 사용해야 합니다. 이러한 시나리오에서는 암호화 적용된 VPC 내부의 모든 트래픽(VPC 간 트래픽 포함)이 암호화됩니다. 암호화가 적용된 VPC의 리소스와 Transit Gateway 사이 구간에서는 VPC 간 트래픽이 암호화됩니다. 그 이후 구간, 즉 암호화가 적용되지 않은 VPC 내 트래픽의 목적지 리소스까지의 암호화 여부는 해당 리소스에 따라 달라지며, 해당 VPC가 강제 적용 모드가 아니므로 암호화가 보장되지 않습니다. 또한 모든 VPC는 동일한 리전에 있어야 합니다.

예, 트래픽은 암호화되지 않은 VPC의 TGW 연결 지점에 도달할 때까지 계속 암호화됩니다. 트래픽은 목적지 VPC의 암호화 상태와 관계없이 소스에서 대상 VPC의 TGW 연결 지점까지 암호화 상태를 유지합니다.

기존 연결을 유지한 상태에서 TGW에서 암호화를 활성화하면 전환이 자동으로 처리됩니다. TGW에서 암호화를 켜도 기존 트래픽 흐름에는 지장이 없습니다.

예, TGW는 전환 과정에서 암호화된 트래픽과 암호화되지 않은 트래픽을 모두 처리하여 점진적 마이그레이션을 지원합니다.

아니요. VPC 암호화 제어가 적용된 Private Link는 AWS 서비스에만 지원됩니다. 비-AWS 서비스용 VPC 엔드포인트는 암호화를 적용하려는 VPC에서 유지될 수 없습니다. VPC를 강제 적용 모드로 전환하기 전에 해당 엔드포인트를 삭제해야 합니다. 강제 적용 모드에서 실행 중인 VPC는 VPC 피어링 또는 Transit Gateway를 통해 연결하여 엔드 투 엔드 암호화를 보장할 수 있습니다.