Cómo compartir AWS VPC Endpoints entre varias VPC: guía de arquitectura y configuración centralizadas

En AWS, la esencia de "compartir un punto final de VPC entre diferentes VPC" no es simplemente adjuntar un punto final directamente a varias VPC, sino más bien:

Centralice los puntos finales de la interfaz VPC en una única VPC de servicios centrales/compartidos y, a continuación, permita que otras VPC accedan a la IP privada de este punto final a través de una puerta de enlace de tránsito o un emparejamiento de VPC, utilizando Route 53 para unificar el DNS.

AWS se refiere oficialmente a este modelo como... Centralized access to VPC private endpoints。

Pero primero, es fundamental distinguirlos. Interface Endpoint y Gateway Endpoint。

En primer lugar, expongamos la conclusión más importante.

Supongamos que actualmente tienes:

VPC-A
VPC-B
VPC-C

Las tres VPC necesitan:

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

Tienes dos diseños.

Opción A: Cada VPC crea su propio punto final.

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

Este es el diseño más simple y aislado.

Sin embargo, el número de puntos finales aumentará rápidamente.

Por ejemplo:

10 VPC × 20 puntos finales de servicio de AWS × 2 zonas de disponibilidad = 400 ENI de punto final

El punto final de la interfaz se basa en Punto final × Zona de disponibilidad × HoraHay una tarifa, más una tarifa de procesamiento de datos.

Por lo tanto, a medida que aumenta la escala, los costos y el mantenimiento aumentarán significativamente.

II. Arquitectura del punto final de VPC centralizado

Establecer un:

Network VPC / Shared Services VPC

Todos los puntos finales se encuentran aquí.

Por ejemplo:

                  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

entonces:

EC2 en VPC-A ↓ ssm.ap-northeast-1.amazonaws.com ↓ Ruta 53 ↓ Se resuelve en la IP privada del punto final de SSM en la VPC compartida ↓ Puerta de enlace de tránsito ↓ Interfaz del punto final ENI ↓ AWS PrivateLink ↓ SSM

AWS ofrece soporte oficial para este diseño centralizado.

III. Una excepción particularmente importante: S3 / DynamoDB

Esto debe discutirse por separado.

Los puntos finales de la puerta de enlace no se pueden compartir de esta manera.

S3 y DynamoDB tienen:

Gateway VPC Endpoint

Por ejemplo:

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

Es completamente diferente de un punto final de interfaz normal.

Gateway Endpoint：

No utilice PrivateLink.
No cree ENI
Básicamente, es una combinación de tabla de rutas y lista de prefijos administrada por AWS.
gratis
Solo puede ser utilizado por la VPC en la que reside.

AWS ha declarado oficialmente:

Los puntos finales de puerta de enlace no pueden extenderse más allá de la VPC; los recursos del otro extremo de una VPC Peering, Transit Gateway, VPN o Direct Connect no pueden tomar prestados recursos de este punto final de puerta de enlace.

Por lo tanto, no debe diseñarse de la siguiente manera:

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

A continuación, queremos que VPC-A utilice el punto final de puerta de enlace S3 de la VPC compartida.

No.

IV. Prácticas correctas para S3 / DynamoDB

Normalmente debería ser:

VPC-A → Su propio punto final de puerta de enlace S3 VPC-B → Su propio punto final de puerta de enlace S3 VPC-C → Su propio punto final de puerta de enlace S3

porque:

Los puntos finales de la puerta de enlace no tienen costo adicional.

Por lo tanto, no es necesario centralizar el punto final de la puerta de enlace S3 para "reducir el número de puntos finales".

recomendar:

                  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.

Estos Interface VPC Endpoint Eso es lo que hace que la centralización sea adecuada.

5. ¿Por qué se puede utilizar Interface Endpoint en diferentes VPC?

Porque un punto final de interfaz es esencialmente:

Cree una ENI con una dirección IP privada en la subred que haya especificado.

Según la documentación oficial de AWS, un punto final de interfaz crea una interfaz de red de punto final en la subred que elijas y le asigna una dirección IP privada a esa subred.

Por ejemplo:

Shared VPC
10.0.0.0/16

AZ-a:
Endpoint ENI
10.0.10.50

AZ-c:
Endpoint ENI
10.0.20.60

Para la otra VPC, siempre que:

VPC-A → Puede enrutar a 10.0.10.50

El grupo de seguridad 10.0.10.50 permite VPC-A

En realidad, la red ya puede acceder al punto final.

Por lo tanto, el llamado:

Punto final de VPC compartido

Lo que realmente sucedió fue:

Otras VPC ↓ Red entre VPC ↓ Acceso a la interfaz de red de punto final de la VPC central

No:

Un dispositivo vpce-xxx puede conectarse a tres VPC simultáneamente.

Se trata de dos conceptos completamente diferentes.

VI. Tres métodos prácticos de implementación

En realidad, se puede dividir en tres tipos.

método	Nivel de recomendación	Adecuado
Transit Gateway	⭐⭐⭐⭐⭐	VPC multi-VPC a gran escala
VPC Peering	⭐⭐⭐⭐	De 2 a 5 VPC
Utilice el DNS del punto final directamente.	⭐⭐⭐	Prueba/Aplicación especial
Punto final independiente por VPC	⭐⭐⭐⭐⭐	Priorizar el aislamiento, a pequeña escala

VII. Método 1: Puerta de enlace de tránsito + Punto final central

Esta es la solución más común para entornos empresariales.

Suponiendo que se trate de la región de Tokio:

ap-northeast-1

red:

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

Arquitectura:

                       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

Transit Gateway (TGW) está diseñado por AWS para el enrutamiento centralizado a través de múltiples VPC y admite el enrutamiento transitorio; AWS también recomienda priorizar TGW para redes multi-VPC a gran escala.

VIII. Procedimientos operativos específicos

A continuación se detalla la configuración real.

Paso 1: Crear una VPC de red

Por ejemplo:

VPC:
shared-endpoint-vpc

CIDR:
10.0.0.0/16

Dos AZ:

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

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

Se recomienda tener al menos 2 AZ.

9. Paso 2: Crear una puerta de enlace de tránsito

VPC Console：

Transit Gateways
→ Create transit gateway

Por ejemplo:

Name:
core-tgw

Luego, cree un archivo adjunto de VPC:

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

Si tienes diferentes cuentas de AWS, también puedes compartir Transit Gateway a través de AWS RAM. AWS admite oficialmente el uso compartido de TGW entre cuentas.

10. Paso 3: Configurar la tabla de rutas de VPC

Suposición:

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

De lo contrario, ocurrirá lo siguiente:

VPC-A → Endpoint

Puedes ir, pero:

Endpoint → VPC-A

No pueden regresar.

11. Paso 4: Configurar la tabla de rutas 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

Si no existe una necesidad especial de aislamiento de red, se puede utilizar la propagación de rutas.

El entorno corporativo suele estar dividido de la siguiente manera:

Spoke TGW RT
Shared Services TGW RT
Inspection TGW RT

Evite permitir que todas las VPC se comuniquen entre sí de forma predeterminada.

12. Paso 5: Crear punto final de interfaz

Por ejemplo, si es necesario compartir:

AWS Systems Manager

crear:

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

De este modo, surge lo siguiente:

vpce-0123456789

ENI-A:
10.0.10.50

ENI-C:
10.0.20.50

Decimotercero, y lo más importante: No habilite directamente el DNS privado.

Cuando una VPC normalmente utiliza su propio punto final:

Enable Private DNS
✓

Muy conveniente.

Por ejemplo, originalmente:

ssm.ap-northeast-1.amazonaws.com

Se analizará automáticamente en:

10.0.10.50
10.0.20.50

El SDK de AWS no requiere absolutamente ninguna modificación.

Sin embargo, la arquitectura centralizada tiene un problema.

El DNS privado crea automáticamente una zona privada alojada administrada por AWS, que solo funciona dentro de la VPC donde reside el punto final.

por lo tanto:

Shared VPC

Saber:

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

pero:

VPC-A
VPC-B

No sé.

Por lo tanto, la arquitectura oficial de punto final central de AWS recomienda:

En el escenario de punto final central, desactive el DNS privado automático para el punto final y, a continuación, cree manualmente la zona alojada privada de Route 53.

14. Paso 6: Crear una zona privada alojada de Route 53

crear:

Route 53
→ Hosted zones
→ Create hosted zone

Domain：

ssm.ap-northeast-1.amazonaws.com

Type：

Private Hosted Zone

Primero, asocia:

shared-endpoint-vpc

15. Paso 7: Crear alias

Ingresar:

ssm.ap-northeast-1.amazonaws.com

Create record。

Record：

ssm.ap-northeast-1.amazonaws.com

Type：

elegir:

Alias

Selección de objetivos:

VPC Endpoint

Entonces:

vpce-0123456789...

La solución oficial de punto final central de AWS es:

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

En lugar de hacer que la aplicación utilice manualmente la IP del punto final.

16. Paso 8: Asociar PHZ con todas las VPC.

Private Hosted Zone：

ssm.ap-northeast-1.amazonaws.com

Relacionado:

shared-endpoint-vpc
app-vpc-a
app-vpc-b
app-vpc-c

Una zona privada alojada en AWS Route 53 puede asociarse con varias VPC.

entonces:

VPC-A

implementar:

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

conseguir:

10.0.10.50
10.0.20.50

VPC-B

mismo:

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

También:

10.0.10.50
10.0.20.50

En este momento:

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

Con esto concluye la historia.

17. Paso 9: Grupo de seguridad de punto final

Este es el segundo error muy común.

El punto final ENI tiene un grupo de seguridad.

Por ejemplo:

endpoint-sg

Inbound：

HTTPS
TCP 443

Source:
10.10.0.0/16
10.20.0.0/16
10.30.0.0/16

Se puede hacer aún más fino.

Por ejemplo, solo:

10.10.10.0/24
10.20.20.0/24

Permitir el acceso al punto final.

Si el paso no está permitido aquí:

DNS OK
Routing OK
TGW OK

aún:

timeout

18. Flujo de datos final

Por ejemplo, EC2 en VPC-A:

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

Solicitud de 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

Lo siguiente no es necesario durante todo el proceso:

Internet Gateway
NAT Gateway
Public IP

Esta es una de sus mayores ventajas. El propósito de PrivateLink es permitir el acceso a los servicios de AWS a través de una red privada sin necesidad de IGW, NAT ni direcciones IP públicas.

19. ¿Cómo gestionar múltiples puntos finales?

Supongamos que necesitas:

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

Entonces PHZ asocia simultáneamente:

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

Algunos servicios de AWS tienen estructuras DNS únicas, como los puntos de conexión ECR Docker/OCI. AWS también señala que algunos servicios pueden requerir alias comodín, por lo que no se puede asumir que todos los puntos de conexión tengan un único registro simple.

20. ¿Qué ocurre si se trata de cuentas de AWS diferentes?

Por ejemplo:

Network Account
111111111111

App Account A
222222222222

App Account B
333333333333

La arquitectura es perfectamente aceptable.

recomendar:

AWS Organizations

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

       ↓ AWS RAM

App Account A
 └─ VPC-A

App Account B
 └─ VPC-B

Se puede acceder a TGW a través de:

AWS Resource Access Manager

compartir.

Las asociaciones entre cuentas para las Zonas Privadas Alojadas son un poco más complicadas.

21. Asociación de PHZ entre cuentas

Por ejemplo:

Network Account:
PHZ Z123456

App Account:
VPC vpc-abcdef

Primero la cuenta de red:

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

Luego, Cuenta de la aplicación:

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

El proceso oficial de AWS para las zonas alojadas privadas entre cuentas es el siguiente:

PHZ Owner
↓
CreateVPCAssociationAuthorization

VPC Owner
↓
AssociateVPCWithHostedZone

Además, esta operación entre cuentas no se puede completar únicamente utilizando la consola de Route 53; requiere CLI/API/SDK.

22. Método 2: Interconexión de VPC

Si solo tienes dos o tres VPC, no necesariamente necesitas un TGW.

Por ejemplo:

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

Configuración:

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

Entonces:

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 todavía:

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

23. El mayor inconveniente del Peering

él:

El enrutamiento transitivo no es compatible.

AWS lo ha dejado claro en comunicados oficiales.

Por ejemplo:

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

Esto no puede utilizarse para concluir que:

A → Central → B

Es posible.

Por lo tanto, si:

2 VPC
3 VPC

Mirar de reojo es muy cómodo.

si:

20 VPC
50 VPC
100 VPC

Su mantenimiento será cada vez más difícil.

Por lo tanto, en términos generales:

Pequeño: Interconexión de VPC Grande: Puerta de enlace de tránsito

24. Método 3: Utilizar directamente el DNS del punto final.

También existe un método muy sencillo, especialmente adecuado para realizar pruebas.

Después de crear un punto final, AWS generará algo como esto:

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

AWS creará nombres DNS regionales y de zona para el punto final de la interfaz.

Por lo tanto, siempre que la red VPC-A pueda alcanzar la VPC compartida, podrá hacerlo directamente:

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

De esta forma, ni siquiera necesitas hacerlo tú mismo:

ssm.ap-northeast-1.amazonaws.com

Private Hosted Zone。

ventaja

Súper fácil.

Ideal para:

Validar enrutamiento, validar SG, validar TGW, validar punto final

defecto

Es necesario modificar la configuración de la aplicación.

original:

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

Ahora se convierte en:

AWS SDK
↓
vpce-xxx....

Muchas aplicaciones no son fáciles de modificar de esta manera.

Por lo tanto, el entorno de producción es generalmente:

PHZ + Alias

mayoría.

25. La mayor ventaja del punto final centralizado

① Reducir significativamente el punto final

Suposición:

20 VPC
15 Interface Endpoints
2 AZ

Distributed：

20 × 15 × 2
=
600 Endpoint AZ instances

Centralización:

15 × 2
=
30

La diferencia es enorme.

26. Ventaja 2: Los costos pueden reducirse significativamente.

Punto final de interfaz recibido:

Endpoint/AZ/hour
+
Data Processing / GB

AWS PrivateLink cobra una tarifa por hora y zona de disponibilidad, además del procesamiento de datos. La tarifa base para el primer PB es de aproximadamente 0,009 €/GB; el precio por hora varía según la región.

Distributed：

VPC × Service × AZ × endpoint-hour

Central：

Service × AZ × endpoint-hour
+
TGW

Cuantas más VPC haya, más significativa será la diferencia en el número de puntos finales.

27. Pero TGW no es gratis.

Muchos diagramas arquitectónicos que se encuentran aquí ignoran deliberadamente este punto.

Transit Gateway recibió:

Tarifa horaria de adjunto + Procesamiento de datos / GB

AWS cobra oficialmente en función del número de horas de conexión y la cantidad de datos que fluyen a través del TGW.

Por lo tanto, lo que realmente debería calcularse es:

Punto final por VPC

Costo = Número de VPC × Número de puntos finales × Número de AZ × Datos de punto final por hora + PrivateLink

Centralized

Costo = Número de puntos finales × Número de AZ × Punto final por hora + conexión TGW por hora + procesamiento de datos TGW + procesamiento de datos PrivateLink + posibles datos entre AZ

entonces:

Si una empresa ya dispone de un TGW (Township Gateway), un punto final central suele ser una opción muy atractiva.

Pero si:

Solo hay 2 VPC, solo 3 puntos finales y ningún TGW.

Construir un TGW específicamente para ahorrar costos en los puntos finales puede no ser rentable.

28. El mayor inconveniente de Centralized: el radio de explosión.

Este es un tema muy importante.

resultan ser:

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

Existe un problema con el punto final A:

Solo A tiene un problema.

Centralización:

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

Punto final central, enrutamiento de VPC compartida, DNS o configuración incorrecta de TGW:

A
B
C
D
E
...

Ambos podrían ser suspendidos.

entonces:

El coste de ahorrar dinero y gestionar los gastos supone un mayor impacto en las infraestructuras compartidas.

AWS también señala específicamente que un punto final centralizado puede ampliar el alcance de las políticas y las repercusiones en caso de fallos.

29. La política de puntos finales también se volverá más compleja.

Distributed：

Punto final de VPC de desarrollo → Permisos de desarrollo Punto final de VPC de producción → Permisos de producción Punto final de VPC de seguridad → Permisos de seguridad

Muy fácil de manejar.

Centralización:

Un punto final KMS para la monitorización de seguridad en entornos de desarrollo, producción y pruebas...

Todo compartido.

Endpoint Policy：

Principal
Resource
Action
Conditions

Se volverá cada vez más complicado.

AWS también ha emitido un recordatorio especial al respecto:

La centralización aumenta la dificultad de gestionar las políticas de privilegios mínimos para los puntos finales, y el alcance de una única política de punto final es mayor; además, el propio documento de política de punto final tiene limitaciones de tamaño.

30. El aislamiento por motivos de seguridad también es un problema.

Por ejemplo:

Production VPC
Development VPC

Todos los usos:

Central S3 Interface Endpoint

A pesar de:

IAM
Bucket Policy
Endpoint Policy
SG

Aún es posible controlar los permisos, pero los límites físicos/de red ya no son completamente independientes.

Por lo tanto, para entornos particularmente exigentes:

Herramientas de seguridad para la producción financiera PCI

Diseños posibles:

Prod Endpoint VPC

NonProd Endpoint VPC

En lugar de toda la empresa:

Una VPC de punto final

31. Estructura empresarial recomendada

No es que solo haya uno en toda la empresa, sino que:

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

incluso:

Security
Production
NonProduction

Cree una VPC de punto final compartido por separado.

De esta forma, podemos tener en cuenta ambos aspectos:

Gestión de costos Seguridad Aislamiento Radio de explosión

32. Otro problema muy práctico: los conflictos de DNS.

Por ejemplo, VPC-A ya tenía el suyo propio:

SSM Endpoint
Private DNS = Enabled

Entonces vuelves a asociar:

ssm.ap-northeast-1.amazonaws.com

Esta es la PHZ central.

Esto podría provocar conflictos en el espacio de nombres DNS.

Por lo tanto, la migración debería ser generalmente:

① Crear un punto final central ② Crear una pHZ central ③ Probar el DNS específico del punto final ④ Asociar la VPC de la red ⑤ Verificar el DNS ⑥ Eliminar el punto final propio de la VPC de la red ⑦ Verificar los servicios ⑧ Migrar a la siguiente VPC

En lugar de eliminarlos todos a la vez.

33. Es posible realizar operaciones entre regiones, pero no se recomienda su uso excesivo.

Por ejemplo:

Tokyo VPC
ap-northeast-1

Osaka VPC
ap-northeast-3

En teoría:

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

AWS también ofrece una arquitectura de punto final centralizado entre regiones, a través de:

TGW Peering
+
Private Hosted Zones

lograr.

Sin embargo, generalmente se recomienda:

Tokyo Endpoint VPC
   ↓
Tokyo VPCs

Osaka Endpoint VPC
   ↓
Osaka VPCs

Es decir:

Una región, una VPC de punto final central.

entonces:

Menor latencia, red más simple, mejor aislamiento ante desastres, menores costos de tráfico entre regiones.

34. Comparación directa de cuatro opciones

proyecto	Punto final por VPC	Peering Central	TGW Central	S3 Gateway
Número de punto final	mucho	pocos	pocos	por VPC
Costos de PrivateLink	alto	Bajo	Bajo	gratis
Costo de TGW	ninguno	ninguno	tener	ninguno
Gestión de DNS	Simple	medio	medio	Es muy sencillo.
complejidad de la red	más bajo	medio	medio	más bajo
VPC a gran escala	❌	❌	✅	✅
Aislamiento	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
Blast Radius	Pequeño	medio	grande	Pequeño
Varias cuentas	Poder	Poder	Muy adecuado	Cada uno creado
Transitive Routing	N/A	❌	✅	N/A
Número recomendado de VPC	1 a una pequeña cantidad	pequeña cantidad	Mediano y grande	cualquier

35. Un diseño adecuado para entornos de gran escala.

Supongamos que la empresa tiene:

30 VPC, 5 cuentas de AWS, región de Tokio

Se puede establecer:

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

Entonces:

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

pero:

S3 Gateway Endpoint
DynamoDB Gateway Endpoint

Todavía se recomienda:

Creado por separado para cada VPC.

Dado que es gratuito, el propio Gateway Endpoint no se puede utilizar desde otras VPC a través de TGW/Peering.

36. Toda la arquitectura puede recordarse como 4 capas.

De hecho, cuando tengas que solucionar problemas en el futuro, solo tendrás que recordar estas cuatro capas:

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

Si no puede acceder, siga estos pasos:

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

Mediante la investigación, generalmente se pueden encontrar los problemas.

La frase más memorable

Un punto final de VPC no se "comparte con varias VPC" a través de la RAM.

La naturaleza centralizada de los puntos finales de interfaz es:

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

Aprobado de nuevo:

Route53 Private Hosted Zone

En todas las VPC:

ssm.ap-northeast-1.amazonaws.com

Todos fueron analizados y resultaron ser:

Central VPC Endpoint

Con esto finaliza todo el proceso. Shared/Centralized VPC Endpoint。

y No hagas esto con los puntos finales de puerta de enlace de S3/DynamoDB; crea el tuyo propio para cada VPC.Porque es gratuito y AWS prohíbe explícitamente su uso desde el otro extremo, como TGW o Peering.