Before starting AWS Cloud Practitioner Essentials, I had a very simple idea of cloud computing:
A place to host a backend, store a database, and run computing workloads.
That was not completely wrong, but after finishing Module 1: Introduction to the Cloud, I realized how incomplete that mental model was.
The module did not just introduce AWS services. It changed how I think about deployment, scalability, availability, security, and architectural trade-offs.
Here are the three concepts that stood out the most.
1. AWS Global Infrastructure is more than “servers around the world”
One of the most useful concepts for me was understanding the difference between AWS Regions and Availability Zones.
Previously, when I used large-scale web applications, I rarely thought about what happened underneath when a physical server failed.
Learning about AWS Global Infrastructure helped me understand how systems can be designed so that a single infrastructure failure does not necessarily interrupt the whole application.
Instead of relying on one machine or one physical location, an architecture can distribute workloads across multiple Availability Zones.
That led me to a much more important concept:
fault tolerance.
For the first time, I started thinking about questions like:
- What happens if one server fails?
- What happens if an entire Availability Zone becomes unavailable?
- Can the application continue serving users?
- Where should data and services be deployed?
This made me realize that reliability is not something we “add later.”
It starts with architecture.
2. Cloud security is still a shared responsibility
The AWS Shared Responsibility Model was probably the concept that challenged one of my assumptions the most.
Before this module, I had a vague idea that once an application was moved to the cloud, the cloud provider would handle most of the security.
That is not how it works.
AWS is responsible for security of the cloud, including the underlying infrastructure, hardware, and physical facilities.
Customers are still responsible for security in the cloud, and the exact responsibility depends on the services and deployment model being used.
That distinction seems simple, but it changes the way I think about architecture.
Choosing a cloud service is not only about functionality.
It also changes:
- and what risks I still own
For someone learning solution architecture, this is an important mindset shift.
3. Scalability is not only a backend problem
As a software engineering student, I used to associate scalability mainly with backend code.
Can the API handle more users?
Can the database process more requests?
Can we optimize the code?
After this module, I started seeing scalability from a wider perspective.
The way an application is deployed, the infrastructure it runs on, and the cloud services behind it all affect:
scalability, elasticity, availability, and cost.
A system may have well-written backend code but still struggle if its infrastructure cannot scale with demand.
At the same time, designing for maximum scale everywhere can become unnecessarily expensive.
This is where cloud architecture becomes interesting.
There is rarely one “best” answer.
Instead, there are trade-offs.
From “Does it work?” to “Why is it designed this way?”
This first module was introductory, but it already changed the questions I ask when looking at a system.
Before:
Does the application work?
Now I am starting to ask:
Where is it deployed?
How does it scale?
What happens when infrastructure fails?
Who is responsible for securing each layer?
What does higher availability cost?
What trade-offs were made?
That is probably the biggest takeaway for me.
Cloud architecture is not simply about choosing AWS services.
It is about making decisions based on requirements, reliability, security, scalability, elasticity, and cost.
As I continue learning toward Solution Architecture and Technical Consulting, this is the mindset I want to develop further:
not only understanding how a system works, but understanding why it was designed that way.
If you are also learning AWS, what was the first cloud concept that changed the way you think about system architecture?
Loading article