AWSの運用を外部へ委託していても、「アラートは届くが原因や再発防止策が分からない」「小さな設定変更にも時間がかかる」「構成や権限を現行ベンダーしか把握していない」といった課題が生じることがあります。

不満があるからといって、すぐに支援会社を変更すれば解決するとは限りません。契約範囲が曖昧なまま依頼していたり、自社側の承認が遅かったり、改善の優先順位を共有していなかったりする場合は、新しい会社へ変えても同じ問題が起こる可能性があります。

重要なのは、現行の運用体制を客観的に評価し、「契約や役割分担を見直せば改善できるのか」「支援会社を変更すべきなのか」を切り分けることです。また、変更する場合は、AWSアカウント、権限、監視設定、運用手順などを漏れなく引き継がなければ、監視の空白や障害対応の遅れにつながります。

本記事では、AWS運用の支援会社を見直すべき8つのサインと、引き継ぎ前に確認する項目を解説します。

支援会社の変更を検討する前に確認したいこと

支援会社への不満は、次の3つに分けて考えると整理しやすくなります。

1. 契約の問題：必要な作業が契約範囲に含まれていない
2. 運用設計の問題：担当、手順、連絡、承認が決まっていない
3. 支援品質の問題：契約した内容が適切に提供されていない

たとえば、24時間監視を契約していても、障害の一次対応や復旧操作が範囲外なら、深夜にアラート通知だけが届くことがあります。これは期待と契約内容の不一致です。

一方、月次報告や改善提案を契約しているにもかかわらず、報告が事実の列挙だけで、原因分析や次の対策が示されない場合は、支援品質の問題と考えられます。

最初に契約書、SLA、作業一覧、問い合わせ記録、月次報告を確認し、期待とのずれを明らかにします。

サイン1：障害通知は来るが、原因と再発防止が残らない

監視サービスでは、アラートを検知して通知することが基本です。しかし、同じ障害が繰り返されているのに、原因、暫定対応、恒久対応、再発防止策が記録されていない場合は注意が必要です。

確認したい点は次のとおりです。

• 障害ごとに発生時刻、影響、対応、原因が記録されているか
• 復旧までの時間と判断経緯を確認できるか
• 同種障害の傾向分析が行われているか
• 恒久対応の担当者と期限が決まっているか
• 監視しきい値や手順書へ学びが反映されているか

通知件数を減らすこと自体が目的ではありません。重要な障害を早く検知し、同じ原因を繰り返さない運用へ改善されているかを見ます。

サイン2：自社と支援会社の責任範囲が曖昧

障害時に「そこは対象外です」「承認待ちです」「アプリケーション側の問題です」と押し戻されることが多い場合、責任分担が不明確かもしれません。

AWSでは、インフラ、OS、ミドルウェア、アプリケーション、ネットワーク、セキュリティ、データなど複数の領域が関係します。誰がどこまで調査し、どの条件で別チームへ引き継ぐかを決めておく必要があります。

RACI表などを使い、次を整理します。

• 監視対象と通知先
• 一次切り分けの担当
• 再起動や切り戻しを実行できる担当
• AWSサポートへ問い合わせる担当
• アプリケーションチームへ連携する条件
• 顧客・利用者へ説明する責任者
• 変更作業を承認する責任者

担当者名だけではなく、役割と連絡経路を文書化します。

サイン3：構成図や運用手順が現状と合っていない

AWS環境は、日々の変更で構成が変わります。構成図、パラメータシート、監視一覧、運用手順が更新されていないと、障害時の調査やベンダー変更に時間がかかります。

次の状態があれば、文書管理を見直す必要があります。

• 構成図に存在しないリソースが稼働している
• 監視対象と実際のシステムが一致しない
• 手順書の画面やコマンドが古い
• 最終更新日や承認者が不明
• 文書が担当者個人の端末やベンダーの環境にしかない
• 緊急時に必要な情報を検索できない

すべてを詳細な設計書へ戻す必要はありません。現在の運用に必要な情報を優先し、変更時に更新するルールを決めます。

サイン4：AWSアカウントや権限を自社で管理できない

支援会社の変更で特に大きなリスクになるのが、アカウントと権限です。

ルートユーザーのメールアドレス、MFA、請求情報、AWS Organizationsの管理、IAMユーザー・ロール、アクセスキーなどを自社で把握できていない場合、契約終了後に必要な操作ができない恐れがあります。

次を確認します。

• ルートユーザーを自社が管理しているか
• MFAデバイスと復旧手段を自社が保有しているか
• 支援会社向け権限が個人ではなく役割として管理されているか
• 不要になった権限を無効化できるか
• アクセスキーや秘密情報の保管場所が明確か
• 操作ログを自社で確認できるか
• 契約終了時の権限削除手順があるか

ベンダー変更を決めてから慌てて回収するのではなく、通常時から自社がアカウントの統制を持つ状態にします。

サイン5：月次報告に改善提案がない

月次報告が「アラート件数」「問い合わせ件数」「実施作業」の一覧だけで終わっている場合、運用代行は行われていても、改善活動が進んでいない可能性があります。

運用改善では、次の観点を定期的に確認します。

• 同じアラートや作業の繰り返し
• リソース使用率と容量の傾向
• バックアップ・リストアの確認
• セキュリティ更新や脆弱性
• AWS利用料の増減
• 手作業の自動化候補
• EOL・EOSやサービス変更への対応
• 障害対応時間と未解決課題

改善提案が契約範囲外なら、オプションや別契約として依頼する方法もあります。必要なのは、現状維持だけを求めるのか、継続改善まで求めるのかを明確にすることです。

サイン6：コスト・セキュリティ・可用性を別々にしか見ていない

AWS運用では、性能を上げればコストが増える、セキュリティを強化すれば運用手順が変わるなど、複数の観点が影響し合います。

たとえば、利用率が低いインスタンスを縮小する提案は、性能と可用性の確認なしに実行できません。ログ保存期間を短くする施策は、監査や障害調査への影響を確認する必要があります。

支援会社からの提案が単一の観点に偏っている場合は、次を確認します。

• コスト変更が性能・可用性へ与える影響
• セキュリティ変更が運用負荷へ与える影響
• 冗長化やバックアップが復旧目標を満たすか
• 運用手順が実際の人員と時間帯で実行可能か
• 変更後の検証と監視が計画されているか

AWS Well-Architected Frameworkなどの共通観点を使うと、議論を整理しやすくなります。

サイン7：対応品質が特定担当者に依存している

「詳しい担当者がいる日は早いが、休みの日は進まない」という状態は、属人化のサインです。

支援会社側に優秀な担当者がいても、情報や判断が共有されていなければ、異動・退職時に品質が下がります。確認したいのは、担当者個人の能力だけではなく、チームとして対応できる仕組みです。

• 問い合わせ履歴が共有されているか
• 障害対応の手順と判断基準があるか
• 複数名が環境を理解しているか
• 引き継ぎやレビューが行われているか
• 緊急連絡先が1人に限定されていないか
• 担当交代時の教育期間が確保されるか

自社側も窓口を1人へ集中させず、重要な決定と背景を共有できるようにします。

サイン8：契約終了時の引き継ぎ条件が決まっていない

契約更新時には費用や対応範囲を確認しても、終了時の扱いを確認していないケースがあります。

次の内容を契約や運用ルールで確認します。

• 引き継ぎ期間
• 提供される文書とデータ
• アカウント・権限の返却や削除
• 監視設定と通知先の移管
• 未完了課題の扱い
• 最終月の障害対応範囲
• 新旧支援会社の並行期間
• 引き継ぎ作業にかかる費用

終了条件が曖昧な場合は、変更を決める前に現行支援会社と協議します。

委託先変更か、現行体制の改善かを判断する

8つのサインに該当しても、すぐに変更するとは限りません。次のように判断します。

現行体制の改善を優先しやすいケース

• 契約範囲と期待のずれが主な原因
• 担当者や報告内容を変えれば改善が見込める
• 構成や業務知識が現行会社に蓄積されている
• 追加の運用設計や改善契約で不足を補える
• 自社側の承認・情報共有にも課題がある

支援会社変更を検討しやすいケース

• 契約内容が継続的に履行されない
• 重大障害への対応や報告に問題がある
• アカウント・権限の統制に協力が得られない
• 改善要求を繰り返しても変化がない
• 必要な技術領域や対応時間を提供できない
• 契約終了時の引き継ぎに非協力的である

判断時は、現行会社への不満だけでなく、新しい会社へ求める成果と評価基準を明確にします。

引き継ぎ前に確認する8項目

支援会社を変更する場合は、次の8項目を一覧化します。

1．契約・連絡体制

契約範囲、SLA、対応時間、緊急連絡先、エスカレーション先、定例会、承認者を整理します。

2．AWSアカウント・請求管理

対象アカウント、AWS Organizations、請求先、サポート契約、ルートユーザー管理、MFAを確認します。

3．構成情報・資産一覧

AWSリソース、ネットワーク、DNS、証明書、外部接続、OS・ミドルウェア、ライセンスを一覧化します。

4．IAM・秘密情報

IAMユーザー、ロール、ポリシー、アクセスキー、秘密情報、踏み台、VPNなどの管理と削除手順を確認します。

5．監視・通知

監視対象、しきい値、通知先、一次対応、抑止設定、メンテナンス時の扱い、監視の空白がないかを確認します。

6．運用手順・変更管理

定常作業、バックアップ、パッチ、起動停止、リリース、変更申請、緊急作業の手順と承認経路を引き継ぎます。

7．障害・課題履歴

過去の障害、原因、再発防止、既知の制約、未完了課題、性能・容量の懸念を共有します。

8．移管計画と受け入れ確認

新旧会社の並行期間、説明会、操作確認、監視テスト、障害訓練、最終承認、旧権限削除日を決めます。

現行のAWS運用体制を見直したい方は、SunnyCloudへAWS運用・監視について相談できます。問い合わせフォームで「AWS運用／監視」を選択し、現在の体制や課題をご記載ください。

移管中に監視と障害対応を途切れさせないポイント

移管では、旧会社の契約終了日と新会社の開始日を同日にするだけでは不十分です。新会社が環境を理解し、監視通知を受け、手順を実行できる状態になるまで並行期間を設けます。

受け入れ確認では、次を実施します。

• テストアラートが新しい窓口へ届くか
• 問い合わせとエスカレーションが機能するか
• 定型の復旧手順を実行できるか
• バックアップから復元できるか
• 権限不足や過剰権限がないか
• 既知の障害や注意点を説明できるか
• 月次報告に必要なデータを取得できるか

旧会社の権限は、新会社の受け入れ完了後に削除します。引き継ぎ資料を受け取っただけで完了とせず、実際に運用できるかを確認することが重要です。

まとめ：支援会社の見直しは、運用品質を定義する機会

AWS運用の委託先を変えること自体が目的ではありません。障害対応、監視、構成管理、コスト、セキュリティ、改善活動について、自社が必要とする品質を定義し直すことが重要です。

見直すべき8つのサインは次のとおりです。

1. 障害の原因と再発防止が残らない
2. 責任範囲が曖昧
3. 構成図や手順が古い
4. アカウントや権限を自社で管理できない
5. 改善提案がない
6. コスト・セキュリティ・可用性を統合して見ていない
7. 対応品質が特定担当者に依存する
8. 契約終了時の引き継ぎ条件がない

まず、契約・運用設計・支援品質のどこに問題があるかを切り分けます。変更する場合は、アカウント、構成、権限、監視、手順、障害履歴を引き継ぎ、新旧体制の並行期間を設けます。