# AWS Cloud Rescue v4.1.0 — Guided Labs > A free, browser-only, AWS-inspired **educational simulator**. Nothing is deployed to AWS and no AWS credentials are required. The UI is a simplified training environment, not an exact copy of every AWS service screen. **Before starting:** Open [AWS Cloud Rescue](index.html#guided), choose Guided Labs, select the Region at the top right, and optionally **Load guided starter environment** from Console Home or Architecture Map. Ten labs share a guided-practice workspace; progress is local to this browser. Each lab has a field-by-field modal walkthrough via **Open step-by-step instructions**. Validation requires real simulated resource configuration, not just visiting pages. Starter resources intentionally have faults you will repair. **Modern console orientation:** Use the top Services button, unified search, favorites strip, Region selector, simulated CloudShell, and account menu. Contextual navigation appears within a service console; use the global Services menu to change services and the Favorites strip to open Learning Center. Use **Create**, **Edit**, and **Validate guided lab** as directed below. The generated HTML manual and in-app popup contain the same steps. **Persistence:** Use **Backup Workspace** before resetting or switching devices. A backup restores both tracks and your older saved challenge history. Instructor grading requires a separate results JSON export. ## Lab index - [Lab 1: Cloud Concepts — Launch a Workload](#lab-01) - [Lab 2: Cloud Economics — Monitor the Cost](#lab-02) - [Lab 3: Global Infrastructure — Multi-AZ Resilience](#lab-03) - [Lab 4: Security — Identity, Data & Audit](#lab-04) - [Lab 5: Networking — Restore Web Reachability](#lab-05) - [Lab 6: Compute — Healthy Multi-AZ Fleet](#lab-06) - [Lab 7: Storage — Durable, Versioned Objects](#lab-07) - [Lab 8: Databases — Protect Relational Data](#lab-08) - [Lab 9: Architecture — Queue & Serverless](#lab-09) - [Lab 10: Monitoring — Scale for Launch](#lab-10) ## Lab 01 — Cloud Concepts — Launch a Workload **Learning outcome:** Build a logically grouped VPC, subnet, firewall policy and EC2 instance. **Recommended sequence:** Complete earlier labs or load the guided starter if resources are missing. ### Step 1: Orient in the modern AWS-style console **Service / area:** 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 related resources within the current service category. Use the global Services menu to switch categories. Any changes here are simulated and saved only in this browser. **Evidence to check:** 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 / area:** 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 to check:** The VPC list contains nimbus-vpc with CIDR 10.20.0.0/16. ### Step 3: Create the first subnet **Service / area:** 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 to check:** The subnet list shows public-web-a linked to nimbus-vpc in zone a. ### Step 4: Configure a web security group **Service / area:** 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 to check:** web-sg belongs to nimbus-vpc and permits web traffic on ports 80 and 443. ### Step 5: Launch a simulated EC2 instance **Service / area:** 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 to check:** The instance table shows nimbus-web-a in Running state. ### Step 6: Validate Guided Lab 1 **Service / area:** 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 to check:** The lab passes its three required checks; practice XP is awarded only on first success. **Completion:** Return to Guided Lab Center, select this lab, and run its validator. Read the missing criteria, correct the configuration and validate again. --- ## Lab 02 — Cloud Economics — Monitor the Cost **Learning outcome:** Use right-sized EC2 capacity and an early warning budget. **Recommended sequence:** Complete earlier labs or load the guided starter if resources are missing. ### Step 1: Orient in the modern AWS-style console **Service / area:** 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 related resources within the current service category. Use the global Services menu to switch categories. Any changes here are simulated and saved only in this browser. **Evidence to check:** 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 / area:** 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 to check:** Every running EC2 instance is either t3.micro or t3.small. ### Step 3: Create a monthly simulated budget **Service / area:** 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 to check:** AWS Budgets shows a positive monthly budget and a threshold of 80%. ### Step 4: Run the cost-control validator **Service / area:** 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 to check:** All Lab 2 checks pass. Budget alerts in this simulation do not impose a real spending cap. **Completion:** Return to Guided Lab Center, select this lab, and run its validator. Read the missing criteria, correct the configuration and validate again. --- ## 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. **Recommended sequence:** Complete earlier labs or load the guided starter if resources are missing. ### Step 1: Orient in the modern AWS-style console **Service / area:** 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 related resources within the current service category. Use the global Services menu to switch categories. Any changes here are simulated and saved only in this browser. **Evidence to check:** 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 / area:** 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 to check:** Public web subnets exist in two distinct Availability Zones. ### Step 3: Place web servers in different zones **Service / area:** 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 to check:** Two Running EC2 instances reside in different zones of one VPC. ### Step 4: Configure the resilient load balancer **Service / area:** 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 to check:** The ALB has an enabled subnet and a Running target in each of two zones. ### Step 5: Add private database subnet coverage **Service / area:** 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 to check:** Two PRIVATE database subnets exist in distinct zones inside the application VPC. ### Step 6: Configure protected Multi-AZ RDS **Service / area:** 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 to check:** RDS uses a private subnet, encryption, Multi-AZ and private subnet coverage in two AZs. ### Step 7: Validate and test Availability Zone recovery **Service / area:** 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 to check:** All four Lab 3 checks pass and the modeled zonal-outage incident can be survived. **Completion:** Return to Guided Lab Center, select this lab, and run its validator. Read the missing criteria, correct the configuration and validate again. --- ## Lab 04 — Security — Identity, Data & Audit **Learning outcome:** Secure every bucket, administrator MFA and CloudTrail activity capture. **Recommended sequence:** Complete earlier labs or load the guided starter if resources are missing. ### Step 1: Orient in the modern AWS-style console **Service / area:** 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 related resources within the current service category. Use the global Services menu to switch categories. Any changes here are simulated and saved only in this browser. **Evidence to check:** 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 / area:** 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 to check:** At least one bucket is private and encrypted; no bucket remains publicly accessible. ### Step 3: Protect privileged IAM accounts **Service / area:** 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 to check:** At least one AdministratorAccess user has MFA enabled; none of the administrators lacks MFA. ### Step 4: Enable simulated activity auditing **Service / area:** 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 to check:** CloudTrail Trails shows at least one enabled training trail. ### Step 5: Validate security remediation **Service / area:** 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 to check:** All four mission checks pass, and remaining diagnostic warnings are understood. **Completion:** Return to Guided Lab Center, select this lab, and run its validator. Read the missing criteria, correct the configuration and validate again. --- ## Lab 05 — Networking — Restore Web Reachability **Learning outcome:** Create a safe web path through subnet routing, instance address and inbound rules without exposed SSH. **Recommended sequence:** Complete earlier labs or load the guided starter if resources are missing. ### Step 1: Orient in the modern AWS-style console **Service / area:** 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 related resources within the current service category. Use the global Services menu to switch categories. Any changes here are simulated and saved only in this browser. **Evidence to check:** 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 / area:** 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 to check:** A Public subnet exists and is in the correct VPC. ### Step 3: Allow web traffic while restricting SSH **Service / area:** 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 to check:** At least one group allows HTTP/HTTPS publicly and no group exposes SSH globally. ### Step 4: Connect reachable compute **Service / area:** 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 to check:** The instance is running, has public IP enabled, and is attached to a compatible web group. ### Step 5: Verify network reachability **Service / area:** 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 to check:** All four simulated networking criteria pass. **Completion:** Return to Guided Lab Center, select this lab, and run its validator. Read the missing criteria, correct the configuration and validate again. --- ## Lab 06 — Compute — Healthy Multi-AZ Fleet **Learning outcome:** Deploy a resilient load-balanced two-AZ compute fleet. **Recommended sequence:** Complete earlier labs or load the guided starter if resources are missing. ### Step 1: Orient in the modern AWS-style console **Service / area:** 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 related resources within the current service category. Use the global Services menu to switch categories. Any changes here are simulated and saved only in this browser. **Evidence to check:** 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 / area:** 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 to check:** There are at least two application subnets in distinct zones. ### Step 3: Deploy and start two hosts **Service / area:** 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 to check:** Two Running EC2 records exist in distinct Availability Zones. ### Step 4: Register both hosts with a load balancer **Service / area:** 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 to check:** The ALB has healthy Running targets in both enabled zones. ### Step 5: Validate compute resilience **Service / area:** 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 to check:** All three compute checks pass. **Completion:** Return to Guided Lab Center, select this lab, and run its validator. Read the missing criteria, correct the configuration and validate again. --- ## Lab 07 — Storage — Durable, Versioned Objects **Learning outcome:** Protect and version S3 object data, including a simulated upload. **Recommended sequence:** Complete earlier labs or load the guided starter if resources are missing. ### Step 1: Orient in the modern AWS-style console **Service / area:** 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 related resources within the current service category. Use the global Services menu to switch categories. Any changes here are simulated and saved only in this browser. **Evidence to check:** 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 / area:** s3 1. Open S3 Buckets and create nimbus-assets- 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 to check:** At least one secure versioned bucket exists; all other buckets are private and encrypted. ### Step 3: Upload an object metadata record **Service / area:** 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 to check:** The secure versioned bucket contains at least one simulated object record. ### Step 4: Validate object protection **Service / area:** 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 to check:** All four storage checks pass. **Completion:** Return to Guided Lab Center, select this lab, and run its validator. Read the missing criteria, correct the configuration and validate again. --- ## Lab 08 — Databases — Protect Relational Data **Learning outcome:** Use private AZ-separated database subnet coverage, RDS encryption and backups. **Recommended sequence:** Complete earlier labs or load the guided starter if resources are missing. ### Step 1: Orient in the modern AWS-style console **Service / area:** 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 related resources within the current service category. Use the global Services menu to switch categories. Any changes here are simulated and saved only in this browser. **Evidence to check:** 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 / area:** 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 to check:** Two private subnets exist in separate AZs within one VPC. ### Step 3: Create an encrypted private relational DB **Service / area:** 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 to check:** RDS is private, encrypted, Multi-AZ and has at least seven backup days. ### Step 4: Validate database resilience **Service / area:** 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 to check:** All four database checks pass, including private Multi-AZ subnet coverage. **Completion:** Return to Guided Lab Center, select this lab, and run its validator. Read the missing criteria, correct the configuration and validate again. --- ## Lab 09 — Architecture — Queue & Serverless **Learning outcome:** Decouple workloads with SQS, dead-letter handling and Lambda processing. **Recommended sequence:** Complete earlier labs or load the guided starter if resources are missing. ### Step 1: Orient in the modern AWS-style console **Service / area:** 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 related resources within the current service category. Use the global Services menu to switch categories. Any changes here are simulated and saved only in this browser. **Evidence to check:** 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 / area:** sqs 1. Open SQS Queues and create nimbus-email-jobs. 2. Turn Configure a dead-letter queue ON, then save. **Evidence to check:** A queue exists with DLQ handling enabled. ### Step 3: Attach the worker to SQS **Service / area:** 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 to check:** The Lambda record references the queue that has dead-letter handling enabled. ### Step 4: Enable checkout health checks **Service / area:** 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 to check:** At least one ALB with health checks has a Running registered target. ### Step 5: Validate decoupled checkout **Service / area:** 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 to check:** All four Well-Architected checks pass. **Completion:** Return to Guided Lab Center, select this lab, and run its validator. Read the missing criteria, correct the configuration and validate again. --- ## Lab 10 — Monitoring — Scale for Launch **Learning outcome:** Connect Auto Scaling to a healthy ALB; add CPU, application-error and budget signals. **Recommended sequence:** Complete earlier labs or load the guided starter if resources are missing. ### Step 1: Orient in the modern AWS-style console **Service / area:** 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 related resources within the current service category. Use the global Services menu to switch categories. Any changes here are simulated and saved only in this browser. **Evidence to check:** 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 / area:** 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 to check:** An ALB with healthy targets in two different enabled zones exists. ### Step 3: Configure Auto Scaling for burst traffic **Service / area:** 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 to check:** ASG is attached to the resilient ALB, supports 8 instances and has dynamic scaling enabled. ### Step 4: Add the CPU alarm **Service / area:** 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 to check:** An active CPU alarm exists. ### Step 5: Add the application error alarm **Service / area:** 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 to check:** An active application error alarm exists. ### Step 6: Review launch spend alerts **Service / area:** 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 to check:** A positive budget with an enabled percentage alert exists. ### Step 7: Validate launch readiness **Service / area:** 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 to check:** All five monitoring and scaling checks pass. **Completion:** Return to Guided Lab Center, select this lab, and run its validator. Read the missing criteria, correct the configuration and validate again. --- **Disclaimer:** AWS and AWS service names are trademarks of Amazon.com, Inc. or its affiliates. AWS Cloud Rescue is an independent educational simulation and is not affiliated with or endorsed by AWS.