Part 3: Security - Locking Down the Network

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!