I’ll utilize the trips.com company, which we used as an example in the prior post, so if you missed it, check out *HERE*.

I’ll briefly and simply describe the concepts of an AWS account and an organization in this post. Finally, I’ll discuss IAM, one of the most essential AWS services. So, let’s go.

Account

“An Account is a container for your AWS resources. You create and manage your AWS resources in an AWS account, and the AWS account provides administrative capabilities for access and billing.”

Well, I previously mentioned that AWS offers +250 services. In order to use these services, you just need to create an account through the AWS Console and start to use them.

Inside an account, you can create and restrict users, manage services, and access multiple AWS regions inside the same account.

Let’s go back to our beloved app: trips.com. Users around the world are heavily using the app, which has the infrastructure in the us-west-2 (Oregon) region.

Singapore users complain that every action they perform on the app takes too long. This happens because data needs to travel long distances between Singapore and Oregon. To solve this issue, they could access the AWS Console, change the region in the UI to ap-southeast-1 (Singapore), and launch the infrastructure in the new region. After that, trips.com will be running in the Oregon and Singapore regions within the same account.

Important note: When an account is created, the credentials filled into the sign-up form are used to create the root account user. This user has full power inside the account and is the only user who can perform some action, like closing the account. This user shouldn’t be used, and it’s highly recommended to enable 2FA. You don’t want the superuser of your account to have the credentials leaked.

Organization

“An organization is a collection of AWS accounts that you can organize into a hierarchy and manage centrally.”

With organization, it’s possible to add and manage multiple accounts easily instead of managing them one by one. For example, you can create an account for the engineering team, one for the company’s homologation environment, and one for the production environment for end users. All these three accounts could be associated with the management account and enjoy the benefits of an organization.

Also, it’s possible to organize them into Organization Units (OU) and organize them hierarchically, following your company’s structure.

Example: You could create an engineering OU with development and test accounts. Then, create a growth OU with marketing and sales accounts.

A few benefits:

• With organization, you could restrict what accounts can do. For instance, you can forbid the root account user of production to delete the AWS account.
• It’s possible to apply compliance rules that all AWS accounts must follow and track if these rules are being followed.
• Also, the organization offers the concept of Consolidated Billing, which means that instead of paying charges for each account, you can pay them all together. The awesome part is, do you remember the concept of paying less by using more? With Consolidated Billing, as all the charges are together, AWS is considered as one single account usage, and you can have discounts on your final bill.

Again, with an organization, you can restrict the root account user of the account, but you cannot restrict the root account user of the management account, so make sure to double-protect this user.

Now that you know what an account and organization are, let’s dive into IAM service.

I believe that AWS has four essential services without which it wouldn’t be running. Are they: EC2(Virtual Machine), S3(File Storage), CloudWatch(Logging e monitoring) and the famous IAM (Identity Access Management)

Identity Access Management

IAM is responsible for managing identities inside AWS. It manages users’ access to AWS services through AWS Console or APIs, and most importantly, it manages the access between services.

Compared to the real world:

The Google Workspace of your company is only accessible to employees. Additionally, some data and operations inside the workplace are only accessible to employees with specific permissions. IAM ensures that only users of your account (or organization, depending on how it has been configured) may access its services and that users can only access what has been granted to them.

Another example:

You have contracted the Apple Care service, and you added your credit card to the Apple Pay Wallet to use contactless payment, but then, without any permission, Apple used this credit card to pay for the Apple Care service. Wouldn’t that be terrible? IAM prevents these things from happening inside AWS. In order to integrate services, you must explicitly give permission to them. By default, every integration is denied.

IAM is a simple but super essential service with four main services: Users, Groups, Policies, and Roles.

Users

A user is an identity that you create inside AWS. It represents a human or a workload that performs actions in your account(e.g., an analytics platform that reads data from your database)

A user has a name, email, password, and/or access keys.

The user password is used to access the AWS console, while access keys are used to access AWS programmatically via API.

Note: By default, new users have no permission. So, once the user is created, you have to assign permissions to allow the user to perform any action inside the account.

Groups

Group is a very simple feature. It’s an identity that allows you to group users and assign permissions to the group instead of assigning permissions to each user separately.

Note: Groups only support users; you can’t add a group inside a group, and you cannot sign in using a group.

Policies

Policy in AWS defines permissions and can be attached to IAM identities (User, Group, Role) or IAM Resources. Once a policy is defined and attached to an identity, that identity inherits all the permissions of that policy.

A policy looks like the image below:

It has statements that contain:

• Effect (Allow or Deny)
• Action that is composed of service: operation, in the above example, S3 PutObject(add an image to S3)
• And the Resource affected by the operation

Note: Policies are useless if not attached to an identity or resource.

Roles

Role is another type of IAM identity; it’s similar to IAM user, but with a key difference: IAM Roles can be assumed by anything that needs it.

By “assume,” I mean that the service, which has the role assigned, gains access to all its policies (permissions).

Another difference for a user is that roles don’t have long-term credentials. When a service needs to assume a role, temporary security credentials are generated for the role.

Without a role associated, a service can’t use another service. That’s why I consider roles the most important features of AWS.

A role is composed of two parts: Trust policy (who can assume the role) and policies (permissions).  Let me give you an example: The trips.com server needs to save a user image on S3. When the server tries to save the image, S3 invokes IAM to check if the action is allowed. IAM will check first if the trust policy allows the server. Once allowed, it will check if the action has an allowed effect. In case both validations succeed, the server will be able to perform the upload.

Note: A role without any policy attached grants no access to the role.

Well, these are the basic topics of IAM that I wanted to show to you, and I hope you understand why IAM is so important. Now, I would like to present you with an AWS principle considered best practice, which you should probably follow.

Least Privilege Principle

The principle of the least privilege states that identities should only have access to what they need to fulfill a task. So, instead of giving admin permissions to anything, you should give just the minimum of permissions that the identity needs.

For example, the trips.com server needs to add a user image to the S3 and send a notification to the user’s email. The role assigned to the server must contain a policy with just two allowed actions: S3:PutObject and sns:Publish.

That’s all for the second part of the series, I hope you liked it and understand the concepts of Accounts and Organizations. And the importance of the IAM service. See you in part 3.

I friendly advice: Avoid the us-east-1(N. Virginia Region) region as much as possible. It’s the oldest and biggest region. It’s the base for most global services and AWS applications, such as AWS Training and AWS Skill Builder. Because of that, it’s the region that has most of the outages and problems. I highly recommend using the us-west-2 (Oregon) region.