Examples

Every example below is ready to click into NetCalc Pro. The Load in tool ↗ button loads a single workspace; the Load all in tool ↗ button on multi-workspace examples replaces every workspace in the app with the full fleet at once.

AWS sizing: production VPCs in these examples use /14 (262 144 addresses) and staging VPCs use /15. The awsvpc CNI assigns one pod IP per container, so EKS and ECS Fargate exhaust a /16 quickly. Small / support VPCs (shared services, dev sandboxes, on-prem sites) stay at /16. Native AWS limits a single VPC primary CIDR to /16, so bigger account-level envelopes like these are typically implemented as one primary VPC plus one or more secondary CIDR blocks (commonly from 100.64.0.0/10 for EKS pod ranges).

Example 1 — Home lab / small office

A /20 (4 k addresses) carved into six VLAN-separated subnets. Covers a serious home lab or a small office with user, IoT, server, guest, management, and DMZ segments. Every tier has room for growth without bumping the parent mask.

Example 2 — Startup: one AWS account, one VPC

Production VPC for a web app on EKS (or ECS) with RDS backing data. Three availability zones. App tier carries the EKS pod IPs, so it's sized /16 per AZ — 65 k usable addresses each. The public tier sits at /20 and the data tier at /22. Real-world scale for a growing startup.

What to do next

• Export Infrastructure as Code → AWS Terraform for a ready-to-apply .tf file.
• Use the inline-editable table to tweak labels, VLANs, and AZs as the plan evolves — Tab rotates through the cells.
• Watch the Radar drawer on the right — any overlap, duplicate VLAN, or unlabelled tier shows up the moment it appears.

Example 3 — Mid-size company: 4 AWS accounts + 2 on-prem DCs

Four AWS accounts (shared services, prod, staging, dev) connected through a Transit Gateway, plus two on-premises data centers (HQ and a DR site) reaching AWS over Direct Connect or VPN. Every network gets a non-overlapping block out of the 10.0.0.0/12 envelope so prod-to-stage peering and VPN tunnels never collide. Production AWS gets a /14 envelope for EKS + RDS + ECS + Lambda ENI headroom.

Top-level CIDR allocation

Per-workspace plans

After loading

• Open Tools → VPC peering validator. It scans every pair of workspaces for CIDR overlap — all six blocks above are disjoint, so every pair comes back clean. Edit any workspace's parent to another's range to see the overlap report in action.
• Export each AWS workspace as Terraform separately so each account has its own state file and CI pipeline.
• Scan the Radar drawer on the prod workspace — it surfaces unlabelled subnets, duplicate VLANs, and cross-workspace overlaps continuously, no button-click required.

Example 4 — Enterprise: 15 AWS accounts

The hardest part of running a full AWS Organization is not losing track of which account owns which block. Overlapping CIDRs make Transit Gateway attachments and VPN tunnels fail the moment you connect two VPCs. The pattern below carves a 10.0.0.0/10 envelope (4 M addresses) into per-account blocks sized by workload: /14 for data-platform and business-unit production accounts (EKS + RDS + ECS + Lambda ENIs), /15 for staging, /16 for supporting workloads and sandboxes. Every account has enough room for secondary CIDRs if the primary VPC hits AWS's native /16 limit.

Top-level CIDR allocation — 15 accounts in one table

Representative VPC plans

Every business-unit account follows the same pattern — only the parent CIDR shifts. Two detailed plans are shown below: the network-hub (centralised egress and inspection) and one of the business-unit production VPCs. All 15 plans are included in the Load all bundle above.

Keeping 15 accounts conflict-free

• Post the allocation table above in your IPAM or pin it in your internal wiki. Every new account request references a single source of truth.
• Whenever you open a new account, copy the business-unit template, shift the parent to the account's envelope, and re-run the VPC peering validator across every open workspace. Any overlap gets flagged before you stand up a Transit Gateway attachment.
• Reserve the low-order /16 slots for shared accounts (core, security, network-hub). They peer with everything, so keep their CIDRs memorable and document the reservation.
• Keep several slots unallocated at the end of the envelope. Acquisitions, pilots, and workload splits always show up eventually, and pre-reserved blocks are cheaper than re-planning the tree.

Adapting an example

The host-count lists above are starting points. Change the inputs to match your actual workload, then re-run the VLSM Wizard to resize the tree. A few rules of thumb:

• Size EKS / ECS tiers by peak pod count, not node count. The awsvpc CNI gives every pod an IP from the subnet. Double it if you expect rolling deployments with both old and new pods present at once.
• Size the data tier small — databases live in a handful of subnets, not thousands.
• Use /27 or /28 for the public (NAT / ALB) tier unless you expect dozens of internet-facing endpoints.
• When in doubt, open Tools → Address Space Calculator first — it returns the recommended mask per tier before you touch the tree.
• When you open more than one workspace, run Tools → VPC peering validator after each addition — it catches CIDR overlaps before they cost you a failed peering request.