Cloud infrastructure designed around your workload and your bill
Cloud architecture is mostly a series of cost decisions disguised as technical ones. Get them right early and the platform grows with you. Get them wrong and you spend three years paying interest on them.
What is cloud infrastructure?
Cloud Infrastructure is the architecture, provisioning and cost management of the compute, storage, networking and deployment pipelines an application runs on. It covers infrastructure as code, autoscaling, disaster recovery and spend control. It suits Australian organisations whose systems have outgrown a single server, or whose cloud bill has grown faster than their traffic.
Get a fixed written quote- Typical timeline
- 5 to 12 weeks
- What drives cost
- Our engagement cost is driven by the number of environments, how many workloads are migrating.
- Best for
- Applications outgrowing a single server, or cloud spend growing faster than usage
- You own
- The cloud accounts, the infrastructure code and the deployment pipelines
- Built with
- Terraform, autoscaling, Sydney and Melbourne regions, tested disaster recovery
Your handover
Architecture decisions that set your bill for the next three years
A handful of early choices determine most of what you will pay and most of what will be painful later. Whether state lives in the application or in a managed database. Whether services talk synchronously or through a queue. Whether the workload is genuinely spiky or merely feels that way. Whether you need multiple availability zones because downtime has a measurable cost, or you are buying resilience against an event that would inconvenience you for an hour a year.
- 01Target architecture with documented failure modes
- 02Terraform modules for every environment
- 03Automated build, test and deploy pipeline
- 04Autoscaling policies tuned to your traffic shape
- 05Identity, access and network guardrails
- 06Centralised logging, metrics and alerting
- Disaster recovery plan with measured recovery times
- Cost dashboard, resource tagging and budget alerts
- Runbooks and a handover walkthrough for your team
The failure mode we see most often is architecture chosen for a scale that never arrives
The failure mode we see most often is architecture chosen for a scale that never arrives. A business with two hundred concurrent users running a container orchestration platform across three zones, paying for the complexity of an organisation a hundred times its size, and requiring a specialist to deploy a change. The opposite failure is real too: an application on one oversized virtual machine, deployed by copying files, with a database on the same box and no way to grow except buying a bigger box. Our job during design is to work out which trap you are closer to and build for the traffic you actually have, with a documented path to the next tier when the numbers justify it.
Rebuilding a region from scratch becomes an operation measured in hours instead of days.
Disaster recovery that has been rehearsed, not just written
Two numbers drive every disaster recovery design. Recovery time objective is how long you can be down. Recovery point objective is how much data you can afford to lose. Executives usually answer zero and zero to both until the cost of that is explained, at which point the real answers emerge and they are usually four hours and fifteen minutes, or something similar. Those two numbers determine the architecture, and picking them honestly saves a great deal of money.
What matters more than the pattern is the rehearsal
From there the design follows: backup and restore for tolerant workloads, a warm standby for systems where hours matter, or an active configuration across availability zones where minutes do. What matters more than the pattern is the rehearsal. We run a recovery exercise, time it, and write down what actually happened rather than what the plan said would happen. Every drill we have run has surfaced something, usually a credential nobody could find or a dependency on a service that was also down. Australian organisations with obligations to report service continuity to a regulator or a large customer need the measured number, not the aspirational one.
How the engagement runs
Infrastructure as code, and why clicking in the console ends badly
Environments built by hand in a web console are undocumented by definition. Six months later nobody remembers which security group rule was added at midnight during an incident, staging has drifted from production in ways that produce mysterious bugs, and rebuilding after a serious failure is an archaeology project. This is the single most common condition we find when taking over someone else's cloud environment.
- 01DiscoveryCurrent architecture, traffic shape, data volumes, compliance constraints and the actual pain points
- 02DesignTarget architecture with the cost model and the failure modes documented alongside it
- 03FoundationsAccounts, network layout, identity and access, logging and guardrails defined in code
- 04Environment buildStaging and production provisioned from the same Terraform with separate variables
- 05PipelineAutomated build, test and deploy with approvals, and a documented rollback
- 06MigrationWorkloads moved in stages, running in parallel where possible, with a fallback at each step
- 07HandoverArchitecture diagrams, runbooks, cost dashboards and a walkthrough with your team
Two decisions on your side that keep the project moving
We define infrastructure in Terraform so the environment is described in files that live in your repository, reviewed like any other change, and applied through a pipeline rather than by memory. Staging becomes production with different variables, so it behaves the same way. A change is proposed as a plan you can read before it is applied. Rebuilding a region from scratch becomes an operation measured in hours instead of days. The discipline costs a little more at the outset and it is what makes everything afterwards routine.
Choose the right level
Where the cloud bill actually goes
Cloud spend rarely balloons because of the obvious line items. It grows through inattention. Environments spun up for a project and never destroyed. Snapshots retained forever because nobody set a lifecycle rule. Data transfer between zones that a small architecture change would eliminate. Storage sitting in an expensive tier when the objects have not been read in two years. Oversized instances chosen during a load test and never revisited.
Common cost driver
01
Compute
What it usually turns out to be
Instances sized for peak and running around the clock
The typical fix
Right sizing, scheduled scaling and commitment discounts once usage is stable
02
Storage
What it usually turns out to be
Old snapshots, logs and media in a hot tier
The typical fix
Lifecycle rules moving objects to cheaper tiers or deleting them
03
Data transfer
What it usually turns out to be
Chatty services communicating across zones or regions
The typical fix
Co-locating components and caching at the edge
04
Managed services
What it usually turns out to be
Databases provisioned for a load that never materialised
The typical fix
Scaling down and measuring before scaling back up
05
Idle environments
What it usually turns out to be
Test and demo stacks nobody remembered to destroy
The typical fix
Tagging, expiry policies and environments rebuilt on demand from code
How we work this out during scoping
We start cost work with measurement rather than opinion. Resources get tagged by environment and function so spend can be attributed, then we look at the top items and ask which of them buys something you actually value. Some do. Redundancy that keeps a revenue system online is not waste. What usually is waste is capacity provisioned for a peak that occurs twice a year, when scheduled scaling or a serverless component would handle it. We put a cost dashboard in front of your team and set budget alerts, because a bill nobody looks at until the card is charged is the underlying problem.
Australian regions, data residency and latency
Major cloud providers operate regions in Sydney and Melbourne, which means there is rarely a good technical reason for an Australian organisation's primary workload to sit overseas. Hosting locally removes tens of milliseconds from every round trip, which compounds across a chatty application, and it keeps your data under Australian jurisdiction by default rather than by exception.
More on australian regions, data residency and latency
Multi region designs within Australia are now practical for organisations that need geographic separation for continuity, which was awkward when Sydney was the only option. That said, we push back on multi region as a default. It roughly doubles the operational surface and introduces data consistency problems that are genuinely hard. Multiple availability zones within one region handles the failure modes most businesses actually face. We reserve cross region designs for workloads where a regional outage would be materially damaging, and we say plainly when yours is not one of them. Where compliance drives the requirement, we document the data flows precisely, since the questions usually come from a procurement team rather than an engineer, and pair it with the security controls they will also ask about.
When you should not move to the cloud
If you run a single WordPress site with predictable traffic, designing cloud infrastructure for it is engineering for its own sake. Put it on well run managed hosting and spend the difference on content or search. We make that recommendation often. The same applies to a business with a stable on premise system that works and has no growth pressure. Migration carries real cost and real risk, and inertia is sometimes the correct financial decision.
The rest of the answer
Cloud infrastructure earns its keep when at least one of these is true: your traffic genuinely varies by an order of magnitude, you are shipping software often enough that deployment automation pays back, your continuity requirements need infrastructure that can be rebuilt rather than repaired, or you are already in the cloud and paying for an architecture nobody designed. That last case is the most common reason clients come to us. If you are building the application itself, the infrastructure conversation belongs alongside the software design rather than after it, and for products with many tenants it shapes the SaaS architecture directly. Larger organisations with internal platform teams often want us for design and handover only, a pattern common in enterprise environments.
How we scope it
Four ways to scope your Cloud Infrastructure project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Setup
Set up correctly, handed over documented
Fixed written quote, agreed before work starts
- Target architecture with documented failure modes
- Terraform modules for every environment
- Automated build, test and deploy pipeline
Managed
Managed for you, with monitoring and a person to call
Fixed written quote, agreed before work starts
- Everything in Setup
- Autoscaling policies tuned to your traffic shape
- Identity, access and network guardrails
- Centralised logging, metrics and alerting
Managed plus
High availability, hardening and a tested restore
Fixed written quote, agreed before work starts
- Everything in Managed
- Disaster recovery plan with measured recovery times
- Cost dashboard, resource tagging and budget alerts
- Runbooks and a handover walkthrough for your team
Ongoing
Patching, backups and response, every month
Rolling monthly, quoted in writing
- Patching, backups and a restore that has been tested
- Monitoring with a response time written into the agreement
- Security review and dependency updates on a schedule
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Ownership and handover
Who owns the cloud accounts and the infrastructure code?
You do. Cloud accounts are opened under your organisation with your billing, and we hold access roles you can revoke. Terraform code, pipelines and runbooks live in your repository from day one, not ours. That is deliberate: infrastructure you cannot rebuild without a specific vendor is a commercial risk regardless of how good the vendor is.
What happens after handover, do we need you ongoing?
Not necessarily, and the handover is designed on that assumption. You get architecture documentation, runbooks and a walkthrough so an internal team or another partner can operate it. Many clients keep us for a defined period while their team builds confidence, then reduce to an advisory arrangement or a support agreement. That should be your choice, so we never hold credentials or knowledge that makes leaving difficult.
Detail and edge cases
How long does a cloud infrastructure project take?
Typically 5 to 12 weeks. Discovery and design take the first two to three weeks, foundations and environment build the middle, and migration the remainder. The variable is almost always the application rather than the infrastructure: workloads with hard coded configuration, undocumented scheduled jobs or a database that has never been moved take longer. We surface those in discovery so the estimate holds.
How should we think about what this costs?
There are two numbers and they behave differently. Our engagement cost is driven by the number of environments, how many workloads are migrating, the compliance evidence required and whether we hand over or stay involved. Your ongoing cloud spend is paid directly to the provider and depends on the architecture, which is exactly why we model it during design. We quote our side in writing before starting.
Can you work with our existing cloud environment rather than rebuilding it?
Usually yes, and it is often the better option. We start with a review covering architecture, security posture, cost and operational risk, then bring the environment under Terraform incrementally by importing existing resources. That avoids a big bang migration and lets you keep running while the foundations improve. Where something is genuinely beyond repair we will say so and scope a replacement for that component only.
Which cloud provider should we use?
For most Australian organisations the honest answer is whichever one your team already knows, because operational familiarity outweighs feature differences at typical scale. If your business runs on Microsoft 365 and your staff are comfortable there, that ecosystem has real integration advantages. If your developers know a different platform, forcing a change costs more than it returns. We work across the major providers and will not push you toward one for our convenience.
Related services
Get an architecture and cost review in writing
Tell us what you run, where it runs and what is prompting the change. We reply the next business day and follow it with a fixed price in writing.