AWS Basic Concepts
Learn basic concepts relevant to Amazon Web Services (AWS).
easy
30 min
635
To access material, start machines and answer questions login.
Learning Objectives
In this room, you will learn about basic technologies associated with the platform. These technologies represent foundational concepts for how you interact with and services. Once completed, you will have learned about:
- The basic security boundary, an account, and the "root user account" associated with each account.
- The Identity and Access Management () infrastructure inherent to using .
- What is an "region" and why that matters when you interact with services.
- How Organizations can streamline operations through central management of multiple/many accounts.
- What is a "Virtual Private Cloud" and why you will almost inevitably need one (or many) when using .
This information will help you become familiar with core services and features. Using this information, you will be better prepared to understand and troubleshoot new challenges as they arise in your cloud journey.
Account
An account is a for your resources. accounts are designated by a 12-digit number (e.g., 123456789012), known as an Account ID. Each Account ID is unique and can never be reused (opens in new tab). also notes that an account is also a security boundary (opens in new tab) in association with Identity and Access Management (). Learning is an entire module by itself, but it is key to understand that or root user credentials are the only way to access the control plane. Even when using Single Sign-On () and third-party identity providers such as AzureAD or Okta, the permissions are granted to an user (opens in new tab) or role (opens in new tab).
Account Root User
To sign up for an account, users provide a root user (opens in new tab) e-mail address. An e-mail address can only be used as the root user e-mail address for one account. The root user is considered an "superuser" and has complete administrative permissions against the account. Generally, customers are recommended not to use the account root user credentials unless performing a task that only the root user can perform (opens in new tab).
By default, root users do not have multi-factor authentication () enforced. Furthermore, root accounts that do not have enabled or a phone number set are susceptible to a weak password reset workflow attack. This is commonly the case for accounts created automatically using the Organizations service, which we will discuss in another room.
If an attacker gains control of the e-mail inbox for an root user without or a phone number on the account, the attacker will be able to send a password reset e-mail and complete a takeover of the targeted account. If you have access to an e-mail inbox or are looking to target e-mail addresses as potential root users, you can use tools like Quiet Riot (opens in new tab) to enumerate valid root user e-mail addresses.
Does AWS require customers to enforce MFA by default for root user credentials? (yea/nay)
Defining
 Identity and Access Management () specifically means the capabilities and features of the engine and service of - this is the underlying system built by to determine how principals (opens in new tab) are granted access to specific services, resources, and capabilities in . Essentially, principals are the identities that recognizes as having privileges in relation to resources in the engine. You can use the following policy evaluation logic (opens in new tab) from to determine whether and what type of access an principal has to a specific service and resource (the policy evaluation logic image starts with an implicit deny):
 Roles
roles are principals that have permissions in relation to services and resources.  roles are notable because of a feature known as "assume-role", or "switch-role". These terms mean that other identities recognized by are allowed to gain the privileges of a particular role. Which identities are allowed to assume or switch to a role is determined by what is known as the "assume-role trust policy" that is attached to each role. Below is an example of an assume-role trust policy:
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/maintenance-role"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
In the above example, the role "maintenance-role" in account "111111111111" would be able to assume the specified role. However, numerous types of an principal can be specified in an assume-role policy, including federated identities.
Federated Identities and Identity Providers
supports the use of Security Assertion Markup Language 2.0 (SAML 2.0) and Open ID Connect (OIDC) to federate identities from third-party Identity Providers (IdPs), such as Azure Active Directory (AAD), Ping Identity, Okta, Facebook, and any other SAML 2.0 or OIDC provider. This means that identities registered with these third-party providers can be provisioned access to roles with specific privileges inside of accounts. In 2017, furthered this integration with Organizations and Identity Center (successor to Single Sign-On ()).
Identity Center
Identity Center allows organizations to provision access across accounts and applications hosted as part of an Organization. Inside an Organization, Identity Center will allow customers to provision third-party access to specific "permission sets" in a single account, an Organizational Unit (), or Organization Root. Furthermore, using capabilities such as System for Cross-domain Identity Management (SCIM 2.0), customers can automatically update which permission sets a user has based on user attributes or group membership in the originating . This means that organizations can seamlessly manage access to from the source without the manual overhead associated with provisioning.
Note: This task is only meant to explain the basics of - please see the room dedicated to for an in-depth look at these technologies.
What policy determines if an IAM principal has the ability to gain the privileges of a particular IAM role?
Global vs. Regional Service
 services are considered either global or regional. A global service means that the service supports a central control plane (opens in new tab) and data plane (opens in new tab) (management APIs) that does not resolve to a specific region. Whereas with a regional service, the control plane and associated data plane resolve to a specific region where data centers are housed geographically. For instance, US-East-1 resolves to Northern Virginia data centers in the United States. This is a valuable concept for organizations with data sovereignty requirements, but it also serves as a redundancy capability for organizations that architect "multi-region" workloads. You can find a list of all "regional" services here (opens in new tab).
