Sample case study · AWS multi-account foundation
Four weeks with Tidepost, Inc., a fictional social-video news app that ran everything in one AWS account. The Build, taken as the add-on after its Security Audit, set up a landing zone, joined the founders’ account to a new organization as production, vended the other accounts, and attached 11 guardrail policies. The same foundation scan went from 1 of 12 checks passing to 11, with 1 waived in writing.The Audit’s governance review replaced the Blueprint, so the add-on starts at the plan readout. Every check of the foundation scan agreed at the readout passes at the end, and a check waived in writing counts as passed. The fee is $25,000, already net, with half of it riding on that gate. It shows the method, not a typical result.
Tidepost, Inc. is a fictional company: every account, person, and figure on this page is simulated. The AWS services and controls are real.
Tidepost, Inc. does not exist. We built it to show what this engagement produces for a startup that grew up in one AWS account: a social-video news app with 38 employees, 600,000 monthly active users, and production, staging, development, data science, and CI all in the founders’ account, simulated resource by resource. Then we ran the four-week Build against it, as the add-on after its Security Audit, window by window, and wrote the reports.
Tidepost is fictional. Its people, products, users, accounts, investors, and figures are invented for this sample, and any resemblance to a real company, person, product, or publication is coincidental. The reports are the real deliverables, written the way we write them for a client, and they agree with each other because every figure comes from one deterministic simulation. The Build is dated January 20 to February 13, 2026. We never cite a client’s findings, with or without the client’s name, so this is how we can show you every page.
Tidepost built fast on one AWS account, and the first scan showed what that costs: no organization, 18 IAM users, root access keys, and no trail of any kind that anyone else held. A SOC 2 Type 2 observation window ran from April 1, 2026 to September 30, 2026, its lead investor had asked for the report, and the newsrooms it sells to ask for one in their vendor reviews. Tidepost’s CPA firm owns that report. Tidepost needed an account structure under production before the window opened, without stopping production.
Dev Raman signed four engagements, and the Security Audit came first. Its week-one scan ran the 13 foundation checks beside its own, and its governance review produced the account map, the policy set as code, and the risk register. That is the discovery a Blueprint would have done, so Tidepost did not buy one: the Build was added in the Audit’s third week and starts at the plan readout. Kofi Brandvold led it day to day, and Sasha Ilyin owned the compliance side.
The Build began in the Security Audit’s third week and ended the same day the Audit did, February 13, so the two ran side by side. The Audit’s governance review stood in for the Blueprint, which is why the plan below was agreed before week one. Each week ended with a report, and every report is below.
The plan was presented inside the Audit’s readout on Friday, January 16, with the Audit’s scan, account map, policy set, and risk register in place of a Blueprint. Dev Raman chose the greenfield path that day, since a retrofit needs an organization to keep and Tidepost had none, agreed 12 of the 13 scan checks as the gate with MAF-11 left out (one VPC and no shared network to own), and approved the first window in writing. The scan had passed 1 of 12 on its first run, and only MAF-13, which tests that Vantalect’s role is gone, passed: the role did not exist yet.
Week one began on Tuesday, January 20, the day after Martin Luther King Jr. Day, when Kofi Brandvold created the operator role in the management account. On Wednesday, January 21 the first window set up Control Tower, the Security OU with the log archive and audit accounts, and the other OUs, 2 of them empty by design, and confirmed the organization trail that has logged ever since. The break-glass user was created and its hardware key sealed on Thursday, January 22, with custody split between Sasha Ilyin and Noor Castellanos, before anything depended on the identity provider. The second window, on Friday, January 23, connected IAM Identity Center to it, created the 6 permission sets, and attached the 8 draft policies to the one OU that never holds a workload.
The windows. W1 on Wednesday, January 21, 09:00 to 15:00 CST, approved January 16; W2 on Friday, January 23, 09:00 to 12:00 CST, approved January 21. Nothing failed and nothing was rolled back.
The join changes who pays the bill, so its window had the longest pre-flight: 9 checks, from root-email custody to whether the account could leave the organization again. The first run, on Monday, January 26, found one blocker, and it was about leaving, not joining. Leaving is the join’s rollback, and it needs a current payment method and the account’s own contact information. The card on file was a founder’s and expired January 31, and the contact still named a founder’s personal email. Joining needs neither, so the window would have run; the failure would have shown only when someone needed to go back. Gwen Tallis fixed both on Tuesday, January 27, the second run was clean, and the window had been approved on the condition that it would be.
On Wednesday, January 28 the founders’ account was invited and Tidepost accepted inside it, so Vantalect never had write access. It landed in the Prod OU, was enrolled in Control Tower, and its events joined the organization trail. Nothing moved: the join changes who the account belongs to, not what runs in it. The day before, finance had exported the account’s Cost Explorer history, because the new payer sees an account’s cost only from the join, and the Cost and Usage Report export started that day. The people had moved from IAM users to Identity Center sign-in on Monday, January 26. The next day root credentials came out of production under centralized root access, and Tidepost created its staging and policy-test accounts itself, through Account Factory.
The windows. W3 on Wednesday, January 28, 09:00 to 15:00 CST, approved January 26, after one blocker in the pre-flight cleared the day before. The rollback was ready and was not used.
The policy set is 11 policies: 4 service control policies, 3 resource control policies, 2 EC2 declarative policies, a tag policy, and a backup policy. None reached an OU that held an account until it had passed its cases in Policy Staging, 29 across the set. The cases found one real defect: on Friday, January 30 the baseline service control policy denied Control Tower’s own configuration update during a drift repair, which on a live OU would have been a repair failing with an access-denied error nobody expected. The fix merged on Monday, February 2 and was re-tested before it went anywhere. The baseline is 3 service control policies and not one per purpose, because AWS allows 5 on an OU and 2 slots are taken before the first is added.
The window on Tuesday, February 3 attached the baseline to the sandbox and non-production OUs and started the denial watch. The window on Thursday, February 5 came 45 hours later, with 0 policy-caused denials in between, and attached it to production, security, and infrastructure. The same window vended the sandbox account through Account Factory, and it passed MAF-02 to MAF-08 without anyone touching it by hand, which is the proof behind MAF-09. Tidepost created its development account itself on Tuesday, February 3, after that day’s window had closed, and it inherited the policies from its first minute.
The windows. W4 on Tuesday, February 3, 09:00 to 12:00 CST; W5 on Thursday, February 5, 09:00 to 13:00 CST. The watch rule is at least 24 hours with no access denied by a policy before the next, more critical OU.
The last window, on Tuesday, February 10, created the backup account through Account Factory, delegated central backup to it, locked the central vaults in compliance mode, and attached the backup and tag policies. Tidepost can remove the vault lock until its cooling-off period ends on Friday, February 13; from then on the lock is immutable. The one waiver of the engagement came a day later: on Wednesday, February 11 Sasha Ilyin signed MAF-05, for a video analytics vendor’s IAM user in production whose system cannot assume a role. The report holds the full waiver. Tidepost deleted the operator role on Friday, February 13, before the final scan, which is how the check for lingering access passes.
The same scan then ran again, the same way, from the read-only roles in every account: 11 checks passing, 1 waived in writing, and 0 failing. The workshop on Thursday, February 12, recorded, had Kofi Brandvold, Sasha Ilyin, and Dev Raman run two of the 5 runbooks live; the other three had already been proved on real changes. The add-on used 68 of its 70 hours.
The windows. W6 on Tuesday, February 10, 09:00 to 14:00 CST, approved February 6. The re-scan and the closing readout were on Friday, February 13.
Half the fee rode on one scan. The same read-only script ran at week one and at the end, in every account, and it scores the organization, not the effort. Each step from the first run to the last is in the re-scan report.
Plus 1 waived in writing, which the gate counts as passed. MAF-11 is out of scope in both runs.
In one organization of 9 OUs, 2 of them empty by design. The founders’ account joined as production and kept running.
People moved to single sign-on; the one user left is the vendor’s, waived in writing and rotated every 90 days.
Counted toward the gate: 12 of 12 in-scope checks, 11 passing and 1 waived in writing, none failing. The gate, as agreed at the readout: Every check of the foundation scan agreed at the readout passes at the end, and a check waived in writing counts as passed. It was met, so the second half of the fee, $12,500 of $25,000, was invoiced on February 13. The fee is net: the list fee is the fee, with no bundle discount.
Still Tidepost’s: moving the staging and data workloads into their own accounts, which is migration and was outside the add-on; tagging the resources the backup policy should select, which the Well-Architected Remediation does; rotating the waived vendor key by May 12, then every 90 days; and scoring MAF-11 when a shared network exists. The Build set up the organization and left it running; it did not move Tidepost in.
Want this gate on your own organization?
Book a call about the BuildA foundation is mostly decisions about what not to touch. These are the ones that shaped the Build, each with who made it and why.
Three things the foundation does not fix. None was missed: each was decided, and each has an owner.
A video analytics vendor’s system cannot assume a role and has no plan to. Its IAM user sits in production, in the Prod OU, so the identity check cannot pass, and moving the user would mean moving production out of Prod. Its scope is read access to one prefix of one bucket, and its key is rotated every 90 days through a role that can change only that user’s keys.
Next rotation. May 12, then reviewed at each quarterly access review.
Tidepost has one VPC and no Transit Gateway, so there is no shared network for a network account to own. The check is described in the week-one scan and left unscored at the end, so the gate does not count it either way.
Scored when. A shared network exists.
Moving the staging and data workloads out of the production account is migration, a change order or another statement of work. The Build vends the accounts and sets the guardrails; Tidepost moves in on its own calendar.
Who moves them. Tidepost’s platform team, following the runbooks for vending an account and for moving one in.
Three decisions that fixed what came first, and why.
A retrofit needs an organization to keep, and Tidepost had none. The founders’ account was its own payer and ran production, so a new management account runs no workload, and the founders’ account joins as the production member.
There were no commitments, credits, budgets, or allocation tags to carry, so nothing depended on a month boundary. Because the new payer cannot see an account’s earlier history, finance exported the Cost Explorer history first; the Cost and Usage Report export started at the join.
A wrong deny on production shows up only as access denied. Every policy was proven in Policy Staging, then attached to the sandbox and non-production OUs, then to production after a watch of at least 24 hours with no policy-caused denial. Detaching any policy is one call.
The one high risk. The register held 10 risks: 1 high, 4 medium, and 5 low.
Each decision is recorded where it was made: the plan readout holds the path, the gate, and the risk register, and the re-scan report holds the waiver in full.
A Build runs in a Pavilion workspace, created from the engagement’s template with every week, window, deliverable, and obligation already in place, on the client’s calendar and in its time zone. The sponsor, the platform lead, the compliance owner, and finance join it, and Charles.
After each session the transcript comes into the workspace, and an agent drafts the summary, the decisions taken, and the action items, each claim citing the part of the transcript it came from. Charles reviews every draft before the client sees it. Every report is published there as an immutable, hashed version, and the sponsor accepts each one against that version.
Tidepost has no demonstration workspace, so this page describes the workspace in words and counts nothing in it.
The join’s first pre-flight on January 26 found a rollback that could not run. The workspace keeps the check, the failure, the fix, and the clean second run together, so the record shows why the window waited a day.
The baseline policy that denied Control Tower’s own repair is recorded with the day staging found it, January 30, and the day the fix merged, February 2, so the revision has its reason beside it.
Sasha Ilyin’s written waiver for MAF-05 is stored with the vendor, the scope, the rotation, and the date of the next review, so the gate’s one waived check is a click away from the person who signed it.
The operator role was created on January 20 and deleted on February 13, before the final scan. The workspace holds both dates, because the scan’s last check is that the role is gone.
The engagement’s last tasks hand the runbooks, the repository, and the custody of break-glass access to Tidepost, with an owner on each. Then the workspace closes.
Eight PDFs and 115 pages. Start with the readout; the reading guide shows how the rest fit together. Then read the four weeks in order and the re-scan for the proof, and you have the Build the way Tidepost’s sponsor did. Each one is tagged for screen readers, and each says on its cover that Tidepost is fictional.
Written for the sponsor, and the one to read if you read nothing else: the greenfield path, the account map, the change windows, the checks in scope, the risk register, and the decisions needed before week one. It was presented inside the Audit’s readout.
tidepost-foundation-3-readout.pdf
The greenfield path, the account map, the change windows, the in-scope checks, and the risk register, presented in the Audit readout.
View Foundation Plan Readout in the PDF viewerDownload PDF of Foundation Plan Readout
The policy set as code: every service control policy, resource control policy, declarative policy, tag policy, and backup policy, with what each blocks, what it exempts, who it would affect today, and the cases it must pass in Policy Staging before any other OU sees it.
tidepost-foundation-2-appendix.pdf
Every SCP, RCP, declarative policy, tag policy, backup policy, and Control Tower control, as code, with what each blocks.
View The Policy Set as Code in the PDF viewerDownload PDF of The Policy Set as Code
The reading guide first, then what each week delivered, in order.
tidepost-0-guide.pdf
Who Tidepost is, why a Series A and a SOC 2 Type 2 brought four engagements, what each of the 33 reports delivers, and what is real and what is simulated.
View Sample Engagement Reports in the PDF viewerDownload PDF of Sample Engagement Reports
tidepost-foundation-4-landing-zone.pdf
Control Tower in the new management account, the Security OU with tp-log-archive and tp-audit, and IAM Identity Center.
View Landing Zone and Core Accounts in the PDF viewerDownload PDF of Landing Zone and Core Accounts
tidepost-foundation-5-moves.pdf
The pre-flight, the January 28 join of the founders’ account as tp-prod, its enrollment, and the billing transfer.
View The Founders’ Account Joined and Enrolled in the PDF viewerDownload PDF of The Founders’ Account Joined and Enrolled
tidepost-foundation-6-guardrails-vending.pdf
Policies proven in Policy Staging and attached OU by OU, the vended tp-sandbox-ml, and central backup.
View Guardrails, Vending, and Shared Services in the PDF viewerDownload PDF of Guardrails, Vending, and Shared Services
tidepost-foundation-7-rescan.pdf
MAF-01 to MAF-13 run again: eleven passing and one waived in writing, and the gate.
View Foundation Re-Scan in the PDF viewerDownload PDF of Foundation Re-Scan
tidepost-foundation-8-runbooks-handover.pdf
Vending, moving an account, changing a policy, break glass, and suspending an account, and the operator role deleted.
View Operations Runbooks and Handover in the PDF viewerDownload PDF of Operations Runbooks and Handover
The same gate on your own organization: the foundation scan at the start, and the same scan at the end.
The Build: a landing zone, every in-scope account in its target OU, guardrails every account inherits, people on single sign-on, account vending, and the same scan run again, with half the fee riding on the gate. After a Security Audit, the Audit’s governance review takes the place of the Blueprint.
Read the engagement
A fictional startup that built fast on one AWS account: $1,054,404 a year identified at list prices, $725,391 measured on its own Cost and Usage Report across 31 changes, and five approved changes kept out of the gate until their conditions are met.
Read the case study
A fictional social-video startup with one AWS account and a SOC 2 Type 2 window coming: 47 findings verified, nine of ten criticals closed and the last signed for with an end date, and the same scan from 24.0% to 90.0%.
Read the case study
A fictional social-video news app and its one production workload, scored against all six pillars of the AWS Well-Architected Framework: 25 high-risk issues agreed, 20 closed by change, 5 accepted in writing, none unresolved at week six, verified in its own Well-Architected Tool.
Read the case studyTell us roughly how many accounts you run, whether you have an organization yet, and what prompted the question. You will hear back from Charles within one business day, and the first call is fifteen minutes.
AWS, Amazon Web Services, and the AWS service names are trademarks of Amazon.com, Inc. or its affiliates. SOC 2 is a registered trademark of the American Institute of Certified Public Accountants. Vantalect is not affiliated with or endorsed by either. Tidepost, Inc. and every person named on this page are fictional.
