Top 50 AWS Interview Questions (2026)

AWS (Amazon Web Services) is a cloud platform that rents computing resources on demand: virtual servers, storage, databases, and hundreds of managed services, billed by usage instead of bought up front. You launch what you need through an API, the CLI, or the console, and turn it off when you're done.

Companies use it to skip buying and running hardware, to scale up or down with demand, and to reach global regions quickly. Instead of a six-week server order, you get an instance in minutes and pay only for what you run, which shifts big capital spending into flexible operating cost.

A Region is a separate geographic area (like us-east-1 or ap-south-1) with its own set of data centers. An Availability Zone (AZ) is one or more discrete data centers within a Region, with independent power, cooling, and networking, connected to the other AZs by fast, low-latency links.

The point is fault isolation: you spread instances across multiple AZs so that if one zone fails, your app keeps running in the others. Regions matter for latency to users, data residency, and which services are available, since not every service launches in every Region at once.

EC2 (Elastic Compute Cloud) gives you resizable virtual servers, called instances, that you launch in minutes and pay for by the second or hour. You pick an instance type (CPU, memory, network), an Amazon Machine Image for the operating system, and a size, then you manage the server like any other machine.

It's the default compute service when you need full control: install what you want, run long-lived processes, tune the OS. The trade-off is you own the operational work, patching, scaling, and the cost of instances that sit idle.

Instance families group instances by what they're tuned for. General purpose (T and M) balance CPU and memory for typical web apps. Compute optimized (C) favor CPU for heavy processing. Memory optimized (R and X) suit databases and caches. Storage optimized (I and D) give fast local disk, and accelerated (P and G) add GPUs.

You pick by the workload's bottleneck: profile whether it's CPU-bound, memory-bound, or I/O-bound, then choose the matching family and the smallest size that meets the need. Starting small and scaling up beats guessing large and overpaying.

S3 (Simple Storage Service) is object storage: you store files (objects) in containers called buckets, each object addressed by a key, and reach them over HTTP. It's built for near-unlimited capacity and is designed for 11 nines of durability, so data loss is extremely unlikely.

It's good for static assets, backups, data lakes, logs, and hosting static websites. It's not a filesystem or a block device, you don't mount it like a disk, and it's not a database. When you need a mountable volume for an instance, that's EBS, not S3.

The three are different storage types. S3 is object storage reached over HTTP, great for files, backups, and assets. EBS (Elastic Block Store) is block storage: a virtual disk you attach to a single EC2 instance, like a hard drive for the operating system and databases. EFS (Elastic File System) is a shared filesystem you can mount on many instances at once.

You pick by access pattern. Need durable object access from anywhere, use S3. Need a disk for one instance, use EBS. Need many instances sharing files, use EFS. Mixing these up is one of the most common storage mistakes in an interview.

A bucket is a top-level container for your data, with a globally unique name. An object is a single stored item: the file's bytes plus metadata. A key is the object's full name within the bucket, which acts like a path even though S3 has no real folders.

So s3://my-bucket/images/logo.png means bucket my-bucket, key images/logo.png. The slashes are just part of the key; the console shows them as folders for convenience, but the storage is flat. Knowing that keys are flat, not a real directory tree, explains why prefixes matter for listing and performance.

IAM (Identity and Access Management) controls who can do what in your account. It manages identities (users, groups, roles) and policies (JSON documents that allow or deny specific actions on specific resources). Every API call is checked against these policies before it runs.

The habit that matters is least privilege: grant only the permissions an identity actually needs, nothing more. IAM is the front door to your account's security, so a sloppy policy that grants too much is one of the most common and dangerous real-world mistakes.

A user is a permanent identity for a person or an application, with its own long-lived credentials. A group is a collection of users so you attach permissions once and every member inherits them, which keeps permissions manageable. A role is an identity with no permanent credentials that gets assumed to receive temporary ones.

Roles are the modern preference for anything non-human: an EC2 instance or Lambda function assumes a role instead of holding access keys, and cross-account access works by assuming a role too. Temporary credentials that expire beat long-lived keys sitting in code.

An IAM policy is a JSON document listing statements, each with an Effect (Allow or Deny), one or more Actions (like s3:GetObject), and Resources the actions apply to, optionally narrowed by Conditions. AWS evaluates all applicable policies for a request and decides whether it's permitted.

The evaluation rule to know: an explicit Deny always wins over any Allow, and if nothing explicitly allows an action, it's denied by default. So access is deny-by-default, opened by Allow statements, and an explicit Deny is the override you use to guarantee something never happens.

A VPC (Virtual Private Cloud) is your own isolated virtual network inside AWS. You define its IP address range, carve it into subnets, and control routing and traffic, so your resources run in a private network you shape rather than on the open internet.

Inside a VPC you place subnets across Availability Zones, attach an internet gateway for public access, and use route tables, security groups, and network ACLs to decide what can talk to what. It's the networking foundation almost every other service sits inside.

The difference is routing, not a checkbox. A subnet is public when its route table sends internet-bound traffic (0.0.0.0/0) to an internet gateway, so resources there can be reached from and reach the internet. A private subnet has no such route, so it's isolated from direct internet access.

The common pattern puts web-facing servers or load balancers in public subnets and databases and application servers in private ones. Private resources that need outbound internet (for updates) reach it through a NAT gateway in a public subnet, which allows outbound traffic without exposing them to inbound connections.

Both filter traffic, but at different levels and with different behavior. A security group acts as a firewall at the instance (elastic network interface) level and is stateful: if you allow inbound traffic, the return traffic is allowed automatically. Security groups only have allow rules.

A network ACL acts at the subnet level and is stateless: you must allow both the inbound and the matching outbound traffic yourself, and it supports both allow and deny rules. In practice, security groups do most of the work; network ACLs are a coarser second layer at the subnet edge.

Lambda is a serverless compute service: you upload a function, and AWS runs it in response to events (an S3 upload, an API Gateway request, a schedule, a queue message) without you provisioning or managing any servers. It scales automatically from zero to many concurrent runs.

You pay per request and per millisecond of execution, so idle costs nothing. The trade-offs are real: a 15-minute maximum runtime, cold starts when a function hasn't run recently, and a stateless model where you keep no local state between invocations. It fits event-driven and spiky work, not long-running processes.

Choose Lambda for event-driven, short, spiky, or unpredictable workloads: a function triggered by an upload, an API endpoint with bursty traffic, a scheduled job. It scales to zero, so you pay nothing when idle, and there's no server to manage.

Choose EC2 (or containers) for steady, long-running, or stateful workloads, anything needing more than 15 minutes, heavy or predictable traffic where reserved capacity is cheaper, or full control over the runtime. The honest framing is: Lambda for bursty event work, EC2 for sustained control, and containers when you want portability in between.

It splits security between AWS and you. AWS is responsible for security of the cloud: the physical hardware, the hypervisor, the global infrastructure, and the managed-service internals. You are responsible for security in the cloud: your data, your IAM permissions, your network configuration, and, for services like EC2, the guest OS and application.

The line shifts by service. For EC2 you patch the operating system; for a managed service like Lambda or DynamoDB, AWS handles more of the stack and you mainly own data and access control. Knowing where the line sits for each service is the point of the question.

On-Demand charges by the second or hour with no commitment, best for short-term or unpredictable use. Reserved Instances and Savings Plans give a large discount in exchange for a one or three year commitment, best for steady baseline load. Spot Instances offer the deepest discount using spare capacity, but AWS can reclaim them with short notice.

The practical mix: reserved or savings plans for the always-on baseline, on-demand for variable load on top, and spot for fault-tolerant or batch work that can survive interruption. Matching the pricing model to the workload's tolerance for interruption is where real cost savings come from.

CloudWatch is AWS's monitoring and observability service. It collects metrics (CPU, memory with the agent, request counts), stores logs, and lets you set alarms that fire when a metric crosses a threshold, which can trigger notifications or actions like scaling.

You use it to watch health, alert on problems, and drive Auto Scaling decisions. CloudWatch Logs centralizes application and system logs, and CloudWatch Alarms plus dashboards give you the at-a-glance and the wake-me-up layers. It's the default answer when an interviewer asks how you'd monitor an AWS system.

An Elastic Load Balancer (ELB) spreads incoming traffic across multiple targets (instances, containers, IPs) and routes only to healthy ones via health checks, which is how you get high availability across Availability Zones. The main types are the Application Load Balancer for HTTP and HTTPS with content-based routing, and the Network Load Balancer for TCP and UDP at very high performance.

You'd reach for an ALB for web apps that need path or host based routing (send /api to one target group, /app to another), and an NLB when you need raw throughput, static IPs, or non-HTTP protocols. The Gateway Load Balancer exists for inserting network appliances, but ALB and NLB cover most interview cases.

RDS is managed relational databases: it runs engines like PostgreSQL, MySQL, and SQL Server, so you get SQL, joins, and strong consistency, and AWS handles backups, patching, and failover. DynamoDB is a managed NoSQL key-value and document store built for single-digit-millisecond latency at any scale, with no servers to size.

You pick RDS when your data is relational and you need SQL and complex queries, and DynamoDB when you need predictable low latency at huge scale with simple access patterns you can design around a key. The tell of experience is knowing DynamoDB rewards designing your table around access patterns, not normalizing like a relational schema.

Multi-AZ is for availability. RDS keeps a synchronous standby copy in another Availability Zone, and if the primary fails, it automatically fails over to the standby. The standby isn't used for reads; it exists purely so a failure doesn't cause an outage.

A read replica is for scaling reads. It's an asynchronous copy you can send read queries to, offloading the primary. Replicas can lag slightly behind and don't provide automatic failover for writes. So Multi-AZ solves availability, read replicas solve read load; teams often use both together.

S3 storage classes trade retrieval speed and access frequency against storage cost. Standard is cheapest to access but priciest to store, for frequently used data. Standard-Infrequent Access lowers storage cost with a per-retrieval fee for data you touch rarely. Glacier and Glacier Deep Archive are cheapest to store but take minutes to hours to retrieve, for archives.

Intelligent-Tiering moves objects between tiers automatically based on access, which is the safe default when access patterns are unknown. You choose by how often you'll read the data and how fast you need it back, and you automate the transitions with lifecycle rules rather than moving objects by hand.

An Auto Scaling group maintains a desired number of instances between a minimum and maximum, launching from a launch template and replacing any that fail health checks. Scaling policies change that desired count: target tracking keeps a metric (like average CPU at 60%) steady, step scaling adds capacity in jumps as a metric climbs, and scheduled scaling handles known traffic patterns.

The triggers are usually CloudWatch metrics: CPU utilization, request count per target, or a custom metric. Paired with a load balancer, new instances register automatically and start taking traffic once healthy. The design goal is matching capacity to demand so you neither drop requests nor pay for idle servers.

Vertical scaling means making one instance bigger: more CPU and memory by changing the instance type. It's simple but has a ceiling (the largest instance size) and usually needs a restart, and a single big instance is still a single point of failure.

Horizontal scaling means adding more instances behind a load balancer. It has no hard ceiling, tolerates the loss of any one instance, and is what Auto Scaling automates, but it requires the app to be stateless so any instance can serve any request. AWS architecture favors horizontal scaling for exactly these reasons.

Stateless means an instance keeps no session or user data locally between requests, so any instance can handle any request. That's what lets a load balancer spread traffic freely and Auto Scaling add or remove instances without losing anyone's session.

You push state out of the instances into shared stores: sessions into DynamoDB or ElastiCache, files into S3, data into RDS. If state lived on the instance, terminating one during a scale-in would drop user sessions, and requests would break when routed to a different instance. Statelessness is what makes instances disposable.

access: keep buckets private by default (Block Public Access on), grant access through IAM policies and bucket policies scoped tightly, and use presigned URLs for temporary, limited sharing rather than making objects public comes first. Most S3 data breaches trace back to a bucket accidentally left open.

Then add durability and confidentiality: enable versioning so overwrites and deletes are recoverable, turn on server-side encryption (SSE-S3 or SSE-KMS) so objects are encrypted at rest, and use lifecycle rules and MFA delete for retention. Encryption in transit comes from requiring HTTPS.

CloudFront is AWS's content delivery network. It caches content at edge locations close to users, so a request is served from a nearby edge instead of traveling all the way to your origin (an S3 bucket, a load balancer, or any HTTP server). That cuts latency and offloads traffic from the origin.

You use it to speed up static assets and cacheable responses globally, to add TLS and DDoS protection at the edge with AWS Shield, and to serve a static website fronting an S3 bucket. The hard part, as with any cache, is invalidation: deciding TTLs and purging the edge when content changes.

SQS (Simple Queue Service) is a message queue: producers put messages in, and one consumer pulls and processes each message, decoupling components and absorbing bursts. It's point-to-point, and messages wait until something processes them, which smooths spikes and adds resilience.

