◈ AWS Cloud Rescue v4.1.0

Guided Lab Manual

Ten detailed, field-by-field AWS-inspired labs with interactive popups, validation and simulated resources.

All services are simulated in your browser. No real AWS account or charges.

Guided Lab 01 — Cloud Concepts — Launch a Workload

Learning outcome: Build a logically grouped VPC, subnet, firewall policy and EC2 instance.

Open lab in simulator →

Step 1: Orient in the modern AWS-style console

Service: home

  1. Start from Console Home. The dark top bar contains Services, unified search, the Region selector, simulated CloudShell and account controls.
  2. Confirm the Region in the top-right selector (for example N. Virginia / us-east-1); regional resources must stay in the same Region for this lab.
  3. Use the Services menu or type a service name into the top search field. Select a service result to open its resource table; use the blue Create action to provision resources.
  4. The left navigation shows resources in the current service category. Use the top Services menu to change categories. Any changes here are simulated and saved only in this browser.

Evidence: You can identify the current Region, find a service from the top bar and return to the Guided Lab Center.

Step 2: Create a training VPC

Service: vpc

  1. Select Your VPCs in the console, then choose Create VPC.
  2. Set Name tag to nimbus-vpc and IPv4 CIDR block to 10.20.0.0/16.
  3. Leave Enable DNS hostnames checked, then select the Create action.

Evidence: The VPC list contains nimbus-vpc with CIDR 10.20.0.0/16.

Step 3: Create the first subnet

Service: subnet

  1. Open Subnets and choose the Create action.
  2. Name the subnet public-web-a; choose the VPC you just created.
  3. Enter 10.20.1.0/24 for Subnet IPv4 CIDR; choose the selected Region’s Availability Zone a.
  4. Check Public subnet, then save.

Evidence: The subnet list shows public-web-a linked to nimbus-vpc in zone a.

Step 4: Configure a web security group

Service: sg

  1. Open Security Groups and choose the Create action.
  2. Enter web-sg as the Security group name and select nimbus-vpc.
  3. Set Inbound allowed TCP ports to 80,443 and source CIDR to 0.0.0.0/0.
  4. Leave outbound traffic enabled and save.

Evidence: web-sg belongs to nimbus-vpc and permits web traffic on ports 80 and 443.

Step 5: Launch a simulated EC2 instance

Service: ec2

  1. Open EC2 Instances, then choose Launch instance.
  2. Enter nimbus-web-a, select t3.micro, then choose public-web-a as its subnet.
  3. Select web-sg as the security group and Running as initial power state.
  4. Set Assign a simulated public IP ON and leave root volume at 20 GiB; create the instance.

Evidence: The instance table shows nimbus-web-a in Running state.

Step 6: Validate Guided Lab 1

Service: missions

  1. Return to Guided Lab Center, keeping Lab 1 selected.
  2. Select Validate guided lab and read each pass/fail criterion.
  3. If any criterion is missing, revisit that service and correct the configuration; run validation again.
  4. After validating, read the pass/fail evidence and revisit the linked services. You earn practice XP for completing the actual simulated checks, not for clicking Next.

Evidence: The lab passes its three required checks; practice XP is awarded only on first success.

Guided Lab 02 — Cloud Economics — Monitor the Cost

Learning outcome: Use right-sized EC2 capacity and an early warning budget.

Open lab in simulator →

Step 1: Orient in the modern AWS-style console

Service: home

  1. Start from Console Home. The dark top bar contains Services, unified search, the Region selector, simulated CloudShell and account controls.
  2. Confirm the Region in the top-right selector (for example N. Virginia / us-east-1); regional resources must stay in the same Region for this lab.
  3. Use the Services menu or type a service name into the top search field. Select a service result to open its resource table; use the blue Create action to provision resources.
  4. The left navigation shows resources in the current service category. Use the top Services menu to change categories. Any changes here are simulated and saved only in this browser.

Evidence: You can identify the current Region, find a service from the top bar and return to the Guided Lab Center.

Step 2: Review compute instance sizes

Service: ec2

  1. Open EC2 Instances and inspect the Instance type and State columns.
  2. If no instance exists, complete Lab 1 or create a new VPC, subnet and security group first.
  3. Start at least one instance, and edit every running instance to t3.micro or t3.small; larger types fail this exercise.

Evidence: Every running EC2 instance is either t3.micro or t3.small.

Step 3: Create a monthly simulated budget

Service: budget

  1. Open AWS Budgets and choose the Create action.
  2. Enter Name launch-operations-budget, Monthly amount 150 (simulated USD).
  3. Set Alert threshold (%) to 80, then save.

Evidence: AWS Budgets shows a positive monthly budget and a threshold of 80%.

Step 4: Run the cost-control validator

Service: missions

  1. Return to Guided Lab Center with Lab 2 selected.
  2. Select Validate guided lab and review the three checks.
  3. If the right-sizing check fails, inspect every Running EC2 instance; if the alert check fails, edit the budget.
  4. After validating, read the pass/fail evidence and revisit the linked services. You earn practice XP for completing the actual simulated checks, not for clicking Next.

Evidence: All Lab 2 checks pass. Budget alerts in this simulation do not impose a real spending cap.

Guided Lab 03 — Global Infrastructure — Multi-AZ Resilience

Learning outcome: Place application targets across two AZs and configure a private encrypted Multi-AZ database in the same VPC.

Open lab in simulator →

Step 1: Orient in the modern AWS-style console

Service: home

  1. Start from Console Home. The dark top bar contains Services, unified search, the Region selector, simulated CloudShell and account controls.
  2. Confirm the Region in the top-right selector (for example N. Virginia / us-east-1); regional resources must stay in the same Region for this lab.
  3. Use the Services menu or type a service name into the top search field. Select a service result to open its resource table; use the blue Create action to provision resources.
  4. The left navigation shows resources in the current service category. Use the top Services menu to change categories. Any changes here are simulated and saved only in this browser.

Evidence: You can identify the current Region, find a service from the top bar and return to the Guided Lab Center.

Step 2: Prepare two public application zones

Service: subnet

  1. Open Subnets and identify nimbus-vpc or another shared VPC.
  2. Ensure there is one public subnet in Availability Zone a and another in zone b, each with nonoverlapping CIDRs (for example 10.20.1.0/24 and 10.20.2.0/24).
  3. Create missing subnets in the SAME VPC, not unrelated networks.

Evidence: Public web subnets exist in two distinct Availability Zones.

Step 3: Place web servers in different zones

Service: ec2

  1. Open EC2 Instances. Start or create nimbus-web-a in your zone-a web subnet.
  2. Start or create nimbus-web-b in the zone-b web subnet.
  3. Attach a security group belonging to the same VPC and set both instances to Running.

Evidence: Two Running EC2 instances reside in different zones of one VPC.

Step 4: Configure the resilient load balancer

Service: elb

  1. Open Load Balancers and create or edit nimbus-app-alb.
  2. Set VPC to the web instances’ VPC. Under Choose subnets, check both the zone-a and zone-b WEB subnets.
  3. Under Choose EC2 targets, check both Running web instances.
  4. Enable simulated health checks and save the load balancer.

Evidence: The ALB has an enabled subnet and a Running target in each of two zones.

Step 5: Add private database subnet coverage

Service: subnet

  1. Open Subnets and create private-db-a with 10.20.10.0/24 in zone a.
  2. Create private-db-b with 10.20.11.0/24 in zone b.
  3. Both must use the EXACT VPC selected in the healthy load balancer (check its VPC ID). Leave Public subnet UNCHECKED for both.

Evidence: Two PRIVATE database subnets exist in distinct zones inside the application VPC.

Step 6: Configure protected Multi-AZ RDS

Service: rds

  1. Open RDS Databases; create or edit nimbus-db.
  2. Choose PostgreSQL and select private-db-a in the SAME VPC as the healthy ALB (the subnet dropdown now shows VPC, zone and public/private status).
  3. Enable Multi-AZ deployment and Storage encryption; turn Public accessibility OFF.
  4. Set Backup retention days to 7 or more and save.

Evidence: RDS uses a private subnet, encryption, Multi-AZ and private subnet coverage in two AZs.

Step 7: Validate and test Availability Zone recovery

