Aisalkyn Aidarova

Posted on Oct 28

Classic solutions architecture discussions

#beginners #aws #cloud #architecture

WhatIsTheTime.com — Architecture Journey (AWS)

0) Baseline PoC

Architecture: 1× public EC2 (t2.micro) + Elastic IP (EIP).
Pros: Fast, simple, stable IP.
Cons: Single point of failure; vertical changes = downtime.

1) Vertical Scale

Action: Stop instance → change type (e.g., m5.large) → start.
IP: Still stable (EIP).
Trade-off: More capacity, but planned downtime and still 1 box.

2) Naïve Horizontal Scale (no LB)

Action: Add more EC2s, each with its own EIP; users connect by IP.
Cons: Users must know multiple IPs; EIP account/region limits (~5); no health checks; hard to add/remove nodes.

3) Route 53 “A record to instances”

Action: A record (TTL=1h) → list of instance public IPs.
Pros: No EIP management; DNS returns current IPs.
Gotcha: TTL caching. If an instance is removed, clients may keep a stale IP for up to TTL → perceived downtime.

4) Proper Horizontal Scale with Load Balancer

Action: Put ALB/NLB public; EC2s become private behind it.
DNS: Route 53 Alias record (A/AAAA Alias) → LB DNS name (LB IPs change!).
Benefits:
- Health checks: Unhealthy targets don’t receive traffic.
- No client TTL pain: LB stays constant; you can add/remove targets anytime.
- Security: SG on EC2s allows only LB SG.

5) Auto Scaling Group (ASG)

Action: ASG manages private EC2 fleet behind the LB.
Scaling: Policies by CPU, RPS, ALB request count, or target tracking.
Benefit: Right-sized capacity over the day; no manual node ops.

6) Multi-AZ High Availability

Action: Put ALB across ≥2 AZs; ASG spans ≥2 AZs (e.g., min 2, one per AZ).
Outcome: Survives AZ failure; traffic shifts automatically.
Tip: Ensure subnets in different AZs are public for ALB, private for EC2 with NAT if instances need egress.

7) Cost Optimization

Steady floor: Reserve the ASG min capacity using Reserved Instances or Compute Savings Plans.
Burst capacity: Use On-Demand or Spot via MixedInstancesPolicy (Spot for stateless, interrupt-tolerant).
Right-size: Regularly re-evaluate instance families/sizes.

Security Group (SG) Pattern (minimal)

ALB SG: Inbound 80/443 from 0.0.0.0/0; Outbound to EC2 SG on app port (e.g., 80).
EC2 SG: Inbound only from ALB SG on app port; outbound as needed.
No public IP on EC2 in private subnets.

Route 53 Records

Public site: whatisthetime.com → Alias A to ALB.
API subdomain: api.whatisthetime.com → Alias A to same/different ALB if you split tiers.
Don’t use plain A to LB IPs (they aren’t stable). Do use Alias.

Health Checks

ALB Target Group: HTTP 200 on /health (fast, lightweight).
Tune: Healthy threshold (e.g., 2), interval (e.g., 10s), timeout (e.g., 5s). Faster detection → faster failout.

ASG Essentials

Launch Template: AMI, instance profile (IAM role), SG, user data (app start).
Subnets: Private subnets across multiple AZs.
Desired/Min/Max: e.g., 2/2/6.
Scaling policy: Target tracking (e.g., 50% CPU) or ALB request count per target.

Common Gotchas (great interview talking points)

DNS TTL vs. instance churn: Use LB to avoid TTL staleness.
EIP limits and operational pain at scale.
Single-AZ ASG still fails if that AZ dies; Multi-AZ is mandatory for HA.
Health check path wrong → all targets marked unhealthy.
User data idempotence: Make bootstrapping safe on restarts.
Statelessness: Required to freely scale/replace nodes (no local session state).

Quick Lab Checklist (hands-on)

VPC: 2 public subnets (ALB), 2 private subnets (EC2) across 2 AZs; 1 NAT GW.
IAM Role: EC2 instance profile (e.g., SSM, CloudWatch logs).
ALB: Internet-facing; listener 80/443; target group HTTP:80.
ASG: Launch template + MixedInstancesPolicy (OD+Spot optional), min=2, desired=2, max=6.
Route 53: Alias whatisthetime.com → ALB.
App: Simple HTTP server returning current time + /health 200.
Test: Kill instances; watch ALB route around, ASG replace, zero user downtime.

