Preparing For AWS Solution Architect Certifications – Infrastructure Organization, Account, IAM

Let’s continue with my study notes giving a brief look at how the Amazon Web Service is built and how it organizes tenant, services, permissions, etc.

Global infrastructure organization

Amazon Web Service is a multisite, multi-datacenter Public Cloud Provider spread across the world. At the root of the service, there are the regions and edge locations: geographic places where a cluster of data centers are physically located.

AWS has the concept of a Region, which is a physical location around the world where we cluster data center. Today AWS could be delivered in 20 regions that are distributed around the globe.

An Availability Zone (AZ) is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region.

AWS Local Zones place compute, storage, database, and other select AWS services closer to end-users. With AWS Local Zones, it’s possible to easily run highly-demanding applications that require single-digit millisecond latencies to your end-users such as media & entertainment content creation, real-time gaming, reservoir simulations, electronic design automation, and machine learning.

AWS Wavelength enables developers to build applications that deliver single-digit millisecond latencies to mobile devices and end-users. AWS developers can deploy their applications to Wavelength Zones, AWS infrastructure deployments that embed AWS compute and storage services within the telecommunications providers’ data centers at the edge of the 5G networks, and seamlessly access the breadth of AWS services in the region.

AWS Outposts bring native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility

Services: AWS offers a broad set of global cloud-based products including compute, storage, database, analytics, networking, machine learning, and AI, mobile, developer tools, IoT, security, enterprise applications, and much more.

High Availability, continuity, and compliance:

• Each AWS Region has multiple AZ’s
• customers who care about the availability and performance of their applications want to deploy these applications across multiple AZ’s in the same region for fault tolerance and low latency
• AZ’s are connected to each other with fast, private fiber-optic networking, enabling you to easily architect applications that automatically fail-over between AZ’s without interruption.
• The AWS control plane (including APIs) and AWS Management Console are distributed across AWS Regions and utilize a multi-AZ architecture
• In addition to replicating applications and data across multiple data centers in the same Region using AZ’s, it’s possible to choose to increase redundancy and fault tolerance further by replicating data across AWS Regions
• In the case of data residency requirements, it’s possible to choose the AWS Region that is in close proximity to the desired location. It’s possible to retain complete control and ownership over the region in which your data is physically located, making it easy to meet regional compliance and data residency requirements.

Source: https://aws.amazon.com/about-aws/global-infrastructure/regions_az/

Other resources:

• https://cloudacademy.com/blog/aws-global-infrastructure/

Accounts and Identity Access Management (IAM)

AWS Account

When you start using AWS, a new Account is created. The Account is an isolated piece of authentication and billing. The root account is first created when you start using AWS. By default, it owns all the billing coming from itself and the other accounts.

Note: In large Enterprise, as a best practice, it’s important to create further accounts in order to distribute operative environments and avoid the direct usage of the root account. The purpose of the root account in large companies is to handle accounts, policies, authentication, billing, etc… Check also these suggested reading: https://aws.amazon.com/blogs/mt/tag/aws-multi-account-management/

The first created user is called AWS account root user. It has a single identity and has complete access to all AWS services and resources in the account.

It’s strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM use.

Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html

IAM

Main doc page: https://docs.aws.amazon.com/iam/index.html

IAM (Identity and Access Management) is a web service that helps you securely control access to AWS resources. Using IAM it’s possible to control who is authenticated (signed in) and authorized (has permissions) to use resources.

IAM Features:

