AWS構成事例カタログ

最もシンプルなWebアプリ構成。1台のEC2にWeb/APサーバーを同居させ、RDS（シングルAZ）をDBとして使う最小構成です。コストを最優先する開発・検証環境や、ごく小規模なサービスの出発点として最適。可用性は低いため、本番の重要システムには次パターン以降の冗長化を推奨します。

ALB（Application Load Balancer）配下に複数AZのEC2を分散配置し、RDSをマルチAZ構成にしてスタンバイを持たせる、最もスタンダードな高可用性Web/AP構成です。AZ障害時もALBのヘルスチェックとRDSの自動フェイルオーバーで継続運転でき、Auto Scalingで負荷変動にも追従します。

ECS Fargate でコンテナをサーバーレス実行し、Aurora PostgreSQL マルチAZでDBの高可用性を確保するモダン構成です。OSやサーバーの管理が不要で、CI/CDによるデプロイ自動化と相性が良く、現在のWeb/APサーバーの主流アーキテクチャです。Auroraはストレージを3AZ・6コピーで保持し、高い耐障害性とスケーラビリティを提供します。

Route 53 のヘルスチェックとフェイルオーバールーティングにより、プライマリリージョン（東京）の障害時にセカンダリリージョン（大阪）へ自動切り替えするアクティブ-スタンバイ型のDR構成です。Aurora Global Database による高速なクロスリージョンレプリケーションで、RPO 1秒未満・RTO 1分以内を実現します。

CloudFront で静的コンテンツを配信し、API Gateway + Lambda でAPIを処理、DynamoDB でデータを永続化するフルサーバーレス構成です。サーバー管理が完全に不要で、リクエスト数に応じた従量課金のためアイドル時のコストはほぼゼロ。マルチAZ冗長やスケーリングはマネージドサービス側が自動で担います。

AWSの金融サービス向けリファレンスアーキテクチャをベースにした、ISO 20022 決済メッセージを処理するマルチリージョン・アクティブ-アクティブ構成です。2つのリージョンが同時に稼働し、API Gateway + Lambda のサーバーレス・マイクロサービスで決済ワークフロー（受信・処理・リリース）を実行。DynamoDB グローバルテーブルにステータスを不変の台帳（ledger）として記録し、リージョン間で複製します。UPDATE/DELETE を避けたイミュータブル設計により、リージョン間の競合を回避しつつ取引の整合性を維持します。

AWSが公開する金融機関向けベースライン環境（baseline-environment-on-aws-for-financial-services-institute）の勘定系リファレンスアーキテクチャをベースにした構成です。預金・為替・融資といった勘定系業務を、東京リージョン（Primary）と大阪リージョン（Secondary / Warm Standby）のマルチリージョンで構成。全銀・統合ATM・ANSER・CAFIS等の外接システムや営業店・銀行端末を Direct Connect / Transit Gateway 経由で接続し、Amazon ECS 上のマイクロサービス（残高照会・取引・取引カウント管理）が処理を担います。データは Aurora Global Database（リージョン間を通常1秒以内で複製）と DynamoDB グローバルテーブルで保持し、リージョン障害時は Application Recovery Controller と Step Functions により約5分以内に大阪へ自動フェイルオーバーします。

インターネットから隔離した閉域ベースのエンタープライズ環境を、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 等の周辺系マネージドサービスで、暗号化・統制・監査といった非機能/ガバナンス要件を満たします。

個人向けのインターネット / モバイルバンキングを想定したチャネル系構成です。CloudFront + WAF / Shield で配信と境界防御を行い、API Gateway 経由で Cognito / 外部IdP による認証を実施。バックエンドは Multi-AZ の ECS Fargate がビジネスロジックを処理し、Aurora（Writer/Reader）と DynamoDB（セッション）でデータを保持します。CloudTrail・KMS・GuardDuty 等で監査・暗号化・脅威検知の非機能要件を満たすことを設計目標とします。可用性・復旧目標は設計目標であり、実値は構成・運用・テスト条件に依存します。

外部事業者（TPP: アグリゲーター / フィンテック）へ口座・取引APIを安全に公開する Open Banking 基盤を想定した構成です。WAF を前段に置いた API Gateway で OAuth 2.0 / OIDC の認可とレート制限を行い、Lambda がAPIロジックを実行。同意・トークンは DynamoDB に保持し、非同期処理は SQS / EventBridge で連携します。行内の勘定系・顧客情報へは PrivateLink を介してインターネットを経由せず接続することを設計目標とし、CloudTrail / S3 で監査証跡を確保します。クライアント証明書（mTLS 相当）による事業者認証を想定します。

決済・口座・ログインなどの取引イベントをリアルタイムに監視し、不正検知・リスクスコアリングを行う構成です。取引イベントをストリーム（Kinesis 相当）で取り込み、Lambda が特徴量を生成、ML 推論エンドポイント（SageMaker 相当）でリスクスコアを算出します。スコアは DynamoDB に記録し、EventBridge のルールで閾値判定。高リスク取引は SNS でアラート通知し、後続の審査・ケース管理へ連携します。生イベントは S3 のデータレイクに保管し、Athena で事後分析・モデル改善に利用します。検知精度やレイテンシはモデル・特徴量・閾値・データ品質に依存します。

複数アカウントにまたがる監査証跡を集約し、改ざん耐性のあるデータレイクとして保全したうえで、監査・規制報告に活用する構成です。各業務アカウントの CloudTrail / Config / Security Hub の証跡を、監査専用の「ログアーカイブアカウント」へ集約。S3 Object Lock（WORM）と KMS 暗号化で改ざん耐性と機密性を確保します。分析・分析アカウントでは Glue（カタログ / ETL 相当）でデータを整え、Athena で SQL 分析、QuickSight（相当）で監査・規制報告のダッシュボードを作成します。AWS Organizations によるマルチアカウント統制で、職務分離と最小権限を実現することを設計目標とします。改ざん耐性・保持期間は Object Lock 設定・リテンション要件に依存します。

全社の生成AI利用を集約する社内AIゲートウェイ基盤です。社内利用者・業務アプリからのリクエストを ALB 経由で Multi-AZ の ECS Fargate（AIゲートウェイ）が受け、Cognito / 外部IdP で認証・権限制御を行います。推論は Amazon Bedrock の基盤モデルへ PrivateLink で閉域アクセスし、Bedrock Guardrails で入出力をフィルタリング。RAG は Bedrock Knowledge Bases を用い、ベクトル検索（OpenSearch Serverless 相当）と S3 上の社内ドキュメントを参照します。プロンプト / レスポンスはログ化し、CloudTrail / S3 で監査証跡を確保。モデル別・チーム別の使用量とコストの可視化を設計目標とします。可用性や精度は構成・モデル・データ整備・テストに依存します。

Snowflake をマネージドSaaSのデータウェアハウスとして利用する全社データ活用基盤です。AWS 側の S3 ランディングバケットへ集めた業務データを、Storage Integration / Snowpipe 相当で Snowflake の Database Storage へロード。BIツールや分析ユーザーは AWS PrivateLink を介して Snowflake へ閉域接続し、IdP / SSO と RBAC でアクセス制御します。Snowflake は『Cloud Services（認証・最適化・メタデータ）』『Virtual Warehouse（弾力的コンピュート）』『Database Storage（圧縮列指向）』の3層で構成され、用途別に仮想ウェアハウスを分離してコストを可視化・分離します。図では AWS Cloud と Snowflake Managed Platform の境界を明示しています。可用性・性能・データ保護は Snowflake のエディション・契約・設定に依存します。

Databricks を用いた Lakehouse 基盤を、制御プレーン（Databricks 管理アカウント）と Customer AWS Account（顧客管理VPC内の Classic Compute Plane）に分離して構成します。ノートブック / SQL / ジョブは制御プレーンから提供され、実際のクラスター（Spark）は顧客VPC内で起動。データは Amazon S3 を中心とした Delta Lake（Bronze / Silver / Gold）に蓄積し、Unity Catalog がデータ・モデルの権限と系譜を一元統制します。制御プレーン接続は AWS PrivateLink で閉域化し、S3 へはクロスアカウント IAM Role と VPC Endpoint で最小権限アクセス。データエンジニアリング・BI・ML（MLflow）を一つの基盤に統合します。図では Databricks 管理アカウント / Customer AWS Account / Data Lake の境界を明示しています。可用性・性能・コストは構成・契約・設定に依存します。

ECS Fargate でコンテナをサーバーレス実行し、サービス間通信を Amazon VPC Lattice（mTLS・L7認可）で束ねたクラウドネイティブな金融AP基盤です。Kubernetes を持たず AWS マネージドサービスでサービスメッシュ相当を実現するため、運用負荷を抑えつつ多層防御を構築できます。接続はハイブリッドで、顧客チャネルはインターネット公開（WAF + Shield + ALB）、勘定系・外接や社内網は Direct Connect + Transit Gateway の閉域で受けます。境界は AWS Network Firewall（IPS/IDS・ドメインallowlist）、外向き通信は Network Firewall Proxy（FQDN allowlist + TLSインスペクション）で統制。セキュリティは CI/CD の SAST（Inspector Code Security）・SCA（BlackDuck）・IaCスキャン・コンテナイメージスキャン（Trivy + ECR Enhanced Scanning）から、デプロイ時の Cosign 署名検証、ランタイムの GuardDuty Runtime Monitoring まで多段で組み込みます。

Amazon EKS 上に Istio サービスメッシュ（mTLS STRICT・認可・Kiali可視化）を敷き、CNCF スタックで可観測性とポリシー強制を構成したクラウドネイティブ金融AP基盤です。デプロイは ArgoCD による pull 型 GitOps で Git を唯一の真実源とし、構成ドリフトを継続的に検出・是正します。接続はハイブリッドで、顧客チャネルはインターネット公開（WAF + Shield + ALB/Ingress）、勘定系・外接や社内網は Direct Connect + Transit Gateway の閉域で受けます。境界は AWS Network Firewall、外向き通信は Network Firewall Proxy（FQDN allowlist + TLS検査）で統制。セキュリティは CI の SAST（Inspector Code Security）・SCA（BlackDuck）・IaCスキャン・コンテナイメージスキャン（Trivy + ECR Enhanced Scanning）から、アドミッション時の OPA/Gatekeeper・Cosign 署名検証、ランタイムの Falco + GuardDuty EKS Runtime Monitoring まで多段で組み込みます。

カード提示・非対面決済など複数チャネルからのオーソリゼーション要求を API Gateway で受け、Amazon MSK を中心に疎結合化したリアルタイム決済処理プラットフォームです。ECS/Fargate の処理コンテナが BIN チェック、リスクチェック、トークナイゼーション、業務ルール判定を実行し、AWS Payment Cryptography や KMS、DynamoDB、ElastiCache を組み合わせて PCI DSS を意識した低遅延・高スループットな処理を構成します。

カード発行会社の Authorization と Reconciliation を AWS に段階移行し、Settlement は既存オンプレミスに残すハイブリッドなカードイシュア構成です。オンプレミスのカードネットワーク接続から Direct Connect と Transit Gateway で AWS へ取り込み、ECS と MSK で承認処理を疎結合化します。DynamoDB Global Tables、Aurora Global Database、ARC Routing Control により、リージョン障害時も処理継続を狙います。

保険業務の契約者情報、健康情報、財務データなどをマルチアカウントで分離しながら統合する AWS ネイティブなレイクハウス基盤です。S3 データレイク、Glue、Aurora メタデータリポジトリ、Redshift Data Sharing、Athena、QuickSight を組み合わせ、メタデータ駆動型のデータパイプラインと分析処理の分離を実現します。

投資家・トレーダーからの注文受付と約定管理を担う OMS を、受注・約定系と発注・出来系に分離したクラウドネイティブ構成です。処理層間は Amazon ElastiCache for Redis Streams などの低レイテンシーメッセージングで連携し、取引所や EMS に近い発注・出来処理を独立スケールさせます。レイテンシーを最優先する場合はクロスAZ通信を抑える Active/Standby、可用性と柔軟性を重視する場合は Active/Active を選択します。