AWS Notes: EC2

These are my notes about AWS EC2. I’m writing down what I learned so I don’t forget. I’ll cover the basics and some useful tips.

First, let’s talk about budgets. It’s good to set one up before you start using EC2 so you don’t get surprised by the bill.

Setting Up Budgets

A Zero-Spend Budget is really useful. It tells you when you start spending money (above $0.01). Good for free tier accounts or when you want to know if something unexpected is charging you.

To create a Zero-Spend Budget:

1. Go to AWS Billing and Cost Management → Budgets
2. Click Create budget
3. Select Use a template (simplified)
4. Choose Zero spend budget template
5. Enter a budget name (e.g., “My Zero-Spend Budget”)
6. Add email recipients for alerts
7. Click Create budget

EC2 Basics

EC2 is AWS’s virtual server service. Basically, you can create virtual machines in the cloud. You can make them bigger or smaller whenever you want.

EC2 Capabilities

EC2 offers several key capabilities and related services:

Service/Feature	Description
EC2 Instances	Virtual servers with different instance types (compute, memory, storage optimized)
Auto Scaling Groups	Automatically scale EC2 instances based on demand or schedules
EBS (Elastic Block Store)	Persistent block storage volumes for EC2 instances
ELB (Elastic Load Balancer)	Distributes incoming traffic across multiple EC2 instances
Security Groups	Virtual firewalls that control inbound and outbound traffic
Key Pairs	SSH key pairs for secure access to EC2 instances
AMI (Amazon Machine Image)	Pre-configured templates for EC2 instances
Placement Groups	Logical grouping of instances for low latency or high throughput

EC2 User Data

User Data is cool - it’s a script that runs automatically when your EC2 instance starts for the first time. You can use it to install stuff, set things up, or run commands. Super useful for automation.

Example: Installing Nginx

Here’s a simple example to install and start Nginx on an Amazon Linux instance:

#!/bin/bash
yum update -y
yum install -y nginx
systemctl start nginx
systemctl enable nginx

Steps to add User Data:

1. When launching an EC2 instance, go to Advanced details section
2. Scroll down to User data
3. Paste your script in the text box
4. Continue with instance launch

Once the instance is in running status, you can access the default Nginx welcome page by opening your browser and navigating to http://[public-ip]. Make sure your security group allows inbound traffic on port 80.

EC2 Instance Types

EC2 has different instance types. Each one is good for different things. Some have more CPU, some have more memory, some have more storage. You pick based on what you need.

Instance Family	Use Case	Examples	Key Feature
General Purpose	Balanced compute, memory, and networking	t3, t4g, m5, m6i	Good for most applications
Compute Optimized	High-performance computing, batch processing	c5, c6i, c7i	More CPU power
Memory Optimized	Databases, caching, big data analytics	r5, r6i, x1e	More RAM
Storage Optimized	High I/O databases, data warehousing	i3, i4i, d2	High storage I/O
Accelerated Computing	Machine learning, graphics rendering	p3, p4, g4	GPU support

Naming convention:

• Letter (t, m, c, r, i, d, p, g) = Family type
• Number (3, 4, 5, 6, 7) = Generation
• Size (nano, micro, small, medium, large, xlarge, 2xlarge, etc.) = Resources

Most of the time, general purpose (t3, m5) is fine. Use compute optimized (c5) if you need lots of CPU power. Use memory optimized (r5) for databases that need lots of RAM.

Useful resource: EC2 Instances Comparison - Compare EC2 instance types, pricing, and specifications.

Security Groups

Security Groups are like firewalls for your EC2 instances. They control what traffic can come in and go out. Think of them as the first line of defense.

How Security Groups Work

• Stateful: If you allow traffic in, the response automatically goes out (and the other way around)
• Default deny: By default, nothing can come in, but everything can go out
• Multiple groups: You can attach more than one security group to an instance
• Region-specific: Security groups only work in one region and VPC

Key Concepts

Concept	Description
Inbound Rules	Control traffic coming into your instance
Outbound Rules	Control traffic going out from your instance
Source/Destination	IP addresses, CIDR blocks, or other security groups
Port/Protocol	Specific ports (e.g., 80, 443, 22) and protocols (TCP, UDP, ICMP)

Common Security Group Rules

