gabriel / musehub public
15-cost-controls.md markdown
48 lines 3.5 KB
Raw
sha256:6e6a6f1117a93cbbf7e0a7aac5c7fc39f797311478b179ca1c6b6dcf1461f82a docs: mark Phase 0 archival dump complete in database archi… Sonnet 5 patch 4 days ago

Section 15 — Cost Controls

Companion to musehub-production-readiness-checklist.md.

Verified today

  • Baseline cost is well-documented in docs/infrastructure.md: ~$35/mo for both environments running (2× t3.small/t3.medium EC2, 2× Elastic IP, 2× EBS gp3 20GB). This already satisfies "document expected baseline monthly cost."
  • Tagging is inconsistent and mostly absent: musehub-prod instance has only a Name tag; musehub-staging has Name + Environment but nothing else. The musehub-releases S3 bucket has no tags at all (NoSuchTagSet). No Owner, Managed-by, or Cost-center tags exist anywhere. ECR repo tags couldn't be checked (permission denied) — likely the same story.
  • Account-level budgets, Cost Anomaly Detection, and billing contacts — all blocked, same permissions gap as Sections 2/3/13. Needs Gabriel or the broader-access grant.
  • Shared account with Stori (Section 2) means cost attribution between the two projects is not currently possible without consistent tagging — this is the practical reason tagging matters more here than it would in a MuseHub-dedicated account.

Checklist assessment

  • [ ] Apply consistent cost-allocation tags. — not done, confirmed inconsistent/absent above
  • [ ] Create monthly AWS budgets. — blocked, needs Gabriel/broader access
  • [ ] Alert Gabriel and Aaron at multiple thresholds. — N/A until budgets exist
  • [ ] Enable Cost Anomaly Detection. — blocked
  • [ ] Review NAT Gateway, data-transfer, and logging costs. — N/A for NAT (none exists, Section 5); logging cost is a real open item given /musehub/staging's unlimited retention (Section 12) — 1.7GB and growing forever
  • [x] Set log-retention limits. — tracked as an open item under Section 12, not duplicated here
  • [ ] Set backup-retention limits consistent with recovery requirements. — N/A, no backups exist yet (Section 8)
  • [ ] Right-size production after load testing. — not done, no load testing has occurred
  • [ ] Review idle resources. — not reviewed; worth checking whether staging is stopped when unused per docs/infrastructure.md's own suggestion ("stop when not in use to reduce cost") — evidence suggests it's left running (log group actively receiving traffic during this session)
  • [x] Document expected baseline monthly cost. — already done in docs/infrastructure.md (~$35/mo)
  • [ ] Document the cost implications of autoscaling. — N/A, no autoscaling exists (Section 5)
  • [ ] Configure service quotas and limits deliberately. — not done, same as Section 5's open item
  • [ ] Review production cost weekly during the first month. — process doesn't exist yet, deferred to Section 19 (Post-Launch)
  • [ ] Add owner and purpose tags to every billable resource. — not done, see tagging findings above
  • [ ] Alert on untagged or unexpectedly expensive resources where practical. — not done

The actual work items here

  1. Apply a consistent tag set (Application, Environment, Owner, Managed-by, Cost-center) across every resource — cheap to do now, gets much harder to retrofit later, and directly enables cost attribution in the shared Stori/MuseHub account.
  2. Once broader access lands: set up account-level budgets with multi-threshold alerts to both Gabriel and Aaron, and enable Cost Anomaly Detection.
  3. Decide whether staging should actually be stopped during idle periods per infrastructure.md's own suggestion, given it appears to be left running continuously today.
File History 1 commit
sha256:e9bdf7fbf5451787b3c5b7c82b3c9991c1c1f4cc9cf06e28036a4e834a34acf8 docs: correct stale self-hosted-only database architecture claims Sonnet 5 4 days ago