The VPC and Her Architecture
Introduction
VPC is just an acronym for Virtual Private Cloud. The VPC has got various definitions by reputable service providers. Amazon defines it as a service that lets you launch AWS resources in a logically isolated network that you define. Azure emphasizes a VPC is a highly secure environment to run your virtual machines and application.
Google preaches that a VPC is global, flexible and scalable.
But this is my laid-back colloquial picture of a VPC; a VPC is a scalable (both horizontally and vertically), highly secure, isolated (if you want) environment where you get to run all your stuff; Production, Development, Virtual Machines, Compute Engines, Storage, Database Servers, Web Servers. The list goes on and on. It’s massive.
Now that you understand, let’s talk about the VPC’s makeup. Okay, let me use the right phrase…
The VPC Architecture
I’m going to walk you through the VPC Architecture. Although I’m more familiar with the AWS VPC environment, the architecture remains the same across all providers. Good, let’s go!
Let’s talk “instances”
An Instance is a Virtual machine that runs all our workload in the cloud. All the “stuff” we talked about ranging from hosting web servers, compute engine, production environment; something has to do the job-the instance. Oftentimes, a virtual machine and an instance are used interchangeably but I thrashed out this concept here.
Let me illustrate better. An Amazon EC2 instance is a virtual server in Amazon’s Elastic Compute Cloud (EC2) for running applications on the AWS infrastructure. AWS instances are created Amazon Machine Images. The images are like templates.
The instance is where all the work is being done and seen. It’s the webserver or database server you interact with. And let me add this, you can have many instances in a VPC.
Subnetting
Subnets allow you to create smaller networks within the large network for higher efficiency. Your instances reside within the subnets. You can create a public subnet and a private subnet. The public subnet has access to the internet. Nevertheless, there’s a way to give the private subnet access to the internet; we’ll talk about this down the line.
Put up the walls of China
In the VPC, two walls make the VPC highly secure. They are the Network Access Control Lists (NACLs) and the Security Groups. The Security Group acts as a virtual firewall that controls the traffic for one or more instances. A Security Group (SG) can be configured for specific purposes. A security group for Web Servers will allow HTTP and HTTPS traffic and block all other traffic. And a security group for Database servers will allow traffic from SQL servers and RDP and block all other traffic. The security group is the bridge between the instance and the subnet.
The Network Access Control List (NACLs) is an optional VPC security layer that acts as a firewall for controlling traffic in and out of one or more subnets. The NACLs are used for blacklisting traffic while the Security Groups are used for whitelisting traffic.
The Gateways
An internet Gateway (IGW) must be connected to your VPC and you can only attach one per VPC. The internet gateway is the device that allows your VPC to communicate with the internet. Nonetheless, every VPC has a default route table that does not direct traffic to the internet gateway (IGW). To get traffic flowing to the internet gateway, you just have to create a custom route table.
The Route Table
A route table contains a set of rules which determines where network traffic. Compulsorily, every subnet has to be associated with a route table. A subnet can only be connected to just one route table but the route table can spread its connection tentacles to multiple subnets. But you must remember that it’s the public subnets you connect to the Internet Gateway.
But… also remember I told you there are ways to connect the Private Subnet to the Internet Gateway. Here’s how: You use a Network Address Translation (NAT) device to enable devices in a private subnet to connect to the internet. A NAT device allows Egress but prevents Ingress. Instances you would want to launch in the private subnet is a Database server.
Anyways, there are great cultural practices you need to imbibe to be as efficient as possible including cost-efficiency- and you know efficiency is at the core of DevOps. I’ll make a quick list.
Always use Private and Public subnets.
Provide NAT Gateways to secure interneted private subnets.
Create separate VPCs for different environments (Production, Staging, Development) or create different subnets within a VPC. It increases efficiency, productivity and speed.
Use standardized naming conventions.
I look forward to hearing your viewpoints and contributions on automation and the DevOps culture. I gotta say, my content isn’t limited to the traditional software space but I also break down the myths and legends of Business and Strategy and their integration with software.
And my content is always relatable by both professionals and newbies in software and software-related fields. So if you have any questions, shoot away or you can also reach me on Twitter.
Thanks for Reading.
Please leave a comment if you have any thoughts about the topic — I am open to learning and knowledge explorations.
