Amplify App Multi Regional Tenancy
How to manage your Amplify app with data isolation and Multi Tenancy.
Multi Tenancy
Multitenancy is that multiple customers of a cloud vendor are using the same computing resources. Despite the fact that they share resources, cloud customers aren’t aware of each other, and their data is kept totally separate. Multitenancy is a crucial component of cloud computing; without it, cloud services would be far less practical. Multitenant architecture is a feature in many types of public cloud computing, including IaaS, PaaS, SaaS, containers, and serverless computing.
Types of Multitenancy
- Multiple Tenant Database
- Multiple Tenant Application
Multiple Tenant Database
In this model the application layer is commonly shared among all the tenants. For example, if the application server layer contains 4 clustered servers, then all the 4 servers can serve any of the clients. However, when it comes to database it is separated by tenant. The level of separation is determined by the tenant architecture.
Different schemas within the same database — where each schema can contain the tables for the respective tenant
Different Databases within the same machine — Each tenant gets a different database. This gives the flexibility to provide specific services like customized back-up and restore services. For example, one of the tenants may request for backing up the DB everyday night and email it to their FTP site. Supporting this request is easier in this model.
Different Databases residing on different machines — Independent machines are allocated for each tenant. This provides the highest level of security from a data isolation/storage perspective. This model also helps in dealing with varying level of usage scenarios. For example, if a tenant is going to use it extensively and the data growth rate is going to be extremely high then you might want to have an extra-large instance as your DB server. On the other hand, for normal usage a medium instance should be sufficient. of course, you will be charging the customer based on the infrastructure required for them. But the key is this model gives you the flexibility.
Multiple Tenant Application
This is the inverse of the previous model. Here the DB layer is kept common across all the tenants, but the application layer is isolated. There are couple of scenarios where this model might come handy,
Metering — just like in the previous case for DB, if you want to meter the usage of this layer and charge the tenant accordingly then this model gives you that flexibility. You can also go for different instances for different tenants depending on their need.
Customization — in case if your application is customized for a specific tenant, then this model allows you to run customized application for each of the tenants. Customization could be in the form of change in business logic, rules, display, etc. However, the DB layer remains constant across the tenants.
Conclusion
To achieve multiregional tenancy, We need to consider certain points.
- Data needs to be stored in tenant location.
- API gateway and Lambda functions are regional in AWS.
- We can create different Amplify app for specific region.
- Manage tenant configs.
The best approach to achieve multiregional tenancy with Amplify app is, to create different amplify app on the tenant region [where this will create API and Lambda functions in the same region]. Refer IMG 1 for architecture diagram.
Tenant specific configurations we can manage through amplify environment variables[tenantConfig={…”region”:”us-east-1",”name”:”tenant_name”}].
Connect same source code repository to all regional app which will help us to maintain single source code deployment.
Create and manage different DB instance in the tenant preferred region. This will help us to isolate the tenant specific data.
This method of managing app is directly satisfying Multiple Tenant Database-Different Databases residing on different machines approach.
