AWS Insight: Virtual Private Cloud

Hello, Cloud enthusiasts!

Today I finally found time and courage to introduce you to a fascinating service, provided by Amazon Web Services: Virtual Private Cloud — VPC.

VPC allows creating isolated private networks within the Amazon Public Cloud. What is it exactly that VPC provides?

·         Private IP sub-networks

·         Full control over addresses

·         Dynamic and convenient management of network devices and routing

·         Support of EC2, RDS, SQS, ElastiCache etc.

·         Much more...

VPC has lots of internal terms and concepts. I will define them in the course of configuration. Today we will setup a cross-zone network for VPC failure-proof.

VPC

Let us move to VPC using the console and create a new private cloud:

For this example I chose the sixteenth sub-network 10.50.0.0, which contains 256*256 = 65536 addresses. By the way, we can also choose between default and dedicated tenancy.

If we choose the default option, our servers will be launched in indefinite locations. The dedicated 'apartment' allows us launching instances in nearby locations, however for a certain fee.

Subnetworks

The Cloud has been created, now we need subnetworks. Our cloud is associated with its region and can have a great many subnetworks (there should be a place to put all those 65k addresses, right?), while the subnetworks are associated with their availability zones.

Also, subnetworks can be:

·         private — no direct Internet access, only via public networks or NAT

·         public — can have Internet access via Elastic IP and Internet Gateway

Let us create a public and a private subnetwork in one zone and just a private one in another zone, so that we get the following layout:

We will make these subnetworks private or public later. For now, we should just create three common subnetworks:

And we get what we requested:

Internet Gateway

As I mentioned earlier, a public network can have direct Internet access via a gateway.

Internet Gateway is a virtual device, letting hosts with elastic IP (EIP) in the Internet. Let us create a gateway and attach it to our cloud to get the following picture:

Step one – creating a gateway per se:

Attaching the gateway to the Cloud:

Route Tables

This is when we start wondering, how we should direct our public network to the gateway we have just created. This is what routes are for.

Routes are virtual paths that spread over one or several subnetworks and provide information traffic distribution rules. This process is not reflected on the hosts’ side. They have a simple route to the first host on the network (e.g. 10.50.1.1). VPC guides traffic independently, based on the Routes.

When you create a subnetwork a default route table is created automatically. We will leave it as is for private networks and create a new one for the public one:

Having selected a new table at the bottom of the page, we can see its components. Let us create a route to Internet 0.0.0.0/24, which passes through our Internet gateway:

An associate our public network with this table:

Now we run an instance in our public subnetwork and assign it an EIP, and a private address 10.50.3.254 (we can control them after all!!!) We should get the following results:

First, let us create an instance in EC2. Technically, we must check the VPC box and choose the required network from a drop-down menu:

While the instance launches we allocate an EIP for  VPC. This is done the usual way, we just have to select VPC, instead of EC2:

Network Interfaces

Another thing created automatically on launch of a new instance in VPC is a network interface.

Network Interface is a virtual device, enabling you to manage physical interfaces of an instance. Network interfaces are managed by means of EC2 console.

Let us see, what we got now:

It is time to try to assign a new private address to the interface. Our interface now has two virtual addresses. Finally, we assign the EIP to the interface:

Done. Our instance can be accessed the ‘outside’:

$ telnet 107.23.210.139 22

Trying 107.23.210.139...

Connected to 107.23.210.139.

Escape character is '^]'.

SSH-2.0-OpenSSH_5.3

NAT Instance

As mentioned earlier, private subnetworks can have Internet access via NAT only. Why don’t we arrange this for our new instance? Also in order to access VPC, I usually setup OpenVP in such cases.

1. Allow forwarding in /etc/sysctl.conf:

net.ipv4.ip_forward = 1

2. Allow forwarding in iptables:

iptables -t filter -A FORWARD -s 10.50.0.0/16 -j ACCEPT

iptables -t filter -A FORWARD -d 10.50.0.0/16 -j ACCEPT

iptables -t nat -A POSTROUTING -s 10.50.0.0/16 -o eth0 -j MASQUERADE

Install and configure an OpenVPN server.

Suppose, we did all of the above and can finally connect to a network.

Private Networks

How can our private subnetworks understand they should go on the Internet? The answer is… easy! Using the same old routes. We take the existing table and slightly update it, choosing our NAT instance as a gateway for Internet 0.0.0.0/0:

Now we just have to associate this table with two remaining subnetworks:

Conclusion

This is it! We can now create instances on our private subnetworks, which will be available via OpenVPN only. You can provide direct access to them using an outside Elastic Load Balancer. The subnetwork can later take the following simple, yet interesting shape:

VPC has many more options, including AWS-maintained VPN access to your datacenter and lots of other small nuances . The general conclusion is, however, quite clear. VPC enables you to create a failsafe private cloud based on AWS.