インターネット / モバイルバンキング(チャネル系)
顧客チャネルの認証・API保護・監査ログ・高可用性
可用性 (SLA目標)
99.9% を設計目標(Multi-AZ 冗長 + Aurora マルチAZ、前提条件付き)
RTO(目標復旧時間)
数分目安(ALB/タスク自動再配置 + Aurora 自動フェイルオーバー、構成・訓練に依存)
RPO(目標復旧時点)
ほぼ 0 を目標(Aurora 同期レプリケーション、運用条件に依存)
概算コスト
月 200,000 円〜(トラフィック・WAF/Shield 等に依存)
構成概要
- 可用性レベル
- マルチAZ
- コンピューティング
- ECS/Fargate
- 想定システム規模
- 中〜大規模(個人向けバンキングチャネル)
- コスト感
- ¥¥¥高コスト
使用AWSサービス
- Amazon CloudFront
- AWS WAF / AWS Shield
- Amazon API Gateway
- Amazon Cognito
- Amazon ECS (Fargate)
- Amazon Aurora (Multi-AZ)
- Amazon DynamoDB
- Amazon CloudWatch
- AWS CloudTrail
- AWS KMS
概要
個人向けのインターネット / モバイルバンキングを想定したチャネル系構成です。CloudFront + WAF / Shield で配信と境界防御を行い、API Gateway 経由で Cognito / 外部IdP による認証を実施。バックエンドは Multi-AZ の ECS Fargate がビジネスロジックを処理し、Aurora(Writer/Reader)と DynamoDB(セッション)でデータを保持します。CloudTrail・KMS・GuardDuty 等で監査・暗号化・脅威検知の非機能要件を満たすことを設計目標とします。可用性・復旧目標は設計目標であり、実値は構成・運用・テスト条件に依存します。
★ 設計のポイント
- ▸CloudFront + WAF / Shield による配信最適化と境界防御・DDoS緩和
- ▸Cognito / 外部IdP による認証(多要素・リスクベース認証は拡張余地)
- ▸Multi-AZ の ECS Fargate + Aurora で可用性を確保(設計目標)
- ▸DynamoDB をセッションストアに用い、ステートレスなチャネル設計
- ▸CloudTrail / KMS / GuardDuty による監査・暗号化・脅威検知
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
配信・保護
バックアップ・DR
コピーしてすぐ使える IaC
インターネット / モバイルバンキング(チャネル系)を再現するためのスターター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 rds from "aws-cdk-lib/aws-rds";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";
import * as cognito from "aws-cdk-lib/aws-cognito";
import * as cloudfront from "aws-cdk-lib/aws-cloudfront";
import * as origins from "aws-cdk-lib/aws-cloudfront-origins";
import * as wafv2 from "aws-cdk-lib/aws-wafv2";
// 顧客チャネル:CloudFront + WAF を前段に、ECS Fargate(内部ALB) + Aurora + DynamoDB(セッション)。
export class ChannelBankingStack 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 });
const userPool = new cognito.UserPool(this, "Customers", { selfSignUpEnabled: false });
const service = new ecsPatterns.ApplicationLoadBalancedFargateService(this, "Channel", {
cluster,
cpu: 512,
memoryLimitMiB: 1024,
desiredCount: 2,
publicLoadBalancer: false, // 内部 ALB(前段は CloudFront/WAF)
taskImageOptions: { image: ecs.ContainerImage.fromRegistry("public.ecr.aws/nginx/nginx:stable"), containerPort: 80 },
});
const sessions = new dynamodb.Table(this, "Sessions", {
partitionKey: { name: "sessionId", type: dynamodb.AttributeType.STRING },
billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
timeToLiveAttribute: "ttl",
});
sessions.grantReadWriteData(service.taskDefinition.taskRole);
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,
});
const waf = new wafv2.CfnWebACL(this, "Waf", {
scope: "CLOUDFRONT",
defaultAction: { allow: {} },
visibilityConfig: { cloudWatchMetricsEnabled: true, metricName: "channelWaf", sampledRequestsEnabled: true },
rules: [],
});
new cloudfront.Distribution(this, "Cdn", {
defaultBehavior: { origin: new origins.LoadBalancerV2Origin(service.loadBalancer) },
webAclId: waf.attrArn,
});
void userPool;
}
}この構成を選ぶ理由
インターネット / モバイルバンキング(チャネル系)は、中〜大規模(個人向けバンキングチャネル)を想定し、AZ障害への耐性と運用現実性を重視する場合に選びやすい構成です。
選定フロー
業務要件を確認する
チャネル系で求められる可用性、RTO/RPO、データ分類を確認する。
運用体制を確認する
チームが AWS Native の運用、監視、権限管理を継続できるかを確認する。
コストと拡張性を比較する
月 200,000 円〜(トラフィック・WAF/Shield 等に依存)を許容し、将来のスケールやDR要件に対応できるかを判断する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
最小構成 | 低い | 単純だが手動復旧が多い | 限定的 | PoC、検証、小規模な開始段階 |
インターネット / モバイルバンキング(チャネル系)採用 | 高い | AWS標準運用で管理可能 | 段階的に拡張可能 | 個人向けインターネットバンキング / 残高照会・振込 |
上位冗長化構成 | 高い | 設計・監視・訓練が増える | 高い | 厳格なSLA、DR、監査要件がある場合 |
採用時のトレードオフ
設計前提の確認が必要
コストと運用負荷のバランス
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
チャネル系
重要度
高(顧客接点 / 個人情報・取引を扱う)
DR方式
Multi-AZ 冗長(リージョンDRは拡張余地として併記)
接続方式
インターネット公開(CloudFront + WAF / Shield)
データ分類
機密(個人情報・口座 / 取引情報)
✔ データ活用・統制の設計目標
- •Cognito / 外部IdP による認証と多要素認証を設計目標とする
- •WAF / Shield と CloudFront による境界防御・DDoS緩和を図る
- •KMS による保存時暗号化と Secrets Manager での認証情報保護
- •CloudTrail による操作・アクセスの監査証跡を確保する
- •IAM 最小権限とサブネット分離による多層防御
⚠ 前提条件・留意事項
- •記載のSLA/RTO/RPOは設計目標であり、実値は構成・運用・テスト条件に依存する
- •認証強度・不正対策(端末認証・リスクベース認証等)は要件に応じ追加設計が必要
- •本人確認・チャネル規制への適合性は別途の評価を要する
✓ メリット
- •CloudFront + WAF / Shield で配信と境界防御を両立
- •Cognito / 外部IdP で認証基盤を委譲し、実装負荷を低減
- •Multi-AZ の ECS Fargate + Aurora で可用性を確保しやすい
- •DynamoDB セッションでステートレス化し、水平スケールが容易
✗ デメリット
- •WAF / Shield Advanced や常時稼働タスクでコストが増えやすい
- •リージョン全体障害にはマルチリージョンDRの追加検討が必要
- •不正対策・認証強化は要件に応じた継続的な作り込みが必要
- •監査・本人確認など金融チャネル特有の非機能要件が多い
→ 主なユースケース
- •個人向けインターネットバンキング / 残高照会・振込
- •モバイルバンキングアプリのバックエンドAPI
- •顧客向け金融ポータル・各種オンライン手続き