翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # コンピューティング **Topics** + [コンテナとマイクロサービス](containersandmicroservices-pattern-list.md) + [サーバーレス](serverless-pattern-list.md) + [ネットワーク](networking-pattern-list.md) + [コンテンツ配信](contentdelivery-pattern-list.md) # コンテナとマイクロサービス **Topics** + [Amazon EKS コンテナから Amazon Neptune データベースにアクセスする](access-amazon-neptune-database-from-amazon-eks-container.md) + [AWS PrivateLink と Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスします](access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.md) + [AWS Fargate、AWS PrivateLink、Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスします。](access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.md) + [AWS PrivateLink と Network Load Balancer を使用して、Amazon EKS 上のコンテナアプリケーションにプライベートアクセスします。](access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer.md) + [AWS Batch を使用して Amazon RDS for PostgreSQL DBインスタンスのバックアップを自動化します](automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch.md) + [CI/CD パイプラインを使用して Amazon EKS へのノード終了ハンドラーのデプロイを自動化する](automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline.md) + [CI/CD パイプラインを使用して Amazon EKS へ Java アプリケーションを自動的にビルドし、デプロイする](automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.md) + [AWS アカウント と 間で Amazon ECR コンテナイメージをコピーする AWS リージョン](copy-ecr-container-images-across-accounts-regions.md) + [Amazon ECS タスク定義を作成し、Amazon EFS を使用して EC2 インスタンスにファイルシステムをマウントする](create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs.md) + [コンテナイメージを使用して Lambda 関数をデプロイする](deploy-lambda-functions-with-container-images.md) + [AWS Fargate を使用して Amazon ECS に Java マイクロサービスをデプロイする](deploy-java-microservices-on-amazon-ecs-using-aws-fargate.md) + [Amazon EKS と Amazon S3 の Helm チャートリポジトリを使用して Kubernetes のリソースとパッケージをデプロイする](deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3.md) + [Terraform を使用して Amazon EKS に CockroachDB クラスターをデプロイする](deploy-cockroachdb-on-eks-using-terraform.md) + [Amazon EKS にサンプル Java マイクロサービスをデプロイし、Application Load Balancer を使用してマイクロサービスを公開する](deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer.md) + [gRPC ベースのアプリケーションを Amazon EKS クラスターにデプロイし、Application Load Balancer でアクセスする](deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.md) + [Docker コンテナとして AWS IoT Greengrass V2 実行されている にコンテナ化されたアプリケーションをデプロイする](deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.md) + [Elastic Beanstalk を使用してコンテナをデプロイする](deploy-containers-by-using-elastic-beanstalk.md) + [Lambda 関数、Amazon VPC、およびサーバーレスアーキテクチャを使用して静的アウトバウンド IP アドレスを生成する](generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.md) + [Amazon ECR リポジトリに移行するときに、重複するコンテナイメージを自動的に識別する](identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.md) + [Kubernetes DaemonSet を使用して Amazon EKS ワーカーノードに SSM エージェントをインストールします](install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset.md) + [prebootstrapコマンドを使用して、SSM エージェントと CloudWatch エージェントを Amazon EKS ワーカーノードにインストールします。](install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands.md) + [Amazon EKS Auto Mode を有効化する際に NGINX Ingress Controller を移行する](migrate-nginx-ingress-controller-eks-auto-mode.md) + [コンテナワークロードを Azure Red Hat OpenShift (ARO) から Red Hat OpenShift Service on AWS (ROSA) に移行する](migrate-container-workloads-from-aro-to-rosa.md) + [Amazon ECS Anywhere を使用して Amazon WorkSpaces で Amazon ECS タスクを実行する](run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere.md) + [Amazon EC2 Linux インスタンスで ASP.NET Core ウェブ API Docker コンテナを実行する](run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.md) + [AWS Fargate 搭載の Amazon EKS で Amazon EFS を使用して、永続的なデータストレージでステートフルワークロードを実行する](run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate.md) + [Amazon EKS Pod Identity と KEDA を使用して Amazon EKS でイベント駆動型自動スケーリングをセットアップする](event-driven-auto-scaling-with-eks-pod-identity-and-keda.md) + [PGO を使用して Amazon EKS での PostgreSQL デプロイを合理化する](streamline-postgresql-deployments-amazon-eks-pgo.md) + [Application Load Balancer を使用して Amazon ECS の相互 TLS でアプリケーション認証を簡素化する](simplify-application-authentication-with-mutual-tls-in-amazon-ecs.md) + [その他のパターン](containersandmicroservices-more-patterns-pattern-list.md) # Amazon EKS コンテナから Amazon Neptune データベースにアクセスする *Amazon Web Services、Ramakrishnan Palaninathan* ## 概要 本パターンは、フルマネージド型のグラフデータベースである Amazon Neptune と、コンテナオーケストレーションサービスである Amazon Elastic Kubernetes Service (Amazon EKS) との間の接続を確立して Neptune データベースにアクセスします。Neptune DB クラスターは、 AWSの仮想プライベートクラウド (VPC) 内に制限されています。そのため、Neptune にアクセスするには、接続を有効にするために VPC を注意して設定する必要があります。 Neptune は、Amazon Relational Database Service (Amazon RDS) for PostgreSQL とは異なり一般的なデータベースアクセス認証情報に依存しません。代わりに、認証に AWS Identity and Access Management (IAM) ロールを使用します。したがって、Amazon EKS から Neptune に接続するには、Neptune へのアクセスに必要なアクセス許可を持つ、IAM ロールの設定が必要になります。 さらに、Neptune エンドポイントには、クラスターが存在する VPC 内のみでアクセスできます。つまり、Amazon EKS と Neptune の間の通信が容易になるようにネットワーク設定を構成する必要があります。Neptune と Amazon EKS 間のシームレスな接続を可能にするには、特定の要件とネットワーク設定に応じて[さまざまな方法で VPC を設定](https://docs.aws.amazon.com/neptune/latest/userguide/get-started-vpc.html)します。それぞれの方法には個別の利点と考慮事項があり、アプリケーションのニーズに合ったデータベースアーキテクチャを柔軟に設計できます。 ## 前提条件と制限事項 **前提条件** + 最新バージョンの **kubectl** をインストールします ([手順](https://kubernetes.io/docs/tasks/tools/#kubectl)を参照)。バージョンを確認するには次を実行します。 ``` kubectl version --short ``` + 最新バージョンの **eksctl** をインストールします ([手順](https://eksctl.io/installation/)を参照)。バージョンを確認するには次を実行します。 ``` eksctl info ``` + AWS Command Line Interface (AWS CLI) バージョン 2 の最新バージョンをインストールします ([手順](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)を参照）。バージョンを確認するには次を実行します。 ``` aws --version ``` + Neptune DB クラスターを作成します ([手順](https://docs.aws.amazon.com/neptune/latest/userguide/get-started-cfn-create.html)を参照)。VPC [ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)、[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html)、またはその他の方法を使用して、クラスターの VPC と Amazon EKS 間の通信を確立します。また、クラスターのステータスが「使用可能」であり、セキュリティグループのポート 8182 にインバウンドルールがあることを確認します。 + 既存の Amazon EKS クラスターで IAM OpenID Connect (OIDC) プロバイダーを設定します ([手順](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)を参照)。 **製品バージョン** + [Amazon EKS 1.27](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) + [Amazon Neptune エンジンバージョン 1.3.0.0 (2023-11-15)](https://docs.aws.amazon.com/neptune/latest/userguide/engine-releases-1.3.0.0.html) ## アーキテクチャ 次の図は、Neptune データベースへのアクセスを可能にする、Amazon EKS クラスター内の Kubernetes ポッドと Neptune との間の接続を示しています。 ![\[Kubernetes ノードのポッドを Amazon Neptune に接続します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/2fcf9e00-1664-462a-825e-b0fdd962f478/images/86da67e5-340e-4b29-acc6-2da416ce57eb.png) **自動化とスケール** Amazon EKS [Horizontal Pod Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html) を使用することでこのソリューションをスケールできます。 ## ツール **サービス** + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [Amazon Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/intro.html) は、複雑に接続されたデータセットを扱うアプリケーションを構築して実行するために使用できるマネージドグラフデータベースサービスです。 ## ベストプラクティス ベストプラクティスについては、「*Amazon EKS ベストプラクティスガイド*」の「[アイデンティティとアクセス管理](https://aws.github.io/aws-eks-best-practices/security/docs/iam/)」を参照してください。 ## エピック ### 環境変数を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クラスターコンテキストを検証する。 | Helm またはその他のコマンドラインツールを使用して Amazon EKS クラスターを操作するときは、事前にクラスターの詳細をカプセル化する環境変数を定義する必要があります。これらの変数は、正しいクラスターとリソースをターゲットにするために、後続のコマンドで使用されます。まず、正しいクラスターコンテキスト内で動作していることを確認します。これにより、後続のコマンドが目的の Kubernetes クラスターに送信されます。現在のコンテキストを確認するには、次のコマンドを実行します。
kubectl config current-context
| AWS 管理者、クラウド管理者 | | `CLUSTER_NAME` 変数を定義します。 | Amazon EKS クラスターの `CLUSTER_NAME` 環境変数を定義します。次のコマンドで、サンプル値をクラスター AWS リージョン に適した`us-west-2`値に置き換えます。サンプル値 `eks-workshop` を既存のクラスターの名前に置き換えます。
export CLUSTER_NAME=$(aws eks describe-cluster --region us-west-2 --name eks-workshop --query "cluster.name" --output text)
| AWS 管理者、クラウド管理者 | | 出力を検証します。 | 変数が正しく設定されていることを確認するには、次のコマンドを実行します。
echo $CLUSTER_NAME
このコマンドの出力が、前のステップで指定した入力と一致することを確認します。 | AWS 管理者、クラウド管理者 | ### IAM ロールを作成し、Kubernetes サービスアカウントに関連付けます。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サービスアカウントを作成します。 | [サービスアカウントの IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html?sc_channel=el&sc_campaign=appswave&sc_content=eks-integrate-secrets-manager&sc_geo=mult&sc_country=mult&sc_outcome=acq)を使用して、Kubernetes サービスアカウントを IAM ロールにマッピングし、Amazon EKS で実行されるアプリケーションのきめ細かなアクセス許可管理を有効にします。[eksctl](https://eksctl.io/) を使用すると、IAM ロールを作成して、Amazon EKS クラスター内の特定の Kubernetes サービスアカウントに関連付けることができます。 AWS 管理ポリシー`NeptuneFullAccess`は、指定した Neptune クラスターへの書き込みおよび読み取りアクセスを許可します。これらのコマンドを実行するときは、先に、クラスターに [OIDC エンドポイント](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html?sc_channel=el&sc_campaign=appswave&sc_content=eks-integrate-secrets-manager&sc_geo=mult&sc_country=mult&sc_outcome=acq)が関連付けられている必要があります。という名前の管理 AWS ポリシーに関連付けるサービスアカウントを作成します`NeptuneFullAccess`。
eksctl create iamserviceaccount --name eks-neptune-sa --namespace default --cluster $CLUSTER_NAME --attach-policy-arn arn:aws:iam::aws:policy/NeptuneFullAccess --approve --override-existing-serviceaccounts
`eks-neptune-sa ` は作成するサービスアカウントの名前です。完了すると、このコマンドは次のレスポンスを表示します。
2024-02-07 01:12:39 [ℹ] created serviceaccount "default/eks-neptune-sa"
| AWS 管理者、クラウド管理者 | | アカウントが正しく設定されていることを確認します。 | `eks-neptune-sa` サービスアカウントがクラスターのデフォルトの名前空間で正しく設定されていることを確認します。
kubectl get sa eks-neptune-sa -o yaml
出力は次のようになります:
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789123:role/eksctl-eks-workshop-addon-iamserviceaccount-d-Role1-Q35yKgdQOlmM
  creationTimestamp: "2024-02-07T01:12:39Z"
  labels:
    app.kubernetes.io/managed-by: eksctl
  name: eks-neptune-sa
  namespace: default
  resourceVersion: "5174750"
  uid: cd6ba2f7-a0f5-40e1-a6f4-4081e0042316
| AWS 管理者、クラウド管理者 | | 接続を確認する。 | `pod-util` というサンプルポッドをデプロイし、Neptune との接続を確認します。
apiVersion: v1
kind: Pod
metadata:
  name: pod-util
  namespace: default
spec:
  serviceAccountName: eks-neptune-sa
  containers:
  - name: pod-util
    image: public.ecr.aws/patrickc/troubleshoot-util
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
kubectl apply -f pod-util.yaml
kubectl exec --stdin --tty pod-util -- /bin/bash
bash-5.1# curl -X POST -d '{"gremlin":"g.V().limit(1)"}' https://db-neptune-1.cluster-xxxxxxxxxxxx.us-west-2.neptune.amazonaws.com:8182/gremlin
{"requestId":"a4964f2d-12b1-4ed3-8a14-eff511431a0e","status":{"message":"","code":200,"attributes":{"@type":"g:Map","@value":[]}},"result":{"data":{"@type":"g:List","@value":[]},"meta":{"@type":"g:Map","@value":[]}}}
bash-5.1# exit
exit
| AWS 管理者、クラウド管理者 | ### 接続アクティビティを検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM データベース認証を有効にする | デフォルトでは、Neptune DB クラスターの作成時、IAM データベース認証は無効になっています。 AWS マネジメントコンソールを使用して、IAM データベース認証を有効にするか、無効にすることができます AWS ドキュメントの手順に従って、[Neptune で IAM データベース認証を有効にします](https://docs.aws.amazon.com/neptune/latest/userguide/iam-auth-enable.html)。 | AWS 管理者、クラウド管理者 | | 接続を検証します。 | このステップでは、既に実行中のステータスにある `pod-util` コンテナを操作して、**awscurl**をインストールし、接続を検証します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-amazon-neptune-database-from-amazon-eks-container.html) | AWS 管理者、クラウド管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Neptune データベースにアクセスできない。 | サービスアカウントにアタッチされている IAM ポリシーを確認します。実行する操作に必要なアクション (`neptune:Connec,neptune:DescribeDBInstances` など) が許可されていることを確認します。 | ## 関連リソース + [Kubernetes サービスアカウント AWS を使用して へのアクセスを Kubernetes ワークロードに許可する](https://docs.aws.amazon.com/eks/latest/userguide/service-accounts.html) (Amazon EKS ドキュメント) + [サービスアカウントの IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) (Amazon EKS ドキュメント) + [新しい Neptune DB クラスターの作成](https://docs.aws.amazon.com/neptune/latest/userguide/get-started-create-cluster.html) (Amazon Neptune ドキュメント) # AWS PrivateLink と Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスします *Amazon Web Services、Kirankumar Chandrashekar* ## 概要 このパターンは、Network Load Balancer の背後にある Amazon Elastic Container Service (Amazon ECS) の Docker コンテナアプリケーションをプライベートでホストし、AWS PrivateLink を使用してアクセスする方法を示しています。その後、専用ネットワークで、Amazon Web Services（AWS） のクラウド上のサービスに安全にアクセスできるようになります。Amazon Relational Database Service (Amazon RDS) を使用して、Amazon ECS で実行される高可用性 (HA) アプリケーション用のリレーショナルデータベースをホストします。アプリケーションに永続的なストレージが必要な場合、Amazon Elastic File System (Amazon EFS) が使用されます。 Dockerアプリケーションを実行する Amazon ECS サービスは、フロントエンドに Network Load Balancer を備えており、AWS PrivateLink経由でアクセスできる仮想プライベートクラウド（VPC）エンドポイントと関連付けることができます。この VPC エンドポイントサービスは、VPC エンドポイントを使用して他の VPC と共有できます。 Amazon EC2 Auto Scaling の代わりに、[AWS Fargate ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) を使用することもできます。詳細については、「[AWS Fargate、AWS PrivateLink、Network Load Balancerを使用して Amazon ECS でコンテナアプリケーションにプライベートにアクセス](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html?did=pg_card)」を参照してください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + Linux、macOSまたは Windows にインストールし、設定されている「[AWS コマンドラインインターフェイス (AWS CLI) バージョン 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」 + Linux、macOSまたは Windows にインストールし設定された「[Docker](https://www.docker.com/)」 + Docker 上で動作するアプリケーション ## アーキテクチャ ![\[AWS PrivateLink を使って Network Load Balancer の背後にある Amazon ECS 上のコンテナアプリにアクセスします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a316bf46-24db-4514-957d-abc60f8f6962/images/573951ed-74bb-4023-9d9c-43e77e4f8eda.png) **テクノロジースタック** + Amazon CloudWatch + Amazon Elastic Compute Cloud (Amazon EC2) + Amazon EC2 Auto Scaling + Amazon Elastic Container Registry (Amazon ECR) + Amazon ECS + Amazon RDS + Amazon Simple Storage Service (Amazon S3) + AWS Lambda + AWS PrivateLink + AWS Secrets Manager + Application Load Balancer + Network Load Balancer + VPC *自動化とスケール* + 「[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)」を使用することで、「[インフラストラクチャをコード](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)」として使用してこのパターンを作成できます。 ## ツール + 「[Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)」— Amazon Elastic Compute Cloud (Amazon EC2) は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。 + [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) — Amazon EC2 Auto Scaling は、アプリケーションの負荷を処理するために適切な数の Amazon EC2 インスタンスを利用できるようにします。 + 「[Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)」— Amazon Elastic Container Service (Amazon ECS) は、クラスター上のコンテナーの実行、停止、管理を簡単にする、拡張性の高い高速なコンテナー管理サービスです。 + 「[Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)」— Amazon Elastic Container Registry (Amazon ECR) は、セキュリティ、スケーラビリティ、信頼性を備えた AWS マネージドコンテナイメージレジストリサービスです。 + 「[Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)」— Amazon Elastic File System (Amazon EFS)は、AWS クラウドサービスやオンプレミスのリソースで使用できる、シンプルでスケーラブルな、フルマネージドされた伸縮自在な NFS ファイルシステムを提供します。 + 「[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」– Lambda は、サーバーのプロビジョニングや管理を行わずにコードを実行するためのコンピューティング サービスです。 + 「[Amazon RDS](https://docs.aws.amazon.com/rds/)」— Amazon Relational Database Service (Amazon RDS) は、AWS クラウドでのリレーショナルデータベースのセットアップ、運用、スケールをより簡単にするウェブサービスです。 + 「[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)」— Amazon Simple Storage Service (Amazon S3)は、インターネット用のストレージです。Web スケールのコンピューティングを開発者が容易にできるように設計されています。 + 「[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)」— Secrets Manager は、Secrets Manager に API 呼び出しを提供してプログラムでシークレットを取得することで、コード内のハードコーディングされた認証情報 (パスワードを含む) を置き換えるのに役立ちます。 + 「[Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)」— Amazon Virtual Private Cloud (Amazon VPC) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。 + 「[Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)」— Elastic Load Balancing は、受信するアプリケーションまたはネットワーク トラフィックを、複数のアベイラビリティーゾーン内の Amazon EC2 インスタンス、コンテナ、IP アドレスなどの複数のターゲットに分散します。 + 「[Docker](https://www.docker.com/)」— Docker を使用すると、開発者はあらゆるアプリケーションを軽量でポータブルな自給自足のコンテナとして簡単に梱包、出荷、および実行できます。 ## エピック ### ネットワークコンポーネントの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPC を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | ### ロードバランサーの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Network Load Balancer を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | Application Load Balancer を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | ### Amazon EFS ファイルシステムを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EFS ファイルシステムを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | サブネットのターゲットをマウントします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | サブネットがターゲットとしてマウントされていることを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | ### S3 バケットを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットを作成する。 | Amazon S3 コンソールを開き、必要に応じてアプリケーションの静的アセットを保存する S3 バケットを作成します。 | クラウド管理者 | ### Secrets Manager シークレットを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Secrets Manager シークレットを暗号化するために、AWS KMS キーを作成します。 | AWS Key Management Service (AWS KMS) コンソールを開き、KMS キーを作成します。 | クラウド管理者 | | Amazon RDS パスワードを保存する Secrets Manager シークレットを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | ### Amazon RDS DB インスタンスの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DB サブネットグループを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | Amazon RDS DB インスタンスを作成します。 | プライベートサブネット内に Amazon RDS インスタンスを作成して設定します。HA のため、**[マルチ AZ]** がオンになっていることを確認してください。 | クラウド管理者 | | Amazon RDS インスタンスにデータをロードします。 | アプリケーションに必要なリレーショナルデータを Amazon RDS インスタンスにロードします。このプロセスは、アプリケーションのニーズや、データベーススキーマの定義方法や設計方法により、異なっています。 | クラウド管理者、DBA | ### Amazon ECS コンポーネントの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | EKS クラスターを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | Docker イメージを作成します。 | *[関連リソース]* セクションの指示に従い、Docker イメージを作成します。 | クラウド管理者 | | Amazon ECR リポジトリを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者、DevOps エンジニア | | Amazon ECR レジストリに対し、Docker CLI を認証します。 | Amazon ECR リポジトリ用の Docker クライアントを認証するには、AWS CLI で `aws ecr get-login-password` コマンドを実行します。 | クラウド管理者 | | Docker イメージを Amazon ECR リポジトリにプッシュします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | Amazon ECS タスク定義を作成します。 | Amazon ECS で Docker コンテナを実行するには、タスク定義が必要です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html)タスク定義の設定方法については、*[関連リソース]* のセクションのタスク定義の作成を参照してください。Amazon ECR にプッシュした Docker イメージを必ず提供してください。 | クラウド管理者 | | Amazon ECS サービスを作成する | 前に作成した ECS クラスターを使用して Amazon ECS サービスを作成します。 、起動タイプとして必ず Amazon EC2 を選択し、前の手順で作成したタスク定義と Application Load Balancer のターゲットグループを選択してください。 | クラウド管理者 | ### Amazon EC2 Auto Scaling グループの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 起動設定を作成します。 | Amazon EC2 コンソールを開き、起動設定を作成します。ユーザーデータに、EC2 インスタンスが必要な ECS クラスターに参加できるようにするコードが含まれていることを確認します。必要なコードの例として、*[関連リソース]* セクションを参照してください。 | クラウド管理者 | | Amazon EC2 Auto Scaling グループを作成します。 | Amazon EC2 コンソールに戻り、**[Auto Scaling]** で **[Auto Scaling グループ]** を選択します。Amazon EC2 Auto Scaling をセットアップします。プライベートサブネットが選択されていることを確認し、前に作成した設定を開始します。 | クラウド管理者 | ### AWS PrivateLinkの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS PrivateLink エンドポイントを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html)詳細については、[関連リソース] セクションを参照してください。 | クラウド管理者 | ### VPC エンドポイントの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPC エンドポイントを作成します。 | 前に作成した AWS PrivateLink エンドポイント用の VPC エンドポイントを作成します。VPC エンドポイントの完全修飾ドメイン名 (FQDN) は、AWS PrivateLink エンドポイント FQDN を指します これにより、DNS エンドポイントがアクセスできる VPC エンドポイントサービスへの耐障害性のあるネットワークインタフェースが作成されます。 | クラウド管理者 | ### Lambda 関数を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数を作成します。 | AWS Lambda コンソールで、Lambda関数を作成して、Network Load Balancer のターゲットとして Application Load Balancer IPアドレスを更新します。詳細については、ブログ記事「[AWS Lambda を使用してアプリケーションロードバランサーで静的 IP アドレスを有効化する](https://aws.amazon.com/blogs/networking-and-content-delivery/using-aws-lambda-to-enable-static-ip-addresses-for-application-load-balancers/)」を参照してください。 | アプリ開発者 | ## 関連リソース ロードバランサーの作成 + [Amazon ECS の Network Load Balancer を使用する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/nlb.html) + [Network Load Balancer を作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) + [Amazon ECS 用の Application Load Balancer を使用する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/alb.html) + 「[Application Load Balancer の作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html)」 Amazon EFS ファイルシステムを作成する + [Amazon EFS ファイルシステムを作成する](https://docs.aws.amazon.com/efs/latest/ug/creating-using-create-fs.html) + 「[Amazon EFS でマウントターゲットを作成](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html)」 S3 バケットを作成する + [S3 バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket) Secrets Manager シークレットの作成 + 「[AWS KMS でキーを作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」 + 「[AWS Secrets Manager でシークレットを作成する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)」 Amazon RDS インスタンスの作成 + 「[Amazon RDS DB インスタンスの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)」 **Amazon ECS コンポーネントの作成** + 「[Amazon ECS クラスターの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-ec2-cluster-console-v2.html)」 + 「[Docker イメージの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html)」 + 「[Amazon ECR リポジトリの作成](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)」 + 「[Amazon ECR リポジトリで Docker を認証](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth)」 + 「[イメージを Amazon ECR リポジトリにプッシュ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)」 + 「[Amazon ECS タスク定義の作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)」 + 「[Amazon ECS サービスの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-console-v2.html)」 Amazon EC2 Auto Scaling グループを作成します。 + 「[起動設定を作成する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-config.html)」 + [起動設定を使用して Auto Scaling グループを作成する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg.html) + 「[Amazon EC2 ユーザーデータを使用してコンテナインスタンスをブートストラップする](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html)」 **AWS PrivateLinkの設定：** + 「[VPC エンドポイントサービス (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html)」 VPC エンドポイントの作成 + 「[インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」 Lambda 関数の作成 + [Lambda 関数を作成する](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) その他のリソース + 「[Application Load Balancer に静的 IP アドレスを使用](https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/)」 + 「[AWS PrivateLink を介したサービスへの安全なアクセス](https://d1.awsstatic.com/whitepapers/aws-privatelink.pdf)」 # AWS Fargate、AWS PrivateLink、Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスします。 *Amazon Web Services、Kirankumar Chandrashekar* ## 概要 このパターンは、Network Load Balancer の後ろで AWS Fargate 起動タイプの Amazon Elastic Container Service (Amazon ECS) を使用することで、Amazon Web Services (AWS) クラウドで Docker コンテナアプリケーションをプライベートでホストし、AWS PrivateLink を使用してアプリケーションにアクセスする方法を示しています。Amazon Relational Database Service (Amazon RDS) を使用して、Amazon ECS で実行される高可用性 (HA) アプリケーション用のリレーショナルデータベースをホストします。アプリケーションに永続的なストレージが必要な場合、Amazon Elastic File System (Amazon EFS) を使用できます。 このパターンでは、Docker アプリケーションを実行する Amazon ECS サービスに「[Fargate 起動タイプ](https://docs.aws.amazon.com/AmazonECS/latest/userguide/launch_types.html)」を使用し、フロントエンドにはNetwork Load Balancerを使用します。また、AWS PrivateLink 経由でアクセスするために、仮想プライベートクラウド (VPC)　エンドポイントと関連付けられることが可能です。この VPC エンドポイントサービスは、VPC エンドポイントを使用して他の VPC と共有できます。 Fargate と Amazon ECS を使用すると、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのサーバーやクラスターを管理することなくコンテナを実行できます。Fargate の代わりに、Amazon EC2 Auto Scaling グループを使用することもできます 詳細については、「[AWS PrivateLink と Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスする](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html?did=pg_card&trk=pg_card)」を参照してください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + Linux、macOSまたは Windows にインストールし、設定されている「[AWS コマンドラインインターフェイス (AWS CLI) バージョン 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」 + Linux、macOSまたは Windows にインストールし設定された「[Docker](https://www.docker.com/)」 + Docker 上で動作するアプリケーション ## アーキテクチャ ![\[PrivateLink を使用して AWS Fargate 起動タイプで、Amazon ECS のコンテナアプリケーションにアクセスする。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/31cca5e2-8d8b-45ec-b872-a06b0dd97007/images/57cc9995-45f4-4039-a0bf-2d2b3d6a05de.png) **テクノロジースタック** + Amazon CloudWatch + Amazon Elastic Container Registry (Amazon ECR) + Amazon ECS + Amazon EFS + Amazon RDS + Amazon Simple Storage Service (Amazon S3) + AWS Fargate + AWS PrivateLink + AWS Secrets Manager + Application Load Balancer + Network Load Balancer + VPC **自動化とスケール** + 「[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)」を使用することで、「[インフラストラクチャをコード](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)」として使用してこのパターンを作成できます。 ## ツール **AWS のサービス** + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えた AWS マネージドコンテナイメージレジストリサービスです。 + [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) は、クラスターでコンテナの実行、停止、管理を簡単に行うことのできる、高度にスケーラブルで高速なコンテナ管理サービスです。 + [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) は、AWS クラウドサービスやオンプレミスのリソースで使用できる、シンプルでスケーラブルな、フルマネージドされた伸縮自在な NFS ファイルシステムを提供します。 + [ Fargate は Amazon ECS で使用できるテクノロジーであり、サーバーやAmazon EC2インスタンスの クラスターを管理することなくAWS Fargateコンテナ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html)を実行できます。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/rds/index.html) は、 AWS クラウドでリレーショナルデータベースを簡単にセットアップし、運用し、スケーリングすることのできるウェブサービスです。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、インターネット用のストレージです。Web スケールのコンピューティングを開発者が容易にできるように設計されています。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/) を使用すると、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールで置き換えて、プログラムでシークレットを取得することができます。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。 + [Elastic Load Balancing (ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) は、受信したアプリケーションまたはネットワークトラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に分散させます。 **その他のツール** + [Docker](https://www.docker.com/) は、デベロッパーがあらゆるアプリケーションを、軽量でポータブル、かつ自給自足のコンテナとして簡単に梱包、出荷、実行できるよう支援します。 ## エピック ### ネットワークコンポーネントの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPC を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | ### ロードバランサーの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Network Load Balancer を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html)このストーリーやその他のストーリーに関するヘルプは、「*関連リソース*」セクションを参照してください。 | クラウド管理者 | | Application Load Balancer を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | ### Amazon EFS ファイルシステムを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EFS ファイルシステムを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | サブネットのターゲットをマウントします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | サブネットがターゲットとしてマウントされていることを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | ### S3 バケットを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットを作成する。 | Amazon S3 コンソールを開き、必要に応じてアプリケーションの静的アセットを保存する [S3 バケットを作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket)します。 | クラウド管理者 | ### Secrets Manager シークレットを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Secrets Manager シークレットを暗号化するために、AWS KMS キーを作成します。 | AWS Key Management Service (AWS KMS) コンソールを開き、KMS キーを作成します。 | クラウド管理者 | | Amazon RDS パスワードを保存する Secrets Manager シークレットを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | ### Amazon RDS DB インスタンスの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DB サブネットグループを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | Amazon RDS DB インスタンスを作成します。 | プライベートサブネット内に Amazon RDS インスタンスを作成して設定します。高可用性 (HA) のため、**マルチ AZ** がオンになっていることを確認してください。 | クラウド管理者 | | Amazon RDS インスタンスにデータをロードします。 | アプリケーションに必要なリレーショナルデータを Amazon RDS インスタンスにロードします。このプロセスは、アプリケーションのニーズや、データベーススキーマの定義方法や設計方法により、異なっています。 | DBA | ### Amazon ECS コンポーネントの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | EKS クラスターを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | Docker イメージを作成します。 | [AWS ドキュメント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html)の指示に従って Docker イメージを作成します。 | クラウド管理者 | | Amazon ECR リポジトリを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者、DevOps エンジニア | | Docker イメージを Amazon ECR リポジトリにプッシュします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | | Amazon ECS タスク定義を作成します。 | Amazon ECS で Docker コンテナを実行するには、タスク定義が必要です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html)タスク定義の設定方法については、*[関連リソース]* のセクションのタスク定義の作成を参照してください。Amazon ECR にプッシュした Docker イメージを必ず提供してください。 | クラウド管理者 | | ECS サービスを作成し、起動タイプとして Fargate を選択します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | ### AWS PrivateLinkの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS PrivateLink エンドポイントを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | クラウド管理者 | ### VPC エンドポイントの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPC エンドポイントを作成します。 | 前に作成した AWS PrivateLink エンドポイント用の [VPC エンドポイントを作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)します。VPC エンドポイントの完全修飾ドメイン名 (FQDN) は、AWS PrivateLink エンドポイント FQDN を指します これにより、ドメインネームサービスのエンドポイントがアクセスできる VPC エンドポイントサービスへのElastic Network Interface が作成されます。 | クラウド管理者 | ### ターゲットを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Application Load Balancer をターゲットとして登録する | Network Load Balancer のターゲットとして Application Load Balancer を追加するには、[AWS ドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/application-load-balancer-target.html)の指示に従います。 | アプリ開発者 | ## 関連リソース ロードバランサーの作成 + [Amazon ECS の Network Load Balancer を使用する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/nlb.html) + [Network Load Balancer を作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) + [Amazon ECS 用の Application Load Balancer を使用する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/alb.html) + 「[Application Load Balancer の作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html)」 Amazon EFS ファイルシステムを作成する + [Amazon EFS ファイルシステムを作成する](https://docs.aws.amazon.com/efs/latest/ug/creating-using-create-fs.html) + 「[Amazon EFS でマウントターゲットを作成](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html)」 Secrets Manager シークレットの作成 + 「[AWS KMS でキーを作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」 + 「[AWS Secrets Manager でシークレットを作成する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」 Amazon RDS インスタンスの作成 + 「[Amazon RDS DB インスタンスの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)」 **Amazon ECS コンポーネントの作成** + 「[Amazon ECR リポジトリの作成](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)」 + 「[Amazon ECR リポジトリで Docker を認証](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth)」 + 「[イメージを Amazon ECR リポジトリにプッシュ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)」 + 「[Amazon ECS タスク定義の作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)」 + 「[Amazon ECS サービスの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-console-v2.html)」 その他のリソース + 「[AWS PrivateLink を介したサービスへの安全なアクセス](https://d1.awsstatic.com/whitepapers/aws-privatelink.pdf)」 # AWS PrivateLink と Network Load Balancer を使用して、Amazon EKS 上のコンテナアプリケーションにプライベートアクセスします。 *Amazon Web Services、Kirankumar Chandrashekar* ## 概要 このパターンは、Network Load Balancer の背後にAmazon Elastic Kubernetes Service (Amazon EKS) で Docker コンテナアプリケーションをプライベートにホストし、AWS PrivateLink を使用してアプリケーションにアクセスする方法を示しています。その後、専用ネットワークで、Amazon Web Services（AWS） のクラウド上のサービスに安全にアクセスできるようになります。  Docker アプリケーションを実行している Amazon EKS クラスターは、フロントエンドにNetwork Load Balancer があり、仮想プライベートクラウド (VPC) エンドポイントに関連付けて AWS PrivateLink 経由でアクセスできます。この VPC エンドポイントサービスは、VPC エンドポイントを使用して他の VPC と共有できます。 このパターンで説明されている設定は、VPC と AWS アカウント間でアプリケーションアクセスを共有するための安全な方法です。コンシューマーアカウントとプロバイダーアカウント間の接続はグローバル AWS バックボーン上にあり、パブリックインターネットを経由しないため、特別な接続やルーティング設定は必要ありません。 ## 前提条件と制限事項 **前提条件** + [「Docker」](https://www.docker.com/)、 Linux、macOS または Windows にインストールし、設定されています。 + Docker 上で実行するアプリケーション。 + アクティブな AWS アカウント。 + Linux、macOS または Windows にインストールして設定されている「[AWS Command Line Interface (AWS CLI) バージョン 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)」。 + タグ付けされたプライベートサブネットとホストアプリケーションに設定された既存の Amazon EKS クラスター。詳細については、「Amazon EKS ドキュメント」の「[サブネットタギング](https://docs.aws.amazon.com/eks/latest/userguide/network_reqs.html#vpc-subnet-tagging)」を参照してください。  + Kubectl は、Amazon EKS クラスター上のリソースにアクセスするようにインストールし、設定されています。詳細については、Amazon EKS ドキュメントの「[kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」を参照してください。  ## アーキテクチャ ![\[PrivateLink と Network Load Balancer を使用して Amazon EKS コンテナ内のアプリケーションにアクセスします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ce977924-012c-4fb6-8e51-94d6e5c829a6/images/378456a3-f4d1-4a57-bb36-879c240cabfb.png) **テクノロジースタック** + Amazon EKS + AWS PrivateLink + Network Load Balancer **自動化とスケール** + Kubernetes マニフェストは Git ベースのリポジトリで追跡、管理でき、AWS CodePipeline の継続的インテグレーションと継続的デリバリー (CI/CD) を使用してデプロイできます。  + AWS CloudFormation を使用して、コードとしての Infrastructure as Code (IaC) を使用してこのパターンを作成できます。 ## ツール + 「[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)」— AWS コマンドラインインターフェイス (AWS CLI) は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。 + 「[Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)」— Elastic Load Balancing は、Amazon Elastic Compute Cloud (Amazon EC2)インスタンス、コンテナ、IPアドレスなど、単一または複数のアベイラビリティゾーンにある複数のターゲットに、受信するアプリケーションまたはネットワークトラフィックを分散します。 + 「[Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)」— Amazon Elastic Kubernetes Service (Amazon EKS) は、独自の Kubernetes コントロールプレーンやノードをインストール、運用、保守することなく、AWS 上で Kubernetes を実行するために使用できるマネージドサービスです。 + 「[Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)」— Amazon Virtual Private Cloud (Amazon VPC) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。 + [Kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) — Kubectl は、Kubernetes クラスターに対してコマンドを実行するためのコマンドラインユーティリティです。 ## エピック ### Kubernetes デプロイとサービスマニフェストファイルをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Kubernetes デプロイマニフェストファイルを作成します。 | ご要求に応じて以下のサンプルファイルを変更して、デプロイマニフェストファイルを作成します。
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: public.ecr.aws/z9d2n7e1/nginx:1.19.5
          ports:
            - name: http
              containerPort: 80
これは NGINX Docker イメージを使用してデプロイされる NGINX サンプル設定ファイルです。詳細については、「Docker ドキュメント」の「[公式 NGINX Docker イメージの使用方法](https://www.docker.com/blog/how-to-use-the-official-nginx-docker-image/)」を参照してください。 | DevOps エンジニア | | Kubernetes デプロイマニフェストファイルをデプロイします。 | 次のコマンドを実行し、Amazon EKS クラスターにデプロイマニフェストファイルを適用します。`kubectl apply –f  ` | DevOps エンジニア | | Kubernetes サービスマニフェストファイルを作成します。 | 以下のサンプルファイルをご要求に応じて変更して、サービスマニフェストファイルを作成します。
apiVersion: v1
kind: Service
metadata:
  name: sample-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: LoadBalancer
  selector:
    app: nginx
内部の Network Load Balancer を定義するには、以下の `annotations` を必ず含めてください。
service.beta.kubernetes.io/aws-load-balancer-type: nlb
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
| DevOps エンジニア | | Kubernetes サービスのマニフェストファイルをデプロイします。 | 次のコマンドを実行し、サービスマニフェストファイルを Amazon EKS クラスターに適用します。`kubectl apply -f ` | DevOps エンジニア | ### エンドポイントを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Network Load Balancer 名を記録します。 | 次のコマンドを実行して、Network Load Balancer 名を取得します。`kubectl get svc sample-service -o wide`AWS PrivateLink エンドポイントの作成に必要な Network Load Balancer 名を記録します。 | DevOps エンジニア | | AWS PrivateLink エンドポイントを作成します。 | AWS マネジメントコンソールにサインインし、Amazon VPC コンソールを開き、AWS PrivateLink エンドポイントを作成します。このエンドポイントをNetwork Load Balancer に関連付けることにより、アプリケーションは顧客が非公開に利用できるようになります。詳細については、Amazon VPC ドキュメントの「[VPC エンドポイントサービス (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html)」を参照してください。コンシューマーアカウントがアプリケーションにアクセスする必要がある場合は、コンシューマーアカウントの [AWS アカウント ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html) を AWS PrivateLink エンドポイント設定の許可プリンシパルリストに追加する必要があります。詳細については、「Amazon VPC ドキュメント」の「[エンドポイントサービスのアクセス権限の追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/add-endpoint-service-permissions.html)」を参照してください。 | クラウド管理者 | | VPC エンドポイントを作成します。 | Amazon VPC コンソールで、**[エンドポイントサービス]** を選択し、**[エンドポイントサービスの作成]** を選択します。AWS PrivateLink エンドポイント用の VPC エンドポイントを作成します。VPC エンドポイントの完全修飾ドメイン名 (FQDN) は AWS PrivateLink エンドポイントの FQDN を指します。これにより、DNS エンドポイントがアクセスできる VPC エンドポイントサービスへの耐障害性のあるネットワークインタフェースが作成されます。  | クラウド管理者 | ## 関連リソース + 公式 NGINX Docker イメージの使用 + 「[Amazon EKS でのネットワークロードバランシング](https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html)」  + 「[VPC エンドポイントサービス (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html)」  + 「[エンドポイントサービスのアクセス権限の追加または削除](https://docs.aws.amazon.com/vpc/latest/userguide/add-endpoint-service-permissions.html)」 # AWS Batch を使用して Amazon RDS for PostgreSQL DBインスタンスのバックアップを自動化します *Amazon Web Services、Kirankumar Chandrashekar* ## 概要 PostgreSQL データベースのバックアップは重要なタスクで、通常 [pg\$1dump ユーティリティ](https://www.postgresql.org/docs/current/app-pgdump.html) を使用して完了します。このユーティリティでは、デフォルトで COPY コマンドを使用して、PostgreSQL データベースのスキーマとデータダンプを作成します。ただし、複数の PostgreSQL データベースを定期的にバックアップする必要がある場合、このプロセスは繰り返しになる可能性があります。PostgreSQL データベースがクラウドでホストされている場合は、Amazon Relational Database Service (Amazon RDS) の PostgreSQL 用の Amazon Relational Database Service (Amazon RDS) により提供される [自動バックアップ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 特徴量を活用することもできます。このパターンでは、pg\$1dump ユーティリティを使用して Amazon RDS for PostgreSQL インスタンスのの定期バックアップを自動化する方法を説明します。 注：手順は Amazon RDS を使用していることを前提としています。ただし、この方法は Amazon RDS の外部でホストされている PostgreSQL データベースにも使用できます。バックアップを取るには、AWS Lambda 関数がデータベースにアクセスできる必要があります。 時間ベースの Amazon CloudWatch Events イベントは、Amazon RDS 上の PostgreSQL DB [インスタンスのメタデータに適用された特定のバックアップタグ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) を検索する Lambda 関数を開始します。PostgreSQL DB インスタンスに **bkp:AutomatedDBDump = Active** タグとその他の必要なバックアップタグがある場合、Lambda 関数はデータベースバックアップごとに個別のジョブを AWS Batch に送信します。  AWS Batch はこれらのジョブを処理し、Amazon Simple Storage Service (Amazon S3) バケットにバックアップデータをアップロードします。このパターンでは、Dockerfile と entrypoint.sh ファイルを使用して、AWS Batch ジョブでバックアップを作成するために使用される Docker コンテナイメージを構築します。バックアッププロセスが完了すると、AWS Batch はバックアップの詳細を Amazon DynamoDB のインベントリテーブルに記録します。追加の安全対策として、AWS Batch でジョブが失敗した場合に CloudWatch Events イベントイベントによって Amazon Simple Notification Service (Amazon SNS) 通知が開始されます。  ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + 既存のマネージド型または非マネージド型のコンピューティング環境。詳細については、AWS Batch ドキュメントの [マネージドコンピューティング環境とアンマネージドコンピューティング環境](https://docs.aws.amazon.com/batch/latest/userguide/compute_environments.html) を参照してください。  + [AWS コマンドラインインターフェイス (AWS CLI) バージョン 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-docker.html) (インストールと設定)。 + Amazon RDS for PostgreSQL DB インスタンス用 Amazon RDS for PostgreSQL DB インスタンス。  + 既存の S3 バケットを使用する  + [Docker](https://www.docker.com/)、Linux、macOS、または Windows にインストールして設定します。 + Lambda でのコーディングに精通していること。  ## アーキテクチャ ![\[pg_dump ユーティリティを使用して Amazon RDS for PostgreSQL DB インスタンスをバックアップするアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/3283f739-980b-43d4-aca0-9d77a2ce3b85/images/352e2eab-1b7d-44ec-840a-a772a175e873.png) **テクノロジースタック** + Amazon CloudWatch Events + Amazon DynamoDB + Amazon Elastic Container Registry (Amazon ECR) + Amazon RDS + Amazon SNS + Amazon S3 + AWS Batch + AWS Key Management Service (AWS KMS) + AWS Lambda + AWS Secrets Manager + Docker ## ツール + [Athena で Amazon CloudWatch Events を使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) – CloudWatch Events は、AWS リソースでの変更を説明するシステムイベントのほぼリアルタイムのストリームを提供します。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスであり、シームレスなスケーラビリティを備えた高速で予測可能なパフォーマンスを提供します。 + 「[Amazon ECR](https://docs.aws.amazon.com/ecr/index.html)」— Amazon Elastic Container Registry (Amazon ECR) は、セキュリティ、スケーラビリティ、信頼性を備えた AWS マネージドコンテナイメージレジストリサービスです。 + 「[Amazon RDS](https://docs.aws.amazon.com/rds/index.html)」— Amazon Relational Database Service (Amazon RDS) は、AWS クラウドでのリレーショナルデータベースのセットアップ、運用、スケールをより簡単にするウェブサービスです。 + 「[Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」— Amazon Simple Notification Service (Amazon SNS) は、パブリッシャーからサブスクライバーへのメッセージ配信を提供するマネージドサービスです。 + 「[Amazon S3](https://docs.aws.amazon.com/s3/index.html)」— Amazon Simple Storage Service (Amazon S3)は、インターネット用のストレージです。 + [AWS Batch](https://docs.aws.amazon.com/batch/index.html) — AWS Batch では、AWS クラウドでバッチコンピューティングワークロードを実行できます。 + [AWS KMS](https://docs.aws.amazon.com/kms/index.html) – AWS Key Management Service (AWS KMS)は、データの暗号化に使用される暗号化キーの作成と管理を容易にするマネージド型サービスです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/index.html) はサーバーをプロビジョニングしたり管理しなくてもコードを実行できるコンピューティングサービスです。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/index.html) は、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールに置き換えて、シークレットをプログラムで取得する上で役立ちます。 + [Docker](https://www.docker.com/) — Dockerを使用すると、開発者はあらゆるアプリケーションを軽量でポータブルな自給自足のコンテナとして簡単に梱包、出荷および実行できます。 Amazon RDS の PostgreSQL DB インスタンスには、[メタデータにタグが適用されている](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) 必要があります。Lambda 関数はタグを検索してバックアップすべき DB インスタンスを識別します。通常は次のタグが使用されます。 | | | タグ | 説明 | | --- |--- | | bkp:AutomatedDBDump = アクティブ | Amazon RDS DB インスタンスをバックアップの候補として識別します。 | | bkp:AutomatedBackupSecret = | Amazon RDS ログイン認証情報を含む Secrets Manager シークレットを識別します。 | | bkp:AutomatedDBDumpS3Bucket = | バックアップの送信先となる S3 バケットを識別します。 | | bkp:AutomatedDBDumpFrequencybkp:AutomatedDBDumpTime | データベースをバックアップする頻度と時間を特定してください。  | | bkp:pgdumpcommand = | バックアップが必要なデータベースを識別します。 | ## エピック ### DynamoDB でインベントリテーブルを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DynamoDB でテーブルを作成します。 | AWS マネジメントコンソールにサインインし、 で Amazon DynamoDB コンソールを開きます。このストーリーやその他のストーリーに関するヘルプは「*関連リソース*」セクションを参照してください。 | クラウド管理者、DBA | | テーブルが作成されたことを確認します。 | `aws dynamodb describe-table --table-name \| grep TableStatus` コマンドを実行します。テーブルが存在する場合、`"TableStatus": "ACTIVE",` コマンドは結果を返します。 | クラウド管理者、DBA | ### AWS Batch で失敗したジョブイベントの SNS トピックを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SNS トピックを作成します。 | Amazon SNS コンソールを開き、**トピック**を選択し、`JobFailedAlert` 名前で SNS トピックを作成します。トピックにアクティブな E メールアドレスを登録し、E メールの受信トレイをチェックして、AWS Notifications からの SNS サブスクリプションメールを確認します。 | クラウド管理者 | | AWS Batch の失敗したジョブイベントルールを作成します。 | Amazon CloudWatchコンソールに移動し、**イベント**を選択して **ルールの作成** を選択します。**詳細オプションを表示**、**編集** の順に選択します。**ターゲットで処理するイベントを選択するパターンを構築**,では、既存のテキストを*追加情報*セクションの「Failed job event」コードに置き換えます。このコードでは、AWS Batch に `Failed` イベントが発生したときに開始される CloudWatch Events イベントルールを定義します。 | クラウド管理者 | | イベントルールターゲットを追加します。 | **[ターゲット]**で、**[ターゲットの追加]** を選択し、[`JobFailedAlert` SNS トピック] を選択します。CloudWatch Events ルールの作成と設定 | クラウド管理者 | ### Docker イメージを Amazon ECR リポジトリにプッシュするには | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECR リポジトリを作成します。 | Amazon ECR コンソールを開き、リポジトリを作成する AWS リージョンを選択します。**リポジトリの追加** を選択し、**リポジトリの作成** を選択します。要件に従ってリポジトリを構成します。 | クラウド管理者 | | Dockerfile を作成します。 | Docker にサインインし、*追加情報* セクションの [サンプル Dockerfile] と [サンプル entrypoint.sh ファイル] を使用して Dockerfile を作成します。 | DevOps エンジニア | | 次に、Docker イメージがAmazon ECR イメージリポジトリにプッシュされます。 | Docker イメージに Docker ファイルをビルドし、Amazon ECR リポジトリにプッシュします。このストーリーやその他のストーリーに関するヘルプは、*関連リソース*セクションを参照してください。 | DevOps エンジニア | ### AWS Batch コンポーネントを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Batch ジョブ定義を作成する | AWS Batch コンソールを開き、Amazon ECR リポジトリのユニフォームリソース識別子 (URI) `Image` をプロパティとして含むジョブ定義を作成します。 | クラウド管理者 | | AWS Batch ジョブキューを設定します。 | AWS Batch コンソールで **Job キュー**を選択し、**キューの作成**を選択します。AWS Batch がコンピューティング環境内のリソースで実行されるまでジョブを保存するジョブキューを作成します。重要：バックアップの詳細を DynamoDB インベントリテーブルに記録する AWS Batch のロジックを必ず記述してください。 | クラウド管理者 | ### Lambda 関数を作成して発行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数を作成して、タグを検索します。 | PostgreSQL DB インスタンス上のタグを検索し、バックアップ候補を識別する Lambda 関数を作成します。Lambda `bkp:AutomatedDBDump = Active` 関数がタグとその他の必要なタグをすべて識別できることを確認してください。重要：Lambda 関数は、AWS Batch ジョブキューにジョブを追加することも可能でなければなりません。 | DevOps エンジニア | | 時間ベースの CloudWatch イベントイベントを作成します。 | Amazon CloudWatch コンソールを開き、cron 式を使用して Lambda 関数を定期的に実行する CloudWatch イベントイベントを作成します。スケジュールされたイベントはすべて UTC\$10 のタイムゾーンを使用しています。 | クラウド管理者 | ### バックアップ自動化のテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon KMS キーを作成します。 | Amazon KMS コンソールを開き、AWS Secrets Manager に保存されている Amazon RDS 認証情報を暗号化するために使用できる KMS キーを作成します。 | クラウド管理者 | | AWS Secrets Manager シークレットを作成する | AWS Secrets Manager コンソールを開き、Amazon RDS for PostgreSQL データベースの認証情報をシークレットとして保存します。 | クラウド管理者 | | 必要なタグを PostgreSQL DB インスタンスに追加します。 | Amazon RDS コンソールを開き、自動的にバックアップしたい PostgreSQL DB インスタンスにタグを追加します。*ツール*セクションの表にあるタグを使用できます。同じ Amazon RDS インスタンス内の複数の PostgreSQL データベースからのバックアップが必要な場合は、`-d test:-d test1` を `bkp:pgdumpcommand` タグの値として使用します。`test` と `test1` はデータベース名です。コロン (：) の後にスペースがないことを確認します。 | クラウド管理者 | | バックアップ自動化を検証してください。 | バックアップの自動化を確認するには、Lambda 関数を呼び出すか、バックアップスケジュールの開始を待つことができます。バックアッププロセスが完了したら、DynamoDB インベントリテーブルに PostgreSQL DB インスタンスの有効なバックアップエントリがあることを確認します。一致すれば、バックアップ自動化プロセスは成功です。 | クラウド管理者 | ## 関連リソース **DynamoDB でインベントリテーブルを作成する** + [Amazon DynamoDB テーブルの作成](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-1.html)   **AWS Batch で失敗したジョブイベントの SNS トピックを作成する** + [Amazon SNS トピックを作成します。](https://docs.aws.amazon.com/sns/latest/dg/sns-tutorial-create-topic.html) + [AWS Batch で失敗したジョブイベントの SNS アラートを送信する](https://docs.aws.amazon.com/batch/latest/userguide/batch_sns_tutorial.html)   **Docker イメージをを構築して、Amazon ECR リポジトリにプッシュする** + [Amazon ECR リポジトリの作成](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)     + [ドッカーファイルを作成し、Docker イメージを作成して Amazon ECR にプッシュする](https://docs.aws.amazon.com/AmazonECR/latest/userguide/getting-started-cli.html)   **AWS Batch コンポーネントの作成** + [AWS Batchジョブ定義の作成](https://docs.aws.amazon.com/batch/latest/userguide/Batch_GetStarted.html#first-run-step-1)     + [コンピューティング環境と AWS Batch ジョブキューの設定](https://docs.aws.amazon.com/batch/latest/userguide/Batch_GetStarted.html#first-run-step-2)    + [AWS Batch でジョブキューを作成する](https://docs.aws.amazon.com/batch/latest/userguide/create-job-queue.html)   **Lambda 関数を作成する** + [Lambda 関数を作成してコードを記述する](https://docs.aws.amazon.com/lambda/latest/dg/getting-started-create-function.html) + [DynamoDB でLambda を使用する](https://docs.aws.amazon.com/lambda/latest/dg/with-ddb.html)   **CloudWatch イベントを作成する** + [時間ベースの CloudWatch イベントイベントを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Scheduled-Rule.html)    + [クラウドウォッチイベントで cron エクスプレッションを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html)   **バックアップ自動化のテスト** + [Amazon KMS キーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)     + [Secrets Manager シークレットを作成する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) + [Amazon RDS インスタンスにタグを追加する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) ## 追加情報 **失敗したジョブイベント：** ``` { "detail-type": [ "Batch Job State Change" ], "source": [ "aws.batch" ], "detail": { "status": [ "FAILED" ] } } ``` **サンプル Dockerfile：** ``` FROM alpine:latest RUN apk --update add py-pip postgresql-client jq bash && \ pip install awscli && \ rm -rf /var/cache/apk/* ADD entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] ``` **サンプル entrypoint.sh ファイル：** ``` #!/bin/bash set -e DATETIME=`date +"%Y-%m-%d_%H_%M"` FILENAME=RDS_PostGres_dump_${RDS_INSTANCE_NAME} FILE=${FILENAME}_${DATETIME} aws configure --profile new-profile set role_arn arn:aws:iam::${TargetAccountId}:role/${TargetAccountRoleName} aws configure --profile new-profile set credential_source EcsContainer echo "Central Account access provider IAM role is: " aws sts get-caller-identity echo "Target Customer Account access provider IAM role is: " aws sts get-caller-identity --profile new-profile securestring=$(aws secretsmanager get-secret-value --secret-id $SECRETID --output json --query 'SecretString' --region=$REGION --profile new-profile) if [[ ${securestring} ]]; then echo "successfully accessed secrets manager and got the credentials" export PGPASSWORD=$(echo $securestring | jq --raw-output | jq -r '.DB_PASSWORD') PGSQL_USER=$(echo $securestring | jq --raw-output | jq -r '.DB_USERNAME') echo "Executing pg_dump for the PostGres endpoint ${PGSQL_HOST}" # pg_dump -h $PGSQL_HOST -U $PGSQL_USER -n dms_sample | gzip -9 -c | aws s3 cp - --region=$REGION --profile new-profile s3://$BUCKET/$FILE # in="-n public:-n private" IFS=':' list=($EXECUTE_COMMAND); for command in "${list[@]}"; do echo $command; pg_dump -h $PGSQL_HOST -U $PGSQL_USER ${command} | gzip -9 -c | aws s3 cp - --region=$REGION --profile new-profile s3://${BUCKET}/${FILE}-${command}".sql.gz" echo $?; if [[ $? -ne 0 ]]; then echo "Error occurred in database backup process. Exiting now....." exit 1 else echo "Postgresql dump was successfully taken for the RDS endpoint ${PGSQL_HOST} and is uploaded to the following S3 location s3://${BUCKET}/${FILE}-${command}.sql.gz" #write the details into the inventory table in central account echo "Writing to DynamoDB inventory table" aws dynamodb put-item --table-name ${RDS_POSTGRES_DUMP_INVENTORY_TABLE} --region=$REGION --item '{ "accountId": { "S": "'"${TargetAccountId}"'" }, "dumpFileUrl": {"S": "'"s3://${BUCKET}/${FILE}-${command}.sql.gz"'" }, "DumpAvailableTime": {"S": "'"`date +"%Y-%m-%d::%H::%M::%S"` UTC"'"}}' echo $? if [[ $? -ne 0 ]]; then echo "Error occurred while putting item to DynamoDb Inventory Table. Exiting now....." exit 1 else echo "Successfully written to DynamoDb Inventory Table ${RDS_POSTGRES_DUMP_INVENTORY_TABLE}" fi fi done; else echo "Something went wrong {$?}" exit 1 fi exec "$@" ``` # CI/CD パイプラインを使用して Amazon EKS へのノード終了ハンドラーのデプロイを自動化する *Amazon Web Services、Sandip Gangapadhyay、Sandeep Gawande、Viyoma Sachdeva、Pragtideep Singh、John Vargas* ## 概要 **注意**: AWS CodeCommit の新規のお客様への提供は終了しています。AWS CodeCommit の既存のお客様は、引き続きサービスをご利用いただけます。[詳細はこちら](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/) Amazon Web Services (AWS) クラウドでは、オープンソースプロジェクトの「[AWS Node Termination Handler](https://github.com/aws/aws-node-termination-handler)」を使用して、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのシャットダウンを正常に処理できます。AWS Node Termination Handler は、EC2 インスタンスが使用できなくなる原因となるイベントに Kubernetes コントロールプレーンが適切に対応できるようにするのに役立ちます。下記のイベントには、次が含まれます。 + 「[EC2 インスタンスの定期メンテナンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html)」 + 「[Amazon EC2 スポットインスタンスの中断](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html)」 + 「[Auto Scaling グループのスケールイン](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroupLifecycle.html#as-lifecycle-scale-in)」 + アベイラビリティーゾーン間の 「[Auto Scaling グループのリバランシング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage)」 + API または AWS マネジメントコンソールによる EC2 インスタンスの終了 イベントが処理されないと、アプリケーションコードが正常に停止しない可能性があります。また、完全な可用性を回復するまでに時間がかかったり、ダウンしているノードに誤って作業をスケジューリングしてしまうこともあります。`aws-node-termination-handler` (NTH) は、インスタンスメタデータサービス (IMDS) とキュープロセッサの 2 つの異なるモードで動作できます。二つのノードについての詳細情報については、「[Readme ファイル](https://github.com/aws/aws-node-termination-handler#readme)」を参照してください。 このパターンでは、 を使用し AWS CodeCommit、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを通じてキュープロセッサを使用して NTH のデプロイを自動化します。 **注記** [EKS マネージドノードグループ](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)を使用している場合は、`aws-node-termination-handler` は必要ありません。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + AWS マネジメントコンソールでの使用がサポートされているウェブブラウザ。「[サポートされるブラウザのリスト](https://aws.amazon.com/premiumsupport/knowledge-center/browsers-management-console/)」を参照してください。 + 「[インストール済み](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_install)」の AWS Cloud Development Kit (AWS CDK) + `kubectl`、Kubernetes コマンドラインツールが 「[インストール](https://kubernetes.io/docs/tasks/tools/)」されています。 + `eksctl`、Amazon Elastic Kubernetes Service (Amazon EKS) の AWS コマンドラインインターフェイス (AWS CLI) が「[インストール](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)」されています。 + バージョン 1.20 以降の稼動中の EKS クラスター + EKS クラスターに接続されているセルフマネージド型ノードグループ。自己管理型ノードグループで Amazon EKS クラスターを作成するには、以下のコマンドを実行します。 ``` eksctl create cluster --managed=false --region --name ``` `eksctl` の詳細については、「[eksctl のドキュメント](https://eksctl.io/usage/creating-and-managing-clusters/)」を参照してください。 + クラスターAWS Identity and Access Management (IAM) OpenID Connect (OIDC) プロバイダー 詳細について、「[クラスターの IAM プロバイダーを作成する](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)」を参照してください。 **制限事項** + Amazon EKS サービスをサポートする AWS リージョンを使用する必要があります。 **製品バージョン** + Kubernetes バージョン 1.20 以降　 + `eksctl` バージョン 0.107.0 以降 + AWS CDK バージョン 2.27.0 またはそれ以降 ## アーキテクチャ **ターゲットテクノロジースタック** + 仮想プライベートクラウド (VPC) + EKS クラスター + Amazon Simple Queue Service (Amazon SQS) + IAM + Kubernetes **ターゲットアーキテクチャ** 次のダイアグラム表は、ノード終了が開始されたときのエンドツーエンドステップのハイレベルビューです。 ![\[Auto Scaling グループを持つ VPC、ノード終了ハンドラーを持つ EKS クラスター、SQS キュー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/970dfb73-9526-4942-a974-e8eef6416596/images/9e0125ae-d55b-49dd-ae70-ccaedf03832a.png) このダイアグラムに示されているワークフローは、以下の大まかなステップで構成されています。 1. 自動スケーリングの EC2 インスタンス終了イベントは SQS キューに送信されます。 1. NTH ポッドは SQS キュー内の新しいメッセージを監視します。 1. NTH ポッドは新しいメッセージを受信し、以下を実行します。 + 新しいポッドがノード上で実行されないように、ノードをコード化します。 + ノードをドレインし、既存のポッドを退避させます。 + ライフサイクルフックシグナルを Auto Scaling グループに送信して、ノードを終了できるようにします。 **自動化とスケール** + コードは AWS CloudFormation のネストスタックによって支えられた AWS CDK によって管理およびデプロイされます。 + 「[Amazon EKS コントロールプレーン](https://docs.aws.amazon.com/eks/latest/userguide/disaster-recovery-resiliency.html)」は、複数のアベイラビリティーゾーンで実行され、高可用性を保証します。 + 「[自動スケーリング](https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html)」については、Amazon EKS は Kubernetes「[クラスター](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)」オートスケーラーと「[Karpenter](https://karpenter.sh/)」をサポートしています。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はフルマネージドの構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + 「[Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)」は、AWS で Kubernetes を実行する際に役立ち、独自の Kubernetes コントロールプレーンまたはノードをインストールまたは維持する必要はありません。 + 「[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)」は、定義した条件に従って、Amazon EC2 インスタンスを自動的に追加または削除できるように、アプリケーションの可用性を維持するのに役立ちます。 + 「[Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)」は、分散したソフトウェアシステムとコンポーネントの統合と切り離しを支援し、セキュアで耐久性があり、利用可能なホスト型キューを提供します。 その他のツール + 「[kubectl](https://kubernetes.io/docs/reference/kubectl/kubectl/)」は、 Kubernetes クラスターに対してコマンドを実行するための Kubernetes コマンドラインツールです。kubectl を使用して、アプリケーションのデプロイ、クラスターリソースの検査と管理、ログの表示を行うことができます。 **コード** このパターンのコードは、GitHub 内の「[deploy-nth-to-eks](https://github.com/aws-samples/deploy-nth-to-eks)」リポジトリで利用できます。コードリポジトリには、以下のファイルとフォルダが含まれます。 + `nth folder` — ノード終了ハンドラー用の AWS CloudFormation テンプレートをスキャンしてデプロイするためのHelm チャート、値ファイル、スクリプト。 + `config/config.json` — アプリケーションの設定パラメータファイル。このファイルには、CDK のデプロイに必要なすべてのパラメーターが含まれています。 + `cdk` — AWS CDK のソースコード。 + `setup.sh` — AWS CDK アプリケーションをデプロイして必要な CI/CD パイプラインとその他の必要なリソースを作成するために使用されるスクリプト。 + `uninstall.sh` — リソースをクリーンアップするために使用されるスクリプト。 例のコードを使用するには、*エピック*セクションの指示に従います。 ## ベストプラクティス AWS ノード終了ハンドラーを自動化する際のベストプラクティスについては、以下を参照してください。 + [ EKS ベストプラクティスガイド](https://aws.github.io/aws-eks-best-practices/) + 「[ノード終了ハンドラー-設定](https://github.com/aws/aws-node-termination-handler/tree/main/config/helm/aws-node-termination-handler)」 ## エピック ### 環境をセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリを変更します。 | SSH (セキュアシェル) を使用してリポジトリをクローンするには、以下のコマンドを実行します。
git clone git@github.com:aws-samples/deploy-nth-to-eks.git
HTTPSを使用して、リポジトリを複製して、以下のコマンドを実行します。
git clone https://github.com/aws-samples/deploy-nth-to-eks.git
リポジトリを複製すると、`deploy-nth-to-eks` という名前のフォルダーが作成されます。そのディレクトリに変更します。
cd deploy-nth-to-eks
| アプリ開発者、AWS DevOps、DevOps エンジニア | | kubeconfig ファイルを設定します。 | ターミナルで AWS 認証情報を設定し、クラスターロールを引き受ける権限があることを確認します。次の例のコードを使用できます。
aws eks update-kubeconfig --name  --region --role-arn
| AWS DevOps、DevOps エンジニア、App 開発者 | ### CI/CD パイプラインをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | パラメータをセットアップします。 | `config/config.json` ファイルで、以下の必須パラメータを設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline.html) | アプリ開発者、AWS DevOps、DevOps エンジニア | | NTH をデプロイする CI/CD パイプラインを作成します。 | setup.sh スクリプトを実行します。
./setup.sh
このスクリプトは、`config/config.json` ファイル内のユーザー入力パラメータに基づいてサンプルコード、パイプライン、および CodeBuild プロジェクトを含む CodeCommit リポジトリを作成する AWS CDK アプリケーションをデプロイします。このスクリプトは sudo コマンドで npm パッケージをインストールする際にパスワードを要求します。 | アプリ開発者、AWS DevOps、DevOps エンジニア | | CI/CD パイプラインを確認します。 | AWS マネジメントコンソールを開き、スタックに作成された以下のリソースを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline.html)パイプラインが正常に実行された後、Helm release `aws-node-termination-handler` が EKS クラスターにインストールされます。また、`aws-node-termination-handler` という名前のポッドがクラスターの `kube-system` 名前空間で実行されています。 | アプリ開発者、AWS DevOps、DevOps エンジニア | ### NTH デプロイをテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Auto Scaling グループのスケールインイベントをシミュレートします。 | 自動スケーリングスケールインイベントをシミュレートするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline.html) | | | ログを見直します。 | スケールインイベント中、NTH ポッドは対応するワーカーノード (スケールインイベントの一部として終了する EC2 インスタンス) をコードオンしてドレインします。ログを確認するには、*追加情報*セクションのコードを使用してください。 | アプリ開発者、AWS DevOps、DevOps エンジニア | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | すべての AWS リソースをクリーンアップします。 | このパターンで作成されたリソースをクリーンアップするには、以下のコマンドを実行します。
./uninstall.sh
これにより、CloudFormation スタックが削除され、このパターンで作成されたすべてのリソースがクリーンアップされます。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | npm レジストリが正しく設定されていません。 | このソリューションのインストール中、スクリプトは npm install をインストールして、必要なパッケージをすべてダウンロードします。インストール中に「モジュールが見つかりません」というメッセージが表示された場合は、npm レジストリが正しく設定されていない可能性があります。以下のコマンドを実行して、現在のレジストリ設定を確認します。
npm config get registry
以下のコマンドを実行して、 `https://registry.npmjs.org/` でレジストリを設定します。
npm config set registry https://registry.npmjs.org
| | SQS メッセージの配信を遅らせる。 | トラブルシューティングの一環として、NTH ポッドへの SQS メッセージ配信を遅延させたい場合は、SQS 配信遅延パラメータを調整できます。詳細については、「[Amazon SQS ディレイキュー](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html)」を参照してください。 | ## 関連リソース + 「[AWS ノード終了ハンドラーのソースコード](https://github.com/aws/aws-node-termination-handler)」 + 「[EC2 ワークショップ](https://ec2spotworkshops.com/using_ec2_spot_instances_with_eks/070_selfmanagednodegroupswithspot/deployhandler.html)」 + [AWS CodePipeline](https://aws.amazon.com/codepipeline/) + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) + 「[AWS クラウド開発キット](https://aws.amazon.com/cdk/)」 + [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ## 追加情報 1. N 番目のポッド名を検出します。 ``` kubectl get pods -n kube-system |grep aws-node-termination-handler aws-node-termination-handler-65445555-kbqc7 1/1 Running 0 26m kubectl get pods -n kube-system |grep aws-node-termination-handler aws-node-termination-handler-65445555-kbqc7 1/1 Running 0 26m ``` 2. ログを確認します。次のようなログの例があります。Auto Scaling グループのライフサイクルフック完了シグナルを送信する前に、ノードが封鎖され、排水されたことを示しています。 ``` kubectl -n kube-system logs aws-node-termination-handler-65445555-kbqc7 022/07/17 20:20:43 INF Adding new event to the event store event={"AutoScalingGroupName":"eksctl-my-cluster-target-nodegroup-ng-10d99c89-NodeGroup-ZME36IGAP7O1","Description":"ASG Lifecycle Termination event received. Instance will be interrupted at 2022-07-17 20:20:42.702 +0000 UTC \n","EndTime":"0001-01-01T00:00:00Z","EventID":"asg-lifecycle-term-33383831316538382d353564362d343332362d613931352d383430666165636334333564","InProgress":false,"InstanceID":"i-0409f2a9d3085b80e","IsManaged":true,"Kind":"SQS_TERMINATE","NodeLabels":null,"NodeName":"ip-192-168-75-60.us-east-2.compute.internal","NodeProcessed":false,"Pods":null,"ProviderID":"aws:///us-east-2c/i-0409f2a9d3085b80e","StartTime":"2022-07-17T20:20:42.702Z","State":""} 2022/07/17 20:20:44 INF Requesting instance drain event-id=asg-lifecycle-term-33383831316538382d353564362d343332362d613931352d383430666165636334333564 instance-id=i-0409f2a9d3085b80e kind=SQS_TERMINATE node-name=ip-192-168-75-60.us-east-2.compute.internal provider-id=aws:///us-east-2c/i-0409f2a9d3085b80e 2022/07/17 20:20:44 INF Pods on node node_name=ip-192-168-75-60.us-east-2.compute.internal pod_names=["aws-node-qchsw","aws-node-termination-handler-65445555-kbqc7","kube-proxy-mz5x5"] 2022/07/17 20:20:44 INF Draining the node 2022/07/17 20:20:44 ??? WARNING: ignoring DaemonSet-managed Pods: kube-system/aws-node-qchsw, kube-system/kube-proxy-mz5x5 2022/07/17 20:20:44 INF Node successfully cordoned and drained node_name=ip-192-168-75-60.us-east-2.compute.internal reason="ASG Lifecycle Termination event received. Instance will be interrupted at 2022-07-17 20:20:42.702 +0000 UTC \n" 2022/07/17 20:20:44 INF Completed ASG Lifecycle Hook (NTH-K8S-TERM-HOOK) for instance i-0409f2a9d3085b80e ``` # CI/CD パイプラインを使用して Amazon EKS へ Java アプリケーションを自動的にビルドし、デプロイする *MAHESH RAGHUNANDANAN、Jomcy Pappachen、James Radtke (Amazon Web Services)* ## 概要 このパターンでは、推奨される DevSecOps プラクティスを使用して Java アプリケーションを自動的にビルドし、 AWS クラウド上の Amazon Elastic Kubernetes Service (Amazon EKS) クラスターにデプロイする継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを作成する方法を説明します。このパターンでは、Spring Boot Java フレームワークで開発され、Apache Maven を使用するグリーティングアプリケーションを使用しています。 このパターンのアプローチを使用して Java アプリケーションのコードをビルドし、アプリケーションのアーティファクトを Docker イメージとしてパッケージ化し、イメージをセキュリティスキャンし、そのイメージをワークロードコンテナとして Amazon EKS にアップロードできます。このパターンのアプローチは、緊密に結合されたモノリシックアーキテクチャからマイクロサービスアーキテクチャに移行する場合に便利です。このアプローチは、Java アプリケーションのライフサイクル全体を監視および管理する上でも役立ち、より高いレベルの自動化が可能になり、エラーまたはバグを回避できます。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + AWS Command Line Interface (AWS CLI) バージョン 2、インストールおよび設定済み。詳細については、 AWS CLI ドキュメントの[「 の最新バージョンのインストールまたは更新 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)」を参照してください。 AWS CLI バージョン 2 は、Amazon EKS クラスターを作成するのと同じ AWS Identity and Access Management (IAM) `aws-auth` ロールで設定する必要があります。これは、そのロールのみが に他の IAM ロールを追加する権限を持っているためです`ConfigMap`。設定の詳細と手順については AWS CLI、 AWS CLI ドキュメントの[「設定の構成](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html)」を参照してください。 + へのフルアクセスを持つ IAM ロールとアクセス許可 AWS CloudFormation。詳細については、 CloudFormation ドキュメントの[「IAM によるアクセスの制御](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)」を参照してください。 + EKS クラスター内のワーカーノードの IAM ロール名と IAM ロールの Amazon リソースネーム (ARN) の詳細を含む既存の Amazon EKS クラスター。 + Amazon EKS クラスターにインストールおよび設定済みの Kubernetes クラスターオートスケーラー。詳細については、Amazon EKS ドキュメントの「[Karpenter と Cluster Autoscaler を使用したクラスターコンピューティングのスケーリング](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html)」を参照してください。  + GitHub リポジトリのコードへのアクセス。 **重要** AWS Security Hub CSPM は、このパターンのコードに含まれる CloudFormation テンプレートの一部として有効になります。デフォルトでは、Security Hub CSPM を有効にすると、30 日間の無料トライアルが付属しています。トライアル後、この AWS のサービスに関連するコストが発生します。料金の詳細については、「[AWS Security Hub CSPM の料金](https://aws.amazon.com/security-hub/pricing/)」を参照してください。 **製品バージョン** + Helm バージョン 3.4.2 以降 + Apache Maven バージョン 3.6.3 以降 + BridgeCrew Checkov バージョン 2.2 以降 + Aqua Security Trivy バージョン 0.37 以降 ## アーキテクチャ **テクノロジースタック** + AWS CodeBuild + AWS CodeCommit + Amazon CodeGuru + AWS CodePipeline + Amazon Elastic Container Registry (Amazon ECR) + Amazon EKS + Amazon EventBridge + AWS Security Hub CSPM + Amazon Simple Notification Service (Amazon SNS) **ターゲットアーキテクチャ** ![\[Java アプリケーションを Amazon EKS にデプロイするためのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/95a5b5c2-d7fb-41eb-9089-455318c0d585/images/4f5fd8c2-2b6d-4945-aa64-fcf317521711.png) この図表は、次のワークフローを示しています: 1. 開発者は CodeCommit リポジトリのベースブランチにある Java アプリケーションコードを更新し、プルリクエスト (PR) を作成します。 1. PR が送信されるとすぐに、Amazon CodeGuru Reviewer はコードを自動的にレビューし、Java のベストプラクティスに基づいて分析し、開発者に推奨事項を提示します。 1. PR がベースブランチにマージされると、Amazon EventBridge イベントが作成されます。 1. EventBridge イベントは CodePipeline パイプラインを起動し、開始されます。 1. CodePipeline は CodeSecurity スキャンステージ (継続的セキュリティ) を実行します。 1. AWS CodeBuild は、Dockerfile および Kubernetes デプロイ Helm ファイルが Checkov を使用してスキャンされ、アプリケーションのソースコードが増分コード変更に基づいてスキャンされるセキュリティスキャンプロセスを開始します。アプリケーションのソースコードスキャンは、[CodeGuru Reviewer コマンドラインインターフェイス (CLI) ラッパー](https://github.com/aws/aws-codeguru-cli)によって実行されます。 **注記** 2025 年 11 月 7 日現在、Amazon CodeGuru Reviewer で新しいリポジトリの関連付けを作成することはできません。CodeGuru Reviewer と同様の機能を持つサービスの詳細については、[CodeGuru Reviewer ドキュメントの「Amazon CodeGuru Reviewer の可用性の変更](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/codeguru-reviewer-availability-change.html)」を参照してください。 CodeGuru 1. セキュリティスキャンステージが成功すると、ビルドステージ (継続的インテグレーション) が開始されます。 1. ビルド段階では、CodeBuild はアーティファクトをビルドし、アーティファクトを Docker イメージにパッケージ化し、Aqua Security Trivy を使用してセキュリティの脆弱性に対するイメージをスキャンし、イメージを Amazon ECR に保存します。 1. ステップ 8 で検出された脆弱性は、開発者またはエンジニアによる詳細な分析のために Security Hub CSPM にアップロードされます。Security Hub CSPM は、脆弱性を修復するための概要と推奨事項を提供します。 1. CodePipeline パイプライン内の一連のフェーズの E メール通知は Amazon SNS で送信されます。 1. 継続的インテグレーションフェーズが完了すると、CodePipeline は Deploy ステージ (継続的デリバリー) に入ります。 1. Docker イメージは、Helm チャートを使用してコンテナワークロード (ポッド) として Amazon EKS にデプロイされます。 1. アプリケーションポッドは、アプリケーションのプロファイリングデータ (CPU、ヒープ使用量、レイテンシー) を CodeGuru Profiler に送信する Amazon CodeGuru Profiler エージェントで構成されます。これで、開発者はアプリケーションの動作を理解し易くなります。 ## ツール **AWS のサービス** + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理することなく、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。 + [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html) は、ライブアプリケーションからランタイムパフォーマンスデータを収集し、アプリケーションのパフォーマンスを微調整する上で役立つ推奨事項を提供します。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなど、さまざまなソースからのリアルタイムデータにアプリケーションを接続するのに役立つサーバーレスイベントバスサービスです AWS アカウント。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) は、 のセキュリティ状態の包括的なビューを提供します AWS。また、セキュリティ業界標準とベストプラクティスに照らして AWS 環境を確認するのにも役立ちます。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、任意のデータ量を保存、保護、取得する際に役立つクラウドベースのオブジェクトストレージサービスです。 **その他のサービス** + [Helm](https://helm.sh/docs/) は Kubernetes 用のオープンソースのパッケージマネージャーです。 + [Apache Maven](https://maven.apache.org/) は、ソフトウェアプロジェクトを管理する包括ツールです。 + [BridgeCrew Checkov](https://www.checkov.io/1.Welcome/What%20is%20Checkov.html) は、Infrastructure as Code (IaC)ファイルをスキャンして、セキュリティまたはコンプライアンスの問題につながる可能性のある設定ミスを検出する静的コード分析ツールです。 + [Aqua Security Trivy](https://github.com/aquasecurity/trivy) は、設定の問題に加えて、コンテナイメージ、ファイルシステム、Git リポジトリの脆弱性のための包括的スキャナーです。 **コード** このパターンのコードは、GitHub 内の「[aws-codepipeline-devsecops-amazoneks](https://github.com/aws-samples/aws-codepipeline-devsecops-amazoneks)」リポジトリで利用できます。 ## ベストプラクティス + このパターンは、[IAM セキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)に従って、ソリューションのすべてのフェーズで IAM エンティティに最小特権の原則を適用します。追加ツール AWS のサービス またはサードパーティーツールを使用してソリューションを拡張する場合は、IAM ドキュメントの[最小特権のアクセス許可の適用](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)に関するセクションを確認することをお勧めします。 + Java アプリケーションが複数ある場合は、各アプリケーションに個別の CI/CD パイプラインを作成することをお勧めします。 + モノリスアプリケーションがある場合は、アプリケーションを可能な場合マイクロサービスに分割することをお勧めします。マイクロサービスは柔軟性が高く、アプリケーションをコンテナとして簡単にデプロイでき、アプリケーションのビルドとデプロイ全体をよりよく把握できます。 ## エピック ### 環境をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub リポジトリのクローン作成 | リポジトリのクローンを作成するには、次の コマンドを実行します。
git clone https://github.com/aws-samples/aws-codepipeline-devsecops-amazoneks
| アプリ開発者、DevOps エンジニア | | S3 バケットを作成し、コードをアップロードします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | AWS DevOps、クラウド管理者、DevOps エンジニア | | CloudFormation スタックを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | AWS DevOps、DevOps エンジニア | | CloudFormation スタックデプロイを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | AWS DevOps、DevOps エンジニア | | S3 バケットを削除します。 | 以前に作成した S3 バケットを空にして削除します。詳細については、Amazon EFS ユーザーガイドの「[バケットの削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)」を参照してください。 | AWS DevOps、DevOps エンジニア | ### Helm チャートを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Java アプリケーションの Helm チャートを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | DevOps エンジニア | | Helm チャートの構文エラーを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | DevOps エンジニア | ### Java CI/CD パイプラインを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CI/CD パイプラインを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | AWS DevOps | ### Security Hub CSPM と Aqua Security の統合を有効にする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Aqua Security の統合をオンにします。 | このステップは、Trivy によって報告された Docker イメージの脆弱性の検出結果を Security Hub CSPM にアップロードするために必要です。 CloudFormation は Security Hub CSPM 統合をサポートしていないため、このプロセスは手動で行う必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | AWS 管理者、DevOps エンジニア | ### Helm コマンドまたは kubectl コマンドを実行する CodeBuild を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CodeBuild が Amazon EKS クラスターで Helm または kubectl コマンドを実行できるようにします。 | CodeBuild が Amazon EKS クラスターで Helm または `kubectl` コマンドを使用するように認証されるようにするには、IAM ロールを `aws-auth` `ConfigMap` に追加する必要があります。この場合は、IAM ロール `EksCodeBuildkubeRoleARN` の ARN を追加します。これは、CodeBuild サービスが Amazon EKS クラスターにアクセスしてワークロードをデプロイするために作成された IAM ロールです。このアクティビティは 1 回限りです。次の手順は、CodePipeline のデプロイ承認段階の前に完了する必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html)`aws_auth` `ConfigMap` が設定され、アクセスが付与されます。 | DevOps | ### CI/CD パイプラインを検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CI/CD パイプラインが自動的に開始されることを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html)CodePipeline を使用してパイプラインを開始する方法の詳細については、CodePipeline ドキュメントの「[Start a pipeline in CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-about-starting.html)」、「[Start a pipeline manually](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-rerun-manually.html)」、および「[Start a pipeline on a schedule](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-trigger-source-schedule.html)」を参照してください。 | DevOps | | デプロイを承認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | DevOps | | アプリケーションプロファイリングを検証します。 | デプロイが完了し、アプリケーションポッドが Amazon EKS にデプロイされると、アプリケーションに設定されている Amazon CodeGuru Profiler エージェントは、アプリケーションのプロファイリングデータ (CPU、ヒープサマリー、レイテンシー、ボトルネック) を CodeGuru Profiler に送信します。アプリケーションの初期デプロイでは、CodeGuru Profiler はプロファイリングデータの可視化に約 15 分かかります。 | AWS DevOps | ## 関連リソース + [AWS CodePipeline ドキュメント](https://docs.aws.amazon.com/codepipeline/index.html) + [の Trivy を使用したイメージのスキャン AWS CodePipeline](https://aws.amazon.com/blogs/containers/scanning-images-with-trivy-in-an-aws-codepipeline/) (AWS ブログ記事) + [Amazon CodeGuru Profiler を使用した Java アプリケーションの改善](https://aws.amazon.com/blogs/devops/improving-your-java-applications-using-amazon-codeguru-profiler) (AWS ブログ記事) + [AWS Security Finding Format (ASFF) 構文](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format-syntax.html) + [Amazon EventBridge のイベントパターン](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html) + 「[Helm アップグレード](https://helm.sh/docs/helm/helm_upgrade/)」 ## 追加情報 + CodeGuru Profiler は、機能の観点から AWS X-Ray サービスと混同しないでください。CodeGuru Profiler は、ボトルネックまたはセキュリティ問題の原因となる可能性がある最もコストのかかるコード行を特定し、潜在的なリスクになる前に修正するために使用することをお勧めします。X-Ray サービスは、アプリケーションのパフォーマンスをモニタリングするものです。 + このパターンでは、イベントルールはデフォルトのイベントバスに関連付けられます。必要に応じて、カスタムイベントバスを使用するようにパターンを拡張できます。 + このパターンでは、CodeGuru Reviewer をアプリケーションコードの静的アプリケーションセキュリティテスト (SAST) ツールとして使用します。このパイプラインは、SonarQube または Checkmarx などの他のツールにも使用できます。これらのツールのいずれかのスキャンセットアップ手順を `buildspec/buildspec_secscan.yaml` に追加して、CodeGuru スキャン手順を置き換えることができます。 **注記** 2025 年 11 月 7 日現在、Amazon CodeGuru Reviewer で新しいリポジトリの関連付けを作成することはできません。CodeGuru Reviewer と同様の機能を持つサービスの詳細については、[CodeGuru Reviewer ドキュメントの「Amazon CodeGuru Reviewer の可用性の変更](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/codeguru-reviewer-availability-change.html)」を参照してください。 CodeGuru # AWS アカウント と 間で Amazon ECR コンテナイメージをコピーする AWS リージョン *Faisal Shahdad (Amazon Web Services)* ## 概要 このパターンは、サーバーレスアプローチを使用して、タグ付けされたイメージを既存の Amazon Elastic Container Registry (Amazon ECR) リポジトリから他の AWS アカウント および にレプリケートする方法を示しています AWS リージョン。このソリューションでは、 AWS Step Functions を使用してレプリケーションワークフローを管理し、 AWS Lambda 関数を使用して大きなコンテナイメージをコピーします。 Amazon ECR は、リージョンとアカウント間でコンテナイメージをレプリケートする、ネイティブの[クロスリージョン](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-examples.html#registry-settings-examples-crr-single)および[クロスアカウント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-examples.html#registry-settings-examples-crossaccount)レプリケーション機能を使用します。ただし、これらの機能は、レプリケーションを有効化した時点以降のイメージのみをレプリケートします。異なるリージョンやアカウントに既存のイメージをレプリケートするメカニズムはありません。 このパターンは、人工知能 (AI) チームがコンテナ化された機械学習 (ML) モデル、フレームワーク (PyTorch、TensorFlow、Hugging Face など)、依存関係を他のアカウントやリージョンに配布するのに役立ちます。これにより、サービスの制限を克服し、GPU コンピューティングリソースを最適化できます。特定のレプリケート元アカウントとリージョンから、Amazon ECR リポジトリを選択的にレプリケートすることもできます。詳細については、「[Cross-Region replication in Amazon ECR has landed](https://aws.amazon.com/blogs/containers/cross-region-replication-in-amazon-ecr-has-landed/)」を参照してください。 ## 前提条件と制限 **前提条件** + 2 つ以上のアクティブ AWS アカウント (少なくとも 1 つのソースアカウントと 1 つの送信先アカウント) + すべてのアカウントの適切な AWS Identity and Access Management (IAM) アクセス許可 + Lambda コンテナイメージを構築するための Docker + AWS Command Line Interface すべてのアカウントに設定された (AWS CLI) **制限事項** + **タグのないイメージの除外 – **このソリューションでは、明示的なタグを持つコンテナイメージのみがコピーされます。`SHA256` ダイジェストを持つが、タグのないイメージはスキップされます。 + **Lambda 実行タイムアウト制約 –** AWS Lambda 最大 15 分の実行タイムアウトに制限されており、大きなコンテナイメージやリポジトリをコピーするには不十分である可能性があります。 + **コンテナイメージの手動管理 – **`crane-app.py` Python コードでは、Lambda コンテナイメージを再構築および再デプロイする必要があります。 + **並列処理容量の制限 – **`MaxConcurrency` 状態設定は、同時にコピーできるリポジトリの数を制限します。ただし、この設定はソースアカウントの AWS CloudFormation テンプレートで変更できます。同時実行値を大きくすると、サービスレート制限、およびアカウントレベルの Lambda 実行クォータが超過する可能性があることに注意してください。 ## アーキテクチャ **ターゲットスタック** このパターンには、次の 4 つの主要コンポーネントがあります。 + **レプリケート元アカウントのインフラストラクチャ – **オーケストレーションコンポーネントを作成する CloudFormation テンプレート + **レプリケート先アカウントインフラストラクチャ –** クロスアカウントアクセスロールを作成する CloudFormation テンプレート + **Lambda 関数 – **Python ベースの関数であり、Crane を使用してイメージを効率的にコピー + **コンテナイメージ – **必要なツールとともに Lambda 関数をパッケージ化する Docker コンテナ **ターゲットアーキテクチャ** ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/787185e7-664b-4ed8-b30f-1d9507f13377/images/cc7d9823-3dc8-4090-a203-910b1ac4447c.png) **Step Function ワークフロー** 次の図に示すように、Step Functions ステートマシンは以下をオーケストレーションします。 + `PopulateRepositoryList`** –** Amazon ECR リポジトリをスキャンし、Amazon DynamoDB に入力 + `GetRepositoryList`** –** DynamoDB から一意のリポジトリリストを取得 + `DeduplicateRepositories`** –** 重複して実施される処理がないことを確認 + `CopyRepositories`** –** リポジトリの並列コピーを処理 + `NotifySuccess`/`NotifyFailure`** –** 実行結果に基づく Amazon Simple Notification Service (Amazon SNS) 通知 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/787185e7-664b-4ed8-b30f-1d9507f13377/images/1b740084-ba2b-4956-aa12-ebbf52be5e7d.png) ## ツール **Amazon ツール** + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行しているアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + [Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、Lambda 関数とその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。 **その他のツール** + [Crane](https://michaelsauter.github.io/crane/index.html) は Docker オーケストレーションツールです。これは Docker Compose に似ていますが、追加の機能があります。 + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信する、Platform as a Service (PaaS) 製品のセットです。 **コードリポジトリ** + このパターンのコードは、GitHub 内の [sample-ecr-copy repository](https://github.com/aws-samples/sample-ecr-copy) リポジトリで利用できます。このリポジトリの CloudFormation テンプレートを使用して、基盤となるリソースを作成できます。 ## ベストプラクティス 最小特権の原則に従い、タスクの実行に必要最小限のアクセス許可を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 ## エピック ### 環境を準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CLI プロファイルを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps エンジニア、データエンジニア、ML エンジニア | | 必要な情報の収集 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps エンジニア、データエンジニア、ML エンジニア | | リポジトリのクローンを作成する | ローカルワークステーションに、プラットフォームリポジトリのクローンを作成します。
git clone https://github.com/aws-samples/sample-ecr-copy
| DevOps エンジニア、データエンジニア、ML エンジニア | ### レプリケート先アカウントのインフラストラクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テンプレートの検証 | CloudFormation テンプレートを検証します。
aws cloudformation validate-template \
  --template-body file://"Destination Account cf_template.yml" \
  --profile destination-account
| DevOps エンジニア、ML エンジニア、データエンジニア | | レプリケート先インフラストラクチャのデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | データエンジニア、ML エンジニア、DevOps エンジニア | | デプロイメントを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps エンジニア、ML エンジニア、データエンジニア | ### Lambda コンテナイメージをビルドしてデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コンテナビルドの準備 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | データエンジニア、ML エンジニア、DevOps エンジニア | | コンテナイメージの構築 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | データエンジニア、ML エンジニア、DevOps エンジニア | | リポジトリを作成してイメージをアップロードする | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | データエンジニア、ML エンジニア、DevOps エンジニア | | イメージの確認 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | データエンジニア、ML エンジニア、DevOps エンジニア | ### レプリケート元アカウントインフラストラクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイパラメータの準備 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | データエンジニア、DevOps エンジニア、ML エンジニア | | レプリケート元テンプレートの検証 | レプリケート元 CloudFormation テンプレートを検証します。
aws cloudformation validate-template \
  --template-body file://"Source Account Cf template.yml" \
  --profile source-account
| データエンジニア、ML エンジニア、DevOps エンジニア | | レプリケート元インフラストラクチャのデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | データエンジニア、ML エンジニア、DevOps エンジニア | | デプロイを確認し、出力を収集 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps エンジニア、ML エンジニア、データエンジニア | | メールサブスクリプションの確認 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | データエンジニア、ML エンジニア、DevOps エンジニア | ### コピープロセスを実行してモニタリングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コピープロセスを実行してモニタリングする | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps エンジニア、ML エンジニア、データエンジニア | | ステップ関数の実行 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps エンジニア、ML エンジニア、データエンジニア | | 進行状況のモニタリング | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps エンジニア、ML エンジニア、データエンジニア | | 結果の確認 | プロセスが完了するまで待ちます (30 秒ごとに更新)。
while true; do
  STATUS=$(aws stepfunctions describe-execution \
    --execution-arn $EXECUTION_ARN \
    --profile source-account \
    --region $SOURCE_REGION \
    --query 'status' \
    --output text)
  
  echo "Current status: $STATUS"
  
  if [[ "$STATUS" == "SUCCEEDED" || "$STATUS" == "FAILED" || "$STATUS" == "TIMED_OUT" || "$STATUS" == "ABORTED" ]]; then
    break
  fi
  
  sleep 30
done

echo "Final execution status: $STATUS"
| DevOps エンジニア、ML エンジニア、データエンジニア | | イメージの確認 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps エンジニア、データエンジニア、ML エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ステップ関数の実行に失敗した | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | ## 関連リソース + [Crane ドキュメント](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) + [What is Amazon Elastic Container Registry?](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) + [とは AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + [What is Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) ## 追加情報 **設定パラメータ** | | | パラメータ | 説明 | 例 | | --- |--- |--- | | `SourceAccountId` | ソース AWS アカウント ID | `11111111111` | | `DestinationAccountId` | 送信先 AWS アカウント ID | `22222222222` | | `DestinationRegion` | ターゲット AWS リージョン | `us-east-2` | | `SourceRegion` | ソース AWS リージョン | `us-east-1` | | `NotificationEmail` | E メール通知 | `abc@xyz.com` | | `RepositoryList` | コピーするリポジトリ | `repo1,repo2,repo3` | | `LambdaImageUri` | Lambda コンテナイメージの URI | `${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com/ecr-copy-lambda:latest` | # Amazon ECS タスク定義を作成し、Amazon EFS を使用して EC2 インスタンスにファイルシステムをマウントする *Amazon Web Services、Durga Prasad Cheepuri* ## 概要 このパターンは、Amazon Elastic Container Service (Amazon ECS) タスク定義を作成しますが、このタスク定義により、Amazon Web Services (AWS) クラウド内のAmazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行され、Amazon Elastic File System (Amazon EFS) を使用してファイルシステムをマウントします。Amazon EFS を使用する Amazon ECS タスクは、タスク定義で指定したファイルシステムを自動的にマウントし、これらのファイルシステムを AWS リージョンのすべてのアベイラビリティーゾーンのタスクのコンテナで使用できるようにします。 永続ストレージと共有ストレージの要件を満たすには、Amazon ECS と Amazon EFS を同時に使用できます。たとえば、Amazon EFS を使用してアプリケーションの永続的なユーザーデータやアプリケーションデータを保存し、可用性を高めるために異なるアベイラビリティーゾーンで実行されるアクティブ/スタンバイ ECS コンテナペアを使用できます。Amazon EFS により、ECS コンテナと分散ジョブワークロードからparallel アクセスできる共有データを保存することもできます。 Amazon ECS で Amazon EFS を使用するには、タスク定義に 1 つ以上のボリューム定義を追加できます。ボリューム定義には、Amazon EFS ファイルシステム ID、アクセスポイント ID、AWS Identity and Access Management (IAM) 認可または転送中の Transport Layer Security (TLS) 暗号化の設定が含まれています。タスク定義内のコンテナ定義により、コンテナの実行時にマウントされるタスク定義ボリュームを指定できます。Amazon EFS ファイルシステムを使用するタスクを実行すると、Amazon ECS はファイルシステムがマウントされ、アクセスが必要なコンテナで使用できるようにします。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + 仮想プライベートネットワーク (VPN) エンドポイントまたはルーターを使用する仮想プライベートクラウド (VPC) + (推奨) Amazon EFS アクセスポイントおよび IAM 認証機能との互換性のために [Amazon ECS コンテナエージェント 1.38.0 以降](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-versions.html) (詳細については、AWS ブログ記事「[New for Amazon EFS – IAM Authorization and Access Points](https://aws.amazon.com/blogs/aws/new-for-amazon-efs-iam-authorization-and-access-points/)」を参照してください)。 **制限** + 1.35.0 より前のバージョンの Amazon ECS コンテナエージェントは、EC2 起動タイプを使用するタスク用の Amazon EFS ファイルシステムをサポートしません。 ## アーキテクチャ 次の図は、Amazon ECS により、タスク定義を作成し、ECS コンテナ内の EC2 インスタンスに Amazon EFS ファイルシステムをマウントするアプリケーションの例を示しています。 ![\[Amazon ECS architecture with task definition, ECS service, containers, and EFS file system integration.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/090a3f03-a4c6-47e3-b1ae-b0eb5c5b269c/images/343e0f1d-44ee-4ec2-8392-aeddc0e48b83.png) この図表は、次のワークフローを示しています: 1. Amazon EFS ファイルシステムを作成します。 1. コンテナにより、タスク定義を作成します。 1. Amazon EFS ファイルシステムをマウントするようにコンテナインスタンスを設定します。タスク定義はボリューム マウントを参照するため、コンテナ インスタンスは Amazon EFS ファイル システムを使用できます。ECS タスクは、タスクが作成されたコンテナインスタンスと関係なく、同じ Amazon EFS ファイルシステムにアクセスできます。 1. タスク定義の 3 つのインスタンスにより、Amazon ECS サービスを作成します。 テクノロジースタック + Amazon EC2 + Amazon ECS + Amazon EFS ## ツール + 「[Amazon EC2](https://docs.aws.amazon.com/ec2/?id=docs_gateway)」— Amazon Elastic Compute Cloud (Amazon EC2) は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。Amazon EC2 を使用して必要な分だけ仮想サーバーを起動し、スケールアウトまたはスケールインできます。 + 「[Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)」— Amazon Elastic Container Service (Amazon ECS) は、クラスターでコンテナの実行、停止、管理に使用される、高度にスケーラブルで高速のコンテナ管理サービスです。AWS Fargate が管理するサーバーレスインフラ上でタスクやサービスを実行できます。または、インフラストラクチャをより詳細に制御するために、管理する EC2 インスタンスのクラスターでタスクとサービスを実行できます。 + 「[Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)」— Amazon Elastic File System (Amazon EFS)は、AWS クラウドサービスやオンプレミスのリソースで使用できる、シンプルでスケーラブルな、フルマネージドされた伸縮自在な NFS ファイルシステムを提供します。 + 「[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)」— AWS コマンドラインインターフェイス (AWS CLI) はオープンソースのツールで、コマンドラインシェルのコマンドで AWS サービスと対話します。最小限の構成で、コマンドプロンプトからブラウザベースの AWS マネジメントコンソールで提供される機能と同等の機能を実装する AWS CLI コマンドを実行できます。 ## エピック ### Amazon EFS ファイルシステムを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS マネジメントコンソールを使用して Amazon EFS ファイルシステムを作成する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs.html) | AWS DevOps | ### Amazon EFS ファイルシステムまたは AWS CLI のいずれかで Amazon ECS タスク定義を作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EFS ファイルシステムでタスク定義を作成します。 | 「[新しい Amazon ECS コンソール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)」または「[従来の Amazon ECS コンソール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition-classic.html)」を以下の設定で使用して、タスク定義を作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs.html) | AWS DevOps | | AWS CLI を使用してタスク定義を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs.html) | AWS DevOps | ## 関連リソース + 「[Amazon ECSの タスク定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)」 + 「[Amazon EFS ボリューム](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/efs-volumes.html)」 ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/090a3f03-a4c6-47e3-b1ae-b0eb5c5b269c/attachments/attachment.zip)」 # コンテナイメージを使用して Lambda 関数をデプロイする *Ram Kandaswamy、Amazon Web Services* ## 概要 AWS Lambda は、コンテナイメージをデプロイモデルとしてサポートします。このパターンは、コンテナイメージを使用して Lambda 関数をデプロイする方法を示しています。  Lambda はサーバーレスでイベント駆動型のコンピューティングサービスであり、サーバーをプロビジョニングしたり管理したりしなくても、実質どのようなタイプのアプリケーションやバックエンドサービスでも実行できます。Lambda 関数のコンテナイメージサポートにより、アプリケーションアーティファクト用に最大 10 GB のストレージを確保できるというメリットと、使い慣れたコンテナイメージ開発ツールを使用できるというメリットがあります。 このパターンの例では、基礎となるプログラミング言語として Python を使用していますが、Java、Node.js、Go などの他の言語も使用できます。ソースとして、GitLab ベースのシステム、例えば GitHub、GitLab、Bitbucket などを検討するか、Amazon Simple Storage Service (Amazon S3) を使用します。 ## 前提条件と制限事項 **前提条件** + Amazon Elastic Container Registry (Amazon ECR) がアクティブ化される + アプリケーションコード + ランタイムインターフェイスクライアントと最新バージョンの Python を含む Docker イメージ + Git の実用的な知識 **制限事項** + サポートされる最大モデルサイズは 10 GB です。 + Lambda ベースのコンテナデプロイの最大実行時間は 15 分です。 ## アーキテクチャ **ターゲットアーキテクチャ** ![\[Lambda 関数を作成するための 4 ステップのプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e421cc58-d33e-493d-b0bb-c3ffe39c2eb9/images/7f36d3d8-d161-497a-b036-26d886a16c69.png) 1. Git リポジトリを作成し、アプリケーションコードをリポジトリにコミットします。 1. AWS CodeBuild プロジェクトはコミットの変更によってトリガーされます。 1. CodeBuild プロジェクトが Docker イメージを作成し、Amazon ECR にビルドイメージを公開します。 1. Amazon ECR のイメージを使用して Lambda 関数を作成します。 **自動化とスケール** このパターンは、 AWS CloudFormation、 AWS Cloud Development Kit (AWS CDK)または SDK の API オペレーションを使用して自動化できます。Lambda はリクエスト数に基づいて自動的にスケーリングでき、同時実行パラメータを使用して調整できます。詳細については、[Lambda のドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html)を参照してください。 ## ツール **AWS サービス** + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) AWS CloudFormationhelpsは、 AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理します AWS リージョン。このパターンでは、 CloudFormation テンプレートを視覚的に表示および編集するのに役立つ [AWS CloudFormation Application Composer](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/app-composer-for-cloudformation.html) を使用します。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 **その他のツール** + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしての Platform as a Service (PaaS) 製品のセットです。 + [GitHub](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories)、[GitLab](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html)、[Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/tutorial-learn-bitbucket-with-git/) は、ソースコードの変更を追跡するために一般的に使用される Git ベースのソース管理システムの一部です。 ## ベストプラクティス + 不要なファイルが読み込まれないように、関数はできるだけ効率的かつ小さくしてください。 + 静的レイヤーは Docker ファイルリストの上位に配置し、頻繁に変更されるレイヤーは下位に配置するようにしてください。これによりキャッシュが向上し、パフォーマンスが向上します。 + イメージ所有者は、イメージの更新とパッチの適用を担当します。その更新頻度を運用プロセスに追加してください。詳細については、[AWS Lambda のドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-code)を参照してください。 ## エピック ### CodeBuild プロジェクトを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Git リポジトリを作成します。 | アプリケーションソースコード、Dockerfile、および `buildspec.yaml` ファイルを含む Git リポジトリを作成します。 | 開発者 | | CodeBuild プロジェクトを作成する。 | CodeBuild プロジェクトを使用してカスタム Lambda イメージを作成する手順は、次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-lambda-functions-with-container-images.html) | 開発者 | | Dockerfile を編集する。 | Dockerfile は、アプリケーションを開発している最上位のディレクトリに配置する必要があります。Python コードは `src` フォルダにあるはずです。イメージを作成するときは、[Lambda がサポートする公式イメージ](https://gallery.ecr.aws/lambda?page=1)を使用してください。そうしないと、起動エラーが発生し、パッキング処理がより困難になります。詳細については、「[追加情報](#deploy-lambda-functions-with-container-images-additional)」セクションを参照してください。 | 開発者 | | Amazon ECR でリポジトリを作成します。 | Amazon ECR にコンテナリポジトリを作成します。以下のコマンド例では、作成されたリポジトリの名前は `cf-demo` です。
aws ecr create-repository --cf-demo
リポジトリは `buildspec.yaml` ファイル内で参照されます。 | AWS 管理者、デベロッパー | | Amazon ECR にイメージをプッシュします。 | CodeBuild を使用してイメージビルドプロセスを実行できます。CodeBuild には Amazon ECR とやりとりしたり S3 を操作したりするためのアクセス権限が必要です。プロセスの一環として、Docker イメージがビルドされ、Amazon ECR レジストリにプッシュされます。テンプレートとコードの詳細については、「[追加情報](#deploy-lambda-functions-with-container-images-additional)」セクションを参照してください。 | 開発者 | | イメージがリポジトリにあることを確認する。 | イメージがリポジトリにあることを確認するには、Amazon ECR コンソールで **[リポジトリ]** を選択します。Amazon ECR 設定で脆弱性スキャン機能が有効になっている場合は、イメージがタグ付きで一覧表示され、脆弱性スキャンレポートの結果も表示されます。 詳細については、[AWS ドキュメント](https://docs.aws.amazon.com/cli/latest/reference/ecr/put-registry-scanning-configuration.html)を参照してください。 | 開発者 | ### イメージを実行する Lambda 関数を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数を作成します。 | Lambda コンソールで **[関数の作成]** を選択し、**[コンテナイメージ]** を選択します。Amazon ECR リポジトリにあるイメージの関数名と URI を入力し、**[関数の作成]** を選択します。詳細については、[AWS Lambda のドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/API_CreateFunction.html)を参照してください。 | アプリ開発者 | | Lambda 関数をテストします。 | 関数を呼び出してテストするには、**[テスト]** を選択します。詳細については、[AWS Lambda のドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/testing-functions.html)を参照してください。 | アプリデベロッパー | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ビルドが成功しない。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-lambda-functions-with-container-images.html) | ## 関連リソース + [Lambda のベースイメージ](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-images.html) + [CodeBuild の Docker サンプル](https://docs.aws.amazon.com/codebuild/latest/userguide/sample-docker.html) + [一時的な認証情報を渡す](https://aws.amazon.com/premiumsupport/knowledge-center/codebuild-temporary-credentials-docker/) ## 追加情報 **Docker ファイルの編集** 以下のコードは、Dockerfile で編集するコマンドを示しています。 ``` FROM public.ecr.aws/lambda/python:3.xx # Copy function code COPY app.py ${LAMBDA_TASK_ROOT} COPY requirements.txt ${LAMBDA_TASK_ROOT} # install dependencies RUN pip3 install --user -r requirements.txt # Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile) CMD [ "app.lambda_handler" ] ``` `FROM` コマンドで、Lambda でサポートされている Python バージョンに適した値を使用します (例: `3.12`)。これが、パブリック Amazon ECR イメージリポジトリで使用できるベースイメージになります。  `COPY app.py ${LAMBDA_TASK_ROOT}` コマンドは、Lambda 関数が使用するタスクルートディレクトリにコードをコピーします。このコマンドは環境変数を使用するので、実際のパスを心配しなくて済みます。実行する関数は引数として `CMD [ "app.lambda_handler" ]` コマンドに渡されます。 `COPY requirements.txt` コマンドはコードに必要な依存関係をキャプチャします。  `RUN pip install --user -r requirements.txt` コマンドは、依存関係をローカルユーザーディレクトリにインストールします。  イメージを構築するには、次のコマンドを実行します。 ``` docker build -t . ``` **Amazon ECR にイメージを追加** 次のコードでは、アカウント番号に `aws_account_id` を置き換え、別のリージョンを使用している場合は `us-east-1` を置き換えてください。`buildspec` ファイルは CodeBuild ビルド番号を使用して、イメージバージョンをタグ値として一意に識別します。要件に合わせて変更できます。 buildspec のカスタムコード ``` phases: install: runtime-versions: python: 3.xx pre_build: commands: - python3 --version - pip3 install --upgrade pip - pip3 install --upgrade awscli - sudo docker info build: commands: - echo Build started on `date` - echo Building the Docker image... - ls - cd app - docker build -t cf-demo:$CODEBUILD_BUILD_NUMBER . - docker container ls post_build: commands: - echo Build completed on `date` - echo Pushing the Docker image... - aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.us-east-1.amazonaws.com - docker tag cf-demo:$CODEBUILD_BUILD_NUMBER aws_account_id.dkr.ecr.us-east-1.amazonaws.com/cf-demo:$CODEBUILD_BUILD_NUMBER - docker push aws_account_id.dkr.ecr.us-east-1.amazonaws.com/cf-demo:$CODEBUILD_BUILD_NUMBER ``` # AWS Fargate を使用して Amazon ECS に Java マイクロサービスをデプロイする *Vijay Thompson と Sandeep Bondugula、Amazon Web Services* ## 概要 このパターンは、AWS Fargate を使用して Amazon Elastic Container Service (Amazon ECS) 上にコンテナ化された Java マイクロサービスをデプロイするためのガイダンスを提供します。このパターンでは、コンテナ管理に Amazon Elastic Container Registry (Amazon ECR) は使用せず、代わりに、Docker イメージは Docker ハブからプルされます。 ## 前提条件と制限事項 **前提条件** + Docker ハブにある既存の Java マイクロサービスアプリケーション + パブリック Docker リポジトリ + アクティブな AWS アカウント + Amazon ECS や Fargate などの AWS サービスに精通していること + Docker、Java、Spring Boot フレームワーク + Amazon Relational Database Service (Amazon RDS) が実行中 (オプション) + アプリケーションで Amazon RDS が必要な場合の仮想プライベートクラウド (VPC) (オプション) ## アーキテクチャ **ソーステクノロジースタック** + Java マイクロサービス (たとえば、Spring Boot で実装されたもの) と Docker にデプロイされたもの **ソースアーキテクチャ** ![\[Docker にデプロイされた Java マイクロサービスのソースアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/65185957-2b8b-43a6-964c-95ce0a45ba17/images/0a946ca8-fe37-4ede-85cb-a80a1c36105d.png) **ターゲットテクノロジースタック** + Fargate を使用して各マイクロサービスをホストする Amazon ECS クラスター + Amazon ECS クラスターと関連するセキュリティグループをホストする VPC ネットワーク  + Fargate を使用してコンテナを起動する各マイクロサービスのクラスター/タスク定義 **ターゲットアーキテクチャ** ![\[Amazon ECS の Java マイクロサービスのターゲットアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/65185957-2b8b-43a6-964c-95ce0a45ba17/images/b21349ea-21fc-4688-b76a-1bde479858aa.png) ## ツール **ツール** + [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) では、独自のコンテナオーケストレーションソフトウェアのインストールと運用、仮想マシンのクラスターの管理とスケーリング、またはそれらの仮想マシン上でコンテナをスケジュールする必要がなくなります。  + [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html) を使用すると、サーバーまたは Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを管理しないでコンテナを実行する上で役立ちます。Amazon Elastic Container Service (Amazon ECS) と合わせて使用されます。 + [Docker](https://www.docker.com/) は、アプリケーションをすばやくビルド、テスト、およびデプロイできるソフトウェアプラットフォームです。Docker は、ライブラリ、システムツール、コード、ランタイムなど、ソフトウェアの実行に必要なものがすべて揃った*コンテナ*と呼ばれる標準化されたユニットにソフトウェアをパッケージ化します。  **Docker コード** 次の Dockerfile では、使用する Java 開発キット (JDK) のバージョン、Java アーカイブ (JAR) ファイルが存在する場所、公開されるポート番号、およびアプリケーションのエントリポイントを指定します。 ``` FROM openjdk:11 ADD target/Spring-docker.jar Spring-docker.jar EXPOSE 8080 ENTRYPOINT ["java","-jar","Spring-docker.jar"] ``` ## エピック ### 新しいタスク定義を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | タスク定義を作成します。 | Amazon ECS で Docker コンテナを実行するには、タスク定義が必要です。Amazon ECS コンソール（[https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/)）を開き、[**Task definitions（タスク定義）**] を選択してから、新しいタスク定義を作成します。詳細については、[Amazon ECS ドキュメント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)を参照してください。 | AWS システム管理者、アプリ開発者 | | [起動タイプ] を選択します。 | 起動タイプとして、**[Fargate]** を選択します。 | AWS システム管理者、アプリ開発者 | | タスクを設定します。 | タスク名を定義し、適切な量のタスクメモリと CPU でアプリケーションを設定します。 | AWS システム管理者、アプリ開発者 | | コンテナを定義します。 | コンテナ名を指定します。イメージには、Docker サイト名、リポジトリ名、および Docker イメージのタグ名 (`docker.io/sample-repo/sample-application:sample-tag-name`) を入力します。アプリケーションのメモリ制限を設定し、許可するポートのポートマッピング (`8080, 80`) を設定します。 | AWS システム管理者、アプリ開発者 | | タスクを作成します。 | タスクとコンテナの設定が完了したら、タスクを作成します。詳細な手順については、*[関連リソース]* セクションのリンクを参照してください。 | AWS システム管理者、アプリ開発者 | ### クラスターを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クラスターを作成および設定します。 | クラスタータイプとして **[Networking only（ネットワーキングのみ)]** を選択し、名前を設定してからクラスターを作成、または可能な場合は既存のクラスターを使用します。詳細については、[Amazon ECS ドキュメント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html)を参照してください。 | AWS システム管理者、アプリ開発者 | ### タスクの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | タスクを作成します。 | クラスター内で、**[新しいタスクを実行]** を選択します。 | AWS システム管理者、アプリ開発者 | | [起動タイプ] を選択します。 | 起動タイプとして、**[Fargate]** を選択します。 | AWS システム管理者、アプリ開発者 | | タスク定義、リビジョン、プラットフォームバージョンを選択します。 | 実行するタスク、タスク定義のリビジョン、プラットフォームバージョンを選択します。 | AWS システム管理者、アプリ開発者 | | クラスターを選択します。 | タスクを実行するクラスターを選択します。 | AWS システム管理者、アプリ開発者 | | タスクの数を指定します。 | 実行するタスクの数を設定します。2 つ以上のタスクで起動する場合、タスク間でトラフィックを分散するロードバランサーが必要です。 | AWS システム管理者、アプリ開発者 | | タスクグループを指定します。 | (オプション) 一連の関連するタスクをタスクグループとして特定するタスクグループ名を指定します。 | AWS システム管理者、アプリ開発者 | | クラスター VPC、サブネット、セキュリティグループを設定します。 | アプリケーションをデプロイする、クラスター VPC とサブネットを設定します。セキュリティグループ (HTTP、HTTPS、ポート 8080) を作成または更新して、インバウンド接続とアウトバウンド接続にアクセスします。 | AWS システム管理者、アプリ開発者 | | パブリック IP 設定を設定します。 | Fargate タスクにパブリック IP アドレスを使用するかどうかに応じて、パブリック IP を有効または無効にします。デフォルトの推奨オプションは、**有効**です。 | AWS システム管理者、アプリ開発者 | | 設定を確認してタスクを作成する | 設定を確認してから、**[タスク実行]** を選択します。 | AWS システム管理者、アプリ開発者 | ### カットオーバー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーション URL をコピーします。 | タスクステータスが*実行中*に更新されたら、タスクを選択します。ネットワーキングセクションで、パブリック IP をコピーします。 | AWS システム管理者、アプリ開発者 | | アプリケーションをテストします。 | ブラウザにパブリック IP を入力してアプリケーションをテストします。 | AWS システム管理者、アプリ開発者 | ## 関連リソース + [Amazon ECS 用 Docker の基本](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/docker-basics.html)(Amazon ECS ドキュメント) + [AWS Fargate 上の Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html)(Amazon ECS ドキュメント) + [タスク定義の作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)(Amazon ECS ドキュメント) + [クラスターの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html)(Amazon ECS ドキュメント) + [基本的なサービスパラメータの設定](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/basic-service-params.html)(Amazon ECS ドキュメント) + [ネットワークの設定](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-configure-network.html)(Amazon ECS ドキュメント) + [Amazon ECS への Java マイクロサービスのデプロイ](https://aws.amazon.com/blogs/compute/deploying-java-microservices-on-amazon-ec2-container-service/)(ブログ投稿) # Amazon EKS と Amazon S3 の Helm チャートリポジトリを使用して Kubernetes のリソースとパッケージをデプロイする *Sagar Panigrahi、Amazon Web Services* ## 概要 このパターンは、Kubernetes アプリケーションをその複雑さに関係なく効率的に管理するのに役立ちます。このパターンでは、Helm を既存の継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインに統合して、アプリケーションを Kubernetes クラスターにデプロイします。Helm は Kubernetes アプリケーションの管理に役立つ Kubernetes パッケージマネージャです。Helm チャートは、複雑な Kubernetes アプリケーションの定義、インストール、アップグレードに役立ちます。チャートをバージョン管理して Helm リポジトリに保存できるため、システム停止時の平均復元時間 (MTTR) が短縮されます。  このパターンでは、Kubernetes クラスターに対して Amazon Elastic Kubernetes Service (Amazon EKS) を使用します。Amazon Simple Storage Service (Amazon S3) を Helm チャートリポジトリとして使用しているため、チャートを一元的に管理し、組織全体の開発者がアクセスできます。 ## 前提条件と制限事項 **前提条件** + 仮想プライベートクラウド (VPC) を使用するアクティブな Amazon Web Services (AWS) アカウント + Amazon EKS クラスター  + Amazon EKS クラスター内にセットアップされ、すぐにワークロードを処理できるワーカーノード + クライアントマシンのターゲットクラスターの Amazon EKS kubeconfig ファイルを設定するための Kubectl + バケットにアクセスするための AWS Identity and Access Management (IAM) ロール。 + クライアントマシンから Amazon S3 への IAM (プログラムまたはロール) アクセス + ソースコードの編成、および CI/CD パイプライン **制限事項** + 現時点では、カスタムリソース定義 (CRD) のアップグレード、削除、管理はサポートされていません。 + CRD を参照するリソースを使用している場合は、CRD を別に (図の外に) インストールする必要があります。 **製品バージョン** + Helm v3.6.3 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon EKS + Amazon VPC + Amazon S3 + ソースコードの編成 + Helm + Kubectl **ターゲットアーキテクチャ** ![\[クライアント Helm と Kubectl は、Amazon EKS クラスターの Amazon S3 に Helm チャートリポジトリをデプロイします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/d3f993e6-4d96-4cb9-a075-c4debe431fd7/images/2f09f7bb-440a-4c4b-b29f-08d136d1ada4.png) **自動化とスケール** + AWS CloudFormation を使用すると、インフラストラクチャの作成を自動化できます。詳細については、Amazon EKS ドキュメントの「[AWS CloudFormation を使用して Amazon EKS リソースを作成する](https://docs.aws.amazon.com/eks/latest/userguide/creating-resources-with-cloudformation.html)」を参照してください。 + Helm を既存の CI/CD 自動化ツールに組み込んで、Helm チャートのパッケージ化とバージョニングを自動化します (このパターンの対象外です)。 + GitVersion または Jenkins のビルド番号を使用すると、チャートのバージョニングを自動化できます。 ## ツール **ツール** + [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) – Amazon Elastic Kubernetes Service (Amazon EKS) は、独自の Kubernetes コントロールプレーンを立ち上げたり保守したりする必要がなく、AWS で Kubernetes を実行するためのマネージドサービスです。Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するためのオープンソースシステムです。 + [Helm](https://helm.sh/docs/) – Helm は、Kubernetes クラスター上でアプリケーションをインストールおよび管理するのに役立つ Kubernetes のパッケージマネージャです。 + 「[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)」— Amazon Simple Storage Service (Amazon S3)は、インターネット用のストレージです。Simple Storage Service (Amazon S3) を使用すると、いつでもウェブ上の任意の場所から任意の量のデータを保存および取得できます。 + [Kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) – Kubectl は、Kubernetes クラスターに対してコマンドを実行するためのコマンドラインユーティリティです。 **コード** サンプルコードは添付されています。 ## エピック ### Helm の設定と初期化 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Helm クライアントをインストールする。 | Helm クライアントをローカルシステムにダウンロードしてインストールするには、次のコマンドを実行します。 
sudo curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
| DevOps エンジニア | | Helm のインストールを検証する。 | Helm が Amazon EKS クラスター内の Kubernetes API サーバーと通信できることを検証するには、`helm version` を実行してください。 | DevOps エンジニア | ### Amazon EKS クラスターに Helm チャートを作成してインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | NGINX 用の Helm チャートを作成する。 | クライアントマシンで `my-nginx` と名前を付けた Helm チャートを作成するには、`helm create my-nginx` を実行します。 | DevOps エンジニア | | チャートの構造を確認する。 | グラフの構造を確認するには、ツリーコマンド `tree my-nginx/` を実行します。 | DevOps エンジニア | | チャート内のサービスアカウント作成を無効にする。 | `values.yaml` の `serviceAccount` セクションの下で、`create` キーを `false` に設定します。このパターンではサービスアカウントを作成する必要がないため、これはオフになっています。 | DevOps エンジニア | | 変更したチャートに構文エラーがないか検証 (lint) する。 | ターゲットクラスターにインストールする前に、チャートに構文エラーがないか検証するには、`helm lint my-nginx/` を実行します。 | DevOps エンジニア | | チャートをインストールして Kubernetes リソースをデプロイする。 | Helm チャートのインストールを実行するには、次のコマンドを使用します。 
helm install --name my-nginx-release --debug my-nginx/ --namespace helm-space
オプションの `debug` フラグは、インストール中のすべてのデバッグメッセージを出力します。`namespace` フラグは、このチャートのリソース部分が作成される名前空間を指定します。 | DevOps エンジニア | | Amazon EKS クラスターのリソースを確認する。 | `helm-space` ネームスペースの Helm チャートの一部として作成されたリソースを確認するには、以下のコマンドを使用します。 
kubectl get all -n helm-space
| DevOps エンジニア | ### Kubernetes アプリケーションの以前のバージョンにロールバックします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リリースを変更してアップグレードする。 | チャートを変更するには、`values.yaml` で `replicaCount` 値を `2` に変更します。次に、次のコマンドを実行して、既にインストールされているリリースをアップグレードします。
helm upgrade my-nginx-release my-nginx/ --namespace helm-space
| DevOps エンジニア | | Helm リリースの履歴を確認する。 | Helm を使用してインストールされた特定のリリースのすべてのリビジョンを一覧表示するには、以下のコマンドを実行します。 
helm history my-nginx-release
| DevOps エンジニア | | 特定のリビジョンの詳細を確認する。 | 動作中のバージョンに切り替えたり、ロールバックしたりする前や、リビジョンをインストールする前に追加の検証を行う場合は、次のコマンドを使用して各リビジョンに渡された値を確認してください。
helm get --revision=2 my-nginx-release
| DevOps エンジニア | | 以前のバージョンにロールバックする。 | 以前のバージョンにロールバックするには、次のコマンドを使用します。 
helm rollback my-nginx-release 1
この例では、リビジョン番号 1 にロールバックしています。 | DevOps エンジニア | ### S3 バケットを Helm リポジトリとして初期化する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Helm チャート用の S3 バケットを作成します。　 | 独自の S3 バケットを作成します。バケットに `charts` という名前のフォルダを作成します。このパターンの例では、ターゲットチャートリポジトリとして `s3://my-helm-charts/charts` を使用しています。 | クラウド管理者 | | Amazon S3 Helm プラグインをインストールします。 | helm-s3 プラグインをクライアントマシンにインストールするには、以下のコマンドを使用します。 
helm plugin install https://github.com/hypnoglow/helm-s3.git --version 0.10.0
注: Helm V3 のサポートは、プラグインバージョン 0.9.0 以降で利用できます。 | DevOps エンジニア | | Amazon S3 Helm リポジトリを初期化する。 | ターゲットフォルダを Helm リポジトリとして初期化するには、次のコマンドを使用します。 
helm S3 init s3://my-helm-charts/charts
このコマンドは、ターゲット内に `index.yaml` ファイルを作成して、その場所に保存されているすべてのチャート情報を追跡します。 | DevOps エンジニア | | Amazon S3 リポジトリを Helm に追加する。 | クライアントマシンにリポジトリを追加するには、次のコマンドを使用します。
helm repo add my-helm-charts s3://my-helm-charts/charts
このコマンドは、Helm クライアントマシンのターゲットリポジトリにエイリアスを追加します。 | DevOps エンジニア | | リポジトリリストを確認する。 | Helm クライアントマシン内のリポジトリのリストを表示するには、`helm repo list` を実行します。 | DevOps エンジニア | ### チャートをパッケージ化して Amazon S3 Helm リポジトリに保存する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | チャートをパッケージ化します。 | 作成した `my-nginx` チャートをパッケージ化するには、`helm package ./my-nginx/` を実行します。このコマンドは、`my-nginx` チャートフォルダのすべての内容をアーカイブファイルにパッケージ化します。アーカイブファイルには、`Chart.yaml` ファイルに記載されているバージョン番号を使用して名前が付けられます。 | DevOps エンジニア | | パッケージを Amazon S3 Helm リポジトリに保存する。 | Amazon S3 Helm リポジトリにパッケージをアップロードするには、正しい `.tgz` ファイル名を使用して次のコマンドを実行します。
helm s3 push ./my-nginx-0.1.0.tgz my-helm-charts
| DevOps エンジニア | | Helm チャートを検索する。 | グラフがローカルと Amazon S3 Helm リポジトリの両方に表示されることを確認するには、次のコマンドを実行します。
helm search repo my-nginx
| DevOps エンジニア | ### チャートの修正、バージョン管理、パッケージ化 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | グラフを変更してパッケージ化する。 | `values.yaml` では、`replicaCount` の値を `1` に設定します。次に、`helm package ./my-nginx/` を実行してチャートをパッケージ化します。今度はバージョンを `Chart.yaml` から`0.1.1` に変更します。 バージョニングは、CI/CD パイプライン内の GitVersion や Jenkins のビルド番号などのツールを使用して自動化することで更新するのが理想的です。バージョン番号の自動化は、このパターンの範囲外です。 | DevOps エンジニア | | 新しいバージョンを Amazon S3 Helm リポジトリにプッシュする。 | バージョン 0.1.1 の新しいパッケージを Amazon S3 の `my-helm-charts` Helm リポジトリにプッシュするには、次のコマンドを実行します。
helm s3 push ./my-nginx-0.1.1.tgz my-helm-charts
| DevOps エンジニア | ### Amazon S3 Helm リポジトリからチャートを検索してインストールします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | my-nginx チャートのすべてのバージョンを検索する。 | 使用可能なすべてのバージョンのチャートを表示するには、`--versions` フラグを付けて以下のコマンドを実行します。
helm search repo my-nginx --versions
フラグがない場合、Helm はデフォルトでアップロードされた最新バージョンのチャートを表示します。 | DevOps エンジニア | | Amazon S3 Helm リポジトリからチャートをインストールする。 | 前のタスクの検索結果には、`my-nginx` チャートの複数のバージョンが表示されます。Amazon S3 Helm リポジトリから新しいバージョン (0.1.1) をインストールするには、次のコマンドを使用します。
helm upgrade my-nginx-release my-helm-charts/my-nginx --version 0.1.1 --namespace helm-space
| DevOps エンジニア | ## 関連リソース + 「[psql ドキュメント](https://helm.sh/docs/)」 + [helm-s3 plugin (MIT ライセンス)‎‎‏](https://github.com/hypnoglow/helm-s3.git) + [HELM クライアントバイナリ](https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3) + [Amazon EKS ドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/d3f993e6-4d96-4cb9-a075-c4debe431fd7/attachments/attachment.zip)」 # Terraform を使用して Amazon EKS に CockroachDB クラスターをデプロイする *Sandip Gangapadhyay と Kalyan Senthilnathan、Amazon Web Services* ## 概要 このパターンは、[CockroachDB](https://www.cockroachlabs.com/docs/stable/) [演算子を使用して、Amazon Elastic Kubernetes Service (Amazon EKS) にマルチノード CockroachDB ](https://www.cockroachlabs.com/docs/v25.4/cockroachdb-operator-overview)クラスターをデプロイするための HashiCorp Terraform モジュールを提供します。CockroachDB は、地理的に分散されたクラスター間で自動水平シャーディング、高可用性、一貫したパフォーマンスを提供する分散 SQL データベースです。このパターンでは、Amazon EKS をマネージド Kubernetes プラットフォームとして使用し、TLS で保護されたノード通信用の [cert-manager](https://cert-manager.io/docs/) を実装します。また、トラフィック分散に [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) を使用し、耐障害性とパフォーマンスのためにデータを自動的にレプリケートするポッドを持つ CockroachDB [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) を作成します。 **対象者** このパターンを実装するには、以下について理解しておくことをお勧めします。 + HashiCorp Terraform の概念とコードとしてのインフラストラクチャ (IaC) プラクティス + AWS のサービス、特に Amazon EKS + StatefulSets、サービス設定などの Kubernetes の基本 + 分散 SQL データベース + TLS 証明書管理などのセキュリティの概念。 + DevOps プラクティス、CI/CD ワークフロー、インフラストラクチャの自動化 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + Amazon EKS クラスターにリソースをデプロイするアクセス許可 + ノードにラベルが付けられた Amazon EKS クラスターバージョン v1.23 以降 `node=cockroachdb` + [Amazon EKS クラスターにインストールされた Amazon Elastic Block Store Container Storage Interface (CSI) ドライバー](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)バージョン 1.19.0 以降 + Terraform CLI バージョン 1.0.0 以降、[インストール](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)済み + kubectl、[インストール済み](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) + 「[インストール済み](https://git-scm.com/install/)」Git + AWS Command Line Interface (AWS CLI) バージョン 2.9.18 以降、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み **制限事項** + CockroachDB Kubernetes 演算子は、マルチリージョンデプロイ用の複数の Kubernetes クラスターをサポートしていません。その他の制限については、「[Orchestrate CockroachDB Across Multiple Kubernetes Clusters](https://www.cockroachlabs.com/docs/stable/orchestrate-cockroachdb-with-kubernetes-multi-cluster.html#eks) (CockroachDB ドキュメント）」および[CockroachDB Kubernetes Operator](https://github.com/cockroachdb/cockroach-operator) (GitHub)」を参照してください。 + 永続ボリュームクレーム (PVCs) の自動プルーニングは現在、デフォルトで無効になっています。つまり、ノードを廃止して削除した後、オペレーターはポッドにマウントされた永続ボリュームを削除しません。詳細については、CockroachDB ドキュメントの[「自動 PVC プルーニング](https://www.cockroachlabs.com/docs/stable/scale-cockroachdb-kubernetes.html#automatic-pvc-pruning)」を参照してください。 **製品バージョン** + CockroachDB バージョン 22.2.2 ## アーキテクチャ **ターゲットアーキテクチャ** 次の図は、Virtual Private Cloud (VPC) 内の 3 つの AWS アベイラビリティーゾーンにまたがる高可用性 CockroachDB のデプロイを示しています。CockroachDB ポッドは Amazon EKS を通じて管理されます。このアーキテクチャは、ユーザーが Network Load Balancer を介してデータベースにアクセスする方法を示しています。これにより、トラフィックが CockroachDB ポッドに分散されます。ポッドは各アベイラビリティーゾーンの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行され、耐障害性と耐障害性を提供します。 ![\[VPC 内の 3 つの AWS アベイラビリティーゾーンにまたがる高可用性の CockroachDB デプロイ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e22d81ab-b85c-4709-8579-4c9cdb4afdb6/images/4b163abf-6fdc-4310-840c-bda621ab25dd.png) **作成されたリソース** このパターンで使用される Terraform モジュールをデプロイすると、次のリソースが作成されます。 1. **Network Load Balancer** – このリソースは、クライアントリクエストのエントリポイントとして機能し、CockroachDB インスタンス全体にトラフィックを均等に分散します。 1. **CockroachDB StatefulSet** – StatefulSet は、Amazon EKS クラスター内の CockroachDB デプロイの目的の状態を定義します。CockroachDB ポッドの順序付けられたデプロイ、スケーリング、更新を管理します。 1. **CockroachDB ポッド** – これらのポッドは、Kubernetes ポッド内のコンテナとして実行される CockroachDB のインスタンスです。これらのポッドは、分散クラスター全体のデータを保存および管理します。 1. **CockroachDB データベース** – これは、複数のポッドにまたがる CockroachDB によって管理される分散データベースです。高可用性、耐障害性、パフォーマンスのためにデータをレプリケートします。 ## ツール **AWS のサービス** + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 **その他のツール** + [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースを割り当てて管理するのに役立つ Infrastructure as Code (IaC) ツールです。 + [kubectl](https://kubernetes.io/docs/tasks/tools/)は、Kubernetes クラスターに対してコマンドを実行するためのコマンドラインインターフェイスです。 **コードリポジトリ** このパターンのコードは、GitHub [Deploy a CockroachDB cluster in Amazon EKS using Terraform repository ](https://github.com/aws-samples/crdb-cluster-eks-terraform)で入手できます。コードリポジトリには、Terraform の次のファイルとフォルダが含まれています。 + `modules` folder – このフォルダには、CockroachDB の Terraform モジュールが含まれています。 + `main` folder – このフォルダには、CockroachDB 子モジュールを呼び出して CockroachDB データベースクラスターを作成するルートモジュールが含まれています。 ## ベストプラクティス + 3 つ未満のノードにスケールダウンしないでください。これは CockroachDB のアンチパターンと見なされ、エラーを引き起こす可能性があります。詳細については、CockroachDB ドキュメントの[「クラスタースケーリング](https://www.cockroachlabs.com/docs/stable/scale-cockroachdb-kubernetes.html)」を参照してください。 + Karpernter または Cluster Autoscaler を使用して Amazon EKS Auto Scaling を実装します。これにより、CockroachDB クラスターは水平方向および新しいノードを自動的にスケーリングできます。詳細については、Amazon EKS ドキュメントの「[Karpenter と Cluster Autoscaler を使用したクラスターコンピューティングのスケーリング](https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html)」を参照してください。 **注記** `podAntiAffinity` Kubernetes スケジューリングルールにより、1 つの Amazon EKS ノードでスケジュールできる CockroachDB ポッドは 1 つだけです。 + Amazon EKS セキュリティのベストプラクティスについては、Amazon EKS ドキュメントの[「セキュリティのベストプラクティス](https://docs.aws.amazon.com/eks/latest/best-practices/security.html)」を参照してください。 + CockroachDB の SQL パフォーマンスのベストプラクティスについては、CockroachDB ドキュメントの[「SQL パフォーマンスのベストプラクティス](https://www.cockroachlabs.com/docs/stable/performance-best-practices-overview.html)」を参照してください。 + Terraform 状態ファイルの Amazon Simple Storage Service (Amazon S3) リモートバックエンドの設定の詳細については、Terraform ドキュメントの[Amazon S3](https://developer.hashicorp.com/terraform/language/backend/s3)」を参照してください。 ## エピック ### 環境をセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コードリポジトリを複製します。 | リポジトリのクローンを作成するには、次のコマンドを入力します。
git clone https://github.com/aws-samples/crdb-cluster-eks-terraform.git
| DevOps エンジニア、Git | | Terraform 変数を更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | DevOps エンジニア、Terraform | ### リソースのデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インフラストラクチャを準備します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | DevOps エンジニア、Terraform | ### デプロイメントを確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースの作成を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | DevOps エンジニア | | (オプション) スケールアップまたはスケールダウン。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | DevOps エンジニア、Terraform | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インフラストラクチャを削除します。 | ノードを にスケーリングすると`0`、コンピューティングコストを削減できます。ただし、このモジュールによって作成された永続的な Amazon EBS ボリュームには引き続き料金が発生します。ストレージコストを排除するには、以下の手順に従ってすべてのボリュームを削除します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | Terraform | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | プロバイダー認証情報の検証中にエラーが発生しました。 | Terraform `apply`または `destroy` コマンドを実行すると、次のエラーが発生することがあります。`Error: configuring Terraform AWS Provider: error validating provider  credentials: error calling sts:GetCallerIdentity: operation error STS: GetCallerIdentity, https response error StatusCode: 403, RequestID: 123456a9-fbc1-40ed-b8d8-513d0133ba7f, api error InvalidClientTokenId: The security token included in the request is invalid.`このエラーは、ローカルマシンの設定で使用されている認証情報のセキュリティトークンの有効期限が切れていることが原因です。エラーを解決する方法については、 AWS CLI ドキュメントの[「設定の設定と表示](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-methods)」を参照してください。 | | 保留中状態の CockroachDB ポッド | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | ## 関連リソース + [単一の Kubernetes クラスターに CockroachDB をデプロイする](https://www.cockroachlabs.com/docs/dev/deploy-cockroachdb-with-kubernetes.html) (CockroachDB ドキュメント) + [複数の Kubernetes クラスター間で CockroachDB をオーケストレーションする](https://www.cockroachlabs.com/docs/dev/orchestrate-cockroachdb-with-kubernetes-multi-cluster.html) (CockroachDB ドキュメント) + [AWS プロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Terraform ドキュメント) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/e22d81ab-b85c-4709-8579-4c9cdb4afdb6/attachments/attachment.zip)」 # Amazon EKS にサンプル Java マイクロサービスをデプロイし、Application Load Balancer を使用してマイクロサービスを公開する *Amazon Web Services、Vijay Thompson および Akkamahadevi Hiremath* ## 概要 このパターンでは、`eksctl` コマンドラインユーティリティと Amazon Elastic Container Registry (Amazon ECR) を使用して、サンプル Java マイクロサービスをコンテナ化されたアプリケーションとして Amazon Elastic Kubernetes Service (Amazon EKS) にデプロイする方法を説明します。Application Load Balancer を使用して、アプリケーショントラフィックをロードバランスします。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + macOS、Linux、または Windows にインストールおよび設定されている AWS コマンドラインインターフェイス (AWS CLI) バージョン 1.7 以降 + 実行中の [Docker デーモン](https://docs.docker.com/config/daemon/) + macOS、Linux、または Windows にインストールおよび設定されている `eksctl` コマンドラインユーティリティ (詳細については、Amazon EKS ドキュメントの [Amazon EKS の使用開始 — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) を参照してください。) + macOS、Linux、または Windows にインストールおよび設定されている `kubectl` コマンドラインユーティリティ (詳細については、Amazon EKS ドキュメントの「[kubectl のインストールまたは更新](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)を参照してください。) **制限** + このパターンは、Application Load Balancer の SSL 証明書のインストールには適用されません。 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon ECR + Amazon EKS + エラスティックロードバランシング **ターゲットアーキテクチャ** 次の図は、Amazon EKS で Java マイクロサービスをコンテナ化するアーキテクチャを示しています。 ![\[Amazon EKS にコンテナ化されたアプリケーションとしてデプロイされた Java マイクロサービス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e1dd8ab0-9e1e-4d2b-b7af-89d3e583e57c/images/aaca4fd9-5aaa-4df5-aebd-02a2ed881c3b.png) ## ツール + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、安全、スケーラブル、信頼できるマネージド型のコンテナイメージのレジストリサービスです。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) は、AWS で Kubernetes を実行する際に役立ち、独自の Kubernetes コントロールプレーンまたはノードをインストールまたは維持する必要はありません。 + 「[AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)」は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。 + [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) は、受信トラフィックを複数のアベイラビリティーゾーン(Amazon Elastic Compute Cloud (Amazon EC2)のインスタンス、コンテナ、IP アドレスなど) の複数のターゲットに自動的に配信します。 + [eksctl](https://eksctl.io/) は Amazon EKS にクラスターを作成する上で役立ちます。 + [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) を使用すると、Kubernetes クラスターにコマンドを実行できるようになります。 + [Docker](https://www.docker.com/) は、コンテナと呼ばれるパッケージにアプリケーションをビルド、テスト、配信する上で役立ちます。 ## エピック ### eksctl を使用して Amazon EKS クラスターを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EKS クラスターを作成します。 | 2 つの t2.small Amazon EC2 インスタンスをノードとして使用する Amazon EKS クラスターを作成するには、以下のコマンドを実行します。
eksctl create cluster --name  --version  --nodes=1 --node-type=t2.small
このプロセスには 15～20 分かかる場合があります。クラスターが作成されると、適切な Kubernetes 設定が [kubeconfig](https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html) ファイルに追加されます。`kubeconfig` ファイルを `kubectl`** ** と併用して、後の手順でアプリケーションをデプロイできます。 | 開発者、システム管理者 | | Amazon EKS クラスターを検証します。 | クラスターが作成され、接続できることを確認するには、`kubectl get nodes` コマンドを実行します。 | 開発者、システム管理者 | ### Amazon ECR リポジトリを作成して Docker イメージをプッシュします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECR リポジトリを作成します。 | Amazon ECR ドキュメントの [プライベートリポジトリの作成](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)の指示に従います。 | 開発者、システム管理者 | | POM XML ファイルを作成します。 | このパターンの[追加情報](#deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-additional)セクションの *POM ファイル例*のコードに基づき、`pom.xml` ファイルを作成します。 | 開発者、システム管理者 | | ソースファイルを作成します。 | 次の例に基づいて、`src/main/java/eksExample` パスの `HelloWorld.java` というソースファイルを作成します。
package eksExample;
import static spark.Spark.get;

public class HelloWorld {
    public static void main(String[] args) {
        get("/", (req, res) -> {
            return "Hello World!";
        });
    }
}
以下のディレクトリ構造を使用してください。
├── Dockerfile
├── deployment.yaml
├── ingress.yaml
├── pom.xml
├── service.yaml
└── src
    └── main
        └── java
            └── eksExample
                └── HelloWorld.java
| | | Dockerfile を作成します。 | このパターンの[追加情報](#deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-additional)セクションにある *Dockerfile 例*のコードに基づき、`Dockerfile` を作成します。 | 開発者、システム管理者 | | Docker イメージをビルドおよびプッシュします。 | お使いの `Dockerfile` がイメージをビルド、タグ付け、Amazon ECR にプッシュするディレクトリで、以下のコマンドを実行します。
aws ecr get-login-password --region | docker login --username  --password-stdin .dkr.ecr..amazonaws.com
docker buildx build --platform linux/amd64 -t hello-world-java:v1 .
docker tag hello-world-java:v1 .dkr.ecr..amazonaws.com/:v1
docker push .dkr.ecr..amazonaws.com/:v1
上のコマンドで AWS リージョン、アカウント番号、リポジトリの詳細を変更します。後で使用できるように、画像の URL をメモしておきます。M1 チップを搭載した macOS システムでは、AMD64 プラットフォームで実行中の Amazon EKS と互換性があるイメージの作成に問題があります。この問題を解決するには、[docker buildx](https://docs.docker.com/engine/reference/commandline/buildx/) を使用して Amazon EKS で動作する Docker イメージをビルドします。 | | ### Java マイクロサービスをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイファイルを作成します。 | このパターンの[追加情報](#deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-additional)セクションにある*サンプルデプロイファイル*のコードに基づき、 `deployment.yaml` という YAML ファイルを作成します。先ほどコピーしたイメージの URL を Amazon ECR リポジトリのイメージファイルのパスとして使用します。 | 開発者、システム管理者 | | Java マイクロサービスを Amazon EKS クラスターにデプロイします。 | Amazon EKS クラスターにデプロイを作成するには、`kubectl apply -f deployment.yaml` コマンドを実行します。 | 開発者、システム管理者 | | ポッドのステータスを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer.html) | 開発者、システム管理者 | | サービスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer.html) | 開発者、システム管理者 | | AWS Load Balancer Controller アドオンをインストールします。 | Amazon EKS ドキュメントの [AWS Load Balancer Controller のアドオンのインストール](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html)の指示に従います。Kubernetes サービスの Application Load Balancer または Network Load Balancer を作成するには、アドオンがインストールされている必要があります。 | 開発者、システム管理者 | | Ingress リソースを作成します。 | このパターンの[追加情報](#deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-additional)セクションにある *サンプル Ingress リソースファイル*のコードに基づき、 `ingress.yaml` という YAML ファイルを作成します。 | 開発者、システム管理者 | | Application Load Balancer を作成します。 | Ingress リソースをデプロイしてApplication Load Balancer を作成するには、`kubectl apply -f ingress.yaml` コマンドを実行します。 | 開発者、システム管理者 | ### アプリケーションをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションをテストおよび検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer.html) | 開発者、システム管理者 | ## 関連リソース + [プライベートリポジトリの作成](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)(Amazon ECR ドキュメント) + [Docker イメージのプッシュ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)(Amazon ECR ドキュメント) + [Ingress Controllers](https://www.eksworkshop.com/beginner/130_exposing-service/ingress_controller_alb/)(Amazon EKS ワークショップ) + [Docker Buildx](https://docs.docker.com/engine/reference/commandline/buildx/)(Docker ドキュメント) ## 追加情報 **サンプル POM ファイル** ``` 4.0.0 helloWorld helloWorld 1.0-SNAPSHOT com.sparkjavaspark-core2.0.0 org.apache.maven.pluginsmaven-jar-plugin2.4 eksExample trueeksExample.HelloWorlddependency-jars/ org.apache.maven.pluginsmaven-compiler-plugin3.1 1.81.8 org.apache.maven.pluginsmaven-assembly-plugin attachedpackage eksExample jar-with-dependencies eksExample.HelloWorld ``` **サンプル Dockerfile** ``` FROM bellsoft/liberica-openjdk-alpine-musl:17 RUN apk add maven WORKDIR /code # Prepare by downloading dependencies ADD pom.xml /code/pom.xml RUN ["mvn", "dependency:resolve"] RUN ["mvn", "verify"] # Adding source, compile and package into a fat jar ADD src /code/src RUN ["mvn", "package"] EXPOSE 4567 CMD ["java", "-jar", "target/eksExample-jar-with-dependencies.jar"] ``` **サンプルデプロイファイル** ``` apiVersion: apps/v1 kind: Deployment metadata: name: microservice-deployment spec: replicas: 2 selector: matchLabels: app.kubernetes.io/name: java-microservice template: metadata: labels: app.kubernetes.io/name: java-microservice spec: containers: - name: java-microservice-container image: .dkr.ecr.amazonaws.com/: ports: - containerPort: 4567 ``` **サンプルサービスファイル** ``` apiVersion: v1 kind: Service metadata: name: "service-java-microservice" spec: ports: - port: 80 targetPort: 4567 protocol: TCP type: NodePort selector: app.kubernetes.io/name: java-microservice ``` **サンプル Ingress リソースファイル** ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: "java-microservice-ingress" annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/load-balancer-name: apg2 alb.ingress.kubernetes.io/target-type: ip labels: app: java-microservice spec: rules: - http: paths: - path: / pathType: Prefix backend: service: name: "service-java-microservice" port: number: 80 ``` # gRPC ベースのアプリケーションを Amazon EKS クラスターにデプロイし、Application Load Balancer でアクセスする *Amazon Web Services、Kirankumar Chandrashekar、Huy Nguyen* ## 概要 このパターンでは、gRPC ベースのアプリケーションを Amazon Elastic Kubernetes Service (Amazon EKS) クラスターでホストし、Application Load Balancer を介して安全にアクセスする方法を説明します。 「[gRPC](https://grpc.io/)」は、任意の環境で実行できるオープンソースのリモートプロシージャコール (RPC) フレームワークです。マイクロサービスの統合やクライアントとサーバーの通信に使用できます。gRPC の詳細については、AWS ブログのポスト「[Application Load Balancer support for end-to-end HTTP/2 and gRPC](https://aws.amazon.com/blogs/aws/new-application-load-balancer-support-for-end-to-end-http-2-and-grpc/)」を参照してください。 このパターンは、Amazon EKS で Kubernetes ポッドとして実行される gRPC ベースアプリケーションの実行環境を提供する方法を示しています。gRPC クライアントは、SSL/TLS 暗号化接続を使用して、HTTP/2 プロトコルを介して Application Load Balancer に接続します。Application Load Balancer は、Amazon EKS ポッドで実行される gRPC アプリケーションにトラフィックを転送します。gRPC ポッドの数は、「[Kubernetes 水平ポッドオートスケーラー](https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html)」 を使用してトラフィックに基づいて自動的にスケーリングできます。Application Load Balancer のターゲットグループは Amazon EKS ノードのヘルスチェックを行い、ターゲットが正常かどうかを評価して、正常なノードにのみトラフィックを転送します。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + [Docker](https://www.docker.com/)、Linux、macOS、または Windows にインストールして設定します。 + Linux、macOS または Windows にインストールして設定されている「[AWS Command Line Interface (AWS CLI) バージョン 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)」。 + Linux、macOS、または Windows にインストールして設定されている [eksctl](https://github.com/eksctl-io/eksctl#installation)。 + `kubectl`、Amazon EKS クラスターのリソースにアクセスするようにインストールおよび設定されています。詳細については、「Amazon EKS ドキュメント」の「[kubectl のインストールまたは更新](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」を参照してください。  + 「[GrpCurl](https://github.com/fullstorydev/grpcurl)」、インストールおよび設定。 + 新規もしくは既存の Amazon EKS クラスター。詳細については、「[Amazon EKS を使い始める](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)」を参照してください。 + Amazon EKS クラスターにアクセスするように設定されたコンピュータのターミナル。詳細については、「Amazon EKS ドキュメント」の「[クラスターと通信するようにコンピュータを設定する](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html#eks-configure-kubectl)」を参照してください。 + Amazon EKS クラスターにプロビジョニングされた「[AWS Load Balancer Controller](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html)」 + 有効な SSL または SSL/TLS 証明書を持つ既存の DNS ホスト名。AWS Certificate Manager (ACM) を使用するか、既存の証明書を ACM にアップロードすることで、ドメインの証明書を取得できます。この 2 つのオプションの詳細については、ACM ドキュメントの 「[パブリック証明書のリクエスト](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html)」 と 「[AWS 認定 Manager への証明書のインポート](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html)」 を参照してください。 ## アーキテクチャ 次の図に、このパターンが構築するアーキテクチャを示します。 ![\[Amazon EKS での gRPC ベースアプリケーションのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/abf727c1-ff8b-43a7-923f-bce825d1b459/images/281936fa-bc43-4b4e-a343-ba1eab97df38.png) 次の図は、SSL/TLS トラフィックを gRPC クライアントから受信し、Application Load Balancer にオフロードするワークフローを示しています。トラフィックは仮想プライベートクラウド (VPC) から送信されるため、gRPC サーバーにはプレーンテキストで転送されます。 ![\[SSL/TLS トラフィックを gRPC サーバーに送信するワークフロー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/abf727c1-ff8b-43a7-923f-bce825d1b459/images/09e0c3f6-0c39-40b7-908f-8c4c693a5f02.png) ## ツール **AWS サービス** + [AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) はオープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。 + 受信したアプリケーションまたはネットワークトラフィックを複数のターゲットに分散するには、[Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) を使用します。例えば、1 つまたは複数のアベイラビリティーゾーンの Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、および IP アドレスにトラフィックを分散できます。 + 「[Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)」 は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。  + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) は、 で Kubernetes を実行する際に役立ちます。独自の Kubernetes コントロールプレーンまたはノードをインストールおよび維持する必要はありません。  **ツール** + [eksctl](https://eksctl.io/) は、Amazon EKS 上にクラスターを作成するためのシンプルな CLI ツールです。 + 「[kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)」は、 Kubernetes クラスターに対してコマンドを実行するためのコマンドラインユーティリティです。 + [AWS Load Balancer Controller](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html)は、Kubernetes クラスターの AWS Elastic Load Balancers の管理を支援します。 + 「[GrpCurl](https://github.com/fullstorydev/grpcurl)」 は gRPC サービスとのやり取りを支援するコマンドラインツールです。 **コードリポジトリ** このパターンのコードは、GitHub 「[grpc-traffic-on-alb-to-eks](https://github.com/aws-samples/grpc-traffic-on-alb-to-eks.git)」リポジトリで入手可能です。 ## エピック ### gRPC サーバーの Docker イメージをビルドして Amazon ECR にプッシュします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECR リポジトリを作成します。 | AWS マネジメントコンソールにサインインし、[Amazon ECR コンソール](https://console.aws.amazon.com/ecr/)を開いて、Amazon ECR リポジトリを作成します。詳細については、「Amazon ECR ドキュメント」の「[リポジトリの作成](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)」を参照してください。Amazon ECR リポジトリの URL を必ず記録してください。次のコマンドを実行して、AWS CLI で Amazon ECR リポジトリを作成することもできます。
aws ecr create-repository --repository-name helloworld-grpc
| クラウド管理者 | | Docker イメージを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.html) | DevOps エンジニア | | Amazon ECR にDocker イメージをプッシュします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.html) | DevOps エンジニア | ### Kubernetes マニフェストを Amazon EKS クラスターにデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Kubernetes マニフェストファイルの値を変更します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.html) | DevOps エンジニア | | Kubernetes マニフェストファイルをデプロイします。 | 次の `kubectl` コマンドを実行して `grpc-sample.yaml` ファイルを Amazon EKS クラスターに展開します。 
kubectl apply -f ./kubernetes/grpc-sample.yaml
| DevOps エンジニア | ### Application Load Balancerの FQDN の DNS レコードを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Application Load Balancerの FQDN を記録します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.html) | DevOps エンジニア | ### ソリューションをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | gRPC サーバーをテストします。 | GrpCurl を使用して次のコマンドを実行して、エンドポイントをテストします。
grpcurl grpc.example.com:443 list 
grpc.reflection.v1alpha.ServerReflection
helloworld.helloworld
`grpc.example.com` を DNS 名に置き換えます。 | DevOps エンジニア | | gRPC クライアントを使用して gRPC サーバーをテストします。 | `helloworld_client_ssl.py` サンプル gRPC クライアントで、`grpc.example.com` のホスト名を gRPC サーバーに使用されているホスト名に置き換えます。 次のコードサンプルは、クライアントのリクエストに対する gRPC サーバーからの応答を示しています。
python ./app/helloworld_client_ssl.py
message: "Hello to gRPC server from Client"

message: "Thanks for talking to gRPC server!! Welcome to hello world. Received message is \"Hello to gRPC server from Client\""
received: true
これは、クライアントがサーバーと通信でき、接続が成功したことを示しています。 | DevOps エンジニア | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DNS レコードを削除する。 | 前に作成した Application Load Balancer の FQDN を指す DNS レコードを削除します。 | クラウド管理者 | | ロードバランサーを削除する。 | [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)で、**[ロードバランサー]** を選択し、Kubernetes コントローラーが Ingress リソース用に作成したロードバランサーを削除します。 | クラウド管理者 | | Amazon EKS クラスターを削除する。 | `eksctl` を使用して Amazon EKS クラスターを削除します。
eksctl delete cluster -f ./eks.yaml
| AWS DevOps | ## 関連リソース + 「[Amazon EKS でのネットワーク負荷分散](https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html)」 + 「[Application Load Balancer のターゲットグループ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#target-group-protocol-version)」 ## 追加情報 サンプル入力リソース: ``` --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/healthcheck-protocol: HTTP alb.ingress.kubernetes.io/ssl-redirect: "443" alb.ingress.kubernetes.io/backend-protocol-version: "GRPC" alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]' alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:::certificate/ labels: app: grpcserver environment: dev name: grpcserver namespace: grpcserver spec: ingressClassName: alb rules: - host: grpc.example.com # <----- replace this as per your host name for which the SSL certtficate is available in ACM http: paths: - backend: service: name: grpcserver port: number: 9000 path: / pathType: Prefix ``` サンプルデプロイリソース: ``` apiVersion: apps/v1 kind: Deployment metadata: name: grpcserver namespace: grpcserver spec: selector: matchLabels: app: grpcserver replicas: 1 template: metadata: labels: app: grpcserver spec: containers: - name: grpc-demo image: .dkr.ecr.us-east-1.amazonaws.com/helloworld-grpc:1.0 #<------- Change to the URI that the Docker image is pushed to imagePullPolicy: Always ports: - name: grpc-api containerPort: 9000 env: - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP restartPolicy: Always ``` **サンプル出力**: ``` NAME CLASS HOSTS Address PORTS AGE grpcserver 80 27d ``` # Docker コンテナとして AWS IoT Greengrass V2 実行されている にコンテナ化されたアプリケーションをデプロイする *Salih Bakir、Giuseppe Di Bella、Gustav Svalander、Amazon Web Services* ## 概要 AWS IoT Greengrass Version 2は、Docker コンテナとしてデプロイされた場合、Docker アプリケーションコンテナの実行をネイティブにサポートしていません。このパターンは、Docker-in-Docker (DinD) 機能 AWS IoT Greengrass V2 を有効にする の最新バージョンに基づいてカスタムコンテナイメージを作成する方法を示しています。DinD を使用すると、 AWS IoT Greengrass V2 環境内でコンテナ化されたアプリケーションを実行できます。 このパターンは、スタンドアロンソリューションとしてデプロイすることも、Amazon ECS Anywhere などのコンテナオーケストレーションプラットフォームと統合することもできます。どちらのデプロイモデルでも、スケーラブルなコンテナベースのデプロイを有効にしながら、 AWS IoT SiteWise エッジ処理機能を含む完全な AWS IoT Greengrass V2 機能を維持します。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + 一般的な AWS IoT Greengrass Version 2 前提条件については、 AWS IoT Greengrass Version 2 ドキュメントの[「前提条件](https://docs.aws.amazon.com/greengrass/v2/developerguide/getting-started-prerequisites.html)」を参照してください。 + Linux、macOS、または Windows にインストールおよび設定された Docker エンジン。 + Docker Compose (Docker Compose コマンドラインインターフェイス (CLI) を使用して Docker イメージを実行する場合）。 + Linux オペレーティングシステム。 + 仮想化をサポートするホストサーバーを持つハイパーバイザー。 + システム要件: + 2 GB の RAM (最小) + 使用可能なディスク容量 5 GB (最小) + AWS IoT SiteWise Edge の場合、16 GB の RAM と 50 GB の使用可能なディスク容量を備えた x86\$164 クアッドコア CPU。 AWS IoT SiteWise データ処理の詳細については、 AWS IoT SiteWise ドキュメントの[「データ処理パックの要件](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/configure-gateway-ggv2.html#w2aac17c19c13b7)」を参照してください。 **製品バージョン** + AWS IoT Greengrass Version 2 バージョン 2.5.3 以降 + Docker-in-Docker バージョン 1.0.0 以降 + Docker Compose バージョン 1.22 以降 + Docker エンジンバージョン 20.10.12 以降 **制限事項** + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択してください。 ## アーキテクチャ **ターゲットテクノロジースタック** + **データソース** – 処理用のデータを生成する IoT デバイス、センサー、または産業機器 + **AWS IoT Greengrass V2** – エッジインフラストラクチャにデプロイされた D-in-D 機能を備えた Docker コンテナとしての実行 + **コンテナ化されたアプリケーション** – ネストされた Docker コンテナとして AWS IoT Greengrass V2 環境内で実行されるカスタムアプリケーション + **(オプション) Amazon ECS Anywhere** – コンテナのデプロイを管理する AWS IoT Greengrass V2 コンテナオーケストレーション + **その他 AWS のサービス** – AWS IoT Core AWS IoT SiteWiseデータ処理と管理 AWS のサービス のための など **ターゲットアーキテクチャ** 次の図は、コンテナ管理ツールである Amazon ECS Anywhere を使用するターゲットデプロイアーキテクチャの例を示しています。 ![\[Amazon ECS Anywhere を使用したデプロイアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/2ecf5354-40e0-4fd9-9798-086719059784/images/5ed2652e-9604-4809-8962-b167e1991658.png) この図表は、次のワークフローを示しています: **1: コンテナイメージストレージ** – Amazon ECR は、エッジ処理に必要な AWS IoT Greengrass コンテナイメージとカスタムアプリケーションコンテナを保存します。 **2 **および** 3: コンテナのデプロイ** – Amazon ECS Anywhere は AWS IoT Greengrass 、コンテナイメージを Amazon ECR からエッジロケーションにデプロイし、コンテナのライフサイクルとデプロイプロセスを管理します。 **4: コンポーネントのデプロイ** — デプロイされた AWS IoT Greengrass コアは、設定に基づいて関連するコンポーネントを自動的にデプロイします。コンポーネントには、コンテナ化された環境内の AWS IoT SiteWise Edge やその他の必要なエッジ処理コンポーネントが含まれます。 **5: データインジェスト** – 完全に設定されると、 はエッジロケーションのさまざまな IoT データソースからのテレメトリデータとセンサーデータの取り込み AWS IoT Greengrass を開始します。 **6: データ処理とクラウド統合** – コンテナ化された AWS IoT Greengrass コアは、デプロイされたコンポーネント (産業用データの AWS IoT SiteWise Edge を含む) を使用してデータをローカルで処理します。次に、処理されたデータを AWS クラウド サービスに送信して、さらなる分析と保存を行います。 ## ツール **AWS のサービス** + [Amazon ECS Anywhere](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch-type-external.html) は、Amazon ECS タスクとサービスを独自のインフラストラクチャにデプロイ、使用、管理する際に役立ちます。 + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 + [AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/what-is-iot-greengrass.html) は、デバイス上で IoT アプリケーションを構築、デプロイ、管理するのに役立つオープンソースの IoT エッジランタイムおよびクラウドサービスです。 + [AWS IoT SiteWise](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/what-is-sitewise.html) は、産業用機器からデータを大規模に収集、モデル化、分析、視覚化するのに役立ちます。 **その他のツール** + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしての Platform as a Service (PaaS) 製品のセットです。 + [Docker Compose](https://docs.docker.com/compose/) は、マルチコンテナアプリケーションを定義および実行するためのツールです。 + [Docker Engine](https://docs.docker.com/engine/) は、アプリケーションを構築およびコンテナ化するためのオープンソースのコンテナ化テクノロジーです。 **コードリポジトリ** このパターンのコードは、GitHub [AWS IoT Greengrass v2 Docker-in-Docker ](https://github.com/aws-samples/aws-iot-greengrass-docker-in-docker)リポジトリで入手できます。 ## エピック ### AWS IoT Greengrass V2 Docker-in-Docker イメージを構築する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クローンを作成してリポジトリに移動します。 | リポジトリのクローンを作成するには、次のコマンドを使用します。`git clone https://github.com/aws-samples/aws-iot-greengrass-v2-docker-in-docker.git``docker` ディレクトリに移動するには、次のコマンドを使用します。`cd aws-iot-greengrass-v2-docker-in-docker/docker` | DevOps エンジニア、AWS DevOps | | Docker イメージを作成します。 | デフォルト (最新) バージョンで Docker イメージを構築するには、次のコマンドを実行します。`docker build -t x86_64/aws-iot-greengrass:latest .`または、特定のバージョンで Docker イメージを構築するには、次のコマンドを実行します。`docker build --build-arg GREENGRASS_RELEASE_VERSION=2.12.0 -t x86_64/aws-iot-greengrass:2.12.0 .`ビルドを確認するには、次のコマンドを実行します。`docker images \| grep aws-iot-greengrass`  | AWS DevOps、DevOps エンジニア | | (オプション) Amazon ECR にプッシュします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | アプリ開発者、AWS DevOps、DevOps エンジニア | ### AWS 認証情報を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 認証方法を選択します。 | 以下のオプションのいずれかを選択してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | AWS 管理者 | | 認証方法を設定します。 | 選択した認証方法では、次の設定ガイダンスを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | AWS 管理者 | ### Docker Compose で を実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `docker-compose.yml` を設定します。 | 次のように、 `docker-compose.yml` ファイルを環境変数で更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | DevOps エンジニア | | コンテナを起動して検証します。 | フォアグラウンドで を開始するには、次のコマンドを実行します。`docker-compose up --build`または、バックグラウンドで開始するには、次のコマンドを実行します。`docker-compose up --build -d`ステータスを確認するには、次のコマンドを実行します。`docker-compose ps`ログをモニタリングするには、次のコマンドを実行します。`docker-compose logs -f` | DevOps エンジニア | ### Docker CLI で を実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Docker CLI でコンテナを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | DevOps エンジニア | | コンテナを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | DevOps エンジニア | ### コンテナ化されたアプリケーションの管理 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | アプリ開発者 | | Docker-in-Docker にアクセスしてテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | DevOps エンジニア | ### (オプション) Amazon ECS Anywhere との統合 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECS クラスターをセットアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | AWS 管理者 | | Amazon ECS タスクをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | AWS 管理者 | ### 停止とクリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コンテナを停止します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | コンテナはアクセス許可エラーで開始できません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)`--privileged` は、コンテナに拡張された権限を付与します。 | | プロビジョニングは認証情報エラーで失敗します。 | 認証情報が正しく設定されていることを確認するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)IAM アクセス許可に `iot:CreateThing`、`iot:CreatePolicy`、、`iot:AttachPolicy``iam:CreateRole`、 が含まれていることを確認します`iam:AttachRolePolicy`。 | | コンテナ内の Docker デーモンに接続できません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | | コンテナのディスク容量が不足しています。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)最小ディスク容量を確保する: 基本オペレーションの場合は 5 GB、 AWS IoT SiteWise Edge の場合は 50 GB | | ビルドの問題。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | | ネットワーク接続の問題。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)ファイアウォールがアウトバウンド HTTPS (443) および MQTT (8883) トラフィックを許可していることを確認します。 | | Greengrass コンポーネントはデプロイに失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)`/greengrass/v2/logs/` ディレクトリのコンポーネント固有のログを確認します。 | | コンテナは起動直後に終了します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)の場合、必要なすべての環境変数が正しく設定されていることを確認します`PROVISION=true`。コンテナの起動時に `--init`フラグが使用されていることを確認します。 | ## 関連リソース **AWS リソース** + [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) + [AWS IoT SiteWise モデルとアセットのエッジデータ処理を設定する](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/edge-processing.html) + [とは AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/what-is-iot-greengrass.html) **その他のリソース** + [Docker ドキュメント](https://docs.docker.com/) ## 追加情報 + AWS IoT SiteWise Edge データ処理の場合、Docker は AWS IoT Greengrass 環境内で利用できる必要があります。 + ネストされたコンテナを実行するには、管理者レベルの認証情報を使用して AWS IoT Greengrass コンテナを実行する必要があります。 # Elastic Beanstalk を使用してコンテナをデプロイする *Amazon Web Services、Thomas Scott および Jean-Baptiste Guillois* ## 概要 Amazon Web Services (AWS) クラウドでは、AWS Elastic Beanstalk が Docker を利用可能なプラットフォームとしてサポートしているため、作成した環境でコンテナを実行できます。このパターンは、Elastic Beanstalk サービスを使用してコンテナをデプロイする方法を示しています。このパターンのデプロイでは、Docker プラットフォームベースのウェブサーバー環境が使用されます。 ウェブアプリケーションやサービスをデプロイ、スケーリングするために Elastic Beanstalk を使用する場合、コードをアップロードすると、デプロイが自動的に処理されます。キャパシティのプロビジョニング、ロードバランシング、自動スケーリング、アプリケーションのヘルスモニタリングも含まれます。Elastic Beanstalk を使用すると、ユーザーに代わって作成される AWS リソースを完全に制御できます。Elastic Beanstalk に対する追加料金はありません。アプリケーションを保存し、実行するための AWS リソースに料金を支払うだけです。 このパターンには、[AWS Elastic Beanstalk コマンドラインインターフェイス (EB CLI)](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install-advanced.html) と AWS マネジメントコンソールを使用したデプロイ手順が含まれています。 **ユースケース** 以下に、Elastic Beanstalk ラベルの一般的なユースケースを示します。  + プロトタイプ環境をデプロイして、フロントエンドアプリケーションのデモを行います。(このパターンでは Dockerfile** **を例として使用しています)。 + API をデプロイして、特定のドメインの API リクエストを処理します。 + Docker-Compose を使用して、オーケストレーションソリューションをデプロイします(このモードでは、`docker-compose.yml`** **は実際の例として使用されません)。 ## 前提条件と制限事項 **前提条件** + AWS アカウント + AWS EB CLI がローカルにインストールされています + Docker がローカルマシンにインストールされています **機能制限** + 無料プランでは、Docker のプル制限は IP アドレスごとに 6 時間あたり 100 回までです。 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon Elastic Compute Cloud (Amazon EC2) インスタンス + セキュリティグループ + Application Load Balancer + Auto Scaling グループ **ターゲットアーキテクチャ** ![\[Elastic Beanstalk でコンテナをデプロイするためのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/dfabcdc2-747f-40e2-a603-08ea31ba71d3/images/1d17ff09-1aea-4c72-adb5-eaf741601428.png) **自動化とスケール** AWS Elastic Beanstalk は、リクエストの数に基づいて自動的にスケールします。環境枠用に作成された AWS リソースには、Application Load Balancer、Auto Scaling グループ、1 つ以上の Amazon EC2 インスタンスが含まれます。  ロードバランサーは、Auto Scaling グループに属する Amazon EC2 インスタンスの前に配置されています Amazon EC2 Auto Scaling は、アプリケーションへの負荷の増大に対応するために追加の Amazon EC2 インスタンスを自動的に開始します。アプリケーションへの負荷が軽減されると、Amazon EC2 Auto Scaling はインスタンスを停止しますが、少なくとも 1 つのインスタンスは引き続き実行されます。 **自動スケーリングトリガー** Elastic Beanstalk 環境の Auto Scaling グループは、2 つの Amazon CloudWatch アラームを使用してスケーリングオペレーションを開始します。各インスタンスの 5 分間の平均アウトバウンドネットワークトラフィックが 6 MB 以上または 2 MB 以下の場合は、デフォルトのトリガーがスケーリングされます。Amazon EC2 Auto Scaling を効率的に使用するには、アプリケーション、インスタンスタイプ、サービス要件に合ったトリガーを設定します。レイテンシー、ディスク I/O、CPU 使用率、リクエスト数などの複数の統計に基づいて、スケールすることができます。詳細については、「[自動スケーリングトリガー](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-autoscaling-triggers.html)」を参照してください。 ## ツール **AWS サービス** + 「[AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)」は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。 + 「[AWS EB コマンドラインインターフェイス (EB CLI)](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install.html)」は、Elastic Beanstalk 環境の作成、設定、管理に使用できるコマンドラインクライアントです。 + 受信したアプリケーションまたはネットワークトラフィックを複数のターゲットに分散するには、[Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) を使用します。例えば、1 つまたは複数のアベイラビリティーゾーンの Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、および IP アドレスにトラフィックを分散できます。 **その他のサービス** + [Docker](https://www.docker.com/) は、ライブラリ、システムツール、コード、ランタイムを含むコンテナと呼ばれる、標準化されたユニットにソフトウェアをパッケージ化します。 **コード** このパターンのコードは、GitHub 内の「[クラスターサンプルアプリケーション](https://github.com/aws-samples/cluster-sample-app)」リポジトリで利用できます。 ## エピック ### Dockerfile で構築する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リモートリポジトリをクローンを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containers-by-using-elastic-beanstalk.html) | アプリ開発者、AWS 管理者、AWS DevOps | | Elastic Beanstalk Docker プロジェクトを初期化します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containers-by-using-elastic-beanstalk.html) | アプリ開発者、AWS 管理者、AWS DevOps | | プロジェクトをローカルでテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containers-by-using-elastic-beanstalk.html) | アプリ開発者、AWS 管理者、AWS DevOps | ### EB CLI を使用してデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイコマンドの実行 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containers-by-using-elastic-beanstalk.html) | アプリ開発者、AWS 管理者、AWS DevOps | | デプロイされたバージョンにアクセスします。 | デプロイコマンドの終了後、`eb open` コマンドを使用してプロジェクトにアクセスします。 | アプリ開発者、AWS 管理者、AWS DevOps | ### コンソールを使用してデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ブラウザを使用してアプリケーションをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-containers-by-using-elastic-beanstalk.html) | アプリ開発者、AWS 管理者、AWS DevOps | | デプロイされたバージョンにアクセスします。 | デプロイ後、デプロイされたアプリケーションにアクセスし、表示された URL を選択します。 | アプリ開発者、AWS 管理者、AWS DevOps | ## 関連リソース + 「[ウェブサーバー環境](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-webserver.html)」 + 「[macOS で EB CLI をインストール](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install-osx.html)」 + 「[EB CLI の手動インストール](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install-advanced.html)」 ## 追加情報 **Elastic Beanstalk を使用するメリット** + インフラストラクチャの自動プロビジョニング + 基盤となるプラットフォームの自動管理 + アプリケーションをサポートするための自動パッチ適用とアップデート + アプリケーションの自動スケーリング + ノード数のカスタマイズが可能 + 必要に応じて、インフラストラクチャーコンポーネントにアクセス可能 + 他のコンテナデプロイのソリューションよりもデプロイが簡単 # Lambda 関数、Amazon VPC、およびサーバーレスアーキテクチャを使用して静的アウトバウンド IP アドレスを生成する *Thomas Scott、Amazon Web Services* ## 概要 このパターンでは、サーバーレスアーキテクチャを使用して、Amazon Web Services (AWS) クラウドで静的アウトバウンド IP アドレスを生成する方法を説明します。組織がセキュアファイル転送プロトコル (SFTP) を使用して別の事業体にファイルを送信したい場合、この方法を利用することができる。つまり、事業体は、ファイアウォールを通過するファイルを許可する IP アドレスにアクセスできる必要があります。  このパターンのアプローチは、「[Elastic IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)」をアウトバウンド IP アドレスとして使用する AWS Lambda 関数を作成するのに役立ちます。このパターンの手順に従うことで、Lambda 関数と、静的 IP アドレスを持つインターネットゲートウェイ経由でアウトバウンドトラフィックをルーティングする仮想プライベートクラウド (VPC) を作成できます。静的 IP アドレスを使用するには、Lambda 関数を VPC とそのサブネットにアタッチします。  ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。  + AWS Identity and Access Management (IAM) アクセス権限で、Lambda 関数の作成とデプロイ、VPC とそのサブネットの作成が可能です。詳細については、AWS Lambda ドキュメントの「[実行ロールとユーザー権限](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-permissions)」を参照してください。 + infrastructure as code (IaC) を使用してこのパターンのアプローチを実装する予定であれば、AWS Cloud9 のような統合開発環境 (IDE) が必要です。詳細については、AWS Cloud9 ドキュメントにある「[AWS Cloud9 とは?](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)」を参照してください。 ## アーキテクチャ このパターンのサーバーレスアーキテクチャを次の図に示します。 ![\[AWS クラウド VPC architecture with two availability zones, public and private subnets, NAT gateways, and a Lambda function.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eb1d0b05-df33-45ae-b27e-36090055b300/images/c15cc6da-ce4e-4ea0-9feb-de1c845d3ce8.png) この図表は、次のワークフローを示しています: 1. アウトバウンドトラフィックは `NAT gateway 1` の `Public subnet 1` から離れます。 1. アウトバウンドトラフィックは `NAT gateway 2` の `Public subnet 2` から離れます。 1. Lambda 関数は `Private subnet 1` または `Private subnet 2` で実行できます。 1. `Private subnet 1` と `Private subnet 2` はパブリックサブネットの NAT ゲートウェイにトラフィックをルーティングします。 1. NAT ゲートウェイは、パブリックサブネットからインターネットゲートウェイにアウトバウンドトラフィックを送信します。 1. アウトバウンドデータは、インターネットゲートウェイから外部サーバーに転送されます。 テクノロジースタック + Lambda + Amazon Virtual Private Cloud (Amazon VPC)   **自動化とスケール** 異なるアベイラビリティーゾーンにある 2 つのパブリックサブネットと 2 つのプライベートサブネットを使用することで、高可用性 (HA) を確保できます。1 つのアベイラビリティーゾーンが利用できなくなっても、パターンのソリューションは引き続き機能します。 ## ツール + 「[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」 – AWS Lambda はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。課金は実際に消費したコンピューティング時間に対してのみ発生します。コードが実行されていない場合、料金は発生しません。 + 「[Amazon VPC](https://docs.aws.amazon.com/vpc/)」— Amazon Virtual Private Cloud (Amazon VPC) では、AWS クラウドの論理的に隔離されたセクションをプロビジョニングすることで、ユーザーが定義した仮想ネットワーク内で AWS リソースを起動できます。仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークによく似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。 ## エピック ### VPC を新規作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 新しい VPC を作成します。 | AWS マネジメントコンソールにサインインし、Amazon VPC コンソールを開いて、`10.0.0.0/25`** **を IPv4 CIDR 範囲とする `Lambda VPC` という名前の VPC を作成します。VPC の作成に関する詳細は、Amazon VPC ドキュメントの「[Amazon VPC の使用開始](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html#getting-started-create-vpc)」を参照してください。  | AWS 管理者 | ### 2 つのパブリックサブネットを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 最初のパブリックサブネットを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | | 2 番目のパブリックサブネットを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | ### プライベートサブネットを 2 つ作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 最初のプライベートサブネットを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | | 2 番目のプライベートサブネットを作成する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | ### NAT ゲートウェイ用に 2 つの Elastic IP アドレス作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 最初の Elastic IP アドレスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html)この Elastic IP アドレスは、最初の NAT ゲートウェイに使用されます。  | AWS 管理者 | | 2 番目の Elastic IP アドレスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html)この Elastic IP アドレスは 2 番目の NAT ゲートウェイに使用されます。 | AWS 管理者 | ### インターネットゲートウェイを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インターネットゲートウェイを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | | インターネットゲートウェイを VPC にアタッチします。 | 作成したインターネットゲートウェイを選択して、[**アクション]、[VPC にアタッチ**] を選択します。 | AWS 管理者 | ### NAT ゲートウェイを 2 つ作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 最初の NAT ゲートウェイを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | | 2 番目の NAT ゲートウェイを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | ### パブリックサブネットとプライベートサブネットのルートテーブルを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | パブリックワンサブネット用のルートテーブルを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | | パブリック2 サブネットのルートテーブルを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | | プライベートワンサブネットのルートテーブルを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | | プライベートツーサブネットのルートテーブルを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | ### Lambda 関数を作成し、VPC に追加して、ソリューションをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 新しい Lambda 関数の作成 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | | Lambda 関数 を VPC に追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | | 外部サービスを呼び出すコードを記述します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 管理者 | ## 関連リソース + [VPC 内のリソースにアクセスするように Lambda 関数を設定する](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html) # Amazon ECR リポジトリに移行するときに、重複するコンテナイメージを自動的に識別する *Amazon Web Services、Rishabh Yadav と Rwest Singla* ## 概要 このパターンでは、異なるコンテナリポジトリに保存されているイメージが重複しているかどうかを識別するための自動化されたソリューションを提供します。このチェックは、他のコンテナリポジトリから Amazon Elastic Container Registry (Amazon ECR) にイメージを移行する場合に有益です。 基本的な情報として、このパターンでは、イメージダイジェスト、マニフェスト、タグなど、コンテナイメージのコンポーネントについても説明します。Amazon ECR への移行を計画するときは、イメージのダイジェストを比較して、コンテナレジストリ間でコンテナイメージを同期することができます。コンテナイメージを移行する前に、重複を防ぐために、これらのイメージが Amazon ECR リポジトリに既に存在するかどうかを確認する必要があります。ただし、イメージダイジェストを比較して重複を検出するのが難しく、初期移行フェーズで問題が発生する可能性があります。 このパターンでは、イメージを正確に比較するのに役立つように、異なるコンテナレジストリに保存されている 2 つの類似イメージのダイジェストを比較し、ダイジェストが異なる理由を説明します。 ## 前提条件と制限事項 + アクティブな AWS アカウント + [Amazon ECR パブリックレジストリ](https://gallery.ecr.aws/)へのアクセス + 以下に精通していること AWS のサービス。 + [AWS CodeCommit](https://aws.amazon.com/codecommit/) + [AWS CodePipeline](https://aws.amazon.com/codepipeline/) + [AWS CodeBuild](https://aws.amazon.com/codebuild/) + [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) + [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) + CodeCommit 認証情報が設定されていること ([手順](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html)を参照) ## アーキテクチャ **コンテナイメージコンポーネント** 次の図に、コンテナイメージのコンポーネントの一部を示します。これらのコンポーネントについては、図の後に説明します。 ![\[マニフェスト、設定、ファイルシステムレイヤー、ダイジェスト。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/7db5020c-6f5b-4e91-b91a-5b8ae844be1b/images/71b99c67-a934-4f94-8af8-2a8431fb91f5.png) **用語と定義** 以下の用語は、「[Open Container Initiative (OCI): Image Format Specification](https://github.com/opencontainers/image-spec/blob/main/spec.md)」で定義されています。 + **レジストリ:** イメージのストレージと管理のためのサービス。 + **クライアント:** レジストリと通信し、ローカルイメージと連携するツール。 + **プッシュ:** イメージをレジストリにアップロードするためのプロセス。 + **プル:** イメージをレジストリからダウンロードするためのプロセス。 + **blob:** レジストリによって保存され、ダイジェストによって対処できるコンテンツのバイナリ形式。 + **インデックス:** さまざまなコンピュータプラットフォーム (x86-64、ARM 64 ビットなど) やメディアタイプの複数のイメージマニフェストを識別するコンストラクト。詳細については、「[OCI Image Index Specification](https://github.com/opencontainers/image-spec/blob/main/image-index.md)」を参照してください。 + **マニフェスト:** マニフェストのエンドポイントを介してアップロードされるイメージまたはアーティファクトを定義する JSON ドキュメント。マニフェストは、記述子を使用してリポジトリ内の他の blob を参照できます。詳細については、「[OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/main/manifest.md)」を参照してください。 + **ファイルシステムレイヤー:** イメージのシステムライブラリとその他の依存関係。 + **設定:** アーティファクトメタデータを含み、マニフェストで参照される blob。詳細については、「[OCI Image Configuration](https://github.com/opencontainers/image-spec/blob/main/config.md)」を参照してください。 + **オブジェクトまたはアーティファクト:** blob として保存され、設定とともに付随するマニフェストに関連付けられている概念的なコンテンツ項目。 + **ダイジェスト:** マニフェストの内容の暗号化ハッシュから作成される一意の識別子。イメージダイジェストは、イミュータブルなコンテナイメージを一意に識別するのに役立ちます。ダイジェストを使用してイメージをプルすると、オペレーティングシステムまたはアーキテクチャで毎回同じイメージがダウンロードされます。詳細については、「[Digests](https://github.com/opencontainers/image-spec/blob/main/descriptor.md#digests)」を参照してください。 + **タグ:** 人間が読めるマニフェスト識別子。イミュータブルなイメージダイジェストと比較すると、タグは動的です。イメージを指すタグは、変化し、イメージ間で移動することができますが、基になるイメージダイジェストは同じままです。 **ターゲットアーキテクチャ** 次の図に示すのはこのパターンで提供されるソリューションのアーキテクチャ概要です。このアーキテクチャは Amazon ECR とプライベートリポジトリに保存されているイメージを比較して、重複するコンテナイメージを識別します。 ![\[CodePipeline と CodeBuild を使用して自動的に重複を検出します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/7db5020c-6f5b-4e91-b91a-5b8ae844be1b/images/5ee62bc8-db8d-48a3-9e79-f3392b6e9bf7.png) ## ツール **AWS のサービス** + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理することなく、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 **コード** このパターンのコードは、GitHub リポジトリの** **[Automated solution to identify duplicate container images between repositories](https://github.com/aws-samples/automated-solution-to-identify-duplicate-container-images-between-repositories/) で入手できます。 ## ベストプラクティス + [CloudFormation  ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html) のベストプラクティス + [AWS CodePipeline  ](https://docs.aws.amazon.com/codepipeline/latest/userguide/best-practices.html) のベストプラクティス ## エピック ### Amazon ECR パブリックおよびプライベートリポジトリからコンテナイメージをプルする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECR パブリックリポジトリからイメージをプルします。 | ターミナルから次のコマンドを実行して、Amazon ECR パブリックリポジトリからイメージ `amazonlinux` をプルします。
$~ % docker pull public.ecr.aws/amazonlinux/amazonlinux:2018.03
ローカルマシンへのイメージのプルが完了すると、イメージインデックスを表す次のプルダイジェストが表示されます。
2018.03: Pulling from amazonlinux/amazonlinux
4ddc0f8d367f: Pull complete 

Digest: sha256:f972d24199508c52de7ad37a298bda35d8a1bd7df158149b381c03f6c6e363b5

Status: Downloaded newer image for public.ecr.aws/amazonlinux/amazonlinux:2018.03
public.ecr.aws/amazonlinux/amazonlinux:2018.03
| アプリ開発者、AWS DevOps、AWS 管理者 | | Amazon ECR プライベートリポジトリにイメージをプッシュします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | AWS 管理者、AWS DevOps、アプリ開発者 | | Amazon ECR プライベートリポジトリから同じイメージをプルします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | アプリ開発者、AWS DevOps、AWS 管理者 | ### イメージマニフェストを比較する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECR パブリックリポジトリに保存されている、イメージのマニフェストを見つけます。 | ターミナルから次のコマンドを実行して、Amazon ECR パブリックリポジトリからイメージ `public.ecr.aws/amazonlinux/amazonlinux:2018.03` のマニフェストをプルします。
$~ % docker manifest inspect public.ecr.aws/amazonlinux/amazonlinux:2018.03
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 529,
         "digest": "sha256:52db9000073d93b9bdee6a7246a68c35a741aaade05a8f4febba0bf795cdac02",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      }
   ]
}
| AWS 管理者、AWS DevOps、アプリ開発者 | | Amazon ECR プライベートリポジトリに保存されている、イメージのマニフェストを見つけます。 | ターミナルから次のコマンドを実行して、Amazon ECR プライベートリポジトリからイメージ `.dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository:latest` のマニフェストをプルします。
$~ % docker manifest inspect .dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository:latest                                          
{
	"schemaVersion": 2,
	"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
	"config": {
		"mediaType": "application/vnd.docker.container.image.v1+json",
		"size": 1477,
		"digest": "sha256:f7cee5e1af28ad4e147589c474d399b12d9b551ef4c3e11e02d982fce5eebc68"
	},
	"layers": [
		{
			"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
			"size": 62267075,
			"digest": "sha256:4ddc0f8d367f424871a060e2067749f32bd36a91085e714dcb159952f2d71453"
		}
	]
}
| AWS DevOps、AWS システム管理者、アプリケーション開発者 | | Docker によってプルされたダイジェストと、Amazon ECR プライベートリポジトリ内のイメージのマニフェストダイジェストを比較します。 | ここでの疑問は、**docker pull** コマンドによって得られるダイジェストが、イメージ `.dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository:latest` のマニフェストのダイジェストとなぜ異なるかです。**docker pull** に使用されるダイジェストは、レジストリに保存されているイメージマニフェストのダイジェストを表します。このダイジェストは、マニフェストにダウンロードされて Docker にインポートされるコンテンツのハッシュが含まれるため、ハッシュチェーンのルートとみなされます。Docker 内で使用されるイメージ ID は、このマニフェストで `config.digest` として確認できます。これは、Docker が使用するイメージ設定を表します。そのため、マニフェストは封筒、イメージは封筒の中身であると言うことができます。マニフェストダイジェストは常にイメージ ID とは異なります。ただし、特定のマニフェストは常に同じイメージ ID を生成する必要があります。マニフェストダイジェストはハッシュチェーンであるため、特定のイメージ ID で常に同じになるよう保証することはできません。ほとんどの場合、同じダイジェストを生成しますが、Docker ではそれを保証できません。マニフェストダイジェストの違いは、Docker が gzip でローカルに圧縮された blob を保存しないことが原因で発生します。そのため、レイヤーをエクスポートすると、非圧縮のコンテンツは同じであっても、異なるダイジェストが生成される可能性があります。イメージ ID は、非圧縮のコンテンツが同じであることを確認します。つまり、イメージ ID がコンテンツのアドレス可能な識別子 (`chainID`) となっているということです。この情報を確認するには、Amazon ECR のパブリックリポジトリとプライベートリポジトリで **docker inspect** コマンドの出力を比較します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html)結果で、両方のイメージに同じイメージ ID ダイジェストとレイヤーダイジェストがあることを確認します。ID: `f7cee5e1af28ad4e147589c474d399b12d9b551ef4c3e11e02d982fce5eebc68`レイヤー: `d5655967c2c4e8d68f8ec7cf753218938669e6c16ac1324303c073c736a2e2a2`また、ダイジェストは、ローカルで管理されるオブジェクトのバイト数 (ローカルファイルはコンテナイメージレイヤーの tar) またはレジストリサーバーにプッシュされる blob に基づいています。ただし、blob をレジストリにプッシュすると、tar が圧縮され、ダイジェストは圧縮された tar ファイルで計算されます。そのため、**docker pull** ダイジェスト値の差は、レジストリ (Amazon ECR プライベートまたはパブリック) レベルで適用される圧縮によって発生します。この説明は、Docker クライアントの使用に固有のものです。この動作は、**nerdctl** や **Finch** などの他のクライアントでは表示されません。プッシュおよびプル操作中にイメージが自動的に圧縮されないためです。 | AWS DevOps、AWS システム管理者、アプリケーション開発者 | ### Amazon ECR のパブリックリポジトリとプライベートリポジトリ間で重複するイメージを自動的に識別する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | このパターンの GitHub リポジトリをローカルフォルダにクローンします。
$git clone https://github.com/aws-samples/automated-solution-to-identify-duplicate-container-images-between-repositories
| AWS 管理者、AWS DevOps | | CI/CD パイプラインをセットアップします。 | GitHub リポジトリには、パイプラインを設定する CloudFormation スタックを作成する `.yaml` ファイルが含まれています AWS CodePipeline。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html)パイプラインは、プライベートリポジトリ内にありパブリックリポジトリにも存在するイメージを識別するために、2 つのステージ (アーキテクチャ図に示すように CodeCommit と CodeBuild) でセットアップされます。パイプラインには、次のリソースが設定されています。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | AWS 管理者、AWS DevOps | | CodeCommit リポジトリに入力します。 | CodeCommit リポジトリに入力するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | AWS 管理者、AWS DevOps | | クリーンアップ | 料金が今後発生しないように、以下の手順に従ってリソースを削除します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | AWS 管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ターミナルまたはコマンドラインから、CodeCommit リポジトリへのプッシュ、リポジトリからのプル、またはこのリポジトリとの接続を試みると、ユーザー名およびパスワードの入力を求められるため、IAM ユーザーの Git 認証情報を入力する必要がある。 | このエラーの一般的な原因は以下のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html)オペレーティングシステムおよびローカル環境によっては、認証情報マネージャーのインストール、オペレーティングシステム内の認証情報マネージャーの設定、またはローカル環境のカスタマイズを行い、認証情報ストレージを使用する必要がある場合があります。例えば、コンピュータで macOS が実行されている場合は、Keychain Access ユーティリティを使用して認証情報を保存できます。コンピュータで Windows が実行されている場合は、Git for Windows と一緒にインストールされている Git 認証情報マネージャーを使用できます。詳細については、CodeCommit ドキュメントの「[Setup for HTTPS users using Git credentials](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html)」と、Git ドキュメントの「[認証情報の保存](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage)」を参照してください。 | | Amazon ECR リポジトリにイメージをプッシュすると、HTTP 403、つまり「no basic auth credentials」というエラーが発生する。 | **aws ecr get-login-password** コマンドを使用して Docker への認証に成功した場合でも、**docker push** コマンドまたは **docker pull** コマンドからこれらのエラーメッセージが表示されることがあります。既知の原因は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | ## 関連リソース + [Automated solution to identify duplicate container images between repositories](https://github.com/aws-samples/automated-solution-to-identify-duplicate-container-images-between-repositories/) (GitHub リポジトリ) + [Amazon ECR Public Gallery](https://gallery.ecr.aws/) + [Private images in Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/images.html) (Amazon ECR ドキュメント) + [AWS::CodePipeline::Pipeline リソース](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-pipeline.html) (CloudFormation ドキュメント) + [OCI Image Format Specification](https://github.com/opencontainers/image-spec/blob/main/spec.md) ## 追加情報 **Amazon ECR パブリックリポジトリ内のイメージの Docker 検査の出力** ``` [ { "Id": "sha256:f7cee5e1af28ad4e147589c474d399b12d9b551ef4c3e11e02d982fce5eebc68", "RepoTags": [ ".dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository:latest", "public.ecr.aws/amazonlinux/amazonlinux:2018.03" ], "RepoDigests": [ ".dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository@sha256:52db9000073d93b9bdee6a7246a68c35a741aaade05a8f4febba0bf795cdac02", "public.ecr.aws/amazonlinux/amazonlinux@sha256:f972d24199508c52de7ad37a298bda35d8a1bd7df158149b381c03f6c6e363b5" ], "Parent": "", "Comment": "", "Created": "2023-02-23T06:20:11.575053226Z", "Container": "ec7f2fc7d2b6a382384061247ef603e7d647d65f5cd4fa397a3ccbba9278367c", "ContainerConfig": { "Hostname": "ec7f2fc7d2b6", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ], "Cmd": [ "/bin/sh", "-c", "#(nop) ", "CMD [\"/bin/bash\"]" ], "Image": "sha256:c1bced1b5a65681e1e0e52d0a6ad17aaf76606149492ca0bf519a466ecb21e51", "Volumes": null, "WorkingDir": "", "Entrypoint": null, "OnBuild": null, "Labels": {} }, "DockerVersion": "20.10.17", "Author": "", "Config": { "Hostname": "", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ], "Cmd": [ "/bin/bash" ], "Image": "sha256:c1bced1b5a65681e1e0e52d0a6ad17aaf76606149492ca0bf519a466ecb21e51", "Volumes": null, "WorkingDir": "", "Entrypoint": null, "OnBuild": null, "Labels": null }, "Architecture": "amd64", "Os": "linux", "Size": 167436755, "VirtualSize": 167436755, "GraphDriver": { "Data": { "MergedDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/merged", "UpperDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/diff", "WorkDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/work" }, "Name": "overlay2" }, "RootFS": { "Type": "layers", "Layers": [ "sha256:d5655967c2c4e8d68f8ec7cf753218938669e6c16ac1324303c073c736a2e2a2" ] }, "Metadata": { "LastTagTime": "2023-03-02T10:28:47.142155987Z" } } ] ``` **Amazon ECR プライベートリポジトリ内のイメージの Docker 検査の出力** ``` [ { "Id": "sha256:f7cee5e1af28ad4e147589c474d399b12d9b551ef4c3e11e02d982fce5eebc68", "RepoTags": [ ".dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository:latest", "public.ecr.aws/amazonlinux/amazonlinux:2018.03" ], "RepoDigests": [ ".dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository@sha256:52db9000073d93b9bdee6a7246a68c35a741aaade05a8f4febba0bf795cdac02", "public.ecr.aws/amazonlinux/amazonlinux@sha256:f972d24199508c52de7ad37a298bda35d8a1bd7df158149b381c03f6c6e363b5" ], "Parent": "", "Comment": "", "Created": "2023-02-23T06:20:11.575053226Z", "Container": "ec7f2fc7d2b6a382384061247ef603e7d647d65f5cd4fa397a3ccbba9278367c", "ContainerConfig": { "Hostname": "ec7f2fc7d2b6", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ], "Cmd": [ "/bin/sh", "-c", "#(nop) ", "CMD [\"/bin/bash\"]" ], "Image": "sha256:c1bced1b5a65681e1e0e52d0a6ad17aaf76606149492ca0bf519a466ecb21e51", "Volumes": null, "WorkingDir": "", "Entrypoint": null, "OnBuild": null, "Labels": {} }, "DockerVersion": "20.10.17", "Author": "", "Config": { "Hostname": "", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ], "Cmd": [ "/bin/bash" ], "Image": "sha256:c1bced1b5a65681e1e0e52d0a6ad17aaf76606149492ca0bf519a466ecb21e51", "Volumes": null, "WorkingDir": "", "Entrypoint": null, "OnBuild": null, "Labels": null }, "Architecture": "amd64", "Os": "linux", "Size": 167436755, "VirtualSize": 167436755, "GraphDriver": { "Data": { "MergedDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/merged", "UpperDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/diff", "WorkDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/work" }, "Name": "overlay2" }, "RootFS": { "Type": "layers", "Layers": [ "sha256:d5655967c2c4e8d68f8ec7cf753218938669e6c16ac1324303c073c736a2e2a2" ] }, "Metadata": { "LastTagTime": "2023-03-02T10:28:47.142155987Z" } } ] ``` # Kubernetes DaemonSet を使用して Amazon EKS ワーカーノードに SSM エージェントをインストールします *Amazon Web Services、Mahendra Revanasiddappa* ## 概要 **注、2021 年 9 月：**Amazon EKS に最適化された最新の AMI では SSM エージェントが自動的にインストールされます。詳細については、[リリースノート](https://github.com/awslabs/amazon-eks-ami/releases/tag/v20210621)の「June 2021 AMI」セクションを参照してください。 Amazon Elastic Kubernetes Service (Amazon EKS) では、セキュリティガイドラインにより、ワーカーノードにはSecure Shell (SSH) キーペアがアタッチされていません。このパターンは、手動でインストールしたり、ノードの Amazon マシンイメージ (AMI) を置き換えたりする代わりに、Kubernetes DaemonSet リソースタイプを使用して AWS Systems Manager Agent (SSM Agent) をすべてのワーカーノードにインストールする方法を示しています。DaemonSet はワーカーノードの cron ジョブを使用して SSM エージェントのインストールをスケジュールします。このパターンを使用して他のパッケージをワーカーノードにインストールすることもできます。 クラスター内の問題をトラブルシューティングする場合、SSM Agent をオンデマンドでインストールすると、SSH キーペアがなくても、ワーカーノードとの SSH セッションの確立、ログの収集、またはインスタンス設定の確認が可能になります。 ## 前提条件と制限 **前提条件** + Amazon Elastic Compute Cloud (Amazon EC2) ワーカーノードを備えた既存の Amazon EKS クラスター。 + コンテナインスタンスには、SSM サービスと通信するために必要な許可がなければなりません。AWS Identity と Access Management (IAM) マネージドロール 「**AmazonSSMManagedInstanceCore**は、EC2 インスタンスで SSM エージェントを実行するために必要な許可を提供します。詳細については、[ AWS Systems Manager のドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html)を参照してください。 **制限事項** + DaemonSets は Fargate プラットフォームではサポートされていないため、このパターンは AWS Fargate には適用されません。 + このパターンは Linux ベースのワーカーノードにのみ適用されます。 + DaemonSet ポッドは特権モードで実行されます。Amazon EKS クラスターに特権モードでポッドをブロックするウェブフックがある場合、SSM エージェントはインストールされません。 ## アーキテクチャ このパターンのアーキテクチャを以下に図で示します。 ![\[Kubernetes DaemonSet を使用して Amazon EKS ワーカーノードに SSM エージェントをインストールします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/016d53f3-45c1-4913-b542-67124e1462b8/images/3a6dfd00-e54b-44d5-843a-4c26ce9826c9.png) ## ツール **ツール** + 「[kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」は、Amazon EKS クラスターを操作するために使用されるコマンドラインユーティリティです。このパターンは`kubectl`を使用して Amazon EKS クラスターに DaemonSet をデプロイします。これにより、SSM エージェントがすべてのワーカーノードにインストールされます。 + [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) は、独自の Kubernetes コントロールプレーンまたはノードをインストール、操作、維持することなく、 で Kubernetes を簡単に実行できるようにするマネージドサービスです。Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するためのオープンソースシステムです。 + [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) は、EC2 インスタンス、オンプレミスインスタンス、仮想マシン (VM) を、インタラクティブなワンクリックブラウザベースのシェルまたは AWS コマンドラインインターフェイス (AWS CLI) を介して管理できます。 **Code** 次のコードを使用して、Amazon EKS クラスターに SSM エージェントをインストールする DaemonSet 設定ファイルを作成します。「[エピック](#install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-epics) 」セクションの指示に従います。 ``` cat << EOF > ssm_daemonset.yaml apiVersion: apps/v1 kind: DaemonSet metadata: labels: k8s-app: ssm-installer name: ssm-installer namespace: kube-system spec: selector: matchLabels: k8s-app: ssm-installer template: metadata: labels: k8s-app: ssm-installer spec: containers: - name: sleeper image: busybox command: ['sh', '-c', 'echo I keep things running! && sleep 3600'] initContainers: - image: amazonlinux imagePullPolicy: Always name: ssm command: ["/bin/bash"] args: ["-c","echo '* * * * * root yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm & rm -rf /etc/cron.d/ssmstart' > /etc/cron.d/ssmstart"] securityContext: allowPrivilegeEscalation: true volumeMounts: - mountPath: /etc/cron.d name: cronfile terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumes: - name: cronfile hostPath: path: /etc/cron.d type: Directory dnsPolicy: ClusterFirst restartPolicy: Always schedulerName: default-scheduler terminationGracePeriodSeconds: 30 EOF ``` ## エピック ### kubectl のセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | EKS クラスターにアクセスするように kubectl をインストールして設定します。 | `kubectl`がまだインストールされておらず、Amazon EKS クラスタにアクセスするように構成されていない場合、Amazon EKS ドキュメントの「[kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」を参照してください。 | DevOps | ### DaemonSet をデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DeamonSet設定ファイルを作成します。 | このパターンの前述の「[コード](#install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-tools)」セクションのコードを使用して、`ssm_daemonset.yaml`という名前の DaemonSet 設定ファイルを作成します。このファイルは Amazon EKS クラスターにデプロイされます。DaemonSet によって起動されるポッドには、メインコンテナと`init`コンテナがあります。メインコンテナには`sleep`コマンドがあります。`init`コンテナには、パス`/etc/cron.d/`に SSM Agent をインストールするための cron ジョブファイルを作成する`command`セクションが含まれています。cron ジョブは 1 回だけ実行され、作成されるファイルはジョブの完了後に自動的に削除されます。init コンテナが終了すると、メインコンテナは 60 分間待機してから終了します。60 分後、新しいポッドが起動します。このポッドは、SSM エージェントがない場合はインストールするか、SSM エージェントを最新バージョンに更新します。必要であれば、`sleep`コマンドを変更して、ポッドを1日1回再起動したり、もっと頻繁に実行したりすることができる。  | DevOps | | DaemonSet を Amazon EKS クラスターにデプロイします。 | 前のステップで作成した DaemonSet 設定ファイルを Amazon EKS クラスターにデプロイするには、次のコマンドを使用します。
kubectl apply -f ssm_daemonset.yaml
このコマンドは、ワーカーノードでポッドを実行して SSM Agent をインストールする DaemonSet を作成します。 | DevOps | ## 関連リソース + [kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) (Amazon EKS ドキュメント) + [セッションマネージャーのセットアップ](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) (AWS Systems Manager ドキュメント) # prebootstrapコマンドを使用して、SSM エージェントと CloudWatch エージェントを Amazon EKS ワーカーノードにインストールします。 *Amazon Web Services、Akkamahadevi Hiremath* ## 概要 このパターンは、Amazon EKS クラスターの作成中に AWS Systems Manager Agent (SSM Agent) と Amazon CloudWatch エージェントをAmazon Web Services (AWS) クラウド内の Amazon Elastic Kubernetes Service (Amazon EKS) ワーカーノードにインストールするためのコードサンプルと手順を提供します。SSM エージェントと CloudWatch エージェントは、`eksctl`「[設定ファイルスキーマ](https://eksctl.io/usage/schema/)」 (Weaveworks ドキュメント) `preBootstrapCommands`のプロパティを使用してインストールできます。そうすれば、Amazon Elastic Compute Cloud (Amazon EC2) key pair を使用せずに SSM Agent を使用してワーカーノードに接続できます。さらに、CloudWatch エージェントを使用して Amazon EKS ワーカーノードのメモリとディスクの使用状況をモニタリングできます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント。 + macOS、Linux、または Windows で、インストールおよび設定されている「[eksctl コマンドラインユーティリティ](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)」 + macOS、Linux、または Windows で、インストールおよび設定されている「[kubectl コマンドラインユーティリティ](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」 **制限事項** + 実行時間の長いスクリプトは`preBootstrapCommands`** **プロパティに追加しないことをお勧めします。追加すると、スケーリングアクティビティ中にノードが Amazon EKS クラスターに参加するのが遅れるためです。代わりに「[カスタム Amazon Machine Image (AMI)](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.customenv.html)」を作成することをお勧めします。 + このパターンは、Amazon EC2 Linux インスタンスにのみ適用されます。 ## アーキテクチャ **テクノロジースタック** + Amazon CloudWatch + Amazon Elastic Kubernetes Service (Amazon EKS) + Systems Manager Parameter Store **ターゲットアーキテクチャ** 次の図は、`preBootstrapCommands`を使用してインストールされた SSM エージェントを使用して Amazon EKS ワーカーノードに接続するユーザーの例を示しています。 ![\[User connecting to Amazon EKS worker nodes via Systems Manager, with SSM Agent and CloudWatch agent on each node.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b37a3cdb-204f-4014-8317-3600a793dac7/images/9a5760af-23bb-4616-97b0-b401a9d080cf.png) この図表は、次のワークフローを示しています: 1. ユーザは、`preBootstrapCommands`プロパティを持つ`eksctl`設定ファイルを使用してAmazon EKSクラスタを作成し、SSMエージェントとCloudWatchエージェントをインストールします。 1. スケーリングアクティビティによって後でクラスターに追加される新しいインスタンスは、プレインストールされた SSM エージェントと CloudWatch エージェントを使用して作成されます。 1. ユーザーは SSM エージェントを使用して Amazon EC2 に接続し、CloudWatch エージェントを使用してメモリとディスクの使用状況をモニタリングします。 ## ツール + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、AWS のリソースや、AWS で実行されるアプリケーションをリアルタイムに監視します。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) は、AWS で Kubernetes を実行する際に役立ち、独自の Kubernetes コントロールプレーンまたはノードをインストールまたは維持する必要はありません。 + [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) は、設定データ管理とシークレット管理用の安全な階層型ストレージを提供します。 + 「[AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)」は、AWS Systems Manager で、インタラクティブなワンクリックブラウザベースのシェルまたは AWS CLI Command Line Interface (AWS CLI) を介して管理できます。 + [eksctl](https://eksctl.io/usage/schema/) – これは Amazon EKS で Kubernetes クラスターを作成および管理するコマンドラインユーティリティです。 + [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) – これはクラスター API サーバーとの通信用コマンドラインユーティリティです。 ## エピック ### Amazon EKS クラスターを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudWatch エージェント設定ファイルを保存します。 | CloudWatch エージェント設定ファイルを、Amazon EKS クラスターを作成する AWS リージョンの「[AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)」に保存します。これを行うには、AWS Systems Manager Parameter Storeで「[パラメータを作成](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html)」し、パラメータの名前 (例：`AmazonCloudwatch-linux`) を書き留めます。詳細については、このパターンの「[追加情報](#install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands-additional)」セクションにある「*CloudWatch エージェント設定ファイルの例*」を参照してください。 | DevOps エンジニア | | eksctl 設定ファイルとクラスターを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands.html) | AWS DevOps | ### SSM エージェントと CloudWatch エージェントが動作することを確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SSM Agent をテストします。 | SSH を使用して、AWS Systems Manager ドキュメントの「[セッションの開始](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console%20%20or%20https:%2F%2Fdocs.aws.amazon.com%2Fsystems-manager%2Flatest%2Fuserguide%2Fsession-manager-working-with-sessions-start.html%23sessions-start-cli)」で説明されている方法のいずれかを使用して Amazon EKS クラスターノードに接続します。 | AWS DevOps | | CloudWatch エージェントをテストします。 | CloudWatch コンソールを使用して CloudWatch エージェントを検証します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands.html) | AWS DevOps | ## 関連リソース + [サーバーにエージェントをインストールして実行する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html) (Amazon CloudWatch ドキュメント) + [Systems Manager パラメータを作成する (コンソール)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) (AWS Systems Manager ドキュメント) + [CloudWatch エージェント設定ファイルを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file.html) (Amazon CloudWatch ドキュメント) + [セッションを開始します](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#sessions-start-cli) (AWS Systems Manager のドキュメント) + [セッションを開始する (Amazon EC2 コンソール)](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console) (AWS Systems Manager ドキュメント) ## 追加情報 **CloudWatch エージェント設定ファイルの例** 次の例では、CloudWatch エージェントは Amazon Linux インスタンスのディスクとメモリの使用状況を監視するように設定されています。 ``` { "agent": { "metrics_collection_interval": 60, "run_as_user": "cwagent" }, "metrics": { "append_dimensions": { "AutoScalingGroupName": "${aws:AutoScalingGroupName}", "ImageId": "${aws:ImageId}", "InstanceId": "${aws:InstanceId}", "InstanceType": "${aws:InstanceType}" }, "metrics_collected": { "disk": { "measurement": [ "used_percent" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "mem": { "measurement": [ "mem_used_percent" ], "metrics_collection_interval": 60 } } } } ``` **eksctl 設定ファイルの例** ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: test region: us-east-2 version: "1.24" managedNodeGroups: - name: test minSize: 2 maxSize: 4 desiredCapacity: 2 volumeSize: 20 instanceType: t3.medium preBootstrapCommands: - sudo yum install amazon-ssm-agent -y - sudo systemctl enable amazon-ssm-agent - sudo systemctl start amazon-ssm-agent - sudo yum install amazon-cloudwatch-agent -y - sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudwatch-linux iam: attachPolicyARNs: - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore ``` **その他のコードの詳細** + `preBootstrapCommands`プロパティの最後の行には、`AmazonCloudwatch-linux`はAWS System Manager Parameter Storeで作成されたパラメータ名です。Amazon EKS クラスターを作成したときと同じ AWS リージョンのパラメータストアに`AmazonCloudwatch-linux`を含める必要があります。ファイルパスを指定することもできますが、自動化と再利用を容易にするために Systems Manager を使用することをお勧めします。 + `eksctl`設定ファイルで`preBootstrapCommands`を使用すると、AWS マネジメントコンソールに 2 つの起動テンプレートが表示されます。最初の起動テンプレートには、`preBootstrapCommands`で指定されているコマンドが含まれています。2 番目のテンプレートには、`preBootstrapCommands`で指定されているコマンドとデフォルトの Amazon EKS ユーザーデータが含まれます。このデータは、ノードをクラスターに参加させるために必要です。ノードグループの Auto Scaling グループは、このユーザーデータを使用して新しいインスタンスを起動します。 + `eksctl`設定ファイルの`iam`属性を使用する場合は、デフォルトの Amazon EKS ポリシーと、添付AWS Identity and Access Management (IAM) ポリシーに必要な追加ポリシーを一覧表示する必要があります。「*eksctl 設定ファイルとクラスターの作成*」ステップのコードスニペットには、`CloudWatchAgentServerPolicy`と`AmazonSSMMangedInstanceCore`は、CloudWatchエージェントとSSMエージェントが期待どおりに動作することを確認するために追加されたポリシーです。`AmazonEKSWorkerNodePolicy`、`AmazonEKS_CNI_Policy`、`AmazonEC2ContainerRegistryReadOnly`ポリシーは Amazon EKS クラスターが正しく機能するために必要な必須ポリシーです。 # Amazon EKS Auto Mode を有効化する際に NGINX Ingress Controller を移行する *Amazon Web Services、Olawale Olaleye、Shamanth Devagari* ## 概要 Amazon Elastic Kubernetes Service (Amazon EKS) の [EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/automode.html) を使用すると、Kubernetes クラスターでワークロードを実行する際の運用オーバーヘッドを削減できます。このモードでは AWS 、 がユーザーに代わってインフラストラクチャを設定および管理することもできます。既存のクラスターで EKS Auto Mode を有効にする場合は、[NGINX Ingress Controller](https://docs.nginx.com/nginx-ingress-controller/overview/about/) の設定移行を慎重に実施する必要があります。Network Load Balancer の直接転送は不可となっているためです。 既存の Amazon EKS クラスターで EKS Auto Mode を有効にすると、ブルー/グリーンデプロイを用いて NGINX Ingress Controller インスタンスを移行できます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + Kubernetes バージョン 1.29 を搭載の [Amazon EKS クラスター](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) + [最小バージョン](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html#auto-addons-required)を実行する Amazon EKS アドオン + [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html#kubectl-install-update) の最新バージョン + 既存の [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/deploy/#aws) インスタンス + (オプション) DNS ベースのトラフィックシフト用の Amazon Route 53 の[ホストゾーン](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) ## アーキテクチャ *ブルー/グリーンデプロイ*とは、構成が同一である 2 つの環境を別々に構築するデプロイメント戦略です。ブルー/グリーンデプロイではリリースのためのダウンタイムがほとんどなく、ロールバックが可能になります。異なるアプリケーションバージョンを実行している 2 つの同一環境間で、トラフィックを移行することを主な目的としています。 次の図は、EKS Auto Mode を有効にする際の 2 つの異なる NGINX Ingress Controller インスタンスからの Network Load Balancer の移行を示しています。ブルー/グリーンデプロイを使用して、2 つの Network Load Balancer 間でトラフィックをシフトします。 ![\[ブルー/グリーンデプロイを使用して NGINX Ingress Controller インスタンスを移行します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/57e8c14f-cb50-4027-8ef6-ce8ea3f2db25/images/211a029a-90d8-4c92-8200-19e54062f936.png) オリジナルの名前空間は*青*で示されています。EKS Auto Mode を有効にする前に、元の NGINX Ingress Controller サービスとインスタンスが実行される場所です。元のサービスとインスタンスは、Route 53 で設定された DNS 名を持つ Network Load Balancer に接続します。[AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.11/) は、この Network Load Balancer をターゲット仮想プライベートクラウド (VPC) にデプロイします。 この図は、ブルー/グリーンデプロイの環境設定を行う以下のワークフローを示します。 1. 別の NGINX Ingress Controller インスタンスを*緑*の名前空間にインストールして設定します。 1. Route 53 で、新しい Network Load Balancer の DNS 名を設定します。 ## ツール **AWS のサービス** + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 + 受信したアプリケーションまたはネットワークトラフィックを複数のターゲットに分散するには、[Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) を使用します。例えば、1 つまたは複数のアベイラビリティーゾーンの Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、および IP アドレスにトラフィックを分散できます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS ウェブサービスです。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。 **その他のツール** + [Helm](https://helm.sh/) は、Kubernetes 用のオープンソースのパッケージマネージャです。Kubernetes クラスター上でアプリケーションをインストールおよび管理できます。 + [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)は、Kubernetes クラスターに対してコマンドを実行するためのコマンドラインインターフェイスです。 + [NGINX Ingress Controller](https://docs.nginx.com/nginx-ingress-controller/overview/about/) は、Kubernetes アプリケーションとサービスをリクエスト処理、認証、セルフサービスのカスタムリソース、デバッグに接続します。 ## エピック ### 既存環境を確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 元の NGINX Ingress Controller インスタンスが動作していることを確認します。 | 次のコマンドを入力して、`ingress-nginx` 名前空間内のリソースが動作していることを確認します。NGINX Ingress Controller を別の名前空間にデプロイした場合は、このコマンドで名前空間名を更新します。
kubectl get all -n ingress-nginx
出力で、NGINX Ingress Controller ポッドが実行中であることを確認します。以下は、その出力例です。
NAME                                           READY   STATUS      RESTARTS      AGE
pod/ingress-nginx-admission-create-xqn9d       0/1     Completed   0             88m
pod/ingress-nginx-admission-patch-lhk4j        0/1     Completed   1             88m
pod/ingress-nginx-controller-68f68f859-xrz74   1/1     Running     2 (10m ago)   72m

NAME                                         TYPE           CLUSTER-IP       EXTERNAL-IP                                                                     PORT(S)                      AGE
service/ingress-nginx-controller             LoadBalancer   10.100.67.255    k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com   80:30330/TCP,443:31462/TCP   88m
service/ingress-nginx-controller-admission   ClusterIP      10.100.201.176                                                                             443/TCP                      88m

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ingress-nginx-controller   1/1     1            1           88m

NAME                                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/ingress-nginx-controller-68f68f859   1         1         1       72m
replicaset.apps/ingress-nginx-controller-d8c96cf68   0         0         0       88m

NAME                                       STATUS     COMPLETIONS   DURATION   AGE
job.batch/ingress-nginx-admission-create   Complete   1/1           4s         88m
job.batch/ingress-nginx-admission-patch    Complete   1/1           5s         88m
| DevOps エンジニア | ### サンプルの HTTPd ワークロードをデプロイして NGINX Ingress Controller を使用する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Kubernetes リソースを作成します。 | 次のコマンドを入力して、Kubernetes のサンプルデプロイ、サービス、イングレスを作成します。
kubectl create deployment demo --image=httpd --port=80
kubectl expose deployment demo
 kubectl create ingress demo --class=nginx \
  --rule nginxautomode.local.dev/=demo:80
| DevOps エンジニア | | デプロイされたリソースを確認します。 | 次のコマンドを入力して、デプロイ済みリソースリストを表示します。
kubectl get all,ingress
出力で、サンプル HTTPd ポッドが実行中であることを確認します。以下は、その出力例です。
NAME                        READY   STATUS    RESTARTS   AGE
pod/demo-7d94f8cb4f-q68wc   1/1     Running   0          59m

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/demo         ClusterIP   10.100.78.155           80/TCP    59m
service/kubernetes   ClusterIP   10.100.0.1              443/TCP   117m

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/demo   1/1     1            1           59m

NAME                              DESIRED   CURRENT   READY   AGE
replicaset.apps/demo-7d94f8cb4f   1         1         1       59m

NAME                             CLASS   HOSTS                                  ADDRESS                                                                         PORTS   AGE
ingress.networking.k8s.io/demo   nginx   nginxautomode.local.dev                k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com                 80      56m
| DevOps エンジニア | | サービスに到達できることを確認します。 | 次のコマンドを入力して、サービスが Network Load Balancer の DNS 名を介して到達可能であることを確認します。
curl -H "Host: nginxautomode.local.dev" http://k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com
予想される出力は次のようになります。
It works!
| DevOps エンジニア | | (オプション) DNS レコードを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | DevOps エンジニア、AWS DevOps | ### 既存クラスターで EKS Auto Mode を有効にする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | EKS Auto Mode を有効にします。 | 「[既存のクラスターで EKS Auto Mode モードを有効にする](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html) (Amazon EKS ドキュメント)」に記載の手順に従います。 | AWS DevOps | ### 新しい NGINX Ingress Controller をインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 新しい NGINX Ingress Controller インスタンスを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | DevOps エンジニア | | 新しい NGINX Instance Controller インスタンスをデプロイします。 | 次のコマンドを入力して、変更後のマニフェストを適用します。
kubectl apply -f deploy.yaml
| DevOps エンジニア | | デプロイが成功したことを確認します。 | 次のコマンドを入力して、[`ingress-nginx-v2`] の名前空間内のリソースが動作していることを確認します。
kubectl get all -n ingress-nginx-v2
出力で、NGINX Ingress Controller ポッドが実行中であることを確認します。以下は、その出力例です。
NAME                                            READY   STATUS      RESTARTS   AGE
pod/ingress-nginx-admission-create-7shrj        0/1     Completed   0          24s
pod/ingress-nginx-admission-patch-vkxr5         0/1     Completed   1          24s
pod/ingress-nginx-controller-757bfcbc6d-4fw52   1/1     Running     0          24s

NAME                                         TYPE           CLUSTER-IP       EXTERNAL-IP                                                                     PORT(S)                      AGE
service/ingress-nginx-controller             LoadBalancer   10.100.208.114   k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com   80:31469/TCP,443:30658/TCP   24s
service/ingress-nginx-controller-admission   ClusterIP      10.100.150.114                                                                             443/TCP                      24s

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ingress-nginx-controller   1/1     1            1           24s

NAME                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/ingress-nginx-controller-757bfcbc6d   1         1         1       24s

NAME                                       STATUS     COMPLETIONS   DURATION   AGE
job.batch/ingress-nginx-admission-create   Complete   1/1           4s         24s
job.batch/ingress-nginx-admission-patch    Complete   1/1           5s         24s
| DevOps エンジニア | | サンプル HTTPd ワークロードに新規イングレスを作成します。 | 既存のサンプル HTTPd ワークロードに新規イングレスを作成するには、以下のコマンドを入力してください。
kubectl create ingress demo-new --class=nginx-v2 \
  --rule nginxautomode.local.dev/=demo:80
| DevOps エンジニア | | 新規イングレスが機能することを確認します。 | 次のコマンドを入力して、新規イングレスが機能することを確認してください。
curl -H "Host: nginxautomode.local.dev" k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com
予想される出力は次のようになります。
It works!
| DevOps エンジニア | ### カットオーバー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 新しい名前空間にカットオーバーします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | AWS DevOps、DevOps エンジニア | | 2 つのイングレスを確認します。 | 次のコマンドを入力して、サンプルの HTTPd ワークロード用に作成された 2 つのイングレスを確認します。
kubectl get ingress
以下は、その出力例です。
NAME       CLASS      HOSTS                                  ADDRESS                                                                         PORTS   AGE
demo       nginx      nginxautomode.local.dev   k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com                              80      95m
demo-new   nginx-v2   nginxautomode.local.dev   k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com                80      33s
| DevOps エンジニア | ## 関連リソース + 「[既存のクラスターで EKS Auto Mode モードを有効にする](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html) (Amazon EKS ドキュメント)」 + [Amazon EKS の Kubernetes サービスコントローラーによって作成されたロードバランサーのトラブルシューティング](https://repost.aws/knowledge-center/eks-load-balancers-troubleshooting) (AWS re:Post ナレッジセンター) + 「[NGINX Ingress Controller](https://docs.nginx.com/nginx-ingress-controller/) (NGINX ドキュメント)」 # コンテナワークロードを Azure Red Hat OpenShift (ARO) から Red Hat OpenShift Service on AWS (ROSA) に移行する *Amazon Web Services、Naveen Ramasamy、Srikanth Rangavajhala、および Gireesh Sreekantan* ## 概要 このパターンでは、Azure Red Hat OpenShift (ARO) から [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) にコンテナワークロードを移行するためのステップバイステップの手順を説明します。ROSA は、Red Hat が と共同で提供するマネージド Kubernetes サービスです AWS。Kubernetes プラットフォームを使用してコンテナ化されたアプリケーションをデプロイ、管理、スケーリングするのに役立ちます。また、Red Hat の Kubernetes に関する専門知識と AWS クラウド インフラストラクチャの両方を活用できます。 ARO、他のクラウド、またはオンプレミスから ROSA にコンテナワークロードを移行するには、アプリケーション、設定、およびデータを、あるプラットフォームから別のプラットフォームに転送する必要があります。このパターンは、 AWS クラウド サービス、セキュリティ、コスト効率を最適化しながら、スムーズな移行を確保するのに役立ちます。ワークロードを ROSA クラスターに移行するための 2 つの方法として、CI/CD と Migration Toolkit for Containers (MTC) について説明します。 このパターンはどちらの方法にも当てはまります。移行プロセスの複雑さと確実性によって、選択する方法は異なります。アプリケーションの状態を完全に制御でき、パイプラインを通じて一貫したセットアップを確保できる場合は、CI/CD を使用することをお勧めします。ただし、アプリケーションの状態に不確実性、予期しない変更、または複雑なエコシステムが含まれる場合は、アプリケーションとそのデータを新しいクラスターに移行するため、信頼性の高い制御されたパスとして MTC を使用することをお勧めします。2 つの方法の詳細な比較については、「[追加情報](#migrate-container-workloads-from-aro-to-rosa-additional)」セクションを参照してください。 ROSA に移行するメリット: + ROSA はネイティブサービス AWS として とシームレスに統合されます。を通じて簡単にアクセス AWS マネジメントコンソール でき、単一の を通じて請求されます AWS アカウント。他の との完全な互換性 AWS のサービス を提供し、 AWS と Red Hat の両方からの共同サポートを提供します。 + ROSA はハイブリッドデプロイとマルチクラウドデプロイをサポートします。これにより、オンプレミスのデータセンターや複数のクラウド環境にわたってアプリケーションを一貫して実行できるようになります。 + ROSA は Red Hat のセキュリティ重視の恩恵を受けており、ロールベースのアクセス制御 (RBAC)、イメージスキャン、脆弱性評価などの機能を提供して、安全なコンテナ環境を確保します。 + ROSA は、アプリケーションを簡単にスケールできるように設計されており、高可用性オプションを提供します。これにより、信頼性を維持しながら、必要に応じてアプリケーションを拡大できます。 + ROSA は、手動のセットアップおよび管理方法と比較して、Kubernetes クラスターのデプロイを自動化して簡素化します。これにより、開発およびデプロイのプロセスが加速されます。 + ROSA は AWS クラウド サービスからメリットを得ており、データベースサービス、ストレージソリューション、セキュリティサービスなどの AWS サービスとシームレスに統合できます。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + AWS のサービス その ROSA 用に設定されたアクセス許可は、機能を提供するために に依存します。詳細については、ROSA ドキュメントの「[Prerequisites](https://docs.aws.amazon.com/rosa/latest/userguide/set-up.html)」を参照してください。 + [ROSA コンソール](https://console.aws.amazon.com/rosa)で有効になっている ROSA。手順については、[ROSA ドキュメント](https://docs.aws.amazon.com/rosa/latest/userguide/set-up.html#enable-rosa)を参照してください。 + インストールおよび設定済みの ROSA クラスター。詳細については、ROSA ドキュメントの「[Get started with ROSA](https://docs.aws.amazon.com/rosa/latest/userguide/getting-started.html)」を参照してください。ROSA クラスターをセットアップするためのさまざまな方法を理解するには、 AWS 「規範ガイダンスガイド」の[「ROSA 実装戦略](https://docs.aws.amazon.com/prescriptive-guidance/latest/red-hat-openshift-on-aws-implementation/)」を参照してください。 + オンプレミスネットワークから (推奨) または [AWS Direct Connect](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect.html) ([AWS Virtual Private NetworkSite-to-Site VPN)](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) AWS を介して に確立されたネットワーク接続。 + `aws client`、OpenShift CLI (`oc`) クライアント、ROSA クライアント、Git バイナリなどのツールをインストールするための Amazon Elastic Compute Cloud (Amazon EC2) インスタンスまたは別の仮想サーバー。 CI/CD での移行に関するその他の前提条件: + 新しいパイプラインの作成、ステージの追加、OpenShift クラスターの追加、ビルドの実行を行うアクセス許可での、オンプレミスの Jenkins サーバーへのアクセス。 + 新しい Git ブランチを作成し、新しいブランチへのコミットを実行するアクセス許可での、アプリケーションのソースコードが維持されている Git リポジトリへのアクセス。 MTC での移行に関するその他の前提条件: + レプリケーションリポジトリとして使用される Amazon Simple Storage Service (Amazon S3) バケット。 + ソース ARO クラスターへの管理アクセス。これは、MTC 接続をセットアップするために必要です。 **制限事項** + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページを参照して、サービスのリンクを選択します。 ## アーキテクチャ ROSA は、パブリック、プライベート、[AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) の 3 つのネットワークデプロイパターンを提供します。Red Hat のサイト信頼性エンジニアリング (SRE) チームは、PrivateLink により、既存の VPC 内に存在するクラスターの PrivateLink エンドポイントに接続されたプライベートサブネットを使用してクラスターを管理できます。 PrivateLink オプションを選択すると、最も安全な設定が提供されます。そのため、機密性の高いワークロードや厳格なコンプライアンス要件の場合に使用することをお勧めします。パブリックとプライベートのネットワークデプロイオプションの詳細については、[Red Hat OpenShift ドキュメント](https://docs.openshift.com/rosa/architecture/rosa-architecture-models.html#rosa-hcp-architecture_rosa-architecture-models)を参照してください。 **重要** PrivateLink クラスターは、インストール時にのみ作成できます。インストール後に PrivateLink を使用するようにクラスターを変更することはできません。 次の図は、 がオンプレミス環境と ARO 環境への接続 Direct Connect に使用する ROSA クラスターの PrivateLink アーキテクチャを示しています。 ![\[AWS Direct Connect と AWS PrivateLink を使用する ROSA クラスター。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/eff9b017-6fc7-4874-b610-849a42071ef4.png) **AWS ROSA への アクセス許可** ROSA へのアクセス AWS 許可については、存続期間の短い動的トークンで AWS Security Token Service (AWS STS) を使用することをお勧めします。この方法では、最小特権の事前定義されたロールとポリシーを使用して、 で運用するための最小限のアクセス許可を ROSA に付与し AWS アカウント、ROSA のインストール、コントロールプレーン、コンピューティング機能をサポートします。 **CI/CD パイプラインの再デプロイ** CI/CD パイプラインの再デプロイは、成熟した CI/CD パイプラインを持つユーザーに推奨される方法です。このオプションを選択すると、任意の [DevOps デプロイ戦略](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html)を使用して、アプリケーション負荷を ROSA 上のデプロイに徐々にシフトできます。 **注記** このパターンは、オンプレミスの Git、JFrog Artifactory、および Jenkins パイプラインがある一般的なユースケースを前提としています。このアプローチでは、オンプレミスネットワークから AWS までネットワーク接続を確立し Direct Connect、[エピック](#migrate-container-workloads-from-aro-to-rosa-epics)セクションの指示に従う前に ROSA クラスターを設定する必要があります。詳細については、「[前提条件](#migrate-container-workloads-from-aro-to-rosa-prereqs)」セクションを参照してください。 以下の図は、この方法のワークフローを示しています。 ![\[CI/CD での移行方法を使用してコンテナを ARO から ROSA に移行します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/f658590e-fbd9-4297-a02c-0b516694d436.png) **MTC での移行** [Migration Toolkit for Containers (MTC)](https://docs.openshift.com/container-platform/4.13/migration_toolkit_for_containers/about-mtc.html)** **を使用すると、コンテナ化されたワークロードを ARO から ROSA へなど、さまざまな Kubernetes 環境間で移行することができます。MTC は、いくつかの重要なタスクを自動化し、移行ライフサイクルを管理するための包括的なフレームワークを提供することで、移行プロセスを簡素化します。 以下の図は、この方法のワークフローを示しています。 ![\[MTC での移行方法を使用してコンテナを ARO から ROSA に移行します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/979bbc7b-2e39-4dd1-b4f0-ea1032880a38.png) ## ツール **AWS のサービス** + [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) は、 AWS ストレージサービスとの間でファイルまたはオブジェクトデータを移動するのに役立つオンラインデータ転送および検出サービスです。 + [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) は、標準イーサネット光ファイバケーブルを介して内部ネットワークを Direct Connect ロケーションにリンクします。この接続を使用すると、ネットワークパスでインターネットサービスプロバイダーをバイパス AWS のサービス しながら、パブリックに直接仮想インターフェイスを作成できます。 + [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) は、仮想プライベートクラウド (VPC) から他の VPC 内のサービスへの単方向のプライベート接続の確立に役立ちます。 + [Red Hat OpenShift Service on AWS (ROSA)](https://docs.aws.amazon.com/rosa/latest/userguide/what-is-rosa.html) は、Red Hat OpenShift ユーザーがコンテナ化されたアプリケーションを構築、スケーリング、管理できるようにするマネージドサービスです AWS。 + [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) は、ユーザーの権限が制限された一時的な認証情報をリクエストするのに役立ちます。 **その他のツール** + [Migration Toolkit for Containers (MTC)](https://docs.openshift.com/container-platform/4.13/migration_toolkit_for_containers/about-mtc.html) は、コンテナ化されたアプリケーションを ARO から ROSA に移行するためのコンソールと API を提供します。 ## ベストプラクティス + [レジリエンス](https://docs.aws.amazon.com/ROSA/latest/userguide/disaster-recovery-resiliency.html)を確保するため、セキュリティコンプライアンスワークロードがある場合は、PrivateLink を使用するマルチ AZ ROSA クラスターをセットアップします。詳細については、[ROSA ドキュメント](https://docs.aws.amazon.com/rosa/latest/userguide/getting-started-classic-private-link.html)を参照してください。 **注記** インストール後に PrivateLink を設定することはできません。 + レプリケーションリポジトリに使用する S3 バケットは、公開しないでください。適切な S3 バケットポリシーを使用してアクセスを制限します。 + MTC での移行を選択した場合は、**[ステージ]** 移行オプションを使用して、カットオーバー中のダウンタイムウィンドウを短縮します。 + ROSA クラスターをプロビジョニングする前と後で、サービスクォータを確認します。必要に応じて、要件に従ってクォータの引き上げをリクエストします。詳細については、[Service Quotas ドキュメント](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)を参照してください。 + [ROSA セキュリティガイドライン](https://docs.aws.amazon.com/ROSA/latest/userguide/security.html)を確認し、セキュリティのベストプラクティスを実装します。 + インストール後に、デフォルトのクラスター管理者を削除することをお勧めします。詳細については、[Red Hat OpenShift のドキュメント](https://docs.openshift.com/container-platform/4.13/post_installation_configuration/cluster-tasks.html)を参照してください。 + マシンプールの自動スケーリングを使用して、ROSA クラスター内の未使用のワーカーノードをスケールダウンし、コストを最適化します。詳細については、「[ROSA Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/5-nodes-storage/3-autoscale-machine-pool)」を参照してください。 + OpenShift Container Platform 向け Red Hat Cost Management サービスを使用すると、クラウドとコンテナのコストをよりよく理解し、追跡することができます。詳細については、「[ROSA Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/10-cost-management)」を参照してください。 + を使用して、ROSA クラスターインフラストラクチャサービスとアプリケーションをモニタリングおよび監査します AWS のサービス。詳細については、「[ROSA Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/8-observability)」を参照してください。 ## エピック ### オプション 1: CI/CD パイプラインを使用する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 新しい ROSA クラスターを Jenkins に追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 管理者、AWS システム管理者、AWS DevOps | | `oc` クライアントを Jenkins ノードに追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 管理者、AWS システム管理者、AWS DevOps | | 新しい Git ブランチを作成します。 | `rosa-dev` 用の Git リポジトリに新しいブランチを作成します。このブランチは、ROSA のコードまたは設定パラメータの変更を既存のパイプラインから分離します。 | AWS DevOps | | ROSA のイメージにタグを付けます。 | ビルドステージでは、別のタグを使用して、ROSA パイプラインから構築されたイメージを識別します。 | AWS 管理者、AWS システム管理者、AWS DevOps | | パイプラインを作成する | 既存のパイプラインと同様の新しい Jenkins パイプラインを作成します。このパイプラインでは、前に作成した `rosa-dev` Git ブランチを使用して、既存のパイプラインと同じ Git チェックアウト、コードスキャン、ビルドステージを含めるようにしてください。 | AWS 管理者、AWS システム管理者、AWS DevOps | | ROSA デプロイステージを追加します。 | 新しいパイプラインで、ステージを追加して ROSA クラスターにデプロイし、Jenkins グローバル設定に追加した ROSA クラスターを参照します。 | AWS 管理者、AWS DevOps、AWS システム管理者 | | 新しいビルドを開始します。 | Jenkins で、パイプラインを選択して **[Build now]** を選択するか、Git の `rosa-dev` ブランチに変更をコミットして新しいビルドを開始します。 | AWS 管理者、AWS DevOps、AWS システム管理者 | | デプロイメントを確認する。 | **oc** コマンドまたは [ROSA コンソール](https://console.aws.amazon.com/rosa)を使用して、アプリケーションがターゲット ROSA クラスターにデプロイされていることを確認します。 | AWS 管理者、AWS DevOps、AWS システム管理者 | | ターゲットクラスターにデータをコピーします。 | ステートフルワークロードの場合は、 AWS DataSync または **rsync** などのオープンソースユーティリティを使用して、ソースクラスターからターゲットクラスターにデータをコピーするか、MTC メソッドを使用できます。詳細については、[AWS DataSync のドキュメント](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)を参照してください。 | AWS 管理者、AWS DevOps、AWS システム管理者 | | アプリケーションをテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 管理者、AWS DevOps、AWS システム管理者 | | カットオーバーします。 | テストが成功した場合、適切な Amazon Route 53 ポリシーを使用して、トラフィックを ARO ホストアプリケーションから ROSA ホストアプリケーションに移動します。このステップを完了すると、アプリケーションのワークロードは ROSA クラスターに完全に移行されます。 | AWS 管理者、AWS システム管理者 | ### オプション 2: MTC を使用する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | MTC 演算子をインストールします。 | ARO クラスターと ROSA クラスターの両方に MTC 演算子をインストールします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 管理者、AWS DevOps、AWS システム管理者 | | ネットワークトラフィックをレプリケーションリポジトリに設定します。 | プロキシサーバーを使用している場合は、レプリケーションリポジトリとクラスター間のネットワークトラフィックを許可するように設定します。レプリケーションリポジトリは、MTC がデータを移行する際に使用する中間ストレージオブジェクトです。移行中、ソースクラスターとターゲットクラスターはレプリケーションリポジトリにネットワークアクセスできる必要があります。 | AWS 管理者、AWS DevOps、AWS システム管理者 | | MTC にソースクラスターを追加します。 | MTC ウェブコンソールで、ARO ソースクラスターを追加します。 | AWS 管理者、AWS DevOps、AWS システム管理者 | | レプリケーションリポジトリとして Amazon S3 を追加します。 | MTC ウェブコンソールで、Amazon S3 バケット (「[前提条件](#migrate-container-workloads-from-aro-to-rosa-prereqs)」を参照) をレプリケーションリポジトリとして追加します。 | AWS 管理者、AWS DevOps、AWS システム管理者 | | 移行プランを作成します。 | MTC ウェブコンソールで、移行プランを作成し、データ転送タイプとして **[Copy]** を指定します。これにより、MTC はソース (ARO) クラスターから S3 バケットにデータをコピーし、バケットからターゲット (ROSA) クラスターにデータをコピーするように指示されます。 | AWS 管理者、AWS DevOps、AWS システム管理者 | | 移行プランを実行します。 | **[Stage]** または **[Cutover]** オプションを使用して、移行プランを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 管理者、AWS DevOps、AWS システム管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 接続の問題 | コンテナワークロードを ARO から ROSA に移行する場合、移行を成功させるためには、解決する必要がある接続の問題が発生する可能性があります。移行中にこれらの接続の問題 (この表に記載) に対処するには、綿密な計画、ネットワークチームやセキュリティチームとの調整、徹底したテストが不可欠です。段階的な移行戦略を実装し、各ステップで接続を検証することで、潜在的な中断を最小限に抑え、ARO から ROSA へのスムーズな移行を実現できます。 | | ネットワーク設定の違い | ARO と ROSA では、仮想ネットワーク (VNet) 設定、サブネット、ネットワークポリシーなどのネットワーク設定が異なる場合があります。サービス間の適切な通信を行うには、ネットワーク設定が 2 つのプラットフォーム間で一致していることを確認してください。 | | セキュリティグループとファイアウォールルール | ROSA と ARO では、デフォルトのセキュリティグループとファイアウォールの設定が異なる場合があります。移行中にコンテナとサービス間の接続を維持する上で必要なトラフィックを許可するように、これらのルールを調整および更新してください。  | | IP アドレスと DNS の変更 | ワークロードを移行すると、IP アドレスと DNS 名が変更される場合があります。静的 IP または特定の DNS 名に依存するアプリケーションを再設定します。  | | 外部サービスアクセス | アプリケーションがデータベースや API などの外部サービスに依存している状態では、場合によっては、ROSA の新しいサービスと通信できるように接続設定を更新する必要があります。 | | Azure Private Link の設定 | ARO で Azure Private Link またはプライベートエンドポイントサービスを使用する場合、リソース間のプライベート接続を確保するように ROSA で同等の機能をセットアップする必要があります。 | | Site-to-Site VPN または Direct Connect のセットアップ | オンプレミスネットワークと ARO の間に既存の Site-to-Site VPN または Direct Connect 接続がある場合は、ローカルリソースとの中断のない通信のために、ROSA との同様の接続を確立する必要があります。 | | Ingress とロードバランサーの設定 | Ingress コントローラーとロードバランサーの設定は、ARO と ROSA で異なる場合があります。これらの設定を再構成して、サービスへの外部アクセスを維持します。 | | 証明書と TLS の処理 | アプリケーションで SSL 証明書または TLS を使用している場合、証明書が有効であり、ROSA で正しく設定されていることを確認します。 | | コンテナレジストリのアクセス | コンテナが外部コンテナレジストリでホストされている場合、ROSA に関する適切な認証とアクセス許可をセットアップします。 | | モニタリングとログ記録 | モニタリングとログ記録の設定を更新して、ROSA の新しいインフラストラクチャを反映し、コンテナのヘルスとパフォーマンスを継続的かつ効果的に監視できるようにします。 | ## 関連リソース **AWS**** のリファレンス** + [とは Red Hat OpenShift Service on AWS](https://docs.aws.amazon.com/ROSA/latest/userguide/what-is-rosa.html) (ROSA ドキュメント) + [Get started with ROSA](https://docs.aws.amazon.com/ROSA/latest/userguide/getting-started.html) (ROSA ドキュメント) + [Red Hat OpenShift Service on AWS 実装戦略](https://docs.aws.amazon.com/prescriptive-guidance/latest/red-hat-openshift-on-aws-implementation/) (AWS 規範ガイダンス) + [Red Hat OpenShift Service on AWS Now GA](https://aws.amazon.com/blogs/aws/red-hat-openshift-service-on-aws-now-generally-availably/) (AWS ブログ記事) + [ROSA Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/0-introduction) + [ROSA FAQ](https://aws.amazon.com/rosa/faqs/) + [ROSA Workshop FAQ](https://www.rosaworkshop.io/rosa/14-faq/) + [ROSA の料金](https://aws.amazon.com/rosa/pricing/) **Red Hat OpenShift ドキュメント** + [にクラスターをすばやくインストールする AWS](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-default.html) + [制限されたネットワーク AWS での へのクラスターのインストール](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-restricted-networks-aws-installer-provisioned.html) + [既存の VPC AWS に クラスターをインストールする](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-vpc.html) + [CloudFormation テンプレート AWS を使用して のユーザープロビジョニングインフラストラクチャにクラスターをインストールする](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-user-infra.html) + [ユーザーがプロビジョニングしたインフラストラクチャを使用して制限されたネットワーク AWS にクラスターをインストールする](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-restricted-networks-aws.html) + [カスタマイズ AWS を使用した へのクラスターのインストール](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-customizations.html) + [Getting started with the OpenShift CLI](https://docs.openshift.com/container-platform/4.13/cli_reference/openshift_cli/getting-started-cli.html) ## 追加情報 **MTC と CI/CD パイプラインの再デプロイオプションを選択する** ある OpenShift クラスターから別のクラスターにアプリケーションを移行するには、慎重に検討する必要があります。理想的には、CI/CD パイプラインを使用してアプリケーションを再デプロイし、永続ボリュームデータの移行を処理することで、スムーズな移行を行います。ただし、実際には、クラスター上で実行中のアプリケーションは、時間の経過とともに予期しない変更の影響を受けやすくなります。これらの変更により、アプリケーションが元のデプロイ状態から徐々に逸脱する可能性があります。名前空間の正確な内容が不明であり、すべてのアプリケーションコンポーネントを新しいクラスターにシームレスに移行することが重要であるシナリオの場合、MTC がソリューションを提供します。 適切な選択を行うには、特定のシナリオを評価し、各アプローチの利点を比較検討する必要があります。そうすることで、ニーズと優先順位に沿って、正常かつシームレスに移行できます。2 つのオプションから選択するための追加のガイドラインを以下に示します。 **CI/CD パイプラインの再デプロイ** パイプラインを使用してアプリケーションを確実に再デプロイできる場合、推奨されるアプローチは CI/CD パイプラインの使用です。これにより、移行が制御されて予測可能になり、既存のデプロイ方法と一致するようになります。この方法を選択すると、[ブルー/グリーンデプロイ](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html)またはカナリアデプロイ戦略を使用して、ROSA のデプロイにロードを徐々にシフトできます。このシナリオでは、このパターンは、Jenkins がオンプレミス環境からアプリケーションデプロイをオーケストレーションしていることを前提としています。 利点: + ソース ARO クラスターへの管理アクセスは必要ありません。また、ソースクラスターまたはターゲットクラスターに演算子をデプロイする必要もありません。 + このアプローチは、DevOps 戦略を使用することでトラフィックを徐々に切り替える場合に役立ちます。 欠点: + アプリケーションの機能をテストするには、より多くの労力が必要です。 + アプリケーションに永続データが含まれている場合は、 AWS DataSync または他のツールを使用してデータをコピーするための追加のステップが必要です。 **MTC の移行** 実際には、実行中のアプリケーションに予期しない変更が発生し、初期のデプロイから逸脱してしまうことがあります。ソースクラスター上に存在するアプリケーションの現在の状態が不明な場合、MTC オプションを選択します。例えば、アプリケーションエコシステムがさまざまなコンポーネント、設定、データストレージボリュームにまたがっている場合、アプリケーションとその環境全体をカバーする完全な移行を確実に実行するには、MTC を選択することをお勧めします。 利点: + MTC は、ワークロードの完全なバックアップと復元を提供します。 + ワークロードの移行中に、永続データをソースからターゲットにコピーします。 + ソースコードリポジトリへのアクセスを必要としません。 欠点: + ソースクラスターとターゲットクラスターに MTC 演算子をインストールするには、管理者特権が必要です。 + DevOps チームに、MTC ツールを使用して移行を実行するためのトレーニングが必要となります。 # Amazon ECS Anywhere を使用して Amazon WorkSpaces で Amazon ECS タスクを実行する *Akash Kumar、Amazon Web Services* ## 概要 Amazon Elastic Container Service (Amazon ECS) Anywhere は、Amazon Web Services (AWS) マネージドインフラストラクチャやカスタマーマネージドインフラストラクチャを含むあらゆる環境の Amazon ECS タスクのデプロイをサポートします。これは、クラウド上で稼働し、常に最新の状態に保たれる、完全に AWS マネージド型のコントロールプレーンを使用しながら行うことができます。  多くの場合、企業はコンテナベースのアプリケーションの開発に Amazon WorkSpaces を使用します。このため、ECS タスクをテストして実行するには、Amazon Elastic Compute Cloud (Amazon EC2) または Amazon ECS クラスターの AWS Fargate が必要でした。Amazon ECS Anywhere を使用することで、Amazon WorkSpaces を外部インスタンスとして ECS クラスターに直接追加できるようになり、タスクを直接実行できるようになりました。これにより、Amazon WorkSpaces のローカルの ECS クラスターを使用してコンテナをテストできるため、開発時間を短縮できます。コンテナアプリケーションのテストに EC2 または Fargate インスタンスを使用するコストを節約することもできます。 このパターンは、Amazon ECS Anywhere を使用して ECS タスクを Amazon WorkSpaces にデプロイする方法を示しています。ECS クラスターをセットアップし、AWS Directory Service Simple AD を使用して WorkSpaces を起動します。次に、サンプルの ECS タスクは WorkSpaces で NGINX を起動します。 ## 前提条件と制限事項 + アクティブな AWS アカウント + AWS コマンドラインインターフェイス (AWS CLI) + [マシンに設定されている](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) AWS 認証情報 ## アーキテクチャ **ターゲットテクノロジースタック** + 仮想プライベートクラウド (VPC) + Amazon ECS クラスター + Amazon WorkSpaces + Simple AD を使用した AWS Directory Service **ターゲットアーキテクチャ** ![\[ECS Anywhere は ECS クラスターをセットアップし、Simple AD を使用して WorkSpaces を起動します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/da8b2249-3423-485c-9fef-6f902025e969/images/fd354d14-f29b-4b9e-8f1a-c3cb7ed4d6bf.png) このアーキテクチャには、以下のサービスとリソースが含まれます。 + カスタム VPC にパブリックサブネットとプライベートサブネットを持つ ECS クラスター + Amazon WorkSpaces へのユーザーアクセスを提供するための VPC 内の Simple AD + Simple AD を使用して VPC にプロビジョニングされた Amazon WorkSpaces + Amazon WorkSpaces をマネージドインスタンスとして追加するために AWS Systems Manager がアクティブ化されました + Amazon ECS と AWS Systems Manager Agent (SSM Agent) を使用して、Amazon WorkSpaces がSystems Manager と ECS クラスターに追加されました + ECS クラスターの WorkSpaces で実行する ECS タスクの例 ## ツール + [AWS Directory Service Simple Active Directory (Simple AD) ](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_simple_ad.html) は、Samba 4 Active Directory 互換サーバーを搭載したスタンドアロンの管理対象ディレクトリです。Simple AD では、AWS Managed Microsoft AD が提供する機能のサブセットを使用できます。例えば、ユーザーを管理する機能や Amazon EC2 インスタンスに安全に接続する機能などがあります。 + [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) は、クラスターでコンテナの実行、停止、管理をサポートする、高速でスケーラブルなコンテナ管理サービスです。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + 「[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)」は、AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。アプリケーションとリソースの管理が簡略化され、オペレーション上の問題の検出と解決時間が短縮され、AWS リソースを大規模かつセキュアに管理できるようになります。 + [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html) は、*WorkSpaces* として知られる、クラウドベースの仮想 Microsoft Windows または Amazon Linux デスクトップをユーザーにプロビジョニングするのに役立ちます。WorkSpaces は、ハードウェアの調達とデプロイ、または複雑なソフトウェアのインストールの必要性を排除します。 ## エピック ### ECS クラスターをセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ECS クラスターを作成して設定する。 | ECS クラスターを作成するには、次の手順を含む [AWS ドキュメント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html)の指示に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere.html) | クラウドアーキテクト | ### Amazon WorkSpaces を起動する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Simple AD をセットアップし、Amazon WorkSpaces を起動します。 | 新しく作成した VPC に Simple AD ディレクトリをプロビジョニングして Amazon WorkSpaces を起動するには、[AWS ドキュメント](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspace-simple-ad.html)の指示に従ってください。 | クラウドアーキテクト | ### ハイブリッド環境用に AWS Systems Manager をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 添付のスクリプトをダウンロードしてください。 | ローカルマシンで、「*添付ファイル*」セクションにある `ssm-trust-policy.json` および `ssm-activation.json` ファイルをダウンロードします。 | クラウドアーキテクト | | IAM ロールを追加します。 | ビジネス要件に基づいて環境変数を追加します。
export AWS_DEFAULT_REGION=${AWS_REGION_ID}
export ROLE_NAME=${ECS_TASK_ROLE}
export CLUSTER_NAME=${ECS_CLUSTER_NAME}
export SERVICE_NAME=${ECS_CLUSTER_SERVICE_NAME}
以下のコマンドを実行してください。
aws iam create-role --role-name $ROLE_NAME --assume-role-policy-document file://ssm-trust-policy.json
| クラウドアーキテクト | | AmazonSSMManagedInstanceCore ポリシーを IAM ロールに追加します。 | 以下のコマンドを実行してください。
aws iam attach-role-policy --role-name $ROLE_NAME --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
| クラウドアーキテクト | | [AmazonEC2ContainerServiceforEC2Role] ポリシーを IAM ロールに追加します。 | 以下のコマンドを実行してください。
aws iam attach-role-policy --role-name $ROLE_NAME --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
| クラウドアーキテクト | | IAM ロールを検証します。 | 次のコマンドを実行して、IAM ロールを検証します。
aws iam list-attached-role-policies --role-name $ROLE_NAME
| クラウドアーキテクト | | Systems Manager を起動します。 | 以下のコマンドを実行してください。
aws ssm create-activation --iam-role $ROLE_NAME | tee ssm-activation.json
| クラウドアーキテクト | ### ECS クラスターにWorkSpaces を追加 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | WorkSpaces に接続します。 | ワークスペースに接続して設定するには、[AWS ドキュメント](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html)の指示に従ってください。 | アプリ開発者 | | ecs-anywhere インストールスクリプトをダウンロードします。 | コマンドプロンプトで、次のコマンドを入力します。
curl -o "ecs-anywhere-install.sh" "https://amazon-ecs-agent-packages-preview.s3.us-east-1.amazonaws.com/ecs-anywhere-install.sh" && sudo chmod +x ecs-anywhere-install.sh
| アプリ開発者 | | シェルスクリプトの整合性をチェックしてください。 | (オプション) 次のコマンドを実行します。
curl -o "ecs-anywhere-install.sh.sha256" "https://amazon-ecs-agent-packages-preview.s3.us-east-1.amazonaws.com/ecs-anywhere-install.sh.sha256" && sha256sum -c ecs-anywhere-install.sh.sha256


| アプリ開発者 | | Amazon Linux に EPEL リポジトリを追加します。 | Enterprise Linux (EPEL) リポジトリに追加パッケージを追加するには、コマンド `sudo amazon-linux-extras install epel -y` を実行します。 | アプリ開発者 | | Amazon ECS Anywhere にインストールできます。 | インストールスクリプトを実行するには、次のコマンドを使用します。
sudo ./ecs-anywhere-install.sh --cluster $CLUSTER_NAME --activation-id $ACTIVATION_ID --activation-code $ACTIVATION_CODE --region $AWS_REGION


| | | ECS クラスターのインスタンス情報を確認します。 | Systems Manager と ECS クラスターインスタンスの情報を確認し、WorkSpaces がクラスターに追加されたことを確認するには、ローカルマシンで次のコマンドを実行します。
aws ssm describe-instance-information" && "aws ecs list-container-instances --cluster $CLUSTER_NAME
| アプリ開発者 | ### WorkSpaces に ECS タスクを追加 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | タスク実行 IAM ロールを作成するには | 「*添付ファイル*」セクションから `task-execution-assume-role.json` および `external-task-definition.json` をダウンロードします。 ローカルマシンで次のコマンドを実行します。
aws iam --region $AWS_DEFAULT_REGION create-role --role-name $ECS_TASK_EXECUTION_ROLE --assume-role-policy-document file://task-execution-assume-role.json
| クラウドアーキテクト | | ポリシーを実行ロールに追加します。 | 以下のコマンドを実行してください。
aws iam --region $AWS_DEFAULT_REGION attach-role-policy --role-name $ECS_TASK_EXECUTION_ROLE --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
| クラウドアーキテクト | | タスクロールを作成します。 | 以下のコマンドを実行してください。
aws iam --region $AWS_DEFAULT_REGION create-role --role-name $ECS_TASK_EXECUTION_ROLE --assume-role-policy-document file://task-execution-assume-role.json


| クラウドアーキテクト | | タスク定義をクラスターに登録します。 | ローカルマシンで次のコマンドを実行します。
aws ecs register-task-definition --cli-input-json file://external-task-definition.json
| クラウドアーキテクト | | タスクを実行します。 | ローカルマシンで次のコマンドを実行します。
aws ecs run-task --cluster $CLUSTER_NAME --launch-type EXTERNAL --task-definition nginx
| クラウドアーキテクト | | タスクの実行状態を検証します。 | タスク ID を取得するには、次のコマンドを実行します。
export TEST_TASKID=$(aws ecs list-tasks --cluster $CLUSTER_NAME | jq -r '.taskArns[0]')
タスク ID を使用して、次のコマンドを実行します。
aws ecs describe-tasks --cluster $CLUSTER_NAME --tasks ${TEST_TASKID}
| クラウドアーキテクト | | WorkSpace でタスクを確認します。 | NGINX が WorkSpace で実行されていることを確認するには、コマンド ` curl http://localhost:8080` を実行します。 | アプリ開発者 | ## 関連リソース + [ECS クラスター](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html) + [ハイブリッド環境の設定](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html) + [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html) + [Simple AD](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspace-simple-ad.html) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/da8b2249-3423-485c-9fef-6f902025e969/attachments/attachment.zip)」 # Amazon EC2 Linux インスタンスで ASP.NET Core ウェブ API Docker コンテナを実行する *Amazon Web Services、Vijai Anand Ramalingam、Sreelaxmi Pai* ## 概要 このパターンは、Amazon Web Services (AWS) クラウドでアプリケーションのコンテナ化を始めるユーザーを対象としています。クラウド上でアプリケーションのコンテナ化を始める場合、通常、コンテナオーケストレーションプラットフォームは設定されていません。このパターンは、複雑なコンテナオーケストレーションインフラストラクチャを必要とせずに、コンテナ化されたアプリケーションをテストするためのインフラストラクチャを AWS にすばやくセットアップするのに役立ちます。 モダナイゼーションの最初のステップでは、アプリケーションを変換します。レガシー .NET Framework アプリケーションの場合は、まず、ランタイムを ASP.NET Core に変更する必要があります。次に、以下の操作を実行します。 + Docker コンテナイメージを作成する + ビルドされたイメージを使用して Docker コンテナを実行する + Amazon Elastic Container Service (Amazon ECS) またはAmazon Elastic Kubernetes Service (Amazon EKS) のような コンテナオーケストレーションプラットフォームにアプリケーションをデプロイする前に、アプリケーションを検証します。  このパターンでは、Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスでの最新のアプリケーション開発の構築、実行、検証の各側面を扱います。 ## 前提条件と制限事項 **前提条件** + アクティブな [Amazon Web Services (AWS) アカウント](https://aws.amazon.com/account/) + このパターンの AWS リソースを作成するのに十分なアクセス権を持つ [AWS Identity and Access Management (IAM) ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)  + [Visual Studio Community 2022](https://visualstudio.microsoft.com/downloads/) 以降をダウンロードしてインストール済み + ASP.NET Core にモダナイズされた .NET Framework プロジェクト + GitHub リポジトリ **製品バージョン** + Visual Studio Community 2022 以降 ## アーキテクチャ **ターゲット アーキテクチャ** このパターンでは、[AWS CloudFormation テンプレート](https://console.aws.amazon.com/cloudformation/home?region=us-east-2#/stacks/new?stackName=SSM-SSH-Demo&templateURL=https://aws-quickstart.s3.amazonaws.com/quickstart-examples/samples/session-manager-ssh/session-manager-example.yaml)を使用して、次の図に示す高可用性アーキテクチャを作成します。Amazon EC2 Linux インスタンスはプライベートサブネットで起動されます。AWS Systems Manager Session Manager は、プライベート Amazon EC2 Linux インスタンスにアクセスし、Docker コンテナで実行されている API をテストするために使用されます。 ![\[Amazon EC2 Linux インスタンスにアクセスし、Docker コンテナで実行されている API をテストするユーザー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/512e61b2-10ba-43be-bbd8-2bdc597c3de3/images/9c5206f6-32b1-47be-9037-360c0bff713c.png) 1. セッションマネージャーから Linux インスタンスにアクセスする ## ツール **AWS サービス** + [AWS コマンドラインインターフェイス](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) — AWS コマンドラインインターフェイス (AWS CLI) はオープンソースのツールで、コマンドラインシェルのコマンドで AWS サービスとやり取りします。最小限の設定で、ブラウザベースの AWS マネジメントコンソールで提供される機能と同等の機能を実装する AWS CLI コマンドを実行できます。 + [AWS マネジメントコンソール](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/learn-whats-new.html) – AWS マネジメントコンソールは、AWS リソースを管理するためのサービスコンソールの広範なコレクションで構成され、そのコレクションを参照するウェブアプリケーションです。最初にサインインすると、コンソールのホームページが表示されます。各サービスコンソールにアクセスできるホームページは、AWS に関連するタスクを実行するために必要な情報に 1 か所からアクセスできます。 + [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) — Session Manager はフルマネージド型の AWS Systems Manager 機能です。Session Manager を使用すれば、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス を管理できます。Session Manager は、受信ポートを開いたり、踏み台ホストを維持したり、SSH キーを管理したりすることなく、セキュアで監査可能なノード管理を提供します。 **その他のツール** + [Visual Studio 2022](https://visualstudio.microsoft.com/downloads/) — Visual Studio 2022 は統合開発環境 (IDE) です。 + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしてのPlatform as a Service (PaaS) 製品のセットです。 **コード** ``` FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base WORKDIR /app EXPOSE 80 EXPOSE 443 FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build WORKDIR /src COPY ["DemoNetCoreWebAPI/DemoNetCoreWebAPI.csproj", "DemoNetCoreWebAPI/"] RUN dotnet restore "DemoNetCoreWebAPI/DemoNetCoreWebAPI.csproj" COPY . . WORKDIR "/src/DemoNetCoreWebAPI" RUN dotnet build "DemoNetCoreWebAPI.csproj" -c Release -o /app/build FROM build AS publish RUN dotnet publish "DemoNetCoreWebAPI.csproj" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "DemoNetCoreWebAPI.dll"] ``` ## エピック ### ASP.NET Core ウェブ API を開発する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Visual Studio を使用して ASP.NET Core ウェブ API のサンプルを作成します。 | ASP.NET Core ウェブ API のサンプルを作成するには、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | アプリ開発者 | | Dockerfile を作成します。 | Dockerfile を作成するには、以下のいずれかの操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html)変更を GitHub リポジトリにプッシュするには、次のコマンドを実行します。
git add --all
git commit -m "Dockerfile added"
git push
| アプリ開発者 | ### Amazon EC2 Linux インスタンスをセットアップする。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インフラストラクチャを設定します。 | [AWS CloudFormation テンプレート](https://console.aws.amazon.com/cloudformation/home?region=us-east-2#/stacks/new?stackName=SSM-SSH-Demo&templateURL=https://aws-quickstart.s3.amazonaws.com/quickstart-examples/samples/session-manager-ssh/session-manager-example.yaml)を起動して、以下を含むインフラストラクチャを作成します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html)踏み台ホストを必要とせずに Session Manager を使用してプライベート Amazon EC2 インスタンスにアクセスする方法の詳細については、「[踏み台のない世界へ](https://aws.amazon.com/blogs/infrastructure-and-automation/toward-a-bastion-less-world/)」というブログ投稿を参照してください。 | アプリ開発者、AWS 管理者、AWS DevOps | | Amazon EC2 Linux インスタンスにログインします。 | プライベートサブネットの Amazon EC2 Linux インスタンスに接続するには、以下の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | アプリ開発者 | | Docker をインストールして実行します。 | Amazon EC2 Linux インスタンスに Docker をインストールして起動するには、以下の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | アプリ開発者、AWS 管理者、AWS DevOps | | GitHub をインストールして、リポジトリのクローンを作成します。 | Amazon EC2 Linux インスタンスに Git をインストールし、GitHub からリポジトリをクローンするには、以下の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | アプリ開発者、AWS 管理者、AWS DevOps | | Docker コンテナをローカルで構築して実行します。 | Docker イメージを構築し、Amazon EC2 Linux インスタンス内でコンテナを実行するには、次の手順に従います。　[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | アプリ開発者、AWS 管理者、AWS DevOps | ### ウェブ API をテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | curl コマンドを使用して、ウェブ API をテストします。 | ウェブ API をテストするには、次のコマンドを使用します。
curl -X GET "http://localhost/WeatherForecast" -H  "accept: text/plain"
API レスポンスを確認してください。Swagger をローカルで実行している場合、各エンドポイントの curl コマンドは Swagger から取得できます。 | アプリ開発者 | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースを削除します。 | スタックを削除してすべてのリソースを削除します。これにより、利用していないサービスに料金を支払うことはありません。 | AWS 管理者、AWS DevOps | ## 関連リソース + 「[PuTTY を使用した Windows から Linux インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html)」 + 「[ASP.NET コアを使用してウェブ API を作成する](https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio)」 + 「[踏み台のない世界へ](https://aws.amazon.com/blogs/infrastructure-and-automation/toward-a-bastion-less-world/)」 # AWS Fargate 搭載の Amazon EKS で Amazon EFS を使用して、永続的なデータストレージでステートフルワークロードを実行する *Ricardo Morais、Rodrigo Bersa、Lucio Pereira、Amazon Web Services* ## 概要 このパターンは、AWS Fargate を使用してコンピュートリソースをプロビジョニングすることで、Amazon Elastic File System (Amazon EFS) で実行中のコンテナのストレージデバイスとして Amazon Elastic Kubernetes Service (Amazon EKS) を有効化するためのガイダンスを提供します。 このパターンで説明する設定は、セキュリティのベストプラクティスに従い、デフォルトで保管時と転送時のセキュリティを提供します。Amazon EFS ファイルシステムを暗号化するには、AWS Key Management Service (AWS KMS) キーを使用しますが、KMS キーの作成プロセスをディスパッチするキーエイリアスも指定できます。 このパターンの手順に従って、概念実証 (PoC) アプリケーションの名前空間と Fargate プロファイルを作成し、Kubernetes クラスターを Amazon EFS と統合するために使用される Amazon EFS コンテナストレージインターフェイス (CSI) ドライバーをインストールし、ストレージクラスを設定し、PoC アプリケーションをデプロイできます。これらの手順により、Fargate 上で実行中の Amazon EFS ファイルシステムが複数の Kubernetes ワークロード間で共有されます。このパターンには、これらの手順を自動化するスクリプトが付属しています。 このパターンは、コンテナ化されたアプリケーションでデータの永続性を確保し、スケール操作でのデータ損失を回避する場合に使用できます。例えば、次のようになります。 + **DevOps ツール** — 一般的なシナリオは、継続的インテグレーションおよび継続的デリバリー (CI/CD) 戦略を開発することです。この場合、Amazon EFS を共有ファイルシステムとして使用して、CI/CD ツールのさまざまなインスタンス間で設定を保存、または CI/CD ツールのさまざまなインスタンス間のパイプラインステージ用のキャッシュ (例、Apache Maven リポジトリ) を保存できます。 + **Web サーバー** — 一般的なシナリオは、Apache を HTTP Web サーバーとして使用することです。Amazon EFS を共有ファイルシステムとして使用して、Web サーバーのさまざまなインスタンス間で共有される静的ファイルを保存できます。このシナリオ例では、静的ファイルが Docker イメージにベイクされるのではなく、変更がファイルシステムに直接適用されます。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + バージョン 1.17 以降 (バージョン 1.27 までテスト済み) を搭載している既存の Kubernetes Amazon EKS クラスター + Kubernetes StorageClass をバインドし、ファイルシステムを動的にプロビジョニングする既存の Amazon EFS ファイルシステム + クラスター管理権限 + 目的の Amazon EKS クラスターを指すように設定されたコンテキスト **制限** + Fargate で Amazon EKS を使用する際には、考慮すべき制限がいくつかあります。例えば、DaemonSets や特権コンテナなどの一部の Kubernetes コンストラクトの使用はサポートされていません。Fargate の制限に関する詳細については、Amazon EKS ドキュメントの「[AWS Fargate 考慮事項](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html#fargate-considerations)」を参照してください。 + このパターンで提供されるコードは、Linux または macOS を実行中のワークステーションをサポートします。 **製品バージョン** + AWS コマンドラインインターフェイス (AWS CLI)バージョン 2 以降 + Amazon EFS CSI ドライバーバージョン 1.0 以降 (バージョン 2.4.8 までテスト済み) + eksctl バージョン 0.24.0 以降 (バージョン 0.158.0 までテスト済み) + jq バージョン 1.6 以降 + kubectl バージョン 1.17 以降 (バージョン 1.27 までテスト済み) + Kubernetes バージョン 1.17 以降 (バージョン 1.27 までテスト済み) ## アーキテクチャ ![\[Amazon EFS を使用して永続的データストレージでステートフルワークロードを実行するアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/2487e285-269b-415b-a270-877f973e3aaf/images/ec8de63c-3307-4010-9e03-2bd7b9881fff.png) ターゲットアーキテクチャは、次のインフラストラクチャで構成されます。 + 仮想プライベートクラウド (VPC) + 2 つのアベイラビリティーゾーン + インターネットアクセスを提供する NAT ゲートウェイを持つパブリックサブネット + Amazon EKS クラスターと Amazon EFS マウントターゲット (*マウントポイント*としても知られています) を持つプライベートサブネット + VPC レベルでの Amazon EFS 以下は、Amazon EKS クラスターの環境インフラストラクチャです。 + 名前空間レベルで Kubernetes コンストラクトに対応する AWS Fargate プロファイル + 以下を含む Kubernetes 名前空間: + アベイラビリティーゾーンに分散された 2 つのアプリケーションポッド + クラスターレベルで永続ボリューム (PV) にバインドされた 1 つの永続ボリューム要求 (PVC) + 名前空間の PVC にバインドされ、クラスター外のプライベートサブネットの Amazon EFS マウントターゲットを指すクラスター全体の PV ## ツール **AWS サービス** + [AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインから AWS サービスとインタラクトできるオープンソースツールです。 + [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) は、AWS クラウドでの共有ファイルシステムの作成と設定に役立ちます。このパターンでは、Amazon EKS で使用するシンプルで、スケーラブルな完全マネージド型の共有ファイルシステムを提供します。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) を使用すると、独自のクラスターをインストールまたは操作することなく、AWS で Kubernetes を実行できます。 + [AWS Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html) は Amazon EKS 用のサーバーレスコンピュートエンジンです。Kubernetes アプリケーションのコンピュートリソースを作成および管理します。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に効果的な暗号キーを作成および管理する上で役立ちます。 **その他のツール** + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしての Platform as a Service (PaaS) 製品のセットです。 + [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) – これは Amazon EKS で Kubernetes クラスターを作成および管理するコマンドラインユーティリティです。 + [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)は、Kubernetes クラスターに対してコマンドを実行するためのコマンドラインインターフェイスです。 + [jq](https://stedolan.github.io/jq/download/) は JSON を構文解析するコマンドラインツールです。 **Code** このパターンのコードは、GitHub の「[Persistence Configuration with Amazon EFS on Amazon EKS using AWS Fargate](https://github.com/aws-samples/eks-efs-share-within-fargate)」リポジトリで提供されています。スクリプトはエピック別に `epic01` から `epic06` までのフォルダにまとめられ、このパターンの「[エピック](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-epics)」セクションの順序に対応しています。 ## ベストプラクティス ターゲットアーキテクチャには、以下のサービスとコンポーネントが含まれ、[AWS Well-Architected フレームワーク](https://aws.amazon.com/architecture/well-architected/)のベストプラクティスに従います。 + Amazon EFS は、シンプルで、スケーラブル、伸縮性のあるフルマネージド型の NFS ファイルシステムです。これは、選択した Amazon EKS クラスターのプライベートサブネットに分散される、ポッドで実行中の PoC アプリケーションのすべてのレプリケーションの共有ファイルシステムとして使用されます。 + 各プライベートサブネットの Amazon EFS マウントターゲット。これにより、クラスターの仮想プライベートクラウド (VPC) 内のアベイラビリティーゾーンごとの冗長性が確保されます。 + Amazon EKS は Kubernetes ワークロードを実行します。[前提条件](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-prereqs)セクションで説明したように、このパターンを使用する前に Amazon EKS クラスターをプロビジョニングする必要があります。 + AWS KMS は、Amazon EFS ファイルシステムに保存されているコンテンツを保存時に暗号化します。 + Fargate は、コンテナのコンピュートリソースを管理するため、お客様はインフラストラクチャに負担をかけずにビジネス要件に集中できます。Fargate プロファイルはすべてのプライベートサブネットに作成されます。クラスターの仮想プライベートクラウド (VPC) 内のアベイラビリティーゾーンごとに冗長性を提供します。 + Kubernetes ポッドは、アプリケーションのさまざまなインスタンスがコンテンツを共有、利用、書き込みできることを検証します。 ## エピック ### Amazon EKS クラスターをプロビジョニングする (オプション) | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EKS クラスターを作成します。 | クラスターが既にデプロイされている場合は、次のエピックに進みます。既存の AWS アカウントに Amazon EKS クラスターを作成します。[GitHub ディレクトリ](https://github.com/aws-samples/eks-efs-share-within-fargate/tree/master/bootstrap)で、いずれかのパターンを使用し、Terraform または eksctl を使用して Amazon EKS クラスターをデプロイします。詳細については、Amazon EKS ドキュメントの [Amazon EKS クラスターを作成](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)を参照してください。Terraform パターンには、Fargate プロファイルを Amazon EKS クラスターにリンクし、Amazon EFS ファイルシステムを作成し、Amazon EKS クラスターに Amazon EFS CSI ドライバーをデプロイする方法を示す例もあります。 | AWS 管理者、Terraform または eksctl 管理者、Kubernetes 管理者 | | 環境変数をエクスポートします。 | env.sh スクリプトを実行します。これにより、次のステップで必要な情報が提供されます。
source ./scripts/env.sh
Inform the AWS Account ID:
<13-digit-account-id>
Inform your AWS Region:

Inform your Amazon EKS Cluster Name:

Inform the Amazon EFS Creation Token:
まだ確認していない場合は、次の CLI コマンドを使用して、上記でリクエストされたすべての情報を取得できます。
# ACCOUNT ID
aws sts get-caller-identity --query "Account" --output text
# REGION CODE
aws configure get region
# CLUSTER EKS NAME
aws eks list-clusters --query "clusters" --output text
# GENERATE EFS TOKEN
uuidgen
| AWS システム管理者 | ### Kubernetes 名前空間とリンクされた Fargate プロファイルを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションワークロード用に Kubernetes 名前空間と Fargate プロファイルを作成します。 | Amazon EFS とインタラクトするアプリケーションワークロードを受信する名前空間を作成します。`create-k8s-ns-and-linked-fargate-profile.sh` スクリプトを実行します。カスタム名前空間名を使用するか、デフォルトで指定された名前空間 `poc-efs-eks-fargate` を使用するかを選択できます。**カスタムアプリケーション名前空間名がある場合:**
export $APP_NAMESPACE=
./scripts/epic01/create-k8s-ns-and-linked-fargate-profile.sh \
-c "$CLUSTER_NAME" -n "$APP_NAMESPACE"
**カスタムアプリケーション名前空間名がない場合:**
./scripts/epic01/create-k8s-ns-and-linked-fargate-profile.sh \
    -c "$CLUSTER_NAME"
ここで、`$CLUSTER_NAME` は Amazon EKS クラスターの名前です。`-n ` パラメータはオプションです。通知されない場合は、デフォルトで生成された名前空間名が提供されます。 | 権限が付与された Kubernetes ユーザー | ### Amazon EFS ファイルシステムを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 一意のトークンを生成します。 | Amazon EFS では冪等オペレーションを保証する作成トークンが必要です (同じ作成トークンでオペレーションを呼び出しても効果はありません)。この要件を満たすには、利用可能な方法で一意のトークンを生成する必要があります。例えば、作成トークンとして使用する汎用一意識別子 (UUID) を生成できます。 | AWS システム管理者 | | Amazon EFS ファイルシステムを作成します。 | アプリケーションワークロードによって読み書きされるデータファイルを受信するファイルシステムを作成します。暗号化されたファイルシステムまたは暗号化されていないファイルシステムを作成できます。(ベストプラクティスとして、このパターンのコードはデフォルトで保存時の暗号化を有効化する暗号化システムを作成します。) 一意の対称 AWS KMS キーを使用して、ファイルシステムを暗号化できます。カスタムキーを指定しない場合は、AWS マネージドキーが使用されます。Amazon EFS 用の一意のトークンを生成した後、create-efs.sh スクリプトを使用して暗号化された、または暗号化されていない Amazon EFS ファイルシステムを作成します。**KMS キーを使用しないで保存時に暗号化する場合:**
./scripts/epic02/create-efs.sh \
    -c "$CLUSTER_NAME" \
    -t "$EFS_CREATION_TOKEN"
ここで、`$CLUSTER_NAME` は Amazon EKS クラスターの名前、`$EFS_CREATION_TOKEN` はファイルシステムの一意の作成トークンです。**KMS キーを使用して保存時に暗号化する場合:**
./scripts/epic02/create-efs.sh \
    -c "$CLUSTER_NAME" \
    -t "$EFS_CREATION_TOKEN" \
    -k "$KMS_KEY_ALIAS"
ここで、`$CLUSTER_NAME` は Amazon EKS クラスターの名前、`$EFS_CREATION_TOKEN` はファイルシステムの一意の作成トークン、`$KMS_KEY_ALIAS` は KMS キーのエイリアスです。**暗号化しない場合:**
./scripts/epic02/create-efs.sh -d \
    -c "$CLUSTER_NAME" \
    -t "$EFS_CREATION_TOKEN"
ここで、`$CLUSTER_NAME` は Amazon EKS クラスターの名前、`$EFS_CREATION_TOKEN` はファイルシステムの一意の作成トークン、`–d` は保存時の暗号化を無効にします。 | AWS システム管理者 | | セキュリティグループを作成します。 | Amazon EKS クラスターが Amazon EFS ファイルシステムにアクセスできるようにするセキュリティグループを作成します。 | AWS システム管理者 | | セキュリティグループのインバウンドルールを更新します。 | セキュリティグループのインバウンドルールを更新して、以下の設定で受信トラフィックを許可します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate.html) | AWS システム管理者 | | 各プライベートサブネットのマウントターゲットを追加します。 | Kubernetes クラスターの各プライベートサブネットに、ファイルシステムとセキュリティグループのマウントターゲットを作成します。 | AWS システム管理者 | ### Amazon EFS コンポーネントを Kubernetes クラスターにインストールします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EFS CSI ドライバーをデプロイします。 | Amazon EFS CSI ドライバーをクラスターにデプロイします。ドライバーは、アプリケーションが作成した永続ボリューム要求に従ってストレージをプロビジョニングします。`create-k8s-efs-csi-sc.sh` スクリプトを実行して、Amazon EFS CSI ドライバーとストレージクラスをクラスターにデプロイします。
./scripts/epic03/create-k8s-efs-csi-sc.sh
このスクリプトは `kubectl` ユーティリティを使用するため、コンテキストが設定され、目的の Amazon EKS クラスターを指していることを確認してください。 | 権限が付与された Kubernetes ユーザー | | ストレージクラスをデプロイします。 | Amazon EFS プロビジョナー (efs.csi.aws.com) のクラスターにストレージクラスをデプロイします。 | 権限が付与された Kubernetes ユーザー | ### PoC アプリケーションを Kubernetes クラスターにインストールします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 永続的ボリュームをデプロイします。 | 永続ボリュームをデプロイし、作成したストレージクラスと Amazon EFS ファイルシステムの ID にリンクします。アプリケーションは永続ボリュームを使用してコンテンツの読み取りと書き込みをします。ストレージフィールドでは任意のサイズの永続ボリュームを指定できます。Kubernetes ではこのフィールドが必要ですが、Amazon EFS は伸縮性のあるファイルシステムであるため、ファイルシステムの容量は強制しません。永続ボリュームは暗号化の有無にかかわらずデプロイできます。(Amazon EFS CSI ドライバーは、ベストプラクティスとしてデフォルトで暗号化が有効化されています。) `deploy-poc-app.sh` スクリプトを実行して、永続ボリューム、永続ボリューム要求、および 2 つのワークロードをデプロイします。転送時の暗号化の場合:
./scripts/epic04/deploy-poc-app.sh \
    -t "$EFS_CREATION_TOKEN"
ここで、`$EFS_CREATION_TOKEN` はファイルシステムの一意の作成トークンです。転送時に暗号化しない場合:
./scripts/epic04/deploy-poc-app.sh -d \
    -t "$EFS_CREATION_TOKEN"
ここで、`$EFS_CREATION_TOKEN` はファイルシステムの一意の作成トークンで、`–d` は転送時の暗号化を無効化します。 | 権限が付与された Kubernetes ユーザー | | アプリケーションが要求した永続ボリューム要求をデプロイします。 | アプリケーションが要求した永続ボリューム要求をデプロイし、ストレージクラスにリンクします。前に作成した永続ボリュームと同じアクセスモードを使用します。ストレージフィールドでは任意のサイズの永続ボリューム要求を指定できます。Kubernetes ではこのフィールドが必要ですが、Amazon EFS は伸縮性のあるファイルシステムであるため、ファイルシステムの容量は強制しません。 | 権限が付与された Kubernetes ユーザー | | ワークロード 1 をデプロイします。 | アプリケーションのワークロード 1 を表すポッドをデプロイします。このワークロードは `/data/out1.txt` ファイルにコンテンツを書き込みます。 | 権限が付与された Kubernetes ユーザー | | ワークロード 2 をデプロイします。 | アプリケーションのワークロード 2 を表すポッドをデプロイします。このワークロードは `/data/out2.txt` ファイルにコンテンツを書き込みます。 | 権限が付与された Kubernetes ユーザー | ### ファイルシステムの永続性、耐久性、共有性を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `PersistentVolume` のステータスを確認します。 | `PersistentVolume` のステータスを確認するには、次のコマンドを入力します。
kubectl get pv
出力の例として、「[追加情報](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-additional)」セクションを参照してください。 | 権限が付与された Kubernetes ユーザー | | `PersistentVolumeClaim` のステータスを確認します。 | `PersistentVolumeClaim` のステータスを確認するには、次のコマンドを入力します。
kubectl -n poc-efs-eks-fargate get pvc
出力の例として、「[追加情報](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-additional)」セクションを参照してください。 | 権限が付与された Kubernetes ユーザー | | ワークロード 1 がファイルシステムに書き込みできることを確認します。 | 次のコマンドを入力して、ワークロード 1 が `/data/out1.txt` に書き込んでいることを検証します。
kubectl exec -ti poc-app1 -n poc-efs-eks-fargate -- tail -f /data/out1.txt
結果は次のようになります。
...
Thu Sep  3 15:25:07 UTC 2023 - PoC APP 1
Thu Sep  3 15:25:12 UTC 2023 - PoC APP 1
Thu Sep  3 15:25:17 UTC 2023 - PoC APP 1
...
| 権限が付与された Kubernetes ユーザー | | ワークロード 2 がファイルシステムに書き込みできることを確認します。 | 次のコマンドを入力して、ワークロード 2 が `/data/out2.txt` に書き込んでいることを検証します。
kubectl -n $APP_NAMESPACE exec -ti poc-app2 -- tail -f /data/out2.txt
結果は次のようになります。
...
Thu Sep  3 15:26:48 UTC 2023 - PoC APP 2
Thu Sep  3 15:26:53 UTC 2023 - PoC APP 2
Thu Sep  3 15:26:58 UTC 2023 - PoC APP 2
...
| 権限が付与された Kubernetes ユーザー | | ワークロード 1 がワークロード 2 によって書き込まれたファイルを読み取れることを検証します。 | ワークロード 1 がワークロード 2 によって書き込まれた `/data/out2.txt` ファイルを読み取れることを検証するには、以下のコマンドを入力します。
kubectl exec -ti poc-app1 -n poc-efs-eks-fargate -- tail -n 3 /data/out2.txt
結果は次のようになります。
...
Thu Sep  3 15:26:48 UTC 2023 - PoC APP 2
Thu Sep  3 15:26:53 UTC 2023 - PoC APP 2
Thu Sep  3 15:26:58 UTC 2023 - PoC APP 2
...
| 権限が付与された Kubernetes ユーザー | | ワークロード 2 がワークロード 1 によって書き込まれたファイルを読み取れることを検証します。 | ワークロード 2 がワークロード 1 によって書き込まれた `/data/out1.txt` ファイルを読み取れることを検証するには、以下のコマンドを入力します。
kubectl -n $APP_NAMESPACE exec -ti poc-app2 -- tail -n 3 /data/out1.txt
結果は次のようになります。
...
Thu Sep  3 15:29:22 UTC 2023 - PoC APP 1
Thu Sep  3 15:29:27 UTC 2023 - PoC APP 1
Thu Sep  3 15:29:32 UTC 2023 - PoC APP 1
...
| 権限が付与された Kubernetes ユーザー | | アプリケーションコンポーネントを削除する後もファイルが保持されることを確認します。 | 次に、スクリプトを使用してアプリケーションコンポーネント (永続ボリューム、永続ボリューム要求、ポッド) を削除し、ファイル `/data/out1.txt` と `/data/out2.txt` がファイルシステムに保持されていることを確認します。次のコマンドを使用して、`validate-efs-content.sh` スクリプトを実行します。
./scripts/epic05/validate-efs-content.sh \
    -t "$EFS_CREATION_TOKEN"
ここで、`$EFS_CREATION_TOKEN` はファイルシステムの一意の作成トークンです。結果は次のようになります。
pod/poc-app-validation created
Waiting for pod get Running state...
Waiting for pod get Running state...
Waiting for pod get Running state...
Results from execution of 'find /data' on validation process pod:
/data
/data/out2.txt
/data/out1.txt
| 権限が付与された Kubernetes ユーザー、システム管理者 | ### オペレーションを監視する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションログを監視します。 | 2 日目のオペレーションの一環として、監視用に Amazon CloudWatch にアプリケーションログを送信します。 | AWS システム管理者、権限が付与された Kubernetes ユーザー | | Container Insights で、Amazon EKS と Kubernetes コンテナを監視します。 | 2 日目のオペレーションの一環として、Amazon CloudWatch Container Insights を使用して Amazon EKS システムと Kubernetes システムを監視します。このツールは、コンテナ化されたアプリケーションから、さまざまなレベルとディメンションでメトリクスを収集、集計、要約します。詳細については、「[関連リソース](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-resources)」セクションを参照してください。 | AWS システム管理者、権限が付与された Kubernetes ユーザー | | CloudWatch で Amazon EFS を監視します。 | 2 日目のオペレーションの一環として、Amazon CloudWatch を使用して ファイルシステムを監視し、Amazon EFS から生データを収集し、リアルタイムに近い読み取り可能なメトリクスに処理します。詳細については、[関連リソース]セクションを参照してください。 | AWS システム管理者 | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | パターン用に作成されたすべてのリソースをクリーンアップします。 | このパターンを完了したら、AWS 料金が発生しないようにすべてのリソースをクリーンアップします。PoC アプリケーションの使用が終了したら、`clean-up-resources.sh` スクリプトを実行してすべてのリソースを削除します。次のいずれかのオプションを完了します。**KMS キーを使用して保存時に暗号化する場合:**
./scripts/epic06/clean-up-resources.sh \
    -c "$CLUSTER_NAME" \
    -t "$EFS_CREATION_TOKEN" \
    -k "$KMS_KEY_ALIAS"
ここで、`$CLUSTER_NAME` は Amazon EKS クラスターの名前、`$EFS_CREATION_TOKEN` はファイルシステムの作成トークン、`$KMS_KEY_ALIAS` は KMS キーのエイリアスです。**保存時に暗号化しない場合:**
./scripts/epic06/clean-up-resources.sh \
    -c "$CLUSTER_NAME" \
    -t "$EFS_CREATION_TOKEN"
ここで、`$CLUSTER_NAME` は Amazon EKS クラスターの名前、`$EFS_CREATION_TOKEN` はファイルシステムの作成トークンです。 | 権限が付与された Kubernetes ユーザー、システム管理者 | ## 関連リソース **リファレンス** + [Amazon EKS 用 AWS Fargate が Amazon EFS をサポートするようになりました](https://aws.amazon.com/blogs/aws/new-aws-fargate-for-amazon-eks-now-supports-amazon-efs/) (お知らせ) + [AWS Fargate で Amazon EKS を使用するときにアプリケーションログをキャプチャする方法](https://aws.amazon.com/blogs/containers/how-to-capture-application-logs-when-using-amazon-eks-on-aws-fargate/)（ブログ投稿） + [Container Insights の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)(Amazon CloudWatch ドキュメント) + [Amazon EKS と Kubernetes で Container Insights をセットアップする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html)(Amazon CloudWatch ドキュメント) + [Amazon EKS と Kubernetes Container Insights のメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html)(Amazon CloudWatch ドキュメント) + [Amazon CloudWatch での Amazon EFS の監視](https://docs.aws.amazon.com/efs/latest/ug/monitoring-cloudwatch.html)(Amazon EFS ドキュメント) **GitHub チュートリアルおよび例** + [静的プロビジョニング](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/static_provisioning/README.md) + [転送時の暗号化](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/encryption_in_transit/README.md) + [複数のポッドからファイルシステムへのアクセス](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/multiple_pods/README.md) + [StatefulSets での Amazon EFS の利用](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/statefulset/README.md) + [サブパスのマウント](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/volume_path/README.md) + [Amazon EFS アクセスポイントの使用](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/access_points/README.md) + [Amazon EKS Blueprints for Terraform](https://aws-ia.github.io/terraform-aws-eks-blueprints/) **必要なツール** + [AWS CLI バージョン 2 のインストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html) + [eksctl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) + [kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) + [jq のインストール](https://stedolan.github.io/jq/download/) ## 追加情報 `kubectl get pv` コマンドの出力例を次に示します。 ``` NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE poc-app-pv 1Mi RWX Retain Bound poc-efs-eks-fargate/poc-app-pvc efs-sc 3m56s ``` `kubectl -n poc-efs-eks-fargate get pvc` コマンドの出力例を次に示します。 ``` NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE poc-app-pvc Bound poc-app-pv 1Mi RWX efs-sc 4m34s ``` # Amazon EKS Pod Identity と KEDA を使用して Amazon EKS でイベント駆動型自動スケーリングをセットアップする *Amazon Web Services、Dipen Desai、Abhay Diwan、Kamal Joshi、Mahendra Revanasiddappa* ## 概要 [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) などのオーケストレーションプラットフォームは、コンテナベースのアプリケーションのライフサイクル管理を合理化してきました。これにより、組織はコンテナベースのアプリケーションの構築、保護、運用、保守に集中できます。イベント駆動型デプロイがより一般的になるにつれて、組織はさまざまなイベントソースに基づいて Kubernetes デプロイをより頻繁にスケーリングするようになっています。この方法と自動スケーリングを一緒に使用し、アプリケーションロジックに合わせたオンデマンドコンピューティングリソースと効率的なスケーリングを提供することで、大幅なコスト削減につながります。 [KEDA](https://keda.sh/) は、Kubernetes ベースのイベント駆動型オートスケーラーです。KEDA は、処理する必要があるイベントの数に基づいて Kubernetes のコンテナをスケールするのに役立ちます。軽量で、任意の Kubernetes クラスターと統合できます。また、[Horizontal Pod Autoscaling (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) などの標準 Kubernetes コンポーネントでも機能します。KEDA には、認証を委任するのに役立つ機能である [TriggerAuthentication](https://keda.sh/docs/2.14/concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) も用意されています。これにより、ScaledObject やデプロイコンテナとは別の認証パラメータを記述できます。 AWS は AWS Identity and Access Management 、Amazon EKS、Amazon EKS Anywhere、(ROSA)、Amazon Elastic Compute Cloud (Amazon EC2) 上のセルフマネージド Kubernetes クラスターなど、さまざまな Kubernetes デプロイオプションをサポートする (IAM) ロールを提供します。 Red Hat OpenShift Service on AWS Amazon EC2 これらのロールは、OpenID Connect (OIDC) ID プロバイダーや IAM 信頼ポリシーなどの IAM コンストラクトを使用することにより、Amazon EKS サービスや API に直接依存することなく、さまざまな環境で機能します。詳細については、Amazon EKS ドキュメントの「[サービスアカウントの IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)」を参照してください。 [Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) を使用すると、Kubernetes サービスアカウントが OIDC プロバイダーなしで IAM ロールを引き受けるプロセスが簡素化されます。これにより、アプリケーションの認証情報を管理できます。 AWS 認証情報を作成してコンテナに配布したり、Amazon EC2 インスタンスのロールを使用する代わりに、IAM ロールを Kubernetes サービスアカウントに関連付け、サービスアカウントを使用するように Pod を設定します。これにより、複数のクラスターで IAM ロールを使用することができ、IAM ロール間でアクセス許可ポリシーを再利用することでポリシー管理を簡素化することができます。 KEDA と Amazon EKS Pod Identity を実装することで、企業は効率的なイベント駆動型の自動スケーリングとシンプルな認証情報管理を実現できます。アプリケーションは需要に基づいてスケールするため、リソース使用率を最適化し、コストを削減できます。 このパターンは、Amazon EKS Pod Identity を KEDA と統合するのに役立ちます。`keda-operator` サービスアカウントを使用し、`TriggerAuthentication` で認証を委任する方法を説明します。また、KEDA オペレータ用の IAM ロールとアプリケーション用の IAM ロールの間に信頼関係をセットアップする方法についても説明します。この信頼関係により、KEDA はイベントキュー内のメッセージをモニタリングし、送信先 Kubernetes オブジェクトのスケーリングを調整することができます。 ## 前提条件と制限 **前提条件** + AWS Command Line Interface (AWS CLI) バージョン 2.13.17 以降、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)済み + Python バージョン 3.11.5 以降が[インストールされていること](https://www.python.org/downloads/) + AWS SDK for Python (Boto3) バージョン 1.34.135 以降、[インストール](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html)済み + Helm バージョン 3.12.3 以降が[インストールされていること](https://helm.sh/docs/intro/install/) + kubectl バージョン 1.25.1 以降が[インストールされていること](https://kubernetes.io/docs/tasks/tools/) + Docker Engine バージョン 26.1.1 以降が[インストールされていること](https://docs.docker.com/engine/install/) + Amazon EKS クラスターバージョン 1.24 以降が[作成されていること](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) + Amazon EKS Pod Identity エージェントを作成するための前提条件が[満たされていること](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html#pod-id-agent-add-on-create) **制限事項** + `keda-operator` ロールと `keda-identity` ロールの間に信頼関係を確立する必要があります。手順については、このパターンの「[エピック](#event-driven-auto-scaling-with-eks-pod-identity-and-keda-epics)」セクションを参照してください。 ## アーキテクチャ このパターンでは、次の AWS リソースを作成します。 + **Amazon Elastic Container Registry (Amazon ECR) リポジトリ** – このパターンでは、このリポジトリの名前は `keda-pod-identity-registry` です。このプライベートリポジトリは、サンプルアプリケーションの Docker イメージを保存するために使用されます。 + **Amazon Simple Queue Service (Amazon SQS) キュー** – このパターンでは、このキューの名前は `event-messages-queue` です。キューは、受信メッセージを収集して保存するメッセージバッファとして機能します。KEDA は、メッセージ数やキューの長さなどのキューメトリクスをモニタリングし、これらのメトリクスに基づいてアプリケーションを自動的にスケーリングします。 + **アプリケーションの IAM ロール** – このパターンでは、このロールの名前は `keda-identity` です。`keda-operator` ロールはこのロールを引き受けます。このロールにより、Amazon SQS キューへのアクセスが許可されます。 + **KEDA オペレーターの IAM ロール** – このパターンでは、このロールの名前は `keda-operator` です。KEDA 演算子は、このロールを使用して必要な AWS API コールを行います。このロールには、`keda-identity` ロールを引き受けるためのアクセス権限が割り当てられています。`keda-operator` と `keda-identity` ロールの間には信頼関係があるため、`keda-operator` ロールにも Amazon SQS アクセス権限が割り当てられます。 `TriggerAuthentication` および `ScaledObject` Kubernetes カスタムリソースを通じて、オペレーターは `keda-identity` ロールで Amazon SQS キューに接続します。キューのサイズに基づいて、KEDA は自動的にアプリケーションのデプロイをスケーリングします。キュー内の 5 つの未読メッセージごとに 1 つのポッドを追加します。デフォルト設定では、Amazon SQS キューに未読メッセージがない場合、アプリケーションはポッド数 0 までスケールダウンします。KEDA オペレーターは、指定した間隔でキューをモニタリングします。   次の図に、Amazon EKS Pod Identity を使用して `keda-operator` ロールに Amazon SQS キューへの安全なアクセスを提供する方法を示します。 ![\[KEDA と Amazon EKS Pod Identity を使用して、Kubernetes ベースのアプリケーションを自動的にスケーリングします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/56f7506d-e8d3-43e5-bec6-42267fedd0ae/images/05bdbd09-9eb8-4c0b-8c0d-efe38aecb683.png) この図表は、次のワークフローを示しています: 1. Amazon EKS Pod Identity エージェントを Amazon EKS クラスターにインストールします。 1. Amazon EKS クラスターの KEDA 名前空間に KEDA オペレーターをデプロイします。 1. ターゲットに `keda-operator`および `keda-identity` IAM ロールを作成します AWS アカウント。 1. IAM ロールの間に信頼関係を確立します。 1. アプリケーションを `security` 名前空間にデプロイします。 1. KEDA オペレーターは、Amazon SQS キュー内のメッセージをポーリングします。 1. KEDA が HPA を開始し、キューのサイズに基づいてアプリケーションが自動的にスケーリングされます。 ## ツール **AWS のサービス** + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + 「[Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)」は、分散したソフトウェアシステムとコンポーネントの統合と切り離しを支援し、セキュアで耐久性があり、利用可能なホスト型キューを提供します。 その他のツール + [KEDA](https://keda.sh/) は、Kubernetes ベースのイベント駆動型オートスケーラーです。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[Event-driven auto scaling using EKS Pod Identity and KEDA](https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda/tree/main)」で入手できます。 ## ベストプラクティス ACM のベストプラクティスに従うことをおすすめします。 + [Amazon EKS ベストプラクティス](https://docs.aws.amazon.com/eks/latest/best-practices/introduction.html) + [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [Amazon SQS のベストプラクティス](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-best-practices.html) ## エピック ### AWS リソースの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | KEDA オペレーターの IAM ロールを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | AWS 管理者 | | サンプルアプリケーションの IAM ロールを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | AWS 管理者 | | Amazon SQS キューを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | AWS 全般 | | Amazon ECR リポジトリを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | AWS 全般 | ### Amazon EKS クラスターをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EKS Pod Identity エージェントをデプロイします。 | ターゲット Amazon EKS クラスターで、Amazon EKS Pod Identity エージェントをセットアップします。Amazon EKS ドキュメントの「[Amazon EKS Pod Identity エージェントのセットアップ](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html#pod-id-agent-add-on-create)」の手順に従います。 | AWS DevOps | | KEDA をデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps エンジニア | | IAM ロールを Kubernetes サービスアカウントに割り当てます。 | Amazon EKS ドキュメントの「[IAM ロールを Kubernetes サービスアカウントに割り当てる](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html)」の手順に従ってください。以下の値を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | AWS DevOps | | 名前空間を作成します。 | 次のコマンドを入力して、ターゲット Amazon EKS クラスターに `security` 名前空間を作成します。
kubectl create ns security
| DevOps エンジニア | ### サンプルアプリケーションをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションファイルのクローンを作成します。 | 次のコマンドを入力して、GitHub の「[Event-driven auto scaling using EKS Pod Identity and KEDA repository](https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda/tree/main)」のクローンを作成します。
git clone https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda.git
| DevOps エンジニア | | Docker イメージを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps エンジニア | | Amazon ECR にDocker イメージをプッシュします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html)プッシュコマンドを見つけるには、Amazon ECR リポジトリページに移動し、**[プッシュコマンドを表示]** を選択します。 | DevOps エンジニア | | サンプルアプリケーションをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps エンジニア | | IAM ロールをアプリケーションサービスアカウントに割り当てます。 | `keda-identity` IAM ロールをサンプルアプリケーションのサービスアカウントに関連付けるには、次のいずれかを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps エンジニア | | `ScaledObject` と `TriggerAuthentication` をデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps エンジニア | ### 自動スケーリングをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon SQS キューにメッセージを送信します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps エンジニア | | アプリケーションポッドをモニタリングします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | KEDA オペレーターがアプリケーションをスケールできません。 | 次のコマンドを入力して、`keda-operator` IAM ロールのログを確認します。
kubectl logs -n keda -l app=keda-operator -c keda-operator
 `HTTP 403` レスポンスコードがある場合、アプリケーションと KEDA スケーラーには Amazon SQS キューにアクセスするための十分な権限がありません。以下のステップを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html)`Assume-Role` エラーが発生した場合、[Amazon EKS ノードの IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html)は、`TriggerAuthentication` に定義されている IAM ロールを引き受けることができません。以下のステップを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | ## 関連リソース + [Amazon EKS Pod Identity エージェントのセットアップ](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) (Amazon EKS ドキュメント) + [Deploying KEDA](https://keda.sh/docs/2.14/deploy/) (KEDA ドキュメント) + [ScaledObject specification](https://keda.sh/docs/2.16/reference/scaledobject-spec/) (KEDA ドキュメント) + [Authentication with TriggerAuthentication](https://keda.sh/docs/2.14/concepts/authentication/) (KEDA ドキュメント) # PGO を使用して Amazon EKS での PostgreSQL デプロイを合理化する *Shalaka Dengale (Amazon Web Services)* ## 概要 このパターンは、Crunchy Data の Postgres オペレーター (PGO) を Amazon Elastic Kubernetes Service (Amazon EKS) と統合して、クラウドネイティブ環境での PostgreSQL デプロイを合理化します。PGO は、Kubernetes で PostgreSQL データベースを管理するための自動化とスケーラビリティを提供します。PGO を Amazon EKS と組み合わせると、PostgreSQL データベースを効率的にデプロイ、管理、スケーリングするための堅牢なプラットフォームが形成されます。 この統合には、次のような主な利点があります。 + 自動デプロイ: PostgreSQL クラスターのデプロイと管理を簡素化します。 + カスタムリソース定義 (CRD):** **PostgreSQL 管理に Kubernetes プリミティブを使用します。 + 高可用性: 自動フェイルオーバーと同期レプリケーションをサポートします。 + 自動バックアップと復元:** **バックアップと復元プロセスを合理化します。 + 水平スケーリング:** **PostgreSQL クラスターの動的スケーリングを有効にします。 + バージョンアップグレード: 最小限のダウンタイムでローリングアップグレードできるようにします。 + セキュリティ: 暗号化、アクセスコントロール、認証メカニズムを適用します。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + Linux、macOS または Windows にインストールして設定されている「[AWS Command Line Interface (AWS CLI) バージョン 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)」。 + コマンドラインから AWS リソースを接続する [AWS CLI Config](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html)。 + Linux、macOS、または Windows にインストールして設定されている [eksctl](https://github.com/eksctl-io/eksctl#installation)。 + `kubectl`、Amazon EKS クラスターのリソースにアクセスするようにインストールおよび設定されています。詳細については、Amazon EKS ドキュメントの「[kubectl と eksctl のセットアップ](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」を参照してください。  + Amazon EKS クラスターにアクセスするように設定されたコンピュータのターミナル。詳細については、「Amazon EKS ドキュメント」の「[クラスターと通信するようにコンピュータを設定する](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html#eks-configure-kubectl)」を参照してください。 **製品バージョン** + Kubernetes バージョン 1.21～1.24 以降 ([PGO のドキュメント](https://access.crunchydata.com/documentation/postgres-operator/5.2.5/)を参照してください)。 + PostgreSQL バージョン 10 以降。このパターンでは、PostgreSQL バージョン 16 を使用します。 **制限事項** + 一部の AWS のサービス は、すべてで利用できるわけではありません AWS リージョン。利用可能なリージョンについて、詳しくは「[AWS のサービス by Region](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」をご確認ください。特定のエンドポイントについて確認するには、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページを参照し、サービスのリンクを選択してください。 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon EKS + Amazon Virtual Private Cloud (Amazon VPC) + Amazon Elastic Compute Cloud (Amazon EC2) **ターゲット アーキテクチャ** ![\[PGO を 3 つのアベイラビリティーゾーン、2 つのレプリカ、PgBouncer、PGO オペレーターとともに使用するためのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4c164012-7527-4ebe-b6a7-c129600328d6/images/26a5572b-405b-4634-b96a-91254c3ea2c1.png) このパターンでは、3 つのノードがある Amazon EKS クラスターを含むアーキテクチャを構築します。各ノードは、バックエンドの一連の EC2 インスタンス上で実行されます。この PostgreSQL セットアップはプライマリレプリカアーキテクチャに準拠しており、読み取り負荷の高いユースケースに特に効果的です。アーキテクチャには、以下のコンポーネントが含まれます。 + **プライマリデータベースコンテナ (pg-primary)**: すべての書き込み操作を指示するメインの PostgreSQL インスタンスをホストします。 + **セカンダリレプリカコンテナ (pg-replica)**: プライマリデータベースからデータをレプリケートし、読み取り操作を処理する PostgreSQL インスタンスをホストします。 + **PgBouncer**: PGO に含まれている PostgreSQL データベース用の軽量接続プーラーです。これはクライアントと PostgreSQL サーバーの間に位置し、データベース接続の中継役として機能します。 + **PGO**: この Kubernetes 環境で PostgreSQL クラスターのデプロイと管理を自動化します。 + **Patroni**: PostgreSQL の高可用性設定を管理および自動化するオープンソースツールです。PGO に含まれています。Kubernetes で PGO とともに Patroni を使用すると、PostgreSQL クラスターのレジリエンスと耐障害性を確保する上で重要な役割を果たします。詳細については、[Patroni のドキュメント](https://patroni.readthedocs.io/en/latest/)を参照してください。 ワークフローのステップは次のとおりです。 + **PGO オペレーターのデプロイ**: Amazon EKS で実行される Kubernetes クラスターに PGO オペレーターをデプロイします。これは、Kubernetes マニフェストまたは Helm チャートを使用して実行できます。このパターンでは、Kubernetes マニフェストを使用します。 + **PostgreSQL インスタンスの定義**: オペレーターが実行されたら、カスタムリソース (CR) を作成して、PostgreSQL インスタンスの目的の状態を指定します。これには、ストレージ、レプリケーション、高可用性設定などの設定が含まれます。 + **オペレーター管理**: CR などの Kubernetes API オブジェクトを通じてオペレーターをやり取りし、PostgreSQL インスタンスを作成、更新、または削除します。 + **モニタリングとメンテナンス**: Amazon EKS で実行されている PostgreSQL インスタンスの状態とパフォーマンスをモニタリングできます。多くの場合、オペレーターはモニタリングのためにメトリクスとログ記録を提供します。必要に応じて、アップグレードやパッチ適用などの定期的なメンテナンスタスクを実行できます。詳細については、Amazon EKS ドキュメントの「[クラスターのパフォーマンスをモニタリングし、ログを表示する](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html)」を参照してください。 + **スケーリングとバックアップ**: オペレーターが提供する機能を使用して、PostgreSQL インスタンスをスケーリングし、バックアップを管理できます。 このパターンでは、モニタリング、メンテナンス、およびバックアップ操作については説明しません。 **自動化とスケール** + を使用して CloudFormation インフラストラクチャの作成を自動化できます。詳細については、Amazon EKS ドキュメントの「[CloudFormationを使用して Amazon EKS リソースを作成する](https://docs.aws.amazon.com/eks/latest/userguide/creating-resources-with-cloudformation.html)」を参照してください。 + GitVersion または Jenkins のビルド番号を使用して、データベースインスタンスのデプロイを自動化できます。 ## ツール **AWS のサービス** + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。  + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。 **その他のツール** + [eksctl](https://eksctl.io/) は、Amazon EKS 上にクラスターを作成するためのシンプルなコマンドラインツールです。 + 「[kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)」は、 Kubernetes クラスターに対してコマンドを実行するためのコマンドラインユーティリティです。 + [PGO](https://github.com/CrunchyData/postgres-operator) は、Kubernetes での PostgreSQL データベース管理を自動化およびスケーリングします。 ## ベストプラクティス スムーズで効率的なデプロイを確実に行うには、次のベストプラクティスに従ってください。 + **EKS クラスターを保護します**。サービスアカウント (IRSA)、ネットワークポリシー、VPC セキュリティグループの AWS Identity and Access Management (IAM) ロールの使用など、EKS クラスターのセキュリティのベストプラクティスを実装します。EKS クラスター API サーバーへのアクセスを制限し、TLS を使用してノードと API サーバー間の通信を暗号化します。 + Amazon EKS で実行されている PGO と Kubernetes の**バージョン互換性を確保**します。一部の PGO 機能では、特定の Kubernetes バージョンが要求される場合や、互換性の制限が生じる場合があります。詳細については、PGO ドキュメントの「[Components and Compatibility](https://access.crunchydata.com/documentation/postgres-operator/5.2.5/references/components/)」を参照してください。 + CPU、メモリ、ストレージなど、PGO デプロイの**リソース割り当てを計画**します。PGO とそれが管理する PostgreSQL インスタンスの両方のリソース要件を考慮してください。リソースの使用状況をモニタリングし、必要に応じてリソースをスケーリングします。 + **高可用性を実現するように設計**します。高可用性を実現するように PGO デプロイを設計し、ダウンタイムを最小限に抑え、信頼性を確保します。複数のアベイラビリティーゾーンに複数の PGO レプリカをデプロイして、耐障害性を確保します。 + PGO が管理する PostgreSQL データベースの**バックアップおよび復元手順を適用**します。Kubernetes および Amazon EKS と互換性がある PGO またはサードパーティーのバックアップソリューションが提供する機能を使用します。 + PGO デプロイの**モニタリングとログ記録を設定**し、パフォーマンス、状態、イベントを追跡します。メトリクスのモニタリングには Prometheus、視覚化には Grafana などのツールを使用します。トラブルシューティングと監査のために PGO ログを取得するようログ記録を設定します。 + PGO、PostgreSQL インスタンス、Kubernetes クラスター内のその他のサービス間の通信を許可するように**ネットワークを適切に設定**します。ネットワークポリシーの適用とトラフィックの分離には、Amazon VPC ネットワーク機能と、Calico や [Amazon VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) などの Kubernetes ネットワークプラグインを使用します。 + パフォーマンス、耐久性、スケーラビリティなどの要素を考慮して、PostgreSQL データベースに**適したストレージオプションを選択**します。永続的ストレージには、Amazon Elastic Block Store (Amazon EBS) ボリュームまたは AWS マネージドストレージサービスを使用します。詳細については、Amazon EKS ドキュメントの「[Amazon EBS で Kubernetes ボリュームを保存する](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html)」を参照してください。 + などの**Infrastructure as Code (IaC) ツールを使用して** CloudFormation 、Amazon EKS での PGO のデプロイと設定を自動化します。EKS クラスター、ネットワーク、PGO リソースなどのインフラストラクチャコンポーネントを整合性、再現性、バージョン管理のためのコードとして定義します。 ## エピック ### IAM ロールを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM ロールを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | AWS 管理者 | ### Amazon EKS クラスターを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EKS クラスターを作成します。 | 既にクラスターをデプロイしている場合は、このステップをスキップします。それ以外の場合は、`eksctl`、Terraform、または AWS アカウント を使用して Amazon EKS クラスターを現在の にデプロイします CloudFormation。このパターンでは、クラスターのデプロイに `eksctl` を使用します。このパターンでは、Amazon EKS のノードグループとして Amazon EC2 を使用します。を使用する場合は AWS Fargate、[eksctl ドキュメント](https://eksctl.io/usage/schema/#managedNodeGroups)`managedNodeGroups`の設定を参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | AWS 管理者、Terraform または eksctl 管理者、Kubernetes 管理者 | | クラスターのステータスを検証します。 | 次のコマンドを実行して、クラスターのノードの現在のステータスを確認します。
kubectl get nodes
エラーが発生した場合は、Amazon EKS ドキュメントの[トラブルシューティングセクション](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html)を参照してください。 | AWS 管理者、Terraform または eksctl 管理者、Kubernetes 管理者 | ### OIDC ID プロバイダーを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM OIDC プロバイダーを有効にします。 | Amazon EBS Container Storage Interface (CSI) ドライバーの前提条件として、クラスターに既存の IAM OpenID Connect (OIDC) プロバイダーが必要です。次のコマンドを使用して、IAM OIDC プロバイダーを有効化します。
eksctl utils associate-iam-oidc-provider --region={region} --cluster={YourClusterNameHere} --approve
このステップの詳細については、[Amazon EKS のドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html)を参照してください。 | AWS 管理者 | | Amazon EBS CSI ドライバーの IAM ロールを作成します。 | 次の `eksctl` コマンドを使用して、CSI ドライバーの IAM ロールを作成します。
eksctl create iamserviceaccount \
  --region {RegionName} \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster {YourClusterNameHere} \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --role-only \
  --role-name AmazonEKS_EBS_CSI_DriverRole
暗号化された Amazon EBS ドライブを使用する場合は、ポリシーをさらに設定する必要があります。手順については、[Amazon EBS SCI のドキュメント](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#installation-1)を参照してください。 | AWS 管理者 | | Amazon EBS CSI ドライバーを追加します。 | 次の `eksctl` コマンドを使用して、Amazon EBS CSI ドライバーを追加します。
eksctl create addon \
  --name aws-ebs-csi-driver \
  --cluster  service-account-role-arn arn:aws:iam::$(aws sts get-caller-identity \
  --query Account \
  --output text):role/AmazonEKS_EBS_CSI_DriverRole \
  --force
| AWS 管理者 | ### PGO をインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | PGO リポジトリのクローンを作成します。 | PGO の GitHub リポジトリのクローンを作成します。
git clone https://github.com/CrunchyData/postgres-operator-examples.git
| AWS DevOps | | サービスアカウント作成のためにロールの詳細を指定します。 | Amazon EKS クラスターに必要な AWS リソースへのアクセスを許可するには、[GitHub](https://github.com/CrunchyData/postgres-operator/blob/main/config/rbac/cluster/service_account.yaml) にある `service_account.yaml` ファイルで前に作成した OIDC ロールの Amazon リソースネーム (ARN) を指定します。
cd postgres-operator-examples
---
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam:::role/ # Update the OIDC role ARN created earlier
| AWS 管理者、Kubernetes 管理者 | | 名前空間と PGO の前提条件を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | Kubernetes 管理者 | | ポッドの作成を確認します。 | 名前空間とデフォルト設定が作成されていることを確認します。
kubectl get pods -n postgres-operator
| AWS 管理者、Kubernetes 管理者 | | PVC を確認します。 | 次のコマンドを使用して、永続ボリュームのクレーム (PVC) を確認します。
kubectl describe pvc -n postgres-operator
| AWS 管理者、Kubernetes 管理者 | ### オペレーターを作成してデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オペレーターを作成します。 | `/kustomize/postgres/postgres.yaml` にあるファイルの内容を修正して、以下と一致させます。
spec:
  instances:
    - name: pg-1
      replicas: 3
  patroni:
    dynamicConfiguration:
      postgresql:
      pg_hba:
        - "host all all 0.0.0.0/0 trust" # this line enabled logical replication with programmatic access
        - "host all postgres 127.0.0.1/32 md5"
      synchronous_mode: true
  users:
  - name: replicator
    databases:
      - testdb
    options: "REPLICATION"
これらの更新により、以下が実行されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | AWS 管理者、DBA、Kubernetes 管理者 | | オペレーターをデプロイします。 | PGO オペレーターをデプロイして、Kubernetes 環境での PostgreSQL データベースの効率的な管理とオペレーションを可能にします。
kubectl apply -k kustomize/postgres
| AWS 管理者、DBA、Kubernetes 管理者 | | デプロイメントを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html)コマンド出力を確認し、プライマリレプリカ (`primary_pod_name`) とリードレプリカ (`read_pod_name`) を書き留めます。これらは次のステップで使用します。 | AWS 管理者、DBA、Kubernetes 管理者 | ### ストリーミングレプリケーションを検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライマリレプリカにデータを書き込みます。 | 次のコマンドを使用して、PostgreSQL プライマリレプリカに接続し、データベースにデータを書き込みます。
kubectl exec -it  bash -n postgres-operator
psql
CREATE TABLE customers (firstname text, customer_id serial, date_created timestamp);
\dt
| AWS 管理者、Kubernetes 管理者 | | リードレプリカに同じデータがあることを確認します。 | PostgreSQL リードレプリカに接続し、ストリーミングレプリケーションが正しく機能しているかどうかを確認します。
kubectl exec -it {read_pod_name} bash -n postgres-operator
psql
\dt
リードレプリカには、前のステップでプライマリレプリカで作成したテーブルが必要です。 | AWS 管理者、Kubernetes 管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ポッドが起動しません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | | レプリカがプライマリデータベースに対して大幅に遅延しています。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | | PostgreSQL クラスターのパフォーマンスと状態を可視化できません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | | レプリケーションが機能しません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | ## 関連リソース + [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/amazon-elastic-kubernetes-service.html) (「*AWS デプロイオプションの概要*」ホワイトペーパー) + [CloudFormation](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/aws-cloudformation.html) (「*AWS デプロイオプションの概要*」ホワイトペーパー) + [Amazon EKS – eksctl の使用を開始する](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) (*Amazon EKS ユーザーガイド*) + [kubectl および eksctl のセットアップ](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) (*Amazon EKS ユーザーガイド*) + [OpenID Connect フェデレーション用のロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html) (*IAM ユーザーガイド*) + [の設定 ( AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)*AWS CLI ユーザーガイド*) + [Crunchy Postgres for Kubernetes のドキュメント](https://access.crunchydata.com/documentation/postgres-operator/latest) + [Crunch & Learn: Crunchy Postgres for Kubernetes 5.0](https://www.youtube-nocookie.com/embed/IIf9WZO3K50) (ビデオ) # Application Load Balancer を使用して Amazon ECS の相互 TLS でアプリケーション認証を簡素化する *Olawale Olaleye と Shamanth Devagari、Amazon Web Services* ## 概要 このパターンは、[Application Load Balancer (ALB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html) を使用して、Amazon Elastic Container Service (Amazon ECS) の相互 TLS でアプリケーション認証を簡素化し、セキュリティ負担を軽減します。ALB では、X.509 クライアント証明書を認証できます AWS Private Certificate Authority。この強力な組み合わせにより、サービス間の安全な通信を実現し、アプリケーション内での複雑な認証メカニズムの必要性を軽減できます。また、このパターンは Amazon Elastic Container Registry (Amazon ECR) を使用してコンテナイメージを保存します。 このパターンの例では、パブリックギャラリーの Docker イメージを使用して、最初にサンプルワークロードを作成します。その後、新しい Docker イメージは Amazon ECR に保存されるように構築されます。ソースとして、GitHub、GitLab、Bitbucket などの Git ベースのシステムを検討するか、Amazon Simple Storage Service Amazon S3 (Amazon S3) を使用します。Docker イメージを構築するには、後続のイメージ AWS CodeBuild に を使用することを検討してください。 ## 前提条件と制限 **前提条件** + AWS CloudFormation スタックをデプロイするためのアクセス権 AWS アカウント を持つアクティブな 。CloudFormation をデプロイするための AWS Identity and Access Management (IAM) [ユーザーまたはロールのアクセス許可](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/control-access-with-iam.html)があることを確認します。 + AWS Command Line Interface (AWS CLI) [がインストールされています](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)。ローカルマシンまたは環境で AWS 認証情報[を設定するには](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)、 を使用するか、 `~/.aws/credentials` ファイルで環境変数 AWS CLI を設定します。 + OpenSSL が[インストールされていること](https://www.openssl.org/)。 + Docker が[インストールされていること](https://www.docker.com/get-started/)。 + [「 ツール](#simplify-application-authentication-with-mutual-tls-in-amazon-ecs-tools)」で AWS のサービス 説明されている に精通していること。 + Docker と NGINX に関する知識があること。 **制限事項** + Application Load Balancer の相互 TLS は、X.509v3 クライアント証明書のみをサポートします。X.509v1 クライアント証明書はサポートされていません。 + このパターンのコードリポジトリで提供されている CloudFormation テンプレートには、スタックの一部として CodeBuild プロジェクトのプロビジョニングは含まれていません。 + 一部の AWS のサービス は、すべてで利用できるわけではありません AWS リージョン。利用可能なリージョンについては、「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、[「サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択してください。 **製品バージョン** + Docker バージョン 27.3.1 以降。 + AWS CLI バージョン 2.14.5 以降 ## アーキテクチャ 次の図は、このパターンのアーキテクチャコンポーネントを示しています。 ![\[Application Load Balancer を使用して相互 TLS で認証するワークフロー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a343fa4e-097f-416b-9c83-01a28eb57dc3/images/e1371297-b987-4487-9b13-8120933c921f.png) この図表は、次のワークフローを示しています: 1. Git リポジトリを作成し、アプリケーションコードをリポジトリにコミットします。 1. でプライベート認証機関 (CA) を作成します AWS Private CA。 1. CodeBuild プロジェクトを作成する。CodeBuildproject は、コミットの変更によってトリガーされ、Docker イメージを作成し、ビルドされたイメージを Amazon ECR に発行します。 1. CA から証明書チェーンと証明書本文をコピーし、証明書バンドルを Amazon S3 にアップロードします。 1. Amazon S3 にアップロードした CA バンドルを使用してトラストストアを作成します。Application Load Balancer (ALB) の相互 TLS リスナーにトラストストアを関連付けます。 1. プライベート CA を使用して、コンテナワークロードにクライアント証明書を発行します。また、 を使用してプライベート TLS 証明書を作成します AWS Private CA。 1. プライベート TLS 証明書を AWS Certificate Manager (ACM) にインポートし、ALB で使用します。 1. `ServiceTwo` のコンテナワークロードは、発行されたクライアント証明書を使用して、`ServiceOne` のコンテナワークロードと通信するときに ALB で認証します。 1. `ServiceOne` のコンテナワークロードは、発行されたクライアント証明書を使用して、`ServiceTwo` のコンテナワークロードと通信するときに ALB で認証します。 **自動化とスケール** このパターンは、CloudFormation、 AWS Cloud Development Kit (AWS CDK) または SDK の API オペレーションを使用して AWS リソースをプロビジョニングすることで完全に自動化できます。 AWS CodePipeline を使用して、CodeBuild を使用して継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを実装し、コンテナイメージのビルドプロセスを自動化し、Amazon ECS クラスターサービスに新しいリリースをデプロイできます。 ## ツール **AWS のサービス ** + [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) は、 AWS ウェブサイトとアプリケーションを保護するパブリックおよびプライベート SSL/TLS X.509 証明書とキーの作成、保存、更新に役立ちます。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 + [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) は、クラスターでコンテナの実行、停止、管理を簡単に行うことのできる、スケーラビリティに優れた高速なコンテナ管理サービスです。タスクとサービスは、 が管理するサーバーレスインフラストラクチャで実行できます AWS Fargate。または、インフラストラクチャをより詳細に制御するために、管理する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのクラスターでタスクとサービスを実行できます。 + [Amazon ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) を使用すると、最初にホストコンテナのオペレーティングシステムとやり取りしたり、インバウンドポートを開いたり、SSH キーを管理したりすることなく、コンテナと直接やり取りできます。ECS Exec を使用して、Amazon EC2 インスタンスまたは AWS Fargateで実行されているコンテナでコマンドを実行したり、シェルを取得したりできます。 + [Elastic Load Balancing (ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) は、受信するアプリケーションまたはネットワークのトラフィックを複数のターゲットに分散します。例えば、1 つ以上のアベイラビリティーゾーンの Amazon EC2 インスタンス、コンテナ、および IP アドレスにトラフィックを分散できます。ELB は、登録されているターゲットの状態をモニタリングし、正常なターゲットにのみトラフィックをルーティングします。ELB は、受信トラフィックの時間的な変化に応じて、ロードバランサーをスケールします。また、大半のワークロードに合わせて自動的にスケールできます。 + [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html) を使用すると、サーバーや Amazon EC2 インスタンスを管理せずにコンテナを実行できます。Fargate は Amazon ECS と Amazon Elastic Kubernetes Service (Amazon EKS) の両方と互換性があります。Amazon ECS タスクとサービスは、Fargate 起動タイプまたは Fargate キャパシティプロバイダーで実行できます。そのためには、アプリケーションをコンテナにパッケージ化し、CPU とメモリ要件を指定して、ネットワークと IAM ポリシーを定義してから、アプリケーションを起動します。各Fargate タスクは、独自の分離境界を持ち、基盤となるカーネル、CPU リソース、メモリリソース、Elastic Network Interface を別のタスクと共有しません。 + [AWS Private Certificate Authority](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) では、オンプレミス CA の運用にかかる投資コストや保守コストなしに、ルート CA や下位 CA を含むプライベート認証機関 (CA) 階層を作成できます。 **その他のツール****** + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしての Platform as a Service (PaaS) 製品のセットです。 + [GitHub](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories)、[GitLab](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html)、[Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/tutorial-learn-bitbucket-with-git/) は、ソースコードの変更を追跡するために一般的に使用される Git ベースのソース管理システムの一部です。 + [NGINX オープンソース](https://nginx.org/en/docs/?_ga=2.187509224.1322712425.1699399865-405102969.1699399865)は、オープンソースのロードバランサー、コンテンツキャッシュ、ウェブサーバーです。このパターンでは、ウェブサーバーとして使用します。 + [OpenSSL](https://www.openssl.org/) は、TLS と CMS の OpenSSL 実装で使用されるサービスを提供するオープンソースライブラリです。 **コードリポジトリ** このパターンのコードは、GitHub の [mTLS-with-Application-Load-Balancer-in-Amazon-ECS](https://github.com/aws-samples/mTLS-with-Application-Load-Balancer-in-Amazon-ECS) リポジトリで入手できます。 ## ベストプラクティス + Amazon ECS Exec を使用して、コマンドを実行するか、Fargate で実行されているコンテナにシェルを取得します。ECS Exec を使用すると、デバッグに必要な診断情報を収集することもできます。 + セキュリティグループとネットワークアクセスコントロールリスト (ACL) を使用して、サービス間のインバウンドトラフィックとアウトバウンドトラフィックを制御します。Fargate のタスクは仮想プライベートクラウド (VPC) 内の設定済みサブネットから IP アドレスを受け取ります。 ## エピック ### リポジトリを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソースコードをダウンロードします。 | このパターンのソースコードをダウンロードするには、GitHub の [mTLS-with-Application-Load-Balancer-in-Amazon-ECS](https://github.com/aws-samples/mTLS-with-Application-Load-Balancer-in-Amazon-ECS) リポジトリをフォークまたはクローンします。 | DevOps エンジニア | | Git リポジトリを作成します。 | Dockerfile と `buildspec.yaml` ファイルを含む Git リポジトリを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)`git clone https://github.com/aws-samples/mTLS-with-Application-Load-Balancer-in-Amazon-ECS.git` | DevOps エンジニア | ### CA を作成して証明書を生成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | でプライベート CA を作成します AWS Private CA。 | プライベート認証局 (CA) を作成するには、ターミナルで次のコマンドを実行します。サンプル変数の値は独自の値に置き換えます。
export AWS_DEFAULT_REGION="us-west-2"
export SERVICES_DOMAIN="www.example.com"

export ROOT_CA_ARN=`aws acm-pca create-certificate-authority \
    --certificate-authority-type ROOT \
    --certificate-authority-configuration \
    "KeyAlgorithm=RSA_2048,
    SigningAlgorithm=SHA256WITHRSA,
    Subject={
        Country=US,
        State=WA,
        Locality=Seattle,
        Organization=Build on AWS,
        OrganizationalUnit=mTLS Amazon ECS and ALB Example,
        CommonName=${SERVICES_DOMAIN}}" \
        --query CertificateAuthorityArn --output text`
詳細については、 AWS ドキュメントの「 [でプライベート CA を作成する AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/create-CA.html)」を参照してください。 | DevOps エンジニア、AWS DevOps | | プライベートルート CA 証明書を作成してインストールします。 | プライベートルート CA の証明書を作成してインストールするには、ターミナルで次のコマンドを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html) | AWS DevOps、DevOps エンジニア | | マネージド証明書をリクエストします。 | でプライベート ALB AWS Certificate Manager で使用するプライベート証明書をリクエストするには、次のコマンドを使用します。
export TLS_CERTIFICATE_ARN=`aws acm request-certificate \
    --domain-name "*.${DOMAIN_DOMAIN}" \
    --certificate-authority-arn ${ROOT_CA_ARN} \
    --query CertificateArn --output text`
| DevOps エンジニア、AWS DevOps | | プライベート CA を使用してクライアント証明書を発行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)`openssl req -out client_csr1.pem -new -newkey rsa:2048 -nodes -keyout client_private-key1.pem``openssl req -out client_csr2.pem -new -newkey rsa:2048 -nodes -keyout client_private-key2.pem`このコマンドは、2 つのサービスの CSR とプライベートキーを返します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)
SERVICE_ONE_CERT_ARN=`aws acm-pca issue-certificate \
    --certificate-authority-arn ${ROOT_CA_ARN} \
    --csr fileb://client_csr1.pem \
    --signing-algorithm "SHA256WITHRSA" \
    --validity Value=5,Type="YEARS" --query CertificateArn --output text` 

echo "SERVICE_ONE_CERT_ARN: ${SERVICE_ONE_CERT_ARN}"

aws acm-pca get-certificate \
    --certificate-authority-arn ${ROOT_CA_ARN} \
    --certificate-arn ${SERVICE_ONE_CERT_ARN} \
     | jq -r '.Certificate' > client_cert1.cert

SERVICE_TWO_CERT_ARN=`aws acm-pca issue-certificate \
    --certificate-authority-arn ${ROOT_CA_ARN} \
    --csr fileb://client_csr2.pem \
    --signing-algorithm "SHA256WITHRSA" \
    --validity Value=5,Type="YEARS" --query CertificateArn --output text` 

echo "SERVICE_TWO_CERT_ARN: ${SERVICE_TWO_CERT_ARN}"

aws acm-pca get-certificate \
    --certificate-authority-arn ${ROOT_CA_ARN} \
    --certificate-arn ${SERVICE_TWO_CERT_ARN} \
     | jq -r '.Certificate' > client_cert2.cert
詳細については、 AWS ドキュメントの[「プライベートエンドエンティティ証明書を発行](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html)する」を参照してください。 | DevOps エンジニア、AWS DevOps | ### AWS サービスをプロビジョニングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation テンプレート AWS のサービス を使用してプロビジョニングします。 | 仮想プライベートクラウド (VPC)、Amazon ECS クラスター、Amazon ECS サービス、Application Load Balancer、Amazon Elastic Container Registry (Amazon ECR) をプロビジョニングするには、CloudFormation テンプレートを使用します。 | DevOps エンジニア | | 変数を取得します。 | 2 つのサービスが実行されている Amazon ECS クラスターがあることを確認します。リソースの詳細を取得し、変数として保存するには、次のコマンドを使用します。

export LoadBalancerDNS=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`LoadBalancerDNS`].OutputValue')

export ECRRepositoryUri=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`ECRRepositoryUri`].OutputValue')

export ECRRepositoryServiceOneUri=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`ECRRepositoryServiceOneUri`].OutputValue')

export ECRRepositoryServiceTwoUri=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`ECRRepositoryServiceTwoUri`].OutputValue')

export ClusterName=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`ClusterName`].OutputValue')

export BucketName=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`BucketName`].OutputValue')

export Service1ListenerArn=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`Service1ListenerArn`].OutputValue')

export Service2ListenerArn=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`Service2ListenerArn`].OutputValue')
| DevOps エンジニア | | CodeBuild プロジェクトを作成する。 | CodeBuild プロジェクトを使用して Amazon ECS サービスの Docker イメージを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)詳細については、 AWS ドキュメントの[「 でビルドプロジェクトを作成する AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/create-project.html)」を参照してください。 | AWS DevOps、DevOps エンジニア | | Docker イメージを構築します。 | CodeBuild を使用してイメージビルドプロセスを実行できます。CodeBuild には Amazon ECR とやりとりしたり Amazon S3 を操作したりするためのアクセス権限が必要です。プロセスの一環として、Docker イメージがビルドされ、Amazon ECR レジストリにプッシュされます。テンプレートとコードの詳細については、「[追加情報](#simplify-application-authentication-with-mutual-tls-in-amazon-ecs-additional)」を参照してください。(オプション) テスト目的でローカルでビルドするには、次のコマンドを使用します。
# login to ECR
aws ecr get-login-password | docker login --username AWS --password-stdin $ECRRepositoryUri

# build image for service one
cd /service1
aws s3 cp s3://$BucketName/serviceone/ service1/ --recursive
docker build -t $ECRRepositoryServiceOneUri .
docker push $ECRRepositoryServiceOneUri

# build image for service two
cd ../service2
aws s3 cp s3://$BucketName/servicetwo/ service2/ --recursive
docker build -t $ECRRepositoryServiceTwoUri .
docker push $ECRRepositoryServiceTwoUri
| DevOps エンジニア | ### 相互 TLS を有効にする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CA 証明書を Amazon S3 にアップロードします。 | CA 証明書を Amazon S3 バケットにアップロードするには、次のコマンド例を使用します。`aws s3 cp ca-cert.pem s3://$BucketName/acm-trust-store/ ` | AWS DevOps、DevOps エンジニア | | トラストストアを作成します。 | トラストストアを作成するには、次のコマンド例を使用します。
TrustStoreArn=`aws elbv2 create-trust-store --name acm-pca-trust-certs \
    --ca-certificates-bundle-s3-bucket $BucketName \
    --ca-certificates-bundle-s3-key acm-trust-store/ca-cert.pem --query 'TrustStores[].TrustStoreArn' --output text`
| AWS DevOps、DevOps エンジニア | | クライアント証明書をアップロードします。 | Docker イメージのクライアント証明書を Amazon S3 にアップロードするには、次のコマンド例を使用します。
# for service one
aws s3 cp client_cert1.cert s3://$BucketName/serviceone/
aws s3 cp client_private-key1.pem s3://$BucketName/serviceone/

# for service two
aws s3 cp client_cert2.cert s3://$BucketName/servicetwo/
aws s3 cp client_private-key2.pem s3://$BucketName/servicetwo/
| AWS DevOps、DevOps エンジニア | | リスナーを変更します。 | ALB で相互 TLS を有効にするには、次のコマンドを使用して HTTPS リスナーを変更します。
aws elbv2 modify-listener \
    --listener-arn $Service1ListenerArn \
    --certificates CertificateArn=$TLS_CERTIFICATE_ARN_TWO \
    --ssl-policy ELBSecurityPolicy-2016-08 \
    --protocol HTTPS \
    --port 8080 \
    --mutual-authentication Mode=verify,TrustStoreArn=$TrustStoreArn,IgnoreClientCertificateExpiry=false

aws elbv2 modify-listener \
    --listener-arn $Service2ListenerArn \
    --certificates CertificateArn=$TLS_CERTIFICATE_ARN_TWO \
    --ssl-policy ELBSecurityPolicy-2016-08 \
    --protocol HTTPS \
    --port 8090 \
    --mutual-authentication Mode=verify,TrustStoreArn=$TrustStoreArn,IgnoreClientCertificateExpiry=false
詳細については、 AWS ドキュメントの[Application Load Balancer での相互 TLS の設定](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/configuring-mtls-with-elb.html)」を参照してください。 | AWS DevOps、DevOps エンジニア | ### サービスを更新する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECS タスク定義を更新します。 | Amazon ECS タスク定義を更新するには、新しいリビジョンで `image` パラメータを変更します。それぞれのサービスの値を取得するには、前のステップで構築した新しい Docker イメージ URI (`echo $ECRRepositoryServiceOneUri` または `echo $ECRRepositoryServiceTwoUri`) でタスク定義を更新します。

    "containerDefinitions": [
        {
            "name": "nginx",
            "image": "public.ecr.aws/nginx/nginx:latest",   # <----- change to new Uri
            "cpu": 0,
詳細については、 AWS ドキュメント[の「コンソールを使用した Amazon ECS タスク定義の更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html)」を参照してください。 | AWS DevOps、DevOps エンジニア | | Amazon ECS サービスを更新します。 | 最新のタスク定義でサービスを更新します。このタスク定義は、新しく構築された Docker イメージのブループリントであり、相互 TLS 認証に必要なクライアント証明書が含まれています。 サービスを更新するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)他のサービスについても、この手順を繰り返します。 | AWS 管理者、AWS DevOps、DevOps エンジニア | ### アプリケーションにアクセスする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーション URL をコピーします。 | Amazon ECS コンソールを使用してタスクを表示します。タスクステータスが**実行中**に更新されたら、タスクを選択します。**[タスク]** セクションで、タスク ID をコピーします。 | AWS 管理者、AWS DevOps | | アプリケーションをテストします。 | アプリケーションをテストするには、ECS Exec を使用してタスクにアクセスします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html) | AWS 管理者、AWS DevOps | ## 関連リソース **Amazon ECS ドキュメント** + [コンソールを使用した Amazon ECS タスク定義の作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html) + [Amazon ECS で使用するコンテナイメージの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html) + [Amazon ECS クラスター](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html) + [の Amazon ECS AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html#create-container-image-next-steps) + [Amazon ECS ネットワーキングのベストプラクティス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/networking-best-practices.html) + [Amazon ECS サービス定義パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html) **その他の AWS リソース** + [AWS プライベート CA を使用して Application Load Balancer で mTLS を設定する方法を教えてください。](https://repost.aws/knowledge-center/elb-alb-configure-private-ca-mtls) (AWS re:Post) ## 追加情報 **Docker ファイルの編集****** 以下のコードは、サービス 1 の Dockerfile で編集するコマンドを示しています。 ``` FROM public.ecr.aws/nginx/nginx:latest WORKDIR /usr/share/nginx/html RUN echo "Returning response from Service 1: Ok" > /usr/share/nginx/html/index.html ADD client_cert1.cert client_private-key1.pem /usr/local/share/ca-certificates/ RUN chmod -R 400 /usr/local/share/ca-certificates/ ``` 以下のコードは、サービス 2 の Dockerfile で編集するコマンドを示しています。 ``` FROM public.ecr.aws/nginx/nginx:latest WORKDIR /usr/share/nginx/html RUN echo "Returning response from Service 2: Ok" > /usr/share/nginx/html/index.html ADD client_cert2.cert client_private-key2.pem /usr/local/share/ca-certificates/ RUN chmod -R 400 /usr/local/share/ca-certificates/ ``` CodeBuild を使用して Docker イメージを構築する場合、`buildspec` ファイルは CodeBuild ビルド番号を使用してイメージバージョンをタグ値として一意に識別します。次の `buildspec ` カスタムコードに示すように、要件に合わせて `buildspec` ファイルを変更できます。 ``` version: 0.2 phases: pre_build: commands: - echo Logging in to Amazon ECR... - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ECR_REPOSITORY_URI - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7) - IMAGE_TAG=${COMMIT_HASH:=latest} build: commands: # change the S3 path depending on the service - aws s3 cp s3://$YOUR_S3_BUCKET_NAME/serviceone/ $CodeBuild_SRC_DIR/ --recursive - echo Build started on `date` - echo Building the Docker image... - docker build -t $ECR_REPOSITORY_URI:latest . - docker tag $ECR_REPOSITORY_URI:latest $ECR_REPOSITORY_URI:$IMAGE_TAG post_build: commands: - echo Build completed on `date` - echo Pushing the Docker images... - docker push $ECR_REPOSITORY_URI:latest - docker push $ECR_REPOSITORY_URI:$IMAGE_TAG - echo Writing image definitions file... # for ECS deployment reference - printf '[{"name":"%s","imageUri":"%s"}]' $CONTAINER_NAME $ECR_REPOSITORY_URI:$IMAGE_TAG > imagedefinitions.json artifacts: files: - imagedefinitions.json ``` # その他のパターン **Topics** + [AWS CloudFormation スタックと関連リソースの削除を自動化する](automate-deletion-cloudformation-stacks-associated-resources.md) + [AWS Service Catalog と を使用して、Gitflow 環境にホットフィックスソリューションをデプロイするための動的パイプライン管理を自動化する AWS CodePipeline](automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.md) + [AWS CDK を使用してマイクロサービス用の CI/CD パイプラインと Amazon ECS クラスターを自動的に構築する](automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.md) + [GitHub Actions と Terraform を使用して Docker イメージを構築し Amazon ECR にプッシュする](build-and-push-docker-images-to-amazon-ecr-using-github-actions-and-terraform.md) + [Blu Age によってモダナイズされたメインフレームワークロードをコンテナ化](containerize-mainframe-workloads-that-have-been-modernized-by-blu-age.md) + [Firelens ログルーターを使用して Amazon ECS 用のカスタムログパーサーを作成する](create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.md) + [Terraform を使用して CrewAI フレームワークで Amazon Bedrock にエージェンティックシステムを展開する](deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.md) + [Terraform を使用して、コンテナ化された Blu Age アプリケーションの環境をデプロイする](deploy-an-environment-for-containerized-blu-age-applications-by-using-terraform.md) + [Amazon SageMaker の推論パイプラインを使用して、前処理ロジックを単一エンドポイントの ML モデルにデプロイする](deploy-preprocessing-logic-into-an-ml-model-in-a-single-endpoint-using-an-inference-pipeline-in-amazon-sagemaker.md) + [Azure DevOps パイプラインからプライベート Amazon EKS クラスターにワークロードをデプロイする](deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.md) + [K8sGPT と Amazon Bedrock の統合を利用して AI を活用した Kubernetes の診断とトラブルシューティングを実装する](implement-ai-powered-kubernetes-diagnostics-and-troubleshooting-with-k8sgpt-and-amazon-bedrock-integration.md) + [AWS コードサービスと AWS KMS マルチリージョンキーを使用して、複数のアカウントとリージョンへのマイクロサービスのブルー/グリーンデプロイを管理](manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.md) + [AWS CDK で Amazon ECS Anywhere を設定して、オンプレミスコンテナアプリケーションを管理します。](manage-on-premises-container-applications-by-setting-up-amazon-ecs-anywhere-with-the-aws-cdk.md) + [Amazon ECS で Oracle WebLogic から Apache Tomcat (ToMee) に移行する](migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs.md) + [ASP.NET ウェブフォームアプリケーションを AWS で最新化](modernize-asp-net-web-forms-applications-on-aws.md) + [AWS CloudFormation と AWS Config を使用して Amazon ECR リポジトリのワイルドカード権限をモニタリングする](monitor-amazon-ecr-repositories-for-wildcard-permissions-using-aws-cloudformation-and-aws-config.md) + [CloudWatch Logs Insights を使用してアプリケーションアクティビティをモニタリングする](monitor-application-activity-by-using-cloudwatch-logs-insights.md) + [AWS CDK と GitLab を使用して、Amazon ECS Anywhere 上のハイブリッドワークロード用に CI/CD パイプラインを設定する](set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.md) + [cert-managerと Let's Encrypt を使用して Amazon EKS のアプリケーションのエンドツーエンド暗号化を設定](set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.md) + [Flux を使用して Amazon EKS マルチテナントアプリケーションのデプロイを簡素化する](simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.md) + [SageMaker AI と Hybrid を使用して、ローカルでの開発からスケーラブルな実験に至るまでの機械学習ワークフローを合理化する](streamline-machine-learning-workflows-by-using-amazon-sagemaker.md) + [AWS Lambda を使用して六角形アーキテクチャで Python プロジェクトを構築する](structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.md) + [LocalStack および Terraform テストを使用して AWS インフラストラクチャをテストする](test-aws-infra-localstack-terraform.md) + [AWS Fargate WaitCondition フック構造を使用してリソースの依存関係とタスク実行を調整する](use-the-aws-fargate-waitcondition-hook-construct.md) + [Amazon Bedrock エージェントを使用してテキストベースのプロンプトで Amazon EKS でのアクセスエントリコントロールの作成を自動化する](using-amazon-bedrock-agents-to-automate-creation-of-access-entry-controls-in-amazon-eks.md) # サーバーレス **Topics** + [AWS Amplify を使用してサーバーレスの React Native モバイルアプリを構築する](build-a-serverless-react-native-mobile-app-by-using-aws-amplify.md) + [複数の SaaS 製品間のテナントを単一のコントロールプレーンで管理する](manage-tenants-across-multiple-saas-products-on-a-single-control-plane.md) + [静的 IP アドレスに関連付けられたエンドポイントを使用して、Amazon S3 の署名付き URL の生成とオブジェクトのダウンロードを統合する](consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.md) + [組織でクロスアカウント Amazon EventBridge 接続を作成する](create-cross-account-amazon-eventbridge-connection-organization.md) + [で Kinesis Data Streams と Firehose を使用して Amazon S3 に DynamoDB レコードを配信する AWS CDK](deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk.md) + [Amazon API Gateway でカスタムドメインを使用してパスベースの API バージョニングを実装する](implement-path-based-api-versioning-by-using-custom-domains.md) + [psycopg2 ライブラリを にインポート AWS Lambda して PostgreSQL データベースとやり取りする](import-psycopg2-library-lambda.md) + [Amazon API Gateway を Amazon SQS と統合して非同期 REST API を処理する](integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.md) + [Amazon API Gateway と AWS Lambda を使用してイベントを非同期的に処理する](process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.md) + [Amazon API Gateway と Amazon DynamoDB Streams を使用してイベントを非同期的に処理する](processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.md) + [Amazon API Gateway、Amazon SQS、および AWS Fargate でイベントを非同期的に処理する](process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.md) + [AWS Step Functions から AWS Systems Manager Automation タスクを同期的に実行する](run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions.md) + [AWS Lambda 関数で Python を使用して S3 オブジェクトの並列読み取りを実行する](run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.md) + [から OpenSearch AWS Lambda にテレメトリデータを送信してリアルタイムの分析と視覚化を行う](send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.md) + [セルベースアーキテクチャ用にサーバーレスセルルーターを設定する](serverless-cell-router-architecture.md) + [VPC エンドポイントを介して Amazon S3 バケットへのプライベートアクセスを設定する](set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.md) + [Amazon Bedrock AWS Step Functions を使用して の状態をトラブルシューティングする](troubleshooting-states-in-aws-step-functions.md) + [その他のパターン](serverless-more-patterns-pattern-list.md) # AWS Amplify を使用してサーバーレスの React Native モバイルアプリを構築する *Amazon Web Services、Deekshitulu Pentakota* ## 概要 このパターンでは、AWS Amplify と以下の AWS サービスを使用して React Native モバイルアプリのサーバーレスバックエンドを作成する方法を説明しています。　 + AWS AppSync + Amazon Cognito + Amazon DynamoDB Amplify を使用してアプリケーションのバックエンドを設定してデプロイすると、Amazon Cognito はアプリケーションユーザーを認証し、アプリケーションへのアクセスを許可します。　 次に、AWS AppSync はフロントエンドアプリケーションおよびバックエンドの DynamoDB テーブルとやり取りし、データを作成して取得します。 **注記** このパターンでは、例としてシンプルな「ToDoList」アプリを使用しますが、同様の手順を使用して、任意の React Native モバイルアプリケーションを作成できます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + [AWS コマンドラインインターフェイス (AWS CLI)](https://docs.amplify.aws/cli/start/install/) がインストール済みおよび設定済み + XCode (任意のバージョン) + Microsoft Visual Studio (任意のバージョン、任意のコードエディター、任意のテキストエディター) + Amplify Gurify に精通している + Amazon Cognito に精通している + AWS AppSync に精通している + DynamoDB に精通している + Node.js に精通している + npm に精通している + React と React Native に精通している + JavaScript と ECMAScript 6 (ES6) に精通している + GraphQL に精通している ## アーキテクチャ 次の図は、AWS クラウドで React Native モバイルアプリのバックエンドを実行するためのアーキテクチャの例を示しています。 ![\[AWS サービスで React Native モバイルアプリを実行するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c95e0150-5762-4c90-946c-efa3a22913e4/images/5beff5f9-9d14-49dc-a046-b74e5bfbd13f.png) 以下は、アーキテクチャ図を示しています。 1. Amazon Cognito はアプリユーザーを認証し、アプリへのアクセスを許可します。　 1. 次に、AWS AppSync はフロントエンドアプリおよびバックエンドの DynamoDB テーブルとやり取りし、データを作成して取得します。 ## ツール **AWS サービス** + [AWS Amplify](https://docs.aws.amazon.com/amplify/latest/userguide/welcome.html) は、フロントエンドのウェブおよびモバイルデベロッパーが AWS で迅速かつ簡単にフルスタックアプリケーションを構築できるようにする専用のツールと機能のセットです。 + [AWS AppSync](https://docs.aws.amazon.com/appsync/latest/devguide/what-is-appsync.html) は、Amazon DynamoDB、AWS Lambda、および HTTP API を含む、複数のソースからのデータを組み合わせることで、アプリケーション開発者にとって便利でスケーラブルな GraphQL インターフェイスを提供します。 + [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) は、ウェブおよびモバイルアプリの認証、認可、およびユーザー管理機能を提供します。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを発揮します。 **コード** このパターンで使用されているサンプルアプリケーションのコードは、GitHub [aws-amplify-react-native-ios-todo-app](https://github.com/aws-samples/aws-amplify-react-native-ios-todo-app) リポジトリから入手できます。このサンプルファイルを使用するには、このパターンの [**エピック**] セクションの指示に従ってください。 ## エピック ### React Native アプリを作成して実行します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | React Native 開発環境のセットアップ | 手順については、React Native ドキュメントの「[開発環境のセットアップ](https://reactnative.dev/docs/next/environment-setup)」を参照してください。 | アプリ開発者 | | iOS シミュレーターで ToDoList React Native モバイルアプリを作成して実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | アプリ開発者 | ### アプリの新しいバックエンド環境を初期化します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AAmplify でアプリをサポートするために必要なバックエンドサービスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)このパターンで使用する TodoList アプリの設定には、以下の設定例を適用してください。**React Native Amplify アプリの構成設定の例**
? Name: ToDoListAmplify

? Environment: dev

? Default editor: Visual Studio Code

? App type: javascript

? Javascript framework: react-native

? Source Directory Path: src

? Distribution Directory Path: /

? Build Command: npm run-script build

? Start Command: npm run-script start

? Select the authentication method you want to use: AWS profile

? Please choose the profile you want to use: default
詳細については、Amplify Dev Center ドキュメントの「[新しい Amplify バックエンドの作成](https://docs.amplify.aws/lib/project-setup/create-application/q/platform/js/#create-a-new-amplify-backend)」を参照してください。`amplify init` コマンドは、[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用して以下のリソースをプロビジョニングします。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | アプリ開発者 | ### Amplify React Native アプリに Amazon Cognito 認証を追加する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon Cognito 認証サービスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)このパターンで使用する TodoList アプリの設定には、以下の設定例を適用してください。**認証サービスの設定例**
? Do you want to use the default authentication and security configuration? \ 
Default configuration
 
? How do you want users to be able to sign in? \ 
Username 

? Do you want to configure advanced settings? \ 
No, I am done
`amplify add auth` コマンドは、プロジェクトのルートディレクトリ内のローカルフォルダ (**amplify**) に、必要なフォルダ、ファイル、依存関係ファイルを作成します。このパターンで使用する TodoList アプリの設定では、この目的で **aws-exports.js** が作成されます。 | アプリ開発者 | | Amazon Cognito サービスを AWS クラウドにデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)プロジェクトにデプロイされたサービスを確認するには、以下のコマンドを実行して Amplify コンソールに移動します。`amplify console` | アプリ開発者 | | React Native に必要な Amplify ライブラリをインストールし、iOS には CocoaPods 依存関係をインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | アプリ開発者 | | Amplify サービスをインポートして設定します。 | アプリのエントリポイントファイル (**App.js** など) で、次のコード行を入力することで、Amplify サービスの設定ファイルをインポートして読み込みます。
import Amplify from 'aws-amplify'
import config from './src/aws-exports'
Amplify.configure(config)
Amplify サービスをアプリのエントリポイントファイルにインポートした後にエラーが発生した場合は、アプリを停止してください。次に、XCode を開き、プロジェクトの iOS フォルダーから **TodoListAmplify.xcWorkspace** を選択して、アプリを実行します。 | アプリ開発者 | | WithAuthenticator 高次コンポーネント (HOC) を使用するようにアプリのエントリポイントファイルを更新します。 | `withAuthenticator` HOC は、わずか数行のコードを使用して、サインイン、サインアップ、パスワードを忘れた場合のワークフローをアプリ内で実現します。詳細については、Amplify Dev Center で「[オプション 1: ビルド済み UI コンポーネントを使用する](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#option-1-use-pre-built-ui-components)」を参照してください。また、React ドキュメントの [高次コンポーネント](https://reactjs.org/docs/higher-order-components.html) についても説明します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)**WithAuthenticator HOC コード例**
import Amplify from 'aws-amplify'
import config from './src/aws-exports'
Amplify.configure(config)
import { withAuthenticator } from 'aws-amplify-react-native';


const App = () => {
  return null;
};


export default withAuthenticator(App);
iOS シミュレーターでは、アプリには Amazon Cognito サービスが提供するログイン画面が表示されます。 | アプリ開発者 | | 認証サービスの設定をテストします。 | iOS シミュレータで、以下の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)[Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/)を開いて、**アイデンティティプール**に新しいユーザーが作成されたかどうかを確認することもできます。 | アプリ開発者 | ### AWS AppSync API と DynamoDB データベースをアプリにコネクトします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS AppSync API と DynamoDB データベースを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)このパターンで使用する TodoList アプリの設定には、以下の設定例を適用してください。**API とデータベースの設定例**
? Please select from one of the below mentioned services: \ 
GraphQL 

? Provide API name: todolistamplify

? Choose the default authorization type for the API \ 
Amazon Cognito User Pool

Do you want to use the default authentication and security configuration

? Default configuration How do you want users to be able to sign in? \ 
Username

Do you want to configure advanced settings? \ 
No, I am done.

? Do you want to configure advanced settings for the GraphQL API \ 
No, I am done.

? Do you have an annotated GraphQL schema? \ 
No

? Choose a schema template: \ 
Single object with fields (e.g., "Todo" with ID, name, description)

? Do you want to edit the schema now? \ 
Yes
**GraphQL スキーマの例**
 type Todo @model {
   id: ID!
   name: String!
   description: String
}
| アプリ開発者 | | AWS AppSync API をデプロイします。　 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)このパターンで使用する TodoList アプリの設定には、以下の設定例を適用してください。**AWS AppSync API の設定例**次の設定では、AWS AppSync に GraphQL API を作成し、Dynamo DB に **Todo** テーブルを作成します。
 ? Are you sure you want to continue? Yes
? Do you want to generate code for your newly created GraphQL API Yes
? Choose the code generation language target javascript
? Enter the file name pattern of graphql queries, mutations and subscriptions src/graphql/**/*.js
? Do you want to generate/update all possible GraphQL operations - \ 
queries, mutations and subscriptions Yes
? Enter maximum statement depth \
[increase from default if your schema is deeply nested] 2
| アプリ開発者 | | アプリのフロントエンドを AWS AppSync API に接続します。 | このパターンで提供されているサンプル TodoList アプリケーションを使用するには、[aws-amplify-react-native-ios-todo-app](https://github.com/aws-samples/aws-amplify-react-native-ios-todo-app) GitHub リポジトリの **App.js** ファイルからコードをコピーします。次に、サンプルコードをローカル環境に統合します。リポジトリの **App.js** ファイルにあるサンプルコードは以下の処理を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | アプリ開発者 | ## 関連リソース + 「[AWS Amplify](https://aws.amazon.com/amplify/)」 + [Amazon Cognito](https://aws.amazon.com/cognito/) + [AWS AppSync](https://aws.amazon.com/appsync/) + 「[Amazon DynamoDB](https://aws.amazon.com/dynamodb/)」 + 「[React](https://reactjs.org/)」 (React ドキュメント) # 複数の SaaS 製品間のテナントを単一のコントロールプレーンで管理する *Amazon Web Services、Ramanna Avancha、Kishan Kavala、Anusha Mandava、Jenifer Pascal* ## 概要 このパターンは、AWS クラウドの単一のコントロールプレーンで、複数の Software as a Service (SaaS) 製品にまたがるテナントのライフサイクルを管理する方法を示しています。提供されるリファレンスアーキテクチャは、組織が個々の SaaS 製品間で冗長な共有機能の実装を減らし、ガバナンスの効率性を大幅に向上させるのに役立ちます。 大手企業は、さまざまなビジネスユニット間で複数のSaaS製品を保有できます。多くの場合、これらの製品は、さまざまなサブスクリプションレベルの外部テナントが使用できるようにプロビジョニングする必要があります。共通のテナントソリューションがない場合、IT 管理者はコア製品の機能開発に集中するのではなく、複数のSaaS API 間で差別化されていない機能の管理に時間を費やす必要があります。 このパターンで提供される共通テナントソリューションは、次のような組織の共有 SaaS 製品機能の多くを一元管理するのに役立ちます。 + セキュリティ + テナントプロビジョニング + テナントデータストレージ + テナントコミュニケーション + 製品管理 + マトリックス記録とモニタリング ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + Amazon Cognito または第三者の ID プロバイダー (IdP) に関する知識 + Amazon API Gateway に関する知識 + AWS Lambda に関する知識 + Amazon DynamoDB に関する知識 + AWS Identity and Access Management (IAM) + AWS Step Functions に関する知識 + AWS CloudTrail と Amazon CloudWatch に関する知識 + Python ライブラリとコードに関する知識 + さまざまなタイプのユーザー (組織、テナント、管理者とアプリケーションユーザー)、サブスクリプションモデルとテナント分離モデルを含む SaaS API に関する知識 + 組織のマルチプロダクト SaaS 要件とマルチテナントサブスクリプションに関する知識 **制限事項** + 一般的なテナントソリューションと個々の SaaS 製品との統合は、このパターンには含まれていません。 + このパターンでは、Amazon Cognito サービスは単一の AWS リージョンにのみデプロイされます。 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon API Gateway + Amazon Cognito + AWS CloudTrail + Amazon CloudWatch + Amazon DynamoDB + IAM + AWS Lambda + Amazon Simple Storage Service (Amazon S3) + Amazon Simple Notification Service (Amazon SNS) + AWS Step Functions **ターゲットアーキテクチャ** 次の図は、AWS クラウドの 1 つのコントロールプレーンで複数の SaaS 製品間におけるテナントライフサイクルを管理するためのワークフローの例を示しています。 ![\[1 つのコントロールプレーンでテナントライフサイクルを管理するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4306bc76-22a7-45ca-a107-43df6c6f7ac8/images/700faf4d-c28f-4814-96aa-2d895cdcb518.png) この図表は、次のワークフローを示しています: 1. AWS ユーザーは、API ゲートウェイエンドポイントを呼び出して、テナントのプロビジョニング、製品のプロビジョニングまたは管理関連のアクションを開始します。 1. ユーザーは、Amazon Cognito ユーザープールまたは別の IdP から取得したアクセストークンにより認証されます。 1. 個々のプロビジョニングまたは管理タスクは、API Gateway API エンドポイントと統合された Lambda 関数により、実行されます。 1. 共通テナントソリューション (テナント、製品、ユーザー用) の管理 API は、必要な入力パラメータ、ヘッダー、トークンをすべて収集します。その後、管理 API は関連する Lambda 関数を呼び出します。 1. 管理 API と Lambda 関数の両方の IAM 権限は、IAM サービスにより、検証されます。 1. Lambda 関数は、DynamoDB と Amazon S3 のカタログ (テナント、製品、ユーザー用) のデータを保存し、取得します。 1. アクセス権限が検証されると、特定のタスクを実行するために、AWS Step Functions ワークフローが呼び出されます。この図の例は、テナントのプロビジョニングワークフローを示しています。 1. 個々の AWS Step Functions ワークフロータスクは、あらかじめ決められたワークフロー (ステートマシン) で実行されます。 1. 各ワークフロータスクに関連付けられた Lambda 関数の実行に必要かつ重要なデータは、DynamoDB または Amazon S3 から取得されます。他の AWS リソースは、AWS CloudFormation テンプレートでプロビジョニングする必要がある場合があります。 1. 必要に応じて、ワークフローは特定の SaaS 製品用に追加の AWS リソースをプロビジョニングするリクエストをその製品の AWS アカウントに送信します。 1. リクエストが成功または失敗する場合、ワークフローはステータス更新をメッセージとして Amazon SNS トピックに発行します。 1. Amazon SNS は Step Functions ワークフローの Amazon SNS トピックにサブスクライブされています。 1. 次に、Amazon SNS はその後、ワークフローステータスの更新を AWS ユーザーに送り返します。 1. API 呼び出しの監査証跡を含む各 AWS サービスのアクションのログは CloudWatch に送信されます。CloudWatch では、ユースケースごとに特定のルールとアラームを設定できます。 1. ログは監査の目的で Amazon S3 バケットにアーカイブされます。 **自動化とスケール** このパターンは、CloudFormation テンプレートで、共通テナントソリューションのデプロイの自動化に役立ちます。このテンプレートは、関連するリソースの迅速なスケールアップまたはスケールダウンにも役立ちます。 詳細については、*AWS CloudFormation ユーザーガイド*の「[AWS CloudFormation テンプレートの使用](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)」を参照してください。 ## ツール **AWS サービス** + 「[Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)」は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) は、ウェブおよびモバイルアプリの認証、認可、およびユーザー管理機能を提供します。 + 「[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)」は、AWS アカウントのガバナンス、コンプライアンス、運用のリスクの監査をサポートします。 + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、AWS のリソースや、AWS で実行されるアプリケーションをリアルタイムにモニタリングします。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、量にかかわらず、データを保存、保護、取得するのに役立つクラウドベースのオブジェクトストレージサービスです。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)は、AWS Lambda関数と他のAWS サービスを組み合わせてビジネスクリティカルなアプリケーションを構築できるサーバーレスオーケストレーションサービスです。 ## ベストプラクティス このパターンのソリューションでは、単一のコントロールプレーンで複数のテナントのオンボーディングを管理し、複数のSaaS製品へのアクセスをプロビジョニングします。コントロールプレーンは、管理ユーザーがほかの 4 つの機能に固有のプレーンを管理することに役立ちます。 + セキュリティプレーン + ワークフロープレーン + コミュニケーションプレーン + ログ記録とモニタリング ## エピック ### セキュリティプレーンの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | マルチテナント SaaS プラットフォームの要件を確立します。 | 以下の要件の詳細を確立します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html) | クラウドアーキテクト、AWS システム管理者 | | Amazon Cognito サービスを設定します。 | 「*Amazon Cognito 開発者ガイド*」の「[Amazon Cognito の使用開始方法](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-getting-started.html)」に記載されている指示に従ってください。 | クラウドアーキテクト | | 必要な IAM ポリシーを設定します。 | ユースケースに必要なIAMポリシーを作成します。その後、ポリシーを Amazon Cognito の IAM ロールにマッピングします。詳細については、*Amazon Cognito デベロッパーガイド*の「[ポリシーを使用したアクセスの管理](https://docs.aws.amazon.com/cognito/latest/developerguide/security-iam.html#security_iam_access-manage)」と「[ロールベースアクセスコントロール](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html)」を参照してください。 | クラウド管理者、クラウドアーキテクト、AWS IAM sセキュリティ | | 必要な API アクセス権限を設定します。 | IAM ロールとポリシーおよび Lambda 認証で API Gatewayのアクセス権限を設定します。手順については、「*Amazon API Gateway 開発者ガイド*」の以下のセクションを参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html) | クラウド管理者、クラウドアーキテクト | ### データプレーンの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 必要なデータカタログを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)詳細については、*Amazon DynamoDB デベロッパーガイド*の「[DynamoDB のセットアップ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SettingUp.html)」を参照してください。 | DBA | ### コントロールプレーンの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数と API Gateway API を作成して、必要なコントロールプレーンタスクを実行します。 | Lambda 関数と API Gateeway API を個別に作成して、次の項目の追加、削除と管理を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)詳細については、*AWS Lambda デベロッパーガイド*の「[Amazon API Gateway での AWS Lambda の使用](https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html)」を参照してください。 | アプリ開発者 | ### ワークフロープレーンを設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Step Functions ワークフローが実行する必要のあるタスクを特定します。 | 次の AWS Step Functions ワークフロー要件の詳細を特定して文書化します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)主要な利害関係者が要件を承認していることを確認してください。 | アプリ所有者 | | 必要な AWS Step Functions ワークフローを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html) | アプリ開発者、ビルドリード | ### コミュニケーションプレーンの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon SNS トピックを作成します。 | Amazon SNS トピックを作成して、以下に関する通知を受信します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)詳細については、*Amazon SNS デベロッパーガイド*の「[SNS トピックの作成](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html)」を参照してください。 | アプリ所有者、Cloud アーキテクト | | エンドポイントを各 Amazon SNS トピックにサブスクライブします。 | Amazon SNS トピックにパブリッシュされたメッセージを受信するには、各トピックにエンドポイントをサブスクライブする必要があります。詳細については、*Amazon SNS デベロッパーガイド*の「[Amazon SNS トピックのサブスクライブ](https://docs.aws.amazon.com/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html)」を参照してください。 | アプリ開発者、Cloud アーキテクト | ### 記録プレーンとモニタリングプレーンの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 共通テナントソリューションの各コンポーネントの記録を有効にします。 | 作成した共通テナントソリューション内の各リソースの記録をコンポーネントレベルで有効にします。手順については、以下を参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)IAM ポリシーを使用することで、各リソースのログを一元化されたロギングアカウントに統合できます。詳細については、「[集中記録と複数アカウントのセキュリティガードレール](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/centralized-logging-and-multiple-account-security-guardrails.html)」を参照してください。 | アプリ開発者、AWS システム管理者、クラウド管理者 | ### 共通テナントソリューションのプロビジョニングとデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation テンプレートを作成します。 | CloudFormation テンプレートを使用して、共通テナントソリューション全体とそのすべてのコンポーネントのデプロイとメンテナンスを自動化します。詳細については、「[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)」を参照してください。 | アプリ開発者、DevOpsエンジニア、CloudFormation 開発者 | ## 関連リソース + [Amazon Cognito ユーザープールをオーソライザーとして使用して REST API へのアクセスを制御する](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)(*Amazon API Gateway デベロッパーガイド*) + [API Gateway Lambda オーソライザーを使用する](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)(*Amazon API Gateway デベロッパーガイド*) + [Amazon Cognito ユーザープール](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)(*Amazon Cognito デベロッパーガイド*) + [クロスアカウントクロスリージョン CloudWatch コンソール](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)(*Amazon CloudWatch ユーザーガイド*) # 静的 IP アドレスに関連付けられたエンドポイントを使用して、Amazon S3 の署名付き URL の生成とオブジェクトのダウンロードを統合する *Song Jin、Eunhye Jo、Jun Soung Lee (Amazon Web Services)* ## 概要 このパターンは、オブジェクトのダウンロード用に安全なカスタム署名付き URL を作成することで、Amazon Simple Storage Service (Amazon S3) へのアクセスを簡素化します。このソリューションは、一意のドメインと静的 IP アドレスを持つ、単一のエンドポイントを提供します。これは、API エンドポイントと Amazon S3 エンドポイントの両方を、静的 IP アドレスを持つ統合ドメインに集約する必要があるユーザー向けにカスタマイズされています。このユースケースでは、ユーザーが IP とドメインの許可リストのファイアウォールポリシーに従い、API アクセスを特定のドメインと IP アドレスに制限します。 このアーキテクチャでは AWS のサービス、Amazon API Gateway AWS Global Accelerator、 AWS Lambda Application Load Balancer AWS PrivateLink、Amazon S3 などのキーを使用します。この設計では、署名付き URL を生成するための API と Amazon S3 エンドポイントを 1 つのドメインに一元化し、2 つの静的 IP アドレスを持つアクセラレーターにリンクします。これにより、ユーザーが署名付き URL をリクエストし、静的 IP アドレスを持つ統合ドメインエンドポイントを介して Amazon S3 オブジェクトをダウンロードする一連の流れがスムーズになります。 このアーキテクチャは、厳格なポリシーやコンプライアンス要件を持つ、公共部門、医療、金融などのユーザーにとって特に有益です。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + カスタムドメインのパブリックホストゾーン + AWS リージョン 任意の で AWS Certificate Manager (ACM) にインポートされたドメイン **制限事項** + Amazon S3 バケット名はエンドポイントのドメイン名と一致する必要があります。この要件の目的は、単一の API エンドポイント経由で Amazon S3 エンドポイントにサービスを提供できるようにすることです。 + API Gateway で使用されるカスタムドメイン名は、単一の API エンドポイントのドメイン名と一致する必要があります。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択してください。 ## アーキテクチャ 次の図は、このパターンのターゲットアーキテクチャとワークフローを示したものです。 ![\[署名付き URL の生成とオブジェクトのダウンロードのためのコンポーネントとワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e19ebcb5-2138-481e-952e-3cfee9ad9e97/images/effd197c-d4d7-4990-8b66-3eb1c64aab4c.png) この図は、次の概念とワークフローを示しています。 1. ユーザーは、カスタムドメイン名と関連する IP アドレスを使用して AWS Global Accelerator、 を通じて提供されるカスタムエンドポイントを使用して署名付き URL を生成するリクエストを開始します。 1. Lambda 関数は、カスタムエンドポイントを指す署名付き URL を生成します。生成された署名付き URL を含む 301 リダイレクトで応答します。ユーザーはリダイレクトされた署名付き URL を通じて、Global Accelerator から提供されるカスタムエンドポイントを使用し、オブジェクトを自動的にダウンロードします。 署名付き URL を生成し、オブジェクトをダウンロードするワークフローのアーキテクチャ全体のコンポーネントは、次のとおりです。 + Global Accelerator による静的 IP アドレスのプロビジョニング。 + アクセラレーターのエイリアスを、Amazon Route 53 パブリックホストゾーンに A レコードとしてカスタムドメイン名で登録。 + 登録されたカスタムドメイン名と一致するバケット名を持つ Amazon S3 バケットの作成。 + API Gateway と Amazon S3 サービスの VPC エンドポイントの作成。 + Global Accelerator に接続するための内部向け Application Load Balancer の設定。 + ACM 証明書がアタッチされた API Gateway のカスタムドメイン名の割り当て。 + Lambda 関数と統合されたプライベート API Gateway のデプロイ。 + Lambda 関数には、 AWS Identity and Access Management (IAM) ロールがアタッチされています ([GetObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html) アクセス許可があります）。 ## ツール **AWS のサービス** + [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/) は、複数のアベイラビリティーゾーンにある Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなどの複数のターゲットに、受信するアプリケーショントラフィックを分散します。 + [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) は、 AWS ウェブサイトとアプリケーションを保護するパブリックおよびプライベート SSL/TLS X.509 証明書とキーの作成、保存、更新に役立ちます。 + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) は、複数の AWS リージョンのエンドポイントをサポートするグローバルサービスです。 AWS グローバルネットワーク経由で最適なエンドポイントにトラフィックを誘導するアクセラレーターを作成できます。これにより、世界中のユーザーが使用するインターネットアプリケーションの可用性とパフォーマンスが向上します。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) は、仮想プライベートクラウド (VPC) から VPC 外のサービスへの一方向のプライベート接続を確立するのに役立ちます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS ウェブサービスです。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。 **その他のツール** + [Terraform](https://www.terraform.io/) は HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 **コードリポジトリ** このパターンは、必要に応じて AWS CDK または Terraform を使用してデプロイできます。「[エピック](#consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses-epics)」セクションには、両方のデプロイ方法の手順を記載しています。このパターンのコードは、GitHub 内の以下のリポジトリで入手できます。 + **AWS CDK** – [s3-presignedurl-staticips-endpoint-with-cdk](https://github.com/aws-samples/s3-presignedurl-staticips-endpoint-with-cdk) + **Terraform** – [s3-presignedurl-staticips-endpoint-with-terraform](https://github.com/aws-samples/s3-presignedurl-staticips-endpoint-with-terraform) ## ベストプラクティス + 本番環境のセキュリティを強化するには、[Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) などの認可メカニズムを実装して、`PresignedUrl` 生成 API へのアクセスを制限することが重要です。 + 最小特権の原則に従い、タスクの実行に必要最小限のアクセス許可を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 ## エピック ### 環境の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ドメイン名の決定 | 統合 Amazon S3 エンドポイントのパブリックドメイン名を決定します。このドメイン名は Amazon S3 バケット名としても使用されます。 | AWS 管理者、ネットワーク管理者 | | パブリックホストゾーンの作成 | Amazon Route 53 に[パブリックホストゾーン](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html)を作成します。このドメイン名は、API Gateway で使用されるドメイン名と一致する必要があります。 | AWS 管理者、ネットワーク管理者 | | SSL 証明書の準備 | AWS Certificate Manager (ACM) を使用して、ウェブアプリケーションドメインの SSL 証明書を[リクエスト](https://docs.aws.amazon.com/acm/latest/userguide/acm-public-certificates.html)または[インポート](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html)します。 | AWS 管理者、ネットワーク管理者 | ### Terraform を使用してパターンをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Terraform 開発環境の設定 | 開発環境を設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 管理者、クラウド管理者 | | `.tfvars` および** **`provider.tf` ファイルの変更 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html)次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 管理者、クラウド管理者 | | ネットワークリソースのプロビジョニング | ネットワークリソースをプロビジョニングするには、次のコマンドを実行します。
cd ./2.vpc_alb_ga
terraform init
terraform plan --var-file=apg.tfvars
terraform apply --var-file=apg.tfvars
`apply ` コマンドの実行中、確認を求められたら「**yes**」と入力します。 | AWS 管理者、クラウド管理者 | | API Gateway、Amazon S3、Lambda のプロビジョニング | ネットワークリソースをプロビジョニングするには、次のコマンドを使用します。
cd ./2.apigw_s3_lambda
terraform init
terraform plan --var-file=apg.tfvars
terraform apply --var-file=apg.tfvars
| AWS 管理者、クラウド管理者 | ### を使用してパターンをデプロイする AWS CDK | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CDK 開発環境を設定します。 | 開発環境を設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 管理者、クラウド管理者 | | `config/index.ts` ファイルでドメイン設定を指定する | 定数変数のオプションを編集するには、次のコマンドを使用します。
export const options = {
    certificateArn: '{arn of the acm which created before}',
    dnsAttr: {
        zoneName: '{public hosted zone name}',
        hostedZoneId: 'hosted zone Id',
    },
    domainNamePrefix: '{Prefix for the domain}',
    presignPath: 'presign',
    objectsPath: 'objects',
};
コマンドの各プレースホルダーを、必要な情報に置き換えます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 管理者、クラウド管理者 | | スタックのデプロイ | 仮想プライベートクラウド (VPC) 用とアプリケーション用の 2 つのスタックをデプロイするには、次のコマンドを使用します。
$ npm install 
$ cdk synth 
$ cdk deploy --all
| AWS 管理者、クラウド管理者 | ### パターンをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | エンドポイントの IP アドレスの確認 | このパターンのドメインに静的 IP アドレスがあることを確認するには、次のコマンドを使用します。
nslookup ${s3-bucket-prefix}.${domain}
| ネットワーク管理者 | | 後からダウンロード可能なテストファイルをアップロード | テストファイルを、Amazon S3 バケットの `'/objects'` フォルダにアップロードします。 | AWS 管理者、クラウド管理者 | | 署名付き URL を生成する API を起動 | 署名付き URL を生成するには、ブラウザまたは API クライアント ([Postman](https://www.postman.com/product/what-is-postman/) など) から次の形式で URL を呼び出します。
https://${s3-bucket-prefix}.${domain}/presign/objects/${uploaded-filename}
`${s3-bucket-prefix}` および `${domain}` のプレースホルダー値を、前のステップで設定した各値に置き換えます。 | アプリ所有者 | | 結果を確認 | 期待される結果は、301 (Moved Permanently) リダイレクトステータスコードを受け取ることです。このレスポンスには、テストファイルのダウンロードを自動的に開始する署名付き URL が含まれます。 | テストエンジニア | ### Terraform でのクリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | API Gateway、Amazon S3、および Lambda リソースの破棄 | 次のコマンドを使用して、各リソースを削除します。
cd ./2.apigw_s3_lambda
terraform init
terraform plan --destroy --var-file=apg.tfvars
terraform destroy --var-file=apg.tfvars
| AWS 管理者、クラウド管理者 | | ネットワークリソースの破棄 | 次のコマンドを使用して、各ネットワークリソースを削除します。
cd ./1.vpc_alb_ga
terraform init
terraform plan --destroy --var-file=apg.tfvars
terraform destroy --var-file=apg.tfvars
| AWS 管理者、クラウド管理者 | ### でクリーンアップする AWS CDK | タスク | 説明 | 必要なスキル | | --- | --- | --- | | スタックの破棄 | VPC スタックとアプリケーションスタックの両方を破棄するには、次のコマンドを使用します。
$ cdk destroy --all
| AWS 管理者、クラウド管理者 | | Amazon S3 バケットを空にして削除する | デフォルトでは削除されない、オブジェクトの Amazon S3 バケットとログの Amazon S3 バケットを[空](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)にして[削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)します。これらの Amazon S3 バケット名は `${s3-bucket-prefix}.${domain}` と `${s3-bucket-prefix}.${domain}-logs` です。バケットの削除に [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) を使用する場合は、次のコマンドを使用します。
$ aws s3 rm s3://${s3-bucket-prefix}.${domain} --recursive
$ aws s3 rb s3://${s3-bucket-prefix}.${domain} --force
$ aws s3 rm s3://${s3-bucket-prefix}.${domain}-logs --recursive
$ aws s3 rb s3://${s3-bucket-prefix}.${domain}-logs --force
`${s3-bucket-prefix}` と `${domain}` を、前のステップで設定した値に置き換えます。 | AWS 管理者、クラウド管理者 | ## 関連リソース **AWS ブログ** + [が提供する静的 IP アドレスを介した Amazon API Gateway へのアクセス AWS Global Accelerator](https://aws.amazon.com/blogs/networking-and-content-delivery/accessing-an-aws-api-gateway-via-static-ip-addresses-provided-by-aws-global-accelerator/) + [JavaScript AWS CDK 用の署名付き URL をモジュラーで生成する](https://aws.amazon.com/blogs/developer/generate-presigned-url-modular-aws-sdk-javascript/) + [Hosting Internal HTTPS Static Websites with ALB, S3, and PrivateLink](https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/) # 組織でクロスアカウント Amazon EventBridge 接続を作成する *Amazon Web Services、Sam Wilson および Robert Stone* ## 概要 大規模な分散システムでは、Amazon EventBridge を使用して、 AWS Organizations 組織内のさまざまな Amazon Web Services (AWS) アカウント間で状態の変化を通信します。しかし、EventBridge は通常、同じ AWS アカウント内のエンドポイントまたはコンシューマーのみをターゲットにできます。例外は、別のアカウントのイベントバスです。そのイベントバスは有効なターゲットです。別のアカウントのイベントバスからイベントを使用するには、イベントをソースアカウントのイベントバスから送信先アカウントのイベントバスに反映する必要があります。異なる 内のアプリケーション間で重要なイベントを管理する際の課題を回避するには AWS アカウント、このパターンで示されている推奨アプローチを使用します。 このパターンは、 AWS Organizations 組織 AWS アカウント 内の複数の が関与する EventBridge を使用してイベント駆動型アーキテクチャを実装する方法を示しています。このパターンでは AWS Cloud Development Kit (AWS CDK) Toolkit と を使用します AWS CloudFormation。 EventBridge には、イベントを受信、フィルタリング、変換、ルーティング、配信するのに役立つサーバーレスのイベントバスが用意されています。イベント駆動型アーキテクチャの重要なコンポーネントである EventBridge は、メッセージの作成者とそのメッセージの使用者の分離に対応しています。これは、単一のアカウントでは簡単です。マルチアカウント構成では、1 つのアカウントのイベントバス上のイベントを同じ組織内の他のアカウントで使用するために、さらなる考慮が必要です。 作成者と使用者のアカウント固有の考慮事項については、「[追加情報](#create-cross-account-amazon-eventbridge-connection-organization-additional)」セクションを参照してください。 ## 前提条件と制限 **前提条件** + 少なくとも 2 つの が関連付けられている AWS Organizations 組織 AWS アカウント + を使用して両方の でインフラストラクチャをプロビジョニング AWS アカウント できる の AWS Identity and Access Management (IAM) ロール AWS アカウント AWS CloudFormation + Git が[ローカルにインストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)されている + AWS Command Line Interface (AWS CLI) [ローカルにインストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)されている + AWS CDK [ローカルにインストール](https://docs.aws.amazon.com/cdk/latest/guide/cli.html)され、両方の で[ブートストラップされている](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-howto) AWS アカウント **製品バージョン** このパターンは、次のツールとバージョンを使用して構築され、テストされています。 + AWS CDK ツールキット 2.126.0 + Node.js 18.19.0 + npm 10.2.3 + Python 3.12 このパターンは、任意のバージョンの AWS CDK v2 または npm で動作する必要があります。Node.js のバージョン 13.0.0～13.6.0 は AWS CDKと互換性がありません。 ## アーキテクチャ **ターゲットアーキテクチャ** 次の図は、あるアカウントからイベントを送信し、別のアカウントで消費するためのアーキテクチャワークフローを示しています。 ![\[送信元のプロデューサーアカウントと送信先のコンシューマーアカウントを接続する 3 ステップのプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/34a5f3ae-511d-4636-999f-c73396770117/images/ccc4878a-6281-4a77-a483-4e6f299d7807.png) ワークフローの主なステップは、次のとおりです。 1. ソースアカウントのプロデューサー AWS Lambda 関数は、アカウントの EventBridge イベントバスにイベントを配置します。 1. クロスアカウント EventBridge ルールは、送信先アカウントの EventBridge イベントバスにイベントをルーティングします。 1. 送信先アカウントの EventBridge イベントバスには、コンシューマー Lambda 関数を呼び出すターゲット Lambda ルールがあります。 ベストプラクティスは、コンシューマー Lambda 関数の失敗した呼び出しを処理するために[デッドレターキュー (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) を使用することです。しかし、わかりやすくするために DLQ はこのソリューションでは省略されています。ワークフローに DLQ を実装し、ワークフローが障害から回復する機能を向上させる方法の詳細については、[AWS Lambda 「エラー処理パターンの実装](https://aws.amazon.com/blogs/compute/implementing-aws-lambda-error-handling-patterns/)」ブログ記事を参照してください。 **自動化とスケール** AWS CDK は、必要なアーキテクチャを自動的にプロビジョニングします。EventBridge は、 AWS リージョンに応じて 1 秒あたり数千レコードまでスケールできます。詳細は、「[Amazon EventBridge quotas](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-quota.html)」を参照してください。 ## ツール **AWS のサービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。このパターンでは、 AWS CDK アプリケーションの操作に役立つコマンドラインクラウド開発キットである [AWS CDK Toolkit](https://docs.aws.amazon.com/cdk/latest/guide/cli.html) を使用します。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。 **その他のツール** + [Node.js](https://nodejs.org/en/docs/) は、スケーラブルなネットワークアプリケーションを構築するために設計された、イベント駆動型の JavaScript ランタイム環境です。 + [npm](https://docs.npmjs.com/about-npm) は Node.js 環境で動作するソフトウェアレジストリで、パッケージの共有や借用、プライベートパッケージのデプロイ管理に使用されます。 + 「[Python](https://www.python.org/)」は汎用のコンピュータープログラミング言語です。 **コードリポジトリ** このパターンのコードは、GitHub の [cross-account-eventbridge-in-organization](https://github.com/aws-samples/aws-cdk-examples/tree/main/python/cross-account-eventbridge-in-organization) リポジトリで入手可能です。 ## ベストプラクティス EventBridge を使用する際のベストプラクティスは、次のリソースを参照してください。 + [Amazon EventBridge イベントパターンのベストプラクティス](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-patterns-best-practices.html) + [Amazon EventBridge でルールを定義する際のベストプラクティス](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules-best-practices.html) ## エピック ### ローカル AWS CDK デプロイ環境を準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソースアカウントと送信先アカウントのローカル認証情報を設定する。 | 「[Setting up new configuration and credentials](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-new)」を確認し、環境に最も適した認証方法と認証情報を使用します。ソースアカウント認証と送信先アカウント認証の両方 AWS CLI に を設定してください。この手順では、`sourceAccount` と `destinationAccount` の 2 つの AWS プロファイルをローカルに設定していることを前提としています。 | アプリ開発者 | | 両方をブートストラップします AWS アカウント。 | アカウントをブートストラップするには、次のコマンドを実行します。
cdk bootstrap --profile sourceAccount
cdk bootstrap --profile destinationAccount
| アプリデベロッパー | | パターンコードをクローンする。 | リポジトリをクローンするには、次のコマンドを実行します。
git clone git@github.com:aws-samples/aws-cdk-examples.git
次に、ディレクトリを新しくクローンしたプロジェクトフォルダに変更します。
cd aws-cdk-examples/python/cross-account-eventbridge-in-organization
| アプリデベロッパー | ### ソースアカウントに ProducerStack をデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Organizations とアカウントの詳細`cdk.json`を使用して を変更します。 | プロジェクトのルートフォルダで、`cdk.json` に次の変更を加えます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | アプリ開発者 | | ProducerStack リソースをデプロイする。 | プロジェクトのルートディレクトリから、次のコマンドを実行します。
cdk deploy ProducerStack --profile sourceAccount
プロンプトが表示されたら、新しい IAM ロールと、 を通じて作成されたその他のセキュリティ関連のアクセス許可を受け入れます AWS CloudFormation。 | アプリ開発者 | | ProducerStack リソースがデプロイされていることを確認する。 | リソースを確認するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | アプリデベロッパー | ### ConsumerStack を送信先アカウントにデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ConsumerStack リソースをデプロイする。 | プロジェクトのルートディレクトリから、次のコマンドを実行します。
cdk deploy ConsumerStack --profile destinationAccount
プロンプトが表示されたら、新しい IAM ロールと、 を通じて作成されたその他のセキュリティ関連のアクセス許可を受け入れます CloudFormation。 | アプリ開発者 | | ConsumerStack リソースがデプロイされていることを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | アプリデベロッパー | ### イベントの生成と消費 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロデューサー Lambda 関数を呼び出す。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | アプリデベロッパー | | イベントが受信されたことを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | アプリデベロッパー | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ConsumerStack リソースを破棄する。 | このパターンをテストとして使用している場合は、追加コストが発生しないように、デプロイされたリソースを削除します。プロジェクトのルートディレクトリから、次のコマンドを実行します。
cdk destroy ConsumerStack --profile destinationAccount
スタックの削除を確認するプロンプトが表示されます。 | アプリデベロッパー | | ProducerStack リソースを破棄する。 | プロジェクトのルートディレクトリから、次のコマンドを実行します。
cdk destroy ProducerStack --profile sourceAccount
スタックの削除を確認するプロンプトが表示されます。 | アプリデベロッパー | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 送信先アカウントでイベントが受信されなかった。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | | コンソールから Lambda 関数を呼び出すと、次のエラーが返される。`User: arn:aws:iam::123456789012:user/XXXXX is not authorized to perform: lambda:Invoke` | Lambda `ProducerStack-ProducerLambdaXXXX` 関数に対する適切な`lambda:Invoke`アクション許可を受け取るには、 AWS アカウント 管理者にお問い合わせください。 | ## 関連リソース **リファレンス** + [AWS Organizations ユーザーガイド](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) + [Amazon EventBridge のイベントパターン](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html) + [Amazon EventBridge のルール](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html) **チュートリアルと動画** + [Tutorial: Creating and configuration an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html) + [AWS re:Invent 2023 - Amazon EventBridge を使用した高度なイベント駆動型パターン (COM301-R)](https://www.youtube.com/watch?v=6X4lSPkn4ps) ## 追加情報 **プロデューサールール** ソースアカウントでは、プロデューサーからのメッセージを受け入れる EventBridge イベントバスが作成されます (「*アーキテクチャ*」セクションを参照)。このイベントバスには、IAM アクセス許可が付随するルールが作成されます。このルールは、次の `cdk.json` 構成に基づいて、送信先アカウントの EventBridge イベントバスをターゲットにします。 ``` "rules": [ { "id": "CrossAccount", "sources": ["Producer"], "detail_types": ["TestType"], "targets": [ { "id": "ConsumerEventBus", "arn": "arn:aws:events:us-east-2:012345678901:event-bus/CrossAccount" } ] } ] ``` 消費するイベントバスごとに、イベントパターンとターゲットのイベントバスを含める必要があります。 *イベントパターン* [イベントパターン](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)は、このルールが適用されるイベントをフィルタリングします。この例では、イベントソースとレコードの `detail_types` は、どのイベントをソースアカウントのイベントバスから送信先アカウントのイベントバスに送信するかを識別します。 *ターゲットイベントバス* このルールは、別のアカウントに存在するイベントバスを対象としています。ターゲットイベントバスを一意に識別するには完全な `arn` (Amazon リソースネーム) が必要であり、`id` は AWS CloudFormationで使用される[論理 ID](https://docs.aws.amazon.com/cdk/v2/guide/identifiers.html#identifiers_logical_ids) です。ターゲットイベントバスは、ターゲットルールの作成時に実際に存在する必要はありません。 **送信先アカウント固有の考慮事項** 送信先アカウントでは、ソースアカウントのイベントバスからメッセージを受信する EventBridge イベントバスが作成されます。ソースアカウントからイベントを発行できるようにするには、[リソースベースのポリシー](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html)を作成する必要があります。 ``` { "Version": "2012-10-17", "Statement": [{ "Sid": "AllowOrgToPutEvents", "Effect": "Allow", "Principal": "*", "Action": "events:PutEvents", "Resource": "arn:aws:events:us-east-2:012345678901:event-bus/CrossAccount", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-XXXXXXXXX" } } }] } ``` `events:PutEvents` 権限を付与することは特に重要です。これにより、同じ組織内の他のアカウントがこのイベントバスにイベントを発行できるようになります。`aws:PrincipalOrgId` を組織 ID として設定すると、必要なアクセス許可が付与されます。 **イベントパターン** 含まれているイベントパターンは、ユースケースに応じて変更できます。 ``` rule = events.Rule( self, self.id + 'Rule' + rule_definition['id'], event_bus=event_bus, event_pattern=events.EventPattern( source=rule_definition['sources'], detail_type=rule_definition['detail_types'], ) ) ``` 不要な処理を減らすために、イベントパターンでは、送信先アカウントによって処理されるべきイベントのみが送信先アカウントのイベントバスに送信されるように指定する必要があります。 *リソースベースのポリシー* この例では、組織 ID を使用して、どのアカウントが送信先アカウントのイベントバスにイベントを配置できるかを制御します。ソースアカウントの指定など、より制限の厳しいポリシーの使用を検討します。 *EventBridge クォータ* 次の[クォータ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-quota.html)に留意してください。 + イベントバスあたり 300 ルールがデフォルトのクォータです。これは必要に応じて拡張できますが、ほとんどのユースケースに合わせる必要があります。 + 1 つのルールにつき 5 つのターゲットが最大許容数です。アプリケーションアーキテクトは、イベントパターンをきめ細かく制御できるように、送信先アカウントごとに個別のルールを使用することをお勧めします。 # で Kinesis Data Streams と Firehose を使用して Amazon S3 に DynamoDB レコードを配信する AWS CDK *Amazon Web Services、Shashank Shrivastava、Daniel Matuki da Cunha* ## 概要 このパターンは、Amazon Kinesis Data Streams および Amazon Kinesis Data Streams および Amazon Data Firehose を使用して Amazon DynamoDB から Amazon Simple Storage Service (Amazon S3) にレコードを配信するためのサンプルコードとアプリケーションを提供します。このパターンのアプローチでは [AWS Cloud Development Kit (AWS CDK) L3 コンストラクト](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html)を使用し、Amazon Web Services (AWS) クラウド上のターゲット S3 バケットにデータが配信される AWS Lambda 前に でデータ変換を実行する方法の例を示します。 Kinesis Data Streams は、DynamoDB テーブルの項目レベルの変更を記録し、それらを必須の Kinesis Data Streams にレプリケートします。アプリケーションは Kinesis Data Streams にアクセスし、項目レベルの変更をほぼリアルタイムで表示できます。Kinesis Data Streams では、Firehose や Amazon Managed Service for Apache Flink など、他の Amazon Kinesis サービスにもアクセスできます。つまり、リアルタイムのダッシュボードの提供、アラートの生成、動的な料金設定、広告の実装、高度なデータ分析の実行を行うアプリケーションを構築できます。 このパターンは、データ統合のユースケースに使用できます。たとえば、輸送車両や産業機器は、DynamoDB テーブルに大量のデータを送信できます。その後、このデータを変換して Amazon S3 でホストされているデータレイクに保存できます。その後、Amazon Athena、Amazon Redshift Spectrum、Amazon Rekognition、 AWS Glueなどのサーバーレスサービスを使用して、データをクエリして処理し、潜在的な欠陥を予測できます。 ## 前提条件と制限 *前提条件* + アクティブ AWS アカウント。 + AWS Command Line Interface (AWS CLI)、インストールおよび設定済み。詳細については、 AWS CLI ドキュメント[の「 の開始方法 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。 + Node.js (18.x\$1) と npm、インストールおよび設定済み。詳細については、[`npm`ドキュメントの Node.js と npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) のダウンロードとインストールを参照してください。 + aws-cdk (2.x\$1) がインストールされ設定済み。詳細については、 AWS CDK ドキュメント[の「 の開始方法 AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html)」を参照してください。 + GitHub [aws-dynamodb-kinesisfirehose-s3-インジェスト](https://github.com/aws-samples/aws-dynamodb-kinesisfirehose-s3-ingestion/) リポジトリは、ローカルマシンにクローン化されて設定されています。 + DynamoDB テーブルの既存のサンプルデータ。データは以下のフォーマットを使用する必要があります：`{"SourceDataId": {"S": "123"},"MessageData":{"S": "Hello World"}}` ## アーキテクチャ 次の図は、Kinesis データストリームと Firehose を使用して DynamoDB から Amazon S3 にレコードを配信するためのワークフローの例を示しています。 ![\[Kinesis データストリームと Firehose を使用して DynamoDB から Amazon S3 にレコードを配信するためのワークフローの例。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e2a9c412-312e-4900-9774-19a281c578e4/images/6e6df998-e6c2-4eaf-b263-ace752194689.png) この図表は、次のワークフローを示しています: 1. データは Amazon API Gateway を DynamoDB のプロキシとして使用して取り込まれます。他のソースを使用して DynamoDB にデータを取り込むこともできます。  1. アイテムレベルの変更は、Kinesis Data Streams でほぼリアルタイムで生成され、Amazon S3 に配信されます。 1. Kinesis データストリームは Firehose にレコードを送信し、変換と配信を行います。  1. Lambda 関数は、レコードを DynamoDB レコード形式から、レコード項目の属性名と値のみを含む JSON 形式に変換します。 ## ツール *AWS のサービス* + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義して割り当てるのに役立つソフトウェア開発フレームワークです。 + [AWS CDK Toolkit](https://docs.aws.amazon.com/cdk/latest/guide/cli.html) は、 AWS CDK アプリの操作に役立つコマンドラインクラウド開発キットです。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。 *コードリポジトリ* このパターンのコードは、GitHub 内の「[aws-dynamodb-kinesisfirehose-s3-Ingestion](https://github.com/aws-samples/aws-dynamodb-kinesisfirehose-s3-ingestion/)」リポジトリで利用できます。 ## エピック ### サンプルコードのセットアップおよび設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SDK の依存関係をインストールします。 | ローカルマシンで、次のコマンドを実行して、`package.json`、`pattern/aws-dynamodb-kinesisstreams-s3`、および `sample-application` ディレクトリのファイルから依存関係をインストールします。
cd /pattern/aws-dynamodb-kinesisstreams-s3 
npm install && npm run build
cd /sample-application/
npm install && npm run build
  | アプリ開発者、AWS 全般 | | CloudFormation テンプレートを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk.html) | アプリケーション開発者、一般的な AWS、AWS DevOps | ### リソースのデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースを確認してデプロイしてください。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk.html) | アプリケーション開発者、一般的な AWS、AWS DevOps | ### DynamoDB テーブルにデータを取り込み、ソリューションをテストします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DynamoDB テーブルにサンプルデータを取り込みます。 | 次のコマンドを実行して、DynamoDB テーブルにリクエストを送信します AWS CLI。`aws dynamodb put-item --table-name --item '{"": {"S": ""},"MessageData":{"S": ""}}'`例:`aws dynamodb put-item --table-name SourceData_table --item '{"SourceDataId": {"S": "123"},"MessageData":{"S": "Hello World"}}'`デフォルトでは、`put-item` オペレーションが成功しても、は出力として値を返しません。操作が失敗した場合はエラーを返します。データは DynamoDB に保存され、Kinesis データストリームと Firehose に送信されます。 DynamoDB テーブルにデータを追加するには、さまざまな方法が使用できます。詳細については、「DynamoDB ドキュメント」の「[テーブルへのデータのロード](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SampleData.LoadData.html)」を参照してください。 | アプリ開発者 | | S3 バケットに新しいオブジェクトが作成されたことを確認します。 | にサインイン AWS マネジメントコンソール し、S3 バケットをモニタリングして、送信したデータで新しいオブジェクトが作成されていることを確認します。 詳細については、「Amazon S3 ドキュメント」の「[GetObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html)」を参照してください。 | アプリ開発者、AWS 全般 | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースをクリーンアップします。 | `cdk destroy` コマンドを実行して、このパターンで使用されているリソースをすべて削除します。 | アプリ開発者、AWS 全般 | ## 関連リソース + [s3-static-site-stack.ts](https://github.com/awslabs/aws-solutions-constructs/blob/main/source/use_cases/aws-s3-static-website/lib/s3-static-site-stack.ts#L25) (GitHub リポジトリ) + [aws-apigateway-dynamodb](https://github.com/awslabs/aws-solutions-constructs/tree/main/source/patterns/%40aws-solutions-constructs/aws-apigateway-dynamodb) モジュール (GitHub リポジトリ) + [aws-kinesisstreams-kinesisfirehose-s3](https://github.com/awslabs/aws-solutions-constructs/tree/main/source/patterns/%40aws-solutions-constructs/aws-kinesisstreams-kinesisfirehose-s3) モジュール (GitHub リポジトリ) + 「[DynamoDB Streams の変更データキャプチャ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html)」 (「DynamoDB ドキュメント」) + 「[Kinesis Data Streams を使用して DynamoDB への変更をキャプチャする](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html)」 (「DynamoDB ドキュメント」) # Amazon API Gateway でカスタムドメインを使用してパスベースの API バージョニングを実装する *Corey Schnedl、Marcelo Barbosa、Mario Lopez Martinez、Anbazhagan Ponnuswamy、Gaurav Samudra、Abhilash Vinod、Amazon Web Services* ## 概要 このパターンでは、[カスタムドメイン](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html)の [API マッピング](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mappings.html)機能を使用して Amazon API Gateway 用のパスベースの API バージョニングソリューションを実装する方法を示します。 Amazon API Gateway は、API を作成、配布、保守、監視、保護するために規模に関係なく使用できるフルマネージドサービスです。サービスのカスタムドメイン機能を使用すると、API ユーザーに提供できる直感的な URL を使用して、シンプルなカスタムドメイン名を作成できます。API マッピングを使用して、API ステージをカスタムドメイン名に接続することができます。ドメイン名を作成し、DNS レコードを設定したら、API マッピングを使用して、カスタムドメイン名を使用して API にトラフィックを送信します。 API が公開されると、コンシューマーに利用されます。パブリック API が進化するにつれて、そのサービス契約も新機能が反映されるように進化します。ただし、既存の機能を変更または削除することは賢明ではありません。重大な変更は、コンシューマーのアプリケーションに影響を与え、実行時にアプリケーションを破損する可能性があります。API バージョニングは、下位互換性を損なったり、契約に違反したりしないようにするために重要です。 API のバージョニングには、コンシューマーが簡単に採用できるようにするための明確な戦略が必要です。パスベースの URL を使用した API のバージョニングは、最も簡単で一般的に使用されるアプローチです。このタイプのバージョニングでは、バージョンは API URI の一部として明示的に定義されます。次の URL の例で、コンシューマーが URI を使用してリクエストのために API バージョンを指定する方法を示します。 `https://api.example.com/api/v1/orders ` `https://api.example.com/api/v2/orders ` `https://api.example.com/api/vX/orders` このパターンでは、 を使用して、API 用のスケーラブルなパスベースのバージョニングソリューションのサンプル実装 AWS Cloud Development Kit (AWS CDK) を構築、デプロイ、テストします。 AWS CDK は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースをモデル化およびプロビジョニングするオープンソースのソフトウェア開発フレームワークです。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + このパターンのサンプルリポジトリを使用し、Amazon API Gateway カスタムドメイン機能を使用するには、ドメインの所有権が必要です。Amazon Route 53 を使用して、組織のドメインを作成および管理できます。Route 53 を使用してドメインを登録または移管する方法については、Route 53 ドキュメントの「[新しいドメインの登録](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register-update.html)」を参照してください。 + API のカスタムドメイン名をセットアップする前に、 AWS Certificate Managerで [SSL/TLS 証明書](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-specify-certificate-for-custom-domain-name.html)を準備する必要があります。 + API エンドポイントにマッピングするために DNS プロバイダーのリソースレコードを作成または更新する必要があります。このマッピングを行わないと、カスタムドメイン名宛ての API リクエストが API Gateway に届きません。 **制限事項** + カスタムドメイン名は、すべての AWS リージョン で 内で一意である必要があります AWS アカウント。 + 複数のレベルで API マッピングを設定するには、リージョン別カスタムドメイン名と TLS 1.2 セキュリティポリシーを使用する必要があります。 + API マッピングでは、カスタムドメイン名とマップされた API が同じ AWS アカウントにある必要があります。 + API マッピングに含めることができるのは、文字、数字、および `$-_.+!*'()/` の文字だけです。 + API マッピングのパスの最大文字数は 300 文字です。 + ドメイン名ごとに、複数のレベルで 200 個の API マッピングを設定できます。 + TLS 1.2 セキュリティポリシーでは、HTTP API をリージョン別カスタムドメイン名にだけマッピングできます。 + WebSocket APIs HTTP API または REST API と同じカスタムドメイン名にマッピングすることはできません。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択してください。 **製品バージョン** + このサンプル実装では、[AWS CDK in TypeScript](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-typescript.html) バージョン 2.149.0 を使用します。 ## アーキテクチャ 以下の図に、アーキテクチャのワークフローを示します。 ![\[API マッピングとカスタムドメインを使用してパスベースの API バージョニングソリューションを実装するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e1b32d2b-410f-4ace-967e-f0b8aaf0304c/images/fa9f04f1-efa6-4fb1-a541-ae3da4076b00.png) この図表は、以下を示すものです: 1. API ユーザーが、カスタムドメイン名を使用して Amazon API Gateway にリクエストを送信します。 1. API Gateway が、リクエストの URL に示されているパスに基づいて、ユーザーのリクエストを API Gateway の適切なインスタンスとステージに動的にルーティングします。次の表に、さまざまな URL ベースのパスを API Gateway のさまざまなインスタンスの特定のステージにルーティングする方法の例を示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-path-based-api-versioning-by-using-custom-domains.html) 1. 送信先 API Gateway インスタンスがリクエストを処理し、結果をユーザーに返します。 **自動化とスケール** API のバージョンごとに個別の AWS CloudFormation スタックを使用することをお勧めします。このアプローチでは、カスタムドメイン API マッピング機能によって、ルーティング先にできるバックエンド API を完全に分離できます。このアプローチの利点は、別の API を変更するリスクを発生させることなく、API のさまざまなバージョンを個別にデプロイまたは削除できることです。このアプローチは、CloudFormation スタックを分離することで耐障害性を向上させます。また、HTTP エンドポイント AWS Lambda、 アクションなど、API AWS Fargateのさまざまなバックエンドオプションも提供します AWS のサービス。 [Gitflow](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/gitflow-branching-strategy.html) などの Git 分岐戦略を分離された CloudFormation スタックと組み合わせて使用して、さまざまなバージョンの API にデプロイされるソースコードを管理できます。このオプションを使用すると、新しいバージョン用にソースコードを複製することなく、さまざまなバージョンの API を管理できます。Gitflow を使用すると、リリースの実行時に git リポジトリ内のコミットにタグを追加できます。それにより、特定のリリースに関連するソースコードの完全なスナップショットが作成されます。更新を実行する必要がある場合は、特定のリリースのコードをチェックアウトし、更新を行い、対応するメジャーバージョンと一致する CloudFormation スタックに更新済みのソースコードをデプロイできます。このアプローチでは、API の各バージョンには分離されたソースコードがあり、個別の CloudFormation スタックにデプロイされるため、別の API バージョンが破壊されるリスクが軽減されます。 ## ツール **AWS のサービス** + [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) は、 AWS ウェブサイトとアプリケーションを保護するパブリックおよびプライベート SSL/TLS X.509 証明書とキーの作成、保存、更新に役立ちます。 + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、コードでクラウドインフラストラクチャを定義し、それをプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです CloudFormation。このパターンのサンプル実装では、[AWS CDK in TypeScript](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-typescript.html) を使用します。TypeScript AWS CDK で を操作するには、Microsoft TypeScript コンパイラ (`tsc`)、[Node.js](https://nodejs.org/)、ノードパッケージマネージャー () などの使い慣れたツールを使用します`npm`。必要に応じて [Yarn](https://yarnpkg.com/) を使用できますが、このパターンの例では `npm` を使用します。[AWS コンストラクトライブラリ](https://docs.aws.amazon.com/cdk/v2/guide/libraries.html#libraries-construct)を構成するモジュールは、`npm ` リポジトリの [npmjs.org](https://docs.npmjs.com/) を介して配布されます。 + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS ウェブサービスです。 + [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html) は、保護されたウェブアプリケーションリソースに転送される HTTP と HTTPS リクエストをモニタリングできるウェブアプリケーションファイアウォールです。 **その他のツール** + [Bruno](https://www.usebruno.com/) はオープンソースの git フレンドリーな API テストクライアントです。 + [cdk-nag](https://github.com/cdklabs/cdk-nag) は、ルールパックを使用して AWS CDK アプリケーションのベストプラクティスをチェックするオープンソースユーティリティです。 **コードリポジトリ** このパターンのコードは、GitHub の「[path-based-versioning-with-api-gateway](https://github.com/aws-samples/path-based-versioning-with-api-gateway)」リポジトリで入手できます。 ## ベストプラクティス + 堅牢な継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを使用して、 AWS CDKで構築された CloudFormation スタックのテストとデプロイを自動化します。この推奨事項の詳細については、「[AWS Well-Architected DevOps のガイダンス](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」を参照してください。 + AWS WAF は、Amazon API Gateway などのサービスと簡単に統合できるマネージドファイアウォールです。 AWS WAF は、このバージョニングパターンが機能するために必要なコンポーネントではありませんが、 API Gateway AWS WAF に を含めるセキュリティのベストプラクティスとしてお勧めします。 + 古いバージョンの API を効率的に廃止し、削除できるように、API コンシューマーに定期的に最新バージョンの API にアップグレードするよう促します。 + このアプローチを本番環境で使用する前に、API の認可戦略とファイアウォールを導入してください。 + [最小特権アクセスモデル](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) AWS アカウント を使用して、 の AWS リソース管理へのアクセスを実装します。 + で構築されたアプリケーションのベストプラクティスとセキュリティに関する推奨事項を適用するには AWS CDK、[cdk-nag ユーティリティ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/check-aws-cdk-applications-or-cloudformation-templates-for-best-practices-by-using-cdk-nag-rule-packs.html)を使用することをお勧めします。 ## エピック ### ローカル環境を準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | 次のコマンドを実行して、サンプルアプリケーションのリポジトリをクローン作成するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/path-based-versioning-with-api-gateway
| アプリ開発者 | | リポジトリのクローンを作成した場所にナビゲートします。 | リポジトリのクローンを作成したフォルダに移動するには、次のコマンドを実行します。
cd api-gateway-custom-domain-versioning
| アプリ開発者 | | 必要な依存ファイルをインストールします。 | 必要な従属関係をインストールには、次のコマンドを実行します。
npm install
| アプリ開発者 | ### CloudFormation ルーティングスタックをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ルーティングスタックのデプロイを開始します。 | CloudFormation ルーティングスタック `CustomDomainRouterStack` のデプロイを開始するには、次のコマンドを実行します。`example.com` は、所有しているドメインの名前に置き換えてください。
npx cdk deploy CustomDomainRouterStack --parameters PrerequisiteDomainName=example.com
次のドメイン DNS 検証タスクが正常に実行されるまで、スタックのデプロイは成功しません。 | アプリ開発者 | ### ドメインの所有権を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ドメインの所有権を検証します。 | 証明書は、関連付けられたドメインの所有権を証明するまで、**保留中の検証**のステータスのままになります。所有権を証明するには、ドメインに関連付けられているホストゾーンに CNAME レコードを追加します。詳細については、 AWS Certificate Manager ドキュメントの[「DNS 検証](https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html)」を参照してください。適切なレコードを追加すると、`CustomDomainRouterStack` デプロイが成功します。 | アプリ開発者、AWS システム管理者、ネットワーク管理者 | | API Gateway カスタムドメインを指すエイリアスレコードを作成します。 | 証明書が正常に発行および検証されたら、Amazon API Gateway カスタムドメイン URL を指す [DNS レコードを作成します](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-regional-api-custom-domain-create.html#apigateway-regional-api-custom-domain-dns-record)。カスタムドメイン URL は、カスタムドメインのプロビジョニングによって一意に生成され、CloudFormation 出力パラメータとして指定されます。次の内容は[レコードの例](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-basic.html)です。**ルーティングポリシー**: シンプルルーティング**レコード名**: `demo.api-gateway-custom-domain-versioning.example.com`**Alias (エイリアス)**: あり**レコードタイプ**: AWS リソースを指す「A」タイプの DNS レコード**値**: `d-xxxxxxxxxx.execute-api.xx-xxxx-x.amazonaws.com`**TTL (秒)**: 300 | アプリ開発者、AWS システム管理者、ネットワーク管理者 | ### CloudFormation スタックをデプロイして API を呼び出す | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `ApiStackV1` スタックをデプロイします。 | `ApiStackV1` スタックをデプロイするには、以下のコマンドを実行します。
npm run deploy-v1
次の CDK コードは API マッピングを追加します。
var apiMapping = new CfnApiMapping(this, "ApiMapping", {
      apiId: this.lambdaRestApi.restApiId,
      domainName: props.customDomainName.domainName,
      stage: "api",
      apiMappingKey: "api/v1",
    });
| アプリ開発者 | | `ApiStackV2` スタックをデプロイします。 | `ApiStackV2` スタックをデプロイするには、以下のコマンドを実行します。
npm run deploy-v2
| アプリ開発者 | | API を呼び出します。 | Bruno を使用して API を呼び出し、API エンドポイントをテストするには、「[追加情報](#implement-path-based-api-versioning-by-using-custom-domains-additional)」の手順を参照してください。 | アプリ開発者 | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースをクリーンアップします。 | このサンプルアプリケーションに関連付けられたリソースを破棄するには、次のコマンドを実行します。
npx cdk destroy --all
ドメイン所有権の検証プロセスのために手動で追加した Route 53 DNS レコードを必ずクリーンアップしてください。 | アプリデベロッパー | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 証明書を検証できないため、`CustomDomainRouterStack` のデプロイがタイムアウトする。 | 前のタスクで説明したように、適切な DNS 検証 CNAME レコードが追加されていることを確認してください。新しい証明書は、DNS 検証レコードの追加後に、**[保留中の検証]** のステータスを最大 30 分間表示し続けます。詳細については、 AWS Certificate Manager ドキュメントの[「DNS 検証](https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html)」を参照してください。 | ## 関連リソース + [Amazon CloudFront を使用したヘッダーベースの API Gateway バージョニングの実装](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/) – この AWS コンピューティングブログ記事では、このパターンで説明されているパスベースのバージョニング戦略の代わりに、ヘッダーベースのバージョニング戦略を提供しています。 + [AWS CDK ワークショップ](https://cdkworkshop.com/20-typescript.html) – この入門ワークショップでは、 を使用して AWS でアプリケーションを構築およびデプロイすることに重点を置いています AWS Cloud Development Kit (AWS CDK)。このワークショップでは、Go、Python、TypeScript をサポートしています。 ## 追加情報 **Bruno を使用した API のテスト** オープンソース API テストツールである [Bruno](https://www.usebruno.com/) を使用して、パスベースのルーティングがサンプルアプリケーションに対して適切に動作していることを検証することをお勧めします。このパターンでは、サンプル API のテストを容易にするサンプルコレクションを用意しています。 API を呼び出してテストするには、次の手順を実行します。 1. [Bruno をインストールします。](https://www.usebruno.com/downloads) 1. Bruno を開きます。 1. このパターンの[コードリポジトリ](https://github.com/aws-samples/path-based-versioning-with-api-gateway)で、「**Bruno/Sample-API-Gateway-Custom-Domain-Versioning**」を選択し、コレクションを開きます。 1. ユーザーインターフェイス (UI) の右上にある **[環境]** ドロップダウンを表示するには、コレクション内の任意のリクエストを選択します。 1. **[環境]** ドロップダウンで、**[設定]** を選択します。 1. `REPLACE_ME_WITH_YOUR_DOMAIN` 値をカスタムドメインに置き換えます。 1. **[保存]** を選択し、**[設定]** セクションを閉じます。 1. **[サンドボックス環境]** では、**[アクティブ]** オプションが選択されていることを確認します****。 1. 選択したリクエストの **->** ボタンを使用して API を呼び出します。 1. V2 と比較して V1 で検証 (数値以外の値を渡す) がどのように処理されるかに注意してください。 API 呼び出しの例と V1 と V2 の検証の比較のスクリーンショットを確認するには、このパターンの[コードリポジトリ](https://github.com/aws-samples/path-based-versioning-with-api-gateway)の `README.md` ファイル内にある「**サンプル API をテストする**」を参照してください。 # psycopg2 ライブラリを にインポート AWS Lambda して PostgreSQL データベースとやり取りする *Amazon Web Services、Louis Hourcade* ## 概要 [Psycopg](https://www.psycopg.org/docs/) は Python 用の PostgresSQL データベースアダプタです。開発者は、この `psycopg2` ライブラリを使用して、PostgreSQL データベースとやり取りする Python アプリケーションを作成します。 Amazon Web Services (AWS) では、開発者は [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) を使用して、アプリケーションやバックエンドサービスのコードも実行できます。Lambda は、サーバーをプロビジョニングしたり管理したりすることなくコードを実行する、サーバーレスでイベント駆動型のコンピューティングサービスです。 デフォルトでは、[Lambda でサポートされている Python ランタイム](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html)を使用する新しい関数を作成すると、 AWSによって提供される [Lambda のベースイメージ](https://github.com/aws/aws-lambda-base-images)から Lambda ランタイム環境が作成されます。`pandas` や `psycopg2` などのライブラリは、ベースイメージに含まれません。ライブラリを使用するには、ライブラリをカスタムパッケージにバンドルして Lambda にアタッチする必要があります。 ライブラリをバンドルしてアタッチする方法は複数あります。以下に例を示します。 + [.zip ファイルアーカイブ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-zip.html)から Lambda 関数をデプロイします。 + カスタムコンテナイメージから Lambda 関数をデプロイします。 + [Lambda レイヤー](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html#lambda-layer-versions)を作成して、Lambda 関数にアタッチします。 このパターンでは、最初の 2 つのオプションについて説明します。 .zip デプロイパッケージを使用すると、Lambda 関数に `pandas` ライブラリを追加するのが比較的簡単になります。Linux マシンにフォルダを作成し、Lambda スクリプトを `pandas` ライブラリとライブラリの依存関係とともにフォルダに追加して、フォルダを圧縮して、Lambda 関数のソースとして提供します。 .zip デプロイパッケージを使用するのは一般的な方法ですが、この方法は `psycopg2` ライブラリでは機能しません。このパターンではまず、.zip デプロイパッケージを使用して `psycopg2` ライブラリを Lambda 関数に追加した場合に表示されるエラーを示します。次に、このパターンでは、Dockerfile から Lambda をデプロイし、`psycopg2` ライブラリが機能するように Lambda イメージを編集する方法を示します。 パターンがデプロイする 3 つのリソースの詳細については、「[追加情報](#import-psycopg2-library-lambda-additional)」セクションを参照してください。 ## 前提条件と制限事項 **前提条件** + このパターンで使用される AWS リソースをデプロイするための十分なアクセス許可 AWS アカウント を持つアクティブな + AWS Cloud Development Kit (AWS CDK) を実行してグローバルにインストールする `npm install -g aws-cdk` + Git クライアント + Python + Docker **制限事項** + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページから、サービスのリンクを選択してご確認ください。 **製品バージョン** + [Lambda でサポートされている](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html) Python ランタイムバージョン + Psycopg2 バージョン 2.9.3 + Pandas バージョン 1.5.2 ## アーキテクチャ **ソリューションの概要** Lambda で `psycopg2` ライブラリを使用する際に直面する可能性のある課題を説明するために、このパターンでは、次の 2 つの Lambda 関数をデプロイします。 + .zip ファイルから作成された Python ランタイムを含む 1 つの Lambda 関数。`psycopg2` および `pandas` ライブラリは、[pip](https://pypi.org/project/pip/) を使用してこの .zip デプロイパッケージにインストールされます。 + Dockerfile から作成された Python ランタイムを含む 1 つの Lambda 関数。Dockerfile は、Lambda コンテナイメージに `psycopg2` および `pandas` ライブラリをインストールします。 最初の Lambda 関数は、`pandas` ライブラリとその依存関係を .zip ファイルにインストールし、Lambda はそのライブラリを使用できます。 2 番目の Lambda 関数は、Lambda 関数のコンテナイメージを構築することで、Lambda で `pandas` および `psycopg2` ライブラリを実行できることを示しています。 ## ツール **AWS のサービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 **その他のツール** + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしての Platform as a Service (PaaS) 製品のセットです。 + [pandas](https://pandas.pydata.org/) は、データの分析と操作を行うための Python ベースのオープンソースツールです。 + [Psycopg](https://www.psycopg.org/docs/) は、マルチスレッドアプリケーション用に設計された Python 言語用の PostgreSQL データベースアダプタです。このパターンでは Psycopg 2 を使用します。 + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。 **コードリポジトリ** このパターンのコードは、GitHub の [import-psycopg2-in-lambda-to-interact-with-postgres-database](https://github.com/aws-samples/import-psycopg2-in-lambda-to-interact-with-postgres-database) リポジトリで使用できます。 ## ベストプラクティス このパターンでは、 AWS CDK を使用して Dockerfile から Lambda 関数を作成する作業例を示します。アプリケーションでこのコードを再利用する場合は、デプロイされたリソースがすべてのセキュリティ要件を満たしていることを確認してください。インフラストラクチャがデプロイされる前に設定ミスを見つけるには、クラウドインフラストラクチャ設定をスキャンする [Checkov](https://www.checkov.io/) などのツールを使用します。 ## エピック ### リポジトリのクローンを作成し、デプロイを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | ローカルマシンに GitHub リポジトリのクローンを作成するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/import-psycopg2-in-lambda-to-interact-with-postgres-database.git
cd AWS-lambda-psycopg2
| AWS 全般 | | デプロイを設定します。 | 次の情報を使用して `app.py` ファイルを編集します AWS アカウント。
aws_acccount = "AWS_ACCOUNT_ID"
region = "AWS_REGION"
# Select the CPU architecture you are using to build the image (ARM or X86)
architecture = "ARM"
| AWS 全般 | ### AWS アカウントをブートストラップしてアプリケーションをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | をブートストラップします AWS アカウント。 | [AWS 環境をブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)していない場合は、 AWS アカウントの AWS 認証情報を使用して次のコマンドを実行します。
cdk bootstrap aws:///
| AWS 全般 | | コードをデプロイします。 | AWS CDK アプリケーションをデプロイするには、次のコマンドを実行します。
cdk deploy AWSLambdaPyscopg2
| AWS 全般 | ### AWS マネジメントコンソールから Lambda 関数をテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | .zip ファイルから作成された Lambda 関数をテストします。 | .zip ファイルから作成された Lambda 関数をテストするには、以下を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/import-psycopg2-library-lambda.html)Lambda はデフォルトイメージ内に必要な PostgreSQL ライブラリを見つけられないため、`psycopg2` ライブラリを使用できません。 | AWS 全般 | | Dockerfile から作成された Lambda 関数をテストします。 | Lambda 関数内で `psycopg2` ライブラリを使用するには、Lambda Amazon マシンイメージ (AMI) を編集する必要があります。Dockerfile から作成された Lambda 関数をテストするには、以下を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/import-psycopg2-library-lambda.html)次のコードは、 AWS CDK テンプレートが作成する Dockerfile を示しています。
# Start from lambda Python3.13 image
FROM public.ecr.aws/lambda/python:3.13

# Copy the lambda code, together with its requirements
COPY lambda/requirements.txt ${LAMBDA_TASK_ROOT}
COPY lambda/lambda_code.py ${LAMBDA_TASK_ROOT}

# Install postgresql-devel in your image
RUN yum install -y gcc postgresql-devel

# install the requirements for the Lambda code
RUN pip3 install -r requirements.txt --target "${LAMBDA_TASK_ROOT}"

# Command can be overwritten by providing a different command in the template directly.
CMD ["lambda_code.handler"]
Dockerfile は、Python ランタイム用に AWS 提供された Lambda イメージを取得し、[postgresql-devel](https://yum-info.contradodigital.com/view-package/updates/postgresql-devel/) をインストールします。これには、PostgreSQL 管理サーバーと直接やり取りするアプリケーションをコンパイルするために必要なライブラリが含まれています。Dockerfile は、`requirements.txt` ファイルで示されている `pandas` および `psycopg2` ライブラリもインストールします。 | AWS 全般 | ## 関連リソース + [AWS CDK ドキュメント](https://docs.aws.amazon.com/cdk/v2/guide/home.html) + [AWS Lambda ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) ## 追加情報 このパターンでは、 AWS CDK テンプレートは 3 つのリソースを持つ AWS スタックを提供します。 + Lambda 関数の [AWS Identity and Access Management (IAM) ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。 + Python ランタイムを含む Lambda 関数。関数は `Constructs/lambda/lambda_deploy.zip` デプロイパッケージからデプロイされます。 + Python ランタイムを含む Lambda 関数。関数は `Constructs` フォルダの Dockerfile からデプロイされます。 両方の Lambda 関数のスクリプトは、`pandas` ライブラリと `psycopg2` ライブラリが正常にインポートされたかどうかを確認します。 ``` import pandas print("pandas successfully imported") import psycopg2 print("psycopg2 successfully imported") def handler(event, context): """Function that checks whether psycopg2 and pandas are successfully imported or not""" return {"Status": "psycopg2 and pandas successfully imported"} ``` `lambda_deploy.zip` デプロイパッケージは `Constructs/lambda/build.sh` bash スクリプトを使用して構築されます。このスクリプトは、フォルダを作成し、Lambda スクリプトをコピーして、`pandas` ライブラリと `psycopg2` ライブラリをインストールし、.zip ファイルを生成します。.zip ファイルを自分で生成するには、この bash スクリプトを実行して AWS CDK スタックを再デプロイします。 Dockerfile は、Python ランタイムを使用する Lambda 用に AWS 提供されたベースイメージで始まります。Dockerfile は、デフォルトのイメージの上に `pandas` ライブラリと `psycopg2` ライブラリをインストールします。 # Amazon API Gateway を Amazon SQS と統合して非同期 REST API を処理する *Amazon Web Services、Natalia Colantonio Favero および Gustavo Martim* ## 概要 REST API をデプロイするときに、クライアントアプリケーションが公開できるメッセージキューの公開が必要となる場合があります。例えば、サードパーティー API のレイテンシーや応答の遅延の問題が発生したり、データベースクエリの応答時間を回避したり、同時実行 API が多数ある場合にサーバーのスケーリングを回避したりすることが必要となる場合があります。このようなシナリオでは、キューに公開するクライアントアプリケーションは、API がデータを受信したことだけを認識していればよく、データの受信後に何が起こるかを認識する必要はありません。 このパターンでは、[Amazon API Gateway](https://aws.amazon.com/api-gateway/) を使用して [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) にメッセージを送信することで、REST API エンドポイントを作成します。これにより、SQS キューへの直接アクセスを回避しながら、2 つのサービス間の統合を簡単に実装できるようになります。 ## 前提条件と制限事項 + [アクティブな AWS アカウント](https://portal.aws.amazon.com/billing/signup/iam) ## アーキテクチャ ![\[API Gateway を Amazon SQS と統合するためのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/70984dee-e49f-4446-9d52-49ce826c3909/images/737ba0b2-da8f-4478-8c54-0a4835fd69f9.png) 次の図は、これらのステップを示しています。 1. Postman などのツール、別の API、またはその他のテクノロジーを使用して、POST REST API エンドポイントをリクエストします。 1. API Gateway は、リクエストの本文で受信したメッセージをキューにポストします。 1. Amazon SQS はメッセージを受信し、成功または失敗のコードを含む応答を API Gateway に送信します。 ## ツール + [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + 「[Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)」は、安全で耐久性があり、配信ソフトウェアシステムとコンポーネントを統合および分離できる利用可能なホスト型キューを提供します。   ## エピック ### SQS キューを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | キューを作成する。 | REST API からメッセージを受信する SQS キューを作成するには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | ### Amazon SQS へのアクセスを提供する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM ロールを作成します。 | この IAM ロールは、API Gateway リソースに Amazon SQS へのフルアクセスを付与します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者、AWS 管理者 | ### REST API を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | REST API を作成する | これは、HTTP リクエストが送信される REST API です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | | API Gateway を Amazon SQS に接続します。 | このステップにより、メッセージが HTTP リクエストの本文内から Amazon SQS に流れるようになります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | ### REST API をテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | REST API をテストします。 | 不足している設定がないかをチェックするテストを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | | API 統合を変更して、リクエストを Amazon SQS に適切に転送します。 | 統合エラーを修正するには、設定を完了します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | | Amazon SQS でメッセージをテストして検証します。 | テストを実行し、テストが正常に完了したことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | | 特殊文字を使用して API Gateway をテストします。 | メッセージでは許容されない特殊文字 (& など) を含むテストを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html)This is because special characters aren't supported by default in the message body. 次のステップでは、特殊文字をサポートするように API Gateway を設定します。コンテンツタイプの変換の詳細については、「[API Gateway ドキュメント](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings-workflow.html)」を参照してください。 | アプリ開発者 | | 特殊文字をサポートするように API 設定を変更します。 | メッセージ内の特殊文字を許容するように設定を調整します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html)新しいメッセージには特殊文字を含める必要があります。 | アプリ開発者 | ### REST API をデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | API をデプロイします。 | REST API をデプロイするには、以下を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | | 外部ツールを使用してテストします。 | 外部ツールを使用してテストを実行し、メッセージが正常に受信されたことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | API を削除します。 | [API Gateway コンソール](https://console.aws.amazon.com/apigateway/)で、作成した API を選択し、**[削除]** を選択します。 | アプリ開発者 | | IAM ロールを削除します。 | [IAM コンソール](https://console.aws.amazon.com/iam/)の **[ロール]** ペインで、**AWSGatewayRoleForSQS** を選択し、**[削除]** を選択します。 | アプリ開発者 | | SQS キューを削除します。 | [Amazon SQS コンソール](https://console.aws.amazon.com/sqs/)の **[キュー]** ペインで、作成した SQS キューを選択し、**[削除]** を選択します。 | アプリ開発者 | ## 関連リソース + [SQS-SendMessage](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-aws-services-reference.html#SQS-SendMessage) (API Gateway ドキュメント) + [API Gateway でのコンテンツタイプの変換](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings-workflow.html) (API Gateway ドキュメント) + [\$1util 変数](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#util-template-reference) (API Gateway ドキュメント) + [API Gateway REST API を Amazon SQS と統合して一般的なエラーを解決する方法 (](https://repost.aws/knowledge-center/api-gateway-rest-api-sqs-errors)AWS re:Post 記事) # Amazon API Gateway と AWS Lambda を使用してイベントを非同期的に処理する *Amazon Web Services、Andrea Meroni、Marime Kthiri、Nadim Majed、Michael Wallner* ## 概要 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、開発者が API を作成、配布、保守、監視、保護するために規模に関係なく使用できるフルマネージドサービスです。最大で数十万個の同時 API コールの受け入れと処理に伴うすべてのタスクを取り扱います。 API Gateway の重要なサービスクォータは、統合タイムアウトです。このタイムアウトは、バックエンドサービスがレスポンスを返さなければならない最大時間で、その後は REST API がエラーを返します。29 秒のハードリミットは、同期ワークロードでは一般的に許容されます。ただし、この制限は、非同期ワークロードで API Gateway を使用するデベロッパーにとっての課題です。 このパターンは、API Gateway と を使用してイベントを非同期的に処理するアーキテクチャの例を示しています AWS Lambda。このアーキテクチャは、最大 15 分間の処理ジョブの実行をサポートし、インターフェイスとして基本的な REST API を使用します。 [Projen](https://pypi.org/project/projen/) は、ローカル開発環境をセットアップし、[AWS Cloud Development Kit (AWS CDK) Toolkit](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) AWS アカウント、[Docker](https://docs.docker.com/get-docker/)、[Node.js](https://nodejs.org/en/download/) と組み合わせてサンプルアーキテクチャをターゲットにデプロイするために使用されます。Projen は、[事前コミット](https://pre-commit.com/)と、コードの品質保証、セキュリティスキャン、ユニットテストに使用されるツールを使用して、[Python](https://www.python.org/downloads/) 仮想環境を自動でセットアップします。詳しくは「[ツール](#process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-tools)」セクションをご確認ください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + ワークステーションにインストールされている以下のツール: + [AWS Cloud Development Kit (AWS CDK) ツールキット](https://docs.aws.amazon.com/cdk/v2/guide/cli.html)バージョン 2.85.0 + [Docker](https://docs.docker.com/get-docker/) バージョン 20.10.21 + [Node.js](https://nodejs.org/en/download/) バージョン 18.13.0 + [Projen](https://pypi.org/project/projen/) バージョン 0.71.111 + [Python](https://www.python.org/downloads/) バージョン 3.9.16 **制限事項** + ジョブの最大ランタイムは、Lambda 関数の最大ランタイム (15 分) によって制限されます。 + 同時ジョブリクエストの最大数は、Lambda 関数の予約済み同時実行数によって制限されます。 ## アーキテクチャ 次の図は、イベント処理およびエラー処理 Lambda 関数と Amazon EventBridge イベントアーカイブに保存されたイベントとのジョブ API の相互作用を示しています。 ![\[AWS クラウド architecture showing user interaction with jobs API, Lambda functions, and EventBridge.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e027130c-44c1-41ab-bbe9-f196a49bd9ac/images/3c437b65-48e3-477d-aeea-6ff938cc3285.png) 一般的なワークフローには、以下のステップが含まれます。 1. AWS Identity and Access Management (IAM) に対して認証し、セキュリティ認証情報を取得します。 1. HTTP `POST` リクエストを `/jobs` ジョブ API エンドポイントに送信し、リクエスト本文のジョブパラメータを指定します。 1. API Gateway REST API であるジョブ API は、ジョブ識別子を含む HTTP レスポンスを返します。 1. ジョブ API は、イベント処理 Lambda 関数を非同期的に呼び出します。 1. イベント処理関数はイベントを処理し、ジョブ結果を Amazon DynamoDB テーブルに置きます。 1. ステップ 3 の `/jobs/{jobId}` ジョブ識別子を `{jobId}` として、ジョブ API エンドポイントに HTTP `GET` リクエストを送信します。 1. ジョブ API は DynamoDB `jobs` テーブルにクエリを実行してジョブ結果を取得します。 1. ジョブ API は、ジョブ結果を含む HTTP レスポンスを返します。 1. イベント処理が失敗した場合、イベント処理関数はイベントをエラー処理関数に送信します。 1. エラー処理関数は、DynamoDB `jobs` テーブルにジョブパラメータを置きます。 1. ジョブ API エンドポイントに HTTP `GET` リクエストを送信することで、`/jobs/{jobId}` ジョブパラメータを取得できます。 1. エラー処理が失敗した場合、エラー処理関数はイベントを EventBridge イベントアーカイブに送信します。 EventBridge を使用して、アーカイブされたイベントを再生できます。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンドを通じて AWS のサービスを操作するのに役立つオープンソースツールです。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + 「[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)」 は、アプリケーションをさまざまなソースのデータに接続するために支援するサーバーレスイベントバスサービスです。例えば、Lambda 関数、API 宛先を使用する HTTP 呼び出しエンドポイント、その他の AWS アカウントのイベントバスなどです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 **その他のツール** + [autopep8](https://github.com/hhatto/autopep8) は、Python Enhancement Proposal (PEP) 8 スタイルガイドに基づいて自動的に Python コードをフォーマットします。 + [Bandit](https://bandit.readthedocs.io/en/latest/) は Python コードをスキャンして、一般的なセキュリティ問題を見つけます。 + [Commitizen](https://commitizen-tools.github.io/commitizen/) は Git コミットチェッカーと `CHANGELOG` ジェネレーターです。 + [cfn-lint](https://github.com/aws-cloudformation/cfn-lint) は linter AWS CloudFormation です + [Checkov](https://github.com/bridgecrewio/checkov) は、Infrastructure as Code (IaC) のセキュリティとコンプライアンスの設定ミスをチェックする静的コード分析ツールです。 + [jq](https://stedolan.github.io/jq/download/) は JSON を構文解析するコマンドラインツールです。 + [Postman](https://www.postman.com/) は API プラットフォームです。 + [事前コミット](https://pre-commit.com/)は Git フックマネージャーです。 + [Projen](https://github.com/projen/projen) はプロジェクトジェネレーターです。 + 「[pytest](https://docs.pytest.org/en/7.2.x/index.html)」は、小さくて読みやすいテストを書くための Python フレームワークです。 **コードリポジトリ** このアーキテクチャコードの例は、GitHub [Asynchronous Event Processing with API Gateway and Lambda](https://github.com/aws-samples/asynchronous-event-processing-api-gateway-lambda-cdk) リポジトリにあります。 ## ベストプラクティス + この例のアーキテクチャには、デプロイされたインフラストラクチャのモニタリングは含まれません。モニタリングが必要なユースケースの場合は、[CDK モニタリングコンストラクト](https://constructs.dev/packages/cdk-monitoring-constructs)または別のモニタリングソリューションの追加を評価します。 + このアーキテクチャ例では、[IAM アクセス許可](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)を使用して、ジョブ API へのアクセスを制御します。`JobsAPIInvokeRole` を引き受ける権限を持つユーザーは、ジョブ API を呼び出すことができます。そのため、アクセスコントロールメカニズムはバイナリです。より複雑な認可モデルが必要なユースケースの場合は、別の[アクセスコントロールメカニズム](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)の使用を評価します。 + ユーザーが `/jobs` ジョブ API エンドポイントに HTTP `POST` リクエストを送信すると、入力データは 2 つの異なるレベルで検証されます。 + Amazon API Gateway は、最初の[リクエスト検証](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)を担当します。 + イベント処理関数は、2 番目のリクエストを実行します。 ユーザーが `/jobs/{jobId}` ジョブ API エンドポイントに対して HTTP `GET` リクエストを実行する場合、検証は実行されません。追加の入力検証とセキュリティレベルの向上が必要なユースケースの場合は、[AWS WAF を使用した API 保護](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)を評価します。 ## エピック ### 環境をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | リポジトリをローカルに複製するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/asynchronous-event-processing-api-gateway-lambda-cdk.git
| DevOps エンジニア | | プロジェクトを設定します。 | ディレクトリをリポジトリルートに変更し、[Projen](https://github.com/projen/projen) を使用して Python 仮想環境とすべてのツールを設定します。
cd asynchronous-event-processing-api-gateway-api-gateway-lambda-cdk
npx projen
| DevOps エンジニア | | 事前コミットフックをインストールします。 | 事前コミットフックをインストールするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.html) | DevOps エンジニア | ### サンプルアーキテクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ブートストラップ AWS CDK。 | AWS CDK でブートストラップするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen bootstrap
| AWS DevOps | | サンプルアーキテクチャをデプロイします。 | にサンプルアーキテクチャをデプロイするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen deploy
| AWS DevOps | ### アーキテクチャをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストの前提条件をインストールします。 | [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)、[Postman](https://www.postman.com/downloads/)、[jq](https://jqlang.github.io/jq/) をワークステーションにインストールします。[Postman](https://www.postman.com/downloads/) を使用してこのサンプルアーキテクチャをテストすることをお勧めしますが、必須ではありません。代替の API テストツールを選択する場合は、[AWS 署名バージョン 4 認証](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html)に対応していることを確認し、また、[REST API をエクスポート](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html)して検査できる公開 API エンドポイントを参照してください。 | DevOps エンジニア | | `JobsAPIInvokeRole` を引き受けます。 | deploy コマンドから出力された `JobsAPIInvokeRole` を[引き受け](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)ます。
CREDENTIALS=$(AWS_PROFILE=$ aws sts assume-role \
--no-cli-pager \
--role-arn $ \
--role-session-name JobsAPIInvoke)
export AWS_ACCESS_KEY_ID=$(cat $CREDENTIALS | jq ‘.Credentials’’.AccessKeyId’)
export AWS_SECRET_ACCESS_KEY=$(cat $CREDENTIALS | jq ‘.Credentials’’.SecretAccessKey’)
export AWS_SESSION_TOKEN==$(cat $CREDENTIALS | jq ‘.Credentials’’.SessionToken’)
| AWS DevOps | | Postman を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.html) | AWS DevOps | | サンプルアーキテクチャをテストします。 | サンプルアーキテクチャをテストするには、ジョブ API に[リクエストを送信](https://learning.postman.com/docs/sending-requests/requests/#next-steps)します。詳細については、[Postman ドキュメント](https://learning.postman.com/docs/getting-started/first-steps/sending-the-first-request/#send-an-api-request)を参照してください。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | [Amazon CloudWatch Logs ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/apigateway/JobsAPIAccessLogs` が既に存在するため、サンプルアーキテクチャの破壊とその後の再デプロイは失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.html) | ## 関連リソース + [API Gateway マッピングテンプレートとアクセスロギング変数リファレンス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html) + [バックエンド Lambda 関数の非同期呼び出しを設定する](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-integration-async.html) # Amazon API Gateway と Amazon DynamoDB Streams を使用してイベントを非同期的に処理する *Amazon Web Services、Andrea Meroni、Mariem Kthiri、Nadim Majed、Alessandro Trisolini、Michael Wallner* ## 概要 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、開発者が API を作成、配布、保守、監視、保護するために規模に関係なく使用できるフルマネージドサービスです。最大で数十万個の同時 API コールの受け入れと処理に伴うすべてのタスクを取り扱います。 API Gateway の重要なサービスクォータは、統合タイムアウトです。このタイムアウトは、バックエンドサービスがレスポンスを返さなければならない最大時間で、その後は REST API がエラーを返します。29 秒のハードリミットは、同期ワークロードでは一般的に許容されます。ただし、この制限は、非同期ワークロードで API Gateway を使用するデベロッパーにとっての課題です。 このパターンは、API Gateway、Amazon DynamoDB Streams、および を使用してイベントを非同期的に処理するためのアーキテクチャの例を示しています AWS Lambda。このアーキテクチャは、同じ入力パラメータを使用した並列処理ジョブの実行をサポートし、インターフェイスとして基本的な REST API を使用します。この例では、Lambda をバックエンドとして使用すると、ジョブの期間は 15 分に制限されます。この制限を回避するには、代替サービスを使用して受信イベント (例:) を処理します AWS Fargate。 [Projen](https://pypi.org/project/projen/) は、ローカル開発環境をセットアップし AWS アカウント、[AWS Cloud Development Kit (AWS CDK) Toolkit](https://docs.aws.amazon.com/cdk/v2/guide/cli.html)、[Docker](https://docs.docker.com/get-docker/)、[Node.js](https://nodejs.org/en/download/) と組み合わせてサンプルアーキテクチャをターゲットにデプロイするために使用されます。Projen は、[事前コミット](https://pre-commit.com/)と、コードの品質保証、セキュリティスキャン、ユニットテストに使用されるツールを使用して、[Python](https://www.python.org/downloads/) 仮想環境を自動でセットアップします。詳しくは「[ツール](#processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-tools)」セクションをご確認ください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + ワークステーションにインストールされている以下のツール: + [AWS Cloud Development Kit (AWS CDK) Toolkit](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) バージョン 2.85.0 以降 + [Docker](https://docs.docker.com/get-docker/) バージョン 20.10.21 以降 + [Node.js](https://nodejs.org/en/download/) バージョン 18 以降 + [Projen](https://pypi.org/project/projen/) バージョン 0.71.111 以降 + [Python](https://www.python.org/downloads/) バージョン 3.9.16 以降 **制限事項** + スロットリングを避けるため、DynamoDB Streams の推奨最大リーダー数は 2 です。 + ジョブの最大ランタイムは、Lambda 関数の最大ランタイム (15 分) によって制限されます。 + 同時ジョブリクエストの最大数は、Lambda 関数の予約済み同時実行数によって制限されます。 ## アーキテクチャ **アーキテクチャ** 次の図は、Amazon EventBridge イベントアーカイブに保存されたイベントと、DynamoDB Streams およびイベント処理とエラー処理の Lambda 関数とのジョブ API の相互作用を示しています。 ![\[アーキテクチャとプロセスの図 (図の後にステップがリストされています)。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/68a46501-16e5-48e4-99c6-fc67a8b4133a/images/29fe6982-ad81-4099-9c65-08b17c96e78f.png) 一般的なワークフローには、以下のステップが含まれます。 1. AWS Identity and Access Management (IAM) に対して認証し、セキュリティ認証情報を取得します。 1. HTTP `POST` リクエストを `/jobs` ジョブ API エンドポイントに送信し、リクエスト本文のジョブパラメータを指定します。 1. ジョブ API は、ジョブ識別子を含む HTTP レスポンスを返します。 1. ジョブ API は、ジョブパラメータを `jobs_table` Amazon DynamoDB テーブルに置きます。 1. `jobs_table` DynamoDB テーブルの DynamoDB ストリームは、イベント処理 Lambda 関数を呼び出します。 1. イベント処理 Lambda 関数はイベントを処理し、ジョブ結果を DynamoDB `jobs_table` テーブルに置きします。一貫した結果を確保するために、イベント処理関数は[楽観的ロック](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html)メカニズムを実装します。 1. ステップ 3 の `/jobs/{jobId}` ジョブ識別子を `{jobId}` として、ジョブ API エンドポイントに HTTP `GET` リクエストを送信します。 1. ジョブ API は DynamoDB `jobs_table` テーブルにクエリを実行してジョブ結果を取得します。 1. ジョブ API は、ジョブ結果を含む HTTP レスポンスを返します。 1. イベント処理が失敗した場合、イベント処理関数のソースマッピングは、エラー処理を行う Amazon Simple Notification Service (Amazon SNS) トピックにイベントを送信します。 1. エラー処理 SNS トピックは、イベントをエラー処理関数に非同期的にプッシュします。 1. エラー処理関数は、DynamoDB `jobs_table` テーブルにジョブパラメータを置きます。 ジョブ API エンドポイントに HTTP `GET` リクエストを送信することで、`/jobs/{jobId}` ジョブパラメータを取得できます。 1. エラー処理が失敗した場合、エラー処理関数はイベントを Amazon EventBridge アーカイブに送信します。 EventBridge を使用して、アーカイブされたイベントを再生できます。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義して割り当てるのに役立つソフトウェア開発フレームワークです。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + 「[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)」 は、アプリケーションをさまざまなソースのデータに接続するために支援するサーバーレスイベントバスサービスです。たとえば、AWS Lambda 関数、API 宛先を使用する HTTP 呼び出しエンドポイント、または他の AWS アカウントのイベントバスなどです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 **その他のツール** + [autopep8](https://github.com/hhatto/autopep8) は、Python Enhancement Proposal (PEP) 8 スタイルガイドに基づいて自動的に Python コードをフォーマットします。 + [Bandit](https://bandit.readthedocs.io/en/latest/) は Python コードをスキャンして、一般的なセキュリティ問題を見つけます。 + [Commitizen](https://commitizen-tools.github.io/commitizen/) は Git コミットチェッカーと `CHANGELOG` ジェネレーターです。 + [cfn-lint](https://github.com/aws-cloudformation/cfn-lint) は linter AWS CloudFormation です + [Checkov](https://github.com/bridgecrewio/checkov) は、Infrastructure as Code (IaC) のセキュリティとコンプライアンスの設定ミスをチェックする静的コード分析ツールです。 + [jq](https://stedolan.github.io/jq/download/) は JSON を構文解析するコマンドラインツールです。 + [Postman](https://www.postman.com/) は API プラットフォームです。 + [事前コミット](https://pre-commit.com/)は Git フックマネージャーです。 + [Projen](https://github.com/projen/projen) はプロジェクトジェネレーターです。 + 「[pytest](https://docs.pytest.org/en/7.2.x/index.html)」は、小さくて読みやすいテストを書くための Python フレームワークです。 **コードリポジトリ** このアーキテクチャコードの例は、GitHub [Asynchronous Processing with API Gateway and DynamoDB Streams](https://github.com/aws-samples/asynchronous-event-processing-api-gateway-dynamodb-streams-cdk) リポジトリから取得できます。 ## ベストプラクティス + この例のアーキテクチャには、デプロイされたインフラストラクチャのモニタリングは含まれません。モニタリングが必要なユースケースの場合は、[CDK モニタリングコンストラクト](https://constructs.dev/packages/cdk-monitoring-constructs)または別のモニタリングソリューションの追加を評価します。 + このアーキテクチャ例では、[IAM アクセス許可](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)を使用して、ジョブ API へのアクセスを制御します。`JobsAPIInvokeRole` を引き受ける権限を持つユーザーは、ジョブ API を呼び出すことができます。そのため、アクセスコントロールメカニズムはバイナリです。より複雑な認可モデルが必要なユースケースの場合は、別の[アクセスコントロールメカニズム](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)の使用を評価します。 + ユーザーが `/jobs` ジョブ API エンドポイントに HTTP `POST` リクエストを送信すると、入力データは 2 つの異なるレベルで検証されます。 + API Gateway は、最初の[リクエスト検証](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)を担当します。 + イベント処理関数は、2 番目のリクエストを実行します。 ユーザーが `/jobs/{jobId}` ジョブ API エンドポイントに対して HTTP `GET` リクエストを実行する場合、検証は実行されません。ユースケースで追加の入力検証とセキュリティレベルの向上が必要な場合は、 [AWS WAF を使用して API を保護します](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)。 + スロットリングを避けるために、[DynamoDB Streams ドキュメント](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html#Streams.Processing)では、ユーザーが同じストリームのシャードから 3 つ以上のコンシューマーで読み取ることを推奨していません。コンシューマーの数をスケールアウトするため、[Amazon Kinesis Data Streams ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html)を使用することをお勧めします。 + この例では、DynamoDB `jobs_table` テーブル内の項目の一貫した更新を確保するために、[楽観的ロック](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html)が使用されています。ユースケースの要件によっては、悲観的ロックなど、より信頼性の高いロックメカニズムを実装する必要がある場合があります。 ## エピック ### 環境をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | リポジトリをローカルに複製するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/asynchronous-event-processing-api-gateway-dynamodb-streams-cdk.git
| DevOps エンジニア | | プロジェクトを設定します。 | ディレクトリをリポジトリルートに変更し、[Projen](https://github.com/projen/projen) を使用して Python 仮想環境とすべてのツールを設定します。
cd asynchronous-event-processing-api-gateway-api-gateway-dynamodb-streams-cdk
npx projen
| DevOps エンジニア | | 事前コミットフックをインストールします。 | 事前コミットフックをインストールするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.html) | DevOps エンジニア | ### サンプルアーキテクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ブートストラップ AWS CDK。 | [AWS CDK](https://aws.amazon.com/cdk/) でブートストラップするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen bootstrap
| AWS DevOps | | サンプルアーキテクチャをデプロイします。 | にサンプルアーキテクチャをデプロイするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen deploy
| AWS DevOps | ### アーキテクチャをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストの前提条件をインストールします。 | [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)、[Postman](https://www.postman.com/downloads/)、[jq](https://jqlang.github.io/jq/) をワークステーションにインストールします。[Postman](https://www.postman.com/downloads/) を使用してこのサンプルアーキテクチャをテストすることをお勧めしますが、必須ではありません。代替の API テストツールを選択する場合は、[AWS 署名バージョン 4 認証](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html)をサポートしていることを確認し、また、[REST API をエクスポート](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html)して検査できる公開 API エンドポイントを参照してください。 | DevOps エンジニア | | `JobsAPIInvokeRole` を引き受けます。 | `deploy` コマンドから出力された `JobsAPIInvokeRole` を[引き受け](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)ます。
CREDENTIALS=$(AWS_PROFILE=$ aws sts assume-role \
--no-cli-pager \
--role-arn $ \
--role-session-name JobsAPIInvoke)
export AWS_ACCESS_KEY_ID=$(cat $CREDENTIALS | jq ‘.Credentials’’.AccessKeyId’)
export AWS_SECRET_ACCESS_KEY=$(cat $CREDENTIALS | jq ‘.Credentials’’.SecretAccessKey’)
export AWS_SESSION_TOKEN==$(cat $CREDENTIALS | jq ‘.Credentials’’.SessionToken’)
| AWS DevOps | | Postman を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.html) | AWS DevOps | | サンプルアーキテクチャをテストします。 | サンプルアーキテクチャをテストするには、ジョブ API にリクエストを送信します。詳細については、[Postman ドキュメント](https://learning.postman.com/docs/getting-started/first-steps/sending-the-first-request/#send-an-api-request)を参照してください。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | [Amazon CloudWatch Logs ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/apigateway/JobsAPIAccessLogs` が既に存在するため、サンプルアーキテクチャの破壊とその後の再デプロイは失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.html) | ## 関連リソース + [API Gateway マッピングテンプレートとアクセスロギング変数リファレンス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html) + [DynamoDB Streams のデータキャプチャを変更する](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html) + [バージョン番号によるオプティミスティックロック](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html) + [Kinesis Data Streams を使用して DynamoDB への変更をキャプチャする](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html) # Amazon API Gateway、Amazon SQS、および AWS Fargate でイベントを非同期的に処理する *Amazon Web Services、Andrea Meroni、Mariem Kthiri、Nadim Majed、Alessandro Trisolini、Michael Wallner* ## 概要 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、開発者が API を作成、配布、保守、監視、保護するために規模に関係なく使用できるフルマネージドサービスです。最大で数十万個の同時 API コールの受け入れと処理に伴うすべてのタスクを取り扱います。 API Gateway の重要なサービスクォータは、統合タイムアウトです。このタイムアウトは、バックエンドサービスがレスポンスを返さなければならない最大時間で、その後は REST API がエラーを返します。29 秒のハードリミットは、同期ワークロードでは一般的に許容されます。ただし、この制限は、非同期ワークロードで API Gateway を使用するデベロッパーにとっての課題です。 このパターンは、API Gateway、Amazon Simple Queue Service (Amazon SQS)、および を使用してイベントを非同期的に処理するアーキテクチャの例を示しています AWS Fargate。このアーキテクチャは、期間制限なしでの処理ジョブの実行をサポートし、インターフェイスとして基本的な REST API を使用します。 [Projen](https://pypi.org/project/projen/) は、ローカル開発環境をセットアップし AWS アカウント、[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/cli.html)、[Docker](https://docs.docker.com/get-docker/)、[Node.js](https://nodejs.org/en/download/) と組み合わせてサンプルアーキテクチャをターゲットにデプロイするために使用されます。Projen は、[事前コミット](https://pre-commit.com/)と、コードの品質保証、セキュリティスキャン、ユニットテストに使用されるツールを使用して、[Python](https://www.python.org/downloads/) 仮想環境を自動でセットアップします。詳しくは「[ツール](#process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-tools)」セクションをご確認ください。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + ワークステーションにインストールされている以下のツール: + [AWS Cloud Development Kit (AWS CDK) Toolkit](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) バージョン 2.85.0 以降 + [Docker](https://docs.docker.com/get-docker/) バージョン 20.10.21 以降 + [Node.js](https://nodejs.org/en/download/) バージョン 18 以降 + [Projen](https://pypi.org/project/projen/) バージョン 0.71.111 以降 + [Python](https://www.python.org/downloads/) バージョン 3.9.16 以降 **制限事項** + 同時ジョブは 1 分あたり 500 タスクに制限されます。これは、Fargate がプロビジョニングできるタスクの最大数です。 ## アーキテクチャ 次の図は、ジョブ API と `jobs` Amazon DynamoDB テーブル、イベント処理 Fargate サービス、およびエラー処理 AWS Lambda 関数とのやり取りを示しています。イベントは Amazon EventBridge イベントアーカイブに保存されます。 ![\[図に続く説明を含むアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8a03149c-8f34-4593-84d5-accc1800a0a2/images/5e1071aa-4fbc-495c-bc22-8e62a32a136b.png) 一般的なワークフローには、以下のステップが含まれます。 1. AWS Identity and Access Management (IAM) に対して認証し、セキュリティ認証情報を取得します。 1. HTTP `POST` リクエストを `/jobs` ジョブ API エンドポイントに送信し、リクエスト本文のジョブパラメータを指定します。 1. API Gateway REST API であるジョブ API は、ジョブ識別子を含む HTTP レスポンスを返します。 1. ジョブ API は、SQS キューにメッセージを送信します。 1. Fargate は SQS キューからメッセージをプルし、イベントを処理し、ジョブ結果を `jobs` DynamoDB テーブルに置きます。 1. ステップ 3 の `/jobs/{jobId}` ジョブ識別子を `{jobId}` として、ジョブ API エンドポイントに HTTP `GET` リクエストを送信します。 1. ジョブ API は DynamoDB `jobs` テーブルにクエリを実行してジョブ結果を取得します。 1. ジョブ API は、ジョブ結果を含む HTTP レスポンスを返します。 1. イベント処理が失敗した場合、SQS キューはイベントをデッドレターキュー (DLQ) に送信します。 1. EventBridge イベントはエラー処理関数を開始します。 1. エラー処理関数は、DynamoDB `jobs` テーブルにジョブパラメータを置きます。 1. ジョブ API エンドポイントに HTTP `GET` リクエストを送信することで、`/jobs/{jobId}` ジョブパラメータを取得できます。 1. エラー処理が失敗した場合、エラー処理関数はイベントを EventBridge アーカイブに送信します。 EventBridge を使用して、アーカイブされたイベントを再生できます。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html) を使用すると、サーバーや Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを管理する必要なくコンテナを実行できます。Amazon Elastic Container Service (Amazon ECS) と組み合わせて使用されます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、Lambda 関数、API 宛先を使用する HTTP 呼び出しエンドポイント、その他の AWS アカウントのイベントバスなどです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + 「[Amazon Simple Queue Service (Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)) 」は、安全で耐久性があり、配信ソフトウェアシステムとコンポーネントを統合および分離できる利用可能なホスト型キューを提供します。 その他のツール + [autopep8](https://github.com/hhatto/autopep8) は、Python Enhancement Proposal (PEP) 8 スタイルガイドに基づいて自動的に Python コードをフォーマットします。 + [Bandit](https://bandit.readthedocs.io/en/latest/) は Python コードをスキャンして、一般的なセキュリティ問題を見つけます。 + [Commitizen](https://commitizen-tools.github.io/commitizen/) は Git コミットチェッカーと `CHANGELOG` ジェネレーターです。 + [cfn-lint](https://github.com/aws-cloudformation/cfn-lint) は linter AWS CloudFormation です + [Checkov](https://github.com/bridgecrewio/checkov) は、Infrastructure as Code (IaC) のセキュリティとコンプライアンスの設定ミスをチェックする静的コード分析ツールです。 + [jq](https://stedolan.github.io/jq/download/) は JSON を構文解析するコマンドラインツールです。 + [Postman](https://www.postman.com/) は API プラットフォームです。 + [事前コミット](https://pre-commit.com/)は Git フックマネージャーです。 + [Projen](https://github.com/projen/projen) はプロジェクトジェネレーターです。 + 「[pytest](https://docs.pytest.org/en/7.2.x/index.html)」は、小さくて読みやすいテストを書くための Python フレームワークです。 **コードリポジトリ** このアーキテクチャコードの例は、GitHub [Asynchronous Processing with API Gateway and SQS](https://github.com/aws-samples/asynchronous-event-processing-api-gateway-sqs-cdk) リポジトリにあります。 ## ベストプラクティス + この例のアーキテクチャには、デプロイされたインフラストラクチャのモニタリングは含まれません。モニタリングが必要なユースケースの場合は、[CDK モニタリングコンストラクト](https://constructs.dev/packages/cdk-monitoring-constructs)または別のモニタリングソリューションの追加を評価します。 + このアーキテクチャ例では、[IAM アクセス許可](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)を使用して、ジョブ API へのアクセスを制御します。`JobsAPIInvokeRole` を引き受ける権限を持つユーザーは、ジョブ API を呼び出すことができます。そのため、アクセスコントロールメカニズムはバイナリです。より複雑な認可モデルが必要なユースケースの場合は、別の[アクセスコントロールメカニズム](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)の使用を評価します。 + ユーザーが `/jobs` ジョブ API エンドポイントに HTTP `POST` リクエストを送信すると、入力データは 2 つの異なるレベルで検証されます。 + API Gateway は、最初の[リクエスト検証](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)を担当します。 + イベント処理関数は、2 番目のリクエストを実行します。 ユーザーが `/jobs/{jobId}` ジョブ API エンドポイントに対して HTTP `GET` リクエストを実行する場合、検証は実行されません。ユースケースで追加の入力検証とセキュリティレベルの向上が必要な場合は、 [AWS WAF を使用して API を保護します](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)。 ## エピック ### 環境をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | リポジトリをローカルに複製するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/asynchronous-event-processing-api-gateway-sqs-cdk.git
| DevOps エンジニア | | プロジェクトを設定します。 | ディレクトリをリポジトリルートに変更し、[Projen](https://github.com/projen/projen) を使用して Python 仮想環境とすべてのツールを設定します。
cd asynchronous-event-processing-api-gateway-api-gateway-sqs-cdk
npx projen
| DevOps エンジニア | | 事前コミットフックをインストールします。 | 事前コミットフックをインストールするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | DevOps エンジニア | ### サンプルアーキテクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ブートストラップ AWS CDK。 | [AWS CDK](https://aws.amazon.com/cdk/) でブートストラップするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen bootstrap
| AWS DevOps | | サンプルアーキテクチャをデプロイします。 | にサンプルアーキテクチャをデプロイするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen deploy
| AWS DevOps | ### アーキテクチャをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストの前提条件をインストールします。 | [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)、[Postman](https://www.postman.com/downloads/)、[jq](https://jqlang.github.io/jq/) をワークステーションにインストールします。[Postman](https://www.postman.com/downloads/) を使用してこのサンプルアーキテクチャをテストすることをお勧めしますが、必須ではありません。代替の API テストツールを選択する場合は、[AWS 署名バージョン 4 認証](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html)に対応していることを確認し、また、[REST API をエクスポート](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html)して検査できる公開 API エンドポイントを参照してください。 | DevOps エンジニア | | `JobsAPIInvokeRole` を引き受けます。 | `deploy` コマンドから出力された `JobsAPIInvokeRole` を[引き受け](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)ます。
CREDENTIALS=$(AWS_PROFILE=$ aws sts assume-role \
--no-cli-pager \
--role-arn $ \
--role-session-name JobsAPIInvoke)
export AWS_ACCESS_KEY_ID=$(cat $CREDENTIALS | jq ‘.Credentials’’.AccessKeyId’)
export AWS_SECRET_ACCESS_KEY=$(cat $CREDENTIALS | jq ‘.Credentials’’.SecretAccessKey’)
export AWS_SESSION_TOKEN==$(cat $CREDENTIALS | jq ‘.Credentials’’.SessionToken’)
| AWS DevOps | | Postman を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | AWS DevOps | | サンプルアーキテクチャをテストします。 | サンプルアーキテクチャをテストするには、ジョブ API にリクエストを送信します。詳細については、[Postman ドキュメント](https://learning.postman.com/docs/getting-started/first-steps/sending-the-first-request/#send-an-api-request)を参照してください。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | [Amazon CloudWatch Logs ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/apigateway/JobsAPIAccessLogs` が既に存在するため、サンプルアーキテクチャの破壊とその後の再デプロイは失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | | [CloudWatch Logs ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/ecs/EventProcessingServiceLogs` が既に存在するため、サンプルアーキテクチャの破壊とその後の再デプロイは失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | ## 関連リソース + [API Gateway マッピングテンプレートとアクセスロギング変数リファレンス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html) + [一般的なエラーを解決するために、API Gateway REST API を Amazon SQS と統合する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-rest-api-sqs-errors/) # AWS Step Functions から AWS Systems Manager Automation タスクを同期的に実行する *Elie El khoury、Amazon Web Services* ## 概要 このパターンでは、 AWS Step Functions と を統合する方法について説明します AWS Systems Manager。 AWS SDK サービス統合を使用して、ステートマシンワークフローからタスクトークンで Systems Manager **startAutomationExecution** API を呼び出し、トークンが成功または失敗の呼び出しで戻るまで一時停止します。この統合の例を示すために、このパターンはオートメーションドキュメント (ランブック) ラッパーを `AWS-RunShellScript` または `AWS-RunPowerShellScript` ドキュメントの周囲に実装し、`.waitForTaskToken` を使用して `AWS-RunShellScript` または `AWS-RunPowerShellScript` を同期的に呼び出します。Step Functions での AWS SDK サービス統合の詳細については、「 [AWS Step Functions デベロッパーガイド](https://docs.aws.amazon.com/step-functions/latest/dg/supported-services-awssdk.html)」を参照してください。 Step Functions ****は、分散アプリケーションの構築、IT およびビジネスプロセスの自動化、サービスを使用したデータおよび機械学習パイプラインの構築に使用できる、ローコードのビジュアルワークフロー AWS サービスです。ワークフローは失敗、再試行、並列化、サービス統合、オブザーバビリティを管理するので、より価値の高いビジネスロジックに集中できます。 の一機能であるオートメーションは AWS Systems Manager、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Relational Database Service (Amazon RDS)、Amazon Redshift、Amazon Simple Storage Service (Amazon S3) AWS のサービス などの の一般的なメンテナンス、デプロイ、修復タスクを簡素化します。Amazon S3 オートメーションを使用すると、自動化の同時実行性をきめ細かく制御できます。例えば、同時実行のターゲットにするリソースの数や、オートメーションを停止する前に許容可能なエラーの発生数を指定することが可能です。 ランブックのステップ、パラメータ、例など、実装の詳細については、「[追加情報](#run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-additional)」セクションを参照してください。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + AWS Identity and Access Management Step Functions と Systems Manager にアクセスするための (IAM) アクセス許可 + Systems Manager Agent (SSM Agent) が[インストールされた](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-install-ssm-agent.html) EC2 インスタンス + ランブックを実行する予定のインスタンスにアタッチされた [Systems Manager の IAM インスタンスプロファイル](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html) + 以下の IAM 権限を持つ Step Functions ロール (最小特権の原則に従う): ``` { "Effect": "Allow", "Action": "ssm:StartAutomationExecution", "Resource": "*" } ``` **製品バージョン** + SSM ドキュメントスキーマバージョン 0.3 以降 + SSM エージェントバージョン 2.3.672.0 以降。 ## アーキテクチャ **ターゲットテクノロジースタック** + AWS Step Functions + AWS Systems Manager Automation **ターゲットアーキテクチャ** ![\[Systems Manager 自動化タスクを Step Functions から同期的に実行するためのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/47c19e4f-d68d-4f91-bb68-202098757529/images/2d248aae-d858-4565-8af2-593cde0da780.png) **自動化とスケール** + このパターンは、ランブックを複数のインスタンスにデプロイするために使用できる AWS CloudFormation テンプレートを提供します。(GitHub [Step Functions and Systems Manager implementation](https://github.com/aws-samples/amazon-stepfunctions-ssm-waitfortasktoken) を参照してください)。 ## ツール **AWS のサービス** + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数やその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。 + [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。 **コード** このパターンのコードは、GitHub 内の「[Step Functions and Systems Manager implementation](https://github.com/aws-samples/amazon-stepfunctions-ssm-waitfortasktoken)」リポジトリで利用できます。  ## エピック ### ランブックの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation テンプレートをダウンロードします。 | GitHub リポジトリの `cloudformation ` フォルダから `ssm-automation-documents.cfn.json` テンプレートをダウンロードします。 | AWS DevOps | | ランブックを作成します。 | にサインインし AWS マネジメントコンソール、[CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開き、テンプレートをデプロイします。CloudFormation テンプレートのデプロイの詳細については、CloudFormation ドキュメントの[CloudFormation 「コンソールでのスタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。 CloudFormation  CloudFormation テンプレートは 3 つのリソースをデプロイします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions.html) | AWS DevOps | ### サンプルステートマシンを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストステートマシンを作成します。 | [AWS Step Functions デベロッパーガイド](https://docs.aws.amazon.com/step-functions/latest/dg/getting-started-with-sfn.html)の手順に従って、ステートマシンを作成して実行します。定義には、次のコードを使用してください。必ず、アカウント内の有効な Systems Manager 対応インスタンスの ID で `InstanceIds` 値を更新してください。
{
  "Comment": "A description of my state machine",
  "StartAt": "StartAutomationWaitForCallBack",
  "States": {
    "StartAutomationWaitForCallBack": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:ssm:startAutomationExecution.waitForTaskToken",
      "Parameters": {
        "DocumentName": "SfnRunCommandByInstanceIds",
        "Parameters": {
          "InstanceIds": [
            "i-1234567890abcdef0"
          ],
          "taskToken.$": "States.Array($$.Task.Token)",
          "workingDirectory": [
            "/home/ssm-user/"
          ],
          "Commands": [
            "echo \"This is a test running automation waitForTaskToken\" >> automation.log",
            "sleep 100"
          ],
          "executionTimeout": [
              "10800"
          ],
          "deliveryTimeout": [
              "30"
          ],
          "shell": [
              "Shell"
          ]
            }
      },
      "End": true
    }
  }
}
このコードはランブックを呼び出して、Systems Manager Automation への `waitForTaskToken` 呼び出しを示す 2 つのコマンドを実行します。`shell` パラメータ値 (`Shell` または `PowerShell`) は、オートメーションドキュメントが `AWS-RunShellScript` または `AWS-RunPowerShellScript` を実行するかどうかを決定します。タスクは `/home/ssm-user/automation.log` ファイルに「これはテスト実行オートメーションの WaitForTaskToken」と書き込み、100 秒間スリープしてからタスクトークンが返され、ワークフロー内の次のタスクがリリースされます。代わりに `SfnRunCommandByTargets` ランブックを呼び出したい場合は、前のコードの `Parameters` セクションを以下のコードに置き換えてください。
"Parameters": {
          "Targets": [
            {
              "Key": "InstanceIds",
              "Values": [
                "i-02573cafcfEXAMPLE",
                "i-0471e04240EXAMPLE"
              ]
            }
          ],
| AWS DevOps | | ステートマシンの IAM ロールを更新します。 | 前のステップでは、ステートマシンの専用の IAM ロールが自動的に作成されます。ただし、ランブックを呼び出すアクセス許可は付与されません。以下のアクセス許可を追加して、ロールを更新します。
{
      "Effect": "Allow",
      "Action": "ssm:StartAutomationExecution",
      "Resource": "*"
 }
| AWS DevOps | | 同期呼び出しを検証します。 | ステートマシンを実行して、Step Functions と Systems Manager オートメーション間の同期呼び出しを検証します。 出力例については、「[追加情報](#run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-additional)」セクションを参照してください。  | AWS DevOps | ## 関連リソース + [の開始方法 AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/getting-started-with-sfn.html) (*AWS Step Functions デベロッパーガイド*) + [タスクトークンを使用してコールバックを待機する](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token) (*AWS Step Functions デベロッパーガイド*、サービス統合パターン) + [send\$1task\$1success](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_success.html) と [send\$1task\$1failure](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_failure.html) の API コール (Boto3 ドキュメント)  + [AWS Systems Manager 自動化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) (*AWS Systems Manager ユーザーガイド*) ## 追加情報 **実装の詳細** このパターンは、2 つの Systems Manager ランブックをデプロイする CloudFormation テンプレートを提供します。 + `SfnRunCommandByInstanceIds` は、インスタンス ID を使用して `AWS-RunShellScript` または `AWS-RunPowerShellScript` コマンドを実行します。 + `SfnRunCommandByTargets` は、ターゲットを使用して `AWS-RunShellScript` または `AWS-RunPowerShellScript` コマンドを実行します。 各ランブックには、Step Functions の `.waitForTaskToken` オプションを使用する際に同期呼び出しを実現するための 4 つのステップが実装されています。 | | | [ステップ] | [アクション] | 説明 | | --- |--- |--- | | **1** | `Branch` | `shell` パラメータ値 (`Shell` または `PowerShell`) をチェックして、Linux で `AWS-RunShellScript` を実行するか Windows で `AWS-RunPowerShellScript` を実行するかを決定します。 | | **2** | `RunCommand_Shell`、または `RunCommand_PowerShell` | 複数の入力を受け取り、`RunShellScript` または `RunPowerShellScript` コマンドを実行します。詳細については、Systems Manager コンソールの `RunCommand_Shell` または `RunCommand_PowerShell` オートメーションドキュメントの **[詳細]** タブを確認してください。 | | **3** | `SendTaskFailure` | ステップ 2 が中止またはキャンセルされたときに実行されます。Step Functions [send\$1task\$1failure](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_failure.html) API を呼び出し、ステートマシンから渡されたトークン、障害エラー、障害の原因の説明の 3 つのパラメータを入力として受け入れます。 | | **4** | `SendTaskSuccess` | ステップ 2 が成功すると実行されます。ステートマシンから渡されたトークンを入力として受け入れる Step Functions [send\$1task\$1success](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_success.html) API を呼び出します。 | **ランブックパラメータ** `SfnRunCommandByInstanceIds` ランブック: | | | パラメータ名 | タイプ | オプションまたは必須 | 説明 | | --- |--- |--- |--- | | `shell` | 文字列 | 必須 | Linux で `AWS-RunShellScript` を実行するか Windows で `AWS-RunPowerShellScript` を実行するかを決定するインスタンスシェル。 | | `deliveryTimeout` | 整数 | オプションです。 | インスタンスの SSM Agent にコマンドが配信されるまで待機する時間 (秒単位)。このパラメータの最小値は 30 (0.5 分)、最大値は 2,592,000 (720 時間) です。 | | `executionTimeout` | String | オプションです。 | コマンドが失敗したと見なされるまでに完了するまでの時間 (秒単位)。デフォルト値は 3,600 (1 時間) です。最大値は 172800 (48 時間) です。 | | `workingDirectory` | String | オプションです。 | インスタンスの作業ディレクトリへのパス。 | | `Commands` | StringList | 必須 | 実行するシェルスクリプトまたはコマンド。 | | `InstanceIds` | StringList | 必須 | コマンドを実行するインスタンス ID です。 | | `taskToken` | String | 必須 | コールバックレスポンスに使用するタスクトークン。 | `SfnRunCommandByTargets` ランブック: | | | 名前 | 型 | オプションまたは必須 | 説明 | | --- |--- |--- |--- | | `shell` | 文字列 | 必須 | Linux で `AWS-RunShellScript` を実行するか Windows で `AWS-RunPowerShellScript` を実行するかを決定するインスタンスシェル。 | | `deliveryTimeout` | 整数 | オプションです。 | インスタンスの SSM Agent にコマンドが配信されるまで待機する時間 (秒単位)。このパラメータの最小値は 30 (0.5 分)、最大値は 2,592,000 (720 時間) です。 | | `executionTimeout` | 整数 | オプションです。 | コマンドが失敗したと見なされるまでに完了するまでの時間 (秒単位)。デフォルト値は 3,600 (1 時間) です。最大値は 172800 (48 時間) です。 | | `workingDirectory` | String | オプションです。 | インスタンスの作業ディレクトリへのパス。 | | `Commands` | StringList | 必須 | 実行するシェルスクリプトまたはコマンド。 | | `Targets` | MapList | 必須 | 指定したキーと値のペアを使用してインスタンスを識別する検索条件の配列。例: `[{"Key":"InstanceIds","Values":["i-02573cafcfEXAMPLE","i-0471e04240EXAMPLE"]}]` | | `taskToken` | String | 必須 | コールバックレスポンスに使用するタスクトークン。 | **出力例** 次の表に、ステップ関数からの出力例を示します。ステップ 5 (`TaskSubmitted`) からステップ 6 (`TaskSucceeded`) までの合計実行時間が 100 秒を超えていることがわかります。これは、step 関数が `sleep 100` コマンドが終了するのを待ってから、ワークフロー内の次のタスクに移ったことを示しています。 | | | ID | タイプ | [ステップ] | [リソース] | 経過時間 (ミリ秒) | タイムスタンプ | | --- |--- |--- |--- |--- |--- | | ** 1** | `ExecutionStarted` | | - | 0 | 2022 年 3 月 11 日午後 2 時 50 分 34.303 秒 | | ** 2** | `TaskStateEntered` | `StartAutomationWaitForCallBack` | - | 40 | 2022 年 3 月 11 日午後 2 時 50 分 34.343 秒 | | ** 3** | `TaskScheduled` | `StartAutomationWaitForCallBack` | - | 40 | 2022 年 3 月 11 日午後 2 時 50 分 34.343 秒 | | ** 4** | `TaskStarted` | `StartAutomationWaitForCallBack` | - | 154 | 2022 年 3 月 11 日午後 2 時 50 分 34.457 秒 | | ** 5** | `TaskSubmitted` | `StartAutomationWaitForCallBack` | - | 657 | 2022 年 3 月 11 日午後 2 時 50 分 34.960 秒 | | ** 6** | `TaskSucceeded` | `StartAutomationWaitForCallBack` | - | 103835 | 2022 年 3 月 11 日午後 2 時 52 分 18.138 秒 | | ** 7** | `TaskStateExited` | `StartAutomationWaitForCallBack` | - | 103860 | 2022 年 3 月 11 日午後 2 時 52 分 18.163 秒 | | ** 8** | `ExecutionSucceeded` | | - | 103897 | 2022 年 3 月 11 日午後 2 時 52 分 18.200 秒 | # AWS Lambda 関数で Python を使用して S3 オブジェクトの並列読み取りを実行する *Eduardo Bortoluzzi、Amazon Web Services* ## 概要 このパターンを使用して、Amazon Simple Storage Service (Amazon S3) バケットからドキュメントのリストをリアルタイムで取得して要約できます。このパターンは、Amazon Web Services (AWS) の S3 バケットからオブジェクトを並列に読み取るためのサンプルコードを提供します。このパターンは、Python を使用して AWS Lambda 関数で I/O バインドタスクを効率的に実行する方法を示しています。 ある金融会社は、このパターンをインタラクティブなソリューションで使用して、相関する金融取引をリアルタイムで手動で承認または拒否しました。金融取引ドキュメントを市場に関連する S3 バケットに保存しました。オペレーターは S3 バケットからドキュメントのリストを選択し、ソリューションが計算した取引の合計値を分析して、選択したバッチを承認または拒否することを決定しました。 I/O にバインドされたタスクは複数のスレッドをサポートします。このサンプルコードでは、Lambda 関数が最大 1,024 スレッドをサポートしている場合でも、[concurrent.futures.ThreadPoolExecutor](https://docs.python.org/3.13/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor) は最大 30 の同時スレッドで使用されます (これらのスレッドの 1 つがメインプロセスです)。この制限があるのは、スレッドが多すぎると、コンテキストの切り替えとコンピューティングリソースの使用率が原因でレイテンシーの問題が発生するためです。また、すべてのスレッドが S3 オブジェクトのダウンロードを同時に実行できるように、`botocore` でプールの最大接続数を増やす必要があります。 サンプルコードは、S3 バケット内で JSON データとともに 8.3 KB オブジェクトを 1 つ使用します。オブジェクトは複数回読み込まれます。Lambda 関数がオブジェクトを読み取ると、JSON データは Python オブジェクトにデコードされます。2024 年 12 月、この例を実行した後の結果は、2,304 MB のメモリで設定された Lambda 関数を使用して 2.3 秒で 1,000 回の読み込みを処理し、27 秒で 10,000 回の読み込みを処理しました。 は、128 MB から 10,240 MB (10 GB) のメモリ設定 AWS Lambda をサポートしますが、Lambdamemory を 2,304 MB を超えて増やすと、この特定の I/O バウンドタスクの実行時間を短縮することはできませんでした。 [AWS Lambda Power Tuning](https://github.com/alexcasalboni/aws-lambda-power-tuning) ツールを使用して、さまざまな Lambda メモリ設定をテストし、タスクの最適な費用対効果の比率を検証しました。詳細については、「[追加リソース](#run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-additional)」のセクションを参照してください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + Python 開発の習熟度 **制限事項** + Lambda 関数は、最大 [1,024 の実行プロセスまたはスレッド](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution)を持つことができます。 + 新しい AWS アカウント の Lambda メモリ制限は 3,008 MB です。それに応じて AWS Lambda Power Tuning ツールを調整します。詳細については、「[トラブルシューティング](#run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-troubleshooting)」セクションを参照してください。 + Amazon S3 には、[パーティション化されたプレフィックスごとに 1 秒あたり 5,500 件の GET/HEAD リクエスト](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)の制限があります。 **製品バージョン** + Python 3.9 以降 + AWS Cloud Development Kit (AWS CDK) v2 + AWS Command Line Interface (AWS CLI) バージョン 2 + AWS Lambda Power Tuning 4.3.6 (オプション) ## アーキテクチャ **ターゲットテクノロジースタック** + AWS Lambda + Amazon S3 + AWS Step Functions ( AWS Lambda Power Tuning がデプロイされている場合) **ターゲットアーキテクチャ** 次の図は、S3 バケットからオブジェクトを並行して読み取る Lambda 関数を示しています。この図には、Lambda 関数メモリを微調整するための AWS Lambda Power Tuning ツール用の Step Functions ワークフローもあります。このファインチューニングは、コストとパフォーマンスのバランスをとるのに役立ちます。 ![\[Lambda 関数、S3 バケット、AWS Step Functions を示す図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/828696e2-6df7-4536-9205-951c99449f4e.png) **自動化とスケール** Lambda 関数は、必要に応じて迅速にスケールします。需要が高いときに Amazon S3 から 503 Slow Down エラーを受信しないように、スケーリングにいくつかの制限を設定することをお勧めします。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK) v2](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html) は、コードで AWS クラウド インフラストラクチャを定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。デプロイするインフラストラクチャの例が作成されました AWS CDK。 + [AWS Command Line InterfaceAWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。このパターンでは、 AWS CLI バージョン 2 を使用してサンプル JSON ファイルをアップロードします。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Simple Storage Service Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数と他の AWS のサービスを組み合わせてビジネスクリティカルなアプリケーションを構築するのに役立つサーバーレスオーケストレーションサービスです。 **その他のツール** + 「[Python](https://www.python.org/)」は汎用のコンピュータープログラミング言語です。[アイドルワーカースレッドの再利用](https://docs.python.org/3.8/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor)は Python バージョン 3.8 で導入され、このパターンの Lambda 関数コードは Python バージョン 3.9 以降用に作成されました。 **コードリポジトリ** このパターンのコードは、「[aws-lambda-parallel-download](https://github.com/aws-samples/aws-lambda-parallel-download)」GitHub リポジトリで利用できます。 ## ベストプラクティス + この AWS CDK コンストラクトは、インフラストラクチャをデプロイするための AWS アカウントユーザーのアクセス許可に依存します。 AWS CDK Pipelines またはクロスアカウントデプロイを使用する場合は、[「スタックシンセサイザー](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-synthesizers)」を参照してください。 + このサンプルアプリケーションでは、S3 バケットでアクセスログが有効になっていません。本番コードでアクセスログを有効にするのがベストプラクティスです。 ## エピック ### 開発環境を準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Python がインストールされているバージョンを確認します。 | このコードは Python 3.9 と Python 3.13 で特別にテストされており、これらのリリース間のすべてのバージョンで動作するはずです。Python のバージョンを確認するには、ターミナルで `python3 -V` を実行し、必要に応じて新しいバージョンをインストールします。必要なモジュールがインストールされていることを確認するには、`python3 -c "import pip, venv"` を実行します。エラーメッセージが表示されない場合は、モジュールが正しくインストールされ、このサンプルを実行する準備ができていることを意味します。 | クラウドアーキテクト | | をインストールします AWS CDK。 | まだインストール AWS CDK されていない場合は、[「 の開始方法 AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html)」の手順に従ってください。インストールされている AWS CDK バージョンが 2.0 以降であることを確認するには、 を実行します`cdk –version`。 | クラウドアーキテクト | | 環境 をブートストラップします。 | まだブートストラップされていない場合、環境をブートストラップするには、「[AWS CDKで使用する環境をブートストラップする](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping-env.html)」の手順に従ってください。 | クラウドアーキテクト | ### サンプルリポジトリのクローンを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | 最新バージョンのリポジトリのクローンを作成するには、次のコマンドを実行します。
git clone --depth 1 --branch v1.2.0 \
git@github.com:aws-samples/aws-lambda-parallel-download.git
| クラウドアーキテクト | | 作業ディレクトリをクローニングされたリポジトリに変更します。 | 次のコマンドを実行します。
cd aws-lambda-parallel-download
| クラウドアーキテクト | | Python 仮想環境を作成します。 | Python 仮想環境を作成するには、次のコマンドを実行します。
python3 -m venv .venv
| クラウドアーキテクト | | 仮想環境をアクティブ化します。 | 仮想環境を有効にするには、次のコマンドを実行します。
source .venv/bin/activate
| クラウドアーキテクト | | SDK の依存関係をインストールします。 | Python 依存関係をインストールするには、`pip` コマンドを実行します。
pip install -r requirements.txt
| クラウドアーキテクト | | コードを参照します。 | (オプション) S3 バケットからオブジェクトをダウンロードするサンプルコードは、`resources/parallel.py` にあります。インフラストラクチャコードは `parallel_download` フォルダにあります。 | クラウドアーキテクト | ### アプリをデプロイしてテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションをデプロイします。 | `cdk deploy` を実行します。 AWS CDK 出力を書き留めます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.html) | クラウドアーキテクト | | サンプル JSON ファイルをアップロードします。 | リポジトリには、約 9 KB のサンプル JSON ファイルが含まれています。作成したスタックの S3 バケットにファイルをアップロードするには、次のコマンドを実行します。
aws s3 cp sample.json s3://
を AWS CDK 出力の対応する値``に置き換えます。 | クラウドアーキテクト | | アプリを実行します。 | アプリを実行するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.html) | クラウドアーキテクト | | ダウンロード数を追加します。 | (オプション) 1,500 の GET オブジェクト呼び出しを実行するには、`Test` パラメータの**イベント JSON** で次の JSON を使用します。
{"repeat": 1500, "objectKey": "sample.json"}
| クラウドアーキテクト | ### オプション: AWS Lambda 電源調整を実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Lambda Power Tuning ツールを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.html)実行の最後に、**[実行の入力と出力]** タブに結果が表示されます。 | クラウドアーキテクト | | AWS Lambda パワーチューニングの結果をグラフで表示します。 | **[実行の入力と出力]** タブで、`visualization` プロパティリンクをコピーし、新しいブラウザタブに貼り付けます。 | クラウドアーキテクト | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットからオブジェクトを削除します。 | デプロイされたリソースを破棄する前に、S3 バケットからすべてのオブジェクトを削除します。
aws s3 rm s3:// \
--recursive
を AWS CDK 出力の値``に置き換えることを忘れないでください。 | クラウドアーキテクト | | リソースを破棄します。 | このパイロット用に作成されたすべてのリソースを破棄するには、次のコマンドを実行します。
cdk destroy
| クラウドアーキテクト | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | `'MemorySize' value failed to satisfy constraint: Member must have value less than or equal to 3008` | 新しいアカウントでは、Lambda 関数で 3,008 MB 以上を設定できない場合があります。 AWS Lambda Power Tuning を使用してテストするには、Step Functions の実行を開始するときに、入力 JSON に次のプロパティを追加します。
"powerValues": [
    512,
    1024,
    1536,
    2048,
    2560,
    3008
  ]
| ## 関連リソース + [Python – concurrent.futures.ThreadPoolExecutor](https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor) + [Lambda クォータ — 関数の設定、デプロイ、実行](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution) + [Python AWS CDK での の使用](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-python.html) + [AWS Lambda パワーチューニングによる関数のプロファイリング](https://docs.aws.amazon.com/lambda/latest/operatorguide/profile-functions.html) ## 追加情報 **Code** 次のコードスニペットは、並列 I/O 処理を実行します。 ``` with ThreadPoolExecutor(max_workers=MAX_WORKERS) as executor: for result in executor.map(a_function, (the_arguments)): ... ``` `ThreadPoolExecutor` は、スレッドが利用可能になると再利用します。 **テストと結果** これらのテストは 2024 年 12 月に実施されました。 最初のテストでは 2,500 のオブジェクト読み取りが処理され、次のような結果になりました。 ![\[メモリの増加に伴う呼び出し時間の短縮と呼び出しコストの増加。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/f6743412-1e52-4c4c-a51c-ac0f75b3b998.png) 3,009 MB から、処理時間レベルはメモリが増えてもほぼ同じままでしたが、メモリサイズの増加に伴ってコストが増加しました。 別のテストでは、256 MB の倍数の値を使用し、10,000 のオブジェクト読み取りを処理して、1,536 MB から 3,072 MB のメモリの範囲を調査しました。その結果は次のとおりです。 ![\[呼び出し時間の短縮と呼び出しコストの増加の差が減少しました。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/c75d4443-74d8-4b93-9b4d-b2640869381e.png) 最高の費用対効果の比率は、2,304 MB のメモリ Lambda 設定でした。 比較として、2,500 のオブジェクト読み取りのシーケンシャルプロセスには 47 秒かかりました。2,304 MB の Lambda 設定を使用した並列処理には 7 秒かかり、85% 短縮されました。 ![\[シーケンシャル処理から並列処理に切り替えるときの時間の短縮を示すグラフ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/f3dcc44d-ac20-4b75-897d-1d71f0d59781.png) # から OpenSearch AWS Lambda にテレメトリデータを送信してリアルタイムの分析と視覚化を行う *Amazon Web Services、Tabby Ward、Guy Bachar、David Kilzer* ## 概要 最新のアプリケーションはますます分散され、イベント駆動型になり、リアルタイムのモニタリングとオブザーバビリティの必要性が強化されています。 AWS Lambda は、スケーラブルでイベント駆動型のアーキテクチャを構築する上で重要な役割を果たしているサーバーレスコンピューティングサービスです。ただし、Amazon CloudWatch Logs のみに依存すると、Lambda 関数のモニタリングとトラブルシューティングが難しくなるため、作業に遅延が発生し、保持期間が限定される可能性があります。 この課題に対処するために、Lambda Telemetry API AWS を導入しました。これにより、Lambda 関数はテレメトリデータをサードパーティーのモニタリングおよびオブザーバビリティツールに直接送信できます。この API は、ログ、メトリクス、トレースのリアルタイムストリーミングをサポートし、Lambda 関数のパフォーマンスと状態を包括的かつタイムリーに表示します。 このパターンでは、オープンソースの分散検索および分析エンジンである [OpenSearch](https://opensearch.org/docs/latest/) と Lambda Telemetry API を統合する方法について説明します。OpenSearch は、大量のデータの取り込み、保存、分析を行う強力かつスケーラブルなプラットフォームを提供するため、Lambda テレメトリデータに最適です。具体的には、このパターンは、 AWSによって提供される Lambda 拡張機能を使用して、Python で記述された Lambda 関数から OpenSearch クラスターに直接ログを送信する方法を示しています。このソリューションは柔軟性が高くカスタマイズも可能です。したがって、独自の Lambda 拡張機能を作成することも、サンプルソースコードを調整して希望する出力形式に変更することもできます。 このパターンでは、Lambda Telemetry API と OpenSearch の統合を設定する方法を説明し、セキュリティ、コスト最適化、スケーラビリティに関するベストプラクティスも提供します。目的は、Lambda 関数の理解を深め、サーバーレスアプリケーションの全体的なオブザーバビリティを向上させることです。 | | | 注: このパターンは、Lambda Telemetry API とマネージド OpenSearch の統合を中心としています。ただし、説明されている原則と手法は、セルフマネージド型の OpenSearch と Elasticsearch にも適用できます。 | | --- | ## 前提条件と制限事項 統合プロセスを開始する前に、次の前提条件を満たしていることを確認してください。 **AWS アカウント**: 次の AWS リソースを作成および管理するための適切なアクセス許可 AWS アカウント を持つアクティブな 。 + AWS Lambda + AWS Identity and Access Management (IAM) + Amazon OpenSearch Service (マネージド OpenSearch クラスターを使用している場合) **OpenSearch クラスター**: + 既存のセルフマネージド OpenSearch クラスターまたは OpenSearch Service などのマネージドサービスを使用できます。 + OpenSearch Service を使用している場合は、OpenSearch Service ドキュメントの「[Getting started with Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gsg.html)」の手順に従って OpenSearch クラスターを設定します。 + OpenSearch クラスターが Lambda 関数からアクセス可能であり、アクセスポリシー、暗号化、認証などの必要なセキュリティ設定で構成されていることを確認します。 + Lambda テレメトリデータを取り込むために必要なインデックスマッピングと設定で OpenSearch クラスターを構成します。詳細については、OpenSearch Service ドキュメントの「[Loading streaming data into Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/integrations.html)」を参照してください。 **ネットワーク接続**: + Lambda 関数に OpenSearch クラスターにアクセスするために必要なネットワーク接続があることを確認します。仮想プライベートクラウド (VPC) の設定方法のガイダンスについては、OpenSearch Service ドキュメントの「[Launching your Amazon OpenSearch Service domains within a VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html)」を参照してください。 **IAM ロールとポリシー**: + Lambda 関数が OpenSearch クラスターにアクセスし、 AWS Secrets Managerに保存されている認証情報にアクセスするために必要なアクセス許可を持つ IAM ロールを作成します。 + `AWSLambdaBasicExecutionRole` ポリシーや OpenSearch を操作するために必要な追加のアクセス許可など、適切な IAM ポリシーをロールにアタッチします。 + Lambda 関数に付与された IAM アクセス許可により OpenSearch クラスターへのデータの書き込みが許可されていることを確認します。IAM アクセス許可の管理の詳細については、Lambda ドキュメントの「[実行ロールを使用した Lambda 関数のアクセス許可の定義](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)」を参照してください。 **プログラミング言語の知識**: + Lambda 関数と Lambda 拡張機能のサンプルコードを理解して変更するには、Python (または選択したプログラミング言語) に関する基本的な知識が必要です。 **開発環境**: + Lambda 関数と拡張機能を構築およびデプロイするために必要なツールと依存関係を使用して、ローカル開発環境を設定します。 **AWS CLI または AWS マネジメントコンソール**: + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) をインストールして設定するか、適切な認証情報 AWS マネジメントコンソール で を使用して必要な を操作します AWS のサービス。 **モニタリングとログ記録**: + Amazon CloudWatch や などのサービスを含む AWS、 のモニタリングとログ記録 AWS CloudTrail のベストプラクティスに精通し、モニタリングと監査を行います。 + Lambda 関数の CloudWatch Logs をチェックして、Lambda Telemetry API 統合に関連するエラーや例外を特定します。トラブルシューティングのガイダンスについては、[Lambda Telemetry API ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/telemetry-api.html)を参照してください。 ## アーキテクチャ このパターンでは、OpenSearch Service を使用して、Lambda 関数によって生成されたログとテレメトリデータを保存します。このアプローチでは、ログを OpenSearch クラスターに直接すばやくストリーミングできるため、CloudWatch Logs を仲介として使用する際のレイテンシーとコストを削減できます。 | | | Lambda 拡張機能コードは、OpenSearch API を直接使用するか、[OpenSearch クライアントライブラリ](https://opensearch.org/docs/latest/clients/index/)を使用して、テレメトリを OpenSearch Service にプッシュできます。Lambda 拡張機能は、OpenSearch API でサポートされている一括操作を使用してテレメトリイベントをバッチ処理し、1 回のリクエストで OpenSearch Service に送信できます。 | | --- | 次のワークフロー図は、エンドポイントとして OpenSearch クラスターを使用する場合の Lambda 関数のログワークフローを示しています。 ![\[OpenSearch クラスターにテレメトリデータを送信するためのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/57fe8796-9f36-46cf-8304-f506242b9f04/images/283ccdcd-a0e1-40a2-a95a-3bd046bfa8ca.png) アーキテクチャには以下のコンポーネントが含まれています。 + Lambda 関数: 実行中にログとテレメトリデータを生成するサーバーレス関数。 + Lambda 拡張機能: Lambda Telemetry API を使用して OpenSearch クラスターと直接統合する Python ベースの拡張機能。この拡張機能は、Lambda 関数と同じ実行環境で一緒に実行されます。 + Lambda Telemetry API: Lambda 拡張機能がログ、メトリクス、トレースなどのテレメトリデータをサードパーティーのモニタリングおよびオブザーバビリティツールに直接送信できるようにする API。 + Amazon OpenSearch Service クラスター: AWSでホストされているマネージド OpenSearch クラスター。このクラスターは、Lambda 拡張機能を介して Lambda 関数からストリーミングされたログデータの取り込み、保存、インデックス作成を行います。 ワークフローは以下のステップで構成されます。 1. Lambda 関数が呼び出され、実行中にログとテレメトリデータが生成されます。 1. Lambda 拡張機能は関数と一緒に実行され、Lambda Telemetry API を使用してログとテレメトリデータをキャプチャします。 1. Lambda 拡張機能は、OpenSearch Service クラスターとの安全な接続を確立し、ログデータをリアルタイムでストリーミングします。 1. OpenSearch Service クラスターは、Kibana やその他の互換性のあるアプリケーションなどのツールを使用して、ログデータの取り込み、インデックス作成、保存を行い、検索、分析、視覚化に使用できるようにします。 CloudWatch Logs を回避し、ログデータを OpenSearch クラスターに直接送信するため、このソリューションには次のようないくつかの利点があります。 + リアルタイムのログストリーミングと分析により、より迅速なトラブルシューティングが可能になり、オブザーバビリティが向上します。 + CloudWatch Logs に関連するレイテンシーと保持制限の可能性が軽減されます。 + 高い柔軟性により、Lambda 拡張機能をカスタマイズする、特定の出力形式や追加の処理用に独自の拡張機能を作成するといった作業に対応できます。 + OpenSearch Service の検索、分析、視覚化機能と統合して、ログ分析とモニタリングを行うことができます。 「[エピック](#send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-epics)」セクションでは、Lambda 拡張機能の設定、Lambda 関数の設定、OpenSearch Service クラスターとの統合の段階的な手順を説明します。セキュリティ上の考慮事項、コスト最適化戦略、ソリューションのモニタリングとトラブルシューティングのヒントについては、「[ベストプラクティス](#send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-best-practices)」セクションを参照してください。 ## ツール **AWS サービス** + [AWS Lambda](https://aws.amazon.com/lambda/) はサーバーのプロビジョニングや管理をする必要がなく、コードを実行できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。 + [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) は、 が提供するフルマネージドサービス AWS であり、OpenSearch クラスターをクラウドに簡単にデプロイ、運用、スケーリングできます。 + [Lambda 拡張機能](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html)は、カスタムコードを一緒に実行することで、Lambda 関数の機能を拡張します。Lambda 拡張機能を使用して、Lambda を、モニタリング、オブザーバビリティ、セキュリティ、およびガバナンスのさまざまなツールと統合します。 + [AWS Lambda Telemetry API](https://docs.aws.amazon.com/lambda/latest/dg/telemetry-api.html) を使用すると、拡張機能を使用して、Lambda から直接拡張モニタリングおよびオブザーバビリティデータをキャプチャし、任意の送信先に送信できます。 + [CloudFormation](https://aws.amazon.com/cloudformation/) では、 AWS リソースをモデル化してセットアップできるため、それらのリソースの管理に費やす時間が減り、アプリケーションに集中する時間が増えます。 **コードリポジトリ** + [AWS Lambda 拡張機能](https://github.com/aws-samples/aws-lambda-extensions)には、独自の拡張機能の構築を開始するのに役立つ AWS および AWS パートナーからのデモとサンプルプロジェクトが含まれています。 + [OpenSearch の Lambda テレメトリ統合の例](https://github.com/aws-samples/aws-lambda-extensions/tree/main/python-example-telemetry-opensearch-extension)には、Lambda 関数から OpenSearch クラスターにログを送信する方法を示す Lambda 拡張機能のサンプルが用意されています。 **その他のツール** + [OpenSearch](https://opensearch.org/faq/) は、大量のデータを取り込み、保存、分析するための強力なプラットフォームを提供するオープンソースの分散検索および分析エンジンです。 + Kibana は、OpenSearch で使用できるオープンソースのデータ視覚化および探索ツールです。視覚化と分析の実装はこのパターンの範囲外になりますので注意してください。詳細については、[Kibana のドキュメント](https://www.elastic.co/guide/en/kibana/current/index.html)とその他のリソースを参照してください。 ## ベストプラクティス Lambda Telemetry API を OpenSearch と統合するときは、次のベストプラクティスを考慮してください。 **セキュリティとアクセスコントロール** + **安全な通信**: Lambda 関数と OpenSearch クラスター間のすべての通信を HTTPS を使用して暗号化します。Lambda 拡張機能と OpenSearch 設定で必要な SSL/TLS 設定を構成します。 + **IAM アクセス許可**: + 拡張機能は Lambda 関数と同じ実行環境で実行されるため、ファイルシステム、ネットワーク、環境変数などのリソースへの同じレベルのアクセスを継承します。 + Lambda Telemetry API にアクセスして OpenSearch クラスターにデータを書き込むために必要な最小限の IAM アクセス許可を Lambda 関数に付与します。[最小特権の原則](https://docs.aws.amazon.com/lambda/latest/operatorguide/least-privilege.html)を使用して、アクセス許可の範囲を制限します。 + **OpenSearch アクセス制御**: OpenSearch クラスターにきめ細かなアクセス制御を実装して、機密データへのアクセスを制限します。OpenSearch では、ユーザー認証、ロールベースのアクセス制御、インデックスレベルのアクセス許可などの組み込みのセキュリティ機能を使用します。 + **信頼できる拡張機能**: 常に信頼できるソースからのみ拡張機能をインストールします。などのInfrastructure as Code (IaC) ツールを使用して、IAM アクセス許可を含む同じ拡張機能設定を複数の Lambda 関数にアタッチするプロセス CloudFormation を簡素化します。IaC ツールは、以前に使用された拡張機能とバージョンの監査レコードも提供します。 + **機密データの処理**: 拡張機能を構築するときに、機密データのログを回避してください。監査のためにログ記録または永続化する前に、ペイロードとメタデータをサニタイズします。 **コスト最適化** + **モニタリングとアラート**: Lambda 関数から OpenSearch に送信されるデータの量を追跡するモニタリングとアラートのメカニズムを設定します。これにより、潜在的なコスト超過を特定して対処できます。 + **データ保持**: OpenSearch の Lambda テレメトリデータに適したデータ保持期間を慎重に検討してください。保持期間が長くなるとストレージコストが増加する可能性があるため、オブザーバビリティのニーズとコスト最適化のバランスを取ります。 + **圧縮とインデックス作成**: データ圧縮を有効にし、OpenSearch インデックス作成戦略を最適化して、Lambda テレメトリデータのストレージフットプリントを削減します。 + **CloudWatch への依存を減らす**: Lambda Telemetry API を OpenSearch と直接統合することで、CloudWatch Logs への依存を減らすことができ、コスト削減につながる可能性があります。これは、Lambda Telemetry API によって OpenSearch に直接ログを送信できるため、CloudWatch にデータを保存して処理する必要がなくなるためです。 **スケーラビリティと信頼性** + **非同期処理**: Amazon Simple Queue Service (Amazon SQS) や Amazon Kinesis などの非同期処理パターンを使用して、Lambda 関数の実行を OpenSearch データインジェストから切り離します。これにより、Lambda 関数の応答性を維持し、システムの全体的な信頼性を向上させることができます。 + **OpenSearch クラスターのスケーリング**: OpenSearch クラスターのパフォーマンスとリソース使用率をモニタリングし、必要に応じてスケールアップまたはスケールダウンして、増加する Lambda テレメトリデータを処理します。 + **フェイルオーバーとディザスタリカバリ**: 定期的なバックアップや障害発生時にデータをすばやく復元する機能など、OpenSearch クラスターの堅牢なディザスタリカバリ戦略を実装します。 **オブザーバビリティとモニタリング** + **ダッシュボードと視覚化**: Kibana または他のダッシュボードツールを使用して、OpenSearch のテレメトリデータに基づいて Lambda 関数のパフォーマンスと状態に関するインサイトを提供するカスタムダッシュボードと視覚化を作成します。 + **アラートと通知**: Lambda 関数の異常、エラー、パフォーマンスの問題を積極的にモニタリングするようにアラートと通知を設定します。これらのアラートと通知を既存のインシデント管理プロセスと統合します。 + **トレースと相関関係**: Lambda テレメトリデータにリクエスト ID や相関 ID などの関連するトレース情報が含まれていることを確認し、分散サーバーレスアプリケーション全体でエンドツーエンドのオブザーバビリティとトラブルシューティングを実現します。 これらのベストプラクティスに従うことで、Lambda Telemetry API と OpenSearch の統合の安全性、コスト効率、スケーラビリティを確保し、サーバーレスアプリケーションに包括的なオブザーバビリティを提供できます。 ## エピック ### Lambda 拡張機能レイヤーを構築およびデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソースコードをダウンロードします。 | [AWS Lambda 拡張機能](https://github.com/aws-samples/aws-lambda-extensions)リポジトリからサンプル拡張機能をダウンロードします。 | アプリ開発者、クラウドアーキテクト | | `python-example-telemetry-opensearch-extension` フォルダに移動します。 | ダウンロードした [AWS Lambda 拡張機能](https://github.com/aws-samples/aws-lambda-extensions)リポジトリには、いくつかのユースケースと言語ランタイムに関する多数の例が含まれています。[python-example-telemetry-opensearch-extension](https://github.com/aws-samples/aws-lambda-extensions/tree/main/python-example-telemetry-opensearch-extension) フォルダに移動し、Python OpenSearch 拡張機能を使用して OpenSearch にログを送信します。 | アプリ開発者、クラウドアーキテクト | | 拡張機能エンドポイントを実行するアクセス許可を追加します。 | 次のコマンドを実行して、拡張機能エンドポイントを実行可能にします。
chmod +x python-example-telemetry-opensearch-extension/extension.py
| アプリ開発者、クラウドアーキテクト | | 拡張機能の依存関係をローカルにインストールします。 | 以下のコマンドを実行して、Python コードのローカル依存関係をインストールします。
pip3 install -r python-example-telemetry-opensearch-extension/requirements.txt -t ./python-example-telemetry-opensearch-extension/
これらの依存関係は、拡張機能コードとともにマウントされます。 | アプリ開発者、クラウドアーキテクト | | 拡張機能の .zip パッケージを作成して、レイヤーとしてデプロイします。 | 拡張機能の .zip ファイルには、拡張機能実行可能ファイルがある `extensions/` というルートディレクトリと、拡張機能のコアロジックとその依存関係がある `python-example-telemetry-opensearch-extension/` という別のルートディレクトリが含まれている必要があります。拡張機能の .zip パッケージを作成します。
chmod +x extensions/python-example-telemetry-opensearch-extension
zip -r extension.zip extensions python-example-telemetry-opensearch-extension
| アプリ開発者、クラウドアーキテクト | | 拡張機能を Lambda レイヤーとしてデプロイします。 | 拡張機能の .zip ファイルと次のコマンドを使用してレイヤーを公開します。
aws lambda publish-layer-version \
--layer-name "python-example-telemetry-opensearch-extension" \
--zip-file "fileb://extension.zip"
| アプリ開発者、クラウドアーキテクト | ### 拡張機能を関数に統合する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | レイヤーを関数に追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html)Lambda 関数へのレイヤーの追加についての詳細は、「[Lambda ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/adding-layers.html)」を参照してください。 | アプリ開発者、クラウドアーキテクト | | 関数の環境変数を設定します。 | 関数ページで、**[設定]** タブを選択し、次の環境変数を関数に追加します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html) | アプリ開発者、クラウドアーキテクト | ### ログ記録ステートメントを追加して関数をテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 関数にログ記録ステートメントを追加します。 | [組み込みのログ記録メカニズム](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html)のいずれか、または任意のログ記録モジュールを使用して、関数にログ記録ステートメントを追加します。Python でのメッセージのログ記録の例を次に示します。
print("Your Log Message Here")
logger = logging.getLogger(__name__)

logger.info("Test Info Log.")
logger.error("Test Error Log.")
| アプリ開発者、クラウドアーキテクト | | 関数をテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html)すべてが適切に機能すると、「**Executing function: succeeded**」と表示されます。 | アプリ開発者、クラウドアーキテクト | ### OpenSearch でログを表示する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インデックスをクエリします。 | OpenSearch で、次のコマンドを実行してインデックスをクエリします。
SELECT * FROM index-name
ログはクエリ結果に表示されます。 | クラウドアーキテクト | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 接続の問題 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html) | | データインジェストエラー | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html) | ## 関連リソース + [OpenSearch の Lambda テレメトリー統合の例](https://github.com/aws-samples/aws-lambda-extensions/tree/main/python-example-telemetry-opensearch-extension) (GitHub リポジトリ) + [Lambda 拡張機能を使用して Lambda 関数を補強する](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html) (Lambda ドキュメント) + [Lambda Telemetry API](https://docs.aws.amazon.com/lambda/latest/dg/telemetry-api.html) (Lambda ドキュメント) + [AWS Lambda Telemetry API の](https://aws.amazon.com/blogs/compute/introducing-the-aws-lambda-telemetry-api/)紹介 (AWS ブログ記事) + [AWS Lambda Telemetry API と Prometheus および OpenSearch の統合](https://aws.amazon.com/blogs/opensource/integrating-the-aws-lambda-telemetry-api-with-prometheus-and-opensearch) (AWS ブログ記事) ## 追加情報 **ログ構造の変更** 拡張機能は、デフォルトでネストされたドキュメントとしてログを OpenSearch に送信します。これにより、ネストされたクエリを実行して各列の値を取得できます。 デフォルトのログ出力が特定のニーズを満たさない場合は、 が提供する Lambda 拡張機能のソースコードを変更することでカスタマイズできます AWS。 AWS は、出力をビジネス要件に合わせて調整するようお客様にお勧めします。ログ出力を変更するには、拡張機能のソースコード内の `telemetry_dispatcher.py` ファイルで `dispatch_to_opensearch` 関数を見つけ、必要な変更を行います。 # セルベースアーキテクチャ用にサーバーレスセルルーターを設定する *Amazon Web Services、Mian Tariq、Ioannis Lioupras* ## 概要 セルベースのグローバルアプリケーションのシステムに対するエントリポイントとして、セルルーターはユーザーを適切なセルに効率的に割り当て、ユーザーにエンドポイントを提供します。セルルーターは、ユーザーとセルとの間のマッピングの保存、セルの容量のモニタリング、必要に応じた新しいセルのリクエストなどの機能を処理します。中断の可能性がある間、セルルーターの機能を維持することが重要です。 このパターンのセルルーターの設計フレームワークは、耐障害性、スケーラビリティ、全体的なパフォーマンスの最適化に焦点を当てています。このパターンでは、クライアントが初回ログイン時にエンドポイントをキャッシュし、セルと直接通信する静的ルーティングを使用します。このデカップリングは、セルルーターの障害発生時にセルベースのアプリケーションの機能が中断されないようにすることで、システムの耐障害性を向上させます。 このパターンでは、 AWS CloudFormation テンプレートを使用してアーキテクチャをデプロイします。テンプレートのデプロイの詳細、または を使用して同じ設定をデプロイするには AWS マネジメントコンソール、[「追加情報](#serverless-cell-router-architecture-additional)」セクションを参照してください。 **重要** このパターンで示されているデモンストレーション、コード、 CloudFormation テンプレートは、説明のみを目的としています。素材は、設計パターンを説明し、理解を支援する目的でのみ提供されています。デモとコードは本番用ではないため、本稼働のアクティビティには使用しないでください。本番環境でこのコードまたはデモを使用しようとすることはお勧めしません。試みた場合はお客様の責任となります。このパターンまたはそのコンポーネントを本番環境に実装する前に、適切な専門家に相談し、徹底的なテストを実行することをお勧めします。 ## 前提条件と制限 **前提条件** + アクティブな Amazon Web Services (AWS) アカウント + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) の最新バージョン + CloudFormation スタック、 AWS Lambda 関数、および関連リソースを作成するために必要なアクセス許可を持つ [AWS 認証情報](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) **製品バージョン** + Python 3.12 ## アーキテクチャ 次の図は、セルルーターの大まかな設計を示しています。 ![\[セルルーターの 5 つのステップのプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/fd2fbf9d-9ae4-4c27-bc32-cf117350137a/images/feb90b51-dd91-483b-b5a3-b0a5359686e3.png) この図は、次のワークフローを段階的に示しています。 1. ユーザーは、セルルーター API エンドポイントのフロントとして機能する Amazon API Gateway に問い合わせます。 1. Amazon Cognito は認証と認可を処理します。 1. AWS Step Functions ワークフローは以下のコンポーネントで構成されます。 + **オーケストレーター** ‒ は AWS Step Functions `Orchestrator`を使用してワークフローまたはステートマシンを作成します。ワークフローはセルルーター API によってトリガーされます。`Orchestrator` は、リソースパスに基づいて Lambda 関数を実行します。 + **ディスパッチャー** – `Dispatcher` Lambda 関数は、登録された新しいユーザーごとに 1 つの静的セルを識別して割り当てます。この関数は、ユーザー数が最も少ないセルを検索してユーザーに割り当て、エンドポイントを返します。 + **マッパー** ‒ `Mapper`オペレーションは、 CloudFormation テンプレートによって作成された `RoutingDB` Amazon DynamoDB データベース内のuser-to-cellのマッピングを処理します。トリガーされた `Mapper` 関数は、既に割り当てられたユーザーにエンドポイントを提供します。 + **スケーラー** – `Scaler` 関数は、セルの占有率と使用可能な容量を追跡します。必要に応じて、`Scaler` 関数は Amazon Simple Queue Service (Amazon SQS) を介して、プロビジョンとデプロイレイヤーにリクエストを送信して、新しいセルをリクエストできます。 + **バリデーター** – `Validator` 関数はセルエンドポイントを検証し、潜在的な問題を検出します。 1. は、セル情報と属性 (API エンドポイント、状態 AWS リージョン、メトリクス) `RoutingDB`を保存します。 1. セルの使用可能な容量がしきい値を超えると、セルルーターは Amazon SQS を介してプロビジョニングおよびデプロイサービスをリクエストして、新しいセルを作成します。 新しいセルが作成されると、`RoutingDB` はプロビジョンとデプロイレイヤーから更新されます。ただし、このプロセスはこのパターンの範囲外です。セルベースアーキテクチャ設計の前提の概要と、このパターンで使用されるセルルーター設計の詳細については、「[追加情報](#serverless-cell-router-architecture-additional)」セクションを参照してください。 ## ツール **AWS のサービス** + [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。 + [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) は、ウェブおよびモバイルアプリの認証、認可、およびユーザー管理機能を提供します。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを発揮します。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) は、分散ソフトウェアシステムとコンポーネントの統合と分離に役立つ、安全で耐久性があり、利用可能なホスト型キューを提供します。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、Lambda 関数と他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。 **その他のツール** + 「[Python](https://www.python.org/)」は汎用のコンピュータープログラミング言語です。 **コードリポジトリ** このパターンのコードは GitHub 内の [Serverless-Cell-Router](https://github.com/aws-samples/Serverless-Cell-Router/) リポジトリで利用できます。 ## ベストプラクティス セルベースのアーキテクチャを構築する際のベストプラクティスについては、以下の AWS Well-Architected ガイダンスを参照してください。 + [Reducing the Scope of Impact with Cell-Based Architecture](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/reducing-scope-of-impact-with-cell-based-architecture.html) + [AWS Well-Architected フレームワークの信頼性の柱: REL10-BP04 バルクヘッドアーキテクチャを使用して影響範囲を制限する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_use_bulkhead.html) ## エピック ### ソースファイルを準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コードリポジトリの例を複製します。 | 「Serverless-Cell-Router」GitHub リポジトリをコンピュータに複製するには、次のコマンドを使用します。
git clone https://github.com/aws-samples/Serverless-Cell-Router/
| 開発者 | | AWS CLI 一時的な認証情報を設定します。 | の認証情報 AWS CLI を使用して を設定します AWS アカウント。このチュートリアルでは、 AWS IAM Identity Center **コマンドラインまたはプログラムによるアクセス**オプションによって提供される一時的な認証情報を使用します。これにより`AWS_ACCESS_KEY_ID`、、`AWS_SECRET_ACCESS_KEY`、および `AWS_SESSION_TOKEN` AWS 環境変数が、 で使用する適切な認証情報で設定されます AWS CLI。 | 開発者 | | S3 バケットを作成する | CloudFormation テンプレートによるデプロイのために Serverless-Cell-Router Lambda 関数を保存してアクセスするために使用される S3 バケットを作成します。S3 バケットを作成するには、次のコマンドを実行します。
aws s3api create-bucket --bucket  --region eu-central-1 --create-bucket-configuration LocationConstraint=eu-central-1
| 開発者 | | .zip ファイルを作成します。 | [Functions](https://github.com/aws-samples/Serverless-Cell-Router/tree/main/Functions) ディレクトリにある Lambda 関数ごとに 1 つの .zip ファイルを作成します。これらの .zip ファイルは、Lambda 関数のデプロイに使用されます。Mac では、次の `zip` コマンドを使用します。
zip -j mapper-scr.zip Functions/Mapper.py
zip -j dispatcher-scr.zip Functions/Dispatcher.py
zip -j scaler-scr.zip Functions/Scaler.py
zip -j cp validator-scr.zip Functions/Validator.py
zip -j dynamodbDummyData-scr.zip Functions/DynamodbDummyData.py
| 開発者 | | .zip ファイルを S3 バケットにコピーします。 | すべての Lambda 関数の .zip ファイルを S3 バケットにコピーするには、次のコマンドを使用します。
aws s3 cp mapper-scr.zip s3://
aws s3 cp dispatcher-scr.zip s3://
aws s3 cp scaler-scr.zip s3://
aws s3 cp validator-scr.zip s3://
aws s3 cp dynamodbDummyData-scr.zip s3://
| 開発者 | ### CloudFormation スタックを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation テンプレートをデプロイします。 | CloudFormation テンプレートをデプロイするには、次の AWS CLI コマンドを実行します。
aws cloudformation create-stack --stack-name serverless.cell-router \
--template-body file://Serverless-Cell-Router-Stack-v10.yaml \
--capabilities CAPABILITY_IAM \
--parameters ParameterKey=LambdaFunctionMapperS3KeyParameterSCR,ParameterValue=mapper-scr.zip \
ParameterKey=LambdaFunctionDispatcherS3KeyParameterSCR,ParameterValue=dispatcher-scr.zip \
ParameterKey=LambdaFunctionScalerS3KeyParameterSCR,ParameterValue=scaler-scr.zip \
ParameterKey=LambdaFunctionAddDynamoDBDummyItemsS3KeyParameterSCR,ParameterValue=dynamodbDummyData-scr.zip \
ParameterKey=LambdaFunctionsS3BucketParameterSCR,ParameterValue= \
ParameterKey=CognitoDomain,ParameterValue= \
--region
| 開発者 | | 進捗確認。 | にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/cloudformation/]() で CloudFormation コンソールを開き、スタック開発の進行状況を確認します。ステータスが `CREATE_COMPLETE` の場合、スタックは正常にデプロイされています。 | 開発者 | ### 評価と検証 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ユーザーにセルを割り当てます。 | `Orchestrator` を開始するには、次の curl コマンドを実行します。
curl -X POST \
-H "Authorization: Bearer {User id_token}" \
https://xxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/cells
`Orchestrator` は `Dispatcher` 関数の実行をトリガーします。次に、`Dispatcher` はユーザーの存在を検証します。ユーザーが見つかった場合、`Dispatcher` は関連するセル ID とエンドポイント URL を返します。ユーザーが見つからない場合、`Dispatcher` はユーザーにセルを割り当て、割り当てられたセルの残容量を評価するためにセル ID を `Scaler` 関数に送信します。`Scaler` 関数は以下の応答を返します。`"cellID : cell-0002 , endPoint_1 : https://xxxxx.execute-api.eu-north-1.amazonaws.com/ , endPoint_2 : https://xxxxxxx.execute-api.eu-central-1.amazonaws.com/"` | 開発者 | | ユーザーセルを取得します。 | `Orchestrator` を使用して `Mapper` 関数を実行するには、次のコマンドを実行します。
curl -X POST \
-H "Authorization: Bearer {User id_token}" \
https://xxxxxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/mapper
`Orchestrator` は、ユーザーに割り当てられたセルを検索し、以下の応答でセル ID と URL を返します。`"cellID : cell-0002 , endPoint_1 : https://xxxxx.execute-api.eu-north-1.amazonaws.com/ , endPoint_2 : https://xxxxxxx.execute-api.eu-central-1.amazonaws.com/"` | 開発者 | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースをクリーンアップします。 | アカウントで追加料金が発生しないようにするには、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/serverless-cell-router-architecture.html) | アプリ開発者 | ## 関連リソース **リファレンス** + [アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) + [AWS 障害分離境界: 静的安定性](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html) **動画** [Physalia: Cell-based Architecture to Provide Higher Availability on Amazon EBS](https://www.youtube.com/watch?v=6IknqRZMFic) [https://www.youtube-nocookie.com/embed/6IknqRZMFic?controls=0](https://www.youtube-nocookie.com/embed/6IknqRZMFic?controls=0) ## 追加情報 **セルベースアーキテクチャ設計の前提** このパターンではセルルーターに焦点を当てていますが、環境全体を理解することが重要です。環境は 3 つの個別のレイヤーで構成されています。 + ルーティングレイヤー、またはセルルーターを含むシンレイヤー + さまざまなセルで構成されるセルレイヤー + セルをプロビジョニングしてアプリケーションをデプロイするプロビジョンとデプロイレイヤー 各レイヤーは、他のレイヤーに影響を与える障害が発生した場合でも機能を維持します。 AWS アカウント は障害分離の境界として機能します。 次の図は、レイヤーの概要を示しています。セルレイヤーおよびプロビジョンとデプロイレイヤーは、このパターンの範囲外です。 ![\[ルーティングレイヤー、複数のセルアカウントを持つセルレイヤー、プロビジョンとデプロイレイヤー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/fd2fbf9d-9ae4-4c27-bc32-cf117350137a/images/137ac34d-43c3-42b6-95de-a365ff611ce8.png) セルベースアーキテクチャの詳細については、「[Reducing the Scope of Impact with Cell-Based Architecture: Cell routing](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/cell-routing.html)」を参照してください。 **セルルーターの設計パターン** セルルーターはセル間で共有されるコンポーネントです。潜在的な影響を軽減するには、ルーティングレイヤーが、できるだけ薄くてシンプルで水平方向にスケーラブルな設計を使用することが重要です。ルーティングレイヤーは、システムのエントリポイントとして機能し、ユーザーを適切なセルに効率的に割り当てるために必要なコンポーネントのみで構成されます。このレイヤー内のコンポーネントは、セルの管理や作成には関与しません。 このパターンでは静的ルーティングを使用します。つまり、クライアントは最初のログイン時にエンドポイントをキャッシュし、その後セルとの直接通信を確立します。クライアントとセルルーター間の定期的なインタラクションが開始されると、現在のステータスを確認したり、更新を取得したりします。この意図的なデカップリングにより、セルルーターのダウンタイム発生時に既存のユーザーの操作を中断することなく、システム内で継続的な機能と耐障害性を提供します。 このパターンでは、セルルーターは次の機能をサポートしています。 + プロビジョンとデプロイレイヤーのセルデータベースからセルデータを取得し、ローカルデータベースを保存または更新します。 + セル割り当てアルゴリズムを使用して、アプリケーションの新しい登録ユーザーごとにセルを割り当てます。 + ユーザーとセル間のマッピングをローカルデータベースに保存します。 + ユーザー割り当て中にセルの容量をチェックし、ベンディングマシンのイベントをプロビジョンとデプロイレイヤーに上げてセルを作成します。 + セル作成基準アルゴリズムを使用してこの機能を提供します。 + 静的セルの URL を提供して、新しい登録ユーザーのリクエストに応答します。これらの URL は、有効期限 (TTL) を使用してクライアントでキャッシュされます。 + 新規または更新された URL を提供して、無効な URL の既存のユーザーリクエストに応答します。 CloudFormation テンプレートによってセットアップされるデモセルルーターをさらに理解するには、以下のコンポーネントとステップを確認してください。 1. Amazon Cognito ユーザープールを設定して構成します。 1. セルルーターの API Gateway API を設定して構成します。 1. DynamoDB テーブルを作成します。 1. SQS キューを作成して設定します。 1. `Orchestrator` を実装します。 1. Lambda 関数 (`Dispatcher`、`Scaler`、`Mapper`、`Validator`) を実装します。 1. 評価して検証します。 プロビジョンとデプロイレイヤーが既に確立されていることが前提です。実装の詳細は、このアーティファクトの範囲外です。 これらのコンポーネントは CloudFormation テンプレートによって設定および設定されるため、次のステップは説明的で大まかに示されています。セットアップと設定を完了するために必要な AWS スキルがあることを前提としています。 *1. Amazon Cognito ユーザープールを設定して構成する* にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/cognito/]() で Amazon Cognito コンソールを開きます。アプリケーション統合、ホストされた UI、および必要なアクセス許可を使用して、`CellRouterPool` という名前の Amazon Cognito ユーザープールを設定し構成します。 *2。セルルーターの API Gateway API を設定し構成する* API Gateway コンソール (「[https://console.aws.amazon.com/apigateway]()」) を開きます。Amazon Cognito ユーザープール `CellRouterPool` と統合された Amazon Cognito オーソライザーを使用して、`CellRouter` という名前の API を設定し構成します。次の要素を実装します。 + `POST` メソッドを含む `CellRouter` API リソース + ステップ 5 で実装された Step Functions ワークフローとの統合 + Amazon Cognito オーソライザーによる認可 + 統合リクエストと応答マッピング + 必要なアクセス許可の割り当て *3. DynamoDB テーブルを作成する* [https://console.aws.amazon.com/dynamodb/]() で DynamoDB コンソールを開き、次の設定で `tbl_router` という名前の標準 DynamoDB テーブルを作成します。 + **パーティションキー** – `marketId` + **ソートキー** – `cellId` + **キャパシティモード** – プロビジョンド + **ポイントインタイムリカバリ (PITR)** – オフ **[インデックス]** タブで、`marketId-currentCapacity-index` というグローバルセカンダリインデックスを作成します。`Scaler` Lambda 関数は、インデックスを使用して、割り当てられたユーザーの数が最も少ないセルを効率的に検索します。 次の属性を使用してテーブル構造を作成します。 + `marketId` – Europe + `cellId` – cell-0002 + `currentCapacity` – 2 + `endPoint_1` – <最初のリージョンのエンドポイント> + `endPoint_2` – <2 番目のリージョンのエンドポイント> + `IsHealthy` – True + `maxCapacity` – 10 + `regionCode_1` ‒ `eu-north-1` + `regionCode_2` ‒ `eu-central-1` + `userIds` – *4. SQS キューを作成し設定する* [https://console.aws.amazon.com/sqs/]() で Amazon SQS コンソールを開き、**Amazon SQS キー**暗号化で設定された `CellProvisioning` という名前の標準 SQS キューを作成します。 *5。オーケストレーターを実装する* ルーターの `Orchestrator` として機能する Step Functions ワークフローを開発します。ワークフローは、セルルーター API を介して呼び出すことができます。ワークフローは、リソースパスに基づいて指定された Lambda 関数を実行します。Step Functions をセルルーター `CellRouter` の API Gateway API と統合し、Lambda 関数を呼び出すために必要なアクセス許可を設定します。 以下の図に、ワークフローを示しています。Choice ステートは Lambda 関数の 1 つを呼び出します。Lambda 関数が成功すると、ワークフローは終了します。Lambda 関数が失敗すると、Fail ステートが呼び出されます。 ![\[4 つの関数があり、Fail ステートで終了するワークフローの図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/fd2fbf9d-9ae4-4c27-bc32-cf117350137a/images/cfe8d029-6f30-49a1-aaad-cad503bdcbae.png) *6。Lambda 関数を実装する* `Dispatcher`、`Mapper`、`Scaler`、および `Validator` 関数を実装します。デモンストレーションで各関数を設定して構成するときは、関数のロールを定義し、DynamoDB テーブル `tbl_router` で必要な操作を実行するために必要なアクセス許可を割り当てます。さらに、各関数をワークフロー `Orchestrator` に統合します。 *ディスパッチャー関数* `Dispatcher` 関数は、新しい登録ユーザーごとに 1 つの静的セルを識別して割り当てます。新しいユーザーがグローバルアプリケーションに登録すると、リクエストは `Dispatcher` 関数に送信されます。関数は、次のような事前定義された評価基準を使用してリクエストを処理します。 1. **リージョン** – ユーザーが配置されているマーケットのセルを選択します。たとえば、ユーザーが欧州からグローバルアプリケーションにアクセスする場合は、欧州 AWS リージョン で が使用するセルを選択します。 1. **近接またはレイテンシー** – ユーザーに最も近いセルを選択します。例えば、ユーザーがオランダからアプリケーションにアクセスする場合、関数はフランクフルトとアイルランドを使用するセルを考慮します。どのセルが最も近いかの決定は、ユーザーのロケーションとセルリージョン間のレイテンシーなどのメトリクスに基づきます。このパターン例では、情報はプロビジョンとデプロイレイヤーから静的に供給されます。 1. **正常性** – `Dispatcher` 関数は、指定されたセルの状態 (正常 = true または false) に基づいて、選択したセルが正常かどうかを確認します。 1. **容量** – ユーザーディストリビューションは*セル内の最小ユーザー数*ロジックに基づいているため、ユーザーはユーザー数が最も少ないセルに割り当てられます。 **注記** これらの基準は、このパターン例の説明のみを目的に示されています。実際のセルルーター実装では、より細かいユースケースに基づく基準を定義できます。 `Orchestrator` はディスパッチャー関数を呼び出して、ユーザーをセルに割り当てます。このデモ関数では、マーケット値は `europe` として定義された静的パラメータです。 この `Dispatcher` 関数は、セルが既にユーザーに割り当てられているかどうかを評価します。セルが既に割り当てられている場合、`Dispatcher` 関数はセルのエンドポイントを返します。ユーザーにセルが割り当てられていない場合、関数はユーザー数が最も少ないセルを検索してユーザーに割り当て、エンドポイントを返します。セル検索クエリの効率は、グローバルセカンダリインデックスを使用して最適化されます。 *マッパー関数* この `Mapper` 関数は、データベース内のユーザーとセル間のマッピングの保存とメンテナンスを監督します。登録された各ユーザーには、単一のセルが割り当てられます。各セルには、AWS リージョンごとに 1 つずつ、2 つの異なる URL があります。API Gateway でホストされている API エンドポイントとして機能するこれらの URL は、グローバルアプリケーションへのインバウンドポイントとして機能します。 `Mapper` 関数は、クライアントアプリケーションからリクエストを受信すると、DynamoDB テーブル `tbl_router` でクエリを実行して、指定された E メール ID に関連付けられているユーザーとセル間のマッピングを取得します。割り当てられたセルが見つかった場合、`Mapper` 関数はセルの 2 つの URL を迅速に提供します。また、この `Mapper` 関数はセル URL への変更をアクティブにモニタリングし、ユーザー設定への通知や更新を開始します。 *スケーラー関数* `Scaler` 関数はセルの残容量を管理します。`Scaler` 関数は、新しいユーザー登録リクエストごとに、`Dispatcher` 関数がユーザーに割り当てたセルの使用可能な容量を評価します。セルが指定された評価基準に従って決められた制限に達した場合、関数は Amazon SQS キューを介してプロビジョンとデプロイレイヤーへのリクエストを開始し、新しいセルのプロビジョニングとデプロイを要求します。セルのスケーリングは、次のような一連の評価基準に基づいて実行できます。 1. **最大ユーザー数** – 各セルの最大ユーザー数は 500 です。 1. **バッファ容量** – 各セルのバッファ容量は 20% です。つまり、各セルはいつでも 400 のユーザーに割り当てることができます。残りの 20% のバッファ容量は、将来のユースケースや予期しないシナリオ (セルの作成やサービスのプロビジョニングが利用できない場合など) の処理用に予約されています。 1. **セルの作成** – 既存のセルが容量の 70% に達するとすぐに、追加のセルを作成するリクエストがトリガーされます。 **注記** これらの基準は、このパターン例の説明のみを目的に示されています。実際のセルルーター実装では、より細かいユースケースに基づく基準を定義できます。 デモンストレーションの `Scaler` コードは、`Dispatcher` が新しく登録されたユーザーにセルを正常に割り当てた後、`Orchestrator` によって実行されます。`Scaler` は `Dispatcher` からセル ID を受け取ると、事前定義された評価基準に基づいて、指定されたセルに追加のユーザーを受け入れるのに十分な容量があるかどうかを評価します。セルの容量が不十分な場合、`Scaler` 関数は Amazon SQS サービスにメッセージをディスパッチします。このメッセージは、プロビジョンとデプロイレイヤー内のサービスによって取得され、新しいセルのプロビジョニングが開始されます。 **バリデーター関数** `Validator` 関数は、セルアクセスに関連する問題を特定して解決します。ユーザーがグローバルアプリケーションにサインインすると、アプリケーションはユーザープロファイル設定からセルの URL を取得し、ユーザーリクエストをセル内の 2 つの割り当てられたリージョンのいずれかにルーティングします。URL にアクセスできない場合、アプリケーションは検証 URL リクエストをセルルーターにディスパッチできます。セルルーター `Orchestrator` は `Validator` を呼び出します。`Validator` は検証プロセスを開始します。検証には、次のようなチェックが含まれる可能性があります。 + リクエスト内のセル URL をデータベースに保存されている URL と相互参照して、潜在的な更新を特定して処理する + ディープヘルスチェックを実行する (セルのエンドポイントへの `HTTP GET` リクエストなど) 結論として、`Validator` 関数はクライアントアプリケーションリクエストに応答を配信し、検証ステータスを必要な修復ステップとともに提供します。 `Validator` は、ユーザーエクスペリエンスを向上させるように設計されています。インシデントによりセルが一時的に使用できなくなり、特定のユーザーがグローバルアプリケーションにアクセスできないシナリオを考えてみましょう。`Validator` 関数では、一般的なエラーを提示する代わりに、指示的な修復ステップを提供できます。これらのステップには以下のようなアクションが含まれます。 + インシデントについてユーザーに通知する。 + サービスが利用できるようになるまでのおおよその待機時間を提示する。 + 追加情報を取得するためのサポート連絡先番号を提示する。 `Validator` 関数のデモコードは、リクエスト内のユーザーが指定したセル URL と `tbl_router` テーブルに保存されているレコードが一致することを確認します。この `Validator` 関数は、セルが正常かどうかも確認します。 # VPC エンドポイントを介して Amazon S3 バケットへのプライベートアクセスを設定する *Martin Maritsch、Nicolas Jacob Baer、Gabriel Rodriguez Garcia、Shukhrat Khodjaev、Mohan Gowda Purushothama、Joaquin Rinaudo、Amazon Web Services* ## 概要 Amazon Simple Storage Service (Amazon S3) では、署名付き URL を使用して、任意のサイズのファイルをターゲットユーザーと共有できます。デフォルトでは、Amazon S3 の署名付き URL には有効期限内にインターネットからアクセスできるため、使いやすくなっています。ただし、企業環境では、多くの場合、Amazon S3 の署名付き URL へのアクセスをプライベートネットワークのみに制限する必要があります。 このパターンは、インターネットトラバーサルなしでプライベートネットワークからの署名付き URL を使用して S3 オブジェクトを安全に操作するためのサーバーレスソリューションを示しています。このアーキテクチャでは、ユーザーは内部ドメイン名を介して Application Load Balancer にアクセスします。トラフィックは、Amazon API Gateway と S3 バケットの仮想プライベートクラウド (VPC) エンドポイントを介して内部でルーティングされます。この AWS Lambda 関数は、プライベート VPC エンドポイントを介してファイルをダウンロードするための署名URLs を生成し、機密データのセキュリティとプライバシーを強化するのに役立ちます。 ## 前提条件と制限 **前提条件** + AWS アカウント 企業ネットワークに接続された にデプロイされたサブネットを含む VPC ( 経由など AWS Direct Connect)。 **制限事項** + S3 バケットにはドメインと同じ名前を付ける必要があるため、[Amazon S3 バケットの命名規則](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)を確認することをお勧めします。 + このサンプルアーキテクチャには、デプロイされたインフラストラクチャのモニタリング機能は含まれていません。ユースケースでモニタリングが必要な場合は、[AWS モニタリングサービス](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/welcome.html)の追加を検討してください。 + このサンプルアーキテクチャには、入力検証は含まれません。ユースケースで入力検証とセキュリティの強化が必要な場合は、 [を使用して API AWS WAF を保護することを検討してください](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)。 + このサンプルアーキテクチャには、Application Load Balancer によるアクセスログ記録は含まれません。ユースケースでアクセスのログ記録が必要な場合は、[ロードバランサーのアクセスログ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)を有効にすることを検討してください。 バージョン + Python バージョン 3.11 以降 + Terraform バージョン 1.6 以降 ## アーキテクチャ **ターゲットテクノロジースタック** ターゲットテクノロジースタックでは、次の AWS サービスが使用されます。 + **Amazon S3** は、ファイルのアップロード、ダウンロード、および保存を安全に行うために使用されるコアストレージサービスです。 + **Amazon API Gateway** は、S3 バケットを操作するためのリソースとエンドポイントを公開します。このサービスは、データをダウンロードまたはアップロードするための署名付き URL を生成する役割を果たします。 + **AWS Lambda** は、Amazon S3 からファイルをダウンロードするための署名付き URL を生成します。API ゲートウェイは Lambda 関数を呼び出します。 + **Amazon VPC** は VPC 内にリソースをデプロイして、ネットワークを隔離します。VPC には、トラフィックフローを制御するためのサブネットとルーティングテーブルが含まれています。 + **Application Load Balancer** は、受信トラフィックを API ゲートウェイまたは S3 バケットの VPC エンドポイントにルーティングします。これにより、企業ネットワークのユーザーは内部でリソースにアクセスできます。 + **Amazon S3 の VPC エンドポイント**を使用すると、パブリックインターネットを経由することなく、VPC 内のリソースと Amazon S3 間の直接のプライベート通信が可能になります。 + **AWS Identity and Access Management (IAM)** は、 AWS リソースへのアクセスを制御します。アクセス許可は、API およびその他のサービスとの安全なやり取りを確保するために設定されます。 **ターゲットアーキテクチャ** ![\[VPC エンドポイントを介した S3 バケットへのプライベートアクセスの設定\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/683ca6a1-789c-4444-bcbf-e4e80d253df3/images/1ca7ee17-d346-4eb9-bf61-ccf42528a401.png) この図表は、以下を示すものです: 1. 企業ネットワークのユーザーは、内部ドメイン名を使用して Application Load Balancer にアクセスできます。企業ネットワークと のイントラネットサブネットの間に接続が存在することを前提としています AWS アカウント ( Direct Connect 接続経由など）。 1. Application Load Balancer は、受信トラフィックを API ゲートウェイにルーティングして、Amazon S3 または S3 バケットの VPC エンドポイントにデータをダウンロードまたはアップロードするための署名付き URL を生成します。どちらのシナリオでも、リクエストは内部でルーティングされるため、インターネットを経由する必要はありません。 1. API ゲートウェイは、S3 バケットを操作するためのリソースとエンドポイントを公開します。この例では、S3 バケットからファイルをダウンロードするためのエンドポイントを提供しますが、アップロード機能を提供するために拡張することもできます。 1. Lambda 関数は、パブリック Amazon S3 ドメインの代わりに Application Load Balancer のドメイン名を使用して Amazon S3 からファイルをダウンロードするための署名付き URL を生成します。 1. ユーザーは署名付き URL を受け取り、それと Application Load Balancer を使用して Amazon S3 からファイルをダウンロードします。ロードバランサーには、API を意図していないトラフィックを S3 バケットの VPC エンドポイントに送信するデフォルトルートが含まれています。 1. VPC エンドポイントは、カスタムドメイン名を使用して署名付き URL を S3 バケットにルーティングします。S3 バケットは、ドメインと同じ名前にする必要があります。 **自動化とスケール** このパターンでは、Terraform を使用してコードリポジトリから AWS アカウントにインフラストラクチャをデプロイします。 ## ツール **ツール** + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。 + 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りするのに役立つオープンソースツールです。 **コードリポジトリ** このパターンのコードは、[https://github.com/aws-samples/private-s3-vpce](https://github.com/aws-samples/private-s3-vpce) の GitHub リポジトリで入手できます。 ## ベストプラクティス このパターンのサンプルアーキテクチャでは、[IAM アクセス許可](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)を使用して API へのアクセスを制御します。有効な IAM 認証情報を持つユーザーは誰でも API を呼び出すことができます。より複雑な認可モデルが必要なユースケースにおいては、[別のアクセスコントロールメカニズムの使用](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)をご検討ください。 ## エピック ### ソリューションを にデプロイする AWS アカウント | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS 認証情報を取得します。 | AWS 認証情報とアカウントへのアクセスを確認します。手順については、 AWS CLI ドキュメントの[「設定と認証情報ファイルの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)」を参照してください。 | AWS DevOps、AWS 全般 | | リポジトリのクローン作成 | このパターンで提供されている GitHub リポジトリのクローンを作成します。
git clone https://github.com/aws-samples/private-s3-vpce
| AWS DevOps、AWS 全般 | | 変数を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.html) | AWS DevOps、AWS 全般 | | ソリューションをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.html) | AWS DevOps、AWS 全般 | ### ソリューションをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストファイルを作成します。 | Amazon S3 にファイルをアップロードして、ファイルのダウンロードのテストシナリオを作成します。[Amazon S3 コンソール](https://console.aws.amazon.com/s3/)または次の AWS CLI コマンドを使用できます。
aws s3 cp /path/to/testfile s3://your-bucket-name/testfile
| AWS DevOps、AWS 全般 | | 署名付き URL 機能をテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.html) | AWS DevOps、AWS 全般 | | クリーンアップ | 不要になったリソースは必ず削除してください。
terraform destroy
| AWS DevOps、AWS 全般 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 番号記号 (\$1) などの特殊文字を含む S3 オブジェクトキー名により URL パラメータが破損し、エラーが発生します。 | URL パラメータを適切にエンコードし、S3 オブジェクトキー名が [Amazon S3 ガイドライン](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html)に従っていることを確認します。 | ## 関連リソース Amazon S3: + [署名付き URLsを使用したオブジェクトの共有](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html) + [バケットポリシーを使用した VPC エンドポイントからのアクセスの制御](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html) Amazon API Gateway: + [API Gateway のプライベート APIs に VPC エンドポイントポリシーを使用する](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-vpc-endpoint-policies.html) Application Load Balancer: + [ALB、S3、および PrivateLink を使用した内部 HTTPS 静的ウェブサイトのホスティング](https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/) (AWS ブログ記事) # Amazon Bedrock AWS Step Functions を使用して の状態をトラブルシューティングする *Aniket Kurzadkar、Sangam Kushwaha (Amazon Web Services)* ## 概要 AWS Step Functions エラー処理機能は、[ワークフロー](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html)の状態中に発生するエラーを確認するのに役立ちますが、それでもエラーの根本原因を見つけてデバッグするのは難しい場合があります。このパターンでは、この課題に対処し、Amazon Bedrock が Step Functions でステートの実行中に発生するエラーの解決にどのように役立つかを示します。 Step Functions はワークフローオーケストレーションを実現するため、開発者はプロセスを簡単に自動化できます。また、Step Functions にはエラー処理機能も用意されており、次のような利点があります。 + 開発者は、問題が発生しても完全には失敗しない、より回復力の高いアプリケーションを作成できます。 + ワークフローには、さまざまなタイプのエラーを異なる方法で処理する条件付きロジックを含めることができます。 + システムは、エクスポネンシャルバックオフを使用して、失敗した操作を自動的に再試行できます。 + エラーシナリオに対して代替の実行パスを定義できるため、ワークフローを適応させて処理を続行できます。 Step Functions ワークフローでエラーが発生した場合、このパターンでは、Step Functions でサポートされている Claude 3 などの基盤モデル (FM) にエラーメッセージとコンテキストを送信する方法を示します。FM はエラーを分析し、分類し、潜在的な修復手順を提案できます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + [AWS Step Functions とワークフロー](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html)の基本的な理解 + Amazon Bedrock [API 接続](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started-api.html) **制限事項** + このパターンのアプローチは、さまざまな AWS のサービスに使用できます。ただし、結果は、Amazon Bedrock によって評価 AWS Lambda される によって作成されたプロンプトによって異なる場合があります。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについて確認するには、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照し、サービスのリンクを選択してください。 ## アーキテクチャ 次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。 ![\[Step Functions、Amazon Bedrock、Amazon SNS を使用したエラー処理と通知のワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/78f86c74-c9de-4562-adcc-105b87a77a54/images/d8eda499-ea1d-45e5-8a36-e04a44ad5c4b.png) この図は、Step Functions ステートマシンでのエラー処理と通知の自動ワークフローを示しています。 1. 開発者がステートマシンの実行を開始します。 1. Step Functions ステートマシンが状態の処理を開始します。この場合、次の 2 通りの結果が想定されます。 + (a) すべてのステートが正常に実行されると、ワークフローは Amazon SNS に直接進み、E メールで成功通知が送信されます。 + (b) いずれかのステートが失敗すると、ワークフローはエラー処理の Lambda 関数に移動します。 1. エラーが発生した場合、次の処理が行われます。 + (a) Lambda 関数 (エラーハンドラー) がトリガーされます。Lambda 関数は、Step Functions ステートマシンから渡されたイベントデータからエラーメッセージを抽出します。次に、Lambda 関数はこのエラーメッセージに基づいてプロンプトを準備し、Amazon Bedrock に送信します。プロンプトは、発生した特定のエラーに関連する解決策と提案をリクエストします。 + (b) 生成 AI モデルをホストする Amazon Bedrock が、入力プロンプトを処理します (このパターンでは、Amazon Bedrock がサポートする多くの FM の 1 つである Anthropic Claude 3 基盤モデル (FM) を使用します)。AI モデルがエラーコンテキストを分析します。その後、モデルは、エラー発生の原因説明、可能性のある解決策、今後同じ間違いを起こさないようにするための提案を含むレスポンスを生成します。 Amazon Bedrock が、AI によって生成されたレスポンスを Lambda 関数に返します。Lambda 関数がレスポンスを処理し、フォーマットや主要な情報の抽出を行います。その後、Lambda 関数はステートマシンの出力にレスポンスを送信します。 1. エラー処理または実行が正常に完了すると、ワークフローは Amazon SNS をトリガーして E メールで通知を送信し、終了します。 ## ツール **AWS のサービス** + [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) は、主要な AI スタートアップや Amazon が提供する高パフォーマンスな基盤モデル (FM) を、統合 API を通じて利用できるようにするフルマネージド型サービスです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数やその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。 ## ベストプラクティス + Amazon Bedrock はトレーニングされたデータから学習する生成 AI モデルであり、そのデータを使用してコンテキストのトレーニングと生成も行います。ベストプラクティスとして、データ漏洩の問題につながる恐れのある個人情報は隠します。 + 生成 AI は有益なインサイトを提供できますが、特に本番環境において、重大なエラー処理の決定には人間による監視が必要です。 ## エピック ### ワークフロー用のステートマシンを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ステートマシンの作成。 | ワークフローに適したステートマシンを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | AWS DevOps | ### Lambda 関数を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数を作成する。 | Lambda 関数をインポートするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | AWS DevOps | | Lambda コードで必要なロジックを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html)
client = boto3.client(
        service_name="bedrock-runtime", region_name="selected-region"
    )

    # Invoke Claude 3 with the text prompt
    model_id = "your-model-id" # Select your Model ID, Based on the Model Id, Change the body format

    try:
        response = client.invoke_model(
            modelId=model_id,
            body=json.dumps(
                {
                    "anthropic_version": "bedrock-2023-05-31",
                    "max_tokens": 1024,
                    "messages": [
                        {
                            "role": "user",
                            "content": [{"type": "text", "text": prompt}],
                        }
                    ],
                }
            ),
        )
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | AWS DevOps | ### Step Functions を Lambda と統合する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Step Functions でエラーを処理するように Lambda を設定します。 | ワークフローを中断せずにエラーを処理するように Step Functions を設定するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Lambda が Amazon Bedrock API にアクセスできない (実行する権限がない) | このエラーは、Lambda ロールに Amazon Bedrock API へのアクセス許可がない場合に発生します。この問題を解決するには、Lambda ロールに `AmazonBedrockFullAccess` ポリシーを追加します。詳細については、*AWS マネージドポリシーリファレンスガイド*の「[AmazonBedrockFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonBedrockFullAccess.html)」を参照してください。 | | Lambda タイムアウトエラー | プロンプトによっては、レスポンスを生成して返すまでに 30 秒以上かかる場合があります。この問題を解決するには、設定時間を長くします。詳細については、*AWS Lambda デベロッパーガイド*の「[Lambda 関数のタイムアウトを設定する](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonBedrockFullAccess.html)」を参照してください。 | ## 関連リソース + [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) + [Amazon Bedrock API access](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started-api.html) + [最初の Lambda 関数を作成する](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) + [Step Functions を使用したワークフローの開発](https://docs.aws.amazon.com/step-functions/latest/dg/developing-workflows.html#development-run-debug) + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) # その他のパターン **Topics** + [Athena による Amazon DynamoDB テーブルへのアクセス、クエリ、結合](access-query-and-join-amazon-dynamodb-tables-using-athena.md) + [GitHub Actions を使用して Python AWS CDK アプリケーションの Amazon CodeGuru レビューを自動化する](automate-amazon-codeguru-reviews-for-aws-cdk-python-applications.md) + [AWS リソース評価を自動化する](automate-aws-resource-assessment.md) + [AWS SAM を使用してネストされたアプリケーションのデプロイを自動化](automate-deployment-of-nested-applications-using-aws-sam.md) + [マルチリポジトリ設定で AWS Supply Chain データレイクのデプロイを自動化する](automate-the-deployment-of-aws-supply-chain-data-lakes.md) + [間の Amazon RDS インスタンスのレプリケーションを自動化する AWS アカウント](automate-the-replication-of-amazon-rds-instances-across-aws-accounts.md) + [を使用したリージョン間ピアリングの設定を自動化する AWS Transit Gateway](automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.md) + [DynamoDB TTL を使用して項目を Amazon S3 に自動的にアーカイブする](automatically-archive-items-to-amazon-s3-using-dynamodb-ttl.md) + [CodeCommit 内のモノリポジトリの変更を自動的に検出し、さまざまな CodePipeline パイプラインを開始する](automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.md) + [Amazon OpenSearch Service におけるマルチテナントサーバーレスアーキテクチャの構築](build-a-multi-tenant-serverless-architecture-in-amazon-opensearch-service.md) + [AWS クラウドで高度なメインフレームファイルビューアを構築](build-an-advanced-mainframe-file-viewer-in-the-aws-cloud.md) + [AWS のサービスを使用してバリューアットリスク (VaR) を計算](calculate-value-at-risk-var-by-using-aws-services.md) + [AWS Service Catalog 製品を異なる AWS アカウントと AWS リージョンにコピー](copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions.md) + [Java および Python プロジェクト用の動的 CI パイプラインを自動的に作成](create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.md) + [CQRS とイベントソーシングを使用してモノリスをマイクロサービスに分解する](decompose-monoliths-into-microservices-by-using-cqrs-and-event-sourcing.md) + [React ベースのシングルページアプリケーションを Amazon S3 と CloudFront にデプロイする](deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.md) + [プライベートエンドポイントと Application Load Balancer を使用して、Amazon API Gateway API を内部 Web サイトにデプロイする](deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.md) + [インフラストラクチャをコードとして使用して、AWS クラウドにサーバーレスデータレイクをデプロイして管理する](deploy-and-manage-a-serverless-data-lake-on-the-aws-cloud-by-using-infrastructure-as-code.md) + [Terraform と Amazon Bedrock を使用して AWS に RAG ユースケースをデプロイする](deploy-rag-use-case-on-aws.md) + [Amazon Bedrock エージェントとナレッジベースを使用して、完全に自動化したチャットベースのアシスタントを開発する](develop-a-fully-automated-chat-based-assistant-by-using-amazon-bedrock-agents-and-knowledge-bases.md) + [RAG と ReAct プロンプトを使用して高度な生成 AI チャットベースのアシスタントを開発する](develop-advanced-generative-ai-chat-based-assistants-by-using-rag-and-react-prompting.md) + [Step Functions を使用して IAM アクセスアナライザーで IAM ポリシーを動的に生成](dynamically-generate-an-iam-policy-with-iam-access-analyzer-by-using-step-functions.md) + [Amazon Cognito と IaC オートメーションを使用して Amazon Quick Sight ビジュアルコンポーネントをウェブアプリケーションに埋め込む](embed-quick-sight-visual-components-into-web-apps-cognito-iac.md) + [Amazon S3 へのAmazon EMR ロギングが有効になっていることを確認する](ensure-amazon-emr-logging-to-amazon-s3-is-enabled-at-launch.md) + [DynamoDB テーブルのコストをオンデマンドで見積る](estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.md) + [Amazon Personalize を使用して、パーソナライズされ再ランク付けされたレコメンデーションを生成します](generate-personalized-and-re-ranked-recommendations-using-amazon-personalize.md) + [AWS Glue ジョブと Python を使用してテストデータを生成します](generate-test-data-using-an-aws-glue-job-and-python.md) + [SQL Server から PostgreSQL に移行する際に、PII データに SHA1 ハッシュを実装する](implement-sha1-hashing-for-pii-data-when-migrating-from-sql-server-to-postgresql.md) + [AWS Step Functions を使用して、サーバーレス Saga パターンを実装する](implement-the-serverless-saga-pattern-by-using-aws-step-functions.md) + [AWS CDK を使用して複数の AWS リージョン、アカウント、OU にわたって Amazon DevOps Guru を有効にすることで、運用パフォーマンスを向上させます。](improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.md) + [Step Functions と Lambda プロキシ関数を使用して AWS アカウント間で CodeBuild プロジェクトを起動する](launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.md) + [AWS Glue を使用して Apache Cassandra ワークロードを Amazon Keyspaces に移行する](migrate-apache-cassandra-workloads-to-amazon-keyspaces-by-using-aws-glue.md) + [複数の で共有 Amazon マシンイメージの使用をモニタリングする AWS アカウント](monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.md) + [AWS CDK および GitHub Actions ワークフローを使用してマルチアカウントサーバーレスデプロイを最適化する](optimize-multi-account-serverless-deployments.md) + [を使用して、検証、変換、パーティショニングで ETL パイプラインをオーケストレーションする AWS Step Functions](orchestrate-an-etl-pipeline-with-validation-transformation-and-partitioning-using-aws-step-functions.md) + [Amazon Athena を使用して SQL で Amazon DynamoDB テーブルをクエリする](query-amazon-dynamodb-tables-sql-amazon-athena.md) + [Amazon Cognito にカスタム属性を送信し、トークンに挿入する](send-custom-attributes-cognito.md) + [Amazon CloudFront を使用して Amazon S3 バケットの静的なコンテンツを VPC 経由で配信する](serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.md) + [自動ワークフローを使用して Amazon Lex ボットの開発とデプロイを合理化する](streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.md) + [AWS Lambda を使用して六角形アーキテクチャで Python プロジェクトを構築する](structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.md) + [自然言語を OpenSearch と Elasticsearch のクエリ向けにクエリ DSL に変換する](translate-natural-language-query-dsl-opensearch-elasticsearch.md) + [アカウント間で Amazon Redshift クラスターから Amazon S3 にデータをアンロードする](unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.md) + [AWS Fargate WaitCondition フック構造を使用してリソースの依存関係とタスク実行を調整する](use-the-aws-fargate-waitcondition-hook-construct.md) + [Amazon Bedrock エージェントを使用してテキストベースのプロンプトで Amazon EKS でのアクセスエントリコントロールの作成を自動化する](using-amazon-bedrock-agents-to-automate-creation-of-access-entry-controls-in-amazon-eks.md) # ネットワーク **Topics** + [を使用したリージョン間ピアリングの設定を自動化する AWS Transit Gateway](automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.md) + [AWS Transit Gateway を使用してネットワーク接続を一元化](centralize-network-connectivity-using-aws-transit-gateway.md) + [Application Load Balancer を使用して Oracle WebLogic 上の Oracle JD Edwards EnterpriseOne の HTTPS 暗号化を設定します](configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.md) + [プライベートネットワーク経由でアプリケーション移行サービスのデータプレーンをコントロールプレーンに接続](connect-to-application-migration-service-data-and-control-planes-over-a-private-network.md) + [AWS CloudFormation カスタムリソースと Amazon SNS を使用して Infoblox オブジェクトを作成します。](create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns.md) + [Terraform を使用して AWS で階層型のマルチリージョン IPAM アーキテクチャを作成する](multi-region-ipam-architecture.md) + [の Amazon CloudWatch アラートをカスタマイズする AWS Network Firewall](customize-amazon-cloudwatch-alerts-for-aws-network-firewall.md) + [Terraform を使用して リソースを AWS Wavelength ゾーンにデプロイする](deploy-resources-wavelength-zone-using-terraform.md) + [DNS レコードを Amazon Route 53 プライベートホストゾーンに一括で移行する](migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone.md) + [F5 から AWS のApplication Load Balancer に移行するときの HTTP ヘッダーを変更](modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws.md) + [複数の でインバウンドインターネットアクセスに関する Network Access Analyzer の検出結果のレポートを作成する AWS アカウント](create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.md) + [マルチアカウント AWS 環境でハイブリッドネットワークの DNS 解決を設定する](set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.md) + [ELB ロードバランサーに TLS 終了が必要であることを確認](verify-that-elb-load-balancers-require-tls-termination.md) + [Splunk を使用して AWS Network Firewall のログとメトリクスを表示する](view-aws-network-firewall-logs-and-metrics-by-using-splunk.md) + [その他のパターン](networking-more-patterns-pattern-list.md) # を使用したリージョン間ピアリングの設定を自動化する AWS Transit Gateway *Ram Kandaswamy (Amazon Web Services)* ## 概要 [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) は、中央ハブを介して仮想プライベートクラウド (VPCs) とオンプレミスネットワークを接続します。Transit Gateway トラフィックはパブリックインターネットを経由しないため、一般的なエクスプロイトや分散型サービス拒否 (DDoS) 攻撃などの脅威ベクトルが軽減されます。 2 つ以上の 間で通信する必要がある場合は AWS リージョン、リージョン間 Transit Gateway ピアリングを使用して、異なるリージョンの Transit Gateway 間でピアリング接続を確立できます。ただし、Transit Gateway とのリージョン間ピアリングを手動で設定すると、複雑で時間がかかる場合があります。このパターンは、Infrastructure as Code (IaC) を使用してピアリングをセットアップするためのガイダンスを提供します。このアプローチは、複数のリージョンを繰り返し設定する必要がある場合や、マルチリージョンの組織設定 AWS アカウント に使用することができます。 このパターンは、Amazon CloudWatch Logs の AWS Step Functions [ワークフロー](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html)、関数、 AWS Identity and Access Management (IAM) [ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)、[ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)を含む [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)スタックを設定します。 AWS Lambda [https://docs.aws.amazon.com/lambda/latest/dg/concepts-basics.html#gettingstarted-concepts-function](https://docs.aws.amazon.com/lambda/latest/dg/concepts-basics.html#gettingstarted-concepts-function)次に、Step Functions ワークフローを実行して、トランジットゲートウェイのリージョン間ピアリング接続を作成します。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + [Kiro](https://kiro.dev/#what-is-kiro) などのコード生成機能を持つ IDE。 + Amazon Simple Storage Service (Amazon S3) バケットとそのバケットにオブジェクトをアップロードするためのアクセス許可。 + リクエスト元のリージョンと受け入れ先のリージョンで作成されたトランジットゲートウェイ。 + リクエスト元のリージョンと受け入れ先のリージョンで作成された VPCs。VPCsを持つ `addToTransitGateway`キーをタグ付けします`true`。 + 要件に従って VPCs 用に設定された[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)。 + 要件に従って VPCs 用に設定された[ネットワークアクセスコントロールリスト (ACLs)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)。 **制限事項** + 一部の のみがリージョン間ピアリング AWS リージョン をサポートしています。リージョン間ピアリングをサポートするリージョンの完全なリストについては、[AWS Transit Gateway FAQs](https://aws.amazon.com/transit-gateway/faqs/)を参照してください。 ## アーキテクチャ このパターンで説明されているエージェント AI 開発アプローチには、次のステップが含まれます。 1. **自動化プロンプトを定義する** – Kiro は、ピアリング要件の詳細を示す自然言語プロンプトを受け取ります。 1. **自動化スクリプトの生成** – Kiro は、提供されたプロンプトに基づいて CloudFormation スクリプトと Lambda スクリプトを生成します。 1. **スタックをデプロイ**する – Kiro は CloudFormation を使用して必要なリソースをデプロイします。 1. **ピアリングの設定** – Kiro は Step Functions ワークフローを実行します。このワークフローは Lambda 関数を呼び出してピアリング接続を作成し、ルートテーブルを変更します。 次の図は、Step Functions ワークフローを示しています。 ![\[トランジットゲートウェイピアリング用の Lambda 関数を呼び出すための Step Function ワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b678bb87-c7b9-4f7b-b26e-eaac650e5d1b/images/2f235f47-5d68-492c-b954-7dc170939cae.png) ワークフローの主なステップは、次のとおりです。 1. Step Functions ワークフローは、Transit Gateway ピアリングの Lambda 関数を呼び出します。  1. ワークフローは 1 分間待機します。 1. ワークフローはピアリングステータスを取得し、条件ブロックに送信します。ブロックがルーピングを実行します。  1. 成功条件が満たされない場合、ワークフローはタイマーステージに移行するようにコーディングされます。  1. 成功条件が満たされた場合、Lambda 関数はルートテーブルを変更します。 1. Step Functions ワークフローは終了します。 ## ツール + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。  + [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用すると、すべてのシステム、アプリケーション、および からのログを一元化 AWS のサービス できるため、ログをモニタリングして安全にアーカイブできます。 + [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)[ (](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)[IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)[)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、リソースの使用を認証および認可されたユーザーを制御することで、 AWS リソースへのアクセスを安全に管理できます。 + [Kiro](https://kiro.dev/#what-is-kiro) は、スペック駆動型開発を通じて本番環境対応のアプリケーションを構築するのに役立つエージェント AI 開発ツールです。  + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数やその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。   ## エピック ### Lambda および Step Functions コードを生成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロンプトプレースホルダーに特定の詳細を入力する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html)または、ファイルをコンテキストにアタッチせずに、上記の変数を参照するインラインプロンプトとして追加することもできます。 | AWS 全般、ネットワーク管理者 | | ピアリングアタッチメントを作成する Lambda 関数を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html) | AWS 全般、ネットワーク管理者、プロンプトエンジニアリング | | ピアリングアタッチメントのステータスをポーリングする Lambda 関数を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html) | AWS 全般、ネットワーク管理者、プロンプトエンジニアリング | | 両方のリージョンに静的ルートを追加する Lambda 関数を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html) | AWS 全般、ネットワーク管理者 | | CloudFormation テンプレートを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html) | AWS DevOps、AWS 全般、プロンプトエンジニアリング | ### AWS リソースをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロンプトを使用して CloudFormation スタックをデプロイします。 | 次のプロンプトを入力します。
Using the outputs from Prompts 1-4, package and deploy the full stack. Steps:

1. For each of the three Python files from Prompts 1-3, create a zip named after the file (e.g. peer-transit-gateway.zip that contains peer-transit-gateway.py).
2. Upload all three zips to S3_BUCKET.
3. Deploy the CloudFormation template from Prompt 4 to ACTIVE_REGION with S3BucketName=S3_BUCKET and CAPABILITY_NAMED_IAM.
4. Initiate the Step Function from the deployed stack.

Zip file names must match the S3Key values in the template exactly.
| AWS DevOps、クラウド管理者、AWS 全般、プロンプトエンジニアリング | | デプロイを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html) | AWS 全般 | ## 関連リソース + [Step Functions でステートマシンの実行を開始する](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-state-machine-executions.html) + [Transit Gateway ピアリングアタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html) + [AWS リージョン を使用した 間の VPCs相互接続 AWS Transit Gateway](https://www.youtube.com/watch?v=cj1rQqLxXU8) (ビデオ) # AWS Transit Gateway を使用してネットワーク接続を一元化 *Mydhili Palagummi、Nikhil Marrapu (Amazon Web Services)* ## 概要 このパターンでは、AWS Transit Gateway を使用して、オンプレミスネットワークを AWS リージョン内の複数の AWS アカウントの仮想プライベートクラウド (VPC) に接続できる最も単純な構成を示しています。この設定を使用して、リージョン内の複数の VPC ネットワークとオンプレミスネットワークを接続するハイブリッドネットワークを確立できます。これは、トランジットゲートウェイと、オンプレミスネットワークへの仮想プライベートネットワーク (VPN) 接続を使用することで達成されます。 ## 前提条件と制限事項 **前提条件 ** + AWS Organizations の組織のメンバーアカウントとして管理される、ネットワークサービスをホストするためのアカウント + Classless Inter-Domain Routing (CIDR) ブロックが重複しない、複数の AWS アカウントの VPC **制限事項** このパターンでは、特定の VPC 間またはオンプレミスネットワーク間のトラフィックの分離をサポートしません。トランジットゲートウェイに接続されているすべてのネットワークは、相互にアクセスできるようになります。トラフィックを分離するには、トランジットゲートウェイでカスタムルートテーブルを使用する必要があります。このパターンでは、最も単純な構成である単一のデフォルトトランジットゲートウェイルートテーブルを使用して、VPC とオンプレミスネットワークのみを接続します。 ## アーキテクチャ **ターゲットテクノロジースタック** + AWS Transit Gateway + AWS Site-to-Site VPN + VPC + AWS Resource Access Manager (AWS RAM) **ターゲットアーキテクチャ** ![\[AWS Transit Gateway はオンプレミスネットワークを、リージョン内の複数の AWS アカウントにある VPC に接続します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e23f5faf-e75e-42a3-80e3-142516a2db4e/images/1ecf7e04-bbf8-4304-88c8-6aceb7271d1e.jpeg) ## ツール **AWS サービス** + 「[AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)」 は、AWS アカウント、組織単位、または AWS Organizations の組織全体でリソースを安全に共有するのに役立ちます。 + [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)は、仮想プライベートクラウド (VPC) とオンプレミスネットワークを接続する中央ハブです。 ## エピック ### ネットワークサービスアカウントでのトランジットゲートウェイの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | transit gateway を作成します。 | ネットワークサービスをホストする AWS アカウントで、ターゲット AWS リージョンにトランジットゲートウェイを作成します。手順については、「[トランジットゲートウェイの作成](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#create-tgw)」を参照してください。次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-network-connectivity-using-aws-transit-gateway.html) | ネットワーク管理者 | ### オンプレミスネットワークをトランジットゲートウェイに接続する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPN 接続のカスタマーゲートウェイデバイスを設定します。 | カスタマーゲートウェイデバイスは、トランジットゲートウェイとオンプレミスネットワーク間の、Site-to-Site VPN 接続のオンプレミス側に接続されています。詳細については、AWS Site-to-Site VPN ユーザーガイドの「[カスタマーゲートウェイデバイス](https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html)」を参照してください。適用されるオンプレミスの顧客デバイスを特定または起動し、そのパブリック IP アドレスを書き留めます。VPN の設定は、このエピックの後半で完了します。 | ネットワーク管理者 | | ネットワークサービスアカウントで、トランジットゲートウェイへの VPN アタッチメントを作成します。 | 接続をセットアップするには、トランジットゲートウェイの VPN アタッチメントを作成します。手順については、「[トランジットゲートウェイ VPN アタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpn-attachments.html)」を参照してください。 | ネットワーク管理者 | | オンプレミスネットワークのカスタマーゲートウェイデバイスに、VPN を設定します。 | トランジットゲートウェイに関連付けられているSite-to-Site VPN 接続の設定ファイルをダウンロードして、カスタマーゲートウェイデバイスの VPN セッティングを設定します。手順については、「[設定ファイルをダウンロード](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html#vpn-download-config)」を参照してください。 | ネットワーク管理者 | ### ネットワークサービスアカウントのトランジットゲートウェイを、他の AWS アカウントまたは組織と共有する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Organizations 管理アカウントで、共有をオンにします。 | トランジットゲートウェイを組織する、または特定の組織単位と共有するには、AWS Organizations で共有をオンにします。そうしないと、アカウントごとにトランジットゲートウェイを個別に共有する必要性がでてきます。手順については、「[AWS Organizations 内のリソース共有の有効化](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)」 を参照してください。 | AWS システム管理者 | | ネットワークサービスアカウントにトランジットゲートウェイリソースシェアを作成します。 | 組織の他の AWS アカウントの VPC がトランジットゲートウェイに接続できるようにするには、ネットワークサービスアカウントで AWS RAM コンソールを使用してトランジットゲートウェイリソースを共有します。手順については、「[リソース共有の作成](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-create)」 を参照してください。 | AWS システム管理者 | ### Transit Gateway に VPC を接続する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 個別のアカウントで VPC アタッチメントを作成します。 | トランジットゲートウェイが共有されているアカウントで、トランジットゲートウェイ VPC アタッチメントを作成します。手順については、「[VPC へのトランジットゲートウェイアタッチメントの作成](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html#create-vpc-attachment)」を参照してください。 | ネットワーク管理者 | | VPC アタッチリクエストを受け入れます。 | ネットワークサービスアカウントで、トランジットゲートウェイの VPC アタッチメントリクエストを受け入れます。手順については、「[共有アタッチメントの承認](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#tgw-accept-shared-attachment)」 を参照してください。 | ネットワーク管理者 | ### ルーティングを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 個々のアカウント VPC にルートを設定します。 | 個々のアカウント VPC に、Transit Gateway をターゲットとして使用して、オンプレミスのネットワークと他の VPC ネットワークへのルートを追加します。手順については、「[ルートテーブルからのルートの追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes)」 を参照してください。 | ネットワーク管理者 | | トランジットゲートウェイのルートテーブル内のルート。 | VPC と VPN 接続からのルートは伝達され、トランジットゲートウェイのデフォルトルートテーブルに表示されるはずです。必要に応じて、トランジットゲートウェイのデフォルトルートテーブルに静的ルート (静的 VPN 接続のための静的ルートが一例) を作成します。手順については、「[静的ルートの作成](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html#tgw-create-static-route)」 を参照してください。 | ネットワーク管理者 | | セキュリティグループとネットワークをアクセスコントロールリスト (ACL)ルールに加えます。 | EC2 インスタンスと VPC 内のその他のリソースについては、セキュリティグループルールルールとネットワーク ACL ルールが 、VPC とオンプレミスネットワーク間のトラフィックを許可していることを確認します。手順については、「[セキュリティグループを使用してリソースへのトラフィックを制御](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules)」 と「[ACL にルールを追加または削除](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules)」 を参照してください。 | ネットワーク管理者 | ### 接続テスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPC 間の接続をテストします。 | ネットワーク ACL とセキュリティグループが、インターネット制御メッセージプロトコル (ICMP) トラフィックを許可することを確認し、次にVPC 内のインスタンスから、同じくトランジットゲートウェイに接続されている別の VPCへのネットワーク接続を確認します。 | ネットワーク管理者 | | VPC とオンプレミスネットワーク間の接続をテストします。 | ネットワーク ACL ルール、セキュリティグループルール、およびファイアウォールが ICMP トラフィックを許可することを確認し、オンプレミスネットワークと VPC の EC2 インスタンス間の接続を確認します。VPNを `UP` ステータスに接続させるには、まずオンプレミスネットワークからネットワーク通信を開始する必要があります。 | ネットワーク管理者 | ## 関連リソース + [スケーラブルでセキュアなマルチ VPC の AWS ネットワークインフラストラクチャを構築する](https://d1.awsstatic.com/whitepapers/building-a-scalable-and-secure-multi-vpc-aws-network-infrastructure.pdf) (AWS ホワイトペーパー） + 「[共有リソースの使用](https://docs.aws.amazon.com/ram/latest/userguide/working-with.html)」 (AWS RAM ドキュメント) + 「[トランジットゲートウェイの操作](https://docs.aws.amazon.com/vpc/latest/tgw/working-with-transit-gateways.html)」 (AWS Transit Gateway ドキュメント) # Application Load Balancer を使用して Oracle WebLogic 上の Oracle JD Edwards EnterpriseOne の HTTPS 暗号化を設定します *Amazon Web Services、Thanigaivel Thirumalai* ## 概要 このパターンは、Oracle WebLogic ワークロード上の Oracle JD Edwards EnterpriseOne で SSL オフロード用に HTTPS 暗号化を設定する方法を説明しています。この方法では、ユーザーのブラウザとロードバランサー間のトラフィックを暗号化して、EnterpriseOne サーバーにかかる暗号化の負担を軽減します。 多くのユーザーは、「[AWS Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)」を使用して EnterpriseOne JAVA 仮想マシン (JVM) 階層を水平方向にスケーリングしています。ロードバランサーは、クライアントの単一窓口として機能し、複数の JVM に受信トラフィックを分散する。オプションで、ロードバランサーはトラフィックを複数のアベイラビリティーゾーンに分散し、EnterpriseOne の可用性を高めることができます。 このパターンで説明するプロセスでは、ロードバランサーと EnterpriseOne JVM 間のトラフィックを暗号化する代わりに、ブラウザとロードバランサー間の暗号化を設定します。このアプローチは *SSL オフロード*と呼ばれます。SSL 復号化プロセスを EnterpriseOne ウェブサーバーまたはアプリケーションサーバーからApplication Load Balancer にオフロードすることで、アプリケーション側の負担が軽減されます。ロードバランサーで SSL が終了すると、暗号化されていないトラフィックは AWS 上のアプリケーションにルーティングされます。 「[Oracle JD Edwards EnterpriseOne](https://www.oracle.com/applications/jd-edwards-enterpriseone/)」は、製品や物理的資産の製造、建設、流通、サービス、管理を行う組織向けのエンタープライズ・リソース・プランニング (ERP) ソリューションです。JD Edwards EnterpriseOne は、さまざまなハードウェア、オペレーティングシステム、データベースプラットフォームをサポートしています。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + AWS Identity and Access Management (IAM) ロール。AWS サービスコールを実行し、AWS リソースを管理します。 + SSL 証明書 **製品バージョン** + このパターンは Oracle WebLogic 12c でテストされていますが、他のバージョンを使用することもできます。 ## アーキテクチャ SSL オフロードを実行するには複数の方法があります。このパターンでは、次の図に示すように、Application Load Balancer と Oracle HTTP Server (OHS) を使用します。 ![\[ロードバランサーと OHS による SSL オフロード\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c62b976b-31e4-42ca-b7e8-13f7c9d9a187/images/2ae2d0eb-b9f3-41f8-ad86-9af3aade7072.png) 次の図は、JD Edwards EnterpriseOne、Application Load Balancer、および Java アプリケーションサーバー (JAS) JVM レイアウトを示しています。 ![\[エンタープライズワン、ロードバランサー、および JAS JVM レイアウト\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c62b976b-31e4-42ca-b7e8-13f7c9d9a187/images/72ea35b0-2907-48b3-aeb7-0c5d9a3b831b.png) ## ツール **AWS サービス** + 「[Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/)」は、複数のアベイラビリティゾーンにある Amazon Elastic Compute Cloud (Amazon EC2 インスタンス) などの複数のターゲットに、受信するアプリケーショントラフィックを分散する。 + 「[AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)」は、AWS ウェブサイトとアプリケーションを保護するパブリックおよびプライベート SSL/TLS X.509 証明書とキーの作成、保存、更新に役立ちます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。 ## ベストプラクティス + ACM のベストプラクティスについては、「[ACM のドキュメント](https://docs.aws.amazon.com/acm/latest/userguide/acm-bestpractices.html)」を参照してください。 ## エピック ### WebLogic と OHS をセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Oracle コンポーネントのインストールと設定。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | JDE CNC、WebLogic 管理者 | | WebLogic プラグインの名前を、ドメインレベルで有効にします。 | 負荷分散には WebLogic プラグインが必要です。プラグインを有効にするには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | JDE CNC、WebLogic 管理者 | | 設定ファイルを編集します。 | `mod_wl_ohs.conf` ファイルでは OHS から WebLogic へのプロキシリクエストを設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html)


WLSRequest On
SetHandler weblogic-handler
WebLogicHost localhost
WebLogicPort 8000
WLProxySSL On
WLProxySSLPassThrough On

| JDE CNC、WebLogic 管理者 | | エンタープライズマネージャーを使用して OHS を起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | JDE CNC、WebLogic 管理者 | ### Application Load Balancer の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ターゲットグループを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html)詳細な手順については、「[Elastic Load Balancing のドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html)」を参照してください。 | AWS 管理者 | | ロードバランサーの設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | AWS 管理者 | | Route 53 (DNS) レコードを追加します。 | (オプション) サブドメインに Amazon Route 53 DNS レコードを追加できます。このレコードは、Application Load Balancer を指します。手順については、「[Route 53 ドキュメント](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)」を参照してください。 | AWS 管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | HTTP サーバーは表示されません。 | Enterprise Manager コンソールの **[ターゲットナビゲーション]** リストに **[HTTP サーバー]** が表示されない場合は、以下の手順に従ってください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html)インスタンスが作成され、変更が有効になると、**[ターゲットナビゲーションパネル]** に HTTP サーバーが表示されます。 | ## 関連リソース **AWS ドキュメント** + [アプリケーション ロード バランサー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) + 「[パブリックホストゾーンの操作](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/AboutHZWorkingWith.html)」 + 「[プライベートホストゾーンの操作](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)」 Oracle ドキュメンテーション: + 「[Oracle WebLogic サーバープロキシープラグインの概要](https://docs.oracle.com/middleware/1221/webtier/develop-plugin/overview.htm#PLGWL391)」 + 「[インフラストラクチャー・インストーラを使用した WebLogic Server のインストール](https://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/12_2_1/02-01-004-InstallWLSInfrastructure/installweblogicinfrastructure.html)」 + 「[Oracle HTTP サーバーのインストールと設定](https://docs.oracle.com/middleware/1221/core/install-ohs/toc.htm)」 # プライベートネットワーク経由でアプリケーション移行サービスのデータプレーンをコントロールプレーンに接続 *Dipin Jain、Mike Kuznetsov (Amazon Web Services)* ## 概要 このパターンでは、インターフェイス VPC エンドポイントを使用して、プライベートで保護されたネットワーク上の AWS Application Migration Service データプレーンとコントロールプレーンに接続する方法について説明します。 Application Migration Service は、アプリケーションの移行を簡素化、迅速化、削減する高度に自動化されたlift-and-shift (リホスト) ソリューションです AWS。企業はこのサービスを使用することで、互換性の問題、パフォーマンスの中断、または長いカットオーバー期間に悩まされることなく、数多くの物理サーバー、仮想サーバー、またはクラウドサーバーをリホストできるようになります。アプリケーション移行サービスは、 AWS マネジメントコンソールから使用できます。これにより AWS のサービス、Amazon CloudWatch AWS CloudTrailや AWS Identity and Access Management (IAM) などの他の とシームレスに統合できます。 Site-to-Site VPN サービス、または Application Migration Service の VPC ピアリングを使用して AWS Direct Connect、プライベート接続を介して、ソースデータセンターからデータプレーン、つまり宛先 VPC 内のデータレプリケーションのステージングエリアとして機能するサブネットに接続できます。また、 を搭載した[インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)を使用して AWS PrivateLink 、プライベートネットワーク経由で Application Migration Service コントロールプレーンに接続することもできます。  ## 前提条件と制限事項 **前提条件** + **ステージングエリアサブネット** – Application Migration Service を設定する前に、ソースサーバーから AWS (つまり、データプレーン) にレプリケートされるデータのステージングエリアとして使用するサブネットを作成します。アプリケーション移行サービスコンソールに初めてアクセスする場合、[レプリケーション設定テンプレート](https://docs.aws.amazon.com/mgn/latest/ug/template-vs-server.html)でこのサブネットを指定する必要があります。レプリケーション設定テンプレートで、特定のソースサーバーのこのサブネットをオーバーライドできます。で既存のサブネットを使用できますが AWS アカウント、この目的のために新しい専用サブネットを作成することをお勧めします。 + **ネットワーク要件** – ステージングエリアサブネットで Application Migration Service によって起動されるレプリケーションサーバーは、 で Application Migration Service API エンドポイントにデータを送信できる必要があります。ここで`https://mgn..amazonaws.com/`、 AWS リージョン ``はレプリケート先の のコードです (例: `https://mgn.us-east-1.amazonaws.com`)。アプリケーション移行サービスソフトウェアをダウンロードするには、Amazon Simple Storage Service (Amazon S3) のサービス URL が必要となります。 + AWS レプリケーションエージェントのインストーラは、Application Migration Service AWS リージョン で使用している の Amazon Simple Storage Service (Amazon S3) バケット URL にアクセスできる必要があります。 + ステージングエリアのサブネットは、Amazon S3 にアクセスできる必要があります。 + AWS レプリケーションエージェントがインストールされているソースサーバーは、ステージングエリアサブネットのレプリケーションサーバーと の Application Migration Service API エンドポイントにデータを送信できる必要があります`https://mgn..amazonaws.com/`。 以下の表では、必要なポートを示しています。 | | | ソース | 目的地 | ポート | 詳細については、以下を参照 | | --- |--- |--- |--- | | ソースデータセンター | Amazon S3 サービスの URL | 443 (TCP) | [TCP ポート 443 を介した通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#TCP-443) | | ソースデータセンター | アプリケーション移行サービスのAWS リージョン固有のコンソールアドレス | 443 (TCP) | [TCP ポート 443 を介したソースサーバーとアプリケーション移行サービス間の通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#Source-Manager-TCP-443) | | ソースデータセンター | ステージングエリアのサブネット | 1500 (TCP) | [TCP ポート 1500 を介したソースサーバーとステージングエリアサブネット間の通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#Communication-TCP-1500) | | ステージングエリアのサブネット | アプリケーション移行サービスのAWS リージョン固有のコンソールアドレス | 443 (TCP) | [TCP ポート 443 を介したステージングエリアサブネットとアプリケーション移行サービス間の通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#Communication-TCP-443-Staging) | | ステージングエリアのサブネット | Amazon S3 サービスの URL | 443 (TCP) | [TCP ポート 443 を介した通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#TCP-443) | | ステージングエリアのサブネット | サブネットの Amazon Elastic Compute Cloud (Amazon EC2) エンドポイント AWS リージョン | 443 (TCP) | [TCP ポート 443 を介した通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#TCP-443) | **制限** Application Migration Service は現在、すべての AWS リージョン およびオペレーティングシステムで利用できるわけではありません。 + [サポート AWS リージョン](https://docs.aws.amazon.com/mgn/latest/ug/supported-regions.html) + [サポートされるオペレーティングシステム](https://docs.aws.amazon.com/mgn/latest/ug/Supported-Operating-Systems.html) ## アーキテクチャ 次の図表は、一般的な移行のネットワークアーキテクチャを示しています。このアーキテクチャの詳細については、「[アプリケーション移行サービスのドキュメント](https://docs.aws.amazon.com/mgn/latest/ug/Network-Settings-Video.html)」 と「[アプリケーション移行サービスのサービスのアーキテクチャおよびネットワークアーキテクチャのビデオ](https://youtu.be/ao8geVzmmRo)」 を参照してください。 ![\[一般的な移行のためのアプリケーション移行サービスのネットワークアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/21346c0f-0643-4f4f-b21f-fdfe24fc6a8f/images/546598b2-8026-4849-a441-eaa2bc2bf6bb.png) 次の詳細ビューは、Amazon S3 とアプリケーション移行サービスを接続するためのステージングエリア VPC のインターフェイス VPC エンドポイントの設定を示しています。 ![\[一般的な移行のアプリケーション移行サービスのネットワークアーキテクチャ — 詳細図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/21346c0f-0643-4f4f-b21f-fdfe24fc6a8f/images/bd0dfd42-4ab0-466f-b696-804dedcf4513.png) ## ツール + [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) は、 でのアプリケーションのリホストを簡素化、迅速化し、コストを削減します AWS。 + [インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)を使用すると、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を必要と AWS PrivateLink せずに、 を使用するサービスに接続できます。VPC のインスタンスは、サービスのリソースと通信するためにパブリック IP アドレスを必要としません。VPC と他のサービス間のトラフィックは、Amazon ネットワークを離れません。 ## エピック ### アプリケーション移行サービス、Amazon EC2、Amazon S3 のエンドポイントを作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーション移行サービスのインターフェイスエンドポイントを設定します。 | ソースデータセンターとステージングエリア VPC は、ターゲットステージングエリア VPC で作成したインターフェイスエンドポイントを介して、アプリケーション移行サービスコントロールプレーンにプライベートに接続します。エンドポイントを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)詳細については、[Amazon VPC ドキュメントの「インターフェイス VPC エンドポイント AWS のサービス を使用して にアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)」を参照してください。 | 移行リード | | Amazon EC2 のインターフェイスエンドポイントを設定します。 | ステージングエリア VPC は、ターゲットのステージングエリア VPC で作成したインターフェイスエンドポイントを介して Amazon EC2 API にプライベートに接続します。エンドポイントを作成するには、前のストーリーで説明した手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html) | 移行リード | | Amazon S3 のインターフェイスエンドポイントを設定します。 | ソースデータセンターとステージングエリア VPC は、ターゲットステージングエリア VPC で作成したインターフェイスエンドポイントを介して Amazon S3 API にプライベートに接続します。エンドポイントを作成するには、最初のストーリーの手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)ゲートウェイエンドポイントの接続を VPC の外に延長することはできないため、インターフェイスエンドポイントを使用します。(詳細については [AWS PrivateLink ドキュメント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway.html)を参照)。 | 移行リード | | Amazon S3ゲートウェイエンドポイントの設定 | 設定フェーズでは、レプリケーションサーバーは S3 バケットに接続して AWS 、レプリケーションサーバーのソフトウェア更新をダウンロードする必要があります。ただし、Amazon S3 インターフェイスエンドポイントはプライベート DNS 名をサポートしていないため*、*Amazon S3 エンドポイント DNS 名をレプリケーションサーバーに提供する方法はありません。 この問題を軽減するには、ステージングエリアサブネットが属する VPC で Amazon S3 ゲートウェイエンドポイントを作成し、ステージングサブネットのルートテーブルを関連するルートで更新します。詳細については、 AWS PrivateLink ドキュメントの[「ゲートウェイエンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#create-gateway-endpoint-s3)」を参照してください。 | クラウド管理者 | | エンドポイントのプライベート DNS 名を解決するために、オンプレミス DNS を設定する | アプリケーション移行サービスと Amazon EC2 のインターフェイスエンドポイントには、VPC で解決できるプライベート DNS 名があります。ただし、これらのインターフェイスエンドポイントのプライベート DNS 名を解決するように、オンプレミスサーバーを設定する必要もあります。これらのサーバーを設定するには、複数の方法があります。このパターンでは、オンプレミスの DNS クエリをステージングエリア VPC の Amazon Route 53 Resolver インバウンドエンドポイントに転送することで、この機能をテストしました。詳細については、Route 53 ドキュメントの「[Resolving DNS queries between VPCs and your network](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html)」を参照してください。 | 移行エンジニア | ### プライベートリンクを介してアプリケーション移行サービスのコントロールプレーンに接続 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | を使用して AWS レプリケーションエージェントをインストールします AWS PrivateLink。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)以下は、Linux の例です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)Application Migration Service との接続を確立し、 AWS レプリケーションエージェントをインストールしたら、[Application Migration Service ドキュメント](https://docs.aws.amazon.com/mgn/latest/ug/migration-workflow-gs.html)の指示に従って、ソースサーバーをターゲット VPC とサブネットに移行します。 | 移行エンジニア | ## 関連リソース 「**アプリケーション移行サービスドキュメント**」 + 「[概念](https://docs.aws.amazon.com/mgn/latest/ug/CloudEndure-Concepts.html)」 + 「[移行ワークフロー](https://docs.aws.amazon.com/mgn/latest/ug/migration-workflow-gs.html)」 + 「[クイックスタートガイド](https://docs.aws.amazon.com/mgn/latest/ug/quick-start-guide-gs.html)」 + [よくある質問](https://docs.aws.amazon.com/mgn/latest/ug/FAQ.html) + [トラブルシューティング](https://docs.aws.amazon.com/mgn/latest/ug/troubleshooting.html) **追加リソース** + [VPC インターフェイスエンドポイント AWS を使用した のマルチアカウントアーキテクチャでのアプリケーションのリホスト](https://docs.aws.amazon.com/prescriptive-guidance/latest/rehost-multi-account-architecture-interface-endpoints/) (AWS 規範ガイダンスガイド) + [AWS Application Migration Service – 技術的な概要](https://www.aws.training/Details/eLearning?id=71732) (AWS トレーニングと認定のチュートリアル) + [AWS Application Migration Service アーキテクチャとネットワークアーキテクチャ](https://youtu.be/ao8geVzmmRo) (ビデオ) ## 追加情報 **Linux サーバーでのレプリケーションエージェントのインストールの****トラブルシューティング ***AWS * Amazon Linux サーバーで **gcc** エラーが発生した場合は、パッケージリポジトリを設定し、次のコマンドを使用します。 ``` ## sudo yum groupinstall "Development Tools" ``` # AWS CloudFormation カスタムリソースと Amazon SNS を使用して Infoblox オブジェクトを作成します。 *Amazon Web Services、Tim Sutton* ## 概要 **注意**: AWS Cloud9 は新規顧客には利用できなくなりました。の既存のお客様は、通常どおりサービスを AWS Cloud9 引き続き使用できます。[詳細はこちら](https://aws.amazon.com/blogs/devops/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/) Infoblox ドメインネームシステム (DNS)、Dynamic Host Configuration Protocol (DHCP)、IP アドレス管理 ([Infoblox DDI](https://www.infoblox.com/products/ddi/)) により、複雑なハイブリッド環境を一元化し、効率的に制御できます。Infoblox DDIを使用すると、すべてのネットワーク資産を検出して1つの信頼できるIPアドレス管理（IPAM）データベースに記録できます。また、同じアプライアンスを使用してオンプレミスとAmazon Web Services（AWS）クラウドでDNSを管理できます。 このパターンでは、AWS CloudFormation カスタムリソースを使用して Infoblox WAPI API を呼び出して Infoblox オブジェクト (DNS レコードや IP アドレス管理オブジェクトなど) を作成する方法を説明します。Infoblox WAPI の詳細については、Infoblox ドキュメントの「[WAPI ドキュメント](https://www.infoblox.com/wp-content/uploads/infoblox-deployment-infoblox-rest-api.pdf)」を参照してください。 このパターンのアプローチを使用すると、レコードを作成してネットワークをプロビジョニングする手動プロセスを排除できるだけでなく、AWS 環境とオンプレミス環境のDNSレコードとIPAM構成を一元的に把握できます。このパターンのアプローチは、以下のユースケースに使用できます。 + Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを作成した後で A レコードを追加する  + Application Load Balancer の作成後の CNAME レコードの追加 + 仮想プライベートクラウド (VPC) 作成後のネットワークオブジェクトの追加 + 次のネットワーク範囲を指定し、その範囲を使用してサブネットを作成する このパターンを拡張して、さまざまな DNS レコードタイプの追加や Infoblox vDiscovery の設定など、Infoblox デバイスの他の機能を使用することもできます。  このパターンでは、ハブが AWS クラウドまたはオンプレミスの Infoblox アプライアンスへの接続を必要とし、AWS Lambda を使用して Infoblox API を呼び出すハブアンドスポーク設計を採用しています。スポークは AWS Organizationsの同じまたは別のアカウントにあり、AWS CloudFormation カスタムリソースを使用して Lambda 関数を呼び出します。 ## 前提条件と制限事項 **前提条件** + AWS クラウド、オンプレミス、またはその両方にインストールされ、IPAM と DNS アクションを管理できる管理者ユーザーで構成された既存の Infoblox アプライアンスまたはグリッド。詳細については、Infoblox ドキュメントの「[管理者アカウントについて](https://docs.infoblox.com/display/nios86/About+Admin+Accounts)」を参照してください。  + Infoblox アプライアンスにレコードを追加したい既存の DNS 権限ゾーン。詳細については、Infoblox ドキュメントの「[権限のあるゾーンの設定](https://docs.infoblox.com/display/nios86/Configuring+Authoritative+Zones)」を参照してください。  + AWS Organizations 内の 2 つのアクティブな AWS アカウント。1 つのアカウントはハブアカウントで、もう 1 つのアカウントはスポークアカウントです。 + このハブとスポークアカウントは同じ AWS リージョンに存在する必要があります。  + ハブアカウントの VPC は、たとえば AWS Transit Gateway や VPC ピアリングを使用して Infoblox アプライアンスに接続する必要があります。 + 「[AWS サーバーレスアプリケーションモデル (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)」を、ローカルにインストールし、AWS Cloud9 または AWS CloudShell で設定します。 + `Infoblox-Hub.zip`および`ClientTest.yaml`ファイル（添付）は、AWS SAM を含むローカル環境にダウンロードされます。 **制限事項** + AWS CloudFormation カスタムリソースのサービストークンは、作成しているスタックと同じリージョンのものである必要があります。あるリージョンで Amazon Simple Notification Service (Amazon SNS) トピックを作成し、別のリージョンで Lambda 関数を呼び出す代わりに、各リージョンでハブアカウントを使用することをお勧めします。 **製品バージョン** + Infoblox API バージョン 2.7 ## アーキテクチャ 以下の図表に、このパターンのワークフローを示しています。  ![\[AWS CloudFormation カスタムリソースと Amazon SNS を使用して Infoblox オブジェクトを作成する。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8d609d3f-6f5e-4084-849f-ca191db8055e/images/3594a064-e103-4211-84b7-da67c41ebb15.png) この図は、このパターンのソリューションを構成する以下のコンポーネントを示しています。 1. AWS CloudFormation カスタムリソースを使用すると、テンプレートにカスタムのプロビジョニングロジックを記述し、ユーザーがスタックを作成、更新、削除するたびに AWS CloudFormation がそれを実行します。スタックを作成するときに、AWS CloudFormation によって、EC2 インスタンスで実行しているアプリケーションが監視する SNS トピックに `create` リクエストを送信できます。 1. AWS CloudFormation カスタムリソースからの Amazon SNS 通知は、特定の AWS Key Management Service (AWS KMS) キーによって暗号化され、アクセスはOrganizations 内の組織内のアカウントに制限されます。SNS トピックは、Infoblox WAPI API を呼び出すLambda リソースを開始します。 1. Amazon SNS は、Infoblox WAPI URL、ユーザー名、およびパスワード AWS Secrets Manager Amazon リソースネーム (ARN) を環境変数として使用する次の Lambda 関数を呼び出します。  + `dnsapi.lambda_handler`— AWS CloudFormation カスタムリソースから`DNSName`、`DNSType`、`DNSValue`の値を受け取り、それらを使用して DNS A レコードと CNAME を作成します。 + `ipaddr.lambda_handler`— AWS CloudFormation カスタムリソースから`VPCCIDR`、`Type`、`SubnetPrefix`、`Network Name`の値を受け取り、それらを使用してネットワークデータを Infoblox IP アドレス管理データベースに追加したり、新しいサブネットの作成に使用できる次に使用可能なネットワークをカスタムリソースに提供したりします。 + `describeprefixes.lambda_handler`— `"com.amazonaws."+Region+".s3"`フィルタを使用して`describe_managed_prefix_lists` AWS API を呼び出し、必要な`prefix ID`を取得します。 **重要** これらの Lambda 関数は Python で記述されており、互いに似ていますが、呼び出す API が異なります。 1. Infoblox グリッドは、物理、仮想、またはクラウドベースのネットワークアプライアンスとしてデプロイできます。 オンプレミスで導入することも、VMware ESXi、Microsoft Hyper-V、Linux KVM、Xenなどのさまざまなハイパーバイザーを使用して仮想アプライアンスとして導入することもできます。Amazon マシンイメージ (AMI) を使用して Infoblox グリッドを AWS クラウドにデプロイすることもできます。 1. この図は、AWS クラウドとオンプレミスのリソースに DNS と IPAM を提供する Infoblox グリッドのハイブリッドソリューションを示しています。 **テクノロジースタック** + AWS CloudFormation + IAM + AWS KMS + AWS Lambda + AWS SAM + AWS Secrets Manager + Amazon SNS + Amazon VPC  ## ツール + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号キーを作成および管理する上で役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + 「[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)」は、複数の AWS アカウントを 1 つの組織に統合し、作成と一元管理するためのアカウント管理サービスです。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) は、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールに置き換えて、シークレットをプログラムで取得する上で役立ちます。 + 「[AWS サーバーレスアプリケーションモデル (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)」 は、 AWS クラウドのサーバーレスアプリケーションを構築するために支援するオープンソースフレームワークです。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。 **Code** `ClientTest.yaml`サンプル AWS CloudFormation テンプレート (添付) を使用して Infoblox ハブをテストできます。AWS CloudFormation テンプレートをカスタマイズして、次の表のカスタムリソースを含めることができます。 | | | --- | | Infoblox スポークカスタムリソースを使用して A レコードを作成します。 | 戻り値： `infobloxref `— Infoblox のリファレンスリソースの例： ``` ARECORDCustomResource: Type: "Custom::InfobloxAPI" Properties: ServiceToken: !Sub arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfobloxDNSFunction DNSName: 'arecordtest.company.com' DNSType: 'ARecord' DNSValue: '10.0.0.1' ``` | | --- |--- | | Infoblox スポークカスタムリソースを使用して CNAME レコードを作成します。 | **戻り値**： `infobloxref `— Infoblox のリファレンス**リソースの例**：
CNAMECustomResource:

  Type: "Custom::InfobloxAPI"

  Properties:

    ServiceToken: !Sub arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfoblox    

    DNSFunction

    DNSName: 'cnametest.company.com'

    DNSType: 'cname' 

    DNSValue: 'aws.amazon.com'
| | Infoblox スポークカスタムリソースを使用してネットワークオブジェクトを作成します。 | **戻り値**：`infobloxref `— Infoblox のリファレンス`network`— ネットワーク範囲 (と同じ) `VPCCIDR`**リソースの例**：
VPCCustomResource:

  Type: 'Custom::InfobloxAPI'

  Properties:

    ServiceToken: !Sub  arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfobloxNextSubnetFunction

    VPCCIDR: !Ref VpcCIDR

    Type: VPC

    NetworkName: My-VPC
| | Infoblox スポークカスタムリソースを使用して、次に使用可能なサブネットを取得します。 | **戻り値**：`infobloxref`— Infoblox のリファレンス`network `— サブネットのネットワーク範囲**リソースの例**：
Subnet1CustomResource:

  Type: 'Custom::InfobloxAPI'

  DependsOn: VPCCustomResource

  Properties:

    ServiceToken: !Sub  arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfobloxNextSubnetFunction

    VPCCIDR: !Ref VpcCIDR

    Type: Subnet

    SubnetPrefix: !Ref SubnetPrefix

NetworkName: My-Subnet
| ## エピック ### ハブアカウントの VPC を作成して設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Infoblox アプライアンスに接続する VPC を作成します。 | ハブアカウントの AWS マネジメントコンソールにサインインし、AWS クイックスタートの「[AWS クラウドクイックスタートリファレンスデプロイの Amazon VPC ](https://aws-quickstart.github.io/quickstart-aws-vpc/)」の手順に従って VPC を作成します。VPC には Infoblox アプライアンスへの HTTPS 接続が必要です。この接続にはプライベートサブネットを使用することをお勧めします。 | ネットワーク管理者、システム管理者 | | (オプション) プライベートサブネット用の VPC エンドポイントを作成します。 | VPC エンドポイントは、プライベートサブネットのパブリックサービスへの接続を提供します。次のエンドポイントが必要です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns.html)プライベートサブネット用のエンドポイント作成の詳細については、Amazon VPC ドキュメントの「[VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html)」を参照してください。 | ネットワーク管理者、システム管理者 | ### Infoblox ハブをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS SAM テンプレートをビルドします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns.html) | 開発者、システム管理者 | | AWS SAM テンプレートをデプロイします。 | `sam deploy`コマンドは、必要なパラメータを取得して`samconfig.toml`ファイルに保存し、AWS CloudFormation テンプレートと Lambda 関数を S3 バケットに保存し、次に AWS CloudFormation テンプレートをハブアカウントにデプロイします。 次のサンプルコードは、AWS SAM テンプレートをデプロイする方法を示しています。
$ sam deploy --guided

Configuring SAM deploy
======================
        Looking for config file [samconfig.toml] :  Found
        Reading default arguments  :  Success
        Setting default arguments for 'sam deploy'
        =========================================
        Stack Name [Infoblox-Hub]:
        AWS Region [eu-west-1]:
        Parameter InfobloxUsername:
        Parameter InfobloxPassword:
        Parameter InfobloxIPAddress [xxx.xxx.xx.xxx]:
        Parameter AWSOrganisationID [o-xxxxxxxxx]:
        Parameter VPCID [vpc-xxxxxxxxx]:
        Parameter VPCCIDR [xxx.xxx.xxx.xxx/16]:
        Parameter VPCSubnetID1 [subnet-xxx]:
        Parameter VPCSubnetID2 [subnet-xxx]:
        Parameter VPCSubnetID3 [subnet-xxx]:
        Parameter VPCSubnetID4 []: 
        #Shows you resources changes to be deployed and require a 'Y' to initiate deploy
        Confirm changes before deploy [Y/n]: y
        #SAM needs permission to be able to create roles to connect to the resources in your template
Allow SAM CLI IAM role creation [Y/n]: n
Capabilities [['CAPABILITY_NAMED_IAM']]:
        Save arguments to configuration file [Y/n]: y
        SAM configuration file [samconfig.toml]:
        SAM configuration environment [default]:
Infoblox のサインイン認証情報は `samconfig.toml` ファイルに保存されないため、`--guided` オプションは毎回使用する必要があります。 | 開発者、システム管理者 | ## 関連リソース + [Postman を使用して API を使い始める](https://blogs.infoblox.com/community/getting-started-with-wapis-using-postman/) (Infoblox ブログ) + [BYOL モデルを使用した AWS 向けの VNIO のプロビジョニング](https://docs.infoblox.com/display/NAIG/Provisioning+vNIOS+for+AWS+Using+the+BYOL+Model) (Infoblox ドキュメント) + [クイックスタート-AWS-VPC](https://github.com/aws-quickstart/quickstart-aws-vpc) (GitHub リポジトリ) + [describe\$1managed\$1prefix\$1lists](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html#EC2.Client.describe_managed_prefix_lists) (AWS SDK for Python) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/8d609d3f-6f5e-4084-849f-ca191db8055e/attachments/attachment.zip)」 # Terraform を使用して AWS で階層型のマルチリージョン IPAM アーキテクチャを作成する *Amazon Web Services、Donny Schreiber* ## 概要 *IP Address Manager (IPAM)* はネットワーク管理における重要なコンポーネントであり、組織がクラウドインフラストラクチャをスケールするにつれて、その複雑性は増加します。適切な IPAM が欠けている状態では、組織は IP アドレスの競合やアドレススペースの浪費、複雑なトラブルシューティングのリスクにさらされ、停止やアプリケーションのダウンタイムにつながる可能性があります。このパターンは、HashiCorp Terraform を使用して AWS エンタープライズ環境に包括的な IPAM ソリューションを実装する方法を示しています。これにより、組織は組織内のすべての AWS アカウント で一元化された IP アドレス管理を容易にする階層型のマルチリージョン IPAM アーキテクチャを作成できます[AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organization-structure)。 このパターンは、最上位プール、リージョンプール、ビジネスユニットプール、環境固有のプールという高度な 4 層プール階層を持つ [Amazon VPC IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) の実装に活用できます。この構造により、適切な IP アドレスガバナンスをサポートし、組織内の適切なチームに IP 管理を委任できるようになります。このソリューションは AWS Resource Access Manager (AWS RAM) を使用して、IP Address Manager プールを組織全体でシームレスに共有します。 は IPAM 仕様を AWS RAM 一元化および標準化します。この仕様は、チームがすべてのマネージドアカウントで構築できます。 このパターンを活用することで、以下の操作が可能です。 + 、ビジネスユニット AWS リージョン、環境間の IP アドレスの割り当てを自動化します。 + プログラム検証により、組織のネットワークポリシーを適用します。 + 業務ニーズに合わせてネットワークのインフラストラクチャを効率的にスケールします。 + IP アドレススペースを一元管理することで、運用上のオーバーヘッドを削減します。 + セルフサービス CIDR 範囲の割り当てにより、クラウドネイティブワークロードのデプロイを高速化します。 + ポリシーベースの制御と検証を実施することで、アドレスの競合を防ぎます。 ## 前提条件と制限 **前提条件** + 組織として管理される AWS アカウント 1 つ以上の AWS Organizations。 + IP Address Manager の委任管理者として機能するネットワークハブまたはネットワーク管理アカウント。 + AWS Command Line Interface (AWS CLI)、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み。 + [インストール済み](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)の Terraform、バージョン 1.5.0 以降。 + AWS Terraform のプロバイダー、[設定](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)済み。 + AWS Identity and Access Management (IAM) で設定された [IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/iam-ipam.html)、[AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/security-iam.html)、および Virtual Private Cloud (VPC) を管理するためのアクセス許可。 [VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/security-iam.html) **制限事項** + IP Address Manager には [Service Quotas](https://docs.aws.amazon.com/vpc/latest/ipam/quotas-ipam.html) が適用されます。プールのデフォルトの Service Quotas は、スコープあたり 50 です。このデプロイを 6 つのリージョン、2 つのビジネスユニット、4 つの環境で実行すると、67 のプールが作成されます。したがって、クォータの引き上げが必要になる場合があります。 + リソースの割り当て後に IP Address Manager プールを変更または削除すると、依存関係の問題が発生する可能性があります。プールを削除するには、最初に[割り当てを解除](https://docs.aws.amazon.com/vpc/latest/ipam/release-alloc-ipam.html)する必要があります。 + IP Address Manager では、[リソースのモニタリング](https://docs.aws.amazon.com/vpc/latest/ipam/monitor-cidr-compliance-ipam.html)でリソースの変更が反映されるのにわずかな遅延が発生する可能性があります。この遅延は約 20 分です。 + IP Address Manager は、異なるスコープにわたって IP アドレスの一意性を自動的に適用することはできません。 + カスタムタグは 「[AWS tagging best practices](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)」に従って作成してください。例えば、各キーは一意である必要があり、`aws:` で始めることはできません。 + IP Address Manager を組織外のアカウントと統合する際には、必ず「[考慮事項と制限](https://docs.aws.amazon.com/vpc/latest/ipam/enable-integ-ipam-outside-org-considerations.html)」をご確認ください。 ## アーキテクチャ **ターゲットアーキテクチャ** *IP Address Manager の設定とプール階層* ターゲットアーキテクチャの理論コンストラクトを以下の図に示します。*スコープ*は、IP Address Manager の最上位コンテナです。それぞれのスコープは、単一ネットワークの IP アドレススペースを表します。*プール*とは、スコープ内の連続した IP アドレス範囲 (または CIDR 範囲) のコレクションです。プールを使用すると、ルーティングとセキュリティのニーズに応じて IP アドレスを整理できます。この図は、最上位プール、リージョンプール、ビジネスユニットプール、環境プールの 4 つの階層レベルのプールを示しています。 ![\[ネットワークアカウントの単一の AWS リージョン内のプライベートスコープと 4 レベルのプール。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/780e344e-37f7-4b70-8d7c-94ec67a29305/images/1e23b2a7-a274-4a19-9097-61d8a31dfbf8.png) このソリューションは、IP Address Manager プールの明確な階層を確立します。 1. 最上位プールには、`10.176.0.0/12` などの組織の IP アドレススペース全体が含まれます。 1. リージョンプールは、`us-east-1` に対しての `10.176.0.0/15` といった、リージョン固有の割り当てを行う際に機能します。 1. ビジネスユニットプールは、各 内のドメイン固有の割り当てです AWS リージョン。例えば、`us-east-1` リージョンの財務ビジネスユニットでは `10.176.0.0/16` を保有している場合があります。 1. 環境プールは、さまざまな環境に対する目的固有の割り当てです。例えば、`us-east-1` リージョンの財務ビジネスユニットでは、本番環境用に `10.176.0.0/18` を保有している場合があります。 このデプロイトポロジは、一元化された制御を維持しながら、IP Address Manager リソースを地理的に分散します。以下はその機能です。 + IP Address Manager は 1 つのプライマリにデプロイされます AWS リージョン。 + 追加のリージョンは、IP Address Manager がリソースを管理できる[運用リージョン](https://docs.aws.amazon.com/vpc/latest/ipam/mod-ipam-region.html)として登録されます。 + 各運用リージョンは、最上位プールから専用アドレスプールを受け取ります。 + すべての運用リージョンのリソースは、プライマリリージョンの IP Address Manager を通じて一元管理されます。 + 各リージョンプールには、リソースの適切な割り当てに役立つロケールプロパティがリージョンに関連付けられています。 *高度な CIDR 範囲の検証* このソリューションは、無効な設定のデプロイを防ぐように設計されています。Terraform を介してプールをデプロイすると、Terraform 計画フェーズ中に以下が検証されます。 + すべての環境 CIDR 範囲が親ビジネスユニットの CIDR 範囲に含まれていることを検証します + すべてのビジネスユニット CIDR 範囲が親リージョンの CIDR 範囲内に含まれていることを確認します + すべてのリージョンの CIDR 範囲が最上位 CIDR 範囲に含まれていることを確認します + 同じ階層レベル内で重複する CIDR 範囲をチェックします + 環境とそれぞれのビジネスユニットの適切なマッピングを検証します *CIDR 範囲の割り当て* 次の図は、開発者または管理者が新規 VPC を作成し、プールレベルから IP アドレスを割り当てる手法のサンプルを示しています。 ![\[ネットワークアカウントの単一の AWS リージョン内のプライベートスコープと 4 レベルのプール。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/780e344e-37f7-4b70-8d7c-94ec67a29305/images/7c3de2e3-e71b-4fc0-abcd-7e88cfab5c87.png) この図表は、次のワークフローを示しています: 1. 開発者または管理者は AWS マネジメントコンソール、、 AWS CLI、またはInfrastructure as Code (IaC) を通じて、`AY3`環境プールで次に使用可能な CIDR 範囲をリクエストします。 1. IP Address Manager は、そのプールで次に使用可能な CIDR 範囲を `AY3-4` VPC に割り当てます。この CIDR 範囲は使用できなくなりました。 **自動化とスケール** このソリューションは、次のようにスケーラビリティを実現するように設計されています。 + **リージョン拡張** – リージョンプールエントリを追加して Terraform 設定を拡張することで、新しいリージョンを追加します。 + **ビジネスユニットの成長** – BU 設定マップに追加することで、新しいビジネスユニットをサポートします。 + **環境の柔軟性** – 組織のニーズに基づいて、開発や本番環境などのさまざまな環境タイプを設定します。 + **マルチアカウントサポート** – を通じて組織内のすべてのアカウント間でプールを共有します AWS RAM。 + **自動 VPC プロビジョニング** – VPC プロビジョニングワークフローと統合して、CIDR 範囲の割り当てを自動化します。 階層構造では、次のようなさまざまな委任と制御のスケールも許可されます。 + ネットワーク管理者は、最上位プールとリージョンプールを管理する場合があります。 + ビジネスユニットの IT チームは、それぞれのプールの管理を委任している可能性があります。 + アプリケーションチームは、指定された環境プールの IP アドレスを使用する場合があります。 **注記** このソリューションを [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) と統合することもできます。詳しくは、本パターンの「[追加情報](#multi-region-ipam-architecture-additional)」セクションの「*AFT との統合*」をご確認ください。 ## ツール **AWS のサービス** + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行しているアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。 + [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) は、 間でリソースを安全に共有 AWS アカウント し、運用オーバーヘッドを削減し、可視性と監査性を提供します。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。[IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) は Amazon VPC の機能です。 AWS ワークロードの IP アドレスを計画、追跡、モニタリングするのに役立ちます。 **その他のツール** + [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのを支援する Infrastructure as Code (IaC) ツールです。 **コードリポジトリ** このパターンのコードは、GitHub の「[Sample Terraform Implementation for Hierarchical IPAM on AWS](https://github.com/aws-samples/sample-amazon-vpc-ipam-terraform)** **repository」から入手できます。リポジトリ構造には以下が含まれます。 + **ルートモジュール** – デプロイオーケストレーション変数と入力変数。 + **IPAM モジュール** – このパターンで説明されているアーキテクチャのコア実装。 + **タグモジュール** – すべてのリソースに標準化されたタグ。 ## ベストプラクティス ネットワークの計画時は、以下のベストプラクティスを参照してください。 + **最初に計画する** – デプロイ前に IP アドレススペースを慎重に計画します。詳しくは「[IP アドレスのプロビジョニング計画](https://docs.aws.amazon.com/vpc/latest/ipam/planning-ipam.html)」をご確認ください。 + **CIDR 範囲の重複を避ける** – 各レベルの CIDR 範囲が重複しないようにしてください。 + **バッファスペースを確保する** – 増加に対応できるよう、CIDR 範囲は常に広めに割り当てるようにしましょう。 + **IP アドレス割り当てのドキュメント** – IP アドレス割り当て戦略のドキュメントを管理します。 デプロイにおけるベストプラクティスを以下からご確認ください。 + **非本番環境から始める** – まず非本番環境にデプロイします。 + **Terraform 状態管理を活用する** – リモート状態ストレージとロックを実装します。詳しくは Terraform ドキュメントの「[State storage and locking](https://developer.hashicorp.com/terraform/language/state/backends)」をご確認ください。 + **バージョン管理の実装** – Terraform コードのバージョンをすべて管理します。 + **CI/CD 統合の実装** – 反復可能なデプロイには、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用します。 オペレーションにおいては以下のベストプラクティスを参考にしてください。 + **自動インポートを有効にする** – 既存のリソースを自動的に検出してインポートするように IP Address Manager プールを設定します。「[IPAM プールを編集する](https://docs.aws.amazon.com/vpc/latest/ipam/mod-pool-ipam.html)」に記載の手順に従って、自動インポートを有効にします。 + **IP アドレス使用率のモニタリング** – IP アドレス使用率のしきい値のアラームを設定します。詳しくは「[Amazon CloudWatch で IPAM をモニタリングする](https://docs.aws.amazon.com/vpc/latest/ipam/cloudwatch-ipam.html)」をご確認ください。 + **定期的な監査** — IP アドレスの使用状況とコンプライアンスを定期的に監査します。詳しくは「[IPAM での IP アドレス使用状況の追跡](https://docs.aws.amazon.com/vpc/latest/ipam/tracking-ip-addresses-ipam.html)」をご確認ください。 + **使用していない割り当てを削除する** – リソースが廃止された際には IP アドレス割り当てを解放しましょう。詳しくは「[プールから CIDR のプロビジョニングを解除するには](https://docs.aws.amazon.com/vpc/latest/ipam/depro-pool-cidr-ipam.html)」をご確認ください。 セキュリティ面では以下のベストプラクティスを参考にしてください。 + **最小特権を実装する** – 必要最低限のアクセス権を付与した IAM ロールを使用します。詳しくは「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」および「[IPAM での Identity and Access Management](https://docs.aws.amazon.com/vpc/latest/ipam/iam-ipam.html)」をご確認ください。 + **サービスコントロールポリシーを使用する** – サービスコントロールポリシー (SCP) を実装して、組織で IP Address Manager の使用を強制します。詳しくは「[SCP を使用して VPC 作成に IPAM の使用を強制する](https://docs.aws.amazon.com/vpc/latest/ipam/scp-ipam.html)」をご確認ください。 + **リソース共有の制御** – で IP Address Manager リソース共有の範囲を慎重に管理します AWS RAM。詳細については、「 [を使用して IPAM プールを共有する AWS RAM](https://docs.aws.amazon.com/vpc/latest/ipam/share-pool-ipam.html)」を参照してください。 + **タグ付けを強制する** – IP Address Manager に関連するすべてのリソースに必須のタグ付けを実装します。詳しくは「[追加情報](#multi-region-ipam-architecture-additional)」セクションの「*タグ付け戦略*」をご確認ください。 ## エピック ### IP Address Manager の委任管理者アカウントを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Organizations 機能を有効にします。 | AWS Organizations ですべての機能が有効になっていることを確認します。手順については、 AWS Organizations ドキュメントの「 [を使用して組織のすべての機能を有効にする AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)」を参照してください。 | AWS 管理者 | | でリソース共有を有効にします AWS RAM。 | を使用して AWS CLI、次のコマンドを入力して、組織の AWS RAM リソース共有を有効にします。
aws ram enable-sharing-with-aws-organization
詳細については、 AWS RAM ドキュメントの「 [内でリソース共有を有効にする AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)」を参照してください。 | AWS 管理者 | | IP Address Manager の管理者を指定します。 | 組織の管理アカウントから、 を使用して AWS CLI次のコマンドを入力します。ここで、 `123456789012` は IP Address Manager を管理するアカウントの ID です。
aws ec2 enable-ipam-organization-admin-account \
    --delegated-admin-account-id 123456789012
通常、ネットワークまたはネットワークハブアカウントは、IP Address Manager の委任管理者として使用されます。詳細については、[「IP Address Manager ドキュメント」の「Integrate IPAM with accounts in an AWS Organization](https://docs.aws.amazon.com/vpc/latest/ipam/enable-integ-ipam.html)」を参照してください。 | AWS 管理者 | ### インフラストラクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ネットワークアーキテクチャを定義します。 | リージョン、ビジネスユニット、環境の CIDR 範囲など、ネットワークアーキテクチャを定義して文書化します。詳しくは IP Address Manager ドキュメントの「[IP アドレスのプロビジョニング計画](https://docs.aws.amazon.com/vpc/latest/ipam/planning-ipam.html)」をご確認ください。 | ネットワークエンジニア | | リポジトリのクローン作成 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | DevOps エンジニア | | 変数を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | ネットワークエンジニア、Terraform | | IP Address Manager リソースをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | Terraform | | デプロイを検証する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | AWS 全般、ネットワークエンジニア | ### VPC を作成してモニタリングを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPC を作成します。 | Amazon VPC ドキュメントの「[VPC を作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)」の手順に従ってください。VPC の CIDR 範囲を選択するステップに到達したら、リージョン、ビジネスユニット、環境プールのいずれかから利用可能な範囲を割り当てます。 | AWS 全般、ネットワーク管理者、ネットワークエンジニア | | CIDR 範囲の割り当てを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | AWS 全般、ネットワーク管理者、ネットワークエンジニア | | IP Address Manager をモニタリングします。 | IP Address Manager リソースの割り当てに関連するモニタリングとアラームを設定します。手順について、詳しくは IP Address Manager ドキュメントの「[Amazon CloudWatch で IPAM をモニタリングする](https://docs.aws.amazon.com/vpc/latest/ipam/cloudwatch-ipam.html)」および「[リソースごとに CIDR の使用状況をモニタリングする](https://docs.aws.amazon.com/vpc/latest/ipam/monitor-cidr-compliance-ipam.html)」をご確認ください。 | AWS 全般 | | IP Address Manager の使用を強制します。 | 組織内のメンバーが VPC を作成するときに IP Address Manager を使用すること AWS Organizations を要求するサービスコントロールポリシー (SCP) を に作成します。手順については IP Address Manager ドキュメントの「[SCP を使用して VPC 作成に IPAM の使用を強制する](https://docs.aws.amazon.com/vpc/latest/ipam/scp-ipam.html)」を参照してください。 | 一般的な AWS、AWS 管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Terraform が失敗し、「IP Address Manager リソースが見つかりません」という表示が出る | IP Address Manager 管理者アカウントが適切に委任され、 AWS プロバイダーがそのアカウントに認証されていることを確認します。 | | CIDR 範囲の割り当てが失敗する | リクエストされた CIDR 範囲が IP Address Manager プールの使用可能な範囲内に収まり、既存の割り当てと重複していないことを確認します。 | | AWS RAM 問題の共有 | Organization でリソース共有が有効になっていることを確認します AWS 。正しいプリンシパルである組織の Amazon リソースネーム (ARN) が AWS RAM 共有で使用されていることを確認します。 | | プール階層の検証エラー | 子プール CIDR 範囲が親プール CIDR 範囲内に適切に含まれており、兄弟プールと重複していないことを確認します。 | | IP Address Manager のクォータ制限を超過した | IP Address Manager プールのクォータ引き上げをリクエストしてください。詳細については、「*Service Quotas ユーザーガイド*」の「[クォータの引き上げのリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」を参照してください。 | ## 関連リソース **AWS のサービス ドキュメント** + [Amazon VPC IP Address Manager ドキュメント](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) + [AWS Resource Access Manager ドキュメント](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) + [AWS Organizations ドキュメント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) **AWS ブログ投稿** + [Managing IP pools across VPCs and Regions using Amazon VPC IP Address Manager](https://aws.amazon.com/blogs/networking-and-content-delivery/managing-ip-pools-across-vpcs-and-regions-using-amazon-vpc-ip-address-manager/) + [Network address management and auditing at scale with Amazon VPC IP Address Manager](https://aws.amazon.com/blogs/aws/network-address-management-and-auditing-at-scale-with-amazon-vpc-ip-address-manager/) **動画とチュートリアル** + [AWS re:Invent 2022: Amazon VPC 設計と IPAM のベストプラクティス (NET310)](https://www.youtube.com/watch?v=XrEHsy_8RYs) + [AWS re:Invent 2022: 高度な VPC 設計と新機能 (NET401)](https://www.youtube.com/watch?v=tbXTVpwx87o) ## 追加情報 **AFT との統合** このソリューションを AWS Control Tower Account Factory for Terraform (AFT) と統合して、新しくプロビジョニングされたアカウントが適切なネットワーク設定を自動的に受信するようにできます。この IPAM ソリューションをネットワークハブアカウントにデプロイすることで、AFT を介して作成された新アカウントが、共有の IP Address Manager プールを VPC 作成時に参照できるようになります。 次のコードサンプルは、Parameter Store を使用したアカウントカスタマイズでの AFT AWS Systems Manager 統合を示しています。 ``` # Get the IP Address Manager pool ID from Parameter Store data "aws_ssm_parameter" "dev_ipam_pool_id" { name = "/org/network/ipam/finance/dev/pool-id" } # Create a VPC using the IP Address Manager pool resource "aws_vpc" "this" { ipv4_ipam_pool_id = data.aws_ssm_parameter.dev_ipam_pool_id.value ipv4_netmask_length = 24 tags = { Name = "aft-account-vpc" } } ``` **タグ付け戦略** このソリューションは、包括的なタグ付け戦略を実装して、リソース管理を容易にします。以下にサンプルコードの活用例を示します。 ``` # Example tag configuration module "tags" { source = "./modules/tags" # Required tags product_name = "enterprise-network" feature_name = "ipam" org_id = "finance" business_unit = "network-operations" owner = "network-team" environment = "prod" repo = "https://github.com/myorg/ipam-terraform" branch = "main" cost_center = "123456" dr_tier = "tier1" # Optional tags optional_tags = { "project" = "network-modernization" "stack_role" = "infrastructure" } } ``` これらのタグは、すべての IP Address Manager リソースに自動的に適用されます。これにより、安定したガバナンスとコスト配分、リソース管理を実現します。 # の Amazon CloudWatch アラートをカスタマイズする AWS Network Firewall *Amazon Web Services、Jason Owens* ## 概要 このパターンは、 によって生成される Amazon CloudWatch アラートをカスタマイズするのに役立ちます AWS Network Firewall。事前定義されたルールを使用するか、アラートのメッセージ、メタデータ、重要度を決定するカスタムルールを作成できます。その後、これらのアラートに対応するか、Amazon EventBridge などの他のAmazonサービスによる対応を自動化することができます。 このパターンでは、Suricata 互換のファイアウォールルールを生成します。「[Suricata](https://suricata.io/)」はオープンソースの脅威検出エンジンです。まず簡単なルールを作成し、次にそれらをテストして CloudWatch アラートが生成され、記録されていることを確認します。ルールを正常にテストしたら、ルールを変更してカスタムメッセージ、メタデータ、重要度を定義し、もう一度テストして更新を確認します。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + AWS Command Line Interface (AWS CLI) を Linux、macOS、または Windows ワークステーションにインストールして設定します。詳細については、「[Installing or updating the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。 + AWS Network Firewall CloudWatch Logs を使用するようにインストールおよび設定されている。詳細については、「 [からのネットワークトラフィックのログ記録 AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-logging.html)」を参照してください。 + Network Firewall に保護された仮想プライベートクラウド (VPC) のプライベートサブネット内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス。 **製品バージョン** + のバージョン 1 では AWS CLI、1.18.180 以降を使用します。のバージョン 2 では AWS CLI、2.1.2 以降を使用します。 + Suricata バージョン 5.0.2 の分類.config ファイル。この設定ファイルのコピーについては、「[追加情報](#customize-amazon-cloudwatch-alerts-for-aws-network-firewall-additional)」セクションを参照してください。 ## アーキテクチャ ![\[EC2 インスタンスリクエストは Network Firewall でアラートを生成し、アラートを CloudWatch に転送します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/da6087a9-e942-4cfe-85e3-3b08de6f3ba5/images/778d85cd-bc87-4ed0-a161-d35eb5daa694.png) 以下は、アーキテクチャ図を示しています。 1. プライベートサブネットの Amazon EC2 インスタンスは [curl](https://curl.se/) または [Wget](https://www.gnu.org/software/wget/) を使用してリクエストを行います。 1. Network Firewall はトラフィックを処理し、アラートを生成します。 1. Network Firewall は、ログに記録されたアラートを CloudWatch Logs に送信します。 ## ツール **AWS のサービス** + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行するアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用すると、すべてのシステム、アプリケーション、および からのログを一元化 AWS のサービス できるため、ログをモニタリングして安全にアーカイブできます。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。 + [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) は、 AWS クラウドの仮想プライベートクラウド (VPC) にステートフルなマネージドネットワークファイアウォールを形成する、侵入検知および防止サービスです。  **その他のツール** + [curl](https://curl.se/) はオープンソースのコマンドラインツールとライブラリです。 + [GNU Wget](https://www.gnu.org/software/wget/) は無料のコマンドラインツールです。 ## エピック ### ファイアウォールルールとルールグループを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ルールを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者、ネットワーク管理者 | | ルールグループを作成する | で AWS CLI、次のコマンドを入力します。これにより、ルールグループが作成されます。
❯ aws network-firewall create-rule-group \
        --rule-group-name custom --type STATEFUL \
        --capacity 10 --rules file://custom.rules \
        --tags Key=environment,Value=development
以下に出力例を示します。後のステップで必要になるので、 `RuleGroupArn` を書き留めておきます。
{
    "UpdateToken": "4f998d72-973c-490a-bed2-fc3460547e23",
    "RuleGroupResponse": {
        "RuleGroupArn": "arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom",
        "RuleGroupName": "custom",
        "RuleGroupId": "238a8259-9eaf-48bb-90af-5e690cf8c48b",
        "Type": "STATEFUL",
        "Capacity": 10,
        "RuleGroupStatus": "ACTIVE",
        "Tags": [
            {
                "Key": "environment",
                "Value": "development"
            }
        ]
    }
| AWS システム管理者 | ### ファイアウォールポリシーを更新 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ファイアウォールポリシーの ARN を取得します。 | で AWS CLI、次のコマンドを入力します。ポリシーの Amazon リソースネーム (ARN) を返します。後のパターンで使用するために ARN を記録します。
❯ aws network-firewall describe-firewall \
    --firewall-name aws-network-firewall-anfw \
    --query 'Firewall.FirewallPolicyArn'
以下はこのコマンドによって返される ARN の例を示しています。
"arn:aws:network-firewall:us-east-2:1234567890:firewall-policy/firewall-policy-anfw"
| AWS システム管理者 | | ファイアウォールポリシーを更新 | テキストエディターで、次のコードを貼り付けます。前のエピックで記録した値に `` を置き換えてください。`firewall-policy-anfw.json` という名前でファイルを保存します。
{
    "StatelessDefaultActions": [
        "aws:forward_to_sfe"
    ],
    "StatelessFragmentDefaultActions": [
        "aws:forward_to_sfe"
    ],
    "StatefulRuleGroupReferences": [
        {
            "ResourceArn": ""
        }
    ]
}
AWS CLIで、次のコマンドを入力します。このコマンドには、新しいルールを追加するための[「更新トークン」](https://docs.aws.amazon.com/cli/latest/reference/network-firewall/update-firewall-policy.html)が必要です。このトークンは、ポリシーを最後に取得してから変更されていないことを確認するために使用されます。
UPDATETOKEN=(`aws network-firewall describe-firewall-policy \
              --firewall-policy-name firewall-policy-anfw \
              --output text --query UpdateToken`)
 
 aws network-firewall update-firewall-policy \
 --update-token $UPDATETOKEN \
 --firewall-policy-name firewall-policy-anfw \
 --firewall-policy file://firewall-policy-anfw.json
| AWS システム管理者 | | ポリシーの更新を確認します。 | (オプション) ルールが追加されたことを確認して、ポリシー形式を表示する場合は、 AWS CLIで次のコマンドを入力します。
❯ aws network-firewall describe-firewall-policy \
  --firewall-policy-name firewall-policy-anfw \
  --query FirewallPolicy
以下に出力例を示します。
{
    "StatelessDefaultActions": [
        "aws:forward_to_sfe"
    ],
    "StatelessFragmentDefaultActions": [
        "aws:forward_to_sfe"
    ],
    "StatefulRuleGroupReferences": [
        {
            "ResourceArn": "arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom"
        }
    ]
}
| AWS システム管理者 | ### テストアラート機能 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テスト用のアラートを生成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者 | | アラートが記録されていることを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者 | ### ファイアウォールルールとルールグループを更新します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ファイアウォールルールを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者 | | ルールグループを更新します。 | で AWS CLI、次のコマンドを実行します。ファイアウォールポリシーの ARN のを使用します。これらのコマンドは更新トークンを取得し、ルールを変更してルールグループを更新します。
❯ UPDATETOKEN=(`aws network-firewall \
                describe-rule-group \
--rule-group-arn arn:aws:network-firewall:us-east-2:123457890:stateful-rulegroup/custom \
--output text --query UpdateToken`)
 ❯ aws network-firewall update-rule-group \
  --rule-group-arn arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom \
--rules file://custom.rules \
--update-token $UPDATETOKEN
以下に出力例を示します。
{
    "UpdateToken": "7536939f-6a1d-414c-96d1-bb28110996ed",
    "RuleGroupResponse": {
        "RuleGroupArn": "arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom",
        "RuleGroupName": "custom",
        "RuleGroupId": "238a8259-9eaf-48bb-90af-5e690cf8c48b",
        "Type": "STATEFUL",
        "Capacity": 10,
        "RuleGroupStatus": "ACTIVE",
        "Tags": [
            {
                "Key": "environment",
                "Value": "development"
            }
        ]
    }
}
| AWS システム管理者 | ### 更新されたアラート機能のテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テスト用のアラートを生成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者 | | アラートが変更されたことを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者 | ## 関連リソース **リファレンス** + [から Slack チャネル AWS Network Firewall にアラートを送信する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/send-alerts-from-aws-network-firewall-to-a-slack-channel.html) (AWS 規範ガイダンス) + [Suricata AWS を使用した での脅威防止のスケーリング](https://aws.amazon.com/blogs/opensource/scaling-threat-prevention-on-aws-with-suricata/) (AWS ブログ記事) + [のデプロイモデル AWS Network Firewall](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) (AWS ブログ記事) + 「[スリカタメタキーワーク](https://suricata.readthedocs.io/en/suricata-6.0.1/rules/meta.html)」 (Suricata のドキュメント) **チュートリアルと動画** + [AWS Network Firewall ワークショップ](https://networkfirewall.workshop.aws/) ## 追加情報 以下は Suricata 5.0.2 の分類設定ファイルです。これらの分類はファイアウォールルールを作成するときに使用されます。 ``` # config classification:shortname,short description,priority config classification: not-suspicious,Not Suspicious Traffic,3 config classification: unknown,Unknown Traffic,3 config classification: bad-unknown,Potentially Bad Traffic, 2 config classification: attempted-recon,Attempted Information Leak,2 config classification: successful-recon-limited,Information Leak,2 config classification: successful-recon-largescale,Large Scale Information Leak,2 config classification: attempted-dos,Attempted Denial of Service,2 config classification: successful-dos,Denial of Service,2 config classification: attempted-user,Attempted User Privilege Gain,1 config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1 config classification: successful-user,Successful User Privilege Gain,1 config classification: attempted-admin,Attempted Administrator Privilege Gain,1 config classification: successful-admin,Successful Administrator Privilege Gain,1 # NEW CLASSIFICATIONS config classification: rpc-portmap-decode,Decode of an RPC Query,2 config classification: shellcode-detect,Executable code was detected,1 config classification: string-detect,A suspicious string was detected,3 config classification: suspicious-filename-detect,A suspicious filename was detected,2 config classification: suspicious-login,An attempted login using a suspicious username was detected,2 config classification: system-call-detect,A system call was detected,2 config classification: tcp-connection,A TCP connection was detected,4 config classification: trojan-activity,A Network Trojan was detected, 1 config classification: unusual-client-port-connection,A client was using an unusual port,2 config classification: network-scan,Detection of a Network Scan,3 config classification: denial-of-service,Detection of a Denial of Service Attack,2 config classification: non-standard-protocol,Detection of a non-standard protocol or event,2 config classification: protocol-command-decode,Generic Protocol Command Decode,3 config classification: web-application-activity,access to a potentially vulnerable web application,2 config classification: web-application-attack,Web Application Attack,1 config classification: misc-activity,Misc activity,3 config classification: misc-attack,Misc Attack,2 config classification: icmp-event,Generic ICMP event,3 config classification: inappropriate-content,Inappropriate Content was Detected,1 config classification: policy-violation,Potential Corporate Privacy Violation,1 config classification: default-login-attempt,Attempt to login by a default username and password,2 # Update config classification: targeted-activity,Targeted Malicious Activity was Detected,1 config classification: exploit-kit,Exploit Kit Activity Detected,1 config classification: external-ip-check,Device Retrieving External IP Address Detected,2 config classification: domain-c2,Domain Observed Used for C2 Detected,1 config classification: pup-activity,Possibly Unwanted Program Detected,2 config classification: credential-theft,Successful Credential Theft Detected,1 config classification: social-engineering,Possible Social Engineering Attempted,2 config classification: coin-mining,Crypto Currency Mining Activity Detected,2 config classification: command-and-control,Malware Command and Control Activity Detected,1 ``` # Terraform を使用して リソースを AWS Wavelength ゾーンにデプロイする *Zahoor Chaudhrey と Luca Iannario、Amazon Web Services* ## 概要 [AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/what-is-wavelength.html) は、マルチアクセスエッジコンピューティング (MEC) アプリケーション用に最適化されたインフラストラクチャの構築に役立ちます。*Wavelength Zones* は、通信サービスプロバイダー (CSP) の 5G ネットワーク内に AWS コンピューティングおよびストレージサービスを埋め込む AWS インフラストラクチャデプロイです。5G デバイスからのアプリケーショントラフィックは、通信ネットワークを離れることなく、Wavelength Zone で動作しているアプリケーションサーバーに到達します。以下は、Wavelength を介したネットワーク接続を容易にします。 + **仮想プライベートクラウド (VPCs)** – VPCs は、Wavelength Zones を含む複数のアベイラビリティーゾーンにまたがるように拡張 AWS アカウント できます。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスおよび関連サービスは、リージョン VPC の一部として表示されます。VPC は [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) で作成および管理されます。 + **キャリアゲートウェイ** – キャリアゲートウェイは、Wavelength Zone のサブネットから CSP ネットワーク、インターネット、または への CSP のネットワーク AWS リージョン を介した接続を可能にします。キャリアゲートウェイには 2 つの目的があります。特定の場所にある CSP ネットワークからのインバウンドトラフィックを許可し、通信ネットワークおよびインターネットへのアウトバウンドトラフィックを許可します。 このパターンとそれに関連する Terraform コードは、Amazon EC2 インスタンス、Amazon Elastic Block Store (Amazon EBS) ボリューム、VPC、サブネット、キャリアゲートウェイなどのリソースを Wavelength Zone で起動するのに役立ちます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + 統合開発環境 (IDE) + ターゲット Wavelength Zone に[オプトイン](https://docs.aws.amazon.com/wavelength/latest/developerguide/get-started-wavelength.html#enable-zone-group)する + AWS Command Line Interface (AWS CLI)、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み + Terraform バージョン 1.8.4 以降、[インストール済み](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) (Terraform ドキュメント) + Terraform AWS プロバイダーバージョン 5.32.1 以降、[設定](https://hashicorp.github.io/terraform-provider-aws/)済み (Terraform ドキュメント) + Git、[インストール済み](https://github.com/git-guides/install-git) (GitHub) + Amazon VPC、Wavelength、Amazon EC2 リソースを作成するための[アクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) **制限事項** すべての が Wavelength Zones AWS リージョン をサポートしているわけではありません。詳細については、Wavelength ドキュメントの「[利用可能な Wavelength ゾーン](https://docs.aws.amazon.com/wavelength/latest/developerguide/available-wavelength-zones.html)」を参照してください。 ## アーキテクチャ 次の図は、Wavelength Zone にサブネットと AWS リソースを作成する方法を示しています。Wavelength Zone にサブネットが含まれる VPC は、キャリアゲートウェイに接続できます。キャリアゲートウェイを使用すると、次のリソースに接続できます。 + 通信事業者のネットワーク上の 4G/LTE および 5G デバイス。 + 一部の Wavelength Zone パートナー用の固定ワイヤレスアクセス。詳細については、[「マルチアクセス AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/multi-access.html)」を参照してください。 + パブリックインターネットリソースへのアウトバウンドトラフィック。 ![\[キャリアゲートウェイは、Wavelength Zone の AWS リソースを CSP ネットワークに接続します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8c507de1-208c-4563-bb58-52388ab2fa6d/images/a4cc0699-0cbc-4f15-ab14-3ae569ced7f4.png) ## ツール **AWS のサービス** + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。 + [AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/what-is-wavelength.html) は AWS クラウド 、インフラストラクチャを通信プロバイダーの 5G ネットワークに拡張します。これにより、モバイルデバイスおよびエンドユーザー向けに、非常にレイテンシーが低いアプリケーションを構築できます。 **その他のツール** + [Terraform](https://www.terraform.io/) は HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 **コードリポジトリ** このパターンのコードは、GitHub の[「Terraform AWS Wavelength を使用したインフラストラクチャの作成](https://github.com/aws-samples/terraform-wavelength-infrastructure)」リポジトリで入手できます。Terraform コードは、次のインフラストラクチャとリソースをデプロイします。 + VPC + Wavelength Zone + Wavelength Zone のパブリックサブネット + Wavelength Zone のキャリアゲートウェイ + Wavelength Zone の Amazon EC2 インスタンス ## ベストプラクティス + デプロイする前に、最新バージョンの Terraform と AWS CLIを使用していることを確認します。 + 継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを使用して IaC をデプロイします。詳細については、[「Best practices for managing Terraform State files in AWS CI/CD Pipeline](https://aws.amazon.com/blogs/devops/best-practices-for-managing-terraform-state-files-in-aws-ci-cd-pipeline/) on AWS Blogs」を参照してください。 ## エピック ### インフラストラクチャをプロビジョニングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | 次のコマンドを入力して、[Terraform AWS Wavelength を使用してインフラストラクチャを作成する](https://github.com/aws-samples/terraform-wavelength-infrastructure)リポジトリを環境にクローンします。`git clone git@github.com:aws-samples/terraform-wavelength-infrastructure.git` | DevOps エンジニア | | 変数を更新してください。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | DevOps エンジニア、Terraform | | 設定を初期化します。 | 次のコマンドを入力して、作業ディレクトリを初期化します。
terraform init
| DevOps エンジニア、Terraform | | Terraform プランをプレビューしてください。 | 次のコマンドを入力して、ターゲットの状態を AWS 環境の現在の状態と比較します。このコマンドは、設定されるリソースのプレビューを生成します。
terraform plan
| DevOps エンジニア、Terraform | | 確認してデプロイする。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | DevOps エンジニア、Terraform | ### 検証とクリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インフラストラクチャのデプロイを検証する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | AWS DevOps、DevOps エンジニア | | (オプション) インフラストラクチャをクリーンアップします。 | Terraform によってプロビジョニングされたすべてのリソースを削除する必要がある場合は、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | DevOps エンジニア、Terraform | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | の Amazon EC2 インスタンスへの接続 AWS リージョン。 | 「[Linux インスタンスへの接続に関するトラブルシューティング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html)」または「[Windows インスタンスへの接続に関するトラブルシューティング](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/troubleshooting-windows-instances.html)」を参照してください。 | | Wavelength Zone の Amazon EC2 インスタンスへの接続。 | 「[Wavelength ゾーンで起動した EC2 インスタンスへの SSH または RDP の接続をトラブルシューティングする](https://repost.aws/knowledge-center/ec2-wavelength-zone-connection-errors)」を参照してください。 | | Wavelength Zone の容量。 | 「[Wavelength ゾーンのクォータと考慮事項](https://docs.aws.amazon.com/wavelength/latest/developerguide/wavelength-quotas.html)」を参照してください。 | | キャリアネットワークから AWS リージョンへのモバイルまたはキャリア接続。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | ## 関連リソース + [とは AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/what-is-wavelength.html) + [の AWS Wavelength 仕組み](https://docs.aws.amazon.com/wavelength/latest/developerguide/how-wavelengths-work.html) + [の耐障害性 AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/disaster-recovery-resiliency.html) # DNS レコードを Amazon Route 53 プライベートホストゾーンに一括で移行する *Ram Kandaswamy、Amazon Web Services* ## 概要 ネットワークエンジニアやクラウド管理者は、ドメインネームシステム (DNS) レコードを Amazon Route 53 のプライベートホストゾーンに追加する効率的で簡単な方法を必要としていました。Microsoft Excel ワークシートのエントリを Route 53 コンソールの適切な場所に手動でコピーする方法は、手間がかかり、エラーが発生しやすくなります。このパターンは、複数のレコードを追加するのに必要な時間と労力を削減する自動化されたアプローチについて説明します。また、複数のホストゾーンを作成する手順を繰り返すこともできます。　 このパターンでは、レコードの保存に Amazon Simple Storage Service (Amazon S3) を使用します。データを効率的に操作するため、このパターンでは JSON 形式が使用されます。これは、シンプルさと Python ディクショナリ (`dict` データ型) のサポート機能が理由です。 **注記** システムからゾーンファイルを生成できる場合は、代わりに [Route 53 インポート機能](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating-import.html)の使用をご検討ください。 ## 前提条件と制限事項 **前提条件** + プライベートホストゾーンのレコードを含む Excel ワークシート　 + A レコード、 名前付け権限ポインタ (NAPTR) レコード、SRV レコードなど、さまざまな種類の DNS レコードを理解していること (「[サポートされる DNS レコードタイプ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html)」を参照) + Python 言語とそのライブラリを理解していること **制限事項** + このパターンは、すべてのユースケースシナリオを網羅しているわけではありません。例えば、[change\$1resource\$1record\$1sets](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.change_resource_record_sets) 呼び出しでは API の使用可能なプロパティがすべて使用されるわけではありません。 + Excel ワークシートでは、各行の値は固有であると想定されます。各完全修飾ドメイン名 (FQDN) の複数の値が同じ行に表示されることが予想されます。　 そうでない場合は、このパターンで提供されるコードを修正して、必要な連結を実行する必要があります。 + このパターンでは、AWS SDK for Python (Boto3) を使用して、Route 53 サービスを直接呼び出します。コードを拡張して、`create_stack` および `update_stack` コマンドに AWS CloudFormation ラッパーを使用し、JSON 値を使用してテンプレートリソースを設定することができます。 ## アーキテクチャ **テクノロジースタック** + トラフィックをルーティングするための Route 53 プライベートホストゾーン + 出力 JSON ファイルを保存するための Amazon S3 ![\[DNS レコードを Route 53 プライベートホストゾーンに一括移行します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a81c29ea-f0c5-4d4a-ba87-93111a0f1ee9/images/2ada844b-4147-4f9f-8883-d22605aa42d8.png) このワークフローは、前の図と「*エピック*」セクションで説明したように、以下のステップで構成されています。 1. レコードセット情報を含む Excel ワークシートを S3 バケットにアップロードします。 1. Excel データを JSON 形式に変換する Python スクリプトを作成して実行します。 1. S3 バケットのレコードを読み取り、データをクリーンアップします。 1. プライベートホストゾーンにレコードセットを作成します。 ## ツール + [Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) — Amazon Route 53 は、ドメイン登録、DNS ルーティング、ヘルスチェックを処理する、可用性が高くスケーラブルな DNS ウェブサービスです。 + [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) — Amazon Simple Storage Service (Amazon S3) は、オブジェクトストレージサービスです。Simple Storage Service (Amazon S3) を使用すると、いつでもウェブ上の任意の場所から任意の量のデータを保存および取得できます。 ## エピック ### データ自動化の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | レコード用の Excel ファイルを作成します。 | 現在のシステムからエクスポートしたレコードを使用して、完全修飾ドメイン名 (FQDN)、レコードタイプ、有効期間 (TTL)、値など、レコードに必要な列を含む Excel ワークシートを作成します。　 NAPTR レコードと SRV レコードの場合、値は複数のプロパティの組み合わせなので、Excel の `concat` メソッドを使用してこれらのプロパティを組み合わせてください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone.html) | データエンジニア、Excel のスキル | | 作業環境を確認します。 | IDE で Python ファイルを作成し、Excel 入力ワークシートを JSON 形式に変換します。(IDE の代わりに、Amazon SageMaker ノートブックを使用して Python コードを編集することもできます。)Python のバージョン 3.7 以降を使用していることを確認してください。
 python3 --version
**pandas** パッケージをインストールします。
 pip3 install pandas --user
| AWS 全般 | | Excel ワークシートのデータを JSON に変換します。　 | Excel から JSON に変換し、次のコードを含む Python ファイルを作成します。
import pandas as pd
data=pd.read_excel('./Book1.xls')
data.to_json(path_or_buf='my.json',orient='records')
ここで `Book1` は Excel ワークシートの名前、`my.json` は出力 JSON ファイルの名前です。 | データエンジニア、Python スキル | | S3 バケットに JSON ファイルをアップロードします。 | S3 バケットに `my.json` ファイルをアップロードします。詳細については、Amazon S3 ドキュメントの「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)」を参照してください。 | アプリ開発者 | | FQDNName | RecordType | 値 | TTL | | something.example.org | A | 1.1.1.1 | 900 | ### レコードを挿入します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライベートホストゾーンを作成します。 | [create\$1hosted\$1zone](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.create_hosted_zone) API と次の Python サンプルコードを使用して、プライベートホストゾーンを作成します。パラメータ `hostedZoneName`、`vpcRegion`、および `vpcId` をユーザー自身の値に置き換えてください。
import boto3
import random
hostedZoneName ="xxx"
vpcRegion = "us-east-1"
vpcId="vpc-xxxx"
route53_client = boto3.client('route53')
response = route53_client.create_hosted_zone(
        Name= hostedZoneName,
        VPC={
            'VPCRegion: vpcRegion,
            'VPCId': vpcId
        },
        CallerReference=str(random.random()*100000),
        HostedZoneConfig={
            'Comment': "private hosted zone created by automation",
            'PrivateZone': True
        }
    )
 print(response)
AWS CloudFormation などの Infrastructure as Code (IaC) ツールを使用すれば、適切なリソースとプロパティを含むスタックを作成するテンプレートでこれらの手順を置き換えることもできます。 | クラウドアーキテクト、ネットワーク管理者、Python のスキル | | Amazon S3 から詳細をディクショナリとして取得します。 | 以下のコードを使用して S3 バケットから読み取り、JSON 値を Python ディクショナリとして取得します。 
fileobj = s3_client.get_object(
        Bucket=bucket_name,
        Key='my.json'
        )
    filedata = fileobj['Body'].read()
    contents = filedata.decode('utf-8')
    json_content=json.loads(contents)
    print(json_content)
`json_content` には、Pythonディクショナリが含まれます。 | アプリ開発者、Python のスキル | | スペースと Unicode 文字のデータ値を消去します。 | データが正しいことを確認するための安全対策として、`json_content` コードを使用して値を削除してください。このコードでは、各文字列の先頭と末尾のスペース文字が削除されます。　 また、`replace` メソッドを使用して (改行しない) ハードスペース (`\xa0` 文字) を削除します。
for item in json_content:
    fqn_name = unicodedata.normalize("NFKD",item["FqdnName"].replace("u'", "'").replace('\xa0', '').strip())
    rec_type = item["RecordType"].replace('\xa0', '').strip()
    res_rec = {
                 'Value': item["Value"].replace('\xa0', '').strip()
                }
| アプリ開発者、Python のスキル | | レコードを挿入します | `for` ループの一部として次のコードを使用します。
change_response = route53_client.change_resource_record_sets(
            HostedZoneId="xxxxxxxx",
            ChangeBatch={
                'Comment': 'Created by automation',
                'Changes': [
                    {
                        'Action': 'UPSERT',
                        'ResourceRecordSet': {
                            'Name': fqn_name,
                            'Type': rec_type,
                            'TTL': item["TTL"],
                            'ResourceRecords': res_rec
                        }
                    }
                ]
            }
    )
ここで `xxxxxxx` は、このエピックの最初のステップであるホストゾーン ID です。 | アプリ開発者、Python のスキル | ## 関連リソース **リファレンス** + 「[ゾーンファイルをインポートしてレコードを作成する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating-import.html)」 (Amazon Route 53 ドキュメント) + 「[create\$1hosted\$1zone メソッド](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.create_hosted_zone)」 (Boto3 ドキュメント) + 「[change\$1resource\$1record\$1sets メソッド](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.change_resource_record_sets)」 (Boto3 ドキュメント) **チュートリアルと動画** + 「[Python チュートリアル](https://docs.python.org/3/tutorial/)」 (Python ドキュメント) + 「[Amazon Route 53 を使用した DNS 設計](https://www.youtube.com/watch?v=2y_RBjDkRgY)」 (YouTube ビデオ、*AWS オンライン Tech Talks*) # F5 から AWS のApplication Load Balancer に移行するときの HTTP ヘッダーを変更 *Amazon Web Services、Sachin Trivedi* ## 概要 F5 ロードバランサーを使用するアプリケーションをAmazon Web Services (AWS) に移行し、AWS でApplication Load Balancer を使用したい場合、ヘッダー変更の F5 ルールを移行することがよくある問題です。Application Load Balancer はヘッダーの変更をサポートしていませんが、Amazon CloudFront をコンテンツ配信ネットワーク (CDN) として使用し、Lambda @Edge により、ヘッダーを変更できます。 このパターンは、必要なインテグレーションを説明し、AWS CloudFront と Lambda @Edge により、ヘッダーを変更するためのサンプルコードを提供します。 ## 前提条件と制限事項 **前提条件** + F5 ロードバランサーを使用するオンプレミスアプリケーションで、HTTP ヘッダー値を `if, else` により、置き換える設定になっています。この設定の詳細については、F5 製品ドキュメントの「[HTTP:: header](https://clouddocs.f5.com/api/irules/HTTP__header.html)」を参照してください。  **制限事項** + このパターンは F5 ロードバランサーのヘッダーのカスタマイズに適用されます。他の第三者ロードバランサーについては、ロードバランサーのドキュメントでサポート情報を確認してください。 + Lambda@Edge に使用する Lambda 関数は、米国東部 (バージニア北部) リージョンにある必要があります。 ## アーキテクチャ 次の図は、CDN と他の AWS コンポーネント間の統合フローを含む AWS のアーキテクチャを示しています。 ![\[Amazon CloudFront と Lambda @Edge により、ヘッダーを変更するためのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/00abbe3c-2453-4291-9b24-b488dced4868/images/4ee9a19e-6da2-4c5a-a8bc-19d3918a166e.png) ## ツール **AWS サービス** + 「[Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)」─ Application Load Balancer は、開放型システム間相互接続 (OSI) モデルの第 7 層で機能する AWS フルマネージド型負荷分散サービスです。複数のターゲット間でトラフィックを分散し、HTTP ヘッダーとメソッド、クエリ文字列、ホストベースまたはパスベースのルーティングに基づく高度なルーティングリクエストをサポートします。 + 「[Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)」— Amazon CloudFront は、ユーザーへの静的および動的なウェブコンテンツ (.html、.css、.js、イメージファイルなど) の配信を高速化するウェブサービスです。CloudFront では、エッジロケーションというデータセンターの世界的ネットワークを経由してコンテンツを配信し、レイテンシーを短縮し、パフォーマンスを向上させます。 + 「[Lambda@Edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html)」— Lambda@Edge は、CloudFront が配信するコンテンツをカスタマイズする関数を実行できる AWS Lambda の拡張機能です。米国東部 (バージニア北部) リージョンで作成した関数を CloudFront ディストリビューションに関連付けると、サーバーのプロビジョニングや管理の必要もなく、コードを世界中に自動的に複製できます。これにより、待ち時間が短縮され、ユーザーエクスペリエンスが向上します。 **Code** 次のサンプルコードは、CloudFront レスポンスヘッダーを変更するためのブループリントを提供します。*[エピック]* セクションの指示に従い、コードをデプロイします。 ``` exports.handler = async (event, context) => {     const response = event.Records[0].cf.response;     const headers = response.headers;     const headerNameSrc = 'content-security-policy';     const headerNameValue = '*.xyz.com';     if (headers[headerNameSrc.toLowerCase()]) {         headers[headerNameSrc.toLowerCase()] = [{             key: headerNameSrc,             value: headerNameValue,         }];         console.log(`Response header "${headerNameSrc}" was set to ` +                     `"${headers[headerNameSrc.toLowerCase()][0].value}"`);     }     else {             headers[headerNameSrc.toLowerCase()] = [{             key: headerNameSrc,             value: headerNameValue,             }];     }     return response; }; ``` ## エピック ### CDN ディストリビューションの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFront ウェブディストリビューションを作成します。 | このステップでは、CloudFront ディストリビューションを作成して、コンテンツの配信元とコンテンツ配信の追跡および管理方法の詳細を CloudFront に伝えます。コンソールを使用してディストリビューションを作成するには、AWS マネジメントコンソールにサインインし、「[CloudFront コンソール](https://console.aws.amazon.com/cloudfront/v3/home)」を開き、「[CloudFront のドキュメント](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-creating-console.html)」の手順に従います。 | クラウド管理者 | ### Lambda@Edge 関数の作成とデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda@Edge 関数の作成とデプロイ | CloudFront レスポンスヘッダーを変更するためのブループリントを使用して Lambda @Edge 関数を作成できます。(他のブループリントもさまざまなユースケースで利用できます。詳細については、「CloudFront のドキュメント」の「[Lambda @Edge サンプル関数](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html)」を参照してください。) Lambda@Edge 関数を作成するには[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws.html) | AWS 管理者 | | Lambda@Edge 関数をデプロイします。 | Amazon CloudFront ドキュメント「*チュートリアル: 基本的な Lambda@Edge 関数 (コンソール) を作成する*」の[ステップ 4](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works-tutorial-add-trigger) の手順に従い、CloudFront トリガーを設定し、関数をデプロイします。 | AWS 管理者 | ## 関連リソース CloudFront のドキュメント + 「[カスタムオリジンのリクエストとレスポンスの動作](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html)」  + 「[ディストリビューションの使用](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-working-with.html)」  + 「[Lambda@Edge 関数の例](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html)」  + 「[Lambda@Edge を使用したエッジでのカスタマイズ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html)」 + 「[チュートリアル:シンプルな Lambda@Edge 関数の作成](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html)」 # 複数の でインバウンドインターネットアクセスに関する Network Access Analyzer の検出結果のレポートを作成する AWS アカウント *Amazon Web Services、Mike Virgilio* ## 概要 AWS リソースへの意図しないインバウンドインターネットアクセスは、組織のデータ境界にリスクをもたらす可能性があります。[Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html) は、Amazon Virtual Private Cloud (Amazon VPC) の機能の一つで、Amazon Web Services (AWS) のリソースへの意図しないネットワークアクセスを識別できます。Network Access Analyzer を使用してネットワークアクセス要件を指定し、指定した要件を満たさない可能性のあるネットワークパスを特定できます。Network Access Analyzer を使用すると、次の操作を実行できます。 1. インターネットゲートウェイを介してインターネットにアクセスできる AWS リソースを特定します。 1. 運用環境と開発環境を分離し、またはトランザクションワークロードを分離するなど、仮想プライベートクラウド (VPC) が適切にセグメント化されていることを確認します。 Network Access Analyzer は、単一のコンポーネントだけでなく、エンドツーエンドのネットワーク到達可能性条件を分析します。リソースがインターネットにアクセスできるかどうかを判断するために、Network Access Analyzer はインターネットゲートウェイ、VPC ルートテーブル、ネットワークアクセスコントロールリスト (ACL)、Elastic Network Interface の公開 IP アドレスとセキュリティグループを評価します。これらのコンポーネントのいずれかがインターネットアクセスを妨げている場合、Network Access Analyzer は検出結果を生成しません。たとえば、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに、`0/0` からのトラフィックを許可するオープンセキュリティグループがあっても、そのインスタンスがどのインターネットゲートウェイからもルーティングできないプライベートサブネットにある場合、Network Access Analyzer は検出結果を生成しません。これにより精度の高い結果が得られるため、インターネットから本当にアクセスできるリソースを特定できます。 Network Access Analyzerを実行するときには、「[ネットワークアクセススコープ](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html#concepts)」を使用してネットワークアクセス要件を指定します。このソリューションは、インターネットゲートウェイとエラスティックネットワークインターフェース間のネットワークパスを識別します。このパターンでは、 が管理する組織 AWS アカウント 内の一元化された にソリューションをデプロイし AWS Organizations、組織 AWS リージョン内のすべてのアカウントを分析します。 このソリューションは、以下を念頭に置いて設計されました。 + AWS CloudFormation テンプレートは、このパターンで AWS リソースをデプロイするために必要な労力を削減します。 + デプロイ時に CloudFormation テンプレートのパラメータと **naa-script.sh** スクリプトのパラメータを調整することで、環境に合わせてカスタマイズできます。 + Bash スクリプトは、複数のアカウントのネットワークアクセススコープをパラレルで自動的にプロビジョニングして分析します。 + Python スクリプトは検出結果を処理し、データを抽出し、結果を統合します。Network Access Analyzer 検出結果の統合レポートを CSV 形式で確認するか、 AWS Security Hub CSPMで確認するかを選択できます。CSV レポートの例はこのパターンの「[追加情報](#create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-additional)」セクションにあります。 + 検出結果を修正することも、**naa-exclusions.csv** ファイルに追加して今後の分析から除外することもできます。 ## 前提条件と制限 **前提条件** + 組織のメンバーアカウントとして管理されるセキュリティサービスとツールをホスト AWS アカウント するための AWS Organizations。このパターンでは、このアカウントはセキュリティアカウントと呼ばれています。 + セキュリティアカウントには、アウトバウンドのインターネットにアクセスできるプライベートサブネットが必要です。手順については、「Amazon VPC のドキュメント」の「[サブネットの作成](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html)」を参照してください。「[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)」または「[インターフェイスVPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」を使用してインターネットアクセスを確立できます。 + CloudFormation の管理者権限を委任された AWS Organizations 管理アカウントまたはアカウントへのアクセス。手順については、「CloudFormation のドキュメント」の「[委任管理者の登録](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html)」を参照してください。 + AWS Organizations と CloudFormation 間の信頼されたアクセスを有効にします。手順については、「CloudFormation ドキュメント」の「[ 信頼できるアクセスを有効にする AWS Organizations](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html)」を参照してください。 + Security Hub CSPM に結果をアップロードする場合は、アカウントと Amazon EC2 インスタンスがプロビジョニングされている AWS リージョン 場所で Security Hub CSPM を有効にする必要があります。詳細については、「[セットアップ AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html)」を参照してください。 **制限事項** + Network Access Analyzer 機能の制限により、クロスアカウントネットワークパスは現在分析されていません。 + ターゲットは の組織として管理 AWS アカウント する必要があります AWS Organizations。を使用していない場合は AWS Organizations、環境の **naa-execrole.yaml** CloudFormation テンプレートと **naa-script.sh** スクリプトを更新できます。代わりに、スクリプトを実行する AWS アカウント IDs とリージョンのリストを指定します。 + CloudFormation テンプレートは、アウトバウンドインターネットアクセスを持つプライベートサブネットに Amazon EC2 インスタンスをデプロイするように設計されています。 AWS Systems Manager エージェント (SSM エージェント) は、Systems Manager サービスエンドポイントに到達するためにアウトバウンドアクセスを必要とし、コードリポジトリのクローンを作成して依存関係をインストールするにはアウトバウンドアクセスが必要です。パブリックサブネットを使用する場合は、**naa-resources.yaml** テンプレートを変更して [Elastic IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)を Amazon EC2 インスタンスに関連付ける必要があります。 ## アーキテクチャ **ターゲットアーキテクチャ** オプション 1: Amazon S3 バケットの検出結果にアクセス ![\[Amazon S3 バケット内のNetwork Access Analyzerの検出結果レポートにアクセスするためのアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/d0b08437-e5b0-47a1-abdd-040c67b5da8f.png) 図表に示す内容は以下のステップです。 1. ソリューションを手動で実行する場合、ユーザーは Session Manager を使用して Amazon EC2 インスタンスへの認証を行い、次に **naa-script.sh** スクリプトを実行します。このシェルスクリプトはステップ 2～7 を実行します。 ソリューションを自動的に実行する場合、**naa-script.sh** スクリプトは cron 式で定義したスケジュールで自動的に開始されます。このシェルスクリプトはステップ 2 ～ 7 を実行します。詳細については、このセクションの最後にある「*自動化とスケール*」を参照してください。 1. Amazon EC2 インスタンスは Amazon S3 バケットから最新の **naa-exception.csv** ファイルをダウンロードします。このファイルは、プロセスの後半で Python スクリプトが除外を処理するときに使用されます。 1. Amazon EC2 インスタンスは `NAAEC2Role` AWS Identity and Access Management (IAM) ロールを引き受けます。これにより、Amazon S3 バケットにアクセスし、組織内の他のアカウントの `NAAExecRole` IAM ロールを引き受けるアクセス許可が付与されます。 1. Amazon EC2 インスタンスは、組織の管理アカウントの `NAAExecRole` IAM ロールを引き受け、組織内のアカウントのリストを生成します。 1. Amazon EC2 インスタンスは、組織のメンバーアカウント (アーキテクチャ図では*ワークロードアカウント*と記載) の `NAAExecRole` IAM ロールを引き受け、各アカウントのセキュリティ評価を実行します。検出結果は Amazon EC2 インスタンスに JSON ファイルとして保存されます。 1. Amazon EC2 インスタンスは Python スクリプトを使用して JSON ファイルを処理、データフィールドを抽出し、CSV レポートを作成します。 1. Amazon EC2 インスタンスは、Amazon S3 バケットに CSV ファイルをアップロードします。 1. Amazon EventBridge ルールはファイルのアップロードを検出し、Amazon SNS トピックを使用して、レポートが完了したことをユーザーに通知メールを送信します。 1. ユーザーは Amazon S3 バケットから CSV ファイルをダウンロードします。ユーザーはその結果を Excel テンプレートにインポートし、結果を確認します。 *オプション 2: で検出結果にアクセスする AWS Security Hub CSPM* ![\[AWS Security Hub からNetwork Access Analyzerの検出結果にアクセスするアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/9cb4f059-dfb6-4a33-9f8d-159fe5df0d64.png) 図に示す内容は以下のとおりです。 1. ソリューションを手動で実行する場合、ユーザーは Session Manager を使用して Amazon EC2 インスタンスへの認証を行い、次に **naa-script.sh** スクリプトを実行します。このシェルスクリプトはステップ 2～7 を実行します。 ソリューションを自動的に実行する場合、**naa-script.sh** スクリプトは cron 式で定義したスケジュールで自動的に開始されます。このシェルスクリプトはステップ 2 ～ 7 を実行します。詳細については、このセクションの最後にある「*自動化とスケール*」を参照してください。 1. Amazon EC2 インスタンスは Amazon S3 バケットから最新の **naa-exception.csv** ファイルをダウンロードします。このファイルは、プロセスの後半で Python スクリプトが除外を処理するときに使用されます。 1. Amazon EC2 インスタンスは `NAAEC2Role` IAM ロールを引き受け、Amazon S3 バケットにアクセスし、組織内の他のアカウントの `NAAExecRole` IAM 役割を引き受ける権限を付与します。 1. Amazon EC2 インスタンスは、組織の管理アカウントの `NAAExecRole` IAM ロールを引き受け、組織内のアカウントのリストを生成します。 1. Amazon EC2 インスタンスは、組織のメンバーアカウント (アーキテクチャ図では*ワークロードアカウント*と記載) の `NAAExecRole` IAM ロールを引き受け、各アカウントのセキュリティ評価を実行します。検出結果は Amazon EC2 インスタンスに JSON ファイルとして保存されます。 1. Amazon EC2 インスタンスは Python スクリプトを使用して JSON ファイルを処理し、Security Hub CSPM にインポートするためのデータフィールドを抽出します。 1. Amazon EC2 インスタンスは、Network Access Analyzer の検出結果を Security Hub CSPM にインポートします。 1. Amazon EventBridge ルールはインポートを検出し、Amazon SNS トピックで処理が完了したことをユーザーに通知メールを送信します。 1. ユーザーは Security Hub CSPM で検出結果を表示します。 **自動化とスケール** **naa-script.sh** スクリプトをカスタムスケジュールで自動的に実行するように、このソリューションをスケジュールできます。カスタムスケジュールを設定するには、**naa-resources.yaml** の CloudFormation テンプレートで `CronScheduleExpression` パラメータを変更します。たとえば、`0 0 * * 0` のデフォルト値は、ソリューションを毎週日曜日の深夜0時に実行します。 の値は、ソリューションを毎月第 1 日曜日の午前 0 時に実行します。`0 0 * 1-12 0`cron 式の使用に関する詳細は、「Systems Manager のドキュメント」の「[cron 式とrate 式](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html)」を参照してください。 `NAA-Resources` スタックのデプロイ後にスケジュールを調整したい場合は、`/etc/cron.d/naa-schedule` で cron スケジュールを手動で編集できます。 ## ツール **AWS のサービス** + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を認可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。 + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) は、 のセキュリティ状態の包括的なビューを提供します AWS。また、セキュリティ業界標準とベストプラクティスに照らして AWS 環境を確認するのにも役立ちます。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + 「[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)」は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。このパターンは、システムマネージャーの機能である「Session Manager」 を使用します。 コードリポジトリ このパターンのコードは、GitHub 内の「[Network Access Analyzer マルチアカウント分析](https://github.com/aws-samples/network-access-analyzer-multi-account-analysis)」リポジトリで利用できます。コードリポジトリには、以下のファイルが含まれます。 + **naa-script.sh** – この bash スクリプトは AWS アカウント、複数の Network Access Analyzer 分析を並行して開始するために使用されます。**naa-resources.yaml** の CloudFormation テンプレートで定義されているように、このスクリプトは Amazon EC2 インスタンスの `/usr/local/naa` フォルダに自動的にデプロイされます。 + **naa-resources.yaml** – この CloudFormation テンプレートを使用して、組織のセキュリティアカウントにスタックを作成します。このテンプレートは、ソリューションをサポートするためにこのアカウントに必要なリソースをすべてデプロイします。このスタックは **naa-execrole.yaml** テンプレートの前にデプロイする必要があります。 **注記** このスタックを削除して再デプロイした場合、IAM ロール間のクロスアカウント依存関係を再構築するために `NAAExecRole` スタックセットを再構築する必要があります。 + **naa-execrole.yaml** – この CloudFormation テンプレートを使用して、管理アカウントを含む組織内のすべてのアカウントに `NAAExecRole` IAM ロールをデプロイするスタックセットを作成します。 + **naa-processfindings.py** – **naa-script.sh **スクリプトは、この Python スクリプトを自動的に呼び出して Network Access Analyzer JSON 出力を処理し、**naa-exclusions.csv** ファイル内の既知の正常なリソースを除外してから、統合結果の CSV ファイルを生成するか、結果を Security Hub CSPM にインポートします。 ## エピック ### デプロイの準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コードリポジトリを複製します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | テンプレートを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ### CloudFormation スタックの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | セキュリティアカウントにリソースをプロビジョニングします。 | **naa-resources.yaml** テンプレートを使用して、セキュリティアカウントに必要なすべてのリソースをデプロイする CloudFormation スタックを作成します。手順については、「CloudFormation のドキュメント」の「[スタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。このテンプレートを展開する際には、次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | メンバーアカウントで IAM ロールをプロビジョニングします。 | AWS Organizations 管理アカウントまたは CloudFormation の委任管理者権限を持つアカウントで、**naa-execrole.yaml** テンプレートを使用して CloudFormation スタックセットを作成します。スタックセットは、組織内のすべてのメンバーアカウントに `NAAExecRole` IAM ロールをデポロイします。手順については、CloudFormation ドキュメントの「[サービスマネージド型のアクセス許可を持つスタックセットの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-getting-started-create.html#stacksets-orgs-associate-stackset-with-org)」を参照してください。このテンプレートを展開する際には、次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | 管理アカウントで IAM ロールをプロビジョニングします。 | **naa-execrole.yaml** テンプレートを使用して、組織の管理アカウントに `NAAExecRole` IAM ロールをデプロイする CloudFormation スタックを作成します。以前に作成したスタックセットでは、管理アカウントに IAM ロールはデプロイされません。手順については、「CloudFormation ドキュメント」の「[スタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。このテンプレートを展開する際には、次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ### 分析の実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | シェルスクリプトをカスタマイズします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | ターゲットアカウントを分析します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | オプション 1 – Amazon S3 バケットから結果を取得します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | オプション 2 – Security Hub CSPM の結果を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ### 検出結果の修正と除外 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 検出結果を修正します。 | 組織の管理アカウントにIAMロールをデプロイするCloudFormationスタックを作成しました。 AWS ID、リソース、ネットワークの周囲に境界を作成する方法の詳細とベストプラクティスについては、「 [でのデータ境界の構築 AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) (AWS ホワイトペーパー）」を参照してください。 | AWS DevOps | | ネットワークパスが正常であることがわかっているリソースを除きます。 | Network Access Analyzer がインターネットからアクセスできるはずのリソースに関する検出結果を生成した場合、それらのリソースを除外リストに追加できます。今度、Network Access Analyzerを実行しても、そのリソースの検出結果は生成されません。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ### (オプション)［naa-script.sh］スクリプトを更新します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | [naa-script.sh] スクリプトを更新します。 | **naa-script.sh** スクリプトをリポジトリ内の最新バージョンに更新するには、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ### (オプション) クリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイされたリソースをすべて削除します。 | リソースはアカウントにデプロイしたままにしておくことができます。すべてのリソースのプロビジョニングを解除する場合は、以下のように実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Session Manager を使用して Amazon EC2 インスタンスに接続できません。 | SSM エージェントは、Systems Manager エンドポイントと通信できる必要があります。以下の操作を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | | スタックセットをデプロイすると、CloudFormation コンソールに `Enable trusted access with AWS Organizations to use service-managed permissions` を求めるメッセージが表示されます。 | これは、 AWS Organizations と CloudFormation の間で信頼されたアクセスが有効になっていないことを示します。サービスマネージド型のスタックセットをデプロイするには、信頼されたアクセスが必要です。このボタンを選択すると、信頼されたアクセスは有効になります。詳細については、「CloudFormation ドキュメント」の「[信頼されたアクセスの有効化](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html)」を参照してください。 | ## 関連リソース + [新規 – Amazon VPC Network Access Analyzer](https://aws.amazon.com/blogs/aws/new-amazon-vpc-network-access-analyzer/) (AWS ブログ記事) + [AWS re:Inforce 2022 - での効果的なネットワークアクセスコントロールの検証 AWS (NIS202)](https://youtu.be/aN2P2zeQek0) (ビデオ) + 「[デモ- Network Access Analyzer を使用した組織全体のインターネット進入データパス分析](https://youtu.be/1IFNZWy4iy0)」 (ビデオ) ## 追加情報 コンソール出力の例 次のサンプルは、ターゲットアカウントのリストを生成し、ターゲットアカウントを分析した出力を示しています。 ``` [root@ip-10-10-43-82 naa]# ./naa-script.sh download: s3://naa--us-east-1/naa-exclusions.csv to ./naa-exclusions.csv AWS Management Account: AWS Accounts being processed... Assessing AWS Account: , using Role: NAAExecRole Assessing AWS Account: , using Role: NAAExecRole Assessing AWS Account: , using Role: NAAExecRole Processing account: / Region: us-east-1 Account: / Region: us-east-1 – Detecting Network Analyzer scope... Processing account: / Region: us-east-1 Account: / Region: us-east-1 – Detecting Network Analyzer scope... Processing account: / Region: us-east-1 Account: / Region: us-east-1 – Detecting Network Analyzer scope... Account: / Region: us-east-1 – Network Access Analyzer scope detected. Account: / Region: us-east-1 – Continuing analyses with Scope ID. Accounts with many resources may take up to one hour Account: / Region: us-east-1 – Network Access Analyzer scope detected. Account: / Region: us-east-1 – Continuing analyses with Scope ID. Accounts with many resources may take up to one hour Account: / Region: us-east-1 – Network Access Analyzer scope detected. Account: / Region: us-east-1 – Continuing analyses with Scope ID. Accounts with many resources may take up to one hour ``` CSV レポートの例 以下の画像は CSV 出力の例です。 ![\[このソリューションにより生成された CSV レポートの例 1。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/55e02e61-054e-4da6-aaae-c9a8b6f4f272.png) ![\[このソリューションにより生成された CSV レポートの例 2。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/95f980ad-92c1-4392-92d4-9c742755aab2.png) # マルチアカウント AWS 環境でハイブリッドネットワークの DNS 解決を設定する *Anvesh Koganti、Amazon Web Services* ## 概要 このパターンは、複数の Amazon Web Services (AWS) アカウントを含むハイブリッドネットワーク環境で DNS 解決を設定するための包括的なソリューションを提供します。これにより、エンドポイントを介してオンプレミスネットワークと AWS 環境間の双方向 DNS 解決が可能になります Amazon Route 53 Resolver 。このパターンは、[マルチアカウントで一元化されたアーキテクチャ](https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/scaling-dns-management-across-multiple-accounts-and-vpcs.html#multi-account-centralized)で DNS 解決を可能にする 2 つのソリューションを示しています。 + *基本セットアップ*では Route 53 プロファイルを使用しません。これにより、あまり複雑でない中小規模のデプロイのコストを最適化できます。 + *高度なセットアップ*では、Route 53 プロファイルを使用してオペレーションを簡素化します。より大規模な、または複雑な DNS デプロイに最適です。 **注記** 実装する前に、「*制限事項*」セクションでサービスの制限とクォータを確認してください。決定するときは、管理のオーバーヘッド、コスト、運用の複雑さ、チームの専門知識などの要因を考慮してください。 ## 前提条件と制限事項 **前提条件** + 共有サービスとワークロードアカウント全体にデプロイされた Amazon Virtual Private Cloud (Amazon VPC) を使用する AWS マルチアカウント環境 (アカウント構造の[AWS ベストプラクティスに従って AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) を介してセットアップすることをお勧めします）。 + オンプレミスネットワークと AWS 環境間の既存のハイブリッド接続 (AWS Direct Connect または AWS Site-to-Site VPN)。 + Amazon VPC ピアリング AWS Transit Gateway、または VPCs AWS クラウド 間のレイヤー 3 ネットワーク接続用の WAN。(この接続はアプリケーショントラフィックに必要です。DNS 解決が機能するためには必要ありません。DNS 解決は VPC 間のネットワーク接続を独立して操作します。) + オンプレミス環境で実行されている DNS サーバー。 **制限事項** + Route 53 Resolver のエンドポイント、ルール、プロファイルはリージョン構造であり、グローバル組織 AWS リージョン では複数の でレプリケーションが必要になる場合があります。 + Route 53 Resolver、プライベートホストゾーン、およびプロファイルの Service Quotas の包括的なリストについては、Route 53 ドキュメントの「[クォータ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DNSLimitations.html)」を参照してください。 ## アーキテクチャ **ターゲットテクノロジースタック** + Route 53 アウトバウンドエンドポイントとインバウンドエンドポイント + 条件付き転送用の Route 53 Resolver ルール + AWS Resource Access Manager (AWS RAM) + Route 53 プライベートホストゾーン **ターゲットアーキテクチャ** **アウトバウンドエンドポイントとインバウンドエンドポイント** 次の図は、 からオンプレミス AWS への DNS 解決フローを示しています。これは、ドメインがオンプレミスでホストされているアウトバウンド解決の接続設定です。この設定に関連するプロセスの概要を次に示します。詳細については、「[エピック](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-epics)」セクションを参照してください。 1. アウトバウンド Route 53 Resolver エンドポイントを共有サービス VPC にデプロイします。 1. オンプレミスでホストされているドメインの共有サービスアカウントに Route 53 Resolver ルール (転送ルール) を作成します。 1. オンプレミスのホストドメインを解決する必要があるリソースをホストする他のアカウントの VPC とルールを共有して関連付けます。これは、このセクションで後述するように、ユースケースに応じてさまざまな方法で行うことができます。 ![\[AWS のインバウンドエンドポイントとアウトバウンドエンドポイントからオンプレミス DNS 解決へのフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/d69d4cad-5e2c-4481-9370-2708e8a4f8c1.png) 接続を設定した後の、アウトバウンド解決に関連するステップは次のとおりです。 1. Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは、`db.onprem.example.com` の DNS 解決リクエストを VPC\$12 アドレスの VPC の Route 53 Resolver に送信します。 1. Route 53 Resolver は Resolver ルールをチェックし、アウトバウンドエンドポイントを使用してリクエストをオンプレミス DNS サーバー IP に転送します。 1. アウトバウンドエンドポイントは、リクエストをオンプレミス DNS IP に転送します。トラフィックは、共有サービス VPC とオンプレミスデータセンター間の確立されたハイブリッドネットワーク接続を経由します。 1. オンプレミス DNS サーバーはアウトバウンドエンドポイントに応答し、VPC の Route 53 Resolver に応答を転送します。Resolver は EC2 インスタンスに応答を返します。 次の図は、オンプレミス環境から への DNS 解決フローを示しています AWS。これは、ドメインが AWSでホストされているインバウンド解決の接続設定です。この設定に関連するプロセスの概要を次に示します。詳細については、「[エピック](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-epics)」セクションを参照してください。 1. インバウンド Resolver エンドポイントを共有サービス VPC にデプロイします。 1. 共有サービスアカウントにプライベートホストゾーンを作成します (一元的アプローチ)。 1. プライベートホストゾーンを共有サービス VPC に関連付けます。これらのゾーンを共有し、VPC 間の DNS 解決用のクロスアカウント VPC と関連付けます。これは、このセクションで後述するように、ユースケースに応じてさまざまな方法で行うことができます。 ![\[オンプレミスのインバウンドエンドポイントとアウトバウンドエンドポイントから AWS DNS 解決へのフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/a6f5348c-2041-453e-8939-2b4ee0b7ebd8.png) 接続を設定した後の、インバウンド解決に関連するステップは次のとおりです。 1. オンプレミスリソースは、`ec2.prod.aws.example.com` の DNS 解決リクエストをオンプレミス DNS サーバーに送信します。 1. オンプレミス DNS サーバーは、ハイブリッドネットワーク接続を介して共有サービス VPC 内のインバウンド Resolver エンドポイントにリクエストを転送します。 1. インバウンド Resolver エンドポイントは、VPC Route 53 Resolver による解決によって、関連するプライベートホストゾーンでリクエストを検索し、適切な IP アドレスを取得します。 1. これらの IP アドレスはオンプレミス DNS サーバーに返され、オンプレミスリソースに応答が返されます。 この設定により、オンプレミスリソースは、インバウンドエンドポイントを介して適切な AWS プライベートホストゾーンにクエリをルーティングすることで、プライベートドメイン名を解決できます。このアーキテクチャでは、プライベートホストゾーンは共有サービス VPC に一元化されるため、単一のチームによる一元的な DNS 管理が可能になります。これらのゾーンは、VPC 間の DNS 解決のユースケースに対応するために、多くの VPC に関連付けることができます。または、それぞれに DNS ドメインの所有権と管理を委任することもできます AWS アカウント。この場合、各アカウントは独自のプライベートホストゾーンを管理し、各ゾーンを中央共有サービス VPC に関連付けて、オンプレミス環境との統合解決を行います。この分散型アプローチは、このパターンの範囲外です。詳細については、「*Hybrid Cloud DNS Options for Amazon VPC*」ホワイトペーパーの「[Scaling DNS management across multiple accounts and VPCs](https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/scaling-dns-management-across-multiple-accounts-and-vpcs.html)」を参照してください。 Resolver エンドポイントを使用して基本的な DNS 解決フローを確立する場合は、 AWS アカウント全体で Resolver ルールとプライベートホストゾーンの共有と関連付けを管理する方法を決定する必要があります。これは 2 つの方法でアプローチできます。*基本セットアップ*セクションで説明されているように、 AWS RAM を使用してリゾルバールールを共有し、プライベートホストゾーンの関連付けをダイレクトすることでセルフマネージド共有する方法と、*拡張セットアップ*セクションで説明されているように Route 53 プロファイルする方法です。どちらを選択するかは、組織の DNS 管理設定と運用要件によって異なります。次のアーキテクチャ図は、異なるアカウントにまたがる複数の VPC を含むスケーリングされた環境を示しています。これは、一般的なエンタープライズデプロイを表しています。 **基本的なセットアップ** 基本的なセットアップでは、マルチアカウント AWS 環境でのハイブリッド DNS 解決の実装では、 を使用して Resolver 転送ルールとプライベートホストゾーンの関連付け AWS RAM を共有し、オンプレミスと AWS リソース間の DNS クエリを管理します。この方法では、オンプレミスネットワークに接続された共有サービス VPC 内の一元化された Route 53 Resolver エンドポイントを使用して、インバウンドとアウトバウンド両方の DNS 解決を効率的に処理します。 + アウトバウンド解決の場合、リゾルバー転送ルールは共有サービスアカウントで作成され、 を使用して他の と共有 AWS アカウント されます AWS RAM。この共有は、同じリージョン内のアカウントに限定されます。その後、ターゲットアカウントはこれらのルールを VPC に関連付け、それらの VPC 内のリソースを有効にしてオンプレミスドメイン名を解決できます。 + インバウンド解決の場合、プライベートホストゾーンは共有サービスアカウントに作成され、共有サービス VPC に関連付けられます。これらのゾーンは、Route 53 API、 AWS SDKs、または AWS Command Line Interface () を使用して、他のアカウントの VPCs に関連付けることができますAWS CLI。関連付けられた VPCs のリソースは、プライベートホストゾーンで定義された DNS レコードを解決できます。これにより、 AWS 環境全体で統一された DNS ビューが作成されます。 次の図は、この基本セットアップの DNS 解決フローを示しています。 ![\[マルチアカウントの AWS 環境でハイブリッド DNS 解決に基本セットアップを使用します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/258e4bcd-e9c6-43b5-bab8-856ca22206b9.png) この設定は、限られた規模で DNS インフラストラクチャを操作する場合に適しています。ただし、環境が大きくなるにつれて、管理が難しくなる可能性があります。プライベートホストゾーンと Resolver ルールを共有し、VPC と個別に関連付ける方法を管理する際に発生する運用オーバーヘッドは、スケールとともに大幅に増加します。さらに、プライベートホストゾーンあたり 300 VPC の関連付け制限などの Service Quotas は、大規模なデプロイで制約要因になる可能性があります。高度なセットアップは、これらの課題に対処します。 **高度なセットアップ** Route 53 プロファイルは、複数の AWS アカウントにまたがるハイブリッドネットワークの DNS 解決を管理するために合理化されたソリューションを提供します。プライベートホストゾーンと Resolver ルールを個別に管理する代わりに、DNS 設定を 1 つのコンテナにグループ化します。これは、リージョン内の複数の VPC とアカウント間で簡単に共有および適用できます。このセットアップでは、DNS 設定の管理を大幅に簡素化しながら、一元化された Resolver エンドポイントアーキテクチャを共有サービス VPC で維持します。 次の図は、高度なセットアップの DNS 解決フローを示しています。 ![\[マルチアカウントの AWS 環境でハイブリッド DNS 解決に Route 53 プロファイルを使用する高度なセットアップを使用します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/55b9681d-ddb4-4a55-b4ec-fc9afa9870fa.png) Route 53 プロファイルを使用すると、プライベートホストゾーンの関連付け、Resolver 転送ルール、DNS ファイアウォールルールを 1 つの共有可能なユニットにパッケージ化できます。共有サービスアカウントでプロファイルを作成し、 を使用してメンバーアカウントと共有できます AWS RAM。プロファイルを共有してターゲット VPC に適用すると、必要なすべての関連付けと設定がサービスによって自動的に処理されます。これにより、DNS 管理の運用オーバーヘッドが大幅に削減され、拡大する環境に優れたスケーラビリティが提供されます。 **自動化とスケール** CloudFormation や Terraform などの Infrastructure as Code (IaC) ツールを使用して、Route 53 Resolver エンドポイント、ルール、プライベートホストゾーン、プロファイルを自動的にプロビジョニングおよび管理します。DNS 設定を継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインと統合して、一貫性、再現性、迅速な更新を実現します。 ## ツール **AWS のサービス** + [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) は、 間でリソースを安全に共有 AWS アカウント し、運用オーバーヘッドを削減し、可視性と監査性を提供します。 + [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) はリソースからの DNS クエリに再帰的に応答 AWS し、デフォルトですべての VPCsで使用できます。Resolver エンドポイントと条件付き転送ルールを作成して、オンプレミスデータセンターと VPC の間の DNS 名前空間を解決できます。 + [Amazon Route 53 プライベートホストゾーン](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)は、ドメインとそのサブドメインへの DNS クエリに対し、Route 53 がどのように応答するかに関する情報を保持するコンテナです。 + [Amazon Route 53 プロファイル](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html)を使用すると、DNS 関連の Route 53 設定 AWS アカウント を多くの VPCsおよび管理できます。 ## ベストプラクティス このセクションでは、Route 53 Resolver を最適化するためのベストプラクティスについていくつか説明します。これらは Route 53 のベストプラクティスのサブセットを表します。包括的なリストについては、「[Amazon Route 53 のベストプラクティス](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices.html)」を参照してください。 **Resolver エンドポイントでのループ設定の回避** + 再帰的なルーティングを防ぐため、VPC の関連付けを慎重に計画して DNS アーキテクチャを設計してください。VPC がインバウンドエンドポイントをホストする場合は、循環参照を作成できる Resolver ルールに関連付けないでください。 + アカウント間で DNS リソースを共有する場合は、クリーンルーティングパスを維持するために AWS RAM 戦略的に を使用します。 詳細については、Route 53 ドキュメントの「[Resolver エンドポイントを使用した設定のループを回避する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver-endpoints.html)」を参照してください。 **Resolver エンドポイントのスケーリング** + 1 秒あたりのクエリ数 (QPS) が多い環境では、エンドポイントで ENI あたり 10,000 QPS の制限があることに注意してください。DNS QPS をスケールするために、エンドポイントにさらに ENI を追加できます。 + Amazon CloudWatch は `InboundQueryVolume` および `OutboundQueryVolume` メトリクスを提供します ([CloudWatch ドキュメント](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html)を参照してください)。しきい値が特定の値 (10,000 QPS の 80% など) を超えた場合に警告するモニタリングルールを設定することをお勧めします。 + Resolver エンドポイントのステートフルセキュリティグループルールを設定して、大量のトラフィックが発生している最中に接続追跡制限によって DNS クエリスロットリングが発生しないようにします。セキュリティグループでの接続追跡の仕組みに関する詳細は、Amazon EC2 ドキュメントの「[Amazon EC2 セキュリティグループの接続の追跡](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)」を参照してください。 詳細については、Route 53 ドキュメントの「[Resolver エンドポイントのスケーリング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver-endpoint-scaling.html)」を参照してください。 **Resolver エンドポイントの高可用性を提供する** + 冗長性を確保するために、少なくとも 2 つのアベイラビリティーゾーンに IP アドレスを持つインバウンドエンドポイントを指定します。 + メンテナンスやトラフィックの急増時に可用性を確保するための追加のネットワークインターフェイスをプロビジョニングします。 詳細については、Route 53 ドキュメントの「[Resolver エンドポイントの高可用性](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver-endpoint-high-availability.html)」を参照してください。 ## エピック ### Route 53 Resolver エンドポイントをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インバウンドエンドポイントをデプロイします。 | Route 53 Resolverはインバウンド エンドポイントを使用して、DNS クエリをオンプレミスネットワークから Route 53 Resolver に転送します。手順については、Route 53 ドキュメントの「[VPC へのインバウンド DNS クエリの転送](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html)」 を参照してください。受信エンドポイント IP アドレスをメモしておきます。 | AWS 管理者、クラウド管理者 | | アウトバウンドエンドポイントをデプロイします。 | Route 53 Resolver は、アウトバウンドエンドポイントを使用して DNS クエリをオンプレミスの DNS レゾルバ に送信します。手順については、Route 53 ドキュメントの「[アウトバウンド DNS クエリのネットワークへの転送](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-outbound-queries.html)」 を参照してください。出力エンドポイント ID を書きとめておきます。 | AWS 管理者、クラウド管理者 | ### Route 53 プライベートホストゾーンを設定および共有する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWSでホストされているドメインのプライベートホストゾーンを作成します。 | このゾーンは、オンプレミス環境から解決する必要がある AWSホストドメイン ( など`prod.aws.example.com`) 内のリソースの DNS レコードを保持します。手順については、Route 53 ドキュメントの「[プライベートホストゾーンの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-creating.html)」を参照してください。プライベートホストゾーンを作成するときは、VPC を同じアカウントが所有するホストゾーンに関連付ける必要があります。このために共有サービス VPC を選択します。 | AWS 管理者、クラウド管理者 | | 基本セットアップ: プライベートホストゾーンを他のアカウントの VPC に関連付けます。 | 基本セットアップを使用している場合 (「[アーキテクチャ](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-architecture)」セクションを参照):メンバーアカウント VPC のリソースが、このプライベートホストゾーンの DNS レコードを解決できるようにするには、VPC をホストゾーンに関連付ける必要があります。関連付けを承認してから、プログラムで関連付けを作成する必要があります。手順については、Route 53 ドキュメントの「[Amazon VPC を異なる AWS アカウントで作成したプライベートホストゾーンに関連付ける](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html)」を参照してください。 | AWS 管理者、クラウド管理者 | | 高度なセットアップ: Route 53 プロファイルを設定および共有します。 | 高度なセットアップを使用している場合 (「[アーキテクチャ](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-architecture)」セクションを参照):[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.html)組織の構造と DNS 要件によっては、異なるアカウントまたはワークロードに対して複数のプロファイルを作成および管理する必要がある場合があります。 | AWS 管理者、クラウド管理者 | ### Route 53 Resolver 転送ルールを設定して共有する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オンプレミスでホストされているドメインの転送ルールを作成します。 | このルールは、オンプレミスドメイン (`onprem.example.com` など) の DNS クエリを、すべてオンプレミスの DNS Resolver に転送するよう Route 53 Resolver に指示します。このルールを作成するには、オンプレミスの DNS Resolver の IP アドレスとアウトバウンドエンドポイント ID が必要です。手順については、Route 53 ドキュメントの 「[転送ルールの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing-creating-rules.html)」 を参照してください。 | AWS 管理者、クラウド管理者 | | 基本セットアップ: 転送ルールを共有し、他のアカウントの VPC に関連付けます。 | 基本セットアップを使用している場合:転送ルールを有効にするには、ルールを共有して、他のアカウントの VPC に関連付ける必要があります。その後、Route 53 Resolver はドメインを解決する際にルールを考慮します。手順については、Route 53 ドキュメントの「[Resolver ルール AWS アカウント を他の と共有ルールを使用する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing-sharing.html)[」および「転送ルールを VPC に関連付ける](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing-associating-rules.html)」を参照してください。 | AWS 管理者、クラウド管理者 | | 高度なセットアップ: Route 53 プロファイルを設定および共有します。 | 高度なセットアップを使用している場合:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.html)組織の構造と DNS 要件によっては、異なるアカウントまたはワークロードに対して複数のプロファイルを作成および管理する必要がある場合があります。 | AWS 管理者、クラウド管理者 | ### AWS 統合用にオンプレミス DNS リゾルバーを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オンプレミスの DNS Resolver で条件付き転送を設定します。 | 解決のためにオンプレミス環境 AWS から に DNS クエリを送信するには、インバウンドエンドポイント IP アドレスを指すようにオンプレミス DNS リゾルバーで条件付き転送を設定する必要があります。これにより、DNS リゾルバーは、Route AWS 53 Resolver による解決のために、ホストされたドメインのすべての DNS クエリ ( の場合など`prod.aws.example.com`) をインバウンドエンドポイント IP アドレスに転送するように指示されます。 | ネットワーク管理者 | ### ハイブリッド環境でエンドツーエンドの DNS 解決を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | からオンプレミス環境 AWS への DNS 解決をテストします。 | 転送ルールが関連付けられている VPC 内のインスタンスから、オンプレミスホストドメイン (`db.onprem.example.com` の場合など) の DNS クエリを実行します。 | ネットワーク管理者 | | オンプレミス環境から への DNS 解決をテストします AWS。 | オンプレミスサーバーから、ホストされたドメイン ( の場合は など`ec2.prod.aws.example.com`) AWSの DNS 解決を実行します。 | ネットワーク管理者 | ## 関連リソース + [Amazon VPC のハイブリッドクラウド DNS オプション](https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/hybrid-cloud-dns-options-for-vpc.html) (AWS ホワイトペーパー) + [Working with private hosted zones](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) (Route 53 ドキュメント) + [Getting started with Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html) (Route 53 ドキュメント) + [Route 53 Resolver を使用してマルチアカウント環境で DNS 管理を簡素化](https://aws.amazon.com/blogs/security/simplify-dns-management-in-a-multiaccount-environment-with-route-53-resolver/)する (AWS ブログ記事) + [Amazon Route 53 Profiles と複数の VPCs を使用して DNS 管理を統合する ( AWS アカウント](https://aws.amazon.com/blogs/aws/unify-dns-management-using-amazon-route-53-profiles-with-multiple-vpcs-and-aws-accounts/)AWS ブログ記事) + [マルチアカウント DNS 環境を Amazon Route 53 Profiles に移行する](https://aws.amazon.com/blogs/networking-and-content-delivery/migrating-your-multi-account-dns-environment-to-amazon-route-53-profiles/) (AWS ブログ記事) + [スケーラブルなマルチアカウント AWS 環境での Amazon Route 53 プロファイルの使用](https://aws.amazon.com/blogs/networking-and-content-delivery/using-amazon-route-53-profiles-for-scalable-multi-account-aws-environments/) (AWS ブログ記事)   # ELB ロードバランサーに TLS 終了が必要であることを確認 *Amazon Web Services、Priyanka Chaudhary* ## 概要 Amazon Web Services (AWS) クラウドでは、Elastic Load Balancing (ELB) が、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、IP アドレス、AWS Lambda 関数などの複数のターゲットにわたって受信したアプリケーショントラフィックを自動的に分散します。ロードバランサーはリスナーを使用して、ユーザーからトラフィックを受け入れるために、ロードバランサーが使用するポートとプロトコルを定義します。Application Load Balancer はアプリケーションレイヤーでルーティングを決定し、HTTP/HTTPS プロトコルを使用します。Classic Load Balancer は、TCP または Secure Sockets Layer (SSL) プロトコルを使用するトランスポート層、または HTTP/HTTPS を使用してアプリケーション層でルーティングを決定します。 パターンは、Application Load Balance と Classic Load Balancerの複数のイベントタイプを検査する、セキュリティ制御を提供します。関数が呼び出される場合、AWS Lambda はイベントを検査し、ロードバランサーが準拠していることを確認します。 この関数は、次のAPI呼び出しでAmazon CloudWatch Eventsを初期化します: 「[CreateLoadBalancer](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_CreateLoadBalancer.html)」 、「[CreateLoadBalancerListeners](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_CreateLoadBalancerListeners.html)」 、「[DeleteLoadBalancerListeners](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_DeleteLoadBalancerListeners.html)」 、「[CreateLoadBalancerPolicy](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_CreateLoadBalancerPolicy.html)」 、「[SetLoadBalancerPoliciesOfListener](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_SetLoadBalancerPoliciesOfListener.html)」 、「[CreateListener](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_CreateListener.html)」 、「[DeleteListener](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_DeleteListener.html)」 、及び「[ModifyListener](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ModifyListener.html)」 。イベントが3つの API のいずれかを検出する場合、Python スクリプトを実行する AWS Lambda を呼び出します。Python スクリプトは、リスナーに SSL 証明書が含まれているか、および適用されるポリシーがTransport Layer Security (TLS) を使用しているかを評価します。SSL ポリシーが TLS 以外であると判断された場合、関数から Amazon Simple Notification Service (Amazon SNS) 通知が関連の情報を持つユーザーに送信されます。  ## 前提条件と制限事項 **前提条件** + アクティブなAWS アカウント **機能制限 ** + このセキュリティコントロールでは、ロードバランサーリスナーが更新されない限り、既存のロードバランサーをチェックしません。 + このセキュリティ制御はリージョンごとに行われます。監視する AWS リージョンごとにデプロイする必要があります。 ## アーキテクチャ **ターゲットアーキテクチャ** ![\[ロードバランサーに TLS 終了が必要であることの確認。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/da99cda2-ac34-4791-a2bd-d37264d8d3d9/images/af92b3c8-32bb-45eb-a2a8-d8276fb3e824.png) **自動化とスケール** + [AWS Organizations](https://aws.amazon.com/organizations/) を使用している場合は、[AWS Cloudformation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) を使用して、モニタリングする複数のアカウントにこのテンプレートをデプロイできます。 ## ツール **AWS サービス** + 「[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)」 を使用することで、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクルの最初から最後までリソースを管理できます。リソースを個別に管理する代わりに、テンプレートを使用してリソースとその依存関係を記述し、それらをスタックとしてまとめて起動して設定できます。 + [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) – Amazon CloudWatch Events は、AWS リソースの変更を説明するシステムイベントのほぼリアルタイムのストリームを提供します。 + 「[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」 – AWS Lambda はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。 + 「[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)」 — Amazon Simple Storage Service (Amazon S3) は、拡張性の高いオブジェクトストレージサービスで、ウェブサイト、モバイルアプリケーション、バックアップ、データレイクなど、幅広いストレージソリューションに使用できます。 + [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) — Amazon Simple Notification Service (Amazon SNS) は、ウェブサーバーや E メールアドレスなど、パブリッシャーとクライアント間のメッセージ配信や送信を調整および管理します。サブスクライバーは、サブスクライブしているトピックに対して発行されたすべてのメッセージを受信します。また、同じトピックのサブスクライバーはすべて同じメッセージを受信します。 **コード** このパターンには、以下の添付ファイルが含まれます。 + `ELBRequirestlstermination.zip` — セキュリティコントロール用の Lambda コード。 + `ELBRequirestlstermination.yml` — イベントとLambda 関数をセットアップする CloudFormation テンプレート。 ## エピック ### S3 バケットのセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットを定義します。 | 「[Amazon S3 コンソール](https://console.aws.amazon.com/s3/)」 で、Lambda コードの .zip ファイルをホストする S3 バケットを選択、または作成します。この S3 バケットは、評価したいロードバランサーと同じ AWS リージョンに存在する必要があります。S3 バケット名はグローバルに一意であり、名前空間はすべての AWS アカウントによって共有されます。S3 バケット名には、先頭にスラッシュを含めることはできません。 | クラウドアーキテクト | | Lambda コードをアップロードします。 | *添付ファイル*セクションで提供されている Lambda コード (`ELBRequirestlstermination.zip` ファイル) を S3 バケットにアップロードします。 | クラウドアーキテクト | ### CloudFormation のテンプレートを入手するには | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation のテンプレートを起動します。 | S3 バケットと同じ 「[AWS リージョンで AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)」を開き、添付のテンプレート `ELBRequirestlstermination.yml` をデプロイします。AWS CloudFormation テンプレートのデプロイに関する詳細については、CloudFormation ドキュメントの「[AWS CloudFormation コンソールでのスタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。 | クラウドアーキテクト | | テンプレートのパラメータを入力します。 | テンプレートを起動すると、次の情報の入力を求められます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/verify-that-elb-load-balancers-require-tls-termination.html) | クラウドアーキテクト | ### サブスクリプションを確認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サブスクリプションを確認します。 | CloudFormation テンプレートが正常にデプロイされると、指定したメールアドレスにサブスクリプションメールが送信されます。違反通知の受信を開始するには、このメールサブスクリプションを確認する必要があります。 | クラウドアーキテクト | ## 関連リソース + 「[AWS CloudFormation コンソールでのスタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」 (AWS CloudFormation ドキュメント) + 「[AWS Lambda とは?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」 (AWS Lambda ドキュメント） + 「[Classic Load Balancer とは？](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html)」 (ELB ドキュメント) + 「[Application Load Balancer とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)」 (ELB ドキュメント) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/da99cda2-ac34-4791-a2bd-d37264d8d3d9/attachments/attachment.zip)」 # Splunk を使用して AWS Network Firewall のログとメトリクスを表示する *Amazon Web Services、Ivo Pinto* ## 概要 多くの組織は、さまざまなソースからのログとメトリクスを一元的に集約して可視化するツールとして [Splunk Enterprise](https://www.splunk.com/en_us/products/splunk-enterprise.html) を使用しています。このパターンは、Splunk Add-On for AWS を使用して [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) から [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) ログとメトリクスを取得するように Splunk を設定するのに役立ちます。  これを実現するには、読み取り専用の AWS Identity and Access Management (IAM) ロールを作成します。Splunk Add-On for AWS は、このロールを使用して CloudWatch にアクセスします。CloudWatch からメトリクスとログを取得するように Splunk Add-On for AWS を設定します。最後に、取得したログデータとメトリクスから Splunk で視覚化を作成します。 ## 前提条件と制限 **前提条件** + [Splunk](https://www.splunk.com/) アカウント + Splunk Enterprise インスタンス (バージョン 8.2.2 以降)  + アクティブな AWS アカウント + Network Firewall (CloudWatch Logs にログを送信するように[セットアップ](https://docs.aws.amazon.com/network-firewall/latest/developerguide/getting-started.html)および[設定](https://docs.aws.amazon.com/network-firewall/latest/developerguide/logging-cw-logs.html)済み) **制限事項** + Splunk Enterprise は、AWS クラウド内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのクラスターとしてデプロイする必要があります。 + 自動的に検出された Amazon EC2 の IAM ロールを使用したデータの収集は、AWS 中国リージョンではサポートされていません。 ## アーキテクチャ ![\[AWS Network Firewall と Splunk のロギングアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c6ce254a-841f-4bed-8f9f-b35e99f22e56/images/3dd420e9-70af-4a42-b24d-c54872c55e0b.png) この図表は、以下を示すものです: 1. Network Firewall は CloudWatch Logs にログを公開します。 1. Splunk Enterprise は CloudWatch からメトリクスとログを取得します。 このアーキテクチャのサンプルメトリクスとサンプルログを入力するために、ワークロードは Network Firewall エンドポイントを通過するトラフィックを生成してインターネットに移動します。これは、[ルートテーブル](https://docs.aws.amazon.com/network-firewall/latest/developerguide/vpc-config.html#vpc-config-route-tables)の使用によって実現されます。このパターンではワークロードとして単一の Amazon EC2 インスタンスを使用しますが、Network Firewall が CloudWatch Logs にログを送信するように設定されていれば、このパターンは任意のアーキテクチャに適用できます。 このアーキテクチャでは、別の仮想プライベートクラウド (VPC) の Splunk Enterprise インスタンスも使用します。ただし、Splunk インスタンスは、CloudWatch API に到達できる限り、ワークロードと同じ VPC など、別の場所に配置することもできます。 ## ツール **AWS サービス** + 「[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)」は、すべてのシステム、アプリケーション、 AWS からのログを一元化することを支援して、ログを監視して安全にアーカイブできるようにします。 + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) は、ステートフルでマネージド型のネットワークファイアウォールならびに侵入検知および防止サービスです。 その他のツール + 「[Splunk](https://www.splunk.com/)」 はログデータのモニタリング、視覚化、分析に役立ちます。 ## エピック ### IAM ロールを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM ポリシーを作成します。 | 「[JSON エディタを使用してポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)」の手順に従って、CloudWatch Logs データおよび CloudWatch メトリクスへの読み取り専用アクセスを許可する IAM ポリシーを作成します。以下の ポリシーを JSON エディタに貼り付けます。
{
    "Statement": [
        {
            "Action": [
                "cloudwatch:List*",
                "cloudwatch:Get*",
                "network-firewall:List*",
                "logs:Describe*",
                "logs:Get*",
                "logs:List*",
                "logs:StartQuery",
                "logs:StopQuery",
                "logs:TestMetricFilter",
                "logs:FilterLogEvents",
                "network-firewall:Describe*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "2012-10-17"
}
| AWS 管理者 | | 新しい IAM ロールを作成します。 | 「[AWS のサービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」の手順に従って、Splunk Add-On for AWS が CloudWatch へのアクセスに使用する IAM ロールを作成します。**[アクセス許可ポリシー]** で、以前に作成したポリシーを選択します。 | AWS 管理者 | | Splunk クラスターの EC2 インスタンスに IAM ロールを割り当てます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | AWS 管理者 | ### Splunk Add-On for AWS をインストールします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アドオンをインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 管理者 | | AWS 認証情報を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html)詳細については、Splunk ドキュメントの「[Find an IAM role within your Splunk platform instance](https://splunk.github.io/splunk-add-on-for-amazon-web-services/#Find_an_IAM_role_within_your_Splunk_platform_instance)」を参照してください。 | Splunk 管理者 | ### CloudWatch への Splunk アクセスを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudWatch Logs からの Network Firewall ログの取得を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html)デフォルトでは、Splunk は 10 分ごとにログデータを取得します。これは、**[Advanced Settings]**で設定可能なパラメータです。詳細については、Splunk ドキュメントの「[Configure a CloudWatch Logs input using Splunk Web](https://splunk.github.io/splunk-add-on-for-amazon-web-services/#Configure_a_CloudWatch_Logs_input_using_Splunk_Web)」を参照してください。 | Splunk 管理者 | | CloudWatch からの Network Firewall メトリクスの取得を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html)デフォルトでは、Splunk は 5 分ごとにメトリクスデータを取得します。これは、**[Advanced Settings]**で設定可能なパラメータです。詳細については、Splunk ドキュメントの「[Configure a CloudWatch input using Splunk Web](https://splunk.github.io/splunk-add-on-for-amazon-web-services/#Configure_a_CloudWatch_input_using_Splunk_Web)」を参照してください。 | Splunk 管理者 | ### クエリを使用して Splunk 可視化を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 上位の送信元 IP アドレスを表示します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 管理者 | | パケット統計を表示します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 管理者 | | 最も使用されている送信元ポートを表示します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 管理者 | ## 関連リソース **AWS ドキュメント** + [AWS サービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) (IAM ドキュメント) + [IAM ポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-start) (IAM ドキュメント) + [AWS Network Firewall でのロギングとモニタリング](https://docs.aws.amazon.com/network-firewall/latest/developerguide/logging-monitoring.html) (Network Firewall ドキュメント) + [AWS Network Firewall のルートテーブル設定](https://docs.aws.amazon.com/network-firewall/latest/developerguide/route-tables.html) (Network Firewall ドキュメント) **AWS ブログ投稿** + [AWS Network Firewall デプロイモデル](https://aws.amazon.com/pt/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) 「**AWS Marketplace**」 + [Splunk Enterprise Amazon マシンイメージ (AMI)](https://aws.amazon.com/marketplace/pp/prodview-l6oos72bsyaks) # その他のパターン **Topics** + [Session Manager と Amazon EC2 Instance Connect により踏み台ホストにアクセス](access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.md) + [AWS Fargate、AWS PrivateLink、Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスします。](access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.md) + [AWS PrivateLink と Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスします](access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.md) + [AWS Managed Microsoft AD とオンプレミスの Microsoft Active Directory を使用して DNS 解決を一元化する](centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory.md) + [、Angular AWS Amplify、および Module Federation を使用してマイクロフロントエンド用のポータルを作成する](create-amplify-micro-frontend-portal.md) + [プライベートエンドポイントと Application Load Balancer を使用して、Amazon API Gateway API を内部 Web サイトにデプロイする](deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.md) + [を使用してパブリックサブネットの検出属性ベースのアクセスコントロールをデプロイする AWS Config](deploy-detective-attribute-based-access-controls-for-public-subnets-by-using-aws-config.md) + [パブリックサブネットのための属性ベースの予防的アクセスコントロールをデプロイする](deploy-preventative-attribute-based-access-controls-for-public-subnets.md) + [Amazon RDS の PostgreSQL DB インスタンスに対して暗号化された接続を有効にする](enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.md) + [AWS Transit Gateway Connect を使用して VRF を AWS に拡張する](extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.md) + [で F5 BIG-IP ワークロードを F5 BIG-IP VE に移行する AWS クラウド](migrate-an-f5-big-ip-workload-to-f5-big-ip-ve-on-the-aws-cloud.md) + [Amazon EKS Auto Mode を有効化する際に NGINX Ingress Controller を移行する](migrate-nginx-ingress-controller-eks-auto-mode.md) + [非ワークロードサブネット用のマルチアカウント VPC 設計でルーティング可能な IP スペースを節約](preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets.md) + [サービスコントロールポリシーを使用して、アカウントレベルでのインターネットアクセスを防止する](prevent-internet-access-at-the-account-level-by-using-a-service-control-policy.md) + [AWS Network Firewall から Slack チャネルにアラートを送信](send-alerts-from-aws-network-firewall-to-a-slack-channel.md) + [Amazon CloudFront を使用して Amazon S3 バケットの静的なコンテンツを VPC 経由で配信する](serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.md) + [AWS Elastic Disaster Recoveryで Oracle JD Edwards EnterpriseOne のディザスタリカバリをセットアップする](set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.md) + [BMC ディスカバリークエリを使用して移行計画のために移行データを抽出](use-bmc-discovery-queries-to-extract-migration-data-for-migration-planning.md) + [Network Firewall を使用して、アウトバウンドトラフィックのサーバー名表示から DNS ドメイン名をキャプチャする](use-network-firewall-to-capture-the-dns-domain-names-from-the-server-name-indication-sni-for-outbound-traffic.md) # コンテンツ配信 **Topics** + [AWS Firewall Manager と Amazon Data Firehose を使用して Splunk に AWS WAF ログを送信する](send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose.md) + [Amazon CloudFront を使用して Amazon S3 バケットの静的なコンテンツを VPC 経由で配信する](serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.md) + [その他のパターン](contentdelivery-more-patterns-pattern-list.md) # AWS Firewall Manager と Amazon Data Firehose を使用して Splunk に AWS WAF ログを送信する *Michael Friedenthal、Aman Kaur Gandhi、JJ Johnson、Amazon Web Services* ## 概要 これまで、データを Splunk に移動する方法には、プッシュアーキテクチャとプルアーキテクチャの 2 つがありました。*プルアーキテクチャ*では再試行によるデータ配信が保証されますが、データをポーリングする専用のリソースが Splunk に必要になります。プルアーキテクチャはポーリングを行うため、通常はリアルタイムではありません。*プッシュアーキテクチャ*は、通常、レイテンシが低く、拡張性が高く、運用の複雑さとコストが削減されます。ただし、配信を保証することはできません。通常、エージェントが必要です。 Splunk と Amazon Data Firehose の統合により、HTTP イベントコレクター (HEC) を通じて Splunk にリアルタイムのストリーミングデータが配信されます。この統合には、プッシュアーキテクチャとプルアーキテクチャの両方のメリットがあります。再試行によるデータ配信が保証され、ほぼリアルタイムで、レイテンシーが低く、複雑性も低くなります。HEC は、HTTP または HTTPS 経由で Splunk にデータを迅速かつ効率的に直接送信します。HEC はトークンベースなので、アプリケーションやサポートファイルに認証情報をハードコーディングする必要はありません。 AWS Firewall Manager ポリシーでは、すべてのアカウントのすべての AWS WAF ウェブ ACL トラフィックのログ記録を設定でき、Firehose 配信ストリームを使用してそのログデータを Splunk に送信し、モニタリング、可視化、分析を行うことができます。ソリューションは次の利点があります。 + すべてのアカウントの AWS WAF ウェブ ACL トラフィックの一元管理とログ記録 + Splunk と 1 つの との統合 AWS アカウント + スケーラビリティ + ログデータをほぼリアルタイムで配信 + サーバーレスソリューションの使用によるコストの最適化により、未使用のリソースにお金を払う必要がなくなります。 ## 前提条件と制限事項 **前提条件** + の組織の一部 AWS アカウント であるアクティブな AWS Organizations。 + Firehose を使用してログ記録を有効化するには、次の許可が付与されている必要があります。 + `iam:CreateServiceLinkedRole` + `firehose:ListDeliveryStreams` + `wafv2:PutLoggingConfiguration` + AWS WAF とそのウェブ ACLs を設定する必要があります。手順については、[「 の開始方法 AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html)」を参照してください。 + AWS Firewall Manager を設定する必要があります。手順については、「[AWS Firewall Manager prerequisites](https://docs.aws.amazon.com/waf/latest/developerguide/fms-prereq.html)」を参照してください。 + の Firewall Manager セキュリティポリシーを設定 AWS WAF する必要があります。手順については、[「 AWS Firewall ManagerAWS WAF ポリシーの開始方法](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms.html)」を参照してください。 + Splunk には、Firehose からアクセスできるパブリック HTTP エンドポイントをセットアップする必要があります。 **制限事項** + は、 の 1 つの組織で管理 AWS アカウント する必要があります AWS Organizations。 + ウェブ ACL は、配信ストリームと同じリージョンである必要があります。Amazon CloudFront のログをキャプチャする場合、米国東部 (バージニア北部) リージョン `us-east-1` に Firehose 配信ストリームを作成します。 + Firehose 用の Splunk アドオンは、有料の Splunk クラウドデプロイ、分散型 Splunk エンタープライズデプロイ、および単一インスタンスの Splunk エンタープライズデプロイで利用できます。このアドオンは、Splunk Cloud の無料トライアルデプロイではサポートされていません。 ## アーキテクチャ **ターゲットテクノロジースタック** + Firewall Manager + Firehose + Amazon Simple Storage Service (Amazon S3) + AWS WAF + Splunk **ターゲットアーキテクチャ** 次の図は、Firewall Manager を使用してすべての AWS WAF データを一元的にログに記録し、Firehose 経由で Splunk に送信する方法を示しています。 ![\[Amazon Data Firehose を介して AWS WAF ログデータを Splunk に送信する方法を示すアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/3dfeaae0-985a-42b8-91c4-ece081f0b51b/images/669169b1-caa4-419b-9988-19806ded54eb.png) 1. AWS WAF ウェブ ACLsファイアウォールログデータを Firewall Manager に送信します。 1. Firewall Manager は Firehose にログデータを送信します。 1. Firehose 配信ストリームは、ログデータを Splunk と S3 バケットに転送します。S3 バケットは、Firehose 配信ストリームでエラーが発生した場合のバックアップとして機能します。 **自動化とスケール** このソリューションは、組織内のすべての AWS WAF ウェブ ALCs をスケーリングし、それに対応するように設計されています。すべてのウェブ ACL が同じ Firehose インスタンスを使用するように設定できます。ただし、希望する場合は、複数の Firehose インスタンスをセットアップして使用できます。 ## ツール **AWS のサービス** + [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html) は、 のアカウントとアプリケーション全体でファイアウォールルールを一元的に設定および管理するためのセキュリティ管理サービスです AWS Organizations。 + [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) は AWS のサービス、Splunk などのサポートされているサードパーティーサービスプロバイダーが所有する他の HTTP エンドポイント、カスタム HTTP エンドポイント、HTTP エンドポイントにリアルタイムの[ストリーミングデータを](https://aws.amazon.com/streaming-data/)配信するのに役立ちます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html) は、保護されたウェブアプリケーションリソースに転送される HTTP と HTTPS リクエストをモニタリングできるウェブアプリケーションファイアウォールです。 その他のツール + 「[Splunk](https://docs.splunk.com/Documentation)」 はログデータのモニタリング、視覚化、分析に役立ちます。 ## エピック ### Splunk の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Splunk App for をインストールします AWS。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose.html) | セキュリティ管理者、Splunk 管理者 | | のアドオンをインストールします AWS WAF。 | 前の手順を繰り返して、Splunk 用 **AWS ウェブアプリケーションファイアウォールアドオン**をインストールします。 | セキュリティ管理者、Splunk 管理者 | | Firehose 用の Splunk アドオンをインストールして設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose.html) | セキュリティ管理者、Splunk 管理者 | ### Firehose 配信ストリームを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Splunk の宛先へのアクセスを Firehose に付与します。 | Firehose が Splunk の宛先にアクセスし、ログデータを S3 バケットにバックアップすることを許可するアクセスポリシーを設定します。詳細については、「[Grant Firehose Access to a Splunk Destination](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-splunk)」を参照してください。 | セキュリティ管理者 | | Firehose 配信ストリームを作成します。 | ウェブ ACLs を管理するのと同じアカウントで AWS WAF、Firehose で配信ストリームを作成します。配信ストリームを作成するときは、IAM ロールが必要です。Firehose は、IAM ロールを引き受け、指定された S3 バケットへのアクセス権を取得します。手順については、「[配信ストリームの作成](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)」 を参照してください。次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose.html)HTTP イベントコレクターで設定したトークンごとに、このプロセスを繰り返します。 | セキュリティ管理者 | | 配信ストリームをテストします。 | 配信ストリームをテストして、適切に設定されていることを確認します。手順については、Firehose ドキュメントの「[Test using Splunk as the destination](https://docs.aws.amazon.com/firehose/latest/dev/test-drive-firehose.html#test-drive-destination-splunk)」を参照してください。 | セキュリティ管理者 | ### データをログに記録するようにFirewall Manager を設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Firewall Manager のポリシーを設定します。 | Firewall Manager ポリシーは、ロギングを有効にし、ログを正しい Firehose 配信ストリームに転送するように設定する必要があります。詳細と手順については、「 [AWS WAF ポリシーのログ記録の設定](https://docs.aws.amazon.com/waf/latest/developerguide/waf-policies.html#waf-policies-logging-config)」を参照してください。 | セキュリティ管理者 | ## 関連リソース **AWS リソース** + [ウェブ ACL トラフィックのログ記録](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html) (AWS WAF ドキュメント) + [AWS WAF ポリシーのログ記録の設定](https://docs.aws.amazon.com/waf/latest/developerguide/waf-policies.html#waf-policies-logging-config) (AWS WAF ドキュメント) + [Tutorial: Sending VPC Flow Logs to Splunk Using Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/vpc-splunk-tutorial.html) (Amazon Kinesis Data Firehose ドキュメント) + [Amazon Data Firehose を使用して、VPC フローログを Splunk にプッシュするにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/push-flow-logs-splunk-firehose/) (AWS ナレッジセンター) + [Amazon Data Firehose を使用した Splunk へのデータ取り込み](https://aws.amazon.com/blogs/big-data/power-data-ingestion-into-splunk-using-amazon-kinesis-data-firehose/)の強化 (AWS ブログ記事) Splunk ドキュメント + [Splunk Add-on for Amazon Data Firehose](https://docs.splunk.com/Documentation/AddOns/released/Firehose/About) # Amazon CloudFront を使用して Amazon S3 バケットの静的なコンテンツを VPC 経由で配信する *Amazon Web Services、Angel Emmanuel Hernandez Cebrian* ## 概要 Amazon Web Services (AWS) でホストされている静的コンテンツを配信する場合、Amazon Simple Storage Service (S3) バケットをオリジンとして使用し、Amazon CloudFront を使用してコンテンツを配信することが推奨されます。このソリューションには主に 2 つの利点があります。エッジロケーションで静的コンテンツをキャッシュする利便性と、CloudFront ディストリビューションの[ウェブアクセス制御リスト](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html) (ウェブ ACL) を定義する機能です。これにより、最小限の設定と管理オーバーヘッドでコンテンツへのリクエストを保護することができます。 ただし、標準的な推奨アプローチには、アーキテクチャ上の共通の制限があります。環境によっては、仮想プライベートクラウド (VPC) に仮想ファイアウォールアプライアンスをデプロイして、静的コンテンツを含むすべてのコンテンツを検査したい場合があります。標準的なアプローチでは、トラフィックを VPC 経由でルーティングして検査することはありません。このパターンは、アーキテクチャ上の代替ソリューションとなります。S3 バケットの静的コンテンツの配信には引き続き CloudFront ディストリビューションを使用しますが、トラフィックはApplication Load Balancer を使用して VPC 経由でルーティングされます。次に、AWS Lambda 関数が S3 バケットからコンテンツを取得して返します。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント。 + S3 バケットにホストされた静的ウェブサイト内容 **制限事項** + このパターンのリソースは単一の AWS リージョンにある必要がありますが、異なる AWS アカウントにプロビジョニングできます。 + 制限は、Lambda 関数が受信および送信できるリクエストとレスポンスの最大サイズにそれぞれ適用されます。詳細については、「[Lambda functions as targets](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html)」(Elastic Load Balancing ドキュメント) の「*Limits*」を参照してください。 + このアプローチを使用するときは、パフォーマンス、スケーラビリティ、セキュリティ、費用対効果のバランスを取ることが重要です。Lambda はスケーラビリティが高いにもかかわらず、Lambda の同時呼び出しの数が最大クォータを超えると、一部のリクエストがスロットされます。詳細については、Lambda のクォータ（Lambda ドキュメント）を参照してください。Lambda を使用する場合は価格設定も考慮する必要があります。Lambda 呼び出しを最小限に抑えるには、CloudFront ディストリビューションのキャッシュを適切に定義します。詳細については、「[キャッシュと可用性の最適化](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ConfiguringCaching.html)」 (CloudFront ドキュメント)」を参照してください。 ## アーキテクチャ **ターゲットテクノロジースタック** + CloudFront + Amazon Virtual Private Cloud (Amazon VPC) + Application Load Balancer + Lambda + Amazon S3 **ターゲットアーキテクチャ** 次の図表では、CloudFront を使用して S3 バケットから VPC 経由で静的コンテンツを提供する必要がある場合の推奨アーキテクチャを示しています。 ![\[トラフィックは VPC のApplication Load Balancerを経由して Lambda 関数に流れます。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e0dd6928-4fe0-47ab-954f-9de5563349d8/images/b42c7dd9-4a72-4998-bf88-195c8f90ed3e.png) 1. クライアントは CloudFront ディストリビューションの URL をリクエストして S3 バケット内の特定のウェブサイトファイルを取得します。 1. CloudFront は AWS WAF にリクエストを送信します。AWS WAF は、CloudFront ディストリビューションに適用されたウェブ ACL を使用してリクエストをフィルタリングします。リクエストが有効であると判断された場合、フローは続行されます。リクエストが無効であると判断された場合、クライアントは 403 エラーを受け取ります。 1. CloudFront は内部キャッシュをチェックします。受信したリクエストに一致する有効なキーがある場合、関連する値が応答としてクライアントに送り返されます。そうでなければ、フローは続行されます。 1. CloudFront は、指定した Application Load Balancer の URL にリクエストを転送します。 1. Application Load Balancer には、Lambda 関数に基づいてターゲットグループに関連付けられたリスナーがあります。Application Load Balancer は Lambda 関数を呼び出します。 1. Lambda 関数は S3 バケットに接続して `GetObject` 操作を実行し、コンテンツをレスポンスとして返します。 **自動化とスケール** このアプローチを使用して静的コンテンツのデプロイを自動化するには、CI/CD パイプラインを作成して、ウェブサイトをホストする Amazon S3 バケットを更新します。 Lambda 関数は、サービスのクォータと制限の範囲内で、同時リクエストを処理するように自動的にスケーリングします。詳細については、「[Lambda 関数のスケーリング](https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html)」 と「[Lambda クォータ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)」 (Lambda ドキュメント) を参照してください。CloudFront やApplication Load Balancer など、他の AWS のサービスと特徴量については、AWS がこれらを自動的にスケーリングします。 ## ツール + [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) は、世界中のデータセンターネットワークを通じて配信することで、ウェブコンテンツの配信を高速化します。これにより、レイテンシーが減少し、パフォーマンスが向上します。 + 「[Elastic Load Balancing (ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)」 は、受信するアプリケーションまたはネットワークのトラフィックを複数のターゲットに分散します。このパターンでは、Elastic ロードバランサーを通じてプロビジョニングされた 「[Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)」 を使用して、トラフィックを Lambda 関数に転送します。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。 ## エピック ### CloudFront を使用して Amazon S3 から VPC 経由で静的なコンテンツを提供する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPC を作成します。 | Application Load Balancer や Lambda 関数など、このパターンでデプロイされたリソースをホストするための VPC を作成します。 手順については、「[ VPC の作成](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC)」 （Amazon VPC ドキュメント）を参照してください。 | クラウドアーキテクト | | AWS WAF Web ACL を作成する | AWS WAF Web ACL を作成する このパターンの後半で、このウェブ ACL を CloudFront ディストリビューションに適用します。手順については、「[ウェブ ACL の作成](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-creating.html)」 (AWS WAF ドキュメント) を参照してください。 | クラウドアーキテクト | | Lambda 関数の作成 | S3 バケットでホストされている静的コンテンツをウェブサイトとして提供する Lambda 関数を作成します。このパターンの 「[追加情報](#serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront-additional)」 セクションに記載されているコードを使用してください。ターゲット S3 バケットを識別するようにコードをカスタマイズします。 | AWS 全般 | | Lambda 関数をアップロードします。 | 次のコマンドを入力して、Lambda 関数コードを Lambda の.zip ファイルアーカイブにアップロードします。
aws lambda update-function-code \
--function-name  \ 
--zip-file fileb://lambda-alb-s3-website.zip
| AWS 全般 | | Application Load Balancer を作成します。 | Lambda 関数を指すインターネット向けApplication Load Balancer を作成します。手順については、「[Lambda 関数のターゲットグループの作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html#register-lambda-function)」 (Elastic ロードバランサー ドキュメント) を参照してください。高可用性構成の場合は、Application Load Balancer を作成し、それをさまざまなアベイラビリティーゾーンのプライベートサブネットにアタッチします。 | クラウドアーキテクト | | CloudFront ディストリビューションを作成します。 | 作成したApplication Load Balancer を指す CloudFront ディストリビューションを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.html) | クラウドアーキテクト | ## 関連リソース **AWS ドキュメント** + 「[キャッシュと可用性の最適化](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ConfiguringCaching.html)」 (CloudFront ドキュメント)」を参照してください。 + 「[Lambda 関数がターゲットとして機能します](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html)」 (Elastic ロードバランサードキュメント) + 「[Lambda クォータ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)」 (Lambda ドキュメント) AWS サービスウェブサイト + [Application Load Balancer](https://aws.amazon.com/es/elasticloadbalancing/application-load-balancer/) + [Lambda](https://aws.amazon.com/en/lambda/) + [CloudFront](https://aws.amazon.com/en/cloudfront/) + [Amazon S3](https://aws.amazon.com/en/s3/) + [AWS WAF](https://aws.amazon.com/en/waf/) + [Amazon VPC](https://aws.amazon.com/en/vpc/) ## 追加情報 **Code** 次の例のLambda 関数が Node.js で記述されます。この Lambda 関数は、ウェブサイトリソースを含む S3 バケットに対して `GetObject` 操作を実行するウェブサーバーとして機能します。 ``` /** * This is an AWS Lambda function created for demonstration purposes. * It retrieves static assets from a defined Amazon S3 bucket. * To make the content available through a URL, use an Application Load Balancer with a Lambda integration. * * Set the S3_BUCKET environment variable in the Lambda function definition. */ var AWS = require('aws-sdk'); exports.handler = function(event, context, callback) { var bucket = process.env.S3_BUCKET; var key = event.path.replace('/', ''); if (key == '') { key = 'index.html'; } // Fetch from S3 var s3 = new AWS.S3(); return s3.getObject({Bucket: bucket, Key: key}, function(err, data) { if (err) { return err; } var isBase64Encoded = false; var encoding = 'utf8'; if (data.ContentType.indexOf('image/') > -1) { isBase64Encoded = true; encoding = 'base64' } var resp = { statusCode: 200, headers: { 'Content-Type': data.ContentType, }, body: new Buffer(data.Body).toString(encoding), isBase64Encoded: isBase64Encoded }; callback(null, resp); } ); }; ``` # その他のパターン **Topics** + [Amazon CloudFront ディストリビューションのアクセスロギング、HTTPS、TLS バージョンを確認する](check-an-amazon-cloudfront-distribution-for-access-logging-https-and-tls-version.md) + [gRPC ベースのアプリケーションを Amazon EKS クラスターにデプロイし、Application Load Balancer でアクセスする](deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.md) + [パブリックサブネットのための属性ベースの予防的アクセスコントロールをデプロイする](deploy-preventative-attribute-based-access-controls-for-public-subnets.md) + [Terraform を使用して リソースを AWS Wavelength ゾーンにデプロイする](deploy-resources-wavelength-zone-using-terraform.md) + [Terraform を使用して AWS WAF ソリューションのセキュリティオートメーションをデプロイする](deploy-the-security-automations-for-aws-waf-solution-by-using-terraform.md) + [セルベースアーキテクチャ用にサーバーレスセルルーターを設定する](serverless-cell-router-architecture.md) + [Amazon Q Developer をコーディングアシスタントとして使用して生産性を高める](use-q-developer-as-coding-assistant-to-increase-productivity.md) + [Splunk を使用して AWS Network Firewall のログとメトリクスを表示する](view-aws-network-firewall-logs-and-metrics-by-using-splunk.md)