Module services 

The two calls outside the MicroVMs API that ensure_image makes: the caller’s account, for the image ARN, and the artifact upload (#221, IMAGE-8).

Why these are hand-signed here rather than an SDK

The same reason the control plane is (super::transport): one HTTP stack, one TLS implementation, one credential chain. aws-sdk-s3 and aws-sdk-sts would each bring a smithy client this crate turned off on purpose. Two operations — GetCallerIdentity and a single-part PutObject — are small enough to sign with the aws-sigv4 the control plane already uses, and the credentials come from the same default chain ([super::transport::default_credentials]), so the ARN, the upload, and the create are one identity.

Why the account comes from STS

GetMicrovmImage takes an ARN, and the service rejects a bare name, so the image ARN has to be built as arn:aws:lambda:<region>:<account>:microvm-image:<name> before the first describe. GetCallerIdentity is the one call that answers the account for any identity — a user, a role, an SSO session — and needs no permission to make. It is made once per Sandbox and cached there.

The seam

BuildServices is the trait Sandbox::with_build_services takes, the way ControlPlane::with_transport takes a super::transport::Transport: a test records the calls and answers them, and production builds SignedBuildServices on the first ensure_image.

Structs

SignedBuildServices

STS and S3 over SigV4, with the default credential chain.

Traits

BuildServices

The seam ensure_image reaches STS and S3 through.