여러 VPC에서 AWS VPC Endpoint 공유하기: 중앙 집중식 아키텍처 및 구성 가이드

AWS에서 "서로 다른 VPC 간에 VPC 엔드포인트를 공유하는 것"의 핵심은 단순히 엔드포인트를 여러 VPC에 직접 연결하는 것이 아니라 다음과 같은 방식입니다.

인터페이스 VPC 엔드포인트를 단일 중앙/공유 서비스 VPC에 집중시키고, 다른 VPC에서 트랜짓 게이트웨이 또는 VPC 피어링을 통해 이 엔드포인트의 프라이빗 IP에 액세스할 수 있도록 허용하는 동시에 Route 53을 사용하여 DNS를 통합합니다.

AWS는 이 모델을 공식적으로 다음과 같이 부릅니다... Centralized access to VPC private endpoints。

하지만 우선, 둘을 구분하는 것이 중요합니다. Interface Endpoint 그리고 Gateway Endpoint。

먼저 가장 중요한 결론부터 말씀드리겠습니다.

현재 다음과 같은 상황을 가지고 있다고 가정해 보겠습니다.

VPC-A
VPC-B
VPC-C

세 개의 VPC 모두에 필요한 사항:

SSM
EC2 API
ECR
CloudWatch
KMS
Secrets Manager
STS
...

두 가지 디자인이 있습니다.

옵션 A: 각 VPC는 자체 엔드포인트를 생성합니다.

VPC-A
 ├─ SSM Endpoint
 ├─ EC2 Endpoint
 ├─ ECR Endpoint
 ├─ Logs Endpoint
 └─ KMS Endpoint

VPC-B
 ├─ SSM Endpoint
 ├─ EC2 Endpoint
 ├─ ECR Endpoint
 ├─ Logs Endpoint
 └─ KMS Endpoint

VPC-C
 ├─ SSM Endpoint
 ├─ EC2 Endpoint
 ├─ ECR Endpoint
 ├─ Logs Endpoint
 └─ KMS Endpoint

이것은 가장 단순하고 독립적인 설계입니다.

하지만 엔드포인트 수는 빠르게 증가할 것입니다.

예를 들어:

VPC 10개 × AWS 서비스 엔드포인트 20개 × 가용 영역 2개 = 엔드포인트 ENI 400개

인터페이스 엔드포인트는 다음을 기반으로 합니다. 엔드포인트 × AZ × 시간이용료 외에 데이터 처리 수수료가 추가됩니다.

따라서 규모가 커질수록 비용과 유지 관리 부담이 크게 증가합니다.

II. 중앙 집중식 VPC 엔드포인트 아키텍처

다음과 같이 설정하십시오:

Network VPC / Shared Services VPC

모든 엔드포인트가 여기에 배치됩니다.

예를 들어:

                  AWS Services
                       │
                PrivateLink
                       │
             ┌───────────────────┐
             │  Network VPC      │
             │  10.0.0.0/16      │
             │                   │
             │ SSM Endpoint      │
             │ KMS Endpoint      │
             │ ECR Endpoint      │
             │ Logs Endpoint     │
             │ STS Endpoint      │
             │ Secrets Endpoint  │
             └─────────┬─────────┘
                       │
                Transit Gateway
             ┌─────────┼─────────┐
             │         │         │
             │         │         │
          VPC-A      VPC-B      VPC-C
       10.10/16   10.20/16   10.30/16

그 다음에:

VPC-A의 EC2 ↓ ssm.ap-northeast-1.amazonaws.com ↓ Route 53 ↓ 공유 VPC 내 SSM 엔드포인트의 프라이빗 IP로 확인됨 ↓ 트랜짓 게이트웨이 ↓ 인터페이스 엔드포인트 ENI ↓ AWS PrivateLink ↓ SSM

AWS는 이러한 중앙 집중식 설계를 공식적으로 지원합니다.

III. 특히 중요한 예외 사항: S3/DynamoDB

이 문제는 별도로 논의해야 합니다.

게이트웨이 엔드포인트는 이러한 방식으로 공유할 수 없습니다.

S3와 DynamoDB는 다음과 같은 특징이 있습니다.

Gateway VPC Endpoint

예를 들어:

com.amazonaws.ap-northeast-1.s3
com.amazonaws.ap-northeast-1.dynamodb

이는 일반적인 인터페이스 엔드포인트와는 완전히 다릅니다.

Gateway Endpoint：

PrivateLink를 사용하지 마세요.
ENI를 생성하지 마십시오.
기본적으로 라우팅 테이블과 AWS 관리형 접두사 목록의 조합입니다.
무료
해당 VPC 내에서만 사용할 수 있습니다.

AWS는 공식적으로 다음과 같이 밝혔습니다.

게이트웨이 엔드포인트는 VPC 범위를 벗어날 수 없습니다. VPC 피어링, 트랜짓 게이트웨이, VPN 또는 다이렉트 커넥트의 다른 쪽 끝에 있는 리소스는 이 게이트웨이 엔드포인트의 리소스를 사용할 수 없습니다.

따라서 다음과 같이 설계해서는 안 됩니다.

VPC-A ──TGW── Shared VPC ── S3 Gateway Endpoint

다음으로 VPC-A가 공유 VPC의 S3 게이트웨이 엔드포인트를 사용하도록 설정하려고 합니다.

아니요.

IV. S3/DynamoDB 사용을 위한 올바른 방법

일반적으로는 다음과 같아야 합니다.

VPC-A → 사용자 지정 S3 게이트웨이 엔드포인트 VPC-B → 사용자 지정 S3 게이트웨이 엔드포인트 VPC-C → 사용자 지정 S3 게이트웨이 엔드포인트

왜냐하면:

게이트웨이 엔드포인트에는 추가 요금이 부과되지 않습니다.

따라서 "엔드포인트 수를 줄이기 위해" S3 게이트웨이 엔드포인트를 중앙 집중화할 필요는 없습니다.

추천하다:

                  S3
             ↑     ↑     ↑
             │     │     │
           GW EP  GW EP  GW EP
             │     │     │
           VPC-A VPC-B VPC-C

그리고:

SSM
KMS
STS
ECR
ECR Docker
CloudWatch
CloudWatch Logs
Secrets Manager
SNS
SQS
etc.

이것들 Interface VPC Endpoint 그것이 바로 중앙집권화가 적합한 이유입니다.

5. 인터페이스 엔드포인트를 VPC 간에 사용할 수 있는 이유는 무엇입니까?

인터페이스 엔드포인트는 본질적으로 다음과 같기 때문입니다.

지정된 서브넷에 개인 IP 주소를 가진 ENI를 생성하십시오.

AWS 공식 문서에 따르면 인터페이스 엔드포인트는 사용자가 선택한 서브넷에 엔드포인트 네트워크 인터페이스를 생성하고 해당 서브넷에 프라이빗 IP 주소를 할당합니다.

예를 들어:

Shared VPC
10.0.0.0/16

AZ-a:
Endpoint ENI
10.0.10.50

AZ-c:
Endpoint ENI
10.0.20.60

다른 VPC의 경우, 다음 조건이 충족되는 한:

VPC-A → 10.0.10.50으로 라우팅 가능

그리고:

보안 그룹 10.0.10.50은 VPC-A를 허용합니다.

실제로 네트워크는 이미 엔드포인트에 접근할 수 있습니다.

그러므로 소위:

공유 VPC 엔드포인트

실제로 일어난 일은 다음과 같습니다.

다른 VPC ↓ 크로스 VPC 네트워크 ↓ 중앙 VPC 엔드포인트 ENI 액세스

아니요:

vpce-xxx는 최대 세 개의 VPC에 동시에 연결할 수 있습니다.

이 두 가지는 완전히 다른 개념입니다.

VI. 세 가지 실질적인 구현 방법

실제로는 세 가지 유형으로 나눌 수 있습니다.

방법	추천 수준	적합한
Transit Gateway	⭐⭐⭐⭐⭐	대규모 멀티 VPC
VPC Peering	⭐⭐⭐⭐	2~5개의 VPC
엔드포인트 DNS를 직접 사용하세요	⭐⭐⭐	테스트/특수 응용 프로그램
VPC별 독립 엔드포인트	⭐⭐⭐⭐⭐	격리 및 소규모 운영을 우선시하십시오.

VII. 방법 1: 트랜짓 게이트웨이 + 중앙 엔드포인트

이는 기업 환경에서 가장 일반적인 해결책입니다.

도쿄 지역을 가정할 때:

ap-northeast-1

회로망:

Network VPC
10.0.0.0/16

App VPC-A
10.10.0.0/16

App VPC-B
10.20.0.0/16

App VPC-C
10.30.0.0/16

건축학:

                       AWS SSM
                          ▲
                          │
                     PrivateLink
                          │
                 SSM Interface EP
                 10.0.10.50
                 10.0.20.50
                          │
                ┌─────────────────┐
                │   Network VPC   │
                │   10.0.0.0/16   │
                └────────┬────────┘
                         │
                       TGW
              ┌──────────┼──────────┐
              │          │          │
            VPC-A      VPC-B      VPC-C
          10.10/16   10.20/16   10.30/16

AWS에서 설계한 Transit Gateway(TGW)는 여러 VPC 간의 중앙 라우팅을 지원하며 임시 라우팅도 지원합니다. 또한 AWS는 대규모 멀티 VPC 네트워크에서 TGW를 우선 순위로 설정하는 것을 권장합니다.

VIII. 구체적인 운영 절차

다음은 실제 구성에 대한 분석입니다.

1단계: 네트워크 VPC 생성

예를 들어:

VPC:
shared-endpoint-vpc

CIDR:
10.0.0.0/16

두 개의 AZ:

ap-northeast-1a
Endpoint subnet:
10.0.10.0/24

ap-northeast-1c
Endpoint subnet:
10.0.20.0/24

최소 2개의 AZ를 보유하는 것이 좋습니다.

9. 2단계: 트랜짓 게이트웨이 생성

VPC Console：

Transit Gateways
→ Create transit gateway

예를 들어:

Name:
core-tgw

다음으로 VPC 첨부 파일을 생성합니다.

core-tgw
│
├─ shared-endpoint-vpc
├─ app-vpc-a
├─ app-vpc-b
└─ app-vpc-c

여러 AWS 계정을 보유하고 있는 경우 AWS RAM을 통해 Transit Gateway를 공유할 수도 있습니다. AWS는 계정 간 TGW 공유를 공식적으로 지원합니다.

10. 3단계: VPC 라우팅 테이블 구성

추정:

Shared VPC:
10.0.0.0/16

VPC-A:
10.10.0.0/16

VPC-B:
10.20.0.0/16

VPC-A：

Destination        Target

10.10.0.0/16       local
10.0.0.0/16        tgw-xxxxxxxx

VPC-B：

Destination        Target

10.20.0.0/16       local
10.0.0.0/16        tgw-xxxxxxxx

Shared Endpoint VPC：

Destination        Target

10.0.0.0/16        local
10.10.0.0/16       tgw-xxxxxxxx
10.20.0.0/16       tgw-xxxxxxxx

그렇지 않으면 다음과 같은 일이 발생합니다.

VPC-A → Endpoint

가셔도 되지만, 다음과 같은 사항이 있습니다:

Endpoint → VPC-A

그들은 돌아올 수 없어.

11. 4단계: TGW 라우팅 테이블 구성

TGW Route Table：

10.0.0.0/16
    → shared-endpoint-vpc attachment

10.10.0.0/16
    → VPC-A attachment

10.20.0.0/16
    → VPC-B attachment

10.30.0.0/16
    → VPC-C attachment

네트워크 격리가 특별히 필요하지 않은 경우 경로 전파를 사용할 수 있습니다.

기업 환경은 일반적으로 다음과 같이 구분됩니다.

Spoke TGW RT
Shared Services TGW RT
Inspection TGW RT

기본적으로 모든 VPC가 서로 통신하도록 허용하지 마십시오.

12. 5단계: 인터페이스 엔드포인트 생성

예를 들어, 공유가 필요한 경우:

AWS Systems Manager

만들다:

VPC
→ Endpoints
→ Create endpoint

Service：

com.amazonaws.ap-northeast-1.ssm

VPC：

shared-endpoint-vpc

Subnets：

ap-northeast-1a
10.0.10.0/24

ap-northeast-1c
10.0.20.0/24

따라서 다음과 같은 결과가 나타납니다.

vpce-0123456789

ENI-A:
10.0.10.50

ENI-C:
10.0.20.50

열세 번째이자 가장 중요한 사항: 프라이빗 DNS를 직접 활성화하지 마십시오.

VPC가 일반적으로 자체 엔드포인트를 사용하는 경우:

Enable Private DNS
✓

매우 편리합니다.

예를 들어, 원래는 다음과 같습니다.

ssm.ap-northeast-1.amazonaws.com

자동으로 다음과 같이 구문 분석됩니다.

10.0.10.50
10.0.20.50

AWS SDK는 전혀 수정할 필요가 없습니다.

하지만 중앙 집중식 아키텍처에는 문제가 있습니다.

프라이빗 DNS는 엔드포인트가 있는 VPC 내에서만 작동하는 AWS 관리형 프라이빗 호스팅 영역을 자동으로 생성합니다.

그러므로:

Shared VPC

알다:

ssm.ap-northeast-1.amazonaws.com
=
10.0.10.50

하지만:

VPC-A
VPC-B

모르겠습니다.

따라서 AWS의 공식 중앙 엔드포인트 아키텍처는 다음과 같이 권장합니다.

중앙 엔드포인트 시나리오에서는 엔드포인트에 대한 자동 프라이빗 DNS를 비활성화한 다음 Route 53 프라이빗 호스팅 영역을 수동으로 생성합니다.

14. 6단계: Route 53 프라이빗 호스팅 영역 생성

만들다:

Route 53
→ Hosted zones
→ Create hosted zone

Domain：

ssm.ap-northeast-1.amazonaws.com

Type：

Private Hosted Zone

먼저, 동료 여러분:

shared-endpoint-vpc

15. 7단계: 별칭 생성

입력하다:

ssm.ap-northeast-1.amazonaws.com

Create record。

Record：

ssm.ap-northeast-1.amazonaws.com

Type：

선택하다:

Alias

대상 선택:

VPC Endpoint

그 다음에:

vpce-0123456789...

AWS의 공식 중앙 엔드포인트 솔루션은 다음과 같습니다.

AWS Service DNS
↓
Route53 PHZ
↓
Alias
↓
Central Interface Endpoint

애플리케이션이 엔드포인트 IP를 사용하도록 수동으로 설정하는 대신,

16. 8단계: PHZ를 모든 VPC와 연결합니다.

Private Hosted Zone：

ssm.ap-northeast-1.amazonaws.com

VPC-A

구현하다:

nslookup ssm.ap-northeast-1.amazonaws.com

얻다:

10.0.10.50
10.0.20.50

VPC-B

같은:

nslookup ssm.ap-northeast-1.amazonaws.com

도:

10.0.10.50
10.0.20.50

현재:

VPC-A
   │
   │ DNS
   ▼
ssm.ap-northeast-1.amazonaws.com
   │
   ▼
10.0.10.50
   │
   ▼
Transit Gateway
   │
   ▼
Central VPC
   │
   ▼
SSM VPC Endpoint

이것으로 이야기가 끝납니다.

17. 9단계: 엔드포인트 보안 그룹

이것이 두 번째로 매우 흔한 함정입니다.

엔드포인트 ENI에는 보안 그룹이 있습니다.

예를 들어:

endpoint-sg

Inbound：

HTTPS
TCP 443

Source:
10.10.0.0/16
10.20.0.0/16
10.30.0.0/16

더욱 정교하게 만들 수도 있습니다.

예를 들어, 다음과 같은 경우에만 해당됩니다.

10.10.10.0/24
10.20.20.0/24

엔드포인트에 대한 액세스를 허용합니다.

이곳으로의 통행이 허용되지 않는 경우:

DNS OK
Routing OK
TGW OK

아직:

timeout

18. 최종 데이터 흐름

예를 들어 VPC-A의 EC2 인스턴스는 다음과 같습니다.

aws ssm describe-instance-information \
    --region ap-northeast-1

SDK 요청:

https://ssm.ap-northeast-1.amazonaws.com

① DNS：

ssm.ap-northeast-1.amazonaws.com
↓
Route53 Private Hosted Zone
↓
10.0.10.50

② Routing：

EC2
10.10.1.50
↓
VPC-A route table
↓
10.0.0.0/16 → TGW

③ TGW：

10.0.10.50
↓
Shared VPC attachment

④ Shared VPC：

Endpoint ENI
10.0.10.50

⑤ Endpoint：

PrivateLink
↓
AWS SSM

다음 사항은 전체 과정에서 필수 사항이 아닙니다.

Internet Gateway
NAT Gateway
Public IP

이것이 PrivateLink의 가장 중요한 의미 중 하나입니다. PrivateLink의 목적은 IGW, NAT 또는 공용 IP 주소 없이도 사설 네트워크를 통해 AWS 서비스에 액세스할 수 있도록 하는 것입니다.

19. 여러 엔드포인트를 처리하는 방법은 무엇입니까?

다음과 같은 필요가 있다고 가정해 보겠습니다.

SSM
EC2 Messages
SSM Messages
KMS
CloudWatch
CloudWatch Logs
Secrets Manager
ECR API
ECR DKR
STS

Central VPC：

Network VPC

├─ vpce-ssm
├─ vpce-ssmmessages
├─ vpce-ec2messages
├─ vpce-kms
├─ vpce-monitoring
├─ vpce-logs
├─ vpce-secretsmanager
├─ vpce-ecr-api
├─ vpce-ecr-dkr
└─ vpce-sts

Route53：

ssm.ap-northeast-1.amazonaws.com
→ SSM Endpoint

ssmmessages.ap-northeast-1.amazonaws.com
→ SSM Messages Endpoint

ec2messages.ap-northeast-1.amazonaws.com
→ EC2 Messages Endpoint

kms.ap-northeast-1.amazonaws.com
→ KMS Endpoint

logs.ap-northeast-1.amazonaws.com
→ Logs Endpoint

secretsmanager.ap-northeast-1.amazonaws.com
→ Secrets Manager Endpoint

그런 다음 PHZ는 동시에 연관됩니다.

VPC-A
VPC-B
VPC-C
VPC-D
...

일부 AWS 서비스는 ECR Docker/OCI 엔드포인트와 같이 고유한 DNS 구조를 가지고 있습니다. AWS는 또한 일부 서비스에서 와일드카드 별칭이 필요할 수 있으므로 모든 엔드포인트에 단일 레코드만 있다고 가정할 수 없다고 명시합니다.

