こんにちは！ カスタマーサクセス部CS5課で研修中の濱田です。
ところで皆さん、引越しの際には、Amazonの住所変更は確実に済ませておきましょう。高速道路に乗って前の家にポツンと置かれた置き配を取りに行くのは、あまり愉快なドライブとは言えません。
さて、マルチアカウント・マルチリージョンでAWS Config（以下Config）を有効化するとともに、Configルールも作成する機会がありました。このような場合、AWS CloudFormation StackSets を用いて、Configの有効化とConfigルール作成を同時に行うことが考えられるでしょう。
この時検証・構築時に出会ったエラーと、それに対するトラブルシューティングを共有します。どなたかのお役に立ちますように！
本記事の概要
AWS CloudFormation でConfigルールを作成する際は依存関係に注意しましょう。
レコーダーの作成とデリバリーチャネルの作成以前にConfigルールを作成しようとするとエラーになってしまいます。
テンプレートの概要
Configを有効化し、Configルールを作成するスタックを以下のように作成しました。 ここでは簡単のため、Resources部分のみを記載します。[...]の部分は中略を示します。
Resources: ConfigRecorderRolePolicy: Type: AWS::IAM::ManagedPolicy Properties: # [...] ConfigRecorderRole: Type: AWS::IAM::Role Properties: # [...] ConfigRecorder: Type: AWS::Config::ConfigurationRecorder Properties: # [...] ConfigDeliveryChannel: Type: AWS::Config::DeliveryChannel Properties: # [...] RequiredTagsConfigRule: Type: AWS::Config::ConfigRule Properties: # [...]
ここでは計5つのリソースが作成されています。
Configを有効化する際に必要な①Configレコーダー、②デリバリーチャンネル、そして③Configルールを作成しています。
Configレコーダーのために、Configレコーダーが引き受ける④IAMロールと、その中身となる⑤IAMポリシーも作成していますね。 基本的な構成かと思います。
出会ったエラー
本題です。
検証を複数回繰り返す中で、偶発的に出会ったエラーがありました。 複数アカウント・複数リージョンにスタックを流していたのですが、どうしたわけか、大阪リージョンに流れているスタックにのみ、エラーが発生してしまいました。
だけど、大阪リージョンには特に障害等は発生しておらず……。
エラーコードは次のようなものでした。[...]は中略を示します。
Resource handler returned message: "Invalid request provided: NoAvailableConfigurationRecord" (RequestToken: [...], HandlerErrorCode: InvalidRequest)
んんん？ 「有効な設定レコードがない」状態でリクエストを行ったことで、不正なリクエストとしてエラーが発生しているようです。どういうことでしょうか。
エラーについての結論
結論からお伝えします。検証した限りでは、「Configレコーダーがない＝設定が記録されていない」状態でConfigルールを作ろうとすることが問題だった可能性が高いです。
要するに、Configの有効化よりも先にConfigルールを作成しようとすると、エラーになってしまうようです。
行った検証
もちろん、ConfigルールはConfigが収集した情報を基に動作するため、一見このエラーは当たり前のように見えると思います。 しかし、ドキュメントに前提条件として明示的に記載があるわけではないように思います。
実際、意外とConfigそのものとConfigルールの関係は独立しているようにも見える場合もあります。例えばConfigを有効化→Configルールを作成→Configを無効化→その後再び有効化、というプロセスを試すと、Config無効化の後にもConfigルールは残存していたりしますから……。
この点を明らかにするべく、次のような検証を行いました。
あえてConfigの有効化よりも先にConfigルールを作成するテンプレートを実行してみる
仮に、リソースの作成順が問題なのだとすれば、「Configの有効化よりも先にConfigルールを作成する」テンプレートを実行するとエラーになるはずです。あえてこのエラーを狙って依存関係を設定してみましょう。
つまり、こうです。
Resources: ConfigRecorderRolePolicy: Type: AWS::IAM::ManagedPolicy Properties: # [...] ConfigRecorderRole: Type: AWS::IAM::Role # [...] ConfigRecorder: Type: AWS::Config::ConfigurationRecorder Properties: # [...] DependsOn : RequiredTagsConfigRule #←ここを追加しています！ ConfigDeliveryChannel: Type: AWS::Config::DeliveryChannel Properties: # [...] DependsOn : RequiredTagsConfigRule #←ここを追加しています！ RequiredTagsConfigRule: Type: AWS::Config::ConfigRule Properties: # [...]
ConfigRecorderとConfigDeliveryChannelという、Configを有効化される際に作成する2つのリソースに対して、「RequiredTagsConfigRuleに依存せよ」とDependsOn属性をつけています。つまり、RequiredTagsConfigRuleの後にConfigRecorderとConfigDeliveryChannelを作れ、と指示しています。
スタックを「test-invalidrequest」と名付けて、いざ実行！ エラーよ来い！
来ました。やはりエラーは次のとおりです。
Resource handler returned message: "Invalid request provided: NoAvailableConfigurationRecord" (RequestToken: [...], HandlerErrorCode: InvalidRequest)
Configルールを後に作成するテンプレートを実行してみる
では、依存関係を逆にするとどうなるでしょうか。つまりこうです。
Resources: ConfigRecorderRolePolicy: Type: AWS::IAM::ManagedPolicy Properties: # [...] ConfigRecorderRole: Type: AWS::IAM::Role Properties: # [...] ConfigRecorder: Type: AWS::Config::ConfigurationRecorder Properties: # [...] ConfigDeliveryChannel: Type: AWS::Config::DeliveryChannel Properties: # [...] RequiredTagsConfigRule: Type: AWS::Config::ConfigRule Properties: # [...] DependsOn : - ConfigRecorder #←ここが変更点です！ - ConfigDeliveryChannel #←ここが変更点です！
スタックを「test-double-dependency」と名付けて、いざ実行！
来ました！ 5つのリソースが全てCREATE _COMPLETEしています。
システムオールグリーンです！（新世紀エヴァンゲリオン）
結果の検討
以上の結果からは、ConfigルールをConfigRecorderおよびConfigDeliveryChannelの以前に作成しようとするとエラーが発生することが示唆されます。
問題の原因、そしてその解決法が完全に特定できているわけではなく、あくまで状況証拠からの推論にはなりますが、次のように結論づけておきましょう。
レコーダーあるいはデリバリーチャネルの作成以前にConfigルールを作成するとエラーになる。 そしてそれを回避するために「レコーダーの作成とデリバリーチャネルの作成の後にConfigルールを作成するよう明示的に指示を行う」という解決策がありうる。
なぜこのエラーは起こったのか？
次のような仮説を立てています。
このエラーはそもそも、複数回の検証の中で一度しか起こらないものでした。
だから、エラーの原因は、CloudFormationのリソース作成の実行順が必ずしも順次に行われるものではないからなく、稀なケースとしてConfigルールが先に作られるという挙動をしたから、なのかもしれません。
おわりに
私と同じように、偶発的に見えるエラーで困っている方は、もしかしたらリソースの作成順に問題があるかもしれません。
あくまで状況証拠による推論とはなりましたが、同様のエラーに困っている方のヒントになれば幸いです！
それでは、またお会いしましょう。
濱田 明日郎(執筆記事の一覧)
アプリケーションサービス本部ディベロップメントサービス2課
ベルクソン哲学研究で博士号取得ののち、2024年にサーバーワークスに新卒入社。
2025 Japan All AWS Certifications Engineers
奄美大島出身。
