AWS
AWS構成事例カタログ
金融 / エンタープライズマルチAZEC2

閉域 3層 Multi-AZ エンタープライズ基盤(HULFT ファイル連携)

Web/AP/DB のサブネット分離とDirect Connect閉域接続による金融グレード構成

可用性 (SLA目標)

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

RTO(目標復旧時間)

数分(ALBヘルスチェック + Aurora 自動フェイルオーバー)

RPO(目標復旧時点)

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

概算コスト

月 300,000 円〜(専用線・冗長化・周辺系を含む)

構成概要

可用性レベル
マルチAZ
コンピューティング
EC2
想定システム規模
大規模(金融・公共・エンタープライズの基幹業務)
コスト感
¥¥¥高コスト

使用AWSサービス

  • Application Load Balancer
  • Amazon EC2
  • Amazon ECS / EKS
  • Amazon Aurora (Multi-AZ)
  • AWS Direct Connect
  • AWS Transit Gateway
  • NAT Gateway
  • HULFT on AWS
  • Amazon S3
  • AWS KMS
  • AWS IAM
  • AWS Secrets Manager
  • Amazon GuardDuty
  • Amazon CloudWatch
  • AWS CloudTrail

概要

インターネットから隔離した閉域ベースのエンタープライズ環境を、Web/AP/DB の3層をサブネットで厳格に分離して構築する金融グレードの高可用性構成です。社内オンプレミスや全銀ネット・共同センター等の外部金融ネットワークとは Direct Connect と Transit Gateway による閉域接続で連携。各AZ(AZ-A / AZ-C)にALB・Web・AP・Auroraを冗長配置し、HULFT on AWS でオンプレ/外部システムとのファイル授受を行います。KMS・Secrets Manager・GuardDuty・CloudTrail 等の周辺系マネージドサービスで、暗号化・統制・監査といった非機能/ガバナンス要件を満たします。

設計のポイント

  • Web/AP/DB を Public / Private / Isolated サブネットで厳格分離(多層防御)
  • Multi-AZ(AZ-A / AZ-C)でALB・EC2・Auroraを冗長化
  • Direct Connect + Transit Gateway によるインターネット非経由の閉域接続
  • HULFT on AWS(暗号化EBS)でオンプレ・外部金融ネットとファイル連携
  • KMS / Secrets Manager / GuardDuty / CloudTrail で暗号化・統制・監査を担保

システム構成図

AWS CloudVPC(閉域 / インターネット非公開)アベイラビリティゾーン Aアベイラビリティゾーン C周辺系・共通基盤サービス(非機能 / ガバナンス)Application サブネット (Private 2)Application サブネット (Private 2)パブリックサブネットWeb/DMZ サブネット (Private 1)Data サブネット (Isolated)パブリックサブネットWeb/DMZ サブネット (Private 1)Data サブネット (Isolated)閉域/専用線ファイル連携専用線/閉域網ルーティング統合Multi-AZ 同期レプリケーション退避/BK社内オンプレミス拠点基幹 / 業務システム保守・運用端末HULFTオンプレミスサーバ外部金融ネットワーク全銀ネット共同センターDirect Connect(閉域接続)TransitGatewayS3退避/BKKMSIAMSecretsManagerGuardDutyCloudWatchCloudTrailALBNAT GWWeb EC2(リバースプロキシ)AP EC2/ECS(業務処理)HULFT on AWS(EBS暗号化)Aurora PrimaryALBNAT GWWeb EC2(リバースプロキシ)AP EC2/ECS(業務処理)HULFT on AWS(EBS暗号化)Aurora Replica

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

監視・運用

CloudWatchCloudWatchCloudTrailCloudTrailSystems ManagerSystems ManagerAWS ConfigAWS Config

セキュリティ・統制

IAMIAMGuardDutyGuardDutySecurity HubSecurity HubKMSKMSSecrets ManagerSecrets Manager

CI/CD・開発

CodePipelineCodePipelineCodeBuildCodeBuildECRECR

バックアップ・DR

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

コピーしてすぐ使える IaC

閉域 3層 Multi-AZ エンタープライズ基盤(HULFT ファイル連携)を再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。

typescript
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as ec2 from "aws-cdk-lib/aws-ec2";
import * as elbv2 from "aws-cdk-lib/aws-elasticloadbalancingv2";
import * as rds from "aws-cdk-lib/aws-rds";
import * as kms from "aws-cdk-lib/aws-kms";

