Air Gap Cloud
You build an air gap cloud by removing all public network paths from your virtual networks. You then route all traffic through private links and strict network rules. Many teams start by locking down routes and setting up broad admin roles for maintenance. When those roles are too broad, a single mistake inside the isolated network can still delete data or expose records. How an air gap cloud works in practice In a standard cloud setup, virtual machines and databases can reach public endpoint
Compliance Gap Analysis: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build an air gap cloud by removing all public network paths from your virtual networks. You then route all traffic through private links and strict network rules. Many teams start by locking down routes and setting up broad admin roles for maintenance. When those roles are too broad, a single mistake inside the isolated network can still delete data or expose records.
How an air gap cloud works in practice
In a standard cloud setup, virtual machines and databases can reach public endpoints over the web. To isolate the setup, you strip away internet gateways and public IP addresses from every subnet. You also block outbound traffic by default in your network firewall rules.
Workloads still need code updates, container images, and patches to run well. Teams solve this by placing local package mirrors and image stores inside the private network. Security teams vet every software package in a staging zone before moving it across the boundary.
Cloud services like storage buckets or secret stores also need private paths. You set up private endpoints so traffic stays on the cloud provider backbone. DNS servers inside the private zone resolve service names to local IP addresses instead of public ones.
Identity checks must also happen without calling out to a public login service. Teams run local directory servers or sync identity rules through dedicated hardware links. Admin teams log in from secure rooms or dedicated physical links that terminate inside the private network.
What network isolation solves and what it leaves open
Network isolation stops outside attackers from scanning your ports or stealing data over the public web. It also prevents rogue code from calling home to an external command server. For regulated workloads, this boundary proves that external networks cannot touch your private systems.
Still, a strict network boundary only controls how packets move between zones. Once an engineer or an automated script logs in, the network firewall steps aside. Cloud roles and network rules decide who can open a session, not what happens inside that session.
Compliance Gap Analysis: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Inside an isolated network, teams often share high-level database accounts or root keys to fix urgent bugs. It is hard to rotate keys or check individual commands when tools cannot reach external security platforms. If an approved user runs a bad query, the isolated database runs it right away.
In the same way, a valid script can read raw customer emails, phone numbers, or card numbers in clear text. Standard network logs only show that a connection happened between two internal IP addresses. They do not record the exact SQL query or shell command that ran during the session.
Managing day-two operations in isolated networks
Running an isolated setup over time takes careful planning around logs, patches, and human access. Every log file must go to an internal storage bucket so teams can review past events. Because storage fills up fast, you need automated rules to archive old logs to cold storage.
When a live system fails, responders cannot look up answers or pull fresh debug tools from the web. Your team must pre-load diagnostic tools onto internal hosts before an outage happens. You also need clear rules on who can approve emergency actions when the main team is offline.
Testing changes in a mock isolated network helps catch missing dependencies early. If an app tries to call a public API during startup, the test run will fail fast. Fixing these hidden web calls before deployment keeps your production boundary clean and working.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Can a public cloud really be air gapped?
A true physical air gap requires dedicated hardware with no shared wires. In a public cloud, you build a logical air gap by removing internet gateways, blocking public IPs, and using private links.
How do teams patch servers in an air gap cloud?
Teams scan and approve updates in a separate staging network first. They then copy the clean packages into an internal repo that isolated servers can read over private routes.
Why do isolated cloud networks still need command-level controls?
Network boundaries only block outside traffic. Once an insider or local service logs in, you still need controls to inspect queries, block destructive commands, and mask fields like card numbers or national IDs.