Configuration Reference¶

For AWS resource naming conventions (physical names, SSM paths, CloudFormation logical IDs), see NAMING_CONVENTIONS.md.

Table of Contents¶

Config File Naming Convention
Configuration Discriminators
Discriminator Combinations (Enterprise Tier)
- Choosing the right combination

Config File Naming Convention¶

Config files follow a standardized naming pattern that encodes all discriminators directly in the filename, making it immediately clear what each file configures.

Pattern:

{company_prefix}-{env}-{tenant_id}-{region}-{use_case}-ml-{source_control}[-{vpc_mode}-{vpc_source}][-workload][-rtb].yaml

Segment	Values	Notes
`company_prefix`	e.g. `globalbank`, `techcorp`, `edge`	From `client.company_prefix`
`env`	`dev`, `staging`, `prod`	From `environment.env`
`tenant_id`	e.g. `a001`, `b001`, `c001`	From `client.tenant_id`
`region`	e.g. `us-west-1`, `us-west-2`	From `environment.region`
`use_case`	e.g. `fraud-detection`, `customer-churn`	From `ml_product.use_case`
`source_control`	`codecommit` \| `s3`	Always present
`vpc_mode`	`standalone` \| `sgprov`	Enterprise tier only
`vpc_source`	`ssm` \| `direct`	Enterprise tier only
`workload`	`workload`	Present when `ml_product.workload` is set
`rtb`	`rtb`	Present when `route_table_ids` are populated

The VPC segments (vpc_mode and vpc_source) are omitted for starter and professional tiers since VPC integration is an enterprise-only feature.

Examples:

# Starter / Professional tier
techcorp-prod-a001-us-west-2-customer-churn-ml-codecommit.yaml
techcorp-prod-a001-us-west-2-customer-churn-ml-s3.yaml
techcorp-prod-a001-us-west-2-customer-churn-ml-codecommit-workload.yaml

# Enterprise tier
globalbank-prod-c001-us-west-2-demand-forecasting-ml-codecommit-standalone-ssm.yaml
globalbank-prod-c001-us-west-2-demand-forecasting-ml-codecommit-standalone-direct.yaml
globalbank-prod-c001-us-west-2-demand-forecasting-ml-codecommit-sgprov-ssm.yaml
globalbank-prod-c001-us-west-2-demand-forecasting-ml-s3-standalone-ssm.yaml
globalbank-prod-c001-us-west-2-demand-forecasting-ml-codecommit-standalone-ssm-workload.yaml
globalbank-prod-c001-us-west-2-demand-forecasting-ml-codecommit-standalone-direct-rtb.yaml

Configuration Discriminators¶

An ML Provisioner configuration file is defined by three independent discriminators under the ml_product section. Together they determine which resources are created and how the tool integrates with your existing AWS infrastructure.

1. `source_control`¶

Controls how source code repositories are provisioned for the ML pipelines.

Value	Description
`codecommit`	Creates AWS CodeCommit repositories for model-build and model-deploy source code
`s3`	Uses an existing S3 bucket as the pipeline source — no CodeCommit repositories are created

2. `vpc_integration.mode`¶

Controls how the VPC endpoint Security Group is managed.

Value	Description
`standalone`	ML Provisioner creates and manages its own endpoint Security Group
`sgprov`	Security Group is managed externally by SG Provisioner — ML Provisioner skips SG creation and reads the existing SG ID from SSM Parameter Store

Note: mode is nested under vpc_integration in the config file. The value sgprov in config filenames is shorthand for sg-provisioner — the actual YAML value is sg-provisioner.

3. `vpc_integration.vpc_source`¶

Controls how the VPC ID and subnet IDs are resolved at deploy time.

Value	Description
`ssm`	VPC ID and subnet IDs are read from AWS Systems Manager Parameter Store paths — typically populated by VPC Provisioner
`direct`	VPC ID and subnet IDs are hardcoded directly in the configuration file

Note: ssm in config filenames is shorthand for parameter-store — the actual YAML value is parameter-store.

Discriminator Combinations (Enterprise Tier)¶

The three discriminators are independent and can be combined freely. The workload and rtb suffixes are optional additions on top of the base combinations. This gives 12 config files for the enterprise tier.

#	source_control	mode	vpc_source	workload	rtb	Config file suffix
1	codecommit	standalone	ssm	—	—	`-codecommit-standalone-ssm`
2	codecommit	standalone	ssm	yes	—	`-codecommit-standalone-ssm-workload`
3	codecommit	standalone	direct	—	—	`-codecommit-standalone-direct`
4	codecommit	standalone	direct	—	yes	`-codecommit-standalone-direct-rtb`
5	codecommit	sgprov	ssm	—	—	`-codecommit-sgprov-ssm`
6	codecommit	sgprov	direct	—	—	`-codecommit-sgprov-direct`
7	s3	standalone	ssm	—	—	`-s3-standalone-ssm`
8	s3	standalone	ssm	yes	—	`-s3-standalone-ssm-workload`
9	s3	standalone	direct	—	—	`-s3-standalone-direct`
10	s3	standalone	direct	—	yes	`-s3-standalone-direct-rtb`
11	s3	sgprov	ssm	—	—	`-s3-sgprov-ssm`
12	s3	sgprov	direct	—	—	`-s3-sgprov-direct`

workload is only supported with vpc_source: ssm. rtb is only supported with vpc_source: direct.

Choosing the right combination¶

ssm vs direct — use ssm when VPC Provisioner manages your VPC and publishes IDs to Parameter Store (recommended for bundle deployments). Use direct when you know the VPC IDs upfront or are not using VPC Provisioner.
standalone vs sgprov — use standalone for a self-contained ML deployment. Use sgprov when SG Provisioner is already deployed and you want the ML endpoints to use its managed Security Group.
codecommit vs s3 — use codecommit for teams that want AWS-native Git repositories. Use s3 when source code is managed externally and uploaded to S3 before pipeline execution.