Web Server에는 서버 팜의 서버 전체에 대해 향상된 분산 관리 기능을 제공하는 새로운 관리 프레임워크가 포함되어 있습니다. 강력한 관리 기능을 통해 그래픽 인터페이스와 명령줄 인터페이스를 모두 사용하여 Web Server를 원격으로 관리 및 배포할 수 있습니다. 서버 팜의 중앙 위치에서 서버를 관리하고 하나 이상의 노드에 배포하여 서버 인스턴스를 만들 수 있습니다. 이러한 서버에 대한 모니터링 및 라이프사이클 관리 기능도 제공됩니다. Show Web Server는 다양한 기능을 설정 또는 해제하거나, 개별 클라이언트 요청에 대한 응답 방식을 결정하거나, 서버에서 실행되며 서버의 작업과 통합되는 프로그램을 작성할 수 있도록 구성됩니다. 이러한 옵션을 식별하는 지침(지시문)은 구성 파일에 저장됩니다. Web Server 는 시작할 때와 클라이언트 요청 중에 구성 파일을 읽어 선택 사항을 원하는 서버 작동과 매핑합니다. 이 파일에 대한 자세한 내용은 Web Server Administrator's Configuration File Reference Guide를 참조하십시오. Web Server 에서는 웹 응용 프로그램, 구성 파일, 검색 모음 색인과 같은 서버 인스턴스의 구성 가능한 모든 요소가 논리적으로 그룹화되어 구성이라고 불립니다. 구성은 CLI 또는 웹 기반 관리 인터페이스를 사용하여 작성, 수정 또는 삭제할 수 있습니다. 한 번에 두 개 이상의 구성을 관리할 수 있습니다. 구성이라는 용어는 서버의 런타임 서비스를 구성하는 메타데이터 집합을 나타내기도 합니다. 예를 들어 런타임 서비스는 구성된 문서 루트의 웹 페이지를 제공합니다. 구성 메타데이터는 서버 런타임이 내장 서비스와 타사 플러그인을 로드하고, 데이터베이스 드라이버와 같은 다른 서버 확장이 웹 페이지 및 동적 웹 응용 프로그램을 제공하도록 설정하는 데 사용됩니다. 주 – 구성 관련 파일은 모두 파일 시스템의 구성 저장소라고 하는 저장소에 저장됩니다. 이 설명서에 명시되어 있지 않은 한 이 저장소에 있는 파일을 직접 편집하면 안 됩니다. Web Server에서 CLI를 사용하거나 웹 기반 관리 인터페이스를 통해 수행하는 구성 변경은 먼저 구성 저장소에서 이루어지며, 그 후에 구성이 배포됩니다. 이어서 변경 사항이 인스턴스 디렉토리에 복사됩니다. 웹 응용 프로그램은 다음 위치에 배포됩니다. <install_dir>/admin-server/config-store/<config_name>/web-app/<virtual_servername>/ 구성을 배포하면 config-store 아래에 있는 전체 웹 응용 프로그램 디렉토리 및 구성 디렉토리가 압축되어 서버 인스턴스 디렉토리에 복사됩니다. 이 파일은 다음 위치에 있는 current.zip 파일입니다. <install_dir>/admin-server/config-store/<config_name> 따라서 웹 응용 프로그램의 크기에 따라 선택한 구성의 배포를 완료하는 데 시간이 걸릴 수 있습니다. 다음 그림은 구성을 관리 노드에 배포하는 방식을 개략적으로 나타낸 그림입니다.  노드(서버 또는 호스트 등의 네트워크 자원)에 구성을 배포하면 해당 구성의 인스턴스가 만들어집니다. 인스턴스에는 로그 파일을 비롯해 잠금 데이터베이스, 캐시 및 인스턴스에 필요한 임시 파일 등의 다른 런타임 파일이 포함되어 있습니다. CLI 또는 웹 기반 관리 인터페이스를 통해 이러한 인스턴스를 관리할 수 있습니다. 인스턴스가 하나 이상의 노드에 걸쳐 클러스터를 형성할 수도 있습니다. 클러스터의 경우 클러스터를 형성하는 모든 노드는 구성이 동일해야 합니다. 클러스터에 있는 모든 노드는 동일한 유형이어야 합니다. 이러한 인스턴스는 운영 체제가 동일해야 하고 동일하게 구성되며 동일한 서비스를 제공해야 합니다. 서버 팜에서 하나의 노드에는 관리 응용 프로그램이 배포된 서버가 실행되고 있습니다. 특별하게 구성된 이러한 서버를 Administration Server라고 하며, 여기에 배포되는 관리 응용 프로그램은 웹 기반 관리 콘솔이라고 합니다. 관리 콘솔을 사용하면 서버 인스턴스의 라이프사이클을 제어할 수 있습니다. Administration Server는 그 노드의 다른 서버(관리 노드)에서 이루어지는 작업을 제어합니다. 관리 노드는 GUI 인터페이스를 제공하지 않습니다. 서버 팜의 한 노드에는 Administration Server가 설치됩니다. 서버 팜에 있는 다른 모든 노드에는 관리 노드가 설치됩니다. 관리 노드는 설치 즉시 Administration Server에 등록됩니다. 이 작업으로 Administration Server가 관리 노드를 인식하게 됩니다. Administration Server와 관리 노드는 항상 SSL을 통해 통신합니다. Administration Server와 관리 노드는 Administration Server에서 관리 노드의 서버 인증서를 신뢰하고 관리 노드에서 Administration Server가 제시하는 클라이언트 인증서를 신뢰하는 방식으로 서로를 인증합니다. 관리 노드를 등록하는 동안 Administration Server는 해당 관리 노드의 서버 인증서를 생성합니다. 생성된 인증서는 다운로드되어 관리 노드에 설치됩니다. 서버 인증서 발급자도 관리 노드에 설치됩니다. 일반 질문Q: Amazon Virtual Private Cloud란 무엇입니까? Amazon VPC를 사용하면 Amazon Web Services(AWS) 클라우드에서 논리적으로 격리된 공간을 프로비저닝하고, 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. 자체 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워킹 환경을 완벽하게 제어할 수 있습니다. 또한, 기업 데이터 센터와 VPC 사이에 하드웨어 가상 프라이빗 네트워크(VPN) 연결을 생성하여, 기업 데이터 센터의 확장으로서 AWS 클라우드를 사용할 수 있습니다. Amazon VPC용 네트워크 구성을 손쉽게 사용자 지정할 수 있습니다. 예를 들어, 인터넷에 액세스할 수 있는 웹 서버를 위해 퍼블릭 서브넷을 생성할 수 있으며, 인터넷 액세스가 없는 프라이빗 서브넷에 데이터베이스나 애플리케이션 서버와 같은 백엔드 시스템을 배치할 수 있습니다. 보안 그룹 및 네트워크 액세스 제어 목록을 포함한 다중 보안 계층을 활용하여 각 서브넷에서 Amazon EC2 인스턴스에 대한 액세스를 제어하도록 지원할 수 있습니다. Q: Amazon VPC의 구성 요소는 무엇입니까? Amazon VPC는 기존 네트워크를 사용하던 고객에게 익숙한 여러 객체로 구성되어 있습니다.
Q: Amazon VPC를 사용해야 하는 이유는 무엇입니까? Amazon VPC를 통해 AWS 클라우드에서 가상 네트워크를 구축할 수 있으며, VPN, 하드웨어, 물리적 데이터 센터는 필요하지 않습니다. 자체 네트워크 공간을 정의하고 네트워크 및 네트워크 내에 있는 Amazon EC2 리소스가 인터넷에 노출되는 방식을 제어할 수 있습니다. 또한, Amazon VPC의 월등하게 향상된 보안 옵션을 이용하여 가상 네트워크 내 Amazon EC2 인스턴스에 더 세분화된 방식으로 액세스할 수 있습니다. Q: Amazon VPC를 시작하려면 어떻게 해야 합니까? 바로 사용 가능한 기본 VPC에 AWS 리소스가 자동으로 프로비저닝됩니다. AWS Management Console의 Amazon VPC 페이지로 이동하여 [Start VPC Wizard]를 선택하면 추가 VPC를 만들 수 있습니다. 네트워크 아키텍처에 대한 네 가지 기본 옵션을 확인할 수 있습니다. 옵션을 선택한 다음, VPC와 서브넷의 크기 및 IP 주소 범위를 변경할 수 있습니다. Hardware VPN Access 옵션을 선택하면 네트워크 상에서 VPN 하드웨어의 IP 주소를 지정해야 합니다. 보조 IP 범위와 게이트웨이를 추가 또는 제거하거나 더 많은 서브넷을 IP 범위에 추가하도록 VPC를 변경할 수 있습니다. 네 가지 옵션은 다음과 같습니다.
Q: Amazon VPC에서 사용할 수 있는 VPC 엔드포인트 유형에는 어떤 것이 있습니까? VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 또는 방화벽 프록시를 사용하지 않고도 VPC를 AWS에서 호스팅하는 서비스와 비공개로 연결할 수 있습니다. 엔드포인트는 수평적으로 확장 가능하며 가용성이 매우 뛰어난 가상 디바이스로서, VPC 내 인스턴스와 AWS 서비스 간에 통신을 허용합니다. Amazon VPC는 게이트웨이 유형 엔드포인트와 인터페이스 유형 엔드포인트라는 두 가지 유형의 엔드포인트를 제공합니다. 게이트웨이 유형 엔드포인트는 S3 및 DynamoDB를 비롯한 AWS 서비스에서만 이용할 수 있습니다. 이러한 엔드포인트는 사용자가 선택한 라우팅 테이블에 항목을 추가하고, 트래픽을 Amazon의 프라이빗 네트워크를 통해 지원되는 서비스로 라우팅합니다. 인터페이스 유형 엔드포인트는 AWS 서비스인 PrivateLink에서 지원하는 서비스, 자체 서비스 또는 SaaS 솔루션에 비공개로 연결할 수 있으며, Direct Connect를 통한 연결을 지원합니다. 앞으로 이러한 엔드포인트에서 더 많은 AWS 및 SaaS 솔루션을 지원할 예정입니다. 인터페이스 유형 엔드포인트의 요금은 VPC 요금 페이지를 참조하십시오. 결제Q: Amazon VPC의 사용료는 어떻게 과금되어 청구됩니까? VPC 자체를 생성 및 사용하는 데에는 별도의 비용이 없습니다. Amazon EC2와 같은 다른 Amazon Web Services 사용 요금의 경우, 데이터 전송 요금을 비롯하여 해당 리소스에 대해 명시된 요금이 적용됩니다. 선택 사항인 하드웨어 VPN 연결을 사용하여 VPC를 회사의 데이터 센터에 연결하는 경우, VPN 연결 시간(VPN 연결이 "사용 가능" 상태인 시간)당 요금이 부과됩니다. 1시간 미만으로 사용해도 1시간 사용 요금이 청구됩니다. VPN 연결을 통해 전송된 데이터는 표준 AWS 데이터 전송 요금이 청구됩니다. VPC-VPN 요금에 대한 자세한 정보는 Amazon VPC 제품 페이지의 요금 섹션을 참조하시기 바랍니다. Q: 개인 VPC에서 Amazon EC2 인스턴스의 다른 AWS 서비스(예: Amazon S3)를 사용하면 어떤 사용료가 발생합니까? Amazon EC2와 같은 다른 Amazon Web Services에 대한 사용 요금에 대해서는 해당 리소스에 대해 명시된 요금이 적용됩니다. VPC의 인터넷 게이트웨이를 통해 Amazon S3와 같은 Amazon Web Services에 액세스하는 동안에는 데이터 전송 요금이 발생하지 않습니다. VPN 연결을 통해 AWS 리소스에 액세스하면 인터넷 데이터 전송 요금이 청구됩니다. Q: 요금에 세금이 포함되어 있습니까? 명시된 경우를 제외하고 요금에는 VAT 및 해당 판매세를 비롯한 관련 조세 공과가 포함되지 않습니다. 청구지 주소가 일본으로 되어 있는 고객의 경우 AWS 서비스 사용 시 일본 소비세의 적용을 받게 됩니다. 자세히 알아보십시오. 연결Q: Amazon VPC의 연결 옵션에는 무엇이 있습니까? Amazon VPC를 다음 대상에 연결할 수 있습니다.
Q: VPC를 인터넷에 연결하려면 어떻게 해야 합니까? Amazon VPC는 인터넷 게이트웨이 생성을 지원합니다. 이 게이트웨이를 사용하면 VPC 내 Amazon EC2 인스턴스가 인터넷에 직접 액세스할 수 있습니다. VPC에서 인터넷으로 IPv6 트래픽에 대하여 송신 전용 액세스를 제공하는 상태 유지 게이트웨이인 송신 전용 인터넷 게이트웨이를 사용할 수도 있습니다. Q: 인터넷 게이트웨이에 대한 대역폭 제한이 있습니까? 가용성에 대해 걱정해야 합니까? 단일 장애 지점일 수 있습니까? 아니요. 인터넷 게이트웨이는 수평적으로 확장되고, 중복적이며, 가용성이 뛰어납니다. 인터넷 게이트웨이에 대한 대역폭 제한은 없습니다. Q: VPC에 있는 인스턴스는 어떻게 인터넷에 액세스합니까? 탄력적 IP 주소(EIP)와 IPv6 글로벌 고유 주소(GUA)를 비롯한 퍼블릭 IP 주소를 사용하면 VPC 내의 인스턴스가 인터넷으로 직접 아웃바운드 통신을 수행하고 인터넷으로부터(예: 웹 서버) 임의의 인바운드 트래픽을 수신할 수 있습니다. 다음 질문의 솔루션을 사용할 수도 있습니다. Q: IP 주소는 언제 퍼블릭 IP 주소로 간주되나요? 인터넷을 통해 액세스할 수 있는 VPC에서 호스팅되는 서비스 또는 인스턴스에 할당된 모든 IP 주소는 퍼블릭 IP 주소로 간주됩니다. 탄력적 IP 주소(EIP) 및 IPv6 GUA를 포함한 퍼블릭 IPv4 주소만
인터넷에서 라우팅할 수 있습니다. 이렇게 하려면 먼저 VPC를 인터넷에 연결한 다음 인터넷에서 연결할 수 있도록 라우팅 테이블을 업데이트해야 합니다. Q: 퍼블릭 IP 주소가 없는 인스턴스가 인터넷에 액세스하려면 어떻게 해야 합니까 퍼블릭 IP 주소가 없는 인스턴스는 다음 두 가지 방법 중 하나를 사용하여 인터넷에 액세스할 수 있습니다.
Q: 소프트웨어 VPN을 사용하여 VPC에 연결할 수 있습니까? 예. 타사 소프트웨어 VPN을 사용하여 인터넷 게이트웨이를 통한 VPC와 사이트 간 또는 원격 액세스 VPN 연결을 생성할 수 있습니다. Q: 두 인스턴스가 퍼블릭 IP 주소를 사용하여 통신할 경우 또는 인스턴스가 퍼블릭 AWS 서비스 엔드포인트와 통신할 경우 트래픽이 인터넷을 통해 전송되나요? 아니요. 퍼블릭 IP 주소를 사용할 경우 AWS에서 호스팅되는 인스턴스와 서비스 간의 모든 통신에는 AWS의 프라이빗 네트워크가 사용됩니다. AWS 네트워크에서 생성되고 그 대상도 AWS 네트워크에 있는 패킷은 AWS 글로벌 네트워크를 벗어나지 않습니다. 단, AWS 중국 리전으로 들어오거나 나가는 트래픽은 예외입니다. 또한 데이터 센터 및 리전을 상호 연결하는 AWS 글로벌 네트워크를 통해 이동하는 모든 데이터는 보안 시설을 떠나기 전에 물리적 계층에서 자동으로 암호화됩니다. 예를 들어 모든 VPC 교차 리전 피어링 트래픽, 고객 또는 서비스 간 TLS(전송 계층 보안) 연결 등 추가적인 암호화 계층도 존재합니다. Q: AWS Site-to-Site VPN 연결은 Amazon VPC에서 어떻게 작동합니까? AWS Site-to-Site VPN 연결은 사용자의 VPC를 데이터센터에 연결합니다. Amazon은 인터넷 프로토콜 보안 (IPsec) VPN 연결을 지원합니다. VPC와 데이터센터 간에 전송되는 데이터는 암호화된 VPN 연결을 통해 라우팅되어 전송 데이터의 기밀성과 무결성이 유지됩니다. AWS Site-to-Site VPN 연결을 형성하는데 인터넷 게이트웨이는 필요하지 않습니다. IP 주소 지정Q: Amazon VPC에서 사용할 수 있는 IP 주소 범위는 어떻게 됩니까? RFC 1918 또는 공개적으로 라우팅이 가능한 IP 범위를 비롯하여 모든 IPv4 주소 범위를 기본 CIDR 블록에 사용할 수 있습니다. 보조 CIDR 블록에는 특정 제약 조건이 적용됩니다. 공개적으로 라우팅이 가능한 IP 블록은 가상 프라이빗 게이트웨이를 통해서만 연결할 수 있으며, 인터넷 게이트웨이를 통해서는 인터넷상에서 액세스할 수 없습니다. AWS는 고객 소유 IP 주소 블록을 인터넷에 노출하지 않습니다. 관련 API를 호출하거나 AWS 관리 콘솔을 통해 최대 5개의 AWS 제공 또는 BYOIP IPv6 GUA CIDR 블록을 VPC에 할당할 수 있습니다. Q: IP 주소 범위를 Amazon 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에 할당할 수 있습니다. Q: 기본 Amazon VPC에는 어떠한 IP 주소 범위가 할당됩니까? 기본 VPC에는 CIDR 범위 172.31.0.0/16이 할당됩니다. 기본 VPC 내 기본 서브넷에는 VPC CIDR 범위 내 /20 네트블록이 할당됩니다. Q: VPC 공인 IP 주소 범위를 인터넷에 알리고, 데이터 센터의 트래픽을 AWS Site-to-Site VPN을 통해 내 Amazon VPC로 라우팅할 수 있습니까? 예. AWS Site-to-Site VPN 연결을 통해 트래픽을 라우팅하고, 자신의 홈 네트워크에서 주소 범위를 알릴 수 있습니다. Q: VPC에서 IP 주소를 사용하고 인터넷을 통해 액세스할 수 있나요? 예. 퍼블릭 IPv4 주소와 IPv6 GUA 주소를 AWS VPC로 가져와서 이를 서브넷과 EC2 인스턴스에 정적으로 할당할 수 있습니다. 인터넷을 통해 이러한 주소에 액세스하려면 온프레미스 네트워크에서 인터넷에 이를 알려야 합니다. 또한, AWS DX 또는 AWS VPN 연결을 사용하여 VPC와 온프레미스 네트워크 간에 이러한 주소를 통해 트래픽을 라우팅해야 합니다. 가상 프라이빗 게이트웨이를
사용하여 VPC에서 트래픽을 라우팅할 수 있습니다. 마찬가지로 라우터를 사용하여 온프레미스 네트워크에서 VPC로 다시 트래픽을 라우팅할 수 있습니다. Q: 생성할 수 있는 VPC의 크기는 어느 정도입니까? 현재 Amazon VPC에서는 IPv4에 대해 5개의 IP 주소 범위(기본 1개와 보조 4개)를 지원합니다. 각 범위의 크기는 /28(CIDR 표기법)과 /16 사이가 될 수 있습니다. VPC의 IP 주소 범위는 기존 네트워크의 IP 주소 범위와 겹치지 않아야 합니다. IPv6의 경우 VPC는 고정 크기 /56입니다(CIDR 표기법). VPC에는 IPv4 및 IPv6 CIDR 블록 둘 다 연결될 수 있습니다. Q: VPC 크기를 변경할 수 있습니까? 예. VPC에 4개의 보조 IPv4 IP 범위(CIDR)를 추가하면 기존 VPC를 확장할 수 있습니다. VPC에 추가한 보존 CIDR 블록을 삭제하면
VPC의 크기를 줄일 수 있습니다. 마찬가지로 최대 5개의 추가 IPv6 IP 범위(CIDR)를 VPC에 추가할 수 있습니다. 이 추가 범위를 삭제하여 VPC를 축소할 수 있습니다. Q: VPC당 몇 개의 서브넷을 생성할 수 있습니까? 현재 VPC당 서브넷 200개를 생성할 수 있습니다. 더 생성하려는 경우 지원 센터에 사례를 제출하세요. Q: 서브넷 크기에 제한이 있습니까? IPv4의 경우 서브넷의 최소 크기는 /28(또는 IP 주소 14개)입니다. 서브넷은 생성된 VPC보다 더 클 수 없습니다. IPv6의 경우 서브넷 크기는 /64로 고정됩니다. 서브넷에는 IPv6 CIDR 블록 단 한 개만 할당할 수 있습니다. Q: 서브넷에 할당한 IP 주소를 모두 사용할 수 있습니까? 아니요. Amazon은 IP 네트워킹 목적으로 모든 서브넷의 처음 4개 IP 주소와 마지막 1개 IP 주소를 예약합니다. Q: 프라이빗 IP 주소를 어떻게 VPC 내의 Amazon EC2 인스턴스에 할당하나요? IPv6 전용이 아닌 서브넷 내에서 Amazon EC2 인스턴스를 시작할 때 선택적으로 인스턴스에 대한 기본 프라이빗 IPv4 주소를 지정할 수 있습니다. 기본 프라이빗 IPv4 주소를 지정하지 않으면 AWS는 사용자가 해당 서브넷에 할당한 IPv4 주소 범위에서 자동으로 주소를 지정합니다. 보조 프라이빗 IPv4 주소는 인스턴스를 시작할 때, 탄력적 네트워크 인터페이스를 생성할 때 또는 인스턴스가 시작되거나 인터페이스가 생성된 후 언제든지 할당할 수 있습니다. IPv6 전용 서브넷 내에서 Amazon EC2 인스턴스를 시작하는
경우 AWS는 해당 서브넷의 Amazon 제공 IPv6 GUA CIDR에서 자동으로 주소를 지정합니다. 인스턴스의 IPv6 GUA는 올바른 보안 그룹, NACL 및 라우팅 테이블 구성을 사용하여 인터넷에서 연결할 수 있도록 설정하지 않는 한 프라이빗으로 유지됩니다. Q: Amazon EC2 인스턴스가 VPC에서 실행 및/또는 중단되었을 때, Amazon EC2 인스턴스의 프라이빗 IP 주소를 변경할 수 있나요? IPv4 또는 이중 스택 서브넷에서 시작된 인스턴스의 경우 기본 프라이빗 IPv4 주소는 인스턴스 또는 인터페이스의 수명 동안 유지됩니다. 보조 프라이빗 IPv4 주소는 할당 또는 할당 취소될 수 있고 인터페이스나 인스턴스 간에 언제든지 이전될 수 있습니다. IPv6 전용 서브넷에서 시작된 인스턴스의 경우 인스턴스의 기본 네트워크 인터페이스에서 첫 번째 IP 주소이기도 한 할당된 IPv6 GUA는 언제든지 새 IPv6
GUA를 연결하고 기존 IPv6 GUA를 제거하여 수정할 수 있습니다. Q: VPC 내에서 Amazon EC2 인스턴스가 중단되는 경우 동일 VPC에서 동일한 IP 주소를 가진 다른 인스턴스를 시작할 수 있나요? 실행 중인 인스턴스에 할당된 IPv4 주소의 경우 원래 실행 중이던 인스턴스가 "종료" 상태일 경우에는 다른 인스턴스에서 다시 사용할 수 있습니다. 그러나 실행 중인 인스턴스에 할당된 IPv6 GUA는 첫 번째 인스턴스에서 제거된 후 다른 인스턴스에서 다시 사용할 수 있습니다. Q: 여러 인스턴스에 동시에 IP 주소를 할당할 수 있습니까? 인스턴스를 시작하면 한 번에 하나의 인스턴스의 IP 주소를 지정할 수 있습니다. Q: 인스턴스에 어떤 IP 주소든 할당할 수 있습니까? 다음에 해당하는 경우 어떤 IP 주소든 인스턴스에 할당할 수 있습니다.
Q: 인스턴스에 여러 IP 주소를 할당할 수 있습니까? 예. Amazon VPC에서는 탄력적 네트워크 인터페이스 또는 EC2 인스턴스에 하나 이상의 보조 프라이빗 IP 주소를 할당할 수 있습니다. 할당할 수 있는 보조 프라이빗 IP 주소의 수는 인스턴스 유형에 따라 다릅니다. 인스턴스 유형당 할당할 수 있는 보조 프라이빗 IP 주소 수에 대한 자세한 내용은 EC2 사용 설명서를 참조하세요. Q: VPC 기반 Amazon EC2 인스턴스에 하나 이상의 탄력적 IP(EIP) 주소를 할당할 수 있습니까? 예. 하지만 EIP 주소는 인터넷을 통해서만 연결할 수 있습니다(VPN 연결을 통해서는 안 됨). 각 EIP 주소는 인스턴스의 고유한 프라이빗 IP 주소와 연결되어야 합니다. EIP 주소는 트래픽을 인터넷 게이트웨이로 직접 라우팅하도록 구성된 서브넷의 인스턴스에서만 사용해야 합니다. EIP는 인터넷에 액세스하는데 NAT 게이트웨이 또는 NAT 인스턴스를 사용하도록 구성된 서브넷의 인스턴스에서는 사용할 수 없습니다. 이는 IPv4에만 해당됩니다. Amazon VPC는 현재 IPv6용 EIP를 지원하지 않습니다. 토폴리지Q: 어떤 서브넷이 기본값으로 어떤 게이트웨이를 사용할 것인지를 지정할 수 있습니까? 예. 각각의 서브넷에 대해 기본 경로를 생성할 수 있습니다. 기본 경로는 인터넷 게이트웨이, 가상 프라이빗 게이트웨이 또는 NAT 게이트웨이를 통해 VPC에 송신되도록 트래픽을 보낼 수 있습니다. 보안 및 필터링Q: VPC에서 실행되는 Amazon EC2 인스턴스의 보안을 어떻게 유지합니까? Amazon EC2 보안 그룹을 사용하여 Amazon VPC 내의 인스턴스 보안을 유지할 수 있습니다. VPC 내의 보안 그룹을 통해 각각의 Amazon EC2 인스턴스와의 인바운드 및 아웃바운드 네트워크 트래픽을 지정할 수 있습니다. 인스턴스에서 송신 또는 수신되도록 명시적으로 허용되지 않은 트래픽은 자동으로 거부됩니다. 보안 그룹에 더하여, 각 서브넷에 출입하는 네트워크 트래픽은 네트워크 ACL(액세스 제어 목록)를 통해 허용하거나 거부할 수 있습니다. Q: VPC의 보안 그룹과 VPC의 네트워크 ACL의 차이는 무엇입니까? VPC 내의 보안 그룹은 Amazon EC2 인스턴스 사이에서 어떤 트래픽을 허용할 것인지를 지정합니다. 네트워크 ACL은 서브넷 수준에서 작동하며, 서브넷에 출입하는 트래픽을 평가합니다. 네트워크 ACL을 사용하여 허용 및 거부 규칙을 설정할 수 있습니다. 네트워크 ACL은 동일한 서브넷에 있는 인스턴스 간 트래픽은 필터링하지 않습니다. 또한, 보안 그룹이 상태 저장 필터링을 수행하는 반면 네트워크 ACL은 상태 비저장 필터링을 수행합니다. Q: 상태 저장 필터링과 상태 비저장 필터링의 차이는 무엇입니까? 상태 저장 필터링은 요청의 오리진을 추적하며, 오리진 컴퓨터로 반환하라는 요청에 대한 회신을 자동으로 허용합니다. 예를 들어, 웹 서버에서 TCP 포트 80으로 인바운드 트래픽을 허용하는 상태 저장 필터는 보통 큰 수의 포트(예: 목적지 TCP 포트 63, 912)에서 반환 트래픽이 클라이언트와 웹 서버 간의 상태 저장 필터를 통과하도록 허용합니다. 이 필터링 디바이스는 소스 포트와 목적지 포트 수 및 IP 주소를 추적하는 상태 테이블을 관리합니다. 필터링 디바이스에 적용되는 유일한 규칙은 웹 서버에서 TCP 포트 80에 대한 인바운드 트래픽을 허용한다는 것입니다. 상태 비저장 필터링은 소스 또는 목적지 IP 주소와 목적지 포트만 검사하고, 트래픽이 새로운 요청인지 또는 요청에 대한 응답인지 여부는 무시합니다. 위의 예에서, 두 가지 규칙을 필터링 디바이스에 적용해야 합니다. 하나는 TCP 포트 80에서 웹 서버에 대한 인바운드 트래픽을 허용하는 것이며, 다른 하나는 웹 서버로부터 아웃바운드 트래픽을 허용하는 것입니다(TCP 포트 범위는 49, 65~152, 535). Q: Amazon EC2의 인스턴스를 위해 생성한 SSH 키 패어를 Amazon VPC에서 사용하거나 그 반대의 경우가 가능합니까? 예. Q: VPC에 있는 Amazon EC2 인스턴스가 VPC에 있지 않은 Amazon EC2 인스턴스와 통신할 수 있습니까? 예. 인터넷 게이트웨이가 구성되면, VPC 외부의 Amazon EC2 인스턴스로 향하는 Amazon VPC 트래픽은 인터넷 게이트웨이를 통과한 후, 퍼블릭 AWS 네트워크를 통해 EC2 인스턴스에 전달됩니다. 인터넷 게이트웨이가 구성되어 있지 않거나 인스턴스가 가상 프라이빗 게이트웨이를 통해 라우팅되도록 구성된 서브넷에 있을 경우, 트래픽은 VPN 연결을 통과하고, 데이터 센터를 벗어난 후, 퍼블릭 AWS 네트워크로 재진입하게 됩니다. Q: 특정 리전에 있는 VPC의 Amazon EC2 인스턴스가 다른 리전에 있는 VPC의 Amazon EC2 인스턴스와 통신할 수 있습니까? 예. 한 리전 내 인스턴스들은 리전 간 VPC 피어링, 퍼블릭 IP 주소, NAT 게이트웨이, NAT 인스턴스, VPN 연결 또는 Direct Connect 연결을 사용하여 서로 통신할 수 있습니다. Q: VPC 내의 Amazon EC2 인스턴스가 Amazon S3와 통신할 수 있습니까? 예. 사용자의 리소스가 VPC 내에서 Amazon S3와 통신할 수 있는 여러 옵션이 있습니다. S3용 VPC 엔드포인트를 사용하면 모든 트래픽이 Amazon의 네트워크 내에서 유지되도록 하고, 추가적인 액세스 정책을 Amazon S3 트래픽에 적용할 수 있습니다. 인터넷 게이트웨이를 사용하면 VPC에서 인터넷에 액세스할 수 있으며, VPC의 인스턴스가 Amazon S3와 통신할 수 있습니다. 또한 Amazon S3의 모든 트래픽이 Direct Connect 또는 VPN 연결을 트래버스하고 데이터센터에서 벗어나 퍼블릭 AWS 네트워크로 재진입하도록 할 수 있습니다. Q: VPC의 네트워크 트래픽을 모니터링할 수 있습니까? 예. Amazon VPC 트래픽 미러링 및 Amazon VPC
흐름 로그 기능을 사용하여 Amazon VPC의 네트워크 트래픽을 모니터링할 수 있습니다. Q: Amazon VPC 흐름 로그란 무엇입니까? VPC 흐름 로그는 VPC의 네트워크 인터페이스에서 송수신되는 IP 트래픽에 대한 정보를 캡처할 수 있는 기능입니다. 흐름 로그 데이터는 Amazon CloudWatch Logs 또는 Amazon S3에 게시할 수 있습니다. VPC 흐름 로그를 모니터링하여 네트워크 의존성 및 트래픽 패턴에 대한 운영 가시성을 얻고, 이상을 추적하며 데이터 유출을 예방하거나, 또는 네트워크 연결성 및 구성 문제를 해결할 수 있습니다. 흐름 로그의 강화된 메타데이터는 누가 TCP 연결을 시작했는지, NAT 게이트웨이 등의 중간 계층을 통과하는 트래픽의 실제 패킷 수준 출처 및 대상에 대한 추가적인 인사이트를 얻도록 지원합니다. 흐름 로그를 아카이빙하여 일반적인 규정 준수 요건을 충족할 수 있습니다. Amazon VPC 흐름 로그에 대한 자세한 내용은 설명서를 참조하세요. Q: 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 등의 파트너 솔루션을 사용할 수도 있습니다. Q: VPC 흐름 로그는 AWS Transit Gateway를 지원합니까? 예. Transit Gateway 또는 개별 Transit Gateway Attachment에 대한 VPC 흐름 로그를 생성할 수 있습니다. 이 기능을 사용하면 Transit Gateway에서 Transit Gateway를 통과하는 네트워크 흐름에 대한 소스/대상 IP,
포트, 프로토콜, 트래픽 카운터, 타임스탬프 및 다양한 메타데이터와 같은 자세한 정보를 내보낼 수 있습니다. Transit Gateway에 대한 Amazon VPC 흐름 로그 지원에 대해 자세히 알아보려면 설명서를 참조하세요. Q: 흐름 로그를 사용하면 네트워크 지연 시간이나 성능에 영향을 미칩니까? 흐름 로그 데이터는 네트워크 트래픽 경로 외부에서 수집되므로 네트워크 처리량이나 지연 시간에 영향을 미치지 않습니다. 흐름 로그를 생성하거나 삭제더라도 네트워크 성능에 영향을 미치지 않습니다. Q: VPC 흐름 로그 요금은 어떻게 됩니까 CloudWatch Logs 또는 Amazon S3에 흐름 로그를 게시할 때 Vended
로그에 대한 데이터 수집 및 아카이빙 요금이 적용됩니다. 자세한 내용과 예는 Amazon CloudWatch 요금을 참조하세요. 또한 비용 할당 태그를 사용하여 흐름 로그를 게시하는 데 따른 요금을 추적할 수도 있습니다. Q: Amazon VPC 트래픽 미러링이란 무엇입니까? 고객은 Amazon VPC 트래픽 미러링을 사용하여 콘텐츠 검사, 위협 모니터링, 문제 해결 등의 사용 사례를 위해 Amazon EC2 인스턴스의 네트워크 트래픽을 복제하고 대역 외 보안 및 모니터링 어플라이언스로 전달하는 과정을 손쉽게 처리할 수 있습니다. 이러한 어플라이언스는 개별 EC2 인스턴스 또는 UDP(User Datagram Protocol) 리스너가 있는 NLB(Network Load Balancer) 뒤의 인스턴스 플릿에 배포될 수 있습니다. Q: Amazon VPC 트래픽 미러링은 어떤 식으로 작동합니까? 트래픽 미러링 기능은 Amazon VPC에 있는 EC2 인스턴스의 ENI(탄력적 네트워크 인터페이스)에서 네트워크 트래픽을 복사합니다. 미러링된 트래픽은 다른 EC2 인스턴스나 UDP 리스너가 있는 NLB로 전송할 수 있습니다. 트래픽 미러링은 모든 복사된 트래픽을 VXLAN 헤더로 캡슐화합니다. 미러 원본 및 대상(모니터링 어플라이언스)은 동일한 VPC에 있을 수도 있고, VPC 피어링 또는 AWS Transit Gateway를 통해 연결된 다른 VPC에 있을 수도 있습니다. Q: Amazon VPC 트래픽 미러링을 통해 어떤 리소스를 모니터링할 수 있습니까? 트래픽 미러링은 EC2 인스턴스용 탄력적 네트워크 인터페이스(ENI)에서 네트워크 패킷 캡처를
지원합니다. Amazon VPC 트래픽 미러링을 지원하는 EC2 인스턴스는 트래픽 미러링 설명서를 참조하세요. Q: Amazon VPC 트래픽 미러링에서는 어떤 유형의 어플라이언스가 지원됩니까? 고객은 오픈 소스 도구를 사용할 수도 있고, AWS Marketplace에서 제공되는 광범위한 모니터링 솔루션 중에서 선택할 수도 있습니다. 트래픽 미러링을 사용하는 고객은 공급업체별 에이전트를 설치할 필요 없이 복제된 트래픽을 네트워크 패킷 수집기/브로커 또는 분석 도구로 스트리밍할 수 있습니다. Q: Amazon VPC 트래픽 미러링은 Amazon VPC 흐름 로그와 어떻게 다릅니까? 고객은 Amazon VPC 흐름 로그를 사용하여 네트워크 흐름 로그를 수집, 저장 및 분석할 수 있습니다. 흐름 로그에 캡처되는 정보에는 허용 및 거부되는 트래픽, 원본 및 대상 IP 주소, 포트, 프로토콜 번호, 패킷 및 바이트 수, 작업(수락 또는 거절)에 대한 정보가 포함됩니다. 이 기능을 사용하면 연결 및 보안 문제를 해결할 수 있는 것은 물론, 네트워크 액세스 규칙이 예상대로 작동하도록 할 수 있습니다. Amazon VPC 트래픽 미러링을 사용하면 페이로드 같은 실제 트래픽 콘텐츠를 분석하여 네트워크 트래픽을 좀 더 깊이 있게 파악할 수 있습니다. 이 기능은 실제 패킷을 분석하여 성능 문제의 근본 원인을 파악하거나, 정교한 네트워크 공격을 리버스 엔지니어링하거나, 내부자 침해 또는 손상된 워크로드를 감지 및 차단해야 하는 사용 사례를 위한 것입니다. Amazon VPC 및 EC2Q: Amazon VPC를 사용할 수 있는 Amazon EC2 리전은 어디입니까? Amazon VPC는 현재 모든 Amazon EC2 리전 내 여러 가용 영역에서 사용할 수 있습니다. Q: 한 VPC를 여러 가용 영역으로 확장할 수 있습니까? 예. Q: 한 서브넷을 여러 가용 영역으로 확장할 수 있습니까? 아니요. 한 서브넷은 하나의 가용 영역 내에서만 상주해야 합니다. Q: Amazon EC2 인스턴스를 시작할 가용 영역을 지정하려면 어떻게 해야 합니까? Amazon EC2 인스턴스를 시작할 때 반드시 인스턴스를 시작할 서브넷을 지정해야 합니다. 인스턴스는 지정한 서브넷과 연결된 가용 영역 내에서 시작합니다. Q: 서브넷이 어떤 가용 영역에 위치할 것인지를 어떻게 결정합니까? 서브넷을 생성할 때, 반드시 서브넷을 배치할 가용 영역을 지정해야 합니다. VPC 마법사를 사용할 때, 마법사 구성 화면에서 서브넷 가용 영역을 선택할 수 있습니다. API 또는 CLI를 사용하여, 서브넷을 생성할 때 서브넷에 대한 가용 영역을 지정할 수 있습니다. 가용 영역을 지정하지 않으면 "No Preference" 옵션이 기본적으로 선택되며 리전에서 사용 가능한 가용 영역에 서브넷이 생성됩니다. Q: 서로 다른 서브넷에 있는 인스턴스 간의 네트워크 대역폭에 대한 요금이 청구됩니까? 인스턴스가 다른 가용 영역에 있는 서브넷에 상주할 경우, GB당 0.01 USD의 데이터 전송 요금이 부과됩니다. Q: DescribeInstances()를 호출하면 EC2-Classic과 EC2-VPC에 있는 인스턴스를 비롯하여 모든 Amazon EC2 인스턴스를 볼 수 있습니까? 예. DescribeInstances()는 모든 실행 중인 Amazon EC2 인스턴스를 반환합니다. 서브넷 필드에 있는 항목으로 EC2-VPC 인스턴스와 EC2-Classic 인스턴스를 구별할 수 있습니다. 서브넷 ID의 목록이 있다면, 인스턴스는 VPC 내에 있는 것입니다. Q: DescribeVolumes()를 호출하면 EC2-Classic과 EC2-VPC에 있는 볼륨을 비롯하여 모든 Amazon EBS 볼륨을 볼 수 있습니까? 예. DescribeVolumes()는 모든 EBS 볼륨을 반환합니다. Q: VPC에서 얼마나 많은 Amazon EC2 인스턴스를 사용할 수 있나요? IPv4 주소 지정이 필요한 인스턴스의 경우 VPC 내에서 실행할 수 있는 Amazon EC2 인스턴스 수에 제한이 없습니다. 단, VPC가 각 인스턴스에 할당된 IPv4 주소를 가지도록 적절한 크기로 설정되어야 합니다. 처음에는 한 번에 최대 20개의 Amazon EC2 인스턴스를 시작할 수 있도록 제한되며, VPC의 최대 크기는 /16(65,536 IP)입니다. 이러한 한도를 늘리려면 다음 양식을 작성해 주세요. IPv6 전용 인스턴스의 경우 /56의 VPC 크기는 Amazon EC2 인스턴스를 거의 무제한으로 시작할 수 있는 기능을 제공합니다. Q: Amazon VPC에서 기존 AMI를 사용할 수 있습니까? VPC와 같은 리전 내에 등록된 Amazon VPC의 AMI를 사용할 수 있습니다. 예를 들어, us-east-1에 등록된 AMI를 us-east-1에 있는 VPC와 함께 사용할 수 있습니다. 자세한 내용은 Amazon EC2 리전 및 가용 영역 FAQ에서 확인할 수 있습니다. Q: 기존 Amazon EBS 스냅샷을 사용할 수 있습니까? 예. VPC와 같은 리전에 위치해 있다면 Amazon EBS 스냅샷을 사용할 수 있습니다. 세부 정보는 Amazon EC2 리전 및 가용 영역 FAQ에서 확인할 수 있습니다. Q: Amazon VPC에 있는 Amazon EBS 볼륨에서 Amazon EC2 인스턴스를 부팅할 수 있습니까? 예. 하지만 Amazon EBS-backed AMI를 사용하여 VPC에서 시작한 인스턴스는 중지될 때와 다시 시작할 때 동일한 IP 주소를 유지합니다. VPC 외부에서 시작한 유사한 인스턴스가 새 IP 주소를 얻는 것과는 대조됩니다. 서브넷에서 중지된 인스턴스에 대한 IP 주소는 이용할 수 없는 것으로 간주합니다. Q: Amazon VPC에서 Amazon EC2 예약 인스턴스(RI)를 사용할 수 있습니까? 예. 예약 인스턴스를 구매하면 Amazon VPC 내의 인스턴스를 예약할 수 있습니다. 결제 금액을 계산할 때, AWS는 인스턴스가 Amazon VPC와 표준 Amazon EC2 중 어디에서 실행되는지를 구분하지 않습니다. AWS는 사용자가 가장 적은 비용을 지불하도록 어떤 인스턴스에 더 낮은 예약 인스턴스 요금을 부과할지를 자동으로 최적화합니다. 그러나 인스턴스 예약은 Amazon VPC로 특정됩니다. 더 자세한 내용은 예약 인스턴스 페이지를 참조하시기 바랍니다. Q: Amazon VPC에서 Amazon CloudWatch를 사용할 수 있습니까? 예. Q: Amazon VPC에서 Auto Scaling 기능을 사용할 수 있습니까? 예. Q: VPC에서 Amazon EC2 클러스터 인스턴스를 시작할 수 있습니까? 예. 클러스터 인스턴스는 Amazon VPC에서 지원되지만, 모든 인스턴스 유형을 모든 리전 및 가용 영역에서 사용할 수 있는 것은 아닙니다. Q: 인스턴스 호스트 이름이란 무엇인가요? 인스턴스를 시작하면 호스트 이름이 할당됩니다. IP 기반 이름 또는 리소스 기반 이름의 두 가지 옵션을 사용할 수 있으며 이 파라미터는 인스턴스 시작 시 구성할 수 있습니다. IP 기반 이름은 프라이빗 IPv4 주소 형식을 사용하는 반면 리소스 기반 이름은 instance-id 형식을 사용합니다. Q: Amazon EC2 인스턴스의 인스턴스 호스트 이름을 변경할 수 있나요? 예, 인스턴스를 중지한 다음 리소스 기반 이름 지정 옵션을 변경하여 인스턴스 양식 IP 기반의 호스트 이름을 리소스 기반으로 또는 그 반대로 변경할 수 있습니다. Q: 인스턴스 호스트 이름을 DNS 호스트 이름으로 사용할 수 있나요? 예, 인스턴스 호스트 이름을 DNS 호스트 이름으로 사용할 수 있습니다. IPv4 전용 또는 이중 스택 서브넷에서 시작된 인스턴스의 경우 IP
기반 이름은 항상 인스턴스의 기본 네트워크 인터페이스에서 프라이빗 IPv4 주소로 확인되며 비활성화할 수 없습니다. 또한 리소스 기반 이름은 기본 네트워크 인터페이스의 프라이빗 IPv4 주소나 기본 네트워크 인터페이스의 첫 번째 IPv6 GUA 또는 둘 다로 확인하도록 구성할 수 있습니다. IPv6 전용 서브넷에서 시작된 인스턴스의 경우 리소스 기반 이름은 기본 네트워크 인터페이스의 첫 번째 IPv6 GUA로 확인되도록 구성됩니다. 기본 VPCQ: 기본 VPC란 무엇입니까? 기본 VPC는 AWS 클라우드 내에 있는 논리적으로 격리된 가상 네트워크로서, 처음 Amazon EC2 리소스를 프로비저닝할 때 사용자의 AWS 계정에 자동으로 생성됩니다. 서브넷 ID를 지정하지 않고 인스턴스를 시작하면 인스턴스가 기본 VPC에서 시작됩니다. Q: 기본 VPC의 이점은 무엇입니까? 기본 VPC에서 리소스를 시작할 경우, Amazon VPC(EC2-VPC)의 고급 네트워킹 기능을 활용할 수 있을 뿐만 아니라 Amazon EC2(EC2-Classic)를 편리하게 사용할 수 있습니다. VPC를 별도로 생성하여 VPC에서 인스턴스를 시작하지 않고도 보안 그룹 회원을 즉각적으로 변경하거나 보안 그룹 송신 필터링, 다중 IP 주소 및 다중 네트워크 인터페이스와 같은 기능을 활용할 수 있습니다. Q: 어떤 계정에 기본 VPC가 활성화되어 있습니까? AWS 계정이 2013년 3월 18일 이후에 생성된 경우, 기본 VPC에서 리소스를 시작할 수 있습니다. 어떤 리전에서 기본 VPC 기능 세트를 사용할 수 있는지 확인하려면 이 포럼 공지 사항을 참조하십시오. 또한, 기재된 날짜 이전에 생성된 계정은 EC2 인스턴스를 시작한 적이 없거나 Amazon Elastic Load Balancing, Amazon RDS, Amazon ElastiCache 또는 Amazon Redshift 리소스를 프로비저닝한 적이 없는 리전 중 기본 VPC가 활성된 리전에서 기본 VPC를 사용할 수 있습니다. Q: 계정이 기본 VPC를 사용하도록 구성되어 있는지 어떻게 확인합니까? Amazon EC2 콘솔은 사용자가 선택한 리전에서 인스턴스를 시작할 수 있는 플랫폼을 표시하며 해당 리전에 사용자가 기본 VPC를 갖고 있는지 표시합니다. 탐색 모음에서 사용자가 사용할 리전이 선택되었는지 확인하십시오. Amazon EC2 콘솔 대시보드의 [Account Attributes]에서 [Supported Platforms]를 확인하십시오. EC2-Classic과 EC2-VPC, 두 개의 값이 있을 경우 두 플랫폼에서 인스턴스를 시작할 수 있습니다. EC2-VPC 하나의 값만 있다면 EC2-VPC에서만 인스턴스를 시작할 수 있습니다. 사용자 계정이 기본 VPC를 사용하도록 구성된 경우, 기본 VPC ID가 [Account Attributes] 아래에 표시됩니다. EC2 DescribeAccountAttributes API 또는 CLI를 사용하여 귀사가 지원하는 플랫폼을 설명할 수도 있습니다. Q: 기본 VPC를 사용하기 위해 Amazon VPC에 관해 알아야 할 사항이 있습니까? AWS Management Console, AWS EC2 CLI 또는 Amazon EC2 API를 사용하여 기본 VPC에서 EC2 인스턴스와 기타 AWS 리소스를 시작하고 관리할 수 있습니다. AWS에서 자동으로 기본 VPC를 생성하고 AWS 리전의 각 가용 영역에 기본 서브넷을 생성합니다. 기본 VPC는 인터넷 게이트웨이에 연결되고 사용자의 인스턴스는 EC2-Classic과 마찬가지로 퍼블릭 IP 주소를 자동으로 부여받습니다. Q: EC2-Classic과 EC2-VPC에서 각각 시작한 인스턴스의 차이점은 무엇입니까? EC2 사용 설명서에서 EC2-Classic과 EC2-VPC 차이점 섹션을 참조하십시오. Q: 기본 VPC를 사용하려면 VPN 연결이 필요합니까? 기본 VPC는 인터넷에 연결되어 있으며 기본 VPC 내의 기본 서브넷 에서 시작된 모든 인스턴스는 자동으로 퍼블릭 IP 주소를 받게 됩니다. 원할 경우, 사용자의 기본 VPC에 VPN 연결을 추가할 수 있습니다. Q: 다른 VPC를 생성하여 기본 VPC 외에 추가로 사용할 수 있습니까? 예. 기본이 아닌 VPC에서 인스턴스를 시작하려면 인스턴스 시작 과정 중에서 서브넷 ID를 지정하여야 합니다. Q: 기본 VPC 안에 프라이빗 서브넷과 같은 추가 서브넷을 생성할 수 있습니까? 예. 기본 서브넷이 아닌 다른 서브넷에서 시작하려면, 콘솔을 사용하거나 CLI, API 또는 SDK에서 --subnet 옵션을 사용해 시작할 서브넷을 지정할 수 있습니다. Q: 보유할 수 있는 기본 VPC의 수는 몇 개입니까? Supported Platforms 속성이 “EC2-VPC”로 설정된 각 AWS 리전에서 1개의 기본 VPC를 보유할 수 있습니다. Q: 기본 VPC의 IP 범위는 어떻게 됩니까? 기본 VPC CIDR은 172.31.0.0/16입니다. 기본 서브넷은 기본 VPC CIDR 내에서 /20 CIDR을 사용합니다. Q: 기본 VPC에는 몇 개의 기본 서브넷이 있습니까? 사용자의 기본 VPC에 있는 가용 영역당 하나의 기본 서브넷이 생성됩니다. Q: 기본 VPC로 사용할 VPC를 지정할 수 있습니까? 현재는 지원되지 않습니다. Q: 기본 서브넷으로 사용할 서브넷을 지정할 수 있습니까? 현재는 지원되지 않습니다. Q: 기본 VPC를 삭제할 수 있습니까? 예. 기본 VPC를 삭제할 수 있습니다. 삭제한 후에는 VPC 콘솔에서 바로 또는 CLI를 사용하여 새로운 기본 VPC를 생성할 수 있습니다. 그러면 리전에 새로운 기본 VPC가 생성됩니다. 삭제된 이전 VPC가 복원되지는 않습니다. Q: 기본 서브넷을 삭제할 수 있습니까? 예. 기본 서브넷을 삭제할 수 있습니다. 삭제되고 나면 CLI 또는 SDK를 사용하여 가용 영역에 새로운 기본 서브넷을 생성할 수 있습니다. 그러면 지정된 가용 영역에 새로운 기본 서브넷이 생성되며, 삭제된 이전 서브넷은 복원되지 않습니다. Q: 저는 기존 EC2-Classic 계정을 갖고 있습니다. 기본 VPC를 가질 수 있습니까? 기본 VPC를 보유하는 가장 간단한 방법은 기본 VPC가 활성화된 리전에 새 계정을 생성하거나, 이전에 사용한 적이 없는 리전에 있는 기존 계정을 사용하는 것입니다. 그 리전에 있는 해당 계정의 Supported Platforms 속성이 "EC2-VPC"로 설정된 경우에 한해 가능합니다. Q: 기존 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의 존재 여부를 검토한 후 다음 단계를 안내해 드리겠습니다. Q: 기본 VPC는 IAM 계정에 어떤 영향을 줍니까? 사용자의 AWS 계정에 기본 VPC가 있는 경우 사용자의 AWS 계정에 연결된 IAM 계정은 AWS 계정과 동일한 기본 VPC를 사용합니다. EC2 ClassicQ:
EC2-Classic이란 무엇입니까? EC2-Classic은 2006년 여름에 EC2와 함께 출시한 플랫 네트워크입니다. EC2-Classic을 사용하면 인스턴스가 다른 고객과 공유하는 단일 플랫 네트워크에서 실행됩니다. 시간이 지나면서 고객의 진화하는 요구에서 아이디어를 얻어 사용자의 AWS 계정과 논리적으로 격리된 가상 프라이빗 클라우드에서 인스턴스를 실행할 수 있는 Amazon Virtual Private Cloud(VPC)를 2009년에 출시했습니다. 현재는 대다수 고객들이 Amazon VPC를 사용하며 소수의 고객들만이 EC2-Classic을 사용합니다. Q: 무엇이 변경됩니까? 2022년 8월 15일에 Amazon EC2-Classic을 사용 중지하므로 이 날짜 전까지 EC2-Classic에서 실행 중인 EC2 인스턴스 및 기타 AWS 리소스를 Amazon VPC로 마이그레이션해야 합니다. 다음 섹션에서는
EC2-Class 사용 중지와 마이그레이션을 지원할 도구 및 리소스에 대해 자세히 설명합니다. Q: 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 리소스의 마이그레이션 가이드를 확인할 수 있습니다. Q: EC2-Classic에서 Amazon VPC로 이동하면 어떤 이점이 있습니까? Amazon VPC는 AWS 계정과 논리적으로 격리되어 있어 AWS의 가상 네트워크 환경에 대한 완벽한 제어가 가능합니다. EC2-Classic 환경에서는 워크로드에서 다른 고객과 단일 플랫 네트워크를 공유합니다. Amazon VPC 환경에서는 EC2-Classic 환경과 비교해 자체 IP 주소 공간을 선택할 수 있는 기능, 퍼블릭 및 프라이빗 서브넷 구성, 라우팅 테이블 및 네트워크 게이트웨이 관리 등과 같은 여러 다른 이점을 제공합니다. 현재 EC2-Classic에서 사용할 수 있는 모든 서비스 및 인스턴스에 해당하는 서비스를 Amazon VPC 환경에서 사용할 수 있습니다. 또한 Amazon VPC에서는 EC2-Classic보다 다양한 최신의 인스턴스를 제공합니다. Amazon VPC에 대한 자세한 내용은 이 링크를 참조하십시오. Q: EC2-Classic에서 VPC로 마이그레이션하려면 어떻게 합니까? 리소스 마이그레이션에 도움을 주기 위해 아래에서 찾을 수 있는 플레이북과 빌드 솔루션을 게시했습니다. 마이그레이션하려면 VPC에서 EC2-Classic 리소스를 다시 생성해야 합니다. 먼저 이 스크립트를 사용하여 계정의 모든 리전에서 EC2-Classic에 프로비저닝된 모든 리소스를 식별할 수 있습니다. 그런 다음 아래에서 관련 AWS 리소스의 마이그레이션 가이드를 사용할 수 있습니다.
위의 마이그레이션 가이드와 더불어 애플리케이션 마이그레이션을 간소화, 가속화 및 비용을 절감하는 리프트 앤 시프트(리호스팅) 솔루션인 AWS Application Migration Service(AWS MGN)도 제공합니다. AWS MGN에 대한 관련 리소스는 다음을 참조하십시오.
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을 끄는 것이 좋습니다. Q: 알고 있어야 하는 중요한 날짜는 언제입니까? AWS에서는 2022년 8월 15일 사용 중지 날짜 전에 다음 두 가지 작업을 수행합니다.
탄력적 네트워크 인터페이스Q: 실행 중인 EC2 인스턴스에 하나 이상의 네트워크 인터페이스를 연결하거나 분리할 수 있습니까? 예. Q: EC2 인스턴스에 네트워크 인터페이스를 2개 이상 연결할 수 있습니까? EC2 인스턴스에 연결할 수 있는 네트워크 인터페이스의 총 수는 인스턴스 유형에 따라 다릅니다. 인스턴스 유형당 허용되는 네트워크 인터페이스 수에 대한 자세한 내용은 EC2 사용 설명서를 참조하십시오. Q: 특정 가용 영역에 있는 네트워크 인터페이스를 다른 가용 영역에 있는 인스턴스와 연결할 수 있습니까? 네트워크 인터페이스는 동일한 가용 영역에 상주하는 인스턴스에만 연결할 수 있습니다. Q: 특정 VPC에 있는 네트워크 인터페이스를 다른 VPC에 있는 인스턴스와 연결할 수 있습니까? 네트워크 인터페이스는 동일한 VPC 내에 있는 인스턴스에만 인터페이스로서 연결할 수 있습니다. Q: 단일 인스턴스에서 개별 IP 주소를 필요로 하는 여러 웹사이트를 호스팅하는 방법으로 탄력적 네트워크 인터페이스를 사용할 수 있습니까? 예. 하지만 인터페이스가 여러 개인 경우에는 가장 좋은 방법은 아닙니다. 대신 인스턴스에 프라이빗 IP 주소를 추가로 할당하고 필요에 따라 프라이빗 IP에 EIP를 연결합니다. Q: 네트워크 인터페이스에 연결되어 있으나 네트워크 인터페이스가 실행 중인 인스턴스에 연결되어 있지 않을 때, 탄력적 IP 주소에 대한 요금이 청구됩니까? 예. Q: EC2 인스턴스의 기본 인터페이스(eth0)를 분리할 수 있습니까? EC2 인스턴스에 보조 인터페이스(eth2-ethn)를 연결하고 분리할 수는 있으나, eth0 인터페이스를 분리할 수는 없습니다. 피어링 연결Q: 다른 리전의 VPC에 대한 피어링 연결을 생성할 수 있습니까? 예. 다른 리전에서 VPC를 사용하여 피어링 연결을 생성할 수 있습니다. 리전 간 VPC 피어링은 전 세계 모든 상용 리전(중국 제외)에서 사용할 수 있습니다. Q: 내 VPC를 다른 AWS 계정에 속한 VPC와 피어링할 수 있습니까? 예. 다른 VPC의 소유자가 피어링 연결 요청을 허용한 경우 가능합니다. Q: 일치하는 IP 주소 범위의 두 VPC를 피어링할 수 있습니까? 피어링된 VPC는 IP 범위가 겹치지 않아야 합니다. Q: VPC 피어링 연결 비용은 어떻게 됩니까? VPC 피어링 연결 생성에 대한 비용은 없지만, 피어링 연결을 통한 데이터 전송 비용이 청구됩니다. 데이터 전송 요금은 EC2 요금 페이지의 데이터 전송 섹션을 참조하세요. Q: AWS Direct Connect 또는 하드웨어 VPN 연결을 사용하여 나와 피어링된 VPC에 액세스할 수 있습니까? 아니요. "엣지 투 엣지 라우팅"은 Amazon VPC에서 지원되지 않습니다. 추가 정보는 VPC 피어링 가이드를 참조하세요. Q: 피어링 연결을 사용하려면 인터넷 게이트웨이가 필요합니까? VPC 피어링 연결에는 인터넷 게이트웨이가 필요하지 않습니다. Q: 리전 내 VPC 피어링 트래픽은 암호화됩니까? 피어링된 VPC 내 인스턴스 간 트래픽은 프라이빗 상태를 유지하며 격리됩니다. 이는 동일한 VPC 내 두 인스턴스 간 트래픽이 프라이빗 상태를 유지하며 격리되는 것과 유사합니다. Q: 내 쪽의 피어링 연결을 삭제해도 다른 쪽에서는 계속 내 VPC에 대한 액세스 권한을 보유합니까? 피어링 연결된 양측 모두 언제든지 피어링 연결을 종료할 수 있습니다. 피어링 연결을 종료하면 두 VPC 간 트래픽을 주고받지 않게 됩니다. Q: VPC A를 VPC B에 피어링하고 VPC B를 VPC C에 피어링하는 경우 VPC A와 VPC C도 피어링됩니까? 전이성 피어링 관계는 지원되지 않습니다. Q: 피어링 연결이 중단되면 어떻게 됩니까? AWS는 VPC의 기존 인프라를 사용하여 VPC 피어링 연결을 생성합니다. 이는 게이트웨이도, VPN 연결도 아니며 개별적인 물리적 하드웨어에 의존하지 않습니다. 그러므로 통신 또는 대역폭 병목에 대한 단일 지점 장애가 없습니다. 리전 간 VPC 피어링은 현재 VPC를 지원하는 것과 동일한 수평적으로 확장되고 중복적이며 가용성이 높은 기술에서 운영됩니다. 리전 간 VPC 피어링 트래픽은 내장된 중복성 및 동적 대역폭 할당 기능을 지원하는 AWS 백본으로 이동합니다. 통신에 대한 단일 실패 지점이 없습니다. 리전 간 피어링 연결이 끊어지는 경우 트래픽이 인터넷을 통해 라우팅되지 않습니다. Q: 피어링 연결에 대한 대역폭 제한이 있습니까? 피어링되는 VPC 내 인스턴스 간 대역폭은 동일한 VPC 내 인스턴스 간 대역폭과 같습니다. 참고: 배치 그룹은 피어링된 여러 VPC를 포괄할 수 있지만, 피어링된 VPC의 인스턴스 간에는 양방향 대역폭이 지원되지 않습니다. 배치 그룹에 대한 자세한 내용을 읽어보세요. Q: 리전 간 VPC 피어링 트래픽은 암호화됩니까? 트래픽은 최신 AEAD(Authenticated Encryption with Associated Data) 알고리즘을 사용하여 암호화됩니다. AWS에서 키 계약 및 관리를 처리합니다. Q: DNS 변환은 리전 간 VPC 피어링과 어떻게 연동됩니까? 기본적으로 다른 리전의 피어링된 VPC에서 인스턴스에 대한 퍼블릭 호스트 이름 쿼리는 퍼블릭 IP 주소로 확인됩니다. Route 53 프라이빗 DNS는 리전 간 VPC 피어링을 사용한 프라이빗 IP 주소를 확인하는 데 사용할 수 있습니다. Q: 리전 간 VPC 피어링 연결 사이에서 보안 그룹을 참조할 수 있나요? 리전 간 VPC 피어링 연결 사이에서 보안 그룹을 참조할 수 없습니다. Q: 리전 간 VPC 피어링은 IPv6를 지원합니까? 예. 리전 간 VPC 피어링은 IPv6를 지원합니다. Q: 리전 간 VPC 피어링을 EC2-Classic Link와 함께 사용할 수 있나요? 리전 간 VPC 피어링은 EC2-ClassicLink와 함께 사용할 수 없습니다. ClassicLinkQ: ClassicLink란 무엇입니까? Amazon Virtual Private Cloud(VPC) ClassicLink는 EC2-Classic 플랫폼의 EC2 인스턴스가 프라이빗 IP 주소를 사용해 VPC의 인스턴스와 통신할 수 있도록 지원합니다. ClassicLink를 사용하려면 사용자 계정에서 VPC에 ClassicLink를 활성화한 후 VPC의 보안 그룹과 EC2-Classic의 인스턴스를 연결하십시오. VPC 보안 그룹의 모든 규칙은 EC2-Classic의 인스턴스와 VPC의 인스턴스 간 통신에 적용됩니다. Q: ClassicLink 요금은 어떻게 됩니까? ClassicLink를 사용할 경우 추가 요금이 부과되지 않으며, 기존 가용 영역 간 데이터 전송 요금이 적용됩니다. 자세한 내용은 EC2 요금 페이지를 참조하십시오. Q: ClassicLink를 사용하려면 어떻게 해야 합니까? ClassicLink를 사용하려면 먼저 사용자 계정에 있는 하나 이상의 VPC에서 ClassicLink를 활성화해야 합니다. 그런 다음 VPC의 보안 그룹과 원하는 EC2-Classic 인스턴스를 연결합니다. EC2-Classic 인스턴스가 현재 VPC에 연결되고 VPC에서 선택한 보안 그룹의 멤버가 됩니다. EC2-Classic 인스턴스를 둘 이상의 VPC와 동시에 연결할 수 없습니다. Q: EC2-Classic 인스턴스가 VPC 멤버가 됩니까? EC2-Classic 인스턴스는 VPC 멤버가 되지 않습니다. 해당 인스턴스와 연결된 VPC 보안 그룹의 멤버가 됩니다. VPC 보안 그룹에 대한 참조와 모든 규칙은 EC2-Classic 인스턴스의 인스턴스와 VPC 내 리소스 간 통신에 적용됩니다. Q: 프라이빗 IP를 사용하여 통신하기 위해 내 EC2-Classic과 EC2-VPC 인스턴스 간에 서로 통신하는 데 EC2 퍼블릭 DNS 호스트 이름을 사용할 수 있습니까? 아니요. EC2-Classic 인스턴스에서 쿼리할 때 EC2 퍼블릭 DNS 호스트 이름으로는 EC2-VPC 인스턴스의 프라이빗 IP 주소를 확인할 수 없습니다. 반대의 경우도 마찬가지입니다. Q: ClassicLink를 활성화할 수 없는 VPC가 있습니까? 예. 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를 활성화할 수 없습니다. Q: EC2-Classic 인스턴스의 트래픽이 Amazon VPC를 통과하여 인터넷 게이트웨이, 가상 프라이빗 게이트웨이 또는 피어링된 VPC로 전송될 수 있습니까? EC2-Classic 인스턴스의 트래픽은 VPC 내 프라이빗 IP 주소로만 라우팅될 수 있습니다. 인터넷 게이트웨이, 가상 프라이빗 게이트웨이 또는 피어링된 VPC 대상을 비롯하여 VPC 외부에 있는 대상으로는 라우팅되지 않습니다. Q: ClassicLink가 EC2-Classic 인스턴스와 EC2-Classic 플랫폼에 있는 다른 인스턴스 간의 액세스 제어에 영향을 미칩니까? ClassicLink는 EC2-Classic 플랫폼의 기존 보안 그룹을 통해 EC2-Classic 인스턴스에 대해 정의된 액세스 제어를 변경하지 않습니다. Q: 내 EC2-Classic 인스턴스의 ClassicLink 설정은 중지/시작 주기 동안 지속됩니까? ClassicLink 연결은 EC2-Classic 인스턴스의 중지/시작 주기 동안 지속되지 않습니다. EC2-Classic 인스턴스를 중지하고 시작한 후 다시 VPC에 연결해야 합니다. 그렇지만 인스턴스 재부팅 주기 동안 ClassicLink 연결이 지속됩니다. Q: ClassicLink를 활성화한 후 내 EC2-Classic 인스턴스에 새 프라이빗 IP 주소가 지정됩니까? EC2-Classic 인스턴스에 새 프라이빗 IP 주소가 지정되지 않습니다. EC2-Classic 인스턴스의 ClassicLink를 활성화하는 경우 인스턴스에서 기존 프라이빗 IP 주소를 유지하여 VPC의 리소스와 통신하는 데 사용합니다. Q: ClassicLink를 사용하여 EC2-Classic 보안 그룹 규칙에 VPC 보안 그룹을 참조하거나 그 반대의 경우가 가능합니까? ClassicLink를 사용하여 EC2-Classic 보안 그룹 규칙에 VPC 보안 그룹을 참조할 수 없습니다. 반대의 경우도 같습니다. AWS PrivateLinkQ: AWS PrivateLink란 무엇입니까? AWS PrivateLink는 모든 네트워크 트래픽을 AWS 네트워크 내부에 유지하면서 고객이 높은 가용성과 확장성 방식으로 AWS에 호스팅된 서비스에 액세스할 수 있도록 합니다. 고객은 이 기능을 통해 퍼블릭 IP나 인터넷 연결 트래픽 없이도 자신의 온프레미스 또는 Amazon Virtual Private Cloud(VPC)에서 PrivateLink로 구동되는 서비스에 비공개로 액세스할 수 있습니다. 서비스 소유자는 자신의 Network Load Balancers를 PrivateLink 서비스에 등록하고 다른 AWS 고객에게 서비스를 제공할 수 있습니다. Q: AWS PrivateLink를 사용하려면 어떻게 해야 합니까? 서비스 사용자는 PrivateLink로 구동되는 서비스를 위해 인터페이스 유형 VPC 엔드포인트를 생성해야 합니다. 이러한 서비스 엔드포인트는 VPC 내 프라이빗 IP가 연결된 ENI(Elastic Network Interface)로 표시됩니다. 이러한 엔드포인트가 생성되면, 이 IP로 향하는 모든 트래픽이 비공개로 해당 AWS 서비스로 라우팅됩니다. 서비스 사용자는 서비스 앞단에 Network Load Balancer(NLB)를 설정하여 AWS PrivateLink에 서비스를 탑재할 수 있으며 NLB PrivateLink 서비스를 생성하여 NLB에 등록할 수 있습니다. 고객은 자신의 계정 및 IAM 역할을 허용한 후에 VPC 내에 엔드포인트를 설정하여 서비스에 연결할 수 있습니다. Q: 현재 AWS PrivateLink에서 사용할 수 있는 서비스는 무엇입니까? 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 제품에 대해 더 자세히 알아볼 수 있습니다. Q: AWS Direct Connect를 통해 AWS PrivateLink에서 지원하는 서비스에 비공개로 액세스할 수 있습니까? 예. 온프레미스에 있는 애플리케이션은 AWS Direct Connect를 통해 Amazon VPC에 있는 서비스 엔드포인트에 연결할 수 있습니다. 서비스 엔드포인트에서는 자동으로 AWS PrivateLink에서 지원하는 AWS 서비스로 트래픽을 보냅니다. Q: 인터페이스 기반의 VPC 엔드포인트에 대해 사용할 수 있는 CloudWatch 지표는 무엇입니까? 현재 인터페이스 기반의 VPC 엔드포인트에 대해 사용할 수 있는 CloudWatch 지표는 없습니다. Q: 인터페이스 기반의 VPC 엔드포인트를 통해 전송되는 트래픽에 대한 데이터 전송 비용은 누가 지불합니까? 데이터 전송 비용의 개념은 EC2 인스턴스에 대한 데이터 전송 비용 개념과 비슷합니다. 인터페이스 기반 VPC 엔드포인트는 서브넷의 ENI이므로 데이터 전송 요금은 트래픽 소스에 따라 달라집니다. 이 인터페이스로 가는 트래픽이 AZ 전역의 리소스에서 발생한 경우 EC2 교차 AZ 데이터 전송 요금이 소비자 측에 적용됩니다. 소비자 VPC의 고객은 자신의 계정에서 사용 가능한 각 AZ를 프로비저닝한 경우 트래픽이 동일한 AZ 내에 머무르도록 하기 위해 AZ 특정 DNS 엔드포인트를 사용할 수 있습니다. Bring Your Own IPQ: Bring Your Own IP 기능은 무엇입니까? 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 또는 둘 모두를 사용할 수 있습니다. Q: 왜 BYOIP를 사용해야 합니까? 다음과 같은 이유로 자체 보유한 IP 주소를 AWS에 가져올 수 있습니다. 고객 화이트리스트: BYOIP를 사용하는 고객은 IP 주소 화이트리스트에 의존하는 워크로드를 새 IP 주소를 포함하는 화이트리스트의 재설정 없이 그대로 AWS로 옮길 수 있습니다. 하드 코딩된 종속성: 여러 고객이 IP를 디바이스에 하드 코딩하거나 IP에 대한 아키텍처 종속성을 가집니다. BYOIP를 사용하면 이러한 고객이 AWS로 자유롭게 마이그레이션할 수 있습니다. 규정 및 준수: 많은 고객은 규정 및 준수 이유로 인해 특정 IP를 사용해야 합니다. 이러한 IP도 BYOIP를 통해 자유롭게 사용할 수 있습니다. 온프레미스 IPv6 네트워크 정책: 많은 고객은 자체 온프레미스 네트워크에서 자신의 IPv6만 라우팅할 수 있습니다. 이런 고객은 VPC에 자체 IPv6 범위를 할당함에 따라 BYOIP를 통해 자유롭게 사용하고 인터넷 또는 직접 연결을 사용해 온프레미스 네트워크에 라우팅하도록 선택할 수 있습니다. Q: BYOIP 접두사의 IP를 어떻게 AWS 리소스에 사용할 수 있습니까? BYOIP 접두사는 계정에서 IP 풀로 표시됩니다. IPv4 풀에서 탄력적 IP(EIP)를 생성하고 EIP를 지원하는 AWS 리소스를 통해 일반 EIP처럼 사용할 수 있습니다. 현재 EC2 인스턴스, NAT 게이트웨이 및 Network Load Balancer가 EIP를 지원합니다. VPC에 IPv6 풀에서 CIDR을 연결할 수 있습니다. BYOIP를 통해 가져온 IPv6 주소는 Amazon에서 제공하는 IPv6 주소와 정확히 일치합니다. 예를 들어 이 IPv6 주소를 VPC 내의 서브넷, Elastic Network Interfaces(ENI) 및 EC2 인스턴스와 연결할 수 있습니다. Q: BYOIP 탄력적 IP를 해제하면 어떻게 됩니까? BYOIP 탄력적 IP를 해제하면 할당된 BYOIP IP 풀로 돌아갑니다. Q: 어느 AWS 리전에서 BYOIP를 사용할 수 있습니까? 이 기능은 현재 아프리카(케이프타운), 아시아 태평양(홍콩), 아시아 태평양(뭄바이), 아시아 태평양(시드니), 아시아 태평양(도쿄), 아시아 태평양(서울), 아시아 태평양(싱가포르), 캐나다(중부), EU(더블린), EU(프랑크푸르트), EU(런던), EU(밀라노), EU(파리), EU(스톡홀름), 중동(바레인), 남아메리카(상파울루), 미국 서부(캘리포니아 북부), 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오레곤), AWS GovCloud(미국 서부), AWS GovCloud(미국 동부) 리전에서 사용할 수 있습니다. Q: 동일한 계정에서 BYOIP 접두사를 여러 VPC와 공유할 수 있습니까? 예. 동일한 계정에서 BYOIP 접두사를 여러 VPC와 함께 사용할 수 있습니다. Q: BYOIP를 통해 얼마나 많은 IP 범위를 가져올 수 있습니까? 계정에 최대 5개의 IP 범위를 가져올 수 있습니다. Q: BYOIP를 통해 가져올 수 있는 가장 구체적인 접두사는 무엇입니까? BYOIP를 통해 가져올 수 있는 가장 구체적인 IPv4 접두사는 /24 IPv4 접두사와 /56 IPv6 접두사입니다. IPv6 접두사를 인터넷에 알리려는 경우 가장 구체적인 IPv6 접두사는 /48입니다. Q: BYOIP에 사용할 수 있는 RIR 접두사는 무엇입니까? ARIN, RIPE 및 APNIC 등록 접두사를 사용할 수 있습니다. Q: 재지정되거나 재할당된 접두사를 가져올 수 있습니까? 현재 재지정되거나 재할당된 접두사는 허용되지 않습니다. IP 범위는 직접 할당 또는 직접 지정의 순 유형이어야 합니다. Q: BYOIP 접두사를 AWS 리전 간에 이동할 수 있습니까? 예. 현재 리전에서 BYOIP 접두사의 프로비저닝을 해제한 다음 새 리전에 프로비저닝하면 됩니다. 추가 질문Q: AWS Management Console을 사용하여 Amazon VPC를 제어하고 관리할 수 있습니까? 예. AWS Management Console을 사용하여 VPC, 서브넷, 라우팅 테이블, 인터넷 게이트웨이, IPSec VPN 연결 등의 Amazon VPC 객체를 관리할 수 있습니다. 또한 간편한 마법사를 사용하여 VPC를 생성할 수도 있습니다. Q: 얼마나 많은 VPC, 서브넷, Elastic IP 주소 및 인터넷 게이트웨이를 생성할 수 있습니까? 다음 수만큼 생성할 수 있습니다.
VPC 한도에 대한 자세한 내용은 Amazon VPC 사용 설명서를 참조하십시오. Q: Amazon VPC에 대한 AWS Support를 받을 수 있습니까? 예. AWS Support에 대한 자세한 정보는 여기를 클릭하십시오. Q: Amazon VPC에서 ElasticFox를 사용할 수 있습니까? ElasticFox는 공식적으로 더 이상 Amazon VPC를 관리하는 데 지원되지 않습니다. Amazon VPC 지원은 AWS API, 명령줄 도구, AWS Management Console 및 그 외 다양한 타사 유틸리티를 통해 사용할 수 있습니다. 시작할 준비가 되셨습니까? 가입 추가 질문이 있으십니까? 문의하기 |
하나 이상의 웹서버를 가질 수 있나요
저작권 © 2024 ihoctot Inc.
