Skip to content

feat(aws): export the MicroVM service limits MicrovmApp enforces - #1403

Merged
lex00 merged 1 commit into
mainfrom
export-microvm-limits
Aug 3, 2026
Merged

feat(aws): export the MicroVM service limits MicrovmApp enforces#1403
lex00 merged 1 commit into
mainfrom
export-microvm-limits

Conversation

@lex00

@lex00 lex00 commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Closes #1374.

MicrovmApp encodes the Lambda MicroVMs service's real limits — five memory tiers, name pattern and length, environment-variable cap, connector bounds — verified against the upstream CDK construct and the AWS docs. All module-private, so a consumer driving the same service through a different control plane had to copy them.

kubemicrovm-ops does exactly that: its tier profile declares the five memory sizes a second time and its lint pack a third, while its own design page names this composite as the source of truth for two planned rules it cannot import.

One named object rather than seven loose constants:

export const MICROVM_LIMITS = {
  memoryMiB: [512, 1024, 2048, 4096, 8192],
  namePattern: /^[a-zA-Z0-9-_]+$/,
  maxNameLength: 64,
  reservedEnvironmentKeys: ["AWS_REGION"],
  maxEnvironmentVariables: 50,
  maxEgressConnectors: 10,
  connectorSubnets: { min: 1, max: 16 },
} as const;

The composite reads its own validation out of it, which is what keeps the export honest. The test probes the limits through MicrovmApp's public API rather than restating them, so an export and an enforcement cannot drift apart while both look right.

Reachable from the package root, guarded by the barrel test from #1337.

Worth a follow-up: whether other composites hold service limits the same way. This is unlikely to be the only one, and the general shape — a composite knowing something real that nothing else can reach — is the thing.

The composite encodes the service's real limits — the five memory tiers,
the name pattern and length, the environment-variable cap, the connector
bounds — verified against the upstream CDK construct and the AWS docs. All
of it was module-private, so a consumer driving the same service through a
different control plane had to copy the numbers.

kubemicrovm-ops does exactly that: its tier profile declares the five
memory sizes a second time and its lint pack a third, while its own design
page names this composite as the source of truth for two planned rules it
cannot import.

One named object rather than seven loose constants, so the shape is
discoverable and a new limit has an obvious home. The composite now reads
its own validation out of it, which is what keeps the export honest — a
test probes the limits through MicrovmApp's public API rather than
restating them, so the two cannot drift while both look right.

Worth checking whether other composites hold service limits the same way.
This is unlikely to be the only one, and the general shape — a composite
knowing something real that nothing else can reach — is the thing.
@lex00
lex00 merged commit 1fefebf into main Aug 3, 2026
5 checks passed
@lex00
lex00 deleted the export-microvm-limits branch August 3, 2026 04:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MicrovmApp's service limits are module-private, so consumers redeclare them

1 participant