AWS運用保守の委託範囲と費用｜監視・障害対応・パッチ適用の判断基準

AWS運用保守の見積りは、ほぼ同じ構成でも月5万円から100万円超まで開きます。差を生んでいるのは技術力より先に、対応時間帯と、どこまでを委託範囲に入れたかです。この記事では監視・障害対応・パッチ適用・コスト見直しという四領域に分けて外に出せる作業を整理し、規模別の相場帯、契約前に詰めるSLAとエスカレーション経路、2027年1月1日に終了するAWSサポートの旧プランが委託契約に与える影響までを発注者の視点でまとめました。内製を選ぶかどうかの分かれ目にも触れます。

まとめ：AWS運用保守で外部に出す作業と自社に残る責任の切り分け

AWS運用保守の委託でつまずく原因の大半は、監視項目と対応時間帯を決めないまま月額だけで比べたことにあります。最初に決めるのは、監視・障害対応・パッチ適用・コスト見直しの四領域それぞれをどの深さまで外に出すか。次が対応時間帯で、平日日中のみと24時間365日のあいだには人件費由来の大きな段差があります。

費用は委託費とAWS利用料の二本立てで、見積書ではこれに監視ツールとログ保管の実費を加えた三つを分けて書かせてください。比較メディアが公開している相場帯では、小規模で月5万〜20万円、中規模で20万〜80万円、24時間対応が入ると20万〜100万円以上に伸びます。

委託しても消えない責任があります。AWSの責任共有モデルでは、EC2のゲストOSの更新とセキュリティパッチ、インストールしたアプリケーション、セキュリティグループの設定は顧客側の責任です。委託先はそれを代行するだけで、適用可否の承認と権限設計の妥当性判断は発注者に残ります。

加えて2026年から2027年にかけて、AWSサポートの契約前提が変わります。Developer Support・Business Support・Enterprise On-Ramp は2027年1月1日に提供終了。Enterprise Support の最低月額は15,000ドルから5,000ドルへ下がりました。

AWS運用保守の作業内容＝監視・障害対応・パッチ適用・コスト見直しの四領域

「AWS運用保守」に業界共通の定義はありません。同じ名前でも、死活監視だけを指す会社と、コスト見直しやセキュリティ更新まで含める会社が混在します。AWSの仕組みや料金モデルを前提から確認したい場合は、クラウドとは何か・AWSとは何かの解説を先に読むと、どこまでがAWS側の責務でどこからが運用の話なのかを切り分けやすくなります。

責任共有モデルで顧客側に残るゲストOSの更新とセキュリティパッチの適用

AWSの責任共有モデルは、AWSが「クラウドのセキュリティ」を、顧客が「クラウド内のセキュリティ」を担うという線引きです。公式ドキュメントは顧客責任の範囲として、ゲストOS（更新とセキュリティパッチを含む）、顧客がインスタンスにインストールしたアプリケーションソフトウェアやユーティリティ、AWSが提供するファイアウォール（セキュリティグループ）の設定を明記しています。

ここが委託設計の起点になります。EC2を使う限り、OSパッチの適用義務は発注者側に残り続けます。委託先ができるのは作業の代行であって、責任の移転ではありません。契約書では「パッチ適用の実施」と「適用可否の承認」を分けて書き、後者を自社に残すかどうかを決めてください。検証環境での事前検証を含むのか、再起動を伴う場合の停止調整を誰が顧客部門と行うのかまで決めておくと、月次のパッチ作業が止まりません。

監視で押さえる死活・リソース・ログの三層とCloudWatchアラームの設計

監視は三層で考えると抜けが出ません。

• 死活監視：インスタンスやコンテナ、外形からのURL監視で「落ちたか」を検知する層
• リソース監視：CPU・メモリ・ディスク使用率、RDSの接続数など「落ちる前」を捉える層
• ログ監視：アプリケーションのエラーログや監査ログから、稼働はしているが処理が失敗している状態を拾う層

実務でまず固めるのは死活とリソースの二層です。ログ監視は検知パターンの設計に工数がかかるため、初期は主要エラーの文字列一致に絞るほうが立ち上がりが速くなります。委託先の標準メニューが死活監視だけで止まっている例は珍しくないので、提案書のどこにリソース監視のしきい値が書かれているかを確認してください。

コスト面での注意点も挙げておきます。Amazon CloudWatchの無料利用枠は標準解像度アラーム10個・カスタムメトリクス10個・ログ取り込み5GB/月まで。超過分は標準解像度アラームが月0.10ドル/メトリクス、カスタムメトリクスは最初の10,000個が0.30ドル/個です（いずれも米国東部バージニア北部の表示値）。アラームを数百個並べる設計にすると監視の実費が月数万円規模になるため、委託費とは別枠で見積書に載せてもらいます。

障害対応の一次切り分け＝AWS側の障害とアプリ側の不具合を分ける手順

障害が起きたとき、最初に判定するのは原因がAWS基盤側にあるのかアプリケーション側にあるのかです。AWS側の広域障害なら自社にできることは限られ、待つか代替リージョンへ切り替えるかの意思決定に切り替わります。アプリ側なら、そのまま復旧作業へ。この分岐を誤ると初動が数十分単位で遅れます。

委託契約では、一次対応・復旧作業・恒久対策の三つを分けて範囲を決めてください。一次対応は検知から状況把握と報告まで、復旧は再起動やフェイルオーバーなど手順書に沿った作業、恒久対策は原因分析と改修です。多くの標準メニューは一次対応と手順書内の復旧まで。手順書に無い事象が起きたときに誰が判断するのかも、契約時に書いておく項目です。

AWS側の障害かどうかを確認する具体的な操作手順は、AWS障害の確認方法と原因・対策の解説にまとめています。Health Dashboardの見方は、委託先に任せる場合でも発注者側で把握しておく価値があります。

コスト見直しの実務＝Savings Plansの適用率と未使用リソースの棚卸し

コスト見直しは、運用保守のメニューに入っていたりいなかったりする領域です。入っていなければAWS利用料は右肩上がりのまま放置されます。実務で効く順に並べると、まず購入コミットメントの見直し、次に未使用リソースの停止、最後にインスタンスタイプの見直し。

購入コミットメントではSavings Plansを使います。Compute Savings Plansはオンデマンド比で最大66%、EC2 Instance Savings Plansは最大72%の割引。コミット期間は1年または3年です。ここで見るべき指標は割引率ではなく適用率で、コミット量に対して実使用が下回れば払い損が出ます。月次レポートに「Savings Plansの適用率」と「コミット未消化額」が載っているかを確認してください。

未使用リソースの棚卸しは地味ですが即効性があります。アタッチされていないEBSボリューム、関連付けの切れたElastic IP、検証で作って消し忘れたRDSインスタンス、保持期間を設定していないスナップショット。この四つで月数万円が消えている環境は多く見られます。棚卸しの頻度を月次と契約に書き、削除の承認フローを決めておくと、指摘だけで実行されない状態を避けられます。

AWS運用保守の費用相場と、見積書で内訳を割らせるべき四つの費目

AWS運用保守の費用は、AWSに払う利用料と委託先に払う運用費という性質の違う二つが混ざります。合計額だけを並べても比較になりません。AWS利用料そのものの試算はAWSの見積もりと料金計算ツールの使い方で扱うため、ここでは委託費の側を見ます。

規模別の月額委託費＝小規模5万〜20万円・中規模20万〜80万円という相場帯

比較メディア3本が2026年8月時点で公開している相場帯を、体制の違いとあわせて整理します。一次情報ではないため、金額そのものより「何が入ると段が上がるか」を読み取ってください。

段が上がる要因は、実質ふたつに集約されます。夜間休日の一次対応を人が受けるかどうかと、対象アカウント数です。監視対象のインスタンス台数は、台数課金の会社でも1台あたり数千円程度の刻みで、体制の違いほど金額を動かしません。相見積りでは台数の多寡ではなく、夜間の受付方法（有人か自動通知か）を各社に同じ条件でそろえて出させてください。

見積書で分ける三つの費目＝AWS利用料・運用委託費・監視ツールの実費

見積書は三つに割らせます。第一がAWS利用料で、これは委託先の取り分ではありません。請求代行を挟む場合は手数料率を別行で出してもらいます。第二が運用委託費で、人日単価と想定工数、夜間対応の有無で決まる部分。第三が監視ツールとログ保管の実費で、CloudWatchのアラーム数やログ取り込み量、あるいはDatadogなど外部SaaSのライセンス費が入ります。

四つ目として、スポット作業の単価も先に決めておきます。手順書外の障害調査や緊急のパッチ適用は月額に含まれないのが通常で、都度見積りになると初動が遅れるからです。時間単価か人日単価を契約書に書き、月額に含む作業時間の上限を数値で置いてください。

委託契約で先に詰めるSLA・対応時間帯・エスカレーション経路の条件

運用保守の契約で後から揉めるのは、金額よりも「どの時間帯に誰が何分以内に動くか」です。数値で書いていない契約は、障害の夜に機能しません。

対応時間帯の段差＝平日日中のみと24時間365日で変わる月額の開き

対応時間帯は月額を決める最大の変数です。比較メディアが公開しているサービス構成でも、エントリー相当が9時〜21時（365日）、上位プランが24時間365日という段になっています。24時間365日を人で回すにはシフトが必要で、その人件費がそのまま単価に乗ります。

実務では中間の設計が有効です。監視と自動通知は24時間、有人の一次対応は平日9時〜21時、夜間は待機のみでオンコール発動時に時間課金という組み方。夜間障害の発生頻度が年数回であれば、常時有人待機の月額よりも総額が下がります。過去1年の夜間障害の件数を数えてから時間帯を決めてください。

EC2のSLAはリージョン99.99%・インスタンス99.5%という数値

SLAは二層あります。AWSが顧客に提供するSLAと、委託先が発注者に提供するSLAです。前者はAmazon EC2 SLA（最終更新2022年5月25日）に定められており、リージョンレベルの月間稼働率が99.99%、個別インスタンスレベルが99.5%。下回った場合は99.0%以上99.99%未満でサービスクレジット10%、95.0%以上99.0%未満で30%、95.0%未満で100%が返ります。

気をつけたいのは、AWSのSLAは金銭補償ではなくサービスクレジット、つまりAWS利用料への充当だという点。事業損失は補填されません。委託先が「AWSのSLAは99.99%です」と説明した場合、それは委託先の稼働保証ではないため、混同しないでください。委託先に求めるべきは稼働率ではなく、検知から一次報告までの時間と、復旧着手までの時間です。

AWSサポートケースの起票権限とエスカレーション経路の取り決め

AWSへ技術的な問い合わせを出せるのは、そのAWSアカウントにサポートプランを契約している側です。ここを決めていないと、障害の最中に「委託先経由でしか起票できず、委託先の営業時間外だった」という詰まり方をします。

取り決めるのは三点。自社アカウントでサポートプランを直接契約するのか、委託先のアカウント配下（リセラー契約）に入るのか。緊急時に発注者側の担当者が直接ケースを起票してよいのか。そして委託先が起票したケースの内容を発注者がいつ見られるのか。リセラー契約は請求がまとまり単価も下がる一方、AWSとの直接の窓口を失います。ミッションクリティカルな本番環境では、自社契約を維持して委託先にIAMで権限を付与する形のほうが、障害時の自由度が残ります。

2027年1月のAWSサポートプラン終了が運用委託契約に与える影響

2025年12月2日、AWSはサポートプランの再編を発表しました。現行の商用リージョンで選べるのは Business Support+ ／ Enterprise Support ／ Unified Operations の3本と、全顧客に付く Basic Support です。日本語の解説記事の多くはまだ旧プラン前提のままなので、2026年から2027年に契約更新を迎える運用保守案件では、この変更を織り込んで交渉してください。

