AWS

AWS Certification Roadmap 2026: Which Certification Should You Take?

AWS certifications aren't a single linear path. This guide helps you choose the right certification based on your experience, role and cloud career goals.

By YourCloudDude

•

Sep 22, 2026

•

16 min read

AWS Certification Roadmap 2026 branching from Cloud Practitioner into architecture, CloudOps, development and data paths

AWS certification is not one mandatory ladder that every learner must climb in the same order. The right starting point depends on your existing experience, the work you want to do and how much hands-on AWS practice you already have.

This roadmap compares the main foundational, associate and professional directions so you can choose a focused path instead of collecting credentials without a clear goal.

AWS Certification Roadmap at a Glance

New to AWS? Build cloud fundamentals first. Cloud Practitioner can validate that foundation, then a role-based associate certification can take you toward architecture, operations, development or data engineering.

START → CLOUD PRACTITIONER → CHOOSE YOUR DIRECTION

Architecture → AWS Certified Solutions Architect – Associate
Cloud operations → AWS Certified CloudOps Engineer – Associate
Application development → AWS Certified Developer – Associate
Data engineering → AWS Certified Data Engineer – Associate
Experienced professionals → Professional or specialty paths aligned with real responsibilities

Cloud Practitioner is useful for many beginners, but it is not a universal prerequisite. Learners with solid cloud fundamentals and practical AWS experience may start with the associate certification that best matches their intended role.

Which AWS Certification Should You Take First?

If you are completely new to AWS, Cloud Practitioner can provide a useful foundation. If you already understand cloud fundamentals and have hands-on AWS experience, you may choose an associate-level certification aligned with your career goal instead.

Career goal	Suggested direction
Complete beginner	Cloud Practitioner
Solutions or cloud architect	Solutions Architect – Associate
Cloud operations	CloudOps Engineer – Associate
AWS developer	Developer – Associate
Data engineer	Data Engineer – Associate
Advanced architecture	Solutions Architect – Professional
DevOps or platform engineering	Associate foundation → DevOps Engineer – Professional

Do You Need AWS Cloud Practitioner First?

No. AWS does not require Cloud Practitioner before an associate exam. It is most useful when you need a structured introduction to cloud concepts, AWS terminology, security, billing and the shared responsibility model.

You may be ready to skip it when you already understand those fundamentals, can navigate common AWS services and have built or operated small workloads. Use the relevant exam guide to check your gaps before deciding.

YourCloudDude Tip

Don’t choose certifications because someone told you there is one mandatory path. Choose them based on the work you want to be able to do.

AWS Certified Cloud Practitioner

AWS Certified Cloud Practitioner validates a high-level understanding of AWS Cloud services, terminology and core cloud concepts. AWS describes it as a useful starting point for people with no prior IT or cloud experience and for non-technical roles that need cloud literacy.

It makes sense when you want an organized foundation before role-based study. If you already design, build or operate workloads on AWS, its technical depth may be below your current level.

Level: Foundational
Best for: Beginners and learners building foundational AWS knowledge
Focus: Cloud concepts, AWS services, security, billing and support
Next step: A role-based associate certification

AWS Certified Solutions Architect – Associate

AWS Certified Solutions Architect – Associate focuses on designing secure, resilient, high-performing and cost-aware solutions across a broad range of AWS services. It suits learners who enjoy evaluating requirements and deciding how a cloud system should be structured.

Level: Associate
Best for: Cloud architecture and solutions architecture
Core question: How should this AWS system be designed?

Skills You Should Have Before Taking It

Core cloud and AWS service fundamentals
IAM, networking, compute, storage and database basics
Availability, scalability and disaster-recovery concepts
Cost and performance trade-offs
Enough hands-on practice to explain why one design fits better than another

AWS Certified CloudOps Engineer – Associate

AWS Certified CloudOps Engineer – Associate validates the ability to deploy, manage and operate workloads on AWS. It covers monitoring, maintenance, security controls, networking, business continuity, cost optimization and performance optimization.

This path is especially relevant to cloud engineers, operations specialists and support professionals who need to troubleshoot systems and keep production workloads reliable.

Level: Associate
Best for: Cloud engineers and operations-focused roles
Core question: How do we deploy, operate, monitor and recover this system?

Architecture and Operations Are Complementary

Solutions Architect	CloudOps Engineer
Designs the system and evaluates trade-offs	Deploys, monitors and operates the system
Prioritizes architecture, resilience, security and cost	Prioritizes observability, automation, troubleshooting and recovery

AWS Certified Developer – Associate

AWS Certified Developer – Associate validates technical proficiency in developing, testing, deploying and debugging AWS Cloud-based applications. It aligns with developers who build APIs, event-driven systems and serverless applications or use AWS SDKs and deployment tooling.

Level: Associate
Best for: Developers building applications using AWS
Focus: Application services, serverless development, deployment, debugging, APIs, SDK usage and developer-facing IAM

AWS Certified Data Engineer – Associate

AWS Certified Data Engineer – Associate focuses on implementing data pipelines and data stores on AWS. It is suited to learners working with ingestion, transformation, storage, data quality, lifecycle management and the operation of cloud data workloads.

Level: Associate
Best for: Cloud data engineers
Focus: Data pipelines, data stores, data operations, quality, security and cost-performance optimization

Choose Your AWS Certification Path

Choose the path that matches the work you want to practice. The certification should organize your learning; projects should prove that you can apply it.

Cloud Architect

Cloud fundamentals
Optional Cloud Practitioner
Solutions Architect – Associate
Projects and architecture practice
Solutions Architect – Professional

Cloud Engineer or CloudOps

Cloud fundamentals
Hands-on AWS projects
Solutions Architect – Associate
CloudOps Engineer – Associate
Production operations practice

AWS Developer

AWS fundamentals
Serverless application projects
Developer – Associate
CI/CD and containers
Advanced DevOps skills

Data Engineer

AWS fundamentals
SQL and data fundamentals
Data projects
Data Engineer – Associate
Advanced data architecture

Cloud Practitioner vs Solutions Architect Associate

Cloud Practitioner validates broad foundational knowledge. Solutions Architect – Associate goes deeper into technical design and is more appropriate when you need to make architecture decisions.

Dimension	Cloud Practitioner	Solutions Architect – Associate
Level	Foundational	Associate
Audience	New cloud learners and non-technical roles	Technical learners and architecture-focused roles
Technical depth	High-level concepts and terminology	Service selection and design trade-offs
Architecture	Awareness	Core focus
Hands-on expectations	Helpful but not required by AWS	Practical experience strongly supports preparation
Useful for	Building cloud literacy	Designing AWS solutions

Solutions Architect vs CloudOps Engineer

Neither certification is universally better. Solutions Architect – Associate emphasizes how workloads should be designed, while CloudOps Engineer – Associate emphasizes how workloads should be deployed, monitored, maintained and recovered.

Choose Solutions Architect when…	Choose CloudOps when…
You enjoy system design and service trade-offs	You enjoy monitoring, automation and troubleshooting
Your goal is cloud or solutions architecture	Your goal is cloud engineering, operations or support
You want broad architectural context	You want deeper operational practice

AWS Projects vs Certifications: Which Matters More?

Certifications validate that you understand a defined body of knowledge. Projects demonstrate how you apply that knowledge, make trade-offs, troubleshoot failures and document a working system. They are stronger together than either is alone.

Learn → Build → Break → Troubleshoot → Improve → Certify

Study the next concept, build a small system, test failure conditions, investigate what breaks, improve the design and then use certification preparation to close remaining gaps.

Explore AWS Projects for Beginners →

Recommended AWS Learning Paths

Absolute Beginner

Cloud fundamentals
Cloud Practitioner
AWS projects
Solutions Architect – Associate

Future Cloud Engineer

Linux and networking
AWS fundamentals
AWS projects
Solutions Architect – Associate
CloudOps Engineer – Associate
CloudOps or DevOps projects

Future AWS Developer

Programming fundamentals
AWS fundamentals
Serverless projects
Developer – Associate
CI/CD and containers

Common AWS Certification Mistakes

Collecting certifications without building projects
Choosing a certification only because it appears easy or difficult
Memorizing practice questions instead of understanding the service decisions
Ignoring Linux and networking fundamentals
Trying to learn every AWS service
Taking a professional certification before gaining suitable experience
Holding certificates without documenting a practical portfolio

Continue Your AWS Learning

Use the AWS Cloud Engineer Roadmap 2026 to connect certifications with Linux, networking, projects and career preparation.

Build practical evidence with 15 AWS Projects for Beginners.

Future YourCloudDude guides will explore CloudOps engineering, IAM, AWS architecture and focused certification comparisons. These pages are not linked until they exist, preventing broken navigation.

Learn AWS Beyond the Exam

Certification knowledge becomes much more useful when you can apply it to real cloud systems. Explore YourCloudDude’s AWS guides, projects and architecture resources to combine certification learning with hands-on skills.

Explore AWS Resources →

Frequently Asked Questions

Which AWS certification should I take first?

Start with Cloud Practitioner if you are completely new to cloud concepts. If you already have foundational knowledge and hands-on AWS experience, choose the associate certification that aligns with your intended role.

Can I skip AWS Cloud Practitioner?

Yes. AWS does not require Cloud Practitioner before an associate exam. Skip it only when you can already explain core cloud concepts, common AWS services, security responsibilities and basic billing concepts.

Is Solutions Architect Associate good for beginners?

It can be a strong first technical certification for learners who already have cloud or IT fundamentals. Complete beginners usually benefit from foundational study and small AWS projects first.

Which AWS certification is aligned with cloud engineering?

CloudOps Engineer – Associate is directly aligned with deploying, managing, monitoring and operating AWS workloads. Solutions Architect – Associate adds useful design context, so many cloud engineers study both areas.

Is CloudOps Engineer harder than Cloud Practitioner?

CloudOps Engineer – Associate is more technical and operationally focused than the foundational Cloud Practitioner certification. It assumes stronger knowledge of deployment, monitoring, networking, security and recovery.

Should I take Solutions Architect before CloudOps?

It is not mandatory, but Solutions Architect – Associate can provide broad service and design context before deeper operational study. Experienced operations professionals may choose CloudOps first.

Are AWS certifications enough to get a cloud job?

No credential guarantees a role. Certifications can validate knowledge, while projects, troubleshooting ability, documentation, communication and relevant experience demonstrate that you can apply it.

How many AWS certifications do I need?

Start with one certification that matches your goal. Add another only when it supports a new responsibility or deeper specialization; a small number of relevant certifications plus strong projects is usually more coherent than collecting unrelated credentials.

Should I build AWS projects before taking a certification?

Yes, when possible. Projects make abstract exam topics concrete and expose gaps that practice questions cannot reveal. Build before and during exam preparation, not only afterward.

Official AWS Certification References

Review the AWS Certification catalog for the current certification lineup and role-based paths.

Check the official AWS exam guides before scheduling an exam because objectives and versions can change.

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

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

Confirm the account, Region, instance state and status checks.
Confirm the intended connectivity model: public IPv4/IPv6, EC2 Instance Connect Endpoint, VPN, bastion or Systems Manager.
For a public path, verify the address, attached internet gateway and the subnet route.
Allow SSH only from the required trusted IP or network; do not open port 22 globally as a shortcut.
Check network ACLs, the local/corporate firewall, the AMI user name and SSH service.
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

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

Capture the exact principal, action, resource ARN and error context.
Run aws sts get-caller-identity when using the CLI or SDK.
Review identity policies and the resource policy where the service supports one.
Check permissions boundaries, session policies, service control policies and applicable conditions.
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

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

Identify the caller with sts get-caller-identity and record the exact S3 action.
Check the bucket ARN versus object ARN and review both identity and bucket policies.
Inspect Object Ownership and any cross-account path.
For SSE-KMS objects, verify the relevant KMS permissions and key policy.
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

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

Read the target health reason code before changing settings.
Confirm protocol, port, path, timeout and success-code matcher.
From inside the VPC, request the same path on the target’s private address and port.
Verify the target security group allows the load balancer security group.
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

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

Use the REPORT line and logs to find where duration is spent.
Add timing around external calls and inspect the last successful log statement.
Test downstream availability and configure explicit connection/read timeouts.
If VPC-connected, check routes, security groups, DNS and NAT or service endpoints.
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

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

Capture the request ID and enable useful API access/execution logging for the API type.
Open the corresponding Lambda log stream and locate the same request.
Invoke the function with the API event shape.
For a Lambda proxy integration, validate statusCode, headers, isBase64Encoded when used, and a string body.
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

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

Classify the error: DNS failure, connection timeout/refused, TLS failure or authentication rejection.
Confirm the current RDS endpoint, port, engine status and Region.
Test DNS and TCP reachability from the application environment.
Verify the DB security group allows the application security group or the required trusted source.
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

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

Write down source, destination, protocol and port.
Confirm the destination is listening and its address is current.
Inspect security groups in both directions of the intended stateful flow.
Trace route tables, peering/transit-gateway attachments and network ACL rules.
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

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

Run aws sts get-caller-identity.
Run aws configure list and inspect environment variables.
Print the effective Region and compare it with the console.
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

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

Confirm account, Region, time range, log group and stream.
Check whether the service must have logging enabled and whether the destination exists.
Verify the execution or delivery role can create streams and put log events when those permissions are required.
Add a known startup or request-boundary log and test again.
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

Symptom	Check first	Likely layer
EC2 SSH timeout	Network path + security group	Networking
AccessDenied	IAM evaluation	Identity and authorization
S3 403	IAM + bucket policy	Authorization
ALB unhealthy	Health check	Application and network
Lambda timeout	Logs + dependency	Runtime and dependency
API 502	Lambda + response contract	Integration response
RDS timeout	Network + DB security group	Network, authentication or configuration
VPC connection fails	Path analysis	Network path
CLI resource missing	Account + Region	Configuration
No logs	Logging configuration	Observability

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

Changing five things at once
Granting AdministratorAccess to test
Opening security groups to everyone
Ignoring the exact error message
Assuming AWS itself is broken first
Ignoring the Region or account
Fixing the symptom but not the cause
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

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?

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

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

Confirm the account, Region, instance state and status checks.
Confirm the intended connectivity model: public IPv4/IPv6, EC2 Instance Connect Endpoint, VPN, bastion or Systems Manager.
For a public path, verify the address, attached internet gateway and the subnet route.
Allow SSH only from the required trusted IP or network; do not open port 22 globally as a shortcut.
Check network ACLs, the local/corporate firewall, the AMI user name and SSH service.
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

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

Capture the exact principal, action, resource ARN and error context.
Run aws sts get-caller-identity when using the CLI or SDK.
Review identity policies and the resource policy where the service supports one.
Check permissions boundaries, session policies, service control policies and applicable conditions.
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

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

Identify the caller with sts get-caller-identity and record the exact S3 action.
Check the bucket ARN versus object ARN and review both identity and bucket policies.
Inspect Object Ownership and any cross-account path.
For SSE-KMS objects, verify the relevant KMS permissions and key policy.
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

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

Read the target health reason code before changing settings.
Confirm protocol, port, path, timeout and success-code matcher.
From inside the VPC, request the same path on the target’s private address and port.
Verify the target security group allows the load balancer security group.
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

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

Use the REPORT line and logs to find where duration is spent.
Add timing around external calls and inspect the last successful log statement.
Test downstream availability and configure explicit connection/read timeouts.
If VPC-connected, check routes, security groups, DNS and NAT or service endpoints.
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

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

Capture the request ID and enable useful API access/execution logging for the API type.
Open the corresponding Lambda log stream and locate the same request.
Invoke the function with the API event shape.
For a Lambda proxy integration, validate statusCode, headers, isBase64Encoded when used, and a string body.
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

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

Classify the error: DNS failure, connection timeout/refused, TLS failure or authentication rejection.
Confirm the current RDS endpoint, port, engine status and Region.
Test DNS and TCP reachability from the application environment.
Verify the DB security group allows the application security group or the required trusted source.
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

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

Write down source, destination, protocol and port.
Confirm the destination is listening and its address is current.
Inspect security groups in both directions of the intended stateful flow.
Trace route tables, peering/transit-gateway attachments and network ACL rules.
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

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

Run aws sts get-caller-identity.
Run aws configure list and inspect environment variables.
Print the effective Region and compare it with the console.
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

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

Confirm account, Region, time range, log group and stream.
Check whether the service must have logging enabled and whether the destination exists.
Verify the execution or delivery role can create streams and put log events when those permissions are required.
Add a known startup or request-boundary log and test again.
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

Symptom	Check first	Likely layer
EC2 SSH timeout	Network path + security group	Networking
AccessDenied	IAM evaluation	Identity and authorization
S3 403	IAM + bucket policy	Authorization
ALB unhealthy	Health check	Application and network
Lambda timeout	Logs + dependency	Runtime and dependency
API 502	Lambda + response contract	Integration response
RDS timeout	Network + DB security group	Network, authentication or configuration
VPC connection fails	Path analysis	Network path
CLI resource missing	Account + Region	Configuration
No logs	Logging configuration	Observability

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

Changing five things at once
Granting AdministratorAccess to test
Opening security groups to everyone
Ignoring the exact error message
Assuming AWS itself is broken first
Ignoring the Region or account
Fixing the symptom but not the cause
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

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