Learn AWS by Following One Request
Stop memorizing services. Follow what happens when a user opens your application.
# Learn AWS by Following One Request
AWS feels overwhelming because beginners meet it as a catalog.
More than 200 services.
Dozens of acronyms.
Multiple ways to run compute.
Multiple ways to store data.
Multiple ways to secure, monitor, automate, and deploy.
That is why many beginners ask the wrong question:
“Which AWS services should I learn?”
A better question is:
“What happens when one user opens my application?”
Follow that request, and AWS starts to make sense.
1. The user needs to find you
Before your app runs, before your database is queried, before your backend processes anything, the browser needs to know where to go.
Humans type names.
Computers route to addresses.
That is why DNS matters.
In AWS, Route 53 handles that job. It turns a domain name into the right destination for your application.
For a beginner, the lesson is simple:
If you do not understand DNS, IP addresses, ports, and routing, AWS service names will feel random.
Cloud starts with networking.
2. Static content should not need your backend
When a user opens a site, not everything needs application logic.
Images, CSS, JavaScript, videos, downloads, and basic site files are static content.
Those files need to live somewhere reliable.
That is where S3 fits.
S3 is object storage. Think files, not rows.
Then CloudFront sits in front of those files and delivers them from locations closer to the user.
The job is not “learn S3” or “learn CloudFront.”
The job is:
Where do static files live?
How do users get them quickly?
How do we keep the origin protected?
3. Dynamic requests need a compute decision
At some point the user clicks something.
Add to cart.
Submit form.
Login.
Search.
Upload image.
Now the application has to do work.
AWS gives you several compute paths.
Lambda is useful when work is event-driven, short-lived, and you do not want to manage servers.
EC2 is useful when you need control over the operating system, runtime, installed software, network configuration, or legacy requirements.
ECS is useful when you want containers: a consistent application package that can run across environments and scale as a service.
The right question is not “Which compute service is best?”
The right question is:
What does this workload need?
Short bursts?
Full control?
Container portability?
Long-running processes?
Specific dependencies?
Predictable traffic?
Unpredictable spikes?
That is architecture.
4. Data has different shapes
After compute comes state.
Your application needs to store something.
But not all storage is the same.
S3 is good for objects: files, images, exports, logs, backups, static assets.
RDS is good when the data has structure and relationships: customers, orders, products, inventory, payments.
DynamoDB is good when access patterns are known, speed matters, scale matters, and the data model can be designed around key lookups.
The beginner mistake is treating “database” as one generic thing.
The better question is:
How will the application read and write this data?
Do we need joins and relationships?
Do we need predictable low-latency key-value access?
Do we need to store complete files?
Data shape decides service shape.
5. AI is another layer, not the whole architecture
The source talks about Bedrock and SageMaker, and this matters.
Modern applications increasingly add AI features.
But AI does not remove the architecture underneath.
Bedrock can help you use foundation models through AWS.
SageMaker is for deeper machine learning workflows: preparing data, training models, deploying endpoints, and running inference.
But both still need data, permissions, monitoring, cost awareness, and integration with the rest of the system.
AI is not a replacement for cloud fundamentals.
It sits on top of them.
6. Security is not a final checklist
Security appears throughout the request path.
VPC controls the network boundary.
Subnets separate public resources from private resources.
Internet gateways allow public connectivity.
NAT gateways let private resources reach out without becoming directly reachable from the internet.
Security groups control traffic at the resource level.
Network ACLs control traffic at the subnet level.
IAM controls who or what can access each AWS action and resource.
The principle is simple:
Give every component only the access it needs.
No more.
This becomes even more important with AI workloads because models, prompts, documents, and customer data can become sensitive parts of the system.
Security has to be designed into the architecture before the first production incident teaches the lesson for you.
7. You cannot operate what you cannot see
The last part of the request path is visibility.
CloudWatch tells you how the system is behaving.
Metrics.
Logs.
Events.
Alarms.
Dashboards.
CloudTrail tells you who changed what in the AWS account.
API calls.
IAM changes.
VPC changes.
Resource modifications.
When something breaks, you need both.
CloudWatch helps you understand the operational impact.
CloudTrail helps you understand the change history.
That is the difference between guessing and debugging.
The service map
Here is the beginner map:
Route 53 helps users find the application.
CloudFront delivers content closer to users.
S3 stores static files and objects.
Load balancers and API Gateway route dynamic requests.
Lambda, EC2, and ECS run application logic.
RDS and DynamoDB store application data.
Bedrock and SageMaker add AI capability.
VPC and IAM create boundaries and permissions.
CloudWatch and CloudTrail create visibility.
That is already a lot.
But it is no longer random.
Each service has a job.
Takeaway
Do not start AWS by memorizing 200 service names.
Start with one request.
Where does the user go?
Where does static content come from?
Where does dynamic logic run?
Where does data live?
What can access what?
What happens when traffic grows?
What happens when something fails?
What logs prove what changed?
That is how AWS becomes learnable.
Not as a catalog.
As a system.
Sources: user-provided YouTube transcript; AWS documentation; IBM 2025 Cost of a Data Breach reporting.