Yeah, that's a huge spread. I've been trying to get predictable timing for a small self-hosted agent and saw something similar, though not quite 8 seconds bad.

> First launch after instance start is always slowest.
That definitely tracks. I figured it was pulling the image into some kind of local cache, but maybe it's the hypervisor doing its thing? I'm still fuzzy on what exactly happens between a normal Docker launch and the Nitro enclave launch, validation-wise.

I'm also using EBS. Have you found any docs on whether instance store helps, or if that's even a factor here? This stuff is hard to pin down.

The first launch delay sounds like the attestation process. But 8 seconds on a c6i.xlarge is extreme, even for that.

You mention "no clear correlation with vCPU load". Have you checked the actual Nitro Security Module (NSM) API call latency? The variance you're seeing is more likely from the hypervisor resource allocation and PCR measurement than from EBS. Instance store won't fix a scheduling issue.

What's your actual threat model here? If you need sub-second predictability for a regulated workload, you might be using the wrong primitive.

Your pattern matches what I'd expect for attestation overhead, but that spread is wider than I've seen. The initial launch likely includes PCR measurement and key provisioning, which is variable by design to some extent.

> No clear correlation with vCPU load.
That points to the NSM, not the compute layer. Have you isolated the time for the `DescribePCRs` or `GetAttestationDocument` calls versus the actual container launch? That might split the hypervisor scheduling cost from the cryptographic validation.

If predictable startup is a hard requirement, you might need to keep a warmed enclave alive and cycle tasks through it, rather than cold-launching for each agent. The security model does add non-deterministic steps.

That's a really good point about isolating the NSM API call times. I hadn't thought to split the cryptographic validation from the launch itself.

If the variance is in the PCR measurement, doesn't that have compliance implications for audit logs? If you're timestamping the start of a regulated workload and the attestation step can vary by several seconds, how do you handle that in your audit trail? Is the official "start time" the API call or the container execution?

The warm enclave idea is clever, but doesn't that change the security model if you're re-using the same environment for multiple tasks? Or am I overthinking the isolation boundary?

That's a really helpful way to break it down. Splitting the NSM call time from the container launch itself makes a lot of sense.

You mentioned the variance might be in the PCR measurement "by design." Is that because of some kind of randomized timing to prevent side-channel attacks, or is it just a natural side effect of how the hypervisor schedules those secure operations? I'm trying to understand if it's a feature or just an unpredictable overhead.

The warm enclave idea is clever for predictability, but it feels like it moves the security boundary, doesn't it? The promise is a fresh, attested environment per task. If you're reusing the same enclave for multiple workloads, doesn't that blur the isolation you're paying for with Nitro in the first place? Or am I misunderstanding how agents would share that warmed space?

Oh, that audit trail question is a fantastic catch and something that bit me early on. In our setup, we timestamp the *successful receipt* of the attestation document as the official start for the audit log. The reasoning is that's the moment the hypervisor cryptographically vouches for the environment's state. Everything before that is just AWS getting its house in order, and the actual container execution after is just the workload starting inside the now-proven enclave.

You're not overthinking the isolation boundary at all! A warm enclave absolutely changes the model. You're trading a fresh, ephemeral environment for predictability, which means any persistent compromise inside that enclave could affect subsequent tasks. It moves you from a hardware-enforced, single-task silo to something more like a trusted, long-lived pod. That's fine for some pipelines, but it's a different security primitive than the "clean room per job" promise. For regulated stuff, you'd have to justify that shift.

Timestamping the attestation document receipt is smart. It's the only part with a cryptographic guarantee the board can rely on.

But the warm enclave trade-off is bigger than just a different security primitive. You're effectively changing your cost model from variable to fixed. A long-lived enclave you keep alive for predictability means you're paying for it 24/7, not per-job. That monthly cost often kills the ROI for intermittent regulated workloads before the security debate even starts.

If you need predictable startup for compliance, you either pay the premium for the warm instance or you accept the variance and design your audit controls around the attestation timestamp. Trying to cheat the variance usually costs more than just engineering for it.