test(cli): local AWS e2e harness + fail-fast validation guards

[kylehounslow]

What

Users reported a silent failure running the VPC install: a security group with no egress rule left the demo EC2 instance unable to send anything out, so no data reached OpenSearch. Nothing errored, the stack built clean and stayed empty.

This PR adds a security-group check to catch that class of failure up front, plus a local e2e test harness that reproduces and guards the full VPC data path (which is how the failure was confirmed and fixed).

Additional Note to reviewers.

There is currently no security-approved mechanism to run e2e tests on an AWS account from GitHub. These e2e tests can be run on developer AWS accounts until automation is available.

Security-group check

checkSecurityGroupRules (in aws.mjs, called from executePipeline after VPC topology validation) describes the stack's security groups and warns about rules that break the data path, before the ~30-minute build. It validates existing bring-your-own groups; it does not create or modify one. Warnings only, never blocks: traffic may route via other groups, a NAT, or NACLs the CLI can't see.

Rules checked across the union of the stack's groups:

• Intra-VPC egress 443 (always): OSIS to domain, and with a demo, demo collector to OSIS ingest.
• Internet egress 443 to 0.0.0.0/0 (only with a demo): the instance bootstraps over the public internet (package install, GitHub clone, image pulls), which does not use the VPC-private endpoint. A VPC-scoped rule does not satisfy this.
• Intra-VPC ingress 443 (always): OSIS from demo, domain from OSIS.

When the role lacks ec2:DescribeSecurityGroups, it returns one warning listing the rules to verify by hand.

Not covered: routing. A 0.0.0.0/0 egress rule is useless if a private subnet has no NAT route or a public one has no IGW. The check does not inspect route tables or NACLs.

E2E harness

E2E tests don't run in CI (GitHub Actions has no AWS credentials), so the VPC data path had no repeatable proof. The harness under aws/cli-installer/test/e2e/ creates a full stack against a real account, drives telemetry through it, verifies the data lands, and tears it down.

• scenarios.mjs: scenario matrix and a pure CLI-arg builder.
• verify.mjs: synthetic OTLP push and data-flow verification via the OpenSearch Application endpoint (/api/console/proxy _count).
• run.mjs: live runner (create, drive, verify, destroy).
• e2e-unit.test.mjs: 41 unit tests over the pure logic, no AWS calls.

npm test runs the src unit tests plus the harness unit tests (134 total). Live scenarios are opt-in; VPC scenarios need E2E_VPC_ID / E2E_SUBNET_IDS / E2E_SECURITY_GROUP_IDS and are reported skipped, not failed, when unset.

Scenario	Backend	Network	Demo	Data flow verified
managed-public-demo	Managed	Public	EC2 OTel-demo	yes
managed-public-nodemo	Managed	Public	Synthetic OTLP	yes
serverless-public-nodemo	Serverless	Public	Synthetic OTLP	yes
managed-vpc-demo	Managed	VPC-private	EC2 OTel-demo	yes
managed-vpc-nodemo	Managed	VPC-private	none	create/destroy only

Verification queries through the Application endpoint, which is reachable from outside the VPC. managed-vpc-nodemo is create/destroy only because its ingest endpoint is VPC-private (RFC-1918); managed-vpc-demo proves in-VPC data flow because the demo runs in-VPC.

Validation

• 134/134 unit tests pass.
• All four data-flow scenarios ran green on a sandbox account (us-east-1). managed-vpc-demo verified logs=965 / spans=633 / service-map=4 through the Application endpoint from outside the VPC.
• The SG check was validated live against the reported failure: stripped egress triggers the warning; a VPC-CIDR-only group fails the demo internet-egress check and passes under --skip-demo; a self-referencing group with default egress produces none.

[kylehounslow]

Superseded by upstream opensearch-project#344 (same head branch).