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

クラウドネイティブ金融AP基盤(EKS / CNCF / GitOps)

Istio サービスメッシュ × CNCFスタック × ArgoCD GitOps × ハイブリッド接続

可用性 (SLA目標)

99.9% 以上(Multi-AZ + Aurora マルチAZ)

RTO(目標復旧時間)

数分(Pod自動再スケジュール + Aurora 自動フェイルオーバー)

RPO(目標復旧時点)

ほぼ 0(Aurora 同期レプリケーション)

概算コスト

月 400,000 円〜(EKS・冗長化・セキュリティ運用・専用線を含む)

構成概要

可用性レベル
マルチAZ
コンピューティング
Managed / SaaS
想定システム規模
大規模(金融機関の顧客チャネル・取引API基盤)
コスト感
¥¥¥高コスト

使用AWSサービス

  • Amazon EKS
  • Istio (Service Mesh)
  • Argo CD (GitOps)
  • Amazon Aurora PostgreSQL (Multi-AZ)
  • AWS WAF / AWS Shield Advanced
  • AWS Network Firewall (+ Proxy)
  • Amazon ECR (Enhanced Scanning)
  • Amazon Inspector
  • Amazon GuardDuty (EKS Runtime Monitoring)
  • Falco
  • OPA/Gatekeeper
  • AWS Direct Connect
  • AWS Transit Gateway
  • AWS KMS
  • AWS Secrets Manager

概要

Amazon EKS 上に Istio サービスメッシュ(mTLS STRICT・認可・Kiali可視化)を敷き、CNCF スタックで可観測性とポリシー強制を構成したクラウドネイティブ金融AP基盤です。デプロイは ArgoCD による pull 型 GitOps で Git を唯一の真実源とし、構成ドリフトを継続的に検出・是正します。接続はハイブリッドで、顧客チャネルはインターネット公開(WAF + Shield + ALB/Ingress)、勘定系・外接や社内網は Direct Connect + Transit Gateway の閉域で受けます。境界は AWS Network Firewall、外向き通信は Network Firewall Proxy(FQDN allowlist + TLS検査)で統制。セキュリティは CI の SAST(Inspector Code Security)・SCA(BlackDuck)・IaCスキャン・コンテナイメージスキャン(Trivy + ECR Enhanced Scanning)から、アドミッション時の OPA/Gatekeeper・Cosign 署名検証、ランタイムの Falco + GuardDuty EKS Runtime Monitoring まで多段で組み込みます。

設計のポイント

  • EKS + Istio で mTLS(STRICT)・認可・Kiali トポロジ可視化を実現
  • ArgoCD による pull型 GitOps で Git を真実源にドリフト検出・自動同期
  • OPA/Gatekeeper + Cosign で未署名・特権コンテナのデプロイをブロック
  • Falco(syscall)+ GuardDuty EKS Runtime Monitoring の二重ランタイム監視
  • Prometheus / Grafana / OpenTelemetry で CNCF ネイティブな可観測性

システム構成図

AWS CloudVPC(ハイブリッド接続)Amazon EKS クラスター(Istio サービスメッシュ / mTLS)Data サブネット (Isolated / Multi-AZ)Egress サブネットパブリック(Ingress)サブネットDirect Connect閉域mTLS同期レプリケーションegresspush / 署名imageGitOps 同期インターネット(顧客チャネル)社内 / 外部金融網全銀ネット勘定系・外接Direct Connect(閉域)WAF + ShieldALB / Ingress(HTTPS 443)TransitGatewayAWS Network Firewall境界 IPS/IDSドメイン allowlistIstio Ingress GatewaymTLS / 認可EKS Node(AZ-a)EKS Node(AZ-c)Falco / GuardDuty EKS Runtimeランタイム検知AuroraWriter (AZ-a)AuroraReader (AZ-c)Network Firewall Proxyegress / FQDN allowTLS インスペクションNAT GWIGWArgoCD (GitOps)pull型 同期ドリフト検出CI / DevSecOpsSAST: InspectorSCA: BlackDuckTrivy / OPACosign 署名ECR(署名イメージ)

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

監視・可観測性

Prometheus / GrafanaPrometheus / GrafanaOpenTelemetry / KialiOpenTelemetry / KialiCloudTrailCloudTrailAWS ConfigAWS Config

セキュリティ・統制

GuardDuty EKS RuntimeGuardDuty EKS RuntimeSecurity Hub / InspectorSecurity Hub / InspectorWAFWAFShield AdvancedShield AdvancedKMSKMSSecrets ManagerSecrets ManagerIRSA(最小権限)IRSA(最小権限)

CI/CD・GitOps

CodeBuild (CI)CodeBuild (CI)ECR Enhanced ScanECR Enhanced ScanArgoCD (GitOps)ArgoCD (GitOps)

バックアップ・DR

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

コピーしてすぐ使える IaC

EKS クラスター本体は Terraform、メッシュ/ポリシー/GitOps は Helm/Kustomize で管理する分担の雛形です。実運用では IRSA、OPA/Gatekeeper、Cosign 検証、External Secrets、Network Firewall(Proxy) を併せて構成してください。

hcl
module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "cloudnative-fin"
  cluster_version = "1.31"
  vpc_id          = var.vpc_id
  subnet_ids      = var.private_subnet_ids

  # コントロールプレーンの監査ログを全種別有効化
  cluster_enabled_log_types = ["api", "audit", "authenticator", "controllerManager", "scheduler"]

  # KMS でシークレットを暗号化(封筒暗号化)
  create_kms_key            = true
  cluster_encryption_config = { resources = ["secrets"] }

  cluster_endpoint_public_access  = false
  cluster_endpoint_private_access = true

  eks_managed_node_groups = {
    app = {
      instance_types = ["m6i.large"]
      min_size       = 2
      max_size       = 6
      desired_size   = 3
      subnet_ids     = var.private_subnet_ids
    }
  }
}

# ECR Enhanced Scanning(Amazon Inspector)
resource "aws_ecr_repository" "app" {
  name                 = "cloudnative-fin-app"
  image_tag_mutability = "IMMUTABLE"
  image_scanning_configuration { scan_on_push = true }
  encryption_configuration { encryption_type = "KMS" }
}

resource "aws_inspector2_enabler" "this" {
  account_ids    = [data.aws_caller_identity.current.account_id]
  resource_types = ["ECR", "LAMBDA", "EC2"]
}

# GuardDuty EKS Runtime Monitoring
resource "aws_guardduty_detector_feature" "eks_runtime" {
  detector_id = var.guardduty_detector_id
  name        = "EKS_RUNTIME_MONITORING"
  status      = "ENABLED"

  additional_configuration {
    name   = "EKS_ADDON_MANAGEMENT"
    status = "ENABLED"
  }
}

data "aws_caller_identity" "current" {}

この構成を選ぶ理由

Kubernetes / Istio を継続運用できる体制があり、CNCF をフル活用して細かい制御・移植性・GitOps を重視する場合に適した構成です。

選定フロー

1

Kubernetes 運用体制があるか

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

ある → 本構成(EKS)ない → ECS + VPC Lattice 版
2

求める制御の粒度

トラフィックシフト・サイドカー・アドミッション制御など細かい統制が要るか。

細かく要る → EKS + Istioマネージドで十分 → ECS + VPC Lattice

Istio + OPA は高い制御性を提供するが、運用の成熟度を要する。

代替案との比較

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

採用時のトレードオフ

!

運用の成熟度が必須

EKS バージョン更新、Istio/アドオンのライフサイクル、Prometheus/ArgoCD 運用など、継続的な作り込みと専門知識が前提になります。
!

設定ミスの表面積が広い

RBAC・NetworkPolicy・PSS・IRSA・アドミッション制御など統制ポイントが多く、ガードレール(OPA/Config)と監査が欠かせません。
i

リージョン障害は別設計

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

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

