AWS Compute Deep Dive for Backend Engineers

⚙️ AWS Compute Deep Dive for Backend Engineers

EC2 | ECS | EKS (Kubernetes) | Lambda — Concepts, Architecture & Interview Q&A

🚀 Introduction

Compute is the core layer of any backend architecture.
In AWS, you have multiple compute options — from bare-metal-like EC2 instances to fully managed serverless runtimes like Lambda.

A good backend engineer must understand when to use each service, how to scale and secure workloads, and how to integrate compute with storage, networking, and CI/CD.

🧱 1. Amazon EC2 — Elastic Compute Cloud

🔹 Overview

Amazon EC2 provides virtual machines (instances) in the cloud.
You can choose OS, CPU, memory, storage, and networking configuration.
It’s best suited when you need full control of the OS and runtime.

Feature	Description
Instance Types	Optimized for general, compute, memory, GPU, or storage
AMI	Amazon Machine Image – template for your instance
EBS Volumes	Persistent block storage for EC2
Security Groups	Virtual firewalls controlling inbound/outbound traffic
Elastic IP	Static IP for instances
Auto Scaling	Automatically adjust instance count based on demand

🧠 Interview Questions & Answers

1️⃣ What is the difference between EC2 and Lambda?
→ EC2 is infrastructure-as-a-service — you manage the OS and scaling.
→ Lambda is serverless — AWS manages servers and scales automatically per request.

2️⃣ What are EC2 purchasing options?

On-Demand: Pay by the second/hour — flexible but costly for long-term.
Reserved Instances: 1–3 year commitment; up to 72% cheaper.
Spot Instances: Unused capacity at up to 90% discount (can be interrupted).
Savings Plans: Flexible compute discounts for steady workloads.

3️⃣ What are placement groups?
→ Logical grouping of instances to control networking:

Cluster: Low latency, high throughput (same rack).
Spread: Instances across hardware (for HA).
Partition: Grouped for large distributed systems like Hadoop.

4️⃣ How do you secure EC2 instances?

Use IAM roles instead of access keys.
Enable security groups + NACLs.
Patch OS regularly.
Store secrets in AWS Secrets Manager.

✅ Best Practices

Use Auto Scaling Groups (ASG) for elasticity.
Use Elastic Load Balancer (ALB/NLB) for fault tolerance.
Use EBS gp3 volumes for cost optimization.
Always attach an IAM Role for AWS API access.
Use EC2 Image Builder for automated AMI updates.

🐳 2. Amazon ECS — Elastic Container Service

🔹 Overview

Amazon ECS is a container orchestration service that runs and scales Docker containers on AWS.
You can run ECS on:

EC2 (self-managed cluster) or
AWS Fargate (serverless compute for containers)

Component	Description
Task Definition	Blueprint describing container image, CPU/memory, ports
Service	Long-running task definition with scaling rules
Cluster	Logical group of EC2/Fargate resources
Task Role	IAM role assigned to containers
Load Balancing	Uses ALB/NLB for routing traffic

🧠 Interview Questions & Answers

1️⃣ ECS vs EKS?
→ ECS is AWS-native container orchestration.
→ EKS is Kubernetes-based, more portable but more complex.

2️⃣ ECS vs Fargate?
→ Fargate is the serverless mode for ECS — no EC2 management, pay per CPU-second.
→ ECS on EC2 gives you control of the instance fleet.

3️⃣ How does scaling work in ECS?
→ Use Service Auto Scaling based on CloudWatch metrics (CPU, memory, queue length).

4️⃣ How do you secure containers?
→ Assign IAM roles to tasks, not containers.
→ Store images in ECR (Elastic Container Registry) with scanning enabled.
→ Run containers with read-only root filesystem.

✅ Best Practices

Use Fargate for short-lived or spiky workloads.
Use ECS Capacity Providers for efficient scaling.
Keep task definitions version-controlled.
Use ALB target groups for each service.
Centralize logs in CloudWatch Logs or Fluent Bit + OpenSearch.

☸️ 3. Amazon EKS — Elastic Kubernetes Service

🔹 Overview

