“Speed matters disproportionately to our customers to scale” – Andy Jessy (Chief Executive Officer of Amazon).
If you’re a startup owner, you might be worried about scaling your application as it grows in popularity. Equally, as the CTO of an enterprise, you might be wondering how to handle scaling in the cloud as companies grow organically and make mergers and acquisitions. What challenges arise when managing an AWS environment?
When using a cloud environment, you often start by setting up a single account and introducing a user to it. Over time, you add more users to that account, and then as you scale or need to change permissions, you see the need to create another account with new users. Despite the correct configuration of these two accounts, the organization continues to grow and scale. Soon, you will have many accounts, most of which operate similarly. At some point, costs increase dramatically, and the finance team questions the need for all these accounts.
Such confusion occurs from a need for more planning of the architecture. Success scaling is anticipating and positioning your cloud architecture to make it easier to scale later. While you can’t always predict the future, you must make some assumptions early on. Experience shows that slower growth at the beginning helps you make faster changes in the future. So what should you keep in mind when implementing an AWS environment? This article will focus on planning for the elements that require scaling.
Table of Contents
Elements of the AWS environment structure
When we discuss the structure, we want to think of it as building a building. This is the easiest way to understand what is happening when designing a cloud environment. When you think of building a building, you have many different elements. Indeed, it consists of bricks as the essential elements that make up a building. Then you think about the frame or structure that defines what your building looks like.
Once the building is completed, you need a manager with the tools to manage it effectively. Finally, you want to have a well-developed security system capable of, for example, locking doors, keeping people in, and impacting the security of all processes in the building.
Let’s now translate this into elements of the AWS cloud structure.
AWS accounts as building blocks
AWS accounts are like bricks, the building blocks in the cloud. You can create cloud instances quickly and grow them flexibly. When considering an account, consider the resources you develop and the services and applications that serve your customers, e.g., software, networking, or data storage. Think of an account as a container of resources, not a single user.
What to consider when scaling across accounts?
- Restrictions
We recommend scaling between accounts because when you reach a limit within one account, you can scale within the resources of the other account.
- Security (natural boundaries, isolation)
Regarding security, operating on different accounts gives you natural boundaries of isolation. When you create another account for another project or service, it is not connected to your other accounts by default. There is no access to it. If a problem occurs in one of your accounts, it is isolated from the current account.
- Regulatory compliance/business processes
If you need specific workloads to comply with certain regulations, you can create and build accounts to comply with them. This gives you greater flexibility to build an environment for your specific needs.
Organizational units (OUs) as a structure that helps categorize accounts
To build a structure, you need supports, ties, or frames that set the pattern for the bricks. Organizational Units are a structure, a framework that puts accounts in place and allows you to align different environments to the larger AWS environment. An organizational unit (OU) is a logical grouping of accounts in your organization created using AWS Organizations. OUs permit you to organize accounts into a hierarchy and make it easier to apply management controls.
When you design a business unit structure, a type of your environment, you want to start with a smaller structure before expanding it. This involves building customized environments and putting safeguards defining what activities will occur.
If you don’t have any structure or organizational units, start with one and then expand to others.
What to do if you want a scalable AWS environment model?
If you design OUs around your business teams, those business teams fluctuate a lot. The account or team owner can change daily. Therefore, consider designing your OUs or accounts around applications, services, and security, not necessarily business teams.
4 basic organizational units that operate in various forms of activity
- Security (Security) – contains an archive of logs and defines security policies and tools.
- Infrastructure (Infrastructure) – contains accounts for the infrastructure of your environment (shared services, network services, etc.).
- Sandbox – hosts all accounts built for developers to test application development without the restrictions of other business units (fixed spending limit, disconnection from the network, etc.).
- Workloads – where software scales to multiple accounts, such as a nested OU reflecting the software development cycle. It separates the environment, protects production workloads, and then continues to allow scaling to additional applications and services as they grow.
Other recommended OUs
- Policy staging – Verifying and testing SCP changes, where you test policies before applying them to your organization.
- Suspended – Closing accounts, marking them before moving them.
- Individual Users – If you have individual users in your organization who need special accounts, such as a team of business analysts requiring a place to host all their tables, you may want to have individual user accounts within a specific OU. These are self-defined apart from other workloads and resources.
- Exceptions – Highly personalized places, a new product that requires highly customized rules that do not apply to the rest of the environment.
- Deployments – intended for accounts that host CI/CD deployments.
- Transition – when there are multiple mergers and acquisitions, there are many instances where accounts come and go from your organization. A transition OU is where you can host these accounts and test their functionality and policies to ensure they fit elsewhere in the organization.
Administering an AWS environment
The organization has three specific elements:
Root – Defines the boundaries of your organization and determines what accounts are in your organization.
OU – Organizational units we mentioned earlier.
Membership accounts – Accounts housed within these organizational units.
Since the management account is used to administer the environment, it is recommended to be secure. To this end, delegating responsibilities outside the management account is best.
Security system – how to secure the AWS environment?
The best practices we recommend when it comes to environmental security are:
1. Employ proactive security mechanisms.
Preventative controls – Security preventative controls (SCP) -SCP allows the creation and application of custom security barriers; this means the application of custom policies that dictate the actions that can be taken within accounts.
The most common SCP use cases
- Use of shared services for each OU
- Restrict use to specific AWS regions
- Require tags when creating resources
- Determining allowed instance sizes
- Preventing “root” user actions
- Prevent deletion or modification of roles
- Prevent disabling default encryption
When designing security policies and service controls, it is best to start at the top level of the organization, descending to more detailed policies at lower levels of the organization.
For example, you can deploy EC2 on all instances at the organization level. Still, sometimes it’s better to limit it to smaller sizes within specific OUs that don’t require huge EC2 instance sizes.
You can read more about EC2 deployment in this article below.
2. Central visibility and controlled access
When it comes to central visibility, it’s best to use AWS security services that exist throughout the organization. As part of AWS security, we recommend maintaining two separate accounts.
- Log archive account – this is where all the logs from CloudTrail, (an AWS service that helps with operational auditing, management, and account compliance) are stored. This way, the security team operating under this account can see the entire organization regarding what’s going on.
- Security tools account – there are many AWS security services (e.g., GuardDuty, Security Hub, IAM Access Analyzer, etc.) whose administration you can delegate to this security tools account. Then your security team can review any existing findings and take appropriate action.
Setting up security and other services is typically contained in two steps:
- Configure the service for the organization
- Register a delegated administrator to an account related to management
We recommend doing this to limit activities within the management account.
Building manager – or how to scale in the cloud?
The building manager is the one who knows what’s going on because he lives in the building every day and makes sure it’s operational. How important is this in AWS architecture?
- Operations are where we test whether our plan will survive on the battlefield.
- Everything you set up is tested under emergency conditions.
- You must have the data and tools to see what’s happening and where the vulnerabilities are.
One tool to manage operations – it is essential to have one tool that combines all the necessary functions without switching between different browser tabs and logins.
Build runbooks and automation – The ability to detect and respond immediately through automation is critical. In the development process, you need to spend time in your team sprints to add automation and compilation of routines and operations so that you can respond quickly without negatively impacting customer responsiveness.
Feedback loop – It is vital to get regular feedback to adjust the behavior of your software in production without having to deploy new software. Such things must be planned so that you can, for example, increase or decrease the number of threads or simultaneous background operations in your application.
Best practices and key lessons learned
When reviewing your architecture, the most important thing is to plan an effective structure. It’s a good idea to think of accounts as bricks and build your OU structure around those bricks. Then you should limit accesses and use preventive controls where possible.
It is also necessary to equip teams with centralized tools to have complete visibility of operations if there is a security risk. If there are operations, you should ensure each one runs smoothly. Build runbooks, automation, and preventive feedback loops across the organization and accounts.
- STARTUP – If you are a small company with one account, create an organization, and build a second account to separate them.
- SCALE-UP – If you are an organization with several accounts but have not yet delved into service control policies, create a policy that prevents accounts from leaving the organization and test it on a test account in the organization.
- ENTERPRISE – If you are a large organization with several business units, but don’t have an established account management mechanism, build automation.
Managing AWS cloud architecture is something that takes time to happen. It requires planning, making decisions in advance to establish some framework, and thinking of specific decisions in the long term.
If you have questions about AWS structure management, please contact our experts. They’ll be sure to help you provide standard security and operations controls for your team. All to ensure that your structure is prepared for future growth.
