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.

# Comprendre les artefacts de réseau générés
<a name="transform-migrations-generated-artifacts"></a>

AWS Transform génère votre réseau cible sous forme d'infrastructure en tant que code (IaC) afin que vous puissiez le réviser et le déployer à l'aide de vos propres outils et processus. Il produit le réseau en un rien de temps, et vous décidez comment et quand le déployer : vérifiez-le par rapport à vos propres normes, adaptez-le au fonctionnement de votre équipe, déployez-le de la manière dont vous déployez déjà l'infrastructure et maintenez le contrôle des versions afin de pouvoir suivre les modifications et le déployer à nouveau ultérieurement.

Vous pouvez trouver ces artefacts dans un compartiment Amazon S3 de votre AWS compte cible. AWS Transformez les écritures AWS CDK et CloudFormation pour chaque migration, ainsi que tous les autres formats que vous avez sélectionnés, vers le même emplacement. Le bucket se trouve dans le AWS compte et dans AWS la région que vous avez spécifiés pour le connecteur et commence par`transform-vmware-target-`. Pour plus d'informations sur le connecteur, consultez[Étape 3 : Configuration du connecteur](transform-vmware-connect-target-account.md#transform-vmware-cta-connector).

Utilisez le lien fourni dans AWS Transform pour ouvrir les artefacts générés dans ce compartiment. Les artefacts générés incluent un `README.md` fichier qui explique comment utiliser les modèles générés.

**Important**  
Pour vérifier que le fichier téléchargé n'a pas été corrompu ou altéré, générez et téléchargez un checksum, puis comparez-le à un hachage généré localement à l'aide de la commande. `openssl dgst -sha256 -binary <file.zip> | base64`

## Structure du répertoire de sortie
<a name="transform-migrations-generated-artifacts-layout"></a>

Chaque format IaC possède son propre répertoire de sortie (`cdk/`et `cfn/``cdk_l2/`,`terraform/`, ou`lza/`). Chacun contient un `network_segments/` répertoire pour les définitions de réseau et un `security/` répertoire pour les définitions de sécurité. Les arbres suivants montrent la structure de chaque format, avec `<segment>` un espace réservé pour chaque segment :

**CloudFormation**(`cfn/`) contient des CloudFormation modèles.

```
cfn/
├── network_segments/
│   └── <segment>/                        # CloudFormation template JSON
└── security/
    ├── <segment>_security/
    └── <segment>_security_dependencies/   # only when the segment has cross-VPC rules
```

**CDK L1** (`cdk/`) contient un AWS CDK projet. Il inclut un `README.md` fichier.

```
cdk/
├── README.md
├── network_segments/
│   └── <segment>/
└── security/
    ├── security-interface.json
    ├── validate-references.py
    ├── <segment>_security/
    └── <segment>_security_dependencies/   # only when the segment has cross-VPC rules
```

**CDK L2** (`cdk_l2/`) contient des AWS CDK projets qui utilisent des constructions de niveau supérieur (L2) issues de la bibliothèque de constructions. AWS CDK Les constructions L2 fournissent des valeurs par défaut raisonnables et sont moins passe-partout que les constructions L1 utilisées par CDK L1. Pour plus d'informations, consultez la section [Constructions](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html) du *guide du Cloud Development Kit AWS (AWS CDK) développeur*. Les segments de charge de travail sont fournis sous forme de fichiers zip de projet complets, et le déploiement `README.md` se fait dans chaque fichier zip.

```
cdk_l2/
├── network_segments/
│   ├── <segment>/                         # hub and spoke CDK app (.ts source)
│   └── <segment>/                         # workload segment (.zip)
└── security/
    ├── security-interface.json
    ├── validate-references.py
    ├── <segment>_security/                # .zip
    └── <segment>_security_dependencies/   # .ts source, only when the segment has cross-VPC rules
```

**Terraform** (`terraform/`) est livré sous forme de fichier zip unique.

```
terraform/
├── README.md, LICENSE.txt, main.tf, outputs.tf
├── modules/                                # networking, vpc, workload-vpc
├── network_segments/
│   └── <segment>/                         # main.tf, outputs.tf, variables.tf, versions.tf, terraform.tfvars
└── security/                               # standalone Terraform root
    ├── main.tf, locals.tf, variables.tf, terraform.tfvars
    ├── security-interface.json
    ├── validate-references.py
    ├── modules/security/
    └── security_segments/
        ├── <segment>_security/            # main.tf, variables.tf, terraform.tfvars (plus versions.tf for cross-account segments)
        └── <segment>_security_dependencies/   # only when the segment has cross-VPC rules
```

**LZA** (`lza/`) contient les fichiers de configuration de Landing Zone Accelerator et les applications par VPC AWS CDK .

```
lza/
├── README.md
├── network_segments/
│   ├── network-config.yaml
│   └── replacements-config.yaml
└── security/
    ├── <segment>/                          # one CDK app per VPC segment
    │   ├── <stack_name>.ts                 #   security group stack
    │   ├── app.ts
    │   ├── cdk.json
    │   ├── tsconfig.json
    │   └── package.json
    └── <segment>_dependencies/             # same file set; only when the segment has cross-VPC rules
```

## Définitions de sécurité
<a name="transform-migrations-generated-artifacts-security"></a>

À l'intérieur`security/`, les groupes de sécurité sont divisés par segment. Les groupes de sécurité propres à chaque segment figurent dans son `<segment>_security/` répertoire. Si un segment possède des règles qui font référence à un autre segment, ses règles inter-VPC sont séparées dans un `<segment>_security_dependencies/` répertoire qui se déploie en dernier, une fois que les groupes de sécurité auxquels il fait référence existent.

Un segment dont le VPC existe déjà dans le compte conserve son nom d'origine sans `security/<segment>/` suffixe.

Les `terraform/` sorties `cdk/``cdk_l2/`,, et incluent deux fichiers supplémentaires dans `security/` :
+ `security-interface.json`répertorie les identifiants réseau utilisés par chaque segment, avec une entrée par segment. Le type d'identifiant dépend du format : noms CloudFormation d'exportation pour CloudFormation, CDK L1 et CDK L2, ou noms de paramètres SSM pour Terraform. Un segment qui n'importe rien n'a pas d'entrée.
+ `validate-references.py`est un script que vous exécutez avant de déployer un segment. Cela confirme que les identifiants réseau existent `security-interface.json` déjà dans votre AWS compte. Son exécution nécessite le AWS CLI, avec des informations d'identification configurées pour le compte cible et la région.

**Note**  
Déployez les ressources `network_segments/` avant qu'elles n'arrivent`security/`. Les définitions de sécurité font référence aux exportations et aux paramètres des ressources réseau, qui doivent déjà exister.

## Multi-account sortie
<a name="transform-migrations-generated-artifacts-accounts"></a>

Un déploiement multicompte ajoute un fichier manifeste par format à la racine du répertoire de sortie. Un déploiement à compte unique ne comporte aucun fichier manifeste. Chaque format possède son propre manifeste :
+ `manifest-cdk_l1.json`pour le format AWS CDK L1.
+ `manifest-cdk_l2.json`pour le format AWS CDK L2.
+ `manifest-terraform.json`pour le format Terraform, à la `terraform/` racine.
+ `manifest-lza.json`pour le format LZA.

L'attribution des comptes n'est pas indiquée dans la structure des dossiers. Il est contenu dans des champs de données : chaque manifeste répertorie ses segments avec un compte cible (le `segments[].targetAccount` champ du manifeste), et chaque entrée `security-interface.json` contient un `targetAccount` champ.