Welcome to the multitenancy multi series blog. In this series, we shall delve into a comprehensive overview of multitenancy, including its architectures, use cases, and implementation.
Introduction:
Tenants are typically a single user or a group of users, such as client organizations, who have similar access and permissions to the application instance. The application instance will segregate all tenants’ data to ensure its security and privacy.
Multitenancy can occur at any level, including databases and the cloud. Technically, multitenancy refers to the deployment of a single software program or service that caters to a large number of users or clients, ensuring their separation from each other. By sharing infrastructure and code, this method maximizes resource usage and cost efficiency.
Multitenancy Architectures
Single Database, Separate Schemas
This architecture stores all tenants’ data in a single database, yet each tenant maintains its own schema. This architecture provides strong isolation among tenants while still allowing for efficient data management. It is appropriate for cases in which tenants share similar data structures but require data isolation.
Database-per-Tenant
Every tenant has its own database instance. This method provides the highest level of data isolation, but it can be resource-intensive and costly. It’s useful for scenarios that require strong data separation.
Micro-services with API Gateway
Tenants are served by individual microservices, each with its own database. An API gateway handles tenant-specific routing and authentication. This technique offers flexibility, scalability, and strong isolation.
Account level isolation
Each tenant or customer receives their own dedicated AWS account in a multi-tenancy architecture with separate AWS accounts. This architecture offers strong isolation, security, and scalability among tenants. Tenants manage their AWS resources separately, with IAM policies controlling access.
Separate VPCs achieve network isolation. Each tenant handles monitoring, billing, and disaster recovery separately, enabling more customized solutions. This method is best suited for cases requiring data separation and security, such as SaaS apps or managed service providers.
Here we will be examining the concept of Account Level Isolation.
Multi Tenancy at Account Level
For multi-tenancy, using separate AWS accounts is a reliable method that ensures strong isolation and security between tenants. Here’s a high-level overview of a multi-tenancy architecture with separate AWS accounts:
Tenant Isolation
We assign each tenant its own AWS account. Tenant resources, data, and configurations remain completely isolated from each other due to this separation.
Identity and Access Management (IAM)
AWS Identity and Access Management (IAM) controls access and permissions to each tenant’s AWS resources. IAM policies ensure granular access control, allowing tenants to access only their own resources.
Networking – Virtual Private Cloud (VPC) isolation
Each tenant typically has its own VPC, which provides network isolation. This prevents tenants from interacting directly with each other’s resources. Each tenant receives outbound internet access through Network Address Translation (NAT) gateways or instances.
Resource Scaling
Each tenant’s AWS account can independently scale its resources based on its own requirements and usage patterns. This ensures that one tenant’s resource demands do not impact others.
Monitoring and Logging
We use AWS CloudWatch and CloudTrail to monitor, log, and audit tenant-specific activities. This facilitates troubleshooting and security monitoring.
Backup and Disaster Recovery
Each tenant can implement backup and disaster recovery strategies based on their specific needs and compliance requirements.
Billing and Cost Allocation
You can use AWS Organizations to track individual tenant usage by providing cost allocation tags and consolidating billing across all tenant accounts.
Tenant Onboarding and Offboarding
You can set up automated processes for tenant onboarding and offboarding. When adding or removing tenants, you can automate the provisioning and de-provisioning of resources and permissions.
Cross-Tenant Functionality
You can set up a shared services or central admin account to manage functions that need to span across tenants, such as global authentication or reporting.
This architecture offers a strong separation between tenants, making it ideal for scenarios requiring security and data isolation, such as SaaS applications or managed service providers. It allows tenants to control their resources and configurations while centralizing administrative tasks.
When properly implemented, it offers a scalable, secure, and easily manageable multi-tenancy solution in the AWS cloud.
Stay tuned for our next blog post, where we’ll explore a real-time handling of a multitenancy use case.
Amuthavarsni Rajkumar
