Cloud and platform engineering
AWS and Azure landing zones that pass an audit.
Multi-account or multi-subscription landing zones, network and identity baseline, CI/CD, IaC standards, secrets, observability and cost engineering. Every application in Techtons deploys onto this baseline.
The premise
The unglamorous layer everything else stands on. A landing zone, an identity baseline, a deployment path and the observability to know what is happening. Every application in Techtons deploys onto this shape, which is why our replacement projects do not spend their first month arguing about accounts and networks.
Reference implementations
The AWS and Azure architectures in every library entry assume this baseline. Watchtower is the observability reference implementation and Conduit is the integration backbone.
What you get
- A multi-account AWS organisation or multi-subscription Azure tenant with the account structure, guardrails and service control policies written down and applied as code.
- Network and identity baseline: private connectivity, egress control, workload identity federation, and no long-lived cloud credentials anywhere in a pipeline.
- Terraform or Bicep module standards, a module registry, and the review conventions that keep them from rotting.
- A deployment path from commit to production with environment promotion, artefact signing and a rollback that has been used at least once in anger.
- Secrets management, certificate lifecycle and rotation that does not depend on somebody remembering.
- Observability with real service level objectives: metrics, logs, traces, alerts that fire on symptoms rather than causes, and dashboards owned by the teams that get paged.
- Cost engineering: tagging enforced at deploy, per-team allocation, budget alerts, and a written review cadence.
How it runs
5 phases, each with a date attached.
Durations below are what this shape of work typically takes with a team of two to four. They move with scope, and the assessment is where they stop being typical and start being yours.
- 01
Current state and target
2 weeksWhat exists, what is undocumented, what compliance obligations bind you, and where the organisation is genuinely trying to go. Ends with a target architecture and a sequencing plan that does not require a freeze.
- 02
Landing zone build
3 to 5 weeksAccounts or subscriptions, network, identity, guardrails and the pipeline, all as code in your repository. Delivered with a non-production environment you can break.
- 03
First workload migration
2 to 4 weeksOne real workload onto the new baseline, chosen because it is representative rather than because it is easy. This is what turns the platform from a design into something with users.
- 04
Paved road and enablement
3 to 4 weeksTemplates, module library, golden pipelines and the documentation your teams will actually read. Two or three teams onboarded with us in the room so we can see where the road is not paved.
- 05
Handover
2 weeksRunbooks, an on-call model, a decision log and an owner for each part of the platform. Platform work fails when it has no owner, so this phase ends with names against components.
What it costs
No rate card on this page, on purpose.
Priced per phase and sequenced so you can stop after any of them with something useful in your hands. A landing zone alone is a coherent deliverable; so is a landing zone plus one migrated workload.
Two things move the number more than anything else: whether you are starting clean or inheriting several years of accounts nobody wants to touch, and how much regulatory evidence the platform has to produce. Greenfield with no formal compliance regime is a fraction of a regulated brownfield estate with an existing audit finding, and we will not pretend otherwise in a proposal.
Cloud spend is yours, billed directly by AWS or Azure with no margin from us. The cost engineering work usually reduces it, and we will show you the before and after rather than claiming a percentage.
A published day rate would be a number we could not stand behind for your specific situation, and every firm that publishes one quotes something different in the room. What we will commit to before you sign is the phase scope, the phase price and the team shape. Use the calculator for the replacement arithmetic against your own seat count.
Normally bought inside
Guide
You have a dev team. We hand them the blueprint.
Fixed monthly. 3-month minimum.
Deliver
We take it end to end and hand over the keys.
Fixed price per phase. Run priced separately.
When not to buy this
3 reasons to walk away.
Every library entry has rows where the honest answer is no. Every service page has this section for the same reason: the cases below are ones we have seen go badly, and we would rather lose the work than deliver into them.
You have one application and no plans for another
A landing zone is amortised over many workloads. For a single system, a well-structured single account and a good pipeline is the right answer, and it costs a lot less.
You already have a platform team who are doing fine
If your platform team can tell you their SLOs, show you the module registry and describe the last rollback, they do not need us. Possibly they need a second pair of hands for a specific piece, which is Join, not this.
There is no agreement on the cloud provider
If that decision is still being fought over at executive level, a landing zone built now will be rebuilt. We can help you make the decision, but we will not start building underneath it.
Pick one contract. We will show you the replacement.
A two-week assessment: we take your single most expensive SaaS line item, establish what you actually use, and come back with a parity matrix, an architecture for AWS and Azure, a cost model and a delivery plan. Fixed price. If the answer is keep buying it, we will tell you that.