One-liner Interview Summary

Start with a single EIP-backed EC2 (downtime on resize), then move to Route 53 A records and discover TTL issues. Fix with an internet-facing ALB and Alias record, put EC2s private behind it, add ASG for elasticity, and span multiple AZs for HA. Lock in cost on the steady floor with RIs/Savings Plans, burst with On-Demand/Spot, and rely on health checks and SG-to-SG rules for resilience and security.

MyClothes.com — Stateful, Multi-Tier, Scalable Architecture

1️⃣ Problem

Users add clothes to a shopping cart.
Requests can hit different EC2 instances → cart lost.
Goal: Keep the web tier stateless so scaling remains easy.

2️⃣ Solutions to Handle State

A. ELB Stickiness (Session Affinity)

ELB keeps user → same backend EC2.
Works short-term; simple to enable.
❌ Loses session if instance terminates.
❌ Not horizontally resilient.

B. Store Cart in Client Cookies

Cart data stored in browser cookies.
Every request sends full cart info → any EC2 can rebuild state.
✅ Web tier fully stateless.
⚠️ Size limit: 4 KB per cookie.
⚠️ Security: must validate data integrity.
⚠️ Performance: heavier HTTP payloads.

C. Server-Side Sessions via ElastiCache (Redis/Memcached)

Client keeps only Session ID (small cookie).
EC2 instances store/retrieve cart data in ElastiCache using that session ID.
✅ Millisecond latency, centralized truth.
✅ Survives instance rotation.
✅ Easy horizontal scale.
⚠️ Cache invalidation required; session expiry policy needed.
🔁 Alternative: store sessions in DynamoDB (fully managed, persistent).

3️⃣ Persistent User Data Layer

Long-term info (user profiles, addresses, orders) → RDS.
EC2 → RDS via secure SG reference.
✅ Structured relational storage.
✅ Multi-AZ standby (automatic failover).
✅ Read replicas (scale reads up to 15).

4️⃣ Read Scaling & Caching Patterns

RDS Read Replicas

Reads go to replicas → lighten primary write load.
Async replication delay possible (~seconds).

ElastiCache Lazy Loading

EC2 → ElastiCache → if miss → fetch from RDS → populate cache.
✅ Faster user experience.
✅ Less CPU on DB.
⚠️ Need cache invalidation policy (TTL, write-through).

5️⃣ Multi-AZ & High Availability

Layer	HA Feature	Notes
Route 53	Globally redundant	Alias to ALB
ALB	Multi-AZ	Public subnets
ASG	Multi-AZ	Private subnets across 2–3 AZs
RDS	Multi-AZ standby + replicas	Auto failover
ElastiCache	Redis Multi-AZ replication groups	Optional cross-AZ failover

6️⃣ Security Groups (SG-to-SG Reference Model)

ALB SG: Inbound 80/443 from 0.0.0.0/0 → Outbound to EC2 SG.
EC2 SG: Inbound only from ALB SG → Outbound to ElastiCache + RDS SGs.
ElastiCache SG: Inbound only from EC2 SG.
RDS SG: Inbound only from EC2 SG.
❌ No public access to EC2/RDS/ElastiCache.

7️⃣ Architecture Summary (3-Tier Pattern)

          [ Users ]
             │
        [ Route 53 ]
             │
        [ ALB (Multi-AZ) ]
             │
   ┌───────────────────────┐
   │  Auto Scaling Group   │
   │  EC2 Web Tier (Stateless)
   │   ↳ Session in ElastiCache
   │   ↳ Persistent data in RDS
   └───────────────────────┘
        │            │
 [ElastiCache]    [RDS Multi-AZ + Read Replicas]
 (session/cache)   (user, orders)

8️⃣ Key Takeaways for Solutions Architects

Concern	Solution	AWS Component
Stateless web tier	Offload state to cache/db	ElastiCache / DynamoDB
Sticky user sessions	ELB stickiness (temporary)	ALB feature
Session persistence	Session ID + cache	Redis/Memcached
Persistent data	Central DB	RDS
Scale reads	Read replicas / cache	RDS / ElastiCache
Disaster recovery	Multi-AZ everywhere	ALB, ASG, RDS, Redis
Security	SG chaining	SG references
Performance	Cache reads, offload RDS	Lazy loading pattern
Cost	Right-size instances, use caching	RI + cache hit ratio

