s3-cost-management: prune automation disabled; correct guidance

The weekly media-prune cron (and monthly accounts refresh --all) were
removed 2026-06-01 after repeatedly breaking avatars. Update the
majortoot sections: the 648->7GB shrink was a one-time safe attachment
cleanup; automation is now disabled; prune attachments manually if ever
needed, never profiles. Cross-link the two new troubleshooting articles.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Marcus Summers 2026-06-01 15:46:42 -04:00
parent 4e63d8546c
commit e6a249403c

View file

@ -5,7 +5,7 @@ category: cloud
tags: [aws, s3, cost, billing, mastodon, glacier]
status: published
created: 2026-04-19
updated: 2026-05-23
updated: 2026-06-01
---
# AWS S3 Cost Management
@ -23,7 +23,7 @@ The majorlinux AWS account is used exclusively for S3 object storage. This cover
| Bucket | Size | Storage Class | Cost/mo | Purpose |
|--------|------|---------------|---------|--------|
| `majortoot` | ~7 GB (after weekly prune running) | S3 Standard | ~$0.16/mo | Mastodon media |
| `majortoot` | ~7 GB (one-time prune; automation disabled) | S3 Standard | ~$0.16/mo | Mastodon media |
| `majorhomebackup` | 16 TiB | Glacier Deep Archive | ~$1112/mo | MLS stream archives (sole copy) |
| `config-bucket-*` | ~185 KB | S3 Standard | ~$0.00 | AWS Config snapshots |
@ -87,9 +87,13 @@ The theory: switching `S3_STORAGE_CLASS=STANDARD_IA` saves ~$45/mo on storage
With the weekly prune now running correctly and the bucket shrinking toward ~7 GB, the storage savings of SIA are negligible (~$0.05/mo). **Leave at STANDARD.**
### majortoot — Weekly media prune
### majortoot — media pruning (automation DISABLED 2026-06-01)
Weekly cron deployed (`0 3 * * 0`) via `configure_mastodon_media_prune.yml`. Removes remote federated cache older than 7 days. Bucket shrinking from 648 GB toward ~7 GB over time. **This is the real cost driver — let it run.**
A weekly prune cron (`0 3 * * 0`, via `configure_mastodon_media_prune.yml`) **used to** run `tootctl media remove --days=7`. It shrank the bucket from 648 GB to ~7 GB — a one-time cleanup of years of accumulated remote **attachment** cache, which is safe and accounts for the bulk of the savings above.
**That automation was removed 2026-06-01.** The same playbook also carried a monthly `tootctl accounts refresh --all`, and automated profile pruning (plus a storage-level deletion during the cost-cull/migration) repeatedly broke remote avatars. The playbook is now an *enforce-absent* guard, and a [synthetic upload health check](../services/mastodon-s3-acl-upload-failures.md) alerts if media serving/uploads regress. See [[mastodon-prune-profiles-trap]] and [[mastodon-s3-acl-upload-failures]].
**Going forward:** the bucket is already small (~7 GB) and attachment cache re-accumulates slowly. If it ever grows enough to matter, run an **attachment-only** prune **manually and deliberately** (`bin/tootctl media remove --days=30`) — never automate profile/header pruning or `accounts refresh --all`.
### majorhomebackup — Self-host consideration
@ -148,5 +152,6 @@ aws cloudtrail lookup-events \
## Related
- [[mastodon-instance-tuning]] — media cache management
- [[mastodon-prune-profiles-trap]] — avatar restore incident (May 2026)
- [[mastodon-prune-profiles-trap]] — avatar restore incident + bulk-restore procedure
- [[mastodon-s3-acl-upload-failures]] — silent upload failures on ACL-disabled buckets
- [[majortoot]] — Mastodon host