Partage d'un point d'extrémité VPC sur plusieurs VPC: un guide complet d'architecture et de mise en œuvre

️ Topologie de base

                         AWS SERVICES
                               ▲
                               │
                         PrivateLink
                               │
             ┌──────────────────────────┐
             │ NETWORK ACCOUNT          │
             │ Central Endpoint VPC     │
             │                          │
             │ AZ-A             AZ-C    │
             │ VPCE ENI         VPCE ENI│
             │                          │
             │ SSM / KMS / STS / ECR    │
             │ Secrets / CloudWatch     │
             │ SNS / SQS / EC2 API      │
             │ Route 53 Profile         │
             └────────────┬─────────────┘
                          │
                    Transit Gateway
               ┌──────────┼───────────┐
               │          │           │
             PROD        DEV         TEST
               │          │           │
            VPC-A       VPC-B       VPC-C
               │          │           │
        S3 Gateway   S3 Gateway   S3 Gateway
        DDB Gateway  DDB Gateway  DDB Gateway

Quatre services de base

• Points d'extrémité VPC AWS PrivateLink / interface: Fournir une connectivité privée des VPC de l'application aux services AWS régionaux.
• Portée de transit AWS: Connecte le VPC de point final à plusieurs VPC d'application, tandis que les tables de route TGW contrôlent la facilité d'accès.
• Profiles de la route 53: Gérez de manière centralisée le DNS privé de l'interface d'extrémité et associez cette configuration DNS à plusieurs VPC.
• RAM de l'AWS: Partage les profils Transit Gateway et Route 53 sur les comptes AWS.

Lorsqu'un centre de données sur place est impliqué

Lorsque le réseau local atteint AWS via VPN ou Direct Connect, ajoutez un point d'extrémité entrant de la Route 53 Resolver afin que le DNS local puisse rediriger les noms de services AWS vers la Route 53 Resolver. N'envoyez pas de requêtes directement à l'adresse du résolveur CIDR + 2 d'un VPC.

1️ Créer un VPC dédié au point final

• Créer Endpoint-VPC dans un compte de réseau ou de services partagés. Cet exemple utilise 10.100.0.0/16.
• Utiliser au moins deux AZ dans la production, tels que 10.100.10.0/24 dans l'AZ-a et 10.100.20.0/24 dans AZ-c, avec un sous-réseau de point d'extrémité dans chacun.
• Un point d'extrémité d'interface crée un ENI dans chaque sous-réseau de point d'extrémité sélectionné.
• Évitez de placer des terminaux partagés dans une application VPC arbitraire, où la propriété du réseau, les limites d'accès et la réponse aux incidents sont liés à une seule charge de travail.

2️ Ajouter une passerelle de transit ou un parallèle VPC

• Créer une passerelle de transit centrale et des pièces jointes VPC pour le point final VPC, VPC-A, VPC-B et VPC-C.
• Dans un environnement multi-comptes, partagez le TGW via la RAM AWS, puis laissez les comptes d'application créer ou accepter les pièces jointes.
• Pour seulement deux ou trois VPCs d'application, comparez chacun directement avec le VPC Endpoint pour éviter une autre couche de réseau et des charges TGW.
• Le peering n'est pas transitif. À mesure que l'environnement augmente, la connexion et l'expansion des tables de route rendent le modèle TGW de hub-and-spoke plus pratique.

3️ Application des tables de parcours VPC

Chaque sous-réseau d'application qui a besoin d'un point d'extrémité doit rediriger le CIDR VPC du point d'extrémité vers le TGW. Pour le VPC-A:

Destination       Target
10.1.0.0/16       local
10.100.0.0/16     tgw-xxxx

VPC-B et VPC-C envoient également 10.100.0.0/16 Avec le peering, utilisez la connexion de peering appropriée comme cible.

4️ Routes de retour dans le point final VPC

La table des itinéraires associée aux sous-réseaux de points d'arrêt doit renvoyer le trafic à chaque application VPC:

10.100.0.0/16      local
10.1.0.0/16        tgw-xxxx
10.2.0.0/16        tgw-xxxx
10.3.0.0/16        tgw-xxxx

Les deux directions sont requises. Un itinéraire avant sans itinéraire de retour produit généralement un TCP SYN sans SYN/ACK et finalement un temps de connexion.

5️ Tableaux des itinéraires du TGW

• Les itinéraires associés à l'application doivent être envoyés par les VPC 10.100.0.0/16 à l'annexe VPC du point final.
• Sur le côté VPC du point final, les itinéraires pour 10.1.0.0/16, 10.2.0.0/16, et 10.3.0.0/16 doivent indiquer leurs pièces jointes respectives du VPC.
• Les environnements avec une segmentation stricte utilisent souvent plusieurs tables de itinéraires TGW pour contrôler explicitement la propagation.

6️ Créer des terminaux de service dans le VPC de terminaux

