スキップしてコンテンツを表示

Workload Discovery on AWSにてCloudformationから一覧スタックを削除後、残ってしまうリソースについての課金対象の有無、また削除方法。

0

Workload Discovery on AWSにてCloudformationから一連のスタックを作成し、その後削除した際、いくつかのAWSリソース(S3など)が残ることを確認しております。これは動作として正しいでしょうか? 削除した後に残るAWSリソースは課金対象となり、残ったS3にデータが増え続ける懸念はございますでしょうか。 また、もしこれが動作として正しい場合、Workload Discovery on AWSで作成されたAWSリソースを完全に削除する方法はございますでしょうか。 現在はそれと思われる残ったリソースは削除しておりますが、再現させて問題となるARN等をご連絡させて頂く事も可能です。

質問済み 5ヶ月前118ビュー

1回答
0

残っているリソースにもよると思いますが、S3の場合はデータがバケット内に残っていなければ請求は発生しません。
以下のドキュメントを見る限りだとCloudFormationを削除した後にS3にデータが増え続けるといったこともないので、使用しなくなったらS3ごと削除してしまえば問題ないと思います。
https://aws.amazon.com/jp/solutions/implementations/workload-discovery-on-aws/
https://docs.aws.amazon.com/solutions/latest/workload-discovery-on-aws/solution-overview.html

エキスパート

回答済み 5ヶ月前

  • ご回答頂きありがとうございました。頂いたご回答は理解できました。 また背景等不足しており失礼致しました。以下、背景と質問になります。

    背景: 現在AWS関連のプロジェクトで弊社お客様のAWS環境を構築しております。既にある程度の構成が出来上がっており、 そこに弊社が追加で設計、構築を行っております。現状の構成が比較的複雑であるため現構成をWorkload Discovery on AWS を使って全体の構成を洗い出す必要がございます。 そこで貴社からご提供頂いている弊社AWSアカウント上で、事前にWorkload Discovery on AWSを構成し、その後削除したところ、 Workload Discovery on AWSで削除したはずのAWSリソース(CloudFormationスタック)がいくつか残り続けておりました。 例えばS3バケットや、Lambdaファンクションが削除されず残り続けておりました。 弊社検証環境では間違って削除しても問題ないのですが、これをお客様環境で実施した場合、Workload Discovery on AWSを構築し、 その削除したとき、残ってはいけないAWSリソースが存在することが考えられます。またWorkload Discovery on AWSを構成する際、 非常に多くのAWSリソースが作成されるため、削除した後に残存するAWSリソースがどれになるのかわからなくなったり、 不要なAWSリソースが残ってしまう為、結果お客様のAWS環境を汚してしまう可能性がございます。

    質問: Workload Discovery on AWSにてCloudFormationから一連のスタックを作成し、その後削除した際、いくつかのAWSリソース(S3など)が残ることを確認しております。これは動作として正しいでしょうか? またWorkload Discovery on AWSで作成されたAWSリソースを完全に削除する方法はございますでしょうか。


  • 以下のドキュメントの手順に記載されていますが、Workload Discovery on AWSを削除する前にECSタスクは停止されましたでしょうか? ECSタスクが残っていると削除が失敗することがあるようです。 https://docs.aws.amazon.com/ja_jp/solutions/latest/workload-discovery-on-aws/uninstall-the-solution.html
    以下のGitHubのソースコード (展開されるCloudFormation) を確認しましたが、CloudFormationを削除するとS3内のデータを削除するためのLambdaが動いてからS3の削除などが走るようなので、動きとしては全て削除されるが正になると思います。 https://github.com/aws-solutions/workload-discovery-on-aws/blob/main/source/cfn/templates/buckets.template
    ちなみに回答とはずれてしまうのですが、ドキュメントでは専用のAWSアカウントにデプロイすることを推奨しています。 今回のように既存のアカウントにデプロイすると多数のリソースによってアカウント内が汚れてしまうことが想定されるための推奨事項だと考えられます。 https://docs.aws.amazon.com/ja_jp/solutions/latest/workload-discovery-on-aws/choosing-the-deployment-account.html

    AWS Organizations を使用していない場合は、このソリューションのために作成された専用の AWS アカウントに AWS でのワークロード検出をデプロイすることをお勧めします。このアプローチにより、AWS でのワークロード検出は既存のワークロードから分離され、ユーザーの追加や新しい AWS リージョンのインポートなど、このソリューションを設定するための単一の場所を提供します。また、このソリューションの実行中に発生したコストを追跡しやすくなります。 AWS でのワークロード検出ソリューションがデプロイされると、プロビジョニング済みのアカウントから AWS リージョンをインポートできるようになります。

  • 以下のドキュメントの手順に記載されていますが、Workload Discovery on AWSを削除する前にECSタスクは停止されましたでしょうか? ECSタスクが残っていると削除が失敗することがあるようです。 https://docs.aws.amazon.com/ja_jp/solutions/latest/workload-discovery-on-aws/uninstall-the-solution.html

    ご教示ありがとうございます。確認させて頂きます。

    ちなみに回答とはずれてしまうのですが、ドキュメントでは専用のAWSアカウントにデプロイすることを推奨しています。 今回のように既存のアカウントにデプロイすると多数のリソースによってアカウント内が汚れてしまうことが想定されるための推奨事項だと考えられます。 >https://docs.aws.amazon.com/ja_jp/solutions/latest/workload-discovery-on-aws/choosing-the-deployment-account.html

    ありがとうございます。対象の環境はOrganization配下のAWSアカウントである事と、環境を分離するために外部のAWSアカウントから参照する要件はセキュリティ上 許可されていない為、対象のAWSアカウント環境内で実施する必要がございます。

    まずは再度、先に頂いた内容を検証環境で確認させて頂きます。 ありがとうございます。

ログインしていません。 ログイン 回答を投稿する。

優れた回答とは、質問に明確に答え、建設的なフィードバックを提供し、質問者の専門分野におけるスキルの向上を促すものです。

関連するコンテンツ