Skip to content

AWS 2026-10-13 Tier 1

Read original ↗

Stopping business email compromise with AI-driven email security: How VIPRE protects modern enterprises on AWS

Summary

An AWS Architecture Blog post describing VIPRE Integrated Email Security (IES), a cloud-native email-security product built entirely on AWS to stop business email compromise (BEC) — the social-engineering/impersonation class of attack (urgent wire transfers, "confidential legal matter," thread hijacks, QR-code "quishing") that bypasses link/attachment-based gateways. The durable system-design content is a distributed, event-driven, four-layer pipeline: (1) a durable-ingest front (every email → S3 object, a lightweight reference → SQS job, pulled by stateless ECS/Fargate microservices); (2) a fan-out/fan-in multi-engine detection stage (static, behavioral/sandbox, semantic/NLP-transformer-on-GPU, contextual-intelligence engines run in parallel); (3) response/remediation (inline quarantine + post-delivery clawback via mail-provider APIs); and (4) a search & analytics layer wired as a CDC pipeline (MSK event stream → enrich → RDS system-of-record → CDC → OpenSearch for sub-second tenant-scoped queries). The post reports >500K messages/day in production, designed to scale to millions.

Key takeaways

  • Durable-ingest decoupling: S3 as payload store, SQS as job queue. Each incoming email stream is treated as a discrete job; the raw payload is committed immediately to S3 (cited at 11 nines — 99.999999999% durability), and only a lightweight reference to that S3 object is enqueued in SQS. This decouples ingestion from downstream processing, buffers unpredictable traffic spikes, and keeps the queue messages small (queue-decoupled durable ingest). (Source: this article)
  • Stateless workers pull jobs. ECS with AWS Fargate runs stateless microservices that pull SQS jobs, fetch the S3 payload, and start the detection pipeline — the canonical serverless-container realization of serverless claim-check ingestion. (Source: this article)
  • Four-engine detection with fan-out/fan-in parallelism. After ingest, a multi-stage workflow runs multiple engines in parallel, coordinating phases with fan-in and fan-out patterns (concepts/scatter-gather-query). Four analysis kinds:
  • Static — email as passive data; definitions/rules/signatures/heuristics/ classifiers updated via hot reload.
  • Behavioral — links/attachments detonated in a controlled sandbox, monitored and run through ML classifiers; ML classifiers are versioned and shipped with the sandbox Docker images; rule/heuristic updates via S3 + S3 events.
  • Semantic — email text through an NLP pipeline of multiple bidirectional transformer models (named entity recognition + coreference, intent summarization, zero-shot classification, semantic similarity matching); strongly-versioned models in Docker images on ECR, PyTorch, scheduled on NVIDIA GPUs; heuristics/embedding datasets updated separately via Apache Parquet packages on S3, with Amazon MWAA (managed Airflow) orchestrating the data-pipeline workflows.
  • Contextual intelligence — global (customer-independent IoCs/reputation feeds) + local (sender reputation, trust lists, roles) data correlated and injected during analysis; discovered risk is fed back into a security data lake for rapid identification of emerging risks. (Source: this article)
  • Inline enforcement + flexible release. This layer is the control plane translating detection verdicts into action via customizable Action Rule Definitions. In inline mode the service is a final gateway that quarantines high-severity risk before mailbox delivery (minimal dwell time); quarantine workflows include admin release (full visibility: audit logs, engine scores, raw payloads) and end-user self-release (secure metadata digest for low-risk bulk mail; all actions audited). (Source: this article)
  • Post-delivery clawback. Beyond inline blocking, the system uses native mail-provider API integrations to execute programmatic clawbacks — retracting malicious messages from inboxes after delivery to neutralize "time-bomb" threats and prevent lateral movement. (Source: this article)
  • Search & analytics as a CDC pipeline. Every state change and verdict is published as an event to an Amazon MSK cluster (durable, ordered, scalable event stream); events are consumed, enriched with metadata (user, group profile), and committed to Amazon RDS as the long-term auditable system of record; change data capture (CDC) streams RDS updates in real time into OpenSearch for sub-second analytical queries. (concepts/change-data-capture) (Source: this article)
  • Multi-tenant isolation at the query layer. Analytics queries and results are strictly scoped by the client's tenant ID, enforcing multi-tenant isolation and data-separation assurance. (concepts/tenant-isolation) (Source: this article)
  • Monitoring/governance across the whole detection pipeline via Amazon CloudWatch. (Source: this article)

