Multi-Tenant SaaS Application Using AWS EKS & Deployment models – Part 3

A continuation of part two of the blog.

AWS provides several cloud-enabled solutions, which in effect, can be utilized as the following SaaS deployment models:

Tenant Isolation at the Container Layer

Containerization platforms such as Docker or Kubernetes use containers to isolate the application and data within its context.

By design, different workloads can share the same cluster, with some level of logical or physical isolation between them. In this model, all the deployments for tenant solutions are in the same AWS account, but the level of separation is at the namespace level.

We can achieve tenant isolation for each tenant application by using namespaces. The SELinux runtime environment provides a separate namespace for every tenant deployment. This ensures a logical separation between tenants. The stack consists of Kubernetes operators as the runtime that manages the application and an application custom resource instance and a database custom resource instance.

AWS provides containerization through several services such as AWS ECS (Elastic Container Service), EKS (Elastic Kubernetes Service), and AWS Fargate. In the case of Kubernetes, multi-tenancy can be achieved by leveraging namespaces and a Platform-as-Code approach to build a multi-tenant SaaS solution on a Kubernetes cluster.

In the realm of physical isolation, multi-tenant PaaS solutions can provide the orchestration power of Kubernetes and the runtime isolation through namespaces to build a secure multi-tenant platform. Rancher, a multi-tenant Kubernetes as a service solution, is a good example of such a service.

Rancher can be used to deploy multiple containers separated by namespaces, with groups of applications and databases combined in a database-per-service design pattern.

Pros:

• Since there is no theoretical limit to the number of namespaces that can be defined, this model is highly extensible for the organization.
• Application customization is specific to each tenant. It does not interfere with others as the data is isolated for each tenant.
• Amazon EKS provides an RBAC implementation that allows IAM users, thereby helping to gain control over the other layers of isolation.

Cons:

• With many namespaces, the complexity of the system may become substantially higher to manage.
• As a best practice, it is recommended to keep the master and worker nodes secure. This may be difficult with multiple tenants sharing the same worker nodes, which increases the attack vector surface area for hackers.
• If the network policies allow network communications between namespaces, traffic between namespaces can become a security loophole.

Tenant Isolation at the Data Layer

At the database level, an application requiring a multi-tenancy architecture can adopt one of the following database architectures. In a typical 3-tier application having shared web and application layers, minute variations can exist at the database layer. The following figure shows possible multi-tenant architectures, assuming that existing applications may have to be re-architected in a tenant-aware fashion. AWS provides its portfolio of compute and database services for this purpose.

a) Instance Isolation: The first design involves complete isolation of the application’s compute instance as well as the associated database. The design will require the most compute and storage and can have customized security policies, user interfaces, and database design. However, this may be much more costly and difficult to maintain. Further, depending on certain compliance and security requirements, co-hosting tenants with different security profiles may not be possible. AWS provides this by design, with its current web service offering.

b) Single Instance, Separate Databases: Each tenant will have a different database for maximum isolation. To enable the application layers to pick the right database upon each tenant’s request, it would be required to maintain metadata in a separate store (such as Amazon DynamoDB) where the mapping of a tenant to its database is managed.

c) Single Database, Separate Tables/Schemas: Different database flavors have different constructs, but another possible deployment model could be that each tenant’s data resides in the same database. However, the data is tied to different schemas or tables to provide a level of isolation.

d) Single Database, Shared Schema/Tables: In this model, each tenant’s data is placed together. A unique tenant ID column separates data records for each tenant. Whenever a new tenant needs to be added to the system, a new tenant ID is generated, additional capacity is provisioned, and traffic routing to an existing or new stack gets initiated. Although difficult to architect, this is the most optimized architecture which results in economies of scale, higher resource usage, is easier to provision & maintain, and is a cheaper tenancy model with shared components. Its limitations are exposure and vulnerability to shared attack surfaces, lesser control over the environment and customizations, and that in the event of failures, all tenants can be affected.

Pros:

• By utilizing shared components (part d of the above architecture), the design provides the best economies of scale and hence, is the cheapest option to operate at scale.
• It is easier to manage, maintain, and rollback as there is a single deployment, whether in the single database separate schema or the single database shared schema design.
• This usually involves a single VPC design; however, even if multiple VPCs are deployed, they would be only be limited in number.

Cons:

• Since the application architecture needs to be multi-tenant aware, applications that do not have multi-tenancy may need to be re-architected.
• Security requirements may mandate an entirely separate implementation; in which case, it would be difficult to utilize this architecture style.

Conclusion

Multi-tenancy architecture allows organizations to efficiently serve customers from all strata, ranging from small and medium customers (whose scale may not require dedicated infrastructure) to large enterprises (that require access to the cloud’s virtually unlimited and indispensable resources). Shared software development and maintenance costs, reduce expenditure, leading to savings that are passed onto the customers.

Read Part 1 and Part 2