AWSIntégration zéro ETL pour les sources de base de données autogérées - AWSService de Migration de Base de Données
Comment fonctionne l'intégration Zero-ETL pour les sources de base de données autogéréesConfiguration des autorisations IAM et du chiffrement pour une intégration sans ETL

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.

AWSIntégration zéro ETL pour les sources de base de données autogérées

AWSL'intégration Zero-ETL est une solution entièrement gérée qui rend les données transactionnelles et opérationnelles disponibles dans Amazon Redshift, Amazon S3 et Amazon S3 Tables à partir de plusieurs sources de bases de données opérationnelles et transactionnelles. À l'aide de Zero-ETL, vous pouvez répliquer les données de vos bases de données sources autogérées telles que MySQL, PostgreSQL, SQL Server et Oracle vers Amazon Redshift via les points de terminaison source existants (). AWS Database Migration Service AWS DMS La synchronisation automatique évite le processus traditionnel d'extraction, de transformation et de chargement (ETL). Il permet également des analyses en temps réel et des charges de travail basées sur l'IA. Pour plus d'informations, consultez la section Intégrations Zero-ETL dans le guide de gestion Amazon Redshift.

L'intégration Zero-ETL offre les avantages suivants :

  • Réplication des données en temps réel : synchronisation continue des données entre les bases de données Oracle et Amazon Redshift avec une latence minimale.

  • Élimination des pipelines ETL complexes : il n'est pas nécessaire de créer et de gérer des solutions d'intégration de données personnalisées.

  • Frais opérationnels réduits — Configuration et gestion automatisées grâce à AWSAPIs.

  • Architecture d'intégration des données simplifiée — Intégration parfaite entre les bases de données autogérées et les services AWS d'analyse.

  • Sécurité améliorée — Chiffrement intégré et contrôles d'accès IAM.

Comment fonctionne l'intégration Zero-ETL pour les sources de base de données autogérées

Vous pouvez utiliser des AWS DMS points de terminaison existants créés précédemment pour les bases de données autogérées ou en créer de nouveaux.

  • Utilisez la AWS Glue console ou la CLI pour créer l'intégration Zero-ETL avec Amazon Redshift en tant que cible dans AWS Glue le catalogue. Vous pouvez spécifier un schéma et un filtre de table lors de la création d'intégrations sans ETL.

  • Des ressources supplémentaires en lecture seule liées aux intégrations sont automatiquement créées au sein du service. AWS DMS Ces ressources, y compris le moteur Zero-ETL, sont utilisées pour lancer des processus de chargement complet et de modification continue des données, afin de synchroniser les données avec la base de données cible Amazon Redshift.

  • Vous contrôlez le chiffrement de vos données lorsque vous créez la source d’intégration, lorsque vous créez l’intégration zéro ETL et lorsque vous créez l’entrepôt de données Amazon Redshift.

  • L’intégration surveille l’état du pipeline de données et effectue la récupération en cas de problèmes, lorsque cela est possible.

  • Vous pouvez créer des intégrations à partir de sources du même type dans un seul entrepôt des données Amazon Redshift afin de dériver des informations holistiques entre plusieurs applications.

Une fois les données répliquées, vous pouvez utiliser les fonctionnalités d'analyse d'Amazon Redshift. Par exemple, le machine learning (ML) intégré, les vues matérialisées, le partage de données et l’accès direct à plusieurs magasins de données et lacs de données. Pour les ingénieurs de données, les intégrations sans ETL permettent d'accéder à des données sensibles au facteur temps qui, autrement, peuvent être retardées en raison d'erreurs intermittentes dans des pipelines de données complexes. Vous pouvez exécuter des requêtes analytiques et des modèles ML sur des données transactionnelles afin de dériver des informations en temps opportun sur les événements sensibles au temps et les décisions commerciales.

Vous pouvez créer un abonnement aux notifications d'événements Amazon Redshift pour être automatiquement averti en cas de problème lié à une intégration zéro ETL. Pour consulter la liste des notifications d'événements liés à l'intégration, consultez la section Notifications d'événements d'intégration Zero-ETL avec Amazon. EventBridge Le moyen le plus simple de créer un abonnement est d'utiliser la console Amazon Simple Notification Service. Pour en savoir plus sur la création d’une rubrique Amazon SNS et l’abonnement à cette rubrique, consultez Démarrage avec Amazon SNS dans le Guide du développeur Amazon Simple Notification Service.

Configuration des autorisations IAM et du chiffrement pour une intégration sans ETL

Pour créer et gérer des intégrations sans ETL, vous devez configurer les autorisations IAM, les clés de chiffrement AWS Key Management Service (AWS KMS) et les politiques de ressources appropriées. Cette section fournit des conseils sur la configuration des composants de sécurité requis.

Conditions préalables

Avant de créer une intégration zéro ETL, assurez-vous de disposer des éléments suivants :

  • Un utilisateur ou un rôle IAM doté des autorisations appropriées pour créer et gérer des intégrations

  • Points de terminaison AWS DMS source existants pour vos bases de données autogérées

  • Un cluster provisionné par Amazon Redshift ou un espace de noms sans serveur comme cible

  • Configuration réseau, y compris les sous-réseaux VPC et les groupes de sécurité

Création d'une clé KMS

Créez d'abord une AWS KMS clé gérée par le client pour chiffrer les données dans votre intégration Zero-ETL. L'exemple suivant crée une clé de chiffrement symétrique : 

aws kms create-key \
  --description "On-prem Zero-ETL Integration Encryption Key" \
  --key-usage ENCRYPT_DECRYPT \
  --key-spec SYMMETRIC_DEFAULT \
  --region region

Notez les éléments KeyId et Arn contenus dans la réponse, car vous en aurez besoin lors de la configuration de la politique clé et de la création de l'intégration.

Exemple de sortie :

{
    "KeyMetadata": {
        "AWSAccountId": "account-id",
        "KeyId": "4e2c14f8-7abe-4aec-851a-379f6ed973a8",
        "Arn": "arn:aws:kms:region:account-id:key/4e2c14f8-7abe-4aec-851a-379f6ed973a8",
        "CreationDate": 1763155061.148,
        "Enabled": true,
        "Description": "Zero-ETL Integration Encryption Key",
        "KeyUsage": "ENCRYPT_DECRYPT",
        "KeyState": "Enabled",
        "Origin": "AWS_KMS",
        "KeyManager": "CUSTOMER",
        "CustomerMasterKeySpec": "SYMMETRIC_DEFAULT",
        "KeySpec": "SYMMETRIC_DEFAULT",
        "EncryptionAlgorithms": [
            "SYMMETRIC_DEFAULT"
        ],
        "MultiRegion": false
    }
}

Configuration de la politique des clés KMS

Après avoir créé la clé KMS, configurez la politique de clé pour autoriser Amazon Redshift et les AWS Glue services à utiliser la clé pour les opérations de chiffrement et de déchiffrement. La politique de clé doit accorder les autorisations nécessaires aux responsables du service et inclure le contexte de chiffrement qui sera utilisé lors de la création de l'intégration.

L'exemple suivant montre une politique clé pour les intégrations sans ETL :

{
    "Version": "2012-10-17",		 	 	 
    "Id": "key-default-1",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::account-id:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allows the Redshift and glue service principal to add a grant to a KMS key",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "redshift.amazonaws.com",
                    "glue.amazonaws.com"
                ]
            },
            "Action": "kms:CreateGrant",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
	              "kms:EncryptionContext:context-key": "context-value"
                },
                "ForAllValues:StringEquals": {
                    "kms:GrantOperations": [
                        "Decrypt",
                        "GenerateDataKey",
                        "CreateGrant",
                        "GenerateDataKeyWithoutPlaintext",
                        "ReEncryptTo"
                    ]
                }
            }
        }
    ]
}

La kms:EncryptionContext condition doit correspondre au contexte de chiffrement supplémentaire que vous spécifiez lors de la création de l'intégration. Vous pouvez mettre à jour la politique clé à l'aide de la AWS KMS console ou de la commande CLI suivante : 

aws kms put-key-policy \
  --key-id key-id \
  --policy-name default \
  --policy file://kms-key-policy.json

Création d'un utilisateur IAM et configuration AWS de la CLI

Créez un utilisateur IAM qui sera utilisé pour gérer les intégrations Zero-ETL et configurer la AWS CLI avec les informations d'identification appropriées.

  1. Créez un utilisateur IAM :

    aws iam create-user --user-name cli-user

  2. Créez des clés d'accès pour l'utilisateur :

    aws iam create-access-key --user-name cli-user

    Enregistrez le AccessKeyId et SecretAccessKey depuis la sortie, car vous en aurez besoin pour configurer la AWS CLI.

Création et attachement d’une politique IAM

Créez une politique IAM qui accorde des autorisations pour les opérations d'intégration sans ETL. La politique doit inclure les autorisations pourAWS Glue,AWS DMS, Amazon RedshiftAWS KMS, et.

Enregistrez la politique suivante dans un fichier (par exemple,/tmp/zetl-policy.json) :

{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ZetlGlueIntegrationAccess",
            "Effect": "Allow",
            "Action": [
                "glue:CreateIntegration",
                "glue:ModifyIntegration",
                "glue:DeleteIntegration",
                "glue:DescribeIntegrations",
                "glue:DescribeInboundIntegrations"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DMSIntegrationAccess",
            "Effect": "Allow",
            "Action": [
                "dms:CreateOutboundIntegration",
                "dms:ModifyOutboundIntegration",
                "dms:CreateEndpoint",
                "dms:DescribeEndpoints",
                "dms:ModifyEndpoint",
                "dms:DeleteEndpoint",
                "dms:TestConnection"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ZetlRedshiftFullAccess",
            "Effect": "Allow",
            "Action": [
                "redshift:*",
                "redshift-serverless:*",
                "ec2:DescribeAccountAttributes",
                "ec2:DescribeAddresses",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcs",
                "ec2:DescribeInternetGateways",
                "sns:CreateTopic",
                "sns:Get*",
                "sns:List*",
                "cloudwatch:Describe*",
                "cloudwatch:Get*",
                "cloudwatch:List*",
                "cloudwatch:PutMetricAlarm",
                "cloudwatch:EnableAlarmActions",
                "cloudwatch:DisableAlarmActions",
                "tag:GetResources",
                "tag:UntagResources",
                "tag:GetTagValues",
                "tag:GetTagKeys",
                "tag:TagResources"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ZetlRedshiftDataAPI",
            "Effect": "Allow",
            "Action": [
                "redshift-data:ExecuteStatement",
                "redshift-data:CancelStatement",
                "redshift-data:ListStatements",
                "redshift-data:GetStatementResult",
                "redshift-data:DescribeStatement",
                "redshift-data:ListDatabases",
                "redshift-data:ListSchemas",
                "redshift-data:ListTables",
                "redshift-data:DescribeTable"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ZetlKMSAccess",
            "Effect": "Allow",
            "Action": [
                "kms:CreateKey",
                "kms:DescribeKey",
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:GenerateDataKey",
                "kms:ListKeys",
                "kms:CreateAlias",
                "kms:ListAliases",
                "kms:CreateGrant"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ZetlSecretsManagerAccess",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:PutSecretValue",
                "secretsmanager:CreateSecret",
                "secretsmanager:UpdateSecret",
                "secretsmanager:DeleteSecret",
                "secretsmanager:DescribeSecret",
                "secretsmanager:ListSecrets",
                "secretsmanager:GetResourcePolicy",
                "secretsmanager:PutResourcePolicy",
                "secretsmanager:ValidateResourcePolicy"
            ],
            "Resource": "*"
        }
    ]
}

Créez la politique et associez-la à l'utilisateur IAM :

aws iam create-policy \
  --policy-name ZetlCustomPolicy \
  --policy-document file:///tmp/zetl-policy.json

aws iam attach-user-policy \
  --policy-arn arn:aws:iam::account-id:policy/ZetlCustomPolicy \
  --user-name cli-user

Configuration du profil AWS CLI

Configurez un profil AWS CLI avec les informations d'identification utilisateur créées lors des étapes précédentes :

aws configure set aws_access_key_id ACCESS_KEY_ID --profile cli-user
aws configure set aws_secret_access_key SECRET_ACCESS_KEY --profile cli-user
aws configure set region region --profile cli-user
aws configure set output json --profile cli-user

Testez la configuration du profil :

aws sts get-caller-identity --profile cli-user

La sortie doit afficher l'ID de compte, l'ID utilisateur et l'ARN de l'utilisateur, confirmant que le profil est correctement configuré.

Création d'une politique de ressources Redshift

Créez une politique de ressources Amazon Redshift pour autoriser le point de terminaison AWS DMS source à créer des intégrations entrantes avec votre espace de noms Amazon Redshift. Cette politique est attachée à l'espace de noms Amazon Redshift et contrôle les sources autorisées à y répliquer des données.

L'exemple suivant montre comment créer une politique de ressources pour un espace de noms Amazon Redshift :

aws redshift put-resource-policy \
  --policy '{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": ["redshift.amazonaws.com"]
        },
        "Action": ["redshift:AuthorizeInboundIntegration"],
        "Condition": {
          "StringEquals": {
            "aws:SourceArn": "arn:aws:dms:region:account-id:endpoint:endpoint-id"
          }
        }
      },
      {
        "Effect": "Allow",
        "Principal": {
          "AWS": "account-id"
        },
        "Action": [
          "redshift:CreateInboundIntegration",
          "redshift:ModifyInboundIntegration"
        ]
      }
    ]
  }' \
  --resource-arn arn:aws:redshift:region:account-id:namespace:namespace-id \
  --region region

Remplacez les espaces réservés suivants :

  • region— La AWS région où se trouvent vos ressources

  • account-id— Votre identifiant AWS de compte

  • endpoint-id— L'ID de votre point de terminaison AWS DMS source

  • namespace-id— L'ID de votre espace de noms Amazon Redshift

Exemple : création d'une intégration zéro ETL avec chiffrement

Après avoir configuré les autorisations et les clés de chiffrement nécessaires, vous pouvez créer une intégration zéro ETL à l'aide de l'AWS GlueAPI. L'exemple suivant illustre la création d'une intégration entre une source MySQL et une cible Amazon Redshift avec le chiffrement KMS : 

aws glue create-integration \
  --integration-name mysql-onprem-integration \
  --source-arn arn:aws:dms:region:account-id:endpoint:source-endpoint-id \
  --target-arn arn:aws:redshift:region:account-id:namespace:namespace-id \
  --description "MySQL to Redshift integration" \
  --integration-config '{"SourceProperties":{"SubnetIds":"subnet-id1,subnet-id2,subnet-id3","VpcSecurityGroupIds":"sg-id"}}' \
  --data-filter "include: mysql.*" \
  --kms-key-id arn:aws:kms:region:account-id:key/key-id \
  --additional-encryption-context '{"context-key": "context-value"}' \
  --profile cli-user \
  --region region

La commande inclut les paramètres clés suivants :

  • --integration-name— Un nom unique pour votre intégration

  • --source-arn— L'ARN de votre point de terminaison AWS DMS source

  • --target-arn— L'ARN de votre espace de noms Amazon Redshift

  • --integration-config— Configuration du réseau, y compris les sous-réseaux IDs et les groupes de sécurité

  • --data-filter— Spécifie les schémas et les tables à répliquer

  • --kms-key-id— L'ARN de la AWS KMS clé pour le chiffrement

  • --additional-encryption-context— Paires clé-valeur du contexte de chiffrement qui doivent correspondre à la politique de clé KMS (par exemple,) {"context-key": "context-value"}

  • --profile— Le profil AWS CLI à utiliser (le profil cli-user créé précédemment)

Une fois la création réussie, la commande renvoie les détails de l'intégration, notamment l'ARN de l'intégration, l'état et les paramètres de configuration. Exemple de sortie : 

{
    "SourceArn": "arn:aws:dms:region:account-id:endpoint:endpoint-id",
    "TargetArn": "arn:aws:redshift:region:account-id:namespace:namespace-id",
    "IntegrationName": "mysql-onprem-integration",
    "IntegrationArn": "arn:aws:glue:region:account-id:integration:integration-id",
    "KmsKeyId": "arn:aws:kms:region:account-id:key/key-id",
    "AdditionalEncryptionContext": {
	  "context-key": "context-value"
    },
    "Status": "CREATED",
    "CreateTime": 1763234086.001,
    "DataFilter": "include: mysql.*",
    "IntegrationConfig": {
        "SourceProperties": {
            "SubnetIds": "subnet-id1,subnet-id2,subnet-id3",
            "VpcSecurityGroupIds": "sg-id"
        }
    }
}

Bonnes pratiques de sécurité

Suivez ces bonnes pratiques de sécurité lors de la configuration d'intégrations sans ETL :

  • Utiliser le moindre privilège d'accès : accordez uniquement les autorisations minimales requises pour créer et gérer des intégrations. Envisagez d'utiliser des autorisations au niveau des ressources dans la mesure du possible.

  • Activer le chiffrement : utilisez toujours des AWS KMS clés gérées par le client pour chiffrer les données d'intégration. Spécifiez le contexte de chiffrement pour renforcer la sécurité.

  • Rotation régulière des informations d'identification : si vous utilisez les clés d'accès utilisateur IAM, alternez-les régulièrement. Envisagez plutôt d'utiliser des rôles IAM avec des informations d'identification temporaires.

  • Surveiller l'accès : permet AWS CloudTrail de surveiller les appels d'API liés à la création et à la gestion des intégrations.

  • Restreindre l'accès au réseau : configurez les groupes de sécurité VPC pour limiter l'accès au réseau aux seules ressources requises.

  • Utiliser des politiques en matière de ressources : implémentez des politiques de ressources Amazon Redshift pour contrôler les sources qui peuvent créer des intégrations avec votre entrepôt de données.

  • Ressources de balises : appliquez des balises aux intégrations et aux ressources associées pour une meilleure organisation et un meilleur suivi des coûts.