Operational numbers

  • >500,000 messages/day processed in production; designed to scale to millions.
  • Sample 24-hour period across EU + NA production: 517,726 messages scanned (376,847 EU + 140,879 NA); 5,508 BEC attempts detected (3,853 EU + 1,655 NA) ≈ ~1% of scanned messages.
  • P95 message-processing latency (hourly average): 1.4–15 s with dynamic sandboxing disabled; 39–78 s with full sandbox analysis enabled.
  • S3 durability cited at 99.999999999% (11 nines) as the ingest-store rationale.
  • Deployment: native Microsoft 365 integration via secure APIs — no MX record changes (deploy in minutes vs days).

Systems / concepts extracted

  • systems/vipre-ies (NEW page — primary subject) — VIPRE's cloud-native Integrated Email Security product; the four-layer event-driven BEC-detection pipeline described above.
  • systems/aws-s3 — durable payload store (claim-check); the 11-nines durability figure is the stated ingest-store rationale; also the distribution substrate for rule/heuristic/embedding (Parquet) updates via S3 events.
  • systems/aws-sqs — the job queue carrying lightweight references to S3 payloads; traffic-spike buffer that decouples ingest from detection.
  • systems/amazon-ecs / systems/aws-fargate — stateless detection microservices that pull SQS jobs and fetch S3 payloads.
  • systems/amazon-ecr — registry for the strongly-versioned transformer-model Docker images (and the sandbox images carrying versioned ML classifiers).
  • systems/amazon-msk — the durable/ordered event stream carrying every state change + verdict into the analytics pipeline.
  • systems/aws-rds — long-term auditable system of record; CDC source for the search index.
  • systems/amazon-opensearch-service — sub-second analytical query store, populated by CDC from RDS; tenant-ID-scoped.
  • systems/mwaa (managed systems/apache-airflow) — orchestrates the model/embedding data-pipeline workflows feeding the semantic engine.
  • systems/aws-cloudwatch — centralized monitoring/governance across the detection pipeline.
  • concepts/event-driven-architecture — the overall "distributed, event-driven architecture" framing (every message a job, every verdict an event).
  • concepts/change-data-capture — RDS → OpenSearch real-time index sync.
  • concepts/scatter-gather-query — fan-out/fan-in parallel multi-engine detection coordination.
  • concepts/serverless-compute and concepts/tenant-isolation — the scaling and isolation primitives. S3's 11-nines durability and the SQS job queue's decoupling of ingest from detection are the ingest-store rationale (recorded as prose/tags; no dedicated pages minted per the taxonomy gate).
  • Sandboxing of links/attachments (behavioral detonation), model-in-Docker- image versioning, hot-reload of static rules, and the security-data-lake feedback loop are recorded as prose/tags per the taxonomy gate (single-source, implementation specifics — not minted as pages).

Caveats / notes

  • Vendor solution post (VIPRE on AWS), not an AWS-internal retrospective. It passes scope on genuine distributed-systems architecture depth (durable ingest, fan-out/fan-in detection, CDC search pipeline, multi-tenant isolation) and concrete production numbers, not on marketing. The closing CTA ("Explore VIPRE IES in AWS Marketplace") is product promotion.
  • No internals disclosed for: engine count per stage, sandbox fleet sizing, GPU instance types/count, MSK broker/partition topology, RDS engine/size, or the CDC mechanism (DMS vs native). Treat the per-system entries as hooks.
  • The 49% of spam is BEC and ~half of BEC is AI-generated figures are from VIPRE Security Group press material, not independent measurement.
  • The P95 latency ranges are hourly averages over a sample window, not a steady SLO; the sandbox-on vs sandbox-off split (1.4–15 s vs 39–78 s) is the load-bearing latency datum.

Source

Last updated · 854 distilled / 2,448 read