Management of (external) Transit Gateway Attachments

[richardkeit]

**Problem statement (with example) Integrating Enterprise AWS Cloud Platform to Mulesoft Private Spaces using Transit Gateway Attachments

Overall process:

1. Customer creates Transit Gateway Route table within the Landing Zone Accelerator
2. Customer Shares Transit Gateway with Mulesoft
3. Mulesoft create TGW attachment
4. Customer accepts TGW attachment
5. Customer configures routing (snippet: Interim auxiliary template for route propagation and route table association)

A east/west firewall is used in this architecture for traffic inspection

Describe the feature you'd like

• Ability to propagate routes from attachments not defined in LZA. Currently available through TransitGatewayAttachmentConfig routePropogations for defined VPCs
  • TransitGatewayRouteEntryConfig supports attachment which does not support a physical resource (only resources selected by name of the various types)
• Similar to the above, cannot associate attachments (created outside of LZA) to LZA defined TGWs

Additional context Transit Gateway Config:

transitGateways:
  - name: tgw-networking-prod
    account: Network
    region: *HOME_REGION
    shareTargets:
      accounts:
        - NetworkEdge
    routeTables:
      # Routes to spoke VPCs are propogated to the route table
      - name: tgw-rt-infra-firewall-apse2
        routes: []
      - name: tgw-rt-external-np-mulesoft-apse2
        routes:
          - destinationCidrBlock: 0.0.0.0/0
            attachment:
              vpcName: vpc-d-infra-prod-firewall-apse2
              account: NetworkEdge

Interim auxiliary template for route propagation and route table association:

AWSTemplateFormatVersion: "2010-09-09"

Description: Integrate Mulesoft to Existing TGW via Firewall (from Network Core)

Parameters:
  MulesoftAttachmentId:
    Type: String
    Description: Mulesoft Attachment Id

  MulesoftRouteTableId:
    Type: AWS::SSM::Parameter::Value<String>
    Description: SSM path to specific MuleSoft Route Table Id
    Default: /accelerator/network/transitGateways/tgw-networking-prod/routeTables/tgw-rt-external-np-mulesoft-apse2/id

  FirewallRouteTableId:
    Type: AWS::SSM::Parameter::Value<String>
    Description: SSM path to specific Firewall Route Table Id
    Default: /accelerator/network/transitGateways/tgw-networking-prod/routeTables/tgw-rt-infra-firewall-apse2/id

Resources:
  MulesoftRouteTableAssociation:
    Type: AWS::EC2::TransitGatewayRouteTableAssociation
    Properties:
      TransitGatewayAttachmentId: !Ref MulesoftAttachmentId
      TransitGatewayRouteTableId: !Ref MulesoftRouteTableId

  # Firewall
  PropogateMulesoftToFirewall:
    Type: AWS::EC2::TransitGatewayRouteTablePropagation
    Properties:
      TransitGatewayAttachmentId: !Ref MulesoftAttachmentId
      TransitGatewayRouteTableId: !Ref FirewallRouteTableId

[bo1984]

Hi Richard!

I've went ahead and created a feature request for this. I'll keep this issue open as we continue to evaluate the request in our backlog. If you have any other questions or concerns in the meantime, please do not hesitate to contact us.

[CirrusHQ-Pipeline-User]

Is there an update on this one? This is key for deploying a LZA Networking Architecture on top of an existing environment and migrating the existing environment (with existing VPC's) over to the LZA controlled Network