AMS Trusted Remediator でコスト最適化とセキュリティ修復を自動化する

本記事は 2026 年 2 月 5 日に公開された”Optimize cost and automate security remediation with AMS Trusted Remediator” を翻訳したものです。

Amazon Web Services (AWS) を活用している組織は、セキュリティとコスト最適化に関する推奨事項を毎月数千件も受け取ります。しかし、優先順位の問題やリソースの制約からその多くは実施されないままとなっています。AWS Managed Services (AMS) の Trusted Remediator はこの課題を解決するため、複数の AWS アカウントにわたる修復を自動化し、手作業による修復にかかる時間と手間を大幅に減らします。あらかじめ用意された修復ライブラリは、116 件の推奨事項に対応しており、新しい機能が加わるたびに増え続けています。これらの自動化は、セキュリティ、コスト最適化、運用上の優秀性の各分野にわたります。企業はセキュリティホールを効率よくふさぎ、コストを最適化し、コンプライアンスを維持しながら AWS のベストプラクティスの変化にも柔軟に対応できます。

課題:インサイトが行動につながらない

実行すべき推奨事項は、AWS Trusted Advisor、AWS Security Hub CSPM、AWS Compute Optimizer、AWS Well-Architected のレビューなどから、毎月数千件も生成されます。これらのインサイトは、セキュリティの向上、コストの削減、耐障害性の強化、コンプライアンスの維持への道筋を示します。ところが肝心なのはそのうちどれだけ実施されているかです。意欲のある組織でも推奨事項のかなりの部分を修復しきれていません。その結果、重大な脆弱性が残りコンプライアンス上の不備が放置され、コスト最適化の機会が生かされないままになっています。

優先順位の競合が実施の壁になる

多くの企業は「自分で作り、自分で運用する (you build it, you run it)」という考え方を取り入れています。そのため、アプリケーションチームは運用まで自分たちで責任を持ち自律的に判断できるようになる一方で、バックログには優先順位を争うタスクが積み上がります。たとえば、プロダクトマネージャーは新機能を求め、エンジニアリングのリーダーは開発速度を保つために技術的負債の削減を重視し、ビジネスの関係者は売上につながる信頼性の向上を期待します。このようにすでに混み合っているバックログに修復作業まで加わります。修復は組織のセキュリティとコンプライアンスに欠かせませんが、エンドのお客様には見えず、ビジネス指標に直接影響するお客様向けの機能と比べると優先する理由を説明しにくい作業です。こうして、プラットフォーム、SecOps、FinOps のリーダーは全社のセキュリティ状況とコンプライアンスの成果に責任を負っていながら、各アプリケーションチームに対して直接指示する権限はないという根本的なずれが生まれます。

実施を阻む現実的な課題

修復に前向きなアプリケーションチームでも現実にはさまざまな壁にぶつかります。必要な変更を行う権限がなく、追加の承認や、組織の境界を越えた調整が必要になることがよくあります。また検出された内容を調べてビジネスへの影響を理解するのにも、特に複雑なサービスや構成ではかなりの時間がかかります。さらに、変更が安全か既存のワークロードと互換性があるかを慎重に評価する必要があり、これには専門知識と注意深さが求められます。最後に、運用の基準を守るため、修復のたびにドキュメントの作成と検証も必要です。これらが重なると 1 件の修復にかかる期間が数時間から数日、場合によっては数週間にまで延びます。そのため自動化なしですべての推奨事項に対応し続けるのは現実的ではありません。

修復のギャップ:よい推奨事項が実施されない理由

手作業による修復は企業の規模やニーズが大きくなるほど対応しきれなくなります。調査、実施、テスト、ドキュメント作成に加えてサービスの知識も必要で、本来はイノベーションに充てるべきエンジニアリングのリソースを大量に消費してしまうためです。

その影響は小さくありません。たとえば、優秀なエンジニアが Amazon Simple Storage Service (Amazon S3) バケットのログ記録の有効化や Amazon Elastic Compute Cloud (Amazon EC2) のインスタンスタイプの調整といった推奨事項の実施に時間を取られ、お客様向けのプロダクトを作る時間が削られます。その結果、推奨事項は次々と生成される一方で、対応に割ける時間は限られているため、実施が追いつかずその差が広がっていきます。未対応の指摘は脆弱性として残り、最適化の遅れは無駄なコストにつながります。またコンプライアンスの不備は規制リスクを生み、積み上がるバックログはチームの士気を下げます。

こうした状況では推奨事項の量と修復の対応力が根本的に釣り合っていないため、修復をその都度の手作業に任せるのではなく、体系的で自動化されたプロセスとして見直す必要があります。問うべきは修復を自動化するかどうかではありません。手作業のプロセスが限界を迎える前に、どれだけ早く自動化を進められるかです。

解決策:AWS Managed Services (AMS) Trusted Remediator

AWS Organizations 全体での自動修復

AMS Trusted Remediator は複数アカウントの AWS 環境にまたがって、包括的な自動修復をスムーズに実行します。具体的には Trusted Advisor、Security Hub CSPM、Compute Optimizer の検出事項を統一された枠組みで扱い、数週間かかっていた手作業を数分の自動処理に変えます。これにより修復にかかる時間を最大 95% 短縮できます。またテストを重ねて有効性が確認された修復をいくつかの簡単な手順で設定し、安心してデプロイできます。こうした企業規模の自動化とわかりやすい使い勝手の組み合わせにより、手作業の負担なしにセキュリティホールをふさぎ、コストを削減し、コンプライアンスを維持できます。

図 1: Trusted Remediator の構成図

この図は AMS Trusted Remediator のソリューション構成を示しています。まず AWS AppConfig が委任管理者アカウントを通じて修復の設定を管理します。一方、AWS Trusted Advisor は 1 から n までのメンバーアカウントで問題を検出します。検出された問題は Systems Manager Automation ドキュメントで自動的に修復され、Systems Manager OpsItems (1 から n まで) で活動が追跡されます。最後に、結果は Amazon S3 に記録され Amazon Quick のダッシュボードで可視化されます。

修復の対象範囲:116 件の自動化と、急速に広がる対応範囲

このソリューションは 6 つの重要な運用分野にわたり、自動修復に対応する 116 件のチェックを提供します。最も多いのはセキュリティの 64 件で、設定の誤り、コンプライアンス違反、アクセス制御の管理に対応します。コスト最適化の 16 件は、未使用リソースの特定、適切なサイズへの変更、コストの非効率の修復を扱います。耐障害性の 17 件は、バックアップ戦略の強化、災害対策の構成、システムの回復力に注目します。パフォーマンスの 8 件は、リソースのサイジングとチューニングの推奨事項を扱い、サービス制限の 7 件は、クォータ管理とキャパシティ計画に対応します。運用上の優秀性の 4 件は、適切なモニタリング、ログ記録、運用のベストプラクティスの実施を確認します。

AMS Trusted Remediator の主な機能

安全な修復の枠組み

AMS Trusted Remediator は安全に修復を進めるための枠組みを備えています。重要な修復についてはリソースの種類や環境に応じて、人の承認を挟む手動ワークフローとして扱うよう設定できます。この方法ならガバナンスに必要な統制を保ちつつ、自動化の利点を最大限に引き出せます。この枠組みの中核となるのは AWS Systems Manager の Automation ドキュメントです。繰り返し実行できて冪等性があるように丁寧に設計されているため、AWS インフラストラクチャ全体で一貫して信頼できる修復結果が得られます。

他のサービスとの連携

