AWS EC2でSSM接続する際に起こりそうなエラーの調査①

初めに

👆の記事でプライベートサブネットに配置したEC2へのSSM接続をしてみました。
この記事以外にもSSM接続の記事は調べれば出てくると思います。
しかし、実際に構築してみると接続がうまくいかないといったケースもあると思います。

そこで今回はプライベートサブネットのEC2のSSM接続するまでの過程で遭遇しそうなエラーの切り分けと対応を行ってみようと思います。
大きく分けて「リソース構築時」「構築後にSSM接続ができない」の2つのパターンで考えられるエラーを検証します。

目次

1. リソース構築時のエラー
   1. エンドポイント作成時のエラー
   2. EC2作成時にロールを付与できない
2. SSM接続ができない　　👈別の記事にすることにしました
   1. VPCエンドポイントの不備
   2. IAMロールの不備
   3. セキュリティグループの不備
   4. SSMエージェントがプリインストールされていないor停止している
3. その他のケース

事前確認

そもそもちゃんとSSM接続ができていることを確認します。

正常に接続できていますね。では先ほどの目次の順番でエラーの発生 ⇒ 解消のサイクルで検証していきます。

リソース構築時のエラー

リソースの構築時のエラーとしては下記2項目を検証してみます。
・エンドポイント作成時のエラー
・ロールを付与できないエラー

エンドポイント作成時のエラー

VPCエンドポイントを作成する際に下記のエラーに遭遇することがあります。

赤文字で仰々しく表示されますが、エラー文には👇とあります。

「Enabling private DNS requires both enableDnsSupport and enableDnsHostnames VPC attributes set to true for vpc-09b3d692a41dded7b」

翻訳してみると、👇になるみたいです

プライベート DNS を有効にするには、vpc-09b3d692a41dded7b の enableDnsSupport と enableDnsHostnames の両方の VPC 属性を true に設定する必要があります。

VPCエンドポイント作成時に「DNS名を有効化」を選択しています。

これを有効にしてVPCエンドポイントを作成するにはVPC側の設定で「DNS解決」「DNSホスト名」が有効にする必要があるという内容のエラーみたいです。

ということでVPCの設定を確認してみます。

確認したところエラー文通り「DNSホスト名」が無効になっているみたいです。
とりあえず「アクション」>「VPCの設定を編集」から「DNSホスト名を有効化」にチェックを入れて保存します。

👆「DNSホスト名」が有効になっていることが確認できます。
気を取り直してVPCエンドポイントの作成をしてみます。

今度は正常に作成できました。原因は「DNSホスト名」が無効になっていたことみたいです。

どうやらこの「DNSホスト名」はVPCを作成する際に有効/無効を選択する箇所がなくデフォルトで無効になっている項目のようです。
VPC作成後に設定する必要があるのでお気を付けください。

EC2作成時にロールを付与できない

続いてこちらのケースです。

こちらを解説するにあたってEC2に付与するIAMロールについてお話します。
EC2にIAMロールを付与する場合はインスタンスプロファイルなるものを使用する必要があります。

実際にSSM用のIAMロール下記２種類用意し、検証してみます。

• インスタンスプロファイルとして紐づいているIAMロール ⇒「EC2-SSM-Role-Miyazaki」
• インスタンスプロファイルとして紐づいていないIAMロール ⇒「Qiita-Test-Miyazaki」

👆３つのキャプチャから２つのロールに許可されているポリシーに際はないことが確認できます。
しかしながらEC2にロールを付与しようとすると「EC2-SSM-Role-Miyazaki」しか出てきません。

この原因となっているのが、先ほどのインスタンスプロファイルなるものになります。
実際に2つのIAMロールを詳しく見比べてみると概要タブに「インスタンスプロファイルのARN」の記載に差異が見受けられます。

IAMロールをEC2に付与するロールとして認識させるにはIAMロールをインスタンスプロファイルに紐づけなければなりません。キャプチャからわかるように、「Qiita-Test-Miyazaki」のほうはインスタンスプロファイルのARNが存在していない ⇒ つまりインスタンスプロファイルに紐づいていないというわけです。

インスタンスプロファイルについての具体的な内容はAWS公式のリンクからご参照ください。

今回重要なのは下記の2点となります。

• IAMロールは直接EC2にアタッチできない
• インスタンスプロファイルはEC2が参照できる器のようなイメージ

雑な図ですがこんな感じのイメージです。

原因についてはわかりましたが、ではどのようなケースでインスタンスプロファイルに紐づいていないIAMロールが作られるてしまうのでしょうか?

こちらは大きく2つほどありそうです。

• マネコンから作成する際に、信頼されたエンティティをEC2にしていない
• CLIをはじめとするコードで作成時に明示的に作成していない

マネコンから作成する際に、信頼されたエンティティをEC2にしていない

こちらのケースについて検証してみます。

通常EC2用のIAMロールを作成する際は👇のキャプチャのように

• 信頼されたエンティティ：AWSのサービス
• ユースケース：EC2
  
  

と選択するケースがほとんどだと思います。
実際にこの設定で「Qiita-Test02-Miyazaki」というIAMロールを作成すると、インスタンスプロファイルに紐づいていることがわかります。

ですが、会社の方針などで信頼するエンティティを「カスタム信頼ポリシー」で作成する必要がある場合はこうはいきません。
信頼されたエンティティをカスタム信頼ポリシーを選択し「Qiita-Test03-Miyazaki」を作成してみます。

作成した「Qiita-Test03-Miyazaki」の詳細を見てみると「インスタンスプロファイルのARN」が記載されていないことがわかります。

何らかの理由で信頼されたエンティティをカスタム信頼ポリシーなど別の項目から作成しなければならない場合は、インスタンスプロファイルに紐づいたロールが作成されないでお気を付けください。

じゃどうやってIAMロールをインスタンスプロファイルに紐づけるかという話になりますが、それは後ほど記載します。

CLIをはじめとするコードで作成時に明示的に作成していない

続いてはこちらのケースを考えてみます。
AWSのリソースを操作する方法はGUIのマネジメントコンソールのほかにもCLIをはじめとしたコードで操作する方法があります。

今回はCLIで作成するケースを考えてみます。CLIのドキュメントは👇になります。

IAMロールを作成するコマンドは下記になります。

aws iam create-role \
  --role-name {作成するロール名を記載} \
  --assume-role-policy-document \
'{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}'

上記のコマンドで「Qiita-Test04-Miyazaki」を作成したので早速確認してみます。

こちらも「インスタンスプロファイルのARN」がないことが確認できます。
ということでインスタンスプロファイルに紐づかないケースの確認ができたので、次はインスタンスプロファイルの紐づけ方を記載してみます。

作成したIAMロールをインスタンスプロファイルに紐づける

続いてはIAMロールとインスタンスプロファイルの紐づけの仕方を記載していきます。
※ここからはCloudShell上でCLIを実行していきます。

まずはIAMロールとインスタンスプロファイルを比較してみます。
👇👇👇IAMロールの一覧取得

aws iam list-roles --query 'Roles[].RoleName' | grep Qiita

出力結果

    "Qiita-Test-Miyazaki",
    "Qiita-Test02-Miyazaki",
    "Qiita-Test03-Miyazaki",
    "Qiita-Test04-Miyazaki",

👇👇👇インスタンスプロファイル一覧の取得

aws iam list-instance-profiles | grep Qiita

出力結果

            "InstanceProfileName": "Qiita-Test02-Miyazaki",
            "Arn": "arn:aws:iam::<アカウントID>:instance-profile/Qiita-Test02-Miyazaki",
                    "RoleName": "Qiita-Test02-Miyazaki",
                    "Arn": "arn:aws:iam::<アカウントID>:role/Qiita-Test02-Miyazaki",

出力結果からわかるようにインスタンスプロファイルとして「Qiita-Test02-Miyazaki」が登録されており、IAMロール「Qiita-Test02-Miyazaki」に紐づいていることが確認できます。

EC2にアタッチできるロールとして存在するのもtest02のみです。

それでは早速インスタンスプロファイルの作成と紐づけを行います。
👇👇👇インスタンスプロファイルの作成

aws iam create-instance-profile --instance-profile-name QiitaInstance-Profile-Miyazaki

不自然な名前になってしまいましたが「QiitaInstance-Profile-Miyazaki」を作成しました。

aws iam list-instance-profiles | grep Qiita

出力結果

            "InstanceProfileName": "Qiita-Test02-Miyazaki",
            "Arn": "arn:aws:iam::<アカウントID>:instance-profile/Qiita-Test02-Miyazaki",
                    "RoleName": "Qiita-Test02-Miyazaki",
                    "Arn": "arn:aws:iam::<アカウントID>:role/Qiita-Test02-Miyazaki",
            "InstanceProfileName": "QiitaInstance-Profile-Miyazaki",
            "Arn": "arn:aws:iam::<アカウントID>:instance-profile/QiitaInstance-Profile-Miyazaki",

ですが、RoleNameの記載がなくIAMロールとの紐づけができていません。
続いて作成したインスタンスプロファイルとIAMロール「Qiita-Test-Miyazaki」との紐づけを実施していきます

aws iam add-role-to-instance-profile --instance-profile-name QiitaInstance-Profile-Miyazaki --role-name Qiita-Test-Miyazaki

もう一度インスタンスプロファイルを確認してみると下記の出力が得られ、IAMロールとインスタンスプロファイルが紐づいていることを確認できます

            "InstanceProfileName": "Qiita-Test02-Miyazaki",
            "Arn": "arn:aws:iam::<アカウントID>:instance-profile/Qiita-Test02-Miyazaki",
                    "RoleName": "Qiita-Test02-Miyazaki",
                    "Arn": "arn:aws:iam::<アカウントID>:role/Qiita-Test02-Miyazaki",
            "InstanceProfileName": "QiitaInstance-Profile-Miyazaki",
            "Arn": "arn:aws:iam::<アカウントID>:instance-profile/QiitaInstance-Profile-Miyazaki",
                    "RoleName": "Qiita-Test-Miyazaki",
                    "Arn": "arn:aws:iam::<アカウントID>:role/Qiita-Test-Miyazaki",

正しく認識されているかを確認するためにEC2に「QiitaInstance-Profile-Miyazaki」をアタッチし、SSM接続できることを確認してみます。

EC2にアタッチするのはインスタンスプロファイルになります。
インスタンスプロファイルをIAMロールと別の名前で作成し、紐づけた場合はインスタンスプロファイル名でリソースを選択することに気を付けてください

EC2にアタッチできるリソースとして「QiitaInstance-Profile-Miyazaki」が認識されています。

「QiitaInstance-Profile-Miyazaki」がアタッチされているので、「接続」からSSM接続してみます

SSM接続が正常にできました！！！

まとめ

今回はSSM接続する際に遭遇するであろうエラーを調査してみました。

今回の調査では下記のことがわかりました。

• VPCエンドポイントをDNSを有効にするにはVPC側のDNSの項目が２つとも有効になっている必要がある
• EC2にアタッチできるロールはインスタンスプロファイルと紐づいている必要がある

記事が長くなってきたので残りの下記項目は別の記事にしようと思います。
※記事書いたらリンク張ります

• SSM接続ができない
• VPCエンドポイントの不備
• IAMロールの不備
• セキュリティグループの不備
• SSMエージェントがプリインストールされていないor停止している
• その他のケース