AWS構成管理の進め方｜設定変更を把握し、属人化を防ぐ方法

アマゾンウェブサービス（AWS）では、リソースの追加や設定変更を重ねるうちに、現在の構成や変更経緯を把握しにくくなることがあります。複数の担当者が手作業で変更している環境では、設定のばらつきや管理の属人化も起こりやすくなります。

こうした課題に対応するには、AWS Configで構成や変更履歴を記録するだけでなく、AWS CloudFormationなどのIaCを活用し、変更方法まで含めて管理する仕組みが必要です。

本記事では、AWSで構成管理する対象や代表的なサービスを整理し、構成を把握・標準化しながら継続的に運用する進め方を解説します。

AWSにおける構成管理とは

AWSの構成管理では、EC2やVPC、IAMなどの設定や変更履歴を記録し、意図した構成とのずれを把握できる状態を整えます。

リソースの変更が積み重なると、設計書と実環境が一致しなくなることがあります。そのため、AWS Configなどを使い、実際の構成を継続的に確認できるようにします。

AWSで構成管理が必要になる理由

複数の担当者が個別に設定を変更していると、設計時の構成と実環境にずれが生じたり、変更理由を追えなくなったりします。障害発生時の原因調査や設定の見直しにも時間がかかります。

構成や変更履歴を記録し、可能な範囲でIaCを取り入れて変更手順を共通化すれば、設定のばらつきを抑えられます。AWS Well-Architected Frameworkでも、インフラストラクチャをコードとして管理し、変更を追跡できる仕組みが推奨されています。

オンプレミスの構成管理との違い

構成管理の目的は、AWSでもオンプレミスでも大きく変わりません。違いは、リソースを短時間で追加・変更できることです。

オンプレミスでは、物理機器の調達や設置を伴う変更もあります。一方、AWSではAPIやAWS Management Consoleからリソースをすぐに変更できるため、実環境が設計時の状態から変化しやすくなります。

そのため、設計書の更新だけに頼らず、実際の構成と変更履歴を継続的に確認できるようにしておく必要があります。

AWSで構成管理する主な対象

構成管理の対象は、大きく分けると、AWSリソースの設定、構成変更の履歴、EC2内部のOS・ソフトウェアです。それぞれ管理する情報や方法が異なるため、対象を分けて整理します。

AWSリソースの設定情報

EC2、VPC、セキュリティグループ、IAM、S3など、AWSリソースの設定情報を管理します。

たとえば、セキュリティグループの通信ルール、EC2インスタンスが配置されているVPCやサブネット、S3バケットの設定などです。設計書に記載された構成だけでなく、実際に稼働している環境がどのような状態にあるかも把握できるようにしておきます。

AWS環境の設定不備を確認する方法については、以下の記事も参考にしてください。

>> AWSの設定不備をどう見つける？セキュリティ診断の種類と進め方

構成変更の履歴

構成管理では、現在の設定だけでなく、「いつ、何が変わったか」も記録します。

変更履歴が残っていれば、障害や想定外の挙動が発生した際に、その前後でどの設定が変わったのかを確認できます。操作履歴と照らし合わせれば、変更が行われた経緯も追いやすくなります。

OS・ミドルウェアの設定

EC2を利用している場合は、インスタンス内部も構成管理の対象です。OSの設定、インストール済みのソフトウェア、稼働中のサービスなども把握しておきます。

AWSリソースの設定と、EC2内部のOS・ソフトウェアでは管理する情報が異なります。両者を分けて管理すると、どこに変更や問題が生じたのかを切り分けやすくなります。

AWSの構成管理に使える主なサービス・手法

AWSの構成管理では、目的に応じて複数のサービスや手法を使い分けます。代表的なのは、AWS Config、AWS CloudFormation、AWS Systems Managerです。

AWS Config｜構成と変更履歴を記録する

AWS Configは、対応するAWSリソースの構成を記録し、変更履歴を確認できるサービスです。

セキュリティグループの設定がいつ変更されたか、EC2インスタンスの構成がどのように変化したかなどを追跡できます。AWS Config Rulesを利用すると、各リソースがあらかじめ定めたルールに準拠しているかも評価でき、設定上の問題を検知する用途にも使えます。

AWS CloudFormation｜構成をコードで管理する

AWS CloudFormationは、AWSリソースの構成をテンプレートで定義し、インフラストラクチャをコードとして管理するサービスです。

同じテンプレートから環境を構築できるため、手作業による設定のばらつきを抑えられます。テンプレートをGitなどで管理すれば、変更履歴をコードとして残し、レビューを経て反映する流れもつくれます。

AWS Configが実環境の状態や変化を追うのに対し、CloudFormationは、あるべき構成をコードで定義し、再現するために使います。

AWS Systems Manager｜OS・ソフトウェアの状態を管理する

AWS Systems Managerは、EC2などのマネージドノードを管理するためのサービスです。OSやインストール済みソフトウェアなど、サーバー内部の構成管理にも利用できます。

Systems Manager Inventoryでは、アプリケーションやサービスなどの情報を収集できます。State Managerでは、マネージドノードなどを定めた状態に維持し、構成のずれを抑える運用ができます。

AWS構成管理を継続的に運用する進め方

AWSの構成は運用中も変化します。管理対象と基準を決め、現状を把握し、変更後のずれまで確認できる流れを整えます。

1. 管理対象とあるべき構成を決める

まず、構成管理の対象と、維持したい状態を決めます。すべてを同じ粒度で管理するのではなく、セキュリティや可用性への影響が大きいリソースから優先すると進めやすくなります。

たとえば、セキュリティグループの許可範囲や暗号化の有無などを基準として定めます。AWS Config RulesやConformance Packsを利用すれば、その基準に各リソースが準拠しているかを評価できます。

2. 現在の構成と変更経路を可視化する

次に、実際に稼働しているリソースと設定を確認します。設計書が残っていても、現在の環境と一致しているとは限りません。

あわせて、AWS Management Console、CLI、IaC、運用ツールなど、どこから変更が行われているかも整理します。構成の変化と操作履歴を照らし合わせられるようにしておくと、変更の経緯を追いやすくなります。

3. IaCで構成を標準化・再現可能にする

手作業で管理している構成は、AWS CloudFormationなどのIaCへ段階的に移行します。

Gitなどでコードを管理し、レビューを経て変更する流れを整えれば、設定方法のばらつきを抑えながら、同じ構成を再現できます。

最初からすべてをIaC化する必要はありません。変更頻度が高いリソースや、設定ミスの影響が大きい部分から対象を広げる方が現実的です。

CloudFormationなどを使った開発環境の構成管理については、以下の記事でも紹介しています。

>> AWS開発環境構築ガイド｜サービス選定からセキュリティ・コストまで解説

4. 意図しない変更や設定差分を検知する

IaCを導入しても、AWS Management Consoleなどから直接変更されれば、コードで定義した内容と実際の環境にずれが生じます。

CloudFormationのドリフト検出では、対応するリソースについて、テンプレートやパラメータで明示した設定と実際の構成との差を確認できます。AWS Config Rulesを利用すれば、あらかじめ定めた基準から外れた設定も把握できます。 

5. 検知した差分を評価し、改善につなげる

差分を検知したら、まず変更の意図を確認します。必要な変更であればIaC側へ反映し、誤った変更であれば実環境を元の状態へ戻します。

定型的なルール違反は、AWS Configの修復アクションを使って自動化する方法もあります。一方、影響範囲が大きい変更は人が確認するなど、対象に応じて対応を分けます。

さらに、なぜ差分が生じたのかを確認し、必要に応じて変更手順や管理ルールを見直します。同じ問題を繰り返さないところまでを構成管理の運用に含めます。

AWS環境全体を点検し、構成や運用の改善につなげる方法は、下記記事で詳しく解説しています。

>> AWS環境診断で何がわかる？確認項目と改善の進め方

AWS構成管理を定着させる3つのポイント

構成管理を組織の運用として定着させるには、変更時のルールや情報の参照先を明確にしておく必要があります。複数の担当者やAWSアカウントが関わる場合は、個別の判断に任せず、共通の運用方法を決めておきます。

1. 変更経路と例外時のルールを決める

構成変更をIaC経由に統一していても、障害対応などでAWS Management Consoleから直接変更する場面はあります。

そのため、「通常はどの経路から変更するか」「直接変更した場合は誰が確認し、どのようにIaCへ反映するか」まで決めておきます。例外時の扱いもルール化しておけば、実環境と管理しているコードのずれを放置しにくくなります。

2. 構成情報・変更履歴の参照先を決める

設計書、管理表、担当者のメモなどに構成情報が分散すると、どれが最新なのか判断しにくくなります。

AWS Configでリソースの構成や変更履歴を確認し、CloudTrailで操作履歴を追うなど、情報の種類ごとに参照先を決めておきます。CloudTrailのイベント履歴では、各AWSリージョンで直近90日間の管理イベントを確認できます。より長期間記録する場合は、証跡（trail）やCloudTrail Lakeのイベントデータストアを利用します。 

3. 複数アカウントに共通ルールを適用する

AWSアカウントが増えると、アカウントごとに構成管理の方法や基準がばらつきやすくなります。

AWS Configのアグリゲーターを使えば、複数のAWSアカウントやリージョンの構成情報、コンプライアンスデータを集約できます。AWS OrganizationsとConformance Packsを組み合わせ、共通のAWS Config Rulesを複数アカウントへ展開する方法もあります。

アカウントごとに個別対応するのではなく、組織全体で共通の基準を適用できる形にしておくと、環境が拡大しても管理のばらつきを抑えられます。

まとめ

AWSの構成管理では、AWS Config、AWS CloudFormation、AWS Systems Managerなどを目的に応じて使い分け、構成や変更を継続的に把握できる状態を整えます。

あわせて、管理基準や変更経路、情報の参照先を決めておくことで、担当者やアカウントごとの運用のばらつきを抑えられます。

最初からすべてを管理対象にするのではなく、セキュリティや可用性への影響が大きいリソースから始め、段階的に対象を広げていくとよいでしょう。