クラウドネイティブ金融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 ネイティブな可観測性
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・可観測性
セキュリティ・統制
CI/CD・GitOps
バックアップ・DR
コピーしてすぐ使える IaC
EKS クラスター本体は Terraform、メッシュ/ポリシー/GitOps は Helm/Kustomize で管理する分担の雛形です。実運用では IRSA、OPA/Gatekeeper、Cosign 検証、External Secrets、Network Firewall(Proxy) を併せて構成してください。
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 を重視する場合に適した構成です。
選定フロー
Kubernetes 運用体制があるか
K8s/Istio/Prometheus/ArgoCD を継続運用できるチームがあるか。
求める制御の粒度
トラフィックシフト・サイドカー・アドミッション制御など細かい統制が要るか。
Istio + OPA は高い制御性を提供するが、運用の成熟度を要する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
EKS + Istio採用 | 高 | K8s+Istio+可観測性の運用が必要 | 非常に高い | CNCFをフル活用し細かい制御・GitOps・移植性を重視する金融AP基盤 |
ECS Fargate + VPC Lattice | 中〜高 | AWSスキルで完結。K8s運用なし | 高い | K8sを持たずメッシュ+多層防御を実現したい場合 |
Lambda + API Gateway | 低〜中 | 低い | 非常に高い | イベント駆動・API中心で常時稼働が不要な場合 |
採用時のトレードオフ
運用の成熟度が必須
設定ミスの表面積が広い
リージョン障害は別設計
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
チャネル系・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 を重視する基盤
- •移植性(マルチクラウド/ハイブリッド)を見据えたコンテナ基盤