aws - cirelledo-csa/herd GitHub Wiki

Amazon Web Services

Amazon Web Services AWS is a global compute services provider

Why use AWS Services?

Because they are services! Generally any Amazon service that provides the technical requirements you need will probably be better than anything you build for reasons of:

  • availability
  • capability
  • consistency
  • convenience
  • cost
  • full stack integration
  • scale
  • standing on the shoulders of giants

Always use the native AWS services unless there is a compelling technical reason not to. This is how we're used to running this is not a compelling technical reason. Some examples are:

Want to be a good AWS rancher?

  • Respect the well architected frame work provided by AWS.

  • Cattle not Pets aka Immutable Cattle.

  • Treat infrastructure like it's software.

  • Don't rely on static resources.

Where do we graze our cattle?

AWS has regions distributed across the globe. Our default region is us-west-2 (oregon) because it's cheap and fast. us-east-1 always has the services running in us-west-2.
us-east-2 is probably also ok for DR. Use multiple availability zones within a region for durability but remember availability can come at the expense of cost.

Herd Management

RTFM

AWS is thoroughly documented

  • Don't be shy about asking for advice.

    • Ask your peers.

    • Ask AWS for advice.

    • Second opinions can be of great help.

  • Don't assume you know everything about AWS Services.

    • There are too many and they continue to grow in breadth and depth with surprising new features.

Accounts

We want a multi account strategy that makes it easy for us to create and manage will architected applications. Some issues to think about:

  • blast radius
  • separation of function
  • product inventory
  • cost allocation
Account creation and configuration

Use AWS control tower as the only way to control account creation and configuration

  • Record and enforce configuration state in each AWS region with AWS config service.

  • Create accounts within AWS Organizations Service

  • Use ServiceControlPolicies to limit services as needed.

  • We should probably have prod vs not prod organization

  • name accounts sensibly, $Product$Environment

  • tag accounts sensibly, $Product, $Environment, $Owner

  • Products map to Product owners, eg $Product@$HostedZone is an alias to a team led by a product owner

  • Use account name for root email contact $Product$Environment@$HostedZone

  • Create shared services account(s) for core functions like AD, logging, network, security, etc.

    • which account(s) hosts shared services?

  • run non production products in non production accounts

  • no sharing of accounts for separate production products

  • production products run in dedicated production accounts

    • restrict access to production accounts as much as possible

    • create a role that allows a build account to deploy production workloads

    • do NOT allow humans to directly change production workloads

      • grant developers access to change almost everything in a dev account
      • consider using burner poc accounts for poc - burner accounts should be incinerated after some period of time
      • product owners/developers are responsible for what they create in their accounts
      • A central service build account should compile code and deploy versions of a product to target accounts
      • cross account deployment details

Infrastructure as code

  • Deploy all AWS services using CloudFormation service. You read that right, use a service to deploy a service! This can lead to the interesting situation of using a service to deploy itself resulting in nested CloudFormation stacks.

  • A few things can not be created via cloudformation, but most everything can

    • use awscli for these exceptions.

  • Use code to orchestrate cloudformaton creation and deployment:

  • cloudformation stacks should have useful outputs

  • Store your cloudformation code in git, eg:

  • Store code that creates cloudformation in git

  • Store parameters in secrets manager or parameter store

Logging

  • If it moves log it! Log everything to AWS an service:

  • Log all AWS api calls in all regions of all accounts to an S3 bucket with AWS cloudtrail service

    • you can replicate cloudtrail to multiple buckets if needed.
    • enforce cloudtrail checksum so you know the veracity of the logs.

Networking

  • Record network traffic in every VPC with the AWS flowlogs service

  • use AWS DNS route53 service

    • use root hosted zones in a DNS account
    • delegate hosted zones for accounts $account-name.$hostedzoneroot

  • use AWS Transit Gateway to centralize networking and provide a scalable consistent network architecture for all accounts.

    • which account host transit gateway?

  • use AWS vpcs to isolate applications

Security, Identity & Compliance

Use native AWS security, identity and compiance services: