AWS Cloud Rescue · Guided Lab Instructions

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

Open mission 1 in the simulator ↗

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.

Success 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?

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

Open mission 2 in the simulator ↗

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.

Success 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?

Objective: Model redundancy across Availability Zones.

Open mission 3 in the simulator ↗

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.

Success 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?

Objective: Improve S3, IAM and audit configurations.

Open mission 4 in the simulator ↗

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.

Success 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?

Objective: Model public subnet and application listener prerequisites.

Open mission 5 in the simulator ↗

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.

Success 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?

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

Open mission 6 in the simulator ↗

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.

Success 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?

Objective: Secure and version a simulated object repository.

Open mission 7 in the simulator ↗

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.

Success 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?

Objective: Configure private, encrypted, recoverable relational data.

Open mission 8 in the simulator ↗

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.

Success 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?

Objective: Use asynchronous messaging to reduce dependency failures.

Open mission 9 in the simulator ↗

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.

Success 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?

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

Open mission 10 in the simulator ↗

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.

Success 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 notes and privacy

Students may work individually or in teams. The hosted static website does not automatically collect scores. Exported student results are unverified local JSON reports and should be treated as formative evidence unless corroborated. Avoid entering genuine credentials, secrets, or personal data.

For more detailed grading, limitations, and procedure notes, see the Markdown lab manual.