> For the complete documentation index, see [llms.txt](https://documentation.grax.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.grax.com/technology/overview/operating-costs.md).
# Operating Costs
This page covers what GRAX infrastructure costs to run on AWS, Azure, and Heroku, and how to keep those costs down.
## Base Costs
GRAX-managed minimum requirements are a VM with 4 vCPUs and 16 GB of RAM, as well as a Postgres database server with dedicated capacity. These minimum requirements support small Salesforce orgs with 20 GB of data.
On AWS a base deploy costs **$260.65 / mo** for the recommended `m8g.xlarge` EC2 instance and Aurora Postgres Serverless:
* $131.05 / mo (m8g.xlarge)
* $129.60 / mo (1.5 Aurora Capacity Units)
Note that Aurora Serverless auto scales and is billed based on consumption.
On Azure a base deploy costs **$384 / mo** for the recommended `Standard_D4s_v3` VM and a `GP_Standard_D4s_v3` Azure PostgreSQL Flexible Server:
* $138.24 / mo (Standard\_D4s\_v3)
* $246.24 / mo (GP\_Standard\_D4s\_v3)
On Heroku a base deploy costs **$700 / mo** for the recommended `Performance L` dyno and `Premium 0` Heroku Postgres:
* $500 / mo (Performance L dyno)
* $200 / mo (Premium 0 Heroku Postgres)
Note that you may also want a Heroku Private Space which adds extra base costs.
Larger Salesforce orgs may need a larger VM or database to process data without issues, so your final costs may vary. Work with your cloud provider or contact [GRAX Sales](mailto:sales@grax.com) for help estimating costs for your org.
## Cloud Cost, Usage and Optimization
GRAX takes full advantage of the public cloud to support Salesforce orgs of any size and volume: automatic high availability, effortless vertical scaling, and consumption-based pricing.
GRAX proactively monitors the health of your data and alerts you to problems affecting backups. For GRAX-managed environments, GRAX also provides one-click tools to vertically scale your VM or database when needed.
The only tradeoff is that your cloud costs may vary over time and are hard to predict.
We highly recommend deploying GRAX with the minimum requirements, starting backups, then reviewing your cost and usage after 30 and 60 days. After this time your Salesforce data will be fully protected and your average cloud costs will be fully understood.
If the cost of resources is deemed too high after this time, you can:
* work with your cloud provider to buy reservations at a discount
* work with your Salesforce admin to reduce data change volumes
* work with GRAX Support to discuss deployment and product optimizations
And of course at any time you can discontinue your use of GRAX and stop all cloud resources and costs.
## Cloud Providers
### Amazon Estimate Calculator
A pre-configured estimate of the high-level AWS resources necessary for GRAX is available [here](https://calculator.aws/#/estimate?id=3c415d7c23a5673340bdb32f854297b71900af72).
All prices set by AWS are subject to change by AWS at any time; see their [pricing documentation](https://aws.amazon.com/pricing/) for more information. GRAX isn't responsible for changes to AWS pricing.
### Azure Estimate Calculator
A pre-configured estimate of the high-level Azure resources necessary for GRAX is available [here](https://azure.com/e/30cdc58d64e1430caca8f6ee2426bd6a).
## Frequently Asked Questions
What contributes to base or static costs?
Costs that can be determined prior to usage, like the hourly cost of an EC2 instance given a 24x7x52 uptime, are considered static. These sections of the estimate aren't expected to change, regardless of GRAX features used or data processed.
What contributes to variable costs?
Many networking and storage services in the public cloud bill entirely based on usage, and GRAX's use of RDS, S3, and NAT Gateway services is no exception. The estimate above includes best-attempt estimations of usage under a typical app load. GRAX provides no guarantees as to the accuracy, in either direction, of these estimates.
Many factors can affect total realized costs:
* Usage of specific GRAX features
* Total Salesforce org size
* Turnover rate of Salesforce records (created and changed per hour)
* Number of files in Salesforce (each file is downloaded and stored)
* Disk and memory cache sizes ([`/tmp` and memory sizes](/technology/requirements/technical-requirements.md))
* Cross-provider storage connections (for example, AWS compute with Azure storage bills extra)
* Public vs. private traffic routing (exiting the VPC may incur NAT costs)
What do self-managed deployments cost?
GRAX Self-Managed supports whatever cloud architecture your company requires for security and compliance reasons. The architecture and related costs are ultimately up to you, and GRAX can only offer guidance on minimizing them, such as keeping storage traffic private and providing enough cache space.
Why should storage traffic stay inside my VPC or cloud provider?
Traffic leaving the VPC crosses the NAT Gateway and incurs much higher costs. GRAX reads many terabytes of data as it [compacts and processes your datasets](/technology/overview/blob-storage.md#how-it-works), so this difference adds up. Never route storage traffic outside the VPC or cloud provider, including traffic from an AWS EC2 instance to Azure storage or any other similar mismatch in infrastructure providers.
How does cache size affect costs?
Low cache size, in both memory and disk, leads to frequent read operations from storage and drives up overall data transfer. Where data transfer incurs cost, this can become very expensive. See [Technical Requirements](/technology/requirements/technical-requirements.md#cache-disk) to make sure your GRAX hardware operates within safe limits.