prod, stg, dev, test環境アカウントなど別のAWSアカウントにAMIを共有したいときがあると思います。

その際に、EBSストレージを暗号化しているとAMIの共有が不可能なため

今回はEBSストレージの暗号化解除方法について簡単に解説いたします。

とは言っても、以下の公式サイトの手順を確実に踏めば問題なく解除できるため

正直解説するほどのものでもないのですが、暗号化解除するにあたり詰まったことがあったため、共有いたします。

暗号化された EBS ボリュームを暗号化解除する | AWS re:Post

上記、公式手順の12番目に以下の記載があります。

「重要: データロスを防ぐために、新しいボリュームのサイズが暗号化されたボリュームのサイズよりも大きいことを確認してください。」

私は上記の注記を、「ストレージの空き容量は20GB以上あるし、別にコピー先ボリュームのストレージ容量を上げる必要もないよな」と思って、コピー元ボリュームとコピー先ボリュームを同じストレージ容量でコピーしました。

結果は悲惨なもので、コピー先ボリュームをルートボリュームとしてインスタンスを起動したところ一時的に実行中となり、エラーも出力されずにすぐさま停止が押されてしまいました。

原因調査のため仕方なくボリュームをデタッチして、再度データボリュームとしてアタッチし、/var/log/messagesなどにログが出力されていないか確認しましたが何も出力されず、

aws cliからec2 describe-instancesコマンドで、ec2 のstate reasonを確認してもクライアントからのシャットダウン要求を受け付けたとあるのみ、、

[
    {
        "Code": "Client.UserInitiatedShutdown",
        "Message": "Client.UserInitiatedShutdown: User initiated shutdown"
    }
]

今にして思えば、そもそもシステムの起動段階でこけているので、dmesgなどで起動時のログを確認するべきでしたが全く思いついておりませんでした。

長くなってしまいましたが結論どうやって解決したかというと、素直に手順に従いコピー先のボリュームのストレージ容量を増やすことで解決しました。

空き容量が大半を占めるストレージなのになぜストレージの容量を増やすことで解決されるかについて原因をまだつかめていないのですが、おそらくファイルシステムのメタデータもしくは、コピー元ボリュームは暗号化済みなので、暗号化に必要なメタデータ用の領域を確保しているが、コピー先ボリュームは非暗号化ボリュームなためその領域が存在せず、データロスになってしまい起動ができなかったのかなと考えております。

ここら辺は完全に予想なのであまり信じないでください。

ただ、運用として暗号化解除する度にストレージ容量を増やすのもおかしな話ですし、

そもそもとして空き容量がほとんどを占めるストレージなのに容量は増やしたくありません。

なので、以下のサイトなどを参考にext4のresizefsに当たる手順を行って、パーティションを縮小し、ファイルシステムレベルでのコピーを行いたいと考えてます。

How to Shrink an EBS Root Volume (XFS) on Amazon Linux 2 / 2023 | by Benedikt Langens | Medium

ストレージ容量を増やさずに暗号化解除ができたらまたこちらの記事でご報告します。

以上、ありがとうございました。