20. 만약 서로 다른 AWS 계정이라면 어떻게 되나요?

예를 들어:

Network Account
111111111111

App Account A
222222222222

App Account B
333333333333

건축 양식은 완벽하게 적합합니다.

추천하다:

AWS Organizations

Network Account
 ├─ TGW
 ├─ Shared VPC
 ├─ Interface Endpoints
 └─ Route53 PHZ

       ↓ AWS RAM

App Account A
 └─ VPC-A

App Account B
 └─ VPC-B

TGW는 다음 경로를 통해 접속할 수 있습니다:

AWS Resource Access Manager

공유하다.

개인 호스팅 영역에 대한 계정 간 연결은 조금 더 복잡합니다.

21. 계정 간 PHZ 연관 관계

예를 들어:

Network Account:
PHZ Z123456

App Account:
VPC vpc-abcdef

네트워크 계정 우선:

aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z123456 \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdef

그런 다음 앱 계정:

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z123456 \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdef

AWS에서 계정 간 프라이빗 호스팅 영역을 설정하는 공식 절차는 다음과 같습니다.

PHZ Owner
↓
CreateVPCAssociationAuthorization

VPC Owner
↓
AssociateVPCWithHostedZone

또한, 이러한 계정 간 작업은 Route 53 콘솔만으로는 완전히 완료할 수 없으며, CLI/API/SDK가 필요합니다.

22. 방법 2: VPC 피어링

VPC가 두세 개밖에 없다면 TGW가 반드시 필요한 것은 아닙니다.

예를 들어:

           Central VPC
          Endpoint VPC
        10.0.0.0/16
          /       \
         /         \
      Peering     Peering
       /             \
   VPC-A             VPC-B
10.10/16           10.20/16

구성:

VPC-A ↔ Central VPC
VPC-B ↔ Central VPC

그 다음에:

VPC-A：

10.0.0.0/16
→ pcx-aaa

Central：

10.10.0.0/16
→ pcx-aaa

10.20.0.0/16
→ pcx-bbb

Endpoint SG：

443
10.10.0.0/16

443
10.20.0.0/16

DNS는 여전히:

PHZ
↓
Endpoint Alias
↓
associate VPC-A
associate VPC-B

23. 피어링의 가장 큰 단점

그것:

전이 라우팅은 지원되지 않습니다.

AWS는 공식 성명을 통해 이 점을 분명히 밝혔습니다.

예를 들어:

VPC-A
  │
peering
  │
Central
  │
peering
  │
VPC-B

이것으로는 다음과 같은 결론을 내릴 수 없습니다.

A → Central → B

가능합니다.

그러므로 만약:

2 VPC
3 VPC

엿보기가 매우 편합니다.

만약에:

20 VPC
50 VPC
100 VPC

유지하기가 점점 더 어려워질 것입니다.

그러므로 일반적으로 말하자면:

소규모: VPC 피어링 대규모: 트랜짓 게이트웨이

24. 방법 3: 엔드포인트 DNS를 직접 사용

또한 테스트에 특히 적합한 매우 간단한 방법도 있습니다.

엔드포인트를 생성하면 AWS에서 다음과 같은 내용이 생성됩니다.

vpce-0123456789abcdef-xxxx.ssm.ap-northeast-1.vpce.amazonaws.com

AWS는 인터페이스 엔드포인트에 대한 지역 및 영역 DNS 이름을 생성합니다.

따라서 VPC-A 네트워크가 공유 VPC에 도달할 수만 있다면 다음과 같은 작업을 직접 수행할 수 있습니다.

aws ssm describe-instance-information \
  --endpoint-url \
  https://vpce-xxxx.ssm.ap-northeast-1.vpce.amazonaws.com

이렇게 하면 직접 할 필요조차 없습니다.

ssm.ap-northeast-1.amazonaws.com

Private Hosted Zone。

이점

아주 쉽습니다.

다음과 같은 용도에 적합합니다:

라우팅 유효성 검사, SG 유효성 검사, TGW 유효성 검사, 엔드포인트 유효성 검사

결점

해당 애플리케이션의 구성을 수정해야 합니다.

원래의:

AWS SDK
↓
ssm.ap-northeast-1.amazonaws.com

이제 다음과 같이 됩니다:

AWS SDK
↓
vpce-xxx....

많은 애플리케이션은 이런 방식으로 수정하기가 편리하지 않습니다.

따라서 일반적인 생산 환경은 다음과 같습니다.

PHZ + Alias

최대.

25. 중앙 집중식 엔드포인트의 가장 큰 장점

① 엔드포인트를 크게 줄입니다

추정:

20 VPC
15 Interface Endpoints
2 AZ

Distributed：

20 × 15 × 2
=
600 Endpoint AZ instances

집중:

15 × 2
=
30

차이가 엄청납니다.

