Naming Conventions

Table of Contents

Overview

This document defines the naming conventions for all resources and artifacts created by the Security Provisioner Tool.

Configuration Variables

All naming patterns use these variables from the configuration file:

  • {company_prefix} - Company identifier (e.g., acme)

  • {env} - Environment (e.g., prod, dev, staging)

  • {tenant_id} - AWS tenant id (e.g., a001)

  • {region} - AWS region (e.g., us-west-1)

  • {tier_name} - Security tier name without version (e.g., startup, medium, enterprise)

The stem is the base name prefix used across all resources and files. Every resource the tool creates starts with this stem, making it easy to identify and manage all artifacts from a single deployment.

Stem pattern: {company_prefix}-{env}-{tenant_id}-{region}-{tier_name}-sec

Stem examples:

  • techcorp-prod-a001-us-west-1-startup-sec

  • edge-prod-b001-us-west-1-medium-sec

  • globalbank-prod-c001-us-west-1-enterprise-sec

For example, if your stem is edge-prod-b001-us-west-1-medium-sec, then:

  • Your stack is named edge-prod-b001-us-west-1-medium-sec-stack

  • Your template file is edge-prod-b001-us-west-1-medium-sec-template.yaml

  • Your IAM policy file is edge-prod-b001-us-west-1-medium-sec-iam-policy.json

  • Your log files start with edge-prod-b001-us-west-1-medium-sec-

Note: The tier name in the stem comes from tier.name in the configuration file (e.g., startup, medium, enterprise). The tier version (e.g., startup-5, medium-10, enterprise-12) is tracked separately in tier.version and does not appear in resource names.

AWS Resources

CloudFormation Stack (Regional)

Pattern: {stem}-stack

Examples:

  • techcorp-prod-a001-us-west-1-startup-sec-stack

  • edge-prod-b001-us-west-1-medium-sec-stack

  • globalbank-prod-c001-us-west-1-enterprise-sec-stack

Rationale: Stack is deployed to a specific region, even though it creates global IAM resources. Region is included for:

  • Multi-region deployment support

  • Drift detection and stack management

  • Future regional resource extensions (KMS, Secrets Manager, Security Hub)

IAM Groups (Global)

Pattern: {company_prefix}-{env}-{tenant_id}-group-{group_name}

Examples:

  • globalbank-prod-c001-group-data-scientists

  • globalbank-prod-c001-group-ai-governance

  • edge-prod-b001-group-platform-administrators

  • edge-prod-b001-group-operations-support

  • techcorp-prod-a001-group-business-consumers

  • techcorp-prod-a001-group-data-scientists

Rationale: IAM groups are global (account-level), so region is omitted.

IAM Service Roles (Global)

Pattern: {company_prefix}-{env}-{tenant_id}-role-{role_name}

Examples:

  • globalbank-prod-c001-role-lambda-ml-pipeline

  • globalbank-prod-c001-role-glue-etl

  • edge-prod-b001-role-sagemaker-execution

  • edge-prod-b001-role-codebuild-service

  • techcorp-prod-a001-role-sagemaker-execution

  • techcorp-prod-a001-role-lambda-ml-pipeline

Rationale: IAM roles are global (account-level), so region is omitted.

IAM Assumable Roles (Global)

Pattern: {company_prefix}-{env}-{tenant_id}-role-{role_name}

Examples:

  • edge-prod-b001-role-adata-scientist

  • globalbank-prod-c001-role-aml-engineer

Rationale: Assumable (cross-function and elevation) roles use the same role- prefix as service roles. They are distinguished by their trust policy (same-account assumption) and their config key name.

IAM Cross-Account Roles (Global)

Pattern: {company_prefix}-{env}-{tenant_id}-xacct-{role_name}

Examples:

  • globalbank-prod-c001-xacct-deployment-role

  • globalbank-prod-c001-xacct-monitoring-role

Rationale: IAM cross-account roles are global. The xacct prefix distinguishes them from service and assumable roles.

IAM Custom Policies (Inline)

