5 Ways to Know you are Ready for AWS Auto Scaling

Whether you are running one Amazon EC2 instance or hundreds, you can use AWS Auto Scaling to detect impaired Amazon EC2 instances and unhealthy applications, then automatically replace them without your intervention. This ensures that your application is getting availability you expect. For a fully managed Auto Scaling environment pre-configured, check out Cloudnexa's Starter Hosting Packages for PHP applications like WordPress.

1. User Session Management

There are various ways to manage user sessions, the most common approaches are utilizing Sticky sessions, or using a Distributed Cache for your session management.

Sticky sessions, also known as session affinity, allow you to route a site user to the particular web server and can be simply managed on the AWS ELB. While this can be a cost-effective approach, it is not scalable, as in the event of a server failure, all user session data will be lost. If your application is still leveraging sticky sessions, you should consider updating the architecture design to remove this functionality.

Distributed Cache session management is highly recommended as it designates a layer in your architecture to store those sessions independently of the ELB and EC2 instances. Utilizing AWS ElastiCache with Redis or Memcached is the ideal choice to store sessions scalably. Additionally, AWS Dynamodb or even RDS can also provide a reliable option with Auto Scaling depending on the applications traffic load.

2. Email

A common requirement for a web application is the ability to send email. With Auto Scaling, you need to think about a reliable and scalable way to send emails. Running a local mail server on each instance will not prove reliable, as the IP address can change during an Auto Scaling event. A changing IP can affect the rating of your emails and potentially find yourself on spam blacklists. The best way to manage is via an external email relay provider like the AWS SES service, or Mailjet. These solutions allow you to decouple the email server from the Auto Scaled web application, providing the reliability and scalability required to achieve the migration.

If you are using WordPress, try a SMTP Plugin to allow you to bring an email relay service into your architecture.

3. Cron

Occasionally we hear from our customers that they require access to the linux cron, a time based job scheduler most often used for repetitive tasks. Linux cron does not have the concept of sessions management or concurrency checking, therefore in an active Auto Scaled environment it is not recommended to leverage cron. For example, if you have a cronjob setup on a single ec2 instance in an Auto Scaling group, then you increase capacity by adding a 2nd and 3rd EC2 instance, it will duplicate the crontab configurations across the 2nd and 3rd. This can cause concurrency issues. For example, each of the 3 EC2 instances would over write the other when making changes to files or a database.

When it comes to Auto Scaling, the usage of native Linux cron jobs on its own is not recommended. Better solutions include:

• Running on a dedicated EC2 instance that is not Auto Scaled.
• Configuring a job service that can better manage concurrency via the use of queues from SQS and Elastic Beanstalk Worker Environments.
• 3rd party built library for managing job scheduling within the application code itself, which may include the database as a centralized job tracking repository.

4. Health Check

To automatically discover the availability of your EC2 instances part of an Auto Scaling group, you need to enable a health check page configured on your ELB. Configuring an accurate health check is critical to ensure the proper identification of a failed EC2 instance. If your application leverages a database, consider a health check page that validates the database connections as well. Be sure to be conscious about properly managing open database connections to ensure you do not flood the database and max out connections. For example, the WordPress application leverages the database for session storage, therefore validating the health of a single web page can also validate the database via session lookups.

It is important to note that an ELB health check page should not be a redirect to another page, the classic ELB will fail the health check with http response code of a 302. The page should return only an HTTP 200.

5. User Generated Content

Some web applications leverage user generated content, where users can upload files, images, or videos which can then be made immediately available on all EC2 web servers. In this scenario, a distributed storage system is required to maintain synchronization of the content across any number of EC2 instances part of your Auto Scaling Group. An ideal candidate would be the Amazon S3 Service. As a centralized storage solution, you can have users upload content directly to s3 via the AWS javascript sdk, ( for security will require token vending for access to the s3 bucket via the AWS IAM STS Service ), or the EC2 instances themselves can receive the files and upload to s3 behind the scenes. Another option is to leverage a shared filesystem like NFS. For higher performance requirements we would recommend the shared file system solution from Zadara Storage or the Amazon EFS Service for lower volume sites. With NFS attached to all the EC2 instances you can ensure content will stay in sync.

For a fully managed Auto Scaling environment pre-configured to automatically manage all of these steps except session management for you, check out Cloudnexa's Starter Hosting Packages for PHP applications like WordPress.