← Tutorials 🤖 AI 📓 Architect's Notebook ☁ AWS 📋 Cheatsheet 🗃 Databases 🚀 DevOps 🧩 DSA ❓ FAQ 🖥 Frontend ☕ Java 🍏 MongoDB 🐍 Python 🌿 Spring Boot 🏗 System Design 🏛 TOGAF
Tutorials › AWS

Getting Started with AWS

☁️ AWS · Getting Started · 8 min read

Amazon Web Services (AWS) is the world's most widely adopted cloud platform — a collection of 200+ on-demand services (compute, storage, databases, networking, ML) billed pay-as-you-go. Instead of buying and racking your own servers, you rent capacity from Amazon's global infrastructure and scale it up or down in minutes.

Why Cloud / Why AWS

  • No upfront cost — pay only for what you use (per second/hour/GB)
  • Elasticity — scale from 1 server to 1,000 and back automatically
  • Global reach — deploy in any of 30+ Regions in minutes
  • Managed services — Amazon runs the databases, queues, and load balancers so you don't

Global Infrastructure

Understanding AWS geography is the foundation of every exam question and every real architecture.

Region

A physical geographic area (e.g. us-east-1 N. Virginia, ap-south-1 Mumbai). Most services are region-scoped. Choose based on latency, compliance, price, and service availability.

Availability Zone (AZ)

One or more discrete data centers within a Region, isolated from failures but linked by low-latency fiber. A Region has 3–6 AZs (e.g. us-east-1a, 1b, 1c).

Edge Location

400+ Points of Presence used by CloudFront and Route 53 to cache content close to users globally.

Local / Wavelength Zones

Infrastructure placed in large metros or 5G networks for ultra-low latency to end users.

Visual: How the Pieces Nest

AWS Region — ap-south-1 (Mumbai) AZ-1a (data centers) EC2 · EBS · RDS primary Subnet 10.0.1.0/24 AZ-1b (data centers) EC2 · EBS · RDS standby Subnet 10.0.2.0/24 AZ-1c (data centers) EC2 · Auto Scaling Subnet 10.0.3.0/24 Global services on top: IAM · Route 53 · CloudFront · WAF · Billing

How to Implement — AWS Console (First Steps)

  1. Create an AWS account at aws.amazon.com (the email becomes the root user).
  2. Enable MFA on the root user immediately, then stop using root for daily work.
  3. Open IAM → create an admin IAM user/role for yourself.
  4. Set a Billing budget & alert (Billing → Budgets) so a surprise spend emails you.
  5. Pick your default Region (top-right dropdown) closest to your users.

How to Implement — Spring Boot (AWS SDK Setup)

Spring apps talk to AWS through the AWS SDK for Java v2. The cleanest integration is Spring Cloud AWS, which auto-configures clients from properties.

// pom.xml — BOM + a starter per service you use <dependencyManagement> <dependencies> <dependency> <groupId>io.awspring.cloud</groupId> <artifactId>spring-cloud-aws-dependencies</artifactId> <version>3.2.0</version> <type>pom</type><scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependency> <groupId>io.awspring.cloud</groupId> <artifactId>spring-cloud-aws-starter-s3</artifactId> </dependency>
# application.yml — never hardcode keys; use the default credentials chain spring: cloud: aws: region: static: ap-south-1 # credentials picked up from: env vars → ~/.aws/credentials → IAM role
💡 Credential best practice: On your laptop use aws configure (a profile in ~/.aws/credentials). In production on EC2/ECS/Lambda, attach an IAM role — the SDK fetches temporary credentials automatically, so you never ship long-lived keys.

AWS Identity & Access Management (IAM)

☁️ AWS · Security Foundation · 10 min read

IAM controls who (authentication) can do what (authorization) on which AWS resources. It is global (not region-scoped), free, and the single most important service to get right — almost every security incident traces back to over-permissive IAM.

Core Building Blocks

Users

A human identity with long-term credentials (password for console, access keys for CLI/SDK). One user = one person.

Groups

A collection of users. Attach policies to the group; membership grants the permissions. Groups cannot be nested.

Roles

An identity with temporary credentials, assumed by a service (EC2, Lambda), a user, or another account. The right way to grant app permissions.

Policies

JSON documents listing allowed/denied actions on resources. Attached to users, groups, or roles.

How a Policy Reads

// Allow read-only access to one S3 bucket { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::my-app-bucket", "arn:aws:s3:::my-app-bucket/*" ] }] }

Evaluation logic: an explicit Deny always wins → otherwise an Allow grants → default is implicit deny.

Visual: How an EC2 App Gets Permissions via a Role

EC2 Instance (your Spring app) IAM Role + permission policy S3 / DynamoDB resource assumes temp creds No access keys on the server — STS issues rotating temporary credentials.

How to Implement — AWS Console

  1. IAM → Users → Create user → attach to a group (e.g. Developers).
  2. IAM → Policies → create a least-privilege policy or pick an AWS-managed one.
  3. IAM → Roles → Create role → trusted entity AWS service → EC2 → attach the policy.
  4. Attach the role to your EC2 instance (Actions → Security → Modify IAM role).
  5. Enable IAM Access Analyzer and turn on MFA for all human users.

How to Implement — Spring Boot

Your code never references credentials. The SDK's default credential provider chain finds the EC2/ECS role automatically:

@Configuration public class AwsConfig { @Bean S3Client s3Client() { return S3Client.builder() .region(Region.AP_SOUTH_1) // DefaultCredentialsProvider walks: env → profile → IAM role .credentialsProvider(DefaultCredentialsProvider.create()) .build(); } }
⚠️ Never commit access keys to Git or bake them into a Docker image. Use IAM roles in prod and aws-vault/SSO locally. Rotate any key that leaks immediately.

Amazon EC2 — Basics

☁️ AWS · Compute · 10 min read

Amazon Elastic Compute Cloud (EC2) is a virtual server in the cloud. You choose an OS image, a hardware size, networking and storage, and you get a running Linux/Windows machine in seconds — billed per second while it runs.

The Five Choices When Launching

AMI

Amazon Machine Image — the OS + pre-installed software template (Amazon Linux, Ubuntu, your own golden image).

Instance Type

The hardware: family + size, e.g. t3.micro (2 vCPU, 1 GB). Families: t/m general, c compute, r/x memory, g/p GPU.

EBS Volume

Network-attached disk that persists independently of the instance (root + extra data volumes).

Security Group

A stateful virtual firewall — inbound/outbound rules by port, protocol, and source IP/SG.

Key Pair

SSH public/private key for login. Download the .pem once — AWS keeps only the public half.

User Data

A bootstrap script that runs once at first boot — install packages, pull your app, start services.

Security Groups — The #1 Gotcha

  • Stateful: if inbound is allowed, the response is automatically allowed out.
  • You can only write Allow rules — there is no deny rule (use NACLs for deny).
  • Can reference another security group as a source (e.g. "allow web-SG to reach db-SG on 5432").
  • Common: open 22 (SSH) to your IP only, 80/443 to the world, 8080 to the load-balancer SG.

Visual: A Minimal EC2 Web Server

User Security Group (firewall): allow 443, 22 from you EC2 Instance t3.micro · Amazon Linux Spring Boot :8080 EBS Volume gp3 root disk

How to Implement — AWS Console

  1. EC2 → Launch instance → name it.
  2. Pick AMI (Amazon Linux 2023) and type (t3.micro, free-tier eligible).
  3. Create/select a key pair.
  4. Network: choose VPC/subnet, create a security group (22 from My IP, 443 from anywhere).
  5. Add User data to bootstrap (install Java, run your jar — below).
  6. Launch, then connect via EC2 Instance Connect or SSH.
#!/bin/bash — EC2 User Data: install Java & run your Spring Boot jar dnf install -y java-21-amazon-corretto aws s3 cp s3://my-app-artifacts/app.jar /opt/app.jar java -jar /opt/app.jar --server.port=8080

How to Implement — Spring Boot

A Spring Boot fat-jar runs anywhere with a JVM, so deploying to EC2 is literally "copy jar + java -jar". Bind to all interfaces and externalize the port so a load balancer can reach it:

# application.yml server: port: 8080 address: 0.0.0.0 management: endpoints: web: exposure: include: health # /actuator/health for the load balancer health check
💡 For production, don't hand-bootstrap. Bake an AMI (Packer), or run the jar as a systemd service so it restarts on crash and on reboot, and put the instance behind an ALB + Auto Scaling Group (next topics).

Amazon EC2 — Associate

☁️ AWS · Compute (Deep Dive) · 12 min read

Beyond launching one box, the Associate level is about cost optimization, placement, and networking — how you buy capacity and how instances connect.

Purchasing Options (Cost Optimization)

OptionDiscountBest for
On-Demand0% (baseline)Short, unpredictable, spiky workloads
Reserved (1/3 yr)up to 72%Steady-state, always-on servers
Savings Plansup to 72%Commit to $/hr spend, flexible across families
Spot Instancesup to 90%Fault-tolerant batch, CI, big-data (can be reclaimed)
Dedicated HostCompliance / BYOL licensing needs

Networking — Public vs Private vs Elastic IP

  • Private IP — fixed, used inside the VPC. Always present.
  • Public IP — changes every stop/start. Free while running.
  • Elastic IP (EIP) — a static public IP you own and can remap. Charged when not attached to a running instance.
  • ENI — Elastic Network Interface, a virtual NIC you can detach/reattach to another instance for failover.

Placement Groups

Cluster

Pack instances in one AZ for the lowest latency / highest throughput (HPC). Risk: AZ failure takes all.

Spread

Each instance on distinct hardware across AZs (max 7/AZ). Maximum fault isolation for critical apps.

Partition

Groups of racks (partitions) isolated from each other — for large distributed systems like Kafka/HDFS.

Visual: Spot + On-Demand Mixed Fleet

Auto Scaling Group mixed instances policy 2 On-Demand (baseline) up to 8 Spot (-90% cost) Steady core +cheap burst capacity

How to Implement — AWS Console

  1. EC2 → Spot Requests → request a Spot fleet for batch jobs.
  2. EC2 → Elastic IPs → allocate → associate with an instance for a stable address.
  3. EC2 → Placement groups → create (cluster/spread/partition) before launch.
  4. Billing → Savings Plans → commit to a $/hr rate for steady workloads.

How to Implement — Spring Boot (Graceful Spot Shutdown)

Spot instances get a 2-minute termination notice. Enable graceful shutdown so in-flight requests finish before the JVM dies:

# application.yml — drain connections on SIGTERM server: shutdown: graceful spring: lifecycle: timeout-per-shutdown-phase: 25s
@Component class SpotInterruptionWatcher { // poll EC2 instance metadata for the spot termination notice @Scheduled(fixedRate = 5000) void check() { // GET http://169.254.169.254/latest/meta-data/spot/instance-action // if 200 → deregister from ALB, stop accepting new work } }

Amazon EC2 — Instance Storage

☁️ AWS · Storage for Compute · 10 min read

EC2 instances need disks. AWS offers three very different kinds — get the distinction right or you will lose data.

The Three Storage Types

EBS (Elastic Block Store)

Network-attached, durable block storage. Persists when the instance stops. One volume → one instance (except io2 Multi-Attach). Like a virtual hard drive.

Instance Store

Physical disk on the host — extremely fast (NVMe) but ephemeral: data is lost on stop/terminate/hardware failure. For cache/scratch only.

EFS (Elastic File System)

Managed NFS shared file system. Mountable by many instances across AZs at once. Scales automatically. Linux only.

EBS Volume Types

TypeUse caseNote
gp3 (SSD)General purpose, most workloadsDefault. Provision IOPS/throughput independently.
io2 Block Express (SSD)High-performance DBsUp to 256k IOPS; Multi-Attach capable.
st1 (HDD)Big-data, log processing (throughput)Cannot be a boot volume.
sc1 (HDD)Cold, infrequent accessCheapest.

Snapshots

  • Point-in-time backup of an EBS volume, stored incrementally in S3.
  • Copy across Regions for DR; create an AMI from a snapshot.
  • Data Lifecycle Manager (DLM) automates scheduled snapshots and retention.

Visual: EBS vs Instance Store vs EFS

EC2 #1 EC2 #2 EBS (1:1, persistent) Instance Store (fast, lost) EFSshared, multi-AZ

How to Implement — AWS Console

  1. EC2 → Volumes → Create volume (gp3) in the same AZ as the instance → Attach.
  2. On the instance: mkfs -t xfs /dev/xvdf then mount it; add to /etc/fstab.
  3. EC2 → Snapshots → Create snapshot; or set up Lifecycle Manager for automatic backups.
  4. For shared storage: EFS → Create file system → mount with the EFS helper on each instance.

How to Implement — Spring Boot

Apps usually don't touch raw block devices. The pattern that matters: keep the instance stateless — write uploads to S3/EFS, not the local disk, so any instance can be replaced freely.

# Bad: local disk on an ephemeral instance — lost on scale-in file.transferTo(new File("/tmp/uploads/" + name)); # Good: durable shared storage spring.servlet.multipart.location=/mnt/efs/uploads # EFS mount, or # better: stream straight to S3 (see the S3 topic)
💡 Rule of thumb: EBS = boot + single-instance databases · Instance Store = throwaway cache · EFS = shared files across a fleet · S3 = object uploads/artifacts (preferred for web apps).

High Availability & Scalability

☁️ AWS · Architecture · 12 min read

Two related but distinct goals. Scalability = handle more load (vertical = bigger box; horizontal = more boxes). High availability = survive failures (run across multiple AZs so one data-center outage doesn't take you down). On AWS these are delivered by three services working together: ELB + Auto Scaling Groups + multi-AZ.

Elastic Load Balancers (ELB)

TypeLayerUse for
ALB (Application)L7 (HTTP/S)Web apps, path/host routing, microservices, containers
NLB (Network)L4 (TCP/UDP)Extreme performance, static IP, TCP services
GWLB (Gateway)L3Deploy 3rd-party firewalls/appliances

ALBs do health checks (e.g. /actuator/health), route only to healthy targets, terminate TLS, and support sticky sessions.

Auto Scaling Groups (ASG)

  • Maintains a desired count between min and max; replaces unhealthy instances automatically.
  • Dynamic scaling: Target Tracking (e.g. keep CPU at 50%), Step, or Scheduled policies.
  • Spreads instances across AZs for availability; integrates with the ALB target group.

Visual: The Classic Highly-Available Web Tier

Users ALBhealth checks AZ-a EC2 (app) EC2 (app) Auto Scaling Group (min 2 / max 8) AZ-b EC2 (app) EC2 (app) scales out on CPU > 50%

How to Implement — AWS Console

  1. EC2 → Launch Template → define AMI, type, user-data, SG (the ASG blueprint).
  2. EC2 → Target Groups → create, set health check to /actuator/health.
  3. EC2 → Load Balancers → create an ALB → listener 443 → forward to the target group.
  4. EC2 → Auto Scaling Groups → use the launch template, select 2+ AZs, attach the target group.
  5. Add a Target Tracking policy (CPU 50%); set min 2, desired 2, max 8.

How to Implement — Spring Boot

For horizontal scaling, your app must be stateless — any instance can serve any request. The two big rules:

// 1) Don't store session in memory — use a shared store (Redis/ElastiCache) // pom: spring-session-data-redis + spring-boot-starter-data-redis spring.session.store-type=redis // 2) Expose a real health check for the ALB target group management.endpoint.health.probes.enabled=true management.endpoints.web.exposure.include=health,info
// Custom health indicator — ALB only routes when this is UP @Component class DbHealth implements HealthIndicator { public Health health() { return dbReachable() ? Health.up().build() : Health.down().withDetail("db","unreachable").build(); } }
💡 HA checklist: ≥2 AZs · stateless app + external session store · ALB health checks · ASG min ≥ 2 · Multi-AZ database. Lose any single AZ and the site stays up.

RDS, Aurora & ElastiCache

☁️ AWS · Managed Databases · 12 min read

Running your own database on EC2 means patching, backups, replication, and failover are your problem. RDS, Aurora, and ElastiCache hand all of that to AWS.

Amazon RDS

Managed relational database supporting PostgreSQL, MySQL, MariaDB, Oracle, SQL Server. AWS handles provisioning, patching, automated backups (point-in-time restore), and monitoring.

Multi-AZ

Synchronous standby replica in another AZ. Automatic failover (~60–120s). For availability, not scaling — standby takes no reads.

Read Replicas

Up to 15 async replicas to scale reads. App sends reads to replicas, writes to primary. Can be cross-region.

Amazon Aurora

  • AWS's cloud-native MySQL/PostgreSQL-compatible engine — up to 5× MySQL / 3× PostgreSQL throughput.
  • Storage auto-grows to 128 TB; 6 copies across 3 AZs; self-healing.
  • Aurora Serverless v2 auto-scales capacity; Global Database for cross-region DR.

Amazon ElastiCache

Managed Redis or Memcached — in-memory cache to offload the database and store sessions, leaderboards, rate-limit counters. Sub-millisecond reads.

Visual: Cache-Aside + Read Replicas

Spring AppRDS Proxy ElastiCache Redis1) check cache RDS Primarywrites Read Replicareads Cache miss → DB →write back to cache

How to Implement — AWS Console

  1. RDS → Create database → PostgreSQL → enable Multi-AZ.
  2. Place it in private subnets; SG allows 5432 only from the app's SG.
  3. Add a read replica for read scaling if needed.
  4. ElastiCache → create a Redis cluster (cluster mode + Multi-AZ) in the same VPC.
  5. Store DB credentials in Secrets Manager (auto-rotation), not in config.

How to Implement — Spring Boot

# application.yml — point at RDS & ElastiCache spring: datasource: url: jdbc:postgresql://mydb.xxxx.ap-south-1.rds.amazonaws.com:5432/app username: ${DB_USER} password: ${DB_PASS} # injected from Secrets Manager hikari: maximum-pool-size: 10 data: redis: host: my-redis.xxxx.cache.amazonaws.com port: 6379
// Cache-aside with Spring Cache + Redis — one annotation @Cacheable(value = "products", key = "#id") public Product findById(Long id) { return repo.findById(id).orElseThrow(); // only runs on cache miss }
💡 Use RDS Proxy in front of RDS for serverless/Lambda or high-concurrency apps — it pools and shares DB connections, preventing connection exhaustion during scale-out.

Databases in AWS

☁️ AWS · Choosing a Database · 11 min read

AWS offers a purpose-built database for every data shape. The skill — and the exam — is matching the access pattern to the right engine instead of forcing everything into one relational DB.

The Database Decision Table

ServiceModelPick when…
RDS / AuroraRelational (SQL)Transactions, joins, strong consistency, structured data
DynamoDBKey-value / document (NoSQL)Massive scale, single-digit-ms latency, serverless, known access patterns
ElastiCacheIn-memoryCaching, sessions, leaderboards, sub-ms reads
DocumentDBDocument (MongoDB-compatible)JSON documents, MongoDB workloads
NeptuneGraphSocial networks, fraud, recommendations
KeyspacesWide-column (Cassandra)Cassandra workloads, time-series
TimestreamTime-seriesIoT/metrics data
RedshiftColumnar warehouseAnalytics / OLAP over huge datasets

DynamoDB — The NoSQL Workhorse

  • Fully managed, serverless, single-digit-millisecond latency at any scale.
  • Data modeled around partition key (+ sort key); design tables around access patterns, not entities.
  • On-demand (pay per request) or provisioned capacity; auto-scaling available.
  • DynamoDB Streams emit change events; DAX adds a microsecond in-memory cache; Global Tables for multi-region.

Visual: Polyglot Persistence

Microservices Auroraorders DynamoDBcart/sessions Rediscache Neptunerecommendations Redshiftanalytics

How to Implement — AWS Console

  1. DynamoDB → Create table → set partition key (e.g. userId), sort key (orderId).
  2. Choose On-demand capacity to start; enable Point-in-time recovery.
  3. Add a Global Secondary Index for a second access pattern.
  4. Grant the app's IAM role dynamodb:*Item on that table's ARN only.

How to Implement — Spring Boot (DynamoDB)

// Enhanced DynamoDB client + a mapped bean @DynamoDbBean public class Order { private String userId; private String orderId; private BigDecimal total; @DynamoDbPartitionKey public String getUserId() { return userId; } @DynamoDbSortKey public String getOrderId() { return orderId; } // getters/setters… } @Repository class OrderRepo { private final DynamoDbTable<Order> table; OrderRepo(DynamoDbEnhancedClient c) { this.table = c.table("Orders", TableSchema.fromBean(Order.class)); } void save(Order o) { table.putItem(o); } Order get(String u, String o) { return table.getItem(Key.builder().partitionValue(u).sortValue(o).build()); } }
💡 Choose SQL (RDS/Aurora) when you need joins and transactions; choose DynamoDB when you need predictable low latency at unlimited scale and your access patterns are known up front.

Amazon Route 53

☁️ AWS · DNS · 10 min read

Route 53 is AWS's highly available, scalable DNS service (the "53" is the DNS port). It translates domain names to IPs, registers domains, performs health checks, and — uniquely — supports smart routing policies that ordinary DNS can't.

Record Types You'll Use

RecordMaps…
A / AAAAname → IPv4 / IPv6
CNAMEname → another name (not allowed at the zone apex)
Aliasname → an AWS resource (ALB, CloudFront, S3) — free, works at the apex
NS / SOAdelegation & zone authority
💡 Prefer an Alias record over CNAME for AWS targets: it's free, resolves faster, and is allowed at the root domain (example.com).

Routing Policies (the superpower)

Simple

One record → one (or random) value.

Weighted

Split traffic by % — canary/blue-green deployments.

Latency

Send users to the Region with the lowest latency.

Failover

Primary + secondary; health check fails → switch to backup.

Geolocation

Route by the user's country/continent (compliance, language).

Geoproximity / Multivalue

Bias by geography; or return up to 8 healthy records (client-side LB).

Visual: Latency Routing + Failover

User (India) Route 53latency policy + health check ap-south-1 ALB ✓lowest latency, healthy us-east-1 ALBstandby (failover)

How to Implement — AWS Console

  1. Route 53 → Registered domains → register or transfer your domain.
  2. Hosted zones → create a public zone for the domain.
  3. Create an A – Alias record → target your ALB or CloudFront distribution.
  4. Add a health check (HTTPS /actuator/health) and a failover record for DR.

How to Implement — Spring Boot

The app side is mostly DNS config, but make sure the health endpoint Route 53 polls is fast and dependency-aware:

# A lightweight liveness endpoint for Route 53 health checks management.endpoint.health.group.dns.include=ping # Route 53 health check → https://api.example.com/actuator/health/dns
# For blue/green: weighted records let you shift 10% → 100% gradually api.example.com A Alias → blue-ALB weight 90 api.example.com A Alias → green-ALB weight 10 # ramp up as you gain confidence

Amazon VPC

☁️ AWS · Networking · 13 min read

A Virtual Private Cloud is your own isolated, software-defined network inside AWS. You control the IP range, subnets, route tables, and gateways — the foundation that EC2, RDS, ELB, and almost everything else lives in.

Core Components

VPC & CIDR

The network and its private IP range, e.g. 10.0.0.0/16 (65k addresses). Region-scoped.

Subnet

A slice of the CIDR pinned to one AZ. Public (route to IGW) or private (no direct internet).

Internet Gateway (IGW)

Lets public subnets reach the internet (and be reached).

NAT Gateway

Lets private instances make outbound internet calls (updates, APIs) without being inbound-reachable.

Route Tables

Rules that decide where subnet traffic goes (local, IGW, NAT, peering…).

Security Group vs NACL

SG = stateful, instance-level, allow-only. NACL = stateless, subnet-level, allow + deny.

Connectivity Options

  • VPC Peering — connect two VPCs privately (non-transitive).
  • Transit Gateway — hub-and-spoke to connect many VPCs/on-prem at scale.
  • VPC Endpoints — reach AWS services (S3, DynamoDB via Gateway endpoint; others via Interface/PrivateLink) without traversing the internet.
  • Site-to-Site VPN / Direct Connect — link your data center to AWS.

Visual: Public/Private 3-Tier VPC

VPC 10.0.0.0/16 Public subnet 10.0.1.0/24 ALB NAT GW Private subnet 10.0.2.0/24 EC2 app servers (no public IP) Private subnet 10.0.3.0/24 (DB) RDS primary + standby Internet Gateway↕ internet

How to Implement — AWS Console

  1. VPC → Create VPC (VPC and more) → it scaffolds subnets, IGW, NAT, route tables across 2 AZs.
  2. Put the ALB in public subnets; EC2/ECS and RDS in private subnets.
  3. Add a Gateway VPC Endpoint for S3/DynamoDB (free, keeps traffic off the internet).
  4. Lock down with SGs (app SG → DB SG on 5432) and audit with VPC Flow Logs.

How to Implement — Spring Boot

VPC is infrastructure, but it shapes how the app connects. Inside a private subnet your app reaches RDS by its private DNS name and reaches S3 via the gateway endpoint — no public internet, no NAT cost:

# App in a private subnet talks to RDS over private DNS spring.datasource.url=jdbc:postgresql://mydb.xxxx.ap-south-1.rds.amazonaws.com:5432/app # S3 calls route through the Gateway VPC Endpoint automatically — # no code change; the SDK uses the regional S3 endpoint, kept on AWS's network.
⚠️ NAT Gateways are billed per hour and per GB. If your app only talks to AWS services, use VPC endpoints to avoid sending that traffic (and that bill) through NAT.

CloudFront & Global Accelerator

☁️ AWS · Edge Networking · 10 min read

Both services use AWS's global edge network to speed up delivery to users worldwide — but they solve different problems. CloudFront is a CDN (caches content). Global Accelerator is a network accelerator (routes packets over AWS's backbone, no caching).

Amazon CloudFront (CDN)

  • Caches static + dynamic content at 400+ edge locations close to users.
  • Origins: S3 bucket, ALB, EC2, or any HTTP server.
  • Integrates with AWS WAF, TLS certs (ACM), OAC to lock the S3 origin to CloudFront only.
  • CloudFront Functions / Lambda@Edge run code at the edge (auth, redirects, A/B).

AWS Global Accelerator

