AWS
AWS構成事例カタログ
金融 / API連携サーバーレスLambda

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アクセスの監査証跡

システム構成図

AWS Cloud(API公開アカウント)認可非同期mTLS相当 / 閉域監査ログ外部事業者 (TPP)アグリゲーターフィンテックWAF(レート制限/防御)API Gateway(OAuth2.0/OIDC)Cognito認可サーバDynamoDB同意/トークンLambda(APIロジック)SQS(非同期処理)S3APIアクセスログAWS PrivateLink内部API接続EventBridge(イベント連携)行内システム勘定系 API顧客情報

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

監視・運用

CloudWatchCloudWatchCloudTrailCloudTrailEventBridgeEventBridge

セキュリティ・統制

IAMIAMGuardDutyGuardDutyKMSKMSSecrets ManagerSecrets Manager

配信・保護

WAFWAFShieldShield

バックアップ・監査

AWS BackupAWS BackupS3S3
リージョンVPCプライベートパブリック概念図 / アイコン: AWS Architecture Icons

コピーしてすぐ使える IaC

Open Banking / 外部API公開基盤(API連携)を再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。

typescript
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公開・パートナー連携基盤)を想定し、運用負荷の低減とイベント駆動の伸縮性を重視する場合に選びやすい構成です。

選定フロー

1

業務要件を確認する

API連携で求められる可用性、RTO/RPO、データ分類を確認する。

要件に合う → 候補として採用不足がある → 上位の冗長化/統制構成を検討
2

運用体制を確認する

チームが AWS Native の運用、監視、権限管理を継続できるかを確認する。

運用可能 → 詳細設計へ負荷が高い → よりマネージドな代替案へ
3

コストと拡張性を比較する

月 30,000〜200,000 円程度(API呼び出し量に依存)を許容し、将来のスケールやDR要件に対応できるかを判断する。

許容できる → 本構成を採用過剰/不足 → 代替案を比較

代替案との比較

候補コスト運用保守負荷スケーラビリティ選定すべきケース
最小構成
低い単純だが手動復旧が多い限定的PoC、検証、小規模な開始段階
Open Banking / 外部API公開基盤(API連携)採用
中程度AWS標準運用で管理可能需要に応じて高く伸縮Open Banking / オープンAPIによる口座・取引情報の公開
上位冗長化構成
高い設計・監視・訓練が増える高い厳格なSLA、DR、監査要件がある場合

採用時のトレードオフ

!

設計前提の確認が必要

記載のSLA/RTO/RPOは設計目標であり、実値は構成・運用・テスト条件に依存する
i

コストと運用負荷のバランス

mTLS・同意管理・標準API準拠の作り込みが必要

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

API Gateway のスロットリング・WAF による濫用・不正リクエスト対策
クライアント証明書(mTLS 相当)で外部事業者を認証する想定
Cognito による OAuth 2.0 / OIDC の認可・トークン発行
KMS による暗号化、Secrets Manager による資格情報の保護
CloudTrail による全API操作の証跡化と監査対応

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

業務領域

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マーケットプレイス
金融API連携Open BankingOAuthOIDCAPI GatewayPrivateLinkサーバーレス