Amazon Web Services (AWS) gives organizations the flexibility of using several different methods for managing user accounts. In this article, we will take a look at some of the best user account management practices and their potential pros and cons.
The Ins and Outs of AWS Accounts
AWS accounts provide comprehensive access to resources created during the account creation process. The first account is created when the user provides his payment details. from then on, the user is considered a root user. Additional users and accounts can be set up through an AWS service called Identity Access Management (IAM). We can use this service to create users with granular-level roles and permissions.
Two unique identifiers are assigned to each account during its creation:
- AWS Account ID
- Canonical user ID
AWS Account ID is a unique 12-digit number meant as a reference point for each and every user. It also helps to differentiate between users and resources.
Canonical User ID is a long string used for enabling cross-account access on S3 buckets. It is achieved by using any other AWS account’s canonical user ID while writing an S3 bucket policy.
AWS Account Detailing
AWS account has a versatile set of features and functions. The resources and features help define the boundaries between the application and the service running in AWS account is set. There are six different types of the properties and behaviors:
- Security and Access Controls
- Communication
- AWS Service Limits
- Cost and Billing
- Resource sharing
- Account Linkage and Consolidated Billing
Security and Access Controls
IAM
Identity Access Management and AWS identity exist for every account made on AWS. It offers control over access and permissions within an AWS account. It allows users and roles to be created as well as permission sets, which control access to resources within the account.
The default IAM configuration prevents any unauthorized access to users not associated with the AWS account. Cross-account access is possible, too. An AWS account is best in when organizations are divided into business units: Within each business unit, the users, roles and permissions are created specific to the unit.
Security Groups
The security groups in EC2 are used to control ingress and egress requests from Elastic Compute Cloud (EC2) instances. In other words, security groups can be configured to control the open ports used for inbound and outbound requests to the EC2 instance. They allow access to the use of Instance ID, CIDR range or by referencing existing security groups. Unlike CIDR, other security groups just work within the AWS account.
Advantages:
- Accidental configurations allowing access across accounts can be avoided easily.
- The responsibilities of departments within the organization/business unit are clearly defined.
Communication
AWS virtual private clouds (VPCs) are logically isolated sections of the system within the EC2 environment, which facilitate the construction of discrete networks for workload or organization. They empower users to gain not only control over the subnets but also access to the routing tables, internet connectivity, etc. IAM controls the access to VPCs. Security groups control ingress and egress at the EC2 instance level and access control lists (ACL) control the access to subnets at the VPC layer.
By default, it is impossible for instances within different VPCs to communicate privately with each other. But using the unique feature of VPC Peering, it is possible to connect routing traffic between IP spaces for two different VPCs. Communication between subnets within two or more VPCs is possible as well. To initiate a VPC Peering connection, the requester has to send the request to the target or Peer VPC and then the request must be accepted by the administrator associated with the target or Peer VPC. Once the connection is established, all the routing tables can be modified, enabling the flow of traffic between the connected VPCs. If there are no particular IAM configurations, the person initiating the VPC Peering request might possess permissions to accept the request from the target VPC, allowing inter-VPC access.
Cross-account peering is possible using VPC peering, but the administrative control of AWS accounts is usually segregated.
AWS Service Limits
A lot of AWS service limits exist by default. They are region-specific and provide the control over the number of different types of resources that could be created.
Examples of AWS Service limits include:
Although most of the limits that are specified are soft and can be increased or decreased easily on request, changes are not instantaneous. AWS support needs 24 hours to remove service limits after receiving business need-based requests. If an organization is using separate AWS accounts, it will end up with multiple sets of these AWS service limits. Putting a logical boundary in place is a good practice whenever there are multiple, independently functioning business units within any organization.
Cost and Billing
The AWS account can be seen as a billing entity that functions as a boundary for the allocation of the cost associated with the resources within the account. There may be different payment modes for different AWS accounts, and can produce detailed billing statements. Tagging is used for identification of the individual resources within an AWS account, making accurate cost allocation models possible.
Note: There might be some resources that do not use tagging and will not be represented in detailed reports. If, for example, an organization is sharing an AWS account for several different entities that need their cost to be apportioned, then the best way to deal with this will be to use separate AWS accounts.
The following list of resources that cannot be tagged:
- Ingress or Egress Bandwidth from EC2
- VPC endpoints
- VPC flow logs
- Elastic IPs
- Ingress or Egress Bandwidth from S3
When it comes to the cost optimization, reserved instances (RIs) play a vital role. RIs allow customers to access the significant amount of discounts over on-demand EC2 instances by committing to an instance type, region availability, period and level of utilization. RIs are not allowed to be moved between accounts, but it is possible to sell an unwanted RI on Reserved Instance Marketplace.
Sharing Resources
While there are several methods to prevent cross-account sharing, there are some that facilitate sharing it. Cross-account interaction with appropriate security controls is provided through VPC Peering.
Some methods that facilitate sharing of resources between accounts are:
- EC2 Amazon Machine Images (AMIs)
- EBS volume snapshots
- RDS Backup
- Amazon S3 Buckets
These mechanisms are used for sharing data from critical services. Even without relying on these tools, transfer of the data can be done manually, which is often prone to errors and security risks. This is not recommended.
Linking Accounts and Consolidated Billing
In AWS, linking multiple accounts in parent-child model is an efficient way to organize accounts for organizations. This method, called Linked Accounts, provides customers a holistic view of billing from multiple child AWS accounts into the single master AWS account. Through a single billing report that also includes separate reports per child account, Linked Accounts gives the user an integrated view on the resource charges for a cluster of AWS accounts. It provides more visibility into an organization’s spend throughout all AWS, still utilizing the AWS account as a boundary.
When a linked account model is set up, a best practice is to make an empty master AWS account strictly for consolidated billing. When AWS resources are created within the master account, it adds complexity to the consolidated billing configuration/data and accounts holding payment.
Consolidated billing is also beneficial at the time of purchasing RIs for an optimizing cost. RIs bought at the master account level could be linked at instance startup time to any child accounts linked to the master account.
Account Usage Patterns
Training accounts can be used for different purposes:
- Single Account Model
- Autonomous Model
- Single Master Hierarchy Account Model
- Multiple Master Hierarchy Account Model
Single Account Model
In this model, all AWS resources are contained within a single AWS account employed by an organization. It’s a preferred model for smaller organizations that require simplistic workloads or fewer workloads within their AWS account. It also can be leveraged by an organization that centrally manages the IT and business functions. Using this model, a customer for a single payment method would receive a single billing report—the client is not required to handle numerous accounts for access management or communications.
Pros:
- Less complicated.
- Cross-account configuration is not required.
- Sharing of resources is held within an account.
- Financial governance is easier and can be easily centralized.
- Customer is provided with a single payment method and billing report.
Cons:
- With the increase in the usage, the account limits are required to be frequently raised.
- Configuration and resource issue in one environment will adversely affect other settings (including production).
- There is no way to isolate the access controls independent of IAM policies.
- Erroneous changes to Security Group or IAM policies can have adverse effects.
- Production and non-production workloads are not independent of each other.
Autonomous Model
This model leverages multiple AWS unlinked accounts to provide the advantages of the single account model. This permits independent IT or business functions to operate independently. It also allows each division or department to have a decentralized model to administer their functioning.
Pros:
- Decreased complexity for all accounts in the model.
- Sharing of resources is held within the account.
- Cross-account configuration is not required.
- Individual billing reports for each AWS account.
- Payment modes for every AWS account and business unit.
- Decentralized governance across AWS resources.
- Impact of erroneous changes to items such as IAM policies or Security Group changes reduced to a lone organizational unit
Cons:
- Assigning as a single account to manage a business unit reduces the impact of erroneous change outside the business unit. But this also has the drawback of single account model.
- With no centralization available, the construction of multiple accounts becomes a challenge to manage.
- Managing IAM policies with the different independent account may result in a drift of standards and access control, for instance, the user management.
- Duplication of efforts because the organization manages several different billing and payment reports.
Single Master Hierarchical Model
In this one-to-many connected account model, a single master account helps the organization integrate the control and governance of AWS spending while allowing some autonomy for the business units. The Single Master Hierarchical Model is preferred by big organizations with centralized finance having several workloads throughout functional groups or projects. This model uses distinct subordinate AWS accounts for isolating the application environments within the organization.
Pros:
- Provides for a central managing system.
- A single payment mechanism and integrated billing report across several accounts.
- One single billing statement that covers subordinate accounts.
- Provides the ability for attributing the costs, taggable or not, to an individual business unit.
- Less prone to incorrect changes in the IAM policies, as the impact is contained within limited accounts.
- Business units can be empowered to carry out administrative and IT duties.
- RIs can be purchased at the master account level and used for the child accounts.
Cons:
- Managing IAM users and other policies can be tricky, as each account requires duplicate configuration.
- Manual linking is required for setting up the new subordinate AWS account.
- Consolidated billing that includes child accounts may produce multiple reports, making it difficult for efficient data analysis.
Multiple Master Hierarchical Model
This model also knows as, multi-master account structure, is preferred by large organizations or enterprises with numerous business units or governing bodies. These groups usually want their business units to function independent of each other, for legislative, political or financial reasons. In this model, several master payer accounts are set up, followed by dependent child accounts. This model retains benefits of the single-master model while allowing cost-allocation on a master-by-master account basis to payers and payment methods.
Pros:
- A centralized governing body yet separation between the child accounts.
- Separate payment methods for each account as dictated by the needs of business divisions and units.
- Reduced collateral damage from mistakes, such as security breach or IAM changes (constrained to individual accounts).
- Business units and project groups can be empowered to carry out administrative and IT duties.
- RI buyouts can be done at every master account level, enabling RI improvement inside every business unit.
Cons:
- IAM clients, policies and roles can be more tricky and intricate to manage because of the presence of AWS master and sub-accounts.
- Consolidated billing over several master AWS accounts with numerous child accounts results in complex billing documents.
- Multi-master arrangement will typically lose some of the cost efficiencies by limiting RI buys to every master account.
- No nesting approach for setting multiple master records into a n+ various leveled structure
Using a single account for all AWS resources will reduce complexity but increases risk, as issues with one account can impair several business applications. A single-report model should be used only for simple or singular use cases.
Eventually, there’s no definite answer to what is the best account model. The choice of model is a subjective decision based on the requirements. However, some aspects of the Linked Accounts model can be a good fit for most real-world scenarios. It’s tricky to set up, but the behaviors and efficiencies of Linked Accounts model would overshadow the cash outlay for its setup. A structure should be chosen with an eye toward the future. Can this structure support rapid growth? Can it help growing communication in near future? These are the questions that should be addressed before choosing a model.
Simplifying Your AWS Account Strategy
Leveraging a single AWS account pattern may result in operational challenges. Managing and setting up IAM users, roles and groups consume a lot of time and could cause trouble and unexpected behaviors. While Identity Provider federation or cross-account IAM can be used to reduce the overhead, their configuration settings may be complex.
AWS has a lot of human specialists who can assist with configuration, organization and administration of AWS assets. They can also help simplify operations of AWS infrastructure.
AWS IAM Configuration Setup And Management
With IAM, users can be allowed cross-account IAM role. One should remove the root account access to console and API. Also, a parent account could be created with access to specific AWS resources as an administrator or in read-only/read-write mode. As a best practice, roles and policies should be defined on the role. Then when the users are created, they can be allowed to be part of a particular role as needed.
Consolidated Billing
Consolidated Billing could be used for consolidating payments for several AWS accounts or AISPL (Amazon International Services Pvt. Ltd) accounts within a company by defining any of those accounts as the payer account. Consolidated Billing is a free service and offers a collective view of all the account changes, along with cost report for accounts associated with the payer account at the individual level. Usually, AISPL and AWS cannot be consolidated together; however, service providers could tie these two accounts and offer Consolidated Billing.
Consolidated Billing offers the simplicty of one bill for multiple accounts. Account charges and cost data tracking is available in CSV format. And, in the case of multiple accounts, AWS integrates the use of all accounts, making the user eligible for a volume pricing discount.
Summary
By following the usage patterns discussed in this white paper, operational issues can be addressed through proper planning, automation and additional tooling.
