はじめに
ガバメントクラウドでは、デジタル庁が定義する「モダン化」への対応が求められています。モダン化の柱として掲げられているのは、APIベースのシステム構成、ステートレスなアーキテクチャ、マネージドサービスの活用、モダンな運用といった要素です。
一方で、ガバメントクラウドを利用する官公庁・自治体システムの多くは、セキュリティ要件として閉域網（インターネット非接続環境）でのシステム運用が求められることがあります。
本記事では、モダン化基準の基本形2（フロントエンド・バックエンド分離構成）を閉域環境で実現する場合に、何が課題になり、どのような回避策があるのかを整理します。
モダン化基準と基本形2のおさらい
ガバメントクラウドにおけるモダン化の定義
デジタル庁は2025年現在、以下をモダン化の定義として掲げています。
- APIベースのシステム構成 — システム間を疎結合化し、APIで連携
- ステートレスなアーキテクチャ — コンテナ化・オートスケール
- マネージドサービスの活用 — 自らサーバを構築しない
- モダンな運用 — IaC、CI/CD、監視の自動化
基本形2：フロントエンド・バックエンド分離構成
基本形2は、フロントエンドがUI/UXに責任を持ち、バックエンドがデータ管理に責任を持つ構成です。両者はAPIで連携し、開発・デプロイを独立して実施できるようにします。
AWSで実現する場合の代表的な構成は以下のとおりです。
| レイヤー | サービス構成 |
|---|---|
| フロントエンド（静的ホスティング） | Amazon CloudFront + Amazon S3 |
| バックエンドAPI | Amazon API Gateway + AWS Fargate（またはLambda） |
| 認証 | Amazon Cognito（User Pool / Identity Pool） |
| データベース | Amazon RDS / DynamoDB |
[ユーザー端末]
│
├── CloudFront ──→ S3（SPAの静的コンテンツ）
│
├── Cognito（認証トークン取得）
│
└── API Gateway ──→ Fargate / Lambda（バックエンドAPI）
この構成はインターネット経由でのアクセスを前提としており、閉域網ではそのままでは動作しません。
閉域網で何が使えないのか
閉域網の要件を以下のように想定します。
- ユーザー端末からインターネットへの直接アクセスが不可
- VPCにInternet Gatewayをアタッチできない（Control Tower等による統制）
この前提で、基本形2の各コンポーネントが閉域網で使えるかどうかを整理します。
| コンポーネント | 閉域対応 | 理由 |
|---|---|---|
| CloudFront | ❌ 不可 | インターネット経由のアクセスが前提。PrivateLink非対応 |
| S3 | ⚠️ 条件付き | VPC Endpoint（Interface / Gateway）経由でアクセス可能 |
| API Gateway（REST API） | ✅ 可能 | Private REST APIとして構成可能。VPC Endpoint経由でアクセス |
| Cognito | ⚠️ 一部制約あり | 2025年11月にUser Pool、12月にIdentity PoolがPrivateLink対応。ただしHosted UI / OAuth2フロー / フェデレーションは非対応 |
| Fargate / Lambda | ✅ 可能 | VPC内で動作。PrivateLink経由で呼び出し可能 |
特に問題になるのは、CloudFrontとCognito（の一部機能）です。
閉域構成でのアーキテクチャ
全体像
閉域環境での基本形2構成は、以下のような代替アーキテクチャとなります。
[ユーザー端末（庁内LAN等）]
│
│ ※インターネット不可
│
├── ALB ──→ S3 Interface Endpoint（静的コンテンツ配信）
│ ※ホストヘッダー書き換えでバケット名を解決
│
├── API Gateway（Private REST API）
│ └── HTTP統合 ──→ Cognito エンドポイント（認証プロキシ）
│ ※ブラウザからの認証フローの場合
│
└── API Gateway（Private REST API）──→ Fargate（バックエンドAPI）
└── Cognito VPC Endpoint経由でJWT検証・ユーザー管理
1. 静的コンテンツ配信：CloudFrontの代替
CloudFrontが使えないため、ALB + S3 Interface Endpoint の構成で代替します。
方法A：ALB + S3（PrivateLink経由）
S3のInterface EndpointのプライベートIPアドレスを、ALBのIPターゲットとして登録する構成です。
ポイント：
- ALBにACM証明書をアタッチしてHTTPS通信を実現
- ヘルスチェックの成功コードを
307に設定（S3 Interface Endpointはリダイレクトを返すため） - 2025年10月のALBアップデートにより、ホストヘッダー書き換え機能が追加。これにより、ALBのカスタムドメイン名とS3バケット名を一致させる必要がなくなった
SPA（BrowserRouter）対応：
ALBのURLパス変換機能を使い、拡張子なしのパスへのリクエストを index.html にリライトすることで、SPAのパスベースルーティングにも対応できます。これにより、従来はHashRouterに制限されていた閉域SPAでもBrowserRouterが利用可能になりました。
方法B：ALB + Fargate（Webサーバーコンテナ）
Fargate上でNginx等のWebサーバーコンテナを動かし、S3からコンテンツを取得して配信する方式です。
メリット：
- BrowserRouterが素直に使える（サーバー側でルーティング制御可能）
- S3バケット名の制約なし
デメリット：
- Fargateの常時起動コストが発生
- コンテナイメージの管理が必要
2. 認証：Cognitoの閉域対応
Cognito PrivateLink対応の現状（2025年末時点）
2025年後半に大きなアップデートがありました。
| 日付 | アップデート内容 |
|---|---|
| 2025年11月7日 |
Cognito User Pool が PrivateLink に対応。com.amazonaws.<region>.cognito-idp のInterface VPC Endpointが作成可能に |
| 2025年12月11日 |
Cognito Identity Pool が PrivateLink に対応。com.amazonaws.<region>.cognito-identity のInterface VPC Endpointが作成可能に |
これにより、バックエンド（Lambda / Fargate）からのCognito API呼び出しは、PrivateLink経由で閉域内に完結できるようになりました。JWT検証のためのjwks_uriへのアクセスや、AdminInitiateAuth等の管理API呼び出しにインターネットアクセスが不要になっています。
Cognito閉域利用時の制約（重要）
PrivateLink対応によって「すべて閉域で完結する」と考えてしまいがちですが、ブラウザからのエンドユーザー向け認証フローには依然として制約があります。
| 機能 | PrivateLink対応 | 備考 |
|---|---|---|
| User Pool管理操作（ユーザープール一覧、詳細確認等） | ✅ | バックエンドからの呼び出しが閉域化 |
| 管理者操作（AdminCreateUser等） | ✅ | バックエンドからの呼び出しが閉域化 |
| ローカルユーザーのサインイン（USER_PASSWORD_AUTH等） | ✅ | バックエンドでAdminInitiateAuth等を使う場合 |
| Hosted UI / マネージドログイン | ❌ | ブラウザからCognitoドメインへの直接アクセスが必要。閉域では到達不可 |
| OAuth 2.0 認可コードフロー | ❌ |
/oauth2/authorize、/oauth2/token 等のエンドポイントがPrivateLink非対応 |
| Client Credentialsフロー | ❌ | M2M認証のトークンエンドポイントがPrivateLink非対応 |
| 外部IdPフェデレーション（SAML / OIDC） | ❌ | ブラウザが外部IdPとCognito双方に到達する必要があり、閉域では成立しない |
| ソーシャルIdPサインイン | ❌ | Google、Facebook等のIdPへのインターネットアクセスが必要 |
閉域での認証フロー設計パターン
上記の制約を踏まえると、閉域でCognitoを使う場合の認証フローは以下のような設計になります。
パターン1：API Gateway HTTP統合によるプロキシ（ブラウザ → API GW → Cognito）
フロントエンド（ブラウザ上のSPA）からCognitoのUser Pool APIに直接到達できないため、Private REST API（API Gateway）のHTTP統合を利用してプロキシする方式です。Amplify JS（v6.15.0以上）ではuserPoolEndpoint / identityPoolEndpoint にカスタムエンドポイントを指定可能です。
パターン2：バックエンドAPI経由の認証（ブラウザ → API GW → Fargate/Lambda → Cognito VPC Endpoint）
バックエンド側でAdminInitiateAuth等のAdmin APIを使用し、Cognito VPC Endpoint経由で認証処理を行う方式です。Hosted UIやOAuth2フローを使わず、自前のログインAPIをバックエンドに構築します。フロントエンドはAPIを叩くだけの薄い構成になります。
いずれのパターンでも、Hosted UI / マネージドログインは使えません。 フロントエンドでAmplify UIのAuthenticatorコンポーネント等を使って認証画面を自前実装するか、バックエンドにログインAPIを構築する必要があります。
3. バックエンドAPI：API Gatewayの閉域対応
API GatewayはPrivate REST APIとして構成することで、VPC内からのみアクセス可能にできます。
2024年11月のアップデート：プライベートカスタムドメイン名対応
API GatewayがPrivate REST APIのカスタムドメイン名をサポートするようになりました。これにより、xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com のような自動生成URLではなく、api.example.local のような組織のドメイン名でAPIを公開できます。
閉域構成におけるカスタムドメインの利用
閉域環境では、CloudFrontが使えない代わりにALBやAPI Gatewayで各エンドポイントを構成します。通常構成ではCloudFrontのカスタムドメインで統一的にURLを管理できますが、閉域構成でも同様にカスタムドメインを利用できるかは重要なポイントです。
ALB + S3（静的コンテンツ配信）：カスタムドメインの利用
ALBでは、ACM証明書をリスナーにアタッチすることで、任意のカスタムドメイン（例：app.example.local）でHTTPS通信を提供できます。
従来のALB + S3構成では、S3 Interface Endpointの仕様上、ALBのカスタムドメイン名とS3バケット名を一致させる必要があるという制約がありました。しかし、2025年10月に追加されたALBのホストヘッダー書き換え機能により、ALBのリスナールール内でホストヘッダーをS3バケット名に変換できるようになったため、カスタムドメイン名とS3バケット名を独立して設定可能になりました。
これにより、通常構成のCloudFront + S3と同様に、組織の命名規則に沿ったドメイン名でフロントエンドを公開でき、閉域化によるエンドユーザーへの影響は小さく抑えられます。
API Gateway（Private REST API）：カスタムドメインの利用
2024年11月のアップデートで、Private REST APIでもカスタムドメイン名が利用可能になりました。従来は xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com のような自動生成URLしか使えませんでしたが、api.example.local のような組織のドメイン名を設定できます。
主な機能：
- ACM証明書によるTLS管理：カスタムドメインに対応するTLS証明書をACMで発行・管理。証明書のライフサイクルを組織側で完全に制御可能
-
ベースパスマッピング：1つのカスタムドメインに対して複数のAPIをマッピングできる（例：
api.example.local/v1/とapi.example.local/v2/） - アカウント間共有：AWS RAMを使って、別アカウントのVPCからもカスタムドメイン経由でAPIにアクセス可能。ガバメントクラウドのマルチアカウント構成との親和性が高い
- リソースポリシーによるアクセス制御：ドメインに対する呼び出しをVPC Endpoint単位やアカウント単位で制御可能
カスタムドメイン対応まとめ
| コンポーネント | ドメイン例 | カスタムドメイン対応 |
|---|---|---|
| フロントエンド（SPA） | app.example.local |
✅ ALB + ACM証明書 |
| バックエンドAPI | api.example.local |
✅ API Gateway Private カスタムドメイン + ACM証明書 |
| Cognito認証プロキシ | auth.example.local |
✅ API Gateway Private カスタムドメイン + ACM証明書 |
ALB・API Gatewayいずれもカスタムドメインに対応しているため、閉域構成であっても通常構成と遜色のないURL体系で各エンドポイントを提供できます。
閉域構成のまとめ：サービス対照表
| 基本形2（通常構成） | 閉域構成 | 備考 |
|---|---|---|
| CloudFront + S3 | ALB + S3 Interface Endpoint | ホストヘッダー書き換え機能活用。または ALB + Fargate |
| Cognito（ブラウザから直接） | API Gateway HTTP統合 → Cognito プロキシ、またはバックエンドAdmin API経由 | Hosted UI / OAuth2フロー / フェデレーションは不可。認証画面の自前実装が必要 |
| Cognito（バックエンドから） | Cognito VPC Endpoint（PrivateLink） | 2025年11月〜12月にUser Pool / Identity Pool共に対応 |
| API Gateway（パブリック） | API Gateway（Private REST API） | カスタムドメイン名対応済み |
| CloudFrontカスタムドメイン | ALB + ACM証明書 / API Gateway Privateカスタムドメイン | 各コンポーネントでカスタムドメイン利用可能 |
| Fargate / Lambda | Fargate / Lambda（VPC内） | 変更なし |
考慮事項と注意点
コスト面
- CloudFrontの代わりにALBを利用するため、ALBの固定時間課金が発生
- Fargateでフロントエンドを配信する場合はコンテナの常時起動コストも加算
- API GatewayによるCognitoプロキシ分のリクエスト課金が追加（パターン1の場合）
- VPC Endpoint（Interface Endpoint）の時間課金（AZごと）とデータ処理課金。Cognito用・S3用・API Gateway用で複数必要になるため、エンドポイント数に注意
運用面
- ALBターゲットへのS3 Interface Endpoint IPの登録が必要（ENIのIPは存続期間中は固定）
- Cognitoプロキシ用のAPI Gatewayの構成管理が追加（パターン1の場合）
- IaCで管理する場合、閉域固有のリソースが増えるためCDKテンプレートの複雑度が上がる
- ACM証明書の発行・更新管理。Private CAを利用する場合はCA運用も必要
- 認証画面の自前実装・保守が必要（Hosted UIが使えないため）
セキュリティ面
- API GatewayのHTTP統合でCognitoをプロキシする場合、API GatewayからCognitoへの通信はAWSネットワーク内にとどまるが、パブリックエンドポイント経由である点は認識しておく
- Cognito VPC Endpointのエンドポイントポリシーはデフォルトで全許可になっている。「閉域だから安全」と考えず、適切にAPIアクセスを絞り込む
- Private REST APIにはリソースポリシーを適切に設定し、意図しないアクセスを防ぐ
- カスタムドメインのTLS証明書管理を適切に行い、証明書の失効やローテーションに対応する
まとめ
ガバメントクラウドのモダン化基準基本形2（フロントエンド・バックエンド分離）を閉域環境で実現することは可能ですが、いくつかのサービスで代替構成が必要になります。
対応のポイント：
- CloudFrontが使えない → ALB + S3 Interface Endpoint（またはALB + Fargate）で代替。2025年10月のALBアップデートで制約が大幅に緩和
- Cognitoは一部PrivateLink対応済み → バックエンドからのAPI呼び出しはVPC Endpoint経由で閉域化可能。ただしHosted UI / OAuth2フロー / フェデレーションはPrivateLink非対応のため、認証画面の自前実装が必要
- API Gatewayは閉域対応済み → Private REST API + カスタムドメイン名で柔軟に構成可能
- カスタムドメイン → ALB・API Gatewayいずれも対応しており、閉域でも通常構成と同様のURL体系を維持可能
閉域環境でのモダン構成は通常構成と比べて設計・運用の複雑度が上がりますが、2025年後半のCognito PrivateLink対応やALBの機能強化により、状況は着実に改善されています。閉域要件がある場合は、早い段階で各コンポーネントの閉域対応状況を確認し、特にCognitoの認証フロー設計については制約を正確に把握した上でアーキテクチャを決定することが重要です。