「非実在AMI」の可能性~You may not be permitted to view itの罠~
まさかとは思いますが、この「AMI」とは、あなたの想像上の存在に過ぎないのではないでしょうか。
▲ ネッシーだって巨大ウナギ説が出る時代
ネッシーと言う巨大生物がいたんだと夢を見る自由は許されていて欲しい、AWS事業本部のShirotaです。本当にネッシーいたんだもん！心の中には！
毎度強引な入りから始めてしまうのはもう癖です。後、結構無茶振りをしてもいらすとやにおあつらえ向きなイラストが存在しているのも大きいです。
あの画風でAWSっぽいやつも探せばありそう、と思えてしまう品揃えの豊富さには思わず舌を巻いてしまいます。
このようなメッセージをご存知だろうか
さて。皆さんは、以下のようなメッセージを見た事がありますか？
Cannot load details for ami-xxxxxxx. You may not be permitted to view it.
どこかで見た記憶があるかも、という方はこちらの画像から探してみて下さい。
▲ 見つかりましたか？
これはEC2のインスタンス一覧のページなのですが、下部にある「Description」タブの「AMI ID」に先ほどのメッセージが載っています。
▲ 普段はAMI IDが記載されているエリア
このメッセージを和訳してみると、以下のような感じになるでしょうか。
ami-xxxxxxxの詳細情報を読み込めません。あなたにはその権限が与えられていないかもしれません。
これ、どう感じましたか？
私は、このメッセージを見た時にこのように感じました。
- 権限が無いという事は、このAMIは自分が所持していないカスタムAMIなのかもしれない
- 所有元アカウントが別アカウントで、今は共有を止められてしまったから情報が見えないのでは？
先に結論を言いますと、上記の推測は間違ってはいませんでした。
ただ、 これ以外の理由でもメッセージが出てくる 事があると知りました。
今回は「 You may not be permitted to view itの罠 」と大仰に題して、このメッセージについて調べてみた事をお話し致します。
メッセージの意図を調べてみた
権限が無くなる事はマネージドAMIでもある！
このメッセージについて調べていたところ、AWS公式のユーザーガイドに以下のような記述がありました。
お客様がデフォルトで最新のセキュリティ更新を受けられるように、AWS は Windows AMI を 3 か月間使用可能にしています。新しい Windows AMI の公開から 10 日以内に、AWS は公開から 3 か月を経過した Windows AMI を非公開にします。 AMI が非公開になった後、その AMI から起動されたインスタンスをコンソールで表示すると、[AMI ID] フィールドに "ami-xxxxx の詳細をロードできません (Cannot load detail for ami-xxxxx)" と示されます。You may not be permitted to view it" と表示されます。
この場合はマネージドなWindows AMIが非公開になった為、詳細情報が読み込めなくなってしまったといった感じでしょうか。
これは元々の推測から大筋がずれていないので理解しやすいかと思います。
ただ、今回私が初めてこのメッセージを見かけたのはWindows ServerのEC2インスタンスではありませんでした。
当初の仮説についても調べてみる
実際に、アカウントAからアカウントBにAMIを共有させ、そのAMIでEC2を作成した後にアカウントAからのAMI共有を止めてみました。
▲ 共有しているAWSアカウントは無い
その後、EC2インスタンスについて確認すると例のメッセージが確認できました。
▲ 共有していたAMIのIDを確認
これで、当初考えていた「別AWSアカウントから共有されていたAMIの共有を止められた」事によっても例のメッセージが現れる事が検証できました。
閲覧権限が無い = そういった存在がある とは限らない!?
「権限が無い」ということはそもそも「 物があり、そのものに対しての権限が無い 」という事だと思っていましたが、そうとは限らない場合もあります。
Amazon Linux2のEC2インスタンスを起動し、スナップショットを作成してカスタムAMIを作成しました。
このカスタムAMIで新たにEC2インスタンスを立ち上げます。
▲ Tuxくんがいますね。かわいい
立ち上げたインスタンスでは勿論、AMI IDの情報が見られます。
▲ OSがOther Linuxになってしまうんですよね
ここで、当該のAMIを削除します。
▲ 綺麗さっぱり
再びEC2インスタンス一覧に戻ると、例のメッセージが出ていました。
▲ あ、あ、あー！
「権限が無い」というよりは、そもそも「AMIが無い」状況です。
ざっとまとめると
調べた範囲で見つけられた Cannot load details for ami-xxxxxxx. You may not be permitted to view it. が表示される状況というのは主に3つに分けられます。
- マネージドWindows AMIが公開から3ヶ月経って非公開になった
- 他アカウントから共有されていたAMIの共有が止められた
- カスタムAMIを作成し、それでEC2を立ち上げた後に削除した
「AMIが無い」という状況のリスク
さて、AMIがどういうものなのかを改めて考えてみましょう。
AWS Solutions Architect ブログのこの記述が、個人的には一番AMIについて分かり易く感じました。
AMI = 「EBS ボリュームの中のデータ(スナップショット) とインスタンスを構成する管理情報」を含む起動テンプレート
上記のようなものなので、EC2に何らかのトラブルがあった際、同じ環境(AMI)でのインスタンスの立ち上げが不可能になってしまいます。
EBSのスナップショットさえ取っていれば、そこから同じ環境に近いAMIを再作成して環境をリストアする事ができます。
この辺りの手順等に関しては弊社に様々な良エントリがあり、またそれを纏めた良エントリもありましたのでこちらを紹介させて頂きます。
「障害対応・復旧・復元」の項目に記載されているエントリをご参照下さい。
Developers.IOにある 冗長化（マルチAZ、マルチリージョン）、監視、障害対応などの記事をまとめてみた（全116個）
実際、障害が起きてしまってからスナップショットを確認して、スナップショットがあったとしたらAMIを作成して……では初動が遅れると思います。
なので、もし現状で Cannot load details for ami-xxxxxxx. You may not be permitted to view it. と表示されているEC2インスタンスをご使用中の方はそのインスタンスからAMIを取得しておく事をお勧めします。
ただし、 Windows Server の場合は、パスワード周りでつまづく可能性がありますのでカスタムAMIを取得する前には以下のブログ、公式ドキュメントを一読しておいた方が良いかなと思いました。
Amazon EC2（Windows Server 2012）の カスタムAMI の作成
AMIバックアップイメージから復元したWindows EC2インスタンスのパスワード取得について
エラーメッセージの読解は結構手強い
「非実在AMI」、とでも名付けたくなるようなAMIがそこにいない状況を一緒に見てきて貰いました。
皆さんはあのエラーメッセージを見た時、どれだけの可能性を想像する事ができましたか？
私はあのエラーメッセージを調べ、思った以上に障害時には深刻な状態に陥りそうな可能性に辿り着いた時「字面通りに捉えていたらまずかったな」と気付きました。
勿論「あぁ致命傷だ。終わったな」と感じさせてくれるエラーメッセージも怖いですが、「権限が無いだけなのか、つけてあげれば何とかなるだろうな」と気付かず死に至るようなエラーメッセージはそれ以上に怖いものです。
エラーメッセージを字面通りに捉えるな、と言ってしまうと元も子もなくなってしまうのですが、「このエラーメッセージが出る状況ってどんなものが考えられそうかな？」と立ち止まってみるだけで致命傷を避けられるようになるかもしれません。
実際に、今回困って検索をかけても全てを網羅したページが出てこなかったのでまとめてみました。
同じようなエラーメッセージが出てきて困った方の助けになりますと幸いです。
