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 it is open public WiFi at a coffee shop.
Today, we are doing a deep dive. We will build a
"Landing Zone" according to high-security standards and explain how "Air Gapped" actually works in AWS.
The Myth: "Air Gap" requires scissors (cutting the cables to the outside world)
In the old world, an "Air Gap" meant: The server is in the basement, the network port is glued shut, and you can only enter with a USB stick.
In the Cloud, there are no physical air gaps. But there are logical air gaps. And if you build them correctly, they are often more secure than that dusty server in the basement that hasn't been patched since 2015.
Here is my blueprint for high-security environments
(Banking, Pharma, GovTech).
1. The Foundation:
The "Landing Zone"
A Landing Zone is just an AWS Account, Right ?
Wrong.
A Landing Zone is the airport before the first plane
(your application) even lands. It is a fully automated,
pre-configured set of rules.
When I say "Landing Zone," I mean a Multi-Account Strategy using AWS Control Tower.
Why we need this:
We don't throw everything into one bucket. We separate strictly:
- Security Account: This holds the logs (CloudTrail) that nobody can delete. (Write Once, Read Many).
- Shared Services:
Centralized tooling lives here.
- *Workload Accounts (Prod/Dev): * This is where the app lives.
The trick?
We use SCPs
(Service Control Policies).
Think of these 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 is the first wall.
2. The Architecture:
"Private by Design"
Now let's get technical.
How do we simulate the Air Gap?
We build a VPC (Virtual Private Cloud) that is deaf and mute to the public internet.
The Ingredient List for the "High-Security Standard":
A. No Internet Gateways (IGW)
This is Rule #1. In your sensitive subnet, there is no IGW.
There is no route to 0.0.0.0/0
Packets trying to go to the internet simply die here. It is a dead end.
B. AWS PrivateLink (VPC Endpoints)
"But Ali, if I have no internet, how do I talk to S3 or my Database Backups?"
Here comes the magic:
AWS PrivateLink
Instead of routing traffic over the public internet to reach AWS services, we „drill“ a private tunnel directly through the AWS Backbone Network. The traffic never leaves the Amazon network.
To your server, S3 looks like a local hard drive in its own LAN.
C. KMS (Key Management Service) with CMK
Encryption is mandatory. But we don't just use the default keys.
We use Customer Managed Keys (CMK).
Why?
Because we control the Key Policy. We can say: "This key can ONLY be used if the request comes from inside THIS specific VPC."
What this does ?
Even if someone steals the data without the key and the correct location (VPC), it’s just digital garbage.
3. Admin Access: Kill the Bastion Host!
This is my favorite topic.
Historically, we built "Jump Servers" or "Bastion Hosts."
A server with a public IP that we SSH into, just to jump to the next server.
This is a security vulnerability. Port 22 is open. Hackers love Port 22.
The Solution: AWS Systems Manager (SSM) Session Manager
We install the SSM Agent (or use AMIs where it’s pre-installed).
The Agent connects from the inside out to the AWS Service.
- No Port 22 open.
- No Public IP needed.
No SSH Key Management
Every command is logged ("Who typed
rm -rf?").
This is the modern way. The Admin sits at home, authenticates via IAM (MFA!), and gets a shell in the browser or terminal. But the server itself remains completely dark to the internet.
4. Summary: The "Air Gapped Cloud" Checklist
Next time someone asks you how to build "High Security" in the Cloud, this is your Tech Stack:
Isolation: Dedicated AWS Account, locked down by SCPs (Organizational Policies).
Network: Private Subnets without an Internet Gateway.
Connectivity: VPC Endpoints (PrivateLink) for AWS Services.
Access: SSM Session Manager instead of SSH/Bastion.
Data: KMS Encryption with strict Key Policies.
This is how we build systems that are compliant, secure, and yet scalable. We don't need to cut the cables. We just need to design the architecture correctly.
Have you worked with Air-Gapped environments in the Cloud before? Drop your thoughts and opinions in the comments!
*Hi, I'm Ali! I am currently retraining as an IT Specialist (I have 8 years of IT experience)
and on my journey to becoming a Cloud Security Architect.
I love translating complex security concepts into plain language. Follow me for more insights from my journey!*
Top comments (0)