with overlapping CIDRs • Non-Production and Production workloads sitting in the same Account YIKES! • Eventually migrated department workloads to 40+ AWS Accounts • March 2017: https://speakerdeck.com/stevepotayteo/a-multi-aws- account-story • Current Company • Worked on AWS Account & VPC Strategy based on enterprise requirements • Thinking of how to scale AWS Multi-Accounts and VPCs is one of my weird hobbies
Strategy •Which should be deliberate, tailored to your organization’s current needs and allowed to evolve to future needs •Removes doubt on where to place workloads
private cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud. 2. VPCs = network containment != AWS User Access Security!
designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” – Melvin Conway • Eg. Business – Profit Center • Eg. Dev Team – Cost Center • Usually done because of a need for showback / chargeback or isolation among workloads • Easily broken when prone to organization changes
– Platform / Service •Fine-grained – System / Application •Splitting it too fine-grained might not make sense at all if it makes workloads too small • Eg. 1 AWS account just for 1 EC2? • Container optimization?
good architecture is to defer decisions, delay decisions.” – Uncle Bob Martin •Decisions are driven by concerns, which can be immediate or non-immediate depending on scale and requirements • Usually any concerns around networking foundation are immediate
have DX to your on-prem environment •Pre-mature buying of DX and related services without understanding • Limitations of the various DX options • AWS Account and VPC Strategy • Interactivity between on-prem and AWS workloads • Security and Infrastructure policies •Engage a proper partner who can advise you
cost centers, like in an Enterprise •You need to pre-empt and explain to your finance team how to handle a AWS bill and do cost attribution before they get really upset •Better for cost transparency than cost tag allocation
– Service Control Policies to enforce global policies, eg. Prevent disabling of Cloudtrail across all accounts • All Root Accounts and Admin accounts to be 2FA enabled • Apply baseline IAM policies through Cloudformation / Terraform and CI/CD Pipelines • Detective Controls • Enable AWS GuardDuty
VPCs Patterns • Build up a security model around individual resources to understand how to secure it • Detective & Remediative Controls • Automated AWS Config Rules, eg. Disable global unrestricted access to Port 22 • Enable AWS GuardDuty
root account emails into a single inbox to make sure no email is missed • Incidents / Deprecations / Outages • Setup and standardize alternate contacts
Pets or Cattle? •Automate everything – Terraform / CloudFormation through CI / CD pipeline •Prevent / avoid manual changes as much as possible to eliminate configuration draft
users on every account, eg. 100 accounts, 10 users each • Options • Use a landing zone account, and STS AssumeRole to other account’s IAM roles • What worked well for me in the past • AD -> Okta -> SAML Federation to every AWS Account • Okta was good for us to manage complexity with multiple services
a central account vs RIs in separate accounts • Capacity Reservation only holds if specific account and specific AZs • Resource & Charges Duplication • Same resources provisioned across multiple accounts • Might want to consolidate if you have the option • Eg. Multiple NAT Gateways across AWS Accounts - Considering using Proxy Instances • AWS POC Credits • Do not join a POC account to an existing Organisation, as credits can only be applied on the master billing account! Instead let the POC account be standalone for now so that you can apply the credits directly on it
glass yet • Eg. Cloudwatch (use something like Datadog to mitigate this) • Eg. Trusted Advisor • Might have to roll in your own and use third party • Some commercial tools can’t support or have punitive licenses for Multiple AWS Accounts
Instances • Wanted selection of reserved instances specifically not against certain accounts • https://aws.amazon.com/about-aws/whats-new/2017/11/customize-your- organizations-aws-credit-and-reserved-instance-ri-discount-sharing-using- new-billing-preferences/
It’s all about meeting your requirements as best • Evolving Architecture • Make the most important decisions first, eg. AWS Account Structure, VPC Segmentation • AWS is a very complex beast. Understand the fundamentals well • Be hands-on. Experiment and validate assumptions with hands-on • Be aware of soft and hard limits which can impact the overall architecture, eg. VPC Peering Limits, DX VIF • Enforce a naming strategy, document or keep an inventory of • AWS Accounts, VPCs
default • Secure globally using AWS Organisations SCP where possible • Automate AWS Account Configuration - Terraform / CloudFormation • Centralize Everything eg. AWS Systems Manager • Use SaaS/tools that can scale with multiple AWS Accounts (eg. Licensing, Automation) • Know the nature of AWS resources (eg. Account-Specific, AZ-Specific, Region-Specific, VPC-Specific) • Disable unused services / regions • Do not create any workloads on the organisation master account
stevepotayteo
oracle4engineer
kazuhitotakahashi
yoshidashingo
eijikominami
coincheck_recruit
salaboy
tkikuchi
kniino
kaminashi
minorun365
holman
shlominoach
yeseniaperezcruz
bluesmoon
destraynor
panda_program
eileencodes
mclloyd
brianwarren
brad_frost
philhawksworth
ddemaree
