Partager des AWS VPC Endpoints entre plusieurs VPC : guide de l'architecture et de la configuration centralisées

📅 2026-08-21
📍 AWS Centralized VPC Endpoint
⏱️ Temps de lecture : environ 35 minutes

Point de terminaison d'interface | Passerelle de transit | Appairage VPC | Route 53 | Inter-comptes | Coût et sécurité

Dans AWS, le principe du « partage d'un point de terminaison VPC entre différents VPC » ne consiste pas simplement à attacher un point de terminaison directement à plusieurs VPC, mais plutôt :

Centralisez les points de terminaison VPC d'interface dans un seul VPC de services centralisés/partagés, puis autorisez d'autres VPC à accéder à l'adresse IP privée de ce point de terminaison via une passerelle de transit ou un peering VPC, tout en utilisant Route 53 pour unifier le DNS.

AWS désigne officiellement ce modèle comme... Centralized access to VPC private endpoints。

Mais il est essentiel, avant tout, de faire la distinction entre eux. Interface Endpoint et Gateway Endpoint。

Commençons par énoncer la conclusion la plus importante.

Supposons que vous ayez actuellement :

VPC-A
VPC-B
VPC-C

Les trois VPC nécessitent :

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

Vous avez deux modèles.

Option A : Chaque VPC crée son propre point de terminaison.

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

Il s'agit du modèle le plus simple et le plus isolé.

Cependant, le nombre de points de terminaison va augmenter rapidement.

Par exemple:

10 VPC × 20 points de terminaison de service AWS × 2 zones de disponibilité = 400 interfaces réseau de points de terminaison

Le point de terminaison d'interface est basé sur Point d'arrivée × AZ × HeureDes frais s'appliquent, auxquels s'ajoutent des frais de traitement des données.

Par conséquent, à mesure que l'échelle augmente, les coûts et la maintenance augmenteront considérablement.

II. Architecture du point de terminaison VPC centralisé

Établir un :

Network VPC / Shared Services VPC

Tous les points d'accès sont placés ici.

Par exemple:

                  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

alors:

EC2 dans VPC-A ↓ ssm.ap-northeast-1.amazonaws.com ↓ Route 53 ↓ Résolution en adresse IP privée du point de terminaison SSM dans le VPC partagé ↓ Passerelle de transit ↓ Interface de point de terminaison ENI ↓ AWS PrivateLink ↓ SSM

AWS soutient officiellement cette conception centralisée.

III. Une exception particulièrement importante : S3 / DynamoDB

Cela doit être discuté séparément.

Les points de terminaison de passerelle ne peuvent pas être partagés de cette manière.

S3 et DynamoDB ont :

Gateway VPC Endpoint

Par exemple:

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

Il est complètement différent d'un point de terminaison d'interface classique.

Gateway Endpoint：

  • N'utilisez pas PrivateLink
  • Ne créez pas d'ENI
  • Il s'agit essentiellement d'une combinaison de table de routage et de liste de préfixes gérée par AWS.
  • gratuit
  • Il ne peut être utilisé que par le VPC dans lequel il réside.

AWS a officiellement déclaré :

Les points de terminaison de passerelle ne peuvent pas s'étendre au-delà du VPC ; les ressources provenant de l'autre extrémité d'un appariement VPC, d'une passerelle de transit, d'un VPN ou d'une connexion directe ne peuvent pas emprunter à ce point de terminaison de passerelle.

Par conséquent, il ne doit pas être conçu comme suit :

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

Nous souhaitons ensuite que VPC-A utilise le point de terminaison de passerelle S3 du VPC partagé.

Non.

IV. Bonnes pratiques pour S3 / DynamoDB

Normalement, cela devrait être :

VPC-A → Votre propre point de terminaison de passerelle S3 VPC-B → Votre propre point de terminaison de passerelle S3 VPC-C → Votre propre point de terminaison de passerelle S3

parce que:

Les points d'accès de la passerelle ne font l'objet d'aucun frais supplémentaire.

Il n’est donc pas nécessaire de centraliser le point de terminaison de la passerelle S3 afin de « réduire le nombre de points de terminaison ».

recommander:

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

et:

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

Ces Interface VPC Endpoint C'est ce qui rend la centralisation appropriée.

5. Pourquoi un point de terminaison d'interface peut-il être utilisé sur plusieurs VPC ?

Parce qu'un point de terminaison d'interface est essentiellement :

Créez une ENI avec une adresse IP privée dans votre sous-réseau spécifié.

Selon la documentation officielle d'AWS, un point de terminaison d'interface crée une interface réseau de point de terminaison dans le sous-réseau que vous choisissez et attribue une adresse IP privée à ce sous-réseau.

Par exemple:

Shared VPC
10.0.0.0/16

AZ-a:
Endpoint ENI
10.0.10.50

AZ-c:
Endpoint ENI
10.0.20.60

Pour l'autre VPC, tant que :

VPC-A → Peut router vers 10.0.10.50

et:

Le groupe de sécurité 10.0.10.50 autorise VPC-A

En réalité, le réseau peut déjà accéder au point de terminaison.

Par conséquent, les soi-disant :

Point de terminaison VPC partagé

Voici ce qui s'est réellement passé :

Autres VPC ↓ Réseau inter-VPC ↓ Accès au point de terminaison ENI du VPC central

Non:

Un vpce-xxx peut être connecté simultanément à trois VPC.

Ce sont deux concepts complètement différents.

VI. Trois méthodes pratiques de mise en œuvre

En réalité, on peut la diviser en trois types.

méthode Niveau de recommandation Approprié
Transit Gateway ⭐⭐⭐⭐⭐ VPC multi-échelle
VPC Peering ⭐⭐⭐⭐ 2 à 5 VPC
Utilisez directement le DNS de point de terminaison ⭐⭐⭐ Application de test/spéciale
Point de terminaison indépendant par VPC ⭐⭐⭐⭐⭐ Privilégier l'isolement à petite échelle

VII. Méthode 1 : Passerelle de transit + Point d'extrémité central

Il s'agit de la solution la plus courante pour les environnements d'entreprise.

En supposant qu'il s'agisse de la région de Tokyo :

ap-northeast-1

réseau:

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

Architecture:

                       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 conçu par AWS pour le routage centralisé sur plusieurs VPC et prend en charge le routage transitoire ; AWS recommande également de privilégier TGW pour les réseaux multi-VPC à grande échelle.

VIII. Procédures opérationnelles spécifiques

Voici le détail de la configuration réelle.

Étape 1 : Créer un VPC réseau

Par exemple:

VPC:
shared-endpoint-vpc

CIDR:
10.0.0.0/16

Deux AZ :

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

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

Il est recommandé d'avoir au moins 2 AZ.

9. Étape 2 : Créer une passerelle de transit

VPC Console：

Transit Gateways
→ Create transit gateway

Par exemple:

Name:
core-tgw

Créez ensuite une pièce jointe VPC :

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

Si vous possédez plusieurs comptes AWS, vous pouvez également partager la passerelle de transit via AWS RAM. AWS prend officiellement en charge le partage de la passerelle de transit entre comptes.

10. Étape 3 : Configurer la table de routage VPC

Hypothèse:

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

Sinon, voici ce qui se produira :

VPC-A → Endpoint

Vous pouvez y aller, mais :

Endpoint → VPC-A

Ils ne peuvent pas revenir.

11. Étape 4 : Configurer la table de routage 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

S'il n'y a pas de besoin particulier d'isolation du réseau, la propagation des routes peut être utilisée.

L'environnement de l'entreprise est généralement défaillant :

Spoke TGW RT
Shared Services TGW RT
Inspection TGW RT

Évitez d'autoriser par défaut la communication entre tous les VPC.

12. Étape 5 : Créer un point de terminaison d’interface

Par exemple, si le partage est requis :

AWS Systems Manager

créer:

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

Il en résulte donc ce qui suit :

vpce-0123456789

ENI-A:
10.0.10.50

ENI-C:
10.0.20.50

Treizièmement, et surtout : n’activez pas directement le DNS privé.

Lorsqu'un VPC utilise normalement son propre point de terminaison :

Enable Private DNS
✓

Très pratique.

Par exemple, à l'origine :

ssm.ap-northeast-1.amazonaws.com

Il sera automatiquement analysé comme suit :

10.0.10.50
10.0.20.50

Le kit de développement logiciel AWS (AWS SDK) ne nécessite absolument aucune modification.

Cependant, l'architecture centralisée présente un problème.

Le DNS privé crée automatiquement une zone hébergée privée gérée par AWS, qui ne fonctionne qu'au sein du VPC où se trouve le point de terminaison.

donc:

Shared VPC

Savoir:

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

mais:

VPC-A
VPC-B

Je ne sais pas.

Par conséquent, l'architecture officielle de point de terminaison central d'AWS recommande :

Dans le scénario de point de terminaison central, désactivez le DNS privé automatique pour le point de terminaison, puis créez manuellement la zone hébergée privée Route 53.

14. Étape 6 : Créer une zone hébergée privée Route 53

créer:

Route 53
→ Hosted zones
→ Create hosted zone

Domain：

ssm.ap-northeast-1.amazonaws.com

Type：

Private Hosted Zone

Premièrement, associez-vous :

shared-endpoint-vpc

15. Étape 7 : Créer un alias

Entrer:

ssm.ap-northeast-1.amazonaws.com

Create record。

Record：

ssm.ap-northeast-1.amazonaws.com

Type：

A

choisir:

Alias

Sélection de la cible :

VPC Endpoint

Alors:

vpce-0123456789...

La solution officielle de point de terminaison central d'AWS est :

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

Au lieu de configurer manuellement l'application pour qu'elle utilise l'adresse IP du point de terminaison.

16. Étape 8 : Associer PHZ à tous les VPC

Private Hosted Zone：

ssm.ap-northeast-1.amazonaws.com

En rapport:

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

Une zone hébergée privée dans AWS Route 53 peut être associée à plusieurs VPC.

alors:

VPC-A

mettre en œuvre:

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

obtenir:

10.0.10.50
10.0.20.50

VPC-B

même:

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

Aussi:

10.0.10.50
10.0.20.50

À l'heure actuelle :

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

Voilà qui conclut l'histoire.

17. Étape 9 : Groupe de sécurité des points de terminaison

Voici le deuxième piège très courant.

Le point de terminaison ENI possède un groupe de sécurité.

Par exemple:

endpoint-sg

Inbound：

HTTPS
TCP 443

Source:
10.10.0.0/16
10.20.0.0/16
10.30.0.0/16

On peut même le rendre encore plus fin.

Par exemple, seulement :

10.10.10.0/24
10.20.20.0/24

Autoriser l'accès au point de terminaison.

Si le passage n'est pas autorisé ici :

DNS OK
Routing OK
TGW OK

toujours:

timeout

18. Flux de données final

Par exemple, EC2 dans VPC-A :

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

Requête 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

Les éléments suivants ne sont pas requis tout au long du processus :

Internet Gateway
NAT Gateway
Public IP

C'est là l'un de ses principaux avantages. L'objectif de PrivateLink est de permettre l'accès aux services AWS via un réseau privé, sans avoir recours à une passerelle Internet (IGW), à la traduction d'adresses réseau (NAT) ou à des adresses IP publiques.

19. Comment gérer plusieurs points de terminaison ?

Supposons que vous ayez besoin de :

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

Puis PHZ associe simultanément :

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

Certains services AWS possèdent des structures DNS spécifiques, comme les points de terminaison ECR Docker/OCI. AWS précise également que certains services peuvent nécessiter des alias génériques ; il est donc impossible de supposer que tous les points de terminaison ne possèdent qu’un seul enregistrement DNS simple.

20. Que se passe-t-il s'il s'agit de comptes AWS différents ?

Par exemple:

Network Account
111111111111

App Account A
222222222222

App Account B
333333333333

L'architecture est parfaitement acceptable.

recommander:

AWS Organizations

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

       ↓ AWS RAM

App Account A
 └─ VPC-A

App Account B
 └─ VPC-B

TGW est accessible via :

AWS Resource Access Manager

partager.

Les associations entre comptes pour les zones hébergées privées sont un peu plus compliquées.

21. Association PHZ inter-comptes

Par exemple:

Network Account:
PHZ Z123456

App Account:
VPC vpc-abcdef

Premier compte réseau :

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

Compte d'application :

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

La procédure officielle d'AWS pour les zones hébergées privées inter-comptes est la suivante :

PHZ Owner
↓
CreateVPCAssociationAuthorization

VPC Owner
↓
AssociateVPCWithHostedZone

De plus, cette opération inter-comptes ne peut pas être entièrement réalisée en s'appuyant sur la console Route 53 ; elle nécessite une interface de ligne de commande (CLI), une API ou un kit de développement logiciel (SDK).

22. Méthode 2 : Interconnexion VPC

Si vous n'avez que deux ou trois VPC, vous n'avez pas forcément besoin d'un TGW.

Par exemple:

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

Configuration:

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

Alors:

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 toujours :

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

23. Le plus grand inconvénient du peering

il:

Le routage transitif n'est pas pris en charge.

AWS l'a clairement indiqué dans des déclarations officielles.

Par exemple:

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

On ne peut donc pas en conclure que :

A → Central → B

C'est possible.

Par conséquent, si :

2 VPC
3 VPC

L'observation est très confortable.

si:

20 VPC
50 VPC
100 VPC

Son entretien deviendra de plus en plus difficile.

Donc, d'une manière générale :

Petit : Interconnexion VPC Grand : Passerelle de transit

24. Méthode 3 : Utilisation directe du DNS du point de terminaison

Il existe également une méthode très simple, particulièrement adaptée aux tests.

Après la création d'un point de terminaison, AWS générera un élément similaire à celui-ci :

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

AWS créera des noms DNS régionaux et de zone pour le point de terminaison d'interface.

Par conséquent, tant que le réseau VPC-A peut atteindre le VPC partagé, il peut directement :

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

Ainsi, vous n'aurez même pas besoin de le faire vous-même :

ssm.ap-northeast-1.amazonaws.com

Private Hosted Zone。

avantage

Super facile.

Idéal pour :

Valider le routage, valider le SG, valider le TGW, valider le point de terminaison

défaut

La configuration de l'application doit être modifiée.

original:

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

Cela devient maintenant :

AWS SDK
↓
vpce-xxx....

De nombreuses applications ne se prêtent pas facilement à cette modification.

Par conséquent, l'environnement de production est généralement :

PHZ + Alias

la plupart.

25. Le principal avantage du point de terminaison centralisé

① Réduire significativement le point final

Hypothèse:

20 VPC
15 Interface Endpoints
2 AZ

Distributed：

20 × 15 × 2
=
600 Endpoint AZ instances

Centralisation:

15 × 2
=
30

La différence est énorme.

26. Avantage 2 : Les coûts peuvent être considérablement réduits.

Point de terminaison d'interface reçu :

Endpoint/AZ/hour
+
Data Processing / GB

AWS PrivateLink facture un tarif horaire par zone de disponibilité, auquel s'ajoutent les frais de traitement des données. Le tarif de base pour le premier pétaoctet est d'environ 0,009 €/Go ; le prix horaire varie selon la région.

Distributed：

VPC × Service × AZ × endpoint-hour

Central：

Service × AZ × endpoint-hour
+
TGW

Plus il y a de VPC, plus la différence dans le nombre de points de terminaison est significative.

27. Mais TGW n'est pas gratuit.

De nombreux schémas d'architecture présentés ici ignorent délibérément ce point.

Transit Gateway a reçu :

Tarif horaire pour pièces jointes + Traitement des données / Go

AWS facture officiellement en fonction du nombre d'heures de connexion et du volume de données transitant par le TGW.

Par conséquent, ce qu'il faudrait réellement calculer, c'est :

Point de terminaison par VPC

Coût = Nombre de VPC × Nombre de points de terminaison × Nombre de zones de disponibilité × Coût horaire par point de terminaison + Données PrivateLink

Centralized

Coût = Nombre de points de terminaison × Nombre de zones de disponibilité × Coût horaire par point de terminaison + Coût horaire de la connexion TGW + Traitement des données TGW + Traitement des données PrivateLink + Données inter-zones potentielles

donc:

Si une entreprise possède déjà un TGW (Township Gateway), un point de terminaison central est généralement très intéressant.

Mais si :

Il n'y a que 2 VPC, seulement 3 points de terminaison et pas de TGW.

La mise en place d'une passerelle de transfert (TGW) spécifiquement pour réduire les coûts des terminaux peut ne pas être rentable.

28. Le plus gros inconvénient de Centralized : le rayon d'explosion

C'est une question très importante.

s'avèrent être :

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

Il y a un problème avec le point de terminaison A :

Seul A a un problème.

Centralisation:

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

Mauvaise configuration du point de terminaison central, du routage VPC partagé, du DNS ou de la passerelle de transfert :

A
B
C
D
E
...

Ils pourraient tous les deux être suspendus.

donc:

Le coût des économies et de la gestion des coûts se traduit par un rayon d'action accru pour les infrastructures partagées.

AWS souligne également qu'un point de terminaison central peut élargir la portée des impacts des politiques et des défaillances.

29. La politique relative aux points de terminaison deviendra également plus complexe.

Distributed：

Point de terminaison VPC de développement → Autorisations de développement Point de terminaison VPC de production → Autorisations de production Point de terminaison VPC de sécurité → Autorisations de sécurité

Très facile à gérer.

Centralisation:

Un point de terminaison KMS pour la surveillance de la sécurité des environnements de développement, de production et de test...

Tout est partagé.

Endpoint Policy：

Principal
Resource
Action
Conditions

Cela va devenir de plus en plus compliqué.

AWS a également publié un rappel spécial à ce sujet :

La centralisation accroît la difficulté de gérer les politiques de points de terminaison à privilèges minimaux, et le rayon d'action d'une politique de point de terminaison unique est plus grand ; le document de politique de point de terminaison lui-même a également des limites de taille.

30. L'isolation de sécurité pose également problème.

Par exemple:

Production VPC
Development VPC

Tous les usages :

Central S3 Interface Endpoint

Bien que:

IAM
Bucket Policy
Endpoint Policy
SG

Les autorisations peuvent toujours être contrôlées, mais les limites physiques et réseau ne sont plus totalement indépendantes.

Par conséquent, pour les environnements particulièrement exigeants :

Outils de sécurité de la production financière PCI

Conceptions possibles :

Prod Endpoint VPC

NonProd Endpoint VPC

Au lieu de toute l'entreprise :

Un VPC de point de terminaison

31. Structure d'entreprise recommandée

Ce n'est pas qu'il n'y en ait qu'un seul dans toute l'entreprise, mais plutôt :

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

même:

Security
Production
NonProduction

Créez un VPC de point de terminaison partagé séparément.

De cette façon, nous pouvons prendre les deux en compte :

Gestion des coûts Sécurité Isolation Rayon d'explosion

32. Un autre problème très pratique : les conflits DNS.

Par exemple, VPC-A possédait déjà le sien :

SSM Endpoint
Private DNS = Enabled

Puis vous vous associez à nouveau :

ssm.ap-northeast-1.amazonaws.com

Il s'agit du PHZ central.

Cela pourrait entraîner des conflits d'espace de noms DNS.

Par conséquent, la migration devrait généralement être :

① Créer un point de terminaison central ② Créer une zone de disponibilité centrale (pHZ) ③ Tester le DNS spécifique au point de terminaison ④ Associer le VPC distant ⑤ Vérifier le DNS ⑥ Supprimer le point de terminaison du VPC distant ⑦ Vérifier les services ⑧ Migrer vers le VPC suivant

Au lieu de tous les supprimer en même temps.

33. Les opérations interrégionales sont possibles, mais leur utilisation excessive n’est pas recommandée.

Par exemple:

Tokyo VPC
ap-northeast-1

Osaka VPC
ap-northeast-3

Théoriquement:

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

AWS propose également une architecture de point de terminaison centralisée interrégionale, via :

TGW Peering
+
Private Hosted Zones

accomplir.

Toutefois, il est généralement recommandé de :

Tokyo Endpoint VPC
   ↓
Tokyo VPCs

Osaka Endpoint VPC
   ↓
Osaka VPCs

C'est-à-dire :

Une région, un VPC de point de terminaison central.

donc:

Latence réduite, réseau simplifié, meilleure isolation en cas de sinistre, coûts de trafic interrégional réduits

34. Comparaison directe de quatre options

projet Point de terminaison par VPC Peering Central TGW Central S3 Gateway
Numéro du point de terminaison beaucoup de peu peu par VPC
Coûts de PrivateLink haut Faible Faible gratuit
Coût TGW aucun aucun avoir aucun
Gestion DNS Simple moyen moyen C'est très simple.
Complexité du réseau le plus bas moyen moyen le plus bas
VPC à grande échelle ❌ ❌ ✅ ✅
Isolement ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐
Blast Radius Petit milieu grand Petit
Comptes multiples Peut Peut Très approprié Chaque créé
Transitive Routing N/A ❌ ✅ N/A
Nombre de VPC recommandé 1 à une petite quantité petite quantité Moyen et grand n'importe lequel

35. Une conception adaptée aux environnements à grande échelle

Supposons que l'entreprise ait :

30 VPC, 5 comptes AWS, région de Tokyo

Il est possible d'établir :

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

Alors:

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

mais:

S3 Gateway Endpoint
DynamoDB Gateway Endpoint

Il est toujours recommandé :

Créé séparément pour chaque VPC

Parce que c'est gratuit, et que le point de terminaison de passerelle lui-même ne peut pas être utilisé depuis d'autres VPC via TGW/Peering.

36. L'architecture entière peut être mémorisée comme 4 couches.

En fait, lorsque vous devrez résoudre des problèmes à l'avenir, vous n'aurez besoin de vous souvenir que de ces quatre niveaux :

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

Si l'accès est indisponible, veuillez suivre les étapes suivantes :

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

Une enquête permet généralement de déceler les problèmes.

La phrase la plus mémorable

Un point de terminaison VPC n'est pas lui-même « partagé avec plusieurs VPC » via la RAM.

La nature centralisée des points de terminaison d'interface est :

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

Adopté à nouveau :

Route53 Private Hosted Zone

Dans tous les VPC :

ssm.ap-northeast-1.amazonaws.com

Tous ont été analysés comme étant :

Central VPC Endpoint

Ceci achève le processus. Shared/Centralized VPC Endpoint。

et N'utilisez pas les points de terminaison de passerelle S3/DynamoDB pour cela ; créez les vôtres pour chaque VPC.Parce que c'est gratuit, et qu'AWS interdit explicitement son utilisation depuis l'autre extrémité, par exemple via TGW ou Peering.