Search

Please follow the naming convention bellow to help consistent provisioning of AWS resources.

ItemFormatting Style
Determined by Construct{{construct_name}}
Entered by User

{{item_name}}

Optional Text based on use[[naming]]
To be Included "AS IS"wording


For Updates to items already present, please use the inline-comment feature. For new additions which are not below, use the page comments (which will be deleted when resolved).




  1. Dashes are required as entered, do not remove them
  2. Spaces are left for legibility reasons around dashes, they are not to be included in the name
  3. Delimiters are not to be substituted into areas which are components of the name. Where clarity is needed for a veryLongName use modifiedCamelCase

If you need to deviate from standards, please contact your team architect. It will get added to the standard as appropriate (e.g. "search" for a tier type)

Naming Constructs

AWS Resource

Resource Name

Comment

Example

Account Naming Construct

{{teamName}} - {{environment}} - {{context}}

teamName should be the name of the application team providing support

  • atsea
  • dms

Environment should be one of:

  • prod
  • dev

Context should be one of:

  • standard

  • level4 (for Level 4 specific accounts)

  • bcdr (only for bcdr exclusive accounts)

admints-dev-standard

admints-prod-standard

admints-prod-level4

App Naming Construct

{{appName}} - {{environment}} [[number]]-[[region]]-{{scope}}[[number]]

Environment should be one of:

  • prod
  • int
  • uat
  • stage
  • test
  • dev
  • blue
  • green

Scope should be used if necessary and can reflect components of an application

  • auth
  • solr
  • app

  • web

  • cache

  • master

  • worker

  • nfs

If multiple are needed, increment number.

Region is optional and should be used when necessary (e.g. BC/DR)

takeasweater-dev

takeasweater-stage

takeasweater-test

takeasweater-prod

ask-prod-auth

coursecatalog-prod-solr1

AWS Resource Naming Standards

CloudFormation Naming Standards

AWS Resource

Resource Name

Comment

Example

CloudFormation Stack

If this stack is universal and not application specific:

{{account_naming_construct}}  - {{stack_group}} - cf


If this stack is application specific:

{{appname_construct}} - {{stack_group}} - cf

stack_group should be one of:

  • ALL - includes all stack types

  • VPC - All VPC resources

  • NAT - NAT servers for the VPC

  • SG - Security Groups

  • IAM - IAM roles used instances and CodeDeploy

  • ELB - Elastic Load Balancer

  • ASGLC - AutoScaling Group and Launch Configuration

  • CW - CloudWatch monitoring

  • RDS - Databases, options groups, parameter groups

  • RDSREPLICA - Replica/slave database instances
  • S3 - S3 buckets

  • CONFIG - Config Rules

admints-prod-level4-vpc-cf

or

takeasweater-prod-all-cf

or

takeasweater-prod-iam-cf

CloudFormation ChangeSet

If this stack is universal and not application specific:

{{account_naming_construct}}  - {{dateGenerated}} - cset


If this stack is application specific:

{{appname_construct}} - {{dateGenerated}} - cset

Date Generated should follow:

YYYYMMDDHHMM

Any additional information about the change set should be included in the description of the changeset

admints-prod-level4-201704201100-cset

or

takeasweater-prod-201704201100-cset

AWS Account Items

AWS Resource

Resource Name

Comment

Example

AWS Account Name

{{account_naming_construct}}

Not all P-env’s require a separate account

admints-dev-standard

admints-prod-level4

AWS Account Emailhuit-cloudops-awsaccounts + {{teamName}} - {{environment}} @calists.harvard.edu

Environment should be one of:

  • P = prod
  • P-1 = stage
  • P-2 = test
  • P-3 = dev

    Not all P-env’s require a separate account

huit-cloudops-awsaccounts+admints-dev@calists.harvard.edu

If account naming conflicts exist, such as a single group owns a standard account as well as a level4 account, abbreviate {{context}} to make a clear differentiation. e.g. admints-prod and admints-prod-l4

There is a 64 character limit on the AWS Account Email Address form input


VPC Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

VPCs

{{account_naming_construct}} - vpc 

  • level4 

    • for Level 4 VPC’s inside non-l4 specific accounts

  • bcdr 

    • only for bcdr exclusive accounts

admints-dev-standard-vpc

admints-stage-standard-vpc

admints-prod-standard-vpc

admints-prod-level4-vpc

admints-prod-bcdr-vpc


Subnets

{{account_name_construct}} - {{subnetType}} - {{routeType}} - {{az}} {{number}}

Subnet Type should be one of:

  • app

  • elb

  • db

  • cache

  • nat

  • web

  • data

Number:

  • Starts at 1, only increments if we have outgrown that AZ’s subnet

admints-dev-standard-app-private-1a-1

admints-stage-standard-elb-public-1b-1

admints-prod-standard-db-private-1c-1

admints-prod-level4-web-private-1d-1

VPC Peering Link{{account_naming_construct_of_target}} - {{scope_of_target}} - vpc-peerlinkThe items to be written should be that of the remote end of the VPC Peering Link

Example link between admints and sharedservices

  • admints-prod-standard-vpc-peerlink
  • sharedservices-prod-standard-vpc-peerlink


Route Tables{{account_naming_construct}} - {{routeType}} - rt  [[ zone]]  

Route type is one of the following:

  • public
  • private

If the route table is distinct for each AZ (e.g. you are routing to different NATs), you must add the following Zone

Zone should be #l (e.g 1a, 1b, 1c, 1d, 1e)

admints-dev-standard-private-rt-1a

admints-dev-standard-public-rt

DHCP Option Sets{{account_naming_construct}} - dhcpoptionsPlease Reference VPC Setup: DHCP Option Sets Required Settings

admints-dev-standard-dhcpoptions

Network ACL{{account_naming_construct}} {{naclType}} nacl

NACL Types should reference why they exist (dnsout, etc)

Please note that these are not required and not great to use

admints-dev-dnsout-nacl
Virtual Private Gateway{{account_naming_construct}} - {{scope}} - vgw 

Scope should be one of (only if colocated in a "standard" account)

  • level4 

    • for Level 4 VPC’s inside non-l4 specific accounts

  • bcdr 

    • only for bcdr exclusive accounts


This should match the VPC naming


EC2 Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

Elastic Load Balancer

{{appname_construct}} - elb

All new ELBs should be internal


takeasweater-dev-elb

takeasweater-stage-web-elb

takeasweater-prod-web1-elb


Launch Configuration

{{appname_construct}} - {{dateGenerated}} - lc


dateGenerated only required if manually created

Date should be in the form:

YYYYMMDDHHMM

Hours should be in 24 hour format


car-prod-web-201511041708-lc

maximo-dev-nfs-201511091000-lc

fastcat-prod-app-lc

coursecatalog-prod-app-lc

AutoScaling

{{appname_construct}} - asg


takeasweater-prod-app-asg

takeasweater-prod-asg

Security Groups

{{appname_construct}}[[number]] - {{resource_name}} - sg


Account level Security Group resources:

{{account_naming_construct}}[[number]] - {{account_level_resource_name}} - sg

Resource Name can be one of:

  • elb

  • efs
  • nfs
  • instance
  • db
  • mgmt 

    • for bastion and direct Harvard management access only

If multiple are needed, increment number.

Account level resource name:

  • nat

takeasweater-dev-elb-sg

takeasweater-prod-web-mgmt-sg

takeasweater-prod-web01-instance-sg

takeasweater-prod-web02-instance-sg

Instances

{{appname_construct}} [[-  ec2asg]] 


 Account level instance resources:

{{account_naming_construct}} - {{account_level_instance_scope}} [[-  ec2asg]] 

If generated by an Autoscaling Group add "-ec2asg"

Account level Instance Scope:

  • nat

takeasweater-dev-app

takeasweater-prod-cache

takeasweater-prod-web-ec2asg

AMIs{{appname_construct}} - ami


nagiosxi-prod-master-ami

SSH Pem Keys

{{account_naming_construct}} {{appname_construct}} - {{dateGenerated}}

Date should be in the form:

YYYYMMDD

.pem will be added by AWS on download

admints-dev-standard-takeasweater-dev-web-20151102.pem

S3 Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

S3 Buckets{{teamName}} - {{environment}} - {{scope}} - bucket

Environment should be one of:

  • P = prod
  • P-1 = stage
  • P-2 = test
  • P-3 = dev

Scope can be one or the following

  • elblogs

admints-dev-bucket

admints-dev-elblogs-bucket

Lambda Function Naming Standard

AWS Resource

Resource Name

Comment

Example

Lambda Function

{{appname_construct}} - {{function_scope}} - lambda-function


 Account level function resources:

{{account_naming_construct}} {{function_scope}} - lambda-function

Function scope should be one of the following:

  • autodeploy
  • cfoutputs

takeasweater-prod-autodeploy-lambda-function


campussvcs-prod-standard-cfoutputs-lambda-function

RDS Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

RDS (DB Instance Name)

{{appname_construct}} - {{db_type}} - {{deployment_type}}

DB Type is one of the following:

  • oracle
  • mysql
  • postgres
  • maria
  • aurora

Deployment Type is one of the following:

  • multiaz
  • standalone
  • slave
    • Used when making Read Slaves in RDS



takeasweater-prod-oracle-standalone

takeasweater-prod-mysql-multiaz

takeasweater-prod-aurora-slave

RDS (Subnet Group)

{{appname_construct}} - {{db_type}} - {{deployment_type}} - subnetgroup

DB Type is one of the following:

  • oracle
  • mysql
  • postgres
  • maria
  • aurora

Deployment Type is one of the following:

  • multiaz
  • standalone
  • slave
    • Used when making Read Slaves in RDS



takeasweater-prod-oracle-standalone-subnetgroup

takeasweater-prod-mysql-multiaz-subnetgroup

takeasweater-prod-aurora-slave-subnetgroup

RDS (Option Group)

{{appname_construct}} - {{db_type}} - {{deployment_type}} - optiongroup

DB Type is one of the following:

  • oracle
  • mysql
  • postgres
  • maria
  • aurora

Deployment Type is one of the following:

  • multiaz
  • standalone
  • slave
    • Used when making Read Slaves in RDS



takeasweater-prod-oracle-standalone-optiongroup

takeasweater-prod-mysql-multiaz-optiongroup

takeasweater-prod-aurora-slave-optiongroup

RDS (Parameter Group)

{{appname_construct}} - {{db_type}} - {{deployment_type}} - paramgroup

DB Type is one of the following:

  • oracle
  • mysql
  • postgres
  • maria
  • aurora

Deployment Type is one of the following:

  • multiaz
  • standalone
  • slave
    • Used when making Read Slaves in RDS



takeasweater-prod-oracle-standalone-paramgroup

takeasweater-prod-mysql-multiaz-paramgroup

takeasweater-prod-aurora-slave-paramgroup


Elasticache Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

ElastiCache{{appname_construct}} - {{cache_type}} - {{deployment_type}}

Cache Type is one of the following:

  • memcached
  • redis

Deployment Type is one of the following:

  • multiaz
  • standalone
  • slave
    • Used when making Redis Read Slaves in RDS

takeasweater-prod-memcached-standalone

takeasweater-prod-redis-multiaz

takeasweater-prod-redis-slave


CodeDeploy Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

Code Deploy Deployment Group

{{appname_construct}} - {{scope}} - dg

Scope Can be one of the following:

  • app

  • web

  • cache

takeasweater-prod-app-dg

takeasweater-dev-web-dg

IAM Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

IAM User

Administrators:

first_last

Service Accounts:

service_name

IAM user names should mirror the users @harvard.edu email address



robert_ruma

thomas_vachon

cloud_endure

IAM Group

{{appname_construct}} - {{group_purpose}} -  iam - group


Note: There will be a standard naming structure for account level group resources:

{{account_naming_construct}} - {{group_purpose}} - {{access_level}} -  iam - group

Application group purpose can be one of the following:

  • readonly
  • poweruser
  • administrator


Account level group purpose can be one of the following:

  • forcemfa
  • cloudendure
  • administrator

Option account level group access can be one of the following:

  • administrator
  • poweruser
  • readonly
  • isolated-by-tag


takeasweater-prod-readonly-iam-group

takeasweater-dev-administrator-iam-group




admints-dev-standard-forcemfa-iam-group

IAM Role (via SAML)

{{account_naming_construct}} saml - {{group_purpose}} -  iam - role@us-east-1


Note: There will be a standard naming structure for app level roles resources:

{{appname_construct}} saml - {{group_purpose}} -  iam - role@us-east-1

Account group purpose can be one of the following:

  • admin
  • poweruser
  • readonly
  • (More can be added as required)


Account level group purpose can be one of the following:

  • fullaccess
  • readonly


cloudhacks-dev-standard-saml-admin-iam-role@us-east-1





takeasweater-prod-saml-readonly-iam-role@us-east-1


IAM Roles{{appname_construct}} - {{role_purpose}} -  iam - role

Role Purpose can be one of the following:

  • autodeploy
  • s3access
  • securitymonkey
  • datapipeline
  • ebssnapshot
  • lambdaexecute




takeasweater-prod-autodeploy-iam-role

takeasweater-dev-s3access-iam-role

Instance Role{{appname_construct}} - {{role_type}} -  iam - ec2role

Role Purpose can be one of the following:

  • app

  • web

  • cache

  • master

  • worker

  • nfs


takeasweater-prod-app-iam-ec2role

takeasweater-dev-cache-iam-ec2role

IAM Policy

{{appname_construct}} - {{product_used}} -  {{level_of_access}} - iam - policy



 

Note: There will be a standard naming structure for account level policy resources:

 

{{account_naming_construct}} - {{product_used}} -  {{level_of_access}} -  iam - policy


Product Used must be one of the AWS product names such as:

  • ec2
  • s3
  • lambda
  • codedeploy
  • sqs

Account level product names can be one of the following:

  • securitymonkey
  • osaccounts
  • cloudendure
  • cfoutputs

Level of Access must be one of the following:

  • readonly
  • readwrite
  • isolated-by-tag
takeasweater-prod-s3-readwrite-iam-policy

takeasweater-dev-codedeploy-readonly-iam-policy





Note: Instance profiles are a collection of policies added to a role

KMS

{{appname_construct}} {{scope}} {{type}} - kms

Context should be one of:

  • standard

  • level4 (for Level 4 Data)

  • bcdr (only for bcdr exclusive accounts)


Type should be one of:

  • ebs
  • rds
  • snowball
  • s3
  • redshift
  • codecommit
  • cloudtrail
  • elastictranscoder
  • ses


takeasweater-dev-standard-rds-kms

takeasweater-prod-standard-ebs-kms

 SSL Certificates (for ELB or Cloudfront)


{{appname_construct}} - {{product_used}} {{certificate_type}} - {{certificate_expiry}} - sslcert


These items are treated internally as IAM resources and therefore must be named appropriately

Product Used must be one of the following AWS product names:

  • elb
  • cloudfront

Certificate Type should be one of the following:

  • domain
  • wildcard
  • san


Certificate Expiry should be in the format "YYYYMM"


takeasweater-dev-elb-domain-201601-sslcert

takeasweater-prod-cloudfront-wildcard-201601-sslcert


Cloudwatch Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

CloudWatch Alarm{{appname_construct}} - {{instance_id}} - {{alarm_product}} - {{alarm_metric}} - {{check_status}} - cw-alarm

Alarm Product Should be one of the following (lowercased):

  • elb
  • asg
  • rds
  • billing
  • ebs
  • lambda
  • s3
  • sns
  • linuxsystem (instance_id must be used)

Alarm Metric should match the metric name in lowercase dashed style such as:

  • http-4xx
  • http-5xx
  • volume-queue-length
  • cpu
  • memory
  • swap
  • diskspace

Check Status should be one of:

  • high
  • low


takeasweater-prod-elb-http-4xx-high-cw-alarm

takeasweater-prod-rds-max-connections-high-cw-alarm


SNS Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

SNS Topic{{appname_construct}} - {{topic_name}} - {{topic_subscription_type}} sns-topic

Topic name should be a lowercased name for the topic

Topic Subscription Type should be one of the following:

  • email
  • http
  • sqs
  • sms
  • application
  • lambda


takeasweater-prod-elbcw-email-sns-topic

takeasweater-prod-codedeploy-lambda-sns-topic



SQS Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

SQS Queue{{appname_construct}} - {{queue_name}} sqs-queueThe Queue name should be a lowercased name for the queuetakeasweater-prod-myqueuename-sqs-queue


CloudOps Tool Naming Standards

Package Names for CAR 

TypeFormatExampleKnown Standards Reference
RPM

hcdo - {{ package context }}

Version and architecture are added in the Jenkins build

hcdo-ansible-role-apache

hcdo-ansible-role-postfix

hcdo-ansible-role-splunk

hcdo-splunk-certs

hcdo-cloud-os-accounts

https://fedoraproject.org/wiki/Packaging:NamingGuidelines
DEB



Splunk Index Naming

FormatCommentExample

cloud - {{ teamName }} - {{ environment }}

Optional for level4 isolation:

cloud - {{ teamName }} - {{ inner-group }} - {{ environment }}



Environment should be one of:

  • prod
  • uat
  • stage
  • test
  • dev

Values should be lowercase, no spaces

Already created indexes:

cloud-acts-dev

cloud-acts-prod

cloud-admints-dev

cloud-admints-test

cloud-admints-uat

cloud-admints-prod

cloud-campusservices-dev

cloud-campusservices-prod

cloud-cloudops-dev

cloud-cloudops-prod

cloud-lts-dev

cloud-lts-prod

cloud-sharedservices-dev

cloud-sharedservices-prod

Optional for level4:

cloud-admints-researchadmin-prod

cloud-admints-researchadmin-dev




Git Repository

TypeFormatCommentExample
Automation Code Repositories

hcdo - {{ code context }} - {{ resource name }}


Code context should be one of the following:

  • ansible-role
  • cloudformation


This name should mirror any associated CAR package


Resource name should be the name of the resource the automation code manages.


hcdo-ansible-role-apache

hcdo-ansible-role-postfix

hcdo-ansible-role-splunk

hcdo-cloudformation-rds


Tools Repositorieshcdo - {{ tool name }}

Tool name is specific to the function of the tool.

It should reflect a meaningful name.


This name should mirror any associated CAR package

hcdo-splunk-certs

hcdo-cloud-os-accounts

Application Repositorieshcdo - applications - {{teamName}} - {{appName}}

teamName should be the application team name providing support

appName should be the application name without the environment

hcdo-applications-admints-gmas
Feature Branchfeature/CLOPS-xxx_short_descriptionCLOPS-xxx should be the JIRA Story or task used to track progressfeature/CLOPS-2713_adding_environment_tag
Bugfix Branchbugfix/CLOPS-xxx_short_descriptionCLOPS-xxx should be the JIRA Story or task used to track progressbugfix/CLOPS-2713_fix_race_condition

DynamoDB Tables

FormatCommentExample
 {{appname_construct}} - {{ context }}

Context may be arbitrary but reflects the use of the table


 pidash-dev-osaccounts

 pidash-prod-osaccounts

CloudWatch Log Groups

FormatCommentExample

{{appname_construct}} - {{ source }} - {{ context }} 


Source should be one of the following (the AWS service the CloudWatch Log is configured with):

  • lambda
  • vpc

Context may be arbitrary but reflects the context of the use of the log

vpc-flowlog

lambda-dev-autodeploy

lambda-prod-autodeploy

pidash-dev-lambda-deleteebssnapshot

pidash-prod-solr-lambda-deleteebssnapshot

pidasht-dev-lambda-ebssnapsho

pidash-prod-lambda-ebssnapshot

Elastic File System

FormatCommentExample
 {{appname_construct}} - efs

Context may be arbitrary but reflects the purpose of the storage


 github-prod-backup-efs

maximo-test-efs

Ansible Tower

TypeFormatCommentExample
Projects (Generic role)

{{ organization }} - ansible - role - {{ name }} - {{ environment }}

Organization is the Tower organization the resource is a member of

Name should be a unique identifying term related to the technology in use and closely related to the SCM repository name containing the code

Environment refers to the software deployment environment and may be one of:

  • dev
  • test
  • stage
  • prod

The directory layout should follow Ansible best practices

huit-ansible-role-carbonblack-prod

huit-ansible-role-rhn-prod

Projects (Application specific)

{{ organization }} - ansible - {{ scope }} - {{ appname_construct }}

Organization is the Tower organization the resource is a member of

Appname construct should be closely related to the SCM repository name containing the code

Scope is optional and should be used to add context to the function of the project and may be one of:

  • infra
  • deploy
  • role
  • playbook

The directory layout should follow Ansible best practices

huit-ansible-deploy-coursecatalog-prod-solr1

huit-ansible-ask-prod-auth

Inventories (Cloud){{ account_naming_construct }}

Applies to Amazon EC2 sourced inventories

acts-dev-standard

acts-prod-standard

ebs-prod-level4

Inventories (On-prem)

onprem - {{ teamName }} - {{ environment }} - hosts

teamName should be the organizational team providing operational support

Environment refers to the software deployment environment and may be one of:

  • dev
  • test
  • stage
  • prod

*Subject to change