• Ouvrez VPC → Endpoints → Créez un endpoint et choisissez le service régional, tel que com.amazonaws.ap-northeast-1.ssm pour le directeur des systèmes à Tokyo.
• Sélectionner Endpoint-VPC et les deux sous-réseaux endpoint-subnet-a et endpoint-subnet-c.
• Avec la conception de la Route 53 Profiles, gardez DNS privé activé. Les SDK AWS et les CLI peuvent continuer à utiliser des noms de service standard tout en les résolvant à des adresses privées PrivateLink.
• Créer uniquement les terminaux requis par les charges de travail réelles. Chaque terminaux d'interface ajoute des frais d'heure AZ et de traitement de données.

Endpoints centraux communs

• Gestionnaire des systèmes: SSM, SSM Messages et EC2 Messages.
• Les services de base: API EC2, KMS, Gestionnaire de secrets, STS, Lambda et EventBridge.
• Surveillance et messagerie: CloudWatch, CloudWatch Logs, SNS et SQS.
• Containers et livraison: API ECR, DKR ECR, ECS et CodeArtifact.
• Accès à l'application: services PrivateLink pris en charge tels que API Gateway execute-api.

7️ Groupe de sécurité des points d'arrêt

• Créer un groupe de sécurité dédié aux ENI des points finaux, tels que: sg-vpce-central.
• Permettre HTTPS entrant sur TCP 443 uniquement à partir des CIDR d'application qui nécessitent un accès, tels que 10.1.0.0/16, 10.2.0.0/16, et 10.3.0.0/16.
• Ne laissez pas 0.0.0.0/0 réduire la source en fonction de l'organisation, de l'environnement, de la sensibilité ou du point d'extrémité dédié, le cas échéant.
• Les groupes de sécurité sont étatiques, mais les règles de sortie d'instance, les NACL et les appareils intermédiaires doivent toujours autoriser TCP 443 et retourner le trafic.

8️ Politique des points d'extrémité

• La politique des points d'extrémité contrôle quels principaux responsables peuvent effectuer quelles actions de service à travers ce point d'entrée. Une politique d'accès complet est utile pour les tests de connectivité, et non pas en tant que défaut de production à long terme.
• Un terminal KMS peut être limité à des comptes approuvés, des rôles IAM et des clés KMS. Appliquez également des clés de condition et des restrictions de ressources à d'autres services.
• L'autorisation efficace est la combinaison de politiques de point d'extrémité, de politiques IAM, de SCP, de politiques de ressources et de politiques telles que les politiques de seau ou de clés.
• Les politiques de moindre privilège deviennent plus complexes à mesure que de plus en plus de PCV partagent un point d'extrémité et que les limites de taille des documents de politique sont toujours applicables.

Responsabilités du compte

AWS Organizations

Network Account
├ Endpoint VPC
├ Transit Gateway
└ Route 53 Profile

Production Account
├ VPC-A
└ VPC-B

Development Account
├ VPC-C
└ VPC-D

Security Account
└ VPC-E

• Le compte réseau partage le profil Route 53 via la RAM AWS avec la production, le développement, la sécurité et d'autres comptes dans la même région.
• Chaque compte associe ses VPCs au profil partagé, réutilisant le DNS d'endpoint centralisé sans créer une zone d'hébergement privée pour chaque service et VPC.
• Cette division s'adapte aux modèles d'exploitation AWS Organisations, Control Tower et Landing Zone: l'équipe réseau possède des VPCE, DNS, TGW et logging, tandis que les équipes d'application possèdent des ressources informatiques et de charge de travail.

1 Résolution DNS

Lorsqu'une instance EC2 à 10.1.10.50 dans les appels VPC-A Secrets Manager, le SDK regarde vers le haut secretsmanager.ap-northeast-1.amazonaws.com. Route 53 Resolver et le profil associé renvoient les adresses privées du VPCE centralisé.

EC2 → Route 53 Resolver → Route 53 Profile
    → VPCE Private DNS → 10.100.10.25 / 10.100.20.25

2 Voie du réseau

10.1.10.50
    │ HTTPS 443
    ▼
VPC-A Route Table
    ▼
Transit Gateway
    ▼
Endpoint VPC
    ▼
VPCE ENI 10.100.10.25
    ▼
AWS PrivateLink
    ▼
Secrets Manager

Ce chemin vers le service AWS reste privé et ne nécessite pas de passerelle NAT ou de passerelle Internet. La demande doit encore passer à la fois les contrôles de réseau et l'autorisation d'identité.

• Lorsque l'ECS, l'ECS ou l'EC2 extrait une image de l'ECR, ecr.api le seul n'est généralement pas suffisant; ecr.dkr est également requise.
• Les couches d'image du conteneur sont soutenues par S3, de sorte que les tirages peuvent toujours échouer même lorsque les deux extrémités de l'interface ECR existent.
• Une conception typique centralisera les points d'extrémité d'interface ECR API et ECR DKR tout en créant un point d'extrémité de passerelle S3 dans chaque VPC d'application.
• Lorsque la résolution des problèmes d'image s'arrête, vérifiez le DNS, les deux points d'extrémité ECR, le point d'extrémité de passerelle S3, le routage, les groupes de sécurité et les autorisations IAM de la tâche ou de l'instance.

