AWS EC2

EC2, short for Elastic Compute Cloud, is the service that lets you rent a virtual server from AWS. Where Lambda gives you a place to run code without thinking about servers at all, EC2 is the opposite end of the spectrum — you get an actual virtual machine, with a full operating system, that stays running until you stop it. This makes EC2 the right tool when you need something Lambda cannot easily provide: long-running processes, full control over the environment, specific software that needs to be installed persistently, or workloads that do not fit the short-lived, stateless model that serverless functions are built around.

Each EC2 server is called an instance. When you launch one, you choose an Amazon Machine Image, or AMI, which is essentially a template containing the operating system and any pre-installed software. AWS provides official AMIs for Amazon Linux, Ubuntu, Windows Server, and several other operating systems, and you can also create your own custom AMI once you have a server configured the way you want, so future instances can be launched already set up the same way.

Instances come in different sizes and families, referred to as instance types. A type like t3.micro tells you the family (t3, a general-purpose burstable type) and the size (micro, one of the smallest). Larger instance types have more CPU and memory, and cost proportionally more per hour. Choosing the right instance type is mostly about matching your workload's actual resource needs — an instance that is too small will struggle under load, while one that is too large wastes money on capacity you are not using.

Unlike Lambda, EC2 charges you for the instance the entire time it is running, whether or not it is actively doing anything. This is the fundamental tradeoff between the two services: EC2 gives you full control and persistence, but you pay for uptime rather than actual usage. Understanding this tradeoff is usually the deciding factor when choosing between EC2 and Lambda for a given project.

Launching an EC2 instance starts in the AWS Console under the EC2 service. You choose an AMI, select an instance type, configure networking, and choose or create a key pair for secure access. The key pair is important and easy to overlook the first time — it is a cryptographic key used to securely connect to your instance, and AWS only lets you download the private half of it once, at creation time. If you lose it, there is no way to recover it, and you would need to use a more involved recovery process to regain access to the instance.

Storage for an EC2 instance is provided through EBS, Elastic Block Store — think of it as a virtual hard drive attached to your instance. When you launch an instance, you choose the size and type of the root EBS volume that will hold the operating system and any data you store. EBS volumes persist independently of the instance's running state, meaning if you stop an instance (but do not terminate it), the data on its EBS volume remains intact and is there when you start it again.

Once your instance is running, you connect to it using SSH if it is a Linux-based AMI, or Remote Desktop Protocol if it is Windows. A typical SSH connection looks like this from a terminal:

The chmod command restricts the permissions on your private key file, which SSH requires before it will use the key — most SSH clients refuse to use a key file that is readable by other users on your system, as a basic security safeguard. The username in the SSH command depends on the AMI: ec2-user is standard for Amazon Linux, while ubuntu is standard for Ubuntu-based AMIs.

User data scripts are worth knowing about early. When launching an instance, you can provide a script that runs automatically the first time the instance boots, which is useful for automating setup — installing packages, pulling application code from a repository, or configuring services — without having to SSH in and do it manually every time you launch a new instance from the same configuration.

Security groups are the firewall that controls traffic to and from your EC2 instance. Every instance must be assigned at least one security group, and by default a new security group denies all inbound traffic while allowing all outbound traffic. This means, immediately after launching an instance, you typically cannot connect to it at all until you explicitly open the ports you need.

A security group rule specifies a protocol, a port range, and a source (for inbound rules) or destination (for outbound rules). For a typical web server, you would open port 22 for SSH access, restricted to your own IP address rather than the entire internet, and port 80 or 443 for HTTP or HTTPS traffic, open to everyone since that is the point of a public web server. Restricting SSH access to a specific IP address rather than leaving it open to 0.0.0.0/0, which means all of the internet, is one of the simplest and most important security practices for any EC2 instance.

Security groups are stateful, meaning if you allow inbound traffic on a port, the corresponding outbound response traffic is automatically allowed without needing a separate rule. This is different from Network ACLs, another layer of networking control in AWS that operates at the subnet level and is stateless — a more advanced topic that most projects do not need to touch directly, since security groups handle the vast majority of practical access control needs.

Instances live inside a VPC, a Virtual Private Cloud, which is your own isolated network within AWS. By default, AWS creates a default VPC in every region with public subnets already configured, which is enough for most simple projects. As your infrastructure grows more complex, you may eventually want to design a custom VPC with public and private subnets, but for a first EC2 instance, the default VPC is the right starting point and lets you focus on the application rather than networking architecture.

EC2 pricing is based primarily on the instance type and how many hours (or seconds, for most instance types) it runs. On-demand pricing, the default and simplest option, charges a fixed hourly rate for as long as the instance is running, with no upfront commitment. This is the right choice when you are experimenting, running short-lived workloads, or are not yet sure how much capacity you will need long-term.

For workloads you know will run continuously for a long period, Reserved Instances and Savings Plans offer significantly discounted rates — often 30 to 60 percent cheaper than on-demand — in exchange for committing to one or three years of usage. Spot Instances are another pricing option, offering steep discounts (sometimes 70 to 90 percent off on-demand pricing) in exchange for the possibility that AWS can reclaim the instance with only a short warning if capacity is needed elsewhere. Spot Instances are well suited to fault-tolerant workloads like batch processing, but not appropriate for anything that needs to run continuously without interruption.

The free tier includes 750 hours per month of a t2.micro or t3.micro instance (depending on region) for the first twelve months of a new AWS account. This is enough to run one small instance continuously for an entire month, which makes it a reasonable way to experiment with EC2 at no cost while you are learning, as long as you keep only one qualifying instance running and remember that the free tier applies only for the first year.

The most common mistake with EC2, by a wide margin, is forgetting that an instance is running. Unlike Lambda, which only costs money when actually invoked, an EC2 instance charges continuously from the moment it launches until you stop or terminate it, regardless of whether it is doing any useful work. Stopping an instance (rather than terminating it) halts compute charges but the attached EBS volume continues to incur its own storage cost, which is smaller but not zero. Getting into the habit of reviewing the EC2 console periodically for instances you forgot about, and setting a billing alarm as covered in the AWS Billing course, is the most effective protection against this kind of unnecessary spend.

EC2 pairs naturally with many other AWS services covered elsewhere in this collection — S3 for storing files the instance needs to read or write, IAM roles for granting the instance permission to call other AWS services without embedding credentials, and CloudWatch for monitoring CPU usage, memory, and custom application metrics. Once you understand EC2 on its own, connecting it to the rest of your AWS infrastructure becomes a matter of applying what you already know from the other courses in this series.