While Grax provides you the ability to store data in your own storage provider, owning that storage does come with an operational cost. These costs can be estimated using online cost calculators so that you can adequately budget for the year. If you have a Cloud Services team, it is best to involve them in the estimation process as your company may have negotiated better rates than are available online and also may have configured additional Cloud Resources that are not typically included in our recommended setup.
- Total data size of Salesforce files & data
This can be found in Salesforce from
- Total number of Salesforce Records
This can also be roughly estimated from the Storage Usage page within Salesforce.
- Average monthly data change
What percentage of your data in Salesforce is modified or created each month? This input is tough to calculate, so this will initially be based on intuition. After the first month’s use of Grax in production, you will be able to more accurately estimate this.
Storage usage tab is an estimate
Some standard objects do not display on this page, such as order items, opportunity line items, and quote line items. See the Salesforce documentation for more information.
Additionally, salesforce only estimates the data size as 2KB per record. The actual data size may vary slightly higher or lower when stored in S3.
- S3 Standard Storage. This should account for the initial data size in your Salesforce org, plus the additional incremental change of data your expect per month
- S3 Standard PUT requests. Grax writes data to storage as encrypted, compressed blobs, each of which could have hundreds or thousands of records' data within. For the SFDC file binaries, however, each of these will use one PUT request.
This example is an estimate only!
This example uses publicly available pricing information from AWS. Your actual rates vary by region and your company may have negotiated discounted pricing with AWS directly.
Let’s make some estimates for the inputs described above:
P1 = Total data size of Salesforce files & data. In the screenshot above, my org has 20 GB of Data and 1.9 GB of files which we will round up to 22 GB of storage.
P2 = Total number of Salesforce records. Looking roughly at the storage usage screen, I can see that I have about 15 million records. We don’t need to be exact, because in production environments this number is always changing anyway
P3 = Average monthly data change. I don’t have a lot of automated processes, so I’ll estimate a 5% increase on a monthly basis. Make sure you consider any integrations or 3rd party managed packages that may be mass updating your records. Additionally, if you are planning a data migration in the near future, you would want to include those numbers as well.
As of the writing of this article, publicly available S3 costs for the Region US-EAST-1 are:
- A1 = S3 Standard Storage. $0.023 per GB
- A2 = S3 Standard PUT requests. $0.005 per 1,000 requests
With all our inputs, we can now derive formulas and estimate costs:
(22 $0.023) + ((15,000,000 / 1000) $0.005) = $0.51 + $75 = $75.51
(22 5% $0.023) + ((15,000,000 5% / 1000) $0.005) = $0.03 + $3.75 = $3.78
- The operational cost of Grax is much lower than the initial backup due to the volume of records.
- It costs much more to move data to storage than it does to keep it there. Your costs can roughly be attributed to the types of backup process you run from Salesforce. For example, if you wanted to run a full backup of all your data every month, regardless of changes to the records, you could expect an increase of the initial backup in your AWS bill. The same would be true of any sandbox environment you also want to backup. If your company mandates a full backup of sandbox data, this should be included in your cost calculation.
Grax gives the ability to be very selective about the data that you backup. If you are being conscious of S3 costs consider the following:
- After the initial full backup, only run incremental backup which capture data that has actually changed
- Do not backup objects on more than one incremental job
- If archiving, there is no need to run a backup job before running the Archive, Grax will do this automatically.
- If you enable time machine on an object, do not run a backup job for that object unless you have disabled time machine for a certain period of time to perform a mass update
- Avoid running full backups in sandboxes
KMS Encryption - KMS encryption has an additional cost for requesting and using encryption keys. Grax requests tokens every time you write or retrieve a file to storage or retrieve. The cost varies based on the type of encryption key your company uses.
IAM Assume Role - Assume Role charges can be seen on your bill as STS token requests. This cost varies depending on the Time To Live (TTL) value set for this role. The standard implementation is 12 hours. Grax makes one token request per process instance.
The Grax product is constantly evolving to be faster and more efficient with its use of resources. Keep this in mind when updating to a newer version of Grax as certain features of Grax may leverage additional resources that incur a cost.
Updated about 2 months ago