AWSでSLOを"運用に効かせる" — SLI選定・エラーバジェット・バーンレートアラートの設計

監視ダッシュボードはある。アラートも鳴る。それでも「このサービスはどれだけ失敗してよいのか」を数で持ち、リリース判断に効かせている現場は多くありません。本記事は、AWSの CloudWatch Application Signals（サービスの稼働状況を自動で計測し、SLOをネイティブに扱えるマネージド機能）を使って、SLI（信頼性を測る指標）を選び、SLO（その目標値）を決め、エラーバジェットとバーンレートアラートをリリース判断まで効かせる設計を扱います。「SLOとは何か」の解説ではなく、設計値の決め方に絞ります。AWS上のサービスに信頼性の責任を持つ読者を想定し、前提知識は省きます。

監視だけでは足りない理由と、本記事の地図

監視は「何が起きたか」を見せますが、「どこまでの失敗を許容するか」「いつリリースを止めるか」までは決めてくれません。結果としてアラートは増え続け（アラート疲れ）、リリースの可否は担当者の勘に委ねられます。これを解くのが、監視を SLO に、さらに意思決定へと昇格させる設計です。Application Signals は SLO をネイティブ機能として持つため、自前で計算基盤を組まずにこの昇格を実装できます。

なお、SLIの計測そのもの（OpenTelemetryでのメトリクス取り込みなど）はCloudWatchのOpenTelemetryメトリクス対応で扱っています。本記事は、計測した値を SLI/SLO にどう束ね、リリース判断に効かせるかに集中します。

SLI選定 — 自動で持つ指標とユーザー体験指標

Application Signals は、発見した各サービス・オペレーションに Latency（応答にかかる時間）と Availability（正常応答の割合）を自動収集し、これらをそのまま SLI に使えます。加えて、任意の CloudWatch メトリクスやメトリクス式も SLI に指定できます。

SLI候補	取りやすさ	ユーザー体験への近さ
自動収集の Latency/Availability	高い（無設定で取れる）	中（汎用指標）
任意のCloudWatchメトリクス	中	中〜高
メトリクス式（複数を合成した独自SLI）	低い（設計が要る）	高い

トレードオフは、計測しやすい自動値で素早く始め、重要なオペレーションを独自SLIへ段階的に昇格させることです。最初から完璧な独自指標を目指して着手が遅れるより、自動値で運用を回しながら精度を上げます。

SLOを決める — 型・インターバル・期間

SLOには2つの型があります。request-based（不良リクエスト数÷総リクエスト数）と、period-based（不良な期間数÷総期間数）です。これに達成目標（attainment goal、SLIが閾値を満たすべき割合）と、数時間から1年までのインターバルを組み合わせます。設計上の分かれ目になるのがインターバルの種類です。

インターバル	集計の仕方	向く用途
Rolling（ローリング）	直近の一定期間を常に集計	直近のユーザー体験を追う
Calendar（カレンダー）	暦に揃える（月次など・日数を自動調整）	事業報告・SLA契約の基準

例として「達成目標99%・1日のcalendarインターバル・1分のperiod」は、「1日を構成する1分periodの99%で閾値を満たす」という意味になります。複数オペレーション（2〜20）の Availability を束ねる Composite SLO も使えます。SLOはコード化でき、CloudFormation の AWS::ApplicationSignals::ServiceLevelObjective または API の CreateServiceLevelObjective で定義します。クォータはリージョンあたり250、サービスあたり100で、いずれも調整可能です。判断軸は明快で、直近のユーザー体験を重視するなら rolling、契約や事業報告に合わせるなら calendar を選びます。

エラーバジェット — 許容失敗量を「数」で持つ

エラーバジェットは、インターバル内で閾値を破ってもSLOを満たせる余地です。全体量（total）と、消費後の残量（remaining）で持ちます。公式の計算例で具体化します。30日・1分period・達成目標99%の場合、期間内の1分periodは43,200個あり、その99%にあたる42,768分が健全である必要があります。差し引き、エラーバジェットは432分です。request-based の場合は、リクエストの良し悪しの比に応じて残量が動的に増減します。

許容失敗量を分という数で持てると、リリースを止めるかどうかを勘ではなくデータで判断する土台ができます。

バーンレート — 誤報なく効かせる

バーンレートは、エラーバジェットをどれだけ速く消費しているかを表す倍数です。基準は baseline error rate（＝100%から達成目標を引いた値。達成目標99%なら1%）で、バーンレートが1ちょうどなら予算をぴたり使い切るペース、1未満なら超過達成の見込み、1を超えると予算を使い果たす恐れを意味します。式は次のとおりです。

burn rate = look-back窓のerror rate ÷ （100% − attainment goal）

look-back窓は、SLO periodの倍数かつSLOインターバル未満に取ります。アラートの閾値の決め方には2方式があり、ここが運用言語への翻訳の核です。

方式	閾値の式	鳴る条件	感度と誤報
方式1（予算消費割合で鳴らす）	X% × インターバル長 ÷ look-back窓	窓内で予算をX%消費したら	Xを小さくするほど高感度・誤報増
方式2（枯渇までの時間で鳴らす）	インターバル長 ÷ X	あとX時間で枯渇するペースなら	Xを短くするほど高感度・誤報増

方式1の具体例として、30日（720時間）の予算の5%を1時間で消費する設定は、5% × 720 ÷ 1 = 36 が閾値になります。さらに、急なスパイクと緩やかな悪化の両方を捉えるのがマルチウィンドウ・マルチバーンレートです。インターバルが3時間以上あれば、異なるlook-back窓のアラート対を composite alarm（複合アラーム）で組みます。短い場合は、一方の窓を他方の12分の1にした1対から始めます。誤報を抑える warning レベルも併せて設定します。

トレードオフは一貫しています。感度を上げれば誤報が増え、下げれば見逃しが増えます。それを「予算を何%消費したら」「あと何時間で枯渇するなら」という運用の言葉に式で翻訳できることが、バーンレート設計の要点です。

リリース判断に効かせる

最後に、ここまでの数値を意思決定へ接続します。エラーバジェットの残量はデプロイの凍結・解凍に使います。残量が一定ラインを割ったら新規リリースを止め、回復したら解凍します。バーンレートアラートはオンコールの起動や機能フラグの巻き戻しに紐づけます。接続は2段で考えると扱いやすくなります。warningレベルのアラートはオンコールへの通知にとどめ、criticalレベルはデプロイパイプラインの自動停止やロールバックに結びつける、という段差を付けると、過剰反応と見逃しの両方を避けられます。

判断軸が数で定まっていれば、「今は出してよいのか」を勘でなく説明できます。受託案件で信頼性に責任を負う場面でも、止めた・出した理由を残せることが効いてきます。

実務での注意点

東京リージョン（ap-northeast-1）に対応しています。料金は Application Signals の signal 従量で、最初の1億は100万signalあたり$1.50、次の9億は$0.75、超過分は$0.30です。SLO個別の月額固定費はなく、SLOはSLIメトリクスの周期でsignalを生成して同じ段階課金に乗ります。これらの段階値は公表段階（us-east-1基準）であり、2026年6月時点の参考値です。東京リージョンの実値と最新の料金は公式の料金表でご確認ください。マルチバーンレートの「3時間以上で複合」「12分の1」といった具体値も、運用前に公式ドキュメントの現行記述を確認します。

まとめ：SLO運用チェックリスト

監視からリリース判断までを、5段で1枚に集約します。

段階	決めること	主な選択基準
① SLI選定	自動値か独自メトリクス式か	取りやすさとUXの近さ
② SLO型・インターバル	request/period・rolling/calendar	直近UXか事業・SLA基準か
③ エラーバジェット	total と remaining を数で	許容失敗量の合意
④ バーンレート閾値	方式1/方式2・マルチウィンドウ	感度と誤報のバランス
⑤ リリース接続	残量→凍結、アラート→対応	データでの判断と説明責任

ダッシュボードを眺めるだけのSREから卒業する鍵は、この5段を設計値で決め切ることにあります。料金・クォータ・仕様は改定されうるため、本番適用の前に公式の最新情報をあわせてご確認ください。