Every agent covered in this series runs inside an AWS account. This article is the foundation those accounts need to exist on — architected once, provisioned for every new client in hours instead of weeks.
DevOps Agent, Security Agent, and FinOps Agent all need somewhere consistent to run: an account structure with the right guardrails, the right cross-account roles, and the right centralized visibility, provisioned identically for the tenth client as for the first. Without that, every new client onboarding becomes a bespoke infrastructure project, and the agentic practice described elsewhere in this series never scales past a handful of hand-built accounts.
1. The Core Structure
AWS Organizations with Control Tower provides the account-vending machine at the top: a management account applying Service Control Policies and org-wide guardrails, with organizational units separating security (log archive, audit, GuardDuty delegated administration), infrastructure (shared networking, Direct Connect or Transit Gateway attachments), and workloads (one account per tenant, or per environment within a tenant for larger clients).
Each tenant account is templated, not hand-built — the same account factory blueprint applied every time, with per-tier variation limited to explicit override points rather than ad hoc configuration drift. Cross-account IAM roles, scoped narrowly per tenant, are what the MSP’s own tooling and the agents from earlier articles assume when they act on a client’s behalf.
Technical deep-dive — what the account factory template actually enforces. The blueprint’s value is in what it makes structurally impossible, not just what it configures by default. A minimal SCP attached at the Workloads OU denies any action that would disable the mandatory guardrails, regardless of what permissions an individual tenant account’s IAM roles later grant:
{
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"guardduty:DeleteDetector",
"config:DeleteConfigurationRecorder",
"config:StopConfigurationRecorder"
],
"Resource": "*",
"Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws:iam::MGMT_ACCOUNT:role/BreakGlassAdmin" } }
}That single SCP is what lets an MSP promise a client “your account cannot silently go dark on audit logging,” even from an admin inside that tenant’s own account — the guarantee that makes the centralized logging account in Figure 4 actually trustworthy rather than merely convenient.
2. Centralization Without Losing Tenant Boundaries
A dedicated logging and billing account aggregates CloudTrail, Config, and GuardDuty findings across every tenant account, and consolidates billing. Cross-account metrics centralization lets the MSP designate a monitoring account that automatically aggregates metrics from every member account, which is what makes fleet-wide dashboards and alarms possible without manual per-account setup — the same centralization pattern this series’ earlier observability work depends on.
The design tension is between centralization (one place to see everything) and isolation (a tenant’s data never leaks sideways to another tenant, and a security incident in one account cannot escalate laterally). Getting this boundary right, once, in the account factory template is what lets every subsequent client onboarding skip the argument entirely.
3. Productizing the Practice
Enterprise — a custom OU structure reflecting the client’s own business units or compliance boundaries, with SCP overrides negotiated as part of the onboarding statement of work, but still provisioned through the same underlying account factory.
SMB — the standard templated baseline, provisioned with no negotiation on structure — the value is speed and consistency, not customization.
DNB — fast, self-service provisioning, often triggered by the client’s own platform team through an API rather than an MSP ticket, with the MSP’s role concentrated in the initial template design and periodic guardrail review.
What changes for the SI partner
The landing zone stops being a one-time setup fee buried inside a larger migration engagement and becomes a standalone, repeatable asset — the thing that makes every other article in this series deployable in days rather than months for the next client. Partners who template this well measure client onboarding time in hours; partners who don’t measure it in weeks, and that gap compounds across every new logo.
Business Value Mapping
| Technical capability | Business outcome | Metric / KPI | Primary stakeholder |
|---|---|---|---|
| Templated account factory (Control Tower blueprint) | New client onboarding in hours, not a bespoke infra project | Time from signed SOW to first workload account live | Delivery lead / partner ops |
| SCP-enforced guardrails at the OU level | Compliance posture is structural, not a policy on paper | Guardrail violation rate across tenant fleet | CISO / compliance |
| Centralized logging & billing account | One place to see and bill every tenant, no manual per-account setup | Time to produce a cross-tenant report | Finance / partner ops |
| Scoped cross-account IAM roles | MSP tooling and agents act on a client’s behalf without shared credentials | Least-privilege audit pass rate | CISO |
| Tier-based override points (Enterprise/SMB/DNB) | Customization only where it’s sold, standardization everywhere else | % of onboardings requiring off-template changes | Delivery lead |
The landing zone is the least visible thing you build and the reason everything else you sell can be sold twice as fast.
Sources: AWS Control Tower and Organizations documentation · CloudWatch cross-account metrics centralization (AWS documentation, 2026) · AWS Cloud Operations Blog, multi-account architecture patterns.
