Amazon EBS のボリュームタイプ (AWS::EC2::Volume) を更新しようとするときに発生する、CloudFormation の「Volume vol-XXXXXXXXXX cannot be modified in modification state OPTIMIZING」というエラーを解決するにはどうすればよいですか?

簡単な説明

CloudFormation スタックで EBS ボリュームを変更する際に認証情報を使用する場合、ボリュームのタイムアウト期間は約 7 時間です。代わりに AWS Identity and Access Management (IAM) サービスロール を使用してスタックを実行する場合、CloudFormation ではタイムアウト期間が 36 時間に延長されます。

注: ボリュームのタイムアウト期間は、CloudFormation を使用したボリュームの変更にのみ適用されます。タイムアウト期間は、リソースとアクションの種類によって異なります。

通常、完全に使用されている 1 テビバイト (TiB) の EBS ボリュームでは、新しいパフォーマンス設定に移行するのに約 6 時間かかります。詳細については、「Monitor the progress of volume modifications (ボリューム変更の進行状況を監視する) 」を参照してください。

重要: CloudFormation でスタックの更新をすでに開始している場合は、スタックが安定するまで約 7 時間待ってから次の手順を実行します。スタックが UPDATE_ROLLBACK_FAILED 状態になると、スタックは安定します。

解決方法

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新の AWS CLI バージョンを使用していることを確認してください。

スタックが安定するのを待ってから復旧する

次に例を示します。EBS のボリュームタイプを st1 から gp3 に変更すると、ボリュームのサイズが原因で、スタックのボリュームタイプの更新が失敗することがあります。このシナリオでは、スタック上で continue-update-rollback オペレーションを実行することで、スタックを復旧できます。復旧オペレーションでは、更新に失敗したリソースの論理 ID をスキップする必要があります。スタックは UPDATE_ROLLBACK_COMPLETE 状態になります。

AWS CLI または CloudFormation コンソールのいずれかを使用してスタックを復旧します。

AWS CLI:

aws cloudformation continue-update-rollback --stack-name your-stack-name --resources-to-skip logical-ID-of-EBS-volume

CloudFormation コンソール:

1.    CloudFormation コンソールを開きます。

2.    ナビゲーションペインで、[スタック] を選択します。

3.    [Stack name (スタック名)] 列から、UPDATE_ROLLBACK_FAILED 状態で停止しているスタックを選択します。

4.    [スタックアクション] を選択してから、[更新ロールバックを続ける] を選択します。

5.    [更新ロールバックを続ける] ダイアログボックスで、[高度なトラブルシューティング] を展開します。

6.    次に、[スキップするリソース - オプション] セクションで、スキップするリソースを選択します。

注: 更新に失敗したボリュームの論理 ID を必ず選択してください。

7.    [更新ロールバックを続ける] をクリックします。

EBS ボリュームの現在の状態に一致するようにスタックを更新する

EBS ボリュームの現在の状態に一致するようにスタックを更新する必要があります。スタックの更新によって CloudFormation テンプレートが更新され、スタックの状態が UPDATE_COMPLETE に変わります。

たとえば、ボリュームタイプ (AWS::EC2::Volume) を st1 から gp3 に変更できます。ただし gp3 への更新が Amazon EBS に正確に反映されていても、ロールバック操作のため、CloudFormation のボリュームタイプは st1 のままです。

1.    EBS ボリュームの状態を監視するには、Amazon EC2 コンソール を使用するか、次のコマンドを実行します。

aws ec2 describe-volumes-modifications --volume-ids your-volume-ID

2.    Amazon EBS でボリュームタイプが gp3 に変わったら、ボリュームタイプ (AWS::EC2::Volume) を gp3 として CloudFormation スタックを更新します。

注: ボリュームタイプを gp3 に変更すると、CloudFormation テンプレートを変更できます。次に、更新オペレーションを実行します。

3.    ドリフトの検出を使用して、EBS ボリュームのリソース (AWS::EC2::Volume) がスタックと同期していることを確認します。

重要: サービスロールを使用しない場合、またはボリュームサイズが大きい (～8 TiB) 場合、スタックの更新には 36 時間以上かかることがあります。このような場合、36 時間の安定化でサービスロールを使用した後でも、スタックの更新が失敗する可能性があります。その後、スタックが安定するまで待つ必要があります。この期間中、他のリソースタイプを変更することはできません。この問題を解決するには、以下の手順を実行します。

1.    保持 削除ポリシーを使用して、ボリュームを削除せずにスタックから EBS ボリュームを削除します。

2.    代わりに Amazon EBS コンソールを使用して、CloudFormation の外部で EBS ボリュームを更新します。

3.    EBS ボリュームをスタックにインポートし直します。

ボリュームをスタックに常に保持する場合は、ボリュームサイズがしきい値を下回るようにする必要があります。たとえば、8 TiB のデータに 64 時間かかる場合、36 時間の最大サイズを見積もり、データサイズを 4 TiB に下げることができます。このしきい値の調整を行うことで、更新が完了します。

---