• Shared access to your AWS account: grant other people to administer and use resources in the Account
• Granular permissions: grant different permissions to different people for different resources
• Secure access to AWS resources for applications that run on Amazon EC2
• Multi-factor authentication (MFA)
• Identity Federation: federate the corporate user directory
• Identity information for assurance: logging information about those who made requests in the Account
• PCO DSS Compliance: supports the processing, storage, and transmission of credit card data by a merchant or service provider, and has been validated as being compliant with Payment Card Industry (PCI) Data Security Standard (DSS)
• Integrated with many AWS services: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html
• Eventually Consistent (https://en.wikipedia.org/wiki/Eventual_consistency): IAM achieves high availability by replicating data across multiple servers within Amazon’s data centers around the world. If a request to change some data is successful, the change is committed and safely stored. However, the change must be replicated across IAM, which can take some time.
• Free to use: IAM and STS (Security Token Service) are offered by AWS at no additional charge.
• IAM could be accessed by:
  • AWS Management Console
  • AWS CLI
  • AWS SKD
  • IAM HTTPS API

Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html

IAM Users are not separate accounts. They are users within your account. Each user can have its own password for access to the AWS Management Console.

If the users in your organization already have a way to be authenticated, such as by signing in to your corporate network, you don’t have to create separate IAM users for them. Instead, you can federate those user identities into AWS.

Federation is useful in these cases:

1. users already have identities in a corporate directory
2. users already have Internet identities

The access management portion of AWS Identity and Access Management (IAM) helps to define what a principal entity is allowed to do in an account.

A principal entity is a person or application that is authenticated using an IAM entity (user or role).

Access management is often referred to as authorization. It’s possible to manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources.

A policy is an object in AWS that, when associated with an identity or resource, defines their permission.

Permissions in the policies determine whether the request is allowed or denied.

In a single account in AWS, it’s possible to define the permissions within that account using policies. With IAM roles it’s possible to handle resource-based policies, or access control lists (ACLs) for cross-account permissions.

In a multiple accounts organization, it’s recommended to use the AWS Organizations service to help you manage cross-account permissions.

An IAM user can’t access anything in the account until permission is given. The identity-based policy, which is a policy that is attached to the user or a group to which the user belongs.

Policies are summarized in three tables:

1. Policy Summary: includes a list of services.
2. Service Summary: includes a list of actions
3. Action Summary: includes a list of resources

Policy Example:

Structure:

1. Version
2. Statement
   1. Effect: Allow or Deny
   2. Action: the verb of what you can do… in this example all DynamoDB actions
   3. Resource: specify the resource where the policy can apply. In this case only in a specific table called Books

IAM groups are entities that group IAM users. It’s possible to attach a policy to a group to let contained user use the same policies. (check also: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html )

Federated users don’t have permanent identities. To assign permissions to federated users, it’s possible to create an entity referred to as a role and define permissions for the role.

Identity-based policies are permissions policies attached to an IAM identity such as an IAM user, group, or role. They control what actions the identity can perform, on which resources, and under what conditions:

• Managed policies
  • AWS managed policies
  • Customer managed policies
• Inline policies

Resource-based policies are permissions policies attached to a resource such as an Amazon S3 bucket or an IAM role trust policy. They control what actions a specified principal can perform on that resource and under what conditions. Resource-based policies are inline policies, and there are no managed resource-based policies.

Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html

Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags. Tags can be attached to IAM principals (users or roles) and to AWS resources. You can create a single ABAC policy or a small set of policies for your IAM principals.

The traditional authorization model used in IAM is called role-based access control (RBAC). RBAC defines permissions based on a person’s job function, known outside of AWS as a role. In IAM, you implement RBAC by creating different policies for different job functions.

As a best practice, you grant the minimum permissions necessary for the job function. This is known as granting least privilege

ABAC provides the following advantages over the traditional RBAC model:

• ABAC permissions scale with innovation. It’s no longer necessary for an administrator to update existing policies to allow access to new resources
• ABAC requires fewer policies. Because you don’t have to create different policies for different job functions, you create fewer policies
• Using ABAC, teams can change and grow quickly. This is because permissions for new resources are automatically granted based on attributes
• Granular permissions are possible using ABAC
• Use employee attributes from your corporate directory with ABAC

Some AWS products have other ways to secure their resources as well. The following list provides some examples, though it is not exhaustive:

• Amazon EC2: In Amazon Elastic Compute Cloud you log into an instance with a key pair (for Linux instances) or using a user name and password (for Microsoft Windows instances).
• Amazon RDS: In Amazon Relational Database Service you log into the database engine with a user name and password that are tied to that database.
• EC2 + RDS: In Amazon EC2 and Amazon RDS you use security groups to control traffic to an instance or database.
• Amazon WorkSpaces: users sign in to a desktop with a user name and password.
• Amazon WorkDocs: users get access to shared documents by signing in with a user name and password.

For quick links to common tasks refer to this doc page: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_quick-links-common-tasks.html

Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html