cdk-vpc-module construct library is an open-source extension of the AWS Cloud Development Kit (AWS CDK) to deploy configurable aws vpc and its individual components in less than 50 lines of code and human readable configuration which can be managed by pull requests!
- ✅ Option to configure custom IPv4 CIDR(10.10.0.0/24)
- ✅ VPC Peering with route table entry
- ✅ Configurable NACL as per subnet group
- ✅ NATGateway as per availabilityZones
Using cdk a vpc can be deployed using the following sample code snippet:
import { Network } from "@smallcase/cdk-vpc-module/lib/constructs/network";
import { aws_ec2 as ec2, App, Stack, StackProps } from "aws-cdk-lib";
import { Construct } from "constructs";
export class VPCStack extends Stack {
constructor(scope: Construct, id: string, props: StackProps = {}) {
const s3EndpointIamPermission = new iam.PolicyStatement({
actions: ["s3:*"],
resources: ['arn:aws:s3:::*'],
principals: [new iam.AnyPrincipal()],
})
const monitoringEndpointIamPermission = new iam.PolicyStatement({
actions: ["*"],
resources: ['*'],
principals: [new iam.AnyPrincipal()],
})
super(scope, id, props);
new Network(this, 'NETWORK', {
vpc: {
cidr: '10.10.0.0/16',
subnetConfiguration: [],
},
peeringConfigs: {
"TEST-PEERING": { // this key will be used as your peering id, which you will have to mention below when you configure a route table for your subnets
peeringVpcId: "vpc-0000",
tags: {
"Name": "TEST-PEERING to CREATED-VPC",
"Description": "Connect"
}
}
},
subnets: [
{
subnetGroupName: 'NATGateway',
subnetType: ec2.SubnetType.PUBLIC,
cidrBlock: ['10.10.0.0/28', '10.10.0.16/28', '10.10.0.32/28'],
availabilityZones: ['ap-south-1a', 'ap-south-1b', 'ap-south-1c'],
ingressNetworkACL: [
{
cidr: ec2.AclCidr.ipv4('0.0.0.0/0'),
traffic: ec2.AclTraffic.allTraffic(),
},
],
routes: [
],
egressNetworkACL: [
{
cidr: ec2.AclCidr.ipv4('0.0.0.0/0'),
traffic: ec2.AclTraffic.allTraffic(),
},
],
},
{
subnetGroupName: 'Public',
subnetType: ec2.SubnetType.PUBLIC,
cidrBlock: ['10.10.2.0/24', '10.10.3.0/24', '10.10.4.0/24'],
availabilityZones: ['ap-south-1a', 'ap-south-1b', 'ap-south-1c'],
ingressNetworkACL: [
{
cidr: ec2.AclCidr.ipv4('0.0.0.0/0'),
traffic: ec2.AclTraffic.allTraffic(),
},
],
egressNetworkACL: [
{
cidr: ec2.AclCidr.ipv4('0.0.0.0/0'),
traffic: ec2.AclTraffic.allTraffic(),
},
],
routes: [
],
tags: {
// if you use this vpc for your eks cluster, you have to tag your subnets [read more](https://aws.amazon.com/premiumsupport/knowledge-center/eks-vpc-subnet-discovery/)
'kubernetes.io/role/elb': '1',
'kubernetes.io/cluster/TEST-CLUSTER': 'owned',
},
},
{
subnetGroupName: 'Private',
subnetType: ec2.SubnetType.PRIVATE_WITH_NAT,
cidrBlock: ['10.10.5.0/24', '10.10.6.0/24', '10.10.7.0/24'],
availabilityZones: ['ap-south-1a', 'ap-south-1b', 'ap-south-1c'],
ingressNetworkACL: [
{
cidr: ec2.AclCidr.ipv4('0.0.0.0/0'),
traffic: ec2.AclTraffic.allTraffic(),
},
],
egressNetworkACL: [
{
cidr: ec2.AclCidr.ipv4('0.0.0.0/0'),
traffic: ec2.AclTraffic.allTraffic(),
},
],
routes: [
{
// if you use this vpc for your eks cluster, you have to tag your subnets [read more](https://aws.amazon.com/premiumsupport/knowledge-center/eks-vpc-subnet-discovery/)
routerType: ec2.RouterType.VPC_PEERING_CONNECTION,
destinationCidrBlock: "<destinationCidrBlock>",
//<Your VPC PeeringConfig KEY, in this example TEST-PEERING will be your ID>
existingVpcPeeringRouteKey: "TEST-PEERING"
}
],
tags: {
'kubernetes.io/role/internal-elb': '1',
'kubernetes.io/cluster/TEST-CLUSTER': 'owned',
},
},
{
subnetGroupName: 'Database',
subnetType: ec2.SubnetType.PRIVATE_WITH_NAT,
cidrBlock: ['10.10.14.0/27', '10.10.14.32/27', '10.10.14.64/27'],
availabilityZones: ['ap-south-1a', 'ap-south-1b', 'ap-south-1c'],
ingressNetworkACL: [
{
cidr: ec2.AclCidr.ipv4('0.0.0.0/0'),
traffic: ec2.AclTraffic.allTraffic(),
},
],
egressNetworkACL: [
{
cidr: ec2.AclCidr.ipv4('0.0.0.0/0'),
traffic: ec2.AclTraffic.allTraffic(),
},
],
routes: [
],
tags: {
},
},
],
vpcEndpoints: [
{
name: "s3-gw",
service: ec2.GatewayVpcEndpointAwsService.S3,
subnetGroupNames: ["Private","Database"],
externalSubnets: [
{
id: "subnet-<id>",
availabilityZone: "ap-south-1a",
routeTableId: "rtb-<id>"
},
{
id: "subnet-<id>",
availabilityZone: "ap-south-1b",
routeTableId: "rtb-<id>"
}
],
iamPolicyStatements: [s3EndpointIamPermission]
},
{
name: "da-stag-monitoring-vpe",
service: ec2.InterfaceVpcEndpointAwsService.CLOUDWATCH_MONITORING,
subnetGroupNames: ["ManageServicePrivate"],
iamPolicyStatements: [monitoringEndpointIamPermission],
securityGroupRules: [
{
peer: ec2.Peer.ipv4("10.10.0.0/16"),
port: ec2.Port.tcp(443),
description: "From Test VPC"
}
],
},
]
});
}
}
const envDef = {
account: '<AWS-ID>',
region: '<AWS-REGION>',
};
const app = new App();
new VPCStack(app, 'TEST', {
env: envDef,
terminationProtection: true,
tags: {
});
app.synth();
Please refer here to check how to use individual resource constructs.
The quick start shows you how to create an AWS-VPC using this module.
- A working
aws
CLI installation with access to an account and administrator privileges - You'll need a recent NodeJS installation
To get going you'll need a CDK project. For details please refer to the detailed guide for CDK.
Create an empty directory on your system.
mkdir aws-quick-start-vpc && cd aws-quick-start-vpc
Bootstrap your CDK project, we will use TypeScript, but you can switch to any other supported language.
npx cdk init sample-vpc --language typescript
npx cdk bootstrap
Install using NPM:
npm install @smallcase/cdk-vpc-module
Using yarn
yarn add @smallcase/cdk-vpc-module
Check the changed which are to be deployed
~ -> npx cdk diff
Deploy using
~ -> npx cdk deploy
Features Multiple VPC Endpoints: Define and manage multiple VPC Endpoints in one configuration. Flexible Subnet Selection: Attach VPC Endpoints to multiple subnet groups or external subnets. Custom Security Groups: Configure security groups for Interface VPC Endpoints. IAM Policies: Attach custom IAM policies to control access to the VPC Endpoints. Tagging: Apply custom tags to each VPC Endpoint.
Defining VPC Endpoints Configuration You can define multiple VPC Endpoints in the vpcEndpoints: [] configuration array. Each VPC Endpoint can be customized with different subnet groups, IAM policies, security group rules, and tags.
vpcEndpoints: [
{
name: "test-s3-gw",
service: ec2.GatewayVpcEndpointAwsService.S3,
subnetGroupNames: ["ManageServicePrivate", "ToolPrivate", "Database"], // Subnet groups for the endpoint
externalSubnets: [
{
id: "subnet-<id>",
availabilityZone: "ap-south-1a",
routeTableId: "rtb-<id>",
},
{
id: "subnet-<id>",
availabilityZone: "ap-south-1b",
routeTableId: "rtb-<id>",
}
],
iamPolicyStatements: [s3EndpointIamPermission], // Custom IAM policy for the endpoint
},
{
name: "DynamoDbGatewayEndpoint",
service: ec2.GatewayVpcEndpointAwsService.DYNAMODB,
subnetGroupNames: ["private-subnet"],
additionalTags: {
Environment: "Staging",
},
},
],
In this example:
The S3 Gateway Endpoint is created in three subnet groups: ManageServicePrivate, ToolPrivate, and Database. External subnets are specified with their IDs, availability zones, and route table IDs for the S3 endpoint. A custom IAM policy (s3EndpointIamPermission) is attached to control access to the S3 endpoint. A DynamoDB Gateway Endpoint is created in the private-subnet with additional tags specifying the environment and ownership.
Configuration Options Here’s a breakdown of the configuration options available:
- name: A unique name for the VPC Endpoint.
- service: The AWS service the VPC Endpoint connects to (e.g., S3, DynamoDB, Secrets Manager)
- subnetGroupNames: The subnet group names where the VPC Endpoint will be deployed.
- externalSubnets: Specify external subnets if you need to define subnets manually (each with an id, availabilityZone, and routeTableId).
- iamPolicyStatements: (Optional) Attach IAM policy statements to control access to the endpoint.
- additionalTags: (Optional) Add custom tags to the VPC Endpoint for easier identification and tracking.
The module automatically chooses the optimal routing strategy based on the number of NAT Gateways to prevent duplicate 0.0.0.0/0
route entries:
- Strategy: One route table per subnet group
- Benefits:
- Cost Optimized: Fewer route tables = lower costs
- Simpler Management: One route table per subnet group
- No Duplicate Routes: Single NAT Gateway means no duplicate
0.0.0.0/0
entries - Suitable for: Development, testing, small workloads
- Configuration: All subnets in a group share the same route table with one NAT route
- Strategy: One route table per subnet
- Benefits:
- Prevents Duplicate Routes: Each subnet gets its own route table, avoiding duplicate
0.0.0.0/0
entries - AZ-Aware Routing: Each subnet uses NAT Gateway in the same AZ when possible
- High Availability: Better fault tolerance and load distribution
- Cross-AZ Cost Reduction: Reduced data transfer costs
- Suitable for: Production workloads, high availability requirements
- Prevents Duplicate Routes: Each subnet gets its own route table, avoiding duplicate
- Configuration: Each subnet gets its own route table with one NAT route
AWS route tables don't support duplicate entries for the same destination CIDR (like 0.0.0.0/0
). When you have multiple NAT Gateways:
- ❌ Wrong Approach: Multiple NAT routes in same route table →
AlreadyExists
error - ✅ Correct Approach: One route table per subnet → Each gets one NAT route
// Single NAT Gateway - Cost Optimized
new Network(this, 'NETWORK', {
vpc: {
cidr: '10.10.0.0/16',
subnetConfiguration: [],
},
subnets: [
{
subnetGroupName: 'NATGateway',
subnetType: ec2.SubnetType.PUBLIC,
cidrBlock: ['10.10.0.0/28'], // Only one subnet
availabilityZones: ['ap-south-1a'], // Only one AZ
useSubnetForNAT: true,
},
{
subnetGroupName: 'Private',
subnetType: ec2.SubnetType.PRIVATE_WITH_NAT,
cidrBlock: ['10.10.5.0/24', '10.10.6.0/24', '10.10.7.0/24'],
availabilityZones: ['ap-south-1a', 'ap-south-1b', 'ap-south-1c'],
},
],
});
// Multiple NAT Gateways - Performance Optimized
new Network(this, 'NETWORK', {
vpc: {
cidr: '10.10.0.0/16',
subnetConfiguration: [],
},
natEipAllocationIds: [
'eipalloc-1234567890abcdef',
'eipalloc-0987654321fedcba',
'eipalloc-abcdef1234567890',
],
subnets: [
{
subnetGroupName: 'NATGateway',
subnetType: ec2.SubnetType.PUBLIC,
cidrBlock: ['10.10.0.0/28', '10.10.0.16/28', '10.10.0.32/28'],
availabilityZones: ['ap-south-1a', 'ap-south-1b', 'ap-south-1c'],
useSubnetForNAT: true,
},
{
subnetGroupName: 'Private',
subnetType: ec2.SubnetType.PRIVATE_WITH_NAT,
cidrBlock: ['10.10.5.0/24', '10.10.6.0/24', '10.10.7.0/24'],
availabilityZones: ['ap-south-1a', 'ap-south-1b', 'ap-south-1c'],
},
],
});
The module provides outputs to show which strategy is being used:
- RoutingStrategy: Shows "Route Table per Subnet Group" or "Route Table per Subnet"
- NATGatewayCount: Shows the number of NAT Gateways configured
Scenario | Route Tables | NAT Routes per Table | Strategy |
---|---|---|---|
Single NAT | 1 per subnet group | 1 | Cost optimized |
Multiple NAT | 1 per subnet | 1 | Performance optimized |
You can easily migrate between strategies by changing your configuration:
- Development → Production: Add more NAT Gateway subnets
- Production → Development: Reduce to single NAT Gateway subnet
- Cost Optimization: Monitor usage and adjust NAT Gateway count
The module handles the migration automatically without manual route table changes.
You can specify existing Elastic IP (EIP) allocation IDs to use with your NAT Gateways. This is useful when you want to:
- Use pre-existing EIPs
- Maintain consistent IP addresses across deployments
- Control EIP costs and management
new Network(this, 'NETWORK', {
vpc: {
cidr: '10.10.0.0/16',
subnetConfiguration: [],
},
// Specify existing EIP allocation IDs
natEipAllocationIds: [
'eipalloc-1234567890abcdef', // EIP for NAT Gateway 1
'eipalloc-0987654321fedcba', // EIP for NAT Gateway 2
'eipalloc-abcdef1234567890', // EIP for NAT Gateway 3
],
subnets: [
{
subnetGroupName: 'NATGateway',
subnetType: ec2.SubnetType.PUBLIC,
cidrBlock: ['10.10.0.0/28', '10.10.0.16/28', '10.10.0.32/28'],
availabilityZones: ['ap-south-1a', 'ap-south-1b', 'ap-south-1c'],
useSubnetForNAT: true,
},
{
subnetGroupName: 'Private',
subnetType: ec2.SubnetType.PRIVATE_WITH_NAT,
cidrBlock: ['10.10.5.0/24', '10.10.6.0/24', '10.10.7.0/24'],
availabilityZones: ['ap-south-1a', 'ap-south-1b', 'ap-south-1c'],
},
],
});
- Count: Should match the number of NAT Gateway subnets (optional)
- Format: Must be valid EIP allocation IDs (e.g.,
eipalloc-xxxxxxxxx
) - Region: Must be in the same region as your VPC
- Account: Must be owned by the same AWS account
- Cost Control: Reuse existing EIPs instead of creating new ones
- IP Consistency: Maintain the same public IP addresses across deployments
- Compliance: Meet requirements for static IP addresses
- DNS: Use existing DNS records that point to specific EIPs
When EIP allocation IDs are provided, the module outputs:
- NATEipAllocationIds: Comma-separated list of EIP allocation IDs used
- RoutingStrategy: Shows the routing strategy being used
- NATGatewayCount: Number of NAT Gateways configured
{
"NATEipAllocationIds": "eipalloc-1234567890abcdef,eipalloc-0987654321fedcba,eipalloc-abcdef1234567890",
"RoutingStrategy": "Route Table per Subnet",
"NATGatewayCount": "3"
}
If you need to create EIPs first, you can do so using CDK:
import * as ec2 from 'aws-cdk-lib/aws-ec2';
// Create EIPs
const eip1 = new ec2.CfnEIP(this, 'NATEip1', {
domain: 'vpc',
});
const eip2 = new ec2.CfnEIP(this, 'NATEip2', {
domain: 'vpc',
});
const eip3 = new ec2.CfnEIP(this, 'NATEip3', {
domain: 'vpc',
});
// Use them in your Network construct
new Network(this, 'NETWORK', {
vpc: {
cidr: '10.10.0.0/16',
subnetConfiguration: [],
},
natEipAllocationIds: [
eip1.attrAllocationId,
eip2.attrAllocationId,
eip3.attrAllocationId,
],
// ... rest of configuration
});