​

NomadicML on AWS

This page describes how the video analysis platform is deployed in AWS, how data moves through it on the read and write paths, and how client applications reach it privately over AWS PrivateLink.

​

General Architecture

The platform runs inside a NomadicML-managed VPC. Client applications never reach it over the public internet. They connect through an interface VPC endpoint in their own VPC, which AWS PrivateLink joins to a VPC endpoint service we publish. Everything behind that endpoint service (load balancer, application tier, storage and inference) runs in private subnets with no public IP address.

​

Key Components

​

Read Path

A client asks for job status, analysis results, or the media behind them. The request enters through the endpoint service and is served from the two data stores inside the VPC.

​

Read Path Flow

1. Client application sends the request through AWS PrivateLink, resolving a private DNS name to the interface endpoint in its own subnet.
2. Endpoint service accepts the connection from an allow-listed principal and passes it to the internal load balancer.
3. API service authenticates the API key and resolves what was asked for: job status, an analysis document, or media.
4. DocumentDB and Amazon S3 return the analysis document and the video or derived artifacts behind it. Results travel back on the connection the client already opened.

​

Write Path

Upload and analysis are decoupled, so a long-running analysis never holds a client connection open.

​

Write Path Flow

The API service writes video to Amazon S3 synchronously and records a job document in DocumentDB, then returns. The upload is complete at that point. Analysis workers claim the queued job on a lease, marking it in progress so no two workers take the same job, and call Amazon Bedrock for inference. As they run they publish progress events to an ElastiCache stream, which the API service relays to the client as server-sent events. Finished results are written back to DocumentDB and derived artifacts to S3, where the read path picks them up.

​

Private Connectivity

AWS PrivateLink is two resources, one in each account. NomadicML publishes the VPC endpoint service; the client creates an interface VPC endpoint in their own VPC. Traffic between them rides the AWS backbone.

• The connection is one-way. The client initiates. NomadicML cannot reach back into the client VPC, so exposure is limited to the single published service rather than a route between two networks.
• Consumption is allow-listed. The endpoint service names which AWS principals may create an endpoint against it, and each connection request is accepted individually.
• No address-space coordination. Traffic terminates on an interface in the client’s own subnet, so overlapping CIDR ranges are irrelevant.
• Nothing needs a public IP. The client side needs no internet gateway or NAT for this path, and the load balancer is internal.

The equivalent primitive on GCP is Private Service Connect and on Azure is Private Link Service. All three follow the same publish-and-consume shape.

​

Deployment Models

Three options, differing in whose account holds the application and whose holds the data. Setup steps for the in-VPC model are covered in Self-Hosted VPC Setup.

​

What You Provide

For a PrivateLink connection to the managed service, the client side needs very little.