Containerization for government data centres: a practical Australian guide

Australia's federal, state and territory agencies are quietly running one of the largest technology modernisation programs in the Asia-Pacific region. The Digital Transformation Agency has been nudging agencies towards more agile procurement and shared platforms since the late 2010s, and the appetite for portable, repeatable application deployments keeps growing. Containers have moved from a developer curiosity to a real option for agencies that need to host sensitive workloads inside Australian soil.

For teams operating under the Protective Security Policy Framework and the Australian Government Information Security Manual, the conversation is less about hype and more about evidence. The Australian Signals Directorate publishes guidance that shapes how an agency can host a workload, and the Infosec Registered Assessors Program decides whether a platform gets the tick for OFFICIAL: Sensitive data. Containerization is now part of that conversation, not a sidetrack from it.

This guide walks through what a government architect, a platform engineer or a procurement lead in Canberra, Sydney, Melbourne or Brisbane actually needs to consider when weighing up containers. It draws on publicly available Australian government material and general engineering practice, and it complements the broader material published across e-Pragati for readers who want a structured reference.

Why containerisation matters for Australian public sector workloads

For decades, federal agencies ran large monolithic applications on dedicated virtual machines, often hosted in one of the few Australian Government Data Centres operated under whole-of-government arrangements. Those environments were predictable, slow to change, and expensive to scale. The shift towards whole-of-government cloud panels has changed the math, but it has not removed the need for portable, standardised packaging.

A container bundles an application with its dependencies, libraries and configuration into a single image. That image can be tested on a development laptop in Parramatta, promoted to a staging cluster in a Sydney region, and run on production hardware in Canberra without rewriting anything. For agencies running federated programs across multiple states, that portability is worth more than any single performance benchmark.

The other reason it matters is procurement. The Digital Marketplace and the whole-of-government cloud panels reward suppliers who can show repeatable deployments. A containerised application can be onboarded onto a new panel provider in days rather than the months that traditional lift-and-shift exercises used to demand. That changes the conversation with vendors, because the agency is buying behaviour, not just capacity.

Core concepts every government architect should know

The vocabulary around containers is small but precise. An image is the static template; a container is the running instance of that image. A registry stores the images and signs them so consumers know who built them. An orchestrator decides which physical or virtual host should run each container, restarts failed instances, and handles rolling updates.

In the Australian context, the most common orchestrator is Kubernetes, usually packaged as a managed service by one of the major hyperscalers with an Australian region. Smaller agencies sometimes start with Docker Swarm or Nomad because they are easier to operate, but the gravitational pull of the broader ecosystem tends to win over a twelve-month horizon. The choice is rarely about technical superiority and almost always about available skills in the local labour market.

A useful mental model is to treat each container as a short-lived, stateless unit of work, and to push configuration, secrets and persistent data outside the image. That idea lines up nicely with how the Essential Eight expects agencies to manage application execution and integrity checking, and it makes incident response far simpler when something does go wrong on a Tuesday afternoon.

Choosing a runtime and orchestration layer

The runtime is the software that actually starts a container. Most government architects will encounter runC, containerd or CRI-O before they ever need to make a conscious choice, because the chosen orchestrator usually selects one of these behind the scenes. The interesting question is which orchestration layer sits above the runtime.

Kubernetes dominates because of its rich ecosystem, its well-understood failure modes and the depth of available tooling. For a small agency hosting one application, it can feel like overkill, and a managed platform such as AWS ECS on the Sydney region's Fargate profile or Azure Container Apps in Australia East may be a better fit. The trade-off is portability: managed platforms save operations effort but bind the workload to a single provider's API surface.

A practical decision framework looks at three things. First, where does the data live, and which platform has the IRAP assessment for that classification level. Second, who in the agency or its panel partners already knows how to operate the chosen orchestrator. Third, what does the exit plan look like if the panel arrangement changes in three years. Agencies that answer these honestly tend to pick boring, well-supported options, and that is usually the right call.

