Airgap Cloud
You build an airgap cloud by blocking all public internet paths to your servers. You then route all traffic through private network links and strict firewall rules. Most teams start this setup by removing public IP addresses from every virtual machine. They also turn off internet routers inside their main cloud network. Yet teams still need a way to run updates and fix broken apps. To make work easier, admins often grant broad network roles to engineers. When roles are too broad, anyone inside t
Cloud: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build an airgap cloud by blocking all public internet paths to your servers. You then route all traffic through private network links and strict firewall rules. Most teams start this setup by removing public IP addresses from every virtual machine. They also turn off internet routers inside their main cloud network. Yet teams still need a way to run updates and fix broken apps. To make work easier, admins often grant broad network roles to engineers. When roles are too broad, anyone inside the network can reach every database.
How an airgap cloud setup works
An airgap cloud keeps your servers and data away from the open internet. First, you create a private network space inside your cloud account. You delete the default route that sends traffic out to the web. Next, you set up private links to reach cloud storage and key tools. These links keep your data inside the provider network at all times. Your packets never touch public routers or external lines.
Engineers still need a safe way to log in and do daily work. Teams usually build a private line from their office to the cloud network. Once on that line, a user logs in through an identity tool. The identity tool checks who the user is and assigns a cloud role. That role tells the cloud which servers or databases the user can reach. You also host your own code packages and app images inside the private space. Your servers pull updates from these internal stores instead of public web sites.
What native network isolation solves and what it misses
Native network isolation stops outside attackers from scanning your ports from the web. It also prevents stolen apps from sending your data to external servers. If a bad actor cannot reach your network, they cannot start an attack. Your cloud role setup also controls which team members can log in. This gives you a strong wall around your private servers and data stores.
Still, network walls and login roles only check who enters the network. They do not watch or control what a user does after logging in. Once a developer opens a database session, the network lets all traffic pass. A user with a valid role can run a command that drops a table. They can also run a big query that reads every row of user data by default. Network logs only show that packets moved between two private IP addresses. They do not record the exact query or command that the user ran. Also, native network rules do not mask sensitive fields in query results. If a table holds emails, phone numbers, or card numbers, the query returns them. Masking rewrites matched fields in results, which network firewalls cannot do.
Cloud: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing day two operations in isolated networks
Running a locked network gets harder when an app breaks at night. An engineer needs to check logs and run a quick fix right away. If your rules are too strict, the engineer cannot reach the broken server. To avoid delays, teams often leave wide internal ports open for admin roles. They also share static database keys among the whole on-call team. Shared keys make it impossible to see which person ran a bad command.
To keep the setup safe, you must control actions at the command level. You need to approve risky commands before they run on a production host. You also need clear logs that link every database query to one person. This control must work inside your private network without needing public web paths.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Can a public cloud really be airgapped?
You cannot pull the physical plug on a public cloud server. Instead, you build a logical gap by removing all public internet routes and IPs.
How do teams update software in an airgap cloud?
Teams check updates in a staging space first. Then they copy safe packages into a private store inside the isolated network.
Why are firewall rules not enough for internal security?
Firewalls only check IP addresses and ports when a connection starts. They cannot read database queries, block bad commands, or mask card numbers in results.