  • Gives you 2 static anycast IPs as a fixed front door.
  • Routes user traffic into the nearest AWS edge, then over the private AWS backbone to your app — lower jitter/latency than the public internet.
  • Instant regional failover; great for TCP/UDP apps, gaming, VoIP, non-HTTP workloads.

CloudFront vs Global Accelerator

CloudFrontGlobal Accelerator
Caches content?YesNo
Best forHTTP(S), static/media, webTCP/UDP, non-cacheable, gaming/IoT
Entry pointEdge-cached responses2 static anycast IPs

Visual: CloudFront in Front of S3 + ALB

User CloudFront Edgecache + WAF + TLS S3 (static assets)/static/* via OAC ALB → Spring app/api/* (dynamic)

How to Implement — AWS Console

  1. CloudFront → Create distribution → origin = your S3 bucket; enable OAC.
  2. Add a second origin = your ALB; create a behavior /api/* → ALB (no caching).
  3. Attach an ACM certificate + your domain (alternate domain name).
  4. Attach AWS WAF; set cache policies (long TTL for static, none for API).

How to Implement — Spring Boot

Serve hashed static assets with long cache headers so CloudFront caches them aggressively, and keep API responses uncacheable:

// Cache static resources for a year (filenames are content-hashed) @Override public void addResourceHandlers(ResourceHandlerRegistry reg) { reg.addResourceHandler("/static/**") .addResourceLocations("classpath:/static/") .setCacheControl(CacheControl.maxAge(365, TimeUnit.DAYS).cachePublic()); } // API responses stay fresh — no edge caching @GetMapping("/api/quote") ResponseEntity<Quote> quote() { return ResponseEntity.ok() .cacheControl(CacheControl.noStore()) .body(service.latest()); }
💡 Read the real client IP from the X-Forwarded-For header (set server.forward-headers-strategy=framework) — behind CloudFront/ALB the direct remote address is the proxy, not the user.

Amazon S3

☁️ AWS · Object Storage · 11 min read

Simple Storage Service is AWS's infinitely scalable object store. You put files ("objects") into "buckets" and get them back over HTTP. It backs websites, data lakes, backups, media, ML datasets — designed for 11 nines (99.999999999%) of durability.

Key Concepts

Bucket

A globally-unique-named container, created in one Region. Holds unlimited objects.

Object & Key

The file + its full path-like key (invoices/2026/jan.pdf). Max 5 TB. Has metadata + version id.

Storage Classes

Standard, Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant/Flexible/Deep Archive — trade cost vs retrieval time.

Versioning

Keep every version of an object; protects against overwrite/delete.

Storage Classes — Cost vs Access

ClassUse forRetrieval
StandardHot, frequently accessedInstant
Intelligent-TieringUnknown/changing patternsInstant (auto-moves)
Standard-IAInfrequent but fast accessInstant, cheaper storage
Glacier FlexibleArchiveMinutes–hours
Glacier Deep ArchiveLong-term compliance~12 hours, cheapest

Lifecycle Rules

Automatically transition objects to cheaper classes and expire them: e.g. Standard → Standard-IA after 30 days → Glacier after 90 → delete after 365.

Visual: Upload & Serve Flow

Browser Spring Apppresigned URL S3 Bucketuploads/ · 11 nines 1 ask 2 url 3 PUT directly to S3

How to Implement — AWS Console

  1. S3 → Create bucket (globally unique name, pick Region, Block Public Access ON).
  2. Enable Versioning and default encryption (SSE-S3 or SSE-KMS).
  3. Add a Lifecycle rule to tier/expire objects.
  4. Grant the app's IAM role s3:PutObject/GetObject on arn:aws:s3:::bucket/*.

How to Implement — Spring Boot

// Upload & generate a presigned download URL (AWS SDK v2) @Service class StorageService { private final S3Client s3; private final S3Presigner presigner; private final String bucket = "my-app-bucket"; void upload(String key, MultipartFile file) throws IOException { s3.putObject(PutObjectRequest.builder() .bucket(bucket).key(key).contentType(file.getContentType()).build(), RequestBody.fromBytes(file.getBytes())); } String presignedGet(String key) { var get = GetObjectRequest.builder().bucket(bucket).key(key).build(); return presigner.presignGetObject(b -> b .signatureDuration(Duration.ofMinutes(15)).getObjectRequest(get)) .url().toString(); } }
💡 For user uploads, hand the browser a presigned PUT URL so the file goes straight to S3 — your server never proxies the bytes, saving bandwidth and memory.

Amazon S3 — Advanced

☁️ AWS · Object Storage (Deep Dive) · 11 min read

Beyond put/get, S3 has features for performance, durability across Regions, and querying data in place.

Performance & Large Objects

  • Multipart Upload — split files >100 MB into parallel parts (required >5 GB). Faster, resumable.
  • S3 Transfer Acceleration — upload via the nearest CloudFront edge over AWS backbone.
  • Byte-Range Fetches — download parts of an object in parallel; resume failed reads.
  • S3 scales to 3,500 PUT / 5,500 GET per second per prefix — spread keys across prefixes for huge throughput.

Replication

CRR — Cross-Region

Async copy to a bucket in another Region. DR, compliance, lower-latency global reads.

SRR — Same-Region

Aggregate logs across accounts, or keep prod/test copies. Requires versioning on both ends.

Querying & Events

  • S3 Select — run SQL on a single object (CSV/JSON/Parquet), retrieve only matching rows.
  • Athena — serverless SQL across an entire bucket (data lake) — covered in Data & Analytics.
  • Event Notifications — on object create/delete, trigger Lambda, SQS, or SNS (e.g. generate a thumbnail on upload).
  • S3 Object Lambda — transform objects on the fly as they're retrieved (redact, resize, reformat).

Visual: Event-Driven Thumbnailing

S3: uploads/PutObject event Lambdaresize image S3: thumbs/output

How to Implement — AWS Console

  1. S3 → bucket → Management → Replication rules → set destination bucket/Region.
  2. S3 → bucket → Properties → Event notifications → on PUT → trigger a Lambda.
  3. Enable Transfer Acceleration on the bucket for global uploads.

How to Implement — Spring Boot (Multipart + S3 Select)

// Resilient large-file upload via the Transfer Manager (CRT) S3TransferManager tm = S3TransferManager.create(); Upload up = tm.upload(b -> b .putObjectRequest(r -> r.bucket("my-app-bucket").key("big/video.mp4")) .source(Path.of("/tmp/video.mp4"))); up.completionFuture().join(); // auto multipart + parallel parts
# Trigger via event instead of polling: Lambda consumes the S3 PutObject event, # or your app subscribes to an SQS queue fed by S3 notifications.

Amazon S3 — Security

☁️ AWS · Data Protection · 10 min read

S3 misconfiguration is the most famous cause of public data leaks. Locking buckets down is a layered job: block public access, encrypt, use the right policy type, and audit.

Access Control Layers

Block Public Access

Account- and bucket-level master switch — leave ON unless you're intentionally hosting a public site.

Bucket Policy

Resource-based JSON on the bucket — grant cross-account access, enforce TLS, restrict by VPC/IP.

IAM Policy

Identity-based — what a user/role can do across buckets.

ACLs (legacy)

Object/bucket grants — AWS now recommends disabling ACLs (Object Ownership = bucket owner enforced).

Encryption

  • SSE-S3 — AWS-managed keys (AES-256). Default, zero effort.
  • SSE-KMS — AWS KMS keys; adds audit trail + access control over the key. Recommended for sensitive data.
  • SSE-C — you supply the key per request.
  • Client-side — encrypt before upload.
  • Enforce in transit with a bucket policy denying aws:SecureTransport = false.

Example: Lock the Bucket to HTTPS + CloudFront Only

// Bucket policy: deny non-TLS, allow only the CloudFront OAC { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyInsecure", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::my-app-bucket/*", "Condition": { "Bool": { "aws:SecureTransport": "false" } } }, { "Sid": "AllowCloudFront", "Effect": "Allow", "Principal": { "Service": "cloudfront.amazonaws.com" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-app-bucket/*", "Condition": { "StringEquals": { "AWS:SourceArn": "arn:aws:cloudfront::123:distribution/E1ABC" } } } ] }

How to Implement — AWS Console

  1. S3 → bucket → Permissions → confirm Block all public access = ON.
  2. Set default encryption = SSE-KMS with a customer-managed key.
  3. Disable ACLs (Object Ownership → Bucket owner enforced).
  4. Turn on S3 Access Logs and review IAM Access Analyzer findings.

How to Implement — Spring Boot

Request server-side encryption explicitly and rely on the IAM role for access — never embed credentials or make objects public:

s3.putObject(PutObjectRequest.builder() .bucket("my-app-bucket").key(key) .serverSideEncryption(ServerSideEncryption.AWS_KMS) .ssekmsKeyId("arn:aws:kms:ap-south-1:123:key/abc") // SSE-KMS .build(), RequestBody.fromBytes(bytes));
⚠️ Share files via presigned URLs (time-limited), never by making the object/bucket public. A presigned GET grants temporary access scoped to one object and expires automatically.

AWS Storage Extras

☁️ AWS · Specialized Storage · 9 min read

Beyond EBS, EFS, and S3, AWS has purpose-built storage services for files, hybrid setups, and bulk data transfer.

The Extra Storage Services

Amazon FSx

Managed third-party file systems: FSx for Windows (SMB/AD), Lustre (HPC/ML, S3-linked), NetApp ONTAP, OpenZFS.

AWS Storage Gateway

Hybrid bridge — on-prem apps use local NFS/SMB/iSCSI while data is backed by S3/Glacier (File, Volume, Tape gateways).

AWS Backup

Central, policy-based backups across EBS, RDS, DynamoDB, EFS, FSx — with cross-Region/account copies.

AWS DataSync

Fast online transfer/sync between on-prem (NFS/SMB) and AWS storage on a schedule.

Snow Family — Offline/Edge Transfer

  • Snowcone — small, rugged, edge compute + transfer (TBs).
  • Snowball Edge — petabyte-scale device with compute; ship data physically when networks are too slow.
  • Snowmobile — exabyte transfer in a shipping container (legacy/extreme).
💡 Quick test: it's faster to ship a Snowball than to upload over the internet once you're moving tens of TB on a typical link. Use DataSync for ongoing online sync; Snow for one-off bulk or low-bandwidth sites.

Visual: Choosing a Transfer Path

On-prem data DataSync (online, ongoing) Storage Gateway (hybrid) Snowball (offline bulk) S3 / Glacier

How to Implement — AWS Console

  1. AWS Backup → create a Backup plan → assign resources by tag → set retention & cross-Region copy.
  2. DataSync → create a task (source NFS → S3) → schedule it.
  3. FSx → create a file system → mount from EC2 for shared Windows/HPC workloads.

How to Implement — Spring Boot

These are mostly ops/infra services your app benefits from indirectly. The app-relevant pattern: mount FSx/EFS as a normal path, or keep using the S3 SDK — the backend storage tiering is transparent to your code.

# App writes to a mounted FSx/EFS share like any local directory app.shared-dir=/mnt/fsx/reports # AWS Backup snapshots it on schedule — no app code needed.

Classic Solutions Architecture

☁️ AWS · Putting It Together · 12 min read

This is where individual services combine into real architectures. The exam loves "evolution" stories — start simple, then add HA, scale, and decoupling as load grows. The guiding compass is the AWS Well-Architected Framework.

The Six Well-Architected Pillars

Operational Excellence

Run & monitor systems; automate changes (IaC, CI/CD).

Security

Least privilege, encryption, traceability.

Reliability

Recover from failure; multi-AZ; auto-scaling.

Performance Efficiency

Right-size; use managed/serverless where it fits.

Cost Optimization

Pay for what you need; Spot/Savings Plans; tier storage.

Sustainability

Minimize environmental impact of workloads.

Reference Pattern: Stateless Web App at Scale

The canonical design that combines everything in this course:

Users Route 53+ CloudFront ALB+ WAF ASG (multi-AZ)EC2/ECS appEC2/ECS app ElastiCache (sessions) RDS Multi-AZ+ read replicas S3 (assets,uploads)

Decoupling for Spikes

When work is bursty (image processing, emails, reports), put a queue (SQS) between the web tier and workers so the app stays responsive and workers scale on queue depth.

How to Implement — AWS Console

  1. Network: VPC with public (ALB) + private (app, DB) subnets across 2 AZs.
  2. Edge: CloudFront + Route 53 alias + ACM cert + WAF.
  3. Compute: Launch Template → ASG behind ALB; ElastiCache for sessions.
  4. Data: RDS Multi-AZ + read replica; S3 for assets/uploads.
  5. Decouple: SQS + a worker ASG/Lambda for async jobs.
  6. Run the Well-Architected Tool review before go-live.

How to Implement — Spring Boot

// The app's job in this architecture: be stateless & observable spring.session.store-type=redis // sessions → ElastiCache management.endpoints.web.exposure.include=health,info,prometheus server.shutdown=graceful // clean scale-in // reads → replica datasource, writes → primary (routing datasource) // uploads → S3, heavy jobs → publish to SQS
💡 The progression to remember: single EC2 → add ELB+ASG (HA) → move state to RDS/ElastiCache/S3 (stateless) → add SQS (decouple) → add CloudFront/Route 53 (global & resilient).

Disaster Recovery & Migrations

☁️ AWS · Resilience & Moving to Cloud · 11 min read

DR planning is about two numbers: RPO (Recovery Point Objective — how much data you can afford to lose) and RTO (Recovery Time Objective — how long you can be down). Tighter targets cost more.

The Four DR Strategies (cheapest → fastest)

StrategyRTO/RPOHow
Backup & RestoreHoursBack up to S3/another Region; rebuild on disaster. Cheapest.
Pilot Light10s of minCore (DB) always running in DR Region; spin up the rest on failover.
Warm StandbyMinutesScaled-down full copy always running; scale up on failover.
Multi-Site Active/Active~Real-timeFull capacity in 2+ Regions serving live traffic. Most expensive.

Visual: Pilot Light Failover

Primary Region (active) ASG + ALB RDS primary DR Region (pilot light) ASG min=0 RDS read replica async replication On disaster: promote replica + scale ASG + flip Route 53 failover record

Migration Tooling

  • AWS Migration Hub — track migrations across tools.
  • Application Migration Service (MGN) — lift-and-shift servers to EC2.
  • Database Migration Service (DMS) — migrate DBs with minimal downtime; SCT converts schemas/engines.
  • DataSync / Snow Family — bulk data transfer.
  • The 7 Rs: Rehost, Replatform, Repurchase, Refactor, Retire, Retain, Relocate.

How to Implement — AWS Console

  1. Enable cross-Region backups (AWS Backup) and RDS read replica in the DR Region.
  2. Pre-create the DR VPC, launch templates, and ASG (min 0) = pilot light.
  3. Configure Route 53 failover records with health checks.
  4. For migration: run DMS (full load + CDC) from on-prem DB → RDS.
  5. Game-day test the failover regularly — an untested DR plan is no plan.

How to Implement — Spring Boot

Make the app Region-portable: externalize endpoints and keep schema migrations in code (Flyway/Liquibase) so the DR database is always at the right version.

# Region-agnostic config injected per environment spring.datasource.url=${DB_URL} # swapped to the DR endpoint on failover spring.data.redis.host=${REDIS_HOST} # Flyway runs migrations on startup → DR DB schema always matches the app spring.flyway.enabled=true
⚠️ Aim RPO/RTO at business need, not zero. Active/active is real-time but doubles cost and adds data-consistency complexity. Most apps are well served by Warm Standby.

AWS Integration & Messaging

☁️ AWS · Decoupling Services · 12 min read

As systems grow, synchronous calls between services become brittle — one slow service stalls everyone. Messaging decouples producers from consumers so they scale and fail independently. The three pillars: SQS (queue), SNS (pub/sub), EventBridge (event bus), plus Kinesis for streams.

The Core Services

SQS (Queue)

One producer → one consumer pulls. Decouples & buffers. Standard (at-least-once, best-effort order) or FIFO (exactly-once, ordered).

SNS (Pub/Sub)

One message → fan-out to many subscribers (SQS, Lambda, email, HTTP). Push model.

EventBridge

Serverless event bus with content-based routing rules, schema registry, SaaS & AWS-service events, scheduler.

Kinesis

Real-time streaming of large data (clickstream, logs, IoT) with ordered, replayable shards.

The Fan-Out Pattern (SNS + SQS)

Publish once to an SNS topic; each downstream service has its own SQS queue subscribed to it — they process independently and a slow consumer can't drop messages.

Order Service SNS topicOrderPlaced SQS → Billing SQS → Shipping SQS → Analytics Lambda/EC2

SQS Essentials

  • Visibility timeout — a consumed message is hidden while processed; reappears if not deleted (retry).
  • Dead-Letter Queue (DLQ) — messages that fail N times move here for inspection.
  • Long polling — reduce empty receives/cost.
  • Scale workers on queue depth (ApproximateNumberOfMessages) with an ASG/Lambda.

How to Implement — AWS Console

  1. SQS → Create queue (Standard) → set visibility timeout + a DLQ with maxReceiveCount.
  2. SNS → create a topic → subscribe the SQS queue(s) to it.
  3. Grant the producer sns:Publish and the consumer sqs:ReceiveMessage/DeleteMessage.
  4. Add a CloudWatch alarm + ASG scaling policy on queue depth.

How to Implement — Spring Boot (Spring Cloud AWS)

// Producer — publish to SQS @Service class OrderPublisher { private final SqsTemplate sqs; void publish(Order o) { sqs.send(to -> to.queue("orders-queue").payload(o)); } } // Consumer — annotation-driven listener (auto-deletes on success) @Component class OrderConsumer { @SqsListener("orders-queue") void handle(Order o) { process(o); // throw → message returns after visibility timeout → DLQ after N tries } }
💡 Rule of thumb: SQS when one consumer should process each message (work queue) · SNS when many services need the same event (fan-out) · EventBridge when you need routing rules & SaaS/AWS events · Kinesis for high-volume ordered streams you may replay.

Containers on AWS

☁️ AWS · Container Orchestration · 12 min read

Containers package your app + dependencies into a portable image. AWS runs them with ECS (AWS-native orchestrator), EKS (managed Kubernetes), Fargate (serverless containers — no servers to manage), and ECR (private image registry).

The Container Services

ECR

Private Docker registry. docker push your image here; ECS/EKS pull from it.

ECS

AWS's own orchestrator. Define Task Definitions (containers) and Services (desired count + ALB + auto-scaling).

EKS

Managed Kubernetes control plane. Pick this for K8s portability/ecosystem.

Fargate

Launch type for ECS/EKS — runs containers without you managing EC2 hosts. Pay per vCPU/GB-second.

EC2 vs Fargate Launch Type

EC2 launch typeFargate
Server managementYou patch/scale the EC2 hostsNone — serverless
Cost modelPay for EC2 (good if dense/steady)Pay per task resource
Best forHigh, steady utilizationVariable/spiky, simplicity

Visual: ECS on Fargate Behind an ALB

Users ALB ECS Service (Fargate, multi-AZ) Taskapp:8080 container Taskapp:8080 container Service Auto Scaling: 2 → 10 tasks on CPU ECR pull image

How to Implement — AWS Console

  1. ECR → create a repo → docker build, tag, docker push.
  2. ECS → create a Task Definition (Fargate) → image = your ECR URI, port 8080, CPU/memory.
  3. ECS → create a Cluster → a Service (desired 2) attached to an ALB target group.
  4. Add Service Auto Scaling (target CPU 60%) and a CloudWatch log group.

How to Implement — Spring Boot (Dockerize)

# Option A: let Buildpacks build an OCI image (no Dockerfile) ./mvnw spring-boot:build-image -Dspring-boot.build-image.imageName=myapp:latest # Option B: a small multi-stage Dockerfile FROM eclipse-temurin:21-jre AS run WORKDIR /app COPY target/app.jar app.jar EXPOSE 8080 ENTRYPOINT ["java","-jar","app.jar"]
# Push to ECR aws ecr get-login-password | docker login --username AWS --password-stdin \ 123.dkr.ecr.ap-south-1.amazonaws.com docker tag myapp:latest 123.dkr.ecr.ap-south-1.amazonaws.com/myapp:latest docker push 123.dkr.ecr.ap-south-1.amazonaws.com/myapp:latest
💡 Give the ECS Task Role the AWS permissions your app needs (S3, SQS…) and the Task Execution Role permission to pull from ECR and write logs. The SDK picks up the task role automatically — same as EC2.

Serverless Overview

☁️ AWS · Serverless · 11 min read

Serverless means no servers to provision or manage — you deploy code/config, AWS runs and scales it, and you pay only for actual use (often down to zero when idle). The flagship is AWS Lambda, surrounded by managed building blocks.

AWS Lambda

  • Run a function in response to an event (API Gateway, S3, SQS, EventBridge, DynamoDB Streams…).
  • Pay per request + GB-second; scales to thousands of concurrent executions automatically.
  • Limits: up to 15-min timeout, 10 GB memory, 10 GB ephemeral /tmp.
  • Cold start = first invocation latency; mitigate with Provisioned/SnapStart.

The Serverless Toolbox

API Gateway

Managed REST/HTTP/WebSocket front door → Lambda. Auth, throttling, caching, stages.

DynamoDB

Serverless NoSQL — the natural database for Lambda.

S3

Serverless storage + event source.

Step Functions

Orchestrate multi-step workflows (state machine) across Lambdas/services.

EventBridge / SQS / SNS

Event routing & decoupling between functions.

Cognito

Serverless user auth (sign-up/sign-in, JWT).

Visual: HTTP API → Lambda → DynamoDB

Client API Gatewayauth + throttle Lambdayour function DynamoDBon-demand

How to Implement — AWS Console

  1. Lambda → Create function (Java 21) → upload jar/zip → set handler, memory, timeout.
  2. Attach an IAM execution role with only the permissions the function needs.
  3. Add a trigger: API Gateway (HTTP API) or S3/SQS event.
  4. Set env vars; enable SnapStart (Java) to cut cold starts.

How to Implement — Spring Boot on Lambda

Use Spring Cloud Function + the AWS adapter to run Spring beans as Lambda handlers (or AWS SnapStart for full Spring Boot):

// pom: spring-cloud-function-adapter-aws @SpringBootApplication public class App { public static void main(String[] a) { SpringApplication.run(App.class, a); } // A @Bean Function IS the Lambda handler @Bean public Function<OrderEvent, Receipt> processOrder(OrderService svc) { return event -> svc.handle(event); } } // Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker
⚠️ Plain Spring Boot has slow cold starts on Lambda. For latency-sensitive APIs prefer Spring Cloud Function + SnapStart, or keep Spring Boot on Fargate and use Lambda for event-driven glue.

Serverless Architectures

☁️ AWS · Serverless Patterns · 11 min read

Composing serverless building blocks into complete applications. The goal: event-driven systems that scale to zero, cost nothing when idle, and need no server maintenance.

Pattern 1 — Serverless REST API

API Gateway → Lambda → DynamoDB, with Cognito for auth and S3+CloudFront for the static frontend. The textbook "no servers" web app.

Pattern 2 — Event-Driven Processing

S3 upload → event → Lambda transforms → writes result + emits to EventBridge. Great for media pipelines, ETL, thumbnailing.

Pattern 3 — Workflow Orchestration (Step Functions)

For multi-step business processes (order → payment → inventory → ship), Step Functions coordinate Lambdas with retries, branching, parallelism, and built-in error handling — visually.

Validate Charge Reserve stock Notify Ship Retry/DLQ

Cost & Scaling Notes

  • Scale-to-zero: pay nothing when there's no traffic — ideal for spiky/unpredictable loads.
  • Watch concurrency limits and downstream throttling (e.g. RDS connections → use RDS Proxy or DynamoDB).
  • Use SAM or CDK to define the whole stack as Infrastructure-as-Code.

How to Implement — AWS Console / SAM

  1. Define the stack in a SAM template (API + Lambda + DynamoDB + permissions).
  2. sam build && sam deploy --guided provisions everything.
  3. Add a Step Functions state machine for the workflow; wire Lambdas as states.
  4. Front the static site with S3 + CloudFront; secure the API with Cognito.

How to Implement — Spring Boot

// Each step = a Spring Cloud Function bean; Step Functions invokes them in order @Bean Function<Order, Order> validate() { return o -> { /* checks */ return o; }; } @Bean Function<Order, Order> charge(PayClient p){ return o -> { p.charge(o); return o; }; } @Bean Function<Order, Receipt> ship(ShipSvc s){ return o -> s.dispatch(o); } // Step Functions handles retries/branching between these — no orchestration code.
💡 Decision: pick serverless for spiky/event-driven workloads and fast time-to-market; pick containers (Fargate/ECS) for steady traffic, long-running processes, or full Spring Boot apps where cold starts matter.

Data & Analytics

☁️ AWS · Data Pipelines · 11 min read

AWS analytics services let you ingest, store, transform, and query data at any scale — from ad-hoc SQL over S3 to petabyte data warehouses and real-time streams.

The Analytics Stack

Amazon Athena

Serverless SQL directly on S3 (CSV/JSON/Parquet). Pay per TB scanned. No infrastructure.

Amazon Redshift

Petabyte columnar data warehouse for fast OLAP/BI. Redshift Spectrum queries S3 too.

AWS Glue

Serverless ETL + Data Catalog. Crawlers infer schema; jobs transform data.

Kinesis / MSK

Real-time streaming ingestion (clickstream, logs, IoT); Kafka-compatible MSK.

Amazon EMR

Managed Hadoop/Spark for big-data processing.

QuickSight

Serverless BI dashboards over your data.

OpenSearch

Search & log analytics (the ELK-style stack).

Lake Formation

Build & govern a secure S3 data lake.

The Data Lake Pattern

Land raw data in S3 → catalog/transform with Glue → query with Athena or load to Redshift → visualize in QuickSight. S3 is the durable, cheap center of gravity.

Sources S3 lakeraw Glue ETL+ catalog Athena (SQL) Redshift QuickSight

How to Implement — AWS Console

  1. Land data in an S3 bucket (partitioned by date, Parquet for efficiency).
  2. Glue Crawler → infer schema into the Data Catalog.
  3. Athena → run SQL over the catalogued tables (no servers).
  4. Build a QuickSight dashboard on Athena/Redshift for BI.

