DEV Community: CobuildX AI

Introducing PII Extractor: A Lightweight Model for PII Extraction at Warp Speed

Emmanuel R — Thu, 29 Oct 2026 05:12:16 +0000

Three open models, from 17M to 68M parameters, built for a single job: finding personal information in text accurately enough for production and fast enough to run on every request.

Highlights

88.3% F1 on Privacy-Bench, a benchmark of human-annotated business documents, with a 68M-parameter model. PII-Tracer (596M) scores 86.5%, GLiNER2-PII (205M) 83.7% and nvidia GLiNER-PII (570M) 66.4%.
The smallest model, at 17M parameters, is within half a point of PII-Tracer at 1/35 of its size.
37% fewer false alarms than PII-Tracer while finding almost as much personal data.
12 types of PII, from names and emails to government IDs, secrets and IP addresses.
Openly available on Hugging Face under Apache-2.0: pii-extractor-68M, pii-extractor-32M and pii-extractor-17M.

Every message sent to an LLM, every document added to a search index and every support ticket written to a log raises the same question: does this contain personal information, and exactly where? The check runs on every request, so its speed and cost set the floor for everything behind it. Yet the strongest PII detectors available today carry hundreds of millions of parameters, and general-purpose LLMs carry far more.

PII Extractor is a family of three compact models purpose-built to extract personal data from the text you send it, and light enough to fine-tune for your own use case. At 68M parameters, it is the most accurate PII detector we tested on real business documents. At 17M, it processes 1,000 tokens in 0.17 seconds on four CPU threads, with no GPU at all.

Why PII detection belongs in a small model

Finding PII is not open-ended generation. A model reads a text once and decides, for every word, whether it belongs to a name, an email address, an account number or nothing at all. The answer is a set of character positions that can be redacted, masked or routed.

That makes it a natural fit for a small encoder. An encoder reads the whole text in both directions at once, so every word is judged in its full context: in "Will will sign the contract on Monday", the first "Will" is a name and the second is not. There is no text to generate and no output to parse, and the cost of a call depends only on the length of the input.

Meet PII Extractor

PII Extractor is fine-tuned from Ettin [6], an open encoder family from Johns Hopkins University with an architecture similar to ModernBERT [7]. The three models are built on Ettin-68M, Ettin-32M and Ettin-17M.

Each model reads up to 8K tokens in a single pass, splits longer texts automatically, and returns every piece of personal data with its exact position and one of 12 types:

Type	What it covers
PERSON	Names, including first names alone, initials and nicknames
EMAIL	Email addresses, including written-out forms
PHONE	Phone and fax numbers
ADDRESS	Street addresses; a city or country on its own is not labelled
DATE	Dates of birth
URL	Web addresses, with or without `https://`
ACCOUNT_NUMBER	Bank, card, IBAN and customer account numbers
GOV_ID	Social security, passport, national ID, tax ID and driving licence numbers
USERNAME	Usernames and handles
SECRET	Passwords, PINs, access codes, API keys and tokens
IP_ADDRESS	IPv4 and IPv6 addresses
OTHER_ID	Employee, patient, member and device IDs

Leading accuracy on business documents

On Privacy-Bench, 656 pages of real business documents annotated by people, PII Extractor-68M scores 88.3% F1, ahead of PII-Tracer at 86.5%, GLiNER2-PII at 83.7% and nvidia GLiNER-PII at 66.4%. PII Extractor-32M also scores above all three, at 18× smaller than PII-Tracer.

Model	Size	Privacy-Bench	PII-TRACE	GPU, 1,000 tokens	CPU, 1,000 tokens
PII Extractor-68M	68M	88.3%	82.4%	23 ms	1.17 s
PII Extractor-32M	32M	87.5%	84.6%	16 ms	0.40 s
PII Extractor-17M	17M	86.0%	81.2%	15 ms	0.17 s
PII-Tracer [3]	596M	86.5%	92.6%	271 ms	9.15 s
GLiNER2-PII [4]	205M	83.7%	62.2%	199 ms	3.68 s
nvidia GLiNER-PII [8]	570M	66.4%	75.1%	429 ms	9.45 s

Emails and phone numbers are close to solved for every model except nvidia GLiNER-PII, which marks the names inside an email address such as megan.donovan@lilly.com as two names and scores 34% on emails. Names sit at 86–88% for both PII Extractor and PII-Tracer. Addresses are where PII Extractor pulls furthest ahead: 63% for the 68M model, against 51% for PII-Tracer and 8% for GLiNER2-PII. Account numbers and links remain hard for every model, and appear only 167 and 21 times in the benchmark.

n/a: PII-Tracer does not support usernames, so it is not scored on them. Dates and secrets are not shown because Privacy-Bench does not annotate them.

On PII-TRACE, a benchmark of multi-turn conversations released alongside PII-Tracer, PII-Tracer leads with 92.6% against 84.6% for PII Extractor-32M, mostly because that benchmark also labels meeting dates and reference codes, which PII Extractor deliberately leaves unmarked.

Fewer false alarms, cleaner redaction

An F1 score combines two different failures. A missed value leaks personal data. A false alarm hides ordinary text and makes a document harder to use, which is why over-eager detectors tend to get switched off.

Out of 8,490 PII values in Privacy-Bench, PII Extractor-68M and PII-Tracer miss a similar number (613 and 567). The difference is in what they flag that isn't PII: 342 false alarms for PII Extractor-68M against 546 for PII-Tracer, 37% fewer. GLiNER2-PII makes the fewest false alarms but misses about one value in five. nvidia GLiNER-PII misses the fewest values (538) but raises 3,194 false alarms, more than nine times as many as PII Extractor-68M.

Fast enough for every request, even without a GPU

We timed every model on the same 50 text samples at each of three lengths, 1,000, 2,000 and 3,000 tokens, and report the median time per sample.

On a T4 GPU, all three PII Extractor models stay under 70 milliseconds per sample, even at 3,000 tokens. PII-Tracer takes 271 milliseconds at 1,000 tokens and almost 2 seconds at 3,000. nvidia GLiNER-PII is the slowest at 1,000 tokens, at 429 milliseconds, and takes 1.6 seconds at 3,000.

Without a GPU, PII Extractor-17M takes 0.17 seconds at 1,000 tokens and 0.48 seconds at 3,000, against 9.15 and 37.37 seconds for PII-Tracer. That makes it practical on ordinary application servers.

Which size to choose

PII Extractor-68M for the highest accuracy, on a GPU.
PII Extractor-32M for the best balance of accuracy and speed.
PII Extractor-17M for CPU-only servers and the lowest cost.

How we evaluated

We ran every model ourselves, on the same texts, with the same scoring. Privacy-Bench [1] contains 656 pages of Word and PDF business documents with 8,490 PII values annotated by people. PII-TRACE [2] contains 500 multi-turn conversations with 2,442 annotated values.

A prediction counts as correct only when its start, end and type all match the annotation. Each benchmark's types were mapped to ours as below, and every model was scored on the types that both the benchmark and the model support.

PII Extractor	Privacy-Bench	PII-TRACE
PERSON	NAME_GIVEN, NAME_FAMILY	private_person
EMAIL	EMAIL_ADDRESS	private_email
PHONE	PHONE_NUMBER	private_phone
ADDRESS	LOCATION_ADDRESS	private_address
URL	URL	private_url
ACCOUNT_NUMBER	ACCOUNT_NUMBER	account_number
USERNAME	USERNAME	Not annotated
DATE	Not annotated	private_date
SECRET	Not annotated	secret

GOV_ID, IP_ADDRESS and OTHER_ID are not annotated in either benchmark, so this evaluation does not cover them.

Latency is the median of 50 text samples per length, processed one at a time on a Tesla T4 GPU and on four CPU threads. PII-TRACE scores use its public subset, so they are not comparable with the official test results in the PII-Tracer paper [2].

Limitations

English only. The models were trained and tested on English text.
Our definitions of PII. Sensitive attributes such as health, religion or ethnicity are not detected in this version.
Rare types. Usernames, account numbers and links are found less reliably than names, emails and phones.

What's next

We're bringing dynamic labels at run time to our super-efficient, lightweight models: describe the PII types you need when you call the model, in the style of GLiNER [5], and get them back with no retraining, at a size that still runs on every request.

Try PII Extractor

All three models are on Hugging Face under the Apache-2.0 licence: pii-extractor-68M, pii-extractor-32M and pii-extractor-17M.

Need PII detection tuned to your own definitions, documents or languages? Get in touch with our team at cobuildx.ai/contact.

References

Benchmarks

TonicAI. Privacy-Bench (human-annotated documents). https://huggingface.co/datasets/TonicAI/Privacy-Bench
K. Zhang et al. PII-TRACE: A Benchmark for Context-Aware PII Detection in Multi-Turn LLM Conversations. arXiv:2609.22200, 2026. https://huggingface.co/datasets/perplexity-ai/PII-TRACE

Models and methods

Perplexity AI. PII-Tracer. https://huggingface.co/perplexity-ai/PII-Tracer
Fastino. GLiNER2-PII. https://huggingface.co/fastino/gliner2-privacy-filter-PII-multi
U. Zaratiana et al. GLiNER: Generalist Model for Named Entity Recognition using Bidirectional Transformer. NAACL 2024. arXiv:2311.08526.
O. Weller et al. Seq vs Seq: An Open Suite of Paired Encoders and Decoders (Ettin). arXiv:2507.11412, 2025.
B. Warner et al. Smarter, Better, Faster, Longer: A Modern Bidirectional Encoder for Fast, Memory Efficient, and Long Context Finetuning and Inference (ModernBERT). arXiv:2412.13663, 2024.

Other baselines

NVIDIA. gliner-PII. https://huggingface.co/nvidia/gliner-PII

Originally published at cobuildx.ai.

Moving Storage from GCP to AWS: Cloud Storage, Disks and File Shares

Emmanuel R — Wed, 28 Oct 2026 10:29:34 +0000

A plain-English guide to moving storage from Google Cloud to AWS: Cloud Storage, Persistent Disk, Filestore, backups and transfer tools. What replaces what, how storage classes and access change, how to copy the data safely, what changes on the bill, and a step-by-step plan.

Every app keeps data somewhere. Photos that users upload. Disks that servers run on. Folders that many machines share. Backups. Records that must be kept for years. All of this is "storage". When you move from Google Cloud (GCP) to AWS, storage is often the biggest thing to carry across.

On GCP, storage means three main things:

Cloud Storage keeps files in buckets. A bucket is like a big folder in the cloud. Each file in it is called an object.
Persistent Disk and Hyperdisk are the hard drives attached to virtual machines.
Filestore is a shared folder that many machines can use at the same time.

Around these sit backups and tools for copying data.

Storage looks easy to move. A bucket is a bucket. But the details are different. The cheap "cold" storage works in a different way. Access rules are written in a different way. And copying many terabytes takes time and money. On top of that, every file must arrive whole. Not one file can be lost or changed.

"S3 is effectively a living, breathing organism."

— Andy Warfield, VP and Distinguished Engineer at Amazon S3, in Building and operating a pretty big storage system called S3

That is a good way to think about the move. You are not just dropping files into a box. You are moving into a service with its own habits. This guide covers:

Which AWS service replaces each GCP storage service
What works differently on AWS
How to copy the data safely
What changes on the bill
A simple step-by-step plan

The Quick Map

Here is each GCP storage service and its closest match on AWS. The rest of the post explains each row.

GCP	Closest AWS match	Watch out for
Cloud Storage	Amazon S3	Cold storage works differently
Autoclass	S3 Intelligent-Tiering	Very small files are not moved to cheaper tiers
Persistent Disk / Hyperdisk	Amazon EBS	You set disk speed yourself
Regional Persistent Disk	No direct match	An EBS disk lives in one data center
Local SSD	EC2 instance store	Data is lost when the machine stops
Filestore	Amazon EFS, or Amazon FSx	Pick by how the folder is shared
Google Cloud NetApp Volumes	Amazon FSx for NetApp ONTAP	Same NetApp tools on both sides
Backup and DR Service	AWS Backup	Backup plans are set up again, not copied
Storage Transfer Service	AWS DataSync	DataSync can read Cloud Storage directly
Transfer Appliance	Copy over the network with DataSync	Snowball is closed to new customers

What about Snowball? Snowball was AWS's way to ship large amounts of data on a physical device. But AWS stopped offering Snowball Edge to new customers on November 7, 2025. For a move from one cloud to another, copying over the network is the normal path anyway.

Cloud Storage to Amazon S3

Cloud Storage and Amazon S3 work the same basic way. You make buckets. You put files in them. Each file has a name, its data and a few labels (called metadata). Almost everything you do in one, you can do in the other.

Google even offers an S3-style way to talk to Cloud Storage. That is why many AWS tools can read your GCP buckets directly.

Storage classes

A storage class is a price plan for your files. Files you read often go in a normal class. Files you rarely read go in a cheaper "cold" class. You pay less to keep them, but more to read them.

Both clouds have these classes, and the names roughly line up. But there is one big difference. On GCP, every class gives your file back in milliseconds, even Archive. On AWS, the two coldest classes do not. You must first ask AWS to restore the file, and that can take minutes or hours.

Cloud Storage class	S3 class to use	Shortest time you pay for	How fast you can read it
Standard	S3 Standard	No minimum	Right away
Nearline	S3 Standard-IA	30 days	Right away
Coldline	S3 Glacier Instant Retrieval	90 days	Right away
Archive	S3 Glacier Instant Retrieval	90 days	Right away
Archive (if nobody needs it fast)	S3 Glacier Deep Archive	180 days	Hours, after a restore
Autoclass	S3 Intelligent-Tiering	No minimum	Right away

These numbers come from the S3 storage class guide. One more thing to know: in S3 Standard-IA and Glacier Instant Retrieval, every file is billed as if it were at least 128 KB. If you have millions of tiny files, a cold class can cost more, not less.

Rule of thumb: if an app still reads old files, move Archive to Glacier Instant Retrieval. Use Deep Archive only for files nobody needs in a hurry, like old backups and legal copies.

Bucket settings

Most bucket settings have a direct match on AWS. They just have new names:

