View a markdown version of this page

Étape 2 : Lancez votre zone d'atterrissage à l'aide des API AWS Control Tower - AWS Control Tower

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.

Étape 2 : Lancez votre zone d'atterrissage à l'aide des API AWS Control Tower

Vous pouvez utiliser les API AWS Control Tower pour lancer votre zone d'atterrissage. Cette section explique comment créer le fichier manifeste de zone d'atterrissage requis et comment l'utiliser avec l'opération CreateLandingZone d'API.

Création du fichier manifeste

Le fichier manifeste est un document JSON qui spécifie la configuration de votre zone d'atterrissage. Avec la version 4.0 de Landing Zone, de nombreux composants sont désormais optionnels, ce qui permet un déploiement plus flexible.

Structure du manifeste

Vous trouverez ci-dessous la structure complète du fichier manifeste avec toutes les configurations disponibles :

{ "accessManagement": { "enabled": true // Required - Controls IAM Identity Center integration }, "backup": { "enabled": true, // Required - Controls AWS Backup integration "configurations": { "backupAdmin": { "accountId": "111122223333" // Backup administrator account }, "centralBackup": { "accountId": "111122224444" // Central backup account }, "kmsKeyArn": "arn:aws:kms:region:account-id:key/key-id" } }, "centralizedLogging": { "accountId": "111122225555", // Log archive account "enabled": true, // Required - Controls centralized logging "configurations": { "accessLoggingBucket": { "retentionDays": 365 // Minimum value: 1 }, "loggingBucket": { "retentionDays": 365 // Minimum value: 1 }, "kmsKeyArn": "arn:aws:kms:region:account-id:key/key-id" } }, "config": { "accountId": "111122226666", // Config aggregator account "enabled": true, // Required - Controls AWS Config integration "configurations": { "accessLoggingBucket": { "retentionDays": 365 // Minimum value: 1 }, "loggingBucket": { "retentionDays": 365 // Minimum value: 1 }, "kmsKeyArn": "arn:aws:kms:region:account-id:key/key-id" } }, "governedRegions": [ // Optional - List of regions to govern "us-east-1", "us-west-2" ], "securityRoles": { "enabled": true, // Required - Controls security roles creation "accountId": ""111122226666" // Security/Audit account } }

Remarques importantes

  • Tous les enabled drapeaux doivent figurer dans le manifeste.

  • Si vous désactivez l'intégration AWS Config ("config.enabled": false), vous devez également désactiver les intégrations suivantes :

    • Rôles de sécurité ("securityRoles.enabled": false)

    • Gestion des accès ("accessManagement.enabled": false)

    • Sauvegarde ("backup.enabled": false)

  • Les identifiants de compte doivent être des identifiants de AWS compte à 12 chiffres valides.

  • Les ARN de clé KMS doivent être des ARN de AWS KMS clé valides.

  • Les jours de rétention doivent être d'au moins 1.

Utilisation de l' CreateLandingZone API

Pour créer votre zone d'atterrissage à l'aide de l'API :

aws controltower create-landing-zone --landing-zone-version 4.0 --manifest file://manifest.json

L'API renverra un identifiant d'opération de zone d'atterrissage que vous pourrez utiliser pour suivre la progression de la création de votre zone d'atterrissage. Exemple de réponse :

{ "arn": "arn:aws:controltower:us-west-2:123456789012:landingzone/1A2B3C4D5E6F7G8H", "operationIdentifier": "55XXXXXX-e2XX-41XX-a7XX-446XXXXXXXXX" }

Vous pouvez surveiller l'état des opérations à l'aide de l'GetLandingZoneOperationAPI qui renvoie un état de SUCCEEDEDFAILED, ou IN_PROGRESS :

aws controltower get-landing-zone-operation --operation-identifier "55XXXXXX-eXXX-4XXX-aXXX-44XXXXXXXXXX"

Ce qui a changé dans la version 4.0 de Landing Zone

Changements importants apportés à la structure et aux exigences du manifeste :

  • Structure de l'organisation

    • organizationStructurela définition a été supprimée du manifeste

    • Les clients peuvent désormais définir leur propre structure organisationnelle

    • Seule exigence : les comptes d'intégration de services doivent se trouver dans la même unité d'organisation, directement sous root

  • Drapeaux activés

    • Toutes les configurations d'intégration de services comportent un enabled indicateur qui est désormais un champ obligatoire.

    • Les clients doivent toujours fournir une valeur booléenne. Aucune valeur par défaut n'est fournie.

    • Les clients doivent explicitement indiquer enable/disable chaque configuration d'intégration de services dans le manifeste :

      • accessManagement

      • backup

      • centralizedLogging

      • config

      • securityRoles

  • Rôles de sécurité

    • L'intégration des rôles de sécurité est désormais facultative

    • Nouveau enabled drapeau introduit pour gérer securityRoles le déploiement

    • Lorsqu'elles sont désactivées, les fonctionnalités de sécurité associées ne seront pas mises en œuvre

  • AWS Intégration de la configuration

    • Une nouvelle section d'intégration du service AWS Config a été ajoutée au manifeste, comme config pour les champs suivants :

      • enabled: indicateur booléen requis pour gérer le déploiement de l'intégration AWS Config

      • accountId: ID de compte AWS pour l'agrégateur AWS Config

      • configurations :

        • accessLoggingBucket.retentionDays: Période de conservation des journaux d'accès

        • loggingBucket.retentionDays: Période de conservation des journaux AWS Config

        • kmsKeyArn: clé KMS pour le chiffrement