Amazon Web Services Architecture and Operations Questions
Advanced knowledge of Amazon Web Services platform services, architectural patterns, operational best practices, and trade offs. Candidates should be able to justify compute choices such as Amazon Elastic Compute Cloud instance types, instance sizing and performance tuning, and Auto Scaling strategies; storage and durability decisions including Amazon Simple Storage Service storage classes, versioning, lifecycle management, replication and archival strategies; database patterns such as Amazon Relational Database Service with multi availability zone deployments, read replicas and failover behavior, and Amazon DynamoDB capacity modes and throughput trade offs; networking design including Amazon Virtual Private Cloud topology, subnet and routing strategies, peering, gateway and interface endpoints, and network security controls; infrastructure as code and deployment patterns using Amazon CloudFormation including stack management and automated rollbacks; serverless and event driven design such as Amazon Web Services Lambda concurrency and cold start considerations and integration with Amazon API Gateway; content delivery and caching with Amazon CloudFront and Amazon ElastiCache including cache invalidation and expiry strategies; service specific operational concerns such as rate limiting, backup and restore, monitoring, logging, alerting and incident response; and cross cutting concerns including identity and access governance, cost optimization, disaster recovery planning and testing, and automation. Interview focus is on design reasoning, anticipating failure modes, scaling strategies, performance tuning, observability and automation, and provider specific operational practices.
MediumTechnical
89 practiced
Design a layered network security posture in AWS using Security Groups, Network ACLs, AWS WAF, AWS Shield (DDoS), Firewall Manager, and VPC endpoints. Explain where each control should be applied, common misconfigurations to avoid, and how to centralize enforcement across multiple accounts.
Sample Answer
Design a layered AWS network-security posture by applying controls at progressively broader layers (host, subnet, edge, application, management) and centralizing policy enforcement across accounts.Architecture & where to apply controls- Security Groups (host/application): stateful, attached to ENIs/instances/ALBs. Use least-privilege ingress/egress (CIDR, security-group references). Apply per-tier (web, app, db).- Network ACLs (subnet): stateless, apply to public/private subnets as a coarse-grained boundary (block known-bad IP ranges, ephemeral port rules). Use to add an extra filter for public subnets, not as the only control.- VPC Endpoints (gateway & interface): place in private subnets to keep traffic to S3, DynamoDB, KMS, Systems Manager off the internet. Restrict S3 buckets with endpoint policies and IAM condition aws:sourceVpce.- AWS WAF: attach to CloudFront or ALB in front of web tier for OWASP protections, rate-based rules, managed rules. Use custom rules for app-specific signatures.- AWS Shield (Standard & Advanced): Shield Standard auto-protects edge services (CloudFront, ALB). Use Shield Advanced for critical assets to get DDoS mitigation, 24/7 response and cost protection.- AWS Firewall Manager: centralize WAF, Shield Advanced, security-group, and Route 53 policies across multiple accounts in an AWS Organization. Use it to enforce guardrails and automatic remediation.- Logging & Detection (cross-cutting): VPC Flow Logs, ALB access logs, CloudFront logs, GuardDuty, AWS Config, CloudWatch. Send logs to centralized account/S3 and SIEM.Common misconfigurations to avoid- Overly permissive Security Groups (0.0.0.0/0 for DB/admin ports).- Relying solely on NACLs for stateful app traffic; NACLs are stateless and order-sensitive.- Not scoping SGs by SG-id (use references instead of CIDR where possible).- Missing endpoint policies on VPC endpoints—allowing unintended bucket access.- Applying WAF only to ALB but exposing S3 static sites via CloudFront without WAF.- Not enabling Shield Advanced for high-risk public endpoints.- No centralized logging or lack of cross-account visibility.Centralized enforcement across accounts- AWS Organizations + Firewall Manager: designate a security admin account as policy owner; create organization-wide Firewall Manager policies for WAF rules, Shield Advanced protections, and security-group audit enforcement.- Service Control Policies (SCPs): prevent users from detaching required protections, creating internet-facing endpoints without tags, or disabling logging.- AWS Config + Aggregator: enforce resource compliance rules (e.g., SG least-privilege, S3 endpoint requirement) and aggregate findings centrally.- CloudFormation StackSets / AWS CDK / Terraform modules: enforce standardized SGs, NACLs, and VPC endpoints consistently across accounts/regions.- Central logging bucket and SIEM: route Flow Logs, ALB/CloudFront logs, GuardDuty findings to a central security account; enable cross-account roles for incident response.Trade-offs & operational notes- Defense-in-depth increases complexity; prefer automation (StackSets, Firewall Manager) to avoid drift.- Use WAF on CloudFront for global rate limits and lower latency; ALB WAF for region-specific controls.- Balance strict NACLs with application troubleshooting complexity; prefer SGs + WAF as primary filters.This layered approach—host (SG), subnet (NACL), private connectivity (VPC endpoints), application (WAF), edge DDoS (Shield), and centralized policy (Firewall Manager/Org/SCP/Config)—provides strong, enforceable, scalable network security across multiple AWS accounts.
MediumSystem Design
120 practiced
Design a globally distributed, low-latency web application to serve 10M monthly active users with peaks of 10,000 requests/sec. Define AWS services and patterns for compute, caching, CDN, databases, routing and global failover. Explain trade-offs for consistency, cost, and operational complexity.
Sample Answer
Requirements recap: globally distributed web app for 10M MAU, peaks 10k RPS, low latency (<100–200ms), high availability and regional failover, secure and cost-effective.High-level architecture:- Edge + CDN: Amazon CloudFront (with Lambda@Edge for light auth/AB testing) + AWS WAF + Shield.- Global routing & failover: Amazon Route 53 (weighted + health checks) plus AWS Global Accelerator for consistent global anycast IPs and improved latency/fast failover.- Compute: Containerized stateless services on Amazon ECS/Fargate or EKS (Fargate on EKS) behind regional ALBs, auto-scaling per region based on CPU/RPS.- Caching: Global: CloudFront + origin shield. Regional: ElastiCache for Redis (clustered, clustered-mode enabled) per region for session cache and hot keys; use read-through TTLs and cache-aside pattern.- Data stores: - Relational: Amazon Aurora Global Database with single primary write region and read-only secondary regions for low-latency reads. Use writer region affinity for strong writes; promote a secondary on region failure. - Key-value / low-latency writes: Amazon DynamoDB Global Tables for multi-master low-latency writes if cross-region writable data is required (eventual consistency across regions). - Object storage: S3 (multi-region replication for backups/large objects).- Messaging & async: Amazon SQS + SNS + EventBridge for decoupling, cross-region replication with Kinesis or MSK if streaming required.- Observability & ops: CloudWatch metrics/logs, X-Ray tracing, GuardDuty, Config. CI/CD with CodePipeline/CodeDeploy or GitHub Actions.Patterns and behaviors:- Read-heavy traffic served from nearest CloudFront + regional read replicas (Aurora read replicas / DynamoDB local tables) to minimize latency.- Writes routed to preferred write region; if global low-latency writes are required, use DynamoDB Global Tables (paying the eventual-consistency trade-off) or use local write queues with conflict resolution.- Failover: Route 53 health checks trigger weighted failover and Global Accelerator reroutes traffic. Aurora Global Database can perform fast regional promotion; automate with runbooks and Lambda for orchestration.Trade-offs:- Consistency: - Aurora single-writer gives strong consistency for relational data but adds write latency for users far from writer region. Use read replicas to serve reads. - DynamoDB Global Tables provide multi-master writes and low-latency local writes but only eventual consistency across regions; add vector clocks/CRDTs or business rules to resolve conflicts.- Cost: - Multi-region primary databases, read replicas, Global Accelerator, and cross-region replication increase cost. Optimize by using regional read-only replicas, right-sizing instances, using Fargate to lower ops cost, and caching aggressively.- Operational complexity: - Multi-region deployments increase runbook complexity, CI/CD, and monitoring overhead. Using managed services (Aurora, DynamoDB, ElastiCache, CloudFront) reduces operational burden but requires solid automation for failover testing and DR runbooks. - Promotion of Aurora secondary must be rehearsed; DynamoDB conflict handling requires careful schema and app logic.Key best practices:- Design for locality: prefer reading from local replicas, push compute to edge where possible.- Cache hot paths aggressively and use TTLs with cache invalidation strategies.- Automated runbooks & DR drills; feature flags and canary deployments across regions.- Encrypt data in transit and at rest (KMS), use least-privilege IAM roles, and rate-limit with WAF.This design balances low latency, availability, and operational manageability; choose Aurora (strong relational) vs DynamoDB (multi-master low-latency writes) based on primary data model and consistency needs.
HardTechnical
76 practiced
A customer requires a low-latency trading application where deterministic latency and minimal jitter are critical. Recommend EC2 instance types, placement strategies, networking configuration (ENA, EFA, placement groups), OS and kernel tuning parameters, and AWS features to minimize tail latency while considering availability trade-offs.
Sample Answer
Situation: Customer needs a low‑latency trading application where deterministic latency and minimal jitter are critical. Below is a solutions‑architect recommendation covering EC2 types, placement, networking, OS/kernel tuning, and AWS features — with availability trade‑offs called out.Recommendation summary- EC2 instance types: - Nitro-based, high‑network‑bandwidth, CPU‑optimized or bare‑metal: - Preferred: c7g/c6gn (Graviton3/Graviton2) for best price‑performance if software is compatible. - Intel/AMD options: c6i/c6a, c5n (for built-in 100Gbps on some sizes). - For absolute deterministic performance: bare metal (i3.metal, m6i.metal or c6in.metal where supported) to remove hypervisor jitter. - Choose sizes with high ENA/EFA support and multiple vCPUs to dedicate for NIC processing.- Placement strategy: - Use cluster placement groups (single AZ) to minimize network hop latency and maximize L2/L3 locality. - For ultra‑low tail latency, accept single‑AZ risk. Mitigate by: - Active/passive cross‑AZ recovery fleet (replicate state to secondary AZ). - Or use spread placement groups for control/management instances that need availability.- Networking configuration: - Enable Enhanced Networking (ENA) on all instances. - Use Elastic Fabric Adapter (EFA) for RDMA/low‑latency kernel bypass and libfabric support for application messaging (works on supported Nitro instances). - Use ENA + SR‑IOV offloads for minimal CPU overhead. - Attach instances to ENIs with high bandwidth quotas; use jumbo frames (MTU 9001) if your app benefits. - Use Security Groups and NACLs tuned (minimal rules) to avoid extra processing; keep packet filtering simple.- OS and kernel tuning (Linux): - CPU: - Disable hyperthreading (if OS/hardware allows) to reduce contention. - Use isolcpus and irqbalance disabled; pin application threads and NIC interrupts to dedicated cores. - kernel boot: isolcpus=2-7 nohz_full=2-7 rcu_nocbs=2-7 - Use tuned profile (latency‑performance) or custom systemd‑nohz setup. - Scheduler & governor: - Set CPU governor to performance. - Use SCHED_FIFO for critical threads with proper real‑time budgeting. - Memory: - Enable hugepages and lock critical memory (mlockall). - Network stack: - Increase rmem/wmem, net.core.netdev_max_backlog, somaxconn: - sysctl net.core.rmem_max=268435456 - sysctl net.core.wmem_max=268435456 - sysctl net.core.netdev_max_backlog=250000 - sysctl net.ipv4.tcp_max_syn_backlog=4096 - Enable XPS/RPS and tune IRQ affinity: - echo <cpu-mask> > /proc/irq/<irq>/smp_affinity - set xps_cpus for tx queues - Disable offloads only if they hurt (test with/without GRO/GSO/LRO). - Use low-latency NIC drivers (ENA driver up‑to‑date), and EFA/libfabric stack when using EFA. - IO: - Use NVMe/EBS-optimized instances; enable EBS‑optimized throughput. - Prefer instance store/NVMe for order‑book caches where persistence across failure is not required. - Misc: - Turn off swap or set vm.swappiness=1. - Set kernel.printk to reduce console noise. - Keep power management disabled in BIOS/firmware and ACPI tuned to performance.- Application-level: - Use user‑space networking (e.g., DPDK or RDMA via EFA/libfabric) for sub‑microsecond messaging where appropriate. - Pin threads, pre‑allocate buffers, avoid GC pauses (use tuned runtimes or native languages). - Instrument tail latency and correlate CPU/IRQ/NET metrics.- AWS features and operational trade‑offs: - Use Placement Groups (cluster) + EFA + ENA for lowest latency — trade‑off: single AZ risk. - To balance availability: - Deploy active/redundant hot standbys in another AZ with cross‑AZ replication of critical state (async for performance; consider consistency trade-offs). - Use Amazon FSx or ElastiCache (Redis) for shared low‑latency state where appropriate, but be mindful of cross‑AZ latency. - Use Auto Scaling with pre‑warmed instances kept in standby to minimize provisioning latency. - Use CloudWatch custom metrics and Container Insights / NIC counters to monitor jitter and tail events. - Use AWS Nitro System updates scheduled during maintenance windows only; coordinate for deterministic SLAs.Key trade‑offs- Lowest latency = cluster placement + EFA + bare‑metal → single‑AZ exposure and less automated AZ failover. Mitigate with cross‑AZ DR design and state replication.- Higher availability = Multi‑AZ design with spread placement → increased latency/jitter due to network hops and consistent hashing needed.Example quick checklist to implement- Choose Nitro bare‑metal or Nitro instances with EFA support.- Launch in cluster placement group, same subnet, same AZ.- Enable ENA/EFA, set MTU 9001.- Disable hyperthreading, pin IRQs and app threads, enable hugepages, set CPU governor to performance.- Use EFA + libfabric (or DPDK) for messaging.- Implement cross‑AZ standby replication and monitoring for failover.This architecture minimizes tail latency and jitter while explicitly acknowledging availability trade‑offs; final choices should be validated with profiling runs (p95/p99/p999) in a realistic trading workload.
EasyTechnical
85 practiced
A client requires S3 object versioning so accidental deletes can be recovered for 30 days, and older versions should transition to lower-cost storage after 90 days. Describe the S3 bucket configuration (versioning, lifecycle rules, MFA Delete considerations) and how you'd validate recovery procedures end-to-end.
Sample Answer
Configuration:- Enable S3 Versioning on the bucket (required to retain previous object states and to allow recovery after accidental deletes).- Lifecycle rules: - Rule A (protect short-term recovery): Do NOT expire noncurrent versions for at least 30 days. This ensures any accidental delete (which creates a delete marker) or overwrite can be recovered within 30 days. - Rule B (cost optimization): Transition noncurrent versions to lower-cost storage after 90 days (e.g., S3 Glacier Flexible Retrieval or S3 Glacier Instant Retrieval or S3 Standard-IA depending on restore latency needs). Example: NoncurrentVersionTransition: 90 days → GLACIER; NoncurrentVersionExpiration: (optional) e.g., 3650 days for permanent cleanup.- Delete markers: lifecycle should not permanently remove delete markers for the 30-day recovery window; only allow deletion after retention period you choose.- MFA Delete: recommend enabling MFA Delete only if regulatory / high-risk requirement exists. Note MFA Delete can only be enabled/disabled via the root account and complicates automation (and is supported only for versioned buckets). Alternative: use S3 Object Lock Governance/Compliance mode or AWS Backup to enforce retention immutably if you need stronger protection.- IAM & Logging: restrict s3:DeleteObjectVersion, enable CloudTrail and S3 access logging, and enable bucket encryption.Validation (end-to-end):1. Permissions & monitoring checks: confirm Versioning = Enabled, lifecycle rule present, CloudTrail logging enabled.2. Functional test (happy path): - Upload object v1. - Overwrite with v2. - Delete object (creates delete marker). - Recovery within 30 days: List object versions (aws s3api list-object-versions), identify the desired VersionId, and either: - Delete the delete marker to make the latest version visible, or - Copy the specific VersionId to a new key or restore it (for archived versions). - Verify content integrity.3. Lifecycle/archival test: - In a test bucket replicate lifecycle rules with short transition days (e.g., 1–2 days) to simulate 90-day behavior. - Confirm noncurrent versions transition to Glacier class and that a restore request (S3 restore-object) succeeds and returns original data after expected restore time.4. MFA Delete/test of protections: - If MFA Delete enabled, verify that version deletions require MFA and that automation without MFA fails.5. Recovery runbook & RTO/RPO: - Document step-by-step recovery commands, required IAM roles, expected restore times for chosen storage class, and run periodic drills. Capture metrics (time-to-recover, success) and iterate.Why this design:- Versioning + retention window addresses 30-day accidental-deletion recovery.- Transitioning noncurrent versions after 90 days reduces cost while keeping recoverability via Glacier restore.- MFA Delete vs Object Lock trade-offs are explained so client can choose between operational complexity and stronger immutability.
HardTechnical
94 practiced
Design an AWS architecture to meet HIPAA and PCI-DSS compliance for a healthcare payments platform. Identify required technical controls including encryption, logging, access controls, network segmentation, key management, and the types of evidence you would collect to satisfy an auditor.
Sample Answer
Requirements:- Protect PHI (HIPAA) and cardholder data (PCI-DSS); encryption at rest/in transit, strong access controls, logging, segmentation, key management, breach detection, retention policies, and auditable evidence.High-level architecture:- VPC with separate subnets: public (ALB/NAT), private app subnets, isolated DB subnets. PCI and PHI workloads logically separated into different VPCs or accounts (AWS Organizations) with Transit Gateway or VPC Peering and strict controls.- Front-end: ALB + WAF, AWS Shield Advanced for DDoS.- App tier: autoscaling EC2/ECS/Fargate in private subnets; use IAM roles for tasks.- Data tier: Amazon RDS (Aurora) or RDS Proxy in private DB subnets with storage encrypted.- Tokenization/service for card data: dedicated PCI-scoped service; consider using third-party PCI-HSM or AWS Payment Cryptography.- Logging/monitoring: CloudTrail (management events), VPC Flow Logs, GuardDuty, Config, CloudWatch Logs, Security Hub, AWS Config rules.Technical controls:- Encryption: - TLS 1.2+ with ALB; enforce HTTPS and HSTS. - At-rest: AWS KMS CMKs for RDS/EBS/S3. Use encryption by default. - Application-level encryption for PHI and PAN before storage; tokenization for PAN.- Key Management: - AWS KMS with multi-account key policies; use AWS CloudHSM for FIPS/PAN key material when required. - Strict key rotation, key usage auditing, and split privileges for key administrators (no single-person control).- Access Controls: - Least privilege IAM, roles for services, MFA for console access, IAM permission boundaries, and AWS SSO with SCIM for centralized identity. - Use Attribute-Based Access Control (ABAC) and resource tags to limit access. - Session recording for privileged sessions (AWS Systems Manager Session Manager).- Network Segmentation: - Separate PCI and PHI scopes by account/VPC/subnet; restrict inbound/outbound with NACLs and security groups. - Use private endpoints (VPC Endpoints) for S3, KMS, Secrets Manager. - Bastion hosts or Session Manager for admin access; deny direct internet access to databases.- Secrets & Credential Management: - AWS Secrets Manager or Parameter Store with encryption for DB credentials, API keys.- Logging & Monitoring: - Centralized, immutable log store in S3 with bucket lock & lifecycle; enable CloudTrail Insights and multi-region trails. - Retention policies per compliance requirements; alerts via CloudWatch Alarms, SNS, PagerDuty.- Change & Configuration Management: - Infrastructure as Code (Terraform/CloudFormation), code review, pipeline with enforced checks. - AWS Config rules to enforce CIS/HIPAA/PPCI baseline.Evidence for auditor:- Architecture diagrams, account/VPC inventory, and data flow diagrams showing PHI/PAN scope.- IAM policies, roles and SSO configuration; MFA enforcement reports.- KMS key policies, rotation schedules, CloudHSM usage logs.- CloudTrail logs (management and data events) with retention proof and S3 Object Lock snapshots.- VPC Flow Logs, ALB access logs, WAF logs, GuardDuty findings, Config snapshots and remediation history.- RDS snapshots/backups encryption and automated backup configs.- Penetration test results, vulnerability scanner reports, patch management records.- Change control records, IaC templates, code review/audit logs, deployment pipeline history.- Incident response plan, tabletop exercise records, and breach notification procedures.- PCI-specific: evidence of PAN tokenization, attestation of PCI scope reduction, SAQ/ROC artifacts if applicable.- HIPAA-specific: Signed BAA with AWS, risk assessment, business continuity and data retention policies.Trade-offs and notes:- Use separate AWS accounts to minimize blast radius and simplify PCI scoping.- CloudHSM adds cost/complexity but may be required for FIPS/PCI-HSM controls.- Prefer tokenization to reduce PCI scope; isolate PHI processing to minimize HIPAA exposure.
Unlock Full Question Bank
Get access to hundreds of Amazon Web Services Architecture and Operations interview questions and detailed answers.
