Release: AWS SDK for PHP 1.4.1

Amazon ElastiCache

Amazon ElastiCache is a new web service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud. The service improves the performance of web applications by allowing you to retrieve information from a fast, managed, in-memory caching system, instead of relying entirely on slower disk-based databases. Amazon ElastiCache is protocol-compliant with Memcached, a widely adopted memory object caching system, so code, applications, and tools that you use today with your existing Memcached environments will work seamlessly with the service. Amazon ElastiCache simplifies and offloads the management, monitoring, and operation of in-memory cache environments, enabling you to focus on the differentiating parts of your applications. The service is ideal for many read-heavy application workloads (such as social networking, gaming, media sharing and Q&A portals) or compute-intensive workloads (such as a recommendation engine).

For more information about Amazon ElastiCache, see http://aws.amazon.com/elasticache/.

Spot Instance Support with Amazon Elastic MapReduce

Developers can now run their Amazon Elastic MapReduce applications on Spot Instances, significantly reducing the cost of processing vast amounts of data on managed Apache Hadoop clusters. Customers can run their Elastic MapReduce applications entirely on Spot Instances to enjoy the largest potential cost savings or they can easily mix Spot Instances with On-Demand and/or Reserved Instances to protect against cluster failure due to Spot Instances being outbid.

Termination Protection Support with Amazon Elastic MapReduce

Termination protection ensures that the Amazon EC2 instances in your job flow are not shut down by an accident or error. This protection is especially useful if your cluster contains data in ephemeral instance storage that you need to recover before those instances are terminated.

2GB limit for 32-bit stacks

Because PHP's integer type is signed and many platforms use 32-bit integers, the AWS SDK for PHP does not correctly handle files larger than 2GB on a 32-bit stack (whereby "stack" includes CPU, OS, web server, and PHP binary). This is a well-known PHP issue.

The recommended solution is to use a 64-bit stack, such as the 64-bit Amazon Linux AMI with the latest version of PHP installed.

For more information, please see: PHP filesize: Return values. A workaround is suggested in AmazonS3::create_mpu_object() with files bigger than 2GB.

S3 Buckets containing periods

Amazon S3's SSL certificate covers domains that match *.s3.amazonaws.com. When buckets (e.g., my-bucket) are accessed using DNS-style addressing (e.g., my-bucket.s3.amazonaws.com), those SSL/HTTPS connections are covered by the certificate.

However, when a bucket name contains one or more periods (e.g., s3.my-domain.com) and is accessed using DNS-style addressing (e.g., s3.my-domain.com.s3.amazonaws.com), that SSL/HTTPS connection will fail because the certificate doesn't match.

The most secure workaround is to change the bucket name to one that does not contain periods. Less secure workarounds are to use disable_ssl() or disable_ssl_verification(). Because of the security implications, calling either of these methods will throw a warning. You can avoid the warning by adjusting your error_reporting() settings.

Expiring request signatures

When leveraging AmazonS3::create_mpu_object(), it's possible that later parts of the multipart upload will fail if the upload takes more than 15 minutes.

Too many open file connections

When leveraging AmazonS3::create_mpu_object(), it's possible that the SDK will attempt to open too many file resources at once. Because the file connection limit is not available to the PHP environment, the SDK is unable to automatically adjust the number of connections it attempts to open.

A workaround is to increase the part size so that fewer file connections are opened.

Exceptionally large batch requests

When leveraging the batch request feature to execute multiple requests in parallel, it's possible that the SDK will throw a fatal exception if a particular batch pool is exceptionally large and a service gets overloaded with requests.

This seems to be most common when attempting to send a large number of emails with the SES service.