How a watch floor turns a stream of AIS position reports into reviewed alerts, evidence backed investigations and collection tasking, with Amazon Bedrock AgentCore, Amazon Nova, Strands Agents, LangGraph and the Model Context Protocol.
The Problem: Vessels That Go Dark
Every commercial vessel above 300 gross tons broadcasts its identity, position, course and speed through the Automatic Identification System (AIS). Maritime domain awareness leans on that stream. The vessels worth watching are the ones that bend it: a tanker that switches its transponder off for an hour inside a subsea cable corridor, two ships that drift together at sea for a ship to ship transfer nobody declared, a hull that reports the same MMSI from two places at once, a bulk carrier that loiters at the edge of a naval exercise area. Each of these is a small signal inside millions of routine reports, and each one needs context before it means anything: who owns the ship, where has it been flagged, is the operator on a sanctions list, has it done this before.
A watch floor does this work by hand today. An analyst notices a gap on the plot, opens a registry lookup, checks a sanctions screen, pulls the track history, writes a vessel of interest note and decides whether to ask for satellite imagery. The bottleneck is not detection, a rule can find a gap. The bottleneck is the investigation that follows, the judgement about which of the forty gaps this morning deserve an hour of attention, and the record that shows why a decision was made.
Argus is a working system built for that gap. It watches an area, raises alerts, investigates each one across identity, ownership, sanctions and behaviour, writes a Vessel of Interest report with every claim cited to the tool that produced it, and proposes collection tasking. Officers keep every decision: alerts are accepted or rejected, reports are reviewed, tasking is approved or declined. Nothing is tasked and nothing is closed by a model on its own.
Figure 1. How Argus works, from AIS feeds through detection, investigation and reporting to the officer's decisions.
What A Shift Looks Like With Argus
The system runs as a loop with a person at the end of it. A sweep runs every thirty minutes on a schedule, or when an officer presses the sweep button. Detectors scan the last twelve hours of positions for five anomaly kinds and hand fixed candidates to the Watch agent, which decides what to raise and how to describe it. Each alert lands on the watch floor with its evidence attached.
- Sweep: the detectors and the Watch agent turn twelve hours of positions into a short list of alerts, each with a kind, a time window, a severity and the evidence behind it.
- Review: the officer reads the alert, opens the track, and accepts or rejects it. High severity alerts open an investigation automatically; any alert can be investigated on demand.
- Investigation: the Orchestrator runs two Investigator branches in parallel (identity, ownership and sanctions on one side, behaviour on the other), asks the Tasking agent whether imagery is worth collecting, and drafts the report.
- Report: the Vessel of Interest report carries a headline, a timeline, indicators and counter indicators, information gaps, recommended actions and a collection plan. Every evidence line names the tool that produced it.
- Tasking: collection requests arrive as proposals. An officer approves or rejects each one; approval is the only path to a tasked request.
- Record: every state change is an append only audit event that names the actor, human or agent, so a reviewer can reconstruct who did what and when. The scenario used through this article is a scripted eastern Mediterranean baseline with eight fictional vessels and planted anomalies, played on a loop at sixty times real speed. The same stack runs on live AIS from AISStream across six watched regions, and later sections show both.
Design Principles
Five decisions shape everything else in the system. They are recorded as architecture decision records in the repository, eighteen of them at the time of writing, and they explain most of what follows.
- Agents propose, officers decide. Agents can raise alerts, write findings and propose tasking. They cannot approve tasking, close an alert or finalise a report. Human in the loop is enforced in the API, not in a prompt.
- The investigation is a code owned graph. The Orchestrator is a LangGraph state machine whose sequence is fixed in code. The only model call it makes itself is the report draft. No model chooses which agent runs next, so a run is reproducible and its cost is bounded.
- Every claim cites a tool. Findings and reports carry evidence lines in the form server.tool (for example ais.get_vessel_track). A report that cites nothing, or recommends an action outside the allowed set, is rejected by a policy check and redrafted once with the corrections listed.
- Production is Bedrock only, with Amazon Nova. Three model tiers map to Nova Lite, Nova 2 Lite and Nova Pro. Other providers exist for development and evaluation, but the deployed runtimes can only reach first party Bedrock models through a VPC endpoint, and the IAM allowlist enforces that.
- Agents live in an isolated network. The AgentCore runtimes sit in subnets with no route to the internet. Everything they need, Bedrock, the tool gateway, the registry, Secrets Manager, SSM, is an interface endpoint. If an agent is compromised, there is nowhere for it to send data.
Architecture On AWS
The deployment is four CDK stacks (network, data, platform, agents) and nothing is created outside infrastructure as code. The figure below is the complete picture. Reading it left to right: the watch floor and the operators arrive through an edge that signs them in, the platform stack holds the API, the job workers, the scheduler and the databases, the agents plane runs on Amazon Bedrock AgentCore behind two gateways, and the external feeds enter through the ingest task alone.
Figure 2. Argus on AWS: edge, platform, agents plane, tool plane, data and observability, with the trust boundaries drawn.
The Edge
An Application Load Balancer terminates TLS and runs the Cognito sign in itself: every listener for the UI and for Grafana carries an authenticate action, so the browser never reaches an application page without a session. The balancer forwards the signed id token on every request and the API verifies it against the balancer's regional key, checks that the signer is this deployment's balancer and that the issuer is its user pool, and records the officer's email on every decision. AWS WAF sits in front with a per IP rate limit and the managed rule groups for IP reputation, common attacks and known bad inputs. Tooling and evaluation runs bypass the browser sign in on /api/* with a bearer token that the API verifies against IAM, admitting only named roles.
Figure 3. The hosted sign in page. Officers are created by an operator; there is no self sign up, and MFA can be made mandatory with one deployment flag.
The Platform
A FastAPI service is the system of record's front door. It owns alerts, investigations, findings, tasking, review states and the audit log, and it is the only component that writes those tables. Long running work never runs inside a request: the API writes a job row and publishes its id to one of two SQS queues, one for sweeps and one for investigations, and a worker service per queue picks it up. The queues carry ids only. A worker heartbeats the message visibility while the job runs, reclaims a job that a crashed worker left behind, and dead letters the ones that fail for good. EventBridge Scheduler drops the periodic sweep onto the same queue, so a scheduled sweep and a button press take the identical path.
Aurora Serverless v2 with PostGIS holds everything: positions partitioned by day, vessels and the registry, the ownership network, zones, alerts, investigations, evidence snapshots and the audit trail. The ingest task subscribes to AISStream for every watched region in live mode, or replays the scenario, and writes positions straight into the partitions while publishing them on a stream for the map.
The Agents Plane
The four agents and the four MCP tool servers run as Amazon Bedrock AgentCore Runtime endpoints (ARM64 containers, one IAM role per runtime). Two AgentCore Gateways front them. The tools gateway exposes the twenty four tools of the four servers with semantic search and an AgentCore Policy engine in enforce mode: Cedar policies generated from the tool inventory allow each agent exactly the tools it is meant to call and block everything else. The agents gateway carries the agent to agent calls (A2A) from the orchestrator and the workers to the specialists. Agents discover each other through the AWS Agent Registry rather than through environment variables, AgentCore Identity holds the OpenSanctions credential as an API key provider, AgentCore Memory keeps what the system learned about a vessel across investigations, and AgentCore Evaluations scores live sessions online.
| AgentCore capability | How Argus uses it |
|---|---|
| Runtime | Nine endpoints: Watch, Investigator, Tasking, Orchestrator, the four tool servers and the tasking harness pilot |
| Gateway (tools) | One MCP gateway over the four servers, IAM inbound, semantic tool search, Cedar policy in enforce mode |
| Gateway (agents) | Runtime targets for A2A; callers hit //invocations and never a runtime URL |
| Policy | Cedar allow rules per agent generated from mcp-servers/tools.json; a tool added without regenerating is blocked |
| Agent Registry | MCP server records and A2A agent cards, approved on deploy; agents resolve each other by name |
| Identity | API key credential provider for OpenSanctions; the runtime injects the workload token per request |
| Memory | Per vessel long term memory plus raw recent events, so a repeat investigation sees the previous run at once |
| Evaluations | Online evaluators on each agent: built in helpfulness, correctness, tool selection, goal success, harmfulness, plus a report rubric |
| Guardrails | One Bedrock Guardrail on every model call, calibrated so it does not block legitimate investigation prompts |
The Tool Plane
Tools are Model Context Protocol servers, one per data domain. They are the only way an agent touches data, and each carries its own database role and reads personal data only where a specific tool needs it.
| Server | Tools | What it answers |
|---|---|---|
| ais | 10 | Tracks, latest positions, gaps, MMSI conflicts, loitering, rendezvous, zone incursions, vessels near a point, open alerts |
| registry | 5 | Vessel lookup, flag history, fleet associations, the ownership network, sanctions screening (OpenSanctions or the local list) |
| geo | 5 | Zones, point in zone tests, nearest ports, reverse geocoding |
| imagery | 4 | Sentinel scene search, next pass estimate, tasking requests (create and list) |
Any free text a server receives from an external source passes through an untrusted content wrapper before a model sees it, and the servers verify who is calling: each request carries a token signed by AWS STS that proves the caller's IAM role, and the servers admit an allowlist of role names and nothing else.
The Investigation Graph
The figure shows one investigation from trigger to watch floor. An alert review, a policy rule or an officer's request opens the job; the worker claims it and invokes the Orchestrator through the agents gateway with the vessel, the trigger and the alert. The Orchestrator fans out to two Investigator branches that run in parallel, merges their findings in pure code, asks the Tasking agent for a collection decision, drafts the report, runs the policy check, and persists the result to Aurora and then to AgentCore Memory.
Figure 4. The investigation graph: triggers, the durable job, parallel Investigator branches, the pure merge, Tasking, report plus policy, persistence, then the watch floor.
The branches split the work by the questions an analyst asks, so each carries a focused prompt and a focused tool set:
- Identity, ownership and sanctions: who is this ship, who owns and operates it, how has its flag changed, what does the ownership network connect it to, does anything screen against a sanctions list.
- Behaviour: what did the track do, where and for how long was it silent, who did it meet, which zones did it enter, what does the vessel's recent history in memory say. A branch that fails does not fail the investigation. It is marked degraded and the report says so. A branch that hits a provider availability error is retried once on the next model tier. If both branches fail, the job fails and the audit trail records it, which is exactly what the earlier screenshot of failed runs shows from a misconfigured local environment.
The report node is the one place the Orchestrator calls a model. Its output must pass a policy module before it is stored: a headline and summary, a timeline, indicators and counter indicators, information gaps, recommended actions from an allowed list, a collection plan, and evidence lines in the server.tool form. On the run captured for this article the first draft was rejected for an action outside the allowed set and for an empty counter indicator list, and the second draft, written with the correction list in the prompt, passed.
Agents, Frameworks And Models
Two agent frameworks share the plane on purpose. Strands Agents runs the tool heavy loops where a model reasons over many tool results (Watch, Tasking). LangGraph runs the graphs whose structure must be fixed (the Investigator's own branch graph and the Orchestrator). Both frameworks build their models through one factory, so a tier, a guardrail or a provider change lands everywhere at once.
| Agent | Framework | Tier and model | Role |
|---|---|---|---|
| Watch | Strands | fast: Amazon Nova Lite | Reviews detector candidates from a sweep and raises or dismisses each with a written reason |
| Investigator | LangGraph | standard: Amazon Nova 2 Lite, escalates to strong | Two branches: identity, ownership and sanctions; behaviour. Emits findings with evidence |
| Tasking | Strands | standard: Amazon Nova 2 Lite | Decides whether imagery is worth collecting and proposes a request with a sensor, a window and a priority |
| Orchestrator | LangGraph (code graph) | strong: Amazon Nova Pro for the report | Owns the sequence, merges findings, drafts and checks the report, persists |
The Watch sweep deserves a closer look because it is where a small model does the most damage if left alone. Early runs let the model name the vessel and the time window of each alert, and a smaller model would copy one vessel's gap window onto another; evaluation recall swung between 0.4 and 0.8 from run to run. The sweep is now a deterministic pre pass followed by judgement. The detectors run first and build candidates with a fixed MMSI, kind, window and evidence. The model only chooses to raise or dismiss a candidate by id and writes the explanation. Two kinds are not dismissible at all, an MMSI reporting from two places and a rendezvous outside any declared anchorage, because they are anomalies by definition. Candidates are ranked and capped at twenty five per sweep so a busy hour cannot exhaust the model's context.
Prompts are published to Amazon Bedrock Prompt Management at deploy time and the runtimes fetch them by version, falling back to the file in the image. The manifest of every investigation records the prompt version, the model and the tier that produced each node, so a reviewer can tell which prompt wrote which report.
Data Model And Provenance
The data model separates what the feeds gave, what Argus produced, and the record. Positions are range partitioned by day and deliberately have no primary key, because spoofed MMSIs and duplicate AIS reports legitimately share a vessel and a timestamp. Evidence snapshots freeze the tool output an investigation used, so a report can be re read months later against the data it actually saw, not against the table as it is today. Each investigation carries a manifest naming the prompt versions, models, tools and tiers that ran.
Figure 5. The PostGIS data model grouped by concern: the picture the feeds gave, the findings and work Argus produced, and the append only record.
- Review state is not approval. Findings and reports carry a review state (draft, accepted, rejected). Actions such as tasking carry an approval status. The two are separate columns with separate endpoints, because reviewing a claim and authorising an action are different acts.
- The audit log is append only. A database trigger rejects updates and deletes. Every API state change writes an event naming the actor, and agents appear as actors under their own names.
- Personal data is encrypted at the column. Beneficial owner names and person entities exist only as pgp encrypted values with a data key from Secrets Manager. The registry tool decrypts for the one lookup that needs it; the API and the UI stay pseudonymous. Re keying rewrites every row in one transaction from an operator command.
- The database password rotates monthly. Connection pools notice a failed authentication, re read the secret and rebuild, with no restart and no lost job.
The Watch Floor
The user interface is a single page over the API: a map with vessels, zones and watched areas on the left, and four tabs on the right for alerts, investigations, tasking and the audit trail. It is built for a shift, not a demo: keyboard shortcuts move through the alert queue, review actions need a modifier key so stray typing cannot accept an alert, and the officer's identity comes from the sign in and is locked in the header on AWS.
Live Watching Across Regions
In live mode the ingest subscribes to every watched region in one AISStream session. The header's watching selector lists all regions and lets the officer fit the map to one of them and filter the vessels shown to that box; alerts stay global. The catalogue of regions is a small YAML file and a single environment variable picks which are watched.
Figure 6. Live mode with six watched regions: the dashed boxes are the subscribed areas, each vessel dot is a live AIS report, and the scale bar reads five hundred nautical miles.
Figure 7. The eastern Mediterranean box on live AIS: the cable corridor and the naval exercise area from the scenario, with real traffic around them and two alerted vessels in amber.
One Case From Alert To Audit
The walkthrough below was recorded on the deployed system against live AIS traffic. It opens on the map with every watched region drawn; choosing the eastern Mediterranean from the watching selector fits the map to that box and filters the vessels to the ninety or so reporting there. The alert queue is global: the half hourly sweeps had raised over a hundred alerts that day, each marked as an AI draft, which every agent written record stays until an officer reviews it. The newest is a 171 minute AIS gap on a container ship near Singapore. Expanding the evidence shows the three tool results the Watch agent used, each cited as server.tool with the detector's numbers. Track draws another alerted vessel's last twenty four hours with its two silent periods. Investigate opens a job, and the progress card follows it from the queue through the orchestrator, the two Investigator branches and tasking to the report.
The report comes back in about a minute and is a useful example of restraint: priority low, confidence low, one indicator (the gap) against one counter indicator (the vessel was in no declared zone and its positions before and after the gap suggest it anchored), an information gap (no registry record for this hull), and a collection plan. Accept report and Reject report are the officer's two verbs. On the tasking tab the agent's SAR proposal for the gap waits for Approve or Reject, and the approval is stamped with the officer's email and the time. The audit tab, filtered on the vessel, shows the chain: the alert raised by the Watch agent, the investigation opened by the officer, the tasking proposed by the Tasking agent, each linked to its record.
Figure 8. The live walkthrough: every region on one map, the region selected, the evidence behind one alert, a track with two silent periods, the investigation in progress, the report, the approved tasking and the audit trail.
Figure 9. The finished Vessel of Interest report on live data: headline, priority and confidence, summary, timeline and recommended actions, with the trace id into the trace store and the AI draft badge until review.
The report from that run, as stored, reads as follows.
| Field | Value |
|---|---|
| Headline | The vessel OOCL PANAMA exhibited a 171-minute AIS gap, which may indicate an attempt to avoid tracking, but its behavior before and after the gap suggests it may have anchored, a benign activity. |
| Priority, confidence | low, low |
| Indicators | 171-minute AIS gap detected (source: ais.find_ais_gaps) |
| Counter indicators | The vessel was not inside any declared zones during the AIS gap (source: geo.point_in_zones) |
| Information gaps | Registry identity (name, IMO, flag, type) is not available. |
| Evidence sources | ais.find_ais_gaps, geo.point_in_zones, registry.lookup_vessel |
| Collection plan | Propose sentinel-1-sar imagery collection with AOI center at [-73.935242, 40.689247] and radius 10.0 NM, window start 2026-09-11T10:00:00+00:00, window end 2026-09-11T11:00:00+00:00. |
| Cost of the run | $0.089 |
Observability
Everything emits OpenTelemetry. The platform services and the runtimes send spans, metrics and logs to a collector; the collector fans out to a self hosted Grafana, Tempo, Loki and Prometheus task and to CloudWatch and X-Ray. AgentCore's own unified telemetry lands in CloudWatch with Transaction Search on, which is what AgentCore Evaluations and the GenAI observability views read. One Grafana board, generated from a Python panel library, is the operator view; it is organised by the question someone is asking rather than by service.
Figure 10. A scroll through the Argus board after a day of live sweeps: the watch floor strip, pipeline health against the service levels, tool and model calls, tokens and cost per investigation, the AgentCore section, and the infrastructure row.
The alarms that must page regardless of the board live in CloudWatch: thirty one of them, covering the queues and dead letter queues, both load balancers and their targets, every service's running task count, Aurora CPU, capacity and local storage, NAT gateways, the web ACL's blocked requests, degraded investigator branches and the evaluation gate per suite. Alarm and recovery both notify one SNS topic, and every alarm name has a runbook entry.
Quality Gates: Evaluations And Tests
A prompt or model change is not done until the evaluation gate passes against a running stack. Each agent has a suite with regression floors, scored by deterministic checks where possible and by a model judge where a rubric is needed. The Watch suite scores alerts against the scenario's ground truth by time overlap, so an alert without a window scores nothing.
| Suite | Floors |
|---|---|
| watch | recall 0.8, precision 0.6 |
| investigator | schema valid 1.0, evidence traceability 0.9, expected hits 0.7 |
| tasking | schema valid 1.0, decision match 0.5 |
| report | completion 1.0, policy clean 1.0, rubric average 3.5 of 5, expected hits 0.6 |
Below the evaluation gate, the repository carries a unit suite that runs with no database, no Docker and no AWS (one hundred and sixty three tests across twenty three files at the time of writing), integration tests for the detectors against PostGIS, ruff for lint and format, a compose configuration check, and cdk-nag on every synth with every suppression justified in code. Several of the unit tests exist because a deploy found the bug: a self recursive connection wrapper, an SNS topic policy that dropped the CloudWatch allow, a JWT verifier that re encoded the balancer's padded token. Each is pinned so it cannot return.
Security Posture
- Identity at the edge: Cognito user pool with operator created users, optional or mandatory TOTP, eight hour sessions, sign in enforced by the balancer on every listener.
- Identity between services: STS signed caller tokens verified by the tool servers and the API; allowlists of IAM role names; agent only API routes that stay IAM only even for signed in officers.
- Least privilege: one IAM role per runtime and per task, a Bedrock allowlist limited to first party models, a deploy role that requires MFA, an operator role for tooling, and a refusal to run scripts as root.
- Network: agents in subnets with no NAT route and interface endpoints for every AWS service they use; the tool servers reachable only through the gateway; HTTPS on the internal balancer with a certificate the agents trust through SSM.
- Data: encrypted personal data columns, monthly password rotation, an operator run re key, an append only audit log, and no demo or synthetic disclaimers in agent output so a report reads as a report.
- Model safety: one guardrail on every model call, prompt attack and misconduct filters calibrated against real investigation prompts, and a policy check on every report.
Running It
The same compose file and the same CDK application serve local development and AWS. Locally, one command starts the twenty containers and the scenario replays on a loop:
cp .env.example .env # set MODEL_PROVIDER and its credential
make up # UI on :8088, API on :8000, Grafana on :3000
make sweep # or press Sweep 12 h on the watch floor
On AWS the lifecycle is CDK only. The deploy script reads the feed keys and the officer's email from the environment, builds the images, deploys the four stacks, stores the keys in Secrets Manager and restarts the reader that needs them:
make deploy # create or update everything
make stop-aws # ECS to zero, Aurora pauses; volumes and data kept
make start-aws
make destroy # destroy plus asset garbage collection
Cost is a design input. An idle deployment with the observability task and two NAT gateways runs at roughly four hundred dollars a month, a paused one at roughly one hundred and forty, and a destroyed one at under two dollars for the retained buckets. An investigation costs a few cents in Nova tokens; the run captured above cost just under nine cents.
Lessons From Building It
- Small models need rails, not longer prompts. Handing the model fixed candidates and asking only for a decision took Watch recall from a coin flip to a stable floor.
- Reproducibility comes from code, not from a planner. A code owned graph with a single model node for the report made cost, latency and failure modes predictable.
- Every new managed service type was validated by a failed deploy. Evaluator placeholders, registry descriptor limits, gateway role permissions, resource policy shapes: read the service's own documentation page before guessing, and pin the answer in a unit test.
- Observability pays for itself in the first incident. The three bugs found on the final deploy were all diagnosed from logs and metrics in minutes: a task that could not connect, an alarm action that could not publish, a token that failed verification.
- Keep humans in the API. Enforcing review and approval in the service, with separate endpoints and separate columns, made the human in the loop guarantee something a test can check.
What Comes Next
- Move the Tasking agent onto the AgentCore harness path by default once its evaluation suite matches the direct path.
- Add more detector kinds (course reversals near boundaries, speed profiles inconsistent with the declared ship type) and their ground truth to the scenarios.
- Run the agents across two availability zones once AgentCore VPC mode supports the remaining zones in the region.
- Extend the region catalogue and give each region its own zone set and its own sweep cadence. Argus is a complete system rather than a demonstration of one technique: a feed, detectors, four agents on two frameworks, twenty four tools behind a policy enforcing gateway, a durable job system, a reviewed data model, a watch floor, and the observability and evaluation harness to run it. The AWS generative AI stack, AgentCore in particular, supplied the runtime, the gateway, the policy, the identity, the memory and the evaluation pieces so that the engineering effort could go into the domain: what an analyst needs to know about a ship that went dark, and how to show the evidence.
What It Costs To Run
The figures below are the on demand list prices in us-east-1 at the time of writing, rounded, for the deployment as shipped: two availability zones, one NAT gateway per zone, the self hosted observability task on, Aurora at its half ACU floor. Model usage is metered separately and is small next to the fixed floor: an investigation costs a few cents in Amazon Nova tokens, and the day of live sweeps behind the screenshots came to under a dollar. Your bill will differ with region, traffic, retention and the free tier.
| Component | Running, approximate per month | Paused (make stop-aws) |
|---|---|---|
| NAT gateways (two zones) | about $66 plus data | about $66 |
| Application load balancers (public and internal) | about $35 | about $35 |
| Aurora Serverless v2 (0.5 ACU floor, storage, backups) | about $50 | about $5 (auto pause, storage only) |
| ECS Fargate: API, UI, two workers, ingest, collector, observability task | about $150 | $0 (services at zero) |
| ElastiCache Serverless, WAF, Secrets Manager, S3, VPC endpoints | about $60 | about $30 |
| CloudWatch, X-Ray Transaction Search, logs | about $15 to $30 | under $5 |
| Bedrock AgentCore runtimes, gateways, memory (metered per use) | usage: a few dollars at demo load | $0 |
| Amazon Nova tokens | about $0.04 to $0.09 per investigation, cents per sweep | $0 |
| Total | about $400 idle plus usage | about $140 |
Destroyed (make destroy) the account keeps only the retained buckets, under two dollars a month. The runbook lists the two switches that move the floor most: a single NAT gateway (about $33 less) and the Aurora reader (about $43 more when on).
Source Code
The complete system, infrastructure as code, tests, evaluation harness and documentation set are in the repository below. The README covers the local stack in one command and the AWS deployment in one more.
Argus - https://github.com/techwithshadab/argus
References
AWS services and the documentation pages this article leans on:
- Amazon Bedrock AgentCore
- Amazon Bedrock AgentCore developer guide
- Amazon Bedrock
- Amazon Nova models
- Amazon Bedrock Guardrails
- Amazon Bedrock Prompt Management
- Application Load Balancer user authentication with Amazon Cognito
- AWS WAF
- Amazon Aurora Serverless v2
- AWS CDK v2 developer guide
- cdk-nag
Agent frameworks and protocols:
Data, mapping and observability:
Top comments (0)