[入門] AMIのコピーでエラーが出たら [EBS Encryption]

[入門] AMIのコピーでエラーが出たら [EBS Encryption]

Clock Icon2017.10.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちはこむろです。本日もどこにも需要がなさそうな気がする記事をあげていく所存。プログラミングはどこへ。

EBS暗号化の作業に伴い、様々なオペレーションを実行してます。その中でAMIのコピーでいくつか躓いたのでこちらに記録しておきます。

共有したAMIのコピーで失敗する

AMIはアカウントをまたいで共有することができます。通常EC2の起動に利用するのであれば、AMIの共有設定だけで問題ありません。共有したAMIからインスタンスを立ち上げることが出来ます。

しかし、共有先のアカウントでAMIの コピーをする 際には注意が必要です。権限が足りないと以下のエラーメッセージが表示されます。

スクリーンショット 2017-10-05 17.38.39

おや?AMIの共有設定が有効なのに・・・。

スクリーンショット 2017-10-05 18.42.12

Snapshotの権限を確認する

EBS BackedなAMIの場合、EBS SnapshotがAMIに紐付いています。そのため、Snapshot側にもアカウントの共有設定を行う必要があります。

スクリーンショット 2017-10-05 17.39.55

このようにSnapshot側にアカウントの共有設定がないと、件のエラーメッセージが表示されます。こちらにも共有したいアカウントの設定を行います。

スクリーンショット 2017-10-05 17.40.23

これで正常にコピーができます。良かったですね。

スクリーンショット 2017-10-05 17.41.12

おまけ

AMI共有時にここのチェックをしておけば、AMIの共有設定と共にSnapshotの共有設定も行われるのでチェックを入れて保存すれば良いようです。(チェックしておいてほしかった)

スクリーンショット 2017-10-05 18.45.50

Amazon所有のAMIはコピーできない

EB dockerで利用しているAmazonが提供するAMIをコピーしようとしたところエラーが発生しました。

Amazon所有のAMIなのでPublicイメージを検索します。

スクリーンショット 2017-10-05 17.42.50

イメージのコピーを実行します。

スクリーンショット 2017-10-05 17.43.05

あれ?確かにAMIに紐づくSnapshot IDを検索しても出てこないんですよね。

スクリーンショット 2017-10-05 17.43.09

どうやら、Amazon所有のAMIはそのままコピーして利用ができないようです。無念。

EBS暗号化の手順のために、AMIをコピー+暗号化してカスタムAMIを作成していたため、AMIがコピーできないとちょっと困ります。

じゃあどうすんの?

AMIからインスタンスは作れるので以下のような手順を踏めばカスタムAMIが手に入るようです。

  1. Amazon提供のAMIから適当なインスタンスタイプを指定してEC2インスタンスを起動する
  2. 起動したEC2インスタンスからカスタムAMIを作成する
  3. 作成したカスタムAMIをコピーして暗号化する
  4. AMI IDを指定してEBの設定を変更する

Amazon提供のAMIから適当なインスタンスタイプを指定してEC2インスタンスを起動する

AMIがコピーできないならEC2インスタンスを起動すればいいじゃない。

スクリーンショット 2017-10-05 19.06.44

起動したEC2インスタンスからカスタムAMIを作成する

起動したEC2インスタンスから、カスタムAMIを作成。これで概ね同じイメージが作成できました。

スクリーンショット 2017-10-05 19.13.05

作成したカスタムAMIをコピーして暗号化する

自己所有のカスタムAMIならばコピーは可能です。AMIをコピーして暗号化をしていきます。

スクリーンショット 2017-10-05 19.18.49

スクリーンショット 2017-10-05 19.21.32

AMI IDを指定してEBの設定を変更する

暗号化したAMIをベースとしてEBの設定を変更します。

スクリーンショット 2017-10-05 19.30.57

Volumeの設定を確認するとEBS暗号化が施されていました。 *1良かったですね。

Image 2017-10-11 17-40-35

EB Dockerの場合、 Docker環境のイメージを格納するため に /dev/xvdcz にルートボリュームとは別のボリュームがアタッチされてます。今回の手順ではルートボリュームにアタッチされているボリュームのみを暗号化しているので、厳密な意味で100%暗号化ではありません。

まとめ

普段あまりEBS-Backed AMIやEBS Snapshot等を意識することがないのですが、エラーが起きると色々と存在感を増してくる存在でした。さらにいうと、EBSの暗号化という情報自体があまりなく、細かな情報を継ぎ接ぎして何とか手順を確立するという有様でした。

  • EBS-BackedなAMIはコピーするタイミングで暗号化できる。ただし、コピー元が別アカウントの所有の場合、EBS Snapshot側にも共有設定がされてないと、コピー操作ができない。
  • Amazon所有のAMIの場合、そのままではコピーが出来ない。一度インスタンスを起動して再度AMIを作成する方法がある。
  • EB Dockerは起動元のカスタムAMI指定では、ルートボリュームとブロックデバイスの一部のみが暗号化される。イメージ保管用のボリュームはまた別に存在する。

なかなか大変だ。

参照

脚注

  1. ただし、これはAmazon管理下からはずれるイメージになるため、OSパッチ等があたらなくなり運用コストは増すことは認識が必要です。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.