AWS EC2 Fundamentals — instances, security groups, pricing and networking

EC2: the fundamentals

EC2 (Elastic Compute Cloud) is AWS’s most popular service. It’s an IaaS (Infrastructure as a Service).

Its main capabilities:

• Rent virtual machines (EC2)
• Store data on virtual drives (EBS)
• Distribute load across multiple machines (ELB)
• Scale services with auto scaling (ASG)

Almost everything can be configured on an EC2 instance:

• The OS: macOS, Linux, Windows
• The CPU
• The RAM
• The network card (speed and public IP)
• Storage: network attached (EFS, EBS) or hardware (EC2 Instance Store)
• Firewall rules (Security Groups)
• The bootstrap script

Bootstrap script

The bootstrap script is a script that runs automatically when the EC2 instance launches.

• It only runs once, on the very first boot.
• Typically used to download updates, install software, fetch files from the internet — basically anything.
• This script runs as the root user.

Instance naming convention

AWS follows this naming convention. Example with m5.2xlarge:

• m = the instance class
• 5 = the instance generation
• 2xlarge = the instance size

EC2 instance types

There are several families of EC2 instances: Instance types

1. General Purpose

AWS’s Swiss Army knife. These instances offer a balance between compute, memory and networking.

• Main use: diverse workloads that don’t require extreme power in one specific area.
• Pros: very versatile, great for handling sudden performance spikes beyond baseline capacity.
• Cons: not the best choice for very heavy compute or massive databases.
• Examples: web servers, dev/test environments, small databases.

2. Compute Optimized

Built for tasks requiring high CPU power relative to RAM.

• Main use: intensive data processing, high-performance computing.
• Pros: very fast processors, optimized cost per compute unit.
• Cons: lack the RAM needed for applications that hold large amounts of data in memory during processing.
• Examples: video encoding, scientific modeling, high-performance game servers, batch processing.

3. Memory Optimized

Equipped with very large amounts of RAM to process in-memory workloads quickly.

• Main use: applications that need to load huge volumes of data into RAM.
• Pros: complex real-time data processing with minimal latency.
• Cons: generally more expensive per hour.
• Examples: in-memory databases (Redis), real-time Big Data, high-performance caches.

4. Storage Optimized

Designed for very fast access (read/write) to large volumes of locally stored data.

• Main use: tens of thousands of IOPS on local disk.
• Pros: very high sequential read/write speed on local SSDs.
• Cons: local storage (Instance Store) is often ephemeral — data is lost if the instance is stopped or fails.
• Examples: NoSQL databases (Cassandra, MongoDB), data warehousing, distributed file systems.

Security Groups

A Security Group is a virtual firewall that controls traffic to EC2 instances. Think of it as a bouncer at the server’s door, deciding who can come in or out.

Key characteristics

• Instance level: applies at the EC2 instance level (or its network interface), not at the subnet level.
• Stateful: if inbound traffic is allowed, the response is automatically allowed out, regardless of outbound rules.
• Allow rules only: you can only create ALLOW rules. Anything not explicitly allowed is denied by default.

Common use cases

Security Groups are used to segment the architecture following the least privilege principle:

• Public web access: allow inbound traffic on ports 80 (HTTP) and 443 (HTTPS) from any IP (0.0.0.0/0).
• Remote administration: allow port 22 (SSH) for Linux or 3389 (RDP) for Windows. Best practice: only allow your own public IP.
• Internal communication (chaining): configure the database’s Security Group to only accept traffic from the EC2 servers’ Security Group. Nobody on the internet touches the database directly.
• Verification and troubleshooting: use VPC Flow Logs to see which rules accept or reject traffic.

Summary

Characteristic	Behavior
Target	The EC2 instance itself
Rules	”Who” (IP/group), “which port” (80, 22), “which protocol” (TCP)
Memory	Stateful: what comes in can go back out without going through the bouncer again
Security	You can’t say “block this IP”, only “allow these ones”

For maximum security: restrict access to the strict minimum and chain Security Groups (load balancer allows the web, EC2 allows the load balancer, DB allows EC2).

My first EC2

Security groups: accept all connections from anywhere on ports 22 and 80. Any other connection on any other port is denied.

Connecting via SSH

To SSH into a created EC2 instance, use the pem key generated when the instance was created, with the ec2-user user:

ssh -i key.pem ec2-user@Public_IPv4_address

Don’t forget to chmod 600 the key on first use.

[!WARNING] If you get a connection timeout, it’s usually a Security Group issue. Any timeout (not just SSH) is related to Security Groups or a firewall. Check that the Security Group is properly configured and assigned to the instance.

If the timeout persists despite a correctly configured Security Group: it’s probably a corporate or personal firewall blocking the connection.

EC2 Instance Connect is another SSH connection method: you connect through the web console with just the IP and the user — a temporary key.pem is uploaded automatically. Obviously, if port 22 is blocked, the connection is impossible.

The AWS CLI is already installed on the Amazon Linux AMI.

[!DANGER] Never enter your AWS CLI credentials inside an EC2 instance — if someone gets access to the EC2, they get the CLI credentials too. Instead, attach an IAM role to the instance to give it credentials.

EC2 purchasing options

1. On-Demand Instances

   • Details: pay-as-you-go, no commitment. E.g. m4.large at ~10 cents/hour.
   • Pros: maximum flexibility, no interruption by AWS.
   • Cons: the most expensive option per hour.
   • Example: unpredictable workloads, testing or new projects.

2. Reserved Instances

   • Details: 1 or 3-year commitment. Types: Standard (large discounts) and Convertible (flexibility). Payment: All Upfront, Partial Upfront or No Upfront.
   • Pros: discounts up to 75% vs On-Demand.
   • Cons: long-term commitment (1 or 3 years).
   • Example: applications with stable, predictable load (production database).

3. Savings Plans

   • Details: commitment to an hourly usage amount ($/h). Types: Compute and EC2 Instance.
   • Pros: up to 66-72% savings, more flexible than Reserved Instances.
   • Cons: firm 1 or 3-year commitment; any overage billed at On-Demand rate.
   • Example: companies whose infrastructure evolves but whose compute consumption stays constant.

4. Spot Instances

   • Details: unused capacity at a variable price (up to 90% discount).
   • Pros: the cheapest option in the AWS cloud.
   • Cons: can be interrupted by AWS with 2 minutes’ notice.
   • Example: temporary or flexible tasks, batch processing, ML training, video rendering.

5. Dedicated Hosts

   • Details: physical servers reserved exclusively for you. Important for compliance and licensing (up to 70% discount on reservation).
   • Pros: lets you reuse existing software licenses (BYOL) tied to physical cores/sockets (SQL Server, Oracle).
   • Cons: more complex to manage and generally more expensive than shared instances.
   • Example: software with strict hardware licensing constraints.

6. Capacity Reservations

   • Details: guarantee capacity availability at the On-Demand rate.
   • Pros: guaranteed immediate launch in a specific AZ for critical workloads.
   • Cons: paid whether used or not; no automatic discount.
   • Example: disaster recovery plans, critical business events on a fixed date.

7. Dedicated Instances

   • Details: physical host-level isolation within a VPC.
   • Pros: complete hardware isolation (no host sharing).
   • Cons: no control over physical placement, no advanced BYOL.
   • Example: compliance needs requiring non-shared hardware.

Hotel analogy

• On-Demand: the standard nightly rate — a room without reservation, flexible but expensive.
• Reserved Instances: the seasonal lease — 1-3 year commitment, big discount.
• Savings Plans: the flexible loyalty credit — spend commitment, flexibility on room type/destination.
• Spot Instances: the last-minute flash sale — very low price, but possible eviction with 2 minutes’ notice.
• Dedicated Hosts: the private villa with your own furniture — full control, reusable licenses.
• Dedicated Instances: the hotel’s reserved wing — hardware isolation without precise placement choice.
• Capacity Reservations: the guarantee of having a room — availability guarantee, paid whether used or not.

Comparison table

Purchase option	Discount (estimated savings)	Commitment	Billing / characteristics
On-Demand	0% (base rate)	None	Pay per second/hour based on usage
Reserved Instances	Up to 75%	1 or 3 years	Large discount in exchange for a time commitment
Savings Plans	Up to 66-72%	1 or 3 years	Commitment to an hourly consumption amount
Spot Instances	Up to 90%	None	Unused capacity, very low variable price
Dedicated Hosts	Variable (up to 70%)	Optional	Cost per physical host, license reuse
Dedicated Instances	More expensive than On-Demand	None	Surcharge for physical hardware isolation
Capacity Reservations	0% (On-Demand rate)	None	On-Demand rate paid, launched or not

Key points for cost strategy

• Stable and predictable loads: favor Savings Plans or Reserved Instances. Savings Plans are often recommended for their superior flexibility (instance type, region) with a similar discount (~66%).
• Flexible, fault-tolerant loads: Spot Instances are the most cost-effective (up to 90%). Ideal for batch or ML training.
• New workloads: start with On-Demand to analyze needs before committing.
• Decision tools: AWS Compute Optimizer (ideal instance size) and AWS Cost Explorer (visualize potential savings).

IP addresses

1. Private IP addresses (Local IP)

Used for internal communication within the VPC.

• Usage: communication between resources (e.g. EC2 instances) within the same VPC or connected networks.
• Subnets: instances in a private subnet only use private IPs, not directly reachable from the internet.
• Exam tip: in a simple high-availability scenario, you can route traffic to a standby instance via its private IPv4 if the main application fails.

2. Public IP addresses

Needed for communication with the outside world (the internet).

• Usage: make an instance reachable from the internet, or access public services.
• Assignment: typically assigned dynamically in public subnets (with a route to an Internet Gateway).
• Limitation: a standard public IP is dynamic — it can change if the instance is stopped/restarted.

3. Elastic IP addresses (EIP)

An EIP is a static IPv4 address designed for dynamic cloud computing.

• Static nature: stays allocated to the AWS account until voluntarily released.
• Failover masking: a key exam concept — you can mask an instance failure by quickly remapping the EIP to another instance.
• Costs: small fees if the EIP is not associated with a running instance, or associated with a stopped instance. Free while used by an active EC2 instance.
• Exam tip: to keep a fixed IP across restarts, or quickly redirect traffic without changing DNS config, the answer is often Elastic IP.

Exam summary

Characteristic	Private IP	Standard public IP	Elastic IP (EIP)
Scope	Internal (VPC)	External (internet)	External (internet)
Persistence	Fixed for the interface’s lifetime	Changes on restart	Fixed until released
Use case	Security, internal communication	Temporary internet access	Fixed endpoints, failover
Subnet	Private or public	Public only	Public only

[!INFO] To let instances in a private subnet access the internet (updates, etc.) without a public or Elastic IP, use a NAT Gateway placed in a public subnet.

Placement Groups

A placement group is an AWS configuration rule defining how EC2 instances are physically laid out on data center hardware. Goal: maximize network throughput and reduce latency between servers, or guarantee fault tolerance by physically isolating machines.

1. Cluster Placement Group

• Description: physically groups instances on the same network segment, within a single AZ. Ultra-low latency, maximum network throughput.
• Pros: minimal inter-instance latency (microseconds), throughput up to 100 Gbps or more.
• Cons: limited to a single AZ, high risk of InsufficientInstanceCapacity error when adding instances later, risk of the whole group failing simultaneously.
• Critical points: launch all instances in a single RunInstances request; only supports certain instance types (c5, m5, r5, p3, i3…); impossible to merge two Cluster Placement Groups.
• Use case: HPC, financial modeling, scientific simulations, Big Data with intensive communication (MPI).

2. Partition Placement Group

• Description: splits instances into partitions, each with its own dedicated racks, switches and power.
• Pros: reduces the blast radius of failures, spans multiple AZs, supports thousands of instances with hardware isolation.
• Cons: slightly higher latency than Cluster mode.
• Critical points: maximum 7 partitions per AZ; cross-account sharing possible via AWS RAM; AWS provides partition metadata to guide data replicas.
• Use case: Cassandra, HBase, Kafka, Hadoop HDFS, MongoDB.

3. Spread Placement Group

• Description: spreads each instance across distinct physical hardware (separate rack, power, switch for each instance).
• Pros: maximum tolerance to hardware failures, spans multiple AZs.
• Cons: very strict limit on instances per AZ.
• Critical points: maximum 7 instances per AZ per group (3 AZs = 21 instances max); incompatible with Dedicated Hosts/Instances.
• Use case: HA database clusters (primary/secondary), domain controllers, Kubernetes master nodes, small critical instances.

⚠️ Rules common to all Placement Groups

1. A group’s name must be unique per account and per region.
2. To move an existing (stopped) instance into a group, use the CLI/API (aws ec2 modify-instance-placement).
3. Creating and using Placement Groups is 100% free — you only pay for the EC2 instances.
4. Impossible to merge multiple existing Placement Groups.
5. Mixing instance families is possible as long as they’re supported (same type recommended, especially for Cluster).

ENI (Elastic Network Interface)

1. Primary Network Interface (eth0)

• Description: network card created by default when the instance launches.
• Pros: automatic configuration.
• Cons: cannot be detached or transferred; deleted when the instance is terminated.
• Use case: basic network connection for any EC2 instance.

2. Secondary Network Interface (eth1, eth2…)

• Description: additional interface manually attached to an instance.
• Pros: independent of the instance (keeps its IPs/MAC if moved).
• Cons: sometimes requires advanced OS-level routing.
• Use case: failover/HA, isolated management networks, dual-homed appliances.

3. Requester-Managed ENI

• Description: interface automatically generated by AWS services within the VPC.
• Pros: lets serverless/managed services access private resources.
• Cons: locked, cannot be modified/deleted directly.
• Use case: VPC Endpoints (PrivateLink), Lambda in a VPC, RDS, Load Balancers.

⚠️ The 5 critical rules to remember

1. AZ rule: an ENI is tied to a subnet and can never change Availability Zone.
2. Instance quota: the number of ENIs and IPs per ENI depends on the EC2 instance type.
3. Firewalls/routers: if the instance routes traffic, you need to disable Source/Destination Check on the ENI.
4. Security: Security Groups apply to the ENI, not to the EC2 instance.
5. Persistence: secondary ENIs are not deleted when the instance is terminated, by default.