Introduction to Cloud Computing on AWS

Section 1: Let’s Get Started

Overview:
This section introduces cloud computing fundamentals, compares traditional IT with cloud services,
and explains AWS’s role as a leading public cloud provider. It also guides learners through setting up
an AWS Free Tier account, configuring security/billing, and preparing tools for hands-on exercises.

Key Concepts
1. Cloud Computing Characteristics (NIST Model):
o On-demand self-service: Provision resources without human intervention.
o Broad network access: Accessible via standard protocols (HTTP, APIs).
o Resource pooling: Shared infrastructure with multi-tenant isolation.
o Rapid elasticity: Auto-scaling based on demand.
o Measured service: Pay-per-use billing.
2. Cloud Deployment Models:
o Private Cloud: Built and managed by organizations (high cost/complexity).
o Public Cloud (AWS, Azure, GCP): Subscription-based, globally scalable.
3. Service Models:
o IaaS (EC2): Manage OS, apps, data; AWS manages infrastructure.
o PaaS (AWS Elastic Beanstalk): Deploy code; AWS manages runtime.
o SaaS (Gmail, Salesforce): Fully managed by provider.
4. AWS Infrastructure:
o Regions: Geographically isolated locations (e.g., us-east-1).
o Availability Zones (AZs): Redundant data centers within a region.
o Global Network: Low-latency, high-bandwidth connectivity.
5. AWS Management Tools:
o Console (GUI): Web-based interface.
o CLI/SDKs: Programmatic control (e.g., aws s3 ls).
o CloudShell: Browser-based CLI with pre-configured credentials.

AWS Services Covered

• IAM (Identity & Access Management): Create users/groups with policies.
• EC2: Virtual servers (IaaS).
• S3: Object storage.
• AWS Budgets: Track spending and set alerts.
• CloudShell: Integrated CLI tool.

Hands-On Steps (Brief)

1. AWS Free Tier Account Setup:
o Use a unique email and credit card.
o Avoid root user; create IAM users for daily tasks.
2. Billing Configuration:
o Enable billing access for IAM users.
o Set a monthly budget (e.g., $5) with alerts.
 3. Tool Installation:
o AWS CLI: Run commands locally (e.g., aws configure).
o Visual Studio Code: Edit code snippets.
o CloudShell: Use AWS’s browser-based CLI.

Best Practices
• Root User: Use only for critical tasks (e.g., account recovery).
• IAM: Assign least-privilege policies to users/groups.
• Cost Control: Terminate unused resources; leverage Free Tier.

Real-World Use Cases

• Startups use AWS to avoid upfront infrastructure costs.
• Enterprises replace on-premises email/file servers with SaaS (e.g., Gmail, Dropbox).

Summary & Key Takeaways

• Cloud computing offers scalability, cost-efficiency, and reduced management overhead.
• AWS leads in public cloud with 200+ services, global infrastructure, and rapid innovation.
• Always secure accounts with IAM and monitor spending via AWS Budgets.

Section 2: Amazon Web Services Fundamentals

Overview:
This section delves into AWS’s global infrastructure, the shared responsibility model, APIs, pricing
frameworks, and the core advantages of cloud computing.

Key Concepts
1. AWS Global Infrastructure:
o Regions: Geographically isolated locations (e.g., us-east-1). Each region has
multiple Availability Zones (AZs).
o Availability Zones (AZs): One or more redundant data centers within a region.
Designed for fault tolerance (e.g., power/networking redundancy).
o Edge Locations: Part of Amazon CloudFront (CDN) to cache content closer to users
for low latency.
o Specialized Zones:
▪ AWS Outposts: Run AWS services on-premises.
▪ Local Zones: Extend regions to metropolitan areas for latency-sensitive apps.
▪ Wavelength Zones: Embed AWS services in 5G networks for mobile/edge
computing.
2. Shared Responsibility Model:
o AWS Responsibility: Security of the cloud (physical infrastructure, hardware, global
network).
o Customer Responsibility: Security in the cloud (data encryption, IAM policies,
OS/application patches, network/firewall configurations).
 3. APIs (Application Programming Interfaces):
o Definition: Rules/protocols for programmatic interaction with AWS services via HTTP
methods (GET, POST, PUT, DELETE).
o Examples:
▪ S3 API: GetObject (download files) or PutObject (upload files).
▪ EC2 API: RunInstances (launch virtual servers).
o Universal Use: Every AWS action (via Console, CLI, or SDK) translates to an API call.
4. AWS Pricing Models:
o Pay-as-You-Go: Default model; pay for compute (per second), storage (per GB), and
data transfer out of AWS.
o Save When You Reserve: Up to 75% discount for committing to 1- or 3-year terms (e.g.,
EC2 Reserved Instances).
o Volume-Based Discounts: Tiered pricing (e.g., S3 storage costs decrease with higher
usage).
5. Six Advantages of Cloud Computing (AWS):
o 1. Trade Capex for Opex: Shift from upfront costs to operational expenses.
o 2. Economies of Scale: Lower costs via AWS’s aggregated infrastructure.
o 3. Stop Guessing Capacity: Scale dynamically; avoid over-provisioning.
o 4. Speed & Agility: Rapid deployment of global resources.
o 5. No Data Center Management: Focus on innovation, not infrastructure.
o 6. Go Global in Minutes: Deploy apps worldwide with ease.

AWS Services Covered

• EC2 (Elastic Compute Cloud): Virtual servers (IaaS).
• S3 (Simple Storage Service): Object storage with APIs.
• IAM (Identity & Access Management): User/role permissions.
• CloudFront: Content Delivery Network (CDN).
• AWS Outposts: Hybrid cloud deployments.

Diagrams/Visual Aids
1. AWS Global Network:
o Regions → Availability Zones → Subnets (public/private).
o Low-latency connections between AZs; high redundancy within regions.
2. Shared Responsibility Model:
o AWS (bottom layer: hardware, regions) vs. Customer (top layer: data, apps, access
controls).

Best Practices
• Infrastructure Design: Deploy resources across multiple AZs for high availability.
• Cost Control: Use Reserved Instances for predictable workloads; monitor data transfer costs.
• Security: Follow least privilege in IAM; encrypt data at rest/in transit.
Real-World Use Cases
• Netflix: Uses CloudFront for global video streaming.
• Startups: Leverage pay-as-you-go to avoid upfront infrastructure costs.
• Enterprises: Use Reserved Instances to reduce long-term compute expenses.

Summary & Key Takeaways

• AWS’s global infrastructure ensures redundancy and low latency.
• Security is a shared duty: AWS handles physical infrastructure; customers manage data/apps.
• Every AWS interaction is an API call.
• Pricing flexibility (pay-as-you-go, reserved, volume discounts) supports cost optimization.
• Cloud advantages include scalability, agility, and reduced operational overhead.

Section 3: AWS Authentication and Access Control

Overview:
This section focuses on AWS Identity and Access Management (IAM) and IAM Identity Center. Topics
include user/group/role management, policies, authentication/authorization, and centralized identity
management for multi-account environments.

Key Concepts
1. IAM Fundamentals:
o Users: Individual accounts with permissions (e.g., User: Joe).
o Groups: Collections of users with shared permissions (e.g., Admin Group).
o Roles: Temporary permissions for users/apps (e.g., EC2-Role).
o Policies: JSON documents defining permissions (e.g., AdministratorAccess policy).
2. Authentication vs. Authorization:
o Authentication: Verifying identity (e.g., password, MFA).
o Authorization: Permissions granted via policies.
3. IAM Roles & STS:
o Security Token Service (STS): Generates temporary credentials for role assumption.
o Role Switching: Users assume roles for temporary permissions (e.g., sts:AssumeRole).
4. IAM Identity Center:
o Single Sign-On (SSO): Centralized access to AWS accounts and SaaS apps.
o Permission Sets: Predefined/custom permissions (e.g., ViewOnlyAccess).
o Integration: Works with AWS Organizations for multi-account management.
5. Shared Responsibility Model:
o AWS Responsibility: Infrastructure security.
o Customer Responsibility: User permissions, data encryption, MFA.

AWS Services Covered

• IAM: Manage users, groups, roles, and policies.
• IAM Identity Center: SSO and centralized identity management.
• AWS Organizations: Multi-account billing and policy management.
• STS: Temporary credentials for role assumption.
Hands-On Steps (Brief)
1. Create IAM User/Group:
o Create a user (e.g., Joe) and assign to a group (e.g., Admins).
o Attach policies (e.g., AdministratorAccess).
2. IAM Role Creation:
o Define a role (e.g., EC2-Role) with trusted entities (AWS account/users).
o Attach policies (e.g., AmazonEC2FullAccess).
3. Role Switching:
o Grant users sts:AssumeRole permission.
o Use the AWS console or CLI to switch roles.
4. IAM Identity Center Setup:
o Enable AWS Organizations.
o Create permission sets (e.g., Admin, ViewOnly).
o Assign users/groups to accounts with specific permissions.

Best Practices
• Avoid Root User: Use IAM users/roles for daily tasks.
• Least Privilege: Grant minimal necessary permissions.
• MFA: Enable multi-factor authentication for all users.
• Use Roles: Temporary access reduces long-term security risks.
• Centralize with Identity Center: Simplify SSO for multi-account environments.

Real-World Use Cases

• Enterprise SSO: Employees use one login for multiple AWS accounts and SaaS apps (e.g.,
Salesforce).
• Temporary Access: Developers assume roles for EC2 management without permanent
permissions.
• Auditing: Assign ViewOnly permissions to auditors for compliance checks.

Summary & Key Takeaways

• IAM is critical for securing AWS resources via users, groups, roles, and policies.
• Roles provide temporary, scoped permissions, enhancing security.
• IAM Identity Center simplifies SSO and centralized access control for enterprises.
• Policies define permissions in JSON; always follow least privilege.
• AWS Organizations + Identity Center streamline multi-account management.
 Section 4.1: Amazon EC2, Auto Scaling, and Load Balancing
Overview:
This section introduces Amazon EC2 (Elastic Compute Cloud), Auto Scaling, and Elastic Load
Balancing (ELB). Topics include server virtualization, scaling strategies, high availability, fault
tolerance, and hands-on EC2 instance deployment.

Key Concepts
1. Server Virtualization:
o Hypervisor: Software layer (e.g., KVM, Xen) enabling multiple virtual machines (VMs) to
run on a single physical server.
o Benefits: Resource efficiency, portability, rapid deployment, and scalability.
2. Scaling Strategies:
o Vertical Scaling (Scaling Up):
▪ Increase resources (CPU, RAM) of a single instance (e.g., upgrading
from t2.micro to c5.xlarge).
▪ Use cases: Databases (e.g., MySQL) needing more compute power.
o Horizontal Scaling (Scaling Out):
▪ Add more instances to distribute load (e.g., deploying
multiple t2.micro instances).
▪ Use cases: Stateless web servers (e.g., static websites).
3. High Availability (HA) vs. Fault Tolerance (FT):
o HA: Minimizes downtime by distributing workloads across AZs (e.g., using Auto
Scaling and ELB).
▪ Services: ELB, Route 53 (DNS failover).
o FT: Zero downtime via redundant components (e.g., RAID 1, synchronous replication).
▪ AWS handles underlying FT (e.g., redundant power/networking).
4. Durability vs. Availability:
o Durability: Protection against data loss (e.g., S3 offers 99.999999999% durability).
o Availability: Percentage of time data/services are accessible (e.g., 99.99% uptime).

