In this blog post, we will take a look at the top 13 AWS EC2 misconfigurations that you should avoid. Let us brush up our knowledge on what AWS EC2 is first.
2026 update — the 13 misconfigurations below are still worth avoiding, but AWS has changed several defaults since this article was written, and there are now bigger EC2 risks that this original list did not cover.
Read this article as two layers. The original 13 items (below) remain valid checks — none of them have become “wrong.” What has changed is that AWS now gives you account-level guardrails that make some of these misconfigurations far easier to prevent, and the real-world EC2 attack pattern has shifted toward identity and metadata abuse rather than open ports alone. Each relevant section below carries an inline note explaining exactly what changed. In short, the most important 2026 additions are:
- Enforce IMDSv2 on every instance. This is the single most impactful EC2 security control today and it was not in the original list. Details are in the new section added after item 13.
- Turn on the account-level “Block Public Access” settings that AWS shipped in 2023 — one for EBS snapshots and one for AMIs. These turn the first three items below from “remember to check each resource” into “block it once for the whole account.”
- Turn on EBS encryption by default at the account level so the AMI/volume encryption items are satisfied automatically for every new volume.
- Do not rely on the “default VPC” advice as a security control by itself — the reasoning has been clarified below.
Nothing here asks you to undo the original guidance. It tells you the current, easier, and more complete way to achieve the same goal.
What is AWS EC2?
Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides a secure and resizable compute capacity in the cloud. In other words, Amazon allows users to rent virtual computers (called EC2 instances) on which they can run their applications. This eliminates your need to invest in hardware resources as you can rely on these virtual servers for your storage and configure your security. The aim of AWS EC2 is to make web-scale distributed computing simpler for developers. The “pay-as-you-go” model of AWS EC2 makes it even more popular.
The 13 Common AWS EC2 Misconfigurations
With every good service and for it to be really secure, you need to take specific measures from your side too. Below are the AWS top 13 common EC2 Misconfigurations that will help you achieve security, efficiency, cost optimization, and adherence to various compliance standards.
-
Public Snapshots
-
Non-public EC2 AMI
-
Encrypted AMI
-
Not using default VPC
-
AMI Age
-
Scheduled Events
-
EC2 Instance Not In Public Subnet
-
Unrestricted Netbios Access
-
Unrestricted Outbound Access
-
EC2 Reserved Instance Payment Pending
-
EC2 IAM Roles
-
Unrestricted CIFS Access
-
EC2 Reserved Instance Payment Failed
Let us take a look at them one by one in detail.
Public Snapshots
The very first EC2 misconfigurations you should be avoiding is making your snapshots public. Ensure that your EC2 instance snapshots are not publicly accessible. Having public snapshots can expose your personal and sensitive information, thereby violating compliance standards like GDPR, NIST, and PCI DSS. Violating these compliance standards can result in hefty fines and litigation.
2026 update — you can now block this at the account level in one step, instead of checking each snapshot. In November 2023 AWS launched Block Public Access for EBS snapshots. It is a Regional setting: once you enable it (in “block all sharing” mode) in a Region, any attempt to publicly share a snapshot in that Region is automatically blocked, and snapshots that were already public are treated as private. The right move today is to enable this setting in every Region you use, so a public snapshot becomes impossible rather than something you have to keep auditing. The per-snapshot check below is still useful as a detection control, but the account-level block is your primary defense now. Note that this setting is not on by default — you must turn it on.
Non-Public EC2 AMI
The next most common EC2 misconfiguration is publicly sharing your Amazon Machine Images (AMIs) with other AWS accounts. AWS AMIs should not be shared publicly with the other AWS accounts to prevent exposing sensitive data. It is a requirement for NIST**,ARPA, and** MAS compliance standards.
2026 update — there is now an account-level “Block Public Access for AMIs” setting, mirroring the snapshot one. AWS added this control so you can prevent any AMI in your account from being made public, regardless of individual sharing settings. Important nuance so you do not assume the wrong default: if your account had one or more public AMIs on or after July 15, 2023, this Block Public Access setting is disabled by default for your account (even if you later made those AMIs private); otherwise it may be enabled by default. Because the default depends on your account’s history, do not assume — explicitly check the “Block public access for AMIs” setting in the EC2 console (under Data protection and security / AMI settings) and turn it on. Keep doing the per-AMI review below as well, especially before publishing any AMI you build from a production instance, since AMIs can carry embedded credentials or data.
Encrypted AMI
Talking about AMIs, having non-encrypted AMIs is another misconfiguration. When dealing with sensitive data that is crucial to your business, encrypting AMIs is necessary to protect your data from attackers. Amazon Machine Images (AMIs) should be encrypted to fulfill compliance requirements for data-at-rest encryption. Compliance standards required for this are NIST,PCI,ARPA,MAS,HIPAA, and GDPR.
2026 update — enable “EBS encryption by default” once, and every new volume, snapshot, and AMI is encrypted automatically. Rather than remembering to encrypt each AMI, turn on the account-level, per-Region setting EC2 → EBS encryption → Enable encryption by default. After that, all newly created EBS volumes and the snapshots/AMIs derived from them are encrypted with your chosen KMS key without any further action. This directly satisfies the data-at-rest requirements listed above for NIST, PCI DSS, HIPAA, and GDPR. Two things to know so you are not caught out: this setting does not retroactively encrypt volumes that already exist (you must copy/re-create those), and it is a Regional setting, so enable it in every Region you operate in.
Not Using Default VPC
Using a default VPC is a misconfiguration you should avoid. It is recommended not to use the default VPC. Compliance with this policy is also required for APRA**,** MAS**,** and NIST.
2026 update — the goal here is a purpose-built, segmented network, not simply “avoid the default VPC.” Avoiding the default VPC is still reasonable advice, but on its own it does not make you secure — a custom VPC with wide-open security groups is no better than the default one. Read this item as “design your own VPC with intentional subnetting, security groups, and routing” rather than treating the default VPC as the whole problem. In 2026 the stronger, current practices are: put workloads in private subnets by default, use VPC endpoints so traffic to AWS services (S3, ECR, etc.) stays off the public internet, and use tools like AWS Network Access Analyzer or VPC Reachability Analyzer to prove which paths are actually reachable. The default-VPC check is a starting point, not the finish line.
AMI Age
Your AMI should not be old than a given number of days. This value can be as per your convenience; however, we recommend not having an AMI older than 180 days. Using up-to-date AMIs ensures that your EC2 instances deployed are secure and reliable. Overcoming this misconfiguration is one step toward achieving NIST, APRA, and MAS compliance.
Scheduled Events
Not taking any action on the AWS EC2 scheduled events results in unexpected downtimes that further result in low availability and reliability. You should take the necessary steps on EC2 instances that are scheduled for retirement and/or maintenance.
EC2 Instance Not In Public Subnet
Backend instances should not be running in public subnets. This will help you maintain security. Backend instances are EC2 instances that should run in a private subnet (i.e., behind a NAT gateway). Backend instances do not require direct access to the public internet, such as databases, API, or caching servers.
Unrestricted Netbios Access
No AWS EC2 security group should allow unrestricted inbound access to TCP port 139 and UDP ports 137 and 138 (NetBIOS). Failure to resolve this misconfiguration can result in devastating consequences like Denial of Service (DoS) attacks, man-in-the-middle (MITM) attacks, and data breaches. Furthermore, having this misconfiguration violates a host of compliance standards like – PCI**,** APRA**,** MAS**,** NIST**,** and SOC2.
Unrestricted Outbound Access
EC2 security groups should not allow unrestricted outbound/egress access. The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives.
2026 update — restricting outbound access matters more now, because it is your main defense against data exfiltration and command-and-control. The three port-specific items in this list (NetBIOS on 137–139, CIFS/SMB on 445, and unrestricted egress) are all still valid, but the way to think about them has matured. Inbound rules for legacy Windows file-sharing ports (NetBIOS, SMB/CIFS) should almost never be open to
0.0.0.0/0at all — these have been the entry point for worms and ransomware for years, so treat any such rule as a critical finding. For outbound access, the modern reasoning is that once an attacker or a compromised dependency is running on your instance, wide-open egress is what lets them phone home and copy your data out. Lock egress down to only the destinations the workload actually needs, and route AWS-service traffic through VPC endpoints so it never traverses the public internet. Pair this with VPC Flow Logs (and GuardDuty, which reads them) so unexpected outbound connections are detected even if a rule is too broad. The principle: default-deny on both directions, then open only what is required and justified.
EC2 Reserved Instance Payment Pending
Ensuring that none of your AWS EC2 Reserved Instance purchases have a pending status helps you implement cost optimization. Furthermore, it also helps you comply with APRA**,** MAS, and**** AWAF.
EC2 IAM Roles
IAM Roles/Instance profiles should be used instead of IAM Access Keys to appropriately grant access permissions to any application that performs AWS API requests running on your EC2 instances.
2026 update — using an IAM role is correct, but it is only half the control today. You must also enforce IMDSv2, or that role becomes an attacker’s easiest target. When an instance uses an IAM role, its temporary credentials are handed out by the Instance Metadata Service (IMDS) at the link-local address 169.254.169.254. In the old IMDSv1 model, any process that could make an HTTP request from the instance could read those credentials — which is exactly how Server-Side Request Forgery (SSRF) attacks steal EC2 role credentials (the well-known 2019 Capital One breach followed this pattern). IMDSv2 fixes this by requiring a session token obtained with a PUT request and enforcing a low network hop limit, which blocks the typical SSRF and proxy paths. So the complete 2026 practice is: attach a least-privilege IAM role (as this item says) and require IMDSv2 on the instance. See the dedicated IMDSv2 section added below the list for how to enforce it account-wide.
Unrestricted CIFS Access
No AWS EC2 security group should allow unrestricted inbound access to TCP port 445 and (CIFS). Failure to resolve this misconfiguration can result in devastating consequences like Denial of Service (DoS) attacks, man-in-the-middle (MITM) attacks, and data breaches. Furthermore, having this misconfiguration violates a host of compliance standards like – PCI**,** APRA**,** MAS**,** and NIST.
EC2 Reserved Instance Payment Failed
Ensuring that none of your AWS EC2 Reserved Instance purchases have failed helps you implement cost optimization. Furthermore, it also helps you comply with APRA**,** MAS, and**** AWAF.
2026 addition — Enforce IMDSv2 (the single most important EC2 control missing from the original list)
This misconfiguration did not appear in the original 13, but in 2026 it belongs near the top of any EC2 hardening list. Instances that still allow IMDSv1 are the most common way attackers turn a minor application flaw (like SSRF) into stolen AWS credentials.
What to do, precisely:
- Set IMDSv2 as the account default for new launches. Since March 2024 you can set an account-level, per-Region default so every newly launched instance requires IMDSv2 automatically. The latest EC2 instance types already default to IMDSv2, but older types do not, so set the account default explicitly.
- Require IMDSv2 on existing instances by setting
HttpTokens=required(and a hop limit of 1 or 2) viaaws ec2 modify-instance-metadata-options.- Find who still uses IMDSv1 before enforcing, using the CloudWatch
MetadataNoTokenmetric — when it reads zero, nothing is relying on IMDSv1 anymore and it is safe to require IMDSv2 everywhere.- Bake it into your AMIs so images launch with IMDSv2 required from the start.
Enforcing IMDSv2 is free, and it closes the exact door that credential-theft attacks against EC2 rely on.
2026 addition — three more modern EC2 checks worth adding
- Attach instances to SSM, not SSH. Use AWS Systems Manager Session Manager for shell access instead of opening port 22 with SSH keys, or adopt just-in-time VM access for identity-stamped, time-bound sessions. It removes the need for public inbound SSH, gives you full audit logging, and works through IAM. An open port 22 to the world is now considered a finding in its own right. This is the pattern behind securing EC2 workloads through a Kubernetes migration in healthcare.
- Watch for public IPs you did not intend. Auto-assign public IP on subnets and launch templates quietly puts workloads on the internet. Treat “instance has a public IP” as something to justify, not a default.
- Feed EC2 findings into continuous scanning. The current Amazon Inspector automatically and continuously scans running EC2 instances for OS and application CVEs (this replaces the old “AMI Age” style manual check with real vulnerability data). Enable it so a stale, vulnerable instance is flagged the moment a new CVE lands, not 180 days later.
How Can Cloudanix Help?
EC2 Misconfigurations issues are not new. It is the largest issue faced by organizations for years. It is essential to understand what they are and why acting on them immediately is necessary. Cloudanix provides you with an EC2 recipe that helps audit your AWS account for these misconfigurations and more, as part of continuous CSPM and workload protection! We also help you remediate these EC2 misconfigurations in an automated way — the same foundation behind workload protection for Docker on EC2 for a healthcare lean team. You can sign up for a free trial today!
People Also Read
- Top 15 Cloud Misconfigurations in 2026 - How to Fix Them?
- A Complete List of AWS S3 Misconfigurations
- Top 16 AWS S3 Misconfigurations To Avoid in 2023
- 15 Top AWS RDS Misconfigurations To Avoid
- Top 10 Azure Virtual Machine (VM) Misconfigurations To Avoid
- Top 6 AWS IAM Misconfigurations To Avoid in 2022
- How to use CSPM to detect and remediate cloud misconfigurations
- Top 18 Challenges of Cloud Security in 2026