SNS (Simple Notification Service) is publish-subscribe: a message published to a topic fans out to many subscribers at once (queues, Lambda functions, HTTP endpoints, email). A common pattern is fan-out: SNS publishes to a topic, and several SQS queues subscribe, so multiple services each get their own copy to process independently.

A NAT (Network Address Translation) gateway lets resources in a private subnet reach the internet for outbound traffic (downloading updates, calling external APIs) without being reachable from the internet inbound. It lives in a public subnet and translates the private instances' addresses to its own public IP.

Private subnets have no route to the internet gateway by design, so without a NAT gateway their instances can't fetch anything from the internet at all. The NAT gateway gives one-way outbound access while keeping the instances shielded from inbound connections. It's a managed, highly available service, but it does cost per hour and per gigabyte, which surprises people on the bill.

EBS volumes come in SSD-backed and HDD-backed families. General Purpose SSD (gp3, gp2) is the balanced default for most workloads, including boot volumes. Provisioned IOPS SSD (io2, io1) gives the highest, guaranteed IOPS for demanding databases. Throughput Optimized HDD (st1) suits large sequential workloads like big data, and Cold HDD (sc1) is the cheapest for infrequent access.

You choose by the I/O profile: gp3 for general use because you can tune IOPS and throughput independently and cheaply, io2 when a database needs guaranteed high IOPS and durability, and the HDD types when the workload is large and sequential rather than random. Starting with gp3 and measuring is the sensible default.

CloudFormation is AWS's native infrastructure-as-code service. You describe your resources in a template (JSON or YAML), and CloudFormation provisions and manages them as a single unit called a stack, in the right order and with dependency handling. Updating the template updates the stack; deleting the stack tears down everything it created.

The wins are repeatability and cleanup: you version the template, spin up identical environments, and avoid orphaned resources because the stack tracks what it owns. Many teams use Terraform instead for multi-cloud, or the CDK to write infrastructure in a real programming language that compiles to CloudFormation.

ElastiCache is a managed in-memory cache offering Redis and Memcached. It sits between your app and a slower backing store (like RDS) to serve hot data straight from memory in sub-millisecond time, which cuts database load and speeds up reads. AWS runs the nodes, failover, and patching so you don't operate the cache yourself.

You reach for it to cache expensive query results, store session data for stateless apps, and hold frequently read values. Redis adds persistence, replication, and data structures; Memcached is simpler and purely a cache. The hard parts are the usual cache problems: choosing what to cache, setting TTLs, and invalidating stale entries.

Route 53 is AWS's managed DNS service. It translates domain names into addresses and also registers domains and runs health checks. Beyond basic name resolution, it offers routing policies that decide which endpoint a query resolves to, which is where it gets useful for architecture.

The policies worth naming: simple (one record), weighted (split traffic by percentage, handy for canaries), latency-based (send users to the lowest-latency Region), failover (route to a standby when the primary fails a health check), and geolocation (route by user location). Those turn DNS into a traffic-management tool, not just a lookup.

They answer different questions. CloudWatch is about performance and health: it collects metrics, logs, and alarms that tell you how your resources are behaving (CPU, latency, error rates) and alert you when something crosses a threshold. Think of it as the tool for watching whether the system is running well right now.

CloudTrail is about auditing: it records API calls made in your account, who did what, when, and from where. When you need to know who deleted a bucket or changed a security group, that's CloudTrail. CloudWatch tells you the system is unhealthy; CloudTrail tells you what actions were taken. Security and compliance work leans on CloudTrail.

The simplest is VPC peering: a direct, private connection between two VPCs so their resources talk over private IPs. It's cheap and low-latency, but it doesn't route transitively, if A peers with B and B peers with C, A still can't reach C, so peering many VPCs becomes a tangle.

For connecting many VPCs and on-premises networks, Transit Gateway acts as a central hub: every network attaches once to the gateway and routes through it, which scales far better than a mesh of peerings. PrivateLink is the third option, exposing a single service privately across VPCs without opening up whole networks.

It's AWS's set of best-practice pillars for evaluating and improving an architecture: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Each pillar is a lens with questions you ask of a design to find weaknesses before they bite.

In an interview it's useful as a structure: when asked to critique or design a system, you can walk the pillars to show you think beyond just making it work. The point isn't reciting the six names, it's using them to reason about trade-offs, because improving one pillar (say, reliability) often costs another (cost), and naming those tensions is what senior review looks like.

