AWS Services Learning Guide¶

This document is designed as a structured learning path from fundamentals to advanced concepts, with clear explanations, examples, code snippets, and reference links for deeper exploration.

Note:

AWS services can be created in two ways:

AWS Management Console – Useful for learning and quick experimentation

Infrastructure as Code (IaC) – The preferred and recommended approach for real-world environments

This document includes Terraform examples for reference, while Terraform concepts and workflows are covered in a separate dedicated document.

Table of Contents¶

References & Further Reading¶

Basic Level¶

Introduction to AWS¶

Amazon Web Services (AWS) is a cloud computing platform that provides on-demand access to compute, storage, networking, databases, and other services over the internet.

AWS allows organizations to build, deploy, and scale applications without managing physical infrastructure.

Key Characteristics¶

On-demand – Resources can be provisioned when needed

Pay-as-you-go – Pay only for what you use

Scalable – Scale resources up or down based on demand

Secure – Built-in security and compliance capabilities

Why AWS is used¶

Faster application deployment

Reduced infrastructure cost

High availability and reliability

Global reach

Common Use Cases¶

Hosting web and mobile applications

Data storage and analytics

Serverless and containerized applications

Enterprise and startup workloads

AWS Global Infrastructure (Regions, Availability Zones)¶

AWS Global Infrastructure is designed to provide high availability, fault tolerance, and low latency for applications worldwide.

Key Components / Terms¶

Region – A geographical area where AWS operates data centers (for example: us-east-1, eu-west-1).

Availability Zone (AZ) – One or more physically separate data centers within a region, designed to be isolated from failures.

Edge Location – Locations used by services like CloudFront to deliver content with low latency.

How it works¶

Each Region contains multiple Availability Zones

AZs are connected with high-speed, low-latency networking

Applications can be deployed across AZs for high availability

Practical Example¶

Deploy an application across multiple Availability Zones so that if one data center fails, the application remains available.

Real-World Use Cases¶

High-availability application design

Disaster recovery and fault tolerance

Low-latency access for global users

Compute Basics¶

AWS Lambda¶

What it is A serverless compute service that runs code in response to events without requiring server management.

Key Components / Terms¶

Function – The code executed by Lambda

Runtime – Language environment used to run the function

Handler – Entry point method for execution

Event Trigger – AWS service that invokes the function

Execution Role – IAM role granting permissions to Lambda

Terraform Example for creating Lambda service¶

resource "aws_lambda_function" "example" {
  function_name = "sample-lambda"
  runtime       = "python3.10"
  handler       = "lambda_function.handler"
  role          = aws_iam_role.lambda_role.arn
}

Real-World Use Cases¶

Serverless API backends

Event-driven data processing

Automation and scheduled jobs

Best Practices¶

Keep functions short-lived

Use environment variables

Follow least-privilege IAM policies

Deep Dive: AWS Lambda Documentation

Amazon EC2¶

What it is A service that provides resizable virtual servers in the cloud.

Key Components / Terms¶

AMI – Template used to launch instances

Instance Type – Defines CPU and memory capacity

Security Group – Virtual firewall for instances

Key Pair – Used for secure login

Practical Example Host a simple web application on a virtual machine.

Terraform Example¶

resource "aws_instance" "web" {
  ami           = "ami-0abcdef"
  instance_type = "t2.micro"
}

Real-World Use Cases¶

Web servers

Legacy applications

Custom compute workloads

Best Practices¶

Right-size instances

Avoid hardcoded AMIs

Restrict access using security groups

Deep Dive: Amazon Elastic Compute Cloud Documentation

Storage Basics¶

Amazon S3¶

What it is Highly durable object storage for storing and retrieving any amount of data.

Key Components / Terms¶

Bucket – Container for storing objects

Object – File stored in S3

Versioning – Keeps multiple versions of objects

Lifecycle Rules – Automates data transition or deletion

Practical Example Store application logs or static website files.

Terraform Example¶

resource "aws_s3_bucket" "data" {
  bucket = "my-s3-bucket"
}

Real-World Use Cases¶

Static website hosting

Backup and archival storage

Data lakes

Best Practices¶

Enable encryption

Avoid public access

Use lifecycle policies

