こんにちは、「カミナシ レポート」の開発に携わっている furuya です。
re:Invent2025 の参加レポート第二弾です。前回に引き続き現地レポートとセッションレポートをお送りします。
現地レポート：食べ物
ラスベガスでの夕食
前回、朝ごはんやランチ、おやつはカンファレンス内で提供される、というのを書きました。夕食はどうでしょう。毎日各所でAWS含むいろんな会社さんやグループがパーティを開いており、事前に申し込んでいればネットワーキングと会食を楽しむことができます。そういうのがない日はカミナシメンバーみんなでご飯にいきました。
どれも美味しかったですが、やはり高い…！写真のハンバーガーは$30.54 = ¥4700。くら寿司も一皿$3.65 = ¥570… 逐一円換算してると何も食べられなくなるのでいったん気にしないこととしました。
セッションレポート
Securing Amazon ECS workloads with application-aware networking
ECS のサービス間通信を総おさらいできるワークショップでした。普段 ECS サービス間の通信を意識することはあまりないのですが、その分普段触れていないサービス（Amazon ECS Service Connect や VPC Latticeなど）を触るきっかけにしたいな、と思ったのと、「Securing Amazon ECS workloads」とあるようにセキュリティをしっかり意識した構成の勉強になるかな、と思い本セッションを受講しました。以降、ワークショップで解説されていたこと、取り組んだ内容について簡単にご紹介します。
ECSサービス間を接続する方法おさらい
マイクロサービスのように複数の ECS サービス間で通信する必要がある場合、現状いくつかの選択肢があります。
ALB
internal ALB を作成することでサービス間の通信を実現します。
Amazon ECS Service Discovery
AWS Cloud Map というサービスを使って、各 ECS タスクが持つプライベート IP に解決される DNS ホスト名を管理します。ホスト名を使って各 ECS タスクに直接通信できます。
Amazon ECS Service Connect
上記の Amazon ECS Service Discovery の発展型で、2025/12 現在 AWS としてもこちらを推奨しているようです（ワークショップ中に記載がありました）。ECS サービスに対して Service Connect を有効にするタイミングでサービス名を Cloud Map に登録するところまでは Service Discovery と一緒ですが、違いとして各タスクにサイドカーコンテナとおして Proxy が配備され他のサービスへの通信は Proxy を経由して行われます。サービス側の /etc/hosts を見てみると Cloud Map に登録されたサービス名への通信はすべて Proxy を経由するようになっています。
# /etc/hosts の例 127.0.0.1 localhost 10.0.5.41 ip-10-0-5-41.us-west-2.compute.internal 172.31.16.1 service-b.local 172.31.32.1 service-b.local
Amazon VPC Lattice
2023年の re:Invent で発表された比較的新しいサービスです。一言でいうと、VPC の中にあるもの（EC2 や Fargate など）をターゲットグループとして登録でき、それをサービスとしてホスト名を与えて公開する、というものです。ホスト名の管理は Route 53 で行われます。
なんだか ALB などのロードバランサーに似ていますね（図的にも）。実際、 VPC Lattice は EKS において Kubernetes Gateway API の実装として利用されるため、どちらかというとロードバランサーの仲間のような気がしています。
サービスの成長に伴う接続先の増加に対応する
ワークショップではとあるベンチャー企業の成長ストーリーに合わせてアーキテクチャが変わっていく様子を追体験しました。架空のeコマースサイトを運営しているという想定で最初は UI のみ、つまりカートや購入の処理はモックになっている状態からスタートです。
ここから実際のバックエンドの処理を追加していきます。商品一覧サービス（catalog）とカートサービス（cart）を UI と同じ ECS クラスターに作成し、UIサービスから ECS Service Connect を利用して呼び出します。同じクラスターに作るんだ？とも思ったりしましたが全体として1つのプロダクトであることを考えると論理単位として1つのクラスターに収める、ということなんだなと理解しました。
さらにオーダーの処理を追加していきます。そのあたりのお金が絡むシステムは既存のシステムを利用しなければならない、という現実にありそうな制約のため他の VPC にある EC2 で稼働している API にアクセスしなければなりません（ここは ECS ちゃうんかい）。ここで VPC Lattice を使います。VPC Lattice を使って EC2 をターゲットとしたサービスを作成し、アクセス元の ECS クラスターが存在する VPC と紐づけることで EC2 サービスのホスト名を使って簡単に UI サービスからアクセスできます。
セキュリティを強化する
ワークショップでは各接続方法におけるセキュリティ向上方法を具体的に学ぶことができました。まず Amazon ECS Service Connect では AWS Private Certificate Authority を使った TLS 接続を設定しました。
次にVPC Lattice のネットワークレベルのセキュリティとして、通信の受け手であるサービス側のリソース（ENI）のセキュリティグループを考えます。VPC Lattice 経由での通信のみに絞りたい場合は用意されている Managed Prefix を使うことができます。
PREFIX_LIST_NAME="com.amazonaws.$AWS_REGION.vpc-lattice" IPV4_PREFIX=$(aws ec2 describe-managed-prefix-lists \ --filters Name=owner-id,Values=AWS \ --query "PrefixLists[?PrefixListName=='${PREFIX_LIST_NAME}'].PrefixListId | [0]" \ --output text)
VPC Lattice のサービスに IAM 認証をつけることもできます。実際に ECS を起点としたサービス間通信を行う場合は Proxy コンテナを経由してサービスにアクセスするのがよさそう、という具体例も紹介されていました。
詳細を色々省いてしまったのですが、今回のワークショップおよび関連リソースはこちらのリンクにまとまっていますので興味のある方はぜひ見てみてください。
https://serverlessland.com/reinvent2025/CNS330
まとめ
前回のレポート同様 VPC Lattice も「なんとなく知ってたけど自分で手を動かしていなかった」サービスだったので、一部で言われていた「VPC Lattice = なんでも ALB」という解釈が完全に理解できました。これは便利。VPC におけるサービス間通信には様々な選択肢があるので適材適所、使いこなせるようになっておかなければいけないですね。
