Amazon OpenSearch Service ajoute les mises à niveau par clonage : validation des seules requêtes de lecture sur un cluster cloné, annulation avant la bascule ou retour en arrière pendant une période de conservation fixée par vous ; limité à OpenSearch 1.1 ou plus récent et Elasticsearch 7.10, cinq chemins de mise à niveau, et les deux clusters sont facturés pendant la validation

Le 10 novembre 2026, AWS a annoncé les mises à niveau par clonage pour Amazon OpenSearch Service. L'annonce dit qu'on peut désormais valider une nouvelle version d'OpenSearch à côté de la version actuelle et ne basculer que lorsqu'on est satisfait. En cas de problème, on peut annuler avant la bascule ou revenir en arrière après. Ce compte rendu s'appuie sur cette annonce et sur la page du guide du développeur d'OpenSearch Service consacrée à la migration de version, qui décrit les étapes, les limites et les frais. Il ne traite pas de la vitesse de construction d'un clone, car aucune des deux pages ne donne de durée pour les mises à niveau par clonage.

L'ancienne méthode est la mise à niveau sur place. Le guide dit qu'elle met à niveau le cluster existant du domaine selon un déploiement bleu/vert, et qu'on ne peut ni la mettre en pause, ni l'annuler, ni revenir en arrière. Elle est disponible à partir d'OpenSearch 1.0 et d'Elasticsearch 5.1. Le guide précise que, même si des contrôles préalables s'exécutent d'abord, le cluster mis à niveau prend le relais dès la fin de la mise à niveau, qu'une mise à niveau sur place peut durer de 15 minutes à plusieurs heures, et qu'OpenSearch Dashboards peut être indisponible pendant ce temps. Pour revenir à la version précédente après une mise à niveau sur place, le guide indique de restaurer un instantané sur un nouveau domaine.

Une mise à niveau par clonage fonctionne autrement. OpenSearch Service crée un second cluster, le cluster cloné, sur la version cible et y copie vos données. Le cluster sur lequel tourne déjà le domaine est le cluster principal, et il continue de servir le trafic. Le guide liste six étapes. D'abord, les contrôles préalables s'exécutent, les mêmes que pour une mise à niveau sur place, et le processus ne continue pas s'ils échouent. Ensuite, un instantané est pris, et là encore rien ne continue s'il échoue. Troisièmement, le cluster cloné est créé et vos données y sont copiées ; le domaine continue de servir lectures et écritures depuis le cluster principal pendant que le clone reste synchronisé. Quatrièmement, la mise à niveau attend votre validation du clone. L'annonce dit qu'on peut exécuter les mêmes requêtes de recherche sur les deux clusters et comparer les performances avec les métriques Amazon CloudWatch, et le guide ajoute qu'on peut, en option, envoyer une part du trafic de lecture vers le clone. Cinquièmement vient la bascule. Sixièmement, une période de conservation facultative.

Plusieurs conditions se remarquent peu. La validation ne couvre que les lectures : le guide dit qu'on peut valider le cluster cloné avec ses propres requêtes de lecture, et c'est tout. Pendant la bascule, OpenSearch Service bloque les écritures jusqu'à la fin de la bascule, le temps que le clone rattrape son retard et que le trafic y soit déplacé. Le guide dit que le point de terminaison du domaine ne change pas. Un retour en arrière n'est possible qu'après la bascule et seulement pendant la période de conservation que vous avez fixée. Cette période commence à la fin de la bascule. Si vous ne fixez aucune période, le guide dit qu'OpenSearch Service supprime le cluster principal immédiatement après la bascule, ce qui ne laisse rien vers quoi revenir. Annuler avant la bascule supprime le cluster cloné et laisse le domaine tel qu'il était.

Les règles d'éligibilité sont étroites. L'annonce dit que les mises à niveau par clonage sont disponibles pour les domaines sous OpenSearch 1.1 ou plus récent ou Elasticsearch 7.10, dans les régions commerciales d'AWS où le service est proposé, sauf Asie-Pacifique (Nouvelle-Zélande), Asie-Pacifique (Taipei), Asie-Pacifique (Thaïlande) et Mexique (centre). Le guide liste cinq chemins pris en charge : Elasticsearch 7.10 vers OpenSearch 1.3, OpenSearch 1.1 vers 1.3, OpenSearch 1.3 vers 2.19, OpenSearch 2.x vers 2.19, et OpenSearch 2.19 vers 3.x. Pour les autres chemins, le guide dit d'utiliser une mise à niveau sur place. Il liste aussi les domaines non pris en charge : ceux qui utilisent des instances OpenSearch Optimized (OR1 ou OR2), des instances UltraWarm ou la réplication inter-clusters, ceux auxquels sont associés des paquets de plug-ins personnalisés ou tiers, et ceux qui utilisent l'authentification SAML ou Amazon Cognito pour OpenSearch Dashboards. On ne peut pas non plus modifier la configuration du domaine pendant la mise à niveau.

La règle de coût est énoncée clairement. Une mise à niveau sur place n'entraîne pas de frais supplémentaires. Pour une mise à niveau par clonage, la tarification standard s'applique aux instances et au stockage du clone, comme pour tout autre nœud. Vous payez à la fois le cluster principal et le clone pendant la validation, et si vous conservez le cluster principal pour un retour en arrière, vous payez les deux jusqu'à la fin de la période de conservation. L'annonce et le guide ne donnent aucun montant en dollars. Une validation ou une période de conservation plus longue allonge donc la durée pendant laquelle vous payez deux clusters ; le surcoût dépend de vos propres choix d'instances et de stockage et des tarifs standard.

Avant toute mise à niveau, le guide demande trois choses : prendre un instantané manuel, qu'on peut restaurer sur un nouveau domaine pour retrouver la version précédente ; vérifier les chemins de mise à niveau pris en charge ; et exécuter le contrôle préalable. Il avertit aussi que si vous alimentez OpenSearch Service avec des services comme Amazon Data Firehose ou Amazon CloudWatch Logs, vous devez vérifier qu'ils prennent en charge la version plus récente avant de migrer. Le tableau de dépannage liste des conditions qui bloquent une mise à niveau, comme plus de 1 000 partitions sur un nœud, une utilisation du disque supérieure à 90 %, une pression mémoire JVM supérieure à 75 % et un état de cluster rouge. Ces contrôles valent pour les deux types de mise à niveau.

Ce qui ne figure pas dans ces deux pages compte pour la planification. Elles ne donnent aucune mesure du temps que met un clone à se construire ou à rattraper son retard, aucune indication sur la durée de blocage des écritures pendant la bascule, et aucune preuve de la mesure dans laquelle la performance du clone prédit la performance en production. Le guide dit que la validation ne couvre que les lectures : cette étape ne permet donc pas de tester directement le comportement en écriture. Ce qui suit est notre jugement, pas une affirmation d'AWS. Une équipe à forte charge d'écriture devrait prévoir à part des tests d'écriture hors production et une répétition de la bascule. Toute équipe qui veut ce filet de sécurité devrait aussi mesurer la durée de la bascule sur un domaine hors production, décider à l'avance combien de temps garder le cluster principal et budgéter deux clusters pendant cette période.