# cidrcalculator.net — Full Content for AI Ingestion > Free, browser-based CIDR / subnet calculator and network planning toolkit. IPv4 and IPv6. Multi-cloud (AWS, Azure, GCP, OCI). VLSM design, IaC export, IPAM-Lite, RFC validation, AI subnet design assistant, 109 learning lessons, 24 in-depth articles. This file contains the full text content of the site, formatted as markdown, for use by AI systems. All calculations on cidrcalculator.net run client-side; user data does not leave the browser. --- # Tools # About cidrcalculator.net A free CIDR toolkit for network engineers, cloud architects, and students. ## Our mission cidrcalculator.net was built to solve a small but persistent frustration: existing subnet calculators were either feature-poor, visually dated, or hidden behind enterprise pricing. We set out to build one tool that does everything an engineer needs — IPv4, IPv6, VLSM, cloud-aware sizing, Infrastructure-as-Code export, validation, and visualization — and keep it free to use. ## What makes us different - **Comprehensive** — over 60 features across calculation, design, validation, and export - **Cloud-aware** — built-in rules for AWS, Azure, GCP, OCI and Kubernetes - **Client-side** — all calculations happen in your browser; your CIDR ranges are not transmitted to our servers - **Standards-compliant** — calculations follow RFC 1918, RFC 4632, RFC 6598, RFC 4291 and related standards - **Free to use** — supported by non-intrusive advertising rather than subscriptions for core tools ## Who we serve Our users include: - Network engineers managing enterprise WANs and LANs - Cloud architects designing multi-cloud environments - DevOps and platform engineers generating Terraform and CloudFormation - Students preparing for CCNA, Network+, AWS Solutions Architect and similar certifications - Educators teaching networking fundamentals - Security teams reviewing ACLs and firewall rules ## How we sustain the service cidrcalculator.net is free for everyone. Core tools — calculator, VLSM designer, IPAM, IaC export, learning resources — are open and unrestricted. The site may carry display advertising in the future to support development costs; if it does, we'll disclose the networks in our privacy policy. We make this trade-off intentionally: we believe basic subnet math should never be gated behind a paywall, and that an ad-supported model makes the tool more sustainable than a freemium model that would force key features behind subscriptions. ## Accuracy & reliability While we work hard to ensure correctness, cidrcalculator.net is provided as an aid, not as a substitute for professional network engineering judgment. We strongly recommend reviewing all results before applying them to production networks. See our disclaimer for full details. ## Open standards All calculations follow published RFCs. Where cloud-specific behavior differs (e.g., reserved IPs in AWS VPC), we cite the source provider's documentation. Where conventions exist (e.g., RFC 6598 CGNAT range), we apply them transparently and explain them in the Learn section. ## Contact us Have feedback, found a bug, or want to suggest a feature? We'd love to hear from you. Visit the contact page or email contactus@cidrcalculator.net. --- # CIDR Calculator IPv4, IPv6, overlap detection, supernet aggregation, conversions — everything you need in one place. --- # Split & join subnets visually Design hierarchical networks with variable-length subnet masking. Click split to halve a subnet, join to merge children back. Starting NetworkStandard (2 reserved)AWS VPC (5 reserved)Azure VNet (5 reserved)GCP (4 reserved)Oracle Cloud (3 reserved)ResetJSON Copy CSV PDF ShareUse this networkTotal subnets**1**Total addresses**65,536**Usable hosts**65,534**Reserved IPs**2**Utilization**0%**Bulk Import Paste CIDR blocks (one per line) to load existing networks. ImportQuick Templates Start from a common architecture pattern. 3-tier app (web / app / db)Multi-AZ AWS VPCHub-and-spoke AzureKubernetes clusterHow VLSM works Variable Length Subnet Masking lets you carve a single network into multiple subnets of different sizes — perfect when you have one team needing 1000 hosts and another needing only 10. **Split:** halve a subnet (e.g. /24 → two /25s). **Join:** merge sibling subnets back together. Notes and color tags persist when you save or share. ## What VLSM solves Classical subnetting splits a parent block into equal-sized chunks. That wastes a lot of address space when your actual subnets need very different host counts. **Variable-Length Subnet Masking** lets you allocate a /24 for one tier, a /28 for another, and a /30 point-to-point link, all from the same parent — sized to demand, not to a fixed grid. This planner takes a parent CIDR and a list of required host counts, then computes the smallest prefix that fits each one, allocated in order from the largest. The output is ready to copy into your network documentation, drop into the IaC export tool for Terraform/CloudFormation/Pulumi, or save to a workspace project. ### When to use VLSM versus equal subnetting VLSM is the right choice whenever your subnets have meaningfully different sizes. Examples: - A **3-tier web app** with a small public subnet (a few load balancers), a medium app subnet (dozens of instances), and a small database subnet — three different sizes. - **Point-to-point links** using /30 or /31 alongside larger user subnets. - **Datacenter racks** where each rack needs 50-200 hosts and the count varies. If every subnet you need is the same size, equal subnetting via the main calculator is simpler. Use VLSM when the sizes differ. The subnetting by hosts vs subnets article explains the tradeoff in more depth. ### Background reading The VLSM explained article walks through a complete worked example. If you're using AWS, AWS VPC reserved IPs explains the 5-IP reservation that affects your usable-host counts. To go from a VLSM plan straight to deployable infrastructure code, see from subnet design to Terraform. ## Related tools CIDR CalculatorSingle-block inspection, overlap, and conversions.IaC ExportConvert your VLSM plan to Terraform / CloudFormation.VisualizeSee your allocation as a tree, bitmap, or topology.WorkspaceSave VLSM plans as named projects. ## Frequently asked questions ### What is VLSM and when should I use it? VLSM (Variable-Length Subnet Masking) is the practice of allocating subnets of different sizes from a parent network. Use it whenever your subnets have meaningfully different host counts. For example, a 3-tier web app might need a small public-facing subnet, a medium app-tier subnet, and a small database subnet — three different sizes from one parent VPC. If all your subnets are the same size, classical equal subnetting is simpler. ### How does VLSM differ from classful subnetting? Classful subnetting divides a parent network into equal-sized subnets, often wasting address space. VLSM allows subnets of varying sizes from the same parent. With VLSM you allocate subnets in order from largest to smallest, sizing each to demand. The result uses address space efficiently and supports modern network designs that classful addressing cannot. ### How do I size a VLSM subnet for N hosts? Find the smallest prefix that fits N hosts plus the required reserved addresses. For a standard subnet, you need N + 2 total addresses (network + broadcast reservations). Take the smallest power of 2 that is at least N + 2, then compute the prefix as 32 minus log2 of that power. For example, 50 hosts needs 52 addresses; the next power of 2 is 64, so prefix = 32 - 6 = /26. In cloud environments add the cloud's extra reservation count. ### Can I export a VLSM plan to Terraform? Yes. After designing your VLSM allocation here, the IaC Export tool converts the plan to Terraform, CloudFormation, Pulumi, CDK, Ansible, or Bicep. The exported code uses the cloud provider's reservation rules automatically. --- # Cloud-aware subnet planning Each cloud provider reserves a different number of IPs per subnet. Pick yours and we'll do the math. --- # Generate Terraform, CloudFormation & more Design your subnets once. Export to every major IaC format with one click. Network DesignVPC / VNet CIDRVPC nameRegionus-east-1 (N. Virginia)us-west-2 (Oregon)eu-west-1 (Ireland)ap-south-1 (Mumbai)ap-northeast-1 (Tokyo)Subnets+ AddTagsEnvironmentOwnerGenerated Code Copy Download Terraform AWSTerraform AzureTerraform GCPCloudFormationAzure BicepARMPulumi TSPulumi PythonAWS CDKAnsibleK8s NetPolicyCisco IOS ``` ``` Generated code accounts for cloud-specific reserved IPs. Review before applying to production. ## From subnet plan to deployable code The CIDR math is the easy part. The hard part is turning your subnet plan into Terraform, CloudFormation, Pulumi, CDK, Ansible, or Bicep that actually deploys. This page handles that conversion. Pick a target format and your VPC and subnet definitions become ready-to-commit infrastructure code. The generated code uses your chosen cloud provider's idioms — AWS resources for Terraform AWS, Bicep for Azure, CDK for either. Reserved-IP handling matches the cloud-aware calculator: if your subnet is sized for AWS reservations, the IaC respects that. For multi-size subnet plans, design them in VLSM first, then bring the result here. ### Which IaC tool to pick - **Terraform:** Cross-cloud, declarative, biggest community. Default choice if you don't have an existing toolchain. - **CloudFormation:** AWS-native, no extra tooling, integrated with AWS Stack management. - **Pulumi:** Same model as Terraform but written in real programming languages (TypeScript, Python, Go). Better for complex logic. - **AWS CDK:** AWS-native, written in code, compiles to CloudFormation under the hood. - **Bicep:** Azure-native equivalent of CloudFormation, replaces ARM templates. - **Ansible:** Imperative, good for environments where you also configure servers post-deploy. If you want to share or revisit your design, save it to a workspace project first — the workspace stores your inputs so you can regenerate the IaC later without re-entering them. ### Background reading The subnet design to Terraform article walks through a complete 3-tier VPC end-to-end. For deciding how subnets fit across clouds, see multi-cloud CIDR planning. ## Related tools Cloud-Aware CalculatorGet reservation-correct subnet sizes first.VLSM PlannerAllocate multi-size subnets from a parent VPC CIDR.WorkspaceSave your design and regenerate IaC anytime.AI AssistantDescribe your network in plain English first. ## Frequently asked questions ### Which IaC format should I pick for my subnet plan? Terraform if you want cross-cloud portability and the biggest community. CloudFormation if you are AWS-only and want native integration. Pulumi if you prefer a real programming language over HCL or YAML. AWS CDK if you want code-based AWS infrastructure. Bicep if you are Azure-only. Ansible if you also configure servers after deploy. There is no single best choice — pick what matches your existing toolchain. ### Does the generated Terraform handle cloud-provider reserved IPs? Yes. The exported code respects the reserved-IP counts of the target cloud automatically. If you sized a /28 in AWS expecting 11 usable hosts, the Terraform code creates that subnet correctly without warnings. The IaC export is designed to be deployable as-is. ### Can I import an existing VPC and get IaC back? Not directly — this tool generates IaC from a fresh CIDR plan, not from a live cloud account. To import existing infrastructure, use Terraform's terraform import command or AWS Former for CloudFormation. Use this tool when you are planning a new VPC or redesigning an existing one. ### Why does the exported code use /28 as the minimum? Because AWS requires a minimum subnet size of /28 (16 addresses, 11 usable after reservations). Azure requires /29 minimum for most services. GCP requires /29. OCI requires /30. The exported code uses each cloud's minimum and warns if your plan goes below it. --- # Plan networks in plain English 100 design patterns. Runs entirely in your browser. Zero API calls, zero cost, instant responses. 100design patterns12categories0msnetwork latency100%private (client-side)**Hi! I'm your network planning assistant.** Describe what you need and I'll generate a complete subnet design with reasoning. I recognize **100 distinct patterns** across cloud architectures, Kubernetes, VLSM, IPv6, security segmentation, and more. Try something like: - "3-tier AWS app in /16 across 3 AZs" - "K8s pod and service CIDRs for 5000 pods" - "Allocate 10.0.0.0/16 to teams of 500, 250, 100, 30 hosts" - "Office network for 200 employees with VLANs" - "How many hosts in /22?" Send **How it works:** A pattern-matching engine runs in your browser, recognizes intent + extracts parameters (CIDRs, host counts, cloud provider, AZ count), and generates designs using deterministic CIDR math. No LLM, no API calls, no data leaves your device. Designs are guaranteed mathematically correct. #### Example prompts --- # Network diagrams & topology export Auto-generated subnet trees, VPC topology and IP heatmaps. Export to PNG, SVG, Mermaid or draw.io. --- # CIDR validation & security checks Verify RFC compliance, flag CGNAT/bogons/multicast, detect risks before deploying. Validate a single CIDRValidateBatch validate Copy CSVPDF Paste multiple CIDRs (one per line) to validate them all at once. 10.0.0.0/8 192.168.1.0/24 172.16.0.0/12 100.64.0.0/10 169.254.0.0/16 224.0.0.0/4 255.255.255.0/32 fc00::/7Validate allCommon range reference #### Private networks (RFC 1918) 10.0.0.0/8Class A privateRoutable in private nets172.16.0.0/12Class B privateRoutable in private nets192.168.0.0/16Class C privateRoutable in private nets #### Special-use ranges 100.64.0.0/10CGNAT (RFC 6598)ISP carrier-grade NAT169.254.0.0/16Link-local (RFC 3927)Auto-config only127.0.0.0/8LoopbackLocal host only224.0.0.0/4MulticastMulticast group only240.0.0.0/4Reserved (Class E)Do not use192.0.2.0/24TEST-NET-1 (RFC 5737)Documentation only #### IPv6 special ranges ::1/128LoopbackLocal host onlyfe80::/10Link-localLocal link onlyfc00::/7Unique local (ULA)Private IPv62001:db8::/32Documentation (RFC 3849)Examples onlyff00::/8MulticastGroup addressing ## What gets validated This is the safety check that catches the boring-but-painful bugs. The validator inspects a CIDR against a battery of RFC compliance rules and well-known reserved-range checks. It flags: - **Host bits set** — e.g. someone wrote `192.168.1.5/24` when they meant `192.168.1.0/24`. The validator normalizes and warns. - **Reserved ranges (Class E)** — IANA reserved for future use, never to be deployed. - **Loopback (127.0.0.0/8)** — useful inside one host, harmful in a routing table. - **Link-local (169.254.0.0/16)** — auto-configured, not routable beyond the local link. - **Multicast (224.0.0.0/4)** — for group communication, not assignable to hosts. - **CGNAT (100.64.0.0/10)** — for ISPs, NOT for enterprise use (RFC 6598). - **TEST-NET ranges** — RFC 5737 reserved for documentation only. - **Very large or very small subnets** — flags /31 and /32 (special use only) and warns on /16 and larger. ### When to use bulk validation The single-CIDR validator is for spot-checking. The **bulk validator** takes a list of CIDRs and runs every check against each one — useful for auditing an existing network design, validating a firewall rule import, or screening an IP allowlist before deployment. Paste a list, get back a pass/warn/fail per line. If you find conflicts between subnets (overlap, containment), the overlap tool in the main calculator handles pairwise checks, and the IPAM tool tracks an inventory and flags new conflicts as you add allocations. ### Background reading For the differences between the RFC 1918 private ranges and RFC 6598 CGNAT space (a common source of validation failures), see RFC 1918 vs RFC 6598. For the more obscure reserved ranges that show up in surprising places, bogon IP ranges covers the lot. If your validation surfaced a real overlap in production, troubleshooting overlapping CIDRs is the recovery playbook. ## Related tools CIDR CalculatorInspect or run overlap checks on single blocks.IPAMInventory and conflict tracking at scale.VisualizeSee validation problems on a topology diagram.LearnLessons on RFC categories and special ranges. ## Frequently asked questions ### What does CIDR validation actually check? The validator runs each CIDR through a battery of RFC compliance checks: host bits set in the input, reserved ranges (Class E, multicast, loopback, link-local), private vs public classification, CGNAT detection, TEST-NET ranges, and edge cases like /31 and /32. The bulk validator runs the same checks against an entire list at once. ### Why does the validator warn about 100.64.0.0/10? Because 100.64.0.0/10 is the CGNAT range reserved under RFC 6598 for Internet Service Providers, not for enterprise networks. Using CGNAT space in your own network can collide with your ISP's NAT and cause unpredictable routing. The validator flags it so you do not deploy a network that may conflict in production. ### What is the difference between a bogon and a martian IP? A bogon is an IP address that should not appear on the public internet — including unallocated ranges, reserved ranges, and addresses from RFC 1918 private space. A martian is a stricter category: an IP that should not appear as a packet source or destination in normal routing. All martians are bogons; not all bogons are martians. The validator flags both categories. ### Can I validate an entire list of CIDRs at once? Yes. The bulk validator on this page accepts a newline-separated list and returns pass/warn/fail results for each entry. Use it for auditing firewall rule imports, validating IP allowlists before deployment, or screening a network design. --- # IP Address Management Track allocations, monitor utilization, flag conflicts. Saves locally in your browser — no signup, no server. Total subnets0across 0 parent networksAllocated IPs0no allocations yetConflicts0no overlapping rangesHigh utilization0no subnets above 80% ### Your IPAM inventory is empty Start tracking subnet allocations. Data stays in your browser — nothing is sent to a server. + Add first subnetLoad sample dataImport CSVSubnet Inventory Copy CSVPDFImport+ AddCIDRName / PurposeOwner / TagsStatusUtilizationAudit LogClearUtilization by parentQuick actionsRun conflict checkFind next free /24Export to CSVBackup as JSONReset all data ### Add subnet ×CIDR *Name / Purpose *OwnerStatusAllocatedReservedFreeUtilization (%)Tags (comma-separated)NotesCancelSave ### Import subnets × Paste CSV or one CIDR per line. Recognized columns: `cidr,name,owner,status,util,tags,notes`. Only `cidr` is required. CancelImport ## Why a browser-side IPAM Full IP Address Management products (Infoblox, BlueCat, NetBox) are powerful and expensive. For small teams that just need to track "who has which subnet" without standing up a server, a local inventory is plenty. This IPAM tool stores everything in your browser via localStorage — no account, no server, no leak. Export to CSV when you want to back it up or share with the team. It tracks allocations, surfaces conflicts as you add them, lets you tag and filter, and renders utilization. For full visual context, the visualizer reads from the same inventory and renders the topology. ### When IPAM matters - **Multiple environments** — dev, staging, prod each with their own subnets, easy to confuse without tracking. - **Multiple regions or VPCs** — once you have more than 2-3 VPCs, mental tracking breaks down. - **Team handoffs** — exporting the inventory to CSV beats explaining the address scheme verbally. - **Pre-deployment audits** — adding a new subnet here first will surface a conflict with an existing allocation before you push it to Terraform. For team-scale workflows that go beyond a single user's localStorage, workspace projects let you save and share full network designs via URL. Use IPAM for inventory and conflict detection; use Workspace for plan-and-iterate-with-collaborators. ### Background reading The IPAM for small teams article covers the workflow patterns this tool was built around. If conflicts keep cropping up across cloud accounts, multi-cloud CIDR planning walks through how to prevent them at the design stage. For dealing with conflicts that have already shipped to production, see troubleshooting overlapping CIDRs. ## Related tools WorkspaceSave and share named network projects.ValidatePre-screen CIDRs against RFC rules before adding.VisualizeRender the inventory as a heatmap or VPC diagram.VLSM PlannerDesign new allocations before adding them here. ## Frequently asked questions ### What is IPAM and when do I need it? IP Address Management (IPAM) tracks who owns which subnet across your network. You need IPAM when you have more than a handful of subnets across multiple environments, regions, or VPCs — at that point mental tracking breaks down. IPAM detects conflicts when you add new allocations, shows utilization, and exports inventory for handoffs. ### How does this IPAM tool differ from Infoblox or NetBox? This is a browser-side IPAM-Lite tool: all inventory lives in your browser's localStorage, no server, no signup. It is designed for small teams that need conflict tracking and CSV export without standing up infrastructure. Enterprise tools like Infoblox, BlueCat, and NetBox offer more features (DHCP integration, RBAC, audit logs) but require deployment and ongoing maintenance. ### Is my inventory data shared with anyone? No. The IPAM tool stores everything in your browser's localStorage. No data is transmitted to our servers or any third party. To back up or share your inventory, use the CSV export. ### Can I import an existing CSV into IPAM? Yes. The import button accepts a CSV file with columns for CIDR, name, owner, status, utilization, tags, and notes. The tool validates each row and surfaces any conflicts with existing entries before importing. --- # Your saved network designs Save subnet designs as named projects in your browser. No signup — everything stays local. Import/export to move between machines. Total projects0no projects yetTotal subnets0across 0 projectsTotal IPs tracked0none allocated yetStorage used0 KBbrowser localStorageAll tagsImportExport all New project ### No saved projects yet Create your first design or load sample data to see how it works. Everything stays in your browser — no signup. + Create first projectLoad sample dataImport JSON backupActivity FeedClearQuick share Generate a shareable link that encodes a project in the URL — no server needed. Copy linkTips - Projects live in your browser's localStorage - Use **Export all** to back up to a JSON file - Open the JSON on another machine via **Import** - Tag projects to filter big workspaces - Click any subnet to edit; drag to reorder ### Project ×NameTagParent CIDRCollaborators (comma-separated names)Description**Subnets**+ Add subnet Tip: paste a list of CIDRs (one per line) into the first row to import many at once. Delete projectExport thisSend to IPAMCancelSave ### Import projects × Paste a JSON backup file. Supports both single-project exports and full workspace backups from **Export all**. Merge with existing Replace everything CancelImport ## What the workspace is for The workspace stores named network projects — a parent VPC, its subnets, tags, owner notes, and collaborator handles. Unlike the in-memory work in other tools, a workspace project persists in localStorage and can be exported as a shareable URL. The intended workflow is iterative: design a network with the VLSM planner or AI assistant, save it as a project, share the URL with a teammate, iterate over time, and finally export to Terraform or CloudFormation when you're ready to deploy. Throughout, the inventory side of things lives in IPAM — workspace is for planning, IPAM is for tracking what's been deployed. ### When to use workspace vs IPAM Different tools for different stages: - **Workspace** is for *designs*: networks you're still iterating on, sharing with reviewers, or might never actually deploy. - **IPAM** is for *deployments*: subnets that exist in production and need conflict tracking, utilization monitoring, and owner attribution. A single network typically lives in workspace first while it's being designed, then moves to IPAM once it's been deployed. The two tools share storage conventions so transferring is straightforward — copy the subnet list from the workspace project and paste into IPAM. ### Background reading For working patterns that benefit from saved designs, see IPAM for small teams. If your workflow ends with deploying the design, subnet design to Terraform covers the export side. ## Related tools IPAMTrack deployed subnets with conflict detection.VLSM PlannerDesign the subnets that go into a project.IaC ExportGenerate deployable code from a saved project.AI AssistantGenerate a starting design from a plain-English brief. ## Frequently asked questions ### What is the difference between Workspace and IPAM? Workspace is for designs — networks you are still iterating on, sharing with reviewers, or might never actually deploy. IPAM is for deployments — subnets that exist in production and need conflict tracking, utilization monitoring, and ownership. A network typically lives in Workspace first while being designed, then moves to IPAM once it is deployed. ### Can I share a Workspace project with my team? Yes. Each project can be exported as a shareable URL that contains the design. Anyone with the URL can open the project in their browser and see the same subnets, tags, and notes. No account or login is required. ### Where is my Workspace data stored? Workspace projects are stored in your browser's localStorage. They persist across sessions but are not synced to any server. To move a project between browsers or share with others, use the shareable URL feature. --- # Help & documentation Everything you need to know about using cidrcalculator.net effectively. --- # Articles # How to Calculate Subnets by Hand (the magic number method) 9 min read·Published May 26, 2026·By cidrcalculator.net team If you can subnet in your head, you save 5 minutes of fumbling every time you set up a VLAN, write a firewall rule, or design a VPC. If you cannot, you either reach for a calculator or trust whatever the documentation says — both of which have failure modes. This article teaches the "magic number" method that lets you handle any subnetting question in under 30 seconds without binary arithmetic. If you just want the answer for a one-off calculation, our CIDR calculator will do it for you. But if you want to internalize subnet math so you can sanity-check tools and read configs at a glance, the method below is the foundation. ## The two things you must memorize Everything else builds on these: ### 1. Powers of 2 up to 256 2, 4, 8, 16, 32, 64, 128, 256. ### 2. The octet-to-bits table Octet valueBinaryLeading 1sMagic number (256-x)1281000000011281921100000026422411100000332240111100004162481111100058252111111006425411111110722551111111181 These eight values are the only ones that appear in a valid subnet mask octet (other than 0 or 255). The "magic number" column is what we will use to find subnet boundaries. ## The magic number method Given any CIDR like `192.168.10.42/26`, here is how to find the subnet it belongs to: - **Identify the interesting octet** — the one where the mask transitions from 255 to a smaller number. For /26, the mask is `255.255.255.192`, so the interesting octet is the fourth. - **Find the mask value in that octet**: 192. - **Compute the magic number**: 256 − 192 = 64. - **Subnets start at multiples of the magic number** in that octet: .0, .64, .128, .192. - **Find which subnet contains your host**: largest multiple of 64 that is ≤ 42 is 0. Subnet = `192.168.10.0/26`. - **Broadcast**: add (magic number − 1) to the subnet start: `192.168.10.63`. - **Usable range**: 1 above network, 1 below broadcast: `192.168.10.1 – 192.168.10.62`. ## Worked example: /20 Find the subnet for `10.30.71.5/20`. - /20 mask = `255.255.240.0`. Interesting octet = 3rd (value 240). - Magic number = 256 − 240 = 16. - Subnets in the third octet at: 0, 16, 32, 48, 64, 80, 96... - Host has 71 in the third octet. Largest multiple of 16 ≤ 71 is 64. - Subnet = `10.30.64.0/20`. - Broadcast = `10.30.79.255` (third octet = 64 + 16 − 1 = 79; fourth octet = 255). - Usable hosts = `10.30.64.1 – 10.30.79.254` (4,094 hosts). ## Worked example: /27 Find the subnet for `172.16.4.200/27`. - /27 mask = `255.255.255.224`. Interesting octet = 4th (value 224). - Magic number = 256 − 224 = 32. - Subnets in the fourth octet at: 0, 32, 64, 96, 128, 160, 192, 224. - Host has 200 in the fourth octet. Largest multiple of 32 ≤ 200 is 192. - Subnet = `172.16.4.192/27`. - Broadcast = `172.16.4.223`. - Usable hosts = `172.16.4.193 – 172.16.4.222` (30 hosts). ## What about /22, /23? The same method works for shorter prefixes — the interesting octet just moves left. For `10.0.6.42/22`: - /22 mask = `255.255.252.0`. Interesting octet = 3rd (value 252). - Magic number = 256 − 252 = 4. - Subnets in third octet at: 0, 4, 8, 12, 16, 20, 24... - Host has 6 in third octet. Largest multiple of 4 ≤ 6 is 4. - Subnet = `10.0.4.0/22`. - Broadcast = `10.0.7.255` (third octet = 4 + 4 − 1 = 7). - Usable hosts = `10.0.4.1 – 10.0.7.254` (1,022 hosts). ## Host count for any prefix Usable hosts = `2^(32 − prefix) − 2`. For mental math: - /24 = 2^8 − 2 = 254 - /25 = 2^7 − 2 = 126 - /26 = 2^6 − 2 = 62 - /27 = 2^5 − 2 = 30 - /28 = 2^4 − 2 = 14 Each step shorter doubles the usable count: /23 = 510, /22 = 1,022, /21 = 2,046. ## Sizing subnets for N hosts Given a host count requirement, find the smallest power of 2 that is at least `N + 2`, then the prefix is `32 − log₂(that power)`. - Need 25 hosts → 25 + 2 = 27 → next power of 2 is 32 → prefix = 32 − 5 = **/27** (30 usable, 5 to spare). - Need 200 hosts → 200 + 2 = 202 → next power of 2 is 256 → prefix = 32 − 8 = **/24** (254 usable, 54 to spare). - Need 1000 hosts → 1000 + 2 = 1002 → next power of 2 is 1024 → prefix = 32 − 10 = **/22** (1022 usable, 22 to spare). ## Common mistakes to avoid - **Forgetting the −2.** A /27 has 32 total addresses but only 30 usable. The network and broadcast are not assignable. - **Misaligning the magic number.** Subnets *must* start at multiples of the magic number. `10.0.0.5/27` is not a valid subnet — it gets normalized to `10.0.0.0/27` (containing .5). - **Treating /31 like a regular subnet.** /31 has 2 usable hosts per RFC 3021 — it has no network or broadcast. Used on point-to-point links. See our article on /30 vs /31. - **Forgetting cloud reservations.** AWS reserves 5 IPs per subnet. A /28 has 14 usable normally but only 11 on AWS. ## When to skip the math Mental subnet math is great for quick sanity checks, but for any production design you should still use a tool to catch typos and edge cases. Use our CIDR calculator for one-off conversions and the VLSM Designer for full subnet planning. The Validate tool catches overlaps in a list of CIDRs. ## Key takeaways - The **magic number is 256 − the mask value in the interesting octet**. Subnets start at multiples of it. - Find the subnet by rounding the host's octet down to the nearest multiple of the magic number. - Broadcast = subnet start + magic number − 1 in the interesting octet, with .255 in any following octets. - Usable hosts = `2^(32-prefix) − 2` (except /31 = 2, /32 = 1). - For N hosts needed, round `N + 2` up to the next power of 2 and derive the prefix. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Career #### The CCNA Subnetting Questions That Trip People Up If you are studying for the CCNA, here are the eight subnetting question patterns that consistently cause failure. Each one is solvable in 3... 8 min readFundamentals #### The Complete Subnet Mask Cheat Sheet (/0 to /32 with examples) Full reference table of IPv4 subnet masks from /0 to /32: prefix, dotted decimal, hex, host count, AWS usable, and common use cases. Printab... 7 min readFundamentals #### VLSM Explained: Variable-Length Subnet Masking from Scratch VLSM lets you allocate different-sized subnets from one parent network without wasting addresses. This worked example shows the largest-firs... 10 min readFundamentals #### Subnetting by Host Count vs by Subnet Count The two ways to approach a subnetting problem: by required hosts per subnet, or by required number of subnets. Same answers usually, but the... 7 min read --- # VLSM Explained: Variable-Length Subnet Masking from Scratch 10 min read·Published May 26, 2026·By cidrcalculator.net team Before VLSM (Variable-Length Subnet Masking), networks had to use uniform subnet sizes — every subnet of a parent network had the same prefix. If you had a `/16` and split it into `/24`s, you got 256 equal subnets whether you needed them or not. A four-person admin team got the same 254 addresses as a 250-person sales team. The result was massive waste. VLSM lets you use **different prefix lengths within one parent network**. The admin team gets a `/27` (30 hosts), sales gets a `/24` (254 hosts), and the address space is allocated efficiently. This is the modern default, and it is the only realistic way to size networks for cloud or enterprise scale. This article shows you how VLSM actually works through a worked example, explains the strict alignment rules, and walks through the common mistakes that cause re-IPing pain later. If you want to skip the math and just design VLSM allocations interactively, use our VLSM Designer. ## The fundamental rule: largest first VLSM allocation always proceeds from the largest subnet to the smallest. This is not a preference — it is a structural requirement. If you allocate small subnets first, you create unallocatable holes in the address space. Here is why. CIDR blocks must align on a boundary that is a multiple of their own size. A `/24` (256 addresses) must start at a multiple of 256 (`10.0.0.0`, `10.0.1.0`, `10.0.2.0`...). A `/22` (1024 addresses) must start at a multiple of 1024 (`10.0.0.0`, `10.0.4.0`, `10.0.8.0`...). If you allocate two `/27`s at the start of a `/24`, you have consumed `10.0.0.0` through `10.0.0.63`. Now suppose you need a `/25` (128 addresses). It must start at `.0` or `.128`. The `.0` spot is taken, so the `/25` goes at `.128` — and `.64` through `.127` is wasted forever. Allocating the `/25` first would have put it at `.0–.127`, leaving `.128` through `.255` for the two `/27`s with no waste. ## Worked example: a small office network Suppose you have `192.168.0.0/22` (1,022 usable addresses) and need to allocate for these teams: TeamHosts neededMinimum prefixUsable hostsSales250/24254Engineering120/25126Marketing60/2662Operations28/2730Admin10/2814Lab (point-to-point)2/302 Total hosts needed: 470. Total usable available in the /22: 1,022. There is plenty of room, but only if we allocate in the right order. ### Step 1: Allocate the /24 (Sales, largest) ``` 192.168.0.0/24 Sales (192.168.0.0 - 192.168.0.255) ``` ### Step 2: Allocate the /25 (Engineering) The next available aligned `/25` position is `192.168.1.0`: ``` 192.168.0.0/24 Sales (192.168.0.0 - 192.168.0.255) 192.168.1.0/25 Engineering (192.168.1.0 - 192.168.1.127) ``` ### Step 3: Allocate the /26 (Marketing) Next aligned `/26` position is `192.168.1.128`: ``` 192.168.0.0/24 Sales (192.168.0.0 - 192.168.0.255) 192.168.1.0/25 Engineering (192.168.1.0 - 192.168.1.127) 192.168.1.128/26 Marketing (192.168.1.128 - 192.168.1.191) ``` ### Step 4: Allocate the /27 (Operations) ``` 192.168.1.192/27 Operations (192.168.1.192 - 192.168.1.223) ``` ### Step 5: Allocate the /28 (Admin) ``` 192.168.1.224/28 Admin (192.168.1.224 - 192.168.1.239) ``` ### Step 6: Allocate the /30 (Lab P2P) ``` 192.168.1.240/30 Lab (192.168.1.240 - 192.168.1.243) ``` ### Final allocation ``` 192.168.0.0/24 Sales 254 usable 192.168.1.0/25 Engineering 126 usable 192.168.1.128/26 Marketing 62 usable 192.168.1.192/27 Operations 30 usable 192.168.1.224/28 Admin 14 usable 192.168.1.240/30 Lab 2 usable == Free == 192.168.1.244 - 192.168.3.255 (768 addresses available for growth) ``` Every team has just enough space, the allocations are contiguous, and the remaining 768 addresses are aligned to multiple useful prefixes for future allocations (`/24`, `/23`, smaller). ## Sizing rule: round up to a power of 2 To find the right prefix for N hosts, find the smallest power of 2 that is at least `N + 2` (the +2 accounts for network and broadcast addresses). Then the prefix is `32 − log₂(that power)`. Hosts neededPower of 2PrefixUsable2 (P2P)4/3021016/28143032/27305064/2662120128/25126250256/24254500512/2351010001024/221,022 For cloud environments, remember that AWS, Azure, and GCP reserve additional addresses per subnet. See our guide on AWS reserved IPs for the exact counts. ## Common VLSM mistakes ### Allocating small subnets first The most common mistake, covered above. If your tool or process does not enforce largest-first, you will fragment the address space and lose room for larger future allocations. ### Forgetting alignment Engineers sometimes try to "tighten" allocations by putting a `/24` at `10.0.0.128` instead of `10.0.0.0` or `10.0.1.0`. This is invalid — the network address would have non-zero host bits, which breaks routing. Most tools quietly normalize the input to the nearest valid network address, which may not be what you intended. ### Not leaving headroom If you allocate exactly the addresses you need today, the first team that grows by 10% will force a re-IPing operation. The standard practice is to **round up by one prefix length** beyond the minimum, then leave the rest of the parent network unallocated as growth space. The /22 example above naturally has 768 addresses of headroom because the teams are small relative to the parent. ### Mixing VLSM with discontiguous subnets If you split a `/16` into `/24`s across two physical sites and use them non-contiguously (e.g., site A uses `10.0.1.0/24` and `10.0.3.0/24`, site B uses `10.0.2.0/24` and `10.0.4.0/24`), older routing protocols cannot summarize correctly. Modern routing (OSPF, IS-IS, BGP, EIGRP) handles this, but the operational complexity is unnecessary. Always allocate contiguous blocks per site. ## VLSM in cloud environments Cloud VPCs are the modern application of VLSM. A typical AWS VPC layout uses VLSM principles even if you do not think of it that way: large `/20` subnets for application tiers, medium `/24` subnets for databases, and tiny `/28` subnets for VPN endpoints and transit gateways. All allocated from one parent VPC CIDR like `10.0.0.0/16`. The key extra constraint in cloud is that AWS, Azure, and GCP reserve addresses per subnet, so your usable counts are 3-5 fewer than the VLSM math predicts. Our Cloud calculator handles this automatically. ## Subnetting practice and tooling Doing VLSM by hand is a useful skill (and shows up on certification exams — see our CCNA subnetting question patterns), but for production work you should always use a tool. The cost of getting a subnet allocation wrong is usually a multi-hour maintenance window to re-IP a workload, so verify before you commit. - Our VLSM Designer handles arbitrary host requirements, applies the largest-first rule, and exports the result as CSV or to our IaC Export tool. - The Validate tool checks a list of existing CIDRs for overlaps before you commit. - The IPAM-Lite tracker records your allocations and warns about conflicts when you add a new entry. ## Key takeaways - VLSM lets you allocate different prefix lengths within one parent network. Always **allocate largest first**. - Each subnet must align on a boundary that is a multiple of its size. You cannot put a `/24` at `10.0.0.128`. - For N hosts, round up to the next power of 2, add 2 for network and broadcast, and compute the prefix from there. - Leave headroom — round one prefix length above the minimum, or leave the parent network's remaining space unallocated for growth. - In cloud, subtract 3-5 reserved addresses per subnet from the usable count. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Fundamentals #### How to Calculate Subnets by Hand (the magic number method) The magic number method lets you find any subnet, broadcast address, or host count in under 30 seconds without binary math. Worked examples ... 9 min readFundamentals #### The Complete Subnet Mask Cheat Sheet (/0 to /32 with examples) Full reference table of IPv4 subnet masks from /0 to /32: prefix, dotted decimal, hex, host count, AWS usable, and common use cases. Printab... 7 min readCloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readFundamentals #### Subnetting by Host Count vs by Subnet Count The two ways to approach a subnetting problem: by required hosts per subnet, or by required number of subnets. Same answers usually, but the... 7 min read ## Frequently asked questions ### What does VLSM stand for? VLSM stands for Variable-Length Subnet Masking. It is the technique of allocating subnets of different prefix lengths from a single parent network, allowing each subnet to be sized to its actual host demand rather than forcing a fixed grid. ### Why was VLSM invented? Before VLSM, networks had to use uniform subnet sizes. Every subnet of a parent network had the same prefix length, which wasted address space whenever subnets had different host requirements. VLSM was standardized in RFC 1812 to allow flexible subnet sizing within a single parent block. ### How do you calculate subnets using VLSM? Sort your subnet requirements from largest to smallest by host count. For each subnet, find the smallest prefix that fits the required hosts plus reserved addresses. Allocate each subnet starting from the parent's network address, in order of decreasing size. This minimizes wasted space and prevents fragmentation. ### Can VLSM be combined with cloud subnet rules? Yes. When sizing VLSM subnets for AWS, Azure, GCP, or OCI, add the cloud's reservation count to your host requirement. For example, 50 hosts in AWS needs 50 + 5 = 55 addresses; the next power of 2 is 64, so the subnet is /26. --- # The Complete Subnet Mask Cheat Sheet (/0 to /32 with examples) 7 min read·Published May 26, 2026·By cidrcalculator.net team This is the reference table you reach for when you need to remember whether a `/22` is 1,022 or 1,024 hosts, or what dotted-decimal mask matches `/27`. Bookmark this page, or download the printable cheat sheet from our home page. The table covers all 33 prefix lengths (/0 to /32) with the standard fields: dotted-decimal mask, hex, total addresses, usable hosts (RFC 1812), AWS-usable count (after AWS's 5-IP reservation), and typical use cases. ## Full table: /0 to /32 PrefixMaskTotalUsableAWS UsableTypical use/00.0.0.04.29B——Default route/8255.0.0.016.7M16.7M—Class A, full RFC1918 (10/8)/12255.240.0.01.05M1.05M—RFC1918 (172.16/12), cloud allocation/16255.255.0.065,53665,53465,531Class B, AWS max VPC/17255.255.128.032,76832,76632,763Large VPC tier/18255.255.192.016,38416,38216,379EKS cluster pod CIDR/19255.255.224.08,1928,1908,187Large workload subnet/20255.255.240.04,0964,0944,091Standard AWS app tier per AZ/21255.255.248.02,0482,0462,043Medium subnet/22255.255.252.01,0241,0221,019EKS node group subnet/23255.255.254.0512510507Medium workload subnet/24255.255.255.0256254251Class C, standard subnet, DB tier/25255.255.255.128128126123Small DB tier/26255.255.255.192646259Specialized service subnet/27255.255.255.224323027VPC endpoint subnet/28255.255.255.240161411AWS minimum subnet, TGW attach/29255.255.255.24886—Azure minimum, small P2P range/30255.255.255.25242—Standard P2P link/31255.255.255.25422—RFC 3021 P2P (no network/broadcast)/32255.255.255.25511—Single host route, loopback Prefixes between /8 and /16 not shown above follow the same pattern. The total address count for any /N is exactly `2^(32-N)`. Usable (RFC 1812) is total minus 2 for the network and broadcast addresses, except /31 (2 usable per RFC 3021) and /32 (1 usable). ## Conversion tricks ### Prefix to dotted-decimal mask The mask has `N` consecutive 1 bits followed by `(32-N)` 0 bits. To convert mentally: - Divide the prefix by 8 to find the number of complete `255` octets. - The remainder is the number of leading 1 bits in the next octet. - Map the remainder using the octet table (below). Leading 1sOctet valueMagic number (256 − value)00256112812821926432243242401652488625247254282551 Example: /22 → 22 ÷ 8 = 2 remainder 6. Two complete 255 octets, then 252 (6 leading 1s), then zeros. Mask = `255.255.252.0`. Magic number for /22 in the third octet = 4. ### Mask to wildcard mask Wildcard = inverse of subnet mask. For each octet: `wildcard = 255 - mask`. PrefixSubnet maskWildcard mask/24255.255.255.00.0.0.255/22255.255.252.00.0.3.255/16255.255.0.00.0.255.255 Used in Cisco ACLs and OSPF area declarations. See our wildcard mask article for details. ## Cloud-specific reserved IP counts The "AWS Usable" column above subtracts 5 from the standard usable count. For other clouds: ProviderReserved per subnetMinimum subnetAWS VPC5/28Azure VNet5/29Google Cloud VPC4/29Oracle Cloud3/30 For full AWS specifics see our AWS reserved IPs deep dive. ## Calculator and quick reference For one-off lookups, paste any CIDR into our CIDR calculator and get the network address, broadcast, usable range, and cloud-mode numbers instantly. For interactive visualization of how a /24 splits into /26s splits into /28s, use our subnet visualizer. ## Key takeaways - **Total addresses** in /N = `2^(32-N)`. **Usable hosts** = total − 2 (except /31 and /32). - Subtract 5 from usable for AWS subnets, 5 for Azure, 4 for GCP, 3 for OCI. - Minimum cloud subnets: AWS /28, Azure /29, GCP /29, OCI /30. - Magic number for any prefix = 256 − (octet value at the prefix boundary). Use it for fast mental subnet math. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Fundamentals #### How to Calculate Subnets by Hand (the magic number method) The magic number method lets you find any subnet, broadcast address, or host count in under 30 seconds without binary math. Worked examples ... 9 min readFundamentals #### VLSM Explained: Variable-Length Subnet Masking from Scratch VLSM lets you allocate different-sized subnets from one parent network without wasting addresses. This worked example shows the largest-firs... 10 min readCareer #### The CCNA Subnetting Questions That Trip People Up If you are studying for the CCNA, here are the eight subnetting question patterns that consistently cause failure. Each one is solvable in 3... 8 min readFundamentals #### Subnetting by Host Count vs by Subnet Count The two ways to approach a subnetting problem: by required hosts per subnet, or by required number of subnets. Same answers usually, but the... 7 min read --- # Subnet Mask vs Wildcard Mask: ACLs, OSPF, and Quick Conversion 7 min read·Published May 26, 2026·By cidrcalculator.net team If you have configured a Cisco ACL or OSPF network statement, you've seen syntax like `192.168.10.0 0.0.0.255` instead of `192.168.10.0/24`. That second number is a **wildcard mask** — the inverse of a subnet mask, where 0 bits mean "must match" and 1 bits mean "don't care." Wildcard masks exist because Cisco's earlier syntax used them, and they have stuck around in IOS and IOS XE. Modern configs increasingly use prefix-length notation, but you still encounter wildcards in ACLs and OSPF network statements. This article explains how to convert between the two, why wildcard masks exist, and the edge cases where non-contiguous wildcards matter. ## The basic conversion For each octet: `wildcard = 255 − subnet_mask`. PrefixSubnet maskWildcard mask/8255.0.0.00.255.255.255/16255.255.0.00.0.255.255/20255.255.240.00.0.15.255/22255.255.252.00.0.3.255/24255.255.255.00.0.0.255/25255.255.255.1280.0.0.127/26255.255.255.1920.0.0.63/27255.255.255.2240.0.0.31/28255.255.255.2400.0.0.15/30255.255.255.2520.0.0.3/32255.255.255.2550.0.0.0 (or host keyword) The wildcard for a /N is just the size of the subnet minus 1, expressed as a 32-bit number. /24 has 256 addresses, wildcard is 255 (= 256-1) in the last octet. ## How wildcard matching works A wildcard mask is a bitmask: - **0 bit** = this bit must match exactly - **1 bit** = this bit is "don't care" (matches either 0 or 1) For `192.168.10.0 0.0.0.255`: the first 24 bits must match exactly (192.168.10), and the last 8 bits are wildcarded (any value 0-255). This matches the entire /24 range from 192.168.10.0 to 192.168.10.255. ## Where you actually see wildcard masks ### Cisco IOS ACLs ``` access-list 10 permit 192.168.10.0 0.0.0.255 access-list 10 permit 10.0.0.0 0.0.0.255 access-list 10 deny any ``` The first line matches `192.168.10.0/24`, the second matches `10.0.0.0/24` (note: not 10/8!), the third denies everything else. ### OSPF network statements ``` router ospf 1 network 10.0.0.0 0.0.0.255 area 0 network 10.0.1.0 0.0.0.255 area 1 network 192.168.10.0 0.0.0.255 area 0 ``` Specifies which interfaces participate in OSPF and which area they belong to. ### BGP neighbor / route-map matches ``` ip prefix-list MY_PREFIXES seq 10 permit 10.0.0.0/8 le 24 ``` BGP usually uses prefix lists (CIDR-native), not wildcards. But older configs sometimes still use wildcard-masked ACLs. ## The /32 host shortcut For a single host, instead of writing `192.168.10.42 0.0.0.0`, Cisco accepts: ``` access-list 10 permit host 192.168.10.42 ``` And for any source, instead of `0.0.0.0 255.255.255.255`: ``` access-list 10 permit any ``` These keywords are common in production ACLs and you should recognize them. ## Non-contiguous wildcards Here is where wildcards reveal their power. Unlike subnet masks (which are always contiguous 1s followed by contiguous 0s), **wildcard masks can have non-contiguous bits**. This lets you match patterns that subnet masks cannot express. Example: match all hosts on even-numbered /24s in `10.0.0.0/16` (10.0.0.0/24, 10.0.2.0/24, 10.0.4.0/24, ...): ``` access-list 10 permit 10.0.0.0 0.0.254.255 ``` The wildcard `0.0.254.255` in binary: `00000000.00000000.11111110.11111111`. The third octet's lowest bit is 0 (must match), making only addresses with that bit = 0 (even values) match. This is mostly an esoteric pattern in modern networks. It's useful for matching odd/even VLANs or for compactly expressing certain firewall patterns, but most engineers will never need it. Mentioning it because it explains *why* wildcards exist instead of just using subnet masks: they are strictly more expressive. ## Conversion shortcut For typical subnet masks (contiguous 1s), the conversion is mechanical: - Find the wildcard's value in the interesting octet: `256 - mask_value - 1`. - The wildcard has 0s in all "255" octets of the mask and 255s in all "0" octets. For /22 (mask 255.255.252.0): wildcard third octet = 256 - 252 - 1 = 3. Wildcard fourth octet = 255 (subnet mask 0). Wildcard first two octets = 0 (subnet mask 255). Result: `0.0.3.255`. ## Common wildcard mask mistakes - **Writing the wildcard as a subnet mask.**`access-list 10 permit 10.0.0.0 255.0.0.0` is wrong — IOS will use the value as a wildcard, which means "match only 10.x.0.0 hosts where x can be anything, with the second and third octets being 0." Almost certainly not what you wanted. - **Misreading non-contiguous wildcards.** If you see `0.0.255.7`, it is unusual and probably intentional. Don't "simplify" it without understanding what was intended. - **Forgetting OSPF wildcards match interfaces, not networks.** OSPF wildcards select which interfaces participate, based on their IP. If you have an interface at 10.0.0.1 and you write `network 10.0.0.0 0.0.0.255 area 0`, that interface joins area 0. ## Migrating from wildcards to prefix-list Modern IOS supports prefix-list and CIDR-native syntax in most places. The transition: ``` ! Old: ACL with wildcard access-list 10 permit 10.0.0.0 0.255.255.255 ! New: prefix-list with CIDR ip prefix-list ALLOW_RFC1918 seq 10 permit 10.0.0.0/8 ``` For new configs, prefer prefix-list and CIDR notation. They are easier to read, less error-prone, and more expressive (you can specify `le` and `ge` bounds for prefix length). ## Key takeaways - Wildcard = inverse of subnet mask. **0 means match, 1 means don't care**. - Conversion: each octet's wildcard = 255 − that octet's subnet mask value. - Used in Cisco IOS ACLs, OSPF network statements, and route-maps. - Wildcards can be non-contiguous (unlike subnet masks), enabling patterns like "match all odd VLANs." - Use the `host` and `any` keywords for /32 and 0.0.0.0/0 shortcuts. - For new configs, prefer prefix-lists and CIDR notation over ACLs with wildcard masks. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Fundamentals #### The Complete Subnet Mask Cheat Sheet (/0 to /32 with examples) Full reference table of IPv4 subnet masks from /0 to /32: prefix, dotted decimal, hex, host count, AWS usable, and common use cases. Printab... 7 min readFundamentals #### How to Calculate Subnets by Hand (the magic number method) The magic number method lets you find any subnet, broadcast address, or host count in under 30 seconds without binary math. Worked examples ... 9 min readCareer #### The CCNA Subnetting Questions That Trip People Up If you are studying for the CCNA, here are the eight subnetting question patterns that consistently cause failure. Each one is solvable in 3... 8 min readFundamentals #### VLSM Explained: Variable-Length Subnet Masking from Scratch VLSM lets you allocate different-sized subnets from one parent network without wasting addresses. This worked example shows the largest-firs... 10 min read --- # Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) 8 min read·Published May 26, 2026·By cidrcalculator.net team If you have ever created a tiny `/28` subnet in AWS expecting 14 usable addresses and only got 11, you have run into one of the more confusing parts of AWS VPC design. AWS reserves **five IP addresses** in every subnet you create. Two are the standard network and broadcast addresses you would expect on any IPv4 subnet; the other three are AWS-specific reservations used by the platform itself. This article explains exactly which addresses AWS reserves, why those choices were made, the implications for subnet sizing, and how to plan VPC capacity so you do not run into ENI exhaustion under load. If you are starting a greenfield VPC design, you can run the numbers in our Cloud subnet calculator with AWS mode enabled. ## The five reserved addresses, explained In any AWS subnet, regardless of size, these five addresses are not available to assign to your EC2 instances, ENIs, Lambda functions, or anything else: AddressPurpose.0Network address (standard IPv4 reservation).1VPC router (default gateway for the subnet).2DNS resolver (Amazon-provided DNS).3Reserved by AWS for future uselastBroadcast address (standard IPv4 reservation, AWS does not actually broadcast) For a `/24` subnet at `10.0.0.0/24`, the reserved addresses are `10.0.0.0`, `10.0.0.1`, `10.0.0.2`, `10.0.0.3`, and `10.0.0.255`. That leaves **251 usable addresses** instead of the 254 you would expect on a non-AWS network. ## Why three AWS-specific reservations? The `.1` address being the gateway is intuitive: every subnet needs a default gateway, and AWS picked the first usable address. The `.2` reservation for the Amazon-provided DNS resolver (the one your VMs reach at `10.0.0.2` if your VPC is `10.0.0.0/16`) is more AWS-specific. Without an integrated resolver, you would need to deploy and manage DNS servers in every VPC. The `.3` address is reserved for future use but has been unused for over a decade. AWS has not removed it because doing so would change the behavior of millions of existing VPCs. The practical consequence: on small subnets, the AWS overhead is significant. A `/28` has 16 total addresses and only **11 are usable** — that is a 31% loss to reserved addresses. By contrast, a non-cloud `/28` would give you 14 usable. ## The /28 minimum and the /16 maximum AWS enforces a minimum subnet size of `/28`. Below that, the platform refuses to create the subnet. The rationale is the math above: `/29` (8 total addresses) would leave only 3 usable after the 5 reservations, which is too tight for any real workload. The maximum subnet size is `/16` (65,536 addresses). Larger subnets are not supported even if your VPC itself is bigger — for example, a `/15` or `/14` VPC must be carved into multiple `/16`-or-smaller subnets. Subnet sizeTotal addressesAWS usableCommon use/281611Transit subnets, VPN endpoints/273227Small internal services/266459Mid-sized service subnets/24256251Standard application subnets/2210241019Large workload subnets, EKS/2040964091EKS clusters, large microservice fleets/1665,53665,531Whole VPC tier (max single subnet size) ## The hidden cost: ENIs, not just instances The single biggest mistake in AWS subnet sizing is planning for the number of EC2 instances rather than the number of **ENIs (Elastic Network Interfaces)**. Several AWS services create ENIs dynamically in your subnets, each consuming one address from the pool. - **EC2 instances** consume 1 ENI per instance by default, but larger instance types support multiple ENIs and many secondary IPs. - **Lambda functions** in a VPC create Hyperplane ENIs on cold start. At high concurrency the pool can drain quickly. - **AWS Fargate** tasks each get their own ENI. - **RDS, ElastiCache, ELB, MSK, OpenSearch** all create ENIs in your subnets when they launch. - **EKS pods** using the VPC CNI plugin consume ENIs and secondary IPs from your VPC. See our article on EKS VPC CNI prefix delegation for the deep dive. A subnet sized correctly for 100 EC2 instances can run out of addresses with only 30 EC2 instances if you are also running Lambda, Fargate, and RDS in the same subnet. ## How to plan VPC capacity properly The general rule for production AWS workloads: **plan for 4-10x your expected peak ENI count**. A `/24` subnet (251 usable) comfortably supports about 50 mixed workloads (instances + Lambda + Fargate + managed services). A `/22` (1,019 usable) supports about 250. A typical greenfield three-tier production VPC looks like this: ``` 10.0.0.0/16 # VPC (65,531 usable) +-- 10.0.0.0/20 (4091) # web-tier-az-a +-- 10.0.16.0/20 (4091) # web-tier-az-b +-- 10.0.32.0/20 (4091) # web-tier-az-c +-- 10.0.48.0/20 (4091) # app-tier-az-a +-- 10.0.64.0/20 (4091) # app-tier-az-b +-- 10.0.80.0/20 (4091) # app-tier-az-c +-- 10.0.96.0/24 (251) # db-tier-az-a (small, RDS only) +-- 10.0.97.0/24 (251) # db-tier-az-b +-- 10.0.98.0/24 (251) # db-tier-az-c +-- 10.0.99.0/28 (11) # tgw-attachment-az-a +-- 10.0.99.16/28 (11) # tgw-attachment-az-b +-- 10.0.99.32/28 (11) # tgw-attachment-az-c +-- 10.0.100.0/22 (1019) onward # reserved for future ``` This gives every workload tier enough headroom for serverless and managed-service ENIs to grow into, while keeping database and transit subnets appropriately small. You can model this exact layout in our VLSM Designer and export it as Terraform with the IaC Export tool. ## What happens when you run out of IPs? This is the failure mode every AWS architect dreads. When a subnet has no free addresses left: - New EC2 launches fail with **InsufficientFreeAddressesInSubnet** - Lambda cold starts fail; concurrency drops to zero - Fargate tasks fail to launch - RDS/ElastiCache scale-up operations fail - EKS pod scheduling fails (with VPC CNI) The fixes are all painful at production scale: - **Add a secondary CIDR to the VPC.** Up to 4 secondary CIDRs are allowed, including from CGNAT space (`100.64.0.0/10`). Newer subnets can use the secondary range. - **Re-IP affected workloads** to larger subnets. Requires recreating ELBs, sometimes Auto Scaling groups, and is a maintenance window operation. - **Migrate EKS clusters** to use VPC CNI prefix delegation (which packs 16 pods per ENI instead of 1 per IP) and/or move pods to a CGNAT secondary CIDR. ## Comparison with other clouds AWS is not alone in reserving addresses, but it reserves the most. Here is how the major clouds compare: ProviderReserved per subnetMinimum subnetNotesAWS VPC5/28.0, .1, .2, .3, lastAzure VNet5/29Similar to AWSGoogle Cloud4/29One fewer than AWSOracle Cloud3/30Most efficient For multi-cloud organizations, plan address space with the AWS reservation count in mind even for non-AWS subnets — it gives you uniform sizing rules and makes peering planning simpler. See our article on multi-cloud VPC peering for the full org-level allocation chart. ## Key takeaways - AWS reserves **5 IPs per subnet**: `.0`, `.1`, `.2`, `.3`, and last. - The smallest subnet you can create is `/28`, giving 11 usable addresses. - Plan for ENI count, not instance count — Lambda, Fargate, and managed services consume ENIs from your subnets dynamically. - Use `/20` or `/22` for production workload tiers, `/24` for databases, `/28` for transit and gateway endpoints. - Secondary CIDRs (including CGNAT space) are the standard fix when a VPC runs low on addresses. If you want to model an AWS subnet design before applying it, our Cloud calculator handles the 5-IP reservation automatically and shows you what is actually usable. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Cloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min readCloud #### Azure VNet Subnet Sizing: GatewaySubnet, Bastion, Firewall Azure has reserved subnet names with specific size requirements (GatewaySubnet, AzureBastionSubnet, AzureFirewallSubnet) that trip up first-... 9 min readKubernetes #### EKS VPC CNI Prefix Delegation: 16x More Pods Per Node Without prefix delegation, an m5.large EKS node runs out at 29 pods. Turning on prefix delegation increases the limit to 110+ — by handing p... 10 min readKubernetes #### Sizing Kubernetes Pod and Service CIDRs Correctly You cannot resize the pod CIDR after a cluster is running. Here is the rule of thumb for sizing pod, service, and node CIDRs to handle produ... 10 min read ## Frequently asked questions ### Why does AWS reserve 5 IPs in every VPC subnet? AWS reserves the first 4 addresses of each subnet for: the network address, the VPC router, the Amazon-provided DNS resolver, and a future-use address. The last address is the broadcast address. The combined 5-IP reservation is fixed and applies to every subnet regardless of size, which is why small subnets feel especially constrained. ### How does the AWS reservation affect a /28 subnet? A /28 contains 16 IP addresses. After AWS reserves 5, only 11 are assignable to instances. This is the most common surprise for engineers new to AWS — they compute 2^4 - 2 = 14 expecting on-premises math, but the cloud reservation makes the actual count 11. ### What is the minimum subnet size in AWS? /28. AWS will not let you create a subnet smaller than /28 because the 5-IP reservation would leave too few usable addresses. /28 is the minimum for both IPv4 and most IPv6 deployments in AWS. ### Does the reservation apply to IPv6 subnets in AWS? AWS reserves a similar pattern of addresses in IPv6 subnets but the impact is negligible because IPv6 subnet sizes are astronomically larger. A /64 IPv6 subnet has 2^64 addresses; losing 5 of them is rounding error. --- # Azure VNet Subnet Sizing: GatewaySubnet, Bastion, Firewall 9 min read·Published May 26, 2026·By cidrcalculator.net team Azure VNets follow most of the same CIDR rules as AWS VPCs, but with one major twist: **some subnets have specific names that the platform recognizes and enforces sizes for**. Pick the wrong name or size and the deployment fails — sometimes silently, sometimes with a clear error. This article covers Azure's reserved subnet names, the correct size for each, the 5 reserved IPs per subnet, and how to lay out a production-grade VNet that supports VPN, Bastion, and Azure Firewall together. ## Azure reserves 5 IPs per subnet Like AWS, Azure reserves five addresses in every subnet: AddressPurpose.0Network address.1Default gateway.2 / .3Azure DNS mappinglastBroadcast address So a `/29` (8 total addresses) gives you 3 usable, and a `/24` gives 251 usable. Same arithmetic as AWS, different reserved purposes for two of the addresses. ## Minimum subnet: /29 Unlike AWS (minimum /28), Azure allows subnets as small as **/29**. The portal will reject anything smaller. Practical minimum for production workloads is /27 or /26 — the /29 leaves only 3 usable addresses, which is too tight for almost anything except a single management appliance. ## The named subnets that have size requirements Subnet name (exact)Minimum sizeRecommendedPurposeGatewaySubnet/29/27VPN/ExpressRoute gatewayAzureBastionSubnet/26/26Azure Bastion serviceAzureFirewallSubnet/26/26Azure FirewallAzureFirewallManagementSubnet/26/26Azure Firewall management traffic (basic SKU)RouteServerSubnet/27/27Azure Route Server The name match is *exact and case-sensitive*. `GatewaySubnet` is correct; `Gateway-Subnet` or `gatewaysubnet` is not — Azure will refuse to use it for the platform service. ### GatewaySubnet Used by the VPN gateway and ExpressRoute gateway. Microsoft documentation says minimum /29, but recommends /27 because it allows easier upgrades to higher-throughput gateway SKUs that need more addresses. There is no traffic in this subnet from your VMs — the gateway uses these addresses for its own ENIs and tunneling endpoints. ### AzureBastionSubnet Used by Azure Bastion (the managed jump host service). Must be /26 or larger. Cannot have an NSG attached in the basic SKU. Cannot be used for anything except Azure Bastion. ### AzureFirewallSubnet Used by Azure Firewall. Must be /26 or larger. Cannot be associated with an NSG (the firewall itself handles all traffic policy). For Premium SKU with TLS inspection, /25 or /24 may be needed depending on scale. ### AzureFirewallManagementSubnet Required only for the Basic SKU of Azure Firewall. Holds the firewall's management traffic separately. Also /26 minimum. ## Standard production VNet layout A typical hub-and-spoke layout in Azure, with all the named services: ``` 10.0.0.0/16 Hub VNet (65,531 usable) +-- GatewaySubnet 10.0.0.0/27 (27 usable) +-- AzureBastionSubnet 10.0.0.32/26 (59 usable) +-- AzureFirewallSubnet 10.0.0.96/26 (59 usable) +-- RouteServerSubnet 10.0.0.160/27 (27 usable) +-- shared-services 10.0.1.0/24 (251 usable) +-- (10.0.2.0 - 10.0.255.255 reserved) 10.1.0.0/16 Spoke VNet 1 (workloads) +-- web-tier 10.1.0.0/20 (4,091 usable) +-- app-tier 10.1.16.0/20 (4,091 usable) +-- db-tier 10.1.32.0/24 (251 usable) +-- (10.1.33.0 onward reserved) ``` VNet peering connects spokes to the hub. The hub provides shared services (firewall, VPN, DNS). Spokes do not peer with each other directly — traffic flows through the hub's firewall. ## VNet peering and address overlap Like AWS VPC peering, Azure VNet peering rejects overlapping address spaces. Plan CIDRs across all VNets the way you would across AWS VPCs — see our multi-cloud CIDR planning article. Azure does allow some overlap if you do not need direct routing (e.g., if both VNets only reach an external service via the hub firewall), but the platform still warns you and the configuration is fragile. ## Subnet expansion is supported Unlike AWS (where subnet CIDRs are immutable after creation), **Azure lets you expand a subnet's address range** as long as the new range is still inside the VNet's address space and does not overlap other subnets. Shrinking is not supported. This means you can start with a /27 and grow to a /24 later without recreating resources. Helpful for unpredictable workloads, though designing the right size up front is still better practice. ## Common Azure subnet mistakes - **Misspelling reserved names.**`Gatewaysubnet`, `azureBastionSubnet`, `AzureFirewall-Subnet` — all rejected. Use exact casing. - **Trying to attach NSGs to AzureBastionSubnet/AzureFirewallSubnet.** Not allowed. The services manage their own traffic policy. - **Sizing GatewaySubnet at /29.** Technically allowed, but you cannot upgrade to high-performance gateway SKUs. Always start at /27. - **Forgetting Azure reserves 5 IPs.** Same trap as AWS. A /29 has 8 total but only 3 usable. - **Not planning for managed service ENIs.** Azure SQL, App Service, AKS pods, and Container Instances all consume ENIs from your subnets. Plan capacity accordingly. ## AKS pod CIDR sizing AKS supports two networking modes: - **Kubenet**: pods use an overlay range (default 10.244.0.0/16). Node count limited to 400. - **Azure CNI**: each pod gets a real VNet IP. Node count up to 5,000 but every pod consumes a VNet IP. Azure CNI gives better performance and integration but burns VNet space. Plan the same way as EKS — see our Kubernetes CIDR sizing article for the full pattern. Azure CNI with dynamic IP allocation (Overlay mode, preview/GA in many regions) gives you EKS-prefix-delegation-style efficiency. ## Terraform pattern for Azure ``` resource "azurerm_virtual_network" "hub" { name = "hub-vnet" address_space = ["10.0.0.0/16"] location = "eastus" resource_group_name = azurerm_resource_group.main.name } resource "azurerm_subnet" "gateway" { name = "GatewaySubnet" resource_group_name = azurerm_resource_group.main.name virtual_network_name = azurerm_virtual_network.hub.name address_prefixes = ["10.0.0.0/27"] } resource "azurerm_subnet" "bastion" { name = "AzureBastionSubnet" resource_group_name = azurerm_resource_group.main.name virtual_network_name = azurerm_virtual_network.hub.name address_prefixes = ["10.0.0.32/26"] } ``` Our IaC Export tool generates this for Azure including the firewall, route server, and spoke peering setup. ## Key takeaways - Azure VNets reserve **5 IPs per subnet** (same count as AWS, different purposes). - Minimum subnet is **/29**. Practical minimum for workloads is /27. - Reserved subnet names are **case-sensitive**: `GatewaySubnet`, `AzureBastionSubnet`, `AzureFirewallSubnet`, `AzureFirewallManagementSubnet`, `RouteServerSubnet`. - Recommended size for GatewaySubnet is /27 (not the /29 minimum) to support gateway SKU upgrades. - Unlike AWS, Azure subnets **can be expanded** after creation. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Cloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readCloud #### GCP VPC Subnet Sizing and Expansion Guide GCP VPCs differ from AWS and Azure: subnets are regional (not zonal), expansion is supported without downtime, and only 4 IPs are reserved p... 8 min readCloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min readDevOps #### Generating Terraform from a Subnet Design Going from a whiteboard subnet plan to production Terraform code without copy-paste errors. Patterns for modular VPC design, AWS provider be... 10 min read --- # GCP VPC Subnet Sizing and Expansion Guide 8 min read·Published May 26, 2026·By cidrcalculator.net team Google Cloud's VPC implementation is the most flexible of the major clouds: **subnets are regional** (one subnet spans all zones in a region), **only 4 IPs are reserved per subnet** instead of AWS's 5, and **subnet expansion is supported online** without recreating resources. These design choices come from Google's experience running global infrastructure, and they meaningfully simplify multi-zone architectures. This article covers how GCP VPC sizing differs from AWS and Azure, the standard production patterns, and the gotchas to watch for. ## The big architectural difference: regional subnets In AWS, each subnet is bound to a single AZ. A three-AZ deployment needs three subnets per tier. In GCP, **one subnet covers all zones in a region**. A three-zone deployment uses one subnet — the platform handles per-zone IP assignment. This simplifies VPC layouts dramatically. A typical GCP production VPC with three tiers: ``` my-vpc (custom mode) +-- web-tier-us-central1 10.10.0.0/20 (4,092 usable) +-- app-tier-us-central1 10.10.16.0/20 (4,092 usable) +-- db-tier-us-central1 10.10.32.0/24 (252 usable) +-- web-tier-europe-west1 10.20.0.0/20 (different region) +-- app-tier-europe-west1 10.20.16.0/20 +-- db-tier-europe-west1 10.20.32.0/24 ``` Six subnets total, not 18 (three AZs × six tiers × two regions would be the AWS count). The simplification compounds as you add more regions and tiers. ## Only 4 reserved IPs AddressPurpose.0Network address.1Default gatewaysecond-to-lastReserved by Google for future uselastBroadcast address One fewer reservation than AWS or Azure. A GCP /28 gives 12 usable addresses; a /24 gives 252. ## Minimum subnet: /29 GCP allows subnets as small as /29 (8 total, 4 usable). Practical minimum for any real workload is /28 or /27. ## Auto-mode vs custom-mode VPCs GCP supports two VPC types: ModeBehaviorRecommendationAuto-modeSubnets pre-created in every region, fixed CIDRs (10.128.0.0/9)Tutorials and demos onlyCustom-modeYou define every subnet manuallyAlways for production Auto-mode VPCs are convenient for getting started but use fixed CIDRs in `10.128.0.0/9`. If you have any on-premises networks or other clouds that might conflict, auto-mode creates instant overlap problems. Always use custom-mode for production. ## Subnet expansion (the killer feature) This is the operational advantage GCP has over AWS and Azure. **You can expand a subnet's CIDR online** without affecting running workloads. ``` # Before: 10.10.0.0/24 (running with 50 instances) gcloud compute networks subnets expand-ip-range my-subnet \ --region=us-central1 \ --prefix-length=22 # After: 10.10.0.0/22 (4x larger, no instance restarts needed) ``` The only constraint is that the new range must: - Contain the original range (you can grow, not move) - Not overlap any other subnet in the VPC - Not exceed /16 (subnet max) This makes "oh no we ran out of IPs" recoverable without re-IPing or maintenance windows. Compare to AWS where the only fix is adding a secondary VPC CIDR or re-IPing workloads. ## Secondary IP ranges Each GCP subnet can have multiple secondary IP ranges that are used by specific services. The most important use case is **GKE** (Google Kubernetes Engine) clusters, which use secondary ranges for: - **Pod IP range** — typically /16 or /17, providing addresses for every pod - **Service IP range** — typically /20, virtual addresses for Services Example: a primary subnet of `10.10.0.0/22` for nodes, with secondary `10.40.0.0/14` for pods and `10.50.0.0/20` for services. The pod range can be much larger than the node range without consuming VM-routable space. ## Shared VPC (the GCP-specific pattern) GCP has a powerful concept called **Shared VPC**: one host project owns the VPC, multiple service projects deploy resources into it. This is the GCP equivalent of AWS VPC peering or Transit Gateway, but tighter — service project resources see the shared VPC as if it were their own. For multi-team organizations, the pattern is: - Create one host project with all VPCs and subnets - Network team manages CIDR allocation and routing - Each application team gets a service project with permission to deploy into specific subnets - No peering, no Transit Gateway — just access controls This is meaningfully simpler than the AWS hub-and-spoke pattern using Transit Gateway. ## Global routing as default GCP VPCs have **global routing by default**: a VM in `us-central1` can reach a VM in `europe-west1` using the same VPC's subnets without any peering setup. This is in stark contrast to AWS, where VPCs are regional and cross-region traffic requires peering or Transit Gateway. The downside: cross-region traffic crosses Google's backbone but is still subject to network egress charges. Design with regional separation in mind for cost optimization. ## Standard production layout ``` prod-vpc (custom-mode, global) +-- web-us-central1 10.10.0.0/20 (4,092 usable) +-- app-us-central1 10.10.16.0/20 (4,092 usable) +-- db-us-central1 10.10.32.0/24 (252 usable) +-- gke-nodes-us-cent1 10.10.36.0/22 (1,020 usable) | +-- (secondary) pods 10.40.0.0/14 (262,140) | +-- (secondary) services 10.50.0.0/20 (4,092) +-- web-europe-west1 10.20.0.0/20 +-- app-europe-west1 10.20.16.0/20 +-- db-europe-west1 10.20.32.0/24 ``` Compare to the AWS equivalent — same workload would require ~24 subnets across two regions. GCP's regional subnet model reduces VPC complexity by ~3x. ## Terraform pattern ``` resource "google_compute_network" "prod" { name = "prod-vpc" auto_create_subnetworks = false # always custom mode routing_mode = "GLOBAL" } resource "google_compute_subnetwork" "gke_nodes" { name = "gke-nodes-us-central1" region = "us-central1" network = google_compute_network.prod.id ip_cidr_range = "10.10.36.0/22" secondary_ip_range { range_name = "pods" ip_cidr_range = "10.40.0.0/14" } secondary_ip_range { range_name = "services" ip_cidr_range = "10.50.0.0/20" } } ``` Our IaC Export generates this for GCP with the standard tiered subnet layout and GKE secondary ranges. ## Common GCP subnet mistakes - **Using auto-mode in production.** CIDR conflicts with on-prem are almost guaranteed eventually. Always start custom-mode. - **Sizing GKE secondary ranges too small.** Like all Kubernetes, pod CIDR is fixed at cluster creation. See our Kubernetes CIDR sizing article. - **Not using subnet expansion.** Many engineers default to AWS-style "recreate the subnet" thinking. GCP supports online expansion — use it. - **Forgetting global routing.** A VM in another region can reach your DB by default. Lock this down with firewall rules if you want regional isolation. ## Key takeaways - GCP subnets are **regional**, not zonal — one subnet per region per tier, not per AZ. - Only **4 IPs reserved** per subnet (vs 5 for AWS/Azure). - **Online subnet expansion** is supported and is the killer feature for capacity planning. - Always use **custom-mode VPCs** in production; auto-mode is for tutorials only. - GKE uses **secondary IP ranges** for pods and services within a subnet — size these carefully because they cannot be resized after cluster creation. - **Shared VPC** is the GCP-specific pattern for multi-team architectures — simpler than AWS hub-and-spoke. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Cloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readCloud #### Azure VNet Subnet Sizing: GatewaySubnet, Bastion, Firewall Azure has reserved subnet names with specific size requirements (GatewaySubnet, AzureBastionSubnet, AzureFirewallSubnet) that trip up first-... 9 min readCloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min readDevOps #### Generating Terraform from a Subnet Design Going from a whiteboard subnet plan to production Terraform code without copy-paste errors. Patterns for modular VPC design, AWS provider be... 10 min read --- # Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap 11 min read·Published May 26, 2026·By cidrcalculator.net team The single most expensive networking mistake organizations make in the cloud is using overlapping CIDR blocks. Two VPCs that both default to `10.0.0.0/16` cannot peer with each other. When the business decides to connect those VPCs — because of an acquisition, a multi-region rollout, or just an unrelated team needing to talk to your service — you have a re-IPing project on your hands. That is typically multiple weeks of work and a maintenance window. This article walks through a tested CIDR planning pattern that prevents this problem from ever happening. It works for organizations going greenfield in the cloud and for ones that need to retrofit a coherent allocation onto an existing mess. ## Why CIDRs must not overlap when peering VPC peering, Transit Gateway, Virtual WAN, and every other cloud routing primitive uses the destination IP to decide where a packet goes. If two VPCs both contain `10.0.5.42`, the router cannot decide which one to send a packet to. The cloud platforms know this and refuse to allow the peering at all. The error message you get when you try is usually some variant of: ``` InvalidVpcPeeringConnectionId.NotFound: The VPC CIDR ranges overlap. ``` The fix at that point requires moving one VPC's workloads to a different CIDR, which means recreating subnets, ENIs, load balancers, and potentially every instance. It is the multi-day kind of fix. ## The org-wide allocation chart The right time to design CIDR allocation is **before the first VPC is created**. The wrong time is after you have 40 VPCs and someone needs them to talk to each other. A standard pattern for organizations using all three major clouds: ``` 10.0.0.0/8 Organization total (16,777,216 IPs) +-- 10.0.0.0/12 AWS (1,048,576 IPs) | +-- 10.0.0.0/16 aws-prod-us-east-1 | +-- 10.1.0.0/16 aws-prod-us-west-2 | +-- 10.2.0.0/16 aws-prod-eu-west-1 | +-- 10.3.0.0/16 aws-staging-us-east-1 | +-- 10.4.0.0/16 aws-staging-us-west-2 | +-- 10.5.0.0/16 aws-dev | +-- 10.6.0.0/16 aws-sandbox | +-- (10.7-10.15) reserved for future AWS VPCs +-- 10.16.0.0/12 Azure (1,048,576 IPs) | +-- 10.16.0.0/16 azure-prod-eastus | +-- 10.17.0.0/16 azure-prod-westus2 | +-- (10.18-10.31) reserved +-- 10.32.0.0/12 GCP (1,048,576 IPs) | +-- 10.32.0.0/16 gcp-prod-us-central1 | +-- (10.33-10.47) reserved +-- 10.48.0.0/12 On-premises (1,048,576 IPs) | +-- 10.48.0.0/16 datacenter-primary | +-- 10.49.0.0/16 datacenter-secondary | +-- (10.50-10.63) reserved for branches +-- 10.64.0.0/12 Acquisitions (1,048,576 IPs) | +-- reserved for newly-acquired company networks +-- 10.128.0.0/9 Future / DR (8,388,608 IPs) ``` Each cloud provider gets a `/12` (1M addresses, 16 `/16` VPCs). On-premises gets its own /12. Acquisitions get a separate block so you can integrate company networks without rushing a re-IP. The top half of `10/8` is reserved for the future — for new clouds, new regions, or anything else. ## Within a VPC: per-region patterns Inside each VPC, allocate subnets predictably so that subnets in different VPCs can be identified by their address. A standard three-tier, three-AZ pattern at `/16` uses `/20` subnets: ``` aws-prod-us-east-1 (10.0.0.0/16) +-- web-az-a (10.0.0.0/20) +-- web-az-b (10.0.16.0/20) +-- web-az-c (10.0.32.0/20) +-- app-az-a (10.0.48.0/20) +-- app-az-b (10.0.64.0/20) +-- app-az-c (10.0.80.0/20) +-- db-az-a (10.0.96.0/24) +-- db-az-b (10.0.97.0/24) +-- db-az-c (10.0.98.0/24) +-- tgw-attach (10.0.99.0/28 - 10.0.99.48/28) +-- (10.0.100.0/22 onward reserved for growth) ``` This carves the VPC into 16 `/20` subnets max. Three tiers times three AZs is 9 subnets used, leaving 7 reserved for growth. Database subnets are smaller (/24) because RDS uses far fewer IPs than EKS or EC2 fleets. You can design this layout interactively with our VLSM Designer in cloud mode, which applies AWS's 5-IP reservation rules automatically. ## The CGNAT escape valve For organizations that are running out of RFC 1918 space, or that need to integrate with networks that already use `10.0.0.0/8` heavily, **RFC 6598 CGNAT space (`100.64.0.0/10`)** is a 4-million-address third option. Cloud providers support it as a secondary CIDR. AWS in particular benefits because Kubernetes (EKS) pods can consume thousands of VPC addresses per cluster. Putting pod IPs in CGNAT keeps your RFC 1918 space free for VMs, RDS, ELBs, and the things you actually peer with. See our article on Kubernetes pod CIDR sizing for the full pattern. ## What to do when overlap is already present If you are looking at this article because two VPCs you need to peer are already overlapping, the options are: ### Option A: Re-IP one VPC The painful but clean option. Pick the less-critical VPC and move its workloads to a non-overlapping CIDR. For AWS, this typically means: - Add a new VPC with the correct CIDR. - Recreate subnets, security groups, and route tables. - Migrate workloads (instance by instance, using AMI snapshots). - Update DNS, ELBs, and external service registrations. - Decommission the old VPC. Plan for 2-6 weeks depending on workload count and complexity. ### Option B: Use private NAT If re-IPing is genuinely impossible (regulated workload, frozen infrastructure), you can use private NAT to translate addresses at the peering boundary. AWS has a "private NAT gateway" feature for this. Azure supports it via private endpoints in some configurations. Operational complexity is high — you lose end-to-end address visibility, and troubleshooting becomes harder. ### Option C: Transit Gateway with route segmentation If only some subnets need to communicate, you can sometimes avoid the conflict by routing only the non-overlapping subnets through Transit Gateway. This works if your overlap is in a portion of the VPC that does not need cross-VPC connectivity. See our article on Transit Gateway vs VPC peering for the details. ## Tooling to enforce the chart Once you have a CIDR allocation chart, the chart itself becomes a critical document. Common practice: - Store the chart in a shared location (Confluence, Notion, a Git repo). - Require chart updates as part of the VPC provisioning workflow — no VPC gets created without an allocated CIDR from the chart. - Use Terraform or similar to enforce this in code. Our IaC Export tool generates ready-to-use Terraform VPC modules from a designed allocation. - Track active allocations in an IPAM tool. Our IPAM-Lite tracker uses your browser's localStorage; for team use you might want a server-backed tool. ## Key takeaways - Design CIDR allocation **before the first VPC is created**. Retrofitting is expensive. - Use a **top-down /12 per cloud** pattern with room for future regions and acquisitions. - Within a VPC, use **/20 subnets for application tiers, /24 for databases, /28 for transit endpoints**. - Use **CGNAT (100.64.0.0/10)** as a secondary CIDR when RFC 1918 space is constrained — especially for EKS pod CIDRs. - When CIDRs do overlap, re-IPing is usually the right fix. Private NAT is an emergency-only workaround. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Cloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readCloud #### AWS Transit Gateway vs VPC Peering: Cost, Complexity, Scale VPC peering is point-to-point and free. Transit Gateway is hub-and-spoke and costs $36+/month. Here is when each is the right choice and the... 9 min readCloud #### Azure VNet Subnet Sizing: GatewaySubnet, Bastion, Firewall Azure has reserved subnet names with specific size requirements (GatewaySubnet, AzureBastionSubnet, AzureFirewallSubnet) that trip up first-... 9 min readCloud #### GCP VPC Subnet Sizing and Expansion Guide GCP VPCs differ from AWS and Azure: subnets are regional (not zonal), expansion is supported without downtime, and only 4 IPs are reserved p... 8 min read ## Frequently asked questions ### How do I plan CIDRs across multiple clouds without overlap? Allocate a distinct, non-overlapping super-block per cloud and per environment from the start. For example: AWS production gets 10.0.0.0/12, AWS staging gets 10.16.0.0/12, Azure production gets 10.32.0.0/12, GCP production gets 10.64.0.0/12. Even if you have no cross-cloud connectivity today, you preserve the option for tomorrow. ### What CIDR size should I use for each cloud VPC? /16 (65,536 IPs) is a common starting point for a production VPC across two or three availability zones. /20 (4,096 IPs) is reasonable for staging or smaller environments. /22 (1,024 IPs) is the minimum for most production designs once you account for VPC subnet reservations and growth headroom. ### Can I peer VPCs that have overlapping CIDRs? No. AWS VPC peering, Transit Gateway, Azure VNet peering, and GCP VPC peering all require non-overlapping CIDRs. If you discover overlap after the fact, the only fix is to renumber one side of the peering — which is painful and typically requires a maintenance window. --- # IPv6 for IPv4 Engineers: The Only Guide You Need 14 min read·Published May 26, 2026·By cidrcalculator.net team IPv6 has been "coming next year" since about 1998. By now, it is genuinely deployed: mobile networks run IPv6-only with NAT64 for legacy IPv4 services, every major cloud provider supports dual-stack VPCs, and Apple's App Store has required IPv6 compatibility since 2016. If your career as a network engineer is going to outlast IPv4 (it probably is), you need to understand IPv6. The good news: **IPv6 is conceptually simpler than IPv4 once you adopt it**. No NAT, no broadcasts, no address scarcity, no classful baggage. The bad news: 30 years of accumulated IPv4 muscle memory has to be unlearned for some parts. This guide walks through the differences that matter for daily network engineering work. ## Address format and notation An IPv6 address is 128 bits — four times the size of IPv4. Written as eight groups of four hex digits separated by colons: `2001:0db8:0000:0000:0000:0000:0000:0001`. That is too much to type, so IPv6 has two compression rules: - **Drop leading zeros** in each group: `2001:0db8:0000:0000:0000:0000:0000:0001` becomes `2001:db8:0:0:0:0:0:1`. - **Compress one run of all-zero groups** to `::`: `2001:db8:0:0:0:0:0:1` becomes `2001:db8::1`. You can only use `::` once per address, otherwise the count of zero groups is ambiguous. So `2001::1::5` is invalid. For practice and documentation, always use the **RFC 3849 documentation prefix**`2001:db8::/32`. It is the IPv6 equivalent of the TEST-NETs in IPv4 — blackhole-routed, safe to use in examples, and will never be assigned to a real network. ## The /64 rule: every LAN is exactly a /64 This is the single most important IPv6 concept to internalize. **Every IPv6 LAN segment is exactly a /64**. Not /63, not /65, not /48 — exactly /64. This is structural, not a recommendation. SLAAC (stateless address autoconfiguration), privacy extensions, and EUI-64 all require exactly 64 bits for the interface ID. If your LAN is a /65, SLAAC breaks. If it is a /48, SLAAC works but you have wasted a 16-bit chunk of address space that could have been used for additional subnets. Engineers coming from IPv4 panic at the apparent waste. A /64 contains 2^64 = 18 quintillion addresses for one LAN of a few hundred hosts. But IPv6 addresses are practically infinite — there are **3.4 × 10^38 total IPv6 addresses**. Even with /64 per LAN, you cannot run out at any imaginable scale. ### The IPv6 allocation hierarchy ``` /48 one site (your organization's allocation) /56 one branch office or sub-site (256 LANs) /64 one LAN segment (a VLAN, a broadcast domain) ``` If your ISP only gives you a /64 for a business connection, push back. The standard expectation is a **/48 for businesses and /56 or /60 for residential** connections. A /64 allocation means you cannot subnet internally — every device shares one LAN, which is operationally constraining. ## Address types you need to know RangeNameEquivalent in IPv42000::/3Global Unicast (GUA)Public addressesfc00::/7Unique Local (ULA)RFC 1918 (10/8, 172.16/12, 192.168/16)fe80::/10Link-local169.254.0.0/16 (APIPA)::1/128Loopback127.0.0.1::/0Default route0.0.0.0/0ff00::/8Multicast224.0.0.0/42001:db8::/32Documentation192.0.2.0/24 (RFC 5737) ### ULA: the IPv6 RFC 1918 For private networks (the IPv6 equivalent of your `10.0.0.0/8` internal range), use **ULA** from the `fd00::/8` half of the `fc00::/7` block. Critically, ULA addresses are structured as `fd` + 40-bit random Global ID + 16-bit subnet + 64-bit interface ID. The Global ID **must be random**. RFC 4193 explicitly forbids memorable values like `fd00:1::`, because randomness prevents collisions when companies later interconnect. If two organizations both use `fd00:1::/48` and merge, they have a re-IPing event on their hands — exactly the IPv4 RFC 1918 problem that prompted ULA to add randomness in the first place. Generate a ULA prefix with: `openssl rand -hex 5`. Use those 5 bytes (40 bits) as your Global ID. Result: something like `fd7a:c9b1:e3f2::/48` — your private allocation for the lifetime of the organization. ### Link-local: always present Every IPv6 interface automatically has a **link-local address** in `fe80::/10`. This exists before any DHCPv6 or SLAAC has happened, derived from the MAC address (EUI-64) or randomly assigned. Link-local is used by IPv6's neighbor discovery protocol (NDP, the ARP replacement), router advertisements, and IGP control planes (OSPFv3 peers over link-local). You cannot route link-local traffic. To ping a link-local address, you must specify the interface: `ping fe80::1%eth0`. ## SLAAC vs DHCPv6 In IPv4, you got an address from DHCP. In IPv6, hosts can self-configure two ways: - **SLAAC (Stateless Address Autoconfiguration)** — the router announces the /64 prefix in a Router Advertisement, and the host appends its own 64-bit interface ID (random or EUI-64). No central server needed. Works out of the box on any modern OS. - **DHCPv6** — works like IPv4 DHCP, with a server tracking leases. Required for fixed-address assignment and for getting DNS server info on platforms that do not support RDNSS (Router Advertisement DNS). Production networks often run both: SLAAC for the address itself (so hosts work even if DHCP is down) and DHCPv6-stateless for DNS server info. Note that Android historically did not support stateful DHCPv6 at all; this has only recently been changing. ## NDP replaces ARP IPv4's ARP is replaced by **NDP (Neighbor Discovery Protocol)**, which runs over ICMPv6. Five NDP message types: - **Router Solicitation (RS)** — host asks "are there any routers?" - **Router Advertisement (RA)** — router announces itself and the /64 prefix - **Neighbor Solicitation (NS)** — "who has this IP?" (like ARP request) - **Neighbor Advertisement (NA)** — "I do" (like ARP reply) - **Redirect** — "use a better gateway" NS and NA use solicited-node multicast (`ff02::1:ff00:0/104`) instead of broadcast, which is more efficient than ARP at scale because only hosts with matching solicited-node addresses process the packet. ## Privacy extensions: rotating temporary addresses The original SLAAC algorithm derived the 64-bit interface ID from the MAC address (EUI-64). This is bad for privacy — every site you visit can correlate you across networks because your interface ID never changes. RFC 4941 (privacy extensions) fixes this by generating **random interface IDs that rotate** on a schedule (typical default: 24 hours). Modern operating systems enable this by default. The side effect: a host has multiple IPv6 addresses simultaneously. A stable EUI-64 address for inbound services, plus one or more temporary addresses used for outbound traffic. `ip -6 addr show` on Linux reveals both. This is normal and expected. ## NAT64: connecting IPv6 hosts to IPv4 services Mobile carriers (T-Mobile US, Reliance Jio) have deployed IPv6-only networks since the mid-2010s. To let those devices reach legacy IPv4 services, they use **NAT64** with the well-known prefix `64:ff9b::/96` (RFC 6052). An IPv6 client looks up `example.com` via DNS64, receives a synthesized AAAA record like `64:ff9b::93.184.216.34` (the IPv4 address embedded in the last 32 bits of the IPv6 address), and connects. The NAT64 gateway intercepts that traffic, extracts the IPv4 destination, and forwards the connection over IPv4 to the real server. This is how IPv6-only deployment works at scale today. The transition to fully IPv6-only is a generational change, but the mechanisms are in place. ## Operational differences from IPv4 ### No broadcast IPv6 eliminated broadcast entirely. The equivalent operations use multicast in `ff00::/8`. `ff02::1` sends to all nodes on the link. `ff02::2` sends to all routers. This is more efficient because only hosts subscribed to a group process the multicast — no broadcast storms. ### No NAT Every host gets a real, globally unique address. NAT exists in IPv6 (NAT66, NPTv6) but is generally discouraged. The combination of ULA for private networks and GUA for public addressing makes NAT unnecessary in most cases. ### Larger MTU minimum IPv4 must support a minimum MTU of 68 bytes. IPv6 mandates a minimum of **1280 bytes**. This simplifies fragmentation: routers no longer fragment packets in transit; only endpoints fragment. If a router gets a packet too large for the next-hop MTU, it sends ICMPv6 "Packet Too Big" and drops it. The sender shrinks future packets accordingly. ### Stateful routing protocols changed Most IPv4 routing protocols have IPv6 versions: OSPFv2 → OSPFv3, EIGRPv4 → EIGRPv6, RIPv2 → RIPng. Modern designs lean toward IS-IS (always multi-protocol) and BGP (which carries IPv6 prefixes in the multiprotocol extension). ## Common IPv6 mistakes - **Treating /64 as wasteful.** It is mandatory. Always /64 per LAN. - **Using memorable ULA prefixes.** Defeats the purpose. Use `openssl rand`. - **Filtering all ICMPv6 at the firewall.** NDP and Path MTU Discovery depend on ICMPv6. You must allow neighbor discovery messages and "Packet Too Big" (type 2). RFC 4890 documents what to allow. - **Hardcoding IPv4 assumptions in scripts.** Regex for "an IP address" usually matches `123.45.67.89` but not `2001:db8::1`. Audit your tooling. - **Not testing dual-stack.** A host can have working IPv4 and broken IPv6 (or vice versa). Test both, because clients with broken IPv6 fall back slowly and your service appears slow. ## Calculator support Our CIDR calculator supports IPv6 alongside IPv4. Enter any IPv6 CIDR like `2001:db8::/48` and you get the prefix length, total addresses, and subnet breakdown. The VLSM Designer supports IPv6 prefix planning if you need to allocate multiple /64s from a /48 site allocation. ## Key takeaways - Every IPv6 LAN is exactly a **/64**. Not an option. - Hierarchy: **/48 site → /56 site or /60 residential → /64 LAN**. - Use **ULA from fd00::/8 with a random Global ID** for private networks. Never invent memorable prefixes. - **Link-local addresses (fe80::/10)** are always present; you can ping them but must specify the interface. - **SLAAC** autoconfigures addresses without a server. **DHCPv6** exists for stateful assignment and DNS info. - **NDP** replaces ARP. **NAT64** bridges IPv6-only clients to IPv4 servers. - Allow ICMPv6 in firewalls (selectively — see RFC 4890). It is not the same as IPv4 ICMP. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles IPv6 #### IPv6 Prefix Delegation: /48, /56, /60, /64 Explained IPv6 prefix delegation lets ISPs hand subnets to customers automatically. Here is what /48 vs /56 vs /60 vs /64 mean for your business or ho... 9 min readFundamentals #### RFC 1918 vs RFC 6598: When to Use 100.64.0.0/10 CGNAT (100.64.0.0/10) is a 4-million-address range that is not classed as RFC 1918 private, but is filtered at internet edges. Here is when ... 7 min readFundamentals #### The Complete Subnet Mask Cheat Sheet (/0 to /32 with examples) Full reference table of IPv4 subnet masks from /0 to /32: prefix, dotted decimal, hex, host count, AWS usable, and common use cases. Printab... 7 min readSecurity #### Bogons, CGNAT, and Other IP Ranges That Will Ruin Your Day Some IP ranges should never appear on the internet. Bogons, CGNAT, link-local, multicast, TEST-NET — these are the non-obvious blocks that n... 9 min read --- # Sizing Kubernetes Pod and Service CIDRs Correctly 10 min read·Published May 26, 2026·By cidrcalculator.net team The number one operational mistake in production Kubernetes is undersizing the pod CIDR. Unlike VPC sizes (which most clouds let you expand), the **pod CIDR is fixed at cluster creation and cannot be changed**. Get it wrong, and the only fix is to build a new cluster and migrate workloads — typically a multi-week project. This article walks through the three CIDRs every Kubernetes cluster needs, how to size each one, and the cloud-specific patterns that prevent VPC address exhaustion under load. ## The three CIDRs every cluster needs A Kubernetes cluster requires three independent IP address ranges: CIDRWhat it coversResizable later?**Node CIDR**IPs for the underlying VMs (EC2 instances, etc.)Yes, via VPC expansion**Pod CIDR**IPs for every pod in the cluster**NO — fixed at creation****Service CIDR**Virtual IPs for Services (ClusterIP)**NO — fixed at creation** The node CIDR is just your VPC subnet space, which you can extend by adding more subnets or growing the VPC. The pod and service CIDRs, however, are baked into the cluster's API server and kubelet config — changing them requires building a new cluster. ## Sizing the pod CIDR (the hard one) The pod CIDR is the largest of the three because every pod gets at least one IP. The rule of thumb: Pod CIDR ≥ 4× expected peak pod count. The 4× multiplier accounts for in-flight pod restarts, IPAM padding (most CNIs hold spare IPs per node), DaemonSets, and growth headroom. A cluster that runs 5,000 pods at peak needs roughly 20,000 pod IPs — at minimum a `/17`, more comfortably a `/16`. Target peak podsMin pod CIDRRecommendedRecommended addresses500/22 (1,024)/20 (4,096)4,0962,000/20 (4,096)/19 (8,192)8,1925,000/18 (16,384)/16 (65,536)65,53620,000/16 (65,536)/15 (131,072)131,07250,000/15 (131,072)/14 (262,144)262,144 Always round up to the next power of 2. The cost of over-provisioning is zero in terms of money — you are not paying per pod IP. The cost of under-provisioning is a cluster rebuild. ## Sizing the service CIDR The service CIDR is much smaller because services are sparse compared to pods. Each Service gets one ClusterIP — a virtual address that kube-proxy or eBPF translates to actual pod IPs. A `/16` service CIDR (65,536 IPs) is plenty for almost any cluster. Even a 100,000-pod cluster rarely has more than a few thousand Services. The kubeadm default of `10.96.0.0/12` (1M addresses) is wildly overprovisioned; that is fine because the service CIDR is virtual and does not consume any real network space. **Critical constraint:** the service CIDR *must not overlap* with the pod CIDR or the node CIDR. If they overlap, traffic to a service can be misrouted to a pod or a node and silently fail. ## Sizing the node CIDR Node CIDR sizing depends on: - Maximum simultaneous nodes you expect (be generous — autoscaling spikes can double node count for hours). - Whether you use VPC-native CNI (AWS VPC CNI, Azure CNI) — if so, the node CIDR also has to hold pod IPs in some configurations. - Cloud reserved IPs per subnet (5 for AWS, 5 for Azure, 4 for GCP). A standard production EKS cluster with VPC CNI prefix delegation, expecting 50-200 nodes, fits in a single `/22` subnet (1,024 IPs) per AZ comfortably. Without prefix delegation, you need to oversize substantially. ## The VPC CNI vs overlay decision Two fundamentally different approaches to pod networking: ModelExamplesPod IPs come fromAddress efficiencyVPC-nativeAWS VPC CNI, Azure CNIYour VPC subnets directlyLow (each pod = 1 VPC IP)OverlayCalico, Flannel, CiliumSeparate virtual rangeHigh (overlay independent of VPC) **VPC-native** gives pods real, routable cloud IPs. Direct connectivity to other VPC resources, no overlay overhead. The downside is that pods burn VPC space fast — a 5,000-pod cluster consumes 5,000+ VPC addresses. **Overlay** pods live in a virtual range (often a /16 like `172.20.0.0/16` or `192.168.0.0/16`). Encapsulated traffic (VXLAN, IP-in-IP) between nodes. Pods are invisible outside the cluster. Address-efficient but adds packet overhead. For production EKS, the dominant pattern is **VPC CNI with prefix delegation** (16x density improvement) and a **secondary VPC CIDR in CGNAT space** for pod IPs. This combines the connectivity of VPC-native with the address efficiency of overlay. See our deep dive on EKS VPC CNI prefix delegation. ## Multi-cluster networking If you run multiple clusters that need to communicate (active-active, multi-region, edge sites), the pod CIDRs **must not overlap across clusters**. This is true for: - **Cilium ClusterMesh** — direct pod-to-pod via WireGuard or VXLAN - **Istio multi-primary** — service mesh handles cross-cluster routing - **Submariner** — IPsec tunnels across clusters - **Any VPC-peering-based connectivity** — VPC peering rejects overlapping CIDRs as discussed in our multi-cloud CIDR planning article Plan your cluster allocation chart upfront. A reasonable pattern: each cluster gets a unique /16 from a coordinated /12 pool. `100.64.0.0/16` for cluster A, `100.65.0.0/16` for cluster B, and so on. CGNAT space gives you 64 such /16 cluster allocations. ## Pod-per-node density limits Maximum pods per node depends on: - **Kubernetes default kubelet limit:** 110 pods/node. Raising this requires kubelet config changes and cluster-CIDR sizing. - **AWS VPC CNI**: limited by ENI capacity per instance type (e.g., m5.large = ~29 pods without prefix delegation, ~110 with). - **GKE**: 110 by default, configurable up to 256. - **AKS**: 110 with kubenet, 30 with Azure CNI (no prefix delegation). Calculating total cluster capacity: `pods_per_node × nodes = total_pods`. For a 5,000-pod cluster at 110 pods per node, you need at least 46 nodes — but practically you want headroom for scheduling, so size for 60+ nodes. ## Common sizing mistakes - **Sizing for today's pods, not 3 years out.** Multiply your current peak pod count by 4-10x for the pod CIDR. - **Putting pod CIDR in your primary VPC range.** Forces pods to share address space with VMs and managed services. Use a secondary CIDR (CGNAT) for pods on AWS. - **Service CIDR overlapping VPC ranges.** Silent breakage. Use something distinct like `172.20.0.0/16` (the EKS default). - **Forgetting Lambda and managed services.** A subnet's IPs are not just for pods — Lambda, RDS, ELBs all use the same pool. ## Tools for planning Our CIDR calculator validates pod, service, and node CIDR ranges. The AI assistant has dedicated Kubernetes intent handlers — try "Plan Kubernetes for 5000 pods" for a complete CIDR breakdown. ## Key takeaways - Pod CIDR is **fixed at cluster creation**. Oversize by 4-10x your peak pod estimate. - Service CIDR can be small (`/16`); pod CIDR is usually `/16` to `/14` for production. - None of the three CIDRs may overlap each other or other VPCs you peer with. - For EKS, use **VPC CNI prefix delegation + CGNAT secondary CIDR** for the best of both worlds. - Plan multi-cluster pod CIDRs from a shared allocation chart so future ClusterMesh, Istio, or Submariner deployments do not require re-IPing. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Kubernetes #### EKS VPC CNI Prefix Delegation: 16x More Pods Per Node Without prefix delegation, an m5.large EKS node runs out at 29 pods. Turning on prefix delegation increases the limit to 110+ — by handing p... 10 min readCloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min readCloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readFundamentals #### RFC 1918 vs RFC 6598: When to Use 100.64.0.0/10 CGNAT (100.64.0.0/10) is a 4-million-address range that is not classed as RFC 1918 private, but is filtered at internet edges. Here is when ... 7 min read --- # Public vs Private Subnets: When to Use Each 8 min read·Published May 26, 2026·By cidrcalculator.net team The terms "public subnet" and "private subnet" are deeply misleading. Both kinds of AWS subnet are *technically* identical — same CIDR, same VPC, same reserved IPs, same maximum size. The only difference is in the **route table**: a public subnet has a route to the Internet Gateway; a private subnet does not. This article explains exactly what those two flavors are good for, the design patterns for combining them in production, and the common confusions that lead to security issues. ## What makes a subnet "public" A public subnet has these characteristics: - Its route table contains a route for `0.0.0.0/0` pointing to an Internet Gateway. - Instances in it can have public IP addresses or Elastic IPs assigned to their ENIs. - Inbound traffic from the internet can reach instances if security groups and NACLs allow it. That is the entire definition. There is no "public subnet" flag in the AWS API — it is just a subnet whose route table happens to have an Internet Gateway route. ## What makes a subnet "private" A private subnet has these characteristics: - Its route table has **no direct route to the Internet Gateway**. - Outbound internet traffic goes through a NAT Gateway, NAT Instance, or VPC Endpoint (or not at all). - Inbound traffic from the internet cannot reach instances even if security groups allow it (there is no return path). Again, no "private subnet" flag — it's just the absence of an Internet Gateway route. ## The standard production layout The pattern that 95% of production AWS workloads use: ``` VPC: 10.0.0.0/16 +-- Public subnet az-a 10.0.0.0/24 | - ELB (ALB / NLB) | - NAT Gateway | - Bastion host (optional) +-- Public subnet az-b 10.0.1.0/24 | - (ELB targets here too) | - NAT Gateway +-- Public subnet az-c 10.0.2.0/24 | - NAT Gateway +-- Private subnet az-a 10.0.16.0/20 | - EC2 application instances | - EKS nodes +-- Private subnet az-b 10.0.32.0/20 +-- Private subnet az-c 10.0.48.0/20 +-- DB subnet az-a 10.0.64.0/24 | - RDS +-- DB subnet az-b 10.0.65.0/24 +-- DB subnet az-c 10.0.66.0/24 ``` The three layers: - **Public subnets**: hold load balancers and NAT Gateways. Small (/24 is plenty). - **Private subnets**: hold application workloads. Large (/20 typical for ENI-heavy workloads). - **DB subnets**: hold RDS, ElastiCache. Small (/24). Often a separate "tier" with stricter security groups. The ELB sits in public subnets and forwards traffic to targets in private subnets. The targets cannot accept direct internet connections, but the ELB can. This is the standard pattern. ## Why this layout works - **Security:** Application code in private subnets has no return path from the internet, so even if an instance is compromised, attackers cannot send back exfiltrated data over the same TCP connection (they would need to initiate an outbound connection through NAT). - **Operational simplicity:** Only the ELB needs to be hardened against direct internet attacks. Application instances rely on the ELB's WAF and rate limiting. - **NAT cost containment:** Application instances do not need static public IPs — they share the NAT Gateway's address pool. ## When to use a public subnet Only the following resources belong in public subnets: - Load balancers (ALB, NLB) - NAT Gateways - Bastion hosts (optional, increasingly replaced by SSM Session Manager) - VPN gateways / Site-to-Site VPN endpoints - Internet-facing reverse proxies (when ALB is not sufficient) If you find yourself putting application servers in a public subnet, stop. Even with strict security groups, the architecture creates risk surface. Move them behind a load balancer. ## When to use a private subnet Almost everything else: - Application EC2 instances - EKS nodes - RDS / ElastiCache (sometimes in a separate DB-only subnet for stricter isolation) - Lambda functions (when VPC-attached) - Fargate tasks - Internal services not reachable from outside the VPC ## Bastion hosts: increasingly optional Historically, the only way to SSH into a private-subnet instance was through a public-subnet bastion host. That pattern is still common but increasingly unnecessary. AWS Systems Manager Session Manager allows SSH-equivalent access to instances without any public-subnet hop. The instance just needs the SSM agent and an IAM role permitting SSM. No bastion, no public IPs, no inbound SSH rules. For production workloads in 2026, the recommended pattern is: - SSM Session Manager for ad-hoc instance access - AWS Client VPN or third-party VPN for engineer LAN access - No bastion hosts in public subnets ## "Egress-only" private subnets If you want even less network exposure, make the subnet "egress-only" by removing even the NAT route. Workloads in such a subnet can only reach: - Other resources in the same VPC - VPC endpoints (S3, DynamoDB, PrivateLink to other AWS services) - Peered VPCs (if peering is configured) This is useful for compliance-heavy workloads where outbound internet is forbidden. Combined with VPC endpoints for AWS services, applications can still function without any internet access at all. ## Common public/private subnet mistakes - **Putting application instances in public subnets "to make things simpler."** Almost never the right tradeoff. The architectural simplicity is not worth the security risk. - **Confusing "private" with "secure."** A private subnet without proper security groups is just as exploitable as a public one if an attacker gets in some other way (e.g., a compromised instance in the same VPC). Security groups still matter. - **Forgetting that NAT Gateways are in public subnets.** A common surprise: "Why is my NAT bill so high?" because the NAT Gateway sits in a public subnet and processes all outbound traffic. - **Cross-AZ NAT routing.** If your private subnet in AZ-A routes to a NAT Gateway in AZ-B, every byte crosses AZs. Always per-AZ NAT. ## The Azure and GCP equivalents Azure and GCP do not use the "public" / "private" terminology officially, but the same pattern applies: - **Azure**: a subnet becomes "public" by associating it with an Azure Public IP or NAT Gateway. Otherwise it's private. - **GCP**: VMs with public IPs are reachable from the internet; VMs without public IPs need Cloud NAT for outbound traffic. The same architectural patterns apply. ## Key takeaways - "Public" subnet = subnet with a default route to an Internet Gateway. "Private" subnet = no Internet Gateway route. - Standard production layout: **public for ELB + NAT, private for apps, separate DB tier**. - Use SSM Session Manager instead of bastion hosts. - Workloads with outbound internet needs use a NAT Gateway in their AZ. See our NAT options article for cost optimization. - "Egress-only" subnets with only VPC endpoints are the most restrictive pattern, used for compliance-heavy workloads. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Cloud #### NAT Gateway vs NAT Instance vs VPC Endpoints Three different ways to give private subnet workloads access to outside services in AWS. Cost, throughput, and operational tradeoffs explain... 9 min readCloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readCloud #### AWS Transit Gateway vs VPC Peering: Cost, Complexity, Scale VPC peering is point-to-point and free. Transit Gateway is hub-and-spoke and costs $36+/month. Here is when each is the right choice and the... 9 min readCloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min read --- # RFC 1918 vs RFC 6598: When to Use 100.64.0.0/10 7 min read·Published May 26, 2026·By cidrcalculator.net team For 25 years, "private IP" meant one of three RFC 1918 ranges: `10.0.0.0/8`, `172.16.0.0/12`, or `192.168.0.0/16`. In 2012, the IETF published **RFC 6598**, which reserved a fourth large block — `100.64.0.0/10` — specifically for ISP carrier-grade NAT. That range is neither public nor RFC 1918 private; it sits in a third category that is now heavily used in cloud and overlay networking. This article explains exactly what `100.64.0.0/10` is, when to use it, and the operational implications versus pure RFC 1918 space. ## The original problem: ISP NAT By 2010, IPv4 exhaustion was forcing ISPs to NAT their own customers. A mobile carrier serving 50 million subscribers might only have 1 million public IPv4 addresses — so they NAT subscribers behind a smaller pool of public IPs. This is **CGNAT (Carrier-Grade NAT)**, also called LSN (Large-Scale NAT). The problem: which IP range do ISPs use for the subscriber side of the NAT? The obvious answer is RFC 1918, but that breaks for any subscriber who is also running RFC 1918 internally. A home customer with `192.168.1.0/24` behind their router cannot have their ISP's CGNAT also assign them `192.168.x.x` — routing collapses. RFC 6598 solved this by reserving a new range that ISPs could use for CGNAT without colliding with customer-internal networks: ``` 100.64.0.0/10 = 100.64.0.0 - 100.127.255.255 (4,194,304 addresses) ``` ## Properties of RFC 6598 space PropertyRFC 1918 (10/8 etc)RFC 6598 (100.64/10)Filtered at internet edge?YesYesRoutable inside private nets?YesYesDesigned for general use?YesNo, ISP-only initiallyTotal addresses~17.9 million4,194,304Likely to collide with customer-internal?Yes (common)No (uncommon) For the network operator's purposes, RFC 6598 space behaves almost identically to RFC 1918: filtered at the internet edge, routable within your private network, never assignable to public destinations. The only meaningful difference is the *convention* — RFC 6598 was meant for ISPs, but the IETF did not prohibit other uses. ## Modern uses beyond ISPs Over the past decade, RFC 6598 space has been adopted for several use cases that ISPs did not anticipate: ### Cloud secondary CIDRs AWS VPCs allow up to 4 secondary CIDR blocks beyond the primary. These secondary blocks **must not overlap with the primary**, which is challenging if the primary is already RFC 1918. Adding `100.64.0.0/16` as a secondary gives you 65,536 additional addresses without burning more RFC 1918 space. This is especially common for EKS clusters. The primary VPC stays under 10/8, but pod IPs come from a CGNAT secondary CIDR. See our Kubernetes CIDR sizing article for the full pattern. ### Overlay networking (Tailscale, WireGuard meshes) Tailscale assigns each node an address in `100.64.0.0/10` by default. This works because the user's home network is almost certainly RFC 1918, and using CGNAT space eliminates a routing collision. ### Container networking Some Kubernetes CNI plugins (especially Cilium) use CGNAT space for cluster-wide IPs to avoid colliding with user VPC CIDRs. ### VPN concentrators Corporate VPN servers commonly assign clients from RFC 6598 to avoid collisions with the user's home network. ## When to use RFC 6598 vs RFC 1918 ### Use RFC 1918 (10/8 or 172.16/12 or 192.168/16) when - You are designing a greenfield network with no external integration constraints. - Your network is small (under 1,000 hosts), and RFC 1918 has plenty of room. - You are not worried about future peering with other networks that might use the same range. ### Use RFC 6598 (100.64/10) when - Your primary VPC CIDR is already RFC 1918 and you need a secondary range. - You are deploying EKS with VPC CNI and want pods isolated from VM/RDS address space. - You are building an overlay network (Tailscale, mesh VPN) that needs to coexist with user-internal RFC 1918 networks. - You are migrating from one RFC 1918 network to another and need a temporary "bridge" range that does not collide with either source or destination. ## Pitfalls to be aware of ### Some ISPs filter incoming 100.64 Because 100.64/10 is reserved for ISP-internal CGNAT, some ISPs filter inbound traffic from that range — they assume any 100.64 traffic crossing their boundary must be misconfigured. If you use 100.64 in a way that traverses third-party networks, this can silently break connectivity. ### Some firewalls treat it as untrusted Older firewall vendors did not update their default trust zones when RFC 6598 came out. You may need to manually add 100.64/10 to "trusted internal" zones, or it will be treated like public internet space. ### Mobile devices use it If your network has Wi-Fi users on mobile carriers, those devices may be NAT'd at the carrier in 100.64 space. Connecting them to a corporate Wi-Fi network that also uses 100.64 internally creates the classic NAT collision. Choose your CGNAT subnet carefully if you have mobile-heavy user bases. ### Smaller pool than RFC 1918 100.64/10 has 4 million addresses. RFC 1918 has 17.9 million. For very large organizations, CGNAT is not a complete replacement for RFC 1918; it is a supplement. ## Allocation patterns Within an organization using both RFC 1918 and RFC 6598, a useful pattern is: ``` 10.0.0.0/8 Primary corporate network (VMs, databases, users) 100.64.0.0/10 Container, overlay, and serverless workloads 172.16.0.0/12 Lab, isolated test environments 192.168.0.0/16 Office Wi-Fi (where small subnets are convenient) ``` This separates address space by workload type, which makes routing tables, firewall rules, and operational debugging easier. ## Detecting CGNAT space in traffic If you see `100.64.x.x` as a source on your internet uplink, that is almost always a leaked CGNAT from a customer's ISP. ISPs are supposed to filter it at their edge, but mistakes happen. Modern bogon-filtering BGP feeds (Team Cymru, SpamHaus DROP) include 100.64/10 in the standard bogon list. Inside your own networks, 100.64 traffic should be normal if you have adopted it for any of the use cases above. Audit your firewall logs periodically to make sure 100.64 traffic is going where you expect. ## Key takeaways - **RFC 6598** reserves `100.64.0.0/10` (4M addresses) for ISP carrier-grade NAT. - It behaves like RFC 1918 in most respects: filtered at internet edges, routable internally. - Modern use cases include cloud VPC secondary CIDRs, Kubernetes pod IPs, overlay networks (Tailscale), and VPN client pools. - Most common pattern: use RFC 6598 as a secondary VPC CIDR for EKS pods to keep your primary RFC 1918 space free. - Pitfalls: some ISPs filter inbound 100.64 traffic, mobile carriers may already NAT users from it, and older firewalls may treat it as untrusted. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Security #### Bogons, CGNAT, and Other IP Ranges That Will Ruin Your Day Some IP ranges should never appear on the internet. Bogons, CGNAT, link-local, multicast, TEST-NET — these are the non-obvious blocks that n... 9 min readKubernetes #### Sizing Kubernetes Pod and Service CIDRs Correctly You cannot resize the pod CIDR after a cluster is running. Here is the rule of thumb for sizing pod, service, and node CIDRs to handle produ... 10 min readCloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min readCloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min read ## Frequently asked questions ### What is the difference between RFC 1918 and RFC 6598? RFC 1918 defines the three classic private address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) intended for use inside enterprise and home networks, with NAT for internet access. RFC 6598 defines a separate range (100.64.0.0/10) reserved for Carrier-Grade NAT (CGNAT) used by Internet Service Providers, not by their customers. ### Can I use 100.64.0.0/10 in my enterprise network? Generally no. 100.64.0.0/10 is reserved by RFC 6598 for ISP CGNAT use. If you use it in your enterprise network and your ISP also uses it for CGNAT (many do), you will get routing conflicts. Stick to RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) for enterprise networks. ### Why do some cloud providers recommend 100.64.0.0/10? A few cloud-specific designs (notably some Kubernetes pod CIDR examples) use 100.64.0.0/10 because the RFC 1918 ranges are often exhausted in large enterprises. This works only if you control all the networks involved and none of them is also doing ISP-style CGNAT. Use with care and document the choice prominently. ### Is 100.64.0.0/10 considered private? It is non-public and not globally routable, but it is not 'private' in the RFC 1918 sense. The IETF deliberately created a separate category to avoid confusion. Treat RFC 6598 space as 'shared address space for ISP CGNAT' rather than 'another private range.' --- # Troubleshooting Overlapping CIDR Blocks: Detection and Resolution 10 min read·Published May 26, 2026·By cidrcalculator.net team Overlapping CIDR blocks are the network-architecture mistake that comes back to bite you years after you make it. Two VPCs both default to `10.0.0.0/16`. A company you acquire uses the same subnet as your DMZ. A consultant's lab range collides with your production. The discovery usually happens at the worst possible time — when business needs require the two networks to talk. This article is a playbook for handling CIDR overlap: how to detect it before deployment, what to do when it surfaces after, and the migration patterns that minimize downtime. ## Why overlap is a problem Overlap matters because the routing table is a flat namespace: each destination IP maps to one next-hop. If two networks both contain `10.0.5.42`, a router sitting between them cannot send a packet to "the right one" — there is no way to disambiguate. Concrete manifestations: - **VPC peering fails** with `InvalidVpcPeeringConnectionId.Conflict` or similar. - **Transit Gateway attachments fail** with similar errors. - **VPN tunnels won't establish** if both endpoints claim the same subnet. - **Direct Connect / ExpressRoute** rejects route advertisements that overlap with existing. - **Subtle routing failures** when overlap is partial — some traffic works, some doesn't, and the pattern is hard to diagnose. ## Detection: catching overlap before deployment The cheapest fix is the one you make before infrastructure is provisioned. Validation should happen at: - **Design time** — when someone proposes a new VPC, check the CIDR against the allocation chart. - **Code-review time** — Terraform PR opens, CI runs CIDR validation. - **Apply time** — the cloud platform itself rejects overlapping creates. Detection tools: - Our Validate tool accepts a list of CIDRs and identifies overlaps. - The IPAM-Lite tracker warns when you add an entry that overlaps existing ones. - NetBox detects overlaps server-side when allocating new prefixes. - AWS VPC IPAM rejects overlapping allocations within a pool. ## The overlap discovery checklist When you suspect overlap (or know it but need to scope the damage), gather: - **List of all known CIDR allocations** across the affected networks. Spreadsheet, IPAM, manual inventory — whatever you have. - **Active workloads** in the overlapping ranges. What instances, what services, what owners? - **Routes** that reference the overlapping ranges. Route tables, BGP, OSPF, VPN. - **Dependencies** that traverse the overlap. Anything that connects to or through the conflict zone. You cannot fix what you cannot see. Inventory first, intervene second. ## Resolution options ranked by disruption ### Option 1: avoid the connection (zero disruption) The simplest fix is to not connect. If two VPCs overlap but the business only needs them to reach the same set of external services, you can route both through a shared egress without peering them to each other. They each see only their own /16; the conflict is invisible. Limitations: only works when the connection is genuinely not needed. Cannot solve "we need our app in VPC-A to call services in VPC-B." ### Option 2: NAT at the boundary (moderate complexity) Translate one side's addresses at the boundary, so the conflicting range is presented to the other side under different addresses. Patterns: - **Private NAT Gateway** on AWS — performs NAT at the VPC edge so the "other side" sees translated addresses. - **F5 BIG-IP / Palo Alto / Fortinet appliances** — vendor NAT/SNAT in inspection VPCs. - **Application-layer proxies** — when the application is HTTP-based, an ALB / ingress controller can act as the translation point. Downsides: - End-to-end IP visibility is lost. Source IP for audit/logging becomes the NAT IP, not the original client. - Connections become asymmetric in interesting ways. Some protocols (FTP, SIP, IPsec) break under NAT. - Throughput limited by the NAT device. - Operational burden of maintaining the NAT mapping rules. Useful for emergency interconnect when re-IPing isn't possible, less ideal as a permanent solution. ### Option 3: re-IP one side (high disruption, clean result) The painful but correct option. Pick the network with smaller blast radius and move it to a non-overlapping CIDR. Steps: - **Plan the new CIDR** from a coordinated allocation chart. See our multi-cloud planning article. - **Build the new VPC** alongside the old one, with new subnets, security groups, and route tables in the correct CIDR. - **Migrate workloads**: standard patterns are blue-green (run both in parallel, cut over via DNS) or instance-by-instance (snapshot and relaunch in the new VPC). - **Update DNS and external integrations** to point at the new addresses. - **Decommission** the old VPC. Typical timeline: 2-6 weeks for a moderate-sized VPC, longer for heavily-connected ones. Plan for a maintenance window for the DNS cutover even though most preparation happens in parallel. ### Option 4: introduce a new range alongside (partial fix) If you can't move existing workloads, you can sometimes add a **secondary VPC CIDR** in non-overlapping space. New workloads go in the secondary range; old ones stay where they are. AWS allows up to 4 secondary CIDRs per VPC, including from CGNAT (`100.64.0.0/10`). This buys time but doesn't fully resolve the conflict — the original overlap still prevents the affected workloads from being reachable across the peering. Useful when most workloads can migrate gradually. ## Acquisition scenarios The classic case: your company acquires another that uses overlapping IP space. Common patterns: - **Plan re-IP into the acquisition's project plan.** If you control the timeline, do it right. - **Use private NAT on the boundary** as an interim while the acquisition's environment is re-IPed. - **If the acquired network is too critical to touch**, re-IP your side instead. Painful but sometimes the right call. - **Set aside a `/12` in your allocation chart for future acquisitions** — common defensive practice in large organizations. ## Migration patterns that minimize downtime ### Blue-green re-IP Build the entire new VPC, populate it with the migrated workloads (replicated from the source), test thoroughly, then cut over DNS in one operation. Old VPC is decommissioned after a verification period. Pros: short cutover window. Cons: requires double infrastructure cost during migration. ### Rolling re-IP (per-instance) Move workloads one at a time from old VPC to new. Each instance is replaced with a snapshot in the new VPC. Inter-instance traffic during the migration goes via Transit Gateway (which can route between non-overlapping VPCs). Pros: minimal extra infrastructure cost. Cons: longer overall timeline; complex temporary routing. ### Application-level re-IP For applications behind load balancers or service mesh, swap traffic by updating service registration rather than instance addresses. Old and new addresses are both registered; weight shifts gradually from old to new. Pros: lowest user-visible disruption. Cons: requires the application to have a service mesh or load-balancer abstraction. ## Prevention: lessons for going forward The best fix for CIDR overlap is to never get it in the first place. The discipline that prevents it: - One authoritative allocation chart for the entire organization. - No VPC gets created without an allocated CIDR from the chart. - The chart includes reserved ranges for acquisitions and growth. - Use CGNAT (`100.64.0.0/10`) for high-density workloads like Kubernetes pods. - Validate every new allocation against existing ones (use our Validate tool or NetBox or similar). ## Key takeaways - Detect overlap at **design, code review, and apply time** — three layers of defense. - **Avoidance** (don't connect) is the cheapest fix when the connection is not actually needed. - **NAT at the boundary** is a workable interim measure but is operationally complex. - **Re-IP one side** is the correct long-term fix; takes 2-6 weeks for a typical VPC. - **Blue-green or rolling migration** patterns minimize downtime during re-IP. - Prevent future overlap with an authoritative allocation chart and validation tooling. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Cloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min readCloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readFundamentals #### RFC 1918 vs RFC 6598: When to Use 100.64.0.0/10 CGNAT (100.64.0.0/10) is a 4-million-address range that is not classed as RFC 1918 private, but is filtered at internet edges. Here is when ... 7 min readCloud #### AWS Transit Gateway vs VPC Peering: Cost, Complexity, Scale VPC peering is point-to-point and free. Transit Gateway is hub-and-spoke and costs $36+/month. Here is when each is the right choice and the... 9 min read ## Frequently asked questions ### What happens when two CIDR blocks overlap? Behavior depends on where the overlap occurs. In a single VPC routing table, longest-prefix match wins — but if prefixes are identical, behavior depends on the platform (some pick the most recent, some refuse the configuration). In cross-VPC peering or VPN, overlapping CIDRs prevent the connection from being established at all. In ACLs and firewall rules, overlap can cause rules to silently mask each other. ### How do I find overlapping CIDRs in an existing network? Export your subnet inventory to a list, then run pairwise overlap checks. The CIDR Calculator's overlap tool does this for two blocks at a time; the IPAM tool detects conflicts as you add entries. For large inventories, sort by network integer and check whether each subnet's range contains or is contained by its neighbors. ### Can overlapping CIDRs be fixed without downtime? Sometimes. If the overlap is in a routing table you control and traffic is not yet flowing through the conflicting routes, you can renumber the less-critical subnet. If the overlap is in a peering connection, you must renumber one side, which typically requires migrating workloads to new addresses — usually a planned maintenance event. --- # Generating Terraform from a Subnet Design 10 min read·Published May 26, 2026·By cidrcalculator.net team Every cloud platform supports Terraform, and Terraform is the de facto standard for production VPC provisioning. The path from "we want a VPC with these subnets" to working Terraform code is straightforward but has plenty of places to introduce errors: typos in CIDRs, off-by-one alignment mistakes, forgetting AZ assignments, and so on. This article walks through the patterns that turn a designed subnet allocation into reliable Terraform, the common mistakes to avoid, and how to generate the boilerplate automatically. Our IaC Export tool generates Terraform from a VLSM design in one click — but understanding what it produces is essential for production use. ## The minimum-viable AWS VPC in Terraform A bare-bones VPC with three subnets across three AZs: ``` resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" enable_dns_support = true enable_dns_hostnames = true tags = { Name = "prod-vpc" } } resource "aws_subnet" "private_a" { vpc_id = aws_vpc.main.id cidr_block = "10.0.0.0/20" availability_zone = "us-east-1a" tags = { Name = "prod-private-a", Tier = "private" } } resource "aws_subnet" "private_b" { vpc_id = aws_vpc.main.id cidr_block = "10.0.16.0/20" availability_zone = "us-east-1b" tags = { Name = "prod-private-b", Tier = "private" } } resource "aws_subnet" "private_c" { vpc_id = aws_vpc.main.id cidr_block = "10.0.32.0/20" availability_zone = "us-east-1c" tags = { Name = "prod-private-c", Tier = "private" } } ``` This works, but it does not scale. For a real production VPC with web/app/db tiers across three AZs, you would have 9 subnet resources, plus route tables, internet/NAT gateways, security groups, and route table associations. Inlining all of that is unmaintainable. ## The modular approach Production Terraform for VPCs uses a few patterns to stay clean: ### Pattern 1: cidrsubnet() for derived blocks Terraform has a built-in function, `cidrsubnet()`, that derives child CIDRs from a parent. Avoids hardcoding CIDR strings. ``` variable "vpc_cidr" { default = "10.0.0.0/16" } locals { azs = ["us-east-1a", "us-east-1b", "us-east-1c"] # 9 subnets: 3 tiers × 3 AZs, each /20 subnet_cidrs = { private_a = cidrsubnet(var.vpc_cidr, 4, 0) # 10.0.0.0/20 private_b = cidrsubnet(var.vpc_cidr, 4, 1) # 10.0.16.0/20 private_c = cidrsubnet(var.vpc_cidr, 4, 2) # 10.0.32.0/20 public_a = cidrsubnet(var.vpc_cidr, 4, 3) # 10.0.48.0/20 public_b = cidrsubnet(var.vpc_cidr, 4, 4) # 10.0.64.0/20 public_c = cidrsubnet(var.vpc_cidr, 4, 5) # 10.0.80.0/20 db_a = cidrsubnet(var.vpc_cidr, 8, 96) # 10.0.96.0/24 db_b = cidrsubnet(var.vpc_cidr, 8, 97) # 10.0.97.0/24 db_c = cidrsubnet(var.vpc_cidr, 8, 98) # 10.0.98.0/24 } } ``` The function signature is `cidrsubnet(prefix, newbits, netnum)`. It extends the prefix by `newbits` bits and uses `netnum` for those bits. Read more in the Terraform documentation. ### Pattern 2: for_each over a subnet map Once you have a map of subnets, create them all with one resource block using `for_each`: ``` resource "aws_subnet" "this" { for_each = local.subnet_cidrs vpc_id = aws_vpc.main.id cidr_block = each.value availability_zone = local.azs[index(keys(local.subnet_cidrs), each.key) % 3] tags = { Name = "prod-${each.key}" Tier = split("_", each.key)[0] } } ``` This creates 9 subnet resources from one block. Adding or removing a subnet is one line in the map. ### Pattern 3: Use a community module For most teams, writing VPC Terraform from scratch is not worth it. The terraform-aws-modules/vpc/aws module has been the de facto standard since 2018 and handles every edge case (NAT gateways, VPC endpoints, flow logs, IPv6, transit gateway attachments). ``` module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "~> 5.0" name = "prod-vpc" cidr = "10.0.0.0/16" azs = ["us-east-1a", "us-east-1b", "us-east-1c"] private_subnets = ["10.0.0.0/20", "10.0.16.0/20", "10.0.32.0/20"] public_subnets = ["10.0.48.0/20", "10.0.64.0/20", "10.0.80.0/20"] database_subnets = ["10.0.96.0/24", "10.0.97.0/24", "10.0.98.0/24"] enable_nat_gateway = true single_nat_gateway = false # one per AZ for HA enable_vpn_gateway = false enable_dns_hostnames = true } ``` Most production AWS deployments should use this module unless there is a specific reason not to. The custom Terraform above is useful for understanding what is happening, but in practice "use the module" is the right answer. ## Common mistakes ### Hardcoded CIDRs that drift from documentation If your subnet CIDRs are hardcoded in Terraform and also in a Confluence page, the two will drift. Use Terraform outputs to render the actual CIDRs into reports/docs, not vice versa. ### Forgetting AZ count for cidrsubnet() If you use `cidrsubnet(var.vpc_cidr, 4, count.index)` with 9 subnets, you carve the /16 into 16 chunks (/20 each). If you later add a 10th subnet with the same pattern, no problem. But if you change `4` to `5` (carving into /21), every existing subnet's CIDR changes — and Terraform will try to delete and recreate them. Audit any change to `newbits`. ### Off-by-one in netnum `cidrsubnet("10.0.0.0/16", 4, 0)` gives `10.0.0.0/20`. The first subnet is netnum=0, not netnum=1. Documenting this convention in comments prevents confusion later. ### Not reserving address space for growth If you allocate the full /16 across 16 /20 subnets at provisioning time, there is no room to grow. Use 9-12 subnets out of the 16 possible /20s, leaving the rest reserved. ### Cross-AZ database subnets that are too small RDS Multi-AZ requires a DB subnet group with at least 2 AZs. Each subnet needs at least the minimum size for your instance class (which AWS sets at 8+ IPs for most engines). A /28 is technically usable but very tight; /24 is the practical minimum for production databases. ## Beyond AWS: Azure and GCP patterns Azure's Terraform provider uses `azurerm_virtual_network` and `azurerm_subnet`. The main differences from AWS: - Some subnets need specific names hardcoded by the platform: `GatewaySubnet`, `AzureBastionSubnet`, `AzureFirewallSubnet`. Get the name wrong and the platform refuses to recognize the subnet. - NSGs are attached at the subnet level (not per-instance like AWS security groups). - VNet peering is a separate resource and is one-directional — you need both ends configured. See our Azure VNet subnet sizing guide for the full pattern. GCP uses `google_compute_network` and `google_compute_subnetwork`. The main differences: - Subnets are regional (one per region), not zonal. Simpler than AWS multi-AZ patterns. - Auto-mode VPCs come with pre-defined subnets in every region. Always use custom-mode for production. - Subnet expansion (growing an existing subnet's CIDR) is supported in GCP without downtime. AWS and Azure require recreation. ## Generating Terraform automatically Our IaC Export tool turns a VLSM design into ready-to-use Terraform for AWS, Azure, or GCP. The workflow: - Design your subnet allocation in the VLSM Designer. - Click "Export to IaC". - Choose your provider (AWS, Azure, GCP). - Pick the format: terraform-aws-modules style, raw resources, CloudFormation, Pulumi, or Ansible. - Copy the generated code into your repo. The generator handles the boilerplate (route tables, NAT gateways, AZ assignment, tagging) so you can focus on the parts that vary by your organization. ## Key takeaways - Use **cidrsubnet()** in Terraform to derive child CIDRs from a parent VPC CIDR — avoids hardcoded magic numbers. - Use **for_each** to create many subnets from one resource block. - For most AWS deployments, use the **terraform-aws-modules/vpc/aws** community module instead of hand-rolling resources. - Reserve unallocated CIDR space for future subnets; do not provision the entire VPC at day one. - Use our **IaC Export** to generate provider-specific Terraform from a designed VLSM allocation. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Cloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readCloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min readCloud #### Azure VNet Subnet Sizing: GatewaySubnet, Bastion, Firewall Azure has reserved subnet names with specific size requirements (GatewaySubnet, AzureBastionSubnet, AzureFirewallSubnet) that trip up first-... 9 min readFundamentals #### VLSM Explained: Variable-Length Subnet Masking from Scratch VLSM lets you allocate different-sized subnets from one parent network without wasting addresses. This worked example shows the largest-firs... 10 min read --- # Bogons, CGNAT, and Other IP Ranges That Will Ruin Your Day 9 min read·Published May 26, 2026·By cidrcalculator.net team The public IPv4 address space looks like a flat 4-billion-address pool from outside, but it is in fact carved up by a dozen reservations that should never appear on the internet. These ranges — collectively called **bogons** — are critical to filter in production network configurations, because their presence on internet traffic is almost always a sign of spoofing, misconfiguration, or malicious activity. This article walks through every bogon range, the lesser-known semi-private ranges like CGNAT, and the operational impact of not filtering them. If you maintain firewall rules, BGP feeds, or any network ACLs, this is the reference you want. ## The standard bogon list RangeReason / RFCWhat to do if you see it0.0.0.0/8"This network" (RFC 1122)Drop. Only valid as a source on a DHCP DISCOVER.10.0.0.0/8RFC 1918 privateDrop on internet ingress.100.64.0.0/10CGNAT (RFC 6598)Drop on internet ingress.127.0.0.0/8Loopback (RFC 1122)Drop. Only valid on the local host.169.254.0.0/16Link-local / APIPA (RFC 3927)Drop. Only valid on the local link.172.16.0.0/12RFC 1918 privateDrop on internet ingress.192.0.0.0/24IETF Protocol AssignmentsDrop. Reserved for IANA use.192.0.2.0/24TEST-NET-1 (RFC 5737)Drop. Documentation only.192.168.0.0/16RFC 1918 privateDrop on internet ingress.198.18.0.0/15Benchmark testing (RFC 2544)Drop. Lab testing only.198.51.100.0/24TEST-NET-2 (RFC 5737)Drop. Documentation only.203.0.113.0/24TEST-NET-3 (RFC 5737)Drop. Documentation only.224.0.0.0/4Multicast (RFC 5771)Drop as unicast destination.240.0.0.0/4Reserved / former Class EDrop. Has never been assigned.255.255.255.255/32Limited broadcastDrop. Never crosses a router. Together, these ranges total roughly 593 million IPv4 addresses — about 14% of the total IPv4 space — that should never appear as a source on an internet uplink. If you see traffic from one of these ranges arriving on a public-facing interface, it is almost certainly spoofed or misconfigured. ## The semi-private ranges that confuse people ### CGNAT: 100.64.0.0/10 The biggest source of confusion. **CGNAT (Carrier-Grade NAT) space** is defined in RFC 6598 and reserved for ISP-internal use. It is not RFC 1918 private, but it is also not public — it sits in a third category specifically for ISP NAT pools. The range contains 4,194,304 addresses, which is what mobile carriers use to NAT millions of subscribers behind a smaller pool of public IPv4 addresses. Real-world uses today: - Mobile carriers NAT'ing subscribers - AWS EKS clusters using `100.64.0.0/16` as a secondary VPC CIDR for pod IPs (avoids burning RFC 1918 space — see our Kubernetes CIDR sizing article) - Tailscale and other overlay networks - VPN concentrator client pools Routes to this range are filtered at internet edges by most ISPs. CGNAT acts effectively private even though it is not RFC 1918. If you see `100.64.x.x` traffic on your internet uplink, it usually means a customer's ISP is leaking their internal CGNAT. ### APIPA: 169.254.0.0/16 The link-local range that hosts assign themselves when DHCP fails. If you see `169.254.x.x` on a machine, your DHCP server is unreachable. Legitimate uses include AirPlay, Bonjour/mDNS, and ad-hoc networking. The most operationally significant use today is the AWS instance metadata service at `169.254.169.254` — every EC2 instance reaches it for credentials and config. Azure similarly uses `168.63.129.16` (technically not link-local but uses the convention). ### 192.0.0.0/24 — IANA assignments A small block reserved for IANA's protocol assignments. Includes `192.0.0.8/32` (IPv4 dummy address used by some applications) and `192.0.0.170`/`192.0.0.171` (NAT64/DNS64 well-known). Drop all of it on internet ingress. ### 198.18.0.0/15 — benchmark range RFC 2544 reserves this for lab benchmark testing. You will rarely see it in the wild — but if you do, someone is leaking lab traffic onto the public internet. ## Where bogons cause real damage ### Spoofed DDoS attacks Attackers spoof source addresses in reflection attacks. Without bogon filtering at your edge, the attacker's traffic uses fake source IPs from RFC 1918 or TEST-NET ranges, making attribution impossible. Standard bogon filtering at your network edge limits the source addresses an attacker can use. ### BGP hijacks via bogon space A malicious or compromised AS can announce a bogon range. Without BGP-level filtering, your routers may install routes to `10.0.0.0/8` via some upstream peer — disrupting all your internal RFC 1918 traffic. Standard practice: filter bogon prefixes in BGP imports. ### Improper firewall rules A rule like "permit any source to webserver port 443" will accept connections from `169.254.x.x` if your edge is misconfigured. While rare in practice, lazy firewall rules that do not exclude bogon sources can be exploited in cases of route leaks or accidental peerings. ### Internal misconfigurations The most common bogon issue is internal: someone configures a static route to `0.0.0.0/8` by mistake, or uses TEST-NET addresses in a production config thinking they are private. The result is silently broken traffic for that range. ## Sources of bogon lists The bogon list changes occasionally when previously-reserved IPv4 ranges get allocated. Always use a maintained feed rather than hand-maintaining a list: - **Team Cymru Bogon BGP Feed** — free BGP feed of current bogons. The industry standard for internet-edge routers. - **SpamHaus DROP and EDROP lists** — "Don't Route Or Peer" lists of hijacked and bogus prefixes. - **RPKI route validation** — does not directly filter bogons but reduces the risk of bogon hijacks by validating route origins. ## IPv6 bogons IPv6 has its own bogon list, though the space is so much larger that bogons are a smaller percentage: RangeReason::/8Unspecified, loopback, IPv4-mapped100::/64Discard prefix (RFC 6666)2001:db8::/32Documentation (RFC 3849)fc00::/7Unique Local (ULA)fe80::/10Link-localff00::/8Multicast Also any prefix not currently allocated by IANA. Because IPv6 allocations change more frequently than IPv4, the maintained feeds (Team Cymru) are even more important. ## Detecting bogons in your traffic Our Validate tool checks a list of CIDR blocks for overlaps with reserved ranges. If you paste in a list of source IPs from a firewall log and run it through Validate, anything overlapping a bogon range is immediately visible. For ongoing monitoring, flow analysis tools (NetFlow, sFlow, IPFIX) can identify traffic from bogon source addresses on your edge interfaces. Any non-zero count is worth investigating — it is either a misconfigured customer or an active attack. ## Key takeaways - The standard bogon list covers ~14% of IPv4 address space that should never appear on the internet. - The most operationally important non-obvious ranges: **CGNAT (100.64.0.0/10)**, **link-local (169.254/16)**, and the three **TEST-NET blocks**. - CGNAT is not RFC 1918 but acts effectively private. Modern cloud and overlay networking commonly use it. - Filter bogons at your internet edge, in BGP imports, and in firewall rules. - Use a maintained feed (Team Cymru) rather than a hand-maintained list — bogon ranges change. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Fundamentals #### RFC 1918 vs RFC 6598: When to Use 100.64.0.0/10 CGNAT (100.64.0.0/10) is a 4-million-address range that is not classed as RFC 1918 private, but is filtered at internet edges. Here is when ... 7 min readCloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readSecurity #### Troubleshooting Overlapping CIDR Blocks: Detection and Resolution Two VPCs need to peer but CIDRs overlap. A new acquisition uses your IP space. Here is the playbook for detecting, isolating, and resolving ... 10 min readCloud #### Public vs Private Subnets: When to Use Each What actually makes an AWS subnet "public" or "private", and how to design tiers so workloads have the right combination of internet access ... 8 min read --- # Subnetting by Host Count vs by Subnet Count 7 min read·Published May 26, 2026·By cidrcalculator.net team There are two common ways to express a subnetting requirement: "I need subnets each with at least N hosts" or "I need at least M subnets from my parent network." Both produce a prefix length, but the math is different. Knowing both methods makes you faster at the right one for any given question. This article works through both approaches with examples, and shows how they connect to each other. ## Method 1: subnetting by host count You know how many hosts each subnet must hold. Find the smallest prefix that accommodates that count. ### Formula - You need N hosts. - You need at least N + 2 total addresses (network + broadcast not usable). - Round up to the next power of 2. - Prefix = 32 − log₂(that power). ### Quick reference Hosts neededMin total addressesNext power of 2PrefixUsable244/302688/296101216/2814252732/2730505264/2662100102128/25126250252256/24254500502512/235101,0001,0021,024/221,022 ### Example You need 60 hosts per subnet. Round 62 up to 64. Prefix = 32 − 6 = **/26** (62 usable). ## Method 2: subnetting by subnet count You know how many subnets you need to carve from a parent network. Find the smallest number of bits to borrow. ### Formula - You need M subnets. - Borrow B bits where 2^B ≥ M. - New prefix = parent_prefix + B. ### Quick reference Subnets neededBits to borrowTotal subnets created1012123-4245-8389-1641617-3253233-6466465-1287128129-2568256 ### Example You have `10.0.0.0/16` and need 10 subnets. Borrow 4 bits (2^4 = 16 ≥ 10). New prefix = 16 + 4 = **/20**. You get 16 subnets, each with 4,094 usable hosts. ## The two methods connected If you take a parent /16 and need 10 subnets each with 200 hosts, both methods agree: - **By host count:** 200 hosts → /24 → fits in a /16 easily. - **By subnet count:** 10 subnets from a /16 → /20. But each /20 has 4,094 hosts, much more than 200 needed. This is the conflict. Using only the subnet-count method, you would carve into /20s, but each /20 is wildly over-sized for 200 hosts each. Using only the host-count method, you'd carve /24s, but you could carve 256 of them — way more than 10 needed, and you "lose" the smaller subnets from being directly usable. **The host-count method is almost always what you actually want.** The subnet-count method is mostly an artifact of legacy classful subnetting where each subnet was constrained to a fixed prefix length. With VLSM (which is now universal), you can have different-sized subnets, so size each to its actual hosts. ## Method 3 (bonus): the combined VLSM approach For real-world subnetting, you usually have a mix of requirements — some subnets need 250 hosts, others need 14, others need 2. The combined approach is VLSM: - Use the host-count method for *each* subnet independently. - Allocate from a parent network largest-first. - Each subnet is exactly the size it needs to be. See our VLSM article for the full worked example. ## Where the subnet-count method still matters Despite VLSM being the modern default, the subnet-count method comes up in a few practical contexts: - **Cloud subnet provisioning:** "I have a /16 VPC and want 12 equal-sized subnets." Borrow 4 bits → /20s. All equal. Suitable when subnets serve identical functions (e.g., one per AZ for a uniform tier). - **OSPF / EIGRP area design:** Each area gets a /N subnet. Subnet count determines how many areas you can carve. - **CCNA exam questions:** Some questions are phrased as "how many subnets if you use prefix /X" — explicit subnet-count framing. ## The "minimum hosts per subnet" trap If a question says "minimum 50 hosts per subnet," people often forget the +2 for network and broadcast. 50 hosts → /26 (62 usable), not /27 (30 usable, which fails the requirement). Triple-check: usable count = 2^(32-prefix) − 2. The −2 is critical. ## Common questions ### "How many /24s in a /16?" 2^(24-16) = 2^8 = 256. ### "How many /28s in a /24?" 2^(28-24) = 2^4 = 16. ### "How many subnets of any size in a /16, given some are /20 and some are /24?" Now VLSM. Each /20 consumes 1/16 of the parent, each /24 consumes 1/256. Use a tool like our VLSM Designer to plan it. ## Cloud-specific reservations For AWS, Azure, and GCP, subtract 3-5 from the usable count to account for cloud-reserved IPs. See our AWS reserved IPs article for details. ## Key takeaways - **Host-count method**: round (hosts + 2) up to next power of 2, compute prefix from there. Use this 95% of the time. - **Subnet-count method**: borrow B bits where 2^B ≥ M subnets needed. Useful when all subnets are equal-sized. - Modern subnetting uses **VLSM**: combine host-count sizing with largest-first allocation from a parent network. - Always remember **−2 for network and broadcast** (except /31, which has 2 usable per RFC 3021). ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Fundamentals #### How to Calculate Subnets by Hand (the magic number method) The magic number method lets you find any subnet, broadcast address, or host count in under 30 seconds without binary math. Worked examples ... 9 min readFundamentals #### VLSM Explained: Variable-Length Subnet Masking from Scratch VLSM lets you allocate different-sized subnets from one parent network without wasting addresses. This worked example shows the largest-firs... 10 min readFundamentals #### The Complete Subnet Mask Cheat Sheet (/0 to /32 with examples) Full reference table of IPv4 subnet masks from /0 to /32: prefix, dotted decimal, hex, host count, AWS usable, and common use cases. Printab... 7 min readCareer #### The CCNA Subnetting Questions That Trip People Up If you are studying for the CCNA, here are the eight subnetting question patterns that consistently cause failure. Each one is solvable in 3... 8 min read --- # EKS VPC CNI Prefix Delegation: 16x More Pods Per Node 10 min read·Published May 26, 2026·By cidrcalculator.net team By default, the AWS VPC CNI plugin assigns each EKS pod its own private VPC IP from your subnet. That gives pods direct VPC connectivity but caps the pod density per node at the instance type's ENI/IP limit. An `m5.large` can run 29 pods. An `m5.xlarge` can run 58. For dense microservice workloads, that is way too few. In 2021, AWS introduced **prefix delegation** for the VPC CNI: instead of one IP per pod, ENIs receive entire `/28` prefixes (16 IPs each). This raises the per-node pod limit to **110+ for almost any instance type** — a 4-16x density improvement that often eliminates the need for larger nodes. This article explains how prefix delegation works, when to use it, the tradeoffs, and the production configuration patterns. ## The original ENI/IP limit problem Without prefix delegation, the VPC CNI plugin works like this: - Each EC2 instance has a fixed maximum number of ENIs. - Each ENI can hold a fixed number of secondary IPs. - Total pod IPs available = (ENIs - 1) × IPs_per_ENI + (IPs_per_ENI - 1). - (One IP per ENI is used by the ENI itself; the primary ENI's primary IP is used by the node.) Instance typeENIsIPs/ENIMax pods (no PD)Max pods (with PD)m5.large31029110m5.xlarge41558110m5.2xlarge41558110m5.4xlarge830234250m5.8xlarge830234250c5.large31029110r5.large31029110 Note the cliff at large instance sizes — m5.large to m5.2xlarge all hit the 110 kubelet default with prefix delegation, even though without PD the IP capacity scales linearly. This means prefix delegation often lets you run smaller, cheaper instances at the same pod count. ## How prefix delegation works Instead of assigning individual IPs to an ENI, prefix delegation assigns **/28 prefixes (16 addresses each)**. The math becomes: - Each ENI can hold a fixed number of prefixes (instead of IPs). - Each prefix gives 16 pod IPs (a /28). - So an ENI that previously held 10 IPs now holds 10 prefixes = 160 IPs. The prefix is just a contiguous range of IPs in your subnet that this ENI "owns." Pods on that node take IPs from the prefix. ## Enabling prefix delegation It is an environment variable on the VPC CNI daemonset: ``` kubectl set env daemonset aws-node \ -n kube-system \ ENABLE_PREFIX_DELEGATION=true ``` Or via Helm chart values, or via the EKS addon configuration if you manage the CNI as an EKS addon. After enabling, new nodes use prefix delegation immediately. Existing nodes continue with their original IP allocation until they are recycled. ## Warm prefix targets Prefix delegation introduces tuning around how many prefixes to pre-fetch on each node. The relevant settings: VariableDefaultPurposeWARM_PREFIX_TARGET1Keep N extra prefixes warm beyond current needMINIMUM_IP_TARGET-Minimum free IPs (overrides prefix-based logic)WARM_IP_TARGET-Keep N free IPs warm The default of `WARM_PREFIX_TARGET=1` means each node has at least one fully-spare prefix ready for pod scheduling. For a node that runs 50 pods steady-state, the CNI may hold 5 prefixes (80 IPs) — using 50, with 30 "wasted" as warm capacity. For tighter VPC space, lower `WARM_PREFIX_TARGET` to 0 and use `MINIMUM_IP_TARGET=10` to keep just 10 IPs warm regardless of prefix count. ## Subnet sizing with prefix delegation The math for subnet sizing changes when prefixes are involved. Each node consumes one or more /28 prefixes (16 IPs each). For a 100-node cluster: - Worst case (max density, lots of warm prefixes): each node holds 7 prefixes = 112 IPs. 100 nodes × 112 = 11,200 IPs needed. - Typical: each node holds 3-4 prefixes = 48-64 IPs. 100 nodes × 56 = 5,600 IPs needed. That's a substantial chunk of any subnet. The pattern most teams use is to give EKS its own subnet (or set of per-AZ subnets) sized as `/20` (4,091 usable AWS) or `/19` (8,187 usable). Or, even better, put pods in a CGNAT secondary VPC CIDR — see our Kubernetes pod CIDR sizing article for the full pattern. ## When NOT to use prefix delegation - **Very low pod density**. If you only run 5-10 pods per node, the prefix overhead wastes IPs. Stick with individual IP assignment. - **Subnets are already tight on space**. Prefix delegation needs contiguous /28s in your subnet. If your subnet is fragmented or near-full, you may not be able to allocate them. - **You use security groups for pods**. With pod-level security groups, every pod gets its own ENI (with its own primary IP). Prefix delegation does not apply. - **You are on Nitro-generation instances only**. Prefix delegation requires Nitro-generation instances; older instance types (m4, c4, r4) do not support it. ## Bottlerocket and self-managed nodes Prefix delegation works on: - **Amazon Linux 2 / 2023 EKS-optimized AMIs** — supported since 2021 - **Bottlerocket** — supported, automatically configured - **EKS managed node groups** — supported when CNI version is recent enough - **Self-managed node groups** — supported, configure manually via bootstrap script - **Karpenter-provisioned nodes** — supported, set on the CNI daemonset The pod density limit (`MAX_PODS`) is set by the kubelet startup. The EKS-optimized AMI has a script `/etc/eks/max-pods-calculator.sh` that computes this. Older versions of the script do not know about prefix delegation; update the AMI or override `MAX_PODS` manually. ## Operational gotchas - **Fragmented subnets reject prefix allocation.** If your subnet has individual IPs scattered around (from non-PD pods, ENIs, lambda, etc.), AWS may not find a contiguous /28 to delegate. Solve by giving EKS dedicated subnets. - **Node startup time can increase** if the CNI has to allocate many prefixes for warming. Tune `WARM_PREFIX_TARGET` down if startup matters. - **IPv6 mode is separate.** EKS IPv6 clusters work differently — every pod gets an IPv6 address out of a /80 delegated to the ENI. No /28 prefixes involved. ## Calculator workflow Our Cloud calculator in EKS mode computes the right subnet size given: - Target node count - Target pods per node - Whether prefix delegation is enabled - Warm prefix target Use it to plan a new EKS subnet allocation before applying. ## Key takeaways - **Prefix delegation** raises the per-node pod limit from 29 (m5.large) to 110+ by handing ENIs `/28` prefixes (16 IPs each) instead of individual IPs. - Enable with `ENABLE_PREFIX_DELEGATION=true` on the aws-node daemonset. - Each EKS node typically holds 3-7 /28 prefixes (48-112 IPs) under default warm target settings. - Tune `WARM_PREFIX_TARGET` and `MINIMUM_IP_TARGET` for tighter IP usage at the cost of slower pod scheduling. - Combine with CGNAT secondary VPC CIDRs to keep pod IPs separate from VM/RDS address space. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Kubernetes #### Sizing Kubernetes Pod and Service CIDRs Correctly You cannot resize the pod CIDR after a cluster is running. Here is the rule of thumb for sizing pod, service, and node CIDRs to handle produ... 10 min readCloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readFundamentals #### RFC 1918 vs RFC 6598: When to Use 100.64.0.0/10 CGNAT (100.64.0.0/10) is a 4-million-address range that is not classed as RFC 1918 private, but is filtered at internet edges. Here is when ... 7 min readCloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min read --- # NAT Gateway vs NAT Instance vs VPC Endpoints 9 min read·Published May 26, 2026·By cidrcalculator.net team The "NAT problem" in AWS is a familiar one: your private subnets need to reach the internet (or AWS services like S3) for software updates, API calls, and similar — but you do not want those workloads directly accessible from the public internet. The three main solutions are NAT Gateway, NAT Instance, and VPC Endpoints. Each has different cost, performance, and operational profiles. Picking wrong can lead to either security risk or a surprisingly large AWS bill. This article compares the three, explains when each is the right choice, and shows how a combination is often the optimal answer for cost-conscious architectures. ## The three options at a glance FeatureNAT GatewayNAT InstanceVPC EndpointManaged by AWS?YesNo (you run an EC2)YesHigh availabilityPer-AZ built-inYou build itYesThroughputUp to 100 GbpsInstance dependentService dependentCostHourly + per-GBEC2 hourly onlyHourly (interface) or free (gateway)ReachesInternetInternetSpecific AWS services onlyOperational complexityLowMedium-HighLow ## NAT Gateway: the default answer AWS's managed NAT service. You create one per AZ for HA, route private subnet traffic to it via the route table, and your private workloads can reach the internet. ### Pros - Fully managed — no patching, no replacement - Scales to 100 Gbps per AZ - Per-AZ HA built in - Supports up to 55,000 concurrent connections to a single destination ### Cons - **Cost.** Roughly $0.045/hour per NAT Gateway plus $0.045 per GB of data processed (us-east-1 as of 2026). A single-AZ NAT Gateway is ~$33/month idle, plus data transfer. Three-AZ NAT Gateways are ~$100/month idle, before any data. - The per-GB cost dominates at any meaningful scale. A workload that pushes 10 TB/month through NAT pays $450 in NAT data processing fees alone (plus $33-100 for the gateway). - Per-AZ — cross-AZ NAT traffic incurs additional inter-AZ transfer fees. ### When to use it Almost always the right answer for production unless you have specific cost or feature constraints. The operational simplicity is worth the cost for most workloads. ## NAT Instance: the cost-optimized DIY answer Run an EC2 instance (typically with the legacy NAT AMI or a small Linux instance configured to do NAT) and route private subnet traffic to it. You pay only for the EC2 instance — no per-GB data processing fee. ### Pros - **Massive cost savings** at scale. A t3.nano running as NAT costs $3-4/month for the instance vs $33+ for NAT Gateway, AND there is no per-GB charge. For high-traffic workloads, savings can be 90%+. - You control the host — can add IDS, custom logging, traffic shaping, etc. - Can be used for outbound source NAT with a static IP that you control ### Cons - **You operate it.** Patching, AMI updates, failover orchestration, monitoring. - HA is your problem. Either Auto Scaling Group with route table swap on failure, or a multi-instance setup with health checks. - Throughput limited by instance type. A t3.nano caps around 1-2 Gbps. - Single-instance NAT is a SPOF unless you build HA. ### When to use it - Dev/staging environments where downtime is acceptable - Cost-sensitive production workloads with predictable traffic patterns - Use cases that need IDS/IPS at the NAT boundary - When you need to control the outbound source IP ## VPC Endpoints: the elimination answer VPC Endpoints let your private subnet workloads reach **specific AWS services without going through NAT at all**. Traffic stays inside the AWS backbone — no internet, no NAT, no per-GB processing. Two types: TypeServices supportedCost**Gateway endpoint**S3, DynamoDBFree**Interface endpoint (PrivateLink)**Most AWS services and SaaS~$0.01/hour per AZ per endpoint, plus per-GB ### Gateway endpoints For S3 and DynamoDB only. Add a route table entry pointing those services through the gateway endpoint. Traffic never leaves the VPC. **Completely free.** Every AWS VPC that talks to S3 should have an S3 gateway endpoint. There is no reason not to — it's free, fast, and eliminates NAT processing fees for S3 traffic. The amount you save on a high-S3-traffic workload is substantial. ### Interface endpoints (PrivateLink) For most other AWS services (SQS, SNS, ECR, EC2 API, KMS, Secrets Manager, etc.) and third-party SaaS that supports PrivateLink. Each endpoint costs roughly $7/month per AZ + $0.01/GB of data processed. The cost calculus: if you push more than ~$10/month of NAT data for a specific service, an interface endpoint is cheaper. For high-volume services like ECR (image pulls) or CloudWatch Logs (log ingestion), the savings are large. ## The combined production pattern Cost-optimized production VPCs use all three: - **NAT Gateway** for general internet egress (package updates, third-party APIs) - **S3 gateway endpoint** for all S3 traffic (free, no NAT charges) - **DynamoDB gateway endpoint** if you use DynamoDB - **Interface endpoints** for high-traffic AWS services (ECR, KMS, Secrets Manager, CloudWatch Logs) - **NAT Instance** only in dev/staging for cost savings, not in production This pattern can cut NAT data charges by 80-95% in workloads that talk heavily to AWS services (which is most workloads). The setup cost is one-time; the savings recur monthly. ## How to identify NAT savings opportunities Look at NAT Gateway metrics in CloudWatch: - `BytesOutToDestination` — total bytes going out from NAT - VPC Flow Logs filtered to NAT IPs — destination service/endpoint analysis The top destinations by byte volume are your highest-value endpoint candidates. ECR (`*.dkr.ecr.region.amazonaws.com`) and S3 are almost always near the top. ## Egress-only Internet Gateway (IPv6) For IPv6 traffic, AWS has an analogous concept: the **Egress-only Internet Gateway**. Lets IPv6 workloads in private subnets reach the internet without being reachable from the internet. Free — no per-GB fee unlike NAT Gateway for IPv4. If your workloads are dual-stack, route IPv6 egress through the egress-only IGW and reserve NAT Gateway only for IPv4 traffic. Further reduces NAT bills. ## Common mistakes - **No S3 gateway endpoint.** Easiest free win in any VPC. Always add it. - **Cross-AZ NAT.** If all your workloads run in us-east-1a but your NAT Gateway is in us-east-1b, every byte goes cross-AZ. Always create one NAT Gateway per AZ and route per-AZ traffic to its local one. - **Interface endpoint for every service.** Cost only pays off for high-traffic services. For low-traffic services (KMS calls happen rarely), the NAT route is cheaper. - **Forgetting that VPC Endpoints have policies.** An S3 gateway endpoint defaults to allowing all S3 access. Use endpoint policies to restrict to specific buckets. ## Key takeaways - **NAT Gateway** is the right default for managed, scalable internet egress. Cost: ~$33/AZ/month + per-GB. - **NAT Instance** is dramatically cheaper if you accept the operational burden. Useful for dev/staging. - **S3 gateway endpoint** is free and should be in every VPC. Eliminates NAT charges for S3. - **Interface endpoints (PrivateLink)** cut costs for high-traffic AWS services like ECR and CloudWatch Logs. - **Egress-only IGW** handles IPv6 egress with no NAT fee. - Use VPC Flow Logs to identify your highest-traffic destinations and prioritize endpoint setup accordingly. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Cloud #### Public vs Private Subnets: When to Use Each What actually makes an AWS subnet "public" or "private", and how to design tiers so workloads have the right combination of internet access ... 8 min readCloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readCloud #### AWS Transit Gateway vs VPC Peering: Cost, Complexity, Scale VPC peering is point-to-point and free. Transit Gateway is hub-and-spoke and costs $36+/month. Here is when each is the right choice and the... 9 min readCloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min read --- # AWS Transit Gateway vs VPC Peering: Cost, Complexity, Scale 9 min read·Published May 26, 2026·By cidrcalculator.net team If you have two VPCs that need to talk, AWS gives you two main options: **VPC peering** (a direct point-to-point connection) or **Transit Gateway** (a hub-and-spoke router). They have very different cost, complexity, and scaling profiles. Picking the wrong one can result in either a $0 solution that scales poorly or a $200+/month bill for what should be free. This article compares the two, walks through the breakeven analysis as VPC count grows, and covers the operational patterns that work. ## The two options at a glance FeatureVPC PeeringTransit GatewayTopologyPoint-to-pointHub-and-spokeScalingQuadratic (N² peerings for full mesh)Linear (N attachments)CostFree + per-GB data transfer$36/month + per-attachment + per-GBCross-regionYes (paid by GB)Yes (paid by GB + peering cost)Transitive routingNoYesRoute tablesVPC route table onlyTGW route tables + VPC route tablesSecurity groups across peeringReference SG IDs in some setupsReference SG IDs not supportedMaximum connections125 active peerings per VPC5,000 VPCs per TGW (with quota increase) ## VPC Peering: simple, free, doesn't scale A VPC peering is a direct connection between two VPCs. Once established, instances in either VPC can route to instances in the other (provided route tables and security groups allow it). ### Pros - **No fixed cost.** Pay only for data transfer ($0.01/GB cross-AZ, $0.02/GB cross-region in 2026). - Simple to set up. Request peering, accept, update route tables, done. - No latency added. Direct VPC-to-VPC routing. - Supports referencing security groups across the peering (within a single region). ### Cons - **Not transitive.** If VPC-A peers with VPC-B and VPC-B peers with VPC-C, VPC-A cannot reach VPC-C through VPC-B. Each pair needs its own peering. - **Quadratic scaling.** A full mesh of N VPCs needs N(N-1)/2 peerings. 10 VPCs = 45 peerings. 20 VPCs = 190 peerings. That's a lot of route tables to maintain. - 125 peering limit per VPC (with quota increase). For very dense organizations this becomes a hard cap. ## Transit Gateway: hub-and-spoke that scales Transit Gateway (TGW) is a managed router. You attach VPCs to it, configure routing, and traffic flows through the hub. ### Pros - **Transitive routing.** Any attached VPC can reach any other attached VPC. - **Linear scaling.** Adding a new VPC means one new attachment, not N new peerings. - Multiple route tables let you segment which VPCs can reach which others (e.g., prod and dev isolated even though attached to the same TGW). - Supports VPN and Direct Connect attachments, so on-premises networks fit the same topology. - Inter-region TGW peering for global mesh. ### Cons - **Fixed cost.** $0.05/hour ($36/month) per TGW, plus $0.05/hour per attachment ($36/month per attached VPC), plus $0.02/GB processed. - For 10 VPCs: $36 (TGW) + 10 × $36 (attachments) = $396/month base, before any data. - Slight added latency (~1-2 ms) for traffic going through the TGW versus direct peering. - Cannot reference security groups across attachments (must use CIDR-based rules). ## The breakeven analysis Setup time and operational cost matter, but raw AWS bills are easier to compute. For data transfer the cost is similar either way (TGW adds $0.02/GB processing on top of the underlying transfer). For the fixed costs: VPCs (full mesh)PeeringsPeering fixed costTGW fixed cost21$0$10833$0$144510$0$2161045$0$39620190$0$756501,225$0$1,836 Strictly on AWS bill, peering is always cheaper. **The reason TGW exists is operational complexity.** Maintaining 1,225 peerings is not feasible for human operators — every new VPC requires updating ~50 other VPCs' route tables. Mistakes in any of them cause silent connectivity failures. For most organizations, the breakeven is around **5-7 VPCs** where the operational burden of maintaining the peering mesh outweighs the TGW cost. ## The hybrid pattern (most common in practice) Production AWS organizations often use both: - **Transit Gateway** as the primary backbone for most VPCs. - **VPC peering** for specific high-traffic VPC pairs where TGW's per-GB processing cost matters. For example, suppose your shared services VPC needs to reach your application VPC at 50 TB/month. Through TGW that's $1,000/month in processing fees alone. A direct peering between those two VPCs is free (data transfer cost is the same either way). Hybrid setups can save substantial money for known-high-bandwidth flows. ## Route table segmentation with TGW One of TGW's killer features is multiple route tables. Use cases: - **Prod/dev isolation:** Prod VPCs use a route table that does not have routes to dev VPCs, and vice versa. - **Inspection VPCs:** Force all traffic to traverse a firewall VPC before reaching destination VPCs. - **Per-environment segments:** Each business unit's VPCs see only their own. This is the AWS-native equivalent of MPLS L3VPN-style segmentation, without needing actual MPLS. ## Common mistakes - **Using TGW for 2-3 VPCs.** Almost always overkill. Use peering until your mesh becomes painful. - **Using peering for 10+ VPCs.** The operational pain is real, even if the AWS bill is lower. Migrate to TGW. - **Forgetting TGW processing fees on cross-VPC traffic.** $0.02/GB adds up. Audit your top bandwidth pairs. - **CIDR overlaps in TGW attachments.** Like peering, TGW rejects overlapping VPC CIDRs. See our multi-cloud CIDR planning article. - **Not using route tables for segmentation.** A single TGW with one route table is just a faster peering mesh. The segmentation features are the real value. ## Alternatives worth knowing about - **AWS Cloud WAN** — newer service, manages multi-region TGW topologies and on-prem connectivity from a single policy document. Worth evaluating for global deployments. - **VPC Lattice** — service-level connectivity (not VPC-level), better for microservice-to-microservice traffic across VPCs. - **PrivateLink** — for service exposure rather than full mesh routing. Often better when only specific services need to be reachable across VPCs. ## Key takeaways - **VPC peering** is free, point-to-point, and scales quadratically. Good for 2-5 VPCs. - **Transit Gateway** costs ~$36/month + per-attachment + per-GB processing, but scales linearly with route table segmentation features. - Breakeven point operationally is around **5-7 VPCs**. - Hybrid (TGW backbone + peering for high-bandwidth pairs) is the cost-optimized pattern. - Always non-overlapping VPC CIDRs — both peering and TGW reject overlaps. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Cloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min readCloud #### NAT Gateway vs NAT Instance vs VPC Endpoints Three different ways to give private subnet workloads access to outside services in AWS. Cost, throughput, and operational tradeoffs explain... 9 min readCloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min readCloud #### Public vs Private Subnets: When to Use Each What actually makes an AWS subnet "public" or "private", and how to design tiers so workloads have the right combination of internet access ... 8 min read --- # IPv6 Prefix Delegation: /48, /56, /60, /64 Explained 9 min read·Published May 26, 2026·By cidrcalculator.net team If you order business internet from a competent ISP, they will hand you a **/48 IPv6 prefix**. That gives you 65,536 LAN segments. If you order residential internet, you might get a /56 (256 LANs), a /60 (16 LANs), or — if the ISP is being stingy — just a /64 (which is one LAN, and breaks internal subnetting entirely). This article explains how IPv6 prefix delegation works, what each size means for your network design, and why "just give us a /64" is the wrong answer regardless of how small your network feels. ## The IPv6 hierarchy you need to know PrefixLANs (/64s)Typical use/324.3 billionISP allocation/4865,536Business site, RFC 6177 recommended minimum/56256Generous residential/6016Typical residential/641Single LAN segment An ISP gets a /32 from the regional internet registry (4 billion /64 LANs, enough for millions of customers). They subdivide it: /48 for businesses, /56 or /60 for residential. Every customer ends up with multiple /64 LANs out of their allocation. ## Why /64 is never enough Engineers coming from IPv4 sometimes think "I only have one LAN at home, so why do I need more than one /64?" The answer is multifaceted: ### Guest networks If you want a separate Wi-Fi for guests/IoT/kids isolated from your main LAN, each isolated network is a separate /64. With only one /64, you cannot subnet at all. ### VLANs Every VLAN is its own broadcast domain, which in IPv6 terms means its own /64. Office networks routinely have 5-20 VLANs. ### VPN clients If you run a VPN server (WireGuard, OpenVPN), connected clients need their own /64 for proper routing back home. With only one /64 you have to NAT or proxy. ### Site-to-site routing Two offices connecting over IPv6 each need their own /64 LANs plus a transit /64. Three sites = at least 6 /64s. ### Future proofing IPv6 is going to be the dominant protocol for the next 50+ years. Get the right allocation now or you will be re-numbering later. ## DHCPv6 prefix delegation (DHCPv6-PD) The standard mechanism by which an ISP hands a prefix to a customer is **DHCPv6 Prefix Delegation**, defined in RFC 3633. The process: - Your router boots up and sends a DHCPv6 Solicit message with IA_PD (Identity Association for Prefix Delegation). - The ISP's DHCPv6 server responds with a prefix allocation (e.g., `2001:db8:abcd::/56`). - Your router automatically subdivides this into /64s for each connected LAN segment. - Internal devices receive their /64 prefix via Router Advertisement and configure themselves via SLAAC. The whole process takes seconds and requires no manual configuration. The customer just sees their devices come online with IPv6 addresses. ## What good routers do automatically Modern consumer and SMB routers that support DHCPv6-PD do this without configuration: - Request a prefix from the ISP (preferring /48, accepting /56 or /60). - Subdivide the prefix into /64s for each LAN segment (main LAN, guest, IoT, VLAN-N). - Announce each /64 via Router Advertisement on the appropriate interface. - Allow hosts to self-configure via SLAAC. - Update firewall rules to allow IPv6 traffic with appropriate restrictions. Examples of routers that handle this correctly: anything running OpenWrt, OPNsense, pfSense, MikroTik RouterOS, Cisco IOS XE, Ubiquiti UniFi. Many ISP-provided modems do *not* support DHCPv6-PD properly — request a /48 in bridge mode or replace the modem. ## How to allocate inside your /48 With a /48, you have 65,536 /64 LANs. A reasonable subdivision uses the 16 bits between the /48 and /64 as a structured hierarchy: ``` 2001:db8:abcd::/48 Your allocation +-- 2001:db8:abcd:0000::/52 Headquarters (16 /56s) | +-- 2001:db8:abcd:0000::/56 HQ building 1 (256 /64s) | | +-- 2001:db8:abcd:0000::/64 Floor 1 default LAN | | +-- 2001:db8:abcd:0001::/64 Floor 1 VLAN guest | | +-- ... up to 0x00ff | +-- 2001:db8:abcd:0100::/56 HQ building 2 +-- 2001:db8:abcd:1000::/52 Branch offices (16 sites) +-- 2001:db8:abcd:2000::/52 Data center +-- 2001:db8:abcd:f000::/52 Reserved ``` Structured allocation makes routing tables shorter (summary routes), troubleshooting easier (you can identify a site from its prefix), and growth predictable. ## What to do if your ISP only offers /64 Some residential ISPs hand out /64s with no PD support. This is technically a deployment, but it severely limits what you can do internally. Options: - **Push back.** RFC 6177 says ISPs should give residential customers at least /56 and businesses at least /48. Cite it. Some ISPs change practice when customers ask. - **Use a Hurricane Electric tunnel.** Free /48 over an IPv6-in-IPv4 tunnel from tunnelbroker.net. Adds latency, but gives you a proper allocation. - **Use ULA (fd00::/8) internally.** Combine with the single /64 from your ISP for external traffic. You lose end-to-end addressing for the multiple LANs, but can keep IPv6 working internally. See our IPv6 fundamentals article for ULA details. - **Switch ISP.** The strongest signal you can send. ## Cloud IPv6 prefix patterns Cloud providers handle IPv6 prefix sizing differently from on-premises: ProviderVPC IPv6 prefixSubnet IPv6 prefixAWS/56/64 (one per subnet)Azure/56 (default), expandable to /48/64GCP/48 (custom mode)/64 AWS hands you a /56 from their allocation; you cannot bring your own. Each AWS subnet uses a /64 from that /56, giving you up to 256 subnets per VPC. ## Common prefix delegation mistakes - **Subnetting a /64 into smaller pieces.** Breaks SLAAC. Every LAN must be exactly /64. If you need more LANs, get a shorter prefix. - **Hardcoding the ISP-assigned prefix.** ISPs may rotate prefixes (especially residential). Use prefix delegation so your router adapts. - **Forgetting to firewall the delegated prefix.** By default, devices behind your router get publicly routable IPv6. Set up stateful firewall rules to block unsolicited inbound — most routers do this automatically. - **Mixing /64 RA prefixes from your ISP and ULA.** Sometimes works, sometimes breaks. Pick one source of truth per LAN; use SLAAC for global addresses and explicit static config for ULA if needed. ## Key takeaways - Business ISPs should give you a **/48 (65,536 LANs)**. Residential should be **/56 (256 LANs)** or at least /60 (16 LANs). - A single /64 is one LAN. You cannot subnet it; you cannot run multiple isolated networks. - Prefix delegation works automatically with **DHCPv6-PD**. Modern routers handle the entire process. - Cloud providers hand out /56 (AWS, Azure) or /48 (GCP) per VPC; each subnet uses a /64 from that. - If your ISP only gives /64, push back, use a Hurricane Electric tunnel, or change ISPs. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles IPv6 #### IPv6 for IPv4 Engineers: The Only Guide You Need If you understand IPv4 subnetting, IPv6 is actually simpler. This guide covers /64 LAN rule, prefix delegation, ULA vs GUA, link-local addre... 14 min readFundamentals #### RFC 1918 vs RFC 6598: When to Use 100.64.0.0/10 CGNAT (100.64.0.0/10) is a 4-million-address range that is not classed as RFC 1918 private, but is filtered at internet edges. Here is when ... 7 min readFundamentals #### The Complete Subnet Mask Cheat Sheet (/0 to /32 with examples) Full reference table of IPv4 subnet masks from /0 to /32: prefix, dotted decimal, hex, host count, AWS usable, and common use cases. Printab... 7 min readSecurity #### Bogons, CGNAT, and Other IP Ranges That Will Ruin Your Day Some IP ranges should never appear on the internet. Bogons, CGNAT, link-local, multicast, TEST-NET — these are the non-obvious blocks that n... 9 min read --- # /30 vs /31 for Point-to-Point Links: When and Why 6 min read·Published May 26, 2026·By cidrcalculator.net team A point-to-point (P2P) link only needs two usable IP addresses — one on each end. The traditional way to allocate this is a `/30` subnet (4 total addresses, 2 usable, 2 wasted on network and broadcast). Since 2000, RFC 3021 has provided an alternative: **use a `/31` instead**, which has 2 total addresses and 2 usable, with zero waste. This article walks through when to use /30 vs /31, the platforms that support each, the address savings at scale, and the operational gotchas. ## The math: /30 vs /31 PrefixTotal addressesUsableWasteSpec/30422 (50%)RFC 1812/31220RFC 3021 A /30 at `10.0.0.0/30` has: - `10.0.0.0` — network address (not usable) - `10.0.0.1` — usable (one end of the link) - `10.0.0.2` — usable (other end) - `10.0.0.3` — broadcast (not usable) A /31 at `10.0.0.0/31` has: - `10.0.0.0` — usable (one end) - `10.0.0.1` — usable (other end) RFC 3021 explicitly states that point-to-point links do not need a network address (there's only one network) or a broadcast address (broadcast on a P2P link is the same as unicast to the other end). So both addresses become assignable. ## Why this matters at scale For a single P2P link, the difference is 2 addresses — trivial. For service provider networks with hundreds or thousands of P2P links, the difference is real money: - 500 P2P links with /30: 2,000 addresses consumed, 1,000 wasted. - 500 P2P links with /31: 1,000 addresses consumed, 0 wasted. For IPv4-constrained operators (small ISPs, MPLS backbones with /22 of public space), saving 1,000+ addresses by switching to /31 is meaningful. It also makes documentation neater — every link is exactly 2 addresses, no exceptions. ## Platform support Platform/31 supportNotesCisco IOS / IOS XE / IOS XRYesSince IOS 12.2(2)TJuniper JunosYesNativeArista EOSYesNativeLinuxYesNativeOPNsense / pfSense / FreeBSDYesNativeWindows ServerYes (recent versions)Some edge cases historicallyEmbedded / IoTMixedAlways verify before deployingSome older equipmentNoLimited to /30 minimum If you are on a modern network, /31 is universally supported. Vendor docs explicitly recommend /31 for P2P links in IOS XE and Junos configs. ## When to use /30 instead - **Mixed-equipment environments** where any device on the link might not support /31. The cost of having one mystery outage is much higher than wasting 2 addresses per link. - **Legacy network designs** being modified incrementally. Consistency with existing /30 allocations may be more important than reclaiming addresses. - **BGP peering with vendors** who specifically request a /30 in their setup docs. Some ISPs and exchanges still standardize on /30. ## When to use /31 - **Greenfield service provider** or DC fabric designs. The address savings compound. - **OSPF / IS-IS / BGP between known-good routers** (Cisco, Juniper, Arista, modern Linux). - **SDN and cloud-router architectures** where everything is software-defined and /31 is just a config choice. - **Any new MPLS or BGP backbone** where the team controls both ends of every link. ## How to configure /31 ### Cisco IOS XE ``` interface GigabitEthernet0/0/0 description Link to PE2 ip address 10.255.1.0 255.255.255.254 ``` ### Juniper Junos ``` set interfaces ge-0/0/0 unit 0 family inet address 10.255.1.0/31 ``` ### Arista EOS ``` interface Ethernet1 description Link to spine-1 no switchport ip address 10.255.1.0/31 ``` ### Linux iproute2 ``` ip addr add 10.255.1.0/31 dev eth1 ``` ## Allocating /31s from a parent If you have `10.255.0.0/22` for P2P link addressing, you can carve it into 512 /31 links. Each link uses 2 consecutive addresses, with the lower address typically going to the "lower-numbered" side of the link (e.g., the spine). ``` 10.255.0.0/31 Spine 1 <-> Leaf 1 (spine .0, leaf .1) 10.255.0.2/31 Spine 1 <-> Leaf 2 (spine .2, leaf .3) 10.255.0.4/31 Spine 1 <-> Leaf 3 ... 10.255.0.62/31 Spine 1 <-> Leaf 32 10.255.1.0/31 Spine 2 <-> Leaf 1 ... ``` This convention makes it easy to identify which spine/leaf a given address belongs to. ## IPv6 P2P: /127, not /126 The IPv6 equivalent of /31 for P2P is **/127**, per RFC 6164. Same idea: 2 addresses on the link, both usable, no network or broadcast. This is the recommended IPv6 P2P size — even though IPv6 has so much address space that wasting addresses on /126s would not matter for capacity, /127 prevents NDP exhaustion attacks where attackers flood the link with neighbor discovery for random addresses. ## Common /31 mistakes - **Using /31 on a multi-access link.** /31 is ONLY for true point-to-point. Two-host Ethernet between a switch and a router is fine. A switch with three hosts attached is not P2P; use /29 or larger. - **Mixing /30 and /31 in the same OSPF area.** Works but creates inconsistent documentation. Pick one convention per network. - **Routing the /31's "network" or "broadcast" address.** They do not exist in /31. Some legacy tools and scripts assume they do. ## Key takeaways - **/31** on P2P links is universally supported on modern equipment and saves 2 addresses per link. - **/30** still works and may be needed for legacy equipment or some vendor BGP peering requirements. - For IPv6 P2P, use **/127** per RFC 6164. - Use /31 by default for greenfield service-provider and DC fabric designs; use /30 only when you have a specific compatibility reason. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Fundamentals #### The Complete Subnet Mask Cheat Sheet (/0 to /32 with examples) Full reference table of IPv4 subnet masks from /0 to /32: prefix, dotted decimal, hex, host count, AWS usable, and common use cases. Printab... 7 min readFundamentals #### How to Calculate Subnets by Hand (the magic number method) The magic number method lets you find any subnet, broadcast address, or host count in under 30 seconds without binary math. Worked examples ... 9 min readFundamentals #### VLSM Explained: Variable-Length Subnet Masking from Scratch VLSM lets you allocate different-sized subnets from one parent network without wasting addresses. This worked example shows the largest-firs... 10 min readCareer #### The CCNA Subnetting Questions That Trip People Up If you are studying for the CCNA, here are the eight subnetting question patterns that consistently cause failure. Each one is solvable in 3... 8 min read --- # BGP and CIDR: How the Internet Routes Your Packets 10 min read·Published May 26, 2026·By cidrcalculator.net team Border Gateway Protocol is the routing protocol that holds the global internet together. Every routing decision between Autonomous Systems — every time a packet leaves your ISP for someone else's network — involves BGP. And the unit BGP uses to describe destinations is the CIDR prefix. This article explains how BGP and CIDR work together: what an Autonomous System is, how prefixes are announced, how routers pick between competing routes, and why longest prefix match means "more specific wins." ## Autonomous Systems An **Autonomous System (AS)** is a network operated by a single organization with consistent routing policy. The internet is a graph of ~120,000 ASes connected to each other. Each one has a number: - 2-byte ASN range: 1–65,535 (the original allocation) - 4-byte ASN range: 65,536–4,294,967,295 (since 2007) - Private ASNs: 64,512–65,534 (2-byte) and 4,200,000,000–4,294,967,294 (4-byte) Examples: Google is AS15169. Cloudflare is AS13335. Comcast is AS7922. Your own organization probably has private ASNs internally (e.g., for separating data center routing domains) and may have a public ASN for internet peering. ## What BGP carries: prefix + path Each BGP route announcement consists of: - **A CIDR prefix**: e.g., `8.8.8.0/24`, `2606:4700::/32` - **An AS path**: the sequence of ASes the route passed through, e.g., `[AS1234, AS5678, AS15169]` - **Attributes**: next hop, local preference, MED, community values, etc. When AS A announces a prefix to AS B, B prepends A's ASN to the path before sharing the route further. This builds up the visible AS path for each prefix. A typical full BGP table in 2026 has roughly **1 million IPv4 prefixes and 200,000 IPv6 prefixes**. Every internet-edge router holds this entire table, which is why edge routers need substantial memory. ## Longest prefix match When a router needs to forward a packet, it looks up the destination IP in its routing table and selects the **longest matching prefix**. This is the fundamental forwarding rule of CIDR. Example. Suppose a router knows about these prefixes: ``` 0.0.0.0/0 via ISP-A (default route, matches everything) 10.0.0.0/8 via Hub (RFC1918 internal) 10.0.1.0/24 via Office-VPN 10.0.1.128/26 via Lab-Switch ``` A packet destined for `10.0.1.150` matches all four prefixes. Longest wins: the router sends it to Lab-Switch via the /26 route. This is how a small organization can announce a /25 of their address space to a specific upstream while still having a default route handle everything else. The /25 takes precedence over the default. ## Why prefix length matters in DDoS mitigation DDoS attacks often target a specific IP or a small subnet. The standard mitigation: **announce a more specific prefix** that redirects the targeted range to a scrubbing center. If you normally announce `198.51.100.0/22` and the attacker targets `198.51.100.42`, you can announce `198.51.100.0/24` from your scrubbing provider's AS. Every router on the internet now sends traffic for that /24 to the scrubber (longest match wins), while traffic for the rest of your /22 still flows normally. This is why BGP communities like "blackhole" (RFC 7999) and the existence of RTBH (Remote Triggered Black Hole) routing are based on longest-prefix-match: you announce a more specific prefix with a special community telling neighbors to drop the traffic. ## How an AS chooses between competing routes If a router learns the same prefix from multiple BGP neighbors (which is common for popular destinations), it has to pick one. The simplified decision order: - Highest `LOCAL_PREF` wins. (Set by the operator's policy. "Prefer paid transit over peering.") - Shortest AS path wins. (Fewer hops.) - Lowest origin code wins. (IGP < EGP < incomplete.) - Lowest MED wins. (Multi-Exit Discriminator. Hint from the announcing AS about which entry point to prefer.) - eBGP routes preferred over iBGP. - Lowest IGP cost to next hop. - Lowest router ID (tiebreaker). In practice, steps 1 and 2 decide most cases. `LOCAL_PREF` is the policy lever operators use to express "send traffic this way." ## RPKI: validating that an AS owns its prefix For decades, BGP had no built-in way to verify that an AS legitimately owns a prefix it announces. A malicious or compromised AS could announce someone else's prefix and hijack their traffic. There have been several famous incidents. **RPKI (Resource Public Key Infrastructure)** fixes this. Address owners cryptographically sign records mapping their prefixes to their authorized ASNs (these signed records are called Route Origin Authorizations, ROAs). Routers running RPKI validation drop announcements that contradict published ROAs. Adoption is ~50% of internet routes as of 2026. If you operate a public BGP AS, publishing ROAs for your prefixes is a no-brainer — it prevents hijacks of your space with almost no operational cost. ARIN's RPKI page walks through the process for North American operators. ## Prefix aggregation and the /24 floor One way to reduce the global BGP table size is to aggregate adjacent prefixes. If you have `10.0.0.0/24` and `10.0.1.0/24`, you can announce `10.0.0.0/23` to your upstreams and they will receive one route instead of two. In practice, most ISPs do not accept announcements more specific than `/24` for IPv4 or `/48` for IPv6. Announcements of `/25` through `/32` are typically dropped by tier-1 transit providers to keep the global table from exploding. So if you want to be globally routable, the smallest you can announce is `/24` (256 addresses). ## The internet's prefix accounting Current global BGP table counts (approximate, 2026): - IPv4 prefixes: ~1,000,000 - IPv6 prefixes: ~200,000 - Active ASNs: ~80,000 - Median AS path length: 4 hops You can browse current statistics at the CIDR Report or Hurricane Electric's BGP toolkit. ## Implications for cloud architecture - **Bringing your own IP space to AWS / Azure** requires owning a /24 (the minimum that cloud providers will announce on your behalf), having a Letter of Authorization, and publishing ROAs for it. - **Anycast services** (Cloudflare, AWS Global Accelerator, Cloudflare Tunnels, modern DNS providers) announce the same prefix from multiple physical sites. BGP's longest-prefix-match plus shortest-AS-path naturally directs each user to their nearest endpoint. - **Internal MPLS / BGP networks** use BGP for site-to-site routing inside an organization. Same rules, smaller scale. ## Key takeaways - BGP carries **CIDR prefixes + AS paths** between Autonomous Systems. - Routers forward packets using **longest prefix match**. More specific routes always win over less specific ones. - The internet has ~120k ASes, ~1M IPv4 prefixes, ~200k IPv6 prefixes. - BGP's path selection prefers **highest LOCAL_PREF, then shortest AS path** (most of the time). - **RPKI** cryptographically validates which AS owns each prefix — a critical defense against BGP hijacks. - The smallest globally-routable prefix is **/24 (IPv4) or /48 (IPv6)** — anything smaller is typically filtered. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Security #### Bogons, CGNAT, and Other IP Ranges That Will Ruin Your Day Some IP ranges should never appear on the internet. Bogons, CGNAT, link-local, multicast, TEST-NET — these are the non-obvious blocks that n... 9 min readCloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min readCloud #### AWS Transit Gateway vs VPC Peering: Cost, Complexity, Scale VPC peering is point-to-point and free. Transit Gateway is hub-and-spoke and costs $36+/month. Here is when each is the right choice and the... 9 min readFundamentals #### RFC 1918 vs RFC 6598: When to Use 100.64.0.0/10 CGNAT (100.64.0.0/10) is a 4-million-address range that is not classed as RFC 1918 private, but is filtered at internet edges. Here is when ... 7 min read --- # IPAM for Small Teams: Lightweight Alternatives to BlueCat & Infoblox 9 min read·Published May 26, 2026·By cidrcalculator.net team IPAM (IP Address Management) is the discipline of tracking which IP addresses and subnets are allocated to which workloads. Enterprise IPAM platforms like BlueCat, Infoblox, and EfficientIP combine DNS, DHCP, and IPAM in one product and start at five figures per year. For most teams under a few hundred engineers, you do not need any of that. This article surveys lightweight IPAM options that work for small to mid-sized teams — from a spreadsheet to NetBox to phpIPAM — and explains when each makes sense. If you want to try IPAM with zero setup, our IPAM-Lite tracker runs in your browser with no signup. ## The IPAM spectrum TierCostBest forSpreadsheet$01-10 engineers, ad-hoc trackingcidrcalculator.net IPAM-Lite$0Quick visualization, sharing a planphpIPAM$0 (self-hosted)10-50 engineersNetBox / NetBox Cloud$0 (self) / paid (SaaS)50-500 engineersBlueCat / Infoblox / EfficientIP$$$+500+ engineers, regulated industries You can grow up the stack as your team and complexity grow. The transitions between tiers are typically driven by specific pain points, not headcount alone. ## Tier 1: spreadsheet For the smallest teams, a shared Google Sheet or Notion database works: CIDRDescriptionVPCOwnerStatus10.0.0.0/20prod-app-tier-aprod-vpcplatformactive10.0.16.0/20prod-app-tier-bprod-vpcplatformactive10.0.32.0/24prod-dbprod-vpcdataactive Strengths: zero setup, anyone can edit, fits in everyone's existing workflow. Weaknesses: no validation (typos go uncorrected), no conflict detection (overlaps go undetected), no API (cannot integrate with Terraform), no history. When it breaks: when you have more than ~50 allocations, when multiple teams modify the same sheet, or when an audit asks "who allocated what when." ## Tier 2: cidrcalculator.net IPAM-Lite Our IPAM-Lite tracker sits between a spreadsheet and a real IPAM tool. Stores allocations in your browser's localStorage, detects overlaps automatically, integrates with our calculator and IaC export. Strengths: zero setup, free, conflict detection, web URL sharing of allocations. Weaknesses: per-browser storage (no team sync), no audit log persistence beyond the device. Good for small teams who want conflict detection without standing up infrastructure. Use it interactively while planning, then export to a more durable format. ## Tier 3: phpIPAM phpIPAM is a free open-source IPAM with a 15-year history. PHP-based web app, MySQL backend, runs in a single VM or Docker container. Features: - Hierarchical sections (group VPCs by environment) - Subnet visualization (tree view of nested CIDRs) - Per-IP records (which device has 10.0.0.42) - REST API - Active Directory integration - Simple SNMP discovery Strengths: mature, free, low resource footprint. Weaknesses: PHP/MySQL stack is dated, the UI feels old, and the API is REST but not OpenAPI-documented. Good for teams who want a real IPAM but cannot justify NetBox's complexity. Setup time: ~1 hour for a Docker deploy. ## Tier 4: NetBox NetBox is the dominant open-source IPAM/DCIM in 2026. Started at DigitalOcean, now an independent project with strong commercial backing (NetBox Labs). Python/Django stack, PostgreSQL backend. What NetBox handles: - IPAM (subnets, IP addresses, VRFs) - DCIM (racks, devices, cables, power) - Circuits and providers - VLANs - Tenancy (multi-tenant isolation) - REST and GraphQL API - Webhooks for downstream automation - Custom fields, change logging, journal Strengths: feature-complete, well-documented, large community, integrates with Ansible/Terraform/Salt/Nornir/etc. Weaknesses: not lightweight — running it requires PostgreSQL, Redis, and at least 2 GB of RAM. The "source of truth" pattern requires discipline to keep accurate. NetBox Cloud is the hosted SaaS version, starting around $250/month. Avoids the operational burden of running it yourself. Good for teams of 50+ engineers, or anyone who also needs DCIM, or anyone integrating with Ansible/Terraform via the NetBox provider. ## Tier 5: enterprise IPAM BlueCat, Infoblox, EfficientIP, Men & Mice, Solarwinds IPAM. These products combine DNS, DHCP, and IPAM in one platform, with regulated-industry features like HSM integration, audit certification (PCI, HIPAA, SOX), 24/7 support, and on-prem appliances. Costs are not publicly advertised but start in the low five figures per year for small deployments and scale to seven figures for global enterprises. When it's worth it: - You need integrated DNS and DHCP managed centrally across hundreds of sites - You have regulatory requirements that demand auditable IPAM - You have 500+ engineers and dozens of network teams making allocations - You operate in industries (banking, telecom, government) where the vendor relationship and support are required Most teams under 500 engineers do not need this tier. The free options scale further than people expect. ## Cloud-native IPAM offerings The major clouds have native IPAM offerings: - **AWS VPC IPAM** — manages CIDR allocations across accounts and regions. Strongly recommended if you're AWS-heavy. Free for in-region tracking; pay only for cross-region/cross-account features. - **Azure Virtual Network Manager** — similar concept for Azure environments. Newer. - **GCP Hub-spoke / Shared VPC** — not a traditional IPAM but provides centralized network management. For organizations primarily in one cloud, the cloud's native IPAM is often the simplest starting point. ## What to track in IPAM At minimum, every IPAM should record: - **CIDR / prefix** - **Purpose** (what the subnet is used for) - **Location** (region, AZ, VPC, on-prem site) - **Owner** (team responsible) - **Status** (planned, active, retired) - **Date allocated** More mature IPAMs add per-IP tracking, DNS integration, change history, and approval workflows. Start small and grow as needs become clear. ## The "source of truth" discipline The hardest part of IPAM is not the tool — it is the discipline to keep it accurate. An IPAM that's 70% accurate is worse than no IPAM, because people stop trusting it and start "verifying" by checking the actual network. Practices that work: - Make IPAM part of the provisioning workflow (no subnet gets created without an IPAM entry) - Automate verification (cron jobs that compare IPAM to actual cloud state, flag discrepancies) - Assign clear ownership for the IPAM itself (someone whose job includes keeping it current) - Periodic audits (quarterly review of suspicious entries) ## Key takeaways - **Spreadsheet** works for 1-10 engineers, but breaks at 50+ allocations. - **cidrcalculator.net IPAM-Lite** for browser-local quick tracking with conflict detection. - **phpIPAM** for a real IPAM with low setup cost. - **NetBox** for serious teams that also need DCIM and API integration. - **Cloud-native IPAM** (AWS VPC IPAM, etc.) for single-cloud organizations. - Enterprise IPAM platforms (BlueCat, Infoblox) are only worth it for 500+ engineer organizations with regulatory needs. - Tool selection matters less than the discipline to keep the IPAM accurate. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Cloud #### Multi-Cloud VPC Peering: Avoiding the CIDR Overlap Trap The single most common multi-cloud mistake is overlapping CIDRs across AWS, Azure, and GCP. Here is a tested allocation pattern that scales ... 11 min readSecurity #### Troubleshooting Overlapping CIDR Blocks: Detection and Resolution Two VPCs need to peer but CIDRs overlap. A new acquisition uses your IP space. Here is the playbook for detecting, isolating, and resolving ... 10 min readDevOps #### Generating Terraform from a Subnet Design Going from a whiteboard subnet plan to production Terraform code without copy-paste errors. Patterns for modular VPC design, AWS provider be... 10 min readCloud #### Why AWS Reserves 5 IPs Per Subnet (and how to plan around it) AWS reserves 5 IP addresses in every VPC subnet. Learn which addresses are reserved, why the minimum subnet size is /28, and how to plan VPC... 8 min read --- # The CCNA Subnetting Questions That Trip People Up 8 min read·Published May 26, 2026·By cidrcalculator.net team The CCNA exam (200-301) gives you about 90 seconds per question and roughly 8-12 subnetting questions per exam. If you have to do long-form binary arithmetic for each one, you will run out of time. The good news: every CCNA subnetting question fits one of about eight patterns, and each pattern has a 30-second mental solution. This article walks through all eight, with the shortest method for each. If you commit these patterns to muscle memory, subnetting questions become free points on the exam. ## The two foundations you need Memorize these two things and the rest follows. ### 1. Powers of 2 up to 256 n2^nn2^n12532246643871284168256 You will use these to compute subnet sizes, host counts, and address counts. Burn them into memory. ### 2. The magic number method The "magic number" is the increment between consecutive subnets in the interesting octet. To find it: - Identify the **interesting octet** — the one where the mask transitions from 255 to a smaller value. - Compute the magic number: **256 − mask value in that octet**. - Subnets begin at multiples of the magic number in that octet. Examples: - `/27` = mask `255.255.255.224`. Interesting octet is the 4th, magic number = 256 − 224 = 32. Subnets at .0, .32, .64, .96, .128, .160, .192, .224. - `/20` = mask `255.255.240.0`. Interesting octet is the 3rd, magic number = 256 − 240 = 16. Subnets at .0, .16, .32, .48... - `/22` = mask `255.255.252.0`. Interesting octet is the 3rd, magic number = 256 − 252 = 4. Subnets at .0, .4, .8, .12... ## Pattern 1: "What is the subnet of host X?" **Example:** What subnet does host `192.168.1.130` with mask `255.255.255.192` belong to? **Method:** Find the magic number (256 − 192 = 64). Find the largest multiple of 64 that is ≤ 130 (it's 128). The subnet is `192.168.1.128/26`. **Why this works:** Subnets start at multiples of the magic number. The host belongs to whichever subnet has the largest starting address less than or equal to the host's address. ## Pattern 2: "What is the broadcast address of host X?" **Example:** What is the broadcast address for host `10.0.5.42/22`? **Method:** First find the subnet using Pattern 1. The mask /22 has magic number 4 in the third octet. Largest multiple of 4 ≤ 5 is 4. Subnet is `10.0.4.0/22`. Add (magic number − 1) to that octet and 255 to all the following octets: broadcast is `10.0.7.255`. ## Pattern 3: "How many usable hosts in /X?" **Example:** How many usable hosts in a `/26`? **Method:** Usable = 2^(32−prefix) − 2. For /26: 2^6 − 2 = 64 − 2 = 62. **Exception:** /31 has 2 usable (RFC 3021). /32 has 1 (the address itself). Common answers to memorize: PrefixUsable hosts/302/296/2814/2730/2662/25126/24254/23510/221,022 ## Pattern 4: "What prefix gives me N hosts?" **Example:** You need 50 hosts. What prefix? **Method:** Round 50 up to the next power of 2 (= 64). Add 2 for network/broadcast (66). Wait — we round up *before* adding, because 64 ≥ 50 only if we count the 2 reserved. The formula: - You need N hosts. - You need at least N + 2 total addresses (for network + broadcast). - Round up to next power of 2. - Prefix = 32 − log₂(that power). For N=50: 50 + 2 = 52 → next power of 2 is 64 → 2^6 = 64 → prefix = 32 − 6 = /26 (62 usable). Done. ## Pattern 5: "Convert subnet mask to prefix" **Example:** What is the prefix for mask `255.255.240.0`? **Method:** The mask has 16 "255" bits (first two octets) plus the leading 1s in the third octet. 240 in binary is `11110000` — four 1s. So prefix = 16 + 4 = /20. Memorize the third/fourth octet values: Octet valueLeading 1s0012811922224324042485252625472558 ## Pattern 6: "Which addresses are valid hosts?" **Example:** Which of these is a valid host on `172.16.32.0/20`? - A) 172.16.32.0 - B) 172.16.47.255 - C) 172.16.48.0 - D) 172.16.42.100 **Method:** /20 has magic number 16 in the third octet. Subnet is 32-47 in the third octet. Network = 172.16.32.0, broadcast = 172.16.47.255. So A is network, B is broadcast, C is outside the subnet, D is a valid host. Answer: D. ## Pattern 7: "How many subnets in a /X if I borrow N bits?" **Example:** If you have a /24 and subnet it into /27s, how many subnets do you get? **Method:** Borrowed bits = 27 − 24 = 3. Subnet count = 2^3 = 8. Each /27 has 30 usable hosts (Pattern 3). 8 subnets × 30 hosts = 240 total addressable, vs 254 in the unsubnetted /24. The "loss" of 14 addresses is the subnetting tax: 7 extra subnets times 2 reserved addresses each. ## Pattern 8: VLSM allocation **Example:** Given `10.0.0.0/24`, allocate subnets for groups of 60, 30, 14, and 6 hosts. **Method:** Always allocate largest first. - 60 hosts → /26 → starts at 10.0.0.0, covers .0–.63 - 30 hosts → /27 → starts at 10.0.0.64, covers .64–.95 - 14 hosts → /28 → starts at 10.0.0.96, covers .96–.111 - 6 hosts → /29 → starts at 10.0.0.112, covers .112–.119 - Remaining: 10.0.0.120 to 10.0.0.255 (136 addresses) free for future See our full VLSM article for more worked examples and the gotchas around alignment. ## Practice strategy for the exam - Drill flashcards of the prefix-to-hosts table and the octet-to-bits table. These should be automatic recall, not calculation. - Practice the magic number method until you can do it without writing anything down. - For VLSM questions, always allocate largest first. Always. - If the question gives you a host address and asks for the subnet, do not try to convert to binary. Use the magic number method. - Use our Practice Quiz to drill these patterns — it generates questions of every type and tracks your streak. ## Key takeaways - Memorize **powers of 2 up to 256** and the mask-to-bits conversion table. These are the foundation. - The **magic number method (256 − mask)** answers most exam questions in under 30 seconds. - The 8 question patterns above cover almost every subnetting question on the CCNA. Drill them until they are automatic. - Always allocate largest-first for VLSM. ### Plan your subnets the easy way Skip the math. Our free tools handle CIDR calculations, VLSM allocation, cloud reserved IPs, and IaC export — all in your browser, no signup. CalculatorVLSM DesignerCloud modeIaC Export ## Related articles Fundamentals #### How to Calculate Subnets by Hand (the magic number method) The magic number method lets you find any subnet, broadcast address, or host count in under 30 seconds without binary math. Worked examples ... 9 min readFundamentals #### The Complete Subnet Mask Cheat Sheet (/0 to /32 with examples) Full reference table of IPv4 subnet masks from /0 to /32: prefix, dotted decimal, hex, host count, AWS usable, and common use cases. Printab... 7 min readFundamentals #### VLSM Explained: Variable-Length Subnet Masking from Scratch VLSM lets you allocate different-sized subnets from one parent network without wasting addresses. This worked example shows the largest-firs... 10 min readFundamentals #### Subnet Mask vs Wildcard Mask: ACLs, OSPF, and Quick Conversion Cisco ACLs use wildcard masks, the inverse of subnet masks. Here is exactly what wildcard masks mean, how to convert, and when non-contiguou... 7 min read ---