Cloud and SAP infrastructure, written as code, built the same way every time.
We define your cloud networks, servers, storage and security settings in Terraform, Bicep or AWS CloudFormation, and use the SAP deployment tools from AWS, Microsoft and Google Cloud to build SAP landscapes. Every environment is reviewed, versioned and repeatable, so test matches production and changes are traceable.
Why build cloud infrastructure from code
When infrastructure is built by hand in a console, each environment drifts a little from the last. Firewall rules, disk layouts and tags differ between development, quality and production, nobody can say exactly what changed, and rebuilding after a failure depends on memory. For SAP this matters more than usual: HANA storage layouts, cluster settings and network rules must match SAP and hyperscaler guidance, and a quality system that does not match production gives misleading test results.
Drift between environments
Manual changes pile up, so systems that should be identical are not. Code makes the target state explicit and lets you detect drift.
Slow, error-prone builds
Building an SAP landscape by hand takes days of checklist work. Templates and pipelines cut that to a repeatable run.
No audit trail
Console changes leave little record of who changed what and why. Code in version control gives you history, review and approval.
Retiring tools
Some older tools are being withdrawn, such as Google Cloud Deployment Manager. Moving to supported tooling avoids a forced migration later.
What we do
We design, write and hand over infrastructure code for your SAP and non-SAP estate on AWS, Microsoft Azure and Google Cloud.
Landing zone as code
We codify accounts, subscriptions or projects, networks, policies and logging for your landing zone. New workloads then start from an approved, consistent base.
SAP landscape automation
We use AWS Launch Wizard for SAP, the SAP Deployment Automation Framework on Azure and Google Cloud Workload Manager guided deployment, or our own modules, to build SAP HANA and NetWeaver based systems. Each build follows the published reference architectures for that cloud.
Reusable modules
We build or adopt tested modules, including Azure Verified Modules for Bicep and Terraform, for common patterns such as networks, VMs and storage. Teams reuse them instead of copying code.
Pipelines and state
We set up pipelines that plan, review and apply changes, with remote state stored securely and locked. Changes reach production only after approval.
Policy and security checks
We add automated checks for tagging, encryption, network exposure and naming before code is applied. Problems are caught in review, not after deployment.
Migration of existing estates
We import hand-built resources into code and convert older templates, for example from Google Cloud Deployment Manager to Infrastructure Manager. You keep what runs today and gain control of it.
How it works
- 1
Assess
We review your current environments, tooling and team skills, and agree which IaC language and SAP deployment tool fit each cloud. We also list resources that already exist and need importing.
1 to 2 weeks - 2
Design
We define the repository structure, module set, naming and tagging rules, state storage and approval flow. For SAP we agree the system sizes, high availability pattern and storage layout per environment.
1 to 2 weeks - 3
Build
We write the modules and pipelines, deploy a first environment such as sandbox or development, and test rebuilds from scratch. SAP software installation is automated where the tooling supports it.
3 to 6 weeks - 4
Roll out
We deploy the remaining environments from the same code with environment specific settings. Drift checks and policy checks run on every change.
2 to 4 weeks - 5
Hand over
We document the code, run working sessions with your team and agree who owns which repositories. We can continue to run the pipelines under a managed service if you prefer.
1 week
Infrastructure as code tools on each cloud
Each hyperscaler has its own native tooling, and Terraform works across all three.
| Need | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Native template language | AWS CloudFormation, AWS CDK | Bicep, ARM templates | Terraform via Infrastructure Manager |
| Managed Terraform runs | Terraform with your own pipeline | Terraform with your own pipeline | Infrastructure Manager |
| Verified or reference modules | AWS CloudFormation templates and AWS CDK constructs | Azure Verified Modules (Bicep and Terraform) | Google Cloud Terraform modules |
| Guided SAP deployment | AWS Launch Wizard for SAP | Azure Center for SAP solutions | Workload Manager guided deployment automation |
| Open source SAP automation | Launch Wizard APIs with CloudFormation | SAP Deployment Automation Framework (Terraform and Ansible) | Exported Terraform and Ansible from Workload Manager |
| Secrets for pipelines | AWS Secrets Manager | Azure Key Vault | Secret Manager |
Infrastructure as code for SAP
Where you run SAP yourself, on ECC or SAP S/4HANA with your own licences on cloud infrastructure, infrastructure as code gives you consistent HANA hosts, clusters and storage across every tier. Each hyperscaler offers SAP specific tooling: AWS Launch Wizard for SAP provisions and configures SAP HANA, NetWeaver, S/4HANA and BW/4HANA systems through CloudFormation, Microsoft's open source SAP Deployment Automation Framework uses Terraform for infrastructure and Ansible for configuration, and Google Cloud Workload Manager can deploy SAP systems and export the Terraform and Ansible it used. Under RISE with SAP the picture is different: SAP builds and runs the SAP systems on the hyperscaler you choose, so our code covers what you own around them, such as the hub network, connectivity, identity, BTP related resources and non-SAP workloads.
- Repeatable SAP HANA and NetWeaver builds for sandbox, quality and production
- High availability clusters and storage layouts that follow hyperscaler SAP guidance
- Rapid rebuilds of project, training or copy systems during S/4HANA moves
- Code for the customer owned side of RISE with SAP: hub network, peering and identity
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
Deliverables
- Agreed IaC standards: language per cloud, repository layout, naming and tagging
- Reusable modules for networks, compute, storage and SAP system tiers
- Deployment pipelines with plan review, approval and secure remote state
- Automated SAP landscape builds using the hyperscaler SAP deployment tools
- Policy and drift checks running on every change
- Runbooks, documentation and working sessions for your team
Frequently asked
Should we use Terraform or the native tool?
Terraform suits teams that work across more than one cloud and want one language. Bicep on Azure and CloudFormation or CDK on AWS integrate closely with their platforms and need no separate state store. We recommend one primary tool per estate and help you choose based on your clouds and skills.
Can you bring our existing hand-built resources under code?
Yes. Terraform, Bicep and CloudFormation all support importing or describing existing resources. We import them in stages, confirm the code matches what is running, then manage changes only through code.
Does this apply if we move to RISE with SAP?
Partly. Under RISE with SAP, SAP provisions and runs the SAP systems and their infrastructure, so you do not write code for those VMs. You still own the landing zone, connectivity, identity and surrounding workloads, and those benefit from infrastructure as code.
We use Google Cloud Deployment Manager. What now?
Google ended support for Deployment Manager on 31 March 2026 and recommends moving to Infrastructure Manager, which runs Terraform. Google provides a conversion tool, and we help convert, test and cut over your configurations.
Can the SAP software installation be automated too?
Yes, within limits. AWS Launch Wizard for SAP and the SAP Deployment Automation Framework can install SAP software you supply, and Google Cloud Workload Manager can deploy SAP systems. Some steps, such as system copies or specific add-ons, may still need SAP Basis work.
Often paired with this
Plan your move with people who know SAP.
One working session with our cloud and SAP architects. You leave with the options, the risks and a first plan.
- Your landscape reviewed
- The right cloud and region
- A first roadmap
At Mawkish, the Ashholm Pass is how we keep Infrastructure Provisioning as Code work checked, owned and answered for, whoever does the build.
AWS, Microsoft Azure, Google Cloud and SAP are trademarks of their respective owners.