Skip to content

Network Layer

In this section we detail all the network design related specifications

  • VPCs CIDR blocks
  • VPC Gateways: Internet, NAT, VPN.
  • VPC Peerings
  • VPC DNS Private Hosted Zones Associations.
  • Network ACLS (NACLs)

VPCs IP Addressing Plan (CIDR blocks sizing)

Introduction

VPCs can vary in size from 16 addresses (/16 netmask) to 65,536 addresses (/28 netmask). In order to size a VPC correctly, it is important to understand the number, types, and sizes of workloads expected to run in it, as well as workload elasticity and load balancing requirements.

Keep in mind that there is no charge for using Amazon VPC (aside from EC2 charges), therefore cost should not be a factor when determining the appropriate size for your VPC, so make sure you size your VPC for growth.

Moving workloads or AWS resources between networks is not a trivial task, so be generous in your IP address estimates to give yourself plenty of room to grow, deploy new workloads, or change your VPC design configuration from one to another. The majority of AWS customers use VPCs with a /16 netmask and subnets with /23 netmasks. The primary reason AWS customers select smaller VPC and subnet sizes is to avoid overlapping network addresses with existing networks.

So having AWS single VPC Design we've chosen a Medium/Small VPC/Subnet addressing plan which would probably fit a broad range variety of use cases

Networking - IP Addressing

Starting CIDR Segment (AWS Org)

  • AWS Org IP Addressing calculation is presented below based on segment 172.16.0.0/12
  • We started from 172.16.0.0/12 and subnetted to /20
  • Resulting in Total Subnets: 256
    • 2 x AWS Account with Hosts/SubNet: 4094
    • 1ry VPC + 2ry VPC
    • 1ry VPC DR + 2ry VPC DR

Individual CIDR Segments (VPCs)

⏩ Then each of these are /20 to /23

  • Considering the whole Starting CIDR Segment (AWS Org) before declared, we'll start at 172.18.0.0/20

    • shared
      • 1ry VPC CIDR: 172.18.0.0/23
      • 2ry VPC CIDR: 172.18.16.0/23
    • apps-devstg
      • 1ry VPC CIDR: 172.18.64.0/23
      • 2ry VPC CIDR: 172.18.80.0/23
    • apps-prd
      • 1ry VPC CIDR: 172.18.128.0/23
      • 2ry VPC CIDR: 172.18.144.0/23

  • Resulting in Subnets: 16 x VPC

    • VPC Subnets with Hosts/Net: 256.
    • Eg: apps-devstg account → us-east-1 w/ 3 AZs → 4 x Private Subnets /az + 4 x Public Subnets /az
      • 1ry VPC CIDR: 172.18.64.0/23Subnets:
        • Private 172.18.64.0/23, 172.18.66.0/23, 172.18.68.0/23, and 172.18.70.0/23
        • Public 172.18.72.0/23, 172.18.74.0/23, 172.18.76.0/23, and 172.18.78.0/23
        • Note: keep in mind that you may not strictly need 4 private subnets and 4 public subnets in every case. In some cases you might do fine with only 2 or 3, if that goes in sync with the kind of availability that you need to meet.

Planned VPCs and their Subnets

Having defined the initial VPC that will be created in the different accounts that were defined, we are going to create subnets in each of these VPCs defining Private and Public subnets split among different availability zones:

VPC CIDR Purpose Visual Subnet Calc
Shared
172.18.0.0/20 Primary Link
172.18.16.0/20 Secondary Link
172.18.32.0/20 Primary DR Link
172.18.48.0/20 Secondary DR Link
Apps-DevStg
172.18.64.0/20 Primary Link
172.18.80.0/20 Secondary Link
172.18.96.0/20 Primary DR Link
172.18.112.0/20 Secondary DR Link
Apps-DevStg EKS
10.2.0.0/16 Primary Link
Apps-DevStg EKS DemoApps
10.1.0.0/16 Primary Link
Apps-Prd
172.18.128.0/20 Primary Link
172.18.144.0/20 Secondary Link
172.18.160.0/20 Primary DR Link
172.18.176.0/20 Secondary DR Link
Network
172.20.0.0/20 Primary Link
172.20.16.0/20 Secondary Link
172.20.32.0/20 Primary DR Link
172.20.48.0/20 Secondary DR Link
Data-Science
172.19.0.0/20 Primary Link
172.19.16.0/20 Secondary Link
172.19.32.0/20 Primary DR Link
172.19.48.0/20 Secondary DR Link

Considerations

User guide

Please follow the steps below to orchestrate your base-network layer, 1st in your project-shared AWS account and afterwards in the necessary member accounts which will host network connected resources (EC2, Lambda, EKS, RDS, ALB, NLB, etc):

Network layer standard creation workflow

  1. Please follow Leverage's Terraform workflow for each of your accounts.
  2. We'll start by project-shared AWS Account Update (add | remove | customize) your VPC associated code before deploying this layer shared/base-network Main files
  3. Repeat for every AWS member Account that needs its own VPC Access AWS Organization member account
    consider repeating step 3. but for the corresponding member accounts.

Next Steps

📚 AWS VPC Peering