そう感じるエンジニアは少なくないでしょう。EC2、S3、RDS、Lambda、ELB……サービスの数は200を超え、機能が重複して見えるものも多い。
この記事では、選定基準の1つとして「可用性（SLA）」に着目します。各AWSサービスが公表するSLAを一覧で整理し、可用性目標から逆算してサービスとアーキテクチャを選ぶ考え方を解説します。想定環境はAWS（マルチリージョン・マルチAZ構成を検討するシステム設計フェーズ）です。
この記事のポイント
・AWSサービスのSLAはサービス・構成ごとに99.5%～99.999%と大きく差がある
・S3の99.999999999%は「耐久性」でありSLA（可用性）は99.99%
・RDSはマルチAZでSLA 99.95%、シングルAZは対象外
・Route 53は唯一100% SLAを掲げ、DNS冗長化の要として機能する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AWSサービスの「可用性」とは何か
可用性（Availability）とは、システムが正常に稼働している時間の割合のことです。AWSはサービスごとに「SLA（Service Level Agreement）」という形で可用性目標を公表しており、その値を下回った場合はサービスクレジットが適用されます。よく混同されるのが「可用性」と「耐久性（Durability）」の違いです。
・可用性（Availability）：サービスにアクセスできる確率（稼働率）
・耐久性（Durability）：データが消えずに保存され続ける確率
たとえばS3の「イレブンナイン（99.999999999%）」はデータが消えない確率（耐久性）の話であり、サービスにアクセスできる確率（可用性のSLA）は99.99%です。この区別ができていないと、「S3に置けばデータへのアクセスも完璧」という誤った設計につながります。
また、SLAは「補償の基準値」であり、実測の稼働率ではありません。設計の際には参考値として使い、自システムの可用性目標はSLAより高めに設定するのが実務上の鉄則です。
主要AWSサービス可用性一覧（比較マトリクス）
以下に主要サービスのSLAをカテゴリ別に整理します。1. コンピューティング系（EC2・Lambda）
| サービス | 構成条件 | SLA | 備考 |
|---|---|---|---|
| EC2 | マルチAZ（2つ以上のAZ） | 99.99% | Auto Scalingグループ推奨 |
| EC2 | シングルインスタンス | 99.5% | SLA対象外のケースあり |
| Lambda | — | 99.95% | マネージドのためAZ設計不要 |
| ECS（Fargate） | — | 99.99% | EC2起動タイプは別計算 |
2. ストレージ系（S3・EBS・EFS）
| サービス | ストレージクラス・条件 | SLA（可用性） | 耐久性 |
|---|---|---|---|
| S3 | Standard | 99.99% | 99.999999999% |
| S3 | Standard-IA | 99.9% | 99.999999999% |
| EBS | io2 Block Express | 99.999% | — |
| EBS | gp3 / gp2 | 99.8%～99.9% | — |
| EFS | Standard（マルチAZ） | 99.99% | — |
3. データベース系（RDS・DynamoDB）
| サービス | 構成 | SLA | 備考 |
|---|---|---|---|
| RDS | マルチAZ | 99.95% | シングルAZはSLA対象外 |
| Aurora | — | 99.99% | ストレージが自動的にマルチAZ冗長化 |
| DynamoDB | Standard | 99.99% | グローバルテーブルは99.999% |
| ElastiCache（Redis） | マルチAZ | 99.99% | シングルノードはSLA対象外 |
4. ネットワーク系（ELB・Route 53・CloudFront）
| サービス | 構成 | SLA | 備考 |
|---|---|---|---|
| Application Load Balancer（ALB） | — | 99.99% | Network LB も同値 |
| Route 53 | — | 100% | 唯一の100% SLA |
| CloudFront | — | 99.9% | CDNエッジとしては十分 |
| AWS Global Accelerator | — | 99.99% | マルチリージョン最適化に利用 |
可用性目標から逆算するサービス選定の手順
実際の設計では「このサービスのSLAはいくつか」を知った後に、システム全体の可用性目標（SLO）から逆算して選定します。たとえば、年間ダウンタイムを1時間以内（可用性99.9886%以上）に抑えたいWebシステムを設計する場合、以下のような逆算が必要です。
# システム全体可用性 = 各コンポーネントのSLAの積 # 例: ALB(99.99%) × EC2マルチAZ(99.99%) × RDSマルチAZ(99.95%) # = 0.9999 × 0.9999 × 0.9995 = 約 0.9993（99.93%） # 計算式（参考） python3 -c "print(0.9999 * 0.9999 * 0.9995)" # 出力例（環境により異なります） # 0.9993001500049999
上位のSLA 99.99%を維持したい場合は、Aurora（99.99%）やDynamoDB（99.99%）への変更、またはキャッシュ層（ElastiCacheマルチAZ）を前段に置いてDBへのアクセス頻度を下げる設計が有効です。
AWSの基礎的なサービス構成やAmazon Linuxのサーバー構築入門を押さえておくと、こうした設計の選択肢を増やす土台になります。
マルチAZ構成で可用性を積み上げる設計パターン
SLA一覧を見ると、マルチAZ構成を取るかどうかで可用性が大きく変わることがわかります。一般的な3層Webシステムでのマルチ構成は次のようになります。・フロントエンド層：ALBをマルチAZで配置（AWSが自動的に複数AZに分散）
・アプリケーション層：EC2をAuto Scalingグループでマルチ配置（AZ-a・AZ-cに分散）
・データベース層：RDSマルチAZ（プライマリとスタンバイを別AZに配置）
このとき意識すべきことが1点あります。ALBはデフォルトでマルチAZになりますが、EC2のAuto ScalingグループでAZを1つしか選ばないと、実質シングルAZになります。マルチAZ冗長設計のより詳しい構成手順も参照してください。
# Auto ScalingグループのAZ設定確認（aws CLIコマンド例） aws autoscaling describe-auto-scaling-groups \ --query 'AutoScalingGroups[*].{Name:AutoScalingGroupName,AZs:AvailabilityZones}' \ --output table # 出力例（環境により異なります） # --------------------------------------------------- # | DescribeAutoScalingGroups | # +-------------------+-----------------------------+ # | AZs | Name | # +-------------------+-----------------------------+ # | ap-northeast-1a | my-web-asg | # | ap-northeast-1c | | # +-------------------+-----------------------------+
よくある設計ミスと対処法
可用性一覧を見て設計するときに陥りやすいミスを3つ挙げます。・ミス1：コスト削減でRDSをシングルAZにする：シングルAZはSLA対象外です。本番DBは必ずマルチAZにする。ステージング環境はシングルAZで問題ありません
・ミス2：S3の99.999999999%を可用性と勘違いする：この数字は「データが消えない確率（耐久性）」です。アクセス可用性は99.99%（Standard）で、Standard-IAは99.9%に下がります
・ミス3：EBSのgp3可用性を過信する：gp3のSLAは99.8%です。データベースI/Oが止まると困るシステムではio2、または読み取り負荷はEFSやS3に分散する設計を検討してください
本記事のまとめ
主要AWSサービスの可用性SLAをまとめます。| カテゴリ | サービス | SLA | マルチAZ必須 |
|---|---|---|---|
| コンピューティング | EC2（マルチAZ） | 99.99% | 必須 |
| コンピューティング | Lambda | 99.95% | 不要（マネージド） |
| ストレージ | S3 Standard | 99.99% | 不要（自動冗長化） |
| ストレージ | EBS gp3 | 99.8%～99.9% | — |
| データベース | RDS（マルチAZ） | 99.95% | 必須 |
| データベース | Aurora | 99.99% | 自動 |
| データベース | DynamoDB | 99.99% | 自動 |
| ネットワーク | ALB / NLB | 99.99% | 自動 |
| ネットワーク | Route 53 | 100% | — |
| ネットワーク | CloudFront | 99.9% | — |
＞＞ Amazon Linux サーバー構築入門コースを見る
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：AWS S3可用性を活かすバケット配置設計｜VPC構成と組み合わせた冗長化パターン
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます