Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Amazon OpenSearch sans serveur
Amazon OpenSearch Serverless est une configuration auto-scalante à la demande pour Amazon OpenSearch Service. Contrairement aux OpenSearch domaines provisionnés, qui nécessitent une gestion manuelle de la capacité, une collection OpenSearch Serverless adapte automatiquement les ressources informatiques en fonction des besoins de votre application.
OpenSearch Serverless offre une solution rentable pour les charges de travail peu fréquentes, intermittentes ou imprévisibles. Il optimise les coûts en adaptant automatiquement la capacité de calcul en fonction de l'utilisation de votre application. Les collections sans serveur utilisent le même volume de stockage à haute capacité, distribué et hautement disponible que les domaines de service provisionnés OpenSearch .
OpenSearch Les collections sans serveur sont toujours cryptées. Vous pouvez choisir la clé de chiffrement, mais vous ne pouvez pas désactiver le chiffrement. Pour de plus amples informations, consultez [Chiffrement dans Amazon OpenSearch Serverless](serverless-encryption.md).
## Avantages
OpenSearch Le mode Serverless présente les avantages suivants :
+ **Plus simple que le provisionnement** : le mode OpenSearch sans serveur élimine une grande partie de la complexité liée à la gestion des OpenSearch clusters et de la capacité. Il dimensionne et ajuste automatiquement vos clusters et prend en charge la gestion du cycle de vie des partitions et des index. Il gère également les mises à jour des logiciels de service et les mises à niveau des OpenSearch versions. Toutes les mises à jour et mises à niveau se font sans interruption de service.
+ **Rentable** — Lorsque vous utilisez OpenSearch Serverless, vous ne payez que pour les ressources que vous consommez. Il n'est donc plus nécessaire de procéder à une allocation initiale et à une surallocation pour les charges de travail de pointe.
+ **Haute disponibilité** : OpenSearch Serverless prend en charge les charges de travail de production grâce à la redondance afin de se protéger contre les pannes de zone de disponibilité et les défaillances d'infrastructure.
+ **Évolutif** — OpenSearch Serverless adapte automatiquement les ressources afin de maintenir des taux d'ingestion de données et des temps de réponse aux requêtes toujours rapides.
# Qu'est-ce qu'Amazon OpenSearch Serverless ?
Amazon OpenSearch Serverless est une option sans serveur à la demande pour Amazon OpenSearch Service qui élimine la complexité opérationnelle liée au provisionnement, à la configuration et au réglage des clusters. OpenSearch C'est la solution idéale pour les entreprises qui préfèrent ne pas gérer elles-mêmes leurs clusters ou qui ne disposent pas des ressources et de l'expertise nécessaires pour effectuer des déploiements à grande échelle. Avec OpenSearch Serverless, vous pouvez rechercher et analyser de gros volumes de données sans gérer l'infrastructure sous-jacente.
Une *collection OpenSearch * sans serveur est un groupe d' OpenSearch index qui fonctionnent ensemble pour prendre en charge une charge de travail ou un cas d'utilisation spécifique. Les collections simplifient les opérations par rapport aux OpenSearch clusters autogérés, qui nécessitent un provisionnement manuel.
Les collections utilisent le même stockage à haute capacité, distribué et hautement disponible que les domaines de OpenSearch service provisionnés, mais réduisent encore la complexité en éliminant la configuration et le réglage manuels. Les données d'une collection sont cryptées pendant le transfert. OpenSearch Serverless prend également en charge les OpenSearch tableaux de bord, fournissant une interface pour l'analyse des données.
Actuellement, les collections sans serveur exécutent la OpenSearch version 2.17.x. À mesure que de nouvelles versions sont publiées, OpenSearch Serverless met automatiquement à niveau les collections pour intégrer de nouvelles fonctionnalités, des corrections de bogues et des améliorations de performances.
OpenSearch Serverless prend en charge les mêmes opérations d'API d'ingestion et de requête que la suite OpenSearch open source, ce qui vous permet de continuer à utiliser vos clients et applications existants. Vos clients doivent être compatibles avec la OpenSearch version 2.x pour fonctionner avec OpenSearch Serverless. Pour de plus amples informations, veuillez consulter [Ingestion de données dans des collections Amazon OpenSearch Serverless](serverless-clients.md).
**Topics**
+ [Cas d'utilisation du mode OpenSearch Serverless](#serverless-use-cases)
+ [Comment ça marche](#serverless-process)
+ [Choix d'un type de collection](#serverless-usecase)
+ [Tarification](#serverless-pricing)
+ [Soutenu Régions AWS](#serverless-regions)
+ [Limitations](#serverless-limitations)
+ [Comparaison entre le OpenSearch service et le mode OpenSearch sans serveur](serverless-comparison.md)
## Cas d'utilisation du mode OpenSearch Serverless
OpenSearch Serverless prend en charge deux principaux cas d'utilisation :
+ **Analyse des journaux** : le segment d'analyse des journaux se concentre sur les grands volumes de données de séries temporelles semi-structurées et générées par des machines, afin d'obtenir des informations sur les opérations et le comportement des utilisateurs.
+ **Recherche en texte intégral** : le segment de recherche en texte intégral alimente les applications de vos réseaux internes (systèmes de gestion de contenu, documents juridiques) et les applications accessibles sur Internet, telles que la recherche de contenu sur les sites web de commerce en ligne.
Lorsque vous créez une collection, vous choisissez l'un de ces cas d'utilisation. Pour de plus amples informations, veuillez consulter [Choix d'un type de collection](#serverless-usecase).
## Comment ça marche
Les OpenSearch clusters traditionnels possèdent un ensemble unique d'instances qui effectuent à la fois des opérations d'indexation et de recherche, et le stockage d'index est étroitement lié à la capacité de calcul. En revanche, OpenSearch Serverless utilise une architecture native pour le cloud qui sépare les composants d'indexation (ingestion) des composants de recherche (requête), Amazon S3 étant le principal stockage de données pour les index.
Cette architecture découplée vous permet de mettre à l'échelle les fonctions de recherche et d'indexation indépendamment les unes des autres et indépendamment des données indexées dans S3. L'architecture permet également d'isoler les opérations d'ingestion et de requête afin qu'elles puissent s'exécuter simultanément sans conflit de ressources.
Lorsque vous écrivez des données dans une collection, OpenSearch Serverless les distribue aux unités de calcul *d'indexation*. Les unités de calcul d'indexation ingèrent les données entrantes et déplacent les index vers S3. Lorsque vous effectuez une recherche sur les données de collecte, OpenSearch Serverless achemine les demandes vers les unités *de calcul de recherche* qui contiennent les données demandées. Les unités de calcul de recherche téléchargent les données indexées directement depuis S3 (si elles ne sont pas déjà mises en cache localement), exécutent des opérations de recherche et effectuent des regroupements.
L'image suivante illustre cette architecture découplée :
![\[Diagram showing indexing and search processes using compute units and Amazon S3 storage.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/Serverless.png)
OpenSearch La capacité de calcul sans serveur pour l'ingestion, la recherche et l'interrogation de données est mesurée en unités de OpenSearch calcul ()OCUs. Chaque OCU est une combinaison de 6 Gio de mémoire et du processeur virtuel (vCPU) correspondant et crée un transfert de données vers Amazon S3. Chaque OCU comprend suffisamment de stockage éphémère à chaud pour 120 Gio de données d'index.
Lorsque vous créez votre première collection, OpenSearch Serverless en instancie deux, l'une pour l'indexation OCUs et l'autre pour la recherche. Afin de garantir une haute disponibilité, il lance également un ensemble de nœuds de secours dans une autre zone de disponibilité. À des fins de développement et de test, vous pouvez désactiver le paramètre **Activer la redondance** pour une collection, ce qui élimine les deux répliques de secours et n'en instancie que deux. OCUs Par défaut, les répliques actives redondantes sont activées, ce qui signifie qu'un total de quatre répliques OCUs sont instanciées pour la première collection d'un compte.
Ils OCUs existent même lorsqu'il n'y a aucune activité sur les points de terminaison de collecte. Toutes les collections suivantes les partagent OCUs. Lorsque vous créez des collections supplémentaires dans le même compte, OpenSearch Serverless en ajoute uniquement OCUs pour la recherche et l'ingestion si nécessaire pour prendre en charge les collections, conformément aux [limites de capacité](serverless-scaling.md#serverless-scaling-configure) que vous spécifiez. La capacité diminue à mesure que votre utilisation des ressources informatiques diminue.
Pour plus d'informations sur la façon dont ces frais vous sont facturés OCUs, consultez[Tarification](#serverless-pricing).
## Choix d'un type de collection
OpenSearch Serverless prend en charge trois types de collecte principaux :
**Séries chronologiques** : segment d'analyse des journaux qui analyse de grands volumes de données semi-structurées générées par des machines en temps réel, fournissant des informations sur les opérations, la sécurité, le comportement des utilisateurs et les performances de l'entreprise.
**Recherche : recherche** en texte intégral qui active les applications des réseaux internes, telles que les systèmes de gestion de contenu et les référentiels de documents juridiques, ainsi que les applications Internet telles que la recherche sur les sites de commerce électronique et la découverte de contenu.
**Recherche vectorielle** — La recherche sémantique sur les intégrations vectorielles simplifie la gestion des données vectorielles et permet des expériences de recherche augmentées par le machine learning (ML). Il prend en charge les applications d'IA génératives telles que les chatbots, les assistants personnels et la détection des fraudes.
Vous choisissez un type de collection lorsque vous créez une collection pour la première fois :
![\[Three collection type options: Time series, Search, and Vector search for different data use cases.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-collection-type.png)
Le type de collection que vous choisissez dépend du type de données que vous prévoyez d'intégrer à la collection et de la manière dont vous allez les interroger. Vous ne pouvez pas modifier le type de la collection après l'avoir créée.
Les types de collection présentent les **différences** notables suivantes :
+ Pour les collections *de recherche* et *de recherche vectorielle*, toutes les données sont stockées dans un espace de stockage à chaud afin de garantir des temps de réponse rapides aux requêtes. Les collections de *séries temporelles* utilisent une combinaison de stockage à chaud et tiède, les données les plus récentes étant conservées dans un stockage hot afin d'optimiser les temps de réponse aux requêtes pour les données les plus fréquemment consultées.
+ Pour les *séries chronologiques* et les collections *de recherche vectorielle*, vous ne pouvez pas indexer par identifiant de document personnalisé ni mettre à jour par des requêtes upsert. Cette opération est réservée aux cas d'utilisation de recherche. Vous pouvez plutôt effectuer une mise à jour par numéro de document. Pour de plus amples informations, veuillez consulter [Opérations et autorisations d' OpenSearch API prises en charge](serverless-genref.md#serverless-operations).
+ Pour les *recherches* et les collections de *séries chronologiques*, vous ne pouvez pas utiliser d'index de type K-nn.
## Tarification
AWS vous facture les composants OpenSearch sans serveur suivants :
+ Calcul d'ingestion de données
+ Calcul de recherche et de requêtes
+ Stockage conservé dans Amazon S3
Une OCU comprend 6 Go de RAM, le vCPU GP3 correspondant, le stockage et le transfert de données vers Amazon S3. La plus petite unité qui peut vous être facturée est de 0,5 OCU. AWS facture OCU sur une base horaire, avec une granularité de second niveau. Dans votre relevé de compte, vous voyez une entrée pour le calcul en heures OCU avec une étiquette pour l'ingestion de données et une étiquette pour la recherche. AWS vous facture également sur une base mensuelle pour les données stockées dans Amazon S3. L'utilisation des OpenSearch tableaux de bord ne vous est pas facturée.
Lorsque vous créez une collection avec des répliques actives redondantes, un minimum de 1 OCU (0,5 OCU × 2) vous est facturé pour l'ingestion, y compris les répliques principale et de secours, et 1 OCU (0,5 OCU × 2) pour la recherche :
+ 1 OCU (0,5 OCU × 2) pour l'ingestion, y compris l'unité primaire et la dose de réserve
+ 1 OCU (0,5 OCU × 2) pour la recherche
Si vous désactivez les répliques actives redondantes, un minimum de 1 OCU (0,5 OCU x 2) vous sera facturé pour la première collecte enregistrée sur votre compte. Toutes les collections suivantes peuvent les partager OCUs.
OpenSearch Serverless ajoute des unités supplémentaires par incréments de 1 OCU OCUs en fonction de la puissance de calcul et du stockage nécessaires pour prendre en charge vos collections. Vous pouvez configurer un nombre maximum de OCUs pour votre compte afin de contrôler les coûts.
**Note**
Les collections uniques ne AWS KMS keys peuvent pas être partagées OCUs avec d'autres collections.
OpenSearch Serverless tente d'utiliser les ressources minimales requises pour tenir compte de l'évolution des charges de travail. Le nombre de OCUs fournitures fournies à tout moment peut varier et n'est pas exact. Au fil du temps, l'algorithme utilisé par OpenSearch Serverless continuera de s'améliorer afin de mieux minimiser l'utilisation du système.
Pour en savoir plus sur les tarifs, consultez les [tarifs d'Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/pricing/).
## Soutenu Régions AWS
OpenSearch Serverless est disponible dans un sous-ensemble de Régions AWS ce OpenSearch service disponible dans. Pour obtenir la liste des régions prises en charge, consultez la section [Points OpenSearch de terminaison et quotas Amazon Service](https://docs.aws.amazon.com/general/latest/gr/opensearch-service.html) dans le *Références générales AWS*.
## Limitations
OpenSearch Le mode Serverless présente les limites suivantes :
+ Certaines opérations OpenSearch d'API ne sont pas prises en charge. Consultez [Opérations et autorisations d' OpenSearch API prises en charge](serverless-genref.md#serverless-operations).
+ Certains OpenSearch plugins ne sont pas pris en charge. Consultez [OpenSearch Plugins pris en charge](serverless-genref.md#serverless-plugins).
+ Il n'existe actuellement aucun moyen de migrer automatiquement vos données d'un domaine de OpenSearch service géré vers une collection sans serveur. Vous devez réindexer vos données d'un domaine vers une collection.
+ L'accès intercompte aux collections n'est pas pris en charge. Vous ne pouvez pas inclure les collections provenant d'autres comptes dans vos stratégies de chiffrement ou d'accès aux données.
+ Les OpenSearch plugins personnalisés ne sont pas pris en charge.
+ Les instantanés automatisés sont pris en charge pour les collections OpenSearch sans serveur. Les instantanés manuels ne sont pas pris en charge. Pour de plus amples informations, veuillez consulter [Sauvegarde de collections à l'aide de snapshots](serverless-snapshots.md).
+ La recherche et la réplication entre régions ne sont pas prises en charge.
+ Le nombre de ressources sans serveur que vous pouvez avoir dans un seul compte et une seule région est limité. Voir [Quotas OpenSearch sans serveur](https://docs.aws.amazon.com/general/latest/gr/opensearch-service.html#opensearch-limits-serverless).
+ L'intervalle d'actualisation des index dans les collections de recherche vectorielle est d'environ 60 secondes. L'intervalle d'actualisation des index dans les recherches et les collections de séries chronologiques est d'environ 10 secondes.
+ Le nombre de partitions, le nombre d'intervalles et l'intervalle d'actualisation ne sont pas modifiables et sont gérés par OpenSearch Serverless. La stratégie de partitionnement est basée sur le type de collecte et le trafic. Par exemple, une collection de séries chronologiques redimensionne les partitions primaires en fonction des goulots d'étranglement du trafic d'écriture.
+ Les fonctionnalités géospatiales disponibles sur OpenSearch les versions jusqu'à 2.1 sont prises en charge.
# Comparaison entre le OpenSearch service et le mode OpenSearch sans serveur
Dans OpenSearch Serverless, certains concepts et fonctionnalités sont différents de leurs fonctionnalités correspondantes pour un domaine de OpenSearch service provisionné. Par exemple, une différence importante est que OpenSearch Serverless n'a pas le concept de cluster ou de nœud.
Le tableau suivant décrit en quoi les fonctionnalités et concepts importants de OpenSearch Serverless diffèrent des fonctionnalités équivalentes dans un domaine de OpenSearch service provisionné.
| Fonctionnalité | OpenSearch Service | OpenSearch Sans serveur |
| --- | --- | --- |
| **Domaines vs. collections** | Les index sont conservés dans des *domaines*, qui sont des clusters pré-provisionnés OpenSearch . Pour de plus amples informations, veuillez consulter [Création et gestion de domaines Amazon OpenSearch Service](createupdatedomains.md). | Les index sont conservés dans des *collections*, qui sont des regroupements logiques d'index qui représentent une charge de travail ou un cas d'utilisation spécifique. Pour de plus amples informations, veuillez consulter [Gestion des collections Amazon OpenSearch Serverless](serverless-manage.md). |
| **Types de nœuds et gestion de la capacité** | Vous créez un cluster avec des types de nœuds qui répondent à vos spécifications en matière de coûts et de performances. Vous devez calculer vos besoins en stockage et choisir un type d'instance pour votre domaine. Pour de plus amples informations, veuillez consulter [Dimensionnement des domaines Amazon OpenSearch Service](sizing-domains.md). | OpenSearch Serverless adapte et fournit automatiquement des unités de calcul supplémentaires pour votre compte en fonction de l'utilisation de votre capacité. Pour de plus amples informations, veuillez consulter [Gestion des limites de capacité pour Amazon OpenSearch Serverless](serverless-scaling.md). |
| **Facturation** | Vous payez chaque heure d'utilisation d'une instance EC2 et selon la taille cumulée des volumes de stockage EBS associés à vos instances. Pour de plus amples informations, veuillez consulter [Tarification d'Amazon OpenSearch Service](what-is.md#pricing). | Vous êtes facturé en heures d'OCU pour le calcul d'ingestion de données, le calcul de recherche et des requêtes, et le stockage conservé dans S3. Pour de plus amples informations, veuillez consulter [Tarification](serverless-overview.md#serverless-pricing). |
| **Chiffrement** | Le chiffrement au repos est *facultatif* pour les domaines. Pour de plus amples informations, veuillez consulter [Chiffrement des données au repos pour Amazon OpenSearch Service](encryption-at-rest.md). | Le chiffrement au repos est *requis* pour les collections. Pour de plus amples informations, veuillez consulter [Chiffrement dans Amazon OpenSearch Serverless](serverless-encryption.md). |
| **Contrôle d'accès aux données** | L'accès aux données au sein des domaines est déterminé par des politiques IAM et un [contrôle d'accès précis](fgac.md). | L'accès aux données au sein des collections est déterminé par des [stratégies d'accès aux données](serverless-data-access.md). |
| OpenSearchOpérations prises en charge | OpenSearch Le service prend en charge un sous-ensemble de toutes les opérations d' OpenSearch API. Pour de plus amples informations, veuillez consulter [Opérations prises en charge dans Amazon OpenSearch Service](supported-operations.md). | OpenSearch Serverless prend en charge un sous-ensemble différent d'opérations d' OpenSearch API. Pour de plus amples informations, veuillez consulter [Opérations et plug-ins pris en charge dans Amazon OpenSearch Serverless](serverless-genref.md). |
| Connexion aux tableaux de bord | Connectez-vous à l'aide d'un nom d'utilisateur et d'un mot de passe. Pour de plus amples informations, veuillez consulter [Accès aux OpenSearch tableaux de bord en tant qu'utilisateur principal](fgac.md#fgac-dashboards). | Si vous êtes connecté à la AWS console et que vous accédez à l'URL de votre tableau de bord, vous vous connecterez automatiquement. Pour de plus amples informations, veuillez consulter [Accès aux OpenSearch tableaux de bord](serverless-dashboards.md). |
| APIs | Interagissez par programmation avec le OpenSearch service à l'aide des opérations de l'[API du OpenSearch service](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html). | Interagissez par programmation avec OpenSearch Serverless à l'aide des opérations de l'API [OpenSearch Serverless](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/Welcome.html). |
| Accès réseau | Les paramètres réseau d'un domaine s'appliquent au point de terminaison du domaine ainsi qu'au point de terminaison OpenSearch des tableaux de bord. L'accès réseau pour ces deux points de terminaison est étroitement lié. | Les paramètres réseau du point de terminaison du domaine et du point de terminaison OpenSearch des tableaux de bord sont découplés. Vous pouvez choisir de ne pas configurer l'accès au réseau pour les OpenSearch tableaux de bord. Pour de plus amples informations, veuillez consulter [Accès au réseau pour Amazon OpenSearch Serverless](serverless-network.md). |
| Signature des requêtes | Utilisez les clients REST de OpenSearch haut et de bas niveau pour signer les demandes. Spécifiez le nom du service sous la forme `es`. | À l'heure actuelle, OpenSearch Serverless prend en charge un sous-ensemble de clients pris en charge par OpenSearch Service. Lorsque vous signez des requêtes, spécifiez le nom du service sous la forme `aoss`. L'en-tête `x-amz-content-sha256` est obligatoire. Pour de plus amples informations, veuillez consulter [Signature des demandes HTTP avec d'autres clients](serverless-clients.md#serverless-signing). |
| OpenSearch mises à niveau de version | Vous mettez à niveau manuellement vos domaines au fur et à mesure que de nouvelles versions de sont OpenSearch disponibles. Vous êtes responsable de vous assurer que votre domaine répond aux exigences de mise à niveau et que vous avez pris en compte toutes les modifications majeures. | OpenSearch Serverless met automatiquement à niveau vos collections vers les nouvelles OpenSearch versions. Les mises à niveau ne se produisent pas nécessairement dès qu'une nouvelle version est disponible. |
| Mises à jour du logiciel de service | Vous appliquez manuellement les mises à jour du logiciel de service à votre domaine dès qu'elles sont disponibles. | OpenSearch Serverless met automatiquement à jour vos collections pour intégrer les dernières corrections de bogues, fonctionnalités et améliorations de performances. |
| Accès VPC | Vous pouvez [allouer votre domaine au sein d'un VPC](vpc.md). Vous pouvez également créer des [points de terminaison OpenSearch VPC supplémentaires gérés par le service](vpc-interface-endpoints.md) pour accéder au domaine. | Vous créez un ou plusieurs points de [OpenSearch terminaison VPC gérés sans serveur](serverless-vpc.md) pour votre compte. Vous incluez ensuite ces points de terminaison dans les [stratégies réseau](serverless-network.md). |
| Authentification SAML | Vous activez l'authentification SAML par domaine. Pour de plus amples informations, veuillez consulter [Authentification SAML pour les tableaux de bord OpenSearch](saml.md). | Vous configurez un ou plusieurs fournisseurs SAML au niveau du compte, puis vous incluez l'utilisateur et le groupe associés IDs dans les politiques d'accès aux données. Pour de plus amples informations, veuillez consulter [Authentification SAML pour Amazon Serverless OpenSearch](serverless-saml.md). |
| protocole TLS (Transport Layer Security) | OpenSearch Le service prend en charge le protocole TLS 1.2, mais il est recommandé d'utiliser le protocole TLS 1.3. | OpenSearch Serverless prend en charge le protocole TLS 1.2, mais il est recommandé d'utiliser le protocole TLS 1.3. |
# Tutoriel : prise en main d'Amazon OpenSearch Serverless
Ce didacticiel vous explique les étapes de base pour mettre rapidement en place une collection *de recherche* Amazon OpenSearch Serverless. Une collection de recherche vous permet d'alimenter les applications de vos réseaux internes et les applications connectées à Internet, telles que la recherche sur les sites Web de commerce électronique et la recherche de contenu.
Pour savoir comment utiliser une collection de *recherche vectorielle*, voir[Utilisation de collections de recherche vectorielle](serverless-vector-search.md). Pour des informations plus détaillées sur l'utilisation des collections, consultez [Gestion des collections Amazon OpenSearch Serverless](serverless-manage.md) et les autres rubriques de ce guide.
Dans le cadre de ce didacticiel, vous suivrez les étapes suivantes :
1. [Configurer des autorisations](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-getting-started.html#serverless-gsg-permissions)
1. [Créer une collection](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-getting-started.html#serverless-gsg-create)
1. [Charger et rechercher des données](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-getting-started.html#serverless-gsg-index)
1. [Supprimer la collection](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-getting-started.html#serverless-gsg-delete)
**Note**
Nous vous recommandons de n'utiliser que des caractères ASCII pour votre. `IndexName` Si vous n'utilisez pas de caractères ASCII pour votre compte`IndexName`, les CloudWatch métriques entrantes seront converties `IndexName` en un format codé URL pour les caractères non ASCII.
## Étape 1 : configurer des autorisations
Pour suivre ce didacticiel, et pour utiliser OpenSearch Serverless en général, vous devez disposer des autorisations IAM appropriées. Dans le cadre de ce didacticiel, vous allez créer une collection, charger et rechercher des données, puis supprimer la collection.
Votre utilisateur ou votre rôle doit être associé à une [politique basée sur l'identité](security-iam-serverless.md#security-iam-serverless-id-based-policies) avec les autorisations minimales suivantes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"aoss:CreateCollection",
"aoss:ListCollections",
"aoss:BatchGetCollection",
"aoss:DeleteCollection",
"aoss:CreateAccessPolicy",
"aoss:ListAccessPolicies",
"aoss:UpdateAccessPolicy",
"aoss:CreateSecurityPolicy",
"aoss:GetSecurityPolicy",
"aoss:UpdateSecurityPolicy",
"iam:ListUsers",
"iam:ListRoles"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
Pour plus d'informations sur les autorisations IAM OpenSearch sans serveur, consultez. [Identity and Access Management pour Amazon OpenSearch Serverless](security-iam-serverless.md)
## Étape 2 : créer une collection
Une collection est un groupe d' OpenSearch index qui fonctionnent ensemble pour prendre en charge une charge de travail ou un cas d'utilisation spécifique.
**Pour créer une collection OpenSearch sans serveur**
1. Ouvrez la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home ).
1. Choisissez **Collections** dans le panneau de navigation de gauche, puis choisissez **Create collection** (Créer une collection).
1. Nommez la collection **movies** (films).
1. Pour le type de collection, choisissez **Search** (Rechercher). Pour plus d'informations, consultez [Choisir un type de collection](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-overview.html#serverless-usecase).
1. Pour **Sécurité**, choisissez **Création standard**.
1. Sous **Chiffrement**, sélectionnez **Utiliser Clé détenue par AWS**. C'est ce AWS KMS key que OpenSearch Serverless utilisera pour chiffrer vos données.
1. Sous **Network** (Réseau), configurez les paramètres réseau de la collection.
+ Pour le type d'accès, sélectionnez **Public**.
+ Pour le type de ressource, sélectionnez **Activer l'accès aux OpenSearch points de terminaison** et **Activer l'accès aux OpenSearch tableaux de bord**. Comme vous téléchargerez et rechercherez des données à l'aide de OpenSearch tableaux de bord, vous devez activer les deux.
1. Choisissez **Suivant**.
1. Pour **Configure data access** (Configurer l'accès aux données), configurez les paramètres d'accès pour la collection. Les [stratégies d'accès aux données](serverless-data-access.md) permettent aux utilisateurs et aux rôles d'accéder aux données d'une collection. Dans le cadre de ce didacticiel, nous allons fournir à un seul utilisateur les autorisations requises pour indexer et rechercher des données dans la collection *movies*.
Créez une règle unique qui donne accès à la collection de *films*. Nommez la règle **Movies collection access** (Accès à la collection movies).
1. Choisissez **Ajouter des principaux, des** **utilisateurs et des rôles IAM**, puis sélectionnez l'utilisateur ou le rôle que vous utiliserez pour vous connecter aux OpenSearch tableaux de bord et indexer les données. Choisissez **Enregistrer**.
1. Sous **Index permissions** (Autorisations d'index), sélectionnez toutes les autorisations.
1. Choisissez **Suivant**.
1. Pour les paramètres de la stratégie d'accès, choisissez **Create a new data access policy** (Créer une nouvelle stratégie d'accès aux données) et nommez la stratégie **movies** (films).
1. Choisissez **Suivant**.
1. Vérifiez vos paramètres de collection et choisissez **Submit** (Soumettre). Attendez quelques minutes pour que le statut de la collection devienne `Active`.
## Étape 3 : charger et rechercher des données
Vous pouvez télécharger des données vers une collection OpenSearch sans serveur à l'aide de [Postman ou cURL](https://www.postman.com/downloads/). Par souci de concision, ces exemples utilisent les **outils de développement** de la console OpenSearch Dashboards.
**Indexer et rechercher des données dans la collection movies**
1. Choisissez **Collections** dans le panneau de navigation de gauche, puis choisissez la collection **movies** pour afficher sa page des détails.
1. Choisissez l'URL OpenSearch des tableaux de bord pour la collection. L'URL est au format `https://dashboards.{region}.aoss.amazonaws.com/_login/?collectionId={collection-id}`.
1. Dans OpenSearch Dashboards, ouvrez le volet de navigation de gauche et choisissez **Dev Tools**.
1. Pour créer un index unique appelé *movies-index*, envoyez la requête suivante :
```
PUT movies-index
```
![\[OpenSearch Dashboards console showing PUT request for movies-index with JSON response.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-gsg-create.png)
1. Pour indexer un seul document dans *movies-index*, envoyez la requête suivante :
```
PUT movies-index/_doc/1
{
"title": "Shawshank Redemption",
"genre": "Drama",
"year": 1994
}
```
1. Pour rechercher des données dans OpenSearch les tableaux de bord, vous devez configurer au moins un modèle d'index. OpenSearch utilise ces modèles pour identifier les index que vous souhaitez analyser. Ouvrez le panneau de navigation de gauche, choisissez **Stack Management** (Gestion des piles), choisissez **Index Patterns** (Modèles d'index), puis **Create index pattern** (Créer un modèle d'index). Dans le cadre de ce tutoriel, saisissez *movies*.
1. Choisissez **Next step (Étape suivante)**, puis **Create index pattern (Créer un modèle d'index)**. Une fois le modèle créé, vous pouvez consulter les différents champs du document, comme `title` et `genre`.
1. Pour commencer à rechercher vos données, ouvrez à nouveau le panneau de navigation de gauche et choisissez **Discover** (Découvrir), ou utilisez l'[API de recherche](https://opensearch.org/docs/latest/api-reference/search/) dans les outils de développement.
## Gestion des erreurs
Lorsque vous exécutez des opérations d'index et de recherche, vous pouvez obtenir les réponses d'erreur suivantes :
+ `HTTP 507`— Indique qu'une erreur interne du serveur s'est produite. Cette erreur indique généralement que vos unités de OpenSearch calcul (OCUs) sont surchargées par le volume ou la complexité de vos demandes. Bien que le mode OpenSearch Serverless s'adapte automatiquement pour gérer la charge, le déploiement de ressources supplémentaires peut être retardé.
Pour atténuer cette erreur, implémentez une politique de rétentative exponentielle. Cette approche réduit temporairement le taux de demandes afin de gérer efficacement la charge. Pour plus de détails, reportez-vous à la section [Comportement d'une nouvelle](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) tentative dans le *guide de référence AWS SDKs et Tools*.
+ `HTTP 402`— Indique que vous avez atteint la limite de capacité maximale de l'unité de OpenSearch calcul (OCU). Optimisez votre charge de travail pour réduire l'utilisation de l'OCU ou demander une augmentation de quota.
## Étape 4 : supprimer la collection
Étant donné que la collection *movies* est destinée aux tests, veillez à la supprimer lorsque vous aurez fini de l'utiliser.
**Pour supprimer une collection OpenSearch sans serveur**
1. Retournez à la console **Amazon OpenSearch Service**.
1. Choisissez **Collections** dans le panneau de navigation de gauche et sélectionnez la collection **movies**.
1. Choisissez **Delete (Supprimer)** et confirmez la suppression.
## Étapes suivantes
Maintenant que vous savez comment créer une collection et indexer des données, n'hésitez pas à essayer les exercices suivants :
+ Découvrez des options de création de collection plus avancées. Pour de plus amples informations, veuillez consulter [Gestion des collections Amazon OpenSearch Serverless](serverless-manage.md).
+ Découvrez comment configurer des stratégies de sécurité pour gérer la sécurité des collections à grande échelle. Pour de plus amples informations, veuillez consulter [Présentation de la sécurité dans Amazon OpenSearch Serverless](serverless-security.md).
+ Découvrez d'autres moyens d'indexer les données dans des collections. Pour de plus amples informations, veuillez consulter [Ingestion de données dans des collections Amazon OpenSearch Serverless](serverless-clients.md).
# Collections Amazon OpenSearch Serverless
Dans Amazon OpenSearch Serverless, une *collection* est un regroupement logique d'un ou de plusieurs index représentant une charge de travail d'analyse. OpenSearch Serverless gère et ajuste automatiquement la collection, nécessitant un minimum de saisie manuelle.
**Topics**
+ [Gestion des collections Amazon OpenSearch Serverless](serverless-manage.md)
+ [Utilisation de collections de recherche vectorielle](serverless-vector-search.md)
+ [Utilisation des politiques de cycle de vie des données avec Amazon OpenSearch Serverless](serverless-lifecycle.md)
+ [Utilisation du AWS SDKs pour interagir avec Amazon OpenSearch Serverless](serverless-sdk.md)
+ [Utilisation CloudFormation pour créer des collections Amazon OpenSearch Serverless](serverless-cfn.md)
+ [Sauvegarde de collections à l'aide de snapshots](serverless-snapshots.md)
+ [Support du codec Zstandard dans Amazon Serverless OpenSearch](serverless-zstd-compression.md)
+ [Économisez de l'espace de stockage en utilisant une source dérivée](serverless-derived-source.md)
# Gestion des collections Amazon OpenSearch Serverless
Dans Amazon OpenSearch Serverless, une *collection* est un regroupement logique d'un ou de plusieurs index représentant une charge de travail d'analyse. OpenSearch Serverless gère et ajuste automatiquement la collection, nécessitant un minimum de saisie manuelle.
**Topics**
+ [Configuration des autorisations pour les collections](serverless-collection-permissions.md)
+ [Enrichissement sémantique automatique pour Serverless](serverless-semantic-enrichment.md)
+ [Créer des collections](serverless-create.md)
+ [Accès aux OpenSearch tableaux de bord](serverless-dashboards.md)
+ [Afficher les collections](serverless-list.md)
+ [Supprimer des collections](serverless-delete.md)
# Configuration des autorisations pour les collections
OpenSearch Serverless utilise les autorisations Gestion des identités et des accès AWS (IAM) suivantes pour créer et gérer des collections. Vous pouvez spécifier des conditions IAM pour restreindre les utilisateurs à des collections spécifiques.
+ `aoss:CreateCollection` : créer une collection.
+ `aoss:ListCollections` : répertorier les collections du compte actuel.
+ `aoss:BatchGetCollection` : obtenir des informations sur une ou plusieurs collections.
+ `aoss:UpdateCollection` : modifier une collection.
+ `aoss:DeleteCollection` : supprimer une collection.
L'exemple suivant de stratégie d'accès basée sur l'identité fournit les autorisations minimales nécessaires à un utilisateur pour gérer une collection unique nommée `Logs` :
```
[
{
"Sid":"Allows managing logs collections",
"Effect":"Allow",
"Action":[
"aoss:CreateCollection",
"aoss:ListCollections",
"aoss:BatchGetCollection",
"aoss:UpdateCollection",
"aoss:DeleteCollection",
"aoss:CreateAccessPolicy",
"aoss:CreateSecurityPolicy"
],
"Resource":"*",
"Condition":{
"StringEquals":{
"aoss:collection":"Logs"
}
}
}
]
```
`aoss:CreateAccessPolicy` et `aoss:CreateSecurityPolicy` sont incluses, car des stratégies de chiffrement, de réseau et d'accès aux données sont nécessaires au bon fonctionnement d'une collection. Pour de plus amples informations, veuillez consulter [Identity and Access Management pour Amazon OpenSearch Serverless](security-iam-serverless.md).
**Note**
Si vous créez la première collection de votre compte, vous devez également disposer de l'autorisation `iam:CreateServiceLinkedRole`. Pour de plus amples informations, veuillez consulter [Utilisation de rôles liés à un service pour créer OpenSearch des collections sans serveur](serverless-service-linked-roles.md).
# Enrichissement sémantique automatique pour Serverless
## Introduction
La fonctionnalité d'enrichissement sémantique automatique peut aider à améliorer la pertinence de la recherche jusqu'à 20 % par rapport à la recherche lexicale. L'enrichissement sémantique automatique élimine le fardeau indifférencié lié à la gestion de votre propre infrastructure de modèles de ML (machine learning) et à l'intégration au moteur de recherche. La fonctionnalité est disponible pour les trois types de collection sans serveur : Search, Time Series et Vector.
## Qu'est-ce que la recherche sémantique
Les moteurs de recherche traditionnels s'appuient sur la word-to-word correspondance (appelée recherche lexicale) pour trouver les résultats des requêtes. Bien que cela fonctionne bien pour des requêtes spécifiques telles que les numéros de modèles de téléviseurs, cela pose des difficultés pour les recherches plus abstraites. Par exemple, lorsque vous recherchez « chaussures pour la plage », une recherche lexicale fait simplement correspondre les mots « chaussures », « plage », « pour » et « le » dans les articles du catalogue, ce qui peut entraîner l'absence de produits pertinents tels que « sandales imperméables » ou « chaussures de surf » qui ne contiennent pas les termes de recherche exacts.
La recherche sémantique renvoie des résultats de requête qui intègrent non seulement la correspondance des mots clés, mais aussi l'intention et le sens contextuel de la recherche de l'utilisateur. Par exemple, si un utilisateur recherche « comment traiter un mal de tête », un système de recherche sémantique peut renvoyer les résultats suivants :
+ Remèdes contre la migraine
+ Techniques de gestion de la douleur
+ Over-the-counter analgésiques
## Détails du modèle et indice de performance
Bien que cette fonctionnalité gère les complexités techniques en arrière-plan sans révéler le modèle sous-jacent, nous assurons la transparence grâce à une brève description du modèle et à des résultats de référence pour vous aider à prendre des décisions éclairées concernant l'adoption des fonctionnalités dans le cadre de vos charges de travail critiques.
L'enrichissement sémantique automatique utilise un modèle clairsemé pré-entraîné et géré par les services qui fonctionne efficacement sans nécessiter de réglage personnalisé. Le modèle analyse les champs que vous spécifiez et les développe en vecteurs épars basés sur des associations apprises à partir de diverses données d'entraînement. Les termes développés et leurs poids de signification sont stockés dans le format d'index Lucene natif pour une extraction efficace. Nous avons optimisé ce processus en utilisant le [mode document uniquement,](https://docs.opensearch.org/docs/latest/vector-search/ai-search/neural-sparse-with-pipelines/#step-1a-choose-the-search-mode) dans lequel l'encodage s'effectue uniquement pendant l'ingestion des données. Les requêtes de recherche sont simplement tokenisées plutôt que traitées par le biais du modèle fragmenté, ce qui rend la solution à la fois rentable et performante.
Notre validation des performances lors du développement des fonctionnalités a utilisé le jeu de données de récupération de passages [MS MARCO](https://huggingface.co/datasets/BeIR/msmarco), contenant des passages d'une moyenne de 334 caractères. Pour le score de pertinence, nous avons mesuré le gain cumulé réduit normalisé (NDCG) moyen pour les 10 premiers résultats de recherche (ndcg @10) sur le benchmark [BEIR](https://github.com/beir-cellar/beir) pour le contenu anglais et le ndcg @10 moyen sur MIRACL pour le contenu multilingue. [Nous avons évalué la latence grâce à des mesures au 90e percentile (p90) côté client et à des valeurs prises par p90 dans la réponse à la recherche.](https://github.com/beir-cellar/beir) Ces points de référence fournissent des indicateurs de performance de base pour la pertinence des recherches et les temps de réponse. Voici les principaux chiffres de référence :
+ Langue anglaise - Amélioration de la pertinence de 20 % par rapport à la recherche lexicale. Il a également réduit la latence de recherche P90 de 7,7 % par rapport à la recherche lexicale (BM25 26 ms et enrichissement sémantique automatique de 24 ms).
+ Multilingue : amélioration de la pertinence de 105 % par rapport à la recherche lexicale, tandis que la latence de recherche P90 a augmenté de 38,4 % par rapport à la recherche lexicale (BM25 26 ms et enrichissement sémantique automatique 36 ms).
Compte tenu de la nature unique de chaque charge de travail, nous vous encourageons à évaluer cette fonctionnalité dans votre environnement de développement à l'aide de vos propres critères d'analyse comparative avant de prendre des décisions de mise en œuvre.
## Langues prises en charge
La fonctionnalité prend en charge l'anglais. En outre, le modèle prend également en charge l'arabe, le bengali, le chinois, le finnois, le français, l'hindi, l'indonésien, le japonais, le coréen, le persan, le russe, l'espagnol, le swahili et le télougou.
## Configurer un index d'enrichissement sémantique automatique pour les collections sans serveur
La configuration d'un index avec l'enrichissement sémantique automatique activé pour vos champs de texte est simple, et vous pouvez le gérer via la console et les CloudFormation modèles lors de la création d'un nouvel index. APIs Pour l'activer pour un index existant, vous devez recréer l'index en activant l'enrichissement sémantique automatique pour les champs de texte.
Expérience de console - La AWS console vous permet de créer facilement un index avec des champs d'enrichissement sémantique automatiques. Une fois que vous avez sélectionné une collection, vous trouverez le bouton de création d'index en haut de la console. Une fois que vous avez cliqué sur le bouton de création d'index, vous trouverez des options permettant de définir des champs d'enrichissement sémantique automatique. Dans un index, vous pouvez combiner l'enrichissement sémantique automatique pour l'anglais et le multilingue, ainsi que des champs lexicaux.
![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/ase-console-exp-serverless.png)
Expérience de l'API - Pour créer un index d'enrichissement sémantique automatique à l'aide de l'interface de ligne de AWS commande (AWS CLI), utilisez la commande create-index :
```
aws opensearchserverless create-index \
--id [collection_id] \
--index-name [index_name] \
--index-schema [index_body] \
```
**Dans l'exemple de schéma d'index suivant, le champ *title\$1semantic* a un type de champ défini sur *texte* et le paramètre semantic\$1enrichment défini sur status ENABLED.** *La définition du paramètre *semantic\$1enrichment active l'enrichissement* sémantique automatique du champ title\$1semantic.* *Vous pouvez utiliser le champ *language\$1options* pour spécifier l'*anglais* ou le multilingue.*
```
aws opensearchserverless create-index \
--id XXXXXXXXX \
--index-name 'product-catalog' \
--index-schema '{
"mappings": {
"properties": {
"product_id": {
"type": "keyword"
},
"title_semantic": {
"type": "text",
"semantic_enrichment": {
"status": "ENABLED",
"language_options": "english"
}
},
"title_non_semantic": {
"type": "text"
}
}
}
}'
```
Pour décrire l'index créé, utilisez la commande suivante :
```
aws opensearchserverless get-index \
--id [collection_id] \
--index-name [index_name] \
```
Vous pouvez également utiliser des CloudFormation modèles (Type :AWS::OpenSearchServerless::CollectionIndex) pour créer une recherche sémantique pendant le provisionnement de la collection ainsi qu'après la création de la collection.
## Ingestion et recherche de données
Une fois que vous avez créé un index avec l'enrichissement sémantique automatique activé, la fonctionnalité fonctionne automatiquement pendant le processus d'ingestion des données, aucune configuration supplémentaire n'est requise.
Ingestion des données : lorsque vous ajoutez des documents à votre index, le système :
+ Analyse les champs de texte que vous avez désignés pour l'enrichissement sémantique
+ Génère des codages sémantiques à l'aide du modèle clairsemé géré par le OpenSearch service
+ Stocke ces représentations enrichies aux côtés de vos données d'origine
Ce processus utilise OpenSearch les connecteurs ML et les pipelines d'ingestion intégrés, qui sont créés et gérés automatiquement en arrière-plan.
Recherche : les données d'enrichissement sémantique sont déjà indexées, de sorte que les requêtes s'exécutent efficacement sans invoquer à nouveau le modèle ML. Cela signifie que vous bénéficiez d'une pertinence de recherche améliorée sans surcoût de latence de recherche supplémentaire.
## Configuration des autorisations pour l'enrichissement sémantique automatique
Avant de créer un index d'enrichissement sémantique automatique, vous devez configurer les autorisations requises. Cette section explique les autorisations nécessaires et explique comment les configurer.
### Autorisations liées à la politique IAM
Utilisez la politique Gestion des identités et des accès AWS (IAM) suivante pour accorder les autorisations nécessaires à l'utilisation de l'enrichissement sémantique automatique :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AutomaticSemanticEnrichmentPermissions",
"Effect": "Allow",
"Action": [
"aoss:CreateIndex",
"aoss:GetIndex",
"aoss:UpdateIndex",
"aoss:DeleteIndex",
"aoss:APIAccessAll"
],
"Resource": "*"
}
]
}
```
------
**Autorisations de clés**
+ Les `aoss:*Index` autorisations permettent la gestion des index
+ L'`aoss:APIAccessAll`autorisation autorise les opérations OpenSearch d'API
+ Pour restreindre les autorisations à une collection spécifique, remplacez-la `"Resource": "*"` par l'ARN de la collection
### Configuration des autorisations d'accès aux données
Pour configurer un index pour un enrichissement sémantique automatique, vous devez disposer de politiques d'accès aux données appropriées autorisant l'accès aux ressources de collecte d'index, de pipeline et de modèles. Pour plus d'informations sur les politiques d'accès aux données, consultez[Contrôle d'accès aux données pour Amazon OpenSearch Serverless](serverless-data-access.md). Pour la procédure de configuration d'une politique d'accès aux données, consultez[Création de stratégies d'accès aux données (console)](serverless-data-access.md#serverless-data-access-console).
#### Autorisations d'accès aux données
```
[
{
"Description": "Create index permission",
"Rules": [
{
"ResourceType": "index",
"Resource": ["index/collection_name/*"],
"Permission": [
"aoss:CreateIndex",
"aoss:DescribeIndex",
"aoss:UpdateIndex",
"aoss:DeleteIndex"
]
}
],
"Principal": [
"arn:aws:iam::account_id:role/role_name"
]
},
{
"Description": "Create pipeline permission",
"Rules": [
{
"ResourceType": "collection",
"Resource": ["collection/collection_name"],
"Permission": [
"aoss:CreateCollectionItems",
"aoss:DescribeCollectionItems"
]
}
],
"Principal": [
"arn:aws:iam::account_id:role/role_name"
]
},
{
"Description": "Create model permission",
"Rules": [
{
"ResourceType": "model",
"Resource": ["model/collection_name/*"],
"Permission": ["aoss:CreateMLResource"]
}
],
"Principal": [
"arn:aws:iam::account_id:role/role_name"
]
},
]
```
#### Autorisations d'accès au réseau
Pour autoriser le service APIs à accéder aux collections privées, vous devez configurer des politiques réseau qui autorisent l'accès requis entre l'API du service et la collection. Pour plus d'informations sur les politiques réseau, consultez la section [Accès réseau pour Amazon OpenSearch Serverless](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-network.html).
```
[
{
"Description":"Enable automatic semantic enrichment in a private collection",
"Rules":[
{
"ResourceType":"collection",
"Resource":[
"collection/collection_name"
]
}
],
"AllowFromPublic":false,
"SourceServices":[
"aoss.amazonaws.com"
],
}
]
```
**Pour configurer les autorisations d'accès réseau pour une collection privée**
1. Connectez-vous à la console de OpenSearch service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home).
1. Dans le volet de navigation de gauche, sélectionnez *Stratégies réseau*. Ensuite, effectuez l’une des actions suivantes :
+ Choisissez un nom de politique existant, puis cliquez sur *Modifier*
+ Choisissez *Créer une politique réseau* et configurez les détails de la politique
1. Dans la zone *Type d'accès*, choisissez *Privé (recommandé)*, puis sélectionnez *Accès privé au AWS service*.
1. Dans le champ de recherche, choisissez *Service*, puis *aoss.amazonaws.com*.
1. Dans la zone *Type de ressource*, cochez la case *Activer l'accès au OpenSearch point de terminaison*.
1. Pour *Rechercher une ou plusieurs collections, ou saisir des termes de préfixes spécifiques*, dans le champ de recherche, sélectionnez *Nom de la collection*. Entrez ou sélectionnez ensuite le nom des collections à associer à la politique réseau.
1. Choisissez *Créer* pour une nouvelle politique réseau ou *Mettre à jour* pour une politique réseau existante.
## Réécritures de requêtes
L'enrichissement sémantique automatique convertit automatiquement vos requêtes « correspondantes » existantes en requêtes de recherche sémantique sans qu'il soit nécessaire de les modifier. Si une requête correspondante fait partie d'une requête composée, le système parcourt votre structure de requête, trouve les requêtes correspondantes et les remplace par des requêtes neuronales clairsemées. Actuellement, la fonctionnalité prend uniquement en charge le remplacement des requêtes « match », qu'il s'agisse d'une requête autonome ou d'une partie d'une requête composée. « multi\$1match » n'est pas pris en charge. En outre, cette fonctionnalité prend en charge toutes les requêtes composées pour remplacer leurs requêtes de correspondance imbriquées. Les requêtes composées incluent : bool, boosting, constant\$1score, dis\$1max, function\$1score et hybrid.
## Limites de l'enrichissement sémantique automatique
La recherche sémantique automatique est particulièrement efficace lorsqu'elle est appliquée à des champs small-to-medium dimensionnés contenant du contenu en langage naturel, tels que des titres de films, des descriptions de produits, des critiques et des résumés. Bien que la recherche sémantique améliore la pertinence dans la plupart des cas d'utilisation, elle peut ne pas être optimale pour certains scénarios. Tenez compte des limites suivantes lorsque vous décidez d'implémenter l'enrichissement sémantique automatique pour votre cas d'utilisation spécifique.
+ Documents très longs — Le modèle clairsemé actuel ne traite que les 8 192 premiers jetons de chaque document en anglais. Pour les documents multilingues, il s'agit de 512 jetons. Pour les articles longs, pensez à implémenter le découpage des documents afin de garantir un traitement complet du contenu.
+ Charges de travail d'analyse des journaux : l'enrichissement sémantique augmente considérablement la taille de l'index, ce qui peut être inutile pour l'analyse des journaux où une correspondance exacte est généralement suffisante. Le contexte sémantique supplémentaire améliore rarement suffisamment l'efficacité de la recherche dans les journaux pour justifier les exigences de stockage accrues.
+ L'enrichissement sémantique automatique n'est pas compatible avec la fonctionnalité Source dérivée.
+ Limitation — Les demandes d'inférence d'indexation sont actuellement plafonnées à 100 TPS pour les applications sans serveur. OpenSearch Il s'agit d'une limite souple ; contactez le AWS Support pour obtenir des limites plus élevées.
## Tarification
OpenSearch L'enrichissement sémantique automatique des factures sans serveur est basé sur les unités de OpenSearch calcul (OCUs) consommées lors de la génération de vecteurs épars au moment de l'indexation. Vous n'êtes facturé que pour l'utilisation réelle lors de l'indexation. Vous pouvez surveiller cette consommation à l'aide de l' SemanticSearchOCU CloudWatch métrique Amazon. Pour obtenir des informations spécifiques sur les limites des jetons du modèle, le débit volumique par OCU et un exemple de calcul d'échantillon, consultez la section Tarification des [ OpenSearch services](https://aws.amazon.com/opensearch-service/pricing/).
# Créer des collections
Vous pouvez utiliser la console ou le AWS CLI pour créer une collection sans serveur. Ces étapes expliquent comment créer une *recherche* ou une collection de *séries chronologiques*. Pour créer une collection *de recherche vectorielle*, voir[Utilisation de collections de recherche vectorielle](serverless-vector-search.md).
**Topics**
+ [Créer une collection (console)](serverless-create-console.md)
+ [Créer une collection (CLI)](serverless-create-cli.md)
# Créer une collection (console)
Suivez les procédures décrites dans cette section pour créer une collection à l'aide du AWS Management Console. Ces étapes expliquent comment créer une *recherche* ou une collection de *séries chronologiques*. Pour créer une collection *de recherche vectorielle*, voir[Utilisation de collections de recherche vectorielle](serverless-vector-search.md).
**Topics**
+ [Configuration des paramètres de collecte](#serverless-create-console-step-2)
+ [Configuration de champs de recherche supplémentaires](#serverless-create-console-step-3)
## Configuration des paramètres de collecte
Utilisez la procédure suivante pour configurer les informations relatives à votre collection.
**Pour configurer les paramètres de collecte à l'aide de la console**
1. Accédez à la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/home/](https://console.aws.amazon.com/aos/home/).
1. Développez **Serverless** (Sans serveur) dans le panneau de navigation de gauche et choisissez **Collections**.
1. Choisissez **Create collection** (Créer une collection).
1. Saisissez un nom et une description pour la collection. Le nom doit répondre aux critères suivants :
+ est propre à votre compte et Région AWS
+ Contient uniquement les lettres minuscules a-z, les chiffres 0-9 et le trait d'union (-)
+ Contient entre 3 et 32 caractères
1. Choisissez un type de collection :
+ **Séries temporelles** : segment d'analyse des journaux qui se concentre sur des gros volumes de données semi-structurées et générées par des machines. Au moins 24 heures de données sont stockées sur des index chauds, le reste étant stocké à chaud.
+ **Recherche** : recherche en texte intégral qui alimente les applications de vos réseaux internes et les applications disponibles sur Internet. Toutes les données de recherche sont stockées dans le stockage à chaud afin de garantir des temps de réponse rapides aux requêtes.
**Note**
Choisissez cette option si vous activez la recherche sémantique automatique, comme décrit dans[Configuration des paramètres de collecte](#serverless-create-console-step-2).
+ **Recherche vectorielle : recherche** sémantique sur les intégrations vectorielles qui simplifie la gestion des données vectorielles. Favorise les expériences de recherche augmentées par le machine learning (ML) et les applications d'IA génératives telles que les chatbots, les assistants personnels et la détection des fraudes.
Pour de plus amples informations, veuillez consulter [Choix d'un type de collection](serverless-overview.md#serverless-usecase).
1. Pour **Type de déploiement**, choisissez le paramètre de redondance pour votre collection. Par défaut, chaque collection est redondante, ce qui signifie que les unités de OpenSearch calcul d'indexation et de recherche (OCUs) disposent chacune de leurs propres répliques de secours dans une zone de disponibilité différente. À des fins de développement et de test, vous pouvez choisir de désactiver la redondance, ce qui réduit à deux le nombre de OCUs membres de votre collection. Pour de plus amples informations, veuillez consulter [Comment ça marche](serverless-overview.md#serverless-process).
1. Pour **Sécurité**, choisissez **Création standard**.
1. Pour **le chiffrement**, choisissez une AWS KMS clé pour chiffrer vos données. OpenSearch Serverless vous avertit si le nom de collection que vous avez saisi correspond à un modèle défini dans une politique de chiffrement. Vous pouvez choisir de conserver cette correspondance ou de la remplacer par des paramètres de chiffrement uniques. Pour de plus amples informations, veuillez consulter [Chiffrement dans Amazon OpenSearch Serverless](serverless-encryption.md).
1. Pour les **paramètres d'accès réseau**, configurez l'accès réseau pour la collection.
+ Pour le **type d'accès**, sélectionnez public ou privé.
Si vous choisissez privé, spécifiez les points de terminaison VPC autorisés à Services AWS accéder à la collection.
+ **Points de terminaison VPC pour l'accès** : spécifiez un ou plusieurs points de terminaison VPC pour autoriser l'accès. Pour créer un point de terminaison d'un VPC, veuillez consulter la rubrique [Accès au plan de données via AWS PrivateLink](serverless-vpc.md).
+ **Service AWS accès privé** : sélectionnez un ou plusieurs services pris en charge auxquels vous souhaitez autoriser l'accès.
+ Pour le **type de ressource**, indiquez si les utilisateurs peuvent accéder à la collection via son *OpenSearch*point de terminaison (pour effectuer des appels d'API via cURL, Postman, etc.), via le point de terminaison *OpenSearch Dashboards* (pour travailler avec des visualisations et effectuer des appels d'API via la console), ou les deux.
**Note**
Service AWS l'accès privé s'applique uniquement au OpenSearch point de terminaison, pas au point de terminaison OpenSearch des tableaux de bord.
OpenSearch Serverless vous avertit si le nom de collection que vous avez saisi correspond à un modèle défini dans une politique réseau. Vous pouvez choisir de conserver cette correspondance ou de la remplacer par des paramètres réseau personnalisés. Pour de plus amples informations, veuillez consulter [Accès au réseau pour Amazon OpenSearch Serverless](serverless-network.md).
1. (Facultatif) Ajoutez une ou plusieurs balises à la collection. Pour de plus amples informations, veuillez consulter [Marquage des collections Amazon OpenSearch Serverless](tag-collection.md).
1. Choisissez **Suivant**.
## Configuration de champs de recherche supplémentaires
Les options affichées à la page 2 du flux de travail de création de collection dépendent du type de collection que vous créez. Cette section explique comment configurer des champs de recherche supplémentaires pour chaque type de collection. Cette section décrit également comment configurer l'enrichissement sémantique automatique. Ignorez les sections qui ne s'appliquent pas à votre type de collection.
**Topics**
+ [Configuration de l'enrichissement sémantique automatique](#serverless-create-console-step-3-semantic-enrichment-fields)
+ [Configuration des champs de recherche de séries chronologiques](#serverless-create-console-step-3-time-series-fields)
+ [Configuration des champs de recherche lexicaux](#serverless-create-console-step-3-lexical-fields)
+ [Configuration des champs de recherche vectorielle](#serverless-create-console-step-3-vector-search-fields)
### Configuration de l'enrichissement sémantique automatique
Lorsque vous créez ou modifiez une collection, vous pouvez configurer l'enrichissement sémantique automatique, ce qui simplifie la mise en œuvre et les fonctionnalités de recherche sémantique dans Amazon OpenSearch Service. La recherche sémantique renvoie des résultats de requête qui intègrent non seulement la correspondance des mots clés, mais aussi l'intention et le sens contextuel de la recherche de l'utilisateur. Pour de plus amples informations, veuillez consulter [Enrichissement sémantique automatique pour Serverless](serverless-semantic-enrichment.md).
**Pour configurer l'enrichissement sémantique automatique**
1. Dans la section **Détails de l'index**, pour **Nom de l'index**, spécifiez un nom.
1. Dans la section **Champs d'enrichissement sémantique automatique**, choisissez **Ajouter un champ de recherche sémantique**.
1. Dans le **champ Nom du champ d'entrée pour l'enrichissement sémantique**, entrez le nom du champ que vous souhaitez enrichir.
1. Le **type de données** est **Texte**. Vous ne pouvez pas modifier cette valeur.
1. Pour **Langue**, choisissez **Anglais** ou **Multilingue**.
1. Choisissez **Ajouter un champ**.
1. Une fois que vous avez fini de configurer les champs facultatifs pour votre collection, choisissez **Next**. Passez en revue vos modifications et choisissez **Soumettre** pour créer la collection.
### Configuration des champs de recherche de séries chronologiques
Les options de la section **Champs de recherche des séries chronologiques** concernent les données des séries chronologiques et les flux de données. Pour plus d'informations sur ces sujets, consultez[Gestion des séries chronologiques dans Amazon OpenSearch Service à l'aide de flux de données](data-streams.md).
**Pour configurer les champs de recherche de séries chronologiques**
1. Dans la section **Champs de recherche de séries chronologiques**, choisissez **Ajouter un champ de série chronologique**.
1. Pour **Nom du champ**, entrez un nom.
1. Pour **Type de données**, choisissez-en un dans la liste.
1. Choisissez **Ajouter un champ**
1. Une fois que vous avez fini de configurer les champs facultatifs pour votre collection, choisissez **Next**. Passez en revue vos modifications et choisissez **Soumettre** pour créer la collection.
### Configuration des champs de recherche lexicaux
La recherche lexicale cherche à obtenir une correspondance exacte entre une requête de recherche et des termes ou mots clés indexés.
**Pour configurer les champs de recherche lexicaux**
1. Dans la section **Champs de recherche lexicaux**, choisissez **Ajouter un champ de recherche**.
1. Pour **Nom du champ**, entrez un nom.
1. Pour **Type de données**, choisissez-en un dans la liste.
1. Choisissez **Ajouter un champ**
1. Une fois que vous avez fini de configurer les champs facultatifs pour votre collection, choisissez **Next**. Passez en revue vos modifications et choisissez **Soumettre** pour créer la collection.
### Configuration des champs de recherche vectorielle
**Pour configurer les champs de recherche vectorielle**
1. Dans la section **Champs vectoriels**, choisissez **Ajouter un champ vectoriel**.
1. Pour **Nom du champ**, entrez un nom.
1. Pour **Engine**, choisissez un type dans la liste.
1. Entrez le nombre de dimensions.
1. Pour **Distance Metric**, choisissez un type dans la liste.
1. Une fois que vous avez fini de configurer les champs facultatifs pour votre collection, choisissez **Next**.
1. Passez en revue vos modifications et choisissez **Soumettre** pour créer la collection.
# Créer une collection (CLI)
Utilisez les procédures décrites dans cette section pour créer une collection OpenSearch sans serveur à l'aide du AWS CLI.
**Topics**
+ [Avant de commencer](#serverless-create-cli-before-you-begin)
+ [Création d’une collection](#serverless-create-cli-creating)
+ [Création d'une collection avec un index d'enrichissement sémantique automatique](#serverless-create-cli-automatic-semantic-enrichment)
## Avant de commencer
Avant de créer une collection à l'aide de AWS CLI, suivez la procédure suivante pour créer les politiques requises pour la collection.
**Note**
Dans chacune des procédures suivantes, lorsque vous spécifiez le nom d'une collection, celui-ci doit répondre aux critères suivants :
est propre à votre compte et Région AWS
Contient uniquement les lettres minuscules a-z, les chiffres 0-9 et le trait d'union (-)
Contient entre 3 et 32 caractères
**Pour créer les politiques requises pour une collection**
1. Ouvrez le AWS CLI et exécutez la commande suivante pour créer une [politique de chiffrement](serverless-encryption.md) avec un modèle de ressource correspondant au nom prévu de la collection.
```
&aws opensearchserverless create-security-policy \
--name policy name \
--type encryption --policy "{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection\/collection name\"]}],\"AWSOwnedKey\":true}"
```
Par exemple, si vous envisagez de nommer votre collection *logs-application*, vous pouvez créer une stratégie de chiffrement comme suit :
```
&aws opensearchserverless create-security-policy \
--name logs-policy \
--type encryption --policy "{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection\/logs-application\"]}],\"AWSOwnedKey\":true}"
```
Si vous envisagez d'utiliser la stratégie pour des collections supplémentaires, vous pouvez élargir la règle, par exemple `collection/logs*` ou `collection/*`.
1. Exécutez la commande suivante pour configurer les paramètres réseau de la collection à l'aide d'une [politique réseau](serverless-network.md). Vous pouvez créer des stratégies réseau après avoir créé une collection, mais nous vous recommandons de le faire au préalable.
```
&aws opensearchserverless create-security-policy \
--name policy name \
--type network --policy "[{\"Description\":\"description\",\"Rules\":[{\"ResourceType\":\"dashboard\",\"Resource\":[\"collection\/collection name\"]},{\"ResourceType\":\"collection\",\"Resource\":[\"collection\/collection name\"]}],\"AllowFromPublic\":true}]"
```
À l'aide de l'exemple *logs-application* précédent, vous pouvez créer la stratégie réseau suivante :
```
&aws opensearchserverless create-security-policy \
--name logs-policy \
--type network --policy "[{\"Description\":\"Public access for logs collection\",\"Rules\":[{\"ResourceType\":\"dashboard\",\"Resource\":[\"collection\/logs-application\"]},{\"ResourceType\":\"collection\",\"Resource\":[\"collection\/logs-application\"]}],\"AllowFromPublic\":true}]"
```
## Création d’une collection
La procédure suivante utilise l'action [CreateCollection](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateCollection.html)API pour créer une collection de type `SEARCH` ou`TIMESERIES`. Si vous ne spécifiez pas de type de collection dans la demande, il est défini par défaut à `TIMESERIES`. Pour plus d'informations sur ces types, consultez[Choix d'un type de collection](serverless-overview.md#serverless-usecase). Pour créer une collection *de recherche vectorielle*, voir[Utilisation de collections de recherche vectorielle](serverless-vector-search.md).
Si votre collection est chiffrée avec un Clé détenue par AWS, `kmsKeyArn` c'est `auto` plutôt qu'un ARN.
**Important**
Une fois la collection créée, vous ne pourrez y accéder que si elle correspond à une stratégie d'accès aux données. Pour de plus amples informations, veuillez consulter [Contrôle d'accès aux données pour Amazon OpenSearch Serverless](serverless-data-access.md).
**Pour créer une collection**
1. Vérifiez que vous avez créé les politiques requises décrites dans[Avant de commencer](#serverless-create-cli-before-you-begin).
1. Exécutez la commande suivante. Pour `type` spécifier l'un `SEARCH` ou l'autre`TIMESERIES`.
```
&aws opensearchserverless create-collection --name "collection name" --type collection type --description "description"
```
## Création d'une collection avec un index d'enrichissement sémantique automatique
Utilisez la procédure suivante pour créer une nouvelle collection OpenSearch Serverless avec un index configuré pour un enrichissement [sémantique automatique](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-semantic-enrichment.html). La procédure utilise l'action d'[CreateIndex](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateIndex.html)API OpenSearch Serverless.
**Pour créer une nouvelle collection avec un index configuré pour un enrichissement sémantique automatique**
Exécutez la commande suivante pour créer la collection et un index.
```
&aws opensearchserverless create-index \
--region Region ID \
--id collection name --index-name index name \
--index-schema \
'mapping in json'
```
Voici un exemple :
```
&aws opensearchserverless create-index \
--region us-east-1 \
--id conversation_history --index-name conversation_history_index \
--index-schema \
'{
"mappings": {
"properties": {
"age": {
"type": "integer"
},
"name": {
"type": "keyword"
},
"user_description": {
"type": "text"
},
"conversation_history": {
"type": "text",
"semantic_enrichment": {
"status": "ENABLED",
// Specifies the sparse tokenizer for processing multi-lingual text
"language_option": "MULTI-LINGUAL",
// If embedding_field is provided, the semantic embedding field will be set to the given name rather than original field name + "_embedding"
"embedding_field": "conversation_history_user_defined"
}
},
"book_title": {
"type": "text",
"semantic_enrichment": {
// No embedding_field is provided, so the semantic embedding field is set to "book_title_embedding"
"status": "ENABLED",
"language_option": "ENGLISH"
}
},
"abstract": {
"type": "text",
"semantic_enrichment": {
// If no language_option is provided, it will be set to English.
// No embedding_field is provided, so the semantic embedding field is set to "abstract_embedding"
"status": "ENABLED"
}
}
}
}
}'
```
# Accès aux OpenSearch tableaux de bord
Après avoir créé une collection avec le AWS Management Console, vous pouvez accéder à l'URL des OpenSearch tableaux de bord de la collection. Vous pouvez trouver l'URL des tableaux de bord en choisissant **Collections** dans le volet de navigation de gauche et en sélectionnant la collection pour ouvrir sa page de détails. L'URL est au format `https://dashboards.us-east-1.aoss.amazonaws.com/_login/?collectionId=07tjusf2h91cunochc`. Une fois que vous avez accédé à l'URL, vous vous connectez automatiquement aux tableaux de bord.
Si l'URL des OpenSearch tableaux de bord est déjà disponible mais que vous n'y êtes pas AWS Management Console, l'appel de l'URL des tableaux de bord depuis le navigateur sera redirigé vers la console. Une fois que vous aurez saisi vos AWS informations d'identification, vous vous connecterez automatiquement aux tableaux de bord. Pour plus d'informations sur l'accès aux collections pour le protocole SAML, consultez la section [Accès aux OpenSearch tableaux de bord avec](serverless-saml.md#serverless-saml-dashboards) le protocole SAML.
Le délai d'expiration OpenSearch de la console Dashboards est d'une heure et n'est pas configurable.
**Note**
Le 10 mai 2023, OpenSearch a introduit un point de terminaison mondial commun pour les OpenSearch tableaux de bord. Vous pouvez désormais accéder aux OpenSearch tableaux de bord dans le navigateur à l'aide d'une URL au format `https://dashboards.us-east-1.aoss.amazonaws.com/_login/?collectionId=07tjusf2h91cunochc` approprié. Pour garantir la rétrocompatibilité, nous continuerons à prendre en charge les points de terminaison des OpenSearch tableaux de bord spécifiques à la collection existante avec ce format. `https://07tjusf2h91cunochc.us-east-1.aoss.amazonaws.com/_dashboards`
# Afficher les collections
Vous pouvez consulter les collections existantes dans l' Compte AWS onglet **Collections** de la console Amazon OpenSearch Service.
Pour répertorier les collections avec leurs IDs informations, envoyez une [ListCollections](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_ListCollections.html)demande.
```
&aws opensearchserverless list-collections
```
**Exemple de réponse**
```
{
"collectionSummaries":[
{
"arn":"arn:aws:aoss:us-east-1:123456789012:collection/07tjusf2h91cunochc",
"id":"07tjusf2h91cunochc",
"name":"my-collection",
"status":"CREATING"
}
]
}
```
Pour limiter les résultats de recherche, utilisez des filtres de collection. Cette requête filtre la réponse aux collections à l'état `ACTIVE` :
```
&aws opensearchserverless list-collections --collection-filters '{ "status": "ACTIVE" }'
```
Pour obtenir des informations plus détaillées sur une ou plusieurs collections, y compris le OpenSearch point de terminaison et le point de terminaison OpenSearch Dashboards, envoyez une [BatchGetCollection](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_BatchGetCollection.html)demande :
```
&aws opensearchserverless batch-get-collection --ids "07tjusf2h91cunochc" "1iu5usc4rame"
```
**Note**
Vous pouvez inclure `--names` ou `--ids` dans la requête, mais pas les deux.
**Exemple de réponse**
```
{
"collectionDetails":[
{
"id": "07tjusf2h91cunochc",
"name": "my-collection",
"status": "ACTIVE",
"type": "SEARCH",
"description": "",
"arn": "arn:aws:aoss:us-east-1:123456789012:collection/07tjusf2h91cunochc",
"kmsKeyArn": "arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"createdDate": 1667446262828,
"lastModifiedDate": 1667446300769,
"collectionEndpoint": "https://07tjusf2h91cunochc.us-east-1.aoss.amazonaws.com",
"dashboardEndpoint": "https://07tjusf2h91cunochc.us-east-1.aoss.amazonaws.com/_dashboards"
},
{
"id": "178ukvtg3i82dvopdid",
"name": "another-collection",
"status": "ACTIVE",
"type": "TIMESERIES",
"description": "",
"arn": "arn:aws:aoss:us-east-1:123456789012:collection/178ukvtg3i82dvopdid",
"kmsKeyArn": "arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"createdDate": 1667446262828,
"lastModifiedDate": 1667446300769,
"collectionEndpoint": "https://178ukvtg3i82dvopdid.us-east-1.aoss.amazonaws.com",
"dashboardEndpoint": "https://178ukvtg3i82dvopdid.us-east-1.aoss.amazonaws.com/_dashboards"
}
],
"collectionErrorDetails":[]
}
```
# Supprimer des collections
La suppression d'une collection entraîne la suppression de toutes ses données et de tous ses index. Vous ne pouvez pas récupérer les collections après les avoir supprimées.
**Supprimer une collection à l'aide de la console**
1. Dans le panneau **Collections** de la console Amazon OpenSearch Service, sélectionnez la collection que vous souhaitez supprimer.
1. Choisissez **Delete (Supprimer)** et confirmez la suppression.
Pour supprimer une collection à l'aide du AWS CLI, envoyez une [DeleteCollection](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_DeleteCollection.html)demande :
```
&aws opensearchserverless delete-collection --id 07tjusf2h91cunochc
```
**Exemple de réponse**
```
{
"deleteCollectionDetail":{
"id":"07tjusf2h91cunochc",
"name":"my-collection",
"status":"DELETING"
}
}
```
# Utilisation de collections de recherche vectorielle
Le type *de collection de recherche vectorielle* dans OpenSearch Serverless fournit une fonctionnalité de recherche de similarité évolutive et performante. Il vous permet de créer facilement des expériences modernes de recherche augmentée par apprentissage automatique (ML) et des applications d'intelligence artificielle générative (IA) sans avoir à gérer l'infrastructure de base de données vectorielle sous-jacente.
Les exemples d'utilisation des collections de recherche vectorielle incluent les recherches d'images, les recherches de documents, la récupération de musique, les recommandations de produits, les recherches de vidéos, les recherches géolocalisées, la détection des fraudes et la détection des anomalies.
Comme le moteur vectoriel de OpenSearch Serverless est alimenté par la [fonction de recherche du voisin le plus proche (k-NN)](https://opensearch.org/docs/latest/search-plugins/knn/index/) dans OpenSearch, vous bénéficiez des mêmes fonctionnalités avec la simplicité d'un environnement sans serveur. Le moteur prend en charge l'[API du plugin K-nn](https://opensearch.org/docs/latest/search-plugins/knn/api/). Grâce à ces opérations, vous pouvez tirer parti de la recherche en texte intégral, du filtrage avancé, des agrégations, des requêtes géospatiales, des requêtes imbriquées pour une extraction plus rapide des données et des résultats de recherche améliorés.
Le moteur vectoriel fournit des mesures de distance telles que la distance euclidienne, la similitude des cosinus et la similitude des produits par points, et peut prendre en charge 16 000 dimensions. Vous pouvez stocker des champs contenant différents types de données pour les métadonnées, tels que des nombres, des booléens, des dates, des mots clés et des points géographiques. Vous pouvez également stocker des champs avec du texte pour obtenir des informations descriptives afin d'ajouter du contexte aux vecteurs stockés. La colocation des types de données réduit la complexité, augmente la maintenabilité et évite la duplication des données, les problèmes de compatibilité des versions et les problèmes de licence.
**Note**
Veuillez noter les informations suivantes :
Amazon OpenSearch Serverless prend en charge la quantification scalaire 16 bits Faiss, qui peut être utilisée pour effectuer des conversions entre des vecteurs flottants 32 bits et des vecteurs 16 bits. Pour en savoir plus, consultez la section [Quantification scalaire 16 bits Faiss](https://opensearch.org/docs/latest/search-plugins/knn/knn-vector-quantization/#faiss-16-bit-scalar-quantization). Vous pouvez également utiliser des vecteurs binaires pour réduire les coûts de mémoire. Pour plus d'informations, consultez la section [Vecteurs binaires](https://opensearch.org/docs/latest/field-types/supported-field-types/knn-vector#binary-vectors).
Amazon OpenSearch Serverless prend en charge la recherche vectorielle sur disque. La recherche vectorielle sur disque réduit considérablement les coûts opérationnels liés aux charges de travail vectorielles dans les environnements à faible mémoire. Pour plus d'informations, consultez la section [Recherche vectorielle sur disque](https://docs.opensearch.org/2.19/vector-search/optimizing-storage/disk-based-vector-search/).
## Commencer à utiliser les collections de recherche vectorielle
Dans ce didacticiel, vous allez effectuer les étapes suivantes pour stocker, rechercher et récupérer des intégrations vectorielles en temps réel :
1. [Configurer des autorisations](#serverless-vector-permissions)
1. [Créer une collection](#serverless-vector-create)
1. [Charger et rechercher des données](#serverless-vector-index)
1. [Supprimer la collection](#serverless-vector-delete)
### Étape 1 : configurer des autorisations
Pour suivre ce didacticiel (et pour utiliser OpenSearch Serverless en général), vous devez disposer des autorisations Gestion des identités et des accès AWS (IAM) appropriées. Dans ce didacticiel, vous allez créer une collection, télécharger et rechercher des données, puis supprimer la collection.
Votre utilisateur ou votre rôle doit être associé à une [politique basée sur l'identité](security-iam-serverless.md#security-iam-serverless-id-based-policies) avec les autorisations minimales suivantes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"aoss:CreateCollection",
"aoss:ListCollections",
"aoss:BatchGetCollection",
"aoss:DeleteCollection",
"aoss:CreateAccessPolicy",
"aoss:ListAccessPolicies",
"aoss:UpdateAccessPolicy",
"aoss:CreateSecurityPolicy",
"iam:ListUsers",
"iam:ListRoles"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
Pour plus d'informations sur les autorisations IAM OpenSearch sans serveur, consultez. [Identity and Access Management pour Amazon OpenSearch Serverless](security-iam-serverless.md)
### Étape 2 : créer une collection
Une *collection* est un groupe d' OpenSearch index qui fonctionnent ensemble pour prendre en charge une charge de travail ou un cas d'utilisation spécifique.
**Pour créer une collection OpenSearch sans serveur**
1. Ouvrez la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home ).
1. Choisissez **Collections** dans le panneau de navigation de gauche, puis choisissez **Create collection** (Créer une collection).
1. Nommez le **boîtier** de collection.
1. Pour le type de collection, choisissez **Recherche vectorielle**. Pour de plus amples informations, veuillez consulter [Choix d'un type de collection](serverless-overview.md#serverless-usecase).
1. Sous **Type de déploiement**, désélectionnez **Activer la redondance (répliques actives)**. Cela crée une collection en mode développement ou test et réduit à deux le nombre d'unités de OpenSearch calcul (OCUs) de votre collection. Si vous souhaitez créer un environnement de production dans ce didacticiel, laissez la case cochée.
1. Sous **Sécurité**, sélectionnez **Easy create** pour rationaliser votre configuration de sécurité. Toutes les données du moteur vectoriel sont cryptées en transit et au repos par défaut. Le moteur vectoriel prend en charge les autorisations IAM détaillées afin que vous puissiez définir qui peut créer, mettre à jour et supprimer des chiffrements, des réseaux, des collections et des index.
1. Choisissez **Suivant**.
1. Vérifiez vos paramètres de collection et choisissez **Submit** (Soumettre). Attendez quelques minutes pour que le statut de la collection devienne `Active`.
### Étape 3 : charger et rechercher des données
Un *index* est un ensemble de documents dotés d'un schéma de données commun qui vous permet de stocker, de rechercher et de récupérer vos intégrations vectorielles et d'autres champs. [Vous pouvez créer et télécharger des données vers les index d'une collection OpenSearch sans serveur à l'aide de la console [Dev Tools](https://opensearch.org/docs/latest/dashboards/dev-tools/index-dev/) dans les OpenSearch tableaux de bord ou d'un outil HTTP tel que [Postman](https://www.postman.com/downloads/) ou awscurl.](https://github.com/okigan/awscurl) Ce didacticiel utilise les outils de développement.
**Pour indexer et rechercher des données dans la collection de logements**
1. Pour créer un index unique pour votre nouvelle collection, envoyez la demande suivante dans la console [Dev Tools](https://opensearch.org/docs/latest/dashboards/dev-tools/index-dev/). Par défaut, cela crée un index avec un `nmslib` moteur et une distance euclidienne.
```
PUT housing-index
{
"settings": {
"index.knn": true
},
"mappings": {
"properties": {
"housing-vector": {
"type": "knn_vector",
"dimension": 3
},
"title": {
"type": "text"
},
"price": {
"type": "long"
},
"location": {
"type": "geo_point"
}
}
}
}
```
1. Pour indexer un seul document dans *housing-index*, envoyez la demande suivante :
```
POST housing-index/_doc
{
"housing-vector": [
10,
20,
30
],
"title": "2 bedroom in downtown Seattle",
"price": "2800",
"location": "47.71, 122.00"
}
```
1. Pour rechercher des propriétés similaires à celles de votre index, envoyez la requête suivante :
```
GET housing-index/_search
{
"size": 5,
"query": {
"knn": {
"housing-vector": {
"vector": [
10,
20,
30
],
"k": 5
}
}
}
}
```
### Étape 4 : supprimer la collection
La collection de *logements* étant destinée à des fins de test, assurez-vous de la supprimer lorsque vous aurez terminé d'expérimenter.
**Pour supprimer une collection OpenSearch sans serveur**
1. Revenez à la console **Amazon OpenSearch Service**.
1. Choisissez **Collections** dans le volet de navigation de gauche et sélectionnez la collection de **propriétés**.
1. Choisissez **Supprimer** et confirmez la suppression.
## Recherche filtrée
Vous pouvez utiliser des filtres pour affiner les résultats de votre recherche sémantique. Pour créer un index et effectuer une recherche filtrée sur vos documents, remplacez les [données de téléchargement et de recherche](#serverless-vector-index) du didacticiel précédent par les instructions suivantes. Les autres étapes restent les mêmes. Pour plus d'informations sur les filtres, voir [K-nn search with filters](https://opensearch.org/docs/latest/search-plugins/knn/filter-search-knn/).
**Pour indexer et rechercher des données dans la collection de logements**
1. Pour créer un index unique pour votre collection, envoyez la demande suivante dans la console [Dev Tools](https://opensearch.org/docs/latest/dashboards/dev-tools/index-dev/) :
```
PUT housing-index-filtered
{
"settings": {
"index.knn": true
},
"mappings": {
"properties": {
"housing-vector": {
"type": "knn_vector",
"dimension": 3,
"method": {
"engine": "faiss",
"name": "hnsw"
}
},
"title": {
"type": "text"
},
"price": {
"type": "long"
},
"location": {
"type": "geo_point"
}
}
}
}
```
1. Pour indexer un seul document dans *housing-index-filtered*, envoyez la demande suivante :
```
POST housing-index-filtered/_doc
{
"housing-vector": [
10,
20,
30
],
"title": "2 bedroom in downtown Seattle",
"price": "2800",
"location": "47.71, 122.00"
}
```
1. Pour rechercher vos données pour un appartement à Seattle à un prix donné et à une distance donnée d'un point géographique, envoyez la demande suivante :
```
GET housing-index-filtered/_search
{
"size": 5,
"query": {
"knn": {
"housing-vector": {
"vector": [
0.1,
0.2,
0.3
],
"k": 5,
"filter": {
"bool": {
"must": [
{
"query_string": {
"query": "Find me 2 bedroom apartment in Seattle under $3000 ",
"fields": [
"title"
]
}
},
{
"range": {
"price": {
"lte": 3000
}
}
},
{
"geo_distance": {
"distance": "100miles",
"location": {
"lat": 48,
"lon": 121
}
}
}
]
}
}
}
}
}
}
```
## Des milliards de charges de travail à grande échelle
Les collections de recherche vectorielle prennent en charge des charges de travail contenant des milliards de vecteurs. Il n'est pas nécessaire de réindexer à des fins de mise à l'échelle, car la mise à l'échelle automatique s'en charge pour vous. Si vous possédez des millions de vecteurs (ou plus) avec un grand nombre de dimensions et que vous en avez besoin de plus de 200 OCUs, contactez le [AWS Support](https://aws.amazon.com/premiumsupport/) pour augmenter le nombre maximum d'unités de OpenSearch calcul (OCUs) pour votre compte.
## Limitations
Les collections de recherche vectorielle présentent les limites suivantes :
+ Les collections de recherche vectorielle ne sont pas compatibles avec le moteur Apache Lucene ANN.
+ Les collections de recherche vectorielle ne prennent en charge que l'algorithme HNSW avec Faiss et ne prennent pas en charge la FIV et l'IVFQ.
+ Les collections de recherche vectorielle ne prennent pas en charge les opérations de l'API d'échauffement, de statistiques et d'entraînement des modèles.
+ Les collections de recherche vectorielle ne prennent pas en charge les scripts intégrés ou stockés.
+ Les informations sur le nombre d'index ne sont pas disponibles dans AWS Management Console les collections de recherche vectorielle.
+ L'intervalle d'actualisation des index des collections de recherche vectorielle est de 60 secondes.
## Étapes suivantes
Maintenant que vous savez comment créer une collection de recherche vectorielle et indexer des données, vous pouvez essayer certains des exercices suivants :
+ Utilisez le client OpenSearch Python pour travailler avec des collections de recherche vectorielle. Consultez ce didacticiel sur [GitHub](https://github.com/opensearch-project/opensearch-py/blob/main/guides/plugins/knn.md).
+ Utilisez le client OpenSearch Java pour travailler avec des collections de recherche vectorielle. Consultez ce didacticiel sur [GitHub](https://github.com/opensearch-project/opensearch-java/blob/main/guides/plugins/knn.md).
+ Configuré LangChain pour être utilisé OpenSearch comme magasin de vecteurs. LangChain est un framework open source permettant de développer des applications basées sur des modèles de langage. Pour plus d’informations, consultez la [documentation LangChain ](https://python.langchain.com/docs/integrations/vectorstores/opensearch).
# Utilisation des politiques de cycle de vie des données avec Amazon OpenSearch Serverless
Une politique de cycle de vie des données dans Amazon OpenSearch Serverless définit la durée pendant laquelle OpenSearch Serverless conserve les données dans une collection de séries chronologiques. Par exemple, vous pouvez définir une politique pour conserver les données du journal pendant 30 jours avant que OpenSearch Serverless ne les supprime.
Vous pouvez configurer une politique distincte pour chaque index de chaque collection de séries chronologiques de votre Compte AWS. OpenSearch Serverless conserve les documents pendant au moins la durée que vous spécifiez dans la politique. Il supprime ensuite les documents automatiquement dans la mesure du possible, généralement dans les 48 heures ou 10 % de la période de conservation, selon le délai le plus long.
Seules les collections de séries chronologiques prennent en charge les politiques de cycle de vie des données. Les collections de recherche et de recherche vectorielle ne le sont pas.
**Topics**
+ [Politiques relatives au cycle de vie](#serverless-lifecycle-policies)
+ [Autorisations requises](#serverless-lifecycle-permissions)
+ [Priorité des stratégies](#serverless-lifecycle-precedence)
+ [Syntaxe d’une politique](#serverless-lifecycle-syntax)
+ [Création de politiques de cycle de vie des données](#serverless-lifecycle-create)
+ [Mise à jour des politiques de cycle de vie](#serverless-lifecycle-update)
+ [Supprimer les politiques de cycle de vie des données](#serverless-lifecycle-delete)
## Politiques relatives au cycle de vie
Dans une politique de cycle de vie des données, vous définissez une série de règles. La politique de cycle de vie des données vous permet de gérer la période de conservation des données associées aux index ou aux collections conformes à ces règles. Ces règles définissent la durée de conservation des données d'un index ou d'un groupe d'index. Chaque règle comprend un type de ressource (`index`), une période de rétention et une liste de ressources (index) auxquelles s'applique la période de rétention.
Vous définissez la période de conservation à l'aide de l'un des formats suivants :
+ `"MinIndexRetention": "24h"`— OpenSearch Serverless conserve les données d'index pendant la période spécifiée en heures ou en jours. Vous pouvez définir cette période pour qu'elle soit comprise entre `24h` et`3650d`.
+ `"NoMinIndexRetention": true`— OpenSearch Serverless conserve les données d'index indéfiniment.
Dans l'exemple de politique suivant, la première règle spécifie une période de conservation de 15 jours pour tous les index de la collection`marketing`. La deuxième règle précise que tous les noms d'index commençant par `log` dans la `finance` collection n'ont pas de période de conservation définie et seront conservés indéfiniment.
```
{
"lifeCyclePolicyDetail": {
"type": "retention",
"name": "my-policy",
"policyVersion": "MTY4ODI0NTM2OTk1N18x",
"policy": {
"Rules": [
{
"ResourceType":"index",
"Resource":[
"index/marketing/*"
],
"MinIndexRetention": "15d"
},
{
"ResourceType":"index",
"Resource":[
"index/finance/log*"
],
"NoMinIndexRetention": true
}
]
},
"createdDate": 1688245369957,
"lastModifiedDate": 1688245369957
}
}
```
Dans l'exemple de règle de politique suivant, OpenSearch Serverless conserve indéfiniment les données de tous les index pour toutes les collections du compte.
```
{
"Rules": [
{
"ResourceType": "index",
"Resource": [
"index/*/*"
]
}
],
"NoMinIndexRetention": true
}
```
## Autorisations requises
Les politiques de cycle de vie pour OpenSearch Serverless utilisent les autorisations Gestion des identités et des accès AWS (IAM) suivantes. Vous pouvez définir des conditions IAM pour limiter les utilisateurs aux politiques de cycle de vie des données associées à des collections et à des index spécifiques.
+ `aoss:CreateLifecyclePolicy`— Créez une politique de cycle de vie des données.
+ `aoss:ListLifecyclePolicies`— Répertoriez toutes les politiques relatives au cycle de vie des données du compte courant.
+ `aoss:BatchGetLifecyclePolicy`— Consultez une politique de cycle de vie des données associée à un compte ou à un nom de politique.
+ `aoss:BatchGetEffectiveLifecyclePolicy`— Afficher une politique de cycle de vie des données pour une ressource donnée (`index`c'est la seule ressource prise en charge).
+ `aoss:UpdateLifecyclePolicy`— Modifiez une politique de cycle de vie des données donnée et modifiez son paramètre ou sa ressource de rétention.
+ `aoss:DeleteLifecyclePolicy`— Supprimez une politique de cycle de vie des données.
La politique d'accès basée sur l'identité suivante permet à un utilisateur de consulter toutes les politiques relatives au cycle de vie des données et de mettre à jour les politiques en fonction du modèle de ressources : `index/application-logs`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"aoss:UpdateLifecyclePolicy"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aoss:collection": "application-logs"
}
}
},
{
"Effect": "Allow",
"Action": [
"aoss:ListLifecyclePolicies",
"aoss:BatchGetLifecyclePolicy"
],
"Resource": "*"
}
]
}
```
------
## Priorité des stratégies
Dans certaines situations, les règles relatives au cycle de vie des données se chevauchent, au sein des politiques ou entre celles-ci. Dans ce cas, une règle avec un nom de ressource ou un modèle de ressource plus spécifique pour un index remplace une règle avec un nom de ressource ou un modèle de ressource plus général pour tous les index communs aux *deux* règles.
Par exemple, dans la politique suivante, deux règles s'appliquent à un index`index/sales/logstash`. Dans ce cas, la deuxième règle a priorité car elle `index/sales/log*` correspond le plus longtemps à`index/sales/logstash`. Par conséquent, OpenSearch Serverless ne définit aucune période de rétention pour l'index.
```
{
"Rules":[
{
"ResourceType":"index",
"Resource":[
"index/sales/*",
],
"MinIndexRetention": "15d"
},
{
"ResourceType":"index",
"Resource":[
"index/sales/log*",
],
"NoMinIndexRetention": true
}
]
}
```
## Syntaxe d’une politique
Fournissez une ou plusieurs *règles*. Ces règles définissent les paramètres du cycle de vie des données pour vos index OpenSearch sans serveur.
Chaque règle contient les éléments suivants. Vous pouvez fournir `MinIndexRetention` ou `NoMinIndexRetention` dans chaque règle, mais pas les deux.
| Element | Description |
| --- | --- |
| Type de ressource | Type de ressource auquel s'applique la règle. La seule option prise en charge pour les politiques de cycle de vie des données estindex. |
| Ressource | Une liste de and/or modèles de noms de ressources. Les modèles se composent d'un préfixe et d'un caractère générique (\$1), qui permettent aux autorisations associées de s'appliquer à plusieurs ressources. Par exemple, index//. |
| MinIndexRetention | Période minimale, en jours (d) ou heures (h), pour conserver le document dans l'index. La limite inférieure est 24h et la limite supérieure est3650d. |
| NoMinIndexRetention | Sitrue, OpenSearch Serverless conserve les documents indéfiniment. |
Dans l'exemple suivant, la première règle s'applique à tous les index du `autoparts-inventory` modèle (`index/autoparts-inventory/*`) et exige que les données soient conservées pendant au moins 20 jours avant que toute action, telle que la suppression ou l'archivage, ne puisse avoir lieu.
La deuxième règle cible les index correspondant au `auto*/gear` modèle (`index/auto*/gear`), en fixant une période de conservation minimale de 24 heures.
La troisième règle s'applique spécifiquement à l'`tires`index et ne prévoit aucune durée de conservation minimale, ce qui signifie que les données de cet index peuvent être supprimées ou archivées immédiatement ou en fonction d'autres critères. Ces règles permettent de gérer la conservation des données d'index avec des durées de conservation variables ou sans restrictions de conservation.
```
{
"Rules": [
{
"ResourceType": "index",
"Resource": [
"index/autoparts-inventory/*"
],
"MinIndexRetention": "20d"
},
{
"ResourceType": "index",
"Resource": [
"index/auto*/gear"
],
"MinIndexRetention": "24h"
},
{
"ResourceType": "index",
"Resource": [
"index/autoparts-inventory/tires"
],
"NoMinIndexRetention": true
}
]
}
```
## Création de politiques de cycle de vie des données
Pour créer une politique de cycle de vie des données, vous définissez des règles qui gèrent la conservation et la suppression de vos données en fonction de critères spécifiques.
### Console
**Pour créer une politique de cycle de vie des données**
1. Connectez-vous à la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home).
1. Dans le volet de navigation de gauche, sélectionnez **Data Lifecycle policies**.
1. Choisissez **Créer une politique de cycle de vie des données**.
1. Entrez un nom descriptif pour la politique.
1. Pour le **cycle de vie des données**, choisissez **Ajouter** et sélectionnez les collections et les index pour la politique.
Commencez par choisir les collections auxquelles appartiennent les index. Choisissez ensuite l'index dans la liste ou entrez un modèle d'index. Pour sélectionner toutes les collections comme sources, entrez un astérisque (`*`).
1. Pour **la conservation des données**, vous pouvez choisir de conserver les données indéfiniment ou de désélectionner **Illimité (ne jamais supprimer)** et de spécifier une période après laquelle OpenSearch Serverless supprime automatiquement les données d'Amazon S3.
1. Choisissez **Enregistrer**, puis **Créer**.
### AWS CLI
Pour créer une politique de cycle de vie des données à l'aide de AWS CLI, utilisez la [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/create-lifecycle-policy.html)commande avec les options suivantes :
+ `--name`— Le nom de la politique.
+ `--type`— Le type de politique. Actuellement, la seule valeur disponible est`retention`.
+ `--policy`— La politique de cycle de vie des données. Ce paramètre accepte à la fois les politiques intégrées et les fichiers .json. Vous devez encoder les politiques intégrées sous forme de chaîne JSON échappée. Pour fournir la politique dans un fichier, utilisez le format`--policy file://my-policy.json`.
**Example**
```
aws opensearchserverless create-lifecycle-policy \
--name my-policy \
--type retention \
--policy "{\"Rules\":[{\"ResourceType\":\"index\",\"Resource\":[\"index/autoparts-inventory/*\"],\"MinIndexRetention\": \"81d\"},{\"ResourceType\":\"index\",\"Resource\":[\"index/sales/orders*\"],\"NoMinIndexRetention\":true}]}"
```
## Mise à jour des politiques de cycle de vie
Pour mettre à jour une politique de cycle de vie des données, vous pouvez modifier les règles existantes afin de tenir compte de l'évolution de vos exigences en matière de conservation ou de suppression des données. Cela vous permet d'adapter vos politiques en fonction de l'évolution de vos besoins en matière de gestion des données.
Il peut s'écouler quelques minutes entre le moment où vous mettez à jour la politique et le moment où OpenSearch Serverless commence à appliquer les nouvelles périodes de rétention.
### Console
**Pour mettre à jour une politique de cycle de vie des données**
1. Connectez-vous à la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home).
1. Dans le volet de navigation de gauche, sélectionnez **Data Lifecycle policies**.
1. Sélectionnez la politique de cycle de vie des données que vous souhaitez mettre à jour, puis choisissez **Modifier**.
1. Modifiez la politique à l'aide de l'éditeur visuel ou de l'éditeur JSON.
1. Choisissez **Enregistrer**.
### AWS CLI
Pour mettre à jour une politique de cycle de vie des données à l'aide de AWS CLI, utilisez la [update-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/update-lifecycle-policy.html)commande.
Vous devez inclure le `--policy-version` paramètre dans la demande. Vous pouvez récupérer la version de stratégie à l'aide des commandes [list-lifecycle-policies](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/list-lifecycle-policies.html) ou [batch-get-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/batch-get-lifecycle-policy.html). Nous vous recommandons d'inclure la version de politique la plus récente afin d'éviter de remplacer accidentellement les modifications apportées par d'autres personnes.
La demande suivante met à jour une politique de cycle de vie des données avec un nouveau document JSON de politique.
**Example**
```
aws opensearchserverless update-lifecycle-policy \
--name my-policy \
--type retention \
--policy-version MTY2MzY5MTY1MDA3Ml8x \
--policy file://my-new-policy.json
```
## Supprimer les politiques de cycle de vie des données
Lorsque vous supprimez une politique de cycle de vie des données, OpenSearch Serverless ne l'applique plus aux index correspondants.
### Console
**Pour supprimer une politique de cycle de vie des données**
1. Connectez-vous à la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home).
1. Dans le volet de navigation de gauche, sélectionnez **Data Lifecycle policies**.
1. Sélectionnez la politique que vous souhaitez supprimer, puis choisissez **Supprimer** et confirmez la suppression.
### AWS CLI
Pour supprimer une politique de cycle de vie des données à l'aide de AWS CLI, utilisez la [delete-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/delete-lifecycle-policy.html)commande.
**Example**
```
aws opensearchserverless delete-lifecycle-policy \
--name my-policy \
--type retention
```
# Utilisation du AWS SDKs pour interagir avec Amazon OpenSearch Serverless
Cette section contient des exemples d'utilisation du AWS SDKs pour interagir avec Amazon OpenSearch Serverless. Ces exemples de code montrent comment créer des stratégies de sécurité et des collections et comment interroger des collections.
**Note**
Nous sommes en train de créer ces exemples de code. Si vous souhaitez apporter un exemple de code (Java, Go, etc.), veuillez ouvrir une pull request directement dans le [GitHub référentiel](https://github.com/awsdocs/amazon-opensearch-service-developer-guide/blob/master/doc_source/serverless-sdk.md).
**Topics**
+ [Python](#serverless-sdk-python)
+ [JavaScript](#serverless-sdk-javascript)
## Python
L'exemple de script suivant utilise le client [AWS SDK pour Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/opensearchserverless.html), ainsi que le client [opensearch-py](https://pypi.org/project/opensearch-py/) pour Python, pour créer des stratégies de chiffrement, réseau et d'accès aux données, créer une collection correspondante et indexer des exemples de données.
Pour installer les dépendances requises, exécutez les commandes suivantes :
```
pip install opensearch-py
pip install boto3
pip install botocore
pip install requests-aws4auth
```
Dans le script, remplacez l'élément `Principal` par l'Amazon Resource Name (ARN) de l'utilisateur ou du rôle qui signe la requête. Vous pouvez également modifier la `region`.
```
from opensearchpy import OpenSearch, RequestsHttpConnection
from requests_aws4auth import AWS4Auth
import boto3
import botocore
import time
# Build the client using the default credential configuration.
# You can use the CLI and run 'aws configure' to set access key, secret
# key, and default region.
client = boto3.client('opensearchserverless')
service = 'aoss'
region = 'us-east-1'
credentials = boto3.Session().get_credentials()
awsauth = AWS4Auth(credentials.access_key, credentials.secret_key,
region, service, session_token=credentials.token)
def createEncryptionPolicy(client):
"""Creates an encryption policy that matches all collections beginning with tv-"""
try:
response = client.create_security_policy(
description='Encryption policy for TV collections',
name='tv-policy',
policy="""
{
\"Rules\":[
{
\"ResourceType\":\"collection\",
\"Resource\":[
\"collection\/tv-*\"
]
}
],
\"AWSOwnedKey\":true
}
""",
type='encryption'
)
print('\nEncryption policy created:')
print(response)
except botocore.exceptions.ClientError as error:
if error.response['Error']['Code'] == 'ConflictException':
print(
'[ConflictException] The policy name or rules conflict with an existing policy.')
else:
raise error
def createNetworkPolicy(client):
"""Creates a network policy that matches all collections beginning with tv-"""
try:
response = client.create_security_policy(
description='Network policy for TV collections',
name='tv-policy',
policy="""
[{
\"Description\":\"Public access for TV collection\",
\"Rules\":[
{
\"ResourceType\":\"dashboard\",
\"Resource\":[\"collection\/tv-*\"]
},
{
\"ResourceType\":\"collection\",
\"Resource\":[\"collection\/tv-*\"]
}
],
\"AllowFromPublic\":true
}]
""",
type='network'
)
print('\nNetwork policy created:')
print(response)
except botocore.exceptions.ClientError as error:
if error.response['Error']['Code'] == 'ConflictException':
print(
'[ConflictException] A network policy with this name already exists.')
else:
raise error
def createAccessPolicy(client):
"""Creates a data access policy that matches all collections beginning with tv-"""
try:
response = client.create_access_policy(
description='Data access policy for TV collections',
name='tv-policy',
policy="""
[{
\"Rules\":[
{
\"Resource\":[
\"index\/tv-*\/*\"
],
\"Permission\":[
\"aoss:CreateIndex\",
\"aoss:DeleteIndex\",
\"aoss:UpdateIndex\",
\"aoss:DescribeIndex\",
\"aoss:ReadDocument\",
\"aoss:WriteDocument\"
],
\"ResourceType\": \"index\"
},
{
\"Resource\":[
\"collection\/tv-*\"
],
\"Permission\":[
\"aoss:CreateCollectionItems\"
],
\"ResourceType\": \"collection\"
}
],
\"Principal\":[
\"arn:aws:iam::123456789012:role\/Admin\"
]
}]
""",
type='data'
)
print('\nAccess policy created:')
print(response)
except botocore.exceptions.ClientError as error:
if error.response['Error']['Code'] == 'ConflictException':
print(
'[ConflictException] An access policy with this name already exists.')
else:
raise error
def createCollection(client):
"""Creates a collection"""
try:
response = client.create_collection(
name='tv-sitcoms',
type='SEARCH'
)
return(response)
except botocore.exceptions.ClientError as error:
if error.response['Error']['Code'] == 'ConflictException':
print(
'[ConflictException] A collection with this name already exists. Try another name.')
else:
raise error
def waitForCollectionCreation(client):
"""Waits for the collection to become active"""
response = client.batch_get_collection(
names=['tv-sitcoms'])
# Periodically check collection status
while (response['collectionDetails'][0]['status']) == 'CREATING':
print('Creating collection...')
time.sleep(30)
response = client.batch_get_collection(
names=['tv-sitcoms'])
print('\nCollection successfully created:')
print(response["collectionDetails"])
# Extract the collection endpoint from the response
host = (response['collectionDetails'][0]['collectionEndpoint'])
final_host = host.replace("https://", "")
indexData(final_host)
def indexData(host):
"""Create an index and add some sample data"""
# Build the OpenSearch client
client = OpenSearch(
hosts=[{'host': host, 'port': 443}],
http_auth=awsauth,
use_ssl=True,
verify_certs=True,
connection_class=RequestsHttpConnection,
timeout=300
)
# It can take up to a minute for data access rules to be enforced
time.sleep(45)
# Create index
response = client.indices.create('sitcoms-eighties')
print('\nCreating index:')
print(response)
# Add a document to the index.
response = client.index(
index='sitcoms-eighties',
body={
'title': 'Seinfeld',
'creator': 'Larry David',
'year': 1989
},
id='1',
)
print('\nDocument added:')
print(response)
def main():
createEncryptionPolicy(client)
createNetworkPolicy(client)
createAccessPolicy(client)
createCollection(client)
waitForCollectionCreation(client)
if __name__ == "__main__":
main()
```
## JavaScript
L'exemple de script suivant utilise le [SDK pour JavaScript Node.js](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-opensearchserverless/), ainsi que le client [opensearch-js](https://www.npmjs.com/package/@opensearch-project/opensearch) pour JavaScript, pour créer des politiques de chiffrement, de réseau et d'accès aux données, créer une collection correspondante, créer un index et indexer des exemples de données.
Pour installer les dépendances requises, exécutez les commandes suivantes :
```
npm i aws-sdk
npm i aws4
npm i @opensearch-project/opensearch
```
Dans le script, remplacez l'élément `Principal` par l'Amazon Resource Name (ARN) de l'utilisateur ou du rôle qui signe la requête. Vous pouvez également modifier la `region`.
```
var AWS = require('aws-sdk');
var aws4 = require('aws4');
var {
Client,
Connection
} = require("@opensearch-project/opensearch");
var {
OpenSearchServerlessClient,
CreateSecurityPolicyCommand,
CreateAccessPolicyCommand,
CreateCollectionCommand,
BatchGetCollectionCommand
} = require("@aws-sdk/client-opensearchserverless");
var client = new OpenSearchServerlessClient();
async function execute() {
await createEncryptionPolicy(client)
await createNetworkPolicy(client)
await createAccessPolicy(client)
await createCollection(client)
await waitForCollectionCreation(client)
}
async function createEncryptionPolicy(client) {
// Creates an encryption policy that matches all collections beginning with 'tv-'
try {
var command = new CreateSecurityPolicyCommand({
description: 'Encryption policy for TV collections',
name: 'tv-policy',
type: 'encryption',
policy: " \
{ \
\"Rules\":[ \
{ \
\"ResourceType\":\"collection\", \
\"Resource\":[ \
\"collection\/tv-*\" \
] \
} \
], \
\"AWSOwnedKey\":true \
}"
});
const response = await client.send(command);
console.log("Encryption policy created:");
console.log(response['securityPolicyDetail']);
} catch (error) {
if (error.name === 'ConflictException') {
console.log('[ConflictException] The policy name or rules conflict with an existing policy.');
} else
console.error(error);
};
}
async function createNetworkPolicy(client) {
// Creates a network policy that matches all collections beginning with 'tv-'
try {
var command = new CreateSecurityPolicyCommand({
description: 'Network policy for TV collections',
name: 'tv-policy',
type: 'network',
policy: " \
[{ \
\"Description\":\"Public access for television collection\", \
\"Rules\":[ \
{ \
\"ResourceType\":\"dashboard\", \
\"Resource\":[\"collection\/tv-*\"] \
}, \
{ \
\"ResourceType\":\"collection\", \
\"Resource\":[\"collection\/tv-*\"] \
} \
], \
\"AllowFromPublic\":true \
}]"
});
const response = await client.send(command);
console.log("Network policy created:");
console.log(response['securityPolicyDetail']);
} catch (error) {
if (error.name === 'ConflictException') {
console.log('[ConflictException] A network policy with that name already exists.');
} else
console.error(error);
};
}
async function createAccessPolicy(client) {
// Creates a data access policy that matches all collections beginning with 'tv-'
try {
var command = new CreateAccessPolicyCommand({
description: 'Data access policy for TV collections',
name: 'tv-policy',
type: 'data',
policy: " \
[{ \
\"Rules\":[ \
{ \
\"Resource\":[ \
\"index\/tv-*\/*\" \
], \
\"Permission\":[ \
\"aoss:CreateIndex\", \
\"aoss:DeleteIndex\", \
\"aoss:UpdateIndex\", \
\"aoss:DescribeIndex\", \
\"aoss:ReadDocument\", \
\"aoss:WriteDocument\" \
], \
\"ResourceType\": \"index\" \
}, \
{ \
\"Resource\":[ \
\"collection\/tv-*\" \
], \
\"Permission\":[ \
\"aoss:CreateCollectionItems\" \
], \
\"ResourceType\": \"collection\" \
} \
], \
\"Principal\":[ \
\"arn:aws:iam::123456789012:role\/Admin\" \
] \
}]"
});
const response = await client.send(command);
console.log("Access policy created:");
console.log(response['accessPolicyDetail']);
} catch (error) {
if (error.name === 'ConflictException') {
console.log('[ConflictException] An access policy with that name already exists.');
} else
console.error(error);
};
}
async function createCollection(client) {
// Creates a collection to hold TV sitcoms indexes
try {
var command = new CreateCollectionCommand({
name: 'tv-sitcoms',
type: 'SEARCH'
});
const response = await client.send(command);
return (response)
} catch (error) {
if (error.name === 'ConflictException') {
console.log('[ConflictException] A collection with this name already exists. Try another name.');
} else
console.error(error);
};
}
async function waitForCollectionCreation(client) {
// Waits for the collection to become active
try {
var command = new BatchGetCollectionCommand({
names: ['tv-sitcoms']
});
var response = await client.send(command);
while (response.collectionDetails[0]['status'] == 'CREATING') {
console.log('Creating collection...')
await sleep(30000) // Wait for 30 seconds, then check the status again
function sleep(ms) {
return new Promise((resolve) => {
setTimeout(resolve, ms);
});
}
var response = await client.send(command);
}
console.log('Collection successfully created:');
console.log(response['collectionDetails']);
// Extract the collection endpoint from the response
var host = (response.collectionDetails[0]['collectionEndpoint'])
// Pass collection endpoint to index document request
indexDocument(host)
} catch (error) {
console.error(error);
};
}
async function indexDocument(host) {
var client = new Client({
node: host,
Connection: class extends Connection {
buildRequestObject(params) {
var request = super.buildRequestObject(params)
request.service = 'aoss';
request.region = 'us-east-1'; // e.g. us-east-1
var body = request.body;
request.body = undefined;
delete request.headers['content-length'];
request.headers['x-amz-content-sha256'] = 'UNSIGNED-PAYLOAD';
request = aws4.sign(request, AWS.config.credentials);
request.body = body;
return request
}
}
});
// Create an index
try {
var index_name = "sitcoms-eighties";
var response = await client.indices.create({
index: index_name
});
console.log("Creating index:");
console.log(response.body);
// Add a document to the index
var document = "{ \"title\": \"Seinfeld\", \"creator\": \"Larry David\", \"year\": \"1989\" }\n";
var response = await client.index({
index: index_name,
body: document
});
console.log("Adding document:");
console.log(response.body);
} catch (error) {
console.error(error);
};
}
execute()
```
# Utilisation CloudFormation pour créer des collections Amazon OpenSearch Serverless
Vous pouvez les utiliser CloudFormation pour créer des ressources Amazon OpenSearch Serverless telles que des collections, des politiques de sécurité et des points de terminaison VPC. Pour obtenir une CloudFormation référence complète sur le OpenSearch mode sans serveur, consultez [Amazon OpenSearch Serverless](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_OpenSearchServerless.html) dans le guide de l'*CloudFormation utilisateur*.
L'exemple de CloudFormation modèle suivant crée une politique d'accès aux données, une politique réseau et une politique de sécurité simples, ainsi qu'une collection correspondante. C'est un bon moyen d'être rapidement opérationnel avec Amazon OpenSearch Serverless et de fournir les éléments nécessaires à la création et à l'utilisation d'une collection.
**Important**
Cet exemple utilise l'accès au réseau public, ce qui n'est pas recommandé pour les charges de travail de production. Nous vous recommandons d'utiliser l'accès VPC pour protéger vos collections. Pour plus d'informations, consultez [AWS::OpenSearchServerless::VpcEndpoint](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-opensearchserverless-vpcendpoint.html) et [Accès au plan de données via AWS PrivateLink](serverless-vpc.md).
```
AWSTemplateFormatVersion: 2010-09-09
Description: 'Amazon OpenSearch Serverless template to create an IAM user, encryption policy, data access policy and collection'
Resources:
IAMUSer:
Type: 'AWS::IAM::User'
Properties:
UserName: aossadmin
DataAccessPolicy:
Type: 'AWS::OpenSearchServerless::AccessPolicy'
Properties:
Name: quickstart-access-policy
Type: data
Description: Access policy for quickstart collection
Policy: !Sub >-
[{"Description":"Access for cfn user","Rules":[{"ResourceType":"index","Resource":["index/*/*"],"Permission":["aoss:*"]},
{"ResourceType":"collection","Resource":["collection/quickstart"],"Permission":["aoss:*"]}],
"Principal":["arn:aws:iam::${AWS::AccountId}:user/aossadmin"]}]
NetworkPolicy:
Type: 'AWS::OpenSearchServerless::SecurityPolicy'
Properties:
Name: quickstart-network-policy
Type: network
Description: Network policy for quickstart collection
Policy: >-
[{"Rules":[{"ResourceType":"collection","Resource":["collection/quickstart"]}, {"ResourceType":"dashboard","Resource":["collection/quickstart"]}],"AllowFromPublic":true}]
EncryptionPolicy:
Type: 'AWS::OpenSearchServerless::SecurityPolicy'
Properties:
Name: quickstart-security-policy
Type: encryption
Description: Encryption policy for quickstart collection
Policy: >-
{"Rules":[{"ResourceType":"collection","Resource":["collection/quickstart"]}],"AWSOwnedKey":true}
Collection:
Type: 'AWS::OpenSearchServerless::Collection'
Properties:
Name: quickstart
Type: TIMESERIES
Description: Collection to holds timeseries data
DependsOn: EncryptionPolicy
Outputs:
IAMUser:
Value: !Ref IAMUSer
DashboardURL:
Value: !GetAtt Collection.DashboardEndpoint
CollectionARN:
Value: !GetAtt Collection.Arn
```
# Sauvegarde de collections à l'aide de snapshots
Les snapshots sont point-in-time des sauvegardes de vos collections Amazon OpenSearch Serverless qui fournissent des fonctionnalités de reprise après sinistre. OpenSearch Serverless crée et gère automatiquement des instantanés de vos collections, garantissant ainsi la continuité des activités et la protection des données. Chaque instantané contient des métadonnées d'index (paramètres et mappages pour vos index), des métadonnées de cluster (modèles d'index et alias) et des données d'index (tous les documents et données stockés dans vos index).
OpenSearch Serverless fournit des sauvegardes automatiques toutes les heures sans configuration manuelle, sans frais de maintenance, sans frais de stockage supplémentaires, avec une restauration rapide en cas de perte de données accidentelle et la possibilité de restaurer des index spécifiques à partir d'un instantané.
Avant de travailler avec des instantanés, prenez connaissance de ces considérations importantes. La création d'un instantané prend du temps et n'est pas instantanée. Les nouveaux documents ou les mises à jour lors de la création d'un instantané ne seront pas inclus dans l'instantané. Vous pouvez restaurer les instantanés uniquement dans leur collection d'origine et non dans une nouvelle collection. Une fois restaurés, les index reçoivent de nouvelles UUIDs versions différentes de leurs versions d'origine. La restauration d'un index ouvert existant dans OpenSearch Serverless remplacera les données de cet index à condition qu'aucun nouveau nom d'index ou modèle de préfixe ne soit fourni. Cela diffère du comportement de base. OpenSearch Vous ne pouvez exécuter qu'une seule opération de restauration à la fois, et vous ne pouvez pas démarrer plusieurs opérations de restauration simultanément sur la même collection. Toute tentative de restauration d'index pendant une opération de restauration active entraîne l'échec de l'opération. Au cours d'une opération de restauration, vos demandes adressées aux index échouent.
## Autorisations requises
Pour utiliser des instantanés, configurez les autorisations suivantes dans votre politique d'accès aux données. Pour plus d'informations sur les politiques d'accès aux données, consultez[Stratégies d'accès aux données ou politiques IAM](serverless-data-access.md#serverless-data-access-vs-iam).
****
| Politique d'accès aux données | APIs |
| --- | --- |
| aoss : DescribeSnapshot | GET /\$1 -automatisé cat/snapshots/aossOBTENEZ \$1snapshot/aoss-automated/snapshot/ |
| aoss : RestoreSnapshot | POST /\$1 /\$1restore snapshot/aoss-automated/snapshot |
| aoss : DescribeCollectionItems | OBTENEZ /\$1cat/recovery |
Vous pouvez configurer les politiques à l'aide des AWS CLI commandes suivantes :
1. [ create-access-policy](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/create-access-policy.html)
1. [ delete-access-policy ](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/delete-access-policy.html)
1. [ get-access-policy ](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/get-access-policy.html)
1. [ update-access-policy ](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/update-access-policy.html)
Voici un exemple de commande CLI pour créer une politique d'accès. Dans la commande, remplacez le *example* contenu par vos informations spécifiques.
```
aws opensearchserverless create-access-policy \
--type data \
--name Example-data-access-policy \
--region aws-region \
--policy '[
{
"Rules": [
{
"Resource": [
"collection/Example-collection"
],
"Permission": [
"aoss:DescribeSnapshot",
"aoss:RestoreSnapshot",
"aoss:DescribeCollectionItems"
],
"ResourceType": "collection"
}
],
"Principal": [
"arn:aws:iam::111122223333:user/UserName"
],
"Description": "Data policy to support snapshot operations."
}
]'
```
## Utilisation des instantanés
Par défaut, lorsque vous créez une nouvelle collection, OpenSearch Serverless crée automatiquement des instantanés toutes les heures. Aucune action de votre part n'est requise. Chaque instantané inclut tous les index de la collection. Une fois que OpenSearch Serverless a créé des instantanés, vous pouvez les répertorier et consulter les détails de l'instantané à l'aide des procédures suivantes.
### Répertorier les instantanés
Utilisez les procédures suivantes pour répertorier tous les instantanés d'une collection et vérifier leurs détails.
------
#### [ Console ]
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).
1. Dans le volet de navigation de gauche, choisissez **Serverless**, puis **Collections**.
1. Choisissez le nom de votre collection pour ouvrir sa page de détails.
1. Choisissez l'onglet **Instantanés** pour afficher tous les instantanés générés.
1. Passez en revue les informations de l'instantané, notamment :
+ **ID de capture d'écran** : identifiant unique pour l'instantané
+ **État** - État actuel (disponible, en cours)
+ **Heure de création** : date à laquelle le cliché a été pris
------
#### [ AWS CLI ]
+ Utilisez la commande suivante pour répertorier tous les instantanés d'une collection :
```
GET /_cat/snapshots/aoss-automated
```
OpenSearch Serverless renvoie une réponse semblable à la suivante :
```
id status start_epoch start_time end_epoch end_time duration indexes successful_shards failed_shards total_shards
snapshot-ExampleSnapshotID1 SUCCESS 1737964331 07:52:11 1737964382 07:53:02 50.4s 1
snapshot-ExampleSnapshotID2 SUCCESS 1737967931 08:52:11 1737967979 08:52:59 47.7s 2
snapshot-ExampleSnapshotID3 SUCCESS 1737971531 09:52:11 1737971581 09:53:01 49.1s 3
snapshot-ExampleSnapshotID4 IN_PROGRESS 1737975131 10:52:11 - - 4.8d 3
```
------
### Obtenir des informations sur les instantanés
Utilisez les procédures suivantes pour récupérer des informations détaillées sur un instantané spécifique.
------
#### [ Console ]
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).
1. Dans le volet de navigation de gauche, choisissez **Serverless**, puis **Collections**.
1. Choisissez le nom de votre collection pour ouvrir sa page de détails.
1. Choisissez l'onglet **Instantanés**.
1. Choisissez l'ID de la tâche de capture instantanée pour afficher des informations détaillées sur la capture instantanée, notamment les métadonnées, les index inclus et les informations temporelles.
------
#### [ AWS CLI ]
+ Utilisez la commande suivante pour récupérer les informations relatives à un instantané. Dans la commande, remplacez le *example* contenu par vos informations spécifiques.
```
GET _snapshot/aoss-automated/snapshot/
```
Exemple de demande :
```
GET _snapshot/aoss-automated/snapshot-ExampleSnapshotID1/
```
Exemple de réponse :
```
{
"snapshots": [
{
"snapshot": "snapshot-ExampleSnapshotID1-5e01-4423-9833Example",
"uuid": "Example-5e01-4423-9833-9e9eb757Example",
"version_id": 136327827,
"version": "2.11.0",
"remote_store_index_shallow_copy": true,
"indexes": [
"Example-index-0117"
],
"data_streams": [],
"include_global_state": true,
"metadata": {},
"state": "SUCCESS",
"start_time": "2025-01-27T09:52:11.953Z",
"start_time_in_millis": 1737971531953,
"end_time": "2025-01-27T09:53:01.062Z",
"end_time_in_millis": 1737971581062,
"duration_in_millis": 49109,
"failures": [],
"shards": {
"total": 0,
"failed": 0,
"successful": 0
}
}
]
}
```
------
La réponse instantanée inclut plusieurs champs clés : `id` fournit un identifiant unique pour l'opération de capture instantanée, `status` renvoie l'état actuel `SUCCESS` ou `IN_PROGRESS` `duration` indique le temps nécessaire pour terminer l'opération de capture instantanée et `indexes` renvoie le nombre d'index inclus dans l'instantané.
## Restaurer à partir d’un instantané
La restauration à partir d'un instantané permet de récupérer les données d'une sauvegarde effectuée précédemment. Ce processus est crucial pour la reprise après sinistre et la gestion des données en mode OpenSearch Serverless. Avant la restauration, sachez que les index restaurés seront différents de leurs versions d'origine, UUIDs que la restauration d'un index ouvert existant dans OpenSearch Serverless remplacera les données de cet index à condition qu'un nouveau nom d'index ou qu'aucun modèle de préfixe ne soit fourni, que les instantanés ne peuvent être restaurés que dans leur collection d'origine (la restauration entre collections n'est pas prise en charge) et que les opérations de restauration auront un impact sur les performances du cluster. Planifiez en conséquence.
Utilisez les procédures suivantes pour restaurer des index sauvegardés à partir d'un instantané.
------
#### [ Console ]
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).
1. Dans le volet de navigation de gauche, choisissez **Serverless**, puis **Collections**.
1. Choisissez le nom de votre collection pour ouvrir sa page de détails.
1. Choisissez l'onglet **Instantanés** pour afficher les instantanés disponibles.
1. Choisissez l'instantané à partir duquel vous souhaitez effectuer la restauration, puis choisissez **Restaurer à partir d'un instantané**.
1. Dans la boîte de dialogue **Restaurer à partir d'un instantané** :
+ Pour le **nom du snapshot**, vérifiez l'ID du snapshot sélectionné.
+ Pour **Snapshot Scope**, choisissez l'une des options suivantes :
+ **Tous les index de la collection** - Restaurez tous les index à partir de l'instantané
+ **Index spécifiques : sélectionnez les** index individuels à restaurer
+ Pour **Destination**, choisissez la collection vers laquelle vous souhaitez effectuer la restauration.
+ (Facultatif) Configurez les **paramètres de renommage** pour renommer les index restaurés :
+ **Ne pas renommer** : conserver les noms d'index d'origine
+ **Ajouter un préfixe aux noms d'index restaurés** - Ajoutez un préfixe pour éviter les conflits
+ **Renommer à l'aide d'une expression régulière** - Utiliser des modèles de renommage avancés
+ (Facultatif) Configurez les paramètres de **notification** pour être averti lorsque la restauration est terminée ou qu'elle rencontre des erreurs.
1. Choisissez **Enregistrer** pour démarrer l'opération de restauration.
------
#### [ OpenSearch API ]
1. Exécutez la commande suivante pour identifier le snapshot approprié.
```
GET /_snapshot/aoss-automated/_all
```
Pour réduire la liste des instantanés, exécutez la commande suivante.
```
GET /_cat/snapshots/aoss-automated
```
1. Exécutez la commande suivante pour vérifier les détails du snapshot avant de le restaurer. Dans la commande, remplacez le *example* contenu par vos informations spécifiques.
```
GET _snapshot/aoss-automated/snapshot-ExampleSnapshotID1/
```
1. Exécutez la commande suivante pour effectuer une restauration à partir d'un instantané spécifique.
```
POST /_snapshot/aoss-automated/snapshot-ID/_restore
```
Vous pouvez personnaliser l'opération de restauration en incluant un corps de demande. Voici un exemple :
```
POST /_snapshot/aoss-automated/snapshot-ExampleSnapshotID1-5e01-4423-9833Example/_restore
{
"indices": "opensearch-dashboards*,my-index*",
"ignore_unavailable": true,
"include_global_state": false,
"include_aliases": false,
"rename_pattern": "opensearch-dashboards(.+)",
"rename_replacement": "restored-opensearch-dashboards$1"
}
```
1. Exécutez la commande suivante pour voir la progression de la restauration.
```
GET /_cat/recovery
```
------
**Note**
Lorsque vous restaurez un instantané à l'aide d'une commande incluant un corps de requête, vous pouvez utiliser plusieurs paramètres pour contrôler le comportement de restauration. Le `indices` paramètre indique les indices à restaurer et prend en charge les modèles de caractères génériques. Configurez `ignore_unavailable` pour poursuivre l'opération de restauration même s'il manque un index dans le cliché. `include_global_state`À utiliser pour déterminer s'il faut restaurer l'état du cluster et `include_aliases` pour contrôler s'il faut restaurer les alias associés. Les `rename_replacement` paramètres `rename_pattern` et renomment les index lors de l'opération de restauration.
# Support du codec Zstandard dans Amazon Serverless OpenSearch
Les codecs d'index déterminent comment les champs stockés d'un index sont compressés et stockés sur disque et dans S3. Le codec d'index est contrôlé par le `index.codec` paramètre statique qui spécifie l'algorithme de compression. Ce paramètre a un impact à la fois sur la taille de la partition d'index et sur les performances de fonctionnement de l'index.
Par défaut, les index dans OpenSearch Serverless utilisent le codec par défaut avec l' LZ4 algorithme de compression. OpenSearch Serverless prend également en charge `zstd` et `zstd_no_dict` codecs avec des niveaux de compression configurables de 1 à 6.
**Important**
Comme il `index.codec` s'agit d'un paramètre statique, il ne peut pas être modifié après la création de l'index.
Pour plus de détails, consultez la documentation relative aux [codecs d'OpenSearch index](https://opensearch.org/docs/latest/im-plugin/index-codecs/).
## Création d'un index avec le codec ZSTD
Vous pouvez spécifier le codec ZSTD lors de la création de l'index à l'aide du paramètre : `index.codec`
```
PUT /your_index
{
"settings": {
"index.codec": "zstd"
}
}
```
## Niveaux de compression
Les codecs ZSTD prennent en charge les niveaux de compression optionnels via le `index.codec.compression_level` paramètre, en acceptant les entiers compris dans la plage [1, 6]. Des niveaux de compression plus élevés se traduisent par de meilleurs taux de compression (stockage réduit) mais des vitesses de compression et de décompression plus lentes. Le niveau de compression par défaut est le niveau 3.
```
PUT /your_index
{
"settings": {
"index.codec": "zstd",
"index.codec.compression_level": 2
}
}
```
## Analyse comparative des performances
Sur la base de tests de référence réalisés avec le jeu de données nyc\$1taxi, la compression ZSTD a permis d'obtenir une compression supérieure de 26 à 32 % par rapport à la valeur de référence pour différentes combinaisons de niveaux de compression et de niveaux de `zstd` compression. `zstd_no_dict`
| Métrique | ZSTD L1 | ZSTD L6 | ZSTD\$1NO\$1DICT L1 | ZSTD\$1NO\$1DICT P6 |
| --- | --- | --- | --- | --- |
| Réduction de la taille de l'index | 28,10 % | 32 % | 26,90 % | 28,70 % |
| Modification du débit d'indexation | -0,50 % | -23,80 % | -0,50 % | -5,30 % |
| Amélioration de la latence de Match-all Query p90 | -16,40 % | 29,50 % | -16,40 % | 23,40 % |
| Amélioration de la latence de Range Query p90 | 90,90 % | 92,40 % | -282,90 % | 92,50 % |
| Distance, quantité, p90, amélioration de la latence Agg | 2 % | 24,70 % | 2 % | 13,80 % |
Pour plus de détails, consultez le [AWS OpenSearch blog](https://aws.amazon.com/blogs/big-data/optimize-storage-costs-in-amazon-opensearch-service-using-zstandard-compression/).
# Économisez de l'espace de stockage en utilisant une source dérivée
Par défaut, OpenSearch Serverless stocke chaque document ingéré dans le `_source` champ, qui contient le corps du document JSON d'origine, et indexe les champs individuels pour la recherche. Bien que le `_source` champ ne soit pas consultable, il est conservé afin que le document complet puisse être renvoyé lors de l'exécution de requêtes de récupération, telles que get et search. Lorsque la source dérivée est activée, OpenSearch Serverless ignore le stockage du `_source` champ et le reconstruit dynamiquement à la demande, par exemple lors des opérations de recherche, de get, de mget, de réindexation ou de mise à jour. L'utilisation du paramètre de source dérivé peut réduire l'utilisation du stockage jusqu'à 50 %.
## Configuration
Pour configurer la source dérivée pour votre index, créez l'index à l'aide du `index.derived_source.enabled` paramètre :
```
PUT my-index1
{
"settings": {
"index": {
"derived_source": {
"enabled": true
}
}
}
}
```
## Considérations importantes
+ Seuls certains types de champs sont pris en charge. Pour obtenir la liste des champs pris en charge et des limites, consultez la [OpenSearch documentation](https://docs.opensearch.org/latest/mappings/metadata-fields/source/#supported-fields-and-parameters). Si vous créez un index avec une source dérivée et un champ non pris en charge, la création de l'index échouera. Si vous tentez d'ingérer un document dont le champ n'est pas pris en charge dans un index dérivé activé par la source, l'ingestion échouera. Utilisez cette fonctionnalité uniquement lorsque vous connaissez les types de champs qui seront ajoutés à votre index.
+ `index.derived_source.enabled`Il s'agit d'un paramètre statique. Cela ne peut pas être modifié une fois l'index créé.
## Limitations relatives aux réponses aux requêtes
Lorsque la source dérivée est activée, elle impose certaines limites quant à la manière dont les réponses aux requêtes sont générées et renvoyées.
+ Les champs de date dont plusieurs formats sont spécifiés utilisent toujours le premier format de la liste pour tous les documents demandés, quel que soit le format ingéré d'origine.
+ Les valeurs des géopoints sont renvoyées dans un `{"lat": lat_val, "lon": lon_val}` format fixe et peuvent perdre en précision.
+ Les tableaux à valeurs multiples peuvent être triés et les champs de mots clés peuvent être dédupliqués.
Pour plus de détails, consultez le [OpenSearch blog](https://opensearch.org/blog/save-up-to-2x-on-storage-with-derived-source/).
## Analyse comparative des performances
Sur la base de tests de référence avec le jeu de données nyc\$1taxi, la source dérivée a obtenu une réduction de 58 % de la taille de l'indice par rapport à la valeur de référence.
| Métrique | Source dérivée |
| --- | --- |
| Réduction de la taille de l'index | 58,3 % |
| Modification du débit d'indexation | 3,7 % |
| Indexation du changement de latence (p90) | 6,9 % |
| Amélioration de la latence de Match-all Query p90 | 19 % |
| Amélioration de la latence de Range Query p90 | -18,8 % |
| Distance, quantité, p90, amélioration de la latence Agg | -7,3 % |
Pour plus de détails, consultez le [OpenSearch blog](https://opensearch.org/blog/save-up-to-2x-on-storage-with-derived-source/).
# Groupes de collecte Amazon OpenSearch Serverless
Dans Amazon OpenSearch Serverless, les *groupes de collecte* organisent plusieurs collections et permettent le partage des ressources informatiques entre les collections dotées de différentes clés KMS. Ce modèle de calcul partagé réduit les coûts en éliminant le besoin d'unités de OpenSearch calcul distinctes (OCUs) pour chaque clé KMS.
Chaque collection OpenSearch Serverless que vous créez est protégée par le chiffrement des données au repos utilisé AWS KMS pour stocker et gérer vos clés de chiffrement. Les collections d'un même groupe de collecte partagent les ressources informatiques et l'espace mémoire OCU, même lorsqu'elles utilisent des clés KMS différentes pour le chiffrement.
Les groupes de collecte fournissent une isolation pour répondre aux exigences de sécurité et de performance. Vous pouvez regrouper les collections avec la même clé KMS dans un seul groupe de collecte pour l'isolation de sécurité, ou combiner des collections avec différentes clés KMS dans le même groupe pour optimiser les coûts. Cette flexibilité vous permet de trouver un équilibre entre les exigences de sécurité et l'efficacité des ressources.
Lorsque vous ajoutez une collection à un groupe de collections, OpenSearch Serverless l'affecte aux ressources informatiques partagées du groupe. Le système gère automatiquement la répartition des charges de travail entre ces ressources tout en préservant la sécurité en chiffrant les données de chaque collection avec la clé KMS qui lui est attribuée. Les contrôles d'accès continuent de s'appliquer au niveau de la collecte, et les ressources informatiques partagées accèdent à plusieurs clés KMS selon les besoins pour servir les collections du groupe.
Vous contrôlez l'allocation des ressources en définissant des limites d'OCU minimales et maximales au niveau du groupe de collecte. Ces limites s'appliquent à toutes les collections du groupe et vous aident à gérer les coûts tout en garantissant des performances constantes.
Par défaut, il existe un quota de service (limite) pour le nombre de collections dans un groupe de collections, le nombre d'index dans une collection et le nombre de collections OCUs dans un groupe de collections. Pour plus d'informations, consultez la section [Quotas OpenSearch sans serveur](https://docs.aws.amazon.com/general/latest/gr/opensearch-service.html#opensearch-limits-serverless).
## Concepts clés
Groupe de collection
AWS Ressource qui sert de conteneur pour une ou plusieurs collections. Chaque groupe de collecte possède un identifiant unique et peut avoir ses propres limites de capacité et paramètres de configuration.
Calcul partagé
Les collections d'un même groupe de collections partagent le même ensemble de clés KMS OCUs, quelles que soient les clés KMS qu'elles utilisent. Ce partage réduit les coûts en éliminant le besoin de ressources de calcul distinctes pour chaque clé KMS.
Limites de capacité
Vous pouvez définir des limites d'OCU minimales et maximales pour les opérations d'indexation et de recherche au niveau du groupe de collections. Ces limites permettent de contrôler les coûts et de garantir des performances constantes.
# Limites de capacité des groupes de collecte
Les groupes de collecte fournissent un contrôle granulaire de l'allocation des ressources grâce à des limites d'OCU minimales et maximales. Ces limites s'appliquent à toutes les collections du groupe et fonctionnent indépendamment des paramètres de capacité au niveau du compte.
Par défaut, il existe un quota de service (limite) pour le nombre de collections dans un groupe de collections, le nombre d'index dans une collection et le nombre de collections OCUs dans un groupe de collections. Pour plus d'informations, consultez la section [Quotas OpenSearch sans serveur](https://docs.aws.amazon.com/general/latest/gr/opensearch-service.html#opensearch-limits-serverless).
## Comprendre les limites de capacité des groupes de collecte
Vous pouvez configurer des limites d'OCU minimales et maximales pour les opérations d'indexation et de recherche au niveau du groupe de collection. Ces limites contrôlent la manière dont OpenSearch Serverless adapte les ressources pour les collections du groupe :
+ **OCU minimal** : nombre minimal d' OCUsOCU conservés par OpenSearch Serverless pour le groupe de collecte, garantissant ainsi des performances de base cohérentes.
+ Si la charge de travail nécessite moins d'OCU que la valeur minimale spécifiée, OpenSearch Serverless maintiendra toujours la valeur minimale spécifiée d'OCU et la facturation en tiendra compte.
+ Si la charge de travail nécessite un nombre d'OCU supérieur à la valeur minimale spécifiée, OpenSearch Serverless maintiendra le niveau d'OCU requis pour la charge de travail et la facturation reflétera l'utilisation plus élevée des OCU.
+ **OCU maximal** : le nombre maximum d'OCU OCUs que OpenSearch Serverless peut atteindre pour le groupe de collecte, ce qui vous permet de contrôler les coûts.
Les limites de capacité des groupes de collecte sont dissociées des limites au niveau du compte. Les paramètres d'OCU maximum au niveau du compte s'appliquent uniquement aux collections qui ne sont associées à aucun groupe de collections, tandis que les paramètres d'OCU maximum du groupe de collections s'appliquent aux collections au sein de ce groupe spécifique.
## Valeurs limites de capacité valides
Lorsque vous définissez des limites d'OCU minimales et maximales pour un groupe de collecte, vous ne pouvez utiliser que les valeurs de l'ensemble suivant : 1, 2, 4, 8, 16 et des multiples de 16 (tels que 32, 48, 64, 80, 96) jusqu'à un maximum de 1 OCUs 696.
Les limites d'OCU minimales et maximales sont facultatives lorsque vous créez un groupe de collections. Si vous ne spécifiez pas de limite maximale d'OCU, OpenSearch Serverless utilise une valeur par défaut de 96. OCUs
La limite minimale d'OCU doit être inférieure ou égale à la limite d'OCU maximale.
## Comprendre la relation entre les limites OCU au niveau du compte et du groupe de collecte
Lorsque vous planifiez votre capacité OpenSearch sans serveur, il est important de comprendre comment les limites d'OCU au niveau du compte et les limites d'OCU des groupes de collecte interagissent. La somme des paramètres d'OCU maximum pour tous les groupes de collecte et du paramètre d'OCU maximal au niveau du compte doit être inférieure ou égale à la limite de quota de service par compte. Pour les valeurs limites actuelles, consultez la section [Quotas OpenSearch sans serveur](https://docs.aws.amazon.com/general/latest/gr/opensearch-service.html#opensearch-limits-serverless).
**Note**
Les paramètres OCU maximaux au niveau du compte s'appliquent uniquement aux collections qui ne sont associées à aucun groupe de collections. Les collections au sein des groupes de collecte sont régies par leurs limites de groupe de collecte respectives, et non par les limites au niveau du compte.
Cette contrainte s'applique à la fois à l'indexation et à la recherche OCUs indépendamment. Par exemple, si vous configurez des paramètres au niveau du compte et des groupes de collecte, vous devez vous assurer que le total ne dépasse pas la limite de quota de service pour l'indexation OCUs et ne dépasse pas séparément la limite de quota de service pour la recherche. OCUs En outre, vous pouvez créer un maximum de 300 groupes de collecte par compte.
**Exemple : capacité de planification avec des limites au niveau des comptes et des groupes de collecte**
Si vous définissez l'OCU de recherche maximale au niveau du compte sur 500 et que la limite de quota de service est de 1 700 :
+ Et créez 2 groupes de collection, la somme de l'OCU maximum pour les 2 groupes de collecte ne doit pas dépasser 1 200 (1 700 - 500)
+ Vous pouvez laisser chaque groupe de collecte à l'OCU maximum par défaut de 96 (96 \$1 96 \$1 500 = 692), ce qui laisse une marge de manœuvre pour une croissance future
+ Vous pouvez également augmenter le maximum de chaque groupe de collecte à 600 (600 \$1 600 \$1 500 = 1 700), en utilisant la capacité maximale autorisée par le quota de service
Cette relation est essentielle pour la planification des capacités. Avant de créer de nouveaux groupes de collecte ou d'augmenter les limites maximales d'OCU, vérifiez que votre allocation totale ne dépasse pas la limite de quota de service. Si vous atteignez cette limite, vous devez soit réduire les paramètres d'OCU maximaux des groupes de collecte existants, soit diminuer les paramètres d'OCU maximaux au niveau de votre compte pour faire de la place pour de nouvelles allocations.
## Configuration des limites de capacité
Vous pouvez définir des limites de capacité lorsque vous créez un groupe de collecte ou les mettre à jour ultérieurement. Pour configurer les limites de capacité à l'aide de AWS CLI, utilisez les [UpdateCollectionGroup](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UpdateCollectionGroup.html)commandes [CreateCollectionGroup](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateCollectionGroup.html)ou :
```
aws opensearchserverless create-collection-group \
--name my-collection-group \
--capacity-limits maxIndexingCapacityInOCU=32,maxSearchCapacityInOCU=32,minIndexingCapacityInOCU=4,minSearchCapacityInOCU=4
```
Pour mettre à jour les limites de capacité d'un groupe de collecte existant :
```
aws opensearchserverless update-collection-group \
--id abcdef123456 \
--capacity-limits maxIndexingCapacityInOCU=48,maxSearchCapacityInOCU=48,minIndexingCapacityInOCU=8,minSearchCapacityInOCU=8
```
## Surveillance de la capacité des groupes de collecte
OpenSearch Serverless émet les métriques Amazon CloudWatch Logs suivantes à intervalles d'une minute pour vous aider à surveiller l'utilisation des OCU et les limites de capacité au niveau du groupe de collecte :
+ `IndexingOCU`— Le nombre d'indexages OCUs actuellement utilisés par le groupe de collection.
+ `SearchOCU`— Le nombre de recherches OCUs actuellement utilisées par le groupe de collection.
OpenSearch Serverless émet également des métriques OCU au niveau du compte pour les collections qui ne sont associées à aucun groupe de collecte. Vous pouvez agréger ces statistiques CloudWatch pour visualiser la somme de OCUs tous les groupes de collections et des collections au niveau du compte.
Configurez des alarmes pour vous avertir lorsque votre groupe de collecte approche de ses limites de capacité afin de pouvoir ajuster les paramètres selon vos besoins. Pour plus d'informations sur les métriques OpenSearch sans serveur, consultez[Surveillance d'Amazon OpenSearch Serverless](serverless-monitoring.md).
## Comment les limites de capacité sont appliquées
OpenSearch Serverless applique les limites de capacité des groupes de collecte lors des opérations de dimensionnement. Lorsque vos collections ont besoin de ressources supplémentaires, OpenSearch Serverless s'adapte jusqu'à la limite maximale d'OCU. Lorsque la demande diminue, OpenSearch Serverless réduit sa capacité mais maintient au moins la limite minimale d'OCU afin de garantir des performances constantes.
Les limites de capacité ne sont appliquées que lorsque le groupe de collecte contient au moins une collection. Les groupes de collecte vides ne consomment OCUs ni n'appliquent de limites de capacité.
Si une opération de dimensionnement dépasse la limite maximale d'OCU ou enfreint les exigences d'OCU minimales, OpenSearch Serverless rejette l'opération pour maintenir la conformité avec les limites que vous avez configurées.
# Chiffrement et clés KMS dans les groupes de collecte
Chaque collection OpenSearch Serverless que vous créez est protégée par le chiffrement des données au repos utilisé AWS KMS pour stocker et gérer vos clés de chiffrement. Lorsque vous travaillez avec des groupes de collecte, vous disposez d'une certaine flexibilité dans la manière dont vous spécifiez la clé KMS pour vos collections.
Vous pouvez fournir la clé KMS associée à une collection de deux manières :
+ **Dans la CreateCollection demande** — Spécifiez la clé KMS directement lorsque vous créez la collection à l'aide du `encryption-config` paramètre.
+ **Dans les politiques de sécurité** : définissez l'association de clés KMS dans une politique de sécurité de chiffrement.
Lorsque vous spécifiez une clé KMS aux deux emplacements, la clé KMS fournie dans la CreateCollection demande a priorité sur la configuration de la politique de sécurité.
Cette flexibilité simplifie la gestion des collections à grande échelle, en particulier lorsque vous devez créer plusieurs collections avec des clés KMS uniques. Au lieu de créer et de gérer des milliers de politiques de chiffrement, vous pouvez spécifier la clé KMS directement lors de la création de la collection.
## Partage OCUs entre différentes clés KMS
Les groupes de collections permettent de partager les ressources de calcul entre les collections dotées de différentes clés KMS. Les collections d'un même groupe de collections partagent l'espace mémoire OCU, quelles que soient leurs clés de chiffrement. Ce modèle de calcul partagé réduit les coûts en éliminant le besoin d'une clé KMS distincte OCUs pour chaque clé KMS.
Les groupes de collecte fournissent une isolation pour répondre aux exigences de sécurité et de performance. Vous pouvez regrouper les collections avec la même clé KMS dans un seul groupe de collecte pour l'isolation de sécurité, ou combiner des collections avec différentes clés KMS dans le même groupe pour optimiser les coûts. Cette flexibilité vous permet de trouver un équilibre entre les exigences de sécurité et l'efficacité des ressources.
Le système assure la sécurité en chiffrant les données de chaque collection avec sa clé KMS désignée. Les contrôles d'accès continuent de s'appliquer au niveau de la collecte, et les ressources informatiques partagées accèdent à plusieurs clés KMS selon les besoins pour servir les collections du groupe.
## Autorisations KMS requises
Lorsque vous spécifiez une clé KMS dans la CreateCollection demande, vous avez besoin des autorisations supplémentaires suivantes :
+ `kms:DescribeKey`— Permet à OpenSearch Serverless de récupérer des informations sur la clé KMS.
+ `kms:CreateGrant`— Permet à OpenSearch Serverless de créer une autorisation pour la clé KMS afin de permettre les opérations de chiffrement.
Ces autorisations ne sont pas requises lors de l'utilisation de clés AWS détenues.
# Création de groupes de collections
Cette rubrique explique comment créer, configurer et gérer des groupes de collecte dans Amazon OpenSearch Serverless. Utilisez des groupes de collecte pour organiser les collections et partager les ressources informatiques afin d'optimiser les coûts. Définissez des limites d'OCU minimales et maximales au niveau du groupe de collecte afin de contrôler les performances et les dépenses.
## Création d'un groupe de collection
Utilisez les procédures suivantes pour créer un nouveau groupe de collecte et configurer ses paramètres. Créez un groupe de collecte à l'aide de la console OpenSearch Serverless ou du AWS SDKs . AWS CLI Lorsque vous créez un groupe de collecte, vous spécifiez des limites de capacité et d'autres options de configuration.
------
#### [ Console ]
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).
1. Dans le volet de navigation de gauche, choisissez **Serverless**, puis choisissez **Collection groups**
1. Choisissez **Créer un groupe de collection**.
1. Dans **Nom du groupe de collection**, entrez le nom de votre groupe de collection. Le nom doit comporter de 3 à 32 caractères, commencer par une lettre minuscule et ne contenir que des lettres minuscules, des chiffres et des traits d'union.
1. (Facultatif) **Dans Description**, entrez une description pour votre groupe de collecte.
1. Dans la section **Gestion des capacités**, configurez les limites de l'OCU :
+ **Capacité d'indexation maximale** : nombre maximal d'indexation OCUs que les collections de ce groupe peuvent atteindre.
+ **Capacité de recherche maximale** : nombre maximal de recherches OCUs que les collections de ce groupe peuvent atteindre.
+ **Capacité d'indexation minimale** : nombre minimal d'indexages OCUs à maintenir pour des performances constantes.
+ **Capacité de recherche minimale** : nombre minimal de recherches OCUs à maintenir pour des performances constantes.
1. (Facultatif) Dans la section **Balises**, ajoutez des balises pour aider à organiser et à identifier votre groupe de collection.
1. Choisissez **Créer un groupe de collection**.
------
#### [ AWS CLI ]
+ Utilisez la [create-collection-group](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/create-collection-group.html)commande pour créer un nouveau groupe de collection. Dans la commande, remplacez le *example* contenu par vos propres informations spécifiques.
```
aws opensearchserverless create-collection-group \
--name my-collection-group \
--description "Collection group for production workloads" \
--capacity-limits maxIndexingCapacityInOCU=20,maxSearchCapacityInOCU=20,minIndexingCapacityInOCU=2,minSearchCapacityInOCU=2 \
--tags key=Environment,value=Production key=Team,value=DataEngineering
```
La commande renvoie des informations sur le groupe de collection créé, notamment son identifiant unique et son ARN.
------
## Ajouter une nouvelle collection à un groupe de collections
Lorsque vous créez une nouvelle collection, spécifiez un nom de groupe de collection existant auquel associer la collection. Utilisez les procédures suivantes pour ajouter une nouvelle collection à un groupe de collections.
------
#### [ Console ]
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).
1. **Dans le volet de navigation de gauche, choisissez **Serverless**, puis Collections**
1. Choisissez **Create collection** (Créer une collection).
1. Dans **Nom de la collection**, entrez le nom de votre collection. Le nom doit comporter de 3 à 28 caractères, commencer par une lettre minuscule et ne contenir que des lettres minuscules, des chiffres et des traits d'union.
1. (Facultatif) **Dans Description**, entrez une description pour votre collection.
1. Dans la section **Groupe de collections**, sélectionnez le groupe de collections auquel vous souhaitez attribuer la collection. Une collection ne peut appartenir qu'à un seul groupe de collections à la fois.
(Facultatif) Vous pouvez également choisir de **créer un nouveau groupe**. Cela vous dirigera vers le flux de travail de **création d'un groupe de collection**. Après avoir créé le groupe de collections, revenez à l'étape 1 de cette procédure pour commencer à créer votre nouvelle collection.
1. Poursuivez le flux de travail pour créer la collection.
**Important**
Ne quittez pas le flux de travail de **création de collection**. Cela arrêtera la configuration de la collecte. La page des **détails de la collection** apparaît une fois la configuration terminée.
------
#### [ AWS CLI ]
+ Utilisez la commande [create-collection](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/create-collection.html) pour créer une nouvelle collection et l'ajouter à un groupe de collections existant. Dans la commande, remplacez le *example* contenu par vos propres informations spécifiques.
```
aws opensearchserverless create-collection \
--name my-collection \
--type SEARCH \
--collection-group-name my-collection-group \
--description "Collection for search workloads"
```
------
# Gérer les groupes de collecte Amazon OpenSearch Serverless
Après avoir créé des groupes de collecte Amazon OpenSearch Serverless, vous pouvez modifier leurs paramètres en fonction de vos besoins. Utilisez ces opérations de gestion pour mettre à jour les limites de capacité et consulter les détails des groupes de collecte. Ces modifications vous aident à optimiser l'allocation des ressources et à maintenir une organisation efficace de vos collections.
## Afficher les groupes de collections
Affichez vos groupes de collecte OpenSearch sans serveur pour passer en revue leurs configurations, les collections associées et leur statut actuel.
------
#### [ Console ]
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).
1. **Dans le volet de navigation de gauche, choisissez **Serverless**, puis Collections**
1. Choisissez l'**onglet Groupes de collections**. Les groupes de collecte de votre compte sont affichés.
1. Choisissez le **nom** d'un groupe de collections pour afficher ses détails.
------
#### [ AWS CLI ]
+ Utilisez la [list-collection-groups](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/list-collection-groups.html)commande pour répertorier tous les groupes de collecte de votre compte. Utilisez la [batch-get-collection-group](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/batch-get-collection-group.html)commande pour afficher les détails relatifs à des groupes de collecte spécifiques. Dans les commandes suivantes, remplacez le *example* contenu par vos propres informations spécifiques.
Pour répertorier tous les groupes de collections :
```
aws opensearchserverless list-collection-groups
```
Pour obtenir des informations sur des groupes de collecte spécifiques :
```
aws opensearchserverless batch-get-collection-group \
--names my-collection-group another-group
```
------
## Mettre à jour les paramètres du groupe de collecte
Mettez à jour les paramètres de votre groupe de collecte OpenSearch sans serveur pour modifier les configurations telles que les limites de capacité et la description.
------
#### [ Console ]
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).
1. **Dans le volet de navigation de gauche, choisissez **Serverless**, puis Collections**
1. Choisissez l'**onglet Groupes de collections**. Les groupes de collecte de votre compte sont affichés.
1. Choisissez le **nom** d'un groupe de collections pour afficher ses détails.
1. Dans **Détails du groupe de collections**, choisissez **Modifier**.
1. Apportez les modifications souhaitées, puis choisissez **Enregistrer**.
------
#### [ AWS CLI ]
+ Utilisez la [update-collection-group](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/update-collection-group.html)commande pour mettre à jour la description et les limites de capacité d'un groupe de collecte existant. Dans la commande suivante, remplacez le *example* contenu par vos propres informations.
```
aws opensearchserverless update-collection-group \
--id abcdef123456 \
--description "Updated description for production workloads" \
--capacity-limits maxIndexingCapacityInOCU=30,maxSearchCapacityInOCU=30,minIndexingCapacityInOCU=4,minSearchCapacityInOCU=4
```
------
Les modifications apportées aux limites de capacité prennent effet immédiatement et peuvent avoir un impact sur le comportement de dimensionnement des collections du groupe.
## Supprimer des groupes de collections
Avant de pouvoir supprimer un groupe de collections, vous devez d'abord supprimer toutes les collections du groupe. Vous ne pouvez pas supprimer un groupe de collections qui contient des collections.
------
#### [ Console ]
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).
1. **Dans le volet de navigation de gauche, choisissez **Serverless**, puis Collections**
1. Choisissez l'**onglet Groupes de collections**. Les groupes de collecte de votre compte sont affichés.
1. Choisissez le **nom** du groupe de collection que vous souhaitez supprimer.
**Important**
Supprimez toutes les collections du groupe de collections en mettant à jour chaque collection pour supprimer l'association de groupes de collections ou en les déplaçant vers d'autres groupes de collections.
1. En haut de la page, sélectionnez **Delete** (Supprimer).
1. Confirmez la suppression, puis choisissez **Supprimer**.
------
#### [ AWS CLI ]
+ Utilisez la [delete-collection-group](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/delete-collection-group.html)commande pour supprimer un groupe de collection.
**Important**
Supprimez toutes les collections du groupe de collections en mettant à jour chaque collection pour supprimer l'association de groupes de collections ou en les déplaçant vers d'autres groupes de collections.
Dans la commande suivante, remplacez le *example* contenu par vos propres informations.
Supprimez le groupe de collecte vide :
```
aws opensearchserverless delete-collection-group \
--id abcdef123456
```
------
# Gestion des limites de capacité pour Amazon OpenSearch Serverless
Avec Amazon OpenSearch Serverless, vous n'avez pas à gérer vous-même la capacité. OpenSearch Serverless adapte automatiquement la capacité de calcul de votre compte en fonction de la charge de travail actuelle. La capacité de calcul sans serveur est mesurée en *unités OpenSearch de calcul* (OCUs). Chaque OCU est une combinaison de 6 Gio de mémoire et du processeur virtuel (vCPU) correspondant et crée un transfert de données vers Amazon S3. Pour plus d'informations sur l'architecture découplée dans OpenSearch Serverless, consultez. [Comment ça marche](serverless-overview.md#serverless-process)
Lorsque vous créez votre première collection, OpenSearch Serverless instancie en OCUs fonction de vos paramètres de redondance. Par défaut, les répliques actives redondantes sont activées, ce qui en instancie quatre OCUs (deux pour l'indexation et deux pour la recherche). Cela garantit une haute disponibilité avec des nœuds de secours situés dans une autre zone de disponibilité.
Pour le développement et les tests, vous pouvez désactiver le paramètre **Activer la redondance** pour une collection. Cela supprime les répliques de secours et n'en utilise que deux OCUs (une pour l'indexation et une pour la recherche).
Ils existent OCUs toujours, même en l'absence d'indexation ou d'activité de recherche. Toutes les collections suivantes peuvent les partager OCUs, à l'exception des collections avec des AWS KMS clés uniques, qui instancient leur propre ensemble de. OCUs Toutes les collections associées à un groupe de collections peuvent partager le même ensemble de OCUs. Un seul type de collection (recherche, série chronologique ou recherche vectorielle) peut être inclus dans un seul groupe de collections. Pour de plus amples informations, veuillez consulter [Groupes de collecte Amazon OpenSearch Serverless](serverless-collection-groups.md).
OpenSearch Serverless s'adapte automatiquement et s'ajoute à OCUs mesure que votre utilisation de l'indexation et de la recherche augmente. Lorsque le trafic diminue, la capacité est réduite au minimum OCUs requis pour la taille de vos données.
Pour les recherches et les collections de séries chronologiques, le nombre de données OCUs requises en cas d'inactivité est proportionnel à la taille des données et au nombre d'index. Pour les collections de vecteurs, les exigences en matière d'OCU dépendent de la mémoire (RAM) pour stocker les graphes vectoriels et de l'espace disque pour stocker les index. Lorsqu'il n'est pas inactif, les exigences en matière d'OCU tiennent compte de ces deux facteurs.
Les collections vectorielles stockent les données d'index dans le stockage local OCU. Les limites de RAM OCU sont atteintes plus rapidement que les limites de disque, ce qui limite les collections de vecteurs par espace RAM.
Lorsque la redondance est activée, la capacité de l'OCU est réduite à un minimum de 1 OCU (0,5 OCU x 2) pour l'indexation et de 1 OCU (0,5 OCU x 2) pour la recherche. Lorsque vous désactivez la redondance, votre collection peut être réduite à 0,5 OCU pour l'indexation et à 0,5 OCU pour la recherche.
La mise à l'échelle prend également en compte le nombre de partitions nécessaires à votre collection ou à votre index. Chaque OCU prend en charge un nombre spécifié de partitions, et le nombre d'index doit être proportionnel au nombre de partitions. Le nombre total de bases OCUs requises correspond au maximum de vos besoins en matière de données, de mémoire et de partitions. Pour plus d'informations, consultez les [fonctionnalités de recherche économiques d'Amazon OpenSearch Serverless, à n'importe quelle échelle](https://aws.amazon.com/blogs/big-data/amazon-opensearch-serverless-cost-effective-search-capabilities-at-any-scale/), sur le *blog AWS Big Data*.
Pour les collections *de recherche* et *de recherche vectorielle*, toutes les données sont stockées sur des index actifs afin de garantir des temps de réponse rapides aux requêtes. Les collections de *séries chronologiques* utilisent une combinaison de stockage à chaud et à chaud, ce qui permet de conserver les données les plus récentes dans un stockage à chaud afin d'optimiser les temps de réponse aux requêtes pour les données les plus fréquemment consultées. Pour de plus amples informations, veuillez consulter [Choix d'un type de collection](serverless-overview.md#serverless-usecase).
**Note**
Une collection de recherche vectorielle ne peut pas être partagée OCUs avec des collections de *recherche* et de *séries chronologiques*, même si la collection de recherche vectorielle utilise la même clé KMS que les collections *de recherche* ou de *séries chronologiques*. Un nouvel ensemble de OCUs sera créé pour votre première collection de vecteurs. Les collections OCUs de vecteurs sont partagées entre les mêmes collections de clés KMS.
Pour gérer la capacité de vos collections et contrôler les coûts, vous pouvez spécifier la capacité maximale globale d'indexation et de recherche pour le compte courant et la région, et OpenSearch Serverless adapte automatiquement vos ressources de collecte en fonction de ces spécifications.
Étant donné que les capacités d'indexation et de recherche se mettent à l'échelle séparément, vous devez définir des limites au niveau du compte pour chacune :
+ **Capacité d'indexation maximale** — OpenSearch Serverless peut augmenter la capacité d'indexation jusqu'à ce nombre de. OCUs
+ **Capacité de recherche maximale** — OpenSearch Serverless peut augmenter la capacité de recherche jusqu'à ce nombre de OCUs.
**Note**
À l'heure actuelle, les paramètres de capacité ne s'appliquent qu'au niveau du compte. Vous ne pouvez pas configurer de limites de capacité par collection.
Votre objectif doit être de vous assurer que la capacité maximale est suffisamment élevée pour gérer les pics de charge de travail. En fonction de vos paramètres, OpenSearch Serverless augmente automatiquement le nombre de collections OCUs pour traiter la charge de travail d'indexation et de recherche.
**Topics**
+ [Configurer les paramètres de capacité](#serverless-scaling-configure)
+ [Limites de capacité maximale](#serverless-scaling-limits)
+ [Surveiller l'utilisation de la capacité](#serverless-scaling-monitoring)
## Configurer les paramètres de capacité
**Pour configurer les paramètres de capacité dans la console OpenSearch Serverless, développez **Serverless** dans le volet de navigation de gauche et sélectionnez Dashboard.** Spécifiez la capacité maximale d'indexation et de recherche sous **Capacity management** (Gestion de la capacité) :
![\[Capacity management dashboard showing indexing and search capacity graphs with 10 OCU limits.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/ServerlessCapacity.png)
Pour configurer la capacité à l'aide du AWS CLI, envoyez une [UpdateAccountSettings](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UpdateAccountSettings.html)demande :
```
aws opensearchserverless update-account-settings \
--capacity-limits '{ "maxIndexingCapacityInOCU": 8,"maxSearchCapacityInOCU": 9 }'
```
## Limites de capacité maximale
Le nombre maximum d'index qu'une collection peut contenir est de 1 000. Pour les trois types de collections, la capacité maximale par défaut de l'OCU est de 10 OCUs pour l'indexation et de 10 OCUs pour la recherche. La capacité OCU minimale autorisée pour un compte est de 1 OCU [0,5 OCU x 2] pour l'indexation et de 1 OCU [0,5 OCU x 2] pour la recherche. Pour toutes les collections, la capacité maximale autorisée est de 1 700 OCUs pour l'indexation et de 1 700 OCUs pour la recherche. Vous pouvez configurer le nombre d'OCU pour qu'il soit compris entre 2 et la capacité maximale autorisée, par multiples de 2.
Chaque OCU inclut suffisamment de stockage éphémère à chaud pour 120 GiB de données d'index. OpenSearch *Serverless prend en charge jusqu'à 1 TiB de données par index *dans* les collections de recherche *et de recherche vectorielle*, et 100 TiB de données chaudes par index dans une collection de séries chronologiques.* Pour les collections de séries chronologiques, vous pouvez toujours ingérer davantage de données, qui peuvent être stockées sous forme de données chaudes dans S3.
Pour obtenir la liste de tous les quotas, consultez la section [Quotas OpenSearch sans serveur](https://docs.aws.amazon.com/general/latest/gr/opensearch-service.html#opensearch-limits-serverless).
## Surveiller l'utilisation de la capacité
Vous pouvez surveiller `SearchOCU` les CloudWatch indicateurs `IndexingOCU` au niveau du compte pour comprendre l'évolution de vos collections. Nous vous recommandons de définir des alertes qui vous avertissent si votre compte se rapproche d'un seuil pour les métriques liées à la capacité, afin que vous puissiez ajuster vos paramètres de capacité en conséquence.
Vous pouvez également utiliser ces métriques pour déterminer si les paramètres de capacité maximale sont appropriés ou si vous devez les ajuster. Analysez ces métriques afin de concentrer vos efforts sur l'optimisation de l'efficacité de vos collections. Pour plus d'informations sur les métriques auxquelles OpenSearch Serverless envoie CloudWatch, consultez[Surveillance d'Amazon OpenSearch Serverless](serverless-monitoring.md).
# Ingestion de données dans des collections Amazon OpenSearch Serverless
Ces sections fournissent des informations sur les pipelines d'ingestion pris en charge pour l'ingestion de données dans les collections Amazon OpenSearch Serverless. Ils couvrent également certains des clients que vous pouvez utiliser pour interagir avec les opérations de l' OpenSearch API. Vos clients doivent être compatibles avec la version OpenSearch 2.x afin de pouvoir s'intégrer à OpenSearch Serverless.
**Topics**
+ [Autorisations minimales requises](#serverless-ingestion-permissions)
+ [OpenSearch Ingestion](#serverless-osis-ingestion)
+ [Fluent Bit](#serverless-fluentbit)
+ [Amazon Data Firehose](#serverless-kdf)
+ [Go](#serverless-go)
+ [Java](#serverless-java)
+ [JavaScript](#serverless-javascript)
+ [Logstash](#serverless-logstash)
+ [Python](#serverless-python)
+ [Ruby](#serverless-ruby)
+ [Signature des demandes HTTP avec d'autres clients](#serverless-signing)
## Autorisations minimales requises
Afin d'ingérer des données dans une collection OpenSearch sans serveur, le principal qui écrit les données doit disposer des autorisations minimales suivantes attribuées dans une politique d'[accès aux données](serverless-data-access.md) :
```
[
{
"Rules":[
{
"ResourceType":"index",
"Resource":[
"index/target-collection/logs"
],
"Permission":[
"aoss:CreateIndex",
"aoss:WriteDocument",
"aoss:UpdateIndex"
]
}
],
"Principal":[
"arn:aws:iam::123456789012:user/my-user"
]
}
]
```
Les autorisations peuvent être plus étendues si vous prévoyez d'écrire dans des index supplémentaires. Par exemple, plutôt que de spécifier un seul index cible, vous pouvez autoriser l'accès à tous les index (index/ *target-collection* /\$1) ou à un sous-ensemble d'index (index//). *target-collection* *logs\$1*
Pour une référence de toutes les opérations OpenSearch d'API disponibles et de leurs autorisations associées, consultez[Opérations et plug-ins pris en charge dans Amazon OpenSearch Serverless](serverless-genref.md).
## OpenSearch Ingestion
Plutôt que d'utiliser un client tiers pour envoyer des données directement à une collection OpenSearch sans serveur, vous pouvez utiliser Amazon OpenSearch Ingestion. Vous configurez vos producteurs de données pour qu'ils envoient des données à OpenSearch Ingestion, qui les fournit automatiquement à la collection que vous spécifiez. Vous pouvez également configurer OpenSearch Ingestion pour transformer vos données avant de les livrer. Pour de plus amples informations, veuillez consulter [Présentation d'Amazon OpenSearch Ingestion](ingestion.md).
Un pipeline d' OpenSearch ingestion a besoin d'une autorisation pour écrire dans une collection OpenSearch sans serveur configurée comme récepteur. Ces autorisations incluent la possibilité de décrire la collection et de lui envoyer des requêtes HTTP. Pour obtenir des instructions sur OpenSearch l'utilisation d'Ingestion pour ajouter des données à une collection, reportez-vous à[Autoriser les pipelines OpenSearch Amazon Ingestion à accéder aux collections](pipeline-collection-access.md).
Pour commencer à utiliser OpenSearch Ingestion, voir[Tutoriel : Ingestion de données dans une collection à l'aide d'Amazon OpenSearch Ingestion](osis-serverless-get-started.md).
## Fluent Bit
Vous pouvez utiliser l'[AWS image Fluent Bit](https://github.com/aws/aws-for-fluent-bit#public-images) et le [plugin OpenSearch de sortie](https://docs.fluentbit.io/manual/pipeline/outputs/opensearch) pour ingérer des données dans des collections OpenSearch sans serveur.
**Note**
Vous devez disposer de la version 2.30.0 ou ultérieure de l'image AWS for Fluent Bit pour pouvoir intégrer Serverless. OpenSearch
**Exemple de configuration** :
Cet exemple de section de sortie du fichier de configuration montre comment utiliser une collection OpenSearch Serverless comme destination. L'ajout important est le paramètre `AWS_Service_Name`, qui est `aoss`. `Host` est le point de terminaison de la collection.
```
[OUTPUT]
Name opensearch
Match *
Host collection-endpoint.us-west-2.aoss.amazonaws.com
Port 443
Index my_index
Trace_Error On
Trace_Output On
AWS_Auth On
AWS_Region
AWS_Service_Name aoss
tls On
Suppress_Type_Name On
```
## Amazon Data Firehose
Firehose prend en charge le mode OpenSearch Serverless comme destination de livraison. Pour obtenir des instructions sur l'envoi de données vers OpenSearch Serverless, consultez [Creating a Kinesis Data Firehose Delivery](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html) Stream [et OpenSearch Choose Serverless for Your Destination](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-opensearch-serverless) dans le manuel *Amazon* Data Firehose Developer Guide.
Le rôle IAM que vous fournissez à Firehose pour la livraison doit être spécifié dans une politique d'accès aux données avec `aoss:WriteDocument` l'autorisation minimale pour la collecte cible, et vous devez disposer d'un index préexistant auquel envoyer des données. Pour de plus amples informations, veuillez consulter [Autorisations minimales requises](#serverless-ingestion-permissions).
Avant d'envoyer des données vers OpenSearch Serverless, vous devrez peut-être effectuer des transformations sur les données. Pour en savoir plus sur l'utilisation des fonctions Lambda pour effectuer cette tâche, consultez [Transformation de données Amazon Kinesis Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/data-transformation.html) dans le même guide.
## Go
L'exemple de code suivant utilise le client [opensearch-go](https://github.com/opensearch-project/opensearch-go) pour Go afin d'établir une connexion sécurisée avec la collection OpenSearch Serverless spécifiée et de créer un index unique. Vous devez fournir des valeurs pour `region` et `host`.
```
package main
import (
"context"
"log"
"strings"
"github.com/aws/aws-sdk-go-v2/aws"
"github.com/aws/aws-sdk-go-v2/config"
opensearch "github.com/opensearch-project/opensearch-go/v2"
opensearchapi "github.com/opensearch-project/opensearch-go/v2/opensearchapi"
requestsigner "github.com/opensearch-project/opensearch-go/v2/signer/awsv2"
)
const endpoint = "" // serverless collection endpoint
func main() {
ctx := context.Background()
awsCfg, err := config.LoadDefaultConfig(ctx,
config.WithRegion(""),
config.WithCredentialsProvider(
getCredentialProvider("", "", ""),
),
)
if err != nil {
log.Fatal(err) // don't log.fatal in a production-ready app
}
// create an AWS request Signer and load AWS configuration using default config folder or env vars.
signer, err := requestsigner.NewSignerWithService(awsCfg, "aoss") // "aoss" for Amazon OpenSearch Serverless
if err != nil {
log.Fatal(err) // don't log.fatal in a production-ready app
}
// create an opensearch client and use the request-signer
client, err := opensearch.NewClient(opensearch.Config{
Addresses: []string{endpoint},
Signer: signer,
})
if err != nil {
log.Fatal("client creation err", err)
}
indexName := "go-test-index"
// define index mapping
mapping := strings.NewReader(`{
"settings": {
"index": {
"number_of_shards": 4
}
}
}`)
// create an index
createIndex := opensearchapi.IndicesCreateRequest{
Index: indexName,
Body: mapping,
}
createIndexResponse, err := createIndex.Do(context.Background(), client)
if err != nil {
log.Println("Error ", err.Error())
log.Println("failed to create index ", err)
log.Fatal("create response body read err", err)
}
log.Println(createIndexResponse)
// delete the index
deleteIndex := opensearchapi.IndicesDeleteRequest{
Index: []string{indexName},
}
deleteIndexResponse, err := deleteIndex.Do(context.Background(), client)
if err != nil {
log.Println("failed to delete index ", err)
log.Fatal("delete index response body read err", err)
}
log.Println("deleting index", deleteIndexResponse)
}
func getCredentialProvider(accessKey, secretAccessKey, token string) aws.CredentialsProviderFunc {
return func(ctx context.Context) (aws.Credentials, error) {
c := &aws.Credentials{
AccessKeyID: accessKey,
SecretAccessKey: secretAccessKey,
SessionToken: token,
}
return *c, nil
}
}
```
## Java
L'exemple de code suivant utilise le client [opensearch-java pour Java](https://search.maven.org/artifact/org.opensearch.client/opensearch-java) afin d'établir une connexion sécurisée avec la collection OpenSearch Serverless spécifiée et de créer un index unique. Vous devez fournir des valeurs pour `region` et `host`.
La différence importante par rapport aux *domaines OpenSearch * de service réside dans le nom du service (`aoss`au lieu de`es`).
```
// import OpenSearchClient to establish connection to OpenSearch Serverless collection
import org.opensearch.client.opensearch.OpenSearchClient;
SdkHttpClient httpClient = ApacheHttpClient.builder().build();
// create an opensearch client and use the request-signer
OpenSearchClient client = new OpenSearchClient(
new AwsSdk2Transport(
httpClient,
"...us-west-2.aoss.amazonaws.com", // serverless collection endpoint
"aoss" // signing service name
Region.US_WEST_2, // signing service region
AwsSdk2TransportOptions.builder().build()
)
);
String index = "sample-index";
// create an index
CreateIndexRequest createIndexRequest = new CreateIndexRequest.Builder().index(index).build();
CreateIndexResponse createIndexResponse = client.indices().create(createIndexRequest);
System.out.println("Create index reponse: " + createIndexResponse);
// delete the index
DeleteIndexRequest deleteIndexRequest = new DeleteIndexRequest.Builder().index(index).build();
DeleteIndexResponse deleteIndexResponse = client.indices().delete(deleteIndexRequest);
System.out.println("Delete index reponse: " + deleteIndexResponse);
httpClient.close();
```
L'exemple de code suivant établit à nouveau une connexion sécurisée, puis recherche un index.
```
import org.opensearch.client.opensearch.OpenSearchClient;
SdkHttpClient httpClient = ApacheHttpClient.builder().build();
OpenSearchClient client = new OpenSearchClient(
new AwsSdk2Transport(
httpClient,
"...us-west-2.aoss.amazonaws.com", // serverless collection endpoint
"aoss" // signing service name
Region.US_WEST_2, // signing service region
AwsSdk2TransportOptions.builder().build()
)
);
Response response = client.generic()
.execute(
Requests.builder()
.endpoint("/" + "users" + "/_search?typed_keys=true")
.method("GET")
.json("{"
+ " \"query\": {"
+ " \"match_all\": {}"
+ " }"
+ "}")
.build());
httpClient.close();
```
## JavaScript
L'exemple de code suivant utilise le client [opensearch-js](https://www.npmjs.com/package/@opensearch-project/opensearch) JavaScript pour établir une connexion sécurisée avec la collection OpenSearch Serverless spécifiée, créer un index unique, ajouter un document et supprimer l'index. Vous devez fournir des valeurs pour `node` et `region`.
La différence importante par rapport aux *domaines OpenSearch * de service réside dans le nom du service (`aoss`au lieu de`es`).
------
#### [ Version 3 ]
Cet exemple utilise [la version 3](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/) du SDK pour JavaScript le fichier Node.js.
```
const { defaultProvider } = require('@aws-sdk/credential-provider-node');
const { Client } = require('@opensearch-project/opensearch');
const { AwsSigv4Signer } = require('@opensearch-project/opensearch/aws');
async function main() {
// create an opensearch client and use the request-signer
const client = new Client({
...AwsSigv4Signer({
region: 'us-west-2',
service: 'aoss',
getCredentials: () => {
const credentialsProvider = defaultProvider();
return credentialsProvider();
},
}),
node: '' # // serverless collection endpoint
});
const index = 'movies';
// create index if it doesn't already exist
if (!(await client.indices.exists({ index })).body) {
console.log((await client.indices.create({ index })).body);
}
// add a document to the index
const document = { foo: 'bar' };
const response = await client.index({
id: '1',
index: index,
body: document,
});
console.log(response.body);
// delete the index
console.log((await client.indices.delete({ index })).body);
}
main();
```
------
#### [ Version 2 ]
Cet exemple utilise [la version 2](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/) du SDK pour JavaScript le fichier Node.js.
```
const AWS = require('aws-sdk');
const { Client } = require('@opensearch-project/opensearch');
const { AwsSigv4Signer } = require('@opensearch-project/opensearch/aws');
async function main() {
// create an opensearch client and use the request-signer
const client = new Client({
...AwsSigv4Signer({
region: 'us-west-2',
service: 'aoss',
getCredentials: () =>
new Promise((resolve, reject) => {
AWS.config.getCredentials((err, credentials) => {
if (err) {
reject(err);
} else {
resolve(credentials);
}
});
}),
}),
node: '' # // serverless collection endpoint
});
const index = 'movies';
// create index if it doesn't already exist
if (!(await client.indices.exists({ index })).body) {
console.log((await client.indices.create({
index
})).body);
}
// add a document to the index
const document = {
foo: 'bar'
};
const response = await client.index({
id: '1',
index: index,
body: document,
});
console.log(response.body);
// delete the index
console.log((await client.indices.delete({ index })).body);
}
main();
```
------
## Logstash
Vous pouvez utiliser le [ OpenSearch plugin Logstash](https://github.com/opensearch-project/logstash-output-opensearch) pour publier des journaux dans des collections OpenSearch Serverless.
**Pour utiliser Logstash pour envoyer des données vers Serverless OpenSearch**
1. Installez la version *2.0.0 ou ultérieure* du [logstash-output-opensearch](https://github.com/opensearch-project/logstash-output-opensearch)plugin à l'aide de Docker ou Linux.
------
#### [ Docker ]
[Docker héberge le logiciel Logstash OSS avec le plugin de OpenSearch sortie préinstallé : opensearchproject/ -output-plugin. logstash-oss-with-opensearch](https://hub.docker.com/r/opensearchproject/logstash-oss-with-opensearch-output-plugin/tags?page=1&ordering=last_updated&name=8.4.0) Vous pouvez extraire l'image comme n'importe quelle autre image :
```
docker pull opensearchproject/logstash-oss-with-opensearch-output-plugin:latest
```
------
#### [ Linux ]
Si vous ne l'avez pas déjà fait, [installez la dernière version de Logstash](https://www.elastic.co/guide/en/logstash/current/installing-logstash.html). Ensuite, installez la version 2.0.0 du plugin de sortie :
```
cd logstash-8.5.0/
bin/logstash-plugin install --version 2.0.0 logstash-output-opensearch
```
Si le plugin est déjà installé, mettez-le à jour vers la dernière version :
```
bin/logstash-plugin update logstash-output-opensearch
```
À partir de la version 2.0.0 du plugin, le AWS SDK utilise la version 3. Si vous utilisez une version de Logstash antérieure à la version 8.4.0, vous devez supprimer tous les AWS plugins préinstallés et installer le plugin : `logstash-integration-aws`
```
/usr/share/logstash/bin/logstash-plugin remove logstash-input-s3
/usr/share/logstash/bin/logstash-plugin remove logstash-input-sqs
/usr/share/logstash/bin/logstash-plugin remove logstash-output-s3
/usr/share/logstash/bin/logstash-plugin remove logstash-output-sns
/usr/share/logstash/bin/logstash-plugin remove logstash-output-sqs
/usr/share/logstash/bin/logstash-plugin remove logstash-output-cloudwatch
/usr/share/logstash/bin/logstash-plugin install --version 0.1.0.pre logstash-integration-aws
```
------
1. Pour que le plugin OpenSearch de sortie fonctionne avec OpenSearch Serverless, vous devez apporter les modifications suivantes à la section de `opensearch` sortie de logstash.conf :
+ Spécifiez `aoss` comme `service_name` sous `auth_type`.
+ Spécifiez le point de terminaison de votre collection pour `hosts`.
+ Ajoutez les paramètres `default_server_major_version` et `legacy_template`. Ces paramètres sont nécessaires pour que le plugin fonctionne avec OpenSearch Serverless.
```
output {
opensearch {
hosts => "collection-endpoint:443"
auth_type => {
...
service_name => 'aoss'
}
default_server_major_version => 2
legacy_template => false
}
}
```
Cet exemple de fichier de configuration prend ses entrées à partir des fichiers d'un compartiment S3 et les envoie à une collection OpenSearch Serverless :
```
input {
s3 {
bucket => "my-s3-bucket"
region => "us-east-1"
}
}
output {
opensearch {
ecs_compatibility => disabled
hosts => "https://my-collection-endpoint.us-east-1.aoss.amazonaws.com:443"
index => my-index
auth_type => {
type => 'aws_iam'
aws_access_key_id => 'your-access-key'
aws_secret_access_key => 'your-secret-key'
region => 'us-east-1'
service_name => 'aoss'
}
default_server_major_version => 2
legacy_template => false
}
}
```
1. Ensuite, lancez Logstash avec la nouvelle configuration pour tester le plugin :
```
bin/logstash -f config/test-plugin.conf
```
## Python
L'exemple de code suivant utilise le client [opensearch-py](https://pypi.org/project/opensearch-py/) pour Python afin d'établir une connexion sécurisée avec la collection OpenSearch Serverless spécifiée, de créer un index unique et d'effectuer une recherche dans cet index. Vous devez fournir des valeurs pour `region` et `host`.
La différence importante par rapport aux *domaines OpenSearch * de service réside dans le nom du service (`aoss`au lieu de`es`).
```
from opensearchpy import OpenSearch, RequestsHttpConnection, AWSV4SignerAuth
import boto3
host = '' # serverless collection endpoint, without https://
region = '' # e.g. us-east-1
service = 'aoss'
credentials = boto3.Session().get_credentials()
auth = AWSV4SignerAuth(credentials, region, service)
# create an opensearch client and use the request-signer
client = OpenSearch(
hosts=[{'host': host, 'port': 443}],
http_auth=auth,
use_ssl=True,
verify_certs=True,
connection_class=RequestsHttpConnection,
pool_maxsize=20,
)
# create an index
index_name = 'books-index'
create_response = client.indices.create(
index_name
)
print('\nCreating index:')
print(create_response)
# index a document
document = {
'title': 'The Green Mile',
'director': 'Stephen King',
'year': '1996'
}
response = client.index(
index = 'books-index',
body = document,
id = '1'
)
# delete the index
delete_response = client.indices.delete(
index_name
)
print('\nDeleting index:')
print(delete_response)
```
## Ruby
La `opensearch-aws-sigv4` gemme fournit un accès à OpenSearch Serverless, ainsi qu'à OpenSearch Service, prêt à l'emploi. Elle possède toutes les fonctions du client [opensearch-ruby](https://rubygems.org/gems/opensearch-ruby), car elle est une dépendance de cette gemme.
Lors de l'instanciation du signataire Sigv4, spécifiez `aoss` comme nom de service :
```
require 'opensearch-aws-sigv4'
require 'aws-sigv4'
signer = Aws::Sigv4::Signer.new(service: 'aoss',
region: 'us-west-2',
access_key_id: 'key_id',
secret_access_key: 'secret')
# create an opensearch client and use the request-signer
client = OpenSearch::Aws::Sigv4Client.new(
{ host: 'https://your.amz-opensearch-serverless.endpoint',
log: true },
signer)
# create an index
index = 'prime'
client.indices.create(index: index)
# insert data
client.index(index: index, id: '1', body: { name: 'Amazon Echo',
msrp: '5999',
year: 2011 })
# query the index
client.search(body: { query: { match: { name: 'Echo' } } })
# delete index entry
client.delete(index: index, id: '1')
# delete the index
client.indices.delete(index: index)
```
## Signature des demandes HTTP avec d'autres clients
Les exigences suivantes s'appliquent lors de [la signature de demandes](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) destinées à des collections OpenSearch sans serveur lorsque vous créez des requêtes HTTP avec d'autres clients.
+ Vous devez spécifier le nom du service sous la forme `aoss`.
+ L'en-tête `x-amz-content-sha256` est obligatoire pour toutes les requêtes AWS Signature Version 4. Il fournit un hachage de la charge utile de la requête. S'il existe une charge utile de demande, définissez la valeur sur le hachage cryptographique () de son algorithme de hachage sécurisé (SHA). SHA256 S'il n'existe aucune charge utile de requête, définissez la valeur sur `e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`, qui est le hachage d'une chaîne vide.
**Topics**
+ [Indexation avec cURL](#serverless-signing-curl)
+ [Indexation avec Postman](#serverless-signing-postman)
### Indexation avec cURL
L'exemple de demande suivant utilise la bibliothèque de demandes d'URL du client (cURL) pour envoyer un seul document vers un index nommé `movies-index` dans une collection :
```
curl -XPOST \
--user "$AWS_ACCESS_KEY_ID":"$AWS_SECRET_ACCESS_KEY" \
--aws-sigv4 "aws:amz:us-east-1:aoss" \
--header "x-amz-content-sha256: $REQUEST_PAYLOAD_SHA_HASH" \
--header "x-amz-security-token: $AWS_SESSION_TOKEN" \
"https://my-collection-endpoint.us-east-1.aoss.amazonaws.com/movies-index/_doc" \
-H "Content-Type: application/json" -d '{"title": "Shawshank Redemption"}'
```
### Indexation avec Postman
L'image suivante montre comment envoyer une demande à une collection à l'aide de Postman. Pour obtenir des instructions d'authentification, consultez le [flux de travail d'authentification Authentifier avec AWS signature dans Postman](https://learning.postman.com/docs/sending-requests/authorization/aws-signature/).
![\[JSON response showing creation of a "movies-index" with successful result and no shards.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/ServerlessPostman.png)
# Configurer le Machine Learning sur Amazon OpenSearch Serverless
## Machine Learning (apprentissage automatique)
Le Machine Learning (ML) fournit des fonctionnalités de ML sous la forme d'algorithmes ML et de modèles distants. Avec l'accès à ces modèles, vous pouvez exécuter plusieurs flux de travail d'IA tels que RAG ou la recherche sémantique. Le ML prend en charge l'expérimentation et le déploiement en production de cas d'utilisation de l'IA générative à l'aide des derniers modèles hébergés en externe que vous pouvez configurer à l'aide de connecteurs. Après avoir configuré un connecteur, vous devez le configurer sur un modèle, puis le déployer pour effectuer une prédiction.
## Connecteurs
Les connecteurs facilitent l'accès aux modèles hébergés sur des plateformes ML tierces. Ils servent de passerelle entre votre OpenSearch cluster et un modèle distant. Pour plus d’informations, consultez la documentation suivante :
+ [Création de connecteurs pour des plateformes ML tierces](https://docs.opensearch.org/latest/ml-commons-plugin/remote-models/connectors/) sur le site Web de *OpenSearch documentation*
+ [Connecteurs pour plateformes externes](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ml-external-connector.html)
+ [Connecteurs pour Services AWS](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ml-amazon-connector.html)
**Important**
Lorsque vous créez une politique de confiance, **ml.opensearchservice.amazonaws.com** ajoutez-la comme principe de OpenSearch service.
Ignorez les étapes de la page [Connecteurs](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ml-amazon-connector.html) qui indiquent comment configurer un domaine dans la politique.
Ajoutez l'`iam:PassRole`instruction à l'étape [Configurer les autorisations](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ml-amazon-connector.html#connector-sagemaker-prereq).
Ignorez l'étape **Cartographier le rôle ML** dans les OpenSearch tableaux de bord. La configuration du rôle principal n'est pas requise. Cela s'applique aux [connecteurs pour Services AWS](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ml-amazon-connector.html) plateformes externes et aux [connecteurs pour plateformes externes](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ml-external-connector.html).
Dans votre demande SigV4 adressée au point de terminaison de collecte, définissez le nom du service sur au **aoss** lieu de**es**.
## Modèles
Un modèle est la fonctionnalité de base utilisée dans les différents flux de travail d'IA. Généralement, vous associez le connecteur à un modèle pour effectuer une prédiction à l'aide du connecteur. Une fois qu'un modèle est déployé, vous pouvez exécuter une prédiction. Pour plus d'informations, voir [Enregistrer un modèle hébergé sur une plateforme tierce](https://docs.opensearch.org/latest/ml-commons-plugin/api/model-apis/register-model/#register-a-model-hosted-on-a-third-party-platform) sur le site Web de *OpenSearch documentation*.
**Note**
Les fonctionnalités du modèle ne sont pas toutes prises en charge sur OpenSearch Serverless, comme les modèles locaux. Pour de plus amples informations, veuillez consulter [Machine Learning APIs et fonctionnalités non pris en charge](serverless-machine-learning-unsupported-features.md).
## Configuration des autorisations pour le Machine Learning
La section suivante décrit les politiques d'accès aux données de collecte requises pour le Machine Learning (ML). Remplacez le *placeholder values* par vos informations spécifiques. Pour de plus amples informations, veuillez consulter [Autorisations de stratégies prises en charge](serverless-data-access.md#serverless-data-supported-permissions).
```
{
"Rules": [
{
"Resource": [
"model/collection_name/*"
],
"Permission": [
"aoss:DescribeMLResource",
"aoss:CreateMLResource",
"aoss:UpdateMLResource",
"aoss:DeleteMLResource",
"aoss:ExecuteMLResource"
],
"ResourceType": "model"
}
],
"Principal": [
"arn:aws:iam::account_id:role/role_name"
],
"Description": "ML full access policy for collection_name"
}
```
+ **AOSS:Describe MLResource** — Accorde l'autorisation de rechercher et d'interroger des connecteurs, des modèles et des groupes de modèles.
+ **AOSS:Create MLResource — Accorde** l'autorisation de créer des connecteurs, des modèles et des groupes de modèles.
+ **AOSS:Update MLResource — Accorde** l'autorisation de mettre à jour les connecteurs, les modèles et les groupes de modèles.
+ **aoss:Delete MLResource** — Accorde l'autorisation de supprimer des connecteurs, des modèles et des groupes de modèles.
+ **AOSS:Execute MLResource — Accorde** l'autorisation d'effectuer des prédictions sur les modèles.
# Machine Learning APIs et fonctionnalités non pris en charge
## Non pris en charge APIs
Le Machine Learning (ML) APIs suivant n'est pas pris en charge sur Amazon OpenSearch Serverless :
+ Fonctionnalité du modèle local
+ API Model Train
+ API de l'algorithme Model Predict
+ API Model Batch Predict
+ L'API des agents et ses outils correspondants
+ Serveur MCP APIs
+ Mémoire APIs
+ Contrôleur APIs
+ Exécuter l'API de l'algorithme
+ Profil ML AP
+ API de statistiques ML
Pour plus d'informations sur le ML APIs, consultez [ML APIs](https://docs.opensearch.org/latest/ml-commons-plugin/api/index/) sur le site Web de *OpenSearch documentation*.
## Fonctions non prises en charge
Les fonctionnalités ML suivantes ne sont pas prises en charge sur Amazon OpenSearch Serverless :
+ Agents et outils
+ Modèles locaux
+ Le processeur ML Inference intégré aux pipelines de recherche et d'ingestion
+ Processeur d'ingestion d'inférence ML
+ Processeur de réponse à la recherche d'inférence ML
+ Processeur de demandes de recherche d'inférence ML
Pour plus d'informations sur ces fonctionnalités, consultez la documentation suivante sur le site Web de *OpenSearch documentation* :
+ [Machine learning](https://docs.opensearch.org/latest/ml-commons-plugin)
+ [Processeur d'inférence ML](https://docs.opensearch.org/latest/ingest-pipelines/processors/ml-inference/)
+ [Pipelines de recherche](https://docs.opensearch.org/latest/search-plugins/search-pipelines/index/)
# Configuration de la recherche neuronale et de la recherche hybride sur OpenSearch Serverless
## Recherche neuronale
Amazon OpenSearch Serverless prend en charge la fonctionnalité de recherche neurale pour les opérations de recherche sémantique sur vos données. Neural Search utilise des modèles d'apprentissage automatique pour comprendre le sens sémantique et le contexte de vos requêtes, fournissant ainsi des résultats de recherche plus pertinents que les recherches traditionnelles basées sur des mots clés. Cette section explique comment configurer Neural Search en mode OpenSearch Serverless, notamment les autorisations requises, les processeurs pris en charge et les principales différences par rapport à l' OpenSearch implémentation standard.
Avec Neural Search, vous pouvez effectuer une recherche sémantique sur vos données, en tenant compte du sens sémantique pour comprendre l'intention de vos requêtes de recherche. Cette fonctionnalité est alimentée par les composants suivants :
+ Processeur de pipeline d'ingestion de texte
+ Requête neuronale
+ Requête neuronale clairsemée
## Recherche hybride
Avec la recherche hybride, vous pouvez améliorer la pertinence des recherches en combinant des fonctionnalités de recherche sémantique et de recherche par mots clés. Pour utiliser la recherche hybride, créez un pipeline de recherche qui traite les résultats de votre recherche et combine les scores des documents. Pour plus d'informations, consultez la section [Pipelines de recherche](https://docs.opensearch.org/latest/search-plugins/search-pipelines/index/) sur le site Web de *OpenSearch documentation*. Utilisez les composants suivants pour implémenter la recherche hybride :
+ Processeur de pipeline de recherche de normalisation
**Techniques de normalisation prises en charge**
+ `min_max`
+ `l2`
**Techniques de combinaison prises en charge**
+ `arithmetic_mean`
+ `geometric_mean`
+ `harmonic_mean`
Pour plus d'informations sur les techniques de normalisation et de combinaison, consultez la section [Champs du corps de la demande](https://docs.opensearch.org/latest/search-plugins/search-pipelines/normalization-processor/#request-body-fields) sur le site Web de *OpenSearchdocumentation*.
+ Requête hybride
## Requêtes neuronales et hybrides
Par défaut, OpenSearch calcule les scores des documents à l'aide de l' BM25algorithme Okapi basé sur des mots clés, qui fonctionne bien pour les requêtes de recherche contenant des mots clés. Neural Search propose de nouveaux types de requêtes pour les requêtes en langage naturel et la possibilité de combiner la recherche sémantique et la recherche par mots clés.
**Example : `neural`**
```
"neural": {
"vector_field": {
"query_text": "query_text",
"query_image": "image_binary",
"model_id": "model_id",
"k": 100
}
}
```
Pour plus d'informations, consultez la section [Requête neurale](https://docs.opensearch.org/latest/query-dsl/specialized/neural/) sur le site Web de *OpenSearch documentation*.
**Example : `hybrid`**
```
"hybrid": {
"queries": [
array of lexical, neural, or combined queries
]
}
```
Pour plus d'informations, consultez la section [Requête hybride](https://docs.opensearch.org/latest/query-dsl/compound/hybrid/) sur le site Web de *OpenSearch documentation*.
Pour configurer les composants de recherche sémantique dans Amazon OpenSearch Serverless, suivez les étapes du [didacticiel Neural Search sur le site](https://docs.opensearch.org/latest/tutorials/vector-search/neural-search-tutorial/) Web de *OpenSearch documentation*. Gardez à l'esprit ces différences importantes :
+ OpenSearch Serverless ne prend en charge que les modèles distants. Vous devez configurer les connecteurs pour les modèles hébergés à distance. Il n'est pas nécessaire de déployer ou de supprimer des modèles distants. Pour plus d'informations, consultez [Commencer à utiliser la recherche sémantique et hybride](https://docs.opensearch.org/latest/tutorials/vector-search/neural-search-tutorial/) sur le site Web de *OpenSearch documentation*.
+ Attendez-vous à une latence pouvant atteindre 15 secondes lorsque vous effectuez une recherche dans votre index vectoriel ou lorsque vous recherchez des pipelines de recherche et d'ingestion récemment créés.
## Configurer les autorisations
La recherche neurale en OpenSearch mode Serverless nécessite les autorisations suivantes. Pour de plus amples informations, veuillez consulter [Autorisations de stratégies prises en charge](serverless-data-access.md#serverless-data-supported-permissions).
**Example : Politique de recherche neuronale**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "NeuralSearch",
"Effect": "Allow",
"Action": [
"aoss:CreateIndex",
"aoss:CreateCollection",
"aoss:UpdateCollection",
"aoss:DeleteIndex",
"aoss:DeleteCollection"
],
"Resource": "arn:aws:aoss:us-east-1:111122223333:collection/your-collection-name"
}
]
}
```
+ **aoss : \$1Index** — Crée un index vectoriel dans lequel les intégrations de texte sont stockées.
+ **aoss : \$1 CollectionItems** — Crée des pipelines d'ingestion et de recherche.
+ **aoss : \$1 MLResource** — Crée et enregistre des modèles d'intégration de texte.
+ **aoss : APIAccess All** — Permet d'accéder aux opérations de OpenSearch APIs recherche et d'ingestion.
Ce qui suit décrit les politiques d'accès aux données de collecte requises pour la recherche neuronale. Remplacez le *placeholder values* par vos informations spécifiques.
**Example : Politique d'accès aux données**
```
[
{
"Description": "Create index permission",
"Rules": [
{
"ResourceType": "index",
"Resource": ["index/collection_name/*"],
"Permission": [
"aoss:CreateIndex",
"aoss:DescribeIndex",
"aoss:UpdateIndex",
"aoss:DeleteIndex"
]
}
],
"Principal": [
"arn:aws:iam::account_id:role/role_name"
]
},
{
"Description": "Create pipeline permission",
"Rules": [
{
"ResourceType": "collection",
"Resource": ["collection/collection_name"],
"Permission": [
"aoss:CreateCollectionItems",
"aoss:DescribeCollectionItems",
"aoss:UpdateCollectionItems",
"aoss:DeleteCollectionItems"
]
}
],
"Principal": [
"arn:aws:iam::account_id:role/role_name"
]
},
{
"Description": "Create model permission",
"Rules": [
{
"ResourceType": "model",
"Resource": ["model/collection_name/*"],
"Permission": ["aoss:CreateMLResources"]
}
],
"Principal": [
"arn:aws:iam::account_id:role/role_name"
]
}
]
```
# Configuration des flux de travail sur Amazon OpenSearch Serverless
## Flux de travail
Les flux de travail aident les créateurs à créer des applications d'IA innovantes sur OpenSearch. Le processus actuel d'utilisation des offres d'apprentissage automatique (ML) OpenSearch, telles que Semantic Search, nécessite des tâches de configuration et de prétraitement complexes, ainsi que des requêtes utilisateur détaillées, qui peuvent toutes deux prendre du temps et être source d'erreurs. Les flux de travail constituent un cadre de simplification permettant d'enchaîner plusieurs appels d'API OpenSearch.
Pour la configuration et l'utilisation, voir [Automatisation des configurations](https://docs.opensearch.org/docs/latest/automating-configurations/index/) sur le *OpenSearch*site Web. Lorsque vous utilisez des flux de travail en mode OpenSearch Serverless, tenez compte de ces différences importantes :
+ OpenSearch Serverless utilise uniquement des modèles distants dans les étapes du flux de travail. Il n'est pas nécessaire de déployer ces modèles.
+ OpenSearch Serverless ne prend pas en charge l'étape de **réindexation** du flux de travail.
+ Lorsque vous recherchez **des flux de travail** et des **états de flux** de travail après d'autres appels d'API, attendez-vous à une latence pouvant atteindre 15 secondes pour que les mises à jour apparaissent.
OpenSearch Les collections sans serveur prennent en charge les flux de travail lorsqu'elles sont utilisées comme source de données dans votre application d' OpenSearch interface utilisateur. Pour plus d'informations, consultez [la section Gestion des associations de sources de données](application-data-sources-and-vpc.md).
## Configurer les autorisations
Avant de créer et d'approvisionner un modèle, vérifiez que vous disposez des autorisations requises. Si vous avez besoin d'aide, contactez l'administrateur de votre compte. OpenSearch Les flux de travail sans serveur nécessitent les autorisations suivantes. Vous pouvez définir les autorisations d'accès à une collection spécifique en définissant l'ARN de la ressource de collection dans votre politique IAM.
**Example : Politique relative aux flux de travail**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "NeuralSearch",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Cognito_identitypoolname/Auth_Role"
]
},
"Action": [
"aoss:CreateIndex",
"aoss:CreateCollection",
"aoss:UpdateCollection",
"aoss:DeleteIndex",
"aoss:DeleteCollection"
],
"Resource": "arn:aws:aoss:us-east-1:111122223333:collection/your-collection-name"
}
]
}
```
+ **aoss : \$1 CollectionItems — Accorde** l'autorisation de créer et de gérer des modèles, et de fournir des pipelines [de recherche et d'ingestion](serverless-configure-neural-search.md).
+ **aoss : \$1Index** — Autorise la création et la suppression d'index à l'aide d'opérations d' OpenSearch API.
+ **aoss : \$1 MLResource — Accorde** l'autorisation de [configurer les étapes du flux de travail utilisant le Configure Machine Learning](serverless-configure-machine-learning.md).
# Présentation de la sécurité dans Amazon OpenSearch Serverless
La sécurité dans Amazon OpenSearch Serverless diffère fondamentalement de la sécurité dans Amazon OpenSearch Service pour les raisons suivantes :
| Fonctionnalité | OpenSearch Service | OpenSearch Sans serveur |
| --- | --- | --- |
| Contrôle d'accès aux données | L'accès aux données est déterminé par des politiques IAM et un contrôle d'accès précis. | L'accès aux données est déterminé par des stratégies d'accès aux données. |
| Chiffrement au repos | Le chiffrement au repos est facultatif pour les domaines. | Le chiffrement au repos est requis pour les collections. |
| Configuration et administration de la sécurité | Vous devez configurer le réseau, le chiffrement et l'accès aux données individuellement pour chaque domaine. | Vous pouvez utiliser des stratégies de sécurité pour gérer les paramètres de sécurité de plusieurs collections à grande échelle. |
Le schéma suivant illustre les composants de sécurité qui constituent une collection fonctionnelle. Une collection doit être associée à une clé de chiffrement, des paramètres d'accès réseau et une stratégie d'accès aux données accordant l'accès à ses ressources.
![\[Diagram showing encryption, network, data access, and authentication policies for a collection.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-security.png)
**Topics**
+ [Stratégies de chiffrement](#serverless-security-encryption)
+ [Stratégies réseau](#serverless-security-network)
+ [Stratégies d'accès aux données](#serverless-security-data-access)
+ [Authentification IAM et SAML](#serverless-security-authentication)
+ [Sécurité de l’infrastructure](#serverless-infrastructure-security)
+ [Commencer à utiliser la sécurité dans Amazon OpenSearch Serverless](serverless-tutorials.md)
+ [Identity and Access Management pour Amazon OpenSearch Serverless](security-iam-serverless.md)
+ [Chiffrement dans Amazon OpenSearch Serverless](serverless-encryption.md)
+ [Accès au réseau pour Amazon OpenSearch Serverless](serverless-network.md)
+ [Conformité à la norme FIPS dans Amazon Serverless OpenSearch](fips-compliance-opensearch-serverless.md)
+ [Contrôle d'accès aux données pour Amazon OpenSearch Serverless](serverless-data-access.md)
+ [Accès au plan de données via AWS PrivateLink](serverless-vpc.md)
+ [Accès au plan de contrôle via AWS PrivateLink](serverless-vpc-cp.md)
+ [Authentification SAML pour Amazon Serverless OpenSearch](serverless-saml.md)
+ [Validation de conformité pour Amazon OpenSearch Serverless](serverless-compliance-validation.md)
## Stratégies de chiffrement
Les [politiques de chiffrement](serverless-encryption.md) définissent si vos collections sont chiffrées à l'aide d'une clé gérée par le client Clé détenue par AWS ou d'une clé gérée par le client. Les stratégies de chiffrement sont constituées de deux composants : un **modèle de ressource** et une **clé de chiffrement**. Le modèle de ressource définit la ou les collections auxquelles la stratégie s'applique. La clé de chiffrement détermine la manière dont les collections associées seront sécurisées.
Pour appliquer une stratégie à plusieurs collections, vous devez inclure un caractère générique (\$1) dans la règle de stratégie. Par exemple, la stratégie suivante s'appliquera à toutes les collections dont le nom commence par « logs ».
![\[Input field for specifying a prefix term or collection name, with "logs*" entered.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-security-encryption.png)
Les stratégies de chiffrement simplifient le processus de création et de gestion des collections, en particulier lorsque vous procédez par programmation. Vous pouvez créer une collection en spécifiant un nom, et une clé de chiffrement lui est automatiquement attribuée lors de sa création.
## Stratégies réseau
Les [politiques réseau](serverless-network.md) définissent si vos collections sont accessibles en privé ou via Internet à partir de réseaux publics. *Les collections privées sont accessibles via des points de terminaison OpenSearch VPC gérés sans serveur, ou par des utilisateurs spécifiques Services AWS tels qu'Amazon Bedrock utilisant un accès privé.Service AWS * Tout comme les stratégies de chiffrement, les stratégies réseau peuvent s'appliquer à plusieurs collections, ce qui vous permet de gérer l'accès réseau à de nombreuses collections à grande échelle.
Les stratégies réseau sont constituées de deux composants : un **type d'accès** et un **type de ressource**. Le type d'accès peut être public ou privé. Le type de ressource détermine si l'accès que vous choisissez s'applique au point de terminaison de collecte, au point de terminaison OpenSearch des tableaux de bord ou aux deux.
![\[Access type and resource type options for configuring network policies in OpenSearch.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-security-network.png)
Si vous envisagez de configurer l'accès VPC dans le cadre d'une politique réseau, vous devez d'abord créer un ou plusieurs points de terminaison VPC gérés [OpenSearch sans serveur](serverless-vpc.md). Ces points de terminaison vous permettent d'accéder à OpenSearch Serverless comme s'il se trouvait dans votre VPC, sans utiliser de passerelle Internet, de périphérique NAT, de connexion VPN ou de connexion. Direct Connect
L'accès privé à ne Services AWS peut s'appliquer qu'au point de OpenSearch terminaison de la collection, et non au point de terminaison OpenSearch des tableaux de bord. Services AWS ne peut pas être autorisé à accéder aux OpenSearch tableaux de bord.
## Stratégies d'accès aux données
Les [stratégies d'accès aux données](serverless-data-access.md) définissent la manière dont vos utilisateurs accèdent aux données de vos collections. Les stratégies d'accès aux données vous permettent de gérer les collections à grande échelle en attribuant automatiquement des autorisations d'accès aux collections et aux index qui correspondent à un modèle spécifique. Plusieurs stratégies peuvent s'appliquer à une seule ressource.
Les stratégies d'accès aux données se composent d'un ensemble de règles, chacune comportant trois éléments : un **type de ressource**, des **ressources octroyées** et un ensemble d'**autorisations**. Le type de ressource peut être une collection ou un index. Les ressources accordées peuvent être collection/index des noms ou des modèles avec un caractère générique (\$1). La liste des autorisations indique les [opérations OpenSearch d'API](serverless-genref.md#serverless-operations) auxquelles la politique accorde l'accès. En outre, la stratégie contient une liste de **principaux** qui spécifient les rôles IAM, les utilisateurs et les identités SAML auxquels accorder l'accès.
![\[Selected principals and granted resources with permissions for collection and index access.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-data-access.png)
Pour plus d'informations sur le format d'une stratégie d'accès aux données, veuillez consulter la rubrique relative à la [syntaxe de la stratégie](serverless-data-access.md#serverless-data-access-syntax).
Avant de créer une stratégie d'accès aux données, vous devez disposer d'un ou de plusieurs rôles ou utilisateurs IAM ou d'identités SAML, à qui accorder l'accès dans la stratégie. Pour plus de détails, veuillez consulter la section suivante.
**Note**
Le passage de l'accès public à l'accès privé pour votre collection supprimera l'onglet Indexes de la console de collecte OpenSearch sans serveur.
## Authentification IAM et SAML
Les principaux IAM et les identités SAML constituent les éléments de base d'une stratégie d'accès aux données. Dans l'instruction `principal` d'une stratégie d'accès, vous pouvez inclure des rôles IAM, des utilisateurs et des identités SAML. Ces principaux se voient ensuite octroyer les autorisations que vous spécifiez dans les règles de stratégie associées.
```
[
{
"Rules":[
{
"ResourceType":"index",
"Resource":[
"index/marketing/orders*"
],
"Permission":[
"aoss:*"
]
}
],
"Principal":[
"arn:aws:iam::123456789012:user/Dale",
"arn:aws:iam::123456789012:role/RegulatoryCompliance",
"saml/123456789012/myprovider/user/Annie"
]
}
]
```
Vous configurez l'authentification SAML directement dans OpenSearch Serverless. Pour de plus amples informations, veuillez consulter [Authentification SAML pour Amazon Serverless OpenSearch](serverless-saml.md).
## Sécurité de l’infrastructure
Amazon OpenSearch Serverless est protégé par la sécurité du réseau AWS mondial. Pour plus d'informations sur les services AWS de sécurité et sur la manière dont AWS l'infrastructure est protégée, consultez la section [Sécurité du AWS cloud](https://aws.amazon.com/security/). Pour concevoir votre AWS environnement en utilisant les meilleures pratiques en matière de sécurité de l'infrastructure, consultez la section [Protection de l'infrastructure](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) dans le cadre * AWS bien architecturé du pilier de sécurité*.
Vous utilisez des appels d'API AWS publiés pour accéder à Amazon OpenSearch Serverless via le réseau. Les clients doivent prendre en charge le protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3. Pour obtenir la liste des chiffrements pris en charge pour TLS 1.3, consultez la section [Protocoles et chiffrements TLS dans la documentation Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-tls-listener.html#tls-protocols-ciphers).
En outre, vous devez signer les demandes à l'aide d'un identifiant de clé d'accès et d'une clé d'accès secrète associés à un principal IAM. Vous pouvez également utiliser [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) pour générer des informations d’identification de sécurité temporaires et signer les demandes.
# Commencer à utiliser la sécurité dans Amazon OpenSearch Serverless
Les didacticiels suivants vous aideront à commencer à utiliser Amazon OpenSearch Serverless. Les deux didacticiels suivent les mêmes étapes de base, mais l'un utilise la console tandis que l'autre utilise l' AWS CLI.
Veuillez noter que les cas d'utilisation présentés dans ces didacticiels sont simplifiés. Les stratégies réseau et de sécurité sont assez légères. Pour les charges de travail de production, nous vous recommandons de configurer des fonctionnalités de sécurité plus robustes telles que l'authentification SAML, l'accès au VPC et des stratégies d'accès aux données restrictives.
**Topics**
+ [Tutoriel : prise en main de la sécurité dans Amazon OpenSearch Serverless (console)](gsg-serverless.md)
+ [Tutoriel : prise en main de la sécurité dans Amazon OpenSearch Serverless (CLI)](gsg-serverless-cli.md)
# Tutoriel : prise en main de la sécurité dans Amazon OpenSearch Serverless (console)
Ce didacticiel explique les étapes de base pour créer et gérer des politiques de sécurité à l'aide de la console Amazon OpenSearch Serverless.
Dans le cadre de ce didacticiel, vous suivrez les étapes suivantes :
1. [Configurer des autorisations](#gsgpermissions)
1. [Créer une stratégie de chiffrement](#gsg-encryption)
1. [Création d'une stratégie réseau](#gsg-network)
1. [Configuration d'une stratégie d'accès aux données](#gsg-data-access)
1. [Créer une collection](#gsgcreate-collection)
1. [Charger et rechercher des données](#gsgindex-collection)
Ce didacticiel vous explique comment configurer une collection à l'aide du AWS Management Console. Pour les mêmes étapes à suivre lors de l'utilisation du AWS CLI, voir[Tutoriel : prise en main de la sécurité dans Amazon OpenSearch Serverless (CLI)](gsg-serverless-cli.md).
## Étape 1 : configurer des autorisations
**Note**
Vous pouvez ignorer cette étape si vous utilisez déjà une politique basée sur l'identité plus large, telle que `Action":"aoss:*"` ou `Action":"*"`. Toutefois, dans les environnements de production, nous vous recommandons de suivre le principe du moindre privilège et de n'attribuer que les autorisations minimales nécessaires pour effectuer une tâche.
Afin de suivre ce didacticiel, vous devez disposer des autorisations IAM appropriées. Votre utilisateur ou votre rôle doit être associé à une [politique basée sur l'identité](security-iam-serverless.md#security-iam-serverless-id-based-policies) avec les autorisations minimales suivantes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"aoss:ListCollections",
"aoss:BatchGetCollection",
"aoss:CreateCollection",
"aoss:CreateSecurityPolicy",
"aoss:GetSecurityPolicy",
"aoss:ListSecurityPolicies",
"aoss:CreateAccessPolicy",
"aoss:GetAccessPolicy",
"aoss:ListAccessPolicies"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
Pour obtenir la liste complète des autorisations OpenSearch sans serveur, consultez[Identity and Access Management pour Amazon OpenSearch Serverless](security-iam-serverless.md).
## Étape 2 : créer une stratégie de chiffrement
Les [politiques de chiffrement](serverless-encryption.md) spécifient la AWS KMS clé que OpenSearch Serverless utilisera pour chiffrer la collection. Vous pouvez chiffrer des collections à l'aide d'une clé Clé gérée par AWS ou d'une autre clé. Par souci de simplicité, dans le cadre de ce didacticiel, nous allons chiffrer notre collection à l'aide d'une Clé gérée par AWS.
**Créer une stratégie de chiffrement**
1. Ouvrez la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home ).
1. Développez **Serverless** (Sans serveur) dans le panneau de navigation de gauche et choisissez **Encryption policies** (Stratégies de chiffrement).
1. Choisissez **Create encryption policy** (Créer une stratégie de chiffrement).
1. Nommez la stratégie **books-policy**. Pour la description, saisissez **Encryption policy for books collection** (Stratégie de chiffrement pour la collection books).
1. Dans **Resources** (Ressources), saisissez **books** (livres), le nom que vous donnerez à votre collection. Si vous souhaitez être plus large, vous pouvez inclure un astérisque (`books*`) pour que la stratégie s'applique à toutes les collections commençant par le mot « books ».
1. Pour **le chiffrement**, maintenez **l'option Utiliser la clé AWS détenue** sélectionnée.
1. Choisissez **Créer**.
## Étape 3 : créer une politique réseau
[Les politiques réseau](serverless-network.md) déterminent si votre collection est accessible via Internet à partir de réseaux publics ou si elle doit être accessible via des points de terminaison OpenSearch VPC gérés sans serveur. Dans le cadre de ce didacticiel, nous allons configurer l'accès public.
**Créer une stratégie réseau**
1. Choisissez **Network policies** (Stratégies réseau) dans le panneau de navigation de gauche, puis **Create network policy** (Créer une stratégie réseau).
1. Nommez la stratégie **books-policy**. Pour la description, saisissez **Network policy for books collection** (Stratégie réseau pour la collection books).
1. Sous **Rule 1** (Règle 1), nommez la règle **Public access for books collection** (Accès public à la collection books).
1. Par souci de simplicité, dans le cadre de ce didacticiel, nous allons configurer l'accès public à la collection *books*. Pour le type d'accès, sélectionnez **Public**.
1. Nous allons accéder à la collection depuis les OpenSearch tableaux de bord. Pour ce faire, vous devez configurer l'accès réseau pour les tableaux de bord *et* le OpenSearch point de terminaison, sinon les tableaux de bord ne fonctionneront pas.
Pour le type de ressource, activez à la fois **l'accès aux OpenSearch points de terminaison** et **l'accès aux OpenSearch tableaux de bord**.
1. Dans les deux zones de saisie, saisissez **Collection Name = books** (Nom de la collection = books). Ce paramètre réduit la portée de la stratégie afin qu'elle ne s'applique qu'à une seule collection (`books`). Votre règle devrait ressembler à ceci :
![\[Search interface showing two input fields for collection or prefix term selection, both set to "books".\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-tutorial-network.png)
1. Choisissez **Créer**.
## Étape 4 : Création d'une politique d'accès aux données
Les données de votre collection ne seront pas accessibles tant que vous n'aurez pas configuré l'accès aux données. Les [stratégies d'accès aux données](serverless-data-access.md) sont distinctes de la politique IAM basée sur l'identité que vous avez configurée à l'étape 1. Elles permettent aux utilisateurs d'accéder aux données réelles d'une collection.
Dans le cadre de ce didacticiel, nous allons fournir à un seul utilisateur les autorisations requises pour indexer des données dans la collection *books*.
**Créer une stratégie d'accès aux données**
1. Dans le panneau de navigation de gauche, choisissez **Data access policies** (Stratégies d'accès aux données), puis **Create access policy** (Créer une stratégie d'accès).
1. Nommez la stratégie **books-policy**. Pour la description, saisissez **Data access policy for books collection** (Stratégie d'accès aux données pour la collection books).
1. Sélectionnez **JSON** comme méthode de définition de stratégie et collez la stratégie suivante dans l'éditeur JSON.
Remplacez l'ARN principal par l'ARN du compte que vous utiliserez pour vous connecter aux OpenSearch tableaux de bord et indexer les données.
```
[
{
"Rules":[
{
"ResourceType":"index",
"Resource":[
"index/books/*"
],
"Permission":[
"aoss:CreateIndex",
"aoss:DescribeIndex",
"aoss:ReadDocument",
"aoss:WriteDocument",
"aoss:UpdateIndex",
"aoss:DeleteIndex"
]
}
],
"Principal":[
"arn:aws:iam::123456789012:user/my-user"
]
}
]
```
Cette stratégie fournit à un seul utilisateur les autorisations minimales requises pour créer un index dans la collection *books*, indexer certaines données et les rechercher.
1. Choisissez **Créer**.
## Étape 5 : Création d'une collection
Maintenant que vous avez configuré les stratégies de chiffrement et réseau, vous pouvez créer une collection correspondante et les paramètres de sécurité lui seront automatiquement appliqués.
**Pour créer une collection OpenSearch sans serveur**
1. Choisissez **Collections** dans le panneau de navigation de gauche, puis choisissez **Create collection** (Créer une collection).
1. Nommez la collection **books**.
1. Pour le type de collection, choisissez **Search** (Rechercher).
1. Sous **Chiffrement**, OpenSearch Serverless vous informe que le nom de la collection correspond à la politique de `books-policy` chiffrement.
1. Dans **les paramètres d'accès au réseau**, OpenSearch Serverless vous informe que le nom de la collection correspond à la politique du `books-policy` réseau.
1. Choisissez **Suivant**.
1. Sous **Options de politique d'accès aux données**, OpenSearch Serverless vous informe que le nom de la collection correspond à la politique d'accès aux `books-policy` données.
1. Choisissez **Suivant**.
1. Vérifiez la configuration de la collection et choisissez **Submit** (Soumettre). L'initialisation des collections prend généralement moins d'une minute.
## Étape 6 : charger et rechercher des données
Vous pouvez télécharger des données dans une collection OpenSearch sans serveur à l'aide de Postman ou de curl. Par souci de concision, ces exemples utilisent les **outils de développement** de la console OpenSearch Dashboards.
**Indexer et rechercher des données dans une collection**
1. Choisissez **Collections** dans le panneau de navigation de gauche, puis choisissez la collection **books** pour afficher sa page des détails.
1. Choisissez l'URL OpenSearch des tableaux de bord pour la collection. L'URL est au format `https://collection-id.us-east-1.aoss.amazonaws.com/_dashboards`.
1. Connectez-vous aux OpenSearch tableaux de bord à l'aide des [clés AWS d'accès et secrètes](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-appendix-sign-up.html) du principal que vous avez spécifiées dans votre politique d'accès aux données.
1. Dans OpenSearch Dashboards, ouvrez le menu de navigation de gauche et choisissez **Dev Tools**.
1. Pour créer un index unique appelé *books-index*, exécutez la commande suivante :
```
PUT books-index
```
![\[OpenSearch Dashboards console showing PUT request for books-index with JSON response.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-createindex.png)
1. Pour indexer un seul document dans *books-index*, exécutez la commande suivante :
```
PUT books-index/_doc/1
{
"title": "The Shining",
"author": "Stephen King",
"year": 1977
}
```
1. Pour rechercher des données dans OpenSearch les tableaux de bord, vous devez configurer au moins un modèle d'index. OpenSearch utilise ces modèles pour identifier les index que vous souhaitez analyser. Ouvrez le menu principal Tableaux de bord et choisissez **Stack Management (Gestion de la pile)**, **Index Patterns (Modèles d'index)**, puis **Create index pattern (Créer un modèle d'index)**. Pour ce didacticiel, saisissez *books-index*.
1. Choisissez **Next step (Étape suivante)**, puis **Create index pattern (Créer un modèle d'index)**. Une fois le modèle créé, vous pouvez consulter les différents champs du document, comme `author` et `title`.
1. Pour commencer à effectuer des recherches sur vos données, ouvrez à nouveau le menu principal et choisissez **Discover** (Découvrir) ou utilisez l'[API de recherche](https://opensearch.org/docs/latest/opensearch/rest-api/search/).
# Tutoriel : prise en main de la sécurité dans Amazon OpenSearch Serverless (CLI)
Ce didacticiel explique les étapes décrites dans le [didacticiel de démarrage de la console](gsg-serverless.md) pour la sécurité, mais utilise la console AWS CLI plutôt que la console OpenSearch de service.
Dans le cadre de ce didacticiel, vous suivrez les étapes suivantes :
1. Création d'une politique d'autorisations IAM
1. Associer la politique IAM à un rôle IAM
1. Créer une politique de chiffrement
1. Création d'une stratégie réseau
1. Créer une collection
1. Configuration d'une stratégie d'accès aux données
1. Récupérer le point de terminaison de collecte
1. Téléchargez des données sur votre connexion
1. Rechercher des données dans votre collection
L'objectif de ce didacticiel est de configurer une collection unique OpenSearch sans serveur avec des paramètres de chiffrement, de réseau et d'accès aux données assez simples. Par exemple, nous allons configurer l'accès au réseau public, un Clé gérée par AWS système de chiffrement et une politique d'accès aux données simplifiée qui accorde des autorisations minimales à un seul utilisateur.
Dans un scénario de production, envisagez de mettre en œuvre une configuration plus robuste, notamment une authentification SAML, une clé de chiffrement personnalisée et un accès VPC.
**Pour commencer à utiliser les politiques de sécurité dans OpenSearch Serverless**
1.
**Note**
Vous pouvez ignorer cette étape si vous utilisez déjà une politique basée sur l'identité plus large, telle que `Action":"aoss:*"` ou `Action":"*"`. Toutefois, dans les environnements de production, nous vous recommandons de suivre le principe du moindre privilège et de n'attribuer que les autorisations minimales nécessaires pour effectuer une tâche.
Pour commencer, créez une Gestion des identités et des accès AWS politique avec les autorisations minimales requises pour effectuer les étapes de ce didacticiel. Nous nommerons la politique `TutorialPolicy` :
```
aws iam create-policy \
--policy-name TutorialPolicy \
--policy-document "{\"Version\": \"2012-10-17\",\"Statement\": [{\"Action\": [\"aoss:ListCollections\",\"aoss:BatchGetCollection\",\"aoss:CreateCollection\",\"aoss:CreateSecurityPolicy\",\"aoss:GetSecurityPolicy\",\"aoss:ListSecurityPolicies\",\"aoss:CreateAccessPolicy\",\"aoss:GetAccessPolicy\",\"aoss:ListAccessPolicies\"],\"Effect\": \"Allow\",\"Resource\": \"*\"}]}"
```
**Exemple de réponse**
```
{
"Policy": {
"PolicyName": "TutorialPolicy",
"PolicyId": "ANPAW6WRAECKG6QJWUV7U",
"Arn": "arn:aws:iam::123456789012:policy/TutorialPolicy",
"Path": "/",
"DefaultVersionId": "v1",
"AttachmentCount": 0,
"PermissionsBoundaryUsageCount": 0,
"IsAttachable": true,
"CreateDate": "2022-10-16T20:57:18+00:00",
"UpdateDate": "2022-10-16T20:57:18+00:00"
}
}
```
1. Attachez `TutorialPolicy` au rôle IAM qui indexera et recherchera les données dans la collection. Nous nommerons l'utilisateur `TutorialRole` :
```
aws iam attach-role-policy \
--role-name TutorialRole \
--policy-arn arn:aws:iam::123456789012:policy/TutorialPolicy
```
1. Avant de créer une collection, vous devez créer une [stratégie de chiffrement](serverless-encryption.md) qui attribue une Clé détenue par AWS à la collection *books* que vous créerez ultérieurement.
Envoyez la requête suivante afin de créer une stratégie de chiffrement pour la collection *books* :
```
aws opensearchserverless create-security-policy \
--name books-policy \
--type encryption --policy "{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection\/books\"]}],\"AWSOwnedKey\":true}"
```
**Exemple de réponse**
```
{
"securityPolicyDetail": {
"type": "encryption",
"name": "books-policy",
"policyVersion": "MTY2OTI0MDAwNTk5MF8x",
"policy": {
"Rules": [
{
"Resource": [
"collection/books"
],
"ResourceType": "collection"
}
],
"AWSOwnedKey": true
},
"createdDate": 1669240005990,
"lastModifiedDate": 1669240005990
}
}
```
1. Créez une [stratégie réseau](serverless-network.md) qui fournit un accès public à la collection *books* :
```
aws opensearchserverless create-security-policy --name books-policy --type network \
--policy "[{\"Description\":\"Public access for books collection\",\"Rules\":[{\"ResourceType\":\"dashboard\",\"Resource\":[\"collection\/books\"]},{\"ResourceType\":\"collection\",\"Resource\":[\"collection\/books\"]}],\"AllowFromPublic\":true}]"
```
**Exemple de réponse**
```
{
"securityPolicyDetail": {
"type": "network",
"name": "books-policy",
"policyVersion": "MTY2OTI0MDI1Njk1NV8x",
"policy": [
{
"Rules": [
{
"Resource": [
"collection/books"
],
"ResourceType": "dashboard"
},
{
"Resource": [
"collection/books"
],
"ResourceType": "collection"
}
],
"AllowFromPublic": true,
"Description": "Public access for books collection"
}
],
"createdDate": 1669240256955,
"lastModifiedDate": 1669240256955
}
}
```
1. Créez la collection *books* :
```
aws opensearchserverless create-collection --name books --type SEARCH
```
**Exemple de réponse**
```
{
"createCollectionDetail": {
"id": "8kw362bpwg4gx9b2f6e0",
"name": "books",
"status": "CREATING",
"type": "SEARCH",
"arn": "arn:aws:aoss:us-east-1:123456789012:collection/8kw362bpwg4gx9b2f6e0",
"kmsKeyArn": "auto",
"createdDate": 1669240325037,
"lastModifiedDate": 1669240325037
}
}
```
1. Créez une [stratégie d'accès aux données](serverless-data-access.md) qui fournit les autorisations minimales nécessaires pour indexer et rechercher des données dans la collection *books*. Remplacez l'ARN du principal par l'ARN du `TutorialRole` de l'étape 1 :
```
aws opensearchserverless create-access-policy \
--name books-policy \
--type data \
--policy "[{\"Rules\":[{\"ResourceType\":\"index\",\"Resource\":[\"index\/books\/books-index\"],\"Permission\":[\"aoss:CreateIndex\",\"aoss:DescribeIndex\",\"aoss:ReadDocument\",\"aoss:WriteDocument\",\"aoss:UpdateIndex\",\"aoss:DeleteIndex\"]}],\"Principal\":[\"arn:aws:iam::123456789012:role\/TutorialRole\"]}]"
```
**Exemple de réponse**
```
{
"accessPolicyDetail": {
"type": "data",
"name": "books-policy",
"policyVersion": "MTY2OTI0MDM5NDY1M18x",
"policy": [
{
"Rules": [
{
"Resource": [
"index/books/books-index"
],
"Permission": [
"aoss:CreateIndex",
"aoss:DescribeIndex",
"aoss:ReadDocument",
"aoss:WriteDocument",
"aoss:UpdateDocument",
"aoss:DeleteDocument"
],
"ResourceType": "index"
}
],
"Principal": [
"arn:aws:iam::123456789012:role/TutorialRole"
]
}
],
"createdDate": 1669240394653,
"lastModifiedDate": 1669240394653
}
}
```
`TutorialRole` devrait désormais pouvoir indexer et rechercher des documents dans la collection *books*.
1. Pour appeler l' OpenSearch API, vous avez besoin du point de terminaison de collecte. Envoyez la requête suivante pour récupérer le paramètre `collectionEndpoint` :
```
aws opensearchserverless batch-get-collection --names books
```
**Exemple de réponse**
```
{
"collectionDetails": [
{
"id": "8kw362bpwg4gx9b2f6e0",
"name": "books",
"status": "ACTIVE",
"type": "SEARCH",
"description": "",
"arn": "arn:aws:aoss:us-east-1:123456789012:collection/8kw362bpwg4gx9b2f6e0",
"createdDate": 1665765327107,
"collectionEndpoint": "https://8kw362bpwg4gx9b2f6e0.us-east-1.aoss.amazonaws.com",
"dashboardEndpoint": "https://8kw362bpwg4gx9b2f6e0.us-east-1.aoss.amazonaws.com/_dashboards"
}
],
"collectionErrorDetails": []
}
```
**Note**
Vous ne pourrez pas voir le point de terminaison de la collection tant que le statut de la collection ne sera pas passé à `ACTIVE`. Vous devrez peut-être effectuer plusieurs appels pour vérifier le statut jusqu'à ce que la collection soit correctement créée.
1. Utilisez un outil HTTP tel que [Postman](https://www.getpostman.com/) ou curl pour indexer les données dans la collection *books*. Nous allons créer un index appelé *books-index* et ajouter un seul document.
Envoyez la requête suivante au point de terminaison de collection que vous avez récupéré à l'étape précédente, à l'aide des informations d'identification de `TutorialRole`.
```
PUT https://8kw362bpwg4gx9b2f6e0.us-east-1.aoss.amazonaws.com/books-index/_doc/1
{
"title": "The Shining",
"author": "Stephen King",
"year": 1977
}
```
**Exemple de réponse**
```
{
"_index" : "books-index",
"_id" : "1",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 0,
"successful" : 0,
"failed" : 0
},
"_seq_no" : 0,
"_primary_term" : 0
}
```
1. Pour commencer à rechercher des données dans votre collection, utilisez l'[API de recherche](https://opensearch.org/docs/latest/opensearch/rest-api/search/). La requête suivante permet d'effectuer une recherche de base :
```
GET https://8kw362bpwg4gx9b2f6e0.us-east-1.aoss.amazonaws.com/books-index/_search
```
**Exemple de réponse**
```
{
"took": 405,
"timed_out": false,
"_shards": {
"total": 6,
"successful": 6,
"skipped": 0,
"failed": 0
},
"hits": {
"total": {
"value": 2,
"relation": "eq"
},
"max_score": 1.0,
"hits": [
{
"_index": "books-index:0::3xJq14MBUaOS0wL26UU9:0",
"_id": "F_bt4oMBLle5pYmm5q4T",
"_score": 1.0,
"_source": {
"title": "The Shining",
"author": "Stephen King",
"year": 1977
}
}
]
}
}
```
# Identity and Access Management pour Amazon OpenSearch Serverless
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Les administrateurs IAM contrôlent qui peut être *authentifié* (connecté) et *autorisé (autorisé*) à utiliser les ressources OpenSearch sans serveur. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Politiques basées sur l'identité pour Serverless OpenSearch](#security-iam-serverless-id-based-policies)
+ [Actions stratégiques pour le mode OpenSearch Serverless](#security-iam-serverless-id-based-policies-actions)
+ [Ressources relatives aux politiques pour le mode OpenSearch Serverless](#security-iam-serverless-id-based-policies-resources)
+ [Clés de conditions de politique pour Amazon OpenSearch Serverless](#security_iam_serverless-conditionkeys)
+ [ABAC avec Serverless OpenSearch](#security_iam_serverless-with-iam-tags)
+ [Utilisation d'informations d'identification temporaires avec OpenSearch Serverless](#security_iam_serverless-tempcreds)
+ [Rôles liés à un service pour Serverless OpenSearch](#security_iam_serverless-slr)
+ [Autres types de politique](#security_iam_access-manage-other-policies)
+ [Exemples de politiques basées sur l'identité pour Serverless OpenSearch](#security_iam_serverless_id-based-policy-examples)
+ [Support d'IAM Identity Center pour Amazon Serverless OpenSearch](serverless-iam-identity-center.md)
## Politiques basées sur l'identité pour Serverless OpenSearch
**Prend en charge les politiques basées sur l’identité :** oui
Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
### Exemples de politiques basées sur l'identité pour Serverless OpenSearch
Pour consulter des exemples de politiques basées sur l'identité OpenSearch sans serveur, consultez. [Exemples de politiques basées sur l'identité pour Serverless OpenSearch](#security_iam_serverless_id-based-policy-examples)
## Actions stratégiques pour le mode OpenSearch Serverless
**Prend en charge les actions de politique :** oui
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Les actions de stratégie portent généralement le même nom que l'opération AWS d'API associée. Il existe quelques exceptions, telles que les *actions avec autorisations uniquement* qui n’ont pas d’opération API correspondante. Certaines opérations nécessitent également plusieurs actions dans une politique. Ces actions supplémentaires sont nommées *actions dépendantes*.
Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
Les actions de stratégie dans OpenSearch Serverless utilisent le préfixe suivant avant l'action :
```
aoss
```
Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules.
```
"Action": [
"aoss:action1",
"aoss:action2"
]
```
Vous pouvez préciser plusieurs actions à l'aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `Describe`, incluez l’action suivante :
```
"Action": "aoss:List*"
```
Pour consulter des exemples de politiques basées sur l'identité OpenSearch sans serveur, consultez. [Exemples de politiques basées sur l'identité pour Serverless OpenSearch](#security_iam_id-based-policy-examples)
## Ressources relatives aux politiques pour le mode OpenSearch Serverless
**Prend en charge les ressources de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
## Clés de conditions de politique pour Amazon OpenSearch Serverless
**Prend en charge les clés de condition de politique spécifiques au service :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Outre le contrôle d'accès basé sur les attributs (ABAC), OpenSearch Serverless prend en charge les clés de condition suivantes :
+ `aoss:collection`
+ `aoss:CollectionId`
+ `aoss:index`
Vous pouvez même utiliser ces clés de condition afin de fournir des autorisations relatives aux stratégies d'accès et de sécurité. Par exemple :
```
[
{
"Effect":"Allow",
"Action":[
"aoss:CreateAccessPolicy",
"aoss:CreateSecurityPolicy"
],
"Resource":"*",
"Condition":{
"StringLike":{
"aoss:collection":"log"
}
}
}
]
```
Dans cet exemple, la condition s'applique aux stratégies qui contiennent des *règles* correspondant au nom ou au modèle d'une collection. Les conditions adoptent le comportement suivant :
+ `StringEquals` : s'applique aux stratégies dont les règles contiennent la chaîne de ressource *exacte* « log » (c'est-à-dire `collection/log`).
+ `StringLike` : s'applique aux stratégies dont les règles contiennent une chaîne de ressource qui *contient* la chaîne « log » (c'est-à-dire `collection/log`, mais également `collection/logs-application` ou `collection/applogs123`).
**Note**
Les clés de condition de *collection* ne s'appliquent pas au niveau de l'index. Par exemple, dans la stratégie ci-dessus, la condition ne s'appliquerait pas à une stratégie d'accès ou de sécurité contenant la chaîne de ressource `index/logs-application/*`.
Pour consulter la liste des clés de condition OpenSearch sans serveur, consultez la section [Clés de condition pour Amazon OpenSearch Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchserverless.html#amazonopensearchserverless-policy-keys) dans la référence *d'autorisation de service*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez [Actions définies par Amazon OpenSearch Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchserverless.html#amazonopensearchserverless-actions-as-permissions).
## ABAC avec Serverless OpenSearch
**Prise en charge d’ABAC (balises dans les politiques) :** Oui
Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs appelés balises. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource.
Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`.
Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**.
Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d'informations sur le balisage des ressources OpenSearch sans serveur, consultez. [Marquage des collections Amazon OpenSearch Serverless](tag-collection.md)
## Utilisation d'informations d'identification temporaires avec OpenSearch Serverless
**Prend en charge les informations d’identification temporaires :** oui
Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*.
## Rôles liés à un service pour Serverless OpenSearch
**Prend en charge les rôles liés à un service :** oui
Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service apparaissent dans votre Compte AWS répertoire et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
Pour plus de détails sur la création et la gestion des rôles liés à un service OpenSearch sans serveur, consultez. [Utilisation de rôles liés à un service pour créer OpenSearch des collections sans serveur](serverless-service-linked-roles.md)
## Autres types de politique
AWS prend en charge d'autres types de politiques moins courants. Ces types de politiques peuvent définir le nombre maximum d’autorisations qui vous sont accordées par des types de politiques plus courants.
+ **Politiques de contrôle des services (SCPs)** : SCPs politiques JSON qui spécifient les autorisations maximales pour une organisation ou une unité organisationnelle (UO) dans AWS Organizations. AWS Organizations est un service permettant de regrouper et de gérer de manière centralisée plusieurs AWS comptes détenus par votre entreprise. Si vous activez toutes les fonctionnalités d'une organisation, vous pouvez appliquer des politiques de contrôle des services (SCPs) à l'un ou à l'ensemble de vos comptes. Le SCP limite les autorisations pour les entités des comptes membres, y compris pour chaque utilisateur root AWS du compte. Pour plus d'informations sur les Organizations et consultez SCPs les [politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de AWS Organizations l'utilisateur*.
+ **Politiques de contrôle des ressources (RCPs)** : RCPs politiques JSON que vous pouvez utiliser pour définir le maximum d'autorisations disponibles pour les ressources de vos comptes sans mettre à jour les politiques IAM associées à chaque ressource que vous possédez. Le RCP limite les autorisations pour les ressources des comptes membres et peut avoir un impact sur les autorisations effectives pour les identités, y compris l'utilisateur root du AWS compte, qu'il appartienne ou non à votre organisation. Pour plus d'informations sur les Organizations RCPs, y compris une liste des AWS services compatibles RCPs, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*.
## Exemples de politiques basées sur l'identité pour Serverless OpenSearch
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier des ressources OpenSearch sans serveur. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM.
Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*.
Pour plus de détails sur les actions et les types de ressources définis par Amazon OpenSearch Serverless, y compris le format du ARNs pour chacun des types de ressources, consultez la section [Actions, ressources et clés de condition pour Amazon OpenSearch Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchserverless.html) dans le *Service Authorization Reference*.
**Topics**
+ [Bonnes pratiques en matière de stratégies](#security_iam_serverless-policy-best-practices)
+ [Utilisation de OpenSearch Serverless dans la console](#security_iam_serverless_id-based-policy-examples-console)
+ [Administration des OpenSearch collections sans serveur](#security_iam_id-based-policy-examples-collection-admin)
+ [Affichage de OpenSearch collections sans serveur](#security_iam_id-based-policy-examples-view-collections)
+ [Utilisation des opérations OpenSearch d'API](#security_iam_id-based-policy-examples-data-plane)
+ [ABAC pour les opérations d' OpenSearch API](#security_iam_id-based-policy-examples-data-plane-abac)
### Bonnes pratiques en matière de stratégies
Les politiques basées sur l'identité sont très puissantes. Ils déterminent si quelqu'un peut créer, accéder ou supprimer des ressources OpenSearch sans serveur dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer des ressources OpenSearch sans serveur dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
### Utilisation de OpenSearch Serverless dans la console
Pour accéder à OpenSearch Serverless depuis la console de OpenSearch service, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et d'afficher les informations relatives aux ressources OpenSearch Serverless de votre AWS compte. Si vous créez une stratégie basée sur l'identité qui est plus restrictive que les autorisations minimales requises, la console ne fonctionnera pas comme prévu pour les entités (telles que les rôles IAM) de cette stratégie.
Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API que vous tentez d’effectuer.
La politique suivante permet à un utilisateur d'accéder à OpenSearch Serverless dans la console OpenSearch de service :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Resource": "*",
"Effect": "Allow",
"Action": [
"aoss:ListCollections",
"aoss:BatchGetCollection",
"aoss:ListAccessPolicies",
"aoss:ListSecurityConfigs",
"aoss:ListSecurityPolicies",
"aoss:ListTagsForResource",
"aoss:ListVpcEndpoints",
"aoss:GetAccessPolicy",
"aoss:GetAccountSettings",
"aoss:GetSecurityConfig",
"aoss:GetSecurityPolicy"
]
}
]
}
```
------
### Administration des OpenSearch collections sans serveur
Cette politique est un exemple de politique « d'administration des collections » qui permet à un utilisateur de gérer et d'administrer des collections Amazon OpenSearch Serverless. L'utilisateur peut créer, consulter et supprimer des collections.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Resource": "arn:aws:aoss:us-east-1:111122223333:collection/*",
"Action": [
"aoss:CreateCollection",
"aoss:DeleteCollection",
"aoss:UpdateCollection"
],
"Effect": "Allow"
},
{
"Resource": "*",
"Action": [
"aoss:BatchGetCollection",
"aoss:ListCollections",
"aoss:CreateAccessPolicy",
"aoss:CreateSecurityPolicy"
],
"Effect": "Allow"
}
]
}
```
------
### Affichage de OpenSearch collections sans serveur
Cet exemple de politique permet à un utilisateur de consulter les détails de toutes les collections Amazon OpenSearch Serverless de son compte. L'utilisateur ne peut pas modifier les collections ni les stratégies de sécurité associées.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Resource": "*",
"Action": [
"aoss:ListAccessPolicies",
"aoss:ListCollections",
"aoss:ListSecurityPolicies",
"aoss:ListTagsForResource",
"aoss:BatchGetCollection"
],
"Effect": "Allow"
}
]
}
```
------
### Utilisation des opérations OpenSearch d'API
Les opérations d'API du plan de données comprennent les fonctions que vous utilisez dans OpenSearch Serverless pour obtenir de la valeur en temps réel du service. Les opérations de l'API du plan de contrôle comprennent les fonctions que vous utilisez pour configurer l'environnement.
Pour accéder au plan de données APIs et aux OpenSearch tableaux de bord Amazon OpenSearch Serverless depuis le navigateur, vous devez ajouter deux autorisations IAM pour les ressources de collecte. Ces autorisations sont `aoss:APIAccessAll` et`aoss:DashboardsAccessAll`.
**Note**
À compter du 10 mai 2023, OpenSearch Serverless aura besoin de ces deux nouvelles autorisations IAM pour les ressources de collecte. L'`aoss:APIAccessAll`autorisation autorise l'accès au plan de données et l'`aoss:DashboardsAccessAll`autorisation autorise les OpenSearch tableaux de bord depuis le navigateur. L'échec de l'ajout des deux nouvelles autorisations IAM entraîne une erreur 403.
Cet exemple de politique permet à un utilisateur d'accéder au plan de données APIs pour une collection spécifiée dans son compte et d'accéder aux OpenSearch tableaux de bord pour toutes les collections de son compte.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "aoss:APIAccessAll",
"Resource": "arn:aws:aoss:us-east-1:111122223333:collection/collection-id"
},
{
"Effect": "Allow",
"Action": "aoss:DashboardsAccessAll",
"Resource": "arn:aws:aoss:us-east-1:111122223333:dashboards/default"
}
]
}
```
------
Dans `aoss:APIAccessAll` les deux cas, `aoss:DashboardsAccessAll` accordez une autorisation IAM complète aux ressources de collection, tandis que l'autorisation Dashboards fournit également un accès aux OpenSearch Dashboards. Chaque autorisation fonctionne indépendamment, de sorte qu'un refus explicite `aoss:APIAccessAll` ne bloque pas l'`aoss:DashboardsAccessAll`accès aux ressources, y compris aux outils de développement. Il en va de même pour le démenti`aoss:DashboardsAccessAll`. OpenSearch Serverless prend en charge les clés de condition globales suivantes :
+ `aws:CalledVia`
+ `aws:CalledViaAWSService`
+ `aws:CalledViaFirst`
+ `aws:CalledViaLast`
+ `aws:CurrentTime`
+ `aws:EpochTime`
+ `aws:PrincipalAccount`
+ `aws:PrincipalArn`
+ `aws:PrincipallsAWSService`
+ `aws:PrincipalOrgID`
+ `aws:PrincipalOrgPaths`
+ `aws:PrincipalType`
+ `aws:PrincipalServiceName`
+ `aws:PrincipalServiceNamesList`
+ `aws:ResourceAccount`
+ `aws:ResourceOrgID`
+ `aws:ResourceOrgPaths`
+ `aws:RequestedRegion`
+ `aws:ResourceTag`
+ `aws:SourceIp`
+ `aws:SourceVpce`
+ `aws:SourceVpc`
+ `aws:userid`
+ `aws:username`
+ `aws:VpcSourceIp`
Voici un exemple d'utilisation du bloc `aws:SourceIp` conditionnel de la politique IAM de votre principal pour les appels du plan de données :
```
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0"
}
}
```
Voici un exemple d'utilisation du bloc `aws:SourceVpc` conditionnel de la politique IAM de votre principal pour les appels du plan de données :
```
"Condition": {
"StringEquals": {
"aws:SourceVpc": "vpc-0fdd2445d8EXAMPLE"
}
}
```
En outre, un support est proposé pour les clés spécifiques à OpenSearch Serverless suivantes :
+ `aoss:CollectionId`
+ `aoss:collection`
Voici un exemple d'utilisation du bloc `aoss:collection` conditionnel de la politique IAM de votre principal pour les appels du plan de données :
```
"Condition": {
"StringLike": {
"aoss:collection": "log-*"
}
}
```
### ABAC pour les opérations d' OpenSearch API
Les politiques basées sur l'identité vous permettent d'utiliser des balises pour contrôler l'accès au plan de données Amazon OpenSearch Serverless. APIs La politique suivante est un exemple permettant aux principaux attachés d'accéder au plan de données APIs si la collection possède la `team:devops` balise :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "aoss:APIAccessAll",
"Resource": "arn:aws:aoss:us-east-1:111122223333:collection/collection-id",
"Condition": {
"StringEquals": {
"aws:ResourceTag/team": "devops"
}
}
}
]
}
```
------
La politique suivante est un exemple de refus aux principaux attachés d'accéder au plan de données APIs et aux tableaux de bord si la collection possède le `environment:production` tag :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"aoss:APIAccessAll",
"aoss:DashboardsAccessAll"
],
"Resource": "arn:aws:aoss:us-east-1:111122223333:collection/collection-id"
}
]
}
```
------
Amazon OpenSearch Serverless ne prend pas en charge `RequestTag` les clés de condition `TagKeys` globales pour le plan APIs de données.
# Support d'IAM Identity Center pour Amazon Serverless OpenSearch
## Support d'IAM Identity Center pour Amazon Serverless OpenSearch
Vous pouvez utiliser les principes du centre d'identité IAM (utilisateurs et groupes) pour accéder aux données Amazon OpenSearch Serverless via Amazon Applications. OpenSearch Pour activer la prise en charge d'IAM Identity Center pour Amazon OpenSearch Serverless, vous devez activer l'utilisation d'IAM Identity Center. Pour en savoir plus sur la procédure à suivre, consultez [Qu'est-ce qu'IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) ?
**Note**
Pour accéder aux collections Amazon OpenSearch Serverless à l'aide d'utilisateurs ou de groupes IAM Identity Center, vous devez utiliser la fonctionnalité OpenSearch UI (Applications). L'accès direct aux tableaux de bord OpenSearch sans serveur à l'aide des informations d'identification IAM Identity Center n'est pas pris en charge. Pour plus d'informations, consultez la section [Prise en main de l'interface OpenSearch utilisateur](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/application.html).
Une fois l'instance IAM Identity Center créée, l'administrateur du compte client doit créer une application IAM Identity Center pour le service Amazon OpenSearch Serverless. Cela peut être fait en appelant le [CreateSecurityConfig:](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateSecurityConfig.html). L'administrateur du compte client peut spécifier les attributs qui seront utilisés pour autoriser la demande. Les attributs par défaut utilisés sont `UserId` et `GroupId.`
L'intégration du centre d'identité IAM pour Amazon OpenSearch Serverless utilise les autorisations AWS IAM Identity Center (IAM) suivantes :
+ `aoss:CreateSecurityConfig`— Créez un fournisseur de centre d'identité IAM
+ `aoss:ListSecurityConfig`— Répertoriez tous les fournisseurs IAM Identity Center du compte courant.
+ `aoss:GetSecurityConfig`— Afficher les informations du fournisseur IAM Identity Center.
+ `aoss:UpdateSecurityConfig`— Modifie une configuration IAM Identity Center donnée
+ `aoss:DeleteSecurityConfig`— Supprimez un fournisseur de centre d'identité IAM.
La politique d'accès basée sur l'identité suivante peut être utilisée pour gérer toutes les configurations d'IAM Identity Center :
------
#### [ JSON ]
****
```
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"aoss:CreateSecurityConfig",
"aoss:DeleteSecurityConfig",
"aoss:GetSecurityConfig",
"aoss:UpdateSecurityConfig",
"aoss:ListSecurityConfigs"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
**Note**
L'`Resource`élément doit être un caractère générique.
## Création d'un fournisseur de centre d'identité IAM (console)
Vous pouvez créer un fournisseur de centre d'identité IAM pour activer l'authentification avec l' OpenSearchapplication. Pour activer l'authentification IAM Identity Center pour les OpenSearch tableaux de bord, effectuez les opérations suivantes :
1. Connectez-vous à la [console Amazon OpenSearch Service](https://console.aws.amazon.com/aos/home.).
1. Dans le panneau de navigation de gauche, développez **Serverless** et choisissez **Authentication**.
1. Choisissez **l'authentification IAM Identity Center**.
1. Sélectionnez **Modifier**
1. Cochez la case à côté de Authentifier auprès d'IAM Identity Center.
1. Sélectionnez la clé d'attribut de l'**utilisateur et du groupe** dans le menu déroulant. Les attributs utilisateur seront utilisés pour autoriser les utilisateurs en fonction de `UserName``UserId`, et`Email`. Les attributs de groupe seront utilisés pour authentifier les utilisateurs en fonction de `GroupName` et`GroupId`.
1. Sélectionnez l'instance **IAM Identity Center**.
1. Sélectionnez **Enregistrer**
## Création d'un fournisseur de centre d'identité IAM ()AWS CLI
Pour créer un fournisseur de centre d'identité IAM à l'aide de AWS Command Line Interface (AWS CLI), utilisez la commande suivante :
```
aws opensearchserverless create-security-config \
--region us-east-2 \
--name "iamidentitycenter-config" \
--description "description" \
--type "iamidentitycenter" \
--iam-identity-center-options '{
"instanceArn": "arn:aws:sso:::instance/ssoins-99199c99e99ee999",
"userAttribute": "UserName",
"groupAttribute": "GroupId"
}'
```
Une fois qu'un centre d'identité IAM est activé, les clients peuvent uniquement modifier les attributs des **utilisateurs et des groupes**.
```
aws opensearchserverless update-security-config \
--region us-east-1 \
--id \
--config-version \
--iam-identity-center-options-updates '{
"userAttribute": "UserId",
"groupAttribute": "GroupId"
}'
```
Pour afficher le fournisseur du centre d'identité IAM à l'aide de AWS Command Line Interface, utilisez la commande suivante :
```
aws opensearchserverless list-security-configs --type iamidentitycenter
```
## Supprimer un fournisseur de centre d'identité IAM
IAM Identity Center propose deux instances de fournisseurs, l'une pour le compte de votre organisation et l'autre pour votre compte de membre. Si vous devez modifier votre instance IAM Identity Center, vous devez supprimer votre configuration de sécurité via l'`DeleteSecurityConfig`API et créer une nouvelle configuration de sécurité à l'aide de la nouvelle instance IAM Identity Center. La commande suivante peut être utilisée pour supprimer un fournisseur IAM Identity Center :
```
aws opensearchserverless delete-security-config \
--region us-east-1 \
--id
```
## Accorder à IAM Identity Center l'accès aux données de collecte
Une fois que votre fournisseur de centre d'identité IAM est activé, vous pouvez mettre à jour la politique d'accès aux données de collecte afin d'inclure les principes du centre d'identité IAM. Les principes du IAM Identity Center doivent être mis à jour dans le format suivant :
```
[
{
"Rules":[
...
],
"Principal":[
"iamidentitycenter//user/",
"iamidentitycenter//group/"
]
}
]
```
**Note**
Amazon OpenSearch Serverless ne prend en charge qu'une seule instance IAM Identity Center pour toutes les collections de clients et peut prendre en charge jusqu'à 100 groupes pour un seul utilisateur. Si vous essayez d'utiliser un nombre d'instances supérieur au nombre autorisé, vous rencontrerez une incohérence dans le traitement des autorisations de votre politique d'accès aux données et vous recevrez un message `403` d'erreur.
Vous pouvez octroyer l'accès aux collections, aux index ou aux deux. Si vous souhaitez que différents utilisateurs disposent d'autorisations différentes, vous devez créer plusieurs règles. Pour obtenir la liste des autorisations disponibles, consultez [Identity and Access Management in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html). Pour plus d'informations sur le formatage d'une politique d'accès, consultez la section [Accorder aux identités SAML l'accès aux données de collecte](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-saml.html#serverless-saml-policies).
# Chiffrement dans Amazon OpenSearch Serverless
## Chiffrement au repos
Chaque collection Amazon OpenSearch Serverless que vous créez est protégée par le chiffrement des données au repos, une fonctionnalité de sécurité qui permet d'empêcher tout accès non autorisé à vos données. Encryption at rest utilise AWS Key Management Service (AWS KMS) pour stocker et gérer vos clés de chiffrement. Il utilise l'algorithme Advanced Encryption Standard avec des clés 256 bits (AES-256) afin de procéder au chiffrement.
**Topics**
+ [Stratégies de chiffrement](#serverless-encryption-policies)
+ [Considérations](#serverless-encryption-considerations)
+ [Autorisations nécessaires](#serverless-encryption-permissions)
+ [Politique de clé pour une clé gérée par le client](#serverless-customer-cmk-policy)
+ [Comment OpenSearch Serverless utilise les subventions dans AWS KMS](#serverless-encryption-grants)
+ [Créer des stratégies de chiffrement (console)](#serverless-encryption-console)
+ [Créer des stratégies de chiffrement (AWS CLI)](#serverless-encryption-cli)
+ [Affichage des stratégies de chiffrement](#serverless-encryption-list)
+ [Mise à jour des stratégies de chiffrement](#serverless-encryption-update)
+ [Supprimer des stratégies de chiffrement](#serverless-encryption-delete)
### Stratégies de chiffrement
Les stratégies de chiffrement vous permettent de gérer de nombreuses collections à grande échelle en attribuant automatiquement une clé de chiffrement aux collections nouvellement créées qui correspondent à un nom ou à un modèle spécifique.
Lorsque vous créez une stratégie de chiffrement, vous pouvez soit spécifier un *préfixe*, qui est une règle de correspondance basée sur des caractères génériques, par exemple `MyCollection*`, soit saisir un nom de collection unique. Ensuite, lorsque vous créez une collection correspondant à ce nom ou à ce modèle de préfixe, la stratégie et la clé KMS correspondante lui sont automatiquement attribuées.
Lorsque vous créez une collection, vous pouvez spécifier une AWS KMS clé de deux manières : par le biais de politiques de sécurité ou directement dans la `CreateCollection` demande. Si vous fournissez une AWS KMS clé dans le cadre de la `CreateCollection` demande, elle a priorité sur les politiques de sécurité correspondantes. Grâce à cette approche, vous avez la possibilité de remplacer les paramètres de chiffrement basés sur des politiques pour des collections spécifiques en cas de besoin.
![\[Encryption policy creation process with rules and collection matching to KMS key.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-encryption.png)
Les stratégies de chiffrement comportent les éléments suivants :
+ `Rules` : une ou plusieurs règles de correspondance des collections, chacune comportant les sous-éléments suivants :
+ `ResourceType` : à l'heure actuelle, la seule option est « collection ». Les stratégies de chiffrement s'appliquent uniquement aux ressources de collection.
+ `Resource` : un ou plusieurs noms ou modèles de collection auxquels la stratégie s'appliquera, au format `collection/`.
+ `AWSOwnedKey` : si une Clé détenue par AWS doit être utilisée.
+ `KmsARN` : si vous définissez `AWSOwnedKey` sur false (faux), spécifiez l'Amazon Resource Name (ARN) de la clé KMS avec laquelle chiffrer les collections associées. Si vous incluez ce paramètre, OpenSearch Serverless l'`AWSOwnedKey`ignore.
L'exemple de stratégie suivant attribuera une clé gérée par le client à toute collection future nommée `autopartsinventory`, ainsi qu'aux collections commençant par le terme « sales » (ventes) :
```
{
"Rules":[
{
"ResourceType":"collection",
"Resource":[
"collection/autopartsinventory",
"collection/sales*"
]
}
],
"AWSOwnedKey":false,
"KmsARN":"arn:aws:kms:us-east-1:123456789012:key/93fd6da4-a317-4c17-bfe9-382b5d988b36"
}
```
Même si une stratégie correspond au nom d'une collection, vous pouvez choisir de remplacer cette attribution automatique lors de la création de la collection si le modèle de ressource contient un caractère générique (\$1). Si vous choisissez de remplacer l'attribution automatique des clés, OpenSearch Serverless crée pour vous une politique de chiffrement nommée **auto-< *collection-name* >** et l'attache à la collection. La stratégie ne s'applique initialement qu'à une seule collection, mais vous pouvez la modifier pour inclure des collections supplémentaires.
Si vous modifiez les règles de stratégie pour qu'elles ne correspondent plus à une collection, la clé KMS associée ne sera pas dissociée de cette collection. La collection reste toujours chiffrée à l'aide de sa clé de chiffrement initiale. Si vous souhaitez modifier la clé de chiffrement d'une collection, vous devez recréer la collection.
Si les règles de plusieurs stratégies correspondent à une collection, la règle la plus spécifique est utilisée. Par exemple, si une stratégie contient une règle pour `collection/log*` et une autre pour `collection/logSpecial`, la clé de chiffrement de la seconde stratégie est utilisée, car elle est plus spécifique.
Vous ne pouvez pas utiliser de nom ou de préfixe dans une politique s'il existe déjà dans une autre stratégie. OpenSearch Serverless affiche une erreur si vous essayez de configurer des modèles de ressources identiques dans différentes politiques de chiffrement.
### Considérations
Tenez compte des éléments suivants lorsque vous configurez le chiffrement de vos collections :
+ Le chiffrement au repos est *requis* pour toutes les collections sans serveur.
+ Vous avez la possibilité d'utiliser une clé gérée par le client ou une Clé détenue par AWS. Si vous choisissez une clé gérée par le client, nous vous recommandons d'activer la [rotation automatique des clés](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html).
+ Vous ne pouvez pas modifier la clé de chiffrement d'une collection après la création de la collection. Choisissez soigneusement celle que vous AWS KMS souhaitez utiliser la première fois que vous configurez une collection.
+ Une collection ne peut correspondre qu'à une seule stratégie de chiffrement.
+ Les collections dotées de clés KMS uniques ne peuvent pas partager d'unités de OpenSearch calcul (OCUs) avec d'autres collections. Chaque collection avec une clé unique nécessite ses propres 4 clés OCUs.
+ Si vous mettez à jour la clé KMS dans une stratégie de chiffrement, la modification n'affecte pas les collections correspondantes existantes auxquelles des clés KMS ont déjà été attribuées.
+ OpenSearch Serverless ne vérifie pas explicitement les autorisations des utilisateurs sur les clés gérées par le client. Si un utilisateur est autorisé à accéder à une collection par le biais d'une stratégie d'accès aux données, il pourra ingérer et interroger les données chiffrées à l'aide de la clé associée.
### Autorisations nécessaires
Le chiffrement au repos pour OpenSearch Serverless utilise les autorisations Gestion des identités et des accès AWS (IAM) suivantes. Vous pouvez spécifier des conditions IAM pour restreindre les utilisateurs à des collections spécifiques.
+ `aoss:CreateSecurityPolicy` : créer une stratégie de chiffrement.
+ `aoss:ListSecurityPolicies` : répertorier toutes les stratégies de chiffrements et collections auxquelles elles sont associées.
+ `aoss:GetSecurityPolicy` : consulter les détails d'une stratégie de chiffrement spécifique.
+ `aoss:UpdateSecurityPolicy` : modifier une stratégie de chiffrement.
+ `aoss:DeleteSecurityPolicy` : supprimer une stratégie de chiffrement.
L'exemple de stratégie d'accès basée sur l'identité suivant fournit les autorisations minimales nécessaires à un utilisateur pour gérer les stratégies de chiffrement à l'aide du modèle de ressource `collection/application-logs`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"aoss:CreateSecurityPolicy",
"aoss:UpdateSecurityPolicy",
"aoss:DeleteSecurityPolicy",
"aoss:GetSecurityPolicy"
],
"Resource":"*",
"Condition":{
"StringEquals":{
"aoss:collection":"application-logs"
}
}
},
{
"Effect":"Allow",
"Action":[
"aoss:ListSecurityPolicies"
],
"Resource":"*"
}
]
}
```
------
### Politique de clé pour une clé gérée par le client
Si vous sélectionnez une [clé gérée par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) pour protéger une collection, OpenSearch Serverless obtient l'autorisation d'utiliser la clé KMS au nom du principal qui effectue la sélection. Ce principal, un utilisateur ou un rôle, doit disposer des autorisations sur la clé KMS requises par OpenSearch Serverless. Vous pouvez fournir ces autorisations dans une [stratégie de clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) ou une [politique IAM](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html).
OpenSearch Serverless effectue `GenerateDataKey` des appels d'API `Decrypt` KMS lors d'opérations de maintenance telles que le dimensionnement automatique et les mises à jour logicielles. Il se peut que vous observiez ces appels en dehors de vos habitudes de trafic habituelles. Ces appels font partie du fonctionnement normal du service et n'indiquent pas un trafic utilisateur actif.
OpenSearch Serverless lance un message `KMSKeyInaccessibleException` lorsqu'il ne peut pas accéder à la clé KMS qui chiffre vos données au repos. Cela se produit lorsque vous désactivez ou supprimez la clé KMS, ou lorsque vous révoquez les autorisations permettant à OpenSearch Serverless d'utiliser la clé.
OpenSearch Serverless nécessite au minimum les autorisations suivantes sur une clé gérée par le client :
+ [km : DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)
+ [km : CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html)
Par exemple :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "kms:DescribeKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/Dale"
},
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "aoss.us-east-1.amazonaws.com"
}
}
},
{
"Action": "kms:CreateGrant",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/Dale"
},
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "aoss.us-east-1.amazonaws.com"
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"Decrypt",
"GenerateDataKey"
]
},
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
------
OpenSearch Serverless crée une subvention avec les autorisations [kms : GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) et [KMS:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html).
Pour de plus amples informations, veuillez consulter [Utilisation des politiques de clé AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) dans le *AWS Key Management Service Guide du développeur*.
### Comment OpenSearch Serverless utilise les subventions dans AWS KMS
OpenSearch Serverless nécessite une [autorisation](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) pour utiliser une clé gérée par le client.
Lorsque vous créez une politique de chiffrement dans votre compte avec une nouvelle clé, OpenSearch Serverless crée une subvention en votre nom en envoyant une [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html)demande à AWS KMS. AWS KMS Les autorisations sont utilisées pour donner un accès OpenSearch sans serveur à une clé KMS dans un compte client.
OpenSearch Serverless nécessite l'autorisation d'utiliser votre clé gérée par le client pour les opérations internes suivantes :
+ Envoyez [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)des demandes AWS KMS à pour vérifier que l'ID de clé symétrique géré par le client fourni est valide.
+ Envoyez [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)des demandes à KMS Key pour créer des clés de données avec lesquelles chiffrer des objets.
+ Envoyez des demandes de [déchiffrement](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) AWS KMS à pour déchiffrer les clés de données chiffrées afin qu'elles puissent être utilisées pour chiffrer vos données.
Vous pouvez révoquer l’accès à l’octroi ou supprimer l’accès du service à la clé gérée par le client à tout moment. Si vous le faites, OpenSearch Serverless ne pourra accéder à aucune des données chiffrées par la clé gérée par le client, ce qui affectera toutes les opérations qui dépendent de ces données, entraînant des `AccessDeniedException` erreurs et des échecs dans les flux de travail asynchrones.
OpenSearch Serverless retire les autorisations dans un flux de travail asynchrone lorsqu'une clé gérée par le client n'est associée à aucune politique de sécurité ou à aucune collection.
### Créer des stratégies de chiffrement (console)
Dans une stratégie de chiffrement, vous spécifiez une clé KMS et une série de modèles de collection auxquels la stratégie s'appliquera. Toutes les nouvelles collections correspondant à l'un des modèles définis dans la stratégie se verront attribuer les clés KMS correspondantes lors de la création de la collection. Nous vous recommandons de créer des stratégies de chiffrement *avant* de commencer à créer des collections.
**Pour créer une politique de chiffrement OpenSearch sans serveur**
1. Ouvrez la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home).
1. Dans le panneau de navigation de gauche, développez **Serverless** (Sans serveur) et choisissez **Encryption policies** (Stratégies de chiffrement).
1. Choisissez **Create encryption policy** (Créer une stratégie de chiffrement).
1. Saisissez un nom et une description pour la stratégie.
1. Sous **Resources** (Ressources), saisissez un ou plusieurs modèles de ressources pour cette stratégie de chiffrement. Toutes les collections nouvellement créées sur le Compte AWS et dans la région actuels qui correspondent à l'un des modèles sont automatiquement attribuées à cette stratégie. Par exemple, si vous saisissez `ApplicationLogs` (sans caractère générique) et que vous créez ultérieurement une collection portant ce nom, la stratégie et la clé KMS correspondante sont attribuées à cette collection.
Vous pouvez également fournir un préfixe tel que `Logs*`, qui attribue la stratégie à toute nouvelle collection dont le nom commence par `Logs`. En utilisant des caractères génériques, vous pouvez gérer les paramètres de chiffrement de plusieurs collections à grande échelle.
1. Sous **Encryption** (Chiffrement), choisissez une clé KMS à utiliser.
1. Choisissez **Créer**.
#### Étape suivante : créer des collections
Après avoir configuré une ou plusieurs stratégies de chiffrement, vous pouvez commencer à créer des collections qui correspondent aux règles définies dans ces stratégies. Pour obtenir des instructions, veuillez consulter [Créer des collections](serverless-create.md).
À l'étape **Chiffrements** de la création de la collection, OpenSearch Serverless vous informe que le nom que vous avez saisi correspond au modèle défini dans une politique de chiffrement et attribue automatiquement la clé KMS correspondante à la collection. Si le modèle de ressource contient un caractère générique (\$1), vous pouvez choisir de remplacer la correspondance et de sélectionner votre propre clé.
### Créer des stratégies de chiffrement (AWS CLI)
Pour créer une politique de chiffrement à l'aide des opérations de l'API OpenSearch Serverless, vous devez spécifier des modèles de ressources et une clé de chiffrement au format JSON. La [CreateSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateSecurityPolicy.html)demande accepte à la fois les politiques intégrées et les fichiers .json.
Les stratégies de chiffrement prennent le format suivant. Cet exemple de fichier `my-policy.json` correspond à toute future collection nommée `autopartsinventory`, ainsi qu'à toutes les collections dont le nom commence par `sales`.
```
{
"Rules":[
{
"ResourceType":"collection",
"Resource":[
"collection/autopartsinventory",
"collection/sales*"
]
}
],
"AWSOwnedKey":false,
"KmsARN":"arn:aws:kms:us-east-1:123456789012:key/93fd6da4-a317-4c17-bfe9-382b5d988b36"
}
```
Pour utiliser une clé appartenant au service, définissez `AWSOwnedKey` sur `true` :
```
{
"Rules":[
{
"ResourceType":"collection",
"Resource":[
"collection/autopartsinventory",
"collection/sales*"
]
}
],
"AWSOwnedKey":true
}
```
La requête suivante crée la stratégie de chiffrement :
```
aws opensearchserverless create-security-policy \
--name sales-inventory \
--type encryption \
--policy file://my-policy.json
```
Utilisez ensuite l'opération [CreateCollection](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateCollection.html)API pour créer une ou plusieurs collections correspondant à l'un des modèles de ressources.
### Affichage des stratégies de chiffrement
Avant de créer une collection, vous souhaiterez peut-être prévisualiser les stratégies de chiffrement existantes dans votre compte pour voir laquelle possède un modèle de ressource correspondant au nom de votre collection. La [ListSecurityPolicies](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_ListSecurityPolicies.html)demande suivante répertorie toutes les politiques de chiffrement de votre compte :
```
aws opensearchserverless list-security-policies --type encryption
```
La requête renvoie des informations sur toutes les stratégies de chiffrement configurées. Utilisez le contenu de l'élément `policy` pour consulter les règles de modèle définies dans la stratégie :
```
{
"securityPolicyDetails": [
{
"createdDate": 1663693217826,
"description": "Sample encryption policy",
"lastModifiedDate": 1663693217826,
"name": "my-policy",
"policy": "{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection/autopartsinventory\",\"collection/sales*\"]}],\"AWSOwnedKey\":true}",
"policyVersion": "MTY2MzY5MzIxNzgyNl8x",
"type": "encryption"
}
]
}
```
Pour afficher des informations détaillées sur une politique spécifique, y compris la clé KMS, utilisez la [GetSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_GetSecurityPolicy.html)commande.
### Mise à jour des stratégies de chiffrement
Si vous mettez à jour la clé KMS dans une stratégie de chiffrement, la modification s'applique uniquement aux collections nouvellement créées qui correspondent au nom ou au modèle configuré. Cela n'affecte pas les collections existantes auxquelles des clés KMS ont déjà été attribuées.
Il en va de même des règles de correspondance de stratégie. Si vous ajoutez, modifiez ou supprimez une règle, la modification ne s'applique qu'aux collections nouvellement créées. Les collections existantes ne perdent pas la clé KMS qui leur est attribuée si vous modifiez les règles d'une stratégie afin qu'elle ne corresponde plus au nom d'une collection.
Pour mettre à jour une politique de chiffrement dans la console OpenSearch Serverless, choisissez **Politiques de chiffrement**, sélectionnez la politique à modifier, puis choisissez **Modifier**. Effectuez vos modifications, puis cliquez sur **Enregistrer**.
Pour mettre à jour une politique de chiffrement à l'aide de l'API OpenSearch Serverless, utilisez l'[UpdateSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UpdateSecurityPolicy.html)opération. La requête suivante met à jour une stratégie de chiffrement avec un nouveau document JSON de stratégie :
```
aws opensearchserverless update-security-policy \
--name sales-inventory \
--type encryption \
--policy-version 2 \
--policy file://my-new-policy.json
```
### Supprimer des stratégies de chiffrement
Lorsque vous supprimez une stratégie de chiffrement, toutes les collections qui utilisent actuellement la clé KMS définie dans la stratégie ne sont pas affectées. Pour supprimer une politique dans la console OpenSearch Serverless, sélectionnez-la, puis choisissez **Supprimer**.
Vous pouvez également utiliser l'[DeleteSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_DeleteSecurityPolicy.html)opération :
```
aws opensearchserverless delete-security-policy --name my-policy --type encryption
```
## Chiffrement en transit
Dans OpenSearch Serverless, tous les chemins d'une collection sont chiffrés en transit à l'aide du protocole TLS (Transport Layer Security) avec un algorithme de chiffrement AES-256 conforme aux normes du secteur. L'accès à tous APIs et aux tableaux de bord pour Opensearch se fait également via TLS 1.2. Le protocole TLS est un ensemble de protocoles cryptographiques conformes aux normes de l'industrie utilisés pour chiffrer les informations échangées sur le réseau.
# Accès au réseau pour Amazon OpenSearch Serverless
Les paramètres réseau d'une collection Amazon OpenSearch Serverless déterminent si la collection est accessible via Internet à partir de réseaux publics ou si elle doit être accessible de manière privée.
L'accès privé peut s'appliquer à l'un des éléments suivants ou aux deux :
+ OpenSearch Points de terminaison VPC gérés sans serveur
+ Supportés Services AWS , tels qu'Amazon Bedrock
Vous pouvez configurer l'accès au réseau séparément pour le point de *OpenSearch*terminaison d'une collection et pour le point de terminaison *OpenSearch Dashboards* correspondant.
L'accès réseau est le mécanisme d'isolation permettant l'accès à partir de différents réseaux source. Par exemple, si le point de terminaison OpenSearch des tableaux de bord d'une collection est accessible au public mais que le point de terminaison de l' OpenSearch API ne l'est pas, un utilisateur peut accéder aux données de la collection uniquement via les tableaux de bord lorsqu'il se connecte depuis un réseau public. S'ils essaient de les appeler OpenSearch APIs directement depuis un réseau public, ils seront bloqués. Les paramètres réseau peuvent être utilisés pour de telles permutations de la source au type de ressource. Amazon OpenSearch Serverless prend en charge les deux, IPv4 ainsi que la IPv6 connectivité.
**Topics**
+ [Stratégies réseau](#serverless-network-policies)
+ [Considérations](#serverless-network-considerations)
+ [Autorisations requises pour configurer les politiques réseau](#serverless-network-permissions)
+ [Priorité des stratégies](#serverless-network-precedence)
+ [Créer des stratégies réseau (console)](#serverless-network-console)
+ [Création de stratégies réseau (AWS CLI)](#serverless-network-cli)
+ [Affichage des stratégies réseau](#serverless-network-list)
+ [Mettre à jour des stratégies réseau](#serverless-network-update)
+ [Supprimer des stratégies réseau](#serverless-network-delete)
## Stratégies réseau
Les stratégies réseau vous permettent de gérer de nombreuses collections à grande échelle en attribuant automatiquement des paramètres d'accès réseau aux collections qui correspondent aux règles définies dans la stratégie.
Dans une stratégie réseau, vous spécifiez une série de *règles*. Ces règles définissent les autorisations d'accès aux points de terminaison de collecte et aux points de terminaison des OpenSearch tableaux de bord. Chaque règle comprend un type d'accès (public ou privé) et un type de ressource (collection et/ou point de terminaison OpenSearch Dashboards). Pour chaque type de ressource (`collection` et `dashboard`), vous spécifiez une série de règles qui définissent à quelles collections la stratégie s'appliquera.
Dans cet exemple de politique, la première règle spécifie l'accès du point de terminaison VPC à la fois au point de terminaison de collecte et au point de terminaison du tableau de bord pour toutes les collections commençant par le terme. `marketing*` Il spécifie également l'accès à Amazon Bedrock.
**Note**
L'accès privé à Services AWS Amazon Bedrock *ne s'applique qu'*au point de terminaison de la collection, et non au OpenSearch point de terminaison OpenSearch des tableaux de bord. Même si `ResourceType` c'est le cas`dashboard`, l'accès aux OpenSearch tableaux de bord Services AWS ne peut pas être accordé.
La deuxième règle spécifie l'accès public à la collection `finance`, mais uniquement pour le point de terminaison de la collection (aucun accès aux tableaux de bord).
```
[
{
"Description":"Marketing access",
"Rules":[
{
"ResourceType":"collection",
"Resource":[
"collection/marketing*"
]
},
{
"ResourceType":"dashboard",
"Resource":[
"collection/marketing*"
]
}
],
"AllowFromPublic":false,
"SourceVPCEs":[
"vpce-050f79086ee71ac05"
],
"SourceServices":[
"bedrock.amazonaws.com"
],
},
{
"Description":"Sales access",
"Rules":[
{
"ResourceType":"collection",
"Resource":[
"collection/finance"
]
}
],
"AllowFromPublic":true
}
]
```
Cette politique fournit un accès public uniquement aux OpenSearch tableaux de bord pour les collections commençant par « finance ». Toute tentative d'accès direct à l' OpenSearch API échouera.
```
[
{
"Description": "Dashboards access",
"Rules": [
{
"ResourceType": "dashboard",
"Resource": [
"collection/finance*"
]
}
],
"AllowFromPublic": true
}
]
```
Les stratégies réseau peuvent s'appliquer aux collections existantes ainsi qu'aux collections futures. Par exemple, vous pouvez créer une collection, puis créer une stratégie réseau avec une règle correspondant au nom de la collection. Vous n'avez pas besoin de créer des stratégies réseau avant de créer des collections.
## Considérations
Tenez compte des éléments suivants lorsque vous configurez l'accès réseau de vos collections :
+ Si vous envisagez de configurer l'accès au point de terminaison VPC pour une collection, vous devez d'abord créer au [OpenSearch moins un point de terminaison VPC géré sans serveur](serverless-vpc.md).
+ L'accès privé à Services AWS ne s'applique qu'au point de OpenSearch terminaison de la collection, et non au point de terminaison OpenSearch des tableaux de bord. Même si `ResourceType` c'est le cas`dashboard`, l'accès aux OpenSearch tableaux de bord Services AWS ne peut pas être accordé.
+ Si une collection est accessible depuis les réseaux publics, elle est également accessible depuis tous les points de terminaison VPC OpenSearch gérés sans serveur et depuis tous. Services AWS
+ Plusieurs stratégies réseau peuvent s'appliquer à une seule collection. Pour de plus amples informations, veuillez consulter [Priorité des stratégies](#serverless-network-precedence).
## Autorisations requises pour configurer les politiques réseau
L'accès réseau pour OpenSearch Serverless utilise les autorisations Gestion des identités et des accès AWS (IAM) suivantes. Vous pouvez spécifier des conditions IAM pour restreindre les utilisateurs à des stratégies réseau associées à des collections spécifiques.
+ `aoss:CreateSecurityPolicy` : créer une stratégie d'accès au réseau.
+ `aoss:ListSecurityPolicies` : répertorier toutes les stratégies réseau du compte actuel.
+ `aoss:GetSecurityPolicy` : afficher une spécification de stratégie d'accès au réseau.
+ `aoss:UpdateSecurityPolicy` : modifier une stratégie d'accès réseau donnée et modifier l'ID du VPC ou la désignation d'accès public.
+ `aoss:DeleteSecurityPolicy` : supprimer une stratégie d'accès au réseau (après l'avoir détachée de toutes les collections).
La stratégie d'accès basée sur l'identité suivante permet à un utilisateur de consulter toutes les stratégies réseau et de mettre à jour les stratégies qui contiennent le modèle de ressource `collection/application-logs` :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"aoss:UpdateSecurityPolicy"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aoss:collection": "application-logs"
}
}
},
{
"Effect": "Allow",
"Action": [
"aoss:ListSecurityPolicies",
"aoss:GetSecurityPolicy"
],
"Resource": "*"
}
]
}
```
------
**Note**
En outre, OpenSearch Serverless nécessite les `aoss:DashboardsAccessAll` autorisations `aoss:APIAccessAll` et pour les ressources de collecte. Pour de plus amples informations, veuillez consulter [Utilisation des opérations OpenSearch d'API](security-iam-serverless.md#security_iam_id-based-policy-examples-data-plane).
## Priorité des stratégies
Dans certains cas, les règles de stratégie réseau se chevauchent, au sein des stratégies ou entre elles. Dans ce cas, une règle qui spécifie l'accès public remplace une règle qui spécifie l'accès privé pour toutes les collections communes aux *deux* règles.
Par exemple, dans la stratégie suivante, les deux règles attribuent un accès réseau à la collection `finance`, mais une règle spécifie l'accès VPC tandis que l'autre spécifie l'accès public. Dans ce cas, l'accès public outrepasse l'accès VPC *uniquement pour la collection finance* (car il existe dans les deux règles), de sorte que la collection finance sera accessible depuis les réseaux publics. La collection sales (ventes) bénéficiera d'un accès VPC à partir du point de terminaison spécifié.
```
[
{
"Description":"Rule 1",
"Rules":[
{
"ResourceType":"collection",
"Resource":[
"collection/sales",
"collection/finance"
]
}
],
"AllowFromPublic":false,
"SourceVPCEs":[
"vpce-050f79086ee71ac05"
]
},
{
"Description":"Rule 2",
"Rules":[
{
"ResourceType":"collection",
"Resource":[
"collection/finance"
]
}
],
"AllowFromPublic":true
}
]
```
Si plusieurs points de terminaison d'un VPC issus de règles différentes s'appliquent à une collection, les règles s'additionnent et la collection sera accessible depuis tous les points de terminaison spécifiés. Si vous définissez `AllowFromPublic` `true` mais que vous fournissez également un ou plusieurs `SourceVPCEs` ou`SourceServices`, OpenSearch Serverless ignore les points de terminaison et les identifiants de service VPC, et les collections associées seront accessibles au public.
## Créer des stratégies réseau (console)
Les stratégies réseau peuvent s'appliquer aux collections existantes ainsi qu'aux collections futures. Nous vous recommandons de créer des stratégies réseau avant de commencer à créer des collections.
**Pour créer une politique réseau OpenSearch sans serveur**
1. Ouvrez la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home ).
1. Dans le panneau de navigation de gauche, développez **Serverless** (Sans serveur) et choisissez **Network policies** (Stratégies réseau).
1. Choisissez **Create network policy** (Créer une stratégie réseau).
1. Saisissez un nom et une description pour la stratégie.
1. Fournissez une ou plusieurs *règles*. Ces règles définissent les autorisations d'accès pour vos collections OpenSearch Serverless et leurs points de terminaison de OpenSearch Dashboards.
Chaque règle contient les éléments suivants :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-network.html)
Pour chaque type de ressource que vous sélectionnez, vous pouvez choisir des collections existantes auxquelles appliquer les paramètres de politique, and/or créer un ou plusieurs modèles de ressources. Les modèles de ressources se composent d'un préfixe et d'un caractère générique (\$1) et définissent les collections auxquelles les paramètres de stratégie s'appliqueront.
Par exemple, si vous incluez un modèle appelé `Marketing*`, les paramètres réseau de cette stratégie seront automatiquement appliqués à toutes les collections nouvelles ou existantes dont le nom commence par « Marketing ». Un seul caractère générique (`*`) applique la stratégie à toutes les collections actuelles et futures.
En outre, vous pouvez spécifier le nom d'une *future* collection sans caractère générique, par exemple`Finance`. OpenSearch Serverless appliquera les paramètres de politique à toute collection nouvellement créée portant le même nom exact.
1. Lorsque la configuration de votre stratégie vous satisfait, choisissez **Create** (Créer).
## Création de stratégies réseau (AWS CLI)
Pour créer une politique réseau à l'aide des opérations de l'API OpenSearch Serverless, vous devez spécifier des règles au format JSON. La [CreateSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateSecurityPolicy.html)demande accepte à la fois les politiques intégrées et les fichiers .json. Toutes les collections et tous les modèles doivent être sous la forme `collection/`.
**Note**
Le type de ressource autorise `dashboards` uniquement l'accès aux OpenSearch tableaux de bord, mais pour que les OpenSearch tableaux de bord fonctionnent, vous devez également autoriser l'accès aux collections à partir des mêmes sources. La deuxième stratégie ci-dessous sert d'exemple.
Pour spécifier un accès privé, incluez l'un des éléments suivants ou les deux :
+ `SourceVPCEs`— Spécifiez un ou plusieurs points de OpenSearch terminaison VPC gérés sans serveur.
+ `SourceServices`— Spécifiez l'identifiant d'un ou de plusieurs appareils pris en charge Services AWS. Actuellement, les identifiants de service suivants sont pris en charge :
+ `bedrock.amazonaws.com`— Amazon Bedrock
L'exemple de politique réseau suivant fournit un accès privé, à un point de terminaison VPC et à Amazon Bedrock, aux points de terminaison de collecte uniquement pour les collections commençant par le préfixe. `log*` Les utilisateurs authentifiés ne peuvent pas se connecter aux OpenSearch tableaux de bord ; ils ne peuvent accéder au point de terminaison de collecte que par programmation.
```
[
{
"Description":"Private access for log collections",
"Rules":[
{
"ResourceType":"collection",
"Resource":[
"collection/log*"
]
}
],
"AllowFromPublic":false,
"SourceVPCEs":[
"vpce-050f79086ee71ac05"
],
"SourceServices":[
"bedrock.amazonaws.com"
],
}
]
```
La politique suivante fournit un accès public au OpenSearch point de terminaison *et* aux OpenSearch tableaux de bord pour une seule collection nommée`finance`. Si la collection n'existe pas, les paramètres réseau seront appliqués à la collection si et quand elle sera créée.
```
[
{
"Description":"Public access for finance collection",
"Rules":[
{
"ResourceType":"dashboard",
"Resource":[
"collection/finance"
]
},
{
"ResourceType":"collection",
"Resource":[
"collection/finance"
]
}
],
"AllowFromPublic":true
}
]
```
La requête suivante crée la stratégie réseau ci-dessus :
```
aws opensearchserverless create-security-policy \
--name sales-inventory \
--type network \
--policy "[{\"Description\":\"Public access for finance collection\",\"Rules\":[{\"ResourceType\":\"dashboard\",\"Resource\":[\"collection\/finance\"]},{\"ResourceType\":\"collection\",\"Resource\":[\"collection\/finance\"]}],\"AllowFromPublic\":true}]"
```
Pour fournir la stratégie dans un fichier JSON, utilisez le format `--policy file://my-policy.json`.
## Affichage des stratégies réseau
Avant de créer une collection, vous souhaiterez peut-être prévisualiser les stratégies réseau existantes dans votre compte pour voir laquelle possède un modèle de ressource correspondant au nom de votre collection. La [ListSecurityPolicies](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_ListSecurityPolicies.html)demande suivante répertorie toutes les politiques réseau de votre compte :
```
aws opensearchserverless list-security-policies --type network
```
La requête renvoie des informations sur toutes les stratégies réseau configurées. Pour consulter les règles de modèle définies dans une politique spécifique, recherchez les informations de stratégie dans le contenu de l'`securityPolicySummaries`élément de la réponse. Notez la `name` fin `type` de cette politique et utilisez ces propriétés dans une [GetSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_GetSecurityPolicy.html)demande pour recevoir une réponse contenant les détails de politique suivants :
```
{
"securityPolicyDetail": [
{
"type": "network",
"name": "my-policy",
"policyVersion": "MTY2MzY5MTY1MDA3Ml8x",
"policy": "[{\"Description\":\"My network policy rule\",\"Rules\":[{\"ResourceType\":\"dashboard\",\"Resource\":[\"collection/*\"]}],\"AllowFromPublic\":true}]",
"createdDate": 1663691650072,
"lastModifiedDate": 1663691650072
}
]
}
```
Pour afficher des informations détaillées sur une politique spécifique, utilisez la [GetSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_GetSecurityPolicy.html)commande.
## Mettre à jour des stratégies réseau
Lorsque vous modifiez les points de terminaison d'un VPC ou la désignation d'accès public pour un réseau, toutes les collections associées sont affectées. Pour mettre à jour une politique réseau dans la console OpenSearch Serverless, développez **les politiques réseau**, sélectionnez la politique à modifier, puis choisissez **Modifier**. Effectuez vos modifications, puis cliquez sur **Enregistrer**.
Pour mettre à jour une politique réseau à l'aide de l'API OpenSearch Serverless, utilisez la [UpdateSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UpdateSecurityPolicy.html)commande. Vous devez inclure une version de stratégie dans la requête. Vous pouvez récupérer la version de stratégie à l'aide des commandes `ListSecurityPolicies` ou `GetSecurityPolicy`. En incluant la version la plus récente de la stratégie, vous vous assurez de ne pas annuler par inadvertance une modification apportée par quelqu'un d'autre.
La requête suivante met à jour une stratégie réseau avec un nouveau document JSON de stratégie :
```
aws opensearchserverless update-security-policy \
--name sales-inventory \
--type network \
--policy-version MTY2MzY5MTY1MDA3Ml8x \
--policy file://my-new-policy.json
```
## Supprimer des stratégies réseau
Avant de supprimer une stratégie réseau, vous devez la détacher de toutes les collections. Pour supprimer une politique dans la console OpenSearch Serverless, sélectionnez-la, puis choisissez **Supprimer**.
Vous pouvez également utiliser la [DeleteSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_DeleteSecurityPolicy.html)commande :
```
aws opensearchserverless delete-security-policy --name my-policy --type network
```
# Conformité à la norme FIPS dans Amazon Serverless OpenSearch
Amazon OpenSearch Serverless prend en charge les normes fédérales de traitement de l'information (FIPS) 140-2, une norme gouvernementale américaine et canadienne qui spécifie les exigences de sécurité pour les modules cryptographiques qui protègent les informations sensibles. Lorsque vous vous connectez à des points de terminaison compatibles FIPS avec OpenSearch Serverless, les opérations cryptographiques sont effectuées à l'aide de bibliothèques cryptographiques validées par FIPS.
OpenSearch Les points de terminaison FIPS sans serveur sont disponibles Régions AWS là où le protocole FIPS est pris en charge. Ces points de terminaison utilisent le protocole TLS 1.2 ou version ultérieure et des algorithmes cryptographiques validés par le protocole FIPS pour toutes les communications. Pour plus d'informations, consultez la section [Conformité à la norme FIPS](https://docs.aws.amazon.com/verified-access/latest/ug/fips-compliance.html) dans le *Guide de l'utilisateur de l'accès AWS vérifié*.
**Topics**
+ [Utilisation de points de terminaison FIPS avec Serverless OpenSearch](#using-fips-endpoints-opensearch-serverless)
+ [Utilisez les points de terminaison FIPS avec AWS SDKs](#using-fips-endpoints-aws-sdks)
+ [Configuration des groupes de sécurité pour les points de terminaison VPC](#configuring-security-groups-vpc-endpoints)
+ [Utiliser le point de terminaison VPC FIPS](#using-fips-vpc-endpoint)
+ [Vérifiez la conformité à la norme FIPS](#verifying-fips-compliance)
+ [Résoudre les problèmes de connectivité des terminaux FIPS dans les zones hébergées privées](serverless-fips-endpoint-issues.md)
## Utilisation de points de terminaison FIPS avec Serverless OpenSearch
Régions AWS Lorsque la norme FIPS est prise en charge, les collections OpenSearch sans serveur sont accessibles via des points de terminaison standard et conformes à la norme FIPS. Pour plus d'informations, consultez la section [Conformité à la norme FIPS](https://docs.aws.amazon.com/verified-access/latest/ug/fips-compliance.html) dans le *Guide de l'utilisateur de l'accès AWS vérifié*.
Dans les exemples suivants, remplacez *collection\$1id* et *Région AWS* par votre identifiant de collection et son Région AWS.
+ **Point de terminaison standard** —**https://*collection\$1id*.*Région AWS*.aoss.amazonaws.com**.
+ Point de terminaison **conforme à la norme FIPS —**. **https://*collection\$1id*.*Région AWS*.aoss-fips.amazonaws.com**
De même, les OpenSearch tableaux de bord sont accessibles via des points de terminaison standard et conformes à la norme FIPS :
+ Point de **terminaison standard des tableaux** de bord —**https://*collection\$1id*.*Région AWS*.aoss.amazonaws.com/\$1dashboards**.
+ Point de terminaison de **tableaux de bord conforme à la norme FIPS —**. **https://*collection\$1id*.*Région AWS*.aoss-fips.amazonaws.com/\$1dashboards**
**Note**
Dans les régions compatibles FIPS, les points de terminaison standard et conformes à la norme FIPS fournissent une cryptographie conforme à la norme FIPS. **Les points de terminaison spécifiques à FIPS vous aident à répondre aux exigences de conformité qui imposent spécifiquement l'utilisation de points de terminaison dont le nom est FIPS.**
## Utilisez les points de terminaison FIPS avec AWS SDKs
Lors de l'utilisation AWS SDKs, vous pouvez spécifier le point de terminaison FIPS lors de la création du client. Dans l'exemple suivant, remplacez *collection\$1id* et *Région AWS* par votre identifiant de collection et son Région AWS.
```
# Python SDK example
from opensearchpy import OpenSearch, RequestsHttpConnection, AWSV4SignerAuth
import boto3
host = '"https://collection_id.Région AWS.aoss-fips.amazonaws.com"
region = 'us-west-2'
service = 'aoss'
credentials = boto3.Session().get_credentials()
auth = AWSV4SignerAuth(credentials, region, service)
client = OpenSearch(
hosts = [{'host': host, 'port': 443}],
http_auth = auth,
use_ssl = True,
verify_certs = True,
connection_class = RequestsHttpConnection,
pool_maxsize = 20
)
```
## Configuration des groupes de sécurité pour les points de terminaison VPC
Pour garantir une communication correcte avec votre point de terminaison Amazon VPC (VPC) conforme à la norme FIPS, créez ou modifiez un groupe de sécurité afin d'autoriser le trafic HTTPS entrant (port TCP 443) en provenance des ressources de votre VPC qui doivent accéder à Serverless. OpenSearch Associez ensuite ce groupe de sécurité à votre point de terminaison VPC lors de la création ou en modifiant le point de terminaison après sa création. Pour plus d'informations, veuillez consulter [Création d'un groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html) dans le *Guide de l'utilisateur Amazon VPC*.
## Utiliser le point de terminaison VPC FIPS
Après avoir créé le point de terminaison VPC conforme à la norme FIPS, vous pouvez l'utiliser pour OpenSearch accéder à Serverless à partir des ressources de votre VPC. Pour utiliser le point de terminaison pour les opérations d'API, configurez votre SDK pour utiliser le point de terminaison FIPS régional, comme décrit dans la [Utilisation de points de terminaison FIPS avec Serverless OpenSearch](#using-fips-endpoints-opensearch-serverless) section. Pour accéder aux OpenSearch tableaux de bord, utilisez l'URL des tableaux de bord spécifique à la collection, qui sera automatiquement acheminée via le point de terminaison VPC conforme à la norme FIPS lors de l'accès depuis votre VPC. Pour de plus amples informations, veuillez consulter [Utilisation de OpenSearch tableaux de bord avec Amazon Service OpenSearch](dashboards.md).
## Vérifiez la conformité à la norme FIPS
Pour vérifier que vos connexions à OpenSearch Serverless utilisent une cryptographie conforme à la norme FIPS, utilisez-la AWS CloudTrail pour surveiller les appels d'API effectués vers Serverless. OpenSearch Vérifiez que le `eventSource` champ dans les CloudTrail journaux s'affiche `aoss-fips.amazonaws.com` pour les appels d'API.
Pour accéder aux OpenSearch tableaux de bord, vous pouvez utiliser les outils de développement du navigateur pour inspecter les détails de connexion TLS et vérifier que des suites de chiffrement conformes à la norme FIPS sont utilisées.
# Résoudre les problèmes de connectivité des terminaux FIPS dans les zones hébergées privées
Les points de terminaison FIPS fonctionnent avec les collections Amazon OpenSearch Serverless accessibles au public. Pour les collections VPC nouvellement créées qui utilisent des points de terminaison VPC nouvellement créés, les points de terminaison FIPS fonctionnent comme prévu. Pour les autres collections VPC, vous devrez peut-être effectuer une configuration manuelle pour garantir le bon fonctionnement des points de terminaison FIPS.
**Pour configurer les zones hébergées privées FIPS dans Amazon Route 53**
1. Ouvrez la console Route 53 à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Passez en revue vos zones hébergées :
1. Localisez les zones hébergées dans lesquelles se trouvent Régions AWS vos collections.
1. Vérifiez les modèles de dénomination des zones hébergées :
+ Format non FIPS :. `region.aoss.amazonaws.com`
+ Format FIPS :`region.aoss-fips.amazonaws.com`.
1. Vérifiez que le **type** de toutes vos zones hébergées est défini sur **Zone hébergée privée**.
1. Si la zone hébergée privée FIPS est absente :
1. Sélectionnez la zone hébergée privée non FIPS correspondante.
1. Copiez les VPCs informations **associées**. Par exemple : `vpc-1234567890abcdef0 | us-east-2`.
1. Trouvez l'enregistrement de domaine générique. Par exemple : `*.us-east-2.aoss.amazonaws.com`.
1. Copiez le **trafic Value/Route dans les** informations. Par exemple :`uoc1c1qsw7poexampleewjeno1pte3rw.3ym756xh7yj.aoss.searchservices.aws`.
1. Créez la zone hébergée privée FIPS :
1. Créez une nouvelle zone hébergée privée au format FIPS. Par exemple : `us-east-2.aoss-fips.amazonaws.com`.
1. Dans **Associated VPCs**, entrez les informations VPC que vous avez copiées depuis la zone hébergée privée non FIPS.
1. Ajoutez un nouvel enregistrement avec les paramètres suivants :
1. Nom de l'enregistrement : \$1
1. Type d'enregistrement : CNAME
1. Valeur : Entrez la **valeur/l'itinéraire du trafic vers** les informations que vous avez copiées précédemment.
## Problèmes courants
Si vous rencontrez des problèmes de connectivité avec vos points de terminaison VPC conformes à la norme FIPS, utilisez les informations suivantes pour résoudre le problème.
+ Défaillances de résolution DNS : vous ne pouvez pas résoudre le nom de domaine du point de terminaison FIPS au sein de votre VPC
+ Expiration des délais de connexion : le délai d'expiration de vos demandes adressées au point de terminaison FIPS
+ Erreurs d'accès refusé - L'authentification ou l'autorisation échoue lors de l'utilisation de points de terminaison FIPS
+ Enregistrements de zone hébergée privée manquants pour les collections réservées aux VPN
**Pour résoudre les problèmes de connectivité des terminaux FIPS**
1. Vérifiez la configuration de votre zone hébergée privée :
1. Vérifiez qu'une zone hébergée privée existe pour le domaine de point de terminaison FIPS (`*.region.aoss-fips.amazonaws.com`.
1. Vérifiez que la zone hébergée privée est associée au VPC approprié.
Pour plus d'informations, consultez les [sections Zones hébergées privées](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted- zones-private.html) dans le *guide du développeur Amazon Route 53* et [Gérer les noms DNS](https://docs.aws.amazon.com/vpc/latest/privatelink/manage-dns-names.html) dans le *AWS PrivateLink guide*.
1. Testez la résolution DNS :
1. Connectez-vous à une instance EC2 de votre VPC.
1. Exécutez la commande suivante :
```
nslookup collection-id.region.aoss-fips.amazonaws.com
```
1. Vérifiez que la réponse inclut l'adresse IP privée de votre point de terminaison VPC.
Pour plus d'informations, consultez les [politiques relatives aux points de terminaison](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints- access.html#endpoint-dns-verification) et [les attributs DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc- dns-troubleshooting) dans le guide de l'*utilisateur Amazon VPC*.
1. Vérifiez les paramètres de votre groupe de sécurité :
1. Vérifiez que le groupe de sécurité attaché au point de terminaison VPC autorise le trafic HTTPS (port 443) provenant de vos ressources.
1. Vérifiez que les groupes de sécurité de vos ressources autorisent le trafic sortant vers le point de terminaison VPC.
Pour plus d'informations, consultez [les politiques relatives aux terminaux](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#vpc-endpoint-security-groups) dans le *AWS PrivateLink guide* et les [groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#SecurityGroupRules) dans le guide de l'*utilisateur Amazon VPC*.
1. Vérifiez la configuration de votre ACL réseau :
1. Vérifiez que le réseau ACLs autorise le trafic entre vos ressources et le point de terminaison VPC.
Pour plus d'informations, consultez la section [Réseau ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network- acls.html#nacl-troubleshooting) dans le guide de l'*utilisateur Amazon VPC*.
1. Passez en revue votre politique en matière de terminaux :
1. Vérifiez que la politique de point de terminaison VPC autorise les actions requises sur vos ressources OpenSearch sans serveur.
*Pour plus d'informations, consultez les sections [Autorisations de point de terminaison VPC requises](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vpc.html#serverless-vpc-permissions) et [Politiques relatives aux points de terminaison dans le Guide](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints- access.html#vpc-endpoint-policies).AWS PrivateLink *
**Astuce**
Si vous utilisez des résolveurs DNS personnalisés dans votre VPC, configurez-les `*.amazonaws.com` pour transmettre les demandes de domaines aux AWS serveurs.
# Contrôle d'accès aux données pour Amazon OpenSearch Serverless
Grâce au contrôle d'accès aux données dans Amazon OpenSearch Serverless, vous pouvez autoriser les utilisateurs à accéder aux collections et aux index, quel que soit leur mécanisme d'accès ou leur source réseau. Vous pouvez accorder l'accès aux rôles IAM et aux [identités SAML](serverless-saml.md).
Vous gérez les autorisations d'accès par le biais de *stratégies d'accès aux données*, qui s'appliquent aux collections et aux ressources d'index. Les stratégies d'accès aux données vous permettent de gérer les collections à grande échelle en attribuant automatiquement des autorisations d'accès aux collections et aux index qui correspondent à un modèle spécifique. Plusieurs stratégies d'accès aux données peuvent s'appliquer à une seule ressource. Notez que vous devez disposer d'une politique d'accès aux données pour votre collection afin d'accéder à l'URL de vos OpenSearch tableaux de bord.
**Topics**
+ [Stratégies d'accès aux données ou politiques IAM](#serverless-data-access-vs-iam)
+ [Autorisations IAM requises pour configurer les politiques d'accès aux données](#serverless-data-access-permissions)
+ [Syntaxe d’une politique](#serverless-data-access-syntax)
+ [Autorisations de stratégies prises en charge](#serverless-data-supported-permissions)
+ [Exemples de jeux de données sur les tableaux de bord OpenSearch](#serverless-data-sample-index)
+ [Création de stratégies d'accès aux données (console)](#serverless-data-access-console)
+ [Créer des stratégies d'accès aux données (AWS CLI)](#serverless-data-access-cli)
+ [Afficher les stratégies d'accès aux données](#serverless-data-access-list)
+ [Mettre à jour les stratégies d'accès aux données](#serverless-data-access-update)
+ [Supprimer des stratégies d'accès aux données](#serverless-data-access-delete)
+ [Accès aux données entre comptes](#serverless-data-access-cross)
## Stratégies d'accès aux données ou politiques IAM
Les politiques d'accès aux données sont logiquement distinctes des politiques Gestion des identités et des accès AWS (IAM). Les autorisations IAM contrôlent l'accès aux [opérations d'API sans serveur](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/Welcome.html), telles que `CreateCollection` et `ListAccessPolicies`. Les politiques d'accès aux données contrôlent l'accès aux [OpenSearch opérations prises](#serverless-data-supported-permissions) en charge par OpenSearch Serverless, telles que `PUT ` ou`GET _cat/indices`.
Les autorisations IAM qui contrôlent l'accès aux opérations d'API de stratégie d'accès aux données, telles que `aoss:CreateAccessPolicy` et `aoss:GetAccessPolicy` (décrites dans la section suivante), n'affectent pas l'autorisation spécifiée dans une stratégie d'accès aux données.
Supposons, par exemple, qu'une politique IAM empêche un utilisateur de créer des stratégies d'accès aux données pour `collection-a`, mais lui permette de créer des stratégies d'accès aux données pour toutes les collections (`*`) :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"aoss:CreateAccessPolicy"
],
"Resource": "*",
"Condition": {
"StringLike": {
"aoss:collection": "collection-a"
}
}
},
{
"Effect": "Allow",
"Action": [
"aoss:CreateAccessPolicy"
],
"Resource": "*"
}
]
}
```
------
Si l'utilisateur crée une stratégie d'accès aux données qui autorise certaines autorisations pour *toutes* les collections (`collection/*` ou `index/*/*`), la stratégie s'appliquera à toutes les collections, y compris la collection A.
**Important**
L'octroi d'autorisations dans le cadre d'une politique d'accès aux données n'est pas suffisant pour accéder aux données de votre collection OpenSearch Serverless. Un principal associé doit *également* avoir accès aux autorisations IAM `aoss:APIAccessAll` et`aoss:DashboardsAccessAll`. Les deux autorisations accordent un accès complet aux ressources de collection, tandis que l'autorisation Dashboards donne également accès aux OpenSearch Dashboards. Si un principal ne dispose pas de ces deux autorisations IAM, il recevra 403 erreurs lorsqu'il tentera d'envoyer des demandes à la collection. Pour de plus amples informations, veuillez consulter [Utilisation des opérations OpenSearch d'API](security-iam-serverless.md#security_iam_id-based-policy-examples-data-plane).
## Autorisations IAM requises pour configurer les politiques d'accès aux données
Le contrôle d'accès aux données pour OpenSearch Serverless utilise les autorisations IAM suivantes. Vous pouvez spécifier des conditions IAM pour restreindre les utilisateurs à des noms de stratégie d'accès spécifiques.
+ `aoss:CreateAccessPolicy` : créer une stratégie d'accès.
+ `aoss:ListAccessPolicies` : répertorier toutes les stratégies d'accès.
+ `aoss:GetAccessPolicy` : afficher les informations relatives à une stratégie d'accès spécifique.
+ `aoss:UpdateAccessPolicy` : modifier une stratégie d'accès.
+ `aoss:DeleteAccessPolicy` : supprimer une stratégie d'accès.
La stratégie d'accès basée sur l'identité suivante permet à un utilisateur de consulter toutes les stratégies d'accès et de mettre à jour les stratégies qui contiennent le modèle de ressource `collection/logs`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"aoss:ListAccessPolicies",
"aoss:GetAccessPolicy"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"aoss:UpdateAccessPolicy"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"aoss:collection": [
"logs"
]
}
}
}
]
}
```
------
**Note**
En outre, OpenSearch Serverless nécessite les `aoss:DashboardsAccessAll` autorisations `aoss:APIAccessAll` et pour les ressources de collecte. Pour de plus amples informations, veuillez consulter [Utilisation des opérations OpenSearch d'API](security-iam-serverless.md#security_iam_id-based-policy-examples-data-plane).
## Syntaxe d’une politique
Une stratégie d'accès aux données inclut un jeu de règles, chacune avec les éléments suivants :
| Element | Description |
| --- | --- |
| ResourceType | Type de ressource (collection ou index) auquel les autorisations s'appliquent. Les autorisations relatives aux alias et aux modèles se situent au niveau de la collection, tandis que les autorisations de création, de modification et de recherche de données se situent au niveau de l'index. Pour plus d'informations, veuillez consulter la rubrique [Autorisations de stratégie prises en charge](#serverless-data-supported-permissions). |
| Resource | Liste de and/or modèles de noms de ressources. Les modèles sont des préfixes suivis d'un caractère générique (\$1), qui permettent aux autorisations associées de s'appliquer à plusieurs ressources.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-data-access.html) |
| Permission | Liste d'autorisations à accorder pour les ressources spécifiées. Pour obtenir une liste complète des autorisations et des opérations d'API qu'elles autorisent, veuillez consulter la rubrique [Opérations et autorisations d' OpenSearch API prises en charge](serverless-genref.md#serverless-operations). |
| Principal | Liste d'un ou de plusieurs principaux auxquels accorder l'accès. Les principaux peuvent être un rôle IAM ARNs ou des identités SAML. Ces principaux doivent se trouver au sein du Compte AWS actuel. Les politiques d'accès aux données ne prennent pas directement en charge l'accès entre comptes, mais vous pouvez inclure dans votre politique un rôle qu'un utilisateur d'un autre compte Compte AWS peut assumer dans le compte propriétaire de la collection. Pour de plus amples informations, veuillez consulter [Accès aux données entre comptes](#serverless-data-access-cross). |
L'exemple de stratégie suivant accorde des autorisations d'alias et de modèle à la collection nommée `autopartsinventory`, ainsi qu'à toutes les collections commençant par le préfixe `sales*`. Il accorde également des autorisations de lecture et d'écriture à tous les index de la collection `autopartsinventory`, ainsi qu'à tous les index de la collection `salesorders` commençant par le préfixe `orders*`.
```
[
{
"Description": "Rule 1",
"Rules":[
{
"ResourceType":"collection",
"Resource":[
"collection/autopartsinventory",
"collection/sales*"
],
"Permission":[
"aoss:CreateCollectionItems",
"aoss:UpdateCollectionItems",
"aoss:DescribeCollectionItems"
]
},
{
"ResourceType":"index",
"Resource":[
"index/autopartsinventory/*",
"index/salesorders/orders*"
],
"Permission":[
"aoss:*"
]
}
],
"Principal":[
"arn:aws:iam::123456789012:user/Dale",
"arn:aws:iam::123456789012:role/RegulatoryCompliance",
"saml/123456789012/myprovider/user/Annie",
"saml/123456789012/anotherprovider/group/Accounting"
]
}
]
```
Vous ne pouvez pas refuser explicitement l'accès dans le cadre d'une stratégie. Par conséquent, toutes les autorisations de stratégies sont cumulatives. Par exemple, si une stratégie accorde à un utilisateur `aoss:ReadDocument` et qu'une autre stratégie accorde `aoss:WriteDocument`, l'utilisateur disposera des *deux* autorisations. Si une troisième stratégie accorde au même utilisateur `aoss:*`, celui-ci peut effectuer *toutes* les actions sur l'index associé. Les autorisations plus restrictives ne remplacent pas les autorisations moins restrictives.
## Autorisations de stratégies prises en charge
Les autorisations suivantes sont prises en charge dans les stratégies d'accès aux données. Pour les opérations OpenSearch d'API autorisées par chaque autorisation, consultez[Opérations et autorisations d' OpenSearch API prises en charge](serverless-genref.md#serverless-operations).
**Autorisations de collection**
+ `aoss:CreateCollectionItems`
+ `aoss:DeleteCollectionItems`
+ `aoss:UpdateCollectionItems`
+ `aoss:DescribeCollectionItems`
+ `aoss:*`
**Autorisations d'index**
+ `aoss:ReadDocument`
+ `aoss:WriteDocument`
+ `aoss:CreateIndex`
+ `aoss:DeleteIndex`
+ `aoss:UpdateIndex`
+ `aoss:DescribeIndex`
+ `aoss:*`
## Exemples de jeux de données sur les tableaux de bord OpenSearch
OpenSearch Les tableaux de bord fournissent des [exemples de jeux](https://opensearch.org/docs/latest/dashboards/quickstart-dashboards/#adding-sample-data) de données accompagnés de visualisations, de tableaux de bord et d'autres outils pour vous aider à explorer les tableaux de bord avant d'ajouter vos propres données. Pour créer des index à partir de ces exemples de données, vous avez besoin d'une politique d'accès aux données qui fournit des autorisations pour l'ensemble de données avec lequel vous souhaitez travailler. La politique suivante utilise un caractère générique (`*`) pour fournir des autorisations aux trois exemples de jeux de données.
```
[
{
"Rules": [
{
"Resource": [
"index//opensearch_dashboards_sample_data_*"
],
"Permission": [
"aoss:CreateIndex",
"aoss:DescribeIndex",
"aoss:ReadDocument"
],
"ResourceType": "index"
}
],
"Principal": [
"arn:aws:iam:::user/"
]
}
]
```
## Création de stratégies d'accès aux données (console)
Vous pouvez créer une stratégie d'accès aux données à l'aide de l'éditeur visuel ou au format JSON. Toutes les nouvelles collections correspondant à l'un des modèles définis dans la stratégie se verront attribuer les autorisations correspondantes lors de la création de la collection.
**Pour créer une politique d'accès aux données OpenSearch sans serveur**
1. Ouvrez la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home ).
1. Dans le volet de navigation de gauche, développez **Serverless** et sous **Sécurité**, choisissez **Politiques d'accès aux données**.
1. Choisissez **Create access policy** (Créer une stratégie d'accès).
1. Saisissez un nom et une description pour la stratégie.
1. Saisissez un nom pour la première règle de votre stratégie. Par exemple, « Accès à la collection de journaux ».
1. Choisissez **Add principals** (Ajouter des principaux) et sélectionnez un ou plusieurs rôles IAM ou [utilisateurs et groupes SAML](serverless-saml.md) pour accorder l'accès aux données.
**Note**
Pour sélectionner des principaux dans les menus déroulants, vous devez disposer des autorisations `iam:ListUsers` et `iam:ListRoles` (pour les principaux IAM) et de l'autorisation `aoss:ListSecurityConfigs` (pour les identités SAML).
1. Choisissez **Grant** (Accorder) et sélectionnez les autorisations d'alias, de modèle et d'index à accorder aux principaux associés. Pour obtenir la liste complète des autorisations et des accès qu'elles octroient, veuillez consulter la rubrique [Opérations et autorisations d' OpenSearch API prises en charge](serverless-genref.md#serverless-operations).
1. (Facultatif) Configurez des règles supplémentaires pour la stratégie.
1. Choisissez **Créer**. Il peut s'écouler environ une minute entre le moment où vous créez la stratégie et le moment où les autorisations sont appliquées. Si cela prend plus de 5 minutes, contactez [Support](https://console.aws.amazon.com/support/home).
**Important**
Si votre stratégie ne comprend que des autorisations d'index (et aucune autorisation de collection), vous pouvez toujours recevoir un message pour les collections correspondantes indiquant `Collection cannot be accessed yet. Configure data access policies so that users can access the data within this collection`. Vous pouvez ignorer cet avertissement. Les principaux autorisés peuvent toujours effectuer les opérations liées à l'index qui leur sont attribuées sur la collection.
## Créer des stratégies d'accès aux données (AWS CLI)
Pour créer une politique d'accès aux données à l'aide de l'API OpenSearch Serverless, utilisez la `CreateAccessPolicy` commande. La commande accepte à la fois les stratégies en ligne et les fichiers .json. Les stratégies en ligne doivent être codées sous la forme d'une [chaîne d'échappement JSON](https://www.freeformatter.com/json-escape.html).
La requête suivante crée une stratégie d'accès aux données :
```
aws opensearchserverless create-access-policy \
--name marketing \
--type data \
--policy "[{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection/autopartsinventory\",\"collection/sales*\"],\"Permission\":[\"aoss:UpdateCollectionItems\"]},{\"ResourceType\":\"index\",\"Resource\":[\"index/autopartsinventory/*\",\"index/salesorders/orders*\"],\"Permission\":[\"aoss:ReadDocument\",\"aoss:DescribeIndex\"]}],\"Principal\":[\"arn:aws:iam::123456789012:user/Shaheen\"]}]"
```
Pour fournir la stratégie dans un fichier .json, utilisez le format `--policy file://my-policy.json`.
Les principaux inclus dans la politique peuvent désormais utiliser les [OpenSearch opérations](#serverless-data-supported-permissions) auxquelles ils ont été autorisés à accéder.
## Afficher les stratégies d'accès aux données
Avant de créer une collection, vous souhaiterez peut-être prévisualiser les stratégies d'accès aux données existantes dans votre compte pour voir laquelle possède un modèle de ressource correspondant au nom de votre collection. La [ListAccessPolicies](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_ListAccessPolicies.html)demande suivante répertorie toutes les politiques d'accès aux données de votre compte :
```
aws opensearchserverless list-access-policies --type data
```
La requête renvoie des informations sur toutes les stratégies d'accès aux données configurées. Pour consulter les règles de modèle définies dans une politique spécifique, recherchez les informations de stratégie dans le contenu de l'`accessPolicySummaries`élément de la réponse. Notez la `name` fin `type` de cette politique et utilisez ces propriétés dans une [GetAccessPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_GetAccessPolicy.html)demande pour recevoir une réponse contenant les détails de politique suivants :
```
{
"accessPolicyDetails": [
{
"type": "data",
"name": "my-policy",
"policyVersion": "MTY2NDA1NDE4MDg1OF8x",
"description": "My policy",
"policy": "[{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection/autopartsinventory\",\"collection/sales*\"],\"Permission\":[\"aoss:UpdateCollectionItems\"]},{\"ResourceType\":\"index\",\"Resource\":[\"index/autopartsinventory/*\",\"index/salesorders/orders*\"],\"Permission\":[\"aoss:ReadDocument\",\"aoss:DescribeIndex\"]}],\"Principal\":[\"arn:aws:iam::123456789012:user/Shaheen\"]}]",
"createdDate": 1664054180858,
"lastModifiedDate": 1664054180858
}
]
}
```
Vous pouvez inclure des filtres de ressources pour limiter les résultats aux stratégies contenant des collections ou des index spécifiques :
```
aws opensearchserverless list-access-policies --type data --resource "index/autopartsinventory/*"
```
Pour afficher les détails d'une politique spécifique, utilisez la [GetAccessPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_GetAccessPolicy.html)commande.
## Mettre à jour les stratégies d'accès aux données
Lorsque vous mettez à jour une stratégie d'accès aux données, toutes les collections associées sont affectées. Pour mettre à jour une politique d'accès aux données dans la console OpenSearch Serverless, choisissez **Contrôle d'accès aux données**, sélectionnez la politique à modifier, puis choisissez **Modifier**. Effectuez vos modifications, puis cliquez sur **Enregistrer**.
Pour mettre à jour une politique d'accès aux données à l'aide de l'API OpenSearch Serverless, envoyez une `UpdateAccessPolicy` demande. Vous devez inclure une version de la stratégie, que vous pouvez récupérer à l'aide des commandes `ListAccessPolicies` ou `GetAccessPolicy`. En incluant la version la plus récente de la stratégie, vous vous assurez de ne pas annuler par inadvertance une modification apportée par quelqu'un d'autre.
La [UpdateAccessPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UpdateAccessPolicy.html)demande suivante met à jour une politique d'accès aux données avec un nouveau document JSON de politique :
```
aws opensearchserverless update-access-policy \
--name sales-inventory \
--type data \
--policy-version MTY2NDA1NDE4MDg1OF8x \
--policy file://my-new-policy.json
```
Il peut s'écouler quelques minutes entre le moment où vous mettez à jour la stratégie et le moment où les nouvelles autorisations sont appliquées.
## Supprimer des stratégies d'accès aux données
Lorsque vous supprimez une stratégie d'accès aux données, toutes les collections associées perdent l'accès défini dans la stratégie. Assurez-vous que vos utilisateurs IAM et SAML disposent de l'accès approprié à la collection avant de supprimer une stratégie. Pour supprimer une politique dans la console OpenSearch Serverless, sélectionnez-la, puis choisissez **Supprimer**.
Vous pouvez également utiliser la [DeleteAccessPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_DeleteAccessPolicy.html)commande :
```
aws opensearchserverless delete-access-policy --name my-policy --type data
```
## Accès aux données entre comptes
Bien que vous ne puissiez pas créer de politique d'accès aux données avec une identité entre comptes ou des collections entre comptes, vous pouvez toujours configurer un accès entre comptes avec l'option assumer un rôle. Par exemple, s'il `account-a` possède une collection à laquelle il `account-b` faut accéder, l'utilisateur de `account-b` peut jouer un rôle dans`account-a`. Le rôle doit disposer des autorisations IAM `aoss:APIAccessAll` et `aoss:DashboardsAccessAll` être inclus dans la politique d'accès aux données sur`account-a`.
# Accès au plan de données via AWS PrivateLink
Amazon OpenSearch Serverless prend en charge deux types de AWS PrivateLink connexions pour les opérations du plan de contrôle et du plan de données. Les opérations du plan de contrôle incluent la création et la suppression de collections ainsi que la gestion des politiques d'accès. Les opérations du plan de données servent à indexer et à interroger des données au sein d'une collection. Cette page couvre les points de terminaison VPC du plan de données. Pour plus d'informations sur les AWS PrivateLink extrémités du plan de contrôle, consultez[Accès au plan de contrôle via AWS PrivateLink](serverless-vpc-cp.md).
Vous pouvez l'utiliser AWS PrivateLink pour créer une connexion privée entre votre VPC et Amazon OpenSearch Serverless. Vous pouvez accéder à OpenSearch Serverless comme s'il se trouvait dans votre VPC, sans utiliser de passerelle Internet, de périphérique NAT, de connexion VPN ou de connexion. Direct Connect Les instances de votre VPC n'ont pas besoin d'adresses IP publiques pour accéder OpenSearch à Serverless. Pour plus d'informations sur l'accès au réseau VPC, consultez [Modèles de connectivité réseau pour Amazon OpenSearch Serverless](https://aws.amazon.com/blogs/big-data/network-connectivity-patterns-for-amazon-opensearch-serverless/).
Vous établissez cette connexion privée en créant un *point de terminaison d'interface* à technologie AWS PrivateLink. Nous créons une interface réseau du point de terminaison dans chaque sous-réseau que vous spécifiez pour le point de terminaison d'interface. Il s'agit d'interfaces réseau gérées par les demandeurs qui servent de point d'entrée pour le trafic destiné OpenSearch à Serverless.
Pour plus d’informations, consultez [Accès aux Services AWS via AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) dans le *Guide AWS PrivateLink *.
**Topics**
+ [Résolution DNS des points de terminaison de collecte](#vpc-endpoint-dnc)
+ [VPCs et politiques d'accès au réseau](#vpc-endpoint-network)
+ [VPCs et politiques relatives aux terminaux](#vpc-endpoint-policy)
+ [Considérations](#vpc-endpoint-considerations)
+ [Autorisations nécessaires](#serverless-vpc-permissions)
+ [Création d'un point de terminaison d'interface pour OpenSearch Serverless](#serverless-vpc-create)
+ [Configuration d'un VPC partagé pour Amazon Serverless OpenSearch](#shared-vpc-setup)
## Résolution DNS des points de terminaison de collecte
Lorsque vous créez un point de terminaison VPC de plan de données via la console OpenSearch Serverless, le service crée une nouvelle [zone hébergée Amazon Route 53 privée](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) et l'attache au VPC. Cette zone hébergée privée consiste en un enregistrement permettant de résoudre l'enregistrement DNS générique pour les collections OpenSearch sans serveur (`*.us-east-1.aoss.amazonaws.com`) aux adresses d'interface utilisées pour le point de terminaison. Vous n'avez besoin que d'un point de terminaison VPC OpenSearch sans serveur dans un VPC pour accéder à toutes les collections et à tous les tableaux de bord de chaque VPC. Région AWS Chaque VPC doté d'un point de terminaison pour OpenSearch Serverless possède sa propre zone hébergée privée attachée.
Le point de terminaison de l'interface OpenSearch sans serveur crée également un enregistrement DNS générique Route 53 public pour toutes les collections de la région. Le nom DNS correspond aux adresses IP publiques OpenSearch sans serveur. Les clients VPCs qui ne disposent pas d'un point de terminaison VPC OpenSearch sans serveur ou les clients des réseaux publics peuvent utiliser le résolveur Route 53 public et accéder aux collections et aux tableaux de bord avec ces adresses IP. Le type d'adresse IP (IPv4 IPv6, ou Dualstack) du point de terminaison VPC est déterminé en fonction des sous-réseaux fournis lorsque vous [créez un](#serverless-vpc-create) point de terminaison d'interface pour Serverless. OpenSearch
**Note**
OpenSearch Serverless crée une zone hébergée privée Amazon Route 53 supplémentaire ``.opensearch.amazonaws.com` (`) pour la résolution OpenSearch d'un domaine de service. Vous pouvez mettre à jour votre point de terminaison IPv4 VPC existant vers Dualstack en utilisant la commande du [update-vpc-endpoint](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/update-vpc-endpoint.html). AWS CLI
L'adresse du résolveur DNS pour un VPC donné est la deuxième adresse IP du CIDR du VPC. Tout client du VPC doit utiliser ce résolveur pour obtenir l'adresse du point de terminaison du VPC pour toute collection. Le résolveur utilise une zone hébergée privée créée par OpenSearch Serverless. Il suffit d'utiliser ce résolveur pour toutes les collections, quel que soit le compte. Il est également possible d'utiliser le résolveur VPC pour certains points de terminaison de collection et le résolveur public pour d'autres, bien que cela ne soit généralement pas nécessaire.
## VPCs et politiques d'accès au réseau
Pour accorder des autorisations réseau OpenSearch APIs et des tableaux de bord pour vos collections, vous pouvez utiliser des politiques d'[accès réseau OpenSearch ](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-network.html) sans serveur. Vous pouvez contrôler cet accès réseau à partir de vos points de terminaison VPC ou de l'Internet public. Étant donné que votre politique réseau ne contrôle que les autorisations de trafic, vous devez également définir une [politique d'accès aux données](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-data-access.html) qui spécifie l'autorisation d'opérer sur les données d'une collection et de ses index. Imaginez un point de terminaison VPC OpenSearch sans serveur comme un point d'accès au service, une politique d'accès réseau comme le point d'accès au niveau du réseau aux collections et aux tableaux de bord, et une politique d'accès aux données comme le point d'accès permettant un contrôle d'accès précis pour toute opération sur les données de la collection.
Comme vous pouvez spécifier plusieurs points de terminaison VPC IDs dans une politique réseau, nous vous recommandons de créer un point de terminaison VPC pour chaque VPC devant accéder à une collection. Ils VPCs peuvent appartenir à des AWS comptes différents de ceux du compte propriétaire de la collection OpenSearch Serverless et de la politique réseau. Nous vous déconseillons de créer une solution de VPC-to-VPC peering ou autre solution de proxy entre deux comptes afin que le VPC d'un compte puisse utiliser le point de terminaison VPC d'un autre compte. Cela est moins sûr et moins rentable que le fait que chaque VPC possède son propre point de terminaison. Le premier VPC ne sera pas facilement visible pour l'administrateur de l'autre VPC, qui a configuré l'accès au point de terminaison de ce VPC dans la politique réseau.
## VPCs et politiques relatives aux terminaux
Amazon OpenSearch Serverless prend en charge les politiques relatives aux terminaux pour VPCs. Une politique de point de terminaison est une politique basée sur les ressources IAM que vous attachez à un point de terminaison VPC pour contrôler quels AWS principaux peuvent utiliser le point de terminaison pour accéder à votre service. AWS Pour plus d'informations, consultez [Contrôler l'accès aux points de terminaison VPC à l'aide de politiques de point de terminaison](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html).
Pour utiliser une politique de point de terminaison, vous devez d'abord créer un point de terminaison d'interface. Vous pouvez créer un point de terminaison d'interface à l'aide de la console OpenSearch Serverless ou de l'API OpenSearch Serverless. Après avoir créé le point de terminaison de votre interface, vous devez ajouter la politique du point de terminaison au point de terminaison. Pour de plus amples informations, veuillez consulter [Création d'un point de terminaison d'interface pour OpenSearch Serverless](#serverless-vpc-create).
**Note**
Vous ne pouvez pas définir une politique de point de terminaison directement dans la console OpenSearch de service.
Une politique de point de terminaison ne remplace ni ne remplace les autres politiques basées sur l'identité, les politiques basées sur les ressources, les politiques réseau ou les politiques d'accès aux données que vous avez éventuellement configurées. Pour plus d'informations sur la mise à jour des politiques de point de terminaison, consultez [Contrôler l'accès aux points de terminaison VPC à l'aide de politiques de point de terminaison](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html).
Par défaut, une politique de point de terminaison accorde un accès complet à votre point de terminaison VPC.
```
{
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*"
}
]
}
```
Bien que la politique de point de terminaison VPC par défaut accorde un accès complet au point de terminaison, vous pouvez configurer une politique de point de terminaison VPC pour autoriser l'accès à des rôles et à des utilisateurs spécifiques. Pour ce faire, consultez l'exemple suivant :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"123456789012",
"987654321098"
]
},
"Action": "*",
"Resource": "*"
}
]
}
```
------
Vous pouvez spécifier une collection OpenSearch sans serveur à inclure en tant qu'élément conditionnel dans votre politique de point de terminaison VPC. Pour ce faire, consultez l'exemple suivant :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aoss:collection": [
"coll-abc"
]
}
}
}
]
}
```
------
Support pour `aoss:CollectionId` est pris en charge.
```
Condition": {
"StringEquals": {
"aoss:CollectionId": "collection-id"
}
}
```
Vous pouvez utiliser les identités SAML dans votre politique de point de terminaison VPC pour déterminer l'accès aux points de terminaison VPC. Vous devez utiliser un caractère générique `(*)` dans la section principale de votre politique de point de terminaison VPC. Pour ce faire, consultez l'exemple suivant :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"saml:cn": [
"saml/111122223333/idp123/group/football",
"saml/111122223333/idp123/group/soccer",
"saml/111122223333/idp123/group/cricket"
]
}
}
}
]
}
```
------
En outre, vous pouvez configurer votre politique de point de terminaison pour inclure une politique principale SAML spécifique. Pour ce faire, consultez les informations suivantes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/Department": [
"Engineering"]
}
}
}
]
}
```
------
Pour plus d'informations sur l'utilisation de l'authentification SAML avec Amazon OpenSearch Serverless, consultez Authentification [SAML pour Amazon](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-saml.html) Serverless. OpenSearch
Vous pouvez également inclure les utilisateurs IAM et SAML dans la même politique de point de terminaison VPC. Pour ce faire, consultez l'exemple suivant :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"saml:cn": [
"saml/111122223333/idp123/group/football",
"saml/111122223333/idp123/group/soccer",
"saml/111122223333/idp123/group/cricket"
]
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": "*",
"Resource": "*"
}
]
}
```
------
Vous pouvez également accéder à une collection Amazon OpenSearch Serverless depuis Amazon EC2 via des points de terminaison VPC d'interface. Pour plus d'informations, consultez [Accéder à une collection OpenSearch sans serveur depuis Amazon EC2 (via des points de terminaison VPC d'interface)](https://aws.amazon.com/blogs/big-data/network-connectivity-patterns-for-amazon-opensearch-serverless/).
## Considérations
Avant de configurer un point de terminaison d'interface pour OpenSearch Serverless, tenez compte des points suivants :
+ OpenSearch Serverless permet d'appeler toutes les opérations d'[OpenSearch API prises en charge (et non les opérations](serverless-genref.md#serverless-operations) d'API de configuration) via le point de terminaison de l'interface.
+ Après avoir créé un point de terminaison d'interface pour OpenSearch Serverless, vous devez toujours l'inclure dans [les politiques d'accès au réseau](serverless-network.md) afin qu'il puisse accéder aux collections sans serveur.
+ Par défaut, l'accès complet à OpenSearch Serverless est autorisé via le point de terminaison de l'interface. Vous pouvez associer un groupe de sécurité aux interfaces réseau du point de terminaison pour contrôler le trafic vers OpenSearch Serverless via le point de terminaison de l'interface.
+ Un seul Compte AWS peut avoir un maximum de 50 points de terminaison VPC OpenSearch sans serveur.
+ Si vous activez l'accès Internet public à l'API ou aux tableaux de bord de votre collection dans le cadre d'une politique réseau, votre collection est accessible par n'importe quel VPC et par Internet public.
+ Si vous êtes sur site et en dehors du VPC, vous ne pouvez pas utiliser directement un résolveur DNS pour la résolution des points de terminaison du VPC OpenSearch sans serveur. Si vous avez besoin d'un accès VPN, le VPC a besoin d'un résolveur de proxy DNS que les clients externes peuvent utiliser. Route 53 fournit une option de point de terminaison entrant que vous pouvez utiliser pour résoudre les requêtes DNS adressées à votre VPC à partir de votre réseau local ou d'un autre VPC.
+ La zone hébergée privée que OpenSearch Serverless crée et attache au VPC est gérée par le service, mais elle apparaît dans Amazon Route 53 vos ressources et est facturée à votre compte.
+ Pour d'autres considérations, veuillez consulter les [Considérations](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) dans le *Guide AWS PrivateLink *.
## Autorisations nécessaires
L'accès VPC pour OpenSearch Serverless utilise les autorisations Gestion des identités et des accès AWS (IAM) suivantes. Vous pouvez spécifier des conditions IAM pour restreindre les utilisateurs à des collections spécifiques.
+ `aoss:CreateVpcEndpoint` : créer un point de terminaison d'un VPC.
+ `aoss:ListVpcEndpoints` : répertorier tous les points de terminaison d'un VPC.
+ `aoss:BatchGetVpcEndpoint` : consulter les détails d'un sous-ensemble de points de terminaison d'un VPC.
+ `aoss:UpdateVpcEndpoint` : modifier un point de terminaison d'un VPC.
+ `aoss:DeleteVpcEndpoint` : supprimer un point de terminaison d'un VPC.
En outre, vous devez disposer des autorisations Amazon EC2 et Route 53 suivantes pour créer un point de terminaison d'un VPC.
+ `ec2:CreateTags`
+ `ec2:CreateVpcEndpoint`
+ `ec2:DeleteVpcEndPoints`
+ `ec2:DescribeSecurityGroups`
+ `ec2:DescribeSubnets`
+ `ec2:DescribeVpcEndpoints`
+ `ec2:DescribeVpcs`
+ `ec2:ModifyVpcEndPoint`
+ `route53:AssociateVPCWithHostedZone`
+ `route53:ChangeResourceRecordSets`
+ `route53:CreateHostedZone`
+ `route53:DeleteHostedZone`
+ `route53:GetChange`
+ `route53:GetHostedZone`
+ `route53:ListHostedZonesByName`
+ `route53:ListHostedZonesByVPC`
+ `route53:ListResourceRecordSets`
## Création d'un point de terminaison d'interface pour OpenSearch Serverless
Vous pouvez créer un point de terminaison d'interface pour OpenSearch Serverless à l'aide de la console ou de l'API OpenSearch Serverless.
**Pour créer un point de terminaison d'interface pour une OpenSearch collection sans serveur**
1. Ouvrez la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home).
1. Dans le panneau de navigation de gauche, développez **Serverless** (Sans serveur) et choisissez **VPC endpoints** (Points de terminaison d'un VPC).
1. Choisissez **Create VPC endpoint** (Créer un point de terminaison d'un VPC).
1. Saisissez un nom pour le point de terminaison.
1. Pour le **VPC**, sélectionnez le VPC à partir duquel vous allez accéder sans serveur. OpenSearch
1. Pour les **sous-réseaux**, sélectionnez un sous-réseau à partir duquel vous accéderez OpenSearch sans serveur.
+ L'adresse IP et le type DNS du point de terminaison sont basés sur le type de sous-réseau
+ Dualstack : si tous les sous-réseaux ont à la fois IPv4 des plages d'adresses IPv6
+ IPv6: si tous les sous-réseaux IPv6 ne sont que des sous-réseaux
+ IPv4: si tous les sous-réseaux ont des plages d' IPv4 adresses
1. Pour **Security groups** (Groupes de sécurité), sélectionnez les groupes de sécurité à associer aux interfaces réseau du point de terminaison. Il s'agit d'une étape critique qui vous permet de limiter les ports, les protocoles et les sources de trafic entrant que vous autorisez sur votre terminal. Assurez-vous que les règles du groupe de sécurité autorisent les ressources qui utiliseront le point de terminaison VPC pour communiquer avec OpenSearch Serverless à communiquer avec l'interface réseau du point de terminaison.
1. Choisissez **Créer un point de terminaison**.
Pour créer un point de terminaison VPC à l'aide de l'API OpenSearch Serverless, utilisez la commande. `CreateVpcEndpoint`
**Note**
Après avoir créé un point de terminaison, prenez note de son ID (par exemple, `vpce-abc123def4EXAMPLE`). Afin de fournir au point de terminaison un accès à vos collections, vous devez inclure cet ID dans une ou plusieurs stratégies d'accès réseau.
Après avoir créé un point de terminaison d'interface, vous devez lui donner accès aux collections par le biais de stratégies d'accès réseau. Pour de plus amples informations, veuillez consulter [Accès au réseau pour Amazon OpenSearch Serverless](serverless-network.md).
## Configuration d'un VPC partagé pour Amazon Serverless OpenSearch
Vous pouvez utiliser Amazon Virtual Private Cloud (VPC) pour partager des sous-réseaux VPC avec d'autres Comptes AWS membres de votre organisation, ainsi que pour partager une infrastructure réseau telle qu'un VPN entre plusieurs ressources. Comptes AWS
Actuellement, Amazon OpenSearch Serverless ne prend pas en charge la création d'une AWS PrivateLink connexion à un VPC partagé, sauf si vous êtes propriétaire de ce VPC. AWS PrivateLink ne prend pas non plus en charge le partage de connexions entre Comptes AWS.
Cependant, sur la base de l'architecture flexible et modulaire de OpenSearch Serverless, vous pouvez toujours configurer un VPC partagé. Cela est dû au fait que l'infrastructure réseau OpenSearch sans serveur est distincte de celle de l'infrastructure de collecte individuelle (OpenSearch service). Vous pouvez donc créer un AWS PrivateLink VPCe point de terminaison pour un compte sur lequel se trouve un VPC, puis utiliser un VPCe ID dans la politique réseau des autres comptes afin de limiter le trafic provenant uniquement de ce VPC partagé.
Les procédures suivantes font référence à un *compte propriétaire* et à un *compte client*.
Un compte propriétaire agit comme un compte réseau commun dans lequel vous configurez un VPC et le partagez avec d'autres comptes. Les comptes clients sont les comptes qui créent et gèrent leurs collections OpenSearch sans serveur dans le VPC partagé avec eux par le compte propriétaire.
**Conditions préalables**
Assurez-vous que les conditions suivantes sont remplies avant de configurer le VPC partagé :
+ Le compte du propriétaire prévu doit déjà avoir configuré un VPC, des sous-réseaux, une table de routage et les autres ressources requises dans Amazon Virtual Private Cloud. Pour de plus amples informations, consultez le *[Guide de l’utilisateur Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/)*.
+ Le compte du propriétaire prévu et les comptes du consommateur doivent appartenir à la même organisation dans AWS Organizations. Pour plus d’informations, consultez le *Guide de l’utilisateur [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/)*.
**Pour configurer un VPC partagé dans un compte account/common réseau propriétaire.**
1. Connectez-vous à la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home).
1. Suivez les étapes de [Création d'un point de terminaison d'interface pour OpenSearch Serverless](#serverless-vpc-create). Au fur et à mesure, effectuez les sélections suivantes :
+ Sélectionnez un VPC et des sous-réseaux partagés avec les comptes clients de votre organisation.
1. Après avoir créé le point de terminaison, notez l' VPCe identifiant généré et fournissez-le aux administrateurs chargés d'effectuer la tâche de configuration dans les comptes clients.
VPCe IDs sont au format`vpce-abc123def4EXAMPLE`.
**Pour configurer un VPC partagé dans un compte client**
1. Connectez-vous à la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home).
1. Utilisez les informations [Gestion des collections Amazon OpenSearch Serverless](serverless-manage.md) pour créer une collection, si vous n'en avez pas déjà une.
1. Utilisez les informations contenues [Créer des stratégies réseau (console)](serverless-network.md#serverless-network-console) pour créer une politique réseau. Au fur et à mesure, effectuez les sélections suivantes.
**Note**
Vous pouvez également mettre à jour une politique réseau existante à cette fin.
1. Pour le **type d'accès**, sélectionnez **VPC (recommandé)**.
1. Pour les **points de terminaison VPC auxquels vous pouvez accéder**, choisissez l' VPCe ID qui vous a été fourni par le compte propriétaire, au format. `vpce-abc123def4EXAMPLE`
1. Dans la zone **Type de ressource**, procédez comme suit :
+ Cochez la case **Activer l'accès au OpenSearch point de terminaison**, puis sélectionnez le nom ou le modèle de collection à utiliser pour activer l'accès depuis ce VPC partagé.
+ Sélectionnez la case **Activer l'accès au OpenSearch tableau de bord**, puis sélectionnez le nom ou le modèle de collection à utiliser pour autoriser l'accès depuis ce VPC partagé.
1. Pour une nouvelle politique, choisissez **Create**. Pour une politique existante, choisissez **Mettre à jour**.
# Accès au plan de contrôle via AWS PrivateLink
Amazon OpenSearch Serverless prend en charge deux types de AWS PrivateLink connexions pour les opérations du plan de contrôle et du plan de données. Les opérations du plan de contrôle incluent la création et la suppression de collections ainsi que la gestion des politiques d'accès. Les opérations du plan de données servent à indexer et à interroger des données au sein d'une collection. Cette page couvre le point de AWS PrivateLink terminaison du plan de contrôle. Pour plus d'informations sur les points de terminaison VPC du plan de données, consultez. [Accès au plan de données via AWS PrivateLink](serverless-vpc.md)
## Création d'un point de AWS PrivateLink terminaison du plan de contrôle
Vous pouvez améliorer le niveau de sécurité de votre VPC en configurant OpenSearch Serverless pour utiliser un point de terminaison VPC d'interface. Les points de terminaison de l'interface sont alimentés par AWS PrivateLink. Cette technologie vous permet d'accéder en privé OpenSearch sans serveur APIs sans passerelle Internet, appareil NAT, connexion VPN ou connexion AWS Direct Connect.
Pour plus d'informations sur AWS PrivateLink les points de terminaison VPC, consultez la section Points de terminaison [VPC dans le guide de l'utilisateur](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html#concepts-vpc-endpoints) Amazon VPC.
### Considérations
+ Les points de terminaison VPC ne sont pris en charge que dans la même région.
+ Les points de terminaison d'un VPC prennent uniquement en charge le DNS fourni par Amazon via Amazon Route 53.
+ Les points de terminaison VPC prennent en charge les politiques des points de terminaison pour contrôler l'accès aux collections OpenSearch sans serveur, aux politiques et. VpcEndpoints
+ OpenSearch Serverless ne prend en charge que les points de terminaison d'interface. Les points de terminaison de passerelle ne sont pas pris en charge.
### Création du point de terminaison VPC
*Pour créer le point de terminaison VPC du plan de contrôle pour Amazon OpenSearch Serverless, utilisez la [procédure Access an AWS service using an interface VPC endpoint du manuel Amazon VPC Developer](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint) Guide.* Créez le point de terminaison suivant :
+ `com.amazonaws.region.aoss`
**Pour créer un point de terminaison VPC du plan de contrôle à l'aide de la console**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le panneau de navigation, choisissez **Points de terminaison**.
1. Choisissez **Create Endpoint** (Créer un point de terminaison).
1. Pour **Service category** (Catégorie de service), choisissez **Services AWS**.
1. Pour **Services**, choisissez`com.amazonaws.region.aoss`. Par exemple, `com.amazonaws.us-east-1.aoss`.
1. Pour **VPC**, choisissez le VPC dans lequel créer le point de terminaison.
1. Pour **Sous-réseaux**, choisissez les sous-réseaux (zones de disponibilité) dans lesquels créer les interfaces réseau du point de terminaison.
1. Pour les **groupes de sécurité**, choisissez les groupes de sécurité à associer aux interfaces réseau des terminaux. Assurez-vous que le protocole HTTPS (port 443) est autorisé.
1. Pour **la stratégie**, choisissez **Accès complet** pour autoriser toutes les opérations, ou choisissez **Personnalisé** pour joindre une politique personnalisée.
1. Choisissez **Créer un point de terminaison**.
### Création d'une politique de point de terminaison
Vous pouvez associer une politique de point de terminaison à votre point de terminaison VPC qui contrôle l'accès à Amazon OpenSearch Serverless. La politique spécifie les informations suivantes :
+ Le principal qui peut exécuter des actions.
+ Les actions qui peuvent être effectuées.
+ Les ressources sur lesquelles les actions peuvent être exécutées.
Pour plus d’informations, consultez [Contrôle de l’accès aux services avec points de terminaison d’un VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) dans le *Guide de l’utilisateur Amazon VPC*.
**Example Politique de point de terminaison VPC pour Serverless OpenSearch**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": [
"aoss:ListCollections",
"aoss:BatchGetCollection"
],
"Resource": "*"
}
]
}
```
**Example Politique restrictive autorisant uniquement les opérations de liste**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "aoss:ListCollections",
"Resource": "*"
}
]
}
```
# Authentification SAML pour Amazon Serverless OpenSearch
Avec l'authentification SAML pour Amazon OpenSearch Serverless, vous pouvez utiliser votre fournisseur d'identité existant pour proposer l'authentification unique (SSO) pour les points de terminaison des OpenSearch tableaux de bord des collections sans serveur.
L'authentification SAML vous permet d'utiliser des fournisseurs d'identité tiers pour vous connecter aux OpenSearch tableaux de bord afin d'indexer et de rechercher des données. OpenSearch Serverless prend en charge les fournisseurs qui utilisent la norme SAML 2.0, tels que IAM Identity Center, Okta, Keycloak, Active Directory Federation Services (AD FS) et Auth0. Vous pouvez configurer IAM Identity Center pour synchroniser les utilisateurs et les groupes provenant d'autres sources d'identité telles qu'Okta et Microsoft Entra ID. OneLogin Pour obtenir la liste des sources d'identité prises en charge par IAM Identity Center et les étapes à suivre pour les configurer, consultez les [didacticiels de mise en route](https://docs.aws.amazon.com/singlesignon/latest/userguide/tutorials.html) du guide de l'*utilisateur d'IAM Identity Center*.
**Note**
L'authentification SAML permet uniquement d'accéder aux OpenSearch tableaux de bord via un navigateur Web. Les utilisateurs authentifiés peuvent uniquement envoyer des demandes aux opérations de l' OpenSearch API via les **outils de développement dans les** OpenSearch tableaux de bord. Vos informations d'identification SAML ne vous permettent *pas* d'envoyer des requêtes HTTP directes aux opérations de l' OpenSearch API.
Pour configurer l'authentification SAML, vous devez d'abord configurer un fournisseur d'identité (IdP) SAML. Vous incluez ensuite un ou plusieurs utilisateurs de cet IdP dans une [stratégie d'accès aux données](serverless-data-access.md). Cette politique lui accorde certaines autorisations sur les and/or index de collections. Un utilisateur peut ensuite se connecter aux OpenSearch tableaux de bord et effectuer les actions autorisées dans la politique d'accès aux données.
![\[SAML authentication flow with data access policy, OpenSearch interface, and JSON configuration.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-saml-flow.png)
**Topics**
+ [Considérations](#serverless-saml-considerations)
+ [Autorisations nécessaires](#serverless-saml-permissions)
+ [Créer des fournisseurs SAML (console)](#serverless-saml-creating)
+ [Accès aux OpenSearch tableaux de bord](#serverless-saml-dashboards)
+ [Octroyer aux identités SAML l'accès aux données de collection](#serverless-saml-policies)
+ [Créer des fournisseurs SAML (AWS CLI)](#serverless-saml-creating-api)
+ [Consulter des fournisseurs SAML](#serverless-saml-viewing)
+ [Mettre à jour des fournisseurs SAML](#serverless-saml-updating)
+ [Supprimer des fournisseurs SAML](#serverless-saml-deleting)
## Considérations
Tenez compte des éléments suivants lors de la configuration de l'authentification SAML :
+ Les requêtes signées et chiffrées ne sont pas prises en charge.
+ Les assertions chiffrées ne sont pas prises en charge.
+ L'authentification et la déconnexion initiées par l'IdP ne sont pas prises en charge.
+ Les politiques de contrôle des services (SCP) ne seront pas applicables ni évaluées dans le cas d'identités non IAM (comme le SAML dans OpenSearch Amazon Serverless et SAML et l'autorisation utilisateur interne de base pour Amazon Service). OpenSearch
## Autorisations nécessaires
L'authentification SAML pour OpenSearch Serverless utilise les autorisations Gestion des identités et des accès AWS (IAM) suivantes :
+ `aoss:CreateSecurityConfig` : créer un fournisseur SAML.
+ `aoss:ListSecurityConfig` : répertorier tous les fournisseurs SAML du compte actuel.
+ `aoss:GetSecurityConfig` : afficher les informations du fournisseur SAML.
+ `aoss:UpdateSecurityConfig` : modifier la configuration d'un fournisseur SAML donné, y compris les métadonnées XML.
+ `aoss:DeleteSecurityConfig` : supprimer un fournisseur SAML.
La stratégie d'accès basée sur l'identité suivante permet à un utilisateur de gérer toutes les configurations IdP :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"aoss:CreateSecurityConfig",
"aoss:DeleteSecurityConfig",
"aoss:GetSecurityConfig",
"aoss:UpdateSecurityConfig",
"aoss:ListSecurityConfigs"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
Veuillez noter que l'élément `Resource` doit être un caractère générique.
## Créer des fournisseurs SAML (console)
Ces étapes expliquent comment créer des fournisseurs SAML. Cela permet l'authentification SAML avec l'authentification initiée par le fournisseur de services (SP) pour les OpenSearch tableaux de bord. L'authentification initiée par l'IdP n'est pas prise en charge.
**Pour activer l'authentification SAML pour les tableaux de bord OpenSearch**
1. Connectez-vous à la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home ).
1. Dans le panneau de navigation de gauche, développez **Serverless** (Sans serveur) et sélectionnez **SAML authentication** (Authentification SAML).
1. Choisissez **Add SAML provider** (Ajouter un fournisseur SAML).
1. Saisissez un nom et une description pour le fournisseur.
**Note**
Le nom que vous spécifiez est accessible au public et apparaît dans un menu déroulant lorsque les utilisateurs se connectent à OpenSearch Dashboards. Assurez-vous que le nom est facilement reconnaissable et qu'il ne révèle pas d'informations sensibles sur votre fournisseur d'identité.
1. Sous **Configure your IdP** (Configurer votre IdP), copiez l'URL Assertion Consumer Service (ACS).
1. Utilisez l'URL ACS que vous venez de copier pour configurer votre fournisseur d'identité. La terminologie et les étapes varient selon le fournisseur. Consultez la documentation de votre fournisseur.
Dans Okta, par exemple, vous créez une « application web SAML 2.0 » et vous spécifiez l'URL ACS comme **URL d'authentification unique**, **URL du destinataire** et **URL de destination**. Pour Auth0, vous le spécifiez dans **Allowed URLs Callback**.
1. Indiquez la restriction d'audience si votre IdP dispose d'un champ à cet effet. La restriction d'audience est une valeur de l'assertion SAML qui indique à qui l'assertion est destinée. Avec OpenSearch Serverless, vous pouvez effectuer les opérations suivantes. Assurez-vous de remplacer le code indiqué *content* dans l'exemple de code suivant par votre propre Compte AWS identifiant :
1. Utilisez la restriction d'audience par défaut`:opensearch:111122223333`.
1. (Facultatif) configurez une restriction d'audience personnalisée à l'aide du AWS CLI. Pour de plus amples informations, veuillez consulter [Créer des fournisseurs SAML (AWS CLI)](#serverless-saml-creating-api).
Le nom du champ de restriction d'audience varie selon le fournisseur. Pour Okta, il s'agit d'**URI d'audience (ID d'entité du fournisseur de services)**. Pour IAM Identity Center, il s'agit de **l'audience SAML des applications**.
1. Si vous utilisez IAM Identity Center, vous devez également spécifier le [mappage d'attributs](https://docs.aws.amazon.com/singlesignon/latest/userguide/attributemappingsconcept.html) suivant : `Subject=${user:name}`, au format `unspecified`.
1. Une fois votre fournisseur d'identité configuré, il génère un fichier de métadonnées de fournisseur d'identité. Ce fichier XML contient des informations sur le fournisseur, telles qu'un certificat TLS, des points de terminaison d'authentification unique et l'ID d'entité du fournisseur d'identité.
Copiez le texte dans le fichier de métadonnées IdP et collez-le sous le champ **Provide metadata from your IdP** (Fournir les métadonnées de votre IdP). Vous pouvez également choisir **Importer depuis un fichier XML**, puis charger le fichier. Le fichier de métadonnées doit se présenter comme suit :
```
tls-certificate
s
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
```
1. Laissez le champ d'**attribut Custom user ID** vide pour utiliser l'`NameID`élément de l'assertion SAML comme nom d'utilisateur. Si votre assertion n'utilise pas cet élément standard et inclut plutôt le nom d'utilisateur comme attribut personnalisé, spécifiez cet attribut ici. Les attributs sont sensibles à la casse. Seul un attribut d'utilisateur unique est pris en charge.
L'exemple suivant montre un attribut de remplacement pour `NameID` dans l'assertion SAML :
```
annie
```
1. (Facultatif) Spécifiez un attribut personnalisé dans le champ **Group attribute** (Attribut de groupe), tel que `role` ou `group`. Seul un attribut de groupe unique est pris en charge. Il n'existe aucun attribut de groupe par défaut. Si vous n'en spécifiez pas, vos stratégies d'accès aux données ne peuvent contenir que des principaux d'utilisateur.
L'exemple suivant montre un attribut de groupe dans l'assertion SAML :
```
finance
```
1. Par défaut, OpenSearch Dashboards déconnecte les utilisateurs au bout de 24 heures. Vous pouvez configurer cette valeur sur un nombre compris entre 1 et 12 heures (15 et 720 minutes) en spécifiant le **délai d'expiration OpenSearch des tableaux** de bord. Si vous essayez de régler le délai d'attente égal ou inférieur à 15 minutes, votre session sera réinitialisée à une heure.
1. Choisissez **Create SAML provider** (Créer un fournisseur SAML).
## Accès aux OpenSearch tableaux de bord
Après avoir configuré un fournisseur SAML, tous les utilisateurs et groupes associés à ce fournisseur peuvent accéder au point de terminaison OpenSearch Dashboards. Le format de l'URL des tableaux de bord correspond à celui `collection-endpoint/_dashboards/` *de toutes les collections*.
Si le protocole SAML est activé, vous êtes AWS Management Console redirigé vers la page de sélection de l'IdP, où vous pouvez vous connecter à l'aide de vos informations d'identification SAML. Tout d'abord, utilisez la liste déroulante pour sélectionner un fournisseur d'identité :
![\[OpenSearch login page with dropdown menu for selecting SAML Identity Provider options.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/idpList.png)
Connectez-vous ensuite à l'aide de vos informations d'identification d'IdP.
Si le protocole SAML n'est pas activé, vous pouvez cliquer sur le lien dans le pour AWS Management Console vous connecter en tant qu'utilisateur ou en tant que rôle IAM, sans aucune option pour le protocole SAML.
## Octroyer aux identités SAML l'accès aux données de collection
Après avoir créé un fournisseur SAML, vous devez toujours octroyer aux utilisateurs et aux groupes sous-jacents l'accès aux données de vos collections. Vous octroyez l'accès par le biais de [stratégies d'accès aux données](serverless-data-access.md). Tant que vous n'aurez pas octroyé l'accès aux utilisateurs, ils ne pourront pas lire, écrire ou supprimer les données de vos collections.
Pour accorder l'accès, créez une politique d'accès aux données et spécifiez votre and/or groupe d'utilisateurs SAML IDs dans la `Principal` déclaration suivante :
```
[
{
"Rules":[
...
],
"Principal":[
"saml/987654321098/myprovider/user/Shaheen",
"saml/987654321098/myprovider/group/finance"
]
}
]
```
Vous pouvez octroyer l'accès aux collections, aux index ou aux deux. Si vous souhaitez que différents utilisateurs aient des autorisations différentes, créez plusieurs règles. Pour obtenir la liste des autorisations disponibles, veuillez consulter la rubrique [Autorisations de stratégie prises en charge](serverless-data-access.md#serverless-data-supported-permissions). Pour plus d'informations sur le formatage d'une stratégie d'accès, veuillez consulter la rubrique [Policy syntax](serverless-data-access.md) (Syntaxe de stratégie).
## Créer des fournisseurs SAML (AWS CLI)
Pour créer un fournisseur SAML à l'aide de l'API OpenSearch Serverless, envoyez une [CreateSecurityConfig](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateSecurityConfig.html)demande :
```
aws opensearchserverless create-security-config \
--name myprovider \
--type saml \
--saml-options file://saml-auth0.json
```
Spécifiez `saml-options`, y compris le fichier XML des métadonnées, sous la forme d'un mappage clé-valeur dans un fichier .json. Le fichier XML des métadonnées doit être codé sous la forme d'une [chaîne d'échappement JSON](https://www.freeformatter.com/json-escape.html).
```
{
"sessionTimeout": 70,
"groupAttribute": "department",
"userAttribute": "userid",
"openSearchServerlessEntityId": "aws:opensearch:111122223333:app1",
"metadata": "EntityDescriptor xmlns=\"urn:oasis:names:tc:SAML:2.0:metadata\" ... ... ... IDPSSODescriptor\r\n\/EntityDescriptor"
}
```
**Note**
(Facultatif) configurez une restriction d'audience personnalisée à l'aide du AWS CLI. Pour de plus amples informations, veuillez consulter [Créer des fournisseurs SAML (AWS CLI)](#serverless-saml-creating-api).
## Consulter des fournisseurs SAML
La [ListSecurityConfigs](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_ListSecurityConfigs.html)demande suivante répertorie tous les fournisseurs SAML de votre compte :
```
aws opensearchserverless list-security-configs --type saml
```
La requête renvoie des informations sur tous les fournisseurs SAML existants, y compris les métadonnées IdP complètes générées par votre fournisseur d'identité :
```
{
"securityConfigDetails": [
{
"configVersion": "MTY2NDA1MjY4NDQ5M18x",
"createdDate": 1664054180858,
"description": "Example SAML provider",
"id": "saml/111122223333/myprovider",
"lastModifiedDate": 1664054180858,
"samlOptions": {
"groupAttribute": "department",
"metadata": "EntityDescriptorxmlns=\"urn:oasis:names:tc:SAML:2.0:metadata\" ...... ...IDPSSODescriptor\r\n/EntityDescriptor",
"sessionTimeout": 120,
"openSearchServerlessEntityId": "aws:opensearch:111122223333:app1",
"userAttribute": "userid"
}
}
]
}
```
Pour consulter les détails d'un fournisseur spécifique, y compris la `configVersion` des mises à jour futures, envoyez une requête `GetSecurityConfig`.
## Mettre à jour des fournisseurs SAML
**Pour mettre à jour un fournisseur SAML à l'aide de la console OpenSearch Serverless, choisissez **l'authentification SAML**, sélectionnez votre fournisseur d'identité, puis choisissez Modifier.** Vous pouvez modifier tous les champs, y compris les métadonnées et les attributs personnalisés.
Pour mettre à jour un fournisseur via l'API OpenSearch Serverless, envoyez une [UpdateSecurityConfig](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UpdateSecurityConfig.html)demande et incluez l'identifiant de la politique à mettre à jour. Vous devez également inclure une version de configuration, que vous pouvez récupérer à l'aide des commandes `ListSecurityConfigs` ou `GetSecurityConfig`. En incluant la version la plus récente, vous vous assurez de ne pas annuler par inadvertance une modification apportée par quelqu'un d'autre.
La requête suivante met à jour les options SAML d'un fournisseur :
```
aws opensearchserverless update-security-config \
--id saml/123456789012/myprovider \
--type saml \
--saml-options file://saml-auth0.json \
--config-version MTY2NDA1MjY4NDQ5M18x
```
Spécifiez vos options de configuration SAML sous la forme d'un mappage clé-valeur dans un fichier .json.
**Important**
Les **mises à jour des options SAML ne sont *pas* progressives**. Si vous ne spécifiez aucune valeur pour un paramètre de l'objet `SAMLOptions` lorsque vous effectuez une mise à jour, les valeurs existantes seront remplacées par des valeurs vides. Par exemple, si la configuration actuelle contient une valeur pour `userAttribute`, puis que vous effectuez une mise à jour sans inclure cette valeur, la valeur est supprimée de la configuration. Assurez-vous de connaître les valeurs existantes avant de procéder à une mise à jour en appelant l'opération `GetSecurityConfig`.
## Supprimer des fournisseurs SAML
Lorsque vous supprimez un fournisseur SAML, les références aux utilisateurs et aux groupes associés dans vos stratégies d'accès aux données ne sont plus fonctionnelles. Pour éviter toute confusion, nous vous suggérons de supprimer toutes les références au point de terminaison dans vos stratégies d'accès avant de supprimer le point de terminaison.
**Pour supprimer un fournisseur SAML à l'aide de la console OpenSearch Serverless, choisissez **Authentification**, sélectionnez le fournisseur, puis choisissez Supprimer.**
Pour supprimer un fournisseur via l'API OpenSearch Serverless, envoyez une [DeleteSecurityConfig](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_DeleteSecurityConfig.html)demande :
```
aws opensearchserverless delete-security-config --id saml/123456789012/myprovider
```
# Validation de conformité pour Amazon OpenSearch Serverless
Des auditeurs tiers évaluent la sécurité et la conformité d'Amazon OpenSearch Serverless dans le cadre de plusieurs programmes de AWS conformité. Il s'agit notamment des programmes SOC, PCI et HIPAA.
Pour savoir si un [programme Services AWS de conformité Service AWS s'inscrit dans le champ d'application de programmes de conformité](https://aws.amazon.com/compliance/services-in-scope/) spécifiques, consultez Services AWS la section de conformité et sélectionnez le programme de conformité qui vous intéresse. Pour des informations générales, voir Programmes de [AWS conformité Programmes AWS](https://aws.amazon.com/compliance/programs/) de .
Vous pouvez télécharger des rapports d'audit tiers à l'aide de AWS Artifact. Pour plus d'informations, voir [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Votre responsabilité en matière de conformité lors de l'utilisation Services AWS est déterminée par la sensibilité de vos données, les objectifs de conformité de votre entreprise et les lois et réglementations applicables. Pour plus d'informations sur votre responsabilité en matière de conformité lors de l'utilisation Services AWS, consultez [AWS la documentation de sécurité](https://docs.aws.amazon.com/security/).
# Marquage des collections Amazon OpenSearch Serverless
Les balises vous permettent d'attribuer des informations arbitraires à une collection Amazon OpenSearch Serverless afin que vous puissiez les classer et les filtrer en fonction de ces informations. Une *balise* est une étiquette de métadonnées que vous attribuez ou attribuez à une AWS ressource. AWS
Chaque balise se compose d’une *clé* et d’une *valeur*. Pour les balises que vous attribuez, vous définissez la clé et la valeur. Par exemple, vous pouvez définir la clé sur `stage` et la valeur pour une ressource sur `test`.
Les balises vous permettent d'identifier et d'organiser vos AWS ressources. De nombreux AWS services prennent en charge le balisage. Vous pouvez donc attribuer le même tag aux ressources de différents services pour indiquer que les ressources sont liées. Par exemple, vous pouvez attribuer la même balise à une collection OpenSearch sans serveur que celle que vous attribuez à un domaine Amazon OpenSearch Service.
Dans OpenSearch Serverless, la ressource principale est une collection. Vous pouvez utiliser la console de OpenSearch service AWS CLI, les opérations de l'API OpenSearch Serverless ou AWS SDKs pour ajouter, gérer et supprimer des balises dans une collection.
## Autorisations nécessaires
OpenSearch Serverless utilise les autorisations AWS Identity and Access Management Access Analyzer (IAM) suivantes pour baliser les collections :
+ `aoss:TagResource`
+ `aoss:ListTagsForResource`
+ `aoss:UntagResource`
# Balisage des collections (console)
La console constitue le moyen le plus simple de baliser une collection.
****Pour créer une identification (console)****
1. Connectez-vous à la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home ).
1. Développez **Serverless** (Sans serveur) dans le panneau de navigation de gauche et choisissez **Collections**.
1. Sélectionnez la collection à laquelle vous souhaitez ajouter des balises et accédez à l'onglet **Tags** (Balises).
1. Choisissez **Manage (Gérer)** et **Add new tag (Ajouter une nouvelle balise)**.
1. Saisissez une clé de balise et une valeur de balise facultative.
1. Choisissez **Save (Enregistrer)**.
Pour supprimer une balise, suivez les mêmes étapes et choisissez **Remove (Supprimer)** sur la page **Manage tags (Gérer les balises)**.
Pour plus d'informations sur l'utilisation de la console avec des identifications, veuillez consulter [Éditeur d'identification](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html) dans le *Guide de démarrage de la console de gestion AWS *.
# Balisage de collections ()AWS CLI
Pour étiqueter une collection à l'aide du AWS CLI, envoyez une [TagResource](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_TagResource.html)demande :
```
aws opensearchserverless tag-resource
--resource-arn arn:aws:aoss:us-east-1:123456789012:collection/my-collection
--tags Key=service,Value=aoss Key=source,Value=logs
```
Affichez les balises existantes pour une collection à l'aide de la [ListTagsForResource](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_ListTagsForResource.html)commande :
```
aws opensearchserverless list-tags-for-resource
--resource-arn arn:aws:aoss:us-east-1:123456789012:collection/my-collection
```
Supprimez les tags d'une collection à l'aide de la [UntagResource](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UntagResource.html)commande :
```
aws opensearchserverless untag-resource
--resource-arn arn:aws:aoss:us-east-1:123456789012:collection/my-collection
--tag-keys service
```
# Opérations et plug-ins pris en charge dans Amazon OpenSearch Serverless
Amazon OpenSearch Serverless prend en charge une variété de OpenSearch plug-ins, ainsi qu'un sous-ensemble des [opérations d'API](https://opensearch.org/docs/latest/opensearch/rest-api/index/) d'indexation, de recherche et de métadonnées disponibles dans. OpenSearch Vous pouvez inclure les autorisations dans la colonne de gauche du tableau dans les [stratégies d'accès aux données](serverless-data-access.md) afin de limiter l'accès à certaines opérations.
**Topics**
+ [Opérations et autorisations d' OpenSearch API prises en charge](#serverless-operations)
+ [OpenSearch Plugins pris en charge](#serverless-plugins)
## Opérations et autorisations d' OpenSearch API prises en charge
Le tableau suivant répertorie les opérations d'API prises en charge par OpenSearch Serverless, ainsi que les autorisations de politique d'accès aux données correspondantes :
| Autorisation de stratégie d'accès aux données | OpenSearch Opérations d'API | Description et mises en garde |
| --- | --- | --- |
| `aoss:CreateIndex` | PUT | Créer des index. Pour plus d'informations, veuillez consulter la rubrique [Créer un index](https://opensearch.org/docs/latest/api-reference/index-apis/create-index/) (langue française non garantie). Cette autorisation s'applique également à la création d'index avec les exemples de données sur les OpenSearch tableaux de bord. |
| `aoss:DescribeIndex` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Décrire des index. Pour plus d’informations, consultez les ressources suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) |
| `aoss:WriteDocument` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Rédiger et mettre à jour des documents. Pour plus d’informations, consultez les ressources suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) Certaines opérations ne sont autorisées que pour les collections de type `SEARCH`. Pour de plus amples informations, veuillez consulter [Choix d'un type de collection](serverless-overview.md#serverless-usecase). |
| `aoss:ReadDocument` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Lire des documents. Pour plus d’informations, consultez les ressources suivantes :[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) |
| `aoss:DeleteIndex` | DELETE | Supprimer les index. Pour plus d'informations, veuillez consulter la rubrique [Supprimer un index](https://opensearch.org/docs/latest/api-reference/index-apis/delete-index/) (langue française non garantie). |
| `aoss:UpdateIndex` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Mettre à jour les paramètres d'index. Pour plus d’informations, consultez les ressources suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) |
| `aoss:CreateCollectionItems` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) |
| `aoss:DescribeCollectionItems` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Décrit comment utiliser les alias, les modèles d'index et de framework, ainsi que les pipelines. Pour plus d’informations, consultez les ressources suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) |
| `aoss:UpdateCollectionItems` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Mettez à jour les alias, les modèles d'index et les modèles de framework. Pour plus d’informations, consultez les ressources suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) \$1 L'API pour déprovisionner les modèles. Les services ML Commons Client et OpenSearch Serverless gèrent les politiques dépendantes. |
| `aoss:DeleteCollectionItems` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Supprimez les alias, les modèles d'index et de framework, ainsi que les pipelines. Pour plus d’informations, consultez les ressources suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) |
| `aoss:DescribeMLResource` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Décrit GET et la recherche APIs pour récupérer des informations sur les modèles et les connecteurs. |
| `aoss:CreateMLResource` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Permet de créer des ressources ML. |
| `aoss:UpdateMLResource` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Permet de mettre à jour les ressources ML existantes. |
| `aoss:DeleteMLResource` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Permet de supprimer des ressources ML. |
| `aoss:ExecuteMLResource` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-genref.html) | Fournit l'autorisation d'exécuter des modèles. |
## OpenSearch Plugins pris en charge
OpenSearch Les collections sans serveur sont préemballées avec les plugins suivants de la OpenSearch communauté. La technologie sans serveur déploie et gère automatiquement les plugins pour vous.
**Plugins d'analyse**
+ [ICU Analysis](https://github.com/opensearch-project/OpenSearch/tree/main/plugins/analysis-icu)
+ [Japanese (kuromoji) Analysis](https://github.com/opensearch-project/OpenSearch/tree/main/plugins/analysis-kuromoji)
+ [Korean (Nori) Analysis](https://github.com/opensearch-project/OpenSearch/tree/main/plugins/analysis-nori)
+ [Phonetic Analysis](https://github.com/opensearch-project/OpenSearch/tree/main/plugins/analysis-phonetic)
+ [Smart Chinese Analysis](https://github.com/opensearch-project/OpenSearch/tree/main/plugins/analysis-smartcn)
+ [Stempel Polish Analysis](https://github.com/opensearch-project/OpenSearch/tree/main/plugins/analysis-stempel)
+ [Ukrainian Analysis](https://github.com/opensearch-project/OpenSearch/tree/main/plugins/analysis-ukrainian)
**Plugins de mappage**
+ [Mapper Size](https://github.com/opensearch-project/OpenSearch/tree/main/plugins/mapper-size)
+ [Mapper Murmur3](https://github.com/opensearch-project/OpenSearch/tree/main/plugins/mapper-murmur3)
+ [Mapper Annotated Text](https://github.com/opensearch-project/OpenSearch/tree/main/plugins/mapper-annotated-text)
**Plugins de script**
+ [Painless](https://opensearch.org/docs/latest/api-reference/script-apis/exec-script/)
+ [Expression](https://opensearch.org/docs/latest/data-prepper/pipelines/expression-syntax/)
+ [Mustache](https://mustache.github.io/mustache.5.html)
En outre, OpenSearch Serverless inclut tous les plugins fournis sous forme de modules.
# Surveillance d'Amazon OpenSearch Serverless
La surveillance joue un rôle important dans le maintien de la fiabilité, de la disponibilité et des performances d'Amazon OpenSearch Serverless et de vos autres AWS solutions. AWS fournit les outils de surveillance suivants pour surveiller OpenSearch Serverless, signaler tout problème et prendre des mesures automatiques le cas échéant :
+ *Amazon CloudWatch* surveille vos AWS ressources et les applications que vous utilisez AWS en temps réel. Vous pouvez collecter et suivre les métriques, créer des tableaux de bord personnalisés, et définir des alarmes qui vous informent ou prennent des mesures lorsqu’une métrique spécifique atteint un seuil que vous spécifiez.
Par exemple, vous pouvez CloudWatch suivre l'utilisation du processeur ou d'autres indicateurs de vos instances Amazon EC2 et lancer automatiquement de nouvelles instances en cas de besoin. Pour plus d'informations, consultez le [guide de CloudWatch l'utilisateur Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ *AWS CloudTrail* capture les appels d’API et les événements associés effectués par votre Compte AWS ou au nom de ce dernier. Il remet les fichiers journaux au compartiment Amazon S3 que vous spécifiez. Vous pouvez identifier les utilisateurs et les comptes appelés AWS, l'adresse IP source à partir de laquelle les appels ont été effectués et la date des appels. Pour plus d’informations, consultez le [Guide de l’utilisateur AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
+ *Amazon EventBridge* fournit un flux d'événements système en temps quasi réel décrivant les modifications apportées à vos domaines OpenSearch de service. Vous pouvez créer des règles qui surveillent certains événements et déclencher des actions automatisées dans d'autres Services AWS cas lorsque ces événements se produisent. Pour plus d'informations, consultez le [guide de EventBridge l'utilisateur Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/).
# Surveillance OpenSearch sans serveur avec Amazon CloudWatch
Vous pouvez surveiller Amazon OpenSearch Serverless en utilisant CloudWatch, qui collecte les données brutes et les traite en métriques lisibles en temps quasi réel. Ces statistiques sont enregistrées pour une durée de 15 mois ; par conséquent, vous pouvez accéder aux informations historiques et acquérir un meilleur point de vue de la façon dont votre service ou application web s’exécute.
Vous pouvez également définir des alarmes qui surveillent certains seuils et envoient des notifications ou prennent des mesures lorsque ces seuils sont atteints. Pour plus d'informations, consultez le [guide de CloudWatch l'utilisateur Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
OpenSearch Serverless indique les métriques suivantes dans l'espace de `AWS/AOSS` noms.
| Métrique | Description |
| --- | --- |
| ActiveCollection | Indique si une collection est active. La valeur 1 signifie que la collection est à l'état `ACTIVE`. Cette valeur est émise lors de la création réussie d'une collection et reste égale à 1 jusqu'à ce que vous supprimiez la collection. La métrique ne peut pas être égale à 0. **Statistiques pertinentes** : maximum **Dimensions** : `ClientId`, `CollectionId`, `CollectionName` **Fréquence** : 60 secondes |
| DeletedDocuments | Nombre total de documents supprimés. **Statistiques pertinentes** : moyenne, somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName`, `IndexId`, `IndexName` **Fréquence** : 60 secondes |
| IndexingOCU | Le nombre d'unités de OpenSearch calcul (OCUs) utilisées pour ingérer les données de collecte. Cette métrique s'applique au niveau du compte. Représente l'utilisation uniquement pour les collections qui ne font partie d'aucun groupe de collections. **Statistiques pertinentes** : somme **Dimensions** : `ClientId` **Fréquence** : 60 secondes |
| IndexingOCU | Le nombre d'unités de OpenSearch calcul (OCUs) utilisées pour ingérer les données de collecte. Cette métrique s'applique au niveau du groupe de collecte. **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionGroupId`, `CollectionGroupName` **Fréquence** : 60 secondes |
| IngestionDataRate | Taux d'indexation en Gio par seconde vers une collection ou un index. Cette métrique s'applique uniquement aux requêtes d'indexation en bloc. **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName`, `IndexId`, `IndexName` **Fréquence** : 60 secondes |
| IngestionDocumentErrors | Nombre total d'erreurs de document lors de l'ingestion pour une collection ou un index. Après une requête d'indexation en bloc réussie, les enregistreurs traitent la requête et émettent des erreurs pour tous les documents ayant échoué inclus dans la requête. **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName`, `IndexId`, `IndexName` **Fréquence** : 60 secondes |
| IngestionDocumentRate | Taux par seconde auquel les documents sont ingérés dans une collection ou un index. Cette métrique s'applique uniquement aux requêtes d'indexation en bloc. **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName`, `IndexId`, `IndexName` **Fréquence** : 60 secondes |
| IngestionRequestErrors | Nombre total d'erreurs de demande d'indexation en bloc dans une collection. OpenSearch Serverless émet cette métrique lorsqu'une demande d'indexation en masse échoue pour une raison quelconque, telle qu'un problème d'authentification ou de disponibilité. **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName` **Fréquence** : 60 secondes |
| IngestionRequestLatency | Latence, en secondes, pour les opérations d'écriture en bloc dans une collection. **Statistiques pertinentes** : minimum, maximum, moyenne **Dimensions** : `ClientId`, `CollectionId`, `CollectionName` **Fréquence** : 60 secondes |
| IngestionRequestRate | Nombre total d'opérations d'écriture en bloc reçues par une collection. **Statistiques pertinentes** : minimum, maximum, moyenne **Dimensions** : `ClientId`, `CollectionId`, `CollectionName` **Fréquence** : 60 secondes |
| IngestionRequestSuccess | Nombre total d'opérations d'indexation réussies dans une collection. **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName` **Fréquence** : 60 secondes |
| SearchableDocuments | Nombre total de documents consultables dans une collection ou un index. **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName`, `IndexId`, `IndexName` **Fréquence** : 60 secondes |
| SearchRequestErrors | Nombre total d'erreurs de requête par minute pour une collection. **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName` **Fréquence** : 60 secondes |
| SearchRequestLatency | Temps moyen nécessaire, en millisecondes, pour terminer une opération de recherche dans une collection. **Statistiques pertinentes** : minimum, maximum, moyenne **Dimensions** : `ClientId`, `CollectionId`, `CollectionName` **Fréquence** : 60 secondes |
| SearchOCU | Le nombre d'unités de OpenSearch calcul (OCUs) utilisées pour rechercher les données de collecte. Cette métrique s'applique au niveau du compte. Représente l'utilisation uniquement pour les collections qui ne font partie d'aucun groupe de collections. **Statistiques pertinentes** : somme **Dimensions** : `ClientId` **Fréquence** : 60 secondes |
| SearchOCU | Le nombre d'unités de OpenSearch calcul (OCUs) utilisées pour rechercher les données de collecte. Cette métrique s'applique au niveau du groupe de collecte. **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionGroupId`, `CollectionGroupName` **Fréquence** : 60 secondes |
| SearchRequestRate | Nombre total de requêtes de recherche par minute pour une collection. **Statistiques pertinentes** : moyenne, maximum, somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName` **Fréquence** : 60 secondes |
| StorageUsedInS3 | La quantité, en octets, de stockage Amazon S3 utilisée. OpenSearch Serverless stocke les données indexées dans Amazon S3. Vous devez sélectionner la période à une minute pour obtenir une valeur précise. **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName`, `IndexId`, `IndexName` **Fréquence** : 60 secondes |
| VectorIndexBuildAccelerationOCU | Nombre d'unités de OpenSearch calcul (OCUs) utilisées pour accélérer l'indexation vectorielle. Cette métrique s'applique au niveau de la collection. **Statistiques pertinentes** : somme **Dimensions** :`ClientId`, `CollectionId` **Fréquence** : 60 secondes |
| 2xx, 3xx, 4xx, 5xx | Nombre de requêtes adressées à une collection ayant entraîné le code de réponse HTTP donné (2*xx*, 3*xx*, 4*xx*, 5*xx*). **Statistiques pertinentes** : somme **Dimensions** : `ClientId`, `CollectionId`, `CollectionName` **Fréquence** : 60 secondes |
# Journalisation des appels d'API OpenSearch sans serveur à l'aide de AWS CloudTrail
Amazon OpenSearch Serverless est intégré à AWS CloudTrail un service qui fournit un enregistrement des actions entreprises par un utilisateur, un rôle ou un AWS service dans Serverless.
CloudTrail capture tous les appels d'API pour OpenSearch Serverless sous forme d'événements. Les appels capturés incluent des appels provenant de la section Serverless de la console de OpenSearch service et des appels de code vers les opérations de l'API OpenSearch Serverless.
Si vous créez un suivi, vous pouvez activer la diffusion continue d' CloudTrail événements vers un compartiment Amazon S3, y compris des événements pour OpenSearch Serverless. Si vous ne configurez pas de suivi, vous pouvez toujours consulter les événements les plus récents dans la CloudTrail console dans **Historique des événements**.
À l'aide des informations collectées par CloudTrail, vous pouvez déterminer la demande qui a été faite à OpenSearch Serverless, l'adresse IP à partir de laquelle la demande a été faite, qui a fait la demande, quand elle a été faite et des détails supplémentaires.
Pour en savoir plus CloudTrail, consultez le [guide de AWS CloudTrail l'utilisateur](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html).
## OpenSearch Informations sans serveur dans CloudTrail
CloudTrail est activé sur votre compte Compte AWS lorsque vous créez le compte. Lorsqu'une activité se produit dans OpenSearch Serverless, cette activité est enregistrée dans un CloudTrail événement avec d'autres événements de AWS service dans **l'historique** des événements. Vous pouvez consulter, rechercher et télécharger les événements récents dans votre Compte AWS. Pour plus d'informations, consultez la section [Affichage des événements à l'aide de l'historique des CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Pour un enregistrement continu des événements survenus dans votre environnement Compte AWS, y compris les événements pour OpenSearch Serverless, créez une trace. Un *suivi* permet CloudTrail de fournir des fichiers journaux à un compartiment Amazon S3. Par défaut, lorsque vous créez un journal d’activité dans la console, il s’applique à toutes les régions Régions AWS.
Le journal enregistre les événements de toutes les régions de la AWS partition et transmet les fichiers journaux au compartiment Amazon S3 que vous spécifiez. En outre, vous pouvez configurer d'autres AWS services pour analyser plus en détail les données d'événements collectées dans les CloudTrail journaux et agir en conséquence. Pour plus d’informations, consultez les ressources suivantes :
+ [Présentation de la création d’un journal de suivi](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail services et intégrations pris en charge](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html)
+ [Configuration des notifications Amazon SNS pour CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html)
+ [Réception de fichiers CloudTrail journaux de plusieurs régions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) et [réception de fichiers CloudTrail journaux de plusieurs comptes](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Toutes les actions OpenSearch Serverless sont enregistrées CloudTrail et documentées dans la référence de l'[API OpenSearch Serverless](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/Welcome.html). Par exemple, les appels aux `CreateCollection``ListCollections`, et `DeleteCollection` les actions génèrent des entrées dans les fichiers CloudTrail journaux.
Chaque événement ou entrée de journal contient des informations sur la personne ayant initié la demande. Les informations relatives à l'identité vous permettent de déterminer :
+ Si la demande a été faite avec les informations d'identification de l'utilisateur root ou Gestion des identités et des accès AWS (IAM).
+ Si la demande a été effectuée avec les informations d’identification de sécurité temporaires d’un rôle ou d’un utilisateur fédéré.
+ Si la demande a été faite par un autre AWS service.
Pour de plus amples informations, veuillez consulter l'[élément userIdentity CloudTrail ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## OpenSearch Événements de données sans serveur dans CloudTrail
[Les événements de données](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events) fournissent des informations sur les opérations de ressources effectuées sur ou dans une ressource (par exemple, la recherche ou l'indexation dans une collection OpenSearch sans serveur). Ils sont également connus sous le nom opérations de plans de données. Les événements de données sont souvent des activités à fort volume. Par défaut, CloudTrail n'enregistre pas les événements liés aux données. L'**historique des CloudTrail événements** n'enregistre pas les événements liés aux données.
Des frais supplémentaires s’appliquent pour les événements de données. Pour plus d'informations sur la CloudTrail tarification, consultez la section [AWS CloudTrail Tarification](https://aws.amazon.com/cloudtrail/pricing/).
Vous pouvez enregistrer les événements de données pour les types de `AWS::AOSS::Collection` ressources à l'aide de la CloudTrail console ou AWS CLI des opérations de CloudTrail l'API. Pour plus d’informations sur la façon de journaliser les événements de données, consultez [Journalisation des événements de données avec la AWS Management Console](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console) et [Journalisation des événements de données avec l’ AWS Command Line Interface](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI) dans le *Guide de l’utilisateur AWS CloudTrail *.
Vous pouvez configurer des sélecteurs d’événements avancés pour filtrer les champs `eventName`, `readOnly` et `resources.ARN` afin de ne journaliser que les événements importants pour vous. Pour plus d’informations sur ces champs, consultez [https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html) dans la *Référence des API AWS CloudTrail *.
## Comprendre les OpenSearch entrées d'événements de données sans serveur
Dans l'exemple suivant :
+ Le `requestParameters` champ contient des informations sur l'appel d'API effectué vers la collection. Il inclut le chemin de la demande de base (sans les paramètres de requête).
+ Le `responseElements` champ inclut un code de statut qui indique le résultat de votre demande lors de la modification des ressources. Ce code d'état vous permet de savoir si vos modifications ont été traitées avec succès ou si elles nécessitent une attention particulière.
+ OpenSearch Serverless enregistre les événements de CloudTrail données uniquement pour les demandes ayant réussi l'authentification IAM.
**Example**
```
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws::sts::111122223333:assumed-role/Admin/user-role",
"accountId": "111122223333",
"accessKeyId": "access-key",
"userName": "",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/Admin",
"accountId": "111122223333",
"userName": "Admin"
},
"attributes": {
"creationDate": "2025-08-15T22:57:38Z",
"mfaAuthenticated": "false"
},
"sourceIdentity": "",
"ec2RoleDelivery": "",
"assumedRoot": ""
},
"identityProvider": "",
"credentialId": ""
},
"eventTime": "2025-08-15T22:58:00Z",
"eventSource": "aoss.amazonaws.com",
"eventName": "Search",
"awsRegion": "us-east-1",
"sourceIPAddress": "AWS Internal",
"userAgent": "python-requests/2.32.3",
"requestParameters": {
"pathPrefix": "/_search"
},
"responseElements": null,
"requestID": "2cfee788-EXAM-PLE1-8617-4018cEXAMPLE",
"eventID": "48d43617-EXAM-PLE1-9d9c-f7EXAMPLE",
"readOnly": true,
"resources": [
{
"type": "AWS::AOSS::Collection",
"ARN": "arn:aws:aoss:us-east-1:111122223333:collection/aab9texampletu45xh77"
}
],
"eventType": "AwsApiCall",
"managementEvent": false,
"recipientAccountId": "111122223333",
"eventCategory": "Data"
}
]
}
```
## Comprendre les OpenSearch entrées d'événements de gestion sans serveur
Un suivi est une configuration qui permet de transmettre des événements sous forme de fichiers journaux à un compartiment Amazon S3 que vous spécifiez. CloudTrail les fichiers journaux contiennent une ou plusieurs entrées de journal.
Un événement représente une demande individuelle d’une source quelconque. Il inclut des informations sur l'action demandée, la date et l'heure de l'action, les paramètres de la demande, etc. CloudTrail les fichiers journaux ne constituent pas une trace ordonnée des appels d'API publics, ils n'apparaissent donc pas dans un ordre spécifique.
L'exemple suivant affiche une entrée de CloudTrail journal illustrant l'`CreateCollection`action.
```
{
"eventVersion":"1.08",
"userIdentity":{
"type":"AssumedRole",
"principalId":"AIDACKCEVSQ6C2EXAMPLE",
"arn":"arn:aws:iam::123456789012:user/test-user",
"accountId":"123456789012",
"accessKeyId":"access-key",
"sessionContext":{
"sessionIssuer":{
"type":"Role",
"principalId":"AIDACKCEVSQ6C2EXAMPLE",
"arn":"arn:aws:iam::123456789012:role/Admin",
"accountId":"123456789012",
"userName":"Admin"
},
"webIdFederationData":{
},
"attributes":{
"creationDate":"2022-04-08T14:11:34Z",
"mfaAuthenticated":"false"
}
}
},
"eventTime":"2022-04-08T14:11:49Z",
"eventSource":"aoss.amazonaws.com",
"eventName":"CreateCollection",
"awsRegion":"us-east-1",
"sourceIPAddress":"AWS Internal",
"userAgent":"aws-cli/2.1.30 Python/3.8.8 Linux/5.4.176-103.347.amzn2int.x86_64 exe/x86_64.amzn.2 prompt/off command/aoss.create-collection",
"errorCode":"HttpFailureException",
"errorMessage":"An unknown error occurred",
"requestParameters":{
"accountId":"123456789012",
"name":"test-collection",
"description":"A sample collection",
"clientToken":"d3a227d2-a2a7-49a6-8fb2-e5c8303c0718"
},
"responseElements": null,
"requestID":"12345678-1234-1234-1234-987654321098",
"eventID":"12345678-1234-1234-1234-987654321098",
"readOnly":false,
"eventType":"AwsApiCall",
"managementEvent":true,
"recipientAccountId":"123456789012",
"eventCategory":"Management",
"tlsDetails":{
"clientProvidedHostHeader":"user.aoss-sample.us-east-1.amazonaws.com"
}
}
```
# Surveillance des événements OpenSearch sans serveur à l'aide d'Amazon EventBridge
Amazon OpenSearch Service s'intègre EventBridge à Amazon pour vous informer de certains événements affectant vos domaines. Les événements AWS liés aux services sont diffusés EventBridge en temps quasi réel. Les mêmes événements sont également envoyés à [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatchEvents.html), le prédécesseur d'Amazon EventBridge. Vous pouvez rédiger des règles pour indiquer les événements qui vous intéressent et les actions automatisées à effectuer lorsqu'un événement correspond à une règle. Voici quelques exemples d'actions que vous pouvez activer automatiquement :
+ Invoquer une fonction AWS Lambda
+ Appel d'une Run Command Amazon EC2
+ Relais de l’événement à Amazon Kinesis Data Streams
+ Activation d'une machine à états AWS Step Functions
+ Notification d’une rubrique Amazon SNS ou d’une file d’attente Amazon SQS
Pour plus d'informations, consultez la section [Commencer avec Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) dans le *guide de EventBridge l'utilisateur Amazon*.
## Configuration des notifications
Vous pouvez utiliser [les notifications AWS utilisateur](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) pour recevoir des notifications lorsqu'un événement OpenSearch sans serveur se produit. Un événement est un indicateur d'un changement dans l'environnement OpenSearch sans serveur, par exemple lorsque vous atteignez la limite maximale d'utilisation de votre OCU. Amazon EventBridge reçoit l'événement et envoie une notification au centre de AWS Management Console notifications et aux canaux de diffusion que vous avez choisis. Vous recevez une notification lorsqu'un événement correspond à une règle que vous avez spécifiée.
## OpenSearch Événements relatifs aux unités de calcul (OCU)
OpenSearch Serverless envoie des événements EventBridge lorsque l'un des événements suivants liés à l'OCU se produit.
### L'utilisation de l'OCU approche de la limite maximale
OpenSearch Serverless envoie cet événement lorsque l'utilisation de votre OCU de recherche ou d'indexation atteint 75 % de votre limite de capacité. L'utilisation de votre OCU est calculée en fonction de votre limite de capacité configurée et de votre consommation actuelle d'OCU.
**Exemple**
Voici un exemple d'événement de ce type (recherche OCU) :
```
{
"version": "0",
"id": "01234567-0123-0123-0123-012345678901",
"detail-type": "OCU Utilization Approaching Max Limit",
"source": "aws.aoss",
"account": "123456789012",
"time": "2016-11-01T13:12:22Z",
"region": "us-east-1",
"resources": ["arn:aws:es:us-east-1:123456789012:domain/test-domain"],
"detail": {
"eventTime" : 1678943345789,
"description": "Your search OCU usage is at 75% and is approaching the configured maximum limit."
}
}
```
Voici un exemple d'événement de ce type (index OCU) :
```
{
"version": "0",
"id": "01234567-0123-0123-0123-012345678901",
"detail-type": "OCU Utilization Approaching Max Limit",
"source": "aws.aoss",
"account": "123456789012",
"time": "2016-11-01T13:12:22Z",
"region": "us-east-1",
"resources": ["arn:aws:es:us-east-1:123456789012:domain/test-domain"],
"detail": {
"eventTime" : 1678943345789,
"description": "Your indexing OCU usage is at 75% and is approaching the configured maximum limit."
}
```
### L'utilisation de l'OCU a atteint la limite maximale
OpenSearch Serverless envoie cet événement lorsque l'utilisation de votre OCU de recherche ou d'indexation atteint 100 % de votre limite de capacité. L'utilisation de votre OCU est calculée en fonction de votre limite de capacité configurée et de votre consommation actuelle d'OCU.
**Exemple**
Voici un exemple d'événement de ce type (recherche OCU) :
```
{
"version": "0",
"id": "01234567-0123-0123-0123-012345678901",
"detail-type": "OCU Utilization Reached Max Limit",
"source": "aws.aoss",
"account": "123456789012",
"time": "2016-11-01T13:12:22Z",
"region": "us-east-1",
"resources": ["arn:aws:es:us-east-1:123456789012:domain/test-domain"],
"detail": {
"eventTime" : 1678943345789,
"description": "Your search OCU usage has reached the configured maximum limit."
}
}
```
Voici un exemple d'événement de ce type (index OCU) :
```
{
"version": "0",
"id": "01234567-0123-0123-0123-012345678901",
"detail-type": "OCU Utilization Reached Max Limit",
"source": "aws.aoss",
"account": "123456789012",
"time": "2016-11-01T13:12:22Z",
"region": "us-east-1",
"resources": ["arn:aws:es:us-east-1:123456789012:domain/test-domain"],
"detail": {
"eventTime" : 1678943345789,
"description": "Your indexing OCU usage has reached the configured maximum limit."
}
}
```