Air-gapped Cloud
An air gapped cloud isolates your workloads from the public internet and outside networks. You build it by removing public routes and using private network paths for traffic. Teams set up this boundary to protect sensitive data from external threats. Still, once an engineer enters the private zone, broad roles often grant too much power. How an air gapped cloud works in practice In a standard cloud setup, servers reach the internet through public routers. An air gapped cloud removes those pub
Cloud: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An air gapped cloud isolates your workloads from the public internet and outside networks. You build it by removing public routes and using private network paths for traffic. Teams set up this boundary to protect sensitive data from external threats. Still, once an engineer enters the private zone, broad roles often grant too much power.
How an air gapped cloud works in practice
In a standard cloud setup, servers reach the internet through public routers. An air gapped cloud removes those public doorways from your virtual network. You drop all internet route rules and block public IP addresses on every machine. Servers inside this boundary can only talk to other machines in the same zone.
To keep apps running, you must bring every needed tool inside the wall. You host your own code repos, container registries, and package stores on private servers. When a server needs a software update, it pulls files from your local mirror. No packet ever leaves your private network to fetch code from the outside world.
Admins and developers still need a way to manage these isolated systems. Teams set up dedicated private links or require staff to work from secure rooms. Users log in through a local directory that lives inside the closed network. Once the directory checks their identity, the user lands inside the private zone.
What network isolation solves and what it misses
Network isolation is great at stopping outside attackers from reaching your servers. It also stops local apps from sending stolen data out to public web hosts. If a bad actor cannot reach the network, they cannot probe your ports. This setup satisfies strict rules for government, finance, and defense workloads.
Still, a closed network only decides who can cross the outer wall. It does not control what an authorized user does once they are inside. After an engineer logs into a database or server, network rules step aside. If that user has a broad admin role, they can run any command.
A careless script can still drop a critical table inside an isolated zone. A curious admin can still query full tables of customer emails and card numbers. Native cloud roles check permissions at login time, not while commands run. You still need a way to inspect commands and mask data in flight.
Cloud: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing daily operations in an isolated setup
Day-to-day work in a closed network requires extra planning from your platform team. You cannot rely on public cloud tools to check logs or push updates. Instead, you must run your own logging servers and alert tools inside the boundary. Every alert stays inside the zone unless you build a safe export path.
To reduce risk during maintenance, teams should shrink role permissions for every internal user. Split read roles from write roles on all databases and cluster hosts. Require a second person to approve high-risk tasks before an engineer runs them. Keep clear audit logs that show every single query and command a user runs.
Data masking also plays a big role during live support sessions. When an engineer troubleshoots a bug, masking rewrites matched fields in results. Sensitive fields like phone numbers or national IDs turn into safe placeholders in output. This keeps private data safe even when someone has full network access.
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
How do you update software in an air gapped cloud?
You download updates on an outside machine and scan them for threats first. Then you move the clean files into your private mirror for local servers.
Can a cloud setup be truly air gapped?
In public clouds, you use logical isolation with zero internet routes and private links. Dedicated government cloud regions also offer physical separation from public hardware.
Why do we need command checks inside a closed network?
Network walls do not stop insider mistakes or overly broad admin roles. Checking individual commands prevents accidental data deletion and blocks large data dumps.