AWS Cloud Practical Labs
Identity, compute, storage, custom networking and the governance layer — all configured by hand in a live AWS account, including the parts that broke.
- Type
- Self-directed hands-on labs
- Account
- AWS Free Tier, live
- Domains
- Identity · Compute · Network · Storage
- Status
- Ongoing
Why labs instead of a course
I already had a networking and security background, so watching someone else click through a console was never going to teach me much. Instead I worked through AWS in a live Free Tier account, building each piece myself: an instance I had to actually reach over SSH, a VPC I had to actually route traffic out of, an alarm that had to actually notify me.
The result is that the AWS services below aren't line items on a skills list — they're things I have configured, misconfigured, and repaired.
What I built
Identity & access
- Created IAM users and organised them into groups
- Wrote and attached permission policies
- Worked through least-privilege permission design
Compute
- Launched EC2 instances and connected over SSH with key pairs
- Configured security groups as instance-level firewalls
- Allocated and attached Elastic IPs for stable addressing
Storage
- Created buckets and configured access policies
- Enabled and tested versioning
- Worked through public vs. private object access
Networking
- Built a custom VPC from scratch rather than using the default
- Carved out subnets and attached an internet gateway
- Configured route tables to control egress
Observability
- Configured CloudWatch metrics and alarms
- Enabled CloudTrail for API-level audit logging
- Wired SNS notifications and EventBridge rules
Account & governance
- Studied AWS Organizations and multi-account structure
- Worked with billing, budgets and cost visibility
- Reviewed the support plan tiers
Where the networking background paid off
Building a custom VPC is subnetting, routing and firewalling with AWS names on top. Route tables are routing tables. Security groups are stateful ACLs. An internet gateway is a default route out. Coming from CCNA, the concepts transferred almost directly — what I had to learn was AWS's vocabulary and where its boundaries sit, not the fundamentals underneath.
The same is true of IAM. Users, groups, policies and least-privilege are the access-control model I'd already met from the security side; IAM is a rigorous implementation of it.
What broke
SSH connection refused after launching an instance
The classic first AWS wall. Tracing it back through the security group inbound rules, the key pair permissions and the instance's network placement is what turned 'security group' from a term into a mental model.
Custom VPC with no route out
An instance in a subnet I built myself could not reach the internet. The gateway existed; the route table entry pointing at it did not. Building a VPC by hand is the fastest way to learn that AWS networking is just routing, and I already knew routing.
IAM permission denials
Working out why an action was denied — which policy, attached at which level, was or wasn't granting it — and fixing it by narrowing permissions rather than widening them.
Getting the audit and alerting path to actually fire
Configuring CloudTrail and CloudWatch so events were genuinely captured and an SNS notification arrived at the other end, rather than assuming it worked because the console showed green.
Where this connects
This work directly feeds the scale-out plan for MartialXPro. The platform currently runs on a single Ubuntu host; the AWS path — EC2 inside a properly routed VPC, IAM-scoped access, S3 for generated documents, CloudWatch for visibility — is provisioned and planned on the back of these labs rather than guessed at.