26. 장점 ②: 비용이 크게 절감될 수 있습니다.

인터페이스 엔드포인트 수신됨:

Endpoint/AZ/hour
+
Data Processing / GB

AWS PrivateLink에는 AZ별 시간당 요금과 데이터 처리 요금이 부과됩니다. 첫 1PB의 기본 데이터 처리 요금은 약 ₩14.10/GB이며, 시간당 요금은 리전에 따라 달라집니다.

Distributed：

VPC × Service × AZ × endpoint-hour

Central：

Service × AZ × endpoint-hour
+
TGW

VPC 수가 많을수록 엔드포인트 수의 차이가 더욱 두드러집니다.

27. 하지만 TGW는 무료가 아닙니다.

여기 있는 많은 아키텍처 다이어그램은 의도적으로 이 점을 무시하고 있습니다.

트랜짓 게이트웨이에서 수신함:

첨부파일 시간당 요금 + 데이터 처리(GB당)

AWS는 공식적으로 연결 시간 수와 TGW를 통해 흐르는 데이터 양을 기준으로 요금을 부과합니다.

그러므로 실제로 계산해야 할 것은 다음과 같습니다.

VPC 엔드포인트별

비용 = VPC 수 × 엔드포인트 수 × 가용 영역 수 × 엔드포인트 시간당 요금 + PrivateLink 데이터

Centralized

비용 = 엔드포인트 수 × 가용 영역(AZ) 수 × 엔드포인트 시간당 비용 + TGW 연결 시간당 비용 + TGW 데이터 처리 비용 + PrivateLink 데이터 처리 비용 + 가용 영역 간 데이터 전송 비용(해당되는 경우)

그래서:

이미 TGW(타운십 게이트웨이)를 보유한 기업의 경우, 중앙 엔드포인트 구축은 매우 매력적인 선택지입니다.

하지만 만약:

VPC는 2개뿐이고, 엔드포인트는 3개뿐이며, TGW는 없습니다.

엔드포인트 비용을 절감하기 위해 특별히 TGW를 구축하는 것은 비용 효율적이지 않을 수 있습니다.

28. 중앙집중화 방식의 가장 큰 단점: 폭발 반경

이것은 매우 중요한 문제입니다.

결과적으로 다음과 같은 것으로 밝혀졌습니다:

VPC-A → Endpoint-A
VPC-B → Endpoint-B
VPC-C → Endpoint-C

엔드포인트 A에 문제가 있습니다.

A만 문제가 있다.

집중:

A ─┐
B ─┼→ Central Endpoint
C ─┘

중앙 엔드포인트, 공유 VPC 라우팅, DNS 또는 TGW 구성 오류:

A
B
C
D
E
...

두 사람 모두 정학 처분을 받을 수도 있습니다.

그래서:

비용 절감과 관리에 드는 비용은 공유 인프라에 대한 파급 효과 확대라는 결과를 초래합니다.

AWS는 또한 중앙 엔드포인트가 정책 및 장애 영향의 범위를 넓힐 수 있다는 점을 구체적으로 지적합니다.

29. 엔드포인트 정책 또한 더욱 복잡해질 것입니다.

Distributed：

개발 VPC 엔드포인트 → 개발 권한 프로덕션 VPC 엔드포인트 → 프로덕션 권한 보안 VPC 엔드포인트 → 보안 권한

관리하기 매우 쉽습니다.

집중:

개발, 운영, 테스트 환경의 보안 모니터링을 위한 KMS 엔드포인트...

모두 공유했습니다.

Endpoint Policy：

Principal
Resource
Action
Conditions

상황은 점점 더 복잡해질 것입니다.

AWS는 이와 관련하여 특별 공지를 발표했습니다.

중앙 집중화는 최소 권한 엔드포인트 정책 관리를 더욱 어렵게 만들고, 단일 엔드포인트 정책의 파급 효과를 더욱 크게 만듭니다. 또한 엔드포인트 정책 문서 자체에도 크기 제한이 있습니다.

30. 보안 격리 또한 문제입니다.

예를 들어:

Production VPC
Development VPC

모든 용도:

Central S3 Interface Endpoint

하지만:

IAM
Bucket Policy
Endpoint Policy
SG

권한 관리는 여전히 가능하지만, 물리적/네트워크 경계는 더 이상 완전히 독립적이지 않습니다.

따라서, 특히 까다로운 환경의 경우:

PCI 금융생산 보안 도구

가능한 디자인:

Prod Endpoint VPC

NonProd Endpoint VPC

회사 전체 대신에:

엔드포인트 VPC

31. 권장 기업 구조

