翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# のコンピューティング環境 AWS Batch
ジョブキューは、1 つ以上のコンピューティング環境にマッピングされます。コンピューティング環境には、コンテナ化されたバッチジョブを実行するための Amazon ECS コンテナインスタンスが含まれています。特定のコンピューティング環境を 1 つ以上のジョブキューにマッピングすることもできます。ジョブキュー内では、関連するコンピュート環境はそれぞれ順番を持っており、スケジューラは実行準備が整ったジョブをどこで実行するかを決定するのに使用します。最初のコンピュート環境の`VALID`ステータスが、利用可能なリソースがある場合、ジョブはそのコンピュート環境内のコンテナインスタンスにスケジューリングされる。最初のコンピュート環境の`INVALID`ステータスが、適切なコンピュートリソースを提供できないか、または提供できない場合、スケジューラは次のコンピュート環境でジョブを実行しようとします。
**Topics**
+ [マネージド型のコンピューティング環境](managed_compute_environments.md)
+ [アンマネージド型のコンピューティング環境](unmanaged_compute_environments.md)
+ [コンピューティング環境を作成する](create-compute-environment.md)
+ [でコンピューティング環境を更新する AWS Batch](updating-compute-environments.md)
+ [コンピューティングリソースの AMI](compute_resource_AMIs.md)
+ [で Amazon EC2 起動テンプレートを使用する AWS Batch](launch-templates.md)
+ [インスタンスメタデータサービス (IMDS) の設定](imds-compute-environments.md)
+ [EC2 設定](ec2-configurations.md)
+ [AWS Batch のインスタンスタイプの配分戦略](allocation-strategies.md)
+ [コンピューティングリソースメモリの管理](memory-management.md)
+ [Fargate のコンピューティング環境](fargate.md)
+ [Amazon EKS コンピュート環境](eks.md)
# マネージド型のコンピューティング環境
マネージド型のコンピューティング環境を使用して、 が環境内のコンピューティングリソースの容量とインスタンスタイプ AWS Batch を管理できます。これは、コンピュート環境の作成時に定義したコンピュートリソースの仕様に基づいています。Amazon EC2 オンデマンドインスタンスと Amazon EC2 スポットインスタンスを使用するかを選択できます。または、マネージド型のコンピューティング環境で Fargate および Fargate スポット容量を使用することもできます。スポットインスタンスを使用する場合、オプションで上限価格を設定できます。こうすることで、スポット・インスタンスは、スポットインスタンス価格がオンデマンド価格の指定されたパーセンテージを下回った場合にのみ起動する。
**重要**
Fargate スポットインスタンスは ではサポートされていません Windows containers on AWS Fargate。FargateWindows のジョブが、Fargate Spot のコンピュート環境のみを利用するジョブキューに投入された場合、ジョブキューはブロックされます。
**重要**
AWS Batch は、Amazon EC2 起動テンプレート、Amazon EC2 Auto Scaling グループ、Amazon EC2 スポットフリート、Amazon ECS クラスターなど、ユーザーに代わってアカウント内で複数の AWS リソースを作成および管理します。これらのマネージドリソースは、最適な AWS Batch オペレーションを確保するために特別に設定されています。これらの AWS Batchマネージドリソースを手動で変更すると、ドキュメントに AWS Batch 明示的に記載されていない限り、`INVALID`コンピューティング環境、最適ではないインスタンススケーリング動作、ワークロード処理の遅延、予期しないコストなどの予期しない動作が発生する可能性があります。これらの手動変更は、 AWS Batch サービスで決定的にサポートすることはできません。コンピューティング環境を管理するには、必ずサポートされている AWS Batch APIsまたは AWS Batch コンソールを使用してください。
サポートされていない手動変更には、独自の Amazon ECS タスクまたはサービスオン AWS Batchマネージド Amazon ECS クラスターの実行、または追加のプロセス、デーモン、またはサービスオン AWS Batchマネージドインスタンスの直接開始が含まれます。 は、マネージドコンピューティング環境でコンピューティングリソースの完全な制御を AWS Batch 引き受け、いつでもインスタンスを終了、タスクを停止、またはクラスターをスケーリングできます。これらのマネージドリソースで AWS Batch ジョブの送信外で実行するワークロードは、警告なしに中断される可能性があります。ワークロード以外のAWS Batch 管理 AWS Batch対象クラスターやインスタンスを実行すると、 AWS Batch ジョブのスケジュール設定やインスタンスのスケーリングが妨げられる可能性があります。
マネージドコンピューティング環境は、指定した VPC とサブネットに Amazon EC2 インスタンスを起動し、Amazon ECS クラスターに登録します。Amazon EC2インスタンスは、Amazon ECSサービスエンドポイントと通信するために外部ネットワークアクセスが必要です。一部のサブネットでは、Amazon EC2インスタンスにパブリックIPアドレスを提供していない。Amazon EC2インスタンスがパブリックIPアドレスを持っていない場合、このアクセスを得るためにネットワークアドレス変換（NAT）を使用する必要があります。詳細については、*Amazon VPC ユーザーガイド* の[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を参照してください。VPC の作り方の詳細については、[仮想プライベートクラウドを作成する](create-public-private-vpc.md)を参照してください。
デフォルトでは、 AWS Batch マネージド型コンピューティング環境は、コンピューティングリソース用に最新の承認済みバージョンの Amazon ECS 最適化 AMI を使用します。ただし、さまざまな理由により、マネージド型のコンピューティング環境で使用する AMI を独自に作成する場合もあります。詳細については、「[コンピューティングリソースの AMI](compute_resource_AMIs.md)」を参照してください。
**注記**
AWS Batch は、作成後にコンピューティング環境の AMIs を自動的にアップグレードしません。例えば、Amazon ECS最適化AMIの新しいバージョンがリリースされても、コンピュート環境のAMIは更新されません。ゲストオペレーティングシステムの管理はユーザーの責任です。これには、アップデートとセキュリティパッチが含まれます。また、コンピューティングリソースにインストールするその他のアプリケーションソフトウェアやユーティリティについても責任を負うものとします。 AWS Batch ジョブに新しい AMI を使用する方法は 2 つあります。オリジナルの方法は、次のステップを完了することです。
新しい AMI を使用して新しいコンピューティング環境を作成します。
コンピューティング環境を既存のジョブキューに追加します。
古いコンピューティング環境をジョブキューから削除します。
以前のコンピューティング環境を削除します。
2022 年 4 月に、コンピューティング環境の更新に対する拡張サポート AWS Batch が追加されました。詳細については、「[でコンピューティング環境を更新する AWS Batch](updating-compute-environments.md)」を参照してください。コンピューティング環境の拡張アップデートを使用して AMI を更新するには、次のルールに従います。
サービスロール([https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole))パラメータを設定しないか、**AWSServiceRoleForBatch** サービス連動ロールに設定します。
割り当て戦略 ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy)) パラメータを、`BEST_FIT_PROGRESSIVE`、`SPOT_CAPACITY_OPTIMIZED` または `SPOT_PRICE_CAPACITY_OPTIMIZED`に設定します。
最新のイメージバージョンへの更新 ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion)) パラメータを `true` に設定します。
[https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId)、[https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride)([https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html)) または起動テンプレート ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)) には AMI ID を指定しないでください。この場合、 はインフラストラクチャの更新が開始された AWS Batch 時点で でサポートされている最新の Amazon ECS 最適化 AMI AWS Batch を選択します。または、`imageId`または`imageIdOverride`パラメータで AMI ID を指定するか、`LaunchTemplate`プロパティで識別されるローンチテンプレートを指定することもできます。これらのプロパティのいずれかを変更すると、インフラストラクチャの更新が開始されます。AMI ID が起動テンプレートで指定されている場合、`imageId` または `imageIdOverride` パラメータで AMI ID を指定して置き換えることはできません。別の起動テンプレートを指定することでのみ置き換えることができます。`$Default` または `$Latest`、起動テンプレートのバージョンがまたはに設定されている場合は、起動テンプレートの新しいデフォルトバージョンを設定するか(設定されている場合 `$Default` )、起動テンプレートに新しいバージョンを追加(ある場合 `$Latest` )します。
これらのルールに従うと、インフラストラクチャの更新をトリガーする更新により、AMI ID が再選択されます。起動テンプレート[https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version)の ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate))設定が`$Latest`または`$Default`に設定されている場合、[https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)を更新していない場合でも、インフラストラクチャの更新時に起動テンプレートの最新バージョンまたはデフォルトバージョンが評価されます。
## マルチノード並列ジョブを作成する際の考慮事項
AWS Batch では、マルチノード並列 (MNP) ジョブと非 MNP ジョブを実行するための専用のコンピューティング環境を作成することをお勧めします。これは、マネージドコンピュート環境におけるコンピューティングキャパシティの作り方によるものです。新しいマネージドコンピューティング環境を作成するときに、ゼロより大きい`minvCpu`値を指定すると、 は非 MNP ジョブでのみ使用するインスタンスプール AWS Batch を作成します。マルチノード並列ジョブが送信されると、 はマルチノード並列ジョブを実行する新しいインスタンス容量 AWS Batch を作成します。単一ノードとマルチノードの両方の並列ジョブが、 `minvCpus`または `maxvCpus`値が設定されている同じコンピューティング環境で実行されている場合、必要なコンピューティングリソースが使用できない場合 AWS Batch 、 は現在のジョブが終了するのを待ってから、新しいジョブを実行するために必要なコンピューティングリソースを作成します。
# アンマネージド型のコンピューティング環境
アンマネージド型のコンピューティング環境では、独自のコンピューティングリソースを管理します。 は Amazon ECS と Amazon EKS の両方でアンマネージド型のコンピューティング環境 AWS Batch をサポートしているため、Batch のジョブスケジューリング機能を活用しながら、インフラストラクチャの制御を維持できます。
**注記**
AWS Fargate リソースは、アンマネージド型のコンピューティング環境ではサポートされていません。
アンマネージド Amazon ECS コンピューティング環境では、コンピューティングリソースに使用する AMI が Amazon ECS コンテナインスタンス AMI 仕様を満たしていることを確認する必要があります。詳細については、「[コンピューティングリソースの AMI 仕様](batch-ami-spec.md)」および「[チュートリアル: コンピューティングリソース AMI を作成する](create-batch-ami.md)」を参照してください。
アンマネージ型のコンピューティング環境を作成したら、[DescribeComputeEnvironments](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeComputeEnvironments.html) API オペレーションを使用してコンピューティング環境の詳細を確認します。環境に関連付けられている Amazon ECS クラスターを見つけ、その Amazon ECS クラスター内で手動でコンテナインスタンスを起動します。
次の AWS CLI コマンドは、Amazon ECS クラスター ARN も提供します。
```
$ aws batch describe-compute-environments \
--compute-environments unmanagedCE \
--query "computeEnvironments[].ecsClusterArn"
```
詳細については、Amazon Elastic Container Service デベロッパーガイドの[Amazon ECS コンテナインスタンスの起動](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_container_instance.html)を参照してください。コンピュートリソースを起動する際、リソースが登録するAmazon ECSクラスターARNを以下のAmazon EC2ユーザーデータで指定します。*ecsClusterArn* を前のコマンドで取得したクラスター ARN に置き換えます。
```
#!/bin/bash
echo "ECS_CLUSTER=ecsClusterArn" >> /etc/ecs/ecs.config
```
アンマネージド型の Amazon EKS コンピューティング環境では、 がジョブのスケジュールと配置 AWS Batch を処理しながら、独自の Kubernetes ノードを管理します。これにより、Kubernetes インフラストラクチャのセキュリティ、コンプライアンス、または運用要件を直接制御できます。は既存の Amazon EKS クラスターと AWS Batch 統合してジョブをスケジュールして実行しながら、Amazon EKS ノードのプロビジョニングと設定を行う責任があります。
詳細については、[「チュートリアル: Amazon EKS リソースを使用してアンマネージド型のコンピューティング環境を作成する](https://docs.aws.amazon.com/batch/latest/userguide/create-compute-environment-unmanaged-eks.html)」を参照してください。
# コンピューティング環境を作成する
でジョブを実行する前に AWS Batch、コンピューティング環境を作成する必要があります。が仕様に基づいて環境内の Amazon EC2 インスタンスまたは AWS Fargate リソース AWS Batch を管理するマネージドコンピューティング環境を作成できます。あるいは、アンマネージド型のコンピューティング環境を構築し、Amazon EC2 インスタンスの設定を環境内で処理することも可能です。
**重要**
Fargate Spot インスタンスは、以下のシナリオではサポートされません。
Windows containers on AWS Fargate
このようなシナリオでは、Fargate Spot コンピューティング環境のみを使用するジョブキューにジョブが送信されると、ジョブキューはブロックされます。
**Topics**
+ [チュートリアル: Fargate リソースを使用してマネージド型のコンピューティング環境を作成する](create-compute-environment-fargate.md)
+ [チュートリアル: Amazon EC2 リソースを使用して、マネージド型のコンピューティング環境を作成する](create-compute-environment-managed-ec2.md)
+ [チュートリアル: Amazon EC2 リソースを使用して、アンマネージド型のコンピューティング環境を作成する](create-compute-environment-unmanaged-ec2.md)
+ [チュートリアル: Amazon EKS リソースを使用してマネージド型のコンピューティング環境を作成する](create-compute-environment-managed-eks.md)
+ [チュートリアル: Amazon EKS リソースを使用してアンマネージド型のコンピューティング環境を作成する](create-compute-environment-unmanaged-eks.md)
+ [リソース: コンピューティング環境テンプレート](compute-environment-template.md)
+ [インスタンスタイプのコンピューティングテーブル](instance-type-compute-table.md)
# チュートリアル: Fargate リソースを使用してマネージド型のコンピューティング環境を作成する
以下のステップを実行し、 AWS Fargate リソースを使用してマネージドコンピューティング環境を作成します。
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) で AWS Batch コンソールを開きます。
1. ナビゲーションバーから、 AWS リージョン 使用する を選択します。
1. ナビゲーションペインで、**コンピューティング環境]** を選択します。
1. **[作成]** を選択します。
1. コンピューティング環境を設定します。
**注記**
Windows containers on AWS Fargate ジョブのコンピューティング環境には、少なくとも 1 つの vCPU が必要です。
1. **コンピュート環境設定** で、**Fargate** を選択します。
1. **名前** で、コンピューティング環境の一意な名前を指定します。名前の長さは最大 128 文字です。大文字、小文字、数字、ハイフン (-)、アンダースコア (\$1) を含めることができます。
1. **サービスロール** で、サービスがユーザーに代わって必要な AWS API オペレーションを呼び出すことを許可する AWS Batch サービスにリンクされたロールを選択します。例えば、**AWSServiceRoleForBatch** を選択します。詳細については、「[のサービスにリンクされたロールの使用 AWS Batch](using-service-linked-roles.md)」を参照してください。
1. (オプション) **タグ** を展開します。タグを追加するには、**タグの追加** を選択します。次に、**キー** 名を入力し、オプションで **値** を入力します。**タグを追加]** を選択します。
1. **次のページ** を選択します。
1. **インスタンス設定** セクション:
1. (オプション) **Fargate Spot キャパシティを使用** では、Fargate Spot をオンにします。Fargate Spot については、[Amazon EC2 スポットと Fargate\$1Spot を使用する](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/ec2-and-fargate-spot.html)を参照してください。
1. **最大 vCPU]** では、ジョブキューの需要にかかわらず、コンピューティング環境でスケールアウトできる vCPU の最大数を選択します。
1. **次のページ** を選択します。
1. ネットワーキングを設定します。
**重要**
コンピューティングリソースには、Amazon ECS サービスエンドポイントと通信するために外部ネットワークアクセスが必要です。これは、インターフェイス VPC エンドポイントを介して、またはパブリック IP アドレスを持つコンピュートリソースを通じて可能になります。
インターフェイス VPC エンドポイントの詳細については、*Amazon Elastic Container Service 開発者ガイド*の[Amazon ECS インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html) を参照してください。
インターフェイス VPC エンドポイントが設定されておらず、コンピューティングリソースがパブリック IP アドレスを持たない場合は、ネットワークアドレス変換 (NAT) を使用してこのアクセスを提供する必要があります。詳細については、*Amazon VPC ユーザーガイド*の [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を参照してください。詳細については、[VPC を作成する](create-a-vpc.md)を参照してください。
1. **仮想プライベートクラウド (VPC) ID** では、インスタンスを起動する VPC を選択します。
1. **サブネット** では、使用するサブネットを選択します。デフォルトでは、選択した VPC 内のすべてのサブネットを使用できます。
**注記**
AWS Batch Fargate の は現在ローカルゾーンをサポートしていません。詳細については、Amazon Elastic Container Service 開発者ガイドの[Amazon ECS クラスターのローカルゾーン、波長ゾーン、および AWS Outposts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-regions-zones.html#clusters-local-zones)を参照してください。
1. **セキュリティグループ]** では、インスタンスにアタッチするセキュリティグループを選択します。デフォルトでは、VPC のデフォルトのセキュリティグループが選択されます。
1. **次のページ** を選択します。
1. **レビュー** では、設定手順を確認します。変更する必要がある場合は、**[編集]** を選択します。完了したら、**コンピューティング環境の作成** を選択します。
# チュートリアル: Amazon EC2 リソースを使用して、マネージド型のコンピューティング環境を作成する
Amazon Elastic Compute Cloud (Amazon EC2) リソースを使用してマネージドコンピューティング環境を作成するには、次の手順を実行します。
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) で AWS Batch コンソールを開きます。
1. ナビゲーションバーから、 AWS リージョン 使用する を選択します。
1. ナビゲーションペインで [**Environments (環境)**] を選択します。
1. **[環境の作成]** を選択した後、**[コンピューティング環境]** を選択します。
1. 環境を設定します。
1. **コンピューティング環境設定** で、**Amazon Elastic Compute Cloud (Amazon EC2)** を選択します。
1. **オーケストレーションタイプ** で、**マネージド** を選択します。
1. **名前** で、コンピューティング環境の一意な名前を指定します。名前の長さは最大 128 文字です。大文字、小文字、数字、ハイフン (-)、アンダースコア (\$1) を含めることができます。
1. **サービスロール** で、サービスがユーザーに代わって必要な AWS API オペレーションを呼び出すことを許可する AWS Batch サービスにリンクされたロールを選択します。例えば、**AWSServiceRoleForBatch** を選択します。詳細については、「[のサービスにリンクされたロールの使用 AWS Batch](using-service-linked-roles.md)」を参照してください。
1. **インスタンスロール**の場合、新しいインスタンスプロファイルを作成するか、必要な IAM アクセス許可がアタッチされた既存のプロファイルを使用するかを選択します。このインスタンスプロファイルにより、コンピューティング環境用に作成された Amazon ECS コンテナインスタンスが、ユーザーに代わって必要な AWS API オペレーションを呼び出すことができます。詳細については、「[Amazon ECS インスタンスロール](instance_IAM_role.md)」を参照してください。新しいインスタンスプロファイルを作成することを選択した場合は、必要なロール (`ecsInstanceRole`) が作成されます。
1. (オプション) **タグ** を展開します。
1. (オプション) **EC2 タグ** で、**タグを追加** を選択して、コンピューティング環境で起動されるリソースにタグを追加します。次に、**キー** 名を入力し、オプションで **値** を入力します。**[タグを追加]** を選択します。
1. (オプション) **タグ** には **タグを追加** を選択します。次に、**キー** 名を入力し、オプションで **値** を入力します。**[タグを追加]** を選択します。
詳細については、「[AWS Batch リソースのタグ付け](using-tags.md)」を参照してください。
1. **[Next]** (次へ) を選択します。
1. **インスタンス設定** セクション:
1. (オプション) **スポットインスタンスの使用を有効にする** でスポットをオンにします。詳細については、[スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)を参照してください。
1. (スポットの場合のみ) **上限のオンデマンド価格の割合 (%)** で、インスタンス起動前のインスタンスタイプのオンデマンド価格と対比したスポットインスタンス価格の最大パーセンテージを選択します。例えば、上限価格が 20% の場合、その EC2 インスタンスのスポット料金は現在のオンデマンド料金の 20% 未満にする必要があります。支払い額は常に最低 (市場料金) となり、最大パーセンテージを超えることはありません。このフィールドを空のままにした場合、デフォルト値はオンデマンド料金の 100% です。
1. (スポットの場合のみ) **スポットフリートロール** で、既存の Amazon EC2 スポットフリート IAM ロールを選択してスポットコンピューティング環境に適用します。既存の Amazon EC2 スポットフリート IAM ロールが存在しない場合には、まずこのロールを作成する必要があります。詳細については、[Amazon EC2 スポットフリートロール](spot_fleet_IAM_role.md)を参照してください。
**重要**
作成時にスポットインスタンスにタグを付けるには、Amazon EC2 スポットフリートの IAM ロールに、**より新しい AmazonEC2SpotFleetTaggingRole** 管理ポリシーを使用する必要があります。**AmazonEC2SpotFleetRole** 管理ポリシーには、スポットインスタンスにタグを付けるために必要なアクセス許可はありません。詳細については、「[作成時にタグが付けられていないスポットインスタンス](spot-instance-no-tag.md)」および「[リソースのタグ付け](tag-resources.md)」を参照してください。
1. **最小 vCPU** で、ジョブキューの需要にかかわらず、コンピューティング環境で維持する vCPU の最小数を選択します。
1. **必要な vCPU** で、コンピューティング環境の起動に必要な vCPU の数を選択します。ジョブキューの需要が増えると、 AWS Batch はコンピューティング環境で必要な vCPU の数を増やし、vCPU の最大数まで EC2 インスタンスを追加できます。需要が減ると、 AWS Batch はコンピューティング環境で必要な vCPU の数を減らし、vCPU の最小数までインスタンスを削減できます。
1. **[最大 vCPU]** では、ジョブキューの需要にかかわらず、コンピューティング環境でスケールアウトできる vCPU の最大数を選択します。
1. (オプション) **スケールダウン遅延 (分)** では、ジョブの完了後にコンピューティング環境でインスタンスを実行 AWS Batch し続ける最小時間 (分単位) を選択します。
1. **許可されたインスタンスタイプ]** では、起動できる Amazon EC2 インスタンスタイプを選択します。インスタンスファミリーを指定してそのファミリー内のいずれかのインスタンスタイプ (`c5`、`c5n`、`p3`など) を起動できます。または、ファミリー内の特定のサイズを指定することもできます (`c5.8xlarge`)。メタルインスタンスタイプはインスタンスファミリーに含まれていません。例えば、`c5` は `c5.metal` を含んでいません。
AWS Batch 次のいずれかを選択した場合、 はインスタンスタイプを選択できます。
+ `optimal` を選択すると、ジョブキューの需要に見合ったインスタンスタイプを (`c4`、`m4`、`r4`、`c5`、`m5` および `r5` インスタンスファミリーから) 選択します。
+ `default_x86_64` を選択すると、ジョブキューのリソース需要に見合った x86 ベースのインスタンスタイプを (m6i、c6i、r6i、c7i インスタンスファミリーから) 選択します。
+ `default_arm64` を選択すると、ジョブキューのリソース需要に見合った x86 ベースのインスタンスタイプを (m6g、c6g、r6g、c7g インスタンスファミリーから) 選択します。
**注記**
2025 年 11 月 1 日以降、`optimal` の動作は `default_x86_64` と一致するように変更されます。変更中、インスタンスファミリーは新しい世代に更新される可能性があります。アップグレードを実行するためにアクションを実行する必要はありません。変更に関する詳細については、「[ インスタンスファミリーの自動更新を受信するための最適なインスタンスタイプの設定 2025 年 11 月 1 日以降、`optimal` の動作は `default_x86_64` と一致するように変更されます。変更中、インスタンスファミリーは新しい世代に更新される可能性があります。アップグレードを実行するためにアクションを実行する必要はありません。 AWS Batch は、ジョブキューの需要`optimal`に合わせて、 の **instanceTypes** で 1 つのオプションをサポートしました。`default_x86_64` と `default_arm64` の 2 つの新しいインスタンスタイプのオプションが導入されました。インスタンスタイプを選択しない場合、`default_x86_64` が使用されます。これらの新しいオプションでは、ジョブキューの要件に基づいて、さまざまなファミリーや世代にわたって費用対効果の高いインスタンスタイプが自動的に選択されるため、ワークロードをすばやく実行できます。 で新しいインスタンスタイプの十分な容量が利用可能になると AWS リージョン、対応するデフォルトプールは新しいインスタンスタイプで自動的に更新されます。既存の `optimal` オプションは引き続きサポートされ、今後更新されたインスタンスを提供するために基盤となるデフォルトプールでサポートされるため、廃止されません。'`optimal` を使用している場合、ユーザー側でアクションは必要ありません。 ただし、`ENABLED` および `VALID` コンピューティング環境 (CE) のみが新しいインスタンスタイプで自動的に更新されることに注意してください。`DISABLED` または `INVALID` CE がある場合は、再有効化されて `VALID` 状態に設定されると、更新を受け取ります。 ](optimal-default-instance-troubleshooting.md#optimal-default-instance-troubleshooting.title)」を参照してください。
**注記**
インスタンスファミリーの可用性は、 AWS リージョンによって異なります。例えば、一部の AWS リージョンには第 4 世代のインスタンスファミリーがないが、第 5 世代と第 6 世代のインスタンスファミリーがある場合があります。
`default_x86_64` または `default_arm64` インスタンスバンドルを使用する場合、 AWS Batch はコスト効率とパフォーマンスのバランスに基づいてインスタンスファミリーを選択します。新世代のインスタンスでは価格パフォーマンスが向上することがよく AWS Batch ありますが、ワークロードの可用性、コスト、パフォーマンスを最適に組み合わせれば、旧世代のインスタンスファミリーを選択することもできます。例えば、c6i インスタンスと c7i インスタンス AWS リージョン の両方が利用可能な では、特定のジョブ要件に対して費用対効果がより高い c6i インスタンス AWS Batch を選択できます。 AWS Batch インスタンスタイプと AWS リージョン 可用性の詳細については、[「インスタンスタイプのコンピューティングテーブル](instance-type-compute-table.md#instance-type-compute-table.title)」を参照してください。
AWS Batch は、デフォルトのバンドル内のインスタンスを、よりコスト効率の高い新しいオプションに定期的に更新します。更新は、ユーザーからのアクションを必要とせずに自動的に行われます。ワークロードは、更新中も中断せずに実行され続けます。
**注記**
コンピューティング環境を作成する際、そのコンピューティング環境で選択するインスタンスタイプで同じアーキテクチャを使用する必要があります。例えば、x86 と ARM インスタンスを同じコンピューティング環境で使用することはできません。
**注記**
AWS Batch は、ジョブキューの必要量に基づいて GPUs をスケーリングします。GPU スケジューリングを使用するには、コンピューティング環境に `p6`、`p3`、`p4`、`p5`、`g3`、`g3s`、`g4`、`g5`、または `g6` ファミリーのインスタンスタイプを含める必要があります。
1. **[配分戦略]** では、許可されるインスタンスタイプのリストからインスタンスタイプを選択するときに使用する配分戦略を選択します。EC2 のオンデマンドコンピューティング環境では **BEST\$1FIT\$1PROGRESSIVE** を、EC2 のスポットコンピューティング環境では **SPOT\$1CAPACITY\$1OPTIMIZED** または **SPOT\$1PRICE\$1CAPACITY\$1OPTIMIZED** を選択するのが一般的です。詳細については、「[AWS Batch のインスタンスタイプの配分戦略](allocation-strategies.md)」を参照してください。
1. **追加設定]** を展開します。
1. (オプション) **プレイスメントグループ** では、プレイスメントグループ名を入力して、コンピューティング環境内のリソースをグループ化します。
1. (オプション) **EC2 キーペア** で、インスタンス接続時のセキュリティ認証情報としてパブリックキーとプライベートキーのペアを選択します。Amazon EC2 キーペアの詳細については、[Amazon EC2 キーペアおよび Linux インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)を参照してください。
1. (オプション) **EC2 設定**では、**イメージタイプ**と**イメージ ID オーバーライド**値を選択して、 がコンピューティング環境のインスタンスの Amazon マシンイメージ (AMIs) を選択 AWS Batch するための情報を提供します。イメージ**タイプごとにイメージ** **ID オーバーライド**が指定されていない場合、 は最新の [Amazon ECS 最適化 AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) AWS Batch を選択します。**イメージタイプ**が指定されていない場合、デフォルトは非 GPU、非 Graviton インスタンスの **Amazon Linux 2** AWS です。
**重要**
カスタム AMI を使用するには、イメージタイプを選択し、**イメージ ID のオーバーライド** ボックスにカスタム AMI ID を入力します。
[Amazon Linux 2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#al2ami)
すべての AWS Graviton ベースのインスタンスファミリー (、、`C6g``M6g`、 など`T4g`) のデフォルトであり`R6g`、すべての非 GPU インスタンスタイプに使用できます。
[Amazon Linux 2 (GPU)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#gpuami)
すべての GPU インスタンスファミリー ( `P4`や など`G4`) のデフォルトであり、すべての Graviton AWS ベースのインスタンスタイプで使用できます。
[Amazon Linux 2023](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)
AWS Batch は、Amazon Linux 2023 をサポートします。
Amazon Linux 2023 は `A1` インスタンスをサポートしていません。
[Amazon Linux 2023 (GPU)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#gpuami)
すべての GPU インスタンスファミリー ( `P4`や など`G4`) のデフォルトであり、すべての Graviton AWS ベースのインスタンスタイプで使用できます。
**注記**
コンピューティング環境用に選択する AMI は、そのコンピューティング環境で使用するインスタンスタイプのアーキテクチャと一致している必要があります。例えば、コンピューティング環境で A1 インスタンスタイプを使用する場合、選択するコンピューティングリソース AMI で ARM インスタンスをサポートしている必要があります。Amazon ECS は、Amazon ECS に最適化された Amazon Linux 2 AMI の、x86 と ARM の両バージョンを提供しています。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の「[Amazon ECS に最適化された Amazon Linux 2 AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html)」を参照してください。
1. (オプション) **起動テンプレート**を展開する
1. (オプション) **[デフォルトの起動テンプレート]** では、既存の Amazon EC2 起動テンプレートを選択して、コンピューティングリソースを設定します。テンプレートのデフォルトバージョンは自動的に設定されます。詳細については、[で Amazon EC2 起動テンプレートを使用する AWS Batch](launch-templates.md)を参照してください。
**注記**
起動テンプレートで、作成したカスタム AMI を指定できます。
1. (オプション) **[デフォルトのバージョン]** では、`$Default` または `$Latest` を入力するか、使用する特定のバージョン番号を指定します。
**注記**
注意: 置換変数 (\$1Default または \$1Latest) のいずれかを使用すると、この設定が保存された時点での現在のデフォルトまたは最新のバージョン番号が適用されます。今後、デフォルトバージョンまたは最新バージョンが変更された場合は、情報をアップデートする必要があります。自動的にはアップデートされません。
**重要**
起動テンプレートのバージョンパラメータが `$Default` または `$Latest` の場合、指定された起動テンプレートのデフォルトまたは最新バージョンがインフラストラクチャの更新時に評価されます。デフォルトで別の AMI ID が選択されている場合、または起動テンプレートの最新バージョンが選択されている場合、その AMI ID が更新に使用されます。詳細については、「[インフラストラクチャの更新中の AMI の選択](infrastructure-updates.md#updating-compute-environments-ami)」を参照してください。
1. (オプション) **[起動テンプレートのオーバーライド]** で、**[起動テンプレートのオーバーライドを追加]** を選択します。
1. (オプション) **[起動テンプレート]** で、特定のインスタンスタイプとファミリーに使用する既存の Amazon EC2 起動テンプレートを選択します。
1. (オプション) **[デフォルトのバージョン]** では、特定のバージョン番号を入力して `$Default` または `$Latest` を使用します。
**注記**
`$Default` または `$Latest`変数を使用する場合、 AWS Batch はコンピューティング環境の作成時に現在の情報を適用します。デフォルトまたは最新バージョンが今後変更される場合は、[UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) または AWS マネジメントコンソール - を使用して情報を更新する必要があります AWS Batch。
1. (オプション) **[ターゲットインスタンスタイプ]** で、起動テンプレートのオーバーライドを適用するインスタンスタイプまたはファミリーを選択します。
**注記**
起動テンプレートのオーバーライドを指定する場合は、**[ターゲットインスタンスタイプ]** が必要です。詳細については、「[LaunchTemplateSpecificationOverride.targetInstanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecificationOverride.html#Batch-Type-LaunchTemplateSpecificationOverride-targetInstanceTypes)」を参照してください。
**注記**
選択するインスタンスタイプまたはファミリーがこのリストに表示されない場合は、`Allowed instance types` で行った選択を確認します。
1. [**次へ**] を選択します。
1. **ネットワーク設定** セクションで:
**重要**
コンピューティングリソースには、Amazon ECS サービスエンドポイントと通信するために外部ネットワークアクセスが必要です。これは、インターフェイス VPC エンドポイントを介して、またはパブリック IP アドレスを持つコンピュートリソースを通じて可能になります。
インターフェイス VPC エンドポイントの詳細については、*Amazon Elastic Container Service 開発者ガイド*の[Amazon ECS インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html) を参照してください。
インターフェイス VPC エンドポイントが設定されておらず、コンピューティングリソースがパブリック IP アドレスを持たない場合は、ネットワークアドレス変換 (NAT) を使用してこのアクセスを提供する必要があります。詳細については、*Amazon VPC ユーザーガイド*の [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を参照してください。詳細については、[VPC を作成する](create-a-vpc.md)を参照してください。
1. **仮想プライベートクラウド (VPC) ID** では、インスタンスを起動する先の VPC を選択します。
1. **サブネット** では、使用するサブネットを選択します。デフォルトでは、選択した VPC 内のすべてのサブネットを使用できます。
**注記**
AWS Batch Amazon EC2 の は Local Zones をサポートしています。詳細については、「*Amazon EC2 ユーザーガイド*」の「[ローカルゾーン](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html?icmpid=docs_ec2_console#concepts-local-zones)」、および「*Amazon Elastic Container Service 開発者ガイド*」の「[Amazon ECS クラスターのローカルゾーン、波長ゾーン、および AWS Outposts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-regions-zones.html#clusters-local-zones)」を参照してください。
1. (オプション) **セキュリティグループ** で、インスタンスにアタッチするセキュリティグループを選択します。デフォルトでは、VPC のデフォルトのセキュリティグループが選択されます。
**注記**
注意: 置換変数 (\$1Default または \$1Latest) のいずれかを使用すると、この設定が保存された時点での現在のデフォルトまたは最新のバージョン番号が適用されます。今後、デフォルトバージョンまたは最新バージョンが変更された場合は、情報をアップデートする必要があります。自動的にはアップデートされません。
1. **次のページ** を選択します。
1. **レビュー** では、設定手順を確認します。変更する必要がある場合は、**[編集]** を選択します。完了したら、**コンピューティング環境の作成** を選択します。
# チュートリアル: Amazon EC2 リソースを使用して、アンマネージド型のコンピューティング環境を作成する
Amazon Elastic Compute Cloud (Amazon EC2) リソースを使用してアンマネージドコンピューティング環境を作成するには、次のステップを実行します。
****
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) で AWS Batch コンソールを開きます。
1. ナビゲーションバーから、 AWS リージョン 使用する を選択します。
1. ［**コンピューティング環境**］ページで、［**作成**］を選択します。
1. 環境を設定します。
1. **コンピューティング環境設定** で、**Amazon Elastic Compute Cloud (Amazon EC2)** を選択します。
1. **オーケストレーションタイプ** で、**アンマネージド** を選択します。
1. **名前** で、コンピューティング環境の一意な名前を指定します。名前の最大長は 128 文字です。大文字、小文字、数字、ハイフン (-)、アンダースコア (\$1) を含めることができます。
1. **サービスロール**で、 AWS Batch サービスがユーザーに代わって必要な AWS API オペレーションを呼び出すことを許可するロールを選択します。
**注記**
アンマネージド型のコンピューティング環境では `AWSServiceRoleForBatch` を使用できません。
1. **[最大 vCPU]** では、ジョブキューの需要にかかわらず、コンピューティング環境でスケールアウトできる vCPU の最大数を選択します。
1. (オプション) **タグ** を展開します。タグを追加するには、**タグの追加** を選択します。次に、**キー** 名を入力し、オプションで **値** を入力します。**[タグを追加]** を選択します。詳細については、[AWS Batch リソースのタグ付け](using-tags.md)を参照してください。
1. **次のページ** を選択します。
1. **レビュー** では、設定手順を確認します。変更する必要がある場合は、**[編集]** を選択します。完了したら、**コンピューティング環境の作成** を選択します。
# チュートリアル: Amazon EKS リソースを使用してマネージド型のコンピューティング環境を作成する
Amazon Elastic Kubernetes Service (Amazon EKS) リソースを使用してマネージドコンピューティング環境を作成するには、次の手順を実行します。
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) で AWS Batch コンソールを開きます。
1. ナビゲーションバーから、 AWS リージョン 使用する を選択します。
1. ナビゲーションペインで、**コンピューティング環境]** を選択します。
1. **作成]** を選択します。
1. **コンピューティング環境の設定** で、**Amazon Elastic Kubernetes Service (Amazon EKS)** を選択します。
1. **名前** で、コンピューティング環境の一意な名前を指定します。名前の最大長は 128 文字です。大文字、小文字、数字、ハイフン (-)、アンダースコア (\$1) を含めることができます。
1. **インスタンスロール** では、必要な IAM アクセス許可がアタッチされた既存のインスタンスプロファイルを使用することを選択します。
**注記**
AWS Batch コンソールでコンピューティング環境を作成するには、 `eks:ListClusters`および アクセス`eks:DescribeCluster`許可を持つインスタンスプロファイルを選択します。
1. **EKS クラスター** で、既存の Amazon EKS クラスターを選択します。
1. **名前空間** で、クラスター内の AWS Batch プロセスをグループ化する Kubernetes 名前空間を入力します。
1. (オプション) **タグ** を展開します。**タグの追加** を選択し、キーと値のペアを入力します。
1. **次のページ** を選択します。
1. (オプション) **EC2 スポットインスタンスを使用** で、**スポットインスタンスの使用を有効にする** をオンにして Amazon EC2 スポットインスタンスを使用します。
1. (スポットの場合のみ) **上限のオンデマンド価格の割合 (%)** で、インスタンス起動前のインスタンスタイプのオンデマンド価格と対比したスポットインスタンス価格の最大パーセンテージを選択します。例えば、上限価格が 20% の場合、その EC2 インスタンスのスポット料金は現在のオンデマンド料金の 20% 未満にする必要があります。支払い額は常に最低 (市場料金) となり、最大パーセンテージを超えることはありません。このフィールドを空のままにした場合、デフォルト値はオンデマンド料金の 100% です。
1. (スポットのみ) **スポットフリートロール** で、`SPOT` コンピューティング環境用の Amazon EC2 スポットフリート IAM ロールを選択します。
**重要**
このロールは、配分戦略が `BEST_FIT` に設定されている場合、または指定されていない場合に必要です。
1. (オプション) **最小 vCPU** で、ジョブキューの需要にかかわらず、コンピューティング環境で維持する vCPU の最小数を選択します。
1. (オプション) **最大 vCPU** で、ジョブキューの需要にかかわらず、コンピューティング環境でスケールアウトできる vCPU の最大数を選択します。
1. (オプション) **スケールダウン遅延 (分)** では、ジョブの完了後にコンピューティング環境でインスタンスを実行 AWS Batch し続ける最小時間 (分単位) を選択します。
1. **許可されたインスタンスタイプ]** では、起動できる Amazon EC2 インスタンスタイプを選択します。インスタンスファミリーを指定してそのファミリー内のいずれかのインスタンスタイプ (`c5`、`c5n`、`p3`など) を起動できます。または、ファミリー内の特定のサイズを指定することもできます (`c5.8xlarge`)。メタルインスタンスタイプはインスタンスファミリーに含まれていません。例えば、`c5` は `c5.metal` を含んでいません。
AWS Batch 次のいずれかを選択した場合、 はインスタンスタイプを選択できます。
+ `optimal` を選択すると、ジョブキューの需要に見合ったインスタンスタイプを (`c4`、`m4`、`r4`、`c5`、`m5` および `r5` インスタンスファミリーから) 選択します。
+ `default_x86_64` を選択すると、ジョブキューのリソース需要に見合った x86 ベースのインスタンスタイプを (m6i、c6i、r6i、c7i インスタンスファミリーから) 選択します。
+ `default_arm64` を選択すると、ジョブキューのリソース需要に見合った x86 ベースのインスタンスタイプを (m6g、c6g、r6g、c7g インスタンスファミリーから) 選択します。
**注記**
2025 年 11 月 1 日以降、`optimal` の動作は `default_x86_64` と一致するように変更されます。変更中、インスタンスファミリーは新しい世代に更新される可能性があります。アップグレードを実行するためにアクションを実行する必要はありません。変更に関する詳細については、「[インスタンスファミリーの自動更新を受信するための最適なインスタンスタイプの設定](optimal-default-instance-troubleshooting.md)」を参照してください。
**注記**
インスタンスファミリーの可用性は、 AWS リージョンによって異なります。例えば、一部の AWS リージョンには第 4 世代のインスタンスファミリーがないが、第 5 世代と第 6 世代のインスタンスファミリーがある場合があります。
`default_x86_64` またはインスタンス`default_arm64`バンドルを使用する場合、 は費用対効果とパフォーマンスのバランスに基づいてインスタンスファミリー AWS Batch を選択します。新世代のインスタンスでは価格パフォーマンスが向上することがよく AWS Batch ありますが、ワークロードの可用性、コスト、パフォーマンスを最適に組み合わせれば、旧世代のインスタンスファミリーを選択することもできます。例えば、c6i インスタンスと c7i インスタンス AWS リージョン の両方が利用可能な では、特定のジョブ要件に対して費用対効果が高い c6i インスタンス AWS Batch を選択できます。 AWS Batch インスタンスタイプと AWS リージョン 可用性の詳細については、[「インスタンスタイプのコンピューティングテーブル](instance-type-compute-table.md#instance-type-compute-table.title)」を参照してください。
AWS Batch は、デフォルトのバンドル内のインスタンスを、よりコスト効率の高い新しいオプションに定期的に更新します。更新は、ユーザーからのアクションを必要とせずに自動的に行われます。ワークロードは、更新中も中断せずに実行され続けます。
**注記**
コンピューティング環境を作成する際、そのコンピューティング環境で選択するインスタンスタイプで同じアーキテクチャを使用する必要があります。例えば、x86 と ARM インスタンスを同じコンピューティング環境で使用することはできません。
**注記**
AWS Batch は、ジョブキューの必要量に基づいて GPUs をスケーリングします。GPU スケジューリングを使用するには、コンピューティング環境に `p6`、`p3`、`p4`、`p5`、`g3`、`g3s`、`g4`、`g5`、または `g6` ファミリーのインスタンスタイプを含める必要があります。
1. (オプション) **[追加設定]** を展開します。
1. (オプション) **プレイスメントグループ** では、プレイスメントグループ名を入力して、コンピューティング環境内のリソースをグループ化します。
1. **配分戦略** で、**BEST\$1FIT\$1PROGRESSIVE** を選択します。
1. (オプション) **Amazon マシンイメージ (AMI) 設定** で、**Amazon マシンイメージ (AMI) 設定の追加** を選択します。
Amazon EKS 最適化 Amazon Linux AMI またはカスタム AMI のいずれかを使用できます。
1. [Amazon EKS 最適化 Amazon Linux AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html) を使用するには:
1. **[イメージタイプ]** で、以下のいずれかを選択します。
+ [Amazon Linux 2](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): すべての Graviton AWS ベースのインスタンスファミリー (、、`C6g``M6g`、 など`T4g`) のデフォルトであり`R6g`、すべての非 GPU インスタンスタイプに使用できます。
+ [Amazon Linux 2 (高速)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): すべての GPU インスタンスファミリー ( `P4`や など`G4`) AWS のデフォルトであり、すべての Graviton ベースのインスタンスタイプで使用できます。
+ [Amazon Linux 2023](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): は Amazon Linux 2023 (AL2023) AWS Batch をサポートしています。
+ [Amazon Linux 2023 (accelerated)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): GPU インスタンスファミリーで、非 AWS Graviton ベースのすべてのインスタンスタイプに使用できます。
1. **[Kubernetesバージョン]** に、[Kubernetes バージョン番号](supported_kubernetes_version.md#supported_kubernetes_version.title)を入力します。
1. カスタム AMI を使用するには:
1. **[イメージタイプ]** で、カスタム AMI の基となる AMI タイプを選択します。
+ [Amazon Linux 2](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): すべての Graviton AWS ベースのインスタンスファミリー (、、`C6g``M6g`、 など`T4g`) のデフォルトであり`R6g`、すべての非 GPU インスタンスタイプに使用できます。
+ [Amazon Linux 2 (高速)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): すべての GPU インスタンスファミリー ( `P4`や など`G4`) AWS のデフォルトであり、すべての Graviton ベースのインスタンスタイプで使用できます。
+ [Amazon Linux 2023](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): AL2023 AWS Batch をサポートしています。
+ [Amazon Linux 2023 (accelerated)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): GPU インスタンスファミリーで、非 AWS Graviton ベースのすべてのインスタンスタイプに使用できます。
1. **[イメージ ID オーバーライド]** には、カスタム AMI ID を入力します。
1. **[Kubernetesバージョン]** に、[Kubernetes バージョン番号](supported_kubernetes_version.md#supported_kubernetes_version.title)を入力します。
1. (オプション) **[起動テンプレート]** で、既存の [[起動テンプレート]](eks-launch-templates.md#eks-launch-templates.title) を選択します。
1. (オプション) **起動テンプレートのバージョン** では、**\$1Default** または **\$1Latest** を使用するか、あるいは起用するバージョン番号を指定します。
1. (オプション) **[起動テンプレートのオーバーライド]** でオーバーライドを追加するには、**[起動テンプレートのオーバーライドを追加]** を選択します。
1. (オプション) **[起動テンプレート]** で、オーバーライドを追加する起動テンプレートを選択します。
1. (オプション) **[起動テンプレートのバージョン]** で、起動テンプレートのバージョン番号、`$Default` または `$Latest` を選択します。
1. (オプション) **[ターゲットインスタンスタイプ]** で、このオーバーライドを適用するインスタンスタイプまたはファミリーを選択します。これにより、**許可されたインスタンスタイプ**に含まれるインスタンスタイプとファミリーのみをターゲットにできます。
1. (オプション) **userdataType** で EKS ノードの初期化を選択します。起動テンプレートまたは起動テンプレートのオーバーライドとして AMI が指定されている場合にのみ、このフィールドを使用します。`EKS_AL2023`、`EKS_AL2023_NVIDIA` に基づくカスタム AMI には **EKS\$1NODEADM**、`EKS_AL2` および `EKS_AL_NVIDIA` には **EKS\$1BOOSTRAP\$1SH** を選択します。デフォルト値は **EKS\$1BOOSTRAP\$1SH** です。
同じコンピューティング環境で AL2 と AL2023 ベースのカスタム AMI の両方を使用している[混合環境](mixed-ami-environments.md#mixed-ami-environments.title)の場合は、**userdataType** を使用します。
1. **次のページ** を選択します。
1. **仮想プライベートクラウド (VPC) ID** で、インスタンスを起動する先の VPC を選択します。
1. **サブネット** では、使用するサブネットを選択します。デフォルトでは、選択した VPC 内のすべてのサブネットを使用できます。
**注記**
AWS Batch Amazon EKS の では、ローカルゾーンがサポートされています。詳細については、[「Amazon EKS ユーザーガイド」の「Amazon EKS と AWS ローカルゾーン](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html)」を参照してください。 **
1. (オプション) **セキュリティグループ** で、インスタンスにアタッチするセキュリティグループを選択します。デフォルトでは、VPC のデフォルトのセキュリティグループが選択されます。
1. **次のページ** を選択します。
1. **レビュー** では、設定手順を確認します。変更する必要がある場合は、**[編集]** を選択します。完了したら、**コンピューティング環境の作成** を選択します。
# チュートリアル: Amazon EKS リソースを使用してアンマネージド型のコンピューティング環境を作成する
Amazon Elastic Kubernetes Service (Amazon EKS) リソースを使用してアンマネージド型のコンピューティング環境を作成するには、次の手順を実行します。
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) で AWS Batch コンソールを開きます。
1. ページ上部のナビゲーションバーから、 AWS リージョン 使用する を選択します。
1. ナビゲーションペインで、**コンピューティング環境]** を選択します。
1. **[作成]** を選択します。
1. 環境を設定します。
1. **コンピューティング環境の設定** で、**Amazon Elastic Kubernetes Service (Amazon EKS)** を選択します。
1. **オーケストレーションタイプ** で、**アンマネージド** を選択します。
1. **名前** で、コンピューティング環境の一意な名前を指定します。名前の最大長は 128 文字です。大文字、小文字、数字、ハイフン (-)、アンダースコア (\$1) を含めることができます。
1. **EKS クラスター** で、既存の Amazon EKS クラスターを選択します。新しい EKS クラスターを作成するには、[「Amazon EKS クラスターの作成」ページの](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)ステップに従います。
1. **名前空間** で、クラスター内の AWS Batch プロセスをグループ化する Kubernetes 名前空間を入力します。
1. (オプション) **最大 vCPUs**、プロビジョニングされた容量からジョブスケジューリングに使用できる vCPUs の最大数を指定します。
1. (オプション) **タグ** を展開します。**タグの追加** を選択し、キーと値のペアを入力します。
1. **次のページ** を選択します。
1. **レビュー** では、設定手順を確認します。変更する必要がある場合は、**[編集]** を選択します。完了したら、**コンピューティング環境の作成** を選択します。
**アンマネージド型のコンピューティング環境に Amazon EKS クラスターノードを割り当てる**
アンマネージド型のコンピューティング環境を作成したら、Amazon EKS ノードにコンピューティング環境 UUID のラベルを付ける必要があります。
まず、`DescribeComputeEnvironments`API 結果からコンピューティング環境 UUID を取得します。
```
$ aws batch describe-compute-environments \
--compute-environments unmanagedEksCE \
--query "computeEnvironments[].{name: computeEnvironmentName, uuid: uuid}"
```
ノード情報を取得します。
```
kubectl get nodes -o name
```
ノードに AWS Batch コンピューティング環境 UUID のラベルを付けます。
```
kubectl label batch.amazonaws.com/compute-environment-uuid=uuid
```
# リソース: コンピューティング環境テンプレート
次の例では、空のコンピューティング環境テンプレートを示しています。このテンプレートを使ってコンピューティング環境を作成し、それをファイルに保存して AWS CLI `--cli-input-json` オプションで使用できます。これらのパラメータの詳細については、「[CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html)」 (*AWS Batch API リファレンス*) を参照してください。
**注記**
コンピューティング環境テンプレートは、以下の AWS CLI コマンドで生成できます。
```
$ aws batch create-compute-environment --generate-cli-skeleton
```
```
{
"computeEnvironmentName": "",
"type": "UNMANAGED",
"state": "DISABLED",
"unmanagedvCpus": 0,
"computeResources": {
"type": "EC2",
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"minvCpus": 0,
"maxvCpus": 0,
"desiredvCpus": 0,
"instanceTypes": [
""
],
"imageId": "",
"subnets": [
""
],
"securityGroupIds": [
""
],
"ec2KeyPair": "",
"instanceRole": "",
"tags": {
"KeyName": ""
},
"placementGroup": "",
"bidPercentage": 0,
"spotIamFleetRole": "",
"launchTemplate": {
"launchTemplateId": "",
"launchTemplateName": "",
"version": ""
},
"ec2Configuration": [
{
"imageType": "",
"imageIdOverride": "",
"imageKubernetesVersion": ""
}
]
},
"serviceRole": "",
"tags": {
"KeyName": ""
},
"eksConfiguration": {
"eksClusterArn": "",
"kubernetesNamespace": ""
}
}
```
# インスタンスタイプのコンピューティングテーブル
次の表に AWS リージョン、、インスタンスファミリーキーワード、使用可能なインスタンスファミリーを示します。 AWS Batch は最新のファミリーからインスタンスを割り当てようとしますが、インスタンスファミリーの可用性はインスタンスファミリーの以前の世代によって異なる可能性があるため AWS リージョン です。
**default\$1x86\$164**
| リージョン | インスタンスファミリー |
| --- | --- |
| をサポートするすべての AWS リージョン[AWS Batch](https://docs.aws.amazon.com/general/latest/gr/batch.html) | m6i、c6i、r6i c7i |
**default\$1arm64**
| リージョン | インスタンスファミリー |
| --- | --- |
| をサポートするすべての AWS リージョン[AWS Batch](https://docs.aws.amazon.com/general/latest/gr/batch.html) | m6g、c6g、r6g c7g |
**最適**
| リージョン | インスタンスファミリー |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/batch/latest/userguide/instance-type-compute-table.html) | m4、c4、r4 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/batch/latest/userguide/instance-type-compute-table.html) | m5、c5、r5 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/batch/latest/userguide/instance-type-compute-table.html) | m6、c6、r6 |
# でコンピューティング環境を更新する AWS Batch
AWS Batch は、コンピューティング環境を更新するための複数の戦略を提供します。各戦略は、特定の更新シナリオと要件に合わせて設計されています。これらのアプローチは、同じ基盤となる更新 API を使用しますが、更新を効果的に管理するためのさまざまな規範的手法を示しています。これらの更新は、 AWS Batch コンソールまたは を使用して管理できます AWS CLI。これらの戦略を理解することで、ワークロードの中断を最小限に抑えつつ、ニーズに最適な方法を選択できます。
このトピックでは、利用可能な更新戦略の概要と、各アプローチを使用するタイミングに関するガイダンスについて説明します。詳細な手順については、各更新戦略の個々のセクションを参照してください。
**重要**
AWS Batch は、Amazon EC2 起動テンプレート、Amazon EC2 Auto Scaling グループ、Amazon EC2 スポットフリート、Amazon ECS クラスターなど、ユーザーに代わってアカウント内で複数の AWS リソースを作成および管理します。これらのマネージドリソースは、最適な AWS Batch オペレーションを確保するために特別に設定されています。これらの AWS Batchマネージドリソースを手動で変更すると、 AWS Batch ドキュメントに明示的に記載されていない限り、`INVALID`コンピューティング環境、最適ではないインスタンススケーリング動作、ワークロード処理の遅延、予期しないコストなどの予期しない動作が発生する可能性があります。これらの手動変更は、 AWS Batch サービスで決定的にサポートすることはできません。コンピューティング環境を管理するには、常にサポートされている AWS Batch APIsまたは AWS Batch コンソールを使用してください。
サポートされていない手動変更には、独自の Amazon ECS タスクまたはサービス オン AWS Batchマネージド Amazon ECS クラスターの実行、または追加のプロセス、デーモン、またはサービス AWS Batchオンマネージドインスタンスの直接開始が含まれます。 は、マネージドコンピューティング環境でコンピューティングリソースの完全な制御を AWS Batch 引き受け、インスタンスを終了したり、タスクを停止したり、クラスターをいつでもスケールしたりできます。これらのマネージドリソースで AWS Batch ジョブの送信外で実行するワークロードは、警告なしに中断される可能性があります。ワークロード以外のAWS Batch 管理 AWS Batch対象クラスターやインスタンスを実行すると、 AWS Batch ジョブのスケジュール設定やインスタンスのスケーリングも妨げられる可能性があります。
**Topics**
+ [コンピューティング環境の更新戦略](#update-strategies)
+ [適切な更新戦略の選択](#choosing-update-strategies)
+ [AMI 更新に関する考慮事項](#ami-update-considerations)
+ [スケーリングの更新を実行する](scaling-updates.md)
+ [インフラストラクチャの更新を実行する](infrastructure-updates.md)
+ [コンピューティング環境のブルー/グリーン更新を実行する](blue-green-updates.md)
## コンピューティング環境の更新戦略
スケーリングまたはインフラストラクチャの更新を使用すると、コンピューティング環境が更新されます。ブルー/グリーン更新戦略では、新しいコンピューティング環境 (グリーン) を作成し、ワークロードを古いコンピューティング環境 (ブルー) から新しいコンピューティング環境 (グリーン) に移行します。
AWS Batch には、コンピューティング環境の更新に関する 3 つの異なる戦略があります。
スケーリングの更新
スケーリングの更新は、既存のインスタンスを置き換えることなくインスタンスを追加または削除することで、コンピューティング環境の容量を調整します。これは最速の更新シナリオであり、ダウンタイムは必要ありません。容量設定 (vCPUs) を変更する必要がある場合は、スケーリングの更新を使用します。これらの更新は通常、数分で完了します。
Fargate の更新は、スケーリングの更新と同じ手順を使用して実行されます。詳細については、「[スケーリングの更新を実行する](scaling-updates.md)」を参照してください。
インフラストラクチャの更新
インフラストラクチャの更新は、コンピューティング環境のインスタンスを、設定が更新された新しいインスタンスに置き換えます。これらの更新には、特定のサービスロールと割り当て戦略の設定が必要ですが、ダウンタイムを最小限に抑えることができ、実行中のジョブが中断される可能性があります。インスタンスタイプ、AMI 設定、ネットワーク設定、サービスロール、環境の状態、またはその他のインフラストラクチャコンポーネントを変更する必要がある場合は、インフラストラクチャの更新を使用します。これらの更新は通常、ジョブの完了にもよりますが 10～30 分で完了します。
詳細については、「[インフラストラクチャの更新を実行する](infrastructure-updates.md)」を参照してください。
ブルー/グリーン更新
ブルー/グリーン更新により、既存の環境とともに新しいコンピューティング環境が作成され、ダウンタイムなしでワークロードを段階的に移行できます。このアプローチは最も安全な更新パスを提供しますが、2 つの環境を一時的に実行する必要があります。ダウンタイムゼロが必要である場合、完全なデプロイ前に変更をテストする場合、クイックロールバック機能が必要な場合、またはインフラストラクチャの更新でサポートされていない設定を使用している場合は、ブルー/グリーン更新を使用します。完了までの時間はさまざまで、ユーザーが制御します。
詳細については、「[コンピューティング環境のブルー/グリーン更新を実行する](blue-green-updates.md)」を参照してください。
## 適切な更新戦略の選択
この決定ガイドを使用して、ニーズに最も適した更新戦略を選択します。
### 次の場合は、スケーリングの更新を選択します。
コンピューティング容量 (vCPUs) を調整するだけで済む場合は、スケーリング更新戦略を選択します。スケーリングの更新は、ダウンタイムなしの迅速な更新が必要で、インフラストラクチャ設定の変更が不要な場合に最適です。
詳細な手順については、[スケーリングの更新を実行する](scaling-updates.md) を参照してください。
### 次の場合は、インフラストラクチャの更新を選択します。
インスタンスタイプ、AMI 設定、サービスロール、環境の状態、またはネットワーク設定を変更する必要がある場合は、インフラストラクチャの更新戦略を選択します。環境では、サービスにリンクされたロール *[AWSServiceRoleForBatch]* と、`BEST_FIT_PROGRESSIVE`、`SPOT_CAPACITY_OPTIMIZED`、`SPOT_PRICE_CAPACITY_OPTIMIZED` の割り当て戦略を使用する必要があります。インフラストラクチャの更新は、更新中にジョブの若干の中断が許容され、最新の Amazon ECS 最適化 AMI の自動更新が必要な場合に適しています。
詳細な手順については、[インフラストラクチャの更新を実行する](infrastructure-updates.md) を参照してください。
### 次の場合は、ブルー/グリーン更新を選択します。
ワークロードのダウンタイムがゼロである必要がある場合、または本番ワークロードの移行前に変更をテストする必要がある場合は、ブルー/グリーン更新戦略を選択します。このアプローチは、クイックロールバック機能が重要である場合、環境が `BEST_FIT` 配分戦略を使用する場合、または環境においてサービスにリンクされたロール *[AWSServiceRoleForBatch]* を使用しない場合に不可欠です。ブルー/グリーン更新は、手動更新を必要とするカスタム AMI を使用する場合や、大規模な設定変更を行う必要がある場合にも最適です。
詳細な手順については、[コンピューティング環境のブルー/グリーン更新を実行する](blue-green-updates.md) を参照してください。
## AMI 更新に関する考慮事項
AMIs を更新するアプローチは、コンピューティング環境の設定によって異なります。
### AWS Batch 提供されたデフォルトの AMI を最新の に更新する
AWS Batch は、これらの条件がすべて満たされた場合、[インフラストラクチャ](infrastructure-updates.md#infrastructure-updates.title)の更新中に最新の Amazon ECS 最適化 AMI に更新できます。
**注記**
インフラストラクチャの更新が完了すると、`updateToLatestImageVersion` が `false` に設定されます。別の更新を開始するには、`updateToLatestImageVersion` を `true` に設定する必要があります。
+ コンピューティング環境は、サービスにリンクされたロール *[AWSServiceRoleForBatch]* を使用します。
+ 割り当て戦略を `BEST_FIT_PROGRESSIVE`、`SPOT_CAPACITY_OPTIMIZED`、`SPOT_PRICE_CAPACITY_OPTIMIZED` に設定します。
+ `imageId`、`imageIdOverride` または起動テンプレートで AMI ID が明示的に指定されていない
+ `updateToLatestImageVersion` は `true` に設定されています。
### ブルー/グリーンデプロイを使用した AMI の更新
以下のシナリオでは、ブルー/グリーンデプロイを使用して AMI を更新する必要があります。
+ `BEST_FIT` 配分戦略を使用する場合 (インフラストラクチャの更新をサポートしていない)
+ [サービスにリンクされたロール](using-service-linked-roles-batch-general.md) *[AWSServiceRoleForBatch]* を使用していない場合
### カスタム AMI の AMI 更新
コンピューティング環境の起動テンプレートでカスタム AMI を指定した場合、EC2 設定の `imageId`パラメータまたは `imageIdOverride`パラメータ AWS Batch は、インフラストラクチャの更新中にカスタム AMI を自動的に更新しません。コンピューティング環境の作成時に最初に使用された パラメータで新しい ID を指定することで、カスタム AMI ID を更新できます。 AWS Batchが提供する AMI の使用に切り替える場合は、コンピューティング環境の更新でカスタム AMI ID を削除することで切り替えることができます。
# スケーリングの更新を実行する
スケーリングの更新では、インスタンスを追加または削除することで、コンピューティング環境の容量を調整します。これは最速の更新戦略であり、既存のインスタンスを置き換える必要はありません。スケーリングの更新は、任意のサービスロールタイプと割り当て戦略で機能するため、最も柔軟な更新オプションになります。
## スケーリングの更新をトリガーする変更
次の設定のみを変更すると、 AWS Batch はスケーリングの更新を実行します。これらの設定のいずれかを他のコンピューティング環境設定とともに変更すると、 は代わりに[インフラストラクチャの更新](infrastructure-updates.md#infrastructure-updates.title) AWS Batch を実行します。
以下の設定は、排他的に変更された場合にスケーリングの更新をトリガーします。
+ `desiredvCpus` – 環境の vCPU ターゲット数を設定します。
+ `maxvCpus` – 起動できる vCPU の最大数を定義します。
+ `minvCpus` – 維持する vCPU の最小数を指定します。
+ `minScaleDownDelayMinutes` – ジョブの完了後にコンピューティング環境でインスタンスを実行 AWS Batch し続ける最小時間 (分単位) を指定します。
**注記**
`minScaleDownDelayMinutes` は、インフラストラクチャの更新中に置き換えられるインスタンスには適用されません。
Fargate コンピューティング環境では、スケーリングの更新のためにこれらの設定を変更することもできます。
+ `securityGroupIds` – コンピューティング環境のセキュリティグループ ID。
+ `subnets` – コンピューティング環境のサブネット。
**注記**
AWS Batch は を動的`desiredvCpus`に調整するため、 を使用してスケーリング更新を開始することはお勧めしません`desiredvCpus`。代わりに、`minvCpus` を使用する必要があります。
`desiredvCpus` を更新する場合、値は `minvCpus`～`maxvCpus` である必要があります。新たな値は、現在の `desiredvCpus` 値と同等かそれ以上である必要があります。詳細については、「[`desiredvCpus` 設定を更新すると、エラーメッセージが表示されます](error-desired-vcpus-update.md)」を参照してください。
**重要**
これらのスケーリング設定のいずれかを他のコンピューティング環境設定 (インスタンスタイプ、AMI IDs、起動テンプレートなど) と一緒に変更すると、 はスケーリング更新の代わりにインフラストラクチャの更新 AWS Batch を実行します。インフラストラクチャの更新には時間がかかり、既存のインスタンスが置き換えられる可能性があります。
------
#### [ Performing scaling updates using the AWS マネジメントコンソール ]
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) で AWS Batch コンソールを開きます。
1. ナビゲーションペインで、**[環境]**、**[コンピューティング環境]** タブの順に選択します。
1. 更新するコンピューティング環境を選択します。
1. **[アクション]** を選択してから **[編集]** を選択します。
1. [スケーリングの更新をサポートする 1 つ以上の設定](#scaling-updates-triggers)を変更します。例えば、次のようになります。
+ **[最小 vCPU]** に、vCPU の最小数を入力します。
+ **[必要な vCPU]** に、vCPU の要求数を入力します。
+ **[最大 vCPU]** に、vCPU の最大数を入力します。
1. **[変更の保存]** をクリックします。
1. コンピューティング環境のステータスをモニタリングします。更新に必要なのはスケーリング操作のみであるため、すぐに完了します。
------
#### [ Performing scaling updates using the AWS CLI ]
**update-compute-environment** コマンドを使用して、スケーリングの更新を実行します。次の 2 つの例では一般的なスケーリング操作について説明しています。[スケーリングの更新をサポートする以下の設定](#scaling-updates-triggers)を 1 つ以上変更できます。
+ この例では、必要な vCPU と 最大 vCPU を更新します。
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources minvCpus=2,maxvCpus=8
```
------
## スケーリングの更新のモニタリング
AWS Batch コンソールを使用してスケーリングの更新をモニタリングし、コンピューティング環境のステータスを表示し、インスタンス数と vCPU メトリクスを確認します。**describe-compute-environments** コマンド AWS CLI で を使用して、ステータスを確認し、インスタンス数と vCPU 値をモニタリングすることもできます。
# インフラストラクチャの更新を実行する
インフラストラクチャの更新は、コンピューティング環境のインスタンスを、設定が更新された新しいインスタンスに置き換えます。この更新戦略は、スケーリング更新よりも時間がかかり、特定のサービスロールと割り当て戦略の設定が必要です。インフラストラクチャの更新は、サービスの可用性を維持しながら、基本的なコンピューティング環境設定を変更する方法を提供します。
**重要**
インフラストラクチャの更新には、サービスにリンクされたロール *[AWSServiceRoleForBatch]* と、`BEST_FIT_PROGRESSIVE`、`SPOT_CAPACITY_OPTIMIZED`、`SPOT_PRICE_CAPACITY_OPTIMIZED` の割り当て戦略が必要です。環境がこれらの要件を満たしていない場合は、代わりにブルー/グリーン更新を使用します。
## インフラストラクチャの更新をトリガーする変更
次のいずれかの設定を変更すると、 はインフラストラクチャの更新 AWS Batch を実行します。インフラストラクチャの更新は、スケーリング更新設定とともにこれらの設定を変更する場合にも発生します。
以下の設定により、インフラストラクチャの更新がトリガーされます。
**コンピューティング設定**
+ `allocationStrategy` – がインスタンスタイプ AWS Batch を選択する方法を決定します。
+ `instanceTypes` – 使用する EC2 インスタンスタイプを指定します。
+ `bidPercentage` – スポットインスタンスのオンデマンド料金の最大パーセンテージ。
+ `type` – コンピューティング環境タイプ (`EC2` または `SPOT`)。
**AMI と起動設定**
+ `imageId` – インスタンスに使用する特定の AMI。
+ `ec2Configuration` – `imageIdOverride` を含む EC2 設定。
+ `launchTemplate` – EC2 起動テンプレートの設定。
+ `ec2KeyPair` – インスタンスアクセス用の SSH キーペア。
+ `updateToLatestImageVersion` – AMI の自動更新設定。
**ネットワークとセキュリティ**
+ `subnets` – インスタンスが起動される VPC サブネット (EC2 コンピューティング環境の場合）。
+ `securityGroupIds` – インスタンスのセキュリティグループ (EC2 コンピューティング環境の場合）。
+ `placementGroup` – EC2 プレイスメントグループ設定。
**その他の設定**
+ `instanceRole` – EC2 インスタンスの IAM ロール。
+ `tags` – EC2 インスタンスに適用されるタグ。
**重要**
インフラストラクチャの更新設定をスケーリング更新設定 (`desiredvCpus`、`maxvCpus`、`minvCpus` など) とともに変更すると、 AWS Batch はインフラストラクチャの更新を実行します。インフラストラクチャの更新には、スケーリングの更新よりもずっと時間がかかります。
## インフラストラクチャの更新中の AMI の選択
インフラストラクチャの更新中に、これら 3 つの設定のいずれかで AMI が指定されているかどうかに応じて、コンピュート環境の AMI ID が変更される場合があります。AMI は `imageId` (in `computeResources`)、`imageIdOverride` (in `ec2Configuration` )、または `launchTemplate` で指定されている起動テンプレートで指定されます。これらの設定のいずれにも AMI ID が指定されておらず、`updateToLatestImageVersion` 設定が `true` であるとします。次に、 でサポートされている最新の Amazon ECS 最適化 AMI AWS Batch が、インフラストラクチャの更新に使用されます。
これらの設定の少なくとも 1 つで AMI ID が指定されている場合、更新は、更新前に使用された AMI ID が提供された設定によって異なります。コンピュート環境を作成する場合、AMI ID を選択する際の優先順位は、最初に起動テンプレート、次に `imageId` の設定、最後に `imageIdOverride` の設定です。ただし、使用される AMI ID が起動テンプレートからのものである場合、`imageId` または `imageIdOverride` の設定を更新しても AMI ID は更新されません。起動テンプレートから選択した AMI ID を更新する唯一の方法は、起動テンプレートを更新することです。起動テンプレートのバージョンパラメータが `$Default` または `$Latest` の場合、指定された起動テンプレートのデフォルトまたは最新バージョンが評価されます。デフォルトで別の AMI ID が選択されている場合、または起動テンプレートの最新バージョンが選択されている場合、その AMI ID が更新に使用されます。
起動テンプレートを使用して AMI ID を選択しなかった場合は、`imageId` または `imageIdOverride` のパラメータで指定されている AMI ID が使用されます。両方を指定すると、`imageIdOverride` パラメータで指定された AMI ID が使用されます。
コンピュート環境が `imageId`、`imageIdOverride`、または `launchTemplate` パラメータで指定された AMI ID を使用しており、 AWS Batchでサポートされている最新の Amazon ECS 最適化 AMI を使用するとします。次に、更新により AMI ID を提供した設定を削除する必要があります。このため `imageId`、そのパラメータには空の文字列を指定する必要があります。このため `imageIdOverride`、`ec2Configuration` パラメータには空の文字列を指定する必要があります。
AMI ID が起動テンプレートから取得されている場合は、次のいずれかの方法で AWS Batch でサポートされている最新の Amazon ECS 最適化 AMI に変更できます。
+ `launchTemplateId` または `launchTemplateName` パラメータに空の文字列を指定して、起動テンプレートを削除します。これにより、AMI ID だけではなく、起動テンプレート全体が削除されます。
+ 更新バージョンの起動テンプレートで AMI ID が指定されていない場合は、`updateToLatestImageVersion` パラメータを `true` に設定する必要があります。
## 更新中のジョブ処理
更新ポリシーを使用してインフラストラクチャ更新時に実行されているジョブの処理方法を設定します。`terminateJobsOnUpdate=true` を設定すると、実行中のジョブはすぐに終了し、`jobExecutionTimeoutMinutes` 設定は無視され、インスタンスが置き換えられるとすぐに更新が続行されます。`terminateJobsOnUpdate=false` を設定すると、実行中のジョブは指定されたタイムアウト期間中は継続され (デフォルトのタイムアウトは 30 分)、タイムアウト期間を超えるとジョブは終了します。
**注記**
更新中に終了したジョブを再試行するには、ジョブの再試行戦略を設定します。詳細については、「[ジョブの再試行の自動化](job_retries.md)」を参照してください。
------
#### [ Performing infrastructure updates using the AWS マネジメントコンソール ]
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) で AWS Batch コンソールを開きます。
1. ナビゲーションペインで、**[環境]**、**[コンピューティング環境]** タブの順に選択します。
1. 更新するコンピューティング環境を選択します。
1. **[アクション]** を選択してから **[編集]** を選択します。
1. **[更新動作]** セクションで、実行中のジョブの処理方法を設定します。
+ **[AMI を最新バージョンに更新]** を選択すると、AMI は最新バージョンに更新されます。
+ **[更新時にジョブをすぐに終了]** を選択すると、更新プロセスの実行時にジョブを終了します。
+ **[ジョブ実行タイムアウト]** には、更新プロセスを開始する前に待機する分数を入力します。
1. [インフラストラクチャの更新が必要な設定](#infrastructure-updates-triggers)を 1 つ以上変更します。例えば、次のようになります。
+ **インスタンスロール**
+ **EC2 スポットインスタンスを使用する**
+ **許可されたインスタンスタイプ**
+ **配置グループ**
+ **EC2 キーペア**
+ **EC2 設定**
+ **起動テンプレート**
+ **サブネット**
+ **セキュリティグループ**
1. **[Save changes]** (変更の保存) をクリックします。
1. コンピューティング環境のステータスをモニタリングします。更新プロセス中に環境が `UPDATING` を示します。
------
#### [ Performing infrastructure updates using the AWS CLI ]
**update-compute-environment** コマンドを使用して、[インフラストラクチャの更新を必要とする 1 つ以上の設定](#infrastructure-updates-triggers) を変更します。次の 3 つの例は、一般的なインフラストラクチャオペレーションです。
+ この例では、インスタンスタイプを更新し、更新ポリシーを設定します。
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources instanceTypes=default_x86_64 \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=30
```
+ この例では、VPC サブネットとセキュリティグループを更新します。
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources subnets=subnet-abcd1234,subnet-efgh5678 securityGroupIds=sg-abcd1234 \
--update-policy terminateJobsOnUpdate=true
```
+ この例では、最新の Amazon ECS 最適化 AMI の自動更新を有効にします。
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources updateToLatestImageVersion=true \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=60
```
------
## インフラストラクチャの更新のモニタリング
AWS Batch コンソールを使用してインフラストラクチャの更新をモニタリングし、コンピューティング環境のステータスが に変わるのをモニタリングし`UPDATING`、インスタンスの置き換えの進行状況をモニタリングして、失敗した更新がないか確認します。コンピューティング環境の状態が `VAILD` になると、更新は成功します。CloudWatch を使用して、インスタンスの終了イベントを追跡し、更新中にジョブの状態をモニタリングすることもできます。で AWS CLI、 **describe-compute-environments** コマンドを使用してステータスを確認し、インスタンスのライフサイクルイベントをモニタリングします。
# コンピューティング環境のブルー/グリーン更新を実行する
ブルー/グリーン更新は、既存のコンピューティング環境 (ブルー) に沿って新しいコンピューティング環境 (グリーン) を作成することでダウンタイムとリスクを軽減する更新戦略です。このアプローチにより、既存の環境を運用しながら、ワークロードを新しい環境に徐々に移行できます。ブルー/グリーン更新は最も安全な更新パスを提供し、任意のサービスロールタイプまたは割り当て戦略で機能します。
## 概要:
ブルー/グリーン更新には、本番環境に最適ないくつかの利点があります。更新プロセス中にワークロードを継続的に実行することで、*ダウンタイムをゼロ*にします。このアプローチによって*簡単にロールバックできる*機能を得られ、問題が発生したらすぐに元の環境に戻すことができます。本番ワークロードに完全に切り替える前に、新しい環境のパフォーマンスを検証して*段階的な移行*戦略を実行できます。また、この方法では、元の環境は変更されず、削除されるまで動作するため、*リスク軽減*の面でも優れています。
### ブルー/グリーン更新が必要な場合
ブルー/グリーン更新は、以下の状況で使用する必要があります。
+ コンピューティング環境において `BEST_FIT` 配分戦略を使用する場合 (インフラストラクチャの更新をサポートしていない)
+ コンピューティング環境が *AWSServiceRoleForBatch* サービスにリンクされたロールを使用しない場合
+ 異なるサービスロールタイプ間で移行する必要がある場合
### ブルー/グリーン更新が推奨される場合
ブルー/グリーン更新は、ワークロードにとってダウンタイムゼロが重要な本番環境で特に推奨されます。このアプローチは、本番ワークロードを移行する前に新しい設定をテストし、変更がパフォーマンスと信頼性の要件に適合していることを確認する必要がある場合に適しています。クイックロールバック機能がオペレーションにとって重要な場合、特に大幅な変更でカスタム AMI を更新する場合は、ブルー/グリーン更新を選択します。この方法は、変更に完全にコミットする前にパフォーマンス特性と動作を検証し、更新プロセスの信頼性を提供する場合にも最適です。
### 前提条件
ブルー/グリーン更新を実行する前に、以下があることを確認してください。
+ コンピューティング環境を作成および管理するための適切な [IAM アクセス許可](IAM_policies.md#IAM_policies.title)
+ ジョブキューの設定を表示および変更するためのアクセス
+ 移行中の潜在的な障害を処理するためにジョブ定義用に設定されたジョブ再試行戦略。詳細については、「[ジョブの再試行の自動化](job_retries.md)」を参照してください。
+ 新しいコンピューティング環境の AMI ID。これは以下のいずれかとなります。
+ Amazon ECS 最適化 AMI の最近の承認済みバージョン (デフォルトで使用)
+ Amazon ECS コンテナインスタンス AMI 仕様を満たすカスタム AMI。カスタム AMI を使用する場合は、次のいずれかの方法で指定できます。
+ EC2 設定で**イメージ ID オーバーライド**フィールドを使用する
+ 起動テンプレートでの指定
カスタム AMI の作成の詳細については、「[チュートリアル: コンピューティングリソース AMI を作成する](create-batch-ami.md)」を参照してください。
新しい環境を作成する前に、既存のコンピューティング環境の設定を記録する必要があります。これを行うには、 AWS マネジメントコンソール または を使用します AWS CLI。
**注記**
次の手順では、AMI のみを変更するブルー/グリーン更新を実行する方法について詳しく説明します。新しい環境の他の設定を更新できます。
**重要**
古い (ブルー) コンピューティング環境を削除すると、インスタンスが終了するため、それらのインスタンスで現在実行中のジョブはすべて失敗します。これらの障害を自動的に処理するように、ジョブ定義でジョブ再試行戦略を設定します。詳細については、「[ジョブの再試行の自動化](job_retries.md)」を参照してください。
新しい環境に確信を持てたら、以下を行います。
ジョブキューを編集して古いコンピューティング環境を削除します。
古い環境で実行中のジョブが完了するまで待ちます。
古いコンピューティング環境を削除します。
------
#### [ Performing blue/green updates using the AWS マネジメントコンソール ]
1. 現在のコンピューティング環境のクローンを作成する
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) で AWS Batch コンソールを開きます。
1. 既存のコンピューティング環境を選択します。
1. **[アクション]** を選択してから **[クローン]** を選択します。
1. **[名前]** で、新しいコンピューティング環境の一意の名前を入力します。
1. **[次へ]** を選択します。
1. **[インスタンス設定]** セクションで AMI の設定を更新します。
1. **[追加設定]** を展開します。
1. **[EC2 設定]** では、**[イメージタイプ]** に新しい AMI タイプを指定し、**[イメージ ID オーバーライド]** フィールドに AMI ID を指定します。
1. [**次へ**] を選択します。
1. **[ネットワーク設定]** で **[次へ]** を選択します。
1. 既存の環境から自動的にコピーされる他の設定を確認します。
1. **[コンピューティング環境の作成]** を選択します。
1. 新しいコンピューティング環境のステータスが `VALID` になるまで待ちます。
1. ジョブキューの順序を変更する
1. ナビゲーションペインで **[キュー]** を選択します。
1. 既存のコンピューティング環境に関連付けられているジョブキューを選択します。
1. **[編集]** を選択します。
1. **[接続されたコンピューティング環境]** で、新しいコンピューティング環境を追加します。
+ 新しいコンピューティング環境を既存の環境よりも高い順序で追加して、ワークロードを移行します。
+ 新しい環境が正しく動作していることを確認したら、低い順序の番号を付けることで、それをプライマリ環境にすることができます。
1. **[ジョブキューの更新]** を選択します。
1. クリーンアップ
1. 新しい環境でジョブの実行をモニタリングし、すべてが期待どおりに動作していることを確認します。
1. 新しい環境に確信を持てたら、以下を行います。
1. ジョブキューを編集して古いコンピューティング環境を削除します。
1. 古い環境で実行中のジョブが完了するまで待ちます。
1. 古いコンピューティング環境を削除します。
------
#### [ Performing blue/green updates using the AWS CLI ]
1. を使用して設定を取得するには AWS CLI、次のコマンドを使用します。
```
aws batch describe-compute-environments \
--compute-environments your-compute-environment-name
```
新しい環境を作成するときに、参照用に出力を保存します。
1. 既存の環境の設定を使用して新しいコンピューティング環境を作成しますが、新しい AMI を使用します。以下に、コマンド構造の例を示します。
この例の値を前のステップの実際の設定に置き換えます。
```
cat < ./blue-green-compute-environment.json
{
"computeEnvironmentName": "your-new-compute-environment-name",
"type": "MANAGED",
"state": "ENABLED",
"computeResources": {
"instanceRole": "arn:aws:iam::012345678901:instance-profile/ecsInstanceRole",
"type": "EC2",
"minvCpus": 2,
"desiredvCpus": 2,
"maxvCpus": 256,
"instanceTypes": [
"optimal"
],
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"ec2Configuration": [
{
"imageType": "ECS_AL2023",
"imageIdOverride": "ami-0abcdef1234567890"
}
],
"subnets": [,
"subnet-0abcdef1234567890"
],
"securityGroupIds": [
"sg-0abcdef1234567890"
]
}
}
EOF
```
```
$ aws batch create-compute-environment --cli-input-json file://./blue-green-compute-environment.json
```
1. 新しい環境が使用可能になるまで待ちます。
```
aws batch describe-compute-environments \
--compute-environments your-new-compute-environment-name \
--query 'computeEnvironments[].status'
```
1. 新しいコンピューティング環境をジョブキューに追加します。
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-existing-environment \
order=2,computeEnvironment=your-new-compute-environment-name
```
1. 検証したら、再度更新して新しい環境をプライマリにします。
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-new-compute-environment-name
```
古い環境ですべてのジョブが完了したら、無効にしてから削除します。
```
aws batch update-compute-environment \
--compute-environment your-existing-environment \
--state DISABLED
```
```
aws batch delete-compute-environment \
--compute-environment your-existing-environment
```
------
# コンピューティングリソースの AMI
デフォルトでは、AWS Batch のマネージド型のコンピューティング環境では、承認されたバージョンの Amazon ECS に最適化された最新の AMI をコンピューティングリソースに使用します。ただし、マネージド型およびアンマネージド型のコンピューティング環境で使用する AMI を独自に作成することもできます。次のいずれかが必要な場合は、独自の AMI を作成することをお勧めします。
+ AMIルートまたはデータボリュームのストレージサイズを増やす
+ サポートされているAmazon EC2インスタンスタイプにインスタンスストレージボリュームを追加します。
+ Amazon ECS コンテナエージェントをカスタマイズする
+ Docker をカスタマイズする
+ サポートされている Amazon EC2 インスタンスタイプで、コンテナから GPU ハードウェアにアクセスできるように GPU ワークロードの AMI を設定する
**注記**
コンピューティング環境の作成後、AWS Batch はコンピューティング環境内の AMI をアップグレードしません。また、Amazon ECS の最適化された AMI の新しいバージョンが使用可能な場合、AWS Batch はコンピューティング環境内の AMI を更新しません。ゲストオペレーティングシステムの管理はユーザーの責任です。これには、アップデートとセキュリティパッチが含まれます。また、コンピューティングリソースにインストールするその他のアプリケーションソフトウェアやユーティリティについても責任を負うものとします。AWS Batch ジョブに新しい AMI を使用するには、次の手順を実行します。
新しい AMI を使用して新しいコンピューティング環境を作成します。
コンピューティング環境を既存のジョブキューに追加します。
古いコンピューティング環境をジョブキューから削除します。
以前のコンピューティング環境を削除します。
2022 年 4 月、AWS Batch によりコンピューティング環境の更新のためにサポートが強化されました。詳細については、[でコンピューティング環境を更新する AWS Batch](updating-compute-environments.md)を参照してください。コンピューティング環境の拡張アップデートを使用して AMI を更新するには、次のルールに従います。
サービスロール([https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole))パラメータを設定しないか、**AWSServiceRoleForBatch** サービス連動ロールに設定します。
割り当て戦略 ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy)) パラメータを `BEST_FIT_PROGRESSIVE`、`SPOT_CAPACITY_OPTIMIZED`、または `SPOT_PRICE_CAPACITY_OPTIMIZED` に設定します。
最新のイメージバージョンへの更新 ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion)) パラメータを `true` に設定します。
[https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId)、[https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride)([https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html)) または起動テンプレート ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)) には AMI ID を指定しないでください。AMI ID を指定しないと、インフラストラクチャの更新が開始された時点で、AWS Batch は AWS Batch がサポートしている最新の Amazon ECS 最適化 AMIを選択します。代わりに、`imageId` または `imageIdOverride` パラメータを使用してAMI IDを指定できます。あるいは、`LaunchTemplate` プロパティによって識別される起動テンプレートを指定できます。これらのプロパティのいずれかを変更すると、インフラストラクチャの更新が開始されます。AMI ID が起動テンプレートで指定されている場合、`imageId` または `imageIdOverride` パラメータで AMI ID を指定しても AMI ID を置き換えることはできません。AMI ID は、別の起動テンプレートを指定することでのみ置き換えることができます。起動テンプレートのバージョンが `$Default` または `$Latest` に設定されている場合、AMI ID は起動テンプレートの新しいデフォルトバージョンを設定 (`$Default` の場合) するか、起動テンプレートに新しいバージョンを追加 (`$Latest` の場合) することで置き換えることができます。
これらのルールに従うと、インフラストラクチャの更新を開始する更新により、AMI ID が再選択されます。起動テンプレート ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)) の [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version) 設定が `$Latest` または `$Default` に設定されている場合、[https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate) が更新されていなくても、起動テンプレートの最新バージョンまたはデフォルトバージョンがインフラストラクチャの更新時に評価されます。
**Topics**
+ [コンピューティングリソースの AMI 仕様](batch-ami-spec.md)
+ [チュートリアル: コンピューティングリソース AMI を作成する](create-batch-ami.md)
+ [GPU ワークロードの AMI を使用する](batch-gpu-ami.md)
+ [Amazon Linux の廃止](al1-ami-deprecation.md)
+ [Amazon EKS Amazon Linux 2 AMI の廃止](eks-al2-ami-deprecation.md)
+ [Amazon ECS Amazon Linux 2 AMI の廃止](ecs-al2-ami-deprecation.md)
# コンピューティングリソースの AMI 仕様
基本的な AWS Batch コンピューティングリソース AMI の仕様は、以下の項目で構成されます。
必須
+ HVM 仮想化タイプの AMI で、バージョン 3.10 以上の Linux カーネルを実行している最新の Linux ディストリビューション。Windows コンテナはサポートされていません。
**重要**
マルチノード並列ジョブは、`ecs-init` パッケージがインストールされた Amazon Linux インスタンスで起動されたコンピューティングリソースでのみ実行できます。コンピューティング環境を作成するときに、デフォルトの Amazon ECS 最適化 AMI を使用することが推奨されます。これを行うには、カスタム AMI を指定しません。詳細については、[マルチノード並列ジョブ](multi-node-parallel-jobs.md)を参照してください。
+ Amazon ECS コンテナエージェント。最新バージョンの使用をお勧めします。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の[Amazon ECS コンテナエージェントのインストール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html)を参照してください。
+ `awslogs` ログドライバーは、Amazon ECS コンテナエージェントが開始するときの `ECS_AVAILABLE_LOGGING_DRIVERS` 環境変数として利用可能なログドライバとして指定する必要があります。詳細については、Amazon Elastic Container Service デベロッパーガイドの[Amazon ECS コンテナエージェントの構成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-config.html)を参照してください。
+ バージョン 1.9 以上を実行する Docker デーモン、および Docker ランタイムの依存関係。詳細については、Docker ドキュメントの[ランタイムの依存関係を確認する](https://docs.docker.com/engine/installation/binaries/#check-runtime-dependencies)を参照してください。
**注記**
対応する Amazon ECS エージェントバージョンに同梱されており、そのバージョンでテストされた Docker バージョンをお勧めします。Amazon ECS は、GitHub で Amazon ECS を使用して最適化した AMI の Linux バリアントの変更ログを提供します。詳細については、「[Changelog](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md)」を参照してください。
推奨
+ Amazon ECS エージェントを実行およびモニタリングするための初期化およびナニープロセス。Amazon ECS に最適化した AMI は `ecs-init` 起動プロセスを使用し、その他のオペレーティングシステムは `systemd` を使用する場合があります。詳細および例については、「*Amazon Elastic Container Service 開発者ガイド*」の「[コンテナインスタンスのユーザーデータ設定スクリプトの例](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_user_data_scripts.html)」を参照してください。`ecs-init` についての詳細は、GitHub の[`ecs-init` プロジェクト](https://github.com/aws/amazon-ecs-init)を参照してください。少なくとも、マネージド型のコンピューティング環境ではブート時に Amazon ECS エージェントをスタートする必要があります。コンピューティングリソースで実行されていない Amazon ECS エージェントでは、AWS Batch からジョブを受け入れることはできません。
Amazon ECS に最適化された AMI は、これらの要件および推奨事項に従って事前設定されています。Amazon ECS最適化AMIまたはコンピュートリソースにインストールされている`ecs-init`パッケージのAmazon Linux AMIを使用することをお勧めします。アプリケーションが特定のオペレーティングシステムや、これらのAMIでまだ利用できないDockerバージョンを必要とする場合は、別のAMIを選択してください。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の[Amazon ECS に最適化された AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)を参照してください。
# チュートリアル: コンピューティングリソース AMI を作成する
コンピューティングリソースのカスタム AMI を独自に作成して、マネージド型およびアンマネージド型のコンピューティング環境で使用できます。手順については、[コンピューティングリソースの AMI 仕様](batch-ami-spec.md)を参照してください。カスタム AMI を作成したら、その AMI を使用するコンピューティング環境を作成し、その環境をジョブキューに関連付けることができます。最後に、そのキューへのジョブの送信をスタートできます。
**コンピューティングリソースのカスタム AMI を作成するには**
1. 基本 AMI を選択してスタートします。基本 AMI は、HVM 仮想化を使用する必要があります。基本 AMI を Windows AMI にすることはできません。
**注記**
コンピューティング環境用に選択する AMI は、そのコンピューティング環境で使用するインスタンスタイプのアーキテクチャと一致している必要があります。例えば、コンピューティング環境で A1 インスタンスタイプを使用する場合、選択するコンピューティングリソース AMI で ARM インスタンスをサポートしている必要があります。Amazon ECS は、Amazon ECS に最適化された Amazon Linux 2 AMI の、x86 と ARM の両バージョンを提供しています。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の「[Amazon ECS に最適化された Amazon Linux 2 AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html)」を参照してください。
Amazon ECS に最適化された Amazon Linux 2 AMI は、マネージド型のコンピューティング環境のコンピューティングリソースのデフォルト AMI です。Amazon ECS 最適化 Amazon Linux 2 AMI は、 AWS エンジニア AWS Batch によって事前設定され、 でテストされています。これは最小限の AMI であり、 の使用を開始して、 で実行されているコンピューティングリソース AWS をすばやく取得できます。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の[Amazon ECS に最適化された AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)を参照してください。
または、別の Amazon Linux 2 バリアントを選択し、次のコマンドを使用して `ecs-init` パッケージをインストールできます。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の[Amazon Linux 2 EC2 インスタンスへの Amazon ECS コンテナエージェントのインストール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html#ecs-agent-install-al2)を参照してください。
```
$ sudo amazon-linux-extras disable docker
$ sudo amazon-linux-extras install ecs-init
```
たとえば、 AWS Batch コンピューティングリソースで GPU ワークロードを実行する場合は、[Amazon Linux Deep Learning AMI ](https://aws.amazon.com/marketplace/pp/B01M0AXXQB)から開始できます。次に、 AWS Batch ジョブを実行するように AMI を設定します。詳細については、「[GPU ワークロードの AMI を使用する](batch-gpu-ami.md)」を参照してください。
**重要**
`ecs-init` パッケージをサポートしていない基本 AMI も選択できます。ただし、その場合はブート時に Amazon ECS エージェントを開始して実行を続けるように設定する必要があります。Amazon ECS コンテナエージェントを開始してモニタリングする、`systemd` を使用したユーザーデータ設定スクリプトの例をいくつか用意しています。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の[コンテナインスタンスのユーザーデータ設定スクリプトの例](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_user_data_scripts.html)を参照してください。
1. AMI の適切なストレージオプションがある、選択された基本 AMI からインスタンスを起動します。アタッチされた Amazon EBS ボリュームまたはインスタンスストレージボリューム (選択したインスタンスタイプでサポートされている場合) のサイズと数を設定できます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launching-instance.html)」と「[Amazon EC2 インスタンスストア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)」を参照してください。
1. SSH を使用してインスタンスに接続し、必要に応じて設定タスクを実行します。これには、以下のステップのいずれかまたはすべてが含まれる場合があります。
+ Amazon ECS コンテナエージェントをインストールする 詳細については、*Amazon Elastic Container Service デベロッパーガイド*の[Amazon ECS コンテナエージェントのインストール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html)を参照してください。
+ インスタンスストアボリュームをフォーマットするスクリプトを設定する。
+ インスタンスストアボリュームまたは Amazon EFS ファイルシステムを `/etc/fstab` ファイルに追加し、ブート時にマウントする。
+ Docker オプションを設定する (デバッグの有効化、基本イメージサイズの調整など)。
+ パッケージのインストールやファイルのコピー。
詳細については、「*Amazon EC2 ユーザーガイド*」の「[SSH クライアントを使用して Linux インスタンスに接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html)」を参照してください。
1. Amazon ECS コンテナエージェントをインスタンスで開始する場合は、AMI を作成する前にインスタンスを停止して永続的なデータチェックポイントを削除する必要があります。この操作を行わないと、AMI から起動されたインスタンスでエージェントが起動しません。
1. Amazon ECS コンテナエージェントを停止します。
+ Amazon ECS 対応 Amazon Linux 2 AMI:
```
sudo systemctl stop ecs
```
+ Amazon ECS に最適化された Amazon Linux AMI:
```
sudo stop ecs
```
1. 永続的なデータチェックポイントファイルを削除します。デフォルトでは、このファイルは `/var/lib/ecs/data/` ディレクトリにあります。ファイルが存在する場合は、次のコマンドを使用してこれらのファイルを削除します。
```
sudo rm -rf /var/lib/ecs/data/*
```
1. 実行中のインスタンスから新しい AMI を作成します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EBS-backed Linux AMI を作成する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html)」を参照してください。
**で新しい AMI を使用するには AWS Batch**
1. 新しい AMI が作成されたら、新規 AMI でコンピューティング環境を作成します。これを行うには、イメージタイプを選択し、 AWS Batch コンピューティング環境を作成するときにイメージ ID オーバーライドボックスにカスタム AMI **ID** を入力します。詳細については、「[チュートリアル: Amazon EC2 リソースを使用して、マネージド型のコンピューティング環境を作成する](create-compute-environment-managed-ec2.md)」を参照してください。
**注記**
コンピューティング環境用に選択する AMI は、そのコンピューティング環境で使用するインスタンスタイプのアーキテクチャと一致している必要があります。例えば、コンピューティング環境で A1 インスタンスタイプを使用する場合、選択するコンピューティングリソース AMI で ARM インスタンスをサポートしている必要があります。Amazon ECS は、Amazon ECS に最適化された Amazon Linux 2 AMI の、x86 と ARM の両バージョンを提供しています。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の「[Amazon ECS に最適化された Amazon Linux 2 AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html)」を参照してください。
1. ジョブキューを作成し、新しいコンピューティング環境を関連付けます。詳細については、[ジョブキューを作成する](create-job-queue.md)を参照してください。
**注記**
ジョブキューに関連付けられているすべてのコンピューティング環境で、同じアーキテクチャを共有する必要があります。 AWS Batch では、単一のジョブキューでのコンピューティング環境アーキテクチャタイプの混在をサポートしていません。
1. (オプション) 新しいジョブキューにサンプルジョブを送信します。詳細については[ジョブ定義の例](example-job-definitions.md)、[シングルノードのジョブ定義を作成する](create-job-definition.md)、および[チュートリアル: ジョブを送信する](submit_job.md)を参照してください。
# GPU ワークロードの AMI を使用する
ユーザーの AWS Batch コンピューティングリソースで GPU ワークロードを実行するには、GPU 対応の AMI を使用する必要があります。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の [Amazon ECS での GPU の使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-gpu.html)および [Amazon ECS に最適化された AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)を参照してください。
マネージドコンピューティング環境では、コンピューティング環境で `p3`、`p4`、`p5`、`p6`、`g3`、`g3s`、`g4`、`g5`、`g6` のインスタンスタイプまたはインスタンスファミリーが指定されている場合、AWS Batch は Amazon ECS GPU 最適化 AMI を使用します。
アンマネージド型のコンピューティング環境では、 Amazon ECS GPU に最適化された AMI をお勧めします。AWS Command Line Interface または AWS Systems Manager パラメータストアの [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html)、[GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html)、および [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html) オペレーションを使用して、推奨される Amazon ECS GPU 最適化 AMI のメタデータを取得できます。
**注記**
`p5` のインスタンスファミリーは、Amazon ECS GPU に最適化された AMI に等しいバージョン、または Amazon ECS GPU に最適化された AMI の `20230912` よりも遅いバージョンでのみサポートされており、`p2` および `g2` のインスタンスタイプとは互換性がありません。`p5` インスタンスを使用する必要がある場合は、コンピューティング環境に `p2` または `g2`の インスタンスが含まれておらず、最新のデフォルトの Batch AMI を使用していることを確認してください。新しいコンピューティング環境を作成すると最新の AMI が使用されますが、ユーザーが `p5` を追加するようにコンピューティング環境を更新する場合は、`ComputeResource` プロパティで [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion) を `true` に設定することにより、最新の AMI を使用していることを確認できます。AMIのGPUインスタンスと互換性の詳細については、Amazon Elastic Container Service デベロッパーガイドの[Amazon ECS での GPU との連動](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-gpu.html)を参照してください。
次に、[GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html) コマンドの使用方法を示します。
------
#### [ AWS CLI ]
```
$ aws ssm get-parameter --name /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended \
--region us-east-2 --output json
```
出力には、`Value` パラメータのAMI 情報が含まれています。
```
{
"Parameter": {
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended",
"LastModifiedDate": 1555434128.664,
"Value": "{\"schema_version\":1,\"image_name\":\"amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs\",\"image_id\":\"ami-083c800fe4211192f\",\"os\":\"Amazon Linux 2\",\"ecs_runtime_version\":\"Docker version 18.06.1-ce\",\"ecs_agent_version\":\"1.27.0\"}",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended"
}
}
```
------
#### [ Python ]
```
from __future__ import print_function
import json
import boto3
ssm = boto3.client('ssm', 'us-east-2')
response = ssm.get_parameter(Name='/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended')
jsonVal = json.loads(response['Parameter']['Value'])
print("image_id = " + jsonVal['image_id'])
print("image_name = " + jsonVal['image_name'])
```
出力には、AMI ID と AMI 名のみが含まれます。
```
image_id = ami-083c800fe4211192f
image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs
```
------
[GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html) の使用例を以下に示します。
------
#### [ AWS CLI ]
```
$ aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name \
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id \
--region us-east-2 --output json
```
出力にはパラメータそれぞれの完全なメタデータが含まれています。
```
{
"InvalidParameters": [],
"Parameters": [
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id",
"LastModifiedDate": 1555434128.749,
"Value": "ami-083c800fe4211192f",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name",
"LastModifiedDate": 1555434128.712,
"Value": "amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name"
}
]
}
```
------
#### [ Python ]
```
from __future__ import print_function
import boto3
ssm = boto3.client('ssm', 'us-east-2')
response = ssm.get_parameters(
Names=['/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name',
'/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id'])
for parameter in response['Parameters']:
print(parameter['Name'] + " = " + parameter['Value'])
```
出力には、AMI ID とAMI 名が含まれており、フルパス名が使用されています。
```
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id = ami-083c800fe4211192f
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs
```
------
以下の例は、[GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html)コマンドの使用方法を示しています。
------
#### [ AWS CLI ]
```
$ aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended \
--region us-east-2 --output json
```
出力には、指定されたパスに基づくすべてのパラメータの完全なメタデータが含まれています。
```
{
"Parameters": [
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version",
"LastModifiedDate": 1555434128.801,
"Value": "1.27.0",
"Version": 8,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version",
"LastModifiedDate": 1548368308.213,
"Value": "Docker version 18.06.1-ce",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id",
"LastModifiedDate": 1555434128.749,
"Value": "ami-083c800fe4211192f",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name",
"LastModifiedDate": 1555434128.712,
"Value": "amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os",
"LastModifiedDate": 1548368308.143,
"Value": "Amazon Linux 2",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version",
"LastModifiedDate": 1548368307.914,
"Value": "1",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version"
}
]
}
```
------
#### [ Python ]
```
from __future__ import print_function
import boto3
ssm = boto3.client('ssm', 'us-east-2')
response = ssm.get_parameters_by_path(Path='/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended')
for parameter in response['Parameters']:
print(parameter['Name'] + " = " + parameter['Value'])
```
出力には、名前のフルパスを使用して、指定されたパスにあるすべてのパラメータ名の値が含まれています。
```
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version = 1.27.0
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version = Docker version 18.06.1-ce
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id = ami-083c800fe4211192f
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os = Amazon Linux 2
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version = 1
```
------
詳細については、*Amazon Elastic Container Service デベロッパーガイド*の[Amazon ECS に最適化された AMI メタデータの取得](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html)を参照してください。
# Amazon Linux の廃止
Amazon Linux AMI (Amazon Linux 1 とも呼ばれます) は 2023 年 12 月 31 日にサポートを終了しました。AWS Batch は 2024 年 1 月 1 日以降、Amazon Linux AMI のセキュリティ更新プログラムやバグ修正を受け取れないため、サポートを終了しました。Amazon Linux のサポート終了の詳細については「[Amazon Linux AMI に関するよくある質問](https://aws.amazon.com/amazon-linux-ami/faqs/)」を参照してください。
予期しないワークロードの中断を避け、セキュリティ更新プログラムやその他の更新プログラムを引き続き受け取れるように、既存の Amazon Linux ベースのコンピューティング環境を Amazon Linux 2023 にアップデートすることをお勧めします。
Amazon Linux AMI を使用するコンピューティング環境は、2023 年 12 月 31 日のサポート終了日を過ぎても機能し続ける可能性があります。ただしこれらのコンピューティング環境は、AWS から新しいソフトウェア更新、セキュリティパッチ、バグ修正を受け取ることはできません。サポート終了後に Amazon Linux AMI 上のこうしたコンピューティング環境を維持することはお客様の責任となります。最適なパフォーマンスとセキュリティを維持するために、AWS Batch コンピューティング環境を Amazon Linux 2023 または Amazon Linux 2 に移行することをお勧めします。
AWS Batch を Amazon Linux AMI から Amazon Linux 2023 または Amazon Linux 2 に移行する際のサポートについては、「[コンピューティング環境を更新します - AWS Batch](https://docs.aws.amazon.com/batch/latest/userguide/updating-compute-environments.html)」を参照してください。
# Amazon EKS Amazon Linux 2 AMI の廃止
AWS は、2025 年 11 月 26 日より、Amazon EKS 最適化 Amazon Linux 2 AMI のサポートを終了します。最適なパフォーマンスとセキュリティを維持するために、2025 年 11 月 26 日よりも前に AWS Batch Amazon EKS コンピューティング環境を Amazon Linux 2023 に移行することをお勧めします。
2025 年 11 月 26 日のサポート終了日を過ぎても、Amazon EKS コンピューティング環境で Batch 提供の Amazon EKS 最適化 Amazon Linux 2 AMI を引き続き使用できますが、これらのコンピューティング環境は AWS から新しいソフトウェア更新、セキュリティパッチ、バグ修正を受け取れなくなります。サポート終了後に Amazon EKS 最適化 Amazon Linux 2 AMI 上のこうしたコンピューティング環境を維持することはお客様の責任となります。
Amazon EKS AL2 サポート終了の詳細については、「*Amazon EKS ユーザーガイド*」の「[Amazon EKS AMI の廃止に関するよくある質問](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html)」を参照してください。
AWS Batch Amazon EKS コンピューティング環境を Amazon Linux 2 から Amazon Linux 2023 に移行するためのサポートについては、「[EKS AL2 から EKS AL2023 へアップグレードする方法](eks-migration-2023.md)」を参照してください。
# Amazon ECS Amazon Linux 2 AMI の廃止
AWS は Amazon Linux 2 のサポートを終了します。2026 年 1 月から、AWS Batch は新しい Amazon ECS コンピューティング環境のデフォルト AMI を Amazon Linux 2 から Amazon Linux 2023 に変更します。最適なパフォーマンスとセキュリティを維持するために、AWS Batch Amazon ECS コンピューティング環境を Amazon Linux 2023 に移行することをお勧めします。
Amazon Linux 2 のサービス終了の詳細については、「[Amazon Linux 2 に関するよくある質問](https://aws.amazon.com/amazon-linux-2/faqs/)」を参照してください。
Amazon Linux 2 および Amazon Linux 2023 の相違点の詳細については、「*Amazon Linux 2023 ユーザーガイド*」の「[Amazon Linux 2 と Amazon Linux 2023 の比較](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html)」を参照してください。
Amazon ECS 最適化 AMI における Amazon Linux 2023 の変更については、「*Amazon ECS ユーザーガイド*」の「[Amazon Linux 2 から Amazon Linux 2023 Amazon ECS 最適化 AMI への移行](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html)」を参照してください。
AWS Batch Amazon ECS コンピューティング環境を Amazon Linux 2 から Amazon Linux 2023 に移行するためのサポートについては、「[ECS AL2 から ECS AL2023 に移行する方法](ecs-migration-2023.md)」を参照してください。
# で Amazon EC2 起動テンプレートを使用する AWS Batch
AWS Batch はAmazon EC2 EC2 起動テンプレートの使用をサポートしています。起動テンプレートを使用すると、カスタマイズされた AMIs を作成することなく、 AWS Batch コンピューティングリソースのデフォルト設定を変更できます。
**注記**
起動テンプレートは AWS Fargate リソースではサポートされていません。
コンピューティング環境に関連付ける前に、起動テンプレートを作成する必要があります。起動テンプレートは、Amazon EC2 コンソールから作成することができます。または、 AWS CLI または AWS SDK を使用できます。たとえば、次の JSON ファイルは、デフォルトの AWS Batch コンピューティングリソース AMI の Docker データボリュームのサイズを変更し、暗号化するように設定する起動テンプレートを表します。
```
{
"LaunchTemplateName": "increase-container-volume-encrypt",
"LaunchTemplateData": {
"BlockDeviceMappings": [
{
"DeviceName": "/dev/xvda",
"Ebs": {
"Encrypted": true,
"VolumeSize": 100,
"VolumeType": "gp2"
}
}
]
}
}
```
前の起動テンプレートを作成するには、JSON を という名前のファイルに保存`lt-data.json`し、次の AWS CLI コマンドを実行します。
```
aws ec2 --region create-launch-template --cli-input-json file://lt-data.json
```
起動テンプレートの詳細については、「*Amazon EC2 ユーザーガイド*」の「[起動テンプレートからのインスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)」を参照してください。
起動テンプレートを使用してコンピューティング環境を作成する場合、次の既存のコンピューティング環境パラメータを起動テンプレートに移動できます。
**注記**
上記のパラメータ (Amazon EC2 タグ以外) が起動テンプレートおよびコンピューティング環境設定の両方で指定されているとします。その場合は、コンピューティング環境パラメータが優先されます。Amazon EC2 タグは、起動テンプレートとコンピューティング環境設定間でマージされます。タグキーの対立がある場合、コンピューティング環境設定の値が優先されます。
+ Amazon EC2 のキーペア
+ Amazon EC2 AMI ID
+ セキュリティグループ ID
+ Amazon EC2 タグ
次の起動テンプレートパラメータは によって**無視されます** AWS Batch。
+ インスタンスタイプ (コンピューティング環境作成時にインスタンスタイプを指定)
+ インスタンスロール (コンピューティング環境作成時にインスタンスロールを指定)
+ ネットワークインターフェイスサブネット (コンピューティング環境の作成時に、サブネットを指定)
+ インスタンス市場オプション (スポットインスタンス設定を制御するAWS Batch 必要があります)
+ API の終了を無効にする (インスタンスのライフサイクルを制御するAWS Batch 必要があります)
AWS Batch は、インフラストラクチャの更新中にのみ、起動テンプレートを新しい起動テンプレートバージョンで更新します。詳細については、「[でコンピューティング環境を更新する AWS Batch](updating-compute-environments.md)」を参照してください。
## デフォルトおよびオーバーライド起動テンプレート
コンピューティング環境のデフォルトの起動テンプレートと、特定のインスタンスタイプとファミリーのオーバーライド起動テンプレートを定義できます。これは、コンピューティング環境のほとんどのインスタンスタイプにデフォルトのテンプレートを使用できるようにするのに便利です。
置換変数 `$Default` および `$Latest` は、特定のバージョンに名前を付ける代わりに使用できます。オーバーライド起動テンプレートを指定しない場合、デフォルトの起動テンプレートが自動的に適用されます。
`$Default` 変数または `$Latest`変数を使用する場合、 AWS Batch はコンピューティング環境の作成時に現在の情報を適用します。デフォルトまたは最新バージョンが今後変更される場合は、[UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) または AWS マネジメントコンソール - を使用して情報を更新する必要があります AWS Batch。
柔軟性を高めるために、特定のコンピューティングインスタンスタイプまたはファミリーに適用されるオーバーライド起動テンプレートを定義できます。
**注記**
コンピューティング環境ごとに、最大 10 個のオーバーライド起動テンプレートを指定できます。
`targetInstanceTypes` パラメータを使用して、このオーバーライド起動テンプレートを使用するインスタンスタイプまたはファミリーを選択します。インスタンスタイプまたはファミリーは、まず [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-instanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-instanceTypes) パラメータで識別する必要があります。
起動テンプレートのオーバーライドを定義し、後で削除する場合は、空の配列を渡して [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html) API オペレーションで [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides) パラメータの設定を解除できます。`UpdateComputeEnvironment` API オペレーションを送信するときに、`overrides` パラメータを含めないことも選択できます。詳細については、「」を参照してください。 [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides)
詳細については、 AWS Batch API リファレンスガイド[https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecificationOverride.html#Batch-Type-LaunchTemplateSpecificationOverride-targetInstanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecificationOverride.html#Batch-Type-LaunchTemplateSpecificationOverride-targetInstanceTypes)の「」を参照してください。
## 起動テンプレートの Amazon EC2 ユーザーデータ
起動テンプレート内の Amazon EC2 ユーザーデータを、[cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html) をインスタンス起動時に提供できます。ユーザーデータは、以下を含む一般的な設定シナリオを実行できます。ただし、これらに限定されるものではありません。
+ [ユーザーまたはグループを含む](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)
+ [パッケージのインストール](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages)
+ [パーティションおよびファイルシステムの作成](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#create-partitions-and-filesystems)
起動テンプレートの Amazon EC2 ユーザーデータは、[MIME マルチパートアーカイブ](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive)の形式であることが必要です。これは、ユーザーデータがコンピューティングリソースの設定に必要な他の AWS Batch ユーザーデータとマージされるためです。複数のユーザーデータブロックと単一の MIME マルチパートファイルを組み合わせることができます。例えば、Amazon ECS コンテナエージェントの設定情報を書き込むユーザーデータシェルスクリプトを使用して、Docker デーモンを設定するクラウドブートフックを組み合わせることができます。
を使用している場合は AWS CloudFormation、[AWS::CloudFormation::Init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html) タイプを [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html) ヘルパースクリプトとともに使用して、一般的な設定シナリオを実行できます。
MIME マルチパートファイルには次のコンポーネントが含まれます。
+ コンテンツの種類およびパート境界の宣言: `Content-Type: multipart/mixed; boundary="==BOUNDARY=="`
+ MIME バージョンの宣言: `MIME-Version: 1.0`
+ 次のコンポーネントを含む 1 つ以上のユーザーデータブロック:
+ ユーザーデータブロックの始まりを示す開始境界: `--==BOUNDARY==`。この境界の前の行は空白にしておく必要があります。
+ ブロックのコンテンツの種類の宣言: `Content-Type: text/cloud-config; charset="us-ascii"`。コンテンツの種類の詳細については、[Cloud-Init のドキュメント](https://cloudinit.readthedocs.io/en/latest/topics/format.html)を参照してください。コンテンツタイプ宣言の後の行は空白にしておく必要があります。
+ ユーザーデータのコンテンツ (例えば、シェルコマンドや `cloud-init` ディレクティブのリスト)。
+ MIME マルチパートファイルの終わりを示す、終了境界: `--==BOUNDARY==--`。この境界の前の行は空白にしておく必要があります。
**注記**
Amazon EC2 コンソールの起動テンプレートにユーザーデータを追加するには、ユーザーデータをプレーンテキストとして貼り付けます。または、ファイルからアップロードすることもできます。 AWS CLI または AWS SDK を使用する場合は、この `base64` JSON ファイルに示すように、[CreateLaunchTemplate](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateLaunchTemplate.html) を呼び出すときに、まずユーザーデータをエンコードし、その文字列を `UserData`パラメータの値として送信する必要があります。
```
{
"LaunchTemplateName": "base64-user-data",
"LaunchTemplateData": {
"UserData": "ewogICAgIkxhdW5jaFRlbXBsYXRlTmFtZSI6ICJpbmNyZWFzZS1jb250YWluZXItdm9sdW..."
}
}
```
**Topics**
+ [デフォルトおよびオーバーライド起動テンプレート](#default-lt-and-overrides)
+ [起動テンプレートの Amazon EC2 ユーザーデータ](#lt-user-data)
+ [リファレンス: Amazon EC2 起動テンプレートの例](launch-template-examples.md)
# リファレンス: Amazon EC2 起動テンプレートの例
以下は、独自のテンプレートを作成するのに使用できる MIME マルチパートファイルの例です。
**Topics**
+ [例: 既存の Amazon EFS ファイルシステムのマウント](#example-mount-an-existing-amazon-efs-file-system)
+ [例: デフォルトの Amazon ECS コンテナエージェント設定の上書き](#example-override-default-amazon-ecs-container-agent-configuration)
+ [例: 既存の Amazon FSx for Lustre ファイルシステムのマウント](#example-mount-an-existing-amazon-fsx-for-lustre-file-system)
## 例: 既存の Amazon EFS ファイルシステムのマウント
**Example**
このサンプル MIME マルチパートファイルは、コンピューティングリソースを設定して `amazon-efs-utils` パッケージをインストールし、既存の Amazon EFS ファイルシステムを `/mnt/efs` にマウントします。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"
packages:
- amazon-efs-utils
runcmd:
- file_system_id_01=fs-abcdef123
- efs_directory=/mnt/efs
- mkdir -p ${efs_directory}
- echo "${file_system_id_01}:/ ${efs_directory} efs tls,_netdev" >> /etc/fstab
- mount -a -t efs defaults
--==MYBOUNDARY==--
```
## 例: デフォルトの Amazon ECS コンテナエージェント設定の上書き
**Example**
このサンプル MIME マルチパートファイルは、コンピューティングリソースのデフォルトの Docker イメージクリーンアップ設定を上書きします。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo ECS_IMAGE_CLEANUP_INTERVAL=60m >> /etc/ecs/ecs.config
echo ECS_IMAGE_MINIMUM_CLEANUP_AGE=60m >> /etc/ecs/ecs.config
--==MYBOUNDARY==--
```
## 例: 既存の Amazon FSx for Lustre ファイルシステムのマウント
**Example**
このサンプル MIME マルチパートファイルは、コンピューティングリソースを設定して Extras Library から `lustre2.10` パッケージをインストールし、`/scratch` にある既存の Fsx for Lustre ファイルシステムを `fsx` というマウント名でマウントします。この例は Amazon Linux 2 用です。他の Linux ディストリビューションのインストール手順については、「*Amazon FSx for Lustre ユーザーガイド*」の「[Lustre Client のインストール](https://docs.aws.amazon.com/fsx/latest/LustreGuide/install-lustre-client.html)」を参照してください。詳細については、「*Amazon FSx for Lustre ユーザーガイド*」の「[Amazon FSx ファイルシステムの自動マウント](https://docs.aws.amazon.com/fsx/latest/LustreGuide/mount-fs-auto-mount-onreboot.html)」を参照してください。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"
runcmd:
- file_system_id_01=fs-0abcdef1234567890
- region=us-east-2
- fsx_directory=/scratch
- amazon-linux-extras install -y lustre2.10
- mkdir -p ${fsx_directory}
- mount -t lustre ${file_system_id_01}.fsx.${region}.amazonaws.com@tcp:fsx ${fsx_directory}
--==MYBOUNDARY==--
```
コンテナプロパティの [volumes](https://docs.aws.amazon.com/batch/latest/APIReference/API_ContainerProperties.html#Batch-Type-ContainerProperties-volumes) および [mountPoints](https://docs.aws.amazon.com/batch/latest/APIReference/API_ContainerProperties.html#Batch-Type-ContainerProperties-mountPoints) メンバーでは、マウントポイントをコンテナにマッピングする必要があります。
```
{
"volumes": [
{
"host": {
"sourcePath": "/scratch"
},
"name": "Scratch"
}
],
"mountPoints": [
{
"containerPath": "/scratch",
"sourceVolume": "Scratch"
}
],
}
```
# インスタンスメタデータサービス (IMDS) の設定
インスタンスメタデータサービス (IMDS) は、EC2 インスタンスに関するメタデータを、それらのインスタンスで実行されているアプリケーションに提供します。すべての新しいワークロードに IMDSv2 を使用し、既存のワークロードを IMDSv1 から IMDSv2 に移行してセキュリティを強化します。IMDS と IMDS の設定の詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータを使用して EC2 インスタンスを管理する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)」および「[新しいインスタンスのインスタンスメタデータオプションを設定する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html)」を参照してください。
## 設定シナリオ
コンピューティング環境の設定に基づいて、適切な設定方法を選択する:
### 起動テンプレートのないデフォルトの AMI
デフォルトの AWS Batch AMI を使用し、起動テンプレートを指定しない場合は、次のいずれかのオプションを選択する:
1. **Amazon Linux 2023 のデフォルト AMI を使用する** – Amazon Linux 2023 では、デフォルトで IMDSv2 が必要です。コンピューティング環境を作成するときは、イメージタイプとして **Amazon Linux 2023** を選択します。
1. **アカウントレベルの IMDSv2 設定を指定** – すべての新しいインスタンスにIMDSv2 を要求するように AWS アカウントを設定します。この設定は、アカウントで起動するすべての新しいインスタンスに影響します。手順については、「*Amazon EC2 ユーザーガイド*」の「[アカウントのデフォルトとして IMDSv2 を設定する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#set-imdsv2-account-defaults)」を参照してください。
**注記**
アカウントレベルの IMDS 設定は、起動テンプレートまたは AMI 設定で上書きできます。起動テンプレートの設定は、アカウントレベルの設定よりも優先されます。
### 起動テンプレートのないカスタムの AMI
起動テンプレートなしでカスタム AMI を使用する場合は、次のいずれかのオプションを選択する:
1. **Amazon Linux 2023 をベースとして使用する** – Amazon Linux 2023 をベースイメージとして使用してカスタム AMI を構築します。カスタム AMI の作成について詳しくは、「[チュートリアル: コンピューティングリソース AMI を作成する](create-batch-ami.md)」を参照してください。
1. **カスタム AMI で IMDSv2 を設定する** – カスタム AMI を作成するときに、IMDSv2 を要求するように設定します。手順については、「*Amazon EC2 ユーザーガイド*」の「[カスタム AMI のインスタンスメタデータのオプションを設定する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#configure-IMDS-new-instances-ami-configuration)」を参照してください。
1. **アカウントレベルの IMDSv2 設定を指定** – すべての新しいインスタンスにIMDSv2 を要求するように AWS アカウントを設定します。この設定は、アカウントで起動するすべての新しいインスタンスに影響します。手順については、「*Amazon EC2 ユーザーガイド*」の「[アカウントのデフォルトとして IMDSv2 を設定する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#set-imdsv2-account-defaults)」を参照してください。
**注記**
アカウントレベルの IMDS 設定は、起動テンプレートまたは AMI 設定で上書きできます。起動テンプレートの設定は、アカウントレベルの設定よりも優先されます。
### 起動テンプレートの使用
コンピューティング環境で起動テンプレートを使用する場合は、IMDSv2 を要求するメタデータオプションを起動テンプレートに追加します。Batch での起動テンプレートの使用の詳細については、「[で Amazon EC2 起動テンプレートを使用する AWS Batch](launch-templates.md)」を参照してください。
```
{
"LaunchTemplateName": "batch-imdsv2-template",
"VersionDescription": "IMDSv2 only template for Batch",
"LaunchTemplateData": {
"MetadataOptions": {
"HttpTokens": "required"
}
}
}
```
AWS CLI を使用して起動テンプレートを作成する:
```
aws ec2 create-launch-template --cli-input-json file://imds-template.json
```
# EC2 設定
AWS Batch は、EC2 および EC2 スポットコンピューティング環境に Amazon ECS に最適化された AMI を使用します。デフォルトは [Amazon Linux 2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#al2ami) (`ECS_AL2`) です。2026 年 1 月以降、デフォルトは [AL2023](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#al2023ami) (`ECS_AL2023`) に変更されます。
AWS は Amazon Linux 2 のサポートを終了します。最適なパフォーマンスとセキュリティを維持するために、AWS Batch Amazon ECS コンピューティング環境を Amazon Linux 2023 に移行することをお勧めします。詳細については、[Amazon ECS Amazon Linux 2 AMI の廃止](ecs-al2-ami-deprecation.md) を参照してください。
予期しないワークロードの中断を避け、セキュリティ更新プログラムやその他の更新プログラムを引き続き受け取れるように、既存の Amazon Linux ベースのコンピューティング環境を Amazon Linux 2023 にアップデートすることをお勧めします。
AWS Batch を Amazon Linux AMI から Amazon Linux 2023 に移行する際のサポートについては、「[ECS AL2 から ECS AL2023 に移行する方法](ecs-migration-2023.md)」を参照してください。
**Topics**
+ [ECS AL2 から ECS AL2023 に移行する方法](ecs-migration-2023.md)
# ECS AL2 から ECS AL2023 に移行する方法
AL2023 は、クラウドアプリケーションに安全かつ安定した高パフォーマンス環境を提供するように設計された、Linux ベースのオペレーティングシステムです。AL2 および AL2023 間の相違点の詳細については、「*Amazon Linux 2023 ユーザーガイド*」の「[Amazon Linux 2023 と Amazon Linux 2 の比較](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html)」を参照してください。
2026 年 1 月から、AWS Batch は新しい Amazon ECS コンピューティング環境のデフォルト AMI を Amazon Linux 2 から Amazon Linux 2023 に変更します。これは、AWS が [Amazon Linux 2 のサポートを終了する](https://aws.amazon.com/amazon-linux-2/faqs/)ためです。デフォルトの AMI は、新しいコンピューティング環境を作成するときに [imageType.Ec2Configuration](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html) フィールドに値を指定しない場合に使用されます。最適なパフォーマンスとセキュリティを維持するために、AWS Batch Amazon ECS コンピューティング環境を Amazon Linux 2023 に移行することをお勧めします。
コンピューティング環境の設定方法に応じて、AL2 から AL2023 への以下のアップグレードパスのいずれかを使用できます。
**Ec2Configuration.ImageType を使用したアップグレード**
+ 起動テンプレートまたは起動テンプレートの上書きを使用していない場合は、[Ec2Configuration.ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType) を `ECS_AL2023` (または GPU インスタンスを使用している場合は `ECS_AL2023_NVIDIA`) に変更し、[UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) を実行します。
+ [Ec2Configuration.ImageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride) を指定する場合、[Ec2Configuration.ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType) は [Ec2Configuration.ImageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride) で指定された AMI タイプと一致する必要があります。
`ImageIdOverride` と `ImageType` が一致しない場合、コンピューティング環境が正しく機能しない可能性があります。
**起動テンプレートを使用したアップグレード**
+ `ECS_AL2023` に基づいて AMI を指定する起動テンプレートを使用する場合は、起動テンプレートが Amazon Linux 2023 と互換性があることを確認してください。Amazon ECS 最適化 AMI における Amazon Linux 2023 の変更については、「*Amazon ECS ユーザーガイド*」の「[Amazon Linux 2 から Amazon Linux 2023 Amazon ECS 最適化 AMI への移行](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html)」を参照してください。
+ AL2023 AMI の場合、カスタムユーザーデータまたは初期化スクリプトが AL2023 環境およびパッケージ管理システムと互換性があることを確認します。
**CloudFormation を使用したアップグレード**
+ CloudFormation を使用してコンピューティング環境を管理する場合は、テンプレートを更新して、`Ec2Configuration` の `ImageType` プロパティを `ECS_AL2` から `ECS_AL2023` (または GPU インスタンスを使用する場合は `ECS_AL2023_NVIDIA`) に変更します。
```
ComputeEnvironment:
Type: AWS::Batch::ComputeEnvironment
Properties:
ComputeResources:
Ec2Configuration:
- ImageType: ECS_AL2023
```
次に、CloudFormation スタックを更新して変更を適用します。
+ CloudFormation テンプレートで `ImageIdOverride` を使用してカスタム AMI が指定されている場合は、AMI ID が AL2023 ベースの AMI に対応し、`ImageType` 設定と一致していることを確認します。
## 移行に関する考慮事項
Amazon Linux 2 から Amazon Linux 2023 に移行するときは、次の点を考慮してください。
+ **パッケージ管理** – Amazon Linux 2023 はパッケージ管理において `yum` の代わりに `dnf` を使用します。
+ **システムサービス** – 一部のシステムサービスとその設定は、AL2 と AL2023 で異なる場合があります。
+ **コンテナランタイム** – AL2 と AL2023 はどちらも Docker をサポートしていますが、AL2023 のデフォルト設定は異なる場合があります。
+ **セキュリティ** – AL2023 には強化されたセキュリティ機能が含まれており、セキュリティ関連の設定の更新が必要になる場合があります。
+ **Instance Metadata Service Version 2 (IMDSv2)** – IMDSv2 は、EC2 インスタンスメタデータにアクセスするためにトークンベースの認証を要求するセッション指向のサービスであり、セキュリティを強化します。IMDS の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Instance Metadata Service Version 2 の仕組み](https://docs.aws.amazon.com/configuring-instance-metadata-service.html#instance-metadata-v2-how-it-works)」を参照してください。
変更と移行に関する考慮事項の包括的なリストについては、*「Amazon ECS ユーザーガイド」*の[「Amazon Linux 2 から Amazon Linux 2023 Amazon ECS 最適化 AMI への移行](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html)」を参照してください。
# AWS Batch のインスタンスタイプの配分戦略
マネージド型のコンピューティング環境が作成されると、AWS Batch はジョブのニーズに最も適したインスタンスタイプを、指定された `[instanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-instanceTypes)` から選択します。配分戦略は、AWS Batch が追加のキャパシティを必要とする場合の動作を定義します。このパラメータは、Fargate リソースで実行されているジョブには適用されません。このパラメータを指定しないようにしてください。
`BEST_FIT` (デフォルト)
AWS Batch は、最もコストの低いインスタンスタイプを優先して、ジョブのニーズに最も適したインスタンスタイプを選択します。選択したインスタンスタイプの追加インスタンスが利用できない場合、AWS Batch は追加インスタンスが利用可能になるまで待機します。十分なインスタンスが利用できない場合、またはユーザーが [Amazon EC2 Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)に達した場合、現在実行中のジョブが完了するまで追加のジョブは実行されません。この配分戦略により、コストは低くなりますが、スケーリングは制限される場合があります。`BEST_FIT` でスポットフリートを使用する場合は、スポットフリートの IAM ロールを指定する必要があります。`BEST_FIT` コンピューティング環境の更新時にはサポートされません。詳細については、[でコンピューティング環境を更新する AWS Batch](updating-compute-environments.md) を参照してください。
アカウントの AWS リソースは AWS Batch が管理します。BEST\$1FIT 配分戦略をとるコンピューティング環境には当初、デフォルトで起動設定が使用されていました。しかし、新しい AWS アカウントでの起動設定の使用は、いずれ制限されます。したがって、2024 年 4 月下旬以降、新規作成された BEST\$1FIT コンピューティング環境はデフォルトでテンプレートを起動します。サービスロールに起動テンプレートを管理するアクセス権限がない場合、AWS Batch は起動設定を引き続き使用できます。既存のコンピューティング環境では引き続き起動設定が使用されます。
`BEST_FIT_PROGRESSIVE`
AWS Batch は、キュー内のジョブの要件を満たすのに十分な大きさのインスタンスタイプを追加で選択します。vCPUあたりのコストが低いインスタンスタイプが優先されます。以前選択したインスタンスタイプの追加のインスタンスが利用できない場合、AWS Batch は新しいインスタンスタイプを選択します。
[マルチノード並列ジョブ](multi-node-parallel-jobs.md#multi-node-parallel-jobs.title)では、AWS Batch は使用できる最適なインスタンスタイプを選択します。容量不足が原因でインスタンスタイプが使用できなくなった場合、ファミリー内の他のインスタンスタイプは起動されません。
`SPOT_CAPACITY_OPTIMIZED`
AWS Batch は、キュー内のジョブの要件を満たすのに十分な大きさの 1 つ以上のインスタンスタイプを選択します。中断されにくいインスタンスタイプが推奨されます。この配分戦略は、スポットインスタンスのコンピューティングリソースでのみ使用できます。
`SPOT_PRICE_CAPACITY_OPTIMIZED`
料金とキャパシティの最適化配分戦略では、料金とキャパシティの両方を考慮して、中断される可能性が最も低く、料金が最も低いスポットインスタンスプールを選択します。この配分戦略は、スポットインスタンスのコンピューティングリソースでのみ使用できます。
ほとんどの場合、`SPOT_CAPACITY_OPTIMIZED` ではなく `SPOT_PRICE_CAPACITY_OPTIMIZED` を使用することをお勧めします。
`BEST_FIT_PROGRESSIVE` および `BEST_FIT` 戦略はオンデマンドまたはスポットインスタンスを使用し、`SPOT_CAPACITY_OPTIMIZED` および `SPOT_PRICE_CAPACITY_OPTIMIZED` 戦略はスポットインスタンスを使用します。ただし、AWS Batch はお客様の容量要件を満たすために `maxvCpus` を超える必要がある場合があります。この場合、AWS Batch は 1 つのインスタンスよりも `maxvCpus` を超えることはありません。
# コンピューティングリソースメモリの管理
Amazon ECS コンテナエージェントが、コンテナインスタンスコンピュートリソースをクラスターコンピューティング環境に登録する場合、エージェントはタスクジョブの実行のために、コンテナインスタンスコンピューティングリソースが使用できるメモリ容量を決定する必要があります。プラットフォームのメモリ・オーバーヘッドとシステム・カーネルが占有するメモリのため、この数値はAmazon EC2インスタンスのインストール済みメモリ量とは異なります。例えば、`m4.large` インスタンスには 8 GiB のメモリがインストールされています。しかし、これはコンピューティングが登録されたときに、 ジョブに厳密に8192 MiBのメモリに常に変換されるとは限りません。
ジョブに8192 MiB を指定した場合、この要件を満たす使用可能なメモリが 8192 MiB以上のメモリがないとします。その場合、そのジョブをコンピューティング環境に置くことができなくなります。マネージド型コンピューティング環境を使用している場合、リクエストに対応するためには、AWS Batchはより大きなインスタンスタイプを起動する必要があります。
デフォルト AWS Batch コンピューティングリソースAMIも、Amazon ECS コンテナエージェントやその他の重要なシステムプロセス用に32 MiBのメモリを予約します。このメモリはジョブ割り当てには利用できない。詳細については、[システムメモリを予約する](ecs-reserved-memory.md)を参照してください。
Amazon ECS コンテナエージェントは、Docker `ReadMemInfo()`関数を使用してオペレーティングシステムで使用可能な合計メモリのクエリを実行します。Linuxは、合計メモリを判断するためにコマンドラインユーティリティを提供します。
**Example - Linux 合計メモリを決定**
**free** コマンドは、オペレーティングシステムによって認識される合計メモリを復活します。
```
$ free -b
```
Amazon ECSに最適化されたAmazon Linux AMIを実行する `m4.large` インスタンスの出力例。
```
total used free shared buffers cached
Mem: 8373026816 348180480 8024846336 90112 25534464 205418496
-/+ buffers/cache: 117227520 8255799296
```
このインスタンスには 8373026816バイトの合計メモリがあります。つまり、7985 MiBがタスクに使用できます。
**Topics**
+ [システムメモリを予約する](ecs-reserved-memory.md)
+ [チュートリアル: コンピューティングリソースのメモリを表示する](viewing-memory.md)
+ [Amazon EKS の AWS Batch におけるメモリと vCPU に関する考慮事項](memory-cpu-batch-eks.md)
# システムメモリを予約する
タスクジョブでコンピューティングリソース上の全メモリを占有している場合、タスクジョブがメモリを必要とする重要なシステムプロセスと競い、システム障害の引き金となる可能性があります。Amazon ECS コンテナエージェントは、`ECS_RESERVED_MEMORY` と呼ばれる設定変数を提供します。この変数を使用して、タスクジョブに割り当てられたプールから特定のMiBメモリを削減できます。これにより、重要なシステムプロセスのメモリを効果的に確保することができます。
デフォルト AWS Batch コンピュートリソース AMI は、Amazon ECS コンテナエージェントやその他の重要なシステムプロセス用に 32 MiB のメモリを予約します。Amazon ECS コンテナエージェントやその他の重要なシステムプロセスには、5% のメモリバッファを予約することをお勧めします。
# チュートリアル: コンピューティングリソースのメモリを表示する
Amazon ECS コンソールまたは [DescribeContainerInstances](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeContainerInstances.html) API操作で、コンテナインスタンスコンピューティングリソースが登録されているメモリ量を表示できます。特定のインスタンスタイプに対して、可能な限り大きなメモリをタスクジョブに割り当てて、リソース使用率を最大化しようとする場合は、そのコンピューティングリソースに使用可能なメモリを観察でき、その後にタスクジョブに可能な限り多くのメモリを割り当てることができます。
**コンピューティングリソースのメモリを表示するために**
1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。
1. **クラスター**を選択し、表示するコンピューティングリソースをホストするクラスターを選択します。
コンピューティング環境のクラスター名は、クラスター環境名で始めます。
1. **インフラストラクチャ** を選択します。
1. **コンテナインスタンス**で、コンテナインスタンスを選択します。
1. **リソースとネットワーキング** セクションに、コンピューティングリソース用に登録され、使用できるメモリが表示されます。
**[総容量]** は、Amazon ECS の初回起動時に登録されたコンピューティングリソースのメモリの値です。**[使用可能]** メモリの値は。まだジョブに割り当てられていないメモリの値です。
# Amazon EKS の AWS Batch におけるメモリと vCPU に関する考慮事項
Amazon EKSのAWS Batchでは、コンテナで使用できるリソースを指定できます。例えば、vCPU とメモリリソースの `requests` 値、または `limits` 値を指定できます。
vCPU リソースを指定する際の制約は次のとおりです：
+ 少なくとも 1つのvCPU`requests`、または`limits`値 のいずれか指定する必要があります。
+ １つのvCPU ユニットは、１つの物理コアまたは仮想コアに相当します。
+ vCPUの値は、整数または0.25単位で入力する必要があります。
+ 有効な最小値は0.25です。
+ 両方が特定される場合、`requests`の値は`limits`の値以下でなくてはなりません。このようにして、ソフトとハードのvCPU設定の両方を行うことができます。
+ vCPU値をミリCPU形式で指定することはできません。例えば、`100m` は有効な値ではありません。
+ AWS Batch は、この `requests` 値をスケーリングの決定に使用します。`requests` 値が指定されていない場合、`limits` 値は `requests` 値にコピーされます。
メモリリソースを指定する際の制約は、次のとおりです：
+ 少なくとも1つのメモリ`requests` または `limits` 値を指定する必要があります。
+ メモリ値は mebibytes (MiBs) 内である必要があります。
+ 両方を指定する場合、`requests` 値は `limits` 値と等しくなければなりません。
+ AWS Batch は、この `requests` 値をスケーリングの決定に使用します。`requests` 値が指定されていない場合、`limits` 値は `requests` 値にコピーされます。
GPUリソースを指定する際の制約は、次のとおりです：
+ 両方を指定する場合、`requests` 値は`limits` 値と等しくなければなりません。
+ AWS Batchは、この `requests` 値をスケーリングの決定に使用します。`requests` 値が指定されていない場合、`limits` 値は `requests` 値にコピーされます。
## 例: ジョブ定義
Amazon EKS ジョブ定義の以下の AWS Batch では、ソフト vCPU 共有を設定します。これにより、Amazon EKS のAWS Batchは、インスタンスタイプの vCPU容量のすべて使用できるようになります。ただし、実行中の他のジョブがある場合、そのジョブには最大数の `2` vCPUs が割り当てられます。メモリは、2 GBに制限されています。
```
{
"jobDefinitionName": "MyJobOnEks_Sleep",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["sleep", "60"],
"resources": {
"requests": {
"cpu": "2",
"memory": "2048Mi"
}
}
}
]
}
}
}
```
Amazon EKS AWS Batch の以下のジョブ定義の`request` 値は `1` で、最大の `4` vCPUs をジョブに割り当てます。
```
{
"jobDefinitionName": "MyJobOnEks_Sleep",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["sleep", "60"],
"resources": {
"requests": {
"cpu": "1"
},
"limits": {
"cpu": "4",
"memory": "2048Mi"
}
}
}
]
}
}
}
```
以下のAmazon EKS のAWS Batchジョブ定義では 、vCPU `limits` 値をに `1`を、メモリ `limits` 値を 1 GB に設定します。
```
{
"jobDefinitionName": "MyJobOnEks_Sleep",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["sleep", "60"],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi"
}
}
}
]
}
}
}
```
AWS Batch Amazon EKS 上のジョブを Amazon EKS ポッドにAWS Batch 変換するときに、AWS Batch `limits` 値をその `requests` 値にコピーします。これは、`requests` 値が指定されていない場合です。前述のジョブ定義の例を送信すると、ポッド`spec` は次のようになります。
```
apiVersion: v1
kind: Pod
...
spec:
...
containers:
- command:
- sleep
- 60
image: public.ecr.aws/amazonlinux/amazonlinux:2
resources:
limits:
cpu: 1
memory: 1024Mi
requests:
cpu: 1
memory: 1024Mi
...
```
## ノードCPUとメモリの予約
AWS Batch は、vCPU とメモリの予約に関して`bootstrap.sh`ファイルのデフォルトロジックに依存します。`bootstrap.sh` ファイルの詳細については、[bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) を参照してください。vCPUメモリリソースのサイズを決定する場合、以下の例を検討してください。
**注記**
実行中のインスタンスがない場合、vCPUとメモリの予約が最初にAWS Batchスケーリングロジックと意思決定に影響を与える可能性があります。インスタンスが実行されたら、AWS Batch は初期割り当てを調整します。
## 例: ノード CPU 予約
CPU 予約値は、インスタンスで使用可能な vCPU の総数を使用してミリコア単位で計算されます。
| vCPU番号 | 予約率 |
| --- | --- |
| 1 | 6% |
| 2 | 1% |
| 3～4 | 0.5% |
| 4以上 | 0.25% |
上記の値を使用すると、次のようになります:
+ 仮想CPUが2つある `c5.large` インスタンスのvCPUs予約値は,70 m です。これは次の方法で計算されます：*(1\$160) \$1 (1\$110) = 70 m*。
+ 96個のvCPUsを搭載した`c5.24xlarge` インスタンスのCPU予約値は、 310 mです。これは次の方法で計算されます：(1\$160) \$1 (1\$110) \$1 (2\$15) \$1 (92\$12.5) = 310 m。
この例では、`c5.large` インスタンスでジョブを実行するために使用できるミリコアvCPU ユニットは、1930（計算は2000－70) です。ジョブに `2` (2\$11000 m) の vCPU ユニットが必要で、そのジョブが 単一の`c5.large` インスタンスに収まらないとします。ただし、`1.75` vCPU ユニットが必要なジョブには適しています。
## 例: ノードメモリ予約
メモリ予約値は、以下を使用してメビバイト単位で計算されます:
+ インスタンスキャパシティーは MB 単位です。例えば、8 GB のインスタンスは 7,748 です MiB。
+ `kubeReserved` 値。`kubeReserved` 値は、システムデーモン用に確保するメモリ量です。`kubeReserved` 値は次のように計算されます: *((11 \$1 インスタンスタイプでサポートされる最大ポッド数) \$1 255)*。各インスタンスタイプによりサポートされるポッドの最大数のリストは、GitHub の[eni-max-pods.txt](https://github.com/awslabs/amazon-eks-ami/blob/main/nodeadm/internal/kubelet/eni-max-pods.txt)を参照してください。
+ `HardEvictionLimit` 値。使用可能なメモリが`HardEvictionLimit` 値を下回ると、インスタンスはポッドを削除しようとします。
割り当て可能なメモリの計算式は次のとおりです：(*Instance\$1Capacity\$1IN\$1MIB*)-(11 \$1 (*最大ポッド数*))-255-(* `HardEvictionLimit` 値。* ))。
1つの `c5.large` インスタンスは最大29個のポッドをサポートします。`HardEvictionLimit` 値が100 MiBの8 GB `c5.large` インスタンスの場合、割り当て可能なメモリは7074ですMiB。これは次の方法で計算されます: *(7748-(11 \$1 29) -255 -100) = 7074 MiB*。この例では、8,192件のMiB のタスクジョブは 、8 gibibyte (GiB) インスタンスであるにもかかわらず、このインスタンスには当てはまりません。
## DaemonSets
DaemonSets を使用する場合は、以下を考慮してください：
+ Amazon EKS インスタンスでAWS Batchがまったく実行されていない場合、最初はDaemonSets AWS Batch のスケーリングロジックと意思決定に影響する可能性があります。AWS Batchは最初に0.5 のvCPU ユニットと、500 MiB を想定されるDaemonSetsに割り当てます。インスタンス実行されたら、AWS Batchは初期割り当てを調整します。
+ DaemonSetがvCPUまたはメモリの制限を定義している場合、Amazon EKSジョブのAWS Batchが少なくなります。AWS Batchジョブに割り当てられる DaemonSets の数は、できるだけ少なくすることをお勧めします。
# Fargate のコンピューティング環境
Fargate は、Amazon EC2 インスタンスのサーバーやクラスターを管理することなく[コンテナ](https://aws.amazon.com/what-are-containers)を実行する AWS Batch ために で使用できるテクノロジーです。Fargateを使用すると、コンテナを実行するために仮想マシンのクラスターをプロビジョニング、設定、スケールする必要がありません。これにより、サーバータイプの選択、クラスターをスケールするタイミングの決定、クラスターのパッキングの最適化を行う必要がなくなります。
Fargate リソースを使用してジョブを実行する場合、アプリケーションをコンテナにパッケージ化し、CPU とメモリ要件を指定して、ネットワークとIAM ポリシーを定義して、アプリケーションを起動します。各 Fargate ジョブは、独自の分離境界を持ち、基本となるカーネル、CPU リソース、メモリリソース、Elastic Network Interface を別のジョブと共有しません。
**Topics**
+ [Fargateをいつ使うべきか](when-to-use-fargate.md)
+ [Fargate でのジョブ定義](fargate-job-definitions.md)
+ [Fargate のジョブキュー](fargate-job-queues.md)
+ [Fargate のコンピューティング環境](fargate-compute-environments.md)
# Fargateをいつ使うべきか
ほとんどのシナリオで Fargate を使用することをお勧めします。Fargate は、コンテナに指定したリソース要件に厳密に一致するようにコンピューティングを起動し、スケールします。Fargate を使用すると、追加のサーバーに対してオーバープロビジョニングまたは料金を支払う必要はありません。また、インスタンスタイプなど、インフラストラクチャ関連のパラメータの詳細について心配する必要はありません。コンピューティング環境をスケールアップする必要がある場合、Fargate リソースで実行されるジョブをより迅速に開始できます。通常、新しい Amazon EC2 インスタンスの作成に数分かかります。しかし、Fargate で実行されるジョブは約 30 秒でプロビジョニングできます。正確な所要時間は、コンテナイメージのサイズやジョブ数など、いくつかの要因によって異なります。
ただし、ジョブに次のいずれかが必要な場合は、Amazon EC2 を使用することをお勧めします。
+ 16 個以上の vCPU
+ 120 ギガバイト (GiB) 以上のメモリ
+ 1 個のGPU
+ 1 個のカスタム Amazon マシンイメージ (AMI)
+ [LinuxParameters](job_definition_parameters.md#ContainerProperties-linuxParameters) パラメータのいずれか
ジョブの数が多い場合は、Amazon EC2 インフラストラクチャを使用することをお勧めします。例えば、同時実行ジョブの数が Fargate スロットリング制限を超える場合です。これは、EC2 では、Fargate リソースよりも高いレートで EC2 リソースにジョブをディスパッチできるためです。さらに、EC2 を使用すると、同時に実行できるジョブが増えます。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Fargate サービスクォータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html#service-quotas-fargate)」を参照してください。
# Fargate でのジョブ定義
AWS Batch の ジョブは、使用可能なすべてのジョブ定義パラメータをサポート AWS Fargate しているわけではありません。一部のパラメータはまったくサポートされていません。また、その他のパラメータは Fargate ジョブでは異なる動作をします。
次のリストでは、Fargate ジョブで有効でないか、または制限されていないジョブ定義パラメータについて説明します。
`platformCapabilities`
`FARGATE` と指定する必要があります。
```
"platformCapabilities": [ "FARGATE" ]
```
`type`
`container` と指定する必要があります。
```
"type": "container"
```
`containerProperties` のパラメータ
`executionRoleArn`
Fargate リソースで実行されているジョブには指定する必要があります。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の[タスク用の IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)を参照してください。
```
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
```
`fargatePlatformConfiguration`
(オプション、Fargate ジョブ定義の場合のみ)。Fargate プラットフォームのバージョンを指定するか、最新のプラットフォームバージョンの場合は `LATEST` を指定します。`platformVersion` の可能な値はデフォルトで `1.3.0`、`1.4.0`、`LATEST` です。
```
"fargatePlatformConfiguration": { "platformVersion": "1.4.0" }
```
`instanceType``ulimits`
Fargate リソースで実行されているジョブには適用されません。
`memory``vcpus`
これらの設定は、`resourceRequirements` で指定する必要があります。
`privileged`
このパラメータを指定しないか、`false` を指定します。
```
"privileged": false
```
`resourceRequirements`
メモリと vCPU の要件は、[サポートされている値](job_definition_parameters.md#ContainerProperties-resourceRequirements-Fargate-memory-vcpu)を使用して指定する必要があります。GPU リソースは、Fargate リソースで実行されているジョブではサポートされていません。
GuardDuty Runtime Monitoring を使用する場合、GuardDuty セキュリティエージェントには多少のメモリオーバーヘッドがあります。したがって、メモリ制限には GuardDuty セキュリティエージェントのサイズを含める必要があります。GuardDuty セキュリティエージェントのメモリ制限については、「*GuardDuty ユーザーガイド*」の「[CPU およびメモリ制限](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html#ecs-runtime-agent-cpu-memory-limits)」を参照してください。ベストプラクティスの詳細については、「*Amazon ECS 開発者ガイド*」の「[ランタイムモニタリングを有効にした後、Fargate タスクのメモリ不足エラーに対処するにはどうすればよいですか?](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-guard-duty-troubleshooting.html#memory-error)」を参照してください。
```
"resourceRequirements": [
{"type": "MEMORY", "value": "512"},
{"type": "VCPU", "value": "0.25"}
]
```
`linuxParameters` のパラメータ
`devices``maxSwap``sharedMemorySize``swappiness``tmpfs`
Fargate リソースで実行されているジョブには適用されません。
`logConfiguration` のパラメータ
`logDriver`
`awslogs` と `splunk` のみがサポートされています。詳細については、[awslogs ログドライバーを使用する](using_awslogs.md)を参照してください。
`networkConfiguration` のメンバー
`assignPublicIp`
プライベートサブネットにインターネットへトラフィックを送るための NAT ゲートウェイが接続されていない場合、`[assignPublicIp](https://docs.aws.amazon.com/batch/latest/APIReference/API_NetworkConfiguration.html#Batch-Type-NetworkConfiguration-assignPublicIp)` は`ENABLED`でなければなりません。詳細については、[AWS Batch IAM 実行ロール](execution-IAM-role.md)を参照してください。
# Fargate のジョブキュー
AWS Batch のジョブキュー AWS Fargate は基本的に変更されません。`computeEnvironmentOrder` にリストされているコンピューティング環境は、すべて Fargate のコンピューティング環境 (`FARGATE` または `FARGATE_SPOT`) であることが唯一の制限事項です。EC2 と Fargate コンピューティング環境は混在できません。
# Fargate のコンピューティング環境
AWS Batch の コンピューティング環境は、使用可能なすべてのコンピューティング環境パラメータをサポート AWS Fargate しているわけではありません。一部のパラメータはまったくサポートされていません。Fargate では特定の制限があるパラメータもあります。
次のリストでは、Fargate ジョブで有効でない、または制限されているコンピューティング環境パラメータについて説明します。
`type`
このパラメータを `MANAGED` に設定する必要があります。
```
"type": "MANAGED"
```
`computeResources` オブジェクトのパラメータ
`allocationStrategy``bidPercentage``desiredvCpus``imageId``instanceTypes``ec2Configuration``ec2KeyPair``instanceRole``launchTemplate``minvCpus``placementGroup``spotIamFleetRole`
これらは、Fargate コンピューティング環境には適用されないため、指定できません。
`subnets`
このパラメータにリストされているサブネットに NAT ゲートウェイが接続されていない場合は、ジョブ定義の `assignPublicIp` パラメータを `ENABLED` に設定する必要があります。
`tags`
これは、Fargate コンピューティング環境では適用されないため、指定できません。Fargate のコンピューティング環境用のタグを指定するには、`computeResources` オブジェクトにない `tags` パラメータを使用します。
`type`
これは `FARGATE` または `FARGATE_SPOT` であることが必要です。
```
"type": "FARGATE_SPOT"
```
# Amazon EKS コンピュート環境
[Amazon EKS AWS Batch での の開始方法](getting-started-eks.md) EKS コンピュート環境を作成するための簡単なガイドを提供します。このセクションでは、Amazon EKS のコンピューティング環境についてより詳しく説明します。
![\[AWS Batch workflow diagram showing integration with Amazon EKS, ECS, Fargate, and EC2.\]](http://docs.aws.amazon.com/ja_jp/batch/latest/userguide/images/batch-on-eks.png)
AWS Batch は、マネージドバッチ機能を提供することで、Amazon EKS クラスターのバッチワークロードを簡素化します。これには、キューイング、依存関係の追跡、マネージドジョブの再試行と優先順位、ポッド管理、ノードスケーリングが含まれます。 は、複数のアベイラビリティーゾーンと複数の Amazon EC2 インスタンスタイプとサイズを処理 AWS Batch できます。 は、いくつかの Amazon EC2 スポットのベストプラクティス AWS Batch を統合して、耐障害性のある方法でワークロードを実行するため、中断が少なくなります。 AWS Batch を使用すると、わずかな夜間ジョブや数百万のミッションクリティカルなジョブを自信を持って実行できます。
![\[AWS Batch workflow on Amazon EKS, showing job queue, compute environment, and EC2 instances.\]](http://docs.aws.amazon.com/ja_jp/batch/latest/userguide/images/batch-on-eks-detail.png)
AWS Batch は、Amazon Elastic Kubernetes Service (Amazon EKS) によって管理されるKubernetesクラスター内のバッチワークロードをオーケストレーションするマネージドサービスです。 は、「オーバーレイ」モデルを使用して、クラスターの外部でこのオーケストレーション AWS Batch を実行します。 AWS Batch はマネージドサービスであるため、クラスターにインストールまたは管理するKubernetesコンポーネント (オペレーターやカスタムリソースなど) はありません。 では、 Kubernetes API サーバーとの AWS Batch 通信を に許可するロールベースのアクセスコントロール (RBAC) Kubernetes でクラスターを設定 AWS Batch する必要があります。 は Kubernetes APIs を AWS Batch 呼び出してポッドとノードを作成、モニタリング、削除します。
AWS Batch には、ジョブ容量の割り当てに関する最適化により、ジョブキューの負荷に基づいてKubernetesノードをスケールするスケーリングロジックが組み込まれています。ジョブキューが空の場合、 はノードを設定した最小容量に AWS Batch スケールダウンします。デフォルトではゼロです。 はこれらのノードのライフサイクル全体 AWS Batch を管理し、ノードにラベルとテイントをデコレーションします。これにより、他のKubernetesワークロードは によって管理されるノードに配置されません AWS Batch。例外は です。これは`DaemonSets`、ジョブの適切な実行に必要なモニタリングやその他の機能を提供するために AWS Batch ノードをターゲットにできます。さらに、管理 AWS Batch していないクラスター内のノードでは、ジョブ、特にポッドは実行されません。こうすることで、クラスター上の他のアプリケーションに個別のスケーリングロジックとサービスを使用できます。
ジョブを送信するには AWS Batch、 AWS Batch API と直接やり取りします。 はジョブを AWS Batch に変換し`podspecs`、Amazon EKS クラスター AWS Batch の によって管理されるノードにポッドを配置するリクエストを作成します。`kubectl` などのツールを使用して、実行中のポッドやノードを表示できます。ポッドの実行が完了すると、 はKubernetesシステムへの負荷を軽減するために作成したポッド AWS Batch を削除します。
有効な Amazon EKS クラスターを に接続することで開始できます AWS Batch。次に、 AWS Batch ジョブキューをアタッチし、`podspec`同等の属性を使用して Amazon EKS ジョブ定義を登録します。最後に、ジョブ定義を参照する [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) API オペレーションを使用してジョブを送信します。詳細については、「[Amazon EKS AWS Batch での の開始方法](getting-started-eks.md)」を参照してください。
## Amazon EKS
**Topics**
+ [Amazon EKS](#compute-environments-eks)
+ [Amazon EKS デフォルト AMI](eks-ce-ami-selection.md)
+ [AMI が混在する環境](mixed-ami-environments.md)
+ [サポートされる Kubernetes バージョン](supported_kubernetes_version.md)
+ [コンピューティング環境の Kubernetes バージョンを更新する](updating-k8s-version-ce.md)
+ [Kubernetes ノードの責任分担](eks-ce-shared-responsibility.md)
+ [AWS Batch マネージドノードDaemonSetで を実行する](daemonset-on-batch-eks-nodes.md)
+ [Amazon EKS 起動テンプレートをカスタマイズする](eks-launch-templates.md)
+ [EKS AL2 から EKS AL2023 へアップグレードする方法](eks-migration-2023.md)
# Amazon EKS デフォルト AMI
Amazon EKS コンピューティング環境を作成するときは、Amazon マシンイメージ (AMI) を指定する必要はありません。 は、[CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html) リクエストで指定されたKubernetesバージョンとインスタンスタイプに基づいて Amazon EKS 最適化 AMI AWS Batch を選択します。一般的に、デフォルトの AMI 選択を使用することをお勧めします。Amazon EKS 最適化 AMI の詳細については、「*Amazon EKS ユーザーガイド*」の「[Amazon EKS 最適化 Amazon Linux AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html)」を参照してください。
**重要**
Amazon Linux 2023 AMIs は、Amazon EKS AWS Batch の のデフォルトです。
AWS は、 から Amazon EKS AL2-optimizedおよび AL2-accelerated AMIs のサポートを終了します11/26/25。サポート11/26/25end-of-supportを過ぎても、Amazon EKS コンピューティング環境で AWS Batch Amazon EKS 最適化 Amazon Linux 2 AMIs を引き続き使用できますが、これらのコンピューティング環境は から新しいソフトウェア更新、セキュリティパッチ、またはバグ修正を受け取りません AWS。AL2 から AL2023 へのアップグレードの詳細については、「*AWS Batch ユーザーガイド*」の「[EKS AL2 から EKS AL2023 へアップグレードする方法](eks-migration-2023.md)」を参照してください。
次のコマンドを実行して、Amazon EKS コンピューティング環境に AWS Batch 選択した AMI タイプを確認します。次の例は GPU 以外のインスタンスタイプです。
```
# compute CE example: indicates Batch has chosen the AL2 x86 or ARM EKS 1.32 AMI, depending on instance types
$ aws batch describe-compute-environments --compute-environments My-Eks-CE1 \
| jq '.computeEnvironments[].computeResources.ec2Configuration'
[
{
"imageType": "EKS_AL2",
"imageKubernetesVersion": "1.32"
}
]
```
次の例は GPU インスタンスタイプです。
```
# GPU CE example: indicates Batch has choosen the AL2 x86 EKS Accelerated 1.32 AMI
$ aws batch describe-compute-environments --compute-environments My-Eks-GPU-CE \
| jq '.computeEnvironments[].computeResources.ec2Configuration'
[
{
"imageType": "EKS_AL2_NVIDIA",
"imageKubernetesVersion": "1.32"
}
]
```
# AMI が混在する環境
起動テンプレートオーバーライドを使用して、Amazon Linux 2 (AL2) AMI と Amazon Linux 2023 (AL2023) AMI の両方を持つコンピューティング環境を作成できます。これは、アーキテクチャごとに異なる AMI を使用する場合や、AL2 から AL2023 への移行期間において役立ちます。
**注記**
AWS は、 から Amazon EKS AL2-optimizedおよび AL2-accelerated AMIs のサポートを終了します11/26/25。サポート11/26/25end-of-supportを過ぎても、Amazon EKS コンピューティング環境で AWS Batch Amazon EKS 最適化 Amazon Linux 2 AMIs を引き続き使用できますが、これらのコンピューティング環境は から新しいソフトウェア更新、セキュリティパッチ、またはバグ修正を受け取りません AWS。AMI が混在する環境は移行期間中に役立つため、既存の AL2 ベースのワークロードとの互換性を維持しながら、ワークロードを AL2023 に段階的に移行できます。
両方の AMI タイプを使用した設定例:
```
{
"computeResources": {
"launchTemplate": {
"launchTemplateId": "TemplateId",
"version": "1",
"userdataType": "EKS_BOOTSTRAP_SH",
"overrides": [
{
"instanceType": "c5.large",
"imageId": "ami-al2-custom",
"userdataType": "EKS_BOOTSTRAP_SH"
},
{
"instanceType": "c6a.large",
"imageId": "ami-al2023-custom",
"userdataType": "EKS_NODEADM"
}
]
},
"instanceTypes": ["c5.large", "c6a.large"]
}
}
```
# サポートされる Kubernetes バージョン
AWS Batch Amazon EKS の は現在、次のKubernetesバージョンをサポートしています。
+ `1.34`
+ `1.33`
+ `1.32`
+ `1.31`
+ `1.30`
+ `1.29`
`CreateComputeEnvironment` API オペレーションまたは API オペレーション `UpdateComputeEnvironment` を使用してコンピュート環境を作成または更新すると、次のようなエラーメッセージが表示されることがあります。この問題は、Kubernetes でサポートされていないバージョンを `EC2Configuration` で指定した場合に発生します。
```
At least one imageKubernetesVersion in EC2Configuration is not supported.
```
この問題を解決するには、コンピュート環境を削除し、サポートされている Kubernetes バージョンで再作成してください。
Amazon EKS クラスターでマイナーバージョンアップグレードを実行できます。例えば、イナーバージョンがサポートされていない場合でも、クラスターを `1.xx` から `1.yy` マにアップグレードできます。
ただし、`INVALID` メジャーバージョンを更新すると、コンピュート環境のステータスがに変わることがあります。例えば、`1.xx` から `2.yy` へのメジャーバージョンアップグレードを実行する場合などです。メジャーバージョンが でサポートされていない場合は AWS Batch、次のようなエラーメッセージが表示されます。
```
reason=CLIENT_ERROR - ... EKS Cluster version [2.yy] is unsupported
```
# コンピューティング環境の Kubernetes バージョンを更新する
を使用すると AWS Batch、Amazon EKS クラスターのアップグレードをサポートするようにコンピューティング環境Kubernetesのバージョンを更新できます。コンピューティング環境Kubernetesのバージョンは、 がジョブを実行するために AWS Batch 起動するKubernetesノードの Amazon EKS AMI バージョンです。Amazon EKS ノードの Kubernetes バージョンのアップグレードは、Amazon EKS クラスターのコントロールプレーンのバージョンを更新する前後どちらでも実行できます。コントロールプレーンをアップグレードした後に、ノードを更新することをお勧めします。詳細については、「*Amazon EKS ユーザーガイド*」の「[Amazon EKS クラスターの Kubernetes バージョンを更新](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)」を参照してください。
コンピュート環境の Kubernetes バージョンをアップグレードするには、[https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) API オペレーションを使用します。
```
$ aws batch update-compute-environment \
--compute-environment \
--compute-resources \
'ec2Configuration=[{imageType=EKS_AL2,imageKubernetesVersion=1.32}]'
```
# Kubernetes ノードの責任分担
コンピュート環境のメンテナンスは共同責任です。
+ AWS Batch ノード、ラベル、テイント、名前空間、起動テンプレート、または自動スケーリンググループを変更または削除しないでください。 AWS Batch マネージドノードにテイントを追加しないでください。これらの変更を行うと、コンピュート環境がサポートされなくなり、アイドル状態のインスタンスなどの障害が発生します。
+ ポッドを AWS Batch マネージドノードにターゲットにしないでください。ポッドを管理対象ノードにすると、スケーリングが中断したり、ジョブキューが停止したりします。セルフマネージド型ノードまたはマネージド型ノードグループ AWS Batch で を使用しないワークロードを実行します。詳細については、「*Amazon EKS ユーザーガイド*」の「[マネージドノードグループ](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)」を参照してください。
+ AWS Batch マネージドノードで実行する DaemonSet をターゲットにできます。詳細については、「[AWS Batch マネージドノードDaemonSetで を実行する](daemonset-on-batch-eks-nodes.md)」を参照してください。
AWS Batch はコンピューティング環境 AMIs を自動的に更新しません。更新するのはあなたの責任です。モジュールを最新バージョンにアップグレードするには、次のコマンドを実行します。
```
$ aws batch update-compute-environment \
--compute-environment \
--compute-resources 'updateToLatestImageVersion=true'
```
AWS Batch はKubernetesバージョンを自動的にアップグレードしません。次のコマンドを実行して、コンピュータ環境Kubernetesのバージョンを *1.32* に更新します。
```
$ aws batch update-compute-environment \
--compute-environment \
--compute-resources \
'ec2Configuration=[{imageType=EKS_AL2,imageKubernetesVersion=1.32}]'
```
Kubernetes より新しいバージョンの AMI に更新する場合、更新時にジョブを終了するかどうか (`terminateJobsOnUpdate`) と、実行中のジョブが終了しない場合にインスタンスが置き換えられるまでの待機時間 (`jobExecutionTimeoutMinutes`.) を指定できます。詳細については、[でコンピューティング環境を更新する AWS Batch](updating-compute-environments.md) および [https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) API オペレーションで設定されているインフラストラクチャ更新ポリシー ([https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdatePolicy.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdatePolicy.html)) を参照してください。
# AWS Batch マネージドノードDaemonSetで を実行する
AWS Batch AWS Batch はマネージドKubernetesノードにテイントを設定します。次の を使用して、 AWS Batch マネージドノードで を実行するDaemonSetように をターゲットにできます`tolerations`。
```
tolerations:
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
```
そのためのもう 1 つの方法は、次の `tolerations` のように実行することです。
```
tolerations:
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
effect: "NoSchedule"
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
effect: "NoExecute"
```
# Amazon EKS 起動テンプレートをカスタマイズする
AWS Batch Amazon EKS の では、起動テンプレートがサポートされています。起動テンプレートでできることには制約があります。
**重要**
EKS AL2 AMIs、 は AWS Batch を実行します`/etc/eks/bootstrap.sh`。`/etc/eks/bootstrap.sh` を起動テンプレートや cloud-init user-data スクリプトでは実行しないでください。[bootstrap.sh ](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) には `--kubelet-extra-args` パラメータ以外にもパラメータを追加できます。これを行うには、`AWS_BATCH_KUBELET_EXTRA_ARGS` `/etc/aws-batch/batch.config` ファイルに変数を設定します。詳細は以下の例を参照してください。
EKS AL2023 の場合、 は EKS の [NodeConfigSpec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec) AWS Batch を使用してインスタンスを EKS クラスターに参加させます。 AWS Batch は EKS クラスターの [NodeConfigSpec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec) に [ClusterDetails](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#clusterdetails) を入力するため、指定する必要はありません。
**注記**
は値を上書きするため AWS Batch 、起動テンプレートで以下の[https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec)設定は行わないことをお勧めします。詳細については、「[Kubernetes ノードの責任分担](eks-ce-shared-responsibility.md)」を参照してください。
`Taints`
`Cluster Name`
`apiServerEndpoint`
`certificatAuthority`
`CIDR`
プレフィックス `batch.amazonaws.com/` が付いたラベルを作成しないでください
**注記**
[CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html) を呼び出した後に起動テンプレートが変更された場合は、[https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) を呼び出して代替用の起動テンプレートのバージョンを評価する必要があります。
**Topics**
+ [`kubelet` 追加因数を追加する](#kubelet-extra-args)
+ [コンテナランタイムを設定する](#change-container-runtime)
+ [Amazon EFS ボリュームをマウントする](#mounting-efs-volume)
+ [IPv6 サポート](#eks-ipv6-support)
## `kubelet` 追加因数を追加する
AWS Batch は、 `kubelet` コマンドへの引数の追加をサポートしています。サポートされるパラメータのリストについては、「*Kubernetes ドキュメント*」の「[https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)」 を参照してください。EKS AL2 AMI の次の例では、`--node-labels mylabel=helloworld` が `kubelet` コマンドラインに追加されています。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
mkdir -p /etc/aws-batch
echo AWS_BATCH_KUBELET_EXTRA_ARGS=\"--node-labels mylabel=helloworld\" >> /etc/aws-batch/batch.config
--==MYBOUNDARY==--
```
EKS AL2023 AMI の場合、ファイル形式は YAML です。サポートされるパラメータのリストについては、「*Kubernetes ドキュメント*」の「[https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec)」 を参照してください。EKS AL2023 AMI の次の例では、`--node-labels mylabel=helloworld` が `kubelet` コマンドラインに追加されています。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: application/node.eks.aws
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
kubelet:
flags:
- --node-labels=mylabel=helloworld
--==MYBOUNDARY==--
```
## コンテナランタイムを設定する
環境変数を使用して AWS Batch `CONTAINER_RUNTIME`、マネージドノードでコンテナランタイムを設定できます。次の例では、`bootstrap.sh` コンテナランタイムを実行時に `containerd` を設定しています。詳細については、「*Kubernetes ドキュメント*」の「 [https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd)」を参照してください。
最適化された `EKS_AL2023` または `EKS_AL2023_NVIDIA` AMI を使用している場合は、**containerd** のみがサポートされているため、コンテナランタイムを指定する必要はありません。
**注記**
`CONTAINER_RUNTIME` 環境変数は `bootstrap.sh` の `--container-runtime` オプションと同等です。詳細については、「*Kubernetes ドキュメント*」の「 [https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#options](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#options)」を参照してください。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
mkdir -p /etc/aws-batch
echo CONTAINER_RUNTIME=containerd >> /etc/aws-batch/batch.config
--==MYBOUNDARY==--
```
## Amazon EFS ボリュームをマウントする
起動テンプレートを使用してボリュームをノードにマウントできます。次の例では、`cloud-config`、`packages` および `runcmd` の設定が使用されています。詳細については、「*cloud-init ドキュメント*」の「[クラウド設定例](https://cloudinit.readthedocs.io/en/latest/topics/examples.html)」を参照してください。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"
packages:
- amazon-efs-utils
runcmd:
- file_system_id_01=fs-abcdef123
- efs_directory=/mnt/efs
- mkdir -p ${efs_directory}
- echo "${file_system_id_01}:/ ${efs_directory} efs _netdev,noresvport,tls,iam 0 0" >> /etc/fstab
- mount -t efs -o tls ${file_system_id_01}:/ ${efs_directory}
--==MYBOUNDARY==--
```
このボリュームをジョブで使用するには、[RegisterJobDefinition](https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html) の [EKSProperties](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) パラメーターにボリュームを追加する必要があります。次の例は、仕事定義の大部分です。
```
{
"jobDefinitionName": "MyJobOnEks_EFS",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["ls", "-la", "/efs"],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi"
}
},
"volumeMounts": [
{
"name": "efs-volume",
"mountPath": "/efs"
}
]
}
],
"volumes": [
{
"name": "efs-volume",
"hostPath": {
"path": "/mnt/efs"
}
}
]
}
}
}
```
ノードでは、Amazon EFS ボリュームが `/mnt/efs` ディレクトリにマウントされます。Amazon EKS ジョブのコンテナでは、ボリュームは `/efs` ディレクトリにマウントされます。
## IPv6 サポート
AWS Batch は、IPv6 アドレスを持つ Amazon EKS クラスターをサポートします。 AWS Batch サポートにカスタマイズは必要ありません。ただし、始める前に、「*Amazon EKS ユーザーガイド*」の「[ポッドとサービスへの IPv6 アドレスの割り当て](https://docs.aws.amazon.com/eks/latest/userguide/cni-ipv6.html)」で説明されている考慮事項と条件を確認することをお勧めします。
# EKS AL2 から EKS AL2023 へアップグレードする方法
Amazon EKS 最適化 AMI は、Amazon Linux 2 (AL2) および Amazon Linux 2023 (AL2023) をベースとする 2 つのファミリーで使用できます。AL2023 は、クラウドアプリケーションに安全かつ安定した高パフォーマンス環境を提供するように設計された、Linux ベースのオペレーティングシステムです。AL2 および AL2023 間の相違点の詳細については、「*Amazon EKS ユーザーガイド*」の「[Amazon Linux 2 から Amazon Linux 2023 にアップグレードする](https://docs.aws.amazon.com/eks/latest/userguide/al2023.html)」を参照してください。
**重要**
AWS は、 から Amazon EKS AL2-optimizedおよび AL2-accelerated AMIs のサポートを終了します11/26/25。最適なパフォーマンスとセキュリティを維持するために、11/26/25 より前に AWS Batch Amazon EKS コンピューティング環境を Amazon Linux 2023 に移行することをお勧めします。11/26/25 end-of-supportを過ぎても、Amazon EKS コンピューティング環境で AWS Batchが提供する Amazon EKS 最適化 Amazon Linux 2 AMIs を引き続き使用できますが、これらのコンピューティング環境は から新しいソフトウェア更新、セキュリティパッチ、またはバグ修正を受け取りません AWS。サポート終了後に Amazon EKS 最適化 Amazon Linux 2 AMI 上のこうしたコンピューティング環境を[維持することはお客様の責任](eks-ce-shared-responsibility.md#eks-ce-shared-responsibility.title)となります。
コンピューティング環境の設定方法に応じて、AL2 から AL2023 への以下のアップグレードパスのいずれかを使用できます。
**Ec2Configuration.ImageType を使用したアップグレード**
+ 起動テンプレートまたは起動テンプレートの上書きを使用していない場合は、[Ec2Configuration.ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType) を `EKS_AL2023`または に変更し`EKS_AL2023_NVIDIA`、[UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) を実行します。
+ [Ec2Configuration.ImageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride) を指定する場合、[Ec2Configuration.ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType) は [Ec2Configuration.ImageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride) で指定された AMI タイプと一致する必要があります。
`ImageIdOverride` と `ImageType` が一致しない場合、ノードはクラスターに参加しません。
**起動テンプレートを使用したアップグレード**
+ 起動テンプレートまたは起動テンプレートの上書きで`kubelet`追加の引数が定義されている場合は、新しい[`kubelet`追加の引数形式](eks-launch-templates.md#kubelet-extra-args.title)に更新する必要があります。
`kubelet` の追加の引数の形式が一致しない場合、追加の引数は適用されません。
+ AL2023 AMI の場合、サポートされているコンテナランタイムは **containerd** のみです。起動テンプレートの `EKS_AL2023` のコンテナランタイムを指定する必要はありません。
でカスタマイズされたコンテナランタイムを指定することはできません`EKS_AL2023`。
+ `EKS_AL2023` に基づいて AMI を指定する起動テンプレートまたは起動テンプレートオーバーライドを使用する場合は、[userdataType](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html) を `EKS_NODEADM` に設定する必要があります。
`userdataType` と AMI が一致しない場合、ノードはクラスターに参加しません。