Posted by Brian Bradley on Aug 2, 2022 10:00:00 AM
When forming a hybrid cloud to consume cloud-hosted services, secure and reliable network connectivity is an obvious requirement. While VPN is a great way to get started for private PaaS/IaaS, it is still at the mercy of the dynamic and vulnerable nature of the enterprise internet service provider’s Public Internet BGP routing exchanges. This can lead to the occasional sub-optimal routing, with latency and jitter impacting the services the enterprise is consuming. This also impacts non-VPN, publicly reachable, SaaS-delivered services hosted in the cloud. The solution to all these problems is a Direct Connect (DX) circuit to AWS with BGP peering.
DX can be set up between your enterprise WAN and AWS. Assuming you are consuming SaaS and/or internal enterprise-facing PaaS/IaaS services hosted in AWS, let's break down how to connect them back to your enterprise using a DX.
First, get an inventory of all enterprise-consumed services, as this will determine what type of Virtual Interface (VIF) you will need to establish. SaaS uses Public VIFs and internal enterprise-facing PaaS/IaaS use Private or Transit VIFs. They also use public and private IP address space, respectively.
Next, we need to select the type of DX that is most appropriate for our enterprise use case. There are four types:
- Hosted from the enterprise co-location within a cloud exchange
- Direct from the enterprise co-location to AWS
- Hosted from the existing private WAN/MPLS provider
- Private WAN extension to a cloud exchange/AWS from your enterprise
The SLAs are established at this point based on the type of DX connectivity selected from the above options. This could be a simple WAN SLA for a direct DX circuit, or a hybrid SLA comprised of a circuit SLA, and hosting/exchange provider SLA within the cloud exchange for the fiber interconnect back to your network equipment. This provides the reliability and accountability that enterprises are looking for when implementing this type of premium connectivity.
Now it’s time to set up your VIFs. In the case of a Private VIF, you will attach it to a Virtual Gateway (VGW) and a Transit VIF will attach to a Transit Gateway (TGW). In both cases, BGP routing will be set up and enterprise Private IP connectivity will be established. For additional security or compliance requirements, this connection can be encrypted using a VPN across the DX using only RFC 1918 private IP space.
A public VIF will provide the ability to consume all the AWS-peered BGP-advertised Public IP space in an AWS region, continent or globally without transiting the public internet. This can be filtered using BGP community strings when BGP routing is established with AWS for additional control along with route filtering on the enterprise router or firewall (recommended) using route maps with prefix lists for known services that are consumed via SaaS. The AWS-hosted public IP space from your SaaS application provider can be obtained by contacting them and asking for it, or more specifically the regions in which they host the SaaS application.
As an added bit of flexibility, your enterprise can run both public and private VIFs across the same DX, providing an enterprise-specific cloud on-ramp, with SLAs that provide insight and accountability back to the business while improving the performance and availability of cloud-hosted network services for users.
Contact the ConvergeOne Digital Infrastructure (Advisory, Cloud, Data Center, Network and Cyber Security) teams when your enterprise is ready, and we can help you with secure network cloud service consumption using a DX with Amazon-peered BGP.