feat: add support to Subnet and VPC L2 constructs for deploying to an Outpost

[RyanFrench]

Issue # (if applicable)

Closes #33542.

Reason for this change

This PR extends the L2 VPC Construct to allow developers to provision a VPC that extends the Subnets onto an Outpost, and provides simplified configuration of the routing via the Local Gateway (on-premise router) or NAT/Internet Gateway (in-region routers)

Description of changes

This PR changes the VPC and Subnet L2 constructs with new subnet types, adds additional configuration options to the SubnetConfig in the VPC construct, and changes the default route setup based on the SubnetConfig.

Describe any new or updated permissions being added

None

Description of how you validated changes

We have written tests covering the new configuration options for subnets, as well as validated that this worked by deploying a VPC to an account with an Outpost attached, using the example code in the original Issue.

Example usage for deploying a VPC with on-premise networking routing traffic via the Local Gateway

const vpcCidr = this.node.tryGetContext("vpcCidr");
const outpostAvailabilityZone = this.node.tryGetContext("outpostAvailabilityZone");
const outpostArn = this.node.tryGetContext("outpostArn");
const localGatewayId = this.node.tryGetContext("localGatewayId");
const localGatewayRouteTableId = this.node.tryGetContext("localGatewayRouteTableId");
new ec2.Vpc(this, "OutpostVPC", {
    cidr: vpcCidr,
    maxAzs: 2,
    localGatewayRouteTableIds: [localGatewayRouteTableId],
    subnetConfiguration: [
        {
            cidrMask: 26,
            name: "Public",
            subnetType: ec2.SubnetType.PUBLIC,
        },
        {
            cidrMask: 26,
            name: "Private",
            subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
        },
        {
            cidrMask: 26,
            name: "OutpostPublic",
            outpostArn,
            outpostAvailabilityZone: outpostAvailabilityZone,
            outpostDefaultRoute: ec2.OutpostDefaultRoute.ON_PREMISE,
            localGatewayId: localGatewayId,
            subnetType: ec2.SubnetType.PUBLIC_OUTPOST,
        },
        {
            cidrMask: 26,
            name: "OutpostPrivate",
            outpostArn,
            outpostAvailabilityZone: outpostAvailabilityZone,
            outpostDefaultRoute: ec2.OutpostDefaultRoute.ON_PREMISE,
            localGatewayId: localGatewayId,
            subnetType: ec2.SubnetType.PRIVATE_OUTPOST_WITH_EGRESS,
        },
    ],
});

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ Features must contain a change to an integration test file and the resulting snapshot.
❌ CLI code has changed. A maintainer must run the code through the testing pipeline (git fetch origin pull/33545/head && git push -f origin FETCH_HEAD:test-main-pipeline), then add the 'pr-linter/cli-integ-tested' label when the pipeline succeeds.

If you believe this pull request should receive an exemption, please comment and provide a justification. A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed, add Clarification Request to a comment.

✅ A exemption request has been requested. Please wait for a maintainer's review.

[RyanFrench]

Exemption Request - I have some Integ tests that I can add, however, they will always fail unless the account has an Outpost attached to it, and the test is able to dynamically find the correct values for OutpostARN, Local Gateway ID, Local Gateway Route Table ID, and the CIDR range associated with the ServiceLink. Some of these values cannot be programatically determined.

[shikha372]

will this always be an internet IP range or can be restricted ?

[RyanFrench]

This applied to the public subnets that are deployed on the Outpost, where internet traffic can be routed either through an Internet Gateway deployed in region or the Local Gateway deployed on the Outpost network. The aim was to create functionality similar to the addDefaultInternetRoute() function that applies to public subnets deployed in region where 0.0.0.0/0 is always used.

[shikha372]

same question for this

[RyanFrench]

Same answer as above.

[shikha372]

@RyanFrench , Thank you for your contribution, before starting to review this, some high level questions:

1. Can this be just a single field under existing subnet type where users can provide outpost Arn.
2. instead of these default route, we can expose a helper method to to define this association for selected subnets, also addRoute method is for defining a new Route of type AWS::EC2::Route but i see some other resources that are specific to localgateway routing https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-localgatewayroutetable.html

[RyanFrench]

@RyanFrench , Thank you for your contribution, before starting to review this, some high level questions:

1. Can this be just a single field under existing subnet type where users can provide outpost Arn.
2. instead of these default route, we can expose a helper method to to define this association for selected subnets, also addRoute method is for defining a new Route of type AWS::EC2::Route but i see some other resources that are specific to localgateway routing https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-localgatewayroutetable.html

Hi @shikha372. Thank you for picking this up.

We originally did look to just add the outpost Arn to the existing subnet types, which does work for allowing the subnet to be deployed on to an Outpost, however, the complexity is in the various routing options for Outposts. Traffic can either be routed over the service link into the region, or it can be routed via the Local Gateway direct to the internet. Without these changes then users deploying to Outpost would be unable to define the Outpost subnets inside the VPC construct, or would need to define them and then have a way of deleting the automatically added default routes to replace with local gateway routes.

In terms of the local gateway default routes, I believe you're referring to the mode parameter. By default, direct-to-vpc routing is enabled which appears to be the far more common case over customer owned IPs. We did consider adding it but wanted to restrict the blast radius as this was already quite a complicated PR.

[shikha372]

Thanks @RyanFrench ,
I think few suggestions to model this change to keep the implementation simple as we already have VPCv2 for customized routes and entries for users and we want to minimize this default setup:

1. Instead of defining different subnet types with OUTPOST suffix, we define a property under subnetConfiguration with boolean set to true or false

outpost : {
enable: true/false,
route: OutpostDefaultRoute,
localGatewayId: string,
}

2. instead of adding default routes, add helper function to the base class that customers can leverage to define these routes.
3. Rest of the checks and implementation can be done based on outpost property in subnetConfiguration.

Let me know what you think.

[aws-cdk-automation]

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. Note that PRs with failing linting check or builds are not reviewed, please ensure your build is passing

To prevent automatic closure:

• Resume work on the PR
• OR request an exemption by adding a comment containing 'Exemption Request' with justification e.x "Exemption Request: "
• OR request clarification by adding a comment containing 'Clarification Request' with a question e.x "Clarification Request: "

This PR will automatically close in 14 days if no action is taken.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 182ba6d
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error.

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.