AWS Organizations is an account management service that enables to consolidate multiple AWS accounts into an organization that has been previously created. This service includes account management and billing capabilities. With the release of this new service, came also a bunch of AWS Organizations best practices that we must start to apply. As businesses expand their footprints on public cloud platforms, AWS comes forward as the cloud space’s undisputed market leader.
So, if you haven’t started your Cloud journey on AWS, it is time to begin your business digital transformation! I’ll make a pause over here, to suggest starting with an AWS migration, trust me, a lot of things will change in your digital company.
AWS is a cloud frontier when it comes to hosting the critical applications of financial services companies. With this surge in demand, organizations are adopting multiple AWS accounts for numerous departments and their line-of-businesses. This is where AWS Organizations come into the picture.
This article explores Multi-account AWS Organizations’ best practices for financial services, banks, NBFCs (Non-banking Financial Corporations), and other fintech companies. It also explores the architecture they typically follow and their billing mechanisms.
Table of contents
- What is AWS Organizations?
- Case Study of AWS Organizations in Financial Services
- Security in AWS Organization
- AWS Multi-Account Strategy
- AWS Organization Best Practices
What is AWS Organizations?
Launched in Feb 2017, AWS Organizations service enables you to manage multiple AWS accounts in your company. It allows you to create an organizational structure in your AWS account. We can understand that your organization has different departments like finance or operations all requiring different uses for AWS. You can create separate AWS accounts for all the various departments with independent roles and access to all the users.
However, there are AWS Organizations’ best practices you should aim to follow. These practices protect your organizational policies and adhere to the security and compliance requirements of your organizational units.
Now, a question arises about the billing. What happens to the billing when you manage multiple AWS accounts for your different lines of business? AWS has a consolidated billing mechanism for all the accounts you create using AWS Organizations. This removes the operational overhead of managing the cost of multiple AWS accounts.
Benefits of using AWS Organizations
When companies and corporate houses are running their IT infrastructure on multiple environments using multiple AWS accounts, a line has to be drawn between some significant aspects:
- Identity Access Management (IAM policies): You can have better control over the roles and access you want to provide to your employees. You can create IAM groups and assign the roles required to perform a particular function. This will ensure better governance in your AWS account
- Role-based Access Control: RBAC is a neutral access control system in an enterprise. RBAC can facilitate the administration of security policies of thousands of users at a time.
- Cost management: Consolidated billing is the best cost management technique. You can manage and audit your expenses of all the accounts from one dashboard.
In case you’re looking for further information about AWS costs, here’s a blog that talks about how AWS pricing works.
- Effectively manage different cloud resources, servers, and storage.
When used effectively, AWS Organizations’ essentially protects you from the challenges of managing multiple resources at a time. It’s worth noting that Financial services providers generally require better governance of their AWS account and services than companies in other sectors. There are specific benefits of AWS Organizations that enterprises can get when best practices are followed. Some of these benefits are:
- Consolidated billing: Consolidated billing is one of the major benefits of AWS Organizations. Using a single payment method, you can pay the combined charges of all the AWS accounts within your organization. AWS also provides some promotional discounts on aggregated usage of services occasionally.
- Centralized management system: Helps in centrally managing the policies across multiple AWS accounts. It helps to create a better control on the AWS environments by forming groups of accounts and then attaching the correct policies to the groups. This process can also be automated to save the manual efforts in the account/policy creation.
- Improved governance: Better governance of user accesses through Service Control Policies (SCPs). Following the AWS Organizations’ best practices ensures the correct usage of actions and services allowed in your account.
Different components of AWS Organizations
You can build a diverse architecture around your application using AWS. Before we delve deeper into the world of AWS Organizations, the following explains the key concepts/components and terminologies you should know.
Master Account: This can be your root account designated for managing your AWS infrastructure. It is the central account where your services are billed from. The Master Account is also the central management and governance hub.
Organizational Units (OU): This is a set of AWS accounts logically grouped within an organization. This can be best seen as a container of accounts within your root account. Multiple OUs can also be created under a single OU, making it a tree line structure.
Security Control Policy (SCPs): This document describes controls to be applied to a selected set of accounts. The policy defines the services and actions that users or a role can perform. SCPs are very much similar to IAM permission policies except that they do not grant any permission. Instead, SCPs define the maximum number of permissions an account and an OU can have.
So, when you think about organizing your service accounts in OUs, there are certain aspects that you need to look at. Some of them are:
1. Where do you see your business and their individual units’ growth in the coming years?
2. Identify the common elements in your organization and policies. If the environments are the same, we can re-use the policies and try to automate it.
3. Grouping similar accounts is a plus point. This will help with automating the tasks among similar organizational units.
Case Study of AWS Organizations in Financial Services
Before we explore this service further, let’s discuss a case study where AWS Organizations helps banks and other financial services companies in their AWS management and governance activities. We need to understand the architecture that these companies follow, which adhere to the multi-account AWS Organizations’ best practices.
Let’s talk about an online bank. This is one of the leading banks in Europe. Before we go ahead with more details about the implementations, let me quote what the bank says about the AWS Organization. They say that they can run a platform with more than 4 million users, with only eight people managing the entire AWS infrastructure and its reliability. Interesting, right? That’s how powerful AWS Financial services are.
One of the primary reasons why banks and financial services companies in Europe choose AWS is that it complies with all the banking regulations. In November 2015, the Financial Conduct Authority (FCA), the UK banking regulatory, released detailed guidelines for banks using off-premise cloud services. This is one major benefit of using AWS as it works in close proximity with all the major financial regulators worldwide.
Fig: A recommended architecture for financial services companies
Now, let’s look at the architecture diagram above and see how financial services companies can implement AWS Organizations’ best practices. AWS Organization helps the banking infrastructure to separate the AWS accounts. Usually, the banks use one AWS account for production, one for pre-production environments, one for storage and another for storing user data, policies, and the roles within AWS.
In the architecture diagram above, we have a Master AWS account with its well-defined policies. Two different and isolated AWS accounts are created. One of them has all the pre-production environments, and the other has the production instance. This isolates the entire infrastructure from one another.
Consequently, where one of the AWS accounts is compromised, critical services running in other AWS accounts remain safe. Configuration of AWS organization is so easy that the admins can easily migrate old accounts to multiple AWS accounts in a day.
Read more to continue learning about the Top 6 services of AWS for Financial Services.
Security in AWS Organization
The current cybersecurity landscape means that financial services providers like banks are very concerned about security. Protecting the data and the records they hold for their customers is paramount for the banks. How does this partition of an AWS account help the banks add security and protection to their IT infrastructure? Let’s see the different security components which AWS Organizations can offer to protect the accounts.
- Root Account MFA: Every AWS account has a root user. And without any second thoughts, you should add an extra layer of security to the root user login with Multi-Factor Authentication. The root account has god-level privileges. They can add services, delete users, and even deactivate the entire AWS service for the organization. So, as an AWS Organizations best practice, you should add MFA to the root account.
However, we recommend that you use an IAM user with appropriate permissions to perform tasks and access AWS resources. AWS Organizations’ best practices suggest using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.
- AWS CloudTrail: This will provide you with a hawk-eye view of the entire AWS accounts in your enterprise. It will allow you to see all the audit logs and monitor all the API calls’ source and destination. This will help you identify any suspicious behavior in your account. You can also create custom trails using CloudTrail for better handling of the information which is logged in the console.
- Map Enterprise roles: You’ll need to administer the roles you have assigned to different people. You may also want to keep a check on the right set of roles assigned to a network engineer or lambda developer for instance. They should have the right set of permissions. You can also federate this through the bank’s LDAP directory, where all the roles and permissions for all the users are already defined.
What are AWS organizations’ SCPs (Service Control Policies)?
Service Control Policies are a type of organizational policy that helps you to manage and control your organization’s permissions. SCPs offer central control over the maximum available permission on all the accounts. So, how do these SCPs come under the umbrella of AWS Organizations’ best security practice?
- SCPs allow you to control the accessibility of APIs. With the help of SCPs, you can allow a set of APIs (whitelist) and block a different set of APIs (blacklist).
- SCPs are invisible to all the child accounts. They are not visible even to the root account.
- SCPs are applied to all the child accounts, including root.
- The IAM policy simulator can manage · Intersection between SCP and IAM policies. This simulator is completely SCP aware.
- SCPs affect all the users and roles attached to an account, even the root user. There are some tasks and entities (will be discussed later in this section) which are not restricted by SCP.
- SCPs do notaffect any service-linked role. These roles enable other AWS services to integrate with AWS Organizations and can’t be restricted by SCPs.
You cannot use SCP to restrict the below tasks:
- Any action performed by Master Account.
- Any task performed using permissions linked to a service-linked role.
- Change the AWS support level as a root user.
- Provide trusted signer functionality for CloudFront private content.
- Modify AWS account email allowance/reserve DNS.
- Tasks on AWS related service:
- Alexa Top Sites
- Alexa Web Information Services
- Amazon Mechanical Turk
- Amazon Product Marketing API
AWS Multi-Account Strategy
Organizing your AWS accounts should be a serious consideration for your business and several strategies can be implemented. For instance, you may choose to organize your account based on the functional domain. This can be likened to segregating your people into different corporate units. People performing the same functions stay on the same team. Similarly, services working on the same functionality should be in the same account.
An alternative approach could be organizing your accounts by the development phase. You may want a different account with a different set of settings for developers and testers with corresponding VPCs. An identical account can be created for the production environment. This will ensure complete isolation of production instances.
You could also use a data-driven strategy. This involves keeping more sensitive data and their related services in one account and the other services, which are not so critical, in another account.
Fig: A sample of different AWS accounts under a Master Account
It’s important to understand that works in one situation may not work in another. So, we highly recommend that you analyze your requirements clearly before modifying your AWS account’s organizational structure.
AWS Organization Best Practices
The following looks into the AWS Organizations’ best practices, which are being followed in the financial services industry.
It is recommended that the Master Account of AWS should be kept free of all the operational tasks (except for CloudTrail). This will help you take high-quality control decisions and make it more comfortable to monitor the different kinds of charges incurred in your AWS account bill.
Use of CloudTrail
CloudTrail should be the only service (exception mentioned above) running in the Master account. This will be your central tracking system for all sorts of usage in your member accounts.
While setting up the policies for the organizational units (OUs), assign as few policies as possible.
Assign policies to OUs rather than assigning it to the accounts. This will allow you to maintain a better mapping between your organizational structure and the access levels in your AWS accounts.
All the policies should be tested on a single account before scaling up.
Different APIs and CloudFormation templates can be used to automate the creation of all the new accounts. Automation can help ease out the burden of performing repetitive tasks like creating new accounts, users, roles, and IAM policies.
To achieve all the aspects mentioned, you should consider adopting DevOps for your fintech company since you can achieve faster releases to market and of course, better security and reliability.
If you’re curious about DevOps, here’s a blog that showcases the Top Benefits of DevOps for Financial companies.
AWS Organizations can be a valuable service to large enterprises that need to manage multiple (large and small scale) applications on AWS. It essentially makes the management and governance of AWS services easy, thereby increasing the security and reliability of the cloud infrastructure. Additionally, consolidated billing of multiple accounts attracts a lot of discounts, which AWS offers repeatedly. This will ultimately save your operational cost of running your applications on the cloud.
Because of the amazing benefits of AWS Organizations, this service is highly recommended for enterprises that need much more than a single account and need to isolate their environments & VPCs and have better control and governance of their AWS environment.
In case you need some help with any of the aspects mentioned in this blog, we’ll be glad to help you with our AWS Consulting service.