AMS Trusted Remediator は既存の AWS 運用ツールとスムーズに連携し、クラウド運用を強化する包括的な自動化の仕組みを作ります。具体的には Trusted Advisor、Security Hub CSPM、Compute Optimizer の検出事項を自動で取り込んで修復し、最も重要な問題から優先して対処できます。修復の過程では、実行者、操作、タイムスタンプ、対象リソースといった重要な詳細を含む完全な監査証跡を保持し、コンプライアンス報告やインシデント発生後の原因調査(フォレンジック分析)に必要な情報を提供します。

一元管理コンソール

運用チームは複数アカウントの修復を 1 つの画面で管理・監視できます。コンソールには委任管理の機能があり各運用チームが自分の担当範囲の修復を管理しながら、組織全体の監督と統制も維持できます。

図 2: Trusted Advisor の検出事項に対する Trusted Remediator のワークフロー

この図は AMS Trusted Remediator のワークフローを示しています。まず AWS Trusted Advisor がリソースの問題を検出します。次に、検出された問題をあらかじめ定義された Trusted Remediator の設定に照らして評価します。ソリューションが適切な修復アクションをスケジュールし、AWS Systems Manager Automation ドキュメントで自動修復を実行して検出された問題を解決します。

導入のロードマップ

前提条件

ソリューションを導入する前にいくつかの重要な前提条件を満たす必要があります。まず AMS Accelerate の利用契約が有効であることが必要です。また、セキュリティ、FinOps、運用の各チームの足並みをそろえ、スムーズに導入できるようにしておくことも欠かせません。技術面では修復の元になる検出事項を得るために、Trusted Advisor、AWS Security Hub CSPM、Compute Optimizer を有効にしておく必要があります。最後に修復の過程全体で監査の可視性とコンプライアンスの追跡を確保するため、Amazon CloudWatch と AWS CloudTrail を設定しておきます。

4 段階の導入ステップ

フェーズ 1:評価と計画

導入は Trusted Advisor、Security Hub CSPM、Compute Optimizer から出ている現在の未対応の修復の包括的な分析から始まります。この分析で効果の大きい自動化の機会を見つけます。このフェーズではガバナンスの枠組みを整え、ワークフローを定義しビジネス上の価値とリスクに応じて修復の優先順位を決めます。またこのフェーズの成果物は優先順位をつけた実施リストと、明確に定義された成功指標です。この成功指標が以降のプロジェクトの指針になります。

フェーズ 2:構成と設定

計画フェーズが終わったら組織の要件に合わせて Systems Manager の Automation パラメータを設定します。クラウド運用チームは通知、ロールバックの仕組み、重要な操作の承認ゲートといった安全のための基本的な統制を実装します。修復の活動と進捗を把握できるよう運用ダッシュボードも作成します。このフェーズの終わりには堅牢なモニタリングを備え、最初のテストに進める本番に対応した自動化の基盤が整います。

フェーズ 3:パイロット導入

検証はリスクを抑えながら早く成果を出せるコスト最適化の修復から非本番環境で始めます。アプリケーションチームは自動修復がアプリケーションの機能、パフォーマンス、既存の連携に悪影響を与えないことを十分にテストして確認します。あわせて依存するサービス、ワークロードの動作、運用ワークフローへの影響も分析します。そのうえでチームは結果を注意深く監視し、パフォーマンスの指標を集め、関係者の意見やシステムの観察結果をもとに設定を調整します。テストにはアプリケーションのヘルスチェック、パフォーマンスのベンチマーク、互換性の評価も含まれ、修復がアプリケーションの要件や事業継続の基準に合っていることを確認します。このフェーズの成功はインシデントがゼロであることと、測定できるコスト削減が得られることで判断し、本格的な展開の前にソリューションへの組織内の信頼を築きます。

フェーズ 4:本番環境への展開

最後のフェーズでは少しずつ慎重に本番アカウントにも自動化を広げていきます。セキュリティの修復は安全に実行できる仕組みを整えてから有効にします。またソリューションへの信頼と経験が深まるにつれて、より複雑な複数ステップのシナリオにも対象を広げます。最終的な成功の基準は組織のすべてのアカウントで 80% 以上の自動修復率を達成し、コスト効率とセキュリティの状況を継続的に改善することです。

導入事例

カーティン大学:セキュリティコンプライアンスの強化

カーティン大学は世界でも上位に評価される研究機関で、5 つの海外キャンパスに分散した AWS 環境を管理しており、重要なセキュリティ課題を克服するため AMS と連携しました。同大学では増え続けるクラウドセキュリティのニーズに対し、技術的なリソースが限られていました。また手作業による修復は時間がかかるうえに一貫性がなく、セキュリティホールが生じていました。さらにキャンパスごとにセキュリティの運用が異なり、標準化が難しく、コンプライアンスの維持も困難でした。AMS Trusted Remediator の導入により同大学は半年で AWS Security Improvement Program (SIP) のスコアを 32% 改善し、年間目標を前倒しで上回りました。また優先度の高い 18 のチェックでセキュリティ修復を自動化すると同時に、78 件のコスト最適化も実施しセキュリティとコストの両面で効果を上げています。加えて、一元化されたプラットフォームによって分散したチーム間のコミュニケーションのギャップが埋まり、手作業が大きく減りました。この事例は複雑な組織構造を持つ企業でも、マネージドサービスによる自動化を通じてリアクティブな対応からプロアクティブなセキュリティ管理へと転換し、運用効率とコンプライアンスの成果を高められることを示しています。

金融機関:多数のアカウントで運用上の優秀性とコンプライアンスを実現

30 を超える AMS アカウントを管理する大手金融機関は多くの企業に共通する課題に直面していました。四半期ごとの厳しいコンプライアンス目標を達成しなければならない一方で、セキュリティチームは手作業の修復に追われていました。またセキュリティは同社の最優先事項でしたが、複数アカウントの環境で検出された件数が膨大でコンプライアンス要件に遅れないよう素早く対処することは困難でした。

AMS Trusted Remediator を導入すると変化はすぐに目に見える形で表れ、1,000 件を超えるセキュリティと運用の検出事項が自動的に修復されました。そのうち 64% は重要なセキュリティ強化に関するものです。たとえば機密性の高い金融データを守るために Amazon Relational Database Service (Amazon RDS) データベースでプロアクティブなモニタリングを有効にし、S3 バケットのログ記録も有効にしました。それにより手作業が減りコンプライアンスに準拠するまでにかかる時間も短縮されたことで、セキュリティチームはリアクティブな対応に追われる状態からセキュリティ状況を戦略的に改善する業務に移れました。この成果を受けて同社と AMS は現在、コンプライアンスの枠組みをさらに強化するため Trusted Remediator で扱う Security Hub CSPM のコントロールを追加で検討しています。

まとめ

AMS Trusted Remediator はクラウド運用の管理を根本から変えます。セキュリティ、コスト最適化、運用の各分野にわたる包括的な自動修復を提供し Trusted Advisor、Security Hub CSPM、Compute Optimizer ともスムーズに連携します。大幅な時間の節約やコストの大きな削減といった、これまでに確認された成果はリアクティブなインシデント対応からプロアクティブな最適化へ移行できることを裏づけています。この移行により、組織は数日かかっていた修復サイクルをほぼ即時の対応にまで短縮できます。また一貫性のない手作業の実施は標準化された自動化に置き換わり、多くのリソースを要していたプロセスは効率のよい運用へと変わります。なお繰り返しの多い修復作業を自動化すれば技術チームはイノベーションと戦略的な取り組みに力を注げます。同時に AWS 環境全体で優れたセキュリティ状況、コンプライアンスの遵守、コスト効率を維持できます。

AMS Trusted Remediator の詳細と、カーティン大学の導入事例の全文については、次のリソースをご覧ください。

翻訳はオペレーションエンジニアの上原が担当しました。原文はこちらです。

Amazon Web Services ブログ