Introduction

Defining and provisioning standardized virtual private cloud (VPC) patterns across an enterprise poses several challenges for many customers. These challenges include ensuring self-service capabilities, meeting security and compliance requirements, and maintaining adherence to those requirements.

Traditionally, when an application team wants to provision a VPC in their workload account, it is requested through a centralized team such as Cloud or Networking. This may take days to weeks before being fully provisioned and operational. Also, it often involves an engineer logging in to a workload account to deploy and run multiple templates and scripts, and several manual steps to connect the VPC to the enterprise network.

This post shows you how to create a self-service VPC product in Amazon Web Services (AWS) Service Catalog, providing a solution that can be modified and extended to integrate with other automations across an enterprise environment. This solution enables teams to provision infrastructure autonomously through automated processes, expediting innovation across the organization. Concurrently, it upholds centralized oversight and regulation over the infrastructure resources.

Solution overview

This solution provides integration with the following AWS services and solutions:

• AWS Transit Gateway automation with Network Orchestration for AWS Transit Gateway
• IP address management with Amazon VPC IP Address Manager (IPAM)
• Dynamic subnet size calculation with Subnet Calculator Custom Resource
• Self-service with AWS Service Catalog with Template Constraints

Integration with the services and automations mentioned in the Introduction section means that the VPC product described in this solution provides the following benefits:

• Allow teams to choose the VPC configuration and self-serve, without engaging a centralized cloud/networking team, while enabling:
  • Organized IP address space into security domains through integration with IPAM.
  • Customizable subnet VPC and Subnet Classless Inter-Domain Routing (CIDR) range calculation and automated IP address allocation.
  • Automated connectivity to an AWS Transit Gateway network.
• Enforce compliance through:
  • Self-service through AWS Service Catalog using a pre-defined template and VPC patterns.
  • AWS Service Catalog template constraints to enforce configurations in different environments.
• Flexibility and extensibility to customize the solution by:
  • Providing a base VPC template that can be integrated with other networking automations you may have.
  • Modifying or adding more VPC patterns to meet your organization security, compliance, and networking requirements.
  • Defining networking egress patterns by modifying the route tables.

High level architecture

The following figure shows the high level architecture for this solution.

Figure 1: High level architecture for enterprise-grade VPC product

1. An AWS Service Catalog product is created from the VPC AWS CloudFormation template stored in the VPC Service Catalog Bucket.
2. User permissions are assigned through either AWS IAM Identity Center permission sets or IAM roles to access the VPC Service Catalog product that is shared with:
   • All AWS accounts in your AWS Organization or selected organizational units (OUs), using sharing with Organizations
   • Individual AWS accounts using account-to-account sharing
3. A user assumes the configurable (reference the Prerequisites section) AWS Identity and Access Management (IAM) Role through either AWS Identity and Access Management (IAM) or IAM Identity Center into the member account, with access to the Service Catalog Portfolio.
4. The user launches the VPC Service Catalog product with selected patterns. The parameters visible to the user are restricted by Template Constraints. For example, if the Environment is set to non-prod, then VPC patterns with public subnets can’t be selected.
5. The VPC stack created from the Service Catalog product connects to IPAM to retrieve an available IP CIDR based on the VPC size selected. Then, it sends the subnet label and prefix into the Subnet Calculator, which returns the subnet sizes to the CloudFormation stack for Subnet creations.
6. When the VPC and Subnets are created, they are tagged based on the VPC and Transit Gateway connectivity pattern selected, which triggers the Network Orchestration for Transit Gateway automation. The Network Orchestration for Transit Gateway automation then creates Transit Gateway Attachments, Transit Gateway Route Table Associations, and Propagations according to the VPC and Subnet Tags.
7. All VPCs created from the Service Catalog product send VPC Flow Logs into a centralised Amazon Simple Storage Service (S3) bucket.

VPC patterns

The following four categories of VPC patterns are included in the VPC Service Catalog Product given as examples:

Service Catalog Template Constraint Rules are used to restrict which VPC and Transit Gateway connectivity patterns can be used based on the Environment parameter selected (prod or non-prod).

Subnet sizes are calculated automatically based on the default mapping specified in VPC-Product.yaml, and they can be customized by changing the parameters. IPAM pools used by the VPC creation are determined dynamically based on the Environment parameter in the product template.

To modify or add VPC patterns, the cloud/networking team can update the VPC CloudFormation template, and they can apply the changes in the Service Catalog product through their preferred pipeline. Existing VPCs are not affected by updates, and only new VPCs are affected (or Service Catalog updates to existing VPCs).

For the full solution source code, refer to our GitHub repository.

Prerequisites

The following prerequisites are necessary to follow this solution:

Accounts and permissions

1. Access to AWS CloudShell with Administrator level access to AWS Organization.
2. Management account: Access to the management account within your Organization.
3. Networking account: A networking account created in your Organization acting as the Network Orchestration for AWS Transit Gateway Hub. For more information on Network Orchestration for AWS Transit Gateway, refer to the solution guide.
4. Member account: A member account of your Organization to deploy a standardized VPC using the provisioned AWS Service Catalog Product.
5. An OU needs to be created and the member account is moved to this OU.
6. Make sure that an IAM Identity Center permission set is assigned to, or IAM role is available in, the member account to access the VPC Service Catalog Product. This post assumes that you are using the AdministratorAccess permission. However, if you are deploying to production, then make sure that you follow the least-privilege permissions.

Although the solution can be deployed in a single account, we recommend deploying across multiple accounts. This approach demonstrates the isolation of roles, responsibilities, and end-to-end workflow in an Enterprise environment.

Dependencies

Network Orchestration for AWS Transit Gateway: Provides functionality to automate setting up and managing the transit network in a multi-account AWS environment. It is used in this solution to automate the attachments of Transit Gateways across member accounts. In the walkthrough we assume that this solution is already configured and tested in the network account.

Subnet Calculator Custom Resource: Provides functionality to unevenly split CIDR-based off requirements, such as Transit Gateway subnets, a smaller public subnet with larger private subnets. In the walkthrough we assume that this solution is already configured and tested in the network account.

IPAM: Provides functionality to automatically assign IP CIDRs to self-served VPCs in the workload accounts when requested through Service Catalog. A prod and non-prod IPAM pool are setup by default in this solution to demonstrate the integration with IPAM and the VPC Service Catalog product. The VPC template can be modified to work with existing IPAM pools if needed.

For the deployment details of Network Orchestration for AWS Transit Gateway and Subnet Calculator Custom Resource, refer to the relevant sections in the README.

Walkthrough

After the dependencies are deployed and configured, there are two steps to deploy this solution:

1. Organizations configuration to allow Organization-wide resource sharing.
2. Service Catalog product creation to allow users to request the VPC.

Step 1: AWS Organization configuration

In the management account, the following configurations are needed:

• AWS Resource Access Manager (AWS RAM) sharing needs to be enabled to share IPAM pools and Transit Gateway.
• Service Catalog Organizations sharing needs to be enabled, and the account hosting the Service Catalog Product needs to be one of the delegated administrators for Service Catalog.
• Delegate IPAM administration to the networking account and create an Organization role to allow the networking account to describe accounts within the Organization.
• IPAM Organizations sharing needs to be enabled, and the account hosting the IPAM pools need to be the delegated administrator for IPAM.

To enable this, log in to your Organization Management account, launch AWS CloudShell in the desired AWS Region, and run the following commands:

# 1. Enable RAM sharing
aws ram enable-sharing-with-aws-organization

You should observe output similar to the following:

{
    "returnValue": true
}

# 2. Delegate IPAM administration to Network account
network_account=012345678901  # REPLACE ME
aws ec2 enable-ipam-organization-admin-account --delegated-admin-account-id $network_account

You should observe output similar to the following:

{
    "Success": true
}

# 3. Register and delegate Service Catalog administration to Network account where the service catalog product will be deployed:
aws organizations enable-aws-service-access --service-principal servicecatalog.amazonaws.com

aws organizations register-delegated-administrator --service-principal servicecatalog.amazonaws.com --account-id $network_account

You should observe output similar to the following:

{
    "DelegatedServices": [
        {
            "ServicePrincipal": "servicecatalog.amazonaws.com",
            "DelegationEnabledDate": "2024-07-25T14:29:13.540000+10:00"
        }
    ]
}

Step 2: Service Catalog product creation

Next, we run the install.sh script that creates the CloudFormation stacks needed for the VPC Service Catalog product. The script assumes the components are deployed in the Network Account.

Log in to the Network Account, launch AWS CloudShell in the desired AWS Region, and run the following commands:

git clone https://github.com/aws-samples/enterprise-grade-vpc-product-with-aws-service-catalog
cd vending-advanced-customizable-vpcs-with-service-catalog/service-catalog-product
./install.sh # follow prompts

The script asks for the following information:

• Do you want to use the existing VPC Flow Log S3 bucket or create a default one?
• Assign the OU Amazon Resource Name (ARN) that contains the member account to the prod and non-prod IPAM pools that are created. We are using the same OU ARN for testing purposes, thus you can adjust the assignments based on your requirements.
• The Service Catalog provider display name.
• The Service Catalog product version, which defaults to v1. Increment this if you make a change in the product CloudFormation template file.
• The Principal type that is using the Service Catalog product. If you are using IAM Identity Center, then enter IAM_Identity_Center_Permission_Set. Otherwise, if you have federated IAM roles configured, then select IAM role name.
• The Principal(s) that have access to the Service Catalog product across the AWS accounts. If you are using IAM Identity Center, then this is a permission set name, for example AWSAdministratorAccess. Otherwise, enter the IAM role name.

After the script finishes installation, it asks whether it should automatically share this Service Catalog portfolio with the entire Organization, a specific account, or configure sharing to specific OUs manually.

Now the Service Catalog product is configured, shared, and ready to be deployed.

Deploying the VPC Service Catalog product

To deploy a standardized VPC using Service Catalog in your member account, follow these steps:

1. Make sure you are logged in to the target member account using the target principal, and using either an IAM_Identity_Center_Permission_Set or IAM _role_name, specified during installation to list and deploy the VPC product.
2. In the AWS Service Catalog → Products, select the VPC product, and choose Launch.
3. Enter a provisioned product name, for example VPC-01, and fill out the necessary parameters, considering the following requirements:
   • Name of VPC: Provide a name for the VPC.
   • Environment: The environment, for example prod, non-prod. When selecting the environment make sure the member account OU aligns to the environment’s IPAM pool OU. If this condition is not met, then the product fails to launch.
   • Transit Gateway connectivity requirements: Define the scope of Transit Gateway connectivity for the VPC. Customization of the route tables is defined in the network (hub) account as part of the Network Orchestration for Transit Gateway solution.
4. If you want to customize your VPC, then you can modify other default values in the VPC product (for example subnet size).
5. Finally, press Launch Product. After a few minutes the product provisioning is complete. If the product fails to launch, then refer to the troubleshooting section.

Congratulations on deploying a standardized VPC pattern in a member account with Transit Gateway orchestration through Service Catalog!

Cleaning up

To avoid ongoing charges, follow these steps:

• In the test Member Account(s):
  • Go to Service Catalog Provisioned products, and terminate the associated provisioned product(s). This deletes the VPC and other associated resources, such as the Transit Gateway Attachments.
  • Go to CloudFormation, and delete the network-orchestration-spoke-service-linked-roles stack.
• In the Network Account:
  • Go to Service Catalog, Portfolios, choose VPC, go to the Share tab, select the items in the list, and choose Actions -> Unshare.
  • Go to CloudFormation, and delete the VPC-Service-Catalog stack.
  • Go to Amazon S3, select the bucket starting with vpc-sc-bucket, choose Empty, and empty the bucket.
  • (If using default VPC flow log bucket) Go to Amazon S3, select the bucket starting with vpc-flow-logs, choose Empty, and empty the bucket.
  • Go to CloudFormation and delete the following stacks: 1) VPC-SC-Bucket, 2) VPC-Flow-Log-Bucket, 3) IPAM, 4) network-orchestration-hub, 5) network-orchestration-spoke, 6) Subnet-Calculator, and 7) VPC-Service-Catalog.
• In the Management Account:
  • Go to CloudFormation, and delete the network-orchestration-organization-role stack.

Next steps

This section provides more information about other networking solutions that can be integrated with the example VPC template in this post based on the Organization requirements. This allows network administrators to customize the VPC template in this post based on your Organization requirements:

• Centralized egress and inspections with either AWS Network Firewall or Gateway Load Balancer can be achieved by adding static routes in the Transit Gateway and Subnet route tables.
• Hybrid and multi-account DNS:
  • The AWS DNS Whitepaper and AWS Prescriptive Guidance provide insight on the different multi-account and hybrid DNS management patterns.
    • Amazon Route 53 Profiles can be used to share private hosted zones and DNS Resolver Rules with the spoke VPCs, for more information on how this can be used, refer to Using Amazon Route 53 Profiles for scalable multi-account AWS environments.
  • To automate the spoke private hosted zone association with the Hub VPC, refer to Deploy consistent DNS with AWS Service Catalog and AWS Control Tower customizations for code examples.
• Centralized VPC interface endpoints can be achieved by deploying VPC interface endpoints in the hub VPC, combining with the DNS resolver rule shared with the spoke accounts.
• Centralized Management of DNS firewall can be achieved by configuring Amazon Route 53 Resolver DNS Firewall to protect against DNS-level threats such as DNS Exfiltration.

Conclusion

In this post, we demonstrated how to setup an enterprise grade VPC product and share with member accounts in a multi-account Organization environment using Service Catalog. The solution brings together multiple AWS services and solutions that result in removing the need to log requests with a centralized team.

The modular nature of the solution allows you to extend and customize based on an Organization’s specific requirements. More capabilities such as centralized egress filtering, hybrid DNS management, and shared VPC endpoints can be incorporated by modifying the VPC template and integrations with other networking services.

Overall, this approach helps accelerate application deployment by empowering teams with self-service automated infrastructure provisioning, while still maintaining centralized governance and control.

To get started, first review the solution dependencies and then follow the walkthrough to provision standardized VPC patterns across your AWS environment. If you run into issues or want to submit a feature request, use the New issue button under the issues tab in the GitHub repository.

A correction was made on October 15, 2024: An earlier version of this post included spelling mistakes and was missing a URL. The spelling mistake and missing URL have been corrected. 

About the authors