個人で作成したAMIを使ってEC2(Windows)を起動したら、IAMロールが割り当てられているのに他サービスにアクセスできない事象が発生した件について

#はじめに
表題にある通り、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を作成しました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/c67d24ee-b344-241f-1b30-380462f1fa64.png)


###現象内容
新しく作成したAMIを使ってEC2を立ち上げた後、EC2にログインしてAWS CLIで各種サービスにアクセスできることを確認しようとしたのですが、なぜかうまくいかず、「aws configure list」で確認すると、Access KeyやSecret Access Keyが割り当てられていない状態でした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/15eb6fc4-a064-a3d7-4d53-9586a95783b0.png)
コンソールで見ると、ちゃんとIAMロール割りつけられているんですけどねぇ。。。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/07bf7565-92f0-7a8f-e6d9-3e18f21fddcc.png)

#原因
###違う方法でIAMのCredentialを確認してみると
いろいろ調べてもなかなか解決策が見つからずでしたが、[こちらのサイト](https://dev.classmethod.jp/articles/how-to-get-iam-role-credential-info-from-ec2-windows-instance/)にある確認手順を試したところ、以下の結果となりました。 http://169.254.169.254 に接続できないんですねぇ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/84c3171b-4d70-182b-df30-aba56084c339.png)
ちなみに、Access KeyなどのCredential情報はメタデータから取得しているみたいですねぇ。勉強になります。

で、なぜ http://169.254.169.254 に接続できないのかですが、ヒント（というか答え）が[別のサイト](https://qiita.com/fumitti/items/c529c521415310493870)にありました。どうもルーティングテーブルがおかしくなって、 http://169.254.169.254 にアクセス出来なくなるようです。この情報を元に、こちらの環境のルーティングテーブルを確認してみました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/e0a4205c-fa0b-39e8-d190-aebae92b9fe2.png)
おかしいですねぇ。EC2は10.1.0.0/24のサブネットに配置しているので、デフォルトのルーティングはオレンジ線に表示された設定になっているのですが、169.254.169.xxx向けのルーティングはゲートウェイが10.0.24.1になっていて、デフォルトとは異なった先で、かつ、違うネットワークアドレスのゲートウェイに接続に行くような設定になっています。

###とりあえずルーティングテーブルを変更
[ここのサイト](https://dev.classmethod.jp/articles/how-to-get-iam-role-credential-info-from-ec2-windows-instance/)には、ルーティングテーブルを削除して再起動とあったのですが、とりあえず手動で再作成してみたところ、、、、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/b3a125e6-ece5-de41-31dc-045e8b9f942b.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/88ebbc74-b397-911d-186e-fc5a77bb463d.png)
http://169.254.169.254 にアクセス出来て、Credential取れました。s3にもアクセスできました。
[ここのサイト](https://dev.classmethod.jp/articles/how-to-get-iam-role-credential-info-from-ec2-windows-instance/)の記載にあったように、ルーティングテーブルがおかしくなっていたことが原因だったようです。


#原因調査
###なぜルーティングテーブルがおかしくなったのか
一応解決はしましたが、なぜルーティングテーブルがおかしくなったのかという疑問が残ります。
先程のおかしかったルーティングテーブルを再度見直してみたところ、ふと思い当たる節がありました。

&nbsp;&nbsp;&nbsp; 0.0.0.0&nbsp;&nbsp;&nbsp;0.0.0.0&nbsp;&nbsp;&nbsp;**10.1.0.1**&nbsp;&nbsp;&nbsp;10.1.0.130
&nbsp;&nbsp;&nbsp; 169.254.169.xxx&nbsp;&nbsp;&nbsp;255.255.255.255&nbsp;&nbsp;&nbsp;**10.0.24.1**&nbsp;&nbsp;&nbsp;10.1.0.130  

VPC/Subnetの設定です。

**AMI作成時**
 VPC:10.0.0.0/16
 Public Subnet：10.0.24.0/24
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/18451efd-3b83-a422-a8eb-30fe3be564c1.png)

**作成したAMIを使ってEC2を起動した時**
 VPC:10.1.0.0/16
 Public Subnet：10.1.0.0/24
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/2f4e1513-fe49-909f-5f14-21a557ea86d2.png)

おそらくですが、AMI作成時に設定されていたルーティングテーブルがそのままAMIに記録されたことよって、作成したAMIを使って別環境でEC2起動した際に、AMI作成時のルーティングテーブルがそのまま使用されて、http://169.254.169.254 に接続できなくなってしまったようです。


#対処
###ルーティングテーブルの削除
[リンク先のサイト](https://dev.classmethod.jp/articles/how-to-get-iam-role-credential-info-from-ec2-windows-instance/)にもあるように、該当ルートを削除し、再起動することにより正常なルーティング情報が自動的にセットされるようなので、169.254.169.xxx向けのルーティングテーブルを全て削除した上で、AMIを作成します。
削除後のルーティングテーブルです。こんな感じですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/b7bf1529-3651-9938-805a-ff305f0e9bee.png)
この状態でAMIを作成します。

###対処したAMIでEC2起動
作成したAMIでEC2を起動します。
起動後に169.254.169.xxxに接続できるか確認します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/a3b374a4-9727-2b7c-5b09-af0adad1df94.png)

問題なく、169.254.169.xxxに接続できました。
これで、各サービスへのアクセス権も付与されました。

#結論
自分で作成したAMIを使用する場合は、ネットワーク構成に気を付けてください。
AMIを作成する場合は、いろいろなネットワーク構成を考慮して、ルーティングテーブルを削除した上で作成するのが賢明なのかもしれません。
##追記(2021/04/30)
[JAWS-UG 新潟 プチキャッチアップ 2021 #17](https://jawsug-niigata.connpass.com/event/211458/)に参加しまして、本記事の内容について質問させてもらったところ、以下のブログを紹介していただきました。
・[Windows Server EC2インスタンスを別サブネットに移行する際に注意すべきこと](https://dev.classmethod.jp/articles/about-windows-ec2-instance-static-route/)
クラスメッソドさんでも注意点としてあげられていたようで、Windowsインスタンスを使用する場合は個別に注意が必要だったようです。
ブログの中にも書かれてますが、2020年7月にEC2LaunchのメジャーバージョンアップであるEC2Launch v2がリリースされたことで、本現象が解消されるそうです（[EC2Launch v2がリリースされました](https://dev.classmethod.jp/articles/ec2launch-v2-released/)）。ということは不具合だったのでしょうかね。。。。
改めて、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
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/18451efd-3b83-a422-a8eb-30fe3be564c1.png)
起動して、EC2Launchのバージョンを確認したら**V1**でした。これだとルーティングテーブルが固定になりますが、検証のためこのままAMIを作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/6926cad9-9053-ec30-afb4-a4c7faea1b2a.png)
作成したAMIを使って、以下のVPC/Subnet環境で起動します。
 VPC:10.1.0.0/16
 Public Subnet：10.1.0.0/24
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/2f4e1513-fe49-909f-5f14-21a557ea86d2.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/0202a1a6-c63e-9e62-e8de-df682f20cd3f.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/5531abc3-e17f-44c9-9615-8414fbb4e531.png)


###EC2LaunchV2への移行
[リンク先のサイト](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/ec2launch-v2-migrate.html)の記載内容を元に、V2へバージョンアップします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/fea81e2a-05c9-79b5-2100-e86da1bf1dab.png)
サイトには「移行ツールは、EC2Launch v1 スクリプトにリンクされているスケジュールされたタスクを検出しないため、EC2Launch v2 のタスクは自動的にセットアップされません。」と記載にがありますが、EC2Launch の設定はデフォルトのまま使用しているので、特に何も対応していません。
EC2を再起動し状態を確認します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/4bb155ef-d126-d5cf-cb3f-acaac34c3339.png)
メタデータのアクセスが可能になり、Credentialの取得ができました。また、ルーティングテーブルもデフォルトルートと同様のゲートウェイに向いています。
以上の事から、EC2LauchV2へバージョンアップすることで、使用するネットワーク環境を気にすることなくAMIを利用することができます。