Test new version

[dylanratcliffe]

No description provided.

[github-actions]

Caution

[High Risk] New API instance will create a direct EC2 HTTP endpoint in the public ALB subnet

The change adds a new production API EC2 instance in subnet-07b5b1fb2ba02f964 and boots a Python HTTP service bound to 0.0.0.0:9090. It reuses the shared security groups sg-03cf38efd953aa056 and sg-089e5107637083db5, which already protect an existing public instance in the same subnet. This creates another directly reachable EC2 endpoint in the internet-facing ALB subnet instead of keeping the instance behind dedicated load-balancer controls, which conflicts with SEC05-BP01, REL02-BP01, and the organization's rule that EC2 instances must not be directly reachable from the internet.

Because those security groups are shared, attaching them to another host expands every existing CIDR-based ingress rule to an additional target. The new host will answer on port 9090 to internal 10.0.0.0/8 sources and may also become publicly reachable through the same public-IP/EIP pattern already used by i-01b022d745b7fa2ab, bypassing ALB/WAF policy, listener routing, and centralized edge controls. That increases the attack surface and exposes a new unmanaged HTTP endpoint in production.
_{View reasoning tree here.}

Caution

[High Risk] Production EC2 instances are being left publicly reachable while root storage remains unencrypted

The change leaves 540044833068.eu-west-2.ec2-instance.i-014d43042fc546607 on an unencrypted root EBS volume and introduces a new production EC2 instance in the same environment with a direct public endpoint. Blast radius shows the existing root volume 540044833068.eu-west-2.ec2-volume.vol-0c301c7f1065c61f6 has Encrypted: false, while organizational policy requires all EBS volumes to be encrypted with no exceptions. It also shows the existing instance already has public IP 35.177.248.251, and the new production-api-server design places an instance in the public subnet and, in the live environment, results in a public IP assignment as well.

That combination creates a real security and compliance failure rather than a hypothetical best-practice gap: production compute is being exposed directly while local root storage remains unencrypted. If either instance is compromised, data and configuration stored on the root volume are not protected at rest, and the change does not remediate that condition. This is a high-severity risk because it violates explicit security policy and increases the blast radius of an internet-exposed EC2 compromise.
_{View reasoning tree here.}

Signals

Routine → Multiple AWS access and notification resources showing unusual and infrequent change patterns at 1-2 events/week for the last 3 months, including load balancer attachment activity at 1 event/week for the last 3 months and subscription activity at 2 events/week for the last 3 months.
Policies → Multiple infrastructure resources showing unusual policy violations that may need review: the S3 bucket 'does not have server-side encryption configured' and 'is missing the required' tags, while the security group 'allows SSH (port 22) access from anywhere (0.0.0.0/0)'.

_{Additional Change Details:} Items 135 Edges 243 model|risks_v6 ✨Encryption Key State Risk ✨KMS Key Creation