AWS a placé plusieurs produits en mode maintenance, ce qui bloque leur adoption par de nouveaux clients tout en maintenant le service pour les utilisateurs existants. La liste comprend notamment Amazon Kendra, Amazon Q Business, Cognito Sync, Simple AD et l’ancienne génération de Bedrock Agents, renommée Bedrock Agents Classic.

La réponse rapide

StatutConséquence
MaintenanceLes clients existants continuent, mais les nouveaux ne peuvent plus activer la fonction.
Fin de support annoncéeUne migration doit être planifiée avant l’arrêt ou la perte d’assistance.
Fin de support atteinteLe service ou la fonction n’est plus disponible selon le calendrier AWS.

AWS cite aussi des trajectoires de retrait pour WorkSpaces PCoIP, WorkSpaces Pool, re:Post Private, SageMaker AI Profiler et d’autres offres. Les dates varient : il faut consulter la page de cycle de vie propre à chaque service.

Maintenance ne veut pas dire stabilité éternelle

Un service en maintenance continue généralement de recevoir l’exploitation nécessaire, mais ne constitue plus un choix d’architecture durable. Les nouvelles régions, intégrations et fonctions peuvent ne jamais arriver. Une dépendance qui fonctionne aujourd’hui peut devenir plus coûteuse à remplacer lorsque les compétences et la documentation se raréfient.

Les équipes existantes doivent inventorier les ressources, versions d’API, volumes, règles IAM et flux de données. Ajoutez le statut du service au registre de risques et affectez un propriétaire à la migration.

Le cas de la recherche et des assistants

Kendra et Q Business ont servi à indexer des contenus d’entreprise et à produire des réponses assistées. Leur passage en maintenance oblige à comparer les alternatives sur la qualité de recherche, les connecteurs, les ACL documentaires et les coûts d’indexation, pas seulement sur la présence d’un chatbot.

Bedrock Agents Classic pose un autre problème : les actions, prompts, bases de connaissances et observabilité ne se transposent pas toujours directement vers une génération plus récente. Construisez un jeu d’évaluation avant de migrer pour comparer réponses, autorisations et latence.

Ne pas confondre sauvegarde et portabilité

Exporter les documents ou une configuration ne garantit pas qu’ils puissent être restaurés chez un autre fournisseur. Documentez les schémas, transformations, identités et dépendances réseau. Testez l’import dans la cible avant de supprimer la source.

Pour un annuaire ou un espace de travail, prévoyez la coexistence, le basculement DNS, les sessions actives et le retour arrière. La migration technique doit être accompagnée d’un plan utilisateur et de support.

Une leçon d’architecture cloud

Un service managé réduit l’exploitation quotidienne, pas le risque de cycle de vie. Évaluez dès la conception la disponibilité d’un export, les standards utilisés et le coût d’un remplacement. Une couche d’abstraction n’est utile que si elle est testée ; sinon elle ajoute du code sans offrir de sortie réelle.

Abonnez-vous aux notifications de cycle de vie et faites remonter les échéances dans les outils d’incident ou de gouvernance. Un courriel reçu par un ancien administrateur ne constitue pas un processus.

Les annonces AWS ne demandent pas toutes une migration immédiate, mais elles donnent un signal clair. Les organisations déjà clientes doivent utiliser la période de maintenance pour préparer une sortie contrôlée, avant qu’une date de fin transforme un choix en urgence.