한 회사에서 단일 Route 53 퍼블릭 호스팅 영역을 사용하여 도메인에 대한 인터넷 애플리케이션을 제공하고 있습니다. 3계층 애플리케이션이 재개발 중이며, 프런트엔드 EC2 인스턴스는 Elastic IP가 있는 퍼블릭 서브넷에 있고 백엔드 구성 요소는 프라이빗 RFC1918 서브넷에 있습니다. 애플리케이션 구성 요소는 퍼블릭 인터넷에서 사용되는 것과 동일한 호스트 이름을 사용하여 VPC 내에서 서로를 확인하고 도달할 수 있어야 합니다. 엔지니어는 향후 DNS 변경(새 이름 또는 사용 중단된 항목)도 허용해야 합니다. 이러한 요구 사항을 충족하는 작업 조합은 무엇입니까? (3개 선택)

이 솔루션은 VPC 내에서 애플리케이션 구성 요소가 퍼블릭 인터넷에서 사용되는 것과 동일한 호스트 이름을 사용하여 서로를 확인하고 도달할 수 있도록 합니다. 1. 동일한 도메인 이름에 대한 Route 53 프라이빗 호스팅 영역을 생성하고 애플리케이션의 VPC를 새 프라이빗 호스팅 영역과 연결합니다. 이렇게 하면 VPC 내에서 내부 DNS 확인이 가능해집니다. 2. 애플리케이션의 VPC에 대해 DNS 호스트 이름을 활성화합니다. 이는 VPC 내에서 DNS 확인이 작동하는 데 필요합니다. 3. 해당 프라이빗 IP 주소를 사용하여 퍼블릭 호스팅 영역의 각 이름에 대한 항목을 프라이빗 호스팅 영역에 생성합니다. 이렇게 하면 내부적으로 동일한 호스트 이름을 사용하여 프라이빗 IP 주소로 확인됩니다. 지리 근접 라우팅 정책은 외부 트래픽 라우팅에 사용되며 내부 DNS 확인에는 관련이 없습니다. 기존 퍼블릭 호스팅 영역에 프라이빗 IP 주소를 추가하는 것은 외부 사용자가 프라이빗 IP 주소로 확인하게 되어 보안 위험을 초래하고 내부 확인 문제를 해결하지 못합니다. CloudTrail 및 EventBridge를 사용한 자동화는 DNS 변경 관리를 위한 고급 솔루션이지만, 직접적인 DNS 확인 문제를 해결하는 데 필수적인 단계는 아닙니다.