47 AWS Interview Questions: EC2, S3, Lambda & IAM (2026)

AWS interviews usually focus on a smaller set of services than the full catalog. Strong answers connect service mechanics to workload requirements, failure modes, security boundaries and measured cost rather than reciting product names.

You can know what every service does and still fail if you can't explain how VPC networking actually works or when to use Lambda versus EC2. This guide covers the core AWS services that appear in nearly every cloud interview, with the questions interviewers actually ask.

Table of Contents

1. AWS Fundamentals Questions
2. EC2 and Compute Questions
3. Lambda and Serverless Questions
4. S3 Storage Questions
5. EBS and Block Storage Questions
6. VPC Networking Questions
7. IAM Security Questions
8. RDS Database Questions
9. DynamoDB Questions
10. Architecture and Troubleshooting Questions

AWS Fundamentals Questions

Understanding AWS's global infrastructure is essential before diving into specific services.

What is the difference between a Region and an Availability Zone?

A Region is a separate geographic area identified by a code such as us-east-1 or eu-west-1. AWS designs Regions for isolation, and most regional resources do not replicate to another Region unless the service and workload configure it. Some global services and cross-Region features deliberately cross that boundary, so “completely independent” is too absolute.

An Availability Zone (AZ) is one or more discrete data centers within a region, each with independent power, cooling, and networking. AZs within a region connect via low-latency links, enabling you to build highly available applications that survive data center failures.

flowchart TB
    subgraph aws["AWS Global Infrastructure"]
        subgraph r1["Region (us-east-1)"]
            az1a["AZ (us-east-1a)"]
            az1b["AZ (us-east-1b)"]
            az1c["AZ (us-east-1c)"]
        end
        subgraph r2["Region (eu-west-1)"]
            az2a["AZ (eu-west-1a)"]
            az2b["..."]
        end
        edge["Edge infrastructure"]
    end

AWS edge infrastructure supports services such as CloudFront and Route 53, but an edge location is not another Region or AZ and service behavior differs. Avoid memorizing a location count because the network changes.

Why should you deploy across multiple Availability Zones?

Deploying independent capacity across multiple AZs can improve availability. It does not guarantee uninterrupted service: load balancers, databases, queues, caches, quotas, routing, deployment tooling and application state must survive the failure, and failover needs capacity and testing.

A Single-AZ dependency can remain a failure domain for the path that depends on it. Choose the number of AZs from availability objectives and service characteristics, then use fault injection and recovery exercises to validate the design.

What is the scope of different AWS services?

Services operate at different scopes, which affects how you architect solutions and what you need to create in each region you use. Understanding this prevents common mistakes like assuming S3 data replicates automatically across regions.

Common interview trap: “Is S3 regional or global?” A general-purpose bucket is created in a Region, but its name is unique across accounts within an AWS partition, not universally across every partition. Cross-Region Replication is explicit. Directory buckets for S3 Express One Zone are zonal and use different naming and API semantics.

What are the six pillars of the AWS Well-Architected Framework?

The Well-Architected Framework provides a consistent approach for evaluating architectures against AWS best practices. Interviewers expect you to know these pillars and frame your architecture answers around them.

When answering architecture questions, reference these pillars to demonstrate mature thinking about trade-offs.

EC2 and Compute Questions

EC2 (Elastic Compute Cloud) provides configurable virtual servers. It is one compute option among containers, functions and managed application/data services.

How do EC2 instance types work and how do you choose the right one?

EC2 instance types are named by family, generation, and size (e.g., m5.xlarge). The family letter indicates the use case, the number indicates generation, and the size determines CPU and memory allocation.

Choosing the right instance type requires matching your workload characteristics to the instance family's strengths. Running a memory-intensive workload on a compute-optimized instance wastes money and underperforms.

When would you use a T instance versus an M instance?

T instances are burstable: CPU below baseline earns credits and bursts spend them. They can fit workloads with a low average and occasional CPU peaks, but the credit mode and cost must be observed.

M families do not use the T credit model and often fit balanced sustained workloads. In T standard mode, exhausting credits returns performance to baseline; T3/T3a/T4g normally launch in unlimited mode and can sustain CPU above baseline while incurring surplus-credit charges. Benchmark representative load instead of mapping “production” automatically to M.

What are the EC2 pricing models and when do you use each?

Understanding EC2 pricing directly impacts cloud costs. Many organizations overspend by using On-Demand for everything when Reserved or Spot instances would work better.

How would you reduce costs for a batch processing job that can tolerate interruptions?

Spot Instances can materially reduce compute cost for interruption-tolerant batch work. AWS interruption notices are best effort; stop/terminate normally has a two-minute warning, while hibernation begins immediately.

Checkpoint to durable storage, make work idempotent and test interruption with Fault Injection Service. Diversify eligible instance types and AZs through an Auto Scaling group, EC2 Fleet or Spot Fleet, use a capacity-optimized allocation strategy where appropriate, and define an On-Demand fallback from actual completion objectives.

Lambda and Serverless Questions

Lambda runs code without provisioning servers and is central to serverless architectures on AWS.

What is AWS Lambda and what are its key characteristics?

Lambda runs code in service-managed execution environments. AWS operates the underlying fleet and runtime patch modes, while you still own application code, dependencies, IAM, event semantics, quotas, concurrency, observability, deployment and downstream capacity.

Key characteristics define when Lambda is appropriate:

• Event-driven: Triggered by events from API Gateway, S3, SQS, DynamoDB, and dozens of other sources
• Metered execution: Request, duration and other charges depend on architecture and enabled features
• Managed scaling: Scales under regional/function concurrency, event-source and downstream limits
• Execution model: Standard function invocations run for at most 15 minutes; Durable Functions coordinate checkpointed steps and waits under a different long-running model

What are Lambda cold starts and how do you reduce them?

A cold start is the initialization work needed for a new execution environment before its handler runs. It can occur during scale-out or service lifecycle changes; AWS does not promise how long an on-demand environment remains reusable. Its impact depends on runtime, package/image, initialization, extensions, VPC/network dependencies, memory and traffic, so measure the latency distribution for the deployed configuration.

flowchart LR
    subgraph cold["Cold Start"]
        C1["Request"] --> C2["Initialize Runtime"] --> C3["Load Code"] --> C4["Run Handler"] --> C5["Response"]
    end
    subgraph warm["Warm Start"]
        W1["Request"] --> W2["Run Handler"] --> W3["Response"]
    end

Strategies to reduce cold starts:

• Provisioned Concurrency: Keep a specified number of instances warm and ready
• Optimize static initialization: Load only required dependencies and initialize reusable clients outside the handler
• SnapStart where supported: Restore a prepared snapshot while respecting its uniqueness and feature constraints
• Measure first: Separate platform initialization, application initialization and downstream latency

When should you use Lambda versus EC2?

This decision depends on workload characteristics, cost considerations, and operational preferences. Neither is universally better—they serve different needs.

flowchart TD
    Q1{"Need host, OS or<br/>special hardware control?"}
    Q1 -->|Yes| A1["Evaluate EC2"]
    Q1 -->|No| Q2{"Does the Lambda execution,<br/>event and quota model fit?"}
    Q2 -->|No| A2["Evaluate EC2 or containers"]
    Q2 -->|Yes| Q3{"Measured cost, latency and<br/>operations meet objectives?"}
    Q3 -->|No| A3["Compare alternatives"]
    Q3 -->|Yes| A4["Lambda is a candidate"]

When would Lambda be more expensive than EC2?

Lambda may cost more when sustained execution, memory allocation, request volume, provisioned concurrency, logging or data transfer outweigh avoided operations. EC2 may cost more when instances are underused or require more platform work. Compare the same availability, throughput and latency objective with Savings Plans/Spot where eligible, network/NAT costs, observability and engineering operations. Recalculate from actual billing and profiles; constant traffic is evidence to model, not a proof of the winner.

S3 Storage Questions

S3 (Simple Storage Service) is object storage with regional general-purpose buckets and zonal directory buckets for S3 Express One Zone.

What is S3 and what are its core concepts?

General-purpose S3 buckets store objects up to 5 TB. Their names are unique within an AWS partition. The apparent folders are key prefixes rather than directories; directory buckets are a distinct zonal bucket type with different semantics.

S3 is designed for large scale and most storage classes are designed for 11 nines of durability, but One Zone-IA and Express One Zone deliberately store within one AZ. Durability, availability, versioning, deletion protection, backup and cross-Region disaster recovery are separate concerns.

Key concepts:

• Buckets: General-purpose regional or directory/zonal containers with partition-scoped naming rules
• Objects: Files plus metadata, identified by keys
• Keys: The full path to an object within a bucket

What are S3 storage classes and when should you use each?

Choose from measured access frequency, latency, AZ resilience, retention, object size and the full price model. Lower storage price can add monitoring, request, retrieval, early-deletion and restore charges.

How do S3 lifecycle policies work?

Lifecycle rules can transition or expire objects, noncurrent versions and incomplete multipart uploads. Transitions are asynchronous and constrained by supported paths, object size and minimum storage-duration billing. Validate restore requirements, Object Lock/retention, replication and versioned delete-marker behavior before treating lifecycle as guaranteed savings.

{
  "Rules": [{
    "Status": "Enabled",
    "Transitions": [
      {"Days": 30, "StorageClass": "STANDARD_IA"},
      {"Days": 90, "StorageClass": "GLACIER"}
    ],
    "Expiration": {"Days": 365}
  }]
}

This policy transitions objects to Standard-IA after 30 days, Glacier after 90 days, and deletes them after one year.

How would you ensure no S3 bucket in your account is ever publicly accessible?

Enable all four S3 Block Public Access settings at the organization/account and bucket/access-point scopes you govern, then prevent weakening them with Organizations controls. These settings reject access patterns AWS classifies as public; they do not detect every unintended private principal, leaked credential, overly broad VPC endpoint policy or application-level disclosure.

Continuously inventory policies and ACLs with IAM Access Analyzer and AWS Config, alert on changes, minimize resource policies, disable ACLs with Bucket owner enforced where appropriate, and test preventive controls. Public access needed for a website should normally be mediated deliberately, for example through CloudFront origin access control, rather than weakening an account-wide invariant.

What are the different S3 encryption options?

S3 encrypts new uploads at rest with SSE-S3 by default. The choice is about key ownership, audit and policy controls, request rate/cost, cross-account use and who must hold plaintext.

• SSE-S3: AWS manages encryption keys entirely—simplest option
• SSE-KMS: Uses an AWS KMS key, including a customer-managed key when you need policy and lifecycle control
• DSSE-KMS: Applies two independent server-side encryption layers with KMS integration
• SSE-C: You provide encryption keys with each request—AWS never stores them
• Client-side: Encrypt data before uploading—AWS never sees unencrypted data

Encryption does not replace access control, TLS, data classification, deletion/retention controls or secret prevention. SSE-C and client-side encryption add key-loss and operational risks that must be designed explicitly.

EBS and Block Storage Questions

EBS (Elastic Block Store) provides block storage volumes that attach to EC2 instances.

What is EBS and how does it differ from S3?

EBS provides block storage volumes that function like hard drives attached to EC2 instances. Unlike S3's object storage, EBS supports file systems and databases that require block-level operations.

Key differences from S3:

What EBS volume types are available and when do you use each?

EBS offers SSD and HDD volume types optimized for different performance characteristics. Choosing the wrong type either wastes money (over-provisioning) or causes performance problems (under-provisioning).

Which EBS volume type would you use for a database needing consistent high IOPS?

Start with the measured I/O size, IOPS, throughput, latency distribution, durability target, queue depth and instance EBS limits. gp3 now reaches much higher configurable performance than its old 16,000-IOPS ceiling and may fit; io2 Block Express is the candidate when its higher provisioned performance, durability and latency characteristics are required. Benchmark the database path because filesystem, engine, instance and volume limits combine.

How do EBS snapshots work?

EBS snapshots are point-in-time backups stored in S3 (managed by AWS, not visible in your buckets). Snapshots are incremental—only blocks changed since the last snapshot are stored—making them space and cost efficient.

Snapshots are regional but can be copied cross-region for disaster recovery. You can create new volumes from snapshots in any AZ within the region, enabling data migration between AZs.

VPC Networking Questions

A VPC is a regional network boundary for resources such as EC2 and RDS. A normal Lambda function runs in a Lambda-managed VPC; attaching it to customer VPC subnets adds connectivity to private resources and changes its network path.

What is a VPC and what are its core components?

A VPC is your isolated network in AWS where you define IP ranges, create subnets, configure routing, and control security. Think of it as your own data center network in the cloud, but with AWS managing the physical infrastructure.

Core components work together to create network topology:

• VPC: The overall network boundary with a CIDR block (e.g., 10.0.0.0/16)
• Subnet: A segment within a VPC, existing in a single AZ
• Route Table: Rules determining where network traffic goes
• Internet Gateway (IGW): Enables communication with the internet
• NAT Gateway: Provides address translation for outbound flows; it is not a general inbound path or firewall

flowchart TB
    subgraph vpc["VPC (10.0.0.0/16)"]
        subgraph aza["AZ-a"]
            pub1["Public Subnet<br/>10.0.1.0/24"]
            priv1["Private Subnet<br/>10.0.3.0/24"]
            nat1["NAT Gateway AZ-a"]
        end
        subgraph azb["AZ-b"]
            pub2["Public Subnet<br/>10.0.2.0/24"]
            priv2["Private Subnet<br/>10.0.4.0/24"]
            nat2["NAT Gateway AZ-b"]
        end
        igw["Internet Gateway"]
    end
 
    pub1 -->|"0.0.0.0/0"| igw
    pub2 -->|"0.0.0.0/0"| igw
    priv1 -->|"0.0.0.0/0"| nat1
    priv2 -->|"0.0.0.0/0"| nat2
    nat1 --> igw
    nat2 --> igw

What is the difference between public and private subnets?

The distinction between public and private subnets determines what can be reached from the internet and forms the basis of network security architecture.

A subnet is conventionally called public when its route table has a route to an internet gateway. An instance also needs a public IPv4/Elastic IP or IPv6 address plus permissive security controls to communicate directly; a route alone does not make every resource reachable.

Why should you put your database in a private subnet?

Database subnet groups normally use subnets without a direct internet-gateway route, and public accessibility is disabled. That removes a direct path but does not make the database safe after a security-group mistake: compromised application identities, peering/TGW/VPN routes, trusted networks and control-plane changes remain paths. Restrict database security groups to the exact application security group/ports, encrypt, patch, audit, manage credentials and test restore. A public “bastion first” is not a required architecture; managed access paths can avoid inbound administration entirely.

What is the difference between Security Groups and NACLs?

Security Groups and Network ACLs (NACLs) both control traffic but operate at different levels and with different behaviors. Understanding both is essential for troubleshooting connectivity issues.

Stateful vs Stateless is the key difference: Security Groups automatically allow return traffic for allowed connections. NACLs require explicit rules for both directions.

Traffic is blocked even though the Security Group allows it. What could cause this?

When traffic is blocked despite correct Security Group rules, investigate these possibilities in order:

1. NACL blocking: Stateless subnet rules might reject either direction
2. Route table issues: Traffic might not be routed correctly to reach the destination
3. Ephemeral ports: NACL return rules must match the actual client OS/service port range
4. Source IP: NAT changes source IP—the Security Group might expect a different source
5. Missing IGW/NAT: Infrastructure might not exist or be attached

What are the options for connecting VPCs together?

AWS provides several connectivity options depending on scale, latency, and security requirements.

IAM Security Questions

IAM (Identity and Access Management) controls who can do what in your AWS account. Security questions appear in every AWS interview.

What are the core IAM concepts?

IAM provides authentication (who you are) and authorization (what you can do) for AWS. Understanding these concepts is fundamental to AWS security.

• Users: Account identities that can have long-term credentials; prefer federation/Identity Center for workforce access
• Groups: Collections of IAM users for shared identity policies
• Roles: Identities assumed by services, applications, or users—provide temporary credentials
• Policies: JSON documents defining permissions, attached to users, groups, or roles

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject"
    ],
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

What are the different IAM policy types?

IAM policies come in several types that work together to determine effective permissions. Understanding policy types helps troubleshoot access issues and design proper security boundaries.

Effective authorization is not a simple union. Explicit denies override allows, and the applicable identity policy, resource policy, permissions boundary, SCP/RCP and session policy interact differently by principal and request context. Use policy simulation and CloudTrail evidence, not the table alone, to debug a decision.

What is the principle of least privilege and why does it matter?

Least privilege means granting only the permissions needed to perform a task—no more. This fundamental security principle limits the blast radius when credentials are compromised or mistakes are made.

Bad practice:

{"Action": "*", "Resource": "*"}

Narrower starting point (still requires conditions and full access-path review):

{"Action": "s3:GetObject", "Resource": "arn:aws:s3:::specific-bucket/*"}

Always mention least privilege when discussing IAM in interviews—it demonstrates security awareness.

How should an EC2 instance access S3 or other AWS services?

Use a least-privilege role through an instance profile instead of distributing long-term access keys. Supported SDK credential providers retrieve rotating temporary credentials from the Instance Metadata Service. Require IMDSv2, restrict metadata access where containers or untrusted processes share a host, and remember that server-side request forgery or code execution can still use the role within its permissions.

# No credentials needed - uses instance role
import boto3
s3 = boto3.client('s3')
s3.list_buckets()

Storing access keys on instances creates security risks: they don't rotate automatically, can be accidentally committed to version control, and persist if the instance is compromised.

How does cross-account IAM role assumption work?

Cross-account access enables resources in one AWS account to access resources in another without sharing long-term credentials. This pattern is common in multi-account architectures.

The process works as follows. The ExternalId condition in this example is appropriate when a third-party provider issues and uses it to address confused-deputy risk; first-party access should use conditions suited to its own trust model.

1. Account B creates a role with a trust policy allowing Account A to assume it
2. Account A calls sts:AssumeRole to get temporary credentials
3. Account A uses those credentials to access Account B's resources

// Trust policy in Account B's role
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::ACCOUNT_A_ID:role/SpecificCallerRole"},
    "Action": "sts:AssumeRole",
    "Condition": {"StringEquals": {"sts:ExternalId": "provider-issued-value"}}
  }]
}

RDS Database Questions

RDS (Relational Database Service) manages relational databases including MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Aurora.

What does RDS manage for you versus what you still manage?

RDS automates parts of database infrastructure operation, but responsibility depends on engine, deployment mode and features you configure.

RDS manages:

• Provisioning and patching
• Backup mechanisms and point-in-time recovery when configured and retained correctly
• Multi-AZ failover and read replicas when you select supported deployments
• Service metrics and monitoring integrations

You still manage:

• Schema design and optimization
• Query performance tuning
• Capacity, parameters, upgrades, maintenance windows, security, recovery objectives and application-level correctness

What is the difference between RDS Multi-AZ and Read Replicas?

Multi-AZ and Read Replicas serve different purposes and can be used together. Confusing them is a common interview mistake.

Do not answer “Multi-AZ has no readable standby” without naming the deployment: it is true for the traditional Multi-AZ DB instance, false for the newer Multi-AZ DB cluster. Application retry, DNS/endpoint behavior, connection recovery and capacity still determine experienced downtime.

Your database needs both high availability and read scaling. What do you configure?

Choose either a supported Multi-AZ DB cluster with readable instances or a Multi-AZ DB instance plus separate read replicas, depending on engine, Region, workload and cost. Route read-only traffic intentionally, define consistency tolerance and monitor lag. Test failover and connection recovery. “Enable both” is not universally available or beneficial, and neither configuration guarantees that the whole application survives an AZ event.

When would you choose Aurora over standard RDS MySQL?

Aurora is a managed relational engine compatible with selected MySQL/PostgreSQL versions but with a distributed storage and replication architecture. Evaluate it when its failover, reader, global, serverless, I/O and operational model matches the workload—not as an automatic “enterprise” tier.

Aurora advantages:

• Distributed storage across three AZs
• Up to 15 Aurora Replicas in a Region
• Managed cluster endpoints and failover tiers
• Aurora Serverless for variable workloads

Compare engine/version compatibility, extensions, migration and rollback, instance and I/O pricing, failover behavior, replica lag, operational tooling and team skill. Aurora is not always more expensive or faster; benchmark the real query and failure workload.

DynamoDB Questions

DynamoDB is a managed key-value and document database designed for predictable low-latency access when keys, capacity and item design distribute work effectively.

What is DynamoDB and what are its key characteristics?

DynamoDB removes database-server provisioning, but clients still own keys and access patterns, item size, hot-key avoidance, capacity mode/autoscaling, indexes, consistency, retries, throttling, transactions, backups and cost. Data size alone is not the promise; a skewed partition key or inefficient scan can still perform badly.

Key characteristics:

• Low-latency key access under the service's workload design assumptions
• On-demand or provisioned capacity with quotas and throttling behavior
• Built-in replication across AZs
• No servers to manage

flowchart TB
    subgraph table["Table: Orders"]
        pk["Partition Key: customer_id"]
        sk["Sort Key: order_date"]
        subgraph items["Items"]
            i1["{customer_id: 123,<br/>order_date: 2026-01-07,<br/>total: 99.99, ...}"]
            i2["{customer_id: 123,<br/>order_date: 2026-01-06,<br/>items: [...], ...}"]
        end
    end

How do DynamoDB partition keys and sort keys work?

The primary key design determines how DynamoDB stores and retrieves data. Good key design enables efficient queries; poor design creates hot partitions and limits query flexibility.

Partition Key: Determines which partition stores the item. DynamoDB hashes this key to distribute data across partitions. Must be unique (if no sort key) or unique in combination with sort key.

Sort Key: Orders items within a partition, enabling range queries. Items with the same partition key are stored together, sorted by sort key.

What are DynamoDB indexes and when do you use them?

Indexes enable queries on attributes other than the primary key. Without indexes, you can only query by partition key (and optionally sort key).

GSI (Global Secondary Index): Uses a new partition key and optional sort key. Reads are eventually consistent, projection and capacity/cost matter, and propagation can lag.

LSI (Local Secondary Index): Same partition key as the table, different sort key. Supports strongly consistent reads. Must be created at table creation time.

How would you design a DynamoDB table to query orders by customer and by status?

Design the primary key for the most common access pattern, then add indexes for secondary patterns.

Primary key: Partition key = customer_id, sort key = order_date. This efficiently supports "get all orders for customer X, sorted by date."

GSI: A bare partition key of order_status can become hot because a few values receive all traffic. Prefer a design derived from volume and query shape, such as status plus time bucket or shard as the GSI partition key and creation time/order ID as its sort key, then query/merge the required buckets.

This design enables both access patterns with single queries rather than table scans.

When should you choose DynamoDB versus RDS?

The choice depends on data model, query patterns, and scale requirements. Neither is universally better.

Architecture and Troubleshooting Questions

These questions test your ability to apply AWS knowledge to real scenarios.

How would you design a highly available web application on AWS?

A highly available design targets explicit SLO, RTO and RPO values and reduces known failure domains; it cannot promise “no downtime.” Start with traffic, state, consistency and regional-disaster requirements, then test failures.

Architecture components:

• Independently scaled capacity across enough AZs for the availability target
• Application Load Balancer distributing traffic
• Auto Scaling Group for EC2 instances
• RDS Multi-AZ for database
• S3 for static assets, CloudFront for CDN
• Private subnets for app/database, public for ALB
• Security Groups limiting access between tiers

How would you reduce costs for a development environment?

Development environments don't need production-level availability, creating cost optimization opportunities. Balance cost savings against developer productivity.

Cost reduction strategies:

• Right-size or scale development compute from measured demand; stop idle resources
• Schedule instances to stop outside business hours (Lambda + EventBridge)
• Use Spot Instances for non-critical workloads
• Single-AZ RDS (availability less critical in dev)
• Delete unused EBS volumes and snapshots
• Review and right-size based on CloudWatch metrics

How would you design a system to process files uploaded to S3?

S3 event notifications can feed Lambda, SQS, SNS or EventBridge. Delivery can be duplicate and out of order, so processing needs an idempotency key/version strategy and a durable record of state. Avoid notification loops when outputs share a bucket/prefix.

Design:

1. S3 bucket with event notification on object creation
2. Notification goes through SQS/EventBridge when buffering, retry control or fan-out is needed
3. Lambda or container/EC2 workers are selected by runtime, memory, I/O, dependency and quota needs—not file size alone
4. Results stored in S3 or database
5. Dead-letter queue for failed processing
6. CloudWatch alarms for monitoring failures

An EC2 instance can't reach the internet. What do you check?

Systematic troubleshooting starts with identifying where traffic is blocked. Work through the network path from instance to internet.

Troubleshooting steps:

1. Is it in a public or private subnet?
2. Public subnet: Does it have a public IP? Is there a route to IGW?
3. Private subnet: Is there a NAT Gateway? Route to NAT?
4. Security Group: Outbound rules allow the traffic?
5. NACL: Allow outbound and inbound for return traffic?
6. Is the IGW/NAT Gateway actually created and attached?

A Lambda function times out when accessing RDS. Why?

Lambda timeout issues with RDS typically stem from networking configuration or connection management problems.

Common causes:

1. Lambda must be attached to customer-VPC subnets with a route to the RDS endpoint; NAT is irrelevant to a private RDS path and is needed only for destinations reached through it
2. RDS security group must allow the database port from the Lambda security group, with NACL/DNS/routes also working
3. Check DNS, TLS, credentials, database load, locks and connection/query timeouts before blaming Lambda timeout
4. Initialization plus DNS/TLS/connection setup can consume the timeout budget; measure each phase
5. Execution environments can reuse connections initialized outside the handler, but burst concurrency can exhaust the database; bound concurrency and consider RDS Proxy where supported

S3 bucket policy allows access but requests are denied. Why?

When explicit allow policies don't grant access, something else is denying. Work through all policy types that could contain denials.

Check these in order:

1. S3 Block Public Access enabled at bucket or account level?
2. IAM policy on the user/role explicitly denying?
3. Permission boundary restricting access?
4. SCP/RCP or session policy limiting the principal?
5. VPC endpoint policy restricting access?
6. Bucket/access-point policy condition, object ownership or ACL mismatch?
7. KMS key policy/grant denying an SSE-KMS operation?

Quick Reference

Frequently Asked Questions

What is the difference between a Region and an Availability Zone in AWS?

An AWS Region is a separate geographic area that contains multiple isolated Availability Zones. An AZ consists of one or more discrete data centers with independent power, cooling and physical security, connected to other AZs in the Region through redundant low-latency networking. Multi-AZ design can tolerate an AZ failure only when every dependency, routing path, capacity plan and recovery mechanism is also designed and tested for it.

When should you use EC2 vs Lambda?

Use Lambda when its event model, runtime, standard-invocation limit or Durable Functions model, concurrency behavior and quotas fit the workload and reduced infrastructure operation is valuable. Use EC2 when you need host or OS control, unsupported runtimes, long-lived processes, specialized hardware or a different scaling and cost model. Measure end-to-end latency, steady and burst cost, startup, state, networking, observability and team operations; constant traffic alone does not decide the answer.

What is the difference between Security Groups and NACLs?

Security groups are stateful allow-only controls associated with supported resources and network interfaces; response traffic for an allowed flow is tracked. Network ACLs are stateless ordered allow/deny rules evaluated at subnet boundaries, so both directions and ephemeral ports matter. They are complementary layers, but neither replaces routing, identity policy, endpoint policy, application authorization or inspection.

What are S3 storage classes and when should you use each?

Choose S3 Standard for frequent multi-AZ access; Intelligent-Tiering for unknown or changing access; Standard-IA for long-lived infrequent multi-AZ data; One Zone-IA for recreatable single-AZ data; Express One Zone for latency-sensitive single-AZ access; and Glacier Instant, Flexible or Deep Archive by retrieval and retention needs. Compare availability, AZ resilience, retrieval time and fees, minimum duration, minimum billable size, monitoring and request costs before automating lifecycle transitions.

What is the difference between RDS Multi-AZ and Read Replicas?

A traditional RDS Multi-AZ DB instance deployment keeps a synchronous standby for failover and does not serve reads from that standby. A Multi-AZ DB cluster instead has one writer and two readable instances across three AZs using semisynchronous native replication. Read replicas are separate engine-specific replicas primarily for read scaling and can have lag or require promotion. Select the deployment type by supported engine, RTO/RPO, read/write behavior, endpoints, failover testing and cost.

How does IAM role assumption work for cross-account access?

The target account creates a role whose trust policy permits a specific external principal to call STS AssumeRole, while the caller also needs identity-based permission unless its account delegates directly through the trust policy. The resulting temporary session is limited by the role policy plus applicable session policies, permissions boundaries, SCPs, resource policies and explicit denies. Scope the principal and conditions, use ExternalId for relevant third-party confused-deputy risk, protect the source identity and audit CloudTrail.

Sources

• AWS Regions and Availability Zones
• AWS Well-Architected Framework pillars
• EC2 burstable performance Unlimited mode
• EC2 Spot interruption notices
• AWS Lambda quotas
• AWS Lambda execution environment lifecycle
• Amazon S3 storage classes
• Amazon S3 default encryption
• Amazon S3 Block Public Access
• Amazon EBS volume types
• Security groups and network ACLs
• AWS IAM policy evaluation logic
• Cross-account IAM roles
• Amazon RDS Multi-AZ DB clusters
• DynamoDB read consistency
• Amazon S3 event notification ordering and duplication

Related Articles

• Complete DevOps Engineer Interview Guide - Full DevOps interview preparation
• Docker Interview Guide - Container fundamentals
• Kubernetes Interview Guide - Container orchestration on EKS
• Linux Commands Interview Guide - Essential Linux skills
• Monitoring & Observability Interview Guide - CloudWatch and beyond