View a markdown version of this page

Automatisez la configuration du peering interrégional avec AWS Transit Gateway - Recommandations AWS
RésuméConditions préalables et limitationsArchitectureOutilsÉpopéesRessources connexes

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Automatisez la configuration du peering interrégional avec AWS Transit Gateway

Ram Kandaswamy, Amazon Web Services

Résumé

AWS Transit Gatewayconnecte les clouds privés virtuels (VPCs) et les réseaux sur site via un hub central. Le trafic Transit Gateway ne traverse pas l'Internet public, ce qui réduit les vecteurs de menaces, tels que les exploits courants et les attaques par déni de service (DDoS) distribué.

Si vous avez besoin de communiquer entre deux ou plusieurs Régions AWS, vous pouvez utiliser le peering inter-region Transit Gateway pour établir des connexions de peering entre les passerelles de transit de différentes régions. Cependant, la configuration manuelle du peering interrégional avec Transit Gateway peut s'avérer complexe et fastidieuse. Ce modèle fournit des conseils pour l'utilisation de l'infrastructure en tant que code (IaC) pour configurer le peering. Vous pouvez utiliser cette approche si vous devez configurer plusieurs régions à plusieurs reprises et Comptes AWS pour la configuration d'une organisation multirégionale.

Ce modèle définit une AWS CloudFormationpile qui inclut un AWS Step Functions flux de travail, des AWS Lambda fonctions, des rôles Gestion des identités et des accès AWS (IAM) et des groupes de CloudWatch journaux dans Amazon Logs. Vous exécutez ensuite le flux de travail Step Functions pour créer la connexion d'appairage interrégionale pour vos passerelles de transport en commun.

Conditions préalables et limitations

Conditions préalables

Limites

  • Seuls certains Régions AWS soutiennent le peering interrégional. Pour une liste complète des régions qui prennent en charge le peering interrégional, consultez le. AWS Transit Gateway FAQs

Architecture

L'approche de développement de l'IA agentique décrite dans ce modèle implique les étapes suivantes :

  1. Définissez l'invite d'automatisation — Kiro reçoit une invite en langage naturel qui détaille les exigences de peering.

  2. Générer un script d'automatisation : Kiro génère les scripts CloudFormation et Lambda en fonction de l'invite fournie.

  3. Déployer la pile : Kiro utilise CloudFormation pour déployer les ressources requises.

  4. Configuration du peering : Kiro exécute le flux de travail Step Functions, qui appelle les fonctions Lambda pour créer des connexions d'appairage et modifier les tables de routage.

Le schéma suivant illustre le flux de travail Step Functions :

Workflow Step Functions pour appeler la fonction Lambda afin de modifier les tables de routage pour le peering des passerelles de transit.

Le flux de travail comprend les étapes suivantes :

  1. Le flux de travail Step Functions appelle la fonction Lambda pour le peering de Transit Gateway. 

  2. Le flux de travail attend une minute.

  3. Le flux de travail récupère l'état du peering et l'envoie au bloc de conditions. Le bloc est responsable de la boucle. 

  4. Si la condition de réussite n'est pas remplie, le flux de travail est codé pour passer à l'étape du chronomètre. 

  5. Si la condition de réussite est remplie, une fonction Lambda modifie les tables de routage.

  6. Le flux de travail Step Functions se termine.

Outils

  • AWS CloudFormationvous aide à configurer les AWS ressources, à les approvisionner rapidement et de manière cohérente, et à les gérer tout au long de leur cycle de vie à travers Comptes AWS et Régions AWS. 

  • Amazon CloudWatch Logs vous aide à centraliser les journaux de tous vos systèmes et applications, Services AWS afin que vous puissiez les surveiller et les archiver en toute sécurité.

  • Gestion des identités et des accès AWS(IAM) vous aide à gérer en toute sécurité l'accès à vos AWS ressources en contrôlant qui est authentifié et autorisé à les utiliser.

  • Kiro est un outil de développement d'intelligence artificielle qui vous aide à créer des applications prêtes pour la production grâce à un développement piloté par les spécifications. 

  • AWS Lambda est un service de calcul qui vous aide à exécuter du code sans avoir à allouer ni à gérer des serveurs. Il exécute votre code uniquement lorsque cela est nécessaire et évolue automatiquement, de sorte que vous ne payez que pour le temps de calcul que vous utilisez.

  • AWS Step Functionsest un service d'orchestration sans serveur qui vous aide à combiner des AWS Lambda fonctions et autres Services AWS pour créer des applications critiques pour l'entreprise.  

Épopées

Sous-tâcheDescriptionCompétences requises

Remplir les espaces réservés des messages instantanés avec des détails spécifiques

  1. Mettez à jour l'invite suivante en remplaçant les noms Régions AWS des compartiments et :

    - Active region: ACTIVE_REGION
- Passive region: PASSIVE_REGION
- S3_BUCKET : my-lambda-packages-bucket 
- STACK_NAME : transit-gateway-peering 
- All Lambda functions use two boto3 EC2 clients at module level (one per region), each with signature_version v4 and retries max_attempts=1 mode=standard.
- Print all API responses for CloudWatch logging.

  2. Enregistrez-le sous forme de fichier Markdown.

  3. Ajoutez ce fichier de balisage à votre projet Kiro pour le contexte.