Option	Best fit for	Operational burden	IRAP-aligned examples
Managed Kubernetes (EKS, AKS, GKE)	Multi-service platforms, mature DevOps teams	Medium, depends on shared responsibility	Available in AWS Sydney, Azure Australia East
Lightweight orchestrators (Swarm, Nomad)	Single-application teams, simpler estates	Low	Operated as customer-managed in any region
Serverless container platforms (Fargate, Container Apps)	Spiky workloads, small ops teams	Very low	Built on assessed hyperscaler regions
Self-hosted Kubernetes on government cloud	Data sovereignty, custom compliance stacks	High	Whole-of-government certified clouds

Security, compliance and the IRAP reality

Containers change the attack surface rather than shrink it. Every image pulled from a registry is a software supply chain decision, and agencies that adopt containers without rethinking patching, scanning and provenance usually find themselves explaining an incident report to the Australian Cyber Security Centre. The Essential Eight already asks organisations to maintain an inventory of applications and to patch quickly; containers make both activities easier if the right tooling is in place.

IRAP assessors look for evidence that an agency can show what is running, who built it, and how it was deployed. That maps neatly onto signed images, immutable tags, admission controllers that reject unsigned workloads, and a clear audit trail from code commit through to production. A common mistake is to let developers push anything tagged "latest" into production, which removes traceability and breaks any hope of passing an assessment.

For inter-agency data sharing, the conversation often overlaps with related technologies. Readers exploring complementary patterns may find it useful to read up on blockchain in government applications, because the immutability and provenance ideas transfer cleanly into the container world. Both rely on a verifiable chain of custody, and both need governance that matches the technology rather than chasing it.

Migration patterns for legacy government systems

The phrase "lift and shift" gets used too loosely in Canberra briefing papers. With containers, there are at least four distinct patterns, and the choice determines how much refactoring is needed. A straight lift copies the existing application and its configuration into a container without changing the code, which is rarely a good idea because most legacy systems depend on specific hostnames, registry keys or Windows components.

A more common starting point is to lift, re-platform and then refactor. The first step packages the application as a container with the same dependencies it had on the old server. The second step moves configuration and secrets to a managed store. The third step rewrites the parts of the application that need to be stateless, twelve-factor compliant or cloud-native. Many agencies spend eighteen months on the second step alone, because it forces conversations about identity, secrets management and network segmentation that were long overdue.

A pattern that works well for citizen-facing services is the strangler-fig approach, where new microservices gradually replace parts of a monolith while both run side by side. The user-friendly government portal interface is often where this first becomes visible to the public, because front-end features can be redeployed on containers without touching the back office. That keeps the visible experience fresh while the slower refactor of core systems continues underneath.

Operating containers at scale in Canberra and beyond

Running containers in production is mostly an operations problem dressed up as an engineering one. Agencies that succeed treat the platform as a product, with a small dedicated team owning the cluster, the CI/CD pipelines, the registry and the developer experience. Teams that fail usually treat it as a project, hand it over to a generic infrastructure group, and discover eighteen months later that nobody owns the upgrade path when Kubernetes moves to its next minor release.

Observability is the first thing to get right. Centralised logging, metrics and tracing need to be in place before the first workload goes live, because once a cluster has fifty services, retro-fitting telemetry is painful. Australian agencies often use a combination of open-source tools such as Prometheus and Grafana alongside the cloud provider's native monitoring, which keeps costs predictable and data inside Australian regions.

Skills matter as much as tools. The Australian Computer Society regularly reports shortfalls in cloud and platform engineering, and competition for Kubernetes talent is fierce across Sydney, Melbourne and Brisbane. Agencies that invest in internal training, contribute to open-source projects, and rotate staff between operational and development roles tend to retain people longer than those that outsource the whole platform to a single panel provider.

For Australian agencies weighing up their next platform decision, containers are no longer an experimental choice. They are a sensible default for new workloads, a workable path for many legacy ones, and a credible answer to the portability questions raised by whole-of-government procurement. The technology is mature, the assessors understand it, and the local skills market, while tight, is growing.

A practical next step is to pick one modest application, containerise it end to end, and take it through an IRAP-aligned review. The lessons from that single pilot will shape the next ten decisions far more reliably than any strategy deck. Readers who want a structured reference for the broader digital transformation conversation, including governance, architecture and leadership perspectives, will find useful background material across e-Pragati.