How to AWS Blog Series: <br> Day 2 - Decisions. | Itoc

How to AWS Blog Series:
Day 2 - Decisions.

Written by How to AWS Blog Series:
Day 2 - Decisions.,

Posted October 25, 2018

Welcome to Day 2 of the "How to AWS" series: Decisions

Today, we’re going to expand on the previous blog on the setup 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).  

In our previous blog post in this series, Day 1 - Setup, we covered:

  • AWS Cloud adoption planning
  • Stakeholder identification
  • AWS account setup
  • AWS organisations
  • Consolidated billing
  • Collection of billing data
  • Budgets

If you missed the introduction and drivers behind this series, check it out here.   

What is AWS to you?

First and foremost you need to decide how your business will treat AWS. Will it be an extension to your existing network? Will it be an island to itself? Are you only interested in AWS as a sandpit environment? Or perhaps you're all-in?

Each approach is equally important and valid, and all have their pros and cons. This single decision significantly impacts on your perception, trust and configuration of resources within AWS. Do what is right for you in your situation.

By the way, AWS can be all of these scenarios at the same time for your business. The flexibility is there, its just how you choose to engage it. If you’re not sure what is best for you, please get in touch and we’d be more than happy to assist.

In the last blog, Day 1 - Setup, we suggested setting up a simple but robust AWS account structure focused around separation of concerns. If you're only looking for a sandpit environment, that structure may not best fit your needs. Adapt it to suit.

Which Regions?

Once you've determined how you'll be interacting and treating AWS in the context of your business, the next question to ask is which region will you be looking to operate in?

AWS operate a global network of regions to select from which are all easily accessible. When selecting your chosen region(s), do note that due to the scale at which AWS operate and regional demand for services, not all regions are created equal and do lack some AWS products or service offerings. If you will be looking to leverage a particular service, it is worth checking the AWS region table for current service availability by region.

Other factors to consider with your region choice are:

  • Regulatory requirements
  • Data sovereignty
  • Pricing - yes pricing does vary between regions - but not so much that it should be your determining factor.
  • Latency of requests - don't underestimate latency, both to internal stakeholders in your business and your customer base! Just because the region is close to you, doesn’t mean it is close to your customers!

Once you've determined which regions you will operate in, write them down. Bonus points for documenting the reasons why these have been selected!

Now we've solved that one, next is dealing with identity management. 

Identity Management

This is often overlooked and not properly addressed when starting out on AWS. Knowing how you will manage identities upfront will minimise issues down the track. Not to mention that managing this access and the associated identities is core to proper auditing and control of your environments.

AWS provides a built in Identity and Access Management (IAM) solution which provides a robust access control system for interacting with your AWS environment. There is no question, you will use IAM in AWS. It is the mechanism for authenticating and authorising access to interact with all of AWS, be it via the AWS Management Console, via command line, API or SDK.

IAM stops short of providing an end-to-end Identity Management solution for your workloads however.

  • It doesn't manage your Linux or Windows users;
  • It doesn’t provide an easy auth source for your CRM; and
  • It doesn't revoke access in that third-party SaaS provider from your file server.

Straight away you can create users, groups and roles within IAM to allow you to interact and build on AWS. Often this is the first step for getting running on AWS.

The big question is, do you want to manage another set of identities for your users?

Odds are that you already have an identity provider in your business. Think of your email provider, that Active Directory server or SaaS Identity Provider. You need to know what they are, determine if they could be appropriate for providing identities for AWS and if they're compatible with AWS. 

AWS IAM provides direct integration with many SAML 2.0 identity providers allowing you to leverage your existing identities for federated access within AWS. Everyone loves being able to use Single Sign On (SSO)!

IAM is scoped to an AWS Account, so permissions granted in one AWS account, do not transfer or provide rights in another. In any multi-AWS account structure - federation or centralising your identities really comes into its own.

Do you need assistance or are interested in Itoc's recommendations for managing your identities? Contact us here and we will be in touch.

Have some standards!

Next I'm going to challenge you to set some guiding principles or standards upfront. You should strive to achieve and follow them. They are your guiding posts and gate keepers to effective AWS deployments moving forwards.

Standard #1: Embrace Infrastructure as Code

It will take longer initially, but take heart, the benefits will flow. Repeatability, auditability, automation and clarity - these things await. Everything is code! Everything is versioned! Treat your AWS resources as such! CloudFormation is your best friend, and makes sure your team really knows how things piece together.

There will be times CloudFormation may not yet support a certain feature or function. There are ways to work around these and CloudFormation is only getting better!

As a general rule of thumb, native tools always seem to work best. 

Of course there are other options out there (e.g. Terraform, Config Management tools like Ansible, Puppet or Chef, custom scripting). Take a look if they’re of interest or have particular value to your business. Every solution will have its shortcomings and also benefits. Select what is right for you and stick with it.

Standard #2: Use Configuration Management

No manual (aka untracked) changes. There is no excuse for not using one of the readily available Configuration Management tools. The level of confidence, repeatability and automation you can achieve quickly speaks for itself. 

Take a look at AWS Systems Manager and the features available for free on AWS! Of course, Ansible, Chef, Puppet, Salt (just to name a few) are all in the running here as well. Once again pros and cons for each.

Do you want some advice or guidance on which config management tooling we’d recommend for your business? Get in touch

Standard #3: Experiment

Don't be afraid to experiment and try ideas/concepts. There is no barrier to spinning up an isolated test environment and proving a concept, business case or evaluating your options. You can iterate, fail, improve and innovate easily. Prove the point, document your outcomes and then tear it down!

This is possibly the single best way to make data-driven decisions. How will you know which option to select if you can't eliminate a few and prove the others?

Standard #4: AWS Support

Sign up for and enable AWS Support. Business support is crucial for any account running Production workloads. Make sure to encourage your teams to use it, and not just when things are broken.

This is a large resource for AWS guidance and troubleshooting. It is often a very under-utilised service - you pay for the service so you might as well use it.


Hopefully, it goes without saying, but document your decisions! Document how Identity Management will work for your business and the high level standards you will follow.

Once these are documented, communicate them with your stakeholders identified earlier in the blog series. Communication is key to ensuring everyone is on the same page. The opportunity for feedback and course correction is really key to your success.

In Summary

In this post we discussed your stance on:

  • How you will treat AWS within your context;
  • The regions you will operate in;
  • How you will manage identities within AWS
  • Set high level standards to guide operations and workload planning on AWS.

We have covered many topics in this post, but there will be more for your to consider as you leverage AWS to propel your business to new heights. How you leverage it is up to you, your team, and any external parties that you engage with to see you there. In our next blog post in this series we will discuss security.

How to AWS Blog Series:
Day 2 - Decisions.

Need help getting started with AWS?