→

→

AWS Cloud Engineer Roadmap 2026: From Beginner to Job Ready

AWS

AWS Cloud Engineer Roadmap 2026: From Beginner to Job Ready

AWS Cloud Engineer Roadmap 2026: From Beginner to Job Ready

A practical step-by-step AWS Cloud Engineer Roadmap for 2026. Learn what skills matter, which AWS services to focus on, what projects to build and how to move from beginner to job ready.

A practical step-by-step AWS Cloud Engineer Roadmap for 2026. Learn what skills matter, which AWS services to focus on, what projects to build and how to move from beginner to job ready.

A practical step-by-step AWS Cloud Engineer Roadmap for 2026. Learn what skills matter, which AWS services to focus on, what projects to build and how to move from beginner to job ready.

By YourCloudDude

•

•

18 min read

AWS Cloud Engineer Roadmap 2026 from beginner to job ready

Learning AWS can feel overwhelming.

There are hundreds of services, multiple certifications, endless tutorials and no obvious answer to one simple question:

What should I actually learn to become an AWS Cloud Engineer?

The answer is not to memorize every AWS service.

A job-ready cloud engineer needs a combination of cloud fundamentals, Linux, networking, core AWS services, security, automation, infrastructure as code, monitoring, architecture and hands-on projects.

This roadmap gives you a practical order to learn them.

AWS Cloud Engineer Roadmap 2026 at a Glance

If you want the short version, follow this path:

Cloud Fundamentals ↓ Linux + Networking ↓ Git + Basic Scripting ↓ IAM + AWS Security Fundamentals ↓ EC2 + S3 + VPC ↓ Databases ↓ Load Balancing + Auto Scaling ↓ Serverless + Event-Driven AWS ↓ Monitoring + Logging ↓ Infrastructure as Code ↓ Containers ↓ CI/CD + Automation ↓ AWS Architecture ↓ Real Projects ↓ Certification ↓ Portfolio + Interview Preparation

The most important rule

Do not learn AWS service by service without building anything.

For every major concept you learn, build something with it.

That is how AWS starts making sense.

What Does an AWS Cloud Engineer Do?

An AWS Cloud Engineer helps design, deploy, automate, monitor and maintain applications and infrastructure running on Amazon Web Services.

Depending on the company, the role may involve:

  • provisioning cloud infrastructure

  • managing compute and storage resources

  • configuring networks

  • implementing IAM and security controls

  • deploying applications

  • automating infrastructure

  • setting up monitoring and alerts

  • troubleshooting cloud systems

  • optimizing performance and cost

  • creating CI/CD pipelines

  • working with containers

  • improving availability and reliability

  • supporting backup and disaster recovery

You therefore need more than knowledge of AWS services.

You need to understand how cloud systems work together.

Stage 1: Learn Cloud Computing Fundamentals

Before diving into EC2, Lambda or Kubernetes, understand the cloud itself.

You should be able to explain:

  • What is cloud computing?

  • What is Infrastructure as a Service?

  • What is Platform as a Service?

  • What is Software as a Service?

  • What is public cloud?

  • What is private cloud?

  • What is hybrid cloud?

  • What is scalability?

  • What is elasticity?

  • What is high availability?

  • What is fault tolerance?

  • What is disaster recovery?

  • What is pay-as-you-go pricing?

You should also understand the difference between:

On-premises infrastructure

and

Cloud infrastructure

Why this matters

AWS becomes much easier when you understand the problem each service is solving.

For example:

You should understand virtual machines before trying to memorize EC2 instance types.

You should understand object storage before learning Amazon S3.

You should understand DNS before learning Route 53.

Learn the concept first.

Then learn the AWS implementation.

Stage 2: Learn Linux

Linux is one of the most valuable skills you can combine with AWS.

A huge amount of cloud infrastructure runs on Linux, and you will regularly interact with Linux servers while working with EC2, containers, automation and DevOps tooling.

You do not need to become a Linux administrator before starting AWS.

But you should become comfortable with:

Linux basics

  • files and directories

  • file permissions

  • users and groups

  • processes

  • packages

  • environment variables

  • SSH

  • system services

  • logs

  • networking commands

Commands worth knowing

ls

cd

pwd

mkdir

cp

mv

rm

cat

grep

find

chmod

chown

ps

top

curl

wget

ssh

systemctl

journalctl

Mini project

Launch an Amazon EC2 Linux instance.

Then:

  1. Connect to it using SSH.

  2. Install a web server.

  3. Deploy a basic HTML page.

  4. Configure the security group.

  5. Inspect server logs.

  6. Stop and restart the instance.

This tiny project connects Linux, networking, security and AWS in one exercise.

Stage 3: Learn Networking Before Going Deep Into AWS

Networking is one of the areas beginners skip most often.

That becomes a problem later when they encounter VPCs, subnets, routing, load balancers, VPNs and security groups.

Learn these concepts first:

  • IP addresses

  • public vs private IP addresses

  • IPv4

  • CIDR notation

  • ports

  • TCP

  • UDP

  • HTTP

  • HTTPS

  • DNS

  • routing

  • firewalls

  • NAT

  • subnets

  • gateways

  • load balancing

You don't need to become a network engineer.

You need enough networking knowledge to understand how traffic reaches your application and how you control that traffic.

Example

If a website running on EC2 cannot be accessed from the internet, you should know to investigate things such as:

  • security group rules

  • subnet configuration

  • route tables

  • internet gateway

  • public IP addressing

  • web server configuration

That is much more valuable than simply knowing what EC2 stands for.

Stage 4: Learn Git and Basic Scripting

Cloud Engineers automate repetitive work.

That means you should understand both version control and basic scripting.

Learn Git

Focus on:

  • repository

  • commit

  • branch

  • merge

  • pull

  • push

  • .gitignore

  • GitHub workflow

  • pull requests

You will later store infrastructure code, scripts and CI/CD configuration inside Git repositories.

Learn one scripting language

You don't need five programming languages.

Start with:

Python

or

Bash

For Python, learn:

  • variables

  • conditions

  • loops

  • functions

  • lists

  • dictionaries

  • files

  • JSON

  • APIs

  • exception handling

  • modules

Later, learn how to interact with AWS programmatically using AWS SDKs.

The goal

You should eventually be able to say:

"I can automate this instead of doing it manually."

That mindset is more important than memorizing syntax.

Stage 5: Learn IAM Before Most Other AWS Services

AWS Identity and Access Management, or IAM, controls who can access AWS resources and what they are allowed to do.

It should be one of the first AWS services you learn properly.

Understand:

  • IAM users

  • IAM groups

  • IAM roles

  • IAM policies

  • permissions

  • least privilege

  • temporary credentials

  • root account protection

  • multi-factor authentication

AWS uses a shared responsibility model in which AWS protects the infrastructure running the cloud, while customers retain responsibilities that vary according to the services they use, including configuration, access control and protection of their data.

YourCloudDude rule

Never treat security as a chapter you learn at the end.

Learn security alongside every AWS service.

When learning S3, learn S3 security.

When learning EC2, learn EC2 security.

When learning databases, learn database security.

Stage 6: Master the Core AWS Services

You don't need to start with 100 AWS services.

Begin with the services that teach the fundamentals of cloud infrastructure.

Amazon EC2

Learn:

  • instances

  • instance families

  • AMIs

  • EBS volumes

  • security groups

  • key pairs

  • user data

  • Elastic IP addresses

  • instance metadata

  • pricing concepts

Build

Deploy a Linux web server on EC2.

Amazon S3

Learn:

  • buckets

  • objects

  • storage classes

  • versioning

  • lifecycle policies

  • encryption

  • bucket policies

  • static website concepts

  • replication

  • presigned URLs

Build

Create an automated file backup system using S3.

Amazon VPC

Learn:

  • VPCs

  • public subnets

  • private subnets

  • route tables

  • internet gateways

  • NAT

  • security groups

  • network ACLs

  • VPC endpoints

Build

Create a VPC containing:

Internet ↓ Public Subnet ↓ Application Tier ↓ Private Subnet ↓ Database

This will teach you much more than watching another VPC tutorial.

Elastic Load Balancing

Understand why distributing traffic across multiple servers improves availability and scalability.

Learn:

  • Application Load Balancer

  • target groups

  • health checks

  • listener rules

EC2 Auto Scaling

Learn how infrastructure can automatically grow and shrink based on demand.

Understand:

  • Auto Scaling Groups

  • launch templates

  • scaling policies

  • health checks

Architecture

Users ↓ Route 53 ↓ Application Load Balancer ↓ EC2 Auto Scaling Group ↓ Application

That is your first step from "knowing EC2" to designing infrastructure.

Stage 7: Learn AWS Databases

A Cloud Engineer should understand different database models and when to use them.

Don't simply memorize database names.

Start with the difference between:

Relational databases

and

NoSQL databases

Amazon RDS

Learn:

  • database instances

  • engines

  • backups

  • Multi-AZ

  • read replicas

  • security groups

  • encryption

  • automated backups

Use RDS when you need a managed relational database.

Amazon DynamoDB

Learn:

  • tables

  • items

  • attributes

  • partition keys

  • sort keys

  • indexes

  • capacity concepts

  • DynamoDB Streams

  • TTL

Use DynamoDB when your application fits a key-value or document-oriented NoSQL model and benefits from serverless scaling.

Important skill

Don't ask:

"Which AWS database is best?"

Ask:

"What are the requirements of this workload?"

Architecture decisions should start from requirements.

Stage 8: Learn Serverless AWS

Serverless architecture is an important part of modern AWS development.

Start with:

AWS Lambda

Learn:

  • functions

  • triggers

  • execution roles

  • environment variables

  • timeouts

  • memory configuration

  • logs

  • concurrency

Amazon API Gateway

Learn how APIs expose backend functionality.

Amazon SQS

Learn message queues and asynchronous processing.

Amazon SNS

Learn publish/subscribe messaging and notifications.

Amazon EventBridge

Learn event-driven application integration.

Build this project

Serverless URL Shortener

User ↓ API Gateway ↓ Lambda ↓ DynamoDB

Add:

  • IAM permissions

  • CloudWatch logging

  • API validation

  • error handling

Now you aren't simply learning four AWS services.

You are learning how they work together as a system.

Stage 9: Learn Monitoring, Logging and Troubleshooting

Deploying infrastructure is only half the job.

Cloud Engineers must understand what happens after applications go live.

Start with:

Amazon CloudWatch

Learn:

  • metrics

  • logs

  • alarms

  • dashboards

  • log groups

  • log streams

Then understand:

AWS CloudTrail

CloudTrail helps you record AWS account activity and API actions for auditing and investigation.

Also become familiar with:

  • AWS Config

  • AWS Systems Manager

  • health checks

  • application logs

  • operating system logs

Think like an engineer

Instead of asking:

"Is the application working?"

Ask:

  • What is its CPU utilization?

  • What are its response times?

  • Are errors increasing?

  • Are requests failing?

  • Did a deployment change something?

  • Can we identify who modified a resource?

  • Will an alert fire before users complain?

This is the beginning of operational thinking.

Stage 10: Learn Infrastructure as Code

Manually creating infrastructure from the AWS Console is useful while learning.

It should not remain your only method.

Infrastructure as Code allows cloud infrastructure to be defined using code.

Popular options include:

  • AWS CloudFormation

  • AWS CDK

  • Terraform

You do not need to learn all three immediately.

Choose one and become comfortable with:

  • defining resources

  • variables

  • outputs

  • dependencies

  • reusable modules or constructs

  • infrastructure changes

  • version control

Project upgrade

Take a project you previously built manually.

Rebuild the entire architecture using Infrastructure as Code.

That single exercise will dramatically improve your cloud engineering skills.

Stage 11: Learn Docker and Containers

Once you understand servers, networking and deployment, learn containers.

Start with Docker.

Understand:

  • images

  • containers

  • Dockerfiles

  • volumes

  • ports

  • registries

  • environment variables

Then move into AWS container services.

Amazon ECR

Store and manage container images.

Amazon ECS

Run containerized workloads using AWS-managed orchestration.

AWS Fargate

Run containers without managing the underlying server capacity.

You should also understand what Kubernetes and Amazon EKS are, but you do not need to master Kubernetes before becoming productive with AWS.

Build

Containerize a simple application.

Then:

Developer ↓ Docker Image ↓ Amazon ECR ↓ Amazon ECS / Fargate ↓ Load Balancer ↓ Users

Stage 12: Learn CI/CD and Deployment Automation

Modern cloud teams don't manually upload application files every time they release software.

Learn the basic CI/CD lifecycle:

Code ↓ Build ↓ Test ↓ Deploy ↓ Monitor

Learn how tools such as GitHub Actions or AWS-native development services can automate deployments.

Your pipeline should eventually be able to:

  1. detect a code change

  2. run tests

  3. build an artifact or container

  4. deploy the new version

  5. report failures

  6. allow rollback when necessary

Why this matters

A Cloud Engineer isn't just responsible for where applications run.

They often help build the systems that allow teams to release those applications reliably.

Stage 13: Learn Cloud Security Properly

Security should now move beyond IAM basics.

Learn:

  • least-privilege access

  • IAM roles

  • KMS

  • encryption at rest

  • encryption in transit

  • Secrets Manager

  • security groups

  • network ACLs

  • CloudTrail

  • AWS Config

  • AWS WAF

  • GuardDuty

  • backup strategies

  • patching

  • secret management

The objective isn't simply to know security services.

You need to ask:

What can go wrong with this architecture, and how do I reduce that risk?

Stage 14: Start Thinking Like an AWS Architect

At this stage, stop thinking mainly in individual services.

Start thinking in systems.

For every architecture, consider:

  • security

  • reliability

  • scalability

  • availability

  • performance

  • cost

  • operations

  • failure recovery

AWS organizes its Well-Architected Framework around six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.

Use those ideas when reviewing your own projects.

What Does a Real AWS Architecture Look Like?

Consider a production-style web application.

Users ↓ Route 53 ↓ CloudFront ↓ Application Load Balancer ↓ EC2 Auto Scaling Group ↓ Amazon RDS

Supporting services:

S3 → Static assets and object storage CloudWatch → Monitoring and logs IAM → Access control Secrets Manager → Application secrets WAF → Application-layer protection

Don't memorize this architecture.

Ask why each component exists.

Why CloudFront?

To deliver cached content closer to users and reduce latency.

Why a load balancer?

To distribute incoming application traffic across multiple targets.

Why Auto Scaling?

To adjust compute capacity as demand changes.

Why RDS?

To provide a managed relational database.

Why CloudWatch?

To observe what the system is doing.

This is how architecture knowledge develops.

Stage 15: Build Real AWS Projects

Projects are where your AWS knowledge becomes practical.

Do not build only one static S3 website and call your portfolio complete.

Build progressively harder systems.

Project 1: Static Portfolio Website

Use:

  • S3

  • CloudFront

  • Route 53

  • HTTPS

Learn

Storage, DNS, CDN and website delivery.

Project 2: Automated Backup System

Use:

  • S3

  • Lambda

  • EventBridge

  • IAM

  • CloudWatch

Learn

Automation, scheduling, permissions and storage.

Project 3: Serverless API

Use:

  • API Gateway

  • Lambda

  • DynamoDB

  • IAM

  • CloudWatch

Learn

APIs, serverless compute and NoSQL.

Project 4: Highly Available Web Application

Use:

  • VPC

  • public/private subnets

  • Application Load Balancer

  • EC2

  • Auto Scaling

  • RDS

  • CloudWatch

Learn

Networking, scalability, availability and databases.

Project 5: Containerized Application

Use:

  • Docker

  • ECR

  • ECS

  • Fargate

  • Load Balancer

  • CloudWatch

Learn

Containers, deployment and application operations.

Project 6: Infrastructure as Code Deployment

Take one of the previous architectures and deploy it using:

  • Terraform

  • CloudFormation

or

  • AWS CDK

Learn

Automation, repeatability and infrastructure version control.

How Should You Present AWS Projects in Your Portfolio?

Don't write:

"Created an EC2 instance."

That tells recruiters almost nothing.

Instead explain:

Problem

What were you trying to build?

Architecture

Which components did you choose?

Decisions

Why did you choose those services?

Security

How did you protect the system?

Reliability

What happens if something fails?

Monitoring

How do you know whether the application is healthy?

Cost

What did you do to control spending?

Evidence

Include:

  • architecture diagram

  • GitHub repository

  • README

  • screenshots

  • deployment instructions

  • lessons learned

The project should show your engineering decisions, not just screenshots of the AWS Console.

Which AWS Certification Should a Cloud Engineer Take?

Certifications can help organize your learning and validate knowledge, but they should complement hands-on work rather than replace it.

Absolute beginner

AWS Certified Cloud Practitioner

This foundational certification validates general AWS Cloud knowledge rather than a specific technical job role. AWS currently lists areas such as cloud concepts, security and compliance, cloud technology and services, and billing and pricing.

It can be useful if AWS is completely new to you.

It is not mandatory before every associate-level certification.

Architecture-focused learner

AWS Certified Solutions Architect – Associate

AWS states that the certification validates the ability to design solutions based on the AWS Well-Architected Framework, including secure, resilient, high-performing and cost-optimized architectures.

This makes it a strong option for learners who want deeper AWS architecture knowledge.

Operations-focused Cloud Engineer

AWS Certified CloudOps Engineer – Associate

This credential is particularly relevant to Cloud Engineering and operations.

AWS says the current SOA-C03 exam validates the ability to deploy, manage and operate AWS workloads and covers areas including monitoring, reliability, automation, security, networking and business continuity.

YourCloudDude Recommendation

Don't do this:

Certification → Certification → Certification → Start building

Do this:

Learn → Build → Break → Troubleshoot → Improve → Certify

A certification tells people what you know.

Projects help show what you can do.

You want both.

A Practical 6-Month AWS Cloud Engineer Roadmap

You don't need to follow an exact timeline, but this gives you a practical learning sequence.

Month 1: Foundations

Learn:

  • cloud computing

  • Linux

  • Git

  • networking

  • basic Python or Bash

  • AWS global infrastructure

  • IAM

Build:

EC2 Linux Web Server

Month 2: Core AWS

Learn:

  • EC2

  • S3

  • EBS

  • VPC

  • Route 53

  • Load Balancing

  • Auto Scaling

Build:

Highly Available Web Application

Month 3: Data + Serverless

Learn:

  • RDS

  • DynamoDB

  • Lambda

  • API Gateway

  • SQS

  • SNS

  • EventBridge

Build:

Serverless API

Month 4: Operations + Automation

Learn:

  • CloudWatch

  • CloudTrail

  • AWS Config

  • Systems Manager

  • AWS CLI

  • Terraform / CloudFormation / CDK

Build:

Infrastructure as Code Deployment

Month 5: DevOps + Containers

Learn:

  • Docker

  • ECR

  • ECS

  • Fargate

  • CI/CD

  • GitHub Actions

  • deployment strategies

Build:

Containerized Cloud Application

Month 6: Architecture + Portfolio

Learn:

  • Well-Architected principles

  • high availability

  • disaster recovery

  • cost optimization

  • security patterns

  • scalability

Then:

  • improve your best three projects

  • create architecture diagrams

  • clean your GitHub repositories

  • write strong READMEs

  • prepare for scenario-based interviews

  • prepare for a relevant AWS certification

At this point, stop collecting tutorials.

Start designing systems independently.

What AWS Services Should a Beginner Learn First?

If you want a shorter list, prioritize these:

Foundation

  • IAM

  • EC2

  • S3

  • VPC

  • EBS

Networking

  • Route 53

  • Elastic Load Balancing

  • Auto Scaling

  • CloudFront

Databases

  • RDS

  • DynamoDB

Serverless

  • Lambda

  • API Gateway

  • SQS

  • SNS

  • EventBridge

Operations

  • CloudWatch

  • CloudTrail

  • Systems Manager

Security

  • IAM

  • KMS

  • Secrets Manager

  • WAF

  • GuardDuty

Automation

  • AWS CLI

  • CloudFormation

  • CDK

Containers

  • ECR

  • ECS

  • Fargate

Learn these deeply before worrying about dozens of niche AWS services.

Common AWS Learning Mistakes

1. Trying to Learn Every AWS Service

You don't need to.

Learn the core services and learn how systems are designed.

2. Only Watching Tutorials

Watching someone deploy an application is not the same as deploying it yourself.

Build.

Break things.

Fix them.

3. Ignoring Linux

Linux becomes increasingly important as your cloud skills progress.

4. Ignoring Networking

You will struggle with VPCs and distributed architectures if networking fundamentals are weak.

5. Memorizing Instead of Understanding

Don't memorize:

"S3 is object storage."

Understand:

  • why object storage exists

  • when you would choose it

  • how applications access it

  • how permissions work

  • how it differs from block and file storage

6. Collecting Certifications Without Projects

Certifications can validate knowledge.

They do not replace engineering experience.

7. Building Only Tutorial Projects

Eventually remove the tutorial.

Start with a blank page and ask:

How would I design this myself?

That is where real learning starts.

Do You Need Coding to Become an AWS Cloud Engineer?

You don't need to be an advanced software engineer to start learning AWS.

But basic programming or scripting becomes increasingly valuable.

For Cloud Engineering, learn enough Python or Bash to:

  • automate repetitive tasks

  • interact with APIs

  • process JSON

  • manipulate files

  • create scripts

  • work with AWS SDKs

  • troubleshoot automation

You should also become comfortable reading configuration files such as YAML and JSON.

Do You Need DevOps to Become a Cloud Engineer?

You don't need to master an entire DevOps toolchain before learning AWS.

However, modern Cloud Engineering overlaps heavily with DevOps practices.

Eventually become familiar with:

  • Git

  • Linux

  • Docker

  • Infrastructure as Code

  • CI/CD

  • monitoring

  • automation

  • containers

  • configuration management concepts

Think of AWS as the platform.

DevOps practices help you use that platform efficiently and repeatedly.

How Long Does It Take to Learn AWS?

There is no universal number.

Someone with Linux, networking and development experience will progress differently from someone entering technology for the first time.

Instead of measuring progress only in months, measure it by what you can do independently.

Can you:

  • create a secure VPC?

  • deploy an application?

  • configure IAM permissions?

  • troubleshoot connectivity?

  • create monitoring alarms?

  • automate infrastructure?

  • build a deployment pipeline?

  • explain architecture trade-offs?

  • recover from a failure?

  • estimate the cost impact of a design choice?

Those are much better indicators of progress.

When Are You Job Ready?

You do not need to know every AWS service before applying for jobs.

A strong junior Cloud Engineer candidate should ideally be able to:

  • work comfortably with Linux

  • understand basic networking

  • use Git

  • write basic scripts

  • deploy EC2 workloads

  • work with S3

  • configure IAM

  • create VPC networking

  • understand databases

  • monitor workloads

  • use Infrastructure as Code

  • understand CI/CD

  • work with containers

  • troubleshoot common problems

  • explain cloud architecture

  • show multiple practical projects

The key word is:

independently.

If you can build only while copying every line from a tutorial, keep practicing.

The Complete AWS Cloud Engineer Roadmap

Save this learning order:

1. Cloud Fundamentals Understand how cloud computing works.

↓

2. Linux Learn to work confidently with Linux servers.

↓

3. Networking Understand IPs, DNS, ports, routing, subnets and firewalls.

↓

4. Git + Scripting Learn version control and basic Python or Bash.

↓

5. AWS IAM Learn identities, roles, policies and least privilege.

↓

6. Core AWS EC2 → S3 → VPC → EBS → Route 53

↓

7. Scalable Infrastructure Load Balancer → Auto Scaling → CloudFront

↓

8. Databases RDS → DynamoDB

↓

9. Serverless Lambda → API Gateway → SQS → SNS → EventBridge

↓

10. Operations CloudWatch → CloudTrail → Systems Manager

↓

11. Infrastructure as Code Terraform / CloudFormation / CDK

↓

12. Containers Docker → ECR → ECS → Fargate

↓

13. CI/CD Automate application deployment.

↓

14. Security IAM → KMS → Secrets → WAF → GuardDuty

↓

15. Architecture Design secure, scalable, reliable and cost-aware systems.

↓

16. Projects Build increasingly complex AWS systems.

↓

17. Certification Validate what you have learned.

↓

18. Portfolio + Interviews Show how you think, build and troubleshoot.

Key Takeaways

You do not become an AWS Cloud Engineer by memorizing the AWS Console.

You become one by learning how infrastructure works and then repeatedly designing, deploying, securing, automating and troubleshooting it.

Remember:

  • learn concepts before services

  • learn Linux and networking early

  • focus on core AWS services

  • build after every major learning stage

  • learn IAM from the beginning

  • automate repetitive infrastructure

  • monitor what you deploy

  • understand why architecture decisions are made

  • use certifications to validate skills

  • use projects to demonstrate skills

Most importantly:

Don't try to learn all of AWS.

Learn how to solve problems using AWS.

What Should You Learn Next?

Continue your AWS journey with:

15 AWS Projects for Beginners to Build Real Cloud Skills

Move from theory to practical experience with progressively harder projects.

AWS Certification Roadmap 2026

Understand which AWS certification makes sense for your current skill level and career direction.

10 Real-World AWS Architectures You Should Know

Learn how individual AWS services fit together inside production-style systems.

Build Your AWS Skills Through Projects

Reading AWS documentation teaches you what services do.

Building projects teaches you how to use them together.

AWS Project Vault

Build practical AWS projects covering areas such as:

  • serverless applications

  • storage

  • databases

  • monitoring

  • automation

  • networking

  • highly available systems

  • cloud architecture

Explore the AWS Project Vault →

Frequently Asked Questions

Is AWS good for beginners in 2026?

Yes. Beginners can start with cloud fundamentals and gradually move into core AWS services such as IAM, EC2, S3 and VPC. You do not need to understand every AWS service before building useful projects.

Which AWS service should I learn first?

Start with IAM fundamentals, then learn core services such as EC2, S3 and VPC. Learn the underlying concepts, such as compute, storage, identity and networking, alongside the AWS services.

Which programming language is best for AWS Cloud Engineers?

Python is a strong choice because it is easy to learn and useful for scripting, automation, APIs and AWS SDKs. Bash is also valuable for Linux and infrastructure automation.

Should I learn Linux before AWS?

You can start AWS without mastering Linux, but Linux should be learned early. It becomes important when working with EC2, containers, scripting, troubleshooting and DevOps workflows.

Is AWS Cloud Practitioner required before Solutions Architect Associate?

No. Cloud Practitioner can help absolute beginners build foundational AWS knowledge, but it is not a mandatory prerequisite for Solutions Architect Associate.

Which AWS certification is best for a Cloud Engineer?

There is no single certification for every cloud role. Solutions Architect Associate is useful for architecture-focused skills, while AWS Certified CloudOps Engineer – Associate is directly focused on deploying, managing and operating AWS workloads. Choose based on the work you want to do.

Are AWS certifications enough to get a cloud job?

A certification can strengthen your profile, but hands-on skills matter. Build projects, document your architecture decisions, use GitHub and practice troubleshooting alongside certification preparation.

How many AWS projects should I build?

Instead of targeting a large number, build a small collection of increasingly difficult projects. Three to five well-documented projects that demonstrate networking, security, automation, databases, monitoring and architecture can communicate more skill than dozens of copied tutorials.

What is the best way to learn AWS?

Use a repeating cycle:

Learn → Build → Break → Troubleshoot → Improve → Document

That approach develops both AWS knowledge and practical engineering ability.

About YourCloudDude

YourCloudDude creates practical AWS, cloud and Python learning resources designed to help learners move beyond scattered tutorials and build real technical skills through structured roadmaps, projects and architecture-based learning.

AWS CloudOps · Troubleshooting

Deploying an AWS resource is only half the skill. The harder part begins when an instance cannot be reached, an API returns 502, an IAM request is denied or an application suddenly loses database connectivity.

This AWS troubleshooting guide is not a list of definitions or a collection of random fixes. It teaches a repeatable process for identifying the broken layer, tracing the request, testing one hypothesis at a time and proving the fix.

The objective is not to memorize every AWS error. It is to develop a CloudOps method you can reuse across EC2, IAM, S3, VPC, Lambda, API Gateway, RDS and load balancers.

Good troubleshooting is not guessing faster. It is eliminating possibilities systematically.

Quick answer

How Do You Troubleshoot an AWS Problem?

Read the exact symptom, identify the most likely layer, check recent changes and telemetry, trace the request, isolate one component, find the root cause, fix it, verify the behavior and prevent recurrence.

How Cloud Engineers Debug AWS
Read symptom
Identify layer
Recent changes
Metrics + logs
Trace request
Isolate
Root cause
Fix
Verify
Prevent
Jump to a failure

Request path

First Identify Which Layer Is Broken

A request usually crosses several layers. Do not begin by checking random services. Determine where the request stops, then investigate that boundary.

Trace the Request
User
DNS
Network
Load Balancer
Compute
Application
Database
Dependencies
IAM / SecurityMonitoringConfiguration
01

Failure 01 · EC2

EC2 Instance Is Running but SSH Times Out

Symptom

The instance is running, but an SSH connection to port 22 times out.

Most likely layer

Networking

Typical causes

  • Wrong Region or public address
  • Port 22 is not allowed from your trusted source
  • No internet-gateway route for the subnet
  • A network ACL or local firewall blocks the path
  • The SSH service or instance is not ready

Architecture

EC2 troubleshooting path
Laptop
Internet
Internet Gateway
Route Table
Security Group
EC2 :22

How to Diagnose It

  1. Confirm the account, Region, instance state and status checks.
  2. Confirm the intended connectivity model: public IPv4/IPv6, EC2 Instance Connect Endpoint, VPN, bastion or Systems Manager.
  3. For a public path, verify the address, attached internet gateway and the subnet route.
  4. Allow SSH only from the required trusted IP or network; do not open port 22 globally as a shortcut.
  5. Check network ACLs, the local/corporate firewall, the AMI user name and SSH service.
  6. Use VPC Reachability Analyzer when a configuration-path analysis will help isolate the blocking component.

Root cause example

The instance was healthy, but its subnet route table had no route to the attached internet gateway.

Fix

Restore the intended route or use the approved private-access method, then keep the security-group source narrowly scoped.

How to verify the fix

Reconnect using the correct address and user, confirm the host key, then test the application from the same approved path.

Prevent it next time

  • Use reviewed network templates
  • Prefer managed private access where practical
  • Document the approved connection path
02

Failure 02 · IAM

AWS Says “AccessDenied”

Symptom

An AWS API request is rejected with AccessDenied or not authorized.

Most likely layer

Identity and authorization

Typical causes

  • The active user or role is not the identity you expected
  • No applicable Allow grants the exact action and resource
  • An identity, resource, boundary, session or organization policy explicitly denies it
  • A policy condition does not match
  • The request uses the wrong role session context

Architecture

IAM troubleshooting path
User / Role
Policy Evaluation
Allow or Deny
AWS Resource

How to Diagnose It

  1. Capture the exact principal, action, resource ARN and error context.
  2. Run aws sts get-caller-identity when using the CLI or SDK.
  3. Review identity policies and the resource policy where the service supports one.
  4. Check permissions boundaries, session policies, service control policies and applicable conditions.
  5. Distinguish an implicit deny caused by no matching Allow from an explicit Deny, which wins over an Allow.

Root cause example

The application assumed a deployment role whose session policy omitted the required resource ARN.

Fix

Grant only the required action on the intended resource in the correct policy layer, or correct the role/session being used.

How to verify the fix

Repeat the same request as the same principal and confirm CloudTrail records the expected allowed action.

Prevent it next time

  • Use least-privilege policy reviews
  • Log the principal ARN in deployments
  • Test permission boundaries before release
03

Failure 03 · S3

S3 Returns 403 Access Denied

Symptom

An application can reach Amazon S3 but receives HTTP 403 for a bucket or object operation.

Most likely layer

Authorization

Typical causes

  • IAM or bucket policy does not allow the operation
  • An explicit deny or Block Public Access setting rejects the request context
  • Object ownership or cross-account context differs
  • A customer-managed KMS key policy lacks required access
  • A presigned URL is expired or signed for a different request

Architecture

S3 troubleshooting path
Application
IAM Role
S3 Authorization
Bucket / Object

How to Diagnose It

  1. Identify the caller with sts get-caller-identity and record the exact S3 action.
  2. Check the bucket ARN versus object ARN and review both identity and bucket policies.
  3. Inspect Object Ownership and any cross-account path.
  4. For SSE-KMS objects, verify the relevant KMS permissions and key policy.
  5. For presigned URLs, check expiry, method, headers, Region and the signer’s permissions.

Root cause example

The role could read the bucket, but the object used a customer-managed KMS key that the role could not decrypt.

Fix

Correct the narrowly scoped S3 and, when required, KMS permissions. Keep the bucket private unless public access is truly intended.

How to verify the fix

Repeat the exact object operation as the same role and confirm the correct object is returned without broadening public access.

Prevent it next time

  • Test the real runtime role
  • Standardize bucket ownership
  • Review S3 and KMS policies together
04

Failure 04 · ALB

Application Load Balancer Says Target Is Unhealthy

Symptom

A registered EC2 or ECS target fails the target group health check.

Most likely layer

Application and network

Typical causes

  • Health-check path does not exist
  • Health-check port differs from the listening port
  • The target security group blocks the load balancer
  • The service has not started or is bound to the wrong interface
  • The returned status code is outside the configured success matcher

Architecture

ALB troubleshooting path
Users
ALB
GET /health :8080
EC2 / ECS

How to Diagnose It

  1. Read the target health reason code before changing settings.
  2. Confirm protocol, port, path, timeout and success-code matcher.
  3. From inside the VPC, request the same path on the target’s private address and port.
  4. Verify the target security group allows the load balancer security group.
  5. Check application startup logs and confirm the process is listening on the expected interface and port.

Root cause example

The target group checked /health on port 8080, while the application listened on port 3000.

Fix

Align the target group health check with the application or correct the application listener, while preserving least-privilege security-group rules.

How to verify the fix

Wait for the healthy threshold, confirm the target becomes Healthy and make a request through the load balancer.

Prevent it next time

  • Expose a lightweight health endpoint
  • Keep app and infrastructure ports in one configuration source
  • Alert on healthy-host count
05

Failure 05 · Lambda

Lambda Function Times Out

Symptom

The function reaches its configured timeout before returning a response.

Most likely layer

Runtime and dependency

Typical causes

  • A downstream API or database is slow
  • A network call has no shorter client timeout
  • VPC routing, NAT or security rules block an outbound dependency
  • The workload needs more CPU or a different design
  • The function is waiting, retrying or processing too much in one invocation

Architecture

Lambda troubleshooting path
Event
Lambda
External Dependency
Response

How to Diagnose It

  1. Use the REPORT line and logs to find where duration is spent.
  2. Add timing around external calls and inspect the last successful log statement.
  3. Test downstream availability and configure explicit connection/read timeouts.
  4. If VPC-connected, check routes, security groups, DNS and NAT or service endpoints.
  5. Test memory settings because Lambda allocates CPU proportionally with memory, but do not treat more memory as a substitute for finding a blocked call.

Root cause example

A VPC-connected function called a public API from a private subnet with no working outbound path.

Fix

Restore the required network path or use an appropriate private endpoint, and set bounded client timeouts and retries.

How to verify the fix

Invoke with representative events, confirm duration stays below the timeout and verify the dependency receives the expected request.

Prevent it next time

  • Instrument dependency latency
  • Use bounded retries and timeouts
  • Alarm on errors, duration and throttles
06

Failure 06 · API

API Gateway Returns 502 Internal Server Error

Symptom

A client receives 502 from an API Gateway endpoint backed by Lambda.

Most likely layer

Integration response

Typical causes

  • The Lambda function ran but returned an error
  • The proxy response has the wrong shape or a non-string body
  • The function version or alias is not the one expected
  • Integration logging is incomplete
  • The integration contract differs from the deployed API

Architecture

API troubleshooting path
Client
API Gateway
Lambda
Response Contract

How to Diagnose It

  1. Capture the request ID and enable useful API access/execution logging for the API type.
  2. Open the corresponding Lambda log stream and locate the same request.
  3. Invoke the function with the API event shape.
  4. For a Lambda proxy integration, validate statusCode, headers, isBase64Encoded when used, and a string body.
  5. Distinguish invocation rejection, which can surface as 500, from a function error or malformed proxy response, which AWS documents as 502.

Root cause example

The function returned body as an object instead of a JSON string in a proxy response.

Fix

Return the response contract expected by the integration and handle application errors deliberately.

How to verify the fix

Call the deployed stage, confirm the intended HTTP status/body and correlate the request in API Gateway and Lambda logs.

Prevent it next time

  • Contract-test integration responses
  • Log request IDs
  • Deploy API and Lambda changes together
07

Failure 07 · RDS

Application Cannot Connect to RDS

Symptom

The application cannot establish or authenticate a database connection.

Most likely layer

Network, authentication or configuration

Typical causes

  • Wrong endpoint, port or database name
  • The DB security group does not allow the application security group
  • Subnet routing, peering or network ACLs block the path
  • The DB is unavailable or still starting
  • Credentials or secrets are wrong or stale

Architecture

RDS troubleshooting path
Application
App Security Group
VPC Path
DB Security Group
RDS

How to Diagnose It

  1. Classify the error: DNS failure, connection timeout/refused, TLS failure or authentication rejection.
  2. Confirm the current RDS endpoint, port, engine status and Region.
  3. Test DNS and TCP reachability from the application environment.
  4. Verify the DB security group allows the application security group or the required trusted source.
  5. Only after the network path works, verify the secret, database user, TLS mode and application connection string.

Root cause example

A new application security group was deployed, but the DB inbound rule still referenced the old group.

Fix

Restore the intended security-group relationship or correct the connection configuration and credentials.

How to verify the fix

Connect from the application runtime, run a harmless query and confirm the app’s connection-pool health.

Prevent it next time

  • Reference security groups rather than broad CIDRs
  • Monitor connections and DB availability
  • Rotate and test secrets safely
08

Failure 08 · VPC

Two AWS Resources Cannot Communicate Inside a VPC

Symptom

A source resource cannot reach a destination on a known protocol and port.

Most likely layer

Network path

Typical causes

  • The destination security group does not allow the source
  • A route is missing or points to the wrong target
  • A network ACL blocks the request or return path
  • The resources are in unconnected VPCs or overlapping networks
  • The destination service is not listening

Architecture

VPC troubleshooting path
Source
Source SG
Route
Subnet / NACL
Destination SG
Destination

How to Diagnose It

  1. Write down source, destination, protocol and port.
  2. Confirm the destination is listening and its address is current.
  3. Inspect security groups in both directions of the intended stateful flow.
  4. Trace route tables, peering/transit-gateway attachments and network ACL rules.
  5. Use VPC Reachability Analyzer to analyze configured reachability and identify a blocking component.

Root cause example

The destination security group allowed the old source CIDR but not the source instance’s security group.

Fix

Correct the narrow network control or route that breaks the intended path, then confirm the service is listening.

How to verify the fix

Test the exact protocol and port from the source and rerun the path analysis after the configuration change.

Prevent it next time

  • Document flows as source–destination–port
  • Review network changes
  • Use repeatable infrastructure definitions
09

Failure 09 · CLI

AWS CLI Shows No Resources but They Exist in the Console

Symptom

A list command returns no resources while the console shows them.

Most likely layer

Configuration

Typical causes

  • The CLI uses a different Region
  • The active profile belongs to another account
  • A different role is assumed
  • Environment credentials override the profile
  • A command filter excludes the resource

Architecture

CLI troubleshooting path
CLI Profile
Account
Region
List / Filter

How to Diagnose It

  1. Run aws sts get-caller-identity.
  2. Run aws configure list and inspect environment variables.
  3. Print the effective Region and compare it with the console.
  4. Retry without optional filters and confirm the service is regional or global as expected.

Root cause example

The console displayed Account A in us-east-1 while the CLI profile used Account B in eu-west-1.

Fix

Select the intended profile and Region explicitly, then remove or correct the filter.

How to verify the fix

Repeat the list command and compare the returned resource ID with the console.

Prevent it next time

  • Name profiles clearly
  • Show account and Region in shell prompts
  • Pass Region explicitly in automation
10

Failure 10 · Logs

The App Is Broken but CloudWatch Shows “Nothing”

Symptom

The application fails, but the expected CloudWatch log group or log events are empty.

Most likely layer

Observability

Typical causes

  • The wrong account, Region, log group or stream is open
  • Application or service logging is not configured
  • The delivery role lacks required log permissions
  • The request never reaches the expected code path
  • Retention or log routing removed or redirected the events

Architecture

Logs troubleshooting path
Application
Logging
CloudWatch Logs
Query / Alarm

How to Diagnose It

  1. Confirm account, Region, time range, log group and stream.
  2. Check whether the service must have logging enabled and whether the destination exists.
  3. Verify the execution or delivery role can create streams and put log events when those permissions are required.
  4. Add a known startup or request-boundary log and test again.
  5. Check metrics separately: metrics and logs are different signals, and one can exist without the other.

Root cause example

The application failed at the load balancer and never invoked the code path that emitted application logs.

Fix

Restore logging configuration or permissions, then instrument the earliest useful boundary in the request path.

How to verify the fix

Generate a controlled request and confirm a timestamped event, correlation ID and expected metric appear in the correct account and Region.

Prevent it next time

  • Provision logging with the workload
  • Use correlation IDs
  • Alert on missing expected telemetry

Save this

AWS Troubleshooting Cheat Sheet

SymptomCheck firstLikely layer
EC2 SSH timeoutNetwork path + security groupNetworking
AccessDeniedIAM evaluationIdentity and authorization
S3 403IAM + bucket policyAuthorization
ALB unhealthyHealth checkApplication and network
Lambda timeoutLogs + dependencyRuntime and dependency
API 502Lambda + response contractIntegration response
RDS timeoutNetwork + DB security groupNetwork, authentication or configuration
VPC connection failsPath analysisNetwork path
CLI resource missingAccount + RegionConfiguration
No logsLogging configurationObservability

EC2 SSH timeout

Check firstNetwork path + security group
LayerNetworking

AccessDenied

Check firstIAM evaluation
LayerIdentity and authorization

S3 403

Check firstIAM + bucket policy
LayerAuthorization

ALB unhealthy

Check firstHealth check
LayerApplication and network

Lambda timeout

Check firstLogs + dependency
LayerRuntime and dependency

API 502

Check firstLambda + response contract
LayerIntegration response

RDS timeout

Check firstNetwork + DB security group
LayerNetwork, authentication or configuration

VPC connection fails

Check firstPath analysis
LayerNetwork path

CLI resource missing

Check firstAccount + Region
LayerConfiguration

No logs

Check firstLogging configuration
LayerObservability

Fast triage

The 5-Minute AWS Debugging Checklist

  • Am I in the correct AWS account?
  • Am I in the correct Region?
  • What changed recently?
  • What identity or role is being used?
  • What exact error do I have?
  • Is DNS resolving?
  • Can traffic reach the destination?
  • Are security groups correct?
  • What do the logs show?
  • Are downstream services healthy?
  • Can I reproduce the failure?
  • Did the fix resolve the root cause?

Avoid these traps

Troubleshooting Habits That Make AWS Problems Worse

  1. Changing five things at once
  2. Granting AdministratorAccess to test
  3. Opening security groups to everyone
  4. Ignoring the exact error message
  5. Assuming AWS itself is broken first
  6. Ignoring the Region or account
  7. Fixing the symptom but not the cause
  8. Not documenting the incident

Transferable method

Think Like a Cloud Engineer

Observe the evidence, form a testable hypothesis, change one controlled variable, isolate the failing boundary, fix the cause, verify the result and document what you learned.

Think Like a Cloud Engineer
Observe
Hypothesize
Test
Isolate
Fix
Verify
Document

Learn → Build → Break → Troubleshoot → Improve → Document

Troubleshooting is one of the skills that turns AWS knowledge into practical cloud engineering ability. Use the AWS Cloud Engineer Roadmap 2026 to place it in your wider learning path, then intentionally debug the systems in 15 AWS Projects for Beginners. When certification supports that path, compare options in the AWS Certification Roadmap 2026.

Future deep dives can expand this playbook with AWS IAM Explained, AWS VPC Explained, EC2 vs Lambda, an AWS CloudOps Engineer Roadmap and a dedicated AWS CloudWatch Guide.

Build AWS Skills Beyond Tutorials

Troubleshooting gets easier when you have actually built the systems you are debugging. Explore YourCloudDude’s hands-on AWS projects and architecture resources.

Explore AWS Resources →

Direct answers

AWS Troubleshooting FAQ

What is the best way to troubleshoot AWS?

The best approach is to identify the broken layer, inspect recent changes and telemetry, trace the request, isolate one component, apply one fix and verify the result.

Why does AWS say AccessDenied?

AWS returns AccessDenied when the effective policy evaluation does not allow the requested action, or when an applicable policy explicitly denies it.

Why can I not connect to my EC2 instance?

First separate instance health from network reachability, then check the address, approved access path, route, security group, network ACL and SSH service.

How do I troubleshoot AWS networking?

Write down the source, destination, protocol and port, then trace every routing and security control between them.

What is VPC Reachability Analyzer?

VPC Reachability Analyzer is a static configuration-analysis tool that determines whether a configured network path is reachable and identifies a blocking component; it is not a packet generator.

Why does API Gateway return a 502 error?

With a Lambda integration, API Gateway can return 502 when the function runs but errors or when the proxy response does not match the required format.

What should I check when Lambda times out?

Check where execution time is spent, especially downstream calls, retries, VPC networking and resource usage, before increasing the timeout.

What AWS service should I use for logs?

Amazon CloudWatch Logs is the central log service for many AWS workloads, but the producing service or application must be configured and authorized to deliver the logs.

Is troubleshooting important for Cloud Engineers?

Yes. Cloud Engineers must be able to trace failures across identity, network, compute, application, data and observability layers instead of only deploying resources.

Technical references

Official AWS Documentation Used

AWS CloudOps · Troubleshooting

Deploying an AWS resource is only half the skill. The harder part begins when an instance cannot be reached, an API returns 502, an IAM request is denied or an application suddenly loses database connectivity.

This AWS troubleshooting guide is not a list of definitions or a collection of random fixes. It teaches a repeatable process for identifying the broken layer, tracing the request, testing one hypothesis at a time and proving the fix.

The objective is not to memorize every AWS error. It is to develop a CloudOps method you can reuse across EC2, IAM, S3, VPC, Lambda, API Gateway, RDS and load balancers.

Good troubleshooting is not guessing faster. It is eliminating possibilities systematically.

Quick answer

How Do You Troubleshoot an AWS Problem?

Read the exact symptom, identify the most likely layer, check recent changes and telemetry, trace the request, isolate one component, find the root cause, fix it, verify the behavior and prevent recurrence.

How Cloud Engineers Debug AWS
Read symptom
Identify layer
Recent changes
Metrics + logs
Trace request
Isolate
Root cause
Fix
Verify
Prevent
Jump to a failure

Request path

First Identify Which Layer Is Broken

A request usually crosses several layers. Do not begin by checking random services. Determine where the request stops, then investigate that boundary.

Trace the Request
User
DNS
Network
Load Balancer
Compute
Application
Database
Dependencies
IAM / SecurityMonitoringConfiguration
01

Failure 01 · EC2

EC2 Instance Is Running but SSH Times Out

Symptom

The instance is running, but an SSH connection to port 22 times out.

Most likely layer

Networking

Typical causes

  • Wrong Region or public address
  • Port 22 is not allowed from your trusted source
  • No internet-gateway route for the subnet
  • A network ACL or local firewall blocks the path
  • The SSH service or instance is not ready

Architecture

EC2 troubleshooting path
Laptop
Internet
Internet Gateway
Route Table
Security Group
EC2 :22

How to Diagnose It

  1. Confirm the account, Region, instance state and status checks.
  2. Confirm the intended connectivity model: public IPv4/IPv6, EC2 Instance Connect Endpoint, VPN, bastion or Systems Manager.
  3. For a public path, verify the address, attached internet gateway and the subnet route.
  4. Allow SSH only from the required trusted IP or network; do not open port 22 globally as a shortcut.
  5. Check network ACLs, the local/corporate firewall, the AMI user name and SSH service.
  6. Use VPC Reachability Analyzer when a configuration-path analysis will help isolate the blocking component.

Root cause example

The instance was healthy, but its subnet route table had no route to the attached internet gateway.

Fix

Restore the intended route or use the approved private-access method, then keep the security-group source narrowly scoped.

How to verify the fix

Reconnect using the correct address and user, confirm the host key, then test the application from the same approved path.

Prevent it next time

  • Use reviewed network templates
  • Prefer managed private access where practical
  • Document the approved connection path
02

Failure 02 · IAM

AWS Says “AccessDenied”

Symptom

An AWS API request is rejected with AccessDenied or not authorized.

Most likely layer

Identity and authorization

Typical causes

  • The active user or role is not the identity you expected
  • No applicable Allow grants the exact action and resource
  • An identity, resource, boundary, session or organization policy explicitly denies it
  • A policy condition does not match
  • The request uses the wrong role session context

Architecture

IAM troubleshooting path
User / Role
Policy Evaluation
Allow or Deny
AWS Resource

How to Diagnose It

  1. Capture the exact principal, action, resource ARN and error context.
  2. Run aws sts get-caller-identity when using the CLI or SDK.
  3. Review identity policies and the resource policy where the service supports one.
  4. Check permissions boundaries, session policies, service control policies and applicable conditions.
  5. Distinguish an implicit deny caused by no matching Allow from an explicit Deny, which wins over an Allow.

Root cause example

The application assumed a deployment role whose session policy omitted the required resource ARN.

Fix

Grant only the required action on the intended resource in the correct policy layer, or correct the role/session being used.

How to verify the fix

Repeat the same request as the same principal and confirm CloudTrail records the expected allowed action.

Prevent it next time

  • Use least-privilege policy reviews
  • Log the principal ARN in deployments
  • Test permission boundaries before release
03

Failure 03 · S3

S3 Returns 403 Access Denied

Symptom

An application can reach Amazon S3 but receives HTTP 403 for a bucket or object operation.

Most likely layer

Authorization

Typical causes

  • IAM or bucket policy does not allow the operation
  • An explicit deny or Block Public Access setting rejects the request context
  • Object ownership or cross-account context differs
  • A customer-managed KMS key policy lacks required access
  • A presigned URL is expired or signed for a different request

Architecture

S3 troubleshooting path
Application
IAM Role
S3 Authorization
Bucket / Object

How to Diagnose It

  1. Identify the caller with sts get-caller-identity and record the exact S3 action.
  2. Check the bucket ARN versus object ARN and review both identity and bucket policies.
  3. Inspect Object Ownership and any cross-account path.
  4. For SSE-KMS objects, verify the relevant KMS permissions and key policy.
  5. For presigned URLs, check expiry, method, headers, Region and the signer’s permissions.

Root cause example

The role could read the bucket, but the object used a customer-managed KMS key that the role could not decrypt.

Fix

Correct the narrowly scoped S3 and, when required, KMS permissions. Keep the bucket private unless public access is truly intended.

How to verify the fix

Repeat the exact object operation as the same role and confirm the correct object is returned without broadening public access.

Prevent it next time

  • Test the real runtime role
  • Standardize bucket ownership
  • Review S3 and KMS policies together
04

Failure 04 · ALB

Application Load Balancer Says Target Is Unhealthy

Symptom

A registered EC2 or ECS target fails the target group health check.

Most likely layer

Application and network

Typical causes

  • Health-check path does not exist
  • Health-check port differs from the listening port
  • The target security group blocks the load balancer
  • The service has not started or is bound to the wrong interface
  • The returned status code is outside the configured success matcher

Architecture

ALB troubleshooting path
Users
ALB
GET /health :8080
EC2 / ECS

How to Diagnose It

  1. Read the target health reason code before changing settings.
  2. Confirm protocol, port, path, timeout and success-code matcher.
  3. From inside the VPC, request the same path on the target’s private address and port.
  4. Verify the target security group allows the load balancer security group.
  5. Check application startup logs and confirm the process is listening on the expected interface and port.

Root cause example

The target group checked /health on port 8080, while the application listened on port 3000.

Fix

Align the target group health check with the application or correct the application listener, while preserving least-privilege security-group rules.

How to verify the fix

Wait for the healthy threshold, confirm the target becomes Healthy and make a request through the load balancer.

Prevent it next time

  • Expose a lightweight health endpoint
  • Keep app and infrastructure ports in one configuration source
  • Alert on healthy-host count
05

Failure 05 · Lambda

Lambda Function Times Out

Symptom

The function reaches its configured timeout before returning a response.

Most likely layer

Runtime and dependency

Typical causes

  • A downstream API or database is slow
  • A network call has no shorter client timeout
  • VPC routing, NAT or security rules block an outbound dependency
  • The workload needs more CPU or a different design
  • The function is waiting, retrying or processing too much in one invocation

Architecture

Lambda troubleshooting path
Event
Lambda
External Dependency
Response

How to Diagnose It

  1. Use the REPORT line and logs to find where duration is spent.
  2. Add timing around external calls and inspect the last successful log statement.
  3. Test downstream availability and configure explicit connection/read timeouts.
  4. If VPC-connected, check routes, security groups, DNS and NAT or service endpoints.
  5. Test memory settings because Lambda allocates CPU proportionally with memory, but do not treat more memory as a substitute for finding a blocked call.

Root cause example

A VPC-connected function called a public API from a private subnet with no working outbound path.

Fix

Restore the required network path or use an appropriate private endpoint, and set bounded client timeouts and retries.

How to verify the fix

Invoke with representative events, confirm duration stays below the timeout and verify the dependency receives the expected request.

Prevent it next time

  • Instrument dependency latency
  • Use bounded retries and timeouts
  • Alarm on errors, duration and throttles
06

Failure 06 · API

API Gateway Returns 502 Internal Server Error

Symptom

A client receives 502 from an API Gateway endpoint backed by Lambda.

Most likely layer

Integration response

Typical causes

  • The Lambda function ran but returned an error
  • The proxy response has the wrong shape or a non-string body
  • The function version or alias is not the one expected
  • Integration logging is incomplete
  • The integration contract differs from the deployed API

Architecture

API troubleshooting path
Client
API Gateway
Lambda
Response Contract

How to Diagnose It

  1. Capture the request ID and enable useful API access/execution logging for the API type.
  2. Open the corresponding Lambda log stream and locate the same request.
  3. Invoke the function with the API event shape.
  4. For a Lambda proxy integration, validate statusCode, headers, isBase64Encoded when used, and a string body.
  5. Distinguish invocation rejection, which can surface as 500, from a function error or malformed proxy response, which AWS documents as 502.

Root cause example

The function returned body as an object instead of a JSON string in a proxy response.

Fix

Return the response contract expected by the integration and handle application errors deliberately.

How to verify the fix

Call the deployed stage, confirm the intended HTTP status/body and correlate the request in API Gateway and Lambda logs.

Prevent it next time

  • Contract-test integration responses
  • Log request IDs
  • Deploy API and Lambda changes together
07

Failure 07 · RDS

Application Cannot Connect to RDS

Symptom

The application cannot establish or authenticate a database connection.

Most likely layer

Network, authentication or configuration

Typical causes

  • Wrong endpoint, port or database name
  • The DB security group does not allow the application security group
  • Subnet routing, peering or network ACLs block the path
  • The DB is unavailable or still starting
  • Credentials or secrets are wrong or stale

Architecture

RDS troubleshooting path
Application
App Security Group
VPC Path
DB Security Group
RDS

How to Diagnose It

  1. Classify the error: DNS failure, connection timeout/refused, TLS failure or authentication rejection.
  2. Confirm the current RDS endpoint, port, engine status and Region.
  3. Test DNS and TCP reachability from the application environment.
  4. Verify the DB security group allows the application security group or the required trusted source.
  5. Only after the network path works, verify the secret, database user, TLS mode and application connection string.

Root cause example

A new application security group was deployed, but the DB inbound rule still referenced the old group.

Fix

Restore the intended security-group relationship or correct the connection configuration and credentials.

How to verify the fix

Connect from the application runtime, run a harmless query and confirm the app’s connection-pool health.

Prevent it next time

  • Reference security groups rather than broad CIDRs
  • Monitor connections and DB availability
  • Rotate and test secrets safely
08

Failure 08 · VPC

Two AWS Resources Cannot Communicate Inside a VPC

Symptom

A source resource cannot reach a destination on a known protocol and port.

Most likely layer

Network path

Typical causes

  • The destination security group does not allow the source
  • A route is missing or points to the wrong target
  • A network ACL blocks the request or return path
  • The resources are in unconnected VPCs or overlapping networks
  • The destination service is not listening

Architecture

VPC troubleshooting path
Source
Source SG
Route
Subnet / NACL
Destination SG
Destination

How to Diagnose It

  1. Write down source, destination, protocol and port.
  2. Confirm the destination is listening and its address is current.
  3. Inspect security groups in both directions of the intended stateful flow.
  4. Trace route tables, peering/transit-gateway attachments and network ACL rules.
  5. Use VPC Reachability Analyzer to analyze configured reachability and identify a blocking component.

Root cause example

The destination security group allowed the old source CIDR but not the source instance’s security group.

Fix

Correct the narrow network control or route that breaks the intended path, then confirm the service is listening.

How to verify the fix

Test the exact protocol and port from the source and rerun the path analysis after the configuration change.

Prevent it next time

  • Document flows as source–destination–port
  • Review network changes
  • Use repeatable infrastructure definitions
09

Failure 09 · CLI

AWS CLI Shows No Resources but They Exist in the Console

Symptom

A list command returns no resources while the console shows them.

Most likely layer

Configuration

Typical causes

  • The CLI uses a different Region
  • The active profile belongs to another account
  • A different role is assumed
  • Environment credentials override the profile
  • A command filter excludes the resource

Architecture

CLI troubleshooting path
CLI Profile
Account
Region
List / Filter

How to Diagnose It

  1. Run aws sts get-caller-identity.
  2. Run aws configure list and inspect environment variables.
  3. Print the effective Region and compare it with the console.
  4. Retry without optional filters and confirm the service is regional or global as expected.

Root cause example

The console displayed Account A in us-east-1 while the CLI profile used Account B in eu-west-1.

Fix

Select the intended profile and Region explicitly, then remove or correct the filter.

How to verify the fix

Repeat the list command and compare the returned resource ID with the console.

Prevent it next time

  • Name profiles clearly
  • Show account and Region in shell prompts
  • Pass Region explicitly in automation
10

Failure 10 · Logs

The App Is Broken but CloudWatch Shows “Nothing”

Symptom

The application fails, but the expected CloudWatch log group or log events are empty.

Most likely layer

Observability

Typical causes

  • The wrong account, Region, log group or stream is open
  • Application or service logging is not configured
  • The delivery role lacks required log permissions
  • The request never reaches the expected code path
  • Retention or log routing removed or redirected the events

Architecture

Logs troubleshooting path
Application
Logging
CloudWatch Logs
Query / Alarm

How to Diagnose It

  1. Confirm account, Region, time range, log group and stream.
  2. Check whether the service must have logging enabled and whether the destination exists.
  3. Verify the execution or delivery role can create streams and put log events when those permissions are required.
  4. Add a known startup or request-boundary log and test again.
  5. Check metrics separately: metrics and logs are different signals, and one can exist without the other.

Root cause example

The application failed at the load balancer and never invoked the code path that emitted application logs.

Fix

Restore logging configuration or permissions, then instrument the earliest useful boundary in the request path.

How to verify the fix

Generate a controlled request and confirm a timestamped event, correlation ID and expected metric appear in the correct account and Region.

Prevent it next time

  • Provision logging with the workload
  • Use correlation IDs
  • Alert on missing expected telemetry

Save this

AWS Troubleshooting Cheat Sheet

SymptomCheck firstLikely layer
EC2 SSH timeoutNetwork path + security groupNetworking
AccessDeniedIAM evaluationIdentity and authorization
S3 403IAM + bucket policyAuthorization
ALB unhealthyHealth checkApplication and network
Lambda timeoutLogs + dependencyRuntime and dependency
API 502Lambda + response contractIntegration response
RDS timeoutNetwork + DB security groupNetwork, authentication or configuration
VPC connection failsPath analysisNetwork path
CLI resource missingAccount + RegionConfiguration
No logsLogging configurationObservability

EC2 SSH timeout

Check firstNetwork path + security group
LayerNetworking

AccessDenied

Check firstIAM evaluation
LayerIdentity and authorization

S3 403

Check firstIAM + bucket policy
LayerAuthorization

ALB unhealthy

Check firstHealth check
LayerApplication and network

Lambda timeout

Check firstLogs + dependency
LayerRuntime and dependency

API 502

Check firstLambda + response contract
LayerIntegration response

RDS timeout

Check firstNetwork + DB security group
LayerNetwork, authentication or configuration

VPC connection fails

Check firstPath analysis
LayerNetwork path

CLI resource missing

Check firstAccount + Region
LayerConfiguration

No logs

Check firstLogging configuration
LayerObservability

Fast triage

The 5-Minute AWS Debugging Checklist

  • Am I in the correct AWS account?
  • Am I in the correct Region?
  • What changed recently?
  • What identity or role is being used?
  • What exact error do I have?
  • Is DNS resolving?
  • Can traffic reach the destination?
  • Are security groups correct?
  • What do the logs show?
  • Are downstream services healthy?
  • Can I reproduce the failure?
  • Did the fix resolve the root cause?

Avoid these traps

Troubleshooting Habits That Make AWS Problems Worse

  1. Changing five things at once
  2. Granting AdministratorAccess to test
  3. Opening security groups to everyone
  4. Ignoring the exact error message
  5. Assuming AWS itself is broken first
  6. Ignoring the Region or account
  7. Fixing the symptom but not the cause
  8. Not documenting the incident

Transferable method

Think Like a Cloud Engineer

Observe the evidence, form a testable hypothesis, change one controlled variable, isolate the failing boundary, fix the cause, verify the result and document what you learned.

Think Like a Cloud Engineer
Observe
Hypothesize
Test
Isolate
Fix
Verify
Document

Learn → Build → Break → Troubleshoot → Improve → Document

Troubleshooting is one of the skills that turns AWS knowledge into practical cloud engineering ability. Use the AWS Cloud Engineer Roadmap 2026 to place it in your wider learning path, then intentionally debug the systems in 15 AWS Projects for Beginners. When certification supports that path, compare options in the AWS Certification Roadmap 2026.

Future deep dives can expand this playbook with AWS IAM Explained, AWS VPC Explained, EC2 vs Lambda, an AWS CloudOps Engineer Roadmap and a dedicated AWS CloudWatch Guide.

Build AWS Skills Beyond Tutorials

Troubleshooting gets easier when you have actually built the systems you are debugging. Explore YourCloudDude’s hands-on AWS projects and architecture resources.

Explore AWS Resources →

Direct answers

AWS Troubleshooting FAQ

What is the best way to troubleshoot AWS?

The best approach is to identify the broken layer, inspect recent changes and telemetry, trace the request, isolate one component, apply one fix and verify the result.

Why does AWS say AccessDenied?

AWS returns AccessDenied when the effective policy evaluation does not allow the requested action, or when an applicable policy explicitly denies it.

Why can I not connect to my EC2 instance?

First separate instance health from network reachability, then check the address, approved access path, route, security group, network ACL and SSH service.

How do I troubleshoot AWS networking?

Write down the source, destination, protocol and port, then trace every routing and security control between them.

What is VPC Reachability Analyzer?

VPC Reachability Analyzer is a static configuration-analysis tool that determines whether a configured network path is reachable and identifies a blocking component; it is not a packet generator.

Why does API Gateway return a 502 error?

With a Lambda integration, API Gateway can return 502 when the function runs but errors or when the proxy response does not match the required format.

What should I check when Lambda times out?

Check where execution time is spent, especially downstream calls, retries, VPC networking and resource usage, before increasing the timeout.

What AWS service should I use for logs?

Amazon CloudWatch Logs is the central log service for many AWS workloads, but the producing service or application must be configured and authorized to deliver the logs.

Is troubleshooting important for Cloud Engineers?

Yes. Cloud Engineers must be able to trace failures across identity, network, compute, application, data and observability layers instead of only deploying resources.

Technical references

Official AWS Documentation Used