はじめに
表題にある通り、AWSから提供されているAMIをベースとして個人でAMIを作成し、そのAMIを使ってEC2(Windows Server 2019)を起動したら、IAMロールが割り当てられているにも関わらず、EC2からAWSの各サービスにアクセスできない事象が発生しました。
本記事は、現象の要因や対処等を備忘録としてまとめたものです。
問題詳細
使用したAMIの詳細
ベースとしたAMIは以下です。
Windows_Server-2019-Japanese-Full-Base-2020.12.09 - ami-027a63125bb60c403
Microsoft Windows Server 2019 with Desktop Experience Locale Japanese AMI provided by Amazon
上記AMIでEC2を起動後に個別にアプリをインストールし、AWSコンソールの「イメージを作成」で新しいAMIを作成しました。
現象内容
新しく作成したAMIを使ってEC2を立ち上げた後、EC2にログインしてAWS CLIで各種サービスにアクセスできることを確認しようとしたのですが、なぜかうまくいかず、「aws configure list」で確認すると、Access KeyやSecret Access Keyが割り当てられていない状態でした。
コンソールで見ると、ちゃんとIAMロール割りつけられているんですけどねぇ。。。
原因
違う方法でIAMのCredentialを確認してみると
いろいろ調べてもなかなか解決策が見つからずでしたが、こちらのサイトにある確認手順を試したところ、以下の結果となりました。 http://169.254.169.254 に接続できないんですねぇ。
ちなみに、Access KeyなどのCredential情報はメタデータから取得しているみたいですねぇ。勉強になります。
で、なぜ http://169.254.169.254 に接続できないのかですが、ヒント（というか答え）が別のサイトにありました。どうもルーティングテーブルがおかしくなって、 http://169.254.169.254 にアクセス出来なくなるようです。この情報を元に、こちらの環境のルーティングテーブルを確認してみました。
おかしいですねぇ。EC2は10.1.0.0/24のサブネットに配置しているので、デフォルトのルーティングはオレンジ線に表示された設定になっているのですが、169.254.169.xxx向けのルーティングはゲートウェイが10.0.24.1になっていて、デフォルトとは異なった先で、かつ、違うネットワークアドレスのゲートウェイに接続に行くような設定になっています。
とりあえずルーティングテーブルを変更
ここのサイトには、ルーティングテーブルを削除して再起動とあったのですが、とりあえず手動で再作成してみたところ、、、、
http://169.254.169.254 にアクセス出来て、Credential取れました。s3にもアクセスできました。
ここのサイトの記載にあったように、ルーティングテーブルがおかしくなっていたことが原因だったようです。
原因調査
なぜルーティングテーブルがおかしくなったのか
一応解決はしましたが、なぜルーティングテーブルがおかしくなったのかという疑問が残ります。
先程のおかしかったルーティングテーブルを再度見直してみたところ、ふと思い当たる節がありました。
0.0.0.0 0.0.0.0 10.1.0.1 10.1.0.130
169.254.169.xxx 255.255.255.255 10.0.24.1 10.1.0.130
VPC/Subnetの設定です。
AMI作成時
VPC:10.0.0.0/16
Public Subnet：10.0.24.0/24
作成したAMIを使ってEC2を起動した時
VPC:10.1.0.0/16
Public Subnet：10.1.0.0/24
おそらくですが、AMI作成時に設定されていたルーティングテーブルがそのままAMIに記録されたことよって、作成したAMIを使って別環境でEC2起動した際に、AMI作成時のルーティングテーブルがそのまま使用されて、http://169.254.169.254 に接続できなくなってしまったようです。
対処
ルーティングテーブルの削除
リンク先のサイトにもあるように、該当ルートを削除し、再起動することにより正常なルーティング情報が自動的にセットされるようなので、169.254.169.xxx向けのルーティングテーブルを全て削除した上で、AMIを作成します。
削除後のルーティングテーブルです。こんな感じですね。
この状態でAMIを作成します。
対処したAMIでEC2起動
作成したAMIでEC2を起動します。
起動後に169.254.169.xxxに接続できるか確認します。
問題なく、169.254.169.xxxに接続できました。
これで、各サービスへのアクセス権も付与されました。
結論
自分で作成したAMIを使用する場合は、ネットワーク構成に気を付けてください。
AMIを作成する場合は、いろいろなネットワーク構成を考慮して、ルーティングテーブルを削除した上で作成するのが賢明なのかもしれません。
追記(2021/04/30)
JAWS-UG 新潟 プチキャッチアップ 2021 #17に参加しまして、本記事の内容について質問させてもらったところ、以下のブログを紹介していただきました。
・Windows Server EC2インスタンスを別サブネットに移行する際に注意すべきこと
クラスメッソドさんでも注意点としてあげられていたようで、Windowsインスタンスを使用する場合は個別に注意が必要だったようです。
ブログの中にも書かれてますが、2020年7月にEC2LaunchのメジャーバージョンアップであるEC2Launch v2がリリースされたことで、本現象が解消されるそうです（EC2Launch v2がリリースされました）。ということは不具合だったのでしょうかね。。。。
改めて、EC2Launch v2を利用して検証したいと思います。
検証(2021/05/12更新)
上記追記内容について検証を行いました。
以前使用したAMIはすでに提供されなくなっていましたので、以下のAMIを使用します。
Windows_Server-2019-Japanese-Full-Base-2021.04.14 - ami-0a8f70a19608d9e8f
Microsoft Windows Server 2019 with Desktop Experience Locale Japanese AMI provided by Amazon
現象再現確認
まず、以下のVPC/Subnet環境で起動します。
VPC:10.0.0.0/16
Public Subnet：10.0.24.0/24
起動して、EC2Launchのバージョンを確認したらV1でした。これだとルーティングテーブルが固定になりますが、検証のためこのままAMIを作成します。
作成したAMIを使って、以下のVPC/Subnet環境で起動します。
VPC:10.1.0.0/16
Public Subnet：10.1.0.0/24
EC2LaunchV2への移行
リンク先のサイトの記載内容を元に、V2へバージョンアップします。
サイトには「移行ツールは、EC2Launch v1 スクリプトにリンクされているスケジュールされたタスクを検出しないため、EC2Launch v2 のタスクは自動的にセットアップされません。」と記載にがありますが、EC2Launch の設定はデフォルトのまま使用しているので、特に何も対応していません。
EC2を再起動し状態を確認します。
メタデータのアクセスが可能になり、Credentialの取得ができました。また、ルーティングテーブルもデフォルトルートと同様のゲートウェイに向いています。
以上の事から、EC2LauchV2へバージョンアップすることで、使用するネットワーク環境を気にすることなくAMIを利用することができます。