# AWS Cloud Rescue — Classic Console Lab Instructions

**Version:** 3.1 · **Mode:** Guided hands-on console labs · **Delivery:** Static HTML on Tencent EdgeOne Pages or any static host

> **Simulation only.** This is an independently developed AWS-inspired educational emulator, not the real AWS Management Console and not an AWS-operated service. It creates no real EC2, S3, network, IAM, or database resources. No AWS account, API key, payment method, or real cloud charges are required.

## Getting started

1. Open [`index.html`](index.html#missions) in a browser or visit your instructor's hosted URL. Select **Mission Center** or **Guided Console Labs**.
2. Choose a student workspace from the account menu (or create a new callsign and class section). Each browser saves its own simulated resources and scores.
3. Select the Region and keep it consistent while completing the missions. IAM and Budgets are modeled as global resources.
4. Select a numbered mission. The mission includes a storyline, grading criteria, and buttons taking you to the **actual simulated service pages**.
5. Follow the steps below using the resource-creation forms. Return to Mission Center and choose **Run mission validation**.
6. Fix failed criteria and retest. Each mission awards **100 XP on its first complete passing validation**.
7. After completing the set, go to **Instructor & Reports**, export your student results JSON, and submit it through the instructor's LMS.

**Tip:** You may select **Load practice environment** once in an empty Region to receive a starter Nimbus deployment with deliberately insecure or incomplete settings. Alternatively, build from an empty Region. The starter data can require remediation to pass several missions. Do not use Reset Region unless you understand it removes that Region's simulated resources and saved mission results.

**How the evaluation works:** All mission checks inspect the same resource records shown in the Classic Console. They are simplified conceptual criteria, not authoritative assessments of AWS correctness or professional certification readiness.

---
## Mission 01: Cloud Concepts

**Scenario:** Provision your first cloud workload.

**Objective:** Launch a basic virtual network and EC2 compute instance on demand.

**Open in console:** [Mission 01](index.html#mission-1)

### Hands-on procedure

1. Create a VPC named `nimbus-vpc` with IPv4 CIDR `10.20.0.0/16`.
2. Create subnet `public-web-a` using `10.20.1.0/24` in the VPC; choose `us-east-1a` or your selected Region’s first Availability Zone.
3. Create security group `web-sg` in the VPC. Add inbound TCP `80` or `443`; allow outbound traffic.
4. Launch EC2 instance `nimbus-web-a` using a `t3.micro` instance type, your subnet, and the security group. Set state to **Running**.
5. Open Mission Center and run **Mission 1 validation**.

### Validation criteria

- [ ] A VPC exists
- [ ] A subnet exists
- [ ] At least one EC2 instance is running

**Reflection:** When does cloud on-demand provisioning improve the business case compared with a traditional procurement process?

---

## Mission 02: Cloud Economics & Billing

**Scenario:** Bring a runaway budget under control.

**Objective:** Apply cost awareness without relying on any actual AWS pricing.

**Open in console:** [Mission 02](index.html#mission-2)

### Hands-on procedure

1. Open **EC2 Instances**. Launch a `t3.micro` or `t3.small`, or edit an existing running instance to one of those sizes.
2. Open **AWS Budgets** and create `launch-operations-budget`; specify a positive simulated monthly amount, for example `150`.
3. Set **Alert threshold (%)** to `80` or lower. Save.
4. Return to Mission Center and validate Mission 2.

### Validation criteria

- [ ] A modest t3 instance is running
- [ ] A budget exists
- [ ] Budget alert threshold is 80% or less

**Reflection:** What is the difference between a budget alert and automatically enforcing a spending cap?

---

## Mission 03: Global Infrastructure

**Scenario:** Keep the site online through a zone outage.

**Objective:** Model redundancy across Availability Zones.

**Open in console:** [Mission 03](index.html#mission-3)

### Hands-on procedure

1. In **Subnets**, create `public-web-b` with nonoverlapping CIDR `10.20.2.0/24` in Availability Zone **b**. Ensure two subnet Availability Zones exist.
2. Create a second EC2 instance `nimbus-web-b` in subnet `public-web-b`. Both EC2 instances must be **Running** and in different Availability Zones.
3. Open **Load Balancers** and create `nimbus-app-alb` in the correct VPC. Select both web subnets and both running EC2 targets. Enable health checks.
4. Return to Mission Center and validate Mission 3. As an extension, configure Multi-AZ RDS and run **Availability Zone outage** from the Architecture Map.

### Validation criteria

- [ ] Two distinct Availability Zones
- [ ] A load balancer spanning both zones
- [ ] Healthy EC2 targets spread across the zones

**Reflection:** Why does multi-zone deployment reduce the risk of a single facility outage?

---

## Mission 04: Cloud Security

**Scenario:** Contain a data exposure and repair privileged access.

**Objective:** Improve S3, IAM and audit configurations.

**Open in console:** [Mission 04](index.html#mission-4)

### Hands-on procedure

1. Open **S3 Buckets** and create or edit an S3 bucket. Turn **Block all public access** and **Enable default encryption** ON.
2. If any other S3 buckets already exist, apply Block Public Access to all of them.
3. Open **IAM Users**. Create an administrator user with MFA enabled, or update an existing privileged user to enable MFA.
4. Open **CloudTrail Trails** and create a trail with **Recording API activity** enabled.
5. Run Mission 4 validation. For the stronger diagnostic, open Architecture Map → **Security audit**; correct any additional findings.

### Validation criteria

- [ ] Private encrypted S3 bucket
- [ ] No public S3 buckets
- [ ] Privileged IAM users have MFA
- [ ] CloudTrail recording enabled

**Reflection:** Why is least-privilege authorization different from simply enabling MFA?

---

## Mission 05: Networking & Content Delivery

**Scenario:** Repair the application’s traffic path.

**Objective:** Model public subnet and application listener prerequisites.

**Open in console:** [Mission 05](index.html#mission-5)

### Hands-on procedure

1. In **Subnets**, ensure one subnet in your VPC is marked **Public subnet**.
2. In **Security Groups**, set allowed inbound TCP ports to include `80` or `443`. Do not expose SSH `22` to `0.0.0.0/0`.
3. In **EC2 Instances**, verify an instance is **Running** in the public subnet, with the security group attached and **Assign a simulated public IP** enabled.
4. Run Mission 5 validation and review the Architecture Map.

### Validation criteria

- [ ] Public subnet exists
- [ ] TCP 80 or 443 is permitted
- [ ] Running compute has compatible subnet, security group and simulated public IP

**Reflection:** In real AWS, what additional networking components are needed for a truly reachable internet-facing EC2 endpoint?

---

## Mission 06: Compute

**Scenario:** Build an application fleet that can survive host loss.

**Objective:** Deploy a two-instance fleet and register ALB targets.

**Open in console:** [Mission 06](index.html#mission-6)

### Hands-on procedure

1. In **EC2 Instances**, confirm at least two instances are **Running**.
2. Use separate subnets in different Availability Zones for the two instances.
3. In **Load Balancers**, create or edit an ALB, select the relevant subnets, attach both instances as targets, and enable health checks.
4. Run Mission 6 validation. For extra practice, stop one instance and inspect the incident diagnostics, then restart it.

### Validation criteria

- [ ] Two running EC2 instances
- [ ] EC2 spread across two zones
- [ ] At least one healthy application load balancer

**Reflection:** How does a load balancer differ from Auto Scaling?

---

## Mission 07: Storage

**Scenario:** Prevent the loss and unintended exposure of game assets.

**Objective:** Secure and version a simulated object repository.

**Open in console:** [Mission 07](index.html#mission-7)

### Hands-on procedure

1. Open **S3 Buckets** and create `nimbus-assets-<unique suffix>`, all lowercase.
2. Enable Block Public Access, default encryption, and versioning. Review **every existing bucket** for the first two settings.
3. Open the new bucket using its name and select **Upload object**; enter key `images/launch-banner.png` and a simulated size such as `120 KB`. No real file is transmitted.
4. Run Mission 7 validation.

### Validation criteria

- [ ] At least one bucket exists
- [ ] All buckets block public access and use encryption
- [ ] A bucket has versioning enabled
- [ ] At least one object metadata record exists

**Reflection:** What does versioning protect against, and what additional controls are needed for long-term backup assurance?

---

## Mission 08: Databases

**Scenario:** Remove the single-zone failure point.

**Objective:** Configure private, encrypted, recoverable relational data.

**Open in console:** [Mission 08](index.html#mission-8)

### Hands-on procedure

1. Create **two private subnets** in distinct Availability Zones in the same VPC, such as `10.20.10.0/24` and `10.20.11.0/24`.
2. In **RDS Databases**, create or edit a PostgreSQL or MySQL DB with the private primary subnet.
3. Set **Public accessibility** OFF and **Storage encryption** ON.
4. Set **Multi-AZ deployment** ON and backup retention to `7` days or more. The model checks for subnets in distinct zones.
5. Run Mission 8 validation, then inject **Database failure** from Architecture Map.

### Validation criteria

- [ ] At least one database
- [ ] All DBs private and encrypted
- [ ] At least one Multi-AZ DB
- [ ] At least seven backup retention days

**Reflection:** What is the difference between Multi-AZ failover and point-in-time restore?

---

## Mission 09: Well-Architected Design

**Scenario:** Decouple checkout from a failing email service.

**Objective:** Use asynchronous messaging to reduce dependency failures.

**Open in console:** [Mission 09](index.html#mission-9)

### Hands-on procedure

1. In **SQS Queues**, create `nimbus-email-jobs` and enable **Configure a dead-letter queue**.
2. In **Lambda Functions**, create `nimbus-email-worker` and select the SQS queue as its trigger.
3. In **Load Balancers**, enable simulated health checks on an ALB.
4. Validate Mission 9, then inject the **Email integration outage** incident on the Architecture Map.

### Validation criteria

- [ ] SQS queue exists
- [ ] Dead-letter handling enabled
- [ ] Lambda has SQS trigger
- [ ] ALB health checks enabled

**Reflection:** Why does a queue improve resilience when an external API is slow or unavailable?

---

## Mission 10: Auto Scaling & Monitoring

**Scenario:** Prepare for launch-day traffic.

**Objective:** Combine fleet scaling, application alarms, and financial alerts.

**Open in console:** [Mission 10](index.html#mission-10)

### Hands-on procedure

1. In **Auto Scaling Groups**, create or edit an ASG attached to an existing ALB; configure Minimum `1`, Desired `2`, and Maximum `8` or more.
2. Enable **target-tracking scaling**.
3. In **CloudWatch Alarms**, create and enable an alarm for `EC2 CPUUtilization`.
4. Create and enable a second alarm for `Application 5XXError`.
5. In **AWS Budgets**, ensure a positive budget with a configured alert threshold exists.
6. Run Mission 10 validation, then inject **8× traffic surge** from the Architecture Map.

### Validation criteria

- [ ] ASG max >= 8 with target tracking
- [ ] CPU alarm enabled
- [ ] Application error alarm enabled
- [ ] Budget alert exists

**Reflection:** How can an application be highly available while still being operationally expensive?

---
## Instructor delivery and assessment

Suggested class pattern: one mission following each module PowerPoint (25–40 minutes), or a two- to three-session capstone combining missions 1–10. Ask students to explain their design decisions and screenshot one misconfiguration and its repair. The available validators are formative checks; an instructor should evaluate reasoning and lab reflections separately.

**Assessment example (100 points):** 40 points for the ten validated missions (4 each), 30 points for architecture explanations, 20 points for an incident analysis, and 10 points for the reflection questions. Modify based on local grading policy. Student JSON reports are locally generated and are not tamper-proof; use them for practice or formative credit unless corroborated.

**Student privacy:** The static version does not connect to a central account service or automatically transmit data to the instructor. Callsigns, section codes, simulated resource names, and mission results reside in local browser storage. Export files are shared only when the student chooses to submit them. Avoid entering actual credentials, secrets, personal records or real infrastructure identifiers.

**Real AWS differences:** The emulator has simplified subnet and route behavior, IAM policy types, EC2 states, load balancer health, RDS availability and cost estimates. It does not create actual routing tables, run virtual machines, execute Lambda code, provision hardware, or simulate every AWS API. Use an AWS-managed lab environment for real operational competence after the conceptual exercise.

**Static site assets:** [`index.html`](index.html), [`lab-instructions.html`](lab-instructions.html), and [`LAB_INSTRUCTIONS.md`](LAB_INSTRUCTIONS.md) ship together for EdgeOne direct upload. Keep the file names and case intact.