Skip to content

chore(deps): update terraform#514

Open
renovate[bot] wants to merge 1 commit intomainfrom
renovate/terraform
Open

chore(deps): update terraform#514
renovate[bot] wants to merge 1 commit intomainfrom
renovate/terraform

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate bot commented Mar 27, 2026

This PR contains the following updates:

Package Type Update Change
aws (source) required_provider minor < 6.38< 6.41
aws (source) required_provider minor 6.37.06.40.0
google (source) required_provider minor 7.25.07.27.0

Warning

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


Release Notes

hashicorp/terraform-provider-aws (aws)

v6.40.0

Compare Source

FEATURES:

  • New Data Source: aws_opensearchserverless_collection_group (#​46308)
  • New Data Source: aws_opensearchserverless_collection_groups (#​46308)
  • New Data Source: aws_s3files_access_point (#​47352)
  • New Data Source: aws_s3files_file_system (#​47344)
  • New Data Source: aws_s3files_file_systems (#​47344)
  • New Data Source: aws_s3files_mount_target (#​47347)
  • New List Resource: aws_config_config_rule (#​47319)
  • New List Resource: aws_glue_job (#​47266)
  • New List Resource: aws_opensearchserverless_collection_group (#​46308)
  • New List Resource: aws_s3files_access_point (#​47352)
  • New List Resource: aws_s3files_file_system (#​47325)
  • New List Resource: aws_s3files_file_system_policy (#​47355)
  • New List Resource: aws_s3files_mount_target (#​47347)
  • New List Resource: aws_s3files_synchronization_configuration (#​47353)
  • New List Resource: aws_ssm_association (#​47321)
  • New List Resource: aws_ssm_patch_group (#​47329)
  • New Resource: aws_opensearchserverless_collection_group (#​46308)
  • New Resource: aws_s3files_access_point (#​47352)
  • New Resource: aws_s3files_file_system (#​47325)
  • New Resource: aws_s3files_file_system_policy (#​47355)
  • New Resource: aws_s3files_mount_target (#​47347)
  • New Resource: aws_s3files_synchronization_configuration (#​47353)
  • New Resource: aws_servicequotas_auto_management (#​45968)

ENHANCEMENTS:

  • data-source/aws_msk_cluster: Add broker_node_group_info.connectivity_info.network_type attribute (#​47279)
  • resource/aws_cloudformation_stack_set: Add depends_on_stack_sets to auto_deployment configuration block (#​47269)
  • resource/aws_config_config_rule: Add Resource Identity support (#​47286)
  • resource/aws_config_configuration_aggregator: Add Resource Identity support (#​47286)
  • resource/aws_config_configuration_recorder: Add Resource Identity support (#​47286)
  • resource/aws_config_configuration_recorder_status: Add Resource Identity support (#​47286)
  • resource/aws_config_conformance_pack: Add Resource Identity support (#​47286)
  • resource/aws_config_delivery_channel: Add Resource Identity support (#​47286)
  • resource/aws_config_organization_conformance_pack: Add Resource Identity support (#​47286)
  • resource/aws_config_organization_custom_policy_rule: Add Resource Identity support (#​47286)
  • resource/aws_config_organization_custom_rule: Add Resource Identity support (#​47286)
  • resource/aws_config_organization_managed_rule: Add Resource Identity support (#​47286)
  • resource/aws_config_remediation_configuration: Add Resource Identity support (#​47286)
  • resource/aws_config_retention_configuration: Add Resource Identity support (#​47286)
  • resource/aws_controltower_landing_zone: Add remediation_types attribute (#​46549)
  • resource/aws_glue_job: Add Resource Identity support (#​47266)
  • resource/aws_iam_instance_profile: Add resource identity support (#​47307)
  • resource/aws_kinesisanalyticsv2_application: Support FLINK-2_2 as a valid value for runtime_environment (#​47207)
  • resource/aws_msk_cluster: Add broker_node_group_info.connectivity_info.network_type argument (#​47279)
  • resource/aws_opensearchserverless_access_policy: Add Resource Identity support (#​47262)
  • resource/aws_opensearchserverless_lifecycle_policy: Add Resource Identity support (#​47262)
  • resource/aws_opensearchserverless_security_config: Add Resource Identity support (#​47262)
  • resource/aws_opensearchserverless_security_policy: Add Resource Identity support (#​47262)
  • resource/aws_opensearchserverless_vpc_endpoint: Add Resource Identity support (#​47262)
  • resource/aws_s3control_storage_lens_configuration: Add storage_lens_configuration.data_export.storage_lens_table_destination argument (#​47152)
  • resource/aws_ssm_patch_group: Add resource identity support (#​47318)

BUG FIXES:

  • resource/aws_bcmdataexports_export: Allows empty values in export.data_query.table_configurations (#​47261)
  • resource/aws_cloudwatch_log_metric_filter: Fix validation to count pattern length in UTF-8 characters (#​47287)
  • resource/aws_config_configuration_recorder_status: Mark name as as ForceNew (#​47286)
  • resource/aws_organizations_account: Fix AccountAlreadyClosedException error when deleting an account that has already been closed with close_on_deletion set to true (#​46627)
  • resource/aws_s3_bucket_server_side_encryption_configuration: Change rule.apply_server_side_encryption_by_default.kms_master_key_id, rule.blocked_encryption_types, and rule.bucket_key_enabled to Optional and Computed, preventings diffs once SSE-C is disabled for all new general purpose buckets (#​47359)
  • resource/aws_uxc_account_customizations: Fix inconsistent result error when visible_regions or visible_services is set to an explicit empty set ([]) (#​47290)

v6.39.0

Compare Source

NOTES:

  • data-source/aws_eks_access_entry: The tags_all attribute is deprecated and will be removed in a future major version (#​47133)

FEATURES:

  • New Data Source: aws_iam_role_policies (#​46936)
  • New Data Source: aws_iam_role_policy_attachments (#​47119)
  • New Data Source: aws_networkmanager_core_network (#​45798)
  • New Data Source: aws_uxc_services (#​47115)
  • New List Resource: aws_eks_cluster (#​47133)
  • New List Resource: aws_organizations_aws_service_access (#​46993)
  • New List Resource: aws_sagemaker_training_job (#​46892)
  • New List Resource: aws_workmail_group (#​47131)
  • New List Resource: aws_workmail_user (#​47131)
  • New Resource: aws_organizations_aws_service_access (#​46993)
  • New Resource: aws_sagemaker_training_job (#​46892)
  • New Resource: aws_uxc_account_customizations (#​47115)
  • New Resource: aws_workmail_group (#​47131)
  • New Resource: aws_workmail_user (#​47131)

ENHANCEMENTS:

  • data-source/aws_outposts_asset: Add instance_families attribute (#​47153)
  • resource/aws_eks_cluster: Add resource identity support (#​47133)
  • resource/aws_eks_cluster: Support tier-8xl as a valid value for control_plane_scaling_config.tier (#​46976)
  • resource/aws_network_acl_rule: Add Resource Identity support (#​47090)
  • resource/aws_observabilityadmin_centralization_rule_for_organization: Add source.source_logs_configuration.data_source_selection_criteria argument. Change source.source_logs_configuration.log_group_selection_criteria to Optional (#​47154)
  • resource/aws_prometheus_scraper: Add source.vpc argument. Change source.eks to Optional (#​47155)
  • resource/aws_s3_bucket_metric: Support bucket metrics for directory buckets (#​47184)
  • resource/aws_s3control_storage_lens_configuration: Add storage_lens_configuration.account_level.advanced_performance_metrics and storage_lens_configuration.account_level.bucket_level.advanced_performance_metrics arguments (#​46865)

BUG FIXES:

  • data-source/aws_eks_access_entry: Fixed tags not being returned (#​47133)
  • data-source/aws_service_principal: Fix service principal names for EC2 and S3 in the aws-cn partition (#​47141)
  • resource/aws_config_organization_conformance_pack: Fix creation timeout when using a delegated administrator account (#​47072)
  • resource/aws_dynamodb_table: Fix Error: waiting for creation AWS DynamoDB Table (xxxxx): couldn't find resource in highly active accounts by restoring 5s delay before polling for table status. This fixes a regression introduced in v6.28.0. (#​47143)
  • resource/aws_eks_cluster: Set bootstrap_self_managed_addons to true when importing (#​47133)
  • resource/aws_elasticache_serverless_cache: Fix InvalidParameterCombination error when cache_usage_limits is removed (#​46134)
  • resource/aws_glue_catalog_table: Detect and report failed view creation (#​47101)

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)
hashicorp/terraform-provider-google (google)

v7.27.0

Compare Source

v7.26.0

Compare Source

BREAKING CHANGES:

  • compute: Removed google_compute_region_backend_bucket from the google (GA) provider. It is currently beta-only, and calls to the nonexistent GA API always returned a 404. Until released in google, use google-beta instead. (#​26597)

FEATURES:

  • New Data Source: google_network_security_address_groups (#​26562)
  • New Data Source: google_iam_workload_identity_pool_iam_policy (#​26598)
  • New Resource: google_bigqueryreservation_reservation_group (#​26560)
  • New Resource: google_compute_region_composite_health_check (#​26591)
  • New Resource: google_compute_region_health_aggregation_policy (#​26591)
  • New Resource: google_compute_region_health_source (#​26591)
  • New Resource: google_contact_center_insights_assessment_rule (#​26530)
  • New Resource: google_iam_workload_identity_pool_iam_* (#​26598)
  • New Resource: google_workstations_workstation (#​26561)
  • New Resource: google_workstations_workstation_iam_* (#​26561)
  • New Resource: google_workstations_workstation_cluster (#​26561)
  • New Resource: google_workstations_workstation_config (#​26561)
  • New Resource: google_workstations_workstation_config_iam_* (#​26561)

IMPROVEMENTS:

  • bigqueryreservation: added reservation_group field to google_bigquery_reservation resource (#​26560)
  • ces: added remote_dialogflow_agent.respect_response_interruption_settings field to google_ces_agent resource (#​26578)
  • clusterdirector: made boot_disk.size_gb and boot_disk.type editable within nodesets and login nodes in google_hypercomputecluster_cluster (#​26615)
  • colab: added colab_image field to google_colab_runtime_template resource (#​26582)
  • colab: made google_colab_runtime_template resource updatable (#​26582)
  • compute: added hyperdisk-balanced as an option for disk_type field in google_container_cluster resource (#​26581)
  • compute: made backend_service field optional for google_compute_target_tcp_proxy resource (#​26519)
  • compute: promoted resolve_subnet_field field in google_compute_subnetwork resource to GA (#​26570)
  • iambeta: promoted mode, inline_certificate_issuance_config, and inline_trust_config fields in google_iam_workload_identity_pool resource to GA (#​26598)
  • spanner: added autoscaling config for instance partition and missing asymmetric autoscaling override fields to google_spanner_instance resource (#​26577)
  • sql: added server_certificate_rotation_mode field to google_sql_database_instance resource (#​26572)
  • storage: added google_managed_encryption_enforcement_config, customer_managed_encryption_enforcement_config and customer_supplied_encryption_enforcement_config to google_storage_bucket resource (#​26529)

BUG FIXES:

  • alloydb: fixed an issue where password_wo and password_wo_version fields were not functioning properly during update requests in google_alloydb_user resource (#​26571)
  • biglake: fixed erroneous diff for the properties field in the google_biglake_iceberg_table and google_biglake_iceberg_namespace resources (#​26595)
  • cloudfunctionsv2: fixed validation to only allow one of direct_vpc_network_interface or vpc_connector on google_cloudfunctions2_function resource (#​26567)
  • cloudrunv2: fixed validation to only allow one of network_interfaces or connector on google_cloud_run_v2_service and google_cloud_run_v2_job resources (#​26567)
  • compute: fixed google_compute_region_backend_bucket being present in the google (GA) provider. It is currently beta-only, and calls to the nonexistent GA API always returned a 404. (#​26597)
  • compute: fixed invalid update mask used for rate_limit_options field in google_compute_region_security_policy_rule resource (#​26527)
  • compute: fixed invalid update mask used for rate_limit_options field in google_compute_security_policy and google_compute_security_policy_rule resources (#​26526)
  • iambeta: fixed a perma-diff on mode field for google_iam_workload_identity_pool resource (#​26601)
  • provider: fixed an issue when custom endpoints use http:// (#​26600)
  • vertexai: fixed operation calls in google_vertex_ai_ resources not respecting universe_domain and vertex_custom_endpoint (#​26556)

Configuration

📅 Schedule: (in timezone Europe/London)

  • Branch creation
    • "before 10am on friday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

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

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


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

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

@renovate renovate bot added dependencies Renovatebot and dependabot updates terraform labels Mar 27, 2026
@renovate renovate bot enabled auto-merge (squash) March 27, 2026 00:52
@github-actions
Copy link
Copy Markdown

github-actions bot commented Mar 27, 2026

Open in Overmind ↗


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

🔴 Change Signals

Routine 🔴 ▇▅▃▂▁ Multiple AWS compute and related resources showing unusual infrequent changes at 1-2 events/week for the last 2-3 months, with one load balancer attachment at 1 event/week for the last 7 weeks and one monitoring alarm at 1 event/week for the last 2 months, which is infrequent compared to typical patterns.
Policies 🔴 ▃▂▁ S3 bucket 'aws_s3_bucket.terraform-example-state-bucket' is missing required tags and server-side encryption, and security group allows SSH access from anywhere, which is unusual compared to typical patterns.

View signals ↗


🔥 Risks

Replacement API server will remain directly exposed to the internet with SSH open to the world ‼️High Open Risk ↗
The change replaces the public EC2 API server 540044833068.eu-west-2.ec2-instance.i-0ef4bfdd45730e71d with a new AMI and different user_data while preserving the same internet-facing design. Blast-radius state shows the current instance is launched with a public IP, attached to security group sg-0437857de45b640ce, and that group allows both SSH (22) and HTTP (80) from 0.0.0.0/0. The instance also has no IAM instance profile and still allows IMDSv1 because http_tokens is optional, so the replacement is keeping a directly reachable host with weak access hardening instead of moving it behind a managed edge or private access path.

When this replacement deploys, the new instance will inherit the same direct exposure while changing the AMI and bootstrap configuration at the same time. That creates a real compromise risk: attackers can continue to reach SSH and web ports from the internet, and any mistake or regression in the new image or startup script will be exposed immediately on a public endpoint. This violates the org requirement that EC2 instances must not be directly internet-reachable and that SSH must never be open to 0.0.0.0/0.


🧠 Reasoning · ✔ 1 · ✖ 3

Internet-exposed EC2 instances and permissive security posture increase compromise risk

Observations 2

Hypothesis

An EC2 instance (i-0c326c28fef2cb7ee) has a public IP (13.134.236.98) directly attached and reachable from the internet. Another instance (i-0ef4bfdd45730e71d) uses an AMI update (ami-09ce8939d5ab2791d) and modified user_data while retaining a security group that allows SSH and HTTP from 0.0.0.0/0. Exposing instances directly to the internet instead of via a load balancer/CDN and maintaining permissive inbound rules significantly increase attack surface, may lack WAF/Shield and centralized protections, and can introduce unpatched or insufficiently hardened images. These factors raise the likelihood of compromise via direct network access or insecure OS/application configurations.

Investigation

I treated the concern area as security exposure and compromise risk for internet-reachable EC2 instances. Per the required org knowledge, I checked the compute, network security, IAM, security compliance, and infrastructure quick-reference documents before evaluating evidence. Those documents are explicit that EC2 instances must not be directly reachable from the internet, that SSH from 0.0.0.0/0 is prohibited, and that a public IP plus an open security group is critical severity. They also note shared security groups can have high fanout, though in the blast-radius evidence here I only confirmed the specific internet-access security group on the replaced instance.

The key question is whether this change introduces or preserves the risky exposure, rather than merely describing an existing condition. The blast-radius state confirms that 540044833068.eu-west-2.ec2-instance.i-0ef4bfdd45730e71d currently has associate_public_ip_address=true, public IP 13.40.27.201, no IAM instance profile, metadata http_tokens=optional, and security group sg-0437857de45b640ce, which allows both TCP/80 and TCP/22 from 0.0.0.0/0. The planned diff for that instance is a replacement to a new AMI with modified user_data, but it does not remove the public association or indicate any tightening of the attached security groups; those fields become computed because the instance is being replaced, not because the exposure is being removed. Separately, the blast radius confirms 540044833068.eu-west-2.ec2-instance.i-0c326c28fef2cb7ee currently has the elastic IP 13.134.236.98 attached directly to its ENI, so the hypothesis is directionally correct that another instance is directly internet-addressable, but that instance itself is not the main changed resource in this plan. The ec2-address.13.134.236.98 diff only shows the association becoming recomputed during apply, which by itself is not evidence of a new or worsening security control failure.

I also checked AWS documentation to verify the semantics around metadata hardening and SSH exposure. AWS documents that http_tokens=optional permits IMDSv1 as well as IMDSv2, while required enforces IMDSv2 only, and AWS prescriptive guidance says unrestricted ingress to SSH from 0.0.0.0/0 should be avoided in favor of Session Manager. That means the replaced instance is not only publicly reachable on SSH and HTTP, but also lacks two common hardening controls: enforced IMDSv2 and an IAM instance profile for SSM-based access. This is strong evidence that the change perpetuates an insecure posture on the new instance rather than fixing it.

I decided the risk is real because the planned replacement keeps the same attack surface in place while introducing a new AMI and new bootstrap script, so any hardening assumptions tied to the old image or old user_data are being discarded without removing direct internet reachability. This is not speculative: the current instance is directly reachable, the security group is permissive, the org policy explicitly forbids this pattern, and nothing in the change diff shows the issue being corrected. The specific bad outcome is increased likelihood of host compromise through direct internet access to the replacement API server.

✔ Hypothesis proven


Load balancer target group replacement risks deregistration, failed health checks, and outages

Observations 20

Hypothesis

Multiple ELBv2 target groups for the API health path, including the ALB/NLB target group 'api-health-terraform-example', are being replaced. Across ALB and NLB usage, replacement can change target registrations, health check configuration, target group attributes, and ARNs, impacting:

  • Internal NLB 'mon-internal-terraform-example' routing and health checks for backend instances (e.g., IP 10.50.101.182, ENIs such as eni-0528.. / 10.50.102.66)
  • Internet-facing ALB routing to IP targets such as 10.0.101.106:9090 and other private IPs (e.g., 10.0.101.211 / eni-0714cc06176804efa)
    During replacement, targets may be deregistered or briefly absent, causing failed health checks, disrupted listener forwarding, and outages for public and internal APIs. This can interrupt monitoring and health scraping and affect client traffic allowed via security groups such as sg-03cf38efd953aa056. Mis-coordinated changes can force traffic directly to EC2 instances or bypass intended load balancing and protection layers, violating network segmentation and reliability best practices.

Investigation

I investigated the concern area as potential API and monitoring traffic interruption caused by ELB target group replacement. Per the required process, I first checked relevant organizational guidance: aws-high-availability, aws-network-security, and infrastructure-quick-reference. Those documents confirm that load balancer changes should be treated cautiously, especially for production reliability, but they do not establish that any target group replacement is inherently outage-causing.

I then examined the planned changes for the three directly relevant resources: 540044833068.eu-west-2.elbv2-target-group.api-health-terraform-example, 540044833068.eu-west-2.elbv2-target-group.api-207c90ee-tg, and github.com/overmindtech/terraform-example.aws_lb_target_group_attachment.module.api_server.aws_lb_target_group_attachment.api[0]. All three are marked as replaced, but the plan data available here contains no attribute-level diff showing a port, protocol, health check, target type, or listener action mismatch. Because the hypothesis depends on a specific bad replacement mechanism, the absence of any concrete before/after configuration change matters.

I used blast radius data to validate current state. The internal NLB target group api-health-terraform-example is currently TCP on port 9090, target type ip, attached to the internal NLB mon-internal-terraform-example, and its sampled target health for 10.0.101.106:9090 is currently healthy. The public ALB target group api-207c90ee-tg is an HTTP instance target group with health checks on /health, and the ALB itself spans two AZs. That means the current configuration is coherent and healthy; I found no evidence of an existing fragility like failed health checks, wrong ports, or missing multi-AZ coverage.

I also checked AWS/Terraform documentation. AWS documents that listeners can be updated to forward to a new target group ARN, and for NLBs existing active connections remain associated to the original target group for a period while new connections are routed to the new one. Terraform lifecycle documentation also shows that replacement does not automatically imply destroy-before-create; create_before_destroy can preserve dependencies. Since the plan provided here does not show any listener replacement, rule replacement, or explicit destroy-before-create sequencing, I do not have strong evidence that traffic will ever be forwarded to an empty target group or that targets will be absent long enough to cause an outage.

So the hypothesis identifies a plausible concern area, but the evidence in this specific change is weak and speculative. I found no concrete configuration mismatch, no demonstrated dangling reference, no listener/rule mis-coordination in the visible plan, and no sign that the change removes the protections currently in place. Because active investigation did not uncover a specific outage mechanism beyond generic fear of target group replacement, I conclude the risk is not proven for this change.

✖ Hypothesis disproven


EC2 lifecycle changes impacting IAM trust, role usage, and private IP–based networking assumptions

Observations 36

Hypothesis

EC2 instances are experiencing lifecycle and identity changes that may affect IAM and networking guarantees:

  • Instance i-08c49ffb6f2242b1e is updated with associated instance profiles in multiple regions (e.g., api-207c90ee-api-profile, ovm-scale-us-east-1-p32ws0nl-ec2-profile, ovm-scale-us-west-2-p32ws0nl-ec2-profile, ovm-scale-eu-west-1-p32ws0nl-ec2-profile, ovm-scale-ap-southeast-1-p32ws0nl-ec2-profile) that grant roles such as api-207c90ee-api-role and ovm-scale-*-p32ws0nl-ec2-role with AmazonSSMManagedInstanceCore and other permissions. Even when Terraform diffs appear empty, instance replacement or modification can change or detach these ec2-iam-instance-profile-associations, breaking the instance’s ability to assume its roles. This can remove SSM permissions and other AWS API access used for management, patching, automation, and monitoring, leading to loss of Systems Manager connectivity and operational visibility. Changes to role attachments or trust policies without review also risk deviating from least-privilege and role-assumption controls.
  • Instance i-0ef4bfdd45730e71d is being replaced with a new AMI, which may change or detach its primary private IP (10.0.101.211). If DNS records, security rules, or other services rely on this specific IP, replacement can silently break internal name resolution and connectivity.
    Without verifying instance-profile associations, tightening IAM trust conditions, and avoiding brittle dependencies on fixed private IPs, instance replacement or profile changes can lead to loss of management access, unauthorized role assumption, and unexpected connectivity failures.

Investigation

I investigated the two concern areas in the hypothesis separately: IAM/profile continuity and breakage caused by private-IP-dependent networking. I first checked the relevant organizational knowledge. The IAM guidance says to flag broad or weakened trust policies and least-privilege regressions, and the network/compliance guidance says brittle public exposure and unsafe network changes are risks. None of the planned diffs change IAM roles, instance profiles, trust policies, security groups, or route/DNS resources. The only EC2 diffs shown are AMI replacement for 540044833068.eu-west-2.ec2-instance.i-0ef4bfdd45730e71d and computed public IP/DNS churn for 540044833068.eu-west-2.ec2-instance.i-08c49ffb6f2242b1e.

For IAM: current blast-radius state shows i-08c49ffb6f2242b1e is associated with instance profile api-207c90ee-api-profile, and that profile contains role api-207c90ee-api-role with a standard EC2 trust policy. There is no planned change to the instance profile, the role, or the association resource. The other instance, i-0ef4bfdd45730e71d, currently has no IAM instance profile at all, so this change cannot break SSM or API permissions on that instance by detaching a profile that is not present. AWS documentation also indicates that IAM profile changes are explicit attach/replace/detach operations; there is no evidence of such an operation in this plan. So the hypothesis’s IAM mechanism is unsupported.

For networking/IP stability: the replaced instance i-0ef4bfdd45730e71d currently has private IP 10.0.101.211 and AWS-provided private DNS ip-10-0-101-211.eu-west-2.compute.internal. AWS documentation confirms that the private DNS hostname corresponds to the instance’s private IPv4 address, and Terraform documentation confirms that replacement causes IP/hostname values to become unknown until apply because the new instance may get different values. However, in this plan there is no Route 53/private DNS record, security-group rule, target group attachment, or other planned resource that hard-codes 10.0.101.211. The only DNS object in blast radius for that name is the AWS-generated internal hostname that automatically tracks the instance address. Since no user-managed dependency on the fixed private IP is being changed or referenced here, the claim that replacement will silently break consumers relying on that IP remains speculative.

I also checked adjacent planned resources. The Elastic IP 13.134.236.98 is attached to a different instance (i-0c326c28fef2cb7ee), not to the replaced i-0ef4bfdd45730e71d. The api-207c90ee target group is a separate ALB target group for the profiled instance and does not establish a dependency on 10.0.101.211. In short, the change does replace one instance and therefore may change its private IP, but I found no concrete evidence in the plan or current state that IAM trust/profile usage or private-IP-based networking assumptions will fail because of this specific change. The hypothesis points to a real class of risk in general, but not a confirmed risk in this plan.

✖ Hypothesis disproven


SNS production alerts sent to external email may leak sensitive information

Observations 1

Hypothesis

A new SNS email subscription is being created for the 'production-api-alerts' topic in eu-west-2 with endpoint alerts@example.com. Sending operational or security alerts to an external email address risks leaking sensitive information if the address is incorrect, shared outside the organization, or not governed by internal controls. Inadequate topic policy restrictions or unredacted alert content can further expose internal architecture details, incident data, or credentials over email.

Investigation

I investigated the concern area as a potential sensitive-information leak via a new external SNS email subscription. I first checked relevant organizational guidance. The available IAM/access-control guidance focuses on overly broad resource policies, public access, and least privilege; the monitoring guidance focuses on ensuring alarms have SNS targets; and the security compliance document focuses on encryption, network exposure, and key management. None of these documents define a blanket prohibition on email subscriptions to SNS topics or require internal-only endpoints for alerting.

I then checked the current state of the affected SNS topic and related alarms. The existing topic 540044833068.eu-west-2.sns-topic.arn:aws:sns:eu-west-2:540044833068:production-api-alerts currently has the default SNS topic policy, which uses AWS:SourceOwner = 540044833068. That policy does include actions such as SNS:Subscribe and SNS:Publish for Principal: "*", but the AWS:SourceOwner condition restricts those actions to requests originating from the same AWS account, so this is not public topic access. I also checked the alarms in blast radius: the CloudWatch alarms shown are publishing to a different SNS topic, arn:aws:sns:eu-west-2:540044833068:api-207c90ee-alerts, not to production-api-alerts. That means the hypothesis overstates the immediate blast radius because there is no evidence from the inspected alarms that production operational alerts are currently routed through the topic receiving the new email subscription.

I verified SNS/Terraform behavior against documentation as well. The Terraform aws_sns_topic_subscription resource for protocol = "email" simply creates an email endpoint subscription, and AWS SNS requires a confirmation step before the subscription becomes active. The proposed resource has endpoint_auto_confirms = false, which is consistent with standard SNS email confirmation behavior. So the change does not immediately begin delivering messages to an arbitrary unverified inbox at apply time; the recipient must confirm first.

There is still a governance concern in the abstract: if someone confirms an external mailbox and the topic later carries sensitive content, email could expose that content outside tightly controlled systems. But the available evidence is not strong enough to classify this as a real infrastructure risk for this specific change. I found no org policy forbidding it, no public or cross-account topic policy misconfiguration, no evidence that this topic currently carries the inspected production alarms, and no indication that Terraform is bypassing SNS confirmation safeguards. This remains a speculative security concern rather than a demonstrated risk in the current plan.

✖ Hypothesis disproven


💥 Blast Radius

Items 152

Edges 824

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ 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 ↗

@renovate renovate bot force-pushed the renovate/terraform branch from ba884cb to 12213ca Compare March 31, 2026 20:58
@renovate renovate bot changed the title chore(deps): update terraform aws to v6.38.0 chore(deps): update terraform Mar 31, 2026
@renovate renovate bot force-pushed the renovate/terraform branch from 12213ca to 97c66a8 Compare April 1, 2026 23:30
Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ Auto-Blocked


🔴 Decision

Found 4 high risks requiring review


📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3


🔥 Risks Summary

High 4 · Medium 0 · Low 0


💥 Blast Radius

Items 138 · Edges 201


View full analysis in Overmind ↗

@renovate renovate bot force-pushed the renovate/terraform branch from 97c66a8 to 602c793 Compare April 7, 2026 21:51
Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ Auto-Blocked


🔴 Decision

Auto-blocked: Policy signal (-3) is below threshold (-2); Routine score (-5) is below minimum (-1)


📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3


🔥 Risks Summary

High 0 · Medium 2 · Low 0


💥 Blast Radius

Items 132 · Edges 252


View full analysis in Overmind ↗

@renovate renovate bot force-pushed the renovate/terraform branch from 602c793 to 0f43049 Compare April 9, 2026 00:33
Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ Auto-Blocked


🔴 Decision

Found 1 high risk requiring review


📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3


🔥 Risks Summary

High 1 · Medium 0 · Low 0


💥 Blast Radius

Items 152 · Edges 824


View full analysis in Overmind ↗

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Renovatebot and dependabot updates terraform

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants