VPC프라이빗 엔드포인트에 대한 중앙 집중식 액세스

VPC엔드포인트를 사용하면 인터넷 게이트웨이나 NAT 장치, 연결 또는 VPN 연결 없이 지원되는 AWS 서비스에 비공개로 연결할 수 있습니다. VPC AWS Direct Connect 따라서 공용 인터넷에 VPC 노출되지 않습니다. 의 인스턴스는 이 인터페이스 엔드포인트를 사용하여 AWS 서비스 엔드포인트와 통신하는 데 퍼블릭 IP 주소가 VPC 필요하지 않습니다. 사용자 VPC 서비스와 다른 서비스 간의 트래픽은 AWS 네트워크 백본을 벗어나지 않습니다. VPC엔드포인트는 가상 디바이스입니다. 수평적으로 확장되고 중복되며 가용성이 높은 구성 요소입니다. VPC 현재 두 가지 유형의 엔드포인트, 즉 인터페이스 엔드포인트 (전원 공급) 와 게이트웨이 엔드포인트를 프로비저닝할 수 있습니다. AWS PrivateLink 게이트웨이 엔드포인트를 사용하여 Amazon S3 및 Amazon DynamoDB 서비스에 비공개로 액세스할 수 있습니다. 게이트웨이 엔드포인트 사용에 따르는 추가 요금은 없습니다. 데이터 전송 및 리소스 사용량에 대한 표준 요금이 그대로 적용됩니다.

인터페이스 VPC 엔드포인트

인터페이스 엔드포인트는 지원되는 서비스로 향하는 트래픽의 진입점 역할을 하는 사설 IP 주소를 가진 하나 이상의 엘라스틱 네트워크 인터페이스로 구성됩니다. AWS 인터페이스 엔드포인트를 프로비저닝하면 데이터 처리 요금과 함께 엔드포인트를 실행하는 시간당 비용이 발생합니다. 기본적으로 서비스에 VPC 액세스하려는 모든 위치에 인터페이스 엔드포인트를 생성합니다. AWS 이는 고객이 여러 곳에 걸쳐 특정 AWS 서비스와 상호 작용하기를 원하는 랜딩 존 설정에서는 비용이 많이 들고 관리하기 어려울 수 있습니다. VPCs 이를 방지하기 위해 인터페이스 엔드포인트를 중앙 집중식으로 호스팅할 수 있습니다. VPC 모든 스포크는 VPCs Transit Gateway를 통해 이러한 중앙 집중식 엔드포인트를 사용합니다.

AWS 서비스에 VPC 엔드포인트를 생성할 때 DNS 비공개를 활성화할 수 있습니다. 이 설정을 활성화하면 AWS 관리형 Route 53 프라이빗 호스팅 영역 (PHZ) 이 생성되며, 이를 통해 공용 AWS 서비스 엔드포인트를 인터페이스 엔드포인트의 프라이빗 IP로 확인할 수 있습니다. 관리형은 인터페이스 엔드포인트가 VPC 있는 PHZ 내에서만 작동합니다. 설정에서 스포크가 VPCs 중앙 VPC 집중식으로 DNS 호스팅된 VPC 엔드포인트를 해결할 수 있도록 하려는 경우 관리형 엔드포인트는 PHZ 작동하지 않습니다. 이 문제를 해결하려면 인터페이스 엔드포인트가 DNS 생성될 때 자동으로 프라이빗을 생성하는 옵션을 비활성화하세요. 다음으로, 서비스 엔드포인트 이름과 일치하는 Route 53 프라이빗 호스팅 영역을 수동으로 생성하고 인터페이스 엔드포인트를 가리키는 전체 AWS 서비스 엔드포인트 이름이 포함된 Alias 레코드를 추가합니다.

1. AWS Management Console 로그인하고 Route 53으로 이동합니다.

2. 프라이빗 호스팅 영역을 선택하고 레코드 생성으로 이동합니다.

3. 레코드 이름 필드를 채우고 레코드 유형을 A로 선택한 다음 별칭을 활성화합니다.

   참고로 Docker 및 OCI 클라이언트 엔드포인트 (dkr.ecr) 와 같은 일부 서비스에서는 레코드 이름에 와일드카드 별칭 (*) 을 사용해야 합니다.

4. Route Traffic to 섹션에서 트래픽을 전송할 서비스를 선택하고 드롭다운 목록에서 지역을 선택합니다.

5. 적절한 라우팅 정책을 선택하고 대상 상태 평가 옵션을 활성화합니다.

이 프라이빗 호스팅 영역을 랜딩 존 VPCs 내의 다른 영역과 연결합니다. 이 구성을 통해 스포크는 중앙 VPCs 집중식 인터페이스 엔드포인트에 대한 풀 서비스 엔드포인트 이름을 확인할 수 있습니다. VPC

참고

공유 프라이빗 호스팅 영역에 액세스하려면 스포크의 호스트가 해당 호스트의 Route 53 Resolver IP를 VPCs 사용해야 합니다. VPC 인터페이스 엔드포인트는 Direct Connect를 통해 온프레미스 네트워크에서도 액세스할 수 VPN 있습니다. 조건부 전달 규칙을 사용하여 전체 서비스 엔드포인트 이름에 대한 모든 DNS 트래픽을 Route 53 Resolver 인바운드 엔드포인트로 전송하면, Route 53 Resolver 인바운드 엔드포인트는 프라이빗 호스팅 영역에 따라 요청을 해결합니다DNS.

다음 그림에서 Transit Gateway는 VPCs 스포크에서 중앙 집중식 인터페이스 엔드포인트로의 트래픽 흐름을 가능하게 합니다. 네트워크 서비스 계정에서 VPC 엔드포인트와 이에 대한 프라이빗 호스팅 영역을 생성하고 이를 스포크 계정의 VPCs 스포크와 공유하십시오. 엔드포인트 정보를 다른 VPCs 사람과 공유하는 방법에 대한 자세한 내용은 AWSTransit AWS PrivateLink Gateway와 Amazon Route 53 Resolver 통합 블로그 게시물을 참조하십시오.

참고

분산 VPC 엔드포인트 접근 방식, 즉 엔드포인트를 VPC 사용하면 엔드포인트에 최소 권한 정책을 적용할 수 있습니다. VPC 중앙 집중식 접근 방식에서는 단일 엔드포인트에서 모든 스포크 VPC 액세스에 대한 정책을 적용하고 관리합니다. 정책 문서 수가 VPCs 늘어남에 따라 단일 정책 문서로 최소 권한을 유지하는 것이 복잡해질 수 있습니다. 또한 단일 정책 문서로 인해 폭발 반경이 더 커집니다. 또한 정책 문서의 크기 (20,480자) 도 제한됩니다.

인터페이스 엔드포인트 중앙 집중화 VPC

지역 간 엔드포인트 액세스

공통 VPC 엔드포인트를 공유하는 여러 지역에 여러 VPCs 설정을 하려면 앞서 설명한 대로 a를 PHZ 사용하십시오. 각 리전의 두 VPCs 리전은 엔드포인트의 PHZ 별칭과 함께 연결됩니다. 다중 지역 아키텍처 간에 VPCs 트래픽을 라우팅하려면 각 지역의 Transit Gateway를 함께 피어링해야 합니다. 자세한 내용은 다음 블로그를 참조하십시오. 교차 계정 다중 지역 아키텍처를 위한 Route 53 프라이빗 호스팅 영역 사용.

VPCs트랜짓 게이트웨이 또는 피어링을 사용하여 서로 다른 지역의 데이터를 서로 라우팅할 수 있습니다. VPC 트랜짓 게이트웨이 피어링에 대해서는 다음 설명서를 사용하십시오. 트랜짓 게이트웨이 피어링 첨부 파일.

이 예제에서 VPC us-west-1 지역의 Amazon EC2 인스턴스는 를 사용하여 지역 내 엔드포인트의 프라이빗 IP 주소를 가져오고 Transit Gateway 피어링 또는 VPC 피어링을 VPC 통해 트래픽을 us-west-2 지역으로 라우팅합니다. PHZ us-west-2 이 아키텍처를 사용하면 트래픽이 AWS 네트워크 내에 남아 있어 인터넷을 us-west-2 거치지 않고도 EC2 인스턴스가 VPC 서비스에 안전하게 액세스할 수 있습니다. us-west-1

