AWS interview questions test both conceptual understanding of core services and how you'd architect real systems on the platform. Here's what comes up most for backend, DevOps, and cloud roles.
EC2 gives you full virtual machines you manage yourself (OS, scaling, patching) — most control, most operational overhead. Lambda runs your code as stateless functions triggered by events, with no server management and automatic scaling, but functions are capped at 15 minutes of execution time and can suffer cold-start latency. ECS/EKS run containerized workloads (Docker) with orchestration for scaling and scheduling — ECS is AWS's native orchestrator, EKS is managed Kubernetes — striking a middle ground between full VM control and fully serverless. A common way to frame it in an interview: EC2 is infrastructure you own, Lambda is code you hand to AWS to run, and ECS/EKS sit in between, owning the container runtime while you still define how workloads are packaged and scheduled.
S3 Standard is for frequently accessed data with the highest availability and lowest latency. S3 Standard-IA and One Zone-IA cost less per GB but charge a retrieval fee, suiting data accessed occasionally, with One Zone trading multi-AZ redundancy for an even lower price. S3 Intelligent-Tiering automatically moves objects between access tiers based on observed usage, which is useful when access patterns are unpredictable. For long-term archival, Glacier Instant Retrieval, Glacier Flexible Retrieval, and Glacier Deep Archive offer progressively lower storage cost in exchange for retrieval times ranging from milliseconds to many hours — choosing the right class based on access patterns is a common cost-optimization lever.
IAM (Identity and Access Management) defines who (users, groups, roles) can do what (actions) on which resources, via JSON policy documents attached to identities or resources. The best practice is least-privilege — granting only the specific permissions needed — and using roles (temporary, assumable credentials issued via STS) for services and applications rather than long-lived access keys embedded in code. Policies can also be resource-based (like an S3 bucket policy) rather than identity-based, and permission boundaries or SCPs (in AWS Organizations) can cap what even an administrator is allowed to grant.
A VPC (Virtual Private Cloud) is an isolated, logically-defined section of AWS where you control networking — subnets, route tables, IP ranges, and gateways. It lets you place resources in public subnets (internet-facing, with a route to an internet gateway) or private subnets (internal only, no direct inbound internet access), which is central to securing a multi-tier architecture where, for example, a database shouldn't be directly reachable from the internet. Private subnets typically reach the internet outbound (for patches or API calls) through a NAT gateway, and VPC peering or Transit Gateway let you connect multiple VPCs together when needed.
RDS is a managed relational database service (Postgres, MySQL, SQL Server, and others) — you get SQL, joins, and ACID transactions, with AWS handling patching, backups, and failover. DynamoDB is a managed NoSQL key-value/document store built for very high, predictable single-digit-millisecond latency at virtually unlimited scale, with a different data modeling approach (denormalized, access-pattern-driven) rather than normalized relational tables. A common interview follow-up is Aurora, AWS's own relational engine that's wire-compatible with MySQL/Postgres but re-architected for higher throughput and faster replication than stock RDS.
Deploy across multiple Availability Zones (physically separate data centers within a region) so a single AZ failure doesn't take the system down, use an Auto Scaling Group behind a load balancer to replace unhealthy instances automatically, and use managed services with built-in multi-AZ replication (like RDS Multi-AZ, which keeps a synchronous standby in another AZ for automatic failover) for the data layer. For disaster recovery beyond a single region, some architectures also replicate across regions using strategies like pilot light, warm standby, or active-active, trading cost and complexity for resilience to a full-region outage. High availability and disaster recovery are related but distinct goals — HA is about surviving component or AZ failure with minimal disruption, DR is about recovering after a larger-scale disaster, and interviewers often want you to name the tradeoff explicitly.
A Security Group is a stateful virtual firewall attached to instances or resources — if you allow inbound traffic on a port, the corresponding outbound response is automatically allowed. A Network ACL operates at the subnet level and is stateless — inbound and outbound rules must both be explicitly defined, since return traffic isn't automatically permitted, and rules are evaluated in numbered order until a match is found. Security Groups are the primary, more granular control and only support allow rules; NACLs add a coarser subnet-level layer and can also explicitly deny traffic, which makes them useful for quickly blocking a known bad IP range across an entire subnet.
AWS is responsible for security OF the cloud — the physical data centers, hardware, global network infrastructure, and the virtualization layer. The customer is responsible for security IN the cloud — configuring IAM correctly, patching the guest OS where applicable, securing application code, managing network controls like security groups, and encrypting data. Where the line falls shifts with the service: on EC2 you own the OS and everything above it, while on a fully managed or serverless service like Lambda or S3, AWS takes on more of the stack and you're left mainly responsible for configuration, data, and access control. Interviewers often use this question to check that you understand AWS will never patch your application code or fix a misconfigured S3 bucket policy for you.
CloudFront caches content at edge locations around the world so users fetch data from a nearby point of presence instead of the origin server, cutting latency and offloading traffic from S3, an ALB, or an on-premises origin. On a cache miss, CloudFront pulls from the origin, caches the response according to configured TTLs and cache behaviors, and serves subsequent requests from the edge until the object expires or is invalidated. It integrates with AWS WAF and Shield for edge-level security, supports signed URLs and signed cookies to serve private content to authorized users only, and can also handle dynamic content by proxying straight through to the origin when caching isn't appropriate. A common gotcha interviewers probe for is remembering to invalidate or version cached assets after a deployment so users don't get stale content.
Route 53 is AWS's managed DNS service, used both for registering and resolving domain names and for directing traffic based on policy rather than just returning a static IP. Simple routing returns one or more resource records for a domain with no special logic, while weighted routing splits traffic across multiple endpoints by percentage, useful for gradual rollouts or A/B testing. Latency-based routing sends users to the region with the lowest measured latency, geolocation and geoproximity routing route based on the user's location, and failover routing pairs with health checks to redirect traffic to a standby endpoint if the primary becomes unhealthy. Multivalue answer routing returns several healthy records for simple client-side load balancing, and these policies are often combined, for example weighted routing nested inside a latency-based policy for fine-grained traffic control.
SQS is a pull-based message queue used to decouple producers and consumers — messages sit in the queue until a consumer polls and processes them, which smooths out traffic spikes and lets consumers scale independently. SNS is a push-based pub/sub service — a single published message fans out immediately to multiple subscribers, which can be SQS queues, Lambda functions, HTTP endpoints, email, or SMS. SQS offers Standard queues (at-least-once delivery, best-effort ordering, higher throughput) and FIFO queues (exactly-once processing and strict ordering, with lower throughput limits). A very common pattern is combining the two — SNS fans a single event out to several SQS queues so each downstream service processes it independently and durably, rather than SNS delivering directly to consumers that might be temporarily unavailable.
CloudFormation lets you define AWS infrastructure declaratively in YAML or JSON templates, describing the desired end state of resources rather than the steps to create them. Deploying a template creates a stack, and CloudFormation tracks every resource in that stack so updates and deletions are managed consistently, with change sets letting you preview exactly what will be added, modified, or replaced before applying anything. Drift detection can flag when someone has manually changed a resource outside of CloudFormation, which is a common source of production incidents. In interviews it's also worth contrasting CloudFormation with Terraform (a multi-cloud IaC tool with its own state file and HCL syntax) and the AWS CDK (which lets you author CloudFormation templates using a real programming language like TypeScript or Python).
An Auto Scaling Group is defined by a launch template plus a minimum, maximum, and desired capacity, and it uses health checks (EC2 status checks or ELB health checks) to automatically terminate and replace unhealthy instances. Scaling itself is driven by policies: target tracking scaling keeps a metric like average CPU or request count near a target value and adjusts capacity automatically, step scaling changes capacity by defined increments as a metric crosses thresholds, and scheduled scaling pre-emptively adjusts capacity for known traffic patterns like a daily peak. Combining a target tracking policy for normal fluctuation with a scheduled policy for predictable spikes is a common real-world setup, and cooldown periods prevent the group from reacting too aggressively to short-lived metric noise.
ElastiCache is a managed in-memory data store used to cache frequently accessed data and take load off a primary database, supporting either the Redis or Memcached engine. Redis is the more feature-rich option — it supports persistence, replication, automatic failover with cluster mode, pub/sub, and richer data structures like sorted sets and hashes — while Memcached is a simpler, multi-threaded pure cache with no persistence or replication, suited to straightforward horizontal scaling of a cache layer. The most common pattern is cache-aside, where the application checks the cache first, falls back to the database on a miss, and writes the result back into the cache. It's typically reached for when database read load or latency becomes a bottleneck for read-heavy, repeatedly-accessed data like session state or query results.
A cold start happens when Lambda has to initialize a brand-new execution environment for a function — downloading the code package, starting the runtime, and running any initialization code outside the handler — which adds latency compared to reusing a warm environment. Cold starts are typically worse for functions attached to a VPC, functions with larger deployment packages, and runtimes with heavier startup costs like Java, and can be mitigated with provisioned concurrency, which keeps a specified number of environments pre-initialized and ready. Separately, concurrency limits control how many instances of a function can run simultaneously per account or per function; reserved concurrency guarantees (and caps) capacity for a specific function, and requests beyond the available concurrency are throttled rather than queued indefinitely. Interviewers often want to hear that provisioned concurrency solves latency while reserved concurrency solves resource contention — they address different problems even though both involve the word concurrency.
On-Demand pricing charges per use with no commitment, which is flexible but the most expensive baseline. Reserved Instances and Savings Plans commit to steady usage over a 1- or 3-year term in exchange for discounts of up to roughly 70%, making sense for predictable, always-on workloads. Spot Instances tap into AWS's spare capacity at a steep discount but can be reclaimed with about two minutes' notice, making them a good fit for fault-tolerant or batch workloads like data processing or CI runners rather than anything stateful and latency-sensitive. Beyond compute purchasing options, right-sizing instances, applying S3 lifecycle policies to move cold data to cheaper storage classes, and using Cost Explorer or Trusted Advisor to spot idle or underutilized resources are the everyday levers most teams actually pull.
CloudWatch collects metrics, logs, and events from AWS services and custom applications, and CloudWatch Alarms watch those metrics against a threshold to trigger an action, such as notifying an SNS topic, paging on-call, or invoking an Auto Scaling policy. CloudWatch Logs centralizes application and service logs, and Logs Insights lets you run query-based searches across them without standing up a separate log pipeline for basic use cases. Dashboards give a visual view of key metrics, and custom metrics can be published from application code for anything AWS doesn't track out of the box. It's worth distinguishing CloudWatch from CloudTrail in an interview — CloudWatch is about operational metrics and logs, while CloudTrail is an audit log of API calls made against your account, and the two are frequently confused.
Encryption in transit is generally handled by TLS between clients and AWS services, or between services themselves, protecting data as it moves across the network. Encryption at rest is typically handled per-service — S3, EBS, and RDS all support encrypting stored data — and KMS (Key Management Service) is the backing service that creates, stores, and manages the encryption keys (CMKs) used to do it, using envelope encryption where a data key encrypts the actual data and is itself encrypted by a master key. You can use AWS-managed keys for convenience or customer-managed keys when you need control over key policies, rotation, and auditing of exactly who used a key and when. Key policies (separate from IAM policies) control access to the key itself, which is a common point of confusion — having IAM permission to use a KMS key isn't enough if the key's own policy doesn't also allow it.
Elastic Beanstalk is a platform-as-a-service layer on top of EC2 — you upload your application code and Beanstalk provisions and wires together the underlying EC2 instances, load balancer, Auto Scaling Group, and monitoring for you, while still giving you access to the underlying resources if you need to tune them. Setting up EC2 manually means you choose and configure every piece yourself — the AMI, the load balancer, the scaling policies, the deployment pipeline — which gives full control at the cost of more operational setup and maintenance. Beanstalk is generally reached for when a team wants to get a standard web application running quickly without building that infrastructure by hand, while manual EC2 (or IaC on top of it) is preferred when the architecture has requirements Beanstalk's opinionated setup doesn't fit well. It sits between fully managed serverless options like Lambda and fully manual EC2, trading some flexibility for a much faster path to a running, scalable environment.