I have a Risk Agent workflow built in Make, where Google Drive currently works as the main file storage layer. I’m now considering moving that storage part to Amazon Web Services (AWS), specifically Amazon S3.
My goal is to understand whether the Google Drive storage layer can be replaced with Amazon S3 while keeping most of the existing scenario logic unchanged.
What is the problem & what have you tried?
Right now, the Google Drive part of the scenario handles things like:
• watching or receiving files
• searching for files
• getting and downloading files
• uploading output files
• moving files
• creating a folder structure for organized storage
The rest of the flow includes processing and AI-related steps, so ideally I would only replace the storage side and keep the rest of the scenario as similar as possible.
At this stage, I’m trying to understand whether this kind of migration is realistic in Make, and whether there are any important differences or limitations when replacing Google Drive with Amazon S3 in this type of workflow.
Has anyone done something similar?
Error messages or input/output bundles
No specific error yet — this is an architecture / migration question before I start rebuilding the scenario.
To be honest, I’m afraid there is no simple yes/no answer to your question.
Can it be replaced? It depends on your workflow.
Can it be done automatically - like you click one button and puff, everything changes? Not really. You can use the Make DevTool Chrome extension, which will replace your app, but changing the logic and mappings must be done manually.
Where will you face problems? Make.comAmazon S3 app does not offer a native “Watch” module, so there is no direct substitute for Watch Files in a Folder, Watch Folders, or Watch All Files modules. So if you want to trigger scenario when change occurs you must build solution for that.
Also, Amazon S3 identifies files by bucket name and object key (file path), meaning there is no stable file ID like in Google Drive which is independent to file name (I’m referring to the default setup).
So you must analyse your workflow step by step and then decide. Here you will find Make’s S3 app documentation:
S3 has no concept of folders like Google Drive. If you work on a team and you need to share access to a specific folder etc, that’s also going to be a problem.
S3 is just a file store, whereas Google Drive is a “solution”.
You can set up webhook triggers to mimic the watch functionality, but basically alot of the things you get out of the box with Google Drive, you have to make your own with S3 because it’s really the lowest layer in the tech stack.
A better question to ask here is why do you want to move from a solution like Google Drive to S3? S3 is probably a better choice if you are storing thousands of files, foldering is not a priority, cost is a priority, and accessing the files by your team through a web browser is not a priority.
@mszymkowiak Thank you for the feedback. I will look into the AWS S3 documentation and analyze it. @zbk28382 Unfortunately, this may have been a decision made by upper management (the CEO) to change the location where all data is collected and stored.
I logged into AWS S3 and saw options to create folders, similar to Google Drive.
Can I share access to the entire bucket, or only to the top-level folder, with access inherited by the subfolders?
So theres a button there that says “create folders”, but it is definitely not similar to Google Drive.
Technically you can limit access with IAM permissions to specific folder paths (“my/folder/*”) for specific IAM users, sure.
But I would caution against trying to get S3 to work like Google Drive. You’ll just be reinventing the wheel and it could lead to misconfigurations and data exposure.
If the management decision was due to data sovereignty concerns etc, there’s a number of cloud storage providers on Make and elsewhere that are closer to Google Drive (and most likely are built on top of s3 too). It sounds like that’s a better fit for what you are looking for than just raw S3.