accounts
- to deliver secure, cost effective, efficient, reliable and useful products
How do we use AWS Accounts to deliver secure, cost effective, efficient, reliable and useful products?
- Through automation using 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.
- Be nice to them, they can make your bacon.
- 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 automation using something like 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
Will are cloud strategy be consistent with Control Tower?
- Yes by adopting the use of Control Tower ASAP
- To create ordered, reusable, governed, secure, cost effective, reliable and efficient deployment of resources that create useful products. The alternative leads to poor hygiene.
Will we use a single AWS Account?
- No
- Yes
- limit complexity for each product team
- provide separation of product teams
- provide easy cost per product team
- NO
- NO
- NO
- NO
- > One type of account will be used to support product team's development efforts: non-production aka sandbox, poc, dev, test
- Each product team has a dedicated product account (aka prod, production)
- Products 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.
- NO! Accounts are single payer, we will not support recharge to more than one payment stream for an 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 service provides.
- The teams that maintain the core AWS services that support our organization.
- Be nice to them, they can save your bacon.
- Yes
An account maintained by the cloud services teams 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.
- 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 teams 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
- Yes
An account maintained by the cloud services teams and dedicated to the control and governance of all accounts in the org.
- master payer
- billing service
- The fewer service running in master organization account the better
- Yes
An account maintained by the cloud services teams and dedicated to the security of all accounts in the org.
- Securely control access to AWS resources with IAM
- 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
[ ] TBD
An account maintained by the cloud services teams and dedicated to providing supporting services for other accounts in the org.
-
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 teams and Cloud Committee/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
- product teams can request 1 development account with a name teamnameDev.
- non development accounts are created as needed by the cloud services teams in response to requests for services, eg deploy a test or production version of a product.
- New accounts shall be requested through this form.
- A budget
- Support level
- Account contacts
- Team Name
- Product Name
- Product Owner
accounts are 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.
- Team environments are Build, Dev and Test and should be limited to these as the postfix to their account name/alias.
- Product owners should choose Product and Team names with a preference for brevity.
NOTE: account name and account alias should be the same
- 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 define
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 back to $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.
- Operations has a strong preference for business level support on any product account
- Architecture encourages that support cases be created prior to production
- We will evaluate use of support as compared to cost. We may choose to remove support where it isn't useful if the risk of the additional overhead of changing support level in an account is acceptable (you need root to change support level)
- Cloud services and product teams will collaborate to determine the appropriate support level for each account. 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.