Performance Tuning Guide¶

Performance optimization strategies for IAM infrastructure provisioned by the SEC Provisioner.

Table of Contents¶

Deployment Performance
IAM API Performance
CloudFormation Optimization
Template Size Optimization
SSM Parameter Store Performance
Provisioner Performance
Monitoring Performance

Deployment Performance¶

Typical Deployment Times by Tier¶

Tier	Resources	Template Size	Deploy Time	Delete Time
Startup-5	~20	~30 KB	30-60 seconds	20-40 seconds
Medium-10	~44	~69 KB	90-120 seconds	60-90 seconds
Enterprise-12	~55	~85 KB	120-180 seconds	90-120 seconds

Deployment time scales linearly with resource count. IAM resource creation is fast — the overhead is CloudFormation orchestration.

What Affects Deploy Time¶

Factor	Impact	Mitigation
Resource count	Linear — more resources = longer	Use appropriate tier
S3 template upload	1-3 seconds (medium/enterprise)	Ensure S3 bucket is in same region
SSM parameter storage	1-2 seconds per parameter	Unavoidable — sequential API calls
CloudFormation orchestration	30-60 seconds base overhead	Unavoidable
AWS API throttling	Can add 10-30 seconds	Retry logic built into provisioner

IAM API Performance¶

API Rate Limits¶

AWS IAM has global rate limits:

Operation	Rate Limit	Notes
CreateGroup	5 requests/second	Shared across account
CreateRole	5 requests/second	Shared across account
CreatePolicy	5 requests/second	Shared across account
AttachGroupPolicy	5 requests/second	Shared across account
PutGroupPolicy	5 requests/second	Shared across account

CloudFormation manages these limits automatically with built-in retry and backoff. You don’t need to tune this.

Concurrent Deployments¶

Avoid deploying multiple SEC stacks simultaneously in the same account — IAM API rate limits are shared across the entire account. Deploy sequentially:

# Deploy dev first
--config edge-dev-b001-us-west-1-sec.yaml --action deploy --force

# Then staging
--config edge-staging-b001-us-west-1-sec.yaml --action deploy --force

# Then production
--config edge-prod-b001-us-west-1-sec.yaml --action deploy --force

CloudFormation Optimization¶

Template Size and Deployment Method¶

Template Size	Method	Performance
< 51,200 bytes	TemplateBody (inline)	Fastest — no S3 upload
> 51,200 bytes	S3 TemplateURL	1-3 seconds slower (upload step)

Startup tier templates are typically under 51 KB and use TemplateBody. Medium and enterprise exceed this limit and automatically upload to S3.

ChangeSet Performance¶

show-changes creates a temporary ChangeSet:

Stack Size	ChangeSet Creation	Total Time
20 resources	5-10 seconds	10-20 seconds
44 resources	10-20 seconds	20-35 seconds
55 resources	15-25 seconds	25-45 seconds

Drift Detection Performance¶

check-drift initiates drift detection on all supported resources:

Stack Size	Detection Time	Notes
20 resources	10-20 seconds	IAM Groups excluded (not supported)
44 resources	20-40 seconds	Only roles and policies checked
55 resources	30-60 seconds	Larger stacks take longer

Note: CloudFormation does not support drift detection for IAM Groups. Only IAM Roles and Managed Policies are checked.

Template Size Optimization¶

What Drives Template Size¶

Component	Size Impact	Per Resource
IAM Group (with inline policies)	~1-2 KB	Depends on policy count
Service Role	~0.5-1 KB	Depends on policy attachments
Assumable Role	~0.5-1 KB	Cross-function or elevation
Managed Policy	~1-3 KB	Depends on action count
Stack Output	~0.1 KB	One per resource

Reducing Template Size¶

If you’re close to the 51 KB TemplateBody limit (startup tier):

Remove unused groups from the security profile
Reduce policy assignments per group
Use combined policies to merge multiple service permissions

If you exceed 51 KB, the provisioner automatically switches to S3 TemplateURL — no action needed.

SSM Parameter Store Performance¶

Write Performance¶

After deployment, the provisioner stores stack outputs in SSM Parameter Store:

Tier	Parameters	Write Time
Startup-5	~20	3-5 seconds
Medium-10	~46	7-12 seconds
Enterprise-12	~55	10-15 seconds

Parameters are written sequentially (SSM API limitation). This is the final step after stack creation.

Read Performance¶

Reading parameters for cross-provisioner integration:

import boto3

ssm = boto3.client('ssm', region_name='us-west-1')

# Single parameter — < 50 ms
role_arn = ssm.get_parameter(
    Name='/security/edge-prod-b001-us-west-1-medium-sec/SagemakerExecutionRoleArn'
)['Parameter']['Value']

# All parameters — 100-300 ms
all_params = ssm.get_parameters_by_path(
    Path='/security/edge-prod-b001-us-west-1-medium-sec/',
    Recursive=True
)

Caching Recommendations¶

For applications that read SEC parameters frequently:

Cache parameter values in application memory
Refresh cache every 5-15 minutes
Use get_parameters (batch) instead of individual get_parameter calls

Provisioner Performance¶

Operation Times¶

Action	Typical Duration	Bottleneck
validate-config	< 1 second	Schema validation (local)
export-iam-policy	< 1 second	JSON generation (local)
export-service-policies	< 1 second	Template parsing (local)
export-groups	< 1 second	Config parsing (local)
export-roles	< 1 second	Config parsing (local)
create-prov-template	< 1 second	Template generation (local)
validate-prov-template	< 1 second	YAML parsing + ref checking (local)
show-changes	10-45 seconds	ChangeSet creation (AWS)
check-drift	10-60 seconds	Drift detection (AWS)
test-deploy	30-180 seconds	Stack creation (AWS)
deploy	30-180 seconds	Stack creation + SSM writes (AWS)
delete-stack	20-120 seconds	Stack deletion + SSM cleanup (AWS)

Local Actions Are Instant¶

All export and validation actions run locally — they parse config files and generate output without AWS API calls (except license validation). These complete in under 1 second regardless of tier.

Optimizing the Deployment Workflow¶

Validate early: Run validate-config and validate-prov-template before deploying
Export and review: Use export actions to catch issues before deployment
Test first: Use test-deploy to verify the full stack before production
Preview changes: Use show-changes before updating an existing stack

This workflow catches errors locally (< 1 second) instead of waiting for CloudFormation failures (60+ seconds).

Monitoring Performance¶

CloudFormation Stack Events¶

Monitor deployment progress:

# Watch stack events in real-time
aws cloudformation describe-stack-events \
  --stack-name edge-prod-b001-us-west-1-medium-sec-stack \
  --query 'StackEvents[0:5].[Timestamp,ResourceStatus,LogicalResourceId]' \
  --output table

CloudTrail API Monitoring¶

Track IAM API call rates to detect throttling:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=iam.amazonaws.com \
  --max-results 20 \
  --query 'Events[].{Time:EventTime,Name:EventName,Error:ErrorCode}'

If you see Throttling errors, space out deployments across environments.

Execution Logs¶

Review provisioner logs for timing information:

# Each log includes operation timing
grep "took" sec/reports/*.log
# Example: Operation 'deploy-security-stack' took 112.16s

For cost optimization, see COST_OPTIMIZATION.md. For troubleshooting, see TROUBLESHOOTING.md.