How to Implement — Spring Boot

Apps feed the lake (events/logs) and can query Athena via JDBC for reporting:

// Stream domain events to S3 via Kinesis Firehose (buffered, auto-Parquet) firehose.putRecord(PutRecordRequest.builder() .deliveryStreamName("events-to-s3") .record(Record.builder().data(SdkBytes.fromUtf8String(json)).build()) .build()); # Query Athena from Spring via the Athena JDBC driver for reports spring.datasource.url=jdbc:awsathena://AwsRegion=ap-south-1;S3OutputLocation=s3://results/
💡 Store analytics data as partitioned Parquet in S3 — Athena scans far less data (lower cost, faster) than raw CSV/JSON.

Machine Learning

☁️ AWS · AI/ML Services · 10 min read

AWS ML comes in three layers: ready-made AI services (call an API, no ML knowledge), SageMaker (build/train/deploy your own models), and Bedrock (managed access to foundation/generative-AI models).

AI Services (API-Level — Easiest)

ServiceDoes
RekognitionImage/video analysis — objects, faces, moderation
ComprehendNLP — sentiment, entities, key phrases
TextractExtract text/forms/tables from documents
Transcribe / PollySpeech↔text
TranslateLanguage translation
LexChatbots (Alexa tech)
Personalize / ForecastRecommendations / time-series forecasting

Amazon SageMaker & Bedrock

  • SageMaker — end-to-end platform to label, build, train, tune, and deploy custom models to managed endpoints.
  • Bedrock — serverless access to foundation models (text/image/embeddings) for GenAI apps; supports RAG and agents.

Visual: ML Service Layers

AI Services — call an API (Rekognition, Comprehend, Textract, Bedrock) SageMaker — build / train / deploy your own models Frameworks on EC2/EKS (TensorFlow, PyTorch) — full control

How to Implement — AWS Console

  1. For quick wins, just enable an AI service and grant the IAM role access (e.g. rekognition:DetectLabels).
  2. For custom models: SageMaker Studio → notebook → train → deploy a real-time endpoint.
  3. For GenAI: enable Bedrock model access; call InvokeModel.

How to Implement — Spring Boot

// Moderate an uploaded image with Rekognition — no ML expertise needed @Service class ImageModerator { private final RekognitionClient rek; boolean isSafe(byte[] image) { var res = rek.detectModerationLabels(r -> r .image(i -> i.bytes(SdkBytes.fromByteArray(image))) .minConfidence(80f)); return res.moderationLabels().isEmpty(); // empty = clean } }
// Call a Bedrock foundation model for a GenAI feature var resp = bedrock.invokeModel(r -> r .modelId("anthropic.claude-...") .body(SdkBytes.fromUtf8String(promptJson)));
💡 Don't train a model if an AI service already solves it. Reach for SageMaker/Bedrock only when the managed APIs can't meet your accuracy or domain needs.

AWS Monitoring, Audit & Performance

☁️ AWS · Observability · 11 min read

You can't operate what you can't see. AWS observability rests on three pillars: CloudWatch (metrics/logs/alarms — what is happening), CloudTrail (API audit — who did what), and X-Ray (distributed tracing — where the latency is).

The Three Pillars

CloudWatch

Metrics, Logs, Alarms, Dashboards, Events. Custom metrics + Logs Insights queries. Triggers auto-scaling & alerts.

CloudTrail

Records every AWS API call (who, when, from where) — security forensics & compliance. Enable org-wide.

X-Ray

Traces a request across services to find bottlenecks & errors in microservices.

AWS Config

Tracks resource configuration changes & evaluates compliance rules over time.

Alarms & Auto-Remediation

A CloudWatch alarm watches a metric (CPU, latency, queue depth, custom) and acts: notify via SNS, trigger Auto Scaling, or run a Lambda to self-heal.

App / EC2 / ALB CloudWatchmetrics + logs Alarm fires SNS → email/Slack/PagerDuty Auto Scaling / Lambda heal

How to Implement — AWS Console

  1. CloudWatch → create a dashboard; add an alarm (e.g. ALB 5xx > 1%) → SNS notify.
  2. Ship app logs to a CloudWatch Log group; query with Logs Insights.
  3. Enable CloudTrail (all Regions) → deliver to S3 for audit.
  4. Enable X-Ray tracing on the service; set Config rules for compliance.

How to Implement — Spring Boot

Expose metrics via Micrometer and let the CloudWatch agent or OTel collector ship them; enable X-Ray tracing:

// pom: micrometer-registry-cloudwatch2 + spring-boot-starter-actuator management: metrics: export: cloudwatch: namespace: myapp batch-size: 20 tracing: sampling: probability: 1.0 # X-Ray / OTel tracing endpoints: web: exposure: include: health,info,metrics,prometheus
// Custom business metric — appears in CloudWatch automatically @Autowired MeterRegistry registry; void onOrder() { registry.counter("orders.placed").increment(); }
💡 Remember the split: CloudWatch = health/performance, CloudTrail = security/audit ("who called the API"), X-Ray = request tracing across services.

Advanced Identity in AWS

☁️ AWS · Identity at Scale · 11 min read

Beyond basic IAM, large organizations need multi-account governance, federation with corporate identities, and user-facing auth. These services deliver that.

The Identity Services

AWS Organizations

Manage many accounts centrally; consolidated billing; group accounts into OUs.

Service Control Policies (SCPs)

Org-wide guardrails — the max permissions any account/role can have (even admins). Deny by default at scale.

IAM Identity Center (SSO)

Single sign-on to all accounts; integrate with corporate IdP (Okta, Entra ID, AD).

Amazon Cognito

Customer (app user) identity — User Pools (sign-up/sign-in, JWT) + Identity Pools (temp AWS creds).

STS

Issues short-lived temporary credentials — the engine behind AssumeRole & federation.

IAM Roles Anywhere / Directory Service

Extend roles to on-prem workloads; managed AD in AWS.

Cross-Account Access via AssumeRole

The clean way to let one account act in another: define a role in account B that trusts account A, then A's principal calls STS AssumeRole to get temporary credentials — no shared keys.

Account A (CI/CD)sts:AssumeRole STStemp creds (1h) Account B (Prod)DeployRole (trusts A)

How to Implement — AWS Console

  1. Set up Organizations → create OUs (prod/dev/sandbox) → attach SCP guardrails.
  2. Enable IAM Identity Center → connect your IdP → assign permission sets per account.
  3. For app users: create a Cognito User Pool → app client → hosted UI / OIDC.
  4. For cross-account: create a role with a trust policy naming the other account.

How to Implement — Spring Boot (Cognito + Resource Server)

// Validate Cognito-issued JWTs as a Spring Security resource server spring: security: oauth2: resourceserver: jwt: issuer-uri: https://cognito-idp.ap-south-1.amazonaws.com/<userPoolId>
@Configuration @EnableWebSecurity class SecurityConfig { @Bean SecurityFilterChain chain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(a -> a .requestMatchers("/api/admin/**").hasAuthority("SCOPE_admin") .anyRequest().authenticated()) .oauth2ResourceServer(o -> o.jwt(Customizer.withDefaults())); return http.build(); } }
💡 Two different identity problems: IAM Identity Center = your employees accessing AWS · Cognito = your application's end users signing in.

AWS Security & Encryption

☁️ AWS · Security · 12 min read

Security is job zero at AWS, governed by the Shared Responsibility Model: AWS secures the cloud (hardware, facilities, managed-service software); you secure what's in the cloud (data, IAM, configuration, encryption).

Encryption — KMS & CloudHSM

  • KMS — managed keys for encrypting data across services (S3, EBS, RDS, Secrets…). AWS-managed, customer-managed (CMK), or imported keys; full CloudTrail audit; automatic rotation.
  • CloudHSM — dedicated, single-tenant hardware security module for strict compliance.
  • Encryption in transit — TLS everywhere; ACM issues/auto-renews certificates free.
  • Envelope encryption — KMS encrypts a data key, the data key encrypts the data.

Secrets & Parameters

Secrets Manager

Store DB creds/API keys with automatic rotation; KMS-encrypted; fine-grained access.

SSM Parameter Store

Config + secrets (SecureString) — cheaper, no auto-rotation. Great for app config.

Threat Detection & Protection

ServiceProtects against
AWS WAFL7 web attacks (SQLi, XSS, bad bots) on ALB/CloudFront/API GW
AWS ShieldDDoS (Standard free; Advanced for large attacks)
GuardDutyIntelligent threat detection from logs (crypto-mining, recon)
Amazon MacieDiscovers sensitive data (PII) in S3
InspectorVulnerability scanning of EC2/ECR/Lambda
Security HubAggregates & scores findings across all of the above

Visual: Layered (Defense-in-Depth) Security

User Shield + WAFDDoS / L7 ALB (TLS/ACM)in transit App (private)IAM role + SG Data (KMS)at rest GuardDuty + Inspector + Security Hub watch every layer

How to Implement — AWS Console

  1. Enable encryption everywhere: KMS on S3/EBS/RDS; ACM cert on ALB/CloudFront.
  2. Move all secrets into Secrets Manager with rotation; remove keys from config.
  3. Attach WAF to the ALB; turn on GuardDuty, Inspector, Security Hub.
  4. Run Macie on data buckets; review findings in Security Hub.

How to Implement — Spring Boot (Secrets Manager)

# Spring Cloud AWS pulls secrets at startup — no keys in the jar spring: config: import: aws-secretsmanager:/prod/myapp/db # Keys in that secret (username/password) become resolvable properties: spring.datasource.username=${username} spring.datasource.password=${password}
⚠️ Shared Responsibility: AWS will never leak your data, but it cannot stop you from making a bucket public or hardcoding a key. Encryption, IAM least-privilege, and secret hygiene are your half of the deal.