How We Slashed Azure Service Onboarding to 15 Mins

Service onboarding was a critical business bottleneck for our client, a cloud-native SaaS provider, when manual infrastructure configuration began draining hours of engineering capacity.

While they had successfully automated foundational Azure resources—such as Managed Identities and Federated Credentials—deploying any new microservice still required manual configuration for critical security, networking, and database layers. As the platform scaled beyond 60 microservices, this fragmented process created a 3-to-5-day onboarding delay that stalled feature release cycles.

What’s in this article:

• How we built a GitOps-driven self-service infrastructure platform with OpenTofu and GitHub Actions
• How compliance is enforced across Azure Commercial and Government clouds
• How automated pipelines slashed service provisioning times down to ~15 minutes

Building a Self-Service Infrastructure Platform

To eliminate manual onboarding and standardize infrastructure provisioning, we built a GitOps-driven self-service platform using OpenTofu, GitHub Actions, and declarative YAML configuration. Instead of raising infrastructure tickets, developers define their microservice requirements in a YAML configuration file and submit a pull request. GitHub Actions then validates the configuration, generates an OpenTofu execution plan, and—after the required approvals—deploys the necessary Azure resources while enforcing organizational standards for identity, networking, security, and governance.

Every infrastructure change follows the same GitOps workflow. To reduce execution time, the pipeline performs change detection so that only services with modified service-config.yaml files are processed. Environment protection rules enforce approval gates before production deployments, ensuring that infrastructure changes remain secure, traceable, and auditable. 

Two design decisions help the platform balance efficiency with governance:

• Change detection: The CI/CD workflow processes only services with modified service-config.yaml files, preventing documentation or application code changes from triggering unnecessary infrastructure deployments.
• Approval gates: GitHub environment protection rules require approvals before the apply stage. Policies are tailored to each environment, enabling streamlined reviews in development while enforcing stricter governance for production, particularly in Azure Government deployments.

Platform Architecture

The platform uses a configuration-driven architecture that enables infrastructure to be defined declaratively while keeping service requirements separate from implementation. 

Configuration-Driven Infrastructure 

A central service registry (onboarding-service-workflow.yaml) maintains metadata such as service names, environments, and deployment locations, while individual service-config.yaml files define the infrastructure components and resource-specific settings required by each service. OpenTofu evaluates these configurations and composes only the modules required for the deployment.

1# service-config.yaml (excerpt)
2# Component Configuration
3components:
4 common:
5   - managed_identity
6   - key_vault
7   - keyvault_private_endpoint
8   - database
9   - role_assignments
10   - federated_credentials
11  optional: 
12   - app_registration
13   - redis
14   - storage_account
15   - event_hub

Each microservice maintains its own Terraform state, limiting the blast radius of infrastructure changes and simplifying operational management. The platform supports both Azure Commercial and Azure Government through a single is_usgovernment flag, which automatically resolves cloud-specific endpoints, DNS suffixes, and service APIs for resources such as PostgreSQL, Azure Storage, Event Hubs, and Azure Container Registry. As a result, the same service definition can be deployed to either environment without modification. 

1locals {
2 is_usgovernment = var.azure_cloud == "usgovernment"
3 
4  vault_private_dns_zone = local.is_usgovernment
5   ? "privatelink.vaultcore.usgovcloudapi.net"
6   : "privatelink.vaultcore.azure.net"
7}

Identity and Access Management 

Every service is provisioned with a User-Assigned Managed Identity, enabling authentication through OpenID Connect (OIDC) and Azure Workload Identity Federation without client secrets. PostgreSQL uses Microsoft Entra ID (Azure AD) tokens for authentication, eliminating the need for database credentials.

Key Vault access is managed through Azure RBAC by default. Standardized role assignments provide consistent permissions for application runtimes, platform operators, and shared services, replacing legacy access policies with centralized, policy-driven authorization.

Network Isolation 

Resources use private endpoints within dedicated subnets. Network ACLs default to "Deny," with allowlists for CI/CD runners and AKS subnets. Cloud-specific suffixes are resolved automatically based on the configuration. 

Reusable Platform Modules

The platform is built on a library of reusable OpenTofu modules that encapsulate infrastructure best practices and organizational standards. By centralizing infrastructure logic, updates can be implemented once and automatically adopted across services during subsequent deployments, reducing maintenance effort while improving consistency.

A dedicated naming module generates deterministic, human-readable resource names from service metadata, making resource ownership, deployment environment, and region immediately identifiable while enforcing a consistent naming convention.

1{type}-{service}-{env}-{location-short}-{id}
2→ kv-xyz-devcc-wus-01

Impact of Self-Service Infrastructure

Implementing a configuration-driven onboarding platform significantly improved the developer experience while reducing the operational burden on the platform engineering team. Tasks that previously required multiple manual steps and coordination between teams can now be completed in approximately 15 minutes through a single pull request. This accelerated service delivery while allowing platform engineers to focus on improving the platform instead of performing repetitive infrastructure tasks.

Beyond reducing onboarding time, the platform established consistent security and governance standards across every microservice. By provisioning infrastructure through reusable OpenTofu modules, security controls such as Managed Identities, RBAC, Private Endpoints, and standardized networking are applied by default, reducing configuration drift and ensuring every service starts from the same secure foundation.

The GitOps-based workflow also introduced complete traceability into the onboarding process. Infrastructure changes are now reviewed through pull requests, validated in CI/CD pipelines, and version-controlled in Git, making deployments easier to audit, troubleshoot, and maintain as the platform continues to scale.