We recently did a cost analysis where we considered outsourcing to Amazon’s EC2 (Elastic Computing Cloud) service and the topic of network performance monitoring among other issues came up. We considered the amount of bandwidth we would use as well as how we would monitor the quality of service our customers were gaining through our use of EC2 and the final decision was that Amazon EC2 was not of us.
Amazon EC2 services allow companies to create a server hosted by Amazon and manipulate it pretty much as if it were your own. Once configured, the server can either sit on the internet for remote access or a VPN can be setup to allow the Amazon hosted server to sit on your internal network. It is a great concept. To monitor network performance to and from the hosted server, we planned on installing the nProbe to monitor TCP connection times to all of our customers. This would allow us to trend metrics on round trip times (RTT) and gain metrics on the Cisco IP SLA monitors used to verify acceptable connection times.
The nProbe, similar to Cisco’s performance monitoring Flexible NetFlow technology for medianets, watches TCP handshakes to provide metrics on RTT. Understandably this technology is not ideal for long lived TCP connections as a 2nd TCP hand shake doesn’t occur during a long lived connection. In our implementation however, nearly all connections are short lived hence a technology leveraging TCP handshakes to calculate a RTT works fine if not ideal because the RTT measured is of the actual end user connection and not a synthetic transaction like when using IP SLA monitors. There is a great white paper on calculating latency with NetFlow and TCP flags.
Imagine leveraging a cloud service like salesforce.com and being able to gain metrics on every TCP connection. You would be able to gain insight on which remote offices, subnets and individuals within those groups are seeing the worse connection times. Being a network traffic monitoring company, we have grown accustom to always having this type of insight at our finger tips. The more we looked at the Amazon EC2 service offering the more attractive it became until we started crunching the numbers.
Because we maintain a network traffic baseline of current traffic patterns, we were able to calculate the Amazon EC2 costs times our expected bandwidth use for an entire year. The final figures were in favor of us buying a bigger server and having it hosted at our local service provider. We learned that although Amazon’s Elastic Computing Cloud is an attractive offering for many applications, it was not ideal for our specific use. The bandwidth our server would use made the switch to Amazon EC2 cost prohibitive.We will certainly consider this service in the future and you can bet when we do, the use of Cisco Performance Monitoring and or the nProbe will be part of the solution. Learn more by watching the Network Performance Monitoring webcast.