!—Influ2 code starts --> <!—Influ2 code ends -->
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:
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.
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.
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.
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.
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.
In the next part of this blog, we will discuss the two SaaS deployment models on Container and data layer.
Palani works as a Senior Architect in the Cloud Engineering Studio division of Brillio. He has deep expertise in multi-cloud initiatives for large enterprises.
Let’s create something brilliant together!Let's Connect