AWSのEC2立ち上げからセッションマネージャーでアクセスするまでに出会ったエラー対処法
更新日 : 2023/5/9
つい先日、仕事でAWSのEC2を立ち上げる必要があり、AWSマネジメントコンソール上のセッションマネージャーで接続する方法を個人で簡単に確認していました。
EC2はこれまで何度か使用したことがあるので苦戦することなくできるだろうなーと思っていたのですが、意外と躓いた部分があったのでこの記事にまとめます。
まず1つ目のエラーです。
「既存の参照先のグループ ID ルールに 1 つの IPv4 CIDR を指定することはできません。」のエラー対処法
エラーの内容
最終的に確認したいのは、Nginxのサーバの挙動だったので、コンソール上でEC2を立ち上げた後、まずEC2インスタンスへインターネットから HTTP / HTTPS で接続できるようにインバウンドルールの設定を行いました。 デフォルトのインバウンドルールでは、インスタンスのいるセキュリティグループからポート80番（HTTP）へのアクセスしか許可されていなかったため、 具体的には「0.0.0.0 / 0」からポート80番（HTTP）と443番（HTTPS）へアクセスできるように設定しようとしました。
すると、以下のようなエラーが、、
(下の画像はソースの部分を「0.0.0.0/0」からセキュリティグループへ変更しようとした際の画像ですが、セキュリティグループから「0.0.0.0/0」へ変更しようとしても同様のエラーが発生します。)
「既存の参照先のグループ ID ルールに 1 つの IPv4 CIDR を指定することはできません。」と表示されています。
対処法
結論からいうと、前に作成した（されていた）ルールを一度削除した後に改めて作成したいルールを作成することでこのエラーは解消されます。
具体的には、以下の画像の赤枠の部分を押下して既存のルールを削除した後、画面左下の「ルールを追加」ボタンを押下して作成したいルールを作成するといった感じです。
AWSエンジニアの方からすると当たり前のことかもしれませんが、恥ずかしながら私はここで少々つまずきました、、
続いて2つ目のエラーです。
AWS EC2にセッションマネージャーで接続できない場合の対処法
エラーの内容
今回は個人的な動作確認だったので、公開鍵を使ったSSH接続ではなく、 AWSマネジメントコンソール上のセッションマネージャーでぱぱっと設定しようと思い、EC2のコンソールからセッションマネージャーを開きました。
すると、今度は以下のようなエラーが、、
はい、
インスタンスに接続できませんでした。
だそうです。。
対処法
こちらの原因はいくつかあるようですが、 セキュリティグループなど特に設定していない、作成したてのEC2インスタンスにコンソールからセッションマネージャーでアクセスする場合は、大体以下の2点を確認すると解決するのではないかと思います。
- EC2インスタンスにSSM Agentがインストールされているか
- EC2インスタンスに「AmazonSSMManagedInstanceCore」のIAMポリシーがついているか
それぞれ詳しく見ていきます。
【EC2インスタンスにSSM Agentがインストールされているか】
まず前提として、以下のインスタンスについては、インスタンスを立ち上げた時点で既にSSM Agentはインストールされているので、特に作業する必要はありません。（2023年4月時点）
参考 : SSM Agent がプリインストールされた Amazon Machine Images (AMIs)
- 2017 年 9 月以降の Amazon Linux Base AMI
- Amazon Linux 2
- Amazon Linux 2 ECS に最適化されたベース AMIs
- Amazon Linux 2023 (AL2023)
- Amazon EKS 最適化 Amazon Linux AMIs
- macOS 10.14.x (Mojave)、10.15.x (Catalina)、11.x (Big Sur)
- SUSE Linux Enterprise Server(SLES) 12 と 15
- Ubuntu Server 16.04、18.04、および 20.04
- 2016 年 11 月以降に公開された Windows Server 2008-2012 R2 AMIs
- Windows Server 2016、2019、および 2022
色々あって少し混乱しそうですが、Amazon Linux系はほぼ全てにプリインストールされています。
UbuntuやWindowsは良く使われるものはプリインストールされていて、その他RedHat, Debianなどは自分でインストールしなければ、セッションマネージャーで接続はできないようです。
私はAmazon Linux 2023 (AL2023)だったのでこちらは問題ありませんでしたが、もしプリインストールされていないインスタンスを使用されている方は以下のサイトを参考にインストールしてみてください。
その他の場合
- その他のインスタンスの場合はこちらのサイト下部のリンクが参考になります。
続いて2つ目の確認ポイントです。
【EC2インスタンスに「AmazonSSMManagedInstanceCore」のIAMポリシーがついているか】
こちらは恐らくどのOSを選択していたとしても必要になる作業だと思います。
確認ポイントの文章の通り、「AmazonSSMManagedInstanceCore」のIAMポリシーをEC2インスタンスへアタッチすれば問題ないのですが、慣れていない人はその方法が分からないかもしれないので、簡単に手順を説明します。
＜手順①＞ 「AmazonSSMManagedInstanceCore」のIAMポリシーがアタッチされたIAMロールの作成
- AWSマネジメントコンソールでIAMのコンソールへアクセスします。
- アクセスした後、左メニューから「ロール」＞「ロールを作成」の順で選択します。
- 「信頼されたエンティティを選択」画面で、「AWSのサービス」にチェックを入れ、「ユースケース」で「EC2」にチェックを入れます。「次へ」を押下します。
- 「許可を追加」画面で、検索窓に「AmazonSSMManagedInstanceCore」と入力して表示された「AmazonSSMManagedInstanceCore」にチェックを入れ、「次へ」を押下します。（ここで選択したものがIAMポリシーです。）
- 作成するロールの内容確認画面が表示されるので、任意のロール名を入力し、「ロールを作成」を押下します。
以下はロール作成時の最後の確認画面です。
＜手順②＞ 作成したポリシーをEC2インスタンスへアタッチ
- AWSマネジメントコンソールでEC2のコンソールへアクセスし、対象のインスタンスにチェックを入れて「アクション▲」を押下します。
- 「アクション▲」の下に表示されたメニューから「セキュリティ」＞「IAMロールを変更」の順で選択します。
- 「IAMロールを選択」の部分をクリックし、先ほど作成したロールを選択して「IAMロールの更新」を押下します。
- ここでインスタンスを起動している場合はインスタンスを再起動してください。
本当に簡単でしたが手順は以上です。
これで以下の画像のように、「接続」ボタンが活性化してコンソールから接続することができるようになっているかと思います。
手順②の最後のインスタンスの再起動は意外と忘れがちなので、忘れないように再起動しましょう。
最後に
以上、私がEC2を立ち上げてからセッションマネージャーで接続するまでに出会ったエラーの内容と対処法でした。
業務で使用したことのあるAWSサービスはフルマネージドサービス（Lambda、Glueなど）が多かったこともあり、上記のようなエラーで少し躓きましたが、
特にIAMポリシーの付与のし忘れは、これまでに何回かやらかした記憶があるので、頭に叩き込む目的でも今回記事としてまとめてみたという感じです笑。
この記事がどなたかの助けになれば幸いです！
それでは！
