Cloud environments your own team can run on Monday morning.
We plan, build, migrate and run AWS, Azure and Google Cloud environments in Terraform. Early on, we also decide how every pipeline, pod and VM proves who it is. Nothing should depend on an access key someone pasted into a secrets store.
Cloud engineering is the design, build and operation of the infrastructure your applications run on.
Cohash plans cloud strategy, migrates workloads to AWS, Azure and Google Cloud, builds landing zones and pipelines in Terraform, and runs day-two operations and cost reporting. We replace stored cloud keys with workload identity federation, so pipelines and services authenticate with short-lived tokens.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Cloud Engineering, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · where you end up
incident board · cloud engineering3 open
openCloud accounts were opened team by team and nobody can say which guardrails apply to which one.
recurringPipelines still deploy with access keys someone created years ago, and nobody has rotated them since.
blockedThe monthly cloud bill arrives and no one can tie the spend to an application or owner.
exposure
Strategy and landing zonesMigrationOperations and cost controlDevSecOpsWorkload identity
ready to hand over
Every account reports to one trail and sits under one set of guardrails.
Finance reads one monthly report with both clouds in the same columns.
chapter 01 · where it hurts
Why teams reach out
Cloud accounts were opened team by team and nobody can say which guardrails apply to which one.
Pipelines still deploy with access keys someone created years ago, and nobody has rotated them since.
The monthly cloud bill arrives and no one can tie the spend to an application or owner.
chapter 02 · what we change
How we solve it
Strategy and landing zones
Migration
Operations and cost control
DevSecOps
Workload identity
chapter 03 · where you end up
What changes
Every account reports to one trail and sits under one set of guardrails.
Finance reads one monthly report with both clouds in the same columns.
what we do
Where we spend the hours
5 areas of work, each one done by an engineer who has run it in production.
A decision for each workload (rehost, replatform, refactor, replace or retire), plus the account structure, network layout and policy guardrails it will land in.
Dependency maps, wave plans and rehearsed cutovers with a tested rollback. On AWS we plan in AWS Transform, which AWS points to now that Migration Hub is closed to new customers.
We tie monitoring to runbooks, schedule patching and time restore tests, and cost reports come in the FinOps FOCUS format so bills from different clouds line up column for column.
Build pipelines that scan, sign and deploy. Put the checks in the pull request, where developers will actually see them.
GitHub Actions, Kubernetes pods and VMs get short-lived credentials through OIDC federation. We use Entra workload identity federation, Google Cloud Workload Identity Federation, EKS Pod Identity, and IAM Roles Anywhere for servers outside AWS.
capability 01 / 05in production
Strategy and landing zones
A decision for each workload (rehost, replatform, refactor, replace or retire), plus the account structure, network layout and policy guardrails it will land in.
Dependency maps, wave plans and rehearsed cutovers with a tested rollback. On AWS we plan in AWS Transform, which AWS points to now that Migration Hub is closed to new customers.
We tie monitoring to runbooks, schedule patching and time restore tests, and cost reports come in the FinOps FOCUS format so bills from different clouds line up column for column.
GitHub Actions, Kubernetes pods and VMs get short-lived credentials through OIDC federation. We use Entra workload identity federation, Google Cloud Workload Identity Federation, EKS Pod Identity, and IAM Roles Anywhere for servers outside AWS.
We pieced these together from Cloud Engineering situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Forty AWS accounts opened by teams, a third outside AWS Organizations
composite · not a client story
Beforethe situation
Product teams opened AWS accounts over several years. About forty exist, a third sit outside AWS Organizations, console IAM users with passwords are common, and CloudTrail is on in some accounts and off in others.
What we dothe work
Invite the stray accounts into Organizations and turn on an organization trail first. Then group accounts into OUs by environment, apply a short SCP set (deny leaving the org, deny stopping CloudTrail, region limits) and move console users to IAM Identity Center behind Entra ID or Okta.
Afterwhere you end up
Every account reports to one trail and sits under one set of guardrails. People sign in through the corporate identity provider, and new accounts come out of a Terraform pipeline with the baseline already applied.
case file 02
Azure under an Enterprise Agreement, data platform on AWS, two invoices
composite · not a client story
Beforethe situation
Microsoft workloads run in Azure, the data platform runs in AWS, and finance gets two invoices in two formats. Tag keys differ between the clouds, so nobody can show spend per application or per owner.
What we dothe work
Agree a tag schema with finance covering application, owner, environment and cost center. Enforce it with Azure Policy and AWS tag policies, switch both clouds to FOCUS-format cost exports, load them into one table and build showback by application. Untagged spend gets its own line.
Afterwhere you end up
Finance reads one monthly report with both clouds in the same columns. Application owners see their own spend, and untagged resources show up on the report with a name next to them.
How a cloud estate fits together from code to running workloads
Engineers change infrastructure through Terraform in a pipeline that authenticates to the cloud with short-lived OIDC tokens. The landing zone applies guardrails to every account, and operations feeds cost, drift and alert data back to owners.
Put these to anyone bidding on your Cloud Engineering work. The ones who've done it answer differently from the ones who've read about it.
Q1
Will the landing zone be Terraform we own outright, or an accelerator we license from you?
Some partners deliver landing zones as a proprietary accelerator. If the code, state files and pipeline don't transfer cleanly, every later change goes back through the same partner.
Q2
Where are the long-lived cloud keys today, and what replaces each one?
Keys stored in CI or on servers are a common way into a cloud account. A partner should name the federation pattern per platform: Entra workload identity, GCP Workload Identity Federation, EKS Pod Identity or IAM Roles Anywhere.
Q3
Which SCPs or Azure Policy assignments will block something our teams do today?
Guardrails that break a running deployment get switched off within a week. Ask to see the policy set run in audit mode against your accounts before anything is enforced.
Q4
Who's going to hold break-glass access to the management account, both during the work and after it?
The organization's management account, or a tenant Global Administrator, can undo every guardrail you build. Make sure the handover names who holds those accounts, requires phishing-resistant MFA, and alerts on every single use.
Q5
How will you show that the Terraform matches what is actually running?
People will make console changes during a build-out. That's normal. A scheduled plan against every environment turns that drift into a diff someone reviews, so it doesn't ambush you at the next apply.
01Which cloud should we standardize on?
Usually the one your team, your identity provider and your main software vendors already support well. We compare clouds on the workloads you actually run, looking at licensing terms, the managed services you need, data residency and where your data platform lives. A second cloud is worth it for specific workloads, rarely as a default.
02Do you work on AWS, Azure and Google Cloud?
Yes. Terraform is what we write infrastructure in across all three, although we use CloudFormation or Bicep when your team already standardizes on them.
03What drives the cost of a cloud engagement?
Mainly the number of workloads, how tangled their dependencies are, your compliance scope and whether you want us to operate the environment afterward. A short discovery gives us enough to estimate honestly.
04Can you take over an environment another firm built?
Yes. We start with a review of infrastructure-code drift, IAM roles and service principals, network rules and spend, then agree what to fix first.
05Can you build on our existing AWS Control Tower or Azure landing zone?
Yes. Most estates already have something in place. We review what it actually enforces, extend it in Terraform where it falls short, and avoid rebuilding accounts and subscriptions that already work.
related
Often paired with
Projects on Cloud Engineering usually end up touching one of these, so they're worth a look.