the root user: enable MFA on it, stop using it for daily work, and remove any root access keys comes first. Then run everything through IAM with least privilege, prefer roles and temporary credentials over long-lived keys, and require MFA for humans. Turn on CloudTrail for a full audit log and AWS Config to track resource changes.

Layer on the account structure: use AWS Organizations with separate accounts per environment and Service Control Policies to set guardrails no one can exceed, enable GuardDuty for threat detection, and centralize secrets in Secrets Manager. The threat model to name is credential compromise and misconfiguration, so the controls target both identity and drift.

You use role assumption, not shared credentials. In the account holding the resource, create an IAM role with a trust policy that names the other account (or a specific principal) as allowed to assume it, and attach a least-privilege permissions policy. Principals in the other account then call AssumeRole to get temporary credentials scoped to that role.

For extra safety on third-party access, add an external ID to the trust policy to prevent the confused-deputy problem. This pattern keeps credentials temporary and auditable: every assumption shows up in CloudTrail, and you never copy long-lived keys between accounts. AWS Organizations and IAM Identity Center make this cleaner at scale.

Multiple accounts give hard isolation: a blast radius boundary so a mistake or breach in dev can't touch production, clean per-environment or per-team billing, and separate service quotas. One giant account mixing everything is fragile and hard to reason about at scale.

You manage them with AWS Organizations: a management account, organizational units grouping accounts, and Service Control Policies that set maximum permissions across whole OUs (like denying a Region or a risky action everywhere). IAM Identity Center handles single sign-on across accounts, and consolidated billing rolls it up. The model is 'many accounts, centrally governed'.

The four common tiers trade cost against recovery speed. Backup and restore is cheapest: keep backups, rebuild after a disaster, with recovery in hours. Pilot light keeps a minimal core (like a replicated database) always running and scales the rest up on demand. Warm standby runs a scaled-down full copy ready to take traffic in minutes. Multi-site active-active runs full capacity in multiple Regions for near-zero downtime.

You choose by the business's RTO (how fast you must recover) and RPO (how much data loss is acceptable), because active-active is expensive and complex while backup-and-restore is cheap but slow. Start from those two numbers, not from the architecture, and rehearse the failover, since an untested DR plan usually fails when it's needed.

Measure first: use tagging and Cost Explorer to attribute spend to teams and services, because cutting blind hurts reliability. Then work the big levers: right-size over-provisioned instances, buy Savings Plans or Reserved Instances for steady baseline load, use Spot for fault-tolerant work, move cold data to cheaper S3 tiers, and delete waste like idle instances, unattached EBS volumes, and old snapshots.

The guardrail matters: don't cut the redundancy that protects availability, and don't chase savings that add so much operational risk that one incident erases them. The best wins are usually turning off forgotten resources and right-sizing, not degrading production. Watch the sneaky costs too: NAT gateway data, cross-AZ traffic, and orphaned load balancers.

A common shape is API Gateway in front of Lambda functions, with DynamoDB for state, S3 for files, SQS or EventBridge for async work, and Step Functions to coordinate multi-step workflows. Each piece scales independently and you pay per use, so it fits event-driven and spiky workloads well.

The gotchas are what senior interviews probe: cold starts adding latency (mitigate with provisioned concurrency), the 15-minute Lambda limit ruling out long jobs, connection limits when many Lambdas hit a relational database (use RDS Proxy or DynamoDB), harder local testing and debugging across many small functions, and cost that can exceed a plain server at very high steady volume. Serverless isn't free of operations, the operations just move.

ECS is AWS's own container orchestrator: simpler, tightly integrated, a good default when you're all-in on AWS and don't need Kubernetes. EKS is managed Kubernetes: pick it when you want the Kubernetes ecosystem, portability across clouds, or your team already knows it, at the cost of more complexity to run.

Fargate is a launch mode, not a separate orchestrator: it runs ECS or EKS tasks without you managing the EC2 nodes, so you skip node patching and scaling but pay a premium per unit and give up some low-level control. The decision: ECS for AWS-native simplicity, EKS for Kubernetes portability, and Fargate on top of either when you don't want to manage servers.

Two main options. A Site-to-Site VPN sets up encrypted tunnels over the public internet between your data center and a VPC: quick to stand up and cheap, but throughput and latency ride on the internet. Direct is a dedicated private physical link connects to AWS: consistent low latency and high bandwidth, but it takes time to provision and costs more.