Note

Vous pouvez également l'ajouter sous forme d'invite en ligne qui fait référence aux variables ci-dessus sans joindre le fichier pour le contexte.

AWS général, administrateur réseau

Créez une fonction Lambda qui crée les pièces jointes d'appairage.

  1. Dans votre projet Kiro, entrez le message suivant :

    Write a Python Lambda that creates a transit gateway peering attachment from active region  to passive region. Both of these regions will be read as environment variables of the Lambda function. Use two boto3 EC2 clients at the module level, one per Region. The handler should describe available transit gateways in both Regions. Then check if a peering attachment already exists on the active side by filtering describe_transit_gateway_attachments for resource-type "peering" and states: available, initiatingRequest, modifying, pendingAcceptance, pending, rejected, and rejecting. Only if zero results, create the peering attachment with tags for both Transit Gateway IDs, then wait 60 seconds (AWS needs this before the passive side can accept), then call accept_transit_gateway_peering_attachment on the passive client. Print all API responses.

  2. Enregistrez et nommez ce fichier peer-transit-gateway.py.

AWS général, administrateur réseau, Prompt engineering

Créez une fonction Lambda qui interroge l'état de la pièce jointe au peering.

  1. Dans votre projet Kiro, entrez le message suivant :

    Using the shared context above, write a Python Lambda that polls peering attachment status. Describe available transit gateways in both regions, then call describe_transit_gateway_attachments on the active client filtered by the active Transit Gateway ID only (no resource-type filter). Return exactly `{'status': status}` where status is the State field from the first attachment. Do not return statusCode or body — the Step Function Choice state reads `$.Payload.status` and compares to "available".

  2. Enregistrez et nommez ce fichier get-transit-gateway-peering-status.py.

AWS général, administrateur réseau, Prompt engineering

Créez une fonction Lambda qui ajoute des itinéraires statiques aux deux régions.

  1. Dans votre projet Kiro, entrez le message suivant :

    Using the shared context, write a Python Lambda that adds static routes to both regions' TGW route tables. Describe available transit gateways in both Regions, extract each transit gateway's AssociationDefaultRouteTableId. Discover routable VPCs by filtering describe_vpcs with tag `addtotransitgateway=true` in each region, collecting their CIDRs. Get the peering attachment ID from the active side by filtering on the active route table ID. For each passive CIDR, search the active route table using `route-search.exact-match` — only create the route if none found. For each active CIDR, search the passive route table using `route-search.supernet-of-match` (not exact-match — passive side may have supernet routes) — only create if none found. Both sides use the same peering attachment ID.

  2. Enregistrez ce fichier et nommez-le sous le nommodify-transit-gateway-routes.py.

AWS général, administrateur réseau

Créez le CloudFormation modèle.

  1. Entrez l'invite d'orchestration suivante, qui crée un CloudFormation modèle :

    Write a CloudFormation JSON template that deploys: three Lambda functions (peer-transit-gateway with 600s timeout, get-transit-gateway-peering-status with 30s timeout, modify-transit-gateway-routes with 600s timeout), Lambda code from an S3 bucket parameter (no default value — user must supply the bucket name at deploy time), a Step Functions state machine, and CloudWatch log groups with 90-day retention. The state machine flow is:

1. Invoke peer-transit-gateway
2. Wait 20 seconds (attachment needs time after the Lambda's internal 20s sleep + acceptance)
3. Invoke get-transit-gateway-peering-status
4. Choice: if `$.Payload.status` equals "available" → go to step 5, otherwise loop back to step 2
5. Invoke modify-transit-gateway-routes → End

Use `Fn::Sub` with Lambda ARN references like `${PeerTransitGateways.Arn}` in the DefinitionString. The polling loop has no max retry — it loops until "available" (typically 3-5 minutes total).

  2. Enregistrez le fichier et nommez-letransit-gateway-peering.json.

AWS DevOps, AWS général, Ingénierie rapide
Sous-tâcheDescriptionCompétences requises

Déployez la CloudFormation pile à l'aide des instructions.

Entrez le message suivant :

Using the outputs from Prompts 1-4, package and deploy the full stack. Steps:

1. For each of the three Python files from Prompts 1-3, create a zip named after the file (e.g. peer-transit-gateway.zip that contains peer-transit-gateway.py).
2. Upload all three zips to S3_BUCKET.
3. Deploy the CloudFormation template from Prompt 4 to ACTIVE_REGION with S3BucketName=S3_BUCKET and CAPABILITY_NAMED_IAM.
4. Initiate the Step Function from the deployed stack.

Zip file names must match the S3Key values in the template exactly.
AWS DevOps, Administrateur du cloud, AWS général, Prompt engineering

Validez le déploiement.

  1. Surveillez le flux de travail Step Functions pour vous assurer qu'il est terminé avec succès. Pour obtenir des instructions, consultez la documentation Step Functions.

  2. Vérifiez que le statut d'appairage des pièces jointes Transit Gateway est disponible. Pour obtenir des instructions, consultez la documentation de Transit Gateway.

AWS général

Ressources connexes