search

mlevit / aws-auto-cleanup

Programmatically delete AWS resources based on an allowlist and time to live (TTL) settings
MIT License
496 stars 55 forks source link

Send email notification with exec log report attached 3 days before the actual cleanup takes place #87

Closed atqhg23 closed 2 years ago

atqhg23 commented 2 years ago

Is your feature request related to a problem? Please describe.

Yes, the problem is that when dry-run is off, you do not know what actions the cleanup will take until it actually runs. Currently, dry-run mode can be turned on to view the execution log, but I would like to keep dry-run off, and also generate a report prior to the cleanup taking place. The goal is to allow for some time to review the execution log and determine what needs to be whitelisted before the cleanup destroys the resources without needing to manually change the dry-run mode.

Describe the solution you'd like

When the cleanup is running in destroy mode, it first runs in dry-run mode to generate the execution log, and then X number of days later, it will run in destroy mode.

When the execution log is generated by the first run, it is placed in the “dry-run” folder, and an S3 event notification is triggered based on the object creation that sends the report in an email to the address specified.

You now have X days to review the execution log and see what resources need to be added to the whitelist, before the cleanup runs in destroy mode and the execution log is placed in the “destroy” folder and another email notification is sent with the post-cleanup execution log.

I may be overthinking this, and there may be a simpler approach, but I’m open to any ideas to address this without having to manually switch the dry-run toggle and send an email notification with the pre-cleanup and post-cleanup execution log.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Not sure of other alternatives, but the goal is to add a buffer between when the execution log is generated and when the cleanup actually runs so that there is some time to review the execution log prior to the cleanup destroying any resources while keeping dry-run off.

Additional context

Example logic below:

Dry-run is off

  1. Cleanup runs in dry-run mode to generate execution log.
  2. The execution log is added to the S3 bucket in the “dry-run” folder and event is triggered that emails the report.
  3. Cleanup runs again in 3 days (configurable) in destroy mode, places the execution log in the “destroy” folder, and emails the report.

Dry-run on

  1. Cleanup runs in dry-run mode to generate execution log.
  2. The execution log is added to the S3 bucket in the “dry-run” folder and an event is triggered that emails the report.
  3. Cleanup runs again in 3 days (configurable) in dry-run mode, places the execution log in the “dry-run” folder and emails the report.
mlevit commented 2 years ago

@mcueva10 I do understand where you're coming from but this is not something I'm willing to implement as I don't believe it adds the right level of value.

The tool was aimed to be used organisation-wide where all employees could pre-emptively whitelist their resources. The execution log is not meant to be a reminder of resources that will be destroyed, rather than actions taken.

Dry run mode is there for you to use the very first time and give you ample time to whitelist whatever resources you need to. Think of the tool as a set and forget. If you forget to whitelist your resource, you lose it.

atqhg23 commented 2 years ago

I see, thanks for your input