The workloads that do not belong inside Salesforce.
Heavy compute, long-term storage, cross-system analytics, and anything that would eat your API limits belongs next to Salesforce rather than inside it. We architect that side properly the first time — VPC, IAM, infrastructure as code — so the account is auditable and the bill does not surprise you in month four. Cost work is part of the design here, not a clean-up we sell you afterwards.
- Shape
- Fixed-scope project
- Typical length
- 4–12 weeks
- Priced
- Scoped from the architecture review
- Starts with
- An architecture review
- You keep
- Infrastructure repo, cost alerts, access model, runbook
Twelve weeks, and the first two decide the other ten.
Drawn to scaleWhat we build on the AWS side.
Four areasThe review comes first and it decides the rest — including, sometimes, that the answer is to switch things off rather than build.
The architecture review
Every engagement opens with one. It covers what you run now, what it costs, and — the answer people least expect — which parts of it Salesforce should stop doing. The first recommendation is often what to switch off.
Foundation as code
Written as Terraform or CDK, so the account can be rebuilt from the repository rather than remembered:
- Network — VPC, subnets, routing, and private connectivity to what needs it
- Identity — IAM roles scoped to the job, with guardrails on what the account can do at all
- Accounts — separation between production and everything else, enforced rather than agreed
- Budgets — cost alerts wired at setup, not after the first surprising invoice
Workloads
Whichever the review picked:
- Serverless processing — Lambda consuming Salesforce Platform Events, so the org publishes and stops waiting
- Migration — moving a legacy system off its own hardware, with a rollback that actually works
- Storage lifecycle — S3 with tiering, so archived data stops being billed at hot-storage rates
- Analytics layer — QuickSight, Athena or Snowflake, reading the cross-system view Salesforce alone cannot give you
Salesforce-adjacent by design
The point is not “we also do AWS”. It is that the two sides are designed together: what stays in the org, what moves out, what crosses between them, and which API limits that crossing spends.
You keep the infrastructure repository, the budgets and cost alerts, the documented access model, and the runbook.
The handover
What you are left holding.
An AWS account you cannot rebuild from a repository is a liability. That is the test we build against, and these four are what passing it looks like.
- The infrastructure repositoryTerraform or CDK in your git. The account can be rebuilt from it, which is the only real test that it is documented.
- The cost alertsBudgets, anomaly detection and per-service alarms set during the build, so month four is not a surprise.
- The access modelIAM roles, permission boundaries and who can do what — written down rather than inferred from the console.
- The runbookHow it deploys, what breaks first, and what to check at 2am.