Top 42 AWS / Cloud Computing Interview Questions & Answers (2026)

Cloud computing is the delivery of computing services — servers, storage, databases, networking, software, analytics, and intelligence — over the internet ("the cloud") to offer faster innovation, flexible resources, and economies of scale. Instead of owning and maintaining physical data centers and servers, you access technology services on an as-needed basis from a cloud provider and pay only for what you use. Key characteristics (NIST definition): (1) On-demand self-service: provision resources without human interaction with the provider; (2) Broad network access: available over the network via standard mechanisms; (3) Resource pooling: provider serves multiple customers using a multi-tenant model; (4) Rapid elasticity: scale up or down quickly and automatically; (5) Measured service: pay for what you use (metering). Service models: IaaS (Infrastructure as a Service — EC2), PaaS (Platform as a Service — Elastic Beanstalk, Heroku), SaaS (Software as a Service — Gmail, Salesforce). Deployment models: Public cloud (AWS, Azure, GCP), Private cloud (on-premises), Hybrid cloud (both), Multi-cloud (multiple public providers). Major providers: Amazon Web Services (AWS — market leader ~33%), Microsoft Azure (~22%), Google Cloud Platform (~10%), Alibaba Cloud.

Amazon Web Services (AWS) is Amazon's comprehensive cloud platform, launched in 2006 — the world's most widely adopted cloud. It offers 200+ fully featured services from data centers globally. Core service categories: Compute: EC2 (virtual servers), Lambda (serverless), ECS/EKS (containers), Fargate (serverless containers), Elastic Beanstalk (PaaS); Storage: S3 (object storage), EBS (block storage for EC2), EFS (managed NFS), Glacier (archival); Database: RDS (managed relational — MySQL, PostgreSQL, Oracle, SQL Server), Aurora (high-performance MySQL/PostgreSQL compatible), DynamoDB (NoSQL), ElastiCache (Redis/Memcached), Redshift (data warehouse); Networking: VPC (virtual private cloud), Route 53 (DNS), CloudFront (CDN), ELB (load balancing), API Gateway; Security/Identity: IAM (identity management), Cognito (user auth), KMS (key management), WAF (web application firewall), Shield (DDoS protection); Messaging: SQS (queue), SNS (pub/sub), EventBridge, Kinesis (streaming); DevOps: CodePipeline, CodeBuild, CodeDeploy, CloudFormation (IaC), CDK; Monitoring: CloudWatch (metrics, logs, alarms), CloudTrail (API audit), X-Ray (distributed tracing). AWS operates in 32 geographic Regions with 102 Availability Zones worldwide.

Amazon EC2 (Elastic Compute Cloud) provides resizable virtual servers (instances) in the cloud. You can launch instances within minutes and pay only for the compute time you use — no upfront hardware investment. Key concepts: Instance types: different combinations of CPU, memory, storage, and networking. Families: General Purpose (t3, m5), Compute Optimized (c5, c6g), Memory Optimized (r5, x1), Storage Optimized (i3, d2), Accelerated Computing (p3, g4 — GPU). Instance sizes: nano, micro, small, medium, large, xlarge, 2xlarge, etc. Amazon Machine Image (AMI): the template for the root volume — OS, application, configuration. Choose from: AWS-provided (Amazon Linux, Ubuntu, Windows Server), Marketplace AMIs, or custom AMIs. Pricing models: On-Demand (per second/hour, no commitment); Reserved Instances (1 or 3-year commitment, up to 75% discount); Savings Plans (flexible commitment to usage, up to 66% discount); Spot Instances (use spare capacity, up to 90% discount — can be interrupted with 2-min notice); Dedicated Hosts (physical server dedicated to you — compliance/licensing). Key features: Elastic Load Balancing, Auto Scaling, security groups (virtual firewalls), Elastic IP addresses (static public IPs), EC2 User Data (bootstrap scripts on launch), Instance metadata service. Instance states: pending → running → stopping → stopped → terminated.

Amazon S3 (Simple Storage Service) is an object storage service offering industry-leading scalability, data availability, security, and performance. It stores data as objects (files) in buckets (containers), accessible via a unique URL. Key features: unlimited storage capacity; objects can be 0 bytes to 5TB (5GB per single PUT, use multipart for larger); 99.999999999% (11 nines) durability — data replicated across minimum 3 AZs; 99.99% availability; global access via HTTP. Bucket naming: globally unique, lowercase, 3-63 characters, no periods (for SSL). URLs: https://bucket-name.s3.region.amazonaws.com/key. Storage classes: S3 Standard (frequent access); S3 Intelligent-Tiering (automatic cost optimization); S3 Standard-IA (infrequent access, cheaper storage but retrieval cost); S3 One Zone-IA (single AZ, cheaper); S3 Glacier Instant Retrieval, Glacier Flexible Retrieval (archival, minutes to hours retrieval); S3 Glacier Deep Archive (cheapest, 12h retrieval). Key features: versioning (keep multiple versions), lifecycle policies (auto-transition to cheaper class or delete), replication (cross-region CRR, same-region SRR), static website hosting, pre-signed URLs (temporary access without auth), access control (bucket policies, ACLs, IAM), S3 Object Lock (WORM compliance), event notifications (trigger Lambda on upload), Transfer Acceleration (CloudFront edge for faster global uploads).

AWS IAM is a web service that controls access to AWS resources securely. It's global (not region-specific) and free to use. Core components: (1) Users: individual AWS accounts for people or applications — have long-term credentials (password, access keys); (2) Groups: collections of users with the same permissions — simplify management; (3) Roles: like users but assumed temporarily — for EC2 instances, Lambda functions, cross-account access, federated users. No long-term credentials — temporary security tokens via STS; (4) Policies: JSON documents defining permissions (Allow/Deny specific Actions on specific Resources under specific Conditions). AWS Managed Policies (predefined) vs Customer Managed Policies vs Inline Policies. Policy structure: {"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/*", "Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}}]}. Principle of Least Privilege: grant only the permissions needed to perform a task. IAM Best practices: delete root account access keys; enable MFA for root and privileged users; use IAM roles for applications/services (not access keys); create individual users (not share credentials); rotate access keys regularly; use IAM Access Analyzer to identify overly permissive policies. Permission boundaries: limit maximum permissions a user or role can have. Service Control Policies (SCPs): organization-wide guardrails in AWS Organizations.

Amazon VPC lets you provision a logically isolated section of the AWS cloud where you can launch AWS resources in a virtual network that you define. You control networking: IP address range, subnets, routing tables, network gateways. Key components: (1) CIDR block: IP address range for the VPC (e.g., 10.0.0.0/16 — 65,536 addresses); (2) Subnets: segments of the VPC IP range in a specific AZ. Public subnets (internet accessible), private subnets (no direct internet). Subnet CIDR must be subset of VPC CIDR; (3) Internet Gateway (IGW): allows communication between VPC and the internet. Attach to VPC, add route in public subnet route table; (4) Route Tables: rules determining where network traffic is directed. Each subnet associated with one route table; (5) NAT Gateway: allows private subnet instances to access internet (outbound only) while remaining private. Managed, highly available, charged per hour + data; (6) Security Groups: stateful virtual firewalls for instances — allow/deny inbound/outbound traffic by protocol, port, IP; (7) Network ACLs (NACLs): stateless firewall at subnet level — allow/deny rules evaluated in order; (8) VPC Peering: connect two VPCs privately; (9) VPC Endpoints: private connection to AWS services without internet (Gateway endpoints for S3/DynamoDB free; Interface endpoints for others via PrivateLink); (10) VPN Gateway: connect on-premises network to VPC. Default VPC: AWS creates one per region with public subnets — use for quick starts but create custom VPCs for production.

