Managing Multi-Tenancy in Digital Banking with AWS Control Tower

By Amol Pathak, Principal Architect at Persistent Systems
By Viraj Nadkarni, Solutions Architect at Persistent Systems

Cost conscious credit unions looking to provide digital banking services need logical isolation from other tenants. These credit unions are usually small. Larger credit unions, on the other hand, require physical as well as logical isolation from other tenants.

Finding the best solution and figuring out how to implement it can be difficult for both large and small credit unions. Persistent Systems recently launched a digital banking platform designed to help credit unions large and small set up and manage multi-tenant environments.

Persistent Systems Digital Credit Union Solution helps a credit union go live in a short time frame with digital banking offerings such as digital loans or digital deposits.

Persistent Systems is AWS Partner Network (APN) Advanced Consulting Partner with AWS Competencies in Data & Analytics, DevOps, Internet of Things (IoT), and Software-as-a-Service (SaaS). With 11,000 employees around the world, we are a global solutions company delivering digital business acceleration and enterprise modernization for businesses across industries and geographies.

In this post, we describe our microservices-based solution, the challenges we faced, and how AWS Control Tower and other Amazon Web Services (AWS) technologies helped us overcome them.

Microservices-Based Architecture

At Persistent Systems, we developed our credit union solution using fine-grained microservices, deployed on Amazon Elastic Kubernetes Service (Amazon EKS) and provided as secure API’s using Amazon API Gateway.

Our Digital Credit Union solution’s pluggable components include:

Loan market access
Customer relationship management (CRM)
Credit decisioning
Core banking system (Mambu)
Payment providers
Know Your Customer (KYC) and Anti-Money Laundering (AML) capabilities
Credit score providers
Compliance and regulatory reporting
Fraud detection

We use Helm to deploy microservices and other tools required for non-functional aspects. These include Istio for service mesh, Prometheus for monitoring, and ElasticSearch, FluentD, Kibana (EFK) for logging.

Challenges to Multi-Tenancy Models

Because our solution is used by credit unions large and small, it needs to support both single-tenant and multi-tenant models.

For Smaller Credit Unions

For smaller credit unions looking only for logical isolation, we create an Amazon EKS cluster and assign a dedicated Kubernetes namespace for each tenant. The platform uses Kubernetes network policies to ensure services within a namespace cannot communicate with any other services from other namespaces.

We also enforce resource quotas (CPU, number of pods, and memory) for each namespace to reduce the “noisy neighbor” problem of one tenant workload negatively impacting other tenants.

For Larger Credit Unions

For larger credit unions requiring both physical and logical isolation, we create a new AWS account where we deploy the platform in a dedicated Amazon EKS cluster.

Requirements for the Multi-Tenancy Solution

We had the following requirements to manage and control the multiple identity and access management (IAM) accounts:

Re-use of AWS CloudFormation templates and Helm charts for both small and large credit union deployment models.
Enforce the same security controls across all tenants and their IAM accounts:
- Flag any non-compliant accounts.
Ability to centrally control the billing and list of services used by all tenants and their IAM accounts.
Ability to centrally view logs for all the tenants.
Ability to centrally audit the IAM accounts for all tenants without having to create a user in each IAM account.

To address these challenges and requirements, we evaluated AWS Control Tower.

If you’re an organization with multiple AWS accounts and teams, cloud setup and governance can be complex and time consuming, slowing down the very innovation you’re trying to speed up.

AWS Control Tower provides the easiest way to set up and govern a new, secure, multi-account AWS environment based on best practices established through AWS’ experience working with thousands of enterprises as they move to the cloud.

With AWS Control Tower, builders can provision new AWS accounts in a few clicks, while you have peace of mind knowing your accounts conform to your company-wide policies.

How AWS Control Tower Helped

When you set it up, AWS Control Tower creates a landing zone. It’s the enterprise-wide container that holds all your organizational units (OUs), accounts, users, and other resources. In its landing zone, AWS Control Tower accommodates three types of OUs:

Root OU: contains all other OUs.
Core OU: contains the log archive and audit member shared accounts.
Custom OU: contains the member accounts of your credit unions.

Figure 1 – AWS Control Tower high-level architecture.

For our deployment model, we created several Custom OUs:

Production OU: The Production OU contains the production deployments for each individual customer. This can be done in one of two deployment models described above.

Figure 2 – Production OU.

Shared services OU: This OU, among other things, hosts platform continuous integration/continuous delivery (CI/CD) pipelines designed to build, package, and deploy fresh installs and upgrades. Also included in this OU are other services shared among multiple production and non-production accounts.

Figure 3 – Shared services OU.
.

Log and audit OU: These accounts are under a Core OU and hold aggregated logs and other audit information. These are of importance to security, compliance, or audit teams.

Figure 4 – Log archive account (Core OU).

Figure 5 – Audit account (Core OU).

Non-production OU: This is another custom OU we use for spinning up any non-production environments such as development, test, or staging. This OU is used during a regular product development lifecycle until the changes are signed off as ready for production.

Figure 6 – Non-production OU..

Master OU: The root OU, where AWS Control Tower, AWS Organizations, AWS Service Catalog, and other services that provide the overall governance are deployed.

Figure 7 – Master account (Root OU).

The two deployment modes are:

Shared account: We create an Amazon EKS cluster and add a new Kubernetes namespace each time a tenant is onboarded, and deploy all core and supplementary platform services.
.
Dedicated AWS accounts (one per tenant): We create a new AWS account every time a tenant is onboarded, and create an Amazon EKS cluster within it.

This model allowed us to easily re-use our AWS CloudFormation templates and Helm charts for onboarding new tenants.

For each tenant’s shared AWS account with dedicated namespace, we use the following deployment architecture.

Figure 8 – Dedicated namespace per tenant.

For each tenant’s dedicated AWs account, we used the following deployment architecture:

Figure 9 – Dedicated AWS account per tenant.

AWS Control Tower has a guardrails capability that allows us to create high-level rules for ongoing governance for all the IAM accounts in the OUs managed by AWS Control Tower.

We have created Preventive and Detective Guardrails, so that all IAM accounts are secured in exactly the same way. Also, since we create different Custom OUs for different use cases, we get fine-grained control over which guardrails to apply to which OUs.

Benefits from Using AWS Control Tower

By integrating AWS Control Tower into our solution, we were able to solve most of our technical challenges. We’re able to view logs centrally, and view or manage billing for all IAM accounts inside OUs. We also experienced faster tenant onboarding, faster upgrades, and improved security.

Faster Tenant Onboarding

Onboarding a new tenant now takes a few minutes to an hour, depending on the deployment model.

To cater to tenants with different security and budget requirements, we created automated infrastructure templates. We set up several AWS Control Tower landing zone configurations in CloudFormation templates, and made them available through AWS Service Catalog.

We were able to orchestrate different core networking setup and core application infrastructure setup for different applications, and automate the supporting services around the application. We offered these configurations as “products” through AWS Service Catalog.

This approach allowed us to update different configurations independently of each other, and allocate access to specific user groups.

Faster Upgrades

Using our CI/CD pipeline, we put in place strict processes to be followed for each type of update. One process for setting up a new environment from ground up, another to update an existing environment, and another to update the code for an existing application.

All of this would have been much cumbersome to build without the use of AWS Control Tower, AWS CloudFormation, and AWS Service Catalog.

Security Benefits

The credit unions that use our product typically have strict security, regulatory, and compliance requirements. A key challenge we faced was how to automate governance across multiple tenant accounts in multiple environments with different requirements.

We were able to provide this capability with a combination of OUs and guardrails. Because different guardrails can be configured for different OUs, we configured guardrails that would best meet the security and compliance needs of the tenants in each OU.

As a result, we were able to enforce the similar security measures for similar tenants, and flag any non-compliant OU and IAM accounts. This approach was not cumbersome, so we were able to continuously update our guardrails to reflect AWS best practices.

Conclusion

By relying on AWS services, the Persistent Systems Digital Credit Union solution is able to help both small and large credit unions set up and manage multi-tenant environments, while meeting their requirements for low cost, high security, and regulatory compliance.

AWS Control Tower’s landing zone capability enabled us to configure different infrastructures, security policies, and update process for different types of tenants. We were able to easily code these in AWS CloudFormation templates, and offer them as different products in AWS Service Catalog.

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

.

.

Persistent Systems – APN Partner Spotlight

Persistent Systems is an AWS Competency Partner. With 11,000 employees around the world, Persistent is a global solutions company delivering digital business acceleration and enterprise modernization for businesses across industries and geographies.

Contact Persistent Systems | Practice Overview

*Already worked with Persistent Systems? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.

AWS Partner Network (APN) Blog