The latest articles on DEV Community by Amol Kamble (@ammyskamble). https://dev.to/ammyskamble https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4131648%2F3efe2845-aed3-4014-b695-60b4f17a5d7a.jpg https://dev.to/ammyskamble en Amol Kamble Fri, 18 Sep 2026 14:02:02 +0000 https://dev.to/ammyskamble/stop-sending-your-ip-schemas-to-remote-servers-why-i-built-a-100-client-side-subnet-calculator-2mej https://dev.to/ammyskamble/stop-sending-your-ip-schemas-to-remote-servers-why-i-built-a-100-client-side-subnet-calculator-2mej <p>As developers and cloud architects, we are constantly planning VPCs, slicing up subnets for Kubernetes, and trying to avoid IP overlap across multi-region deployments. And like most people, I used to just Google "subnet calculator" and use whatever popped up first.</p> <p>But I realized a massive security flaw in this workflow: <strong>most online subnet calculators process your inputs on their remote servers.</strong></p> <p>Whenever we type our internal IP schemas, CIDR blocks, or exact network topologies into these tools, we are essentially broadcasting our corporate network architecture to a third-party server. For a profession that obsesses over IAM roles, zero-trust networks, and private endpoints, this felt like a glaring blind spot.</p> <p>Network planning should be secure, fast, and entirely private. So, I built <a href="https://devsubnet.com/" rel="noopener noreferrer">DevSubnet</a>.</p> <h2> What is DevSubnet? </h2> <p><a href="https://devsubnet.com/" rel="noopener noreferrer">DevSubnet</a> is a free, 100% client-side IP subnet and CIDR calculator. There is zero server-side processing, no database logging your inputs, and no telemetry tracking your IP architectures. Everything executes locally in your browser via JavaScript.</p> <p>While building it, I also wanted to solve the real-world headaches I face when provisioning infrastructure, going beyond the basic RFC 1918 math.</p> <h3> Key Features Built for Modern DevOps: </h3> <ul> <li> <strong>Cloud Provider Offsets:</strong> Standard calculators assume you lose 2 IPs per subnet (Network and Broadcast). But if you deploy in the cloud, you know that AWS reserves 5 IPs, Azure reserves 5 IPs, and GCP reserves 4. DevSubnet automatically adjusts your usable host counts based on your selected cloud provider.</li> <li> <strong>Infrastructure as Code (IaC) Export:</strong> Once you have your CIDR blocks sliced correctly, you can instantly export configuration syntax for Terraform (<code>cidrsubnet()</code>), AWS CloudFormation, Azure Bicep, Ansible, and Linux <code>iproute2</code>.</li> <li> <strong>Interactive Visual Splitter:</strong> Slicing a <code>/16</code> into multiple <code>/24</code>s for different availability zones? The recursive visual splitter lets you build out your architecture tree visually.</li> <li> <strong>Kubernetes CNI Sizing:</strong> Quickly size Pod and Service CIDR blocks for Cilium, Calico, and AWS VPC CNI to prevent pod scheduling failures down the line.</li> </ul> <h2> Try It Out </h2> <p>You can use the tool completely free here: <a href="https://devsubnet.com/" rel="noopener noreferrer">DevSubnet.com</a></p> <p>Whether you are studying for a networking certification, writing Terraform modules, or architecting a multi-AZ cloud environment, I would love to hear your thoughts. </p> <p>What is your current workflow for planning IP blocks? Are there any specific IaC exports or cloud provider quirks you would like to see added? Drop your feedback in the comments!</p> showdev devops security aws