Updatestf-aws

Terraform AWS Provider: 13 New Features in Networkmanager Attachment Routing Policy Label, Launch Template

v6.32.1v6.33.0Verified February 22, 2026

```mdx

Impact Assessment

Severity: High

This release spans 20 changes across 16 resources, combining 13 new feature additions with 7 behavioral fixes — several of which address production-impacting panics, race conditions, and API validation errors that could silently break deployments.

---

Editor's Note: We'd characterize v6.33.0 as a substantive feature drop rather than routine maintenance, particularly given the breadth of the aws_dms_endpoint oracle_settings expansion and the introduction of aws_networkmanager_attachment_routing_policy_label as a net-new resource. This release continues a recent pattern in the AWS provider of deepening DMS and networking coverage in step with AWS service GA announcements. If your team uses aws_lb with more than 20 attributes — a threshold that's easy to hit with access logs, deletion protection, and cross-zone settings combined — we'd prioritize testing that fix before anything else.

---

Detailed Breakdown

`aws_networkmanager_attachment_routing_policy_label` — New Resource

What changed: A brand-new resource, aws_networkmanager_attachment_routing_policy_label, has been introduced. There is no prior state to migrate from.

Why this matters: Teams managing Cloud WAN attachment routing policies previously had no native Terraform resource for labeling; this gap required workarounds or manual console steps. The new resource enables policy label lifecycle management directly in IaC.

Migration steps:

  • Add the resource block to your Network Manager configurations where routing policy labels are needed.
  • Import any existing labels using terraform import if they were created out-of-band.
  • Confirm your IAM roles include the relevant networkmanager:TagResource and networkmanager:UntagResource permissions.
  • ---

    `aws_launch_template` — `cpu_options.nested_virtualization` and `network_performance_options`

    What changed: Two additions land on aws_launch_template: a nested_virtualization attribute inside the cpu_options block, and a new top-level network_performance_options configuration block. The same nested_virtualization attribute also appears on aws_instance.

    Why this matters: nested_virtualization enables hardware-assisted virtualization within EC2 instances — relevant for workloads running hypervisors or nested VMs. network_performance_options exposes bandwidth configuration that was previously only settable at launch via the API. Both attributes are additive and non-breaking for existing templates.

    Migration steps:

  • Review existing aws_launch_template and aws_instance resources; no changes are required unless you want to adopt these attributes.
  • For nested_virtualization, confirm the target instance type supports it (not all do — check AWS documentation for supported families).
  • Add network_performance_options blocks only after verifying the instance type supports the bandwidth tier you intend to configure.
  • ---

    `aws_launch_template` — `secondary_interfaces` Configuration Block

    What changed: A secondary_interfaces configuration block is now available on aws_launch_template.

    Why this matters: Previously, secondary network interface configuration required separate aws_network_interface resources or instance-level scripting. Embedding this in the launch template simplifies Auto Scaling group configurations that need pre-defined secondary ENI settings.

    Migration steps:

  • Audit any launch templates that rely on external aws_network_interface resources attached post-launch; evaluate whether secondary_interfaces can consolidate that logic.
  • Test in a non-production Auto Scaling group before rolling out, as ENI configuration changes can affect instance startup behavior.
  • ---

    `aws_dms_endpoint` — Expanded `oracle_settings` and `mongodb_settings`

    What changed: Approximately 35 new arguments have been added to the oracle_settings configuration block on aws_dms_endpoint, covering areas such as ASM connectivity (asm_password, asm_server, asm_user), secrets manager integration (secrets_manager_oracle_asm_access_role_arn, secrets_manager_oracle_asm_secret_id), path configuration (oracle_path_prefix, use_path_prefix, replace_path_prefix), and performance tuning (parallel_asm_read_threads, read_ahead_blocks, direct_path_parallel_load). Additionally, use_update_lookup has been added to mongodb_settings.

    Why this matters: Oracle source endpoints with ASM or complex replication topologies previously required out-of-band configuration or the DMS console. These additions bring parity with the DMS API for Oracle sources. The use_update_lookup flag in mongodb_settings affects how change data capture handles update events — a behavioral difference that could affect downstream consumers if toggled on existing endpoints.

    Migration steps:

  • For existing Oracle DMS endpoints, run terraform plan after upgrading to confirm no unexpected drift is detected from the new attributes defaulting differently than your current API state.
  • If using ASM, migrate credentials to Secrets Manager and reference them via secrets_manager_oracle_asm_access_role_arn and secrets_manager_oracle_asm_secret_id rather than inline.
  • For MongoDB endpoints, review whether use_update_lookup should be explicitly set to preserve existing CDC behavior.
  • Validate IAM permissions for any new Secrets Manager ARNs referenced in the endpoint configuration.
  • ---

    `aws_acmpca_certificate_authority` — `custom_path` in CRL Configuration

    What changed: A custom_path argument has been added to the revocation_configuration.crl_configuration block on both the aws_acmpca_certificate_authority resource and its corresponding data source.

    Why this matters: This allows specifying a custom S3 path for CRL distribution points, which is useful when CRL URLs need to match a specific public-facing path (e.g., behind a CDN or custom domain). Without this, the CRL path was determined entirely by AWS defaults.

    Migration steps:

  • Existing certificate authorities are unaffected unless you explicitly add custom_path.
  • If adopting custom_path, ensure the S3 bucket policy and any CloudFront or CDN configuration align with the new path before applying.
  • ---

    `aws_budgets_budget` — `filter_expression` Attribute

    What changed: A filter_expression attribute has been added to aws_budgets_budget.

    Why this matters: This attribute enables more granular cost filtering within budget definitions, going beyond the existing cost_filters approach. Teams with complex tagging strategies or multi-account setups may find this reduces the number of separate budget resources needed.

    Migration steps:

  • Existing budgets are unaffected; filter_expression is additive.
  • Review whether any current cost_filters configurations could be consolidated using the new attribute.
  • ---

    `aws_ecs_task_definition` — Resource Identity Support

    What changed: Resource identity support has been added to aws_ecs_task_definition.

    Why this matters: Resource identity enables Terraform to more reliably track and import ECS task definitions, reducing scenarios where plan output shows unexpected replacements or where terraform import required manual ARN construction.

    Migration steps:

  • Run terraform plan after upgrading to check for any identity-related drift on existing task definition resources.
  • If you maintain import scripts, verify they still function correctly with the updated identity handling.
  • ---

    `aws_lexv2models_intent` — `qna_intent_configuration`

    What changed: A qna_intent_configuration attribute has been added to aws_lexv2models_intent.

    Why this matters: This attribute exposes Q&A intent configuration for Lex V2 bots, enabling Terraform management of intents that leverage the QnA feature — previously only configurable via the console or SDK.

    Migration steps:

  • No action required for existing intents unless you want to adopt this configuration.
  • Import existing QnA intents and add the qna_intent_configuration block to bring them under Terraform management.
  • ---

    `aws_sagemaker_domain` — `domain_settings.trusted_identity_propagation_settings`

    What changed: The domain_settings block on aws_sagemaker_domain now accepts a trusted_identity_propagation_settings argument.

    Why this matters: Trusted identity propagation is relevant for SageMaker domains that integrate with IAM Identity Center, allowing user identity to flow through to downstream services. This was not previously configurable via the Terraform provider.

    Migration steps:

  • Existing domains are unaffected unless the argument is added.
  • Confirm IAM Identity Center is configured in your account before enabling this setting.
  • ---

    `aws_route53_records` — Nil Pointer Panic Fix

    What changed: A runtime error: invalid memory address or nil pointer dereference panic has been fixed when name_regex is set to an invalid regular expression in the aws_route53_records data source.

    Why this matters: Previously, an invalid regex in name_regex would cause a hard provider crash rather than a plan-time validation error, making it difficult to diagnose and potentially breaking CI pipelines mid-run.

    Migration steps:

  • No configuration changes are required.
  • If your pipelines have been catching panics from this data source, the fix should surface a proper error message instead going forward.
  • ---

    `aws_cur_report_definition` — New Valid `s3_region` Values

    What changed: ap-southeast-5 and eusc-de-east-1 are now accepted as valid values for the s3_region field on aws_cur_report_definition.

    Why this matters: Teams operating in the Malaysia (ap-southeast-5) or EUSC Germany East (eusc-de-east-1) regions were previously blocked from creating CUR report definitions targeting S3 buckets in those regions.

    Migration steps:

  • Update s3_region in any CUR report definitions targeting these regions.
  • Verify the S3 bucket exists in the target region and that the CUR service has the appropriate write permissions.
  • ---

    `aws_docdb_cluster` — `serverless_v2_scaling_configuration` Without Replacement

    What changed: Adding or modifying serverless_v2_scaling_configuration on aws_docdb_cluster no longer forces cluster replacement.

    Why this matters: Previously, any change to serverless scaling configuration triggered a destructive replacement of the entire DocumentDB cluster — a significant operational risk for production databases. This fix allows in-place updates.

    Migration steps:

  • Run terraform plan on any aws_docdb_cluster resources with serverless_v2_scaling_configuration after upgrading to confirm the plan no longer shows a replacement.
  • If you had previously avoided modifying this block due to the replacement risk, it is now safe to adjust scaling parameters in-place.
  • ---

    `aws_lb` — Load Balancer Attribute Batch Fix

    What changed: A ValidationError (Member must have length less than or equal to 20) has been fixed when modifying more than 20 load balancer attributes simultaneously on aws_lb.

    Why this matters: The AWS API enforces a 20-attribute limit per ModifyLoadBalancerAttributes call. The provider was not batching requests, causing failures for load balancers with many attributes configured — a scenario common in security-conscious or compliance-driven environments.

    Migration steps:

  • No configuration changes are needed.
  • If you have been working around this by splitting aws_lb resources or applying in stages, those workarounds can be removed after upgrading.
  • ---

    `aws_sagemaker_image_version` — Concurrent Creation Race Condition Fix

    What changed: A race condition when creating multiple aws_sagemaker_image_version resources concurrently has been resolved.

    Why this matters: Parallel terraform apply runs that create multiple image versions for the same SageMaker image could result in intermittent failures. This is particularly relevant in CI/CD pipelines with -parallelism set above 1.

    Migration steps:

  • No configuration changes are required.
  • Teams that added depends_on chains as a workaround for this race condition may want to evaluate whether those dependencies can be removed.
  • ---

    `aws_subnet` — IPAM `cidr_block` and IPv6 Netmask Fixes

    What changed: Two fixes land on aws_subnet. First, specifying a cidr_block when allocating a subnet from an IPAM resource pool is now supported. Second, a validation error (expected ipv6_netmask_length to be one of [44 48 52 56 60], got 64) has been corrected to allow /64 prefixes.

    Why this matters: The IPAM cidr_block restriction was preventing teams from requesting a specific CIDR within a pool rather than accepting an auto-assigned one. The IPv6 validation error was incorrectly rejecting /64, which is a standard and widely-used IPv6 subnet size.

    Migration steps:

  • For IPAM-managed subnets, you can now add an explicit cidr_block to request a specific allocation; verify the CIDR is available within the pool before applying.
  • For IPv6 subnets, update ipv6_netmask_length to 64 where appropriate without expecting a validation error.
  • Run terraform plan to confirm no unintended subnet replacements result from the validation change.
  • ---

    Before You Upgrade

    1. Run terraform plan against all environments after upgrading the provider to 6.33.0 and review the output carefully before applying — pay particular attention to aws_docdb_cluster and aws_ecs_task_definition resources where behavioral changes could surface as unexpected diffs.

    2. Check whether any aws_lb resources have more than 20 attributes configured:

    ```bash

    grep -r "aws_lb" . --include="*.tf" -l

    ```

    Then count attribute assignments in those files to confirm the fix is relevant to your setup.

    3. Validate all name_regex values in aws_route53_records data sources are valid Go regular expressions before upgrading, since the fix changes a panic into a proper error — you want to catch these before plan time:

    ```bash

    grep -r "name_regex" . --include="*.tf"

    ```

    4. For any aws_dms_endpoint resources using oracle_settings, run terraform plan and inspect for drift caused by newly tracked attributes defaulting to values that differ from your current API state.

    5. Confirm that aws_subnet resources using ipv6_netmask_length = 64 are not inadvertently marked for replacement due to the validation correction:

    ```bash

    grep -r "ipv6_netmask_length" . --include="*.tf"

    ```

    6. Review IAM policies for any roles used by aws_dms_endpoint Oracle configurations — the new secrets_manager_oracle_asm_access_role_arn argument requires Secrets Manager read permissions that may not be present in existing roles.

    7. For aws_sagemaker_image_version resources, check whether any depends_on workarounds were added to serialize concurrent creation; evaluate removing them after upgrading to avoid unnecessary serialization overhead.

    8. Verify that aws_cur_report_definition resources targeting ap-southeast-5 or eusc-de-east-1 have the correct S3 bucket policies in place before updating s3_region, since the provider change enables the configuration but the bucket permissions must be set independently.

    9. For aws_docdb_cluster resources with serverless_v2_scaling_configuration, take a manual snapshot before the first terraform apply post-upgrade as a precaution, even though the fix is intended to prevent replacement.

    10. Confirm the target instance types for any aws_launch_template or aws_instance resources where you plan to enable nested_virtualization — not all instance families support this feature, and applying it to an unsupported type will result in an API error.

    ---

    Sources & Timeline

    | Source | URL |

    |--------|-----|

    | Release v6.33.0 — HashiCorp Terraform AWS Provider | https://github.com/hashicorp/terraform-provider-aws/releases/tag/v6.33.0 |

    | Release v6.32.1 — HashiCorp Terraform AWS Provider | https://github.com/hashicorp/terraform-provider-aws/releases/tag/v6.32.1 |

    Last verified: 2026-02-22

    ```

    📎 Sources

    Terraform AWS Provider: 13 New Features in Networkmanager Attachment Routing Policy Label, Launch Template | Brief Stack