Many enterprises use both: Direct Connect for the primary private path and a VPN as an encrypted backup. At scale, a Transit Gateway centralizes the hybrid connectivity so many VPCs and the on-prem network route through one hub rather than a mesh. The choice comes down to whether you need guaranteed performance (Direct Connect) or fast, cheap setup (VPN).

AWS Key Management Service (KMS) manages the encryption keys most services use. It holds customer master keys, and services like S3, EBS, and RDS use those keys to encrypt data at rest, typically with envelope encryption: KMS encrypts a data key, the data key encrypts your data, and the encrypted data key is stored alongside the data.

You control keys with IAM and key policies, get an audit trail of every use through CloudTrail, and can rotate keys automatically. For the highest assurance, CloudHSM gives you a dedicated hardware security module. Encryption in transit is separate and comes from TLS. The senior points are envelope encryption, key policies as a second access layer, and CloudTrail-audited key usage.

It shows up wherever data is replicated across machines or regions. DynamoDB offers eventually consistent reads by default (cheaper and faster) and strongly consistent reads on request; a read right after a write might see stale data unless you ask for strong consistency. RDS read replicas lag the primary asynchronously, so a read replica can return slightly old data.

S3 is now strongly consistent for reads after writes, which removed a classic gotcha, but cross-region replication is still asynchronous. You handle it by choosing strong consistency where correctness demands it (accepting the cost and latency), designing flows that tolerate slight staleness, and reading from the primary when you just wrote and must see the result immediately.

A cold start happens when Lambda has to spin up a fresh execution environment for your function: it downloads the code, starts the runtime, and runs your initialization before handling the request. That setup adds latency, and it happens on the first invocation and when scaling up to more concurrent instances. A warm environment reused for a later request skips all that.

You reduce cold starts by keeping the deployment package and dependencies small, choosing a faster-starting runtime, and moving heavy setup out of the request path. For latency-sensitive functions, provisioned concurrency keeps a set number of environments always warm, at extra cost. Putting a Lambda inside a VPC used to worsen cold starts, though AWS improved that with better networking.

S3 scales to very high request rates per prefix: thousands of GET and PUT requests per second per prefix, and it scales horizontally as you spread load across more prefixes. Older guidance about randomizing key prefixes to avoid hotspots is largely outdated now, but distributing keys across prefixes still helps for extreme request volumes.

For read-heavy or global workloads, put CloudFront in front so most requests hit the CDN edge, not S3 directly. Use multipart upload for large objects to parallelize and recover from failures, S3 Transfer Acceleration for long-distance uploads, and byte-range fetches to parallelize large downloads. The design instinct is to cache reads and parallelize large transfers rather than hammer a single object.

Two styles. Synchronous, request-response over HTTP through API Gateway, an Application Load Balancer, or service discovery (Cloud Map), which is simple but couples services in time: if a downstream is slow, callers wait. Asynchronous, through queues (SQS) and events (SNS, EventBridge), which decouples services so a slow or down consumer doesn't break the producer.

Resilience comes from favoring async where you can, adding timeouts and retries with backoff and a dead-letter queue so failed messages aren't lost, and using idempotent handlers because at-least-once delivery means a message can arrive twice. EventBridge for event routing and Step Functions for orchestrating multi-step workflows keep the coupling loose. The instinct that scores: prefer events over synchronous chains to contain failure.

Clarify first: expected traffic and growth, read versus write mix, latency and availability targets, budget, and any compliance needs. Then lay out the tiers. Front it with Route 53 for DNS and CloudFront for edge caching and TLS. Put stateless application servers in an Auto Scaling group across multiple Availability Zones behind an Application Load Balancer, and keep session state in DynamoDB or ElastiCache so instances stay disposable.

For data, use RDS Multi-AZ (add read replicas for read-heavy load) or DynamoDB for scale, store files and static assets in S3 served through CloudFront, and cache hot reads in ElastiCache. Wrap it with the cross-cutting concerns: least-privilege IAM, private subnets for the app and database with a NAT gateway for outbound, CloudWatch monitoring and alarms, and a DR plan sized to the RTO and RPO you asked about. The structure that scores is clarify, multi-AZ stateless tier, managed data with replicas, cache and CDN, then secure and observe, each choice justified by the requirements.