# Hybrid connectivity
This section focuses on securely connecting your cloud resources with your on-premises data centers. There are three approaches for enabling hybrid connectivity:
+ **One-to-one connectivity** — In this setup, a VPN connection and/or Direct Connect private VIF is created for every VPC. This is accomplished by using the virtual private gateway (VGW). This option is great for small numbers of VPCs, but as a customer scales their VPCs, managing hybrid connectivity per VPC can become difficult.
+ **Edge consolidation** — In this setup, customers consolidate hybrid IT connectivity for multiple VPCs at a single endpoint. All the VPCs share these hybrid connections. This is accomplished by using AWS Transit Gateway and the Direct Connect gateway.
+ **Full mesh hybrid consolidation** — In this setup, customers consolidate connectivity for multiple VPCs at a single endpoint using CloudWAN, built on AWS Transit Gateway. This is a full policy-based approach to networking in one or more AWS accounts, represented in code. At this time, using Direct Connect for edge connectivity requires peering Transit Gateway to CloudWAN.
# VPN
There are various ways to set up VPN to AWS:
![\[A diagram depicting Site-to-Site VPN options\]](http://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/aws-vpn-options.png)
+ **Option 1: Consolidate VPN connectivity on Transit Gateway** — This option leverages the Transit Gateway VPN attachment on Transit Gateway. Transit Gateway supports IPsec termination for site-to-site VPN. Customers can create VPN tunnels to the Transit Gateway, and can access the VPCs attached to it.Transit Gateway supports both Static and BGP-based Dynamic VPN connections. Transit Gateway also supports [Equal-Cost Multi-Path](https://en.wikipedia.org/wiki/Equal-cost_multi-path_routing) (ECMP) on VPN attachments. Each VPN connection has a maximum of 1.25-Gbps throughput per tunnel. Enabling ECMP allows you to aggregate throughput across VPN connections, allowing to scale beyond the default maximum limit of 1.25 Gbps. In this option, you pay for [Transit Gateway pricing](https://aws.amazon.com/transit-gateway/pricing/) as well as [Site-to-Site VPN pricing](https://aws.amazon.com/vpn/pricing/). AWS recommendeds using this option for VPN connectivity. For more information, refer to the [Scaling VPN throughput using AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/scaling-vpn-throughput-using-aws-transit-gateway/) blog post.
+ **Option 2: Terminate VPN on Amazon EC2 instance** — This option is leveraged by customers in edge cases when they want a particular vendor software feature set (such as [Cisco DMVPN](https://www.cisco.com/c/en/us/products/collateral/security/dynamic-multipoint-vpn-dmvpn/data_sheet_c78-468520.html) or Generic Routing Encapsulation (GRE)), or they want operational consistency across various VPN deployments. You can use the transit VPC design for edge consolidation, but it is important to remember that all the key considerations from the [VPC to VPC connectivity](vpc-to-vpc-connectivity.md) section for transit VPC are applicable to hybrid VPN connectivity. You are responsible for managing high availability, and you pay for EC2 instance as well as any vendor software licensing and support costs.
+ **Option 3: Terminate VPN on a virtual private gateway** **(VGW)** — This AWS Site-to-Site VPN service option enables a one-to-one connectivity design where you create one VPN connection (consisting of a pair of redundant VPN tunnels) per VPC. This is great way to get started with VPN connectivity into AWS, but as you scale the number of VPCs, managing a growing number of VPN connections can become challenging. Therefore, edge consolidation design leveraging Transit Gateway will eventually be a better option. VPN throughput to a VGW is limited to 1.25 Gbps per tunnel and ECMP load balancing is not supported. From a pricing perspective, you only pay for AWS VPN pricing, there is no charge for running a VGW. For more information, refer to [Site-to-Site VPN Pricing](https://aws.amazon.com/vpn/pricing/) and [Site-to-Site VPN on virtual private gateway](https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html).
+ **Option 4: Terminate VPN connection on client VPN endpoint** — AWS Client VPN is a managed client-based VPN service that enables you to securely access your AWS resources and resources in your on-premises network. With Client VPN, you can access your resources from any location using an OpenVPN or AWS provided VPN client. By setting up a Client VPN endpoint, clients and users can connect to establish a Transport Layer Security (TLS) VPN connection. For more information, refer to the [AWS Client VPN documentation](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/what-is.html).
+ **Option 5: Consolidate VPN connection on AWS Cloud WAN** — This option is similar to the first option in this list, but it uses the CloudWAN fabric to programmatically configure VPN connections through the network policy document.
# Direct Connect
While VPN over internet is a great option to get started, internet connectivity may not be reliable for production traffic. Because of this unreliability, many customers choose [Direct Connect](http://aws.amazon.com/directconnect/). Direct Connect is a networking service that provides an alternative to using the internet to connect to AWS. Using Direct Connect, data that would have previously been transported over the internet is delivered through a private network connection between your facilities and AWS. In many circumstances, private network connections can reduce costs, increase bandwidth, and provide a more consistent network experience than internet-based connections. There are several ways to use Direct Connect to connect to VPCs:
![\[A diagram depicting ways to connect your on-premises data centers using Direct Connect\]](http://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/connect-on-premises.png)
+ **Option 1: Create a private virtual interface (VIF) to a VGW attached to a VPC** — You can create 50 VIFs per Direct Connect connection, allowing you to connect to a maximum of 50 VPCs (one VIF provides connectivity to one VPC). There is one BGP peering per VPC. Connectivity in this setup is restricted to the AWS Region that the Direct Connect location is homed to. The one-to-one mapping of VIF to VPC (and lack of global access) makes this the least preferred way to access VPCs in the Landing Zone.
+ **Option 2: Create a private VIF to a Direct Connect gateway associated with multiple VGWs (each VGW is attached to a VPC) **— A Direct Connect gateway is a globally available resource. You can create the Direct Connect gateway in any Region and access it from all other Regions, including GovCloud (excluding China). A Direct Connect Gateway can connect to up to 20 VPCs (via VGWs) globally in any AWS account over a single private VIF. This is a great option if a Landing Zone consists of a small number of VPCs (ten or fewer VPCs) and/or you need global access. There is one BGP peering session per Direct Connect Gateway per Direct Connect connection. Direct Connect gateway is only for north/south traffic flow and does not permit VPC-to-VPC connectivity. Refer to [Virtual private gateway associations](https://docs.aws.amazon.com/directconnect/latest/UserGuide/virtualgateways.html) in the Direct Connect documentation for more details. With this option, the connectivity is not restricted to the AWS Region where the Direct Connect location is homed to. Direct Connect gateway is only for north/south traffic flow and does not permit VPC-to-VPC connectivity. An exception to this rule is when a supernet is advertised across two or more VPCs that have their attached VGWs associated with the same Direct Connect gateway and on the same virtual interface. In this case, VPCs can communicate with each other through the Direct Connect endpoint. Refer to [Direct Connect gateways documentation](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html) for more details.
+ **Option 3: Create a transit VIF to a Direct Connect gateway associated with Transit Gateway **— You can associate a Transit Gateway instance to a Direct Connect gateway by using a Transit VIF. Direct Connect now supports connections to Transit Gateway for all port speeds, providing a more cost-effective choice for Transit Gateway users when high-speed connections (greater than 1Gbps) are not required. This enables you to use Direct Connect at speeds of 50, 100, 200, 300, 400, and 500 Mbps connecting to Transit Gateway. Transit VIF allows you to connect your on-premises data center to up to six Transit Gateway instances per Direct Connect gateway (which can connect to thousands of VPCs) across different AWS Regions and AWS accounts over single transit VIF and BGP peering. This is the simplest setup among the options for connecting multiple VPCs at scale, but you should be mindful of the [Transit Gateway quotas](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-limits.html). One key limit to note is that you can advertise only [200 prefixes](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html) from a Transit Gateway to on-premises router over the transit VIF. With the previous options, you pay for Direct Connect pricing. For this option, you also pay for the Transit Gateway attachment and data processing charges. For more information, refer to the [Transit Gateway Associations on Direct Connect documentation](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-transit-gateways.html).
+ **Option 4: Create a VPN connection to Transit Gateway over Direct Connect public VIF **— A public VIF allows you to access all AWS public services and endpoints using the public IP addresses. When you create a VPN attachment on a Transit Gateway, you get two public IP addresses for VPN endpoints at the AWS side. These public IPs are reachable over the public VIF. You can create as many VPN connections to as many Transit Gateway instances as you want over Public VIF. When you create a BGP peering over the public VIF, AWS advertises the entire [AWS public IP range](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) to your router. To ensure that you only permit certain traffic (for example, allowing traffic only to the VPN termination endpoints) you are advised to use a firewall on-premises facilities. This option can be used to encrypt your Direct Connect at the network layer.
+ **Option 5: Create a VPN connection to Transit Gateway over Direct Connect using Private IP VPN** — Private IP VPN is a feature that provides customers the ability to deploy AWS Site-to-Site VPN connections over Direct Connect using private IP addresses. With this feature, you can encrypt traffic between your on-premises networks and AWS through Direct Connect connections without the need for public IP addresses, thus enhancing security and network privacy at the same time. Private IP VPN is deployed on top of Transit VIFs, so it allows you to use Transit Gateway for centralized management of customers’ VPCs and connections to the on-premises networks in a more secured, private, and scalable manner.
+ **Option 6: Create GRE tunnels to Transit Gateway over a transit VIF** – The Transit Gateway Connect attachment type supports GRE. With Transit Gateway Connect, SD-WAN infrastructure can be natively connected to AWS without having to set up IPsec VPNs between SD-WAN network virtual appliances and Transit Gateway. The GRE tunnels can be established over a transit VIF, having Transit Gateway Connect as the attachment type, providing higher bandwidth performance compared to a VPN connection. For more information, refer to the [Simplify SD-WAN connectivity with AWS Transit Gateway Connect](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-sd-wan-connectivity-with-aws-transit-gateway-connect/) blog post.
The “transit VIF to Direct Connect gateway” option might seem to be the best option because it lets you consolidate all your on-premises connectivity for a given AWS Region at a single point (Transit Gateway) using a single BGP session per Direct Connect connection; however, some of the limits and considerations around this option might lead you to use both private and transit VIFs in conjuction for your Landing Zone connectivity requirements.
The following figure illustrates a sample setup where Transit VIF is used as a default method for connecting to VPCs and a private VIF is used for an edge use case where exceptionally large amounts of data must be transferred from an on-premises Data Center to the media VPC. Private VIF is used to avoid Transit Gateway data processing charges. As a best practice, you should have at least two connections at two different Direct Connect locations for [maximum redundancy](https://aws.amazon.com/directconnect/resiliency-recommendation/)—a total of four connections. You create one VIF per connection for a total of four private VIFs and four transit VIFs. You can also create a VPN as backup connectivity to Direct Connect connections.
With the “Create GRE tunnels to Transit Gateway over a transit VIF” option, you get the capability to natively connect your SD-WAN infrastructure with AWS. It eliminates the need to setup IPsec VPNs between SD-WAN network virtual appliances and Transit Gateway.
![\[A diagram depicting a sample reference architecture for hybrid connectivity\]](http://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/hybrid-connectivity-ra.png)
Use the Network Services account for creating Direct Connect resources enabling demarcation of network administrative boundaries. The Direct Connect connections, Direct Connect gateways, and Transit Gateways can all reside in a Network Services account. To share the Direct Connect connectivity with your Landing Zone, simply share the Transit Gateway through AWS RAM with other accounts.
## MACsec security on Direct Connect connections
Customers can use MAC Security Standard (MACsec) encryption (IEEE 802.1AE) with their Direct Connect connections for 10 Gbps and 100 Gbps dedicated connections at [select locations](https://aws.amazon.com/directconnect/locations/). With [this capability](https://docs.aws.amazon.com/directconnect/latest/UserGuide/MACsec.html), customers can secure their data on the layer 2 level, and Direct Connect delivers point-to-point encryption. To enable the Direct Connect MACsec feature, ensure that the [MACsec pre-requisites](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-mac-sec-getting-started.html#mac-sec-prerequisites) are met. Because MACsec protects links on a hop-by-hop basis, your device must have a direct layer 2 adjacency with our Direct Connect device. Your last-mile provider can help you verify that your connection will work with MACsec. For more information refer to [Adding MACsec security to AWS Direct Connect connections](https://aws.amazon.com/blogs/networking-and-content-delivery/adding-macsec-security-to-aws-direct-connect-connections/).
## Direct Connect resiliency recommendations
With Direct Connect, customers can achieve highly resilient connectivity into their Amazon VPCs and AWS resources from their on-premises networks. It is best practice that customers connect from multiple data centers to eliminate any single point physical location failures. It is also recommended that, depending on the type of workloads, customers utilize more than one Direct Connect connection for redundancy.
AWS also offers the Direct Connect Resiliency Toolkit, which provides customers with a connection wizard with multiple redundancy models; to help them determine which model works best for their service level agreement (SLA) requirements and design their hybrid connectivity using Direct Connect connections accordingly. For more information, refer to [Direct Connect Resiliency Recommendations](https://aws.amazon.com/directconnect/resiliency-recommendation/).
## Direct Connect SiteLink
Previously, configuring site-to-site links for your on-premises networks was only possible by using direct circuit buildout through dark fiber or other technologies, IPSEC VPNs, or by using third-party circuit providers with technologies such as MPLS, MetroEthernet, or legacy T1 circuits. With the advent of SiteLink, customers can now enable direct site-to-site connectivity for their on-premises location that terminate at an Direct Connect location. Use your Direct Connect circuit to provide site-to-site connectivity without having to route traffic through your VPCs, bypassing the AWS region completely.
Now, you can create global, reliable, and pay-as-you-go connections between the offices and data centers in your global network by sending data over the fastest path between Direct Connect locations.
![\[A diagram Direct Connect SiteLink\]](http://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/direct-connect-sitelink.png)
When using SiteLink, you first connect your on-premises networks to AWS at any of over 100 Direct Connect locations worldwide. Then, you create virtual interfaces (VIFs) on those connections and enable SiteLink. Once all VIFs are attached to the same Direct Connect gateway (DXGW), you can start sending data between them. Your data follows the shortest path between Direct Connect locations to its destination, using the fast, secure, and reliable AWS global network. You don’t need to have any resources in any AWS Region to use SiteLink.
With SiteLink, the DXGW learns IPv4/IPv6 prefixes from your routers over SiteLink enabled VIFs, runs BGP best path algorithm, updates attributes such as NextHop and AS\$1Path, and re-advertises these BGP prefixes to the rest of your SiteLink-enabled VIFs associated with that DXGW. If you disable SiteLink on a VIF, the DXGW will not advertise the learned on-premises prefixes over this VIF to the other SiteLink-enabled VIFs. The on-premises prefixes from a SiteLink disabled VIF is only advertised to the DXGW Gateway associations, such as AWS Virtual Private Gateways (VGWs) or Transit Gateway (TGW) instances associated with the DXGW.
![\[A diagram showing Sitelink traffic flow examples\]](http://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/full-mesh-connectivity.png)
SiteLink allows customers to use the AWS global network to function as a primary or secondary/backup connection between their remote locations, with high bandwidth and low latency, with dynamic routing to control which locations can communicate with each other and with your AWS regional resources.
For more information, refer to [Introducing Direct Connect SiteLink](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-direct-connect-sitelink/).