Core AWS Services Overview for Java Developers

Fast recall

Quick revision

Core answer

A Java/Spring Boot developer should be familiar with EC2 (virtual machines), S3 (object storage), RDS (managed relational databases), Lambda (serverless functions), SQS (message queues), and SNS (pub/sub notifications). Each solves a different infrastructure concern and maps directly to common backend patterns.

AWS for Java backend work organizes around three layers — compute where the JVM runs, data storage, and the messaging and integration services that connect them. Knowing which service belongs in which layer makes it easy to pick the right one for each job.

Compute — where the application runs

ECS Fargate runs Docker containers without managing EC2 instances — which means you define CPU and memory, push a container image, and AWS schedules and runs it; no patching, no capacity planning for VMs
EC2 is the right choice when you need control over the instance type, GPU access, or specific AMIs; for most Spring Boot services, Fargate is simpler
Lambda runs event-driven functions billed per invocation — which means zero cost when idle; the trade-off is cold starts and a 15-minute execution limit

Data storage

RDS and Aurora handle relational workloads with full JDBC and Hibernate support; Aurora PostgreSQL adds auto-scaling storage and replicas with no operational overhead
S3 stores object data — files, images, backups, large JSON payloads; not a database, but the cheapest and most durable way to store blobs
DynamoDB is a fully managed NoSQL key-value store; useful when you need single-digit millisecond latency at any scale without managing schema migrations

Messaging and integration

SQS decouples producer and consumer services with a durable queue — which means the producer doesn't need the consumer to be running at the same time
SNS fans out one event to multiple subscribers — one publish, many consumers via HTTP, email, or SQS subscriptions
EventBridge routes events from AWS services or custom sources to targets based on content-based rules

For a standard Spring Boot microservice: Fargate for compute, RDS for data, SQS for async communication — these three cover 80% of what backend services need on AWS.

Interview-ready guide

Interview answer

Compute — where the application runs

ECS Fargate runs Docker containers without managing EC2 instances — which means you define CPU and memory, push a container image, and AWS schedules and runs it; no patching, no capacity planning for VMs
EC2 is the right choice when you need control over the instance type, GPU access, or specific AMIs; for most Spring Boot services, Fargate is simpler
Lambda runs event-driven functions billed per invocation — which means zero cost when idle; the trade-off is cold starts and a 15-minute execution limit

Data storage

RDS and Aurora handle relational workloads with full JDBC and Hibernate support; Aurora PostgreSQL adds auto-scaling storage and replicas with no operational overhead
S3 stores object data — files, images, backups, large JSON payloads; not a database, but the cheapest and most durable way to store blobs
DynamoDB is a fully managed NoSQL key-value store; useful when you need single-digit millisecond latency at any scale without managing schema migrations

Messaging and integration

SQS decouples producer and consumer services with a durable queue — which means the producer doesn't need the consumer to be running at the same time
SNS fans out one event to multiple subscribers — one publish, many consumers via HTTP, email, or SQS subscriptions
EventBridge routes events from AWS services or custom sources to targets based on content-based rules

For a standard Spring Boot microservice: Fargate for compute, RDS for data, SQS for async communication — these three cover 80% of what backend services need on AWS.

03 · Deep dive