Reduce AWS SDK Bundle Size in PHP with Composer

Installing the full AWS SDK just to do a few S3 operations has always felt like a lot.

In a traditional hosted app, that might be a little untidy. But when running in a serverless app, that extra weight is more painful. Bigger deployment packages take longer to upload, can slow cold starts, give the runtime more to unpack and initialise, and push us closer to hard platform limits. One example is AWS Lambda's zip deployment limit. It's 250mb unzipped, including layers and custom runtimes.

In a standard PHP app, installing the AWS SDK pushes the vendor/aws directory to around 68mb. By trimming it to only S3 and SQS services, vendor/aws drops to a shade over 5mb. The full vendor directory for that trimmed install was just under 8mb, because Composer still installs shared dependencies outside vendor/aws, but the core point is that we can take a huge bite out of our dependencies by only loading what we need. We can keep using what we need, but avoid carrying the bloat which can slow down our apps.

Trim the PHP SDK

PHP's AWS SDK does not split every service into its own Composer package. Instead, it ships as one SDK with a Composer script that removes unused services at install time.

The default install brings in the full SDK:

composer require aws/aws-sdk-php
du -sh vendor/aws
# 68M

If your code only talks to S3 and SQS, add the Composer hook and list those services in composer.json:

{
  "require": {
    "aws/aws-sdk-php": "^3.0"
  },
  "scripts": {
    "pre-autoload-dump": "Aws\\Script\\Composer\\Composer::removeUnusedServices"
  },
  "extra": {
    "aws/aws-sdk-php": ["S3", "Sqs"]
  }
}

Because the script is bound to the pre-autoload-dump hook, it executes automatically whenever Composer generates autoload files. This means it works seamlessly in CI/CD pipelines and Docker builds running composer install --no-dev, without any extra build steps being required.

Then reinstall or update:

composer update
# ...
# Removed 423 AWS services

du -sh vendor/aws
# 5.1M

du -sh vendor
# 7.8M

From 68mb to a little under 8, without any loss of functionality - not a bad result!

I am measuring vendor/aws because it shows what the SDK trimming script changed. I am also measuring the full vendor directory because that is closer to what a Lambda deployment package actually carries. The AWS SDK still depends on packages outside vendor/aws, such as Guzzle, PSR interfaces, Symfony polyfills, and Composer's generated autoload files.

The service names must match the SDK client namespaces exactly: S3, Sqs, DynamoDb, and so on. Some services, including S3, Kms, SSO, and Sts, are protected from removal because the SDK uses them internally.

If you remove something you later need, composer reinstall aws/aws-sdk-php restores the whole kit and caboodle.

The PHP usage does not change:

use Aws\S3\S3Client;

$client = new S3Client([
    'region' => 'eu-west-1',
    'version' => 'latest',
]);

$result = $client->getObject([
    'Bucket' => 'my-bucket',
    'Key' => 'path/to/file.json',
]);

$contents = $result['Body']->getContents();

The application code is the same, but with a much smaller (and faster!) deployment footprint.

What About JavaScript?

Many PHP apps still have a JavaScript frontend, worker, or small Node service somewhere nearby.

In JavaScript, AWS moved in this direction years ago. The AWS SDK for JavaScript v3 has been around since 2020, with a separate package for each service. If we only need S3, we install the S3 client:

npm install @aws-sdk/client-s3
du -sh node_modules
# 18M

Need S3 and SQS?

npm install @aws-sdk/client-s3 @aws-sdk/client-sqs
du -sh node_modules
# 19M

That is the model PHP is approximating with the Composer trimming script: keep the clients we need, leave the rest behind!

Wrapping Up

If you are using the AWS SDK in PHP, take a look at Composer's unused-service removal hook. It is a small config change that can cut a lot of dead weight from packages. This is generally good hygiene, but especially helpful when trying to speed up slow serverless or CI builds.

Share This Article

Related Articles


phpday Verona 2026

A first trip to phpday, and a first time in Verona!

Screen Portal: sharing a partial screen region in Google Meet

Google Meet only lets you share a full window or a Chrome tab. What if you only need to show a small region of your screen? Screen Portal uses the Screen Capture API to crop and relay any area of your screen into a shareable Chrome tab.

More