Amazon EKS provides a fully managed Kubernetes control plane.
You focus on pods, nodes, and deployments — AWS manages the Kubernetes API servers and etcd.

Component	Description
Cluster	Managed control plane in AWS
Node Group	EC2 or Fargate nodes running workloads
Pod	Smallest deployable unit (containers)
Service	Exposes pods internally/externally
Ingress	Routes traffic to services via ALB/NLB
ConfigMap & Secret	App configuration and credentials

🧠 Interview Questions & Answers

1️⃣ Difference between ECS and EKS?

Feature	ECS	EKS
Orchestrator	AWS proprietary	Kubernetes (open source)
Portability	Tied to AWS	Multi-cloud capable
Complexity	Easier	More complex
Ecosystem	AWS native tools	Kubernetes ecosystem

2️⃣ What are the compute options for EKS?

Managed EC2 node groups
Fargate (serverless pods)

3️⃣ How does networking work in EKS?
→ Uses VPC CNI plugin: each pod gets an ENI (Elastic Network Interface) with its own IP.
→ Use CoreDNS for service discovery.

4️⃣ How do you expose applications?
→ Through Kubernetes Ingress, which integrates with AWS ALB Ingress Controller.

✅ Best Practices

Use managed node groups for easy lifecycle management.
Use IRSA (IAM Roles for Service Accounts) to grant pod-level permissions.
Enable cluster autoscaler and horizontal pod autoscaler (HPA).
Integrate CloudWatch, Prometheus, Grafana for observability.
Use private endpoint access for secure clusters.

⚡ 4. AWS Lambda — Serverless Compute

🔹 Overview

AWS Lambda runs your code without provisioning servers.
You just upload your function; AWS handles scaling, execution, and fault tolerance.

Feature	Description
Runtime	Node.js, Python, Go, Java, .NET, Custom
Trigger Sources	API Gateway, S3, DynamoDB, SNS, EventBridge
Scaling	Automatic — per request
Billing	Pay only for execution time (ms)
Concurrency	Scales automatically; default limit ~1,000 per Region

🧠 Interview Questions & Answers

1️⃣ When would you choose Lambda over EC2?
→ For event-driven, short-duration workloads (e.g., data processing, API backend, file transformation).
→ EC2 is better for long-running or stateful apps.

2️⃣ Lambda vs Fargate?
→ Lambda = Function-level serverless.
→ Fargate = Container-level serverless.

3️⃣ Cold start vs warm start?
→ Cold start = first invocation; container and runtime start-up adds latency.
→ Warm start = reused container → faster execution.

4️⃣ How do you secure Lambda functions?

Use IAM execution role (least privilege).
Store secrets in AWS Secrets Manager or SSM Parameter Store.
Enable VPC access only when necessary.
Use Dead Letter Queues (DLQ) for failure handling.

✅ Best Practices

Use Lambda layers for shared libraries.
Use Provisioned Concurrency to eliminate cold starts.
Monitor with CloudWatch Logs and X-Ray.
Combine with API Gateway or EventBridge for event-driven patterns.
Keep functions small and single-purpose (≤ 15 min runtime).

🧮 5. Choosing the Right AWS Compute Service

Requirement	Recommended Service
Full OS control, long-running app	EC2
Dockerized app, AWS-native orchestration	ECS
Kubernetes workload, multi-cloud portability	EKS
Event-driven or short-lived tasks	Lambda
Need both containers + serverless	ECS/EKS on Fargate

⚖️ 6. Architecture Comparison

Feature	EC2	ECS	EKS	Lambda
Compute Model	VM	Container	Kubernetes	Function
Management Level	Self-managed	Semi-managed	Managed control plane	Fully managed
Scaling	Auto Scaling Group	Service Auto Scaling	Cluster + HPA	Automatic
Cost Model	Pay for uptime	Pay per task/container	Pay for nodes/pods	Pay per invocation
Startup Time	Minutes	Seconds	Seconds	Milliseconds
Best For	Stateful workloads	Microservices	Cloud-native apps	Event-driven tasks

🧠 Interview Cheat Sheet

Question	Short Answer
What is EC2 Auto Scaling?	Dynamically adds/removes instances based on demand.
ECS vs Fargate?	Fargate = no EC2 management, pay-per-task.
What’s IRSA in EKS?	IAM Roles for Service Accounts — granular permissions.
Lambda concurrency limit?	1,000 per Region (can request increase).
How does Lambda scale?	Each request = new container; scales automatically.
How to reduce Lambda cold starts?	Use Provisioned Concurrency or keep function warm.
Which is more portable — ECS or EKS?	EKS (Kubernetes).
Can EKS run on Fargate?	✅ Yes — serverless pods mode.

🧩 7. Best Practice Summary

Area	Recommendation
Security	Use IAM roles, VPC isolation, and secrets management.
Cost Optimization	Use Spot/Reserved instances; Fargate for burst workloads.
Scaling	Enable Auto Scaling (ASG/HPA).
Monitoring	CloudWatch, X-Ray, Prometheus, Grafana.
CI/CD	CodePipeline → CodeBuild → ECS/EKS/Lambda deploy.
Resilience	Multi-AZ deployment + Load Balancers.

🧩 8. Real-World Scenario Examples

Scenario 1:
Microservice API backend with variable load → Use ECS Fargate + ALB for scaling without managing servers.

Scenario 2:
Batch data processing job triggered by S3 uploads → Use Lambda (trigger via S3 event).

Scenario 3:
AI/ML model serving on GPUs → Use EC2 G5 instances or EKS GPU node group.

Scenario 4:
Enterprise-grade microservices requiring Kubernetes governance → Use EKS with GitOps + ArgoCD.

Scenario 5:
Cron-like periodic jobs → Use EventBridge Scheduler + Lambda or ECS Scheduled Tasks.

🧠 Key Takeaways

EC2 → Full control.
ECS → AWS-managed container orchestration.
EKS → Kubernetes power with AWS integration.
Lambda → Pure serverless.
Choose based on control vs. automation vs. workload pattern.

How Amazon S3 Standard Stores and Replicates Data

🌎 How Amazon S3 Standard Stores and Replicates Data

Multi-AZ Durability, Cross-Region Replication, and Cross-Account Sharing Explained

🧭 1. How Amazon S3 Standard Stores Your Data

🏗️ Region vs Availability Zone

Region – a geographic area (e.g., us-east-1, ap-south-1).
Availability Zone (AZ) – a physically isolated data center within that Region.
Example:
```
us-east-1
├── us-east-1a
├── us-east-1b
└── us-east-1c
```

💾 Multi-AZ Redundancy

When you upload an object to Amazon S3 Standard, AWS automatically:

Replicates the data across at least three AZs in the same Region.
Stores redundant copies on separate devices, networks, and power systems.
Performs background integrity checks and self-healing if any copy becomes corrupted.

This design achieves:

Durability: 99.999999999 % (“11 nines”)
Availability: 99.99 % annually

🔒 Even if an entire AZ goes offline, your data remains available from the other AZs in that Region.

🧩 Internal Replication Flow (Within Region)


            ┌──────────────────────────────┐
            │         S3  Bucket           │
            └──────────────────────────────┘
                     │  Object Upload
                     ▼
     ┌───────────────┼────────────────────────┐
     │   us-east-1a  │   us-east-1b  │  us-east-1c │
     │  Object copy  │  Object copy  │  Object copy│
     └───────────────┴────────────────────────┘
                 (Automatic synchronous replication)

🌐 2. Cross-Region Replication (CRR)

S3 Standard keeps data only within its home Region.
If you need redundancy or access in another Region — for example from US East (Virginia) to Asia Pacific (Mumbai) — enable Cross-Region Replication (CRR).

⚙️ What CRR Does

Replicates newly created (or updated) objects asynchronously from a source bucket to a destination bucket in a different Region.
Preserves metadata, ACLs, tags, object locks, and encryption keys (if configured).
Replication typically completes within seconds to minutes.

🧠 Interview Note

S3 replication is asynchronous and one-way — from source → destination.
For bidirectional replication, configure two rules in opposite directions.

🪄 3. How to Set Up Cross-Region Replication

(Example – replicate from us-east-1 to ap-south-1)

Step 1 – Create Buckets


