를 사용하여 리전 간 피어링 설정 자동화 AWS Transit Gateway

AWS 리전 및 버킷 이름을 바꾸어 다음 프롬프트를 업데이트합니다.

- 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.

이를 마크다운 파일로 저장합니다.

컨텍스트를 위해이 마크다운 파일을 Kiro 프로젝트에 추가합니다.

Kiro 프로젝트에 다음 프롬프트를 입력합니다.

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.

이 파일을 저장하고 이름을 peer-transit-gateway.py로 지정합니다.

Kiro 프로젝트에 다음 프롬프트를 입력합니다.

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".

이 파일을 저장하고 이름을 get-transit-gateway-peering-status.py로 지정합니다.

Kiro 프로젝트에 다음 프롬프트를 입력합니다.

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.

이 파일을 로 저장하고 이름을 지정합니다modify-transit-gateway-routes.py.

CloudFormation 템플릿을 생성하는 다음 오케스트레이션 프롬프트를 입력합니다.

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).

이 파일을 저장하고 이름을 transit-gateway-peering.json로 지정합니다.

Step Functions 워크플로가 성공적으로 완료되었는지 모니터링합니다. 지침은 Step Functions 설명서를 참조하세요.

Transit Gateway 연결 피어링 상태를 사용할 수 있는지 확인합니다. 지침은 Transit Gateway 설명서를 참조하세요.