9️⃣ One-Sentence Summary (Interview-Ready)

MyClothes.com is a 3-tier, stateless-web, stateful-data architecture using ALB + ASG + Multi-AZ RDS + ElastiCache (Redis).
Stateless EC2s hold no session; session data lives in cache; persistent data lives in RDS; all layers are Multi-AZ and secured via SG-to-SG references.

MyWordPress.com — Scalable Stateful Web App on AWS

1️⃣ Overview

WordPress = stateful, because it stores:

User content → database (MySQL/Aurora)
Uploaded media → shared file system (images, videos)
App files/config → web tier (PHP/Apache)

Goal: make it scalable, multi-AZ, and highly available.

2️⃣ Database Layer

Option 1: Amazon RDS (MySQL)

Multi-AZ (synchronous standby)
Optional Read Replicas for scaling reads
Managed backups, patching

Option 2: Amazon Aurora (MySQL-compatible)

Fully managed, auto-healing, auto-scaling
Multi-AZ by design
Up to 15 read replicas
Optionally Global Database for worldwide reads

✅ Use Aurora if you want fewer ops and global scalability.

3️⃣ Storage Layer: EBS vs EFS

EBS (Elastic Block Store)

Attached to one EC2 instance in one AZ
Good for single-instance setup ❌ Not shared between instances ❌ Data not accessible across AZs

EFS (Elastic File System)

NFS (Network File System) managed by AWS
Mountable from multiple EC2s across AZs
Each AZ gets its own ENI (Elastic Network Interface) for EFS access
Files instantly available to all web servers

✅ Best choice for WordPress uploads directory (/wp-content/uploads)

4️⃣ Web Tier Architecture

ALB (Application Load Balancer) → public entry point
ASG (Auto Scaling Group) → EC2 (Apache/PHP/WordPress)
EC2s in private subnets across ≥2 AZs
EC2 mounts EFS for shared media
EC2 connects to Aurora for posts, users, metadata
EC2 bootstraps via User Data script (install + config WordPress)

5️⃣ DNS & Routing

Route 53 Alias → ALB DNS name
Users hit mywordpress.com
ALB → target group (EC2 instances)
Sticky sessions not required (WordPress sessions handled via DB/cache)

6️⃣ High Availability & Scalability

Layer	HA Feature	Scaling
ALB	Multi-AZ	Automatically handles targets
ASG	Multi-AZ	Scale in/out based on CPU or request count
Aurora	Multi-AZ + Replicas	Scale reads; failover for writes
EFS	Multi-AZ mount targets	Scales automatically
Route 53	Multi-region DNS failover (optional)	Global endpoint

7️⃣ Security Group Design

ALB SG: allow inbound 80/443 from 0.0.0.0/0; outbound → EC2 SG
EC2 SG: inbound from ALB SG on port 80; outbound → EFS SG (2049), Aurora SG (3306)
EFS SG: inbound from EC2 SG on 2049
Aurora SG: inbound from EC2 SG on 3306

8️⃣ Backup & Disaster Recovery

Aurora Backups & Snapshots → daily automated + manual
EFS Lifecycle Policy → move old files to EFS-IA (cheaper)
Cross-Region Replication
- Aurora Global DB → multi-region reads/failover
- EFS Replication → to secondary region (optional)

9️⃣ Cost Optimization

Component	Optimization
Aurora	Use Serverless v2 or Reserved Instances
EFS	Enable Lifecycle Policy (IA tier)
EC2	Use Auto Scaling + Reserved/Spot Mix
ALB	Shared ALB for multiple apps if possible

🔟 Architecture Diagram (conceptual)

             [ Users ]
                │
         [ Route 53 ]
                │
          [ ALB (Multi-AZ) ]
                │
     ┌─────────────────────────┐
     │ Auto Scaling Group (EC2)│
     │ WordPress + Apache/PHP  │
     │ Mounts shared /wp-content/uploads
     └─────────────────────────┘
          │              │
     [ Amazon EFS ]   [ Aurora MySQL ]
     Shared Media     Multi-AZ + Read Replicas

✅ Key Takeaways for Solution Architects

Concept	AWS Service	Why
Shared file storage	EFS	Needed for uploads consistency
Database HA	Aurora (MySQL)	Simplifies scaling and failover
Load balancing	ALB	Multi-AZ entry, HTTP/HTTPS
Compute elasticity	ASG (EC2)	Scale based on demand
DNS & routing	Route 53 Alias	Stable domain endpoint
Resilience	Multi-AZ + backups	Survives single-AZ failure
Cost control	Lifecycle & reserved capacity	Efficient scaling

