How would you make the case for the cost of a separate AWS account, if leadership pushes back on the added complexity?

Quantify the actual blast radius being contained — specifically what a compromised credential in the shared account could reach versus what it could reach in an isolated account — using concrete resource examples, not abstract risk language, and frame the account's operational cost honestly against that specific, quantified risk reduction; if leadership still isn't convinced, propose the strongest available middle ground (tighter resource-level isolation within the existing account, more aggressive monitoring) as a lower-cost partial mitigation, explicit about what risk it doesn't fully address compared to true account isolation.

Make the blast radius concrete, not abstract: rather than a general "isolation reduces risk" argument, name specifically what's in the shared account that a compromised credential could reach — other services' data, other credentials, production resources unrelated to this integration — versus what an isolated account would limit that same compromise to. Concrete examples ("a compromised key here could currently reach the production customer database; in an isolated account, it would be contained to only this integration's own resources") are far more persuasive than an abstract appeal to defense-in-depth.

Quantify the account's actual operational cost honestly: rather than dismissing leadership's concern, take it seriously and quantify it — AWS accounts themselves are free to create; the actual cost is typically the operational overhead of managing another account (billing consolidation is usually already solved via AWS Organizations, but access management, monitoring setup, and cross-account networking if needed add real, if usually modest, ongoing effort). Presenting this honestly (rather than either overstating or dismissing it) builds credibility for the rest of the argument.

Frame it as risk-proportional, not a blanket policy: rather than arguing "always use separate accounts," make the case specifically for this situation's risk profile (a static credential, a third-party integration, meaningful blast radius if compromised) — this framing is more persuasive than an absolute policy position, and also gives leadership a legitimate way to agree on this specific case without committing to a broader, more expensive standard they might reasonably resist.

Offer a genuine middle-ground fallback if the full ask isn't approved: if a separate account genuinely isn't approved, propose the strongest available partial mitigation within the existing account — tighter resource-level IAM scoping specifically preventing the integration's credential from reaching anything beyond its narrow intended resources (even without full account isolation), combined with the enhanced monitoring discussed elsewhere — explicit that this doesn't fully close the gap a separate account would, but is a real, lower-cost improvement over the status quo. Presenting this alongside the primary ask, rather than only after being told no, shows you've already thought through the trade-off rather than being unprepared for pushback.

• Make the blast-radius argument concrete with specific resource examples, not abstract risk language.
• Quantify the account's actual operational cost honestly rather than dismissing the concern, which builds credibility for the rest of the case.
• Frame the ask as risk-proportional to this specific situation, not an absolute policy — easier for leadership to approve without committing to a broader standard.
• Have a genuine, lower-cost middle-ground fallback ready if the full ask isn't approved, explicit about what risk it doesn't fully address.

• AWS: Organizing your AWS environment using multiple accounts