You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
model|risks_v6 ✨Encryption Key State Risk✨KMS Key Creation
🔴 Change Signals
Routine 🔴 ▇▅▃▂▁ Multiple resources showing unusual routine changes at 1 event/week for the last 2-3 months, which is infrequent compared to typical patterns. Policies 🔴 ▃▂▁ Multiple policy resources are showing unusual security and compliance issues that may need review: an S3 bucket does not have server-side encryption configured and is missing required tags across four checks, while a security group allows SSH (port 22) access from anywhere (0.0.0.0/0).
We investigated 2 potential risks across 27 resources and verified each was safe. See the investigation details below.
🧠 Reasoning · ✔ 0 · ✖ 2
ALB target group capacity and availability risk from EC2 instance update
Observations 8
Hypothesis
Updating EC2 instance i-09d6479fb9b97d123 (status: updated) poses an availability risk because it is a target in the internet-facing ALB api-207c90ee-alb (listener on port 80, default rule forwarding to target group api-207c90ee-tg, TargetType=instance). An update may trigger reboot/replacement or configuration changes that cause the instance to fail ALB HTTP health checks (/health on traffic-port). If marked Unhealthy, it will be removed from the target group, reducing capacity and potentially disrupting traffic to the API backend and associated public IP/DNS endpoints. Additional observations confirm that this can lead to loss of ALB target availability and service disruption for traffic through api-207c90ee-alb if sufficient healthy targets are not maintained. This can violate HA and network design best practices where public endpoints should be resilient and not depend on a single instance, especially if capacity is concentrated in few AZs or if services rely directly on instance public IPs instead of the ALB. Recommended mitigations: stagger instance deployments, ensure multi-AZ targets, configure draining and robust ASG/ELB health checks, and avoid direct dependence on mutable instance public endpoints.
Investigation
Evidence Gathered
I first checked the relevant organizational guidance. aws-high-availability says to flag production workloads that depend on a single AZ or insufficient pre-provisioned capacity, and aws-network-security says direct dependence on mutable EC2 public endpoints is an anti-pattern. infrastructure-quick-reference adds that these environments sometimes use public subnets for cost reasons, but it does not say these API instances are intentionally single-node or exempt from HA expectations.
I then inspected the actual planned diffs for both changed EC2 instances: 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123 and 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa. In both cases, the only visible change is public_ip and public_dns becoming (known after apply). There is no explicit change to AMI, instance type, user data, security groups, subnet, health check path, or target group attachment.
To validate the load balancing side, I queried the blast radius for the ALB, listener, target group, and target health, plus both EC2 instances. The ALB api-207c90ee-alb is internet-facing and spans two AZs (eu-west-2a and eu-west-2b). Its listener on port 80 forwards to target group api-207c90ee-tg. That target group performs HTTP health checks on /health over traffic-port, with healthy threshold 2 and unhealthy threshold 3. Critically, the target group currently shows only one registered target in blast radius data: i-09d6479fb9b97d123, and that target is currently healthy. The second changed instance, i-0464c4413cb0c54aa, is not shown as a target of this ALB/target group.
I also checked AWS documentation. AWS documents that auto-assigned public IPv4 addresses are lost on stop/start unless an Elastic IP is attached, while the network interface and private IP persist. AWS ALB documentation confirms traffic is routed to healthy registered targets and that deregistered targets enter draining; health checks on the configured path determine eligibility. This means public IP churn is expected behavior for a stop/start-style EC2 update, but ALB routing depends on the instance target remaining healthy on its private network path, not on the instance's ephemeral public IP. (docs.aws.amazon.com)
Impact Assessment
There is 1 directly affected ALB target in the queried target group: i-09d6479fb9b97d123. The changed instance i-0464c4413cb0c54aa appears unrelated to this ALB path based on the evidence retrieved. The ALB itself spans 2 AZ subnets, but the actual backend capacity visible here is only a single healthy registered instance target, so if that instance were stopped or became unhealthy there would indeed be complete API backend interruption behind api-207c90ee-alb.
However, the change evidence does not show a concrete action that would make that outage happen. The hypothesis assumes an EC2 “update” here implies reboot, replacement, or application/config changes that could fail /health, but the Terraform diff only shows computed values for public_ip and public_dns becoming unknown until apply. Those are standard computed attributes and, per the change-analysis guidance, are not themselves evidence of a risky configuration change. I found no planned modification to the target group, listener, security groups, instance private IP, or application-facing configuration that would break ALB health checks. I also found no evidence that the ALB or clients rely on the instance’s ephemeral public IP for the ALB path; the ALB uses instance targets in the VPC, and AWS documents that registered healthy targets are reached through the target group mechanism rather than the instance's public DNS name. (docs.aws.amazon.com)
So the environment does appear fragile from an HA perspective because only one healthy target is visible, but that is a pre-existing architectural weakness, not a risk created or evidenced by this specific change. The planned change does not provide strong evidence that Terraform will stop, replace, or misconfigure the instance in a way that causes it to fail health checks.
Conclusion
I conclude the specific risk hypothesis is not proven by the available evidence, so is_risk_real = false. The key reason is that the only planned diff is computed public IP/DNS values becoming unknown after apply, with no concrete instance, ALB, or health-check configuration change that would cause target loss or service disruption.
✖ Hypothesis disproven
Simultaneous public endpoint reassignment risks for external consumers and controls
Observations 4
Hypothesis
Both internet-facing EC2 instances in this change will have their public_dns and public_ip reassigned in the same apply. Any external or out-of-band consumer that keys off those specific addresses (e.g., IP allowlists, shell scripts, bookmarks, SSM parameter payloads, CI jobs, partner integrations, monitoring checks, dashboards, alert targets, operator runbooks, firewall/bastion rules) will see both endpoints drift simultaneously. There is no stable overlap or failover anchor, so paired or redundant paths that treat one instance as a peer or fallback endpoint can lose both discovery points at once. This can cause immediate failures for missed references, coordinated outages until every consumer refreshes configuration, degraded incident detection and triage (no unchanged probe to compare against), and pressure to widen or duplicate network exceptions. Overall, simultaneous public endpoint churn increases availability, operational, and security-control drift risks and diverges from the practice that EC2 instances should not be directly reachable from the internet.
Investigation
Evidence Gathered
I first checked the relevant organizational knowledge: aws-network-security, aws-high-availability, aws-compute-configuration, security-compliance-requirements, and infrastructure-quick-reference. Those sources do establish that direct internet exposure on EC2 is an anti-pattern and that simultaneous rollout to all instances can be a reliability concern, but they do not say that any reassignment of ephemeral public IPs is itself an outage if the service is fronted by a stable endpoint.
I 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 visible change on both resources is public_dns and public_ip becoming (known after apply). There are no diffs changing security groups, listeners, target groups, DNS records, Elastic IP associations, or any explicit consumer configuration. I then queried blast-radius state for both EC2 instances, the ALB api-207c90ee-alb, its target group api-207c90ee-tg, the target-health record, the relevant subnet, and related network interfaces.
That current state shows one of the changed instances, i-09d6479fb9b97d123, is already registered as a healthy target behind the internet-facing ALB on port 80. The ALB has a stable DNS name, api-207c90ee-alb-592661235.eu-west-2.elb.amazonaws.com, spans two subnets/AZs, and its target group uses instance targets rather than public IPs. The subnet hosting the instance has MapPublicIpOnLaunch: false, so the public IP is not coming from automatic subnet assignment. The second changed instance, i-0464c4413cb0c54aa, is also in the same VPC/subnet and currently has a public IP, but the blast radius does not show it as an ALB target or as a stable public endpoint with an Elastic IP. I also checked AWS documentation, which confirms that automatically assigned EC2 public IPv4 addresses and public DNS names can change on stop/start and that Elastic IPs are the mechanism for preserving a stable public address. (docs.aws.amazon.com)
Impact Assessment
There are 2 directly changed EC2 instances. Of those, only 1 is evidenced in the blast radius as serving production traffic through the ALB target group: i-09d6479fb9b97d123. External clients of the application already have a stable discovery point through the ALB DNS name, not through the instance's ephemeral public IP. Because the load balancer targets instances by instance ID and private networking, changing an instance's public IP does not break ALB-to-instance connectivity or client access through the ALB. The blast radius therefore does not support the hypothesis's main failure mode of both public discovery points disappearing for the actual service path.
The real issue exposed by the evidence is architectural drift: both instances have public IPs in production, which conflicts with the security requirement that EC2 instances must not be directly reachable from the internet and with AWS guidance to place public endpoints on managed edge services rather than instance addresses. But that is a pre-existing posture problem, not a demonstrated new outage introduced by this change. There is no evidence in the plan or blast radius of Route 53 records, SSM parameters, CI jobs, partner integrations, monitoring checks, or firewall rules that directly depend on these two specific public IPs or DNS names. Without such evidence, concluding that simultaneous endpoint churn will cause immediate external failures would be speculation.
Conclusion
I conclude the hypothesized risk is not proven for this change. The instances' ephemeral public endpoints will likely change, but the evidenced service entry point is the ALB's stable DNS name, and there is no concrete evidence that any consumer depends on the instance public IPs directly.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
renovate
bot
added
dependencies
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This PR contains the following updates:
1.6.0→1.7.04.7.5→4.8.03.8.0→3.8.18.0.2→8.0.3Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
lucide-icons/lucide (lucide-react)
v1.7.0: Version 1.7.0Compare Source
What's Changed
map-pin-searchicon by @TonySullivan in #4125New Contributors
Full Changelog: lucide-icons/lucide@1.6.0...1.7.0
bvaughn/react-resizable-panels (react-resizable-panels)
v4.8.0Compare Source
useDefaultLayouthook automatically migrates legacy layouts to version 4 format; see issue 605 for details on how this works.v4.7.6Compare Source
Panelaria-disabledattribute withdata-disabledrecharts/recharts (recharts)
v3.8.1Compare Source
What's Changed
Bugfixes!
New Contributors
Full Changelog: recharts/recharts@v3.8.0...v3.8.1
vitejs/vite (vite)
v8.0.3Compare Source
Features
Bug Fixes
metaidentifier insideimport.metawhen a binding namedmetaexists (#22019) (cff5f0c)Miscellaneous Chores
Tests
getCssFilesForChunk(#22016) (43fbbf9)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.
This PR was generated by Mend Renovate. View the repository job log.