Deep Dive: Amazon Simple Storage Service Documentation

Database Basics¶

Amazon DynamoDB (Overview)¶

What it is A fully managed, serverless NoSQL key-value database with low-latency performance.

Key Components / Terms¶

Partition Key – Unique identifier for items

Sort Key – Optional secondary key for sorting

Billing Mode – Capacity configuration

Practical Example Store user session data or application metadata.

Terraform Example¶

resource "aws_dynamodb_table" "table" {
  name         = "Tasks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "id"

  attribute {
    name = "id"
    type = "S"
  }
}

Real-World Use Cases¶

Serverless applications

High-scale systems

Event-driven architectures

Best Practices¶

Design keys carefully

Avoid table scans

Use indexes when needed

Deep Dive: Amazon DynamoDB Documentation

Networking Basics¶

Amazon VPC (Overview)¶

What it is A logically isolated virtual network for AWS resources.

Key Components / Terms¶

CIDR – IP range for the VPC

Subnets – Segments of the VPC

Route Tables – Traffic routing rules

Internet Gateway – Enables internet access

Practical Example Deploy public and private resources securely within a network.

Terraform Example¶

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

Real-World Use Cases¶

Secure application networking

Multi-tier architectures

Best Practices¶

Plan CIDR ranges carefully

Separate public and private subnets

Deep Dive: Amazon Virtual Private Cloud Documentation

Security Basics¶

Amazon IAM¶

What it is A service that manages access and permissions for AWS resources.

Key Components / Terms¶

Users – Identities for people or applications

Roles – Temporary permission sets

Policies – Permission definitions

Practical Example Grant Lambda permission to access DynamoDB.

Terraform Example¶

resource "aws_iam_role" "example" {
  name = "example-role"
}

Real-World Use Cases¶

Secure service-to-service access

Controlled user permissions

Best Practices¶

Follow least privilege

Avoid wildcard permissions

Deep Dive: AWS Identity and Access Management Documentation

Monitoring Basics¶

Amazon CloudWatch (Metrics & Logs)¶

What it is A monitoring service for collecting metrics, logs, and setting alarms.

Key Components / Terms¶

Metrics – Performance data

Logs – Application and system logs

Alarms – Threshold-based notifications

Practical Example Monitor EC2 CPU usage and trigger alerts.

Terraform Example¶

resource "aws_cloudwatch_metric_alarm" "cpu_alarm" {
  alarm_name          = "high-cpu"
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  statistic           = "Average"
  threshold           = 80
  comparison_operator = "GreaterThanThreshold"
  period              = 300
  evaluation_periods  = 2
}

Real-World Use Cases¶

System health monitoring

Alerting and troubleshooting

Best Practices¶

Avoid noisy alarms

Use log retention policies

Deep Dive: Amazon CloudWatch Documentation

Basic Best Practices¶

Use least privilege for all access

Prefer managed and serverless services

Monitor cost and usage regularly

Deploy workloads across multiple Availability Zones

Use Infrastructure as Code for consistency

Intermediate Level¶

Compute¶

Amazon EC2 (Scaling, Security Groups)¶

At the intermediate level, EC2 is used as a scalable and secure compute layer, not just a single virtual machine.

Key Focus Areas¶

Scaling – Use Auto Scaling Groups to automatically add or remove instances based on load.

Security Groups – Act as instance-level firewalls controlling inbound and outbound traffic.

Practical Perspective EC2 instances are commonly placed behind load balancers and scaled horizontally to handle variable traffic while maintaining availability.

Typical Use Cases¶

Auto-scaled application servers

Backend services requiring custom OS-level control

Key Considerations¶

Design stateless instances for scaling

Restrict security group rules to minimum required access

Amazon ECS / EKS (Overview & Use Cases)¶

ECS and EKS are used to orchestrate containerized workloads at scale.

ECS¶

AWS-managed container orchestration

Tighter AWS integration and simpler operations

EKS¶

Managed Kubernetes service

Used when Kubernetes portability or ecosystem is required

Practical Perspective Organizations choose ECS for simplicity and EKS when Kubernetes standardization is needed across platforms.

Typical Use Cases¶

Microservices-based applications

Containerized APIs and background workers

