エムオーテックス株式会社が運営するテックブログです。

採用情報

定額制の落とし穴 ~AWS Configの定期的な記録を設定する前に、変更回数を確認しよう!~

AWS コスト削減

定額制の落とし穴 ~AWS Configの定期的な記録を設定する前に、変更回数を確認しよう!~

はじめに

こんにちは、SREチームの植松です。
2023年のアップデートにより、AWS Configのリソース設定変更を常時記録から1日1回の定期記録に変えられるようになりました。
SREチームでもこの設定変更を適用しましたが、逆にコストが上がってしまう場合がありました。皆様への気づきとなればと思い、本記事では原因と対策を共有します。

aws.amazon.com

AWS Configの定期記録

「はじめに」のリンクの通り、2023年のアップデートでAWS Config(以下、Config)の定期記録が可能になっています。
定期記録を設定すると24時間に1回、AWSリソースの設定変更を取り込むようになるため、記録される設定変更量と、変更記録にかかるコストを削減することができます。
セキュリティ・運用面の観点として下記に示す理由で定期記録にして問題ないと判断しました。

  • ものによっては1リソースあたり1日数百~数千検知される場合があり、莫大な設定変更量であること
  • それらの設定変更は基本的には、サービスのスケーリングに伴う想定通りの変更であること
  • Security Hubを有効化しており、想定外の設定変更を検知、対処していること

Control Tower環境での定期記録

アップデート直後はConfigの定期記録はControl Tower環境では設定できませんでした。(アップデート直後、AWSサポートに確認済み)
LANSCOPE EMクラウド版の開発、運用に関わるAWSアカウント群はControl Towerで管理しているため、今後の更なるアップデートに期待しつつConfig定期記録対応は保留していました。
その後、偶然AWS公式ブログの記事を見ていたところControl Tower環境下でも設定できるようになっているのではと気づき、設定変更対応を進めました。

aws.amazon.com

詳細な手順は公式ブログに記載がありますが、大きく以下の手順でControl Tower環境でのConfig定期記録は可能です。

  1. 設定ファイルのCloneまたはダウンロード
    github.com

  2. CloudFormationスタックの作成

    • Control Towerのホームリージョンに管理アカウントでCloudFormationスタックを作成します。

  3. パラメータの設定:

    • ConfigRecorderExcludedResourceTypes: トラッキングから除外するAWS Configリソースタイプのリストを指定します（カンマ区切り）。
    • ExcludedAccounts: 変更を適用しないAWSアカウントのリストを指定します（ログアーカイブや監査アカウントのIDなど）。
    • ConfigRecorderDailyResourceTypes: 連続記録ではなく、1日1回の記録に設定するAWS Configリソースタイプのリストを指定します（カンマ区切り）。
    • ConfigRecorderDefaultRecordingFrequency: 記録頻度を連続または1日1回に変更します。
    • CloudFormationVersion: 既存のスタックを更新する場合は、バージョン番号を上げます。

  4. スタックの作成

    • パラメータを指定した後、スタックを作成し、デプロイが完了するのを待ちます。

エムオーテックスでは本番環境用、ステージング環境用、開発環境用の3つのテンプレートを作成し、デプロイしました。

定期記録設定後の経過観察

11/11日に定期記録の設定変更を実施し、コストの経過観察を行いました。本番環境は狙い通りコストが最適化されていました。

本番環境のConfig定期記録コスト(縦軸：コスト、横軸：日付　具体的な値は割愛させていただきます)

ただ、本番環境を除いた各開発環境については、定期記録のコスト(ConfigurationItemRecordedDaily)が想定よりも増えており、設定変更前よりもコストが増えているような結果となりました。

開発環境のConfig定期記録のコスト(使用タイプでグループ化)

改めて東京リージョンのConfigのリソース変更記録料金を確認したところ、

  • 連続的な記録 USD 0.003
  • 定期的な記録 USD 0.012

であり、定期記録の方が4倍高額であることがわかります。

定期的な記録は、1リソースに対して1日に何回変更があったとしても定額($0.012)ですが、逆に、変更が4回未満の場合は連続的な記録の方がお得であるということがわかります。
コスト上昇を見るに開発環境については、各AWSリソースの変更回数は4回未満が多いだろうという予測が立ちましたが、実際にそうなっているかを確認することにしました。

料金 - AWS Config | AWS

Configのリソース変更回数の分析

分析用テーブル作成

以下の公式ドキュメントを参考に、Configの記録結果を確認するためのテーブルを作成します。

repost.aws

各AWSアカウントのConfigの記録結果は、Control Towerの導入時に自動的に作成されるLog ArchiveアカウントのS3バケットに集約されます。

公式ドキュメントのクエリを変更し、以下のようなテーブル定義をAthenaで実行します。

LOG_ARCHIVE_ACCOUNT_ID, ORGANIZATION_ID, projection.account_id.valuesのアカウントIDは適宜置き換えが必要です。

CREATE EXTERNAL TABLE `awsconfig`(
    `fileversion` string COMMENT 'from deserializer',
    `configsnapshotid` string COMMENT 'from deserializer',
    `configurationitems` array < struct < configurationitemversion :string,
    configurationitemcapturetime :string,
    configurationstateid :bigint,
    awsaccountid :string,
    configurationitemstatus :string,
    resourcetype :string,
    resourceid :string,
    resourcename :string,
    arn :string,
    awsregion :string,
    availabilityzone :string,
    configurationstatemd5hash :string,
    resourcecreationtime :string > > COMMENT 'from deserializer'
) PARTITIONED BY
    (
        `account_id` string
    ) ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3://aws-controltower-logs-LOG_ARCHIVE_ACCOUNT_ID-ap-northeast-1/ORGANIZATION_ID/AWSLogs' TBLPROPERTIES(
        'projection.account_id.type' = 'enum',
        'projection.account_id.values' = 'ACCOUNT_ID_1,ACCOUNT_ID_2,・・・・',
        'projection.enabled' = 'true',
        'storage.location.template' = 's3://aws-controltower-logs-LOG_ARCHIVE_ACCOUNT_ID-ap-northeast-1/ORGANIZATION_ID/AWSLogs/${account_id}/Config/ap-northeast-1/',
        'transient_lastDdlTime' = '1713148702'
    )

分析用クエリの実行

Athenaのクエリエディタで以下のようなクエリを実行しました。このクエリは、指定された期間内でリソースタイプとリソースIDごとに何回設定変更があったかを集計します。

SELECT
    account_id,
    configurationItem.resourceType,
    configurationItem.resourceId,
    COUNT(configurationItem.resourceId) AS NumberOfChanges
FROM
    default.awsconfig
    CROSS JOIN
        UNNEST(configurationitems) AS t(configurationItem)
WHERE
    "$path" LIKE '%ConfigHistory%'
AND configurationItem.configurationItemCaptureTime >= '2024-11-17T%'
AND configurationItem.configurationItemCaptureTime <= '2024-11-23T%'
GROUP BY
    account_id,
    configurationItem.resourceType,
    configurationItem.resourceId
ORDER BY
    NumberOfChanges DESC

正常に実行できた場合は以下のような結果が表示されます。

集計クエリの実行結果

QuickSightで変更回数を可視化

集計結果をCSVでダウンロードし、QuickSightに取り込みます。
複数ある開発環境(AWSアカウント)について、まとめてリソース変更回数のヒストグラムを出してみたところ、1週間以内の変更回数が1、2回程度のリソースが大多数を占めることがわかりました。

リソースタイプ別の分析

ある開発環境を1つピックアップし、リソースタイプごとの変更回数TOP 3をまとめたものが以下の表です。
1位のAWS::Config::ResourceComplianceについては、Security Hubによるチェックが各リソースに適用されたことが原因でした。
2位のAWS::Lambda::Functionについては、週次で行っているリソースへのタグ付け処理が設定変更とみなされたことが原因です。 LANSCOPE EMクラウドの運用においては多数のLambda関数を使用しているため、積もり積もってトータルの変更回数は多くなっています。
3位のAWS::CloudWatch::Alarmについては、各CloudWatchアラームの状態変更がカウントされています。
アラーム1つ1つの変更回数は少ないですが、Lambdaと同様に回数が多くなっています。

リソースタイプ 変更回数
AWS::Config::ResourceCompliance 2710
AWS::Lambda::Function 2255
AWS::CloudWatch::Alarm 1995

こちらの表は、1リソースあたりの変更回数が多いリソースタイプの変更回数です。
エムオーテックスでは開発環境のコスト最適化のため、業務時間外はEC2やRDSなどを停止する運用をしており、開発環境の開始、停止に伴う設定変更がカウントされています。

リソースタイプ 変更回数
AWS::AutoScaling::AutoScalingGroup 384
AWS::Elasticsearch::Domain 98
AWS::RDS::DBInstance 58

これらの情報から、変更回数が少ないリソースが大多数を占めること、変更回数が多いリソースは僅かであることがわかったので、開発環境については常時記録となるよう設定を戻しました。

おわりに

今回の記事では、AWS Configの定期記録設定について実例を交えてご紹介しました。
定期記録のメリットや注意点を具体的にお伝えしましたが、定期記録を設定する前にリソース変更回数の分析を行うことが重要だと思いました。
皆さんの環境でも同じような課題や改善点が見つかるかもしれませんので、ぜひ参考にしてみてください。
技術は日々進化しているので、最新情報をキャッチアップしながら柔軟に対応していくことが大切です。
これからも、皆さんの業務に役立つ情報をお届けしていきますので、ぜひご期待ください。
最後までお読みいただき、ありがとうございました！