SAP Deployment Automation Framework (SDAF)
Understand the SAP Deployment Automation Framework including its Terraform-based control plane and workload zones, deployment workflow, and how it compares to ACSS and manual deployment approaches.
Infrastructure as code for SAP
☁️ Mei pulls up a Terraform file. “Raj, ACSS is great for portal-based management. But for large enterprises managing dozens of SAP systems across multiple regions and environments, you need infrastructure as code. The SAP Deployment Automation Framework — SDAF — is Microsoft’s Terraform-based solution for automating the entire SAP infrastructure lifecycle.”
🏗️ Raj tilts his head. “Terraform? I have heard our cloud team mention it. Is this like writing scripts to build everything?”
☁️ Mei nods. “Exactly. Instead of clicking through the portal, you define your SAP landscape in configuration files, and SDAF builds it all — VMs, networking, storage, OS configuration, and even SAP software installation. Repeatable, version-controlled, and consistent.”
Think of SDAF like a house blueprint system.
ACSS is like hiring a builder who follows a standard plan — you tell them what you want and they build it. SDAF is like having the actual blueprints, permits, and construction schedules stored in a filing cabinet. You can rebuild the exact same house anywhere, make precise changes to the blueprint, and have a paper trail of every modification. The filing cabinet itself (control plane) lives in a separate location from the houses (workload zones) it builds.
SDAF architecture: four components
SDAF is organized into four deployment units, split across two logical layers:
Control plane (deploy once, use across all environments)
Deployer — a VM that orchestrates all deployments. It runs Terraform and Ansible, connects to Azure, and executes the deployment pipelines. Think of it as the “build server” for SAP infrastructure.
Library — an Azure Storage Account and Key Vault that store Terraform state files, SAP software media, and deployment credentials. The library is the shared data layer for all deployments.
Workload zone (deploy per environment/region)
Landscape — the foundational networking layer for a specific environment (dev, QA, production). It creates the VNet, subnets, NSGs, route tables, and any shared infrastructure for that environment.
System — the actual SAP system (HANA VMs, application VMs, load balancers, disks). A landscape can host multiple systems — for example, the production landscape might contain the ERP system and BW system.
🏗️ Raj traces the diagram. “So the deployer and library are shared. Each environment gets its own landscape. And within each landscape, we can have multiple SAP systems.”
☁️ Mei confirms. “You got it. This architecture means PrecisionSteel could use one control plane to manage dev, QA, pre-prod, and production landscapes — each in different regions if needed.”
Exam tip: Know the four components
The exam may describe an SDAF scenario and ask which component handles a specific function. Remember: deployer runs the automation, library stores the state and media, landscape creates the network, and system deploys the SAP VMs. The control plane (deployer + library) is deployed once. The workload zone (landscape + system) is deployed per environment.
Deployment workflow
A typical SDAF deployment follows this sequence:
- Deploy control plane — create the deployer VM and library storage account
- Upload SAP media — place SAP installation files in the library storage account
- Deploy landscape — create networking for the target environment
- Deploy system — provision VMs, storage, and load balancers for the SAP system
- Configure OS — Ansible playbooks configure the operating system (packages, kernel parameters, mounts)
- Install SAP — Ansible playbooks install HANA, ASCS, and application servers using the media from the library
The entire workflow can be automated through Azure DevOps pipelines or GitHub Actions, enabling CI/CD-style deployments for SAP infrastructure.
DevOps integration
SDAF ships with pre-built Azure DevOps pipeline templates. Teams check their SAP configuration files into a Git repository, and any change triggers a pipeline that runs SDAF to apply the update. This brings software development practices (code review, version control, automated testing) to SAP infrastructure management.
SDAF vs ACSS vs manual
| Aspect | SDAF (Terraform) | ACSS (Azure-native) | Manual (Portal/CLI) |
|---|---|---|---|
| Automation type | Infrastructure as Code (Terraform + Ansible) | Azure-native guided deployment | Step-by-step manual configuration |
| Repeatability | Fully repeatable — same config produces same result | Repeatable through ACSS templates | Depends on documentation discipline |
| Version control | Config files in Git — full change history | No built-in version control | None |
| Multi-environment | One control plane manages all environments | Deploy each environment separately | Each environment configured individually |
| Customization | Highly customizable Terraform modules | Limited to ACSS-supported options | Full flexibility |
| Learning curve | High — requires Terraform and Ansible knowledge | Low — portal-guided experience | Medium — Azure and SAP knowledge required |
| Best for | Large enterprises, multiple SAP landscapes | Single system deployments, quick starts | Proof of concept, unique configurations |
☁️ Mei summarizes. “For PrecisionSteel with one production system and a few non-prod, ACSS is probably sufficient. But if you grow to managing 20 SAP systems across 3 regions, SDAF pays for itself in consistency and automation.”
Bicep and ARM templates
While SDAF uses Terraform, Azure also supports Bicep and ARM templates for SAP infrastructure:
- Bicep — Azure’s domain-specific language that compiles to ARM templates. Simpler syntax than raw JSON.
- ARM templates — JSON-based Azure Resource Manager templates. The foundational IaC format for Azure.
- When to use: Organizations already invested in Bicep/ARM may prefer these over Terraform. However, SDAF’s SAP-specific automation (OS config, SAP installation) is not available in Bicep/ARM — you would need to combine them with Ansible or custom scripts.
Knowledge check
PrecisionSteel is considering SDAF. What component stores the Terraform state files and SAP installation media?
A large enterprise manages 15 SAP systems across 3 Azure regions. They want repeatable, version-controlled deployments. Which approach should Mei recommend?
Summary
You now understand SDAF — Microsoft’s Terraform-based automation framework for SAP on Azure. It separates the control plane (deployer + library) from workload zones (landscape + system), enables repeatable deployments via infrastructure as code, and integrates with Azure DevOps for CI/CD. For simpler deployments, ACSS is easier. For enterprise-scale SAP landscapes, SDAF provides the consistency and automation that manual processes cannot match.
With Domain 2 complete, you can design the full SAP infrastructure stack: VMs, storage, networking, HANA architecture, application tier, availability, ACSS, and SDAF. Next, we tackle the critical question: what happens when something fails? Domain 3 covers high availability and disaster recovery.
🎬 Video coming soon