シングル AZ 構成の本番環境 EC2 を夜間土日に停止する運用のリスクについて考える

自治体では昨今ガバメントクラウドのコスト削減が課題になっています。

コスト削減のため、本番環境であっても「シングル AZ 構成にしたい」「夜間や土日は EC2 インスタンスを停止したい」といった相談を見かけることがあります。

シングル AZ 構成や夜間土日の停止運用は、本番環境の可用性要件との整合を慎重に確認する必要があります。この記事では、AWS 環境でこれらを組み合わせた時に、現実的にどのようなリスクが起き得るのかを考えてみました。

前提となるシステム構成

ガバメントクラウドに構築された仮想の自治体の基幹業務システムとして、以下のような構成を前提とします。

項目	内容
システム	EC2 にアプリケーションとデータベースが同居する基幹業務システムの本番環境とする。
ネットワーク	閉域ネットワークで、1 つの AZ のみ使用。インターフェース型 VPC エンドポイントも 1 つの AZ のみに配置。
インスタンスタイプ	共有テナンシーで m6i.xlarge の Windows Server。
オンライン処理	平日 08:45〜20:00。
夜間バッチ処理	22:00 まで。ただし月次処理や年次処理で終了時間が延びる可能性あり。
インスタンス稼働時間	起動失敗に備えてオンライン処理開始の 2 時間前から起動し、夜間バッチ処理終了後に停止。土日は終日停止。平日 06:45〜22:00。
リージョン	東京リージョン

また、日中の時間帯の基幹業務システムの運用について、停止が許されないシステム（以下「停止不可システム」）と、年に数回程度の数時間レベルの停止は許容するシステム（以下「停止許容システム」）の 2 パターンに分けてそれぞれのリスクを検討することにします。

以上のシステム構成を図にしたものです。

それではこれらのシングル AZ 構成の EC2 を夜間土日に停止運用する時のリスクを検討してみます。

停止運用で起こり得るリスク

1 年間を 52 週とすると平日は 260 日となり、1 台の EC2 インスタンスごとに年間 260 回の起動と停止を繰り返すことになります。

そのため、無停止の運用よりも起動停止に伴うトラブルの発生確率は高くなってしまいます。

始業時に EC2 インスタンスが起動できない

AWS はクラウドサービスですが、当然物理的なリソースの上で稼働しています。停止中の EC2 インスタンスを起動するには、その時点で EC2 インスタンスと同じ AZ の物理リソースに空き容量（キャパシティ）が必要です。

空き容量が不足する状態で EC2 インスタンスを起動しようとすると、 InsufficientInstanceCapacity エラーが発生し、起動に失敗します。

また、EBS ボリュームは同じ AZ の EC2 インスタンスにしか接続できないため、容量不足だからといって別の AZ で起動できません。別のインスタンスタイプに切り替えて再試行する場合も、同じ AZ の中での再試行になります。

容量不足がいつ回復するかは予測できず、数分で回復することもあれば長引くこともあります。また、容量不足がどの程度発生するかについては公表されていないため、予測することはできないのが現状です。

なお、AZ に障害が起きると、その AZ での EC2 インスタンスの起動に影響が出ることがあります。

実際、東京リージョンでは以下のような 1 時間から数時間に及ぶ AZ 障害が発生しています。

2019 年 8 月 23 日の空調設備の障害

日本時間	発生した事象
12:36	オーバーヒートにより一定の割合の EC2 サーバーの停止が発生
13:21	新しい EC2 インスタンスの作成（RunInstances）のエラー率が上昇
16:05	インスタンスの作成のエラー率上昇が解消
18:30	影響を受けた EC2 インスタンスと EBS ボリュームの大部分は回復

2025 年 4 月 15 日の電源の障害

日本時間	発生した事象
16:40	一部の EC2 インスタンスへの接続に問題が発生（影響を受けたゾーンで起動されたインスタンス、および影響を受けた EC2 インスタンスを使用する他の AWS API において、エラー率とレイテンシーの増加が見られた可能性）
17:43	接続の問題が解消（ただし、停電の影響を受けたハードウェア上に残った一部の EC2 インスタンスやボリュームの復旧は、その後も継続）

2026 年 11 月 11 日 運用上の問題

ちょうどこの記事を公開したタイミングで東京リージョンの一部 AZ に障害が起きたので追記します。

日本時間	発生した事象
23:46	主に単一のアベイラビリティーゾーン (apne1-az1) において、API エラー率の上昇および起動失敗が発生
26:46	API の広範な回復が見られ、新規 EC2 インスタンスの起動が成功するようになるも、影響を受けた単一のアベイラビリティーゾーンにおける新規起動インスタンスで接続の問題が発生していることを確認
28:51	回復の最初の兆候を確認
29:31	完全に回復

Operational issue - Amazon Elastic Compute Cloud (Tokyo)

夜間の停止処理が失敗する

何らかの原因で EC2 インスタンスが停止処理中のステータスのまま停止が完了しないことがあります。もし EC2 インスタンスを強制停止する場合、起動後に正常性確認が必要になる場合があり、これがオンライン処理の開始時間に間に合わないリスクがあります。

起動時刻を早めればリスクを回避できるか？

今回、オンライン処理の開始時間までに EC2 インスタンスの起動に失敗する可能性を考慮し、朝の EC2 インスタンスの起動時間をオンライン処理の開始時間の 2 時間前と設定しました。

前述のとおり、容量不足で EC2 インスタンスの起動に失敗する確率や回復までの時間も、AZ に障害が発生する確率も推測するしかないため、以下のように仮定してみました。

起動失敗の原因	どの程度遅延するか	起動時間の前倒しでカバーできるか
AZ の容量不足（InsufficientInstanceCapacity）	数分で回復することもあれば長引くこともあり	長引く場合は間に合わない
AZ 障害	数時間以上続くことがある	間に合わない可能性あり
夜間停止の失敗	強制停止で対応した場合、アプリケーション等の整合性確認に時間を要する可能性がある	長引く場合は間に合わない

いずれの原因についても、場合によっては長期化する可能性があり、確実にオンライン処理に間に合わせなければならないシステム（停止不可システム）の場合は、停止によって追加される起動失敗のリスクを避けるため、夜間土日に停止する運用を避けるべきです。

一方、発生頻度や継続時間は分からないものの、許容範囲を超えた場合の代替業務と復旧策を用意し、残るリスクを受容できるのであれば、停止許容システムだけを夜間土日に停止して運用する選択肢はあります。

シングル AZ の場合に停止しなくても起き得るリスク

ここまで、EC2 インスタンスの停止運用のリスクを検討してきましたが、シングル AZ 構成の場合、停止しない運用であっても次のようなリスクが考えられます。

AZ 障害

EC2 インスタンスのある AZ 全体が障害となった場合、想定のシステム構成では 別の AZ へ EC2 インスタンスを逃すことはできないため、AZ 障害が復旧するまでシステムが利用できません。

また、ホストのハードウェア障害では EC2 インスタンスのオートリカバリーが働きますが、同じ AZ に空き容量がなければ復旧に失敗する可能性があります。

EC2 の SLA から見た停止時間の目安

EC2 の SLA は、2 つ以上の AZ に冗長化している場合はリージョンレベルの SLA として月間稼働率 99.99% としています。しかし、シングル AZ 構成では、インスタンスごとの SLA である月間稼働率 99.5% となります。

99.5% の稼働率だと、1 か月あたり約 3.6 時間、年間で約 44 時間の停止に相当します。思っているより停止時間の目安は大きいです。

なお、SLA はあくまでサービスクレジットを受けられる基準で、実際の停止時間の予測でも保証でもないことに注意です。

シングル AZ 構成では停止を許容しない運用が難しい

以上のことから、シングル AZ 構成の場合、EC2 のシステムで日中の時間帯に停止を許容しない、という運用は難しく、停止が許容できない要件であればコストはかかりますがマルチ AZ 構成を採用する方がリスクは小さいと言えます。

停止運用と Savings Plans の割引とどちらがコストメリットがあるのか

東京リージョンの共有テナンシーの EC2 で m6i.xlarge の Windows Server の場合に、1 台当たりの利用料を、オンデマンド料金で停止運用する場合と Savings Plans（以下「SP」）を適用して 24 時間起動する場合で比較してみました。なお、SP はガバメントクラウドの制約により前払い不可のため、前払いなしとしています。

停止運用の稼働時間は、平日 06:45〜22:00 の 260 日分 = 3,965 時間に、月次処理や年次処理で年間 50 時間の延長があるとして、年間計 4,015 時間と仮定しました。

運用方法	年額（USD）	キャパシティの確保
24 時間起動・オンデマンド	3,784	追加料金なしで ODCR を設定できる
夜間土日に停止運用・オンデマンド	1,734	ODCR は設定しない（24 時間起動と同じ金額になってしまうため）
24 時間起動・EC2 Instance SP（3 年・前払いなし）	2,596	追加料金なしで ODCR を設定できる
24 時間起動・Compute SP（3 年・前払いなし）	2,740	同上

ODCR とはオンデマンドキャパシティ予約のことで、指定した AZ・インスタンスタイプ・プラットフォームなどの条件に合うキャパシティを前もって確保しておくことができます。ODCR には料金がかかりますが、条件が一致する EC2 インスタンスが予約容量を使用している間は、その予約分の追加料金はかかりません。そのため上記の表では、24 時間起動するインスタンスが予約容量を使い続ける前提で、追加料金なしで ODCR を設定できる、としています。

停止運用の場合、SP を適用して 24 時間 EC2 インスタンスを起動する運用よりも年額で約 860〜1,000 USD 安くなります。

しかし、停止運用の場合は、朝の起動処理と夜間の停止処理に失敗した場合に対応する人員を用意する必要があり、別途コストが必要になることに注意が必要です。

コストと EC2 インスタンスのキャパシティを踏まえた対応案

以上のことから、シングル AZ 構成の場合に EC2 インスタンスのコストとキャパシティの確保を考えた時に、望ましいパターンを考えてみます。

システム区分	選択肢	年額（1 台当たり・USD）	条件
停止不可システム	24 時間起動 + ODCR + 3 年前払いなし SP	2,596（EC2 Instance SP）/ 2,740（Compute SP）	シングル AZ に起因するリスクを許容できる
停止許容システム	停止運用	1,734（ただし対応人員の費用など別途要する）	オンライン処理開始時間までに起動できないリスクを許容できる

停止許容システムであれば、前述のとおり停止運用は SP を使った 24 時間起動より安くなりますが、個人的には、この程度の差額で起動失敗時の対応体制まで用意するのは難しいと思うのと、朝に起動できないリスクも残るため、停止許容システムであっても ODCR と SP を組み合わせた 24 時間起動の方がよいと考えています。

それでも停止運用をする場合に検討すべきこと

停止運用を採用するのであれば、可能な限りリスクを小さくする対策をすべきです。

Instance Scheduler on AWS を使う

Instance Scheduler on AWS を使うと、EC2 インスタンスの起動と停止を自動的にスケジュール実行できます。また、容量不足で起動に失敗した場合は、事前に登録した代替インスタンスタイプへ変更して再試行できます。

ただし、別のインスタンスタイプで起動することについてシステムへ影響がないか、事前に確認しておく必要があります。また、別のインスタンスタイプでの再試行も同じ AZ の中で行われるため、AZ 全体の容量不足や AZ 障害の場合は回避できません。

起動失敗時のリカバリー作業の人員を確保する

個人的には、これが実際には非常に難しいと感じています。体制を整えるためのコストを含めても停止運用が本当に SP を使うよりもメリットがあるかは慎重に判断したいところです。

まとめ

EC2 インスタンスのコストとキャパシティの確保はトレードオフの関係にあり、キャパシティを確保できないことによるリスクをどこまで取れるかの判断になります。停止運用の場合は平日に毎日起動・停止を繰り返すことから、回数が多い分起動・停止に伴う不具合に遭遇する機会が増えることには留意が必要です。

また、シングル AZ 構成の場合、マルチ AZ 構成に比べて停止リスクが高いので、更に夜間土日の運用でリスクを増やすことは、個人的には避けた方がよいと考えています。

コストだけに目を向けてしまい、可用性というシステム運用に大切な要素を見落としてしまうことがあるので、メリットとデメリットを十分に検討することが大切です。