Amazon VPC FAQ

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 피어링 연결을 통해)

Amazon VPC는 인터넷 게이트웨이 생성을 지원합니다. 이 게이트웨이를 사용하면 VPC 내 Amazon EC2 인스턴스가 인터넷에 직접 액세스할 수 있습니다. VPC에서 인터넷으로 IPv6 트래픽에 대하여 송신 전용 액세스를 제공하는 상태 유지 게이트웨이인 송신 전용 인터넷 게이트웨이를 사용할 수도 있습니다.

아니요. 인터넷 게이트웨이는 수평적으로 확장되고, 중복적이며, 가용성이 뛰어납니다. 인터넷 게이트웨이에 대한 대역폭 제한은 없습니다.

탄력적 IP 주소(EIP)와 IPv6 글로벌 고유 주소(GUA)를 비롯한 퍼블릭 IP 주소를 사용하면 VPC 내의 인스턴스가 인터넷으로 직접 아웃바운드 통신을 수행하고 인터넷으로부터(예: 웹 서버) 임의의 인바운드 트래픽을 수신할 수 있습니다. 다음 질문에 있는 솔루션을 사용할 수도 있습니다.

인터넷을 통해 액세스할 수 있는 VPC에서 호스팅되는 서비스 또는 인스턴스에 할당된 모든 IP 주소는 퍼블릭 IP 주소로 간주됩니다. 탄력적 IP 주소(EIP) 및 IPv6 GUA를 포함한 퍼블릭 IPv4 주소만 인터넷에서 라우팅할 수 있습니다. 이렇게 하려면 먼저 VPC를 인터넷에 연결한 다음 인터넷에서 연결할 수 있도록 라우팅 테이블을 업데이트해야 합니다.

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

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

예. 타사 소프트웨어 VPN을 사용하여 인터넷 게이트웨이를 통한 VPC와 사이트 간 또는 원격 액세스 VPN 연결을 생성할 수 있습니다.

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

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

AWS Site-to-Site VPN 연결은 사용자의 VPC를 데이터센터에 연결합니다. Amazon은 인터넷 프로토콜 보안 (IPsec) VPN 연결을 지원합니다. VPC와 데이터센터 간에 전송되는 데이터는 암호화된 VPN 연결을 통해 라우팅되어 전송 데이터의 기밀성과 무결성이 유지됩니다. AWS Site-to-Site VPN 연결을 형성하는데 인터넷 게이트웨이는 필요하지 않습니다.

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

기본 VPC에는 CIDR 범위 172.31.0.0/16이 할당됩니다. 기본 VPC 내 기본 서브넷에는 VPC CIDR 범위 내 /20 네트블록이 할당됩니다. 

예. 퍼블릭 IPv4 주소와 IPv6 GUA 주소를 AWS VPC로 가져와서 이를 서브넷과 EC2 인스턴스에 정적으로 할당할 수 있습니다. 인터넷을 통해 이러한 주소에 액세스하려면 온프레미스 네트워크에서 인터넷에 이를 알려야 합니다. 또한, AWS DX 또는 AWS VPN 연결을 사용하여 VPC와 온프레미스 네트워크 간에 이러한 주소를 통해 트래픽을 라우팅해야 합니다. 가상 프라이빗 게이트웨이를 사용하여 VPC에서 트래픽을 라우팅할 수 있습니다. 마찬가지로 라우터를 사용하여 온프레미스 네트워크에서 VPC로 다시 트래픽을 라우팅할 수 있습니다.

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

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

예. VPC에 4개의 보조 IPv4 IP 범위(CIDR)를 추가하면 기존 VPC를 확장할 수 있습니다. VPC에 추가한 보존 CIDR 블록을 삭제하면 VPC의 크기를 줄일 수 있습니다.   마찬가지로 최대 5개의 추가 IPv6 IP 범위(CIDR)를 VPC에 추가할 수 있습니다.  이 추가 범위를 삭제하여 VPC를 축소할 수 있습니다.

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

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

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

아니요. Amazon은 IP 네트워킹 목적으로 모든 서브넷의 처음 4개 IP 주소와 마지막 1개 IP 주소를 예약합니다.

IPv6 전용이 아닌 서브넷 내에서 Amazon EC2 인스턴스를 시작할 때 선택적으로 인스턴스에 대한 기본 프라이빗 IPv4 주소를 지정할 수 있습니다. 기본 프라이빗 IPv4 주소를 지정하지 않으면 AWS는 사용자가 해당 서브넷에 할당한 IPv4 주소 범위에서 자동으로 주소를 지정합니다. 보조 프라이빗 IPv4 주소는 인스턴스를 시작할 때, 탄력적 네트워크 인터페이스를 생성할 때 또는 인스턴스가 시작되거나 인터페이스가 생성된 후 언제든지 할당할 수 있습니다. IPv6 전용 서브넷 내에서 Amazon EC2 인스턴스를 시작하는 경우 AWS는 해당 서브넷의 Amazon 제공 IPv6 GUA CIDR에서 자동으로 주소를 지정합니다. 인스턴스의 IPv6 GUA는 올바른 보안 그룹, NACL 및 라우팅 테이블 구성을 사용하여 인터넷에서 연결할 수 있도록 설정하지 않는 한 프라이빗으로 유지됩니다.

IPv4 또는 이중 스택 서브넷에서 시작된 인스턴스의 경우 기본 프라이빗 IPv4 주소는 인스턴스 또는 인터페이스의 수명 동안 유지됩니다. 보조 프라이빗 IPv4 주소는 할당 또는 할당 취소될 수 있고 인터페이스나 인스턴스 간에 언제든지 이전될 수 있습니다. IPv6 전용 서브넷에서 시작된 인스턴스의 경우 인스턴스의 기본 네트워크 인터페이스에서 첫 번째 IP 주소이기도 한 할당된 IPv6 GUA는 언제든지 새 IPv6 GUA를 연결하고 기존 IPv6 GUA를 제거하여 수정할 수 있습니다.

실행 중인 인스턴스에 할당된 IPv4 주소의 경우 원래 실행 중이던 인스턴스가 "종료" 상태일 경우에는 다른 인스턴스에서 다시 사용할 수 있습니다. 그러나 실행 중인 인스턴스에 할당된 IPv6 GUA는 첫 번째 인스턴스에서 제거된 후 다른 인스턴스에서 다시 사용할 수 있습니다.

인스턴스를 시작하면 한 번에 하나의 인스턴스의 IP 주소를 지정할 수 있습니다.

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

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

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

예. 하지만 EIP 주소는 인터넷을 통해서만 연결할 수 있습니다(VPN 연결을 통해서는 안 됨). 각 EIP 주소는 인스턴스의 고유한 프라이빗 IP 주소와 연결되어야 합니다. EIP 주소는 트래픽을 인터넷 게이트웨이로 직접 라우팅하도록 구성된 서브넷의 인스턴스에서만 사용해야 합니다. EIP는 인터넷에 액세스하는데 NAT 게이트웨이 또는 NAT 인스턴스를 사용하도록 구성된 서브넷의 인스턴스에서는 사용할 수 없습니다. 이는 IPv4에만 해당됩니다. Amazon VPC는 현재 IPv6용 EIP를 지원하지 않습니다.

Bring Your Own IP(BYOIP)를 사용하면 고객이 자체 보유한 공개적으로 라우팅 가능한 IPv4 또는 IPv6 주소 공간의 전부 또는 일부를 AWS로 옮겨 AWS 리소스로 사용할 수 있습니다. 고객은 계속해서 IP 범위를 소유합니다. 고객은 AWS로 가져온 IPv4 공간에서 탄력적 IP를 생성하여 EC2 인스턴스, NAT 게이트웨이 및 Network Load Balancer와 함께 사용할 수 있습니다. 또한 AWS로 가져온 IPv6 공간에서 VPC에 최대 5개의 CIDR을 연결할 수 있습니다. Amazon에서 제공한 IP에 계속 액세스할 수 있으며 BYOIP 탄력적 IP, Amazon에서 제공한 IP 또는 둘 모두를 사용할 수 있습니다.

다음과 같은 이유로 자체 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 탄력적 IP를 해제하면 할당된 BYOIP IP 풀로 돌아갑니다.

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

예. 동일한 계정에서 BYOIP 접두사를 여러 VPC와 함께 사용할 수 있습니다.

계정에 최대 5개의 IP 범위를 가져올 수 있습니다.

BYOIP를 통해 가져올 수 있는 가장 구체적인 IPv4 접두사는 /24 IPv4 접두사와 /56 IPv6 접두사입니다. IPv6 접두사를 인터넷에 알리려는 경우 가장 구체적인 IPv6 접두사는 /48입니다.

ARIN, RIPE 및 APNIC 등록 접두사를 사용할 수 있습니다.

현재 재지정되거나 재할당된 접두사는 허용되지 않습니다. IP 범위는 직접 할당 또는 직접 지정의 순 유형이어야 합니다.

예. 현재 리전에서 BYOIP 접두사의 프로비저닝을 해제한 다음 새 리전에 프로비저닝하면 됩니다.

Amazon VPC IP 주소 관리자(IPAM)는 AWS 워크로드의 IP 주소를 더욱 쉽게 계획하고 추적하며 모니터링할 수 있도록 지원하는 관리형 서비스입니다. IPAM을 사용하면 라우팅 및 보안 요구에 따라 IP 주소를 쉽게 구성할 수 있으며 IP 주소 할당을 제어하는 간단한 비즈니스 규칙을 설정할 수 있습니다. 또한 VPC에 대한 IP 주소 할당을 자동화할 수 있으므로, 유지 관리가 어렵고 시간이 많이 소요될 수 있는 스프레드시트 기반 또는 자체 개발 IP 주소 계획 애플리케이션을 사용할 필요가 없습니다. IPAM은 신뢰할 수 있는 단일 소스로 사용할 수 있는 통합 운영 보기를 제공하므로 IP 사용률 추적, 문제 해결, 감사와 같은 일상적인 IP 주소 관리 활동을 빠르고 효율적으로 수행할 수 있습니다.

IP 주소를 더 효율적으로 관리하려면 IPAM을 사용해야 합니다. 스프레드시트 또는 자체 개발 도구를 활용하는 기존 메커니즘에는 수동 작업이 필요하고 오류가 발생하기 쉽습니다. 예를 들어 IPAM을 사용하면 개발자가 더 이상 중앙 IP 주소 관리 팀의 IP 주소 할당을 기다리지 않아도 될 만큼 신속하게 애플리케이션을 롤아웃할 수 있습니다. 또한 중복된 IP 주소를 감지하고 네트워크가 중단되기 전에 해결할 수 있습니다. 그리고 주소 풀이 거의 소진되거나 리소스가 풀에 설정된 할당 규칙을 준수하지 않는 경우 알림을 받을 수 있도록 IPAM에 대한 경보를 생성할 수 있습니다. 이것들은 IPAM을 사용해야 하는 많은 이유 중 일부입니다.

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에서는 VPC 할당을 위한 인접 IPv6 CIDR 블록을 제공합니다. 인접 CIDR 블록을 사용하면 액세스 제어 목록, 라우팅 테이블, 보안 그룹, 방화벽과 같은 네트워킹 및 보안 구성에서 단일 항목의 CIDR을 집계할 수 있습니다. Amazon IPv6 CIDR을 퍼블릭으로 영역이 제한된 풀로 프로비저닝하고 모든 IPAM 기능을 사용하여 IP 사용량을 관리 및 모니터링할 수 있습니다. 이러한 CIDR 블록 할당은 /52 증분으로 시작되며, 요청 시 더 큰 블록을 사용할 수 있습니다. 예를 들어 Amazon에서 /52 CIDR을 할당하고 IPAM을 사용하여 계정에서 공유하며 해당 계정에서 VPC를 생성할 수 있습니다.

아니요. Amazon 제공 인접 IPv6 CIDR 블록은 현재 IPAM에서만 지원됩니다.

AWS Resource Access Manager(RAM)를 사용하여 IPAM 풀을 AWS 조직의 다른 계정과 공유할 수 있습니다. 기본 AWS 조직 외의 계정과도 IPAM 풀을 공유할 수 있습니다. 예를 들어 이러한 계정은 회사의 다른 사업부 또는 다른 AWS 조직에서 사용자 대신 파트너가 호스팅하는 관리형 서비스일 수 있습니다.

예. 각각의 서브넷에 대해 기본 경로를 생성할 수 있습니다. 기본 경로는 인터넷 게이트웨이, 가상 프라이빗 게이트웨이 또는 NAT 게이트웨이를 통해 VPC에 송신되도록 트래픽을 보낼 수 있습니다.

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

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

VPC 내의 보안 그룹은 Amazon EC2 인스턴스 사이에서 어떤 트래픽을 허용할 것인지를 지정합니다. 네트워크 ACL은 서브넷 수준에서 작동하며, 서브넷에 출입하는 트래픽을 평가합니다. 네트워크 ACL을 사용하여 허용 및 거부 규칙을 설정할 수 있습니다. 네트워크 ACL은 동일한 서브넷에 있는 인스턴스 간 트래픽은 필터링하지 않습니다. 또한, 보안 그룹이 상태 저장 필터링을 수행하는 반면 네트워크 ACL은 상태 비 저장 필터링을 수행합니다.

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

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

예. 인터넷 게이트웨이가 구성되면, VPC 외부의 Amazon EC2 인스턴스로 향하는 Amazon VPC 트래픽은 인터넷 게이트웨이를 통과한 후, 퍼블릭 AWS 네트워크를 통해 EC2 인스턴스에 전달됩니다. 인터넷 게이트웨이가 구성되어 있지 않거나 인스턴스가 가상 프라이빗 게이트웨이를 통해 라우팅되도록 구성된 서브넷에 있을 경우, 트래픽은 VPN 연결을 통과하고, 데이터 센터를 벗어난 후, 퍼블릭 AWS 네트워크로 재진입하게 됩니다.

예. 한 리전의 인스턴스는 Inter-Region VPC Peering, 퍼블릭 IP 주소, NAT 게이트웨이, NAT 인스턴스, VPN Connections 또는 Direct Connect 연결을 사용하여 서로 통신할 수 있습니다.

예. 사용자의 리소스가 VPC 내에서 Amazon S3와 통신할 수 있는 여러 옵션이 있습니다. S3용 VPC 엔드포인트를 사용하면 모든 트래픽이 Amazon의 네트워크 내에서 유지되도록 하고, 추가적인 액세스 정책을 Amazon S3 트래픽에 적용할 수 있습니다. 인터넷 게이트웨이를 사용하면 VPC에서 인터넷에 액세스할 수 있으며, VPC의 인스턴스가 Amazon S3와 통신할 수 있습니다. 또한 Amazon S3의 모든 트래픽이 Direct Connect 또는 VPN 연결을 트래버스하고 데이터센터에서 벗어나 퍼블릭 AWS 네트워크로 재진입하도록 할 수 있습니다.

예. Amazon VPC 트래픽 미러링 및 Amazon VPC 흐름 로그 기능을 사용하여 Amazon VPC의 네트워크 트래픽을 모니터링할 수 있습니다.

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

VPC, 서브넷 또는 네트워크 인터페이스에 대해 흐름 로그를 생성할 수 있습니다. 서브넷 또는 VPC에 대한 흐름 로그를 생성하면 해당 서브넷 또는 VPC의 각 네트워크 인터페이스가 모니터링됩니다. 흐름 로그 구독을 생성하는 동안 캡처할 메타데이터 필드, 최대 집계 간격 및 기본 로그 대상을 선택할 수 있습니다. 또한 모든 트래픽을 캡처하도록 선택할 수도 있고 승인되거나 거부된 트래픽만 캡처하도록 선택할 수도 있습니다. CloudWatch Log Insights 또는 CloudWatch Contributor Insights와 같은 도구를 사용하여 CloudWatch Logs로 전송되는 VPC 흐름 로그를 분석할 수 있습니다. Amazon Athena 또는 AWS QuickSight와 같은 도구를 사용하여 Amazon S3로 전송되는 VPC 흐름 로그를 쿼리하고 시각화할 수 있습니다. 또한 사용자 지정 다운스트림 애플리케이션을 구축하여 로그를 분석하거나, Splunk, Datadog, Sumo Logic, Cisco StealthWatch, Checkpoint CloudGuard, New Relic 등의 파트너 솔루션을 사용할 수도 있습니다.

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

흐름 로그 데이터는 네트워크 트래픽 경로 외부에서 수집되므로 네트워크 처리량이나 지연 시간에 영향을 미치지 않습니다. 흐름 로그를 생성하거나 삭제더라도 네트워크 성능에 영향을 미치지 않습니다.

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

고객은 Amazon VPC 트래픽 미러링을 사용하여 콘텐츠 검사, 위협 모니터링, 문제 해결 등의 사용 사례를 위해 Amazon EC2 인스턴스의 네트워크 트래픽을 복제하고 대역 외 보안 및 모니터링 어플라이언스로 전달하는 과정을 손쉽게 처리할 수 있습니다. 이러한 어플라이언스는 개별 EC2 인스턴스 또는 UDP(User Datagram Protocol) 리스너가 있는 NLB(Network Load Balancer) 뒤의 인스턴스 플릿에 배포될 수 있습니다.

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

고객은 오픈 소스 도구를 사용할 수도 있고, AWS Marketplace에서 제공되는 광범위한 모니터링 솔루션 중에서 선택할 수도 있습니다. 트래픽 미러링을 사용하는 고객은 공급업체별 에이전트를 설치할 필요 없이 복제된 트래픽을 네트워크 패킷 수집기/브로커 또는 분석 도구로 스트리밍할 수 있습니다.

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

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

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

예. 

아니요. 한 서브넷은 하나의 가용 영역 내에서만 상주해야 합니다.

Amazon EC2 인스턴스를 시작할 때 반드시 인스턴스를 시작할 서브넷을 지정해야 합니다. 인스턴스는 지정한 서브넷과 연결된 가용 영역 내에서 시작합니다.

서브넷을 생성할 때, 반드시 서브넷을 배치할 가용 영역을 지정해야 합니다. VPC 마법사를 사용할 때, 마법사 구성 화면에서 서브넷 가용 영역을 선택할 수 있습니다. API 또는 CLI를 사용하여, 서브넷을 생성할 때 서브넷에 대한 가용 영역을 지정할 수 있습니다. 가용 영역을 지정하지 않으면 "No Preference" 옵션이 기본적으로 선택되며 리전에서 사용 가능한 가용 영역에 서브넷이 생성됩니다.

인스턴스가 다른 가용 영역에 있는 서브넷에 상주할 경우, GB당 0.01 USD의 데이터 전송 요금이 부과됩니다.

예. DescribeInstances()는 모든 실행 중인 Amazon EC2 인스턴스를 반환합니다. 서브넷 필드에 있는 항목으로 EC2-VPC 인스턴스와 EC2-Classic 인스턴스를 구별할 수 있습니다. 서브넷 ID의 목록이 있다면, 인스턴스는 VPC 내에 있는 것입니다.

예. DescribeVolumes()는 모든 EBS 볼륨을 반환합니다.

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에서 확인할 수 있습니다.

예. 하지만 Amazon EBS-backed AMI를 사용하여 VPC에서 시작한 인스턴스는 중지될 때와 다시 시작할 때 동일한 IP 주소를 유지합니다. VPC 외부에서 시작한 유사한 인스턴스가 새 IP 주소를 얻는 것과는 대조됩니다. 서브넷에서 중지된 인스턴스에 대한 IP 주소는 이용할 수 없는 것으로 간주합니다.

예.

예. 

예. 클러스터 인스턴스는 Amazon VPC에서 지원되지만, 모든 인스턴스 유형을 모든 리전 및 가용 영역에서 사용할 수 있는 것은 아닙니다.

인스턴스를 시작하면 호스트 이름이 할당됩니다. IP 기반 이름 또는 리소스 기반 이름의 두 가지 옵션을 사용할 수 있으며 이 파라미터는 인스턴스 시작 시 구성할 수 있습니다. IP 기반 이름은 프라이빗 IPv4 주소 형식을 사용하는 반면 리소스 기반 이름은 instance-id 형식을 사용합니다.

예, 인스턴스를 중지한 다음 리소스 기반 이름 지정 옵션을 변경하여 인스턴스 양식 IP 기반의 호스트 이름을 리소스 기반으로 또는 그 반대로 변경할 수 있습니다.

예, 인스턴스 호스트 이름을 DNS 호스트 이름으로 사용할 수 있습니다. IPv4 전용 또는 이중 스택 서브넷에서 시작된 인스턴스의 경우 IP 기반 이름은 항상 인스턴스의 기본 네트워크 인터페이스에서 프라이빗 IPv4 주소로 확인되며 비활성화할 수 없습니다. 또한 리소스 기반 이름은 기본 네트워크 인터페이스의 프라이빗 IPv4 주소나 기본 네트워크 인터페이스의 첫 번째 IPv6 GUA 또는 둘 다로 확인하도록 구성할 수 있습니다. IPv6 전용 서브넷에서 시작된 인스턴스의 경우 리소스 기반 이름은 기본 네트워크 인터페이스의 첫 번째 IPv6 GUA로 확인되도록 구성됩니다. 

기본 VPC는 AWS 클라우드 내에 있는 논리적으로 격리된 가상 네트워크로서, 처음 Amazon EC2 리소스를 프로비저닝할 때 사용자의 AWS 계정에 자동으로 생성됩니다. 서브넷 ID를 지정하지 않고 인스턴스를 시작하면 인스턴스가 기본 VPC에서 시작됩니다.

기본 VPC에서 리소스를 시작할 경우, Amazon VPC(EC2-VPC)의 고급 네트워킹 기능을 활용할 수 있을 뿐만 아니라 Amazon EC2(EC2-Classic)를 편리하게 사용할 수 있습니다. VPC를 별도로 생성하여 VPC에서 인스턴스를 시작하지 않고도 보안 그룹 회원을 즉각적으로 변경하거나 보안 그룹 송신 필터링, 다중 IP 주소 및 다중 네트워크 인터페이스와 같은 기능을 활용할 수 있습니다.

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

AWS Management Console, AWS EC2 CLI 또는 Amazon EC2 API를 사용하여 기본 VPC에서 EC2 인스턴스와 기타 AWS 리소스를 시작하고 관리할 수 있습니다. AWS에서 자동으로 기본 VPC를 생성하고 AWS 리전의 각 가용 영역에 기본 서브넷을 생성합니다. 기본 VPC는 인터넷 게이트웨이에 연결되고 사용자의 인스턴스는 EC2-Classic과 마찬가지로 퍼블릭 IP 주소를 자동으로 부여받습니다.

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

기본 VPC는 인터넷에 연결되어 있으며 기본 VPC 내의 기본 서브넷 에서 시작된 모든 인스턴스는 자동으로 퍼블릭 IP 주소를 받게 됩니다. 원할 경우, 사용자의 기본 VPC에 VPN 연결을 추가할 수 있습니다.

예. 기본이 아닌 VPC에서 인스턴스를 시작하려면 인스턴스 시작 과정 중에서 서브넷 ID를 지정하여야 합니다.

예. 기본 서브넷이 아닌 다른 서브넷에서 시작하려면, 콘솔을 사용하거나 CLI, API 또는 SDK에서 --subnet 옵션을 사용해 시작할 서브넷을 지정할 수 있습니다.

Supported Platforms 속성이 "EC2-VPC"로 설정된 각 AWS 리전에서 1개의 기본 VPC를 보유할 수 있습니다.

사용자의 기본 VPC에 있는 가용 영역당 하나의 기본 서브넷이 생성됩니다.

현재는 지원되지 않습니다.

현재는 지원되지 않습니다.

예. 기본 VPC를 삭제할 수 있습니다. 삭제한 후에는 VPC 콘솔에서 바로 또는 CLI를 사용하여 새로운 기본 VPC를 생성할 수 있습니다. 그러면 리전에 새로운 기본 VPC가 생성됩니다. 삭제가 이전 VPC가 복원되지는 않습니다.

예. 기본 서브넷을 삭제할 수 있습니다. 삭제되고 나면 CLI 또는 SDK를 사용하여 가용 영역에 새로운 기본 서브넷을 생성할 수 있습니다. 그러면 지정된 가용 영역에 새로운 기본 서브넷이 생성되며, 삭제된 이전 서브넷은 복원되지 않습니다.

기본 VPC를 보유하는 가장 간단한 방법은 기본 VPC가 활성화된 리전에 새 계정을 생성하거나, 이전에 사용한 적이 없는 리전에 있는 기존 계정을 사용하는 것입니다. 그 리전에 있는 해당 계정의 Supported Platforms 속성이 "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 계정에 기본 VPC가 있는 경우 사용자의 AWS 계정에 연결된 IAM 계정은 AWS 계정과 동일한 기본 VPC를 사용합니다.

