Core Compute & Isolation
AWS Nitro System
Nitro moves networking, EBS and management off the host CPU onto dedicated cards, which shrinks the hypervisor to something small enough to reason about. The security argument is real: less shared code between tenants means fewer places a cross-tenant escape can live. It is also the wrong thing to spend your attention on. Nobody's AWS account has been breached through the hypervisor. They are breached through an IAM policy someone widened at 17:00 on a Friday.
Nitro Security Chip
The security chip anchors secure boot in hardware, so only signed AWS firmware runs, and the design deliberately removes the interactive administrative access that would let an AWS operator reach into tenant memory. Take that as a strong architectural constraint rather than a mathematical guarantee — it is a claim about AWS's own design and operational controls, verified by audit rather than by anything you can check. For most threat models that is enough. For the ones where it is not, the answer is Nitro Enclaves or your own key custody, not a better hypervisor.
Under the Hood Architecture
VPC Hardware Firewall
Security Groups are enforced in the Nitro data plane, not in the guest, so an instance cannot spoof its way past its own rules and a compromised host cannot disable its own firewall. Two things to internalise. Security Groups are stateful and allow-only, so there is no deny rule and no rule ordering — if you need explicit denies, that is a Network ACL, and NACLs are stateless, which is why people who reach for them break return traffic. And the default group allows all traffic between members of itself, which is how a flat, fully-reachable subnet gets built by accident.
VPC Traffic Mirroring
Traffic Mirroring copies packets from an ENI to a Suricata or Zeek sensor out of band, which gives you real packet forensics without touching the production path — the closest thing to a SPAN port that a cloud offers. Price it before you enable it broadly: you are paying for the mirrored bandwidth, the sensor fleet and the storage, and mirroring everything is how a security budget disappears. Mirror the segments where an investigation would otherwise be impossible, and rely on VPC Flow Logs for the rest.
Real-World Attack Surface
IAM Complexity & Privilege Creep
This is the actual attack surface. AWS ships thousands of individual actions across hundreds of services, evaluated through identity policies, resource policies, permission boundaries, SCPs and session policies simultaneously — and almost nobody can state from memory what a given principal can do. Privilege escalation rarely needs a vulnerability here; iam:PassRole paired with the ability to launch a compute resource is enough, and both are routinely granted to developers who need neither. The failure is silent by construction: an over-broad policy produces no error, no alert and no symptom until someone uses it.
SSRF targeting IMDSv1
One HTTP request from a vulnerable application to 169.254.169.254 returns the instance role's credentials. That is the whole exploit against IMDSv1 — no authentication, no header, nothing an SSRF payload cannot reach — and it is why the 2019 Capital One breach turned a WAF misconfiguration into 100 million records. IMDSv2 fixes it by requiring a PUT to obtain a session token with a TTL-limited hop count, which ordinary SSRF cannot perform. IMDSv1 still works on any instance where it was not explicitly disabled.
Mandatory Hardening Baseline
- Enforce IMDSv2 Globally: set
HttpTokens: requiredfleet-wide, and enforce it at launch time with an SCP rather than a remediation job — otherwise you are permanently chasing instances someone spun up from an old AMI. Expect breakage: older SDKs and any hand-rolled metadata call will stop working, and they fail as credential errors that look like an IAM problem rather than an IMDS one. - Root Account Security: hardware MFA on the management-account root, with no access keys on it at all, and the recovery path written down somewhere that does not depend on AWS. Then think about who physically holds the key and what happens when they are on leave during an incident.
- Strict IAM Boundaries: verify least privilege with IAM Access Analyzer, and pay particular attention to cross-account roles for managed services and third-party vendors — the confused-deputy path runs through them, and
sts:ExternalIdexists because of it. Access Analyzer's findings-from-usage are only as good as its observation window, so a role that is quiet during the sample looks unused rather than over-permissioned.
Architecture Comparison
| Component | AWS | GCP | Azure |
|---|---|---|---|
| Isolation Architecture | Nitro System (Hardware offload) | KVM (Custom/Non-QEMU) | Hyper-V + Cerberus chip |
| Network Visibility | VPC Flow Logs (Costly) | Native Packet Mirroring | NSG Flow Logs |
| Identity Security Tax | Moderate (Directory Services cost) | Severe ($7.20/user/mo for SCIM) | High (Entra ID P1/P2) |
| Key Management | KMS (FIPS 140-2 L2) / CloudHSM | KMS / Cloud HSM (L3) | Key Vault (L2) / Managed HSM |