Storage¶

Amazon S3 (Versioning, Lifecycle Rules)¶

At the intermediate level, S3 is used for data durability, recovery, and cost optimization.

Key Focus Areas¶

Versioning – Maintains multiple versions of objects to protect against accidental deletion.

Lifecycle Rules – Automatically transition data to cheaper storage or delete it after a defined period.

Practical Perspective S3 is often used with lifecycle policies to manage logs, backups, and archival data efficiently.

Typical Use Cases¶

Log retention with automatic expiration

Backup and compliance storage

Database¶

Amazon DynamoDB (Keys, Indexes, Capacity Modes)¶

Intermediate DynamoDB usage focuses on data modeling and performance optimization.

Key Focus Areas¶

Partition & Sort Keys – Define how data is distributed and queried.

Indexes (GSI / LSI) – Enable additional query patterns without table scans.

Capacity Modes – Choose between On-Demand and Provisioned throughput.

Practical Perspective Proper key design is critical to avoid hot partitions and ensure predictable performance.

Typical Use Cases¶

High-throughput applications

Event-driven and serverless backends

Networking¶

Amazon VPC (Subnets, Route Tables, IGW)¶

At this level, VPC is used to control traffic flow and isolate workloads.

Key Focus Areas¶

Subnets – Separate public-facing and internal resources.

Route Tables – Define how traffic is routed within the VPC.

Internet Gateway (IGW) – Enables internet access for public subnets.

Practical Perspective Applications typically run in private subnets, with only load balancers exposed publicly.

Typical Use Cases¶

Multi-tier application architectures

Secure internal networking

Security¶

Amazon IAM (Roles, Policies, Least Privilege)¶

Intermediate IAM usage focuses on secure access management without static credentials.

Key Focus Areas¶

Roles – Preferred over users for service-to-service access.

Policies – Define fine-grained permissions using JSON.

Least Privilege – Grant only the permissions required to perform tasks.

Practical Perspective Most production workloads rely on IAM roles attached to services rather than IAM users.

Typical Use Cases¶

Secure Lambda-to-DynamoDB access

Controlled access between AWS services

Monitoring & Auditing¶

Amazon CloudWatch (Alarms, Dashboards)¶

CloudWatch is used for operational visibility and alerting.

Key Focus Areas¶

Alarms – Trigger notifications or actions when thresholds are breached.

Dashboards – Provide centralized visibility into system health.

Practical Perspective CloudWatch alarms are integrated with SNS or incident tools for real-time alerting.

AWS CloudTrail (Event History, Trails)¶

CloudTrail provides account-level auditing and change tracking.

Key Focus Areas¶

Event History – View recent API activity.

Trails – Store API logs centrally in S3 for long-term auditing.

Practical Perspective CloudTrail is critical for security investigations and compliance requirements.

Cost & Performance Considerations¶

At the intermediate level, cost awareness becomes part of daily operations.

Key Focus Areas¶

Right-sizing compute resources

Choosing appropriate storage classes

Monitoring usage and avoiding over-provisioning

Practical Perspective Cost optimization is an ongoing process and should be monitored alongside performance metrics.

Advanced Level¶

Compute¶

ECS vs EKS Design Decisions¶

At the advanced level, the ECS vs EKS decision defines the operational model of the platform, not just container orchestration.

Key Trade-Offs¶

ECS prioritizes simplicity, AWS-native integration, and reduced operational burden.

EKS prioritizes Kubernetes standardization, ecosystem flexibility, and portability.

Operational Considerations¶

ECS abstracts cluster lifecycle, reducing upgrade and maintenance risk.

EKS requires managing Kubernetes versions, networking plugins, and add-ons.

Risk & Failure Perspective¶

Choosing EKS without Kubernetes expertise increases operational risk and incident frequency.

ECS limits extensibility but reduces blast radius during failures.

Production Reality Many organizations adopt a mixed strategy:

ECS for most application workloads

EKS only where Kubernetes-native tooling or multi-cloud portability is essential

Serverless vs Containerized Architectures¶

This decision impacts cost predictability, scalability behavior, and observability.

Serverless (Lambda)¶

Event-driven, scales automatically, and reduces idle cost.

