Pyvorin on AWS

Running Pyvorin Native 1.0.9 on AWS is mostly a question of baking the right things into an AMI and activating at the right moment. The package runs on EC2 exactly as it runs on any other Linux x86_64 host — compilation is local and in-process, the compiled artefacts are ordinary files, and the licence binds to the instance it is activated on. This page covers the four decisions that actually matter: instance family selection, artefact baking, Auto Scaling behaviour, and a cost model that labels its assumptions instead of hiding them. Where a number comes from the benchmark suite rather than from your own measurement, it says so.

Instance considerations

One hard constraint and one soft one. The hard constraint: pyvorin-native 1.0.9 ships a single binary wheel, built for CPython 3.12 on Linux x86_64. That excludes ARM-based instance families — AWS Graviton among them — from running the package at all. If your fleet standardises on Graviton for cost, Pyvorin is not part of that fleet's answer in this release. The soft constraint is SIMD: Pyvorin's vectorised kernels target x86_64 SIMD, and the compiler's runtime detects what the CPU exposes. On our unremarkable test host, the shipped command reports:

$ python -m pyvorin simd-info
Pyvorin SIMD Kernel Registry
AVX2 detected: yes

Registered kernels (81):
  ...

Eighty-one kernels registered, AVX2 present. Pyvorin does not enumerate AWS instance SKUs, and we will not invent a compatibility matrix; the honest statement is that current-generation x86_64 instance families expose AVX2-class SIMD, and the verification step costs seconds on any instance you actually intend to use — run the command above, confirm AVX2 detected: yes, and let your capacity tests do the rest. Base images need Python 3.12 to match the wheel. A simple way to honour both constraints in one place: pin the AMI to a 3.12 base, pin the package version in the dependency manifest, and let the AMI build fail loudly if either resolve drifts.

Baking compiled artefacts into an AMI

The AMI build is where the value is created. Compile the application during the bake — not at instance start — and the cache ships inside the image:

# Inside the AMI build, after the application source is final
python -m pyvorin compile /opt/app/pipeline.py --fail-on-fallback
python -m pyvorin run /opt/app/pipeline.py --function run --compare --runs 5

Compilation populates <site-packages>/.pyvorin_cache/disk_compile with checksum-validated shared objects, keyed by a hash of the source, function names, compiler options and runtime modification times. Two consequences drive the bake procedure. First, the cache is bound to the exact package build and flags that produced it, so the AMI must contain the same pinned package version and compiler options as the build step that compiled it. Second, source must be byte-identical between compile time and run time; compiling as the final image step, after all source mutations, is the simplest way to guarantee it. The --fail-on-fallback gate means an AMI whose application does not compile fully fails the build instead of silently shipping an interpreter-speed instance. The full cache-shipping scheme, including the CI side, is on the CI artefact caching page and the warm-up and caching strategies page.

Auto Scaling and the compile-cost question

Auto Scaling groups make the bake decision concrete. A scale-out event launches a fresh instance and adds it to the serving pool; every second between launch and readiness is capacity you are paying for without using. If the AMI is baked as above, the instance loads pre-compiled artefacts from its first call and readiness is bounded by your application startup, not by compilation. If it is not baked, every instance that boots pays the compile cost for every function it touches — on our test host a typical numeric function compiled in roughly 259 milliseconds, which sounds small until a scale-out event launches fifty of them into the same minute and the slowest readiness sets the pool's effective response time. Bake. The one thing baking does not remove is the licence step, which follows.

Licensing on disposable instances

Activation is device-bound. The fingerprint is derived from hostname, username and instance machine identity, so each EC2 instance is its own licensed device, and a licence baked into an AMI is a licence bound to an identity that no longer exists at boot — it will not carry. The working pattern: activate at instance start. A first-boot script reads the key from an external source — instance user data from a Secrets Manager retrieval, never the key itself in plain user data — and runs pyvorin activate followed by pyvorin check before joining the pool.

The failure semantics are verified and worth designing around. Once activated, a signed lease validates locally; if the lease lapses, offline grace runs to 24 hours on demo and trial tiers, 72 hours on basic and professional, and 90 days on enterprise, with a server-issued offline permit budgeting additional hours. A scaling event that launches instances into a network partition therefore degrades gracefully: instances already activated keep running within their grace windows, and only genuinely unlicensed states fail the gate. The complete semantics are on the activation and entitlement page, and the full outbound list — two endpoints, key-plus-fingerprint and event metadata — is on the network requirements page. The 30-second activation timeout on first boot is a fine fit for health-checked pools.

Security groups can be correspondingly tight, which is a property worth using: the instance needs its normal application traffic plus HTTPS to api.pyvorin.com for activation, revalidation and the telemetry flush. There is no second licensing host, no update-check endpoint and no artefact download to permit — the compile path generates no network traffic of any kind.

A labelled cost model

The model we use internally, and the one we recommend, refuses the shortcut from benchmark to bill. It is illustrative — every input below is an assumption to be replaced with your measurements, and the licence is shown separately from infrastructure.

Start from your own speed-proof number, not a suite figure: run python -m pyvorin run app.py --function run --compare --runs 5 on the instance family you intend to use, and call the measured ratio S. The theoretical resource reduction on the accelerated workload is then 1 − 1/S. Illustrative values: if your measured S is 4.6x — the suite's etl category geomean, chosen here only as a placeholder — the theoretical reduction is about 78%. Now apply a realisation factor, because infrastructure is not perfectly elastic: you cannot always shrink an Auto Scaling group to its theoretical minimum, minimum capacity, redundancy and headroom all persist. A conservative realisation of 50% turns 78% into roughly 39% of the acceleratable workload's compute; an expected case might use 65%. Add back the fixed infrastructure that does not scale — load balancers, databases, idle headroom — then show the gross annual saving, the Pyvorin licence separately, and the net.

Two cautions keep the model honest. The suite-wide median of 1.35x is the typical workload's result, and at 1.35x the theoretical reduction is only about 26% before realisation — batch-transform and scoring services are the shapes where S is high enough to matter, and the suite's seventeen slower-than-CPython workloads are a reminder that some code should not be compiled at all. Second, speedup converts to savings only where spend scales with the accelerated workload: an Auto Scaling batch fleet qualifies; a fixed-size always-on instance does not, and its saving is capacity headroom, not money. The worst thing a cost model can do is multiply a benchmark by a bill. This one does not.

Where to go next

• How to run a speed proof — produce the measured S on your instance family.
• How to cache artefacts in CI — the cache-key scheme behind AMI baking.
• Activation and entitlement — device binding, leases and grace windows in full.
• Pyvorin vs CPython — what the compiler changes and what it deliberately leaves alone.

Last reviewed 24 June 2026 against pyvorin-native 1.0.9 installed at /root/pvfinal (verified build of 12 September 2026). The simd-info output quoted was captured on this host on 13 September 2026. Cost-model scenarios are illustrative and labelled as such; all figures in them are assumptions, not measurements of your environment. Suite figures are from the canonical 2026-09-13 benchmark artefact.