EC2-Classic은 2006년 여름에 EC2와 함께 출시한 플랫 네트워크입니다. EC2-Classic을 사용하면 인스턴스가 다른 고객과 공유하는 단일 플랫 네트워크에서 실행됩니다. 시간이 지나면서 고객의 진화하는 요구에서 아이디어를 얻어 사용자의 AWS 계정과 논리적으로 격리된 가상 프라이빗 클라우드에서 인스턴스를 실행할 수 있는 Amazon Virtual Private Cloud(VPC)를 2009년에 출시했습니다. 현재는 대다수 고객들이 Amazon VPC를 사용하며 소수의 고객들만이 EC2-Classic을 사용합니다.

2022년 8월 15일에 Amazon EC2-Classic을 사용 중지하므로 이 날짜 전까지 EC2-Classic에서 실행 중인 EC2 인스턴스 및 기타 AWS 리소스를 Amazon VPC로 마이그레이션해야 합니다. 다음 섹션에서는 EC2-Class 사용 중지와 마이그레이션을 지원할 도구 및 리소스에 대해 자세히 설명합니다.

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

리전에서 EC2-Classic에 실행 중인 활성 AWS 리소스가 없는 경우 해당 리전에 대해 계정에서 EC2-Classic을 끄십시오. 리전에서 EC2-Classic을 끄면 해당 리전에서 기본 VPC를 시작할 수 있습니다. 이렇게 하려면 AWS Support Center(console.thinkwithwp.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에 상주하는 인스턴스에만 연결할 수 있습니다.

예. 하지만 인터페이스가 여러 개인 경우에는 가장 좋은 방법은 아닙니다. 대신 인스턴스에 프라이빗 IP 주소를 추가로 할당하고 필요에 따라 프라이빗 IP에 EIP를 연결합니다.

EC2 인스턴스에 보조 인터페이스(eth1-ethn)를 연결하고 분리할 수는 있으나, eth0 인터페이스를 분리할 수는 없습니다.

예. 다른 리전에서 VPC를 사용하여 피어링 연결을 생성할 수 있습니다. 리전 간 VPC 피어링은 전 세계 모든 상용 리전(중국 제외)에서 사용할 수 있습니다.

예. 다른 VPC의 소유자가 피어링 연결 요청을 허용한 경우 가능합니다.

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

VPC 피어링 연결에는 인터넷 게이트웨이가 필요하지 않습니다.

피어링된 VPC 내 인스턴스 간 트래픽은 프라이빗 상태를 유지하며 격리됩니다. 이는 동일한 VPC 내 두 인스턴스 간 트래픽이 프라이빗 상태를 유지하며 격리되는 것과 유사합니다.

피어링 연결된 양측 모두 언제든지 피어링 연결을 종료할 수 있습니다. 피어링 연결을 종료하면 두 VPC 간 트래픽을 주고받지 않게 됩니다.

전이성 피어링 관계는 지원되지 않습니다.

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

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

Inter-Region Peering 연결이 끊어지는 경우 트래픽이 인터넷을 통해 라우팅되지 않습니다.

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

트래픽은 최신 AEAD(Authenticated Encryption with Associated Data) 알고리즘을 사용하여 암호화됩니다. AWS에서 키 계약 및 관리를 처리합니다.

기본적으로 다른 리전의 피어링된 VPC에서 인스턴스에 대한 퍼블릭 호스트 이름 쿼리는 퍼블릭 IP 주소로 확인됩니다. 53 프라이빗 DNS 라우팅은 Inter-Region VPC Peering을 사용한 프라이빗 IP 주소를 해결하는 데 사용할 수 있습니다.

리전 간 VPC 피어링 연결 사이에서 보안 그룹을 참조할 수 없습니다.

예. 리전 간 VPC 피어링은 IPv6를 지원합니다.

리전 간 VPC 피어링은 EC2-ClassicLink와 함께 사용할 수 없습니다.

Amazon Virtual Private Cloud(VPC) ClassicLink는 EC2-Classic 플랫폼의 EC2 인스턴스가 프라이빗 IP 주소를 사용해 VPC의 인스턴스와 통신할 수 있도록 지원합니다. ClassicLink를 사용하려면 사용자 계정에서 VPC에 ClassicLink를 활성화한 후 VPC의 보안 그룹과 EC2-Classic의 인스턴스를 연결하십시오. VPC 보안 그룹의 모든 규칙은 EC2-Classic의 인스턴스와 VPC의 인스턴스 간 통신에 적용됩니다. 

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

ClassicLink를 사용하려면 먼저 사용자 계정에 있는 하나 이상의 VPC에서 ClassicLink를 활성화해야 합니다. 그런 다음 VPC의 보안 그룹과 원하는 EC2-Classic 인스턴스를 연결합니다. EC2-Classic 인스턴스가 현재 VPC에 연결되고 VPC에서 선택한 보안 그룹의 멤버가 됩니다. EC2-Classic 인스턴스를 둘 이상의 VPC와 동시에 연결할 수 없습니다.

EC2-Classic 인스턴스는 VPC 멤버가 되지 않습니다. 해당 인스턴스와 연결된 VPC 보안 그룹의 멤버가 됩니다. VPC 보안 그룹에 대한 참조와 모든 규칙은 EC2-Classic 인스턴스의 인스턴스와 VPC 내 리소스 간 통신에 적용됩니다.

아니요. EC2-Classic 인스턴스에서 쿼리할 때 EC2 퍼블릭 DNS 호스트 이름으로는 EC2-VPC 인스턴스의 프라이빗 IP 주소를 확인할 수 없습니다. 반대의 경우도 마찬가지입니다.

예. VPC의 CIDR(Classless Inter-Domain Routing)이 10.0.0.0/8 범위(10.0.0.0/16 및 10.1.0.0/16 제외)에 속하는 경우 ClassicLink를 활성화할 수 없습니다. 또한, 10.0.0.0/8 CIDR 공간에서 '로컬' 외 대상을 가리키는 라우팅 테이블이 있는 VPC에 대해 ClassicLink를 활성화할 수 없습니다.

EC2-Classic 인스턴스의 트래픽은 VPC 내 프라이빗 IP 주소로만 라우팅될 수 있습니다. 인터넷 게이트웨이, 가상 프라이빗 게이트웨이 또는 피어링된 VPC 대상을 비롯하여 VPC 외부에 있는 대상으로는 라우팅되지 않습니다.

ClassicLink는 EC2-Classic 플랫폼의 기존 보안 그룹을 통해 EC2-Classic 인스턴스에 대해 정의된 액세스 제어를 변경하지 않습니다.

ClassicLink 연결은 EC2-Classic 인스턴스의 중지/시작 주기 동안 지속되지 않습니다. EC2-Classic 인스턴스를 중지하고 시작한 후 다시 VPC에 연결해야 합니다. 그렇지만 인스턴스 재부팅 주기 동안 ClassicLink 연결이 지속됩니다.

ClassicLink를 사용하여 EC2-Classic 보안 그룹 규칙에 VPC 보안 그룹을 참조할 수 없습니다. 반대의 경우도 같습니다.

AWS PrivateLink는 모든 네트워크 트래픽을 AWS 네트워크 내부에 유지하면서 고객이 높은 가용성과 확장성 방식으로 AWS에 호스팅된 서비스에 액세스할 수 있도록 합니다. 고객은 이 기능을 통해 퍼블릭 IP나 인터넷 연결 트래픽 없이도 자신의 온프레미스 또는 Amazon Virtual Private Cloud(VPC)에서 PrivateLink로 구동되는 서비스에 비공개로 액세스할 수 있습니다. 서비스 소유자는 자신의 Network Load Balancers를 PrivateLink 서비스에 등록하고 다른 AWS 고객에게 서비스를 제공할 수 있습니다.

서비스 사용자는 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 제품에 대해 더 자세히 알아볼 수 있습니다.

예. 온프레미스에 있는 애플리케이션은 AWS Direct Connect를 통해 Amazon VPC에 있는 서비스 엔드포인트에 연결할 수 있습니다. 서비스 엔드포인트에서는 자동으로 AWS PrivateLink에서 지원하는 AWS 서비스로 트래픽을 보냅니다.

예. AWS Management Console을 사용하여 VPC, 서브넷, 라우팅 테이블, 인터넷 게이트웨이, IPSec VPN 연결 등의 Amazon VPC 객체를 관리할 수 있습니다. 또한 간편한 마법사를 사용하여 VPC를 생성할 수도 있습니다.

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

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

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