この記事の続きになります。
検討にあったように、ALBをNLBへ置き換えて、ECSへアクセスできるようにしました。
今回は、その確認を行います。
TLDR
- NLBが配置されているPrivateサブネットにEC2を立ち上げる。
- EC2経由でECSタスクへアクセスできるかを確認する。
解説
EC2の立ち上げ
これは、AWSコンソールから立ち上げました。詳細は割愛します。
ポイントとして、NLBが配置されているPrivateサブネット内にEC2インスタンスを配置しています。
EC2インスタンスへアクセス
EC2へのアクセスはセッションマネージャーから行います。
セッションマネージャーへの接続方法については、次の記事を参考させていただきました。
セッションマネージャーからの接続に若干ハマりました。今回の接続のパターンは、セッションマネージャーのハマりどころをパターンごとに整理してみるの「③EC2がプライベートサブネットにあり、インターネットへのアウトバウンド通信経路がない場合」に当たります。
クリアしたポイントは、次の通りです。詳細は割愛します。
- エンドポイントをきちんと設定する。
- インスタンスへロールを設定する。
- SSMの設定画面でインスタンスを手動で指定する。
EC2インスタンス内からECSタスクが見えるかを確認する。
セッションマネージャーを使い、EC2インスタンスへ接続しました。
NLBのDNS名を使って、curlコマンドを実行し、接続確認を行います。
sh-5.2$ curl https://'<NLBのDNS名>'
curl: (60) SSL: no alternative certificate subject name matches target host name '<NLBのDNS名>'
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.接続しているNLBのDNS名と証明書のDNS名が一致していないので、エラーが出ました。
DNS検証を無視するようにしてます。（insecureオプションを付与）
sh-5.2$ curl --insecure https://<NLBのDNS名>/
<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
</body>
</html>一時的なリダイレクトを意味する302コードが出力されました。
これの理由は、今回の環境では、ALBのリスナーでcognito認証を使用しているので、cognitoの認証画面へリダイレクトしようとしているからです。
NLBのアクセス検証としては、これで問題なさそうです。
あとがき
NLBからの接続確認を行いました。
途中、個人的に使ったことがないセッションマネージャーの勉強になってよかったです。
sshキーなどを用意しなくていいので、楽ですね。
今回は、NLBを使ったアクセス検証に焦点を当てましたが、cognito認証については省きましたが、認証画面へ接続するためにインターネットへ接続するので、Natゲートウェイを設定する必要がありました。