ECS Fargate × Aurora PostgreSQL マルチAZ構成
コンテナ化されたモダンなWeb/AP構成
可用性 (SLA目標)
99.9% 以上(Fargate複数AZ + AuroraマルチAZ)
RTO(目標復旧時間)
数分(タスク自動再配置 + Aurora自動フェイルオーバー 通常30秒以内)
RPO(目標復旧時点)
ほぼ 0(Auroraストレージは3AZ・6コピー)
概算コスト
月 50,000〜150,000 円程度
構成概要
- 可用性レベル
- マルチAZ
- コンピューティング
- ECS/Fargate
- 想定システム規模
- 中〜大規模(スタートアップ〜エンタープライズ)
- コスト感
- ¥¥¥中コスト
使用AWSサービス
- Amazon ECS (Fargate)
- Amazon Aurora (Multi-AZ)
- ALB
- Amazon ECR
- Amazon VPC
概要
ECS Fargate でコンテナをサーバーレス実行し、Aurora PostgreSQL マルチAZでDBの高可用性を確保するモダン構成です。OSやサーバーの管理が不要で、CI/CDによるデプロイ自動化と相性が良く、現在のWeb/APサーバーの主流アーキテクチャです。Auroraはストレージを3AZ・6コピーで保持し、高い耐障害性とスケーラビリティを提供します。
★ 設計のポイント
- ▸EC2のOS運用から解放され、コンテナイメージ単位でデプロイ
- ▸Aurora はRDS(MySQL)比で最大5倍の性能・ストレージ自動拡張
- ▸Fargateタスクは数十秒で起動し、スケールアウトが俊敏
- ▸ECRのイメージ + IaC でBlue/Greenデプロイが容易
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
CI/CD・開発
バックアップ・DR
コピーしてすぐ使える IaC
ALB 配下の ECS Fargate サービスと Aurora PostgreSQL を立ち上げるサンプルです。実際にはアプリ用タスクロール、Secrets Manager、CI/CD、ログ保持期間を追加してください。
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as ec2 from "aws-cdk-lib/aws-ec2";
import * as ecs from "aws-cdk-lib/aws-ecs";
import * as ecsPatterns from "aws-cdk-lib/aws-ecs-patterns";
import * as rds from "aws-cdk-lib/aws-rds";
export class EcsAuroraStack 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 cluster = new ecs.Cluster(this, "Cluster", { vpc });
const database = 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,
storageEncrypted: true,
vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
removalPolicy: cdk.RemovalPolicy.RETAIN,
});
const service = new ecsPatterns.ApplicationLoadBalancedFargateService(this, "Service", {
cluster,
cpu: 512,
memoryLimitMiB: 1024,
desiredCount: 2,
publicLoadBalancer: true,
taskImageOptions: {
image: ecs.ContainerImage.fromRegistry("public.ecr.aws/nginx/nginx:latest"),
containerPort: 80,
},
});
database.connections.allowDefaultPortFrom(service.service);
}
}この構成を選ぶ理由
この構成は、EC2運用を減らしつつ、常時稼働型のWeb / API基盤として高可用性とデプロイ自動化を両立したいときに選びやすい構成です。
選定フロー
実行モデルを決める
リクエスト数がゼロでも常時待ち受けるアプリケーションか。
サーバー運用をどこまで減らしたいか
OSレベルの保守を極力持たず、イメージ単位でデプロイしたいか。
開発速度と標準化を重視するか
CI/CD とコンテナ標準化を進め、将来マイクロサービス化したいか。
Fargate は初期学習コストと引き換えに、継続的デリバリーの伸びしろが大きい。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
EC2 + RDS マルチAZ | 中程度 | OS / ミドルウェア運用が必要 | 中程度 | 既存EC2運用資産が強い組織 |
ECS Fargate + Aurora採用 | 中〜高 | コンテナ運用は必要だがOS保守は小さい | 高い | 継続的デリバリーとコンテナ標準化を進めたい場合 |
Lambda + DynamoDB | 低〜中 | 低い | 非常に高い | イベント駆動 / API中心 / コールドスタート許容 |
採用時のトレードオフ
学習コストは上がる
低トラフィック時でも一定コストが出る
✓ メリット
- •サーバー管理不要(OSパッチ・スケール運用が大幅減)
- •コンテナイメージ単位で自動デプロイ・ロールバックが容易
- •Aurora は高性能・ストレージ自動拡張で運用負荷が低い
- •スケールアウトが迅速(タスク起動は数十秒)
✗ デメリット
- •ECS/ECR・タスク定義・ネットワーキングなど学習コストが高い
- •常時起動タスクは費用がかさむことがある
- •Aurora はRDS(汎用)より単価が高め
→ 主なユースケース
- •マイクロサービスアーキテクチャ
- •CI/CDを活用したモダンなアジャイル開発
- •トラフィック変動が大きいWebサービス