Welcome to Day 1 of the "How to AWS" series: Setup
If you missed the introduction and drivers behind this series, check it out here. Today we setup the fundamentals: assess what governance, controls, stakeholder engagement and billing details will look like for your AWS footprint.
Many steps are often overlooked in the desire to move faster, innovate, leverage public cloud cost models, modernise your tech stack, avoid that six-figure contract renewal or just get out of that old data centre down the road. It’s always tempting to jump straight in and realise those benefits immediately.
Before we get started, let me reiterate that this is not just a 10-day adventure and then you’ll be done. What we are going to spell out over this series is a way to live and operate effectively in the cloud.
Ask any developer, code is never done. Ask the Ops team, patching and maintenance is never done. Innovation should never be DONE.
As I alluded to in the introduction to this series, the rigour and depth you need to go into is fundamentally tied to the complexity and requirements of your individual situation. Don’t boil the ocean and write a 63-page document when a 3-page document or a wiki article would suffice. Always consider your circumstances and what will work best for your specific situation!
Amazon Web Services (AWS) provide a plethora of tools and information to get you started on AWS. This selection can be overwhelming for some and causes many to skip this step and push on without it. I am not going to reiterate all of AWS’ documentation here, instead I’m going to give you my curated list of resources and pose some questions so you can gauge if it’ll be applicable to your business.
Depending on the size of your organisation, consider engaging Itoc or Amazon Professional Services to run through the Amazon Cloud Adoption Framework (CAF) to leverage best practices and guidance gleaned over years of experience.
The AWS CAF breaks down your cloud adoption journey into key focus areas. From this, you gain insight into the different perspectives and requirements within your organisation, identify key stakeholders and discern action plans for progressing your journey on AWS.
If the full process is not for you, we recommend you review the CAF outline regardless and review the areas you should be considering. At a minimum you need to know:
- Who are your stakeholders? What information/perspectives do they care about/control. Know your environment!
- What are the competing perspectives within your business?
- Who will own the actions we will discuss moving forwards?
- Do we have senior management visibility and buy in? (Trust me, you want this)
Once you have this information, write it down – documents, wiki page, napkin (you get the idea). You will thank me later!
Know your budget. Do you have one? What are you willing to spend? This will be informed by your drivers and individual circumstances. Everyone is different.
We’ve seen many businesses and the approach they’ve taken to funding their AWS environments. There is no single correct approach, just make sure you consider it before pressing the button.
Big budget or shoestring, you can get a long way within AWS. Just know that if you pinch every penny, there is a trade-off in many areas. Which often have costs not accounted for in your AWS bills.
As the old adage goes: "You get what you pay for."
We will cover estimating your costs and comparing Total Cost of Ownership (TCO) in a later blog post.
Set up your AWS Accounts
Everyone starts with one AWS account and eventually outgrows it (for numerous reasons). Let’s skip that step and the future re-work and get you set up with a more resilient structure from the get-go.
There are numerous approaches to designing an AWS Account structure (all with pros and cons). For this blog post, we will be creating four AWS accounts (don’t fear, you don’t get charged for the number of accounts you have). Here we hit our first prerequisite, you are going to need four different email addresses for the root user in each account. I strongly recommend a distribution list or alias be set up for these accounts, please don’t use a specific named user’s email address!
Each AWS account will serve a specific role and these are detailed later in this post, but for now, create email addresses similar to the ones below:
For those who have used AWS for a while, the addresses above may give you all the intent you need. If not, the emails and accounts are explained below.
Use the first email address (email@example.com) to create a new AWS account. This will become your “master” AWS account. In this account we will create an AWS Organisation and configure consolidated billing for your other accounts. You will need to supply a funding source to this account (typically credit card) and perform simple validation steps.
Once your account is validated, the first thing we are going to do is create an AWS Organisation. AWS Organisations enable you to automate the creation of AWS sub-accounts, enforce policies across these accounts and consolidate the AWS billing of these accounts.
Once created, use AWS Organisations to create the three other AWS accounts (using the other email addresses listed above). For the immediate future, these three accounts will be essentially identical, but we will soon change that.
The firstname.lastname@example.org account will be used for secure storage of audit and change logs. This separate account enforces separation of concerns and access between Business As Usual (BAU) activities and audit/security controls on your AWS resources.
The two other AWS accounts will be used for deploying your workloads on AWS. Production workloads within the production account and any environment prior to production in the pre-production account.
We will discuss further the setup of these accounts later in this series.
You should take the time now to setup account contacts (see the stakeholders you identified earlier) for account specific communications from AWS.
Now we have consolidated billing setup, let’s discuss AWS billing. Unlike traditional infrastructure providers (and some Managed Services providers), AWS’ pricing is fully transparent, albeit a bit confusing at times.
To be clear, the price is the price. You pay the same for the AWS resources as large enterprises do. Same kit. There are discounts to be had at large scale – you’ll know it if you’re in that realm.
What many people don’t comprehend is by leveraging AWS, you have the exact same capabilities as a large corporate player operating on AWS. The playing field has been levelled. Great job AWS.
I mentioned budgets earlier. Many businesses have grown used to the reality of fixed-price expenditure. “It will cost me $xxxx for the next 24 months”. This provides certainty, but at the cost of agility, flexibility, innovation and cost optimisation. In AWS, expect your monthly costs to fluctuate. There will always be a semi-reliable baseline, but increases in network traffic, auto scaling additional instances to handle load or the inverse results in varying bills month to month. Welcome to the AWS OpEx utility model, where you pay for what you use.
To track your spend throughout the months you can configure budgets and billing alerts for your AWS accounts. This should be performed in your AWS Master account.
You will also want to create an S3 Bucket and store your Detailed Billing Reports (DBRs) and associated billing reports (such as the AWS Cost and Usage report). This information collection is key to analysing your AWS spend and determining where cost savings can be made!
In this post, we’ve covered:
- AWS Cloud Adoption Planning
- Stakeholder identification
- AWS Account setup
- AWS Organisations
- Consolidated Billing
- Collection of Billing data
In future posts, we will take this foundation and build upon it until you have a solid, working and comprehensive setup on AWS. Read our next post in the series as we expand on the above points and ask you to make several decisions which will influence how you and your business are going to leverage and interface with Amazon Web Services (AWS).