A continuation of part one of the blog series.

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

Multi-tenancy Isolation Through the Governance Model

In the governance model, all the tenants can be attached to a master (root) organization account (OU), which manages all the accounts associated. Organizational accounts can provide separations of concerns with account-level isolation. The AWS Organizations service helps in defining central configurations, resource sharing across accounts in the organization, and account & group creation. Its policies can be automated to reflect business needs by using governance. Billing for all accounts can be simplified by setting up a single payment method for all the owner AWS accounts, and cost reports can be ascertained for each account separately.

Pros:

• Resources can be shared across accounts with effective utilization of services.
• Consolidated billing allows the organization to have a full overview of the tenant’s expenses.
• OU level-isolation is the maximum level of isolation available. Thus, it should be used only for premium-level customers by a SaaS provider.

Cons:

• As each root account will be bound by its OU limits, this model may not be very scalable.
• More difficult to set up and maintain as there can be shared services in place, and an impact on a shared service may affect all the tenants. However, individual services being used by each account will not be impacted.
• This model could become very expensive for economies of scale, including the applicable limits at the root level for maximum OUs.

Tenant Isolation at the AWS Account Level

In this model, all the tenants will have their specific AWS accounts, which will be isolated – to an extent. In essence, as a multi-tenant SaaS solution, this can be treated as a managed solution on AWS. This model’s advantages are account-level tenant isolation ranging from resource isolation and billing to metrics and security. A marketplace solution that can be deployed on each AWS account is a good example of this model.

Pros:

• • Account-level isolation provides a complete separation of concerns, ideal for security.
  • Due to the isolation, customization of the solution and its configuration are deployment-specific for the tenant.
  • Completely isolated data for each tenant, and hence, a highly secure deployment.
  • Billing is generated for each tenant individually, and tenants do not have any access to each other’s billing information.

Cons:

• • • Volume discounts and resource sharing are not utilized effectively for each tenant, leading to higher costs.
    • As the number of tenants increases, it becomes difficult to manage operations for each separate AWS account, and this may become a management overhead.

Tenant Isolation at the Amazon VPC Layer

In this model, all tenant solution deployments are within the same AWS account. However, the level of separation is at the VPC layer. For every tenant deployment, there is a separate VPC, which creates a logical separation between tenants. It is easier to manage as the entire solution is deployed within a single account (rather than in a multi-account setup). Further, appropriate isolation via a VPC provides better economies of scale and improved utilization of Amazon EC2-reserved instances, as all pricing constructs are applicable on the same AWS account. The limitation of this model is that in consolidated billing, separate account billing by VPC cannot be ascertained.

Pros:

• • • Simplified management & setup deployment since it is within a single account and within a single VPC.
    • This model allows for improved utilization of AWS-reserved instances as all reservations are within the same AWS account.

Cons:

• • • For each region, Amazon VPC limits will have to be monitored at the tenant level.
    • There would be a complex interaction, in case the VPCs require connectivity with an on-premise network. Therefore, managing such connectivity might become a challenge.

Tenant isolation at the Amazon VPC subnet layer

In this model, there is a single AWS account and a single VPC for all tenant deployments. The isolation is prevalent at the subnets level. Each tenant owns a separate application or solution version, without any sharing across tenants. The advantages of this model: no requirement of VPC peering and simplification of VPN and AWS Direct Connect connectivity to a single on-premises site. This model’s limitation is that its NACLs (Network Access Control Lists) and security groups need to be managed very carefully.

Pros:

All tenants can have their public and private subnet, providing appropriate security for the resources deployed within the subnets.

No requirement of creating VPC peering for intercommunications, thus, making it easier to manage resources within the VPC.

Being a single account multi-subnet deployment, costs should be reduced by using shared services, wherever possible.

Cons:

• • • Tenant isolation at the subnet level is tedious to manage as there are many Network Access Control Lists (NACLs) and security groups.
    • Amending a VPC setting such as the DHCP option-set affects all tenants equally, regardless of their isolated deployment.
    • An on-premises connectivity requirement may become complex due to a large number of VPCs that need to be connected.

In the next part of this blog, we will discuss the two SaaS deployment models on Container and data layer.

Continued in Part 3