SYSTEM Cited by 5 sources
AWS Fargate¶
What it is¶
AWS Fargate is AWS's serverless container runtime — a compute engine for containers where AWS operates the underlying hosts and the customer provides only the container image + task/pod spec. Supported substrates are ECS tasks and EKS pods. Compared to EC2 launch-type ECS/EKS, Fargate shifts host-level operations (patching, scaling, placement) to AWS and bills per vCPU/GB/sec of container runtime.
Stub page — minimal viable to support the agentic-development ingest. Expand on future Fargate-internals sources.
Role in this wiki — same image runs locally¶
Named by the AWS Architecture Blog's agentic-AI-development essay as the container-workload peer to ECS in the local-emulation-first ladder:
"Containers offer similar benefits for services that run on Amazon Elastic Container Service (Amazon ECS) or AWS Fargate. By building and running the same container images locally, an agent can validate application behavior before deploying to the cloud." (Source: sources/2026-03-26-aws-architecting-for-agentic-ai-development-on-aws)
The structural property the post leverages: the image is the deliverable, so "build once, run anywhere" lets the agent iterate against a local docker daemon + escalate to Fargate only for scale / integration / config validation. Same Dockerfile, same runtime, same entrypoint — cloud is another execution context, not a rewrite.
Seen in¶
- sources/2026-09-30-aws-how-mhk-built-a-hipaa-eligible-agentic-ai-solution-on-amazon-bedrock — Fargate hosts the Spring Boot Agent Orchestration Core of MHK's SmartProminence AI Orchestrator — the central component (and only one with direct database access) exposing the REST API for job submission, workflow management, LLM proxying, and token management. The stateless controllers and LLM processing agents also run as containers on ECS Fargate and scale horizontally off the SQS queue depth, independent of workflow logic — the stateless, serverless-container substrate under an event-driven controller-agent system. (Source: sources/2026-09-30-aws-how-mhk-built-a-hipaa-eligible-agentic-ai-solution-on-amazon-bedrock)
- sources/2026-09-10-aws-building-resilient-real-time-streaming-workers-with-amazon-dynamodb-leases — Fargate runs the stateful WebSocket worker fleet in AWS's DynamoDB-lease pattern. Two Fargate properties are called out as load-bearing for lease correctness: (1) Amazon Time Sync keeps clock skew between same-Region tasks within a few ms — essential because lease expiry is evaluated against the caller's local clock, not a server clock, so the default 20 s lease has ample margin; off-Fargate deployments must verify NTP and widen the lease by max expected skew. (2) SIGTERM on task stop (rolling deploy / scale-in) triggers the worker's graceful-shutdown handler to release leases immediately. Per-connection memory (~2–5 MB per WebSocket) drives the CPU/memory profiling behind the 700-connections-per-task ceiling. (Source: sources/2026-09-10-aws-building-resilient-real-time-streaming-workers-with-amazon-dynamodb-leases)
- sources/2026-03-26-aws-architecting-for-agentic-ai-development-on-aws framing: "build and run the same container images locally ... validate application behavior before deploying to the cloud."
- sources/2026-08-20-aws-how-agentflo-built-ai-sales-agents-with-amazon-bedrock-agentcore — the messaging layer for AgentFlo's WhatsApp sales agents (behind an ALB): auth, image OCR, STT/TTS, pre-turn guardrails, prompt-injection detection.
- sources/2026-08-21-aws-how-agentflo-built-ai-sales-agents-with-amazon-bedrock-agentcore-part-2 — Part 2 makes the Fargate layer the pre-request stage of AgentFlo's three-layer guardrails: it detects prompt injection, handles opt-outs, and authenticates callers (WhatsApp phone-number identity; enterprise-restricted vs. open deployments) before requests reach the agent.
- sources/2026-04-08-aws-build-a-multi-tenant-configuration-system-with-tagged-storage-patterns — Fargate runs the NestJS Order + Config services of the multi-tenant tagged-storage architecture in private subnets, with an ALB in front + API Gateway / VPC Link at the edge. Shared IAM execution role is called out as the infrastructure-layer tenant- isolation ceiling — stepping up to per-tenant credentials would require the TVM + STS pattern.
Related¶
- systems/amazon-ecs — ECS tasks can run on Fargate (serverless) or EC2 (customer-managed).
- systems/aws-eks — EKS pods can run on Fargate or EC2 node groups or EKS Auto Mode.
- concepts/local-remote-parity — umbrella concept for the tier 1 feedback loop.
- local-emulation-first — the pattern that makes Fargate's image-centric model a feedback-loop win.
- systems/smartprominence-ai-orchestrator — Fargate as the Spring Boot orchestration-core + stateless controller/agent substrate.
Bosch L.OS orchestration runtime¶
Bosch L.OS uses auto-scaling Fargate tasks for the central Tracking Connector, separating its shared orchestration scale from independently deployed provider adapters on Lambda. The article attributes horizontal scale without manual intervention to this ECS/Fargate-plus-Lambda split, but does not disclose task sizing, scaling thresholds, or concurrency. (Source: sources/2026-08-14-aws-serverless-vehicle-tracking-at-scale-bosch-los-on-aws)
AgentFlo messaging layer¶
AgentFlo runs its messaging layer on Fargate behind an ALB: it handles authentication, image OCR, speech-to-text/text-to-speech (Opus OGG → MP3 transcription with fuzzy product-name matching), pre-turn security guards, and prompt-injection detection before validated requests flow into AgentCore Runtime. Fargate here is the always-on ingress/preprocessing tier, scaling independently of the microVM-isolated agent execution tier. (Source: sources/2026-08-20-aws-how-agentflo-built-ai-sales-agents-with-amazon-bedrock-agentcore)