Service: missions

  1. Return to Guided Lab Center and run validation for Lab 3.
  2. Fix any unmet checks; then optionally open Architecture Map and run Availability Zone outage.
  3. Interpret any test failure by checking the ALB targets, enabled zones and RDS subnet design.
  4. After validating, read the pass/fail evidence and revisit the linked services. You earn practice XP for completing the actual simulated checks, not for clicking Next.

Evidence: All four Lab 3 checks pass and the modeled zonal-outage incident can be survived.

Guided Lab 04 — Security — Identity, Data & Audit

Learning outcome: Secure every bucket, administrator MFA and CloudTrail activity capture.

Open lab in simulator →

Step 1: Orient in the modern AWS-style console

Service: home

  1. Start from Console Home. The dark top bar contains Services, unified search, the Region selector, simulated CloudShell and account controls.
  2. Confirm the Region in the top-right selector (for example N. Virginia / us-east-1); regional resources must stay in the same Region for this lab.
  3. Use the Services menu or type a service name into the top search field. Select a service result to open its resource table; use the blue Create action to provision resources.
  4. The left navigation shows resources in the current service category. Use the top Services menu to change categories. Any changes here are simulated and saved only in this browser.

Evidence: You can identify the current Region, find a service from the top bar and return to the Guided Lab Center.

Step 2: Remove public bucket exposure

Service: s3

  1. Open Amazon S3. Create a training bucket or edit an existing one.
  2. Turn Block all public access ON and Enable default encryption ON.
  3. Inspect every other existing bucket and enable Block all public access on each one.

Evidence: At least one bucket is private and encrypted; no bucket remains publicly accessible.

Step 3: Protect privileged IAM accounts

Service: iam

  1. Open IAM Users, create an account named launch-admin or edit an existing administrator.
  2. Set Permissions policy to AdministratorAccess.
  3. Turn MFA enabled ON. Repeat for ALL administrator users; a single unprotected administrator fails the check.

Evidence: At least one AdministratorAccess user has MFA enabled; none of the administrators lacks MFA.

Step 4: Enable simulated activity auditing

Service: cloudtrail

  1. Open CloudTrail Trails and choose the Create action or edit an existing trail.
  2. Enter trail name nimbus-audit.
  3. Check Recording API activity and save.

Evidence: CloudTrail Trails shows at least one enabled training trail.

Step 5: Validate security remediation

Service: missions

  1. Open the Learning Center from the Favorites strip and run Lab 4 validation.
  2. If S3 fails, inspect ALL bucket configurations. If identity fails, review every admin user.
  3. Optionally run Architecture Map → Security audit to check SSH and database settings too.
  4. After validating, read the pass/fail evidence and revisit the linked services. You earn practice XP for completing the actual simulated checks, not for clicking Next.

Evidence: All four mission checks pass, and remaining diagnostic warnings are understood.

Guided Lab 05 — Networking — Restore Web Reachability

Learning outcome: Create a safe web path through subnet routing, instance address and inbound rules without exposed SSH.

Open lab in simulator →

Step 1: Orient in the modern AWS-style console

Service: home

  1. Start from Console Home. The dark top bar contains Services, unified search, the Region selector, simulated CloudShell and account controls.
  2. Confirm the Region in the top-right selector (for example N. Virginia / us-east-1); regional resources must stay in the same Region for this lab.
  3. Use the Services menu or type a service name into the top search field. Select a service result to open its resource table; use the blue Create action to provision resources.
  4. The left navigation shows resources in the current service category. Use the top Services menu to change categories. Any changes here are simulated and saved only in this browser.

Evidence: You can identify the current Region, find a service from the top bar and return to the Guided Lab Center.

Step 2: Verify an internet-facing subnet

Service: subnet

  1. Open Subnets and locate the subnet holding the web instance.
  2. Ensure the subnet belongs to the intended VPC and has Public subnet CHECKED.
  3. If the selected subnet is private, edit it or create a new public web subnet in the VPC.

Evidence: A Public subnet exists and is in the correct VPC.

Step 3: Allow web traffic while restricting SSH

Service: sg

  1. Open Security Groups and inspect the group attached to the web instance.
  2. Set Inbound allowed TCP ports to 80 or 443 (both are acceptable).
  3. For a public web port set Inbound source CIDR to 0.0.0.0/0.
  4. Remove port 22 from any group using 0.0.0.0/0; this lab forbids internet-wide SSH.

Evidence: At least one group allows HTTP/HTTPS publicly and no group exposes SSH globally.

Step 4: Connect reachable compute

Service: ec2

  1. Open EC2 Instances. Edit or launch a Running instance in the public subnet.
  2. Attach the web security group that belongs to the same VPC.
  3. Check Assign a simulated public IP and save.

Evidence: The instance is running, has public IP enabled, and is attached to a compatible web group.

Step 5: Verify network reachability

Service: missions

  1. Return to Guided Lab Center and run Lab 5 validation.
  2. Resolve each failure by checking subnet Public, instance Public IP, and security-group port/source.
  3. Open Architecture Map for a visual review of relationships.
  4. After validating, read the pass/fail evidence and revisit the linked services. You earn practice XP for completing the actual simulated checks, not for clicking Next.

Evidence: All four simulated networking criteria pass.

Guided Lab 06 — Compute — Healthy Multi-AZ Fleet

Learning outcome: Deploy a resilient load-balanced two-AZ compute fleet.

Open lab in simulator →

Step 1: Orient in the modern AWS-style console

Service: home

  1. Start from Console Home. The dark top bar contains Services, unified search, the Region selector, simulated CloudShell and account controls.
  2. Confirm the Region in the top-right selector (for example N. Virginia / us-east-1); regional resources must stay in the same Region for this lab.
  3. Use the Services menu or type a service name into the top search field. Select a service result to open its resource table; use the blue Create action to provision resources.
  4. The left navigation shows resources in the current service category. Use the top Services menu to change categories. Any changes here are simulated and saved only in this browser.

Evidence: You can identify the current Region, find a service from the top bar and return to the Guided Lab Center.

Step 2: Prepare distinct application zones

Service: subnet

  1. Open Subnets and locate public web subnets in the same VPC but different Availability Zones.
  2. If there is only one web subnet, create another with a nonoverlapping CIDR in zone b.

Evidence: There are at least two application subnets in distinct zones.

Step 3: Deploy and start two hosts

Service: ec2

  1. Open EC2 Instances. Create or edit two instances: one in the zone-a subnet and one in the zone-b subnet.
  2. Give both a compatible VPC security group, and set State to Running.
  3. If a host is stopped, use the instance row actions to start it.

Evidence: Two Running EC2 records exist in distinct Availability Zones.

Step 4: Register both hosts with a load balancer

Service: elb

  1. Open Load Balancers and create or edit an ALB in the same VPC.
  2. Check both zonal web subnets under Choose subnets.
  3. Check both Running instance IDs under Choose EC2 targets, enable simulated health checks, and save.

Evidence: The ALB has healthy Running targets in both enabled zones.

Step 5: Validate compute resilience

Service: missions

  1. Return to Lab 6 in the Guided Lab Center and select Validate guided lab.
  2. If the ALB check fails, verify that targets, subnets and VPC all match, and that the two targets are in different AZs.
  3. Optionally stop one host, inspect incident feedback, then start it again and revalidate.
  4. After validating, read the pass/fail evidence and revisit the linked services. You earn practice XP for completing the actual simulated checks, not for clicking Next.

Evidence: All three compute checks pass.

Guided Lab 07 — Storage — Durable, Versioned Objects

Learning outcome: Protect and version S3 object data, including a simulated upload.

Open lab in simulator →

Step 1: Orient in the modern AWS-style console

Service: home

  1. Start from Console Home. The dark top bar contains Services, unified search, the Region selector, simulated CloudShell and account controls.
  2. Confirm the Region in the top-right selector (for example N. Virginia / us-east-1); regional resources must stay in the same Region for this lab.
  3. Use the Services menu or type a service name into the top search field. Select a service result to open its resource table; use the blue Create action to provision resources.
  4. The left navigation shows resources in the current service category. Use the top Services menu to change categories. Any changes here are simulated and saved only in this browser.

Evidence: You can identify the current Region, find a service from the top bar and return to the Guided Lab Center.

Step 2: Create a secure versioned bucket

Service: s3

  1. Open S3 Buckets and create nimbus-assets-<your-suffix> using lowercase letters and hyphens.
  2. Check Block all public access, Enable default encryption and Enable versioning.
  3. Review ALL other existing buckets; they must also block public access and use encryption.
  4. Save and open the bucket’s Details view.

Evidence: At least one secure versioned bucket exists; all other buckets are private and encrypted.

Step 3: Upload an object metadata record

Service: s3

  1. From the versioned bucket Details view, find Upload object.
  2. Enter key images/launch-banner.png and simulated size 120 KB.
  3. Confirm the upload. This simulator stores metadata only, not actual files.
  4. Optionally upload the same key again to observe version numbering.

Evidence: The secure versioned bucket contains at least one simulated object record.

Step 4: Validate object protection

Service: missions

  1. Open the Learning Center from the Favorites strip and select Lab 7.
  2. Run validation and check all four criteria.
  3. If the last check fails, ensure the object is in the SAME bucket with Block Public Access, encryption and versioning enabled.
  4. After validating, read the pass/fail evidence and revisit the linked services. You earn practice XP for completing the actual simulated checks, not for clicking Next.

Evidence: All four storage checks pass.

Guided Lab 08 — Databases — Protect Relational Data

Learning outcome: Use private AZ-separated database subnet coverage, RDS encryption and backups.

Open lab in simulator →

Step 1: Orient in the modern AWS-style console

Service: home

  1. Start from Console Home. The dark top bar contains Services, unified search, the Region selector, simulated CloudShell and account controls.
  2. Confirm the Region in the top-right selector (for example N. Virginia / us-east-1); regional resources must stay in the same Region for this lab.
  3. Use the Services menu or type a service name into the top search field. Select a service result to open its resource table; use the blue Create action to provision resources.
  4. The left navigation shows resources in the current service category. Use the top Services menu to change categories. Any changes here are simulated and saved only in this browser.

Evidence: You can identify the current Region, find a service from the top bar and return to the Guided Lab Center.

Step 2: Prepare private database zones

Service: subnet

  1. Open Subnets and find a VPC suitable for the application.
  2. Create private-db-a in AZ a (for example 10.20.10.0/24) and private-db-b in AZ b (10.20.11.0/24).
  3. Choose the SAME VPC for both, and leave Public subnet unchecked.

Evidence: Two private subnets exist in separate AZs within one VPC.

Step 3: Create an encrypted private relational DB

Service: rds

  1. Open RDS Databases and create or edit accounts-db.
  2. Choose MySQL or PostgreSQL and select private-db-a as Private subnet (primary).
  3. Turn Public accessibility OFF and Storage encryption ON.
  4. Enable Multi-AZ deployment and set Backup retention days to 7 or higher. Save changes.

Evidence: RDS is private, encrypted, Multi-AZ and has at least seven backup days.

Step 4: Validate database resilience

Service: missions

  1. Return to Lab 8 in Guided Lab Center and select Validate guided lab.
  2. If the Multi-AZ check fails, verify two PRIVATE subnets in different AZs exist in the same VPC as RDS.
  3. Optionally inject Database failure from Architecture Map.
  4. After validating, read the pass/fail evidence and revisit the linked services. You earn practice XP for completing the actual simulated checks, not for clicking Next.

Evidence: All four database checks pass, including private Multi-AZ subnet coverage.

Guided Lab 09 — Architecture — Queue & Serverless

Learning outcome: Decouple workloads with SQS, dead-letter handling and Lambda processing.

Open lab in simulator →

Step 1: Orient in the modern AWS-style console

Service: home

  1. Start from Console Home. The dark top bar contains Services, unified search, the Region selector, simulated CloudShell and account controls.
  2. Confirm the Region in the top-right selector (for example N. Virginia / us-east-1); regional resources must stay in the same Region for this lab.
  3. Use the Services menu or type a service name into the top search field. Select a service result to open its resource table; use the blue Create action to provision resources.
  4. The left navigation shows resources in the current service category. Use the top Services menu to change categories. Any changes here are simulated and saved only in this browser.

Evidence: You can identify the current Region, find a service from the top bar and return to the Guided Lab Center.

Step 2: Create a dead-letter-enabled queue

Service: sqs

  1. Open SQS Queues and create nimbus-email-jobs.
  2. Turn Configure a dead-letter queue ON, then save.

