Section 2 — AWS Account Structure
Companion to
musehub-production-readiness-checklist.md.
Decision (already made, per your answer during Section 0)
Single AWS account (992382692655) accepted as technical debt. No AWS Organizations, no
account split, before this launch. Recorded in the main checklist's Decision Log and Accepted
Risks tables.
Why the rest of this section is deferred, not done
Every remaining item in this section (Organization creation, management/production/non-production account split, per-account budget alerts, alternate contacts, region restriction) is scoped underneath the "should we split accounts" decision. Since the answer is "not now," these are correctly deferred rather than partially implemented:
- Creating an AWS Organization for a single account that isn't splitting yet would add organizational overhead (SCPs, OUs) with no accounts to actually separate.
- Budget alerts, alternate contacts, and region restriction are still worth doing within the single account — but that's account hygiene, not account structure. Tracking those under Section 15 (Cost Controls) and Section 3 (Identity) instead, where they actually belong given the single-account reality.
What's true about the current single account today
- Shared with the Stori project —
stori-assets-992382692655-useast2S3 bucket confirmed live alongsidemusehub-releases. This account is not MuseHub-dedicated. - Region usage: MuseHub resources are all in
us-east-1. I have no visibility into whether other regions are enabled account-wide or whether Stori uses a different region (its bucket name suggestsus-east-2— worth Gabriel checking region enablement across both projects before restricting regions, since a MuseHub-only region restriction could be fine, but an account-wide one needs to account for Stori too). - No account-level budget alerts, alternate contacts, or region restrictions confirmed — the
musehub-infracredential can't readbudgets:*or account settings to verify either way; this needs Gabriel checking directly in the AWS console.
Revisit trigger
Recorded in Accepted Risks: revisit the single-account decision post-launch, particularly if Stori and MuseHub start to have materially different security/compliance requirements, or if billing/cost attribution between the two projects becomes hard to disentangle.