Cloud Storage	Amazon S3
Lifecycle rules (move or delete old files)	S3 Lifecycle
Object versioning (keep old copies)	S3 Versioning
Dual-region and multi-region buckets	A bucket in one region, plus S3 Replication if you need a second copy
Retention lock (files can't be deleted)	S3 Object Lock
Your own encryption keys (Cloud KMS)	Encryption with AWS KMS keys
Pub/Sub notifications when a file changes	S3 Event Notifications
Signed URLs (short-lived download links)	Pre-signed URLs
`gcloud storage` command line	`aws s3` command line

Who can read and write

On GCP, most teams give people and apps a role on the bucket, like "Storage Object Viewer". On AWS, access comes from two places. IAM policies say what a user or app may do. A bucket policy says who may use the bucket.

Leave Block Public Access turned on. It stops a bucket from being opened to the whole internet by mistake. New buckets have it on by default. If files really must be public, like images on a website, serve them through CloudFront instead of opening the bucket.

Disks: Persistent Disk to EBS

Disks for virtual machines move to Amazon EBS. The main change is how speed works.

Disk speed is measured in IOPS: how many reads and writes the disk can do each second. On GCP, a bigger disk is often a faster disk. On AWS, the usual disk type (gp3) lets you choose the speed on its own. Every gp3 disk starts at 3,000 IOPS, and you pay extra to go higher.

GCP disk	EBS disk	Good for
pd-standard	st1 (hard drive), or gp3	Big files read from start to end
pd-balanced	gp3	Most apps
pd-ssd	gp3 with more IOPS	Busy databases
pd-extreme, Hyperdisk Extreme	io2	Very busy databases

Two GCP disks have no exact match:

Regional Persistent Disk keeps a copy of the disk in two zones (two separate data centers). An EBS disk lives in one zone. On AWS, you get the same safety another way: a database copy in a second zone, or regular snapshots.
Local SSD becomes EC2 instance store. The warning is the same on both clouds: the data is gone when the machine stops. Use it only for data you can rebuild.

Disks usually move together with their machines. AWS Application Migration Service copies a running machine and its disks to AWS, and keeps them in sync until you switch.

Shared Folders: Filestore to EFS or FSx

Filestore gives many machines one shared folder. Machines reach it over the network using NFS, a common way to share folders on Linux. AWS has a few choices. Pick by what your apps need:

Amazon EFS is the simple match for most Filestore use. It uses NFS. It grows and shrinks on its own, so you never pick a size. It keeps your data in several zones. You pay for what you store.
Amazon FSx for NetApp ONTAP fits apps that need both Linux and Windows sharing, or NetApp features like instant copies. It is also the direct match for Google Cloud NetApp Volumes.
Amazon FSx for Lustre is for very heavy work, like training AI models. It can read files straight from S3.
Amazon FSx for Windows File Server is for Windows apps.

One tip: EFS is fast when many machines read at once, but each small file takes a little time to open. Apps that open thousands of tiny files one by one can feel slower. Test with your real app before you decide.

Moving the Data

For buckets, the best tool is AWS DataSync. It reads Cloud Storage directly. You give it a key from GCP, and it copies files into S3. For bucket to bucket copies, you don't need to install anything on GCP.

DataSync also checks every file after it copies it. On later runs, it only copies what changed. And it writes a report, so you can prove what was moved.

For Filestore, DataSync needs a small helper machine (an "agent") running on GCP, close to the data. For disks, move the whole machine with Application Migration Service.

A safe copy follows the same steps every time:

First full copy while the old system keeps running. For big buckets, this can take days.
Catch-up copies that only move what changed. Each one is shorter than the last.
Final copy. Stop writes for a short time, run one last copy, then point your apps at AWS.
Check everything. Compare the number of files, their sizes and their checksums. A checksum is like a fingerprint of a file. If the fingerprints match, the file arrived unchanged.

"These are simple mechanisms that protect you from a large class of risks."

— Andy Warfield, VP and Distinguished Engineer at Amazon S3, in Building and operating a pretty big storage system called S3

Checks are simple too, and they are what make a move safe. Don't delete anything on GCP until they pass.

Ask about Google's exit offer. Data leaving GCP normally costs money for every GB. Google offers free data transfer for customers who leave Google Cloud. You must apply first, and there are rules. Talk to your Google account team before the big copy starts.

A Simple Way to Decide

Is it files in a bucket? Use S3. Pick the class by how often the files are read. If you don't know, use Intelligent-Tiering.
Is it a disk for one machine? Use EBS gp3. Use io2 only for the busiest databases.
Do many machines share one folder? Use EFS. Use FSx if you need Windows sharing, NetApp features or very heavy work.
Is it a backup? Use AWS Backup. Keep a copy in a separate AWS account, so one mistake can't delete both.

What Changes on the Bill

Storage prices look simple: a price for each GB, each month. The surprises come from everything around that:

Cost	GCP	AWS
Keeping files	Per GB per month, by class	S3: per GB per month, by class
Reading and writing	A fee per 1,000 actions	A fee per 1,000 requests; higher for cold classes
Reading cold files	A fee per GB	A fee per GB, and a wait for Glacier
Deleting too early	You pay the minimum time	You pay the minimum time, and for at least 128 KB per file
Disks	Per GB; speed comes with size	EBS: per GB, plus extra speed if you want it
Shared folders	Filestore: for the size you set aside	EFS: for what you actually store
Data leaving the cloud	Per GB	Per GB

Three things catch teams out:

Lots of tiny files. Request fees and the 128 KB minimum add up fast. Bundle small files together, or keep them in S3 Standard.
Copying lifecycle rules as they are. A rule that moves files to a cold class is cheap on GCP. On AWS, moving millions of small files into Glacier costs a fee for each one.
NAT gateways. Machines in a private network often reach S3 through a NAT gateway, which charges for every GB. Add a free S3 gateway endpoint instead.

Turn on S3 Storage Lens early. It shows which buckets are growing, which files nobody reads, and where a lifecycle rule would save money.

What It Looks Like in Code

Uploading a file and making a one-hour download link, on GCP and on AWS:

# GCP: Cloud Storage (Python)
from datetime import timedelta
from google.cloud import storage

bucket = storage.Client().bucket("shop-invoices")
blob = bucket.blob("2026/10/inv-1042.pdf")
blob.upload_from_filename("inv-1042.pdf")
url = blob.generate_signed_url(expiration=timedelta(hours=1))

# AWS: Amazon S3 (Python)
import boto3

s3 = boto3.client("s3")
s3.upload_file("inv-1042.pdf", "shop-invoices", "2026/10/inv-1042.pdf")
url = s3.generate_presigned_url(
    "get_object",
    Params={"Bucket": "shop-invoices", "Key": "2026/10/inv-1042.pdf"},
    ExpiresIn=3600,
)

And a bucket that keeps old versions and moves files to a cold class after 90 days, in Terraform:

# GCP: a Cloud Storage bucket
resource "google_storage_bucket" "invoices" {
  name                        = "shop-invoices"
  location                    = "US-CENTRAL1"
  uniform_bucket_level_access = true
  versioning { enabled = true }
  lifecycle_rule {
    condition { age = 90 }
    action {
      type          = "SetStorageClass"
      storage_class = "COLDLINE"
    }
  }
}

# AWS: the same bucket in S3 (each setting is its own resource)
resource "aws_s3_bucket" "invoices" {
  bucket = "shop-invoices"   # names are global; it may be taken
}

resource "aws_s3_bucket_versioning" "invoices" {
  bucket = aws_s3_bucket.invoices.id
  versioning_configuration { status = "Enabled" }
}

resource "aws_s3_bucket_lifecycle_configuration" "invoices" {
  bucket = aws_s3_bucket.invoices.id
  rule {
    id     = "cold-after-90-days"
    status = "Enabled"
    filter {}
    transition {
      days          = 90
      storage_class = "GLACIER_IR"   # was COLDLINE
    }
  }
}

These snippets show the shape, not every setting. Check the current docs before you copy them.

Things That Bite Later

"Failures are a given and everything will eventually fail over time."

— Werner Vogels, CTO of Amazon, in 10 Lessons from 10 Years of AWS

These are the small things that tend to break after the move:

Old file paths. Paths like gs://bucket/file and links to storage.googleapis.com hide in code, settings, scripts and database rows. Search for all of them, including links you have already sent to customers.
Bucket names. Bucket names must be unique across all of AWS. The name you used on GCP may already be taken. Choose names early.
File labels. Labels like Content-Type tell a browser what a file is. If they are not copied, a browser may download a picture instead of showing it.
Cold files that need a restore. Code that reads from Archive on GCP will fail on Glacier Deep Archive until the file is restored.
Sudden heavy traffic. S3 handles thousands of requests per second and grows over time. But a brand-new bucket hit hard on day one can slow down at first. Ramp up traffic step by step.
File change alerts. If apps react when a file is added, those alerts move to S3 Event Notifications. The alert looks different, so the code that reads it needs a small change.

Doing the Move, Step by Step

List everything. Every bucket, disk, shared folder and backup, with its size, number of files, class, cost, owner and the apps that use it.
Pick the AWS service and storage class for each one, using the questions above. Write down why.
Set up the base: AWS accounts, networks, S3 gateway endpoints, encryption keys in AWS KMS, access rules and backup plans.
Apply for Google's exit offer before the big copy starts.
Start with one bucket. Copy it with DataSync, check it, and point one app at it.
Move the rest in waves. For each wave: full copy, catch-up copies, a short freeze, a final copy, then checks.
Clean up. Keep the GCP data read-only for a while, then delete it. Remove old keys and accounts. Review the AWS bill after the first full month.

Storage is the heaviest part of a cloud move, but it is also the most predictable. The services match closely. The work is in the details: cold classes, access rules, tiny files and a careful final copy. Get those right, and your data arrives whole.

Common Questions

How do I transfer data from GCS to S3?

Use AWS DataSync. It reads Google Cloud Storage directly with a GCP key, so bucket-to-bucket copies need nothing installed on GCP. It checks every file, copies only what changed on later runs, and writes a report. Run a full copy, catch-up copies, then a short freeze and a final copy.

Is Google Cloud Storage S3 compatible?

Partly. Cloud Storage has an S3-style XML API, which is why DataSync, rclone and many S3 tools can read GCS buckets directly. Your apps still need small changes once they move to real S3, such as signed URLs becoming pre-signed URLs.

Can I use rclone instead of DataSync for GCS to S3?

For small buckets, yes. For large moves, DataSync is safer: it checks every file, retries, runs incremental syncs and gives you a report you can show auditors.

What is the GCP Filestore equivalent in AWS?

Amazon EFS for most NFS shares. Use FSx for NetApp ONTAP for mixed Linux and Windows sharing or NetApp features, FSx for Lustre for heavy AI and HPC work, and FSx for Windows File Server for Windows apps.

Persistent Disk vs EBS: what is different?

On GCP a bigger disk is a faster disk. On EBS gp3 you set speed on its own: every disk starts at 3,000 IOPS and you pay for more. pd-balanced maps to gp3, pd-ssd to gp3 with more IOPS, and pd-extreme to io2. Regional Persistent Disk has no direct match.

Coldline vs Glacier: which S3 class replaces it?

Coldline and Archive map to S3 Glacier Instant Retrieval if apps still read the files. Use Glacier Deep Archive only for files nobody needs fast, because it needs a restore that can take hours.

How do I avoid GCP egress fees when moving to AWS?

Apply for Google's free data transfer for customers leaving Google Cloud before the big copy starts. Talk to your Google account team, since there are rules to follow.

About MigrateX

MigrateX is our platform and service for moving software, data and infrastructure from one technology to another. It combines automation with experienced engineers. The automation does the repetitive work quickly, and the engineers make the tricky decisions.

Here's how we run a GCP to AWS storage move with MigrateX:

Assessment. We list every bucket, disk, shared folder and backup, with its size, file count, class, cost and owner. You see where the work is before anyone agrees on a timeline.
Plan. We work with your team to pick the AWS service and storage class for each one, set up access and encryption, and plan the copy waves.
Migration, step by step. Automation does the repetitive parts: setting up DataSync copies, turning lifecycle rules and bucket settings into their AWS versions, and updating gs:// paths and Terraform. Our engineers handle the parts that need thought: cold data, very large buckets, shared folders and the final switch.
Proof that it works. Every wave ends with checks on file counts, sizes and checksums. Apps are tested against the new storage before the switch.
Handover and clean-up. We retire GCP storage one wave at a time, tune storage classes once real usage is known, and leave your team with a setup they understand and own.

What you get along the way:

No lost data. Every file is checked after it is copied. Nothing is deleted until the checks pass.
Short freezes. Catch-up copies keep the final switch down to minutes or hours, not days.
A smaller bill, not a bigger one. The right storage classes, lifecycle rules and endpoints are part of the move, not an afterthought.
One team from start to end. The same people plan the move, copy the data and hand it over.

Planning a move from GCP to AWS? We'd love to hear about it. Tell us a little about your setup through Contact Us, and we'll start with a free chat about where the work is likely to be.

References

AWS

AWS. What is Amazon S3? https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html
AWS. Understanding and managing Amazon S3 storage classes. https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html
AWS. S3 Intelligent-Tiering. https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html
AWS. Restoring an archived object. https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects.html
AWS. Managing the lifecycle of objects. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html
AWS. Replicating objects. https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html
AWS. S3 Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
AWS. Using server-side encryption with AWS KMS keys. https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html
AWS. Amazon S3 Event Notifications. https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html
AWS. Blocking public access to your Amazon S3 storage. https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
AWS. Sharing objects with presigned URLs. https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html
AWS. Optimizing Amazon S3 performance. https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html
AWS. Amazon S3 Storage Lens. https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens.html
AWS. Gateway endpoints for Amazon S3. https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html
AWS. What is Amazon EBS? https://docs.aws.amazon.com/ebs/latest/userguide/what-is-ebs.html
AWS. General Purpose SSD volumes. https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html
AWS. What is Amazon EFS? https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html
AWS. What is Amazon FSx for NetApp ONTAP? https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html
AWS. What is Amazon FSx for Lustre? https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html
AWS. What is Amazon FSx for Windows File Server? https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html
AWS. What is AWS Backup? https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html
AWS. AWS Key Management Service. https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
AWS. What is AWS Application Migration Service? https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html
AWS. Configuring AWS DataSync transfers with Google Cloud Storage. https://docs.aws.amazon.com/datasync/latest/userguide/tutorial_transfer-google-cloud-storage.html
AWS. AWS Snowball Edge availability change. https://docs.aws.amazon.com/snowball/latest/developer-guide/snowball-edge-availability-change.html

Expert sources

Andy Warfield. Building and operating a pretty big storage system called S3. All Things Distributed, 2023. https://www.allthingsdistributed.com/2023/07/building-and-operating-a-pretty-big-storage-system.html
Werner Vogels. 10 Lessons from 10 Years of Amazon Web Services. All Things Distributed, 2016. https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html

Google Cloud

Google Cloud. Storage classes. https://cloud.google.com/storage/docs/storage-classes
Google Cloud. Cloud Storage interoperability. https://cloud.google.com/storage/docs/interoperability
Google Cloud. Exit Google Cloud. https://cloud.google.com/exit-cloud

CobuildX helps teams migrate legacy applications and cloud infrastructure with MigrateX.

Originally published on the CobuildX blog.

Moving Serverless from GCP to AWS: Cloud Run, Functions and Events

Emmanuel R — Wed, 28 Oct 2026 10:28:58 +0000

A plain-English guide to moving serverless apps from Google Cloud to AWS: Cloud Run, Cloud Run functions, App Engine, Eventarc, Cloud Tasks, Scheduler and Workflows. What replaces what, what behaves differently, what changes on the bill, and a step-by-step plan.

"Serverless" means you give the cloud your code, and it runs it for you. You don't pick servers. You don't patch them. You don't keep them running. The cloud starts your code when it is needed and stops it when it is not.

On Google Cloud (GCP), serverless usually means Cloud Run, Cloud Run functions and App Engine. It also means the services that connect them: Eventarc, Pub/Sub, Cloud Tasks, Cloud Scheduler and Workflows.

Teams move these apps to AWS for simple reasons. The rest of the company is on AWS. The data has already moved. Or the apps need to sit close to other AWS services.

Serverless looks like the easiest thing to move. There are no servers to copy. But each cloud has different default settings, and that is where the work is. Cloud Run sends many requests to one copy of your app. Lambda sends one request at a time. Cloud Run lets a request run for an hour. Lambda stops after 15 minutes. Small differences like these can break an app that worked fine on GCP.

"Serverless is, instead, a mindset: make technology decisions that further your ability to focus on what differentiates you as a business."

— Ben Kehoe, AWS Serverless Hero, in his talk Serverless as a mindset

That is a good test for the move too. The goal is not to copy every GCP service one to one. The goal is to end up with less to look after. This guide covers:

Which AWS service replaces each GCP serverless service
What works differently, and what tends to break
How events, queues and schedules move
What changes on the bill
A simple step-by-step plan

The Quick Map

Here is each GCP serverless service and its closest match on AWS. The rest of the post explains each row.

GCP	Closest AWS match	Watch out for
Cloud Run services	Amazon ECS Express Mode, or AWS Lambda	Cloud Run shares one copy of the app between many requests; Lambda does not
Cloud Run jobs	ECS tasks on Fargate, or AWS Batch	Task numbering and retries are set up differently
Cloud Run functions	AWS Lambda	15-minute limit and a new code entry point
App Engine standard	Lambda, or Elastic Beanstalk	Old built-in services must be replaced
App Engine flexible	Elastic Beanstalk, or ECS on Fargate	`app.yaml` settings move to new config
API Gateway / Cloud Endpoints	Amazon API Gateway	Different login options and limits
Eventarc	Amazon EventBridge	Events look different, so code that reads them changes
Pub/Sub push	SNS and SQS, or EventBridge	Retries are set on the queue
Cloud Tasks	Amazon SQS with Lambda	SQS holds tasks; something must read them
Cloud Scheduler	EventBridge Scheduler	Each schedule names its own time zone and target
Workflows	AWS Step Functions	Workflows are rewritten, not converted
Secret Manager	AWS Secrets Manager, or Parameter Store	Access comes from the app's IAM role

What about App Runner? It looks like the obvious match for Cloud Run. But AWS closed App Runner to new customers on April 30, 2026. For new apps, AWS points to ECS Express Mode instead.

Cloud Run: Containers or Functions

Cloud Run runs your app in a container (a package with your code and everything it needs). It adds copies when traffic grows and removes them when traffic stops. On AWS you have two good choices:

ECS Express Mode is the closest match. You give it your container and two IAM roles. AWS sets up the rest: the service on Fargate, a load balancer, scaling and networking. Your container does not change. Like Cloud Run, one copy of the app can serve many requests at once.
AWS Lambda runs your code only when a request comes in. You pay per request. It is great for small APIs and for traffic that comes in bursts. But a normal Lambda copy handles one request at a time. Lambda can also run container images, but your code must use Lambda's request format.

Here are the main differences side by side. The Lambda numbers come from the Lambda quotas page:

Topic	Cloud Run	ECS Express Mode	Lambda
Requests per copy	Up to 1,000 (80 is common)	As many as your app can take	1
Longest request	60 minutes	Set by the load balancer	15 minutes
Scale to zero	Yes	No, at least one copy runs	Yes
Stay warm	Minimum instances	Minimum number of tasks	Provisioned concurrency
Largest request body	32 MiB	Load balancer limits	6 MB
What you deploy	Container	Container	Zip file or container

Two things follow from this. First, database connections. On Cloud Run, 100 requests might share two copies of the app and a few connections. On Lambda, 100 requests means 100 copies, and each opens its own connections. The database can run out. Use RDS Proxy to share connections, or keep the app on ECS. Second, anything that runs for more than 15 minutes cannot go on Lambda as it is.

Then there are cold starts. A cold start is the short wait while Lambda starts a new copy of your code. Many teams worry about it too much:

"Cold starts that don't add to user-facing latency is generally not worth worrying about."

— Yan Cui, AWS Serverless Hero, in Running Serverless at Scale

If users do feel it, turn on provisioned concurrency, which keeps copies ready, or SnapStart for Java, Python and .NET.

Rule of thumb: if the Cloud Run service is a full web app (a framework, a database, long requests), move the same container to ECS Express Mode. If it is a small API or webhook with spiky traffic, move it to Lambda.

There is also a middle option. Lambda Managed Instances run Lambda on EC2 machines that AWS looks after, and one copy can handle many requests at once. It suits steady, busy traffic. Your code must be safe to run many requests in parallel.

Cloud Run jobs

Cloud Run jobs run a container until the work is done, often as many tasks at once. On AWS, run the same container as an ECS task on Fargate. Start it from EventBridge Scheduler or Step Functions. For big jobs split into many parts, use AWS Batch array jobs. One small change: Cloud Run tells each task its number in CLOUD_RUN_TASK_INDEX. AWS Batch uses AWS_BATCH_JOB_ARRAY_INDEX.

Functions: Cloud Run Functions to Lambda

Cloud Run functions (once called Cloud Functions) map most directly to AWS Lambda. The idea is the same: a small piece of code that runs when a request or an event arrives. What changes is the code around it:

Topic	Cloud Run functions	Lambda
Entry point	Functions Framework (`@functions_framework.http`)	`handler(event, context)`
Web address	Built in	Function URL or API Gateway
Started by events	Eventarc or Pub/Sub	SQS, SNS, EventBridge and others
Memory and CPU	Set one by one	Set memory; CPU grows with it
Longest run	60 minutes for HTTP	15 minutes
Local files	Kept in memory	`/tmp`, up to 10 GB

Most of the work is in the entry point and the trigger, not in the business logic. Keep the logic in its own file. Then write a thin entry point for each cloud. That way you can test both with the same code.

App Engine

App Engine is GCP's oldest serverless service. How you move it depends on which kind you use:

App Engine flexible already runs containers. Move it to ECS on Fargate. Or use Elastic Beanstalk if the team likes the "push code, get an app" style.
App Engine standard apps on newer runtimes are normal web apps. Put them in a container and treat them like Cloud Run.
Older App Engine apps use built-in services like Memcache, Task Queues, Users and Datastore. Each needs a new home on AWS: ElastiCache, SQS, Amazon Cognito and DynamoDB. This is real code work, so find these apps early.

App Engine also has small config files that are easy to forget. cron.yaml becomes EventBridge Scheduler schedules. dispatch.yaml becomes load balancer rules. queue.yaml becomes SQS queues.

Events, Queues and Schedules

Serverless apps talk to each other through events: "an order was placed", "a file was uploaded". This is where small differences cause the most bugs:

Eventarc to EventBridge. Eventarc sends events in the CloudEvents format. EventBridge uses its own format, with fields like source, detail-type and detail. Every function that reads an event needs a small change.
Pub/Sub push to SNS and SQS. Pub/Sub push calls your web address and tries again if it fails. On AWS, put an SQS queue in front of each reader. Lambda then reads the queue in batches. Messages that keep failing go to a dead-letter queue (a side queue for messages that could not be handled).
Cloud Tasks to SQS. Cloud Tasks calls a web address for each task, at a rate you set. SQS only holds the tasks. Something has to read them. Use Lambda with a maximum concurrency setting to control the rate.
Cloud Scheduler to EventBridge Scheduler. EventBridge Scheduler supports cron, time zones and one-time schedules. It can start Lambda, ECS tasks and Step Functions directly.
Workflows to Step Functions. GCP Workflows are steps written in YAML. Step Functions are steps written in JSON. The ideas are the same (steps, retries, choices, waits), but each workflow is rewritten by hand.

Make every handler safe to run twice. On both clouds, a message can arrive more than once. On AWS, if one message in a batch fails, the whole batch is retried unless you report which ones failed. If a handler sends an email or charges a card, save an ID so it never does it twice.

APIs, Access and Identity

Who can call what works on the same idea in both clouds. Only the names change:

GCP	AWS
Service account on a service	IAM role for the Lambda function or ECS task
`roles/run.invoker` on a service	Lambda resource policy, or IAM login on a function URL
Services calling each other with tokens	IAM-signed calls, or a private API in API Gateway
"Allow unauthenticated"	A public function URL or public API
Identity-Aware Proxy	Load balancer login with Amazon Cognito
API keys in API Gateway	Usage plans and API keys in Amazon API Gateway

Give each function or service its own IAM role, with only the access it needs. Don't make one big role for everything, even if the old apps shared one service account.

Networking You'll Trip Over

Reaching private databases. Cloud Run reaches your private network through a connector or Direct VPC egress. Lambda can join your VPC (your private network on AWS). ECS tasks run inside it already.
Reaching the internet from the VPC. A Lambda function inside a VPC cannot reach the internet on its own. It needs a NAT gateway, which costs money per hour and per GB. For AWS services like S3 and DynamoDB, use VPC endpoints instead. They are cheaper.
Custom domains. A Cloud Run domain mapping becomes a certificate in ACM, plus a load balancer, CloudFront or an API Gateway custom domain.
Calls back to GCP. During the move, some apps still call GCP. That is slower and costs money for data leaving GCP. Remove these calls first.

A Simple Way to Decide

Does it run for more than 15 minutes? Use ECS on Fargate or AWS Batch.
Is it a full web app with a framework, a database or steady traffic? Use ECS Express Mode with the same container.
Is it a small API, webhook or event handler? Use Lambda.
Does it run on a schedule? Use EventBridge Scheduler to start a Lambda function or an ECS task.
Does it run several steps in a row, with retries and waits? Use Step Functions.

What Changes on the Bill

Both clouds charge for the time your code runs and for each request. The details change the total:

Topic	GCP	AWS
Pay per request	Cloud Run: CPU time, memory time, requests	Lambda: memory time and requests
Always-on containers	Cloud Run instance billing	Fargate: CPU and memory per second, plus the load balancer
Staying warm	Minimum instances (lower idle price)	Provisioned concurrency (paid while it is on)
APIs	API Gateway per call	API Gateway per call; HTTP APIs cost less than REST APIs
Events and queues	Eventarc, Pub/Sub, Cloud Tasks	EventBridge, SNS, SQS, all per request
Discounts	Committed use discounts	Compute Savings Plans (cover Lambda and Fargate)

Three things catch teams out:

The load balancer. ECS Express Mode puts a load balancer in front of your app. It costs money even with no traffic. Several apps can share one.
NAT gateways. Lambda functions in a VPC that call the internet go through NAT. A lot of outgoing traffic becomes a surprise on the bill.
Waiting time. On Lambda you pay while your code waits for other services. An app that spends most of its time waiting may be cheaper on Fargate.

Run the new setup for a few weeks before you buy a Savings Plan. Real usage is the only good basis for a commitment.

What It Looks Like in Code

A simple HTTP function on GCP and the same function on Lambda:

# GCP: Cloud Run function (Python)
import functions_framework

@functions_framework.http
def hello(request):
    name = request.args.get("name", "world")
    return {"message": f"Hello, {name}"}

# AWS: Lambda behind a function URL or HTTP API (Python)
import json

def handler(event, context):
    params = event.get("queryStringParameters") or {}
    name = params.get("name", "world")
    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"message": f"Hello, {name}"}),
    }

A function that reads Pub/Sub messages, and the same function reading from SQS:

# GCP: triggered by a Pub/Sub topic through Eventarc
import base64, json
import functions_framework

@functions_framework.cloud_event
def on_order(cloud_event):
    data = base64.b64decode(cloud_event.data["message"]["data"])
    process(json.loads(data))

# AWS: triggered by an SQS queue, with partial batch failures
import json

def handler(event, context):
    failed = []
    for record in event["Records"]:
        try:
            process(json.loads(record["body"]))
        except Exception:
            failed.append({"itemIdentifier": record["messageId"]})
    return {"batchItemFailures": failed}

And a Cloud Run service in Terraform, next to the same Lambda function:

# GCP: a Cloud Run service
resource "google_cloud_run_v2_service" "api" {
  name     = "api"
  location = "us-central1"
  template {
    containers {
      image = "us-docker.pkg.dev/shop-prod/apps/api:1.4.2"
      resources { limits = { cpu = "1", memory = "512Mi" } }
    }
    scaling { min_instance_count = 1 }
    max_instance_request_concurrency = 80
    service_account = google_service_account.api.email
  }
}

