What does a hard cap look like for EBS volumes? Or S3? RDS?

Do you just delete when the limit is hit?

__s 9 hours ago | parent | next [-]

It's a system people opt into, you can do something like ingress/egress blocked, & user has to pay a service charge (like overdraft) before access opened up again. If account is locked in overdraft state for over X amount of days then yes, delete data

	▲	maccard 9 hours ago \| parent [-]
		I can see the "AWS is holding me ransom" posts on the front page of HN already.

▲

timando 2 hours ago | parent | prev | next [-]

2 caps: 1 for things that are charged for existing (e.g. S3 storage, RDS, EBS, EC2 instances) and 1 for things that are charged when you use them (e.g. bandwidth, lambda, S3 requests). Fail to create new things (e.g. S3 uploads) when the first cap is met.

▲

wat10000 8 hours ago | parent | prev | next [-]

A cap is much less important for fixed costs. Block transfers, block the ability to add any new data, but keep all existing data.

▲

umanwizard 9 hours ago | parent | prev [-]

Yes, delete things in reverse order of their creation time until the cap is satisfied (the cap should be a rate, not a total)

▲

maccard 9 hours ago | parent [-]

I would put $100 that within 6 months of that, we'll get a post on here saying that their startup is gone under because AWS deleted their account because they didn't pay their bill and didn't realise their data would be deleted.

> (the cap should be a rate, not a total)

this is _way_ more complicated than there being a single cap.

▲

umanwizard 8 hours ago | parent [-]

> I would put $100 that within 6 months of that, we'll get a post on here saying that their startup is gone under because AWS deleted their account because they didn't pay their bill and didn't realise their data would be deleted.

The cap can be opt-in.

	▲	maccard 7 hours ago \| parent [-]
		> The cap can be opt-in. People will opt into this cap, and then still be surprised when their site gets shut down.