０．はじめに

Python スクリプトから CreateImage で AMI を作成し、EC2 インスタンスのバックアップを日時で取っていたんですが、AMI の作成に失敗することがあったので、サポートに確認したところ、ご回答を頂いたのでシェア。

１．経緯

Python スクリプトは、CloudWatchEvent から Lambda で定期実行していたんですが、ある日２つのインスタンスが AMI の作成に失敗し、Failed 状態になっていました。
それ以降は問題なくスクリプトが実行され AMI が作成されたのですが、Failed になっていた AMI が次の日消えていたので、サポートに確認しました。

２．原因

結論からいうと、

• Failed となった原因については、内部的な要因による一時的なエラーが発生し、EBS ボリュームのスナップショット作成に失敗していたとのこと。

また、

• Failed になった AMI が一定時間マネジメントコンソール上に表示され、その後見えなくなる挙動については、現時点での動作仕様とのこと。
  
  
  • マネジメントコンソール上に表示されている間は、その AMI の「詳細」のタブから「AMI ID」や「状態の理由」を参照することができ、それらの情報からトラブルシューティング等が可能。
  • ただし、FailedとなったAMIはご使用できないので、一定時間経過後に一覧から削除される。
  • なお、これらの挙動については現時点での動作仕様であり、将来的には変更される可能性がある。

ということでした。

※ 参考

※ 補足

補足として、以下のご説明も頂きました。

• 今回の事象のように、AMIの作成を含めたあらゆるリクエストの実行は、ネットワーク上のさまざまなコンポーネントが原因でエラーが発生する可能性がある。
  
  
• AWSでは冗長化を含めて耐障害性には十分配慮し、日々改善しているものの、一時的なエラーの発生は避けられない場合がある。
  
  
• 重要なインスタンスのAMIを作成される場合などには、リトライ処理の実施も検討するのが良いかも。
  • create-image のレスポンスとして作成した AMI の ID が取得できるので、その ID を引数に describe-images で AMI の状態 (available | pending | failed) が取得し、リトライの処理を行う。
  • create-image — AWS CLI 1.15.51 Command Reference
  • describe-import-image-tasks — AWS CLI 1.15.51 Command Reference

３．解決策

使っているスクリプトは数年動かしていて初めての失敗だったので、AMI の作成に失敗する確率は非常に低いかと思います。

ただ、
一つの失敗も許されないというのであれば、

• リトライの処理を組み込むか、
• そもそも実行する間隔を短くする

のが良いのかもしれません。

ＸＸ．まとめ

やはり何事もやってみないとわからないことが多いですね。
AWS もとにかくどんどん試してみることが大切かと。

• ※参考：
  • EC2 インスタンス (EBS) の AMI (Snapshot) 作成に関する制限について - Qiita