Warakorn - Fotolia
Virtualization administrators who are hesitant to migrate workloads to the public cloud for security or control reasons should consider Amazon Virtual Private Cloud because it uses public cloud resources, provides isolation and offers design freedom.
When the cloud was new, organizations flocked to Amazon Web Services (AWS) because it offered an easy way to provision and decommission virtual servers. This provided the flexibility of a Linux or Windows system without the hassle of setting up a physical machine. But many organizations didn't consider the networking implications of running a VM with a service provider, so they typically used a public IP address that made the system accessible from anywhere.
Such simplicity is convenient, but it isn't practical or secure, especially once an organization needs to expand its AWS usage to dozens of VMs accessing Simple Storage Service (S3), Relational Database Service (RDS) and other services to run enterprise applications. Real-world cloud usage requires something like the private network and subnetting flexibility that's commonplace in enterprise data centers, which is precisely what Amazon Virtual Private Cloud (VPC) provides.
Since the days of N-tier applications, enterprise network topologies have relied on the ability to segment applications and users into different subnets, each with a uniquely tailored security policy that isolates sensitive data from systems that external users access.
A similar ability to isolate and segment various applications, services, user groups and departments into controlled security zones is critical if cloud services such as AWS are to supplement and replace on-premises infrastructure. Amazon VPC provides this flexibility and more because it uses virtual network services that IT can spin up instantly, reconfigure quickly and scale easily.
The name Virtual Private Cloud is somewhat deceptive because it's about creating private networks, not dedicated clouds, despite the fact that having complete control over a network sandbox makes it seem like a private cloud. Essentially, VPCs are a vessel for other AWS services such as Elastic Compute Cloud (EC2), Elastic Block Store and RDS.
Key features of Amazon Virtual Private Cloud
Amazon VPC provides full control over an isolated virtual network space that delivers the same configuration flexibility as a private data center network. Its key features include:
- a virtual router that supports isolated private networks, such as RFC 1918 using 10.0.0.0/8, 172.16.0.0/16 or 192.168.0.0/24 addressing, with full control over subnetting and the Classless Inter-Domain Routing (CIDR) blocks within the umbrella address space;
- available public, routable IP addresses with network address translation (NAT) using a virtual internet gateway;
- control over inbound and outbound traffic using a virtual firewall and access control lists (ACLs) that can be customized to individual instances;
- the ability to assign static, persistent IPs to instances that remain after stops and restarts;
- support for multiple IP addresses per instance, including more than one network interface, such as an instance, that can simultaneously sit in multiple VPCs;
- the ability to change an instance's security group membership while it's running; and
- support for dedicated EC2 hosts and instances.
Aside from network configuration flexibility, VPCs greatly simplify accessing AWS services from on-premises data centers because users can create private connections using VPC endpoints that don't require NAT and an internet gateway. Endpoints also provide more granular security to AWS resources, such as the ability to create a policy that restricts access to particular S3 buckets.
VPCs are so critical to the way AWS works that it's impossible to use AWS without them; when admins create an AWS account, it comes with a default VPC, which hosts any EC2, RDS, Elastic Load Balancing or other services they launch. Most enterprise AWS users will want to create custom VPCs that support more complex, segmented network designs.
Aside from their inherent adaptability to various network security needs, VPCs are critical to many enterprise usage scenarios, such as hosting public-facing websites and web applications that might need to access sensitive data on a separate protected subnet.
VPCs also help to build multi-tier applications that partition and control traffic and user access between different security zones. They can be used to create hybrid cloud applications where some components, such as the public web UI, are hosted on AWS and others -- enterprise databases or a content management system -- run on premises.
Another common VPC scenario is using AWS as a disaster recovery or business continuity site that duplicates the applications and data of on-premises systems.
Advantages and disadvantages of Amazon Virtual Private Cloud
Using VPCs with EC2 and other AWS services is non-negotiable, so the real issue is the benefits of extensive VPC usage with multiple subnets and security groups. There's little downside in return for great flexibility in network design and security policies.
Aside from the ability to partition a vast private address space into logical chunks with ACLs controlling traffic flow between them, VPCs also provide:
- More external connectivity options with support for AWS Direct Connect -- private, high-bandwidth physical circuits connecting on-premises data centers or private systems at a colocation facility to AWS -- and PrivateLink, aka VPC Endpoints providing private network connectivity between a customer VPC and select AWS and third-party services hosted on AWS; for example, in the Marketplace.
- The ability to bridge on-premises and AWS infrastructure without a Direct Connect circuit using virtual private network (VPN) connections. On the AWS side, the VPN can be an AWS service -- managed VPN or VPN CloudHub -- or a third-party virtual appliance, whereas on premises or at remote sites, the VPN termination point can be either a physical or virtual appliance.
- The option of extending on-premises security directories and policies into AWS by connecting Active Directory (AD) to the AWS Directory Service. Admins can also migrate the on-premises AD installation to AWS.
- The ability to use EC2 dedicated instances that run on physical hardware dedicated to a particular customer -- they must operate in a VPC, though.
- The option of creating private connections between VPCs in different AWS Availability Zones (AZs) using different accounts, even across regions, also known as VPC peering.
- The VPC management interface is part of the AWS management console. It provides a single UI for network and server configuration.
Despite all these features, implementing VPCs doesn't need to complicated; indeed, AWS provides a wizard to build simple configurations. That said, more sophisticated network designs that would be typical of a large enterprise do require intricate, multistep configurations that are best left to experienced network professionals.
Another potential disadvantage is capacity limits on various VPC parameters. For example, an AWS account can only have five VPCs per region with five IPv4 subnets per VPC. Similarly, each VPC only supports 200 ACL rules, with a maximum of 50 ACLs per subnet. SMB users won't encounter these, but some large enterprises might, and they should design accordingly.
Amazon VPC pricing explained
VPCs are free to create, but they are subject to the same data transfer fees as every other AWS service. There are additional charges for external VPN connections to VPC and NAT gateways -- such as bridging some VPCs to the internet with a publicly routable address -- which are detailed on the AWS product page.
Here is a summary: VPN connections, i.e., IPsec over the internet, are 5 cents (U.S.) per connection hour in most cases. PrivateLink VPC endpoints are 1 cent per hour plus 1 cent per transferred GB in most cases. A NAT gateway is 45 cents per hour plus 45 cents per transferred GB.
Amazon Virtual Private Cloud best practices
VPCs can be the foundation for extremely sophisticated network designs, meaning they require the same degree of planning for subnet and address strategies as data center networks. As AWS outlines, VPC users should also liberally use subnets to separate applications with different routing and security requirements.
In addition, use network ACLs to control inbound and outbound traffic to each VPC subnet, but don't overdo it. Use ACLs as roadblocks, not granular checkpoints, because they quickly become a complex management headache. Instead, use security groups tied to server and application roles to fine-tune policies.
Don't make subnets too large, but also leave spare capacity for future expansion. AWS reserves five addresses per subnet and admins will need different CIDR blocks for each AZ should the subnet span zones.
The AWS Quick Start defaults are a good starting point because a 10.0.0.0/17 -- class A with a 17-bit mask -- network leaves room for 32,000 hosts. Avoid overlapping CIDR blocks and be sure to use NAT gateways for redundancy.