chore(deps): update terraform aws to v6.38.0

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
aws (source)	required_provider	minor	< 6.38 → < 6.39
aws (source)	required_provider	minor	6.37.0 → 6.38.0

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

hashicorp/terraform-provider-aws (aws)

v6.38.0

Compare Source

FEATURES:

• New Action: aws_dms_start_replication_task_assessment_run (#​47058)
• New Data Source: aws_dynamodb_backups (#​47036)
• New Data Source: aws_msk_topic (#​46490)
• New Data Source: aws_savingsplans_offerings (#​47081)
• New List Resource: aws_msk_cluster (#​46490)
• New List Resource: aws_msk_serverless_cluster (#​46490)
• New List Resource: aws_msk_topic (#​46490)
• New List Resource: aws_route53_resolver_rule (#​47063)
• New List Resource: aws_sagemaker_algorithm (#​47051)
• New List Resource: aws_ssm_document (#​46974)
• New List Resource: aws_ssoadmin_account_assignment (#​47067)
• New List Resource: aws_vpc_endpoint (#​46977)
• New List Resource: aws_workmail_domain (#​46931)
• New Resource: aws_msk_topic (#​46490)
• New Resource: aws_observabilityadmin_telemetry_enrichment (#​47089)
• New Resource: aws_sagemaker_algorithm (#​47051)
• New Resource: aws_workmail_default_domain (#​46931)
• New Resource: aws_workmail_domain (#​46931)

ENHANCEMENTS:

• data-source/aws_networkfirewall_firewall_policy: Add firewall_policy.enable_tls_session_holding attribute (#​47065)
• resource/aws_bedrockagentcore_agent_runtime: Add authorizer_configuration.custom_jwt_authorizer.custom_claim configuration block (#​47049)
• resource/aws_bedrockagentcore_gateway: Add authorizer_configuration.custom_jwt_authorizer.custom_claim configuration block (#​47049)
• resource/aws_bedrockagentcore_gateway_target: Add target_configuration.mcp.api_gateway configuration block (#​46916)
• resource/aws_dynamodb_table: Add restore_backup_arn argument (#​47068)
• resource/aws_fis_experiment_template: Support KinesisStreams as a value for action.target.key (#​47010)
• resource/aws_fis_experiment_template: Support VPCEndpoints as a value for action.target.key (#​47045)
• resource/aws_mq_broker: Change user block to Optional (#​46883)
• resource/aws_msk_cluster: Add resource identity support (#​46490)
• resource/aws_msk_serverless_cluster: Add resource identity support (#​46490)
• resource/aws_networkfirewall_firewall_policy: Add firewall_policy.enable_tls_session_holding argument (#​47065)
• resource/aws_securityhub_insight: Add filters.aws_account_name configuration block (#​47027)
• resource/aws_securityhub_insight: Add filters.compliance_associated_standards_id configuration block (#​47027)
• resource/aws_securityhub_insight: Add filters.compliance_security_control_id configuration block (#​47027)
• resource/aws_securityhub_insight: Add filters.compliance_security_control_parameters_name configuration block (#​47027)
• resource/aws_securityhub_insight: Add filters.compliance_security_control_parameters_value configuration block (#​47027)
• resource/aws_ssoadmin_account_assignment: Add Resource Identity support (#​47067)

BUG FIXES:

• resource/aws_api_gateway_method: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_apigatewayv2_integration: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_apigatewayv2_route: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_apigatewayv2_stage: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_appmesh_gateway_route: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_appmesh_route: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_appmesh_virtual_gateway: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_appmesh_virtual_node: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_appmesh_virtual_router: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_appmesh_virtual_service: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_cloudfront_distribution_tenant: Fix panic when managed certificate is not found during creation (#​46982)
• resource/aws_controltower_control: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_default_route_table: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_dx_gateway_association: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_dx_hosted_private_virtual_interface: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_dx_hosted_private_virtual_interface_accepter: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_dx_hosted_public_virtual_interface: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_dx_hosted_public_virtual_interface_accepter: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_dx_hosted_transit_virtual_interface: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_dx_hosted_transit_virtual_interface_accepter: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_dx_private_virtual_interface: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_dx_public_virtual_interface: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_dx_transit_virtual_interface: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_ecs_express_gateway_service: Fix Provider produced inconsistent result after apply error when environment variables are defined in non-alphabetical order (#​46771)
• resource/aws_elasticache_reserved_cache_node: Fix Provider returned invalid result object after apply errors where computed attributes remained unknown after create (#​47012)
• resource/aws_kinesis_stream: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_mq_broker: Fix non-idempotent behavior for RabbitMQ brokers with user block (#​46883)
• resource/aws_network_acl: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_network_interface_sg_attachment: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_opensearch_domain: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_route53recoverycontrolconfig_routing_control: Fix panic on concurrent creates when API returns ConflictException (#​47038)
• resource/aws_route_table_association: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_serverlessapplicationrepository_cloudformation_stack: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_servicecatalog_product: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_ses_active_receipt_rule_set: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_ssm_default_patch_baseline: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_vpc_dhcp_options_association: Fix import to honor @region suffix when using resource-level region attribute (#​47043)
• resource/aws_wafv2_web_acl_rule: Fix Unable to unmarshal DynamicValue error when statement.managed_rule_group_statement.rule_action_override block is specified (#​46998)
• resource/aws_wafv2_web_acl_rule_group_association: Fix WAFOptimisticLockException errors when multiple associations target the same Web ACL (#​47037)

---

Configuration

📅 Schedule: Branch creation - "before 10am on friday" in timezone Europe/London, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Open in Overmind ↗

---

model|risks_v6
✨Encryption Key State Risk ✨KMS Key Creation

🔴 Change Signals

Routine 🔴 ▇▅▃▂▁ Multiple API server resources showing unusual update activity at 1 event/week for the last 2-3 months, which is infrequent compared to typical patterns.

View signals ↗

---

🔥 Risks

Tip

✔ All risks disproven

We investigated 3 potential risks across 26 resources and verified each was safe. See the investigation details below.

---

🧠 Reasoning · ✔ 0 · ✖ 3

ALB target health and routing risk from EC2 instance lifecycle/network changes

Observations 7

Hypothesis

Changes to EC2 instance i-09d6479fb9b97d123 (stop/start, replacement, termination, or network/ENI change) can disrupt its role as a backend for the internet-facing ALB api-207c90ee-alb. The instance is registered in target group api-207c90ee-tg on port 80; lifecycle or networking changes can cause the target to fail health checks, be deregistered, or be routed differently, reducing capacity or causing traffic disruption. Instance placement or subnet changes could also affect network segmentation expectations. Recent plans update this instance while it is registered in the target group, with potential changes to its private IP (e.g., 10.0.102.33) and public IP reachability. If the instance is rebooted, replaced, or its IPs change without proper draining and re-registration, ALB target health may degrade and availability for external traffic through api-207c90ee-alb may be reduced. Risk is mitigated by pre-draining traffic, validating ALB target health before and after changes, ensuring the instance retains or cleanly transitions private IP and target registration, and confirming replacement instances are correctly registered and healthy on port 80 before cutover.

Investigation

Evidence Gathered

I first checked the relevant organizational guidance. aws-high-availability says to flag production ELB targets concentrated in a single AZ or changes that roll out to all instances simultaneously, and aws-network-security covers subnet placement and network-layer expectations. infrastructure-quick-reference also matters here because it explains that some infrastructure is intentionally test-like, but nothing in it changes the behavior of EC2 or ALB target registration.

I then examined the actual planned diffs for both changed EC2 instances in this PR. For 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123, the only shown change is public_dns and public_ip becoming (known after apply). The same exact pattern appears on 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa. There is no diff for private_ip, subnet, security groups, ENI attachment, instance ID, target group membership, or ALB/listener/rule/target group configuration. I also queried current blast-radius state for the changed instance, the other instance, the target group, target health, load balancer, ALB ENIs, subnet, and both relevant security groups/rules.

That current state shows i-09d6479fb9b97d123 is running in subnet subnet-07b5b1fb2ba02f964 with private IP 10.0.101.11, attached to security group sg-0b35287bf0a8a338c. The ALB api-207c90ee-alb is internet-facing across 2 AZs (eu-west-2a and eu-west-2b), and target group api-207c90ee-tg is configured for HTTP health checks on /health at port 80. The target-health object for i-09d6479fb9b97d123 reports the target is currently healthy. The API server security group still allows port 80 from the ALB security group, and none of those networking resources are changing in this plan.

Finally, I checked AWS documentation to verify what the surfaced public_ip/public_dns behavior means. AWS documents that on stop/start an EC2 instance keeps its private IPv4 address but may receive a new public IPv4 address unless an Elastic IP is attached. AWS also documents that reboot keeps the same public IP, while stop/start can change it. That matches Terraform showing these fields as computed or “known after apply” during provider refresh-style behavior, but it does not imply a private-IP or target-registration change. The ALB target group here is TargetType: instance, so it routes to the instance registration on port 80 inside the VPC rather than depending on the instance’s ephemeral public IP. (docs.aws.amazon.com)

Impact Assessment

Directly affected by the plan are 2 EC2 instances, but only 1 of them is in the ALB target group blast radius: i-09d6479fb9b97d123 (the API server). The ALB itself spans 2 AZs, but the target group currently shows only 1 registered backend target in the evidence returned, so if that instance were actually stopped long enough to fail health checks, external traffic through api-207c90ee-alb would lose all healthy backend capacity. That would be a high-impact failure mode.

However, the important question is whether this change really triggers that failure mode. The evidence says no. There is no planned change to the target group, target attachment, listener, subnet, ENIs, security groups, or the instance’s private IP. The only surfaced diff is on computed public-address fields. Because the ALB uses instance targets on port 80 and health-checks the instance over its VPC path, a recomputed or later-reassigned public IP does not by itself change ALB routing. The hypothesis mentions possible changes to private IP 10.0.102.33, but that IP belongs to an ALB ENI in eu-west-2b, not to the EC2 backend instance being updated. So the hypothesis is mixing ALB frontend ENI addresses with the backend instance’s address space.

Operationally, this means the feared outage scenario is not supported by the plan. If Terraform were actually replacing the instance, changing its subnet/ENI, or altering registration, I would expect explicit diffs on instance networking or on dependent ELB resources. Those are absent. The scope of the real change appears limited to provider-computed public IP/DNS values, with no demonstrated impact on the ALB-to-instance path.

Conclusion

I conclude the risk is not real for this change. The hypothesis correctly identifies that stopping or replacing a single registered backend could hurt availability, but the actual plan does not show any lifecycle, private-network, or target-registration change that would cause that outcome; it only shows recomputed public_ip/public_dns fields, which the ALB does not use for this instance-target routing path.

✖ Hypothesis disproven

---

EBS DeleteOnTermination on EC2 instance risking data loss on replacement

Observations 1

Hypothesis

EBS volume vol-090e750179b5fa681 is attached to EC2 instance i-09d6479fb9b97d123 with DeleteOnTermination=true. Any replacement or termination of the instance can automatically delete this volume, risking irreversible data loss if stateful data resides on it. The current plan shows the instance as updated with an empty diff, but the attachment metadata still enforces deletion on termination. Risk should be mitigated by disabling DeleteOnTermination where appropriate, snapshotting the volume, or migrating data to managed storage with explicit backup and lifecycle controls before any instance replacement.

Investigation

Evidence Gathered

I first checked the relevant organizational guidance for compute, data protection, storage/data management, and security/compliance. The storage guidance says to flag EBS volumes used for critical data without automated snapshot schedules, and the security guidance says EBS volumes must be encrypted. Those are real baseline findings in the current environment, but they are only actionable as change risks if this plan makes them worse or creates a path to failure.

I then inspected the planned changes for both EC2 instances in this PR. For 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123, the only diff is public_dns and public_ip changing from concrete values to (known after apply). The second instance has the same pattern. There is no force-replacement signal, no change to root_block_device, no AMI change, no subnet/ENI change, no instance type change, and no volume attachment change in the plan output that was provided or returned by planned-changes-query.

I queried the current blast-radius state for the instance and its attached volume. That confirmed vol-090e750179b5fa681 is the instance's root volume (/dev/xvda) and does currently have DeleteOnTermination: true. It also confirmed the volume is attached and healthy, and the EC2 instance is currently healthy and registered as a healthy ALB target on port 80. The same query showed the volume is unencrypted and was created from snapshot snap-0bb6bd2e6892b2ed1.

Finally, I checked AWS documentation. AWS documents that EBS volumes with DeleteOnTermination=true are deleted when the instance is terminated, and that root volumes default to this behavior unless explicitly changed. That validates the semantics of the attribute, but it does not by itself show that this Terraform change will terminate or replace the instance. (docs.aws.amazon.com)

Impact Assessment

Directly affected by this plan are 2 EC2 instances, including i-09d6479fb9b97d123. For the specific hypothesis, the potentially affected data resource is 1 EBS volume: 540044833068.eu-west-2.ec2-volume.vol-090e750179b5fa681, which is the 8 GiB root volume for the production api-207c90ee-api-server. Downstream, that instance is also one ALB target and is currently healthy, so an actual replacement would matter operationally. However, this change set does not show any replacement, termination, or root-volume reconfiguration for that instance.

The bad outcome in the hypothesis is irreversible data loss from automatic deletion of the root EBS volume during instance replacement. That outcome is real in general if someone later terminates or replaces this instance while stateful data lives on the root disk, because AWS will delete the volume when terminating an instance with DeleteOnTermination=true. (docs.aws.amazon.com) But for this specific PR, there is no evidence that Terraform will perform such a termination or replacement. The only planned diffs are computed public IP/DNS fields becoming unknown until apply, which is normal provider behavior and not evidence of instance recreation.

Conclusion

I conclude the risk is not real for this change. The investigation confirmed the root volume is indeed configured with DeleteOnTermination=true, but there is no supporting evidence in the planned diffs that this provider upgrade will replace or terminate i-09d6479fb9b97d123, so the hypothesized data-loss path is speculative rather than plan-backed.

✖ Hypothesis disproven

---

Endpoint/DNS and public identity churn from simultaneous EC2 instance updates

Observations 7

Hypothesis

A Terraform provider upgrade is simultaneously refreshing two public EC2 instances, recomputing their public_ip/public_dns attributes and potentially altering ENI/private IP assignments (e.g., 10.0.101.11) and associated DNS records (such as global.dns.ip-10-0-101-11...). This creates a broad runtime-contract risk: fixed references to these endpoints in DNS, firewall rules, partner allowlists, bastion/SSH paths, monitoring targets, and operational documentation may all become stale in one apply. Both instances can lose or change their public identities at the same time, eliminating redundant failover and complicating incident response, as monitoring and recovery tooling may lose both targets concurrently and operational runbooks or audit evidence keyed to the old public DNS names become invalid. Additionally, continuing to expose EC2 instances directly via public IPs/hostnames (e.g., 13.43.201.81 and 16.60.242.196) instead of stable managed endpoints (ALB/CloudFront) is a network-security anti-pattern and increases the blast radius of such changes by tying external reachability, DNS, and security posture directly to mutable instance identities. This reflects an anti-pattern of binding services, security controls, and observability to specific instance IPs/DNS instead of stable abstractions such as load balancers, Route 53 names, or centralized service identifiers. The environment should be reviewed to ensure no security groups, NACLs, partner ACLs, CloudWatch alarms, external health checks, incident-response scripts, or documentation rely on the current public or private addresses or per-instance DNS names for long-lived contracts, and that protective edge services (e.g., WAF/Shield) are used where appropriate.

Investigation

Evidence Gathered

I loaded the relevant organizational knowledge for network security, high availability, security compliance, and the local infrastructure notes before checking the resources. Those files matter here because the hypothesis is about mutable EC2 endpoints, public exposure, and whether direct instance identities are part of the runtime contract.

I then examined the planned diffs for both changed instances: 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123 and 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa. The only proposed changes are public_ip and public_dns changing from concrete values to (known after apply). There is no diff for private_ip, subnet, ENI attachment, security groups, Route 53 records, or load balancer resources.

From blast-radius state, the first instance (i-09d6479fb9b97d123) is the actual API server behind the ALB target group api-207c90ee-tg, with healthy target health on port 80. The ALB api-207c90ee-alb is internet-facing across 2 subnets/AZs and has its own stable public identities via ALB-managed ENIs and public DNS/IPs (13.43.201.81, 16.60.242.196). The instance security group only allows inbound port 80 from the ALB security group, not from the internet. The second changed instance (i-0464c4413cb0c54aa) is a separate public EC2 instance in the same subnet, not shown as an ALB target and not part of the API path described by the blast radius.

I also checked AWS documentation. AWS states that public IPv4 addresses change when an instance is stopped/started unless an Elastic IP is used, while the private IPv4 address is retained across stop/start for VPC instances. AWS and AWS Config guidance also treat direct public IP association on EC2 as undesirable and recommend stable managed front doors such as ELB rather than binding clients to instance public IPs. But the Terraform diff here does not show any stop/start-triggering attribute change, replacement, Elastic IP reassociation, ENI change, or DNS resource update. The (known after apply) values are provider-computed attributes, and your instructions explicitly say not to treat (known after apply) alone as risk without concrete evidence from the rest of the diff.

Impact Assessment

Directly affected by the Terraform plan are 2 EC2 instances. Of those, only 1 instance in the blast radius is currently serving traffic through the ALB target group: i-09d6479fb9b97d123. The public API entrypoint itself is not one of these instance public IPs; it is the ALB api-207c90ee-alb, which has 2 ALB-managed public endpoints across 2 Availability Zones. That means external user traffic should continue to resolve to and flow through the ALB, not to either instance’s ephemeral EC2 hostname.

The hypothesis’s main failure mode is simultaneous endpoint identity churn breaking fixed references in DNS, allowlists, monitoring, or runbooks. I did not find evidence of such references changing in this plan. No Route 53 records are being modified, no security group rules reference the instance public IPs, no NACLs are in scope, and no partner allowlist artifacts or monitoring resources in the blast radius point to these public identities. The only concrete downstream dependency visible is the ALB target group, and that dependency is instance-ID based, not public-IP or public-DNS based. Even if a stop/start were to occur, the first instance would keep its private IP according to AWS docs, and the ALB-to-instance path is inside the VPC on port 80 through security groups, not via the instance’s public identity.

There is a genuine architectural smell in the current environment: both changed EC2 instances have public IPs, which conflicts with organizational security guidance that EC2 instances must not be directly reachable from the internet. One of them is clearly behind an ALB already, so public exposure is unnecessary. However, that is an existing compliance issue, not a new failure introduced by this specific provider-upgrade change. The hypothesis asked whether this apply creates runtime breakage from identity churn, and the available evidence does not show that it does.

Conclusion

I conclude the hypothesized risk is not real for this change. The plan only recomputes provider-managed public_ip/public_dns fields with no accompanying infrastructure changes that would force endpoint churn, and the actual production traffic path uses a stable ALB rather than these per-instance public identities.

✖ Hypothesis disproven

---

💥 Blast Radius

Items 26

Edges 63

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Routine score (-5) is below minimum (-1)

---

📊 Signals Summary

Routine 🔴 -5

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

💥 Blast Radius

Items 26 · Edges 63

---

View full analysis in Overmind ↗