AWS Basics Interview Preparation

AWS (Amazon Web Services) is a cloud computing platform provided by Amazon that offers 200+ on-demand services including compute, storage, databases, networking, security, AI/ML, analytics, and DevOps.

Instead of purchasing and maintaining physical servers, organizations can rent cloud resources and pay only for what they use (Pay-as-you-go model).

Interview Points

• World’s leading cloud platform.
• Provides Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Serverless services.
• Resources can be provisioned in minutes.
• Highly scalable, reliable, and secure.
• Used by startups as well as enterprises.

Example:

A Spring Boot application can be deployed on EC2, store files in S3, use RDS for MySQL, and monitor the application using CloudWatch.

AWS eliminates the need to purchase and maintain physical infrastructure while providing scalable and highly available cloud services.

Key Advantages

1. Pay-as-you-go Pricing

• Pay only for resources used.
• No upfront hardware investment.

2. Scalability

• Scale resources up or down within minutes.
• Supports Auto Scaling.

3. High Availability

• Applications can run across multiple Availability Zones.
• Reduces downtime.

4. Global Presence

• Multiple Regions worldwide.
• Deploy applications closer to users for lower latency.

5. Security

• Encryption
• IAM (Identity & Access Management)
• Security Groups
• VPC Isolation
• Compliance certifications

6. Reliability

• Built-in backup and disaster recovery options.
• Multiple redundant data centers.

7. Faster Deployment

• Infrastructure can be created within minutes.
• Supports Infrastructure as Code (CloudFormation, Terraform).

8. Managed Services

• AWS manages databases, messaging, monitoring, caching, and many other services.
• Developers focus on business logic instead of infrastructure.

Traditional Data Center vs AWS

Traditional Data Center	AWS Cloud
Buy physical servers	Rent virtual resources
High upfront cost	Pay-as-you-go
Manual scaling	Auto Scaling
Weeks/months to provision	Minutes
Hardware maintenance required	Managed by AWS
Limited redundancy	Multi-AZ architecture

Interview Tip:

Mention that AWS reduces operational overhead and enables faster development and deployment.

AWS Global Infrastructure is the worldwide network of AWS data centers that enables applications to be highly available, fault tolerant, and low latency.

It consists of:

• Regions
• Availability Zones (AZs)
• Edge Locations
• Regional Edge Caches

Components

1. Region

A geographical area where AWS has multiple data centers.

Examples:

• Mumbai
• Singapore
• Frankfurt
• London
• Ohio

Each Region is completely isolated from other Regions.

2. Availability Zone (AZ)

An Availability Zone is one or more physically separate data centers within a Region.

Characteristics:

• Independent power supply
• Independent cooling
• Independent networking
• Connected with high-speed private fiber

Example:

Mumbai Region contains multiple Availability Zones.

3. Edge Locations

Edge Locations are worldwide locations used by AWS CDN (CloudFront), Route 53, and other edge services.

Purpose:

• Cache content near users.
• Reduce latency.
• Improve performance.

4. Regional Edge Cache

A larger cache between Edge Locations and AWS Regions.

Used for:

• Frequently accessed content
• Improved cache hit ratio

Interview Summary

AWS Global Infrastructure

Global
   │
   ├── Region (Mumbai)
   │      ├── AZ-A
   │      ├── AZ-B
   │      └── AZ-C
   │
   ├── Region (Singapore)
   │      ├── AZ-A
   │      └── AZ-B
   │
   └── Edge Locations (Worldwide)

Region

A Region is a separate geographic location where AWS hosts multiple data centers.

Examples:

• Mumbai
• Singapore
• Tokyo
• London

Each Region operates independently and has isolated infrastructure.

Availability Zone (AZ)

An Availability Zone is one or more physically separate data centers inside a Region.

Each AZ has:

• Independent power
• Independent networking
• Independent cooling

Multiple AZs are connected using high-speed private fiber.

Why Multiple AZs?

If one Availability Zone fails due to a hardware or power issue, applications running in another AZ continue to serve users without interruption.

Interview Example

Deploy:

• EC2 in AZ-A
• Another EC2 in AZ-B
• RDS Multi-AZ

If AZ-A fails, traffic is redirected to AZ-B, ensuring the application remains available.

An Edge Location is a small AWS facility located close to end users that caches content and serves requests with low latency.

It is primarily used by:

• CloudFront (CDN)
• Route 53
• AWS Shield
• AWS WAF
• Global Accelerator

Benefits

• Faster content delivery
• Lower latency
• Reduced load on origin servers
• Better user experience

Example

If a website is hosted in the Mumbai Region and a user accesses it from Delhi, CloudFront can serve cached static content from a nearby Edge Location instead of fetching it from Mumbai every time, resulting in faster response times.

Interview Tip: Remember:

• Region stores your application and data.
• Edge Location stores cached copies closer to users.

Region	Availability Zone
Geographic location	One or more data centers inside a Region
Contains multiple AZs	Part of a Region
Isolated from other Regions	Connected to other AZs in the same Region via private fiber
Used for disaster recovery and global deployment	Used for high availability within a Region
Example: Mumbai	Example: ap-south-1a

Interview Explanation

A Region is a geographical area, while an Availability Zone is an isolated data center (or group of data centers) within that Region. Applications are commonly deployed across multiple AZs for high availability, and across multiple Regions for disaster recovery or serving users globally.

AWS provides High Availability by eliminating single points of failure and distributing applications across multiple infrastructure components.

Key Mechanisms

1. Multiple Availability Zones

• Deploy application instances across multiple AZs.
• If one AZ fails, another continues serving traffic.

2. Elastic Load Balancer (ELB)

• Distributes incoming requests across healthy EC2 instances.
• Automatically stops routing traffic to unhealthy instances.

3. Auto Scaling

• Automatically launches new EC2 instances when demand increases or when an instance becomes unhealthy.
• Terminates extra instances when demand decreases.

4. Multi-AZ Databases

• Services like Amazon RDS replicate data to a standby instance in another AZ.
• Automatic failover occurs during infrastructure failures.

5. Route 53

• Performs health checks and DNS failover.
• Routes traffic to healthy endpoints.

6. Data Replication

• Services like S3 store data redundantly across multiple facilities within a Region for high durability and availability.

Interview Example

A production Spring Boot application can be deployed with:

• EC2 instances in AZ-A and AZ-B
• Application Load Balancer distributing traffic
• Auto Scaling Group maintaining the desired number of instances
• RDS Multi-AZ for database failover
• CloudWatch monitoring health and triggering alarms

If one Availability Zone goes down, the Load Balancer routes traffic to healthy instances in the other AZ, Auto Scaling replaces failed instances if needed, and the database automatically fails over to the standby instance. Users experience minimal or no downtime.

Interview Tip: When answering this question, mention these core services together:

• Availability Zones
• Elastic Load Balancer (ELB)
• Auto Scaling
• RDS Multi-AZ
• Route 53 Health Checks
• CloudWatch Monitoring

This demonstrates a production-level understanding of AWS High Availability.

Amazon EC2 (Elastic Compute Cloud) is a service that provides resizable virtual servers (instances) in the AWS cloud. It allows you to deploy and run applications without managing physical hardware.

EC2 gives complete control over the operating system, installed software, storage, networking, and security configurations.

Interview Points

• Virtual machine in AWS.
• Supports Linux, Windows, Ubuntu, Amazon Linux, etc.
• Can scale up/down vertically (instance type) and horizontally (more instances).
• Pay only for the compute resources used.
• Integrated with services like EBS, ELB, Auto Scaling, IAM, CloudWatch, and VPC.

Example:

A Spring Boot microservice can be deployed on an EC2 instance with Nginx as a reverse proxy, MySQL on RDS, and monitored using CloudWatch.

Launching an EC2 instance involves selecting the required infrastructure and configuration.

Steps

• Open the AWS Management Console.
• Go to EC2 → Launch Instance.
• Choose an Amazon Machine Image (AMI).
• Select the Instance Type (e.g., t3.micro).
• Configure:
• VPC
• Subnet
• Auto-assign Public IP (if required)
• Attach storage (EBS volumes).
• Configure Security Groups (SSH, HTTP, HTTPS, etc.).
• Select or create a Key Pair.
• Review and launch the instance.

Interview Tip: When explaining, mention the important configurations:

• AMI
• Instance Type
• Key Pair
• Security Group
• Storage (EBS)
• VPC/Subnet
• IAM Role (if the application needs AWS service access)

AWS provides different instance families optimized for different workloads.

Instance Type	Purpose	Example Use Cases
General Purpose (T, M)	Balanced CPU, Memory	Web applications, APIs
Compute Optimized (C)	High CPU	Gaming, Batch Processing, Microservices
Memory Optimized (R, X)	Large RAM	Databases, Redis, Analytics
Storage Optimized (I, D)	High Disk I/O	NoSQL, Big Data
Accelerated Computing (P, G, Inf)	GPU/AI	Machine Learning, Video Processing

Common Examples

• t3.micro – Small applications, Free Tier eligible.
• m5.large – Balanced production workloads.
• c6i.large – CPU-intensive applications.
• r6g.large – Memory-intensive applications.

Interview Tip: Remember:

• T → Burstable workloads.
• C → Compute-intensive.
• R → Memory-intensive.
• I/D → Storage-intensive.
• P/G → GPU workloads.

An AMI (Amazon Machine Image) is a pre-configured template used to launch EC2 instances.

It contains:

• Operating System
• Installed software/packages
• Application code (optional)
• Configuration settings
• Root volume configuration

Instead of installing everything manually every time, you can create an AMI and launch identical instances whenever required.

Types of AMIs

• AWS Provided AMIs
• Marketplace AMIs
• Community AMIs
• Custom AMIs

Example

After configuring a production-ready Spring Boot server with Java, Nginx, Docker, and monitoring tools, you can create a custom AMI and use it to launch multiple identical EC2 instances.

Interview Tip: An AMI is like a template or blueprint used to create new EC2 instances.

AMI	Snapshot
Template for launching EC2 instances	Backup of an EBS volume
Includes OS and launch configuration	Contains only disk data
Used to create new EC2 instances	Used to restore storage
Can include one or more snapshots	Represents a point-in-time copy of a volume

Interview Explanation

• AMI is used when you want to launch new servers with the same configuration.
• Snapshot is used to back up or restore the data stored on an EBS volume.

Example

• Take an EBS Snapshot before upgrading a server so you can restore the disk if needed.
• Create an AMI after fully configuring the server so you can launch multiple identical servers.

An Elastic IP (EIP) is a static public IPv4 address provided by AWS that can be associated with an EC2 instance.

Unlike the default public IP, an Elastic IP remains the same even if the instance is stopped and started (as long as it remains associated).

Benefits

• Static public IP address.
• Can be remapped quickly to another EC2 instance.
• Useful during failover scenarios.
• Ideal for production applications requiring a fixed public IP.

Interview Example

If the production server fails, the Elastic IP can be reassigned to a standby EC2 instance, allowing users to continue accessing the application without changing DNS records.

Interview Tip: Elastic IPs are limited resources. AWS recommends using Load Balancers instead of assigning Elastic IPs to multiple application servers.

The connection method depends on the operating system.

Linux Instance

ssh -i my-key.pem ec2-user@

or

ssh -i my-key.pem ubuntu@

Windows Instance

• Use Remote Desktop Protocol (RDP).
• Download the Windows administrator password using the key pair.

Prerequisites

• EC2 instance must be running.
• Correct Security Group rules:
• SSH (Port 22) for Linux.
• RDP (Port 3389) for Windows.
• Public IP or Elastic IP (or VPN/Bastion Host for private instances).
• Valid Key Pair.

Interview Tip: For production environments:

• Avoid exposing SSH to the internet.
• Use AWS Systems Manager Session Manager or a Bastion Host for secure access.

A Security Group is a virtual firewall attached to an EC2 instance that controls inbound and outbound traffic.

It operates at the instance level.

Characteristics

• Stateful firewall.
• Supports Allow rules only.
• No Deny rules.
• Applied to EC2 instances, RDS, and other AWS resources.
• Multiple Security Groups can be attached to one instance.

Example Rules

Type	Port	Source
SSH	22	Your IP
HTTP	80	0.0.0.0/0
HTTPS	443	0.0.0.0/0

Interview Example

For a Spring Boot application:

• Allow 80 and 443 from the internet.
• Allow 22 only from the administrator’s IP.
• Restrict database access (3306) to the application Security Group instead of exposing it publicly.

Interview Tip: Security Groups are stateful, meaning if inbound traffic is allowed, the response traffic is automatically allowed without requiring a separate outbound rule.

Security Group	Network ACL (NACL)
Instance-level firewall	Subnet-level firewall
Stateful	Stateless
Supports Allow rules only	Supports Allow and Deny rules
Applied to EC2 instances	Applied to subnets
Return traffic automatically allowed	Return traffic must be explicitly allowed
Default allows all outbound traffic	Default NACL allows all inbound/outbound; custom NACLs require explicit rules

Interview Explanation

• Security Group protects individual EC2 instances.
• Network ACL provides an additional layer of security at the subnet level.

Interview Scenario

Suppose you want to block an entire IP range from reaching a subnet. Use a Network ACL with a Deny rule. To control which ports a specific EC2 instance accepts, use a Security Group.

Interview Tip: A common interview question is: Which is stateful and which is stateless?

• Security Group → Stateful
• Network ACL → Stateless

EC2 instances can be scaled in two ways:

1. Vertical Scaling (Scale Up/Down)

Increase or decrease the instance size.

Example:

• t3.micro → t3.large
• m5.large → m5.xlarge

Suitable when a single server needs more CPU or memory. This may require stopping and restarting the instance.

2. Horizontal Scaling (Scale Out/In)

Add or remove EC2 instances based on application demand.

AWS services used:

• Auto Scaling Group (ASG) to automatically launch or terminate instances.
• Elastic Load Balancer (ELB) to distribute traffic across healthy instances.
• CloudWatch to monitor metrics (CPU, memory via agent, request count) and trigger scaling policies.

Example

A Spring Boot application normally runs with 2 EC2 instances. During peak traffic, if CPU utilization exceeds 70%, CloudWatch triggers the Auto Scaling Group to launch additional instances. The Load Balancer automatically starts routing traffic to the new instances. When traffic decreases, the extra instances are terminated to reduce costs.

Interview Tip: Mention both scaling strategies:

• Vertical Scaling → Increase the capacity of an existing instance.
• Horizontal Scaling → Add more instances using Auto Scaling Groups and Elastic Load Balancers.

For production systems, horizontal scaling is generally preferred because it improves both scalability and high availability.

Amazon EBS (Elastic Block Store) is a persistent block storage service that provides storage volumes for Amazon EC2 instances.

An EBS volume behaves like a physical hard disk attached to a virtual machine. It stores the operating system, applications, databases, and other data.

Unlike Instance Store, EBS data persists even after the EC2 instance is stopped or restarted.

Key Features

• Persistent storage
• High availability within an Availability Zone
• SSD and HDD volume options
• Snapshots for backup
• Supports encryption
• Volume can be resized without data loss
• Can be detached and attached to another EC2 instance (within the same AZ)

Common Use Cases

• Operating System (Boot Volume)
• Databases (MySQL, PostgreSQL)
• Enterprise applications
• File systems
• Log storage

Interview Example

A Spring Boot application runs on an EC2 instance:

• Application code and OS are stored on an EBS volume.
• MySQL database runs on Amazon RDS.
• If the EC2 instance is restarted, the application and data on EBS remain intact.

Interview Tip: Think of EBS as the hard disk of an EC2 instance.

Amazon EBS	Instance Store
Persistent storage	Temporary (ephemeral) storage
Data survives stop/start	Data is lost if the instance stops, terminates, or the underlying host fails
Network-attached storage	Physically attached to the host server
Supports snapshots	Does not support snapshots
Can be detached and attached to another instance (same AZ)	Cannot be detached or moved
Suitable for databases, applications, OS	Suitable for cache, buffers, temporary files

Interview Explanation

• EBS is used when data durability is important.
• Instance Store is used for temporary data that can be recreated.

Example

Use EBS

• Spring Boot application
• Database
• User uploads
• Production workloads

Use Instance Store

• Cache
• Temporary logs
• Scratch space
• Batch processing intermediate files

Interview Tip: A common interview question is:

What happens if an EC2 instance stops?

• EBS → Data remains.
• Instance Store → Data is lost.

An EBS Snapshot is a point-in-time backup of an EBS volume stored in Amazon S3 (managed internally by AWS).

Snapshots are incremental, meaning after the first full snapshot, only the changed blocks are stored, reducing storage costs and backup time.

Benefits

• Backup and recovery
• Disaster recovery
• Create new EBS volumes
• Create custom AMIs
• Cross-region backup (by copying snapshots)
• Incremental backups

Interview Example

Before upgrading a production application:

• Take an EBS Snapshot.
• Perform the upgrade.
• If the upgrade fails, create a new EBS volume from the snapshot and restore the application quickly.

Interview Tip: Remember:

• Snapshot = Backup of an EBS Volume.
• AMI = Template for launching EC2 instances.

Yes.

AWS allows you to increase the size, change the volume type, and provisioned IOPS of most EBS volumes without stopping the EC2 instance, using the Elastic Volumes feature.

Steps

• Modify the EBS volume from the AWS Console, CLI, or API.
• Wait until the volume modification is complete.
• Extend the partition and file system inside the operating system.

For Linux:

lsblk

sudo growpart /dev/xvda 1

sudo resize2fs /dev/xvda1

*(Commands may differ based on the file system, such as XFS or ext4.)*

Interview Example

A production database server has a 100 GB gp3 volume, and disk usage reaches 90%. Instead of shutting down the server, the storage is increased to 200 GB, and the file system is expanded online. The application continues running with minimal or no downtime.

Interview Tip: Mention Elastic Volumes, as interviewers often expect this term when discussing online EBS modifications.

5. Different EBS volume types (gp3, io2, st1, sc1)

AWS provides different EBS volume types optimized for different workloads.

Volume Type	Storage Type	Best For
gp3	SSD	General-purpose workloads
io2	SSD	High-performance databases requiring consistent IOPS
st1	HDD	Frequently accessed large sequential workloads
sc1	HDD	Infrequently accessed cold data

1. gp3 (General Purpose SSD)

Most commonly used EBS volume.

Features

• Balanced performance
• Low latency
• Independent configuration of storage, IOPS, and throughput
• Cost-effective

Best For

• Web applications
• Spring Boot applications
• Boot volumes
• Development and production servers
• Small to medium databases

2. io2 (Provisioned IOPS SSD)

Designed for applications requiring very high and consistent I/O performance.

Features

• Very high IOPS
• Low latency
• High durability
• Predictable performance

Best For

• Oracle Database
• SQL Server
• SAP
• Financial applications
• Large production databases

3. st1 (Throughput Optimized HDD)

Optimized for high-throughput sequential read/write workloads, not for random I/O.

Best For

• Big Data
• Data warehouses
• Log processing
• Streaming workloads

4. sc1 (Cold HDD)

Lowest-cost EBS storage for data accessed infrequently.

Best For

• Backups
• Archived logs
• Historical records
• Cold storage

Interview Summary

Volume	Performance	Typical Use Case
gp3	Balanced SSD	Most applications (default choice)
io2	Highest IOPS SSD	Mission-critical databases
st1	High throughput HDD	Analytics, Big Data, log processing
sc1	Low-cost HDD	Backup and archival data

Interview Tip: If asked “Which EBS volume do you generally use?”, a good production-oriented answer is:

“For most Spring Boot and microservice applications, I use gp3 because it provides a good balance of performance and cost. For high-performance databases requiring consistent IOPS, I would choose io2. For log processing or analytics, st1 is suitable, while sc1 is used for archival and infrequently accessed data.”

Amazon S3 (Simple Storage Service) is a highly scalable, durable, and secure object storage service provided by AWS.

Unlike EBS, which provides block storage, S3 stores data as objects inside buckets. Each object consists of:

• Data (file)
• Metadata
• Unique Object Key

S3 is designed to store virtually unlimited amounts of data with 11 nines (99.999999999%) durability.

Key Features

• Object storage
• Virtually unlimited storage
• Highly durable (99.999999999%)
• High availability
• Secure with IAM, Bucket Policies, ACLs, and encryption
• Versioning support
• Lifecycle Management
• Cross-Region Replication
• Static website hosting

Common Use Cases

• Images and videos
• User uploads
• PDF storage
• Application logs
• Backups
• Static website hosting
• Data lakes

Interview Example

In a Spring Boot application:

• User uploads profile images.
• Images are stored in an S3 bucket.
• Only the image URL is stored in the database.
• The application retrieves the image directly from S3.

Interview Tip: Think of S3 as cloud storage for files, while EBS is cloud storage for disks.

An S3 Bucket is a logical container used to store objects (files) in Amazon S3.

Every object in S3 must be stored inside a bucket.

Characteristics

• Bucket names must be globally unique.
• A bucket belongs to a specific AWS Region.
• Buckets can store unlimited objects.
• Objects are identified using a unique Object Key.

Example

my-company-images
│
├── profile/
│      user1.jpg
│      user2.jpg
│
├── invoices/
│      invoice1.pdf
│
└── documents/
       report.pdf

Interview Tip: A bucket is similar to a folder or container, while the files inside are called objects.

S3 offers multiple storage classes optimized for different access patterns and cost requirements.

Storage Class	Best For
S3 Standard	Frequently accessed data
S3 Intelligent-Tiering	Unknown or changing access patterns
S3 Standard-IA	Infrequently accessed data
S3 One Zone-IA	Infrequently accessed, non-critical data
S3 Glacier Instant Retrieval	Archived data requiring immediate access
S3 Glacier Flexible Retrieval	Long-term archives with retrieval delays
S3 Glacier Deep Archive	Lowest-cost long-term archival
S3 Express One Zone	Ultra-low latency and high-performance workloads within one AZ

Summary

S3 Standard

• Frequently accessed files
• High availability
• Low latency

Intelligent-Tiering

• Automatically moves data between tiers
• Cost optimization

Standard-IA

• Less frequently accessed files
• Lower storage cost
• Retrieval charges apply

One Zone-IA

• Stored in a single AZ
• Lower cost
• Suitable for data that can be recreated

Glacier Storage Classes

• Long-term archival
• Very low storage cost
• Retrieval time depends on the Glacier option

Interview Tip: Remember:

• Frequently accessed → Standard
• Unknown access pattern → Intelligent-Tiering
• Rarely accessed → Standard-IA
• Archive → Glacier

S3 Standard	Glacier
Frequently accessed data	Long-term archival
Immediate access	Retrieval may take from minutes to hours depending on the Glacier tier
Higher storage cost	Much lower storage cost
No retrieval delay	Retrieval process required
Suitable for production applications	Suitable for backup and compliance archives

Interview Example

S3 Standard

• Website images
• Videos
• Documents
• Static content

Glacier

• Seven-year compliance backups
• Old invoices
• Archived logs
• Historical reports

Interview Tip: A common production pattern is:

• New files → S3 Standard
• After 90 days → Glacier using Lifecycle Rules.

Versioning is an S3 feature that keeps multiple versions of the same object.

Instead of permanently overwriting or deleting a file, S3 stores previous versions, allowing data recovery.

Benefits

• Protects against accidental deletion
• Protects against accidental overwrite
• Supports data recovery
• Improves backup and disaster recovery

Example

report.pdf (Version 1)

↓

report.pdf (Version 2)

↓

report.pdf (Version 3)

All previous versions remain available until deleted.

Interview Example

A user accidentally uploads an incorrect PDF. Since versioning is enabled, the previous version can be restored without data loss.

Interview Tip: Versioning is commonly used together with Lifecycle Policies to automatically remove older versions after a defined period.

Lifecycle Management automatically moves or deletes S3 objects based on predefined rules.

It helps reduce storage costs by transitioning data to cheaper storage classes or deleting obsolete files.

Common Actions

• Move Standard → Standard-IA
• Move Standard-IA → Glacier
• Move Glacier → Deep Archive
• Delete expired objects
• Delete old object versions

Example Rule

Day 0
↓
S3 Standard

↓

30 Days
↓

Standard-IA

↓

90 Days
↓

Glacier

↓

365 Days
↓

Delete

Interview Example

Application logs are:

• Stored in S3 Standard initially.
• Moved to Glacier after 90 days.
• Automatically deleted after one year.

This reduces storage costs without manual intervention.

Cross-Region Replication (CRR) automatically copies objects from one S3 bucket to another bucket in a different AWS Region.

Replication occurs asynchronously after objects are uploaded.

Benefits

• Disaster recovery
• Global availability
• Compliance requirements
• Reduced latency for users in other regions

Requirements

• Versioning must be enabled on both buckets.
• Appropriate IAM permissions.
• Source and destination buckets are in different Regions.

Interview Example

Files uploaded to a bucket in the Mumbai Region are automatically replicated to a bucket in the Singapore Region. If the Mumbai Region becomes unavailable, applications can continue using the replicated data.

Interview Tip: – CRR → Replicates across different Regions.

• Same-Region Replication (SRR) → Replicates within the same Region.

Yes.

Amazon S3 can host static websites containing:

• HTML
• CSS
• JavaScript
• Images
• Fonts

It cannot execute server-side code such as Java, Spring Boot, PHP, or Node.js.

Steps

• Create an S3 bucket.
• Upload website files.
• Enable Static Website Hosting.
• Configure index.html and error.html.
• Grant appropriate read permissions (or use CloudFront with Origin Access Control for production).

Common Use Cases

• Portfolio websites
• Documentation
• Landing pages
• React, Angular, or Vue build outputs

Interview Example

A React frontend is deployed to S3, while the backend Spring Boot REST APIs run on EC2 or ECS. The frontend communicates with the backend using HTTPS.

Interview Tip: S3 is suitable only for static content. Dynamic server-side applications must run on services such as EC2, ECS, Elastic Beanstalk, or Lambda.

Amazon S3	Amazon EBS
Object Storage	Block Storage
Stores files as objects	Stores data as disk blocks
Accessed via HTTP/HTTPS APIs	Attached directly to EC2 instances
Virtually unlimited storage	Fixed-size volumes (can be resized)
Not attached as a disk	Appears as a disk to the operating system
Suitable for files, backups, media	Suitable for OS, databases, applications
Supports static website hosting	Cannot host websites directly

Interview Explanation

• S3 stores files such as images, videos, documents, and backups.
• EBS provides disk storage for EC2 instances, storing operating systems, applications, and databases.

Interview Scenario

A production Spring Boot application uses:

• EBS for the EC2 instance’s operating system and application files.
• S3 for user-uploaded images and documents.
• RDS for relational database storage.

Interview Tip: A simple way to remember:

• EBS = Hard Disk for EC2
• S3 = Cloud Storage for Files

IAM (Identity and Access Management) is an AWS service used to securely control who can access AWS resources and what actions they can perform.

It enables authentication (who you are) and authorization (what you can do).

Instead of sharing AWS root credentials, IAM allows you to create users, groups, roles, and policies with specific permissions.

Key Features

• User authentication
• Fine-grained access control
• Role-based access
• Multi-Factor Authentication (MFA)
• Temporary credentials
• Centralized permission management

Common IAM Components

• Users
• Groups
• Roles
• Policies

Interview Example

In a company:

• Developers have access to EC2 and CloudWatch.
• DevOps engineers have full infrastructure access.
• Finance team has billing access only.

IAM ensures each team gets only the permissions required for their job.

Interview Tip: Remember:

Authentication → Who are you?

Authorization → What are you allowed to do?

IAM handles both.

IAM User	IAM Group	IAM Role
Represents a person or application	Collection of IAM Users	Temporary identity with permissions
Permanent credentials	Simplifies permission management	No permanent credentials
Can have Access Keys and Password	Cannot log in directly	Assumed when needed
Used by employees or applications	Used to assign common permissions	Used by AWS services or cross-account access

Interview Explanation

IAM User

Represents an individual person or application.

Example:

• Prakash
• DevOps Engineer
• CI/CD Application

IAM Group

A collection of IAM Users with common permissions.

Example:

• Developers
• QA Team
• Admin Team

Instead of assigning permissions individually, assign them to the group.

IAM Role

A temporary identity assumed by:

• EC2
• Lambda
• ECS
• Cross-account users
• Federated users

Roles provide temporary security credentials.

Interview Example

An EC2 instance needs to read files from S3.

Instead of storing AWS Access Keys inside the application, attach an IAM Role to the EC2 instance. AWS automatically provides temporary credentials.

IAM Policies are JSON documents that define permissions for AWS resources.

They specify:

• Effect (Allow or Deny)
• Action (What operations are allowed)
• Resource (Which AWS resources)

Example Policy

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Effect":"Allow",
      "Action":"s3:GetObject",
      "Resource":"arn:aws:s3:::my-bucket/*"
    }
  ]
}

This policy allows reading objects from my-bucket.

Types of Policies

• AWS Managed Policies
• Customer Managed Policies
• Inline Policies

Interview Tip: Policies do not grant permissions by themselves. They must be attached to a User, Group, or Role.

Managed Policy	Inline Policy
Standalone policy	Embedded directly into a User, Group, or Role
Can be attached to multiple identities	Can be attached to only one identity
Easy to reuse	Not reusable
Easier to manage	Suitable for one-off permissions
Can be AWS-managed or customer-managed	Created by the customer only

Interview Explanation

Managed Policy

• Reusable.
• Centralized management.
• Updating the policy affects all attached identities.

Inline Policy

• Exists only within one specific User, Group, or Role.
• Deleted automatically if the identity is deleted.

Interview Tip: For production environments:

• Prefer Managed Policies because they are reusable and easier to maintain.
• Use Inline Policies only when permissions must remain tightly coupled to a single identity.

The Principle of Least Privilege (PoLP) means granting only the minimum permissions required to perform a task.

Users and applications should never receive unnecessary permissions.

Benefits

• Improved security
• Reduced attack surface
• Lower risk of accidental changes
• Compliance with security best practices

Example

Instead of giving:

AdministratorAccess

Grant only:

s3:GetObject
s3:PutObject

for a specific bucket.

Interview Example

A Spring Boot application only uploads images to S3.

Instead of granting full S3 access, create a policy allowing:

• s3:PutObject
• s3:GetObject

only for that bucket.

Interview Tip: This is one of AWS’s most important security best practices and is frequently asked in interviews.

Use an IAM Role whenever AWS services need to access other AWS services.

IAM Roles provide temporary credentials, while Access Keys are long-term credentials.

Use IAM Role

• EC2 accessing S3
• Lambda accessing DynamoDB
• ECS accessing Secrets Manager
• Cross-account access
• EKS Pods accessing AWS services

Use Access Keys

• External applications
• Third-party integrations
• CLI access (where roles are not available)

Why Roles are Preferred

• No hardcoded credentials
• Automatic credential rotation
• Temporary security credentials
• More secure
• Managed by AWS

Interview Example

Instead of storing AWS Access Keys inside a Spring Boot application’s application.properties, attach an IAM Role to the EC2 instance. The AWS SDK automatically retrieves temporary credentials from the instance metadata service.

Interview Tip: Production Best Practice:

Never hardcode Access Keys inside application code. Prefer IAM Roles whenever possible.

The recommended approach is to attach an IAM Role to the EC2 instance.

Steps

• Create an IAM Role.
• Attach an S3 access policy.
• Attach the Role to the EC2 instance.
• AWS automatically provides temporary credentials.
• The AWS SDK retrieves these credentials automatically.

Flow

EC2 Instance
      │
      ▼
IAM Role
      │
      ▼
Temporary Credentials
      │
      ▼
Amazon S3

Interview Example

A Spring Boot application uploads images to S3.

Instead of storing AWS Access Keys in the application:

• Create an IAM Role with:
• s3:GetObject
• s3:PutObject
• Attach the role to the EC2 instance.
• The AWS SDK securely accesses S3 using temporary credentials.

Interview Tip: This is the AWS-recommended and production-ready approach for accessing AWS services from EC2.

#

A VPC (Virtual Private Cloud) is a logically isolated virtual network in AWS where you can launch and manage AWS resources securely.

It gives you complete control over:

• IP address ranges
• Subnets
• Route Tables
• Internet access
• Security settings

A VPC is similar to your own private data center in the cloud.

Key Components

• CIDR Block
• Public Subnet
• Private Subnet
• Internet Gateway
• NAT Gateway
• Route Tables
• Network ACLs
• Security Groups

Interview Example

A production application architecture:

• Public Subnet
• Application Load Balancer
• NAT Gateway

• Private Subnet
• EC2 (Spring Boot)
• RDS Database

The database is not directly accessible from the internet.

Public Subnet	Private Subnet
Has a route to an Internet Gateway	No direct route to an Internet Gateway
Resources can have public IPs	Resources typically have only private IPs
Internet accessible	Not directly accessible from the internet
Hosts ALBs, Bastion Hosts, NAT Gateways	Hosts application servers and databases

Interview Example

Public Subnet

• Application Load Balancer
• Bastion Host
• NAT Gateway

Private Subnet

• Spring Boot EC2 instances
• RDS
• Redis
• Internal services

Interview Tip: Production applications usually keep business logic and databases in private subnets for better security.

An Internet Gateway (IGW) is a VPC component that enables communication between a VPC and the public internet.

It allows:

• Inbound internet traffic
• Outbound internet traffic

To make an EC2 instance publicly accessible, you need:

• A public subnet
• A route to the Internet Gateway
• A public or Elastic IP
• Appropriate Security Group rules

Interview Example

A public-facing web server uses:

• Public Subnet
• Internet Gateway
• Public IP
• Security Group allowing ports 80 and 443

Users can access the application over the internet.

A NAT (Network Address Translation) Gateway allows instances in a private subnet to access the internet for outbound connections, while preventing inbound internet connections.

Common Uses

• Download software updates
• Access S3
• Pull Docker images
• Call external APIs

Traffic Flow

Private EC2
      │
      ▼
NAT Gateway
      │
      ▼
Internet Gateway
      │
      ▼
Internet

Interview Example

A Spring Boot application in a private subnet needs to download Maven dependencies or call an external payment gateway API. It accesses the internet through the NAT Gateway without exposing the instance to inbound internet traffic.

Interview Tip: A NAT Gateway provides outbound-only internet access for private resources.

A Route Table contains rules that determine where network traffic from a subnet should be directed.

Each subnet is associated with a Route Table.

Example

Destination	Target
10.0.0.0/16	Local
0.0.0.0/0	Internet Gateway

For a private subnet:

Destination	Target
10.0.0.0/16	Local
0.0.0.0/0	NAT Gateway

Interview Tip: A subnet becomes public when its Route Table contains a default route (0.0.0.0/0) pointing to an Internet Gateway.

CIDR (Classless Inter-Domain Routing) is a notation used to define the IP address range of a VPC or subnet.

Example:

10.0.0.0/16

• Network Address: 10.0.0.0
• Prefix: /16
• Supports 65,536 IP addresses (before AWS reserves a few addresses per subnet)

Common CIDR Examples

CIDR	Approximate IP Addresses
/16	65,536
/24	256
/28	16

Interview Example

A VPC with CIDR 10.0.0.0/16 can be divided into smaller subnets such as:

• 10.0.1.0/24
• 10.0.2.0/24
• 10.0.3.0/24

Private instances do not have direct internet access because they have no route to an Internet Gateway.

Instead, they access the internet through a NAT Gateway located in a public subnet.

Architecture

Internet
    │
Internet Gateway
    │
Public Subnet
    │
NAT Gateway
    │
Private Subnet
    │
EC2 Instance

Interview Example

A Spring Boot application runs in a private subnet. It needs to:

• Download OS updates
• Pull Docker images
• Access third-party payment APIs
• Send emails through an external SMTP service

The Route Table for the private subnet points 0.0.0.0/0 to the NAT Gateway, allowing outbound internet access while preventing inbound connections.

Interview Tip: For a production architecture, mention this flow together:

• Application Load Balancer in a Public Subnet
• EC2 Application Servers in Private Subnets
• RDS Database in Private Subnets
• NAT Gateway for outbound internet access
• Internet Gateway attached to the VPC

This demonstrates a secure, highly available AWS network design commonly used in real-world deployments.

Elastic Load Balancer (ELB) is an AWS service that automatically distributes incoming traffic across multiple targets, such as EC2 instances, containers, IP addresses, or Lambda functions.

It helps improve:

• High Availability
• Scalability
• Fault Tolerance
• Application Performance

Instead of users accessing EC2 instances directly, they access the Load Balancer, which forwards requests to healthy targets.

Key Features

• Automatic traffic distribution
• Health Checks
• SSL/TLS Termination
• High Availability across multiple Availability Zones
• Sticky Sessions (optional)
• Integration with Auto Scaling
• Supports HTTP, HTTPS, TCP, UDP, and gRPC (depending on the load balancer type)

Interview Example

A Spring Boot application is deployed on 4 EC2 instances.

Instead of exposing all four servers:

• Users send requests to the Application Load Balancer (ALB).
• ALB distributes traffic evenly across healthy instances.
• If one server fails, traffic is automatically routed to the remaining healthy servers.

Interview Tip: Think of ELB as a traffic manager that distributes requests to healthy application servers.

AWS provides three major types of Load Balancers.

Load Balancer	Layer	Best For
Application Load Balancer (ALB)	Layer 7 (HTTP/HTTPS)	Web applications, REST APIs, Microservices
Network Load Balancer (NLB)	Layer 4 (TCP/UDP)	High-performance, low-latency applications
Classic Load Balancer (CLB)	Layer 4 & 7 (Legacy)	Older AWS applications (legacy only)

1. Application Load Balancer (ALB)

• HTTP/HTTPS
• URL-based routing
• Host-based routing
• Path-based routing
• WebSocket support
• gRPC support
• Microservices

2. Network Load Balancer (NLB)

• TCP/UDP/TLS
• Extremely low latency
• Handles millions of requests
• Static IP support
• High throughput

3. Classic Load Balancer (CLB)

Older generation AWS Load Balancer.

Mostly replaced by:

• ALB
• NLB

Interview Tip: For modern applications, AWS recommends using ALB or NLB instead of CLB.

Feature	ALB	NLB	CLB
OSI Layer	Layer 7	Layer 4	Layer 4 & 7
Protocols	HTTP, HTTPS, WebSocket, gRPC	TCP, UDP, TLS	HTTP, HTTPS, TCP
Routing	Path & Host-based	IP and Port based	Basic routing
Static IP	No	Yes	No
Performance	High	Very High	Moderate
Microservices Support	Excellent	Limited	Poor
Recommended	Yes	Yes	Legacy only

Interview Explanation

ALB

• Intelligent routing.
• Ideal for Spring Boot REST APIs.
• Supports /orders → Order Service.
• Supports /payments → Payment Service.

NLB

• Extremely fast.
• Used for gaming, financial systems, messaging.

CLB

• Legacy.
• Existing applications only.

Interview Tip: For microservices and REST APIs, always mention Application Load Balancer (ALB).

A Target Group is a collection of backend resources that receive traffic from a Load Balancer.

Targets can be:

• EC2 instances
• IP addresses
• ECS tasks
• Lambda functions (ALB only)

The Load Balancer forwards requests only to healthy targets in the Target Group.

Flow

Users
   │
   ▼
Application Load Balancer
   │
   ▼
Target Group
   │
 ┌─┴─────────────┐
 ▼               ▼
EC2-1         EC2-2

Interview Example

A Spring Boot application has:

• ALB
• Target Group containing four EC2 instances

The ALB distributes requests only to the healthy instances in the Target Group.

Interview Tip: Think of a Target Group as the backend server pool behind a Load Balancer.

Health Checks are periodic requests sent by the Load Balancer to determine whether backend targets are healthy.

If a target fails the health check, the Load Balancer stops sending traffic to it until it becomes healthy again.

Common Health Check

GET /actuator/health

Expected Response:

HTTP 200 OK

Health Check Parameters

• Protocol
• Port
• Path
• Success HTTP Status Code
• Interval
• Timeout
• Healthy Threshold
• Unhealthy Threshold

Interview Example

A Spring Boot application exposes:

/actuator/health

The ALB checks this endpoint every 30 seconds.

If the endpoint returns:

• 200 OK → Healthy
• 500 Error → Unhealthy

Traffic is automatically stopped to that instance until it recovers.

Interview Tip: In production, Spring Boot applications commonly use Spring Boot Actuator (/actuator/health) for Load Balancer health checks.

A Load Balancer improves High Availability by distributing traffic across multiple healthy instances running in different Availability Zones.

How It Works

• Evenly distributes traffic.
• Detects unhealthy instances using Health Checks.
• Stops routing traffic to failed instances.
• Works with Auto Scaling to include newly launched instances automatically.
• Supports Multi-AZ deployments.

Interview Example

Production Architecture:

                Users
                   │
                   ▼
        Application Load Balancer
           /                 \\
          ▼                   ▼
      AZ-1 EC2           AZ-2 EC2
          │                   │
          └──────► RDS Multi-AZ

If:

• AZ-1 fails
• EC2 crashes

The ALB automatically routes all traffic to healthy instances in AZ-2.

Users experience little or no downtime.

Interview Tip: When answering High Availability questions, mention these services together:

• Application Load Balancer
• Health Checks
• Multi-AZ Deployment
• Auto Scaling Group
• RDS Multi-AZ

This demonstrates a production-ready architecture.

#

AWS Auto Scaling is a service that automatically adjusts the number of EC2 instances based on application demand.

It helps ensure:

• High Availability
• Better Performance
• Cost Optimization

Instead of manually launching or terminating servers, Auto Scaling performs these actions automatically based on defined policies.

Benefits

• Automatically handles traffic spikes
• Reduces infrastructure costs
• Improves fault tolerance
• Maintains desired application capacity
• Integrates with CloudWatch and ELB

Interview Example

A Spring Boot application usually runs on 2 EC2 instances.

During peak traffic:

• CPU reaches 70%
• Auto Scaling launches 2 additional instances.

When traffic decreases:

• Extra instances are terminated automatically.

An Auto Scaling Group (ASG) is a logical group of EC2 instances managed together.

It ensures that the desired number of healthy instances is always running.

ASG Configuration

• Launch Template or Launch Configuration
• Minimum Capacity
• Desired Capacity
• Maximum Capacity
• Scaling Policies
• Health Checks

Example

Minimum = 2
Desired = 2
Maximum = 8

If one EC2 instance crashes, the ASG automatically launches a replacement to maintain the desired capacity.

Interview Tip: An Auto Scaling Group not only scales instances but also replaces unhealthy instances automatically, even if there is no increase in traffic.

Auto Scaling continuously monitors application metrics using Amazon CloudWatch.

When a configured threshold is reached:

• Scale Out → Launch new EC2 instances.
• Scale In → Terminate unnecessary EC2 instances.

Flow

Users
   │
   ▼
Application Load Balancer
   │
CloudWatch monitors metrics
   │
   ▼
Auto Scaling Group
   │
 ┌───────────────┐
 ▼               ▼
Launch EC2    Terminate EC2

Steps

• CloudWatch monitors metrics.
• Scaling policy evaluates thresholds.
• ASG launches or terminates instances.
• New instances register automatically with the Load Balancer.
• Health Checks ensure only healthy instances receive traffic.

Interview Example

CPU exceeds 70% for 5 minutes:

• CloudWatch alarm triggers.
• ASG launches two additional EC2 instances.
• ALB begins routing traffic to the new healthy instances.

Scaling Out (Horizontal Scaling)	Scaling Up (Vertical Scaling)
Add more EC2 instances	Increase CPU/RAM of an existing instance
Improves scalability and availability	Increases capacity of a single server
Preferred for production	Useful for smaller workloads or legacy applications
Uses Auto Scaling	Requires changing the instance type
Works well with Load Balancers	May require stopping/restarting the instance

Interview Example

Scaling Up

• t3.medium → t3.large

Scaling Out

• 2 EC2 instances → 6 EC2 instances behind an ALB

Interview Tip: For cloud-native and microservice architectures, horizontal scaling is generally preferred because it improves both scalability and fault tolerance.

Auto Scaling is typically triggered using Amazon CloudWatch metrics.

Common Metrics

• CPU Utilization
• Network In
• Network Out
• Request Count (via ALB)
• Target Response Time (via ALB)
• Custom CloudWatch Metrics (e.g., memory utilization, queue length)
• SQS Queue Length (for worker applications)

Example Scaling Policy

Condition	Action
CPU > 70% for 5 minutes	Add 2 EC2 instances
CPU < 30% for 10 minutes	Remove 1 EC2 instance

Interview Example

An e-commerce application experiences a traffic spike during a flash sale:

• CPU utilization increases above 70%.
• CloudWatch triggers the Auto Scaling Group.
• New EC2 instances are launched.
• The Application Load Balancer automatically starts routing traffic to the new instances.
• After the sale ends and CPU drops below 30%, Auto Scaling removes the extra instances to reduce costs.

Interview Tip: For production systems, it’s common to mention a combination of:

• CPU Utilization
• ALB Request Count per Target
• Custom Memory Metrics
• SQS Queue Length (for asynchronous processing)

This demonstrates practical, real-world experience with AWS Auto Scaling.

Amazon RDS (Relational Database Service) is a fully managed relational database service provided by AWS.

It allows you to run relational databases without managing infrastructure such as server provisioning, operating system updates, database installation, backups, patching, or failover.

AWS manages the database infrastructure, while developers focus on application development.

Key Features

• Fully managed database service
• Automated backups
• Automatic patching
• Multi-AZ High Availability
• Read Replicas
• Storage auto scaling
• Monitoring through CloudWatch
• Encryption at rest and in transit

Common Use Cases

• Spring Boot applications
• E-commerce applications
• Banking systems
• ERP applications
• Enterprise web applications

Interview Example

A Spring Boot microservice stores customer and order data in Amazon RDS MySQL. AWS automatically performs backups, patches the database, and handles failover using Multi-AZ.

Interview Tip: Think of RDS as a managed database, where AWS handles infrastructure and database administration tasks.

Amazon RDS supports multiple relational database engines.

Database	Open Source / Commercial
MySQL	Open Source
PostgreSQL	Open Source
MariaDB	Open Source
Oracle Database	Commercial
Microsoft SQL Server	Commercial

Note: Amazon Aurora is AWS’s cloud-native relational database compatible with MySQL and PostgreSQL. Although it is part of the RDS family, it is often discussed separately due to its architecture and performance.

Interview Tip: For most Spring Boot applications, MySQL and PostgreSQL are the most commonly used RDS engines.

Amazon RDS	Database on EC2
Fully managed	Self-managed
Automatic backups	Manual backups
Automatic patching	Manual patching
Built-in Multi-AZ	Must configure manually
Easy scaling	Manual scaling
Monitoring integrated	Must configure manually
Higher operational simplicity	More administrative effort

Interview Explanation

With a database on EC2, you are responsible for:

• Installing the database
• OS updates
• Database upgrades
• Backups
• Replication
• Failover
• Monitoring

With RDS, AWS manages these operational tasks.

Interview Tip: Use RDS unless you require complete OS-level control or features not supported by RDS.

Multi-AZ is a High Availability feature in RDS.

AWS creates:

• One Primary Database
• One Standby Database in another Availability Zone

Data is synchronously replicated from the primary to the standby.

If the primary database fails, AWS automatically promotes the standby database.

Architecture

Application
      │
      ▼
Primary Database (AZ-1)
      │
Synchronous Replication
      ▼
Standby Database (AZ-2)

Benefits

• Automatic failover
• High Availability
• No manual intervention
• Improved reliability

Interview Example

If the primary MySQL database becomes unavailable due to an AZ failure, RDS automatically switches the application to the standby instance with minimal downtime.

Interview Tip: Multi-AZ is designed for High Availability, not for improving read performance.

A Read Replica is a read-only copy of the primary database used to handle read-heavy workloads.

Replication is asynchronous, so there may be a slight delay between the primary and replica.

Benefits

• Offload read traffic
• Improve application performance
• Scale read operations
• Reporting and analytics

Architecture

Primary Database
      │
Asynchronous Replication
      ▼
Read Replica

Interview Example

An e-commerce application:

• Writes customer orders to the primary database.
• Product searches and reports are served from Read Replicas.

This reduces load on the primary database.

Interview Tip: Read Replicas are used for scaling reads, not for automatic failover.

Multi-AZ	Read Replica
High Availability	Read Scalability
Synchronous replication	Asynchronous replication
Standby database	Read-only database
Automatic failover	No automatic failover
Not accessible for reads	Can serve read queries
Improves reliability	Improves performance

Interview Explanation

Multi-AZ

• Protects against database failures.
• Provides automatic failover.

Read Replica

• Improves read performance.
• Handles reporting and analytics.

Interview Tip: A common interview question:

Which one improves performance?

Read Replica.

Which one improves availability?

Multi-AZ.

RDS provides automatic and manual backups.

1. Automated Backups

AWS automatically performs:

• Daily full backups
• Transaction log backups

This enables Point-in-Time Recovery (PITR) within the configured retention period.

Retention:

• 1–35 days

2. Manual Snapshots

• Created manually.
• Retained until explicitly deleted.
• Used before upgrades or major changes.

Interview Example

Before upgrading a production MySQL database:

• Take a manual snapshot.
• Perform the upgrade.
• If something goes wrong, restore the database from the snapshot.

Interview Tip: Mention both:

• Automated Backups → Point-in-Time Recovery
• Manual Snapshots → Long-term backup

#

Amazon CloudWatch is AWS’s monitoring and observability service used to collect and monitor metrics, logs, events, and alarms for AWS resources and applications.

It helps detect issues, monitor performance, trigger automated actions, and improve system reliability.

Key Features

• Metrics
• Logs
• Alarms
• Dashboards
• Events (EventBridge integration)
• Auto Scaling integration

Common Use Cases

• Monitor EC2 CPU utilization
• Monitor RDS performance
• Store application logs
• Trigger Auto Scaling
• Send SNS notifications

Interview Example

A Spring Boot application sends logs to CloudWatch Logs, while CPU utilization and request metrics are monitored through CloudWatch Metrics. If CPU exceeds 70%, CloudWatch triggers Auto Scaling.

CloudWatch Metrics	CloudWatch Logs
Numeric performance data	Log files and application output
CPU, Memory*, Network	Spring Boot logs, Apache logs, System logs
Used for graphs and alarms	Used for troubleshooting and analysis
Time-series data	Text-based data

*Memory utilization requires the CloudWatch Agent because it is not collected by default for EC2.*

Interview Example

Metrics

• CPU Utilization
• Disk Read Operations
• Network Traffic

Logs

• Application exceptions
• Spring Boot logs
• Access logs
• Error logs

Interview Tip: Metrics answer “How is the system performing?”

Logs answer “Why did something happen?”

CloudWatch Alarms monitor CloudWatch Metrics and perform actions when specified thresholds are crossed.

Possible Actions

• Send SNS notifications
• Trigger Auto Scaling
• Invoke Lambda
• Recover an EC2 instance (supported scenarios)

Example

CPU > 70% for 5 minutes
        │
        ▼
CloudWatch Alarm
        │
        ▼
Launch New EC2 Instances

Interview Example

If CPU utilization remains above 70% for five minutes:

• CloudWatch Alarm is triggered.
• Auto Scaling launches additional EC2 instances.
• An SNS notification is sent to the DevOps team.

EC2 instances can be monitored using Amazon CloudWatch.

Default Metrics

• CPU Utilization
• Network In
• Network Out
• Disk Read/Write Operations
• Status Checks

Additional Monitoring

Install the CloudWatch Agent to collect:

• Memory utilization
• Disk usage
• Application logs
• Custom metrics

Interview Example

For a production Spring Boot application:

• CPU Utilization
• Memory Utilization
• Disk Usage
• JVM Logs
• Application Logs
• Request Count

are monitored using CloudWatch and the CloudWatch Agent.

Interview Tip: Mention the CloudWatch Agent when discussing memory monitoring, as EC2 does not publish memory metrics by default.

Yes.

CloudWatch continuously monitors metrics such as CPU utilization, request count, or custom metrics.

When a threshold is reached:

• CloudWatch Alarm is triggered.
• Auto Scaling Group launches or terminates EC2 instances based on the configured scaling policy.

Flow

CloudWatch Metrics
        │
        ▼
CloudWatch Alarm
        │
        ▼
Auto Scaling Group
        │
        ▼
Launch / Terminate EC2

Interview Example

During a flash sale:

• CPU exceeds 70%.
• CloudWatch Alarm triggers.
• Auto Scaling launches three new EC2 instances.
• The Application Load Balancer starts routing traffic to the new instances.

Interview Tip: CloudWatch is commonly integrated with:

• Auto Scaling
• SNS
• Lambda
• EventBridge

#

Amazon Route 53 is AWS’s highly available and scalable Domain Name System (DNS) service.

It translates human-readable domain names into IP addresses and routes users to the appropriate AWS resources.

Key Features

• Domain registration
• DNS management
• Health checks
• Traffic routing
• Failover routing
• Integration with AWS services

Common Use Cases

• Route traffic to ALB
• Route traffic to EC2
• Static website hosting
• Disaster recovery
• Global traffic management

Interview Example

When a user opens:

www.mycompany.com

Route 53 resolves the domain and directs traffic to the Application Load Balancer, which then forwards requests to healthy EC2 instances.

DNS (Domain Name System) is the internet’s naming service that translates domain names into IP addresses.

Without DNS, users would need to remember numeric IP addresses instead of easy-to-read domain names.

Example

www.amazon.com
        │
        ▼
54.x.x.x

Interview Tip: Think of DNS as the phonebook of the internet, mapping names to IP addresses.

A Hosted Zone is a container in Route 53 that stores DNS records for a domain.

It tells Route 53 how to route traffic for that domain.

Types

• Public Hosted Zone – Accessible from the internet.
• Private Hosted Zone – Accessible only within one or more VPCs.

Common DNS Records

• A Record
• AAAA Record
• CNAME
• MX
• TXT
• Alias Record

Interview Example

For example.com, a Hosted Zone may contain:

• www.example.com → ALB
• api.example.com → API Load Balancer
• mail.example.com → Mail Server

Route 53 provides multiple routing policies for different traffic management needs.

Routing Policy	Purpose
Simple	Single resource
Weighted	Distribute traffic based on percentages
Latency	Route to the lowest-latency Region
Failover	Disaster recovery
Geolocation	Route based on user location
Geoproximity*	Route based on geographic proximity
Multi-Value Answer	Return multiple healthy IP addresses

*Geoproximity requires Route 53 Traffic Flow.

Interview Example

• Weighted → 90% traffic to Version A, 10% to Version B during a canary deployment.
• Latency → Users in India are routed to Mumbai, while users in Europe are routed to Frankfurt.
• Failover → Switch traffic to a secondary Region if the primary endpoint becomes unhealthy.

Interview Tip: Frequently asked routing policies:

• Simple
• Weighted
• Latency
• Failover
• Geolocation

Alias Record	CNAME
AWS-specific	Standard DNS record
Can point to AWS resources (ALB, CloudFront, S3, etc.)	Points one domain name to another domain name
Can be used for the root domain (e.g., example.com)	Cannot be used for the root domain
No additional DNS query cost in Route 53	Standard DNS behavior applies

Interview Explanation

Alias Record

• Used for AWS resources.
• Supports zone apex (root domain).
• Automatically tracks changes to AWS resource IP addresses.

CNAME

• Maps one hostname to another hostname.
• Commonly used for subdomains such as api.example.com.

Interview Example

• example.com → Alias Record → Application Load Balancer
• api.example.com → CNAME → my-api.example.net

Interview Tip: For AWS resources like Application Load Balancer, CloudFront, or S3 static website endpoints, prefer Alias Records over CNAME because they support the root domain and integrate seamlessly with AWS infrastructure.

AWS Lambda is a serverless compute service that allows you to run code without provisioning or managing servers.

You upload your code, and Lambda automatically executes it in response to events. AWS manages the underlying infrastructure, scaling, patching, and availability.

You are charged only for:

–

Number of requests

–

Execution duration

–

Memory allocated

Supported Event Sources

–

Amazon S3

–

API Gateway

–

EventBridge

–

SNS

–

SQS

–

DynamoDB Streams

–

CloudWatch Events

Interview Example

When a user uploads an image to S3:

–

S3 triggers a Lambda function.

–

Lambda resizes the image.

–

The resized image is stored in another S3 bucket.

No server needs to be managed.

Interview Tip

Think of Lambda as “Run code only when an event occurs.”

Serverless Computing is a cloud computing model where developers write and deploy code without managing servers.

Although servers still exist, AWS manages:

–

Server provisioning

–

Scaling

–

Patching

–

Operating system maintenance

–

High Availability

Developers focus only on business logic.

Characteristics

–

No server management

–

Automatic scaling

–

Pay per execution

–

Event-driven architecture

–

High Availability

Interview Example

Instead of running a Spring Boot application on EC2 just to process image uploads, a Lambda function processes images only when they are uploaded to S3.

Interview Tip

Serverless does not mean “no servers.” It means you don’t manage the servers—AWS does.

1. No Server Management

AWS manages:

–

Servers

–

Operating System

–

Patching

–

Capacity

2. Automatic Scaling

Lambda automatically scales from a few requests to thousands of concurrent executions.

3. Pay Per Use

You pay only when your function executes.

No charges when the function is idle.

4. High Availability

Lambda runs across multiple Availability Zones.

5. Event Driven

Can be triggered by:

–

API Gateway

–

S3

–

SNS

–

SQS

–

EventBridge

–

DynamoDB Streams

6. Easy Integration

Integrates easily with most AWS services.

Interview Example

A payment confirmation email is sent using Lambda after an order is placed.

Flow:

Order Created

│

▼

SNS Topic

│

▼

Lambda

│

▼

Send Email

Interview Tip

Lambda is ideal for event-driven, short-running tasks.

Lambda execution has three main phases.

1. Initialization (Init Phase)

–

AWS creates the execution environment.

–

Loads runtime.

–

Initializes variables.

–

Loads application dependencies.

This phase is more noticeable during a Cold Start.

2. Invocation

The Lambda function executes the business logic.

Example:

–

Process API request

–

Resize image

–

Read from S3

3. Execution Environment Reuse

After execution:

–

AWS may keep the execution environment warm.

–

Future requests can reuse it.

–

This reduces startup time (Warm Start).

Lifecycle

Request

│

▼

Initialization (Cold Start)

│

▼

Execute Function

│

▼

Return Response

│

▼

Reuse Environment (Warm Start)

Interview Tip

Frequently asked terms:

–

Cold Start → New execution environment is created.

–

Warm Start → Existing execution environment is reused.

Some important limitations are:

Execution Timeout

–

Maximum execution time is 15 minutes.

Stateless

–

Lambda should not store application state in memory between invocations.

–

Use S3, DynamoDB, ElastiCache, or RDS for persistent data.

Cold Starts

The first invocation (or after a period of inactivity) may have higher latency because AWS needs to initialize the execution environment.

Resource Limits

–

Memory and CPU are configurable within AWS limits.

–

Temporary storage (/tmp) is limited (configurable up to AWS-supported limits).

Long-running Applications

Not suitable for:

–

Continuous background services

–

Web servers

–

Applications requiring persistent connections

Interview Tip

Lambda is not a replacement for every application. It is best suited for short-lived, event-driven workloads.

Choose Lambda when the application is event-driven, short-running, and requires automatic scaling without server management.

Choose EC2 when you need full server control, long-running processes, or custom operating system configurations.

Comparison

AWS LambdaAmazon EC2ServerlessVirtual ServerNo server managementFull server controlAutomatic scalingConfigure Auto Scaling manuallyPay per executionPay while the instance is runningMaximum execution time of 15 minutesNo execution time limitBest for event-driven tasksBest for long-running applications

Interview Example

Use Lambda

–

Image processing

–

File upload processing

–

Email notifications

–

Scheduled jobs

–

REST APIs using API Gateway

–

Log processing

Use EC2

–

Spring Boot applications

–

Microservices

–

Game servers

–

Continuous background services

–

Large enterprise applications

Interview Tip

A common interview question:

Can Spring Boot run on Lambda?

Yes, it can using technologies such as AWS Lambda with Spring Cloud Function, but for large, continuously running Spring Boot applications, EC2, ECS, or EKS is generally a better fit due to startup time and resource considerations.

##

Infrastructure as Code (IaC) is the practice of defining and managing infrastructure using code instead of manual configuration.

Instead of creating AWS resources through the console, infrastructure is described in configuration files.

This makes infrastructure:

–

Repeatable

–

Version controlled

–

Automated

–

Consistent across environments

Benefits

–

Automation

–

Consistency

–

Faster deployments

–

Reduced human errors

–

Easy rollback

–

Version control using Git

Interview Example

Instead of manually creating:

–

VPC

–

EC2

–

Security Groups

–

RDS

–

Load Balancer

A CloudFormation template creates the complete infrastructure automatically.

Interview Tip

Popular IaC tools include:

–

AWS CloudFormation

–

Terraform

–

AWS CDK

AWS CloudFormation is an Infrastructure as Code (IaC) service that allows you to provision and manage AWS resources using YAML or JSON templates.

CloudFormation creates, updates, and deletes resources as a single unit called a Stack.

Features

–

Infrastructure automation

–

Repeatable deployments

–

Dependency management

–

Automatic rollback on failures

–

Version-controlled templates

–

Native AWS service integration

Interview Example

A CloudFormation template can create:

–

VPC

–

Public and Private Subnets

–

Internet Gateway

–

NAT Gateway

–

Security Groups

–

Application Load Balancer

–

Auto Scaling Group

–

RDS Database

with a single deployment.

Interview Tip

CloudFormation is AWS’s native IaC service and is commonly used to automate infrastructure deployments.

A CloudFormation Template is a YAML or JSON file that defines the AWS infrastructure to be created.

It describes:

–

AWS resources

–

Configurations

–

Dependencies

–

Parameters

–

Outputs

When the template is executed, CloudFormation provisions all the specified resources.

Example Resources

–

EC2 Instance

–

VPC

–

Security Group

–

S3 Bucket

–

RDS

–

IAM Role

Interview Example

A single YAML template can create an entire production environment including networking, compute, storage, and security resources, ensuring consistent deployments across development, testing, and production.

Interview Tip

Remember:

–

Template → Blueprint describing infrastructure.

–

Stack → Running instance created from that template.

CloudFormation simplifies AWS infrastructure management by automating resource provisioning and ensuring consistent deployments.

Key Benefits

1. Infrastructure Automation

Entire AWS environments can be created with a single template.

2. Repeatable Deployments

The same infrastructure can be deployed consistently across:

–

Development

–

Testing

–

Staging

–

Production

3. Version Control

Templates can be stored in Git, making infrastructure changes traceable and reviewable.

4. Automatic Rollback

If resource creation fails, CloudFormation automatically rolls back changes to avoid partially configured environments.

5. Dependency Management

CloudFormation creates resources in the correct order based on their dependencies.

6. Reduced Human Errors

Infrastructure is deployed from code rather than manual console operations, improving consistency and reliability.

Interview Example

A DevOps team stores CloudFormation templates in GitHub. During each CI/CD deployment, CloudFormation provisions or updates the required infrastructure, ensuring every environment is created in a standardized way.

Interview Tip

For production deployments, mention these advantages together:

–

Infrastructure as Code

–

Automation

–

Repeatable deployments

–

Version control

–

Automatic rollback

–

Reduced manual errors

These are the key benefits interviewers typically expect when discussing CloudFormation.

<button type=”button” class=”text-token-text-secondary hover:bg-token-surface-hover rounded-lg” aria-label=”Copy response”

AWS Elastic Beanstalk is a Platform as a Service (PaaS) that allows developers to deploy and manage applications without worrying about the underlying infrastructure.

You simply upload your application code, and Elastic Beanstalk automatically provisions and manages:

–

EC2 instances

–

Load Balancer

–

Auto Scaling Group

–

Security Groups

–

CloudWatch Monitoring

–

Application deployment

AWS manages the infrastructure while you focus on writing application code.

Supported Platforms

–

Java

–

Spring Boot

–

Node.js

–

Python

–

.NET

–

PHP

–

Ruby

–

Go

–

Docker

Interview Example

A Spring Boot application is packaged as a JAR file.

You upload the JAR to Elastic Beanstalk, and AWS automatically:

–

Creates EC2 instances

–

Configures the Load Balancer

–

Creates an Auto Scaling Group

–

Deploys the application

–

Monitors application health

Interview Tip

Elastic Beanstalk is ideal for developers who want to deploy applications quickly without manually managing AWS infrastructure.

EC2Elastic BeanstalkInfrastructure as a Service (IaaS)Platform as a Service (PaaS)You manage infrastructureAWS manages infrastructureManual deploymentAutomated deploymentManual Auto ScalingAuto Scaling configured automaticallyManual Load Balancer setupLoad Balancer configured automaticallyFull server controlLimited infrastructure controlBest for customized environmentsBest for rapid application deployment

Interview Explanation

EC2

–

Full control over the operating system.

–

Responsible for deployment, patching, scaling, monitoring, and networking.

Elastic Beanstalk

–

Upload application code.

–

AWS handles provisioning, deployment, scaling, monitoring, and health management.

Interview Tip

Choose:

–

EC2 → When full infrastructure control is required.

–

Elastic Beanstalk → When you want faster deployment with minimal infrastructure management.

Elastic Beanstalk is suitable when you want to deploy applications quickly while reducing operational overhead.

Common Use Cases

–

Spring Boot applications

–

REST APIs

–

Internal enterprise applications

–

Development and testing environments

–

Small to medium production workloads

–

Teams without dedicated DevOps engineers

Interview Example

A startup wants to deploy a Spring Boot application quickly without managing EC2, Load Balancers, or Auto Scaling manually.

Elastic Beanstalk provides an easy deployment platform while still allowing customization if needed.

Interview Tip

For large-scale microservices and containerized applications, organizations often prefer ECS, EKS, or Kubernetes, while Elastic Beanstalk is a great choice for simpler application deployments.

##

Amazon ECS (Elastic Container Service) is AWS’s fully managed container orchestration service used to deploy, run, and scale Docker containers.

ECS manages:

–

Container scheduling

–

Scaling

–

Networking

–

Health monitoring

–

Service discovery

Containers can run on:

–

EC2 instances

–

AWS Fargate

Key Components

–

Cluster

–

Task Definition

–

Task

–

Service

Interview Example

A Spring Boot microservices application consists of:

–

User Service

–

Order Service

–

Payment Service

Each service runs as a Docker container managed by ECS.

Interview Tip

ECS is AWS-native and is generally simpler to operate than Kubernetes.

Amazon EKS (Elastic Kubernetes Service) is a managed Kubernetes service provided by AWS.

AWS manages the Kubernetes control plane, while you deploy and manage containerized applications using standard Kubernetes APIs and tools.

Benefits

–

Managed Kubernetes control plane

–

High Availability

–

Automatic upgrades (control plane)

–

Kubernetes ecosystem compatibility

–

Integration with AWS services

Interview Example

An enterprise already uses Kubernetes across multiple cloud providers. By using EKS, they can run Kubernetes workloads on AWS while maintaining the same Kubernetes manifests and tooling.

Interview Tip

Choose EKS if your organization already uses Kubernetes or requires Kubernetes portability and its extensive ecosystem.

Amazon ECSAmazon EKSAWS-native container orchestrationManaged KubernetesEasier to learn and operateMore complexNo Kubernetes knowledge requiredRequires Kubernetes knowledgeUses ECS APIsUses Kubernetes APIsBest for AWS-focused deploymentsBest for Kubernetes and multi-cloud strategies

Interview Explanation

ECS

–

Simpler.

–

AWS-specific.

–

Faster to set up.

–

Good for teams working only in AWS.

EKS

–

Uses Kubernetes.

–

Cloud portable.

–

Rich Kubernetes ecosystem.

–

Suitable for large enterprise environments.

Interview Tip

A common interview question:

Which would you choose for a Spring Boot microservices application?

A good answer:

“If the application is deployed only on AWS and simplicity is the priority, I would choose ECS. If the organization already uses Kubernetes or requires portability across environments, I would choose EKS.”

AWS Fargate is a serverless compute engine for containers used with ECS and EKS.

With Fargate:

–

No EC2 instances to manage.

–

No server provisioning.

–

No operating system maintenance.

–

Pay only for the CPU and memory allocated to running containers.

AWS manages the underlying infrastructure.

Benefits

–

No server management

–

Automatic scaling

–

Improved security isolation

–

Simplified operations

–

Pay per usage

Interview Example

A Spring Boot microservice is packaged as a Docker container and deployed to ECS using the Fargate launch type. AWS automatically provisions the required compute resources without requiring EC2 instances.

Interview Tip

Think of Fargate as “AWS Lambda for containers.”

EC2 Launch TypeFargateYou manage EC2 instancesAWS manages compute infrastructureResponsible for OS patchingNo OS managementMore infrastructure controlSimpler operationsCan optimize costs for steady workloadsPay only for container resources usedSuitable for customized environmentsIdeal for serverless container deployments

Interview Explanation

EC2 Launch Type

–

You provision and manage EC2 instances.

–

Greater flexibility and control.

Fargate

–

No infrastructure management.

–

Focus only on containers and application code.

Interview Tip

Choose:

–

EC2 Launch Type → When you need more control or have predictable long-running workloads.

–

Fargate → When you want minimal operational overhead and serverless container execution.

##

Securing an AWS account involves following AWS security best practices.

Best Practices

1. Protect the Root User

–

Enable Multi-Factor Authentication (MFA).

–

Avoid using the root account for daily tasks.

2. Use IAM Users and Roles

–

Create IAM Users for individuals.

–

Use IAM Roles for AWS services.

–

Avoid sharing credentials.

3. Follow the Principle of Least Privilege

Grant only the permissions required for a specific task.

4. Enable MFA

Require MFA for privileged users and administrators.

5. Rotate Credentials

–

Rotate passwords regularly.

–

Rotate Access Keys if they are used.

6. Enable Logging and Monitoring

–

AWS CloudTrail

–

CloudWatch

–

AWS Config

7. Encrypt Sensitive Data

–

S3

–

EBS

–

RDS

using AWS KMS-managed encryption.

8. Secure the Network

–

Security Groups

–

Network ACLs

–

Private Subnets

–

VPC

Interview Tip

A strong interview answer should mention:

–

IAM

–

MFA

–

Least Privilege

–

Encryption

–

CloudTrail

–

CloudWatch

–

Avoiding root account usage

MFA (Multi-Factor Authentication) adds an additional layer of security by requiring two or more authentication factors.

Typical factors include:

–

Password

–

OTP from an authenticator app or hardware token

Even if a password is compromised, an attacker cannot log in without the second factor.

Benefits

–

Stronger authentication

–

Reduced risk of unauthorized access

–

Protects privileged accounts

Interview Example

An AWS administrator logs in using:

–

Username and password

–

OTP generated by an authenticator application

Both are required to access the AWS Console.

Interview Tip

AWS strongly recommends enabling MFA on the root account and all privileged IAM users.

Amazon S3 supports encryption for data at rest and in transit.

Encryption at Rest

–

SSE-S3 – AWS-managed encryption keys.

–

SSE-KMS – Encryption using AWS Key Management Service (KMS).

–

SSE-C – Customer-provided encryption keys.

Encryption in Transit

Use HTTPS (TLS) when transferring data to and from S3.

Interview Example

A healthcare application stores medical reports in S3 using SSE-KMS encryption and enforces HTTPS-only access through bucket policies.

Interview Tip

For production environments handling sensitive data, SSE-KMS is commonly preferred because it provides centralized key management, auditing, and fine-grained access control.

AWS KMS (Key Management Service) is a managed encryption key service used to create, manage, and control cryptographic keys.

KMS integrates with services such as:

–

S3

–

EBS

–

RDS

–

Lambda

–

Secrets Manager

Benefits

–

Centralized key management

–

Automatic key rotation (configurable)

–

Access control using IAM

–

CloudTrail auditing

–

Secure key storage

Interview Example

A company encrypts all RDS databases and S3 buckets using customer-managed KMS keys to meet compliance requirements and audit key usage.

Interview Tip

KMS manages encryption keys; it does not store application secrets like passwords.

AWS KMSAWS Secrets ManagerManages encryption keysStores and manages secretsUsed for encrypting dataUsed for passwords, API keys, tokens, certificatesIntegrates with many AWS servicesSupports automatic secret rotationFocuses on key managementFocuses on secret lifecycle management

Interview Explanation

KMS

–

Encrypts and decrypts data.

–

Manages cryptographic keys.

Secrets Manager

–

Securely stores secrets.

–

Automatically rotates supported credentials.

–

Retrieves secrets securely at runtime.

Interview Example

A Spring Boot application:

–

Stores the database password in AWS Secrets Manager.

–

Uses KMS to encrypt the secret stored by Secrets Manager.

Interview Tip

Remember:

–

KMS → Encryption Keys

–

Secrets Manager → Passwords, API Keys, Tokens

They are often used together, not as replacements for one another.

The recommended approach is to store database credentials in AWS Secrets Manager instead of hardcoding them in source code or configuration files.

Recommended Approach

–

Store the database username and password in AWS Secrets Manager.

–

Encrypt the secret using AWS KMS.

–

Grant the application an IAM Role with permission to read the secret.

–

Retrieve the secret securely at runtime using the AWS SDK.

Architecture

Spring Boot Application

│

▼

IAM Role

│

▼

AWS Secrets Manager

│

(KMS Encrypts Secret)

│

▼

Database Password

Interview Example

Instead of placing the database password in application.properties, a Spring Boot application running on EC2 retrieves the credentials from Secrets Manager using its IAM Role. This eliminates hardcoded credentials, supports password rotation, and improves security.

Interview Tip

For a production-grade answer, mention all three services together:

–

AWS Secrets Manager → Stores the database password.

–

AWS KMS → Encrypts the secret.

–

IAM Role → Grants secure, temporary access to the application.

This demonstrates knowledge of AWS security best practices used in real-world deployments.

<button type=”button” class=”text-token-text-secondary hover:bg-token-surface-hover rounded-lg” aria-label=”Copy response”

There are multiple ways to deploy a Spring Boot application on AWS. The most common production approach is using EC2 + Application Load Balancer + Auto Scaling + RDS.

Deployment Steps

–

Build the application using Maven or Gradle.

–

Package it as a JAR file.

–

Launch EC2 instances.

–

Install Java.

–

Copy the JAR to EC2 (SCP/S3/CI-CD).

–

Configure environment variables.

–

Start the application.

–

Configure Security Groups.

–

Place EC2 instances behind an Application Load Balancer.

–

Enable Auto Scaling and CloudWatch monitoring.

Production Architecture

Users

│

Route 53

│

Application Load Balancer

│

Auto Scaling Group

┌──────────────┐

▼ ▼

EC2 EC2

│ │

Spring Boot Spring Boot

│

▼

Amazon RDS

│

▼

Amazon S3

Interview Example

A production Spring Boot application:

–

Hosted on EC2

–

Behind an ALB

–

Auto Scaling enabled

–

MySQL on RDS Multi-AZ

–

Images stored in S3

–

Logs monitored using CloudWatch

Interview Tip

Mention:

–

EC2

–

ALB

–

Auto Scaling

–

RDS

–

S3

–

CloudWatch

–

IAM Role

This shows production-level AWS knowledge.

Environment variables are used to store configuration values outside the application code.

Examples:

–

Database URL

–

Database Username

–

Database Password

–

AWS Region

–

API Keys

Common Methods

EC2

Bashexport DB_URL=jdbc:mysql://…

export DB_USERNAME=admin

Spring Boot

propertiesspring.datasource.url=${DB_URL}

spring.datasource.username=${DB_USERNAME}

ECS / Fargate

Environment variables are configured in the Task Definition.

Lambda

Configured in the Lambda Console or Infrastructure as Code templates.

Production Best Practice

Sensitive values should not be stored directly as environment variables if avoidable.

Instead use:

–

AWS Secrets Manager

–

AWS Systems Manager Parameter Store

Interview Tip

Mention:

“For production, I store secrets in AWS Secrets Manager and inject them into the application securely using IAM Roles.”

A Spring Boot application uploads files to S3 using the AWS SDK.

Steps

–

Create an S3 Bucket.

–

Attach an IAM Role to EC2/ECS.

–

Grant:

–

s3:PutObject

–

s3:GetObject

–

Use the AWS SDK to upload files.

Flow

User

│

▼

Spring Boot

│

▼

AWS SDK

│

▼

Amazon S3

Interview Example

A user uploads a profile image.

–

Spring Boot receives the image.

–

Uploads it to S3.

–

Stores only the S3 object URL in the database.

This reduces database storage and improves scalability.

Interview Tip

Never store uploaded files inside EC2 because:

–

EC2 instances may be replaced by Auto Scaling.

–

Files would be lost unless stored on shared storage.

Store uploads in Amazon S3 instead.

HTTPS is typically configured using an Application Load Balancer (ALB) together with AWS Certificate Manager (ACM).

Steps

–

Request an SSL/TLS certificate in ACM.

–

Validate domain ownership.

–

Attach the certificate to the ALB HTTPS listener (port 443).

–

Redirect HTTP (port 80) to HTTPS.

–

Route traffic from Route 53 to the ALB.

Architecture

Users

│

HTTPS (443)

│

Application Load Balancer

│

Spring Boot EC2

Interview Example

A customer visits:

https://mycompany.com

–

ACM provides the SSL certificate.

–

ALB terminates SSL.

–

Traffic between ALB and EC2 can remain encrypted (HTTPS) or use HTTP within the VPC, depending on security requirements.

Interview Tip

AWS best practice:

–

Use AWS Certificate Manager (ACM).

–

Terminate SSL at the Application Load Balancer.

For production, microservices are commonly deployed using Docker containers orchestrated by Amazon ECS or Amazon EKS.

Typical Architecture

Users

│

Route53

│

Application Load Balancer

│

API Gateway (Optional)

│

┌─────────────┬──────────────┬──────────────┐

▼ ▼ ▼

User Service Order Service Payment Service

(ECS/EKS) (ECS/EKS) (ECS/EKS)

│

▼

Amazon RDS

│

▼

Amazon S3

Production Services

–

ECS/EKS

–

Docker

–

ALB

–

Auto Scaling

–

CloudWatch

–

IAM Roles

–

Secrets Manager

–

RDS

–

S3

–

ElastiCache (optional)

–

SQS/SNS (for asynchronous communication)

Interview Tip

For 4–6 years of experience, mentioning Docker + ECS (or EKS) + ALB + Auto Scaling + CloudWatch + RDS + Secrets Manager demonstrates production-ready deployment knowledge.

Scenario-Based Questions ⭐⭐⭐⭐⭐

I would use a production architecture consisting of:

–

Route 53

–

Application Load Balancer

–

Auto Scaling Group

–

EC2 instances running Spring Boot

–

Amazon RDS (Multi-AZ)

–

Amazon S3 for file storage

–

IAM Roles for AWS access

–

CloudWatch for monitoring

–

Secrets Manager for database credentials

–

ACM for HTTPS

Deployment Flow

Users

│

Route53

│

ALB

│

Auto Scaling

│

Spring Boot EC2

│

RDS + S3

This architecture provides scalability, high availability, and fault tolerance.

I would troubleshoot step by step:

–

Check EC2 instance status.

–

Verify Security Group rules (SSH/HTTP/HTTPS).

–

Check Network ACLs.

–

Verify Route Table and Internet Gateway.

–

Ensure the instance has a Public IP or Elastic IP (if expected).

–

Verify SSH key pair.

–

Check whether the instance is in a public subnet.

–

Review EC2 System Logs and Instance Status Checks.

–

Use AWS Systems Manager Session Manager (if configured).

–

Check application logs and CloudWatch Logs.

Interview Tip

Always troubleshoot from network → instance → operating system → application.

I would use Amazon S3 because it is:

–

Highly durable

–

Scalable

–

Cost-effective

–

Supports lifecycle policies

–

Integrates easily with CloudFront for content delivery

The application uploads images to S3 and stores only the object URL in the database.

Interview Tip

Never store uploaded images on EC2 in production because Auto Scaling or instance replacement can result in data loss.

For disaster recovery and global availability:

–

Deploy the application in multiple AWS Regions.

–

Use Route 53 Failover or Latency-based Routing.

–

Replicate S3 data using Cross-Region Replication.

–

Use database replication (depending on the database technology).

–

Enable backups and disaster recovery.

–

Deploy Load Balancers in each Region.

Interview Tip

Within one Region, use Multi-AZ. Across Regions, use multi-region deployment for disaster recovery and global resilience.

I would combine several AWS services:

–

Application Load Balancer

–

Auto Scaling Group

–

Multiple Availability Zones

–

Amazon RDS Read Replicas

–

ElastiCache (Redis)

–

Amazon CloudFront

–

Amazon S3

–

Asynchronous processing using SQS

–

CloudWatch monitoring

Interview Tip

Scaling is not only about adding EC2 instances. It also involves scaling the database, caching frequently accessed data, using a CDN, and decoupling workloads.

I would first identify the bottleneck using CloudWatch and Performance Insights, then apply the appropriate solution:

–

Enable Read Replicas for read-heavy workloads.

–

Enable Multi-AZ for high availability.

–

Increase the RDS instance size if CPU or memory is insufficient.

–

Use ElastiCache (Redis) for caching frequently accessed data.

–

Optimize indexes and SQL queries.

–

Enable storage auto scaling if storage or IOPS is a bottleneck.

–

Use connection pooling (for example, HikariCP in Spring Boot).

Interview Tip

Don’t immediately answer “increase instance size.” Always mention performance analysis first, then scaling or optimization.

The secure approach is:

–

Attach an IAM Role to the EC2 instance (or ECS task/Lambda).

–

Grant only the required S3 permissions (for example, GetObject and PutObject).

–

Use the AWS SDK to access S3.

–

Avoid hardcoding Access Keys in the application.

Interview Tip

The expected production answer is:

IAM Role + Least Privilege + AWS SDK.

I would use:

–

AWS Secrets Manager for database passwords, API keys, and tokens.

–

Encrypt the secrets using AWS KMS.

–

Grant access through IAM Roles.

–

Retrieve secrets dynamically at application startup or when needed.

Interview Tip

Avoid storing secrets in:

–

Source code

–

Git repositories

–

application.properties

–

Hardcoded environment variables (for sensitive values)

I would optimize costs by:

–

Using Auto Scaling to match capacity with demand.

–

Selecting the appropriate EC2 instance type.

–

Using Reserved Instances or Savings Plans for predictable workloads.

–

Using Spot Instances for fault-tolerant or batch workloads.

–

Applying S3 Lifecycle policies to move old data to Glacier.

–

Shutting down unused development environments.

–

Monitoring usage with AWS Cost Explorer and AWS Budgets.

–

Right-sizing EC2 and RDS instances based on utilization.

Interview Tip

Show that cost optimization is both an architectural and operational responsibility.

I would design the application with no single point of failure:

–

Deploy EC2 instances across multiple Availability Zones.

–

Use an Application Load Balancer.

–

Configure Auto Scaling.

–

Use RDS Multi-AZ.

–

Store files in Amazon S3.

–

Use CloudWatch for monitoring and alarms.

–

Use Route 53 health checks and failover routing.

–

Use SQS to decouple asynchronous workloads.

Interview Tip

Mention redundancy at every layer:

–

Compute

–

Network

–

Database

–

Storage

I would:

–

Package each Spring Boot service as a Docker image.

–

Push the images to Amazon Elastic Container Registry (ECR).

–

Deploy the containers using Amazon ECS (or EKS if Kubernetes is required).

–

Place the services behind an Application Load Balancer.

–

Configure Auto Scaling.

–

Store configuration in Secrets Manager or Parameter Store.

–

Monitor using CloudWatch.

Architecture

Docker Images

│

▼

Amazon ECR

│

▼

Amazon ECS / EKS

│

▼

Application Load Balancer

│

▼

Users

Interview Tip

For AWS-centric environments, ECR + ECS + Fargate + ALB is a common production deployment stack.

I would build a CI/CD pipeline using AWS Developer Tools:

–

CodeCommit (or GitHub) stores the source code.

–

CodeBuild compiles the project, runs tests, and creates the JAR or Docker image.

–

Push Docker images to Amazon ECR (if containerized).

–

CodeDeploy or ECS Deployment deploys the application.

–

CodePipeline orchestrates the entire workflow.

–

Monitor deployments using CloudWatch and enable rollback on failures.

Pipeline

GitHub / CodeCommit

│

▼

CodePipeline

│

▼

CodeBuild

│

▼

ECR (Docker) / JAR Artifact

│

▼

CodeDeploy / ECS

│

▼

Production

Interview Tip

For 4–6 years of experience, mention:

–

Source control (GitHub/CodeCommit)

–

Build (CodeBuild)

–

Pipeline orchestration (CodePipeline)

–

Deployment (CodeDeploy or ECS)

–

Monitoring (CloudWatch)

–

Rollback strategy

This demonstrates an end-to-end understanding of modern AWS deployment practices.

<button type=”button” class=”text-token-text-secondary hover:bg-token-surface-hover rounded-lg” aria-label=”Copy response”