AWS
AWS構成事例カタログ
金融 / クラウドネイティブマルチAZECS/Fargate

クラウドネイティブ金融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エージェント)でランタイム脅威を検知

システム構成図

AWS CloudVPC(ハイブリッド接続)Data サブネット (Isolated / Multi-AZ)Egress サブネットパブリック(Ingress)サブネットApplication サブネット (AZ-a)Application サブネット (AZ-c)Direct Connect閉域mTLS同期レプリケーションegresspush / 署名image pullインターネット(顧客チャネル)社内 / 外部金融網全銀ネット勘定系・外接Direct Connect(閉域)WAF + ShieldALB(HTTPS 443)TransitGatewayAWS Network Firewall境界 IPS/IDSドメイン allowlistECS Fargate(AZ-a)ECS Fargate(AZ-c)VPC LatticeサービスメッシュmTLS / 認可AuroraWriter (AZ-a)AuroraReader (AZ-c)Network Firewall Proxyegress / FQDN allowTLS インスペクションNAT GWIGWDevSecOps PipelineSAST: InspectorSCA: BlackDuckイメージ: Trivy/ECR署名: CosignECR(署名イメージ)

周辺・運用機能(クロスカッティング / 全体に適用)

監視・可観測性

Container InsightsContainer InsightsADOT / OpenTelemetryADOT / OpenTelemetryCloudTrailCloudTrailAWS ConfigAWS Config

セキュリティ・統制

GuardDuty RuntimeGuardDuty RuntimeSecurity Hub / InspectorSecurity Hub / InspectorWAFWAFShield AdvancedShield AdvancedKMSKMSSecrets ManagerSecrets ManagerIAM(最小権限)IAM(最小権限)

CI/CD・DevSecOps

CodePipelineCodePipelineCodeBuildCodeBuildECR Enhanced ScanECR Enhanced Scan

バックアップ・DR

AWS BackupAWS BackupS3(監査ログ)S3(監査ログ)
リージョンVPCプライベートパブリック概念図 / アイコン: AWS Architecture Icons

コピーしてすぐ使える IaC

ECS Fargate サービス、VPC Lattice、ECR Enhanced Scanning(Inspector)、WAF を立ち上げる雛形です。実運用では BlackDuck/Trivy のCIゲート、Cosign 署名検証、Network Firewall(Proxy)、Secrets Manager 参照を併せて構成してください。

typescript
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 マネージドサービスでサービスメッシュ・多層セキュリティを実現したい場合に適した構成です。

選定フロー

1

Kubernetes 運用スキルを持つか

K8s/Istio/Prometheus を継続運用できるチームがあるか。

ある → EKS版も検討ない / 増やしたくない → 本構成(ECS)
2

サービスメッシュの粒度を決める

L7ルーティング・mTLS・認可が AWS マネージド範囲で足りるか。

足りる → VPC Latticeより細かい制御が要る → EKS + Istio

VPC Lattice はメッシュ運用コストを抑えつつ mTLS と認可を提供する。

代替案との比較

候補コスト運用保守負荷スケーラビリティ選定すべきケース
ECS Fargate + VPC Lattice採用
中〜高AWSスキルで完結。OS/K8s運用なし高いK8sを持たずメッシュ+多層防御を実現したい金融AP基盤
EKS + Istio
K8s+Istio+可観測性の運用が必要非常に高いCNCFをフル活用し細かい制御・移植性を重視する場合
Lambda + API Gateway
低〜中低い非常に高いイベント駆動・API中心で常時稼働が不要な場合

採用時のトレードオフ

i

VPC Lattice は Istio ほど機能が広くない

高度なトラフィックシフトやサイドカー前提の細かい制御は Istio に劣ります。要件がマネージド範囲を超える場合は EKS + Istio を検討してください。
!

egress プロキシはプレビュー機能を含む

AWS Network Firewall Proxy はプレビュー段階を含むため、本番では提供状況・SLAを確認し、必要に応じて Squid 等のフォワードプロキシで代替してください。
!

リージョン障害は別設計

本構成は Multi-AZ 冗長であり、リージョン全断は吸収しません。継続要件が厳しい場合はマルチリージョンDRの追加設計が必要です。

🛡 セキュリティ・コンプライアンスのポイント

境界防御:AWS WAF(OWASP/レート制限)+ Shield Advanced(ALB前段)
ネットワーク境界:AWS Network Firewall(Suricata互換シグネチャ・ドメインallowlist)
egress統制:AWS Network Firewall Proxy / フォワードプロキシで FQDN allowlist + TLS検査
静的解析(SAST):Amazon Inspector Code Security / SonarQube / Semgrep をPRゲートに
OSS構成解析(SCA):BlackDuck で CVE + ライセンスコンプライアンス + SBOM 生成
IaCスキャン:Inspector(IaC) / Checkov で暗号化漏れ・公開SG等をマージ前に検出
コンテナイメージスキャン:CIで Trivy、レジストリで ECR Enhanced Scanning(Inspector)
イメージ署名:Cosign で署名し、未署名イメージのデプロイをブロック
ランタイムセキュリティ:GuardDuty Runtime Monitoring(プロセス/ファイル/ネットワーク)
暗号化:KMS による EBS/Aurora/S3 の保存時暗号化、通信は TLS 1.2+ を強制
秘密情報:Secrets Manager(自動ローテーション)をタスク定義から参照
統制・監査:CloudTrail / Config / Security Hub(FSBP・PCI DSS)で証跡と準拠確認

🏛 エンタープライズ設計観点・統制

業務領域

チャネル系・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基盤
金融クラウドネイティブECSFargateVPC LatticeサービスメッシュDevSecOpsNetwork FirewallBlackDuckハイブリッド