handling multi sites client per envr in a application

Question

**Hi team,**

I'm currently managing an AV solution running on AWS with the following flow:

1. A client requests a presigned URL via API Gateway, backed by a Lambda function. The client receives this presigned URL.
2. The client uploads a file to `bucket1` using the presigned URL. An S3 event notification is then triggered, sending the event to an SQS queue.
3. A Node.js application running inside ECS Fargate polls the messages from the queue, performs a file scan in parallel, and then sends the result to another SQS queue (`queue2`).
4. Another Lambda function polls `queue2` and notifies the original caller via an API call, using access tokens provided by that client.

Now, there's a new requirement to support multiple sites per environment (e.g., `client_source_dev1`, `client_source_dev2`, `client_source_dev3`, `client_source_stg1`, etc.).

I'm wondering what the best approach would be to adapt to this requirement:

- **Option 1:** Redeploy the entire AV infrastructure within the same environment (for each environment as much as there are a client site by envr: example if we have: `client_source_dev1`, `client_source_dev2`, `client_source_dev3`==> redeploy the AV infra 3 times in DEV so each one deal with each dev caller_source), configuring it to notify each client-source site with the relevant access tokens... (higher costs)
- **Option 2:** Keep a single AV stack/infrastructure per environment and configure it to handle multiple sites of the same caller-source within that environment. or add more lambda notifier... how can i modify the current solution to handle multi-site par envr. error handling, alarm error notification, how can handle cloud watch alarm for application failure should i create 1 CW alarm by caller_source or on single alarm with multi dimentions (1 dimension for each caller_source)....

Any insights or recommendations would be greatly appreciated!

Thank you.

Dmitry_G · Answer

Hi,

It seems like you are trying to convert an existing application to support multi-tenancy, given the provided requirements. Thus, I would strongly suggest you to review [AWS Well-Architected Framework SaaS Lens](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-lens.html) for more information on best practices and recommendations for multi-tenant environments. There are multiple new design considerations that you must take into account now.

For example, if you consider to share the same SQS queue between multiple clients/tenants, you will have to adjust your design so that messages from one client do not block or significantly delay messages from other clients ([Noisy Neighbor](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html)). There is a blog post covering different design approaches for [Using Amazon SQS in a Multi-Tenant SaaS Solution](https://aws.amazon.com/blogs/apn/using-amazon-sqs-in-a-multi-tenant-saas-solution/).

All in all, you might want to search more information on multi-tenant and SaaS enabled patterns since that is your new requirement.

Best regards,

Dhanyashree_S · Answer

Hello,

Thank you for explaining your use-case in details.

As per my analysis on your use-case, I would suggest you to kindly go with option2 for your architecture. However, this may require you to modify your Lambda code's and make sure that the environment behaves different for each of the client's available.

I understand that this may be additional work for you, however, with option1 this would be most expensive option. You'd incur costs for multiple instances of ECS, Lambda functions, S3 buckets, and other resources in each environment.

With Option 2, a single AV infrastructure that handles multiple client sites within the same environment—is recommended because it is cost-effective, easier to manage, and scalable. This approach allows you to share resources across sites, reducing duplication and lowering costs. It also centralizes management, making updates and maintenance simpler. Although it requires careful design to handle multiple sites securely and efficiently, the benefits of reduced operational overhead and improved scalability make it the more practical solution for most scenarios.

handling multi sites client per envr in a application

Relevant content