It’s an exciting day today as it has just been announced that Smart421 is an Amazon Web Services launch partner in the UK for the latest expansion of their Direct Connect offering. Up until today Direct Connect has only been available to certain regions in the US, but now UK customers can get the benefits of this improved connectivity as well. Smart421′s role as an AWS Solution Provider is to help customers reap those benefits by giving them a one-stop shop for full end-to-end connectivity from their premise(s) to the AWS EU region without relying on the Internet at all – except as a backup mechanism.

Our offering is actually a seamlessly managed combination of services from two parts of our parent company, the KCOM group. Smart421 provide an end-to-end experience for the customer and manage the provisioning of the AWS Direct Connect connection at Telecity Sovereign House in London, and we use our sister company Kcom to deploy and manage the “last mile” connection from Telecity to the customer’s premises. The immediate benefit to the customer is that they have one party responsible for a direct private connection from their premises to the cloud – not multiple suppliers to manage and triage etc.


I thought I’d just cover a few basic questions about Direct Connect that I’d expect to come up with customers…

Why would I want it?

The usual mechanism of accessing AWS is over the Internet, with user and/or administration traffic secured using a virtual private network (VPN). This gives privacy and authentication, but the network traffic is fundamentally still sharing your organisation’s Internet pipe and still going via the Internet along with everyone else’s traffic. Many of our customers have a default security policy that certain classes of network traffic must be deployed on a more private infrastructure, e.g. MPLS links etc – to give a greater degree of privacy, predictability and control, especially in terms of improved bandwidth, latency and availability.

Secondly, there is a perception issue with using the Internet – which often becomes more marked the further you move up the management chain :). In fact, when talking to customers this is a classic objection that I sometimes hear – “we’re not comfortable using the cloud over the Internet”. Well now you’ve got a real choice – we can deploy an end-to-end private connection to AWS when required.

Also, you might be shifting significant volumes of data into and out of your cloud deployment, e.g. if you are performing big data processing using Hadoop/Elastic Map Reduce etc, or frequent data replication for disaster recovery purposes when you are using AWS as a logical extension to your on-premise data centres. In these circumstances, having greater control and certainty over the end-to-end connection between your premises and the AWS deployment is attractive.

What are the benefits?

In a nutshell, the key benefit is that your traffic is no longer subject to the unpredictability of the general Internet, and so basic metrics such as band with and latency will be far more predictable. For the connection from the customer’s premises to Telecity in London these metrics will be subject to strict quality of service guarantees, i.e. a bandwidth of X (you choose) with a defined maximum latency and an SLA (service level agreement) for the connection. For the second half of the connection from Telecity to the EU region in Dublin, you can expect superior network characteristics but there is not an SLA that defines guaranteed bandwidth etc. The initial adopters of Direct Connect in the EU region can expect an amazingly good network service given the price point – and our expectation is that over time AWS will have to introduce a degree of throttling/bandwidth management in order to maintain service levels…

What will it cost me?

…which brings me on to the costs. The bottom line is that Direct Connect is amazingly good value in our opinion. For a 1Gb/s port at Telecity it’s of the order of $216/month – i.e. virtually nothing. Unless you have your “on-premise” servers co-located at Telecity, then the costs for the “last mile” connection backed up by a strong SLA back to the customer premises will be much more significant. So guess what – you get what you pay for – no surprise there! For organisations relatively close to Telecity Sovereign House in network terms (e.g. in London) this makes Direct Connect a no-brainer really once your AWS usage becomes significant in terms of business criticality or data volumes, and it’s still highly attractive for an UK-based organisation.

Where might all this be going?

Finally – I just wanted to finish on why we think this is a really exciting development. For the EU region, this is the first step on the road for Smart421 to be able to offer a truly end-to-end service management offering – backed by strong SLAs for the end-to-end network connection and the AWS deployment itself. Over time we expect AWS to enhance Direct Connect with QoS (quality of service) guarantees, and we’re delighted to be in there at the start.

cloud and seaDo the service level agreements (SLAs) offered by public cloud providers hold water? Or are they useless to a customer -and not worth the cyberspace they are written on? We decided to pick the cloud fraternity poster child – Amazon EC2 – review their current SLA offering (which is defined here), and then compare it with ‘traditional’ hosting vendors offerings.

First let’s review the Amazon EC2 SLA. We’re not offering a legal perspective here, but several things strike us as interesting about this:

  • The SLA does provide for some punitive damages in the sense that should the service availability be between 90% and 99.95%, Amazon would still have to pay out 10% of your payments to them.
  • If EC2 was only available 60% of the time, their liability would be limited to 10%.
  • In no way are the damages that Amazon pay out linked to your potential losses. If Amazon had a major outage that could cost you millions, they might only pay out a few thousand in compensation.
  • The definition of ‘unavailable’ that they use here could potentially allow you to claim service credits even when your application is functioning perfectly well if we’re reading the SLA correctly, because ‘region unavailable’ appears to mean that one (not all) of the availability zones within a region is down. For example, if there are two availability zones within your region – your application could be running in both of these zones, such that it fails over between them. You’d get credit if a zone went down even in the event of the application failing over to the backup zone – even though your app is still ‘up.
  • Availability is measured in 5 minute blocks, which implies that they exclude all 4 minute downtimes. 4 minutes is a long time for a critical system to be down.
  • The other angle on this is that the advantage of using EC2 is that it gives you much easier ways to recover from any outage that does occur (provided it doesn’t bring down the whole region, when things get a little trickier).

Having said all of that, how different is this arrangement from what traditional hosting providers offer?

The view from our Head of Service Management is that it looks fairly standard – the hosting providers we work with have similar offerings. One of them offers up to 50% off the monthly fee for poor availability which sounds great but when you read the small print it’s measured in quarterly periods so they can get away with a bad month so long as they have two good months in the same quarter. Amazon’s small print doesn’t look too pleasant from an admin point of view as you must claim within 30 days of the last outage, and have to provide evidence of the outage etc.

Service credits are things that procurement and legal departments like but IT departments can’t be bothered with them, as they cause too much hassle to claim back a small sum that doesn’t really hurt the supplier and doesn’t compensate the customer for the real loss. We have come across some companies who offer a service whereby they take 100% of the service fee if they meet service levels i.e. you don’t have to prove it or claim it, which is obviously more attractive.

Our conclusion is that Amazon have paid lip service to service credits, and have probably done enough to satisfy procurement/legal requirements but nothing to shout about.

Thanks are due to my colleagues Paul Russell and Andy Budd for their input on this material…

Further reading on this subject…


Get every new post delivered to your Inbox.

Join 1,084 other followers