Skip to content

AWS 2026-10-27 Tier 1

Read original ↗

Vessel-specific voyage optimization with machine learning: Manta on AWS

Summary

An AWS Architecture Blog customer case study (co-authored by Manta Marine Technologies engineers and AWS) describing the data/ML platform behind Manta's voyage-optimization product. The premise: seemingly identical ships perform differently (hull condition, trim, draft, machinery state, loading, operating practice), so models built on vessel-type averages miss; Manta instead trains one model per vessel on that vessel's own operational history, combined with weather and ocean forecasts, and retrains it as new voyage data accumulates. The architecture is a fairly conventional but cleanly reasoned AWS stack inside a multi-AZ VPC: a persistent Apache Airflow server on EC2 orchestrates everything, but submits all compute — ETL, training, voyage optimization — as ECS tasks on EC2 capacity, with one capacity provider + one Auto Scaling group + one launch template per instance type so each workload class scales independently and urgency maps to purchase option (Spot for less urgent, On-Demand for time-sensitive). Lambda is the client-facing entry point (trigger a DAG or return already-computed results); state lives in RDS and DynamoDB; images in ECR are split per architecture/workload (Graviton, x86-64, GPU, orchestration, MLOps). The most transferable idea is the same container image runs on an engineer's laptop and in production, so experiments are cheap locally, run unscoped at full scale on AWS when needed, and "scaling a validated result to every vessel is then a scheduling decision rather than a project."

Key takeaways

  1. Per-entity models beat population-average models when entities diverge physically. Manta trains a model per vessel on its own history (up to 3 billion data points in a single training run) rather than per vessel type, because hull/trim/draft/machinery/loading differences make type averages systematically wrong for any given ship (Source: raw article, "The challenge").
  2. Orchestrator ≠ compute. Airflow runs on a persistent EC2 instance because the scheduler is a long-running server process, but every unit of work is handed to ECS via the Airflow ECS operator — the orchestrator only schedules, never executes heavy work (Source: raw article, "The solution"). See systems/apache-airflow.
  3. ECS on EC2, not Fargate, when instance-type control matters. The team chose EC2 capacity over Fargate specifically for direct control of instance type — GPU instances and specific chip generations — which Fargate abstracts away (Source: raw article, "The solution").
  4. One capacity provider / ASG / launch template per instance type instead of a shared pool. Training and voyage optimization use different instance types; isolating them gives per-workload scaling control and lets urgency choose purchase option — Spot for less urgent jobs, On-Demand for time-sensitive ones — a concrete instance of concepts/latency-critical-vs-latency-tolerant-workload and of Spot as opportunistic capacity (Source: raw article, "The solution").
  5. Lambda as a thin front door with a cached-result short-circuit. A Lambda function either triggers the corresponding Airflow DAG or returns already-processed results from the database, so repeat queries don't re-run the pipeline (Source: raw article, "The solution").
  6. Multi-arch, per-role container images. Separate ECR images for Graviton (arm64) vs x86-64, GPU workloads, orchestration, and MLOps; ETL, training, and optimization all run on Graviton where possible. One large-dataset ETL pipeline saw ~25–30% better price performance after moving to Graviton (vs AWS's generic "up to 40%" claim) (Source: raw article, "Why AWS").
  7. Config vs secrets split + per-component least-privilege roles. Non-sensitive config in Parameter Store; DB credentials, Airflow app secrets, and third-party auth tokens in Secrets Manager (encrypted, IAM-gated); every system component has its own IAM role scoped to only what its task requires — concepts/least-privileged-access; data encrypted with KMS (Source: raw article, "The solution").
  8. Data-volume-driven retraining loop. The Airflow scheduler retrains each vessel's model periodically based on how much new data that vessel has produced (not a fixed calendar), launching the training task on the appropriate instance type; the updated model serves that vessel's next optimizations (Source: raw article, architecture description).
  9. IaC + identical images ⇒ environment reproducibility ⇒ cheap experimentation. The whole platform is defined with AWS CDK + Boto3 and verified through CI/CD, reproducing identical dev/staging/prod. Engineers validate ML/data work locally against large samples pulled from the system in the same container images used in production — "the only cost of an experiment is then retrieving the data" — and a validated algorithm reaches the full fleet without re-engineering. This is an infra-level analogue of concepts/local-remote-parity (Source: raw article, "Why AWS").

Architecture (from Figure 1)

 vessel telemetry + weather/ocean forecasts
               │
   ┌───────────▼──────── Amazon VPC (multi-AZ) ──────────────────────────┐
   │                                                                      │
   │  client apps ──► Lambda ──► (trigger DAG) ──► Airflow on EC2         │
   │                    │                          (persistent scheduler) │
   │                    └──► (return cached results from DB)    │         │
   │                                                ECS operator│         │
   │                    ┌───────────────────────────────────────▼──────┐  │
   │                    │ ECS cluster on EC2 capacity                   │  │
   │                    │  capacity provider A ─ ASG A ─ LT A (GPU)     │  │
   │                    │  capacity provider B ─ ASG B ─ LT B (Graviton)│  │
   │                    │  ... one per instance type; Spot or On-Demand │  │
   │                    │  tasks: ETL | per-vessel training | voyage opt│  │
   │                    └──────────────┬───────────────────────────────┘  │
   │          images ◄── ECR (arm64 / x86-64 / GPU / orchestration / MLOps)│
   │          state  ──► RDS + DynamoDB                                    │
   │          config ──► Parameter Store   secrets ──► Secrets Manager     │
   │          IAM role per component · KMS encryption                      │
   │          CloudWatch monitoring ─► SNS alerting                        │
   └──────────────────────────────────────────────────────────────────────┘

Systems / concepts / patterns extracted

Operational numbers

Metric Value
Max data points in one training run up to 3 billion
Graviton price-performance gain (one large ETL pipeline, observed) ~25–30%
AWS generic Graviton claim (cited, not Manta-measured) up to 40%
Expected fuel savings per vessel (internal voyage simulations) ~2–4%

Caveats

  • Customer case study co-written with an AWS sales rep; promotional framing ("Why AWS"). Architecture content is real but shallow — no data on training time, fleet size, model type, serving latency, Spot interruption handling, or how RDS vs DynamoDB responsibilities are split.
  • The 2–4% fuel saving is from internal simulations, not measured production outcomes.
  • Airflow on a single persistent EC2 instance is a potential single point of failure for orchestration; the post doesn't say how scheduler HA is handled despite the multi-AZ VPC framing.
  • Only one Graviton number is Manta's own; the 40% figure is AWS marketing.

Source

Last updated · 854 distilled / 2,448 read