ついにCognitoがPrivateLink対応🎉 閉域での認証アーキテクチャ実現なるか！？

はじめに
Cognito認証とネットワークの課題
PrivateLink対応がもたらしたもの
考えられるユースケース
考慮事項
まとめ

はじめに

AWS上で認証基盤をマネージドサービスとして提供してくれているAmazon Cognito（以下、Cognito）。
非常に強力なサービスで私も好きなサービスのうちの1つです。
そんなCognitoですが、1つ悩ましい課題がありました。

それは、CognitoユーザープールのAPIエンドポイントがパブリックであったという点です。

今回はこの課題を根本から解決する重要なアップデート、CognitoユーザープールのPrivateLink対応について、深く掘り下げて解説します。

ちなみにアップデート内容はコチラ。
Amazon Cognito user pools now supports private connectivity with AWS PrivateLink

Cognito認証とネットワークの課題

まず、従来のアーキテクチャではどうだったのでしょうか？
VPC内のプライベートサブネットに配置されたバックエンド（Lambda、ECS Fargateなど）が、CognitoのAPI（例：AdminInitiateAuthの実行、JWT検証のためのjwks_uriへのアクセス）を呼び出す必要があったとします。
この場合のネットワーク経路は、以下のようになっていました。

この図からわかるように、VPC内からCognitoと通信するために、一度VPCの外（インターネット）に出ていく必要があったのです。
このアーキテクチャですと、以下のような課題が発生していたかもしれません。

コストの懸念：認証リクエストが大量に発生するサービスでは、NAT Gatewayのデータ処理料金が無視できないコスト要因となる
セキュリティの制約：「VPCからインターネットへのアウトバウンド（Egress）通信は原則禁止」といった厳格なセキュリティポリシーを持つ環境（金融、医療、政府系など）における不採用

このように仕方なくNAT Gatewayを使用するであったり、そもそも許容できないケースが一定数発生していたのではないでしょうか？

PrivateLink対応がもたらしたもの

今回のアップデートにより、この状況は根本的に改善されました。
com.amazonaws.<region>.cognito-idp サービスに対するインターフェースVPCエンドポイントを作成できるようになり、PrivateLinkに対応したのです。
これにより、アーキテクチャは以下のように変わります。

NAT GatewayもInternet Gatewayも不要となりました。
VPC内に作成されたENI（プライベートIPアドレスを持つネットワークインターフェース）を経由し、AWSのバックボーンネットワーク内でCognito APIへの通信が完結します。

インターネットへの経路が不要になったことで、アーキテクチャは劇的に改善されます。

コスト：NAT Gatewayが不要になったことで、関連するコスト（時間料金、データ処理料金）が削減（※ ただし、インターフェースVPCエンドポイントのコストとのトレードオフが発生）
セキュリティ：完全な閉域網での認証連携が実現。VPCからのEgress通信を完全に遮断した状態でもCognitoが利用可能となり、セキュリティが大幅に向上。
シンプル：ネットワーク経路がシンプルになり、設計・運用の負担が軽減

考えられるユースケース

ユースケース1：VPC内のバックエンドサービス（Lambda、ECSなど）

シナリオ：プライベートサブネットで稼働するバックエンドAPIが、サーバーサイドでJWTを検証したり、AdminGetUserでユーザー情報を取得したりするケース
効果：これまで必須だったNAT GatewayをインターフェースVPCエンドポイントに置き換えることで、ネットワーク構成の簡素化、コスト最適化に期待できる

ユースケース2：厳格なコンプライアンス要件

シナリオ：「インターネット通信の原則禁止」といった、PCI DSSなどの厳格なセキュリティ・コンプライアンス要件が課せられているシステム
効果：セキュリティ要件を満たせずCognitoの採用を見送っていた環境において、受け入れられやすくなる

ユースケース3：ハイブリッドクラウドとオンプレミス連携

シナリオ：オンプレミスのデータセンターで稼働する基幹システムが、閉域でCognitoのユーザー情報を操作（取得・更新）したいケース
効果：Route 53 ResolverとインターフェースVPCエンドポイントの組み合わせで、通信が自動的にプライベートIPに解決され、閉域網でAPIを実行できるようになる

考慮事項

と、ここまで色々と解説してきましたが、いくつか考慮事項もあるかなと思います。

コストのトレードオフ

これはCognitoのインターフェースVPCエンドポイントに限った話ではありませんが、「NAT Gatewayが不要になる＝必ず安価になる」とは限りません。
以下のようにコスト構造が変わる点を理解しておく必要があります。

削減されるコスト：NAT Gatewayの時間料金 + データ処理料金
新規発生するコスト：インターフェースVPCエンドポイントの時間料金（AZごと） + インターフェースVPCエンドポイントのデータ処理料金

認証トラフィックが比較的少ない環境では、AZごとに時間料金が発生するインターフェースVPCエンドポイントの方が、トータルコストが高くなる可能性もあります。

VPCエンドポイントポリシーによる最小権限の徹底

インターフェースVPCエンドポイントを作成すると、デフォルトのポリシーは事実上「全許可」になっています。
「閉域網だから安全」と考えるのではなく、しっかりとエンドポイントポリシーでAPIアクセスを絞り込むようにしましょう。

プライベートになる対象

これが今回のアップデートで一番勘違いしやすいポイントなのかもしれません。
今回アップデート情報によると、ユーザープール管理オペレーション（ユーザープールの一覧表示、ユーザープールの説明など）、管理オペレーション（管理者作成ユーザーなど）、およびユーザー認証フロー（Cognito に保存されているローカルユーザーのサインイン）がサポート対象となっています。
すなわち、Amplifyライブラリなどを使ってクライアント（ブラウザやアプリ）から直接Cognitoを呼び出す通信（ログイン画面の表示など）は、従来通りパブリックインターネットを経由する必要があるということです。