VPC멀티 리전 엔드포인트

참고

지역 간 엔드포인트에 액세스할 때는 지역 간 데이터 전송 요금이 적용됩니다.

이전 그림을 참조하면 해당 VPC 지역의 a에 엔드포인트 서비스가 생성됩니다. us-west-2 이 엔드포인트 서비스는 해당 지역의 AWS 서비스에 대한 액세스를 제공합니다. 다른 지역 (예:us-east-1) 의 인스턴스가 해당 us-west-2 지역의 엔드포인트에 액세스하려면 원하는 VPC 엔드포인트의 별칭을 PHZ 사용하여 에서 주소 레코드를 생성해야 합니다.

먼저, 각 VPCs 지역의 가 생성한 PHZ 것과 연결되어 있는지 확인하십시오.

여러 가용 영역에 엔드포인트를 배포할 때 반환되는 엔드포인트의 IP 주소는 할당된 가용 영역의 모든 서브넷에서 가져온 DNS 것입니다.

엔드포인트를 호출할 때는 에 있는 정규화된 도메인 이름 (FQDN) 을 사용하십시오. PHZ

AWS Verified Access

AWS Verified Access 네트워크 없이도 사설망의 애플리케이션에 안전하게 액세스할 수 VPN 있습니다. ID, 장치 및 위치와 같은 요청을 실시간으로 평가합니다. 이 서비스는 애플리케이션 정책에 따라 액세스 권한을 부여하고 조직의 보안을 개선하여 사용자를 연결합니다. Verified Access는 ID를 인식하는 역방향 프록시 역할을 하여 개인 애플리케이션에 대한 액세스를 제공합니다. 해당하는 경우 사용자 ID 및 장치 상태는 트래픽을 애플리케이션으로 라우팅하기 전에 수행됩니다.

다음은 Verified·Access의 중요한 개요를 설명하는 다이어그램입니다. 사용자가 애플리케이션 액세스 요청을 보냅니다. Verified·Access는 그룹에 대한 액세스 정책 및 애플리케이션별 엔드포인트 정책을 기준으로 요청을 평가합니다. 액세스가 허용되면 해당 요청이 엔드포인트를 통해 애플리케이션에 전송됩니다.

검증된 액세스 개요

AWS Verified Access 아키텍처의 주요 구성 요소는 다음과 같습니다.

• Verified·Access 인스턴스 – 인스턴스는 애플리케이션 요청을 평가하여 보안 요구 사항이 충족되는 경우에만 액세스를 부여합니다.

• Verified·Access 엔드포인트 - 각 엔드포인트는 애플리케이션을 나타냅니다. 엔드포인트는 ALB 또는 네트워크 인터페이스일 NLB 수 있습니다.

• Verified·Access 그룹 – Verified·Access 엔드포인트의 모음입니다. 정책 관리를 단순화하려면 보안 요구 사항이 비슷한 애플리케이션의 엔드포인트를 그룹화하는 것이 좋습니다.

• 액세스 정책 - 애플리케이션에 대한 액세스를 허용할지 거부할지를 결정하는 사용자 정의 규칙 집합입니다.

• 신뢰 제공자 — Verified Access는 사용자 ID 및 장치 보안 상태를 쉽게 관리할 수 있는 서비스입니다. 타사 신뢰 제공자 AWS 모두와 호환되므로 각 Verified Access 인스턴스에 하나 이상의 신뢰 공급자를 연결해야 합니다. 이러한 각 인스턴스에는 단일 ID 신뢰 공급자뿐만 아니라 여러 장치 신뢰 공급자가 포함될 수 있습니다.

• 신뢰 데이터 — 응용 프로그램 요청이 수신될 때마다 신뢰 제공자가 Verified Access에 보내는 보안 데이터 (예: 사용자의 이메일 주소 또는 사용자가 속한 그룹) 를 액세스 정책에 따라 평가합니다.

자세한 내용은 Verified Access 블로그 게시물에서 확인할 수 있습니다.