Skip to content

Cloud infrastructure.

AWS · Azure · GCP · On-premise · AU-region by default

Cloud, networking, identity, and the operational plumbing that holds everything together. Designed to run reliably on your terms, hosted in Australia where it should be, documented for the team that has to operate it after we leave. Greenfield, migration, or taking over what someone else built before they walked away.

What cloud infrastructure means here

Cloud infrastructure at Bedstone means everything underneath the application: cloud accounts and tenancy, networking and connectivity, identity and access, runtime and orchestration, data stores, observability, CI/CD, secrets, cost management, and the operational practices that make it all work in production. We do not stop at provisioning resources. The system has to run reliably under load, be operable by your team, and pass an auditor's questions without rebuilding from scratch.

What we do not do: drop a Terraform repository over the wall and call it done. Infrastructure that nobody can operate is technical debt with a higher hourly rate. If your engineers cannot deploy, debug, and recover from incidents without us, the engagement is not finished.

Where this fits

Infrastructure engineering is the right call when most of the following are true.

  • You are launching a new system and want production infrastructure built right the first time rather than retrofitted later.
  • You inherited a cloud environment from a previous team or vendor and it is undocumented, expensive, or fragile.
  • Your cloud bill is climbing faster than the business and nobody can explain why.
  • You have outgrown a managed platform (Heroku, Render, Vercel) and need to move onto direct cloud accounts.
  • An enterprise customer or regulator is asking for evidence of how your infrastructure is run.
  • You are running on-premise or colo and want a hybrid posture that does not lock you in.
  • Your team can ship code but the production environment has become a bottleneck they cannot move on.

What we build and run

Engagements range from greenfield builds to taking over existing systems. Common scope:

  • Account and tenancy structure. AWS Organizations, Azure subscriptions, GCP projects. Multi-account separation for prod, non-prod, sandbox, security, log archive. Service control policies and guardrails.
  • Networking. VPCs, subnets, routing, peering, Transit Gateway / Virtual WAN, private connectivity, VPN, Direct Connect / ExpressRoute, DNS, certificates, edge and CDN.
  • Identity and access. Workforce identity (Entra ID, Okta, Google Workspace), SSO into cloud and applications, role-based access, conditional access, MFA enforcement, joiner-mover-leaver automation, privileged access management.
  • Runtime and orchestration. Containers on ECS / EKS / AKS / GKE, serverless (Lambda, Cloud Functions, Container Apps), VMs where they fit, deployment pipelines, blue-green and canary rollout.
  • Data stores. Relational (RDS, Aurora, Cloud SQL, Azure SQL), key-value, document, search, time-series, warehouse. Backup, point-in-time recovery, replication, multi-region where the workload justifies it.
  • Infrastructure as code. Terraform, OpenTofu, AWS CDK, Bicep, Pulumi. Version controlled, peer reviewed, environment promoted. State stored and locked properly.
  • CI/CD. Build, test, sign, deploy. GitHub Actions, GitLab, Bitbucket Pipelines, Azure DevOps, CodePipeline. Scoped credentials, signed artefacts, environment promotion gates.
  • Observability. Metrics, logs, traces, real-user monitoring, synthetic monitoring, alerting. CloudWatch, Datadog, New Relic, Grafana, Honeycomb, depending on what your team uses.
  • Secrets and configuration. Secrets Manager, Key Vault, Secret Manager, Vault. Rotation, scoped access, audit logging.
  • Security baseline. Guardrails, encryption defaults, logging, anomaly detection, threat detection (GuardDuty, Defender, SCC), patching cadence, vulnerability management.
  • Cost management. Tagging, allocation, savings plans, reserved capacity, anomaly detection, budgets, FinOps review cadence.
  • On-premise and hybrid. Where physical infrastructure makes sense to keep. Hybrid connectivity, sovereign data residency, edge presence.

AU-region by default

