v1.3.31 — Lambda multi-account isolation, EC2 BlockDeviceMappings, S3 versioned Last-Modified, EC2 managed prefix lists

May 7, 2026 · v1.3.31

Four community-driven fixes landed in 1.3.31. Three are AWS-spec parity bugs that real users hit in production-shaped tooling (Cloud Custodian, AWS SDK for JavaScript v3, the Java SDK v2). The fourth is a deterministic mock for AWS-managed prefix lists that unblocks Gateway-type VPC endpoint provisioning.

Lambda multi-account isolation

When a Lambda function is deployed under a non-default account, MiniStack now passes the correct AWS_ACCESS_KEY_ID into the runtime — derived from the function ARN — instead of the host process's env var. STS GetCallerIdentity from inside the handler now resolves to the owning account, and every internal SDK call from the handler authenticates against the right tenant.

The fix covers all four execution paths (warm worker, provided runtime, local subprocess, Docker container) and the warm-worker pool key is now {account}:{function}:{qualifier}, so two accounts that deploy the same function name no longer share a worker:

def _account_from_arn(arn: str) -> str:
    parts = arn.split(":")
    if len(parts) >= 5 and _12_DIGIT_RE.match(parts[4]):
        return parts[4]
    return os.environ.get("AWS_ACCESS_KEY_ID", "test")

Function-level Environment.Variables overrides still take precedence over the derived account credentials. Contributed by @jgrumboe.

EC2 RunInstances and DescribeInstances emit BlockDeviceMappings

Real AWS always returns at least one BlockDeviceMappings entry on every EBS-backed instance — the auto-attached root volume — regardless of whether the launch request specified one. Cloud Custodian, AWS Config rules, and any policy tool that classifies instances by storage type breaks if that field is empty.

MiniStack's RunInstances now synthesises a real root EBS volume on every launched instance: /dev/xvda, gp3, 8 GiB, DeleteOnTermination: true, registered in the volume catalog so DescribeVolumes also surfaces it with the matching Attachments link back to the instance:

{
  "BlockDeviceMappings": [
    {
      "DeviceName": "/dev/xvda",
      "Ebs": {
        "VolumeId": "vol-...",
        "Status": "attached",
        "AttachTime": "...",
        "DeleteOnTermination": true
      }
    }
  ]
}

Reported by @Aeres-u99.

S3 GetObject by VersionId — Last-Modified is now RFC 7231

The non-versioned GetObject path already wrapped its Last-Modified header through iso_to_rfc7231 to produce an HTTP-date like Tue, 06 May 2026 14:30:00 GMT. The versioned path (GET /bucket/key?versionId=...) was a missed spot — it emitted the internal ISO-8601 timestamp directly into the HTTP header. AWS SDK for JavaScript v3 deserialises this header strictly and threw after the 200 response, breaking application code that retrieved non-latest object versions.

Fixed by passing the same iso_to_rfc7231 wrapper that the rest of the file uses. Contributed by @mgius-ae.

EC2 AWS-managed prefix lists return deterministic CIDRs

DescribePrefixLists, DescribeManagedPrefixLists, and GetManagedPrefixListEntries previously returned 0.0.0.0/0 as a placeholder, which made VPC endpoint provisioning of type Gateway non-deterministic across runs.

The dispatcher now generates deterministic prefix list IDs and CIDRs from name hashes for the standard AWS-managed names (s3, dynamodb, s3express, vpc-lattice, route53-healthchecks, ec2-instance-connect, cloudfront, groundstation). IPv4 entries use the CGNAT range (100.64.0.0/10); IPv6 uses 64:ff9b:1::/48. Reverse lookup resolves prefix list IDs to AWS-managed names, and the prefix-list-id + owner-id filters work. Contributed by @jgrumboe.

Upgrade

docker pull ministackorg/ministack:1.3.31
docker run -d -p 4566:4566 ministackorg/ministack:1.3.31

Or pin in compose.yaml:

services:
  ministack:
    image: ministackorg/ministack:1.3.31
    ports:
      - "4566:4566"