1. はじめに
2. SSM統合コンソールによる一元管理
3. OSなど構成情報の可視化
4. Patch Managerによるパッチ運用の標準化
5. 証明書有効期限の集中監視と自動通知
6. 導入効果と業務改善イメージ
7. 導入時の設計上の留意点
8. 継続的改善を支える「運用の仕組み化」

1.はじめに

クラウド活用が拡大し、AWS環境が複数アカウントで利用されたり、複数システムにまたがって利用されることは、システム運用における構成の一貫性を維持することの難易度を高めています。

特に、チームや事業部ごとに異なる運用ルールが存在する環境では、OSやミドルウェアのバージョンが混在し、パッチ適用や証明書更新のタイミングが統一されないなどの問題が頻発します。これらの状況が続くと、セキュリティリスクの増大や監査対応工数の肥大化につながるだけでなく、継続的な改善活動を阻害する要因ともなります。

本記事では、複数のAWSアカウントを運用する環境においてAWS Systems Managerを中心に、AWS Config AggregatorおよびAWS Organizationsを組み合わせることで、OS・インストールパッケージの構成管理、パッチ適用・証明書管理といった運用を統合的に管理し、標準化されたセキュリティ運用を実現するためのアーキテクチャと考え方を解説します。

2.SSM統合コンソールによる一元管理

AWS Organizations配下で複数のアカウントを運用する場合、各環境を独立して管理するのではなく、中央集権的な監視・統制基盤用のアカウントに情報を集約する構成が有効です。情報集約の中核を担うのがAWS Systems Manager（以下、SSM）です。

各アカウントに配置されたEC2インスタンスや関連リソースの構成情報（OS・ソフトウェア構成情報）をアカウント内のSSM Inventoryで収集します。各アカウントから、SSMにて「委任」の設定を行う（※1、※2）ことで、集約用アカウント（以下SSM委任アカウント）にSSM Inventoryで収集した情報が連携され、SSM委任アカウントの統合コンソールにてアカウント横断的に情報を確認できるようになります。

※1．委任の設定はAWS Organizationsを利用していることが前提です。

※2．AWS Organizations管理アカウントをSSM委任アカウントに指定することは現時点（2025年11月）ではできません。また、Organizations管理アカウント内のリソースはSSM委任アカウントでの一元管理の対象にできません。

AWS Organizations×Systems Manager活用イメージ

3.OSなど構成情報の可視化

SSM Inventoryは、インスタンス上のOSやアプリケーション、パッケージのバージョン情報などを自動的に収集し、最新の構成状態を可視化する機能です。これにより、どのサーバーがどのバージョンで稼働しているのかを即座に把握でき、環境全体の構成ドリフトを早期に検出することが可能となります。収集された全ノードの情報はSSM委任アカウントに連携されます。また、SSM委任アカウントから はResource Data Syncを利用してS3に同期することができます。S3に同期されたデータに対してAmazon Athenaでクエリを実行し、結果をQuickSightに連携することでアカウントを横断して構成情報を集計・可視化・分析することができます。これにより、監査対応時には全システムの構成一覧を迅速に生成でき、コンプライアンス報告の効率化にも寄与します。

引用：複数の AWS アカウント とAWS リージョン とのリソースデータ同期（2025/10/14 時点）

後述のパッチポリシーの遵守状況を含め、AWSリソースのコンプライアンス準拠状況は、各アカウントのAWS Configにてチェックされます。各アカウントからConfig委任アカウントに委任を設定することで、Config委任アカウントのAWS Config Aggregatorにてコンプライアンス準拠状況を一元管理できるようになります。適用すべきパッチ（Patch Baselineにて定義）の未適用など、ルール非準拠が検出された場合はAWS ConfigからEventBridgeを介してSNSで通知します。

4.Patch Managerによるパッチ運用の標準化

システムの脆弱性対策において、パッチ管理の一貫性は極めて重要です。SSM Patch Managerを利用すれば、OSやアプリケーションに対するパッチ適用をルール化し、自動的に実行することが可能です。

例えば、検証環境では毎週土曜日の深夜に最新のセキュリティ更新を適用し、本番環境では日曜日のメンテナンス時間帯に検証済みのパッチのみを適用するといったポリシーを柔軟に設定できます。適用結果はS3に記録されます。未更新インスタンスが存在する場合は非準拠のリソースとしてAWS Configで検出され、EventBridge、SNSを介して管理者に通知されます。これにより、パッチ適用漏れを防ぎつつ、更新状況を定量的に追跡できるようになります。

パッチポリシーはSSM委任アカウントにてクイックセットアップを利用して作成し、各アカウントに共通で適用することが可能です。少ない設定で、Organizations全体やOU単位、アカウント単位など柔軟な範囲に、必要なパッチポリシーを割り当てることができます。ただしリージョンによっては非対応（例：2025年10月時点では大阪リージョンは非対応）のため、非対応のリージョンを利用している場合や、より細かい制御を検討したい場合にはCloudFormation StackSetsを利用したポリシー展開を検討します。

パッチ自動適用の構成例（CloudFormation StackSets利用）
引用：複数の AWS アカウントとリージョンのパッチソリューション設計（2025/10/14 時点）

5.証明書有効期限の集中監視と自動通知

運用現場で発生しやすいインシデントの一つに「証明書の期限切れによるサービス停止」があります。AWS Certificate Manager（ACM）で管理されている証明書について、マネージドの証明書であればいくつかの条件を満たす必要はありますが、自動更新を利用可能です。まずは自動更新の利用を検討し、ヒューマンエラーによる証明書有効期限切れを予防しましょう。

マネージド証明書の更新

自動更新が利用できない場合、AWS Configのマネージドルールにて期限接近を検出可能です。例えばConfigルールによって30日以内に期限切れとなる証明書を検出し、EventBridgeを経由してSNS経由で通知を発行する仕組みを構築すれば、担当者は証明書が期限切れとなる前にSlackやメールでアラートを受け取ることができます。これにより、証明書の残存日数やドメイン名、ARNといった情報が定期的に共有され、運用上のヒューマンエラーを未然に防止できます。

証明書有効期限監視と自動通知フロー 構成例

6.導入効果と業務改善イメージ

これらの仕組みの導入により、運用効率が改善されます。例えば、従来は月20時間かかっていたパッチ適用作業が3時間に短縮され、証明書更新ミスは年間数件からゼロ件に減少します。

また、環境監査の準備期間は約10日から1日以内に短縮され、運用担当者間の情報差異も減少し、日常的な保守対応の削減が実現されます。

7.導入時の設計上の留意点

運用の仕組みを効果的に機能させるために、設計上のポイントを押さえる必要があります。

事前にAWS OrganizationsとOUの設計を整理し、Patch Managerの適用範囲を明確にすることが必要です。

次に、SSM Agentの自動展開を徹底し、未導入のインスタンスを発生させない（= 導入カバレッジを上げる）ことも大切です。そのためには、Launch TemplateやTerraformなどのIaCツールのテンプレートにSSM Agent設定を組み込む運用が推奨されます。

また、SNSによる通知チャネルはSlackやメールなど複数の経路に対応できるよう柔軟に設計し、IaC（Infrastructure as Code）によってPatch BaselineやConfigルールをコード化することで、変更履歴をGitなどの構成管理ツールで追跡可能にし、構成の再現性を高めることも効果的です。

8.継続的改善を支える「運用の仕組み化」

AWS Systems ManagerとConfig Aggregatorを活用した一元管理は、単なる自動化の実現ではなく、持続可能な運用体制そのものの設計を意味します。これにより、OS・パッチ・証明書といった重要要素の更新状況を即時に把握し、構成情報やセキュリティ設定を統合的に監査する仕組みを確立できます。さらに、運用チーム間の情報共有を自動化することで、システムの信頼性とセキュリティを高い水準で両立させることが可能になります。

最終的に、保守運用チームは障害対応や手作業の更新から解放され、改善や機能追加など、システムの価値を高める業務に集中することができます。これこそが、AWSによる運用の仕組み化がもたらす最大の価値であり、組織全体の運用品質を継続的に向上させる基盤と考えています。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse