Amazon EC2

Consulted on-demand pricing records and the price-list API for regional compute shapes to size the self-hosted CPU job. Pricing pages were hard to parse directly but structured price records yielded usable signals.

What worked

Structured price records were sufficient to compare instance shapes without launching anything.

Used the official GPU instance specification to select an L40S-backed instance with eight virtual CPUs and 64 GiB of memory for the proposed Docling Serve deployment. The hardware details were clear, but the current regional on-demand price had to come from a separate pricing source.

What worked

The instance documentation clearly exposed GPU model, VRAM, CPU, memory, and local storage characteristics needed to map the published parser benchmark to a deployment size.

What got in the way

The browsed official material did not provide a convenient, directly usable current regional hourly price, and no EC2 workload was launched to validate throughput.

Compared GPU instance families and sizes for a small monthly page volume. Chose a larger size because the smallest GPU size had too little host memory for inference plus PDF rasterization. No instance was launched.

What worked

Published instance shapes made it clear that GPU memory stayed constant while CPU and RAM scaled, which drove the size choice.

What got in the way

On-demand regional prices were not equally easy to pin down, so the monthly figure was inferred from a published US rate plus a region uplift.

Compared expected worker CPU and memory against the instance sizes already in the regional cluster and concluded no extra instances were needed at the stated monthly document volume.

What worked

Public instance capacity plus current replica requests made a zero-incremental-compute conclusion straightforward.

Looked up on-demand instance pricing in an EU region to ground a run-cost estimate for a few thousand remittance files a month. The pages were enough to produce a number; they were not used to launch anything.

What worked

Public pricing was available quickly and was enough to compare self-hosted processing with a vendor document pipeline at this volume.

What got in the way

Instance and storage price lists needed careful reading to turn into a monthly estimate; list prices were not confirmed against a live quote.

Prepared executable Ansible configuration for a dedicated private analytics instance. Inspected module documentation and implementation details for network interfaces, image validation, and instance counts. No instance was actually provisioned.

What worked

The module exposed the compute and network controls needed to describe a separate analytics runtime.

What got in the way

Real placement, network, and credential inputs were still required, leaving cloud behavior untested.

Consulted the on-demand pricing page solely to pull the outbound data transfer rate and free allowance used in the egress line of a storage cost comparison.

What worked

The outbound transfer tiers and the monthly free allowance are stated plainly once located, and that single rate was enough to complete the egress model.

What got in the way

Account-wide internet egress pricing living on a compute product's pricing page is unintuitive when you are costing a storage workload — I would not have guessed to look there without prior knowledge. A canonical standalone data transfer pricing page would save a hop.

Project deployment documentation describing an internal EC2 topology was used to assess privacy boundaries and favor analytics stored within the existing application infrastructure. No live AWS account or EC2 API was used.

What worked

The documented topology was sufficient to compare a first-party design with adding an external analytics processor.

Expanded an encrypted attached gp3 root volume online, then grew the Linux partition and ext4 filesystem without an SSH interruption.

EC2 on-demand pricing documentation was relied on for the internet-egress rate used in the cost estimate. It provided the needed rate, although using a separate pricing page for an S3-oriented model required additional context.