Cloud engineering decision guide
Cloud architecture review or monthly engineering retainer?
An architecture review helps establish what to change and why. A monthly retainer provides bounded capacity to implement and verify agreed work. Choose based on the uncertainty you need to resolve and the team that will receive the result.
Compare the work, not just the billing model
| Question | Architecture & systems review | Cloud Improvement Retainer |
|---|---|---|
| What do we need? | A technical understanding of the selected environment and a useful order for improvements. | Continued delivery against a defined and prioritized cloud backlog. |
| What is the stated fee? | $6,750 USD for the defined review. | $8,500 USD/month; three-month initial term ($25,500 in retainer fees), plus separately priced onboarding/assessment. |
| How much time? | Planned two-week engagement with approximately 30 total delivery hours. | Up to 40 total hours/month with a three-month initial term, billed monthly. |
| What boundary? | Up to 3 accounts/subscriptions and 2 workloads in the agreed review. | 1 AWS or Azure platform; up to 3 accounts/subscriptions; 1 production workload plus associated nonproduction. |
| What comes out? | Architecture/boundary record, findings with evidence, improvement sequence, and technical readout. | Reviewed changes, agreed validation results, documentation, and weekly/monthly progress records. |
| What should be ready? | A decision to support, relevant evidence/access, and receiving technical owners. | Completed separately priced onboarding/assessment, agreed priorities, approved access, and a change-review path. |
| Who implements findings? | Your team, or a separately scoped follow-on implementation. | The agreed backlog is delivered within monthly capacity and your approval process. |
Prices apply to the defined commercial scopes and are confirmed in a written proposal. Neither model promises that every finding will be fixed or every backlog item completed. Define the boundary, dependencies, and acceptance criteria before work begins.
Choose a review when the next decision is unclear
A review is useful when several symptoms may share an underlying cause. An unreliable release process may involve infrastructure differences, pipeline permissions, missing observability, and unclear rollback ownership. Buying implementation time before examining those dependencies can put effort into the wrong change.
Illustrative decision: an engineering team sees recurring release failures and a growing cloud bill but has no agreed priority list. A bounded review can collect the available evidence, identify the important dependencies, and hand over a sequenced plan. It does not claim a verified saving or a production fix merely because a recommendation was written.
The architecture review page describes the planned scope, process, and deliverables. Decide beforehand who will act on the findings.
Choose a retainer when the backlog is ready for delivery
A retainer fits known work with a practical receiving owner: improving a Terraform module, adding a pipeline check, validating a recovery procedure, or investigating a bounded usage issue. Each item needs a clear result, review path, dependencies, and acceptance checks.
Illustrative decision: a team already has an architecture assessment and a prioritized list of improvements for one workload. It needs senior capacity to prepare changes, run the agreed checks, and document the result. The monthly allowance lets that team sequence work, while weekly discussions make blocked dependencies and remaining capacity visible.
The Cloud Improvement Retainer page explains the 40-hour total allowance, workload boundary, term, reporting, and exclusions. Meetings and analysis are part of that capacity.
Recognize when a different engagement fits
If you need a narrow architectural or Terraform/SRE decision and can implement it yourselves, scoped advisory may be enough. If the work is defined by a hardening requirement, evidence gap, regulated data, or formal review process, discuss regulated-cloud engineering with its own scope and responsibilities.
If you need a major migration, continuous on-call operations, or delivery across a broader platform boundary, describe that requirement directly. A small review or monthly allowance should not be presented as unlimited coverage.
Prepare a short buying brief
- The system: cloud, accounts/subscriptions, workloads, and important dependencies.
- The decision: what is unclear or what delivery outcome you already know you need.
- The evidence: available assessment, diagrams, incident examples, IaC, and access constraints.
- The owners: the scope approver, engineering receiver, and relevant operating/review teams.
- The commitment: timing, procurement route, minimum term, and the complete scope of fees and exclusions to compare.
Use the pricing and engagement models page to compare the proposal structure. The useful outcome of the first conversation is a defensible boundary and delivery plan, even when that means choosing a smaller engagement.