Introduces cold starts, execution limits, and runtime constraints.

Containers (ECS/EKS)¶

Provide predictable performance and runtime control.

Require capacity planning and continuous resource management.

Architectural Trade-Off Advanced systems often use serverless for orchestration and event handling, and containers for core services requiring long-running processes or custom dependencies.

Failure & Cost Perspective¶

Overusing serverless can increase cost at high, steady traffic.

Overusing containers can lead to resource waste if not right-sized.

Networking¶

Multi-VPC Architectures¶

Multi-VPC designs are driven by isolation, scalability, and governance requirements.

Why Multi-VPC¶

Environment isolation (dev, staging, prod)

Organizational or account-level separation

Reduced blast radius during security incidents

Connectivity Models¶

VPC peering for simple point-to-point connections

Hub-and-spoke or transit VPC models for scale

Risk & Failure Perspective Poorly planned VPC connectivity leads to:

Overlapping CIDR conflicts

Complex routing issues

Difficult troubleshooting

Production Reality Large organizations almost always move to multi-VPC or multi-account architectures as systems scale.

Public vs Private Subnet Design¶

Advanced subnet design focuses on minimizing exposure and controlling traffic paths.

Design Principles¶

Public subnets contain only edge components (ALB, NAT Gateway).

Application and database tiers run in private subnets.

Outbound traffic is explicitly controlled.

Security Implications¶

Public exposure increases attack surface.

Private subnets enforce defense-in-depth.

Failure Perspective Incorrect subnet design can:

Expose internal services

Break outbound dependencies

Complicate incident response

Security¶

IAM Policy Design Patterns¶

At the advanced level, IAM design must scale across teams, services, and accounts.

Design Patterns¶

Role-based access over user-based access

Service roles scoped to specific actions and resources

Separation of duties through distinct roles

Operational Risk Overly permissive policies increase security exposure, while overly restrictive policies slow delivery.

Production Reality IAM policies should be:

Reusable

Auditable

Easy to reason about during incidents

Secure Service-to-Service Communication¶

Advanced security assumes zero trust between internal services.

Key Concepts¶

Identity-based authentication using IAM roles

Encrypted communication in transit

Minimal network exposure between services

Failure Perspective Hardcoded credentials or shared secrets lead to:

Credential leaks

Difficult rotation

Security incidents

Production Reality Modern architectures rely on identity and policy, not network trust.

Monitoring & Auditing¶

CloudWatch + EventBridge Automation¶

Advanced observability moves from monitoring to automated remediation.

Capabilities¶

Detect anomalies via metrics and logs

Trigger EventBridge rules

Invoke remediation workflows automatically

Operational Value¶

Faster incident response

Reduced manual intervention

Improved system resilience

Failure Perspective Alert-only systems increase human dependency and slow recovery.

CloudTrail for Compliance & Forensics¶

CloudTrail becomes a security and compliance backbone.

Advanced Usage¶

Centralized logging across multiple accounts

Long-term retention for audits

Correlation with security incidents

Forensic Value CloudTrail answers:

Who made the change?

When did it happen?

What resource was affected?

Production Reality CloudTrail logs are often treated as immutable evidence.

Architecture Patterns¶

Event-Driven Architectures¶

Event-driven systems improve scalability, resilience, and decoupling.

Key Characteristics¶

Asynchronous communication

Independent scaling

Loose coupling between components

Risk & Trade-Off¶

Increased debugging complexity

Event ordering and duplication challenges

Production Reality Event-driven designs enable systems to evolve independently but require strong observability.

Microservices on AWS¶

Microservices emphasize independent ownership and deployment.

Core Principles¶

Single responsibility per service

Independent data ownership

API or event-based communication

Failure Perspective Poorly designed microservices increase latency, cost, and operational complexity.

Production Reality Microservices are justified by organizational scale, not by technology trends.

Production Best Practices¶

At the advanced level, success is measured by resilience and operability, not feature delivery.

Key Principles¶

Design for failure, not success

Automate deployments and recovery

Monitor continuously

Secure by default

Production Mindset Systems should degrade gracefully and recover automatically.

References & Further Reading¶

Note on References:¶

Some official AWS documentation links are referenced within the Basic Level sections of this document.