This project focuses on evaluating the financial feasibility of migrating an existing on-premises SAP environment to Amazon Web Services (AWS). While no actual migration will take place, the goal is to develop a clear and informed cost model that helps leadership make strategic decisions.
What the Project Involves
Infrastructure Cost Estimation
Analyze the current on-prem SAP setup and calculate what it would cost to run the same environment on AWS. This includes identifying equivalent AWS services, sizing resources correctly, and estimating monthly and annual spend.
Executive-Level Presentation
Translate the technical cost analysis into a clean, concise slide deck tailored for business stakeholders. The presentation will summarize projected AWS costs, key assumptions, potential savings, and migration considerations so executives can confidently assess the viability of moving forward.
To estimate cloud infrastructure costs for our SAP environment, we use the AWS Pricing Calculator available at calculator.aws. Once on the site, the first step is to click “Create estimate”, which opens a blank workspace where we can begin adding AWS services such as EC2, EBS, RDS, and networking components. This workspace will serve as the foundation for our full cost model.
At the top of the interface, you’ll find an option labeled “Search by location type”. We keep this set to Region, allowing us to filter AWS services and pricing based on the geographic area where the business intends to host its infrastructure. This step ensures that our cost assessment is aligned with real-world pricing variations across AWS regions.
For this project, we select the North America region. This choice reflects a hypothetical business requirement— due to data residency, latency considerations, or organizational policy. As cloud data architects and engineers, our role is not to question that business decision but to respect it and produce an accurate estimate within those parameters.
When estimating cloud costs for a production environment, one of the first steps is sizing your EC2 instances—especially if your application relies on multiple always-on servers. In the AWS Pricing Calculator, this begins by searching for EC2 and opening the configuration panel.
Adding EC2 for Production Application Servers
From there, you’ll define a few foundational settings:
Tenancy: Shared instances are typically the most cost-efficient option unless you require dedicated hardware for compliance or licensing reasons.
Operating System: Linux is commonly used for enterprise workloads due to its flexibility and lower licensing costs.
Workload Type: For production servers that run 24/7, select constant usage to reflect real operational patterns.
Next, translate your on-premises specs into cloud requirements. For example, if your environment uses five application servers, each with 8 vCPUs and 16 GB of RAM, you’ll configure the calculator to provision the same number of instances and apply filters for CPU and memory. This narrows your choices to only those EC2 families that match your technical needs.
With the filtered list, the final step is selecting the most cost-effective instance type—typically a general-purpose or compute-optimized option that satisfies the workload requirements. Whichever instance configuration provides the right performance at the lowest cost becomes your selected instance for the estimate.
Applying a Compute Savings Plan
Once you’ve estimated the cost of running your production servers on EC2, the next step is optimizing that cost. By default, the AWS Pricing Calculator uses on-demand pricing, but for workloads that run continuously—like production application servers—there are smarter options available.
One of the most effective ways to reduce long-term compute costs is by applying a Compute Savings Plan. Savings Plans allow you to commit to a consistent amount of compute usage (measured in $/hour) for a 1- or 3-year period in exchange for significantly lower pricing. This makes them ideal for stable, mission-critical environments with predictable usage patterns.
In the Pricing Calculator, you can scroll to the Purchasing Options / Savings Plans section and apply the following settings:
- Plan type: Compute Savings Plan
- Term: 3 years
- Payment option: No upfront
This configuration reflects a business decision to commit to steady compute usage in order to achieve meaningful cost reductions.
After applying the plan, the calculator provides a detailed cost breakdown. By clicking “Show calculations,” you can review below:
- The total compute hours per month
- The adjusted hourly rate under the Savings Plan
- The revised monthly cost for the workload
- Additional insights like utilization summaries and break-even analysis
This step not only highlights potential savings but also helps organizations make informed budgeting and forecasting decisions.Below is the cost calculation
Adding Block Storage (EBS) for Production
After configuring the compute resources for your production application servers, the next step is estimating the storage they require. In many on-prem environments, application servers rely on block storage for logs, binaries, temporary files, and application data. When moving this setup to AWS, the equivalent service is Amazon EBS (Elastic Block Store).
Start by identifying the total amount of block storage used across all application servers. For example, if the environment consumes 2 TB of storage in total and is distributed evenly across five servers, each instance will require approximately 400 GB. Because the AWS Pricing Calculator expects storage to be entered per instance, calculating this per-server value ahead of time ensures your estimate stays accurate.
In the EC2 configuration under the Elastic Block Store section, you can specify:
- Storage type: gp2 (General Purpose SSD)
- Allocated storage per instance: 400 GB
After entering the values, the calculator will display the estimated monthly cost added by EBS. Using the “Show calculations” option gives deeper insight into how storage pricing is derived, including cost per GB-month and total monthly storage spend.
Adding EC2 for Stage and Dev Environments
After modeling the production servers, the next step is to estimate the compute and storage requirements for staging and development environments. Although these environments are less critical than production, they often mirror the same technical configuration—just with fewer servers.
In a typical setup, staging and development servers might share identical specifications, such as 4 vCPUs and 8 GB of RAM. If both environments use the same server size, it’s more efficient to calculate them together. For example, you might have three servers in staging and two in development, resulting in a total of five EC2 instances with matching configurations.
Using the AWS Pricing Calculator, you can add a new EC2 service and filter by the required CPU and memory to identify the most cost-effective instance type. After selecting the instance, set the number of servers, workload type, region, and any long-term commitment options—such as a 3-year Compute Savings Plan—to reflect expected usage patterns and reduce cost.
Block storage should also be included. If staging requires 1 TB and development requires 0.5 TB, the total of 1.5 TB can be divided evenly across the five instances, resulting in 300 GB of EBS storage per server.
Double-checking instance counts is crucial—misconfigured quantities can drastically skew estimates.
Adding Application Load Balancers to the Estimate
Beyond compute and storage, many cloud architectures rely on load balancers to ensure reliability and consistent performance across environments. In most cases, production, staging, and development each include their own load balancer, resulting in a total of three: one per environment.
In the AWS Pricing Calculator, this can be modeled by adding the Elastic Load Balancing service and selecting the Application Load Balancer (ALB) option. After choosing the appropriate AWS Region, simply enter the number of load balancers required—in this case, three.
To generate a more accurate estimate, it’s useful to include basic traffic assumptions. For example, you might estimate:
- Processed data: 2 GB per hour
- Average requests per second: 100 per ALB
- Rule evaluations per second: 100 per ALB
While these inputs are optional, they help refine the pricing and are typically derived from monitoring data in the existing on-premises environment.
An Application Load Balancer plays a key role in modern cloud-based applications. It distributes incoming traffic evenly across multiple servers, prevents any single instance from becoming overloaded, improves fault tolerance, and enables seamless scalability. ALBs can also route requests based on URL paths or hostnames, making them essential for microservices and multi-tier architectures.
After entering the configuration details, the calculator provides a cost breakdown—often in the range of a few hundred dollars per month for multiple ALBs—helping you budget for a resilient and highly available environment.
Adding Shared File Storage Using Amazon EFS
Many on-premises environments rely on NFS-based shared storage for application files, configuration data, or assets that must be accessible across multiple servers. When estimating cloud costs in AWS, the closest managed equivalent to traditional NFS storage is Amazon EFS (Elastic File System).
To budget for this component, start by identifying the total shared storage used across all environments. For example, an environment may allocate 1 TB for production, 0.5 TB for staging, and 0.25 TB for development. Combined, this results in 1.75 TB of shared file storage.
In the AWS Pricing Calculator, you can model this by adding the EFS service and configuring it with the appropriate region and total capacity. Unlike block storage, EFS is designed to be elastic and accessible by multiple EC2 instances simultaneously, making it ideal for workloads that require centralized, scalable file storage.
Entering the total expected storage—such as the full 1.75 TB in this example—allows the calculator to generate an estimated monthly cost for maintaining NFS-style shared storage in the cloud. While additional configuration details can be added, such as descriptions or performance modes, the basic inputs are typically enough to create a reliable estimate.
This step ensures your cloud cost model includes not just compute and block storage, but also the shared file system layer many applications rely on.
Adding RDS Custom for Oracle – Production
When migrating enterprise workloads to the cloud, databases often represent one of the most significant components of the overall cost model. For environments running Oracle, a common AWS choice is Amazon RDS Custom for Oracle, which offers greater control and customization while still providing managed database capabilities.
On-premises databases often use very specific CPU and memory configurations. For example, a production Oracle database might run on hardware sized at 38 vCPUs and 156 GB of RAM. Cloud platforms don’t always offer an identical match, so it’s normal to select the nearest higher configuration. In this case, an instance class offering 48 vCPUs and 192 GB of RAM would provide slightly more capacity while remaining appropriate for cost modeling.
In the AWS Pricing Calculator, you can add RDS Custom for Oracle, choose the number of database instances—often two for high availability—and apply filters for CPU and memory to locate the closest fit.
Key settings include:
- Deployment: Single-AZ (Multi-AZ offers higher resilience but increases cost)
- Pricing model: On-demand for straightforward cost estimation
- Utilization: 100% to reflect continuous production workloads
Database storage must also be included in the model. If the total required storage is 3 TB, dividing it across two database nodes results in 1.5 TB per instance. This can be provisioned using gp2 storage in the calculator.
Backup storage should always match or exceed the full database size. A best-practice estimate may include the full 3 TB plus some overhead—e.g., 3.5 TB total.
By reviewing the detailed calculations, you might see figures such as:
- Database compute cost: ~$9,700 per month
- Primary storage cost: ~$657 per month
- Backup storage: ~$332 per month
The final step is saving the configuration and reviewing the summary, which consolidates compute, storage, and backup costs into the overall cloud cost model.
Estimating Costs for Staging and Development Databases Using Amazon RDS
After modeling the production database, the next step in building a complete cloud cost assessment is estimating the compute and storage requirements for staging and development environments. Although these databases typically support lower-risk workloads, they still need to be sized appropriately to mirror production functionality.
Staging Database Estimate
Staging environments often use scaled-down versions of production resources while still maintaining similar performance characteristics. A common configuration for a staging Oracle or relational database might include two database instances, each sized at 16 vCPUs and 64 GB of RAM.
In the AWS Pricing Calculator, this can be modeled by adding another RDS entry and selecting an instance class that matches the required memory—such as an instance type offering 16 vCPUs and 64 GB RAM. A Single-AZ deployment is typically sufficient for staging, keeping costs reasonable.
Storage and Backup Planning
If the total required storage mirrors production—for example, 3 TB—this can be divided across the two nodes, resulting in 1.5 TB per instance. Backup requirements in staging can often be smaller, so a backup allocation of around 1 TB may be adequate.
This configuration usually results in a modest monthly cost, depending on compute and storage selections.
Development Database Estimate
Development databases tend to require even smaller configurations. A common setup may include two database instances, sized near 8 vCPUs and 32 GB RAM, matching the lower resource needs of active development work.
In the calculator, selecting an RDS instance class that aligns with 8 vCPUs and 32 GB of memory provides a close approximation. Like staging, Single-AZ deployment is appropriate for cost control.
Storage and Backup
A development database may require around 1 TB of total storage, which can be modeled as either 500 GB per instance or simply 1 TB total—whichever aligns better with how the workload uses storage. Backup needs are minimal, and an estimate of 500 GB typically suffices.
When configured, development database costs are usually significantly lower than staging or production, reflecting reduced performance and reliability requirements.
Together, these estimates help build a complete picture of non-production database costs in AWS, ensuring accurate budgeting and smooth planning for cloud migration initiatives.
Reviewing the Overall Infrastructure Estimate
After modeling all of the major components of the cloud architecture—compute resources for production, staging, and development; block storage; load balancers; shared file storage; and multiple database environments—the AWS Pricing Calculator provides a consolidated view of the projected infrastructure cost.
At this stage, the summary typically reveals three key figures:
- Estimated monthly cost
- Estimated annual cost
- Upfront commitment: $0, assuming on-demand pricing combined with Savings Plans
When compared to the operational expense of maintaining a large on-premises footprint—physical servers, storage arrays, networking hardware, power consumption, cooling systems, and ongoing staffing—this cloud-based estimate is already significantly more cost-effective. Beyond the financial benefit, the shift also reduces hardware lifecycle concerns and increases overall agility.
And while this estimate represents a major portion of the infrastructure cost, the analysis is not yet complete. Additional services, network components, management tools, and operational overhead may still need to be factored in to arrive at a fully comprehensive migration cost model.
Factoring AWS Enterprise Support Into the Cost Estimate
When evaluating the total cost of running mission-critical workloads in AWS, infrastructure alone is only part of the equation. High-priority systems—such as SAP, large databases, financial platforms, and core business applications—typically require rapid response times, proactive guidance, and round-the-clock technical support. This is where AWS Enterprise Support becomes an essential part of the cost model.
In the AWS Pricing Calculator, support can be added by selecting the Support option. You’ll be asked how you want to engage with AWS, and for workloads that demand 24/7 availability, the requirements often include:
- Access to multiple AWS support engineers at any time
- Phone and email support 24/7
- Fast response times for critical incidents (often 15 minutes or less)
Once these high-severity response expectations are selected, the lower-tier support plans—Basic, Developer, and Business—automatically drop away, leaving Enterprise Support as the only suitable choice.
Enterprise Support is a significant cost component, often around $15,000 per month depending on usage and AWS spend aggregation.
Despite the increase, organizations running mission-critical systems often find this still far more cost-effective and flexible compared to maintaining equivalent support, reliability, and staffing in a traditional on-premises environment.
Total cost of Ownership
Why Moving to AWS Cloud Is Better Than Staying On-Premises
As organizations re-evaluate the cost and complexity of running mission-critical systems like SAP on traditional on-premises infrastructure, the advantages of shifting to AWS Cloud become increasingly clear. When we modeled an enterprise SAP landscape using the AWS Pricing Calculator—replicating compute, storage, networking, and database requirements—we uncovered just how much more efficient the cloud can be.On-premises environments demand large upfront investments in physical servers, storage arrays, networking gear, cooling, power, and the staff needed to manage them. These systems also require periodic refresh cycles and capacity planning, making them costly and inflexible. In contrast, AWS allows you to provision equivalent compute power—such as EC2 instances sized for production, staging, and development workloads—within minutes and without capital expenditure.Storage services like EBS and EFS scale effortlessly, replacing complex SAN or NFS deployments. Load balancing, which often requires expensive hardware appliances on-prem, becomes a simple managed service through AWS ALB. Even high-performance database needs, such as Oracle for SAP, can be met using RDS Custom for Oracle—giving organizations the power they need without the operational burden.One of the most compelling advantages is cost transparency and optimization. Using Savings Plans, organizations can drastically reduce compute costs by committing to predictable usage. In our model, the full infrastructure cost came to roughly $28595.22 USD per month, or $343142.64 USD per year, with zero upfront investment. Even after adding AWS Enterprise Support—a must for mission-critical workloads—the annual cost of around remained significantly lower than maintaining equivalent on-prem hardware and operations.Beyond cost, AWS offers greater scalability, automatic failover options, managed backups, and rapid provisioning—all without the long lead times and rigid constraints of physical infrastructure. For organizations seeking agility, reliability, and long-term efficiency, the cloud isn’t just an alternative—it’s a strategic upgrade.
