AWS Interview Questions

Note: Naming services is easy; justifying them is what interviewers listen for. For every service you mention, be ready to say what you considered instead.

Cover:

• The workload and its scale. Traffic pattern, data volume, and availability requirement. A spiky consumer application and a steady internal service lead to different architectures.
• The services and the reasoning. "We used Fargate rather than EKS because we had four services and no one to run a cluster" is a real answer. "We used Lambda, S3, and DynamoDB" is a list.
• The hard part. Strong candidates: getting VPC networking and private connectivity right, a database migration with minimal downtime, cost growing faster than usage, or cold starts and concurrency limits under load.
• Outcome — cost, latency, availability, or deployment frequency, with numbers.

If you inherited the architecture rather than designing it, say so and describe what you changed.

This is asked in almost every AWS interview because runaway spend is so common.

Visibility first — you cannot manage what you cannot attribute:

• Tagging enforced by policy for environment, owner, and cost centre, with cost allocation tags activated.
• AWS Budgets with alerts, and Cost Explorer for trend analysis. Anomaly detection catches a spike within a day rather than at month end.

Then the levers, in rough order of payoff:

• Turn off what is idle. Non-production environments running nights and weekends, unattached EBS volumes, old snapshots, idle load balancers, and unassociated Elastic IPs. This is usually the fastest large saving.
• Rightsize. Compute Optimizer gives specific recommendations; instances are routinely provisioned for a peak that never occurs.
• Savings Plans or Reserved Instances for predictable baseline load, and Spot for fault-tolerant batch work, which can cut compute cost dramatically.
• S3 lifecycle policies and Intelligent-Tiering to move cold data down the storage classes.
• Watch data transfer. Cross-AZ and egress charges surprise people because ingress is free, and a chatty architecture across availability zones can cost more than the compute.

Note: Framing cost as an architectural property — that an efficient design is a cheaper design — is stronger than treating it as a procurement exercise.

Give a timeline and separate stabilising from diagnosing.

• Detection. Which alarm, what metric, and how long after the actual start. If a customer told you first, say so — the gap is a finding in itself.
• Stabilise before you understand. Rolling back a deployment, scaling out, failing over to another availability zone, or shedding load. Interviewers want to see that you restore service rather than debugging while users are down.
• Diagnosis. CloudWatch metrics and logs, X-Ray traces to find which downstream call was slow, CloudTrail to see what changed and who changed it, and the AWS Health Dashboard to rule out a platform-side event.
• The permanent fix. Usually structural: a missing health check, no retry with exponential backoff and jitter, a single-AZ dependency, a connection pool exhausted under load, or a hard service quota nobody knew about.

Note: Service quotas are an excellent detail — hitting a Lambda concurrency limit or an API rate limit during a traffic spike is a very common cloud outage cause and one many candidates have never considered. Mentioning that you now monitor quota utilisation shows genuine operational experience.

Lead with identity and least privilege.

• Never use the root account for daily work. Enable MFA on it, remove its access keys, and lock it away.
• No long-lived IAM user access keys where they can be avoided. Use IAM roles — for EC2 instances, Lambda functions, and ECS tasks — so credentials are temporary and rotated automatically. For humans, federate through IAM Identity Center or your existing identity provider rather than creating IAM users.
• Least privilege, built iteratively. Start restrictive and expand from Access Analyzer findings and CloudTrail evidence of what was actually used, rather than granting broad access and intending to tighten it later.
• Multi-account structure with AWS Organizations — separate accounts for production, development, and shared services, with Service Control Policies setting guardrails. Account boundaries are the strongest isolation AWS offers.
• Secrets in Secrets Manager or Parameter Store, never in code, environment variables in a repository, or an AMI.
• Encryption at rest with KMS and in transit with TLS, as a default rather than an exception.
• Detection — CloudTrail enabled everywhere and shipped to a separate account, plus GuardDuty and Security Hub.

Note: Saying you would enforce standards with SCPs and automated checks rather than documentation is what separates someone who has operated a real AWS estate.

How you keep up: the What's New feed and release notes, the AWS Architecture Blog, and re:Invent sessions for the reasoning behind services rather than just their existence. Hands-on work in a personal account is what actually builds judgement — AWS documentation describes the happy path, and the limits only appear when you build something.

How you evaluate a new service:

• Is it generally available in the regions you use? Preview services carry no SLA and may change.
• Does it solve a problem you have measured? AWS releases hundreds of features a year and most are irrelevant to any given workload.
• What are the limits and quotas? This is the question people skip and regret. Concurrency caps, payload sizes, and throughput limits determine whether a service fits at your scale.
• What is the exit cost? The more proprietary the service, the harder it is to leave. That is often an acceptable trade for the operational savings — but it should be a decision, not an accident.
• Can your team operate it? Adopting EKS without Kubernetes experience creates a larger problem than it solves.

Note: The Well-Architected Framework's six pillars are worth naming as the structure you evaluate against — operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability.

Four levels of abstraction, and the guidance is to choose the highest one that meets the requirement.

• EC2 — virtual machines. You manage the operating system, patching, scaling groups, and load balancing. Maximum control and maximum operational burden. Use it for legacy applications, workloads needing specific OS configuration or licensing, or long-running processes that do not containerise well.
• ECS / EKS — container orchestration. ECS is AWS-native and simpler; EKS is managed Kubernetes, portable but with real operational overhead. Use them when you have multiple services to schedule and genuine orchestration needs.
• Fargate — a serverless compute engine for ECS and EKS. You define CPU and memory per task and AWS runs it; there are no instances to patch or scale. Use it when you want containers without managing a cluster of hosts, which covers most container workloads.
• Lambda — event-driven functions. You supply code, AWS handles everything else, scaling to zero and charging per invocation and duration. Use it for event processing, APIs with variable traffic, scheduled jobs, and glue between services.

Lambda's constraints matter: a 15-minute maximum execution time, cold starts affecting latency-sensitive paths, and a concurrency limit. It is excellent for spiky, short work and a poor fit for sustained high-throughput processing, where it can also be more expensive than containers.

Three storage types with different access models — the distinction is how they are attached and accessed.

• S3 — object storage. Accessed over HTTP APIs, not mounted as a filesystem. Effectively unlimited capacity, eleven nines of durability, and very cheap. Objects are written and read whole rather than modified in place. Use for: backups, static assets, data lakes, logs, and media. Storage classes — Standard, Infrequent Access, Glacier tiers — trade retrieval cost against storage cost, managed by lifecycle policies.
• EBS — block storage. A virtual disk attached to a single EC2 instance, in one availability zone. Behaves like a physical disk, so it is what the operating system and databases run on. Volume types range from gp3 for general purpose to io2 for high-IOPS database workloads. Snapshots go to S3 for backup.
• EFS — network file system. An NFS share mountable by many instances simultaneously, across availability zones, growing automatically. Use for: shared content across a fleet, lift-and-shift applications expecting a shared filesystem, or shared home directories. More expensive per gigabyte than EBS.

How to choose: if it needs to look like a disk to one instance, EBS. If several instances need the same files at once, EFS. For anything else — and especially anything large or long-lived — S3, because it is cheaper, more durable, and does not need a server.

A VPC is a logically isolated network within AWS, defined by a CIDR block. Inside it you create subnets, each in a single availability zone.

• A public subnet has a route to an Internet Gateway. Resources with public IPs there are internet-reachable.
• A private subnet has no such route. For outbound internet access — downloading patches, calling an API — it routes through a NAT Gateway in a public subnet, which allows outbound but not inbound connections.

Security groups versus NACLs is the classic question:

• Security groups operate at the instance level, are stateful (return traffic is automatically allowed), and support allow rules only — everything not permitted is denied. They can reference other security groups as a source, which is the clean way to express "the application tier may reach the database tier".
• NACLs operate at the subnet level, are stateless (you must explicitly allow return traffic, including ephemeral ports), and support both allow and deny rules, evaluated in numbered order.

In practice security groups do most of the work; NACLs are a coarse secondary layer, most useful for blocking a specific address range.

Note: VPC endpoints are worth mentioning — they let instances in private subnets reach S3 and DynamoDB without traversing the internet or a NAT Gateway, improving security and cutting NAT data processing costs significantly.

IAM controls who can do what in an AWS account.

• Users — long-lived identities for a person or application, with a password or access keys. These should be minimised. Long-lived access keys are the most common cause of AWS credential compromise, usually through being committed to a repository.
• Groups — collections of users for attaching policies. Manage permissions here rather than per user.
• Roles — identities that are assumed temporarily rather than logged into. They have no permanent credentials; assuming one issues short-lived credentials from STS. This is the mechanism AWS wants you to use everywhere: EC2 instances, Lambda functions, and ECS tasks all get roles, and humans federate into roles from an identity provider.
• Policies — JSON documents defining permissions with Effect, Action, Resource, and optional Condition. Identity-based policies attach to users, groups, and roles; resource-based policies attach to resources such as an S3 bucket and specify who may access them.

How evaluation works: an explicit Deny always wins. Otherwise, access requires an explicit Allow, since the default is deny.

Note: Two useful extras. Conditions are where fine-grained control lives — restricting by source IP, requiring MFA, or requiring encryption in transit. And Service Control Policies at the Organizations level set a maximum permission boundary an account cannot exceed, regardless of its own IAM policies.

Start with the requirement, not the architecture. RTO and RPO determine how much you should spend, and "as available as possible" is not a requirement.

The layers, in increasing cost and protection:

• Eliminate single points of failure within an availability zone. Multiple instances behind an Application Load Balancer in an Auto Scaling group, with health checks replacing unhealthy instances automatically.
• Spread across availability zones. This is the fundamental AWS availability pattern and usually the best value: AZs are physically separate with independent power and networking, and inter-AZ latency is low. Use Multi-AZ RDS, subnets in at least three AZs, and Auto Scaling configured to balance across them.
• Make the application stateless. Sessions in ElastiCache or DynamoDB, uploads in S3 — so any instance can serve any request and instances are disposable.
• Multi-region only if the requirement genuinely demands surviving a region failure. It roughly doubles cost and introduces hard data replication and consistency problems. Route 53 health checks or Global Accelerator handle failover; the database is the difficult part.

Design for failure throughout: retries with exponential backoff and jitter, circuit breakers, timeouts on every call, graceful degradation, and queues to absorb spikes and decouple components.

Note: Say that an untested failover is not a failover. Regular game days are what turn a diagram into a capability.

• RDS — managed relational databases: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server. AWS handles patching, backups, and Multi-AZ failover; you keep full SQL, joins, transactions, and a familiar engine. Use it for anything with genuine relational structure, and for migrating an existing application without rewriting it.
• Aurora — AWS's MySQL- and PostgreSQL-compatible engine with a re-architected storage layer that replicates six ways across three availability zones. Substantially faster than standard RDS, with up to 15 low-lag read replicas and much faster failover. Aurora Serverless v2 scales capacity automatically, which suits variable or unpredictable workloads. Use it when you want relational semantics with better performance and availability, and can accept AWS-specific behaviour.
• DynamoDB — a managed NoSQL key-value and document store with single-digit millisecond latency at effectively any scale, no servers, and no connection management. Use it for high-volume, well-understood access patterns: session stores, user profiles, IoT ingestion, shopping carts.

The critical distinction: DynamoDB requires you to design the table around your access patterns up front. There are no joins and no efficient ad hoc queries — querying by something other than the key means a costly scan or a secondary index planned in advance. If your query patterns are unknown or exploratory, a relational database is the right answer.

Note: DynamoDB on-demand versus provisioned capacity is a common follow-up: on-demand for unpredictable traffic, provisioned with auto scaling for steady load at lower cost.

Infrastructure as code means declaring your infrastructure in version-controlled files rather than clicking through the console. The benefits are reproducibility, code review on infrastructure changes, drift detection, and disaster recovery becoming a pipeline run rather than an archaeology exercise.

The options on AWS:

• CloudFormation — the native service. You write a YAML or JSON template describing resources, and CloudFormation creates them as a stack, handling dependency ordering and, importantly, rolling back automatically if creation fails. Change sets preview what an update will do before you apply it — always use them on anything important. StackSets deploy the same template across many accounts and regions.
• AWS CDK — define infrastructure in TypeScript, Python, Java, or Go, which synthesises to CloudFormation. You get loops, conditionals, type checking, and reusable constructs, which makes large infrastructures far more manageable than raw YAML.
• Terraform — multi-cloud, with a large module ecosystem and its own state file to manage. Frequently chosen where an organisation is not AWS-only.
• SAM — a CloudFormation extension with concise syntax for serverless applications.

Note: The practical caution is drift — someone changing a resource in the console breaks the template's assumptions. Detect it with drift detection, and prevent it by restricting console write access in production so the pipeline is the only path to change.

CloudWatch is the foundation, collecting metrics (numeric time series, with basic EC2 metrics free at five-minute intervals and detailed monitoring at one), logs (via the CloudWatch agent or natively from Lambda and ECS), and alarms that trigger notifications or actions such as Auto Scaling.

The rest of the toolkit:

• CloudWatch Logs Insights — a query language for searching and aggregating across log groups, which is how you actually investigate rather than scrolling.
• X-Ray — distributed tracing. In a system of many services, this is what tells you which downstream call made a request slow. Essential once you pass a handful of services.
• CloudTrail — an audit log of every API call: who did what, when, and from where. The first place to look when something changed unexpectedly, and a security-critical record that should be shipped to a separate account.
• VPC Flow Logs for network-level troubleshooting and detecting unexpected traffic.
• AWS Health Dashboard for platform-side events affecting your resources — check this early.

Practices that matter: structured JSON logging so logs are queryable; a correlation id propagated across services; custom business metrics alongside infrastructure metrics; and log retention set deliberately, because CloudWatch Logs ingestion and storage is a common surprise on the bill.

Note: Alarm on user-visible symptoms — error rate, latency, availability — rather than on CPU. Alerting on causes produces noise.

The shared responsibility model defines the boundary between what AWS secures and what you secure. It is summarised as AWS is responsible for security of the cloud; you are responsible for security in the cloud.

AWS is always responsible for: physical datacentres, hardware, the hypervisor, and the managed service software itself.

You are always responsible for: your data, how you classify and encrypt it, IAM configuration, network and firewall configuration, and application-level security.

Where the line sits depends on the service:

• EC2 (IaaS) — you manage the guest operating system, patching, applications, and security groups. AWS manages the hypervisor down.
• RDS (managed) — AWS patches the database engine and operating system. You manage database users, encryption settings, network access, and backups retention.
• S3 and Lambda (fully managed) — AWS manages nearly everything except your data, permissions, and configuration.

The practical consequences worth stating:

• A publicly exposed S3 bucket is a customer misconfiguration, not an AWS failure — and this remains one of the most common sources of real-world data exposure.
• AWS durability is not backup. S3's eleven nines protect against hardware loss, not against you deleting the object. Versioning and lifecycle policies are your responsibility.
• Patching an EC2 instance is yours; patching RDS is AWS's — which is itself a strong argument for managed services.

Decoupling means components communicate through a message service rather than calling each other directly, so one being slow or unavailable does not cascade.

• SQS — a queue, one-to-one. A producer writes a message; one consumer processes and deletes it. It absorbs traffic spikes, so a burst queues rather than overwhelming the consumer. Standard queues give at-least-once delivery and best-effort ordering; FIFO queues give exactly-once processing and strict ordering at lower throughput.
• SNS — pub/sub, one-to-many. A message published to a topic is pushed to every subscriber — Lambda functions, SQS queues, HTTP endpoints, email. Use it to fan one event out to several independent consumers.
• EventBridge — an event bus with routing and filtering. Events are matched against rules on their content and routed to targets. It also receives events from AWS services and SaaS partners, and supports schema discovery and archive-and-replay. Use it for event-driven architectures where routing logic matters.

The common pattern is SNS fanning out to several SQS queues, giving both broadcast and per-consumer buffering with independent retry.

Essential practices: configure a dead letter queue so messages that repeatedly fail are captured rather than lost or retried forever; and make consumers idempotent, because at-least-once delivery means the same message can arrive twice.