For Australian clients, default deployment keeps data and compute in country.

  • AWS. ap-southeast-2 (Sydney) primary, ap-southeast-4 (Melbourne) where multi-region in country is needed.
  • Azure. Australia East (Sydney) primary, Australia Southeast (Melbourne) as paired region. Australia Central for IRAP / sovereign workloads.
  • GCP. australia-southeast1 (Sydney) primary, australia-southeast2 (Melbourne) for multi-region in country.
  • Backups and snapshots. Stay in AU regions by default. Cross-region replication only with explicit sign-off.
  • Edge and CDN. CloudFront, Front Door, Cloud CDN with AU edge presence prioritised for AU user bases.
  • Sovereign cloud. AWS Top Secret-Cloud and AU Top Secret regions for cleared workloads, Azure Government Cloud / IRAP PROTECTED, where applicable.

Data residency is configured and documented as part of the build, not retrofitted later. Where workloads need to cross borders (third-party AI inference, US-hosted SaaS dependencies), the path is documented and the customer-facing privacy policy reflects reality.

How we work

Six-step engagement from intake to operational handover.

  1. Discovery. Current state assessment. What runs today, where, how, at what cost. Risk and gap analysis. Stakeholder interviews with engineering, IT, security, finance.
  2. Target architecture. Design document covering accounts, networking, identity, runtime, data, observability, security, cost. Decision rationale for each major choice.
  3. Foundation build. Account structure, networking, identity, baseline guardrails, IaC pipeline, secrets, observability foundations. The shared platform everything else lands on.
  4. Workload migration or greenfield deployment. Move the actual applications onto the platform, or stand up greenfield workloads. Cutover with rollback.
  5. Operational handover. Runbooks, dashboards, on-call setup, incident response practice. Your team can deploy, debug, and recover without us.
  6. Operate or retainer. Optional ongoing engagement where we operate the platform alongside your team, or stay on retainer for major changes and incident response support.

Working with your IT and platform team

Infrastructure built without the team that will operate it is infrastructure that gets thrown out. We partner with your IT, platform, and DevOps teams from day one. We came up as engineers and infrastructure operators ourselves, so the working relationship is engineer to engineer: pair on the IaC, peer review the network design, share the on-call rotation during cutover, document decisions in the same wiki they already use.

In practice your team gets shared write access to the IaC repos, sits in on the architecture decisions, pairs on the build, and runs the runbooks themselves before we leave. The handover is the engagement, not an afterthought.

What week one looks like

Most engagements run for four to twelve weeks for the build, plus an optional operate phase. The first week sets up the rest.

  • Day 1. Kickoff and access. Stakeholders mapped. Access requested at appropriate scopes. Existing infrastructure inventoried. Shared communication channels established.
  • Day 2. Discovery interviews. 30 to 45 minute conversations with engineering, IT, security, finance. Understand the system as the people who run it see it.
  • Day 3. Current state assessment. What runs today, at what cost, with what risk. Networking, identity, data flows, dependency map.
  • Day 4. Target architecture working session. Live whiteboard with your team on the target design. Decisions captured in writing.
  • Day 5. Foundation IaC scaffolding. Account structure, IaC repository, CI/CD baseline, first networking and identity primitives landing. Your team has shared write access from day one.

What you actually receive

At engagement end you hold the system plus the operational artefacts that let your team run it.

  • Production infrastructure. Live cloud or on-premise environment running the workloads in scope. Multi-environment (prod, non-prod, sandbox). Documented and tested.
  • Infrastructure as code repository. Version controlled, peer reviewed, environment promoted. State stored and locked. Your engineers can change, plan, and apply.
  • Architecture decision records. Every significant choice documented with context, alternatives, and rationale. Future engineers know why, not just what.
  • Runbooks. Deploy, rollback, scale, backup and restore, incident response, on-call escalation. Written for the team that will use them.
  • Observability dashboards. The two or three views your team actually opens during an incident. SLO dashboards. Cost dashboards.
  • Security and compliance evidence. Where required: SOC 2, ISO 27001, IRAP, Essential Eight evidence trail in the format your auditor expects.
  • Knowledge transfer. Pairing sessions, recorded walkthroughs, and shared on-call during cutover. Your team owns the system before we leave.

Bedstone infrastructure vs alternatives

Option Best for Trade-off
Big-four / large consultancy Framework alignment and procurement boxes. Audit-ready. Build done by juniors with limited operational depth. Inherit something that satisfied an audit but is hard to operate.
Specialist DevOps boutique Specific platform builds (Kubernetes, multi-region SaaS). Often light on AU regulatory context, identity, or compliance overlay.
Offshore managed service provider Lowest cost option. Predictable for steady-state. Black box your team can't debug. Response times don't match an AU business day. Risk shows up at 2 a.m.
Cloud provider professional services Provider-specific deep expertise. AWS / Azure / GCP-native projects. Bias toward provider lock-in. Less useful for hybrid or multi-cloud work.
Bedstone infrastructure Infrastructure that survives the people who built it. AU-region default. IRAP-aware. Handover is the engagement. Less brand recognition than big-four. We trade logo for systems your team can actually operate.

How to evaluate a partner

  1. Ask who actually does the work. Named seniors with verifiable backgrounds, or someone you have never met. Get LinkedIn profiles.
  2. Ask about the handover. A real engagement leaves your team operating the system. If the partner cannot describe what handover looks like, you are signing up for a permanent dependency.
  3. Ask about cost management. A real engagement plans for cost from day one. If FinOps is a separate sales pitch, you will overspend by 30 to 50 percent in the first year.
  4. Ask about AU regulatory context. IRAP, Essential Eight, Privacy Act, data residency. Partners without AU operating history will miss the obligations that matter here.
  5. Ask for runbook samples. A partner who operates real infrastructure has runbooks. A partner who only provisions does not.
  6. Ask about incident response. What is their on-call posture during the engagement and after handover. Vague answers are a tell.

FinOps and cost management

Cloud cost is an engineering problem, not a finance problem. We treat it as part of the build, not a clean-up afterwards.

  • Tagging and allocation. Resources tagged for cost attribution by team, product, environment, and customer. Costs trace back to the engineering decision that drove them.
  • Right-sizing. Compute, storage, and database tier sized to actual workload, not the default the team picked at 2 a.m. before launch.
  • Savings plans and reserved capacity. Where workloads are stable, committed capacity at the right horizon and the right coverage ratio.
  • Anomaly detection. Cost anomaly alarms wired into the same channel as production alerts. A 30 percent spike on a Saturday gets attention before Monday.
  • Storage tier management. Lifecycle policies, archival, deduplication. Most cost reviews find a quarter of storage spend that should not exist.
  • Egress restructuring. Egress is where cloud bills surprise teams. Caching, regional placement, peering options, and dedicated connectivity all change the picture.
  • Observability spend audit. Logging, monitoring, and APM tools often outgrow their value. Periodic audit and consolidation.
  • FinOps cadence. Monthly cost review with engineering, not just finance. Decisions tied to action.

Reliability and observability

Reliability is engineered, not bought. Common engagement elements:

  • SLOs that mean something. Service-level objectives tied to user-visible behaviour. Error budgets your engineering team can use to make trade-off decisions.
  • Three-pillar observability. Metrics, logs, traces. Configured to answer the questions an on-call engineer actually asks at 2 a.m.
  • Real-user monitoring and synthetic checks. External validation that the system works for actual users, not just internal probes.
  • Incident response practice. Runbooks, escalation paths, post-incident reviews, blameless retros. Practiced before they are needed.
  • Capacity planning. Load forecasting, scale testing, headroom monitoring. The first time you find a capacity ceiling should not be in production.
  • Disaster recovery and backups. Restored regularly, not just configured. RTO and RPO targets matched to the business need.
  • Chaos engineering where it fits. Controlled failure injection in mature environments to validate resilience claims.

Compliance overlay (IRAP, SOC 2, ISO 27001, Essential Eight)

