[liveoneggs]

I have caused billing spikes like this before those little warnings were invented and it was always a dark day. They are really a life saver.

Lifecycle rules are also welcome. Writing them yourself was always a pain and tended to be expensive with list operations eating up that api calls bill.

----

Once I supported an app that dumped small objects into s3 and begged the dev team to store the small objects in oracle as BLOBS to be concatenated into normal-sized s3 bjects after a reasonable timeout where no new small objects would reasonably be created. They refused (of course) and the bills for managing a bucket with millions and millions of tiny objects were just what you expect.

I then went for a compromise solution asking if we could stitch the small objects together after a period of time so they would be eligible for things like infrequent access or glacier but, alas, "dev time is expensive you know" so N figure s3 bills continue as far as I know.

[darkwater]

> I then went for a compromise solution asking if we could stitch the small objects together after a period of time so they would be eligible for things like infrequent access or glacier but, alas, "dev time is expensive you know" so N figure s3 bills continue as far as I know.

This hits home so hard that it hurts. In my case is not S3 but compute bills but the core concept is the same.

[WrtCdEvrydy]

Because the bill isn't a "dev problem". Once you move those bills to "devops", it becomes an infrastructure problem.

[zrail]

A big chunk of responsibility for teams doing cloud devops is cost attribution. Cloud costs are incurred by services and those services are owned by teams. Those teams should be billed for their costs and encouraged (via spiffs or the perf process if necessary) to manage them. Devops' job is to build the tooling that allows that to happen.

[ac2022]

It is also because devops is shoved down devs throats while claiming that it is easier and better. So now many of developers don’t want to spend time rewriting their code for something that is supposed to reduce their workload not increase it.

[darkwater]

Yeah, I totally agree, and I do this from an Ops perspective. 6-7 years ago I was really fearing my job would disappear because "everything will be automated in the cloud and owned by developers who write business code". Turns out it just transformed a bit but there is still plenty of not-strictly-related-to-business code to be written and maintained that developers mainly don't care about.

[vdm]

The warning should say "you have N million objects technically eligible for an archive storage class and hitting the button to transition them will cost $M".

Also S3 should no-op transitions for objects smaller than the break-even size for each storage class, even if you ask it to.

[sharken]

I suppose it's not just dev time on the line, but also the risk of doing the change that is thought to be too high.

If I ever get to be a manager I'd go for an idea such as yours. Though I suspect too many managers are too far removed from the technical aspect of things and don't listen nearly enough.