All custom policies are created as inline policies attached directly to their parent IAM group or role. Inline policy names use a short descriptive name only (e.g., s3-access, ecr-access) — they do not carry the full resource prefix because they are scoped to their parent resource and are not independently addressable.

Note: Our roadmap includes a working item to convert inline policies to standalone managed policies depending on client interest. If implemented, standalone policies would follow the pattern {company_prefix}-{env}-{tenant_id}-policy-{policy_name}.

Test Resources (Temporary)

Pattern: {stem}-stack-test-{6_char_random}

Examples:

  • edge-prod-b001-us-west-1-medium-sec-stack-test-a3f9c2

  • edge-prod-b001-group-data-scientists-test-a3f9c2

  • edge-prod-b001-role-sagemaker-execution-test-7b2e1d

  • edge-prod-b001-xacct-deployment-role-test-7b2e1d

Rationale: Test resources use random suffix for uniqueness and easy identification for cleanup.

Local Artifacts

All local artifacts are stored relative to the application working directory.

Configuration Files

Location: configs/

Pattern for Master Configuration Template: {tier_name}-master-config.yaml

Examples:

  • startup-master-config.yaml

  • medium-master-config.yaml

  • enterprise-master-config.yaml

Pattern for Client Configuration: {company_prefix}-{env}-{tenant_id}-{region}-sec.yaml

Examples:

  • techcorp-prod-a001-us-west-1-sec.yaml

  • edge-prod-b001-us-west-1-sec.yaml

  • globalbank-prod-c001-us-west-1-sec.yaml

CloudFormation Templates

Location: templates/

Pattern: {stem}-template.yaml

Examples:

  • techcorp-prod-a001-us-west-1-startup-sec-template.yaml

  • edge-prod-b001-us-west-1-medium-sec-template.yaml

  • globalbank-prod-c001-us-west-1-enterprise-sec-template.yaml

Rationale: Template name and stack name share the same stem for easy correlation.

IAM Policy Files

Location: policies/

Pattern: {stem}-iam-policy.json

Examples:

  • techcorp-prod-a001-us-west-1-startup-sec-iam-policy.json

  • edge-prod-b001-us-west-1-medium-sec-iam-policy.json

  • globalbank-prod-c001-us-west-1-enterprise-sec-iam-policy.json

Rationale: Policy file contains permissions needed to deploy the security stack.

Group Export Files

Location: groups/

Pattern: {company_prefix}-{env}-{tenant_id}-group-{group_name}.json

Examples:

  • edge-prod-b001-group-data-scientists.json

  • edge-prod-b001-group-platform-administrators.json

  • globalbank-prod-c001-group-ai-governance.json

Rationale: Exported group definitions for review and audit before deployment.

Role Export Files

Location: roles/

Pattern: {company_prefix}-{env}-{tenant_id}-role-{role_name}.json

Examples:

  • edge-prod-b001-role-sagemaker-execution.json

  • edge-prod-b001-role-lambda-ml-pipeline.json

  • globalbank-prod-c001-role-glue-etl.json

Rationale: Exported role definitions for review and audit before deployment.

Log Files

Location: reports/

Pattern: {stem}-{action}-{timestamp}.log

Examples:

  • techcorp-prod-a001-us-west-1-startup-sec-deploy-20260316_220312_211.log

  • edge-prod-b001-us-west-1-medium-sec-validate-config-20260316_220500_456.log

  • globalbank-prod-c001-us-west-1-enterprise-sec-create-prov-template-20260316_220312_211.log

Rationale: Timestamp ensures unique log files for each execution. Action name helps identify operation type.

HTML Reports

Location: reports/

Pattern: {stem}-{action}-{timestamp}.html

Examples:

  • edge-prod-b001-us-west-1-medium-sec-validate-config-20260316_220500_456.html

  • edge-prod-b001-us-west-1-medium-sec-policies-20260316_221000_789.html

  • edge-prod-b001-us-west-1-medium-sec-deployment-20260316_221500_123.html

Rationale: HTML reports provide formatted output for browser-based review of validation results, policy summaries, and deployment status.

Policy Templates

