chore(deps): lock file maintenance

[renovate]

This PR contains the following updates:

Update	Change
lockFileMaintenance	All locks refreshed

---

Warning

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

🔧 This Pull Request updates lock files to use the latest dependency versions.

---

Configuration

📅 Schedule: Branch creation - "before 4am on monday" 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]

Open in Overmind ↗

---

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

🔴 Change Signals

Routine 🔴 ▇▅▃▂▁ Multiple API access and server resources showing unusual update activity at 1 event/week for the last 2 months to 3 months, with the related load balancer attachment also at 1 event/week for the last 5 weeks, which is infrequent compared to typical patterns.
Policies 🔴 ▃▂▁ Multiple policy violations detected, including missing tags and lack of server-side encryption on S3 buckets, and security risks from open SSH access.

View signals ↗

---

🔥 Risks

Replacing the only registered API health target will cause a load balancer outage during instance cutover ‼️High Open Risk ↗
The change replaces the production API server instance 540044833068.eu-west-2.ec2-instance.i-0ea52e0eb6476a224 by changing its AMI from ami-01b1bd34b1f8288c8 to ami-094a6f8df2b26dfde, and it also replaces the aws_lb_target_group_attachment that registers that server's IP 10.0.101.142:9090 in 540044833068.eu-west-2.elbv2-target-group.api-health-terraform-example. The current blast radius shows that target group has exactly one healthy target, and that target is the instance being replaced in a single AZ.

During apply, Terraform replacement and target re-registration will remove the only healthy backend before the new instance has finished booting, had the EIP rebound, and passed initial load balancer health checks. That leaves api-health-terraform-example with zero healthy targets and makes the health service behind the internal load balancer unavailable until the new node is registered and healthy. This conflicts with the org's high-availability guidance for single-target, single-AZ production services (REL10-BP01, REL10-BP03).

EC2 replacement preserves the EIP but leaves critical public SSH exposure and breaks the instance’s private-address identity ‼️High Open Risk ↗
The change replaces the module.api_access[0].aws_instance.api_server EC2 instance by switching its AMI from ami-01b1bd34b1f8288c8 to ami-094a6f8df2b26dfde, and it also updates public-addressed EC2 instances whose public IPs will be reassigned at apply. On the affected fleet, 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa is already directly internet-reachable with public IP 18.175.147.19 and security group sg-0437857de45b640ce allowing SSH on 22/tcp from 0.0.0.0/0. That violates the organization’s network-access policy and Well-Architected controls SEC05-BP02 and SEC06-BP03, and the change does nothing to remove the exposure.

The instance replacement also breaks the current address identity of 540044833068.eu-west-2.ec2-instance.i-0ea52e0eb6476a224: its instance ID, ENI, private IP 10.0.101.142, and private DNS name are all being regenerated, and the IP-based target-group attachment is being replaced with it. Terraform-managed dependencies are being updated, but any runtime consumer outside Terraform that still uses the old private IP or private-DNS name will lose connectivity after cutover. The EIP 13.134.236.98 appears to be reassociated to the new instance, so the strongest runtime breakage risk is on private-address consumers, not on the Elastic IP.

---

🧠 Reasoning · ✔ 2 · ✖ 1

Load balancer target attachment, AMI, and instance changes risking service unavailability

Observations 19

Hypothesis

Multiple changes to ALB target group attachments, backend instances, and AMIs can temporarily deregister or reduce healthy targets, causing traffic disruption and failed health checks for services behind the api-health and api-207c90ee-tg/api-207c90ee-alb target groups. Risks include:

• Replacing aws_lb_target_group_attachment objects for api-health, api-health-terraform-example, and related internal or internet-facing ALBs can deregister/re-register IP targets (e.g., 10.0.101.142:9090, 10.50.101.182, 10.50.102.66), leaving the load balancer with fewer or no healthy targets and violating high-availability guidance when single-AZ or single-target configurations exist.
• Instance updates for EC2 instances registered in ALB target groups (e.g., i-09d6479fb9b97d123 on HTTP port 80 /health) can change runtime networking, application behavior, or health-check responses even when Terraform shows no diff, leading to target health failures, brownouts, or routing gaps.
• The api_server instance is rebuilt onto a new AMI while its old target-group attachment and EIP association are recreated. If the new AMI modifies boot behavior, metadata options, or user-data timing, health-server startup may be delayed; with the old node removed, ALB health checks can flap and create retry/recovery storms instead of a graceful handoff.
• Because the design relies on single-node/static capacity and tightly coupled EC2 replacement, AMI refresh, EIP reassociation, and LB re-registration, any misconfiguration or slow bootstrap can cause prolonged service unavailability.
  These are systemic reliability risks around target-group attachment changes, AMI refreshes, and instance updates, and they violate reliability and network availability best practices (REL02-BP01/REL02-BP03, REL10/REL11, SEC05-BP01/SEC05-BP02) when changes are not staged with redundancy, health-check grace/threshold tuning, and controlled rollout.

Investigation

I treated the concern area as service availability loss during this apply, then checked the org guidance first. The relevant knowledge explicitly says to flag production workloads with ELB targets in only one AZ as a reliability risk (REL10-BP01) and to flag deployments applied to all instances simultaneously without gradual rollout (REL10-BP03). I then inspected the current blast radius state and the planned changes.

The current state shows both affected target groups are effectively single-target services. api-health-terraform-example is an NLB target group with exactly one healthy IP target, 10.0.101.142:9090, which belongs to EC2 instance i-0ea52e0eb6476a224. api-207c90ee-tg is an ALB target group with exactly one healthy instance target, i-09d6479fb9b97d123:80. Both instances are in subnet subnet-07b5b1fb2ba02f964 in AZ eu-west-2a, so there is no cross-AZ redundancy in the currently registered targets. The planned change replaces i-0ea52e0eb6476a224 because its ami changes from ami-01b1bd34b1f8288c8 to ami-094a6f8df2b26dfde, and the associated EIP is rebound to the replacement instance. The target group attachment resource for the API server IP is also being replaced. Terraform's lifecycle documentation says replacements are destroy-then-create by default unless create_before_destroy is explicitly set, and the available plan does not show any evidence of such a safeguard. AWS ELB documentation says deregistered targets enter draining / deregistration states, newly registered targets must register and pass initial health checks before they are healthy, and health counts drop immediately when a target is deregistered. That means replacing the only registered target necessarily creates a window with zero healthy targets for api-health-terraform-example during instance replacement and re-registration.

I also looked for evidence against the risk. The current target health is healthy, and there is a CloudWatch alarm on the ALB target group, but alarms detect failure rather than prevent it. AWS documentation notes that newly registered targets can become healthy after an initial check, which reduces recovery time, but it does not remove the outage window when the old sole target is terminated or deregistered first. For i-09d6479fb9b97d123 and i-0464c4413cb0c54aa, the diffs only show public IP/DNS becoming unknown after apply; there is no concrete evidence here of application or listener changes that would independently break health checks, so I did not use those as the main mechanism. The confirmed, closely related mechanism is simpler and stronger: this change replaces the only backend instance behind the api-health-terraform-example target group, along with its attachment and EIP association, in a topology that has only one healthy target in one AZ. That will cause temporary unavailability during apply if bootstrap and registration are not instantaneous, which is exactly the kind of service disruption the hypothesis points to.

✔ Hypothesis proven

---

Public EC2 exposure, AMI changes, and runtime address contract risks

Observations 5

Hypothesis

EC2 configuration continues to expose instances to security and stability risks:

• Instance i-0464c4413cb0c54aa resides in a public subnet with public IPv4 18.175.147.19 and a security group allowing SSH (port 22) from 0.0.0.0/0, enabling internet-wide brute-force attacks and violating least-privilege and network segmentation controls (SEC05-BP02, REL02-BP01).
• Changing the AMI from ami-01b1bd34b1f8288c8 to ami-094a6f8df2b26dfde alters the underlying OS image, potentially introducing kernel, package, or configuration differences that affect instance behavior, compatibility with attached volumes, and security hardening (SEC06-BP02).
• During api_server replacement and related instance updates, instance identity and private/public IPs can change while target-group attachments and EIP associations are updated. If any consumer outside Terraform (applications, DNS, scripts, monitoring, partner systems) is pinned to old private IPs or EIPs instead of stable load balancer or DNS names, the replacement can silently break that runtime address contract.
• Updated ALB targets such as i-09d6479fb9b97d123 may also have direct public exposure (e.g., via EIP or ALB-managed address), which is an anti-pattern per network security guidance when not fronted by appropriate controls.
  Mitigations include restricting direct public SSH access (use bastion or SSM), validating AMI hardening and compatibility before rollout, ensuring external dependencies use stable abstractions instead of raw EC2 addresses, and minimizing direct public exposure of application instances.

Investigation

I treated the hypothesis as three separate concern areas: direct internet exposure, AMI-driven instance replacement, and runtime breakage from address changes. I first loaded the relevant organizational knowledge. That knowledge is decisive here: security-compliance-requirements says EC2 instances must not be directly reachable from the internet, public IPs are a finding, SSH from 0.0.0.0/0 is forbidden, and the combination of a public IP plus an open security group is critical severity. aws-network-security and aws-compute-configuration independently classify public EC2 endpoints and 0.0.0.0/0 SSH as risks.

Blast-radius data confirms the risky current state is real on the specific changed resource 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa: it is running in subnet subnet-07b5b1fb2ba02f964, has public IP 18.175.147.19, and is attached to security group sg-0437857de45b640ce, which allows inbound TCP 22 and 80 from 0.0.0.0/0. The same subnet is tagged as a public subnet and the environment notes explicitly say this test setup places EC2 instances in public subnets because there are no NAT gateways. The planned change does not mitigate that exposure; it only causes the instance public IP/DNS values to become unknown until apply, meaning the instance remains publicly reachable and its public address may rotate.

For the AMI concern, the change on 540044833068.eu-west-2.ec2-instance.i-0ea52e0eb6476a224 is a full replacement driven by an AMI change from ami-01b1bd34b1f8288c8 to ami-094a6f8df2b26dfde. The diff itself shows Terraform already planning replacement, which is consistent with aws_instance AMI changes being ForceNew behavior. That means the old instance ID, private IP, primary ENI, and public IP are not preserved. The EIP resource 540044833068.eu-west-2.ec2-address.13.134.236.98 is being updated to point at the new instance after replacement, so the old public EIP should follow the replacement instance. That is evidence against the specific part of the hypothesis claiming the EIP itself will silently change for consumers using 13.134.236.98.

However, the runtime address-contract risk is still real through a closely related mechanism involving the same resources. The replacement instance currently has private IP 10.0.101.142, private DNS ip-10-0-101-142..., and target health for the internal NLB is explicitly registered by IP on 10.0.101.142:9090, while the aws_lb_target_group_attachment resource for module.api_access[0].aws_lb_target_group_attachment.api_server_ip is being replaced. Because the instance is replaced, that private IP will become unknown until apply and is likely to change. Anything outside Terraform that is pinned to the old private IP or private-DNS name will break immediately after cutover. This is not speculative in the abstract diff sense: the infrastructure already contains one consumer that uses the raw private IP as an attachment target, which shows this environment relies on concrete instance addresses rather than only stable service names. So although I cannot prove an external unmanaged consumer exists, the change undeniably breaks the existing private-address identity of this host and already requires Terraform-managed consumers to be updated in lockstep.

I did not treat the generic public exposure of 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123 as the main finding because that instance is not the one being replaced and the hypothesis’s claim about “ALB-managed address” is imprecise. The strongest confirmed risk is that this change leaves a critically noncompliant internet-exposed EC2 host in place and simultaneously replaces another EC2 host whose private address identity is currently depended on by IP-based attachments. That combination makes the concern area real.

✔ Hypothesis proven

---

Elastic IP association updates impacting ALB and public reachability

Observations 13

Hypothesis

Changes to Elastic IP 13.134.236.98 (allocation eipalloc-05a1609afb54e84ed, associations including ENIs eni-065db8208d75f1855 and eni-00b29d09050c2ef32 in public subnets) can modify association state, public IP metadata, and DNS names (e.g., ec2-35-179-190-100..., ec2-13-134-236-98.eu-west-2.compute.amazonaws.com). This may:

• Disrupt public reachability or cause DNS/routing inconsistencies for instances, internet-facing ALBs such as api-207c90ee-alb, or other resources using this EIP, including impaired health checks and service disruption.
• Accidentally expose backend instances directly to the internet or remove expected public access, violating network segmentation and public-endpoint best practices that discourage direct EC2 public IPs without proper perimeter controls (aws-network-security: Public Endpoints and Edge Networking, REL02-BP01/SEC05-BP01/SEC05-BP03).
• Alter public IP mappings for resources in public subnets (e.g., subnet-07b5b1fb2ba02f964), requiring coordinated updates to Route53, CloudFront/WAF, health checks, DNS records, firewall rules, and external allowlists that may be keyed to the old IP.
  Careful planning of EIP association updates, preference for managed endpoints (ALB/CloudFront) over raw instance IPs, and validation that ALB ENIs retain the correct EIP and that external dependencies remain aligned is required to avoid unintended downtime, exposure, or broken connectivity.

Investigation

I investigated the concern area as public reachability and service disruption caused by an Elastic IP reassociation. I first checked the relevant organizational knowledge: aws-network-security and aws-high-availability are relevant, and infrastructure-quick-reference adds important local context that this environment intentionally places EC2 instances in public subnets and does not use NAT gateways. That means the presence of public IPs here is not, by itself, evidence of a new segmentation violation introduced by this change.

The planned diff on 540044833068.eu-west-2.ec2-address.13.134.236.98 only changes the instance field from a concrete instance ID to (known after apply), while the actual EC2 instance 540044833068.eu-west-2.ec2-instance.i-0ea52e0eb6476a224 is being replaced because its AMI changes. AWS documents that associating an Elastic IP to an instance automatically associates it to the instance’s primary network interface, and reassociation to another instance/interface is automatic; when an EIP is attached to the primary ENI, it replaces the ephemeral public IPv4 on that instance. The current blast-radius state confirms that 13.134.236.98 is attached to the primary ENI eni-065db8208d75f1855 of i-0ea52e0eb6476a224, not to the ALB. AWS also distinguishes requester-managed ALB ENIs from normal instance ENIs, and the ALB-related ENI in blast radius is eni-00b29d09050c2ef32 with a different EIP 35.179.190.100. So the hypothesis’s main mechanism—that this EIP update could disrupt the internet-facing ALB by modifying its EIP association—is not supported.

I also checked whether there is a closely related mechanism affecting the same concern area. The ALB api-207c90ee-alb remains in two subnets across two AZs and targets instance i-09d6479fb9b97d123 on port 80; current target health is healthy. The only target-group attachment being replaced is github.com/overmindtech/terraform-example.aws_lb_target_group_attachment.module.api_access[0].aws_lb_target_group_attachment.api_server_ip, which aligns with the replacement of the separate api_access instance using private IP 10.0.101.142 behind the internal NLB health target group on port 9090, not the internet-facing ALB target group. The diffs for i-09d6479fb9b97d123 and i-0464c4413cb0c54aa only show public DNS/public IP becoming unknown after apply, which is normal computed behavior and not evidence of harmful reassociation. I found no Route53, CloudFront, WAF, security-group, ALB listener, target-group, or subnet changes that would make this EIP movement break external routing or expose the ALB incorrectly.

There may be a brief loss of direct access to the single replaced EC2 instance that currently owns 13.134.236.98, but that is not the risk described in the hypothesis about ALB public reachability, DNS inconsistency across managed endpoints, or network-segmentation regression. After active investigation, the hypothesis appears to be driven by Terraform showing computed public-IP fields as unknown during instance replacement rather than by an actual dangerous networking change.

✖ Hypothesis disproven

---

💥 Blast Radius

Items 83

Edges 189

[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 7 · Edges 23

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Found 2 high risks requiring review

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 2 · Medium 0 · Low 0

---

💥 Blast Radius

Items 83 · Edges 189

---

View full analysis in Overmind ↗