🧠 One-liner (Interview-Ready)

MyWordPress.com uses ALB + Auto Scaling EC2s + EFS + Aurora MySQL (Multi-AZ) to achieve a highly available, scalable WordPress deployment, where EFS centralizes uploaded media and Aurora stores content and users.

MyWordPress.com — Scalable WordPress Architecture on AWS

1️⃣ Objective

Build a fully scalable, highly available WordPress site where:

Multiple EC2 instances serve the same site content.
Uploaded media (images, videos) are accessible from all instances.
Blog data (posts, users, settings) are stored in a managed database.
The solution is fault-tolerant and globally scalable.

2️⃣ Core Challenges

Problem	Why it Matters
Uploads stored locally (EBS)	Works only with one instance; fails in Multi-AZ or Auto Scaling setups.
Database consistency	Must be highly available and durable for posts, users, settings.
Global scalability	Users worldwide need fast reads and reliable writes.

3️⃣ Database Layer

✅ Aurora MySQL

Drop-in replacement for MySQL RDS.
Multi-AZ by default (one primary, multiple read replicas).
Up to 15 read replicas (faster read scaling).
Global Database option for cross-region replication.
Automatic failover and backups → less admin work.

💡 Trade-off: Aurora costs more than RDS, but offers better performance and scalability.

4️⃣ Storage Layer: EBS vs. EFS

❌ EBS (Elastic Block Store)

Block storage attached to a single EC2 instance in one AZ.
Great for single-server setups.
❌ Not shareable across instances or AZs.
❌ Causes missing uploads when traffic is load balanced.

✅ EFS (Elastic File System)

Managed NFS (Network File System) accessible from multiple EC2s across AZs.
Automatically grows/shrinks as files are added or removed.
Multi-AZ architecture using ENIs (Elastic Network Interfaces) in each AZ.
Perfect for /wp-content/uploads directory in WordPress.

💡 Trade-off: EFS is more expensive than EBS, but essential for multi-instance architectures.

5️⃣ Web Tier (Application Layer)

Auto Scaling Group (ASG) spans multiple AZs.
EC2 instances: install WordPress + Apache/PHP.
Mount EFS at /var/www/html/wp-content/uploads.
Connect to Aurora MySQL for data.
User Data bootstrap script installs WordPress automatically.
ALB (Application Load Balancer) distributes traffic evenly.

6️⃣ High-Level Architecture

         [ Users ]
            │
      [ Route 53 DNS ]
            │
     [ ALB (Multi-AZ) ]
            │
 ┌─────────────────────────┐
 │ Auto Scaling Group (EC2)│
 │  WordPress + Apache/PHP │
 │  Mounted EFS Volume     │
 └─────────────────────────┘
     │               │
 [Amazon EFS]     [Aurora MySQL]
 Shared Uploads   Multi-AZ DB

7️⃣ High Availability (HA)

Layer	HA Strategy
ALB	Multi-AZ
ASG	Multi-AZ EC2s
Aurora	Multi-AZ + Read Replicas
EFS	Multi-AZ mount targets
Route 53	Global DNS + health checks

8️⃣ Security Groups

Component	Inbound	Outbound
ALB	`0.0.0.0/0` on 80/443	To EC2 SG
EC2	From ALB SG	To Aurora SG (3306), EFS SG (2049)
Aurora	From EC2 SG (3306)	-
EFS	From EC2 SG (2049)	-

9️⃣ Optional Enhancements

CloudFront + S3 Offloading: Store and serve images from S3, cache via CloudFront CDN for global reach.
Aurora Global Database: Multi-region read replicas for global scaling.
EFS Lifecycle Policy: Move old uploads to Infrequent Access (EFS-IA) to reduce costs.
AWS Backup: Manage snapshots for Aurora and EFS centrally.

🔟 Cost Optimization Tips

Component	Optimization
EC2	Use ASG + Spot + Reserved mix
Aurora	Serverless v2 or Savings Plans
EFS	Lifecycle to IA + burst throughput
ALB	Shared across multiple apps if possible

✅ Key Takeaways

Concept	Service	Purpose
Shared file storage	EFS	Keeps uploads consistent across instances
Managed DB	Aurora (MySQL)	Reliable, Multi-AZ backend
Load balancing	ALB	Public access + even traffic
Auto scaling	ASG (EC2)	Elastic web tier
Multi-AZ fault tolerance	Aurora + EFS + ALB	Survive AZ outage
Global scalability	Aurora Global DB / CloudFront	Low latency reads
Cost control	Lifecycle policies + mixed instance types	Optimized operations

🧠 Interview Summary (One Sentence)

MyWordPress.com uses ALB + Auto Scaling EC2s + shared EFS + Aurora MySQL (Multi-AZ) to host a highly available, scalable WordPress site, ensuring all instances share media via EFS and data via Aurora.

Quick Deployment & Fast Application Instantiation in AWS

1️⃣ Problem

When launching a full environment (EC2, RDS, EBS, etc.), setup can take time:

Installing apps and dependencies
Loading data or schemas
Configuring settings (URLs, credentials)
Bootstrapping environments

We want faster deployments — especially for Auto Scaling, disaster recovery, or blue/green environments.

2️⃣ EC2 Startup Acceleration Methods

A. Golden AMI

Prebuild and bake an Amazon Machine Image (AMI) with:
- OS updates
- Application code
- Libraries/dependencies
- Config templates
Launch new EC2 instances directly from this Golden AMI.

✅ Benefits

Instant launch (everything preinstalled)
Consistent configuration
Reduces provisioning time dramatically

💡 Use Case: Auto Scaling Groups launching web servers from a pre-baked WordPress or Nginx AMI.

B. User Data (Bootstrapping)

User Data scripts run automatically at instance startup.
Used for dynamic setup such as:
- Fetching credentials or endpoints
- Configuring app environment variables
- Registering with load balancers
- Starting services

✅ Best Practice

Use User Data for dynamic config only, not heavy software installs.
Combine with Golden AMI for speed and flexibility.

💡 Example:

#!/bin/bash
# EC2 user data
DB_ENDPOINT=$(aws ssm get-parameter --name "/myapp/db_endpoint" --query "Parameter.Value" --output text)
sed -i "s/DB_HOST_PLACEHOLDER/$DB_ENDPOINT/" /var/www/html/config.php
systemctl restart httpd

C. Hybrid Approach (Golden AMI + User Data)

Base AMI already contains app code/dependencies.
User Data customizes runtime configuration per environment (dev, stage, prod).

✅ Used by Elastic Beanstalk

EB internally uses a prebaked AMI + environment-level user data.

3️⃣ RDS: Faster Database Provisioning

Use Snapshots

Instead of creating a new empty DB and re-running migrations or inserts:
- Restore from an RDS snapshot
- Schema and data appear instantly.

✅ Benefits

Fast recovery & cloning
Ideal for DR or staging environments

💡 You can even share RDS snapshots across accounts.

4️⃣ EBS: Faster Volume Initialization

Use EBS Snapshots

Create new EBS volumes from a snapshot rather than formatting blank storage.

✅ Benefits

Volume already formatted and preloaded with data.
Ideal for restoring logs, config files, or cached data quickly.

💡 Tip: EBS lazy-loads snapshot data; use fio to pre-warm for max performance.

5️⃣ Summary Table

Component	Method	Purpose	Example
EC2	Golden AMI	Prebake software for fast launch	Nginx, PHP, WordPress baked in
EC2	User Data	Dynamic config at startup	Fetch DB endpoint, update config
EC2	Hybrid	Mix of both	Elastic Beanstalk-style setup
RDS	Restore Snapshot	Instant schema & data recovery	Restore production backup
EBS	Snapshot Restore	Preformatted, preloaded volume	Mount and run instantly

6️⃣ Exam/Interview Key Takeaways

Golden AMI: Fastest EC2 provisioning → identical servers at scale.
User Data: Lightweight config → runtime flexibility.
Snapshots: Quick restore → minimal downtime for DBs and disks.
Elastic Beanstalk: Real-world example of AMI + User Data hybrid.
Best Practice: Keep repeatable installs in AMIs, dynamic info in boot scripts.

🧠 One-Liner Summary

To launch environments faster, use Golden AMIs for preinstalled apps, User Data for dynamic config, and restore RDS/EBS from snapshots instead of rebuilding from scratch.

Elastic Beanstalk (EB) — Simplifying Application Deployment