// インターネット非公開の閉域 VPC(IGW なし)。Web/AP/DB を分離し、内部 ALB で受ける。
export class ClosedThreeTierStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 公開サブネットを作らず、Isolated + Egress(NATは保守用) のみ
    const vpc = new ec2.Vpc(this, "Vpc", {
      maxAzs: 2,
      natGateways: 1,
      subnetConfiguration: [
        { name: "web", subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS, cidrMask: 24 },
        { name: "app", subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS, cidrMask: 24 },
        { name: "data", subnetType: ec2.SubnetType.PRIVATE_ISOLATED, cidrMask: 24 },
      ],
    });

    // 内部 ALB(インターネット非公開)。Direct Connect / Transit Gateway 経由のみ到達。
    const alb = new elbv2.ApplicationLoadBalancer(this, "InternalAlb", { vpc, internetFacing: false });
    alb.addListener("Http", { port: 80 });

    new ec2.CfnTransitGatewayVpcAttachment(this, "TgwAttach", {
      transitGatewayId: cdk.Fn.importValue("SharedTransitGatewayId"),
      vpcId: vpc.vpcId,
      subnetIds: vpc.selectSubnets({ subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS }).subnetIds,
    });

    const key = new kms.Key(this, "DataKey", { enableKeyRotation: true });

    // Aurora Multi-AZ(保存時暗号化)。HULFT は専用 EC2 上で稼働させる想定。
    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,
      vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
      storageEncryptionKey: key,
      storageEncrypted: true,
    });
  }
}

この構成を選ぶ理由

閉域 3層 Multi-AZ エンタープライズ基盤(HULFT ファイル連携)は、大規模(金融・公共・エンタープライズの基幹業務)を想定し、AZ障害への耐性と運用現実性を重視する場合に選びやすい構成です。

選定フロー

1

業務要件を確認する

基幹・チャネル基盤で求められる可用性、RTO/RPO、データ分類を確認する。

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

運用体制を確認する

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

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

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

月 300,000 円〜(専用線・冗長化・周辺系を含む)を許容し、将来のスケールやDR要件に対応できるかを判断する。

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

代替案との比較

候補コスト運用保守負荷スケーラビリティ選定すべきケース
最小構成
低い単純だが手動復旧が多い限定的PoC、検証、小規模な開始段階
閉域 3層 Multi-AZ エンタープライズ基盤(HULFT ファイル連携)採用
高いAWS標準運用で管理可能段階的に拡張可能金融機関の勘定系周辺・チャネル系などの基幹業務システム
上位冗長化構成
高い設計・監視・訓練が増える高い厳格なSLA、DR、監査要件がある場合

採用時のトレードオフ

!

設計前提の確認が必要

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

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

Direct Connect・冗長化・周辺系を含めコストと構築工数が大きい

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

VPCはインターネット非公開。NAT Gatewayは保守・パッチ用の最小限アウトバウンドのみ
AWS KMS による保存時暗号化(EBS / Aurora / S3)と鍵の一元管理
AWS Secrets Manager によるDB認証情報の自動ローテーション
AWS IAM の最小権限原則でアクセス制御
AWS GuardDuty による脅威検知、AWS CloudTrail による証跡・監査ログ集約
HULFTのファイル転送は暗号化、退避データはS3へ(KMS暗号化)

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

業務領域

基幹・チャネル基盤

重要度

高(基幹業務 / 閉域・監査要件が厳しい)

DR方式

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

接続方式

Direct Connect + Transit Gateway 閉域接続(インターネット非公開)

データ分類

機密(基幹業務・個人情報 / 外部金融ネット連携データ)

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

  • VPCをインターネット非公開とし、アウトバウンドは保守用の最小限に限定する
  • KMSによる保存時暗号化(EBS / Aurora / S3)と鍵の一元管理を設計目標とする
  • Secrets Manager によるDB認証情報の自動ローテーションで秘密情報を保護する
  • IAM 最小権限・Web/AP/DBサブネット分離による多層防御と職務分離
  • GuardDuty / CloudTrail による脅威検知と監査証跡の集約

前提条件・留意事項

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

メリット

  • Web/AP/DB のサブネット分離と閉域接続で高いセキュリティを確保
  • Multi-AZ 冗長によりAZ障害時も継続運転
  • HULFT による既存オンプレ・外部金融ネットとの確実なファイル連携
  • KMS / Secrets Manager / GuardDuty / CloudTrail で非機能・統制要件を満たす
  • 既存のEC2ベース資産を活かしつつクラウド移行できる

デメリット

  • Direct Connect・冗長化・周辺系を含めコストと構築工数が大きい
  • EC2のOS運用・パッチ適用が必要(AP層をECS/EKS化で軽減可能)
  • 閉域・サブネット分離に伴うネットワーク設計/運用が複雑
  • HULFTなど商用ミドルウェアのライセンス・運用が別途必要

主なユースケース

  • 金融機関の勘定系周辺・チャネル系などの基幹業務システム
  • 既存オンプレ資産と連携するエンタープライズのクラウド移行
  • 閉域・監査要件の厳しい公共・保険・証券系システム
3層Multi-AZ閉域Direct ConnectTransit GatewayHULFTAurora金融セキュリティ