Account
An AWS account (an account, in short) is a virtual environment where you access AWS services and deploy and use AWS resources. The resources you deploy in one account are isolated from the resources deployed in any other account unless you explicitly provide cross-account access (for more on cross-account access, see Chapter 1, Determining an Authentication and Access Control Strategy for Complex Organizations). There is no limit to the number of accounts that you can create and use. By default, you can create up to five AWS accounts within your organization created through AWS Organizations.
That default quota can naturally be raised to match your needs. It is not uncommon for complex organizations (intended here in the sense of companies or BUs) to manage hundreds of accounts within a single organization defined in AWS Organizations.
VPC
A Virtual Private Cloud (VPC) is a virtual network environment that you define in an AWS account. You can use this to deploy AWS resources, such as virtual machines (VMs), containers, databases, and more. VPCs provide yet another layer of isolation for your AWS resources since communication from one VPC to another within the same AWS account is disabled unless you explicitly set it up (for more on inter-VPC communication, see Chapter 2, Designing Networks for Complex Organizations). As you most certainly remember, a VPC is a regional construct and spans all the Availability Zones (AZs) of an AWS Region.
Subnet
A subnet is a network subdivision of a VPC that belongs to a single AZ. It is yet another layer of isolation for your AWS resources.
The next section will discuss how you can best use the above concepts to build proper isolation for a large organization.
Considering all the possibilities, what is the best approach to resource isolation? Well, first, it depends on your requirements. Do you require strong segregation of workloads? What sort of segregation? Is it at a team level or at a department or BU level? Or is it mostly between production and non-production environments? Do the teams in your organization trust each other when it comes to sharing resources? The following paragraph presents an overview of the possible isolation levels, starting from the strongest possible isolation to the weakest one.
To start with, an AWS account provides the highest degree of isolation for resources on AWS. As mentioned earlier, AWS resources in one account are isolated from the rest of the AWS universe and from resources belonging to other accounts in your organization. Further, if something goes wrong in one of your accounts (for instance, a security incident), the affected perimeter—the blast radius—is limited to the affected account.
Therefore, it is strongly recommended, as a best practice, to distribute and separate your resources and workloads across multiple accounts. You may ask, how should I do that?
The first natural separation is between production and non-production resources. As a best practice, you should not put non-production and production resources and workloads in the same account (think again about what would happen in case of an incident). Then, depending on your organization’s requirements and security policies, opt for a particular account structure. You may be required to use a certain type of structure based on certain industry regulations for all or part of your BUs. For instance, you may have to strongly isolate regulated workloads (for instance, workloads regulated by the Health Insurance Portability and Accountability Act (HIPAA) or The Payment Card Industry Data Security Standard (PCI-DSS)) from non-regulated workloads. You may also choose to mirror the structure of your enterprise (for instance, BU, department, team, or application) in your account structure.
Figure 3.1 illustrates an account structure as was just discussed:
Figure 3.1: Example of account structure
A second method involves achieving strong isolation of resources at a network level, even within the same account, by assigning them to different VPCs—that is, different virtual networks. By default, resources located in different VPCs cannot reach each other; there is no route that connects multiple VPCs by default. If you need inter-VPC connectivity, you must enable it, and the various mechanisms to do so were discussed in Chapter 2, Designing Networks for Complex Organizations. You can decide to only allow VPC-to-VPC communication on a case-by-case basis—for instance, when dealing with VPCs hosting resources that belong to the same application or are linked to applications that must talk to each other. Figure 3.2 presents an example of a VPC organization:
Figure 3.2: Example of VPC organization
A third approach would be to distribute your AWS resources further across separate subnets within a given VPC. However, unlike inter-VPC connectivity, which is disabled by default, inter-subnet connectivity is enabled by default. Two resources in separate subnets can reach each other unless you put countermeasures in place, such as network access control lists (NACLs) or security groups, to prevent this from happening. So, because of this, it is apparent that this approach is suitable for resources that should be protected and segregated from each other but not for those that require a stronger level of isolation than VPCs or accounts can offer. Thus, as a general practice, start by organizing (and isolating) your AWS resources and workloads first at an account level, then at a VPC level, and then, only as a last resort, at a subnet level.
Now that you are familiar with the various approaches to resource isolation in AWS, you can learn about the billing features in AWS, as discussed in the next section.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
