Infrastructure as code adoption has established Terraform as the most popular cross cloud framework for codified environments. Within AWS, Systems Manager Parameter Store provides a centralized location for configuration data and secrets that applications can reference at runtime. The interaction between Terraform state and SSM Parameters creates a specific operational tension when parameters are expected to be created once by Terraform and subsequently maintained by other processes. This pattern emerges in CI pipelines that publish image tags, deployment systems that rotate credentials, and operational teams that update configuration through the AWS console or AWS CLI. The reference implementation demonstrates how Terraform can establish the initial parameter resource while remaining tolerant of later external mutations.
The practical scenario begins with a parameter named example created as a String type. Terraform plan output shows the resource creation intent with attributes including arn known after apply, datatype known after apply, id known after apply, insecurevalue known after apply, keyid known after apply, name = "example", tagsall known after apply, tier known after apply, type = "String", value sensitive value, version known after apply. Plan reports 1 to add, 0 to change, 0 to destroy. The apply operation completes after approximately 2 seconds with the message awsssmparameter.example: Creation complete after 2s and Apply complete! Resources: 1 added, 0 changed, 0 destroyed. Outputs include ssmparamvalue = "set by terraform". Verification via CLI confirms the parameter exists with Name example, Type String, Value set by terraform, Version 1, LastModifiedDate "2024-09-17T08:03:23.914000+10:00", ARN arn:aws:ssm:us-east-1:012345678910:parameter/example, DataType text.
External Update Challenge And State Drift
When a process outside Terraform modifies the parameter value, a subsequent terraform apply will detect drift and revert the value to the value stored in state. This behavior is the default reconciliation model of Terraform. For teams that require an initial seed value followed by ongoing external management, the revert action introduces operational conflict. Creating the parameter directly in the console or AWS CLI avoids the revert, but the parameter is not tracked in code, which defeats infrastructure as code governance.
The impact for users is loss of drift visibility and potential outages when automated workflows overwrite intentional changes. The consequence for citizens of the system is that configuration published by GitHub Actions building docker images and pushing them to ECR cannot be safely referenced if Terraform insists on owning the value. The solution demonstrated in the reference material allows Terraform to create the parameter and then yield control of the value to external systems while still tracking existence, name, type, tier and tags.
The workflow where Actions update the current stable tag in SSM and Terraform pulls this value when deploying ECS task or Lambda function illustrates the intended collaboration. The parameter serves as a shared contract between deployment automation and infrastructure provisioning. When Terraform refreshes its state, it pulls the current value of awsssmparameter.example.value from SSM, ensuring the infrastructure definition reflects reality without forcing a write back.
Lifecycle Meta Arguments For Ignoring Value Changes
Terraform provides a lifecycle meta argument that can prevent resource updates based on specific attributes. Applying lifecycle to awsssmparameter allows the resource to be created and managed for existence and metadata while ignoring changes to the value attribute. The module example with ignorevaluechanges = true demonstrates this pattern:
module "list" {
source = "terraform-aws-modules/ssm-parameter/aws"
ignore_value_changes = true
name = "my-parameter-ignore-value-changes"
value = "some-value"
}
The real world consequence is that operators can update the parameter via AWS CLI or console and Terraform will no longer force a revert on the next apply. The state remains synchronized because refresh reads the live value, while plan will report 0 changes for value mutations. This preserves auditability of the resource while permitting operational flexibility.
A data source alternative exists, awsssmparameter data source, but it carries a downside. Terraform fails if the data source does not exist. This prevents creation of dependent resources such as ECR repositories until the parameter exists, which reintroduces manual bootstrapping. The lifecycle approach avoids the chicken and egg problem by allowing Terraform to create the parameter initially.
Regular rotation of credentials and other secrets is an important security hygiene habit. Tracking and managing infrastructure as code ensures consistency in environments. Using lifecycle arguments for SSM Params allows both objectives to be achieved without conflict or surprises.
Terraform Module Patterns For SSM Parameters
The terraform-aws-modules/ssm-parameter/aws module provides a wrapper for creating AWS SSM Parameters with reduced code duplication. The module supports creation of one of multiple SSM Parameters, value type guesser, ability to allow SSM Parameter to ignore changes in the value, and a wrapper for managing multiple resources with less code.
Example usage patterns include:
module "string" {
source = "terraform-aws-modules/ssm-parameter/aws"
name = "my-parameter"
value = "some-value"
}
module "secret" {
source = "terraform-aws-modules/ssm-parameter/aws"
name = "my-secret-token"
value = "secret123123!!!"
secure_type = true
}
module "list" {
source = "terraform-aws-modules/ssm-parameter/aws"
name = "my-list-parameter"
values = ["item1", "item2"]
}
The list module note specifies values not value for StringList type.
Local parameter definitions enable bulk creation:
locals {
parameters = {
"string_simple" = {
value = "string_value123"
}
"string" = {
type = "String"
value = "string_value123"
tier = "Intelligent-Tiering"
allowed_pattern = "[a-z0-9_]+"
}
"secure" = {
type = "SecureString"
value = "secret123123!!!"
tier = "Advanced"
description = "My awesome password!"
}
"secure_encrypted_true" = {
secure_type = true
value = "secret123123!!!"
key_id = "c938de44-1c09-4c91-89fd-b5881f06f317"
}
"list_as_autoguess_type" = {
values = ["item1", "item2"]
}
}
}
The pattern reduces repetition when provisioning dozens of parameters across environments. Impact for platform teams is faster onboarding and consistent tagging, encryption and tier selection.
Parameter Types, Tiers And Value Guessing
SSM Parameter Store supports String, SecureString and StringList types. The module provides a value type guesser that infers type from input shape. Explicit type control is available via type argument. Tier selection influences storage costs and throughput. Intelligent-Tiering is used for string parameters with allowedpattern constraints such as [a-z0-9]+. Advanced tier is used for SecureString with description "My awesome password!" and for parameters requiring policies, expiration or more than 10K parameters.
Secure type activation uses securetype = true and optionally keyid for customer managed KMS key. Example key_id c938de44-1c09-4c91-89fd-b5881f06f317 demonstrates explicit key association. Encryption posture remains consistent because both Secrets Manager and SSM Parameter Store use KMS for encryption. Security posture does not change when migrating between services.
Standard tier costs $0.05 per parameter per month for Advanced tier. Standard is free for up to 10,000 parameters. You only need Advanced tier for policies, expiration, or >10K parameters.
Cost Comparison Between Secrets Manager And SSM Parameter Store
Financial analysis shows Secrets Manager incurs a monthly tax per secret. The reference table quantifies annual cost:
- 20 secrets: Secrets Manager $96 per year, SSM Parameter Store $0 per year, Annual Savings $96
- 50 secrets: Secrets Manager $240 per year, SSM Parameter Store $0 per year, Annual Savings $240
- 100 secrets: Secrets Manager $480 per year, SSM Parameter Store $0 per year, Annual Savings $480
- 200 secrets: Secrets Manager $960 per year, SSM Parameter Store $0 per year, Annual Savings $960
The bottom line states that if secrets do not rotate automatically, the organization is paying a $0.40 per month tax per secret for nothing. SSM Parameter Store provides the same encryption, same access control, same SDK experience for free.
Impact for finance teams is immediate budget relief at scale. Impact for developers is removal of cost barriers to storing configuration.
Migration guidance includes:
- Monitor for 48 hours
- Check CloudTrail — no more GetSecretValue calls
- THEN remove Secrets Manager resources from Terraform
- Terraform apply to delete old secrets
Warning: Never delete the Secrets Manager secret before confirming the app reads from SSM. Run both in parallel during the transition.
Do not migrate rotation-dependent secrets. If RDS credentials auto-rotate via Secrets Manager, leave them. The rotation Lambda integration is not worth rebuilding.
Hierarchical Naming Conventions And Path Based Access
Naming convention matters for discoverability and policy scope. Use hierarchical paths like /app/env/secret-name. SSM supports path-based GetParametersByPath to fetch all secrets for an app at once.
Example path /app/env/secret-name enables bulk retrieval of parameters under a common prefix. Teams can query entire environment configuration with a single API call, reducing latency and IAM policy complexity.
The consequence for operational workflows is faster secret distribution and simplified rotation auditing.
IAM Granularity And Security Posture
SSM supports path-based policies for fine grained access control. Example policy:
arn:aws:ssm:*:*:parameter/myapp/prod/*
This restricts access to just prod secrets. The impact for security teams is least privilege enforcement without custom tagging schemes. Developers can be granted read access to a specific application and environment prefix while being denied access to others.
KMS is the same for both services. Both use KMS for encryption. Security posture does not change when migrating from Secrets Manager to Parameter Store.
Integration With EC2, Load Balancer And Production Workloads
The reference material describes setting up a fully functional server with Terraform using EC2, SSM and Load Balancer. Building a robust and scalable server infrastructure from scratch might seem complex, but with Terraform it becomes a structured and efficient process.
From networking and secure remote management with SSM to deploying a NestJS backend behind a load balancer, the groundwork for a production-ready environment is laid. SSM provides secure remote management for EC2 instances without bastion hosts. Load balancer configuration ties to auto scaling groups and health checks.
Keywords associated with the pattern are Terraform, AWS, EC2, SSM, Load Balancer, Infrastructure as Code, IaC, NestJS, Cloud Infrastructure, DevOps.
Next steps suggested include adding features like autoscaling or monitoring with CloudWatch for even more robustness.
The integration demonstrates how SSM Parameter values can be consumed by EC2 user data or container environment variables injected via Terraform. The parameter serves as a single source of truth for configuration that changes independently of infrastructure.
Migration Checklist From Secrets Manager To Parameter Store
A practical migration sequence minimizes risk:
- Monitor for 48 hours
- Check CloudTrail for no more GetSecretValue calls
- THEN remove Secrets Manager resources from Terraform
- Terraform apply to delete old secrets
Never delete the Secrets Manager secret before confirming the app reads from SSM. Run both in parallel during the transition.
Naming convention matters. Use hierarchical paths like /app/env/secret-name. SSM supports path-based GetParametersByPath to fetch all secrets for an app at once.
Use Standard tier. Advanced tier costs $0.05 per parameter per month. You only need it for policies, expiration, or >10K parameters. Standard is free for up to 10,000 parameters.
KMS is the same. Both services use KMS for encryption. Security posture does not change.
IAM granularity is available via path-based policies such as arn:aws:ssm:::parameter/myapp/prod/* which restricts access to just prod secrets.
Do not migrate rotation-dependent secrets. If RDS credentials auto-rotate via Secrets Manager, leave them. The rotation Lambda integration is not worth rebuilding.
The cost table reinforces the economic incentive for static secrets.
Conclusion
Managing AWS Systems Manager Parameters with Terraform while allowing external updates represents a mature compromise between immutable infrastructure principles and operational reality. The lifecycle meta argument provides a technical mechanism to create parameters with Terraform and then relinquish ownership of the value attribute to external processes. Module wrappers reduce boilerplate and enforce consistent tier, type and encryption choices across teams. Hierarchical naming and path based IAM policies deliver granular access control that matches application boundaries.
Cost analysis demonstrates substantial savings when secrets do not require automatic rotation, with annual savings scaling linearly with secret count and zero cost for SSM Parameter Store Standard tier up to 10,000 parameters. Migration requires careful parallel operation, CloudTrail validation and avoidance of rotation dependent secrets.
The pattern scales from single parameter examples such as example with value set by terraform to enterprise fleets managed via locals maps with String, SecureString and StringList types, Intelligent-Tiering and Advanced tiers, and explicit KMS key IDs. Integration with EC2, SSM Session Manager and load balancers completes a production ready stack where configuration changes propagate without infrastructure drift.
The combination of Terraform state tracking, external update tolerance, and cost effective storage makes SSM Parameter Store a central pillar for configuration management in AWS environments that require both code governance and operational agility.