Master cloud fundamentals with hands-on labs covering AWS, Azure, and multi-cloud architectures. Build real-world cloud solutions through interactive scenarios.
Cloud Foundation Labs - Module 1
Start your cloud journey with fundamental concepts and hands-on implementation across major cloud platforms.
Lab 1: AWS VPC Architecture Design
AWS / Intermediate
Scenario: Multi-Tier VPC Implementation
TechStartup Inc. needs a secure, scalable VPC architecture for their new e-commerce platform. Design and implement a multi-tier VPC with public and private subnets across multiple availability zones, configure NAT gateways, Internet gateway, and implement proper security groups and NACLs.
Learning Objectives:
VPC Design: Create a custom VPC with proper CIDR allocation
Subnet Architecture: Configure public and private subnets across AZs
Gateway Configuration: Set up Internet Gateway and NAT Gateways
Security Implementation: Configure Security Groups and NACLs
📋 Step-by-Step Instructions
Step 1: Create Custom VPC
🎯 Goal: Create a Virtual Private Cloud with CIDR 10.0.0.0/16
📝 What is a VPC?
A VPC is your own isolated network in AWS. Think of it as your private data center in the cloud where you have complete control over IP addressing, routing, and security.
🔍 What happens:
• AWS creates a VPC with ID (e.g., vpc-abc123)
• Reserves IP range 10.0.0.0 to 10.0.255.255
• Creates default route table and NACL
• VPC is isolated from other VPCs
💾 Save the VPC ID: export VPC_ID=vpc-xxxxxxxxx
💡 Pro Tip: /16 gives you 65,536 IPs. For smaller projects, /20 (4,096 IPs) is usually sufficient. Always plan for growth!
📖 Why 10.0.0.0/16? This is a private IP range (RFC 1918). It won't conflict with public internet IPs. Other options: 172.16.0.0/12 or 192.168.0.0/16
Step 2: Create Public & Private Subnets
🎯 Goal: Create 4 subnets across 2 Availability Zones for high availability
📝 Public vs Private Subnets:
• Public: Resources with direct internet access (web servers, load balancers)
• Private: Resources without direct internet (databases, internal apps)
💾 Save Subnet IDs: export PUBLIC_SUBNET_1A=subnet-xxx export PUBLIC_SUBNET_1B=subnet-yyy
💡 Best Practice: Always deploy across multiple AZs for 99.99% availability. Each AZ is a physically separate data center!
🏗️ Architecture: We're using /24 subnets (256 IPs each). 5 IPs per subnet are reserved by AWS. This leaves 251 usable IPs per subnet.
Step 3: Configure Internet Gateway (IGW)
🎯 Goal: Enable internet access for resources in public subnets
📝 What is an IGW?
The Internet Gateway is the door between your VPC and the internet. Without it, your VPC is completely isolated (good for security, bad for web apps!)
💻 Create Internet Gateway: aws ec2 create-internet-gateway
⚠️ Important: Just creating an IGW doesn't enable internet! You must also add a route (0.0.0.0/0 → IGW) in your route table.
✅ Security Note: Only public subnets should route to IGW. Private subnets use NAT Gateway instead (next step).
Step 4: Deploy NAT Gateways for Private Subnets
🎯 Goal: Allow private subnet resources to download updates from internet (outbound only)
📝 Why NAT Gateway?
Databases and app servers in private subnets can't reach the internet directly. NAT Gateway acts as a "proxy" - it allows outbound traffic (for updates, API calls) but blocks ALL inbound traffic from internet.
💻 Allocate Elastic IP (NAT needs a public IP): aws ec2 allocate-address --domain vpc
💻 Create NAT Gateway in Public Subnet: aws ec2 create-nat-gateway --subnet-id $PUBLIC_SUBNET_1A --allocation-id $EIP
⏱️ Wait 2-3 minutes for NAT to become available
💡 For high availability, create 2nd NAT in us-east-1b: aws ec2 create-nat-gateway --subnet-id $PUBLIC_SUBNET_1B --allocation-id $EIP2
💰 Cost Alert: NAT Gateways cost ~$0.045/hour (~$32/month) PLUS data transfer fees. For dev/test, consider NAT Instance (cheaper but less reliable).
🎓 Exam Tip: NAT Gateway is managed by AWS (no patching!). NAT Instance is an EC2 you manage yourself. Gateway is recommended for production.
Step 5: Configure Multi-Tier Security Groups
🎯 Goal: Implement defense-in-depth with layered security
📝 Security Groups = Virtual Firewalls:
Each tier (web, app, database) gets its own security group with least-privilege access. This is called "security by segmentation".
🔒 Security Best Practice: Notice how DB only accepts traffic from App tier, and App only from Web tier. This prevents direct database access from internet!
⛔ Never do this: Don't allow 0.0.0.0/0 on port 3306 (MySQL) or 22 (SSH). This is how databases get hacked!
Step 6: Test & Validate Your VPC Architecture
🎯 Goal: Verify connectivity and security configuration
✅ Test 1: Internet Connectivity from Public Subnet ping 8.8.8.8
Expected: Successful ping (proves IGW is working)
✅ Test 2: Outbound from Private Subnet curl http://checkip.amazonaws.com
Expected: Returns NAT Gateway's public IP (proves NAT works)
✅ Test 3: Security Group Validation aws ec2 describe-security-groups --group-ids $WEB_SG $APP_SG $DB_SG
🎓 Learning Checkpoint: Can you explain the traffic flow when a user visits your website? User → IGW → Public Subnet (Web) → App (Private) → Database (Private) → Response back!
📊 Real-world tip: In production, add VPC Flow Logs to CloudWatch for traffic monitoring and security analysis. This is auditing 101!
AWS CloudShell
aws-user@cloudshell:~$
Progress:0/6 tasks completed
Score: 0/100
🎉 After Completing All Steps - Review Your Work:
1. Validate Your Configuration: Click "Validate Configuration" to run automated checks. The scoring dashboard shows completion % and missing components. 2. View Architecture Diagram: Click "View Architecture" to see a professional network diagram showing subnets, gateways, and security groups. 3. Review What You Built:
• Public subnets with Internet Gateway access
• Private subnets with NAT Gateway
• Multi-tier security groups (Web → App → DB)
• Network isolation and segmentation
💡 Pro Tip: Compare your diagram with AWS reference architectures!
0%
Lab Completed!
Excellent VPC architecture!
Lab 2: Azure Virtual Network Architecture
Azure / Beginner
Scenario: Hub-Spoke Network Topology
GlobalCorp is migrating to Azure and needs a hub-spoke network architecture. Create resource groups, implement a hub virtual network with shared services, and connect multiple spoke VNets for different departments.
Learning Objectives:
Resource Organization: Create and manage resource groups
🎯 Goal: Organize Azure resources into logical groups
📝 What is a Resource Group?
A Resource Group is a container that holds related Azure resources. Think of it like a folder that groups your network components together for easier management and billing.
💻 Create Hub Resource Group: az group create --name RG-Network-Hub --location eastus
💻 Create Spokes Resource Group: az group create --name RG-Network-Spokes --location eastus
💡 Pro Tip: Separate Hub and Spoke resources into different RGs for better cost tracking and access control!
⚠️ Important: Type commands EXACTLY as shown. "eastus" not "eastu" - Azure will reject invalid locations!
Step 2: Deploy Hub Virtual Network
🎯 Goal: Create the central Hub VNet with shared services
📝 What is a Hub VNet?
The Hub is the central point of connectivity. It hosts shared services like VPN gateways, firewalls, and Azure Bastion that all Spoke networks use.
💡 Pro Tip: Hub uses 10.0.0.0/16 which gives 65,536 IPs for shared services. Spokes will use different ranges (10.1.x.x, 10.2.x.x).
Step 3: Create Spoke VNets
🎯 Goal: Create isolated networks for different departments/workloads
📝 What are Spoke VNets?
Spokes are isolated networks for different teams or applications. They connect to the Hub for shared services but are isolated from each other for security.
📖 Why separate address spaces? 10.0.x.x for Hub, 10.1.x.x for Dev, 10.2.x.x for Prod ensures no IP conflicts when peering!
Step 4: Configure VNet Peering
🎯 Goal: Connect Spokes to Hub for network communication
📝 What is VNet Peering?
Peering creates a direct connection between VNets using Microsoft's backbone network. Traffic never goes over the public internet - it's fast and secure!
💡 Critical: Peering MUST be created in BOTH directions! Hub→Spoke AND Spoke→Hub. Otherwise traffic won't flow!
⛔ Common Mistake: Forgetting the reverse peering. Always create 2 peerings per connection!
Step 5: Deploy Azure Bastion
🎯 Goal: Enable secure remote access to VMs without exposing RDP/SSH to internet
📝 What is Azure Bastion?
Azure Bastion provides secure RDP/SSH connectivity to your VMs directly from the Azure portal. No public IPs needed on your VMs - much more secure!
💻 First, create Public IP for Bastion: az network public-ip create --name Bastion-PIP --resource-group RG-Network-Hub --sku Standard
💡 Pro Tip: Bastion requires a dedicated subnet named "AzureBastionSubnet". In production, create this subnet first!
🔒 Security Benefit: With Bastion, your VMs don't need public IPs. Attackers can't directly reach them from the internet!
Step 6: Configure Network Security & Verify
🎯 Goal: Add NSGs and verify the network topology
📝 What is an NSG?
Network Security Groups act as virtual firewalls, controlling inbound and outbound traffic with rules based on source, destination, port, and protocol.
💻 Verify Network Topology: az network watcher show-topology --resource-group RG-Network-Hub
🎓 Learning Checkpoint: Can you trace how traffic flows from Spoke1 VM → Hub → Internet? Spoke1 → Peering → Hub VNet → Internet Gateway!
Azure Cloud Shell
azure-user@cloudshell:~$
Progress:0/6 tasks completed
Score: 0/100
🎉 After Completing All Steps - Review Your Work:
1. Validate Your Configuration: Click "Validate Configuration" to verify Azure resources. The dashboard shows completion status and missing peerings. 2. View Network Topology Diagram: Click "Network Topology" to see hub-spoke architecture with VNet peering, Bastion, and firewall. 3. Review What You Built:
• Hub VNet with Bastion, Firewall, VPN Gateway
• Spoke VNets for Dev and Production
• Bi-directional VNet peering
• Network Security Groups
💡 Pro Tip: Compare with Azure Cloud Adoption Framework reference architectures!
0%
Lab Completed!
Great hub-spoke architecture!
Lab 3: Multi-Cloud Storage Strategy
Multi-Cloud / Intermediate
Scenario: Cross-Cloud Data Replication
DataCorp needs a multi-cloud storage strategy for disaster recovery. Implement storage solutions across AWS S3 and Azure Blob Storage with cross-cloud replication.
Learning Objectives:
Multi-Cloud Storage: Configure S3 and Azure Blob
Data Replication: Implement cross-cloud sync
Security: Configure encryption
Cost Management: Implement lifecycle policies
📋 Step-by-Step Instructions
Step 1: Create AWS S3 Buckets
🎯 Goal: Create primary and disaster recovery S3 buckets in different regions
📝 What is S3?
Amazon S3 (Simple Storage Service) is object storage for the cloud. It's infinitely scalable, 99.999999999% durable, and perfect for backups, static websites, and data lakes.
🎯 Goal: Enable versioning for recovery and encryption for compliance
📝 Why Versioning?
Versioning keeps multiple versions of an object. If someone accidentally deletes or overwrites a file, you can restore the previous version!
🔒 Security Best Practice: Always enable encryption at rest. AES-256 is free with S3. For compliance (HIPAA, PCI), this is mandatory!
⚠️ Warning: Versioning increases storage costs (all versions are stored). Enable lifecycle policies to auto-delete old versions!
Step 3: Create Azure Storage Account
🎯 Goal: Create Azure Blob Storage for multi-cloud redundancy
📝 What is Azure Blob Storage?
Azure Blob Storage is Microsoft's object storage solution. It's similar to S3 but integrates with Azure services. Using both provides true multi-cloud disaster recovery!
💻 Create Storage Account with GRS: az storage account create --name datacorpstorage --resource-group RG-Storage --location eastus --sku Standard_GRS
💡 What is GRS? Geo-Redundant Storage automatically replicates your data to a secondary region 300+ miles away. 16 nines of durability!
💰 Cost Comparison: Azure Blob Hot tier: $0.021/GB vs S3 Standard: $0.023/GB. Azure is slightly cheaper for frequent access!
Step 4: Configure Azure Blob Containers
🎯 Goal: Create containers (similar to S3 buckets) for organizing data
📝 Containers vs Buckets:
Azure uses "containers" inside "storage accounts". One storage account can have many containers. It's like S3 buckets but with an extra level of organization.
💻 Create Primary Data Container: az storage container create --name primary-data --account-name datacorpstorage
💡 Pro Tip: Use separate containers for different data types or access patterns. Apply different access tiers (Hot/Cool/Archive) per container!
Step 5: Setup Cross-Region Replication
🎯 Goal: Sync data between AWS regions for disaster recovery
📝 What is S3 Sync?
The sync command compares source and destination, only copying new or modified files. It's efficient for keeping buckets synchronized.
💻 Sync Primary to DR Bucket: aws s3 sync s3://datacorp-primary-us-east-1 s3://datacorp-dr-us-west-2
💡 Pro Tip: For automatic replication, enable S3 Cross-Region Replication (CRR) instead of manual sync. CRR replicates in near real-time!
🌐 Multi-Cloud Tip: For true multi-cloud sync (AWS ↔ Azure), use tools like rclone, Azure Data Factory, or custom Lambda functions!
Step 6: Test Upload & Verify Status
🎯 Goal: Upload a test file and verify the multi-cloud setup works
💻 Upload Test File: aws s3 cp testfile.txt s3://datacorp-primary-us-east-1/
💻 Check Storage Status: show status
✅ Verification Checklist: Confirm file uploaded, check replication status, verify encryption is applied, and review cost dashboard!
🎓 Learning Checkpoint: You now have a multi-cloud storage strategy! AWS handles primary workloads, Azure provides additional redundancy. If AWS has an outage, Azure still has your data!
Multi-Cloud Terminal
cloud-storage@multi-cloud:~$
Progress:0/6 tasks completed
Score: 0/100
🎉 After Completing All Steps - Review Your Work:
1. Validate Your Setup: Click "Validate Setup" to check storage configurations and see completion percentage. 2. Test Replication Status: Click "Test Replication" to see sync status, latency, and health between AWS and Azure. 3. View Cost Analysis Dashboard:
Click "Cost Analysis" for cost comparison charts, pricing breakdown, and optimization tips.
4. Review What You Built:
• Multi-region S3 buckets with versioning/encryption
• Azure Storage with GRS replication
• Cross-cloud sync (AWS ↔ Azure)
• Enterprise disaster recovery setup
💡 Pro Tip: Lifecycle policies can reduce costs by 60-80%!