Elastic Container Service (ECS)をApp Meshで管理する際の以下通信パターンについて、自分なりの理解を整理
- メッシュ外 -> メッシュ内
- メッシュ内 -> メッシュ内
- メッシュ内 -> メッシュ外
App Meshとは
App Meshは、AWS上においてサービスメッシュを提供するサービスです
サービスメッシュそのものについては、YouTubeにてAWS Japanの公式があげているこちらの動画がわかりやすいです
App Meshは「仮想サービス」、「仮想ゲートウェイ」、「仮想ノード」、「仮想ルータ」などといった要素で構成されており、
これらの繋がりはこちらの公式ブログに載っているアーキテクチャ図がシンプルでわかりやすいです
本記事においては、仮想サービスと仮想ノードを使用します
- 仮想サービス : 仮想ノードまたは仮想ルータと紐づけ、ルートの宛先や仮想ノードのバックエンドとして設定する
- 仮想ノード : 実サービス（本記事でいうと、ECSサービスやメッシュ外のエンドポイント）と紐づける
App Mesh (ECS)における通信パターン
本記事では、上図で示している3パターンの通信についてまとめていきます
- メッシュ外 -> メッシュ内（青）
- メッシュ内 -> メッシュ内（オレンジ）
- メッシュ内 -> メッシュ外（赤）
※ App Meshの機能にフォーカスしているので、Security Groupでのブロックは特にされていない前提で話を進めます
メッシュ外 -> メッシュ内
ECSの場合、デフォルトでは全てのアクセスが成功します
アクセス元の制限を行いたい場合は、クライアント証明書が利用できます（参考）
まぁ、基本的にはSecurity Groupでの制御が無難な気がしますね・・・
（残り2つを話す前に）メッシュのEgressフィルター
App Meshはマイクロサービスを「メッシュ」でまとめて管理します
そんなメッシュには「Egressフィルター」という機能があり、以下2つの選択肢があります
- 外部トラフィックを許可する
- 外部トラフィックを拒否する
外部トラフィックを許可した場合、以下で話す「メッシュ内 -> メッシュ内」及び「メッシュ内 -> メッシュ外」は基本的に全て成功します
なので、以降ではEgressフィルターは「外部トラフィックを拒否する」となっている前提で話を進めます
メッシュ内 -> メッシュ内
デフォルトではアクセスすることができません
そのため、アクセス元となる仮想ノードにてバックエンド設定を行う必要があります
バックエンドは仮想ノードの作成時に設定できますし、作成後に編集することも可能です
メッシュ内 -> メッシュ外
こちらもデフォルトではアクセスすることができません
そのため、以下2つのどちらかの方法を取る必要があります
- ECSタスク定義のプロキシ設定において、「無視された出力ポート」を設定
- 「無視された出力 IP」でも設定できそうな気がしますが、今回は確認していません
- アクセス先のエンドポイント専用の仮想ノードを作成
ECSタスク定義のプロキシ設定において、「無視された出力ポート」を設定
そもそもの話ですが、App Meshではサービスメッシュを実現するために、コンテナの通信は全てEnvoy Proxyを経由して行われます
ECSタスク定義設定の際に、そんなEnvoy Proxyのプロキシ設定を行うことができます
ここで、「無視された出力ポート」で設定されたポートへのアクセスはEnvoy Proxyを経由しなくなり、App Meshによる制御が行われなくなります
アクセス先のエンドポイント専用の仮想ノードを作成
App Meshの説明をしている際に少し触れましたが、仮想ノードにはメッシュ外のエンドポイントも登録することができます
そのため、例えばRDSへアクセスしたい場合は
- RDSのエンドポントを「DNS ホスト名」に記入した上で、仮想ノードを作成
- 1.で作成した仮想ノードに対応する仮想サービスを作成
- アクセス元となる仮想ノードのバックエンドに、2.で作成した仮想サービスを設定
こちらの流れでアクセスが可能となります