Location: policy-templates/

Policy templates are YAML files containing pre-built IAM policy statements for AWS services. They are organized by service:

policy-templates/
├── bedrock/
├── combined/
├── ecr/
├── kms/
├── lambda/
├── pipeline/
├── s3/
├── sagemaker/
└── trusted-advisor/

Combined template pattern: {level_name}.yaml
Service template pattern: {level}-{description}.yaml

Examples:

  • policy-templates/combined/mlops-services-a.yaml

  • policy-templates/sagemaker/level1-read-only.yaml

  • policy-templates/sagemaker/level3-prod-invoke.yaml

  • policy-templates/kms/level1-read-only.yaml

Rationale: Policy templates are not client-specific. They contain publicly documented AWS IAM actions organized by service and access level.

Validation Schemas

Location: schemas/

Pattern: validation-schema-{tier_name}.yaml

Examples:

  • validation-schema-startup.yaml

  • validation-schema-medium.yaml

  • validation-schema-enterprise.yaml

Rationale: A specialized validation schema is used for validating tier configuration.

AWS Systems Manager Parameters

Location: AWS Systems Manager Parameter Store

Pattern: /security/{stem}/{output_key}

Examples:

  • /security/edge-prod-b001-us-west-1-medium-sec/StackName

  • /security/edge-prod-b001-us-west-1-medium-sec/SecurityProfile

  • /security/edge-prod-b001-us-west-1-medium-sec/DataScientistsGroupArn

  • /security/edge-prod-b001-us-west-1-medium-sec/SagemakerExecutionRoleArn

Rationale: Parameter Store paths use the full stem (including region) for multi-region deployment support.

Policy ARN Construction

IAM policies reference regional resources using tenant-scoped ARN patterns:

S3 Bucket ARN:

arn:aws:s3:::${company_prefix}-${env}-${tenant_id}-*
arn:aws:s3:::${company_prefix}-${env}-${tenant_id}-*/*

SageMaker Endpoint ARN:

arn:aws:sagemaker:*:*:endpoint/${company_prefix}-${env}-${tenant_id}-dev-*
arn:aws:sagemaker:*:*:endpoint/${company_prefix}-${env}-${tenant_id}-staging-*
arn:aws:sagemaker:*:*:endpoint/${company_prefix}-${env}-${tenant_id}-prod-*

SageMaker Pipeline ARN:

arn:aws:sagemaker:*:*:pipeline/${company_prefix}-${env}-${tenant_id}-*

Rationale: Even though IAM resources are global, they grant permissions to regional resources, so region must be available in the configuration. Endpoint and pipeline ARNs use wildcards for region and account to support cross-region access patterns.

Naming Convention Comparison

Resource Type

S3 Provisioner

VPC Provisioner

Security Provisioner

Stack Name

{prefix}-{env}-{tid}-{region}-s3-stack

{prefix}-{env}-{tid}-{region}-vpc-stack

{prefix}-{env}-{tid}-{region}-{tier_name}-sec-stack

Primary Resource

{prefix}-{env}-{tid}-{region}-s3

{prefix}-{env}-{tid}-{region}-vpc

{prefix}-{env}-{tid}-group-{name}

IAM Policy

{prefix}-{env}-{tid}-{region}-s3-iam-policy.json

{prefix}-{env}-{tid}-{region}-vpc-iam-policy.json

{prefix}-{env}-{tid}-{region}-{tier_name}-sec-iam-policy.json

Template

{prefix}-{env}-{tid}-{region}-s3-{solution}-template.yaml

{prefix}-{env}-{tid}-{region}-vpc-template.yaml

{prefix}-{env}-{tid}-{region}-{tier_name}-sec-template.yaml

SSM Path

/s3/{prefix}-{env}-{tid}-{region}-s3/

/vpc/{prefix}-{env}-{tid}-{region}-vpc/

/security/{prefix}-{env}-{tid}-{region}-{tier_name}-sec/

Rationale: Consistent naming pattern across all three provisioners with service-specific suffixes. {tid} is shorthand for {tenant_id}.