境界防御:AWS WAF(OWASP/レート制限)+ Shield Advanced(ALB/Ingress 前段)
ネットワーク境界:AWS Network Firewall(Suricata互換シグネチャ・ドメインallowlist)
egress統制:AWS Network Firewall Proxy / フォワードプロキシで FQDN allowlist + TLS検査
Pod境界:Pod Security Standards(Restricted) + Kubernetes NetworkPolicy で最小権限
サービス間:Istio mTLS(STRICT) + AuthorizationPolicy で相互認証・認可
静的解析(SAST):Amazon Inspector Code Security / SonarQube / Semgrep をPRゲートに
OSS構成解析(SCA):BlackDuck で CVE + ライセンスコンプライアンス + SBOM 生成
IaCスキャン:Inspector(IaC) / Checkov / kube-linter でマニフェストとIaCを検査
コンテナイメージスキャン:CIで Trivy、レジストリで ECR Enhanced Scanning(Inspector)
アドミッション制御:OPA/Gatekeeper・Kyverno + Cosign 署名検証でデプロイを統制
ランタイムセキュリティ:Falco(syscall異常検知)+ GuardDuty EKS Runtime Monitoring
暗号化:KMS による EBS/Aurora/S3 の保存時暗号化、通信は TLS 1.2+ を強制
秘密情報:External Secrets Operator → Secrets Manager 連携(Podへ直接注入しない)
認可:IRSA(IAM Roles for Service Accounts)で Pod 単位の最小権限
統制・監査:CloudTrail / EKS Audit Logs / Config / Security Hub で証跡と準拠確認

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

業務領域

チャネル系・AP基盤

重要度

高(顧客チャネル / 取引系の基盤)

DR方式

Multi-AZ 冗長(同一リージョン / リージョンDRは拡張余地)

接続方式

ハイブリッド(インターネット公開 + Direct Connect 閉域)

データ分類

機密(取引・個人情報)

データ活用・統制の設計目標

  • Pod Security Standards(Restricted)・NetworkPolicy で Pod 間を最小権限化する
  • OPA/Gatekeeper・Kyverno で未署名イメージ・特権コンテナのデプロイを禁止する
  • Istio mTLS(STRICT) で全サービス間通信を相互認証・暗号化する
  • GitOps(ArgoCD)で Git を唯一の真実源とし、構成ドリフトを検出・是正する
  • SAST・SCA・IaC・イメージ・ランタイムの多段スキャンを組み込む
  • FISC 安全対策基準・PCI DSS v4 の管理策と対応づけて統制を整理する

前提条件・留意事項

  • 記載のSLA/RTO/RPOは設計目標であり、実値は構成・運用・テスト条件に依存する
  • Kubernetes / Istio / Prometheus を継続運用できる体制があることを前提とする
  • BlackDuck 等の商用SCAのライセンス・運用体制が別途整っていることを前提とする
  • リージョン全体障害への対応はマルチリージョンDR構成の追加検討を要する

メリット

  • Istio + CNCF で mTLS・認可・可観測性・ポリシー強制をフル活用
  • ArgoCD の pull型 GitOps で Git を真実源にドリフトを自動是正
  • Falco + GuardDuty の二重ランタイム監視で異常を多角的に検知
  • OPA/Gatekeeper + Cosign で未署名・特権コンテナのデプロイを抑止

デメリット

  • Kubernetes / Istio / 可観測性スタックの運用に高い成熟度が必要
  • 統制ポイントが多く、設定ミスの表面積が広い
  • ECS 版よりコスト・学習コストが高い
  • リージョン全体障害には別途DR設計が必要

主なユースケース

  • CNCF をフル活用したい金融機関の次世代AP基盤
  • マイクロサービスの細かいトラフィック制御・GitOps を重視する基盤
  • 移植性(マルチクラウド/ハイブリッド)を見据えたコンテナ基盤
金融クラウドネイティブEKSKubernetesCNCFIstioGitOpsArgoCDFalcoDevSecOpsハイブリッド