# AWS: the same API as a Lambda function from a container image
resource "aws_lambda_function" "api" {
  function_name = "api"
  package_type  = "Image"
  image_uri     = "123456789012.dkr.ecr.us-east-1.amazonaws.com/api:1.4.2"
  memory_size   = 1024                    # CPU grows with memory
  timeout       = 30
  role          = aws_iam_role.api.arn    # was the service account
}

resource "aws_lambda_function_url" "api" {
  function_name      = aws_lambda_function.api.function_name
  authorization_type = "AWS_IAM"         # was roles/run.invoker
}

These snippets show the shape, not every setting. Check the current docs before you copy them.

Things That Bite Later

"Failures are a given and everything will eventually fail over time."

— Werner Vogels, CTO of Amazon, in 10 Lessons from 10 Years of AWS

These are the small things that tend to break after the move:

Timeouts in a chain. API Gateway REST APIs stop waiting after 29 seconds by default. A Lambda behind it can run longer, but the caller has already given up. Check every timeout from the user to the database.
Large uploads. Lambda takes up to 6 MB per normal request. Big file uploads that worked on Cloud Run should go straight to S3 with a pre-signed URL.
Things kept in memory. Code that keeps a cache or a counter in memory acts differently when every request has its own copy of the app.
Logs and alerts. Cloud Logging searches and alerts become CloudWatch Logs Insights queries and CloudWatch alarms. Rebuild the alerts people rely on before you move traffic.
Secrets. Secret Manager paths like projects/.../secrets/... become Secrets Manager or Parameter Store names. Search your code for all of them.
Limits. New AWS accounts start with a low Lambda concurrency limit. Ask for more weeks before you move real traffic.

Doing the Move, Step by Step

List everything. Every Cloud Run service and job, function, App Engine app, trigger, queue, schedule and workflow, with its traffic, run time, cost and owner.
Pick the AWS service for each one, using the questions above. Write down why.
Build the base: AWS accounts, networks, a container registry (ECR), IAM roles, logs, alarms and higher limits. The Serverless Applications Lens is a good checklist.
Start with one small app. Move it end to end: code, triggers, secrets, alarms and domain.
Run both clouds side by side. Send a small share of users to AWS using weighted DNS in Route 53. Compare errors and speed.
Move the events. Point schedules and queues at AWS one at a time. Empty the GCP queues before you turn them off.
Clean up. Turn off the GCP services, delete old service accounts and keys, and buy Savings Plans once usage is steady.

"Serverless is still the future because the mindset shift is the thing we haven't gotten to."

— Ben Kehoe, AWS Serverless Hero, speaking to SD Times

Serverless is often the fastest part of a cloud move, because there are no servers to copy. The work is in the default settings: how many requests one copy takes, how long a request may run, and how events are retried. Get those right, and the rest is mostly config.

Common Questions

What is the Cloud Run equivalent in AWS?

ECS Express Mode is the closest: same container, one copy serving many requests, with AWS setting up Fargate, the load balancer and scaling. AWS Lambda fits small APIs and bursty traffic. App Runner is another option for simple web apps.

Cloud Run vs Lambda: which should I pick?

Pick Lambda for small APIs, webhooks and event handlers that can scale to zero. Pick ECS for full web apps, steady traffic, requests longer than 15 minutes, or bodies over 6 MB. Watch database connections: on Lambda every request is its own copy, so use RDS Proxy.

Cloud Run vs Fargate: what changes?

ECS on Fargate runs the same container, but it does not scale to zero, so at least one task runs all the time and a load balancer sits in front of it. In return you get long requests and many requests per copy, like Cloud Run.

How do I migrate Cloud Functions to Lambda?

The business logic usually stays. What changes is the entry point (Functions Framework becomes handler(event, context)), the trigger (Eventarc or Pub/Sub becomes SQS, SNS or EventBridge), and the 15-minute run limit. Keep the logic in its own file and write a thin entry point for each cloud.

Eventarc vs EventBridge: what is different?

Eventarc sends CloudEvents. EventBridge uses its own shape with source, detail-type and detail. Every function that reads an event needs a small change.

What is the Cloud Tasks equivalent in AWS?

Amazon SQS with Lambda. SQS holds the tasks but does not call anything, so Lambda reads the queue, and the maximum concurrency setting controls the rate. Failed tasks go to a dead-letter queue.

What is the App Engine equivalent in AWS?

App Engine flexible moves to ECS on Fargate or Elastic Beanstalk. Standard apps on newer runtimes go in a container. Older apps that use Memcache, Task Queues, Users or Datastore need ElastiCache, SQS, Cognito and DynamoDB. cron.yaml becomes EventBridge Scheduler.

About MigrateX

Here's how we run a GCP to AWS serverless move with MigrateX:

Assessment. We list every Cloud Run service, function, App Engine app, trigger, queue, schedule and workflow, with its traffic, run time, cost and owner. You see where the work is before anyone agrees on a timeline.
Plan. We work with your team to pick the AWS target for each service, design the IAM roles and networking, and decide the order of the move.
Migration, step by step. Automation does the repetitive parts: rewriting handlers and event formats, turning Cloud Run and App Engine config into ECS, Lambda and EventBridge, and converting Terraform. Our engineers handle the parts that need thought: long-running work, concurrency, App Engine bundled services and Workflows.
Proof that it works. Both clouds run side by side. We shift traffic a little at a time and compare errors, response times and costs before each step.
Handover and clean-up. We turn off GCP services one at a time, set up Savings Plans once usage is steady, and leave your team with a setup they understand and own.

What you get along the way:

No big-bang switch. Traffic moves a little at a time, with a quick way back.
No lost events. Queues and schedules move one at a time and are drained before anything is turned off.
A smaller bill, not a bigger one. Right-sized functions, shared load balancers and Savings Plans are part of the move, not an afterthought.
One partner for the whole move. The same team and approach covers your serverless apps, your compute and your data.

Planning a move from GCP to AWS? We'd love to hear about it. Tell us a little about your setup through Contact Us, and we'll start with a free chat about where the work is likely to be.

References

AWS

AWS. AWS App Runner availability change. https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html
AWS. Amazon ECS Express Mode. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-overview.html
AWS. AWS Fargate for Amazon ECS. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html
AWS. Understanding Lambda function scaling. https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html
AWS. Lambda Managed Instances. https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html
AWS. Create a Lambda function using a container image. https://docs.aws.amazon.com/lambda/latest/dg/images-create.html
AWS. Lambda SnapStart. https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
AWS. Using Lambda with Amazon SQS. https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html
AWS. Handling errors for an SQS event source in Lambda. https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-errorhandling.html
AWS. Giving Lambda functions access to resources in a VPC. https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html
AWS. Amazon EventBridge. https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html
AWS. Amazon EventBridge Scheduler. https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html
AWS. AWS Step Functions. https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html
AWS. AWS Batch. https://docs.aws.amazon.com/batch/latest/userguide/what-is-batch.html
AWS. Amazon RDS Proxy. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html
AWS. Lambda quotas. https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
AWS. Provisioned concurrency for Lambda. https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html
AWS. Quotas for REST APIs in API Gateway. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-execution-service-limits-table.html
AWS. Serverless Applications Lens, AWS Well-Architected. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html
AWS. Weighted routing in Route 53. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-weighted.html
AWS. AWS Elastic Beanstalk. https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html

Expert sources

Ben Kehoe. Serverless as a mindset. Serverless Boston meetup talk. https://www.meetup.com/serverless-boston/events/262376552/
Ben Kehoe, quoted in Getting a serverless reality check. SD Times. https://sdtimes.com/cloud/sd-times-blog-getting-a-serverless-reality-check/
Yan Cui. Running Serverless at Scale. https://www.slideshare.net/theburningmonk/running-serverless-at-scale
Werner Vogels. 10 Lessons from 10 Years of Amazon Web Services. All Things Distributed, 2016. https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html

Google Cloud

Google Cloud. Cloud Run quotas and limits. https://cloud.google.com/run/quotas
Google Cloud. Maximum concurrent requests for services. https://cloud.google.com/run/docs/about-concurrency
Google Cloud. Cloud Run functions overview. https://cloud.google.com/functions/docs/concepts/overview

CobuildX helps teams migrate legacy applications and cloud infrastructure with MigrateX.

Originally published on the CobuildX blog.

Moving Big Data from GCP to AWS: BigQuery, Dataproc and Dataflow

Emmanuel R — Wed, 28 Oct 2026 10:28:22 +0000

A plain-English guide to moving big data from Google Cloud to AWS: BigQuery, Dataproc, Dataflow, Pub/Sub, Composer and the data catalog. What replaces what, what behaves differently, what changes on the bill, and a step-by-step plan.

"Big data" is the part of the cloud that stores and works on large amounts of data. It includes the data warehouse, the Spark jobs, the streaming pipelines, the message queues and the tools that run them on a schedule. For many teams on Google Cloud (GCP), this is the most valuable part of their setup. It is also the hardest part to move.

Teams move it to AWS for simple reasons. The rest of the company already runs on AWS. A company they bought came with an AWS data lake. Or their apps have already moved, and sending every event back to GCP costs too much.

On paper the move looks easy: BigQuery goes to Redshift, Dataproc goes to EMR, Pub/Sub goes to Kinesis. In real life, small things change. The SQL is a little different. Prices work differently. Messages arrive in a different order. Each of these can quietly break a report that people rely on.

"Data integration is making all the data an organization has available in all its services and systems."

— Jay Kreps, co-creator of Apache Kafka, in The Log

That is the goal of a big data move too. The data has to keep reaching every team and every report while it moves. This guide covers:

Which AWS service replaces each GCP big data service
What works differently, and what tends to break
How to move the data itself and prove nothing was lost
What changes on the bill
A simple step-by-step plan

The Quick Map

Here is each GCP big data service and its closest match on AWS. The rest of the post explains each row.

GCP	Closest AWS match	Watch out for
BigQuery	Amazon Redshift (Serverless or provisioned)	The SQL and the pricing are different
BigQuery over files in a lake	Amazon Athena on S3, with Apache Iceberg tables	You pay per TB read, so file layout matters
Dataproc	Amazon EMR (on EC2, Serverless or EKS)	`gs://` paths and start-up scripts change
Dataproc Serverless	EMR Serverless	Different job settings and limits
Dataflow (Apache Beam)	Managed Service for Apache Flink, AWS Glue or EMR	No exact match; some jobs need a rewrite
Pub/Sub	Kinesis Data Streams, Amazon MSK, or SNS + SQS	Order, how long messages are kept, and push delivery differ
Cloud Composer	Amazon MWAA	Same Airflow, different operators and connections
Cloud Data Fusion	AWS Glue (visual ETL)	Pipelines are rebuilt, not converted
Datastream	AWS DMS	Change capture is set up differently
Dataplex / Data Catalog	Glue Data Catalog, Lake Formation, SageMaker Catalog	Access rules are rebuilt by hand
BigQuery ML	Redshift ML or SageMaker AI	Models are trained again, not copied
Looker Studio	Amazon QuickSight	Dashboards are rebuilt by hand
Bigtable	Amazon DynamoDB or Keyspaces	Different data model; plan it as its own project

The Warehouse: BigQuery to Redshift or Athena

BigQuery is Google's data warehouse: a place to keep large tables and run SQL on them. It is usually the centre of a GCP data platform, so it's the biggest decision. AWS has two good answers, and many teams use both:

Amazon Redshift is AWS's data warehouse. Use it for busy dashboards, many people running queries at the same time, and fast joins. Redshift Serverless feels closest to BigQuery: there are no servers to size, it grows and shrinks on its own, and you pay for the time it spends working.
Amazon Athena runs SQL directly on files stored in Amazon S3. Like BigQuery on-demand, you pay for the data each query reads. Use it for a data lake and for queries that run now and then. Store the tables in the Apache Iceberg format so you can update and delete rows.

A common setup: keep one copy of the data in S3 as Iceberg tables. Engineers query it with Athena and Spark. Redshift serves the dashboards that need to be fast, and it can read the same Iceberg tables, so you don't need two copies.

What changes in the SQL

Most simple queries move with small edits. The trouble is in features that only BigQuery has:

BigQuery	Redshift	Athena
`STRUCT` and `ARRAY` columns, `UNNEST`	`SUPER` column type	`ROW` and `ARRAY`; `UNNEST` works
Partitioned and clustered tables	Sort keys and distribution keys	Partitions and Iceberg sorting
`SAFE_CAST`, `IFNULL`	`CAST` with checks, `NVL`	`TRY_CAST`, `COALESCE`
`project.dataset.table` names	`database.schema.table`	`catalog.database.table`
Scripts and stored procedures	Stored procedures	Not supported; move logic to Airflow or Glue
Scheduled queries	Redshift query scheduler or Airflow	EventBridge or Airflow

Don't rewrite thousands of queries by hand. The AWS Schema Conversion Tool can convert BigQuery tables and much of the SQL for you. AWS also has a step-by-step BigQuery to Redshift guide. Treat the converted SQL as a first draft, and test every query behind an important report.

Rule of thumb: find the 50 queries that matter most (top dashboards, finance reports, ML features). Test those first, and compare their results row by row with BigQuery. Fix the rest as people use them.

Spark and Hadoop: Dataproc to EMR

Dataproc is Google's service for running Spark and Hadoop clusters. On AWS the same service is Amazon EMR. Both run the same open-source tools, so most jobs work on EMR with small changes:

On Dataproc	On EMR
`gs://bucket/path`	`s3://bucket/path`
Initialization actions (start-up scripts)	Bootstrap actions
Cluster properties	EMR configurations
Autoscaling policies	EMR managed scaling
Spot secondary workers	Spot task nodes
Dataproc Metastore	Glue Data Catalog
Dataproc Serverless	EMR Serverless

Pick the kind of EMR by how your jobs run. Clusters that run all day stay on EMR on EC2. Jobs that start, finish and stop are usually cheaper and simpler on EMR Serverless. If your team already runs everything on Kubernetes, EMR on EKS runs Spark on your existing cluster.

Match versions first. Use the same Spark and Python versions on EMR as on Dataproc. Otherwise small changes in behaviour will look like migration bugs.

Pipelines: Dataflow Is the Hard One

Dataflow is Google's service for running data pipelines written with Apache Beam. It handles the servers for you. AWS has no service that runs Beam in exactly the same way, so most of the engineering work goes here. There are three paths:

Keep the Beam code and run it on Flink. Beam pipelines can run inside Amazon Managed Service for Apache Flink. The code mostly stays the same, but your team has to learn some Flink tuning. This works well for streaming pipelines with a lot of logic.
Rewrite batch pipelines in Spark. Pipelines that run on a schedule often become AWS Glue jobs or Spark jobs on EMR Serverless. It's a rewrite, but Spark is widely known.
Write new streaming jobs for Flink directly. For simple streaming jobs, skip Beam and write them in Flink SQL.

Ready-made Dataflow templates (like "Pub/Sub to BigQuery") often need no code on AWS. Amazon Data Firehose can load a stream straight into S3, Iceberg tables or Redshift.

Count your Dataflow jobs early. They decide your timeline more than anything else. Sort them into three groups: "template, no code", "batch, rewrite in Spark" and "streaming, keep Beam or move to Flink".

Messaging: Pub/Sub to Kinesis, MSK or SQS

Pub/Sub is Google's message service: one system sends messages, and others receive them. Pub/Sub does several jobs at once. AWS splits those jobs across different services, so pick by how each topic is used:

How you use Pub/Sub	Best AWS match	Why
A stream of events for analytics	Kinesis Data Streams	Keeps order, lets you replay, feeds Firehose and Flink
Large streams, or teams that know Kafka	Amazon MSK (managed Kafka)	Works with Kafka tools; keeps data a long time
One message to many services	SNS with SQS queues	Simple fan-out
A work queue with retries	Amazon SQS	Simple, cheap, with a queue for failed messages
Pushing messages to a web address	EventBridge or SNS	Kinesis and SQS don't push

Three differences break the code that reads messages:

Order. Pub/Sub can keep messages in order by key. Kinesis keeps order inside each shard. SQS only keeps order in FIFO queues, which are slower.
How long messages are kept. Pub/Sub keeps them for up to 31 days. Kinesis keeps them for 24 hours by default and up to 365 days. SQS keeps them for up to 14 days.
Duplicates. On AWS, plan for the same message to arrive twice. Make sure handling a message twice does no harm.

Scheduling: Composer to MWAA

Cloud Composer runs Apache Airflow, the tool that starts jobs in the right order on a schedule. On AWS the same thing is Amazon Managed Workflows for Apache Airflow (MWAA). Your Airflow workflows (DAGs) move almost as they are. The work is in what they call:

Operators. Steps like BigQueryInsertJobOperator and DataprocSubmitJobOperator become the Redshift, Athena, EMR and Glue operators from the Amazon provider package.
Connections. The Google service account becomes an IAM role for MWAA. Passwords and keys go into AWS Secrets Manager.
Versions. Use the same Airflow version on MWAA as on Composer. Upgrade later. Doing both at once makes it hard to tell what broke.

During the move, one Airflow can run jobs on both clouds. That lets you move jobs one at a time instead of all at once.

Moving the Data Itself

"Data outlives code."

— Martin Kleppmann, author of Designing Data-Intensive Applications

Your pipelines will be rewritten many times. Your data will stay. So move it with care. Old data and new data move in different ways:

Export the old data. Export BigQuery tables to Parquet files in Cloud Storage. Parquet keeps column types and takes up little space.
Copy it across. AWS DataSync can read straight from Google Cloud Storage and copy the files to S3.
Load it. Register the files as Iceberg tables, or load them into Redshift with COPY.
Keep new data flowing. While both clouds run, send new data to both. You can write from the apps to both sides, run the pipelines on both, or use AWS DMS to copy database changes as they happen.
Check it. Every day, compare row counts and totals for every table on both sides. Switch readers only when they match.

Moving data out of GCP costs money. Google charges per GB for data leaving its network. For a large warehouse, ask Google about its free transfer offer for customers who are leaving, and ask AWS about migration credits, before you start copying.

Catalog and Access Rules

On GCP, who can see which data is set with IAM on datasets and tables, plus column and row rules in BigQuery and Dataplex. On AWS, the Glue Data Catalog lists your tables, and AWS Lake Formation holds the access rules. Athena, Redshift, EMR and Glue all follow them.

No tool converts these rules for you. Export your current rules, review them (many are old and too open), and rebuild them in Lake Formation. Use tags, so new tables get the right rules on their own.

A Simple Way to Decide

For each workload, ask these questions in order and stop at the first yes:

Is it a Dataflow pipeline? Sort it first: template, Spark rewrite, or Flink.
Is it a Spark or Hadoop job? EMR. Serverless for short jobs, EC2 for long-running clusters.
Is it a table behind busy dashboards? Redshift. Start with Serverless.
Is it lake data, or queries that run now and then? Iceberg on S3, queried with Athena.
Is it a stream of events for analytics? Kinesis Data Streams, or MSK if your team knows Kafka.
Is it a queue between services? SQS, with SNS to send to many.

What Changes on the Bill

Big data costs depend more on how you are charged than on list prices.

Topic	GCP	AWS
Pay per query	BigQuery on-demand, per TiB read	Athena, per TB read
Pay for capacity	BigQuery editions (slots per hour)	Redshift Serverless (RPU-hours) or fixed nodes
Commit for a discount	Slot commitments	Redshift reservations
Storage	Cheaper after 90 days without changes	S3 storage classes; Redshift managed storage
Spark	Dataproc fee on top of VM price	EMR fee on top of EC2 price; Spot for extra workers
Streaming	Pub/Sub, per TiB of messages	Kinesis per shard-hour or per GB; MSK per broker-hour
Moving data in or out	Charged per GB leaving GCP	Data coming into AWS is free

Two things catch teams out:

Athena charges for data read, just like BigQuery. Badly organised tables cost money in the same way. Split tables by date and merge small files before people start querying them.
Redshift Serverless charges for time, not data. One dashboard that refreshes every minute can keep it running all day. Set usage limits from day one.

Don't buy reservations in the first weeks. Pay as you go until usage is steady, then commit.

What It Looks Like in Code

A typical BigQuery query and the same query in Redshift:

-- BigQuery
SELECT user_id, item.sku, SAFE_CAST(item.price AS NUMERIC) AS price
FROM `shop-prod.sales.orders`, UNNEST(items) AS item
WHERE DATE(created_at) = CURRENT_DATE();

-- Redshift (items stored as a SUPER column)
SELECT o.user_id, item.sku, item.price::DECIMAL(18,2) AS price
FROM sales.orders AS o, o.items AS item
WHERE TRUNC(o.created_at) = CURRENT_DATE;

A Dataproc cluster in Terraform, and the same cluster on EMR:

# GCP: a Spark cluster
resource "google_dataproc_cluster" "etl" {
  name   = "etl"
  region = "us-central1"
  cluster_config {
    master_config {
      num_instances = 1
      machine_type  = "n2-standard-8"
    }
    worker_config {
      num_instances = 2
      machine_type  = "n2-standard-8"
    }
    initialization_action { script = "gs://etl-scripts/setup.sh" }
  }
}

