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

121–124 of 124 posts

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

#121

Post by orf »

XorNot wrote: post #116
orf wrote: post #107

Earlier quoted context omitted.

It doesn’t make any sense. Forgive me for saying this, but if you don’t really know how all this works then it’s a convenient throwaway thing to suggest. So I think it’s up to you to explain how this would work when there is no difference between a role being deleted and a role being inaccessible . What exactly would you do if I block instance with the ID “xyz” from assuming the role I have assigned it? How would you…

That's an inline policy which is attached to the role . And notably AWS roles require all policies to be removed before they're deleted (which I know because I spent a bunch of time recently fixing ordering issues with CloudFormation deletes). Again you keep just asserting this isn't possible: why ? AWS are aware you need the role to exist to delete the instance (as noted up in the OP), why apparently is it completel…

It’s possible, it’s just convoluted, introduces a weird circular dependency, not always the behavior you want in the general case, possible to do without requiring changes to the IAM service via cloudfront or terraform, would require IAM to support every single possible “delete” variant (delete an instance with a backup? Without one? Final RDS snapshot name? Etc etc), would need to recursively delete resources, would require a complex set of APIs to track the asynchronous deletion process, and as stated several times before completely ineffective against conditions where the role hasn’t been deleted but the service cannot assume it. Which leaves you in exactly the state you’re trying to avoid.

In short: it would be a confusing mess for nebulous gains that doesn’t pass any kind of smell test. Instead they should just… fix the AWS batch service.

The better solution is to provide an API and console tab to show you what services last used the role, when they used it and how they used it. Which is what they do.

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

#122

Post by deathanatos »

jiggawatts wrote: post #106
deathanatos wrote: post #71

Earlier quoted context omitted.

Not only referential integrity, but also not supporting Read-Your-Writes[1]. Cloud scale! Nothing like, 1. Create resource. Success. 2. Attempt to use/reference first resource in another resource/call: Failure: Referenced resource does not exist. Odd. 3. Create resource again? Failure! Resource already exists. Our scripts have so many retry loops and arbitrary pauses mixed in to account for garbage like this. Disting…

> Our scripts have so many retry loops and arbitrary pauses mixed in This is unfortunately your fault, not Azure's. Their API is explicitly designed around this eventual consistency and weak references, so your client side must take this into account. Typical bash, Python, or PowerShell scripts are the Wrong approach with a capital W, and you will forever be tearing your hair out if you persist on using them. (Or any…

To be frank, that's a lot of words to say that, instead of fixing the bugs at their core, MS wrote an entire product to try to work around the bugs in the original product, and now wants me to use that layer instead. And, yeah, that's about how MS sees the world. But "yeah, no" is the serious answer there, and we're moving anything we can to Terraform first.

Most of the failures we see are with AAD, which, AIUI, ARM templates do nothing for.

Even within ARM, as I understand them, ARM templates cannot handle deletes or changes. (They are deployments of new resources.)

And even if one could use templates, that just abstracts the same problem: how long do you wait for the template, if it has finished? (we see changes in ARM take >30 minutes to effect, and even after completion, it can take more minutes for things to "settle", i.e., successive requests to reliably return the same result. It just bottles it all into one highly inconsistent box, maybe, and requires me to learn an entire language on the side.) if it hasn't?

> That works, because the GUID can be used even if the full object is not fully replicated around yet.

Interesting. I'll keep that in mind.

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

#123

Post by lvh »

wielebny wrote: post #18
lvh wrote: post #6

I've used aws-nuke a bunch but the use case seems significantly diminished now that AWS Organizations has the ability to delete entire accounts.

Last time I've checked it was a lengthy process involving attaching a credit card, leaving the organization and then deleting the account. Has it been changed?

It used to be, but there's an API now: https://aws.amazon.com/blogs/mt/aws-organizations-now-provid...

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

#124

Post by deathanatos »

jiggawatts wrote: post #106
deathanatos wrote: post #71

Earlier quoted context omitted.

Not only referential integrity, but also not supporting Read-Your-Writes[1]. Cloud scale! Nothing like, 1. Create resource. Success. 2. Attempt to use/reference first resource in another resource/call: Failure: Referenced resource does not exist. Odd. 3. Create resource again? Failure! Resource already exists. Our scripts have so many retry loops and arbitrary pauses mixed in to account for garbage like this. Disting…

> Our scripts have so many retry loops and arbitrary pauses mixed in This is unfortunately your fault, not Azure's. Their API is explicitly designed around this eventual consistency and weak references, so your client side must take this into account. Typical bash, Python, or PowerShell scripts are the Wrong approach with a capital W, and you will forever be tearing your hair out if you persist on using them. (Or any…

Yeah, so I'm hitting this again today, so now I can comment more knowingly.

> Generally you want to wrap your deployments in a script that takes the object GUID of the created group and feed that into the template. That works, because the GUID can be used even if the full object is not fully replicated around yet.

In the case I have today (wanting to perform an action on a newly created application), this trick doesn't work. (We make the call by specifying the application by ID, too.)

"Bad Request […] It looks like the application '[ID]' you are trying to use has been removed or is configured to use an incorrect application identifier."

It's not removed, of course, and the ID isn't incorrect.

Edit: actually, it is worse than that. So, there's the above error, and that's essentially a failure to have read-your-writes.

Our scripts retry on that, because our scripts have become accustomed to AAD's shit. But we eventually hit this sequence of events:

  1. Create the app
  2. Grant admin-consent
  [other necessary setup]
  3. Create an AKS cluster:
And it fails because the App need to have admin-consent granted on it. But we do that, in step 2, and my logging is now good enough to show that we not only retry it after a read-your-writes failure, but that the command eventually succeeds, but the UI doesn't end up reflecting that. This is not a read-your-writes failure, this is a lost write!
Post reply on HN