Since GRAX can operate in a large number of unique infrastructures and the app uses subsystems that can undergo any number of unique configurations, exact analysis of costs isn't possible. For our purposes, we are going to calculate the expected cost for a standard AWS GRAX installation. The data provided here helps demonstrate how you may perform the same analysis in your specific architecture.
This isn't the cost of contracting for a GRAX license - this is your internal cost of running GRAX.
A pre-configured estimate of the high-level AWS resources necessary for GRAX is available here.
A pre-configured estimate of the high-level Azure resources necessary for GRAX is available here.
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. All prices set by AWS are subject to change by AWS at any time, see their pricing documentation for more information. GRAX isn't responsible for changes to AWS pricing.
Many networking and storage services in the public cloud bill entirely based on usage. When it comes to GRAX's usage of RDS, S3, and NAT Gateway services, there is no exception. The estimate above includes best-attempt estimations of usage when under a typical app load. GRAX provides no guarantees as to the accuracy, in either direction, of these estimates.
There are many factors that can affect total realized costs:
- Usage of Specific GRAX Features
- Total Salesforce org Size
- Turnover Rate of Salesforce Records (created + changed per hour)
- Number of Files in Salesforce (each file gets downloaded and stored)
- Disk and Memory Cache Sizes (
/tmp+ memory sizes)
- Cross-Provider Storage Connections (AWS to Azure, etc. traffic bills extra)
- Public vs. Private Traffic Routing (exiting VPC may incur NAT costs)
As a product of the cost-affecting parameters above, here are the biggest considerations for avoiding high costs with GRAX infrastructure:
Never route your storage traffic external to the 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 so this difference adds up. This includes traffic from an AWS instance to Azure storage, or any other similar mismatch in infrastructure providers.
Low cache size, in both memory and disk, can lead to extremely frequent read operations from storage and thus drive up overall data transfer. In infrastructures where this incurs cost, this can become very expensive. See our technical specifications for GRAX hardware to ensure you're operating within safe limits.
Almost all popular public cloud providers offer some form of discount in exchange for year-or-longer commitments to a minimum expenditure. On AWS, the most applicable version of this is Reserved Instances. By agreeing to "spend" a minimum amount in a specific Region for specific Instance Types, an AWS customer can save a significant amount of money over a 12 month period compared to On-Demand rates for the entire year. For non-standard environments regardless of cloud, these agreements are external to GRAX and can be negotiated between customers and providers directly. Ensure that any created agreements align with documented technical requirements as well as what's deployed within your environment before committing.
While GRAX has no inherent incompatibility with Reserved Instances or similar options, GRAX makes no guarantees as to the consistency of minimum instance requirements, instance count requirements, or the consistency of resource usage across releases. As GRAX releases updates, usage of infrastructure components (including storage, database, networking, memory, or disk) may change significantly and without warning. GRAX isn't responsible for incorrect or invalidated commitments.
Updated about 3 hours ago