- TechOps Examples
- Posts
- AWS EC2 Guide
AWS EC2 Guide
Govardhana M K
February 28, 2025
TechOps Examples
Hey — It's Govardhana MK 👋
Along with a use case deep dive, we identify the remote job opportunities, top news, tools, and articles in the TechOps industry.
IN TODAY'S EDITION
🧠 Use Case
AWS EC2 Guide
🚀 Top News
👀 Remote Jobs
Fluz is hiring a DevOps Engineer
Remote Location: Worldwide
Leapswitch is hiring a Senior Cloud Engineer
Remote Location: India
📚️ Resources
📢 Reddit Threads
🛠️ TOOL OF THE DAY
vulnerable-apps - A sample repository with over 100 examples of vulnerable apps
Note: This can be used for educational or training purposes ONLY – don’t try it in work environments.
🧠 USE CASE
AWS EC2 Guide
I witness this loop in many cases, and you may too.
A cloud engineer spins up an EC2 instance, picks the constant settings, and moves on. Then comes another instance, and another.
Before long, there’s an entire fleet of underutilized, misconfigured, or overpriced EC2 instances running unchecked.
The cycle repeats because it’s easy, but at what cost?
EC2 is powerful, but without intentional decision making, it becomes an expensive, inefficient sprawl.
I’ve prepared this to provide a quick snapshot of the most crucial things you should know.
Download a high resolution copy of this diagram here for future reference.
1. Don’t Let Convenience Burn Your Budget
The biggest mistake engineers make is defaulting to On Demand instances.
It’s the easiest way to get started, but for long term workloads, it’s financially unsustainable. Consider:
Savings Plans vs Reserved Instances: If your workload is predictable, commit to a 1 or 3 year term and slash costs by up to 72%.
Spot Instances: Ideal for fault tolerant applications like batch processing and stateless services.
Compute Savings Plans: A flexible middle ground for teams unwilling to lock into specific instances but still looking for savings.
If your team never revisits its EC2 costs, chances are you’re leaving money on the table.
2. Instance Type Selection Is More Than Just CPU and Memory
Many engineers blindly default to general purpose instances (like t3 or m5), assuming they’re good enough.
But AWS provides highly specialized instance families, picking the right one can be game changing:
C family (Compute Optimized): Best for high performance computing, media transcoding, and gaming workloads.
R family (Memory Optimized): Databases, in memory caching, SAP HANA - if RAM is your bottleneck, use these.
I family (Storage Optimized): For applications that need high IOPS and low latency disk access.
Graviton based instances: AWS’s ARM based processors offer better price performance for specific workloads like microservices and containerized applications.
Are you choosing based on your workload’s actual resource consumption, or just habit?
3. Placement Groups - The Overlooked Performance Booster
Most engineers don’t realize that AWS Placement Groups can make a drastic difference in network latency and throughput.
Before blindly launching an instance, consider:
Cluster Placement Group: For high speed, low latency inter instance communication (great for HPC workloads).
Spread Placement Group: Distributes instances across hardware to improve fault tolerance.
Partition Placement Group: Ideal for large distributed systems like HDFS and Cassandra, reducing correlated failures.
4. Be Ready for Failures
Downtime happens, but how you design your EC2 strategy determines whether it’s a minor inconvenience or a full blown outage.
Auto Recovery: Automatically restarts unhealthy instances to minimize downtime.
Stop vs Hibernate: If your application can resume from memory, hibernation saves time and speeds up boot.
Spot Fleet & Auto Scaling: Ensure cost efficiency by dynamically scaling based on demand rather than keeping fixed instances running.
Before launching another EC2 instance, remember these pointers as they could make all the difference.
You may even like: