→

→

How to Learn AWS From Scratch in 2026: A 90-Day Beginner Plan

AWS

How to Learn AWS From Scratch in 2026: A 90-Day Beginner Plan

How to Learn AWS From Scratch in 2026: A 90-Day Beginner Plan

You don't need to learn hundreds of AWS services. This 90-day plan shows beginners exactly what to learn, what to build and what to focus on first.

You don't need to learn hundreds of AWS services. This 90-day plan shows beginners exactly what to learn, what to build and what to focus on first.

You don't need to learn hundreds of AWS services. This 90-day plan shows beginners exactly what to learn, what to build and what to focus on first.

By YourCloudDude

•

•

22 min read

Learn AWS from scratch 90-day roadmap from cloud fundamentals through IAM, core services, networking, serverless and projects

AWS can feel overwhelming because there are hundreds of services and thousands of tutorials. Beginners do not need to learn everything. A faster way to build a useful foundation is to learn a small set of cloud concepts, see how AWS implements them and immediately practise through small projects.

This guide turns that approach into a practical 12-week plan. You will begin with account safety and cloud fundamentals, then progress through identity, compute, storage, networking, databases, serverless systems, monitoring and multi-service projects.

The goal is not to finish AWS in 90 days. The goal is to build a strong enough foundation to continue learning independently.

How Should a Beginner Learn AWS?

Start with cloud fundamentals and account safety, learn the core AWS building blocks, then combine them in progressively larger projects. Use certification only when it supports your learning goal rather than treating it as the finish line.

Cloud Fundamentals

↓

AWS Account + Billing Safety

↓

IAM

↓

EC2 + S3

↓

Networking + VPC

↓

Databases

↓

Serverless

↓

Monitoring

↓

Projects

↓

Certification, if useful

Don’t learn AWS by memorizing services. Learn a concept, understand how AWS implements it, and then build something with it.

What Should You Know Before Learning AWS?

You can begin from a general technology background. The foundations below make the first weeks smoother, but none of them should delay you for months.

You Do NOT Need

  • Advanced programming

  • Kubernetes

  • DevOps expertise

  • A networking certification

  • Previous cloud experience

Helpful Foundations

  • Basic computer concepts

  • Basic networking

  • Basic Linux

  • Command-line basics

  • Very basic Python or Bash

Want the complete career skill map? Read the AWS Cloud Engineer Roadmap 2026 →

Set Up AWS Safely Before Building Anything

Treat account setup as your first cloud engineering task. The objective is to explore safely without using the most privileged identity for normal work or losing track of running resources.

Create Your AWS Account

Choose the current account plan that fits your learning needs, review which services and usage limits apply, and understand that eligibility, credits and access differ by plan. Do not assume every service is free.

Secure the Root Account

Use the root user only for tasks that require it. Protect the root credentials, recovery email and phone number, and never create root access keys for routine work.

Enable MFA

Enable multi-factor authentication for the root user immediately. AWS also recommends strong sign-in mechanisms and MFA for human access.

Understand IAM

Learn identities, roles, policies and least privilege. Prefer temporary credentials and role-based access where possible instead of long-lived access keys.

Configure AWS Budgets and Cost Monitoring

Create a small cost budget, add alert thresholds and check the Billing and Cost Management console regularly. A budget is a monitoring control; it does not make every service free or automatically stop every resource.

Learn How to Delete Resources

Before leaving a lab, identify every resource you created and confirm how to stop or delete it. Remember that related resources such as storage volumes, snapshots, public IP addresses and databases may continue to exist after one service is stopped.

Beginner Rule

Before launching your first AWS project, understand how AWS billing works and know how to delete every resource you create.

Weeks 1–2: Understand Cloud Computing and AWS

Build the mental model first. Learn what cloud computing changes, how AWS organizes infrastructure and where responsibility shifts between AWS and the customer.

Learn

  • Cloud computing, IaaS, PaaS and SaaS

  • Regions and Availability Zones

  • The shared responsibility model

  • AWS global infrastructure

  • Basic AWS pricing concepts

  • The AWS Management Console

  • IAM identities, roles, policies and least privilege

Build

Explore the AWS Console safely, enable account protections, create appropriate everyday access and inspect the Billing and Cost Management console.

By the End of Week 2

  • Explain what AWS is

  • Describe a Region and an Availability Zone

  • Explain how IAM controls access

  • Describe the shared responsibility model

  • Explain how AWS billing broadly works

Weeks 3–4: Learn Compute and Storage

Compute and storage are where abstract cloud ideas become tangible. Build small, disposable environments and document each resource you create.

Amazon EC2

  • Instances and instance families

  • Amazon Machine Images (AMIs)

  • Amazon EBS volumes

  • Security groups

  • SSH and secure access

  • Public and private IP basics

Amazon S3

  • Buckets and objects

  • Permissions and public-access controls

  • Versioning

  • Lifecycle concepts

  • Durability and storage concepts

Project 1 — Deploy a Linux Web Server on EC2

Launch a small Linux instance, connect securely, install a web server, restrict inbound traffic to only what the project needs, verify the page and then remove the resources.

Project 2 — Create a Static Website or Storage Project with S3

Use S3 to understand object storage, versioning and access controls. If you publish content, follow current S3 security guidance and avoid making unrelated data public.

Weeks 5–6: Learn AWS Networking

Networking explains why traffic can or cannot reach a workload. Learn the path a request takes rather than memorizing VPC screenshots.

  • IP addresses and CIDR

  • VPCs

  • Public and private subnets

  • Route tables

  • Internet gateways

  • NAT concepts

  • Security groups

  • DNS and Amazon Route 53

First Architecture

Internet

↓

Internet Gateway

↓

Public Subnet

↓

EC2

Next Architecture

Internet

↓

Load Balancer

↓

Public Subnets

↓

Application

↓

Private Subnet

Outcome

By the end of week 6, you should begin to answer: Why can or can’t traffic reach my application? Trace the route, security rules, addressing and service configuration instead of changing settings randomly.

A future YourCloudDude guide will cover AWS VPC design in more depth.

Weeks 7–8: Learn Databases and Serverless

Now compare managed relational databases, NoSQL and event-driven compute. Focus on when each model fits rather than trying to master every feature.

Amazon RDS

  • Relational database concepts

  • Managed database operations

  • Backups

  • The Multi-AZ concept

Amazon DynamoDB

  • NoSQL concepts

  • Tables and keys

  • Access patterns

  • Serverless database concepts

AWS Lambda

  • Functions

  • Events and triggers

  • Execution roles

  • Logs and basic troubleshooting

Amazon API Gateway

  • API endpoints

  • Requests and responses

  • Lambda integrations

Project — Build a Serverless URL Shortener

User

↓

API Gateway

↓

Lambda

↓

DynamoDB

Define a simple data model, create a small API, use an execution role with only the required permissions and inspect the function logs when a request fails.

Ready to turn these concepts into practical projects? Explore AWS Projects for Beginners →

Weeks 9–10: Learn Monitoring and Security

Move from tutorial thinking to engineering thinking. A workload is not complete when it launches; you also need to observe it, control access and investigate changes.

CloudWatch

  • Metrics

  • Logs

  • Alarms

  • Dashboards

CloudTrail

  • Account activity

  • API activity

  • Auditing and investigation

Security Foundations

  • IAM roles

  • Least privilege

  • AWS KMS basics

  • AWS Secrets Manager basics

Operational Questions

  • Is the application healthy?

  • Where are the logs?

  • Who changed this resource?

  • What happens when something fails?

  • Who has access?

  • Are costs unexpectedly increasing?

Weeks 11–12: Build Without Following a Tutorial

By this stage, stop copying every tutorial step. Choose a problem, draw the architecture yourself, build it, break it and troubleshoot it.

The YourCloudDude Learning Loop

Learn

↓

Build

↓

Break

↓

Troubleshoot

↓

Improve

↓

Document

This loop turns service knowledge into practical judgment. Keep the first independent project deliberately small so you can explain every component and every cost.

Suggested Project — Highly Available Web Application

Users

↓

Application Load Balancer

↓

EC2 Auto Scaling

↓

RDS

Support the design with a VPC, IAM roles, CloudWatch monitoring and a backup plan. Start with a diagram and a resource checklist before opening the console.

Questions You Should Be Able to Answer

  • Why use a load balancer?

  • What happens if an instance fails?

  • Where should the database live?

  • How will the system be monitored?

  • What costs money?

  • What should be secured?

What AWS Services Should Beginners Learn First?

Begin with a small group of services that teach identity, compute, storage, networking, databases, serverless systems and monitoring.

Priority

AWS service

Learn it for

1

IAM

Identity and access

2

EC2

Compute

3

S3

Object storage

4

VPC

Networking

5

Route 53

DNS

6

RDS

Relational databases

7

DynamoDB

NoSQL

8

Lambda

Serverless compute

9

API Gateway

APIs

10

CloudWatch

Monitoring

You do not need to learn 100 AWS services before building useful cloud projects.

How Much AWS Should You Study Each Day?

A consistent 60–90 minute session is more useful than an occasional all-day sprint. Adjust the schedule around work, school and the difficulty of the current topic.

Example 60–90 Minute Study Session

  • 20 minutes — Learn one concept from a reliable source

  • 40 minutes — Build with the concept in a small environment

  • 20 minutes — Troubleshoot, clean up resources and document what you learned

The 90-day plan is a learning framework, not a guarantee of job readiness.

Should You Learn AWS or Python First?

You can begin learning AWS without mastering Python. Learn basic AWS concepts while developing Python or Bash skills in parallel.

AWS Fundamentals + Basic Python or Bash

↓

Automation

↓

Cloud Engineering

Python becomes increasingly useful for automation, APIs, AWS SDKs, small scripts and Lambda functions. A future YourCloudDude Python roadmap will connect those skills into a focused learning path.

Should Beginners Get AWS Certified?

Certification can provide structure and validate a defined body of knowledge, but it should be combined with hands-on work. AWS Certified Cloud Practitioner can help some absolute beginners, while a role-based associate certification may fit learners who already have relevant foundations and practice.

Not sure which certification fits your goal? Read the AWS Certification Roadmap 2026 →

How Should You Learn AWS?

Official AWS Documentation

Use official documentation to verify service behavior, security guidance, quotas, pricing details and configuration options. Learn to search the documentation for the exact task in front of you.

AWS Training and Skill Builder

Use structured official training when you need a guided sequence or want to prepare for a certification objective.

Hands-On Labs and Projects

Build after every important concept. A small project that fails and requires troubleshooting teaches more than copying a large architecture without understanding it.

Your Own Notes

Record architecture decisions, commands, permission errors, cost observations and cleanup steps. Your notes should help you reproduce the project without the tutorial.

Common Mistakes When Learning AWS

  1. Learning services randomly instead of following a concept-first path

  2. Watching tutorials without building anything

  3. Ignoring IAM and using overly broad permissions

  4. Avoiding networking until every connectivity problem feels mysterious

  5. Memorizing definitions without tracing how a request flows through the system

  6. Chasing certifications before practising the underlying skills

  7. Copying projects without explaining each component

  8. Forgetting to stop or delete resources

  9. Moving to Kubernetes before learning core infrastructure concepts

  10. Never documenting decisions, mistakes or troubleshooting steps

How Do You Know You’re Actually Improving at AWS?

Use these YourCloudDude learning checkpoints as practical self-assessments. They are not official AWS levels.

Level 1 — Beginner

  • Navigate the AWS Console

  • Use IAM more safely

  • Launch and clean up an EC2 instance

  • Create and manage S3 objects

Level 2 — Developing

  • Create basic VPC networking

  • Deploy a small application

  • Use managed databases

  • Troubleshoot simple connectivity

Level 3 — Practical

  • Combine multiple AWS services

  • Monitor applications

  • Implement basic security controls

  • Automate repetitive steps

Level 4 — Strong Foundation

  • Build without copying a tutorial

  • Explain architecture choices

  • Troubleshoot failures

  • Document projects

  • Consider cost, security and reliability

Your 90-Day AWS Checklist

By Day 30

  • Cloud fundamentals

  • AWS account security

  • IAM

  • EC2

  • S3

  • Linux basics

  • First projects

By Day 60

  • Networking

  • VPC

  • Route 53

  • RDS

  • DynamoDB

  • Lambda

  • API Gateway

By Day 90

  • Monitoring

  • CloudWatch

  • CloudTrail

  • Security fundamentals

  • Multi-service projects

  • Troubleshooting

  • Documentation

  • Portfolio development

  • Optional certification preparation

Want a More Structured AWS Learning Path?

If you prefer learning from one structured path instead of piecing together dozens of disconnected tutorials, the YourCloudDude AWS Bundle combines beginner learning, certification resources, practical projects and architecture-focused material.

Explore the AWS Bundle →

Continue Learning

AWS Cloud Engineer Roadmap 2026 — for the complete career-focused AWS skill path.

15 AWS Projects for Beginners — for turning AWS concepts into practical experience.

AWS Certification Roadmap 2026 — for choosing a certification based on your career goal.

Frequently Asked Questions

How do I start learning AWS from scratch?

Begin with cloud fundamentals and account safety, then learn IAM, EC2, S3 and VPC through small hands-on tasks. Add databases, serverless services and monitoring only after the core concepts make sense. Build and document a project at each stage.

Can I learn AWS with no IT experience?

Yes. Start with basic computer, networking, Linux and command-line concepts alongside AWS. You do not need advanced programming or previous cloud experience, but complete beginners may need more than 90 days to become comfortable with every stage.

Is AWS difficult for beginners?

AWS feels difficult when services are learned randomly. A small, ordered learning path makes it manageable: identity first, then compute and storage, networking, data, serverless, monitoring and projects.

Can I learn AWS in 3 months?

You can build a useful AWS foundation in three months with consistent practice. The timeframe is not a guarantee of job readiness or mastery; your starting knowledge, available study time and project depth matter.

Do I need coding to learn AWS?

No. You can learn core AWS concepts without advanced coding. Basic Python or Bash becomes valuable as you automate tasks, call APIs, work with AWS SDKs and build Lambda functions.

Should I learn Linux before AWS?

Learn basic Linux in parallel with AWS rather than waiting to master it first. File navigation, permissions, processes, packages, logs and secure shell access are enough to support early EC2 projects.

Which AWS service should I learn first?

Start with IAM because identity and permissions affect almost everything you build. Then learn EC2, S3 and VPC so you understand compute, storage and networking before combining more services.

Should beginners get AWS certified?

Certification can give beginners a structured syllabus, but it works best with projects. Cloud Practitioner may help absolute beginners, while learners with stronger foundations may prefer a role-based associate path.

How many hours per day should I study AWS?

A realistic starting point is 60–90 minutes on most study days: a short learning block, a larger hands-on block, then troubleshooting and notes. Consistency matters more than a rigid daily target.

Should I learn AWS through projects?

Yes. Projects connect services, expose permission and networking mistakes, and force you to troubleshoot. Begin with small projects you can fully explain, then progress to multi-service systems.

Official AWS References

Review the AWS IAM security best practices for current root-user, MFA, temporary-credential and least-privilege guidance.

Check the current AWS Free Tier information before creating an account because plan access, credits and usage limits can change.

Use AWS Budgets documentation to configure cost and usage monitoring.

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