Source:      my-primary-bucket   (Region: us-east-1)
Destination: my-replica-bucket   (Region: ap-south-1)

Step 2 – Enable Versioning

CRR requires both buckets to have Versioning enabled.


aws s3api put-bucket-versioning --bucket my-primary-bucket --versioning-configuration Status=Enabled
aws s3api put-bucket-versioning --bucket my-replica-bucket --versioning-configuration Status=Enabled

Step 3 – Create an IAM Role for Replication


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "s3.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Attach a policy granting S3 permission to read from the source and write to the destination:


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": ["s3:GetObjectVersion", "s3:GetObjectVersionAcl"],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::my-primary-bucket/*"
    },
    {
      "Action": ["s3:ReplicateObject", "s3:ReplicateDelete"],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::my-replica-bucket/*"
    }
  ]
}

Step 4 – Add Replication Rule to Source Bucket

In the AWS Console or via CLI:


aws s3api put-bucket-replication --bucket my-primary-bucket --replication-configuration '{
  "Role": "arn:aws:iam::<source-account-id>:role/s3-replication-role",
  "Rules": [{
      "Status": "Enabled",
      "Priority": 1,
      "DeleteMarkerReplication": {"Status": "Disabled"},
      "Filter": {"Prefix": ""},
      "Destination": {
          "Bucket": "arn:aws:s3:::my-replica-bucket",
          "StorageClass": "STANDARD"
      }
  }]
}'

📤 Step 5 – Verify Replication

Upload an object to my-primary-bucket.
Within seconds, the same key appears in my-replica-bucket (Mumbai).
Check object metadata → “Replication Status = COMPLETED”.

🧑‍🤝‍🧑 4. Cross-Account Replication and Sharing

🎯 Use Case

You own Account A and want to replicate or share data with Account B (partner or analytics team).

A. Cross-Account Replication Setup

Destination bucket resides in Account B.
Account B adds a bucket policy permitting writes from Account A’s replication role:


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::<AccountA-ID>:role/s3-replication-role" },
    "Action": ["s3:ReplicateObject", "s3:ReplicateDelete"],
    "Resource": "arn:aws:s3:::my-replica-bucket/*"
  }]
}

Account A configures CRR exactly as before, targeting the bucket ARN in Account B.

✅ Now every new object uploaded in Account A’s my-primary-bucket will be replicated automatically to Account B’s bucket in Mumbai.

B. Cross-Account File Sharing Without Replication

If you just want to share existing S3 files:

Method	Description
Pre-Signed URL	Time-limited link granting read/write access to a single object.
Bucket Policy	Allow specific AWS accounts, IAM users, or roles to access your bucket.
S3 Access Points	Simplify large-scale, multi-tenant access with fine-grained policies.
AWS Resource Access Manager (RAM)	Share entire S3 buckets or subnets securely across accounts in the same Org.

Example – Pre-Signed URL


aws s3 presign s3://my-primary-bucket/data/report.csv --expires-in 3600

This generates a URL valid for 1 hour.

⚖️ 5. Architecture Summary

Layer	Default Behavior	Optional Enhancement
Intra-Region	Automatic multi-AZ replication	N/A
Cross-Region	Manual via CRR / SRR	Configure replication rules
Cross-Account	Manual policy or RAM	Combine with CRR for multi-account DR
Sharing	Private by default	Pre-signed URLs / Access Points / RAM

🧠 Interview Cheat Sheet

Question	Quick Answer
Does S3 Standard replicate across Regions?	❌ No, only across AZs within one Region.
How to replicate across Regions?	Enable Cross-Region Replication (CRR).
Is replication synchronous?	Asynchronous (near real time).
Is Versioning required?	✅ Yes — both source and destination.
Can I replicate across accounts?	✅ Yes — via proper IAM role + bucket policy.
How to share an object temporarily?	Generate a pre-signed URL.
How to share persistently with another account?	Use bucket policies or Access Points.

AWS Storage Deep Dive for Backend Engineers

☁️ AWS Storage Deep Dive for Backend Engineers

S3, EFS, FSx, EBS, and More — with Interview Q&A

🚀 Introduction

Storage is one of the foundational layers of any AWS architecture. Whether you’re building APIs, analytics pipelines, or distributed systems, choosing the right storage solution impacts performance, durability, cost, and scalability.

In backend interviews, AWS storage is a frequent topic, testing your ability to:

Choose the right storage service (object vs. file vs. block)
Optimize cost and performance
Understand durability, consistency, and security

Let’s explore S3, EFS, FSx, EBS, and other key services — along with interview questions and answers you should master.

🪣 1. Amazon S3 — Object Storage for the Cloud

🔹 Overview

Amazon Simple Storage Service (S3) stores data as objects within buckets. It’s designed for 99.999999999% (11 nines) durability and 99.99% availability.
Typical use cases include data lakes, backups, static website hosting, and ML datasets.

🔹 Key Features

Concept	Description
Buckets	Global containers for objects
Objects	Data + metadata stored in buckets
Storage Classes	Standard, Intelligent-Tiering, Glacier, Deep Archive
Versioning	Retain multiple versions of objects
Lifecycle Policies	Automate data movement or deletion
Encryption	SSE-S3, SSE-KMS, or client-side
Access Control	IAM policies, bucket policies, ACLs

🧠 Interview Questions & Answers

1️⃣ What is the durability and availability of S3 Standard?
→ Durability: 99.999999999% (11 nines)
→ Availability: 99.99% per year
Durability means data loss is extremely rare even during regional outages.

2️⃣ What’s the difference between S3 Standard, S3 Infrequent Access, and Glacier?

Tier	Use Case	Retrieval	Cost
Standard	Frequently accessed data	Immediate	High
IA	Infrequent access	Milliseconds	Lower
Glacier	Archival	Minutes–hours	Very low

3️⃣ How does S3 consistency work?
→ As of Dec 2020, S3 provides strong read-after-write consistency for all operations (PUT, DELETE, LIST).

4️⃣ What is multipart upload?
→ It’s a method to upload large files (>100MB) in parallel parts for speed and fault tolerance.

5️⃣ How to securely access S3 within a VPC?
→ Use VPC Endpoints (Gateway/Interface) to route S3 traffic internally without public internet.

✅ Best Practices

Enable S3 Intelligent-Tiering to optimize cost automatically.
Turn on Versioning + MFA Delete for data protection.
Use S3 Access Points for multi-tenant data access.
Enforce encryption at rest (SSE-KMS) and in transit (HTTPS).

📁 2. Amazon EFS — Elastic File Storage

🔹 Overview

Amazon Elastic File System (EFS) provides scalable, serverless, shared file storage for Linux-based workloads. It’s accessible across multiple EC2 instances, containers (ECS/EKS), and on-prem systems.

🔹 Key Features

Feature	Description
Type	Network File System (NFS v4)
Performance Modes	General Purpose / Max I/O
Throughput Modes	Bursting / Provisioned
Availability	Regional, across multiple AZs
Encryption	KMS for at-rest, TLS for in-transit
Access Points	Managed entry points with per-app permissions

🧠 Interview Questions & Answers

1️⃣ Difference between EBS and EFS?
→ EBS = block storage for single instance.
→ EFS = shared file storage accessible by many instances concurrently.

2️⃣ Can EFS be mounted by multiple EC2 instances?
→ Yes. That’s one of its biggest advantages over EBS.

3️⃣ How does EFS scale?
→ Automatically scales from MBs to PBs without manual provisioning.

4️⃣ Difference between bursting and provisioned throughput modes?
→ Bursting: Auto scales based on file size.
→ Provisioned: You pre-allocate throughput for consistent performance.

5️⃣ How to reduce EFS costs?
→ Use EFS Infrequent Access (IA) storage class for rarely accessed files.

✅ Best Practices

Use EFS One Zone for cost-optimized dev/test workloads.
Set up access points for app-specific isolation.
Integrate EFS with EKS PersistentVolumes for containers.
Monitor with CloudWatch metrics (I/O, throughput).

🧩 3. Amazon FSx — Managed File Systems

🔹 Overview

Amazon FSx offers fully managed versions of popular enterprise file systems:

FSx for Windows File Server – for SMB/Windows workloads
FSx for Lustre – for HPC workloads
FSx for NetApp ONTAP – for hybrid and snapshot-based workloads
FSx for OpenZFS – for Linux environments

🧠 Interview Questions & Answers

1️⃣ When to use FSx vs EFS?
→ EFS is Linux-based (NFS).
→ FSx is for specialized workloads (Windows, HPC, hybrid).

2️⃣ What is FSx for Lustre?
→ High-performance file system designed for compute-intensive workloads; can link directly with S3.

3️⃣ How does FSx integrate with S3?
→ FSx for Lustre can import data from S3 at startup and export results back — ideal for analytics pipelines.

4️⃣ What is FSx for Windows File Server used for?
→ Provides SMB access with Active Directory integration — suited for Windows apps like SAP or .NET.

5️⃣ What is SnapMirror in FSx for NetApp ONTAP?
→ Data replication feature for backup/disaster recovery between AWS and on-prem NetApp systems.

✅ Best Practices

Choose FSx type aligned with your OS/workload.
Enable encryption with KMS for compliance.
Use DataSync to move data between on-prem and FSx.
For analytics, pair FSx for Lustre with S3 buckets.

💾 4. Amazon EBS — Elastic Block Store

🔹 Overview

EBS provides block-level storage volumes for EC2 instances — like attaching virtual disks.
It’s ideal for databases, boot volumes, and transactional systems.

🧠 Interview Questions & Answers

1️⃣ Difference between EBS and EFS?
→ EBS = single EC2 instance block storage.
→ EFS = shared NFS file system for multiple instances.

2️⃣ What are EBS volume types?

Type	Use Case
gp3	General-purpose (balanced price/performance)
io2	High IOPS databases
st1/sc1	Throughput-optimized HDD for sequential I/O

3️⃣ Can you detach and attach EBS volumes between instances?
→ Yes, within the same AZ. Supports live snapshots for backup.

4️⃣ How to improve EBS performance?
→ Use EBS-optimized instances, provisioned IOPS, or RAID 0 striping.

5️⃣ Is EBS replicated across AZs?
→ No, replication is within a single AZ (but durable). Use snapshots to S3 for cross-AZ/region backup.

✅ Best Practices

Use gp3 over gp2 for cost efficiency.
Automate snapshots using AWS Backup.
Encrypt volumes and snapshots using KMS.
Enable delete-on-termination for temporary volumes.

🧮 5. Supporting Services in AWS Storage Ecosystem

Service	Type	Use Case
AWS Storage Gateway	Hybrid	Bridge on-prem storage to AWS
AWS Backup	Management	Centralized backup across S3, EFS, RDS, DynamoDB
AWS Snow Family	Data Transfer	Offline data migration at petabyte scale
AWS DataSync	Data Transfer	High-speed data transfer between on-prem and AWS
AWS Glacier / Deep Archive	Archival	Long-term data retention with low cost

🧩 Real Interview Scenarios with Answers

Scenario 1:
You need to store 10TB of log data accessed occasionally for analytics.
→ Use S3 Standard-IA or Intelligent-Tiering with Athena for queries.

Scenario 2:
Multiple EC2s need shared configuration files.
→ Use EFS mounted via NFS across all EC2s.

Scenario 3:
A Windows application needs shared SMB file access.
→ Use FSx for Windows File Server integrated with AD.

Scenario 4:
A PostgreSQL database needs high IOPS block storage.
→ Use EBS io2 volumes with Provisioned IOPS.

Scenario 5:
You must replicate files between on-prem servers and AWS.
→ Use AWS DataSync or Storage Gateway (File Gateway).

🧭 Quick Comparison — Choosing the Right AWS Storage

Use Case	Service	Type	Shared Access	Scalability	Typical Cost
Data lake, backups, static assets	S3	Object	Yes	Unlimited	Low
Shared file system for Linux apps	EFS	File	Yes	Auto	Medium
Windows/HPC workloads	FSx	File	Yes	Configurable	Medium–High
Databases, boot disks	EBS	Block	No	Manual	Medium
Archival backups	Glacier	Object	No	High	Very Low

🔐 Security and Compliance Checklist

✅ Enable encryption at rest (KMS) and in transit (TLS).
✅ Restrict access using IAM roles/policies.
✅ Use VPC endpoints for S3/EFS private access.
✅ Enable CloudTrail for audit logging.
✅ Implement least privilege access principles.

🧠 Key Takeaways

Understand Object vs. File vs. Block storage distinctions.
Remember S3 = scalability, EFS = shared Linux, FSx = Windows/HPC, EBS = block storage.
Know durability, availability, encryption, and pricing tiers.
Use lifecycle management to reduce cost automatically.
Be ready to explain design choices in scenario questions.

📘 Summary Table of Core Interview Facts

Topic	Fact
S3 Durability	99.999999999%
EFS Access	Concurrent EC2/EKS
FSx Variants	Windows, Lustre, ONTAP, OpenZFS
EBS Volume Scope	Single AZ
S3 Consistency	Strong read-after-write
Encryption	SSE-S3 / SSE-KMS / Client
Lifecycle Management	Automates storage transitions
Backup Automation	AWS Backup or Lambda
Data Transfer Tools	Snowball, DataSync, Transfer Family

Core Backend Engineering Fundamentals

☕ Core Backend Engineering Fundamentals

Languages & Frameworks

Primary Language: Go, Java, Python, or Node.js
Frameworks: Spring Boot (Java), FastAPI (Python), Gin (Go), Express (Node.js)
Testing: Unit, integration, and load testing (JUnit, pytest, Go test)

System Design

Scalability: Load balancers, caching, database sharding
High Availability & Fault Tolerance
API Design: REST, GraphQL, gRPC
Rate limiting, retries, and circuit breakers
Event-driven architectures (Kafka, SQS, SNS)

Databases

SQL: PostgreSQL, MySQL (indexes, joins, transactions)
NoSQL: DynamoDB, MongoDB, Redis
Data Modeling & Partitioning

Security

Authentication/Authorization (JWT, OAuth2)
Encryption (KMS, SSL/TLS)
Secrets management (AWS Secrets Manager, Parameter Store)

☁️ 2. AWS Cloud Infrastructure for Backend Engineers

Core AWS Services

Area	Key Services
Compute	EC2, ECS, EKS (Kubernetes), Lambda
Storage	S3, EFS, FSx
Database	RDS (PostgreSQL/MySQL), DynamoDB, Aurora
Networking	VPC, Subnets, Route53, ALB/NLB, Security Groups
Messaging	SQS, SNS, EventBridge, Kinesis
Monitoring	CloudWatch, X-Ray, CloudTrail
Security	IAM (roles, policies), KMS, GuardDuty

DevOps/Deployment

CI/CD using CodePipeline, CodeBuild, CodeDeploy, or GitHub Actions
Infrastructure as Code: Terraform, CloudFormation, or CDK
Containerization: Docker + ECS/EKS
Auto Scaling Groups & Load Balancers

Serverless Patterns

API Gateway + Lambda + DynamoDB
Step Functions for orchestration
SQS/SNS for async processing

🧩 3. Observability, Performance & Reliability

Metrics & Logging: CloudWatch Metrics/Logs, OpenTelemetry, Prometheus/Grafana
Tracing: AWS X-Ray or Jaeger
Error Tracking: Sentry, Datadog
Performance Optimization: Caching (Redis, ElastiCache), async jobs, batch processing

🧠 4. Advanced Topics (for Senior Roles)

Multi-account strategy and cross-region deployments
Cost optimization (Spot instances, Savings Plans, S3 lifecycle policies)
Data pipelines (Kinesis → Lambda → S3/Snowflake)
API Gateway custom authorizers, WAF integration
Multi-tenant architecture and feature flags
Observability pipelines and OpenTelemetry
AI/ML integration (SageMaker, Bedrock, custom model endpoints)

📘 5. Hands-on Projects to Practice

Build a microservice (e.g., Order Service) using Go or Java + PostgreSQL
Deploy to EKS using Terraform
Add CI/CD with CodePipeline
Add SQS for async order processing
Integrate CloudWatch dashboards and X-Ray tracing