Deux contraintes autour desquelles les équipes plateforme concevaient depuis dix ans ont disparu la semaine du 13 juillet. S3 a supprimé l'attente de 30 jours avant qu'un objet puisse passer de S3 Standard à Standard-IA ou One Zone-IA, et Lambda a cessé de copier votre paquet de déploiement dans son propre stockage, ce qui supprime le quota de stockage de code et raccourcit l'activation après un déploiement. Un troisième changement est plus petit mais compte pour quiconque consolide l'identité : Cognito peut désormais importer des utilisateurs avec leurs hachages de mots de passe existants, donc une migration depuis un autre fournisseur d'identité n'impose plus une réinitialisation de mot de passe à chaque utilisateur. Côté IA, GPT-5.6 Sol, Terra et Luna d'OpenAI sont passés GA sur Bedrock.

Aucun lancement de migration ou de modernisation n'est tombé dans cette fenêtre au-delà du changement Cognito, donc ce billet est plus court que celui de la semaine dernière. Cela reste une semaine avec un thème : AWS a retiré des limites qui existaient pour la commodité d'AWS plutôt que pour la vôtre.

S3 : Infrequent Access dès le jour zéro

Jusqu'au 16 juillet, une règle de cycle de vie ne pouvait pas faire passer un objet vers S3 Standard-IA ou One Zone-IA avant qu'il ait passé 30 jours dans S3 Standard. La règle peut maintenant dire 0 jour, et la transition a lieu dès le jour de création de l'objet. AWS la présente pour les sauvegardes, l'analyse de logs et les données de conformité qui refroidissent en quelques heures, et le tarif de stockage des classes IA est jusqu'à 40 % en dessous de S3 Standard avec le même accès en millisecondes.

Lisez les considérations sur les transitions avant de passer toutes vos règles à zéro, parce que ce qui rendait IA coûteux pour la mauvaise charge de travail n'a pas bougé. Les objets de moins de 128 Ko ne transitionnent pas par défaut, et vous payez une requête de transition par objet dans tous les cas, donc un bucket de petits fragments de logs devient plus cher, pas moins. Les classes IA gardent leur facturation de durée minimale de stockage, donc un objet que vous écrivez, basculez le jour zéro et supprimez le troisième jour est facturé comme s'il était resté. Et IA facture par Go récupéré, ce qui transforme des données « froides » en surprise quand un job de retraitement les relit toutes. Une règle concrète pour un préfixe de sauvegardes ressemble à ceci :

{
  "Rules": [{
    "ID": "backups-to-ia-day-zero",
    "Status": "Enabled",
    "Filter": { "Prefix": "backups/" },
    "Transitions": [{ "Days": 0, "StorageClass": "STANDARD_IA" }]
  }]
}

La bonne charge de travail, ce sont des données écrites une fois, lues rarement et conservées au-delà de la durée minimale. Les sauvegardes et les archives de conformité se qualifient. Les logs applicatifs que vous suivez pendant une semaine, non, et S3 Intelligent-Tiering gérait déjà le cas « je ne sais pas » sans les frais de récupération.

Lambda : votre bucket est la source de vérité

Lambda copiait chaque paquet de déploiement dans un stockage géré par Lambda quand vous créiez ou mettiez à jour une fonction ou un layer. Cette copie était ce que comptait le quota de stockage de code de 75 Go par Région, et c'était une étape sur le chemin critique de chaque déploiement. Depuis le 15 juillet, vous pouvez positionner S3ObjectStorageMode à REFERENCE sur une fonction ou un layer et Lambda lit le code depuis votre bucket à la place. Le code référencé ne compte pas dans le quota, le quota géré lui-même est passé de 75 Go à 300 Go pour tous les autres, il n'y a aucun frais Lambda supplémentaire, et vous payez le stockage S3 plus le transfert inter-Région là où il s'applique. Le principal de service Lambda a besoin de s3:GetObject et s3:GetObjectVersion sur le bucket.

Le compromis, c'est que vous possédez désormais une dépendance de disponibilité que vous n'aviez pas. Si l'objet du bucket est supprimé, écrasé, ou si sa politique casse, c'est un incident Lambda. Le versioning sur le bucket cesse d'être optionnel, le pipeline de déploiement doit écrire de nouvelles clés plutôt qu'écraser, et la politique du bucket a besoin du même contrôle des changements que le rôle IAM de la fonction. Les équipes avec des centaines de fonctions et de layers, pour qui le quota de 75 Go signifiait un ticket de support chaque trimestre, en tirent le plus. Une équipe avec vingt fonctions devrait se demander si l'activation plus rapide vaut une chose de plus qui peut être mal configurée.

Cognito : la migration qui ne réinitialise plus les mots de passe

Déplacer une base d'utilisateurs vers Cognito via un import CSV a toujours eu un moment désagréable : chaque utilisateur importé devait réinitialiser son mot de passe à la première connexion, parce que Cognito ne pouvait pas accepter les hachages du système source. Depuis le 15 juillet, le CSV peut transporter les hachages, vous déclarez l'algorithme, et Cognito vérifie le mot de passe de l'utilisateur contre le hachage importé à la première connexion, puis le re-protège. Pris en charge : bcrypt, scrypt, Argon2id et PBKDF2 avec SHA-256, dans chaque Région où Cognito tourne.

C'est le genre de changement qui décide si un projet de consolidation a lieu. La réinitialisation forcée était la raison pour laquelle beaucoup d'équipes gardaient un IdP legacy vivant en parallèle pendant un an, avec le trigger de migration à la première connexion. Maintenant, le cutover peut être un simple import. Le mode de défaillance, c'est l'export des hachages lui-même : le système source doit vous donner les paramètres de l'algorithme exactement, et une divergence n'échoue pas bruyamment, elle échoue en « mauvais mot de passe » pour toute la base d'utilisateurs d'un coup. Testez avec un échantillon qui inclut des utilisateurs sur chaque configuration de hachage historique que l'ancien système a jamais utilisée.

Aussi cette semaine

Le fil conducteur

La règle des 30 jours de S3 et la copie de code de Lambda étaient toutes deux des artefacts de la façon dont AWS a construit le service, pas de ce dont les clients avaient besoin. Les deux étaient contournées avec de l'outillage : Intelligent-Tiering pour la première, des scripts d'élagage de layers et des tickets de quota pour la seconde. Les retirer est une bonne chose, et c'est aussi un rappel de ce que le contournement cachait. L'IA au jour zéro expose la tarification de récupération et de durée minimale que l'attente de 30 jours empêchait la plupart des gens de rencontrer. Le code référencé expose votre bucket comme dépendance d'exécution. L'import de hachages de Cognito retire la réinitialisation forcée et expose la qualité de l'export de votre ancien IdP. Dans chaque cas, AWS vous a rendu une décision qu'il prenait à votre place.

À lire ensuite

Pour la lecture IA et agents des mêmes semaines, les notes de terrain vivent sur ercan.ai. Le conseil en AWS, cloud, pipelines CI/CD, Linux, GitHub/GitLab et plus encore passe par ercanermis.com.

Références