DMZ Subnet
A dmz subnet is a buffer zone between the public internet and your private network. You set it up by placing public servers behind outer and inner firewalls. Teams often start by routing all external web traffic into this isolated network segment. When firewall rules or server roles are too broad, attackers can reach internal data. A single wide rule can expose private databases to public web servers. How a dmz subnet works in practice The main goal of a dmz subnet is to keep private systems
Subnet: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A dmz subnet is a buffer zone between the public internet and your private network. You set it up by placing public servers behind outer and inner firewalls. Teams often start by routing all external web traffic into this isolated network segment. When firewall rules or server roles are too broad, attackers can reach internal data. A single wide rule can expose private databases to public web servers.
How a dmz subnet works in practice
The main goal of a dmz subnet is to keep private systems safe. Public apps like web servers and mail relays sit inside this perimeter zone. External users can reach these public hosts, but they cannot reach internal networks.
Teams build this layout using either a single firewall or two separate firewalls. In a dual firewall design, the outer firewall filters traffic from the internet. It only lets approved public requests enter the perimeter zone. The inner firewall sits between the perimeter zone and the private internal network. This inner wall blocks direct traffic from the internet to your private hosts.
In cloud networks, teams set up this pattern with public and private subnets. Public subnets hold load balancers and web servers that have public IP addresses. Private subnets hold backend databases and internal services with no public IP addresses. Route tables send internet traffic only to the public zone. Network access control lists and security groups restrict traffic flowing between the two zones. For example, a web server in the public zone can query a private database. Still, the database only accepts requests on one specific port from that exact server.
What network segmentation solves and what it misses
A perimeter subnet stops random internet scanners from touching your private backend servers. If an attacker breaks into a public web server, the inner firewall blocks them. They cannot scan the rest of the private network with ease. Network rules control which IP addresses and ports can talk to each other. This setup decides which host or user can open a network path.
Still, network rules cannot inspect what happens inside an approved session in flight. Once an engineer or app logs in through an open port, the firewall steps back. A firewall rule allows traffic on a database port, but it cannot read queries. It cannot tell the difference between a safe read and a table drop. It also cannot rewrite sensitive fields like emails or phone numbers in query results.
Subnet: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This gap creates big risks during daily operations and support work. Engineers need a way to reach private servers in order to fix bugs. Teams often open ports from the perimeter zone so engineers can log in. They also store shared database keys on servers that sit near the edge. If those keys leak, anyone on that host gets full database control. IP rules check where traffic comes from, not what commands a user runs. To stay safe, teams must check every command and query after login.
Common mistakes when managing perimeter rules
Over time, firewall rules grow messy as new apps and teams join. A team might open a temporary port for a quick test and forget it. Another team might grant a wide subnet range access to a backend database. When you rely only on IP addresses, one mistake breaks the whole barrier.
Static credentials stored inside the perimeter zone make this problem much worse. Web apps in the public zone often hold long-lived keys for private databases. If a bad actor steals those keys, the inner firewall will not stop them. The attacker just uses the allowed port and runs queries as the web app. Auditing also suffers because network logs only show IP addresses and byte counts. You see that a host sent data, but you do not see who ran what.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between a public subnet and a dmz subnet?
A public subnet is any network segment with a direct route to the internet. A dmz subnet adds strict inner firewall rules to block paths to private networks.
Should databases ever sit inside the perimeter network?
No, private databases should always stay inside an isolated internal subnet. Public servers in the perimeter zone should only reach them through strict, narrow rules.
Do cloud networks still need a perimeter zone?
Yes, cloud networks still need a clear split between public and private hosts. Teams use route tables and security groups to keep public traffic away from data.