onprem-its-csi-dev-hosts
Job Templates{{ inventory_name }} - {{ template_function }} - {{ environment }}

Inventory name is the name of the inventory used in the template configuration

Template function should be a meaningful name describing the functionality of the template

Environment refers to the software deployment environment and may be one of:

  • dev
  • test
  • stage
  • prod

atsea-dev-standard-deploy-account-sshkey-prod

atsea-dev-standard-scan-template-prod

Workflow Job Templates{{ function }} - {{ environment }}

Function should be a meaningful name describing the functionality of the template

Environment refers to the software deployment environment and may be one of:

  • dev
  • test
  • stage
  • prod

all-aws-accounts-deploy-account-sshkey-prod

all-aws-accounts-scan-template-prod

API User Accounts (Generic){{ organization }} _ {{ function }} _ api _ {{ access_permission }}

Organization is the Tower organization the resource is a member of

Function is optional and is a meaningful name describing the functionality os the API user

Access permission must be one of the following:

  • ro
  • rw

huit_api_ro

huit_api_rw

huit_billing_api_ro

API User Accounts (Inventory specific){{ inventory_name }} _ api _ {{ access_permission }}

Inventory name is the name of the inventory the user will have access from

Access permission must be one of the following:

  • ro
  • rw

cloudhacks_dev_standard_api_rw

sharedsvcs_prd_standard_api_rw

Page History

Version Published Changed By Comment
CURRENT (v. 33) Aug 22, 2018 07:49
v. 32 Aug 22, 2018 07:48
v. 31 Mar 29, 2018 10:18
v. 30 Feb 12, 2018 14:10
v. 29 Feb 09, 2018 14:25
v. 28 Feb 09, 2018 14:02
v. 27 Feb 09, 2018 13:59
v. 26 Feb 09, 2018 13:59
v. 25 Feb 09, 2018 13:57
v. 24 Feb 09, 2018 11:36
v. 23 Feb 08, 2018 08:34
v. 22 Feb 08, 2018 08:19
v. 21 Feb 08, 2018 08:18
v. 20 Feb 08, 2018 08:00
v. 19 Feb 08, 2018 07:59
v. 18 Feb 08, 2018 07:58
v. 17 Nov 01, 2017 08:54
v. 16 Nov 01, 2017 07:52
v. 15 Oct 31, 2017 14:59
v. 14 Oct 31, 2017 14:05
v. 13 Oct 31, 2017 12:56
v. 12 Oct 31, 2017 12:04
v. 11 Jun 06, 2017 11:25
v. 10 Jun 03, 2017 12:31
v. 9 Apr 20, 2017 11:24
v. 8 Oct 19, 2016 09:14
v. 7 Sep 28, 2016 21:00
v. 6 Sep 28, 2016 20:49
v. 5 Sep 28, 2016 20:41
v. 4 Sep 28, 2016 13:58
v. 3 Sep 27, 2016 11:15
v. 2 Aug 25, 2016 17:44 Added isolated-by-tag for the policy where access is limited by tags
v. 1 Aug 11, 2016 13:31

9 Comments

  1. It would be good to add color/version to the account naming construct. For example the blue production environment or dev environment 2. Added blue/green environment values to app name construct. Validation needed

  2. Allow Naming Standards to be more easily searchable. Done

  3. Add a Page History section that includes a version number but this feature does not allow for a draft to be edited by multiple individuals and supply platform for a discussion, consensus and release. Done

  4. Should a report or an additional statement be added to the Cloud Health tagging report to ensure resources are named according to the Cloud Naming standards? Acceptance of work needed, External effort needed, Validation needed

  5. Should naming standards be required? Open discussion

    • Initial reactions suggest they should not be required. However, they should be for HUIT partners that use HUIT services.
    • If an Organization already has a naming standard, should they be encouraged to switch to the HUIT standards?
      • No if the Organization's standards are established and have internal dependencies.
  6. Draft adoption document: "Why should you use naming standards" Open discussion

    1. How can we invoke adoption of naming standards?

      Benefits:

      • Avoid naming collisions
      • Allow established services to be automated
      • Security naming in cloud shield
      • Monitoring reusability
      • Grouper services
      • Multi cloud vendor resource naming
  7. I see that "color" like blue has been added to the app naming construct.  I wonder if that is the best place.  Is it possible to express PROD-BLUE and PROD-GREEN?