Tips About Migrating to Amazon Web Services

Over the last two months our development team has been migrating QGenda’s automated  physician on-call scheduling application from our own fully owned geographically separated cabinets of servers, switches, firewalls, and load-balancers to Amazon Web Services (AWS) Elastic Compute Cloud (EC2). We set out with a plan to replicate our current production environment using AWS, and along the way have experienced certain glitches worth mentioning for others planning to utilize AWS EC2.

Here are some main tips and gotchas learned in our AWS migration:

  • The Elastic Load Balancer (ELB) has a default timeout of 60 seconds and drops any long running HTTP(s) requests exceeding this limit (such as generating a downloadable data intensive report on the fly). Solution: Submit an AWS support ticket asking them to extend the timeout to their maximum of 17 minutes.
  • If your application requires SSL, it’s usually always best (performance wise) to decrypt the SSL on the server instead of offloading the decryption to the load balancer. This is especially important when using AWS because decrypting on the ELB would mean your data would travel in plain text within Amazon’s network from the ELB to your server(s) which other AWS customers could potentially intercept.
  • AWS Elastic IPs (EIP) provide a static public facing IP address that can be assigned to any EC2 instance, however the EIP does not have a static internal private IP. If he EC2 associated with the EIP is rebooted, then the internal private IP changes, which can cause troubles when mirroring a database. Solution: Write a script to monitor the internal private IP or use Amazon’s VPC.
  • The AWS Developer support for $49/month is worth every penny. It provides you with email support where they will respond within 12 hours. Another great support resource is the AWS community forums.

Switching from fully owned geographically separated hardware to AWS is definitely something each business should consider. It does not always make sense for every cloud application, but for QGenda’s needs it works perfectly. Just make sure to test, test, and test extensively when moving your production environment to the cloud.

Have you migrated your application to AWS, if so, what tips/gotchas did you run into?

Twitter: @Benoit_Greg

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s