翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 「Auto Scaling グループ」
**注記**
Auto Scaling グループを初めて使用する場合は、チュートリアル「[最初の Auto Scaling グループを作成する](create-your-first-auto-scaling-group.md)」の手順を実行して使用を開始し、グループ内のインスタンスが終了したときに Auto Scaling グループがどのように応答するかを確認します。
Auto Scaling グループには、自動スケーリングと管理の目的で論理グループとして扱われる EC2 インスタンスの集合が含まれます。また、Auto Scaling グループによって、ヘルスチェックの置き換えやスケーリングポリシーなど、Amazon EC2 Auto Scaling の機能も使用できます。Auto Scaling グループでのインスタンス数の維持と自動スケーリングの両方が Amazon EC2 Auto Scaling サービスの主な機能です。
Auto Scaling グループのサイズは、希望するキャパシティーとして設定したインスタンスの数によって異なります。手動でまたは自動スケーリングを使用して、需要に合わせてサイズを調整できます。
Auto Scaling グループは起動時に、希望するキャパシティーに対応するために十分な数のインスタンスを起動します。また、グループのインスタンスに対して定期的にヘルスチェックを実行することで、このインスタンス数を維持します。Auto Scaling グループは、インスタンスに異常が発生した場合でも、一定数のインスタンスを維持し続けます。インスタンスに異常が生じた場合、グループは異常のあるインスタンスを終了し、そのインスタンスを置き換える別のインスタンスを起動します。詳細については、「[Auto Scaling グループでのインスタンスのヘルスチェック](ec2-auto-scaling-health-checks.md)」を参照してください。
スケーリングポリシーを使用して、状況の変化に合わせてグループのインスタンスの数を動的に増減することができます。スケーリングポリシーが有効になっている場合、Auto Scaling グループは、指定された最小キャパシティ値と最大キャパシティ値の間で、グループの希望するキャパシティを調整し、必要に応じてインスタンスを起動または終了します。スケーリングはスケジュールに従って行うこともできます。詳細については、「[スケーリング方法を選択する](scaling-overview.md)」を参照してください。
Auto Scaling グループを作成する際に、オンデマンドインスタンス、スポットインスタンス、またはその両方を起動するかどうかを選択できます。launch template を使用する場合にのみ、Auto Scaling グループに複数の購入オプションを指定できます。詳細については、「[複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ](ec2-auto-scaling-mixed-instances-groups.md)」を参照してください。
スポットインスタンスでは、オンデマンド料金と比べて大幅な割引料金で、未使用の EC2 キャパシティを購入できます。詳細については[Amazon EC2スポットインスタンス](https://aws.amazon.com/ec2/spot/pricing/)を参照してください。スポットインスタンスとオンデマンドインスタンスの主な違いは次のとおりです。
+ スポットインスタンスの料金は需要に応じて変化する
+ スポットインスタンスの可用性や料金が変化したときに、Amazon EC2 が個々のスポットインスタンスを終了できる
スポットインスタンスが削除されると、Auto Scaling グループはグループの希望するキャパシティを維持するために、代わりのインスタンスを起動しようとします。
インスタンスの起動時に複数のアベイラビリティーゾーンを指定した場合は、希望するキャパシティがこれらのアベイラビリティーゾーンに分散されます。スケーリングアクションが発生した場合、Amazon EC2 Auto Scaling は指定したすべてのアベイラビリティーゾーン間でキャパシティーのバランスを自動的に維持します。
**Topics**
+ [起動テンプレートを使用して Auto Scaling グループを作成する](create-auto-scaling-groups-launch-template.md)
+ [起動設定を使用して Auto Scaling グループを作成する](create-auto-scaling-groups-launch-configuration.md)
+ [インスタンスを同期的に起動する](launch-instances-synchronously.md)
+ [Auto Scaling グループを更新する](update-auto-scaling-group.md)
+ [Auto Scaling グループとインスタンスにタグを付ける](ec2-auto-scaling-tagging.md)
+ [インスタンスメンテナンスポリシー](ec2-auto-scaling-instance-maintenance-policy.md)
+ [Amazon EC2 Auto Scaling のライフサイクルフック](lifecycle-hooks.md)
+ [ウォームプールを使用してブート時間が長いアプリケーションのレイテンシーを低減する](ec2-auto-scaling-warm-pools.md)
+ [Auto Scaling グループのゾーンシフト](ec2-auto-scaling-zonal-shift.md)
+ [Auto Scaling グループのアベイラビリティーゾーンの分散](ec2-auto-scaling-availability-zone-balanced.md)
+ [Auto Scaling グループからインスタンスをデタッチまたはアタッチする](ec2-auto-scaling-detach-attach-instances.md)
+ [Auto Scaling グループからインスタンスを一時的に削除する](as-enter-exit-standby.md)
+ [Auto Scaling インフラストラクチャを削除する](as-process-shutdown.md)
# 起動テンプレートを使用して Auto Scaling グループを作成する
起動テンプレートを作成した場合は、起動テンプレートを EC2 インスタンスの設定テンプレートとして使用する Auto Scaling グループを作成できます。起動テンプレートは、インスタンスの AMI ID、インスタンスタイプ、キーペア、セキュリティグループ、ブロックデバイスマッピングなどの情報を指定します。起動テンプレートの作成の詳細については、「[Auto Scaling グループの起動テンプレートを作成する](create-launch-template.md)」を参照してください。
Auto Scaling グループを作成するための十分な許可が必要です。また、サービスにリンクされたロールが存在しない場合は、Amazon EC2 Auto Scaling がユーザーに代わってアクションを実行するために使用する、サービスにリンクされたロールを作成するための十分な許可も必要です。管理者がアクセス許可を付与するための参照として使用できる IAM ポリシーの例については、[アイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md) および [Auto Scaling グループで Amazon EC2 起動テンプレートの使用を制御する](ec2-auto-scaling-launch-template-permissions.md) を参照してください。
**Topics**
+ [起動テンプレートを使用して Auto Scaling グループを作成する](create-asg-launch-template.md)
+ [Amazon EC2 起動ウィザードを使用して Auto Scaling グループを作成する](create-asg-ec2-wizard.md)
+ [複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ](ec2-auto-scaling-mixed-instances-groups.md)
# 起動テンプレートを使用して Auto Scaling グループを作成する
Auto Scaling グループを作成する際、Amazon EC2 インスタンスを設定するために必要な情報、そのインスタンスのアベイラビリティーゾーンと VPC サブネット、希望するキャパシティー、キャパシティー制限の最小値と最大値を指定する必要があります。
Auto Scaling グループによって起動される Amazon EC2 インスタンスを設定するには、起動テンプレートまたは起動設定を指定します。次の手順では、起動テンプレートを使用して Auto Scaling グループを作成する方法を説明します。
**前提条件**
+ 起動テンプレートを作成しておく必要があります。詳細については、「[Auto Scaling グループの起動テンプレートを作成する](create-launch-template.md)」を参照してください。
**起動テンプレートを使用して Auto Scaling グループを作成するには (コンソール)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。
1. 画面上部のナビゲーションバーで、起動テンプレートの作成時に使用した AWS リージョン ものと同じ を選択します。
1. [**Auto Scaling グループの作成**] を選択します。
1. **Choose launch template or configuration** のページで、以下を実行します。
1. **Auto Scaling グループ名**に Auto Scaling グループの名前を入力します。
1. [**起動テンプレート**] で、既存の起動テンプレートを選択します。
1. [**起動テンプレートのバージョン**] で、スケールアウト時に Auto Scaling グループで使用する起動テンプレートのバージョン (デフォルト、最新、または特定のバージョン) を選択します。
1. 起動テンプレートが、使用する予定のすべてのオプションをサポートしていることを確認し、[**次へ**] を選択します。
1. **[インスタンス起動オプションを選択]** ページで、複数のインスタンスタイプを使用していない場合は **[インスタンスタイプの要件]** セクションをスキップして、起動テンプレートで指定されている EC2 インスタンスタイプを使用できます。
複数のインスタンスタイプを使用する場合は、「[複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ](ec2-auto-scaling-mixed-instances-groups.md)」を参照してください。
1. **[Network]** (ネットワーク) の下にある **[VPC]** で、VPC を選択します。Auto Scaling グループは、起動テンプレートで指定したセキュリティグループと、同じ VPC 内に作成する必要があります。
1. **[アベイラビリティーゾーンとサブネット]** で、指定した VPC 内のサブネットを 1 つ以上選択します。複数のアベイラビリティーゾーンのサブネットを使用することで、高可用性を得られます。詳細については、「[VPC サブネットを選択する場合の考慮事項](asg-in-vpc.md#as-vpc-considerations)」を参照してください。
1. **[アベイラビリティーゾーンのディストリビューション]** で、分散戦略を選択します。詳細については、「[Auto Scaling グループのアベイラビリティーゾーンの分散](ec2-auto-scaling-availability-zone-balanced.md)」を参照してください。
1. 指定したインスタンスタイプを使用して起動テンプレートを作成した場合は、次の手順に進み、起動テンプレートのインスタンスタイプを使用する Auto Scaling グループを作成できます。
または、起動テンプレートでインスタンスタイプが指定されていない場合や、Auto Scaling に複数のインスタンスタイプを使用する場合は、**[Override launch template]** (起動テンプレートを上書きする) オプションを選択できます。詳細については、「[複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ](ec2-auto-scaling-mixed-instances-groups.md)」を参照してください。
1. **[Next]** (次へ) を選択して、次のステップに進みます。
または、残りはデフォルトのままにして、[**Skip to Review (確認をスキップ)**] を選択できます。
1. (オプション) **[他のサービスと統合する]** ページで、次のオプションを設定し、**[次へ]** を選択します。
1. **[ロードバランシング]** で、Auto Scaling グループをロードバランサーにアタッチするかどうかを選択します。詳細については、「[Elastic Load Balancing](autoscaling-load-balancer.md)」を参照してください。
1. **[VPC Lattice 統合オプション]** で、VPC Lattice を使用するかどうかを選択します。詳細については、「[VPC Lattice ターゲットグループを使用してトラフィックフローを管理する](ec2-auto-scaling-vpc-lattice.md)」を参照してください。
1. **[Amazon Application Recovery Controller (ARC) ゾーンシフト]** で、チェックボックスを選択してゾーンシフトを有効にします。詳細については、「[Auto Scaling グループのゾーンシフト](ec2-auto-scaling-zonal-shift.md)」を参照してください。
1. ゾーンシフトを有効にする場合は、**[ヘルスチェックの動作]** で、[異常を無視] または [異常なものとの置換を実行] を選択します。詳細については、「[Auto Scaling グループのゾーンシフトの仕組み](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works)」を参照してください。
1. **[ヘルスチェック]** の **[追加のヘルスチェックタイプ]** で、**[Amazon EBS ヘルスチェックをオンにする]** を選択します。詳細については、「[ヘルスチェックを使用して、Amazon EBS ボリュームに障害がある Auto Scaling インスタンスをモニタリングする](monitor-and-replace-instances-with-impaired-ebs-volumes.md)」を参照してください。
1. **[ヘルスチェックの猶予期間]** に、秒単位で時間を入力します。これは、インスタンスが `InService` 状態になった後で、Amazon EC2 Auto Scaling がインスタンスのヘルスステータスのチェックを待つ必要がある時間です。詳細については、「[Auto Scaling グループにヘルスチェックの猶予期間を設定する](health-check-grace-period.md)」を参照してください。
1. (オプション) **[グループサイズとスケーリングを設定する]** ページで、次のオプションを設定し、**[次へ]** を選択します。
1. **[グループサイズ]** の **[希望する容量]** に、起動するインスタンスの初期数を入力します。
1. **[スケーリング]** の **[スケーリング制限]** で、**[希望する容量]** の新しい値が **[最小の希望する容量]** と **[最大の希望する容量]** より大きい場合、**[最大の希望する容量]** は自動的に希望する新しい容量の値に引き上げられます。これらの制限は、必要に応じて変更できます。詳細については、「[Auto Scaling グループのスケーリング制限を設定する](asg-capacity-limits.md)」を参照してください。
1. **[自動スケーリング]** で、ターゲット追跡スケーリングポリシーを作成するかどうかを選択します。このポリシーは、Auto Scaling グループの作成後に作成することもできます。
**[ターゲット追跡スケーリングポリシー]** を選択した場合は、「[ターゲット追跡スケーリングポリシーを作成する](policy_creating.md)」の指示に従ってポリシーを作成してください。
1. **[インスタンスメンテナンスポリシー]** で、インスタンスメンテナンスポリシーを作成するかどうかを選択します。このポリシーは、Auto Scaling グループの作成後に作成することもできます。ポリシーを作成するには、「[インスタンスメンテナンスポリシーを設定する](set-instance-maintenance-policy.md)」の手順を実行してください。
1. **[その他のキャパシティ設定]** の **[キャパシティ予約の詳細設定]** で、キャパシティ予約の詳細設定を使用するかどうかを選択します。詳細については、「[キャパシティ予約を使用して特定のアベイラビリティーゾーンでキャパシティを予約する](use-ec2-capacity-reservations.md)」を参照してください。
1. **[追加設定]** の **[インスタンスのスケールイン保護]** で、インスタンスのスケールイン保護を有効にするかどうかを選択します。詳細については、「[インスタンスのスケールイン保護を使用してインスタンスの終了を制御する](ec2-auto-scaling-instance-protection.md)」を参照してください。
1. **[追加設定]** で、CloudWatch グループメトリクスの収集を有効にするかどうかを選択します。これらのメトリクスは、終了インスタンス数や保留中のインスタンスの数など、潜在的な問題の指標となる測定値を提供します。詳細については、「[Auto Scaling グループとインスタンスの CloudWatch メトリクスを監視する](ec2-auto-scaling-cloudwatch-monitoring.md)」を参照してください。
1. **[デフォルトのインスタンスのウォームアップ]** で、このオプションを選択し、アプリケーションのウォームアップ時間を選択します。スケーリングポリシーを持つ Auto Scaling グループを作成している場合は、インスタンスのデフォルトウォームアップ機能によって、動的スケーリングに使用される Amazon CloudWatch メトリクスが改善されます。詳細については、「[Auto Scaling グループに対するインスタンスのデフォルトウォームアップを設定する](ec2-auto-scaling-default-instance-warmup.md)」を参照してください。
1. (オプション) **[通知の追加]** ページで、通知を設定してから **[次へ]** を選択します。詳細については、「[Amazon EC2 Auto Scaling の Amazon SNS 通知オプション](ec2-auto-scaling-sns-notifications.md)」を参照してください。
1. (オプション) **[タグの追加]** ページで、**[タグの追加]** を選択し、各タグのタグキーと値を指定してから、**[次へ]** を選択します。詳細については、「[Auto Scaling グループとインスタンスにタグを付ける](ec2-auto-scaling-tagging.md)」を参照してください。
1. [**Review (レビュー)**]ページで、[**Create Auto Scaling group (Auto Scaling グループを作成)**] を選択します。
**コマンドラインを使用して Auto Scaling グループを作成するには**
以下のコマンドのいずれかを使用できます。
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) (AWS CLI)
+ [New-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
# Amazon EC2 起動ウィザードを使用して Auto Scaling グループを作成する
次の手順では、Amazon EC2 コンソールで **[Launch instance]** (インスタンスの作成) ウィザードを使用して Auto Scaling グループを作成する方法を示します。このオプションでは、特定の設定が詳細に入力されている起動テンプレートが、**[Launch instance]** (インスタンスの作成) ウィザードに自動的に入力されます。
**注記**
ウィザードは、指定したインスタンス数を Auto Scaling グループに設定しません。起動テンプレートには、Amazon マシンイメージ (AMI) の ID と、インスタンスタイプのみが設定されます。**[Create Auto Scaling group]** (Auto Scaling グループの作成) ウィザードで、起動するインスタンスの数を指定します。
AMI には、インスタンスの設定に必要な情報が含まれています。同じ設定で複数のインスタンスが必要な場合は、1 つの AMI から複数のインスタンスを起動できます。Auto Scaling グループに属するインスタンスを再起動した場合に、インスタンスが終了しないように、既にアプリケーションがインストールされているカスタム AMI を使用することをお勧めします。Amazon EC2 Auto Scaling でカスタム AMI を使用するには、まずカスタマイズされたインスタンスから AMI を作成し、次に AMI を使用して、Auto Scaling グループの起動テンプレートを作成する必要があります。
**前提条件**
+ Auto Scaling グループを作成する AWS リージョン のと同じ にカスタム AMI を作成しておく必要があります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[AMI を作成する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html)」を参照してください。
## カスタム AMI をテンプレートとして使用する
このセクションでは、Amazon EC2 起動ウィザードを使用して、起動テンプレートにカスタム AMI を自動的に入力します。また、起動テンプレートを最初から設定する場合や、起動テンプレートに設定できるパラメータの詳細については、[起動テンプレートを作成する (コンソール)](create-launch-template.md#create-launch-template-for-auto-scaling) を参照してください。
**カスタム AMI をテンプレートとして使用するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. 画面上部のナビゲーションバーに、現在の AWS リージョン が表示されます。Auto Scaling グループを起動するリージョンを選択します。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. **[Launch instance]** (インスタンスを起動) を選択してから、以下を実行します。
1. **[Name and tags]** (名前とタグ) では、**[Name]** (名前) を空のままにしておきます。名前は、起動テンプレートの作成に使用されるデータの 1 部ではありません。
1. **[Application and OS Images (Amazon Machine Image)]** (アプリケーションおよび OS イメージ (Amazon マシンイメージ)) で、**[Browse more AMIs]** (その他の AMI を閲覧する) を選択して完全な AMI カタログを参照します。
1. **[My AMIs]** (自分の AMI) を選択して、作成した AMI を見つけてから、**[Select]** (選択) を選択します。
1. **[Instance type]** (インスタンスタイプ) でインスタンスタイプを選択します。
**注記**
AMI の作成時に使用したものと同じインスタンスタイプを選択するか、より強力なインスタンスタイプを選択します。
1. 画面の右側にある **[Summary]** (概要) で、**[Number of instances]** (インスタンス数) に任意の数を入力します。ここに入力する数値は重要ではありません。起動するインスタンスの数は、Auto Scaling グループの作成時に指定します。
**[Number of instances]** (インスタンス数) フィールドの下に、**[When launching more than 1 instance, consider EC2 Auto Scaling]** (複数のインスタンスを起動する場合は、EC2 Auto Scaling を検討してください) というメッセージが表示されます。
1. ハイパーリンクテキストの **[consider EC2 Auto Scaling]** (EC2 Auto Scaling を検討してください) を選択します。
1. **[Launch into Auto Scaling Group]** (Auto Scaling グループに作成する) 確認ダイアログで **[Continue]** (次へ) を選択して、インスタンス起動ウィザードで選択した AMI とインスタンスタイプが既に入力されている **[Create launch template]** (起動テンプレートを作成) ページに移動します。
**[Continue]** (続行) を選択すると、**[Create launch template]** (起動テンプレートの作成) ページが開きます。この手順に従って、起動テンプレートの作成を完了します。
**起動テンプレートを作成するには**
1. **[Launch template name and description]** (起動テンプレート名と説明) で、新しい起動テンプレートの名前と説明を入力します。
1. (オプション) **[Key pair (login)]** (キーペア (ログイン)) と **[Key pair name]** (キーペア名) では、SSH などを使用したインスタンスへの接続時での使用のために以前作成したキーペアの名前を選択します。
1. (オプション) **[Network settings]** (セットワーク設定) の **[Security groups]** (セキュリティグループ) では、以前作成した[セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)を 1 つ、または複数選択します。
1. (オプション) **[Configure storage]** (ストレージを設定) で、ストレージ設定を更新します。デフォルトのストレージ設定は AMI およびインスタンスタイプによって決まります。
1. 起動テンプレートの設定が終わったら、**[Create launch template]** (起動テンプレートの作成) を選択します。
1. 確認ページで、[**Auto Scaling グループの作成**] を選択します。
## Auto Scaling グループを作成する
**注記**
このトピックの残りの部分では、Auto Scaling グループ作成の基本的な手順について説明します。Auto Scaling グループに設定できるパラメータの詳細については、「[起動テンプレートを使用して Auto Scaling グループを作成する](create-asg-launch-template.md)」を参照してください。
**[Create Auto Scaling group]** (Auto Scaling グループの作成) を選択すると、**[Create Auto Scaling group]** (Auto Scaling グループの作成) ウィザードが開きます。Auto Scaling グループを作成するには、次の手順を実行します。
**Auto Scaling グループを作成する**
1. [**Choose launch template or configuration (起動テンプレートまたは設定の選択)**] ページで、Auto Scaling グループの名前を入力します。
1. 作成した起動テンプレートは、既に選択されています。
[**起動テンプレートのバージョン**] で、スケールアウト時に Auto Scaling グループで使用する起動テンプレートのバージョン (デフォルト、最新、または特定のバージョン) を選択します。
1. **[Next]** (次へ) を選択して、次のステップに進みます。
1. **[インスタンス起動オプションを選択]** ページで、複数のインスタンスタイプを使用していない場合は **[インスタンスタイプの要件]** セクションをスキップして、起動テンプレートで指定されている EC2 インスタンスタイプを使用できます。
複数のインスタンスタイプを使用する場合は、「[複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ](ec2-auto-scaling-mixed-instances-groups.md)」を参照してください。
1. **[Network]** (ネットワーク) の下にある **[VPC]** で、VPC を選択します。Auto Scaling グループは、起動テンプレートで指定したセキュリティグループと、同じ VPC 内に作成する必要があります。
**ヒント**
起動テンプレートでセキュリティグループを指定しなかった場合、指定した VPC のデフォルトのセキュリティグループを使用して、インスタンスが起動されます。デフォルトでは、このセキュリティグループは外部ネットワークからのインバウンドトラフィックを許可しません。
1. **[アベイラビリティーゾーンとサブネット]** で、指定した VPC 内のサブネットを 1 つ以上選択します。
1. **[アベイラビリティーゾーンのディストリビューション]** で、分散戦略を選択します。詳細については、「[Auto Scaling グループのアベイラビリティーゾーンの分散](ec2-auto-scaling-availability-zone-balanced.md)」を参照してください。
1. **[Next]** (次へ) を2 回選択すると、**[Configure group size and scaling policies]** (グループサイズとスケーリングポリシーの設定) ページへ移動します。
1. **[グループサイズ]** で、**[希望する容量]** (Auto Scaling グループの作成直後に起動するインスタンスの初期数) を定義します。
1. **[スケーリング]** セクションの **[スケーリング制限]** で、**[希望する容量]** の新しい値が **[最小の希望する容量]** と **[最大の希望する容量]** より大きい場合、**[最大の希望する容量]** は自動的に希望する新しい容量の値に引き上げられます。これらの制限は、必要に応じて変更できます。詳細については、「[Auto Scaling グループのスケーリング制限を設定する](asg-capacity-limits.md)」を参照してください。
1. [**Skip to review**] を選択します。
1. [**Review (レビュー)**]ページで、[**Create Auto Scaling group (Auto Scaling グループを作成)**] を選択します。
## 次の手順
アクティビティ履歴を表示することによって、Auto Scaling グループが正しく作成されたことを確認できます。**[Activity]** (アクティビティ) タブの **[Activity history]** (アクティビティ履歴) では、**[Status]** (ステータス) 列に、Auto Scaling グループがインスタンスを正常に起動したかどうかが表示されます。インスタンスの起動に失敗したり、起動してもすぐに終了したりする場合は、次のトピックで、考えられる原因と解決方法を参照してください。
+ [Amazon EC2 Auto Scaling をトラブルシューティングする: EC2 インスタンス起動の失敗](ts-as-instancelaunchfailure.md)
+ [Amazon EC2 Auto Scaling をトラブルシューティングする: AMI 問題](ts-as-ami.md)
+ [Amazon EC2 Auto Scaling の異常なインスタンスをトラブルシューティングする](ts-as-healthchecks.md)
必要に応じて、Auto Scaling グループと同じリージョンに、ロードバランサーをアタッチできるようになりました。詳細については、「[Elastic Load Balancing を使用して Auto Scaling グループ内で受信アプリケーショントラフィックを分散する](autoscaling-load-balancer.md)」を参照してください。
# 複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ
1 つの Auto Scaling グループ内で、オンデマンドインスタンスとスポットインスタンスのフリートを起動してオートスケールできます。スポットインスタンスの使用で割引を受けるだけでなく、リザーブドインスタンスまたは Savings Plans を使用して、通常のオンデマンドインスタンスの料金に対する割引の適用を受けることができます。これらの要素は、EC2 インスタンスのコスト削減を最適化し、アプリケーションに必要なスケールとパフォーマンスを得るのに役立ちます。
スポットインスタンスは、EC2 オンデマンドの料金と比較して、大幅割引で提供される予備の容量です。スポットインスタンス はアプリケーションを実行する時間に柔軟性がある場合や、アプリケーションを中断できる場合に、費用効率の高い選択肢です。これらは、フォールトトレラントで柔軟性があるさまざまなアプリケーションに使用できます。これには、ステートレスウェブサーバー、API エンドポイント、ビッグデータアプリケーションおよび分析アプリケーション、コンテナ化されたワークロード、CI/CD パイプライン、高パフォーマンスおよび高スループットコンピューティング (HPC/HTC)、レンダリングワークロード、その他柔軟性の高いワークロードなどがあります。
詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンス購入オプション](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)」を参照してください。
**Topics**
+ [混合インスタンスグループを作成するための設定の概要](mixed-instances-groups-set-up-overview.md)
+ [複数のインスタンスタイプの配分戦略](allocation-strategies.md)
+ [属性ベースのインスタンスタイプの選択を使用して混合インスタンスグループを作成する](create-mixed-instances-group-attribute-based-instance-type-selection.md)
+ [インスタンスタイプを手動で選択して混合インスタンスグループを作成する](create-mixed-instances-group-manual-instance-type-selection.md)
+ [インスタンスの重みを使用するように Auto Scaling グループを設定する](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)
+ [複数の起動テンプレートを使用する](ec2-auto-scaling-mixed-instances-groups-launch-template-overrides.md)
# 混合インスタンスグループを作成するための設定の概要
このトピックでは、Auto Scaling の混合インスタンスグループを作成するための概要とベストプラクティスについて説明します。
**Topics**
+ [概要:](#mixed-instances-groups-overview)
+ [インスタンスタイプの柔軟性](#mixed-instances-group-instance-flexibility)
+ [アベイラビリティーゾーンの柔軟性](#mixed-instances-group-az-flexibility)
+ [最大スポット料金](#mixed-instances-group-spot-max-price)
+ [プロアクティブなキャパシティの再調整](#use-capacity-rebalancing)
+ [スケーリングの動作](#mixed-instances-group-scaling-behavior)
+ [リージョン別のインスタンスタイプの可用性](#setup-overview-regional-availability-of-instance-types)
+ [関連リソース](#setup-overview-related-resources)
+ [制限事項](#setup-overview-limitations)
## 概要:
混合インスタンスグループを作成するには、次の 2 つのオプションがあります。
+ [属性ベースのインスタンスタイプの選択](create-mixed-instances-group-attribute-based-instance-type-selection.md) — コンピューティング要件を定義して、特定のインスタンス属性に基づいてインスタンスタイプを自動的に選択します。
+ [インスタンスタイプの手動選択](create-mixed-instances-group-manual-instance-type-selection.md) — ワークロードに適したインスタンスタイプを手動で選択します。
------
#### [ Manual selection ]
次のステップでは、インスタンスタイプを手動で選択して混合インスタンスグループを作成する方法を説明します。
1. EC2 インスタンスを起動するためのパラメータを含む起動テンプレートを選択します。起動テンプレートのパラメータはオプションですが、amilong; (AMI) ID が起動テンプレートにない場合、Amazon EC2 Auto Scaling はインスタンスを起動できません。
1. 起動テンプレートをオーバーライドするオプションを選択します。
1. ワークロードに合ったインスタンスタイプを手動で選択します。
1. 起動するオンデマンドインスタンスとスポットインスタンスの割合を指定します。
1. Amazon EC2 Auto Scaling が可能なインスタンスタイプからオンデマンドとスポットのキャパシティーを満たす方法を決定する割り当て戦略を選択します。
1. インスタンスを起動するアベイラビリティーゾーンと VPC サブネットを選択します。
1. グループの初期サイズ (希望するキャパシティ) と、グループの最小サイズおよび最大サイズを指定します。
オーバーライドは、起動テンプレートで宣言されたインスタンスタイプをオーバーライドし、Auto Scaling グループ独自のリソース定義に埋め込まれている複数のインスタンスタイプを使用するために必要です。利用可能なインスタンスタイプの詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。
インスタンスタイプごとに次のオプションパラメータを設定することもできます。
+ `LaunchTemplateSpecification` — 必要に応じて、別の起動テンプレートをインスタンスタイプに割り当てることができます。このオプションは現在、コンソールからは利用できません。詳細については、「[複数の起動テンプレートを使用する](ec2-auto-scaling-mixed-instances-groups-launch-template-overrides.md)」を参照してください。
+ `WeightedCapacity` — グループ内の残りのインスタンスとの関係で、どのくらいのインスタンスが希望する容量にカウントされるかを決定します。1 つのインスタンスタイプに `WeightedCapacity` の値を指定する場合は、すべてのインスタンスタイプに `WeightedCapacity` の値を指定する必要があります。デフォルトでは、各インスタンスは希望するキャパシティに対して 1 個としてカウントされます。詳細については、「[インスタンスの重みを使用するように Auto Scaling グループを設定する](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)」を参照してください。
------
#### [ Attribute-based selection ]
Amazon EC2 Auto Scaling が特定のインスタンス属性に基づいてインスタンスタイプを自動的に選択できるようにするには、次のステップに従って、コンピューティング要件を指定することによって混合インスタンスグループを作成します。
1. EC2 インスタンスを起動するためのパラメータを含む起動テンプレートを選択します。起動テンプレートのパラメータはオプションですが、amilong; (AMI) ID が起動テンプレートにない場合、Amazon EC2 Auto Scaling はインスタンスを起動できません。
1. 起動テンプレートをオーバーライドするオプションを選択します。
1. vCPU およびメモリ要件などのコンピューティング要件に一致するインスタンス属性を指定します。
1. 起動するオンデマンドインスタンスとスポットインスタンスの割合を指定します。
1. Amazon EC2 Auto Scaling が可能なインスタンスタイプからオンデマンドとスポットのキャパシティーを満たす方法を決定する割り当て戦略を選択します。
1. インスタンスを起動するアベイラビリティーゾーンと VPC サブネットを選択します。
1. グループの初期サイズ (希望するキャパシティ) と、グループの最小サイズおよび最大サイズを指定します。
オーバーライドは、起動テンプレートで宣言されたインスタンスタイプをオーバーライドし、コンピューティング要件を記述するインスタンス属性のセットを使用するために必要です。サポートされる属性の詳細については、「*Amazon EC2 Auto Scaling API リファレンス*」の「[InstanceRequirements](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstanceRequirements.html)」を参照してください。あるいは、既にインスタンス属性が定義されている起動テンプレートを使用することもできます。
必要に応じて、オーバーライド構造内で `LaunchTemplateSpecification` パラメータを設定して、一連のインスタンス要件に別の起動テンプレートを割り当てることもできます。このオプションは現在、コンソールからは利用できません。詳細については、「*Amazon EC2 Auto Scaling API リファレンス*」の「[LaunchTemplateOverrides](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_LaunchTemplateOverrides.html)」を参照してください。
デフォルトでは、Auto Scaling グループの希望するキャパシティとしてインスタンスの数を設定します。
あるいは、希望するキャパシティの値を vCPU の数またはメモリ量に設定することもできます。これを実行するには、`CreateAutoScalingGroup` API オペレーションの `DesiredCapacityType` プロパティを使用するか、または AWS マネジメントコンソールの **[希望する容量タイプ]** ドロップダウンフィールドを使用します。これは、[インスタンスの重み](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)に代わる便利な方法です。
------
## インスタンスタイプの柔軟性
可用性を高めるには、複数のインスタンスタイプにアプリケーションをデプロイします。キャパシティ要件を満たすために複数のインスタンスタイプを使用するのがベストプラクティスです。そうすることで、選択したアベイラビリティーゾーンに十分なインスタンスのキャパシティがない場合、Amazon EC2 Auto Scaling は別のインスタンスタイプを起動できます。
スポットインスタンスで十分なインスタンスのキャパシティがない場合、Amazon EC2 Auto Scaling は他のスポットインスタンスプールからの起動を試みようとし続けます。(使用するプールは、インスタンスタイプと配分戦略の選択によって決まります)。Amazon EC2 Auto Scaling では、オンデマンドインスタンスの代わりにスポットインスタンスを起動することで、スポットインスタンスのコスト削減効果を活用できます。
ワークロードごとに少なくとも 10 個のインスタンスを使用して柔軟性を持たせることをお勧めします。インスタンスタイプを選択する際には、最も人気のある新しいインスタンスタイプに限定しないでください。旧世代のインスタンスタイプを選択すると、オンデマンドの顧客からの需要が少ないため、スポット中断が少なくなる傾向があります。
## アベイラビリティーゾーンの柔軟性
Auto Scaling グループが複数のアベイラビリティーゾーンにまたがるようにすることを強くお勧めします。複数のアベイラビリティーゾーンを使用すると、ゾーン間で自動的にフェイルオーバーして回復力を高めるアプリケーションを設計できます。
追加のメリットとして、単一のアベイラビリティーゾーン内のグループと比較して、より深い Amazon EC2 キャパシティプールにアクセスできます。キャパシティは各アベイラビリティーゾーンのインスタンスタイプごとに個別に変動するため、多くの場合、より多くのコンピューティングキャパシティを得ることができ、インスタンスタイプとアベイラビリティーゾーンの両方を柔軟に選択できます。
複数のアベイラビリティーゾーンの使用の詳細については、「[例: 複数のアベイラビリティーゾーン全体にインスタンスを分散させる](auto-scaling-benefits.md#arch-AutoScalingMultiAZ)」を参照してください。
## 最大スポット料金
AWS CLI または SDK を使用して Auto Scaling グループを作成するときは、 `SpotMaxPrice`パラメータを指定できます。`SpotMaxPrice` パラメータは、お客様がスポットインスタンス時間について支払ってもよいと考える最大料金を決定します。
オーバーライド (またはグループレベルで `"DesiredCapacityType": "vcpu"` もしくは `"DesiredCapacityType": "memory-mib"`) で `WeightedCapacity` パラメータを指定すると、最大料金はインスタンス全体の最大料金ではなく、最大単価を表します。
最大料金を指定しないことを強くお勧めします。低すぎる上限価格が設定されるなどの理由で、スポットインスタンスを取得できない場合には、アプリケーションが実行されないことがあります。上限料金を指定しない場合、デフォルトの上限料金はオンデマンド価格となります｡ 起動するスポットインスタンスのスポット価格のみを支払います。スポットインスタンスによって提供される大幅な割引は、そのまま受けることができます。これらの割引を実現できるのは、[スポット料金モデル](https://aws.amazon.com/blogs/compute/new-amazon-ec2-spot-pricing/)を使用して適用されるスポット料金が安定しているためです。詳細については、「*Amazon EC2 ユーザーガイド*」の「[料金と削減額](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html#spot-pricing)」を参照してください。
## プロアクティブなキャパシティの再調整
ユースケースで可能な場合は、キャパシティの再調整をお勧めします。キャパシティの再調整は、中断のリスクがあるスポットインスタンスをプロアクティブに置き換えることで、ワークロードの可用性を維持するのに役立ちます。
キャパシティの再調整が有効になっている場合、Amazon EC2 Auto Scaling は、EC2 インスタンスの再調整に関するレコメンデーションを受け取ったスポットインスタンスをプロアクティブに置き換えようとします。これは、中断のリスクが低い新しいスポットインスタンスにワークロードを再調整する機会を提供します。
詳細については、「[リスクがあるスポットインスタンスを置き換えるための Auto Scaling でのキャパシティの再調整](ec2-auto-scaling-capacity-rebalancing.md)」を参照してください。
## スケーリングの動作
混合インスタンスグループを作成すると、デフォルトでオンデマンドインスタンスが使用されます。スポットインスタンスを使用するには、オンデマンドインスタンスとして起動されるグループの割合を変更する必要があります。オンデマンドインスタンスの割合には、0 から 100 までの任意の数を指定できます。
オプションで、開始時のオンデマンドインスタンスのベース数を指定することもできます。その場合、Amazon EC2 Auto Scaling は、グループがスケールアウトする際にオンデマンドインスタンスのベースキャパシティが起動された後までは、スポットインスタンスの起動を待機します。ベースキャパシティーを超える場合、オンデマンドインスタンスの割合を使用して、起動するオンデマンドインスタンスとスポットインスタンスの数が決まります。
Amazon EC2 Auto Scaling は、その割合を同等のインスタンス数に変換します。結果が小数になる場合、オンデマンドインスタンスを優先して次の整数に切り上げられます。
次の表は、サイズが増減した場合における Auto Scaling グループの動作について示しています。
**例: スケーリング動作**
| 購入オプション | 各購入オプションのグループのサイズと実行中のインスタンスの数 |
| --- |--- |
| | **10** | **20** | **30** | **40** |
| --- |--- |--- |--- |--- |
| **例 1**: 10 を基準、50/50% オンデマンド/スポット | | | | |
| On-Demand Instances (base amount) | 10 | 10 | 10 | 10 |
| On-Demand Instances | 0 | 5 | 10 | 15 |
| Spot Instances | 0 | 5 | 10 | 15 |
| **例 2**: 0 を基準、0/100% オンデマンド/スポット | | | | |
| On-Demand Instances (base amount) | 0 | 0 | 0 | 0 |
| On-Demand Instances | 0 | 0 | 0 | 0 |
| Spot Instances | 10 | 20 | 30 | 40 |
| **例 3**: 0 を基準、60/40% オンデマンド/スポット | | | | |
| On-Demand Instances (base amount) | 0 | 0 | 0 | 0 |
| On-Demand Instances | 6 | 12 | 18 | 24 |
| Spot Instances | 4 | 8 | 12 | 16 |
| **例 4**: 0 を基準、100/0% オンデマンド/スポット | | | | |
| On-Demand Instances (base amount) | 0 | 0 | 0 | 0 |
| On-Demand Instances | 10 | 20 | 30 | 40 |
| Spot Instances | 0 | 0 | 0 | 0 |
| **例 5**: 12 を基準、0/100% オンデマンド/スポット | | | | |
| On-Demand Instances (base amount) | 10 | 12 | 12 | 12 |
| On-Demand Instances | 0 | 0 | 0 | 0 |
| Spot Instances | 0 | 8 | 18 | 28 |
グループのサイズが*大きくなる*と、Amazon EC2 Auto Scaling は、指定されたアベイラビリティーゾーン全体でキャパシティのバランスを均等にすることを試みます。次に、指定された配分戦略に従ってインスタンスタイプを起動します。
グループのサイズが*小さくなる*と、Amazon EC2 Auto Scaling は、まず 2 つのタイプ (スポットまたはオンデマンド) のどちらを終了する必要があるかを特定します。その後、指定されたアベイラビリティーゾーン全体でバランスの取れた方法でインスタンスを終了することを試みます。また、優先的に、割り当て戦略に近い方法でインスタンスを終了します。終了ポリシーの詳細については、「[Amazon EC2 Auto Scaling の終了ポリシーを設定する](ec2-auto-scaling-termination-policies.md)」を参照してください。
## リージョン別のインスタンスタイプの可用性
EC2 インスタンスタイプの可用性は、 によって異なります AWS リージョン。例えば、最新世代のインスタンスタイプは、特定のリージョンではまだ利用できない可能性があります。リージョンによってインスタンスの可用性が異なるため、オーバーライドする複数のインスタンスタイプをリージョンで利用できない場合、プログラムでリクエストを行う際に問題が発生する可能性があります。リージョンで利用できない複数のインスタンスタイプを使用すると、リクエストが完全に失敗する可能性があります。この問題を解決するには、異なるインスタンスタイプでリクエストを再試行し、各インスタンスタイプがリージョンで利用可能であることを確認してください。各ロケーションで利用可能なインスタンスタイプを検索するには、[describe-instance-type-offerings](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instance-type-offerings.html) コマンドを使用します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 インスタンスタイプの検索](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html)」を参照してください。
## 関連リソース
スポットインスタンスのベストプラクティスの詳細については、「*Amazon EC2 ユーザーガイド*」の「[EC2 スポットのベストプラクティス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html)」を参照してください。
## 制限事項
[混合インスタンスポリシー](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MixedInstancesPolicy.html)を使用して Auto Scaling グループにオーバーライドを追加した後、`UpdateAutoScalingGroup` API コールでオーバーライドを更新できますが、削除することはできません。オーバーライドを完全に削除するには、まず Auto Scaling グループを切り替え、混合インスタンスポリシーではなく起動テンプレートまたは起動設定を使用する必要があります。その後、オーバーライドなしで混合インスタンスポリシーを再度追加できます。
# 複数のインスタンスタイプの配分戦略
複数のインスタンスタイプを使用する場合、Amazon EC2 Auto Scaling が可能なインスタンスタイプからオンデマンドおよびスポットキャパシティを満たす方法を管理します。これを実行するには、割り当て戦略を指定します。
混合インスタンスグループのベストプラクティスを確認するには、「[混合インスタンスグループを作成するための設定の概要](mixed-instances-groups-set-up-overview.md)」を参照してください。
**Topics**
+ [スポットインスタンス](#spot-allocation-strategy)
+ [オンデマンドインスタンス](#on-demand-allocation-strategy)
+ [配分戦略と重みの仕組み](#lowest-price-allocation-strategy)
## スポットインスタンス
Amazon EC2 Auto Scaling では、スポットインスタンス用に、次の配分戦略を提供しています。
`price-capacity-optimized` (推奨)
価格とキャパシティで最適化された配分戦略では、価格とキャパシティの両方を考慮して、中断される可能性が最も低く、価格ができるだけ低いスポットインスタンスプールを選択します。
使用を開始する際には、この戦略をお勧めします。詳細については、 AWS ブログの[EC2 スポットインスタンスのprice-capacity-optimized配分戦略の紹介](https://aws.amazon.com/blogs/compute/introducing-price-capacity-optimized-allocation-strategy-for-ec2-spot-instances/)」を参照してください。
`capacity-optimized`
Amazon EC2 Auto Scaling は、起動するインスタンスの数に最適なキャパシティを持つプールからスポットインスタンスをリクエストします。
スポットインスタンスでは、料金は需要と供給の長期的な傾向に基づいて時間の経過とともに緩やかに変動します。ただし、キャパシティはリアルタイムで変動します。`capacity-optimized`戦略では、リアルタイムのキャパシティーデータを調べ、可用性の最も高いプールを予測することで、そのプールから スポットインスタンス を自動的に起動します。これにより、作業の再開とチェックポイントに伴う中断コストが高くなる可能性があるワークロードの中断を最小限に抑えることができます。最初に特定のインスタンスタイプを起動する可能性を高めるには、`capacity-optimized-prioritized` を使用します。
`capacity-optimized-prioritized`
起動テンプレートのオーバーライドのリスト内のインスタンスタイプの順序を、優先順位の高いものから順番に (リストの最初から最後まで) 設定することもできます。Amazon EC2 Auto Scaling は、ベストエフォートベースでインスタンスタイプの優先順位を尊重しますが、最初に容量を最適化します。これは、中断の可能性を最小限に抑える必要があるワークロードに適したオプションですが、適切なインスタンスタイプを設定することも重要です。オンデマンド配分戦略を `prioritized` に設定した場合、オンデマンドキャパシティを満たす際にも同じ優先順位が適用されます。
`lowest-price` (非推奨)
スポットインスタンスの中断リスクが非常に高いため、`lowest-price` 戦略はお勧めしません。
Amazon EC2 Auto Scaling は、**[最低料金のプール]** の設定で指定したスポットプールの N 個のプール全体で、アベイラビリティーゾーン内の最低料金のプールを使用してスポットインスタンスをリクエストします。例えば、4 つのインスタンスタイプと 4 つのアベイラビリティーゾーンを指定した場合、Auto Scaling グループは最大 16 個のスポットプールにアクセスできます。(各アベイラビリティーゾーンに 4 個ずつ)。配分戦略で 2 つのスポットプール (N=2) を指定した場合、Auto Scaling グループは、アベイラビリティゾーンあたり 2 つの最低価格のプールを引き出し、スポットキャパシティを満たすことができます。
`lowest-price` 戦略は、 AWS CLIを使用しているときにのみ利用できます。
Amazon EC2 Auto Scaling は、指定された N 個のプールからスポットインスタンスを取得しようとします。ただし、希望するキャパシティを満たす前にプールにスポットキャパシティの残量がなくなった場合、Amazon EC2 Auto Scaling は次に料金の低いプールのキャパシティを利用して引き続きリクエストを満たします。希望するキャパシティを満たすために、指定した N 個を超えるプールからスポットインスタンスが割り当てられることがあります。同様に、ほとんどのプールにスポットキャパシティーがない場合には、指定した N 個より少ないプールから希望するキャパシティのすべてが割り当てられることがあります。
**注記**
[AMD SEV-SNP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sev-snp.html) を有効にして 起動するようにスポットインスタンスを設定すると、選択したインスタンスタイプの[オンデマンド時間料金](https://aws.amazon.com/ec2/pricing/on-demand/)の 10% に相当する追加の時間単位使用料が請求されます。配分戦略で料金を入力として使用する場合、Amazon EC2 Auto Scaling にはこの追加料金は含まれず、スポット料金のみが使用されます。
## オンデマンドインスタンス
Amazon EC2 Auto Scaling では、オンデマンドインスタンスに使用できる、以下の配分戦略を提供しています。
`lowest-price`
Amazon EC2 Auto Scaling は、現在のオンデマンド価格に基づき、各アベイラビリティーゾーンで最も最低価格のインスタンスタイプを自動的にデプロイします。
希望するキャパシティを満たすために、各アベイラビリティーゾーンで複数のタイプのオンデマンドインスタンスを受け取る場合があります。これは、リクエストするキャパシティの大きさによって異なります。
`prioritized`
オンデマンドキャパシティを満たすとき、Amazon EC2 Auto Scaling は、起動テンプレートのオーバーライドのリスト内のインスタンスタイプの順序に基づき、最初に使用するインスタンスタイプを決定します。例えば、3 つの起動テンプレートの優先度を `c5.large`、`c4.large`、`c3.large` と指定するとします。オンデマンドインスタンスが起動すると、Auto Scaling グループは、`c5.large`、`c4.large`、`c3.large` の順にオンデマンドキャパシティを満たします。
オンデマンドインスタンスの優先順位を管理する場合は、次の点を考慮してください。
+ Savings Plans またはリザーブドインスタンスを利用して使用料を前払いすることで、オンデマンドインスタンスの大幅な割引を受けることができます。詳細については、「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」ページを参照してください。
+ リザーブドインスタンスでは、Amazon EC2 Auto Scaling が一致するインスタンスタイプを起動すると、通常のオンデマンドインスタンス コストの割引料金が適用されます。したがって、`c4.large` の未使用のリザーブドインスタンスがある場合、インスタンスタイプの優先順位を設定して、リザーブドインスタンスの最も高い優先順位を `c4.large` インスタンスタイプに付与できます。`c4.large` インスタンスが起動すると、リザーブドインスタンスの料金が発生します。
+ Savings Plans では、Amazon EC2 Instance Savings Plans または Compute Savings Plans を使用する場合、通常のオンデマンドインスタンス コストの割引料金が適用されます。Savings Plans では、インスタンスタイプの優先順位をより柔軟に設定することができます。Savings Plans の対象となるインスタンスタイプであれば、任意の順序で優先順位を設定できます。また、インスタンスタイプの全体の順序を変えることも可能で、その場合でも Savings Plans の割引料金が適用されます。Savings Plans の詳細については、[Savings Plans ユーザーガイド](https://docs.aws.amazon.com/savingsplans/latest/userguide/)を参照してください。
## 配分戦略と重みの仕組み
オーバーライド (またはグループレベルでは `"DesiredCapacityType": "vcpu"` もしくは `"DesiredCapacityType": "memory-mib"`) で `WeightedCapacity` パラメータを指定すると、配分戦略は他の Auto Scaling グループの場合とまったく同じように機能します。
vCPU の量が異なる複数のインスタンスタイプを含む Auto Scaling グループがあるとします。スポットとオンデマンドの配分戦略として `lowest-price` を使うとします。各インスタンスタイプの vCPU 数に基づいた重みの割り当てを選択する場合、Amazon EC2 Auto Scaling は、フルフィルメントの時点で割り当てられた重みの値 (vCPU など) あたりの料金が最も低いインスタンスタイプを起動します。スポットインスタンスの場合、これは vCPU あたりの最低スポット料金であることを意味します。オンデマンドインスタンスの場合、これは vCPU あたりの最低オンデマンド料金であることを意味します。
詳細については、「[インスタンスの重みを使用するように Auto Scaling グループを設定する](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)」を参照してください。
# 属性ベースのインスタンスタイプの選択を使用して混合インスタンスグループを作成する
混合インスタンスグループのインスタンスタイプを手動で選択する代わりに、コンピューティング要件を記述するインスタンス属性のセットを指定できます。Amazon EC2 Auto Scaling がインスタンスを起動するとき、Auto Scaling グループで使用されるインスタンスタイプは、必要なインスタンス属性と一致している必要があります。これは*属性ベースのインスタンスタイプの選択*と呼ばれます。
このアプローチは、コンテナやビッグデータ、CI/CD など、柔軟にインスタンスタイプを使用するワークロードとフレームワークに最適です。
属性ベースのインスタンスタイプを選択すると、次の利点があります。
+ **スポットインスタンスでのオプションの柔軟性** — Amazon EC2 Auto Scaling は、幅広いインスタンスタイプからスポットインスタンスを選択して起動できます。これは、インスタンスタイプに対して柔軟であるという、スポットのベストプラクティスを満たしています。これにより、Amazon EC2 スポットサービスが必要なコンピューティング性能を見つけ、割り当てられる機会に恵まれます。
+ **適切なインスタンスタイプを簡単に使用** - 利用可能なインスタンスタイプの数が多いため、ワークロードに適したインスタンスタイプを見つけるには時間がかかることがあります。インスタンス属性を指定すると、インスタンスタイプにはワークロードに必要な属性が自動的に設定されます。
+ **新しいインスタンスタイプの自動的な使用** — Auto Scaling グループでは、リリースされた時点で、新しい世代のインスタンスタイプを使用できます。要件に一致し、かつ Auto Scaling グループのために選択した割り当て戦略にマッチする場合には、新しい世代のインスタンスタイプが自動的に使用されます。
**Topics**
+ [属性ベースのインスタンスタイプ選択の仕組み](#how-attribute-based-instance-type-selection-works)
+ [料金保護](#understand-price-protection)
+ [パフォーマンス保護](#understand-performance-protection)
+ [前提条件](#attribute-based-instance-type-selection-prerequisites)
+ [属性ベースのインスタンスタイプの選択を使用して混合インスタンスグループを作成する (コンソール)](#attribute-based-instance-type-selection-console)
+ [属性ベースのインスタンスタイプの選択を使用して混合インスタンスグループを作成する (AWS CLI)](#attribute-based-instance-type-selection-aws-cli)
+ [設定例](#attribute-based-instance-type-selection-example-configurations)
+ [インスタンスタイプをプレビューする](#attribute-based-instance-type-selection-preview)
+ [関連リソース](#attribute-based-instance-type-selection-related-resources)
## 属性ベースのインスタンスタイプ選択の仕組み
属性ベースのインスタンスタイプの選択では、特定のインスタンスタイプのリストの代わりに、以下のようなインスタンスに必要なインスタンス属性のリストが提供されます。
+ **vCPU 数** – インスタンスあたりの vCPU の最小数と最大数。
+ **メモリ** – インスタンスあたりのメモリの最小および最大 GiB。
+ **ローカルストレージ** – EBS ボリュームとインスタンスストアボリュームのどちらをローカルストレージに使用するか。
+ **バースト可能なパフォーマンス** – T4g、T3a、T3、および T2 タイプを含む T インスタンスファミリーを使用するかどうか。
インスタンス要件を定義するには、多くのオプションを使用できます。各オプションの説明およびデフォルト値については、「*Amazon EC2 Auto Scaling API リファレンス*」の「[InstanceRequirements](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstanceRequirements.html)」を参照してください。
Auto Scaling グループがインスタンスを起動する必要がある場合、指定した属性に一致し、そのアベイラビリティーゾーンで使用できるインスタンスタイプが検索されます。その後、配分戦略によって、起動する一致するインスタンスタイプが決定されます。属性ベースのインスタンスタイプの選択ではデフォルトで、Auto Scaling グループが予算のしきい値を超えるインスタンスタイプを起動できないようにする料金の保護機能が有効になっています。
デフォルトでは、Auto Scaling グループの希望する容量を設定する際に、インスタンスの数を測定単位として使用します。つまり、各インスタンスが 1 つの単位としてカウントされます。
あるいは、希望するキャパシティの値を vCPU の数またはメモリ量に設定することもできます。そのためには、 の **Desired capacity type**ドロップダウンフィールド、 AWS マネジメントコンソール または `CreateAutoScalingGroup`または `UpdateAutoScalingGroup` API オペレーションの `DesiredCapacityType`プロパティを使用します。その後 Amazon EC2 Auto Scaling により、希望する vCPU またはメモリ容量を満たすのに必要な数のインスタンスが起動されます。例えば、希望する容量タイプとして vCPU を使用し、それぞれ 2 つの vCPU を持つインスタンスを使用する場合、10 個の vCPU 容量で 5 つのインスタンスが起動されます。これは、[インスタンスの重み](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)に代わる便利な方法です。
## 料金保護
料金の保護を使用すると、Auto Scaling グループによって起動される EC2 インスタンスに対して支払う最大料金を指定できます。料金の保護は、指定した属性に適合した場合でも、コストが高すぎると思われるインタンスタイプについては Auto Scaling グループで使用できないようにする機能です。
料金の保護はデフォルトで有効になっており、オンデマンドインスタンスとスポットインスタンスにおける料金のしきい値は異なります。Amazon EC2 Auto Scaling が新しいインスタンスを起動する必要がある場合、関連するしきい値を超える料金のインスタンスタイプは起動されません。
**Topics**
+ [オンデマンド料金の保護](#on-demand-price-price-protection)
+ [スポット料金の保護](#spot-price-price-protection)
+ [料金の保護をカスタマイズする](#customize-price-price-protection)
### オンデマンド料金の保護
オンデマンドインスタンスの場合、指定のオンデマンド料金よりも高い割合で支払うことができる最大のオンデマンド料金を定義します。指定のオンデマンド料金は、指定された属性を持つ現行世代の C、M、または R インスタンスタイプ中で最も安いです。
オンデマンド料金の保護の値が明確に定義されていない場合、指定のオンデマンド料金よりも 20% 高いデフォルトのオンデマンド料金が最大料金として使用されます。
### スポット料金の保護
Amazon EC2 Auto Scaling ではデフォルトで、最適なスポットインスタンス料金の保護が自動的に適用され、幅広いインスタンスタイプから一貫して選択されます。料金保護を手動で設定することもできます。ただし、Amazon EC2 Auto Scaling に任せることで、スポット容量が満たされる可能性を高めることができます。
料金保護は、次のいずれかのオプションを使用して手動で指定できます。料金保護を手動で設定する場合は、最初のオプションを使用することをお勧めします。
+ **指定の*オンデマンド料金*の割合** — 指定のオンデマンド料金は、指定された属性を持つ現行世代の C、M、または R インスタンスタイプ中で最も安いです。
+ **指定の*スポット料金*よりも高い割合** — 指定のスポット料金は、指定された属性を持つ現行世代の C、M、または R インスタンスタイプの中で最も安いです。スポット料金および料金の保護のしきい値は変動する可能性があるため、このオプションの使用は推奨されません。
### 料金の保護をカスタマイズする
Amazon EC2 Auto Scaling コンソール、または AWS CLI または SDKs を使用して、料金保護のしきい値をカスタマイズできます。
+ コンソールで、**[追加のインスタンス属性]** の **[オンデマンド料金の保護]** および **[スポット料金の保護]** 設定を使用します。
+ [InstanceRequirements](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstanceRequirements.html) 構造で、オンデマンドインスタンス料金の保護のしきい値を指定するには、`OnDemandMaxPricePercentageOverLowestPrice` プロパティを使用します。スポットインスタンス料金の保護のしきい値を指定するには、`MaxSpotPriceAsPercentageOfOptimalOnDemandPrice` または `SpotMaxPricePercentageOverLowestPrice` プロパティのいずれかを使用します。
**[希望する容量タイプ]** (`DesiredCapacityType`) を **vCPU** または**メモリ GiB** に設定した場合、料金の保護は、インスタンスごとの料金ではなく、vCPU あたりまたはメモリあたりの料金に基づいて適用されます。
料金保護をオフにすることもできます。料金保護のしきい値を指定しない場合は、`999999` などの高いパーセンテージ値を指定します。
**注記**
現行世代の C、M、または R インスタンスタイプが指定の属性と一致しない場合でも、料金の保護は適用されます。一致するものが見つからなかった場合、指定の料金は現行世代のインスタンスタイプの中で最も安価なものになります。それもない場合は、属性に一致する前世代のインスタンスタイプの中で最も安価なものになります。
## パフォーマンス保護
*パフォーマンス保護*は、Auto Scaling グループが指定されたパフォーマンスベースラインと同等以上のインスタンスタイプを使用できるようにする機能です。パフォーマンス保護を使用するには、ベースラインリファレンスとしてインスタンスファミリーを指定します。指定されたインスタンスファミリーの機能は、許容される最低レベルのパフォーマンスを確立します。Auto Scaling がインスタンスタイプを選択すると、指定した属性およびパフォーマンスベースラインが考慮されます。パフォーマンスベースラインを下回るインスタンスタイプは、他の指定された属性と一致しても、自動的に選択から除外されます。選択したすべてのインスタンスタイプが、指定されたインスタンスファミリーによって確立されたベースラインと同等以上のパフォーマンスを提供できるようにします。Auto Scaling はこのベースラインを使用してインスタンスタイプの選択をガイドしますが、選択したインスタンスタイプがすべてのアプリケーションのベースラインを常に上回る保証はありません。
現在、この機能はベースラインパフォーマンス係数として CPU パフォーマンスのみをサポートしています。指定されたインスタンスファミリーの CPU パフォーマンスがパフォーマンスベースラインとして使用され、選択したインスタンスタイプがこのベースラインと同等以上であるようにします。同じ CPU プロセッサを持つインスタンスファミリーは、ネットワークまたはディスクのパフォーマンスが異なっても、同じフィルタリング結果になります。例えば、ベースラインリファレンスとして `c6in` または `c6i` を指定すると、両方のインスタンスファミリーが同じ CPU プロセッサを使用するため、パフォーマンスベースのフィルタリング結果が同じになります。
**サポートされていないインスタンスファミリー**
次のインスタンスファミリーはパフォーマンス保護でサポートされていません。
+ `c1`
+ `g3` \$1 `g3s`
+ `hpc7g`
+ `m1` \$1 `m2`
+ `mac1` \$1 `mac2` \$1 `mac2-m1ultra` \$1 `mac2-m2` \$1 `mac2-m2pro`
+ `p3dn` \$1 `p4d` \$1 `p5`
+ `t1`
+ `u-12tb1` \$1 `u-18tb1` \$1 `u-24tb1` \$1 `u-3tb1` \$1 `u-6tb1` \$1 `u-9tb1` \$1 `u7i-12tb` \$1 `u7in-16tb` \$1 `u7in-24tb` \$1 `u7in-32tb`
サポートされているインスタンスファミリーを指定してパフォーマンス保護を有効にした場合、返されるインスタンスタイプは上記のサポートされていないインスタンスファミリーを除外します。
**例: CPU パフォーマンスベースラインの設定**
次の例では、インスタンス要件は、`c6i` インスタンスファミリーと同等のパフォーマンスの CPU コアを持つインスタンスタイプで起動することです。性能が下回る CPU プロセッサーが指定した他のインスタンス要件 (vCPU 数など) を満たしても、その CPU プロセッサーを持つインスタンスタイプを除外します。例えば、指定したインスタンス属性に 4 つの vCPUs および 16 GB のメモリが含まれている場合、これらの属性を持っても `c6i` より CPU パフォーマンスが低いインスタンスタイプは選択から除外されます。
```
"BaselinePerformanceFactors": {
"Cpu": {
"References": [
{
"InstanceFamily": "c6i"
}
]
}
```
**考慮事項**
パフォーマンス保護を使用する場合は、次の点を考慮します。
+ インスタンスタイプまたはインスタンス属性のいずれかを指定できますが、両方を同時に指定することはできません。
+ リクエスト設定では、最大 4 つの `InstanceRequirements` 構造を指定できます。
## 前提条件
+ 起動テンプレートを作成する。詳細については、「[Auto Scaling グループの起動テンプレートを作成する](create-launch-template.md)」を参照してください。
+ 起動テンプレートがまだスポットインスタンスをリクエストしていないことを確認します。
## 属性ベースのインスタンスタイプの選択を使用して混合インスタンスグループを作成する (コンソール)
属性ベースのインスタンスタイプの選択を使用して混合インスタンスグループを作成するには、次の手順を実行します。ステップを効率的に進めるために、いくつかのオプションのセクションは省略されています。
ほとんどの汎用的なワークロードでは、必要な vCPU とメモリの数を指定すれば十分です。高度なユースケースでは、ストレージのタイプ、ネットワークインターフェイス、CPU の製造元、アクセラレーターのタイプなどの属性を指定できます。
混合インスタンスグループのベストプラクティスを確認するには、「[混合インスタンスグループを作成するための設定の概要](mixed-instances-groups-set-up-overview.md)」を参照してください。
**混合インスタンスグループを作成するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。
1. 画面の上部のナビゲーションバーで、起動テンプレートを作成したときに使用したのと同じ AWS リージョン を選択します。
1. [**Auto Scaling グループの作成**] を選択します。
1. [**起動テンプレートまたは起動設定を選択する**] ページで [**Auto Scaling グループ名**] にAuto Scaling グループの名前を入力します。
1. 起動テンプレートを選択するには、以下の手順を実行します。
1. [**起動テンプレート**] で、既存の起動テンプレートを選択します。
1. [**起動テンプレートのバージョン**] で、スケールアウト時に Auto Scaling グループで使用する起動テンプレートのバージョン (デフォルト、最新、または特定のバージョン) を選択します。
1. 起動テンプレートが、使用する予定のすべてのオプションをサポートしていることを確認し、[**次へ**] を選択します。
1. **[インスタンス起動オプションを選択]** ページで、次を実行します。
1. **[Instance type requirements]** (インスタンスタイプの要件) で、**[Override launch template]** (起動テンプレートを上書きする) を選択します。
**注記**
vCPU やメモリなどのインスタンス属性のセットが既に含まれている起動テンプレートを選択した場合は、インスタンス属性が表示されます。これらの属性は Auto Scaling グループのプロパティに追加され、Amazon EC2 Auto Scaling コンソールからいつでも更新できます。
1. **[Specify instance attributes]** (インスタンスの属性を指定する) で、まず vCPU とメモリの要件を入力します。
+ **[vCPUs]** に、希望する vCPU の最小数と最大数を入力してください。制限なしを指定するには、**[No minimum]** (最小値なし)、**[No maximum]** (最大値なし)、または両方を選択してください。
+ **[Memory (GiB)]** (メモリ (GiB)) に、希望する最小値と最大値を入力してください。制限なしを指定するには、**[No minimum]** (最小値なし)、**[No maximum]** (最大値なし)、または両方を選択してください。
1. (オプション) **[Additional instance attributes]** (その他のインスタンス属性) では、オプションで 1 つ以上の属性を指定して、コンピューティング要件をより詳細に表現できます。追加の属性は、リクエストにさらに制約を追加します。
1. **[一致するインスタンスタイプをプレビュー]** を展開して、指定した属性を持つインスタンスタイプを表示します。
1. **[インスタンスの購入オプション]** の **[インスタンスの分散]** で、オンデマンドインスタンスとスポットインスタンスとして起動するグループの割合をそれぞれ指定します。アプリケーションが、ステートレスでフォールトトレラントであり、中断されるインスタンスを扱える場合は、より高い割合のスポットインスタンスを指定できます。
1. (オプション) スポットインスタンスの割合を指定するときは、**[オンデマンドベースキャパシティを含める]** を選択してから、オンデマンドインスタンスによって満たされる必要がある Auto Scaling グループの最小初期キャパシティを指定します。ベースキャパシティーを超える場合は、**[Instances distribution]** (インスタンスの分散) 設定を使用して、起動するオンデマンドインスタンスとスポットインスタンスの数を決定します。
1. **[Allocation strategies]** (配分戦略) の**[Lowest price]** (最低価格) は、**[On-Demand allocation strategy]** (オンデマンドの配分戦略) によって自動的に選択され、変更できません。
1. **[Spot allocation strategy]** (スポット配分戦略) で、配分戦略を選択します。デフォルトでは、**[Price capacity optimized]** (価格のキャパシティの最適化) が選択されています。
1. **[容量の再分散]** で、容量の再分散を有効にするか無効にするかを選択します。キャパシティの再調整を使用すると、スポットインスタンスがスポットの中断によって終了に近づいたときに自動的に応答します。詳細については、「[リスクがあるスポットインスタンスを置き換えるための Auto Scaling でのキャパシティの再調整](ec2-auto-scaling-capacity-rebalancing.md)」を参照してください。
1. **[Network]** (ネットワーク) の下にある **[VPC]** で、VPC を選択します。Auto Scaling グループは、起動テンプレートで指定したセキュリティグループと、同じ VPC 内に作成する必要があります。
1. **[Availability Zones and subnets]** (アベイラビリティーゾーンとサブネット) で、指定した VPC 内のサブネットを 1 つ以上選択します。複数のアベイラビリティーゾーンのサブネットを使用することで、高可用性を得られます。詳細については、「[VPC サブネットを選択する場合の考慮事項](asg-in-vpc.md#as-vpc-considerations)」を参照してください。
1. **[次へ]**、**[次へ]** を選択します。
1. **[Configure group size and scaling policies]** (グループサイズとスケーリングポリシーを設定する) ステップでは、以下の手順を実行します。
1. 希望する容量をインスタンス以外のユニットで測定するには、**[グループサイズ]** および **[希望する容量タイプ]** で適切なオプションを選択します。**[Units]** (ユニット)、**[vCPUs]**、および **[Memory GiB]** (メモリ GiB) がサポートされています。デフォルトで、Amazon EC2 Auto Scaling は **[Units]** (ユニット) を指定します。これはインスタンスの数になります。
1. **[希望する容量]** で、Auto Scaling グループの初期サイズを設定します。
1. **[スケーリング]** セクションの **[スケーリング制限]** で、**[希望する容量]** の新しい値が **[最小の希望する容量]** と **[最大の希望する容量]** より大きい場合、**[最大の希望する容量]** は自動的に希望する新しい容量の値に引き上げられます。これらの制限は、必要に応じて変更できます。詳細については、「[Auto Scaling グループのスケーリング制限を設定する](asg-capacity-limits.md)」を参照してください。
1. [**Skip to review**] を選択します。
1. [**Review (レビュー)**]ページで、[**Create Auto Scaling group (Auto Scaling グループを作成)**] を選択します。
## 属性ベースのインスタンスタイプの選択を使用して混合インスタンスグループを作成する (AWS CLI)
**コマンドラインを使用して混合インスタンスグループを作成するには**
以下のいずれかのコマンドを使用します。
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) (AWS CLI)
+ [New-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
## 設定例
AWS CLIを使用して、属性ベースのインスタンスタイプを選択した Auto Scaling グループを作成するには、次の [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用します。
次のインスタンス属性が指定されています。
+ `VCpuCount` — インスタンスタイプには、4 個以上、最大 8 個の vCPU が必要です。
+ `MemoryMiB` – インスタンスタイプには最低 16,384 MiB のメモリが必要です。
+ `CpuManufacturers` — インスタンスタイプには、インテル製の CPU が必要です。
### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
次は、`config.json` ファイルの例です。
```
{
"AutoScalingGroupName": "my-asg",
"DesiredCapacityType": "units",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Default"
},
"Overrides": [{
"InstanceRequirements": {
"VCpuCount": {"Min": 4, "Max": 8},
"MemoryMiB": {"Min": 16384},
"CpuManufacturers": ["intel"]
}
}]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 50,
"SpotAllocationStrategy": "price-capacity-optimized"
}
},
"MinSize": 0,
"MaxSize": 100,
"DesiredCapacity": 4,
"DesiredCapacityType": "units",
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
vCPU の数またはメモリーの総量として、希望するキャパシティー値を設定するには、ファイルで `"DesiredCapacityType": "vcpu"` または `"DesiredCapacityType": "memory-mib"` を指定します。希望するキャパシティータイプのデフォルトは `units` で、これはインスタンスの数を、希望するキャパシティー値として設定します。
### YAML
または、次の [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用して、Auto Scaling グループを作成します。これは、Auto Scaling グループの唯一のパラメータとして YAML ファイルを参照します。
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
次は、`config.yaml` ファイルの例です。
```
---
AutoScalingGroupName: my-asg
DesiredCapacityType: units
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceRequirements:
VCpuCount:
Min: 2
Max: 4
MemoryMiB:
Min: 2048
CpuManufacturers:
- intel
InstancesDistribution:
OnDemandPercentageAboveBaseCapacity: 50
SpotAllocationStrategy: price-capacity-optimized
MinSize: 0
MaxSize: 100
DesiredCapacity: 4
DesiredCapacityType: units
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
vCPU の数またはメモリーの総量として、希望するキャパシティー値を設定するには、ファイルで `DesiredCapacityType: vcpu` または `DesiredCapacityType: memory-mib` を指定します。希望するキャパシティータイプのデフォルトは `units` で、これはインスタンスの数を、希望するキャパシティー値として設定します。
属性ベースのインスタンスタイプの選択で複数の起動テンプレートを使用する方法の例については、「[複数の起動テンプレートを使用する](ec2-auto-scaling-mixed-instances-groups-launch-template-overrides.md)」を参照してください。
## インスタンスタイプをプレビューする
インスタンスを起動することなくコンピューティング要件に一致するインスタンスタイプをプレビューでき、必要に応じて要件を調整できます。Amazon EC2 Auto Scaling コンソールで Auto Scaling グループを作成すると、**[Choose instance launch options]** (インスタンス起動オプションを選択) ページの **[Preview matching instance types]** (一致するインスタンスタイプのプレビュー) セクションに、インスタンスタイプのプレビューが表示されます。
または、 AWS CLI または SDK を使用して Amazon EC2 [GetInstanceTypesFromInstanceRequirements](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetInstanceTypesFromInstanceRequirements.html) API コールを行うことで、インスタンスタイプをプレビューすることもできます。Auto Scaling グループの作成または更新のリクエストの中で、正しい形式で `InstanceRequirements` パラメーターを渡します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[指定された属性でインスタンスタイプをプレビューする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html#ec2fleet-get-instance-types-from-instance-requirements)」を参照してください。
## 関連リソース
属性ベースのインスタンスタイプの選択の詳細については、 AWS ブログの[EC2 Auto Scaling と EC2 フリートの属性ベースのインスタンスタイプの選択](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)」を参照してください。
CloudFormationを使用して Auto Scaling グループを作成する際に、属性ベースのインスタンスタイプの選択を宣言できます。詳細については、「CloudFormation ユーザーガイド」の「[Auto Scaling テンプレートスニペット](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-autoscaling.html#scenario-mixed-instances-group-template-examples)」セクションのサンプルスニペットを参照してください。
# インスタンスタイプを手動で選択して混合インスタンスグループを作成する
このトピックでは、インスタンスタイプを手動で選択して、単一の Auto Scaling グループで複数のインスタンスタイプを起動する方法を示します。
インスタンスタイプを選択する基準としてインスタンス属性を使用する場合は、「[属性ベースのインスタンスタイプの選択を使用して混合インスタンスグループを作成する](create-mixed-instances-group-attribute-based-instance-type-selection.md)」を参照してください。
**Topics**
+ [前提条件](#manual-instance-type-selection-prerequisites)
+ [混合インスタンスグループを作成する (コンソール)](#manual-instance-type-selection-console)
+ [混合インスタンスグループを作成する (AWS CLI)](#manual-instance-type-selection-aws-cli)
+ [設定例](#manual-instance-type-selection-example-configurations)
## 前提条件
+ 起動テンプレートを作成する。詳細については、「[Auto Scaling グループの起動テンプレートを作成する](create-launch-template.md)」を参照してください。
+ 起動テンプレートがまだスポットインスタンスをリクエストしていないことを確認します。
## 混合インスタンスグループを作成する (コンソール)
次の手順を実行して、グループが起動できるインスタンスタイプを手動で選択し、混合インスタンスグループを作成します。ステップを効率的に進めるために、いくつかのオプションのセクションは省略されています。
混合インスタンスグループのベストプラクティスを確認するには、「[混合インスタンスグループを作成するための設定の概要](mixed-instances-groups-set-up-overview.md)」を参照してください。
**混合インスタンスグループを作成するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。
1. 画面の上部のナビゲーションバーで、起動テンプレートを作成したときに使用したのと同じ AWS リージョン を選択します。
1. [**Auto Scaling グループの作成**] を選択します。
1. [**起動テンプレートまたは起動設定を選択する**] ページで [**Auto Scaling グループ名**] にAuto Scaling グループの名前を入力します。
1. 起動テンプレートを選択するには、以下の手順を実行します。
1. [**起動テンプレート**] で、既存の起動テンプレートを選択します。
1. [**起動テンプレートのバージョン**] で、スケールアウト時に Auto Scaling グループで使用する起動テンプレートのバージョン (デフォルト、最新、または特定のバージョン) を選択します。
1. 起動テンプレートが、使用する予定のすべてのオプションをサポートしていることを確認し、**[Next]** (次へ) を選択します。
1. **[インスタンス起動オプションを選択]** ページで、次を実行します。
1. **[Instance type requirements]** (インスタンスタイプの要件) で、**[Override launch template]** (起動テンプレートを上書きする) を選択してから、**[Manually add instance types]** (インスタンスタイプを手動で追加する) を選択します。
1. インスタンスタイプを選択します。まずはレコメンデーションを使用できます。デフォルトでは、**[Family and generation flexible]** (ファミリーと世代が柔軟) が選択されています。
+ インスタンスタイプの順序を変更するには、矢印を使用します。優先順位付けをサポートする配分戦略を選択した場合、インスタンスタイプの順序によって起動の優先順位が設定されます。
+ インスタンスタイプを削除するには、**[X]** を選択します。
+ (オプション) **[重み]** 列のボックスで、各インスタンスタイプに相対的な重みを割り当てます。これを行うには、そのタイプのインスタンスがグループの希望するキャパシティにカウントされるユニット数を入力します。これが便利なのは、インスタンスタイプ別に異なる vCPU、メモリ、ストレージ、またはネットワーク帯域幅の機能を設定する場合です。詳細については、「[インスタンスの重みを使用するように Auto Scaling グループを設定する](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)」を参照してください。
**[サイズが柔軟]** のレコメンデーションを使用することを選択した場合は、このセクションに含まれるすべてのインスタンスタイプに自動的に重みの値が設定されることに留意してください。重みを指定したくない場合は、すべてのインスタンスタイプについて **[Weight]** (重み) 列のボックスをクリアしてください。
1. **[Instance purchase options]** (インスタンスの購入オプション) の **[Instances distribution]** (インスタンスの分散) で、オンデマンドインスタンスとスポットインスタンスとして起動されるグループの割合をそれぞれ指定します。アプリケーションが、ステートレスでフォールトトレラントであり、中断されるインスタンスを扱える場合は、より高い割合のスポットインスタンスを指定できます。
1. (オプション) スポットインスタンスの割合を指定するときは、**[オンデマンドベースキャパシティを含める]** を選択してから、オンデマンドインスタンスによって満たされる必要がある Auto Scaling グループの最小初期キャパシティを指定します。ベースキャパシティーを超える場合は、**[Instances distribution]** (インスタンスの分散) 設定を使用して、起動するオンデマンドインスタンスとスポットインスタンスの数を決定します。
1. **[Allocation strategies]** (配分戦略) の **[On-Demand allocation strategy]** (オンデマンドの配分戦略) で、配分戦略を選択します。インスタンスタイプを手動で選択すると、デフォルトで **[Prioritized]** (高い優先順位で設定済み) が選択されます。
1. **[Spot allocation strategy]** (スポット配分戦略) で、配分戦略を選択します。デフォルトでは、**[Price capacity optimized]** (価格のキャパシティの最適化) が選択されています。
**[キャパシティ最適化]** を選択した場合は、必要に応じて **[インスタンスタイプの優先順位を設定]** ボックスをオンにして、インスタンスタイプのリスト順に基づいて最初に起動するインスタンスタイプを Amazon EC2 Auto Scaling が選択できるようにします。
1. **[容量の再分散]** で、容量の再分散を有効にするか無効にするかを選択します。キャパシティの再調整を使用すると、スポットインスタンスがスポットの中断によって終了に近づいたときに自動的に応答します。詳細については、「[リスクがあるスポットインスタンスを置き換えるための Auto Scaling でのキャパシティの再調整](ec2-auto-scaling-capacity-rebalancing.md)」を参照してください。
1. **[Network]** (ネットワーク) の下にある **[VPC]** で、VPC を選択します。Auto Scaling グループは、起動テンプレートで指定したセキュリティグループと、同じ VPC 内に作成する必要があります。
1. **[Availability Zones and subnets]** (アベイラビリティーゾーンとサブネット) で、指定した VPC 内のサブネットを 1 つ以上選択します。複数のアベイラビリティーゾーンのサブネットを使用することで、高可用性を得られます。詳細については、「[VPC サブネットを選択する場合の考慮事項](asg-in-vpc.md#as-vpc-considerations)」を参照してください。
1. **[次へ]**、**[次へ]** を選択します。
1. **[Configure group size and scaling policies]** (グループサイズとスケーリングポリシーを設定する) ステップでは、以下の手順を実行します。
1. **[グループサイズ]** の **[希望する容量]** に、起動するインスタンスの初期数を入力します。
デフォルトでは、希望する容量はインスタンスの数として表されます。インスタンスタイプに重みを割り当てた場合は、この値を、重みの割り当てに使用したのと同じ測定単位 (vCPU の数など) に変換する必要があります。
1. **[スケーリング]** セクションの **[スケーリング制限]** で、**[希望する容量]** の新しい値が **[最小の希望する容量]** と **[最大の希望する容量]** より大きい場合、**[最大の希望する容量]** は自動的に希望する新しい容量の値に引き上げられます。これらの制限は、必要に応じて変更できます。詳細については、「[Auto Scaling グループのスケーリング制限を設定する](asg-capacity-limits.md)」を参照してください。
1. [**Skip to review**] を選択します。
1. [**Review (レビュー)**]ページで、[**Create Auto Scaling group (Auto Scaling グループを作成)**] を選択します。
## 混合インスタンスグループを作成する (AWS CLI)
**コマンドラインを使用して混合インスタンスグループを作成するには**
以下のいずれかのコマンドを使用します。
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) (AWS CLI)
+ [New-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
## 設定例
次の設定例は、さまざまなスポット割り当て戦略を使用して混合インスタンスグループを作成する方法を示しています。
**注記**
これらの例は、JSON または YAML でフォーマットされた設定ファイルの使用方法を示しています。 AWS CLI バージョン 1 を使用する場合は、JSON 形式の設定ファイルを指定する必要があります。 AWS CLI バージョン 2 を使用する場合は、YAML または JSON のいずれかでフォーマットされた設定ファイルを指定できます。
**Topics**
+ [例 1: `capacity-optimized` 割り当て戦略を使用して スポットインスタンス を起動する](#capacity-optimized-aws-cli)
+ [例 2: `capacity-optimized-prioritized` 割り当て戦略を使用して スポットインスタンス を起動する](#capacity-optimized-prioritized-aws-cli)
+ [例 3: 2つのプール間での `lowest-price` 配分戦略を使用してスポットインスタンスを起動する](#lowest-price-aws-cli)
+ [例 4: 配分戦略を使用して スポットインスタンス を起動する`price-capacity-optimized`](#price-capacity-optimized-aws-cli)
### 例 1: `capacity-optimized` 割り当て戦略を使用して スポットインスタンス を起動する
次の [[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)] コマンドは、以下を指定する Auto Scaling グループを作成します。
+ オンデマンドインスタンスとして起動するグループの割合 (`0`) と開始時のオンデマンドインスタンスのベース数 (`1`)
+ 優先度に従って起動するインスタンスタイプ (`c5.large`、`c5a.large`、`m5.large`、`m5a.large`、`c4.large`、`m4.large`、`c3.large`、`m3.large`)。
+ インスタンスを起動するサブネット (`subnet-5ea0c127`、`subnet-6194ea3b`、`subnet-c934b782`)。それぞれが異なるアベイラビリティーゾーンに対応します。
+ 起動テンプレート (`my-launch-template`) とそのバージョン (`$Default`)。
Amazon EC2 Auto Scaling がオンデマンドキャパシティーを満たそうとするとき、まず `c5.large` インスタンスタイプを起動します。スポットインスタンスは、スポットインスタンスのキャパシティーに基づいて、各アベイラビリティーゾーンの最適なスポットプールから取得されます。
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` ファイルには次のコンテンツが含まれます。
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Default"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandBaseCapacity": 1,
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "capacity-optimized"
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
または、次の [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用して、Auto Scaling グループを作成します。これは、Auto Scaling グループの唯一のパラメータとして YAML ファイルを参照します。
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
`config.yaml` ファイルには次のコンテンツが含まれます。
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandBaseCapacity: 1
OnDemandPercentageAboveBaseCapacity: 0
SpotAllocationStrategy: capacity-optimized
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
### 例 2: `capacity-optimized-prioritized` 割り当て戦略を使用して スポットインスタンス を起動する
次の [[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)] コマンドは、以下を指定する Auto Scaling グループを作成します。
+ オンデマンドインスタンスとして起動するグループの割合 (`0`) と開始時のオンデマンドインスタンスのベース数 (`1`)
+ 優先度に従って起動するインスタンスタイプ (`c5.large`、`c5a.large`、`m5.large`、`m5a.large`、`c4.large`、`m4.large`、`c3.large`、`m3.large`)。
+ インスタンスを起動するサブネット (`subnet-5ea0c127`、`subnet-6194ea3b`、`subnet-c934b782`)。それぞれが異なるアベイラビリティーゾーンに対応します。
+ 起動テンプレート (`my-launch-template`) とそのバージョン (`$Latest`)。
Amazon EC2 Auto Scaling がオンデマンドキャパシティーを満たそうとするとき、まず `c5.large` インスタンスタイプを起動します。Amazon EC2 Auto Scaling がスポットキャパシティーを満たそうとするとき、ベストエフォートベースでインスタンスタイプの優先順位を尊重します。ただし、最初にキャパシティを最適化します。
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` ファイルには次のコンテンツが含まれます。
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandBaseCapacity": 1,
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "capacity-optimized-prioritized"
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
または、次の [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用して、Auto Scaling グループを作成します。これは、Auto Scaling グループの唯一のパラメータとして YAML ファイルを参照します。
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
`config.yaml` ファイルには次のコンテンツが含まれます。
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandBaseCapacity: 1
OnDemandPercentageAboveBaseCapacity: 0
SpotAllocationStrategy: capacity-optimized-prioritized
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
### 例 3: 2つのプール間での `lowest-price` 配分戦略を使用してスポットインスタンスを起動する
次の [[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)] コマンドは、以下を指定する Auto Scaling グループを作成します。
+ オンデマンドインスタンスとして起動するグループの割合 (`50`)。(これは、開始時のオンデマンドインスタンスのベース数を指定するものではありません)。
+ 優先度に従って起動するインスタンスタイプ (`c5.large`、`c5a.large`、`m5.large`、`m5a.large`、`c4.large`、`m4.large`、`c3.large`、`m3.large`)
+ インスタンスを起動するサブネット (`subnet-5ea0c127`、`subnet-6194ea3b`、`subnet-c934b782`)。それぞれが異なるアベイラビリティーゾーンに対応します。
+ 起動テンプレート (`my-launch-template`) とそのバージョン (`$Latest`)。
Amazon EC2 Auto Scaling がオンデマンドキャパシティーを満たそうとするとき、まず `c5.large` インスタンスタイプを起動します。スポットキャパシティーについては、Amazon EC2 Auto Scaling は、各アベイラビリティーゾーンで 2 つの最低価格のプールのスポットインスタンスを均等に起動しようとします。
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` ファイルには次のコンテンツが含まれます。
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 50,
"SpotAllocationStrategy": "lowest-price",
"SpotInstancePools": 2
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
または、次の [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用して、Auto Scaling グループを作成します。これは、Auto Scaling グループの唯一のパラメータとして YAML ファイルを参照します。
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
`config.yaml` ファイルには次のコンテンツが含まれます。
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandPercentageAboveBaseCapacity: 50
SpotAllocationStrategy: lowest-price
SpotInstancePools: 2
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
### 例 4: 配分戦略を使用して スポットインスタンス を起動する`price-capacity-optimized`
次の [[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)] コマンドは、以下を指定する Auto Scaling グループを作成します。
+ オンデマンドインスタンスとして起動するグループの割合 (`30`)。(これは、開始時のオンデマンドインスタンスのベース数を指定するものではありません)。
+ 優先度に従って起動するインスタンスタイプ (`c5.large`、`c5a.large`、`m5.large`、`m5a.large`、`c4.large`、`m4.large`、`c3.large`、`m3.large`)
+ インスタンスを起動するサブネット (`subnet-5ea0c127`、`subnet-6194ea3b`、`subnet-c934b782`)。それぞれが異なるアベイラビリティーゾーンに対応します。
+ 起動テンプレート (`my-launch-template`) とそのバージョン (`$Latest`)。
Amazon EC2 Auto Scaling がオンデマンドキャパシティーを満たそうとするとき、まず `c5.large` インスタンスタイプを起動します。スポットキャパシティについては、Amazon EC2 Auto Scaling は、可能な限り低料金かつ起動するインスタンス数に最適なキャパシティを持つスポットインスタンスを、スポットインスタンスプールから起動しようとします。
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` ファイルには次のコンテンツが含まれます。
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 30,
"SpotAllocationStrategy": "price-capacity-optimized"
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
または、次の [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用して、Auto Scaling グループを作成します。これは、Auto Scaling グループの唯一のパラメータとして YAML ファイルを参照します。
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
`config.yaml` ファイルには次のコンテンツが含まれます。
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandPercentageAboveBaseCapacity: 30
SpotAllocationStrategy: price-capacity-optimized
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
# インスタンスの重みを使用するように Auto Scaling グループを設定する
複数のインスタンスタイプを使用する場合、各インスタンスタイプに関連付けるユニット数を指定し、同じ測定単位を持つグループの容量を指定できます。この容量の仕様オプションは重みと呼ばれます。
たとえば、少なくとも 8 個の vCPU と 15 GiB の RAM で最高のパフォーマンスを発揮する、コンピューティング集約型のアプリケーションを実行するとします。基本単位として `c5.2xlarge` を使用する場合、以下の EC2 インスタンスタイプのいずれかがアプリケーションのニーズを満たします。
**インスタンスタイプの例**
| インスタンスタイプ | vCPU | メモリ (GiB) |
| --- | --- | --- |
| c5.2xlarge | 8 | 16 |
| c5.4xlarge | 16 | 32 |
| c5.12xlarge | 48 | 96 |
| c5.18xlarge | 72 | 144 |
| c5.24xlarge | 96 | 192 |
デフォルトでは、すべてのインスタンスタイプは、サイズにかかわらず同じ重みを持ちます。つまり、Amazon EC2 Auto Scaling が起動するインスタンスタイプの規模の大小にかかわらず、各インスタンスは Auto Scaling グループの希望するキャパシティに対して同じようにカウントされます。
ただし重みでは、各インスタンスタイプに関連付けるユニットを数値で指定します。例えば、インスタンスのサイズが異なる場合、`c5.2xlarge` インスタンスには 2 の重みを付け、`c5.4xlarge` (2 倍大きい) インスタンスには 4 の重みを付けます。その後、Amazon EC2 Auto Scaling がグループをスケールするときに、これらの重みは、各インスタンスが希望するキャパシティとしてカウントするユニット数に変換されます。
重みは、Amazon EC2 Auto Scaling が起動するインスタンスタイプを変更しません。代わりに、割り当て戦略がそれを行います。詳細については、「[複数のインスタンスタイプの配分戦略](allocation-strategies.md)」を参照してください。
**重要**
vCPU の数または各インスタンスタイプのメモリ量を使用して希望するキャパシティを満たすように Auto Scaling グループを設定するには、属性ベースのインスタンスタイプの選択を使用することをお勧めします。`DesiredCapacityType` パラメータを設定すると、このパラメータに設定した値に基づいて、各インスタンスタイプに関連付けるユニット数が自動的に指定されます。詳細については、「[属性ベースのインスタンスタイプの選択を使用して混合インスタンスグループを作成する](create-mixed-instances-group-attribute-based-instance-type-selection.md)」を参照してください。
**Topics**
+ [考慮事項](#weights-considerations)
+ [インスタンスの重みの動作](#instance-weighting-behaviors)
+ [重みを使用するように Auto Scaling グループを設定する](configue-auto-scaling-group-to-use-weights.md)
+ [ユニット時間あたりのスポット料金の例](weights-spot-price-per-unit-hour-example.md)
## 考慮事項
このセクションでは、重みを効果的に実装するための重要な考慮事項について説明します。
+ アプリケーションのパフォーマンスニーズに合ったインスタンスタイプをいくつか選択します。Auto Scaling グループの希望する容量に対して、機能に基づきカウントされる各インスタンスタイプの重みを決定します。これらの重みは、現在および今後のインスタンスに適用されます。
+ 重みの範囲を大きくすることは避けてください。たとえば、インスタンスタイプの重みに 1 を指定し、次に大きいインスタンスタイプの重みに 200 を指定しないでください。最小の重みと最大の重みの差も極端であってはなりません。重みの違いが大きいと、コストパフォーマンスの最適化に悪影響を及ぼす可能性があります。
+ グループの希望する容量をインスタンスではなくユニットで指定します。例えば、vCPU ベースの重みを使用する場合は、希望するコア数に加えて最小値と最大値も設定する必要があります。
+ 重みと希望するキャパシティを設定して、希望するキャパシティが最も大きい重みの少なくとも 2〜3 倍になるようにします。
既存のグループを更新する際には、次の点に注意してください。
+ 既存のグループに重みを追加する際は、現在使用中のすべてのインスタンスタイプの重みを含めます。
+ 重みを追加または変更すると、Amazon EC2 Auto Scaling では新しい重みの値に基づいて希望する容量に達するようにインスタンスを起動または終了します。
+ インスタンスタイプを削除した場合、そのタイプのインスタンスを実行すると、定義されなくなった場合でも最新の重みが維持されます。
## インスタンスの重みの動作
インスタンスの重みを使用すると、Amazon EC2 Auto Scaling は次のように動作します。
+ 現在のキャパシティーは、希望するキャパシティーと同じかそれ以上になります。起動されたインスタンスが残りの希望する容量ユニットを超える場合、現在の容量が希望する容量を超える可能性があります。例えば、2 つのインスタンスタイプ `c5.2xlarge` と `c5.12xlarge` を指定し、`c5.2xlarge` にインスタンスの重み 2 を割り当て、`c5.12xlarge` にインスタンスの重み 12 を割り当てるとします。希望するキャパシティを満たすためのキャパシティが 5 ユニット分残っており、Amazon EC2 Auto Scaling が `c5.12xlarge` をプロビジョニングする場合、希望するキャパシティは 7 ユニット分超過します。
+ インスタンスを起動する際、Amazon EC2 Auto Scaling は、アベイラビリティーゾーン間で容量を分散し、希望する容量を超えて配分戦略を優先します。
+ Amazon EC2 Auto Scaling では、優先される配分戦略を使用してアベイラビリティーゾーン間のバランスを維持するため、最大容量の制限を超えることがあります。Amazon EC2 Auto Scaling によって適用されるハード制限は、希望する容量に最大の重みを加えたものになります。
# 重みを使用するように Auto Scaling グループを設定する
次の AWS CLI の例に示すように、重みを使用するように Auto Scaling グループを設定できます。コンソールを使用する手順については、「[インスタンスタイプを手動で選択して混合インスタンスグループを作成する](create-mixed-instances-group-manual-instance-type-selection.md)」を参照してください。
**重みを使用するように新しい Auto Scaling グループを設定するには (AWS CLI)**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用します。例えば、次のコマンドは新しい Auto Scaling グループを作成し、次を指定して重みを割り当てます。
+ オンデマンドインスタンスとして起動するグループの割合 (`0`)
+ 各アベイラビリティーゾーンのスポットインスタンスの配分戦略 (`capacity-optimized`)
+ 優先度に従って起動するインスタンスタイプ (`m4.16xlarge`、`m5.24xlarge`)
+ インスタンスタイプ間の相対的なサイズの違い (vCPU) に対応するインスタンスの重み (`16`、`24`)
+ インスタンスを起動するサブネット (`subnet-5ea0c127`、`subnet-6194ea3b`、`subnet-c934b782`)。それぞれ異なるアベイラビリティーゾーンに対応
+ 起動テンプレート (`my-launch-template`) とそのバージョン (`$Latest`)
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` ファイルには次のコンテンツが含まれます。
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "m4.16xlarge",
"WeightedCapacity": "16"
},
{
"InstanceType": "m5.24xlarge",
"WeightedCapacity": "24"
}
]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "capacity-optimized"
}
},
"MinSize": 160,
"MaxSize": 720,
"DesiredCapacity": 480,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782",
"Tags": []
}
```
**重みを使用するように既存の Auto Scaling グループを設定するには (AWS CLI)**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) コマンドを使用します。例えば、ここで示すコマンドは、次を指定して既存の Auto Scaling グループのインスタンスタイプに重みを割り当てます。
+ 優先度に従って起動するインスタンスタイプ (`c5.18xlarge`、`c5.24xlarge`、`c5.2xlarge`、`c5.4xlarge`)
+ インスタンスタイプ間の相対的なサイズの違い (vCPU) に対応するインスタンスの重み (`18`、`24`、`2`、`4`)
+ 増やす新しい希望するキャパシティー (最大重みよりも大きい)
```
aws autoscaling update-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` ファイルには次のコンテンツが含まれます。
```
{
"AutoScalingGroupName": "my-existing-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"Overrides": [
{
"InstanceType": "c5.18xlarge",
"WeightedCapacity": "18"
},
{
"InstanceType": "c5.24xlarge",
"WeightedCapacity": "24"
},
{
"InstanceType": "c5.2xlarge",
"WeightedCapacity": "2"
},
{
"InstanceType": "c5.4xlarge",
"WeightedCapacity": "4"
}
]
}
},
"MinSize": 0,
"MaxSize": 100,
"DesiredCapacity": 100
}
```
**コマンドラインを使用して重みを検証するには**
以下のいずれかのコマンドを使用します。
+ [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) (AWS CLI)
+ [Get-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
# ユニット時間あたりのスポット料金の例
次の表では、米国東部 (バージニア北部) の異なるアベイラビリティーゾーンでのスポットインスタンスの時間単位の使用料金と、同じリージョンでのオンデマンドインスタンスの使用料金を比較しています。ここで示している料金は例であり、現在の料金ではありません。これらは*インスタンス時間単位*のコストです。
**例: インスタンス時間単位のスポット料金**
| インスタンスタイプ | us-east-1a | us-east-1b | us-east-1c | オンデマンド料金 |
| --- | --- | --- | --- | --- |
| c5.2xlarge | 0.180 USD | 0.191 USD | 0.170 USD | 0.34 USD |
| c5.4xlarge | 0.341 USD | 0.361 USD | 0.318 USD | 0.68 USD |
| c5.12xlarge | 0.779 USD | 0.777 USD | 0.777 USD | 2.04 USD |
| c5.18xlarge | 1.207 USD | 1.475 USD | 1.357 USD | 3.06 USD |
| c5.24xlarge | 1.555 USD | 1.555 USD | 1.555 USD | 4.08 USD |
インスタンスの重みにより、*ユニット*時間あたりの使用料金に基づいてコストを評価できます。時間単位の使用料金はインスタンスタイプの料金をその単位となる時間数で割って決定できます。オンデマンドインスタンスの場合、時間単位の使用料金は、1 つのインスタンスタイプをデプロイするときと、異なるサイズの同じインスタンスタイプをデプロイするときで同じです。一方、時間単位のスポット料金はスポットプールによって異なります。
次の例は、ユニット時間あたりのスポット料金の計算がインスタンスの重みでどのように機能するかを示しています。計算が容易になるように、スポットインスタンスを `us-east-1a` でのみ起動するとします。ユニット時間あたりの料金を次の表に示します。
**例: ユニット時間あたりのスポット料金**
| インスタンスタイプ | us-east-1a | インスタンスの重み | ユニット時間あたりの価格 |
| --- | --- | --- | --- |
| c5.2xlarge | 0.180 USD | 2 | 0.090 USD |
| c5.4xlarge | 0.341 USD | 4 | 0.085 USD |
| c5.12xlarge | 0.779 USD | 12 | 0.065 USD |
| c5.18xlarge | 1.207 USD | 18 | 0.067 USD |
| c5.24xlarge | 1.555 USD | 24 | 0.065 USD |
# 複数の起動テンプレートを使用する
複数のインスタンスタイプを使用するだけでなく、複数の起動テンプレートを使用することもできます。
例えば、コンピューティング集約型アプリケーション用に Auto Scaling グループを設定し、C5、C5a、C6g のインスタンスタイプを混在させたいとします。ただし、C6g インスタンスは 64 ビット Arm アーキテクチャに基づく AWS Graviton プロセッサを搭載し、C5 および C5a インスタンスは 64 ビット Intel x86 プロセッサで実行されます。C5 インスタンスと C5a インスタンスの AMI はどちらも、これらの各インスタンスで機能しますが、C6g インスタンスでは機能しません。この問題を解決するには、C6g インスタンス用に別の起動テンプレートを使用します。C5 インスタンスと C5a インスタンスには同じ起動テンプレートを引き続き使用できます。
このセクションでは、 を使用して AWS CLI 、複数の起動テンプレートの使用に関連するタスクを実行する手順について説明します。現在、この特徴は AWS CLI または SDK を使用している場合のみ利用可能で、コンソールからは利用できません。
**Topics**
+ [複数の起動テンプレートを使用するように Auto Scaling グループを設定する](#configue-auto-scaling-group-to-use-multiple-launch-templates)
+ [関連リソース](#multiple-launch-templates-related-resources)
## 複数の起動テンプレートを使用するように Auto Scaling グループを設定する
次の例に示すように、複数の起動テンプレートを使用するように Auto Scaling グループを設定できます。
**複数の起動テンプレートを使用するように新しい Auto Scaling グループを設定するには (AWS CLI)**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用します。例えば、次のコマンドは新しい Auto Scaling グループを作成します。これは、`c5.large`、`c5a.large`、および`c6g.large`のインスタンスタイプを指定し、`c6g.large`のインスタンスタイプに新しい起動テンプレートを定義することで、適切な AMI を使用して Arm インスタンスを起動することを保証します。Amazon EC2 Auto Scalingは、インスタンスタイプの順序を使用して、オンデマンドキャパシティーを満たすときに最初に使用するインスタンスタイプを決定します。
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` ファイルには次のコンテンツが含まれます。
```
{
"AutoScalingGroupName":"my-asg",
"MixedInstancesPolicy":{
"LaunchTemplate":{
"LaunchTemplateSpecification":{
"LaunchTemplateName":"my-launch-template-for-x86",
"Version":"$Latest"
},
"Overrides":[
{
"InstanceType":"c6g.large",
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template-for-arm",
"Version": "$Latest"
}
},
{
"InstanceType":"c5.large"
},
{
"InstanceType":"c5a.large"
}
]
},
"InstancesDistribution":{
"OnDemandBaseCapacity": 1,
"OnDemandPercentageAboveBaseCapacity": 50,
"SpotAllocationStrategy": "capacity-optimized"
}
},
"MinSize":1,
"MaxSize":5,
"DesiredCapacity":3,
"VPCZoneIdentifier":"subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782",
"Tags":[ ]
}
```
**複数の起動テンプレートを使用するように既存の Auto Scaling グループを設定するには (AWS CLI)**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) コマンドを使用します。例えば、次のコマンドは、`my-launch-template-for-arm` という名前の起動テンプレートを、*`my-asg`* という名前の Auto Scaling グループの `c6g.large` インスタンスタイプに割り当てます。
```
aws autoscaling update-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` ファイルには次のコンテンツが含まれます。
```
{
"AutoScalingGroupName":"my-asg",
"MixedInstancesPolicy":{
"LaunchTemplate":{
"Overrides":[
{
"InstanceType":"c6g.large",
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template-for-arm",
"Version": "$Latest"
}
},
{
"InstanceType":"c5.large"
},
{
"InstanceType":"c5a.large"
}
]
}
}
}
```
**属性ベースのインスタンスタイプ選択で複数の起動テンプレートを使用するように新しい Auto Scaling グループを設定するには (AWS CLI)**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用します。たとえば、次のコマンドは、ARM AMI を使用する Graviton AWS インスタンス用の起動テンプレートと、x86 AMI を使用する AMD または Intel ベースのインスタンス用の追加の起動テンプレートを指定して、新しい Auto Scaling グループを作成します。次に、[属性ベースのインスタンス選択](create-mixed-instances-group-attribute-based-instance-type-selection.md)を 2 回使用して、各 CPU アーキテクチャの幅広いインスタンスタイプから選択します。[update-autoscaling-grou](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html)p コマンドを使用して、既存の Auto Scaling グループに同様の設定を追加できます。
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` ファイルには次のコンテンツが含まれます。
```
{
"AutoScalingGroupName":"my-asg",
"MixedInstancesPolicy":{
"LaunchTemplate":{
"LaunchTemplateSpecification":{
"LaunchTemplateName":"my-launch-template-for-arm",
"Version":"$Latest"
},
"Overrides":[
{
"InstanceRequirements": {
"VCpuCount": {"Min": 2},
"MemoryMiB": {"Min": 2048},
"CpuManufacturers": ["amazon-web-services"]
}
},
{
"InstanceRequirements": {
"VCpuCount": {"Min": 2},
"MemoryMiB": {"Min": 2048},
"CpuManufacturers": ["intel", "amd"]
},
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template-for-x86",
"Version": "$Latest"
}
}
]
},
"InstancesDistribution":{
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "price-capacity-optimized"
}
},
"MinSize":1,
"MaxSize":10,
"DesiredCapacity":6,
"VPCZoneIdentifier":"subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782",
"Tags":[ ]
}
```
**Auto Scaling グループの起動テンプレートを確認するには**
以下のいずれかのコマンドを使用します。
+ [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) (AWS CLI)
+ [Get-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
## 関連リソース
[AWS re:Post](https://repost.aws/articles/ARQeKDQX68TcqipYaaisl6bA/cloudformation-auto-scaling-group-sample-template-for-mixed-x86-intel-amd-and-aws-graviton-instances) のテンプレートで、属性ベースのインスタンスタイプの選択を使用して複数の起動 CloudFormation テンプレートを指定する例を示します。
# 起動設定を使用して Auto Scaling グループを作成する
**重要**
機能制限:
**2023 年 1 月 1 日**以降、新しい Amazon EC2 インスタンスタイプは起動設定でサポートされなくなります。これには、最初のリージョンの起動 AWS リージョン 後に に追加されたインスタンスタイプのサポートが含まれます。
**2023 年 6 月 1 日**以降に作成されたアカウントは、コンソールを使用して新しい起動設定を作成することはできません。
**2024 年 10 月 1 日以降に作成されたアカウントは、**メソッド (コンソール、API、 AWS CLIまたは CloudFormation) を使用して新しい起動設定を作成することはできません。
起動テンプレートに移行すると、現在または将来的に新しい起動設定を作成する必要がなくなります。Auto Scaling グループを移行してテンプレートを起動する方法については、「[Auto Scaling グループを起動テンプレートに移行する](migrate-to-launch-templates.md)」を参照してください。
起動設定または EC2 インスタンスを作成した場合は、起動設定を EC2 インスタンスの設定テンプレートとして使用する Auto Scaling グループを作成できます。起動設定は、インスタンスの AMI ID、インスタンスタイプ、キーペア、セキュリティグループ、ブロックデバイスマッピングなどの情報を指定します。起動設定の作成については、「[「起動設定を作成する」](create-launch-config.md)」を参照してください。
Auto Scaling グループを作成するための十分な許可が必要です。また、サービスにリンクされたロールが存在しない場合は、Amazon EC2 Auto Scaling がユーザーに代わってアクションを実行するために使用する、サービスにリンクされたロールを作成するための十分な許可も必要です。管理者がアクセス許可を付与するための参照として使用できる IAM ポリシーの例については、[アイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md) を参照してください。
**Topics**
+ [起動設定を使用して Auto Scaling グループを作成する](create-asg-launch-configuration.md)
+ [を使用して既存のインスタンスから Auto Scaling グループを作成する AWS CLI](create-asg-from-instance.md)
# 起動設定を使用して Auto Scaling グループを作成する
**重要**
起動設定に関する情報は、起動設定から起動テンプレートにまだ移行していないお客様向けに提供しています。Auto Scaling グループを移行してテンプレートを起動する方法については、「[Auto Scaling グループを起動テンプレートに移行する](migrate-to-launch-templates.md)」を参照してください。
Auto Scaling グループを作成する際、Amazon EC2 インスタンスを設定するために必要な情報、そのインスタンスのアベイラビリティーゾーンと VPC サブネット、希望するキャパシティー、キャパシティー制限の最小値と最大値を指定する必要があります。
次の手順では、起動設定を使用して Auto Scaling グループを作成する方法を説明します。起動設定は作成後に変更することはできませんが、Auto Scaling グループの起動設定を置き換えることはできます。詳細については、「[Auto Scaling グループの起動設定を変更する](change-launch-config.md)」を参照してください。
**前提条件**
+ 起動設定を作成しておく必要があります。詳細については、「[「起動設定を作成する」](create-launch-config.md)」を参照してください。
**起動設定 (コンソール) を使用して Auto Scaling グループを作成するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. 画面上部のナビゲーションバーで、起動設定の作成時に使用した AWS リージョン ものと同じ を選択します。
1. [**Auto Scaling グループの作成**] を選択します。
1. [**起動テンプレートまたは起動設定を選択する**] ページで [**Auto Scaling グループ名**] にAuto Scaling グループの名前を入力します。
1. 起動設定を選択するには、次の手順を実行します。
1. **[Launch template]** (起動テンプレート) で、**[Switch to launch configuration]** (起動設定に切り替える) を選択します。
1. [**起動設定**] で、既存の起動設定を選択します。
1. 起動設定が、使用する予定のすべてのオプションをサポートしていることを確認し、[**次へ**] を選択します。
1. **[インスタンス起動オプションの設定]** ページの **[ネットワーク]** にある **[VPC]** で、VPC を選択します。Auto Scaling グループは、起動設定で指定したセキュリティグループと、同じ VPC 内に作成する必要があります。
1. **[アベイラビリティーゾーンとサブネット]** で、指定した VPC 内のサブネットを 1 つ以上選択します。複数のアベイラビリティーゾーンのサブネットを使用することで、高可用性を得られます。詳細については、「[VPC サブネットを選択する場合の考慮事項](asg-in-vpc.md#as-vpc-considerations)」を参照してください。
1. **[Next]** (次へ) を選択します。
または、残りはデフォルトのままにして、[**Skip to Review (確認をスキップ)**] を選択できます。
1. (オプション) [**詳細オプションの設定**] ページで、次のオプションを設定し、[**次へ**] を選択します。
1. (オプション) **[ヘルスチェック]** の **[追加のヘルスチェックタイプ]** で、**[Amazon EBS ヘルスチェックをオンにする]** を選択します。詳細については、「[ヘルスチェックを使用して、Amazon EBS ボリュームに障害がある Auto Scaling インスタンスをモニタリングする](monitor-and-replace-instances-with-impaired-ebs-volumes.md)」を参照してください。
1. (オプション) **[ヘルスチェックの猶予期間]** に秒単位で時間を入力します。これは、インスタンスが `InService` 状態になった後で、Amazon EC2 Auto Scaling がインスタンスのヘルスステータスのチェックを待つ必要がある時間です。詳細については、「[Auto Scaling グループにヘルスチェックの猶予期間を設定する](health-check-grace-period.md)」を参照してください。
1. **[Additional settings]** (追加設定)、**[Monitoring]** (モニタリング) で、CloudWatch グループメトリクスの収集を有効にするかどうかを選択します。これらのメトリクスは、終了インスタンス数や保留中のインスタンスの数など、潜在的な問題の指標となる測定値を提供します。詳細については、「[Auto Scaling グループとインスタンスの CloudWatch メトリクスを監視する](ec2-auto-scaling-cloudwatch-monitoring.md)」を参照してください。
1. **[デフォルトのインスタンスのウォームアップを有効にする]** でこのオプションを選択し、アプリケーションのウォームアップ時間を選択します。スケーリングポリシーを持つ Auto Scaling グループを作成している場合は、インスタンスのデフォルトウォームアップ機能によって、動的スケーリングに使用される Amazon CloudWatch メトリクスが改善されます。詳細については、「[Auto Scaling グループに対するインスタンスのデフォルトウォームアップを設定する](ec2-auto-scaling-default-instance-warmup.md)」を参照してください。
1. (オプション) [**Configure group size and scaling policies (グループサイズとスケーリングポリシーの設定)**] ページで、次のオプションを設定し、[**次へ**] を選択します。
1. **[グループサイズ]** の **[希望する容量]** に、起動するインスタンスの初期数を入力します。
1. **[スケーリング]** セクションの **[スケーリング制限]** で、**[希望する容量]** の新しい値が **[最小の希望する容量]** と **[最大の希望する容量]** より大きい場合、**[最大の希望する容量]** は自動的に希望する新しい容量の値に引き上げられます。これらの制限は、必要に応じて変更できます。詳細については、「[Auto Scaling グループのスケーリング制限を設定する](asg-capacity-limits.md)」を参照してください。
1. **[自動スケーリング]** で、ターゲット追跡スケーリングポリシーを作成するかどうかを選択します。このポリシーは、Auto Scaling グループの作成後に作成することもできます。
**[ターゲット追跡スケーリングポリシー]** を選択した場合は、「[ターゲット追跡スケーリングポリシーを作成する](policy_creating.md)」の指示に従ってポリシーを作成してください。
1. **[インスタンスメンテナンスポリシー]** で、インスタンスメンテナンスポリシーを作成するかどうかを選択します。このポリシーは、Auto Scaling グループの作成後に作成することもできます。ポリシーを作成するには、「[インスタンスメンテナンスポリシーを設定する](set-instance-maintenance-policy.md)」の手順を実行してください。
1. [**Instance scale-in protection (インスタンスのスケールイン保護)**] で、インスタンスのスケールイン保護を有効にするかどうかを選択します。詳細については、「[インスタンスのスケールイン保護を使用してインスタンスの終了を制御する](ec2-auto-scaling-instance-protection.md)」を参照してください。
1. (オプション) 通知を受け取るには、[**通知の追加**] を選択し、通知を設定してから [**次へ**] を選択します。詳細については、「[Amazon EC2 Auto Scaling の Amazon SNS 通知オプション](ec2-auto-scaling-sns-notifications.md)」を参照してください。
1. (オプション) タグを追加するには、[**タグの追加**] を選択し、各タグのタグキーと値を指定し、[**次へ**] を選択します。詳細については、「[Auto Scaling グループとインスタンスにタグを付ける](ec2-auto-scaling-tagging.md)」を参照してください。
1. [**Review (レビュー)**]ページで、[**Create Auto Scaling group (Auto Scaling グループを作成)**] を選択します。
**コマンドラインを使用して Auto Scaling グループを作成するには**
以下のコマンドのいずれかを使用できます。
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) (AWS CLI)
+ [New-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
# を使用して既存のインスタンスから Auto Scaling グループを作成する AWS CLI
**重要**
起動設定に関する情報は、起動設定から起動テンプレートにまだ移行していないお客様向けに提供しています。Auto Scaling グループを移行してテンプレートを起動する方法については、「[Auto Scaling グループを起動テンプレートに移行する](migrate-to-launch-templates.md)」を参照してください。
Auto Scaling グループを初めて作成する場合は、コンソールを使用して、既存の EC2 インスタンスから起動テンプレートを作成することをお勧めします。次に、起動テンプレートを使用して新しい Auto Scaling グループを作成します。詳しい手順については、「[Amazon EC2 起動ウィザードを使用して Auto Scaling グループを作成する](create-asg-ec2-wizard.md)」を参照してください。
次の手順は、他のインスタンスを起動するためのベースとして使用する、既存のインスタンスを指定して Auto Scaling グループを作成する方法を示しています。EC2 インスタンスを作成するには、Amazon Machine Image (AMI) ID、インスタンスタイプ、キーペア、セキュリティグループなど、複数のパラメータが必要です。Amazon EC2 Auto Scaling では、スケーリングが必要な場合にユーザーに代わってインスタンスを起動するために、これらの情報もすべて使われます。この情報は、起動テンプレートまたは起動設定のいずれかに保存されます。
既存インスタンスを指定すると、同時に作成された起動設定に基づいて、Amazon EC2 Auto Scaling がインスタンスを起動する Auto Scaling グループを作成します。新しい起動設定には Auto Scaling グループと同じ名前がついていて、インスタンスからの特定の設定についての詳細が含まれます。
次の設定詳細は、特定のインスタンスから起動設定にコピーされます。
+ AMI ID
+ インスタンスタイプ
+ キーペア
+ セキュリティグループ
+ IP アドレスタイプ (パブリックまたはプライベート)
+ IAM インスタンスプロファイル (該当する場合)
+ モニタリング (true または false)
+ EBS 最適化 (true または false)
+ VPC (共有または専用) に起動する場合は、テナンシー設定
+ 該当する場合は、カーネル ID および RAM ディスク ID
+ ユーザーデータ (指定された場合)
+ スポット (最大) 料金
VPC サブネットおよびアベイラビリティーゾーンは、指定のインスタンスから Auto Scaling グループの独自のリソース定義にコピーされます。
特定されたインスタンスがプレイスメントグループ内にある場合、新しい Auto Scaling グループは、特定されたインスタンスと同じプレイスメントグループ内でインスタンスを起動します。起動設定ではプレイスメントグループの指定が許可されないため、プレイスメントグループは新しい Auto Scaling グループの `PlacementGroup` 属性にコピーされます。
次の設定の詳細は、特定のインスタンスからはコピーされません。
+ ストレージ: ブロックデバイス (EBS ボリュームとインスタンスストアボリューム) は、特定のインスタンスからコピーされません。代わりに、AMI 作成の一部として作成されたブロックデバイスマッピングによって、使用されるデバイスが決まります。
+ ネットワークインターフェイスの数: ネットワークインターフェイスは、特定のインスタンスからコピーされません。代わりにデフォルト設定を使用して、Amazon EC2 Auto Scaling が、プライマリネットワークインターフェイス (eth0) であるネットワークインターフェイスを 1 つ作成します。
+ インスタンスメタデータオプション: アクセス可能なメタデータ、メタデータのバージョン、およびトークンレスポンスのホップ制限の設定は、特定のインスタンスからコピーされません。代わりに、Amazon EC2 Auto Scaling はデフォルト設定を使用します。詳細については、「[インスタンスメタデータオプションの設定](create-launch-config.md#launch-configurations-imds)」を参照してください。
+ ロードバランサー: 識別されたインスタンスが 1 つ以上のロードバランサーに登録されている場合、このロードバランサーの情報は新しい Auto Scaling グループのロードバランサーあるいはターゲットグループ属性にコピーされません。
+ タグ: 特定されたインスタンスにタグが指定されている場合、そのタグは新しい Auto Scaling グループの `Tags` 属性にはコピーされません。
## 前提条件
EC2 インスタンスは以下の基準を満たす必要があります。
+ インスタンスは他の Auto Scaling グループのメンバーではありません。
+ インスタンスが `running` 状態であること。
+ インスタンスの起動に使用した AMI は引き続き存在している必要があります。
## EC2 インスタンスを使用して Auto Scaling グループを作成する (AWS CLI)
次の手順は、CLI コマンドを使用して EC2 インスタンスから Auto Scaling グループを作成する方法を示しています。
この手順では、Auto Scaling グループにインスタンスを追加しません。Auto Scaling グループを作成した後、アタッチするインスタンスに [attach-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/attach-instances.html) コマンドを実行する必要があります。
開始する前に、Amazon EC2 コンソールまたは [describe-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instances.html) コマンドを使用して EC2 インスタンスの ID を見つけます。
**現在のインスタンスをテンプレートとして使用するには**
+ 以下の [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用して、EC2 インスタンス`i-123456789abcdefg0`から Auto Scaling グループ、`my-asg-from-instance` を作成します。
```
aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg-from-instance \
--instance-id i-123456789abcdefg0 --min-size 1 --max-size 2 --desired-capacity 2
```
**Auto Scaling グループがインスタンスを起動したことを確認するには**
+ 以下の[describe-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) コマンドを使用して、Auto Scaling グループが正常に作成されたことを確認します。
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg-from-instance
```
次のレスポンスの例は、グループの希望するキャパシティーが 2 であり、グループには実行中のインスタンスが 2 つあり、起動設定の名前が `my-asg-from-instance` であることを示しています。
```
{
"AutoScalingGroups":[
{
"AutoScalingGroupName":"my-asg-from-instance",
"AutoScalingGroupARN":"arn",
"LaunchConfigurationName":"my-asg-from-instance",
"MinSize":1,
"MaxSize":2,
"DesiredCapacity":2,
"DefaultCooldown":300,
"AvailabilityZones":[
"us-west-2a"
],
"LoadBalancerNames":[],
"TargetGroupARNs":[],
"HealthCheckType":"EC2",
"HealthCheckGracePeriod":0,
"Instances":[
{
"InstanceId":"i-34567890abcdef012",
"InstanceType":"t2.micro",
"AvailabilityZone":"us-west-2a",
"LifecycleState":"InService",
"HealthStatus":"Healthy",
"LaunchConfigurationName":"my-asg-from-instance",
"ProtectedFromScaleIn":false
},
{
"InstanceId":"i-012345abcdefg6789",
"InstanceType":"t2.micro",
"AvailabilityZone":"us-west-2a",
"LifecycleState":"InService",
"HealthStatus":"Healthy",
"LaunchConfigurationName":"my-asg-from-instance",
"ProtectedFromScaleIn":false
}
],
"CreatedTime":"2020-10-28T02:39:22.152Z",
"SuspendedProcesses":[ ],
"VPCZoneIdentifier":"subnet-0abc1234",
"EnabledMetrics":[ ],
"Tags":[ ],
"TerminationPolicies":[
"Default"
],
"NewInstancesProtectedFromScaleIn":false,
"ServiceLinkedRoleARN":"arn",
"TrafficSources":[]
}
]
}
```
**起動設定を表示するには**
+ 以下の [describe-launch-configurations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-launch-configurations.html) コマンドを使用して、起動設定の詳細を表示します。
```
aws autoscaling describe-launch-configurations --launch-configuration-names my-asg-from-instance
```
出力例を次に示します。
```
{
"LaunchConfigurations":[
{
"LaunchConfigurationName":"my-asg-from-instance",
"LaunchConfigurationARN":"arn",
"ImageId":"ami-234567890abcdefgh",
"KeyName":"my-key-pair-uswest2",
"SecurityGroups":[
"sg-12abcdefgh3456789"
],
"ClassicLinkVPCSecurityGroups":[ ],
"UserData":"",
"InstanceType":"t2.micro",
"KernelId":"",
"RamdiskId":"",
"BlockDeviceMappings":[ ],
"InstanceMonitoring":{
"Enabled":true
},
"CreatedTime":"2020-10-28T02:39:22.321Z",
"EbsOptimized":false,
"AssociatePublicIpAddress":true
}
]
}
```
**インスタンスを終了するには**
+ 必要がなくなった場合は、インスタンスを終了できます。以下の [terminate-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/terminate-instances.html) コマンドで、インスタンスを終了します`i-123456789abcdefg0`。
```
aws ec2 terminate-instances --instance-ids i-123456789abcdefg0
```
Amazon EC2 インスタンスを削除すると、再起動できなくなります。削除後、ボリュームに含まれるデータは消去され、ボリューム自体はどのインスタンスにもアタッチできなくなります。インスタンスの終了の詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスの終了](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console)」を参照してください。
# インスタンスを同期的に起動する
Amazon EC2 Auto Scaling には、Auto Scaling グループでインスタンスを起動するための 2 つの方法があります。非同期スケーリング動作とLaunchInstances API を使用した同期プロビジョニングです。
同期プロビジョニングでは、LaunchInstances API を使用して、特定のアベイラビリティーゾーン内の特定の数のインスタンスをリクエストします。同期プロビジョニングには、次の利点があります。
+ 特定のアベイラビリティーゾーンでのキャパシティーの可用性に関する即時フィードバック
+ で起動するアベイラビリティーゾーンインスタンスの正確な制御
+ オーケストレーションシステムですぐに使用できる決定的なインスタンス IDs
+ 実際の容量制約に基づくリアルタイムのスケーリングの決定
+ 非同期 Auto Scaling 起動の待機時間を排除してスケーリングを高速化
非同期 Auto Scaling では、希望する容量を変更するか、スケーリングポリシーがトリガーされると、Amazon EC2 Auto Scaling はスケーリングリクエストを処理し、バックグラウンドでインスタンスを起動します。インスタンスが正常に起動されるタイミングを判断するには、スケーリングアクティビティをモニタリングするか、Auto Scaling グループを記述する必要があります。
**注記**
LaunchInstances API は、起動テンプレートを使用する Auto Scaling グループでのみ機能します。起動設定を使用する Auto Scaling グループはサポートされていません。Auto Scaling グループが起動設定を使用している場合は、同期プロビジョニングを使用する前に起動テンプレートに移行する必要があります。
LaunchInstances API は、完全なオンデマンドまたは完全なスポット購入オプションを持つ混合インスタンスポリシーのみをサポートします。オンデマンドインスタンスとスポットインスタンスの両方を組み合わせた混合ポリシーはサポートされていません。
複数のアベイラビリティーゾーンをカバーする Auto Scaling グループの場合は、ターゲットのアベイラビリティーゾーンまたはサブネットを指定する必要があります。シングル AZ グループの場合、このパラメータはオプションです。
## 同期プロビジョニングと非同期スケーリング
### 同期プロビジョニング
LaunchInstances API を使用する場合、Amazon EC2 Auto Scaling は次のようになります。
+ CreateFleet を使用してリクエストされたインスタンスをすぐに起動しようとする
+ CreateFleet が応答する前にインスタンス IDs を返すのを待ちます
+ 成功に関するインスタンス IDs、インスタンスタイプ、およびアベイラビリティーゾーン情報を返します
+ 失敗時の特定のエラーコードと詳細を返します
+ 即時のフィードバックを提供し、リアルタイムのスケーリングの決定を可能にします
### 非同期スケーリング
希望する容量の変更やスケーリングポリシーの使用などの非同期 Auto Scaling メソッドを使用する場合、Amazon EC2 Auto Scaling は次のようになります。
+ API で必要な容量を更新しますが、インスタンスはすぐには返されません
+ アベイラビリティーゾーン間でのインスタンスの起動を自動的に計画します
+ バックグラウンドワークフローを使用してインスタンスを起動します
+ バランスを取るために複数のアベイラビリティーゾーンに容量を自動的に分散します
+ 組み込みの再試行ロジックで起動の失敗を処理します
起動オペレーションのステータスを確認するには、スケーリングアクティビティをポーリングするか、Auto Scaling グループを記述する必要があります。
## 制約事項と考慮事項
同期プロビジョニングを使用する場合は、次の注意事項と制限事項に注意してください。
+ **起動後のインスタンス状態** – API によって返されるインスタンスは保留中状態です。後続のワークフロープロセスまたはライフサイクルフック中に失敗する可能性があります。API レスポンスが成功すると、EC2 は起動リクエストを受け入れ、インスタンス IDs。インスタンスはワークロードに対して完全に準備完了とは見なされず、標準の EC2 および Auto Scaling ライフサイクルプロセスを完了する必要があります。
+ **ウォームプールの制限** — ウォームプールを持つ Auto Scaling グループは、現在サポートされていません。ウォームプールが設定された Auto Scaling グループで LaunchInstances API を呼び出そうとすると、API はウォームプールインスタンスを使用する代わりにコールドスタートを実行し、UnsupportedOperation エラーを返します。コールドスタートの詳細については、[「ウォームプールの制限](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html#warm-pools-limitations)」を参照してください。
+ **API タイムアウトと再試行** — 基盤となる CreateFleet オペレーションに予想以上に時間がかかる場合、API がタイムアウトしてべき等性トークンを返すことがあります。同じ ClientToken を使用して元の起動オペレーションを追跡するか、クライアントトークンで describe-instances を使用して起動されたインスタンスを確認できます。
+ **アベイラビリティーゾーンの制約** – Auto Scaling グループが複数のアベイラビリティーゾーンにまたがり、アベイラビリティーゾーンの再調整が有効になっている場合、インスタンスを同期的に起動すると、運用上の競合が発生する可能性があります。
+ 呼び出しあたりの単一の AZ 制限 – Auto Scaling グループが複数のゾーンにまたがっている場合でも、各 LaunchInstances API 呼び出しは 1 つのアベイラビリティーゾーンのみをターゲットにできます。
+ AZ の再調整の競合 - Auto Scaling グループで AZ の再調整が有効になっている場合、異なる AZs 間でのシーケンシャル呼び出しによって追加の非同期起動がトリガーされ、意図したよりも多くのインスタンスが発生する可能性があります。正確な容量制御のために AZ の再調整を停止することを検討してください。詳細については、「[Amazon EC2 Auto Scaling プロセスの中断と再開](as-suspend-resume-processes.md)」を参照してください。
+ **部分的な成功シナリオ** – リクエストされたキャパシティの一部しか利用できない場合、`LaunchInstances`API は部分的な成功を返すことがあります。これは通常の EC2 動作です。API は、正常に起動されたインスタンスと、起動に失敗したエラーの詳細を返します。すべてのインスタンスを一緒に起動する必要があるユースケース (低レイテンシーで同じ AZ 内のすべてのインスタンスを必要とするアプリケーションなど) では、部分的に起動されたインスタンスを終了し、別の AZ で再試行する必要があります。キャパシティーの影響を受けやすいワークロードの再試行ロジックを設計する場合は、この動作を考慮してください。
+ **インスタンスの重**み – Auto Scaling グループがインスタンスの重みを使用する場合、RequestedCapacity パラメータはインスタンス数ではなく、加重キャパシティーユニットを表します。起動されるインスタンスの実際の数は、選択したインスタンスタイプと設定された重みによって異なります。EC2 Auto Scaling では、リクエストされた加重キャパシティーに関係なく、API コールごとに 100 インスタンスに制限されます。
+ **混合インスタンスタイプ** – LaunchInstances API はAuto Scaling グループの既存の混合インスタンスポリシーを使用して、起動するインスタンスタイプを決定します。API は、グループの配分戦略とインスタンスタイプの優先順位に従ってインスタンスを起動します。
# 同期プロビジョニングを使用したインスタンスの起動
LaunchInstances API を使用して、Auto Scaling グループ内の特定の数のインスタンスを同期的に起動できます。API は、指定したアベイラビリティーゾーンまたはサブネットでインスタンスを起動し、インスタンス IDsまたはエラー情報をすぐに返します。
## 前提条件
LaunchInstances API を使用する前に、以下が必要です。
+ 起動テンプレートを使用する Auto Scaling グループ (起動設定はサポートされていません)
+ 次の IAM アクションのアクセス許可が必要です。
+ `autoscaling:LaunchInstances`
+ `ec2:CreateFleet`
+ `ec2:DescribeLaunchTemplateVersions`
## 同期プロビジョニングを使用してインスタンスを起動する
を通じて同期プロビジョニングを使用してインスタンスを起動できます AWS CLI。
### AWS CLI
同期プロビジョニングを使用してインスタンスを起動するには:
```
aws autoscaling launch-instances \
--auto-scaling-group-name group-name \
--requested-capacity number \
[--availability-zones zone-name] \
[--subnet-ids subnet-id] \
[--availability-zone-ids zone-id] \
[--retry-strategy none|retry-with-group-configuration] \
[--client-token token]
```
#### 例
**特定のアベイラビリティーゾーンでインスタンスを起動する**
```
aws autoscaling launch-instances \
--auto-scaling-group-name my-asg \
--requested-capacity 3 \
--availability-zones us-east-1a \
--retry-strategy retry-with-group-configuration
```
**特定のサブネットでインスタンスを起動する**
```
aws autoscaling launch-instances \
--auto-scaling-group-name my-asg \
--requested-capacity 2 \
--subnet-ids subnet-12345678 \
--retry-strategy none \
--client-token my-unique-token-123
```
#### レスポンスの処理
**成功したレスポンスの例:**
```
{
"AutoScalingGroupName": "my-asg",
"ClientToken": "my-unique-token-123",
"Instances": [
{
"InstanceType": "m5.xlarge",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az1",
"SubnetId": "subnet-12345678",
"MarketType": "OnDemand",
"InstanceIds": ["i-0123456789abcdef0", "i-0fedcba9876543210"]
}
],
"Errors": []
}
```
**エラーのあるレスポンスの例**
```
{
"AutoScalingGroupName": "my-asg",
"ClientToken": "my-unique-token-123",
"Instances": [],
"Errors": [
{
"InstanceType": "m5.large",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az1",
"SubnetId": "subnet-12345678",
"MarketType": "OnDemand",
"ErrorCode": "InsufficientInstanceCapacity",
"ErrorMessage": "There is not enough capacity to fulfill your request for instance type 'm5.large' in 'us-east-1a'"
}
]
}
```
## 起動の失敗と再試行を処理する
LaunchInstances API で障害が発生した場合は、べき等性トークンと適切な再試行ポリシーを使用して再試行戦略を実装できます。
client-token パラメータを使用してリクエストを再試行できます。次の再試行戦略を使用することもできます。
+ `RetryStrategy: none` (デフォルト) - API コールが失敗した場合、Auto Scaling グループの希望する容量は変更されず、自動再試行は行われません。
+ `RetryStrategy: retry-with-group-configuration` - API コールが失敗すると、Auto Scaling グループの希望する容量がリクエストされた量だけ増加し、Auto Scaling はグループの標準設定とプロセスを使用してインスタンスの起動を自動的に再試行します。
の再試行動作`RetryStrategy: retry-with-group-configuration`は、障害タイプによって異なります。
+ **検証エラー**: オペレーションを続行できないため、希望する容量は増加しません。たとえば、無効なパラメータやサポートされていない設定などです。
+ **容量エラー**: 希望する容量が増加し、Auto Scaling はグループの通常のスケーリングプロセスを使用してインスタンスの非同期起動を再試行します。
### 冪等性のためのクライアントトークンの使用
`client-token` パラメータはべき等なオペレーションを保証し、起動リクエストを安全に再試行できるようにします。
主な動作:
+ クライアントトークンの有効期間は、最初のリクエストから 8 時間です。
+ 8 時間以内に同じクライアントトークンで再試行すると、新しいインスタンスを起動する代わりにキャッシュされたレスポンスが返されます。
+ 8 時間後、同じクライアントトークンが新しい起動オペレーションを開始します
# Auto Scaling グループを更新する
Auto Scaling グループの詳細は更新することができます。Auto Scaling グループの名前を更新したり、変更したりすることはできません AWS リージョン。
**Auto Scaling グループ (コンソール) を更新するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。
1. Auto Scaling グループを選択すると、[**詳細**]、[**アクティビティ**]、[**自動スケーリング**]、[**インスタンス管理**]、[**モニタリング**]、[**インスタンス更新**] のタブでグループに関する情報が表示されます。
1. 目的の設定エリアのタブを選択し、必要に応じて設定を更新します。編集する各設定について、[**更新**] を選択して Auto Scaling グループの設定に変更を保存します。
+ [**詳細**] タブ
以下は Auto Scaling グループの一般的な設定です。これらのルールは、Auto Scaling グループの作成時と同じ方法で編集および管理できます。
**詳細設定**セクションには、[[終了ポリシー](ec2-auto-scaling-termination-policies.md)]、[[クールダウン](ec2-auto-scaling-scaling-cooldowns.md)]、[[一時停止プロセス](as-suspend-resume-processes.md)]、[[最大インスタンス有効期間](asg-max-instance-lifetime.md)]など、グループの作成時には使用できないオプションがいくつかあります。Auto Scaling グループのプレイスメントグループと[サービスにリンクされたロール](autoscaling-service-linked-role.md)は表示することはできますが、編集することはできません。
+ **[統合]** タブ
+ **[ロードバランシング]** – [Elastic Load Balancing](autoscaling-load-balancer.md)
グループが Elastic Load Balancing リソースに関連付けられている場合は、アベイラビリティーゾーンを変更する前に [アベイラビリティーゾーンを追加するアベイラビリティーゾーンの削除](as-add-az-console.md) を参照してください。ロードバランサーの制限によっては、グループのアベイラビリティーゾーンへの変更をロードバランサーのアベイラビリティーゾーンに適用できない場合があります。
+ **[VPC Lattice 統合オプション]** – [VPC Lattice](ec2-auto-scaling-vpc-lattice.md)
+ **[ARC ゾーンシフト]** – [Auto Scaling グループのゾーンシフト](ec2-auto-scaling-zonal-shift.md)
+ [**自動スケーリング**] タブ
+ **[動的スケーリングポリシー]** – [動的スケーリングポリシー](as-scale-based-on-demand.md)
+ **[予測スケーリングポリシー]** – [予測スケーリングポリシー](ec2-auto-scaling-predictive-scaling.md)
+ **[スケジュールされたアクション]** – [スケジュールされたアクション](ec2-auto-scaling-scheduled-scaling.md)
+ [**インスタンス管理**] タブ
+ **[ライフサイクルフック]**–— [ライフサイクルフック](lifecycle-hooks.md)
+ **[ウォームプール]** – [ウォームプール](ec2-auto-scaling-warm-pools.md)
+ [**アクティビティ**] タブ
+ **[アクティビティ通知]** – [Amazon SNS 通知](ec2-auto-scaling-sns-notifications.md)
+ [**モニタリング**] タブ
+ このタブには、[CloudWatch グループのメトリックス収集](ec2-auto-scaling-metrics.md)を有効または無効にできるオプションが 1 つしかありません。
**コマンドラインを使用して Auto Scaling グループを更新するには**
以下のコマンドのいずれかを使用できます。
+ [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) (AWS CLI)
+ [Update-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Update-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
## Auto Scaling インスタンスの更新
新しい起動テンプレートまたは起動設定を Auto Scaling グループに関連付けると、すべての新しいインスタンスに更新された設定が適用されます。既存のインスタンスは、最初に起動された構成で実行され続けます。既存のインスタンスに変更を適用するには、次のオプションがあります。
+ 古いインスタンスを置き換えるためにインスタンスの更新を開始します。詳細については、「[インスタンスの更新を使用して Auto Scaling グループのインスタンスを更新する](asg-instance-refresh.md)」を参照してください。
+ スケーリングアクティビティが、[終了ポリシー](as-instance-termination.md)に基づいて古いインスタンスを新しいインスタンスに徐々に置き換えるのを待ちます。
+ 手動で終了させて Auto Scaling グループに置き換えます。
**注記**
以下のインスタンス属性を起動テンプレートまたは起動設定の一部として指定することで変更できます。
[Amazon マシンイメージ (AMI)]
ブロックデバイス
キーペア
インスタンスタイプ
セキュリティグループ
ユーザーデータ
モニタリング
IAM インスタンスプロファイル
プレースメントテナンシー
kernel
ラムディスク
インスタンスにパブリック IP アドレスがあるかどうか
アベイラビリティーゾーンの分散戦略
## Auto Scaling グループ配分戦略と容量の変更
Auto Scaling グループ配分戦略を変更しても、既存のインスタンスは置き換えられません。スケールアウトイベントのために起動された新しいインスタンスが新しい配分戦略に従います。今後のスケールインイベントは[終了ポリシー](ec2-auto-scaling-termination-policies.md)に従い、終了ポリシーが `Default` または `AllocationStrategy` に設定されている場合は新しい配分戦略を使用します。例えば、配分戦略を `lowest-price` から `price-capacity-optimized` に変更した場合、インスタンスの終了は行われませんが、新しいインスタンスは新しい配分戦略で起動されます。インスタンスタイプの変更は既存のインスタンスには影響しません。
[OnDemandBaseCapacity](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstancesDistribution.html) や [OnDemandPercentageAboveBaseCapacity](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstancesDistribution.html) などの特定のパラメータを変更すると、オンデマンドインスタンスとスポットインスタンスの割合が新しい仕様と一致しない場合、Auto Scaling は自動的に再調整を行います。例えば、Auto Scaling グループで `OnDemandPercentageAboveBaseCapacity` が 50% のオンデマンドインスタンスと 50% のスポットインスタンスに設定されているとします。すると、`OnDemandPercentageAboveBaseCapacity` は 100% のオンデマンドインスタンスに引き上げられます。Auto Scaling グループは、新しいオンデマンドインスタンスを起動し、スポットインスタンスを終了することで、プロアクティブに再調整を行います。定義した[インスタンスメンテナンスポリシー](instance-maintenance-policy-overview-and-considerations.md)により、起動アクティビティと終了アクティビティの順序が決まります。
# Auto Scaling グループとインスタンスにタグを付ける
*タグ*は、 AWS リソースに割り当てる、または AWS に割り当てるカスタム属性ラベルです。各 タグは 2 つの部分で構成されます:
+ タグキー (例: `costcenter`、`environment` または `project`)
+ タグ値として知られるオプションのフィールド (例: `111122223333` または `production`)
タグは、以下のことに役立ちます。
+ AWS コストを追跡します。 AWS Billing and Cost Management ダッシュボードでこれらのタグをアクティブ化します。 AWS はタグを使用してコストを分類し、毎月のコスト配分レポートを配信します。詳細については、AWS Billing ユーザーガイド の「[コスト配分タグの使用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)」を参照してください。
+ タグに基づいて、Auto Scaling グループへのアクセスを制御します。IAM ポリシーで条件を使用して、そのグループのタグに基づき、Auto Scaling グループへのアクセスを制御できます。詳しくは、「[セキュリティ用のタグ](tag-security.md)」を参照してください。
+ 追加したタグに基づく Auto Scaling グループのフィルタリングと検索。詳細については、「[タグを使用して Auto Scaling グループをフィルタリングする](use-tag-filters-aws-cli.md)」を参照してください。
+ AWS リソースを特定して整理します。多くの はタグ付け AWS のサービス をサポートしているため、異なるサービスのリソースに同じタグを割り当てて、リソースが関連していることを示すことができます。
新規または既存の Auto Scaling グループにタグを付けることができます。Auto Scaling グループから、起動する EC2 インスタンスにタグを伝播することもできます。
タグは Amazon EBS ボリュームには伝達されません。Amazon EBS ボリュームにタグを追加するには、起動テンプレートでタグを指定します。詳細については、「[Auto Scaling グループの起動テンプレートを作成する](create-launch-template.md)」を参照してください。
タグを作成および管理するには AWS マネジメントコンソール、、 AWS CLI、または SDKsを使用します。
**Topics**
+ [タグの命名と使用制限](#tag_restrictions)
+ [EC2 インスタンスのタグ付けライフサイクル](#tag-lifecycle)
+ [Auto Scaling グループにタグを付ける](add-tags.md)
+ [タグの削除](delete-tag.md)
+ [セキュリティ用のタグ](tag-security.md)
+ [タグへのアクセスを制御する](tag-permissions.md)
+ [タグを使用して Auto Scaling グループをフィルタリングする](use-tag-filters-aws-cli.md)
## タグの命名と使用制限
タグには以下のようなベーシック制限があります。
+ リソースあたりのタグの最大数は 50 です。
+ 単一の呼び出しを使用して追加または削除できるタグの最大数は 25 です。
+ キーの最大長は Unicode 文字で 128 文字です。
+ 値の最大長は Unicode 文字で 256 文字です。
+ タグキーと値は大文字と小文字が区別されます。ベストプラクティスとして、タグを大文字にするための戦略を決定し、その戦略をすべてのリソースタイプにわたって一貫して実装します。
+ タグ名または値に `aws:` プレフィックスを使用しないでください。このプレフィックスは AWS 使用のために予約されています。このプレフィックスが含まれるタグの名前または値は編集または削除できません。これらはリソースクォータあたりのタグに対して計算されません。
## EC2 インスタンスのタグ付けライフサイクル
EC2 インスタンスにタグを伝播することを選択した場合、タグは以下のように管理されます。
+ Auto Scaling グループがインスタンスを起動すると、リソースの作成後ではなく作成中に、インスタンスにタグが追加されます。
+ Auto Scaling グループでは、キーに `aws:autoscaling:groupName`、値に Auto Scaling グループ名が使用され、インスタンスにタグが自動的に追加されます。
+ 起動テンプレートでインスタンスタグを指定し、グループのタグをそのインスタンスに伝播することを選択した場合、すべてのタグがマージされます。起動テンプレートのタグと Auto Scaling グループのタグに同じタグキーが指定されている場合、グループのタグ値が優先されます。
+ 既存のインスタンスをアタッチするときに、Auto Scaling グループはタグをインスタンスに追加し、同じタグキーを持つ既存のタグを上書きします。また、キーが `aws:autoscaling:groupName` で、値が Auto Scaling グループ名のタグも追加されます。
+ Auto Scaling グループからインスタンスからデタッチした場合は、`aws:autoscaling:groupName` タグのみが削除されます。
# Auto Scaling グループにタグを付ける
Auto Scaling グループにタグを追加する際、Auto Scaling グループで起動するインスタンスに追加するかどうかを指定できます。タグを変更する場合は、変更後にその Auto Scaling グループで起動されたインスタンスには更新されたタグのバージョンが追加されます。Auto Scaling グループのタグを作成または変更しても、これらの変更内容は既に Auto Scaling グループで実行中のインスタンスには加えられません。
**Topics**
+ [タグの追加または変更 (コンソール)](#add-tags-console)
+ [タグの追加または変更 (AWS CLI)](#add-tags-aws-cli)
## タグの追加または変更 (コンソール)
**Auto Scaling グループの作成時にタグを付けるには**
Amazon EC2 コンソールを使用して Auto Scaling グループを作成する場合、Auto Scaling グループの作成ウィザードの [**Add Tags (タグの追加)**] ページでタグのキーと値を指定できます。Auto Scaling グループで起動されるインスタンスにタグを付けるには、[**Tag New Instances (新しいインスタンスのタグ付け)**] オプションが選択されたままにしてください。タグを付けない場合は、このオプションの選択を解除できます。
**既存の Auto Scaling グループのタグを追加または変更するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
**[Auto Scaling groups]** (Auto Scaling グループ) ページの下部にスプリットペインが開きます。
1. [**詳細**] タブで、[**タグ**]、[**編集**] の順に選択します。
1. 既存のタグを変更するには、[**Key**] と [**Value**] フィールドを編集します。
1. 新しいタグを追加するには、[**Add tag**] を選択し、[**Key**] と [**Value**] フィールドを選択します。[**Tag New Instances (新しいインスタンスにタグ付けする)**] を選択したままにして Auto Scaling グループで起動されるインスタンスに自動的にタグを追加することも、選択解除して追加しないこともできます。
1. タグの追加を完了したら、[**保存**] を選択します
## タグの追加または変更 (AWS CLI)
次の例は、 を使用して Auto Scaling グループを作成するときにタグ AWS CLI を追加し、既存の Auto Scaling グループのタグを追加または変更する方法を示しています。
**Auto Scaling グループの作成時にタグを付けるには**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) を使用して新しい Auto Scaling グループを作成し、タグを追加します (例: **environment=production** を Auto Scaling グループに追加)。タグは、Auto Scaling グループで起動されるインスタンスにも追加されます。
```
aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg \
--launch-configuration-name my-launch-config --min-size 1 --max-size 3 \
--vpc-zone-identifier "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782" \
--tags Key=environment,Value=production,PropagateAtLaunch=true
```
**既存の Auto Scaling グループのタグを作成または変更するには**
[create-or-update-tags](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-or-update-tags.html) コマンドを使用して、タグを作成または変更します。例えば、以下のコマンドは `Name=my-asg` および `costcenter=cc123` タグを追加します。この変更後、それらのタグは Auto Scaling グループ内で起動されるすべてのインスタンスに追加されます。いずれかのキーを持つタグがすでに存在する場合、既存のタグは置き換えられます。Amazon EC2 コンソールでは、各インスタンスの表示名は、`Name` キーに指定された名前に関連付けられます (大文字と小文字は区別)。
```
aws autoscaling create-or-update-tags \
--tags ResourceId=my-asg,ResourceType=auto-scaling-group,Key=Name,Value=my-asg,PropagateAtLaunch=true \
ResourceId=my-asg,ResourceType=auto-scaling-group,Key=costcenter,Value=cc123,PropagateAtLaunch=true
```
### Auto Scaling グループのタグを記述する (AWS CLI)
特定の Auto Scaling グループに適用されているタグを表示する場合は、次のいずれかのコマンドを使用できます。
+ [describe-tags](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-tags.html) – Auto Scaling グループ名を指定して、指定したグループのタグのリストを表示します。
```
aws autoscaling describe-tags --filters Name=auto-scaling-group,Values=my-asg
```
以下に、応答の例を示します。
```
{
"Tags": [
{
"ResourceType": "auto-scaling-group",
"ResourceId": "my-asg",
"PropagateAtLaunch": true,
"Value": "production",
"Key": "environment"
}
]
}
```
+ [describe-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) – Auto Scaling グループ名を指定して、タグを含む指定したグループの属性を表示します。
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg
```
以下に、応答の例を示します。
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg",
"AutoScalingGroupARN": "arn",
"LaunchTemplate": {
"LaunchTemplateId": "lt-0b97f1e282EXAMPLE",
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 1,
...
"Tags": [
{
"ResourceType": "auto-scaling-group",
"ResourceId": "my-asg",
"PropagateAtLaunch": true,
"Value": "production",
"Key": "environment"
}
],
...
}
]
}
```
# タグの削除
Auto Scaling グループに関連付けられたタグは、いつでも削除できます。
**Topics**
+ [タグの削除 (コンソール)](#delete-tag-console)
+ [タグの削除 (AWS CLI)](#delete-tag-aws-cli)
## タグの削除 (コンソール)
**タグを削除するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. 既存のグループの横にあるチェックボックスをオンにします。
**[Auto Scaling groups]** (Auto Scaling グループ) ページの下部にスプリットペインが開きます。
1. [**詳細**] タブで、[**タグ**]、[**編集**] の順に選択します。
1. タグの横にある [**削除**] を選択します。
1. **[更新]** を選択します。
## タグの削除 (AWS CLI)
[delete-tags](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-tags.html) コマンドを使用してタグを削除します。例えば、以下のコマンドは `environment` キーを持つタグを削除します。
```
aws autoscaling delete-tags --tags "ResourceId=my-asg,ResourceType=auto-scaling-group,Key=environment"
```
タグのキーは指定する必要がありますが、値を指定する必要はありません。指定した値が正しくない場合、タグは削除されません。
# セキュリティ用のタグ
タグを使用してリクエスター (IAM ユーザーまたはロールなど) が特定の Auto Scaling グループを作成、変更、削除する許可を持っていることを確認します。以下の条件キーを 1 つ以上使用して、IAM ポリシーの条件要素にタグ情報を指定します。
+ 特定のタグを持つ Auto Scaling グループに対してユーザーアクションを許可 (または拒否) するには、`autoscaling:ResourceTag/tag-key: tag-value` を使用します。
+ リクエストに特定のタグが含める (または含めない) ことを要求するには、`aws:RequestTag/tag-key: tag-value` を使用します。
+ リクエストに特定のタグキーを含める (または含めない) ことを要求するには、`aws:TagKeys [tag-key, ...]` を使用します。
例えば、以下の例に示すように、キー `environment` および 値 `production` を持つタグを含むすべての Auto Scaling グループへのアクセスを拒否できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"autoscaling:CreateAutoScalingGroup",
"autoscaling:UpdateAutoScalingGroup",
"autoscaling:DeleteAutoScalingGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {"autoscaling:ResourceTag/environment": "production"}
}
}
]
}
```
------
条件キーを使用して Auto Scaling グループへのアクセスを制御する方法の詳細については、「[Amazon EC2 Auto Scaling と IAM の連携](control-access-using-iam.md)」を参照してください。
# タグへのアクセスを制御する
タグを使用してリクエスター (IAM ユーザーまたはロールなど) が Auto Scaling グループのタグを追加、変更、削除する許可を持っていることを確認します。
次の IAM ポリシーの例では、Auto Scaling グループから `temporary` キーを持つタグのみを削除する許可をプリンシパルに与えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "autoscaling:DeleteTags",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": { "aws:TagKeys": ["temporary"] }
}
}
]
}
```
------
Auto Scaling グループに指定されたタグに制約を強制する IAM ポリシーの例については、「[使用できるタグキーとタグ値を制御する](security_iam_id-based-policy-examples.md#policy-example-tags)」を参照してください。
**注記**
ユーザーによる Auto Scaling グループに対するタグ付け (または、タグの削除) 操作の実行を制限するポリシーを持っていても、ユーザーはインスタンスの起動後にタグを手動で変更できます。EC2 インスタンスでタグへのアクセスを制御する例については、「*Amazon EC2 ユーザーガイド*」の「[例: リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-taggingresources)」を参照してください。
# タグを使用して Auto Scaling グループをフィルタリングする
次の例では、[describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) コマンドでフィルターを使用して、Auto Scaling グループを特定のタグで記述する方法を示しています。タグによるフィルタリングは、 AWS CLI または SDK に限定され、コンソールからは使用できません。
**フィルタリングの考慮事項**
+ 1 つのリクエストで複数のフィルターと複数のフィルタの値を指定できます。
+ フィルターの値にワイルドカードを使用することはできません。
+ フィルターの値は大文字と小文字が区別されます。
**例: 特定のタグキーと値のペアを持つ Auto Scaling グループを記述する**
次のコマンドは、**`environment=production`** のタグキーと値のペアを持つ Auto Scaling グループのみを表示するように、結果をフィルタリングする方法を示しています。
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment Name=tag-value,Values=production
```
以下に、応答の例を示します。
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg",
"AutoScalingGroupARN": "arn",
"LaunchTemplate": {
"LaunchTemplateId": "lt-0b97f1e282EXAMPLE",
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 1,
...
"Tags": [
{
"ResourceType": "auto-scaling-group",
"ResourceId": "my-asg",
"PropagateAtLaunch": true,
"Value": "production",
"Key": "environment"
}
],
...
},
... additional groups ...
]
}
```
または `tag:` フィルターを使用して、タグを指定することもできます。例えば、次のコマンドは、**`environment=production`** のタグキーと値のペアを持つ Auto Scaling グループのみを表示するように、結果をフィルタリングする方法を示しています。このフィルターは、次の形式になります: `Name=tag:,Values=` (**** および **** はタグキーと値のペアを表します。)
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag:environment,Values=production
```
`--query` オプションを使用して AWS CLI 出力をフィルタリングすることもできます。次の例は、前のコマンドの AWS CLI 出力をグループ名、最小サイズ、最大サイズ、および希望する容量属性のみに制限する方法を示しています。
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag:environment,Values=production \
--query "AutoScalingGroups[].{AutoScalingGroupName: AutoScalingGroupName, MinSize: MinSize, MaxSize: MaxSize, DesiredCapacity: DesiredCapacity}"
```
以下に、応答の例を示します。
```
[
{
"AutoScalingGroupName": "my-asg",
"MinSize": 0,
"MaxSize": 10,
"DesiredCapacity": 1
},
... additional groups ...
]
```
フィルタリングの詳細については、「 *AWS Command Line Interface ユーザーガイド*[」の AWS CLI 「出力のフィルタリング](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-filter.html)」を参照してください。
**例: 指定したタグキーと一致するタグを持つ Auto Scaling グループを記述する**
次のコマンドは、タグ値に関係なく `environment` タグを持つ Auto Scaling グループのみを表示するように、結果をフィルタリングする方法を示しています。
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment
```
**例: 指定したタグキーのセットに一致するタグを持つ Auto Scaling グループを記述する**
次のコマンドは、タグ値に関係なく `environment` および `project` のタグを持つ Auto Scaling グループのみを表示するように、結果をフィルタリングする方法を示しています。
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment Name=tag-key,Values=project
```
**例: 指定したタグキーのうち少なくとも 1 つに一致するタグを持つ Auto Scaling グループを記述する**
次のコマンドは、タグ値に関係なく `environment` または `project` のタグを持つ Auto Scaling グループのみを表示するように、結果をフィルタリングする方法を示しています。
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment,project
```
**例: 指定したタグ値を持つ Auto Scaling グループを記述する**
次のコマンドは、タグキーに関係なくタグ値 `production` を持つ Auto Scaling グループのみを表示するように、結果をフィルタリングする方法を示しています。
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-value,Values=production
```
**例: 指定したタグ値のセットを持つ Auto Scaling グループを記述する**
次のコマンドは、タグキーに関係なくタグ値 `production` および `development` を持つ Auto Scaling グループのみを表示するように、結果をフィルタリングする方法を示しています。
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-value,Values=production Name=tag-value,Values=development
```
**例: 指定したタグ値の少なくとも 1 つに一致するタグを持つ Auto Scaling グループを記述する**
次のコマンドは、タグキーに関係なくタグ値 `production` または `development` を持つ Auto Scaling グループのみを表示するように、結果をフィルタリングする方法を示しています。
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-value,Values=production,development
```
**例: 複数のタグキーおよびタグ値が一致するタグを持つ Auto Scaling グループを記述する**
フィルターを組み合わせてカスタムの AND および OR ロジックを作成し、より複雑なフィルタリングを実行することもできます。
次のコマンドは、特定のタグのセットを持つ Auto Scaling グループのみを表示するように、結果をフィルタリングする方法を示しています。一方のタグキーは `environment` AND でタグ値は (`production` OR `development`) AND、もう一方のタグキーは `costcenter` AND でタグ値は `cc123` です。
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag:environment,Values=production,development Name=tag:costcenter,Values=cc123
```
# インスタンスメンテナンスポリシー
インスタンスの更新やヘルスチェックプロセスなどのインスタンスの置き換えが発生するイベント時に、特定のキャパシティ要件を満たすように、Auto Scaling グループのインスタンスメンテナンスポリシーを設定できます。
例えば、少数のインスタンスを含む Auto Scaling グループがあるとします。ヘルスチェックで障害のあるインスタンスが検出された際、インスタンスを終了して置き換えることによって発生する可能性のあるサービスの中断を避けたいと考えています。インスタンスメンテナンスポリシーを使用すると、Amazon EC2 Auto Scaling が最初に新しいインスタンスを起動し、それが完全に準備できるのを待ってから、異常なインスタンスを終了するようにすることができます。
また、インスタンスメンテナンスポリシーは、複数のインスタンスが同時に置き換えられた場合に発生する可能性のある中断を最小限に抑えるのにも役立ちます。ポリシーの最小正常率と最大正常率のパラメータを設定すると、Auto Scaling グループはインスタンスを置き換えるときに、最小値と最大値の範囲内でしかキャパシティを増減できません。範囲を大きくすると、同時に置き換えることができるインスタンスの数が増えます。
**Topics**
+ [Auto Scaling グループのインスタンスメンテナンスポリシー](instance-maintenance-policy-overview-and-considerations.md)
+ [Auto Scaling グループにインスタンスメンテナンスポリシーを設定する](set-instance-maintenance-policy-on-group.md)
# Auto Scaling グループのインスタンスメンテナンスポリシー
このトピックでは、使用可能なオプションの概要と、インスタンスメンテナンスポリシーの作成時に考慮すべき点を説明します。
**Topics**
+ [概要:](#instance-maintenance-policy-overview)
+ [重要な概念](#instance-maintenance-policy-core-concepts)
+ [インスタンスのウォームアップ](#instance-maintenance-policy-instance-warm-up)
+ [ヘルスチェックの猶予期間](#instance-maintenance-policy-health-check-grace-period)
+ [Auto Scaling グループをスケールする](#instance-maintenance-policy-scaling-limits)
+ [シナリオ例](#instance-maintenance-policy-scenarios)
## 概要:
Auto Scaling グループのインスタンスメンテナンスポリシーを作成すると、そのポリシーはインスタンスの置き換えを引き起こす Amazon EC2 Auto Scaling イベントに影響を与えます。これにより、同じ Auto Scaling グループ内でより一貫した置き換え動作が得られます。また、必要に応じて、可用性やコストに合わせてグループを最適化することもできます。
コンソールでは、次の設定オプションを使用できます。
+ **終了前の起動** — 既存のインスタンスを終了する前に、新しいインスタンスをプロビジョニングする必要があります。このアプローチは、コスト削減よりも可用性を重視するアプリケーションに適しています。
+ **終了と起動** — 新しいインスタンスは、既存のインスタンスが終了すると同時にプロビジョニングされます。このアプローチは、可用性よりもコスト削減を優先するアプリケーションに適しています。また、インスタンスを置き換える場合でも、現在利用可能な容量を超える容量を起動する必要がないアプリケーションにも適しています。
+ **カスタムポリシー** — このオプションを使用すると、インスタンスを置き換えするときに必要なキャパシティの最小値と最大値の範囲をカスタムで指定して、ポリシーを設定できます。このアプローチは、コストと可用性の最適なバランスを重視する場合に効果的です。
Auto Scaling グループはデフォルトでインスタンスメンテナンスポリシーが設定されていないため、インスタンスのメンテナンスイベントが発生した場合、デフォルトの動作に従って処理されます。デフォルトの動作については、次の表で説明します。
**インスタンスメンテナンスイベントのデフォルトの動作**
| [Event] (イベント) | 説明 | デフォルトの 動作 |
| --- | --- | --- |
| ヘルスチェックの失敗 | インスタンスがヘルスチェックに失敗すると自動的に発生します。Amazon EC2 Auto Scaling は、ヘルスチェックに失敗したインスタンスを置き換えます。ヘルスチェックの失敗の原因については、「[Auto Scaling グループでのインスタンスのヘルスチェック](ec2-auto-scaling-health-checks.md)」を参照してください。 | 終了と起動。 |
| インスタンスの更新 | インスタンスの更新を開始すると実行されます。インスタンスの更新では、設定に応じてインスタンスを 1 つずつ、複数ずつ、またはすべてを一度に置き換えられます。詳細については、「[インスタンスの更新を使用して Auto Scaling グループのインスタンスを更新する](asg-instance-refresh.md)」を参照してください。 | 終了と起動。 |
| 最大インスタンス有効期間 | インスタンスが Auto Scaling グループに指定したインスタンスの最大有効期間に達すると、自動的に実行されます。Amazon EC2 Auto Scaling は、インスタンスの最大有効期間に達したインスタンスを置き換えます。詳細については、「[インスタンスの最大存続期間に基づいて Auto Scaling インスタンスを置き換える](asg-max-instance-lifetime.md)」を参照してください。 | 終了と起動。 |
| リバランシング | グループのバランスが崩れるような根本的な変更があった場合に自動的に実行されます。Amazon EC2 Auto Scaling は、次の状況でグループのバランスを再調整します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/instance-maintenance-policy-overview-and-considerations.html) | 終了前の起動。 Amazon EC2 Auto Scaling は、*最大キャパシティ*の 10% を超えて、グループのサイズを増やすことができます。ただし、キャパシティの再調整を使用している場合、これらの制限を超えることができるのは、*希望するキャパシティ*の最大 10% のみです。 |
Amazon EC2 Auto Scaling は、以下の状況では引き続きデフォルトで終了および起動されます。したがって、これらの状況のいずれかが発生すると、グループのキャパシティがインスタンスメンテナンスポリシーの下限しきい値を下回る可能性があります。
+ 例えば、人為的な操作などにより、インスタンスが予期せず終了した場合。Amazon EC2 Auto Scaling は、実行されなくなったインスタンスを直ちに置き換えます。詳細については、「[Amazon EC2 ヘルスチェック](health-checks-overview.md#instance-health-detection)」を参照してください。
+ Amazon EC2 Auto Scaling が代替インスタンスを起動する前に、Amazon EC2 がスケジュールされたイベントの一環としてインスタンスを再起動、停止、またはリタイアした場合。予これらのイベントの詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスの予定されたイベント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html)」を参照してください。
+ Amazon EC2 スポットサービスがスポットインスタンスの中断を開始し、スポットインスタンスが強制的に終了した場合。
スポットインスタンスでは、Auto Scaling グループでキャパシティの再調整を有効にした場合、インスタンスに、スポット中断を開始する前に起動した別のスポットプールからの保留中のインスタンスが既にある可能性があります。キャパシティの再調整の仕組みの詳細については、「[リスクがあるスポットインスタンスを置き換えるための Auto Scaling でのキャパシティの再調整](ec2-auto-scaling-capacity-rebalancing.md)」を参照してください。
ただし、スポットインスタンスは常に利用できるとは限らず、2 分前に通知されて停止される可能性があるため、新しいインスタンスの起動前にインスタンスが中断された場合、インスタンスメンテナンスポリシーの下限しきい値を超える可能性があります。
## 重要な概念
開始する前に、以下の主要概念と用語を理解してください。
**希望するキャパシティ**
*希望するキャパシティ*は、Auto Scaling グループの作成時のキャパシティを表します。また、グループにスケーリング条件がアタッチされていない場合に、グループが維持しようとするキャパシティでもあります。
**インスタンスメンテナンスポリシー**
*インスタンスメンテナンスポリシー*は、インスタンスのメンテナンスイベントが発生した場合に、既存のインスタンスが終了する前に新しいインスタンスがプロビジョニングされるかどうかを制御します。また、Auto Scaling グループが同時に複数のインスタンスを置き換えるために希望するキャパシティをどの程度下回り、超えるかも決まります。
**最大正常率**
*最大正常率*は、インスタンスを置き換えるときに Auto Scaling グループが増やすことができる、希望するキャパシティの割合です。これは、ワークロードをサポートするために、稼働中で正常な状態、または保留中のインスタンスが、グループ内で占める割合の最大値を表します。コンソールでは、**終了前の起動**オプションまたは **カスタムポリシー**オプションのいずれかを使用すると、最大正常率を設定できます。有効な値は 100～200% です。
**最小正常率**
*最小正常率*とは、インスタンスを置き換えるときにワークロードをサポートするため、稼働状態を維持し、正常な状態を保ち、すぐに使用できるようにしておくのに必要なキャパシティの割合です。インスタンスは、最初のヘルスチェックが正常に完了し、指定されたウォームアップ時間が経過すると、正常と見なされ、すぐに使用できます。コンソールで、**終了と起動**オプションまたは**カスタムポリシー**オプションのいずれかを使用すると、最小正常率を設定できます。有効な値は 0～100% です。
インスタンスをより速く置き換えるには、最小正常率を低く設定します。ただし、正常なインスタンスが十分にない場合、可用性が低下する可能性があります。複数のインスタンスが置き換えられる状況で可用性を維持するために、適切な値を選択することをお勧めします。
## インスタンスのウォームアップ
インスタンスが `InService` 状態になった後に初期化する時間が必要な場合は、Auto Scaling グループのデフォルトのインスタンスウォームアップを有効にします。デフォルトのインスタンスウォームアップ機能を使うと、インスタンスの準備が整う前に、インスタンスを最小正常率の計算から除外できます。これにより、Amazon EC2 Auto Scaling は、既存のインスタンスを停止する前に、ワークロードに対応するために十分なキャパシティを確保するのにかかる時間を考慮するようになります。
デフォルトのインスタンスウォームアップ機能を有効にすることで、動的スケーリングに利用される Amazon CloudWatch メトリクスの精度が向上し、より正確なスケーリングが可能になります。Auto Scaling グループにスケーリングポリシーが設定されている場合、グループがスケールアウトするとき、インスタンスが初期化を完了する前に CloudWatch メトリクスにカウントされないように、同じデフォルトのウォームアップ期間が使用されます。
詳細については、「[Auto Scaling グループに対するインスタンスのデフォルトウォームアップを設定する](ec2-auto-scaling-default-instance-warmup.md)」を参照してください。
## ヘルスチェックの猶予期間
Amazon EC2 Auto Scaling は、Auto Scaling グループが使用するヘルスチェックのステータスに基づいてインスタンスが正常かどうかを判断します。詳細については、「[Auto Scaling グループでのインスタンスのヘルスチェック](ec2-auto-scaling-health-checks.md)」を参照してください。
これらのヘルスチェックをできるだけ早く開始するには、グループのヘルスチェック猶予期間をあまり長く設定しないでください。ただし、Elastic Load Balancing ヘルスチェックがターゲットがリクエストを処理できるかどうかを判断するのに十分な長さに設定します。詳細については、「[Auto Scaling グループにヘルスチェックの猶予期間を設定する](health-check-grace-period.md)」を参照してください。
## Auto Scaling グループをスケールする
インスタンスメンテナンスポリシーは、インスタンスメンテナンスイベントにのみ適用されます。グループが手動または自動でスケーリングされるのを防ぐことはできません。
Auto Scaling グループにスケーリングポリシーまたはスケジュールされたアクションがアタッチされている場合、インスタンスメンテナンスイベントの発生中に並行して実行されることがあります。この場合、グループの希望するキャパシティが増減する可能性がありますが、定義したスケーリング制限内に限られます。これらの制限の詳細については、「[Auto Scaling グループのスケーリング制限を設定する](asg-capacity-limits.md)」を参照してください。
## シナリオ例
一般的なシナリオでは、インスタンスのメンテナンスポリシーと希望するキャパシティは次のようになります。
+ 最小正常率 = 90%
+ 最大正常率 = 120%
+ 希望するキャパシティ ＝ 100
インスタンスのメンテナンスイベント実行中は、Auto Scaling グループのインスタンス数が 90～120 の間で変動することがあります。イベント後、グループはインスタンス数を 100 に戻します。
ウォームプールを持つ Auto Scaling グループでインスタンスメンテナンスポリシーを使用する場合、正常率の最小値と最大値は Auto Scaling グループとウォームプールに個別に適用されます。
例えば、これが設定であるとします。
+ 最小正常率 = 90%
+ 最大正常率 = 120%
+ 希望するキャパシティ ＝ 100
+ ウォームプールサイズ = 10
インスタンスの更新を開始してグループのインスタンスをリサイクルする場合、Amazon EC2 Auto Scaling は最初に Auto Scaling グループのインスタンスを置き換え、次にウォームプール内のインスタンスを置き換えます。Amazon EC2 Auto Scaling が Auto Scaling グループ内のインスタンスの置き換えの処理を行っている間、グループ内のインスタンス数は 90 から 120 の間で変動する可能性があります。グループでの置換が完了すると、Amazon EC2 Auto Scaling はウォームプール内のインスタンスの置き換えを開始します。これが発生している間、ウォームプールのインスタンス数が 9～12 個になる可能性があります。
# Auto Scaling グループにインスタンスメンテナンスポリシーを設定する
Auto Scaling グループを作成する際、インスタンスメンテナンスポリシーを作成できます。既存のグループに対して作成することもできます。
Auto Scaling グループにインスタンスメンテナンスポリシーを設定することで、インスタンスメンテナンスポリシーを上書きしない限り、インスタンス更新機能の最小正常率および最大正常率のパラメータ値を指定する必要がなくなります。
コンソールでは、Amazon EC2 Auto Scaling の開始に役立つオプションが用意されています。
**Topics**
+ [インスタンスメンテナンスポリシーを設定する](set-instance-maintenance-policy.md)
+ [インスタンスメンテナンスポリシーを削除する](remove-instance-maintenance-policy.md)
# インスタンスメンテナンスポリシーを設定する
Auto Scaling グループにインスタンスメンテナンスポリシーを設定するには、次のいずれかの方法で行います。
------
#### [ Console ]
**新しいグループにインスタンスメンテナンスポリシーを設定するには (コンソール）**
1. [起動テンプレートを使用して Auto Scaling グループを作成する](create-asg-launch-template.md) の指示に従い、ステップ 11 までの手順の各ステップを完了します。
1. **[グループサイズとスケーリングポリシーを設定]** ページの **[希望するキャパシティ]** に、起動するインスタンスの初期数を入力します。
1. **[スケーリング]** セクションの **[スケーリング制限]** で、**[希望する容量]** の新しい値が **[最小の希望する容量]** と **[最大の希望する容量]** より大きい場合、**[最大の希望する容量]** は自動的に希望する新しい容量の値に引き上げられます。これらの制限は、必要に応じて変更できます。
1. **[自動スケーリング]** で、ターゲット追跡スケーリングポリシーを作成するかどうかを選択します。このポリシーは、Auto Scaling グループの作成後に作成することもできます。
**[ターゲット追跡スケーリングポリシー]** を選択した場合は、「[ターゲット追跡スケーリングポリシーを作成する](policy_creating.md)」の指示に従ってポリシーを作成してください。
1. **インスタンスメンテナンスポリシー**セクションで、使用可能なオプションのいずれかを選択します。
+ **終了前の起動**: 既存のインスタンスを終了する前に、新しいインスタンスをプロビジョニングする必要があります。これは、コスト削減よりも可用性を重視するアプリケーションに適しています。
+ **終了と起動**: 新しいインスタンスは、既存のインスタンスが終了すると同時にプロビジョニングされます。これは、可用性よりもコスト削減を優先するアプリケーションに適しています。これは、現在利用可能なキャパシティを超えて処理能力を増やす必要のないアプリケーションにも適しています。
+ **カスタムポリシー **: このオプションを使用すると、インスタンスを置き換えするときに必要なキャパシティの最小値と最大値のカスタム範囲を指定してポリシーを設定できます。これにより、コストと可用性の適切なバランスを実現できます。
1. **[正常率を設定]**には、次のフィールドの 1 つまたは両方に値を入力します。有効なフィールドは、前のステップで選択したオプションによって異なります。
+ **最小 **: インスタンスの置き換えを続行するために必要な最小正常率を設定します。
+ **最大 **: インスタンスを置き換えを実行できる最大正常率を設定します。
1. **[希望するキャパシティーセクションに基づいて置き換え中にキャパシティーを表示]** セクションを展開し、**最小**と**最大**の値がグループにどのように適用されるかを確認します。使用される正確な値は、希望するキャパシティ値によって異なります。これは、グループがスケールすると変化します。
1. [起動テンプレートを使用して Auto Scaling グループを作成する](create-asg-launch-template.md) のステップを続行します。
------
#### [ AWS CLI ]
**新しいグループにインスタンスメンテナンスポリシーを設定するには (AWS CLI）**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドに `--instance-maintenance-policy` オプションを追加します。次の例では、`my-asg` という名前の新しい Auto Scaling グループにインスタンスメンテナンスポリシーを設定します。
```
aws autoscaling create-auto-scaling-group \
--launch-template LaunchTemplateName=my-launch-template,Version='1' \
--auto-scaling-group-name my-asg \
--min-size 1 \
--max-size 10 \
--desired-capacity 5 \
--default-instance-warmup 20 \
--instance-maintenance-policy '{
"MinHealthyPercentage": 90,
"MaxHealthyPercentage": 120
}' \
--vpc-zone-identifier "subnet-5e6example,subnet-613example,subnet-c93example"
```
------
------
#### [ Console ]
**既存のグループにインスタンスメンテナンスポリシーを設定するには (コンソール）**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。
1. 画面の上部のナビゲーションバーで、Auto Scaling グループを作した AWS リージョン を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
ページの下部にスプリットペインが開きます。
1. **[詳細]** タブで、**[インスタンスメンテナンスポリシー] **、**[編集]** の順に選択します。
1. グループにインスタンスメンテナンスポリシーを設定するには、使用可能なオプションのいずれかを選択します。
+ **終了前の起動**: 既存のインスタンスを終了する前に、新しいインスタンスをプロビジョニングする必要があります。これは、コスト削減よりも可用性を重視するアプリケーションに適しています。
+ **終了と起動**: 新しいインスタンスは、既存のインスタンスが終了すると同時にプロビジョニングされます。これは、可用性よりもコスト削減を優先するアプリケーションに適しています。これは、現在利用可能なキャパシティを超えて処理能力を増やす必要のないアプリケーションにも適しています。
+ **カスタムポリシー **: このオプションを使用すると、インスタンスを置き換えするときに必要なキャパシティの最小値と最大値のカスタム範囲を指定してポリシーを設定できます。これにより、コストと可用性の適切なバランスを実現できます。
1. **[正常率を設定]**には、次のフィールドの 1 つまたは両方に値を入力します。有効なフィールドは、前のステップで選択したオプションによって異なります。
+ **最小 **: インスタンスの置き換えを続行するために必要な最小正常率を設定します。
+ **最大 **: インスタンスを置き換えを実行できる最大正常率を設定します。
1. **[希望するキャパシティーセクションに基づいて置き換え中にキャパシティーを表示]** セクションを展開し、**最小**と**最大**の値がグループにどのように適用されるかを確認します。使用される正確な値は、希望するキャパシティ値によって異なります。これは、グループがスケールすると変化します。
1. **[更新]** を選択します。
------
#### [ AWS CLI ]
**既存のグループにインスタンスメンテナンスポリシーを設定するには (AWS CLI）**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) コマンドに `--instance-maintenance-policy` オプションを追加します。次の例では、指定された Auto Scaling グループにインスタンスメンテナンスポリシーを設定します。
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \
--instance-maintenance-policy '{
"MinHealthyPercentage": 90,
"MaxHealthyPercentage": 120
}'
```
------
# インスタンスメンテナンスポリシーを削除する
Auto Scaling グループでインスタンスメンテナンスポリシーの使用を停止する場合は、削除できます。
------
#### [ Console ]
**インスタンスメンテナンスポリシーを削除するには (コンソール）**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。
1. 画面の上部のナビゲーションバーで、Auto Scaling グループを作した AWS リージョン を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
ページの下部にスプリットペインが開きます。
1. **[詳細]** タブで、**[インスタンスメンテナンスポリシー] **、**[編集]** の順に選択します。
1. **インスタンスメンテナンスポリシーなし **を選択します。
1. **[更新]** を選択します。
------
#### [ AWS CLI ]
**インスタンスメンテナンスポリシーを削除するには (AWS CLI）**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) コマンドに `--instance-maintenance-policy` オプションを追加します。以下は、指定された Auto Scaling グループからインスタンスメンテナンスポリシーを削除する例を示しています。
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \
--instance-maintenance-policy '{
"MinHealthyPercentage": -1,
"MaxHealthyPercentage": -1
}'
```
------
# Amazon EC2 Auto Scaling のライフサイクルフック
Amazon EC2 Auto Scaling は、Auto Scaling グループにライフサイクルフックを追加する機能を提供します。これらのフックにより、Auto Scaling インスタンスライフサイクルのイベントを認識し、対応するライフサイクルイベントが発生したときにカスタムアクションを実行するソリューションを作成できます。ライフサイクルフックでは、インスタンスが次の状態に移行する前に、ライフサイクルアクションの完了を待つ時間 (デフォルトでは 1 時間) が指定されます。
Auto Scaling インスタンスでライフサイクルフックを使用する例として、以下を実行します。
+ スケールアウト イベントが発生すると、新しく起動したインスタンスはスタートアップ シーケンスを完了し、待機状態に移行します。インスタンスが待機状態の間に、アプリケーションに必要なソフトウェアパッケージをダウンロードしてインストールするスクリプトを実行して、トラフィックの受信をスタートする前に、インスタンスの準備がすべて完了していることを確認できます。スクリプトがソフトウェアのインストールを終了すると、**complete-lifecycle-action**コマンドを実行して続行します。
+ スケールイン イベントが発生すると、ライフサイクルフックによってインスタンスが終了される前に一時停止され、Amazon EventBridge を使用して通知が送信されます。インスタンスが待機状態にある間は、 AWS Lambda 関数を呼び出したり、インスタンスに接続して、インスタンスが完全に終了する前にログやその他のデータをダウンロードしたりできます。
ライフサイクルフックの一般的な使用方法は、インスタンスが Elastic Load Balancing に登録されるタイミングを制御することです。Auto Scaling グループに起動ライフサイクルフックを追加すると、ライフサイクルフックの最後にロードバランサーに登録される前に、ブートストラップスクリプトが正常に完了していて、インスタンス上のアプリケーションがトラフィックを受け入れる準備ができていることを確認できます。
**Topics**
+ [ライフサイクルフックの可用性](#lifecycle-hooks-availability)
+ [考慮事項と制限事項](#lifecycle-hook-considerations)
+ [関連リソース](#lifecycle-hook-related-resources)
+ [Auto Scaling グループでのライフサイクルフックの仕組み](lifecycle-hooks-overview.md)
+ [ライフサイクルフックを追加するための準備](prepare-for-lifecycle-notifications.md)
+ [インスタンスライフサイクルポリシーを使用してインスタンスの保持を制御する](instance-lifecycle-policy.md)
+ [ターゲットライフサイクル状態を取得する](retrieving-target-lifecycle-state-through-imds.md)
+ [Auto Scaling グループにライフサイクル フックを追加する](adding-lifecycle-hooks.md)
+ [Auto Scaling グループでライフサイクルアクションを完了する](completing-lifecycle-hooks.md)
+ [チュートリアル: インスタンスメタデータを使用してライフサイクル状態を取得する](tutorial-lifecycle-hook-instance-metadata.md)
+ [チュートリアル:Lambda 関数を呼び出すライフサイクルフックの設定](tutorial-lifecycle-hook-lambda.md)
## ライフサイクルフックの可用性
次の表は、さまざまなシナリオで利用できるライフサイクルフックを示しています。
| イベント | インスタンスの起動または終了¹ | [インスタンスの最大存続期間](asg-max-instance-lifetime.md): 置き換えインスタンス | [インスタンスの更新](asg-instance-refresh.md): 置き換えインスタンス | [キャパシティの再調整](ec2-auto-scaling-capacity-rebalancing.md): 置き換えインスタンス | [ウォームプール](ec2-auto-scaling-warm-pools.md): ウォームプールに出入りするインスタンス |
| --- | --- | --- | --- | --- | --- |
| インスタンスの起動 | ✓ | ✓ | ✓ | ✓ | ✓ |
| インスタンスの削除 | ✓ | ✓ | ✓ | ✓ | ✓ |
¹ 自動的に開始されたか、または手動で開始されたかにかかわらず (`SetDesiredCapacity` もしくは `TerminateInstanceInAutoScalingGroup` オペレーションを呼び出す場合など)、すべての起動と終了に適用されます。インスタンスのアタッチまたはデタッチ、インスタンスのスタンバイモードへの切り替え、または強制削除オプションを使用したグループの削除には適用されません。
## ライフサイクルフックの考慮事項と制限
ライフサイクルフックを使用する場合は、以下の注意事項と制限事項に留意してください。
+ Amazon EC2 Auto Scaling は、Auto Scaling グループの管理に役立つ独自のライフサイクルを提供します。このライフサイクルは、他の EC2 インスタンスのライフサイクルとは異なります。詳細については、「[Amazon EC2 Auto Scaling インスタンスのライフサイクル](ec2-auto-scaling-lifecycle.md)」を参照してください。ウォームプール内のインスタンスには、[ウォームプール内のインスタンスのライフサイクル状態の移行](warm-pool-instance-lifecycle.md#lifecycle-state-transitions) で説明されている独自のライフサイクルもあります。
+ デフォルトでは、終了ライフサイクルフックはベストエフォートベースで動作します。終了ライフサイクルフックがタイムアウトまたは中止された場合、Amazon EC2 Auto Scaling はインスタンスの即時終了に進みます。終了ライフサイクルフックをインスタンス保持のインスタンスライフサイクルポリシーと組み合わせることができます。詳細については、「[インスタンスライフサイクルポリシーを使用してインスタンスの保持を制御する](instance-lifecycle-policy.md)」を参照してください。
+ スポットインスタンスによりライフサイクルフックを使用できますが、使用可能なキャパシティがなくなった場合、ライフサイクルフックはインスタンスの終了を防ぐことができません。これは、2 分間の中断通知により、いつでも起こり得ます。詳細については、『*Amazon EC2 ユーザーガイド*』の「[スポットインスタンス中断](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html)」を参照してください。ただし、キャパシティの再調整を有効にして、Amazon EC2 スポットサービスから再調整のレコメンデーションを受け取ったスポットインスタンスを積極的に置換することができます。これは、スポットインスタンスの中断リスクが高まったときに送信される信号です。詳細については、「[リスクがあるスポットインスタンスを置き換えるための Auto Scaling でのキャパシティの再調整](ec2-auto-scaling-capacity-rebalancing.md)」を参照してください。
+ インスタンスは一定期間、待機状態に維持できます。ライフサイクルフックのデフォルトタイムアウトは 1 時間です (ハートビートタイムアウト)。インスタンスを待機状態に保つことができる最大時間を指定するグローバルタイムアウトもあります。グローバルタイムアウトは、48 時間か、ハートビートタイムアウトの 100 倍の時間のどちらか短い方になります。
+ ライフサイクルフックの結果は、中止または続行のどちらかになります。インスタンスが起動中の場合、「続行」はアクションが正常に実行され、Amazon EC2 Auto Scaling がインスタンスをサービス開始できることを示します。それ以外の場合、中止はカスタムアクションが失敗し、インスタンスを終了して置き換えることができることを示します。インスタンスが終了する場合、「中止」と「続行」の両方でインスタンスを終了できます。ただし、「中止」は他のライフサイクルフックなど残りのアクションをすべて停止し、「続行」は他のライフサイクルフックを完了することを許可します。
+ ライフサイクルフックが繰り返し失敗する場合、Amazon EC2 Auto Scaling はインスタンスの起動を許可する頻度を制限するので、ライフサイクルアクションをテストして永続的なエラーを修正するようにしてください。
+ AWS CLI、、または SDK を使用してライフサイクルフックを作成および更新すると CloudFormation、 からライフサイクルフックを作成するときに使用できないオプションが提供されます AWS マネジメントコンソール。例えば、コンソールには SNS トピックや SQS キューの ARN を指定するフィールドが表示されません。これは、Amazon EC2 Auto Scaling がすでに Amazon EventBridge にイベントを送信しているからです。これらのイベントはフィルタリングされ、必要に応じて Lambda、Amazon SNS、Amazon SQS などの AWS サービスにリダイレクトできます。
+ または AWS CLI CloudFormation SDK を使用して Auto Scaling グループの作成中に複数のライフサイクルフックを追加できます。 [CreateAutoScalingGroup](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CreateAutoScalingGroup.html) ただし、各フックの通知ターゲットと IAM ロール (指定されている場合) が同じである必要があります。異なる通知ターゲットと異なるロールでライフサイクルフックを作成するには、[PutLifecycleHook](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PutLifecycleHook.html) API に対する別個の呼び出しで、ライフサイクルフックを 1 つずつ作成します。
+ インスタンス起動用のライフサイクルフックを追加すると、ヘルスチェックの猶予期間は、インスタンスが `InService` 状態に到達するとすぐに開始されます。詳細については、「[Auto Scaling グループにヘルスチェックの猶予期間を設定する](health-check-grace-period.md)」を参照してください。
**スケーリングに関する考慮事項**
+ 動的スケーリングポリシーは、複数のインスタンスから集計した、CPU やネットワーク I/O などの CloudWatch メトリックスデータに応じて、スケールインとスケールアウトを行います。スケールアウトしても、Auto Scaling グループで集計するインスタンスメトリックスに、Amazon EC2 Auto Scaling が新しいインスタンスを追加するわけではありません。インスタンスが `InService` 状態に到達し、ウォームアップが完了するまで待機します。詳細については、デフォルトインスタンスのウォームアップのトピックの「[パフォーマンスのスケーリングに関する考慮事項](ec2-auto-scaling-default-instance-warmup.md#scaling-performance-considerations)」を参照してください。
+ スケールインでは、終了するインスタンスの削除が集約インスタンスメトリックスに直ちに反映されない場合があります。Amazon EC2 Auto Scaling の終了ワークフローが開始すると、終了するインスタンスは、グループの集計インスタンスメトリクスへのカウントを停止します。
+ ほとんどの場合、ライフサイクルフックが呼び出されると、簡易スケーリングポリシーに起因するスケーリングアクティビティは、ライフサイクルアクションが完了し、クールダウン期間が終了するまで一時停止されます。クールダウン期間に長い間隔を設定すると、スケーリングが再開されるまでに時間がかかることになります。詳細については、クールダウントピックの「[追加の遅延を発生させる可能性のあるライフサイクルフック](ec2-auto-scaling-scaling-cooldowns.md#cooldowns-lifecycle-hooks)」を参照してください。一般的に、ステップスケーリングポリシーまたはターゲット追跡スケーリングポリシーを使用できる場合には、簡易スケーリングポリシーを使わないことをおすすめします。
## 関連リソース
紹介ビデオについては、[[AWS re: Invent 2018: Amazon EC2 Auto Scaling でキャパシティ管理を容易にする](https://youtu.be/PideBMIcwBQ?t=469)] の [*YouTube*] をご覧ください。
CloudFormation スタックテンプレートでライフサイクルフックを宣言する方法を理解するために使用できる JSON および YAML テンプレートスニペットがいくつか用意されています。詳細については、「*AWS CloudFormation ユーザーガイド*」の「[AWS::AutoScaling::LifecycleHook](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-autoscaling-lifecyclehook.html)」のリファレンスを参照してください。
ライフサイクルフックのサンプルテンプレートとユーザーデータスクリプトは、[GitHub リポジトリ](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)でダウンロードできます。
ライフサイクルフックの使用例については、次のブログ記事を参照してください。
+ [Lambda と Amazon EC2 Run コマンドを使用したスケーリングインスタンスのバックアップシステムの構築](https://aws.amazon.com/blogs/compute/building-a-backup-system-for-scaled-instances-using-aws-lambda-and-amazon-ec2-run-command/)
+ [EC2 Auto Scaling インスタンスを終了する前にコードを実行します](https://aws.amazon.com/blogs/infrastructure-and-automation/run-code-before-terminating-an-ec2-auto-scaling-instance/)。
# Auto Scaling グループでのライフサイクルフックの仕組み
Amazon EC2 インスタンスは、起動から終了まで、さまざまな状態に移行します。Auto Scaling グループ用にカスタムアクションを作成して、ライフサイクルフックによってインスタンスが待機状態へ移行しているときに、動作させることができます。
次の図は、スケールアウトとスケールインにライフサイクル フックを使用する場合の Auto Scaling インスタンスの状態の遷移を示しています。
![\[スケールアウトとスケールインにライフサイクルフックを使用する場合の Auto Scaling インスタンスの状態遷移。\]](http://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/how-lifecycle-hooks-work.png)
(前の図には示されているように)。
1. Auto Scaling グループはスケールアウト イベントに応答し、インスタンスの起動を開始します。
1. ライフサイクルフックはインスタンスを待機状態 (`Pending:Wait`) にし、カスタムアクションを実行します。
インスタンスは、ライフサイクルアクションが完了するまで、またはタイムアウト期間が終了するまで待機状態のままになります。デフォルトでは、インスタンスは 1 時間にわたり待機状態になった後、Auto Scaling グループは起動処理を継続します(`Pending:Proceed`)。さらに時間が必要な場合は、ハートビートを記録することにより、タイムアウト期間を再開できます。カスタムアクションは完了したが、タイムアウト期間はまだ終了していないという場合にライフサイクルアクションを完了すると、タイムアウト期間が終了し、Auto Scaling グループは起動プロセスを続行します。
1. インスタンスは`InService`状態になり、ヘルスチェックの猶予期間がスタートします。ただし、Auto Scaling グループが Elastic Load Balancing ロードバランサーに関連付けられている場合、インスタンスが `InService` 状態に到達する前にインスタンスはロードバランサーに登録され、ロードバランサーはそのヘルスチェックを開始します。ヘルスチェックの猶予期間が終了すると、Amazon EC2 Auto Scaling はインスタンスのヘルス状態のチェックを開始します。
1. Auto Scaling グループはスケールイン イベントに応答し、インスタンスの終了を開始します。Auto Scaling グループが Elastic Load Balancing で使用されている場合、まず、終了するインスタンスがロードバランサーから登録解除されます。ロードバランサーの Connection Draining が有効になっている場合、インスタンスは新しい接続の受け入れを停止し、既存の接続のドレインを待ってから登録解除プロセスを完了します。
1. ライフサイクルフックはインスタンスを待機状態 (`Terminating:Wait`) にし、カスタムアクションを実行します。
インスタンスは、ライフサイクルアクションを完了するまで、またはタイムアウト期間が終了するまで (デフォルトでは 1 時間)、待機状態のままになります。ライフサイクルフックを完了するか、タイムアウト期間が終了すると、インスタンスは次の状態 (`Terminating:Proceed`)に移行します。
1. インスタンスが終了しました。
**重要**
ウォームプール内のインスタンスには、[ウォームプール内のインスタンスのライフサイクル状態の移行](warm-pool-instance-lifecycle.md#lifecycle-state-transitions) で説明されている、対応する待機状態を備えた独自のライフサイクルもあります。
## ルートボリューム置換中のインスタンスのライフサイクル状態遷移
次の図は、ルートボリュームの置き換えにライフサイクルフックを使用する場合の Auto Scaling インスタンスの状態間の遷移を示しています。
![\[ルートボリュームの置き換えにライフサイクルフックを使用する場合の Auto Scaling インスタンスの状態間の遷移。\]](http://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/root-volume-replacement-lifecycle-states.png)
(前の図には示されているように)。
1. Auto Scaling グループはインスタンスの更新に応答し、ルートボリュームの置き換えにインスタンスを選択します。インスタンスが `ReplacingRootVolume`状態になります。インスタンスがロードバランサーに登録されている場合、ロードバランサーから登録解除されます。
1. ライフサイクルフックはインスタンスを待機状態 (`ReplacingRootVolume:Wait`) にし、カスタムアクションを実行します。インスタンスは、ライフサイクルアクションが完了するまで、またはタイムアウト期間が終了するまで待機状態のままになります。カスタムアクションが完了し、タイムアウト期間がまだ切れていない場合にライフサイクルアクションを完了すると、期間は終了し、Auto Scaling グループはルートボリューム置換プロセスを続行します。
1. インスタンスはルートボリュームの置換を完了し、 `RootVolumeReplaced`状態になります。
1. インスタンスが `Pending`状態になります。
1. ライフサイクルフックはインスタンスを待機状態 (`Pending:Wait`) にし、カスタムアクションを実行します。インスタンスは、ライフサイクルアクションを完了するか、タイムアウト期間が終了するまで待機状態のままになります。ライフサイクルフックを完了するか、タイムアウト期間が終了すると、インスタンスは次の状態 (`Pending:Proceed`)に移行します。
1. インスタンスが `InService`状態になります。ただし、インスタンスが `InService`状態になる前に、Auto Scaling グループが Elastic Load Balancing ロードバランサーに関連付けられている場合、インスタンスはロードバランサーに登録されます。
# ライフサイクルフックを Auto Scaling グループに追加するための準備
Auto Scaling グループにライフサイクルフックを追加する前に、ユーザーデータスクリプト、または通知ターゲットまたはが正しく設定されていることを確認するようにしてください。
+ インスタンスの起動中にユーザーデータスクリプトを実行してインスタンスでカスタムアクションを使用するために、通知ターゲットを設定する必要はありません。ただし、ユーザーデータスクリプトを指定する起動テンプレートまたは起動設定を作成し、Auto Scaling グループに関連付けておく必要があります。ユーザーデータスクリプトの詳細については、「*Amazon EC2 ユーザーガイド*」の「[起動時に Linux インスタンスでコマンドを実行する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)」を参照してください。
+ ライフサイクルアクションの完了時に Amazon EC2 Auto Scaling に通知を行うには、スクリプトに [CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) API コールを追加し、Auto Scaling インスタンスがこの API を呼び出すことを許可するポリシーを持つ IAM ロールを手動で作成する必要があります。起動テンプレートまたは起動設定では、起動時に Amazon EC2 インスタンスにアタッチされる IAM インスタンスプロファイルを使用して、このロールを指定する必要があります。詳細については、「[Auto Scaling グループでライフサイクルアクションを完了する](completing-lifecycle-hooks.md)」および「[Amazon EC2 インスタンスで実行中のアプリケーション用の IAM ロール](us-iam-role.md)」を参照してください。
+ ライフサイクルアクション完了時に Lambda に Amazon EC2 Auto Scaling への通知を許可するには、[CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) API コールを関数コードに追加する必要があります。関数の実行ロールに、ライフサイクルフックを完了する許可を Lambda に付与する IAM ポリシーをアタッチする必要もあります。詳細については、「[チュートリアル:Lambda 関数を呼び出すライフサイクルフックの設定](tutorial-lifecycle-hook-lambda.md)」を参照してください。
+ Amazon SNS や Amazon SQS などのサービスを使用してカスタムアクションを実行するには、SNS トピックまたは SQS キューを作成し、その Amazon リソースネーム (ARN) を準備しておく必要があります。また、SNS トピックまたは SQS ターゲットへの Amazon EC2 Auto Scaling アクセスを許可する IAM ロールを作成し、その ARN を準備しておく必要があります。詳細については、「[ライフサイクル通知の通知ターゲットを設定する](#lifecycle-hook-notification-target)」を参照してください。
**注記**
デフォルトでは、コンソールでライフサイクルフックを追加すると、Amazon EC2 Auto Scaling は Amazon EventBridge にライフサイクルイベント通知を送信します。EventBridge またはユーザーデータスクリプトの使用は、推奨されるベストプラクティスです。Amazon SNS、Amazon SQS、または に直接通知を送信するライフサイクルフックを作成するには AWS Lambda、 AWS CLI、 AWS CloudFormation、または SDK を使用してライフサイクルフックを追加します。
## ライフサイクル通知の通知ターゲットを設定する
ライフサイクルフックを Auto Scaling グループに追加して、インスタンスが待機状態になったときにカスタムアクションを実行できます。希望する開発アプローチに応じてターゲットサービスを選択し、これらのアクションを実行できます。
ライフサイクルフックの通知ターゲットを実装するには、次の 4 つの異なるアプローチがあります。
+ **Amazon EventBridge**: 通知を受け取り、必要なアクションを実行します。
+ **Amazon Simple Notification Service (Amazon SNS)**: 通知を発行するためのトピックを作成します。クライアントは SNS トピックに登録し、サポートされているプロトコルを使用して公開されたメッセージを受信できます。
+ **Amazon Simple Queue Service (Amazon SQS)**: ポーリングモデルを介してメッセージを交換します。
+ **AWS Lambda**: 必要なアクションを実行する Lambda 関数を呼び出します。
ベストプラクティスとして、 EventBridge を使用することをお勧めします。Amazon SNS および Amazon SQS に送信される通知には、Amazon EC2 Auto Scaling が EventBridge に送信する通知と同じ情報が含まれています。EventBridge 以前は、SNS または SQS に通知を送信し、別のサービスを SNS または SQS に統合してプログラムによるアクションを実行するのがスタンダードな方法でした。今日、EventBridge では、対象となるサービスのオプションが増え、サーバーレス アーキテクチャを使用してイベントを処理しやすくなりました。
起動テンプレートまたは起動設定に、起動時にインスタンスを設定するユーザーデータスクリプトがある場合は、インスタンスでカスタムアクションを実行するための通知を受け取る必要はありません。
次の手順では、通知ターゲットの設定方法について説明します。
**Topics**
+ [EventBridge を使用して通知を Lambda にルーティングする](#cloudwatch-events-notification)
+ [Amazon SNS を使用した通知の受信](#sns-notifications)
+ [Amazon SQS を使用した通知の受信](#sqs-notifications)
+ [通知を AWS Lambda に直接ルーティングする](#lambda-notification)
+ [通知メッセージの例](#notification-message-example)
**重要**
ライフサイクルフックで使用する EventBridge ルール、Lambda 関数、Amazon SNS トピック、および Amazon SQS キューは、常に Auto Scaling グループを作成したのと同じリージョンに存在する必要があります。
### EventBridge を使用して通知を Lambda にルーティングする
EventBridge ルールを設定して、インスタンスが待機状態になったときに Lambda 関数を呼び出すことができます。Amazon EC2 Auto Scaling は、起動または終了するインスタンスとライフサイクルアクションを制御するために使用するトークンに関して、EventBridge にライフサイクルイベント通知を送信します。これらのイベントの例については、[Amazon EC2 Auto Scaling イベントリファレンス](ec2-auto-scaling-event-reference.md) を参照してください。
**注記**
を使用してイベントルール AWS マネジメントコンソール を作成すると、コンソールは Lambda 関数を呼び出すための EventBridge アクセス許可を付与するために必要な IAM アクセス許可を自動的に追加します。 AWS CLIを使用してイベントルールを作成する場合は、この権限を明示的に付与する必要があります。
EventBridge コンソールでイベントルールを作成する方法の詳細については、「*Amazon EventBridge ユーザーガイド*」の「[Creating Amazon EventBridge rules that react to events](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)」を参照してください。
- または -
コンソールユーザー向けの初歩的なチュートリアルについては、「[チュートリアル:Lambda 関数を呼び出すライフサイクルフックの設定](tutorial-lifecycle-hook-lambda.md)」を参照してください。このチュートリアルは、起動イベントをリッスンし、CloudWatch Logs のログにそれらを書き込むシンプルな Lambda 関数を作成する方法を説明します。
**Lambda 関数を呼び出す EventBridge ルールを作成するには**
1. [[Lambda コンソール](https://console.aws.amazon.com/lambda/home#/functions)] を使用して Lambda 関数を作成し、Amazon リソースネーム (ARN) を書き留めておきます。例えば、`arn:aws:lambda:region:123456789012:function:my-function`。EventBridge ターゲットを作成するには ARN が必要です。詳細については、[AWS Lambda デベロッパーガイド] の [[Lambda の開始方法](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html)] を参照してください。
1. インスタンス起動のイベントに一致するルールを作成するには、次の [put-rule](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/events/put-rule.html) コマンドを使用します。
```
aws events put-rule --name my-rule --event-pattern file://pattern.json --state ENABLED
```
次の例は、インスタンス起動ライフサイクルアクションの `pattern.json` を示しています。**イタリック体**のテキストは、Auto Scaling グループの名前に置き換えてください。
```
{
"source": [ "aws.autoscaling" ],
"detail-type": [ "EC2 Instance-launch Lifecycle Action" ],
"detail": {
"AutoScalingGroupName": [ "my-asg" ]
}
}
```
コマンドが正常に実行された場合は、ルールの ARN を使用して EventBridge が応答します。この ARN をメモします。これは、ステップ 4 で入力する必要があります。
他のイベントに一致するルールを作成するには、イベントパターンを変更します。詳細については、「[Auto Scaling イベントの処理に EventBridge を使用する](automating-ec2-auto-scaling-with-eventbridge.md)」を参照してください。
1. ルールのターゲットとして使用する Lambda 関数を指定するには、次の[put-arget](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/events/put-targets.html)コマンドを実行します。
```
aws events put-targets --rule my-rule --targets Id=1,Arn=arn:aws:lambda:region:123456789012:function:my-function
```
上記のコマンドで、*my-rule* はステップ 2 でルールに指定した名前になり、`Arn` パラメータの値はステップ 1 で作成した関数の ARN になります。
1. ルールが Lambda 関数を呼び出せるようにする許可を追加するには、以下の Lambda [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) コマンドを使用します。このコマンドは、EventBridge サービスのプリンシパル (`events.amazonaws.com`) 信頼し、指定のルールに許可を適用します。
```
aws lambda add-permission --function-name my-function --statement-id my-unique-id \
--action 'lambda:InvokeFunction' --principal events.amazonaws.com --source-arn arn:aws:events:region:123456789012:rule/my-rule
```
上記のコマンドでは:
+ *my-function*は、ルールがターゲットとして使用する Lambda 関数の名前です。
+ *my-unique-id* は、Lambda 関数ポリシーのステートメントを記述するためにユーザーが定義する一意の識別子です。
+ `source-arn`は EventBridge ルールの ARN です。
コマンドが正常に実行された場合は、次のような出力が表示されます。
```
{
"Statement": "{\"Sid\":\"my-unique-id\",
\"Effect\":\"Allow\",
\"Principal\":{\"Service\":\"events.amazonaws.com\"},
\"Action\":\"lambda:InvokeFunction\",
\"Resource\":\"arn:aws:lambda:us-west-2:123456789012:function:my-function\",
\"Condition\":
{\"ArnLike\":
{\"AWS:SourceArn\":
\"arn:aws:events:us-west-2:123456789012:rule/my-rule\"}}}"
}
```
`Statement` 値は、Lambda 関数ポリシーに追加されたステートメントの JSON 文字列バージョンです。
1. これらの指示に従った後、次のステップとして「[Auto Scaling グループにライフサイクル フックを追加する](adding-lifecycle-hooks.md)」に進みます。
### Amazon SNS を使用した通知の受信
Amazon SNS を使用して、ライフサイクルアクションが発生したときに、通知を受け取るよう、通知ターゲット (SNS トピック) をセットアップできます。次に、Amazon SNS は登録された受信者に通知を送信します。登録が確認されるまで、トピックに対して発行された通知は受信者に送信されません。
**Amazon SNS を使用して通知をセットアップするには**
1. Amazon SNS トピックを作成するには、[[Amazon SNS コンソール](https://console.aws.amazon.com/sns/)] または次の [[トピックの作成](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sns/create-topic.html)] のコマンドを使用します。このトピックが、使用している Auto Scaling グループと同じリージョンにあることを確認します。詳細については、[Amazon Simple 通知サービスデベロッパーガイド] の [[Amazon SNS の使用開始](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)] を参照してください。
```
aws sns create-topic --name my-sns-topic
```
1. その Amazon リソースネーム (ARN) をメモします、例えば、 `arn:aws:sns:region:123456789012:my-sns-topic`。ライフサイクルフックを作成するには、それが必要です。
1. IAM サービスロールを作成して、Amazon EC2 Auto Scaling に Amazon SNS 通知ターゲットへのアクセス権を付与します。
**SNS トピックへの Amazon EC2 Auto Scaling のアクセス権を付与するには**
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. 左側のナビゲーションペインで、[**Roles**] を選択します。
1. [**ロールの作成**] を選択してください。
1. **[Select trusted entity]** (信頼されたエンティティの選択) で、**[AWS のサービス]** を選択します。
1. ユースケースでは、[**他の AWS サービスのユースケース**] で [**EC2 Auto Scaling**]、[**EC2 Auto Scaling Notification Access**] の順に選択します。
1. **[Next]** (次へ) を 2 回選択して、**[Name, review, and create]** (名前、確認、および作成) ページに進みます。
1. **[Role name]** (ロール名) にロールの名前 (**my-notification-role** など) を入力して、**[Create role]** (ロールを作成) を選択します。
1. [**Roles (ロール)**] ページで作成したロールを選択して、[**Summary (概要)**] ページを開きます。ロールの **[ARN]** をメモします。例えば、`arn:aws:iam::123456789012:role/my-notification-role`。ライフサイクルフックを作成するには、それが必要です。
1. これらの指示に従った後、次のステップとして「[ライフサイクルフックを追加する (AWS CLI)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-aws-cli)」に進みます。
### Amazon SQS を使用した通知の受信
ライフサイクルアクションが発生したときにメッセージを受け取るよう、Amazon SQS を使用して通知ターゲットをセットアップできます。キューコンシューマーは、SQS キューをポーリングしてこれらの通知を処理する必要があります。
**重要**
FIFO キューはライフサイクルフックとの互換性がありません。
**Amazon SQS を使用して通知をセットアップするには**
1. [[Amazon SQS コンソール](https://console.aws.amazon.com/sqs/)] を使用して、Amazon SQS キューを作成します。キューが,使用している Auto Scaling グループと同じリージョンにあることを確認します。詳細については、「*Amazon Simple Queue Service デベロッパーガイド*」の「[Getting started with Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)」を参照してください。
1. キューの ARN をメモします。例えば、`arn:aws:sqs:us-west-2:123456789012:my-sqs-queue`。ライフサイクルフックを作成するには、それが必要です。
1. IAM サービスロールを作成して、Amazon EC2 Auto Scaling に Amazon SQS 通知ターゲットへのアクセス権を付与します。
**SQS キューへ Amazon EC2 Auto Scaling のアクセス権を付与するには**
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. 左側のナビゲーションペインで、[**Roles**] を選択します。
1. [**ロールの作成**] を選択してください。
1. **[Select trusted entity]** (信頼されたエンティティの選択) で、**[AWS のサービス]** を選択します。
1. ユースケースでは、[**他の AWS サービスのユースケース**] で [**EC2 Auto Scaling**]、[**EC2 Auto Scaling Notification Access**] の順に選択します。
1. **[Next]** (次へ) を 2 回選択して、**[Name, review, and create]** (名前、確認、および作成) ページに進みます。
1. **[Role name]** (ロール名) にロールの名前 (**my-notification-role** など) を入力して、**[Create role]** (ロールを作成) を選択します。
1. [**Roles (ロール)**] ページで作成したロールを選択して、[**Summary (概要)**] ページを開きます。ロールの **[ARN]** をメモします。例えば、`arn:aws:iam::123456789012:role/my-notification-role`。ライフサイクルフックを作成するには、それが必要です。
1. これらの指示に従った後、次のステップとして「[ライフサイクルフックを追加する (AWS CLI)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-aws-cli)」に進みます。
### 通知を AWS Lambda に直接ルーティングする
ライフサイクルアクションが発生したときに通知ターゲットとして Lambda 関数を使用できます。
**通知を AWS Lambda に直接ルーティングするには**
1. Lambda コンソールで [[Functions (関数)] ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。
1. 目的の Lambda 関数を選択します。
新しい Lambda 関数を作成する場合は、「[Lambda 関数を作成する](lambda-custom-termination-policy.md#lambda-custom-termination-policy-create-function)」を参照してください。
1. 次に **[設定]** タブと **[アクセス許可]** を選択します。
1. [**Resource-based policy (リソースベースのポリシー)**] にスクロールダウンして [**アクセス許可の追加**] を選択します。リソースベースのポリシーを使用して、関数を呼び出すアクセス許可を、ポリシーで指定されているプリンシパルに付与します。この場合、プリンシパルは Auto Scaling グループに関連付けられている [Amazon EC2 Auto Scaling service-linked role](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html) です。
1. [**Policy statement (ポリシーステートメント)**] セクションで、権限を設定します。
1. **AWS アカウント** を選択します。
1. **Principal (プリンシパル)** で、例えば **arn:aws:iam:::role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling** といった呼び出しサービスにリンクされたロールの ARN を入力します。
1. [**Action (アクション)**] で、[**lambda:InvokeFunction**] を選択します。
1. [**Statement ID (ステートメント ID)**] に **AllowInvokeByAutoScaling** といった一意のステートメント ID を入力します。
1. **[保存]** を選択します。
1. これらの指示に従った後、次のステップとして「[ライフサイクルフックを追加する (AWS CLI)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-aws-cli)」に進みます。
### 通知メッセージの例
このセクションでは、Amazon SNS、Amazon SQS、および の通知の例を示します AWS Lambda。
インスタンスが待機状態にある間、メッセージは Amazon SNS、Amazon SQS、 AWS Lambda 通知ターゲットに発行されます。
メッセージには、次に示す情報が含まれます。
+ `Origin` — EC2 インスタンスが来る場所。
+ `Destination` — EC2 インスタンスが向かう場所。
+ `LifecycleActionToken` - ライフサイクル アクション トークン。
+ `AccountId` — AWS アカウント ID。
+ `AutoScalingGroupName` - Auto Scaling グループの名前。
+ `LifecycleHookName` - ライフサイクルフックの名前。
+ `EC2InstanceId` - EC2 インスタンスの ID。
+ `LifecycleTransition` - ライフサイクルフックタイプ。
+ `NotificationMetadata` — 通知メタデータ。
通知メッセージの例を次に示します。
```
Service: AWS Auto Scaling
Time: 2021-01-19T00:36:26.533Z
RequestId: 18b2ec17-3e9b-4c15-8024-ff2e8ce8786a
Origin: EC2
Destination: AutoScalingGroup
LifecycleActionToken: 71514b9d-6a40-4b26-8523-05e7ee35fa40
AccountId: 123456789012
AutoScalingGroupName: my-asg
LifecycleHookName: my-hook
EC2InstanceId: i-0598c7d356eba48d7
LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING
NotificationMetadata: hook message metadata
```
#### テスト通知メッセージの例
最初にライフサイクルフックを追加すると、テスト通知メッセージが通知ターゲットに発行されます。テスト通知メッセージの例を次に示します。
```
Service: AWS Auto Scaling
Time: 2021-01-19T00:35:52.359Z
RequestId: 18b2ec17-3e9b-4c15-8024-ff2e8ce8786a
Event: autoscaling:TEST_NOTIFICATION
AccountId: 123456789012
AutoScalingGroupName: my-asg
AutoScalingGroupARN: arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:042cba90-ad2f-431c-9b4d-6d9055bcc9fb:autoScalingGroupName/my-asg
```
**注記**
Amazon EC2 Auto Scaling から EventBridge に配信されるイベントの例については、[Amazon EC2 Auto Scaling イベントリファレンス](ec2-auto-scaling-event-reference.md)を参照してください。
# インスタンスライフサイクルポリシーを使用してインスタンスの保持を制御する
インスタンスライフサイクルポリシーは、終了ライフサイクルアクションが中止されたときの Amazon EC2 Auto Scaling の終了に対する保護を提供します。ライフサイクルフックのみとは異なり、インスタンスライフサイクルポリシーは、正常なシャットダウン手順が正常に完了しなかった場合にインスタンスが保持状態に移行するように設計されています。
## インスタンスライフサイクルポリシーを使用するタイミング
アプリケーションの正常なシャットダウンがオプションではなく必須であり、シャットダウンに失敗した場合に手動による介入が必要な場合は、インスタンスライフサイクルポリシーを使用します。一般的ユースケースには以下が含まれます。
+ 終了前にデータの永続化を完了する必要があるステートフルアプリケーション。
+ ライフサイクルフックの最大タイムアウトである 48 時間を超える可能性のある延長ドレイン期間を必要とするアプリケーション。
+ クリーンアップが失敗または不完全な場合に機密データを処理するワークロードは、データの損失や破損につながる可能性があります。
+ 突然のシャットダウンが可用性に影響を与えるミッションクリティカルなサービス。
インスタンスの終了を適切に処理する方法の詳細については、「」を参照してください[インスタンスの終了を的確に処理するようにアプリケーションを設計する](gracefully-handle-instance-termination.md)。
## インスタンスライフサイクルポリシーが終了ライフサイクルフックと連携する方法
インスタンスライフサイクルポリシーは、代替としてではなく、終了ライフサイクルフックと組み合わせて機能します。このプロセスにはいくつかの段階があります。
1. **終了ライフサイクルアクションが実行されます。**Amazon EC2 Auto Scaling が終了するインスタンスを選択すると、終了ライフサイクルフックが呼び出され、インスタンスは `Terminating:Wait`状態になり、終了ライフサイクルアクションの実行を開始します。
1. **正常なシャットダウンの試行が開始されます。**アプリケーションは、インスタンス上またはコントロールプレーンを介して実行され、終了ライフサイクルアクション通知を受け取り、接続のドレイン、進行中の作業の完了、データ転送などの正常なシャットダウン手順を開始します。
1. **終了ライフサイクルアクションが完了しました。**終了ライフサイクルアクションは、 `CONTINUE`または `ABANDON`の結果で完了できます。
1. **インスタンスライフサイクルポリシーは状況を評価します。**インスタンスライフサイクルポリシーを設定しないと、終了ライフサイクルアクションが`ABANDON`結果とともに完了した場合でも、インスタンスは直ちに終了に進みます。でインスタンスを保持するように設定されたインスタンスライフサイクルポリシーでは`TerminateHookAbandon`、終了ライフサイクルアクションが`ABANDON`結果とともに完了すると、インスタンスは保持状態に移行します。
1. **保持されたインスタンスは手動アクションを待機しています。**保持状態のインスタンスには、引き続き標準の Amazon EC2 料金が発生します。これらのインスタンスは Auto Scaling グループの希望する容量にはカウントされないため、Auto Scaling は必要なサイズを維持するために代替インスタンスを起動します。インスタンスの更新やインスタンスの最大有効期間などの Auto Scaling 機能も、保持されているインスタンスを無視します。これにより、クリーンアップ手順を手動で完了したり、データを復元したり、インスタンスを手動で終了する前に自動シャットダウンが失敗した理由を調査したりできます。
1. **手動終了が発生します。**保持されたインスタンスで必要なアクションを完了したら、 `TerminateInstanceInAutoScalingGroup` API を呼び出してインスタンスを終了する必要があります。
# インスタンスの保持を設定する
終了ライフサイクルアクションが失敗したときにインスタンスを保持するように Amazon EC2 Auto Scaling グループを設定します。
Auto Scaling グループでインスタンスライフサイクルポリシーを使用するには、終了ライフサイクルフックも設定する必要があります。インスタンスライフサイクルポリシーを設定しても、終了ライフサイクルフックがない場合、ポリシーは効果がありません。インスタンスライフサイクルポリシーは、終了ライフサイクルアクションが中止された場合にのみ適用され、`CONTINUE`結果が正常に完了した場合は適用されません。
インスタンスライフサイクルポリシーは、保持トリガーを使用して、インスタンスを保持するタイミングを決定します。`TerminateHookAbandon` トリガーにより、いくつかのシナリオで保持されます。
+ `ABANDON` 結果を使用して [ CompleteLifecycleAction ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) API を明示的に呼び出す場合。
+ ハートビートを受信せずにハートビート`ABANDON`タイムアウトに達したために、デフォルトの終了ライフサイクルアクションがタイムアウトした場合。
+ デフォルトの結果 を持つ終了ライフサイクルアクションでグローバルタイムアウトに達すると`ABANDON`、48 時間またはハートビートタイムアウトの 100 倍のいずれか小さい方になります。
------
#### [ Console ]
**インスタンスの保持を設定するには**
1. Amazon EC2 Auto Scaling コンソールを開く
1. Auto Scaling グループを作成する (インスタンスライフサイクルポリシーのデフォルトは終了)
1. Auto Scaling グループの詳細ページに移動し、**インスタンス管理**タブを選択します。
1. **ライフサイクルフックのインスタンスライフサイクルポリシーで**、**保持**を選択します。
1. 以下を使用して終了ライフサイクルフックを作成します。
+ ライフサイクル移行を**インスタンス終了**に設定
+ デフォルトの結果を **Abandon **に設定する
------
#### [ AWS CLI ]
**インスタンスの保持を設定するには**
インスタンスライフサイクルポリシーで [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを使用します。
```
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-asg \
--launch-template LaunchTemplateName=my-template,Version='$Latest' \
--min-size 1 \
--max-size 3 \
--desired-capacity 2 \
--vpc-zone-identifier subnet-12345678 \
--instance-lifecycle-policy file://lifecycle-policy.json
```
Lifecycle-policy.json の内容:
```
{
"RetentionTriggers": {
"TerminateHookAbandon": "retain"
}
}
```
**終了ライフサイクルフックを追加するには**
[put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html) コマンドを使用します。
```
aws autoscaling put-lifecycle-hook \
--lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
--default-result ABANDON \
--heartbeat-timeout 300
```
------
# 保持されたインスタンスを管理する
保持状態に移行した Amazon EC2 インスタンスを監視および制御します。CloudWatch メトリクスを使用して保持されたインスタンスを追跡し、カスタムアクションの完了後に保持されたインスタンスを手動で終了します。
保持されたインスタンスは、Amazon EC2 Auto Scaling グループの希望する容量にはカウントされません。インスタンスが保持状態になると、Auto Scaling は必要な容量を維持するために代替インスタンスを起動します。たとえば、Auto Scaling グループの希望する容量が 10 であるとします。インスタンスが `Terminating:Retained`状態になると、Auto Scaling は必要な容量を 10 に維持するために代替インスタンスを起動します。これで、アクティブなグループに 10 個のインスタンスと 1 個の保持されたインスタンスの合計 11 個のインスタンスが実行されました。保持されたインスタンスを手動で終了するまで、11 個のインスタンスすべてに対する標準の Amazon EC2 料金が適用されます。
## 保持されたインスタンスのインスタンスライフサイクル状態
インスタンスライフサイクルポリシーが使用される場合に、インスタンスがライフサイクル状態に移行する方法を理解します。インスタンスは、通常の終了から保持、最終終了までの特定のパスに従います。
*保持がトリガーされると、インスタンスは次の状態に移行します。*
1. `Terminating` - 通常の終了が開始されます
1. `Terminating:Wait` - ライフサイクルフックの実行
1. `Terminating:Proceed` - ライフサイクルアクションをまとめる (成功したか失敗したか)
1. `Terminating:Retained` - フックが失敗し、手動介入のためにインスタンスが保持される
ウォームプールインスタンスは、シナリオに応じて異なるライフサイクル状態パスを取ります。
*ウォームプールにスケールバックするインスタンス:*
1. `Warmed:Pending` - 通常のウォームプールの移行が開始されます
1. `Warmed:Pending:Wait` - ライフサイクルフックの実行
1. `Warmed:Pending:Proceed` - ライフサイクルアクションをまとめる (成功したか失敗したか)
1. `Warmed:Pending:Retained` - フックが失敗し、インスタンスが手動介入のために保持される
*ウォームプールから終了されるインスタンス:*
1. `Warmed:Terminating` - 通常の終了が開始されます
1. `Warmed:Terminating:Wait` - ライフサイクルフックの実行
1. `Warmed:Terminating:Proceed` - ライフサイクルアクションをまとめる (成功したか失敗したか)
1. `Warmed:Terminating:Retained` - フックが失敗し、インスタンスが手動介入のために保持される
## 保持されたインスタンスをモニタリングする
保持された Amazon EC2 インスタンスにはコストがかかり、手動による介入が必要なため、モニタリングが不可欠です。Amazon EC2 Auto Scaling には、保持されているインスタンスを追跡するための CloudWatch メトリクスがいくつか用意されています。
グループメトリクスを有効にして、保持されたインスタンスを追跡します。
```
aws autoscaling enable-metrics-collection \
--auto-scaling-group-name my-asg \
--metrics GroupTerminatingRetainedInstances
```
使用可能なメトリクスは次のとおりです。
+ `GroupTerminatingRetainedInstances` は、 `Terminating:Retained`状態のインスタンスの数を示します。
+ `GroupTerminatingRetainedCapacity` は、 `Terminating:Retained`状態のインスタンスによって表されるキャパシティーユニットを示します。
+ `WarmPoolTerminatingRetainedCapacity` は、ウォームプールから終了する保持されたインスタンスを追跡します。
+ `WarmPoolPendingRetainedCapacity` は、ウォームプールに戻る保持されたインスタンスを追跡します。
Amazon EC2 Auto Scaling グループのスケーリングアクティビティを確認して、インスタンスが保持された理由を把握することもできます。ライフサイクルフックの失敗を示す `StatusCode: Cancelled`およびステータスの理由メッセージを含む終了アクティビティを探します。
```
aws autoscaling describe-scaling-activities \
--auto-scaling-group-name my-asg
```
これらのメトリクスに CloudWatch アラームを作成して、インスタンスが保持状態になったときにアラートを受け取ることをお勧めします。これにより、コストへの影響を追跡し、手動による介入が必要なインスタンスのクリーンアップを忘れないようにできます。
## 保持されたインスタンスを終了する
カスタムアクションが完了したら、[TerminateInstanceInAutoScalingGroup API ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html)を呼び出して、保持されているインスタンスを終了します。
```
aws autoscaling terminate-instance-in-auto-scaling-group \
--instance-id i-1234567890abcdef0 \
--no-should-decrement-desired-capacity
```
# インスタンスメタデータを使用してターゲットライフサイクル状態を取得する
起動する各 Auto Scaling インスタンスは、いくつかのライフサイクル状態を経過します。特定のライフサイクル状態移行で実行されるようにインスタンス上のカスタムアクションをインスタンス内から呼び出すには、インスタンスメタデータを使用してターゲットライフサイクル状態を取得する必要があります。
例えば、インスタンスが終了する前にインスタンス上で何らかのコードを実行するために、インスタンス内部からのインスタンスの終了を検出するメカニズムが必要な場合があります。これには、インスタンスからインスタンスのライフサイクル状態を直接ポーリングするコードを書きます。次に、ライフサイクル フックを Auto Scaling グループに追加して、コードが **complete-lifecycle-action** コマンドを送信して続行するまでインスタンスを実行し続けることができます。
Auto Scaling インスタンスのライフサイクルには、2 つの主な定常状態 (`InService` および `Terminated`) と、2 つの副次的な定常状態 (`Detached` および `Standby`) があります。ウォームプールを使用する場合、ライフサイクルにはさらに 4 つの定常状態 (`Warmed:Hibernated`、`Warmed:Running`、`Warmed:Stopped`、および `Warmed:Terminated`) があります。
インスタンスが前述の定常状態のいずれかに移行する準備を行うと、Amazon EC2 Auto Scaling がインスタンスメタデータ項目の `autoscaling/target-lifecycle-state` の値を更新します。インスタンス内からターゲットライフサイクル状態を取得するには、インスタンスメタデータサービスを使用してインスタンスメタデータから状態を取得する必要があります。
**注記**
*インスタンスメタデータ*は、アプリケーションがインスタンス情報をクエリするために使用できる、Amazon EC2 インスタンスに関するデータです。*インスタンスメタデータサービス*は、ローカルコードがインスタンスメタデータにアクセスするために使用する、インスタンス上のコンポーネントです。ローカルコードには、インスタンスで実行されているユーザーデータスクリプトまたはアプリケーションなどがあります。
ローカルコードは、インスタンスメタデータサービスバージョン 1 (IMDSv1) とインスタンスメタデータサービスバージョン 2 (IMDSv2) の 2 つの方法のいずれかを使用して、実行中のインスタンスからのインスタンスメタデータにアクセスできます。IMDSv2 はセッション指向のリクエストを使用し、インスタンスメタデータへのアクセス試行に利用される可能性がある数種類の脆弱性を緩和します。これら 2 つの方法の詳細については、「*Amazon EC2 ユーザーガイド*」の「[IMDSv2 の使用](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)」を参照してください。
------
#### [ IMDSv2 ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/autoscaling/target-lifecycle-state
```
------
#### [ IMDSv1 ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/autoscaling/target-lifecycle-state
```
------
以下は出力の例です。
```
InService
```
ターゲットライフサイクル状態とは、インスタンスの移行先状態のことです。現在のライフサイクル状態は、インスタンスの今の状態です。これらは、ライフサイクルアクションが完了し、インスタンスがターゲットライフサイクル状態への移行を完了した後で同じになる場合があります。インスタンスメタデータからインスタンスの現在のライフサイクル状態を取得することはできません。
Amazon EC2 Auto Scaling は、2022 年 3 月 10 日にターゲットライフサイクル状態の生成を開始しました。この日付以降にインスタンスがターゲットライフサイクル状態のいずれかに移行した場合は、インスタンスメタデータにターゲットライフサイクル状態項目が存在します。移行しなかった場合は項目が存在しないため、HTTP 404 エラーが発生します。
インスタンスメタデータの詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータの取得](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html)」を参照してください。
ターゲットライフサイクル状態を使用するユーザーデータスクリプトでカスタムアクションを伴うライフサイクルフックを作成する方法を説明するチュートリアルについては、「[チュートリアル: データスクリプトとインスタンスメタデータを使用してライフサイクル状態を取得する](tutorial-lifecycle-hook-instance-metadata.md)」を参照してください。
**重要**
カスタムアクションをできるだけ早く呼び出しできるようにするには、ローカルコードで IMDS を頻繁にポーリングし、エラーがあれば再試行する必要があります。
# Auto Scaling グループにライフサイクル フックを追加する
Auto Scaling インスタンスを待機状態にしてカスタムアクションを実行するために、Auto Scaling グループにライフサイクルフックを追加できます。カスタムアクションは、インスタンスの起動時または終了前に実行されます。インスタンスは、ライフサイクルアクションが完了するまで、またはタイムアウト期間が終了するまで待機状態のままになります。
から Auto Scaling グループを作成したら AWS マネジメントコンソール、1 つ以上のライフサイクルフックを追加でき、最大合計 50 個のライフサイクルフックを追加できます。 AWS CLIまたは SDK を使用して CloudFormation、Auto Scaling グループの作成時にライフサイクルフックを追加することもできます。
デフォルトでは、コンソールでライフサイクルフックを追加すると、Amazon EC2 Auto Scaling は Amazon EventBridge にライフサイクルイベント通知を送信します。EventBridge またはユーザーデータスクリプトの使用は、推奨されるベストプラクティスです。このトピックの例に示すように、通知を Amazon SNS、Amazon SQS、または AWS Lambda [put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html) コマンドに直接送信するライフサイクルフックを作成するには。
**Topics**
+ [ライフサイクルフックを追加する (コンソール)](#adding-lifecycle-hooks-console)
+ [ライフサイクルフックを追加する (AWS CLI)](#adding-lifecycle-hooks-aws-cli)
## ライフサイクルフックを追加する (コンソール)
Auto Scaling グループにライフサイクル フックを追加するには、次の手順に従います。スケールアウト (インスタンスの起動) とスケールイン (インスタンスの終了またはウォーム プールへの復帰) のためのライフサイクルフックを追加するには、2 つの個別のフックを作成する必要があります。
作業を開始する前に、「[ライフサイクルフックを Auto Scaling グループに追加するための準備](prepare-for-lifecycle-notifications.md)」で説明されているように必要に応じてカスタムアクションがセットアップされていることを確認してください。
**スケールアウト用のライフサイクルフックを追加するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。ページの下部にスプリットペインが開きます。
1. [**Instance management (インスタンス管理)**] タブの [**Lifecycle hooks (ライフサイクルフック)**] で、[**Create lifecycle hook (ライフサイクルフックを作成)**] を選択します。
1. スケールアウト (インスタンスが起動) のライフサイクルフックを定義するには、以下を実行してください。
1. [**Lifecycle hook name (ライフサイクルフック名)**] で、ライフサイクルフックの名前を指定します。
1. [**Lifecycle transition (ライフサイクルの移行)**] で、[**Instance launch (インスタンスの起動)**] を選択します。
1. **[ハートビートのタイムアウト]** には、スケールアウト時にフックがタイムアウトするまで待機状態を維持する時間を秒単位で指定します。この時間の範囲は `30`～`7200` 秒です。タイムアウト期間を長く設定すると、カスタムアクションが完了する時間が長くなります。その後、タイムアウト期間終了前に終了した場合は、[complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html) コマンドを送信して、インスタンスが次の状態に進むことを許可します。
1. **[Default result]** (デフォルトの結果) には、ライフサイクルフックのタイムアウト時間を過ぎた場合、または予期しない障害が発生した場合に実行するアクションを指定します。**[続行]** または **中止** のどちらかを選択できます。
+ **[続行]** を選択すると、Auto Scaling グループは他のライフサイクル フックを続行し、インスタンスをサービスに投入できます。
+ **[中止]** を選択する場合、Auto Scaling グループは残りのアクションをすべて停止し、インスタンスをただちに終了します。
1. (オプション) **[通知メタデータ]** には、Amazon EC2 Auto Scaling が通知ターゲットにメッセージを送信するときに含めるその他の情報を指定します。
1. **[作成]** を選択します。
**スケールイン用のライフサイクルフックを追加するには**
1. スケールアウト用のライフサイクル フックを作成した後、**[ライフサイクル フックの作成]** を選択して、中断したところから続行します。
1. スケールイン (インスタンスを終了またはウォームプールに戻す) のライフサイクルフックを定義するには、以下を実行してください。
1. [**Lifecycle hook name (ライフサイクルフック名)**] で、ライフサイクルフックの名前を指定します。
1. [**Lifecycle transition (ライフサイクルの移行)**] で、[**Instance terminate (インスタンスの終了)**] を選択します。
1. **[ハートビートのタイムアウト]** には、スケールアウト時にフックがタイムアウトするまで待機状態を維持する時間を秒単位で指定します。CloudWatch から EC2 ログを取得するなどの最終タスクの実行に必要な時間に応じて、`30`～`120` 秒の短いタイムアウト期間で指定することをお勧めします。
1. **[Default result]** (デフォルトの結果) には、タイムアウト時間を超過した、または予期しない失敗が発生した場合に Auto Scaling グループが実行するアクションを指定します。**[ABANDON]** (中止) と **[CONTINUE]** (続行) は、どちらもインスタンスを終了します。
+ **[CONTINUE]** (続行) を選択する場合、Auto Scaling グループは、終了前に他のライフサイクルフックなどの残りのアクションを続行できます。
+ **[中止]** を選択すると、Auto Scaling グループはインスタンスをただちに終了します。
1. (オプション) **[通知メタデータ]** には、Amazon EC2 Auto Scaling が通知ターゲットにメッセージを送信するときに含めるその他の情報を指定します。
1. **[作成]** を選択します。
## ライフサイクルフックを追加する (AWS CLI)
[[put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html)] コマンドを使用して、ライフサイクルフックを作成および更新ができます。
スケールアウトでアクションを実行するには、以下のコマンドを使用します。
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_LAUNCHING
```
スケールインでアクションを実行するには、以下のコマンドを使用します。
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING
```
Amazon SNS または Amazon SQS を使用して通知を受信するには、`--notification-target-arn` および `--role-arn` オプションを追加します。を使用して通知を受信するには AWS Lambda、 を追加します`--notification-target-arn`。
以下の例は、`my-sns-topic` という名前の SNS トピックを通知ターゲットとして指定するライフサイクルフックを作成します。
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
--notification-target-arn arn:aws:sns:region:123456789012:my-sns-topic \
--role-arn arn:aws:iam::123456789012:role/my-notification-role
```
トピックは、以下のキーと値のペアが含まれたテスト通知を受け取ります。
```
"Event": "autoscaling:TEST_NOTIFICATION"
```
デフォルトで、[put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html) コマンドは、ハートビートタイムアウトが `3600` 秒 (1 時間) のライフサイクルフックを作成します。
既存のライフサイクルフックのハートビートタイムアウトを変更するには、以下の例にあるように、`--heartbeat-timeout` オプションを追加します。
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg --heartbeat-timeout 120
```
インスタンスがすでに待機状態になっている場合は、[record-lifecycle-action-heartbeat](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/record-lifecycle-action-heartbeat.html) CLI コマンドを使用して、ハートビートを記録することによってライフサイクルフックがタイムアウトしないようにすることができます。これにより、ライフサイクルフックを作成するときに指定するタイムアウト時間によってタイムアウト期間が延長されます。タイムアウト期間が終わる前に終了した場合は、インスタンスが次の状態に進むことを許可する [complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html) CLI コマンドを送信することができます。詳細な説明と例については、[Auto Scaling グループでライフサイクルアクションを完了する](completing-lifecycle-hooks.md) を参照してください。
# Auto Scaling グループでライフサイクルアクションを完了する
Auto Scaling グループがライフサイクルイベントに応答する際、Auto Scaling グループはインスタンスを待機状態にしてイベント通知を送信します。インスタンスが待機状態にあるときに、カスタムアクションを実行できます。
ライフサイクルアクションを`CONTINUE` の結果で完了させることで、タイムアウト期間が経過する前に終了させることができます。ライフサイクル アクションを完了しない場合、タイムアウト期間が終了すると、ライフサイクル フックは**デフォルトの結果**コードに指定したステータスになります。
**Topics**
+ [ライフサイクルアクションを完了する (手動)](#completing-lifecycle-hooks-aws-cli)
+ [ライフサイクルアクションを完了する (自動)](#completing-lifecycle-hooks-automatic)
## ライフサイクルアクションを完了する (手動)
次の手順はコマンドライン インターフェイスに関するもので、コンソールではサポートされていません。インスタンス ID や Auto Scaling グループの名前など、置き換える必要がある情報は、斜体で表示されます。
**ライフサイクルアクションを完了するには (AWS CLI)**
1. カスタムアクション完了までにさらに時間が必要な場合は、[record-lifecycle-action-heartbeat](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/record-lifecycle-action-heartbeat.html) コマンドを使用してタイムアウト時間を再開し、インスタンスを待機状態に維持します。例えば、タイムアウト期間が 1 時間に設定されており、30 分後にこのコマンドを呼び出す場合、インスタンスはさらに 1 時間 (合計で 90 分) 待機状態のままになります。
以下のコマンドに示すように、[通知](prepare-for-lifecycle-notifications.md#notification-message-example)と共に受信したライフサイクルアクショントークンを指定できます。
```
aws autoscaling record-lifecycle-action-heartbeat --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg --lifecycle-action-token bcd2f1b8-9a78-44d3-8a7a-4dd07d7cf635
```
または、以下のコマンドに示すように、[通知](prepare-for-lifecycle-notifications.md#notification-message-example)とともに受信したインスタンスの ID を指定できます。
```
aws autoscaling record-lifecycle-action-heartbeat --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg --instance-id i-1a2b3c4d
```
1. [[complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html)] コマンドを使用してタイムアウト期間が終了する前にカスタムアクションを終了すると、Auto Scaling グループは起動を継続するか、インスタンスを終了することができます。以下のコマンドに示すように、ライフサイクルアクショントークンを指定できます。
```
aws autoscaling complete-lifecycle-action --lifecycle-action-result CONTINUE \
--lifecycle-hook-name my-launch-hook --auto-scaling-group-name my-asg \
--lifecycle-action-token bcd2f1b8-9a78-44d3-8a7a-4dd07d7cf635
```
または、以下のコマンドに示すように、インスタンスの ID を指定できます。
```
aws autoscaling complete-lifecycle-action --lifecycle-action-result CONTINUE \
--instance-id i-1a2b3c4d --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg
```
## ライフサイクルアクションを完了する (自動)
起動後にインスタンスを設定するユーザーデータスクリプトがある場合は、ライフサイクルアクションを手動で完了する必要はありません。[complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html) コマンドをスクリプトに追加します。スクリプトは、インスタンスのメタデータからインスタンス ID を取得し、ブートストラップスクリプトが正常に完了したときに Amazon EC2 Auto Scaling に通知します。
まだそうしていない場合は、インスタンスメタデータからインスタンスのインスタンス ID を取得するためのスクリプトを更新します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータを取得する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html)」を参照してください。
Lambda を使用する場合は、カスタムアクションが成功した際にインスタンスのライフサイクルを続行できるように、関数のコードにコールバックを設定することもできます。詳細については、「[チュートリアル:Lambda 関数を呼び出すライフサイクルフックの設定](tutorial-lifecycle-hook-lambda.md)」を参照してください。
# チュートリアル: データスクリプトとインスタンスメタデータを使用してライフサイクル状態を取得する
ライフサイクルフックのカスタムアクションを作成する一般的な方法は、Amazon EC2 Auto Scaling が Amazon EventBridge などの他のサービスに送信する通知を使用することですが、その代わりに、インスタンスを設定してライフサイクルアクションを完了するコードをインスタンスそのものに移動させるユーザーデータスクリプトを使用することによって、追加のインフラストラクチャを作成する手間を省くことができます。
以下のチュートリアルは、ユーザーデータスクリプトとインスタンスメタデータを使用して開始する方法を説明します。グループ内のインスタンスの[ターゲットライフサイクル状態](retrieving-target-lifecycle-state-through-imds.md)を読み取り、インスタンスのライフサイクルの特定のフェーズでコールバックアクションを実行して起動プロセスを続行するユーザーデータスクリプトを使用した、基本的な Auto Scaling グループ設定を作成します。
次の図は、ユーザーデータスクリプトを使用してカスタムアクションを実行する際のスケールアウトイベントのフローをまとめたものです。インスタンスが起動した後、タイムアウトまたは Amazon EC2 Auto Scaling が続行のシグナルを受信することによってライフサイクルフックが完了するまで、インスタンスのライフサイクルは一時停止されます。
![\[ユーザーデータスクリプトを使用してカスタムアクションを実行する場合のスケールアウトイベントのフロー。\]](http://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/lifecycle-hook-user-data-script.png)
**Topics**
+ [ステップ 1: ライフサイクルアクションを完了するための許可を持つ IAM ロールを作成する](#instance-metadata-create-iam-role)
+ [ステップ 2: 起動テンプレートを作成して IAM ロールとユーザーデータスクリプトを含める](#instance-metadata-create-hello-world-function)
+ [ステップ 3: Auto Scaling グループを作成する](#instance-metadata-create-auto-scaling-group)
+ [ステップ 4: ライフサイクルフックを追加する](#instance-metadata-add-lifecycle-hook)
+ [ステップ 5: 機能をテストして検証する](#instance-metadata-testing-hook)
+ [ステップ 6: クリーンアップする](#instance-metadata-lifecycle-hooks-tutorial-cleanup)
+ [関連リソース](#instance-metadata-lifecycle-hooks-tutorial-related-resources)
## ステップ 1: ライフサイクルアクションを完了するための許可を持つ IAM ロールを作成する
AWS CLI または AWS SDK を使用してライフサイクルアクションを完了するためのコールバックを送信する場合、ライフサイクルアクションを完了するためのアクセス許可を持つ IAM ロールを使用する必要があります。
**ポリシーを作成するには**
1. IAM コンソールの [[ポリシーページ](https://console.aws.amazon.com/iam/home?#/policies)] を開き、[**ポリシーの作成**] を選択します。
1. **JSON** タブを選択します。
1. **[Policy Document]** (ポリシードキュメント) ボックスで、以下のポリシードキュメントをコピーし、ボックスに貼り付けます。**sample text** を、お使いのアカウント番号と、作成する Auto Scaling グループの名前 (**TestAutoScalingEvent-group**) に置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:CompleteLifecycleAction"
],
"Resource": "arn:aws:autoscaling:*:123456789012:autoScalingGroup:*:autoScalingGroupName/TestAutoScalingEvent-group"
}
]
}
```
------
1. [**次へ**] を選択します。
1. [**ポリシー名**] に「**TestAutoScalingEvent-policy**」と入力します。[**ポリシーの作成**] を選択します。
ポリシーの作成が完了したら、それを使用するロールを作成できます。
**ロールを作成するには**
1. 左側のナビゲーションペインで、[**Roles**] を選択します。
1. [**ロールの作成**] を選択してください。
1. **[Select trusted entity]** (信頼されたエンティティの選択) で、**[AWS のサービス]** を選択します。
1. ユースケースに **[EC2]** を選択してから、**[Next]** (次へ) を選択します。
1. **[Add permissions]** (許可を追加) で、作成したポリシー (**[TestAutoScalingEvent-policy]**) を選択します。その後、**[Next]** を選択します。
1. **[Name, review, and create]** (名前、確認、および作成) ページで、**[Role name]** (ロール名) に **TestAutoScalingEvent-role** を入力し、**[Create role]** (ロールを作成) を選択します。
## ステップ 2: 起動テンプレートを作成して IAM ロールとユーザーデータスクリプトを含める
Auto Scaling グループで使用する起動テンプレートを作成します。作成した IAM ロールと、提供されたサンプルユーザーデータスクリプトを含めます。
**起動テンプレートを作成するには**
1. Amazon EC2 コンソールの[起動テンプレートページ](https://console.aws.amazon.com/ec2/v2/#LaunchTemplates)を開きます。
1. [**起動テンプレートの作成**] を選択してください。
1. [**起動テンプレート名**] を使用する場合、**TestAutoScalingEvent-template** を入力します。
1. [**Auto Scaling ガイダンス**] で、チェックボックスを選択します。
1. [**アプリケーションおよび OS イメージ (Amazon マシンイメージ)**] で、[**クイックスタート**] から Amazon Linux 2 (HVM)、SSD Volume Type、64 ビット (x86) を選択します。
1. **[Instance type]** (インスタンスタイプ) には、Amazon EC2 インスタンスのタイプ (「t2.micro」など) を選択します。
1. [**詳細設定**] を使用する場合、セクションを展開してフィールドを表示します。
1. **[IAM instance profile]** (IAM インスタンスプロファイル) で、IAM ロールの IAM インスタンスプロファイル名を選択します (**TestAutoScalingEvent-role**)。インスタンスプロファイルは IAM ロールのコンテナであり、インスタンスの起動時に Amazon EC2 インスタンスに IAM ロール情報を渡すために使用できます。
IAM コンソールを使用して IAM ロールを作成すると、コンソールが対応するロールと同じ名前を使用したインスタンスプロファイルを自動的に作成します。
1. **[User data]** (ユーザーデータ) では、以下のサンプルユーザーデータスクリプトをコピーして、フィールドに貼り付けます。のサンプルテキストを、作成する Auto Scaling グループ`group_name`の名前に置き換え、 を Auto Scaling グループで使用する `region`に置き換え AWS リージョン ます。
```
#!/bin/bash
function token {
echo "X-aws-ec2-metadata-token: $(curl -X PUT 'http://169.254.169.254/latest/api/token' -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600')"
}
function get_target_state {
echo $(curl -H "$(token)" -s http://169.254.169.254/latest/meta-data/autoscaling/target-lifecycle-state)
}
function get_instance_id {
echo $(curl -H "$(token)" -s http://169.254.169.254/latest/meta-data/instance-id)
}
function complete_lifecycle_action {
instance_id=$(get_instance_id)
group_name='TestAutoScalingEvent-group'
region='us-west-2'
echo $instance_id
echo $region
echo $(aws autoscaling complete-lifecycle-action \
--lifecycle-hook-name TestAutoScalingEvent-hook \
--auto-scaling-group-name $group_name \
--lifecycle-action-result CONTINUE \
--instance-id $instance_id \
--region $region)
}
function main {
while true
do
target_state=$(get_target_state)
if [ \"$target_state\" = \"InService\" ]; then
# Change hostname
export new_hostname="${group_name}-$instance_id"
hostname $new_hostname
# Send callback
complete_lifecycle_action
break
fi
echo $target_state
sleep 5
done
}
main
```
このシンプルなユーザーデータスクリプトは、以下を実行します。
+ インスタンスメタデータを呼び出して、インスタンスメタデータからターゲットライフサイクル状態とインスタンス ID を取得する
+ ターゲットライフサイクル状態が `InService` に変更されるまで、状態を繰り返し取得する
+ ターゲットライフサイクル状態が `InService` の場合、インスタンスのホスト名を Auto Scaling グループの名前が先頭に付加されたインスタンス ID に変更する
+ **complete-lifecycle-action** CLI コマンドを呼び出すことによってコールバックを送信し、EC2 起動プロセスを `CONTINUE` するように Amazon EC2 Auto Scaling に通知する
1. [**起動テンプレートの作成**] を選択してください。
1. 確認ページで、[**Auto Scaling グループの作成**] を選択します。
**注記**
ユーザーデータスクリプトを開発する際の参考として使用できるその他の例については、Amazon EC2 Auto Scaling の [GitHub リポジトリ](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)を参照してください。
## ステップ 3: Auto Scaling グループを作成する
起動テンプレートを作成したら、Auto Scaling グループを作成します。
**Auto Scaling グループを作成する**
1. **[Choose launch template or configuration]** (起動テンプレートまたは起動設定を選択する) ページで、**[Auto Scaling group name]** (Auto Scaling グループ名) に Auto Scaling グループの名前 (**TestAutoScalingEvent-group**) を入力します。
1. **[Next]** (次へ) を選択して、**[Choose instance launch options]** (インスタンス起動オプションを選択) ページに進みます。
1. **[Network]** (ネットワーク) で VPC を選択します。
1. **[Availability Zones and subnets]** (アベイラビリティーゾーンとサブネット) で、1 つ、または複数のアベイラビリティーゾーンから 1 つ、または複数のサブネットを選択します。
1. **[Instance type requirements]** (インスタンスタイプの要件) セクションでは、このステップを簡略化するためにデフォルト設定を使用します。(起動テンプレートを上書きしないでください。) このチュートリアルでは、起動テンプレートで指定されたインスタンスタイプを使用して、オンデマンドインスタンスを 1 つだけ起動します。
1. 画面の最下部にある **[Skip to review]** (スキップして確認) を選択します。
1. **[Review]** (確認) ページで Auto Scaling グループの詳細を確認してから、**[Create Auto Scaling group]** (Auto Scaling グループを作成) を選択します。
## ステップ 4: ライフサイクルフックを追加する
ライフサイクルアクションが完了するまでインスタンスを待機状態に維持するライフサイクルフックを追加します。
**ライフサイクルフックを追加するには**
1. Amazon EC2 コンソールで [Auto Scaling グループのページ](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)を開きます。
1. Auto Scaling グループの横にあるチェックボックスを選択します。ページの下部にスプリットペインが開きます。
1. 下部のペインで、[**Instance management (インスタンス管理)**] タブの [**Lifecycle hooks (ライフサイクルフック)**] で、[**Create lifecycle hook (ライフサイクルフックを作成)**] を選択します。
1. スケールアウト (インスタンスが起動) のライフサイクルフックを定義するには、以下を実行してください。
1. [**ライフサイクルフック名**] で、**TestAutoScalingEvent-hook**を入力します。
1. [**Lifecycle transition (ライフサイクルの移行)**] で、[**Instance launch (インスタンスの起動)**] を選択します。
1. **[Heartbeat timeout]** (ハートビートタイムアウト) に、ユーザーデータスクリプトからのコールバックを待つ秒数として **300** を入力します。
1. [**デフォルトの結果**] で、[**中止**] を選択します。フックがユーザーデータスクリプトからのコールバックを受け取ることなくタイムアウトすると、Auto Scaling グループは新しいインスタンスを終了します。
1. (オプション) **[Notification metadata]** (通知メタデータ) を空のままにしておきます。
1. **[作成]** を選択します。
## ステップ 5: 機能をテストして検証する
機能をテストするには、Auto Scaling グループの希望キャパシティを 1 つ増やすことによって Auto Scaling グループを更新します。インスタンスの起動直後にユーザーデータスクリプトが実行され、インスタンスのターゲットライフサイクル状態のチェックが開始されます。スクリプトは、ターゲットライフサイクル状態が `InService` になるとホスト名を変更し、コールバックアクションを送信します。これには通常、完了まで数秒しかかかりません。
**Auto Scaling グループのサイズを増やすには**
1. Amazon EC2 コンソールで [Auto Scaling グループのページ](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)を開きます。
1. Auto Scaling グループの横にあるチェックボックスを選択します。上部ペインの最上部の行が見えている状態で、下部ペインの詳細を確認します。
1. 下部のペインの [**詳細**] タブで、[**グループの詳細**] 、[**編集**] を順に選択します。
1. [**Desired capacity (希望するキャパシティ)**] の場合は、現在の値を 1 ずつ増やします。
1. **[更新]** を選択します。インスタンスの起動中は、上部ペインの [**Status (ステータス)**] 列に [*Updating capacity (キャパシティの更新)*] というステータスが表示されます。
希望キャパシティを増やした後で、スケーリングアクティビティの説明からインスタンスが正常に起動され、終了されていないことを確認できます。
**スケーリングを表示するには**
1. [**Auto Scaling グループ**] ページに戻り、グループを選択します。
1. [**アクティビティ**] タブの [**アクティビティ履歴**] では、[**ステータス**] 列に、Auto Scaling グループがインスタンスを正常に起動したかどうかが表示されます。
1. ユーザーデータスクリプトが失敗した場合は、タイムアウト期間が過ぎたときに、ステータスが `Canceled` のスケーリングアクティビティと、`Instance failed to complete user's Lifecycle Action: Lifecycle Action with token e85eb647-4fe0-4909-b341-a6c42EXAMPLE was abandoned: Lifecycle Action Completed with ABANDON Result` のステータスメッセージが表示されます。
## ステップ 6: クリーンアップする
このチュートリアルのために作成したリソースでの作業が完了したら、次の手順を実行してそれらを削除してください。
**ライフサイクルフックを削除するには**
1. Amazon EC2 コンソールで [Auto Scaling グループのページ](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)を開きます。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
1. [**Instance management (インスタンス管理)**] タブの [**Lifecycle hooks (ライフサイクルフック)**] で、[lifecycle hook (ライフサイクルフック)] を選択します。(`TestAutoScalingEvent-hook`)
1. **[アクション]**、**[削除]** の順に選択します。
1. 確認のために、もう一度 [**削除**] を選択します。
**起動テンプレートを削除するには**
1. Amazon EC2 コンソールの[起動テンプレートページ](https://console.aws.amazon.com/ec2/v2/#LaunchTemplates)を開きます。
1. 起動テンプレート (`TestAutoScalingEvent-template`) を選択してから、**[Actions]** (アクション)、**[Delete template]** (テンプレートを削除) の順に選択します。
1. 確認を求められたら、**Delete** を入力して指定した起動テンプレートの削除を確認し、**[Delete]** (削除) を選択します。
サンプル Auto Scaling グループでの作業が完了したら、グループを削除してください。作成した IAM ロールと許可ポリシーも削除できます。
**Auto Scaling グループを削除するには**
1. Amazon EC2 コンソールで [Auto Scaling グループのページ](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)を開きます。
1. Auto Scaling グループ (`TestAutoScalingEvent-group`) の横にあるチェックボックスをオンにして、**[Delete]** (削除) を選択します。
1. 確認を求められたら、**delete** を入力して指定された Auto Scaling グループの削除を確認し、**[Delete]** (削除) を選択します。
[**Name (名前)**] 列のロードアイコンに、Auto Scaling グループが削除されたことが示されます。インスタンスを終了してグループを削除するには数分かかります。
**IAM ロールを削除するには**
1. IAM コンソールの [[Roles (ロール)] ページ](https://console.aws.amazon.com/iam/home?#/roles)を開きます。
1. 関数のロール (`TestAutoScalingEvent-role`) を選択します。
1. **[削除]** を選択します。
1. 確認を求められたら、ロールの名前を入力し、**[Delete]** (削除) を選択します。
**IAM ポリシーを削除するには**
1. IAM コンソールの[ポリシー](https://console.aws.amazon.com/iam/home?#/policies)ページを開きます。
1. 作成したポリシーを選択します。(`TestAutoScalingEvent-policy`)
1. **[アクション]**、**[削除]** の順に選択します。
1. 確認を求められたら、ポリシーの名前を入力し、**[Delete]** (削除) を選択します。
## 関連リソース
以下の関連トピックは、インスタンスメタデータで利用可能なデータに基づいてインスタンスに対してアクションを呼び出すコードを開発する際に役立ちます。
+ [インスタンスメタデータを使用してターゲットライフサイクル状態を取得する](retrieving-target-lifecycle-state-through-imds.md). このセクションでは、インスタンスの終了など、他のユースケースのライフサイクルステータスについて説明します。
+ [ライフサイクルフックを追加する (コンソール)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-console). この手順では、スケールアウト (インスタンスの起動) とスケールイン (インスタンスの終了またはウォームプールへの復帰) の両方にライフサイクルフックを追加する方法を示します。
+ 「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータのカテゴリ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories)」 このトピックでは、EC2 インスタンスでアクションを呼び出すために使用できるインスタンスメタデータのすべてのカテゴリを一覧表示します。
Amazon EventBridge を使用して Auto Scaling グループのインスタンスで発生するイベントに基づいて Lambda 関数を呼び出すルールを作成する方法を示すチュートリアルについては、「[チュートリアル:Lambda 関数を呼び出すライフサイクルフックの設定](tutorial-lifecycle-hook-lambda.md)」を参照してください。
# チュートリアル:Lambda 関数を呼び出すライフサイクルフックの設定
この演習では、一致したときにルールターゲットとして AWS Lambda 関数を呼び出すフィルターパターンを含む Amazon EventBridge ルールを作成します。使用するフィルターパターンとサンプル関数コードを提供します。
すべてが正しく設定されると、このチュートリアルの最後に、インスタンスの起動時に Lambda 関数はカスタムアクションを実行します。カスタムアクションは、Lambda 関数に関連付けられている CloudWatch Logs ログ ストリーミングにイベントをログするだけです。
Lambda 関数もコールバックを実行して、このアクションが成功するとインスタンスのライフサイクルを続行しますが、アクションが失敗するとインスタンスは起動を中止し、終了させます。
次の図は、Lambda 関数を使用してカスタムアクションを実行する場合のスケールアウトイベントのフローをまとめたものです。インスタンスが起動した後、タイムアウトまたは Amazon EC2 Auto Scaling が続行のシグナルを受信することによってライフサイクルフックが完了するまで、インスタンスのライフサイクルは一時停止されます。
![\[Lambda 関数を使用してカスタムアクションを実行する場合のスケールアウトイベントのフロー。\]](http://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/lifecycle-hook-lambda-function.png)
**注記**
ユースケースに応じて、以下の手順に従って EventBridge ルールを作成することで、ライフサイクルフックを設定できます。または、Lambda 関数を使用して、EventBridge ルールを作成せずに、ライフサイクルフックを直接設定できます。
**Topics**
+ [前提条件](#lambda-hello-world-tutorial-prerequisites)
+ [ステップ 1: ライフサイクルアクションを完了するための許可を持つ IAM ロールを作成する](#lambda-create-iam-role)
+ [ステップ 2: Lambda 関数を作成する](#lambda-create-hello-world-function)
+ [ステップ 3: EventBridge ルールを作成する](#lambda-create-rule)
+ [ステップ 4: ライフサイクルフックを追加する](#lambda-add-lifecycle-hook)
+ [ステップ 5: イベントをテストし、検証する](#lambda-testing-hook-notifications)
+ [ステップ 6: クリーンアップする](#lambda-lifecycle-hooks-tutorial-cleanup)
+ [関連リソース](#lambda-lifecycle-hooks-tutorial-related-resources)
## 前提条件
このチュートリアルを開始する前に、Auto Scaling グループがまだない場合は、作成します。Auto Scaling グループを作成するには、Amazon EC2 コンソールで、[Auto Scaling グループのページ](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)を開き、**[Auto Scaling グループの作成]** を選択します。
## ステップ 1: ライフサイクルアクションを完了するための許可を持つ IAM ロールを作成する
Lambda 関数を作成する前に、実行ロールと許可ポリシーを作成して、Lambda がライフサイクルフックを完了できるようにする必要があります。
**ポリシーを作成するには**
1. IAM コンソールの [[ポリシーページ](https://console.aws.amazon.com/iam/home?#/policies)] を開き、[**ポリシーの作成**] を選択します。
1. **JSON** タブを選択します。
1. [**ポリシードキュメント**] ボックスに、次のポリシードキュメントを貼り付け、[**イタリック体**] のテキストはアカウント番号と Auto Scaling グループの名前に置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:CompleteLifecycleAction"
],
"Resource": "arn:aws:autoscaling:*:123456789012:autoScalingGroup:*:autoScalingGroupName/my-asg"
}
]
}
```
------
1. [**次へ**] を選択します。
1. [**ポリシー名**] に「**LogAutoScalingEvent-policy**」と入力します。[**ポリシーの作成**] を選択します。
ポリシーの作成が完了したら、それを使用するロールを作成できます。
**ロールを作成するには**
1. 左側のナビゲーションペインで、[**Roles**] を選択します。
1. [**ロールの作成**] を選択してください。
1. **[Select trusted entity]** (信頼されたエンティティの選択) で、**[AWS のサービス]** を選択します。
1. ユースケースに **[Lambda]** を選択してから、**[Next]** (次へ) を選択します。
1. **[Add permissions]** (許可を追加) で、作成したポリシー (**[LogAutoScalingEvent-policy]**) と、**[AWSLambdaBasicExecutionRole]** という名前のポリシーを選択します。その後、**[Next]** を選択します。
**注記**
**AWSLambdaBasicExecutionRole** ポリシーには、ログを CloudWatch Logs に書き込むために関数が必要とするアクセス許可があります。
1. **[Name, review, and create]** (名前、確認、および作成) ページで、**[Role name]** (ロール名) に **LogAutoScalingEvent-role** を入力し、**[Create role]** (ロールを作成) を選択します。
## ステップ 2: Lambda 関数を作成する
イベントの対象となる Lambda 関数を作成します。Node.js で記述したサンプルの Lambda 関数は、一致するイベントが Amazon EC2 Auto Scaling から出力されたときに EventBridge から呼び出されます。
**Lambda 関数を作成するには**
1. Lambda コンソールで [[Functions (関数)] ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。
1. [**関数の作成**] を選択し、[**一から作成**] を選択します。
1. [**基本的な情報**] の [**関数名**] に「**LogAutoScalingEvent**」と入力します。
1. **[ランタイム]** で **[Node.js 18.x]** を選択します。
1. スクロールして **[デフォルトの実行ロールの変更]**を選択し、**[実行ロール]** で、**[既存のロールを使用]** を選択します。
1. 既存の**[ロール]** で、**[ログ オート スケーリングイベント ロール]** を選択します。
1. 他はデフォルト値のままにしておきます。
1. **[機能の作成]**を選択します。関数のコードと設定に戻ります。
1. コンソールで `LogAutoScalingEvent` 関数を開いたまま、エディタの **[コードソース]** で、index.mjs という名前のファイルに次のサンプルコードを貼り付けます。
```
import { AutoScalingClient, CompleteLifecycleActionCommand } from "@aws-sdk/client-auto-scaling";
export const handler = async(event) => {
console.log('LogAutoScalingEvent');
console.log('Received event:', JSON.stringify(event, null, 2));
var autoscaling = new AutoScalingClient({ region: event.region });
var eventDetail = event.detail;
var params = {
AutoScalingGroupName: eventDetail['AutoScalingGroupName'], /* required */
LifecycleActionResult: 'CONTINUE', /* required */
LifecycleHookName: eventDetail['LifecycleHookName'], /* required */
InstanceId: eventDetail['EC2InstanceId'],
LifecycleActionToken: eventDetail['LifecycleActionToken']
};
var response;
const command = new CompleteLifecycleActionCommand(params);
try {
var data = await autoscaling.send(command);
console.log(data); // successful response
response = {
statusCode: 200,
body: JSON.stringify('SUCCESS'),
};
} catch (err) {
console.log(err, err.stack); // an error occurred
response = {
statusCode: 500,
body: JSON.stringify('ERROR'),
};
}
return response;
};
```
このコードは単にイベントをログに記録するので、このチュートリアルの最後に、この Lambda 関数に関連付けられている CloudWatch Logsのログ ストリーミングにイベントが表示されます。
1. **[デプロイ]** をクリックします。
## ステップ 3: EventBridge ルールを作成する
Lambda 関数を実行する EventBridge ルールの作成 EventBridge の使用に関する詳細については、「[Auto Scaling イベントの処理に EventBridge を使用する](automating-ec2-auto-scaling-with-eventbridge.md)」を参照してください。
**コンソールを使用してルールを作成するには**
1. [[EventBridge コンソール](https://console.aws.amazon.com/events/)] を開きます。
1. ナビゲーションペインで **[ルール]** を選択します。
1. **[ルールを作成]** を選択します。
1. **[Define rule detail]** (詳細の定義) で、次の操作を行います。
1. [**名前**] に**LogAutoScalingEvent-rule**と入力してください。
1. **[イベントバス]** として、**[デフォルト]** を選択してください。 AWS のサービス アカウントの がイベントを生成すると、常にアカウントのデフォルトのイベントバスに送られます。
1. **[ルールタイプ]** で、**[イベントパターンを持つルール]** を選択してください。
1. [**Next**] を選択してください。
1. **[Build event pattern]** (イベントパターンの作成) で、次の操作を行います。
1. **[Event source]** (イベントソース) で、**[AWS events or EventBridge partner events]** ( イベントまたは EventBridge パートナーイベント) を選択してください。
1. **[イベントパターン]** までスクロールして、次の操作を行います。
1.
1. **イベントソース** で **AWS のサービス** を選択してください。
1. **[AWS のサービス]** には、**[Auto Scaling]** を選択します。
1. [**イベントタイプ**] で、[**インスタンスの起動と終了**] を選択します。
1. デフォルトで、ルールはすべてのスケールインイベントまたはスケールアウトイベントに一致します。スケールアウトイベントが発生し、ライフサイクルフックに基づいてインスタンスが待機状態になったときに通知するルールを作成するには、**[Specific instance event(s)]** (特定のインスタンスイベント) を選択してから、**[EC2 Instance-launch Lifecycle Action]** (EC2 インスタンス起動ライフサイクルアクション) を選択します。
1. デフォルトでは、このルールはリージョン内のすべての Auto Scaling グループと一致します。ルールを特定の Auto Scaling グループに一致させるには、**[特定のグループ名]** を選択してグループを選択します。
1. [**次へ**] を選択します。
1. **[Select target(s)]** (ターゲットを選択) で、以下の操作を行います。
1. **[Target types]** (ターゲットタイプ) には、**[AWS のサービス]** を選択します。
1. **[Select a target]** (ターゲットを選択) では、**[Lambda function]** (Lambda 関数) を選択します。
1. **[Function]** (機能) には、**[LogAutoScalingEvent]** を選択します。
1. **[次へ]** を 2 回選択します。
1. **[Review and create]** (確認して作成) ページで、**[Create rule]** (ルールの作成) を選択します。
## ステップ 4: ライフサイクルフックを追加する
このセクションでは、Lambda が起動時にインスタンスで関数を実行できるように、ライフサイクルフックを追加します。
**ライフサイクルフックを追加するには**
1. Amazon EC2 コンソールで [Auto Scaling グループのページ](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)を開きます。
1. Auto Scaling グループの横にあるチェックボックスを選択します。ページの下部にスプリットペインが開きます。
1. 下部のペインで、[**Instance management (インスタンス管理)**] タブの [**Lifecycle hooks (ライフサイクルフック)**] で、[**Create lifecycle hook (ライフサイクルフックを作成)**] を選択します。
1. スケールアウト (インスタンスが起動) のライフサイクルフックを定義するには、以下を実行してください。
1. [**ライフサイクルフック名**] で、**LogAutoScalingEvent-hook**を入力します。
1. [**Lifecycle transition (ライフサイクルの移行)**] で、[**Instance launch (インスタンスの起動)**] を選択します。
1. [**ハートビートのタイムアウト**] で、Lambda 関数からのコールバックを待機する秒数として**300**を入力します。
1. [**デフォルトの結果**] で、[**中止**] を選択します。つまり、Lambda 関数からコールバックを受け取らずにフックがタイムアウトすると、Auto Scaling グループは新しいインスタンスを終了します。
1. （オプション）[**通知メタデータ**] を空にします。EventBridge に渡すイベントデータには、Lambda 関数を呼び出すために必要な情報がすべて含まれています。
1. **[作成]** を選択します。
## ステップ 5: イベントをテストし、検証する
イベントをテストするには、Auto Scaling グループで希望するキャパシティを 1 増やして Auto Scaling グループを更新します。Lambda 関数は、希望するキャパシティを増やしてから数秒以内に呼び出されます。
**Auto Scaling グループのサイズを増やすには**
1. Amazon EC2 コンソールで [Auto Scaling グループのページ](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)を開きます。
1. Auto Scaling グループの横にあるチェックボックスを選択すると、下部のペインに詳細が表示され、上部のペインの一番上の行が表示されます。
1. 下部のペインの [**詳細**] タブで、[**グループの詳細**] 、[**編集**] を順に選択します。
1. [**Desired capacity (希望するキャパシティ)**] の場合は、現在の値を 1 ずつ増やします。
1. **[更新]** を選択します。インスタンスの起動中は、上部ペインの [**Status (ステータス)**] 列に [*Updating capacity (キャパシティの更新)*] というステータスが表示されます。
希望するキャパシティに増やしたら、Lambda 関数が呼び出されたことを確認できます。
**Lambda 関数からの出力を表示するには**
1. Amazon CloudWatch コンソールの [[[Log groups (ロググループ)] ページ](https://console.aws.amazon.com/cloudwatch/home#logs:)] を開きます。
1. Lambda 関数 (`/aws/lambda/LogAutoScalingEvent`) のロググループの名前を選択します。
1. ライフサイクルアクションの関数によって提供されるデータを表示するログのストリーミング名を選択します。
次に、スケーリング アクティビティの説明から、インスタンスが正常に起動したことを確認できます。
**スケーリングを表示するには**
1. [**Auto Scaling グループ**] ページに戻り、グループを選択します。
1. [**アクティビティ**] タブの [**アクティビティ履歴**] では、[**ステータス**] 列に、Auto Scaling グループがインスタンスを正常に起動したかどうかが表示されます。
+ アクションが成功した場合、スケーリング アクティビティのステータスは「成功」になります。
+ 失敗した場合、数分待ってから、ステータスが「キャンセル済み」のスケーリング アクティビティが表示され、「インスタンスはユーザーのライフサイクルアクションを完了できませんでした:トークンE85EB647-4FE0-4909-B341-A6C42の例は中止されました:ライフサイクルアクションは中止された結果で完了しました」というステータスメッセージが表示されます。
**Auto Scaling グループのサイズを縮小するには**
このテスト用に起動した追加のインスタンスが必要なくなった場合は、[**詳細**] タブを開き、[**Desired capacity (希望するキャパシティ)**] を 1 減らすことができます。
## ステップ 6: クリーンアップする
このチュートリアル専用に作成したリソースで作業が完了したら、次の手順に従ってリソースを削除します。
**ライフサイクルフックを削除するには**
1. Amazon EC2 コンソールで [Auto Scaling グループのページ](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)を開きます。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
1. [**Instance management (インスタンス管理)**] タブの [**Lifecycle hooks (ライフサイクルフック)**] で、[lifecycle hook (ライフサイクルフック)] を選択します。(`LogAutoScalingEvent-hook`)
1. **[アクション]**、**[削除]** の順に選択します。
1. 確認のために、もう一度 [**削除**] を選択します。
**Amazon EventBridge ルールを削除するには**
1. Amazon EventBridge コンソールで [[Rules](https://console.aws.amazon.com/events/home?#/rules)] (ルール) ページを開きます。
1. [**Event bus (イベントバス)**] で、ルール (`Default`) に関連付けられているイベントバスを選択します。
1. `LogAutoScalingEvent-rule` ルールの横にあるチェックボックスをオンにします。
1. **[削除]** を選択します。
1. 確認を求められたら、ルールの名前を入力し、**[Delete]** (削除) を選択します。
サンプル関数の使用が終了したら、削除します。関数のログを保存するためのロググループや、作成した実行ロールや許可ポリシーも削除できます。
**Lambda 関数を削除するには**
1. Lambda コンソールで [[Functions (関数)] ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。
1. 関数 (`LogAutoScalingEvent`) を選択します。
1. **[アクション]**、**[削除]** の順に選択します。
1. 確認を求められたら、**delete** を入力して指定した関数の削除を確認し、**[Delete]** (削除) を選択します。
**ロググループを削除するには**
1. Amazon CloudWatch コンソールの [[Log groups (ロググループ)] ページ](https://console.aws.amazon.com/cloudwatch/home#logs:)を開きます。
1. 関数のロググループ (`/aws/lambda/LogAutoScalingEvent`) を選択します。
1. [**アクション**]、[**ロググループの削除**] の順にクリックします。
1. **ロググループの削除**ダイアログボックスで、[**削除**] をクリックします。
**実行ロールを削除するには**
1. IAM コンソールの [[Roles (ロール)] ページ](https://console.aws.amazon.com/iam/home?#/roles)を開きます。
1. 関数のロール (`LogAutoScalingEvent-role`) を選択します。
1. **[削除]** を選択します。
1. 確認を求められたら、ロールの名前を入力し、**[Delete]** (削除) を選択します。
**IAM ポリシーを削除するには**
1. IAM コンソールの[ポリシー](https://console.aws.amazon.com/iam/home?#/policies)ページを開きます。
1. 作成したポリシーを選択します。(`LogAutoScalingEvent-policy`)
1. **[アクション]**、**[削除]** の順に選択します。
1. 確認を求められたら、ポリシーの名前を入力し、**[Delete]** (削除) を選択します。
## 関連リソース
以下の関連トピックは、Auto Scaling グループのインスタンスに発生するイベントに基づいて EventBridge ルールを作成する際に役立ちます。
+ [Auto Scaling イベントの処理に EventBridge を使用する](automating-ec2-auto-scaling-with-eventbridge.md). このセクションでは、スケールイン用のイベントなど、他のユースケースのイベントの例を示します。
+ [ライフサイクルフックを追加する (コンソール)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-console). この手順では、スケールアウト (インスタンスの起動) とスケールイン (インスタンスの終了またはウォームプールへの復帰) の両方にライフサイクルフックを追加する方法を示します。
インスタンスメタデータサービス (IMDS) を使用してインスタンス自体からアクションを呼び出す方法を示すチュートリアルについては、「[チュートリアル: データスクリプトとインスタンスメタデータを使用してライフサイクル状態を取得する](tutorial-lifecycle-hook-instance-metadata.md)」を参照してください。
# ウォームプールを使用してブート時間が長いアプリケーションのレイテンシーを低減する
ウォームプールを使用すると、インスタンスが大量のデータをディスクに書き込む必要があるなど、起動時間が非常に長いアプリケーションのレイテンシーを低減できます。ウォームプールの使用によって、アプリケーションのパフォーマンスを向上させるために、レイテンシーを管理するために Auto Scaling グループを過剰にプロビジョニングする必要がなくなりました。詳細については、ブログ記事 [Scaling your applications faster with EC2 Auto Scaling Warm Pools](https://aws.amazon.com/blogs/compute/scaling-your-applications-faster-with-ec2-auto-scaling-warm-pools/) (EC2 Auto Scaling ウォームプールを使用してアプリケーションをより高速にスケーリングする) をご覧ください。
**重要**
必要のないときにウォームプールを作成すると、不要なコストが発生する可能性があります。最初の起動時にアプリケーションに顕著なレイテンシーの問題が発生しない場合は、おそらくウォームプールを使用する必要はありません。
**Topics**
+ [主要概念](#warm-pool-core-concepts)
+ [前提条件](#warm-pool-prerequisites)
+ [ウォームプール内のインスタンスを更新する](#update-warm-pool)
+ [関連リソース](#warm-pools-related-resources)
+ [制限事項](#warm-pools-limitations)
+ [ライフサイクルフックを使用する](warm-pool-instance-lifecycle.md)
+ [Auto Scaling グループのためにウォームプールを作成する](create-warm-pool.md)
+ [ヘルスチェックステータスを表示する](warm-pools-health-checks-monitor-view-status.md)
+ [AWS CLI ウォームプールの使用例](examples-warm-pools-aws-cli.md)
## 主要概念
開始する前に、以下の主要概念を理解してください。
**ウォームプール**
ウォームプールは、Auto Scaling グループに接続された初期化済みの EC2 インスタンスのプールです。アプリケーションがスケールアウトする必要があるときはいつでも、Auto Scaling グループはウォームプールに描画して、新しい希望する容量を満たすことができます。これにより、インスタンスがアプリケーショントラフィックを迅速化し、スケールアウトイベントへの応答を高速化できるようになります。インスタンスは、ウォームプールから離れたときに、グループの希望する容量にカウントされます。これは、*ウォームスタート*として知られています。
インスタンスがウォームプールにある間、スケーリングポリシーは、`InService` 状態のインスタンスのメトリクス値がスケーリングポリシーのアラーム上限しきい値 (ターゲット追跡スケーリングポリシーのターゲット使用率と同じ値) を超える場合のみスケールアウトします。
**ウォームプールのサイズ**
デフォルトでは、ウォームプールのサイズは、Auto Scaling グループの最大容量と希望する容量の数値の差として計算されます。例えば、Auto Scaling グループの希望する容量が 6 で、最大容量が 10 の場合、ウォームプールを最初にセットアップし、プールが初期化されるときに、ウォームプールのサイズは 4 になります。
ウォームプールの最大容量を個別に指定するには、カスタム仕様 (`MaxGroupPreparedCapacity`) オプションを使用して、グループの現在の容量を超えるカスタム値を設定します。カスタム値を指定すると、ウォームプールのサイズは、グループのカスタム値と現在希望する容量の数値の差として計算されます。たとえば、Auto Scaling グループの希望容量が 6、最大容量が 20、カスタム値が 8 である場合、初めてウォームプールをセットアップしてプールが初期化されると、ウォームプールのサイズは 2 になります。
ウォームプールを使用するコストメリットを管理するために、大きな Auto Scaling グループで作業するときは、カスタム仕様 (`MaxGroupPreparedCapacity`) オプションのみを使用する場合があります。例えば、インスタンス 1,000 個、最大容量 1,500 個 (トラフィックの急増時に追加の容量を提供するため)、およびインスタンス 100 個のウォームプールがある Auto Scaling グループは、ウォームプール内に将来使用するインスタンスを 500 個予約しておくよりも、目標の達成に役立つ場合があります。
**ウォームプールサイズの最小サイズ**
最小サイズ設定を使用して、ウォームプール内で維持するインスタンスの最小数 (`MinSize`) を静的に設定することを検討してください。デフォルトでは最小サイズは設定されていません。`MinSize` の設定は、Auto Scaling グループの希望する容量が `MaxGroupPreparedCapacity` よりも高い場合でも、ウォームプールに最小数のインスタンスが維持されるように `MaxGroupPreparedCapacity` を指定する場合に便利です。
**ウォームプールインスタンスの状態**
ウォームプール内のインスタンスは、次の 3 つの状態のいずれかで保持できます: `Stopped`、`Running`、`Hibernated`。インスタンスを`Stopped`状態で保持することは、コストを最小限に抑えるための効果的な方法です。停止したインスタンスでは、使用したボリュームとインスタンスにアタッチされた Elastic IP アドレスの分だけ料金が発生します。
または、インスタンスを `Hibernated` 状態に保持して、メモリコンテンツ (RAM) を削除せずにインスタンスを停止することができます。インスタンスが休止状態になると、RAM コンテンツを Amazon EBS ルートボリュームに保存するようオペレーティングシステムに通知されます。インスタンスを再起動すると、ルートボリュームは以前の状態に復元され、RAM コンテンツがリロードされます。インスタンスが休止状態になっている間は、RAM コンテンツのストレージ、インスタンスにアタッチされた Elastic IP アドレスなどの EBS ボリュームに対してのみ料金が発生します。
ウォームプール内のインスタンスを `Running` 状態にしておくことも可能ですが、不必要な料金の発生避けるためにも、そうしておかないことを強くお勧めします。インスタンスを停止または休止状態にしておくと、インスタンス自体のコストが削減されます。インスタンスの料金は、インスタンスが実行されている場合にのみ発生します。
**ライフサイクルフック**
[ライフサイクルフック](warm-pool-instance-lifecycle.md)を使用して、インスタンスに対してカスタムアクションを実行できるように、インスタンスを待機状態にします。カスタムアクションは、インスタンスの起動時または終了前に実行されます。
ウォームプール設定では、ライフサイクルフックは、初期化が完了するまで、スケールアウトイベント中にインスタンスが停止または休止されたり、稼働したりするのを遅延させます。ライフサイクルフックなしで Auto Scaling グループにウォームプールを追加すると、初期化の完了までに長い時間がかかるインスタンスは停止または休止状態になり、準備が整う前にスケールアウトイベントが開始する可能性があります。
**インスタンスの再利用ポリシー**
デフォルトでは、Amazon EC2 Auto Scaling は、Auto Scaling グループがスケールインするとインスタンスを終了します。次に、新しいインスタンスをウォームプールで起動し、終了したインスタンスを置換します。
置換する代わりに、インスタンスをウォームプールに戻す場合は、インスタンスの再利用ポリシーを指定します。これにより、アプリケーショントラフィックを処理するように設定されたインスタンスを再利用できます。ウォームプールが過剰プロビジョニングされないように、Amazon EC2 Auto Scaling はウォームプール内のインスタンスを終了し、その設定に基づいて、必要以上に大きくなったときにそのサイズを減らすことができます。ウォームプール内のインスタンスを終了する際に、Amazon EC2 Auto Scaling は[デフォルトの終了ポリシー](ec2-auto-scaling-termination-policies.md#default-termination-policy)を使用して、最初に終了するインスタンスを選択します。
スケールイン時にインスタンスを休止し、Auto Scaling グループに既存のインスタンスがある場合は、インスタンスの休止要件を満たしている必要があります。要件を満たしていない場合、インスタンスがウォームプールに戻ると、休止状態ではなく停止状態にフォールバックします。
現在、インスタンスの再利用ポリシーを指定できるのは、 AWS CLI または SDK のみです。この機能はコンソールからは利用できません。
## 前提条件
Auto Scaling グループのためにウォームプールを作成する前に、ライフサイクルフックを使用して新しいインスタンスを適切な初期状態で初期化する方法を決定します。
インスタンスがライフサイクルフックを理由として待機状態にあるときに、インスタンスに対してカスタムアクションを実行するには、次の 2 つのオプションがあります。
+ 起動時にインスタンスでコマンドを実行する単純なシナリオでは、Auto Scaling グループの起動テンプレートまたは起動設定の作成時にユーザーデータスクリプトを含めることができます。ユーザーデータスクリプトは、インスタンスの起動時に cloud-init により実行される通常のシェルスクリプトまたは cloud-init ディレクティブです。このスクリプトは、実行されるインスタンスの ID を使用して、インスタンスが次の状態に移行するタイミングを制御することもできます。まだそうしていない場合は、インスタンスメタデータからインスタンスのインスタンス ID を取得するためのスクリプトを更新します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータにアクセスする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html)」を参照してください。
**ヒント**
インスタンスの再起動時にユーザーデータスクリプトを実行するには、ユーザーデータを MIME マルチパート形式で指定し、ユーザーデータの `#cloud-config` セクションで以下を指定します。
```
#cloud-config
cloud_final_modules:
- [scripts-user, always]
```
+ インスタンスがウォームプールに出入りするときに AWS Lambda 何かを行うなどの高度なシナリオでは、Auto Scaling グループのライフサイクルフックを作成し、ライフサイクル通知に基づいてカスタムアクションを実行するようにターゲットサービスを設定できます。詳細については、「[サポートされている通知ターゲット](warm-pool-instance-lifecycle.md#warm-pools-supported-notification-targets)」を参照してください。
**インスタンス休止のための準備**
`Hibernated` のプール状態を使用して Auto Scaling インスタンスを準備するには、「*Amazon EC2 ユーザーガイド*」の「[休止の前提条件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html)」トピックの説明に従って、インスタンスの休止状態をサポートするように正しくセットアップされた新しい起動テンプレートまたは起動設定を作成します。次に、新しい起動テンプレートまたは起動設定を Auto Scaling グループに関連付けてインスタンスの更新を開始し、以前の起動テンプレートまたは起動設定に関連付けられているインスタンスを置換します。詳細については、「[インスタンスの更新を使用して Auto Scaling グループのインスタンスを更新する](asg-instance-refresh.md)」を参照してください。
## ウォームプール内のインスタンスを更新する
ウォームプール内のインスタンスを更新するには、新しい起動テンプレートまたは起動設定を作成し、それを Auto Scaling グループに関連付けます。新しいインスタンスは、起動テンプレートまたは起動設定で指定された新しい AMI およびその他の更新を使用して起動されますが、既存のインスタンスは影響を受けません。
新しい起動テンプレートまたは起動設定を使用する代替ウォームプールインスタンスを強制的に起動するには、インスタンスの更新を開始してグループのローリング更新を行うことができます。インスタンスの更新は、最初に`InService`インスタンスを置き換えます。その後、ウォームプール内のインスタンスが置き換えられます。詳細については、「[インスタンスの更新を使用して Auto Scaling グループのインスタンスを更新する](asg-instance-refresh.md)」を参照してください。
## 関連リソース
ウォームプールのライフサイクルフックの例については、[GitHub リポジトリ](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)にアクセスしてください。
## 制限事項
+ 混合インスタンスタイプの Auto Scaling グループにおけるウォームプールの制限:
+ ウォームプールは、重み付きの混合インスタンスグループがサポートされていません。Auto Scaling グループがインスタンスの重み付けを使用している場合、ウォームプールを追加できません。
+ ウォームプールは、混合インスタンスグループ内のスポットインスタンスをサポートしていません。混合インスタンスポリシーは、ウォームプールを使用する場合にオンデマンドインスタンスのみで設定する必要があります。
+ 休止状態の混合インスタンスグループでウォームプールを使用する場合は、起動テンプレートで `HibernationOptions` を設定する必要があります。
+ Amazon EC2 Auto Scaling は、ルートデバイスとして Amazon EBS ボリュームを持つ場合にのみ、インスタンスを `Stopped` または `Hibernated` 状態にすることができます。ルートデバイスにインスタンスストアを使用するインスタンスは停止または休止できません。
+ Amazon EC2 Auto Scaling は、「*Amazon EC2 ユーザーガイド*」の「[休止の前提条件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html)」トピックに一覧表示されているすべての要件を満たしている場合にのみ、インスタンスを `Hibernated` 状態にすることができます。
+ スケールアウトイベントがあるときにウォームプールが枯渇した場合、インスタンスは Auto Scaling グループ内に直接起動されます (*コールドスタート*)。また、アベイラビリティーゾーンが容量不足の場合にコールドスタートが発生する可能性があります。
+ ウォームプール内のインスタンスが起動プロセス中に問題に遭遇し、`InService` 状態に到達できない場合、インスタンスは起動に失敗したと見なされ、終了します。これは、容量不足エラーやその他の要因など、根本的な原因に関係なく適用されます。
+ Amazon Elastic Kubernetes Service (Amazon EKS) マネージドノードグループでウォームプールを使用しようとすると、まだ初期化中のインスタンスが Amazon EKS クラスターに登録される可能性があります。その結果、このクラスターは、インスタンスが停止または休止の準備を行っているときにインスタンスでジョブをスケジュールする場合があります。
+ 同様に、Amazon ECS クラスターでウォームプールを使用しようとすると、初期化が完了する前にインスタンスがクラスターに登録される可能性があります。この問題を解決するには、ユーザーデータに特別なエージェント設定変数が含まれる起動テンプレートまたは起動設定を設定する必要があります。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[EC2 起動タイプ用の Amazon ECS キャパシティープロバイダー](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html#using-warm-pool)」を参照してください。
# Auto Scaling グループのウォームプールでライフサイクルフックを使用する
ウォームプールのインスタンスは、移行ごとに適切なカスタムアクションを作成できるように、独自の独立したライフサイクルを維持します。このライフサイクルは、インスタンスがまだ初期化中、およびサービスを開始する前に、ターゲットサービス (Lambda 関数など) でアクションを呼び出すように設計されています。
**注記**
ライフサイクルフックと完全なライフサイクルアクションの追加と管理に使用する API オペレーションは変更されません。インスタンスのライフサイクルのみが変更されます。
ライフサイクルフック追加の詳細については、[Auto Scaling グループにライフサイクル フックを追加する](adding-lifecycle-hooks.md) を参照してください。ライフサイクルアクション完了の詳細については、[Auto Scaling グループでライフサイクルアクションを完了する](completing-lifecycle-hooks.md) を参照してください。
ウォームプールに入るインスタンスは、次のいずれかの理由でライフサイクルフックが必要になる場合があります。
+ 初期化の完了に時間がかかる AMI から EC2 インスタンスを起動する。
+ ユーザーデータスクリプトを実行して EC2 インスタンスをブートストラップする。
ウォームプールを離れるインスタンスは、次のいずれかの理由でライフサイクルフックが必要になる場合があります。
+ EC2 インスタンスの使用準備に、時間を追加することができます。例えば、インスタンスの再起動時に、アプリケーションが正常に動作する前に、開始する必要があるサービスがあるとします。
+ キャッシュデータを事前入力して、新しいサーバーが空のキャッシュで起動しないようにすることができます。
+ 新しいインスタンスをマネージドインスタンスとして設定管理サービスに登録する場合。
## ウォームプール内のインスタンスのライフサイクル状態の移行
オートスケーリングインスタンスは、ライフサイクルの一環として多くの状態に移行します。
次の図表は、ウォームプール使用時のオートスケーリング状態間の移行を示しています。
![\[ウォームプール内のインスタンスのライフサイクル状態の移行。\]](http://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/warm-pools-lifecycle-diagram.png)
¹ この状態は、ウォームプールのプール状態設定によって異なります。プール状態が `Running` に設定されている場合、この状態は代わりに `Warmed:Running` になります。プール状態が `Hibernated` に設定されている場合、この状態は代わりに `Warmed:Hibernated` になります。
ライフサイクルフックを追加するときは、次の点を考慮してください。
+ ライフサイクルフックが `autoscaling:EC2_INSTANCE_LAUNCHING` ライフサイクルアクションに対して設定されている場合、新しく起動したインスタンスは、`Warmed:Pending:Wait` 状態に達したときに一時停止してカスタムアクションを実行します。その後、インスタンスが再開して `Pending:Wait` 状態になったときに再度一時停止してカスタムアクションを実行します。
+ ライフサイクルフックが `EC2_INSTANCE_TERMINATING` ライフサイクルアクションに対して設定されている場合、終了するインスタンスは、`Terminating:Wait` 状態に達したときに一時停止してカスタムアクションを実行します。ただし、スケールインでインスタンスをウォームプールに戻すインスタンスの再使用ポリシーを指定した場合、ウォームプールに戻るインスタンスは `Warmed:Pending:Wait` 状態で一時停止して `EC2_INSTANCE_TERMINATING` ライフサイクルアクションにカスタムアクションを実行します。
+ アプリケーションの要求によってウォームプールが枯渇した場合、Amazon EC2 Auto Scaling はグループが最大容量に到達していない限り、 Auto Scaling グループでインスタンスを直接起動できます。インスタンスがグループ内で直接起動する場合、インスタンスは `Pending:Wait` 状態でのみ一時停止してカスタムアクションを実行します。
+ 次の状態に遷移するまでにインスタンスが待機状態を維持する時間を制御するには、**complete-lifecycle-action** コマンドを使用するようカスタムアクションを設定します。ライフサイクルフックを使用すると、インスタンスは、指定されたライフサイクルアクションが完了したことをユーザーが Amazon EC2 Auto Scaling に通知するか、タイムアウト期間が終了するまで (デフォルトでは 1 時間) 待機状態のままになります。
スケールアウトイベントのフローの概要を次に示します。
![\[スケールアウトイベントのフロー図。\]](http://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/warm-pools-scale-out-event-diagram.png)
インスタンスが待機状態になると、Amazon EC2 Auto Scaling は通知を送信します。これらの通知の例については、このガイドの EventBridge セクションを参照してください。詳しくは、「[ウォームプールのイベントとパターンの例](warm-pools-eventbridge-events.md)」を参照してください。
## サポートされている通知ターゲット
Amazon EC2 Auto Scaling は、ライフサイクル通知の通知ターゲットとして、次のいずれかを定義するためのサポートを提供します。
+ EventBridge ルール
+ Amazon SNS トピック
+ Amazon SQS キュー
+ AWS Lambda 関数
**重要**
起動時にインスタンスを設定するユーザーデータ (cloud-init) スクリプトが起動テンプレートまたは起動設定にある場合、起動または再起動されるインスタンスでカスタムアクションを実行するための通知を受け取る必要はありません。
次のセクションでは、通知ターゲットの設定方法について説明しているドキュメントへのリンクを示します。
**EventBridge ルール**: Amazon EC2 Auto Scaling がインスタンスを待機状態にする際にコードを実行するには、EventBridge ルールを作成し、ターゲットとして Lambda 関数を指定します。異なるライフサイクル通知に基づいて異なる Lambda 関数を呼び出すには、複数のルールを作成し、各ルールを特定のイベントパターンおよび Lambda 関数に関連付けます。詳細については、「[ウォームプールイベント向けの EventBridge ルールを作成する](warm-pool-events-eventbridge-rules.md)」を参照してください。
**Amazon SNS トピック**: インスタンスが待機状態になったときに通知を受け取るには、Amazon SNS トピックを作成し、メッセージ属性に基づいてライフサイクル通知を異なる方法で配信するように、Amazon SNS メッセージフィルタリングを設定します。詳細については、「[Amazon SNS を使用した通知の受信](prepare-for-lifecycle-notifications.md#sns-notifications)」を参照してください。
**Amazon SQS キュー**: 関連するコンシューマーがライフサイクル通知を受け取って処理できる配信ポイントを設定するには、Amazon SQS キュー、および SQS キューからのメッセージを処理するキューコンシューマーを作成します。キューコンシューマーに、メッセージ属性に基づいてライフサイクル通知を別々に処理させる場合は、特定の属性が目的の値と一致する際にメッセージを解析、処理するようにキューコンシューマーを設定する必要があります。詳細については、「[Amazon SQS を使用した通知の受信](prepare-for-lifecycle-notifications.md#sqs-notifications)」を参照してください。
**AWS Lambda 関数** — Amazon EC2 Auto Scaling がインスタンスを待機状態にしたときにカスタムコードを実行するには、通知ターゲットとして Lambda 関数を指定できます。Lambda 関数はライフサイクル通知データで呼び出されるため、インスタンス設定、アプリケーションセットアップ、他の AWS サービスとの統合などのカスタムアクションを実行できます。Auto Scaling のサービスにリンクされたロールが関数を呼び出せるように、Lambda 関数のリソースベースのポリシーを設定する必要があります。詳細については、「[通知を AWS Lambda に直接ルーティングする](prepare-for-lifecycle-notifications.md#lambda-notification)」を参照してください。
# Auto Scaling グループのためにウォームプールを作成する
このトピックでは、Auto Scaling グループのウォームプールを作成する方法について説明します。
**重要**
続行する前に、ウォームプールを作成するための[前提条件](ec2-auto-scaling-warm-pools.md#warm-pool-prerequisites)を満たし、Auto Scaling グループのためにライフサイクルフックが作成されていることを確認します。
## ウォームプールを作成する
Auto Scaling グループのためにウォームプールを作成するには、次の手順を実行します。
**ウォームプールを作成するには (コンソール)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. 既存のグループの横にあるチェックボックスをオンにします。
ページの下部に分割されたペインが開きます。
1. [**インスタンス管理**] タブを選択します。
1. [**ウォームプール**] で、**ウォームプールの作成**を選択します。
1. ウォームプールを設定するには、次の手順を実行します。
1. **ウォームプールインスタンスの状態**で、インスタンスがウォームプールに入ったときに、どの状態に移行するかを選択します。デフォルト値は `Stopped` です。
1. **最小ウォームプールサイズ**に、ウォームプールに維持するインスタンスの最小数を入力します。
1. **インスタンスの再利用** の場合、**[スケールインで再利用]** チェックボックスをオンにすると、スケールインで Auto Scaling グループのインスタンスをウォームプールに戻すことができます。
1. **[ウォームプールサイズ]** で、使用可能なオプションを 1 つ選択します。
+ **デフォルトの仕様**: ウォームプールのサイズは、Auto Scaling グループの最大容量と希望する容量の数値の差によって決まります。このオプションは、ウォームプール管理を合理化します。ウォームプールを作成すると、グループの最大容量を調整するだけで、ウォームプールのサイズを簡単に更新できます。
+ **カスタム仕様**: ウォームプールのサイズはAuto Scaling グループのカスタム値と希望する容量の数値の差によって決まります。このオプションを使用すると、グループの最大容量とは別に、ウォームプールのサイズを柔軟に管理できます。
1. **[現在の設定に基づく推定ウォームプールサイズ]** セクションを表示して、デフォルトまたはカスタム仕様がウォームプールのサイズにどのように適用されるかを確認します。ウォームプールのサイズは、Auto Scaling グループの希望する容量によって異なります。この容量は、グループがスケールすると変化します。
1. **[作成]** を選択します。
## 混合インスタンスグループでのインスタンスタイプの選択
Auto Scaling は、グループに混合インスタンスポリシーが設定されている場合、スケーリングイベント中にウォームプールに既に存在するインスタンスタイプを優先します。起動動作:
1. Auto Scaling は、ウォームプールで使用可能なインスタンスタイプを使用してインスタンスを起動しようとします。
1. ウォーム起動が失敗した場合、Auto Scaling は混合インスタンスポリシーの残りのインスタンスタイプをすべて使用してコールド起動を試みます。
**Example**
**例**
Auto Scaling グループに 10 個のインスタンスタイプを設定し、ウォームプールにそれらのインスタンスタイプが 6 個含まれているとします。スケールアウト中、Auto Scaling はまずウォームプールから 6 個のインスタンスタイプを試行します。失敗した場合、Auto Scaling はコールド起動を通じて、設定されたすべてのインスタンスタイプを試行します。
これにより、完全な混合インスタンス設定の柔軟性を維持しながら、可能な限りウォームプールのパフォーマンス上の利点を得ることができます。
## ウォームプールを削除する
ウォームプールが不要になった場合は、次の手順にしたがって削除します。
**ウォームプールを削除するには (コンソール)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. 既存のグループの横にあるチェックボックスをオンにします。
ページの下部に分割されたペインが開きます。
1. [**インスタンス管理**] タブを選択します。
1. **[Warm pool]** (ウォームプール) で、**[Actions]** (アクション)、**[Delete]** (削除) の順に選択します。
1. 確認を求めるメッセージが表示されたら、[削除] を選択してください。****
# ヘルスチェックのステータスとヘルスチェックの失敗理由を表示する
ヘルスチェックにより、Amazon EC2 Auto Scaling は、インスタンスが異常であり、終了する必要があるタイミングを判断できます。ウォームプールインスタンスが`Stopped`状態の場合、Amazon EBS が`Stopped`インスタンスの可用性を確認して、異常なインスタンスを特定します。これは、`DescribeVolumeStatus`API を使用して、インスタンスにアタッチされている EBS ボリュームのステータスを判別できます。ウォームプールインスタンスの`Running`状態では、EC2 ステータスチェックに依存して、インスタンスの健全性を判断します。ウォームプールインスタンスのヘルスチェック猶予期間はありませんが、Amazon EC2 Auto Scaling はライフサイクルフックが終了するまで、インスタンスのヘルスチェックを開始しません。
インスタンスが異常であることが判明した場合、Amazon EC2 Auto Scaling は自動的に異常インスタンスを削除し、新しいインスタンスを作成して置き換えます。インスタンスは、通常、ヘルスチェックに失敗してから数分以内に終了します。詳細については、「[ヘルスチェック不合格の理由を表示する](replace-unhealthy-instance.md)」を参照してください。
カスタムヘルスチェックもサポートされています。これは、インスタンスの状態を検出し、この情報を Amazon EC2 Auto Scaling に送信できる独自のヘルスチェックシステムがある場合に役立ちます。詳細については、「[Auto Scaling グループに対してカスタムヘルスチェックを設定する](set-up-a-custom-health-check.md)」を参照してください。
Amazon EC2 Auto Scaling コンソールで、ウォームプールインスタンスのステータス（正常または異常）を、ウォームプールインスタンスのステータスを表示できます。 AWS CLI または SDKs のいずれかを使用して、ヘルスステータスを表示することもできます。
**ウォームプールインスタンスのステータスを表示するには (コンソール)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
**[Auto Scaling groups]** (Auto Scaling グループ) ページの下部にスプリットペインが開きます。
1. [**Instance management (インスタンス管理)**] タブにある、[**Warm pool instances (ウォームプールインスタンス)**] の [**Lifecycle (ライフサイクル)**] 列にインスタンスの状態が表示されます。
-**ヘルスステータス**列には、Amazon EC2 Auto Scaling がインスタンスの健全性に対して行った評価が表示されます。
**注記**
新しいインスタンスは正常に起動します。ライフサイクルフックが終了するまで、インスタンスの健全性はチェックされません。
**ヘルスチェックの失敗の理由を表示するには (コンソール)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
**[Auto Scaling groups]** (Auto Scaling グループ) ページの下部にスプリットペインが開きます。
1. **[Activity (アクティビティ)]** タブの [**Activity history (アクティビティ履歴)**] の下の [**Status (ステータス)**] 列に、Auto Scaling グループがインスタンスを正常に起動したか、終了したかが表示されます。
正常でないインスタンスを終了した場合、**原因**列には、終了の日時、およびヘルスチェックが失敗した理由が表示されます。例えば、「2021-04-01T 21:48:35 Z で、EBS ボリュームのヘルスチェックの失敗に応じて、インスタンスがサービス停止されました」と表示されます。
**ウォームプールインスタンスのステータスを表示するには (AWS CLI)**
Auto Scaling グループのウォームプールを表示するには、以下を使用します。[describe-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-warm-pool.html)コマンドを実行します。
```
aws autoscaling describe-warm-pool --auto-scaling-group-name my-asg
```
出力例。
```
{
"WarmPoolConfiguration": {
"MinSize": 0,
"PoolState": "Stopped"
},
"Instances": [
{
"InstanceId": "i-0b5e5e7521cfaa46c",
"InstanceType": "t2.micro",
"AvailabilityZone": "us-west-2a",
"LifecycleState": "Warmed:Stopped",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-08c4cd42f320d5dcd",
"LaunchTemplateName": "my-template-for-auto-scaling",
"Version": "1"
}
},
{
"InstanceId": "i-0e21af9dcfb7aa6bf",
"InstanceType": "t2.micro",
"AvailabilityZone": "us-west-2a",
"LifecycleState": "Warmed:Stopped",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-08c4cd42f320d5dcd",
"LaunchTemplateName": "my-template-for-auto-scaling",
"Version": "1"
}
}
]
}
```
**ヘルスチェックの失敗理由を表示するには (AWS CLI)**
以下の [describe-scaling-activities](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-scaling-activities.html) コマンドを実行します。
```
aws autoscaling describe-scaling-activities --auto-scaling-group-name my-asg
```
以下に、応答の例を示します。`Description`は、Auto Scaling グループがインスタンスを終了したことを示し、`Cause`は、ヘルスチェックが失敗した理由を示します。
スケーリングアクティビティは、開始時刻順に並べられます。まだ進行中のアクティビティを最初に説明します。
```
{
"Activities": [
{
"ActivityId": "4c65e23d-a35a-4e7d-b6e4-2eaa8753dc12",
"AutoScalingGroupName": "my-asg",
"Description": "Terminating EC2 instance: i-04925c838b6438f14",
"Cause": "At 2021-04-01T21:48:35Z an instance was taken out of service in response to EBS volume health check failure.",
"StartTime": "2021-04-01T21:48:35.859Z",
"EndTime": "2021-04-01T21:49:18Z",
"StatusCode": "Successful",
"Progress": 100,
"Details": "{\"Subnet ID\":\"subnet-5ea0c127\",\"Availability Zone\":\"us-west-2a\"...}",
"AutoScalingGroupARN": "arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:283179a2-f3ce-423d-93f6-66bb518232f7:autoScalingGroupName/my-asg"
},
...
]
}
```
# を使用したウォームプールの作成と管理の例 AWS CLI
ウォームプールは、、 AWS Command Line Interface (AWS CLI) AWS マネジメントコンソール、または SDKs を使用して作成および管理できます。
次の例では、 AWS CLIを使用してウォームプールを作成、管理する方法を示します。
**Topics**
+ [例 1: インスタンスを `Stopped` 状態に保つ](#warm-pool-configuration-ex1)
+ [例 2: インスタンスを `Running` 状態に保つ](#warm-pool-configuration-ex2)
+ [例 3: インスタンスを `Hibernated` 状態に保つ](#warm-pool-configuration-ex3)
+ [例 4: スケールイン時にインスタンスをウォームプールに戻す](#warm-pool-configuration-ex4)
+ [例 5: ウォームプール内のインスタンスの最小数を指定する](#warm-pool-configuration-ex5)
+ [例 6: カスタム仕様を使用してウォームプールのサイズを定義する](#warm-pool-configuration-ex6)
+ [例 7: 絶対的なウォームプールサイズを定義する](#warm-pool-configuration-ex7)
+ [例 8: ウォームプールを削除する](#delete-warm-pool-cli)
## 例 1: インスタンスを `Stopped` 状態に保つ
以下の [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) の例では、インスタンスを `Stopped` 状態に保持するウォームプールを作成します。
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped
```
## 例 2: インスタンスを `Running` 状態に保つ
以下の [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) の例では、インスタンスを `Stopped` 状態の代わりに `Running` 状態に保持するウォームプールを作成します。
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Running
```
## 例 3: インスタンスを `Hibernated` 状態に保つ
以下の [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) の例では、インスタンスを `Stopped` 状態の代わりに `Hibernated` 状態に保持するウォームプールを作成します。これにより、メモリコンテンツ (RAM) を削除せずにインスタンスを停止できます。
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Hibernated
```
## 例 4: スケールイン時にインスタンスをウォームプールに戻す
以下の [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) の例では、インスタンスを `Stopped` 状態に保持し、`--instance-reuse-policy` オプションを含むウォームプールを作成します。インスタンスの再利用ポリシー値 `'{"ReuseOnScaleIn": true}'` は Amazon EC2 Auto Scaling に対し、Auto Scaling グループがスケールインしたときにインスタンスをウォームプールに戻すよう指示します。
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --instance-reuse-policy '{"ReuseOnScaleIn": true}'
```
## 例 5: ウォームプール内のインスタンスの最小数を指定する
以下の [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) の例では、4 つ以上のインスタンスを保持できるウォームプールを作成し、トラフィックスパイクの処理に使用可能なインスタンスを 4 つ以上保持します。
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 4
```
## 例 6: カスタム仕様を使用してウォームプールのサイズを定義する
Amazon EC2 Auto Scaling は、デフォルトでウォームプールのサイズを Auto Scaling グループの最大容量と希望する容量の数値の差として管理します。ただし、`--max-group-prepared-capacity` オプションを使用して、グループの最大容量とは別に、ウォームプールのサイズを管理できます。
次の [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) の例では、ウォームプールを作成し、ウォームプールと Auto Scaling グループの両方に同時に存在できるインスタンスの最大数を設定します。グループの希望容量が 800 の場合、このコマンドの実行後にウォームプールが初期化されると、最初のサイズは 100 になります。
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --max-group-prepared-capacity 900
```
ウォームプール内のインスタンスの最小数を維持するには、次のように、コマンドを使用して`--min-size`オプションを、含めます。
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --max-group-prepared-capacity 900 --min-size 25
```
## 例 7: 絶対的なウォームプールサイズを定義する
`--max-group-prepared-capacity` および `--min-size` オプションを同じ値に設定すると、ウォームプールは絶対サイズになります。以下の [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) の例では、10 個のインスタンスのウォームプールサイズを一定に維持するウォームプールを作成します。
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 10 --max-group-prepared-capacity 10
```
## 例 8: ウォームプールを削除する
以下の [delete-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-warm-pool.html) コマンドを使用して、ウォームプールを削除します。
```
aws autoscaling delete-warm-pool --auto-scaling-group-name my-asg
```
ウォームプールにインスタンスがある場合、またはスケーリングアクティビティが進行中の場合は、[delete-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-warm-pool.html)コマンドを`--force-delete`オプションで使用します。このオプションにより、Amazon EC2 インスタンスおよび未処理のライフサイクルアクションも終了します。
```
aws autoscaling delete-warm-pool --auto-scaling-group-name my-asg --force-delete
```
# Auto Scaling グループのゾーンシフト
ゾーンシフトは、Amazon Application Recovery Controller (ARC) の機能です。ゾーンシフトを使用すると、1 つのアクションでアベイラビリティーゾーン内のアプリケーションの障害から迅速に復旧できます。Auto Scaling グループのゾーンシフトを有効にすると、グループは ARC ゾーンシフトサービスに登録されます。その後、 AWS マネジメントコンソール、 AWS CLI、または API を使用してゾーンシフトを開始できます。Auto Scaling グループは、アクティブなゾーンシフトでアベイラビリティーゾーンを障害ありとして扱います。
## Auto Scaling グループのゾーンシフトの概念
先に進む前に、ARC ゾーンシフトとの統合に関連する以下の主要概念を理解しておく必要があります。
**ARC ゾーンシフト**
Auto Scaling は、この機能を有効にするとAuto Scaling グループを ARC ゾーンシフトに登録できます。登録後、[ARC `ListManagedResources`](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_ListManagedResources.html) API を使用してリソースを表示できます。詳細については、[「Amazon Application Recovery Controller (ARC) デベロッパーガイド」の「ARC のゾーンシフト](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html)」を参照してください。 **
**アベイラビリティーゾーンの再調整**
Auto Scaling は、各アベイラビリティーゾーンの容量のバランスを維持しようとします。アベイラビリティーゾーン間で不均衡が発生すると、Auto Scaling は自動的に不均衡の修正を試みます。詳細については、「[インスタンスの分散](auto-scaling-benefits.md#AutoScalingBehavior.Rebalancing)」を参照してください。
**動的なスケーリング**
動的スケーリングは、スケーリングポリシーで選択したメトリクスに基づいて、Auto Scaling グループの希望する容量をスケーリングします。詳細については、「[Amazon EC2 Auto Scaling の動的スケーリング](as-scale-based-on-demand.md)」を参照してください。
**ヘルスチェック**
Auto Scaling は、Auto Scaling グループ内のすべてのインスタンスのヘルスステータスを定期的にチェックして、インスタンスが実行中で良好な状態であることを確認します。異常なインスタンスが検出されると、Auto Scaling はそのインスタンスを置き換え対象としてマークします。詳細については、「[Auto Scaling グループでのインスタンスのヘルスチェック](ec2-auto-scaling-health-checks.md)」を参照してください。
**インスタンスの更新**
Auto Scaling グループのインスタンスを更新するには、インスタンスの更新を使用できます。インスタンスの更新が開始されると、Auto Scaling は Auto Scaling グループ内のすべてのインスタンスの置き換えを試みます。詳細については、「[インスタンスの更新を使用して Auto Scaling グループのインスタンスを更新する](asg-instance-refresh.md)」を参照してください。
**プリスケーリング済み**
アプリケーションの残りのアベイラビリティーゾーンに十分な容量があるため、1 つのアベイラビリティーゾーンの損失を許容できます。
**スケールアウト**
Auto Scaling グループの希望する容量を増やすと、Auto Scaling は新しい希望する容量を満たすために追加のインスタンスの起動を試みます。デフォルトでは、Auto Scaling は、Auto Scaling グループ内の有効な各アベイラビリティーゾーン間で同じ容量を維持するために、バランスの取れた方法でインスタンスを起動します。
## Auto Scaling グループのゾーンシフトの仕組み
次のアベイラビリティーゾーンを持つ Auto Scaling グループがあるとします。
+ `us-east-1a`
+ `us-east-1b`
+ `us-east-1c`
すべてのアベイラビリティーゾーンでゾーンシフトが有効になっていて、 で障害に気付`us-east-1a`いたため、ゾーンシフトをトリガーします。でゾーンシフトがトリガーされると、次の動作が発生します`us-east-1a`。
+ **スケールアウト** – Auto Scaling は、正常なアベイラビリティーゾーン (`us-east-1b` および ) ですべての新しいキャパシティーリクエストを起動します`us-east-1c`。
+ **動的スケーリング** – Auto Scaling は、スケーリングポリシーがすべてのアベイラビリティーゾーンで希望する容量を減らすのをブロックします。Auto Scaling は、スケーリングポリシーがすべてのアベイラビリティーゾーンで希望する容量を増やすのをブロックしません。
+ **インスタンスの更新** – Auto Scaling は、ゾーンシフトがアクティブの間に遅延したインスタンスの更新プロセスのタイムアウトを延長します。
次の表は、 でゾーンシフトがトリガーされたときの各オプションのヘルスチェック動作を示しています`us-east-1a`。
| アベイラビリティーゾーンのヘルスチェック動作選択の障害 | ヘルスチェックの動作 |
| --- | --- |
| 異常を置き換える | 異常と思われるインスタンスは、すべてのアベイラビリティーゾーン (`us-east-1a`、`us-east-1b`、および ) で置き換えられます`us-east-1c`。 |
| 異常を無視する | 異常と思われるインスタンスは、 `us-east-1b`と で置き換えられます`us-east-1c`。アベイラビリティーゾーンのインスタンスは、アクティブなゾーンシフト () に置き換えられません`us-east-1a`。 |
## ゾーンシフトを使用するためのベストプラクティス
ゾーンシフトを使用するときにアプリケーションの高可用性を維持するには、次のベストプラクティスをお勧めします。
+ EventBridge 通知をモニタリングして、進行中のアベイラビリティーゾーン障害イベントがあるかどうかを確認します。詳細については、「[Auto Scaling イベントの処理に EventBridge を使用する](automating-ec2-auto-scaling-with-eventbridge.md)」を参照してください。
+ 適切なしきい値を持つスケーリングポリシーを使用して、アベイラビリティーゾーンの損失を許容するのに十分な容量があることを確認します。
+ インスタンスメンテナンスポリシーを最小正常率 100 に設定します。この設定では、Auto Scaling は、新しいインスタンスが使用できるようになるのを待ってから、異常なインスタンスを終了します。
プリスケーリングされたお客様は、以下もお勧めします。
+ 障害イベント中に**異常なインスタンスを置き換える必要がないため、障害のあるアベイラビリティーゾーンのヘルスチェック動作として異常を無視**を選択します。
+ Auto Scaling グループの ARC でゾーンオートシフトを使用します。ARC のゾーンオートシフト機能を使用すると AWS 、 がアベイラビリティーゾーンの障害 AWS を検出したときに、リソースのトラフィックをアベイラビリティーゾーンから遠ざけることができます。詳細については、[「Amazon Application Recovery Controller (ARC) デベロッパーガイド」の「ARC のゾーンオートシフト](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html)」を参照してください。 **
クロスゾーン無効ロードバランサーをご利用のお客様には、以下もお勧めします。
+ アベイラビリティーゾーンディストリビューション**にのみバランス型**を使用します。
+ Auto Scaling グループとロードバランサーの両方でゾーンシフトを使用している場合は、まず Auto Scaling グループのゾーンシフトをキャンセルします。次に、キャパシティがすべてのアベイラビリティーゾーン間でバランスを取るのを待ってから、ロードバランサーのゾーンシフトをキャンセルします。
+ ゾーンシフトを有効にし、クロスゾーン無効ロードバランサーを使用すると、容量のバランスが崩れる可能性があるため、Auto Scaling には追加の検証ステップが含まれています。ベストプラクティスに従っている場合は、 AWS マネジメントコンソール チェックボックスを選択するか`CreateAutoScalingGroup`、、、または の `skip-zonal-shift-validation`フラグを使用して`UpdateAutoScalingGroup`、この可能性を確認できます`AttachTrafficSources`。
Auto Scaling グループでのゾーンシフトの使用の詳細については、[Amazon EC2 Auto Scaling でのゾーンシフトを使用した](https://aws.amazon.com/blogs/compute/using-zonal-shift-with-amazon-ec2-auto-scaling/) AWS コンピューティングブログ」を参照してください。
# AWS マネジメントコンソール または を使用してゾーンシフトを有効にする AWS CLI
ゾーンシフトを有効にするには、次のいずれかの方法を使用します。
------
#### [ Console ]
**新しいグループでゾーンシフトを有効にするには (コンソール）**
1. [起動テンプレートを使用して Auto Scaling グループを作成する](create-asg-launch-template.md) 「」の手順に従い、ステップ 10 まで手順の各ステップを完了します。
1. **他の サービスとの統合** ページで、**Application Recovery Controller (ARC) ゾーンシフト**で、チェックボックスを選択してゾーンシフトを有効にします。
1. **ヘルスチェックの動作**で、異常を無視するか、異常を置き換えるを選択します。詳細については、「[Auto Scaling グループのゾーンシフトの仕組み](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works)」を参照してください。
1. [起動テンプレートを使用して Auto Scaling グループを作成する](create-asg-launch-template.md) のステップを続行します。
------
#### [ AWS CLI ]
**新しいグループでゾーンシフトを有効にするには (AWS CLI）**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドに `--availability-zone-impairment-policy`パラメータを追加します。
`--availability-zone-impairment-policy` パラメータには 2 つのオプションがあります。
+ **ZonalShiftEnabled** – に設定すると`true`、Auto Scaling は Auto Scaling グループを ARC ゾーンシフトに登録し、ARC コンソールで[ゾーンシフトを開始、更新、またはキャンセル](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html)できます。に設定すると`false`、Auto Scaling は Auto Scaling グループを ARC ゾーンシフトから登録解除します。を に設定するには、ゾーンシフトが既に有効になっている必要があります`false`。
+ **ImpairedZoneHealthCheckBehavior** – に設定すると`replace-unhealthy`、異常なインスタンスはアベイラビリティーゾーンでアクティブなゾーンシフトに置き換えられます。に設定すると`ignore-unhealthy`、アベイラビリティーゾーンの異常なインスタンスはアクティブなゾーンシフトに置き換えられません。詳細については、「[Auto Scaling グループのゾーンシフトの仕組み](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works)」を参照してください。
次の例では、 という名前の新しい Auto Scaling グループでゾーンシフトを有効にします`my-asg`。
```
aws autoscaling create-auto-scaling-group \
--launch-template LaunchTemplateName=my-launch-template,Version='1' \
--auto-scaling-group-name my-asg \
--min-size 1 \
--max-size 10 \
--desired-capacity 5 \
--availability-zones us-east-1a us-east-1b us-east-1c \
--availability-zone-impairment-policy '{
"ZonalShiftEnabled": true,
"ImpairedZoneHealthCheckBehavior": IgnoreUnhealthy
}'
```
------
------
#### [ Console ]
**既存のグループでゾーンシフトを有効にするには (コンソール）**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。
1. 画面の上部のナビゲーションバーで、Auto Scaling グループを作した AWS リージョン を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
ページの下部にスプリットペインが開きます。
1. **統合**タブの **Application Recovery Controller (ARC) ゾーンシフト**で、**編集**を選択します。
1. ゾーンシフトを有効にするには、チェックボックスをオンにします。
1. **ヘルスチェックの動作**で、異常を無視するか、異常を置き換えるを選択します。詳細については、「[Auto Scaling グループのゾーンシフトの仕組み](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works)」を参照してください。
1. **[Update]** (更新) を選択します。
------
#### [ AWS CLI ]
**既存のグループでゾーンシフトを有効にするには (AWS CLI）**
update[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) コマンドに `--availability-zone-impairment-policy`パラメータを追加します。
`--availability-zone-impairment-policy` パラメータには 2 つのオプションがあります。
+ **ZonalShiftEnabled** – に設定すると`true`、Auto Scaling は Auto Scaling グループを ARC ゾーンシフトに登録し、ARC コンソールで[ゾーンシフトを開始、更新、またはキャンセル](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html)できます。に設定すると`false`、Auto Scaling は Auto Scaling グループを ARC ゾーンシフトから登録解除します。を に設定するには、ゾーンシフトが既に有効になっている必要があります`false`。
+ **ImpairedZoneHealthCheckBehavior** – に設定すると`replace-unhealthy`、異常なインスタンスはアベイラビリティーゾーンでアクティブなゾーンシフトに置き換えられます。に設定すると`ignore-unhealthy`、アベイラビリティーゾーンの異常なインスタンスはアクティブなゾーンシフトに置き換えられません。詳細については、「[Auto Scaling グループのゾーンシフトの仕組み](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works)」を参照してください。
次の の例では、指定された Auto Scaling グループでゾーンシフトを有効にします。
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \
--availability-zone-impairment-policy '{
"ZonalShiftEnabled": true,
"ImpairedZoneHealthCheckBehavior": IgnoreUnhealthy
}'
```
------
# Auto Scaling グループのアベイラビリティーゾーンの分散
Auto Scaling グループのアベイラビリティーゾーン戦略について説明します。
**バランシング (ベストエフォート)**
Auto Scaling は、有効なアベイラビリティーゾーン間で同じ数のインスタンスを維持します。あるアベイラビリティーゾーンで起動の試行が失敗した場合、Auto Scaling は、別の正常なアベイラビリティーゾーンでインスタンスを起動しようとします。この戦略は、アベイラビリティーゾーンの冗長性を必要とし、不均衡なグループの影響を受けないアプリケーションにおいて重要です。
**バランシング (限定)**
Auto Scaling は、有効なアベイラビリティーゾーン間で同じ数のインスタンスを維持します。アベイラビリティーゾーンで起動の試行が失敗した場合、Auto Scaling は引き続きアベイラビリティーゾーンでインスタンスを起動しようとします。この戦略は、定足数ベースのワークロードや、残りのアベイラビリティーゾーンに十分な容量があるために Auto Scaling グループがアベイラビリティーゾーンの損失を許容できる場合など、特定の要件を満たすために重要です。
アベイラビリティーゾーンのディストリビューション戦略の選択は、 の**ネットワーク**セクションにあります。 AWS マネジメントコンソール または、[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドまたは [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) コマンドを使用できます。
詳細については、「[起動テンプレートを使用して Auto Scaling グループを作成する](create-auto-scaling-groups-launch-template.md)」を参照してください。
# Auto Scaling グループからインスタンスをデタッチまたはアタッチする
Auto Scaling グループからインスタンスをデタッチできます。インスタンスがデタッチされると、そのインスタンスは独立した存在になり、独自に管理することも、属していた元のグループとは別の異なる Auto Scaling グループにアタッチすることもできます。これは、例えば、既にアプリケーションを実行している既存のインスタンスを使用してテストを実行する場合などに便利です。
このトピックでは、インスタンスをデタッチおよびアタッチする方法について説明します。インスタンスをアタッチする場合、デタッチしたインスタンスではなく既存のインスタンスを使用することもできます。
インスタンスをデタッチして同じグループに再アタッチする代わりに、スタンバイ手順を使用して、グループからインスタンスを一時的に削除することをお勧めします。詳細については、「[Auto Scaling グループからインスタンスを一時的に削除する](as-enter-exit-standby.md)」を参照してください。
**Topics**
+ [インスタンスのデタッチに関する考慮事項](#detach-instances-considerations)
+ [インスタンスのアタッチに関する考慮事項](#attach-instances-considerations)
+ [デタッチとアタッチを使用してインスタンスを別のグループに移行する](#detach-attach-instances)
## インスタンスのデタッチに関する考慮事項
インスタンスをデタッチするときは、次の点に注意してください。
+ インスタンスをデタッチできるのは、インスタンスが `InService` または `StandBy` の状態にある場合のみです。`StandBy` 状態にあるインスタンスをデタッチする場合は注意してください。`StandBy` 状態になった後にインスタンスをデタッチしようとするときに API コールに `ShouldDecrementDesiredCapacity` フラグを含めると、他のインスタンスが予期せず終了する可能性があります。
+ インスタンスをデタッチした後も、インスタンスは引き続き実行され、料金が発生します。不要な料金が発生しないように、デタッチされたインスタンスが不要になった場合は、必ず再アタッチまたは終了してください。
+ 必要なキャパシティを、デタッチするインスタンスの数だけ減らすことを選択できます。キャパシティを減らさないことを選択すると、Amazon EC2 Auto Scaling はデタッチするインスタンスに置き換わる新しいインスタンスを起動し、必要なキャパシティを維持します。
+ デタッチするインスタンスの数により Auto Scaling グループの最小キャパシティを下回る状況が発生する場合は、最小キャパシティを減らす必要があります。
+ 必要なキャパシティを減らすことなく同じアベイラビリティーゾーンから複数のインスタンスをデタッチすると、`AZRebalance` プロセスを中断しない限り、グループ自体が再調整されます。詳細については、「[Amazon EC2 Auto Scaling プロセスの中断と再開](as-suspend-resume-processes.md)」を参照してください。
+ ロードバランサーターゲットグループまたは Classic Load Balancer にアタッチした Auto Scaling グループからインスタンスをデタッチすると、インスタンスはロードバランサーから登録解除されます。ロードバランサーで Connection Draining (登録解除の遅延) が有効になっている場合、Amazon EC2 Auto Scaling は未処理のリクエストが完了するまで待機します。
## インスタンスのアタッチに関する考慮事項
インスタンスをアタッチするときは、次の点に注意してください。
+ Amazon EC2 Auto Scaling は、アタッチしたインスタンスを、グループ自体によって起動されたインスタンスと同様に扱います。つまり、アタッチしたインスタンスが選択された場合、そのインスタンスはスケールインイベント中に終了できます。サービスにリンクされたロール AWSServiceRoleForAutoScaling によって付与されるアクセス許可により、Amazon EC2 Auto Scaling はこれを行うことができます。
+ インスタンスをアタッチすると、アタッチされるインスタンスの数によって、グループの必要なキャパシティーは増加します。新しいインスタンスを追加した後の必要なキャパシティがグループの最大サイズを超える場合、インスタンスを追加でアタッチするリクエストは失敗します。
+ インスタンスをグループに追加し、アベイラビリティーゾーン間で分散が不均等になると、`AZRebalance` プロセスを中断しない限り、Amazon EC2 Auto Scaling はグループを再調整し、均等な分散を再確立します。詳細については、「[Amazon EC2 Auto Scaling プロセスの中断と再開](as-suspend-resume-processes.md)」を参照してください。
+ インスタンスをロードバランサーターゲットグループまたは Classic Load Balancer にアタッチした Auto Scaling グループにアタッチする場合、インスタンスはロードバランサーに登録されます。
アタッチするインスタンスについては、次の条件を満たす必要があります。
+ インスタンスが Amazon EC2 で `running` 状態であること。
+ インスタンスの起動に使用する AMI が引き続き存在していること。
+ インスタンスは他の Auto Scaling グループのメンバーではありません。
+ インスタンスは、Auto Scaling グループで定義されているいずれかのアベイラビリティーゾーンに起動されます。
+ Auto Scaling グループにアタッチされたロードバランサーターゲットグループまたは Classic Load Balancer がある場合は、インスタンスおよびロードバランサーは両方とも同じ VPC にある必要があります。
## デタッチとアタッチを使用してインスタンスを別のグループに移行する
次のいずれかの手順を使用して、インスタンスを Auto Scaling グループからデタッチし、別の Auto Scaling グループにアタッチします。
デタッチしたインスタンスから新しい Auto Scaling グループを作成するには、「[を使用して既存のインスタンスから Auto Scaling グループを作成する AWS CLI](create-asg-from-instance.md)」を参照してください (起動設定を作成するため、非推奨)。
------
#### [ Console ]
**Auto Scaling グループからインスタンスをデタッチするには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
ページの下部にスプリットペインが開きます。
1. [**Instance management (インスタンス管理)**] タブの [**Instances (インスタンス)**] でインスタンスを選択し、[**Actions (アクション)**]、[**Detach (デタッチ)**] の順に選択します。
1. **[インスタンスをデタッチ]** ダイアログボックスで、**[インスタンスを置き換える]** チェックボックスをオンのままにして、置換インスタンスを起動します。必要なキャパシティを減らすには、チェックボックスをオフにします。
1. 確認を求めるプロンプトが表示されたら、指定したインスタンスを Auto Scaling グループから削除することを確認するために **detach** と入力し、**[インスタンスのデタッチ]** を選択します。
インスタンスを別の Auto Scaling グループにアタッチできるようになりました。
**Auto Scaling グループにインスタンスをアタッチする方法**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. (オプション) ナビゲーションペインの [**Auto Scaling**] で、[**Auto Scaling グループ**] を選択します。Auto Scaling グループを選択し、Auto Scaling グループの最大サイズが別のインスタンスを追加できる十分な大きさであることを確認します。大きさが十分でない場合は、[**詳細**] タブで最大キャパシティーを増やします。
1. ナビゲーションペインの **[Instances]** (インスタンス) で **[Instances]** (インスタンス) を選択してから、インスタンスを選択します。
1. [**Actions**]、[**Instance Settings**]、[**Attach to Auto Scaling Group**] の順に選択します。
1. [**Attach to Auto Scaling Group (Auto Scaling Group にアタッチ)**] ページで、[**Auto Scaling group (Auto Scalingグループ)**] を選択し、[**Attach (アタッチ)**] を選択します。
1. インスタンスがこの基準を満たさない場合、エラーメッセージとその詳細が表示されます。例えば、インスタンスが Auto Scaling グループと同じアベイラビリティーゾーンにない可能性があります。**[閉じる]** を選択して、この基準を満たす Auto Scaling グループでもう一度試してください。
------
#### [ AWS CLI ]
インスタンスをデタッチおよびアタッチするには、次のコマンド例を使用します。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。
**Auto Scaling グループからインスタンスをデタッチするには**
1. 現在のインスタンスを記述するには、次の [describe-auto-scaling-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-instances.html) コマンドを使用します。
```
aws autoscaling describe-auto-scaling-instances \
--query 'AutoScalingInstances[?AutoScalingGroupName==`my-asg`]'
```
次の例は、このコマンドを実行したときに生成される出力を示しています。
グループから削除するインスタンスの ID を書き留めます。この ID は次のステップで必要になります。
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-0c20ac468fa3049e8",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-0787762faf1c28619",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-0f280a4c58d319a8a",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
}
]
}
```
1. 必要なキャパシティを減らすことなくインスタンスをデタッチするには、次の [detach-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/detach-instances.html) コマンドを使用します。
```
aws autoscaling detach-instances --instance-ids i-05b4f7d5be44822a6 \
--auto-scaling-group-name my-asg
```
インスタンスをデタッチし、必要なキャパシティを減らすには、`--should-decrement-desired-capacity` オプションを含めます。
```
aws autoscaling detach-instances --instance-ids i-05b4f7d5be44822a6 \
--auto-scaling-group-name my-asg --should-decrement-desired-capacity
```
インスタンスを別の Auto Scaling グループにアタッチできるようになりました。
**Auto Scaling グループにインスタンスをアタッチする方法**
1. インスタンスを別の Auto Scaling グループにアタッチするには、次の [attach-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/attach-instances.html) コマンドを使用します
```
aws autoscaling attach-instances --instance-ids i-05b4f7d5be44822a6 --auto-scaling-group-name my-asg-for-testing
```
1. インスタンスをアタッチした後に Auto Scaling グループのサイズを確認するには、次の [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) コマンドを使用します。
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names my-asg-for-testing
```
以下の応答例は、グループに実行中のインスタンスが 2 つあり、そのうちの 1 つはアタッチしたインスタンスであることを示しています。
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg-for-testing",
"AutoScalingGroupARN": "arn",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "2",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 2,
...
"Instances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"HealthStatus": "Healthy",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "2",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-00dcdfffdf5175890",
"InstanceType": "t3.micro",
"HealthStatus": "Healthy",
"LifecycleState": "InService"
}
],
...
}
]
}
```
------
# Auto Scaling グループからインスタンスを一時的に削除する
インスタンスを `InService` 状態から `Standby` 状態に移行でき、インスタンスを更新またはトラブルシューティングして、インスタンスをサービスに返すことができます。スタンバイ状態のインスタンスはまだ Auto Scaling グループの一部ですが、ロードバランサートラフィックをアクティブに処理しません。
この機能を使用すると、Amazon EC2 Auto Scaling がヘルスチェックの一部として、またはスケールインイベント中にインスタンスを終了することを心配することはなく、インスタンスを停止して起動したり、再起動したりできます。
例えば、起動テンプレートまたは起動設定を変更することで、Auto Scaling グループの Amazon マシンイメージ (AMI) をいつでも変更できます。Auto Scaling グループが起動する後続のインスタンスには、この AMI が使用されます。ただし、Auto Scaling グループは現在稼働中のインスタンスを更新しません。これらのインスタンスを終了し、Amazon EC2 Auto Scaling で置き換えるか、インスタンスの更新機能を使用してインスタンスを終了して置き換えることができます。または、インスタンスをスタンバイ状態にしてソフトウェアを更新し、次にインスタンスをサービスに戻すことができます。
Auto Scaling グループからインスタンスをデタッチすることは、インスタンスをスタンバイ状態にすることと似ています。インスタンスのデタッチは、インスタンスを別のグループにアタッチする場合、またはスタンドアロンの EC2 インスタンスなどのインスタンスを管理し、場合によってはインスタンスを終了する場合に便利です。詳細については、「[Auto Scaling グループからインスタンスをデタッチまたはアタッチする](ec2-auto-scaling-detach-attach-instances.md)」を参照してください。
**Topics**
+ [スタンバイ状態の仕組み](#standby-state)
+ [考慮事項](#standby-instance-considerations)
+ [スタンバイ状態のインスタンスのヘルスステータス](#standby-instance-health-status)
+ [インスタンスをスタンバイに設定して一時的に削除する](#standby-state)
## スタンバイ状態の仕組み
Auto Scaling グループからインスタンスを一時的に削除できるように、スタンバイ状態は次のように機能します:
1. ユーザーはインスタンスをスタンバイ状態にします。スタンバイ状態を終了するまで、インスタンスはこの状態のままです。
1. Auto Scaling グループにアタッチされたロードバランサーターゲットグループまたは Classic Load Balancer がある場合、インスタンスはロードバランサーから登録解除されます。Connection Draining がロードバランサーに対して有効になっている場合、Elastic Load Balancingは登録解除プロセス完了前にデフォルトで 300 秒待ちます。これは、処理中のリクエストの完了に役立ちます。
1. インスタンスを更新またはトラブルシューティングできます。
1. スタンバイ状態を終了することにより、インスタンスを稼働状態に戻します。
1. Auto Scaling グループにアタッチされたロードバランサーターゲットグループまたは Classic Load Balancer がある場合、インスタンスはロードバランサーに登録されます。
Auto Scaling グループのインスタンスのライフサイクルの詳細については、「[Amazon EC2 Auto Scaling インスタンスのライフサイクル](ec2-auto-scaling-lifecycle.md)」を参照してください。
## 考慮事項
インスタンスをスタンバイ状態に移行したり、スタンバイ状態から移行したりする際の考慮事項を次に示します。
+ インスタンスをスタンバイ状態にするとき、このオペレーションを通じて必要なキャパシティを減らすことも、同じ値を維持することもできます。
+ Auto Scaling グループの必要なキャパシティを減らさないことを選択した場合、Amazon EC2 Auto Scaling はスタンバイ状態のインスタンスを置き換えるインスタンスを起動します。その目的は、1 つ以上のインスタンスがスタンバイ状態である間にアプリケーションのキャパシティーを維持できるようにすることです。
+ Auto Scaling グループの必要なキャパシティを減らすことを選択すると、スタンバイ状態のインスタンスを置き換えるためのインスタンスを起動できなくなります。
+ インスタンスを稼働状態に戻すと、Auto Scaling グループ内のインスタンスの数を反映するために必要なキャパシティが増加します。
+ 増加 (および減少) を行うには、新しい必要なキャパシティは、最小グループサイズと最大グループサイズの間にある必要があります。それ以外の場合は、このオペレーションは失敗します。
+ インスタンスをスタンバイ状態にした後、またはスタンバイ状態を終了してインスタンスをサービスに戻した後、Auto Scaling グループがアベイラビリティーゾーン間で不均衡であることが判明した場合、Amazon EC2 Auto Scaling は、 `AZRebalance` プロセスを一時停止しない限り、アベイラビリティーゾーンのバランスを再調整して補正します。詳細については、「[Amazon EC2 Auto Scaling プロセスの中断と再開](as-suspend-resume-processes.md)」を参照してください。
+ スタンバイ状態のインスタンスに対して課金されます。
## スタンバイ状態のインスタンスのヘルスステータス
Amazon EC2 Auto Scaling はスタンバイ状態にあるインスタンスのヘルスチェックを実行しません。インスタンスがスタンバイ状態にあるとき、スタンバイ状態に移行する前の状態がヘルスステータスに反映されます。Amazon EC2 Auto Scaling は、インスタンスを稼働状態に戻すまで、インスタンスのヘルスチェックを実行しません。
例えば、正常なインスタンスをスタンバイ状態に移行して終了する場合、インスタンスは正常であると Amazon EC2 Auto Scaling がレポートし続けます。スタンバイ状態の終了済みインスタンスをサービスに戻そうとすると、Amazon EC2 Auto Scaling はインスタンスのヘルスチェックを実行し、インスタンスが終了していて異常であると判断して、代替インスタンスを起動します。詳細については、「[Auto Scaling グループでのインスタンスのヘルスチェック](ec2-auto-scaling-health-checks.md)」を参照してください。
## インスタンスをスタンバイに設定して一時的に削除する
次のいずれかの手順を使用して、インスタンスをスタンバイ状態にして一時的に使用を中止します。
------
#### [ Console ]
**インスタンスを一時的に削除するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
ページの下部にスプリットペインが開きます。
1. [**Instance management (インスタンス管理)**] タブの [**Instances (インスタンス)**] で、インスタンスを選択します。
1. [**Actions**]、[**Set to Standby**] を選択します。
1. **[スタンバイに設定]** ダイアログボックスで、**[インスタンスを置き換える]** チェックボックスをオンのままにして、置換インスタンスを起動します。必要なキャパシティを減らすには、チェックボックスをオフにします。
1. 確認を求めるプロンプトが表示されたら、指定したインスタンスを `Standby` 状態にすることを確認するために **standby** と入力し、**[スタンバイに設定]** を選択します。
1. 必要に応じてインスタンスを更新、またはトラブルシューティングできます。終了したら、インスタンスを稼働状態に戻すために次のステップに進みます。
1. インスタンスを選択し、[**Actions**]、[**Set to InService**] を選択します。[**Set to InService (InService に設定)**] ダイアログボックスで、[**Set to InService (InService に設定)**] を選択します。
------
#### [ AWS CLI ]
Auto Scaling グループからインスタンスを一時的に削除するには、次のコマンド例を使用します。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。
**インスタンスを一時的に削除するには**
1. 次の [describe-auto-scaling-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-instances.html) コマンドを使用して、更新するインスタンスを確認します。
```
aws autoscaling describe-auto-scaling-instances \
--query 'AutoScalingInstances[?AutoScalingGroupName==`my-asg`]'
```
次の例は、このコマンドを実行したときに生成される出力を示しています。
グループから削除するインスタンスの ID を書き留めます。この ID は次のステップで必要になります。
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceId": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
...
]
}
```
1. インスタンスを次の [enter-standby](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/enter-standby.html) コマンドを使用して、`Standby` 状態に移行させます。`--should-decrement-desired-capacity` オプションは、Auto Scaling グループで代わりのインスタンスが起動されないように希望するキャパシティーを減らします。
```
aws autoscaling enter-standby --instance-ids i-05b4f7d5be44822a6 \
--auto-scaling-group-name my-asg --should-decrement-desired-capacity
```
以下に、応答の例を示します。
```
{
"Activities": [
{
"ActivityId": "3b1839fe-24b0-40d9-80ae-bcd883c2be32",
"AutoScalingGroupName": "my-asg",
"Description": "Moving EC2 instance to Standby: i-05b4f7d5be44822a6",
"Cause": "At 2023-12-15T21:31:26Z instance i-05b4f7d5be44822a6 was moved to standby
in response to a user request, shrinking the capacity from 4 to 3.",
"StartTime": "2023-12-15T21:31:26.150Z",
"StatusCode": "InProgress",
"Progress": 50,
"Details": "{\"Subnet ID\":\"subnet-c934b782\",\"Availability Zone\":\"us-west-2a\"}"
}
]
}
```
1. (オプション) インスタンスが`Standby`以下の [describe-auto-scaling-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-instances.html) コマンド を使用しているか確認します。
```
aws autoscaling describe-auto-scaling-instances --instance-ids i-05b4f7d5be44822a6
```
以下に、応答の例を示します。インスタンスのステータスが `Standby` に設定されました。
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "Standby"
},
...
]
}
```
1. 必要に応じてインスタンスを更新、またはトラブルシューティングできます。終了したら、インスタンスを稼働状態に戻すために次のステップに進みます。
1. 次の [exit-standby](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/exit-standby.html) コマンドを使用してインスタンスをサービスに戻します。
```
aws autoscaling exit-standby --instance-ids i-05b4f7d5be44822a6 --auto-scaling-group-name my-asg
```
以下に、応答の例を示します。
```
{
"Activities": [
{
"ActivityId": "db12b166-cdcc-4c54-8aac-08c5935f8389",
"AutoScalingGroupName": "my-asg",
"Description": "Moving EC2 instance out of Standby: i-05b4f7d5be44822a6",
"Cause": "At 2023-12-15T21:46:14Z instance i-05b4f7d5be44822a6 was moved out of standby in
response to a user request, increasing the capacity from 3 to 4.",
"StartTime": "2023-12-15T21:46:14.678Z",
"StatusCode": "PreInService",
"Progress": 30,
"Details": "{\"Subnet ID\":\"subnet-c934b782\",\"Availability Zone\":\"us-west-2a\"}"
}
]
}
```
1. (オプション) 以下の `describe-auto-scaling-instances` コマンドを使用して、インスタンスが稼働状態に戻っていることを確認します。
```
aws autoscaling describe-auto-scaling-instances --instance-ids i-05b4f7d5be44822a6
```
以下に、応答の例を示します。インスタンスのステータスが `InService` に設定されました。
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
...
]
}
```
------
# Auto Scaling インフラストラクチャを削除する
スケーリングインフラストラクチャを完全に削除するには、次のタスクを実行します。
**Topics**
+ [Auto Scaling グループの削除](#as-shutdown-lbs-delete-asg-cli)
+ [(オプション) 起動設定の削除](#as-shutdown-lbs-delete-lc-cli)
+ [(オプション) 起動テンプレートの削除](#as-shutdown-lbs-delete-lt-cli)
+ [(オプション) ロードバランサーとターゲットグループの削除](#as-shutdown-lbs-delete-lbs-cli)
+ [(オプション) CloudWatch アラームの削除](#as-shutdown-delete-alarms-cli)
+ [Amazon EC2 Auto Scaling リソースの削除保護を設定する](resource-deletion-protection.md)
## Auto Scaling グループの削除
Auto Scaling グループを削除すると、目的の値、最小値、および最大値は 0 に設定されます。その結果、インスタンスは削除されます。インスタンスを削除すると、関連するログまたはデータ、およびインスタンスのすべてのボリュームも削除します。1 つ以上のインスタンスを終了しない場合は、Auto Scaling グループを削除する前にこれらをデタッチすることができます。グループにスケーリングポリシーがある場合、グループを削除すると、ポリシー、基盤となるアラームアクション、および関連付けられたアクションがなくなったアラームが削除されます。
**Auto Scaling グループを削除するには（コンソール）**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの隣にあるチェックボックスを選択し、[**アクション**]、[**削除**] を選択します。
1. 確認を求められたら、**delete** を入力して指定された Auto Scaling グループの削除を確認し、**[Delete]** (削除) を選択します。
**[Name (名前)]** 列のロードアイコンに、Auto Scaling グループが削除されたことが示されます。**[希望]**、**[最小]**、**[最大]** 列には、Auto Scaling グループのインスタンス数として `0` と表示されます。インスタンスを終了し、グループを削除するには数分かかります。リストを更新して、現在の状態を確認します。
**Auto Scaling グループを削除するには (AWS CLI)**
次の [delete-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-auto-scaling-group.html) コマンドを使用して Auto Scaling グループを削除します。この操作は、グループに EC2 インスタンスがある場合は機能せず、インスタンスがゼロのグループにのみ適用されます。
```
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name my-asg
```
実行中のインスタンスまたはスケーリングアクティビティがグループにある場合は、[delete-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-auto-scaling-group.html) コマンドを `--force-delete` オプションで使用します。これにより、EC2 インスタンスも終了します。Amazon EC2 Auto Scaling コンソールから Auto Scaling グループを削除すると、コンソールはこの操作を使用してすべての EC2 インスタンスを終了すると同時にグループを削除します。
```
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name my-asg --force-delete
```
## (オプション) 起動設定の削除
今後使用できるように起動設定を保存するには、このステップをスキップします。
**起動設定を削除するには (コンソール)**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. 左のナビゲーションペインの **[Auto Scaling]** で、**[Auto Scaling グループ]** を選択します。
1. ページの上部付近にある **[起動設定]** を選択します。確認を求めるプロンプトが表示されたら、**[起動設定を表示]** を選択して、**[起動設定]** ページを表示することを確認します。
1. 起動設定を選択し、[**アクション**]、[**起動設定の削除**] の順に選択します。
1. 確認を求めるメッセージが表示されたら、[削除] を選択してください。****
**起動設定を削除するには (AWS CLI)**
以下の [delete-launch-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-launch-configuration.html) コマンドを使用します。
```
aws autoscaling delete-launch-configuration --launch-configuration-name my-launch-config
```
## (オプション) 起動テンプレートの削除
起動テンプレートを削除することも、1 つの起動テンプレートバージョンを削除することもできます。起動テンプレートを削除すると、そのすべてのバージョンが削除されます。
このステップをスキップして、後で使用するために起動テンプレートを維持することもできます。
**起動テンプレートを削除するには (コンソール)**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] の [**テンプレートの起動**] を選択します。
1. 起動テンプレートを選択し、次のいずれかの操作を行います。
+ [**アクション**]、[**テンプレートの削除**] の順に選択します。確認を求められたら、**Delete** を入力して指定した起動テンプレートの削除を確認し、**[Delete]** (削除) を選択します。
+ [**アクション**]、[**Delete template version (テンプレートのバージョンの削除)**] の順に選択します。削除するバージョンを選択し、[**削除**] を選択してください。
**起動テンプレートを削除するには (AWS CLI)**
次の [delete-launch-template](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-launch-template.html) コマンドを使用して、テンプレートとそのすべてのバージョンを削除します。
```
aws ec2 delete-launch-template --launch-template-id lt-068f72b72934aff71
```
または、 [delete-launch-template-versions](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-launch-template-versions.html) コマンドを使用して特定の起動テンプレートのバージョンを削除することもできます。
```
aws ec2 delete-launch-template-versions --launch-template-id lt-068f72b72934aff71 --versions 1
```
## (オプション) ロードバランサーとターゲットグループの削除
Auto Scaling グループが Elastic Load Balancing ロードバランサーに関連付けされていない場合、または今後使用できるようにロードバランサーを維持する場合、このステップをスキップします。
**ロードバランサーを削除するには (コンソール)**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーを選択してから、[**Actions (アクション)**]、[**Delete (削除)**] の順に選択します。
1. 確認を求めるメッセージが表示されたら、[**Yes、Delete**] を選択します。
**ターゲットグループを削除するには (コンソール)**
1. ナビゲーションペインの [**ロードバランシング**] で [**ターゲットグループ**] を選択します。
1. ターゲットグループを選択し、[**Actions (アクション)**]、[**Delete (削除)**] を選択します。
1. 確認を求めるメッセージが表示されたら、[**Yes、Delete**] を選択します。
**Auto Scaling グループに関連付けられているロードバランサーを削除するには (AWS CLI)**
Application Load Balancer および Network Load Balancer では、次の [Delete-Load Balancing](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/elbv2/delete-load-balancer.html) および [delete-target-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/elbv2/delete-target-group.html) コマンドを使用します。
```
aws elbv2 delete-load-balancer --load-balancer-arn my-load-balancer-arn
aws elbv2 delete-target-group --target-group-arn my-target-group-arn
```
Classic Load Balancer を削除するには、次の [delete-load-balancer](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/elb/delete-load-balancer.html) コマンドを使用します。
```
aws elb delete-load-balancer --load-balancer-name my-load-balancer
```
## (オプション) CloudWatch アラームの削除
Auto Scaling グループに関連付けられた CloudWatch アラームを削除するには、次のステップを実行します。例えば、ステップスケーリングまたはシンプルスケーリングポリシーに関連するアラームがあるかもしれません。
**注記**
Auto Scaling グループを削除すると、Amazon EC2 Auto Scaling がターゲット追跡スケーリングポリシーのために管理する CloudWatch アラームが自動的に削除されます。
Auto Scaling グループが CloudWatch アラームに関連付けられていない場合、または今後使用できるようにアラームを維持する場合、このステップはスキップします。
**CloudWatch アラームを削除するには (コンソール)**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、[**アラーム**] を選択します。
1. アラームを選び、[**Action (アクション)**]、[**Delete (削除)**] を選択します。
1. 確認を求めるメッセージが表示されたら、[削除] を選択してください。****
**CloudWatch アラームを削除するには (AWS CLI)**
[delete-alarms](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/delete-alarms.html) コマンドを使用します。1 つ以上のアラームを一度に削除することができます。例えば、次のコマンドを使用して `Step-Scaling-AlarmHigh-AddCapacity` アラームおよび `Step-Scaling-AlarmLow-RemoveCapacity` アラームを削除します。
```
aws cloudwatch delete-alarms --alarm-name Step-Scaling-AlarmHigh-AddCapacity Step-Scaling-AlarmLow-RemoveCapacity
```
# Amazon EC2 Auto Scaling リソースの削除保護を設定する
複数の保護レイヤーを設定することで、Amazon EC2 Auto Scaling インフラストラクチャを誤って削除しないように保護します。Auto Scaling は、Auto Scaling グループと管理する Amazon EC2 インスタンスの不要なリソース削除を防ぐためのいくつかのアプローチを提供します。
**Topics**
+ [Auto Scaling グループの削除保護を設定する](#asg-deletion-protection)
+ [IAM ポリシーを使用して削除アクセス許可を制御する](#deletion-protection-iam-policies)
## Auto Scaling グループの削除保護を設定する
削除保護は、Amazon EC2 Auto Scaling グループが誤って削除されないようにするリソースレベルの設定です。削除保護を有効にすると、[DeleteAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DeleteAutoScalingGroup.html) API オペレーションが成功するのをブロックするため、Auto Scaling グループを削除する前に、まず削除保護設定をより制限の少ないレベルに更新する必要があります。
Amazon EC2 Auto Scaling は、次の 3 つのレベルの削除保護を提供します。
**なし** (デフォルト)
削除保護は有効になっていません。つまり、Auto Scaling グループは `ForceDelete`オプションを使用して、または使用せずに削除できます。`ForceDelete` を使用すると、Auto Scaling グループによって管理されるすべての Amazon EC2 インスタンスも、終了ライフサイクルフックを実行せずに強制的に終了します。
**強制削除の防止**
`ForceDelete` オプションを使用する場合、Auto Scaling グループを削除することはできません。この設定では、空の Auto Scaling グループ (インスタンスのないグループ) を削除できます。このオプションは、インスタンスの大量終了を防ぎ、空のグループのクリーンアップを許可する本稼働ワークロードに推奨されます。
**すべての削除の防止**
`ForceDelete` オプションが使用されているかどうかにかかわらず、Auto Scaling グループを削除することはできません。このオプションは、偶発的な削除に対して最も強力な保護を提供します。Auto Scaling グループを削除する前に、削除保護を明示的に無効にする必要があります。これは、ほとんどまたはまったく削除しないミッションクリティカルな Auto Scaling グループに推奨されます。
### 削除保護の仕組み
削除保護を有効にして [ DeleteAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DeleteAutoScalingGroup.html) API オペレーションを試行する場合:
1. Amazon EC2 Auto Scaling は、リクエストを処理する前に削除保護設定を検証します。
1. 設定された削除保護レベルが削除試行をブロックすると、Amazon EC2 Auto Scaling は を返します`ValidationError`。
1. Auto Scaling グループとその Amazon EC2 インスタンスは変更されません。
1. Auto Scaling グループを削除する前に、削除保護設定をより制限の少ないレベルに更新する必要があります。
削除保護は、次のような他のオペレーションを妨げません。
+ Auto Scaling グループ設定の更新。
+ 個々のインスタンスの終了。
+ スケーリングオペレーション (手動または自動）。
+ プロセスの停止または再開。
インスタンスの終了を適切に処理する方法の詳細については、「」を参照してください[インスタンスの終了を的確に処理するようにアプリケーションを設計する](gracefully-handle-instance-termination.md)。
### 削除保護を設定する
Auto Scaling グループを作成するとき、または既存の Auto Scaling グループの設定を更新するときに、削除保護を設定できます。
------
#### [ Console ]
**削除保護を使用して Auto Scaling グループを作成するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。
1. **[Auto Scaling グループの作成]** を選択します。
1. Auto Scaling グループの設定ステップを完了します。
1. **グループサイズとスケーリングの設定**ページで、**追加設定**を展開します。
1. **Auto Scaling グループの削除保護**には、必要な保護レベルを選択します。
+ **なし** - 削除保護なし (デフォルト)
+ **強制削除の防止** - 強制削除オペレーションのブロック
+ **すべての削除の防止** - すべての削除オペレーションをブロックする
1. 残りのステップを完了して、Auto Scaling グループを作成します。
**既存の Auto Scaling グループの削除保護を更新するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
1. **[Actions]**、**[Edit]** の順に選択します。
1. **追加設定**で、**Auto Scaling グループの削除保護**設定を更新します。
1. **[更新]** を選択します。
------
#### [ AWS CLI ]
**削除保護を使用して Auto Scaling グループを作成するには**
create[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) コマンドを `--deletion-protection`パラメータとともに使用します。
```
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-asg \
--launch-template LaunchTemplateName=my-template,Version='$Latest' \
--min-size 1 \
--max-size 5 \
--desired-capacity 2 \
--vpc-zone-identifier "subnet-12345678,subnet-87654321" \
--deletion-protection prevent-force-deletion
```
の有効な値`--deletion-protection`: `none` \$1 `prevent-force-deletion` \$1 `prevent-all-deletion`
**既存の Auto Scaling グループの削除保護を更新するには**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) コマンドを使用します。
```
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name my-asg \
--deletion-protection prevent-all-deletion
```
**削除保護を無効にするには**
削除保護を に設定します`none`。
```
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name my-asg \
--deletion-protection none
```
**削除保護ステータスを確認するには**
[describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) コマンドを使用します。
```
aws autoscaling describe-auto-scaling-groups \
--auto-scaling-group-names my-asg
```
------
## IAM ポリシーを使用して削除アクセス許可を制御する
AWS Identity and Access Management (IAM) ポリシーを使用して、Auto Scaling グループを削除できるユーザーとロールを制御します。IAM ベースのコントロールは、アイデンティティレベルでアクセス許可を制限することで、追加のセキュリティレイヤーを提供します。
IAM ポリシーは、次の場合に特に役立ちます。
+ Auto Scaling オペレーションへの異なるレベルのアクセスを異なるユーザーに許可します。
+ 特定のユーザーが他の Auto Scaling オペレーションを実行できる場合でも、 `ForceDelete`オプションを使用できないようにします。
+ 削除許可を特定の Auto Scaling グループに制限します。
次のポリシーは、グループにタグ `environment=development` が付けられている場合にのみ、Auto Scaling グループの削除を許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "autoscaling:DeleteAutoScalingGroup",
"Resource": "*",
"Condition": {
"StringEquals": { "aws:ResourceTag/environment": "development" }
}
}]
}
```
------
次のポリシーでは、 `autoscaling:ForceDelete`条件キーを使用して `DeleteAutoScalingGroup` API アクションへのアクセスを制御します。これにより、特定のユーザーが `ForceDelete`オペレーションを使用するのを防ぐことができます。これにより、Auto Scaling グループ内のすべての Amazon EC2 インスタンスが終了します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "autoscaling:DeleteAutoScalingGroup",
"Resource": "*",
"Condition": {
"Bool": {
"autoscaling:ForceDelete": "true"
}
}
}]
}
```
------
Auto Scaling グループへのアクセス制御で条件キーを使用していない場合は、代わりに `Resource` 要素内のリソースの ARN を指定してアクセスを制御できます。
次のポリシーは、名前が で始まる Auto Scaling グループに対してのみ、 `DeleteAutoScalingGroup` API アクションを使用するアクセス許可をユーザーに付与します`devteam-`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "autoscaling:DeleteAutoScalingGroup",
"Resource": "arn:aws:autoscaling:us-east-1:111122223333:autoScalingGroup:*:autoScalingGroupName/devteam-*"
}
]
}
```
------
複数の ARN をリストに含めて指定することもできます。UUID を含めることで、特定の Auto Scaling グループに確実にアクセス許可が付与されます。新しいグループの UUID は、同じ名前の削除済みグループの UUID とは異なります。
```
"Resource": [
"arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-1",
"arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-2",
"arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-3"
]
```
削除許可を制御するポリシーなど、Amazon EC2 Auto Scaling の IAM ポリシーのその他の例については、「」を参照してください[アイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)。