EC2 Security

EC2 Security encompasses the controls needed to protect virtual machines running in AWS. EC2 instances are a top target because they often hold application code, data, and credentials, and because the IAM role attached to an instance turns any host compromise into a cloud credential compromise.

Key Security Controls

• IMDSv2: enforce Instance Metadata Service v2 (token-required) to prevent SSRF attacks from stealing credentials; IMDSv1 should be disabled
• Instance Profiles: use IAM roles (not access keys) for EC2 to access other AWS services
• Security Groups: stateful firewall rules; deny all inbound by default, open only required ports
• EBS Encryption: enable default encryption for all new EBS volumes in each region
• Key Pairs: use EC2 Instance Connect or SSM Session Manager instead of managing SSH keys
• Patching: use SSM Patch Manager for automated OS and application patching
• Nitro Enclaves: isolated compute environments for processing highly sensitive data

Common Risks

• IMDSv1 enabled, allowing SSRF to steal instance role credentials
• Security groups with 0.0.0.0/0 on SSH (port 22) or RDP (port 3389)
• Unencrypted EBS volumes containing sensitive data
• Unpatched instances with known CVEs

Why IMDSv2 Is the Control That Matters Most

Every instance can ask the metadata service at 169.254.169.254 for the temporary credentials of its IAM role. Under IMDSv1 that is a simple GET request, which means any bug that lets an attacker make the server fetch a URL of their choosing (SSRF, a misconfigured proxy, a vulnerable dashboard) can be aimed at the metadata endpoint to read those credentials, no host compromise required. IMDSv2 changes the protocol: callers must first obtain a session token via a PUT request with a special header, then present that token on every read. Typical SSRF primitives cannot send a PUT with custom headers, so the attack collapses. Two settings complete the picture: the hop limit, which defaults to 1 so the metadata response cannot travel beyond the instance itself (set it to 2 only where containers on the instance legitimately need IMDS access), and the option to disable the endpoint entirely on instances that never call AWS APIs.

How It Goes Wrong in Practice

The canonical EC2 incident chains three of the risks above. A web application with an SSRF flaw runs on an instance still allowing IMDSv1. The attacker makes the application request the credentials path of the metadata service, receives the role's access key, secret key, and session token in the response body, and replays them from their own machine. From there the blast radius is whatever the instance role allowed, and instance roles are chronically over-permissioned: s3:GetObject on * turns a web bug into a full data lake exfiltration. This exact pattern, SSRF to IMDSv1 to over-broad role, has driven some of the most damaging publicly documented cloud breaches, and it is entirely preventable with a metadata option flag plus least-privilege role scoping. GuardDuty adds a detective layer here: it can flag instance credentials being used from outside AWS.

A Practical Check: Enforcing IMDSv2 on a Running Instance

Requiring IMDSv2 on an existing instance is one call, no restart needed:

aws ec2 modify-instance-metadata-options --instance-id i-0abc123def4567890 --http-tokens required --http-endpoint enabled

With --http-tokens required, IMDSv1 calls stop working immediately; --http-put-response-hop-limit accepts 1 to 64 if containers need access. For fleets, make the AMI and launch templates default to IMDSv2 and add an SCP or Config rule so exceptions surface. Audit before enforcing: the CloudWatch metric MetadataNoToken shows whether anything on an instance is still making IMDSv1 calls.

Frequently Asked Questions

Will enforcing IMDSv2 break my applications?

Only if something on the instance still speaks IMDSv1, typically very old AWS SDKs, ancient agents, or hand-rolled curl scripts against the metadata endpoint. Modern SDKs negotiate IMDSv2 transparently. Check the MetadataNoToken metric for residual v1 traffic first; if it is zero, enforcement is a non-event.

Do I still need SSH access to EC2 instances?

Usually not. SSM Session Manager provides shell access through the SSM agent with IAM-based authorization and session logging, requiring no inbound port 22, no bastion, and no long-lived key pairs. Closing inbound SSH entirely removes one of the two most attacked ports on the internet from your surface.

What is the default IMDS hop limit and when should I change it?

The default is 1, which keeps metadata responses from being forwarded beyond the instance. Set it to 2 when containers running on the instance legitimately need instance metadata or role credentials; container network hops consume one unit, so a limit of 1 blocks them.