# AWS: the same cluster on EMR
resource "aws_emr_cluster" "etl" {
  name          = "etl"
  release_label = "emr-7.x.0"              # match your Spark version
  applications  = ["Spark"]
  service_role  = aws_iam_role.emr_service.arn
  ec2_attributes {
    subnet_id        = var.private_subnet_id
    instance_profile = aws_iam_instance_profile.emr_ec2.arn
  }
  master_instance_group { instance_type = "m7i.2xlarge" }
  core_instance_group {
    instance_type  = "m7i.2xlarge"
    instance_count = 2
  }
  bootstrap_action {
    name = "setup"
    path = "s3://etl-scripts/setup.sh"   # was an initialization action
  }
}

These snippets show the shape, not every setting. Check the current docs before you copy them.

Things That Bite Later

"Failures are a given and everything will eventually fail over time."

— Werner Vogels, CTO of Amazon, in 10 Lessons from 10 Years of AWS

Plan for the small things that fail after the move, not just the big ones:

Time zones. BigQuery TIMESTAMP is always UTC. Redshift has two kinds of timestamp. Check every date filter in your top reports.
Small files. Streaming into S3 creates thousands of tiny files. That makes Athena slow and expensive. Merge them on a schedule.
Hidden gs:// paths. They hide in Spark settings, Airflow variables, notebooks and SQL. Search for all of them before the switch.
Key files. Google service account key files used by pipelines become IAM roles. Find every one, then delete the keys.
BI tools. Looker, Tableau and notebooks point at BigQuery. Every connection and saved query needs a new home.
Limits. New AWS accounts start with low limits for EMR, Kinesis and Glue. Ask for more weeks ahead.

Doing the Move, Step by Step

List everything. Every dataset, table, query, pipeline, topic, Airflow workflow and dashboard, with its size, cost, owner and who reads it.
Pick the AWS target for each one, using the questions above. Write down why.
Build the base: an S3 data lake with Iceberg, the Glue Data Catalog, Lake Formation rules, Redshift, MWAA, a network link to GCP, and higher limits.
Start with a small pilot. Move one data product end to end: its tables, pipeline, schedule and one dashboard.
Copy the old data, then keep both sides in sync. Compare both sides every day.
Switch readers one dashboard at a time, then switch the pipelines that write data.
Clean up. Turn off GCP jobs, delete old copies once you're sure, and buy reservations only once AWS usage is steady.

"Scope it to one to two weeks, with a few tables and a few queries only."

— Saman Irfan, Solutions Architect at AWS, on the pilot for a BigQuery move, in Best practices for a BigQuery to Amazon Redshift migration proof of concept

Big data is often the hardest part of a cloud move. The services are not that different. The hard part is that so many people depend on the numbers. Move the data carefully, prove the numbers match, and switch readers one at a time.

Common Questions

What is the BigQuery equivalent in AWS?

There are two. Amazon Redshift (Serverless feels closest) is the data warehouse for busy dashboards and many users. Amazon Athena runs SQL on files in S3 and, like BigQuery on-demand, charges for the data each query reads. Many teams keep Iceberg tables in S3 and use both.

Is BigQuery similar to Redshift?

The idea is the same: large tables and SQL. The details differ. BigQuery STRUCT and ARRAY columns become SUPER, partitioning and clustering become sort and distribution keys, and functions like SAFE_CAST and IFNULL need rewriting. The AWS Schema Conversion Tool converts much of this as a first draft.

How do I migrate data from BigQuery to Redshift?

Export BigQuery tables to Parquet in Cloud Storage, copy the files to S3 with AWS DataSync, then load them with COPY or register them as Iceberg tables. Keep new data flowing to both sides, and compare row counts and totals every day before you switch readers.

What is the Dataflow equivalent in AWS?

There is no exact match. Streaming Beam pipelines can run on Amazon Managed Service for Apache Flink with little code change. Batch pipelines are usually rewritten as AWS Glue or EMR Serverless Spark jobs. Simple templates often become Amazon Data Firehose with no code.

Dataproc vs EMR: how hard is the move?

Usually easy. Both run the same Spark and Hadoop. Change gs:// paths to s3://, initialization actions to bootstrap actions, and Dataproc Metastore to the Glue Data Catalog. Keep the same Spark and Python versions so behaviour doesn't shift.

What is the Pub/Sub equivalent in AWS?

It depends on how you use it: Kinesis Data Streams or Amazon MSK for event streams, SNS with SQS for fan-out, SQS for work queues, and EventBridge or SNS for push delivery. Plan for different ordering, retention and duplicate messages.

How do I migrate Cloud Composer to MWAA?

Your DAGs move almost as they are. Swap the Google operators for the Amazon provider operators, move the service account to an IAM role and secrets to Secrets Manager, and keep the same Airflow version until the move is done.

About MigrateX

Here's how we run a GCP to AWS big data move with MigrateX:

Assessment. We list every BigQuery dataset, query, Dataproc job, Dataflow pipeline, Pub/Sub topic and Airflow workflow, with its size, cost, owner and who reads the results. You see where the work is before anyone agrees on a timeline.
Plan. We work with your team to pick the AWS target for each workload, design the data lake and access rules, and decide the order of the move.
Migration, step by step. Automation does the repetitive parts: converting SQL, rewriting paths and operators, and turning Dataproc and Composer setups into EMR and MWAA. Our engineers handle the parts that need thought: Dataflow rewrites, data modelling, streaming and access rules.
Proof that it works. Both clouds run side by side. We compare row counts, totals and report results every day, and only switch readers once AWS matches GCP.
Handover and clean-up. We turn off GCP pipelines one at a time, set up reservations once usage is steady, and leave your team with a data platform they understand and own.

What you get along the way:

No frozen reports. Dashboards keep working while the data moves, one piece at a time.
Numbers you can trust. Daily side-by-side checks prove the data matches before anyone switches.
A smaller bill, not a bigger one. Good table layout, Spot, right-sized serverless and reservations are part of the move, not an afterthought.
One partner for the whole move. The same team and approach covers your data, your infrastructure and your apps.

Planning a move from GCP to AWS? We'd love to hear about it. Tell us a little about your setup through Contact Us, and we'll start with a free chat about where the work is likely to be.

References

AWS

AWS. Migrating a BigQuery project to Amazon Redshift. https://docs.aws.amazon.com/dms/latest/sbs/bigquery-redshift.html
AWS. Using BigQuery as a source for AWS SCT. https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Source.BigQuery.html
AWS. Amazon Redshift Serverless. https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-serverless.html
AWS. Amazon Athena pricing. https://aws.amazon.com/athena/pricing/
AWS. Query Apache Iceberg tables in Athena. https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html
AWS. Amazon EMR Serverless. https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/emr-serverless.html
AWS. EMR bootstrap actions. https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html
AWS. Apache Beam on Managed Service for Apache Flink. https://docs.aws.amazon.com/managed-flink/latest/java/how-creating-apps-beam.html
AWS. Amazon Data Firehose. https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html
AWS. Kinesis Data Streams data retention. https://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html
AWS. Amazon MWAA. https://docs.aws.amazon.com/mwaa/latest/userguide/what-is-mwaa.html
AWS. Transferring data from Google Cloud Storage with DataSync. https://docs.aws.amazon.com/datasync/latest/userguide/tutorial_transfer-google-cloud-storage.html
AWS. AWS Lake Formation. https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html

Expert sources

Jay Kreps. The Log: What every software engineer should know about real-time data's unifying abstraction. LinkedIn Engineering, 2013. https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying
Martin Kleppmann. Designing Data-Intensive Applications, chapter 4. O'Reilly, 2017. https://dataintensive.net/
Werner Vogels. 10 Lessons from 10 Years of Amazon Web Services. All Things Distributed, 2016. https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html
Saman Irfan. Best practices for a BigQuery to Amazon Redshift migration proof of concept. AWS Builder Center. https://builder.aws.com/content/3Gu1BkgphVPKgFak2mNFNZJ1Eiy/best-practices-for-a-bigquery-to-amazon-redshift-migration-proof-of-concept-poc

Google Cloud

Google Cloud. BigQuery pricing. https://cloud.google.com/bigquery/pricing
Google Cloud. Exporting table data. https://cloud.google.com/bigquery/docs/exporting-data
Google Cloud. Pub/Sub replay overview. https://cloud.google.com/pubsub/docs/replay-overview

CobuildX helps teams migrate legacy applications and cloud infrastructure with MigrateX.

Originally published on the CobuildX blog.

Moving Compute from GCP to AWS: VMs, Kubernetes and GPUs

Emmanuel R — Wed, 28 Oct 2026 10:27:46 +0000

A plain-English guide to moving compute from Google Cloud to AWS: VMs, instance groups, Spot, GKE, GPUs, TPUs and batch. What replaces what, what behaves differently, what changes on the bill, and a step-by-step plan.

"Compute" is the part of the cloud that runs your code: virtual machines, Kubernetes nodes, GPU machines and batch jobs. When a team moves from Google Cloud (GCP) to AWS, compute is usually the first thing they plan.

Teams move for simple reasons. The rest of the company is already on AWS. A company they bought came with an AWS account. Their credits ran out on one cloud and started on the other. Or the data they need already lives in AWS.

Most teams start with a table: Compute Engine goes to EC2, GKE goes to EKS, GPUs go to GPUs. That table is a good start, but it hides the real work. Services that do the same job often behave a little differently. Machine sizes, maintenance, Spot, pod networking and discounts all change, and those changes show up in production, not on the diagram.

In this post we go through every GCP compute option one by one. For each, we say what replaces it on AWS, what is different, and what changes on the bill. At the end we show a step-by-step plan and how we run these moves with MigrateX.

This guide covers compute. For Cloud Run, Cloud Run functions and Lambda, see moving serverless from GCP to AWS. For Persistent Disk and Filestore, see moving storage from GCP to AWS. For Dataproc and Dataflow, see moving big data from GCP to AWS.

The Quick Map

Here is every GCP compute option and its closest match on AWS. The rest of the post explains each row.

GCP	Closest AWS match	Watch out for
Compute Engine VMs	EC2	No custom machine sizes; pick the next size up
Instance templates	EC2 launch templates	Different fields; rebuild them, don't convert
Managed instance groups (MIGs)	EC2 Auto Scaling groups	Health checks and zones are set up differently
Spot VMs / preemptible VMs	EC2 Spot Instances	Different warning time and pricing
Sole-tenant nodes	EC2 Dedicated Hosts	Licence rules differ per host type
Machine images, custom images	Amazon Machine Images (AMIs)	Rebuild or replicate; you can't copy them across
Persistent Disk on a VM	Amazon EBS	Covered in the Storage post
GKE Standard	EKS with managed node groups or Karpenter	Pods use real VPC IPs; plan subnets
GKE Autopilot	EKS Auto Mode	Nodes are replaced at least every 21 days
GPU machines (A2, A3, A4, G2)	EC2 P and G instances	Getting capacity is the hard part
Cloud TPU	Trainium / Inferentia, or GPUs	There is no TPU on AWS
Batch	AWS Batch	Job settings and retries map loosely
App Engine	Elastic Beanstalk or App Runner	Often a good time to move to containers
Cloud Run / Cloud Run functions	App Runner, ECS on Fargate, Lambda	See the Serverless post
Bare Metal Solution	EC2 bare metal (`.metal`) instances	Check hardware and licence needs

Virtual Machines: Compute Engine to EC2

This is the easiest part of the move. Both clouds group their machines by job: general purpose, compute-heavy, memory-heavy and GPU. So matching them is mostly a lookup:

GCP series	Used for	AWS family	Note
E2	Cheap, light general use	t3 / t4g	AWS uses CPU credits; busy machines can slow down
N2, N2D, N4	General purpose	m7i / m8i, m7a	Intel and AMD options on both sides
Tau T2A, Axion (C4A)	Arm general purpose	m8g, c8g (Graviton)	Often the cheapest per unit of work
C3, C4, C2	Compute-heavy	c7i / c8i, c7a	Match by vCPU and clock speed, not by name
M1, M2, M3	Large memory	r8i, x2iedn, u-series	Check memory per vCPU
A2, A3, G2	GPU	P4d, P5, G6	See the GPU section below

Two things don't carry over:

Custom machine types. On GCP you can ask for any shape, say 6 vCPUs and 20 GB of memory. EC2 only sells fixed sizes, so you round up and pay for the gap. Before you round up, look at what the VM really uses. Many custom shapes were guesses made years ago.
Live migration. When Google does maintenance, it moves your running VM to new hardware without a reboot. EC2 instead schedules maintenance events, which can mean a stop and start. If a single VM can't be restarted, put it behind an Auto Scaling group or run a second copy.

Rule of thumb: size EC2 from measured CPU and memory, not from the GCP machine type. Rounding up every custom shape is the quickest way to make AWS look more expensive than it is.

What changes inside the VM

On GCP	On AWS
Google guest agent	SSM Agent and cloud-init
Startup script in instance metadata	EC2 user data
Metadata server at `metadata.google.internal`	Instance metadata (IMDSv2) at `169.254.169.254`
VM service account	IAM role attached through an instance profile
OS Login / SSH keys in metadata	SSM Session Manager (no open SSH port needed)
Google-provided OS images	Amazon Linux, Ubuntu, RHEL or Windows AMIs

Instance Groups: MIGs to Auto Scaling Groups

A managed instance group (MIG) is a group of identical VMs that grows or shrinks on its own. It's built from an instance template. On AWS the same thing is an Auto Scaling group built from a launch template.

Scaling on CPU, rolling updates and replacing broken VMs all have direct matches. Two details are different:

Zones. A regional MIG spreads across zones by itself. An Auto Scaling group only spreads across the subnets you give it, so give it one subnet in each Availability Zone.
Health checks. A MIG uses its own health check to replace broken VMs. An Auto Scaling group only checks that the EC2 machine is up, unless you switch it to use the load balancer's health check (health_check_type = "ELB").

Load balancers change too. Google's global HTTP(S) load balancer usually becomes an Application Load Balancer (ALB), and TCP/UDP load balancers become Network Load Balancers (NLB). AWS load balancers are regional, so for global traffic add Route 53 or CloudFront in front.

Cheaper Capacity: Spot VMs

Both clouds sell spare machines at a big discount and take them back when they need them. The rules are different:

	GCP Spot VMs	EC2 Spot Instances
Warning before it's taken back	0 seconds by default, or 120 seconds if you set it	Two minutes, best effort
Price	Fixed discount, changes at most once a month	Changes slowly by instance type and zone
How you find out	Shutdown signal, metadata server	Instance metadata and an EventBridge event
Best practice	Spread across zones and machine types	List many instance types and use capacity-optimized allocation

Shutdown scripts written for GCP usually still work. You just need to change them to read the AWS notice. The bigger change is to use many instance types. A group that lists one instance type gets interrupted far more often than one that lists ten.

Dedicated Hardware and Licences

Sole-tenant nodes become EC2 Dedicated Hosts. Most teams use them for software licensed per physical core, like Windows Server or SQL Server under bring-your-own-licence terms. Read your licence terms for AWS before you move. Often it's cheaper to use licence-included EC2 instances and drop dedicated hardware completely.

If you use Bare Metal Solution (for example, for Oracle), look at EC2 bare metal instances, or Amazon RDS if the database can be managed for you.

Moving the VMs Themselves

There are two ways to get a VM onto EC2: copy the running server, or rebuild it from code.

