Does a Zoho CRM need AWS at all?
Most of the time, no. Zoho CRM, Zoho Analytics and Zoho Flow cover reporting and everyday automation for a typical small or mid-size team. AWS starts to make sense when you need to keep and query a lot of history, run work that is too heavy for CRM functions, or give customers a custom app.
We say this first because we are partners on both sides. We could sell you AWS for any problem, and that would be a mistake. A cloud account brings bills, security settings and someone who has to look after it. If Zoho can do the job with a workflow rule or a report, that is cheaper to run for years.
The picture changes as a company grows. Sales data stays in Zoho, but the product, the warehouse system or the billing engine creates far more data than the CRM was ever meant to hold. Teams start asking questions that cross all of it. That is where the three patterns below come in.
Why put a data lake on Amazon S3 next to Zoho?
Because a CRM is built to run today’s work, not to store every event your business has ever produced. A data lake on Amazon S3 keeps the full history cheaply, in open file formats, so you can query CRM records next to product, order and finance data without slowing Zoho down.
Think of a software company with a few thousand customers. Zoho CRM knows the accounts, deals and renewal dates. The product database knows logins, feature use and support events, often millions of rows a month. Putting all of that into CRM fields would bloat records and burn storage. Leaving it apart means nobody can see which accounts are quietly using less before renewal.
A lake solves it in a simple way:
- Zoho CRM data lands in S3 on a schedule. The Bulk Read API in Zoho CRM exports large record sets as files, so a nightly job can copy changed records without hammering the normal API.
- Product and order data lands beside it. Each source gets its own folder and file format, with the date in the path.
- Questions run where the data sits. Amazon Athena can query the files directly, or you load the busy tables into Amazon Redshift.
- Answers go back to the people who need them. Zoho Analytics can read from Redshift, so sales leaders see usage next to pipeline in a dashboard they already open.
The lake also gives you a long-term copy of CRM history that lives in your own AWS account. That matters to finance teams and auditors, and it makes a later move or upgrade far less scary.
Where should heavy jobs run: in Zoho or on AWS?
Light, record-by-record logic belongs in Zoho, as workflow rules, Blueprints and Deluge functions. Long, bulky or compute-hungry jobs belong on AWS, where AWS Lambda or a container on Amazon ECS can run them, then write a short result back into Zoho.
Deluge functions are great for “when a deal closes, create the project and email the team”. They have execution limits per call and per day, which is fair for a shared platform. Problems start when a function tries to do something that is really a batch job:
- Re-scoring every lead each night against data from three systems.
- Generating hundreds of PDF statements or contracts at month end.
- Resizing and checking photos or documents that field teams upload.
- Pulling a supplier price file and updating thousands of products.
On AWS each of these becomes a small, separate service. A queue such as Amazon SQS holds the work, Lambda or ECS processes it at its own pace, and only the final status goes back to Zoho, through the API, as one update per record. The CRM stays quick for the sales team, and the job can retry on its own when something fails. For lighter custom logic that mostly touches Zoho data, Zoho Catalyst is often the simpler home, and we will tell you when it is.
When does a customer portal belong on AWS?
When the portal is a product in its own right. Zoho CRM’s built-in portals cover many needs, like letting clients see their cases or invoices. Build on AWS when you need your own design, heavy traffic, complex logic, or data that does not live in Zoho.
Typical examples we see: a distributor that lets dealers check live stock and place orders, a lender that shows applicants each step of their file, or an installer that shares project photos and signed paperwork with homeowners. In each case the portal needs to read CRM data and write some of it back, but it also needs its own database, its own login rules and a fast page load on a phone.
On AWS that usually means Amazon Cognito for sign-in, an app on Lambda or ECS behind Amazon API Gateway, a database on Amazon RDS, and Amazon CloudFront in front so pages load fast across the country. Zoho stays the system of record for customers and deals. The portal keeps only what it must and syncs the rest.
What does a Zoho + AWS setup look like?
Three zones: Zoho apps on the left, a thin connecting layer in the middle, and AWS services on the right. Pick a pattern below to see which pieces it uses.
Zoho
Zoho CRMaccounts, deals, owners
Zoho Booksinvoices, payments
Zoho Analyticsdashboards people open
The bridge
API Gatewaywebhooks in, checked
SQS queueholds work if Zoho is busy
Lambdamaps, retries, writes back
AWS
S3 data lakefull history, queried by Athena
ECS jobslong batch work
Portal + Cognitocustomer logins, RDS data
The middle layer is the part people skip, and the part that saves you later. Without it, every new use becomes another script calling Zoho directly with its own keys and its own idea of error handling. With it, there is one place to check signatures, queue work, retry failures and log what happened.
How do Zoho and AWS talk to each other safely?
Through Zoho’s APIs and webhooks, with credentials stored in AWS, the narrowest permissions that do the job, and a queue in between so a busy or offline system never loses data.
- Zoho to AWS. A workflow rule fires a webhook to API Gateway when a record changes. The endpoint checks a shared secret before anything runs.
- AWS to Zoho. Lambda calls the Zoho API with an OAuth connection kept in AWS Secrets Manager, never in code.
- Least privilege. AWS IAM roles let each function touch only its own bucket or table, and the Zoho connection gets only the scopes it uses.
- API limits respected. Zoho plans include a set number of API calls, so jobs batch their writes and back off when Zoho asks them to.
- Everything logged. Amazon CloudWatch keeps a record of each run, and failed items wait in a dead-letter queue for a person to check.
For simple hand-offs between apps, a no-code tool may be all you need; our data sync guide covers those cases. The setup above is for when the data is large, the logic is yours, or the link has to keep working at 2 a.m. without anyone watching.
What does running AWS next to Zoho cost?
Your Zoho plan stays the same. AWS bills by use, so a small lake and a few functions can stay modest, while a busy portal costs more. Our build is one fixed price in a signed BRD, set from your scope.
We do not quote AWS dollar figures in an article because they depend on your data volume, traffic and AWS Region. What we can say is where the money goes: storage in S3, queries in Athena or Redshift, compute for Lambda or ECS, and data transfer out of AWS. Before anything is built we size each piece from your real numbers and show you a monthly estimate.
Two cost habits help from day one: keep raw data in S3 storage classes that suit how often you read it, and tag every resource by team so the bill reads like a list of owners. Our AWS consulting page shows how we review a bill, and the AWS migration checklist helps if you are also moving servers to AWS.
Add AWS when