Use Case	Port	Protocol	Source	Notes
Web Server (HTTP)	80	TCP	0.0.0.0/0 or specific IPs	Allow HTTP traffic from internet
Web Server (HTTPS)	443	TCP	0.0.0.0/0 or specific IPs	Allow HTTPS traffic from internet
SSH Access	22	TCP	Your IP address only	Never use 0.0.0.0/0 for security
MySQL Database	3306	TCP	Application security group	Only allow from app servers
PostgreSQL Database	5432	TCP	Application security group	Only allow from app servers

Creating a Security Group

1. Go to EC2 → Security Groups → Create security group
2. Enter a name and description
3. Select the VPC
4. Add inbound rules:
   • Type: Select protocol (HTTP, HTTPS, SSH, Custom TCP, etc.)
   • Source: IP address, CIDR block, or another security group
   • Port: Specific port or port range
5. Add outbound rules (optional, defaults to allow all)
6. Click Create security group

Key Pairs and SSH Access

To connect to your EC2 instance via SSH, you need a key pair. AWS keeps the public key, and you keep the private key on your computer. Don’t lose it!

Creating a Key Pair

Option 1: Create in AWS Console

1. Go to EC2 → Key Pairs → Create key pair
2. Enter a name (e.g., my-ec2-key)
3. Choose key pair type:
   • RSA (most common)
   • ED25519 (newer, more secure)
4. Choose private key file format:
   • .pem (for OpenSSH, Linux/Mac)
   • .ppk (for PuTTY, Windows)
5. Click Create key pair
6. Important: Download the private key file immediately - you cannot download it again!

Option 2: Use Existing SSH Key

If you already have an SSH key pair, you can import the public key:

1. Go to EC2 → Key Pairs → Import key pair
2. Paste your public key content
3. Enter a name and click Import key pair

Selecting Key Pair When Launching an Instance

When you launch an EC2 instance, you must select a key pair:

1. Go to EC2 → Instances → Launch instance
2. Configure your instance (AMI, instance type, etc.)
3. In the Key pair (login) section, select your key pair from the dropdown
4. If you don’t have a key pair yet, click Create new key pair to create one
5. Continue with the instance launch

Important: You cannot connect to a Linux instance via SSH without a key pair. If you launch an instance without selecting a key pair, you won’t be able to SSH into it later. You’ll need to terminate it and launch a new one with a key pair.

Connecting to EC2 Instance via SSH

Prerequisites:

• EC2 instance is running
• Security group allows inbound SSH (port 22) from your IP
• You have the private key file (.pem) downloaded

Steps:

1. Locate your private key file (e.g., my-ec2-key.pem)

2. Set correct permissions (Linux/Mac only):

   chmod 400 my-ec2-key.pem
   

3. Connect using SSH:

   ssh -i my-ec2-key.pem ec2-user@[public-ip]
   

The default username is ec2-user for Amazon Linux and ubuntu for Ubuntu. For other Linux distributions, check the AWS documentation.

EC2 Instance Connect

EC2 Instance Connect is handy - you can connect to your instance directly from the AWS Console. No need to mess with SSH keys.

How it works:

• Uses temporary credentials (they last 60 seconds)
• No need to download or manage key files
• Just works from the browser

To connect:

1. Go to EC2 → Instances
2. Select your instance
3. Click Connect
4. Choose EC2 Instance Connect tab
5. Click Connect

EC2 Instance Connect is convenient for quick access, but SSH with key pairs is more secure for production use. Instance Connect requires the instance to have a public IP and the security group must allow SSH (port 22).

EC2 Instance Roles

Don’t put AWS access keys on your EC2 instance - that’s not safe. Instead, attach an IAM role to the instance. The instance gets temporary credentials automatically to access AWS services.

Why Use Instance Roles?

Without Instance Roles:

• You need to SSH into the instance
• Run aws configure and provide access key and secret key
• Store credentials on the instance (security risk)
• Manually rotate keys when needed

With Instance Roles:

• No need to store credentials on the instance
• Automatic credential rotation
• Temporary credentials (more secure)
• No manual configuration needed

Example: Creating an Instance Role

Here’s how I create a role that lets the EC2 instance read IAM users:

1. Create IAM Role:
   • Go to IAM → Roles → Create role
   • Select AWS service → EC2
   • Click Next
