クラウドネイティブ金融AP基盤(ECS Fargate / DevSecOps)
VPC Lattice サービスメッシュ × 多段セキュリティスキャン × ハイブリッド接続
可用性 (SLA目標)
99.9% 以上(Multi-AZ + Aurora マルチAZ)
RTO(目標復旧時間)
数分(ECSタスク自動再配置 + Aurora 自動フェイルオーバー)
RPO(目標復旧時点)
ほぼ 0(Aurora 同期レプリケーション)
概算コスト
月 300,000 円〜(冗長化・セキュリティ運用・専用線を含む)
構成概要
- 可用性レベル
- マルチAZ
- コンピューティング
- ECS/Fargate
- 想定システム規模
- 大規模(金融機関の顧客チャネル・取引API基盤)
- コスト感
- ¥¥¥高コスト
使用AWSサービス
- Amazon ECS (Fargate)
- Amazon VPC Lattice
- Amazon Aurora PostgreSQL (Multi-AZ)
- AWS WAF / AWS Shield Advanced
- AWS Network Firewall (+ Proxy)
- Amazon ECR (Enhanced Scanning)
- Amazon Inspector
- Amazon GuardDuty (Runtime Monitoring)
- AWS Direct Connect
- AWS Transit Gateway
- AWS KMS
- AWS Secrets Manager
- AWS Security Hub
概要
ECS Fargate でコンテナをサーバーレス実行し、サービス間通信を Amazon VPC Lattice(mTLS・L7認可)で束ねたクラウドネイティブな金融AP基盤です。Kubernetes を持たず AWS マネージドサービスでサービスメッシュ相当を実現するため、運用負荷を抑えつつ多層防御を構築できます。接続はハイブリッドで、顧客チャネルはインターネット公開(WAF + Shield + ALB)、勘定系・外接や社内網は Direct Connect + Transit Gateway の閉域で受けます。境界は AWS Network Firewall(IPS/IDS・ドメインallowlist)、外向き通信は Network Firewall Proxy(FQDN allowlist + TLSインスペクション)で統制。セキュリティは CI/CD の SAST(Inspector Code Security)・SCA(BlackDuck)・IaCスキャン・コンテナイメージスキャン(Trivy + ECR Enhanced Scanning)から、デプロイ時の Cosign 署名検証、ランタイムの GuardDuty Runtime Monitoring まで多段で組み込みます。
★ 設計のポイント
- ▸VPC Lattice でサービスメッシュ相当(mTLS・認可ポリシー)を Kubernetes なしで実現
- ▸ハイブリッド接続:公開チャネルは WAF/Shield/ALB、閉域は Direct Connect + TGW
- ▸境界=Network Firewall、egress=Network Firewall Proxy で内向き/外向きを分離統制
- ▸CI/CDに SAST/SCA(BlackDuck)/IaC/イメージスキャンを多段で組込み、Cosign署名を強制
- ▸GuardDuty Runtime Monitoring(Fargateエージェント)でランタイム脅威を検知
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・可観測性
セキュリティ・統制
CI/CD・DevSecOps
バックアップ・DR
コピーしてすぐ使える IaC
ECS Fargate サービス、VPC Lattice、ECR Enhanced Scanning(Inspector)、WAF を立ち上げる雛形です。実運用では BlackDuck/Trivy のCIゲート、Cosign 署名検証、Network Firewall(Proxy)、Secrets Manager 参照を併せて構成してください。
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 ecr from "aws-cdk-lib/aws-ecr";
import * as rds from "aws-cdk-lib/aws-rds";
export class CloudNativeEcsSecopsStack 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: 2 });
// Enhanced Scanning (Amazon Inspector) を有効化したリポジトリ
const repo = new ecr.Repository(this, "AppRepo", {
imageScanOnPush: true,
encryption: ecr.RepositoryEncryption.KMS,
});
const cluster = new ecs.Cluster(this, "Cluster", {
vpc,
containerInsightsV2: ecs.ContainerInsights.ENHANCED,
});
const db = new rds.DatabaseCluster(this, "Aurora", {
engine: rds.DatabaseClusterEngine.auroraPostgres({
version: rds.AuroraPostgresEngineVersion.VER_16_1,
}),
writer: rds.ClusterInstance.provisioned("writer"),
readers: [rds.ClusterInstance.provisioned("reader")],
vpc,
storageEncrypted: true,
vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
removalPolicy: cdk.RemovalPolicy.RETAIN,
});
const svc = new ecsPatterns.ApplicationLoadBalancedFargateService(this, "Svc", {
cluster,
cpu: 512,
memoryLimitMiB: 1024,
desiredCount: 2,
publicLoadBalancer: true,
taskImageOptions: {
image: ecs.ContainerImage.fromEcrRepository(repo),
containerPort: 8080,
},
});
db.connections.allowDefaultPortFrom(svc.service);
// WAF / VPC Lattice / Network Firewall は別スタックで関連付け
}
}この構成を選ぶ理由
Kubernetes の運用スキルを前提とせず、AWS マネージドサービスでサービスメッシュ・多層セキュリティを実現したい場合に適した構成です。
選定フロー
Kubernetes 運用スキルを持つか
K8s/Istio/Prometheus を継続運用できるチームがあるか。
サービスメッシュの粒度を決める
L7ルーティング・mTLS・認可が AWS マネージド範囲で足りるか。
VPC Lattice はメッシュ運用コストを抑えつつ mTLS と認可を提供する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
ECS Fargate + VPC Lattice採用 | 中〜高 | AWSスキルで完結。OS/K8s運用なし | 高い | K8sを持たずメッシュ+多層防御を実現したい金融AP基盤 |
EKS + Istio | 高 | K8s+Istio+可観測性の運用が必要 | 非常に高い | CNCFをフル活用し細かい制御・移植性を重視する場合 |
Lambda + API Gateway | 低〜中 | 低い | 非常に高い | イベント駆動・API中心で常時稼働が不要な場合 |
採用時のトレードオフ
VPC Lattice は Istio ほど機能が広くない
egress プロキシはプレビュー機能を含む
リージョン障害は別設計
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
チャネル系・AP基盤
重要度
高(顧客チャネル / 取引系の基盤)
DR方式
Multi-AZ 冗長(同一リージョン / リージョンDRは拡張余地)
接続方式
ハイブリッド(インターネット公開 + Direct Connect 閉域)
データ分類
機密(取引・個人情報)
✔ データ活用・統制の設計目標
- •保存時・転送時の暗号化(KMS / TLS 1.2+)を全層で設計目標とする
- •egress(外向き)通信を FQDN allowlist で制御し、許可先以外への通信を遮断する
- •イメージは署名(Cosign)し、未署名・未スキャンのイメージのデプロイを禁止する
- •SAST・SCA・IaC・イメージ・ランタイムの多段スキャンを CI/CD とランタイムに組み込む
- •IAM 最小権限・タスクロール分離・CloudTrail 監査証跡で職務分離と追跡性を確保する
- •FISC 安全対策基準・PCI DSS v4 の管理策と対応づけて統制を整理する
⚠ 前提条件・留意事項
- •記載のSLA/RTO/RPOは設計目標であり、実値は構成・運用・テスト条件に依存する
- •BlackDuck 等の商用SCAのライセンス・運用体制が別途整っていることを前提とする
- •AWS Network Firewall Proxy はプレビュー機能を含むため、本番採用は提供状況の確認を要する
- •リージョン全体障害への対応はマルチリージョンDR構成の追加検討を要する
✓ メリット
- •Kubernetes を持たずにサービスメッシュ(mTLS・認可)と多層防御を実現
- •ハイブリッド接続で公開チャネルと閉域系を1つの基盤に集約
- •CI/CDからランタイムまでセキュリティスキャンを多段で自動化
- •Fargate でOS運用が不要、AWSスキル中心で運用が完結
✗ デメリット
- •VPC Lattice は Istio に比べトラフィック制御の自由度が低い
- •セキュリティツール(BlackDuck/Trivy/Cosign等)の統合・運用設計が必要
- •egress プロキシのプレビュー機能依存に留意が必要
- •リージョン全体障害には別途DR設計が必要
→ 主なユースケース
- •金融機関の顧客チャネル・取引APIのモダナイズ
- •K8sの運用負荷を避けつつ多層セキュリティを満たしたいコンテナ基盤
- •公開系と閉域系を統合したハイブリッドなAP基盤