Amazon VPC

Basics of building a secure cloud environment using vpc

By Abhinay Durishetty
6 mins read
Designing Your Virtual Environment
VPC in nutshell
VPC is a virtual space where you can run your applications and services securely, just like you would have your own private piece of land to build a house.
Need of
Public and Private Segmentation in VPC
Now, let's say you're building a web application. You need two things: a web server to show the website and a database to store information. Just like in your house, you might have a living room and a storage room.

The web server is like your living room – it's where guests (users) come in and see the nice stuff (your website). Since you want everyone to see it, the web server needs to be accessible from the outside, which means it's in the "public" part of your virtual space.
On the other hand, the database is like your storage room – it's where you keep important things, but you don't want just anyone to access it. It's the heart of your website, so it needs to be well-protected. That's why the database is in the "private" part of your virtual space. It's not directly accessible from the outside.

Here's where it gets interesting. When a user fills out a web form in your web app (let's say they're ordering a cool gadget), the web server needs to talk to the database to save that order. But you don't want the database to talk to strangers on its own – that would be risky. So, the web server acts like a bridge. It takes the user's order, walks over to the private storage room (database), and says, "Hey, store this safely for me."
Segmentation is facilitated using
Subnets in VPC
Just like you might have a front yard and a backyard in your house, you can divide your VPC land into smaller areas called Subnets.

By splitting your VPC land into subnets, you can control who gets to access different parts. This is important because different parts of your AWS infrastructure need different levels of security.

You can connect your public-facing stuff (like the web server) to the public subnet, and keep your more sensitive things (like the database) in the private subnet.
Let's dive into the practical aspect of AWS VPC.
Take a look at the picture, there is
  • a Web server in Subnet 2 (which is public), and
  • a Database server in Subnet 1 (which is private).

Remember the CIDR notation from the IPv4 part? It's a way we figure out how many IP addresses we need. CIDR, short for "Classless Inter-Domain Routing," helps us manage IP addresses smartly.

In this case, we chose 10.0.0.0/24, which means we have 256 IPs.
This 10.0.0.0/24 network is divided into two subnets (each having "/25" subnet mask).
  • The first subnet, 10.0.0.0/25, provides 128 IPs, and
  • The second subnet, 10.0.0.128/25, gives another 128 IPs.
That adds up to a total of 256 IPs.
Getting Internet access using
Route table, NAT and Internet Gateways
Take a glance at the picture above: the router, or route table, facilitates communication between the subnets within the VPC and controls how traffic is directed in and out of the VPC.

An internet gateway enables resources in our public subnet (our Web server) to connect to the internet if the resource has a public IP address.

However, we don't want to expose our database server to the public internet. Yet, it still requires an internet connection, for tasks like server updates. So, what's the solution?
We introduce a NAT gateway. Think of it as a middleman that brings the internet into private subnets. Look at the picture again: we've placed the NAT gateway in the public subnet, since it's the only one connected to the public internet. This setup is defined in the route table.

So, how does it work? The NAT gateway takes internet from the internet gateway and uses the route tables we've defined to direct this internet. It then delivers the internet to the private subnet, providing the necessary internet access to those servers.