2. Attach Permissions:
   • Search for IAMReadOnlyAccess and select it
   • Click Next
3. Name the Role:
   • Role name: EC2-IAM-ReadOnly-Role
   • Click Create role
4. Attach Role to EC2 Instance:
   • Go to EC2 → Instances
   • Select your instance
   • Click Actions → Security → Modify IAM role
   • Select EC2-IAM-ReadOnly-Role
   • Click Update IAM role

Testing the Role

Without a role attached, if you try to run AWS CLI commands, you’ll get an error:

$ aws iam list-users
Unable to locate credentials. You can configure credentials by running "aws configure".

After attaching the role, SSH into your instance and run:

aws iam list-users

The command will work automatically without any aws configure or credentials. The instance uses temporary credentials from the attached role.

Instance roles use IMDS (Instance Metadata Service) to give temporary credentials. These credentials rotate automatically and never get stored on disk, so they’re much safer than static access keys.

EC2 Instance Purchase Options

When you launch an EC2 instance, you’ll see different ways to pay. Each one has different prices and works better for different situations. Let me explain what I learned about them.

Purchase Options Summary

Option	Discount	Commitment	Interruption Risk	Best For
On-Demand	None	None	None	Short-term, unpredictable workloads
Reserved Instances	Up to 72%	1-3 years	None	Steady-state, predictable workloads
Spot Instances	Up to 90%	None	High (2-min notice)	Fault-tolerant, flexible workloads
Savings Plans	Up to 72%	1-3 years	None	Flexible usage across EC2/Lambda/Fargate
Dedicated Instances	None	None	None	Compliance requiring physical isolation
Dedicated Hosts	None	None	None	Licensing requiring physical server control

On-Demand Instances

On-Demand is like “pay-as-you-go”. You pay by the hour (or second) with no upfront costs. No commitment, you can stop anytime.

When to use:

• You’re testing a new application and don’t know how long you’ll need it
• Your traffic is unpredictable (e.g., a new product launch)
• You need instances for short-term projects
• Your application can’t tolerate interruptions

Example scenario: You’re building a prototype and need a few instances for a week. You don’t want to commit to a year, so On-Demand is perfect. When you’re done, you just stop the instances.

Reserved Instances

Reserved Instances are like a subscription. You commit to using an instance for 1-3 years, and AWS gives you a discount (up to 72% off).

The catch: You save money, but you’re stuck. If you don’t need it anymore, you still pay for it.

Payment options:

• All Upfront: Pay everything now, get the biggest discount
• Partial Upfront: Pay some now, rest monthly (middle ground)
• No Upfront: Pay monthly (smallest discount, but no upfront cost)

When to use:

• You have a production database that runs 24/7
• Your application has steady, predictable traffic
• You know you’ll need the instance for at least a year

Example scenario: Your web application runs on 4 instances constantly. Instead of paying On-Demand prices, you reserve them for 1 year with All Upfront payment. You save 40-50% compared to On-Demand.

Reserved Instances make sense when you know how much you’ll use. If you’re not sure, start with On-Demand and you can convert to Reserved later.

Spot Instances

Spot Instances are AWS selling unused capacity at a huge discount (up to 90% off). The problem? AWS can take them back with just 2 minutes warning when they need the capacity.

How it works: You set a maximum price you’re willing to pay. If the current Spot price is below your max, you get the instance. If AWS needs the capacity back, they give you a 2-minute warning and terminate your instance.

Checking Spot prices: Before you request Spot Instances, check the pricing history. Go to EC2 → Spot Requests → Pricing History to see what prices were like before. This helps you set a good maximum price.

When to use:

• You’re running batch jobs that can be restarted
• You’re doing data analysis that can handle interruptions
• You have fault-tolerant applications
• Cost is more important than guaranteed availability

Example scenario: You need to process 1000 hours of video. It doesn’t matter if it takes 10 hours or 12 hours, and if an instance gets interrupted, you can restart the job. Spot Instances can save you 70-90% compared to On-Demand.

Persistent vs One-time requests:

• One-time: Request is fulfilled once. If the instance gets interrupted, it’s gone. You need to create a new request manually.
• Persistent: Request stays active. If the instance gets interrupted, AWS automatically launches a new one when capacity is available again. You don’t need to do anything.