1️⃣ The Challenge

Every web app we built so far included:

ALB (Load Balancer)
Auto Scaling Group (ASG) with EC2s across AZs
RDS (database) and sometimes ElastiCache (cache)

👉 Building this manually every time = complex and slow.
👉 Developers want to focus on code, not infrastructure.

2️⃣ What Is Elastic Beanstalk?

Elastic Beanstalk (EB) is a developer-centric PaaS that:

Automatically provisions the underlying AWS resources (EC2, ASG, ELB, RDS, etc.)
Deploys and manages your application code
Handles capacity, scaling, monitoring, and health checks
Lets you still retain full access to the underlying resources

✅ You pay only for the resources (EC2, RDS, etc.),
not for Beanstalk itself — Beanstalk is free.

3️⃣ Key Components

Component	Description
Application	Logical container for your code, configurations, and environments
Application Version	A specific, uploaded version of your code (e.g., `v1`, `v2`)
Environment	Running version of your app + its resources (ASG, ELB, EC2, RDS)
Configuration Template	Blueprint defining environment type, instance size, scaling, etc.

You can have multiple environments under one app, e.g.:

MyApp
 ├── Dev Environment
 ├── Test Environment
 └── Prod Environment

4️⃣ Beanstalk Tiers

A. Web Server Environment Tier

Standard web apps accessed via HTTP/HTTPS.
Architecture:

  Users → ALB → ASG (EC2 Web Servers)

EC2s run your app (PHP, Node.js, Java, etc.).
Scales based on load metrics (CPU, latency).

B. Worker Environment Tier

Background or asynchronous jobs.
Messages are sent to SQS queue, consumed by worker EC2s.
Scales based on SQS queue length.
Ideal for batch processing, email sending, video conversion, etc.

💡 You can connect both tiers:
Web app pushes messages → Worker environment processes them.

5️⃣ Deployment Options

Mode	Description	Best For
Single Instance	One EC2 instance with optional EIP & RDS	Dev/Test
High Availability	Multi-AZ ASG + ALB + optional RDS (Multi-AZ)	Production

6️⃣ Supported Platforms

Elastic Beanstalk supports major programming stacks:

Language / Platform	Example
Go	Web backend
Java SE / Tomcat	Spring Boot apps
.NET Core / .NET on Windows	Enterprise apps
Node.js	REST APIs
PHP	WordPress
Python	Flask, Django
Ruby	Rails
Docker (Single or Multi-Container)	Any containerized app

7️⃣ Deployment Lifecycle

Create Application
Upload Version (ZIP or WAR or Docker image)
Launch Environment (web or worker tier)
Manage Lifecycle

Scale up/down
Monitor health
Update configurations
1. Update Version (upload new code → deploy)

8️⃣ Scaling & Health

Auto Scaling: Adjusts EC2 capacity automatically.
Elastic Load Balancer: Distributes traffic evenly.
Health Monitoring: Beanstalk dashboard + CloudWatch integration.
Rolling / Blue-Green Deployments supported for zero downtime.

9️⃣ Pricing Model

Elastic Beanstalk service itself → $0
You pay for:
- EC2 instances
- Load balancer
- RDS
- EBS volumes
- Data transfer

🔟 Architecture Summary

Web Tier (High Availability)

           [ Users ]
              │
          [ ALB ]
              │
   ┌──────────────────────┐
   │  ASG (EC2 Instances) │
   │  WordPress / AppCode │
   └──────────────────────┘
              │
         [ RDS Database ]

Worker Tier (Optional)

[ Web Tier ] → [ SQS Queue ] → [ Worker ASG (EC2s) ]

✅ Key Takeaways

Concept	Description
Elastic Beanstalk	Simplifies app deployment (PaaS)
Web vs Worker Tier	Web = front-end, Worker = background jobs
Hybrid Deployment	Web pushes messages to Worker via SQS
Scaling	Auto Scaling + Load Balancer
Deployment Choices	Single instance (dev) or Multi-AZ HA (prod)
Languages Supported	Go, Java, .NET, Node.js, PHP, Python, Ruby, Docker
Cost	Only underlying resources are billed

🧠 One-Liner (Interview Summary)

Elastic Beanstalk is AWS’s PaaS that lets developers deploy code fast without managing infrastructure — it automatically provisions ALB, ASG, EC2, RDS, supports multi-language apps, and offers web + worker tiers for scalable architectures.