Une conception traditionnelle qui fonctionne toujours

• Désactivez le DNS privé sur le point d'extrémité de l'interface centralisée.
• Créer manuellement une zone d'hébergement privée de la route 53 correspondant au nom du service AWS, par exemple ssm.ap-northeast-1.amazonaws.com.
• Créez un enregistrement A alias pointant vers le VPCE, puis associez le PHZ au VPC du point final et à chaque VPC de l'application.

Pourquoi ce n'est plus le premier choix pour de nouveaux environnements

• Avec 30 points d'extrémité et 100 VPC, les associations manuelles de PHZ se transforment en une très grande matrice de gestion.
• Route 53 Les profils peuvent associer tous les VPCE centralisés une fois, puis appliquer la configuration à de nombreux VPC, réduisant les zones, les enregistrements et les associations hébergés répétés.
• L'approche traditionnelle reste utile pour les systèmes existants ou les exigences DNS spécialisées; évaluer d'abord les profils de route 53 pour les déploiements de champs verts.

Components de coûts centralisés

• Les frais horaires de connexion à la passerelle de transit.
• Les frais de traitement des données de la passerelle de transit.
• Frais horaires des terminaux d'interface pour chaque AZ déployé.
• Traitement des données par PrivateLink, ainsi que les éventuels frais de transfert de données entre Zones ou Régions.

Quand la centralisation est plus susceptible d'économiser de l'argent

Le cas d'affaires le plus fort apparaît lorsqu'il y a beaucoup de VPC, beaucoup de points d'extrémité requis et un trafic relativement faible par VPC. Avec 50 VPC, 20 services et deux AZ, une conception distribuée peut créer 2 000 ENI de points d'extrémité, contre environ 40 dans une conception centralisée.

Les personnes chargées de travaux à grande vitesse ont besoin de leurs propres calculs

Si un VPC déplace plusieurs Tb de données S3 chaque jour, l'envoi par TGW à un point d'extrémité d'interface S3 est souvent une mauvaise valeur. Un point d'extrémité de passerelle S3 local est généralement la meilleure conception. Les prix AWS varient selon la région et au fil du temps, alors construisez le budget à partir des prix régionaux actuels et comparez tout en dollars américains.

13 VPC

• Commencez par des points d'extrémité dans chaque VPC pour l'architecture la plus simple et l'isolement le plus fort.
• Si la réduction du nombre de points d'extrémité est importante, utilisez le peering, un profil de route 53 et un petit VPC du point d'extrémité central.
• L'introduction de Transit Gateway uniquement pour partager quelques endpoints est généralement inutile.

520 VPC

• Évaluer sérieusement les profils VPC + TGW + Route 53.
• Comparer les frais fixes du terminal, les frais du TGW et le volume réel du trafic dans le modèle de coûts.
• Garder des terminaux dédiés pour des charges de travail à volume élevé ou fortement isolées, créant ainsi une conception hybride.

20 à des centaines de VPC

• Un compte réseau centralisera généralement TGW ou Cloud WAN, les VPC d'endpoint, les profils de route 53, le résolveur, le pare-feu réseau et le pare-feu DNS.
• Gérer les points d'extrémité et les associations de compte avec l'infrastructure comme le code, les balises standard, les journaux, la surveillance et les contrôles formels des changements.
• Divisez les ressources par région, environnement et limite de confiance afin que chaque charge de travail ne dépend pas d'une seule pile centrale.

1. D.N.S.Retour: dig ssm.ap-northeast-1.amazonaws.comIl devrait renvoyer une adresse privée VPCE telle que: 10.100.x.xCe n'est pas une IP publique.
2. Tableau des itinéraires de VPC par écrit: Confirmer que le point final VPC CIDR pointe vers TGW ou peering.
3. Tableau des itinéraires TGW: Vérifiez les itinéraires de l'application VPC au point final VPC et de retour.
4. Tableau des itinéraires VPC des points d'extrémité: Assurez-vous que les sous-réseaux Endpoint peuvent renvoyer le trafic à chaque application VPC.
5. Groupe de sécurité VPCE: Vérifiez que TCP 443 est autorisé à partir des CIDR de l'application.
6. NACL: Vérifiez les portes entrantes, sortantes et éphémères.
7. Politique des points d'achèvement: Confirmer que le principal, l'action et la ressource ne sont pas refusés.
8. IAM / politique en matière de ressources / SCP: Enfin, examinez les autorisations d'identité, les politiques en matière de ressources et les contrôles au niveau de l'organisation.

Travailler dans l'ordre de résolution, de routage, de contrôle de réseau et d'autorisation est beaucoup plus rapide que de sauter au hasard entre les pages de console.