Amazon Web Services or AWS Cloud offers pay as you go on demand compute resources that allow you to run workloads and store data on AWS network infrastructure which removes the need to buy and maintain expensive computer hardware in-house.
The compute resources as well as many fully managed AWS services can be scaled on demand and are all accessible via the web.
To be accessible via the internet, these services need to be accessible via standard IP protocols and built using familiar network structures that meet standard best practices and meet regulatory and internal security requirements.
AWS VPC is the networking service that will enable you to isolate and manage access to your compute and data storage resources configured in the AWS ecosystem. VPC is a logically isolated virtual network that allows you to secure and monitor traffic and prevent resource instance access inside the VPC
AWS VPC allows you to create a private virtual network in the AWS cloud which uses the same concepts and constructs as on premise networks, however much of the complexity of setting the network is taken care of by AWS. You still retain control of the access, security and usability configuration of your AWS VPCs. According to AWS you will spend less time setting up and managing your virtual network and can focus on building the applications to run on it.
You maintain control of the network configuration of your VPC and have control over setting up IP address ranges, configuring subnets in a VPC and setting up routing tables to control both internal inter-vpc access and access from the internet. You choose which resources to isolate within a VPC and those you wish to expose publicly or via peering connectivity.
You are able to deploy an AWS VPC in a way that layers security controls which gives you fine grained control to allow or deny access to specific internal or external traffic. This is done by isolating subnets, defining access control lists and customising routing table rules. You maintain complete control over allowing or denying access to both incoming and outgoing traffic.
Once you define your VPC, there are lots of AWS resources like EC2 instances that you deploy into your VPC that will inherit the security you have built into your VPC network.
VPC is a foundational AWS service and it integrates tightly with other key foundational services like Amazon RDS, S3, DynamoDB, Workspaces, Elastic Load Balancing, EFS, Elastic Beanstalk, Amazon Route 53 and AWS Elasticache.
When you provision an RDS database for instance, the deployed database instance is placed into the nominated VPC and is protected by the security settings configured for that VPC. This is similar to on premise network security protecting a database installed on a server in your on-prem network.
When you provision an AWS VPC you are building on high availability global infrastructure made up of AWS regions and availability zones. Each AWS region has multiple availability zones (data centres), so when you create your VPC, it can be seamlessly replicated across multiple AZs.
You can create multiple VPCs in your AWS account, each with a separate IP address space, allowing you to segregate applications or environments. You can also create multiple subnets to divide up your VPC for greater control or to allow your VPC to span multiple AZs for greater availability and redundancy.
Private subnets typically do not have access in or out from the internet, while public subnets will allow internet traffic. To allow internet traffic, you will need to attach an internet gateway to the VPC. When configuring your internet gateway, your subnet route table will need to be configured as will any resources in the subnet. For example an EC2 instance that needs public access will need to have a public IP address defined.
Route tables are set up to control the traffic leaving your subnets or traffic in between the subnets and the internet. By default, all the subnets within a VPC can communicate with each other.
There are a number of other integration services that can be used with your VPC
- AWS Transit Gateway — connects VPCs, other AWS accounts and on prem networks.
- AWS Network Firewall — deploys network security across VPCs with a few clicks
- AWS Private Link — establishes links between VPCs without internet exposure
- AWS NAT Gateway — allow private subnets to access the internet but not vice-versa
- AWS VPN — extends your on prem network to the cloud for secure access from anywhere.
When you build applications on AWS you will most likely end up with resources spread across several subnets and availability zones within your AWS account.
The easiest way to visualize these so you can see how your network is constructed is to connect your AWS account to Hava and let Hava diagram your network.
In the above diagram of our demo network, you can see a VPC has been detected which is denoted by the green box (with red highlight for dramatic effect)
On the right we can see details related to the VPC when the VPC bounding box is selected.
External to the VPC are the resources connected to or providing a pathway into the VPC. If we select the top left Icon above the VPC, we can see it’s an internet gateway. Selecting the icon changes the metadata in the attribute pane to reveal the IGW name, region and tags.
Next to the IGW is a VPN gateway, followed by two customer gateways and a web application firewall Access Control List, all of which are providing secure access to the VPC in one form or another.
To the right hand side of the VPC you can see a VPC Endpoint and a VPC peering connection and to the left of the VPC a couple of S3 buckets.
The two vertical columns shown as dotted lines are the Availability Zones that subnets within the VPC have been set up in. In this example the left hand AZ is us-east-1d and the right is us-east-1e
Inside the AZs you have four subnets that are configured within the VPC. The top left subnet is selected and shows details in the attribute pane like the subnet name, region, AZ, VPC and all the connected resources.
Inside each of the subnets you can see the provisioned resources in each subnet.
Selecting the second resource in the top left subnet shows us it’s an EFS File System, it’s name, region, creation time, lifecycle state, mount targets, owner id, performance mode, size, throughput type and whether it’s encrypted.
That’s quite a lot of detailed information about the resource that you didn’t have to go searching for in your AWS console. You’ll also notice that the diagram simply displays the EFS icon and nothing else, which keeps the diagram clean and readable which enables you to get a good understanding of what you have running where. The detailed information regarding the resources on the diagram are a simple click away. You don’t need to go off to a separate console or waste any time tracking down metadata, it’s all there and discoverable by selecting the resource or service icon you wish to know more about.
This is true for all the resources on the diagram, like the elastic and application load balancers, the EC2 instances, the RDS database, the workspaces or even the active directory service in the bottom left subnet.
Even though containerised functions and workloads are gaining in popularity, the AWS VPC is still the most popular way of establishing a cloud based virtual private network for hosting secure applications and data in the AWS cloud.
If you are developing or managing AWS based applications or micro services that use the AWS VPC service and would like to visualise exactly what you have running, you can connect to Hava and have diagrams of your network topology in seconds.
You can take a free trial at https://www.hava.io , or you can get in touch to arrange a one-on-one demo to view a walkthrough and to discuss your use-case and requirements.
Hava is available online as a SaaS service, or can be provided as a self-hosted solution.
Originally published at https://www.hava.io.