Where the infrastructure has to satisfy a formal compliance framework, we design and operate for it from day one rather than retrofitting.

  • IRAP. Australian Signals Directorate framework for systems handling government workloads. Configured deployments for PROTECTED, OFFICIAL: Sensitive, and Top Secret tiers as applicable.
  • ACSC Essential Eight. Application control, patching, MFA, restricted admin privileges, application hardening, daily backups, configured macro settings, user application hardening. Maturity uplift plans.
  • SOC 2. Common when AU SaaS sells into US enterprise. Type 1 and Type 2 evidence. Infrastructure controls in scope with the right evidence trail.
  • ISO 27001. Annex A control mapping for infrastructure-relevant controls. Evidence collection and audit support.
  • APRA CPS 234. For regulated financial entities. Information security capability, policy and standards, identification and classification, implementation of controls, incident management, testing of control effectiveness.
  • Privacy Act and OAIC. Data handling, breach notification readiness, cross-border data flow documentation.

We work alongside your existing GRC tooling rather than replacing it. Infrastructure feeds the evidence trail; your compliance team owns the submission.

How we structure engagements

Infrastructure engagements are scoped to outcome rather than hours. Common shapes:

  • Fixed-scope build. Defined platform, defined timeline, defined handover. Most common for greenfield and migration.
  • Discovery and architecture engagement. Two to four week assessment of current state plus target architecture design. Output drives the build engagement that follows.
  • Operate or co-operate retainer. Monthly engagement where we run the platform alongside your team or carry on-call.
  • FinOps review engagement. Two to four week cost audit with implementation runway. Finds spend you can remove without changing what runs.
  • Embedded platform engineer retainer. Senior platform engineering capacity on a monthly basis for ongoing change, incident response, and architecture review.

Infrastructure work supporting novel software development (custom platforms, AI workloads, in-house tooling) can qualify for the R&D Tax Incentive. Reach out and we will reply within 24 hours with the shape and pricing that fits your situation.

Common questions

Which cloud providers do you work with?

AWS, Microsoft Azure, and Google Cloud, plus on-premise and hybrid where it fits. Default region for Australian clients is ap-southeast-2 (Sydney) on AWS, Australia East on Azure, australia-southeast1 on GCP. We pick the provider that fits your data residency, compliance posture, existing tooling, and skill set, not the one we get the best rebate from.

Can you keep our data in Australia?

Yes. Default deployment for AU clients is AU-region with data and backups staying in country. Where IRAP, sovereign cloud, or specific data residency obligations apply, we configure accordingly and document the controls.

Do you handle on-premise and hybrid?

Yes. On-premise infrastructure, hybrid cloud, colo, and edge deployments are all in scope. We work with your existing hardware footprint where it makes sense to keep it, and design hybrid connectivity that does not turn into a single point of failure.

Can you help reduce our cloud bill?

Yes. A FinOps review surfaces the spend you can remove without changing what runs. Common wins are right-sizing compute, removing idle resources, savings plans and reserved capacity, storage tier changes, data egress restructuring, and observability tool consolidation. Most reviews find 20 to 40 percent of spend that can come out within a quarter.

Do you work with our existing platform team?

Yes. We partner with your IT, platform, and DevOps teams from day one. The goal is a system your team owns and can run after we leave, not a black box only we can touch.

Can you migrate us between cloud providers?

Yes. We have run AWS to Azure, Azure to AWS, on-premise to cloud, and cloud to colo migrations. We do not push a migration unless the business case is real. Migration is expensive and most organisations get better outcomes from improving what they already run.

Do you handle compliance frameworks?

Yes. We design and operate for SOC 2, ISO 27001, IRAP, PCI-DSS, APRA CPS 234, ACSC Essential Eight, and sector-specific obligations. We work alongside your assessor or auditor and produce the evidence trail they expect.

Can you take over an existing setup that is broken or undocumented?

Yes. A common engagement is inheriting infrastructure built by a previous team or vendor. We document it as it is today, surface the risk, stabilise the operational gaps, then propose a remediation roadmap. Day one we can usually keep the lights on. Week four you have a system you understand.

Start a brief