So yes, if you choose persistent when creating a Spot Instance, AWS will automatically replace it with a new VM when it gets interrupted (as long as capacity is available at your max price).

Spot Instances are great for cost savings, but your application must handle interruptions gracefully. With persistent requests, AWS automatically replaces interrupted instances, so you don’t need to manually create new ones.

Spot Fleet

Spot Fleet is basically a service that automatically manages a group of Spot Instances. You just say “I need 10 instances” and it handles the rest.

How it works:

• You set a target capacity (like 10 instances)
• Spot Fleet automatically creates Spot Instances using different instance types and AZs
• If an instance gets interrupted, it automatically creates a new one
• You can mix Spot and On-Demand if you want (for guaranteed capacity)

Why use it:

• Diversification: Uses different instance types and AZs, reduces interruption risk
• Automatic replacement: If an instance gets interrupted, you don’t need to do anything, it handles it
• Cost optimization: Automatically picks the cheapest combination
• Flexible: Can use multiple instance types, sizes, and AZs

When to use:

• Large batch jobs
• Data analysis work
• CI/CD pipelines
• Video/image processing
• Basically, any work that can handle interruptions

Example: You need 20 instances to process a large dataset. Instead of manually managing 20 Spot Instances, you create a Spot Fleet and say “I need 20 instances”. Spot Fleet automatically:

• Picks different instance types (m5.large, m5.xlarge, c5.large, etc.)
• Spreads them across different AZs
• Replaces interrupted instances automatically
• Picks the cheapest combination

Spot Fleet is ideal when you need multiple Spot Instances and want AWS to manage the complexity of diversification and replacement. It’s more cost-effective and reliable than manually managing individual Spot Instances.

Spot Instance vs Spot Fleet

There are two ways to create Spot Instances:

Creating one by one from EC2:

• Go to EC2 → Launch instance → Purchase options → Request Spot Instances
• You choose one instance type (like m5.large)
• You choose one Availability Zone
• If the instance gets interrupted, you need to manually create a new one
• Good for simple tasks, ideal for single instances

Using Spot Fleet:

• You create a Spot Fleet and say “I need 10 instances”
• Spot Fleet automatically picks different instance types (m5.large, m5.xlarge, c5.large, etc.)
• It spreads them across different Availability Zones
• If an instance gets interrupted, it automatically creates a new one
• Much better for multiple instances

What’s the difference? Spot Instance is manual, one by one. Spot Fleet is automatic, manages multiple instances and handles interruptions automatically.

Creating a Spot Fleet

Step 1: Create Spot Fleet Request

1. Go to EC2 → Spot Requests → Spot Fleet
2. Click Create Spot Fleet

Step 2: Configure Fleet Composition

• Target capacity: Set how many instances you want (e.g., 10)
• On-Demand vs Spot: Choose the mix
  • 100% Spot: Maximum savings, higher interruption risk
  • Mix: Some On-Demand for guaranteed capacity, rest Spot for savings
• Instance types: Add multiple instance types (e.g., m5.large, m5.xlarge, c5.large)
  • Spot Fleet will choose the cheapest combination to meet your target

Step 3: Configure Launch Specifications For each instance type:

• Select AMI
• Choose instance type
• Select key pair
• Configure security groups
• Set maximum price (or use On-Demand price)

Step 4: Set Allocation Strategy

• LowestPrice: Fulfill capacity from the lowest-priced pools (can concentrate in one AZ)
• Diversified: Distribute across all pools (better for availability)
• CapacityOptimized: Launch from pools with optimal capacity (best for interruption risk)

Step 5: Review and Create

1. Review your configuration
2. Click Create Spot Fleet
3. Spot Fleet will start requesting instances to meet your target capacity

Important: Spot Fleet handles everything automatically. If instances get interrupted, it replaces them. You can change the target capacity anytime, and Spot Fleet will adjust.

Savings Plans

Savings Plans are like Reserved Instances but more flexible. You commit to spending a certain amount per hour for 1-3 years, and you get discounts on EC2, Lambda, and Fargate.

The good part: Unlike Reserved Instances, you can change instance types, families, regions, or even switch between EC2, Lambda, and Fargate. You just need to meet your hourly spending commitment.

When to use:

