Cloud consulting · Defined scope and accountable delivery
Cloud architecture and systems review for AWS or Azure
Find the changes worth making before committing to a larger implementation. Flat Spell reviews the selected cloud environment, documents the evidence behind its findings, and helps your team choose a practical next delivery.
$6,750USD for the stated architecture review scope
- Planned delivery
- Two weeks
- Delivery allowance
- Approximately 30 total hours
- Cloud boundary
- Up to 3 accounts/subscriptions
- Workload boundary
- Up to 2 workloads
When a review is the right starting point
Your infrastructure may be running, yet the next investment remains unclear: recurring deployment failures, noisy alerts, unexplained cloud costs, or a growing list of security findings. A review is useful when those concerns span several systems and your team needs an independent technical view before choosing work.
Bring a bounded AWS or Azure environment and the business decision the review must support. We agree the workloads, account/subscription access, operational questions, and receiving owners before the delivery window begins. The written scope confirms the schedule and how unavailable evidence or access will be handled.
The review boundary
The stated review fee is $6,750 USD. The written proposal confirms the workload boundary, deliverables, schedule, and fee before work starts. Production implementation and broader investigations are separately scoped.
The starting engagement is planned over two weeks with approximately 30 total delivery hours, covering up to three cloud accounts or subscriptions and two workloads. Preparation, analysis, discussions, and reporting all use that delivery allowance. The review starts with the agreed evidence and access ready.
| Area | Evidence to examine | Decision to support |
|---|---|---|
| Architecture and dependencies | Resource inventory, data flows, network boundaries, service dependencies, and environment differences. | Which dependency or design issue should be addressed first? |
| Infrastructure and delivery | Terraform/Bicep or other IaC, pipeline definitions, recent deployment failures, and change/rollback procedures. | Where can a controlled change reduce delivery risk? |
| Reliability and operations | Alerts, incident patterns, recovery procedures, logs/metrics, and operational ownership. | Which failure path needs better detection, recovery, or accountability? |
| Cost and resource use | Available billing/usage records, resource sizing, ownership, and workload constraints. | Which opportunities merit validation before changing capacity or commitments? |
We select the questions that fit the boundary and time allowance. A focused review does not inspect every cloud feature, application line, or control in a regulatory baseline. If the environment needs broader discovery, agree that scope before proceeding.
How the two-week review runs
- Frame the decision: confirm the workloads, constraints, stakeholders, and evidence sources. Use appropriately scoped access and approved handling for configuration, logs, and architecture records.
- Inspect the implementation: trace the selected systems and compare documented intent with available configuration and operating evidence. Keep observations distinct from assumptions or untested hypotheses.
- Prioritize findings: describe the affected system, business consequence, supporting evidence, recommended next step, and dependencies. Identify where a runtime test or further investigation is still needed.
- Read out and hand over: walk through the findings and improvement sequence with the receiving team. Decide which items they will own, which need a separately scoped implementation, and which remain open questions.
What your team receives
A boundary and architecture record
A concise account of the reviewed workloads, important dependencies, and scope limits, with a diagram where it helps explain the implementation.
An evidence-backed findings register
Each finding records what was observed, why it matters, the evidence available, and an actionable next step. Missing evidence stays visible.
A prioritized improvement plan
A sequence of candidate changes with dependencies, likely effort considerations, proposed owners, and acceptance checks to refine before implementation.
A technical readout
A discussion of decisions and tradeoffs so your engineers can challenge assumptions and take ownership of the next work.
These are review deliverables. Production fixes, migrations, penetration testing, formal compliance assessment, and authorization decisions need their own agreed scope. No cost saving or regulatory outcome is guaranteed by a findings report.
What to prepare before requesting a proposal
- The cloud platform, account/subscription count, and the workloads you want reviewed.
- The decision or recurring problem you need the review to resolve.
- Available diagrams, infrastructure repositories, billing/usage records, incident examples, and access constraints.
- The person who can approve the scope and the engineering owner who will receive the findings.
- Any regulated-data, cloud eligibility, procurement, or scheduling requirements.
Describe the environment in the initial inquiry. We can arrange an appropriate evidence-sharing method after the boundary is agreed.
Choose the next engagement from the findings
If your team can implement the recommendations, the review can end with the handover. If it needs continued engineering capacity, the Cloud Improvement Retainer provides a bounded monthly backlog and progress reporting. A hardening or evidence-producing workflow can instead be scoped through regulated-cloud and compliance automation engineering.
Compare the options in architecture review versus monthly retainer or see the engagement and pricing approach. A review does not commit you to a follow-on retainer.