search

aws-solutions / network-orchestration-for-aws-transit-gateway

The Network Orchestration for AWS Transit Gateway solution automates the process of setting up and managing transit networks in distributed AWS environments. It creates a web interface to help control, audit, and approve (transit) network changes.
https://aws.amazon.com/solutions/implementations/serverless-transit-network-orchestrator/
Apache License 2.0
113 stars 48 forks source link

The spoke is not deployable on accounts that already have a transit gateway attachment #5

Closed faridnsh closed 4 years ago

faridnsh commented 4 years ago

Making a transit gateway attachment seems to automatically create the AWSVPCTransitGatewayServiceRolePolicy service linked role which will conflict with this line: https://github.com/awslabs/serverless-transit-network-orchestrator/blob/8a2f7ff/deployment/aws-transit-network-orchestrator-spoke.template#L47

I can't remove the AWSVPCTransitGatewayServiceRolePolicy service linked role because the transit gateway is using it, so the only to get it working seems to be removing that resource from the template.

Which begs the question, since the service linked role is actually created automatically by the transit gateway attachment, why do we need it in the template?

groverlalit commented 4 years ago

@alFReD-NSH Thanks for bringing this up. The Service Linked Role (SLR) may or may not exist in the member account, which depends on if it was created by another action, for example, create TGW resources using console. Since you can't delete the SLR, a possible workaround to resolve this can be updating the existing SLR with the description used by the template. "Allows TGW and VPC Attachment operations." and retry deploying the template. Hope this helps. Thanks

msporleder commented 2 years ago

I just ran into this -- is there not a cleaner way to detect and validate this? Failing on the description field seems so arbitrary, especially when aws created the roles to begin with