AWS · Advanced interview

Six pillars: Operational Excellence (run and improve systems), Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. The framework is a set of questions and best practices to evaluate and improve architectures against these dimensions, surfacing trade-offs. Senior engineers use it as a structured lens to justify design decisions, not just a checklist.

Deploy across multiple Availability Zones so no single data center is a SPOF: stateless app tiers behind a load balancer in an Auto Scaling group, a Multi-AZ database (RDS Multi-AZ or a distributed store), and replicated/durable storage like S3. Add health checks, automatic failover, and graceful degradation. For higher tiers, extend to multiple regions. The principle is eliminate single points of failure and design for components to fail.

Lambda for event-driven, spiky, or short tasks where you want zero server management and per-request billing (watch cold starts and time limits). Containers (ECS/Fargate or EKS) for long-running services, more control, portability, and steady traffic, with Fargate removing node management. EC2 when you need full OS control, specialized hardware, or sustained workloads where reserved capacity is cheapest. The decision weighs operational overhead, traffic shape, and control.

Access is allowed only if some policy explicitly allows it and no policy explicitly denies it — an explicit deny always wins. Evaluation combines identity policies, resource policies, permission boundaries (a ceiling on what an identity can be granted), SCPs (org-level guardrails), and session policies. Permission boundaries and SCPs let you delegate permission management safely by capping the maximum. Understanding this evaluation order is key to debugging 'why can't I access this' and to secure delegation.

KMS manages encryption keys; the common pattern is envelope encryption — KMS holds a customer master key that encrypts per-object data keys, so you encrypt large data with a fast local data key and only the small data key is protected by KMS. Services (S3, EBS, RDS, etc.) integrate to encrypt at rest with KMS keys, and TLS protects data in transit. You use it for encryption-at-rest everywhere, with key policies and CloudTrail auditing controlling and logging key use.

Enforce least privilege with IAM roles and fine-grained policies (no root for daily use, MFA, no static keys), use SCPs/permission boundaries as guardrails, encrypt data at rest and in transit, keep workloads in private subnets, store secrets in Secrets Manager/Parameter Store, enable logging/auditing (CloudTrail, GuardDuty, Config), and patch/scan. Defense in depth across identity, network, data, and detection — automated and continuously monitored.

Choose a strategy based on RTO/RPO and cost: Backup & Restore (cheap, slow), Pilot Light (core replicated, scale up on failover), Warm Standby (scaled-down running copy), or Active-Active/Multi-Site (full capacity in multiple regions, lowest RTO, highest cost). You replicate data (S3 cross-region, DynamoDB global tables, RDS read replicas), automate failover (Route 53 health checks/DNS), and regularly test. The strategy is a deliberate trade of cost against recovery time and data-loss tolerance.

Decouple components (queues, events) so failures don't cascade, make services stateless and horizontally scalable, spread across AZs/regions, add retries with backoff and idempotency, use circuit breakers and timeouts to downstream calls, and degrade gracefully when a dependency is down. Health checks plus Auto Scaling self-heal failed instances. The goal is that individual component failures are absorbed rather than becoming outages.

CloudWatch for metrics, logs, and alarms; X-Ray (or OpenTelemetry) for distributed tracing across services; and structured logs aggregated for search. You define dashboards and alarms on SLO-relevant metrics (latency percentiles, error rates, queue depth), set up centralized logging, and use CloudTrail for audit. For serverless and microservices especially, tracing is essential to follow a request across Lambda/queues/services and find where latency or errors originate.

Right-size instances and remove idle resources; use Savings Plans/Reserved Instances for steady workloads and Spot for fault-tolerant/batch; adopt serverless or Fargate to pay for actual use; apply S3 lifecycle policies and the right storage classes; cache to cut compute/DB load; and set budgets/alerts and use Cost Explorer to find waste. The discipline is matching capacity to demand and committing to baseline usage, while keeping multi-AZ redundancy where it matters.

Modularize templates (CloudFormation nested stacks/StackSets, Terraform modules, CDK constructs), separate state and environments, and deploy through CI/CD pipelines with plan/review/approval steps. Use remote, locked state and parameterize per environment to keep dev/staging/prod consistent. Add policy-as-code (cfn-guard, OPA, Sentinel) to enforce security/cost guardrails on changes. At scale IaC is about reusable modules, safe pipelines, and governance, not one-off templates.

Design the partition key for even access distribution and high cardinality so traffic spreads across partitions; avoid keys that funnel load (a single popular id, a date). For unavoidable hotspots, add write sharding (suffixing the key) or caching with DAX. Use on-demand capacity for unpredictable traffic or auto-scaling for provisioned, and adaptive capacity helps somewhat — but the real fix is the key design and access-pattern modeling done up front.