Service line 05 of 06

Cloud Data Solutions

Data infrastructure on AWS, Azure and Google Cloud, written as code, with access through your identity provider and costs reported by team and workload.

Where the cloud account gets in the way

Security and cost problems in the cloud account show up in the data platform on top of it.

  • The platform was built by hand in the console, and nobody could rebuild it.

    We import it into Terraform or rewrite it there, so every environment is defined in code and changed through pull requests.

  • Engineers share admin accounts, and access stays when people leave.

    Roles map to groups in your identity provider, with least privilege and no shared credentials, so removing a person removes their access.

  • The cloud bill jumped and nobody can say which workload caused it.

    Tags, budgets and a cost report by team and workload, with alerts when spend leaves its usual range.

  • Development, test and production have drifted apart, so releases break in production.

    Every environment is built from the same modules with its own variables, and CI/CD shows a reviewed plan before each change.

  • Auditors ask where personal data is stored and who can read it.

    We document where data lives and how it is reached, switch on audit logging, and keep data in the regions your rules require.

What we set up in your accounts

Everything here ends up as code or documents in your organisation, not in a vendor account.

  1. Landing zones and IaC

    Accounts or subscriptions, networking, storage and compute for the data platform, as Terraform modules deployed through CI/CD.

    You receive

    • Terraform repository with modules
    • Pipeline that plans and applies changes
    • Environment diagram
  2. Identity and access control

    Roles and groups through your identity provider, service identities for pipelines, secrets in a managed vault, and audit logs kept where you need them.

    You receive

    • Access model per role
    • Joiner and leaver procedure
  3. FinOps reporting

    Tagging rules, budgets, cost allocation by team and workload, and a review of idle resources and reserved capacity.

    You receive

    • Cost dashboard by team
    • Budget alerts
    • Savings recommendations
  4. Containers and runtime

    Kubernetes clusters for the workloads that need one, such as model serving or a self-hosted Airflow, with autoscaling and monitoring.

    You receive

    • Cluster configuration in code
    • Monitoring and alert rules

Clouds and infrastructure tools

We work in the cloud you already run. Terraform covers all three, so the same practices apply whichever one it is.

Listing a technology does not imply a vendor partnership or certification.

Cloud

  • AWS
  • Microsoft Azure
  • Google Cloud

Infrastructure & delivery

  • Terraform
  • GitHub Actions
  • Kubernetes

Data governance

  • Microsoft Purview
  • Unity Catalog

What the infrastructure repository holds

At handover the platform is a repository your team can read, review and change like application code. A pipeline posts a plan on every pull request and applies it only after review.

An illustrative example, not client data.

Terraform state and credentials live in your accounts, not ours.

infra/Example
infra/
├── modules/
│ ├── network/
│ ├── storage/
│ ├── lakehouse_workspace/
│ ├── identity/ # roles from your IdP groups
│ └── monitoring/
├── envs/ # same modules, own variables
│ ├── dev/
│ ├── test/
│ └── prod/
├── policies/ # tags, regions, encryption
├── .github/workflows/
│ └── plan-and-apply.yml # plan on PR, apply on review
└── runbooks/
├── add-a-team.md
├── add-a-data-source.md
├── rotate-a-secret.md
└── restore-from-backup.md

Questions about cloud data platforms

Not answered here? Ask in the request form.

We already have a cloud team. Where do you fit?

Around the data platform. We work inside your landing zone and naming rules, and your cloud team reviews our pull requests.

Can you bring hand-built resources under Terraform without breaking them?

Yes. We import what exists and adjust the code until the plan shows no changes. Only then do we start changing anything.

We run more than one cloud. Is that a problem?

No. We keep shared modules and naming conventions across AWS, Azure and Google Cloud, so the setups stay alike and one team can look after them.

How do you cut costs without slowing things down?

We start with waste: idle compute, oversized warehouses, data nobody reads. Anything that could affect performance is tried outside production first and checked against the cost report.

Who holds the admin credentials?

You do. Our engineers get named, least-privilege accounts through your identity provider, and you can review or revoke each one at any time.

Discuss your cloud

Bring the accounts in scope, a recent bill if you can share it, and any audit or compliance dates coming up.

How it runs: a call (30 minutes with a senior engineer), an assessment and written plan, the build with weekly demos, then handover or run. Our delivery standard