Banking Infrastructure on Cloud
The series shares insights about banking systems' infrastructure architecture on the Cloud (AWS). These are just the knowledge I have gained through digital banking products. The series includes: AWS Account Management How to use Terraform to provision banking infrastructure Networking for Multi AWS Accounts Kubernetes for Multi AWS Accounts: Kubernetes Infrastructure for Scale Kubernetes for Multi AWS Accounts: Kubernetes Cross Cluster Communication Kubernetes Multi-AWS Account Management: GitOps for Multiple EKS Clusters Chaos Engineering Core Banking on Cloud Security Consider AWS Account Management When deploying banking infrastructure on AWS, the first task is to decide how to organize and manage your AWS accounts. Should you use one or multiple AWS accounts? If using multiple accounts, what criteria should you use to create them? How do you manage multiple accounts? One or Multiple AWS Accounts? According to AWS recommendations, enterprises should deploy their systems using a Landing Zone approach with multiple distinct AWS accounts. Using multiple accounts avoids hitting AWS Service Quotas, prevents a single compromised account from impacting the entire system, and simplifies AWS Billing management. For a banking system, it is recommended to deploy the infrastructure across multiple AWS accounts. Method for Establishing Accounts Typical requirements for creating many accounts include the following: Separating production, staging, and development environments Isolating workloads by business unit or application Segregating regulated data or workloads Enabling separate billing and cost allocation For example, when developing a product, we have environments such as dev, uat, staging, and prod. The environments dev, uat, and staging can be grouped as non-production environments, and networking, workload, operation (CI/CD), monitoring, logging, and data systems are typical system components. We can create accounts with the following names (non-prod is used for non-production environments): networking-nonprod workload-nonprod operation-nonprod observability-nonprod data-nonprod networking-prod workload-prod operation-prod observability-prod data-prod All requests must first pass via the networking account, which is used to control both incoming and outgoing network traffic. Tracing every request coming into and going out of the system is the goal. Databases, caches, and apps are all deployed via the workload account. Infrastructure provisioning for other accounts and CI/CD-related activities are handled by the operation account. Using the observability account, methods for logging, tracing, and monitoring are put into place. Data-related actions, such as gathering, processing, and artistically displaying data for internal users, are carried out using the data account. Managing Multiple Accounts When creating multiple accounts as mentioned above, how do we manage AWS Billing and access? We need another account specifically to manage all the above accounts, which can be named the root account. To enable the root account to manage these accounts, we need to use AWS Organizations with AWS Control Tower. The next issue is regarding access to different accounts. When we have multiple AWS accounts as mentioned above, how can we make access as convenient as possible? We cannot use the AWS Console to log in and log out to access each account. Additionally, there is the issue of IAM Users and Permissions; if someone needs access to multiple accounts, do we have to go into each account to create an IAM User for them? To facilitate easy access to the accounts in Control Tower, AWS provides the IAM Identity Center service. We only need to create permissions and users in one place, and they can access different accounts through the IAM Identity Center. The next post will address how to deploy infrastructure for the other accounts using an operations account.
The series shares insights about banking systems' infrastructure architecture on the Cloud (AWS). These are just the knowledge I have gained through digital banking products.
The series includes:
- AWS Account Management
- How to use Terraform to provision banking infrastructure
- Networking for Multi AWS Accounts
- Kubernetes for Multi AWS Accounts: Kubernetes Infrastructure for Scale
- Kubernetes for Multi AWS Accounts: Kubernetes Cross Cluster Communication
- Kubernetes Multi-AWS Account Management: GitOps for Multiple EKS Clusters
- Chaos Engineering
- Core Banking on Cloud
- Security Consider
AWS Account Management
When deploying banking infrastructure on AWS, the first task is to decide how to organize and manage your AWS accounts. Should you use one or multiple AWS accounts? If using multiple accounts, what criteria should you use to create them? How do you manage multiple accounts?
One or Multiple AWS Accounts?
According to AWS recommendations, enterprises should deploy their systems using a Landing Zone approach with multiple distinct AWS accounts. Using multiple accounts avoids hitting AWS Service Quotas, prevents a single compromised account from impacting the entire system, and simplifies AWS Billing management. For a banking system, it is recommended to deploy the infrastructure across multiple AWS accounts.
Method for Establishing Accounts
Typical requirements for creating many accounts include the following:
- Separating production, staging, and development environments
- Isolating workloads by business unit or application
- Segregating regulated data or workloads
- Enabling separate billing and cost allocation
For example, when developing a product, we have environments such as dev, uat, staging, and prod. The environments dev, uat, and staging can be grouped as non-production environments, and networking, workload, operation (CI/CD), monitoring, logging, and data systems are typical system components.
We can create accounts with the following names (non-prod is used for non-production environments):
- networking-nonprod
- workload-nonprod
- operation-nonprod
- observability-nonprod
- data-nonprod
- networking-prod
- workload-prod
- operation-prod
- observability-prod
- data-prod
All requests must first pass via the networking account, which is used to control both incoming and outgoing network traffic. Tracing every request coming into and going out of the system is the goal.
Databases, caches, and apps are all deployed via the workload account.
Infrastructure provisioning for other accounts and CI/CD-related activities are handled by the operation account.
Using the observability account, methods for logging, tracing, and monitoring are put into place.
Data-related actions, such as gathering, processing, and artistically displaying data for internal users, are carried out using the data account.
Managing Multiple Accounts
When creating multiple accounts as mentioned above, how do we manage AWS Billing and access? We need another account specifically to manage all the above accounts, which can be named the root account. To enable the root account to manage these accounts, we need to use AWS Organizations with AWS Control Tower.
The next issue is regarding access to different accounts. When we have multiple AWS accounts as mentioned above, how can we make access as convenient as possible? We cannot use the AWS Console to log in and log out to access each account. Additionally, there is the issue of IAM Users and Permissions; if someone needs access to multiple accounts, do we have to go into each account to create an IAM User for them?
To facilitate easy access to the accounts in Control Tower, AWS provides the IAM Identity Center service. We only need to create permissions and users in one place, and they can access different accounts through the IAM Identity Center.
The next post will address how to deploy infrastructure for the other accounts using an operations account.
