FAQ sur Amazon OpenSearch Service

Oui. Vous pouvez créer un domaine Amazon OpenSearch Service en quelques clics à l'aide de l'assistant de création de domaines disponible dans la console. Lorsque vous créez ce domaine, vous pouvez définir le nombre et le type d'instances, ainsi que les volumes EBS que vous souhaitez allouer au domaine. La console permet également de modifier ou de supprimer des domaines Amazon OpenSearch Service existants.

Oui, Amazon OpenSearch Service s'intègre à Amazon VPC. Quand vous sélectionnez un accès par VPC, les adresses IP de votre VPC sont liées à votre domaine Amazon OpenSearch Service, et l'ensemble du trafic réseau reste au sein du réseau AWS et n'est pas accessible depuis Internet. En outre, vous pouvez utiliser des groupes de sécurité et des politiques IAM pour limiter l'accès à vos domaines Amazon OpenSearch Service.

Oui. AWS CloudFormation prend en charge Amazon OpenSearch Service. Pour en savoir plus, consultez la documentation Référence des modèles CloudFormation.

Oui. Vous pouvez configurer des nœuds principaux dédiés pour vos domaines. Quand vous sélectionnez une configuration maître dédiée, vous pouvez spécifier le type d'instance et leur nombre.

Oui. Vous pouvez créer plusieurs index Elasticsearch ou OpenSearch dans un même domaine Amazon OpenSearch Service. Elasticsearch et OpenSearch distribuent automatiquement les index et les réplicas associés entre les domaines alloués au domaine.

Amazon OpenSearch Service prend en charge trois options pour l'intégration de données :

• Pour de grands volumes de données, nous recommandons Amazon Kinesis Data Firehose, un service entièrement géré qui s'adapte automatiquement au débit de vos données et ne requiert aucune administration continue. Ce service peut également transformer, traiter par lot et compresser des données avant de les charger.
• Amazon OpenSearch Service peut être intégré à Logstash. Il est possible de configurer votre domaine Amazon OpenSearch Service en tant qu'entrepôt de données pour tous les journaux provenant de votre implémentation de Logstash.
• Vous pouvez utiliser des API Elasticsearch (jusqu'à la version 7.10) ou OpenSearch natives, telles qu'index et bulk, pour charger des données dans votre domaine.

Oui. Amazon OpenSearch Service peut être intégré à Logstash. Vous pouvez configurer votre domaine Amazon OpenSearch Service en tant que stockage backend pour tous les journaux transférés via votre implémentation de Logstash. Il est possible de définir les contrôles d'accès à votre domaine Amazon OpenSearch Service de deux manières : vous pouvez utiliser la signature des requêtes, qui permet d'authentifier les appels provenant de votre implémentation de Logstash, ou appliquer des politiques IAM basées sur les ressources, lesquelles permettent d'inclure les adresses IP des instances exécutant votre implémentation de Logstash.

Oui. Amazon OpenSearch Service offre des fonctionnalités de visualisation à technologie OpenSearch Dashboards et Kibana (versions 1.5 à 7.10).

Vous avez le choix entre un stockage local sur l'instance ou sur des volumes EBS. Si vous sélectionnez un stockage sur volume EBS pendant la création du domaine, vous pouvez augmenter et diminuer la taille du volume de stockage selon les besoins.

Vous avez le choix entre des volumes EBS magnétiques, à usage général et à IOPS provisionnés.

Oui. Amazon OpenSearch Service déploie le stockage en fonction du choix de l'instance et/ou de la taille du volume EBS associé. Le stockage maximum par nœud est de 24 To avec les instances R6g.12xlarge, ainsi qu'un stockage EBS gp3. Au cas où chaque domaine Amazon OpenSearch Service est limité par défaut à 80 nœuds de données, vous pouvez allouer environ 1920 To de stockage pour chaque domaine. Vous pouvez demander une augmentation de limite de service jusqu’à 200 instances par domaine en créant un cas auprès du centre AWS Support. Avec 200 instances, vous pouvez allouer environ 3 Po de stockage à un seul domaine.

Si vous déployez vos instances de données dans une seule zone de disponibilité, vos instances principales dédiées sont également déployées dans la même zone. Toutefois, si vous déployez vos instances de données sur deux ou trois zones de disponibilité, Amazon OpenSearch Service distribue automatiquement les instances principales dédiées parmi les trois zones de disponibilité. Font exception à cette règle les cas où une région dispose uniquement de deux régions de disponibilité ou si vous sélectionnez un type d'instance de génération antérieure pour les instances principales qui ne sont pas disponibles dans toutes les zones de disponibilité. Pour plus d’informations, reportez-vous à notre documentation.

Pour les charges de travail de production, nous vous recommandons de déployer vos instances de données sur trois zones de disponibilité, car elles offrent une meilleure disponibilité. Nous vous recommandons également de provisionner des instances par multiples de trois pour une distribution égale sur les zones de disponibilité. Dans les régions où trois zones de disponibilité ne sont pas disponibles, nous vous recommandons d'utiliser un déploiement sur deux zones avec un nombre pair d'instances de données. Dans tous les cas, nous vous recommandons de provisionner trois instances principales dédiées.

Vous pouvez activer des déploiements sur trois zones de disponibilité pour vos domaines tant nouveaux qu'existants, en utilisant la console, l'interface de ligne de commande ou les kits SDK AWS. Pour plus d’informations, reportez-vous à notre documentation.

Non. Amazon OpenSearch Service ne facture pas l'activation des déploiements sur trois zones de disponibilité. Vous ne payez que le nombre d'instances de votre domaine, et non le nombre de zones de disponibilité sur lesquelles elles sont déployées.

Tous les domaines configurés pour plusieurs zones de disponibilité reconnaissent les zones afin de garantir que les partitions sont distribuées parmi les zones de disponibilité. Dans la console, vous pouvez désormais choisir explicitement des déploiements sur deux ou trois zones de disponibilité. Les domaines précédemment avec l'option « Zone Awareness » (reconnaissance des zones) configurée continueront à être déployés sur deux zones de disponibilité, à moins qu'ils ne soient reconfigurés. Pour plus d’informations, reportez-vous à notre documentation.

Si une ou plusieurs instances d'une zone de disponibilité sont inaccessibles ou non fonctionnelles, Amazon OpenSearch Service essaie automatiquement de faire apparaître de nouvelles instances dans la même zone de disponibilité pour remplacer les instances affectées. Dans les rares cas où il est impossible d'intégrer de nouvelles instances dans une zone de disponibilité, Amazon OpenSearch Service en crée de nouvelles dans les autres zones de disponibilité, si le domaine a été configuré pour déployer des instances sur plusieurs zones de disponibilité. Une fois le problème de zone de disponibilité résolu, Amazon OpenSearch Service rééquilibre les instances de manière à ce qu'elles soient équitablement distribuées entre les zones de disponibilité configurées pour le domaine. Pour plus d’informations, reportez-vous à notre documentation.

Même lorsque vous configurez un réplica, nous vous recommandons d'utiliser trois zones de disponibilité. Si un incident se produit au niveau de la zone de disponibilité dans un domaine à trois zones de disponibilité, vous ne perdez qu'un tiers de votre capacité, mais si l'incident a lieu dans un domaine à deux zones de disponibilité, vous perdez la moitié de votre capacité, ce qui peut entraîner davantage de perturbations. De même, dans un domaine à trois zones de disponibilité, Amazon OpenSearch Service peut se rabattre sur les deux zones de disponibilité restantes tout en prenant en charge la réplication multi-zones. Dans un domaine à deux zones de disponibilité, vous perdez la réplication multi-zones si une zone est interrompue, ce qui peut réduire davantage la disponibilité. Pour plus d’informations, reportez-vous à notre documentation.

Le nombre de zones de disponibilité sur lesquelles votre domaine est déployé correspond au nombre de sous-réseaux que vous avez configurés pour votre domaine VPC. Vous devez configurer au moins trois sous-réseaux dans votre domaine VPC pour permettre un déploiement sur trois zones de disponibilité. Pour plus d’informations sur la configuration d’un VPC, reportez-vous à notre documentation.

Oui. Les programmes dotés d'un accès au réseau Internet public peuvent accéder aux domaines Amazon OpenSearch Service à travers un point de terminaison public. Si votre centre de données est déjà connecté à Amazon VPC via Direct Connect ou un tunnel SSH, vous pouvez également utiliser un accès par VPC. Dans les deux cas, vous pouvez configurer des politiques IAM et des groupes de sécurité pour autoriser les programmes exécutés sur des serveurs en dehors d'AWS à accéder à vos domaines Amazon OpenSearch Service. Cliquez ici pour en savoir plus sur les requêtes signées.

Pour la migration de données depuis un cluster Elasticsearch existant ou un cluster OpenSearch, créez un instantané du cluster existant et stockez-le dans votre compartiment Amazon S3. Créez ensuite un nouveau domaine Amazon OpenSearch Service et chargez-y les données provenant de l'instantané Amazon OpenSearch Service créé via l'API de restauration d'Elasticsearch.

Amazon OpenSearch Service met à votre disposition une console, une API et une interface de ligne de commande pour vous aider à gérer le dimensionnement de vos domaines Amazon OpenSearch Service. Vous pouvez mettre à l'échelle votre domaine Amazon OpenSearch Service en ajoutant, supprimant ou modifiant des instances ou des volumes de stockage, selon les besoins de vos applications. Amazon OpenSearch Service s'intègre à Amazon CloudWatch pour vous fournir des métriques sur l'état de vos domaines Amazon OpenSearch Service, ce qui vous permet de prendre des décisions pertinentes en matière de dimensionnement.

Non. Lorsque vous mettez à l'échelle votre domaine Amazon OpenSearch Service en ajoutant ou modifiant des instances et des volumes de stockage, ces opérations sont réalisées en ligne et n'entraînent aucune interruption.

Oui. Si vous avez des réplicas pour vos index OpenSearch/Elasticsearch et que vous utilisez plusieurs zones de disponibilité, Amazon OpenSearch Service distribue automatiquement vos partitions principales et réplicas sur plusieurs instances dans différentes zones de disponibilité.

Oui. Amazon OpenSearch Service génère plusieurs métriques de performance via Amazon CloudWatch, dont le nombre de nœuds, l'état des clusters, les documents pouvant faire l'objet de recherches, les métriques EBS (le cas échéant), l'utilisation du processeur, de la mémoire et de l'espace disque pour les données et les nœuds maîtres. Pour obtenir la liste complète des mesures CloudWatch disponibles, merci de vous référer à la documentation du service.

Oui. AWS CloudTrail est un service Web qui enregistre les appels d'API AWS pour votre compte et vous les présente sous forme de fichier journal. L'historique des appels d'API AWS généré par AWS CloudTrail permet de réaliser une analyse de sécurité, un suivi des modifications au niveau des ressources, ainsi que des audits de conformité. Pour en savoir plus sur AWS CloudTrail, consultez la page de présentation détaillée d’AWS CloudTrail. Pour l’activer, rendez-vous sur la page d’accueil de la console de gestion AWS pour CloudTrail.

Un instantané est une copie de votre domaine Amazon OpenSearch Service réalisée à un instant précis.

Il peut être utile de créer des instantanés en prévision d'une perte de données consécutive à la défaillance d'un nœud ou d'une panne matérielle, bien que ce dernier cas soit peu probable. Vos instantanés pourront vous permettre de restaurer votre domaine Amazon OpenSearch Service ou d'en créer un nouveau à partir de données préchargées. Les sauvegardes sont aussi souvent utilisées à des fins d'archivage. Les instantanés sont stockés dans Amazon S3.

Oui. Par défaut, Amazon OpenSearch Service crée automatiquement un instantané par heure de chaque domaine Amazon OpenSearch Service et les conserve pendant 14 jours.

Amazon OpenSearch Service conserve les instantanés horaires automatiques pendant 14 jours.

Les instantanés automatiques horaires ne donnent lieu à aucuns frais supplémentaires. Ils sont stockés gratuitement dans un compartiment S3 dédié à Amazon OpenSearch Service et sont mis à disposition lorsque vous souhaitez restaurer un nœud.

Oui. Vous pouvez utiliser l'API d'instantané pour créer manuellement des instantanés s'ajoutant à ceux générés automatiquement par Amazon OpenSearch Service sur une base quotidienne. Les instantanés manuels sont stockés dans votre compartiment S3 et sont soumis aux frais d'utilisation d'Amazon S3 en vigueur.

Oui. Les clients peuvent créer un nouveau domaine Amazon OpenSearch Service et y charger les données provenant de leur instantané via l'API de restauration d'OpenSearch/Elasticsearch.

Les instantanés quotidiens conservés par Amazon OpenSearch Service sont supprimés en même temps que le domaine. Avant de supprimer un domaine, pensez donc, si vous le souhaitez, à créer un instantané de ce domaine dans vos propres compartiments S3 en utilisant le processus manuel de création d'instantanés. Les instantanés stockés dans votre compartiment S3 ne sont pas affectés par la suppression de votre domaine Amazon OpenSearch Service.

Amazon OpenSearch Service présente trois journaux Elasticsearch ou OpenSearch via Amazon CloudWatch Logs : des journaux d'erreur, lents de recherche et lents d'indexation. Ces journaux sont utiles pour résoudre des problèmes de performances ou de stabilité du domaine de quelqu'un.

Les journaux lents sont des fichiers journaux permettant de suivre les performances de différentes étapes d'une opération. OpenSearch et Elasticsearch exposent deux types de journaux lents :

• les journaux lents d'indexation, qui fournissent des informations sur le processus d'indexation et qui peuvent servir à l'ajustement de la configuration de ce dernier ;
• les journaux lents de recherche, qui fournissent des informations sur la vitesse et les performances des requêtes et des recherches. Ces journaux permettent d'ajuster les performances de tous types d'opérations de recherche sur OpenSearch ou Elasticsearch.

Pour obtenir des informations complètes sur les journaux lents, consultez la documentation OpenSearch.

Les journaux lents peuvent être activés par simple clic sur un bouton de la console ou via notre CLI et nos API. Pour plus d’informations, consultez notre documentation.

Oui. Vous pouvez mettre à jour les paramètres pour un indice spécifique afin d'activer ou de désactiver les journaux lents pour celui-ci. Pour plus d’informations, reportez-vous à notre documentation.

Non. L'activation des journaux lents dans Amazon OpenSearch Service active l'option permettant de publier les journaux générés dans Amazon CloudWatch Logs pour les indices dans le domaine donné. Toutefois, pour générer les journaux, vous devez mettre à jour les paramètres pour un ou plusieurs indices afin de démarrer le processus de journalisation. Pour plus d’informations sur la configuration d’index en vue d’activer les journaux lents, consultez notre documentation.

Non. La génération des fichiers journaux dépend des paramètres d'indice. Pour désactiver la génération des fichiers journaux, vous devez mettre à jour la configuration d'indice. Pour en savoir plus sur la configuration d’indice en vue d’activer les journaux lents, consultez notre documentation.

Vous ne pouvez changer la granularité que de la journalisation des journaux lents. OpenSearch et Elasticsearch présentent plusieurs niveaux de journalisation pour les journaux lents. Vous devez définir le niveau approprié dans la configuration de votre indexation. Pour plus d’informations sur la configuration de l’index en vue d’activer les journaux lents, consultez la documentation relative à OpenSearch.

Lorsque les journaux lents ou les journaux d'erreur sont activés, Amazon OpenSearch Service commence à publier des journaux générés sur Amazon CloudWatch Logs. Amazon OpenSearch Service ne facture pas l'activation des journaux. Toutefois, les frais standard de CloudWatch s’appliquent.

OpenSearch utilise Apache Log4j 2 et ses niveaux de journaux intégrés TRACE, DEBUG, INFO, WARN, ERROR et FATAL (par niveau de gravité croissant). Si vous activez les journaux des erreurs, Amazon OpenSearch Service publiera des lignes de journaux de niveau WARN, ERROR et FATAL, ainsi que des erreurs sélectionnées du niveau DEBUG, vers CloudWatch. Pour plus d’informations, reportez-vous à notre documentation.

Les journaux d’erreurs peuvent être activés par simple clic sur un bouton de la console AWS ou via notre CLI et nos API. Pour plus d’informations, consultez notre documentation.

Non, les journaux d'erreur sont présentés pour la totalité du domaine. Cela dit, une fois les journaux activés, les entrées de tous les indices du domaine seront disponibles.

Non, les journaux d'erreur ne sont disponibles que pour la version 5.x ou ultérieure d'Elasticsearch.

Oui. Chaque entrée de journal effectuée dans CloudWatch sera limitée à 255 000 caractères. Si votre entrée de journal est supérieure, elle sera tronquée pour rentrer dans les 255 000 caractères.

Les journaux lents ne sont requis que pour le dépannage de vos indices ou les performances d'ajustement. L'approche recommandée consiste à n'activer que la journalisation pour les indices pour lesquels vous avez besoin d'informations supplémentaires sur les performances. Une fois l'investigation terminée, pensez à désactiver la journalisation afin qu'elle ne vous expose pas à des coûts supplémentaires. Pour en savoir plus, consultez notre documentation.

CloudWatch propose plusieurs moyens de consommer les journaux. Vous pouvez afficher les données de journaux, les exporter vers S3 ou les traiter en temps réel. Pour en savoir plus, consultez le Guide du développeur CloudWatch Logs.

Oui. Les journaux lents peuvent être activés pour toutes les versions d'OpenSearch et d'Elasticsearch prises en charge par Amazon OpenSearch Service. Cela dit, il existe quelques différences dans la façon dont les paramètres des journaux peuvent être spécifiés pour chaque version d'Elasticsearch. Veuillez vous référer à la documentation pour plus d’informations.

Non. Il n'y aura aucun temps d'arrêt. Chaque fois que le statut du journal sera mis à jour, nous déploierons un nouveau cluster en arrière-plan et nous remplacerons le cluster existant par un nouveau. Ce processus évitera tout temps d'arrêt. Toutefois, comme un nouveau cluster est déployé, la mise à jour du statut du journal ne sera pas instantanée.

Amazon OpenSearch Service prend actuellement en charge la mise à niveau de la version sur place pour les domaines de toutes les versions OpenSearch et les versions 5.x et supérieures d'Elasticsearch. Les versions cibles que nous prenons en charge pour la mise à niveau sont les versions 5.6, 6.3, 6.4, 6.5, 6.7, 6.8, 7.1, 7.4, 7.7, 7.8, 7.9 et 7.10. Pour plus d'informations, reportez-vous à notre documentation.

Veuillez vous reporter à notre documentation pour plus d’informations sur la migration de diverses versions d’Elastisearch.

Non. Votre domaine restera disponible tout au long du processus de mise à niveau. Cependant, une partie du processus de mise à niveau implique la relocalisation de partitions qui peuvent avoir des conséquences sur les performances du domaine. Nous vous recommandons de procéder à la mise à niveau lorsque la charge sur votre domaine est faible.

La mise à niveau de la version sur place n'est disponible que pour les domaines fonctionnant sur une version 5.x et supérieure d'Elastisearch. Si la version de votre domaine est une version 5.x ou supérieure, vous pouvez exécuter une vérification de l'éligibilité à la mise à niveau pour valider si votre domaine peut être mis à niveau ou non vers la version souhaitée. Veuillez consultez notre documentation pour en savoir plus.

Pour obtenir une liste détaillée des tests que nous exécutons pour valider l’éligibilité à la mise à niveau, veuillez vous reporter à notre documentation.

Non. Lorsque vous avez déclenché la mise à niveau de la version sur place, vous ne pouvez plus apporter de changement à la configuration de votre domaine tant que la mise à niveau n'est pas terminée ou n'a pas échoué. Vous pouvez continuer à lire et à écrire des données pendant que la mise à niveau est en cours. Vous pouvez également supprimer le domaine, auquel cas la mise à niveau se terminera et le domaine sera supprimé.

Le processus de mise à niveau de la version prend automatiquement un instantané du système et ne démarre réellement la mise à niveau que si cet instantané réussit. Si la mise à niveau est en cours lorsque l'heure de début d'instantané automatique arrive, cet instantané automatique est passé pour ce jour et reprendra le lendemain.

Amazon OpenSearch Service exécute une série de tests avant de déclencher la mise à niveau pour vérifier l'ensemble des problèmes connus pouvant empêcher la mise à niveau. Si aucun problème n'est rencontré, le système prend un instantané du domaine et démarre la procédure de mise à niveau si cet instantané réussit. La mise à niveau ne se déclenche pas en cas de problème rencontré au cours de l'une de ces étapes.

Si les problèmes rencontrés sont mineurs et réparables, Amazon OpenSearch Service essaiera automatiquement de s'en occuper et de débloquer la mise à niveau. Cependant, si un problème empêche la mise à niveau, le service reviendra à l'instantané pris avant la mise à niveau et enregistrera l'erreur dans un fichier journal. Pour plus d’informations sur l’affichage des journaux relatifs à la procédure de mise à niveau, veuillez-vous reporter à notre documentation.

Oui. Vous pouvez consulter les journaux de mise à niveau depuis la console AWS ou les demandez à l'aide de l'interface de ligne de commande ou des kits de développement logiciel. Veuillez vous référer à la documentation pour plus d’informations.

Non. Après avoir déclenché la mise à niveau, celle-ci ne peut ni être suspendue ni annulée tant que celle-ci n'est pas terminée ou n'a pas échoué.

Oui. Cependant, si vous souhaitez conserver tous vos domaines sur la même version, nous vous recommandons d'exécuter une vérification de l'éligibilité à la mise à niveau sur tous les domaines avant de les mettre à niveau. Cette étape supplémentaire peut aider à intercepter les problèmes sur un domaine qui pourraient ne pas survenir sur les autres.

Selon la quantité de données et la taille du cluster, les mises à niveau peuvent prendre entre quelques minutes à plusieurs heures.

Non. Lors de la mise à niveau de la version sur place, toutes les données de vos clusters sont également restaurées dans le cadre du processus de mise à niveau. Si vous souhaitez simplement mettre à niveau le domaine seul, vous pouvez prendre un instantané de vos données, supprimer tous les index du domaine, puis déclencher une mise à niveau de la version sur place. Vous pouvez également créer un domaine séparé sur la version la plus récente, puis restaurer toutes vos données sur ce domaine.

Non. Pour passer à une version plus ancienne, contactez AWS Support pour restaurer l'instantané automatique d'avant la mise à niveau sur un nouveau domaine. Vous pouvez effectuer cette étape vous-même si vous avez pris un instantané manuel du domaine d'origine.

Multi-AZ avec Standby est une nouvelle option de déploiement pour Amazon OpenSearch Service qui garantit une haute disponibilité et des performances constantes pour les charges de travail critiques de l'entreprise. Avec Multi-AZ avec Standby, les clusters gérés par OpenSearch Service résistent aux défaillances de l'infrastructure telles que les pertes de nœuds ou la défaillance d'une seule zone de disponibilité, garantissant ainsi l'absence d'impact sur les performances ou la disponibilité, même en cas de défaillance d'une seule zone de disponibilité. La technologie Multi-AZ avec Standby offre l'avantage supplémentaire de simplifier la configuration et la gestion des clusters en appliquant les meilleures pratiques et en réduisant la complexité.

Pour activer Multi-AZ avec Standby, les clusters gérés doivent répondre aux conditions suivantes :

• Exécutez OpenSearch 1.3 ou une version plus récente.
• Déployez dans les régions AWS avec 3-AZ. Actuellement, la région AWS de Californie du Nord ne prend pas en charge la technologie 3-AZ et n'est donc pas adaptée au mode Multi-AZ avec Standby.
• Le nombre de nœuds de données doit être un multiple de trois.
• Le nombre de copies de données (primaire et réplique) doit être un multiple de trois.
• Suivez les directives de dimensionnement pour le leader (taille recommandée en fonction du nombre de nœuds, du nombre de partitions et du nombre de mappages dans votre cluster).

Avec Multi-AZ avec Standby, Amazon OpenSearch Service détecte et répare automatiquement certaines défaillances de l'infrastructure. Amazon OpenSearch Service bascule automatiquement des nœuds actifs vers les nœuds de secours en moins d'une minute lorsque l'un des événements suivants se produit :

• Perte d'une zone de disponibilité active ou de tous les nœuds d'une zone de disponibilité active
• Perte de connectivité à une zone de disponibilité active
• Défaillance matérielle de l'instance dans la zone de disponibilité active
• Défaillance du stockage sur un nœud de la zone de disponibilité active

Actuellement, Multi-AZ avec Standby ne couvre pas les événements suivants :

• Perte du quorum principal, car le rétablissement après cet événement peut prendre plusieurs minutes
• Plusieurs zones de disponibilité
• Perte de connectivité à une région
• Perte de plus de 50 % de nœuds dans plusieurs zones de disponibilité
• Temps d'arrêt dû à une insuffisance de calcul ou de stockage en raison d'une modification des caractéristiques de la charge de travail
• Temps d'arrêt dû à des requêtes intempestives
• Perte d'un ou de plusieurs services dont dépend Amazon OpenSearch Service, tels que ARPS et ALB
• Indisponibilité d'OpenSearch Dashboard pendant les mises à niveau de version

Non. En principe, les directives de dimensionnement restent les mêmes. Le Multi-AZ avec Standby comporte des prérequis qui simplifient le modèle mental requis pour dimensionner le cluster. En ce qui concerne le dimensionnement d'un cluster géré, vous devez prendre en compte la capacité requise pour répondre à votre charge de travail, puis ajouter 50 % pour la redondance. La principale différence entre l'option « Prise en compte de zone » actuelle et l'option Multi-AZ avec veille réside dans la manière dont les capacités redondantes ou supplémentaires sont gérées pour maintenir la disponibilité. Le mode multi-AZ avec mode veille nécessite que vous disposiez d'au moins une copie des données dans chaque zone de disponibilité, afin que le mode multi-AZ avec mode veille puisse réserver de la capacité de manière explicite dans une zone de disponibilité. Cette capacité de secours fait office de cible de basculement en cas d'interruption de AZ ou de défaillance d'une instance. Le modèle existant exige que vous mainteniez des niveaux de ressources optimaux pour répondre à votre charge de travail. Vous continueriez à surveiller votre cluster pour détecter les problèmes de dimensionnement et à prendre des mesures correctives à mesure que les caractéristiques de la charge de travail évoluent.

Non. Amazon OpenSearch Service fonctionne selon un modèle de responsabilité partagée. Vous êtes responsable de vous assurer que la taille de votre cluster est adaptée à votre charge de travail. Multi-AZ avec Standby simplifient le modèle mental de configuration de votre cluster. Vous devez continuer à surveiller les indicateurs d'erreur et de latence ainsi que l'utilisation du stockage, du processeur et de la RAM pour détecter les signaux indiquant que le cluster est surchargé et qu'il peut être nécessaire de le dimensionner.

Non. La fonctionnalité Multi-AZ avec veille est disponible sans frais supplémentaires. Vous continuez à payer pour les ressources déployées sur le cluster pour répondre à votre charge de travail. Si votre cluster suit déjà les meilleures pratiques et possède au moins trois copies des données d'un cluster 3-AZ, il est peu probable que le passage à Multi-AZ avec Standby entraîne des coûts supplémentaires. Toutefois, si votre cluster est sous-dimensionné ou ne dispose pas d'une capacité redondante suffisante pour répondre à votre charge de travail, vous devrez ajouter de la capacité pour passer à Multi-AZ avec Standby afin d'améliorer la disponibilité et les performances. La capacité de réserve est réservée à partir de la capacité totale configurée.

Notre contrat de niveau de service (SLA) Amazon OpenSearch Service garantit un pourcentage de disponibilité mensuel d'au moins 99,9 % pour Amazon OpenSearch Service.

Vous êtes éligible à un crédit de contrat de niveau de service pour Amazon OpenSearch Service conformément au contrat de niveau de service Amazon OpenSearch Service si le pourcentage des déploiements multi-AZ sur Amazon OpenSearch Service est inférieur à 99,9 % au cours de n'importe quel cycle de facturation mensuelle.

Pour consulter l’intégralité des conditions générales du contrat de niveau de service et en savoir plus sur la marche à suivre pour soumettre une demande, référez-vous à la page d’informations du contrat de niveau de service d’Amazon OpenSearch Service.

La recherche croisée est une fonction Elasticsearch et OpenSearch qui permet d'effectuer des requêtes et des agrégations entre deux clusters connectés. Elle fonctionne en établissant une connexion unidirectionnelle légère entre les clusters participants.

Les domaines qui prennent part à une recherche croisée doivent répondre aux critères suivants :

• Les domaines participants doivent tourner sur OpenSearch ou Elasticsearch version 6.8 ou supérieure
• Les domaines participants doivent avoir le chiffrement en transit activé
• Les domaines participants doivent avoir le contrôle d'accès à grains fins (FGAC) activé
• Les versions des domaines participants doivent respecter les mêmes règles que la mise à niveau de version en place.

La recherche croisée est actuellement prise en charge par les types d’instances suivants :

• Famille i2, i3
• Famille r3, r4, r5
• Famille m4, m5
• Famille c4, c5
• Famille Graviton

La recherche croisée n’est pas prise en charge par les familles d'instances t2 et m3 en raison de limitations techniques.

Oui. Les domaines participants peuvent appartenir à deux comptes AWS différents.

Oui.

Pour démarrer la recherche croisée, consultez la documentation disponible ici.

La réplication entre clusters est une nouvelle fonctionnalité qui permet aux clients Amazon OpenSearch Service d'automatiser la copie et la synchronisation des index d'un cluster à un autre avec une faible latence dans la même région AWS ou dans différentes régions AWS.

Les domaines qui participent à une réplication entre clusters doivent répondre aux critères suivants :

• Les domaines participants doivent exécuter Elasticsearch version 7.10.
• Les domaines participants doivent avoir le chiffrement des données en transit activé.
• Les domaines participants doivent avoir le contrôle d'accès à grains fins (FGAC) activé
• Les versions des domaines participants doivent respecter les mêmes règles que la mise à niveau de version en place.

Oui. Des domaines de deux régions AWS différentes peuvent participer à la réplication entre clusters.

Non. L'implémentation actuelle de la réplication entre clusters ne prend pas en charge UltraWarm et le stockage à froid.

Oui. Vous devez payer des frais standard de transfert de données AWS pour les données transférées vers et depuis Amazon OpenSearch Service.

Le 12 avril 2021, nous avons annoncé le projet OpenSearch, un fork en open source axé sur la communauté d'Elasticsearch et de Kibana. Nous nous sommes engagés à investir dans le projet OpenSearch sur le long terme pour nous assurer que les utilisateurs continuent à bénéficier d'une suite de recherche et d'analyse sécurisée, de haute qualité et entièrement en open source, et dotée d'une feuille de route enrichie d'une nouvelle fonctionnalité innovante. Ce projet inclut OpenSearch (dérivé d'Elasticsearch 7.10.2) et d'OpenSearch Dashboards (dérivé de Kibana 7.10.2). Nous avons lancé la version 1.0 d'OpenSearch le 12 juillet 2021. Dans le cadre de notre engagement à long terme dans le projet OpenSearch, nous avons ajouté la prise en charge du service géré d'OpenSearch 1.0 jusqu'au 7 septembre 2021, et changé le nom Amazon Elasticsearch Service en Amazon OpenSearch Service. Avec OpenSearch 1.0, nous continuons à prendre en charge les versions héritées d'Elasticsearch jusqu'à la version 7.10 du service. À part ce changement de nom, vous pouvez être certain que nous continuerons à vous proposer la même expérience de qualité sans aucun impact sur vos opérations en cours, votre méthodologie de développement ou votre cas d'utilisation. Découvrez-en plus sur OpenSearch ici : https://opensearch.org

Nous nous sommes efforcés de rendre ce changement de nom aussi fluide que possible. Il existe des aspects, tels que le nouveau kit SDK ou les nouvelles API de configuration, pour lesquels vous devez effectuer des actions afin de vous assurer de bénéficier des meilleurs avantages du service. Bien que le kit SDK existant continuera de fonctionner dans une perspective de compatibilité, toute nouvelle fonctionnalité nécessitant les nouvelles API de configuration sera implantée dans le nouveau kit SDK uniquement. Nous vous recommandons donc d'adopter le nouveau kit SDK. De plus, indépendamment du nouveau kit SDK, nous vous recommandons vivement d'adopter de nouvelles politiques IAM afin d'utiliser les API de configuration renommées. Pour le moment, vos politiques IAM existantes continueront de fonctionner avec l'ancienne définition d'API. Cependant, nous adopterons la nouvelle validation d'autorisation basée sur des API et nous finirons par exiger de vous que vous utilisiez les nouvelles API dans vos politiques (en particulier pour les API dont le nom a été changé, par ex., CreateElasticsearchDomain qui est devenu CreateDomain). Consultez la documentation pour plus de détails.

Non. Dans le cadre de la rétrocompatibilité, nous veillerons à ce que votre configuration actuelle continue à fonctionner avec OpenSearch 1.0. Cependant, nous vous recommandons tout de même d'adopter le dernier kit SDK afin de bénéficier d'une meilleure expérience à jour, tel que mentionné ci-dessus.

Non. Il n'y a pas de nouvelle tarification.

OpenSearch comprend certains codes Elasticsearch sous licence Apache d'Elasticsearch B.V. et d'autres codes sources. Elasticsearch B.V. n'est pas la source de cet autre code source. ELASTICSEARCH est une marque déposée d'Elasticsearch B.V.

Avec OpenSearch 1.x, vous êtes sûr que l'infrastructure de votre recherche est construite sur un projet open source évolutif et dynamique avec une licence Apache. Vous avez également accès à une myriade d'améliorations innovantes fonctionnalités disponibles dans OpenSearch 1.2 (comme cette écriture).  Les fonctionnalités telles que la sécurité professionnelle, la possibilité d'alerte, la gestion du cycle de vie des données, l'observabilité, la détection des anomalies par la machine, etc. sont toutes disponibles gratuitement dans OpenSearch Service.

Nous utilisons un processus de déploiement bleu/vert (BV) durant la mise à niveau. Durant la période BV, le service ajoute des nœuds au cluster d'OpenSearch Service dans la nouvelle configuration et la nouvelle version, il fait migrer les données depuis les anciens nœuds et abandonne ces derniers une fois la migration des données terminée. Durant la période BV, la recherche et l'indexation des API sont disponibles et fonctionnent normalement. Bien que la période BV soit conçue pour ne pas interférer avec les enquêtes et les requêtes d'indexation, certains changements (en particulier ceux impliquant la modification de paramètres relatifs à la sécurité) peuvent entraîner l'indisponibilité du tableau de bord durant la période de changement.

