Starting your cloud networking journey can seem overwhelming. Especially if you are accustomed to the traditional on-premises way of provisioning hardware and managing and configuring networks. Having a good understanding of core networking concepts like IP addressing, TCP communication, IP routing, security, and virtualization will help you as you begin gaining familiarity with cloud networking on AWS. In the following sections, we answer common questions about cloud networking and explore best practices for building infrastructure on AWS.
What is cloud networking?
Similar to traditional on-premises networking, cloud networking provides the ability to build, manage, operate, and securely connect your networks across all your cloud environments and distributed cloud and edge locations. Cloud networking allows you to architect infrastructure that is resilient and highly available, helping you to deploy your applications faster, at scale, and closer to your end users when you need it.
Why is where I deploy important?
When you open a website or use an application, data and requests need to travel from your computer or phone to a server that is hosting the website or application, and back again to you. This is usually done over a combination of different mediums, such as over Wi-Fi to your router at home, from there to your ISP by way of fiber, cable, ADSL, 5G, etc. Once it reaches the ISP, they in turn connect to a larger network. At some point, it is likely that your data travels through one of the many undersea fiber cables. The speed of light determines what the quickest speed through these cables can be, limiting the fastest possible response—the light inside the cable also reflects off the side as it travels, so the total distance traveled is longer than the cable itself. As an example, one of the cables between Japan and the US West coast is 21,000km in total length, which means light traveling at 299,792,458 m/s would take ~70ms to cross the total length of the cable, slowing down the website or application as multiple calls go back and forth. In extreme examples, the time can be much higher due to not only the distance traveled, but network congestion between points along the way, with responses taking multiple seconds to complete.
With the cloud, you can expand to new geographic regions and deploy globally in minutes. For example, AWS has infrastructure all over the world, so developers can deploy applications in multiple physical locations with just a few clicks. By putting your applications in closer proximity to your end users, you can reduce latency and improve the user experience
AWS Cloud infrastructure is built around AWS Regions and Availability Zones. A Region is a physical location in the world where we have multiple Availability Zones. An Availability Zone consists of one or more discrete data centers, each with redundant power, networking, and connectivity, housed in separate facilities. These Availability Zones offer you the ability to operate production applications and databases that are more highly available, fault tolerant, and scalable than would be possible from a single data center.
What is Amazon VPC?
With Amazon Virtual Private Cloud (Amazon VPC), you can provision a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address ranges, creation of subnets, and configuration of route tables and network gateways. You can also create a hardware virtual private network (VPN) connection between your corporate data center and your VPC, allowing you to connect servers between the two as if they were on the same network.
You can easily customize the network configuration for your VPC based on your requirements. A VPC spans a whole Region, and subnets are used to specify IP address ranges inside Availability Zones inside the Region to allocate to virtual machines and other services. For example, you can create a public subnet for your web servers that has access to the internet, and place your backend systems, such as databases or application servers, in a private subnet with no internet access. You can use multiple layers of security, including security groups and network access control lists, to help control access to Amazon EC2 instances in each subnet.
The following features help you configure a VPC to provide the connectivity that your applications need:
Getting started with Amazon VPC
How do resources in my Amazon VPC communicate?
VPCs gives you full control over your virtual networking environment, including resource placement, connectivity, and security. Get started by setting up your VPC in the AWS Management Console. Next, add resources to it such as Amazon EC2 and Amazon Relational Database Service (Amazon RDS) instances. Finally, define how your VPCs communicate with each other across accounts, Availability Zones, or Regions.
In a VPC you can use both IPv4 and IPv6 addressing. With IPv4 you select and assign a VPC CIDR (Classless Inter-Domain Routing) block from a maximum size of /16 to a minimum size of /28. You can use any public addresses you own (in select Regions). We recommend you use private RFC 1918 addresses. Once you have a CIDR, you define subnets. Subnets can be between /16 and /28 in size and are bounded by Availability Zones. Each VPC subnet must be associated with a subnet route table.
As you create subnets, you must associate them with a main VPC route table. By default, this route table will only contain the local IPv4 and IPv6 CIDRs of the VPC. A subnet can only be associated with one subnet route table. A route table can have multiple subnet associations. The route tables are used to control traffic leaving the subnet. Each subnet has a VPC router. There is no single device for a VPC. The VPC software takes care of the routing for you. You can add more specific routes to provide traffic filtering for east/west traffic.
How can I connect to my Amazon VPC?You can connect your VPC to other networks, such as other VPCs, the internet, or your on-premises network. You can connect your Amazon VPC to:
Can I connect to other VPCs in different accounts?
Yes, assuming the owner of the other VPC accepts your peering connection request, you can peer to other VPCs in different accounts.
Sharing VPCs is useful when network isolation between teams does not need to be strictly managed by the VPC owner, but the account-level users and permissions must be. With a shared VPC, multiple AWS accounts create their application resources (such as EC2 instances) in shared, centrally managed Amazon VPCs. In this model, the account that owns the VPC (owner) shares one or more subnets with other accounts (participants). After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. Participants cannot view, modify, or delete resources that belong to other participants or the VPC owner. Security between resources in shared VPCs is managed using security groups, network access control lists (NACLs), or through a firewall between the subnets
AWS PrivateLink provides private connectivity between VPCs, AWS services, and your on-premises networks without exposing your traffic to the public internet. AWS PrivateLink makes it easy to connect services across different accounts and VPCs to significantly simplify your network architecture. This allows customers who may want to privately expose a service/application residing in one VPC (service provider) to other VPCs (consumer) within an AWS Region in a way that only consumer VPCs initiate connections to the service provider VPC. An example of this is the ability for your private applications to access service provider APIs.
AWS Transit Gateway
AWS Transit Gateway enables customers to connect thousands of VPCs. You can attach all your hybrid connectivity (VPN and Direct Connect connections) to a single Transit Gateway instance, consolidating and controlling your organization's entire AWS routing configuration in one place. Transit Gateway controls how traffic is routed among all the connected spoke networks using route tables. This hub-and-spoke model simplifies management and reduces operational costs because VPCs only connect to the Transit Gateway instance to gain access to the connected networks.
Transit VPC solution
Transit VPCs can solve some of the shortcomings of VPC peering by introducing a hub-and-spoke design for inter-VPC connectivity. In a transit VPC network, one central VPC (the hub VPC) connects with every other VPC (spoke VPC) through a VPN connection, typically by using BGP over IPsec. The central VPC contains EC2 instances running software appliances that route incoming traffic to their destinations using the VPN overlay. Transit VPC peering has the following advantages:
- Transitive routing is enabled using the overlay VPN network, allowing for a simpler hub-and-spoke design.
- When using third-party vendor software on the EC2 instance in the hub transit VPC, vendor functionality around advanced security, such as Layer-7 firewall/Intrusion Prevention System (IPS)/Intrusion Detection System (IDS), can be used. If customers are using the same software on-premises, they benefit from a unified operational/monitoring experience.
- The Transit VPC architecture enables connectivity that may be desired in some use cases. For example, you can connect an AWS GovCloud instance and Commercial Region VPC or a Transit Gateway instance to a Transit VPC and enable inter-VPC connectivity between the two Regions. Evaluate your security and compliance requirements when considering this option. For additional security, you may deploy a centralized inspection model using design patterns described later in this whitepaper.
NOTE: Transit VPC comes with its own challenges, such as higher costs for running third-party vendor virtual appliances on Amazon EC2, based on the instance size/family; limited throughput per VPN connection (up to 1.25 Gbps per VPN tunnel); and additional conﬁguration, management, and resiliency overhead (customers are responsible for managing the high availability and redundancy of EC2 instances running the third-party vendor virtual appliances).
What are some security best practices for your VPC?
The following best practices are general guidelines and don’t represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions.
- When you add subnets to your VPC to host your application, create them in multiple Availability Zones. An Availability Zone is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region. Using multiple Availability Zones makes your production applications highly available, fault tolerant, and scalable.
- Use network ACLs to control access to your subnets and use security groups to control traffic to EC2 instances in your subnets.
- Manage access to Amazon VPC resources and APIs using AWS Identity and Access Management (IAM) identity federation, users, and roles.
- Use Amazon CloudWatch with VPC flow logs to monitor the IP traffic going to and from network interfaces in your VPC.
For answers to frequently asked questions related to VPC security, see the Security and Filtering section in the Amazon VPC FAQs.
What are common VPC scenarios?
VPC with a single public subnet
The configuration for this scenario includes a VPC with a single public subnet, and an internet gateway to enable communication over the internet. We recommend this configuration if you need to run a single-tier, public-facing web application, such as a blog or a simple website.This scenario can also be optionally configured for IPv6. Instances launched into the public subnet can receive IPv6 addresses, and communicate using IPv6.
VPC with public and private subnets (NAT)
The configuration for this scenario includes a VPC with a public subnet and a private subnet. We recommend this scenario if you want to run a public-facing web application, while maintaining backend servers that aren't publicly accessible. A common example is a multi-tier website, with the web servers in a public subnet and the database servers in a private subnet. You can set up security and routing so that the web servers can communicate with the database servers.
The instances in the public subnet can send outbound traffic directly to the internet, whereas the instances in the private subnet can't. Instead, the instances in the private subnet can access the internet by using a network address translation (NAT) gateway that resides in the public subnet. The database servers can connect to the internet for software updates using the NAT gateway, but the internet cannot establish connections to the database servers.
This scenario can also be optionally configured for IPv6. Instances launched into the subnets can receive IPv6 addresses, and communicate using IPv6. Instances in the private subnet can use an egress-only internet gateway to connect to the internet over IPv6, but the internet cannot establish connections to the private instances over IPv6.
VPC with public and private subnets and AWS Site-to-Site VPN access
The configuration for this scenario includes a VPC with a public subnet and a private subnet, and a virtual private gateway to enable communication with your own network over an IPsec VPN tunnel. We recommend this scenario if you want to extend your network into the cloud and also directly access the internet from your VPC. This scenario enables you to run a multi-tiered application with a scalable web frontend in a public subnet, and to house your data in a private subnet that is connected to your network by an IPsec AWS Site-to-Site VPN connection.
This scenario can also be optionally configured for IPv6. Instances launched into the subnets can receive IPv6 addresses. We do not support IPv6 communication over a Site-to-Site VPN connection on a virtual private gateway; however, instances in the VPC can communicate with each other via IPv6, and instances in the public subnet can communicate over the internet via IPv6.
VPC with a private subnet only and AWS Site-to-Site VPN access
The configuration for this scenario includes a VPC with a single private subnet, and a virtual private gateway to enable communication with your own network over an IPsec VPN tunnel. There is no internet gateway to enable communication over the internet. We recommend this scenario if you want to extend your network into the cloud using AWS infrastructure without exposing your network to the internet.
This scenario can also be optionally configured for IPv6. Instances launched into the subnet can receive IPv6 addresses. We do not support IPv6 communication over an AWS Site-to-Site VPN connection on a virtual private gateway; however, instances in the VPC can communicate with each other via IPv6.