How to AWS - Day 4: Groundwork

Itoc-Hubspot-Post_Blog_How-to-AWS-series

Welcome to Day 4 of the "How to AWS" series on implementing the base "groundwork". If you missed the introduction and drivers behind this series, check it out here.

In the previous blog post in this series I encouraged you to:

  • Define your security policy
  • Establish logging and audit trails
  • Consider how you will use AWS Identity and Access Management (IAM)
  • Harden your operational environment
  • Secure your code

Today, we will shift focus a little and start implementing the base “groundwork” for your AWS environment. We will setup the initial IAM configuration, design and deploy our base networking and touch on DNS.

Lots to cover, so let’s get started.

Identity and Access Management (IAM)

No one likes to maintain multiple user accounts, and it's the same when using AWS. A key tenant of your security and auditability is tying actions back to a specific named entity. In the last blog post in this series, we touched on your identity management. My preferred approach by far is to leverage your existing identities and federate into AWS.

If you have chosen to federate identities to your AWS accounts, now is the time to setup this federation against each account. There are numerous guides and documentation on how to do this (for those who don’t know, Itoc can assist you with this). There’s also the option of using AWS Single Sign-On (SSO) - you can read more about that here.

If you’ve opted for IAM identities, we will be leveraging your master account as the central identity account from which people interact with your AWS accounts.  

Side Note: There is a strong case for separating your organisation’s master and billing account from your AWS identity account. This is essentially a separation of duties concern (and a valid one). So by all means, if you want to do this, then do so. However, for the sake of this blog series, we’ll use the master account.

Roles

In each account, we will create IAM Roles (read about them here). These roles will be assumed by your users who have the requisite permissions. By assuming a specific role, the user gains the ability to execute permissions granted to the role. If you’re new to the concept, it’s worth reading the AWS docs on the topic.

Users will log into the master (our identity) account, and then assume the required role in the target AWS account. From there, users can then perform any necessary AWS actions as required. This is depicted in the diagram below.

Role Assumption

This access pattern allows for incredible flexibility in what permissions your users can assume to interact with AWS. For the purposes of this blog series, I will create two roles in both the production and pre-production accounts. The roles will be:

1. Read-only access

2. Administrator access

This is a very simplistic setup, but is easy to expand upon and customise for your specific requirements. The roles and functions you define in your account should reflect the requirements for your business. Often a great starting point is to look at the AWS Managed Policies for Job Functions, take a look and work from there.

To deploy our roles we will use AWS CloudFormation and StackSets from our master account. This will enable us to deploy and manage the IAM roles centrally and easily deploy across our accounts. For this blog post, we will use the template here. If you’re going to use this template, make sure to grab the account ID of your identity account (our master account for this series), you will need it. We’re also enforcing users to have MFA enabled to assume the roles.

Once that’s complete it’s time to create some IAM groups and grant them permission to assume the roles. For the sake of brevity, here’s a link to the CloudFormation I used to setup the IAM groups. The following table shows the permissions mappings I chose to create for this blog post.

IAM Group

Production Account

Pre-Production Account

Administrators

Administrator access

Administrator access

Developers

Read-only Access

Administrator access

Management

Read-only Access

Read-only access

Now create some IAM users, add them to the relevant groups, setup MFA and login to start assuming roles!

Once you’ve created your IAM users and added them to the relevant groups you can use the quick role assumption list I’ve created below for you (note the placeholders in each link for your specific Account IDs). Depending on the group your user is in, you’ll have access to assume the permitted roles.

Account

Role

Link

Production

Administrator

https://signin.aws.amazon.com/switchrole?account=PRODACCOUNTID&roleName=Administrator

Production

Read-only

https://signin.aws.amazon.com/switchrole?account=PRODACCOUNTID&roleName=ReadOnly

Pre-production

Administrator

https://signin.aws.amazon.com/switchrole?account=PREPRODACCOUNTID&roleName=Administrator

Pre-production

Read-only

https://signin.aws.amazon.com/switchrole?account=PREPRODACCOUNTID&roleName=ReadOnly

Note that the only changes between the links are the AWS Account ID. Pro Tip: Setup AWS Account Aliases to assist in identifying accounts!

From here you’ve got the fundamentals setup for accessing and interacting with AWS using short-lived security credentials (security win!)

Network Architecture and Planning

Your requirements for networking are going to be specific to your workload, use case, and requirements. Networking fundamentals in AWS resolve around Virtual Private Cloud (VPC) configuration and design, closely followed by connectivity.

Do you need one big VPC which all your AWS resources will reside in, or would a number of smaller VPCs work best for you? The flexibility is there and you can make it as simple or as complex as you require.

Questions that may help you shape your VPC design are:

  • What kind of workloads will you be deploying?
  • What are your connectivity requirements?
  • How many internal IP addresses do you require?
  • How many availability zones do you need?

The few sane defaults I want to share here are:

  • Always deploy a large VPC (/20 or /16) - give yourself room for growth (unless your networking admin says otherwise!!)
  • Deploy subsets in every available availability zone for your chosen region (even if you won’t use them initially)
  • Implement Public and Private subnets (and know the differences)
  • AWS managed network address translations (NATs) are your friend! (Most business requirements don’t need them deployed in every AZ - save those $$ if you can!)

Specifically for your VPC implementations:

  • Know the current  Classless Inter-Domain Routing (CIDR) ranges in use in your business (e.g. in your office) - don’t use them in your VPC. Avoiding IP conflicts makes your life easier in the long run! Got a network admin? Now is the time to reach out and involve them in planning your networks!
  • Enable DNS hostnames and resolution within your VPCs (you’ll thank me later when you use private DNS for services like AWS PrivateLink)
  • If you need an IPsec connection, use the AWS Managed VPN Connection.
  • Network Access Control Lists (NACLs) serve a use case, but you should leverage AWS Security Groups in preference. Once you hit the NACL rule limit you will know why!

After all of the above, you should have a good idea of what your network environment/architecture should look like. Take the time to define this as Infrastructure as Code (e.g. CloudFormation). For this blog post series, we’ll use the AWS Quick Start VPC template from AWS as an example.

Domains and DNS

Now we’ve got our VPC networking setup, lets touch on Domains and Domain Name Systems (DNS). AWS provides a very robust service for this - Route53. As with pretty much everything in AWS, you can and should interact with it programmatically.

Even if your domains are purchased and registered elsewhere, I strongly recommend using Route53 for your DNS records. Go update those NS records now! Tight integration with AWS services and some awesome capabilities make this a no-brainer!

Route53 offers both Public and Private hosted zones. The former is publicly resolvable, and the latter is only resolvable from within the desired VPCs. As we start deploying resources in AWS, we can programmatically add DNS records for our resources and thus ensure our DNS is always in sync with our infrastructure.

It’s worth looking at the Route53 feature set - it can help with blue/green deployments, user routing and much more.

Keep up the doco!

You’ve just made many decisions and implemented the groundwork on which the rest of your AWS environment will be based. Take the time to document and communicate these decisions!

Document your decisions, keep it concise, and explain the reasoning for bonus points.

In this blog post we setup Identity and Access Management (IAM) for your AWS accounts, designed and implemented your Network Architecture and recommended using Route53 for your DNS requirements.

The next blog post in this series will focus on laying the base operational foundations for your environments on AWS.

To get in touch, simply leave your details below and we’ll contact you shortly. 

how can we help you?

We’d love to catch up for coffee and discuss how we can help you achieve great outcomes in the cloud.

contact us