The 'Virtual Air Gap': Building Fort Knox in AWS
Source: Dev.to
Imagine standing in front of your CISO (or a very strict Data Privacy Officer in Germany) and saying: “We are moving our sensitive patient data to the cloud.”
The reaction? Panic. Hyperventilation. “Never! That needs to be air‑gapped! No internet connection allowed!”
I come from the world of Pharma IT (BioNTech). I know these requirements inside out, and I am here to tell you: yes, it is possible—but we have to stop treating the cloud like open public Wi‑Fi at a coffee shop.
Today we’ll do a deep dive, build a Landing Zone according to high‑security standards, and explain how an “air‑gap” actually works in AWS.
The Landing Zone
What a Landing Zone Is Not
A Landing Zone is not just a single AWS account.
Multi‑Account Strategy with AWS Control Tower
When we talk about a Landing Zone we mean a multi‑account strategy orchestrated by AWS Control Tower. We don’t throw everything into one bucket; we separate responsibilities into distinct accounts.
Account Types
| Account | Purpose |
|---|---|
| Security Account | Holds immutable logs (CloudTrail) that nobody can delete (Write‑Once, Read‑Many). |
| Shared Services | Centralized tooling and services used across the organization. |
| Workload Accounts (Prod/Dev) | Host the actual applications. |
Service Control Policies (SCPs)
Think of SCPs as “parental controls” that sit above the local administrator.
Example policy: In this account, nobody—not even the Root user—is allowed to create a public IP address or attach an Internet Gateway.
That becomes the first wall.
Private by Design
Simulating the Air Gap
Rule #1: In your sensitive subnet, do not attach an Internet Gateway (IGW).
Any packet destined for 0.0.0.0/0 simply dies—there is no path to the public internet.
“But if there’s no internet, how do we talk to S3 or our database backups?”
Accessing AWS Services: PrivateLink
AWS PrivateLink (VPC Endpoints) creates a private tunnel directly through the AWS backbone network. Traffic never leaves the Amazon network, and services such as S3 appear as if they are on the same LAN.
Encryption with Customer‑Managed Keys (CMK)
We use KMS Customer Managed Keys with strict key policies, e.g., “This key can ONLY be used if the request originates from this specific VPC.”
Even if data is exfiltrated, without the correct key and VPC context it is useless.
Secure Access without SSH
- Install the SSM Agent (or use AMIs with it pre‑installed).
- Use AWS Systems Manager Session Manager for interactive shells.
- Authenticate via IAM (MFA) and launch sessions from a browser or terminal.
No public IP, no open SSH port, no key‑pair management.
Every command is logged, providing full auditability (e.g., “Who typed rm -rf …?”).
Recommended Tech Stack for High‑Security Cloud Environments
| Layer | Recommendation |
|---|---|
| Isolation | Dedicated AWS account, locked down by SCPs (Organizational Policies). |
| Network | Private subnets without an Internet Gateway. |
| Connectivity | VPC Endpoints (PrivateLink) for all AWS services. |
| Access | SSM Session Manager instead of SSH/Bastion. |
| Data | KMS encryption with strict, VPC‑bound key policies. |
Designing the architecture this way yields systems that are compliant, secure, and scalable—no need to cut physical cables, just apply the right logical controls.