Notable Global Services
There are a few notable services that you should be aware of that are "global" services:
- - Content Delivery Network; allows customers to expose resources to the public internet.
- Route 53 - Domain Registrar and Provider; Route 53 also allows customers to expose resources to the public internet.
- Organizations - Organizations itself is a "global" service.
- - The Access and Authorization service for ; determines what services and resources customer identities can access.
also has a service known as the Security Token Service (STS) - STS is a key service to understanding security as it allows and third-party identities to retrieve temporary access credentials. Uniquely, STS is both a Global and Regional service. This means that STS has both global endpoints and regional endpoints. Though it is counterintuitive, STS tokens vended from a regional endpoint are valid in all regions, whereas tokens vended from the global endpoints are only valid in regions enabled by default.
In a similar case - the "" for buckets is global. This means that once a bucket name is registered, there can be no other bucket across with the same name. However, buckets are stored regionally (opens in new tab) in multiple availability zones depending on the storage class (opens in new tab) selected for the bucket.
Default Regions
Until 2017, all customers had a default region of US-EAST-1. This means, for longstanding customers, that assumes the customer identities are using US-EAST-1 unless another region is explicitly declared. Over time, this caused a disproportionate amount of customer resources to be deployed in US-EAST-1. Since 2017, US-EAST-2 (Ohio) or US-WEST-2 (Oregon) are the default regions for new accounts.
Beyond having a default region for provisioning resources, certain regions are disabled for customer use by default. These regions are (at the time of writing):
- Africa (Cape Town)
- Asia Pacific (Hong Kong)
- Asia Pacific (Hyderabad)
- Asia Pacific (Jakarta)
- Asia Pacific (Melbourne)
- Europe (Milan)
- Europe (Spain)
- Europe (Zurich)
- Middle East (Bahrain)
- Middle East (UAE)
These regions are not accessible using STS global endpoint credentials. As an customer, if you want to use one of these regions to deploy resources, you will need to manually enable the associated region (opens in new tab) and use a regional STS endpoint to retrieve credentials.
If your AWS account was created prior to 2017, what is your account's default region?
2017 — Beginnings of Organizations
had been around for a decade with only the concept of an "account" to centralize management of a company's resources. For large organizations, managing everything in one account was challenging and inflexible. Furthermore, managing each team or department in separate accounts didn't scale well. So in 2017, decided to introduce the "Organizations" service. Organizations allows customers to centralize and standardize key security and operational management capabilities.
A key value of Organizations is the concept of workload . By collecting accounts under an Organization, customers can track various accounts while segmenting individual workloads (e.g., applications, networking infrastructure, etc.) into individual accounts, each with a separate security boundary. Gone are the days of putting all resources in one account.
Organizational Roots, Organization Units, and Accounts
Inside an Organization, all accounts are collected in a "parent " known as an Organization Root. The hierarchy in the below image can be summarized as follows:
- An Organizational Unit () is a sub- under an Organization Root that may include multiple accounts.
- An can contain other nested OUs (see Infrastructure and Security ).
- An can contain one or more accounts (see Network, Shared Service, Security, Log Archive, and the Tenant-x accounts).
- An account can contain one or more User accounts.
Organization Management Account
Organization Management accounts are the primary account associated with any specific Organization. Inside each Organization Management account are a set of roles (opens in new tab) that can be used to access any account in the Organization. By default, this role is named "OrganizationAccountAccessRole" and has full administrative permissions against the associated child account. Using the Management Console to "switch-role" or the to "assume-role", any principal with privileges to assume these roles may be able to perform administrative activities across the Organization.
The Organization Management account is intended to host Organization-wide logging using a Organization Trail (opens in new tab), which allows administrators to monitor control plane activities in . Organization Accounts also host Single Sign-On () configurations to manage Identity Provider () (e.g., Active Directory/Azure Active Directory/Okta/Ping Identity/etc.) integrations. Enterprises and other organizations use the Identity Center to access child account roles and hosted applications across an Organization using the integrated credentials and authentication processes.
Organization Policies
Organization Policies, such as Service Control Policies (SCPs), allow customers to place restrictions on each child account in an organization. SCPs specifically allow customers to place highly customized security and access restrictions on the Organization Root, OUs, or individual accounts. By default, Organizations attaches an SCP named "p-full-access" to each account, which allows subscription to all services. Each Root, , and Child Account can have up to five (5) SCPs attached, and these policies allow restrictions (opens in new tab) such as:
- Allow only approved services (opens in new tab)
- Deny root user access (opens in new tab)
- Require the use of IMDSv2 (opens in new tab)
- Deny ability to create access keys (opens in new tab)
- Region restriction enforcement (opens in new tab)
- Deny ability to leave Organization (opens in new tab)
- Deny ability to make a accessible from the Internet that isn’t alread (opens in new tab)y (opens in new tab)
Notably, Organization Policies do not apply to the Organization Management account. This means that for users and roles in the Organization Management account, SCP restrictions are not effective.
Other Organizations Capabilities
 Organizations has a number of other capabilities that allow for centralized service management for Organizations-managed accounts. You can use the following services with Organizations to manage configurations of child accounts:
- Account Management - Manage contact information related to accounts.
- Artifact - Accept legal/contractual agreements on behalf of accounts.
- Audit Manager - Automated evidence collection for audit activities.
- Backup - Centralize management and monitoring of backups and backup plans for accounts.
- - Centralize logging of "control plane" activity.
- Amazon Events - Share monitoring event data across accounts.
- Compute Optimizer - Identify opportunities to improve compute efficiency based on recommendations, across accounts.
- Config - Aggregate and analyze asset (resource) configuration data across accounts. Enforce configuration requirements across accounts.
- Control Tower - Automate governance and provisioning of accounts in association with Organizations.
- Directory Services - Provision/integrate Active Directory domains with accounts.
- Manager - Centrally manage configurations of Web Application (WAF) rules across accounts.
- Amazon - Automates detection and response to security incidents across accounts.
- Health - Centralized visibility into potential health events related to resource performance and availability.
- Access Analyzer - Analyze resource-based policies to determine what external accounts/principals may be trusted across accounts.
- Identity Center - Allows customers to configure a third-party Identity Provider () or use Identity Center to provision access centrally.
- License Manager - Centralize management of third-party software licensing.
- Amazon Macie - Data identification and classification across accounts.
- Resource Access Manager - Share data resources across accounts.
- Security Hub - Check Organization-managed accounts for security compliance configurations related to governance standards.
- Service Catalog - Share and manage IT service capabilities ( resources) across accounts.
- Systems Manager - Manage and monitor Virtual Machines (VMs) across accounts.
- Trusted Advisor - automated best practices analysis across accounts.
- Amazon IP Address Manager (IPAM) - plan, track, and monitor IP addresses accessing -bound resources.
As there are so many different capabilities, we will not go into detail regarding the specifics of each service. However, it is important to understand, as both a defender and attacker, the native security tools offers and how they impact the attack lifecycle when implemented.
What is the sub-container for accounts in AWS Organizations?
What AWS Organizations account does Service Control Policies not apply to?
Components
At the core, a Virtual Private Cloud, or , is a software-defined network topology that represents 's "traditional" network infrastructure offering for customers. VPCs allow users to restrict the connectivity to sensitive resources designed to be isolated or segmented from other workloads, and critically, from the public internet. The following networking components are commonly found in customer VPCs:
- Internet gateway - allows communication between the and the internet.
- Egress-only internet gateway - allows an IPv6 IP address to initiate outbound connections to the internet, but restricts inbound.
- Carrier gateways - to establish direct communication with telecommunications carrier networks.
- NAT gateways - Network Address Translation service (NAT) gateways allow private subnets to connect to services outside of the .
- - by default, all instances (VMs) in a non-default receive an unresolvable host name assigned by . This can be updated to leverage custom domains.
- - by default, provides resolution to VPCs via the Route 53 Resolver, a global service.
- Public and Elastic IP addressing - maintains over 100 million public IPv4 IP addresses. Many of these addresses can be assigned by customers to specific resources. When using a Public IP address (opens in new tab) ( term), if the associated instance is stopped, the IP address will be reallocated to , and a new IP address will be assigned if the public instance is ever restarted. However, with an Elastic IP address, the IP address is allocated to an account ongoing and can be assigned to arbitrary resources as the customer chooses.
Default Service Capabilities
Beyond the common components found in VPCs, certain service capabilities are configured by default in any using link-local addresses, which are only valid in the local network segment. While these service capabilities are enabled by default, users can configure and disable the following services:
- Resolver - found at 169.254.169.253 in each ; this is the Route 53 Resolver discussed above. customers can disable this service and implement their own server.
- Amazon Time Sync Service (using Network Time Protocol ()) - found at 169.254.169.123 in each ; this service performs time synchronization for compute instances.
- Microsoft KMS Service - found at 169.254.169.250 and 251 (opens in new tab); this service allows customers running Windows to activate Windows licensing via Microsoft KMS (opens in new tab), without having to connect to the internet.
- Instance Metadata Service - found at 169.254.169.254 in each and abbreviated as IMDS, this capability allows instances to retrieve information (opens in new tab) about the instance performing the query, including data from startup scripts, network interfaces, and potentially, instance metadata credentials that were famously used (opens in new tab) for privilege escalation in the 2019 CapitalOne breach.
- Task Metadata Service - found at 169.254.170.2; if a customer is using Elastic Service () to provision infrastructure, this metadata endpoint is used similarly to the Instance Metadata Endpoint.
Endpoints
Endpoints allow customers to integrate specific services with their without requiring customers to use an internet gateway, NAT device, connection, or Direct Connect connection (opens in new tab). Interface endpoints allow customers to integrate eligible services (opens in new tab) using PrivateLink, a service designed to allow such connectivity without exposing the connection to the internet (opens in new tab). Gateway Load Balancer endpoints can be used for traffic interception and associated inspection (opens in new tab).
Note: This task is only meant to explain the basics of VPCs - please see the room dedicated to VPCs for an in-depth look at these technologies.
What VPC feature was used for privilege escalation during the 2019 CapitalOne Breach?
What type of VPC endpoint will allow for network traffic inspection?
In this room, you have learned about core services and features. These capabilities are defining features of as a user and attacker. You should understand the following concepts:
- How "accounts" and "root users" relate to security at a basic level.
- What is, and some of the key features you will encounter with .
- How most services are regional and the difference between a "regional" and a "global" service.
- The wide variety of services that can be centrally deployed/managed using Organizations.
- How software-defined networking allows accounts to create and interact with network-bound resources in VPCs.
You may never log in as a "root user" if you don't have your own account, but you will encounter these concepts while working with .
Ready to learn Cyber Security?
TryHackMe provides free online cyber security training to secure jobs & upskill through a fun, interactive learning environment.
Already have an account? Log in