AWS EC2 Tutorial: What is AWS EC2?

Summary:

• AWS EC2 provides resizable virtual servers in the cloud, enabling you to launch compute capacity in minutes rather than weeks, with complete control over instance configuration, networking, and storage.
• This tutorial covers the full EC2 lifecycle: from understanding core components like AMIs, security groups, and EBS volumes to launching instances via the console, CLI, and Infrastructure as Code tools like Terraform.
• You will learn how to choose between instance families (including Graviton4 and Graviton5 processors), navigate pricing models such as on-demand, reserved, and spot instances, and implement security best practices that protect production workloads.

Every application running in the cloud ultimately needs compute power. For millions of engineers worldwide, that compute power begins with Amazon Elastic Compute Cloud. Whether you are deploying a simple web server for a side project or architecting a distributed system that handles millions of requests per second, EC2 remains the foundational building block of AWS infrastructure.

This AWS EC2 tutorial will take you from understanding what EC2 actually is under the hood to launching production-ready instances using multiple deployment methods. It addresses the gaps left by existing guides that ignore CLI workflows, modern Graviton processors, and cost optimization strategies that matter in 2025.

The following diagram illustrates the high-level relationship between EC2 and its core dependencies within the AWS ecosystem. This provides a mental model you will reference throughout this guide.

What is AWS EC2 and how does it work

Amazon Elastic Compute Cloud, commonly known as EC2, is a web service that provides resizable compute capacity in the cloud. In practical terms, EC2 allows you to rent virtual servers, called instances, that run on physical hardware managed entirely by AWS. You select the operating system, configure the network settings, attach storage volumes, and control access through security policies. The “elastic” in the name refers to the ability to scale capacity up or down within seconds to minutes, paying only for the compute time you actually consume.

Under the hood, EC2 instances run on the AWS Nitro System, a collection of purpose-built hardware and lightweight hypervisors that offload virtualization functions to dedicated hardware. This architecture delivers near bare-metal performance while maintaining strong security isolation between tenants. When you launch an instance, AWS provisions the underlying resources, boots your selected Amazon Machine Image, and assigns networking components based on your VPC configuration.

Core components every engineer must understand

Before launching your first instance, you need to understand five foundational components that work together to create a functional EC2 deployment. Each component serves a distinct purpose. Misconfiguring any one of them can lead to security vulnerabilities, connectivity issues, or unexpected costs.

• Amazon Machine Image (AMI): A template containing the operating system, application server, and applications required to launch an instance. AWS provides official AMIs for Amazon Linux, Ubuntu, Windows Server, and other distributions, while the AWS Marketplace offers pre-configured images for specific use cases.
• Instance type: Defines the hardware specifications of your virtual server, including vCPU count, memory, storage type, and network performance. Instance types are grouped into families optimized for different workloads.
• Security group: Acts as a virtual firewall controlling inbound and outbound traffic at the instance level. Security groups are stateful, meaning return traffic is automatically allowed regardless of outbound rules.
• Key pair: A cryptographic key pair used for secure SSH or RDP access. AWS stores the public key, and you download the private key exactly once at creation time.
• Elastic Block Store (EBS): Persistent block storage volumes that exist independently of instance lifecycle. EBS volumes can be attached, detached, and snapshotted without affecting the underlying data.

Understanding how these components interact is essential before moving into the practical steps of launching an instance. Consider the following section your hands-on guide to deploying EC2 through multiple methods.

How to launch your first EC2 instance

Launching an EC2 instance can be accomplished through the AWS Management Console, the AWS Command Line Interface, or Infrastructure as Code tools like Terraform and CloudFormation. Each method has distinct advantages. The console provides visual feedback ideal for learning. The CLI enables scripting and automation. IaC tools ensure reproducible, version-controlled infrastructure. This section walks through all three approaches so you can choose the right tool for your workflow.

Launching via the AWS Management Console

The console-based launch wizard guides you through each configuration step with sensible defaults. Navigate to the EC2 Dashboard, click “Launch instance,” and you will encounter a streamlined interface that consolidates previously separate screens into a single page. Start by naming your instance and selecting an AMI from the Quick Start options. Amazon Linux 2023 and Ubuntu 24.04 LTS are popular choices for Linux workloads.

Next, choose an instance type. For learning and development, AWS offers a Free Tier. Free Tier eligibility depends on your account type. Legacy accounts receive 750 hours per month of t2.micro or t3.micro for 12 months, while newer accounts (after July 15, 2025) use a credit-based model with up to $200 in credits and broader instance eligibility. Starting July 15, 2025, AWS updated Free Tier eligibility to include t4g.small instances, making Graviton-based compute accessible at no cost for new users. Select or create a key pair for SSH access, then configure security group rules to allow inbound traffic on port 22 for SSH or port 3389 for RDP.

Launching via the AWS CLI

The AWS CLI provides programmatic control over EC2 resources, enabling automation and integration with deployment pipelines. Before running commands, ensure you have configured credentials using aws configure with an IAM user that has EC2 permissions. The following command launches a t3.micro instance using the latest Amazon Linux 2023 AMI in the us-east-1 region.

aws ec2 run-instances \
  --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --instance-type t3.micro \
  --key-name my-key-pair \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=MyFirstInstance}]' \
  --iam-instance-profile Name=MyEC2Role

This command demonstrates several best practices. It uses SSM Parameter Store to resolve the latest AMI ID dynamically. It attaches an IAM instance profile for secure API access. It applies tags for resource organization. The --iam-instance-profile parameter attaches an IAM role to the instance, eliminating the need to store long-term credentials on the server.

Launching via Terraform

Infrastructure as Code tools like Terraform enable declarative infrastructure management with version control, peer review, and repeatable deployments. The following Terraform configuration creates an EC2 instance with an attached security group and EBS volume, using Launch Template v2 for advanced configuration options.

resource "aws_launch_template" "web_server" {
  name_prefix   = "web-server-"
  image_id      = data.aws_ami.amazon_linux_2023.id
  instance_type = "t3.micro"

  iam_instance_profile {
    name = aws_iam_instance_profile.ec2_profile.name
  }

  network_interfaces {
    associate_public_ip_address = true
    security_groups             = [aws_security_group.web_sg.id]
  }

  user_data = base64encode(<<-EOF
    #!/bin/bash
    yum update -y
    yum install -y httpd
    systemctl start httpd
    systemctl enable httpd
  EOF
  )

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = "WebServer"
    }
  }
}

resource "aws_instance" "web" {
  launch_template {
    id      = aws_launch_template.web_server.id
    version = "$Latest"
  }
}

The user_data block demonstrates automated boot tasks, a powerful feature that executes scripts on first launch. This pattern eliminates manual configuration steps and ensures every instance starts in a known state. With your instance running, the next consideration is selecting the right instance type for your workload.

How to choose EC2 instance types in 2025

AWS offers hundreds of instance types across multiple families, each optimized for specific workload characteristics. Choosing the wrong instance type leads to either wasted spend on over-provisioned resources or performance bottlenecks from under-provisioned capacity. The decision matrix below compares current-generation instance families, including the latest Graviton4 and Graviton5 processors that deliver significant price-performance improvements over x86 alternatives.

Arm versus x86 architecture considerations

The choice between Arm64 (Graviton) and x86_64 (Intel/AMD) architectures depends on your application’s binary compatibility and performance requirements. Most modern programming languages, including Python, Node.js, Java, and Go, run natively on Arm64 without modification. Container workloads using multi-architecture images can seamlessly deploy to Graviton instances. However, applications with compiled x86 dependencies, certain commercial software packages, or Windows workloads require x86 instances.

For senior engineers evaluating architecture decisions, the trade-off extends beyond raw performance. Graviton instances reduce carbon footprint due to higher energy efficiency, which increasingly matters for organizations with sustainability commitments. The operational complexity of maintaining separate AMIs or container images for different architectures is minimal when using modern CI/CD pipelines that build multi-arch artifacts. Understanding instance selection naturally leads to the question of how much these resources actually cost.

EC2 pricing models explained

AWS offers four primary pricing models for EC2, each suited to different usage patterns and budget constraints. Selecting the right model can reduce compute costs by 60-90% compared to on-demand pricing. This requires understanding your workload’s characteristics and tolerance for interruption.

1. On-demand instances: Pay by the second with no upfront commitment. Ideal for unpredictable workloads, short-term projects, or applications being developed and tested. This is the default and most flexible option but also the most expensive per compute hour.
2. Reserved instances: Commit to one or three years of usage in exchange for discounts up to 72% compared to on-demand. Best for steady-state workloads with predictable capacity requirements. Convertible reserved instances allow changing instance families during the term.
3. Savings Plans: Commit to a consistent amount of compute usage (measured in dollars per hour) for one or three years. More flexible than reserved instances because they apply automatically across instance families, sizes, and regions.
4. Spot instances: Bid on unused EC2 capacity at discounts up to 90%. AWS can reclaim spot instances with two minutes notice when capacity is needed. Suitable for fault-tolerant workloads like batch processing, CI/CD pipelines, and distributed computing frameworks.

Cost optimization extends beyond pricing model selection. Right-sizing instances based on actual utilization, scheduling non-production instances to stop outside business hours, and using AWS Compute Optimizer recommendations all contribute to reducing spend. With pricing understood, the final critical area is securing your EC2 deployments against common threats.

Best practices for securing AWS EC2 instances

Security misconfigurations remain the leading cause of cloud breaches. EC2 instances present multiple attack surfaces that require deliberate hardening. The following practices represent the minimum security posture for production workloads, though compliance requirements may demand additional controls.

Start with the principle of least privilege for both network access and IAM permissions. Security groups should allow only the specific ports and source IP ranges required for your application to function. Avoid using 0.0.0.0/0 as a source except for public-facing load balancers or web servers. Even then, consider placing instances in private subnets behind an Application Load Balancer.

• Use IAM roles instead of access keys: Attach IAM roles to instances rather than storing AWS credentials in configuration files or environment variables. Roles provide temporary credentials that rotate automatically.
• Enable IMDSv2: Instance Metadata Service version 2 requires session tokens for metadata requests, mitigating SSRF attacks that could otherwise extract IAM credentials from the metadata endpoint.
• Encrypt EBS volumes: Enable encryption by default in your account settings. AWS manages the encryption keys through KMS, adding negligible performance overhead while protecting data at rest.
• Implement Systems Manager for access: Use Session Manager instead of SSH for shell access. This eliminates the need to open port 22, manage key pairs, or maintain bastion hosts.
• Enable detailed monitoring: CloudWatch detailed monitoring provides one-minute granularity metrics. Combine with CloudWatch Alarms to detect anomalous CPU, network, or disk patterns that may indicate compromise.

Monitoring and operational excellence

Production EC2 deployments require observability beyond basic health checks. Amazon CloudWatch collects metrics, logs, and traces from EC2 instances, enabling both reactive alerting and proactive capacity planning. Install the CloudWatch agent on instances to collect memory utilization and disk metrics not available through the hypervisor. Configure log groups to capture application logs, system logs, and security events for centralized analysis.

For multi-AZ deployments, distribute instances across at least two Availability Zones to maintain availability during infrastructure failures. Use Auto Scaling groups to automatically replace unhealthy instances and adjust capacity based on demand. These patterns transform EC2 from individual virtual machines into resilient, self-healing infrastructure.

Conclusion

This AWS EC2 tutorial covered the essential knowledge required to deploy, configure, and secure EC2 instances in production environments. You learned that EC2 provides resizable compute capacity through virtual servers running on the Nitro System. Core components including AMIs, security groups, key pairs, and EBS volumes work together to create functional deployments. The three deployment methods (console, CLI, and Terraform) each serve different operational needs, from interactive learning to fully automated infrastructure pipelines.

Instance type selection in 2026 increasingly favors Graviton-based processors for their superior price-performance, though x86 instances remain necessary for specific compatibility requirements. Pricing model selection between on-demand, reserved, Savings Plans, and spot instances can reduce costs by up to 90% when matched appropriately to workload characteristics. Security hardening through least-privilege networking, IAM roles, IMDSv2, and encryption forms the baseline for any production deployment.

As AWS continues releasing new instance types and features, the fundamentals covered here remain stable. Engineers who master these concepts can adapt to new offerings while maintaining secure, cost-effective infrastructure. Start with a t4g.small instance under the updated Free Tier, experiment with the CLI and Terraform examples, and build the muscle memory that transforms cloud computing from abstract concept to practical skill.