회사 전체에 단 한 명뿐인 것이 아니라, 오히려 다음과 같은 상황입니다.

                   AWS Services
                        │
          ┌─────────────┴──────────────┐
          │                            │
   Prod Endpoint VPC           NonProd Endpoint VPC
          │                            │
        TGW                         TGW
     ┌────┼────┐                 ┌────┼────┐
     │    │    │                 │    │    │
   Prod Prod Prod              Dev  Test Sandbox
   VPC1 VPC2 VPC3

심지어:

Security
Production
NonProduction

공유 엔드포인트 VPC를 별도로 생성하십시오.

이렇게 하면 두 가지 모두를 고려할 수 있습니다.

비용 관리 보안 격리 폭발 반경

32. 또 다른 매우 실질적인 문제: DNS 충돌.

예를 들어 VPC-A는 이미 자체적인 기능을 가지고 있었습니다.

SSM Endpoint
Private DNS = Enabled

그러면 다시 연관 짓게 됩니다.

ssm.ap-northeast-1.amazonaws.com

여기는 중앙 공공안전구역입니다.

이로 인해 DNS 네임스페이스 충돌이 발생할 수 있습니다.

따라서 이주는 일반적으로 다음과 같아야 합니다.

① 중앙 엔드포인트 생성 ② 중앙 pHZ 생성 ③ 엔드포인트별 DNS 테스트 ④ 스포크 VPC 연결 ⑤ DNS 확인 ⑥ 스포크 VPC 자체 엔드포인트 삭제 ⑦ 서비스 확인 ⑧ 다음 VPC로 마이그레이션

한꺼번에 모두 삭제하는 대신에요.

33. 지역 간 작업은 가능하지만 과도한 사용은 권장되지 않습니다.

예를 들어:

Tokyo VPC
ap-northeast-1

Osaka VPC
ap-northeast-3

이론상으로는:

Tokyo VPC
    ↓
TGW
    ↓
TGW Peering
    ↓
Osaka
    ↓
Central Endpoint

AWS는 또한 다음과 같은 방법을 통해 리전 간 중앙 집중식 엔드포인트 아키텍처를 제공합니다.

TGW Peering
+
Private Hosted Zones

성취하다.

하지만 일반적으로는 다음과 같이 하는 것이 좋습니다.

Tokyo Endpoint VPC
   ↓
Tokyo VPCs

Osaka Endpoint VPC
   ↓
Osaka VPCs

즉, 다음과 같습니다.

하나의 리전, 하나의 중앙 엔드포인트 VPC.

그래서:

지연 시간 단축, 네트워크 간소화, 재해 복구 능력 향상, 지역 간 트래픽 비용 절감

34. 네 가지 옵션의 직접 비교

프로젝트	VPC 엔드포인트별	Peering Central	TGW Central	S3 Gateway
엔드포인트 번호	많은	약간의	약간의	VPC당
PrivateLink 비용	높은	낮은	낮은	무료
TGW 비용	없음	없음	가지다	없음
DNS 관리	단순한	중간	중간	아주 간단합니다.
네트워크 복잡성	가장 낮은	중간	중간	가장 낮은
대규모 VPC	❌	❌	✅	✅
격리	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
Blast Radius	작은	가운데	큰	작은
여러 계정	할 수 있다	할 수 있다	매우 적합함	각각 만들어진
Transitive Routing	N/A	❌	✅	N/A
권장 VPC 수	1에서 소량	소량	중형 및 대형	어느

35. 대규모 환경에 적합한 디자인

회사가 다음과 같은 상황을 가지고 있다고 가정해 보겠습니다.

VPC 30개, AWS 계정 5개, 도쿄 리전

다음과 같이 입증될 수 있습니다:

Network Account
│
├─ Transit Gateway
│
├─ Endpoint VPC
│   │
│   ├─ SSM
│   ├─ SSM Messages
│   ├─ EC2 Messages
│   ├─ ECR API
│   ├─ ECR DKR
│   ├─ STS
│   ├─ KMS
│   ├─ Secrets Manager
│   ├─ CloudWatch
│   ├─ CloudWatch Logs
│   ├─ SNS
│   └─ SQS
│
└─ Route53 Private Hosted Zones

그 다음에:

Account A
├─ VPC1 ─┐
├─ VPC2 ─┤
└─ VPC3 ─┤
         │
Account B│
├─ VPC4 ─┤
├─ VPC5 ─┤
└─ VPC6 ─┤
         ▼
        TGW
         │
         ▼
 Endpoint VPC
         │
         ▼
 AWS PrivateLink

하지만:

S3 Gateway Endpoint
DynamoDB Gateway Endpoint

여전히 권장되는 사항은 다음과 같습니다.

각 VPC별로 별도로 생성됩니다.

무료이기 때문이며, 게이트웨이 엔드포인트 자체는 TGW/피어링을 통해 다른 VPC에서 사용할 수 없습니다.

36. 전체 구조는 4개의 층으로 기억할 수 있습니다.

사실, 앞으로 문제를 해결할 때는 이 네 가지 단계만 기억하면 됩니다.

             ┌─────────────────┐
             │      DNS        │
             │   Route53 PHZ   │
             └────────┬────────┘
                      │
                      ▼
             Endpoint Private IP
                      │
             ┌────────┴────────┐
             │     Routing     │
             │   TGW/Peering   │
             └────────┬────────┘
                      │
             ┌────────▼────────┐
             │    Security     │
             │ Endpoint SG/NACL│
             └────────┬────────┘
                      │
             ┌────────▼────────┐
             │    IAM Policy   │
             │ Endpoint Policy │
             │ Service Policy  │
             └─────────────────┘

접속이 불가능한 경우 다음 단계를 따르십시오.

① DNS
② Route
③ Security Group/NACL
④ IAM / Endpoint Policy

조사를 통해 문제점을 발견할 수 있는 경우가 많습니다.

가장 기억에 남는 문장

VPC 엔드포인트 자체는 RAM을 통해 "여러 VPC와 공유"되지 않습니다.

인터페이스 엔드포인트의 중앙 집중식 특성은 다음과 같습니다.

Central VPC
    ↓
Interface Endpoint ENI
    ↑
TGW / VPC Peering
    ↑
Other VPCs

다시 통과했습니다:

Route53 Private Hosted Zone

모든 VPC에서:

ssm.ap-northeast-1.amazonaws.com

모두 분석 결과는 다음과 같습니다.

Central VPC Endpoint

이로써 전체 과정이 완료됩니다. Shared/Centralized VPC Endpoint。

그리고 S3/DynamoDB 게이트웨이 엔드포인트를 사용할 때는 이렇게 하지 마세요. 각 VPC마다 자체적으로 구축해야 합니다.무료이기 때문이며, AWS는 TGW나 피어링과 같은 다른 쪽 끝에서의 사용을 명시적으로 금지하고 있습니다.

여러 VPC에서 AWS VPC Endpoint 공유하기: 중앙 집중식 아키텍처 및 구성 가이드

먼저 가장 중요한 결론부터 말씀드리겠습니다.

옵션 A: 각 VPC는 ​​자체 엔드포인트를 생성합니다.

II. 중앙 집중식 VPC 엔드포인트 아키텍처

III. 특히 중요한 예외 사항: S3/DynamoDB

게이트웨이 엔드포인트는 이러한 방식으로 공유할 수 없습니다.

IV. S3/DynamoDB 사용을 위한 올바른 방법

5. 인터페이스 엔드포인트를 VPC 간에 사용할 수 있는 이유는 무엇입니까?

VI. 세 가지 실질적인 구현 방법

VII. 방법 1: 트랜짓 게이트웨이 + 중앙 엔드포인트

VIII. 구체적인 운영 절차

1단계: 네트워크 VPC 생성

9. 2단계: 트랜짓 게이트웨이 생성

10. 3단계: VPC 라우팅 테이블 구성

11. 4단계: TGW 라우팅 테이블 구성

12. 5단계: 인터페이스 엔드포인트 생성

열세 번째이자 가장 중요한 사항: 프라이빗 DNS를 직접 활성화하지 마십시오.

14. 6단계: Route 53 프라이빗 호스팅 영역 생성

15. 7단계: 별칭 생성

16. 8단계: PHZ를 모든 VPC와 연결합니다.

VPC-A

VPC-B

17. 9단계: 엔드포인트 보안 그룹

18. 최종 데이터 흐름

19. 여러 엔드포인트를 처리하는 방법은 무엇입니까?

20. 만약 서로 다른 AWS 계정이라면 어떻게 되나요?

21. 계정 간 PHZ 연관 관계

22. 방법 2: VPC 피어링

23. 피어링의 가장 큰 단점

24. 방법 3: 엔드포인트 DNS를 직접 사용

이점

결점

25. 중앙 집중식 엔드포인트의 가장 큰 장점

① 엔드포인트를 크게 줄입니다

26. 장점 ②: 비용이 크게 절감될 수 있습니다.

27. 하지만 TGW는 무료가 아닙니다.

VPC 엔드포인트별

Centralized

28. 중앙집중화 방식의 가장 큰 단점: 폭발 반경

29. 엔드포인트 정책 또한 더욱 복잡해질 것입니다.

30. 보안 격리 또한 문제입니다.

31. 권장 기업 구조

32. 또 다른 매우 실질적인 문제: DNS 충돌.

33. 지역 간 작업은 가능하지만 과도한 사용은 권장되지 않습니다.

34. 네 가지 옵션의 직접 비교

35. 대규모 환경에 적합한 디자인

36. 전체 구조는 4개의 층으로 기억할 수 있습니다.

가장 기억에 남는 문장

옵션 A: 각 VPC는 자체 엔드포인트를 생성합니다.