Closed Brian969 closed 2 years ago
Can we also include the capability of edge-association for the route tables?
Hi, Can you elaborate on what you mean by edge-association? This PR (which is code complete) supports targeting any supported object type from a VPC route table, whether created by the ASEA or not. (i.e. 'egressOnlyInternetGatewayId', 'gatewayId', 'instanceId', 'localGatewayId', 'natGatewayId', 'networkInterfaceId', 'transitGatewayId', 'vpcEndpointId', 'vpcPeeringConnectionId',).
Describe the solution you'd like
Describe alternatives you've considered
Narrative
Overall solution architecture
The below diagram (lower portion) documents the Outpost account, the Outpost, the Dev Outpost VPC, the recommended subnet layouts, etc.![image](https://user-images.githubusercontent.com/56414362/165860259-c69cc054-104d-4f6b-b496-28e36ab6c0bb.png)
Details
Do we a) relax the az definition field, or b)add a new “lz”: “us-west-2-lax-1a” field (i.e. “us-west-2-lax-1a” is the format expected by the API).If provided, we’d concat {region}{-}{lz}{az}. initial preference is b).Option 2alternative: do not add a type or target-id field from option 1, and use the values for “type” field above as the config parameter name and the values for “target-id” field above as the config parameter value. Example: “ localGatewayId”: “lgw-0cdc67d1ae6c75ff8”,Example:Example CFN Stacks For Each of the above new activities:
Stack1 - Associate LGW to VPC (via the LGW-RT):
Stack2 - Add Route Table Entry Pointing to LGW:
Stack3 - Create Outpost Subnet: