DEV Community: Juhi Srivastava

Part 5: Decoupling and Background Jobs

Juhi Srivastava — Wed, 30 Sep 2026 16:07:27 +0000

Building a Web App: A Beginner's Guide to Cloud Architecture (Part 5 of 5)

In Part 1, our main server died, but our load balancer instantly shifted traffic to a backup (High Availability). In Part 2, 50,000 users rushed our registration page, and our infrastructure automatically cloned itself to handle the massive spike (Scalability). In Part 3, malicious actors tried to bypass our website, but our private networks and firewalls blocked them (Security). In Part 4, international users complained about lag, so we moved our static files to global edge networks to make the app lightning fast (Speed).

We now have a highly available, endlessly scalable, secure, and blazing-fast web application.

But there is one final bottleneck to overcome: Synchronous Processing.

Imagine our 50,000 users are now asked to upload a 2GB video portfolio to complete their registration. When a user clicks "Upload," our web server accepts the file and begins processing it. Because it is working synchronously, that specific web server is now completely locked up. For the next 10 minutes, it cannot handle any other requests.

The user is left staring at a spinning loading wheel. If other users try to reach that same server, they are put on hold. Eventually, the browser times out, the connection drops, and the server crashes from memory exhaustion.

To fix this, we need to separate the servers taking the requests from the servers doing the heavy compute. In cloud architecture, this is called Decoupling.

1. The Restaurant Analogy

Think of your web server as a waiter in a restaurant.
A bad restaurant has the waiter take your order, walk into the kitchen, cook the meal themselves, and bring it back to you. While they are cooking, they can't help any other tables.

A good restaurant uses a ticket system. The waiter takes your order, slaps a ticket onto a rail, and immediately goes back to serving other tables. The chefs in the kitchen look at the rail, pull the tickets one by one, and do the heavy lifting in the background.
We need to build that ticket rail and hire some chefs.

2. The Ticket Rail: Message Queues

In the cloud, the "ticket rail" is called a Message Queue. It is a simple, highly durable service that holds onto text messages (tickets) until a server is ready to read them.

AWS provides Amazon SQS (Simple Queue Service
Azure provides Azure Service Bus.

How the new flow works?

The user uploads a video.
The Web Server saves the raw video file to S3 (Object Storage).
The Web Server drops a tiny text message into the SQS Queue saying: "Hey, there is a new video at this S3 link that needs processing. User ID is 45."
The Web Server immediately replies to the user: "Thanks! We are processing your video and will email you when it's ready." The user is happy, the web server is instantly freed up to handle the next user, and the app remains lightning fast. But who actually processes the video?

3. The Chefs: Background Workers

We don't want our front-line Web Servers doing heavy compute. Instead, we spin up a completely separate, hidden group of resources called Workers.
While you could use a second group of standard web servers (like EC2 or Azure VMs) for this, modern cloud teams usually use Containers or Serverless Functions because they are incredibly lightweight and can scale up in seconds rather than minutes.

In AWS: You might use AWS Fargate (Serverless Containers) or AWS Lambda.
In Azure: You would use Azure Container Apps or Azure Functions.

These Worker containers have one job: they constantly ask the Message Queue, "Do you have any new tickets?"

When a worker sees the message about the video, it picks it up, downloads the raw video from S3, spends 10 minutes processing it, saves the final version, and updates the Database to mark the job as "Complete."

Because the Workers are completely decoupled, you can scale them based on the exact length of the queue. If there are 0 messages, you scale the containers down to zero so you pay nothing. If 1,000 users upload videos at once, the queue fills up, and the cloud provider instantly spins up 50 container apps to churn through the backlog.

Architecture Diagrams
Here is the final, fully decoupled architecture showing the Web Servers writing to the Queue, and the isolated Worker Servers reading from it.

AWS Final Architecture (SQS & Workers)
Azure Final Architecture (Service Bus & Workers)

Further Reading & Official Documentation
If you want to dive deeper into the concepts covered in this article, check out the official documentation from AWS and Microsoft:

AWS Queues & Background Workers

Amazon SQS: What is Amazon Simple Queue Service?
AWS Fargate: What is AWS Fargate for Serverless Containers?
Asynchronous Integration: Asynchronous messaging patterns in AWS

Azure Queues & Background Workers

Azure Service Bus: What is Azure Service Bus?
Azure Container Apps: Azure Container Apps Overview
Asynchronous Messaging: Asynchronous messaging options in Azure

That brings us to the end of our five-part journey into cloud architecture. We took a single, fragile web server and evolved it into a highly available, endlessly scalable, secure, fast, and fully decoupled enterprise application.

If you found this series helpful and want to keep leveling up your engineering skills, be sure to follow for more such content!

Part 4: Storage, Speed, and Global Reach

Juhi Srivastava — Tue, 22 Sep 2026 21:27:14 +0000

Building a Web App: A Beginner's Guide to Cloud Architecture (Part 4 of 5)

Let's recap the journey so far.

In Part 1, we made sure our app wouldn't crash if a server suddenly died (High Availability). In Part 2, we survived a massive 50,000-user traffic spike by teaching the app to automatically clone itself (Scalability). In Part 3, we built a digital fortress around the network to keep hackers out (Security).

Our application is now an absolute tank. It is virtually unbreakable. But if we launch it right now, we are going to run into a completely different problem: It feels sluggish.

Imagine that 50,000-user traffic spike hits again. Your servers scale up perfectly, and the app stays online. But every single time a user loads the homepage, your web servers are forced to process a heavy 5MB hero image, and your database has to recalculate the exact same "Top 10 Events" list. Doing that exact same math 50,000 times a minute is exhausting and incredibly expensive.

To make matters worse, if your data center is in Virginia, a user trying to register from Tokyo is going to be staring at a blank screen for three seconds while the data physically travels across the Pacific Ocean.

A secure and scalable app isn't necessarily a fast app.
In Part 4, we are going to fix that. We will optimize our architecture by decoupling our storage, giving our database a short-term memory, and making the app load instantly for users anywhere in the world.

1. The Ephemeral Storage Problem (S3 & Blob Storage)
In an auto-scaling environment, your web servers are "ephemeral." This means they are temporary. The cloud provider creates and destroys them dynamically based on traffic.

Because of this, you can never treat a web server's hard drive as permanent storage. If a user uploads a profile picture and saves it directly to Web Server A, that picture will be permanently deleted the moment the traffic spike ends and the auto-scaler terminates Web Server A.

To fix this, we must make our web servers stateless. Compute and storage need to be completely separated.
Instead of saving files locally, the web server takes the user's uploaded file and pushes it to a centralized, infinitely scalable object storage bucket.

AWS calls this Amazon S3 (Simple Storage Service).
Azure calls this Azure Blob Storage.

Now, it doesn't matter if you have two web servers or two hundred; they all read and write to the exact same centralized storage bucket.

2. The Speed of Light Problem (Content Delivery Networks)
Moving our images and videos to Amazon S3 solves our storage problem, but it introduces a latency problem.

Data travels fast, but it cannot break the speed of light. If your S3 bucket is located in a data center in Virginia, a user in Tokyo is going to experience a delay while that image travels across the Pacific Ocean.

We solve this using a Content Delivery Network (CDN).
A CDN is a massive global network of proxy servers located in hundreds of cities around the world (called Edge Locations). When you put a CDN in front of your storage bucket, it caches copies of your static files at these edge locations.

When the user in Tokyo requests the profile picture, the request doesn't go all the way to Virginia. It goes to a CDN edge node in Tokyo, which serves the image in milliseconds.

AWS calls its CDN Amazon CloudFront.
Azure calls its CDN Azure Front Door.

3. The Database Bottleneck (In-Memory Caching)
Static files (images, CSS, PDFs) are handled by the CDN, but what about dynamic data?

Reading from a relational database is a computationally expensive task because the database has to read from disk. If 10,000 users visit your homepage, and the homepage displays the "Top 10 Newest Articles," your web servers are going to ask the database for the exact same information 10,000 times. This is a massive waste of resources.

We fix this by introducing a caching layer right in front of the database. Think of the cache as the database's short-term memory. It stores data in RAM, making it blisteringly fast to retrieve.
When a user requests the homepage, the web server asks the cache first:

Cache Hit: If the "Top 10 Articles" are in the cache, the cache returns them instantly. The database does no work.
Cache Miss: If the data isn't there, the web server queries the database, returns the articles to the user, and writes the result into the cache for the next user

The industry standard technology for this is Redis.

AWS manages this for you with Amazon ElastiCache for Redis
Azure provides Azure Cache for Redis.

Architecture Diagram

Azure Architecture Diagram

AWS Architecture Diagram

Part 3: Security - Locking Down the Network

Juhi Srivastava — Sun, 06 Sep 2026 22:12:53 +0000

Building a Web App: A Beginner's Guide to Cloud Architecture (Part 3 of 5)

Alright, let's take a step back and look at what we've built so far.

In Part 1, we made sure our app doesn't crash when a server dies (High Availability). In Part 2, we taught it how to automatically clone itself to handle a massive 50,000-user traffic spike (Scalability).

But there's a critical flaw in our current setup: it is completely exposed to the internet.

If your application servers and databases are sitting on the public web, anyone can try to connect to them. You don't want a random script or a malicious user bypassing your web interface to brute-force your database.

To fix this, we need to take our infrastructure off the public internet and lock it down.

1. The Private Network (VPCs & VNets)

When you spin up a server in the cloud, you shouldn't just drop it into the public ether. You need to put it inside a private, isolated network boundary.

Think of this like buying a private plot of land and putting a fence around it. Everything inside the fence can talk to each other, but the outside world doesn't even know it exists.

AWS calls this a Virtual Private Cloud (VPC).
Azure calls this a Virtual Network (VNet).

Once your database and servers are inside this private network, they are safe from direct outside access. But obviously, legitimate users still need a way to reach the website. That's where subnets come in.

2. Zoning the Network: Public vs. Private Subnets

You need to divide your private network into different zones, called Subnets. The easiest way to visualize this is by looking at a bank. The lobby is public - anyone can walk through the front doors. The vault is private, and getting to it requires going through security.
We structure our cloud network the exact same way:

The Public Subnet (The Lobby): This subnet has a route to the internet. We put our Load Balancer here. It faces the public web, accepts user traffic, and routes it backward.
The Private Subnet (The Vault): This subnet is completely cut off from the internet. We put our Web Servers and Database here.

Because the web servers and database live in the private subnet, nobody on the internet can reach them directly. The only way traffic can get to your web servers is if it passes through the load balancer first.

3. Security Groups

Just because we forced traffic through the load balancer doesn't mean our job is done. We still need to define strict rules about which resources are allowed to talk to each other inside the network.
We do this by attaching firewalls directly to our resources.

AWS calls these Security Groups.
Azure calls these Network Security Groups (NSGs).

The default rule for cloud security is the principle of least privilege: deny all traffic, and only explicitly allow what is required.

How we configure the firewall rules for our architecture?

Load Balancer Firewall: Allow incoming HTTP/HTTPS traffic from Anywhere (the internet).
Web Server Firewall: Deny everything, except traffic coming directly from the Load Balancer.
Database Firewall: Deny everything, except traffic coming directly from the Web Servers.

If an attacker somehow compromises the load balancer and tries to send a command straight to the database, the database's firewall will check the origin, see that it isn't a web server, and immediately drop the connection.

4. Deep Inspection: Web Application Firewalls (WAF)

While Security Groups are essential, they have a blind spot. They only check where traffic is coming from and what port it's using (like a bouncer checking an ID). They don't look at the actual data being sent.

If a hacker acts like a normal user but types a malicious database command into your website's login box, the Security Group will let it through because it registers as valid web traffic.

To stop this, we need a Web Application Firewall (WAF) attached directly to the load balancer. If the Security Group is the bouncer checking IDs, the WAF is the metal detector inspecting the payload. It reads HTTP requests line by line. If it spots a common attack - like an SQL injection or Cross-Site Scripting (XSS) - the WAF drops the connection before it ever reaches your web servers.

AWS: You attach AWS WAF to your Application Load Balancer.
Azure: You attach the Azure Web Application Firewall to your Application Gateway.

Architecture

AWS Architecture Diagram

Azure Architecture Diagram

References & Further Reading

If you want to dive deeper into the concepts covered in this article, check out the official documentation from AWS and Microsoft:

AWS Security & Networking

Amazon VPC: What is Amazon VPC?
Security Groups: Control traffic to your AWS resources using security groups
AWS WAF: How AWS WAF works

Azure Security & Networking

Azure Virtual Networks (VNets): What is Azure Virtual Network?
Network Security Groups (NSGs): Network security groups - Azure Virtual Network
Azure WAF: What is Azure Web Application Firewall?

Coming Up Next in Part 4: Speed, Storage, and Global Reach
Our application is now highly available, scalable, and secure. However, forcing our web servers to process heavy image files and run repetitive database queries for every single user is slow and expensive.
In Part 4, we will focus on taking the heavy lifting off our compute layer and making the app load instantly for users anywhere in the world. We will cover:

Object Storage (Amazon S3 / Azure Blob Storage): Why you should never save user uploads directly to a web server, and how to use infinite cloud storage instead.
Content Delivery Networks (AWS CloudFront / Azure Front Door): How to cache those stored files globally so they load in milliseconds, no matter where your users are located.
Database Caching (Amazon ElastiCache / Azure Cache for Redis): How to give your database a "short-term memory" so it stops doing the same heavy lifting twice.

Stay Tuned!

Part 2: Scalability — How to Survive a Massive Traffic Spike?

Juhi Srivastava — Sun, 23 Aug 2026 13:49:28 +0000

Series: Building a Web App: A Beginner’s Guide to Cloud Architecture (Part 2 of 5)

In Part 1, we made our Web App Highly Available. If a server breaks, our load balancer silently shifts traffic to a backup. We don't have to worry about our app going offline due to a hardware failure.

But what if your app doesn't crash from a failure, but from success?

Imagine it is the final day of registration for your event. Suddenly, 50,000 users hit your website at the exact same time. Your two baseline servers max out their CPU, run out of memory, and the system grinds to a halt.

We are going to fix that by making our infrastructure scalable.

Scaling Up vs. Scaling Out

When a server runs out of computing power, you have two choices:

Vertical Scaling (Scaling Up): You turn off the server, buy a bigger processor, add more RAM, and turn it back on. It is easy to understand, but it requires downtime. Eventually, you hit a limit—you can only buy a computer so big.
Horizontal Scaling (Scaling Out): Instead of making one server bigger, you dynamically add more servers. If two servers handle 10,000 users, we can automatically spin up eight more servers to handle 50,000 users.

In the modern cloud, Horizontal Scaling is the gold standard because it is elastic. When the traffic goes down, we delete the extra servers so we stop paying for them.

How Does Auto-Scaling Actually Work?

When your system decides it needs more power, there isn't a person in a data center running over to plug in a new machine. It is entirely automated. Here is what happens when traffic spikes:

The Alarm: A monitoring service notices your servers are struggling (e.g., CPU has been sitting at 80% for three minutes). It sends an alert.
The Blueprint: The Auto Scaler looks at a "Blueprint" you provided earlier. This blueprint contains the exact operating system, application code, and settings needed to run your app perfectly.
The Clone: The cloud provider instantly provisions brand new resources using that exact blueprint.
The Introduction: Once the new servers or containers finish booting up, the Auto Scaler introduces them to the Load Balancer. The Load Balancer immediately starts sending user traffic to them, lowering the CPU usage across the board.

Setting the Rules (Scaling Policies)

Three rules you need to configure:

The Scale-Out Rule (When to add): "If average CPU usage goes over 75% for 3 minutes, add 2 servers." This protects the application from crashing.
The Scale-In Rule (When to remove): "If average CPU usage drops below 30% for 5 minutes, remove 2 servers." This protects your wallet when everyone goes to sleep.
The Cooldown Period: A mandatory waiting period (e.g., 5 minutes) after a scaling event happens. This stops the system from panicking and adding 10 servers all at once before the first new server has even finished booting up.

The Architecture Blueprint

Both major cloud providers have dedicated services that monitor your traffic and automatically create or destroy servers based on the rules you set.

Compute Type	AWS Service	Azure Service	Best For
Raw Servers (IaaS)	Auto Scaling Group (ASG)	Virtual Machine Scale Sets (VMSS)	Legacy apps or deep OS-level control.
Web Apps (PaaS)	Elastic Beanstalk	Azure App Service	Traditional web apps where you just want to upload code.
Simple Containers	AWS Fargate (Standalone)	Azure Container Instances (ACI)	Quick, single-task container execution without complex scaling.
Container Scaling	ECS / EKS with Fargate	Azure Container Apps (ACA)	Modern microservices that need to auto-scale instantly (even down to zero).

Note: An Auto Scaling Group (ASG) is specifically built to manage EC2 instances (which is AWS's official name for raw virtual servers).

Architecture Diagram

AWS Architecture Diagram

Good to know stuff about AWS:
According to the official Amazon EC2 Auto Scaling documentation:

If a scaling action occurs, Amazon EC2 Auto Scaling automatically maintains balance across all of the Availability Zones that you specify.

When a scale-out event happens,

Amazon EC2 Auto Scaling does this by attempting to launch new instances in the Availability Zone with the fewest instances.

Because our Auto Scaling Group spans two Availability Zones, AWS strictly enforces a 'balanced distribution' rule. If we tell it to add 2 instances, it looks at our zones and says, 'AZ 1 has one server, and AZ 2 has one server.' It will launch the first new server in AZ 1, and then launch the second new server in AZ 2 to ensure the high-availability balance remains perfectly intact.

Azure Architecture Diagram

Good to know stuff about Microsoft Azure:
A single VMSS(Virtual Machine scale set) can span across multiple Availability Zones, as long as those zones are inside the same Region.

If you build a VMSS in the "East US" region, you can tell Azure to spread your virtual machines across AZ 1, AZ 2, and AZ 3.

Because our Virtual Machine Scale Set (VMSS) in above diagram spans two Availability Zones, Azure enforces a 'zone balancing' rule. If we tell it to add 2 instances, it looks at our zones and says, 'AZ 1 has one server, and AZ 2 has one server.' It will launch the first new virtual machine in AZ 1, and then launch the second new virtual machine in AZ 2 to ensure the high-availability balance remains perfectly intact.

Further Reading & Official Documentation
If you want to dive deeper into the concepts covered in this article, check out the official documentation from AWS and Microsoft:

AWS Auto Scaling Group Benefits (Multi-AZ):https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html
AWS Auto Scaling Availability Zone Distribution (Balancing): https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-availability-zone-balanced.html
Azure VMSS and Availability Zones (Zone-Spanning): https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-use-availability-zones
Azure Monitor Autoscale Best Practices: https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-best-practices

Coming Up Next in Part 3: Locking Down the Castle (Networking & Security)
So far, we have built an application that is unbreakable (High Availability) and unstoppable (Scalability). But right now, we have a massive blind spot: Security.
If 50,000 legitimate users can easily reach our web servers, what is stopping a malicious hacker from trying to access our database directly?

Stay tuned as we take our cloud architecture from highly scalable to highly secure!

Part 1: High Availability — How to Keep Your Application Online When Servers Fail?

Juhi Srivastava — Thu, 20 Aug 2026 21:30:40 +0000

Series: Building a Web App: A Beginner's Guide to Cloud Architecture (Part 1 of 5)

In this 5-part series, we are building a cloud-based application designed to handle high-stakes user registrations and critical data submissions. We will explore how to make it reliable, scalable, secure, and cost-effective using AWS and Azure.

The Story: A Server Goes Down
Imagine your application is processing user registrations for a massive event with a strict midnight deadline. Thousands of people are filling out their forms and submitting their details at the same time.

At 11:30 PM, the physical computer running the application experiences a hardware fault and turns off.

The website throws an error, form submissions stop working, and users are left stranded. For any business critical application, this kind of downtime is unacceptable.

So, how do we make sure our application stays online even when hardware breaks?

The Problem: The Single Point of Failure (SPOF)
When building a new app, most people start with the simplest setup: one virtual server running the website and the database together.

Pros - This is cheap and quick.
Cons - It creates a Single Point of Failure (SPOF). If that single server crashes, loses power, or loses its internet connection, everything stops working until someone manually logs in and restarts it.

The Solution: Don't Put All Your Eggs in One Basket

In cloud computing, we assume hardware will fail eventually. Instead of hoping a server never breaks, we design the system to automatically recover when it does. This concept is called High Availability (HA).

To achieve this, we use two fundamental building blocks:

Availability Zones (AZs): Cloud providers group their physical data centers into regions. Inside each region, there are multiple, physically isolated data centers called Availability Zones. They have completely separate power supplies, cooling systems, and internet connections. If one building loses power, the other buildings keep running.
A Load Balancer: Think of a load balancer like a traffic officer. It sits in front of your servers, constantly checks which ones are healthy, and directs incoming traffic only to the servers that are working properly.

How Does the Load Balancer Know a Server is Dead?
You might be wondering how exactly does the load balancer know when to stop sending traffic to Zone A and switch to Zone B?

It relies on a mechanism called a Health Check.

Think of the load balancer as an overly attentive manager checking in on its employees. Every few seconds, the load balancer sends a tiny, automated request (like a digital "ping") to every web server it manages.

The Healthy State: If the server is working properly, it instantly replies with a success code (specifically, an HTTP 200 OK status). The load balancer logs this as a healthy heartbeat and continues sending users to that server.
The Unhealthy State: If a server crashes, freezes, or loses power, it won't reply. If the load balancer misses consecutive heartbeats (for example, 3 failed checks in a row), it officially marks that server as Unhealthy.

Once a server is marked unhealthy, the load balancer instantly removes it from the rotation. New users are seamlessly routed only to the healthy servers remaining in the other Availability Zones. Once the broken server is fixed and starts replying to heartbeats again, the load balancer automatically adds it back into the mix.

Now that you know how load balancer works, lets build the Architecture diagram.

AWS Architecture Diagram

Azure Architecture Diagram

Now what happens when someone visits the application:

The Load Balancer receives the request and sends it to either Web Server 1 or Web Server 2.
If Web Server 1 crashes, the load balancer detects the issue immediately and routes 100% of user traffic to Web Server 2. The user doesn't notice any disruption.
For the Database, our primary database continuously syncs all saved data to a standby database in Zone B. If the primary database fails, the cloud provider automatically switches to the standby copy without losing any user records.

AWS vs. Azure: Service Comparison

Both major cloud providers give you managed tools to set this up with just a few clicks:

Component	What It Does?	AWS Service	Azure Service
Traffic Router	Directs web traffic to healthy servers	Application Load Balancer (ALB)	Azure Application Gateway
App Servers	Runs the application code across multiple zones	EC2 (in an Auto Scaling Group)	Virtual Machine Scale Sets (VMSS)
Database	Stores data with an automated backup copy	Amazon RDS (Multi-AZ)	Azure SQL (Zone-Redundant)

Note: For regional High Availability in Microsoft Azure, use Azure Application Gateway. If you want to expand globally later, you would put Azure Front Door in front of everything.

Implementation: The One Line That Saves Your Data

When setting up infrastructure with code (using tools like Terraform), turn on high availability for a database.

Here is an AWS Terraform example:

resource "aws_db_instance" "my_application_db" {
  allocated_storage = 50
  engine            = "postgres"
  instance_class    = "db.t3.medium"
  db_name           = "app_database"
  username          = "dbadmin"
  password          = var.db_password

  # This single line tells AWS to automatically maintain a backup database in a second zone:
  multi_az          = true 
}

By setting multi_az = true, AWS handles all the complex data replication, monitoring, and automatic failovers in the background.

Key Takeaway
High Availability isn't about buying invincible hardware. It is about deploying duplicate resources across different physical locations so a failure in one area doesn't take your entire platform down.

Further Reading & Official Documentation
If you want to dive deeper into the concepts covered in this article, check out the official documentation from AWS and Microsoft:

Coming Up in Part 2: Now that our application won't crash from a single hardware failure, what happens when 50,000 users hit the site simultaneously on the final day of registration? We will cover Scalability and how to automatically add more power during traffic spikes.

Deploy Your Angular App with AWS S3 & CloudFront: A Fast, Cost-Effective Guide

Juhi Srivastava — Mon, 17 Aug 2026 20:42:47 +0000

Introduction

Deploying your Angular application to the cloud is a crucial step in sharing your work with the world. AWS offers a reliable and scalable way to host your app with minimal cost and effort — especially using S3 for static hosting combined with CloudFront for fast global delivery. In this guide, I’ll walk you through how to deploy your Angular app on AWS quickly, even if you’re new to AWS.

Prerequisites

Before we start, make sure you have:

An Angular app ready to deploy
An AWS account (free tier is sufficient for basic hosting)
Basic knowledge of Angular CLI and AWS Console

Before we start …

Before we dive into the step-by-step process to deploy an Angular app on AWS, it’s important to understand the core services we’ll be using: Amazon S3 and CloudFront, and how they work together to host a static website efficiently.

What is Amazon S3?

Amazon Simple Storage Service (Amazon S3) is a highly scalable, secure, and durable object storage service. It allows you to store and protect any amount of data, supporting a wide range of use cases such as data lakes, mobile apps, backups, archives, enterprise applications, IoT devices, big data analytics, and — importantly for us — static website hosting.

In simple terms, S3 acts as a reliable place to store your website files — HTML, CSS, JavaScript, images, and more.

Learn more about Amazon S3

What is CloudFront?

Amazon CloudFront is a fast, secure, and programmable Content Delivery Network (CDN) service. It delivers your web content — including static and dynamic files, videos, APIs — globally with low latency and high transfer speeds.

CloudFront caches your content at edge locations worldwide, so your users get faster access regardless of their geographical location. It acts as a distributed cache, retrieving content from your origin (like your S3 bucket) and serving it quickly from the nearest edge location.

Learn more about Amazon CloudFront

Our Plan for Static Website Hosting

S3 will store and deliver the static files of our Angular application (UI content).
We will deploy the Angular build output directly into an S3 bucket configured for static website hosting.
To improve performance and reduce latency, CloudFront will be used to distribute our content globally.

Accessing the website directly from the S3 bucket is possible but can lead to higher latency, especially for users far from the AWS region hosting your bucket.

CloudFront speeds up this delivery by caching content in multiple edge locations across the Americas, Europe, Asia, Africa, and more. When a user requests your website, CloudFront first checks its nearest cache (edge location). If the content is not found there, it fetches it from the S3 bucket and caches it for subsequent requests.

Lets begin..

Step 1: Build Your Angular Application

Open your terminal and navigate to your Angular project folder. Run the following command to build your app for production:

ng build --prod

This command compiles your app into static files optimized for performance. The output will be in the dist/your-app-name folder.

Step 2: Create an S3 Bucket

Log in to the AWS Management Console.
Navigate to S3 and click Create bucket.
Choose a unique bucket name (e.g., my-angular-app-bucket) and your preferred AWS region.
Leave the default settings, but uncheck “Block all public access” so your site can be publicly accessible.
Confirm the warning and create the bucket.

Click on your newly created bucket.
Click on “Properties” Tab and then edit the “Static website hosting”

Step 3: Enable Static Website Hosting

Click on your bucket name, then go to the Properties tab.
Scroll down to Static website hosting and click Edit.
Select Enable, choose Use this bucket to host a website.
Enter index.html as the Index document and 404.html as the Error document (create a 404 page or leave empty).
Save changes.

Step 4: Upload Your Angular Build Files

Open the dist/your-app-name folder on your computer.
In the AWS Console, go to your S3 bucket and click Upload.
Upload all the files and folders from the dist directory.
Alternatively, use below commands:

aws s3 cp ./dist s3://YOUR-BUCKET-NAME –recursive

Go to “Permissions” and navigate to the Public Access settings for your bucket. Unselect “Block public and cross-account access if bucket has public policies” . We have to change it to false, otherwise it will block public access and our app will be inaccessible from internet. By default all AWS S3 buckets are private.

Step 5: Set Bucket Policy for Public Access

In the “Permissions” Tab , add the bucket policy to “GetObject” that will allow public to access our data. Apply the policy that will allow public access to data in AWS.
Save the policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
    }
  ]
}

Step 6: Use CloudFront for CDN and HTTPS

Navigate to AWS CloudFront Console

Visit https://console.aws.amazon.com/cloudfront/ and click Create Distribution.
Choose Delivery Method

Select Web as the delivery method and click Get Started.
Configure Origin Settings
- For Origin Domain Name, select or enter your S3 bucket URL.
- Make sure to choose the correct bucket that hosts your static website content.
Set Viewer Protocol Policy

Under Default Cache Behavior Settings, change the Viewer Protocol Policy to Redirect HTTP to HTTPS to enforce secure connections.
Configure Distribution Settings
- In the Distribution Settings section, add your Alternative Domain Name (CNAME) if you want to use a custom domain (e.g., www.yourdomain.com).
- Select an appropriate SSL Certificate (either an AWS Certificate Manager certificate for your domain or use the default CloudFront certificate) to enable HTTPS.
- If you don't need a custom domain, leave the SSL settings as default.
Review and Create

Keep other settings at their default values unless you have specific requirements.

Scroll down and click Create Distribution to finalize.
Wait for Distribution Deployment

CloudFront will take approximately 10–15 minutes to deploy your distribution. You’ll be notified when it’s ready.

Navigate to Distributions to see the newly created distribution. The domain name column contains your CloudFront URL, which will be something like this:

YOUR-BUCKET-NAME.s3-website-YOUR-BUCKET-ZONE.amazonaws.com

Copy the CloudFront URL and paste it into the browser tab. You should successfully see your application.

Things to Keep in Mind When Configuring an S3 Bucket as a Static Website

Eable Static Website Hosting:

To serve your content as a static website, you need to enable static website hosting on your S3 bucket. This setting allows Amazon S3 to function like a web server.

Configure and Upload an Index Document:

An index document is the default webpage that Amazon S3 returns when visitors access the root of your website or any subfolder. Make sure to create and upload this file (usually index.html) to your bucket.

Set Permissions for Public Access (if required):

If you want your website to be publicly accessible, you need to:

1. Disable the “Block Public Access” settings on your bucket.

2. Add a bucket policy that grants public read permissions, allowing anyone to view your website content.


    Without these permissions, users won’t be able to access your website.

Understand Your Website Endpoint URL

When static website hosting is enabled, your website is accessible via an AWS Region-specific endpoint.

The URL format depends on your region and typically looks like one of the following:

http://bucket-name.s3-website-<region>.amazonaws.com (with a dash -)
http://bucket-name.s3-website.<region>.amazonaws.com (with a dot .)

Refer to AWS Documentation for More Details:

For comprehensive guidance on static website hosting with Amazon S3, visit the official AWS docs:

Hosting a static website using Amazon S3