Amazon Elastic Compute Cloud (EC2) turned fifteen years old in 2021, and in that time it has become the backbone of a huge share of the internet. Yet a surprising number of teams still stumble over the same handful of configuration errors. The mistakes below are the ones that show up again and again in audits, incident reviews, and surprise billing statements. None of them require exotic knowledge to fix. Most require only a checklist and a little discipline.
Sizing Instances by Guesswork Instead of Data
The single most common EC2 mistake is picking an instance type because it “feels right.” Someone remembers that a `t3.medium` worked for a staging box, so production gets a `m5.4xlarge` “just to be safe.” The result is a fleet that is simultaneously over-provisioned on CPU and under-provisioned on memory, with a bill to match. (What is Amazon EC2?)
What actually works is measuring first. CloudWatch gives you CPU utilization, but CPU alone lies: a workload can sit at 15% CPU while thrashing on memory or disk I/O. Look at memory and network throughput as well, ideally with the CloudWatch agent installed so you get metrics beyond the hypervisor defaults.
Right-sizing is an iterative process, not a one-time decision. Practical tips that hold up in real environments:
- Start with a burstable instance (T-family) for spiky, low-average workloads, but watch the CPU credit balance closely. Exhausted credits turn a cheap instance into a slow one overnight.
- Compare at least two instance families before committing. The difference between a general-purpose and a compute-optimized instance at the same price point is often larger than teams expect.
- Revisit sizing quarterly. Workloads drift, and an instance that was correctly sized at launch is rarely correctly sized a year later.
Over-provisioning has a hidden cost beyond money: oversized instances mask inefficient code, so the performance problem never gets fixed at its source.
Leaving Security Groups Wide Open
A default security group that allows all inbound traffic from `0.0.0.0/0` is the cloud equivalent of leaving the front door propped open with a sign pointing at the valuables. It is also shockingly common, especially in accounts created quickly for a proof of concept and then quietly promoted to production.
The fix is boring but effective. Security groups should follow least privilege: allow only the specific ports from the specific source ranges that genuinely need them. A web server needs 443 from the internet and 22 from a bastion or session manager, not 22 from everywhere. Databases should never accept traffic from outside their own VPC subnet.
Two habits prevent most of these problems:
- Never modify the default security group. Create purpose-built groups with descriptive names, and treat the default as a trap to be left empty.
- Audit inbound rules on a schedule. A rule added during an incident “just for five minutes” has a way of surviving for years.
Network ACLs add a second layer at the subnet boundary. They are not a substitute for security groups, but they catch the mistakes that security groups miss.
Using Long-Lived Access Keys on Instances
Hard-coding an access key and secret into an application config, a `.env` file, or worse, a shell script baked into a custom AMI, is a credential leak waiting to happen. Keys on instances get copied into AMIs, committed to repositories, and pasted into chat threads. Once leaked, they remain valid until someone notices.
The correct pattern is an IAM role attached to the instance profile. The instance retrieves short-lived credentials automatically, and those credentials rotate without any application changes. There is no secret to leak because there is no long-lived secret.
If an application genuinely needs to call AWS APIs from EC2, the role should grant only the specific actions required. A role with `s3:*` on every bucket is barely better than a leaked key. Scope the policy to named resources and specific actions.
Skipping IMDSv2 and Exposing the Metadata Service
The EC2 instance metadata service (IMDS) is how an instance learns its own identity and retrieves temporary credentials. The original version, IMDSv1, accepts simple unauthenticated requests. That design made it vulnerable to server-side request forgery (SSRF): an attacker who can trick an application into fetching an arbitrary URL can ask the metadata endpoint for credentials and walk away with them.
IMDSv2 requires a session token obtained through a PUT request, which breaks the simple SSRF pattern. Enforcing IMDSv2 is a one-setting change per instance or across an entire account through launch templates. There is almost no reason to leave IMDSv1 enabled on new instances.
The practical wrinkle: some older SDKs and agents do not support IMDSv2. Test before enforcing it fleet-wide, and set the metadata service to “disabled” entirely on instances that have no need for it.
Forgetting That Instance Store Is Ephemeral
Instance store volumes are fast, cheap, and completely ephemeral. The data disappears when the instance is stopped, terminated, or moved to new hardware after a host failure. Teams discover this the hard way, usually at the worst possible moment.
Instance store is a fine choice for scratch space, caches, and temporary processing. It is the wrong choice for anything that must survive a reboot cycle. If a workload writes to instance store and the data matters, either replicate it elsewhere continuously or move to EBS.
EBS has its own trap: a volume attached to a single instance in a single availability zone is not a backup. Snapshots are the backup, and snapshots only help if they exist and are tested. An untested backup is a hope, not a plan.
Ignoring Backup and Snapshot Lifecycle Policies
Speaking of snapshots: manual snapshots accumulate forever, cost money, and eventually get deleted by someone tidying up without checking what depends on them. Automated lifecycle policies solve both problems by defining retention rules in code.
A workable baseline looks like this:
| Data type | Snapshot frequency | Retention |
|---|---|---|
| Production databases | Every 6 hours | 35 days |
| Application servers | Daily | 14 days |
| Dev and test | Weekly | 7 days |
| Compliance-bound data | Daily plus monthly archives | Per policy, often years |
The numbers will differ by organization, but the principle does not: retention should be a written decision, not an accident of who remembered to click “create snapshot.” (How to take a screenshot on a mac)
Running Stateful Workloads Without a Failover Plan
Deploying everything into a single availability zone is cheap and simple, right up until that AZ has a bad day. EC2 instances are not inherently resilient; resilience comes from architecture. A single instance holding the only copy of a database is a single point of failure regardless of how many nines the service advertises.
Multi-AZ deployment, load balancing across zones, and automated failover are the standard answers. They cost more, which is why teams skip them, and then pay far more during the outage.
Letting Orphaned Resources Pile Up
Unattached EBS volumes, idle Elastic IP addresses, forgotten load balancers, and snapshots of instances that were terminated two years ago all bill quietly. None of them show up in a dashboard unless someone builds the dashboard.
Tagging is the unglamorous foundation here. Every resource should carry at minimum an owner, an environment, and a cost center. Without tags, cost allocation is guesswork, and cleanup becomes a political negotiation rather than a technical task.
A monthly review that lists unattached volumes and unassociated Elastic IPs takes twenty minutes and routinely finds money. If you need to document what you found, a quick screenshot helps: here is how to take a screenshot on a mac and here is how to take a screenshot on windows, both useful when filing cleanup tickets with visual evidence.
Missing Budgets and Cost Guardrails
AWS will happily let you spend any amount you authorize. Budgets and alerts are the seatbelt. Set a monthly budget with alerts at 50%, 80%, and 100% of expected spend, and route those alerts to a channel someone actually reads.
For non-production accounts, consider hard guardrails: service control policies that block expensive instance families, or automatic shutdown schedules for dev environments outside working hours. A dev box running 168 hours a week when it is used for 40 is pure waste.
Cost anomalies deserve their own alert. A runaway process, a misconfigured auto-scaling group, or a crypto-mining compromise all show up as a spending spike before they show up anywhere else.
Skipping the Operating System and Patch Layer
EC2 is infrastructure as a service, which means the guest operating system is the customer’s responsibility. Unpatched kernels, outdated OpenSSL, and forgotten SSH keys are all familiar stories. The cloud does not patch your AMIs for you.
The sustainable approach is immutable infrastructure: build AMIs from a pipeline, patch the pipeline, and replace instances rather than logging in to fix them. Where that is impractical, at least automate patch reporting so drift is visible.
SSH access itself deserves scrutiny. Key-based access with keys shared across a team is hard to audit. Session Manager or a bastion with short-lived certificates gives you a record of who connected and when, which matters enormously during an incident review.
Treating Monitoring as Optional
An instance without monitoring is an instance you learn about from customers. Basic CloudWatch metrics are free at five-minute resolution, and detailed monitoring at one-minute resolution costs little. Alarms on status checks, CPU, disk, and memory should exist before the instance serves traffic, not after the first outage. (How to take a screenshot on windows)
Log aggregation matters just as much. Instance logs that live only on the instance disappear with the instance. Ship them somewhere durable.
A Quick Word on Tooling Changes
The EC2 ecosystem keeps shifting, and assumptions age badly. Service features, pricing models, and companion services change on a regular cadence; even adjacent platforms churn, as when Amazon Luna ended game purchases in 2026. The lesson generalizes: verify current behavior against documentation rather than relying on what was true two years ago. (Amazon Elastic Compute Cloud)
Conclusion
None of the mistakes above are exotic. They are ordinary shortcuts taken under deadline pressure, and they compound. The teams that run EC2 well are rarely the ones with the cleverest architecture; they are the ones with boring habits: right-size from data, lock down security groups, use IAM roles, enforce IMDSv2, back up and test, tag everything, and set budgets before the bill arrives.
Pick two items from this list and fix them this week. The rest can follow. The goal is not a perfect cloud account, because that does not exist. The goal is an account where the failures you do have are small, visible, and recoverable.
Frequently Asked Questions
What is the most common Amazon EC2 mistake?
Over-provisioning instance types without measuring actual usage is the most widespread mistake, closely followed by overly permissive security groups. Both are easy to introduce and easy to fix, which is why they persist: nobody gets paged when an instance is simply too large or a port is open to the world.
How do I know if my EC2 instances are the right size?
Look beyond CPU utilization. Check memory, network throughput, and disk I/O over at least two weeks, including peak periods. If average CPU sits below roughly 20% and memory is comfortable, a smaller instance is probably viable. Test the change on one instance before rolling it out.
Is IMDSv2 mandatory, and what breaks if I enforce it?
It is not universally mandatory, but enforcing it is strongly recommended because it closes a well-known credential-theft path. The usual breakage comes from older SDKs, custom agents, and legacy applications that only speak IMDSv1. Test in a non-production environment first, then enforce through launch templates.
Should I use IAM roles or access keys on EC2 instances?
Always use IAM roles. Roles provide temporary credentials that rotate automatically and never need to be stored on disk. Long-lived access keys on instances get copied into AMIs, committed to repositories, and leaked. If a key must exist, rotate it and store it in a secrets manager, never in code.
How often should I review my EC2 security groups?
At minimum monthly, and immediately after any incident. Automated tooling that flags rules open to `0.0.0.0/0` catches most problems early. The most dangerous rules are the ones added temporarily during an outage and never removed.
What happens to data on instance store volumes when an instance stops?
It is lost. Instance store is physically attached to the host and does not survive a stop, terminate, or host failure. Use it only for caches, scratch files, and reproducible data. Anything that must persist belongs on EBS with a tested snapshot policy.