OpenSearch prend en charge plusieurs versions d’Elasticsearch et d’OpenSearch, dont certaines ont déjà annoncé la fin de la période de support standard et la date d’extension du support. Pour obtenir la liste complète des versions du moteur et les dates de support correspondantes, veuillez consulter la documentation. Pour plus d’informations sur le support étendu, veuillez consulter le support étendu.

AWS conserve 19 versions d'Elasticsearch sous licence Apache 2.0. Aucune de ces versions n'est désapprouvée pour le moment et aucune désapprobation n'est prévue.

Oui, la mise à niveau déclenchera un processus de déploiement d'une période BV. Veuillez consulter la préparation et les étapes de la mise à niveau ici.

Veuillez vous concerter avec votre équipe de compte AWS pour ce qui concerne votre situation spécifique avec les RI.

Le projet OpenSearch 1.0 est un dérivé de l'open source Elasticsearch 7.10.2. Il est compatible électroniquement avec Elasticsearch 7.10. Vous n'avez pas besoin de modifier votre utilisation. Pour migrer, vous pouvez mettre à niveau votre domaine vers la version Elasticsearch 7.10 depuis n'importe quelle version précédente dans les séries 6.x et 7.x. Puis, vous créez un aperçu et vous le restaurez dans un domaine fonctionnant dans OpenSearch Service 1.x. Certains clients ou certains outils inclut la vérification de la version ce qui peut un dysfonctionnement avec OpenSearch Service. Lorsque vous effectuez la mise à niveau, activez le mode de compatibilité pour réussir ces vérifications de version.

Dans la plupart des cas, vous pouvez continuer à utiliser vos clients existants. Les API et la fonctionnalité recherche principale sont compatibles avec la version 7.10.2 d'Elasticsearch. Si vous avez d'anciens clients, la vérification de la performance des clients ou la fonctionnalité de rentabilité des clients qui sont ciblés pour des versions plus anciennes d'Elasticsearch (telles que les versions principales 5 et 6), nous vous suggérons d'amener vos clients vers un standard de support minimum sur la version 7.10.2 pour assurer une meilleure transition.

Le projet OpenSearch supporte une large gamme de clients qui sont spécifiquement construits pour s'adresser aux versions OpenSearch du moteur sur Amazon OpenSearch Service. Vérifiez que vos clients figurent dans la liste des derniers clients OpenSearch et qu’ils prennent en charge les langages de programmation compatibles.

Vous pouvez activer le mode de compatibilité afin d’interagir avec les clients des autres vendeurs, mais n’oubliez pas de vérifier la version signalée dans OpenSearch. Activez ce paramètre pour vous assurer que le service réponde avec la version 7.10.2 aux clients développés en priorité pour la présentation du moteur OpenSearch.

Les indices d'Elasticsearch 5.x ne sont pas compatibles avec Elasticsearch 7.10 ou avec OpenSearch 1.x. Vous devez créer un nouvel index et télécharger les données depuis votre source. Si vous tenez un journal d'analyses de la charge de travail, vous pouvez évaluer si votre stratégie de conservation des données peut être conservée en parallèle de la construction d'un ensemble complet de données sur un nouveau domaine.

Oui. Veuillez écrire à opensearchmigration-si-support@amazon.com pour demander la liste des partenaires de votre région, de votre secteur et de votre projet. Les partenaires du réseau de partenaires AWS (APN) ont les qualifications et l’expérience nécessaires pour vous accompagner en ce qui concerne vos mises à niveau. 

OpenSearch 1.0 est un dérivé d'Elasticsearch 7.10.2. OpenSearch et Elasticsearch sont compatibles. Si vous activez le mode de compatibilité, les clients Elasticsearch sont également compatibles avec OpenSearch 1.0.

Amazon OpenSearch Service n'offre pas et n'offrira pas de nouvelles versions du moteur Elasticsearch après la version 7.10.2.

Comme l’a annoncé AWS lors de la création d’Elasticsearch, nous avons construit une communauté prospère autour de OpenSearch tel que nous en avions l’intention. Nous avons publié une feuille de route, achevée par l'entrée d'une communauté et du consensus sur les priorités des fonctionnalités. Nous ferons tous les efforts raisonnables possibles pour maintenir la compatibilité avec Elasticsearch. Notre objectif est de nous développer avec notre communauté et les clients Amazon OpenSearch Service.

Vous pouvez évoluer directement vers OpenSearch Service 1.0 depuis les versions 6.8.0 et 7.10.2 d'Elasticsearch et de Kibana et ouvrir une distribution pour Elasticsearch 1.x (ODFE). Pour les mises à niveau évolutives depuis ODFE vers OpenSearch, nous conseillons d'évoluer vers ODFE 1.13 dans un premier temps, puis d'évoluer vers OpenSearch 1.0.

Voici les ressources de migration :

Migrations de données d'analytique

Migration vers Amazon OpenSearch Service

