アカウント間で Amazon Redshift クラスターから Amazon S3 にデータをアンロードする - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

アカウント間で Amazon Redshift クラスターから Amazon S3 にデータをアンロードする

Andrew Kamel、Amazon Web Services

概要

アプリケーションをテストするときは、テスト環境に本番データを使用すると便利です。本番データを使用することで、開発中のアプリケーションをより正確に評価できます。

このパターンは、本番環境の Amazon Redshift クラスターから、Amazon Web Services (AWS) の開発環境の Amazon Simple Storage Service (Amazon S3) バケットにデータを抽出します。

このパターンは、以下を含む開発用アカウントと本番稼働用アカウントの両方のセットアップを段階的に行います。

  • 必要なリソース

  • AWS Identity and Access Management (IAM) ロール

  • Amazon Redshift 接続をサポートするためのサブネット、セキュリティグループ、仮想プライベートクラウド (VPC) のネットワーク調整

  • アーキテクチャをテストするための Python ランタイムを使用する AWS Lambda 関数の例

Amazon Redshift クラスターへのアクセスを許可するために、このパターンは AWS Secrets Manager を使用して関連する認証情報を保存します。Amazon Redshift クラスターの場所がわからなくても、Amazon Redshift クラスターに直接接続するために必要なすべての情報を取得できます。さらに、シークレットの使用をモニタリングできます。

Secrets Manager に保存されるシークレットには、Amazon Redshift クラスターのホスト、データベース名、ポート、および関連する認証情報が含まれます。

このパターンを使用する際のセキュリティ上の考慮事項については、「ベストプラクティス」セクションを参照してください。

前提条件と制限事項

前提条件

制限事項

  • クエリするデータの量によっては、Lambda 関数がタイムアウトする場合があります。

    実行に Lambda の最長タイムアウト (15 分) よりも時間がかかる場合は、Lambda コードに非同期アプローチを使用します。このパターンのコード例では、Python 用の psycopg2 ライブラリを使用していますが、psycopg2 は現在非同期処理をサポートしていません。

  • 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「AWS のサービス (リージョン別)」を参照してください。特定のエンドポイントについては、「サービスエンドポイントとクォータ」ページを参照して、サービスのリンクを選択します。

アーキテクチャ

次の図は、開発用アカウントと本番稼働用アカウントが含まれるターゲットアーキテクチャを示しています。

開発用アカウントの Lambda VPC と本番稼働用アカウントの Amazon Redshift VPC。

この図表は、次のワークフローを示しています:

  1. 開発用アカウントの Lambda 関数は、本番稼働用アカウントの Secrets Manager の Amazon Redshift 認証情報にアクセスするために必要な IAM ロールを引き受けます。

    次に、Lambda 関数は Amazon Redshift クラスターのシークレットを取得します。

  2. 開発用アカウントの Lambda 関数は、この情報を使用して、ピア接続された VPC を介して本番稼働用アカウントの Amazon Redshift クラスターに接続します。

    次に、Lambda 関数はアンロードコマンドを送信して、本番稼働用アカウントの Amazon Redshift クラスターでクエリを実行します。

  3. 本番稼働用アカウントの Amazon Redshift クラスターは、開発用アカウントの S3 バケットにアクセスするための関連する IAM ロールを引き受けます。

    Amazon Redshift クラスターは、クエリされたデータを開発用アカウントの S3 バケットにアンロードします。

Amazon Redshift からのデータのクエリ

次の図は、Amazon Redshift 認証情報を取得して Amazon Redshift クラスターに接続するために使用するロールを示しています。ワークフローは Lambda 関数が開始します。

アカウント間でロールを引き受けるための 3 ステップのプロセス。

この図表は、次のワークフローを示しています:

  1. 開発用アカウントの CrossAccount-SM-Read-Role は、本番稼働用アカウントの SM-Read-Role を引き受けます。

  2. SM-Read-Role ロールは、アタッチされているポリシーを使用して Secrets Manager からシークレットを取得します。

  3. 認証情報は、Amazon Redshift クラスターにアクセスにする際に使用されます。

Simple Storage Service (Amazon S3) へのデータのアップロード

次の図表は、データを抽出して Amazon S3 にアップロードするためのクロスアカウント読み取り/書き込みプロセスを示しています。ワークフローは Lambda 関数が開始します。パターンは Amazon Redshift の IAM ロールを連鎖します。Amazon Redshift クラスターから送信されるアンロードコマンドは、CrossAccount-S3-Write-Role を引き受け、次に S3-Write-Role を引き受けます。このロールの連鎖により、Amazon Redshift は Amazon S3 にアクセスできるようになります。

認証情報の取得、Amazon Redshift へのアクセス、Amazon S3 へのデータのアップロードを行うロール。

このワークフローには、次の手順が含まれます。

  1. 開発用アカウントの CrossAccount-SM-Read-Role は、本番稼働用アカウントの SM-Read-Role を引き受けます。

  2. SM-Read-Role は、Secrets Manager から Amazon Redshift 認証情報を取得します。

  3. Lambda 関数は、Amazon Redshift クラスターに接続し、クエリを送信します。

  4. Amazon Redshift クラスターは CrossAccount-S3-Write-Role を引き受けます。

  5. CrossAccount-S3-Write-Role は、開発用アカウントの S3-Write-Role を引き受けます。

  6. クエリ結果は、開発用アカウントの S3 バケットにアンロードされます。

ツール

AWS のサービス

  • AWS Key Management Service (AWS KMS) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。

  • AWS Lambda は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。

  • Amazon Redshift は、AWS クラウド内でのフルマネージド型、ペタバイト規模のデータウェアハウスサービスです。

  • AWS Secrets Manager を使用すると、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールで置き換えて、プログラムでシークレットを取得することができます。

  • Amazon Simple Storage Service (Amazon S3) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。

コードリポジトリ

このパターンのコードは、GitHub 内の「unload-redshift-to-s3-python」リポジトリで入手できます。

ベストプラクティス

セキュリティについての免責事項

このソリューションを実装する前に、以下の重要なセキュリティ上の推奨事項を検討してください。

  • 開発用アカウントと本番稼働用アカウントを接続すると、スコープが拡大し、全体的なセキュリティ体制が低下する可能性があることに注意してください。このソリューションは一時的にのみデプロイし、必要なデータを抽出してから、すぐにデプロイされたリソースを破棄することを推奨します。リソースを破棄するには、Lambda 関数を削除し、このソリューション用に作成された IAM ロールとポリシーを削除し、アカウント間で付与されたネットワークアクセス権を取り消す必要があります。

  • データを本番環境から開発環境にコピーする前に、セキュリティチームとコンプライアンスチームに相談してください。個人を特定できる情報 (PII)、保護対象医療情報 (PHI)、その他の機密データや規制対象データは、通常、この方法でコピーしてはいけません。公開されている非機密情報 (ショップのフロントエンドからの公開株式データなど) のみをコピーしてください。本番データの使用ではなく、可能な限り、データのトークン化や匿名化、または合成テストデータの生成を検討してください。AWS セキュリティ原則の 1 つは、データからユーザーを遠ざけることです。つまり、デベロッパーは本番稼働用アカウントでオペレーションを実行してはいけません。

  • 開発アカウントの Lambda 関数は本番環境の Amazon Redshift クラスターからデータを読み取ることができるため、Lambda 関数へのアクセスを制限してください。

  • 本番環境の中断を避けるには、次の推奨事項を実装します。

    • テストと開発アクティビティには、別の専用開発アカウントを使用します。

    • 厳格なネットワークアクセス制御を実装し、アカウント間の必要なトラフィックのみに制限します。

    • 本番環境とデータソースへのアクセスをモニタリングし、監査します。

    • 関連するすべてのリソースとサービスに対して、最小特権のアクセス制御を実装します。

    • AWS Secrets Manager シークレットや IAM ロールのアクセスキーなどの認証情報を定期的に確認して更新します。

  • この記事で使用されているサービスについては、次のセキュリティドキュメントを参照してください。

セキュリティは、本番データとリソースにアクセスする際の最優先事項です。常にベストプラクティスに従い、最小特権のアクセス制御を実装し、セキュリティ対策を定期的に見直して更新してください。

エピック

タスク説明必要なスキル

Amazon Redshift クラスター用のシークレットを作成します。

Amazon Redshift クラスター用のシークレットを作成するには、次の手順を実行します。

  1. PROD アカウントで にサインインし AWS マネジメントコンソール、https://console.aws.amazon.com/secretsmanager/ で Secrets Manager コンソールを開きます。

  2. [新しいシークレットを保存] を選択します。

  3. [Amazon Redshift データウェアハウスの認証情報] を選択します。

  4. [ユーザー名][パスワード] には、インスタンスの値を入力し、[暗号化キー] の値を確認または選択します。

  5. シークレットがアクセスする Amazon Redshift データウェアハウスを選択します。

  6. [シークレット名] に「Redshift-Creds-Secret」と入力します。

  7. 残りの作成手順をデフォルトの選択肢で完了し、[保存] を選択します。

  8. シークレットを表示し、シークレットを識別するために生成された [シークレット ARN] の値をメモします。

DevOps エンジニア

Secrets Manager にアクセスするロールを作成します。

ロールを作成するには、次の操作を行います。

  1. 本番稼働用アカウントで、IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ポリシー] を選択します。

  3. [ポリシーの作成] を選択します。

  4. [JSON] タブを選択し、以下のような IAM ポリシーを入力します。

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:ListSecretVersionIds" ], "Resource": [ "<Redshift-Creds-Secret-ARN>" ] }, { "Effect": "Allow", "Action": "secretsmanager:ListSecrets", "Resource": "*" } ] }

    Redshift-Creds-Secret-ARN を、Amazon Redshift クラスターの情報と認証情報が含まれる Secrets Manager のシークレットの Amazon リソースネーム (ARN) に置き換えます。

DevOps エンジニア
タスク説明必要なスキル

S3 バケットにアクセスするためのロールを作成します。

S3 バケットにアクセスするためのロールを作成するには、次の手順を実行します。

  1. 開発用アカウントで、IAM コンソールを開きます。

  2.  [ポリシー] を選択します。

  3. [ポリシーの作成] を選択します。

  4.  [JSON] タブを選択し、以下のような IAM ポリシーを入力します。

    { "Version": "2012-10-17", "Statement": [ { "Sid": "kmsstmt", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey" ], "Resource": [ "<kms-key-arn>" ] }, { "Sid": "s3stmt", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::mybucket", "arn:aws:s3:::mybucket/*" ] } ] }

    mybucket をアクセスする S3 バケットの名前に置き換えます。また、S3 バケットが暗号化されている場合は、 を S3 バケットの暗号化に使用される AWS Key Management Service (AWS KMS) キーの ARN kms-key-arnに置き換えます。それ以外の場合は、ポリシーの AWS KMS セクションは必要ありません。

  5. [ポリシーの確認] を選択し、ポリシーの名前として「S3-Write-Policy」を入力し、[ポリシーの作成] を選択します。

  6. ナビゲーションペインで Roles (ロール) を選択してください。

  7.  [ロールの作成] を選択してください。

  8. 信頼されたエンティティのロールには、[カスタム信頼ポリシー] を選択します。

  9. [次へ: アクセス許可]を選択し、作成した S3-Write-Policy ポリシーを選択します。

  10. ロールの名前として「S3-Write-Role」を入力し、[ロールの作成] を選択します。

DevOps エンジニア

Amazon Redshift ロールを作成します。

Amazon Redshift ロールを作成するには、次の操作を行います。

  1. 本番稼働用アカウントで、IAM コンソールを開きます。

  2. [ポリシー] を選択します。

  3. [ポリシーの作成] を選択します。

  4. [JSON] タブを選択し、以下のような IAM ポリシーを入力します。

    { "Version": "2012-10-17", "Statement": [ { "Sid": "CrossAccountPolicy", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "S3-Write-Role-ARN" } ] }

    S3-Write-Role-ARN を開発用アカウントの S3-Write-Role の ARN に置き換えます。

  5. [ポリシーの確認] を選択し、ポリシーの名前として「S3-Write-Role-Assume-Policy」を入力し、[ポリシーの作成] を選択します。

  6. ナビゲーションペインで ロール を選択してから、ロールを作成する を選択します。

  7. 信頼されたエンティティタイプとして [AWS サービス] を選択し、[Redshift][Redshift – カスタマイズ可能] を選択します。

  8. [次へ: アクセス許可] を選択し、作成した S3-Write-Role-Assume-Policy ポリシーを選択します。

  9. ロールの名前として「CrossAccount-S3-Write-Role」を入力し、[ロールの作成] を選択します。

  10. Amazon Redshift クラスターに IAM ロールを関連付けます

DevOps エンジニア
タスク説明必要なスキル

Lambda 関数をデプロイします。

ピア接続された VPC に Lambda 関数をデプロイするには、次の手順を実行します。

  1. Lambda コンソール (https://console.aws.amazon.com/lambda/) を開きます。

  2. 関数を選択します。

  3. [関数の作成] を選択します。

  4. [基本的な情報][関数名] に、関数の名前を入力します。

  5. [ランタイム][Python 3.8] を選択します

  6. [デフォルト実行ロールの変更] を開き、次の操作を行います。

    1. [既存のロールを使用する] を選択します。

    2. [既存のロール] で、前に作成した CrossAccount-RM-Read-Role Lambda ロールを選択します。

  7. [詳細設定]を展開し、以下の操作を行います。

    1. [VPC を有効にする] チェックボックスをオンにします。

    2. [VPC] には、開発用アカウントのピア接続された VPC を選択します。

    3. [サブネット] には、プライベートサブネットを選択します。

    4. [セキュリティグループ] で、デフォルトのセキュリティグループを選択します。

  8. [関数の作成] を選択します。

  9. psycopg2 ライブラリをレイヤーとして Lambda 関数に追加します。

    注記

    psycopg2-lambda-layer リポジトリから既にデプロイしているレイヤーを使用できます。 AWS リージョン および Python ランタイムに基づいて URL を使用してください。

DevOps エンジニア
タスク説明必要なスキル

必要なリソースをインポートします。

必要なリソースをインポートするには、次のコマンドを実行します。

import ast import boto3 import psycopg2 import base64 from botocore.exceptions import ClientError
アプリ開発者

Lambda ハンドラー関数を実行します。

Lambda 関数は、クロスアカウントアクセスと一時的な認証情報管理に AWS Security Token Service (AWS STS) を使用します。関数は AssumeRole API オペレーションを使用して、sm_read_role IAM ロールのアクセス許可を一時的に引き受けます。

Lambda 関数を実行するには、次のコード例を使用します。

def lambda_handler(event, context): sts_client = boto3.client('sts') # Secrets Manager Configurations secret_name = "redshift_creds" sm_region = "eu-west-1" sm_read_role = "arn:aws:iam::PROD_ACCOUNT_NUMBER:role/SM-Read-Role" # S3 Bucket Configurations s3_bucket_path = "s3://mybucket/" s3_bucket_region = "eu-west-1" s3_write_role = "arn:aws:iam::DEV_ACCOUNT_NUMBER:role/S3-Write-Role" # Redshift Configurations sql_query = "select * from category" redshift_db = "dev" redshift_s3_write_role = "arn:aws:iam::PROD_ACCOUNT_NUMBER:role/CrossAccount-S3-Write-Role" chained_s3_write_role = "%s,%s" % (redshift_s3_write_role, s3_write_role) assumed_role_object = sts_client.assume_role( RoleArn=sm_read_role, RoleSessionName="CrossAccountRoleAssumption", ExternalId="YOUR_EXTERNAL_ID", ) credentials = assumed_role_object['Credentials'] secret_dict = ast.literal_eval(get_secret(credentials, secret_name, sm_region)) execute_query(secret_dict, sql_query, s3_bucket_path, chained_s3_write_role, s3_bucket_region, redshift_db) return { 'statusCode': 200 }
アプリ開発者

シークレットを取得します。

Amazon Redshift シークレットを取得するには、次のコード例を使用します。

def get_secret(credentials, secret_name, sm_region): # Create a Secrets Manager client session = boto3.session.Session() sm_client = session.client( service_name='secretsmanager', aws_access_key_id=credentials['AccessKeyId'], aws_secret_access_key=credentials['SecretAccessKey'], aws_session_token=credentials['SessionToken'], region_name=sm_region ) try: get_secret_value_response = sm_client.get_secret_value( SecretId=secret_name ) except ClientError as e: print(e) raise e else: if 'SecretString' in get_secret_value_response: return get_secret_value_response['SecretString'] else: return base64.b64decode(get_secret_value_response['SecretBinary'])
アプリ開発者

アンロードコマンドを実行します。

S3 バケットにデータをアンロードするには、次のコード例を使用します。

def execute_query(secret_dict, sql_query, s3_bucket_path, chained_s3_write_role, s3_bucket_region, redshift_db): conn_string = "dbname='%s' port='%s' user='%s' password='%s' host='%s'" \ % (redshift_db, secret_dict["port"], secret_dict["username"], secret_dict["password"], secret_dict["host"]) con = psycopg2.connect(conn_string) unload_command = "UNLOAD ('{}') TO '{}' IAM_ROLE '{}' DELIMITER '|' REGION '{}';" \ .format(sql_query, s3_bucket_path + str(datetime.datetime.now()) + ".csv", chained_s3_write_role, s3_bucket_region) # Opening a cursor and run query cur = con.cursor() cur.execute(unload_command) print(cur.fetchone()) cur.close() con.close()
アプリ開発者
タスク説明必要なスキル

Lambda 関数の削除

予期しないコストが発生しないようにするには、リソースと、開発用アカウントと本番稼働用アカウント間の接続を削除します。

Lambda 関数を削除するには、次の手順を実行します。

  1. https://console.aws.amazon.com/lambda/ で AWS Lambda コンソールを開きます。

  2. 作成した Lambda 関数を見つけて選択します。

  3. [アクション][削除] の順に選択します。

  4. 削除を確定します。

DevOps エンジニア

IAM ロールとポリシーを削除します。

開発用アカウントと本番稼働用アカウントから IAM ロールとポリシーを削除します。

開発用アカウントで、次の操作を行います。

  1. [IAM コンソール] を開きます。

  2. 以下のロールを削除します。

    • S3-Write-Role

    • CrossAccount-RM-Read-Role (Lambda ロール)

  3. 関連するポリシーを削除します。

    • S3-Write-Policy

    • 本番稼働用アカウントのロールを引き受けるための CrossAccount ポリシー

本番稼働用アカウントで、次の操作を行います。

  1. [IAM コンソール] を開きます。

  2. 以下のロールを削除します。

    • SM-Read-Role

    • CrossAccount-S3-Write-Role

  3. 関連するポリシーを削除します。

    • Secrets Manager にアクセスするための CrossAccount ポリシー

    • S3-Write-Role-Assume-Policy

DevOps エンジニア

Secrets Manager でシークレットを削除します。

シークレットを削除するには、次の手順を実行します。

  1. 本番稼働用アカウントで、Secrets Manager コンソールを開きます。

  2. Redshift-Creds-Secret」という名前のシークレットを見つけて選択します。

  3. [アクション] を選択してから、[シークレットの削除] を選択します。

  4. 削除を確定します。

DevOps エンジニア

VPC ピアリングとセキュリティグループに関するルールを削除します。

VPC ピアリングとセキュリティグループに関するルールを削除するには、次の手順を実行します。

  1. 本番稼働用アカウントで、Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. [セキュリティグループ] に移動します。

  3. Amazon Redshift クラスターが使用するセキュリティグループを見つけます。

  4. インバウンドルールを編集し、開発用アカウントの Lambda VPC から接続を許可するルールを削除します。

  5. [VPC ピアリング接続] に移動し、ピアリング接続を削除します。

DevOps エンジニア

データを S3 バケットから削除します。

データを Amazon S3 から削除するには、次の手順を実行します。

  1. 開発用アカウントで、Amazon S3 コンソール (https://console.aws.amazon.com/s3/) を開きます。

  2. データストレージに使用したバケットを見つけます。

  3. バケット内のオブジェクトを削除するか、不要な場合はバケット全体を削除します。

DevOps エンジニア

AWS KMS キーをクリーンアップします。

暗号化用のカスタム AWS KMS キーを作成した場合は、次の操作を行います。

  1. https://console.aws.amazon.com/kms/ で AWS KMS コンソールを開きます。

  2. このパターン用に作成されたキーを見つけます。

  3. キーを削除するようにスケジュールします。(キーの削除には必須の待機期間があります)。

DevOps エンジニア

Amazon CloudWatch Logs を確認して削除します。

CloudWatch Logs を削除するには、次の手順を実行します。

  1. CloudWatch コンソールの https://console.aws.amazon.com/cloudwatch/ を開いてください。

  2. Lambda 関数または Amazon Redshift クラスターによって作成されたロググループを確認します。

  3. これらのロググループは、不要な場合は削除します。

DevOps エンジニア

関連リソース

追加情報

Amazon Redshift から Amazon S3 にデータをアンロードした後、Amazon Athena を使用してデータを分析できます。

Amazon Athena はビッグデータを分析できるクエリサービスであり、大量のデータにアクセスする必要がある場合に便利です。Athena は、サーバーやデータベースをプロビジョニングしなくても使用できます。Athena は複雑なクエリをサポートしており、さまざまなオブジェクトでクエリを実行できます。

ほとんどの と同様に AWS のサービス、Athena を使用する主な利点は、複雑さを増すことなくクエリを実行する方法に大きな柔軟性があることです。Athena を使用すると、データ型を変更することなく、CSV や JSON などのさまざまなデータ型を Amazon S3 でクエリできます。外部を含むさまざまなソースからデータをクエリできます AWS。Athena を使用すると、サーバーを管理する必要がないため、複雑さを軽減できます。Athena は、クエリを実行する前にデータをロードしたり変更したりすることなく、Amazon S3 から直接データを読み取ります。