はじめに

表題にある通り、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を利用することができます。