chore(deps): update javascript by renovate[bot] · Pull Request #451 · overmindtech/terraform-example

renovate · 2026-01-16T01:48:33Z

This PR contains the following updates:

Package	Change	Age	Confidence
@eslint/js (source)	`9.39.2` → `9.39.4`
@types/node (source)	`22.19.11` → `22.19.15`
autoprefixer	`10.4.24` → `10.4.27`
eslint (source)	`9.39.2` → `9.39.4`
postcss (source)	`8.5.6` → `8.5.8`
react-hook-form (source)	`7.71.1` → `7.71.2`
typescript-eslint (source)	`8.56.0` → `8.56.1`

Release Notes

eslint/eslint (@eslint/js)

`v9.39.4`

Compare Source

`v9.39.3`

Compare Source

Bug Fixes

791bf8d fix: restore TypeScript 4.0 compatibility in types (#20504) (sethamus)

Chores

8594a43 chore: upgrade @eslint/js@9.39.3 (#20529) (Milos Djermanovic)
9ceef92 chore: package.json update for @eslint/js release (Jenkins)
af498c6 chore: ignore /docs/v9.x in link checker (#20453) (Milos Djermanovic)

postcss/autoprefixer (autoprefixer)

`v10.4.27`

Compare Source

Removed development key from package.json.

`v10.4.26`

Compare Source

Reduced package size.

`v10.4.25`

Compare Source

Fixed broken gradients on CSS Custom Properties (by @serger777).

eslint/eslint (eslint)

`v9.39.4`

Compare Source

Bug Fixes

f18f6c8 fix: update dependency minimatch to ^3.1.5 (#20564) (Milos Djermanovic)
a3c868f fix: update dependency @eslint/eslintrc to ^3.3.4 (#20554) (Milos Djermanovic)
234d005 fix: minimatch security vulnerability patch for v9.x (#20549) (Andrej Beles)
b1b37ee fix: update ajv to 6.14.0 to address security vulnerabilities (#20538) (루밀LuMir)

Documentation

4675152 docs: add deprecation notice partial (#20520) (Milos Djermanovic)

Chores

b8b4eb1 chore: update dependencies for ESLint v9.39.4 (#20596) (Francesco Trotta)
71b2f6b chore: package.json update for @eslint/js release (Jenkins)
1d16c2f ci: pin Node.js 25.6.1 (#20563) (Milos Djermanovic)

`v9.39.3`

Compare Source

Bug Fixes

791bf8d fix: restore TypeScript 4.0 compatibility in types (#20504) (sethamus)

Chores

8594a43 chore: upgrade @eslint/js@9.39.3 (#20529) (Milos Djermanovic)
9ceef92 chore: package.json update for @eslint/js release (Jenkins)
af498c6 chore: ignore /docs/v9.x in link checker (#20453) (Milos Djermanovic)

postcss/postcss (postcss)

`v8.5.8`

Compare Source

Fixed Processor#version.

`v8.5.7`

Compare Source

Improved source map annotation cleaning performance (by CodeAnt AI).

react-hook-form/react-hook-form (react-hook-form)

`v7.71.2`: Version 7.71.2

Compare Source

🕵️‍♂️ fix: use DeepPartialSkipArrayKey for WatchObserver value parameter (#13278)
🧹 fix(clearErrors): emit name signal for targeted field updates (#13280)

thanks to @veeceey, @kaigritun, @pgoslatara & @seongbiny

typescript-eslint/typescript-eslint (typescript-eslint)

`v8.56.1`

Compare Source

This was a version bump only for typescript-eslint to align it with other projects, there were no code changes.

See GitHub Releases for more information.

You can read about our versioning strategy and releases on our website.

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.

👻 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.

github-actions · 2026-01-16T01:53:48Z

Open in Overmind ↗

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

🔴 Change Signals

Routine 🔴 ▇▅▃▂▁ Multiple AWS instance resources showing 1 event/week for the last 7 weeks, which is infrequent compared to typical patterns.
Policies 🔴 ▃▂▁ S3 buckets and security groups are showing unusual policy violations, including missing tags and lack of server-side encryption, along with security risks from SSH access being allowed from anywhere.

View signals ↗

🔥 Risks

Single-target ALB/NLB backends will drop to zero healthy targets during EC2 AMI replacements, causing downtime ‼️High Open Risk ↗
Both api servers are being replaced via AMI changes, and their load balancer target attachments are also being replaced. The application ALB target group api-207c90ee-tg currently has a single registered instance target on port 80 (i-04bb38ef654996c52). When that instance is replaced, the old target will deregister and the new instance will not be healthy yet, leaving the ALB with zero healthy backends and causing user-visible errors.

The internal NLB target group api-health-terraform-example on port 9090 targets a single IP 10.0.101.145, which is the primary private IP of i-0e985281fc3f6ffb7 and is bound to EIP 13.134.236.98. Replacing this instance will change the backend attachment (and likely the private IP) while the EIP re-associates, temporarily removing the only healthy target. During these swaps, health checks will fail and CloudWatch/Route53 alarms will fire, resulting in downtime until the new instances register and pass checks. The NAT gateway is independent and not affected by these replacements.

Single-target target group attachment replacement will leave ALB/NLB with zero healthy backends, causing a brief outage ❗Medium Open Risk ↗
This change replaces the load balancer target group attachments for the API’s ALB-backed instance and the NLB-backed IP target. Each target group currently has only one registered backend (instance i-04bb38ef654996c52 on :80 for api-207c90ee-tg, and 10.0.101.145:9090 for api-health-terraform-example). When Terraform replaces these aws_lb_target_group_attachment resources, the existing targets will be deregistered before the new attachments become healthy.

During this window, the ALB and NLB listeners will have zero healthy targets. Requests will fail until the new targets pass health checks, which with the configured intervals/thresholds can take roughly 60–90 seconds. This will cause brief but complete traffic interruption and likely routing/health status flapping at the load balancer layer. Because the instance and EIP backing 10.0.101.145/13.134.236.98 are also being replaced, the external Route53 health check for 13.134.236.98:443/health can also remain failed or flap during the change, increasing alert noise.

🧠 Reasoning · ✖ 3 · ✔ 2

Load balancer target group attachment replacement causing transient traffic and health-check disruption

Observations 6

Hypothesis

Replacement of aws_lb_target_group_attachment resources will deregister and then re-register targets (e.g., EC2 instance i-04bb38ef654996c52; IP 10.0.101.145, 10.0.101.145:9090) in target group api-health-terraform-example. During this window, targets can fail health checks and be marked unhealthy, causing brief traffic interruption, routing changes at the load balancer/listener layer, and potential alarm triggers. Services relying on these endpoints may experience transient unavailability while attachments are replaced. Additional risk: target group attachment replacement can also cause Route53 health check failures and related alarms when health checks are tied to these endpoints, potentially triggering DNS failover or alert noise during the replacement window.

Investigation

Evidence Gathered

Planned changes show both load balancer attachments will be replaced: github.com/overmindtech/terraform-example.aws_lb_target_group_attachment.module.api_server.aws_lb_target_group_attachment.api[0] and github.com/overmindtech/terraform-example.aws_lb_target_group_attachment.module.api_access[0].aws_lb_target_group_attachment.api_server_ip (both ITEM_DIFF_STATUS_REPLACED). The diffs are blank but the action is replacement, which in Terraform detaches then re-attaches unless an explicit create_before_destroy is set (not shown in the plan).
Current state (blast radius):
- Target group api-207c90ee-tg (ALB) is HTTP on port 80 with health check path /health, interval 30s, healthy threshold 2, unhealthy threshold 3, TargetType=instance. It currently has one healthy target: i-04bb38ef654996c52 at port 80. 540044833068.eu-west-2.elbv2-target-group.api-207c90ee-tg and 540044833068.eu-west-2.elbv2-target-health.arn:aws:elasticloadbalancing:eu-west-2:540044833068:targetgroup/api-207c90ee-tg/443ea3af7659a1be|i-04bb38ef654996c52||80 (HEALTH_OK).
- Target group api-health-terraform-example (NLB) is TCP on port 9090 with interval 30s, healthy/unhealthy threshold 3, TargetType=ip. It currently has one healthy target: 10.0.101.145:9090. 540044833068.eu-west-2.elbv2-target-group.api-health-terraform-example and 540044833068.eu-west-2.elbv2-target-health.arn:aws:elasticloadbalancing:eu-west-2:540044833068:targetgroup/api-health-terraform-example/b062866b5f0bf0e0|10.0.101.145|all|9090 (HEALTH_OK).
- Listeners forward 100% of traffic to these single-target groups: ALB listener on port 80 → api-207c90ee-tg; NLB listener on port 9090 → api-health-terraform-example.
Related instance/EIP replacements in this same plan increase the likelihood of attachment swaps:
- i-04bb38ef654996c52 (the only ALB target) is being replaced to a new AMI. 540044833068.eu-west-2.ec2-instance.i-04bb38ef654996c52 (ITEM_DIFF_STATUS_REPLACED).
- i-0e985281fc3f6ffb7 (owns ENI/EIP for 10.0.101.145/13.134.236.98) is being replaced (ITEM_DIFF_STATUS_REPLACED) and the EIP 13.134.236.98 is being updated.
Alarms/health checks:
- CloudWatch alarm api-207c90ee-unhealthy-targets watches the ALB TG (OK currently).
- Route53 health check b3fb0a5c-a7bb-49fb-8382-914c06cd730a probes 13.134.236.98:443/health and is already failing across regions. While this R53 check is not directly tied to the LB TGs, replacing the backing instance/EIP association can further disrupt it during the change.

Impact Assessment

Directly affected backends: 2 total
- 1 ALB-backed instance target: i-04bb38ef654996c52 on :80 in target group api-207c90ee-tg.
- 1 NLB-backed IP target: 10.0.101.145:9090 in target group api-health-terraform-example.
Front doors depending on them: 2 listeners
- ALB listener arn:.../listener/app/api-207c90ee-alb/... forwards all traffic to api-207c90ee-tg.
- NLB listener arn:.../listener/net/mon-internal-terraform-example/... forwards all traffic to api-health-terraform-example.
Failure mechanism: During attachment replacement, Terraform will deregister the current target and then register the new one. Because each target group presently has only a single registered target, there will be a window with zero healthy targets. New targets must pass health checks before receiving traffic. With the configured intervals/thresholds, the expected blackout window is approximately 60 seconds for the ALB TG (30s interval × 2 healthy) and up to 90 seconds for the NLB TG (30s interval × 3 healthy). During this time, the listeners will have no healthy backends, causing failed requests and potential alerting (e.g., 5xx at the ALB, internal connection errors for the NLB path). The CloudWatch UnHealthyHostCount alarm may or may not fire depending on metric behavior with zero targets, but client-facing unavailability is expected until health checks pass.
Scope: Production resources as indicated by tags and internet-facing ALB. Impact is user-visible for traffic through api-207c90ee-alb and internal consumers of the 9090 service via the NLB. No evidence of redundant targets to mask the swap, so disruption affects 100% of requests through these listeners during the registration window.

Conclusion

Risk is real. Both aws_lb_target_group_attachment resources are being replaced while each target group has only one registered target; deregistration followed by re-registration will leave zero healthy targets until health checks pass, causing a brief but user-visible outage on both the ALB and NLB paths.

✔ Hypothesis proven

EC2 instance replacement via AMI change affecting compatibility, IP/DNS mappings, load balancer targets, and subnet/NAT reachability

Observations 21

Hypothesis

EC2 instance replacements driven by AMI changes and hibernation being set to null (e.g., ami-0f5473fac07833c62 -> ami-0c2b0adc4f380c44c; ami-0edeea98... -> ami-076e6b9...) will terminate and recreate instances (including i-0e985281fc3f6ffb7 and i-04bb38ef654996c52). This can change OS/kernel, drivers, and behavior, potentially causing compatibility issues with attached EBS volumes, ENIs, and instance architecture. During replacement, network interfaces, IPs, and DNS entries may change or be briefly removed (e.g., primary private IPs 10.0.101.145, 10.0.101.216, 10.0.101.75; ENIs such as eni-071468258f1a2c538 and eni-0c502e5a8c20f4df7), which can break DNS A records, ELB/ALB/NLB target references, and any services relying on those addresses. Load balancer target groups and health checks (including ELB/ALB/NLB targets on ports 443 and 9090 and Route53 HTTPS health checks) will see deregistration and health-state fluctuations, potentially reducing capacity, increasing UnHealthyHostCount, and triggering alarms or DNS failover until new instances are registered and pass health checks. Instance replacement can also affect NAT gateway or routing-related roles attributed to these instances and their subnets (e.g., via nat-0bcff9aa2633b680e), causing transient subnet/VPC reachability issues and failing in-flight connections. Overall this represents combined risk of downtime, connectivity loss, and regressions in instance-level and subnet-level networking behavior during and immediately after replacement, including for internal and external load balancers (e.g., NLBs using 10.50.101.182 and 10.50.102.66).

Investigation

Evidence Gathered

Reviewed planned diffs for two EC2 instances marked as replaced:
- 540044833068.eu-west-2.ec2-instance.i-0e985281fc3f6ffb7: AMI changes from ami-0f5473fac07833c62 to ami-0c2b0adc4f380c44c, hibernation: false to null (replacement). citefunctions.planned-changes-query
- 540044833068.eu-west-2.ec2-instance.i-04bb38ef654996c52: AMI changes from ami-0edeea98dcfc779b0 to ami-076e6b911c0417157, hibernation: false to null (replacement). citefunctions.planned-changes-query
Both ALB/NLB target attachments are also planned as replaced, indicating deregistration/registration churn during the rollout: module.api_server aws_lb_target_group_attachment.api[0] and module.api_access[0] aws_lb_target_group_attachment.api_server_ip. citefunctions.planned-changes-query
Current state shows each load balancer has a single backend target:
- ALB target group api-207c90ee-tg (HTTP:80) has exactly one registered instance target: i-04bb38ef654996c52, health=healthy. citefunctions.blast-radius-query
- NLB target group api-health-terraform-example (TCP:9090) has exactly one registered IP target: 10.0.101.145 (the private IP of i-0e985281fc3f6ffb7), health=healthy. citefunctions.blast-radius-query
The EIP 13.134.236.98 is associated to i-0e985281fc3f6ffb7’s primary ENI/private IP 10.0.101.145 (the same IP used by the NLB target). citefunctions.blast-radius-query
Route53 health checks targeting 13.134.236.98 and another endpoint currently report timeouts, showing external health monitoring sensitivity to backend availability. citefunctions.blast-radius-query
NAT gateway nat-0bcff9aa2633b680e is an AWS-managed NAT with its own ENI and EIP; it is not attached to these EC2 instances. Replacement of the instances does not affect the NAT GW’s interfaces or routing. citefunctions.blast-radius-query

Impact Assessment

Directly affected compute: 2 EC2 instances to be replaced
- i-04bb38ef654996c52 (api-207c90ee-api-server)
- i-0e985281fc3f6ffb7 (production-api-server)
Load balancer backends: 2 target groups, each with a single target
- ALB TG api-207c90ee-tg on port 80 has only i-04bb38ef654996c52 registered. Replacing this instance will remove the only healthy target until the new instance launches and passes health checks, driving UnHealthyHostCount > 0 and causing user-facing 5xx/timeouts via api-207c90ee-alb. citefunctions.blast-radius-query
- NLB TG api-health-terraform-example on port 9090 targets a single IP 10.0.101.145. Replacing i-0e985281fc3f6ffb7 is likely to change its primary private IP and temporarily disassociate its EIP 13.134.236.98; the TG attachment is being replaced to point at the new IP. During the swap, the old IP target will deregister and the new IP will not be healthy yet, resulting in zero healthy targets and connection failures. citefunctions.planned-changes-queryfunctions.blast-radius-query
Downstream/monitoring:
- CloudWatch alarms for unhealthy targets and Route53 health checks already show sensitivity to backend health; during replacement they will alarm and, if tied to DNS failover or autoscaling actions, could exacerbate instability. citefunctions.blast-radius-query
Scope of disruption:
- External users of the ALB-backed API will experience downtime while the only instance target is replaced.
- Internal consumers behind the NLB will lose connectivity to the health endpoint on 9090 while the single IP target changes and re-registers.

Conclusion

Risk is real. The plan replaces two EC2 instances that are each the sole backend for their respective load balancer target groups. Target group attachments are also being replaced, which implies deregistration of the old targets before the new ones are healthy. With single-target groups, this results in a period with zero healthy backends, causing outage and health-check/alarm flaps. The NAT gateway mentioned in the hypothesis is not impacted by these instance replacements.

✔ Hypothesis proven

~~Elastic IP and instance lifecycle changes risking loss of public IP/DNS connectivity~~

Observations 4

Hypothesis

Updates to Elastic IP 13.134.236.98 associations (for instance i-0e985281fc3f6ffb7 and ENI eni-00b991fd064931ee8) may detach or re-associate the EIP, disrupting public connectivity for any public-facing services, DNS records, or clients relying on this static IP. Association or allocation changes, as well as related security group or routing adjustments, can cause loss of public reachability until DNS and client configurations are updated or connectivity is restored. Instance replacement for i-0e985281fc3f6ffb7 can further disrupt IP/DNS reachability by changing or briefly removing ENI and private IP mappings (including ENI eni-0c502e5a8c20f4df7) that the EIP and DNS A records rely on, causing temporary unreachability of services during the replacement lifecycle.

Investigation

Evidence Gathered

Planned changes: Queried diffs for the instance and related networking. The EC2 instance i-0e985281fc3f6ffb7 is being replaced only due to an AMI change (ami-0f5473fac07833c62 → ami-0c2b0adc4f380c44c). No port, SG, or networking attributes are changing in the diff. Two ALB target group attachments are being replaced with empty diffs, consistent with dependency churn when the instance ID/private IP changes. The Elastic IP 13.134.236.98 is marked “updated” but shows an empty diff, indicating no declared change to allocation or association attributes in this plan. (planned-changes-query)

Current state validation: The EIP 13.134.236.98 is presently associated to instance i-0e985281fc3f6ffb7 via ENI eni-00b991fd064931ee8 and private IP 10.0.101.145. Security groups sg-089e5107637083db5 and sg-03cf38efd953aa056 are attached. Separately, ENI eni-0c502e5a8c20f4df7 belongs to a NAT Gateway and uses a different EIP (13.42.93.249); it is unrelated to the instance’s public EIP. Multiple load balancer and target group resources are in the blast radius, indicating traffic is fronted by an ALB rather than relying solely on the instance’s EIP. (blast-radius-query)

Impact Assessment

Directly affected resources: 1 EC2 instance (i-0e985281fc3f6ffb7) and its 1 EIP (13.134.236.98) via 1 primary ENI (eni-00b991fd064931ee8). The NAT ENI (eni-0c502e5a8c20f4df7) and its EIP (13.42.93.249) are unrelated to the instance’s public reachability and are not changing in this plan.

Downstream dependencies: The service appears to be accessible via an ALB with target group attachments that are being re-created to follow the new instance/IP during replacement. No evidence shows the EIP will be detached and left unassociated, nor that DNS records will be changed. Any disruption would be limited to the brief re-association window and only for clients that bypass the ALB and connect directly to 13.134.236.98.

Scope: With the ALB and TG attachments being re-provisioned, there is no evidence of a lasting loss of public reachability. The hypothesis also incorrectly links the NAT ENI to the instance’s EIP, which does not reflect the actual architecture.

Conclusion

Risk not confirmed. The plan replaces the instance due to an AMI change and re-creates dependent LB attachments; the EIP shows no concrete change in association. The NAT ENI/EIP cited in the hypothesis are unrelated. There is insufficient evidence of a real, lasting loss of public IP/DNS connectivity beyond routine, transient replacement behavior.

✖ Hypothesis disproven

~~Route53 health check behavior changes via CloudWatch alarm configuration updates~~

Observations 1

Hypothesis

Updating the CloudWatch alarm 540044833068.eu-west-2.cloudwatch-alarm.api-207c90ee-high-cpu may change thresholds or actions and could introduce or modify a CloudWatchAlarmConfiguration on a linked Route53 health check. If a currently null CloudWatchAlarmConfiguration becomes populated or altered, Route53 health status and DNS failover behavior could change unexpectedly, potentially causing unintended failover or making endpoints appear unhealthy, which would impact DNS-based routing and availability.

Investigation

Evidence Gathered

Queried planned changes for the CloudWatch alarm and the referenced Route53 health check. The CloudWatch alarm 540044833068.eu-west-2.cloudwatch-alarm.api-207c90ee-high-cpu shows an update with no diff content provided; the Route53 health check 540044833068.eu-west-2.route53-health-check.0771e285-11bf-4b60-9e00-7b4d71df1a0b is not in the planned changes at all.

Queried current state (blast radius) of the health checks and the alarm:

Route53 health checks 0771e285-11bf-4b60-9e00-7b4d71df1a0b and b3fb0a5c-a7bb-49fb-8382-914c06cd730a both have CloudWatchAlarmConfiguration: null and HealthCheckConfig.AlarmIdentifier: null, meaning neither is configured to use a CloudWatch alarm for health evaluation. Both are standard HTTPS checks to IPs 44.207.52.17 and 13.134.236.98 on port 443 with path /health.

The CloudWatch alarm api-207c90ee-high-cpu is an AWS/EC2 CPUUtilization alarm on instance i-04bb38ef654996c52, threshold 80, evaluation periods 2, actions to an SNS topic. It is currently in OK and there is no evidence it is referenced by any Route53 health check.

No Route53 health check resources are being modified in this plan, so no new CloudWatchAlarmConfiguration could be introduced by this change.

Impact Assessment

Health checks affected via the hypothesized mechanism (CloudWatchAlarmConfiguration linkage): 0. Because both Route53 health checks are not alarm-based, updating the CloudWatch alarm cannot change their Route53 health status or DNS failover behavior.

DNS routing and availability will continue to depend on the existing HTTPS health probes, not on CloudWatch alarm state.

Note: Both health checks currently report timeouts from multiple regions, indicating existing health issues independent of this change; any ongoing failover (if configured) would already be occurring prior to this plan.

Conclusion

Not a real risk. The Route53 health checks have no CloudWatch alarm linkage (CloudWatchAlarmConfiguration and AlarmIdentifier are null), and there are no planned changes to add such linkage. Updating the CloudWatch alarm alone cannot alter Route53 health evaluation or DNS failover.

✖ Hypothesis disproven

~~EBS volume data loss risk due to DeleteOnTermination during EC2 replacement~~

Observations 2

Hypothesis

EBS volumes attached to instances being replaced via AMI change and with DeleteOnTermination=true (e.g., vol-0066d63402683851f, vol-0b0515d0c4e16bd60 on instance i-04bb38ef654996c52) are at risk of being deleted when the old instance is terminated. Instance replacement can trigger detachment and automatic deletion, causing permanent data loss and downtime for any workloads or state stored on these volumes if backups, snapshots, or reattachment plans are not in place.

Investigation

Evidence Gathered

Reviewed the planned diffs: both EC2 instances 540044833068.eu-west-2.ec2-instance.i-04bb38ef654996c52 and 540044833068.eu-west-2.ec2-instance.i-0e985281fc3f6ffb7 are marked “replaced” due to AMI changes; no volume resources are being modified directly in the plan.

Queried current state for the instances and the cited volumes:

i-04bb38ef654996c52 has a single BlockDeviceMappings entry: DeviceName /dev/xvda with DeleteOnTermination=true pointing to vol-0b0515d0c4e16bd60; the volume shows SnapshotId snap-0314f11ce2363f0e3 and is tagged as api-207c90ee-root-volume, confirming it is the root disk. (540044833068.eu-west-2.ec2-instance.i-04bb38ef654996c52; 540044833068.eu-west-2.ec2-volume.vol-0b0515d0c4e16bd60)

i-0e985281fc3f6ffb7 likewise has a single BlockDeviceMappings entry: DeviceName /dev/xvda with DeleteOnTermination=true pointing to vol-0066d63402683851f; the volume shows SnapshotId snap-022908551aa7f4144 (AMI-derived root). (540044833068.eu-west-2.ec2-instance.i-0e985281fc3f6ffb7; 540044833068.eu-west-2.ec2-volume.vol-0066d63402683851f)

No additional (non-root) EBS volumes are attached to either instance, and there is no evidence of data disks where DeleteOnTermination=true would be dangerous.

Impact Assessment

Directly affected resources: 2 EC2 instances being replaced: production-api-server (i-0e985281fc3f6ffb7) and api-207c90ee-api-server (i-04bb38ef654996c52). Each has exactly 1 EBS volume, the root (/dev/xvda).

Because the only volumes with DeleteOnTermination=true are the root volumes created from AMI snapshots, their deletion on instance termination is expected and does not represent loss of shared or persistent application data. Any ephemeral OS-level changes (e.g., logs, package caches) are inherently non-persistent and normally recreated with the new instance.

There is no sign of stateful workloads or data-only EBS volumes at risk (no secondary block device mappings). As such, while instance replacement could cause brief service disruption if not orchestrated via the load balancer, there is no credible pathway here to “permanent data loss” via DeleteOnTermination of these specific volumes.

Conclusion

Risk not real. The cited volumes are AMI-derived root disks with DeleteOnTermination=true, which is correct and expected during instance replacement. No non-root, stateful EBS volumes with DeleteOnTermination=true were found, so the hypothesized data-loss mechanism does not apply.

✖ Hypothesis disproven

💥 Blast Radius

Items 101

Edges 216

github-actions

⛔ Auto-Blocked

🔴 Decision

Found 1 high risk requiring review

📊 Signals Summary

Routine 🟢 +4

🔥 Risks Summary

High 1 · Medium 0 · Low 0

💥 Blast Radius

Items 55 · Edges 92

Conversation

renovate bot commented Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Release Notes

Bug Fixes

Chores

Bug Fixes

Documentation

Chores

Bug Fixes

Chores

v7.71.2: Version 7.71.2

Configuration

Uh oh!

github-actions bot commented Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔴 Change Signals

🔥 Risks

🧠 Reasoning · ✖ 3 · ✔ 2

Load balancer target group attachment replacement causing transient traffic and health-check disruption

Evidence Gathered

Impact Assessment

Conclusion

EC2 instance replacement via AMI change affecting compatibility, IP/DNS mappings, load balancer targets, and subnet/NAT reachability

Evidence Gathered

Impact Assessment

Conclusion

Elastic IP and instance lifecycle changes risking loss of public IP/DNS connectivity

Evidence Gathered

Impact Assessment

Conclusion

Route53 health check behavior changes via CloudWatch alarm configuration updates

Evidence Gathered

Impact Assessment

Conclusion

EBS volume data loss risk due to DeleteOnTermination during EC2 replacement

Evidence Gathered

Impact Assessment

Conclusion

💥 Blast Radius

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

⛔ Auto-Blocked

🔴 Decision

📊 Signals Summary

🔥 Risks Summary

💥 Blast Radius

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

⛔ Auto-Blocked

🔴 Decision

📊 Signals Summary

🔥 Risks Summary

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

⛔ Auto-Blocked

🔴 Decision

📊 Signals Summary

🔥 Risks Summary

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

⛔ Auto-Blocked

🔴 Decision

📊 Signals Summary

🔥 Risks Summary

💥 Blast Radius

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

⛔ Auto-Blocked

🔴 Decision

📊 Signals Summary

🔥 Risks Summary

💥 Blast Radius

Uh oh!

github-actions bot left a comment

renovate bot commented Jan 16, 2026 •

edited

Loading

`v7.71.2`: Version 7.71.2

github-actions bot commented Jan 16, 2026 •

edited

Loading