Pour une équipe PHP, le point important n’est pas la taille du catalogue: c’est la possibilité de dissocier l’exécution, les données et la montée en charge sans maintenir une infrastructure physique. AWS est présenté comme le premier service cloud mondial en 2026.
Le périmètre combine IaaS, PaaS et SaaS. Cette superposition est la règle sur AWS: une application peut louer des machines virtuelles, déléguer son déploiement à une plateforme managée, puis consommer des services sans serveur. Le bon choix dépend donc moins du langage que du niveau d’infrastructure que l’équipe veut réellement administrer.
Calcul: choisir le niveau d’abstraction
Amazon EC2 fournit une capacité de calcul évolutive sous la forme d’ordinateurs virtuels loués. C’est la couche qui conserve le plus de contrôle sur l’environnement d’exécution: adaptée quand l’application impose sa configuration, ses processus et son découpage runtime.
Lightsail vise au contraire le déploiement rapide de technologies, la création de sites web, l’exécution de logiciels d’entreprise et les environnements de test. La logique est plus compacte: moins de composants à assembler, mais aussi moins de granularité exposée.
Elastic Beanstalk se place entre les deux. Le service simplifie le déploiement et surveille l’état de performance des applications; l’auto scaling et l’équilibrage de charge flexible servent à absorber les variations de volume. Pour un projet PHP, cette distinction doit être tranchée avant l’implémentation: VM à gérer, plateforme de déploiement, ou couche d’exécution plus déléguée. Mélanger les trois sans frontière nette produit surtout une architecture difficile à lire.
Conteneurs et serverless: deux modèles d’exécution
AWS propose une solution de gestion et de déploiement Kubernetes sans administration du plan de contrôle. Les conteneurs y tournent sur des clusters via l’API Kubernetes standard, avec des manifestes YAML ou des charts Helm. Le modèle conserve donc les objets Kubernetes: il convient aux équipes déjà structurées autour de ces fichiers de configuration et de ce mode d’orchestration.
AWS Lambda prend l’autre trajectoire. La plateforme exécute le code à la demande, gère les ressources nécessaires et facture le temps de calcul. L’infrastructure disparaît du chemin d’exécution visible; le code et son déclenchement deviennent l’unité principale.
Le test pratique est simple: identifier si l’application doit vivre comme un ensemble de conteneurs déclarés dans Kubernetes, ou comme du code exécuté à la demande. Ce n’est pas un détail de packaging. Ce sont deux surfaces opérationnelles différentes.
Données: S3, SQL et traitement distribué
Amazon Athena est un service de requêtes interactives sur les données placées dans Amazon S3. Sans serveur, il utilise SQL standard et Presto, avec notamment CSV, JSON, ORC, Apache Parquet et Avro. Pour les équipes web, le signal est net: les données stockées peuvent être interrogées sans déployer un serveur de base de données dédié dans ce cadre précis.
Amazon EMR cible le traitement de grands volumes de données avec un framework Hadoop hébergé sur EC2 et S3. Le service permet d’ajuster la capacité aux tâches à réaliser.
Verdict: AWS est à utiliser en production lorsque le découpage entre calcul, stockage, déploiement et traitement de données est explicite. Sans cette cartographie, ses plus de 200 services ne constituent pas une plateforme: ils deviennent une dette de configuration.