This article will discuss the steps I took to create the accounts and organization I will use during my online course for the Solutions Architect Professional certification. See Yesterday’s post for more details about my intentions with these articles and what I hope to accomplish.
This section is introductory, but I want to document regularly what I do in this course.
Accounts are containers for identities and AWS resources. By default, accounts are also self-contained and have no access to resources outside of the account, and nothing has access to anything inside the account. To create an account, you need to have the following:
- A unique email address
- A name associated with the account
- A Payment Method (more on this later in organizations)
By default, a single user is created to use the account - this user is the root user. However, it is advisable to create additional users using the IAM console and avoid directly using the root user to access the account.
To get the account in a state where an IAM user can access it and administer it and avoid logging in with the root user, you may want to set up the account (using the root user initially) to allow access to the account billing info for IAM users. To do this, you must select the account name in the console and choose the account menu item. From there, you scroll down to the section that is titled IAM User and Role Access to Billing Information and click edit. Finally, make sure that Activate IAM Access is checked.
Another good step is to set up a billing alert and budget. Doing this will alert us if we go over a preset amount in a given period. The process to do this is as follows: Click on the Account Name in the top right-hand corner of the console. Select Billing Dashboard
- Click on Budgets
- Click on Create Budget (Choosing Advanced)
- Choose Cost Budget in the list of available budget types.
- Give the budget a name. I named mine “Monthly $10 Budget”.
- Set the Budget Type to Recurring
- Select the Start Month (this should be the current month)
- Select the fixed method
- Enter a budgeted amount. This amount will be the amount you plan to spend every month.
- I left the scope with the default values.
- On the next screen, you can set up a threshold. Doing this will provide you with an alert at a percentage of your spending so you can make sure you’re on track before reaching your budgeted amount.
- I chose 50% of the budgeted amount of $10 for my threshold.
- Now click through and finally click Create Budget.
Setting this budget and threshold should provide peace of mind when working with the accounts. Setting this up is helpful because AWS services can get expensive if you accidentally leave an EC2, RDS, or other services running.
As mentioned earlier, it is generally considered bad practice to use the root user account to do daily work on the account. Therefore, the root user should be reserved for only those tasks restricted to the root user. Therefore, creating an admin user using IAM for daily tasks is a good idea. To create an admin user, follow these steps:
- In the AWS Management Console, navigate to IAM.
- Click on Users in the menu on the left side of the screen.
- Click the Add users button.
- Give the user a User Name and Select Password. Finish the screen by providing or generating an appropriate password and indicating if the user should be required to change the password at first login.
- In the following screens, you can choose how to give the user permissions or assign the user to groups. The easiest way to create an admin user is by directly attaching a policy - using AdministratorAccess. You could also create a group, assign this policy to the group, and put users who should be administrators in the Administrators group.
- At this point, click through the remaining screens.
Once you have a user setup with Administrator access, you can log out of the root user and log in with IAM credentials by specifying the account number, IAM User ID, and the newly created user password.
It is a good idea to set up MFA for privileged users. Using MFA is best practice for both the admin user we just created and the root account. To set it up, log in with the user. Next, you must set up MFA and click on the account name. From there, select Security credentials. Then choose assign MFA. You can use an authenticator app, security key, or a hardware token. The process is relatively straightforward. Simply follow the prompts to set it up. It is important to note that each account will need a separate MFA setup. Most devices allow multiple profiles, and this is easy to do when using virtual/authenticator app style MFA.
If you will be using IAM users to manage the account, it is generally easier to do if you set up the Account Alias. To do this, go to the IAM dashboard. Then, click on edit near the Account Alias section on the right-hand side of the screen and choose a unique name. If the name is accepted, the sign-in URL, displayed directly below the Account Alias, will update, and your IAM users can use that link to log into their accounts. One note here is that the name must be 63 characters or shorter, lower case letters, numbers, and hyphens are ok. Also, the name must be globally unique - if another account (not just accounts you control but any account on AWS) is using an alias, it will not be available for you to use.
To enable access programmatically or command-line access to AWS resources in the account, you need to set up an IAM user with Access Keys. You can set up the admin user you created with keys or create other users, which is probably a better idea in most cases, with more limited abilities, and set up keys for them. To create access keys for an existing user:
- Click on the Users menu item in the IAM dashboard.
- From there, click on the username you want to give access to.
- Choose the Security Credentials tab.
- Click on Create Access Key.
Some notes about Access Keys:
- Access keys are pairs of keys.
- Access Key ID - The shorter of the two IDs shown to you in the console after creation.
- Secret Access Key - A long string of letters, numbers, and symbols. This will only be shown to you at the time of creation. If you lose/forget/don’t record this key, you will need to delete the pair of keys and regenerate a new set.
- An IAM user (or the root user, though it is a bad idea to create access keys for your root user) can have zero, one, or two access keys at any given time.
- The idea behind having two sets of keys is that you may need time to update your applications using the keys. So, having two allows for rotation while both keys work until the first key is no longer in use and can be safely deleted.
- You can disable a key before deleting it. This would allow you to turn off a key pair temporarily; if problems are detected, it would be easy to turn the key back on. Do this before deleting the key for a period after a key rotation.
Setting up an organization allows for easier management of multiple accounts. However, a couple of important benefits beyond easier management are:
- Billing for the accounts in the organization all funnel through the management accounts. You will receive only one bill for all the accounts in the organization.
- Discounts for reserved and provisioned usage can be shared among the accounts, thus allowing for more significant savings.
You only need to go to the organization home in the AWS console to set up an organization. From there, click on create organization. The account that you did this under will become an organization’s management account. The Organization console allows you to invite other accounts, as long as they aren’t already part of an organization, and create new accounts directly under the organization. If you invite an existing account to an organization - the root user of that account will receive an invite to join the organization. If they accept, they will now be under the new organization. If you create a new account under the organization, it will be created with a particular role called, OrganizationAccountAccessRole. This role has a permission policy with AdministratorAccess, full access to the new account, and a trust relationship that allows it to be assumed from the management account. If you invite an existing account, you will need to create this role manually in the invited account.
This role allows IAM users, with appropriate privileges, from the management account, in the console and programmatically to assume the role and work inside the member account.
So far, I have just run through the second section on creating the accounts and a little on the fourth section on organizations. I skipped ahead to that fourth section because I wanted to make both accounts directly in the organization rather than providing payment details. All of this was review from my associate-level courses - but it has been some time, so it was probably good to go through it again. Also, taking the time to write my notes in a post like this has helped me think through the details. Before we get back to the rest of the IAM and organizations stuff, the following section reviews a bunch of topics related to networking, configuration files, DNS, and such. I plan to skim through this section quickly because it is a review. There will be a few parts I go deeper into - but most of it will not be something I spend a ton of time note-taking and writing about here.