Introduction

If editing php.ini on an EC2 instance appears to do nothing, the usual problem is not EC2 itself. It is almost always one of these: you edited the wrong configuration file, you changed the CLI config while the web server uses a different one, another file overrides the setting later, or the relevant PHP service was never reloaded. Once you identify which PHP runtime is serving the request, the behavior becomes much easier to explain.

Start by finding the active configuration file

PHP can load different configuration files depending on how it is executed. The command line, Apache module, and PHP-FPM may each use different config locations.

For CLI:

php --ini

That shows the loaded configuration file and any additional scanned .ini files.

For web requests, create a temporary diagnostic script:

<?php
phpinfo();

Load it in the browser and look for:

• Loaded Configuration File
• Scan this dir for additional .ini files
• Any overridden directive values

This distinction is critical. A php.ini change that affects php -i on the shell does not prove that Apache or PHP-FPM is using the same file.

Know which PHP stack you are actually running

On EC2, a PHP application may be served through several different setups:

• Apache with mod_php
• Nginx with PHP-FPM
• A containerized PHP runtime
• Multiple installed PHP versions side by side

If PHP-FPM serves the application, changing the wrong php.ini or the wrong pool configuration file will have no visible effect.

For example, to inspect PHP-FPM:

php-fpm -i | grep "Loaded Configuration File"

Or check the pool and config directories commonly used by the distribution. The exact paths vary across Amazon Linux, Ubuntu, and other images.

Additional .ini files may override your change

Even if you edited the correct base php.ini, another scanned file may override the setting later. Many Linux distributions load extra configuration files from directories such as conf.d or php.d.

That means this sequence is possible:

1. You set memory_limit = 512M in php.ini
2. A later file sets memory_limit = 128M
3. The runtime uses the later value

Use php --ini or phpinfo() to see which extra files are being scanned, then search those directories for the directive you changed.

Reload the correct service

Configuration changes often require a reload or restart of the service that uses them.

For Apache:

sudo systemctl restart httpd

For Nginx plus PHP-FPM:

sudo systemctl restart php-fpm
sudo systemctl restart nginx

On Ubuntu, the service names may differ:

sudo systemctl restart apache2
sudo systemctl restart php8.2-fpm

If you change a config file and never restart the relevant service, the old runtime may continue using cached settings.

Some settings can be overridden elsewhere

Not every PHP setting comes only from php.ini. Depending on the stack, values may also be overridden by:

• Apache virtual host config
• '.htaccess'
• PHP-FPM pool config
• Per-directory .user.ini
• Environment-specific container config

That is why you should not stop at "I edited php.ini." The runtime behavior depends on the full configuration chain.

Common Pitfalls

The biggest mistake is checking the CLI configuration while the real problem is in the web server configuration. php --ini only tells you about the CLI interpreter.

Another issue is forgetting additional scanned .ini files. A later override can make it look like your php.ini change had no effect.

Developers also restart the wrong service. Restarting Nginx alone does not reload PHP-FPM settings, and restarting Apache does nothing if a different PHP runtime serves the app.

Finally, EC2 itself is often blamed when the real issue is just normal Linux PHP configuration layering. The instance is usually not the special part of the problem.

Summary

• EC2 is rarely the reason a php.ini change appears ineffective.
• Verify which configuration file the active PHP runtime actually loads.
• Distinguish between CLI PHP and web-served PHP.
• Check additional scanned .ini files and service-specific overrides.
• Restart or reload the correct PHP-serving service after the change.