Hands-on AWS labs are most useful when they require a prediction, an observable result and safe cleanup. Private-subnet internet access, Terraform provisioning, containers on EC2 and a small Amplify-connected client can illustrate networking, reproducible infrastructure and application integration, but each exercise depends on current supported services and SDK versions. Before running a lab, set a budget, create narrow permissions and use synthetic data. During the exercise, record what changed and what failed; afterward, destroy disposable resources and confirm that costs and access exposure are controlled.
Use a dedicated nonproduction AWS account and synthetic data. Define a budget alert and a deletion plan, but do not assume a budget notification prevents further spending. Decide which resources may need public internet access and which should remain private. Record what success means for each lab and what deliberate failure will be used to test the design. The most effective sequence builds from networking into a small service, then into deployment and troubleshooting. The labs below are project briefs rather than a list of commands that may become obsolete in the next console update.
Lab One: Design Private-Subnet Egress
Create a VPC with nonoverlapping address ranges and private subnets distributed across at least two Availability Zones. Identify which workload requires outbound internet access and why. Build route tables that retain local traffic while sending the intended destination traffic through an appropriate egress path. Test from a private instance without a public address. The objective is to demonstrate that it can initiate a permitted outbound connection while unsolicited public internet traffic cannot reach it directly. Document the association between the source subnet and its actual route table instead of assuming a subnet name guarantees privacy.
AWS now offers regional NAT gateway mode, introduced in November 2025, alongside the traditional zonal gateway architecture. A zonal public gateway normally resides in a public subnet and commonly uses an Elastic IP, whereas a regional gateway does not require a public host subnet and can expand across zones according to workload presence. NAT gateway deployment should therefore explain which mode a lab is testing. Measure cost and route behavior, and do not assume a private NAT gateway provides public internet access. Delete chargeable egress resources after the experiment.
A troubleshooting extension removes one private route and observes the resulting failure. Restore the route, then test DNS resolution and the actual application endpoint. Distinguish a blocked packet from an unauthorized API call. An instance may use the correct route and still fail if its firewall policy prevents the traffic. Document the expected and observed path, including security-group and network-ACL behavior. This test teaches safe diagnosis instead of encouraging broad inbound rules to solve every reachability problem.
Lab Two: Provision Infrastructure With Terraform
Express a small VPC, security group, EC2 instance and test artifact with version-controlled Terraform configuration. Use a remote state approach and access controls appropriate to the training environment. Run a plan and inspect proposed resource additions before applying it. A second application of unchanged configuration should not generate new duplicate instances. Introduce a harmless manual change in a disposable resource and compare the result against the declared state. Discuss how to reconcile that difference safely rather than blindly reapplying an unexpected destructive change.
Terraform with AWS is most useful when the trainee understands state, dependencies, credentials and the effect of replacement. An instance can be recreated while preserving its application source, but a stateful database requires explicit data protection. Build separate configurations for ephemeral and persistent resources and verify deletion behavior. Store no secret keys in the repository, and avoid a workspace design that would accidentally apply production changes using lab credentials. The learning target is reproducible and reviewable provisioning, not merely typing terraform apply.
Lab Three: Run a Container on EC2
Provision an EC2 instance with a supported operating-system image and install a maintained container runtime through an approved setup method. Build a small HTTP service into a tagged image and run it with restricted privileges. Test the listening port through the intended network route rather than exposing all management ports to the internet. Rebuild the image after changing the application version, then verify that the running container actually uses the expected version. Capture startup logs, error output and basic resource consumption.
Create a deliberate failure by setting the wrong container port or removing a required environment setting. Diagnose the difference between an instance that is reachable, a container process that is stopped and an HTTP service that returns an error. A container is an application packaging mechanism, not an automatic high-availability solution. Explain what would be needed to move the application to a managed orchestrator such as ECS, including health checks, service deployment configuration and appropriately scoped task roles.
Lab Four: Build an Authenticated API and Queue Worker
Implement a small backend that accepts a test request, writes a durable record and places a processing message on a queue. Configure the API’s authentication and separately restrict the worker’s AWS service permissions. The API should acknowledge acceptance without pretending background processing has already completed. A Lambda and API Gateway design can make this clear, but the exact implementation must still address input validation and resource-level authorization. Use test data with no real personal details.
Force the worker to fail after making a state change but before acknowledging its message. When the message is delivered again, the application should identify the already committed operation and avoid duplicating it. Record the visibility timeout, retry pattern and failure destination. Add CloudWatch logging and a correlation identifier that can link the API request to the worker’s eventual result. This demonstrates that event-driven infrastructure needs an application-defined idempotency rule even when every managed component is functioning as documented.
Lab Five: Modernize a Flutter and Amplify Exercise
A Flutter CRUD project using AWS Amplify DataStore requires close attention to supported library versions. Older installation commands should be checked before reuse: AWS documents that Amplify Flutter version 1 was deprecated April 30, 2025, and directs new users to maintained versions. Do not copy an old DataStore or CLI installation sequence as a current default without checking the chosen Amplify generation, Flutter library and supported data-backend API. The durable lab objective is implementing authenticated create, read, update and delete operations with correct authorization and network failure behavior.
Build a simple task list with a unique record identifier and a clear owner. Ensure a user cannot modify a different user’s record merely by changing the identifier supplied by the client. For offline behavior, decide how local changes are reconciled with remote state when two devices modify the same item. Test loss and restoration of connectivity, failed authentication and a conflicting update. An offline synchronization library may supply useful mechanisms but cannot define the application’s conflict policy by itself. Follow current maintained AWS Amplify documentation for the selected version rather than treating a historical tutorial as a production recipe.
Lab Six: Measure Monitoring and Recovery
Take one of the previous labs and define an application-level success metric, such as completed orders or successful HTTP transactions. Configure a safe alert for elevated error rate or backlog growth and test notification delivery. Introduce one controlled failure and record how long it takes to detect, diagnose and recover. A healthy EC2 CPU graph does not prove that the business action succeeds; include dependency and user-visible signals. The runbook should contain the first diagnostic query, expected failure behavior and the actual recovery evidence.
Perform a second exercise that tests permission denial. Revoke a required low-risk test permission and observe the exact AWS error; then restore it without granting broader access than necessary. For a database backup demonstration, restore a test record rather than assuming a successful snapshot creation is enough. Every lab should include a negative test that confirms an unsafe or unauthorized action is blocked. These experiments produce meaningful proof of skills in security, observability and resilience rather than only a list of provisioned cloud resources.
Use Labs to Guide Certification Preparation
Cloud Practitioner candidates can use these projects to understand core service categories and cost responsibility, while SAA-C03 candidates should justify architecture trade-offs. Developer Associate candidates can focus on event contracts, SDK permissions and deployment tests; CloudOps Engineer SOA-C03 candidates can emphasize monitoring, automation and recovery. AWS Skill Builder also offers maintained guided and challenge-based labs, with availability depending on program and subscription. Match exercises to the issuer’s current exam objectives, not to the certification title printed in an old course screenshot.
An effective learning portfolio records the requirement, diagram, code revision, actual AWS resource identifiers with sensitive details redacted, test steps, observed errors, successful repair and cleanup. The work should be reproducible without giving the reader permanent account credentials. Limit expensive services and watch usage while testing. If an exercise fails, keep its diagnostic evidence rather than hiding the result: explaining a failed route, incorrect IAM policy or duplicate queue event often demonstrates deeper understanding than a perfect initial build.
The most durable AWS lab teaches why a workload behaves as designed under normal and abnormal conditions. Private egress, infrastructure code, containers, event processing, mobile data synchronization and recovery all have legitimate roles, but their implementation details evolve. Update tools and service features from issuer sources, protect the training account from unnecessary spending, and validate every exercise with a meaningful positive and negative test. That turns a collection of tutorials into a practical engineering curriculum.