閉域 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 で暗号化・統制・監査を担保
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
CI/CD・開発
バックアップ・DR
コピーしてすぐ使える IaC
閉域 3層 Multi-AZ エンタープライズ基盤(HULFT ファイル連携)を再現するためのスターター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 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障害への耐性と運用現実性を重視する場合に選びやすい構成です。
選定フロー
業務要件を確認する
基幹・チャネル基盤で求められる可用性、RTO/RPO、データ分類を確認する。
運用体制を確認する
チームが AWS Native の運用、監視、権限管理を継続できるかを確認する。
コストと拡張性を比較する
月 300,000 円〜(専用線・冗長化・周辺系を含む)を許容し、将来のスケールやDR要件に対応できるかを判断する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
最小構成 | 低い | 単純だが手動復旧が多い | 限定的 | PoC、検証、小規模な開始段階 |
閉域 3層 Multi-AZ エンタープライズ基盤(HULFT ファイル連携)採用 | 高い | AWS標準運用で管理可能 | 段階的に拡張可能 | 金融機関の勘定系周辺・チャネル系などの基幹業務システム |
上位冗長化構成 | 高い | 設計・監視・訓練が増える | 高い | 厳格なSLA、DR、監査要件がある場合 |
採用時のトレードオフ
設計前提の確認が必要
コストと運用負荷のバランス
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
基幹・チャネル基盤
重要度
高(基幹業務 / 閉域・監査要件が厳しい)
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など商用ミドルウェアのライセンス・運用が別途必要
→ 主なユースケース
- •金融機関の勘定系周辺・チャネル系などの基幹業務システム
- •既存オンプレ資産と連携するエンタープライズのクラウド移行
- •閉域・監査要件の厳しい公共・保険・証券系システム