AWS Lambda is a serverless compute service that runs code in response to events without provisioning or managing servers. You pay only for the compute time consumed — no charge when code is not running. How it works: upload code (Python, Node.js, Java, Go, Ruby, C#, PowerShell, or custom runtime) → define triggers (events that invoke the function) → Lambda executes the function in a managed container. Execution model: function is invoked → Lambda creates a container with your code and dependencies → executes the handler function → returns result → container may be reused for subsequent invocations (warm start — faster) or destroyed. Invocation types: Synchronous (request/response — API Gateway, Cognito, ALB); Asynchronous (fire-and-forget — S3 events, SNS, EventBridge); Event source mapping (polls queues/streams — SQS, Kinesis, DynamoDB Streams). Configuration: Memory: 128MB to 10GB (CPU proportional to memory); Timeout: up to 15 minutes; Ephemeral storage: /tmp up to 10GB. Event triggers: API Gateway (REST/HTTP API), S3 (file upload), DynamoDB Streams, Kinesis, SQS, SNS, EventBridge (scheduled or event-driven), ALB, Cognito, CloudFront. Pricing: $0.20 per 1M requests + $0.00001667 per GB-second. Free tier: 1M requests/month + 400,000 GB-seconds/month. Best for: event-driven processing, APIs with variable traffic, data transformation, scheduled jobs. Cold start: first invocation has extra latency (~100ms to several seconds). Mitigate with Provisioned Concurrency.

Amazon RDS (Relational Database Service) is a managed relational database service that makes it easy to set up, operate, and scale databases in the cloud. AWS handles patching, backups, monitoring, and scaling. Supported engines: Amazon Aurora (MySQL/PostgreSQL compatible — proprietary, highest performance), MySQL, PostgreSQL, MariaDB, Oracle, SQL Server. Key features: (1) Automated backups: daily snapshots + transaction logs — point-in-time recovery within backup retention period (1-35 days); (2) Multi-AZ: synchronous standby replica in a different AZ — automatic failover in 1-2 minutes. For high availability, not for read scaling; (3) Read replicas: asynchronous copies for read scaling — up to 5 for MySQL/PostgreSQL. Can be promoted to standalone. Cross-region read replicas for global apps; (4) Encryption: at rest (AES-256 via KMS) and in transit (SSL/TLS); (5) Performance Insights: database performance monitoring; (6) Enhanced Monitoring: OS-level metrics; (7) Storage Auto Scaling: automatically increases storage when needed. Amazon Aurora: up to 5x faster than MySQL, 3x faster than PostgreSQL. Storage auto-grows in 10GB increments. 6 copies across 3 AZs. Aurora Global Database for cross-region. Aurora Serverless v2 for variable workloads. Instance classes: db.t3 (burstable, dev/test), db.m5/m6g (general purpose), db.r5/r6g (memory optimized for large databases). Pricing: instance hours + storage + I/O (Magnetic) + data transfer.

Amazon DynamoDB is a fully managed, serverless NoSQL database that delivers single-digit millisecond performance at any scale. No server management, built-in security, backup, restore, and in-memory caching. Key concepts: (1) Tables: collection of items (no fixed schema); (2) Items: equivalent to rows — each has a primary key; (3) Attributes: equivalent to columns — schema-less (items can have different attributes); (4) Primary key: Partition key only (simple) or Partition key + Sort key (composite). Must be unique per table; (5) Partition key: hashed to determine which partition stores the item. High cardinality key for even distribution; (6) Sort key: enables range queries and sorting within a partition. Capacity modes: Provisioned (specify RCU/WCU — Reserved and Savings Plans available); On-Demand (pay per request — no capacity planning). Indexes: Global Secondary Index (GSI — different partition key, can be any attribute, eventually consistent); Local Secondary Index (LSI — same partition key, different sort key, created at table creation). DynamoDB Streams: ordered stream of item changes — trigger Lambda for CDC patterns. Transactions: TransactWriteItems and TransactGetItems — ACID across up to 100 items in 10 tables. Global Tables: multi-region, active-active replication. DAX (DynamoDB Accelerator): in-memory cache, sub-millisecond reads. Best for: key-value access patterns, session storage, shopping carts, IoT, gaming leaderboards. Not for: complex queries with JOINs, ad-hoc analytics.

Amazon CloudFront is AWS's Content Delivery Network (CDN) that speeds up distribution of static and dynamic web content — HTML, CSS, JavaScript, images, videos, APIs — by serving from edge locations closest to users. How it works: user requests content → CloudFront routes to nearest edge location (450+ globally) → if cached (cache hit), serves immediately → if not (cache miss), fetches from origin, caches, and serves. Origins: S3 bucket (ideal for static content), ALB/EC2, API Gateway, any HTTP server. Multiple origins with failover. Key features: (1) HTTPS/SSL: free TLS certificates via ACM (AWS Certificate Manager); (2) Custom domain: use your domain with CNAME; (3) Cache behaviors: per path pattern cache settings (e.g., /api/* bypass cache, /static/* cache for 1 year); (4) Cache invalidation: aws cloudfront create-invalidation --paths "/index.html" "/*"; (5) Lambda@Edge / CloudFront Functions: run code at edge locations — URL rewrites, auth, request/response manipulation; (6) Origin Access Control (OAC): restrict S3 access to CloudFront only (S3 not public); (7) WAF integration: block malicious traffic at edge; (8) Field-Level Encryption: encrypt sensitive data at edge; (9) Real-Time Logs: stream access logs to Kinesis. Pricing: data transfer from edge + HTTP request count. No charge for S3 origin data transfer to CloudFront within same region. Free tier: 1TB data transfer + 10M requests/month.

AWS Elastic Load Balancing (ELB) automatically distributes incoming traffic across multiple targets (EC2, Lambda, containers, IP addresses) in one or more AZs, improving availability and fault tolerance. Three types: (1) Application Load Balancer (ALB): Layer 7 (HTTP/HTTPS). Content-based routing — path-based (/api/* → target group A, /web/* → target group B), host-based (api.example.com → API servers), header/query/IP-based, weighted. Supports WebSockets. HTTP/2 support. Lambda targets. Health checks. Ideal for microservices and container-based apps; (2) Network Load Balancer (NLB): Layer 4 (TCP/UDP/TLS). Millions of requests per second with ultra-low latency. Static IP / Elastic IP per AZ. Ideal for gaming, IoT, VoIP, financial apps; (3) Gateway Load Balancer (GWLB): Layer 3 (IP). Deploy, scale, manage third-party network virtual appliances (firewalls, IDS/IPS). Transparent inspection. Key ALB features: Target groups (EC2 instances, ECS tasks, Lambda, IP); Auto Scaling integration; SSL termination; sticky sessions (cookies); access logs; WAF integration; Cognito authentication. Health checks: each load balancer checks target health. Unhealthy targets removed from rotation. Cross-zone load balancing: distribute traffic evenly across all targets in all AZs (ALB always enabled; NLB optional). Connection draining: completes in-flight requests before deregistering a target.

AWS Auto Scaling automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost. EC2 Auto Scaling components: (1) Auto Scaling Group (ASG): collection of EC2 instances treated as a logical unit. Define minimum, desired, and maximum capacity. Spans multiple AZs for high availability; (2) Launch Template: configuration for instances (AMI, instance type, key pair, security group, user data). Versioned — replace Launch Configurations. Supports Spot + On-Demand mix; (3) Scaling policies: Dynamic scaling — respond to CloudWatch alarms: Target Tracking: maintain a metric at a target value (e.g., keep average CPU at 70% — simplest, recommended); Step Scaling: scale by specific amounts based on alarm breach size; Simple Scaling: one adjustment per alarm. Scheduled scaling — pre-configured time-based scaling. Predictive Scaling — ML-based proactive scaling using historical data; (4) Health checks: EC2 health (instance status), ELB health (application health). Replace unhealthy instances automatically. Lifecycle hooks: pause instance launch or termination for custom actions (install software, drain connections). ASG with ELB: newly launched instances automatically register with target group. Warm pools: maintain pre-initialized stopped instances for faster scaling. Instance refresh: rolling update of all instances in ASG (useful for AMI updates). Cost optimization: Spot Instance integration with ASG — mix On-Demand (baseline) + Spot (scale) using Spot Fleet or mixed instances policy.

Amazon CloudWatch is AWS's observability service for monitoring AWS resources and applications. It collects data as metrics, logs, and events. Metrics: time-series data points. Default AWS metrics: EC2 CPU, network, disk (at 5-min intervals); detailed monitoring (1-min intervals, extra cost). Custom metrics: push from your app: aws cloudwatch put-metric-data --namespace "MyApp" --metric-name "OrdersPerMinute" --value 150. Key EC2 metrics: CPUUtilization, NetworkIn/Out, StatusCheckFailed. Note: memory and disk are NOT in default EC2 metrics — must use CloudWatch Agent. Alarms: monitor a metric and take actions when threshold breached. Actions: SNS notification, Auto Scaling action, EC2 action (stop, start, reboot, recover). States: OK, ALARM, INSUFFICIENT_DATA. Logs: CloudWatch Logs — collect, monitor, store, and access log files from: EC2 (via CloudWatch agent), Lambda, API Gateway, VPC Flow Logs, CloudTrail, ECS. Log groups → Log streams → Log events. Log Insights: query language for analyzing logs. Metric Filters: extract metrics from log patterns. Dashboards: customizable home pages of metrics and alarms. Events / EventBridge: respond to changes in AWS services (EC2 state change, S3 upload) or schedule events (cron). Trigger: Lambda, ECS task, SNS, SQS. Container Insights: metrics and logs for ECS and EKS. Synthetics: canary scripts for monitoring endpoints.

AWS infrastructure is organized into a global hierarchy: Regions: a geographic area with multiple, isolated locations (Availability Zones). Each region is completely independent — no automatic replication between regions. Choose a region based on: latency (closest to users), compliance (data must stay in specific country), service availability (not all services in all regions), pricing (varies by region). Examples: us-east-1 (N. Virginia — most services, lowest price), eu-west-1 (Ireland), ap-southeast-1 (Singapore). 32 launched regions worldwide (2024). Availability Zones (AZs): one or more discrete data centers within a region, each with redundant power, networking, and connectivity. Physically separated by meaningful distance (miles apart) but connected with high-bandwidth, low-latency fiber. AZs within a region are identified by a letter suffix: us-east-1a, us-east-1b, us-east-1c. Each region has 2-6 AZs. Design principle: deploy across multiple AZs for high availability — if one AZ fails, others continue serving. Local Zones: extension of an AWS Region to more geographic locations — low-latency access to AWS services for specific metro areas. Wavelength Zones: AWS infrastructure embedded within telecom networks for ultra-low latency to 5G mobile devices. AWS Outposts: AWS infrastructure, services, APIs, and tools running on-premises — hybrid cloud, low-latency local processing. Edge Locations: CloudFront and Route 53 PoPs — 450+ globally for caching and DNS. Not full regions — no compute or storage services (just CDN and DNS).

Amazon SQS (Simple Queue Service) is a fully managed message queue for decoupling and scaling microservices, distributed systems, and serverless applications. Messages are stored until consumers process them. Queue types: Standard queue — maximum throughput (unlimited TPS), at-least-once delivery, best-effort ordering. FIFO queue — exactly-once processing, first-in-first-out order, up to 3,000 TPS with batching. Key features: message size up to 256KB (larger via SQS Extended Client with S3); retention period 1 minute to 14 days (default 4 days); visibility timeout (message hidden while being processed, becomes visible again if not deleted — prevents double processing); dead-letter queue (DLQ — failed messages after N receive attempts); long polling (reduces empty receives, max 20s wait); delay queues (postpone delivery up to 15 min). Amazon SNS (Simple Notification Service) is a fully managed pub/sub messaging service. Publishers send messages to topics; all subscribers receive a copy. Subscribers: SQS, Lambda, HTTP/HTTPS, Email, SMS, mobile push (FCM, APNs). Fan-out pattern: SNS topic → multiple SQS queues — decouple event processing. FIFO topics: strict ordering, exactly-once delivery (paired with SQS FIFO). Message filtering: subscribers receive only messages matching their filter policy — reduces unnecessary processing. SNS + SQS fan-out: one S3 upload event → SNS → multiple SQS queues → different Lambda processors (thumbnail, metadata extraction, virus scan) — fully decoupled.

AWS CloudFormation is Infrastructure as Code (IaC) — define and provision AWS infrastructure using declarative JSON or YAML templates. Create, update, and delete a collection of resources as a single unit called a stack. Template structure: AWSTemplateFormatVersion: "2010-09-09" Description: "Web App Stack" Parameters: Environment: Type: String AllowedValues: [dev, prod] InstanceType: Type: String Default: t3.micro Resources: WebServer: Type: AWS::EC2::Instance Properties: ImageId: ami-0abcdef1234567890 InstanceType: !Ref InstanceType SecurityGroups: [!Ref WebSecurityGroup] UserData: !Base64 | #!/bin/bash yum install -y httpd systemctl start httpd WebSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Allow HTTP/HTTPS Outputs: WebServerURL: Value: !Sub "http://${WebServer.PublicDnsName}". Key features: !Ref (reference a resource/parameter), !Sub (string substitution), !GetAtt (get resource attribute), !Join, !Select, !If (conditional). StackSets: deploy stacks across multiple accounts and regions. Change sets: preview changes before applying. Drift detection: detect configuration changes made outside CloudFormation. Nested stacks: template that references other templates. AWS CDK (Cloud Development Kit): define infrastructure in Python, TypeScript, Java — generates CloudFormation. Higher-level abstractions. Terraform: popular third-party IaC, multi-cloud, uses HCL language.

AWS offers several storage services for different use cases: Amazon S3 (Object Storage): flat key-value store for any type of file. Unlimited capacity, 11 nines durability. Best for: backups, media, data lakes, static websites, application artifacts. Amazon EBS (Elastic Block Store): network-attached block storage for EC2 instances. Like a hard drive — can be formatted with a filesystem. Persists independently of EC2 lifetime (detach and re-attach). Types: gp3 (General Purpose SSD — default, balanced), io2 Block Express (high IOPS for databases), st1 (Throughput Optimized HDD for big data), sc1 (Cold HDD — cheapest, infrequent access). Multi-Attach for io1/io2 (limited use). Snapshots to S3 for backup/migration. One EBS to one EC2 instance (same AZ). Amazon EFS (Elastic File System): fully managed NFS (Network File System). Multiple EC2 instances can mount simultaneously — shared filesystem. Auto-scales from GB to PB. Multi-AZ (Regional) or One Zone. Performance modes: General Purpose (latency-sensitive), Max I/O (highly parallel). Throughput modes: Bursting, Provisioned, Elastic (auto-scale). Much more expensive than EBS per GB. Use for: content management, home directories, dev environments, shared data. Amazon FSx: managed third-party filesystems: FSx for Windows File Server (SMB, Active Directory), FSx for Lustre (high-performance computing, ML training), FSx for NetApp ONTAP, FSx for OpenZFS. AWS Storage Gateway: hybrid storage — connects on-premises to AWS storage.

The AWS Shared Responsibility Model defines what AWS is responsible for ("security OF the cloud") and what the customer is responsible for ("security IN the cloud"): AWS responsibilities (Security OF the cloud): physical security of data centers; hardware and global infrastructure (servers, routers, switches); hypervisor and virtualization layer; managed service components (e.g., RDS OS patching, Lambda runtime); global network infrastructure; AZ and region physical isolation. Customer responsibilities (Security IN the cloud): operating system patches on EC2; network and firewall configuration (security groups, NACLs); application-level security; data encryption (in transit and at rest); identity and access management (IAM users, roles, policies); customer data protection; network traffic configuration. How responsibility shifts by service type: IaaS (EC2): customer manages OS upward; AWS manages hardware and hypervisor. PaaS (Elastic Beanstalk): AWS manages OS and runtime; customer manages application and data. SaaS (S3): AWS manages most things; customer manages data, access policies, encryption settings. Example scenarios: EC2 gets compromised due to unpatched OS → customer responsibility. AWS data center floods → AWS responsibility. S3 bucket accidentally public → customer responsibility (misconfigured access policy). RDS OS patched incorrectly → AWS responsibility. Application-level SQL injection → customer responsibility. Why it matters: customers cannot audit AWS infrastructure directly — rely on compliance certifications (SOC, ISO, PCI). Use AWS Artifact to download compliance reports.

AWS Elastic Beanstalk is a Platform as a Service (PaaS) that simplifies deploying and scaling web applications. You upload your code; Beanstalk handles deployment, capacity provisioning, load balancing, auto-scaling, and application health monitoring. Supported platforms: Node.js, Python, Ruby, PHP, Java (Tomcat), .NET, Go, Docker (single and multi-container). How it works: create an application → create an environment (web server or worker tier) → deploy code (ZIP, WAR, Docker image) → Beanstalk provisions: EC2 instances (Auto Scaling group), Load Balancer (optional), RDS (optional), S3 (for code + logs), CloudWatch alarms. Deployment policies: All at once (fast, downtime); Rolling (no downtime, reduced capacity during update); Rolling with additional batch (no capacity reduction, extra cost); Immutable (new instances with new version — safest, most expensive); Traffic splitting (canary testing). Environments: Blue/Green deployments by swapping environment URLs. Customization: .ebextensions/ folder with config files — install packages, run scripts, set environment variables, configure load balancer. beanstalk.env: set environment variables. Managed updates: automatically applies platform updates. Monitoring: health dashboard, enhanced health monitoring, CloudWatch integration. Cost: no additional charge for Beanstalk — pay only for underlying resources (EC2, ELB, etc.). vs EC2 directly: Beanstalk for quick deployment without infrastructure management; EC2 for full control. Recommended for development teams that want simpler deployment without Kubernetes complexity.

AWS provides two managed container orchestration services: Amazon ECS (Elastic Container Service): AWS-native container orchestration. Launch types: EC2 (you manage EC2 instances in a cluster) or Fargate (serverless — no EC2 management). Key concepts: Cluster (group of capacity), Task Definition (blueprint — Docker image, CPU, memory, env vars, ports, IAM role, logging), Service (maintain N running tasks, integrate with ELB), Task (running instance of a task definition). Integration: ECR (private container registry), ALB with dynamic port mapping, CloudWatch Logs, IAM task roles (like EC2 instance profiles), Service Auto Scaling. ECS Anywhere: run ECS tasks on on-premises servers. Amazon EKS (Elastic Kubernetes Service): managed Kubernetes — AWS manages the Kubernetes control plane (API server, etcd, scheduler). Node groups: managed (AWS manages provisioning and lifecycle), self-managed, Fargate (serverless pods). Features: Kubernetes-standard — portable across clouds; AWS integrations (EBS, EFS, ALB, IAM via IRSA); Karpenter (node autoscaler — more flexible than Cluster Autoscaler); EKS Anywhere (on-premises). ECS vs EKS: ECS is simpler, tighter AWS integration, less operational overhead, AWS-proprietary. EKS is standard Kubernetes — portable, larger ecosystem, steeper learning curve, more flexible. Choose ECS for simpler AWS-native workloads; EKS for teams with Kubernetes expertise or multi-cloud portability needs. AWS Fargate: serverless compute for containers — no EC2 instances to manage. Works with both ECS and EKS. Pay per vCPU and memory per second.

Amazon API Gateway is a fully managed service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket APIs at any scale. No servers to manage — gateway handles traffic management, authorization, throttling, monitoring, API version management. API types: (1) REST API: feature-rich, supports all API Gateway features. Request/response transformation, caching, API keys, usage plans, stage variables. More expensive; (2) HTTP API: lower latency, simpler, cheaper (up to 70% less than REST). Supports JWT authorizers, Lambda proxy, CORS. Missing: API caching, request/response transformation, API keys (use for newer APIs); (3) WebSocket API: bi-directional persistent connections for real-time (chat, gaming, streaming). Key features: Stages and deployments: dev, staging, prod stages with separate settings; Throttling: account-level (10K RPS, 5K burst), stage-level, method-level limits; Caching: REST API cache responses (0.5GB to 237GB), reduce backend calls; Authorization: IAM, Cognito User Pools, Lambda authorizers (custom auth logic); Request/response transformation: mapping templates (VTL) to transform payloads; API keys + Usage plans: monetize APIs, enforce quotas; CORS: configure cross-origin headers; Lambda integration: Lambda Proxy (passthrough) or custom integration; VPC Link: private integration to ALB/NLB in VPC. Integration: Lambda (serverless backend), HTTP backend (EC2, ECS, external APIs), AWS services (SQS, DynamoDB, SNS). Pricing: REST: $3.50/million API calls; HTTP: $1.00/million; WebSocket: $1.00/million connections + $1.00/million messages.

Both Security Groups and Network ACLs (NACLs) control network traffic in a VPC but at different levels: Security Groups (instance-level): virtual stateful firewall applied to an EC2 instance (or other resources like RDS, ELB). Stateful: if you allow inbound traffic, the outbound response is automatically allowed (tracks connection state). Allow rules only — no deny rules. If no rule matches, traffic is denied. Evaluated as a whole — all rules checked. Source/destination can be IP CIDR or another security group (powerful for referencing: "allow traffic from the web security group"). Applied to individual resources, multiple resources can share a security group. Example: allow port 443 from 0.0.0.0/0 (any HTTPS), allow port 5432 from database security group only. Network ACLs (subnet-level): stateless firewall applied to all traffic entering/leaving a subnet. Stateless: must explicitly allow both inbound AND outbound traffic (including ephemeral ports 1024-65535 for return traffic). Allow and deny rules — can explicitly block specific IPs. Rules evaluated in order (lowest rule number first); first match wins. Applies to all instances in the subnet — cannot selectively apply. Default NACL: allows all inbound and outbound. Defense in depth: use both. NACL as a coarse subnet-level filter; Security Groups for fine-grained instance-level control. Remember: Security Groups = stateful, instance-level, allow-only; NACLs = stateless, subnet-level, allow+deny. Security Groups are checked first (most specific) when a packet arrives at an EC2 instance.

AWS Key Management Service (KMS) is a managed service for creating and controlling cryptographic keys used to protect data. Integrates with 100+ AWS services. Key types: AWS Managed Keys — created and managed by AWS for specific services (aws/s3, aws/rds); Customer Managed Keys (CMK) — you create and manage, full control over policies; AWS Owned Keys — AWS manages internally, no customer visibility. Key material: AWS KMS generated (default); imported (bring your own key — BYOK); AWS CloudHSM generated. Encryption at rest (envelope encryption): KMS generates a data key → encrypt data with data key → encrypt data key with KMS CMK (DEK is encrypted, stored with data). Decrypt: KMS decrypts the DEK → use DEK to decrypt data. Only the CMK stays in KMS — data keys never stored in plaintext. Encryption in transit: TLS/SSL handled by individual services. KMS in practice: S3 SSE-KMS (server-side encryption with KMS key per object), RDS encryption (all storage, backups, snapshots encrypted), EBS encryption, Secrets Manager (encrypted by KMS). Key policy: resource-based policy on each CMK — defines who can use and manage. Key rotation: automatic annual rotation (CMK material rotated, old material retained for decryption). Multi-region keys: same key ID and material replicated across regions — decrypt in different region than where data was encrypted. Asymmetric keys: RSA/ECC key pairs for sign/verify and public key encryption. Price: $1/month per CMK + $0.03 per 10K API calls.

AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account by recording all API calls made in your account. What it records: who (IAM identity — user, role, service), when (timestamp), from where (IP address, user agent), what action (API call), on what resource (ARN), result (success/failure), request/response parameters. Trail types: Management events — operations on AWS resources (CreateBucket, RunInstances, TerminateInstances, PutBucketPolicy — control plane); Data events — resource operations (S3 object-level Get/Put/Delete, Lambda function invocations — data plane, not enabled by default); Insights events — detect unusual API activity patterns (spikes, anomalies). Configuration: create a trail → select event types → store logs in S3 → optionally: CloudWatch Logs (real-time monitoring), EventBridge (trigger actions on specific events). Log file integrity validation: CloudTrail signs log files — detects if tampered. Multi-region trails: one trail capturing events from all regions. Organization trails: capture events from all accounts in AWS Organizations. Event History: free 90-day history in CloudTrail console (last 90 days, management events). Athena integration: query CloudTrail logs stored in S3 with SQL — find all actions by a specific IAM user, identify unauthorized API calls. Use cases: security incident investigation, compliance auditing, operational troubleshooting, change tracking. CloudTrail + GuardDuty = security monitoring foundation.

Serverless architecture on AWS means building applications without provisioning or managing servers — you focus on code, AWS manages infrastructure. You pay only when code runs, not for idle time. Core serverless services: Lambda (compute), API Gateway (HTTP frontend), DynamoDB (database), S3 (storage), EventBridge (event bus), SQS/SNS (messaging), Step Functions (orchestration), Cognito (auth), AppSync (GraphQL). Common serverless patterns: (1) Web API: API Gateway → Lambda → DynamoDB. Scales from 0 to millions with no changes; (2) File processing: S3 upload event → Lambda trigger → process (resize image, extract metadata, validate) → store result; (3) Event-driven: EventBridge rule → Lambda (e.g., new order event → send confirmation email, update inventory, notify warehouse); (4) Scheduled tasks: EventBridge cron → Lambda (generate reports, cleanup, sync data). AWS Step Functions: orchestrate multiple Lambda functions in a workflow. States: Task, Wait, Choice (branching), Parallel, Map (iterate), Pass. Handles retries, error handling, timeouts. Express vs Standard (different pricing/durability). SAM (Serverless Application Model): CloudFormation extension for serverless — simpler template syntax for Lambda, API Gateway, DynamoDB. sam local invoke for local testing. Benefits: no server management, automatic scaling, pay-per-use, built-in availability. Challenges: cold starts (Lambda), vendor lock-in, local development complexity, debugging distributed functions, 15-minute Lambda timeout limit.

The AWS Well-Architected Framework provides a consistent approach for evaluating architectures and implementing designs that scale over time. Six pillars: (1) Operational Excellence: run and monitor systems to deliver business value. Practices: IaC (CloudFormation/CDK), CI/CD pipelines, runbooks, observability (metrics, logs, traces), small reversible changes, anticipate failure. Key services: CloudWatch, X-Ray, Systems Manager; (2) Security: protect data, systems, assets. Practices: identity-based access (IAM least privilege), detective controls (GuardDuty, CloudTrail), infrastructure protection (WAF, Shield, Security Groups), data protection (KMS, Macie), incident response automation. Zero trust principles; (3) Reliability: ensure a workload performs its intended function correctly and consistently. Practices: multi-AZ deployments, auto-scaling, graceful degradation, backup and restore, chaos engineering. Services: Route 53, ELB, ASG, S3; (4) Performance Efficiency: use computing resources efficiently. Practices: serverless first, right-sizing, global deployment (CloudFront), caching, monitoring and benchmarking; (5) Cost Optimization: deliver business value at lowest price. Practices: right-sizing, Reserved Instances/Savings Plans, Spot Instances, S3 lifecycle policies, delete unused resources. AWS Cost Explorer, Trusted Advisor; (6) Sustainability: minimize environmental impact. Practices: maximize utilization, use managed services, select efficient regions, reduce downstream impact. Well-Architected Tool: review your workloads against the six pillars, identify risks, prioritize improvements.

Amazon ElastiCache is a fully managed, in-memory caching service that significantly improves application performance by making data retrieval fast. Supports two engines: Redis: advanced data structures (strings, lists, sets, sorted sets, hashes, geospatial, streams). Persistence (AOF, RDB snapshots). Pub/Sub messaging. Multi-AZ with automatic failover. Read replicas. Cluster mode (horizontal sharding up to 500 nodes). Lua scripting. Best for: session caching, leaderboards, real-time analytics, pub/sub, complex data structures. ElastiCache for Redis vs Amazon MemoryDB for Redis (stronger durability — transactions logged to Multi-AZ log); Memcached: simpler, multi-threaded. Pure cache (no persistence). Auto discovery of nodes. Horizontal scaling (add nodes). Best for: simple caching, multi-threaded applications. No replication or persistence. Common use cases: Database query caching — results of expensive SQL queries cached for seconds to minutes; Session store — user session data accessible across multiple app servers; API response caching — reduce downstream calls; Distributed locking — atomic Redis commands (SETNX) for distributed locks; Real-time leaderboards — Redis sorted sets (ZADD/ZRANGE). Cluster mode disabled vs enabled: disabled — single shard (primary + replicas), simpler, up to 500GB. Enabled — data partitioned across multiple shards, up to 500 nodes. Access: only from within the same VPC (not public internet). Pricing: per node-hour + data transfer. No charges for data at rest.

AWS cost optimization strategies across services: 1. Right-sizing: match instance types to actual workload requirements. Use AWS Compute Optimizer, CloudWatch metrics, Trusted Advisor. Upgrade/downgrade CPU/memory as needed. 2. Pricing models: On-Demand for variable/unpredictable workloads; Reserved Instances (1 or 3-year) for predictable baseline — 40-75% savings; Savings Plans (Compute or EC2) — more flexible than RIs, up to 66% savings; Spot Instances for fault-tolerant, flexible workloads (batch, CI/CD, ML training) — up to 90% savings. 3. Auto Scaling: scale down during low-traffic periods. Schedule scale-in at night. Don't over-provision static capacity for peak loads. 4. Storage tiering: S3 Intelligent-Tiering, lifecycle policies moving to Glacier/Deep Archive; delete unattached EBS volumes, old snapshots; EBS gp3 cheaper than gp2 for same IOPS. 5. Serverless: Lambda + DynamoDB on-demand — pay only for actual usage. No idle EC2 costs. 6. Reserved capacity for databases: RDS Reserved Instances, ElastiCache Reserved Nodes. 7. Data transfer: use S3 endpoints (no NAT Gateway charges), deploy in same region as your users, use CloudFront to reduce origin data transfer. 8. Tagging: tag all resources (project, team, environment) → cost allocation reports per tag. 9. Unused resources: audit with Trusted Advisor — idle EC2, unused EIPs, underutilized EBS. Set AWS Budgets alerts. 10. Multi-AZ wisely: Multi-AZ RDS doubles cost — evaluate if actually needed in dev/test. Tools: AWS Cost Explorer (analyze historical costs), Budgets (alerts), Trusted Advisor, Compute Optimizer, Cost Anomaly Detection.

AWS provides native CI/CD services as an integrated pipeline: AWS CodeCommit: private Git repositories — similar to GitHub but managed by AWS. Integrates natively with other AWS services. (Being deprecated — GitHub/GitLab recommended instead.) AWS CodeBuild: fully managed build service. Compiles code, runs tests, produces artifacts. Configured via buildspec.yml: define build phases (install, pre_build, build, post_build), environment variables, artifact paths. Scales automatically. Pay per build minute. Supports Docker builds (no Docker daemon needed in privileged mode). AWS CodeDeploy: automates application deployments to EC2, Lambda, ECS. Deployment configurations: In-place (rolling, rolling with additional batch, one at a time), Blue/Green. AppSpec file (appspec.yml) defines deployment hooks. Rollback on failure. AWS CodePipeline: orchestrates the end-to-end CI/CD pipeline. Stages: Source → Build → Test → Deploy. Triggers on code changes. Example pipeline: GitHub push → CodeBuild (test + build Docker image + push to ECR) → CodeDeploy (deploy to ECS) → Manual approval → Production deploy. GitHub Actions + AWS: many teams use GitHub Actions (or GitLab CI) with AWS CLI/CDK for a simpler, widely adopted approach. Integrations: CodePipeline → S3 (artifact store), ECR (container images), CloudFormation (infrastructure deploy), Elastic Beanstalk, Lambda, ECS. Notifications: CodeStar Notifications → SNS/Slack. Best practices: deploy to dev/staging first, automated tests at each stage, manual approval gates before production, rollback capability.

AWS X-Ray is a distributed tracing service that helps developers analyze and debug distributed applications — particularly microservices and serverless architectures. Core concepts: Trace: end-to-end request path through the application — unique trace ID; Segment: data generated by a single service (EC2, Lambda, ECS task) within a trace; Subsegment: breakdown of a segment (individual SQL queries, HTTP calls, function calls within a segment); Annotations: key-value indexed metadata (searchable, use for filtering); Metadata: additional non-indexed data per segment. Service map: visual graph showing all services and their connections — quickly identify which service is causing latency or errors. Color-coded by health. Integration: Lambda (automatic with X-Ray enabled), API Gateway, ECS (daemon as sidecar container), EC2 (X-Ray daemon process), Elastic Beanstalk (auto-installed), SQS (trace header propagation). SDK: instrument your application code: from aws_xray_sdk.core import xray_recorder @xray_recorder.capture("my_function") def my_function(): # Segment automatically created xray_recorder.put_annotation("user_id", user_id) response = http_client.get("https://api.example.com") return response. Sampling: only record a percentage of requests (default: 1 request/sec + 5%). Reduces cost and overhead while maintaining visibility. Configure custom sampling rules. Insights: AI-powered insights identify anomalies in trace data. Groups: filter and alert on specific trace groups. OpenTelemetry: ADOT (AWS Distro for OpenTelemetry) — vendor-neutral alternative to X-Ray SDK, sends traces to X-Ray or other backends.

Amazon Cognito provides user authentication, authorization, and user management for web and mobile apps. Two main components: User Pools: fully managed user directory. Features: sign-up/sign-in (email, phone, username); social sign-in (Google, Facebook, Apple, SAML, OIDC providers); multi-factor authentication (SMS, TOTP); password policies and account recovery; email/SMS verification; JWT tokens (ID, access, refresh tokens); Lambda triggers (pre-sign-up, post-authentication, custom message, pre-token generation — customize behavior); hosted UI (customizable sign-in page); user groups and attributes. Identity Pools (Federated Identities): grant temporary AWS credentials to users to access AWS services directly. Users authenticated via: Cognito User Pool, social (Google, Facebook), SAML, guest (anonymous). Maps to IAM role → grants permissions for S3 read, DynamoDB access, etc. Use case: mobile app that directly accesses S3 — user authenticates with Cognito, gets temporary AWS credentials, uploads to S3 directly without a backend server. Combined flow: User Pool authenticates user → returns JWT → Identity Pool exchanges JWT for AWS credentials → user accesses AWS services. Integration with API Gateway: use Cognito User Pool as an authorizer — API Gateway validates JWT tokens automatically. Security: Cognito Advanced Security Features — compromised credential check, adaptive authentication (MFA on suspicious logins). Pricing: Free tier 50K MAU (Monthly Active Users). Paid: $0.0055/MAU after 50K.

AWS Systems Manager (SSM) is a centralized hub for managing AWS infrastructure at scale — operational data, automating operational tasks, and managing configuration compliance. No need for SSH/RDP access to instances. Key capabilities: (1) Session Manager: secure browser-based shell/RDP access to EC2 and on-premises servers — no open inbound ports (22/3389), no bastion hosts, full audit trail in CloudTrail and S3; (2) Parameter Store: secure, hierarchical storage for configuration data and secrets: /myapp/prod/db-password (String, StringList, or SecureString encrypted by KMS). Free tier for standard parameters. IAM-controlled access. Version history. SDK integration; (3) Secrets Manager: fully managed secrets service with automatic rotation (built-in rotation for RDS, Redshift, DocumentDB; custom Lambda rotators). More expensive than Parameter Store but includes rotation. Cross-account access. SDK integration for automatic secret retrieval; (4) Run Command: remotely execute shell scripts or PowerShell on EC2 instances/on-premises. No SSH needed. Audit in CloudTrail; (5) Patch Manager: automate OS and application patching across instances. Define patch baselines, maintenance windows. Patch compliance reporting; (6) State Manager: maintain consistent configuration state (ensure SSM agent running, CloudWatch agent configured); (7) Automation: runbooks for common operational tasks (start/stop instances, create AMIs, remediate findings); (8) OpsCenter: centralized view of operational issues; (9) Fleet Manager: manage large fleets of instances. SSM Agent pre-installed on AWS AMIs; required on-premises.

Advanced AWS networking services for complex enterprise architectures: AWS Transit Gateway (TGW): a regional network transit hub connecting multiple VPCs and on-premises networks. Eliminates complex VPC peering (peering doesn't scale — N VPCs requires N*(N-1)/2 peering connections; TGW requires N connections to one hub). Features: up to 5,000 VPC attachments per TGW; route tables for segmentation (dev VPCs can't reach prod); Inter-Region peering between TGWs; VPN and Direct Connect attachments; multicast support; Network Manager (visual topology). Use case: hub-and-spoke network topology — all VPCs attach to TGW, routing centralized. AWS PrivateLink (VPC Endpoint Services): expose your service to other VPCs or accounts privately without internet or VPC peering. Service provider creates a Network Load Balancer → creates endpoint service → consumers create interface VPC endpoints → private DNS resolution → secure communication. Use cases: expose internal microservices to partner accounts; access AWS services privately (ECR, S3, KMS — no internet required); shared services VPC (security, logging) connected to multiple workload VPCs. AWS Direct Connect: dedicated network connection from on-premises to AWS (1Gbps or 10Gbps). Consistent, low-latency, private — no internet. Hosted connections (smaller bandwidth via partners). Direct Connect Gateway for multiple regions. Virtual Interfaces: private (VPC), public (AWS public services like S3), transit (Transit Gateway). Site-to-Site VPN: IPSec encrypted tunnel over internet from on-premises to AWS (cheaper than Direct Connect, higher latency, variable bandwidth). Accelerated VPN uses AWS Global Accelerator for lower latency. Combine Direct Connect (primary) + VPN (backup) for resilient hybrid connectivity.

Advanced IAM concepts for secure, scalable AWS access management: Role assumption chain: EC2 → assumes Role A (instance profile) → Role A can assume Role B (cross-account) → Role B can assume Role C. Each step uses STS AssumeRole with temporary credentials. Max session duration configurable (up to 12h for console, 43,200s for API). Cross-account access: Account A (source) creates a role with Account B as trusted entity in trust policy. Account B user assumes the role: aws sts assume-role --role-arn arn:aws:iam::AccountA::role/ReadS3 --role-session-name session1. Returns temporary credentials. Use Organizations for centralized management. Permission Boundaries: IAM entity (user/role) level — set maximum permissions an entity can have, even if their permission policies grant more. Prevents privilege escalation: developer can't grant themselves more permissions than their boundary allows. Example: developer has AdministratorAccess but boundary only allows S3/DynamoDB → developer can only use S3/DynamoDB. SCP (Service Control Policies): Organization-level guardrails — apply to all accounts/OUs. Define what services/actions are EVER allowed in an account. Even account root can't bypass SCPs. Example: Deny EC2 in non-approved regions. Attribute-Based Access Control (ABAC): control access based on tags. Tag resources and IAM principals with same tags → policy uses condition keys. Scales without adding new policies: new resource with matching tag automatically accessible. AWS Organizations: manage multiple AWS accounts centrally. Account hierarchy: Management account → OUs (Organizational Units) → Member accounts. SCPs, centralized billing, AWS SSO/Identity Center.

AWS disaster recovery (DR) strategies, from cheapest to most expensive: 1. Backup and Restore (RTO: hours, RPO: hours): back up data to another region (S3 cross-region replication, RDS cross-region snapshots, EC2 AMI copy). On disaster: restore from backup in DR region. Cost: only backup storage. Lowest cost, longest recovery time. Use for non-critical systems. 2. Pilot Light (RTO: minutes to hours, RPO: minutes): minimal version of core infrastructure always running in DR region (RDS replica, critical servers). On disaster: scale up the pilot light infrastructure. Database already in sync (near real-time replication). Slightly more expensive than backup/restore. 3. Warm Standby (RTO: minutes, RPO: seconds to minutes): scaled-down but fully functional copy in DR region. Receives real-time data replication. On disaster: scale up to full production capacity. Route 53 health checks + failover routing for automatic DNS switch. Good balance of cost and recovery speed. 4. Multi-Site Active/Active (RTO: near zero, RPO: near zero): full production load in multiple regions simultaneously. Route 53 latency-based or geolocation routing distributes traffic. Both regions fully sized. Expensive — double infrastructure cost. Use for mission-critical applications. Key services for DR: Route 53 health checks + failover; S3 CRR; RDS read replicas + promotion; Global Aurora (cross-region replication with <1s RPO); DynamoDB Global Tables (active-active, multi-region); CloudFormation (recreate infrastructure from code); AMI copying across regions; Elastic Disaster Recovery (DRS — continuous server replication). RTO (Recovery Time Objective) = max acceptable downtime. RPO (Recovery Point Objective) = max acceptable data loss.

AWS provides a comprehensive ecosystem for data engineering and analytics: Ingestion: Kinesis Data Streams (real-time streaming, custom consumers, retain 24h-365 days); Kinesis Data Firehose (load to S3/Redshift/Elasticsearch, automatic transformations, no consumer management); Database Migration Service (DMS — migrate databases, ongoing replication, CDC); AWS Glue (ETL service — discover schema, transform, catalog data); MSK (Managed Kafka — fully managed Apache Kafka). Storage: S3 (data lake — Parquet, ORC, Avro, CSV); Redshift (petabyte-scale data warehouse, columnar storage, Redshift Spectrum for S3 queries); EMR (managed Hadoop/Spark/Hive/Presto — big data processing); AWS Lake Formation (govern and secure data lake). Processing: AWS Glue (Spark ETL, Python/Scala, serverless, Glue Data Catalog); EMR (Spark, Hive, Hadoop, Flink on managed cluster); Lambda (small transformations, event-driven); AWS Batch (batch processing jobs, managed compute). Analytics/Query: Athena (serverless SQL on S3 — pay per query, uses Data Catalog schemas); Redshift (data warehouse SQL); QuickSight (BI dashboarding, SPICE in-memory engine); OpenSearch Service (Elasticsearch compatible — search and log analytics). ML: SageMaker (managed ML platform — train, deploy, monitor models); SageMaker Feature Store, Pipeline, Studio. Orchestration: MWAA (Managed Airflow), Glue Workflows, Step Functions. Data lake pattern: Kinesis/DMS → S3 raw → Glue ETL → S3 refined → Athena/Redshift for analysis → QuickSight for visualization.

AWS security architecture following defense-in-depth principles: 1. Account-level security: AWS Organizations with SCPs; separate accounts for dev/staging/prod; management account for billing only; AWS Control Tower for multi-account governance; AWS Security Hub (aggregate security findings from GuardDuty, Inspector, Macie, Config). 2. Identity: IAM Identity Center (AWS SSO) for centralized human access; no IAM users where possible — use roles; MFA on root and privileged accounts; access key rotation; CloudTrail audit; Access Analyzer (identify public/external access). 3. Infrastructure: VPC with private subnets; security groups (least privilege); NACLs (explicit deny); no public EC2 — use SSM Session Manager; NAT Gateway for outbound; WAF (OWASP rules) in front of ALB/CloudFront; AWS Shield Standard (always on) + Shield Advanced (DDoS specialized response); Network Firewall (stateful, DNS filtering, IDS/IPS). 4. Data: encryption at rest (KMS for EBS, S3 SSE-KMS, RDS); encryption in transit (TLS everywhere, ACM certificates); S3 Block Public Access (account-level); Macie (ML-based sensitive data discovery); Secrets Manager for credentials. 5. Detection: GuardDuty (threat detection — ML on CloudTrail, VPC Flow Logs, DNS logs — finds crypto mining, compromised instances, credential theft); Security Hub (standards — CIS Benchmark, AWS Foundational Best Practices); Inspector (vulnerability scanning for EC2 and ECR images); CloudWatch Alarms + EventBridge for security events; VPC Flow Logs. 6. Incident Response: automated remediation via Lambda + EventBridge (isolate compromised instance: remove from ASG, revoke security group, snapshot for forensics); Runbooks in Systems Manager; SOAR with third-party tools.

Advanced AWS Lambda patterns and optimizations: 1. Provisioned Concurrency: pre-initialize Lambda execution environments to eliminate cold starts. Pay extra for warm instances. Schedule: use Application Auto Scaling to pre-warm before expected traffic. Use for latency-sensitive APIs. 2. Lambda Layers: package shared dependencies (libraries, runtimes) in a layer → add to functions. Up to 5 layers per function. 50MB compressed. Reduces deployment size, enables dependency sharing. 3. Lambda Power Tuning: open-source tool to find optimal memory setting for cost/performance. More memory = more CPU = faster = lower duration billing — often higher memory is cheaper overall. 4. Lambda@Edge / CloudFront Functions: Lambda@Edge runs at CloudFront PoPs (130+ locations), 128MB-10GB, up to 30s timeout. Uses: A/B testing, authentication, dynamic content personalization, URL rewriting, header manipulation. CloudFront Functions: faster (sub-ms), cheaper, limited (2MB code, 2MB memory, no network calls, viewer-only events). 5. Lambda URL: direct HTTPS endpoint for Lambda without API Gateway. Good for simple function-as-API needs. 6. Function URLs with streaming: stream response bytes progressively (useful for long-running AI responses). 7. Dead Letter Queues: async invocation failures → DLQ (SQS or SNS) for manual inspection and retry. 8. Lambda destinations: on success → send result to SQS/SNS/EventBridge/another Lambda; on failure → DLQ alternative, send context. 9. SnapStart (Java): take snapshot after initialization, restore from snapshot on cold start — 10x faster cold starts for Java. 10. Recursive loop detection: Lambda detects recursive invocations (Lambda calling itself via SQS/SNS) — built-in protection. 11. VPC Lambda: enable VPC access for private resources (RDS, ElastiCache) — adds cold start latency; use ENIs; need subnets with NAT Gateway for internet access.

Advanced AWS cost management for optimizing cloud spend: AWS Cost Explorer: analyze historical costs (up to 12 months) and forecast (3 months). Filter by service, region, tag, linked account. Rightsizing recommendations. RI/Savings Plans coverage and utilization reports. AWS Budgets: set custom cost/usage/RI/Savings Plan budgets. Alert when actual or forecasted spend exceeds threshold. Actions: notify via email/SNS, or automated action (restrict IAM, run SSM document, apply SCP). Cost Anomaly Detection: ML-based service that monitors spend patterns and alerts on unexpected increases. Per service, per tag, per linked account. Root cause analysis. Cost Allocation Tags: tag resources with cost center, project, team → Cost Explorer groups spending by tag. Enable cost allocation tags in Billing console to appear in Cost Explorer. Savings Plans vs RIs: Compute Savings Plans — flexible (any instance family, size, region, OS) up to 66% savings; EC2 Instance Savings Plans — specific instance family + region, up to 72% savings; RIs — specific instance type + region + OS, up to 75% savings (least flexible). Spot Instance management: Spot Requests → Spot Fleet → EC2 Auto Scaling with Spot. Spot Advisor shows interruption frequency per instance type. Spot + On-Demand blend: base on On-Demand, burst on Spot. Handle interruption: 2-minute warning via EventBridge → graceful shutdown, save state. AWS Compute Optimizer: ML-based rightsizing recommendations for EC2, EBS, Lambda, ECS on Fargate, Auto Scaling groups. Analyzes 14 days of CloudWatch metrics. S3 Storage Lens: organization-wide storage analytics — find unused buckets, incomplete multipart uploads, over-versioned buckets. S3 Intelligent-Tiering for automatic cost optimization.