Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Nuke – delete all resources associated with AWS account

github.com

Post reply on HN
Print view View original

51–60 of 124 posts

Re: AWS Nuke – delete all resources associated with AWS account

#51

Post by thematrixturtle »

tpmx wrote: post #50

I noticed that this GCP article about Terraform best practices linked to a similar tool: cloud-nuke ( https://github.com/gruntwork-io/cloud-nuke ) https://cloud.google.com/docs/terraform/best-practices-for-t... > After you run the terraform destroy command, also run additional clean-up procedures to remove any resources that Terraform failed to destroy. Do this by deleting any projects used for test execution or by u…

In GCP, the tool is not necessary, because you can simply delete the containing project to "nuke" any resources attached to it.

Re: AWS Nuke – delete all resources associated with AWS account

#52

Post by [deleted] »

thematrixturtle wrote: post #51
tpmx wrote: post #50

I noticed that this GCP article about Terraform best practices linked to a similar tool: cloud-nuke ( https://github.com/gruntwork-io/cloud-nuke ) https://cloud.google.com/docs/terraform/best-practices-for-t... > After you run the terraform destroy command, also run additional clean-up procedures to remove any resources that Terraform failed to destroy. Do this by deleting any projects used for test execution or by u…

In GCP, the tool is not necessary, because you can simply delete the containing project to "nuke" any resources attached to it.

[deleted]

Re: AWS Nuke – delete all resources associated with AWS account

#53

Post by jiggawatts »

orf wrote: post #48
jiggawatts wrote: post #47

Earlier quoted context omitted.

This is because neither AWS nor Azure use referential integrity in any of their "cloud scale" databases. For example, Azure uses some hideous JavaScript-based document DB where things like renames, moves, and deletes are hit & miss at best. A never-ending whack-a-mole of bugs and issues. Remember boys and girls: Being "cloud scale" means data corruption and referential integrity violation!

I don’t think it is - the issue is that the Batch service needs to assume your role in order to clean up associated cluster resources like auto scaling groups. If the role is deleted, it can’t do this.

That's what referential integrity violation means: an essential related piece of information can be deleted without the parent/using object also being deleted.

Re: AWS Nuke – delete all resources associated with AWS account

#54

Post by crazysim »

evanfarrar wrote: post #8

https://github.com/genevieve/leftovers A co-worker made this when we worked together on a project that ran a large number of terraform configurations in CI against real IaaSes. Each account was a sandbox, so we would run this at the end of a pipeline to clean up any failures or faulty teardowns.

Unlike aws-nuke, there seem to be actual automated tests here for this tool. That's really neat!

Though, I do feel the project reaches out to quite a lot of IAAS's for its level of current maintenance, which seems to be somewhat zero.

aws-nukes gets contributions here and there and maybe that's because it's quite focused.

That's a real shame, the implementations for each provider look to be great, standalone by themselves.

Re: AWS Nuke – delete all resources associated with AWS account

#55

Post by wongarsu »

janstice wrote: post #39
Aeolun wrote: post #35

Earlier quoted context omitted.

It seems to me this cannot possibly be a hard limit. If it’s a hard limit it’s only because AWS wants to milk you dry.

I suspect it’s a hard limit to prevent disgruntled (former) admin blast radius.

If that was the concern then surely they could enable support to restore accounts during some grace period. The machinery for that already exists for people who completely close their AWS accounts down.

Maybe it was quicker to implement with a hard limit, or there is some internal service that can't easily handle large volumes of account removals. But if it was Amazon losing money from this limitation instead of the customer I imagine it would be fixed pretty quickly.

Re: AWS Nuke – delete all resources associated with AWS account

#56

Post by orf »

jiggawatts wrote: post #53
orf wrote: post #48

Earlier quoted context omitted.

I don’t think it is - the issue is that the Batch service needs to assume your role in order to clean up associated cluster resources like auto scaling groups. If the role is deleted, it can’t do this.

That's what referential integrity violation means: an essential related piece of information can be deleted without the parent/using object also being deleted.

Sure, in an abstract sense maybe, but in a cross-service context it’s got nothing to do with their “cloud scale databases”.

In fact, being able to delete a role without removing any associated resources is a feature, not a bug. And how would you even ensure referential integrity in this case - you would achieve the same effect by modifying the assume role policy but keeping the role around.

You could craft a policy that only allows Batch to assume the role on a Tuesday for example.

Re: AWS Nuke – delete all resources associated with AWS account

#57

Post by efxhoy »

jiggawatts wrote: post #47
orf wrote: post #11

Shout out to AWS batch, where if you delete the role assigned to a compute cluster the cluster itself becomes impossible to delete. Found this out after using AWS nuke

This is because neither AWS nor Azure use referential integrity in any of their "cloud scale" databases. For example, Azure uses some hideous JavaScript-based document DB where things like renames, moves, and deletes are hit & miss at best. A never-ending whack-a-mole of bugs and issues. Remember boys and girls: Being "cloud scale" means data corruption and referential integrity violation!

Not even redshift enforces uniqueness on their primary keys or referential integrity on their foreign keys. That was a fun finding out…

Re: AWS Nuke – delete all resources associated with AWS account

#58

Post by Frajedo »

vageli wrote: post #40
Frajedo wrote: post #38

Earlier quoted context omitted.

We give each one of our developers their very own aws account managed through AWS organizations service. They are full administrators and responsible for resources and cost. So far we haven’t had any issues or bad surprises, although we have setup some aws billing alerts just in case. Feel free to make them responsible for cost and resources and you’ll be surprised how well they can manage their own account.

> We give each one of our developers their very own aws account managed through AWS organizations service. They are full administrators and responsible for resources and cost. How many developers work at your organization?

25 at the moment :)

Re: AWS Nuke – delete all resources associated with AWS account

#59

Post by tpmx »

thematrixturtle wrote: post #51
tpmx wrote: post #50

I noticed that this GCP article about Terraform best practices linked to a similar tool: cloud-nuke ( https://github.com/gruntwork-io/cloud-nuke ) https://cloud.google.com/docs/terraform/best-practices-for-t... > After you run the terraform destroy command, also run additional clean-up procedures to remove any resources that Terraform failed to destroy. Do this by deleting any projects used for test execution or by u…

In GCP, the tool is not necessary, because you can simply delete the containing project to "nuke" any resources attached to it.

There is a 30 day "marked for deletion period" after you do this. The resources related to the project aren't immediately nuked.

https://cloud.google.com/resource-manager/docs/creating-mana...

Re: AWS Nuke – delete all resources associated with AWS account

#60

Post by Frajedo »

cure wrote: post #41
Frajedo wrote: post #38

Earlier quoted context omitted.

We give each one of our developers their very own aws account managed through AWS organizations service. They are full administrators and responsible for resources and cost. So far we haven’t had any issues or bad surprises, although we have setup some aws billing alerts just in case. Feel free to make them responsible for cost and resources and you’ll be surprised how well they can manage their own account.

> although we have setup some aws billing alerts just in case. My experience with these has been decidedly mixed. As in, you define them and never, ever see an alert.

Hmmm, weird.

We always get the alerts in time with thresholds set to 70% of the wished value.

Post reply on HN