[いつの間に?] Amazon提供のAMIを自分のアカウントへ直接コピーできるようになっていた

[いつの間に?] Amazon提供のAMIを自分のアカウントへ直接コピーできるようになっていた

Clock Icon2018.02.27

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

前段

こんにちは。こむろです。

AWSで構築されたシステムを運用しているとAMIをよく利用します *1。 今回は、地味ながらも個人的にはとても大きなアップデートを見つけてしまい、作業手順が大幅に短縮できたため、小躍りしながらこのエントリーを記述しました。 今まで単に気づいていなかっただけなのか、はたまたそもそも誰もこんな機能を使っていないのか、地味すぎて誰も気づかないのか、真相はわかりませんがこの改善は(個人的に)最高です。

現在担当プロジェクトでは分間数万アクセスをさばくEBアプリケーションが構築されています。この中でもAMIを当然利用しています。EBではプラットフォームに合わせて、Elasticbeanstalk用にAmazonが提供しているカスタマイズされたAMIをベースに利用する必要があります。AMIの一覧で aws-elasticbeanstalk.*docker のように検索すると、この場合はDockerプラットフォームのEB環境で利用できるAMIがズラズラと表示されています。

基本的にはEBでは特に指定しない場合、これらの最新のAMIをベースに環境が立ち上がりますが、何らかの事情で自分のAWSアカウント以下へコピーしカスタマイズしたい場合があります(暗号化とか暗号化とか暗号化とか暗号化とか)

EBで稼働しているアプリケーションが立ち上がるインスタンスのRoot VolumeにアタッチされているEBS Volumeは、通常暗号化されていません。これはインスタンスを立ち上げるベースとなっているAMIに紐づくスナップショットが暗号化されていないためです。そのため、このスナップショットを暗号化してやればよいわけです。ここではAMIに紐づくスナップショットの暗号化をここではAMIの暗号化と呼ぶことにします。

AMIの暗号化について

AMIの暗号化は、AMIのコピー時に暗号化オプションを有効化することでKMSのキーを利用した暗号化が可能です。AMIのコピーについては[EC2] カスタムAMIの活用:共有とコピーが詳しいので合わせて御覧ください。 しかしながら、EBのベースとなっているAmazonの公式AMIを自分のアカウント以下へコピーするのは結構たいへんで、以前は適当なインスタンスを立ち上げた後、AMIを再度作成する必要があるなどそれなりに面倒な作業でした。

以下がきれいな状態の暗号化AMIを手に入れるまでの手順です。

  1. Amazon提供のAMIはコピーができなかったので、t2.microなどでコピーしたいAMIから適当なインスタンスを立ち上げる
  2. 立ち上がったインスタンスから自分のアカウント配下へカスタムAMIを作成する
  3. 作成したAMIをさらにコピーし、暗号化オプションを有効にしてコピーする
  4. 暗号化AMI作成の完了

t2.microで素のAMIとは言え、インスタンスの起動には時間がかかります。さらにAMIを作成する際にも当然時間がかかります。そのため暗号化済みのカスタムAMIを手に入れるまでかなりの時間がかかっていました。

Amazon提供のAMIがコピー可能になっていた

2018/02/26諸事情からEBのDocker AMIを自分のアカウント以下へコピーするためにいつも通りインスタンスを立ち上げてコピーしようとしたところ、「さすがにできないことを前提に書くのは良くない。何事も検証が必要」とばかりに念のためコピーを実行してみました。あれ。数ヶ月前はできなかったはずなのに(自分の記憶が正しければ)

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

あっさりとコピーができました。

コピー先を指定。暗号化作業もこの通り一発。

おや・・・僕の今までの苦労は一体・・・。スナップショットが暗号化されているかを確認します。

はい。暗号化されてます。

手順を修正

暗号化済みAMIの作成手順を見直します。

  1. Amazon提供のAMIをコピーを実行する。その際に暗号化オプションを有効にする
  2. 暗号化AMI作成の完了

手順がかなり簡略化されました。余計なEC2インスタンスも建てないのでとても経済的です!

公式AMIのコピーができることによるメリット

AMIの暗号化はコピーのタイミングで実行できます。そのため、Amazonが提供している素のきれいな状態のAMIをそのままコピーできるというのは非常に効率的です。また、綺麗な状態のAMIをスナップショットとして自分のアカウント配下へコピーしカスタムAMIとして退避しておけば、万一公式のAMIの公開が中止されてしまったとしても、AMIが存在しないことに依るCloudFormationやEB、オートスケールのエラーなどが回避できるかと思います。とても地味なアップデートでしたが、個人的には作業手順と作業時間が大幅に減ったので最高にCoolな更新だと思いました。いつからこれができていたのでしょうか。

過去、AWSのサービスのここがイケてなかったんだよな、と思われていた箇所も時間が経つといつの間にか改善されていることがあります。日々の作業をルーチンワークで正確に回すのも重要ですが、こういったアップデートを取り込み、作業手順をアップデートして改善していくことでより良い作業手順となるのではないでしょうか。

参照

脚注

  1. まあ、構築でもよく利用しますね。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.