Open Banking / 外部API公開基盤(API連携)
TPP 接続・OAuth/OIDC・レート制限・監査証跡
可用性 (SLA目標)
99.95% 前後を設計目標(各マネージドサービスのSLAに依存)
RTO(目標復旧時間)
ほぼ即時を目標(マネージドサービスの自動回復、構成に依存)
RPO(目標復旧時点)
ほぼ 0 を目標(DynamoDB は3AZ同期書き込み)
概算コスト
月 30,000〜200,000 円程度(API呼び出し量に依存)
構成概要
- 可用性レベル
- サーバーレス
- コンピューティング
- Lambda
- 想定システム規模
- 中規模(API公開・パートナー連携基盤)
- コスト感
- ¥¥¥中コスト
使用AWSサービス
- Amazon API Gateway
- AWS WAF / AWS Shield
- Amazon Cognito
- AWS Lambda
- AWS PrivateLink
- Amazon SQS
- Amazon EventBridge
- Amazon DynamoDB
- Amazon S3
- AWS CloudTrail
- AWS KMS
概要
外部事業者(TPP: アグリゲーター / フィンテック)へ口座・取引APIを安全に公開する Open Banking 基盤を想定した構成です。WAF を前段に置いた API Gateway で OAuth 2.0 / OIDC の認可とレート制限を行い、Lambda がAPIロジックを実行。同意・トークンは DynamoDB に保持し、非同期処理は SQS / EventBridge で連携します。行内の勘定系・顧客情報へは PrivateLink を介してインターネットを経由せず接続することを設計目標とし、CloudTrail / S3 で監査証跡を確保します。クライアント証明書(mTLS 相当)による事業者認証を想定します。
★ 設計のポイント
- ▸API Gateway + Lambda のサーバーレスで弾力的にスケール
- ▸OAuth 2.0 / OIDC による認可と同意管理(標準準拠を前提)
- ▸使用量プラン / スロットリングによるレート制限と公平利用
- ▸PrivateLink による行内システムへの閉域接続(インターネット非経由)
- ▸CloudTrail / S3 によるAPIアクセスの監査証跡
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
配信・保護
バックアップ・監査
コピーしてすぐ使える IaC
Open Banking / 外部API公開基盤(API連携)を再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as apigw from "aws-cdk-lib/aws-apigateway";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";
export class OpenBankingApiPlatformStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const table = new dynamodb.Table(this, "Table", {
partitionKey: { name: "pk", type: dynamodb.AttributeType.STRING },
sortKey: { name: "sk", type: dynamodb.AttributeType.STRING },
billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
encryption: dynamodb.TableEncryption.AWS_MANAGED,
});
const handler = new lambda.Function(this, "Handler", {
runtime: lambda.Runtime.NODEJS_20_X,
handler: "index.handler",
code: lambda.Code.fromInline("exports.handler = async () => ({ statusCode: 200, body: 'ok' });"),
environment: { TABLE_NAME: table.tableName },
});
table.grantReadWriteData(handler);
new apigw.LambdaRestApi(this, "Api", { handler });
}
}この構成を選ぶ理由
Open Banking / 外部API公開基盤(API連携)は、中規模(API公開・パートナー連携基盤)を想定し、運用負荷の低減とイベント駆動の伸縮性を重視する場合に選びやすい構成です。
選定フロー
業務要件を確認する
API連携で求められる可用性、RTO/RPO、データ分類を確認する。
運用体制を確認する
チームが AWS Native の運用、監視、権限管理を継続できるかを確認する。
コストと拡張性を比較する
月 30,000〜200,000 円程度(API呼び出し量に依存)を許容し、将来のスケールやDR要件に対応できるかを判断する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
最小構成 | 低い | 単純だが手動復旧が多い | 限定的 | PoC、検証、小規模な開始段階 |
Open Banking / 外部API公開基盤(API連携)採用 | 中程度 | AWS標準運用で管理可能 | 需要に応じて高く伸縮 | Open Banking / オープンAPIによる口座・取引情報の公開 |
上位冗長化構成 | 高い | 設計・監視・訓練が増える | 高い | 厳格なSLA、DR、監査要件がある場合 |
採用時のトレードオフ
設計前提の確認が必要
コストと運用負荷のバランス
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
API連携
重要度
高(外部事業者接続 / 顧客同意データを扱う)
DR方式
サーバーレス・マネージドによる多AZ自動冗長(必要に応じ多リージョン)
接続方式
インターネット公開(外部TPP)+ PrivateLink で行内へ閉域接続
データ分類
機密(口座・取引 / 顧客同意・トークン情報)
✔ データ活用・統制の設計目標
- •OAuth 2.0 / OIDC による認可と同意管理を設計目標とする
- •API Gateway のスロットリング・使用量プランでレート制限を行う
- •クライアント証明書(mTLS 相当)による事業者認証を想定する
- •CloudTrail と S3 によるAPIアクセスの監査証跡を確保する
- •PrivateLink で行内システムへインターネットを経由せず接続する
⚠ 前提条件・留意事項
- •記載のSLA/RTO/RPOは設計目標であり、実値は構成・運用・テスト条件に依存する
- •mTLS・同意管理・APIスキーマは Open Banking 標準/各国規制に応じた実装が前提
- •外部事業者の登録・認可・監督対応は別途のガバナンスを要する
✓ メリット
- •サーバーレスでAPI呼び出し量に応じて自動スケール
- •OAuth/OIDC・レート制限を API Gateway/Cognito に委譲できる
- •PrivateLink で行内システムへ安全に閉域接続
- •CloudTrail / S3 で監査証跡を標準的に確保
✗ デメリット
- •mTLS・同意管理・標準API準拠の作り込みが必要
- •外部事業者の登録・認可・監督対応などガバナンスが重い
- •結果整合性・非同期前提のアプリ設計が必要
- •APIバージョニング・後方互換の継続運用が必要
→ 主なユースケース
- •Open Banking / オープンAPIによる口座・取引情報の公開
- •フィンテック・アグリゲーターとのAPI連携基盤
- •パートナー向けのセキュアなAPIマーケットプレイス