AWS Getting Started: Practical Guide to Cloud Onboarding

Introduction

Starting your cloud journey with AWS can feel overwhelming. Between the hundreds of services, pricing models, and architectural decisions, many organizations struggle to know where to begin. But here’s the good news: AWS has simplified the onboarding process significantly, and with the right guidance, you can have your first cloud environment running efficiently in hours, not weeks.

This practical guide walks you through AWS fundamentals, account setup, service selection, and deployment—all while keeping security and cost optimization front and center. Whether you’re a system administrator exploring cloud infrastructure or an architect planning your organization’s cloud strategy, you’ll find actionable steps to accelerate your time to value.

Understanding AWS Fundamentals

What AWS Offers and Why It Matters

Amazon Web Services is the world’s most comprehensive cloud platform, offering over 200 fully featured services. But you don’t need to understand all of them to get started. AWS provides compute, storage, databases, networking, security, and analytics capabilities that let you build virtually any application.

The real value of AWS lies in its flexibility. You can:

• Scale automatically based on demand without managing physical infrastructure
• Pay only for what you use with no upfront capital expenditure
• Deploy globally in minutes across multiple regions and availability zones
• Focus on your application rather than infrastructure management
• Leverage managed services that handle patching, backups, and maintenance

For cloud engineers and system administrators, this means less time managing servers and more time innovating.

Core Services You’ll Use First

When starting with AWS, focus on these foundational services:

Compute Services:

• EC2 (Elastic Compute Cloud): Virtual servers you control completely
• Lambda: Serverless compute that runs code without managing servers
• ECS/EKS: Container orchestration for Docker and Kubernetes workloads

Storage Services:

• S3 (Simple Storage Service): Object storage for files, backups, and data lakes
• EBS (Elastic Block Store): Block storage for EC2 instances
• EFS (Elastic File System): Shared file storage for multiple instances

Database Services:

• RDS (Relational Database Service): Managed MySQL, PostgreSQL, MariaDB, Oracle, SQL Server
• DynamoDB: NoSQL database for high-performance applications
• ElastiCache: In-memory caching for improved application performance

Networking:

• VPC (Virtual Private Cloud): Your isolated network environment
• ALB/NLB (Load Balancers): Distribute traffic across instances
• CloudFront: Content delivery network for global distribution

Security & Management:

• IAM (Identity and Access Management): Control who accesses what
• CloudTrail: Audit and log all API activity
• CloudWatch: Monitor resources and applications

The AWS Management Console vs. CLI vs. SDKs

AWS provides three primary ways to interact with services:

AWS Management Console

• Web-based graphical interface
• Best for: Learning, initial setup, occasional management tasks
• Advantage: Visual, intuitive, no command syntax to learn
• Limitation: Slower for repetitive tasks, difficult to automate

AWS CLI (Command Line Interface)

• Command-line tool for managing AWS services
• Best for: Automation, scripting, infrastructure-as-code workflows
• Advantage: Fast, scriptable, integrates with CI/CD pipelines
• Limitation: Steeper learning curve, requires terminal familiarity

AWS SDKs

• Programming language libraries (Python, Java, Node.js, Go, etc.)
• Best for: Application development, custom integrations
• Advantage: Native language support, full programmatic control
• Limitation: Requires development expertise

Recommendation for beginners: Start with the Management Console to understand concepts, then graduate to the CLI for automation and infrastructure-as-code approaches.

Setting Up Your AWS Account

Creating and Securing Your Account

Your AWS account is the foundation of everything you’ll build. Securing it properly from day one prevents costly mistakes and security breaches.

Step 1: Create Your AWS Account

1. Visit aws.amazon.com and click “Create an AWS Account”
2. Provide your email address, password, and account name
3. Enter billing information (required even for free tier usage)
4. Verify your identity via phone
5. Choose a support plan (Basic is free)

Step 2: Secure Your Root Account

Your root account has unrestricted access to all AWS resources. Treat it like a master key:

• ✅ Enable Multi-Factor Authentication (MFA) immediately
• ✅ Create a strong, unique password (20+ characters)
• ✅ Store credentials in a password manager
• ❌ Never use root account for daily work
• ❌ Never share root credentials
• ❌ Never embed root credentials in applications

Step 3: Set Up Billing Alerts

Unexpected AWS bills are a common concern. Prevent surprises:

1. Go to Billing Dashboard → Billing Preferences
2. Enable “Receive Billing Alerts”
3. Set up CloudWatch alarms for estimated charges
4. Create budgets with notifications at 50%, 80%, and 100% thresholds

Configuring Identity and Access Management (IAM)

IAM is your primary security tool. It controls who can access what resources and what actions they can perform.

Create an IAM User for Daily Work

Never use your root account for daily operations. Instead:

1. Go to IAM Dashboard → Users → Create User
2. Enter a username (e.g., “admin-user”)
3. Enable “Provide user access to AWS Management Console”
4. Set a strong password or auto-generate one
5. Click Create User

Assign Permissions Using Roles

AWS uses role-based access control (RBAC). Instead of assigning permissions directly to users, assign them to roles:

1. Go to IAM → Roles → Create Role
2. Select AWS Service as the trusted entity
3. Choose the service (e.g., EC2, Lambda)
4. Attach policies (e.g., AmazonEC2FullAccess)
5. Name your role and create it

Best Practice: Implement Least Privilege

Grant only the minimum permissions needed:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*"
    }
  ]
}

This policy allows a user to view, start, and stop EC2 instances—nothing more.

Enabling Multi-Factor Authentication

MFA adds a second layer of security by requiring a second verification method beyond your password.

Enable MFA for Root Account:

1. Go to IAM Dashboard → Security Credentials
2. Click Assign MFA device
3. Choose your MFA device type:

• Virtual MFA device (Google Authenticator, Authy, Microsoft Authenticator)
• Hardware MFA device (physical key fob)
• SMS text message (least secure, not recommended)

1. Scan the QR code with your authenticator app
2. Enter two consecutive codes to verify

Enable MFA for IAM Users:

1. Go to IAM → Users → Select user
2. Click Security Credentials tab
3. Under “Multi-factor authentication (MFA)”, click Assign MFA device
4. Follow the same process as above

Pro Tip: Use a virtual MFA device for flexibility and a hardware device for your root account as a backup.

Choosing Your First Services

Compute: EC2 vs. Lambda for Your Workload

The choice between EC2 and Lambda depends on your application requirements.

EC2 (Elastic Compute Cloud)

Use EC2 when you need:

• Full control over the operating system and runtime environment
• Long-running applications (web servers, databases)
• Specific software or custom configurations
• Predictable, consistent workloads
• GPU or specialized hardware

Characteristics:

• You manage the server, OS, and application
• Pay for compute time whether running or idle
• Scales via Auto Scaling groups
• Suitable for traditional applications

Lambda (Serverless Compute)

Use Lambda when you need:

• Event-driven processing (API requests, file uploads, database changes)
• Short-lived tasks (seconds to minutes)
• Automatic scaling without management
• Pay-per-execution pricing
• Rapid development and deployment

Characteristics:

• AWS manages servers, OS, and runtime
• Pay only for execution time (in 100ms increments)
• Automatic scaling to handle any load
• Ideal for microservices and event-driven architectures

Quick Decision Matrix:

Recommendation for beginners: Start with EC2 if you’re migrating existing applications. Use Lambda for new, event-driven workloads.

Storage: Getting Started with S3

Amazon S3 (Simple Storage Service) is the most popular AWS service. It’s simple, scalable, and incredibly versatile.

What S3 Does:

• Stores any type of file (documents, images, videos, backups, data lakes)
• Provides 99.999999999% (11 nines) durability
• Scales automatically to handle any volume
• Costs pennies per gigabyte per month

S3 Concepts:

• Buckets: Top-level containers (like folders) for your objects
• Objects: Individual files stored in buckets
• Keys: The path/name of an object within a bucket
• Regions: Geographic location where data is stored

Creating Your First S3 Bucket:

1. Go to S3 → Create Bucket
2. Enter a globally unique bucket name (e.g., “my-company-data-2024”)
3. Select your region (choose closest to your users)
4. Keep “Block all public access” enabled (security best practice)
5. Enable versioning (protects against accidental deletion)
6. Enable encryption (protects data at rest)
7. Click Create Bucket

S3 Storage Classes for Cost Optimization:

• S3 Standard: Frequent access, highest cost, lowest latency
• S3 Standard-IA: Infrequent access, lower cost, retrieval fee
• S3 Glacier: Archive data, very low cost, slow retrieval (hours)
• S3 Intelligent-Tiering: Automatic cost optimization based on access patterns

Security Best Practices:

• Enable versioning to recover from accidental deletions
• Enable MFA Delete to require MFA for permanent deletion
• Use bucket policies to restrict access
• Enable S3 Block Public Access to prevent accidental exposure
• Enable encryption with AWS KMS for sensitive data

Databases: When to Use RDS

AWS offers multiple database options. RDS (Relational Database Service) is the managed option for traditional SQL databases.

RDS vs. Self-Managed Databases:

When to Use RDS:

• ✅ Relational data (structured, with relationships)
• ✅ Need managed backups and high availability
• ✅ Want to minimize operational overhead
• ✅ Using standard databases (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server)

When to Use DynamoDB Instead:

• ✅ NoSQL/document data
• ✅ Extreme scale and performance needs
• ✅ Unpredictable traffic patterns
• ✅ Simple key-value lookups

Creating Your First RDS Instance:

1. Go to RDS → Create Database
2. Choose Standard Create for more control
3. Select your database engine (PostgreSQL recommended for beginners)
4. Choose Free Tier template
5. Set master username and password
6. Keep default VPC and security settings
7. Enable automated backups (7-day retention)
8. Click Create Database

Cost Optimization Tips:

• Use the free tier for learning (750 hours/month for 12 months)
• Choose Single-AZ for non-production environments
• Use Reserved Instances for production workloads
• Right-size your instance type based on actual usage

Building Your First Application

Step-by-Step: Launching Your First EC2 Instance

EC2 instances are virtual servers. Launching one is your first hands-on AWS experience.

Prerequisites:

• AWS account with IAM user
• EC2 key pair created (for SSH access)

Step 1: Create a Key Pair

1. Go to EC2 → Key Pairs → Create Key Pair
2. Name it “my-first-key”
3. Choose RSA format
4. Click Create Key Pair
5. Save the .pem file securely (you’ll need it to connect)

Step 2: Launch an EC2 Instance

1. Go to EC2 → Instances → Launch Instances
2. Name: Enter “my-first-instance”
3. AMI (Amazon Machine Image): Select “Amazon Linux 2” (free tier eligible)
4. Instance Type: Select “t2.micro” (free tier eligible)
5. Key Pair: Select “my-first-key”
6. Network Settings:

• Keep default VPC
• Allow SSH traffic from your IP

1. Storage: Keep default 8GB (free tier eligible)
2. Click Launch Instance

Step 3: Connect to Your Instance

From your terminal (Mac/Linux):

# Change permissions on your key file
chmod 400 my-first-key.pem
# Connect via SSH
ssh -i my-first-key.pem ec2-user@<your-instance-public-ip>

From Windows, use PuTTY or Windows Terminal with WSL.

Step 4: Install a Web Server

Once connected, install and start a web server:

# Update system packages
sudo yum update -y
# Install Apache web server
sudo yum install -y httpd
# Start the web server
sudo systemctl start httpd
# Enable auto-start on reboot
sudo systemctl enable httpd
# Create a simple web page
echo "<h1>Hello from AWS!</h1>" | sudo tee /var/www/html/index.html

Step 5: Access Your Web Server

1. Go back to EC2 → Instances
2. Select your instance and copy the Public IPv4 address
3. Open a browser and visit http://<your-public-ip>
4. You should see “Hello from AWS!”

Congratulations! You’ve launched your first EC2 instance and deployed a web application.

Storing Data Securely with S3

Now let’s integrate S3 storage with your EC2 instance.

Step 1: Create an S3 Bucket

(Follow the S3 bucket creation steps from the “Storage” section above)

Step 2: Create an IAM Role for EC2

Your EC2 instance needs permission to access S3:

1. Go to IAM → Roles → Create Role
2. Select AWS Service → EC2
3. Click Next
4. Search for and select AmazonS3FullAccess policy
5. Click Next
6. Name it “EC2-S3-Access”
7. Click Create Role

Step 3: Attach the Role to Your Instance

1. Go to EC2 → Instances → Select your instance
2. Click Instance State → Security → Modify IAM Role
3. Select “EC2-S3-Access”
4. Click Update IAM Role

Step 4: Upload Files from EC2 to S3

Connect to your instance and use the AWS CLI:

# Install AWS CLI (usually pre-installed)
aws --version
# Create a test file
echo "This is test data" > test.txt
# Upload to S3
aws s3 cp test.txt s3://your-bucket-name/
# List files in your bucket
aws s3 ls s3://your-bucket-name/
# Download from S3
aws s3 cp s3://your-bucket-name/test.txt downloaded.txt

Security Best Practices:

• Use IAM roles instead of access keys for EC2 instances
• Enable S3 encryption for sensitive data
• Use S3 bucket policies to restrict access
• Enable versioning for data protection
• Monitor access with CloudTrail

Connecting Components with CloudFormation Templates

CloudFormation lets you define your entire infrastructure as code. This is how professionals build repeatable, scalable architectures.

What is CloudFormation?

CloudFormation is Infrastructure as Code (IaC) for AWS. You write a template (JSON or YAML) describing your resources, and CloudFormation creates them automatically.

Benefits:

• Repeatable deployments
• Version control for infrastructure
• Easy to scale and replicate
• Automatic rollback on failure
• Cost estimation before deployment

Simple CloudFormation Template Example:

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Simple web server with S3 storage'
Resources:
  # S3 Bucket for storage
  DataBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 'my-data-bucket-${AWS::AccountId}'
      VersioningConfiguration:
        Status: Enabled
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
  # IAM Role for EC2
  EC2Role:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: 'sts:AssumeRole'
      ManagedPolicyArns:
        - 'arn:aws:iam::aws:policy/AmazonS3FullAccess'
  # Instance Profile for EC2
  EC2InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Roles:
        - !Ref EC2Role
  # Security Group
  WebSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow HTTP and SSH
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: 0.0.0.0/0
  # EC2 Instance
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-0c55b159cbfafe1f0  # Amazon Linux 2
      InstanceType: t2.micro
      IamInstanceProfile: !Ref EC2InstanceProfile
      SecurityGroupIds:
        - !Ref WebSecurityGroup
      UserData:
        Fn::Base64: |
          #!/bin/bash
          yum update -y
          yum install -y httpd
          systemctl start httpd
          systemctl enable httpd
          echo "<h1>Hello from CloudFormation!</h1>" > /var/www/html/index.html
Outputs:
  BucketName:
    Description: S3 Bucket Name
    Value: !Ref DataBucket
  WebServerPublicIP:
    Description: Public IP of Web Server
    Value: !GetAtt WebServer.PublicIp

Deploying Your Template:

1. Go to CloudFormation → Create Stack
2. Choose Upload a template file
3. Select your YAML file
4. Click Next
5. Enter a stack name (e.g., “my-first-stack”)
6. Click Next → Next → Create Stack

CloudFormation will create all resources automatically. Check the Outputs tab for your web server’s IP address.

Security Best Practices from Day One

Security isn’t an afterthought—it’s foundational. AWS follows the “shared responsibility model”: AWS secures the infrastructure, you secure your applications and data.

Implementing Least Privilege Access

Least privilege means users have only the minimum permissions needed for their job.

Principle:

• Default: Deny all access
• Exception: Grant only required permissions
• Review: Regularly audit and remove unnecessary permissions

Example: Developer Role

A developer needs to:

• View EC2 instances
• Deploy code to Lambda
• Read from DynamoDB

Instead of granting broad permissions, create a specific policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ViewEC2Instances",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeSecurityGroups"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DeployLambda",
      "Effect": "Allow",
      "Action": [
        "lambda:UpdateFunctionCode",
        "lambda:UpdateFunctionConfiguration"
      ],
      "Resource": "arn:aws:lambda:*:*:function/my-app-*"
    },
    {
      "Sid": "ReadDynamoDB",
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query",
        "dynamodb:Scan"
      ],
      "Resource": "arn:aws:dynamodb:*:*:table/my-app-*"
    }
  ]
}

Implementation Steps:

1. Create roles for each job function (Developer, DevOps, DBA, etc.)
2. Attach only necessary policies to each role
3. Use resource-level permissions (ARNs) to limit scope
4. Review permissions quarterly
5. Remove unused roles and policies

Tools for Auditing:

• IAM Access Analyzer: Identifies overly permissive policies
• AWS CloudTrail: Logs all API calls for audit trails
• IAM Policy Simulator: Test policies before applying

Encrypting Data at Rest and in Transit

Encryption protects your data from unauthorized access.

Data at Rest (Stored Data)

Encrypt data stored in AWS services:

S3 Encryption:

# Enable default encryption on bucket
aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "AES256"
      }
    }]
  }'

RDS Encryption:

• Enable at database creation time (cannot be added later)
• Use AWS KMS for key management
• Automated backups are encrypted with the same key

EBS Volume Encryption:

• Enable encryption when creating volumes
• Minimal performance impact
• Snapshots inherit encryption from source volume

Data in Transit (Moving Data)

Encrypt data as it moves between services:

HTTPS/TLS:

• Use HTTPS for all web traffic
• Enable TLS 1.2 or higher
• Use AWS Certificate Manager for free SSL/TLS certificates

VPN and Direct Connect:

• Use AWS VPN for secure remote access
• Use AWS Direct Connect for dedicated network connections
• Encrypt data within your VPC using VPN tunnels

Example: Secure S3 Bucket Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Monitoring Activity with CloudTrail

CloudTrail logs all API calls in your AWS account. It’s essential for security, compliance, and troubleshooting.

What CloudTrail Logs:

• Who made the API call (user/role)
• When the call was made
• What action was performed
• Which resources were affected
• The result (success/failure)

Enabling CloudTrail:

1. Go to CloudTrail → Trails → Create Trail
2. Enter a trail name (e.g., “organization-trail”)
3. Choose S3 bucket for log storage
4. Create a new S3 bucket or use existing
5. Enable CloudWatch Logs for real-time monitoring
6. Enable Log file validation (prevents tampering)
7. Click Create Trail

Analyzing CloudTrail Logs:

# Query CloudTrail logs using AWS CLI
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=my-instance \
  --max-results 10
# Look for failed API calls
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteBucket \
  --max-results 10

CloudTrail Best Practices:

• Enable for all regions
• Enable log file validation
• Store logs in a separate, read-only S3 bucket
• Set up CloudWatch alarms for suspicious activity
• Retain logs for compliance requirements (typically 1-7 years)
• Use AWS Athena to query logs efficiently

Example: CloudWatch Alarm for Unauthorized API Calls

{
  "AlarmName": "UnauthorizedAPICallsAlarm",
  "MetricName": "UnauthorizedAPICallsEventCount",
  "Namespace": "CloudTrailMetrics",
  "Statistic": "Sum",
  "Period": 300,
  "EvaluationPeriods": 1,
  "Threshold": 1,
  "ComparisonOperator": "GreaterThanOrEqualToThreshold",
  "AlarmActions": ["arn:aws:sns:region:account:topic-name"]
}

Monitoring Costs and Optimizing Spending

AWS costs can spiral quickly if not monitored. The good news: AWS provides excellent tools to track and optimize spending.

Leveraging the AWS Free Tier Effectively

The AWS Free Tier lets you experiment without charges for 12 months.

Free Tier Includes:

Free Tier Best Practices:

1. Set up billing alerts to avoid unexpected charges
2. Use t2.micro instances for learning (free tier eligible)
3. Delete unused resources immediately after testing
4. Monitor data transfer (egress charges apply)
5. Use managed services (RDS, DynamoDB) instead of self-managed

Common Free Tier Mistakes:

• ❌ Launching large instances (t2.large, m5.xlarge)
• ❌ Leaving instances running 24/7
• ❌ Storing large amounts of data in S3
• ❌ Transferring data between regions
• ❌ Using premium support

Using Cost Explorer to Track Expenses

Cost Explorer visualizes your spending patterns and identifies optimization opportunities.

Accessing Cost Explorer:

1. Go to Billing → Cost Explorer
2. Click Launch Cost Explorer

Key Reports:

Daily Costs:

• Shows spending by day
• Identifies cost spikes
• Helps correlate costs with deployments

By Service:

• Breaks down costs by AWS service
• Identifies expensive services
• Guides optimization priorities

By Region:

• Shows which regions cost most
• Helps with region selection
• Identifies data transfer costs

By Tag:

• Requires resource tagging
• Allocates costs to projects/teams
• Enables chargeback models

Creating a Cost Anomaly Detection Alert:

1. Go to Cost Explorer → Anomaly Detection
2. Click Create Anomaly Alert
3. Set alert threshold (e.g., 10% increase)
4. Choose notification method (SNS topic)
5. AWS will alert you if spending deviates from baseline

Cost Optimization Recommendations:

AWS provides automatic recommendations:

1. Go to Billing → Cost Optimization Recommendations
2. Review recommendations (usually includes):

• Underutilized EC2 instances
• Unattached EBS volumes
• Unused Elastic IPs
• Idle RDS instances

Choosing Reserved Instances vs. Spot Instances

AWS offers different pricing models for different use cases.

On-Demand Instances

• Pay per hour/second
• No commitment
• Highest cost
• Best for: Unpredictable workloads, testing

Reserved Instances (RIs)

• Commit to 1 or 3 years
• 30-70% discount vs. On-Demand
• Upfront payment options
• Best for: Stable, predictable workloads

Savings Plans

• Flexible commitment (compute, instance family, region)
• 20-50% discount
• More flexible than RIs
• Best for: Mixed workloads

Spot Instances

• Use spare AWS capacity
• Up to 90% discount
• Can be interrupted with 2-minute notice
• Best for: Fault-tolerant, flexible workloads

Decision Matrix:

Example: Cost Comparison for 1 Year

Assume: t2.medium instance in us-east-1

• On-Demand: $0.0464/hour × 8,760 hours = $406/year
• 1-Year RI: $0.0232/hour × 8,760 hours = $203/year (50% savings)
• 3-Year RI: $0.0155/hour × 8,760 hours = $136/year (67% savings)
• Spot Instance: $0.0139/hour × 8,760 hours = $122/year (70% savings, but interruptible)

Purchasing Reserved Instances:

1. Go to EC2 → Reserved Instances → Purchase Reserved Instances
2. Select instance type, region, term (1 or 3 years)
3. Choose payment option:

• All Upfront: Highest discount, pay everything now
  –