Amazon EC2 Explained: Instances, Types and Pricing

Amazon EC2 is where cloud computing on AWS started: rent a virtual server, by the second, and give it back when you are done. AWS describes it as providing on-demand, scalable computing capacity, where an instance is a virtual server in the AWS Cloud (EC2 docs: what is Amazon EC2).

A data engineer may rarely launch an instance by hand. EC2 still sits under much of the work: EMR clusters are EC2 instances, self-managed tools run on them, and many "which size?" and "why is the bill this high?" questions are EC2 questions. Knowing how to read an instance type and how the pricing options differ pays off quickly.

The parts of an instance

• Instance: the virtual server.
• AMI, Amazon Machine Image: the template it boots from, containing the operating system and software.
• Instance type: the hardware, a combination of CPU, memory, storage and network capacity.
• EBS volumes: persistent disks attached over the network.
• Instance store volumes: disks physically attached to the host, for temporary data. The guide is explicit that this data is deleted when you stop, hibernate or terminate the instance.
• Security group: the firewall around it.
• Key pair: the credentials for logging in.

The storage distinction matters for data work. Anything you need to keep goes on EBS or, better, in S3. Instance store is for scratch space such as shuffle and temporary files. S3 vs EBS vs EFS compares the storage options.

Reading an instance type

Names such as r5.4xlarge look cryptic and follow a strict pattern (EC2 docs: naming conventions):

• Series: the letter or letters at the start. m is general purpose, c compute optimized, r memory optimized, i storage optimized, t burstable.
• Generation: the number. Higher is newer.
• Options: letters after the number, such as g for AWS Graviton processors, a for AMD, d for instance store volumes, n for network optimised.
• Size: after the period, from nano up through xlarge multiples to metal.

The script below asks for the specifications of seven types and decodes each name. It runs against moto, a local emulator, so the figures are from the emulator's bundled instance data, and no instance is really launched.

import os, re
import boto3
from moto import mock_aws

os.environ.update(AWS_ACCESS_KEY_ID="testing", AWS_SECRET_ACCESS_KEY="testing",
                  AWS_DEFAULT_REGION="us-east-1")
SERIES = {"t": "burstable", "m": "general purpose", "c": "compute optimized", "r": "memory optimized",
          "i": "storage optimized", "g": "graphics / GPU"}


def explain(name):
    """Split an instance type name into series, generation, options and size."""
    family, size = name.split(".")
    series, generation, options = re.fullmatch(r"([a-z]+?)(\d+)([a-z]*)", family).groups()
    return f"{SERIES.get(series, series)}, generation {generation}" + (f", options '{options}'" if options else "") + f", size {size}"


@mock_aws
def main():
    ec2 = boto3.client("ec2")
    names = ["t3.micro", "m5.xlarge", "c5.xlarge", "r5.xlarge", "r5.4xlarge", "m6g.xlarge", "i3.xlarge"]
    types = {t["InstanceType"]: t for t in ec2.describe_instance_types(InstanceTypes=names)["InstanceTypes"]}
    print(f"{'type':11} {'vCPU':>4} {'memory':>8}  {'GiB per vCPU':>12}  reading the name")
    for name in names:
        t = types[name]
        vcpu, gib = t["VCpuInfo"]["DefaultVCpus"], t["MemoryInfo"]["SizeInMiB"] / 1024
        print(f"{name:11} {vcpu:>4} {gib:>5.1f} GiB  {gib / vcpu:>12.1f}  {explain(name)}")

    # Lifecycle: launch, stop, terminate
    image = ec2.describe_images(Owners=["amazon"])["Images"][0]["ImageId"]
    instance = ec2.run_instances(ImageId=image, InstanceType="t3.micro", MinCount=1, MaxCount=1)["Instances"][0]["InstanceId"]
    state = lambda: ec2.describe_instances(InstanceIds=[instance])["Reservations"][0]["Instances"][0]["State"]["Name"]
    print()
    print("after launch   :", state())
    ec2.stop_instances(InstanceIds=[instance]);      print("after stop     :", state())
    ec2.terminate_instances(InstanceIds=[instance]); print("after terminate:", state())


main()

type        vCPU   memory  GiB per vCPU  reading the name
t3.micro       2   1.0 GiB           0.5  burstable, generation 3, size micro
m5.xlarge      4  16.0 GiB           4.0  general purpose, generation 5, size xlarge
c5.xlarge      4   8.0 GiB           2.0  compute optimized, generation 5, size xlarge
r5.xlarge      4  32.0 GiB           8.0  memory optimized, generation 5, size xlarge
r5.4xlarge    16 128.0 GiB           8.0  memory optimized, generation 5, size 4xlarge
m6g.xlarge     4  16.0 GiB           4.0  general purpose, generation 6, options 'g', size xlarge
i3.xlarge      4  30.5 GiB           7.6  storage optimized, generation 3, size xlarge

after launch   : running
after stop     : stopped
after terminate: terminated

Look at the three xlarge types from generation 5. All have 4 vCPUs. The c5 has 2 GiB of memory per vCPU, the m5 has 4, and the r5 has 8. The series letter is, in effect, a memory-to-CPU ratio. The size then scales both together: r5.4xlarge has four times the vCPUs and four times the memory of r5.xlarge, at the same ratio.

That gives a simple way to choose for data workloads:

Two cautions. Burstable t types deliver full CPU only in bursts, so they suit a small scheduler or bastion host and not a sustained job. And Graviton types, marked g, use Arm processors: often good value, but software and libraries must support Arm.

Launch, stop, terminate

The end of the output shows an instance's main states. The difference between the last two is a common and expensive confusion:

• Stop shuts the instance down. Its EBS volumes remain, and it can be started again.
• Terminate deletes it.

Billing follows state, with a catch. Instance usage is not billed while an instance is stopped, but the guide notes that some resources, such as EBS volumes and Elastic IP addresses, incur charges regardless of the instance's state (EC2 docs: instance state changes). A stopped instance with a large disk still costs money every month.

Purchasing options

The same instance can be paid for in several ways (EC2 docs: purchasing options):

For data engineering, Spot deserves attention. Batch processing is often interruptible by design, and the savings can be large. The condition is that the work tolerates interruption: Amazon EC2 issues an interruption notice two minutes before it stops or terminates a Spot Instance (EC2 docs: Spot interruption notices). Spark on EMR handles this well when Spot is used for task nodes and On-Demand for the nodes that hold data; Amazon EMR explained covers that split.

A sensible progression: start On-Demand, measure for a few weeks, move interruptible batch work to Spot, and only then consider a commitment for the steady remainder. Prices differ by Region and change, so compare on the pricing page, not from memory.

When not to use EC2

EC2 gives full control and with it the full operational burden: patching, scaling, monitoring, and paying for idle time. Before launching instances for data work, check whether a managed service does the job:

EC2 is the right choice when you need software, versions or hardware that managed services do not offer, or when a constant heavy workload is cheaper on committed instances.

Habits that prevent surprises

• Tag every instance with an owner and purpose.
• Terminate what you are not using; stop only what you will restart.
• Delete orphaned EBS volumes and release unused Elastic IPs.
• Put instances in private subnets with narrow security groups; see VPC basics for data engineers.
• Give instances an IAM role, not access keys in a file.
• Right-size from metrics, not from guesses. An instance averaging ten percent CPU is too big.
• Set a budget alert before experimenting.

For where compute sits among all the costs of a data platform, see AWS cost optimisation for data workloads; for the wider learning order, the AWS roadmap for data engineers.

Cloud platforms for data engineering, including AWS compute and storage services, are covered in the Data Engineering course.

Sources

• What is Amazon EC2? (EC2 User Guide) — AWS Documentation
• Amazon EC2 instance type naming conventions (EC2 Instance Types guide) — AWS Documentation
• Amazon EC2 billing and purchasing options (EC2 User Guide) — AWS Documentation
• Spot Instance interruption notices (EC2 User Guide) — AWS Documentation
• Amazon EC2 instance state changes (EC2 User Guide) — AWS Documentation