---
sourceDocument: Options de la ServiceNow AI Platform en Australie
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/servicenow-platform

 Release :

    - australia

ft:locale :

    - fr-FR

ft:publication_title :

    - Options de la ServiceNow AI Platform en Australie

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Classe dans le cloud

# Classe dans le cloud {#ariaid-title1}

* Rversion finale: Australia
* 
* Mis à jour 12 mars 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes de lecture

Description, règle d'identification et autres structures de schéma importantes pour les classes dans le CMDB cloud.
Pour obtenir une description des tables communes CMDB dans un système de base, reportez-vous à la section [Descriptions des tables CMDB](https://servicenow-prod.fluidtopics.net/5uQS5yWc~kL4~cUVuiRiJQ "Liste des tables de la CMDB dans un système de base avec leur nom, leur étiquette et une description du type d’informations stockées dans la table.").
Figure 1. Modèle de classe AWS/Azure/OpenStack Figure 2. Modèle de schéma cloud de centre de données IBM Figure 3. Modèle de schéma de centre de données Google

## Description du schéma dans le cloud {#class-cloud__section_sld_v4g_mkb}

ServiceNow dispose de modèles étendus d'environnements cloud, notamment Amazon Web Services (AWS), le service Microsoft Azure, Google Cloud Platform (GCP) et IBM Cloud. En ce qui concerne le calcul, les modèles pour les environnements cloud et pour les serveurs virtuels sont similaires. Par exemple, les instances d'Amazon Elastic Compute Cloud (EC2) et de Microsoft® Azure Cloud Compute sont une extension des instances d'ordinateur virtuel, où les CI sont généralement créés en se connectant directement à l'inventaire cloud. Toutefois, les instances d'ordinateur virtuel ne représentent pas l'utilisation réelle de l'instance dans le cloud.

Le compte de services dans le cloud \[cmdb_ci_cloud_service_account\] est la classe principale pour le suivi des comptes dans le cloud tels que AWS, GCP et Azure (remplaçant par exemple l'utilisation de la table cmdb_ci_aws_account pour AWS).

Par exemple, vous pouvez représenter un hôte invité Linux exécuté sur Amazon EC2 par la classe Server \[cmdb_ci_server\], avec l'attributIsVirtual True et la relation Runs on :Runs à l'instance EC2. L'intégration d'AWS Config Service ou de l'application Amazon CloudWatch fournit des informations sur l'ID de l'objet EC2. En cours d'exécution Découverte ou un autre programme de découverte sur l'hôte Linux invité, fournit le hostnamefichier .  
Vous devez disposer des éléments suivants :

* Obtention de l'UUID correct qui est stocké dans la table Numéro de série \[cmdb_serial_number\].
* Connexion/création de l'instance de cloud au système d'exploitation hôte, mise en correspondance sur l'UUID/ID d'objet et création de la relation Exécutions sur :exécutions.
{#class-cloud__ul_mhp_yqg_mkb}

En outre, il existe un modèle complet de stockage, de mise en réseau, de Lamda/fonctions en plus de la modélisation de différentes régions en utilisant le concept de la table Centre de données logique \[cmdb_ci_logical_datacenter\] avec la relation Hosts :HostedOn avec le calcul, le stockage, etc.

## Règle d'identification {#class-cloud__section_egp_xtg_mkb}

Le système de base contient des règles d'identification prédéfinies pour les classes de schéma dans le cloud. Un objet dans le cloud nécessite les éléments d'identification suivants :

* ID d'objet : qui est synonyme des ID que les fournisseurs dans le cloud utilisent pour chaque type de ressource dans le cloud, tels qu'Azure Compute, EC2 et Amazon Simple Storage Service (S3).
* L'ID d'objet est unique pour chaque région et a donc une relation dépendante nécessitant des informations de la table Centre de données logique \[cmdb_ci_logical_data_center\] sur la région où la ressource dans le cloud est hébergée. Par exemple, AWS Datacenter \[cmdb_ci_aws_datacenter\], Azure Datacenter \[cmdb_ci_azure_datacenter\], Google Datacenter \[cmdb_ci_google_datacenter\] qui sont étendus à partir de Logical Datacenter.

  Le centre de données logique lui-même comporte deux entrées d'identificateur :
  * ID d'objet : ID unique du centre de données logique, le cas échéant
  * Région : région de la ressource dans le cloud
  {#class-cloud__ul_nbh_nrt_4kb}
* Le centre de données logique a une dépendance aux comptes de service dans le cloud, qui a deux entrées d'identificateur :

  * ID d'objet : ID unique du compte, le cas échéant.
  * ID de compte : ID de compte unique qui englobe les différentes ressources dans le cloud. L'ID de compte est généralement plus applicable que l'ID d'objet.
  {#class-cloud__ul_xvk_n5g_mkb}
{#class-cloud__ul_nhh_xjz_4kb}

Pour plus d'informations, consultez [Identification et rapprochement CMDB (IRE)](https://servicenow-prod.fluidtopics.net/KOsRrNss4UOWoYUMdfe9vg "Le module Identification et rapprochement fournit un cadre centralisé pour identifier et rapprocher les données provenant de différentes sources de données. Cela permet de préserver l’intégrité de la CMDB table et de certaines non-tablesCMDB lorsque plusieurs sources de données sont utilisées pour créer et mettre à jour les enregistrements de CI.").