Alternatives to ElastiCache

In addition to using ElastiCache, you can cache data in AWS in other ways, each of which has its own pros and cons. To review some of the alternatives:

• Amazon CloudFront content delivery network (CDN) — This approach is used to cache webpages, image assets, videos, and other static data at the edge, as close to end users as possible. In addition to using CloudFront with static assets, you can also place CloudFront in front of dynamic content, such as web apps. The important caveat here is that CloudFront only caches rendered page output. In web apps, games, and mobile apps, it's very common to have thousands of fragments of data, which are reused in multiple sections of the app. CloudFront is a valuable component of scaling a website, but it does not obviate the need for application caching.

• Amazon RDS Read Replicas — Some database engines, such as MySQL, support the ability to attach asynchronous read replicas. Although useful, this ability is limited to providing data in a duplicate format of the primary database. You cannot cache calculations, aggregates, or arbitrary custom keys in a replica. Also, read replicas are not as fast as in-memory caches. Read replicas are more interesting for distributing data to remote sites or apps.

• On-host caching — A simplistic approach to caching is to store data on each Amazon EC2 application instance, so that it's local to the server for fast lookup. Don't do this. First, you get no efficiency from your cache in this case. As application instances scale up, they start with an empty cache, meaning they end up hammering the data tier. Second, cache invalidation becomes a nightmare. How are you going to reliably signal 10 or 100 separate EC2 instances to delete a given cache key? Finally, you rule out interesting use cases for in-memory caches, such as sharing data at high speed across a fleet of instances.

Let's turn our attention back to ElastiCache, and how it fits into your application.