AWS Services Covered

• EC2: Virtual servers with customizable OS, CPU, RAM, and storage.
• EBS (Elastic Block Store): Persistent block storage (e.g., GP3 for general use, IO2 for high
IOPS).
• Auto Scaling: Automatically adjusts instance count based on demand.
• Elastic Load Balancing (ELB): Distributes traffic across instances in multiple AZs.
• IAM Roles: Secure permissions for EC2 instances (preferred over access keys).

EC2 Instance Fundamentals

1. Instance Types:
o General Purpose (e.g., t2.micro): Balanced CPU/memory.
o Compute Optimized (e.g., c5.xlarge): High CPU for batch processing.
o Memory Optimized (e.g., r5.large): High RAM for databases.
o Storage Optimized (e.g., i3.large): High disk throughput.
 2. Networking:
o ENI (Elastic Network Interface): Virtual network adapter.
o Public vs. Private IPs: Public IPs for internet access; Private IPs for internal
communication.
o Security Groups: Firewall rules controlling inbound/outbound traffic (e.g., open SSH on
port 22).
3. Storage Options:
o EBS Volumes: Persistent, network-attached storage (attached to instances).
o Instance Store: Ephemeral, high-speed storage (data lost on instance stop/terminate).

Hands-On Steps (Brief)

1. Launching an EC2 Instance:
o Step 1: Choose an AMI (Amazon Machine Image) (e.g., Amazon Linux 2023).
o Step 2: Select instance type (e.g., t2.micro).
o Step 3: Configure security group (e.g., allow SSH/RDP).
o Step 4: Create/key pair (.pem file for SSH).
2. Connecting to Instances:
o Linux: Use SSH (e.g., ssh -i key.pem ec2-user@<public-IP>).
o Windows: Use RDP with decrypted password from AWS Console.
3. IAM Roles for EC2:
o Best Practice: Assign roles (e.g., S3ReadAccess) instead of hardcoding access keys.
o Temporary Credentials: Automatically rotated via AWS STS.

Best Practices
• Security:
o Use IAM roles over access keys.
o Restrict security group rules (e.g., limit SSH/RDP to trusted IPs).
• Cost Optimization:
o Use Auto Scaling to terminate unused instances.
o Choose Spot Instances for non-critical workloads.
• High Availability:
o Deploy instances across multiple AZs.
o Use ELB to distribute traffic.

Real-World Use Cases

• Web Application: Auto Scaling + ELB ensures traffic is distributed across instances during
spikes.
• Database: Use EBS GP3 volumes for persistent storage and vertical scaling.
• Big Data: Use compute-optimized instances for data processing.
 Section 4.2: Amazon EC2, Auto Scaling, and Load Balancing
Overview:
This section covers secure credential management with IAM roles, automating instance setup via user
data, Auto Scaling for dynamic resource allocation, and Elastic Load Balancing (ELB) for traffic
distribution.

Key Concepts
1. IAM Roles vs. Access Keys:
o Access Keys: Long-term credentials stored on instances (security risk if compromised).
o IAM Roles: Temporary credentials via AWS STS (Security Token Service) for secure,
short-term access (best practice).
2. User Data Scripts:
o Automate instance initialization (e.g., install Apache, configure web pages).
o Executes once at launch.
o Example: Script to install a web server and display the instance’s availability zone.
3. Auto Scaling:
o Launch Template: Defines EC2 configurations (AMI, instance type, security groups,
user data).
o Auto Scaling Group (ASG): Manages instance count across AZs.
▪ Scaling Policies:
▪ Target Tracking: Adjusts capacity based on metrics (e.g., CPU utilization,
request count).
▪ Health Checks: Terminates unhealthy instances and launches
replacements.
o Use Cases: Maintain availability, handle demand spikes, replace failed instances.
4. Elastic Load Balancing (ELB):
o Application Load Balancer (ALB):
▪ Operates at Layer 7 (HTTP/HTTPS).
▪ Routes traffic based on URL paths or hostnames.
o Target Groups: Group instances/containers for traffic distribution.
o Health Checks: Ensure only healthy instances receive traffic.

AWS Services Covered

• EC2: Virtual servers with customizable configurations.
• IAM Roles: Secure permissions for EC2 instances.
• Auto Scaling: Dynamic scaling of EC2 instances.
• Elastic Load Balancing (ALB): Distributes traffic across instances.
• CloudWatch: Monitors metrics (e.g., CPU, request count) to trigger scaling.

Hands-On Steps (Brief)

1. IAM Role Setup:
o Create a role (e.g., S3ReadOnly) and attach policies (e.g., AmazonS3ReadOnlyAccess).
o Assign the role to EC2 instances (replaces access keys).
 2. Launch EC2 with User Data:
o Use a script to install Apache and configure a custom webpage.
o Example script:
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Instance AZ: $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-
zone)</h1>" > /var/www/html/index.html

3. Auto Scaling Group:

o Create a launch template with user data.
o Configure ASG to maintain 2 instances across 2 AZs.
o Attach a target group for ELB integration.
4. Application Load Balancer:
o Create a target group (e.g., TG-1) for EC2 instances.
o Configure ALB to listen on HTTP:80 and route traffic to the target group.
5. Dynamic Scaling Policy:
o Set a target tracking policy (e.g., 50 requests per instance).
o Use CloudWatch alarms to trigger scaling (scale-out on high demand, scale-in when
idle).

Best Practices
• Security:
o Use IAM roles instead of access keys.
o Restrict security groups to necessary ports (e.g., HTTP:80, SSH:22).
• Cost Optimization:
o Use Spot Instances for non-critical workloads.
o Terminate unused instances.
• High Availability:
o Deploy instances across multiple AZs.
o Use ELB to distribute traffic and Auto Scaling to replace failed instances.

Real-World Use Cases

• Web Application: ALB distributes traffic to ASG-managed instances, scaling during traffic
spikes.
• Disaster Recovery: Auto Scaling replaces failed instances in different AZs.
• Microservices: ALB routes requests to specific services based on URL paths.
 Section 5: Amazon Virtual Private Cloud (VPC)
Key Concepts
• VPC: A logically isolated virtual network in AWS where you can launch resources (EC2, RDS)
with full control over IP ranges, subnets, routing, and security.
• OSI Model: A 7-layer framework for networking; AWS focuses on Layer 3 (IP/routing), Layer 4
(ports/security groups), and Layer 7 (application load balancers).
• CIDR Blocks: Define IP address ranges for VPCs/subnets (e.g., 10.0.0.0/16).
• Security Groups: Stateful firewalls at the instance level.
• NACLs: Stateless firewalls at the subnet level.

Detailed Notes
1. OSI Model & AWS Relevance
7 Layers:
1. Physical (Layer 1): Hardware (cables, NICs). Managed by AWS.
2. Data Link (Layer 2): MAC addresses/switches. Rarely configured in AWS.
3. Network (Layer 3): IP addresses/routing (VPC, route tables).
4. Transport (Layer 4): TCP/UDP ports (Security Groups, NACLs).
5. Session (Layer 5): Manages connections (handled by AWS services).
6. Presentation (Layer 6): Data encryption/compression (SSL/TLS).
7. Application (Layer 7): HTTP/HTTPS (Application Load Balancers).
AWS Focus:
• Layer 3: Configuring VPCs, subnets, and route tables.
• Layer 4: Managing security groups (TCP/UDP rules).
• Layer 7: Application Load Balancers (content-based routing).

2. Networking Devices
• Switches (Layer 2): Connect devices in the same subnet using MAC addresses.
• Routers (Layer 3): Route traffic between subnets/IP ranges.
• Firewalls:
o Stateful (Security Groups): Track connections (allow return traffic automatically).
o Stateless (NACLs): Require explicit inbound/outbound rules.

3. IP Addressing & CIDR

• IPv4 Structure:
o Network ID: Shared by all devices in a subnet (e.g., 10.0.0.0).
o Host ID: Unique to each device (e.g., 0.1).
• Subnet Masks: Define network vs. host bits (e.g., 255.255.255.0 = /24).
• Private IP Ranges (RFC 1918):
o 10.0.0.0/8
o 172.16.0.0/12
o 192.168.0.0/16
4. VPC Configuration
Components:
• Subnets: Isolated within an Availability Zone (AZ).
• Internet Gateway (IGW): Allows public internet access.
• Route Tables: Define traffic paths (e.g., route 0.0.0.0/0 to IGW for public subnets).
• NAT Gateway: Enables private subnet resources to access the internet.
Hands-On Setup:
1. Create VPC: Define CIDR (e.g., 10.0.0.0/16).
2. Create Subnets: Public (e.g., 10.0.1.0/24 in us-east-1a) and private (10.0.3.0/24).
3. Attach IGW and update route tables for public subnets.
4. Auto-assign Public IP: Enable for public subnets.

5. Security Groups vs. NACLs

Feature Security Groups NACLs

Scope Instance-level Subnet-level

State Stateful (auto-allow return traffic) Stateless (require explicit rules)

Rules Allow only Allow/Deny

Evaluation All rules checked Processed in order (1st match wins)

Example:
• Security Group: Allow SSH (port 22) from 0.0.0.0/0.
• NACL: Deny inbound traffic from a specific IP (192.168.1.1/32).

6. Cloud Deployment Models

1. Private Cloud: On-premises infrastructure (e.g., VMware, OpenStack).
2. Public Cloud: AWS, Azure, Google Cloud (pay-as-you-go).
3. Hybrid Cloud: Mix of on-premises + public cloud (e.g., VPN/Direct Connect).
4. Multi-Cloud: Use multiple cloud providers (AWS + Azure).

7. VPN & Direct Connect

• Site-to-Site VPN: Encrypted connection over the internet using Virtual Private
Gateway (AWS) and Customer Gateway (on-premises).
• Direct Connect: Dedicated private fiber connection to AWS (lower latency, higher cost).
Use Cases:
• VPN: Cost-effective for low/moderate data.
• Direct Connect: High-throughput, mission-critical workloads.
 Section 6: AWS Storage Services
Key Concepts
• Storage Types:
o Block Storage (EBS): Virtual hard disks for EC2 instances.
o File Storage (EFS): Shared file system accessible via NFS.
o Object Storage (S3): Scalable storage for unstructured data (files, images).
• Persistence:
o EBS: Persistent, survives instance termination.
o Instance Store: Ephemeral (data lost on instance stop/termination).
• Snapshots & AMIs:
o Snapshots: Point-in-time backups of EBS volumes stored in S3.
o AMIs (Amazon Machine Images): Templates for EC2 instances, backed by snapshots.

Detailed Notes
1. Block Storage: Amazon Elastic Block Store (EBS)
• Volume Types:
o GP3: General-purpose SSD (default).
o IO1/IO2: High-performance SSD for I/O-intensive workloads.
o Throughput Optimized HDD (st1): Low-cost HDD for big data.
• Features:
o Attached to EC2 instances within the same Availability Zone (AZ).
o Snapshots:
▪ Incremental backups stored in S3.
▪ Can create volumes/AMIs across AZs or regions.
• Hands-On:
o Create/Attach Volume:
# Create a 10GB GP3 volume in us-east-1a
aws ec2 create-volume --availability-zone us-east-1a --size 10 --volume-type gp3

o Mount Volume:
sudo mkfs -t ext4 /dev/xvdf # Format
sudo mount /dev/xvdf /data # Mount to /data

2. File Storage: Amazon Elastic File System (EFS)

• Deployment Options:
o Regional: Mount targets in multiple AZs (high availability).
o One Zone: Single AZ (lower cost).
• Features:
o Uses NFSv4.1 protocol (Linux-only).
o Storage Classes: Standard, Infrequent Access (IA), Archive.
o Encryption: Enabled by default (SSL/TLS in transit, AES-256 at rest).
 • Hands-On:
o Create EFS File System:
▪ Enable mount targets in desired AZs.
▪ Attach security group allowing NFS (port 2049).
o Mount EFS:
sudo yum install -y amazon-efs-utils
sudo mount -t efs -o tls fs-12345678:/ /mnt/efs

3. Object Storage: Amazon S3

• Components:
o Buckets: Globally unique containers for objects.
o Objects: Files stored with a key (filename), metadata, and version ID.
• Storage Classes:
o Standard: Frequent access.
o IA/One Zone-IA: Infrequent access.
o Glacier: Long-term archival.
• Features:
o Versioning: Track object versions.
o Static Website Hosting: Serve HTML/CSS/JS directly from S3.
o Bucket Policies: JSON-based access control (e.g., public read access).
• Hands-On:
o Create Bucket & Upload Objects:
aws s3 mb s3://my-unique-bucket-name
aws s3 cp image.jpg s3://my-unique-bucket-name
o Static Website Setup:
▪ Enable static website hosting in bucket properties.
▪ Upload index.html and configure bucket policy for public access.
// Bucket Policy Example
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}]
}

AWS Services Covered

• EBS: Block storage for EC2.
• EFS: Shared file storage for Linux.
• S3: Scalable object storage.
• Snapshots/AMIs: Backup and instance templates.
Key Differences

Feature EBS EFS S3

Access Single EC2 instance Multiple EC2 instances HTTP/API-based

Persistence Persistent Persistent Persistent

Use Case Boot volumes, databases Shared apps, CMS Static websites, backups

Protocol Block-level (attached disk) NFS REST API

Best Practices
• EBS: Use snapshots for backups; enable encryption.
• EFS: Use IA storage classes for cost savings; mount in multiple AZs for HA.
• S3: Enable versioning and lifecycle policies; restrict public access.

Section 7: AWS Database Services

Key Concepts
• Relational vs. Non-Relational Databases:
o Relational (RDS): Structured data with tables, rows, and rigid schemas (e.g., MySQL,
PostgreSQL). Scales vertically.
o Non-Relational (DynamoDB): Flexible schema, key-value/document stores. Scales
horizontally.
• OLTP vs. OLAP:
o OLTP (Operational): Real-time transaction processing (e.g., RDS, DynamoDB).
o OLAP (Analytical): Complex analytics (e.g., Redshift).
• Multi-AZ & Read Replicas:
o Multi-AZ: Automatic failover for disaster recovery.
o Read Replicas: Scale read traffic horizontally (asynchronous replication).

Detailed Notes
1. Amazon RDS (Relational Database Service)
• Features:
o Managed Service: Supports MySQL, PostgreSQL, Aurora, Oracle, SQL Server.
o Backups: Automated snapshots stored in S3.
o Scaling:
▪ Vertical: Upgrade instance size (requires downtime).
▪ Horizontal: Add read replicas (async replication).
o Multi-AZ Deployment: Sync replication to a standby instance in another AZ for failover.
• Use Cases: Transactional workloads (e.g., e-commerce, CRM).
Hands-On Setup:
1. Create RDS Instance:
o Choose engine (e.g., MySQL), enable Multi-AZ, configure security group (open port
3306).
o Set master username/password.
2. Create Read Replica:
o Replicate data to another AZ/region for read scaling.
3. Backup/Restore: Use snapshots for point-in-time recovery.

2. Amazon DynamoDB (NoSQL Database)

• Features:
o Serverless: No infrastructure management.
o Scalability: Auto-scaling with on-demand/provisioned capacity modes.
o Global Tables: Multi-region replication for low-latency access.
o Streams: Capture item-level changes for real-time processing (e.g., trigger Lambda
functions).
• Core Components:
o Tables: Containers for data.
o Items: Equivalent to rows (uniquely identified by partition + sort key).
o Attributes: Data fields (e.g., strings, numbers).
Hands-On Example:
• Create Table:
aws dynamodb create-table \
--table-name my_orders \
--attribute-definitions \
AttributeName=ClientID,AttributeType=S \
AttributeName=Created,AttributeType=N \
--key-schema \
AttributeName=ClientID,KeyType=HASH \
AttributeName=Created,KeyType=RANGE \
--billing-mode PAY_PER_REQUEST

• Load Data:
aws dynamodb batch-write-item --request-items file://batch-write.json

• Query Data:
aws dynamodb query \
--table-name my_orders \
--key-condition-expression "ClientID = :id" \
--expression-attribute-values '{":id":{"S":"[email protected]"}}'
AWS Services Covered

Service Use Case

RDS Managed relational databases (OLTP).

DynamoDB Serverless NoSQL for high-scale applications.

Redshift Data warehousing (OLAP).

ElastiCache In-memory caching (Redis/Memcached).

Best Practices
• RDS:
o Enable Multi-AZ for critical workloads.
o Use read replicas to offload read traffic.
o Encrypt data at rest (KMS) and enable automated backups.
• DynamoDB:
o Use partition keys for even data distribution.
o Enable auto-scaling for unpredictable workloads.
o Use global tables for multi-region redundancy.

Comparison: RDS vs. DynamoDB

Feature RDS DynamoDB

Schema Rigid (SQL) Flexible (NoSQL)

Scaling Vertical (instance upgrade) Horizontal (auto-scaling)

Pricing Instance + storage Throughput + storage

Use Case Complex queries, transactions High-scale, low-latency apps

 Section 8: Automation and DevOps on AWS
Key Concepts
• Infrastructure as Code (IaC): Define AWS resources using templates (JSON/YAML) for
repeatable deployments.
• Platform as a Service (PaaS): Deploy code without managing servers (Elastic Beanstalk).
• CI/CD Pipeline: Automate code integration, testing, and deployment (CodeCommit,
CodeBuild, CodePipeline).

1. AWS CloudFormation
Core Components:
• Templates: Define resources (EC2, VPC, S3) in JSON/YAML.
• Stacks: Deployments created from templates.
• Change Sets: Preview changes before applying updates.
• Stack Sets: Manage stacks across multiple accounts/regions.
Hands-On Workflow:
1. Create a Stack:
Resources:
MyEC2Instance:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-0abcdef1234567890
InstanceType: t2.micro

2. Update Stack: Use change sets to add resources (e.g., EBS volume, S3 bucket).
3. Delete Stack: Removes all associated resources automatically.
Best Practices:
• Use parameters for dynamic values (e.g., AMI IDs, CIDR blocks).
• Enable termination protection for critical stacks.

2. Elastic Beanstalk
Features:
• Managed Environments: Auto-scaling, load balancing, and health monitoring.
• Platforms: Supports Node.js, Java, .NET, Python, Docker, etc.
• Deployment Options: Web server (HTTP) or worker (background tasks via SQS).
Hands-On Example:
1. Deploy a Node.js App:
o Upload code (ZIP file) → Elastic Beanstalk provisions EC2, ASG, and ELB.
o Access via auto-generated domain (e.g., myapp.elasticbeanstalk.com).
2. Environment Management:
o Rollback versions, adjust instance types, enable HTTPS.
3. Terminate Environment: Deletes all associated resources (EC2, ASG, ELB).
Use Cases: Rapid deployment of web apps without managing infrastructure.
3. AWS Developer Tools (CI/CD)
Services:
• CodeCommit: Git-based source control.
• CodeBuild: Compile, test, and package code.
• CodePipeline: Orchestrate CI/CD stages (Source → Build → Deploy).
• CodeDeploy: Deploy code to EC2, Lambda, or Elastic Beanstalk.
CI/CD Pipeline Workflow:
1. CodeCommit: Developer pushes code to a Git repository.
2. CodeBuild: Build and test code; generate artifacts.
3. CodeDeploy: Deploy artifacts to Elastic Beanstalk/EC2.
Hands-On Setup:
1. Create a Pipeline:
o Source: CodeCommit repository.
o Build: Skip or configure CodeBuild.
o Deploy: Elastic Beanstalk environment.
2. Automate Updates: Code changes trigger pipeline → auto-deploy to production.

AWS Services Covered

Service Purpose

CloudFormation IaC for resource provisioning.

Elastic Beanstalk PaaS for app deployment.

CodeCommit Managed Git repositories.

CodePipeline CI/CD workflow automation.

Best Practices
• CloudFormation: Use nested stacks for modular templates.
• Elastic Beanstalk: Enable enhanced health monitoring.
• CI/CD: Integrate testing in CodeBuild to catch errors early.

Key Takeaways:
• IaC ensures consistency and reduces manual errors.
• PaaS simplifies deployment but offers less control than IaC.
• CI/CD automates the path from code commit to production.
 Section 9: DNS, Caching, and Performance Optimization
Overview
This section covers DNS management with Amazon Route 53, content delivery via Amazon
CloudFront, and performance optimization using AWS Global Accelerator. Focus areas include
reducing latency, improving bandwidth, and leveraging AWS’s global network infrastructure.

Key Concepts
1. Bandwidth vs. Latency
o Bandwidth: Data transfer rate (e.g., Gbps). Dictates how much data can be sent.
o Latency: Delay in data transmission (e.g., milliseconds). Primarily affected by distance
and network hops.
o Factors influencing latency: Propagation delay, transmission delay, queuing delay,
processing delay.
2. DNS Fundamentals
o Translates domain names (e.g., example.com) to IP addresses.
o Record Types:
▪ A: Maps domain to IPv4.
▪ CNAME: Alias for another domain.
▪ MX: Mail server records.
▪ NS: Authoritative name servers.
▪ TXT: Verification/security records.
3. Content Delivery Networks (CDNs)
o Amazon CloudFront: Caches content at edge locations globally.
▪ Reduces latency by serving content closer to users.
▪ Supports static/dynamic content, live streaming, and Lambda@Edge for
request/response manipulation.
4. Global Accelerator
o Uses anycast IPs to route traffic to the nearest AWS edge location.
o Operates at Layer 4 (TCP/UDP), ideal for non-HTTP(S) applications.
o Provides static IPs and automatic failover between regions.

AWS Services & Features

1. Amazon Route 53
• Domain Registration: Buy and manage domains (e.g., .com, .link).
• Routing Policies:
o Failover: Direct traffic based on health checks (active-passive).
o Geolocation: Route users by geographic location.
o Weighted: Split traffic between endpoints (e.g., 80% to Region A, 20% to Region B).
• Hosted Zones: Public (internet-facing) or private (VPC-specific).
2. Amazon CloudFront
• Edge Locations: 300+ globally for caching content.
• Origins: S3 buckets, EC2 instances, or custom servers.
 • Security:
o SSL/TLS via AWS Certificate Manager (ACM).
o Integration with AWS WAF and Shield for DDoS protection.
• Lambda@Edge: Custom code execution at edge locations (e.g., request redirection).
3. AWS Global Accelerator
• Anycast IPs: Single IP address served from multiple locations.
• Use Cases:
o Non-HTTP applications (e.g., gaming, IoT).
o High availability for multi-region deployments.
• Benefits: Reduced jitter, improved throughput via AWS backbone.

Hands-On Steps (Summarized)

1. Register a Domain with Route 53
1. Navigate to Route 53 > Registered Domains.
2. Search for a domain (e.g., example.com), complete checkout.
3. Note: Domain registration may require AWS Support intervention for new accounts.
2. Host a Static Website with S3 + CloudFront
1. Create an S3 Bucket:
o Enable static website hosting (set index.html).
o Apply a bucket policy allowing public read access.
2. Request an ACM Certificate:
o Validate domain ownership via DNS (CNAME record).
3. Create CloudFront Distribution:
o Origin: S3 bucket’s static website endpoint.
o Alternate domain name: example.com.
o Attach ACM certificate.
4. Route 53 Alias Record: Point example.com to the CloudFront distribution.
3. Set Up Global Accelerator
1. Create a Global Accelerator.
2. Attach endpoints (e.g., ALB in us-east-1 and eu-west-1).
3. Use the provided anycast IPs for traffic routing.

Use Cases & Best Practices

• Route 53: Use geolocation routing for localized content (e.g., regional pricing).
• CloudFront: Cache static assets (images, videos) to reduce origin load.
• Global Accelerator: Optimize VoIP or real-time apps requiring low latency.

Diagrams
1. DNS Resolution Flow:
User → Route 53 Query → DNS Server → IP Address → Web Server
2. CloudFront Architecture:
User → Edge Location (Cached Content)
│
└→ Origin (S3/EC2) if cache miss
 3. Global Accelerator Traffic Flow:
User → Edge Location → AWS Backbone → Healthy Endpoint (e.g., ALB)

Key Takeaways
1. Route 53 is a managed DNS service with advanced routing policies.
2. CloudFront accelerates content delivery and integrates with AWS security services.
3. Global Accelerator improves performance for TCP/UDP apps using AWS’s global network.
4. Always test DNS changes and monitor CloudFront cache hit ratios for optimization.

Section 10: Containers and Serverless Computing

Overview
This section explores containerization with Amazon ECS/Fargate, serverless architectures
using AWS Lambda, and application integration services like SQS, SNS, EventBridge, and API
Gateway. Focus areas include microservices, event-driven architectures, and building scalable, cost-
efficient cloud-native applications.

Key Concepts
1. Containers vs. Virtual Machines
o Containers: Lightweight, share the host OS kernel, faster startup, and lower overhead.
o VMs: Include a full OS, slower to start, and consume more resources.
o Docker: Tool for packaging applications into portable images (e.g., stored in Amazon
ECR or Docker Hub).
2. Microservices Architecture
o Decoupled components (e.g., user authentication, payment processing) deployed
independently.
o Benefits: Scalability, fault isolation, flexible tech stack per service, and API-driven
communication.
3. Serverless Computing
o No infrastructure management (AWS handles scaling, patching, HA).
o Pay-per-use pricing (e.g., AWS Lambda charges per execution time/memory).
4. Event-Driven Architecture
o Services trigger actions based on events (e.g., S3 upload → Lambda → DynamoDB).
o Tools: SQS (message queues), SNS (pub/sub), EventBridge (event bus).

AWS Services & Features

1. Amazon Elastic Container Service (ECS)
• Cluster: Logical group of tasks/services.
• Task Definition: Blueprint for containers (image, CPU/memory, networking).
• Launch Types:
o EC2: Manage EC2 instances (more control, lower cost for heavy workloads).
o Fargate: Serverless (no EC2 management, pay per task).
• Use Cases: Deploying web apps (e.g., WordPress + MySQL) with load balancers.
2. AWS Lambda
• Triggers: S3, SQS, API Gateway, CloudWatch Events, etc.
• Execution Role: IAM role granting permissions (e.g., access DynamoDB/S3).
• Features:
o Lambda@Edge: Process requests at CloudFront edge locations.
o Concurrency Limits: Control parallel executions.
o VPC Integration: Connect to private subnets (requires NAT gateway for internet
access).
3. Application Integration Services
• SQS: Message queue for decoupling components (pull-based, store-and-forward).
• SNS: Pub/sub service for notifications (push-based, supports email/SMS/Lambda).
• EventBridge: Central event bus for routing events (e.g., EC2 termination → SNS alert).
• API Gateway: Create REST/HTTP APIs to expose backend services (e.g., Lambda, EC2).