• You want Reserved Instance discounts but need flexibility
• You use multiple AWS compute services (EC2, Lambda, Fargate)
• Your needs might change, but you still want to save money

Example scenario: You commit to $10/hour for 1 year. You can use any combination of EC2 instances, Lambda functions, or Fargate tasks - as long as your total compute spending averages $10/hour. This gives you flexibility while still saving 40-72% compared to On-Demand.

Savings Plans are usually easier to manage than Reserved Instances because you don’t need to worry about matching instance types. Just meet your spending commitment.

Dedicated Instances vs Dedicated Hosts

Both give you physical isolation, but they’re different:

Dedicated Instances:

• Your instances run on hardware dedicated to you
• No visibility: You can’t see which physical server your instance is on
• AWS manages placement: AWS decides which physical server to use
• Lower cost: Cheaper than Dedicated Hosts
• Use case: You need isolation but don’t need to control physical placement

Dedicated Hosts:

• A physical server fully dedicated to you
• Full visibility: You can see sockets, cores, and hypervisor details
• You control placement: You decide which instances run on which host
• Higher cost: More expensive than Dedicated Instances
• Use case: You need to meet licensing requirements (e.g., Windows Server licenses bound to physical servers)

Key difference: Dedicated Instances give you isolation without control. Dedicated Hosts give you both isolation and full control over physical placement.

When to use Dedicated Instances:

• You need physical isolation for compliance
• You don’t need to see or control physical server placement
• Cost is a concern

When to use Dedicated Hosts:

• You have software licenses tied to physical servers (BYOL - Bring Your Own License)
• You need to see and control which instances run on which physical server
• You need to meet strict compliance requirements

Example scenario: Your company has Windows Server licenses that require physical server binding. With Dedicated Hosts, you can see exactly which physical server your instances run on and use your existing licenses. With Dedicated Instances, you get isolation but can’t see the physical server, so you can’t use server-bound licenses.

Most apps don’t need dedicated hardware. Only use it when you have specific compliance or licensing requirements.

Price Comparison Example

Let me compare prices for an m5.large instance (2 vCPUs, 8 GB RAM) in US East (N. Virginia) to show you the cost differences:

Purchase Option	Hourly Cost (approx.)	Monthly Cost (approx.)	Annual Cost (approx.)	Savings vs On-Demand
On-Demand	$0.096	~$70	~$840	Baseline
Reserved 1yr - All Upfront	$0.053	~$39	~$465	~45% savings
Reserved 1yr - Partial Upfront	$0.058	~$42	~$505	~40% savings
Reserved 1yr - No Upfront	$0.063	~$46	~$550	~35% savings
Reserved 3yr - All Upfront	$0.031	~$23	~$270	~68% savings
Reserved 3yr - Partial Upfront	$0.035	~$26	~$305	~64% savings
Reserved 3yr - No Upfront	$0.040	~$29	~$350	~58% savings
Spot (average)	$0.029	~$21	~$250	~70% savings
Savings Plans (1yr)	$0.053	~$39	~$465	~45% savings

Note: Prices are approximate and change by region, instance type, and time. Spot prices go up and down based on demand. All Upfront gives the biggest discount but you pay everything upfront. No Upfront has the smallest discount but no upfront payment. Always check current AWS pricing for accurate costs.

Creating a Spot Fleet - Step by Step Example

Here’s how I create a Spot Fleet step by step:

Step 1: Check Spot Pricing History

1. Go to EC2 → Spot Requests → Pricing History
2. Look at different instance types (e.g., m5.large, m5.xlarge, c5.large)
3. Check different Availability Zones
4. Note the prices - this helps you understand what to expect

Step 2: Create Spot Fleet Request

1. Go to EC2 → Spot Requests → Spot Fleet
2. Click Create Spot Fleet

Step 3: Configure Fleet Composition

• Target capacity: Set how many instances you want (e.g., 10)
• On-Demand vs Spot: Choose the mix
  • 100% Spot: Maximum savings, but higher interruption risk
  • Mix: Some On-Demand for guaranteed capacity, rest Spot for savings
• Instance types: Add multiple instance types (e.g., m5.large, m5.xlarge, c5.large)
  • Spot Fleet will pick the cheapest combination to meet your target

