Amazon Web Services, PHP Sessions
When running a scalable PHP application on Amazon Web Services (AWS), one of the options for PHP sessions is to use file based storage on Elastic File System (EFS). However, this could lead to scalability problems.
PHP includes builtin session handling that many developers use in their applications. There are several ways to store session data, and choosing the proper one is part of building and deploying a scalable web application. Even if an application doesn't use sessions (such as WordPress) you should still consider if any of its plugins or themes use sessions internally.
This document outlines several ways to store sessions using Amazon Web Services (AWS) technology.
File Storage (not recommended)
The file storage mechanism is the default and most common way to store session data. For scalable web applications, these files must be located on shared storage so that all backends can access the same sessions. AWS provides a shared filesystem called Elastic File System (EFS) which you might be temped to use to store session data. It is not recommended you do this for several reasons.
- PHP file sessions use file locks, and EFS has limits on the number of locks your instance can take. AWS has increased this limit in recent years to 65k, but it is better to use session storage that does not have limits that will constrain you maximum number of client requests.
- Enumerating a large directory of session files can take many minutes on EFS. If multiple requests trigger the PHP session garbage collector then backend processes can be tied up trying to cleanup stale sessions.
ElastiCache (Memcached and Redis)
AWS provides a service called ElastiCache which can quickly launch memcached or Redis instances.
Memcached is useful when your session state does not need to persist. When you create an ElastiCache memcached you can specify how many nodes you want and what subnets to place them on. After your cache is created, you find the individual node addresses and use them in the PHP session handler configuration. The memcached module will automatically distribute your data evenly among the configured nodes. When AWS needs to perform maintenance on memcached, any data on that particular node will be lost.
Redis us useful when you session state needs to persist. When you create an ElastiCache Redis cluster you can specify how many nodes you want and what subnets to place them on. After your cache is created, you can take the master node address and use it in the PHP session handler configuration. Your data will be distributed by Redis across all its nodes. When AWS needs to perform maintenance on Redis, it will migrate the master node to make sure Redis is always available.
DynamoDB
AWS provides a No-SQL database called DynamoDB which can also be used for session storage. This offers persistent session storage often at a lower cost than running an ElastiCache Redis cluster. If you are unable to modify your PHP application to include the DynamoDB session handler, then consider placing the session storage setup in a common file and using the PHP configuration option auto_prepend_file.
Provisioning the correct number of read/write credits for DynamoDB can be difficult for a new application. You might want to use ElastiCache for a trial period and review the CloudWatch Metrics to get an idea of the number of credits you need in DynamoDB. You can also use DynamoDB AutoScaling to have it dynamically adjust the read and write credits for you, or use the DynamoDB On Demand pricing model.