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.

The interviewer wants to see that you treat a migration as a planned programme with a rollback path, not a weekend copy job. Structure the answer as assess, plan, migrate, cut over, optimise.

• Context: name the application, its size and why it was moving — for example, “a Java order-management system on two ageing data-centre servers, with the hardware contract ending in six months.”
• Assessment: how you mapped dependencies (databases, file shares, cron jobs, hard-coded IPs, licences) and chose a strategy from the 7 Rs — rehost, replatform, refactor, repurchase, relocate, retain or retire. Saying “we replatformed the database onto RDS but rehosted the app servers on EC2 first” shows judgement.
• Foundations: the landing zone you built before moving anything — accounts, VPC with private subnets, VPN or Direct Connect back to the office, IAM roles and logging.
• Data migration: the tools and the approach, such as AWS DMS with ongoing replication so the cut-over window only covered the final sync, or DataSync for file shares.
• Cut-over: lowering DNS TTLs in advance, a rehearsed runbook, a go/no-go checklist, and a tested rollback plan.
• Result: measurable outcomes — downtime in minutes, cost versus the old hosting, improved recovery time, fewer incidents.

What makes it strong: one honest problem you hit, such as an undocumented dependency discovered during the dry run, and how you handled it. Close with what you optimised after the move, such as right-sizing instances once real metrics were available.

Note: Avoid claiming every workload should be refactored to serverless. Interviewers trust candidates who rehost first to meet a deadline and modernise afterwards.

This tests judgement and influence. A good answer shows you disagreed with evidence, respected the other person, and reached a better outcome together. Use STAR, and spend most of your time on the Action.

• Situation: make the proposal concrete — “the team wanted to run a self-managed Kubernetes cluster on EC2 for three small internal APIs,” or the opposite risk, “a payments service planned as a single EC2 instance in one availability zone.”
• Why it worried you: tie it to a requirement, not a preference. Operational load the team could not staff, a single point of failure against a stated uptime target, or cost out of proportion to traffic.
• How you pushed back: you asked questions first to understand the reasoning, then brought data — a rough cost comparison, the on-call effort, a failure scenario walked through step by step. Frame it with the Well-Architected pillars so it reads as a trade-off, not an opinion.
• The alternative: offer something concrete, such as ECS on Fargate behind an ALB, or a Multi-AZ RDS instance plus an Auto Scaling group across two zones.
• Result: what was decided and the measurable effect — lower monthly cost, fewer pages, or the design surviving a real zone issue later.

Show maturity: mention a point you conceded, or that you documented the decision in an architecture decision record so it could be revisited. If you were overruled, explain how you committed to the decision and reduced the risk anyway.

Note: Never describe colleagues as incompetent. The story is about the reasoning, and interviewers are listening for whether you would be easy to work with.

This checks whether you plan capacity deliberately rather than hoping Auto Scaling saves you. Walk through forecast, test, harden, rehearse, observe.

• Forecast: how you estimated peak load — last year’s numbers, marketing’s campaign plan, a multiple of normal traffic — and translated it into requests per second and database load.
• Find the bottleneck: the web tier is rarely the problem. Talk about the database (connection limits, read replicas, caching with ElastiCache), third-party APIs, and service quotas such as Lambda concurrency or EC2 vCPU limits that you raised in advance.
• Load testing: a realistic test at or above forecast peak, what broke, and what you fixed. This is the part interviewers remember.
• Scaling setup: scheduled scaling to pre-warm capacity before the event, since reactive scaling lags a sudden surge; higher minimums in the Auto Scaling group; CloudFront caching for static and semi-static pages.
• Protection: graceful degradation such as a queue for order processing, rate limiting with AWS WAF, and feature flags to switch off expensive features.
• On the day: a dashboard of the key metrics, alarms, a war-room rota, a change freeze, and a rollback plan.
• Result: peak traffic handled, error rate, latency, and what it cost compared with the previous year.

Close with learning: what you would do differently, and what you automated afterwards so the next event needed less manual work.

Note: Mention that you scaled back down afterwards. Leaving peak capacity running for weeks is a common and expensive mistake.

The interviewer is assessing whether you can change how a team works, not just write templates. Tell it as a change story: where they started, what you introduced, how you got buy-in, and what improved.

• Starting point: be specific — resources created by clicking in the console, no record of who changed what, environments that had drifted apart, and releases done by one person over SSH.
• What you introduced: the tool and why — CloudFormation or CDK because the team was AWS-only and TypeScript-heavy, or Terraform because they also used other providers. Add the pipeline: pull request, lint and security checks such as cfn-lint or Checkov, a change set or plan for review, then deployment.
• How you did it incrementally: starting with one non-critical service, importing existing resources rather than recreating them, and building reusable modules or constructs so the next team found it easy.
• Getting buy-in: pairing sessions, a short internal guide, and showing a quick win — for example, rebuilding a test environment in twenty minutes instead of two days.
• Guardrails: removing console write access in production once IaC was trusted, and drift detection to catch manual changes.
• Result: deployment frequency, lead time, fewer failed releases, or faster recovery, with rough numbers if you have them.

Include a setback: resistance from a senior developer, or a template that deleted a resource unexpectedly, and what you changed — such as adding DeletionPolicy and mandatory change-set review.

Note: Emphasise enabling the team to own their infrastructure. An answer where you remain the only person who can deploy is a warning sign.

This is a trade-off question. The interviewer wants a structured decision, not loyalty to either approach. Pick a real example — self-managed PostgreSQL versus RDS, Kafka on EC2 versus Amazon MSK, Elasticsearch versus Amazon OpenSearch Service, or cron servers versus EventBridge Scheduler with Lambda.

• Context: the workload, its scale, and the team size. “Two engineers supporting a Kafka cluster that paged us every week” sets the scene quickly.
• Criteria you used:
  • Total cost of ownership, including engineer time for patching, backups, upgrades and on-call — not just the monthly bill.
  • Required features and versions, and whether the managed service supports them.
  • Control needs such as OS access, custom plugins or specific tuning.
  • Reliability features you would otherwise build yourself: Multi-AZ failover, automated backups, point-in-time recovery.
  • Lock-in and portability, and whether they genuinely matter for this workload.
• How you evaluated: a proof of concept, a cost model covering a year, and a check of limits and quotas.
• Decision and result: for example, moving to RDS removed most database pages and freed an engineer, at a modestly higher infrastructure cost that the team accepted.

Show balance: mention a case where self-managed was right, such as a database extension the managed service did not support, and how you mitigated the extra operational work with automation.

Note: The strongest line in this answer is usually the one that puts a value on engineering time. Managed services win more often than the bill alone suggests.

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.

AWS evaluates several policy types together. Some grant permissions; others only set the maximum that can be granted.

• Identity-based policies — attached to users, groups or roles. They grant permissions.
• Resource-based policies — attached to resources such as S3 buckets, SQS queues, KMS keys and role trust policies. They name a principal and grant permissions, and are the usual way to allow cross-account access.
• Permissions boundaries — set the maximum permissions an identity-based policy can give a user or role. Useful when you let developers create roles without letting them escalate privileges.
• Service control policies (SCPs) — set the maximum permissions for accounts in an AWS Organization. Resource control policies do the same on the resource side.
• Session policies — passed when assuming a role to narrow that session further.

The evaluation logic:

1. Every request starts as an implicit deny.
2. An explicit deny in any applicable policy always wins.
3. The request must be allowed by every guardrail in play — SCPs, permissions boundaries and session policies. Guardrails never grant anything on their own.
4. Within those limits, an allow in an identity-based or resource-based policy grants access in the same account.
5. For cross-account access, both sides must allow it: the caller’s identity policy and the resource policy (or a role trust policy the caller can assume).

Practical example: a developer has s3:* in their identity policy, but the account’s SCP denies deleting objects in production buckets. The delete fails, because the explicit deny overrides the allow.

Note: Use the IAM policy simulator and CloudTrail’s access-denied events when debugging. Most “I have admin but it still fails” problems are an SCP, a boundary, or a KMS key policy.

AWS Security Token Service (STS) issues short-lived credentials — an access key ID, a secret key and a session token — that expire automatically. It is the mechanism behind roles, federation and cross-account access, and the reason long-lived access keys are rarely needed.

Cross-account assumption, step by step:

1. In the target account (say, Production), create a role with a trust policy naming who may assume it — for example, a specific role in the Tooling account.
2. Attach a permissions policy to that role defining what it can do in Production.
3. In the Tooling account, the caller needs an identity policy allowing sts:AssumeRole on that role’s ARN.
4. The caller calls AssumeRole, receives temporary credentials, and uses them to act in Production. CloudTrail records the session and the original identity.

Both halves are required: the trust policy says who can come in, the permissions policy says what they can do once inside.

Related STS operations:

• AssumeRoleWithWebIdentity — exchanges an OIDC token for credentials. This is how GitHub Actions deploys without stored keys and how EKS pods get IAM roles.
• AssumeRoleWithSAML — for corporate identity-provider federation. For people, IAM Identity Center now wraps this for you.
• GetSessionToken — temporary credentials for an IAM user, often to enforce MFA.

Security details worth mentioning: use an external ID in the trust policy when a third party assumes your role, to prevent the confused-deputy problem. Set a sensible maximum session duration, and add conditions such as aws:PrincipalOrgID or MFA in trust policies.

Note: Role chaining — assuming a role from an assumed-role session — limits the session to one hour, which surprises people running long automation jobs.

Everyone agrees with least privilege; the hard part is getting there without blocking developers. A practical approach is start broad in development, measure, then tighten, with guardrails that prevent the worst mistakes.

• No long-lived keys for people: use IAM Identity Center with short sessions and MFA. Workloads use roles — instance profiles, ECS task roles, Lambda execution roles, OIDC for CI/CD.
• Generate policies from real usage: IAM Access Analyzer can generate a policy from the actions a role actually called in CloudTrail. Last-accessed information shows services and actions never used, so you can remove them.
• Scope resources and actions: avoid "Resource": "*" and s3:*. Name the specific bucket, table or queue ARN and only the actions needed.
• Use conditions: restrict by aws:RequestedRegion, require MFA for sensitive actions, limit to your organisation with aws:PrincipalOrgID, or to a VPC endpoint with aws:SourceVpce.
• Attribute-based access control: tag principals and resources (for example team=payments) and write policies that match tags, so one policy scales across many teams.
• Guardrails that cannot be bypassed: SCPs to deny disabling CloudTrail, leaving approved regions, or deleting log buckets; permissions boundaries when developers create their own roles.
• Continuous review: Access Analyzer findings for resources shared outside the account, unused-access findings, and periodic review of admin role membership.

Separate by blast radius: separate accounts for production and development give a hard boundary that no policy mistake can cross.

Note: Break-glass access matters too — a tightly controlled, well-monitored emergency role, so least privilege does not become a reason nobody can fix an outage.

A standard production VPC separates tiers by subnet and repeats each tier in at least two, ideally three, availability zones.

1. Plan the address space. Choose a CIDR block, such as a /16, that does not overlap with other VPCs or the on-premises network — overlap blocks peering and VPN later. Leave spare ranges for growth, and remember AWS reserves five addresses in every subnet.

2. Create subnet tiers per AZ:

• Public subnets — for load balancers and NAT gateways only. Their route table has 0.0.0.0/0 pointing to the internet gateway. That route is what makes a subnet public.
• Private application subnets — EC2, ECS tasks or Lambda functions. Their default route points to a NAT gateway so they can make outbound calls without being reachable from the internet.
• Private data subnets — RDS, ElastiCache. Often no internet route at all.

3. Routing and NAT. A NAT gateway lives in one AZ. For resilience, run one per AZ and give each private subnet a route table pointing at the NAT in its own zone; a single shared NAT is cheaper but becomes a cross-zone dependency. Add gateway endpoints for S3 and DynamoDB so that traffic skips the NAT entirely.

4. Security layers. Security groups that reference each other — the database accepts traffic only from the app security group, and the app only from the ALB security group. NACLs as a coarse, stateless subnet-level backstop.

5. Visibility. Enable VPC Flow Logs, and use Session Manager instead of bastion hosts so no SSH port is exposed.

Note: NAT gateway data-processing charges are a frequent surprise on the bill. Endpoints for heavy-traffic services and keeping chatty traffic inside the VPC keep them under control.

Both let resources in a VPC reach AWS services privately, without an internet gateway or NAT, but they work in different ways.

When to use which:

• Gateway endpoints for S3 and DynamoDB inside the VPC — almost always. They are free and remove NAT gateway processing charges for heavy S3 traffic.
• Interface endpoints for services like Secrets Manager, ECR, CloudWatch Logs, STS and SSM, especially in subnets with no internet access at all. They are also the choice when on-premises systems need private access to S3.

DNS matters: with private DNS enabled on an interface endpoint, the normal service hostname resolves to the private IP, so applications need no code change. For on-premises clients you need Route 53 Resolver inbound endpoints to resolve those names.

Locking it down: an endpoint policy can limit which buckets or actions are reachable through the endpoint, and a bucket policy with the aws:SourceVpce condition can insist that access comes only through your endpoint — a common data-exfiltration control.

Note: A private ECS or EKS cluster with no NAT needs interface endpoints for ECR API, ECR Docker, CloudWatch Logs and STS, plus the S3 gateway endpoint for image layers.

All three connect workloads across VPCs, but they solve different problems.

• VPC peering — a direct, one-to-one connection between two VPCs, in the same or different accounts and regions.
  • No hourly charge; you pay for data transfer.
  • Not transitive: if A peers with B and B with C, A cannot reach C through B.
  • CIDR ranges must not overlap.
  • Fine for a handful of VPCs, but a full mesh grows quickly — ten VPCs need 45 peering connections, each with route-table entries.
• Transit Gateway — a regional hub that VPCs, VPNs and Direct Connect attach to.
  • Transitive routing through a central point, so each VPC needs one attachment.
  • Multiple TGW route tables allow segmentation — production and development can share the hub without reaching each other.
  • Charged per attachment per hour and per GB processed.
  • Peer transit gateways across regions for a global network.
• PrivateLink — exposes a specific service, not a whole network.
  • The provider puts the service behind a Network Load Balancer; consumers create interface endpoints in their VPCs.
  • Traffic is one-directional, consumer to service, and overlapping CIDRs do not matter.
  • Ideal for SaaS offerings or a shared internal platform service consumed by many teams.

How to choose: two or three VPCs that need full connectivity — peering. Many VPCs plus on-premises connectivity, with central inspection or segmentation — Transit Gateway. One service consumed by many VPCs, possibly with clashing address ranges — PrivateLink.

Note: Mention IP address planning. Overlapping CIDRs are the most common reason a later connectivity design fails, and they are painful to fix once workloads are running.

Both connect an on-premises network to AWS; they differ in the path the traffic takes, and therefore in performance, setup time and cost.

• Site-to-Site VPN
  • An encrypted IPsec connection over the public internet, terminating on a virtual private gateway or a Transit Gateway.
  • Each connection has two tunnels in different AZs for redundancy; configure both on your router.
  • Set up in hours, with low fixed cost.
  • Latency and throughput depend on the internet path, so performance varies, and per-tunnel throughput is limited.
• Direct Connect
  • A dedicated private connection from your data centre or a colocation facility to AWS, directly or through a partner.
  • Consistent latency and high bandwidth; data transfer out over it is cheaper than over the internet.
  • Takes weeks to provision, because a physical circuit is involved.
  • Not encrypted by default. Use MACsec where supported, or run a VPN over Direct Connect if encryption in transit is required.
  • Uses virtual interfaces — private VIFs for VPCs, transit VIFs for Transit Gateway, public VIFs for AWS public endpoints — and a Direct Connect gateway to reach many VPCs and regions.

How to choose: start with VPN for quick, modest or temporary connectivity. Move to Direct Connect for large, steady data transfer, latency-sensitive traffic, or when predictable performance is contractual.

Resilience: a single Direct Connect link is a single point of failure. Production designs use two connections at different Direct Connect locations, or at minimum a Site-to-Site VPN as a backup path with BGP preferring Direct Connect.

Note: Plan non-overlapping IP ranges between on-premises and AWS before anything else. Routing cannot fix two networks that use the same addresses.

EC2 offers the same instances under different commercial terms. The skill is matching each part of the workload to the cheapest option that still meets its availability needs.

• On-Demand — pay per second or hour with no commitment. Most flexible, most expensive. Right for unpredictable or short-lived workloads.
• Savings Plans — commit to a fixed hourly spend for one or three years in exchange for a discount. Compute Savings Plans apply across instance families, sizes, regions, Fargate and Lambda; EC2 Instance Savings Plans give a bigger discount but are tied to one family in one region.
• Reserved Instances — the older commitment model, tied to instance attributes. Standard RIs give the larger discount; Convertible RIs can be exchanged. Zonal RIs also reserve capacity. RIs still matter for services such as RDS, ElastiCache and OpenSearch.
• Spot Instances — spare capacity at a steep discount, but AWS can reclaim them with a two-minute warning. Right for stateless, fault-tolerant work: batch jobs, CI runners, rendering, and part of a stateless web fleet.
• Dedicated Hosts and Dedicated Instances — physical isolation, mainly for licensing tied to sockets or cores, or compliance rules.
• On-Demand Capacity Reservations — guarantee capacity in a specific AZ without a long-term commitment, useful before a known event.

A sensible blend:

1. Right-size first — committing to oversized instances locks in waste.
2. Cover the steady baseline, the capacity that runs all year, with a Compute Savings Plan.
3. Handle daily peaks with On-Demand through Auto Scaling.
4. Put fault-tolerant tiers on Spot using a mixed-instances Auto Scaling group across several instance types and AZs, so a single capacity pool running dry does not hurt you.

Note: Graviton (ARM) instances often give better price-performance for workloads that can run on ARM, and that saving stacks with any commitment discount.

An Auto Scaling group (ASG) keeps a fleet of EC2 instances at the right size and replaces unhealthy ones automatically.

Core pieces:

• Launch template — the AMI, instance type, security groups, IAM instance profile and user data for new instances. Versioned, so you can roll forward and back.
• Minimum, desired and maximum capacity — the ASG keeps the actual count at desired, always within min and max.
• Subnets across AZs — the ASG balances instances across zones and rebalances after a zone recovers.
• Health checks — EC2 status checks by default; enable ELB health checks so an instance that is running but failing the load balancer check is replaced.

Scaling policies:

• Target tracking — keep a metric at a target, for example average CPU at 50% or requests per target at 1,000. The simplest and usually the best starting point.
• Step scaling — add or remove different amounts depending on how far an alarm threshold is breached. Useful when you need an aggressive response to large spikes.
• Scheduled scaling — change capacity at known times, such as office hours or a planned sale.
• Predictive scaling — uses historical patterns to launch capacity ahead of recurring daily or weekly peaks.

Features that make it production-ready:

• Instance warm-up, so new instances are not counted in metrics until they are ready, preventing over-scaling.
• Lifecycle hooks to run actions during launch or termination, such as draining work or pushing logs.
• Instance refresh to roll out a new AMI gradually, and warm pools of pre-initialised instances for slow-booting applications.
• Mixed instances policies to combine On-Demand and Spot across several instance types.

Note: Auto Scaling only helps a stateless tier. Keep sessions in ElastiCache or DynamoDB, not on the instance, or scale-in will log users out.

Elastic Load Balancing offers several load balancer types that work at different layers of the network stack.

Application Load Balancer: content-based routing, so one ALB can front many services — /api/* to one target group, /images/* to another. Supports WebSockets, HTTP/2, redirects, fixed responses, built-in authentication with OIDC or Cognito, AWS WAF, and targets that are instances, IP addresses or Lambda functions. The default for web traffic.

Network Load Balancer: handles very high connection rates with low latency, preserves the client source IP, and provides static IPs — useful when a partner must allow-list your addresses. Also the front end for PrivateLink services, and for TCP or UDP protocols such as MQTT, gaming or custom binary protocols.

Gateway Load Balancer: transparently inserts third-party virtual appliances — firewalls, IDS or IPS — into the traffic path and scales them, using GENEVE encapsulation.

Classic Load Balancer is legacy; migrate away from it.

Details interviewers probe: cross-zone load balancing is on by default for ALB but off by default for NLB. TLS can terminate at the load balancer with certificates from ACM. Health checks and deregistration delay control how gracefully targets leave during deployments.

Note: A common pattern for a fixed IP in front of HTTP routing is an NLB forwarding to an ALB target.

S3 storage classes trade a lower storage price against retrieval cost, retrieval time, minimum storage duration or resilience.

• S3 Standard — frequently accessed data, stored across multiple AZs, no retrieval fee.
• S3 Intelligent-Tiering — moves objects between access tiers automatically based on usage, for a small monitoring fee per object. The best default when access patterns are unknown or changing.
• S3 Standard-IA — infrequently accessed but needed quickly. Cheaper storage, a per-GB retrieval fee, and a minimum storage duration and object size charge.
• S3 One Zone-IA — like Standard-IA but in a single AZ. Only for data you can recreate, such as secondary copies or thumbnails.
• S3 Glacier Instant Retrieval — archive data accessed rarely but needed in milliseconds, such as old medical images.
• S3 Glacier Flexible Retrieval — archives retrieved in minutes to hours.
• S3 Glacier Deep Archive — the cheapest storage, with retrieval in hours. For compliance records kept for years.
• S3 Express One Zone — very low-latency storage in a single AZ for performance-critical workloads such as ML training.

Lifecycle policies automate the movement. Rules filtered by prefix or tag can:

• Transition objects, for example to Standard-IA after 30 days and to Glacier Deep Archive after a year.
• Expire objects, such as deleting temporary exports after seven days.
• Expire noncurrent versions in versioned buckets — otherwise old versions accumulate silently.
• Abort incomplete multipart uploads — orphaned parts are billed but invisible in normal listings.

Watch the fine print: the infrequent-access and Glacier classes have minimum storage durations, so deleting early still bills the minimum, and very small objects can cost more in them than in Standard.

Note: Use S3 Storage Lens or Storage Class Analysis to see actual access patterns before writing lifecycle rules.

Consistency: S3 provides strong read-after-write consistency for all GET, PUT, LIST and DELETE operations. Once a write succeeds, any later read or list returns the new data. Older material describing eventual consistency for overwrites is out of date. There is still no locking, so two simultaneous writers to the same key simply means the last write wins — coordinate writers in the application or use conditional writes.

S3’s durability protects against hardware failure, not against people and software. These features cover the rest:

• Versioning — every overwrite keeps the previous version, and a delete adds a delete marker instead of removing data. You can restore any earlier version. Pair it with lifecycle rules that expire noncurrent versions, or storage cost grows without anyone noticing.
• MFA Delete — requires MFA to permanently delete versions or change versioning state.
• Replication — Cross-Region Replication and Same-Region Replication copy objects asynchronously to another bucket, possibly in another account. Versioning must be enabled on both buckets. It replicates new objects; use S3 Batch Replication for existing ones. Replication Time Control adds a predictable replication time for compliance. Replicating into a separate account with restricted access protects against a compromised source account.
• Object Lock — write-once-read-many (WORM) protection. Governance mode lets specially permitted users override the retention; compliance mode means nobody, including the root user, can delete the object until retention expires. Legal holds block deletion indefinitely until removed. This is the strongest defence against ransomware and a common regulatory requirement.

Putting it together: for critical data, enable versioning, replicate to a locked-down bucket in another account and region, apply Object Lock where retention rules require it, and use AWS Backup for centrally managed, auditable backups.

Note: Replication is not a backup on its own — deleting objects with versioning disabled can propagate the loss. Versioning and Object Lock are what make recovery possible.

S3 encrypts every new object at rest by default, so the real questions are who controls the key and how access to it is audited.

• SSE-S3 — S3 manages the keys entirely. Zero configuration and no extra cost, now the default. Anyone with S3 read permission can read the data.
• SSE-KMS — objects are encrypted with a key in AWS KMS, either the AWS managed key or your own customer managed key. Benefits:
  • A second layer of access control: the caller needs S3 permission and permission to use the KMS key, so a leaked bucket policy alone does not expose data.
  • Every key use is logged in CloudTrail.
  • You control rotation, and can disable the key to make data unreadable.
  KMS requests cost money and count against request quotas, so enable S3 Bucket Keys, which cut KMS calls dramatically for busy buckets.
• DSSE-KMS — two independent layers of encryption with KMS, for regulations that specifically require dual-layer encryption.
• SSE-C — you supply the key with every request and S3 does not store it. You carry the burden of key management; losing the key means losing the data.
• Client-side encryption — data is encrypted before it leaves your application, for example with the AWS Encryption SDK, so S3 and AWS never see plaintext. Use it when the threat model includes the storage provider or when data must be protected end-to-end.

Encryption in transit: enforce HTTPS with a bucket policy that denies requests where aws:SecureTransport is false.

How to choose: SSE-S3 for general, non-sensitive data. SSE-KMS with a customer managed key for anything regulated, personal or financial, where you need auditability and separation of duties. Client-side when you must not trust the service with plaintext.

Note: Cross-account access to SSE-KMS objects fails unless the KMS key policy also grants the other account. This is a classic interview troubleshooting scenario.

A presigned URL gives time-limited access to a specific S3 object without making the bucket public and without giving the user AWS credentials. It is the standard way to let a browser or mobile app download a private file or upload directly to S3.

How it works: your backend, running with credentials that are allowed to access the object, signs the request parameters — bucket, key, operation and expiry — using Signature Version 4. The signature is embedded in the URL’s query string. S3 validates it when the URL is used and acts with the signer’s permissions.

url = s3.generate_presigned_url(
    'get_object',
    Params={'Bucket': 'invoices-prod', 'Key': 'inv/1234.pdf'},
    ExpiresIn=300)

Common uses:

• Downloading private documents such as invoices or certificates after the app has checked the user is entitled to them.
• Direct uploads from the browser, which avoids streaming large files through your servers. A presigned POST can also enforce conditions such as content type and maximum file size.

Security considerations:

• Anyone holding the URL can use it until it expires — it is a bearer token. Keep expiry short, often minutes.
• The URL stops working early if the signer loses permission, or if it was signed with temporary credentials that expire first — a common cause of mysterious failures.
• Sign with a role that has only the permissions needed for this purpose, so a URL cannot be crafted for arbitrary objects.
• Generate URLs only after authorisation checks in your application, and never let the client choose an arbitrary key.
• For uploads, validate or scan the file after it lands — for example with an S3 event triggering a Lambda check.
• Serve them over HTTPS, and do not log full URLs in places where they could be reused.

Note: For serving many private files to a website, CloudFront signed URLs or signed cookies are often a better fit, adding caching and a single signing key.

DynamoDB design starts from the access patterns, not the entities. List every query the application needs first, then design keys that answer each one with a Query or GetItem — never a Scan on a hot path.

• Partition key — hashed to decide which partition stores the item. Must have high cardinality and spread requests evenly: customerId is good, status is bad.
• Sort key — orders items that share a partition key, enabling range queries such as begins_with or between. A composite sort key like ORDER#2026-09-12#8812 lets one query fetch a customer’s orders for a date range.
• Global secondary index (GSI) — a different partition and sort key over the same data, for another access pattern such as “orders by status”. Can be added at any time, has its own capacity, and is eventually consistent only.
• Local secondary index (LSI) — same partition key, different sort key. Must be defined when the table is created, supports strongly consistent reads, and limits each item collection’s size. Use sparingly.

Single-table design: storing several entity types in one table with generic key names such as PK and SK lets related items be fetched in one query. It is powerful but harder to read, so apply it where the access patterns are well understood.

Avoiding hot partitions:

• Choose keys with even request distribution; one celebrity customer or a single date can concentrate traffic.
• Use write sharding — append a random or calculated suffix to hot keys and query the shards in parallel.
• Put DAX or a cache in front of heavily read items.
• Adaptive capacity helps with uneven load, but it cannot rescue a fundamentally skewed key.

Capacity modes: on-demand for unpredictable or new workloads; provisioned with auto scaling for steady, predictable traffic at lower cost.

Note: Items are limited in size, so store large blobs in S3 and keep a pointer in DynamoDB. Use TTL to expire session or temporary data automatically.

They solve different problems: Multi-AZ is for availability, read replicas are for read scaling. Confusing them is one of the most common interview mistakes.

• Multi-AZ (instance deployment)
  • A synchronous standby in another AZ, so no committed transaction is lost on failover.
  • If the primary fails or its AZ has trouble, RDS fails over automatically by repointing the endpoint’s DNS name to the standby, typically within a minute or two.
  • The standby cannot serve reads. It exists only for failover, and also makes patching and backups less disruptive.
  • A newer Multi-AZ DB cluster option for MySQL and PostgreSQL has two readable standbys and faster failover.
• Read replicas
  • Asynchronous copies that serve read-only queries, so there can be replication lag.
  • Used to offload reporting and read-heavy traffic; the application must send reads to the replica endpoint.
  • Can be in another region for lower-latency reads or as a DR copy.
  • Promotion to a standalone primary is manual and breaks replication.

How Aurora differs:

• Compute and storage are separated. The cluster volume keeps six copies of data across three AZs and heals itself, so storage durability does not depend on the instances.
• Replicas share that storage, so replica lag is typically very low, and the replicas are also the failover targets — availability and read scaling come together.
• A reader endpoint load-balances across replicas; the cluster endpoint always points to the writer.
• Aurora Global Database replicates to other regions with low lag for regional DR, and Aurora Serverless v2 scales capacity in fine-grained steps for variable workloads.

Note: Multi-AZ does not protect against a bad DELETE or corruption — it replicates the mistake instantly. Automated backups with point-in-time recovery are what cover that.

A cold start happens when Lambda has no idle execution environment ready for a request and must create one. It adds latency to that request only; later requests reuse the warm environment.

What happens during a cold start:

1. Lambda provisions a new micro-VM execution environment.
2. It downloads your code package or container image.
3. It starts the language runtime.
4. It runs your initialisation code — everything outside the handler, such as imports, SDK clients and configuration loading.

Cold starts occur on the first request after deployment, when traffic scales up, and after environments are recycled following idle periods. The Init Duration field in the CloudWatch REPORT log line shows exactly how long they take.

Factors that make them worse: heavy runtimes and frameworks (large Java or .NET applications with dependency injection), large deployment packages, and slow work during initialisation such as fetching many secrets.

Ways to reduce them:

• Lean initialisation — import only what you use, trim dependencies, bundle and tree-shake JavaScript, and lazy-load rarely used libraries.
• More memory — Lambda allocates CPU in proportion to memory, so initialisation runs faster. This often costs little because duration drops.
• Provisioned concurrency — keeps a set number of environments initialised and ready. Use it for latency-sensitive APIs, scheduled up for business hours.
• SnapStart — snapshots the initialised environment and restores from it, for supported runtimes such as Java. Code must handle uniqueness correctly, for example regenerating random seeds after restore.
• Reuse connections — create SDK and database clients outside the handler so warm invocations reuse them; use RDS Proxy for relational databases.

Note: For many asynchronous workloads — queue processing, file processing — cold starts do not matter at all. Measure before optimising, and focus on the synchronous user-facing paths.

Concurrency is the number of requests a function is handling at the same moment. Each execution environment handles one request at a time, so concurrency is roughly requests per second multiplied by average duration in seconds. A function receiving 200 requests per second that each take half a second needs about 100 concurrent environments.

Limits: every account has a regional concurrency quota shared by all functions, which can be raised through Service Quotas. Functions also scale up at a limited rate, so a sudden surge can be throttled even below the quota.

Reserved concurrency:

• Guarantees a function a slice of the account pool and caps it at that number.
• Used to protect critical functions from noisy neighbours, and to protect downstream systems — capping a function at 20 protects a database that can only handle 20 connections.
• Setting it to zero effectively disables the function, a handy emergency switch.
• No extra charge.

Provisioned concurrency:

• Keeps a number of environments already initialised, eliminating cold starts for that capacity.
• Charged for as long as it is configured, whether used or not. Can be scaled on a schedule or with Application Auto Scaling.
• Applied to a version or alias, not $LATEST.

What happens when throttled depends on the invocation type:

• Synchronous (API Gateway, direct invoke) — the caller gets a throttling error and must retry.
• Asynchronous (S3, SNS, EventBridge) — Lambda queues and retries for a period, then sends the event to a failure destination or dead-letter queue if configured.
• Event source mappings (SQS, Kinesis) — polling slows down. For SQS, set maximum concurrency on the mapping rather than reserved concurrency, to limit parallelism without messages bouncing back to the queue.

Note: Monitor the ConcurrentExecutions and Throttles metrics, and alarm on throttles for critical functions.

Amazon API Gateway is a managed front door for APIs, handling routing, authorisation, throttling and TLS. It offers three API types.

• REST APIs — the feature-rich option. Request and response transformation, request validation, API keys with usage plans for per-customer quotas, response caching, AWS WAF integration, private APIs reachable only from a VPC, and edge-optimised or regional endpoints.
• HTTP APIs — simpler, lower latency and cheaper. Native JWT authorisers, CORS support and Lambda or HTTP proxy integrations. Choose them when you do not need REST-only features.
• WebSocket APIs — persistent two-way connections for chat, live dashboards and notifications. API Gateway manages the connections and routes messages to Lambda; the backend pushes messages back through a connection callback URL.

Securing an API:

• Authorisation
  • JWT or Cognito authorisers — validate tokens from Cognito or any OIDC provider.
  • Lambda authorisers — custom logic, such as validating an in-house token or checking a tenant. Cache results to reduce latency and cost.
  • IAM authorisation — callers sign requests with SigV4. Ideal for service-to-service calls within AWS.
• Throttling at stage, route and usage-plan level to protect backends.
• AWS WAF on REST APIs for rate limiting by IP, managed rule groups and geo-blocking.
• Private APIs with resource policies restricting access to specific VPC endpoints.
• Mutual TLS on custom domains when clients must present certificates.

Limits to remember: integrations have a timeout of around 29 seconds by default, and payload sizes are limited. Long-running work should be accepted, queued, and reported via a status endpoint or WebSocket.

Note: For a single Lambda behind a simple endpoint, Lambda function URLs or an ALB can be simpler alternatives — mention them to show you know when not to use API Gateway.

When a consumer receives a message from SQS, the message is not deleted — it becomes invisible to other consumers for the visibility timeout. The consumer must explicitly delete it after processing. If it does not, because it crashed or took too long, the message reappears and another consumer receives it.

Setting the timeout correctly:

• It must be longer than the worst-case processing time; otherwise a slow message is picked up twice while the first attempt is still running.
• For long or variable jobs, the consumer can call ChangeMessageVisibility to extend it as a heartbeat.
• With Lambda, AWS recommends a queue visibility timeout of several times the function timeout, to allow for retries and batching.

Related settings:

• Long polling — set a receive wait time of up to 20 seconds so consumers wait for messages instead of making many empty, billable requests.
• Dead-letter queue — after maxReceiveCount failed attempts, move the message aside instead of retrying a poison message forever. Alarm on DLQ depth, and use redrive to reprocess once fixed.
• Partial batch responses — with Lambda, report only the failed message IDs so successful messages in the batch are not reprocessed.

Why idempotency is essential: standard queues deliver at least once, and timeouts, retries and crashes after processing but before deletion all cause duplicates. Your consumer must produce the same result if it handles a message twice.

Techniques:

• Include a unique idempotency key, such as an order ID, in every message.
• Record processed keys with a conditional write — for example a DynamoDB PutItem with attribute_not_exists — and skip keys already seen.
• Design operations as naturally idempotent: “set status to PAID” rather than “add 100 to the balance”.
• Use Powertools for AWS Lambda’s idempotency utility, which implements this pattern for you.

Note: FIFO queues add deduplication within a time window and strict ordering per message group, but they do not remove the need for idempotent consumers.

The main risk with CloudFormation is not a failed deployment — it rolls back — but a successful one that replaces or deletes something important. A few features address exactly that.

• Change sets — preview what an update will do before executing it. Look at the Replacement column: renaming an RDS instance identifier or changing certain properties replaces the resource, which for a database means a new, empty one. Make change-set review a mandatory pipeline step for production.
• DeletionPolicy — set Retain or Snapshot on stateful resources such as databases, S3 buckets and DynamoDB tables, so removing them from a template or deleting the stack does not destroy the data. UpdateReplacePolicy does the same when an update forces replacement.
• Stack policies — a JSON document that denies updates to specified resources unless explicitly overridden, preventing accidental replacement of critical resources.
• Termination protection — stops the whole stack being deleted by accident.
• Rollback triggers — link CloudWatch alarms to the stack; if an alarm fires during or shortly after the update, CloudFormation rolls back automatically. This catches changes that deploy cleanly but break the application.
• Drift detection — before updating, check whether someone changed resources manually, because CloudFormation may overwrite those changes or fail.

Pipeline practices:

• Run cfn-lint and a policy-as-code check such as cfn-guard or Checkov on every pull request.
• Deploy the same template to development and staging first, with parameters for environment differences.
• Keep stacks small and split by lifecycle — networking, data and application stacks change at different rates, and a smaller blast radius makes each update safer.
• Use StackSets to roll baseline stacks across many accounts and regions in controlled waves, with failure tolerance settings.

Note: If a stack gets stuck in UPDATE_ROLLBACK_FAILED, you can continue the rollback while skipping specific resources — knowing this recovery path impresses interviewers.

The AWS Cloud Development Kit lets you define infrastructure in a general-purpose language such as TypeScript, Python, Java, C# or Go. Running cdk synth turns your code into CloudFormation templates, and cdk deploy deploys them, so CloudFormation remains the deployment engine underneath.

Structure: an app contains one or more stacks, and stacks contain constructs.

• L1 constructs — one-to-one mappings of CloudFormation resources, named with a Cfn prefix such as CfnBucket. Complete but low-level.
• L2 constructs — curated abstractions with sensible, secure defaults and helper methods. A Bucket can block public access and enforce SSL with simple properties, and grantRead() writes the least-privilege IAM policy for you.
• L3 constructs (patterns) — several resources wired together, such as an ALB-fronted Fargate service in a few lines.

const bucket = new s3.Bucket(this, 'Uploads', {
  encryption: s3.BucketEncryption.KMS_MANAGED,
  blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
  enforceSSL: true,
});
bucket.grantRead(processorFn);

Benefits: loops, conditions, types and IDE support; reusable constructs shared across teams as packages; unit tests on synthesised templates; and far less boilerplate for IAM and networking.

Drawbacks: abstraction can hide what is really created, so always review cdk diff and the synthesised template. CloudFormation limits and behaviours still apply, and code that generates infrastructure can become too clever to follow.

Compared with alternatives:

• CloudFormation — declarative YAML or JSON. Explicit and easy to audit, but verbose and repetitive at scale.
• Terraform — its own language (HCL), a large provider ecosystem covering many clouds and SaaS tools, and a state file you must store and lock securely. Changes are previewed with terraform plan.

Note: Every account and region must be bootstrapped with cdk bootstrap once, which creates the asset bucket and deployment roles the CDK needs.

They are often confused because all three collect data about your account, but each answers a different question.

• CloudWatch — operational monitoring. Service metrics such as CPU and latency, custom application metrics, log groups with Logs Insights queries, alarms that notify or trigger scaling, and dashboards. Use it to detect and diagnose problems.
• CloudTrail — an audit log of API activity: the identity, source IP, time, request parameters and result. Management events are recorded by default for recent activity; create an organisation trail to keep them long-term in a central, locked-down S3 bucket with log file validation. Data events, such as S3 object reads, are optional and cost extra.
• AWS Config — records the configuration of resources over time and their relationships. Config rules evaluate compliance continuously — encrypted volumes, no public buckets, required tags — and can trigger automatic remediation through Systems Manager.

One scenario, three views: someone opens SSH to 0.0.0.0/0 on a production security group.

• Config shows the security group’s configuration changed and flags it non-compliant, optionally reverting it automatically.
• CloudTrail shows the AuthorizeSecurityGroupIngress call, which role made it and from where.
• CloudWatch could alarm on a metric filter over CloudTrail logs, or EventBridge could react to the event in near real time.

Note: GuardDuty builds on these by analysing CloudTrail, VPC Flow Logs and DNS logs for threats — and Security Hub aggregates findings from all of them.

AWS Key Management Service creates and controls cryptographic keys, stored in hardware security modules. The key material of a KMS key never leaves KMS unencrypted; you send data or data keys to KMS to be encrypted or decrypted, and every use is logged in CloudTrail.

Types of KMS keys:

• Customer managed keys — you create them and control the key policy, rotation, and enabling or disabling. Use these for sensitive data.
• AWS managed keys — created by a service on your behalf, such as aws/s3. Convenient, but you cannot edit their policies or share them across accounts.
• AWS owned keys — used internally by services and not visible in your account.

Envelope encryption is how KMS encrypts large amounts of data efficiently:

1. The application calls GenerateDataKey. KMS returns a plaintext data key and the same key encrypted under the KMS key.
2. The application encrypts the data locally with the plaintext data key, then discards that plaintext key from memory.
3. It stores the encrypted data key alongside the encrypted data.
4. To decrypt, it sends the encrypted data key to KMS with Decrypt, gets the plaintext data key back, and decrypts the data locally.

Why do it this way: KMS only encrypts small payloads directly, bulk data never crosses the network to KMS, and re-keying means re-encrypting small data keys rather than all data. S3, EBS and RDS use this pattern internally.

Access control: the key policy is the primary control — IAM policies only work if the key policy allows it. Grants give narrowly scoped, programmatic permissions, typically to AWS services acting on your behalf. An encryption context binds extra authenticated data to each operation and appears in CloudTrail for auditing.

Rotation: automatic rotation creates new key material on a schedule while keeping old material to decrypt existing data, so nothing needs re-encrypting.

Note: Scheduling a key for deletion enforces a waiting period. Deleting a KMS key makes all data encrypted under it permanently unrecoverable, so disable keys first and watch for failures.

Amazon Route 53 is AWS’s DNS service. Routing policies decide which answer it returns for a query, which makes DNS a tool for traffic management and failover.

• Simple — one record with one or more values and no health checks. For a single resource.
• Weighted — split traffic by percentage across records, for example 90/10 between the current and a new version for a canary release or a gradual migration.
• Latency-based — returns the record in the AWS region that gives the user the lowest measured latency. For multi-region applications serving a global audience.
• Failover — active-passive. Traffic goes to the primary while its health check passes and to the secondary when it fails, for example a static maintenance site in S3 or a DR region.
• Geolocation — routes by the user’s continent, country or state. Used for content localisation, legal restrictions or data-residency requirements. Always define a default record for unmatched locations.
• Geoproximity — routes by physical distance between users and resources, with a bias to expand or shrink a region’s share of traffic.
• Multivalue answer — returns up to eight healthy records at random, a simple form of client-side load balancing with health checks.
• IP-based — routes based on the client’s IP range, useful when you know which ISP or network your users come from.

Supporting features:

• Health checks on endpoints, or on CloudWatch alarms, drive failover and remove unhealthy records.
• Alias records point to AWS resources such as ALBs, CloudFront and S3 websites, work at the zone apex (example.com) where CNAMEs cannot, and are free to query.
• Policies can be nested, such as latency-based between regions with weighted records within each.

Note: DNS failover is limited by TTLs and client caching. Use low TTLs on records that must fail over, and remember some clients ignore TTLs — for faster regional failover, look at Global Accelerator.

The Well-Architected Framework is AWS’s set of best practices for evaluating workloads. It is organised into six pillars, each with design principles and review questions.

1. Operational Excellence — running and improving systems. Principles: perform operations as code, make small reversible changes, anticipate failure, learn from operational events. Example: deployments through pipelines with automated rollback, and runbooks that are automated rather than manual.
2. Security — protecting data, systems and assets. Principles: a strong identity foundation with least privilege, traceability, security at every layer, encryption in transit and at rest, and preparing for incidents. Example: IAM roles instead of keys, CloudTrail everywhere, GuardDuty enabled.
3. Reliability — performing correctly and recovering from failure. Principles: automatically recover, test recovery procedures, scale horizontally, stop guessing capacity, manage change through automation. Example: Multi-AZ deployments, backups that are restored in regular tests.
4. Performance Efficiency — using resources efficiently as demand changes. Principles: use managed and serverless services, go global in minutes, experiment more often. Example: choosing DynamoDB for key-value access at scale, caching with CloudFront and ElastiCache.
5. Cost Optimization — delivering value at the lowest price. Principles: adopt a consumption model, measure efficiency, attribute expenditure. Example: tagging for cost allocation, right-sizing, Savings Plans, turning off non-production at night.
6. Sustainability — minimising environmental impact. Principles: understand your impact, maximise utilisation, use managed services and efficient hardware. Example: Graviton instances, deleting unused data, scaling to demand.

In practice: teams run reviews with the Well-Architected Tool in the console, answering pillar questions per workload. The output is a list of high- and medium-risk issues and an improvement plan. Lenses add guidance for specific domains such as serverless, SaaS or machine learning.

Note: The pillars involve trade-offs — more reliability usually costs more. A strong answer explains how you balanced two pillars for a real workload, not just the list.

Disaster recovery strategies trade cost against two targets: RTO (recovery time objective — how long you can be down) and RPO (recovery point objective — how much data you can lose). Start from the business’s targets, then choose the cheapest strategy that meets them.

• Backup and restore — the cheapest. Back up data to another region with AWS Backup, cross-region snapshot copies or S3 replication, and rebuild infrastructure from code when disaster strikes. RTO and RPO measured in hours. Suitable for internal or non-critical systems.
• Pilot light — the core data layer runs continuously in the recovery region, such as a cross-region database replica, while compute is defined in code but switched off or scaled to zero. On failover, you start and scale the application tier. RTO in tens of minutes, RPO in minutes or less.
• Warm standby — a fully functional but scaled-down copy of production runs in the recovery region and can take traffic immediately, then scales up. RTO in minutes. Because it is always running, it is easier to test continuously.
• Multi-site active-active — full production in two or more regions serving traffic simultaneously, with Route 53 or Global Accelerator distributing users. RTO and RPO near zero, but the highest cost and real complexity around data conflicts and consistency.

Useful building blocks: Aurora Global Database and DynamoDB global tables for cross-region data, S3 Cross-Region Replication, AWS Elastic Disaster Recovery for server replication, Route 53 health checks and failover, and infrastructure as code so the recovery region can be rebuilt consistently.

What separates a strong answer:

• DR also protects against logical disasters — ransomware or a bad deployment — so keep immutable, point-in-time backups, not just replicas.
• Design failover to rely on data-plane operations rather than control-plane calls that might be impaired during a regional event.
• Test regularly with game days; an untested DR plan should be assumed not to work.

Note: Many workloads need only Multi-AZ plus backups. Recommending multi-region active-active by default signals poor cost judgement.

Amazon Elastic Container Service schedules and runs containers. Its key concepts:

• Cluster — a logical grouping of capacity where tasks and services run.
• Task definition — a versioned blueprint: container images, CPU and memory, port mappings, environment variables, secrets, logging configuration, IAM roles and network mode. It is the ECS equivalent of a Kubernetes pod spec.
• Task — a running instance of a task definition, with one or more containers.
• Service — keeps a desired number of tasks running, replaces failed ones, registers them with a load balancer target group, and handles deployments. Supports rolling updates with a deployment circuit breaker for automatic rollback, and blue/green deployments.
• Capacity providers — decide where tasks run: Fargate (serverless, no hosts), Fargate Spot (cheaper, interruptible), or an EC2 Auto Scaling group you manage. A service can mix them with weights.

With the awsvpc network mode, each task gets its own network interface and private IP, so security groups apply per task.

Task role versus task execution role — a classic interview question:

• Task execution role — used by the ECS agent to start the task. It pulls the image from ECR, writes logs to CloudWatch Logs, and fetches secrets from Secrets Manager or Parameter Store to inject as environment variables. Your application code never uses it.
• Task role — assumed by your application containers at runtime. It grants what the code does, such as reading an S3 bucket or writing to a DynamoDB table. The SDK picks up these credentials automatically.

Keeping them separate follows least privilege: the application cannot pull arbitrary images, and the agent cannot read your business data.

EKS equivalent: pods obtain AWS permissions through IAM Roles for Service Accounts or EKS Pod Identity, mapping a Kubernetes service account to an IAM role, rather than relying on the node’s instance role.

Note: “Access denied pulling image” points to the execution role; “access denied calling S3 from my code” points to the task role.

Amazon CloudFront is AWS’s content delivery network. It caches content at edge locations worldwide, so users are served from a nearby location instead of your origin, reducing latency and origin load. It also terminates TLS at the edge and absorbs a large share of DDoS traffic.

Key concepts:

• Origins — where content comes from: an S3 bucket, an ALB, API Gateway, or any HTTP server.
• Cache behaviours — path patterns mapped to origins and settings, for example /static/* cached for a long time from S3 and /api/* passed through to an ALB with no caching.
• Cache policies and origin request policies — control what forms the cache key (headers, cookies, query strings) separately from what is forwarded to the origin. A bloated cache key destroys the hit ratio.
• Invalidation versus versioning — invalidations remove cached objects but take time; versioned file names such as app.3f9c2.js are the better practice for static assets.
• Edge compute — CloudFront Functions for lightweight header and URL manipulation, Lambda@Edge for heavier logic.

Serving private S3 content securely:

1. Keep the bucket fully private with Block Public Access on.
2. Use Origin Access Control (OAC), which signs CloudFront’s requests to S3. Add a bucket policy that allows s3:GetObject only to the CloudFront service principal for your specific distribution. OAC replaces the older Origin Access Identity and supports SSE-KMS encrypted objects.
3. For content restricted to particular users, such as paid courses, use CloudFront signed URLs or signed cookies, generated by your application after checking entitlement.
4. Attach AWS WAF for rate limiting and managed rules, and enforce HTTPS with an ACM certificate — for CloudFront it must be issued in us-east-1.

Note: Monitor the cache hit ratio. A low ratio usually means the cache key includes unnecessary headers or cookies, and fixing that is often the biggest performance and cost win.

Both store configuration values and secrets encrypted with KMS, and both are accessed through IAM-controlled APIs. The differences are in lifecycle features and cost.

• AWS Secrets Manager
  • Built for secrets such as database passwords, API keys and OAuth tokens.
  • Automatic rotation on a schedule, with ready-made rotation functions for RDS, Aurora, Redshift and DocumentDB, or a custom rotation Lambda for other systems. RDS can also manage its master password in Secrets Manager directly.
  • Cross-region replication of secrets for multi-region applications and DR.
  • Resource-based policies for cross-account sharing.
  • Charged per secret per month plus per API call.
• Parameter Store
  • A hierarchical key-value store — /orders/prod/db-host — for configuration and, with the SecureString type, for secrets.
  • The standard tier has no storage charge; the advanced tier adds larger values and parameter policies such as expiration notifications.
  • Version history and change notifications through EventBridge.
  • No built-in rotation — you would have to build it yourself.

How to choose: Secrets Manager for credentials that should be rotated, especially database credentials, or shared across accounts and regions. Parameter Store for plain configuration, feature flags and endpoints, and for low-sensitivity secrets where rotation is not needed and cost matters. Many teams use both.

Consuming them well:

• ECS and EKS can inject secrets at container start; the ECS task execution role needs permission to read them.
• Cache values in the application, or use the Lambda extension for parameters and secrets, to avoid calling the API on every request.
• Grant access per path or per secret ARN, never to all secrets.
• Never put secrets in environment variables of the template, in code, or in container images.

Note: When rotation is enabled, applications must handle a credential change gracefully — for example, by re-reading the secret and reconnecting when authentication fails.