Evidence: A queue exists with DLQ handling enabled.

Step 3: Attach the worker to SQS

Service: lambda

  1. Open Lambda Functions and choose the Create action.
  2. Enter nimbus-email-worker and select Python 3.12 as the simulated runtime.
  3. Set SQS trigger queue to nimbus-email-jobs; enter timeout 30 seconds and save.

Evidence: The Lambda record references the queue that has dead-letter handling enabled.

Step 4: Enable checkout health checks

Service: elb

  1. Open Load Balancers; find an ALB with a Running instance registered.
  2. Edit it and turn Enable simulated health checks ON.
  3. If no ALB exists, first build the two-zone web ALB from Lab 6.

Evidence: At least one ALB with health checks has a Running registered target.

Step 5: Validate decoupled checkout

Service: missions

  1. Open the Learning Center from the Favorites strip and run Lab 9 validation.
  2. If Lambda fails, confirm SQS trigger queue points to the DLQ-enabled queue.
  3. Optionally inject Email integration outage from Architecture Map.
  4. After validating, read the pass/fail evidence and revisit the linked services. You earn practice XP for completing the actual simulated checks, not for clicking Next.

Evidence: All four Well-Architected checks pass.

Guided Lab 10 — Monitoring — Scale for Launch

Learning outcome: Connect Auto Scaling to a healthy ALB; add CPU, application-error and budget signals.

Open lab in simulator →

Step 1: Orient in the modern AWS-style console

Service: home

  1. Start from Console Home. The dark top bar contains Services, unified search, the Region selector, simulated CloudShell and account controls.
  2. Confirm the Region in the top-right selector (for example N. Virginia / us-east-1); regional resources must stay in the same Region for this lab.
  3. Use the Services menu or type a service name into the top search field. Select a service result to open its resource table; use the blue Create action to provision resources.
  4. The left navigation shows resources in the current service category. Use the top Services menu to change categories. Any changes here are simulated and saved only in this browser.

Evidence: You can identify the current Region, find a service from the top bar and return to the Guided Lab Center.

Step 2: Confirm a resilient target group

Service: elb

  1. Open Load Balancers and identify a load balancer attached to a Running EC2 target in each of two zones.
  2. Check that both zonal subnets and both target instances share the same VPC and health checks are enabled.
  3. Complete Lab 6 first if you do not yet have a two-zone application load balancer.

Evidence: An ALB with healthy targets in two different enabled zones exists.

Step 3: Configure Auto Scaling for burst traffic

Service: asg

  1. Open Auto Scaling Groups and create or edit a group.
  2. Set Application load balancer to your healthy two-zone ALB.
  3. Set Minimum capacity to 1, Desired capacity to 2, Maximum capacity to at least 8.
  4. Check Enable target-tracking scaling and save.

Evidence: ASG is attached to the resilient ALB, supports 8 instances and has dynamic scaling enabled.

Step 4: Add the CPU alarm

Service: alarm

  1. Open CloudWatch Alarms and create high-cpu-alert.
  2. Set Metric to EC2 CPUUtilization and Alarm threshold to 75 (a positive value).
  3. Check Alarm active and save.

Evidence: An active CPU alarm exists.

Step 5: Add the application error alarm

Service: alarm

  1. Create a second CloudWatch alarm called application-errors.
  2. Set Metric to Application 5XXError and threshold to a positive number, such as 10.
  3. Check Alarm active and save.

Evidence: An active application error alarm exists.

Step 6: Review launch spend alerts

Service: budget

  1. Open AWS Budgets; create or edit a budget with a positive Monthly amount.
  2. Set Alert threshold (%) to a value between 1 and 100 (80 is a useful practice setting), and save.

Evidence: A positive budget with an enabled percentage alert exists.

Step 7: Validate launch readiness

Service: missions

  1. Return to Lab 10 in Guided Lab Center and select Validate guided lab.
  2. If scaling fails, verify that the ASG is linked to the SAME healthy two-AZ ALB, not another balancer.
  3. Optionally inject the 8× flash traffic surge from Architecture Map.
  4. After validating, read the pass/fail evidence and revisit the linked services. You earn practice XP for completing the actual simulated checks, not for clicking Next.

Evidence: All five monitoring and scaling checks pass.