Web 3層 / 高可用性マルチAZEC2
EC2 + RDS マルチAZ冗長構成
ALBによるEC2冗長化 + RDSマルチAZ
可用性 (SLA目標)
99.9%(複数AZ冗長 + RDSマルチAZ)
RTO(目標復旧時間)
数分(ALBヘルスチェック + RDS自動フェイルオーバー)
RPO(目標復旧時点)
ほぼ 0(同期レプリケーション)
概算コスト
月 30,000〜80,000 円程度
構成概要
- 可用性レベル
- マルチAZ
- コンピューティング
- EC2
- 想定システム規模
- 中規模(スタートアップ〜中堅企業)
- コスト感
- ¥¥¥中コスト
使用AWSサービス
- Amazon EC2
- Amazon RDS (Multi-AZ)
- ALB
- Auto Scaling
- Amazon VPC
概要
ALB(Application Load Balancer)配下に複数AZのEC2を分散配置し、RDSをマルチAZ構成にしてスタンバイを持たせる、最もスタンダードな高可用性Web/AP構成です。AZ障害時もALBのヘルスチェックとRDSの自動フェイルオーバーで継続運転でき、Auto Scalingで負荷変動にも追従します。
★ 設計のポイント
- ▸単一AZ障害ではサービス継続。AWS本番の事実上の標準形
- ▸Auto Scaling Group でトラフィックに応じてEC2を増減
- ▸RDSマルチAZの同期レプリケーションでデータ損失をほぼゼロに
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
配信・保護
バックアップ・DR
リージョンVPCプライベートパブリック概念図 / アイコン: AWS Architecture Icons
コピーしてすぐ使える IaC
最小限のALB + Auto Scaling + RDS Multi-AZを再現するサンプル雛形です。実運用ではAMI、監視、バックアップ、パラメータグループを個別に調整してください。
typescript
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as ec2 from "aws-cdk-lib/aws-ec2";
import * as autoscaling from "aws-cdk-lib/aws-autoscaling";
import * as elbv2 from "aws-cdk-lib/aws-elasticloadbalancingv2";
import * as rds from "aws-cdk-lib/aws-rds";
export class WebMultiAzStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const vpc = new ec2.Vpc(this, "Vpc", {
maxAzs: 2,
natGateways: 1,
});
const asg = new autoscaling.AutoScalingGroup(this, "WebAsg", {
vpc,
instanceType: new ec2.InstanceType("t3.small"),
machineImage: ec2.MachineImage.latestAmazonLinux2023(),
minCapacity: 2,
maxCapacity: 4,
desiredCapacity: 2,
vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
});
const alb = new elbv2.ApplicationLoadBalancer(this, "Alb", {
vpc,
internetFacing: true,
});
const listener = alb.addListener("Http", { port: 80, open: true });
listener.addTargets("WebFleet", {
port: 80,
targets: [asg],
healthCheck: { path: "/" },
});
new rds.DatabaseInstance(this, "AppDb", {
vpc,
engine: rds.DatabaseInstanceEngine.postgres({
version: rds.PostgresEngineVersion.VER_16,
}),
multiAz: true,
allocatedStorage: 100,
storageEncrypted: true,
instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MEDIUM),
vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
publiclyAccessible: false,
removalPolicy: cdk.RemovalPolicy.RETAIN,
});
}
}この構成を選ぶ理由
この構成は、単純なEC2単体運用では可用性が不足し、コンテナ化まで一気に進めるには運用体制が整っていない場面の中間解として選びやすい構成です。
選定フロー
1
可用性要件を確認する
単一AZ障害でも継続提供したいか。
はい → 複数AZ構成へいいえ → EC2 + RDS シングルAZ
2
OS / ミドルウェア運用を許容できるか
既存チームにEC2運用ノウハウがあり、パッチ適用やAMI更新を継続できるか。
はい → 本構成いいえ → ECS Fargate / Lambda を検討
EC2運用を維持できるなら、本構成が可用性と既存資産活用のバランスが良い。
3
トラフィック変動の大きさを評価する
日次・月次で急激な変動があり、短時間での細かなスケールが必要か。
大きい → ECS Fargate 優位中程度 → 本構成で十分
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
EC2 + RDS シングルAZ | 低い | 低いが手作業復旧が多い | 限定的 | PoC / 開発環境 / 低トラフィック |
EC2 + RDS マルチAZ採用 | 中程度 | EC2運用は残るが標準化しやすい | 中程度。ASGで水平拡張可能 | 既存EC2資産を活かした本番Webシステム |
ECS Fargate + Aurora | 中〜高 | OS運用は軽いがコンテナ設計が必要 | 高い。スケールの追従が速い | 継続的デリバリーとコンテナ標準化を進めたい場合 |
採用時のトレードオフ
!
運用負荷はゼロにならない
高可用化しても、EC2のパッチ適用、AMI更新、ミドルウェアの脆弱性対応は残ります。可用性改善と引き換えに、運用標準化の成熟度が必要です。
!
リージョン障害は別設計
この構成はAZ障害対策であり、リージョン全断を吸収しません。金融・基幹など厳しい継続要件では、Route 53 とDR構成を追加で設計する必要があります。
✓ メリット
- •AZ障害時も自動フェイルオーバーで継続運転
- •ALBのヘルスチェックで障害インスタンスを自動的に切り離す
- •Auto Scalingでトラフィックの増減に自動対応
- •RDSマルチAZでDBの可用性とデータ保全を両立
✗ デメリット
- •シングルAZ構成よりコストが増加(おおむね2〜3倍)
- •リージョン全体の障害には対応できない
- •EC2のOS管理・パッチ適用が引き続き必要
→ 主なユースケース
- •一般的なBtoCウェブサービス
- •高可用性要件のある社内業務システム
- •中規模のeコマースサイト
EC2RDSマルチAZALBAuto Scaling