When the cloud architecture assignment makes your AWS badge feel like a toy


I recently completed the AWS Academy Cloud Foundations Badge
.
It was a strict requirement for my degree. For a few weeks, my life consisted of nothing but memorizing technical acronyms. I learned the strict differences between an Elastic Compute Cloud (EC2) instance, a Simple Storage Service (S3) bucket, and a Virtual Private Cloud (VPC). I studied security groups and Identity and Access Management (IAM) roles. I passed the exam, acquired the digital badge, and felt highly confident about my cloud computing knowledge.
But knowing what a tool does is very different from knowing how to build a scalable house with it.
The Reality Check
The real test arrived during our final project for the 6CLOUDCOM class under Dr. Jonilo Mababa. The assignment was not a simple multiple-choice exam. We were tasked to design a comprehensive, fault-tolerant AWS cloud architecture for a massive, real-world business enterprise.
My team chose Lazada Singapore Pte. Ltd.
Lazada is not a lightweight application. It is a dominant third-party ecommerce marketplace that routinely handles 160 million active monthly users across Southeast Asia. You cannot simply spin up a single server, attach a database, and hope the system survives a major sale event like 11.11 or a monthly payday rush.
Suddenly, the basic textbook definitions I memorized for my certification were no longer enough to solve the problem.
Architecting for Massive Scale
We had to transition from theoretical knowledge to practical systems design. It took hours of diagramming infrastructure logic and debating routing tables to finalize our five architecture blueprints. We had to implement several advanced cloud patterns to ensure the system would not collapse under pressure.
- Traffic Distribution: We mapped out Elastic Load Balancers (ELB) across multiple subnets. This ensures that when millions of users simultaneously search for products, the incoming network traffic is evenly distributed so no single server becomes a bottleneck.
- Elastic Capacity: We architected Auto Scaling Groups for our compute resources. During a massive midnight sale, the system must automatically provision new servers to handle the spike. Once the sale ends, it must instantly terminate those extra servers to minimize billing costs.
- Fault Tolerance: We deployed our resources across multiple Availability Zones (AZ). If a physical data center in Singapore experiences a power failure, the Lazada application must seamlessly route users to a secondary data center without dropping their active shopping carts.
Expecting Failure
Everything fails, all the time. (Werner Vogels, CTO of Amazon)
Dr. Jonilo Mababa repeatedly emphasized this harsh reality during our course. A cloud service is just a single mechanical gear. The architecture itself is the entire engine. You cannot build an engine assuming all the parts will function perfectly forever. You must design the entire system expecting those gears to break at the worst possible moment.
That single project completely changed how I look at backend development and system operations. It is incredibly easy for a developer to say that they will just put their application in the cloud. It is an entirely different engineering challenge to wire those cloud services together securely, efficiently, and at a massive scale.
The initial AWS badge successfully got my foot in the door and gave me the correct technical vocabulary. However, architecting a complex system that could theoretically support Alibaba-level web traffic is what actually made me feel like a true software engineer.

