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

61–70 of 124 posts

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

#61

Post by 101008 »

Frajedo wrote: post #38
arkadiyt wrote: post #37

99% of our AWS resources are terraformed, but developers constantly push back / want to use the console to create stuff to test or play around with. So we setup a separate "hack" AWS account and give them admin access in there, and have an automated job using AWS Nuke to delete everything in there once a quarter.

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.

> Feel free to make them responsible for cost and resources and you’ll be surprised how well they can manage their own account.

Wow, this is horrible. I understand responsability but this is too much. Are other employees responsible if the company loses money for their actions?

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

#62

Post by OJFord »

Marazan wrote: post #25
OJFord wrote: post #12

Earlier quoted context omitted.

That's a weird one, but surely an aws-nuke bug? It must already use a deliberate order - there's plenty of resources that need anything linked/constituent deleted first - so that order is/was just not correct for those?

No, Batch's interaction with IAM roles and permission is super weird and not at all documented. It is easy to screw it up.

What I mean is 'yes that's a weird interaction' but, if that's how the AWS service works (however weird) then it's an aws-nuke bug that the ordering isn't correct (to account for that weirdness)?

Though 'not at all documented' makes that harder of course. I haven't used it.

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

#63

Post by OJFord »

bilekas wrote: post #15
OJFord wrote: post #12

Earlier quoted context omitted.

That's a weird one, but surely an aws-nuke bug? It must already use a deliberate order - there's plenty of resources that need anything linked/constituent deleted first - so that order is/was just not correct for those?

Nah I've seen this too. It is considered an expected behavior. In a way it makes sense. But it's not well documented.

But that's what I mean, if that's how it works, nuke needs to account for it. I assume it already does for other dependencies, because there are a lot of them - including that do make more (obvious) sense.

You're not the only one to complain about the documentation though, so it's easy to see how aws-nuke apparently missed it!

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

#64

Post by imwillofficial »

101008 wrote: post #61
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.

> Feel free to make them responsible for cost and resources and you’ll be surprised how well they can manage their own account. Wow, this is horrible. I understand responsability but this is too much. Are other employees responsible if the company loses money for their actions?

Ever had a company credit card?

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

#65

Post by thematrixturtle »

tpmx wrote: post #59
thematrixturtle wrote: post #51

Earlier quoted context omitted.

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...

Deleting a project does immediately turn off (stop billing) the vast majority of associated resources, including VMs. The main exception is storage, but that cost is typically fairly marginal.

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

#66

Post by jftuga »

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.

This fork is 36 commits ahead. It aims to stabilize deletion (so far for AWS) and add extended regex filtering support.

https://github.com/notrepo05/leftovers

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

#67

Post by formerkrogemp »

efxhoy wrote: post #57
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!

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

> That was a fun finding out…

Not my idea of a good time, but whatever floats your boat. Hopefully you had a backup?

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

#68

Post by tpmx »

thematrixturtle wrote: post #65
tpmx wrote: post #59

Earlier quoted context omitted.

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...

Deleting a project does immediately turn off (stop billing) the vast majority of associated resources, including VMs. The main exception is storage, but that cost is typically fairly marginal.

Oh, ok. That seems fair and makes sense. (I wish that had been documented.)

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

#69

Post by XorNot »

orf wrote: post #56
jiggawatts wrote: post #53

Earlier quoted context omitted.

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 t…

Wedging a cloud resource so you can't delete it is always a bug.

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

#70

Post by orf »

XorNot wrote: post #69
orf wrote: post #56

Earlier quoted context omitted.

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 t…

Wedging a cloud resource so you can't delete it is always a bug.

Yes, in the service that provides the AWS resource.

Because it didn’t handle the fact that the role it’s using might be deleted or otherwise rendered un-assumable for a variety of different reasons at any point in time.

Which is a feature. Not a bug.

Post reply on HN