Hands-On Steps (Summarized)

1. Deploy a Container on AWS Fargate
1. Create ECS Cluster: Choose Fargate launch type.
2. Define Task: Specify Docker image (e.g., nginx:latest), port 80, and CloudWatch logging.
3. Run Task: Launch container with public IP; verify via browser.
2. Serverless App with Lambda + SQS + DynamoDB
1. Submit Function (Lambda):
o Code: Send order data to SQS queue.
o Permissions: sqs:SendMessage.
2. Process Function (Lambda):
o Triggered by SQS; write data to DynamoDB.
o Permissions: dynamodb:PutItem.
3. SQS Queue: Link to Lambda for automatic processing.
3. REST API with API Gateway
1. Create API: Define resources (e.g., /orders) and POST method.
2. Integrate Lambda: Proxy requests to submit-order function.
3. Enable CORS: Allow static website (hosted on S3) to access the API.
4. Deploy: Stage (e.g., prod) generates an invoke URL.

Use Cases & Best Practices

• ECS/Fargate: Deploy microservices (e.g., e-commerce backend).
• Lambda: Real-time file processing (e.g., resize images on S3 upload).
• SQS: Buffer orders during traffic spikes (decouples frontend/backend).
• EventBridge: Monitor compliance (e.g., alert on S3 bucket policy changes).
Diagrams
1. ECS Architecture:
ECS Cluster → Fargate Tasks (Containers) → ALB → End Users

2. Serverless Event Flow:

S3 Upload → Lambda → SQS → Lambda → DynamoDB

3. API Gateway Integration:

Browser → API Gateway (REST API) → Lambda → SQS/DynamoDB

Key Takeaways
1. Containers (ECS/Fargate) simplify deploying scalable apps without managing servers.
2. Lambda enables event-driven workflows with pay-per-use pricing.
3. SQS/SNS/EventBridge decouple components for resilient architectures.
4. API Gateway exposes backend services securely via REST APIs.
5. Always clean up unused resources (e.g., delete Fargate tasks, Lambda functions).

Section 11: Machine Learning and AI

Overview
This section explores generative AI as a learning/ productivity tool and AWS’s managed machine
learning (ML) services. Focus areas include leveraging AI for code generation, project design, and
integrating ML services into event-driven architectures.

Key Concepts
1. Generative AI as an Educational Tool
o Use Cases: Answering questions, generating code (e.g., Lambda functions), creating
AWS project ideas.
o Best Practices:
▪ Prompt Engineering: Be specific, include context, and iterate for refinement.
▪ Validation: Always test generated code and verify accuracy (AI can "hallucinate"
incorrect answers).
o Tools: ChatGPT (code generation, CLI commands, CloudFormation templates).
2. AWS Machine Learning Services
o Amazon Rekognition: Image/video analysis (objects, faces, text).
o Amazon Transcribe: Speech-to-text conversion.
o Amazon Translate: Real-time language translation.
o Amazon Comprehend: Natural language processing (sentiment analysis).
o Amazon Lex: Build conversational chatbots.
o Amazon CodeGuru: Automated code security and performance reviews.
AWS Services & Features
1. Generative AI Integration
• Code Generation: Use ChatGPT for Lambda functions, CLI commands, or CloudFormation
templates.
# Example: Lambda function code generated by ChatGPT
import boto3
def lambda_handler(event, context):
s3 = boto3.client('s3')
# Process S3 event
return {"statusCode": 200}
• Project Design: Generate end-to-end architectures (e.g., serverless apps with S3, Lambda,
DynamoDB).
2. Amazon Rekognition Workflow
1. Trigger: Image uploaded to S3 → S3 event notification.
2. Process: Lambda invokes Rekognition to analyze the image.
3. Store Results: Lambda writes metadata (e.g., detected objects) to DynamoDB.

Hands-On Steps (Summarized)

Image Analysis Pipeline
1. Create Resources:
o S3 Bucket: Store images (e.g., ml-rekognition-lab).
o DynamoDB Table: image-analysis-results (primary key: image-name).
2. Lambda Function:
o Runtime: Python 3.9.
o Permissions: Attach policies for Rekognition, DynamoDB, and S3.
o Code:
import boto3
rekognition = boto3.client('rekognition')
dynamodb = boto3.resource('dynamodb')

def lambda_handler(event, context):

bucket = event['Records'][0]['s3']['bucket']['name']
key = event['Records'][0]['s3']['object']['key']
response = rekognition.detect_labels(
Image={'S3Object': {'Bucket': bucket, 'Name': key}}
)
table = dynamodb.Table('image-analysis-results')
table.put_item(Item={'image-name': key, 'labels': response['Labels']})
3. Trigger: Configure S3 event to invoke Lambda on object upload.
4. Test: Upload images → Check DynamoDB for analysis results.
Use Cases & Best Practices
• Generative AI:
o Generate CLI commands for VPC setup.
o Debug code using CloudWatch logs.
• Rekognition: Identify objects in user-uploaded images (e.g., e-commerce catalogs).
• Comprehend: Analyze customer feedback sentiment.
• Security: Validate AI-generated code for vulnerabilities before deployment.

Key Takeaways
1. Generative AI accelerates learning and prototyping but requires validation.
2. AWS ML Services simplify adding intelligence to apps (no ML expertise needed).
3. Event-Driven ML: Combine S3, Lambda, and Rekognition for scalable image analysis.
4. CodeGuru/DevOps Guru: Enhance code quality and operational performance.