Completing My First AWS Cloud Engineering Lab Series

I have now completed all five AWS onboarding credit activities in my personal cloud lab: AWS Budgets, EC2, Bedrock, the Lambda web application activity and RDS/Aurora. The final console checkpoint showed $199.97 USD in credits remaining after the small amount of usage generated by the labs.

The credit balance is useful, but it is not the main result. I wanted each activity to leave behind an engineering lesson I could explain and reproduce. That meant validating the services rather than stopping when a resource reached an “Available” state, and cleaning up disposable infrastructure rather than assuming credits made cost discipline irrelevant.

Starting with the account and the bill

Before building workloads, I separated normal administration from the root account, registered hardware-backed root MFA, verified that root had no access keys and created a budget with actual and forecasted alerts. The budget is intentionally retained. It is an early-warning control, not a spending cap.

EC2: validating the controls instead of checking boxes

The EC2 lab used an Amazon Linux 2023 t3.micro instance in us-east-2 with an encrypted gp3 root volume. SSH was the only inbound service and was restricted to a single trusted source address. I connected from Windows with public-key authentication, inspected the operating system, interfaces, routes, DNS and storage, and verified package management.

IMDSv2 was required. I tested that requirement from inside the instance: metadata access without a token returned HTTP 401, while a valid IMDSv2 token allowed the expected metadata request. That denial-and-success pair was better evidence than simply showing the console setting. When the lab was finished, I terminated the instance and verified that the root EBS volume had been removed.

Bedrock: the model still needs an engineer

I used Amazon Nova Micro in the Bedrock playground to review the EC2 configuration. The first answer identified useful strengths, but it also repeated an SSH control that was already implemented, treated account MFA as though it were part of the SSH path and missed the IMDSv2 control entirely.

A revised prompt produced a more relevant answer, including CloudTrail and AWS Config, but the response still required human review. The NACL advice needed context, and adding another AWS service is not automatically the right answer for a temporary lab. The useful lesson was not that an LLM could design the environment for me; it was that prompt refinement and technical validation matter before acting on its advice.

Lambda became something worth keeping

Instead of throwing away the Lambda activity, I turned it into the Family IT Help Desk. The application now combines Cognito authentication, API Gateway, Lambda, DynamoDB, SNS and CloudWatch. v0.1 proved authenticated ticket intake, persistent storage and email notification. v0.2 is extending that into an admin ticket-management workflow.

This is the one starter workload I intentionally kept. It turned a promotional activity into an application with a real user and a reason to keep improving the architecture.

The bugs were part of the engineering

The Help Desk did not arrive as a clean sequence of successful console clicks. The application work included replacing early browser-side behavior with the real Lambda-backed ticket path, keeping validation and priority decisions on the server, and generating ticket identifiers in the backend rather than trusting the browser.

A second bug made the result card continue to display Submitted even though the restored ticket was In Progress. The rendering code was looking for a resultStatus element that the HTML did not actually identify. Adding the correct DOM id—and then correcting a malformed edit that briefly duplicated the default text—brought the visible status back in sync with the backend.

There were also ordinary structural mistakes while editing a large single-file frontend, including a misplaced closing brace that produced a syntax error. The useful part was not avoiding every mistake; it was narrowing each failure, checking the surrounding structure instead of guessing, deploying the correction and retesting the complete path.

The security path was tested separately as well. A security-category submission containing an escalation phrase produced Critical priority and the intended warning behavior. That mattered because the priority logic was supposed to be backend behavior, not decorative UI state.

Those bugs are now some of the strongest evidence in the project. They forced me to distinguish database state, API responses, restored client state and presentation state instead of treating “the page looks right” as proof that the system is right.

Aurora PostgreSQL closed the loop

The last activity used Aurora PostgreSQL Serverless in us-east-2. I configured IAM database authentication and connected through AWS CloudShell. The PostgreSQL server reported version 17.9, and the session negotiated TLS 1.3.

I did not count “connected” as the finish line. I queried the active database, user and server version, created a small relational table with a generated identity key and timestamp, inserted a synthetic record and selected it back successfully. That gave the lab a complete database path: provision, authenticate, connect, create schema, write, read and disconnect.

Aurora also made the cost lesson concrete. The console displayed metered capacity and storage pricing. Credits may cover that usage while they are available, but that does not make the service free. The lab was deliberately short-lived.

Cleanup is part of the build

I deleted the Aurora writer and then the cluster. I disabled creation of a final snapshot and disabled retention of automated backups because the data was disposable. After deletion, I checked the RDS console again: zero databases, zero manual snapshots and zero current-region automated backups.

That final check matters to me. “I deleted it” is not the same thing as proving that the dependent billable resources are gone.

What the first AWS series actually taught me

The five activities touched very different services, but the workflow became consistent: establish the cost boundary, provision the smallest useful resource, apply an appropriate security control, test the control or workload from the inside, record evidence, and deliberately decide whether the resource should be retained or removed.

I now have all five starter activities completed and nearly the full $200 credit pool available for the next stage of AWS learning. More importantly, I have a cloud engineering portfolio that records what worked, what was temporary, what remains running and what I would change for a production environment.

The next AWS work can move beyond onboarding activities into deeper identity, networking, logging, infrastructure automation and security engineering. The credits give me room to experiment; the rule stays the same: they are a budget to manage, not an excuse to leave infrastructure running.

Explore the Cloud Engineering Portfolio ↗

Read the Aurora PostgreSQL case study ↗