AWS Direct Connect with DataVita
I've been working with the AWS platform on and off for around 6 years and it has something which I have enjoyed digging around in the services it provides and playing around. Setting up VPC's in various locations, and the designing networks attached to them in various layouts.
When I worked at Kinly, the networking which I was using there was getting more complex and I felt that the network simplicity was being diluted and I explored transit gateways, which was something I couldn’t do before until then. This opened avenues for Kinly to keep traffic internal and secure whilst still going over various regions etc. and keeping that balance of simplicity which, I was looking for. Ideally, always attempting to stick to that K.I.S.S method
Starting at DataVita I knew that they had access to the Direct Connects, and was hoping for the opportunity to explore this, and today was my chance. Again, Direct Connect is a service provided by AWS which will allow the user to have a “private” connection between one point (for example DataVita DC) to an AWS Region. The setup which I done we applied to “eu-west-2” which is the London Region of the AWS platform. I also thought it would be a good idea to start very straightforward and work my way from there by starting to just connect a DataVita environment, which is our Cloud Tenant to an AWS VPC which is based in London.
Transit
The transit which we I have used for this instance is from Commsworld. Which have peering connections between DataVita and the AWS Service. The transit map will look something like this. Highlighted in Green (not the actual path just a visual representation, image taken from Commsworld website and edited accordingly)
From our Datacentre in Glasgow. The private connection goes down to the main hub in Manchester. This then goes into Equinix network before entering London AWS through the Equinix partner. The actual physical cable layout is highlighted in green. The private line which was provided to me was a 50Mbps line between my DataVita cloud tenant and AWS.
Although this connection is typically layer 2. AWS requires you to provide a Layer 3 approach to this. There is, however, the ability to stretch layer 2 networks over on-prem or from the DC over to AWS. Documentation on this can be found here
A simple network design was created for this setup and the following IP Configuration was used. Again, I am attempting to make this as straightforward and simple as possible at this point.
AWS VPC – 10.10.0.0/24
DataVita Cloud – 10.0.0.0/24
Server at DataVita – 10.0.0.10
EC2 instance – 10.10.0.55
To allow communication between the VPC and AWS environment. You will need to setup a Virtual Interface on AWS and have a Customer Gateway which can use BGP. Although this will work without BGP, it is a recommend step. In my case I am using a ASAv with an IP address of 10.0.0.1 as the gateway. This also has BGP capabilities as well.
In this guide. I have already agreed the direct connect setup with Commsworld and accepted it through the AWS account. Typically, to setup the direct connect. You will just need the AWS account number, and the Region to attach your direct connection to your AWS.
This can be found within your AWS Console > Services > Direct Connect > Connections
Once you have the connection available, you can create a Virtual Private Gateway. This is part of the VPC service, can be found at AWS Console > Services > VPC > Virtual Private Network (VPN) > Virtual Private Gateway
Create the Gateway by Providing a Name Tag
You will then need to attach this gateway to your VPC.
You will then need to create a Virtual Interface which can be found at AWS Console > Services > Direct Connect > Virtual Interfaces
Choosing the following options
When the Interface is created. There is an option within the top right which you can choose to download a sample configuration for the other side of the connection. This can be helpful if you need assistance. However, the configs are slightly limited to Cisco, Juniper, and Palo Alto equipment, and even then, that is further reduced as well. Once you have configured the other side of the connection you could side something like this.
Setup up your routes, between the two sides, since you’re using BGP it should auto populate, but you will need to tell AWS this on your VPC.
Services > VPC > Routing Tables > Highlight the routing table you want > Route Propagation > Edit route Propagation
?Click the enable checkbox and save. This will automatically populate your routing table.
This should now allow the routing and communication between the two. This can be tested, if you have allowed PING between the two (for example) and you can see if the two servers can talk.
I setup a few bits and pieces just to monitor the end-to-end latency of the connection just to verify exactly how low it will go. This appears to be consistent averaging around 12ms between DataVita DC. This was monitored using Grafana as the dashboard, Influxdb as the time series database and telegraf as the agent running on the server. The EC2 instance itself is a t2.micro.
Considering that this is going from Glasgow to London. To me, this is good latency. Will be doing more testing with the direct connect to see what else I can do with it from the DataVita DC. However, really pleased that I can play around with something like this.
If there are individuals, or companies which are looking for real use case for this. I have listed a few below and can discuss them in further detail if you want to know more.
This may need further work as you will need to investigate the failover of WAN IPs etc. Unless you are looking for something which is for local only
Extend your VMWare environment to AWS using direct connect
Will need to consider RPO/RTO as this point and what you are looking to recover
Having a private access to your AWS environment without the need of site-to-site VPN’s
Moving heavy workloads into the cloud
Keeping the traffic local
Need to push data to AWS to do data processing using spot instances
Ideal if you have remote office workers, or have something like a BYOD policy