I used to think AWS was about collecting certifications and drawing clean architectures.
Then I built real projects.
And everything changed.
Certifications helped me understand the landscape — the names, the possibilities, the patterns. They gave me breadth.
Projects gave me something completely different — the ability to touch AWS, mess up configurations, stare at logs, question my life choices, fix them, redeploy, and finally see it work. That gave me depth.
Most importantly, projects gave me confidence through failure, not success.
The AWS services I actually worked with
- Compute & Execution: EC2, AWS Lambda
- Containers: ECS (Fargate), ECR
- Networking: VPC, ALB, Route 53, Security Groups
- CDN & Storage: CloudFront, S3
- CI/CD: CodePipeline, CodeBuild, CodeDeploy
- Observability: CloudWatch (Logs, Metrics, Alarms), AWS X-Ray
- AI Layer: AWS Bedrock (Llama 3), Amazon SNS for alerts
These weren’t services I memorized for an exam — these were services I argued with until they started working.
Common failures that humbled me (and what they taught me)
CloudFront + S3 showing 403
I assumed S3 should be public so CloudFront can read it. Wrong.
The fix was learning how CloudFront OAC signs requests, and S3 should trust CloudFront, not the world.
ALB Target Group Unhealthy
I thought my app was broken. It wasn’t.
The security group only allowed my IP, not ALB.
Lesson learned: AWS debugging is 50% IAM + 50% networking + 0% magic.
ECS task stopped immediately
I blamed Fargate. Turns out I misconfigured the container port and IAM execution role.
Fixing it taught me the difference between task role vs execution role — something the exam never forced me to truly internalize.
Lambda timeout in VPC
I enabled VPC thinking it improves security. It did — by killing internet access.
Then I learned why NAT Gateway matters for outbound, and why CloudWatch logs don’t magically appear without proper routes.
CodePipeline deploy failures
This is where IAM introduced itself personally.
Missing s3:GetObject, missing deploy permissions, missing log creation access — each retry taught me how to write minimal, correct IAM policies instead of admin-access panic mode.
Minute errors that cost maximum time
- One missing slash in health check path
- One port mismatch between ALB and container
- One wrong IAM action
- One region mismatch in a CLI command
These tiny things didn’t just teach AWS — they taught me patience, precision, and why real engineers obsess over logs instead of hype.
How I handled working with multiple services together
I didn’t learn AWS by reading 100 blogs. I learned by:
- Building something small
- Watching it fail in a confusing new way
- Reading AWS docs like a detective
- Digging through CloudWatch logs
- Tracing requests in X-Ray
- Fixing, redeploying, verifying
- Breaking again on purpose to understand it better
- Writing about it publicly so someone else can suffer less than me
- That loop is my real AWS course.
What I wish someone told me when I started:
- Certifications make you aware, projects make you capable
- AWS feels easy until you open IAM or VPC
- Debugging is a skill, not a side quest
- The cloud rewards builders, not memorizers
- Precision > ambition, logs > assumptions
You learn faster when you deploy and fail publicly than when you pass privately
Final takeaway
AWS didn’t become clear to me when I passed exams.
It became clear when I failed deployments, fixed them, and realized:
“I can build anything on AWS… as long as I expect it to break first.”
And honestly? That’s a comforting thought.
Because now, when something fails, I don’t panic.
I open CloudWatch. I open X-Ray. I open IAM.
And I start solving.
Not because I know everything,
but because I know how to figure it out.
If my errors can save someone even 30 minutes of debugging, this post has already succeeded.
Certifications gave me the map.
Projects taught me the terrain.
Failures trained me for the real world.
And I’m still learning — in public — one broken deployment at a time.
Top comments (0)