Skip to content

Instantly share code, notes, and snippets.

@lktslionel

lktslionel/naming-conventions-aws-ssm.md

Last active November 12, 2025 14:49
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save lktslionel/3037a245d35ee9b62dd52c8bade310ac to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save lktslionel/3037a245d35ee9b62dd52c8bade310ac to your computer and use it in GitHub Desktop.
Download ZIP
Naming Convention for AWS SSM Parameter Store
Raw
naming-conventions-aws-ssm.md

Moi je partirait sur quelque chose du style: <namespace>/[<context>]/<component>/<module>/<item-path>/<item-property>

Si on part sur ça, ça signifierait qu'on ait par correspondance:

  • namespace: saws
  • context: shared | common | xxxxx
  • component: network
  • item-path: ${VpcName}-${Stage}/subnet/${SubnetName}-a
  • item-property : id

les elements item-path, item-property semblent pas mal mais les autres ont un soucis de cohérence. Je m'explique:

  • saws comme service, signifie que le service est partagé par tous. Mais, dans CAP, notre code service/appli est saws; je mettrais donc saws à la place de default-socle.

  • common comme namespace signifie que ce paramètre est partagé entre tous les comptes, tous les services, tous les composants, tous les modules, et potentiellement tous les items; ça passe.

  • network: comme component signifie qu'il est partagé par tous et c'est le cas. De plus, nous n'avons pas encore fini l'inventaire de tous les services que notre équipe apporte mais je pense qu'un service de connectivité sera essentiel. On peut l'appeler network ou networking, ça passe!

  • ${VpcName}-${Stage} comme module est peut descriptif je pense. on devrait faire comme avec subnet/ et renseigner plutôt vpc/${VpcName}-${Stage}

En somme, voici 2 possibilités de chemin SSM:

  • common/saws/networking/vpc/${VpcName}-${Stage}/subnet/${SubnetName}-a/id
  • common/saws/network/vpc/${VpcName}-${Stage}/subnet/${SubnetName}-a/id
@lktslionel
Copy link
Author

lktslionel commented Jul 13, 2023

As adjectives the difference between shared and common is that shared is used by multiple entities or for multiple purposes or in multiple ways while common is mutual; shared by more than one.

@lktslionel
Copy link
Author

lktslionel commented Aug 8, 2023 •
edited
Loading

Ref: https://learn.microsoft.com/en-us/powershell/dsc/reference/schemas/definitions/resourcetype?view=dsc-3.0

<owner>[.<group>][.<area>]/<name>

Type name segments

Owner

The owner segment of the type name is mandatory. It identifies the person or organization that owns, develops and maintains the resource.

Group

The group segment of the type name is optional. It defines a logical grouping for a collection of resources. For example, resources that manage SQL Server might use the SqlServer group in their type name.

Area

The area segment of the type name is optional. It defines a grouping for a collection of resources by purpose or higher-level component. For example, resources that manage components of a SQL Server database might use the Database area in their type name.

Name

The name segment of the type name is mandatory. It identifies the component that the resource manages. This segment should be a singular noun unless the resource always manages a list of components in a single resource instance. In that case, the resource name should be the plural form of the noun it manages or the singular form of the noun followed by the word List, like JeaRoleCapabilities or JeaRoleCapabilityList.

Examples

Microsoft.SqlServer/Database
Microsoft.SqlServer.Database/Role
Microsoft.SqlServer.Database/User
Microsoft.SqlServer/Endpoint
Microsoft.SqlServer.Endpoint/Permission
Microsoft.SqlServer/Login
Microsoft.SqlServer/MaxDop

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment