In our last post, we discussed different models of peering over the internet.
This is more or less what the internet infrastructure in Ireland has looked like for over twenty years. However, in recent years, a new service has arrived, also called “peering”, and it represents a very different type of relationship.
It’s a service of Cloud providers such as Amazon AWS and Microsoft Azure, and it arises from the fact that it’s possible to extend your own campus network into the cloud and place your cloud computing resources behind your campus firewall.
In general, traffic from cloud providers follows the same model as above; when we visit a website hosted in AWS or Azure, that traffic travels over the internet as we know it, via public peering, private peering or transit, the same as everything else. Traffic to Office 365 also follows this model, using either our dedicated 10Gbit/s connection to Microsoft or through one of our enormous 100Gbit/s connections to INEX. (All these connections come with failover built in; in extreme situations, we could still reach Microsoft, and everyone else, via transit.)
However, since your own cloud resources are (logically, if not physically) behind your firewall, that’s your internal traffic; it’s not out on the internet, and so the above models would not work.
Cloud providers offer two solutions to this problem.
VPN
If it’s private, and it’s on the internet – encrypt it.
This is the solution you might use with your laptop at home or on the road when you need access from behind your firewall. If you have a VPN endpoint in your campus, you can connect to this, and your private traffic is carried, encrypted, over the public internet. Once it’s decapsulated there, it appears to everyone else to be originating from inside your campus.
Cloud providers have adopted the same mechanism for providing connectivity – you can create a VPN endpoint as part of your internal cloud network, and instead of setting up the tunnel from your laptop, you create it from a router or other device on your campus. AWS does this with their Virtual Private Gateway and Azure with their VPN Gateway. These are both paid services.
Of course, tunnels have their limitations. In particular, the whole business of crafting and encrypting individual packets (rather than simply forwarding them on like a router) means that they become rather expensive to maintain as the amount of traffic increases. AWS supports VPNs up to 1.25Gbit/s at the time of writing, as does Azure on its highest tier.
Physical connections
So what if your traffic exceeds this? Tunnels don’t scale very well – wouldn’t it be great to have a physical connection instead?
These exist too. AWS offers Direct Connect and Azure offers ExpressRoute.
These aren’t cheap to implement; they require infrastructure that effectively keeps a channel open to the cloud provider at all times. There’s also some additional complexity – they require a particular routing setup in order to use them.
Microsoft uses that routing setup to also deliver Office 365 and public Azure traffic over the same connection; happily, in HEAnet, this is equivalent to what we already get over our private peering.
Which should I use?
The best thing about these setups is that there’s a clear progression. If you don’t need behind-the-firewall access to your cloud infrastructure, then HEAnet’s IP service already gives you excellent connectivity (including Office 365.)
If you do need access, but your bandwidth requirements aren’t too high, or you’re not sure what the requirements might be, then a VPN is an excellent first step.
And if the bandwidth usage, or other requirements, make a dedicated connection worth it, do let HEAnet know. We’d love to help.
Anna Wilson – HEAnet
