All service lines

CLOUD & DEVOPS

Cloud & DevOps on AWS, Azure and Google Cloud, built as code, run against evidence.

Terraform-defined infrastructure, GitOps delivery with DevSecOps gates, Kubernetes on EKS, AKS or GKE, and FinOps that attributes every workload's spend to an owner. India regions by default for data residency.

Request a cloud cost auditTalk to an engineer

Runs on

  • AWSMumbai · ap-south-1
  • Microsoft AzureCentral India · Pune
  • Google CloudMumbai · asia-south1

Certified·ISO/IEC 27001·ISO 9001·ISO/IEC 20000·ISO/IEC 42001·Startup India·MSME

4 active engagements·India and the UK·See them

Cost optimisation, done as engineering

A cloud cost audit reads the architecture and the bill together, and writes the answer as code.

  1. 01

    Every resource resolves to an owner.

    Three tag keys — environment, owner, cost centre — applied through Terraform so they cannot be forgotten. A line of the bill with no owner is a finding, not a rounding error.

  2. 02

    Spend is attributed per workload, not per account.

    An account total tells a CFO what was spent. A per-workload view tells an engineer what to change. The audit produces the second.

  3. 03

    Findings ship as infrastructure changes.

    Rightsizing, schedules and commitment reviews come back as reviewed Terraform pull requests, so a recommendation is a diff someone can approve rather than a slide.

Attribution ledger · one line per workload
Illustrative

  1. prod-api

    EKS

    env=prodowner=platformcost-centre=CC-104

    Resolves toPlatform

    Attributed

  2. genomics-batch

    AWS Batch

    env=prodowner=bioinfcost-centre=CC-211

    Resolves toBioinformatics

    Attributed

  3. reporting-db

    RDS

    env=prodowner=datacost-centre=CC-118

    Resolves toData

    Attributed

  4. nat-egress

    NAT Gateway

    env=prodshared=true

    Resolves toSplit by traffic share

    Allocated

  5. legacy-etl

    EC2

    no tags

    Resolves to—

    Untagged

An untagged line is the first finding of every audit: spend with no owner is spend nobody is optimising. Shared infrastructure is allocated by a rule you can read, not averaged away.

How a change ships

How a change reaches production: seven stages, two of which can stop it.

How a change reaches production: commit, build and test, scan, plan, sync, run, observe.

Every stage leaves an artefact: a scan report, a reviewed plan, a sync record, a dashboard. That is what makes the pipeline auditable under ISO/IEC 27001 controls, and it is what a reviewer sees when they ask how a change got to production.

  1. Commit (Version control). Protected branches, review required, every change traceable to a person. Tools: GitHub.
  2. Build & test (CI/CD). Tests run, the container image is built once and promoted unchanged. Tools: GitHub Actions.
  3. Scan (DevSecOps). SonarQube for code quality and static analysis; Trivy for image, dependency and IaC vulnerabilities. Tools: SonarQube, Trivy. Gate: A critical finding blocks the merge.
  4. Plan (Infrastructure as code). Terraform plan reviewed in the pull request; policy checks run before apply. Tools: Terraform. Gate: Apply needs an approval.
  5. Sync (GitOps). Argo CD reconciles the cluster to the repository. Drift is a diff, not a surprise. Tools: Argo CD, Helm.
  6. Run (Kubernetes). Rollouts on EKS, AKS or GKE with health checks. A rollback is a revert. Tools: Kubernetes.
  7. Observe (Monitoring). SLO alerts and dashboards over CloudWatch, Azure Monitor or Cloud Monitoring, with on-call that reaches an engineer. Tools: Prometheus, Grafana.

What we build

Six disciplines, and what each one means here.

  • Cloud architecture and landing zones

    Accounts, networks, identity and guardrails as Terraform, on whichever cloud you run.

    AWS Organizations, Azure management groups or Google Cloud folders · VPC and VNet design · KMS and secrets

  • Migration and re-architecture

    Lift-and-shift where it is right, rebuild to cloud-native where it pays, with a reconciliation step before cutover.

    EKS, AKS or GKE · serverless · managed databases · DMS and Database Migration Service

  • Kubernetes platforms

    Clusters with autoscaling, ingress and health-checked rollouts, where a rollback is a revert.

    EKS · AKS · GKE · Helm · Argo CD

  • CI/CD, GitOps and DevSecOps

    Build once, scan, promote the same artefact, reconcile the cluster to the repository. A critical finding blocks the merge.

    GitHub Actions · SonarQube · Trivy · Argo CD · protected branches

  • FinOps and cost optimisation

    Spend attributed per workload, and findings shipped as Terraform changes rather than slides.

    Tagging policy · rightsizing · schedules · commitment reviews

  • Monitoring and SRE

    SLO-based alerting and on-call that reaches an engineer, with a monthly review of what the platform costs and why.

    Prometheus · Grafana · CloudWatch, Azure Monitor or Cloud Monitoring · DR runbooks and tested restores

How we work with you

Start with the audit. Everything after it is optional.

  1. 011–2 weeks

    Cloud cost audit

    A senior engineer reads your architecture and your cloud bill together. No commitment to engage further.

    You leave with

    A written remediation plan and a bill where every line has an owner.

    Request a cloud cost audit
  2. 028–16 weeks

    Cloud migration or re-architecture

    Lift-and-shift or rebuild to cloud-native: Terraform landing zone, Kubernetes or serverless, CI/CD and GitOps wired from the first week.

    You leave with

    A Terraform-defined platform with the delivery pipeline live and gated.

  3. 03Ongoing

    DevOps and SRE retainer

    On-call coverage, IaC ownership, security scanning kept in the pipeline, and a FinOps review every month.

    You leave with

    An engineer on call, and a monthly review of what the platform costs and why.

Five phases, and the artefact a platform needs at each one.

The full process
  1. 01

    Discovery & Strategy

    1-2 weeks

    Architecture and bill review with a written remediation plan

    Signed off by you, before engineering starts

  2. 02

    Architecture & Design

    2-3 weeks

    Landing-zone design and Terraform module plan, reviewed with your security team

    Signed off by your security team

  3. 03

    Agile Development

    4-12 weeks

    Terraform, pipeline and cluster definitions with the review trail

    Signed off by a senior engineer, every PR

  4. 04

    Quality Assurance

    2-4 weeks

    Disaster-recovery test record, security scan reports and load-test results

    Signed off by your QA and compliance teams

  5. 05

    Launch & Evolution

    Ongoing

    Dashboards, SLO alerts and the monthly cost review

    Signed off by your team, every week

For a migration or a platform build. The audit runs on its own one-to-two-week cadence. Every phase ends with a named artefact and a named sign-off, under ISO/IEC 27001 and ISO 9001 controls.

Recent work on this line

Two engagements running on this line now.

  • Healthcare / Diagnostics

    Active engagement

    AWS Mumbai architecture and CI/CD for a diagnostics-lab platform

    • AWS Mumbai
    • CI/CD
    • India data residency

  • Life Sciences

    In active development

    AWS Batch genomics pipeline supporting InferaGen.ai

    • AWS Batch
    • Genomics pipeline
    • From the Lab

How we work

Built like a product company, shipped like one.

  1. 01

    Audit-engineered by default

    Every engagement runs under ISO/IEC 27001, ISO 9001, ISO/IEC 20000, and ISO/IEC 42001 controls. DPDP-aligned, with HIPAA / GDPR / RBI overlays available per project.

  2. 02

    Founder-led delivery

    Your discovery call is with a founder. The architecture review is with a senior engineer who stays on the project. No body-shop, no offshore handoff, no account-manager translation layer.

  3. 03

    Bias to ship, not slide

    We don't write demos that can't survive a Friday production deploy. Every milestone produces an artifact your team can use immediately: code, diagrams, telemetry.

Questions buyers ask

Straight answers, before the first call.

Which clouds do you work on?
AWS, Microsoft Azure and Google Cloud. India regions by default for data residency: AWS Mumbai (ap-south-1), Azure Central India (Pune) and Google Cloud Mumbai (asia-south1). The same Terraform, GitOps and DevSecOps disciplines apply on all three; the managed services differ and the coverage list on this page names them.
What does a cloud cost audit actually produce?
A bill where every line resolves to an owner, a per-workload attribution rather than an account total, and a written remediation plan whose findings arrive as reviewed Terraform pull requests. It takes one to two weeks and carries no commitment to engage further.
Who owns the Terraform when you leave?
You do. It lives in your repository, applies against your accounts, and its state is in your backend. The retainer keeps an engineer on it; ending the retainer changes nothing about where it lives.
How do you keep our data in India?
Region pinned in the landing zone and enforced by policy: AWS Service Control Policies, Azure Policy or Google Cloud organisation policies deny resources outside the chosen region. Backups and logs stay in-region too, and the DPDP Act controls are drawn into the architecture diagram your security team reviews.
Can you take over an existing platform rather than build a new one?
Yes, and most retainers start that way. The audit reads what is there first; the retainer then brings the platform under Terraform incrementally, adds the scanning gates to the existing pipeline, and puts an engineer on call for it.

Insights

Reading on cloud & DevOps.

Engineering notes on cloud & DevOps, written by the engineers on the work.

All insights

Want your cloud bill read line by line?

A senior engineer reads your architecture and your bill together, then hands over a written remediation plan. No commitment to engage further.

Request a cloud cost auditEmail hello@orbitnexa.com
+91 912-195-7728Hyderabad, IndiaEvery brief gets a senior review. Reply within 1 business hour, 9 AM-7 PM IST.