Atmora Tech

Cloud & Platform

Cloud you can still
explain in year three

We design the account structure, network edges and cost guardrails that decide what your cloud costs and how fast it moves three years from now. The work is unglamorous, written down, and it holds up after the team that built it moves on.

Overview

Landing zones, account structure and cost guardrails, designed before workload one.

Most cloud problems are not technical failures. They are the compound interest on decisions taken in the first six weeks: one flat account, IAM policies written by copy-paste, a VPC that cannot be resegmented without downtime. We start where those decisions are made, and we write them down so they can be argued with later.

A typical engagement produces a multi-account landing zone with an identity boundary, a network topology sized for the traffic you actually have, tagging that finance can reconcile against a bill, and a small set of paved paths covering perhaps 80 per cent of workloads. Everything else gets an exception process rather than a workaround.

We build against your real constraints rather than a reference diagram: the data centre lease running to 2029, the mainframe that will not move, the regulator requiring data residency in-country. Cloud that ignores those constraints tends to be quietly bypassed within a year, usually by the teams under the most delivery pressure.

31%
lower monthly cloud spend within two billing cycles
4.5 days
median time to a production-ready account, down from six weeks
97.2%
of resources tagged to a named cost owner after enforcement

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Landing zone and account design

    Multi-account structure, organisational units, service control policies and a break-glass path. Built so a new team can be onboarded in days without a security review of the whole estate.

  • Network and connectivity architecture

    Hub-and-spoke or mesh topologies, private connectivity back to the data centre, DNS that resolves the same way in every environment, and address space planned for the next five acquisitions.

  • Identity and access boundaries

    Federated identity, role design against actual job functions, and permission boundaries that stop privilege creep. Access reviews that produce a diff rather than a spreadsheet nobody reads.

  • FinOps and cost engineering

    Tagging enforced at provisioning, showback by team, commitment planning across savings plans and reserved capacity, and monthly variance analysis that names the workload behind each spike.

  • Resilience and continuity design

    Failure domain mapping, recovery objectives agreed with the business rather than assumed, and restore drills run against production-shaped data, not just replicated backups nobody has opened.

  • Reference architectures and guardrails

    Terraform modules and policy-as-code for the shapes you build most often, with automated checks in the pipeline so a non-compliant resource fails at plan time rather than at audit.

Deliverables

What you get

  • Landing zone implemented in Terraform, with a versioned module registry
  • Network topology and IP address allocation plan
  • Identity model, role catalogue and access review procedure
  • Cost allocation model with tagging policy and enforcement rules
  • Recovery objectives register and tested runbooks per service tier
  • Architecture decision records covering every non-obvious choice

Stack

What we build it with

  • Terraform
  • Terragrunt
  • AWS Control Tower
  • Azure Landing Zones
  • Open Policy Agent
  • HashiCorp Vault
  • Kubernetes
  • Crossplane
  • Datadog
  • Infracost
  • Cloudflare
  • GitHub Actions

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Estate and constraint review

    Two to three weeks reading what exists: bills, network diagrams, IAM dumps, incident history. We map the constraints before proposing anything at all.

  2. Target architecture and trade-off review

    We present two or three viable designs with their costs and failure modes, then run a written challenge session with your architects before anything gets built.

  3. Foundation build

    Landing zone, network, identity and guardrails delivered as versioned Terraform, with a pipeline your engineers can run without us in the room.

  4. Pilot workload

    One real service moves onto the foundation. It finds the gaps a design review never will, and the fixes go straight back into the shared modules.

  5. Handover and operating model

    Runbooks, on-call structure, a cost review cadence and a named owner for each guardrail. We stay through one full billing cycle after handover.

When this is the wrong engagement

If you run fewer than about a dozen services in a single account and carry no compliance obligations, a foundation engagement is over-engineering and the money is better spent on the product.

FAQ

Questions we get asked

Do we have to standardise on a single cloud provider?

No, and we usually advise against forcing it. The workable pattern is one primary provider for the bulk of workloads and a documented reason for anything sitting elsewhere: data residency, a licensing term, an acquired business. Portability for its own sake costs more than it returns.

How much of this can our own team run afterwards?

All of it, and that is the design goal. Modules, pipelines and runbooks are written for your engineers rather than for us, and handover includes pairing on the parts people usually get stuck on: policy exceptions, network changes and cost anomaly triage.

What if we already have a landing zone that is half-built?

That is the common case. We assess what can be kept, what needs re-founding and what should simply be documented and frozen. Rebuilding an account structure is disruptive, so we only recommend it when the alternative is a permanent exception queue.

How do you control cost without slowing delivery down?

Guardrails at provisioning time rather than approval gates. Teams get a budget, a set of pre-approved instance families and storage classes, and an alert when a workload deviates from its own baseline by more than 20 per cent. Exceptions go to an architect, not a committee.

Related

More in Cloud & Platform

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project