エンタープライズAIゲートウェイ基盤(ECS + Amazon Bedrock)
社内AI APIの共通入口・RAG・ガードレール・コスト可視化
可用性 (SLA目標)
99.9% を設計目標(Multi-AZ ECS + マネージドサービス、前提条件付き)
RTO(目標復旧時間)
数分目安(タスク自動再配置、構成・運用に依存)
RPO(目標復旧時点)
ほぼ 0 を目標(ベクトル/原文書は S3・マネージドに永続化)
概算コスト
月 200,000 円〜(常時稼働タスク + モデル従量、利用量に依存)
構成概要
- 可用性レベル
- マルチAZ
- コンピューティング
- ECS/Fargate
- 想定システム規模
- 全社共通(複数部門のAI利用を集約)
- コスト感
- ¥¥¥高コスト
使用AWSサービス
- Application Load Balancer
- Amazon ECS (Fargate)
- Amazon ECR
- Amazon Bedrock
- Bedrock Knowledge Bases
- Amazon OpenSearch Serverless(ベクトル / 相当)
- Amazon S3
- Amazon Cognito
- AWS WAF
- AWS KMS
- AWS Secrets Manager
- Amazon CloudWatch
- AWS CloudTrail
概要
全社の生成AI利用を集約する社内AIゲートウェイ基盤です。社内利用者・業務アプリからのリクエストを ALB 経由で Multi-AZ の ECS Fargate(AIゲートウェイ)が受け、Cognito / 外部IdP で認証・権限制御を行います。推論は Amazon Bedrock の基盤モデルへ PrivateLink で閉域アクセスし、Bedrock Guardrails で入出力をフィルタリング。RAG は Bedrock Knowledge Bases を用い、ベクトル検索(OpenSearch Serverless 相当)と S3 上の社内ドキュメントを参照します。プロンプト / レスポンスはログ化し、CloudTrail / S3 で監査証跡を確保。モデル別・チーム別の使用量とコストの可視化を設計目標とします。可用性や精度は構成・モデル・データ整備・テストに依存します。
★ 設計のポイント
- ▸社内AI APIの共通入口を ECS で集約し、認証・権限・ログを一元化
- ▸Amazon Bedrock へ PrivateLink で閉域アクセス(公衆経路を回避)
- ▸Bedrock Knowledge Bases によるRAG(ベクトル検索 + 社内文書参照)
- ▸Bedrock Guardrails で入出力をフィルタリング(機微情報の抑止)
- ▸プロンプト/レスポンスのログ化とモデル別コスト可視化(設計目標)
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
CI/CD・配信
コスト・可視化
コピーしてすぐ使える IaC
エンタープライズAIゲートウェイ基盤(ECS + Amazon Bedrock)を再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as ec2 from "aws-cdk-lib/aws-ec2";
import * as ecs from "aws-cdk-lib/aws-ecs";
import * as ecsPatterns from "aws-cdk-lib/aws-ecs-patterns";
import * as iam from "aws-cdk-lib/aws-iam";
import * as s3 from "aws-cdk-lib/aws-s3";
import * as oss from "aws-cdk-lib/aws-opensearchserverless";
// 社内AIゲートウェイ:内部ALB配下のECS。Bedrock は PrivateLink(VPCエンドポイント)で閉域アクセス。
export class AiGatewayStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const vpc = new ec2.Vpc(this, "Vpc", { maxAzs: 2, natGateways: 1 });
const cluster = new ecs.Cluster(this, "Cluster", { vpc });
// Bedrock への閉域アクセス(Interface VPC Endpoint = PrivateLink)
vpc.addInterfaceEndpoint("BedrockRuntime", {
service: new ec2.InterfaceVpcEndpointService(`com.amazonaws.${this.region}.bedrock-runtime`),
});
const docs = new s3.Bucket(this, "Docs", {
encryption: s3.BucketEncryption.KMS_MANAGED,
enforceSSL: true,
blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
});
// RAG 用ベクトルストア(OpenSearch Serverless コレクション)
new oss.CfnCollection(this, "VectorStore", { name: "enterprise-ai-gateway-ecs-bedrock-vectors", type: "VECTORSEARCH" });
const svc = new ecsPatterns.ApplicationLoadBalancedFargateService(this, "Gateway", {
cluster,
cpu: 1024,
memoryLimitMiB: 2048,
desiredCount: 2,
publicLoadBalancer: false, // 内部ALB(社内/閉域からのみ)
taskImageOptions: { image: ecs.ContainerImage.fromRegistry("public.ecr.aws/nginx/nginx:stable"), containerPort: 80 },
});
// タスクロールに Bedrock 呼び出し権限(最小権限)
svc.taskDefinition.taskRole.addToPrincipalPolicy(new iam.PolicyStatement({
actions: ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
resources: ["*"],
}));
docs.grantRead(svc.taskDefinition.taskRole);
}
}この構成を選ぶ理由
エンタープライズAIゲートウェイ基盤(ECS + Amazon Bedrock)は、全社共通(複数部門のAI利用を集約)を想定し、AZ障害への耐性と運用現実性を重視する場合に選びやすい構成です。
選定フロー
業務要件を確認する
AI共通基盤で求められる可用性、RTO/RPO、データ分類を確認する。
運用体制を確認する
チームが AWS Native の運用、監視、権限管理を継続できるかを確認する。
コストと拡張性を比較する
月 200,000 円〜(常時稼働タスク + モデル従量、利用量に依存)を許容し、将来のスケールやDR要件に対応できるかを判断する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
最小構成 | 低い | 単純だが手動復旧が多い | 限定的 | PoC、検証、小規模な開始段階 |
エンタープライズAIゲートウェイ基盤(ECS + Amazon Bedrock)採用 | 高い | AWS標準運用で管理可能 | 段階的に拡張可能 | 社内ナレッジに基づくRAGチャット・ドキュメント検索 |
上位冗長化構成 | 高い | 設計・監視・訓練が増える | 高い | 厳格なSLA、DR、監査要件がある場合 |
採用時のトレードオフ
設計前提の確認が必要
コストと運用負荷のバランス
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
AI共通基盤
プラットフォーム
AWS Native
重要度
高(全社のAI利用を集約する共通基盤)
接続方式
閉域アクセス(Bedrock PrivateLink / 社内からのプライベート接続)
データ分類
機密(社内ドキュメント / プロンプト・レスポンス)
✔ データ活用・統制の設計目標
- •Bedrock への PrivateLink 閉域アクセスを設計目標とし、公衆経路を避ける
- •Cognito / 外部IdP による認証と、API 単位の権限制御を行う
- •Bedrock Guardrails による入出力フィルタリング(不適切・機微情報の抑止)
- •プロンプト / レスポンスのログ化と監査証跡(CloudTrail / S3)を確保する
- •KMS による暗号化・Secrets Manager による資格情報保護・最小権限
- •モデル別・チーム別の使用量 / コストの可視化と上限管理を行う
⚠ 前提条件・留意事項
- •記載のSLA/可用性は設計目標であり、実値はリージョン・モデル・構成・テストに依存する
- •Bedrock の利用可能モデル・リージョン・クォータは契約・設定に依存する
- •RAG の回答精度はドキュメント整備・チャンク設計・埋め込みモデルに依存する
- •生成AIの出力は確率的であり、Guardrails は抑止であって完全な保証ではない
✓ メリット
- •社内AI利用の入口を集約し、認証・権限・監査・コストを統制しやすい
- •PrivateLink 閉域アクセスで機微データの公衆経路流出を抑止
- •Bedrock Knowledge Bases でRAGを比較的少ない実装で構築可能
- •Guardrails でプロンプトインジェクション・機微情報出力を緩和
✗ デメリット
- •常時稼働の ECS とモデル従量でコストが大きくなりやすい
- •RAG 精度はドキュメント整備・チャンク/埋め込み設計に強く依存
- •生成AI出力は確率的で、ガードレールは抑止であり完全な保証ではない
- •モデル/リージョン/クォータなど Bedrock 側の制約管理が必要
→ 主なユースケース
- •社内ナレッジに基づくRAGチャット・ドキュメント検索
- •全社共通の生成AI API ゲートウェイ(権限・コスト統制付き)
- •問い合わせ要約・ドラフト生成など業務支援AI