Copy it (rehost). AWS Transform MGN (formerly AWS Application Migration Service) copies servers to AWS with very little downtime. You install an agent on the GCP VM. It keeps copying the disks to AWS. You launch a test machine, check it, then switch over in minutes. Use this for old servers nobody can rebuild, licensed software, or hand-tuned databases.
Rebuild it. If the VM is built from a startup script, Ansible or Packer, use the same tools to build an AMI (Packer's amazon-ebs builder, or EC2 Image Builder) and launch it from an Auto Scaling group. It's more work at first, but you get something you can rebuild any time.

Either way, plan the network around the move. IP addresses change, so use DNS names, not hard-coded IPs. Lower DNS TTLs a few days before you switch. And set up a private link between the clouds (VPN or Interconnect to Direct Connect) so old and new servers can talk while both are running.

Kubernetes: GKE to EKS

Your Kubernetes manifests and Helm charts mostly move as they are. The cluster around them doesn't. Four things catch almost every team:

Networking. On EKS, every pod gets a real IP address from your VPC subnet. A busy cluster in a small subnet runs out of addresses fast. Use bigger subnets, or turn on prefix delegation, before you move workloads.
Identity. GKE Workload Identity becomes EKS Pod Identity (or the older IRSA). Each Kubernetes service account gets an IAM role. It's the same idea, but every link has to be made again. This is where most "access denied" errors come from in the first week.
Ingress. GKE creates Google load balancers for you. On EKS, install the AWS Load Balancer Controller, which creates ALBs and NLBs. The annotations are different, so check every Ingress.
Nodes. If you use GKE Autopilot, EKS Auto Mode is the closest match. If you manage node pools yourself on GKE Standard, use managed node groups or Karpenter. Karpenter picks the right instance type for each workload, which often saves money and makes Spot much safer.

One difference from Autopilot: EKS Auto Mode replaces every node after at most 21 days. Your workloads must be fine with nodes coming and going. Storage classes change too: GCE Persistent Disk volumes become EBS volumes through the EBS CSI driver.

Topic	GKE	EKS
Pod identity	Workload Identity Federation	EKS Pod Identity (or IRSA)
Pod IPs	Separate IP ranges from nodes	Pods take IPs from the node's subnet
Ingress	GKE Ingress / Gateway creates Google LBs	AWS Load Balancer Controller creates ALBs / NLBs
Node autoscaling	Cluster autoscaler, node auto-provisioning	Karpenter, or built in with Auto Mode
Fully managed nodes	Autopilot	EKS Auto Mode (21-day max node life)
Disks for pods	GCE PD CSI driver	EBS CSI driver
Control plane cost	Cluster fee, with a monthly free credit	$0.10 per cluster per hour (standard support)

Plan the subnets first. Running out of pod IPs is the most common EKS surprise for teams coming from GKE, and it's much easier to fix before the cluster exists.

GPUs Move, TPUs Don't

GPU workloads move fairly easily. Both clouds use the same NVIDIA chips, so CUDA code doesn't change:

GCP machine	GPU	AWS instance
A2	NVIDIA A100	P4d / P4de
A3	NVIDIA H100 / H200	P5 / P5e / P5en
A4	NVIDIA B200	P6-B200
G2	NVIDIA L4	G6
Cloud TPU	TPU	No match: GPUs, or Trainium / Inferentia

The hard part is getting the machines. New AWS accounts start with low GPU limits, so ask for more weeks ahead. If you need many GPUs for a fixed period, look at Capacity Blocks for ML.

TPUs are different. AWS has no TPU, so TPU code has to be changed, not just moved. JAX and PyTorch/XLA models can run on GPUs with some work. AWS's own chips (Trainium for training, Inferentia for serving) can cost less, but they need the Neuron SDK and testing for each model. Treat this as its own engineering project.

Batch Jobs

GCP Batch becomes AWS Batch. Both take a job, put it in a queue, and run it on machines they create for you. AWS Batch can run on EC2 (normal or Spot), on Fargate, or on EKS. For long jobs that can be stopped, run them on Spot with several instance types and save progress along the way (checkpoints), so a lost machine costs minutes, not hours. Retry settings are not the same on both sides, so set them on purpose.

Networking You'll Trip Over

Networking isn't compute, but it's where compute moves go wrong:

VPCs are regional on AWS. One global VPC on GCP becomes one VPC per region, joined with Transit Gateway or peering.
Subnets live in one zone. On GCP a subnet covers the whole region. On AWS each subnet is in one Availability Zone, so you need one per zone.
Firewall rules become security groups. GCP firewall rules use network tags. AWS security groups are attached to each machine and can point at other security groups, which is cleaner but means rewriting every rule.
Traffic between zones costs money. On AWS, data that crosses Availability Zones and NAT Gateway traffic are charged per GB. Keep chatty services in the same zone where you can.

A Simple Way to Decide

For each workload, ask these questions in order and stop at the first yes:

Does it need TPUs? Plan the move to GPUs or Trainium before anything else.
Is it on Kubernetes, and does the team want to keep it there? EKS (Auto Mode if you were on Autopilot).
Is it batch work that can be stopped and restarted? AWS Batch on Spot.
Does it need per-core licences or dedicated hardware? EC2 Dedicated Hosts, or licence-included EC2.
Is it small, stateless and request-driven? It may not need a VM at all. See the Serverless post.
Everything else: EC2 in an Auto Scaling group, sized from real usage.

What Changes on the Bill

Most cost surprises come from discounts, not list prices.

Topic	GCP	AWS
Automatic discounts	Sustained use discounts on some series (N1, N2, N2D, C2, M1, M2)	None; you pay the list price all month
Commitments	Committed use discounts	Savings Plans and Reserved Instances
Billing unit	Per second (1-minute minimum)	Per second for Linux (1-minute minimum)
Spot pricing	Fixed discount, changes at most monthly	Changes by instance type and zone
Managed Kubernetes	Cluster fee, with a monthly free credit	$0.10 per cluster per hour
Network	Premium global network by default	Cross-zone traffic and NAT Gateway charged per GB

The discount that quietly disappears is the sustained use discount. On GCP, a VM that runs most of the month gets up to 30% off automatically. AWS has no such thing. You only get that money back by buying a Savings Plan.

Don't buy one in the first weeks. Run on normal pricing until usage is steady, then commit to the amount you're sure you'll use. A Compute Savings Plan also covers EKS nodes, Fargate and Lambda, so you don't have to commit to one instance family.

What It Looks Like in Terraform

A regional managed instance group becomes a launch template plus an Auto Scaling group:

# GCP: a group of 3 identical VMs across zones
resource "google_compute_region_instance_group_manager" "web" {
  name               = "web"
  base_instance_name = "web"
  region             = "us-central1"
  target_size        = 3
  version { instance_template = google_compute_instance_template.web.id }
}

# AWS: the same group as an Auto Scaling group
resource "aws_autoscaling_group" "web" {
  name                = "web"
  desired_capacity    = 3
  min_size            = 3
  max_size            = 6
  vpc_zone_identifier = var.private_subnet_ids # one subnet per zone
  health_check_type   = "ELB"                  # use the load balancer's check
  launch_template {
    id      = aws_launch_template.web.id
    version = "$Latest"
  }
}

A group that uses Spot should list several instance types. Inside the aws_autoscaling_group, replace the launch_template block with:

mixed_instances_policy {
  instances_distribution {
    on_demand_base_capacity                  = 1  # always keep one normal VM
    on_demand_percentage_above_base_capacity = 0  # the rest on Spot
    spot_allocation_strategy                 = "price-capacity-optimized"
  }
  launch_template {
    launch_template_specification { launch_template_id = aws_launch_template.web.id }
    override { instance_type = "m7i.large" }
    override { instance_type = "m7a.large" }
    override { instance_type = "m6i.large" }
  }
}

These snippets show the shape, not every setting. Check the current provider docs before you copy them.

Things That Bite Later

Service account keys. Every VM service account becomes an IAM role, and every key file hidden in a script needs a new home.
Metadata calls. Code that calls metadata.google.internal for project, zone or tokens must switch to IMDSv2 or the AWS SDK.
Limits. New AWS accounts start with low limits for vCPUs, GPUs and Elastic IPs. Ask for more weeks ahead.
AMI IDs differ per region. Look them up per region, or use SSM parameters, instead of hard-coding them.
Single-zone setups. Check that every Auto Scaling group and node group covers at least two Availability Zones.
Monitoring and logs. Cloud Monitoring and Cloud Logging agents become the CloudWatch agent. Rebuild alerts and dashboards before you switch traffic.

Doing the Move, Step by Step

List everything. Every VM, instance group, cluster and batch job, with its machine type, real usage and what it talks to.
Pick the target for each one using the questions above. Write down why, so you can revisit it later.
Build the base: AWS accounts, VPCs, subnets big enough for EKS, IAM roles, limits and a private link to GCP.
Start with a pilot. Move one small, low-risk service end to end to prove the path works.
Move in waves. Stateless groups and clusters first, then rehost the harder servers with MGN.
Shift traffic slowly with weighted DNS, and keep GCP running until AWS is steady.
Clean up. Turn off GCP group by group, and buy Savings Plans only once AWS usage is steady.

Compute is usually the easy part of a cloud move. The service map fits on one page. The real work is in the details: machine sizes, maintenance, Spot, pod IPs, identity and discounts. Decide those on purpose and the rest is mostly typing.

Common Questions

Compute Engine vs EC2: what is actually different?

The machines are close matches. Two things don't carry over: EC2 has no custom machine types, so you round up to the next fixed size, and EC2 has no live migration, so maintenance can mean a stop and start. The Google guest agent, startup scripts and metadata server are replaced by SSM Agent, user data and IMDSv2.

How do I map GCP machine types to EC2 instance types?

Match by job first, then by vCPU, memory and clock speed, not by name. E2 maps to t3 or t4g, N2 and N2D to m7i or m7a, C3 and C4 to c7i or c8i, M-series to r8i or x2iedn, and Arm machines like Axion to Graviton (m8g, c8g). Size from what the VM really uses, not from its old shape.

How do I migrate a VM from GCP to AWS step by step?

Either copy it or rebuild it. AWS Transform MGN (formerly AWS Application Migration Service) installs an agent on the GCP VM, keeps the disks in sync with AWS, and lets you switch over in minutes. If the VM is built from code with Packer or Ansible, build an AMI instead and run it in an Auto Scaling group.

What is the GKE to EKS migration checklist?

Your manifests and Helm charts mostly move as they are. Plan four things: bigger subnets (every pod takes a VPC IP), Workload Identity to EKS Pod Identity, GKE Ingress to the AWS Load Balancer Controller, and nodes (EKS Auto Mode for Autopilot, managed node groups or Karpenter for GKE Standard). Swap the GCE PD CSI driver for the EBS CSI driver.

Is there a TPU equivalent on AWS?

No. TPU code has to be changed, not just moved. JAX and PyTorch/XLA models can run on NVIDIA GPUs with some work, or on AWS Trainium and Inferentia through the Neuron SDK. Treat it as its own project.

What replaces GCP sustained use discounts on AWS?

Nothing automatic. On AWS you get that saving back by buying a Compute Savings Plan, which also covers EKS nodes, Fargate and Lambda. Wait until usage is steady before you commit.

About MigrateX

This guide is how we approach GCP to AWS compute moves with MigrateX. Here's what that looks like:

Assessment. We list every VM, instance group, GKE cluster, GPU machine and batch job, with real usage, dependencies, licences and the hidden ties to GCP, like metadata calls and service account keys. You see where the work is before anyone agrees on a timeline.
Plan. We work with your team to pick the AWS target for each workload, right-size the machines, design the network and accounts, and decide the order of the waves.
Migration, step by step. Automation does the repetitive parts, like turning Terraform and instance templates into launch templates, Auto Scaling groups and EKS setups, and replicating servers with MGN. Our engineers handle the parts that need thought: identity, networking, Spot design and TPU code.
Proof that it works. Each workload runs on both clouds side by side. We compare health, speed and cost, and only shift traffic once AWS matches or beats GCP.
Handover and clean-up. We turn off GCP group by group, set up Savings Plans once usage is steady, and leave your team with AWS infrastructure they understand and own.

What you get along the way:

No big switch-over weekend. Your services keep running while the move happens one wave at a time.
Less risk. Side-by-side runs and slow traffic shifts mean you can always switch back.
A smaller bill, not a bigger one. Right-sizing, Spot and Savings Plans are part of the move, not an afterthought.
More than one kind of move. We use the same approach for storage, serverless and big data, and for front ends like Angular, Ember and jQuery.

Planning a move from GCP to AWS? We'd love to hear about it. Tell us a little about your setup through Contact Us, and we'll start with a free chat about where the work is likely to be.

References

AWS

AWS. What is AWS Transform MGN? https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html
AWS. Spot Instance interruption notices. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html
AWS. Amazon EKS Auto Mode. https://docs.aws.amazon.com/eks/latest/userguide/automode.html
AWS. Amazon EKS pricing. https://aws.amazon.com/eks/pricing/
AWS. Compute Savings Plans. https://aws.amazon.com/savingsplans/compute-pricing/
AWS. Amazon EC2 Dedicated Hosts. https://aws.amazon.com/ec2/dedicated-hosts/
AWS. AWS Batch. https://aws.amazon.com/batch/

Google Cloud

Google Cloud. Spot VMs. https://docs.cloud.google.com/compute/docs/instances/spot
Google Cloud. Sustained use discounts. https://docs.cloud.google.com/compute/docs/sustained-use-discounts
Google Cloud. GKE pricing. https://cloud.google.com/kubernetes-engine/pricing

CobuildX helps teams migrate legacy applications and cloud infrastructure with MigrateX.

Originally published on the CobuildX blog.

A 14-Year-Old PHP Bug Lets Strangers Run Code on Your Server. Here's How to Stop It

Emmanuel R — Thu, 22 Oct 2026 11:54:50 +0000

The code nobody touched for years just became everyone's problem. A bug hiding in PHP since 2012 lets strangers run code on web servers, and the NSA and India's CERT-In have both raised the alarm. Here's how PHP2Shell (CVE-2026-109618 and CVE-2026-109619) works, how it was found, and exactly what to do about it.

On 21 October 2026, PHP shipped an emergency release for two critical bugs in the PHP engine itself: CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both let an attacker run code on a web server without logging in [1][2].

Governments moved fast. The NSA told organizations that can't update right away to take their PHP systems offline [3]. The same day, India's national cybersecurity agency, CERT-In, issued a critical-severity advisory (CIVN-2026-0510) warning that vulnerable PHP servers could be exposed to remote code execution [10][11]. CISA in the US issued its own alert [6].

The unsettling part is where the bugs came from: code that has sat in PHP since 2012, and that attackers started probing before a patch existed. This post explains what the two bugs are, how they work, how they were found, and what to do about them. If you run PHP anywhere, including inside WordPress, Drupal, Magento or an internal tool, it applies to you.

The Two Bugs at a Glance

	CVE-2026-109618	CVE-2026-109619
Name in the advisory	RCE via OOM corruption	RCE via stale global state
Bug type	Memory corruption when PHP runs out of memory	Use-after-free across two requests
Severity	CVSS v4.0 9.2, critical	CVSS v4.0 9.2, critical
Login needed?	No	No
Confirmed exploit	Apache mod_php	mod_php and PHP-FPM
Advisory	GHSA-w8hw-w9fx-j79w	GHSA-6wmf-4rv5-p3rp

In both cases, a successful attack runs code as the web server's PHP user. From there an attacker can read files, steal database passwords and keys from config files, or plant a backdoor [1][2].

How the Bugs Work

CVE-2026-109618: running out of memory at the wrong moment

When PHP runs out of memory, it doesn't return an error step by step. It jumps straight out of whatever it was doing, using a C function called longjmp(). If that happens while a request is still being set up, some of the request's data is left half-built. Later, when PHP cleans up the request, it treats that half-built data as valid, and memory gets corrupted [1].

An attacker can cause this on purpose. Weaknesses in how PHP parses multipart form uploads let a crafted request use up memory while still looking like it's within the configured limits. On Apache with mod_php, this happens before any application code runs, so the app itself doesn't need to have a bug [1][4].

CVE-2026-109619: one request's leftovers, used by the next

A PHP worker handles many requests in a row, and it keeps some global state between them: error, session and extension data. Normally that state is reset at the end of each request. But a fatal error, such as running out of memory or hitting the execution time limit, can skip that reset. The worker is left holding a pointer to memory that's already been freed [2].

If the next request on the same worker touches that state before it's reset, PHP uses freed memory. The advisory confirms two ways to reach it. One is session upload progress, a feature that's on by default and works even if the app never calls session_start(). The other is PHP 8.5's new fatal error backtraces setting, also on by default. Besides running code, this bug can leak memory from other users' requests, including passwords and tokens [2].

How It Was Found

Both bugs were found in August 2026 by researchers auditing PHP's C source with the help of AI models. Researcher Ryan Austin at Calif found one during an audit run under OpenAI's "Patch the Planet" project. Wiz found the same flaws independently, using AI models alongside its own tooling [5]. The PHP advisories credit reporters from both efforts and others [1][2].

The weakness wasn't entirely new. In 2024 a PHP core developer spotted the out-of-memory problem behind CVE-2026-109618 during an audit, but the team couldn't agree on a fix, and a working exploit was thought unlikely, so it wasn't prioritised [5]. The affected code dates back to PHP 5.4, released in 2012.

Timeline

The release was meant to be a normal coordinated disclosure, but it didn't stay quiet. Amazon's honeypots logged an exploit attempt on 17 October, four days early. On 20 October news leaked on Hacker News, watchTowr posted about it, and a proof-of-concept video was published by mistake, so PHP announced the release a day ahead. The fixes and the two GitHub advisories went out on 21 October, the same day as alerts from CISA, the NSA, India's CERT-In and others [5][6][10].

Some organizations didn't wait. Government portals in the Netherlands, Finland and France, many Wikimedia services and the Internet Archive went offline for a time as a precaution. Wiz compared the bug to Heartbleed, the 2014 OpenSSL flaw [5].

Am I Affected?

Versions: everything from PHP 5.4 up to, but not including, 8.2.35, 8.3.36, 8.4.27 and 8.5.12 [1][2].
Server setups: any PHP that serves web requests: Apache mod_php (highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed [4].
Old versions: PHP 8.1 and older are end of life. The PHP team released source patches for 7.4, 8.0 and 8.1, but no official builds. Older versions get nothing [5].
Hidden PHP: PHP is often bundled inside other products, such as control panels, appliances and vendor software. Cisco, for example, published its own advisory for affected products [6][7].

To check a server, look at the version and the two settings that matter most:

php -v
php -i | grep -E 'session.upload_progress.enabled|fatal_error_backtraces|memory_limit'

Run this with the same PHP the web server uses. The command-line PHP can be a different version from PHP-FPM or mod_php, so also check your web server's phpinfo() page or package list.

What to Do Now

For security teams, this goes beyond applying an update. The work falls into four steps: patch, mitigate, contain and investigate. Start by finding every PHP install, internet-facing ones first [6].

1. Patch

Upgrade to a fixed release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your Linux distribution's patched package. Then restart every PHP worker: PHP-FPM, Apache and any long-running PHP processes. Until they restart, the old code is still running [1][2].

2. Mitigate, if you can't patch today

The PHP advisories list temporary settings. Set them in php.ini, the PHP-FPM pool or the web server config. Setting them with ini_set() or .user.ini is too late to help [1][2][4].

; CVE-2026-109619: closes the confirmed session path.
; Worth keeping off after patching if you don't use upload progress bars.
session.upload_progress.enabled = 0

; CVE-2026-109619, PHP 8.5 only: closes the confirmed backtrace path.
fatal_error_backtraces = 0

; CVE-2026-109618: avoids the out-of-memory jump. Not a complete fix,
; so pair it with tight request limits below and at your proxy.
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 2M

Limit requests before they reach PHP. At nginx, Apache or your load balancer, cap request size, the number of form fields and multipart parts, and headers per part. If your app doesn't take file uploads or multipart forms, block them entirely [1].
Put a web application firewall in front if you have one [6].
Don't rely on RLIMIT_AS or RLIMIT_DATA. These operating system memory limits can trigger the very bug you're trying to avoid [1].
Hiding errors doesn't help. Turning off display_errors or using @ doesn't stop the stale state from being used [4].

These settings only close the paths researchers have confirmed so far. Both advisories say updating is the only complete fix [1][2].

3. Contain

If an internet-facing system can't be patched yet, or runs PHP 8.1 or older, take it offline until it's patched or upgraded. This is what the NSA and CISA both advise [3][6]. Several governments, Wikimedia and the Internet Archive did exactly this on 21 October [5].

4. Investigate

Exploit attempts started before the patch, so a patched server may already have been hit. Look for:

PHP worker processes starting a shell (sh, bash) or tools like curl and wget [6].
Signs of persistence: new or changed .php files in web directories (especially upload folders), new cron jobs or new user accounts.
Unexpected outbound connections from web servers.
Bursts of large or unusual multipart POST requests in your access logs.

Clean logs don't prove a server is safe [2]. If you find signs of compromise, treat it as an incident: rotate the database passwords and API keys stored on that server, not just the PHP version.

The Bigger Lesson

Legacy code isn't harmless just because it's familiar. The code behind PHP2Shell had run on millions of servers for 14 years, and it was trusted because nothing had gone wrong yet.

Neither bug was in anyone's PHP code. Both were memory-safety bugs in the PHP engine, which is written in C: memory used after it was freed, and data used before it was fully set up. These are the same classes of bug the NSA and CISA have pointed to for years when they urge a move to memory-safe languages for new code [8][9].

Two other points stand out. AI-assisted audits found bugs that had sat in widely used code for over a decade, and attackers have the same tools. And PHP runs a large share of the web, yet the PHP Foundation has only 13 employees and relies on donations [5]. If your business depends on PHP, supporting the foundation is part of keeping it safe.

For now, the steps are simple: find every PHP server, update it, restart it, and check it wasn't hit first.

References

Advisories

PHP. RCE via OOM corruption (CVE-2026-109618, GHSA-w8hw-w9fx-j79w). https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
PHP. RCE via stale global state (CVE-2026-109619, GHSA-6wmf-4rv5-p3rp). https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
NSA Cybersecurity. Post on PHP vulnerabilities, 21 October 2026. https://x.com/NSACyber/status/2112903220209098897

Analysis and background

Rapid7. CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP. https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/
Wikipedia. PHP2Shell. https://en.wikipedia.org/wiki/PHP2Shell
CISA. Critical Vulnerabilities in PHP Require Immediate Patching, 21 October 2026. https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
Cisco. Vulnerabilities in PHP Affecting Cisco Products: October 2026. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-php-october26-Jj384Daq
NSA. Software Memory Safety (Cybersecurity Information Sheet). https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
CISA. The Case for Memory Safe Roadmaps. https://www.cisa.gov/resources-tools/resources/case-memory-safe-roadmaps
CERT-In. Vulnerability Note CIVN-2026-0510: PHP2Shell vulnerabilities in PHP, 21 October 2026. https://www.cert-in.org.in/s2cMainServlet?VLCODE=CIVN-2026-0510&pageid=PUBVLNOTES01
NewsBytes. US NSA and India's CERT-In flag 'PHP2Shell' web risk. https://www.newsbytesapp.com/news/science/us-nsa-and-indias-cert-in-flag-php2shell-web-risk/tldr

CobuildX helps teams modernise legacy systems with MigrateX.

Originally published on the CobuildX blog.

Modernize Your Legacy Frontend Without a Rewrite

Emmanuel R — Tue, 20 Oct 2026 08:06:01 +0000

Rewrites don't fail because of the new framework. They fail because of everything the old app does that nobody wrote down.

MigrateX moves legacy frontends — Ember, Backbone, Angular, jQuery — to React one feature at a time, while your product keeps shipping.

🔍 Map everything first. Every route, service and hidden side effect, before a line is ported.
🔀 Ship behind a switch. Each feature can be turned back to the old app instantly.
✅ Prove parity. The same tests run on old and new. It goes live only when both pass.
🧹 Leave nothing behind. Old code, switches and glue removed. One clean codebase.

No feature freeze. No launch day.

See it working: five real apps migrated in the open → migratex-examples

👉 cobuildx.ai/migratex · Try the platform

Modernizing Legacy Apps with RxJS: Streams as the Bridge Between Old and New

Emmanuel R — Mon, 12 Oct 2026 05:32:08 +0000

In most legacy migrations, the difficult part is the async code, not the templates: callbacks, observers, global events and timers that every screen depends on. This post explains how we use RxJS as a bridge, so the old UI and the new React UI share the same streams while screens are moved one by one.

In most legacy frontend migrations, the templates are not the hard part. Templates can be ported quite easily. The hard part is the async code. A jQuery handler sends a request, sets a global flag and fires a custom event. A Backbone model has three views listening to its change event. An Ember observer saves data on every keystroke. A setInterval keeps polling the server, and nobody in the team knows why it was added.

This is where the actual behavior of a legacy app lives, and it is spread across every page. We cannot move it one route at a time, because both the old screens and the new screens depend on it.

In such projects, we use RxJS as a bridge between the old app and the new one. We do not use it as the final architecture, and we do not use it just because Angular uses it. The approach is simple. Wrap each legacy event source in an Observable and keep the shared state behind a stream. Now the old UI and the new React UI can subscribe to the same data while screens are moved one by one. As a bonus, a lot of hand-written debounce, retry and cancel logic becomes a few lines of operators. This is the branch by abstraction pattern, with streams as the interface.

The Short Version

Legacy pattern	What goes wrong	RxJS replacement
Callbacks and `$.Deferred` chains	Deeply nested, cannot be cancelled, errors get lost	`from(promise)`, `defer`, `switchMap`
Global or custom events (`$(document).trigger`, Backbone `on`)	Any code can fire them, and nobody removes the listeners	`fromEvent`, `fromEventPattern`, typed `Subject`s
Observers and watchers (Ember `observer`, `$scope.$watch`)	Order is not clear, and they run too often	`BehaviorSubject` + `distinctUntilChanged`
Hand-rolled debounce and timers	Old responses overwrite new ones, timers keep running	`debounceTime`, `switchMap`, `takeUntil`
Polling with `setInterval`	Requests overlap, and polling never stops	`timer` + `switchMap` / `exhaustMap`
Retry loops	Too many retries, no delay between them	`retry({ count, delay })`
WebSockets with manual reconnects	Duplicate connections, lost messages	`webSocket` + `retry` + `share`

Every row follows the same idea: treat "something that happens over time" as a value that we can pass around, combine and unsubscribe from. Once both apps use Observables, the framework on each side becomes much less important.

Why RxJS Works Well for Modernization

There are many state management libraries. For a migration, RxJS is useful for three specific reasons:

It does not depend on any framework. An Observable works the same way whether jQuery, Backbone, Ember, AngularJS or React subscribes to it. This is exactly what we need during a migration, when the old and new code run on the same page.
One model for every kind of async. DOM events, custom events, promises, timers, WebSockets and Node-style callbacks all become the same type. There is no need to write a different pattern for each source.
Cancellation and cleanup are built in. Every subscription can be closed. Legacy apps often leave handlers and timers running, and many of these leaks are bugs that users have simply got used to.

There is also one clear reason to be careful: RxJS takes time to learn, and a codebase where everything is a stream is difficult to read. We will discuss where to stop later in this post. In short, use it at the boundaries and for real event streams, not for every value in the app.

Step 1: Wrap the Legacy Event Sources

First, find every place where the old app produces events or async results, and create an Observable wrapper for each one. Do not change the legacy code at this stage. The wrapper only listens.

DOM and jQuery events. fromEvent accepts DOM elements and any object with jQuery-style on/off methods, so a jQuery object can be passed directly:

import { fromEvent, map } from 'rxjs';

// The legacy app fires: $(document).trigger('cart:updated', [cart])
export const legacyCartUpdated$ = fromEvent($(document), 'cart:updated', (_e, cart) => cart);

export const searchInput$ = fromEvent<InputEvent>(document.querySelector('#search')!, 'input').pipe(
  map((e) => (e.target as HTMLInputElement).value),
);

Backbone, Ember and anything with its own add/remove API. fromEventPattern takes an add handler and a remove handler. This way, the Observable removes its listener from the legacy object properly when it is unsubscribed:

import { fromEventPattern, startWith, map } from 'rxjs';

// Backbone model or collection
export const fromBackbone = <T>(model: Backbone.Model, event = 'change') =>
  fromEventPattern<Backbone.Model>(
    (handler) => model.on(event, handler),
    (handler) => model.off(event, handler),
  ).pipe(startWith(model), map((m) => m.toJSON() as T));

// Ember object property (Ember.addObserver / removeObserver)
export const fromEmberProperty = <T>(obj: object, key: string) =>
  fromEventPattern<T>(
    (handler) => addObserver(obj, key, handler),
    (handler) => removeObserver(obj, key, handler),
  ).pipe(map(() => get(obj, key) as T), startWith(get(obj, key) as T));

Two points are important here. First, convert to plain objects at the boundary (toJSON(), get). If the stream emits Backbone models or Ember records, the new code will also start calling .get('title'), and the legacy model will spread into React. This is the anti-corruption layer from our strategies post, applied to streams. Second, startWith gives the current value to late subscribers. So a React component that mounts later will not show an empty screen while it waits for the next change.

Promises, callbacks and sockets also have direct wrappers:

import { defer, bindNodeCallback } from 'rxjs';
import { webSocket } from 'rxjs/webSocket';

// defer: the request only starts when someone subscribes, and runs again per subscriber
export const loadOrders$ = (userId: string) => defer(() => legacyApi.getOrders(userId));

// Node-style callback API from an old SDK
export const readConfig$ = bindNodeCallback(legacySdk.readConfig);

export const prices$ = webSocket<PriceTick>('wss://example.com/prices');

For requests, prefer defer(() => promise) over from(promise). A promise starts running as soon as it is created. defer waits until someone subscribes, and this is what makes cancellation and retries possible later.

Step 2: Put Shared State Behind a Stream

Wrapping the sources makes the old app observable. The next step is to give each piece of shared state (the cart, the current user, the selected account, feature flags) a single owner. This owner is a small service that holds the value and exposes it as an Observable. Both apps read from this service, and all updates go through its methods.

import { BehaviorSubject, distinctUntilChanged, map } from 'rxjs';

export interface Cart { items: CartItem[]; total: number }

const state = new BehaviorSubject<Cart>({ items: [], total: 0 });

export const cartService = {
  cart$: state.asObservable(),
  count$: state.pipe(map((c) => c.items.length), distinctUntilChanged()),
  get value() { return state.getValue(); },

  add(item: CartItem) {
    const items = [...state.value.items, item];
    state.next({ items, total: sum(items) });
  },
};

// Keep the legacy event working for screens that still listen to it
cartService.cart$.subscribe((cart) => $(document).trigger('cart:updated', [cart]));

The legacy side subscribes and updates the DOM the same way it does today:

// legacy/header.js (jQuery)
const sub = cartService.count$.subscribe((n) => $('#cart-badge').text(n));
$('#add-to-cart').on('click', () => cartService.add(readItemFromForm()));

// Backbone view: tie the subscription to the view's lifetime
initialize() { this.sub = cartService.cart$.subscribe((c) => this.render(c)); },
remove() { this.sub.unsubscribe(); Backbone.View.prototype.remove.call(this); },

React reads the same stream through a small hook. useSyncExternalStore is the official React API for subscribing to an external store. It also avoids the "tearing" issue that a useEffect + useState version can have during concurrent rendering:

import { useSyncExternalStore } from 'react';
import type { Observable } from 'rxjs';

// Subscribe to a stream that always has a current value (like a service backed by a BehaviorSubject)
export function useStream<T>(stream$: Observable<T>, getValue: () => T): T {
  return useSyncExternalStore(
    (onChange) => {
      const sub = stream$.subscribe(onChange);
      return () => sub.unsubscribe();
    },
    getValue,
  );
}

// In a component
function CheckoutSummary() {
  const cart = useStream(cartService.cart$, () => cartService.value);
  return <p>{cart.items.length} items, {formatMoney(cart.total)}</p>;
}

That is the complete seam. A screen can move from the old app to React, and the cart badge in the legacy header will still update, because neither side owns the cart. Once the last legacy subscriber is removed, the service internals can be replaced (with Zustand, TanStack Query or plain React context) without changing any component, because components only depend on cart$ and add.

Issues we faced

Exposing the Subject directly. If the service exports state instead of state.asObservable(), any file can call .next(), and we are back to global events. Expose streams for reading and methods for writing.
Changing emitted objects in place. state.value.items.push(item) changes the object that both apps hold, but nothing is emitted. Always emit a new object, because useSyncExternalStore depends on reference changes.
Updates inside updates. A legacy handler that calls add() while handling a cart$ emission can create a loop. Using distinctUntilChanged on derived streams, and keeping the legacy re-trigger one-way, prevents most of these cases.
Loops with the legacy event. If the legacy app both fires and listens to cart:updated, either wrap it with fromEvent or re-trigger it from the service. Do not do both.

Step 3: Replace Hand-Written Async Code with Operators

Once events become streams, a lot of fragile legacy code can be rewritten in a few lines, and it usually becomes more correct too. A search box is the common example. Most legacy apps have some version of this jQuery code:

let timer, lastQuery;
$('#search').on('input', function () {
  clearTimeout(timer);
  const q = $(this).val();
  timer = setTimeout(() => {
    if (q === lastQuery) return;
    lastQuery = q;
    $.getJSON('/api/search', { q }).done(renderResults); // a slow early response can overwrite a newer one
  }, 300);
});

It looks fine, but it has a race condition. If the request for "rea" is slow and the request for "react" is fast, the old results arrive last and replace the correct ones. The RxJS version avoids this by design, because switchMap unsubscribes from the previous request as soon as a new query comes in:

import { debounceTime, distinctUntilChanged, filter, switchMap, catchError, of } from 'rxjs';
import { ajax } from 'rxjs/ajax';

export const results$ = searchInput$.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  filter((q) => q.length >= 2),
  switchMap((q) =>
    ajax.getJSON<SearchResult[]>(`/api/search?q=${encodeURIComponent(q)}`).pipe(
      catchError(() => of([])), // one failed search shouldn't kill the stream
    ),
  ),
);

ajax from rxjs/ajax cancels the actual HTTP request when it is unsubscribed. With fetch, pass an AbortSignal inside new Observable (or use fromFetch from rxjs/fetch) to get the same behavior.

The same small set of operators covers most of the other hand-written patterns we see in legacy apps:

Need	Operator	Why it is better than the legacy version
Only the latest request matters (search, filters, route params)	`switchMap`	Cancels old requests, so results never arrive out of order
Ignore clicks while a save is in flight	`exhaustMap`	Replaces `isSaving` flags and disabled-button workarounds
Every action must run, in order (queued writes)	`concatMap`	Writes do not mix, and no update is lost
Poll until the user leaves the page	`timer(0, 5000).pipe(switchMap(load), takeUntil(leave$))`	Polls never overlap, and polling stops reliably
Retry flaky calls with backoff	`retry({ count: 3, delay: (_, i) => timer(2 ** i * 500) })`	Limited attempts with a growing delay
Combine several sources	`combineLatest`, `withLatestFrom`	Replaces flags like `if (userLoaded && settingsLoaded)`
Time out a slow call	`timeout({ first: 8000 })`	Configured in one place, and errors are reported properly

Polling needs one more example, because legacy polling code often causes duplicate requests and battery drain:

import { timer, defer, switchMap, takeUntil, retry, share, fromEvent, filter } from 'rxjs';

const hidden$ = fromEvent(document, 'visibilitychange').pipe(filter(() => document.hidden));

export const jobStatus$ = (jobId: string) =>
  timer(0, 5000).pipe(
    switchMap(() => defer(() => api.getJob(jobId))),
    retry({ count: 3, delay: 1000 }),
    takeUntil(hidden$),
    share(), // several widgets can watch the same job with one poller
  );

Common Mistakes

Leaked subscriptions

Every subscribe() must be closed at some point. In legacy code, connect it to the lifecycle that already exists: a Backbone view's remove, an Ember component's willDestroy, an AngularJS $scope.$on('$destroy'), or a jQuery plugin's destroy. In React, the hook's cleanup takes care of it. For streams that should end on an event, keep takeUntil(destroy$) as the last operator in the pipe, so that nothing after it can subscribe again.

Hot and cold Observables

A cold Observable (like defer(() => fetch(...))) runs again for every subscriber. If three components subscribe to the same stream, three requests are made. When a result should be shared, add share() or shareReplay({ bufferSize: 1, refCount: true }). Use refCount: true unless the source really needs to run forever. Without it, shareReplay keeps the inner subscription (and its polling or socket) running even after the last subscriber has left.

Turning everything into a stream

A common mistake in RxJS projects is a codebase where a simple boolean flag becomes a BehaviorSubject<boolean> passed through four operators. Use streams only where time matters: events, sockets, polling, typeahead and state shared between the two apps. For normal server data in React (load a list, show it, refetch on change), TanStack Query is simpler and also handles caching. For local component state, use useState. A simple rule: if you cannot draw a marble diagram for it, it probably should not be an Observable.

Errors stop streams

When an error reaches a long-running stream, the stream ends and every subscriber stops getting updates, without any visible message. Catch errors inside the switchMap/mergeMap (as shown in the search example) so that the outer stream keeps running, and log every error you catch.

Bundle size and RxJS versions

RxJS 7 supports tree-shaking, and from version 7.2 the operators are exported directly from rxjs. So a typical bridge layer adds only a small amount to the bundle. If the legacy app still uses RxJS 5 or 6 (common in older Angular apps), the official migration guide explains the upgrade to 7. rxjs-compat was meant only for the 5 to 6 upgrade and should not be used in a new layer.

Testing the Bridge

Streams are easy to test without a browser. TestScheduler runs time-based operators on virtual time, so a 300 ms debounce does not actually wait 300 ms. Marble strings describe the input and the expected output:

import { TestScheduler } from 'rxjs/testing';

// The search stream, with its inputs passed in instead of read from globals
export const searchPipeline = (input$: Observable<string>, search: (q: string) => Observable<SearchResult[]>) =>
  input$.pipe(debounceTime(300), distinctUntilChanged(), filter((q) => q.length >= 2), switchMap(search));

const scheduler = new TestScheduler((actual, expected) => expect(actual).toEqual(expected));

test('search only queries the last term after a pause', () => {
  scheduler.run(({ cold, expectObservable }) => {
    const input$ = cold('a 100ms b 400ms c|', { a: 'rea', b: 'react', c: 'react' });
    const api = (q: string) => cold('--r|', { r: [`result for ${q}`] });
    // 'rea' is dropped by the debounce; 'react' settles at 401ms, its result arrives 2 frames later
    expectObservable(searchPipeline(input$, api)).toBe('403ms x 99ms |', { x: ['result for react'] });
  });
});

Writing the pipeline as a function of its inputs is what makes it testable, and it is a good practice for the seam in any case. For checking that both apps behave the same, use the approach from our migration guides: one end-to-end test suite that runs the same screen in the old app and in the new app, and checks for the same visible result. The stream layer is what keeps those results the same, so it needs good test coverage.

Temporary Bridge or Long-Term Layer?

At the end of the migration, decide what happens to the RxJS layer. Both options below are fine, as long as the team makes a clear decision:

Temporary bridge. The bridge was added so that old and new code could share state. Once the legacy app is removed, plain React state, TanStack Query or a small store can handle most of it. Remove the Subjects, and keep only the few streams that represent real events.
Long-term layer. Apps with a lot of real-time behavior (trading screens, live dashboards using sockets, collaborative editors, IoT consoles) often keep RxJS as the event layer under React. In that case, document the rules: where streams are kept, how errors are handled, and which shared streams use shareReplay.

Whichever option you choose, delete the fromEventPattern wrappers around legacy objects in the same sprint as the last legacy screen. These wrappers are always temporary.

Further in This Series

This post covers one technique within a larger migration plan. The posts below explain the overall plan and each starting framework in more detail:

Frontend migration strategies: strangler fig, branch by abstraction and vertical slicing, and how they combine.
One-way vs two-way data binding: why observers and watchers are difficult to migrate, and what replaces them.
Framework guides: Angular, Ember, Backbone, jQuery and vanilla JS to React.

Our Migration Plugins

Finding every event source, observer and shared service in a legacy app takes the most time, and it decides where the streams should go. We have packaged our approach as free, open-source plugins for Claude Code, one for each starting framework:

Plugin	Migrates from
`ember-to-react`	Ember Classic and Octane
`angular-to-react`	Angular 2+ and AngularJS 1.x, including hybrid ngUpgrade apps
`backbone-to-react`	Backbone.js, Marionette, jQuery templates
`jquery-to-react`	jQuery apps, plugins and jQuery UI
`vanillajs-to-react`	Plain HTML, CSS and JavaScript

Each plugin comes with a migration skill, a /<plugin>:plan command that writes a migration plan (strategy, units, route map, test plan and risks) without touching your code, a read-only inventory agent that maps the old app, a parity-reviewer agent that compares each migrated piece with its original, and a bundled Context7 server for up-to-date library docs. To install one in Claude Code:

/plugin marketplace add cobuild-tech/cbx-plugins
/plugin install backbone-to-react@cbx-plugins

They also work in Cursor, in VS Code with GitHub Copilot, and in the GitHub Copilot CLI. Progress is kept in a .migration/ folder in your repo, so a migration can carry on across sessions and teammates. The source and setup steps are at cobuild-tech/cbx-plugins, and issues are welcome.

About MigrateX

A MigrateX project usually runs like this:

Assessment. We map every route, shared service, event source and hidden dependency in your app, so you see where the work is before anyone agrees on a timeline.
Plan. With your team, we choose the strategy, the slice order, and what can simply be deleted.
Migration, step by step. Automation handles the repetitive parts. Our engineers handle the router, the seams and the code that connects old and new.
Proof that it works. The same tests run against both versions. A piece only counts as moved when it passes on both.
Handover. We remove the temporary code, the seams and the flags, and leave your team with a codebase they understand and own.

Your app keeps running and shipping features the whole time, so there's no big launch day. Our migratex-examples repo has small apps in each legacy framework next to their migrated versions.

Working on the async code of a legacy app? Share a few details with us through Contact Us, and we will start with a free discussion on where the seams should go.

References

RxJS

RxJS. Overview and API reference. https://rxjs.dev/guide/overview
RxJS. fromEventPattern. https://rxjs.dev/api/index/function/fromEventPattern
RxJS. Testing RxJS Code with Marble Diagrams. https://rxjs.dev/guide/testing/marble-testing
RxJS. Breaking Changes in Version 7. https://rxjs.dev/deprecations/breaking-changes
Ben Lesh. Hot vs Cold Observables. https://benlesh.medium.com/hot-vs-cold-observables-f8094ed53339

React and migration patterns

React. useSyncExternalStore. https://react.dev/reference/react/useSyncExternalStore
Martin Fowler. Branch By Abstraction. https://martinfowler.com/bliki/BranchByAbstraction.html
Microsoft. Anti-corruption Layer pattern. https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer
TanStack Query. Overview. https://tanstack.com/query/latest/docs/framework/react/overview

Source code

CobuildX AI. cbx-plugins: Claude Code plugins for Backbone, Angular, Ember, jQuery and Vanilla JS to React migrations. https://github.com/cobuild-tech/cbx-plugins
CobuildX AI. migratex-examples: small jQuery, Backbone, Angular, Ember and Vanilla JS apps and their migrated versions. https://github.com/cobuild-tech/migratex-examples

Originally published on the CobuildX blog.

Strangler Fig, Branch by Abstraction, Vertical Slices: Choosing a Frontend Migration Strategy

Emmanuel R — Mon, 12 Oct 2026 05:31:32 +0000

Strangler fig, branch by abstraction, vertical slicing: the strategy decides whether a frontend migration ships, more than the framework you move to. Here's how each one works, where each one bites, and how we combine them on real projects.

Teams that plan a frontend migration spend weeks on the target: React or Vue, Next.js or Vite, Redux or TanStack Query. Then they spend almost no time on the part that decides whether it ships: how the old app and the new app will live together until the old one is gone.

That part is the migration strategy. Pick the wrong one and a good framework choice still turns into an 18-month rewrite branch that never merges. Pick the right one and even a messy legacy app moves over a piece at a time, with users never noticing a launch day.

This post covers the strategies we actually use: the big-bang rewrite (as the baseline), the strangler fig, branch by abstraction, and vertical slicing, plus the supporting tactics that make them safe: parallel runs, feature flags, micro-frontends, anti-corruption layers and expand-contract. Then it shows how they fit together, because on a real project you rarely use just one. Our framework-specific guides (Angular, Ember, Backbone, jQuery, vanilla JS) go deeper on each starting point. This one is about the strategy underneath all of them.

The Short Version

Strategy	Unit of change	What runs side by side	Rollback	Best for
Big-bang rewrite	The whole app	Nothing in production until launch day	Hard: the old app has gone stale	Small or frozen apps
Strangler fig	A route or a screen	Old and new apps behind one router	Point the route back at the old app	Apps with clear routes or pages
Branch by abstraction	A shared dependency behind a seam	Old and new implementations behind one interface	Flip the switch back	Services, stores and widgets used everywhere
Vertical slicing	One user-facing feature, top to bottom	Migrated and unmigrated features	Per slice	Choosing the order of work

The first row is the one people start with. The other three are what actually works, and they answer different questions. Strangler fig decides where the line between old and new runs. Branch by abstraction handles the things that cross that line. Vertical slicing decides what to move next.

Big-Bang Rewrite: the Baseline

The big-bang rewrite is the default plan nobody writes down: start a new repo, rebuild everything, switch over on a chosen day. It's worth understanding properly, because every other strategy exists to avoid its failure modes.

When it is actually right

The app is small. A few screens that one or two people can rebuild in a few weeks. The overhead of running two apps side by side costs more than the rewrite.
The app is frozen. No new features are planned, so the old app won't move while you rebuild it.
The old app can't host anything new. Some legacy stacks make it so painful to mount new code that coexistence costs more than starting clean. This is rarer than it seems. Almost anything can serve an iframe or hand off a route.

Why it usually fails

The target keeps moving. The business doesn't stop for your rewrite. Every feature shipped in the old app is one more thing the new one has to catch up on, and the gap rarely closes.
Nothing is proven until the end. Months of work with zero real users means every wrong assumption surfaces on launch day, all at once.
The old app holds knowledge nobody wrote down. Ten years of bug fixes are hidden in it. Joel Spolsky called rewriting from scratch the single worst strategic mistake a software company can make, for exactly this reason.
Rollback is fiction. By launch day the old app is months behind. "Roll back" means going back to software everyone has stopped maintaining.

The incremental strategies below all share one idea: get the new code in front of real users early, in small pieces, while the old app keeps running.

Strangler Fig

Martin Fowler named this pattern after a vine that grows around a host tree until the tree is gone and the vine stands on its own. In a frontend migration, the vine is the new app and the tree is the old one.

How it works

Put something in front of both apps. A reverse proxy, a CDN rule, or a thin shell app that owns the router. Every request goes through it.
Send every route to the old app at first. Nothing has changed for users, but the switch now exists.
Move one route. Build it in the new app and flip that one path in the router.
Repeat until the old app serves nothing. Then switch it off.

The routing layer can be as simple as a list of migrated paths:

// shell/router.ts: which app owns which path
const MIGRATED = ['/settings', '/profile/:username', '/article/:slug'];

export function ownerOf(path: string): 'react' | 'legacy' {
  return MIGRATED.some((p) => matchPath(p, path)) ? 'react' : 'legacy';
}

In production this is often a CDN or proxy rule instead of code, and each route can sit behind a feature flag so you can roll it out to 5% of users first.

Route-level or widget-level

There are two grains to strangle at:

Route-level. Whole pages move at once. It's the cleanest option: each page is owned by one framework, and the boundary is a URL. Start here if your app has real routes.
Widget-level. New components are mounted inside old pages (a React date picker inside an Ember template, for example). This is how you migrate apps with one giant page, or a shared header that appears everywhere. It's more fragile, because the two frameworks now share a DOM.

Most projects use both: widget-level for the shared shell (nav, header, notifications), route-level for everything else.

Where it shines

Real users see real progress within weeks. Every migrated route is in production.
Rollback is one line. Point the route back at the old app.
Feature work never stops. New features go straight into the new app.
The end is visible. "34 of 52 routes migrated" is a progress bar a manager can read.

Where it costs you

Two runtimes at once. Users may download both frameworks for a while. Keep the old bundle off migrated pages where you can.
Shared state across the boundary. Login, the current user, feature flags and unsaved drafts have to be readable by both apps. Put them somewhere neutral: a cookie, localStorage, or the API.
CSS bleed. Global styles from one app leak into the other. Scope the new app's styles (CSS Modules, a prefix, or Shadow DOM) before you mount anything.
Navigation between apps. Crossing from a React page to an Ember page is a full page load unless the shell handles it. Users notice this, so group related routes and move them together.

Gotchas we hit

The router is the hard part, not the pages. Agree on how deep links, redirects, 404s and query strings behave across both apps before moving a single route.
Auth needs to move first. If the new app can't read the old app's session, every migrated page looks logged out. A shared cookie is the usual fix.
Don't strangle by file. Moving "all the components in /shared" isn't strangling, it's a horizontal layer (see vertical slicing below). Strangle by what users see.
Delete as you go. Once a route is moved and stable, remove its old code. Otherwise the old app never shrinks and you end up maintaining both forever.

The Angular guide walks through a strangler fig migration end to end, including the shell app and the staged rollout.

Branch by Abstraction

Strangler fig works when the thing you're replacing has a clear boundary, like a URL. But some parts of a frontend don't have one. The data layer, the auth service, the API client, the store, a date library: they're used from every page. You can't route around them. Branch by abstraction is the pattern for those.

The name comes from Paul Hammant and is described by Fowler and trunkbaseddevelopment.com. The idea: instead of making a long-lived version-control branch to replace something, you make the "branch" in the code itself, behind an interface.

How it works

Add a seam. Write an interface that describes what callers need. Make the old implementation fit it.
Move callers onto the seam. One at a time, change code that talks to the old thing directly so it talks to the interface instead. Ship each change. Nothing behaves differently yet.
Build the new implementation behind the same interface, in the main branch, switched off.
Switch over. A flag picks the new implementation, first for internal users, then for everyone.
Delete the old implementation, and the flag. If the seam isn't useful anymore, delete it too.

Here's what that looks like for a data layer. Say pages load articles through an Ember Data store or Backbone models, and you're replacing that with a plain API client and TanStack Query. The seam is a small repository interface:

// articles/repository.ts: the seam
export interface ArticleRepository {
  get(slug: string): Promise<Article>;
  list(filter: ArticleFilter): Promise<Article[]>;
  save(input: ArticleInput): Promise<Article>;
}

// old: wraps the legacy store, converting its records to plain objects
export const legacyArticles: ArticleRepository = {
  get: async (slug) => toArticle(await store.queryRecord('article', { slug })),
  list: async (filter) => (await store.query('article', filter)).map(toArticle),
  save: async (input) => toArticle(await store.createRecord('article', input).save()),
};

// new: talks to the API directly
export const apiArticles: ArticleRepository = {
  get: (slug) => api.get(`/articles/${slug}`).then((r) => r.article),
  list: (filter) => api.get('/articles', filter).then((r) => r.articles),
  save: (input) => api.post('/articles', { article: input }).then((r) => r.article),
};

export const articles: ArticleRepository =
  flags.isOn('articles-api') ? apiArticles : legacyArticles;

Two details make this work. First, the interface speaks plain objects, not framework records. If callers receive Ember Data models, they'll keep calling .get('title') and you haven't built a seam, just a wrapper. Second, both implementations live in the main branch and are tested in CI. The "branch" is a flag, not a Git branch.

Where you'll use it in a frontend

The data layer. Ember Data, Backbone collections, Angular services with their own caches → a query library. This is the most common use.
Auth and session. One session interface that both the old and new apps call, so login works on both sides of the strangler boundary.
A shared component. The date picker, the rich text editor, the data grid. Wrap it in one component API, then swap the implementation underneath.
A library replacement that isn't a framework change at all: moment.js → date-fns, a charting library, an HTTP client.

Why not just use a long-lived branch?

Because a migration branch that lives for months is a big-bang rewrite in disguise. It drifts from main every day, the merge at the end is huge, and nothing in it has met a real user. Branch by abstraction keeps every step small and merged. It pairs naturally with trunk-based development and with feature toggles.

The cost: extra code for a while (the interface, two implementations and a flag), and the discipline to actually do step five. Seams and flags that outlive the migration become their own kind of legacy.

Vertical Slicing

Strangler fig and branch by abstraction tell you how to keep old and new running together. Vertical slicing tells you what to move next.

A vertical slice is one user-facing feature moved top to bottom: its UI, its state, its data access, its routes and its tests, all together, until a user can do that thing entirely in the new code. The opposite is a horizontal layer: "first we'll port all the models, then all the services, then all the components".

Why horizontal layers fail

Nothing ships until the last layer is done. Porting every model first gives you months of code with no user, which is the big-bang problem again.
You guess at requirements. Without a real screen using it, a ported service is shaped by what the old code did, not what the new UI needs.
Progress is invisible. "80% of the services are done" means nothing to the people paying for it.

Choosing the first slice

The first slice is mostly about proving the plumbing: routing between apps, shared auth, the build and deploy, the test setup. So pick one that is:

Real, but low-risk. A settings page or a profile page, not checkout.
Light on shared dependencies. It shouldn't need half the app's services to render.
Easy to compare. It has clear behavior you can test old against new.
Used often enough that you'll hear quickly if something's wrong.

After the first one, order the rest by value against coupling. Move high-value, loosely coupled features early. Leave the tangled core, the screen that touches everything, until the seams around it already exist.

How slices map onto the other strategies

In a well-run migration, a vertical slice usually is a strangler fig step: a feature is a set of routes, and moving the feature means flipping those routes. When a slice hits a dependency it shares with unmigrated features (the article store used by both the feed and the editor), that's where a branch-by-abstraction seam goes in.

Supporting Tactics

These aren't migration strategies on their own. They're tools that make the three above safe.

Parallel run and dark launching

Run the new code alongside the old one in production, compare the results, but only show the old one. GitHub's Scientist library made this famous for backend code. In a frontend it's useful for a new data layer or a new calculation (pricing, permissions, validation): call both implementations behind the seam, log any differences, return the old result. Once the differences hit zero, switch. Dark launching is the same idea for whole features: ship them to production hidden, and turn them on later.

// compare old and new behind the seam; users still get the old result
async function get(slug: string) {
  const [oldResult, newResult] = await Promise.allSettled([
    legacyArticles.get(slug),
    apiArticles.get(slug),
  ]);
  reportDiff('articles.get', oldResult, newResult);
  if (oldResult.status === 'rejected') throw oldResult.reason;
  return oldResult.value;
}

Watch the cost: a parallel run doubles API calls. Sample a percentage of traffic, and never run both sides of a write.

Feature flags and canary releases

Every switch in this post (a migrated route, a new implementation behind a seam) should be a flag you can flip without a deploy. That lets you release to staff first, then 5% of users, then everyone, and roll back in seconds. Name each flag after the migration step and give it an expiry date. The feature toggles article on Fowler's site is the best guide to keeping them under control.

Micro-frontends as a way to coexist

Micro-frontends (module federation, single-spa, web components) let several apps share one page. They're a useful vehicle for widget-level strangling: the old app becomes one micro-frontend, the new one another. But think twice before making them the destination. If the goal is one React app, use the micro-frontend setup as scaffolding and take it down when the migration ends. Otherwise you've swapped one legacy app for a distributed system.

Anti-corruption layer

An anti-corruption layer translates between the old model and the new one so the old model's quirks don't leak into new code. The toArticle() function in the branch-by-abstraction example is a tiny one: it turns a legacy record (with its computed properties, observers and odd field names) into a plain object the new code can trust. Keep these at the boundary and delete them when the old side is gone.

Expand and contract

Also called parallel change. When old and new code share data (an API response, a localStorage key, a URL format, a cookie), you can't change its shape in one go. Expand first: support both the old and new shapes. Migrate each reader and writer. Contract: remove the old shape once nothing uses it. It's how you rename a query parameter or restructure saved user preferences without breaking the half of the app that hasn't moved yet.

Combining Them: the Playbook We Use

On a real project these aren't alternatives. They are layers of one plan:

Question	Answered by
Where does the line between old and new run?	Strangler fig (routes, then widgets)
What do we move next?	Vertical slicing (value against coupling)
What about things every page depends on?	Branch by abstraction (a seam, two implementations, a flag)
How do we know the new one behaves the same?	Parallel run and shared tests
How do we release and roll back?	Feature flags and canaries
How do we change shared data safely?	Expand and contract

In phases:

Foundation. Put the shell or proxy in front of the old app, with every route still pointing at it. Make auth work on both sides. Set up one test suite that can run against either app. Add seams around the data layer and other shared services. Nothing changes for users.
First slice. Move one low-risk feature end to end. Its real job is to prove the plumbing: routing, auth, deploys, monitoring, rollback.
Steady state. Move slices in order of value against coupling. Each slice is a set of routes flipped behind a flag. Switch seams to their new implementations as soon as their callers allow it, with a parallel run where correctness matters. Ship new features only in the new app.
Removal. When the old app serves no routes, switch it off. Then delete the seams you no longer need, the anti-corruption layers and every migration flag. A migration isn't done until the scaffolding is gone.

Choosing a Strategy

If you're deciding where to start, these questions settle most of it:

If your app…	Lean towards
Is a handful of screens, or is frozen	Big-bang rewrite. Coexistence isn't worth it.
Has clear routes and pages	Strangler fig at route level
Is one giant page, or has a shared shell everywhere	Strangler fig at widget level, often with a micro-frontend host
Has a data layer, store or service every page uses	Branch by abstraction around it, early
Has few tests	Write tests at the user level (end-to-end) first, then any strategy. Without them, nothing tells you a slice is done.
Has many teams shipping in parallel	Vertical slices owned by one team each, behind flags
Must keep shipping features during the migration	Anything except big-bang

Measuring Progress and Knowing When You're Done

Incremental migrations have a known failure mode: they stall at 80%. The easy routes are done, the hard core remains, and the team gets pulled onto feature work. You end up running two frameworks forever. Measuring progress openly is the best defense:

Routes served by the new app, as a percentage of traffic, not just a count. Ten rarely used admin pages don't equal one home feed.
Lines of legacy code left, falling every week. If it stops falling, something is wrong.
Seams and flags still open. Each one is temporary and should have an owner and an end date.
Parity results. For each slice: do the same tests pass against old and new, and does the parallel run show zero differences?

And a short definition of done that every slice has to meet before its old code is deleted: same tests passing on both, flag at 100% for a full release cycle with no rollbacks, no remaining imports of the old code, and the old code removed in the same sprint.

Big-bang rewrites fail on a deadline. Incremental migrations fail on discipline. Pick the failure you can manage.

Bottom line:

Get new code in front of real users early. Every strategy that works is built on this.
Strangle by what users see, route by route, not file by file.
Put a seam around anything every page depends on, and switch it with a flag, not a merge.
Move whole features, not layers. A finished slice ships. A finished layer doesn't.
Delete as you go, including the scaffolding. The migration ends when the seams and flags are gone, not when the last route moves.

Further in This Series

Each of these takes the strategies above and applies them to one starting point or one design decision:

Moving from Angular to React: A Practical Guide, with the strangler fig worked end to end.
Leaving Ember for React: What Your Conventions Were Hiding, where Ember Data is a classic branch-by-abstraction candidate.
The Framework Nobody Wrote Down: Taking a Backbone App to React
Who Updates the Total? Taking a jQuery App to React, mostly widget-level strangling.
The State Is in the DOM: Taking a Vanilla JavaScript App to React
Client Patterns: MVC, MVVM, and What Came After
One-Way vs Two-Way Binding
Client-Side vs Server-Side Rendering

Our Migration Plugins

Choosing a strategy starts with knowing the app: every route, every shared service, every piece of hidden wiring. That map is slow to build by hand. We've packaged how we do it as free, open-source plugins for Claude Code, one per starting point. Each one plans an incremental, strangler-fig migration by default:

Plugin	Starts from
`ember-to-react`	Ember Classic and Octane
`angular-to-react`	Angular 2+ and AngularJS 1.x, including hybrid ngUpgrade apps
`backbone-to-react`	Backbone.js, Marionette, jQuery templates
`jquery-to-react`	jQuery apps, plugins and jQuery UI
`vanillajs-to-react`	Plain HTML, CSS and JavaScript

/plugin marketplace add cobuild-tech/cbx-plugins
/plugin install ember-to-react@cbx-plugins

About MigrateX

A MigrateX project usually runs like this:

Assessment. We map every route, shared service and hidden dependency in your app, so you see where the work is before anyone agrees on a timeline.
Plan. With your team, we choose the strategy, the slice order, and what can simply be deleted.
Migration, step by step. Automation handles the repetitive parts. Our engineers handle the router, the seams and the code that connects old and new.
Proof that it works. The same tests run against both versions. A piece only counts as moved when it passes on both.
Handover. We remove the temporary code, the seams and the flags, and leave your team with a codebase they understand and own.

Your app keeps running and shipping features the whole time, so there's no big launch day. Our migratex-examples repo has small apps in each legacy framework next to their migrated versions.

Planning a migration and not sure which strategy fits? Tell us a little about your app through Contact Us, and we'll start with a free chat about where the work is likely to be.

References

Further reading

Martin Fowler. Strangler Fig Application. https://martinfowler.com/bliki/StranglerFigApplication.html
Martin Fowler. Branch By Abstraction. https://martinfowler.com/bliki/BranchByAbstraction.html
Paul Hammant. Branch by Abstraction. https://www.branchbyabstraction.com/
Trunk Based Development. Branch by Abstraction. https://trunkbaseddevelopment.com/branch-by-abstraction/
Danilo Sato. Parallel Change. https://martinfowler.com/bliki/ParallelChange.html
Ian Cartwright, Rob Horn and James Lewis. Patterns of Legacy Displacement. https://martinfowler.com/articles/patterns-legacy-displacement/
Pete Hodgson. Feature Toggles (aka Feature Flags). https://martinfowler.com/articles/feature-toggles.html
Cam Jackson. Micro Frontends. https://martinfowler.com/articles/micro-frontends.html
Microsoft. Strangler Fig pattern. https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
Microsoft. Anti-corruption Layer pattern. https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer
GitHub. Scientist: a library for carefully refactoring critical paths. https://github.com/github/scientist
Joel Spolsky. Things You Should Never Do, Part I. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Sam Newman. Monolith to Microservices. O'Reilly, 2019. https://samnewman.io/books/monolith-to-microservices/

Source code

CobuildX AI. cbx-plugins: Claude Code plugins for Backbone, Angular, Ember, jQuery and Vanilla JS to React migrations. https://github.com/cobuild-tech/cbx-plugins
CobuildX AI. migratex-examples: small jQuery, Backbone, Angular, Ember and Vanilla JS apps and their migrated versions. https://github.com/cobuild-tech/migratex-examples

Originally published on the CobuildX blog.

Jev as a Red-Teaming Guardrail: Putting TypeSafe's Model to Work in AI Security

Emmanuel R — Thu, 08 Oct 2026 11:03:01 +0000

We ran TypeSafe's Jev as a prompt guardrail on 1,580 red-teaming prompts against GPT-5-mini, Claude Haiku 4.5 and three open-source guard models. It was five to six times faster, 6–27× cheaper, and had the highest block accuracy of the hosted models.

TypeSafe's Jev promises LLM-grade decisions at a fraction of the time and cost. We put that claim to a practical test: using Jev as a guardrail that screens prompts before they reach an AI agent. Across 1,580 red-teaming prompts from public jailbreak, prompt-injection and harmful-content benchmarks, we compared Jev with OpenAI GPT-5-mini, Claude Haiku 4.5 and three open-source guard models on speed, cost, and how well each one decides what to block and names the risk.

Hype around Jev

TypeSafe launched Jev with this headline [1]:

Why the hype? Orders of magnitude? Is comparing it to an LLM even fair? Let's dig into where that speed comes from, and whether it holds up.

How Jev differs from an LLM

At a high level, Jev predicts the probability of each option in a set of choices or actions that you define, using the prompt or context you give it as the state. You might ask "should this input be blocked?" and "which of these 24 risk categories does it fall into?". Jev returns calibrated probabilities for every option in a single pass.

An LLM works differently. It generates its output one token at a time (The 'decode' phase), and each step depends on the tokens it has already produced. This stepwise decode phase is where most of an LLM's latency comes from. To use an LLM as a classifier, you ask it to write out its decision, usually as JSON, and then parse that text.

That difference has practical consequences:

The output is typed. Jev returns probabilities and choices, not free text. There is nothing to parse, and no output can arrive malformed.
The cost structure is different. Jev bills for input tokens only; its output is free [2]. An LLM bills for both, and at a higher rate for output.
Latency does not grow with the answer. A single scoring pass does not slow down as the answer gets longer, because there is no answer to write out token by token.

Where Jev is a better fit

Jev is not a replacement for an LLM. It does not write answers, summarise documents or generate code. What it targets is the large class of tasks inside AI systems where the output is a decision:

guardrails that decide whether an input or action should be blocked
routing requests to the right model, tool or team
classification, moderation and triage at high volume
choosing the next action in an agent workflow

These decisions often sit in the critical path of every request. In that position, each additional second and each additional cent is paid on every call. That is where a model built only for decisions has the most to gain.

What we tested: Jev as a red-teaming guardrail

Agent security is a natural test for this kind of model. A guardrail has to read one input and make two calls:

Should this input be blocked? It might be a harmful request, a jailbreak attempt, or a prompt injection hidden inside a document or tool response.
What kind of risk is it?

For the second question, every model chooses from 24 risk categories, and the risk category each prompt carries in its source dataset is the ground truth. 22 of these come from RedBench's risk taxonomy [3]. We added No risk for benign inputs and Prompt attack for jailbreak and injection attempts that target no specific harm.

Risk category	Covers
No risk	Benign request; safe to answer normally, even if it uses alarming words
Abusive content	Harassment, insults, bullying or degrading language
Bias content	Stereotyping or unfair treatment of groups
CBRN information or capabilities	Chemical, biological, radiological or nuclear weapons knowledge
Child safety	Content endangering or sexualising minors
Confabulation	Eliciting fabricated facts presented as true
Crime content	Facilitating theft, fraud, drugs or other crimes
Cybersecurity threats (beyond malware)	Hacking, intrusion, phishing, system disruption
Data privacy	Obtaining or exposing personal or confidential data
Decision-making in critical systems	Unsafe automated decisions in medical, legal, financial or safety-critical settings
Economic harm	Market manipulation, scams, financial damage
Election interference	Voter manipulation or election disinformation
Environmental harm	Pollution, ecological damage, wildlife harm
Extremism and radicalization	Promoting extremist ideology or recruitment
Hateful content	Hate speech targeting protected groups
Illegal weapons (non-CBRN)	Building or acquiring illegal conventional weapons or explosives
Intellectual property	Piracy or copyright and trademark infringement
Malware code	Writing or deploying malicious software
Misinformation	False or misleading claims presented as fact
Self-harm content	Suicide, self-injury or eating-disorder encouragement
Sexual content	Explicit or non-consensual sexual content
Violent content	Violence, threats or physical harm to others
Other	Harmful in a way not covered by the categories above
Prompt attack	Jailbreak or prompt-injection attempt when no more specific category applies

Data

Our starting point was RedBench [3], which consolidates 37 red-teaming benchmarks. We added dedicated jailbreak and prompt-injection datasets [4–11], including agent transcripts where the attack is planted in a tool response [9]. From a pool of 41,443 prompts, we evaluated a stratified sample of 1,580 (1,310 harmful, 270 benign), drawn from 14 datasets.

Models

We gave the same task, with identical instructions and the same 24-category risk taxonomy, to three hosted models: TypeSafe Jev [2], OpenAI GPT-5-mini [12] and Anthropic Claude Haiku 4.5 [13].

Results and observations

Speed, cost and quality

Jev's median latency was 0.17 seconds, against 1.00 s for GPT-5-mini and 0.89 s for Claude Haiku 4.5. That is about six times faster than GPT-5-mini and more than five times faster than Haiku. At the 95th percentile, Jev stayed at 0.26 s, while both LLMs were above 1.3 s.

Classifying all 1,580 prompts cost $0.08 with Jev, $0.48 with GPT-5-mini and $2.23 with Claude Haiku 4.5 at list prices. That makes Jev about 6× cheaper than GPT-5-mini and 27× cheaper than Haiku on the same workload.

Our measured gap is smaller than the headline figures TypeSafe published. That is expected. Their numbers describe workflows of System One tasks against their chosen baselines. Ours come from a single adversarial classification task, compared against two widely used, low-cost LLMs. The direction matches their claim; the size of the gap depends on the task and on what you compare against.

Speed and cost only matter if the decisions hold up. Across all prompts, Jev flagged harm correctly 85.5% of the time (block accuracy), against 84.1% for GPT-5-mini and 80.1% for Claude Haiku 4.5.

On naming the exact risk category out of 24 (categorization accuracy), Jev scored 58.0% against 56.0% and 55.4%.

Its macro-F1 across the 24 categories, which weights every category equally regardless of size, was 46.5% against 41.7% and 38.1%.

Detection quality

Categorization accuracy for each risk category with more than 20 labelled prompts:

Of these categories, Jev has the highest categorization accuracy in nine: crime, abusive content, misinformation, cybersecurity threats, bias, data privacy, sexual content, economic harm and decision-making in critical systems. GPT-5-mini leads on hateful content, malware, violent content and illegal weapons. Haiku is strongest at recognising benign inputs (No risk) and prompt attacks, and ties with GPT-5-mini ahead of Jev on self-harm.

Comparison with task-specific models

We also ran three open-source models built specifically for guardrailing, on a T4 GPU: Qwen3Guard-Gen-4B [14], Llama Prompt Guard 2 86M [15] and ProtectAI DeBERTa-v3 prompt-injection v2 [16]. None of them answers in the 24 risk categories, so they are compared with Jev on block accuracy only.

To compare performance across attack domains, we grouped the source benchmarks into nine benchmark groups based on the kind of prompts each contains. The groups are used only to aggregate results; they are not the labels that the models predict.

Benchmark group	What it tests	Benchmarks included
Harmful instruction and question sets	Plainly worded harmful requests and questions	AdvBench, CatQA, CoNA, ControversialInstructions, DAN, DoNotAnswer, ForbiddenQuestions, GPTFuzzer, HarmBench, HarmfulQ, HarmfulQA, JBB-Behaviors, MaliciousInstruct, MaliciousInstructions, MedSafetyBench, QHarm, SGBench, StrongREJECT (all via RedBench [3])
Cyberattack assistance	Requests for help with hacking, intrusion and malware	CyberattackAssistance (via RedBench [3])
Mixed safety suites	Broad safety suites whose prompts span many harm types	XSafety, JADE (via RedBench [3])
Jailbreak prompt collections	DAN-style, role-play and "developer mode" templates, with ordinary prompts as benign contrasts	In-the-wild jailbreak and regular prompts [4], JailbreakBench JBC [5], Salad-Data jailbreak templates [6], jailbreak-classification and ChatGPT-Jailbreak-Prompts [10], LatentJailbreak (via RedBench [3])
Automated jailbreak attacks	Attacks generated automatically (GCG, PAIR, random search, AutoDAN, GPTFuzzer, TAP)	JailbreakBench GCG, PAIR and random-search artifacts [5], Salad-Data AutoDAN, GCG, GPTFuzzer and TAP attacks [6]
Direct prompt injection sets	"Ignore previous instructions" and secret-extraction attempts, with benign contrasts	Gandalf ignore-instructions and summarization (via RedBench [3]), Lakera Gandalf [8], deepset prompt-injections [7], safe-guard-prompt-injection [10]
Indirect prompt injection (InjecAgent)	Instructions planted in tool responses to hijack an agent	InjecAgent data-stealing and direct-harm cases [9], plus clean counterparts built for this study
Toxic statements and unsafe advice	Toxic statements and prompts that invite unsafe advice	ToxiGen, SafeText, PhysicalSafetyInstructions (via RedBench [3])
Over-refusal suites	Benign prompts that sound dangerous, plus unsafe contrasts	XSTest and CoCoNot [11], OR-Bench 11, JBB-Behaviors benign set [5]

Qwen3Guard is scored on every benchmark group. Prompt Guard 2 and ProtectAI detect prompt attacks only, so they appear only in the jailbreak and prompt-injection groups they were run on in full.

Jev matches or beats every task-specific model in eight of the nine benchmark groups.

Clear leads: direct prompt injection (95%, against 88% for ProtectAI and 80% for Qwen3Guard), cyberattack assistance (83% against 67%), toxic statements and unsafe advice (49% against 38%) and indirect prompt injection (77% against 70%).
Narrow leads: harmful instructions (92% against 90%) and mixed safety suites (47% against 42%).
Level: automated jailbreaks (96% for both) and over-refusal (72% for both).
Behind: jailbreak prompt collections, where Qwen3Guard is slightly ahead (93.3% against 92.9%).

The two prompt-attack classifiers trail Jev throughout. Prompt Guard 2 is behind Jev and Qwen3Guard in every group it covers. ProtectAI beats Qwen3Guard on direct injection but not Jev. Both score 33% on indirect injection hidden in tool responses.

Two caveats apply:

Mixed safety suites and toxic statements are hard for every model, with all scores below 50%.
Indirect prompt injection remains Jev's weakest group against the hosted LLMs, which both reached 91% there.

What this means for enterprises

For most organisations, the expensive part of AI safety is not a single model call. It is making that call on every request, every agent step, and every test case in every evaluation run. A guardrail that sits in front of a production agent may run millions of times a month. An evaluation suite that re-scores thousands of cases after each prompt or model change runs constantly during development.

In those settings, the gap between a one-second LLM judgement and a sub-200-millisecond typed decision is not a rounding error. It decides whether security checks can run inline or have to be sampled, and whether evaluation runs on every change or once a week. Customers running their evaluation workloads through OptiX with Jev are already seeing reduced evaluation costs and lower latency, with performance on par with or ahead of the LLMs.

The broader lesson from this study is that decision tasks and generation tasks do not need the same model. Matching the model to the job, and measuring it on your own data, pays off quickly.

Explore OptiX

OptiX is our platform for testing, evaluating and monitoring AI systems. It brings together:

Security scans for jailbreaks, prompt injection and other adversarial inputs
Multi-agent evaluation across complex, multi-step workflows
Observability for AI systems in production
Use-case evaluation for RAG, text-to-SQL, document parsing, entity extraction, summarisation and more
Jev support, so fast, low-cost typed decisions can power guardrails and evaluations alongside LLM-based judges

To see how your own agents hold up, visit optix.cobuildx.ai and get in touch with our team.

References

Benchmark and claim

TypeSafe AI. "193.6x faster, 444.6x cheaper" launch claim. https://typesafe.ai/
TypeSafe AI. Jev model documentation. https://docs.typesafe.ai/models
Q.-A. Dang, C. Ngo, T.-S. Hy. RedBench: A Universal Dataset for Comprehensive Red Teaming of Large Language Models. arXiv:2601.03699, 2026. Dataset: https://huggingface.co/datasets/knoveleng/redbench

Jailbreak and prompt-injection datasets

X. Shen et al. "Do Anything Now": Characterizing and Evaluating In-The-Wild Jailbreak Prompts on Large Language Models. ACM CCS 2024. arXiv:2308.03825. Dataset: https://huggingface.co/datasets/TrustAIRLab/in-the-wild-jailbreak-prompts
P. Chao et al. JailbreakBench: An Open Robustness Benchmark for Jailbreaking Large Language Models. arXiv:2404.01318, 2024. Artifacts: https://github.com/JailbreakBench/artifacts
L. Li et al. SALAD-Bench: A Hierarchical and Comprehensive Safety Benchmark for Large Language Models. arXiv:2402.05044, 2024. Dataset: https://huggingface.co/datasets/OpenSafetyLab/Salad-Data
deepset. prompt-injections dataset. https://huggingface.co/datasets/deepset/prompt-injections
Lakera. gandalf_ignore_instructions dataset. https://huggingface.co/datasets/Lakera/gandalf_ignore_instructions
Q. Zhan et al. InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents. arXiv:2403.02691, 2024. https://github.com/uiuc-kang-lab/InjecAgent
Community datasets on Hugging Face: jackhhao/jailbreak-classification, xTRam1/safe-guard-prompt-injection, rubend18/ChatGPT-Jailbreak-Prompts.
Over-refusal benchmarks: P. Röttger et al. XSTest: A Test Suite for Identifying Exaggerated Safety Behaviours in Large Language Models. arXiv:2308.01263, 2023; F. Brahman et al. The Art of Saying No: Contextual Noncompliance in Language Models (CoCoNot). arXiv:2407.12043, 2024; J. Cui et al. OR-Bench: An Over-Refusal Benchmark for Large Language Models. arXiv:2405.20947, 2024.

Models

OpenAI. GPT-5-mini. https://platform.openai.com/docs/models
Anthropic. Claude Haiku 4.5. https://docs.anthropic.com/en/docs/about-claude/models
H. Zhao et al. Qwen3Guard Technical Report. arXiv:2510.14276, 2025.
S. Chennabasappa et al. LlamaFirewall: An Open Source Guardrail System for Building Secure AI Agents (Llama Prompt Guard 2). arXiv:2505.03574, 2025.
ProtectAI. deberta-v3-base-prompt-injection-v2. https://huggingface.co/protectai/deberta-v3-base-prompt-injection-v2

Originally published on the CobuildX blog.

Collections AI: The Compliance Constraint That Shapes Everything

Emmanuel R — Thu, 08 Oct 2026 11:02:25 +0000

AI can meaningfully improve collections performance within the regulatory framework — propensity scoring, channel optimisation, timing models. What it cannot do is automate the things TCPA, FDCPA, and state-level consumer protection laws prohibit. Here is what the boundary looks like.

Collections is one of the highest-value AI applications in financial services by the numbers — small improvements in recovery rates on large portfolios compound quickly. It is also one of the most heavily regulated operational functions at any lender. TCPA, FDCPA, state-level consumer protection laws, and the CFPB's interpretive guidance on unfair, deceptive, or abusive acts and practices all constrain what an AI-driven collections operation can do. The practical question is not whether to apply AI in collections — the ROI case is clear — but what AI can do within the constraint set.

Collections AI projects fail in two ways. The first: the team builds a sophisticated propensity or segmentation model but does not integrate it into collections workflows in a way that changes collector behaviour. The model exists; nothing changes. The second: the team deploys automated outreach capabilities without adequately scoping the regulatory framework, and the compliance review catches problems that require significant redesign.

Key insight: TCPA and FDCPA do not prevent AI from improving collections — they define the boundaries within which AI can operate. Designing to those boundaries from the start produces a system that is both effective and defensible.

"We built the model. Then compliance reviewed the outreach automation we had planned and we had to redesign half of it."

What TCPA Actually Constrains

The Telephone Consumer Protection Act (TCPA) restricts the use of automatic telephone dialling systems (ATDS) and artificial or prerecorded voice messages to contact consumers without their prior express written consent. In a collections context, this constrains automated outreach — AI-driven diallers, automated SMS campaigns, and prerecorded voice messages — significantly.

Prior express written consent is required for autodialled calls or texts to mobile phones. For debt collection, this consent must be obtained at the time the credit relationship is established or through a subsequent consent process. Consent obtained at origination covers most account holders for initial collection contact, but consumers can revoke consent at any time, and revocations must be honoured immediately — a process that needs to be automated and audited.

The TCPA does not prohibit human-initiated calls using manual dialling. Collections operations can use predictive diallers in a compliant way if the dialler does not meet the ATDS definition — an increasingly nuanced technical and legal question after the Facebook v. Duguid Supreme Court decision in 2021. Any collections AI involving automated outreach should be reviewed by counsel with TCPA expertise before deployment.

TCPA constrains automated outreach to mobile phones without consent — the consent management process is as important to design as the outreach automation itself

FDCPA: What You Can Say and When

The Fair Debt Collection Practices Act (FDCPA) governs third-party debt collectors and imposes specific requirements on the timing, content, and frequency of collection communications. The CFPB's Regulation F, which took effect in 2021, extended some FDCPA principles and added specific guidance on electronic communications including email and text.

Key constraints with direct implications for AI-driven collections:

Contact frequency limits: Regulation F creates a presumption that contacting a consumer more than seven times in a seven-day period, or within seven days of a prior telephone conversation, violates the FDCPA. AI-driven outreach optimisation needs to track and enforce these limits across all communication channels.

Time-of-day restrictions: calls are permitted only between 8am and 9pm in the consumer's local time zone. An AI scheduling model optimising for contact rates needs to incorporate this constraint — and needs to use the consumer's time zone, not the operations centre's.

Cease and desist: if a consumer requests that contact cease, all communication must stop except to confirm receipt of the cease notice or to advise of specific legal action. This revocation process needs to be immediate and auditable.

Seven-in-seven contact frequency limits, time-of-day restrictions, and immediate cease-and-desist compliance are non-negotiable constraints that AI outreach must enforce

What AI Can Do Within These Constraints

Within the regulatory framework, AI delivers meaningful collections improvement through three specific applications.

Propensity to pay modelling. A model that predicts which accounts are most likely to pay in response to outreach — and under what conditions (settlement offer, payment plan, specific timing) — allows collections operations to prioritise contacts more effectively than simple days-past-due segmentation. Accounts with high propensity to pay at full balance get early personal contact; accounts that respond to settlement offers get offers earlier in the delinquency cycle when recovery is higher.

Channel preference optimisation. Different consumers respond to different channels. Some respond to text, some to email, some to phone calls. A model trained on historical contact data can predict which channel is most likely to produce a response for a given consumer profile, reducing contact attempts while improving contact rates.

Timing optimisation. Within the time-of-day constraints and the contact frequency limits, there is still meaningful variation in when a consumer is most likely to answer or respond. ML models trained on response rates by day of week and time of day — by consumer segment — can improve contact rates without increasing total contact attempts.

Propensity to pay modelling, channel preference, and timing optimisation deliver collections lift within the regulatory framework — together, improvements of 10–20% in recovery rates on targeted portfolios are realistic

State-Level Overlay

Federal TCPA and FDCPA requirements are the floor. A significant number of states have consumer protection laws that are more restrictive, and compliance at the federal level does not mean compliance in every state where borrowers are located.

California's Rosenthal Fair Debt Collection Practices Act applies FDCPA-equivalent requirements to first-party collectors (lenders collecting their own debt) in addition to third-party collectors — a broader scope than federal law. New York and other states have similar first-party coverage extensions.

Several states have more restrictive contact frequency rules than Regulation F, shorter time windows for permissible calling hours, or additional disclosure requirements for automated communications.

For a lender with a national portfolio, the compliance standard is the most restrictive applicable state law for each consumer, not the most permissive interpretation of federal law. A collections AI system with national scope needs to implement state-level rule variations or operate to the most conservative standard across the full portfolio.

State-level consumer protection laws can be more restrictive than federal TCPA and FDCPA — compliance requires the most restrictive applicable standard for each consumer's state

Building the Business Case Within the Constraints

The ROI case for collections AI is real within these constraints. The constraint set limits automated outreach, but it does not limit propensity scoring, segmentation, channel optimisation, or timing models — all of which improve outcomes without requiring automation of contact initiation.

Realistic targets for a well-scoped collections AI program: 10–20% improvement in early-stage recovery rates through better prioritisation and channel selection on accounts where propensity to pay is high. 15–25% reduction in average collection cost per recovered dollar through more efficient contact allocation. Measurable reduction in complaints from improved compliance with contact frequency and timing rules.

The compliance investment — consent management, revocation tracking, state-level rule implementation, audit logging — is not small. It is also not optional, and treating it as overhead rather than part of the system design leads to the pattern of building first and redesigning after compliance review. The right approach: scope the compliance infrastructure at the start, design the AI system to operate within it, and build the business case on what is achievable within that framework.

10–20% early-stage recovery improvement and 15–25% cost reduction per recovered dollar are achievable within the regulatory framework — scope the compliance infrastructure at the start, not after

Originally published on the CobuildX blog.

Credit Risk Scoring: The Data Problems That Haven't Changed

Emmanuel R — Thu, 08 Oct 2026 11:01:49 +0000

Better models have not solved the thin-file problem, the data quality issues in alternative data, or the validation requirements that govern what can be deployed in regulated lending. The data problems are still the hard part.

Credit risk modelling has changed significantly over the past decade. Gradient boosting has replaced logistic regression as the standard approach at most sophisticated lenders. Alternative data — cash flow data, rental payment history, utility payments — has broadened the credit-visible population. Explainability tooling has made complex models more deployable in regulated environments. What has not changed: the data quality problems that determine whether any model, regardless of sophistication, produces reliable predictions.

The limiting factor in credit risk modelling is not model architecture. Given reasonable data, a well-tuned gradient boosting model and a well-tuned logistic regression produce different but both useful predictions. The limiting factors are: the thin-file problem (a significant fraction of credit-worthy borrowers have insufficient traditional credit history to model reliably), the alternative data quality problem (much of the data that could address thin-file has its own reliability and coverage gaps), and the model validation requirements that govern what can be deployed.

Key insight: Lenders who have improved credit risk modelling in recent years have done so primarily through better data — specifically cash flow data and expanded credit bureau data — not better model architectures. The model is less important than the signal.

"We spent six months building a more sophisticated model. When we went back and cleaned the training data, the simple model performed just as well."

The Thin-File Problem

Approximately 45 million Americans have thin or no credit files — too little traditional credit history for the major bureaus to generate a reliable score. This population is not uniformly high risk. It includes recent immigrants with strong financial management histories in their home countries, young adults who have avoided debt but have stable income, and individuals who have historically used cash and community lending. A lender that cannot score them declines credit-worthy borrowers and cedes that business to competitors who can.

Traditional bureau data does not solve the thin-file problem because the thin-file is definitionally not in the bureau data. Expanding the modelling approach requires either incorporating non-traditional data sources (rental payments, utility payments, cash flow data) or accepting that a segment of the credit-worthy population will not be scoreable through traditional approaches.

45 million Americans are not scoreable through traditional bureau data — addressing the thin-file problem requires non-traditional data sources, not better models on the same data

Alternative Data: What Works and What Does Not

Cash flow data — transaction-level bank account data showing income deposits, recurring payments, and spending patterns — is the most consistently useful alternative data source for credit risk in consumer lending. It is highly predictive of ability to pay, has reasonable coverage through open banking integrations, and is relatively clean compared to other alternative data sources. Cash flow features (income consistency, average balance, payment-to-income ratios) add meaningful lift for thin-file borrowers on top of bureau data.

Rent payment history, when available and reliably reported, is also useful — a demonstrated track record of on-time rent payments is predictive of future credit performance. The coverage problem is significant: most rent payments are not reported to any bureau, and the coverage of rent payment data from alternative providers is incomplete and variable by geography.

Data sources that have shown less consistent value: social media signals, education and employment data from non-traditional sources, and 'character' signals derived from digital behaviour. These data types often introduce fair lending risk (proxies for protected characteristics appear in unexpected places) without delivering equivalent predictive lift. Several lenders have retreated from these approaches after fair lending testing revealed disparate impact.

Cash flow data is the most consistently predictive alternative data source. Character and digital behaviour signals introduce fair lending risk without reliable predictive lift

The Recency Problem

Credit risk models trained on pre-2020 data reflect credit behaviour in a low-interest-rate, low-unemployment economic environment. Models trained primarily on 2020–2022 data reflect an unprecedented economic disruption period with stimulus payments, forbearance programs, and unusual payment behaviour. Neither training period is a reliable guide to current credit risk in a normalising interest rate environment.

The practical implication: models trained on data more than two to three years old should be retested against recent performance data before being treated as reliable. Performance metrics that looked stable during model development may have degraded significantly as the economic environment shifted.

This is not a new problem — economic cycle sensitivity in credit models has been understood for decades. It became more acute after 2020 because the economic disruption was severe enough to make pre-crisis training data significantly less predictive of post-crisis behaviour. Lenders whose models date from 2018 or earlier and have not been recalibrated against post-2022 performance data are running on models whose accuracy may be materially worse than their validation metrics suggest.

Models trained on pre-2020 data should be retested against recent performance data — the economic environment shift has degraded accuracy in ways validation metrics from that period do not reflect

Model Validation in a Regulated Environment

For banks and supervised lenders, credit risk models are subject to model risk management requirements under SR 11-7. The validation requirement is not just that the model performs well by internal metrics — it is that the model has been independently validated, the validation covers conceptual soundness and outcome analysis, limitations are documented, and ongoing monitoring is in place.

For the models with the most regulatory scrutiny — models used in underwriting decisions for consumer credit at scale — the validation needs to cover fair lending analysis as a standard component. A model that validates well on predictive performance metrics but has not been tested for disparate impact is not ready for production at a regulated lender.

The practical implication for AI/ML models: more complex models require more documentation and a more sophisticated validation function. The validation team needs to understand the feature engineering, the training data, the hyperparameter selection rationale, and the limitations of the model well enough to write a challenge that addresses each. This is achievable but it requires planning — presenting a finished ML model to model risk management without having engaged them in the development process is a common reason for long validation timelines.

Engaging model risk management during development, not at the end of it, is the single most effective way to avoid long validation delays

Originally published on the CobuildX blog.