Chaque version du moteur lancée dans OpenSearch Service est couverte par défaut par le support standard. Dans le cadre du support standard, AWS fournit régulièrement des correctifs de bogues et des mises à jour de sécurité. Lorsque le support standard prend fin pour une version, AWS propose une période de support étendue d’au moins 12 mois après la date de fin du support standard. Pendant la période de support étendu, AWS fournira des correctifs de sécurité et des correctifs de système d’exploitation critiques. Cela vous laisse plus de temps pour planifier votre mise à niveau vers une version plus récente du moteur prise en charge. Lorsque vous utilisez une version faisant l’objet d’un support étendu, des frais forfaitaires par heure d’instance normalisée (NIH) vous seront facturés, en plus des coûts d’instance et de stockage standard. Consultez la documentation pour plus d’informations sur le support étendu et le calendrier des différentes versions. Pour obtenir des informations sur la tarification, veuillez consulter la page de tarification.

Non. Les domaines dont les versions ont atteint la fin du support standard seront automatiquement couverts par le support étendu et seront facturés en conséquence. Une fois que vous aurez mis à niveau votre domaine vers une version plus récente dans le cadre du support standard, le support étendu ne vous sera plus facturé.

Les domaines qui utilisent le support étendu se verront facturer des frais forfaitaires supplémentaires par heure d’instance normalisée (NIH), en plus des tarifs standard d’instance et de stockage. Veuillez consulter la page de tarification pour connaître les prix exacts par région. Le support étendu sera automatiquement facturé à votre domaine le lendemain de la fin du support standard. Si votre domaine exécute une version dont les dates de support standard et étendu ont été publiées (voir ici pour plus de détails), nous vous enverrons une notification sur votre tableau de bord de santé personnel, sur la console OpenSearch Service et lors des événements EventBridge, trois mois avant la fin de la date de support standard. Pour plus d’informations sur la surveillance des notifications dans OpenSearch Service, consultez la documentation ici.

Les domaines exécutant des versions dans le cadre du support étendu seront soumis à des frais forfaitaires supplémentaires par heure d’instance normalisée (NIH). La NIH est calculée en fonction de la taille de l’instance (par exemple, moyenne ou grande) et du nombre d’heures d’instance. Par exemple, si vous exécutez une instance m7g.medium.search pendant 24 heures dans la région USA Est (Virginie du Nord), au prix de 0,068 USD de l’heure (à la demande), vous paierez généralement 1,632 USD (0,068 USD x 24) comme coût de l’instance. Si vous utilisez une version en support étendu, vous devrez payer 0,0065 USD supplémentaires par NIH, soit 0,0065 USD x 24 (nombre d’heures d’instance) x 2 (facteur de normalisation de la taille ; 2 pour les instances de taille moyenne), soit 0,312 USD pour le support étendu pendant 24 heures. Le montant total que vous devrez payer pour 24 heures sera la somme du coût d’utilisation standard de l’instance (hors stockage) et du coût du support étendu, qui est de 1,944 USD (1,632 USD + 0,312 USD). Pour plus d’informations, consultez la documentation.

Vous pouvez mettre à niveau votre domaine vers une version du moteur couverte par le support standard. Une version est couverte par le support standard jusqu’à la date de fin de publication du support standard, ou si aucune date de fin de support standard n’a été annoncée pour la version.

Non. Nous vous recommandons de passer à une version couverte par le support standard ou étendu ou à une version dont la fin du support n’a pas été annoncée. Une fois le support étendu terminé pour une version, les domaines exécutant la version spécifique ne recevront pas de correctifs de bogues ni de mises à jour de sécurité.

Une fois le support étendu terminé pour une version, nous ne publierons plus de correctifs de bogues ni de mises à jour de sécurité pour cette version spécifique. Les domaines dont les versions ne sont pas prises en charge seront isolés, et les données seront conservées pendant au moins 30 jours. Les domaines isolés ne sont plus accessibles, et vous devrez restaurer les données dans un nouveau domaine exécutant une version prise en charge. Nous vous recommandons vivement de mettre à jour votre domaine vers une version prise en charge avant la fin du support étendu pour une version spécifique. Si vous avez besoin d’une assistance supplémentaire, veuillez contacter AWS Support.

Oui. Tant que la version du moteur que vous souhaitez utiliser est couverte par le support étendu, vous pouvez continuer à utiliser le service comme d’habitude, sans aucune restriction.

Dans le cadre du support étendu, AWS fournit des correctifs de sécurité critiques et des correctifs de système d’exploitation selon les besoins.

Oui, en fonction de la version à partir de laquelle et vers laquelle vous effectuez la mise à niveau. Consultez la documentation ici pour obtenir la liste des procédures de mise à niveau prises en charge. Lorsque vous passez d’anciennes versions comme ES 1.5 ou ES 2.3, nous ne prenons pas en charge les mises à niveau sur place. Consultez la documentation disponible ici pour obtenir des instructions sur la mise à niveau de vos domaines exécutant des versions antérieures.

Cette intégration zéro ETL à Amazon DynamoDB élimine la complexité opérationnelle liée à l'orchestration de la réplication des données d'un entrepôt de données opérationnel vers un entrepôt de données de recherche. Les pipelines de données utilisés pour synchroniser les entrepôts de données différents peuvent être difficiles et coûteux à créer et à gérer, et présenter des erreurs intermittentes difficiles à suivre. Cette intégration permet aux clients Amazon DynamoDB d'obtenir des résultats de recherche en temps quasi réel à partir de leurs données transactionnelles en proposant une solution entièrement gérée permettant de rendre les données opérationnelles d'Amazon DynamoDB disponibles dans Amazon OpenSearch Service quelques secondes après leur rédaction.

L'intégration zéro ETL d'Amazon OpenSearch Service avec Amazon DynamoDB utilise Amazon OpenSearch Ingestion pour déplacer de manière transparente les données opérationnelles d'Amazon DynamoDB vers Amazon OpenSearch Service. Pour permettre une intégration, les clients choisissent d'abord la table Amazon DynamoDB dont les données doivent être répliquées. La fonctionnalité d'intégration zéro ETL met en place un pipeline d'ingestion Amazon OpenSearch dans le compte du client qui se charge de répliquer les données vers un cluster géré par Amazon OpenSearch Service ou une collection sans serveur. L'ingestion Amazon OpenSearch comprend la structure des tables Amazon DynamoDB, puis démarre un cluster géré par Amazon OpenSearch Service équivalent ou une collection sans serveur avec les données existantes des tables DynamoDB. Les clients peuvent éventuellement spécifier un schéma pour les index qui seront créés dans Amazon OpenSearch Service. Toute mise à jour de la table DynamoDB est également répliquée sur Amazon OpenSearch Service sans aucune intervention manuelle de la part des clients.

Cette fonctionnalité zéro ETL utilise Amazon OpenSearch Ingestion pour déplacer les données d'Amazon DynamoDB vers Amazon OpenSearch Service et exploite les capacités natives de transformation des données des pipelines Amazon OpenSearch Ingestion pour agréger et filtrer les données pendant qu'elles sont en mouvement. Lorsqu'ils déplacent les données d'une table Amazon DynamoDB, les clients peuvent souhaiter supprimer quelques champs ou en créer de nouveaux en fonction des agrégations entre les champs existants. En option, les clients peuvent également écrire une logique personnalisée pour l'ingestion Amazon OpenSearch afin d'obtenir une capacité de transformation sur mesure. Pour les autres utilisateurs, qui souhaitent simplement déplacer l'intégralité de leurs données de la source vers le récepteur, Amazon OpenSearch Ingestion fournit des plans prêts à l'emploi afin qu'ils puissent effectuer les intégrations en quelques clics.

Afin de garantir que l'ingestion Amazon OpenSearch dispose des autorisations nécessaires pour répliquer les données sur ces deux systèmes, la fonctionnalité d'intégration zéro ETL crée un rôle IAM doté des autorisations nécessaires pour lire les données des tables Amazon DynamoDB et les écrire dans un domaine ou une collection Amazon OpenSearch. Ce rôle est ensuite assumé par les pipelines d'ingestion Amazon OpenSearch afin de garantir que la bonne posture de sécurité est toujours maintenue lors du déplacement des données de la source vers la destination.

Vous pouvez consulter toutes les métriques relatives à votre intégration zéro ETL à Amazon DynamoDB dans les tableaux de bord fournis par Amazon OpenSearch Ingestion ainsi que dans les journaux en temps réel d’Amazon CloudWatch. Cela permet aux clients de mettre en place des alertes personnalisées qui se déclenchent lorsque des seuils définis par l'utilisateur sont dépassés.

Le moteur de requête OpenSearch Service a été réarchitecturé pour prendre en charge l'analyse des données opérationnelles stockées dans des magasins d'objets cloud, tels qu'Amazon S3 et les lacs de données basés sur S3. Il le fait sans dupliquer les données. Lorsque les secondes font la différence, les clients peuvent améliorer les performances de leurs requêtes et créer des tableaux de bord à chargement rapide en utilisant des fonctionnalités intégrées d'accélération des requêtes de la nouvelle intégration.

Pour démarrer à partir de la console de gestion AWS, les clients configurent une nouvelle source de données à partir d’un domaine OpenSearch Service existant exécutant OpenSearch Service version 2.11 ou une version supérieure. Lors de la configuration de la nouvelle source de données Direct Query, les clients devront fournir un accès en lecture et écriture à Amazon S3 et au catalogue de données AWS Glue pour faciliter l'interrogation des données dans Amazon S3 à partir d'OpenSearch Service. Les clients peuvent personnaliser les politiques IAM afin de restreindre l'accès à des compartiments spécifiques dans Amazon S3 ou à des ressources dans le catalogue de données AWS Glue. Après avoir configuré la nouvelle source de données dans la console, les clients iront dans OpenSearch Service pour configurer les contrôles d'accès basés sur les rôles, les accélérations pour accélérer les performances des requêtes et, en option, les tableaux de bord prêts à l'emploi pour les modèles de types de journaux populaires tels que les journaux de flux VPC, les journaux Elastic Load Balancer et les journaux NGINX. Les clients sont facturés pour les ressources de calcul consommées sous la forme d'unités de calcul OpenSearch de Direct Query (OCU ; les taux d'utilisation s'appliquent). Après avoir configuré la nouvelle source de données, les clients peuvent commencer à interroger leurs données directement à partir de l'API OpenSearch ou des tableaux de bord OpenSearch.

Les clients ne paient que pour les ressources consommées par leur charge de travail. OpenSearch Service facture uniquement le calcul nécessaire pour interroger directement les données externes et gérer les index facultatifs dans OpenSearch Service. La capacité de calcul est mesurée en unités de calcul OpenSearch (OCU), qui sont les mêmes unités que celles utilisées par Amazon OpenSearch sans serveur et Amazon OpenSearch Ingestion. Le nombre d'OCU correspond directement au processeur virtuel et à la mémoire nécessaires pour interroger ou gérer des index en fonction des données. Les clients verront une entrée pour le calcul en OCU-heures avec l'étiquette pour la requête directe. Les OCU sont facturées sur une base horaire avec une granularité par minute. Si aucune requête ou activité d'indexation n'est active, aucune OCU n'est consommée. Les coûts pour Amazon S3 ou le catalogue de données AWS Glue seront facturés séparément dans le compte du client. Pour plus d’informations sur la tarification, consultez la page de tarification d’Amazon OpenSearch Service.

L’intégration entre Amazon OpenSearch Service et Amazon Security Lake fournit une expérience rationalisée pour effectuer des recherches directes, obtenir des informations et analyser les données stockées dans Security Lake, le tout dans le cadre du service OpenSearch. Il existe deux façons d’intégrer Security Lake et OpenSearch Service : l’intégration par accès aux requêtes et l’intégration par accès aux données.

Avec l’intégration par accès aux requêtes, les analystes en sécurité peuvent utiliser la console OpenSearch Dashboards pour exécuter des requêtes directes sur les données de Security Lake et tirer parti de l’indexation à la demande ainsi que des contenus pré-construits pour démarrer avec des requêtes liées à la sécurité. Pour l’intégration par accès aux données, le service d’ingestion OpenSearch fournit un plan pré-configuré pour Security Lake, qui inclut une configuration par défaut permettant d’ingérer des fichiers parquet du cadre Open Cybersecurity Schema Framework (OCSF) depuis Security Lake. L’intégration zéro ETL avec Security Lake n’est proposée que sur les collections dotées de l’interface utilisateur OpenSearch, et non sur les clusters.

Pour commencer, vous devez d’abord disposer d’une configuration Security Lake existante dans votre environnement AWS. Cela permettra de centraliser le stockage et l’accès aux données de sécurité de votre entreprise.

Vous pouvez ensuite activer l’intégration entre les deux services via la console de gestion AWS ou en utilisant les modèles AWS CloudFormation. Cela implique de configurer les autorisations et les contrôles d’accès nécessaires pour permettre à Amazon OpenSearch Service d’accéder aux données de votre Security Lake et de les interroger en toute sécurité.

Vous pouvez ensuite explorer les requêtes et intégrations prédéfinies disponibles via OCSF pour vous familiariser rapidement avec les cas d’utilisation courants de l’analytique de sécurité. Vous avez également la possibilité de configurer l’indexation à la demande d’ensembles de données spécifiques de votre Security Lake dans OpenSearch Service pour des besoins analytiques et de visualisation avancés.