Skip to main content
This lesson covers Amazon EC2 (Elastic Compute Cloud) — AWS’s core virtual server service. EC2 provides on‑demand, resizable compute capacity so you can run applications without managing physical hardware. In the client–server model, clients (browsers, mobile apps, other services) send requests to a server, which executes code and returns data or pages. EC2 instances are the virtual servers that host those applications. Before cloud computing, provisioning servers required buying hardware, installing an OS, and performing ongoing maintenance (hardware replacement, OS patching, etc.). EC2 virtualizes the underlying physical host and exposes configurable instance sizes and types so you pick the right balance of CPU, memory, storage, and networking for your workload.

​
EC2 instance types

EC2 instance types are grouped by workload characteristics (compute, memory, storage, GPU). Choose an instance type based on your application’s resource profile.
A slide titled "EC2 Instance Types" showing five labeled columns (01–05). Each column lists a category with an icon: General Purpose, Compute Optimized, Memory Optimized, Storage Optimized, and GPU Instances.
  • General purpose: balanced CPU, memory, and networking — ideal for web servers and general applications.
  • Compute‑optimized: high CPU performance for compute‑bound workloads (batch processing, HPC).
  • Memory‑optimized: large RAM for in‑memory databases and analytics.
  • Storage‑optimized: high I/O throughput/IOPS for databases and heavy disk workloads.
  • GPU instances: GPU acceleration for machine learning, simulations, and graphics.
Table — quick instance type guide:

​
AMI (Amazon Machine Image)

An AMI is the template used to launch an EC2 instance — it defines the operating system, initial software, and boot configuration. Treat an AMI as a blueprint that you select or create to standardize instance provisioning.
  • Choose an AMI when launching an instance; it determines the OS (Amazon Linux, Ubuntu, Windows, etc.).
  • AMIs can include preinstalled packages and configuration so instances are ready at boot.
  • Create a custom AMI from a configured instance to capture that instance’s state for future launches.
Common AMI sharing levels:
A presentation slide titled "Types of AMI" showing three orange square icons. Each icon is labeled underneath as Public AMI, Private AMI, and Shared AMI.
With a single AMI you can launch many identical instances:
A simple EC2 diagram showing an Amazon Machine Image (AMI) on the left. Arrows connect the AMI to three compute instance icons on the right labeled Instance 1, Instance 2, and Instance 3.
You can capture an instance’s configuration (installed packages, users, firewall rules) by creating an AMI from that instance; use it to replicate the configuration reliably.

​
Connecting to EC2 (SSH / RDP)

Linux instances: connect via SSH using an EC2 key pair (public key on the instance, private key you store locally). Windows instances: use RDP; the Administrator password is encrypted and retrieved via the key pair. Example SSH command (Linux/macOS or Git Bash):
Notes:
  • Default usernames differ by AMI: ec2-user (Amazon Linux), ubuntu (Ubuntu), centos (CentOS).
  • Protect your private key and set permissions (e.g., chmod 400 key.pem).
  • For Windows instances, download the encrypted admin password and decrypt it with the private key before connecting via RDP.
A diagram showing SSH public/private key authentication for an Amazon EC2 instance: a user with a private key on the left and an EC2 instance with the public key on the right, connected by bidirectional SSH arrows.

​
EC2 instance lifecycle

An instance transitions through states during its lifecycle. Understanding these states helps with cost, availability, and automation:
  • Pending — instance is launching.
  • Running — instance is active and reachable.
  • Stopping — instance is preparing to stop.
  • Stopped — instance is shut down and not accepting connections. (EBS-backed instances stop and retain volume data; instance-store volumes cannot be stopped.)
  • Shutting‑down — instance is being terminated.
  • Terminated — instance is permanently deleted and cannot be recovered.
A flowchart titled "EC2 Instance Lifecycle" showing colored boxes for states (Pending, Running, Stopping, Stopped, Shutting Down, Terminated) with arrows and labels for transitions like Launch, Start, Stop, and Terminate. The diagram illustrates how an EC2 instance moves between those states.
Tip: For EBS-backed instances you are not billed for compute while the instance is stopped, but attached EBS volumes continue to incur storage charges.

​
User Data (bootstrap)

When launching an instance you can provide user data (shell scripts or cloud‑init directives) that run at boot. Use this to bootstrap instances automatically:
  • Install packages and dependencies
  • Configure services, users, and firewall rules
  • Pull application code and start services
Limits and considerations:
  • User data size limit: 16 KB
  • By default, user data runs on first boot; you can configure cloud‑init to run it on every boot if required.
A simple diagram titled "User Data" showing a user icon sending a "Bootstrap Script" (document icon) to an Amazon EC2 instance (chip icon). An arrow indicates the transfer of the script from the user to the EC2 instance.

​
Security groups

Security groups are virtual firewalls attached to instances that control inbound and outbound traffic by protocol, port range, and source/destination. Best practice examples:
  • Web server: allow inbound TCP 80 (HTTP) and 443 (HTTPS); restrict SSH (22) to trusted IPs.
  • Application tier: allow only necessary ports from internal subnets or load balancer security group.
A simple diagram titled "EC2 With Security Group" showing a user on the left exchanging inbound and outbound traffic with an Amazon EC2 instance on the right. The EC2 instance sits inside a VPC and is protected by a security group (illustrated with a padlock).

​
Storage: EBS and snapshots

EC2 instances commonly use EBS (Elastic Block Store) for persistent block storage. EBS volumes attach to instances and persist independently of instance lifecycle (unless configured for deletion on termination).
  • Use cases: OS boot volumes, databases, file systems, and backups.
  • EBS snapshots: incremental, point‑in‑time backups stored in Amazon S3 behind the scenes. Only changed blocks are saved after the first snapshot, which minimizes storage costs.
EBS volumes are network‑attached, persistent block storage. Instance store (ephemeral) volumes lose data when an instance stops or terminates — use EBS for persistent data and snapshots for backups.
A simplified AWS architecture diagram titled "EC2 With EBS" showing a region and VPC containing two availability zones, each with EC2 instances and attached EBS volumes. To the right are EBS snapshot icons representing backups.

​
Load balancing and Auto Scaling

Combine EC2 with Elastic Load Balancing (ELB) to distribute traffic across instances and Availability Zones. Auto Scaling Groups (ASG) automatically add or remove instances based on demand, health checks, or schedules. Benefits:
  • High availability across AZs
  • Fault tolerance for instance failures
  • Cost optimization by scaling to demand
An AWS architecture diagram titled "EC2 With ELB and AS" showing users sending HTTP requests to an Elastic Load Balancer/auto‑scaling front end that distributes traffic to EC2 instances across two subnets inside a VPC. Icons depict multiple instances in Subnet 1 and Subnet 2 with a central load balancer and autoscaling component.

​
Elastic IPs

Public IPs assigned at launch can change when an instance is stopped and started. An Elastic IP is a static IPv4 address allocated to your account — associate it to an instance to keep a stable public IP. You can disassociate and reassign it as needed.
A simple diagram titled "EC2 With Elastic IP" showing a user/developer icon sending a request and receiving a response to an Amazon EC2 instance, with the instance represented inside a green box labeled Elastic IP.

​
Launch templates

Use launch templates to capture and version instance launch configuration (AMI, instance type, key pair, security groups, user data, network settings, tags). Launch templates are reusable and are commonly used by Auto Scaling and automation scripts to ensure consistent instance configuration.
A diagram titled "EC2 Launch Template" showing a cloud professional creating a launch template. Arrows from the template point to and provision multiple AWS EC2 instances.

​
Placement options

Control how EC2 instances are placed on physical hardware within an Availability Zone using placement groups.
A diagram titled "EC2 Instance Placements" showing icons for EC2 instances arranged to illustrate three AWS placement group types. From left to right it shows Cluster (instances co-located in the same rack), Partition (instances divided into partitions) and Spread (instances spread across separate hardware).
Placement group types:

​
EC2 pricing and purchasing options

Select a pricing model based on workload predictability, fault tolerance, licensing, and cost goals.
A slide titled "EC2 Instance Purchasing Option" showing six colorful tiles labeled On Demand, Spot, Saving Plans, Reserved Instances, Dedicated Hosts, and Dedicated Instances, each with a simple icon.
Analogy reminders:
  • On‑Demand: pay full price when needed.
  • Spot: buy discounted spare capacity if you can tolerate interruptions.
  • Savings Plans / Reserved Instances: commit to save money over time.
  • Dedicated Hosts / Instances: physical isolation for licensing or compliance.

​
Final notes

  • Use AMIs and launch templates to standardize and accelerate instance provisioning.
  • Protect access with security groups and key pairs; restrict management ports to trusted sources.
  • Use EBS for persistent storage and incremental snapshots for backups.
  • Combine ELB and Auto Scaling for resilient, scalable architectures.
  • Choose placement and purchasing options that match latency, isolation, and cost constraints.
Remember: terminating an instance permanently deletes it (unless you created an AMI or snapshot first). Stopping an instance preserves attached EBS volumes (which continue to incur storage charges) but stops compute billing while the instance is stopped.

Watch Video