Step 4: Configure Launch Specifications For each instance type you added:

• Select AMI (e.g., Amazon Linux)
• Choose instance type
• Select key pair
• Configure security groups
• Set maximum price (or use On-Demand price)

Step 5: Set Allocation Strategy

• LowestPrice: Gets instances from the cheapest pools (might put them all in one AZ)
• Diversified: Spreads across all pools (better for availability)
• CapacityOptimized: Launches from pools with best capacity (best for avoiding interruptions)

Step 6: Review and Create

1. Review everything
2. Click Create Spot Fleet
3. Spot Fleet starts requesting instances to meet your target capacity

Important things to know:

• Spot Fleet manages everything automatically. If instances get interrupted, it replaces them.
• You can change the target capacity anytime, and Spot Fleet will adjust.
• Spot Fleet picks the cheapest combination of instances to meet your target, so you save money.
• Using multiple instance types and AZs reduces the chance of all instances getting interrupted at once.

Spot Fleet is great when you need multiple instances. It handles all the complexity for you - diversification, replacement, cost optimization. Much easier than managing individual Spot Instances.

IP Addresses in EC2

When I create an EC2 instance, it gets IP addresses. There are three types I need to remember: private IP, public IP, and Elastic IP.

IP Type	Changes?	Cost	Use Case
Private IP	Changes on stop/start	Free	Internal communication between instances
Public IP	Changes on stop/start	Free	Internet access, SSH, downloads
Elastic IP	Stays the same	Free if attached to running instance, costs money if unused	Fixed IP for DNS, keep IP after restart

Private IP

Every instance gets a private IP automatically. This one:

• Stays with the instance while it’s running
• Only works inside the VPC (can’t reach it from internet)
• Good for instances talking to each other (like web server to database)
• Changes when you stop and start the instance

Used for internal communication between instances (e.g., web server to database).

Public IP

A public IP lets your instance talk to the internet. This one:

• Gets assigned automatically when you launch (if you enable it)
• Changes every time you stop and start the instance
• Only works if your instance is in a public subnet
• Free, but not permanent

I use this when I need to SSH into my instance or when the instance needs to download stuff from the internet.

You can turn off public IP when launching if you don’t need internet access. More secure for instances that only talk to other instances.

Elastic IP

Elastic IP is a static public IP that doesn’t change. This one:

• Stays the same even when you stop and start the instance
• You can move it from one instance to another

The money part:

• Free if it’s attached to a running instance
• Costs money (about $0.005 per hour) if it’s not attached or attached to a stopped instance

Important: You can attach multiple Elastic IPs to one instance, but only the first one is free. If you attach 3 Elastic IPs to a running instance, the first one is free, but the other 2 will cost you money (about $0.005 per hour each). Same goes for unused Elastic IPs - they cost money too.

I use this when:

• My app needs a fixed IP (like DNS pointing to it)
• I want to keep the same IP after restarting
• I need to quickly move the IP to a different instance

How to create and use:

1. Go to EC2 → Network & Security → Elastic IPs → Allocate Elastic IP address
2. Click Allocate
3. Select the Elastic IP → Actions → Associate Elastic IP address
4. Choose Resource type:
   • Instance: Most common - attach to instance’s primary network interface
   • Network interface: For multiple ENIs or unattached ENIs
5. Depending on what you chose:
   • If you picked Instance: Select your instance from the list
   • If you picked Network interface: Select the network interface from the list
6. If the Elastic IP is already attached to another resource, you’ll see a checkbox: “Allow this Elastic IP address to be reassociated”. Check this if you want to move it directly to the new resource (it will automatically disassociate from the old one). If you don’t check it, you need to disassociate it first.
7. Click Associate

Important notes:

• If you attach a new Elastic IP to an instance that already has one, the old one gets disassociated automatically. But it stays allocated to your account, so check your Elastic IPs list and release the ones you’re not using to avoid charges.
• If your instance has multiple private IPs, you can choose which one to associate the Elastic IP with. If you don’t pick one, it goes to the primary private IP (which is usually fine).

When I don’t need it anymore: If it’s attached to an instance, I first disassociate it. Then I select the Elastic IP → Actions → Release Elastic IP addresses → Release. This stops the charges.

Placement Groups

Placement groups control where AWS places your EC2 instances. Sometimes you want instances close together (for low latency), sometimes you want them far apart (for fault tolerance). That’s what placement groups are for.

For detailed information, check the AWS documentation on placement strategies.

Placement Group Type	Use Case	Limits	Availability Zones
Cluster	Low latency, high throughput (HPC, big data)	Same AZ only, same instance type recommended	Single AZ
Partition	Large distributed systems (HDFS, Cassandra)	Up to 7 partitions per AZ, 100s of instances	Multiple AZs
Spread	Critical applications, small clusters	Max 7 instances per AZ, not for Dedicated Instances	Multiple AZs

How to create and use:

1. Create the placement group first:
   • Go to EC2 → Network & Security → Placement Groups → Create placement group
   • Give it a name
   • Choose the placement strategy: Cluster, Partition, or Spread
   • Click Create placement group
2. When launching an instance:
   • During instance launch, go to Advanced details section (scroll down)
   • Find Placement group dropdown
   • Select your placement group from the list
   • For Partition placement groups, you can also specify a partition number (1-7) if you want a specific partition

That’s it. The instance will be placed according to the placement group strategy you chose.

Cluster Placement Group

Puts all instances in the same AZ, close together for low latency and high throughput.

When to use: HPC, big data (Hadoop, Spark), applications needing maximum network performance.

Key points:

• Single AZ only
• Same instance type recommended (can mix but not recommended)
• Launch all instances at once to avoid capacity errors
• Up to 10 Gbps network speed (with enhanced networking)
• Not supported: T2 (burstable), Mac1, M7i-flex

Partition Placement Group

Divides instances into logical partitions. Each partition is isolated - if one fails, others keep running.

When to use: Large distributed systems (HDFS, HBase, Cassandra), hundreds of instances needing logical separation.

Key points:

• Up to 7 partitions per AZ
• Can span multiple AZs (unlike Cluster)
• Can mix instance types
• Can add instances to existing partitions
• With Dedicated Instances: max 2 partitions (instead of 7)
• Can specify partition number (1-7) when launching

Spread Placement Group

Each instance on completely separate hardware (own rack). Maximum fault tolerance.

When to use: Critical applications, small clusters (2-3 instances), production databases (primary/standby).

Key points:

• Max 7 instances per AZ (21 total in 3 AZs)
• Can span multiple AZs
• Can mix instance types
• Not supported for Dedicated Instances
• If one instance fails, others unaffected

Which One Should I Use?

Cluster → Need maximum performance and low latency? Same AZ is fine? Use Cluster.

Partition → Have a big distributed system? Need logical separation? Use Partition.

Spread → Have a small critical application? Need maximum fault tolerance? Use Spread.

Things to remember:

• Can’t change placement group type after creating it
• Can’t move instances between placement groups
• If capacity error: try launching all at once (Cluster) or try again later
• Placement groups are free
• Capacity Reservations: work with Cluster, don’t work with Partition/Spread

Elastic Network Interface (ENI)

An ENI is a virtual network interface that you can attach to an EC2 instance. Think of it as a network card for your instance.

What it does:

• Gives your instance network connectivity
• Can have multiple IP addresses (primary + secondary)
• Can attach/detach from instances (even while running)
• Can move between instances in the same AZ

When to use it:

• Need multiple IP addresses on one instance
• Want to separate network traffic (management vs data)
• Building high availability setups (failover scenarios)
• Network appliances (firewalls, load balancers)
• Need to keep the same IP when replacing an instance

Key concepts:

Primary ENI:

• Created automatically when you launch an instance
• Can’t detach it (it’s tied to the instance)
• Gets deleted when instance terminates
• Has the primary private IP

Secondary ENI:

• You create and attach manually
• Can attach/detach while instance is running
• Can move to different instances (same AZ)
• Useful for multiple IPs or network separation

ENI features:

• Multiple IPs: One primary private IP, can add secondary private IPs
• Elastic IP: Can attach Elastic IP to any private IP on the ENI
• Security Groups: Each ENI can have its own security group
• MAC Address: Each ENI has a unique MAC address
• Source/Dest Check: Enabled by default (instance must be source/dest of traffic). Disable for NAT instances, load balancers, etc.

Limits:

• Instance type determines max ENIs per instance (check AWS docs)
• Example: t3.micro = 2 ENIs, m5.large = 3 ENIs, c5n.18xlarge = 15 ENIs
• Max 50 secondary private IPs per ENI (varies by instance type)

How to use:

1. Create an ENI:
   • Go to EC2 → Network & Security → Network Interfaces → Create network interface
   • Select subnet, security group, private IP (optional)
   • Click Create network interface
2. Attach to instance:
   • Select ENI → Actions → Attach
   • Choose instance (must be in same AZ)
   • Can attach while instance is running
3. Detach from instance:
   • Select ENI → Actions → Detach
   • ENI stays available, can attach to another instance

Important notes:

• ENI must be in same AZ as instance
• Can attach Elastic IP to ENI (not just instance)
• When instance terminates, primary ENI is deleted, secondary ENIs are detached (not deleted)
• Disable source/dest check for NAT instances, transparent proxies, etc.
• ENI keeps its configuration (IPs, security groups) when moved between instances

EC2 Hibernate

Hibernate saves the instance’s RAM to disk (EBS) before stopping. When you start it again, it restores everything exactly as it was - running processes, open files, network connections, etc.

What’s the difference?

Stop/Start:

• RAM is lost
• Instance reboots (fresh start)
• Takes longer to start
• Applications need to restart

Hibernate:

• RAM is saved to EBS
• Instance resumes exactly where it left off
• Faster startup (no reboot)
• Applications continue running

When to use it:

• Long-running applications that take time to start
• Applications with complex state that’s hard to restore
• Development/test environments (pause work, resume later)
• Cost savings: stop instances but keep state

Requirements:

• Instance type: C3, C4, C5, M3, M4, M5, R3, R4, R5 (and newer generations)
• Instance size: Not supported for bare metal instances
• Root volume: Must be EBS (not instance store)
• Root volume size: Must be at least RAM size + OS and applications space
  • Example: 4 GB RAM instance needs root volume with at least 4 GB free space for RAM + space for OS/apps
  • AWS recommends: RAM size + enough space for your OS and applications
  • If root volume is full, hibernate will fail
• AMI: Must be Amazon Linux 2, Ubuntu 16.04+, or Windows Server 2016+
• RAM: Max 150 GB RAM (for the instance)
• Encryption: Root volume must be encrypted (RAM contents are saved to disk, so encryption is required)

How to enable:

1. When launching:
   • First, enable EBS encryption for root volume:
     • Go to Storage section
     • Under root volume, check Encrypt this volume (or use encrypted AMI)
     • Or enable account-level default encryption (all new volumes encrypted automatically)
   • Then go to Advanced details section
   • Find Stop - Hibernate behavior
   • Select Enable
2. On existing instance:
   • Can’t enable hibernate on running instance
   • Must create new instance with:
     • Encrypted root volume (check “Encrypt this volume” or use encrypted AMI)
     • Hibernate enabled in Advanced details

How to use:

• Hibernate: EC2 Console → Select instance → Instance state → Stop and hibernate
• Resume: EC2 Console → Select instance → Instance state → Start

How to test it:

1. SSH into your instance and check uptime:

   uptime
   

   Note the uptime (e.g., “up 2 hours, 15 minutes”)

2. Hibernate the instance:
   • EC2 Console → Select instance → Instance state → Stop and hibernate
   • Wait a few minutes
3. Start the instance and check uptime again:
   • EC2 Console → Instance state → Start
   • Wait for running, then SSH back in

     uptime
     

Result:

• If hibernate worked: Uptime continues from before (e.g., “up 2 hours, 20 minutes”) - no reboot happened
• If it was regular stop/start: Uptime resets (e.g., “up 2 minutes”) - instance rebooted

That’s the easiest way to verify hibernate worked - uptime doesn’t reset because there’s no reboot.

Important notes:

• Hibernate takes a few minutes (saving RAM to disk)
• Resume is faster than regular start (no reboot)
• Charges: You pay for EBS storage while hibernated (not compute)
• Limitations: Can’t hibernate if root volume is full, can’t hibernate Spot Instances
• Data: RAM contents saved to root volume, so make sure you have enough space
• Security: Root volume must be encrypted, so RAM contents are always encrypted when saved
• Networking: Private IP can change after hibernate (unless using Elastic IP)