Sample case study · AWS Well-Architected Framework Review
Six weeks with Tidepost, Inc., a fictional social-video news app, on the one workload it sells: how an upload becomes a moderated, ranked item on a reader’s timeline. The Review scored it against all six pillars of the AWS Well-Architected Framework and found 25 high-risk issues. By week six 20 were closed by change and 5 were accepted in writing, verified in Tidepost’s own AWS Well-Architected Tool.
Tidepost, Inc. is a fictional company: every account, figure, and person on this page is simulated. The AWS prices are real list prices, retrieved October 13, 2026 and October 18, 2026.
Tidepost, Inc. does not exist. We built it to show what this engagement produces for a startup that grew fast on one AWS account: a social-video news app with 600,000 monthly active users, one workload that carries everything it sells, and 18 newsrooms that license its verified clips and ask what happens when something fails. Tidepost ran four Vantalect engagements, one after another, in one simulated AWS estate; this page is the Well-Architected one, and the other three are linked at the bottom.
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 below are the real deliverables, written the way we write them for a client, and Vantalect never cites a real client’s findings, with or without the client’s name.
Tidepost built the Brief fast, in one AWS account, and it worked. By the time the Review began, 600,000 people used it every month, and the Series A closed on February 27, in the Review’s first week. The investor and the newsroom customers were both asking the same plain question: what happens to the workload when something fails?
The estate had already been through two engagements. The Audit closed the critical security findings and the Foundation moved the founders’ account into an organization, so the Review started inside it, with the backup vault in tp-backup waiting. What nobody had looked at together was the workload itself. Of its 23 components on 5 paths, 10 sat in a single Availability Zone, 14 had been built by hand in the console, and only 9 were defined in the CDK. Nothing had ever been restored from a backup, and Tidepost had no written recovery objectives. Two engines, the production database on PostgreSQL 13 and the production Kubernetes cluster, were at the end of standard support.
Each week ended with a report, and every report is below. The Review is the first two weeks and the Remediation the four that follow, in the sequence the sponsor agreed at the readout: the network and the backups first, because the zone moves and the database cutover depend on them.
The Brief became a workload in Tidepost’s own AWS Well-Architected Tool on Monday, February 23. One lens was answered and counted, the AWS Well-Architected Framework; the Machine Learning Lens informed the questions about ranking and moderation and counted for nothing. Four sessions with the people who run it, 5 hours in all, covered the architecture and reliability, security and operations, and performance, cost, and sustainability, so nobody sat through a pillar that was not theirs.
The architecture was written down as found: 23 components on 5 paths, 10 of them in one Availability Zone, 14 built in the console, and 9 in the CDK. Every answer in week two would cite one of 7 read-only sources: live configuration, telemetry, billing, the infrastructure code, service quotas, the earlier engagements, and what people said in the sessions.
The calendar. Kickoff on Monday, February 23 (60 minutes); the workload report on February 27.
In the room. Dev Raman, Kofi Brandvold, and the owners of machine learning, data, trust and safety, and the backend at the kickoff, then each pillar’s owners in their own session.
All 57 questions were answered in the Tool from live configuration, telemetry, the bill, and the repository, with the evidence in each answer’s notes and the best practices not selected listed beside it. The score: 25 high-risk issues, 21 medium-risk issues, and 11 questions with no improvements identified. Reliability was the weakest pillar, with 8 of its 13 questions at high risk, and Security carried the fewest, because the Audit had already closed most of what that pillar asks. Four facts produced most of the register: every stateful service and server tier in one zone, no recovery plan, about half the estate outside code, and capacity that never followed demand.
The readout on March 6 saved the answers as milestone one, the baseline, and agreed all 25 high-risk issues that day: 20 to close by change in weeks three to five, and 5 to accept in writing, because their fixes are cost changes and the cost engagement counts each change once. The readout also recommended that the PostgreSQL 16 upgrade wait for the Multi-AZ cutover on March 22 instead of running in place on a database with no standby, and that is what happened.
Decisions at the readout. The register, issue by issue, with an owner and a week for each; the 5 acceptances to sign; the database upgrade that waits for the cutover; the moderation pipeline rewrite, deferred; and multi-Region active-active, declined.
In the room. The review session on March 5 (90 minutes) with the owners, then the readout on March 6 (60 minutes) with Dev Raman, Noor Castellanos, Kofi Brandvold, and Gwen Tallis.
The acceptances came first. They were signed between March 9 and March 11, each by the person who owns the cost it carries: Lior Haddad, Gwen Tallis, and Yuki Sorensen. Then the network and the backups went in first. NAT gateways moved to three zones, the cache gained replicas in a second zone, and the search domain gained dedicated master nodes. A daily AWS Backup plan began copying recovery points to the vault in tp-backup, where a vault lock means nobody, a compromised administrator included, can delete one early, and to us-west-2 so a Region loss does not take the backups with it.
Quota alarms, budgets with anomaly detection, and cost allocation tags closed their questions too. By the end of the week 4 were closed, 5 accepted in writing, and 16 scheduled, each with an owner and a date.
What closed. Closed: REL02, COST03, COST02, and REL01. Signed: the 5 acceptances.
In the room. The weekly check-in with the sponsor, thirty minutes, and change reviews twice a week through week five, with Kofi Brandvold owning the sequence day to day.
The workload became observable and defensible while it changed: service-level objectives for upload-to-timeline time and playback start with tracing and burn-rate alarms, runbooks with an on-call rotation that names a primary and a secondary, dependency and static analysis in CI that blocks a merge on a high-severity finding, and a data-class standard with a class tag on every bucket, table, and database. The ranking endpoint moved from 2 ml.g5.2xlarge GPU instances to 6 ml.c6i.2xlarge CPU instances on March 18, after a load test held its 99th-percentile latency at 38 ms against a budget of 50 ms.
The serving tiers grew into the zones: the API tier from 6 instances to 9 and the production Kubernetes nodes from 9 to 12, spread across 3 zones so that losing one leaves two thirds of the capacity standing. The week closed with 12 closed, 5 accepted in writing, and 8 scheduled behind proofs that had not yet run.
What closed. Closed: COST01, REL07, SEC11, PERF02, COST04, OPS07, OPS04, and SEC07.
The proofs ran, and each closed the question it named. On Sunday, March 22, in a window from 2:00 to 2:14 AM CDT, production moved from PostgreSQL 13 to PostgreSQL 16 on a new encrypted, private, Multi-AZ instance, read-only for 14 minutes. On March 24, the database, the volumes, and the DynamoDB tables restored from AWS Backup in 52 minutes against a four-hour objective. On March 25, one Availability Zone was taken out of service with no outage, by manual failover. On March 26, the incident process ran end to end, from severity and commander to the message the newsrooms would read. On March 27, 142 console-built resources were imported into the CDK, each one changed since only through a pull request.
That closed the last issue whose fix is a change: 20 closed, 5 accepted in writing, none open. The recovery plan states its numbers by scope, and says what is unproven. Inside us-east-1: 15 minutes of data and a four-hour recovery time. For the loss of the Region: up to 24 hours of data from the daily copies in us-west-2, and a recovery time not yet proven.
What closed. Closed: REL11, REL09, REL13, OPS06, REL10, REL12, OPS10, and OPS05.
Milestone two was saved in the Tool on Monday, March 30, after every fix was verified against live configuration and telemetry. It showed 5 high-risk issues, down from 25: the 5 accepted in writing, as the readout said it would. By pillar, high-risk issues went from the first number to the second: Operational Excellence 5 to 0, Security 2 to 0, Reliability 8 to 0, Performance Efficiency 2 to 1, Cost Optimization 6 to 2, and Sustainability 2 to 2. Questions with no improvements identified went from 11 to 33, and 19 medium-risk issues stay in the improvement plan, outside the guarantee, each with an owner.
The handover on March 31 gave Tidepost 10 runbooks, 4 of them already run end to end in a drill, a test, or the cutover, and a milestone cadence that starts with a third milestone once the cost engagement’s changes land. It also updated the SOC 2 technical map, which lists controls in place on AWS and where the evidence is: 33 of its 35 controls were in place on March 31, against 22 when the Audit handed it over. Vantalect is not the auditor and does not issue, predict, or influence a SOC 2 report. SOC 2 reports are issued by licensed CPA firms. This map lists controls that are in place on AWS, the date each began operating, and where the evidence is; the auditor tests them.
The gate. Every agreed HRI is closed or accepted in writing, verified in milestone two. Verified on March 30: 20 closed by change, 5 accepted in writing, 0 unresolved.
In the room. The handover workshop, two hours, recorded with the attendees’ permission. Across the six weeks, 108 of the 110 consultant hours the engagement caps.
The guarantee counted one thing: every high-risk issue agreed at the week-two readout, closed or accepted in writing, verified in Tidepost’s AWS Well-Architected Tool. Half the fee, $14,875, rode on it. The 5 acceptances were agreed at the readout, before any work began, because their fixes are cost changes and the cost engagement counts each change once. So the Tool still shows them as high risk at week six, and this page says so.
Milestone one against milestone two, across 57 questions: the 5 accepted in writing, each signed by its owner and carrying a named risk.
Of the 25 agreed, each fixed through Tidepost’s pull requests and verified against live configuration and telemetry on March 30.
Questions with nothing left to improve. Medium-risk issues went from 21 to 19, and they sit outside the gate.
Every agreed HRI is closed or accepted in writing, verified in milestone two. Verified in milestone two on March 30: 20 closed by change, 5 accepted in writing, 0 unresolved. The gate was met, and the second half of the fee, $14,875, was invoiced on April 3.
Still to come: the 5 accepted issues wait for the cost engagement, which starts April 6 and takes each one up at its readout on April 17. Tidepost’s own milestone, saved on May 14 after those changes landed, showed 0 high-risk issues and 24 medium-risk issues. It is shown here and was never counted toward this gate.
Want this gate on your own organization?
Book a call about the RemediationA guarantee that counted only what was easy to fix would be easy to meet, so the reports show every call, with the person who made it and the reason: the risks owners accepted in writing, the decisions to leave a risk in place, and the price on the bill of running the workload in more than one zone.
Each fix is a cost change, so its owner signed for the risk and the cost engagement made the change and counted it once. In the Tool each one stays high risk until its change lands, and milestone two shows them that way.
Store raw telemetry in a columnar, partitioned format and point Athena at it, so a query reads only the columns and days it needs. While it waits: Each Athena query keeps scanning raw JSON.
The change. Taken up at the cost readout on April 17; the cost engagement’s change is dated May 6.
Size the GPU endpoints, the notebooks, and the EC2 tiers to measured use. While it waits: Oversized compute keeps running at its current size.
The change. Taken up at the cost readout on April 17; the cost engagement’s change is dated April 27.
Commit to a Savings Plan for the steady compute once it is sized, so the commitment fits what runs. While it waits: Everything keeps billing at On-Demand rates.
The change. Taken up at the cost readout on April 17; the cost engagement’s change is dated April 30.
Scale the GPU endpoints and notebooks to demand instead of running them around the clock. While it waits: GPU endpoints and notebooks keep running around the clock.
The change. Taken up at the cost readout on April 17; the cost engagement’s change is dated April 27.
Set retention on application logs, the telemetry stream, raw telemetry, and the originals. While it waits: Logs, the telemetry stream, and raw telemetry keep growing without limit.
The change. Taken up at the cost readout on April 17; the cost engagement’s change is dated May 6.
A decision to leave a risk in place is part of the plan, not a gap in it. Each names who decided, on what day, and when to look again.
The one-time copy of the originals and holding them in Glacier Instant Retrieval cost more than Tidepost will pay to cover a Region loss, which the plan already treats as the slow case: up to 24 hours of database and DynamoDB data from the daily us-west-2 copies, and a recovery time not yet proven. Accepted in writing as a residual risk under REL13.
Revisit. After the retention schedule (S3-2).
A multi-quarter rewrite of the pipeline that the Trust and Safety team depends on every day. Left as a medium risk (REL04).
Revisit. Tidepost's planning for the third quarter.
Considered and not priced. The drills used manual failover. Left as a medium risk (REL12).
Revisit. After the first full quarter of drills.
The four-hour recovery time is for failures inside us-east-1 and is planned as a restore. For a Region loss Tidepost accepts a restore in us-west-2 from the daily copies, and active-active would double the estate. Declined.
Revisit. Not scheduled.
Redundancy is a cost, and it is deliberate. The designs agreed at the readout added $10,300 a month at list and removed $790, and production’s PostgreSQL 13 Extended Support, $2,336 a month, stopped at the cutover. Staging’s $584 a month continues. The net is $10,094 a month, almost all of it the extra zones, and waiting for the cutover instead of upgrading in place cost production about $1,160 of Extended Support. The five largest additions, and the one saving:
Each of the 2 shards of cache.r6g.4xlarge gains one replica in a second zone (2 replica nodes).
In place. March 11.
The production node group from 9 to 12 m5.4xlarge, four in each of three zones.
In place. March 17.
The API tier from 6 to 9 c6i.4xlarge, three in each of three zones.
In place. March 16.
Traffic between tiers, replicas, and the standby now crosses Availability Zones.
In place. March 17.
A new encrypted, private writer with a synchronous standby in a second zone, cut over on the Sunday 2:00 to 2:14 AM CDT window (14 minutes read-only).
In place. March 22.
2 ml.g5.2xlarge replaced by 6 ml.c6i.2xlarge after a load test with p99 38 ms against a 50 ms budget.
In place. March 18.
The cost engagement starts from the bill with these changes in it, so none of the increase is hidden from the savings it counts.
Every Vantalect engagement runs in a Pavilion workspace, created from the engagement’s template with every week, session, deliverable, and obligation already in place, on the client’s calendar and in its time zone. For this one it would hold the sponsor, the platform lead, the finance owner, and the workload owners, and Charles.
After each session the transcript comes into the workspace, and an agent drafts the summary, the decisions taken, the action items, and a digest for the people who were not in the room, 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.
Each acceptance names who signed, the risk that waits, and the cost change that will close it, so when the sponsor reads milestone two, the issues still showing as high risk are explained by the workspace and not by anyone’s memory.
The database cutover is a task with an owner, a window, and a way back from the readout on. The workspace keeps the plan and what happened side by side, down to the minutes the database was read-only.
Declining multi-Region active-active and deferring the pipeline rewrite are recorded with who decided, on what day, and when to look again, so a later reader finds the reason beside the line.
The restore test and the zone drill each carry a task, an owner, and a result recorded against the objective it was measured against, which is more than a checkmark.
The last tasks hand the runbooks, the improvement plan, and the milestone cadence to Tidepost, each with an owner, and set the next milestone for May 14. Then the workspace closes.
Ten PDFs and 139 pages. Start with the readout; the reading guide shows how the rest fit together. Then read the weeks in order and you have the engagement 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 score, what it means, the agreed register of high-risk issues, the issues to accept in writing, the decisions needed, what the Remediation adds to the bill, and the next four weeks.
tidepost-wa-3-readout.pdf
The agreed HRI register, milestone one, the five HRIs accepted with the cost engagement’s dates, and the next four weeks.
View Review Sponsor Readout and Milestone One in the PDF viewerDownload PDF of Review Sponsor Readout and Milestone One
The full review: every question with its evidence, the register of high-risk issues and the improvement plan of medium-risk issues, and an appendix that repeats each answer as recorded in the Tool, with every best practice not selected.
tidepost-wa-2-review.pdf
Fifty-seven questions answered with evidence, 25 high-risk and 21 medium-risk issues, and the improvement plan.
View Six-Pillar Review: Every Question, Its Evidence, and the HRI and MRI Register in the PDF viewerDownload PDF of Six-Pillar Review: Every Question, Its Evidence, and the HRI and MRI Register
tidepost-wa-2-appendix.pdf
Each question’s selected and missing best practices, as recorded in the AWS Well-Architected Tool.
View Review Appendix: Answers by Question as Recorded in the Tool in the PDF viewerDownload PDF of Review Appendix: Answers by Question as Recorded in the Tool
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-wa-1-workload.pdf
The Brief as a workload in Tidepost’s AWS Well-Architected Tool, its architecture as found, and the evidence gathered.
View Workload Definition, Current-State Architecture, and Evidence in the PDF viewerDownload PDF of Workload Definition, Current-State Architecture, and Evidence
tidepost-wa-4-reliability.pdf
Three zones, AWS Backup to tp-backup, the restore test, the zone drill, and the disaster recovery plan.
View Reliability: Three Zones, Backups, Restore, and Recovery in the PDF viewerDownload PDF of Reliability: Three Zones, Backups, Restore, and Recovery
tidepost-wa-5-operations.pdf
Console-built resources imported into the CDK, canary deployments, SLOs with tracing and alarms, and the incident process.
View Operational Excellence: Code, Deployments, Observability, and Incidents in the PDF viewerDownload PDF of Operational Excellence: Code, Deployments, Observability, and Incidents
tidepost-wa-6-performance-cost-sustainability.pdf
The ranking endpoint moved off GPUs, the cost practices in place, and the five HRIs that wait on the cost engagement.
View Performance, Cost, and Sustainability: What Closed Here and What Moves to the Cost Engagement in the PDF viewerDownload PDF of Performance, Cost, and Sustainability: What Closed Here and What Moves to the Cost Engagement
tidepost-wa-7-milestone.pdf
Milestone two against milestone one, pillar by pillar, and the gate.
View Week-Six Milestone, Pillar by Pillar in the PDF viewerDownload PDF of Week-Six Milestone, Pillar by Pillar
tidepost-wa-8-handover.pdf
The runbooks, the milestone cadence, the SOC 2 technical map as of March 31, and what remains.
View Runbooks, the Milestone Cadence, and Handover in the PDF viewerDownload PDF of Runbooks, the Milestone Cadence, and Handover
The same six weeks and the same gate, in your own AWS Well-Architected Tool, on whichever workload carries your business.
The Review and the Remediation: the workload defined and scored in two weeks, then every agreed high-risk issue fixed as code through your pull requests and verified in a second milestone, with half the fee riding on the result.
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
One AWS account became 9 in four weeks, as the add-on after a Security Audit: production joined without moving a workload, 11 policies landed with no policy-caused denial, and the scan went from 1 of 12 checks passing to 11, plus 1 waived in writing.
Read the case studyTell us which workload carries your business and what prompted the question: an investor, a customer’s vendor review, a near miss, or an outage. You will hear back from Charles within one business day, and the first call is fifteen minutes.
AWS, Amazon Web Services, the AWS Well-Architected Framework, the AWS Well-Architected Tool, 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. PostgreSQL is a registered trademark of the PostgreSQL Community Association of Canada. Kubernetes is a registered trademark of The Linux Foundation. Vantalect is not affiliated with or endorsed by any of them. Tidepost, Inc. and every person named on this page are fictional.
