Getting an Organization started on AWS Part 1: Introduction & AWS Accounts

Part 1: Introduction & AWS Accounts, IAM, and AWS Organizations

Part 2: Multi-Account, Landing Zones & AWS Control Tower

Part 3: Domains, DNS & Route53

Part 4: Identity Center, Single-Sign-On & Directory Service

Part 5: WorkSpaces & WorkMail — workforce style users

Part 6: WordPress & Workloads

Introduction:

Hello, and welcome to “Getting an Organization started on AWS — A practical guide to the boring bits that no one wants to do “.

Setting up a business, a charity or whatever kind of organization can be tricky. Especially since COVID and working from home, a lot of technical infrastructure is required when starting a new organization.

This is going to be a guide on getting the ball rolling on the AWS platform. The following course will not be overly technical; however, you will need some familiarity with AWS. Deep product knowledge, however, will not be expected.

AWS is an exciting place for those that need to build complex, feature-rich custom software. Many of the more interesting AWS guides online cover features such as AWS Lambda, Elastic Container Service, S3, API Gateway, etc…

However, when any organization starts, the first technical needs are a tad more boring. There may be a need to create accounts for employees and grant them access to 3rd party software like Slack, Office, or DropBox. You may also need to grant some of these people access to particular AWS resources, or limited access to the AWS portal itself — all through either a 3rd party Single Sign-On provider or one you implement yourself.

Often, simple websites are needed also… However, in my experience, documentation or simple guides that cover the basics of setting up the boring bits on AWS are scattered and not very clear.

And so, I have compiled a set of walkthroughs for setting up the “boring bits” where best practices for security and organizational visibility are followed, and costs and centralized billing are explained along the way.

In the following blog posts (videos also provided) I’ll be going through the theory and the practicals of setting up a new organization’s IT needs on AWS.

I won’t be spending too much time on deep theory — or going into too much detail on the specifics of AWS products or how they work. Instead, I’ll walk you through setting up a new organization (for the sake of this course, a business) according to best practices, with details on cost, security, and operational efficiency.

Setting up the IT for a new organization can be challenging. Normally, there are quite a few things to juggle:

· Website design

· Website hosting

· Server purchase, installation, and maintenance

· Setting up a corporate network

· Office suites (could be Google Workspaces, Office365, etc…)

· Custom domain name(s)

· Corporate email addresses

· Security guardrails

· Network monitoring

The list goes on…

Leveraging the offerings of AWS for your IT needs can help you rapidly set up your organization and serve customers globally. For a start, there are no physical servers to deal with, the shared responsibility between yourself and Amazon means they manage the infrastructure. Generally, this means higher fault tolerance and availability for less cost — with no up-front cost commitments.

AWS is a great starting point for building/deploying any web-based solution and has great out-the-box integration with third-party software.

In this course, we’ll be creating the fictitious ‘Acme Corporation, and shall be doing the following:

-Creating and securing our first AWS account (with a budget)

-Creating a secured and auditable multi-account AWS Environment, with templates for deploying safe environments for what we host on AWS

-Optionally purchasing and managing a domain name through AWS

-Creating business users and providing software & access

-Creating email addresses & mailboxes for our business users using our domain name

- Providing users with a desktop environment (remote desktop)

-WordPress website hosted with our domain name

Anyway, that’s enough introductions — now for some theory on AWS Accounts, IAM & AWS Organizations

Theory: AWS Accounts, IAM, and AWS Organizations

Any resource you create on AWS, whether that be a domain you purchase, a website you set up, a virtual computer (Ec2), etc.… must be created within an AWS Account.

Some infrastructure within AWS can be multi-regional, or global. You could deploy a website to dozens of geographic regions, all of which would still be within a single AWS account. AWS Accounts are global; however, region constraints can be applied to accounts. An account is a global resource container.

To create an AWS account, you need 3 main things: An email address, a payment method (credit card details), and a name for the account.

An AWS Account is not the same thing as a user on AWS, you can create multiple users within one AWS account through AWS IAM. For example, an account could be called ACME-WebSites-Live, or ACME-Management. However, users created in IAM could be for a tool or a real person, such as ‘Administrator’ or ‘Help Desk Member’ or ‘John Doe’. Up to 5000 IAM users are allowed per AWS account. Each user of the account could access, given the appropriate permissions, the AWS account it belongs to– either to the AWS Console (the main AWS webpage where work on AWS is done) or programmatically access the AWS account through code or the command line using an access key and a secret access key.

Each AWS account has a ‘root’ user, this user has an email address and is the user created in IAM when an account is created. The root user has admin permissions, as well as the ability to perform specific actions that only the root user can do. The root user cannot have permissions restricted. You log into the root user using the email address and password, whilst other IAM Users are logged in through their account name, their username, and their password. Normally, you should log in to an account as an IAM User that has been created in the account, instead of the root user.

An account is the best natural boundary between resources. Any resources or users created in an account only exist within that account, which means any issues, bad practices or exploits are contained within the AWS account. Normally in a real-world setting, multiple AWS accounts are used — managed through AWS organizations. Separate accounts should be used for sandbox/development and live, you could also have accounts for different teams, products or clients. Normally the first account you create is called the management account and is used to manage the other accounts you create.

AWS Organizations is a product by AWS which allows us to manage multiple accounts. AWS Organizations is often used within the management account, and other accounts can be created/invited to the organization. You’re able to group different accounts inside an Organizational Unit (OU). AWS Organizations allows for consolidated billing, which means that the card details of the billing account (often the management account) are used by the other accounts in the organization to bill against, and the child accounts pass the charges up as their own quotas. OU’s can have Service Control Policies (SCPs), which restrict the AWS services that can be used by accounts inside the OU.

Walkthrough: AWS Accounts, IAM, and AWS Organizations

1. Go to https://aws.amazon.com and click “Get Started for Free” => “Create a free account”:

2. Enter the email address and account name for the management account we’ll be creating. You can use an email alias with the + sign to create infinite email addresses from one. Most mail providers support this, alternatively, enter a regular email address. For example, john@mail.com or john+yourorganization-management@mail.com.

3. Enter your contact details and card details, then verify your details and select your plan

4. Sign in and complete the captcha

5. Now that you’re signed in, go to the top corner and go to “Account”

6. Scroll down to “IAM User and Role Access to Billing Information” => “Edit” => “Activate IAM Access”. Once you click and select Update, go to the services search bar at the top and go to “Billing”

7. Go to “Billing” => “Cost Explorer” => “Launch Cost Explorer”. It should say it may take up to 24 hours to set up, but that’s fine. That won’t block us, it should start to enable that in the background. Then go back to Billing and go to “Billing” => “Budgets”

8. Click “Create a budget”. Only “Cost Budget — Recommended” should be available. That’s fine, click “Next” then give the budget a name.

9. Set the details of your budget, for example, a monthly recurring budget of $100. Ensure to select the “All AWS services (Recommended)” option. Leave the default values and click “Next”.

10. If you want to be alerted (emailed) when a certain percentage or amount is reached, then add an alert threshold and enter your email address (I specified 79% for some reason). Continue to click “Next” and then hit “Create budget”.

Now that we’ve created our free tier account and provided a budget, now we need to enforce our root user to use MFA to log in. If you’re following at home, you can use a mobile MFA app such as Authy or Google Authenticator, I use the windows desktop version of Authy. Here are the steps:

1. Go to services search bar => “IAM”

2. Click “Add MFA”

3. Activate MFA => Virtual MFA device => Continue

4. Install an app from one of the compatible MFA apps on their list. Show and scan the QR code or copy the secret key into your MFA app, which should create an account on the app for this IAM user. You should see a temporarily pin (MFA code) on the app. Copy that into the “MFA code 1” box, wait for that to expire — then copy the second code into the “MFA code 2” box. Once done, click “Assign MFA”.

5. To prove this, go to the top right and sign out

6. Log back in, and after entering your email and password, you should be prompted for an MFA code. If all pass fine, you’ll be logged back into the AWS console.

So now we’ve secured the root user, it’s time to create a new IAM user we’ll use as an admin. The root user we’re currently logged in as cannot have their permission restricted, however any IAM user we create can. Generally, logging in with the root user is considered bad practice unless you need to.

So to do that:

1. Go back to IAM

2. Users => Add Users

3. Name the user, grant it access to the console, and auto-gen the password. Require a password reset and click “Next: Permissions”.

4. Attach existing policies directly => AdministratorAccess then click “Next: Tags”, add no tags then click “Next: Review”. Continue through and copy the auto-generated password.

5. 1. Notice the sign-on link on the last page. Click that. Alternatively, go back to the IAM dashboard and the link is there also.

6. Enter the password you copied; you’ll then be prompted to reset the password. Enter a secure password and note it down, then sign-in

And that’s everything for creating your first account! Check out part 2 to learn about multi-account and why you need it! However, if you want to close your account — log back in as the root user, go to the top right corner => “Account”

Scroll right to the bottom, tick the boxes, and close the account