accounts
This is currently a DRAFT!
Our ask of the cloud committee members (ccm) is that you work together as a team to validate and improve this document so that we can convert it from a draft to a proposal. First read this document start to finish for context. Then go back and find the checked items that look like:
- let's do this
and modify to one of the these:
-
let's do this
-
let's do it better this way
-
Dumbest idea ever
let's do this
- An account dedicated to a single human granted admin with a default $200 budget and 3 month life span. Account will be automatically terminated when budget or life span is exceeded.
Here are two possible made up ccm responses:
A:
- Not doing this!
An account dedicated to a single human granted admin with a default $200 budget and 3 month life span. Account will be automatically terminated when budget or life span is exceeded. - NOTE: Maybe not initially but could be useful. EG work with a contractor on short lived project, make a developer sandbox in the test org and discard at completion of project. Let's hibernate this idea and revisit in 2021.
B:
- Awesome idea! An account dedicated to a single human granted admin with an unlimited budget and infinite life span. Just seeing if you're paying attention!
ccm team lead deliverables:
- check all the check boxes (with amended content as needed) to provide minimal viable account strategy proposal
- List ordered top 10 most valuable things to do in the near future to establish our AWS account strategy. Explain their value. Think about opportunity cost, risk, etc.
- valuable thing 1 to do
- valuable thing 2 to do
- valuable thing 3 to do
- valuable thing 4 to do
- valuable thing 5 to do
- valuable thing 6 to do
- valuable thing 7 to do
- valuable thing 8 to do
- valuable thing 9 to do
- valuable thing 10 to do
- Present this improved account strategy document to the cloud strategy owners (SO).
Now that you've accepted your mission, here are some questions you should be asking as you crawl this document:
- Are the questions well defined? Improve them as needed.
- Are there any issues we've missed as it relates to AWS account strategy? Add them and suggest a good solution.
- Are the answers correct? Suggest improvements.
General insecurities:
- Are we asking the right questions?
- Do we use data to answer questions?
- What is our definition of done?
- How do we measure the quality of our proposed account standard? Some starter fuzzy metrics could be: Does our account standard create an environment we enjoy using? Does it provide value to our organization? Suggest your own better measurable metrics.
No pressure! Happy hunting.
- to deliver secure, cost effective, efficient, useful products
- We will use a devsecops shared responsibility model
A useful service or application
A product team is a group of people that support a product owned by a product owner.
- We've got a plan for that here
- We've got a plan for that here
- Well architected products require a move away from manual operation to automation which will require a change in the way we operate. This is the way
NOTE this won't happen overnight but it's a set of habits we should adopt over time. Sooner rather than later.
Will we have an account strategy?
Yes! as detailed in this document.
TBD
- With no sense of humor using this
TBD
TBD
Cloud Committee or CCOE
Will our account strategy be consistent with Well architected framework?
Yes
Will this document be consistent with our Cloud Strategy Document?
Yes
- To create ordered, reusable, governed, secure, cost effective and efficient deployment of resources that create useful products. The alternative leads to poor hygiene.
Will we use a single AWS Account?
- Surely you must be joking.
- Yes!
- limit complexity within each account
- provide separation of duties
- provide separation of applications, products and functions
- provide easy cost per application/products/functions
- provide applications/products/functions inventory
- portability of applications/products/functions
- application/product/function independence
- ease of application/product/function retirement
Three types of accounts will be used to support product teams:
- Each product has a dedicated product (aka prod, production) account
- A product can only run in a dedicated product account
- There can be flexibility in where product teams run their pre-production endpoints, eg one team might want to deploy UAT/QA/STAGE versions of a product in a product account to most closely simulate "production", others might prefer to run these psuedo production versions in their dev or test account.
- Core shared services accounts will host core services (maintained by cloud services teams) that support product teams/groups and their products. The core services are Organization, Logging, Network, Shared Services and Security, see below for details of what each core product type does.
- The product team that maintains the core services that support our organization.
- An account maintained by the cloud services team and dedicated to the aggregation of logs and meta data from every account in the org. It may be used as the data source to provide insight to security, operational or product teams.
- Cloud services team must provide visibility into logs. How? Dunno. We should test drive a service like splunk or datadog to gain operational and security insight.
- We should provide an easy audit feature using our stored archive logs
- global audit trail organization cloudtrail
- global configuration state config aggregator
TBD other logs from cloudwatch, app, s3, load balancer, waf, etc
- An account maintained by the cloud services team and dedicated to network support services for accounts in the Org
- Connect Virtual Private Clouds (VPCs) and on-premises networks to a single transit gateway
- Dedicated network connection from our data centers to AWS with direct connect
- Configure and manage firewall rules across our accounts and applications with firewall manager
- Central delegated route 53 root level hosted zones
- An account maintained by the cloud services team and dedicated to the control and governance of all accounts in the org.
- An account maintained by the cloud services team and dedicated to the security of all accounts in the org.
- Continuously monitor for malicious activity and unauthorized behavior to protect our AWS accounts and workloads with guard duty
- Analyze, investigate, and quickly identify root causes of potential security issues or suspicious activities with detective
- TBD machine learning to automatically discover, classify, and protect sensitive data in AWS macie
- Comprehensive view of our security state in AWS with security hub aggregation
- An account maintained by the cloud services team and dedicated to providing supporting services to other accounts in the org
- securely control access to AWS resources with IAM
- AD
- view and control virtual machines with Systems Manager
- centrally manage access to multiple AWS accounts and business applications and provide users with single sign-on access to all their assigned accounts and applications from one place with SSO
- maintain consistent tags with tag policies
- manage and automate tasks on large numbers of resources at one time with resource groups
- view and manage our quotas from a central location with service quotas
- manage catalogs of IT services approved for use on AWS with service catalog
- share AWS resources within our AWS Organization with resource access manager
- The cloud services team and CCOE will determine the optimal distribution of core services to provide value to products, product owners and product teams. **NOTE the distribution and allocation of core services could be split into more refined accounts, eg maybe IAM/SSO/AD are grouped in one account dedicated to iam type services while systems manager and resource groups are in another account as they relate to ec2.
- Yes! We have a plan for that here
- We've got a plan for that here
- product teams can request 1 development account with a name teamnameDev.
- non development accounts are created as needed by the cloud services team in response to requests for services, eg deploy a test or production version of a product.
- New accounts shall be requested through this form.
Requests for accounts must include
- Billing limit exception (defaults: dev $150/month, build $100/month, test $150/month, product $1000/month but less is better!)
- Support level exception (defaults: dev $100/month biz level, build none, test none, product none
- Account contacts
- Team Name
Requests for Development Team accounts must also include
- Environment (dev/build/test) as needed
Requests for product accounts must also include
- Product Name
- Product Owner
Typical types and sequence of events that lead to account requests:
- Product team needs an account for development work on their products
- Product team needs shared build/test services accounts to create pre-production versions of their products
- Product team needs an account to host a product
accounts are generally named after the team or product and environment, eg:
- acmeLogs could be the alias for the account that the acme team uses to host logging function
- incrediblesDev could be the dev account for the incredibles team
- killerApp could be the account for the killer app product.
NOTE: we can create alias for accounts but we may want to abstract our account names from AWS alias, eg you probably can't create an account with alias "logs" and may have to give it a uniq name like acmeLogs.
Team shared environments are build, dev and test and should have these as postfix. Product owners should choose Product and Team names with a preference for brevity.
- Root owner - name and email, alias is best
- Billing- name and email, alias is best
- Operations - name and email, alias is best
- Security - name and email, alias is best
- Team owner - name and email, alias is best
- (For product accounts) Product owner - name and email, alias is best
- TBD, please determine
Accounts come with certain default configurations
- ACM should be used as needed to create certificates for use with AWS infrastructure (eg load balancers)
- wild card ACM certificates for anything.$accountname.$roothostedzone are for convenience to allow product teams to create non production endpoints without having to allocate certificates for each application environment prior to production. Product certs must have a valid cert for $product.fqdn
- The cloud services team manages root level hosted zones in a central AWS network account.
- The cloud services team will allocate delegated hosted zones of the form $accountname.$roothostedzone.
- The central hosted zone is responsible for managing the propagation of NS records for $accountname.$roothostedzone
Useful tags should be deployed, cf tagging strategy Consider the use of a namespace if you have a tag standard you want, eg mytags: so that you can isolate mytags from yourtags.
Minimum account level tagging requirement:
- Team
WARNING: team ownership of accounts is mandatory and non negotiable, we do not support orphaned accounts with no team ownership
- Cost containment is a shared responsibility and therefore everyone's concern.
- Look at the Billing and think about how to reduce cost.
- Create a billing alert that notifies account product owners when they're likely to overspend.
- Tags should be in place to evaluate cost per product, team, env, etc.
- Set a budget and know what you're spending!
- Cloudtrail must be enabled in all regions and shipped with checksums to a central S3 audit bucket.
- Security is a shared responsibility and therefore everyone's concern. Account tenants should consult these services and see what they have to say about the accounts you use.
- Security Hub in a core security account.
- Guard Duty in a core security account.
- Detective (preview) in a core security account.
- Consult Trusted Advisor. This is where you can see service limits. Ops should have a global view of service limits and capacity. Devs should know their service limits.
- Trusted Advisor does more at higher support levels. What is the value of trusted advisor at higher support levels?
TBD, would like to see self service of service limit with some approval process.
- Our default support allocation for accounts is TBD. Please determine. NOTE: Support is like voting - use Support early and often. There is a significant cost to useful support (business level) so consider the value it brings to an account. Generally dev accounts are the place where support is most useful. Support can be turned on a la carte in an emergency provided we have an efficient root access mechanism. Alternatively we should consider enterprise support to have a uniform support model. This should be a data driven decision instead of fud driven decision.
We have used AWS for 3 years as of 12/2019.