Amazon WorkSpaces Cost Optimizerの実装に詰まった話
こんにちは、Shunです。
今回は、Amazon WorkSpaces Cost Optimizerのデプロイ中に直面した課題とその解決策について、簡潔にご紹介します。
このソリューションは、Amazon WorkSpaces のすべての使用状況データを分析し、個々の使用状況に応じて、WorkSpace を最も費用対効果の高い課金オプション (時間単位または月単位) に自動的に変換します。本ソリューションは、単一のアカウントで使用することも、複数のアカウントにまたがる AWS Organizations で使用することもでき、WorkSpace の使用状況をモニタリングしてコストを最適化するのに役立ちます。
詰まった箇所
私はAmazon WorkSpaces Cost Optimizerの検証を行うために、AWS ソリューションライブラリ内の「実装ガイド」を基にデプロイを進めていました。
しかし、Amazon WorkSpaces Cost OptimizerのCloudFormationテンプレートをデプロイしようとした際、以下のエラーメッセージに直面しました。
この問題は、実装ガイドに記載されたダウンロードリンクからテンプレートを取得して使用したにも関わらず発生しました。エラーメッセージを精査したところ、次のような内容でした。
Resource handler returned message: "Bucket cannot have ACLs set with ObjectOwnership's BucketOwnerEnforced setting
つまり、「ObjectOwnership
のBucketOwnerEnforced
設定を使用している場合、ACLを設定することはできません」という意味です。2023年4月から、ACLはデフォルトで無効化され、BucketOwnerEnforcedがデフォルト設定となりました。
Amazon S3 が新規バケットすべてに 2 つのセキュリティベストプラクティスをデフォルトで適用開始
解決策
この問題を解決するため、AWSのre:Postを参照し、ACLを有効にする場合は所有者をObjectWriter
に設定する必要があることを知りました。
CloudFormationの「バケットは ObjectOwnership の BucketOwnerEnforced 設定で ACL を設定できません」というエラーを修正する方法を教えてください。
CloudFormationテンプレートに以下のハイライトしている箇所を追加することで、問題は解決しました。
LogsBucket: DeletionPolicy: Retain Type: AWS::S3::Bucket Metadata: cfn_nag: rules_to_suppress: - id: W35 reason: Access logging is not required for this bucket. - id: W51 reason: Policy is not required for this bucket. Properties: PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true AccessControl: LogDeliveryWrite OwnershipControls: Rules: - ObjectOwnership: ObjectWriter BucketEncryption: ServerSideEncryptionConfiguration: - ServerSideEncryptionByDefault: SSEAlgorithm: AES256 Tags: - Key: !FindInMap [Solution, Data, "TagKey"] Value: !Ref "AWS::StackName"
根本的な解決策
改めて、「実装ガイド」を見てみると、最終更新日:2022年8月!!
実装ガイドp15からダウンロードしたテンプレートも古いのでは!?
ダウンロードしたテンプレートを見てみると、“version v2.5.1”と古いものでした。
最新版テンプレートは、以下の「CloudFormationテンプレート」からダウンロードが必要でした。
上記からダウンロードしたCloudFormationテンプレートは、ACLではなく、バケットポリシーでアクセス制御がされていました。
AWSがセキュリティのベストプラクティスとして、ACLをデフォルト無効としているのに、AWSのテンプレートがそれで構成されているはずはありませんでした。。
まとめ
CloudFormationのエラーで悩んでましたが、もっと根本的な部分に原因がありました。
ちゃんと最終更新日やバージョンを確認することは大切ですね。。
最近、読んだ世界一流エンジニアの思考法で、「手を動かす前にエラーの仮説を立てる」のようなニュアンスの教訓があったな。と思い出しました。
CloudFormationのエラーが出た際に、非推奨事項であるACLのエラーだったことから、バージョンを疑うなどもできたような気がします。。
この記事が誰かの助けになれば幸いです!
最後まで読んでいただきありがとうございました!
テックブログ新着情報のほか、AWSやGoogle Cloudに関するお役立ち情報を配信中!
Follow @twitterGoogle Cloud11冠、2024 AWS All Cert、ビール検定1冠
Recommends
こちらもおすすめ
-
CloudFormationで認証情報を扱うベストプラクティス
2020.8.7
Special Topics
注目記事はこちら
データ分析入門
これから始めるBigQuery基礎知識
2024.02.28
AWSの料金が 10 %割引になる!
『AWSの請求代行リセールサービス』
2024.07.16