Data Flow & Architecture — Cam Uptime Fleet

Metadata-only Ring camera uptime monitoring · All infrastructure in AWS us-east-1

Cam Uptime Fleet is a metadata-only service. It monitors whether Ring cameras are online or offline and reports uptime and SLA information. It never retrieves, views, stores, or processes any video, snapshot, live view, or image. This page documents where data lives and how it flows between systems, for Ring App certification.

No media anywhere. There is no video, image, snapshot, or media store in this architecture. The application never calls any Ring media, snapshot, or live-video endpoint, and no media is ever retrieved or persisted. Every system below handles device status metadata and timestamps only.

Region: AWS us-east-1 TLS/HTTPS in transit AES-256 at rest (KMS) HMAC-SHA256 webhooks Least-privilege IAM CloudTrail + CloudWatch

Data flow between systems

The diagram shows the request and event paths through the system. Everything runs inside AWS us-east-1. The single Node 20 Lambda cuf-api serves the HTTP API, the SQS alert worker, and the scheduled reconciliation sweep.

Solid arrows are request/write paths; dashed arrows are event triggers and outbound status reads. The Ring device-list read during reconciliation returns device status metadata only — no media.

Flow, path by path

Ingress. The Ring Partner API and operator browsers reach Amazon API Gateway (HTTP API on the custom domain fleet.erbacciltd.com, TLS), which invokes AWS Lambda cuf-api (Node 20). API Gateway strips the named-stage prefix before routing.
Webhook path. Ring sends device_online / device_offline (and other) webhooks. The Lambda verifies the HMAC-SHA256 signature on the RAW request body, writes the new device status to Amazon DynamoDB, and enqueues alert work to Amazon SQS (with a dead-letter queue). An SQS-triggered worker (the same Lambda) then sends email via Resend, the transactional email provider.
Account linking. A Ring OAuth authorization code is delivered to /account-link. The Lambda exchanges the code for tokens and stores them encrypted in DynamoDB. Tokens are never exposed on the client side.
Reconciliation. Amazon EventBridge Scheduler invokes the Lambda about every 10 minutes. It reads device status metadata from the Ring device-list API (one call per organization) and repairs any webhook that was missed, updating DynamoDB. No media is read.
Dashboard / UI. The operator's browser loads the dashboard served by the same Lambda at fleet.erbacciltd.com, then makes same-origin /api/* calls. Authentication is passwordless email-OTP with bearer-token sessions.

Data storage locations & systems

All storage is in AWS us-east-1, encrypted at rest with AES-256 via AWS KMS. The systems below are the only places data is persisted. Each holds device status metadata, operational records, or secrets — never media.

System	What it stores	Protection
Amazon DynamoDB 10 `cuf-*` tables	Device online/offline status, sites, SLA & event history (timestamps and durations), org/user records, and encrypted account-linking tokens. Metadata only.	AES-256 at rest via AWS KMS; point-in-time recovery (PITR) enabled; least-privilege IAM.
Amazon SQS alert queue + DLQ	Transient alert-job messages (which device, which org, timing) awaiting the email worker; failures land in the dead-letter queue for retry.	Encrypted at rest; consumed and drained by the Lambda worker only.
AWS Secrets Manager	Application secrets, including the Resend API key read at runtime.	AES-256 at rest via KMS; scoped least-privilege `GetSecretValue` read.

Explicitly: there is NO media/video/image/snapshot store. No S3 media bucket, no clip archive, no frame cache, no thumbnail store — nothing. The application never retrieves or stores any media, so there is no media at rest anywhere in this architecture.

Security & observability

In transit: TLS/HTTPS everywhere (API Gateway custom domain, outbound calls to Ring and Resend).
At rest: AES-256 via AWS KMS on DynamoDB, SQS, and Secrets Manager.
Access: least-privilege IAM roles; account-linking tokens stored encrypted and never exposed client-side.
Integrity: inbound Ring webhooks are HMAC-SHA256 verified on the raw body before any processing.
Auditing: AWS CloudTrail for API/management activity and Amazon CloudWatch for application logs and metrics.