既存三プランの2027年1月1日終了とBusiness Support+への移行

Developer Support・Business Support・Enterprise On-Ramp の3プランは、2027年1月1日に提供終了します（AWS GovCloud (US) リージョンでは継続）。Developer と Business の契約者は、それまで既存プランを使い続けるか、任意のタイミングで Business Support+ へ上げるかを選べます。Enterprise On-Ramp は扱いが異なり、2026年中に契約更新のタイミングまたは定期バッチで Enterprise Support へ自動アップグレードされ、1か月前にメール通知が届きます。

プランごとの初回応答時間と最低月額は次のとおりです。

本番システム停止で1時間未満、本番機能低下で4時間未満、一般ガイダンスで24時間未満という応答時間は3プラン共通。24時間365日対応とTrusted Advisorの全チェックも3プランに付き、専任のテクニカルアカウントマネージャーが付くのは Enterprise Support 以上です。

Enterprise Supportの最低月額5,000ドルへの引き下げと委託判断

今回の再編で運用委託の設計に効くのは、Enterprise Support の最低月額が15,000ドルから5,000ドルへ下がったことです。旧 Enterprise On-Ramp（15,000ドル相当の帯）にいた規模の環境が、より安い金額で15分応答と専任TAMを得られる計算になります。

ここから導かれる判断はひとつ。中規模以上の本番環境で「委託先の24時間有人対応」に月80万円を払っている場合、その一部をAWSのEnterprise Supportに振り替えたほうが、障害時の技術的な解決力は上がります。委託先の夜間一次対応が実質「AWSへの起票代行」で終わっているなら、なおさらです。委託先には手順書に沿った復旧作業と自社アプリケーション側の調査を任せ、AWS基盤側の切り分けはAWSのサポートに直接投げる。この分担のほうが総額あたりの復旧速度が出ます。

逆に、月間AWS利用額が数十万円規模の小さな環境では Business Support+（月29ドル、または月間AWS利用額の9%のいずれか高い方）で足ります。30分未満の応答と24時間365日対応が付くため、旧 Business Support から実質的な機能低下はありません。

内製と委託の分岐点＝24時間体制の要員数と、委託を見送るべき三つの条件

ここまでを踏まえて、そもそも委託すべきかを判断します。構築フェーズを含む発注全体の損益分岐はAWS構築代行の依頼範囲と費用の解説で扱うため、本章は運用フェーズ固有の変数を見ます。

24時間365日を自社で回す場合の最少人員と月あたり人件費の試算

24時間365日の有人監視を自社で成立させるには、単純なシフト計算で最低4名から5名が必要です。1日24時間を3交代で埋めるだけで3名、そこに休日・有給・退職リスクを吸収する余裕を入れると4名を下回れません。比較メディアが挙げる運用エンジニアの想定年収は500万〜1,000万円。4名なら人件費だけで年2,000万円以上、月換算で170万円前後になります。

この数字は、24時間有人体制の外注が月20万〜100万円という相場帯に対して明確に上回ります。24時間の有人対応が要件なら、委託のほうが安いという結論は動きません。逆に平日日中のみでよい環境なら、既存の情報システム担当者が兼務できる余地があり、内製の側に勝ち目が出ます。分岐は技術力ではなく、要求される時間帯にあります。

委託を見送るべき三条件＝小規模構成・手順書の不在・判断者の不在

次の三つのどれかに当てはまるなら、いま発注しても投資は回収できません。優先度の高い順に挙げます。

第一に、月間AWS利用額が10万円を下回る小規模構成。委託費が利用料を上回る逆転が起き、Business Support+ とCloudWatchの標準アラームで足ります。第二に、運用手順書と構成図が社内に存在しない状態。委託先は手順書に沿って動く契約なので、手順書が無ければ最初の数か月は現状把握の工数を払うだけで終わります。構成図とパラメータシートを先に整えるほうが順序として正しい進め方です。第三に、障害時に停止や切り替えを判断できる人が社内にいない体制。委託先は技術的な選択肢を出せますが、事業影響を踏まえた停止判断を代行することはできません。

三条件のいずれにも当てはまらず、24時間対応が要件に入るなら、委託は合理的です。手順書の整備から並走してほしい場合や、将来の内製化を見据えて運用設計そのものを見直したい場合は、保守運用と内製化支援のサービスで対応範囲を確認してください。

丸投げの発注で監視項目とコスト削減が動かなくなる典型的な進め方

失敗する発注には共通の形があります。監視項目を決めずに「よしなに見てほしい」で契約し、委託先の標準メニュー（死活監視と月次レポート）だけが適用される状態。半年後に「アラートは来るが何も改善しない」という不満が出ます。原因は委託先の怠慢ではなく、しきい値と対応アクションを誰も決めていないことにあります。

コスト見直しも同じ構図で止まります。月次レポートに「未使用のEBSボリュームが12本」と載っても、削除の承認者と期限が決まっていなければ翌月も同じ行が並ぶだけ。指摘に対する社内の判断フローまで契約時に決めておくと、コスト見直しが実行に変わります。

よくある質問

AWS運用保守の委託を検討する段階で多く挙がる質問をまとめました。

AWS運用保守を外部に委託すると月額はいくらかかりますか？

比較メディアが2026年8月時点で公開している相場帯では、EC2数台の小規模構成で月5万〜20万円、冗長構成の本番環境で20万〜80万円、複数アカウントの大規模環境で80万〜200万円以上。24時間対応が入ると20万〜100万円以上の帯に移ります。ただしこれは委託費のみで、AWS利用料と監視ツール・ログ保管の実費は別に発生します。

AWSのマネージドサービスを使えば運用保守は不要になりますか？

作業量は減りますが、ゼロにはなりません。Amazon RDSやAWS Lambdaへ寄せればゲストOSのパッチ適用という作業自体は消えます。一方で、監視のしきい値設計、障害時の切り分けと判断、IAM権限の棚卸し、コストの見直しは残ります。責任共有モデル上、クラウド内のセキュリティは顧客側の責任という線引きが変わらないためです。EC2中心の構成でパッチ運用が重い場合は、委託範囲を広げる前にマネージドサービスへの置き換えを検討する順序が効きます。

委託先はAWSパートナーの認定で選べばよいですか？

足切りには使えますが、運用保守の選定では認定だけでは足りません。パートナーティアは認定資格の保有者数と実績数という数値要件で決まるため客観性がある一方、運用フェーズで効くのは夜間の受付方法、手順書外の事象が起きたときの判断者、月次レポートに適用率や未使用リソースの指摘が載るかどうかです。直近1年の他社案件で夜間障害を何件受けたかを聞くほうが、実態に近い情報が得られます。

AWSサポートプランは自社契約と委託先契約のどちらが得ですか？

金額だけならリセラー経由（委託先契約）が下がることが多く、障害時の自由度なら自社契約が有利です。委託先のアカウント配下に入ると、AWSへの起票経路が委託先の営業時間に依存するためです。ミッションクリティカルな本番環境では自社契約を維持し、委託先にはIAMで作業権限を付与する形を推奨します。

運用保守の契約を途中で別会社に切り替えることはできますか？

できますが、移管性は契約時にしか設計できません。切り替えを可能にする条件は、AWSアカウントの名義が自社であること、運用手順書と構成図が納品物として自社に渡っていること、監視設定がCloudWatchなどAWS標準側に寄っていることの三つです。委託先独自の監視基盤にしきい値と通知設定を持たれていると、乗り換え時にゼロから設計し直しになります。

関連記事

• システム保守とは？運用との違い・費用相場・契約形態：保守契約の型と費用
• システム運用とは？保守との違いから委託判断まで：運用業務の全体像
• システム運用保守の会社はどう選ぶか：相見積りをそろえる手順
• MSPとは？マネージドサービスプロバイダーの役割：包括で預ける選択肢
• AWS構築代行の依頼範囲と費用：構築フェーズの発注判断