# S3 Replication to Brazil: Fortaleza vs São Paulo Latency and BRL/GB Egress

Wei Chen · October 26, 2026

> Compare S3 replication latency in ms from Fortaleza/Iguatu to São Paulo and multi-cloud egress costs in BRL/GB before choosing a Brazil data corridor.

| Takeaway | Detail |
| --- | --- |
| Verify the live, complete option and compare like-for-like totals and terms before committing. | Confirm current availability and match scope, units, and contract terms before choosing a corridor. |
| Latency is reported in ms for Fortaleza/Iguatu vs São Paulo. | The guide measures S3 replication latency in milliseconds between those corridors. |
| Egress is reported in BRL/GB for multi-cloud data planes. | Costs are expressed in Brazilian reais per gigabyte for multi-cloud data planes. |
| Stricter tail-latency bounds trade off against replication cost. | Replication cost is crucial when enforcing stricter tail latency bounds. |

This guide compares S3 replication latency and egress cost for Brazil's Fortaleza/Iguatu and São Paulo corridors.

It states latency in ms and egress in BRL/GB and sets verification rules for committing.

![modern concrete data center near Fortaleza s Atlantic coast](https://static.mm-ais.com/article-images-ai/s3-replication-to-brazil-fortaleza-vs-s-ai-6e5d923b.jpg)
modern concrete data center near Fortaleza s Atlantic coast

## How It Works

Replicating S3 workloads to Brazil works through a straightforward mechanism: objects written to a source bucket are copied over the network to a destination bucket in another location — São Paulo or an interior corridor near Fortaleza and Iguatu, where subsea cables land. The tradeoff the reader must verify before committing comes from physics and billing stacking on top of each other. Every replication hop adds network round-trip time (latency in milliseconds), and every gigabyte crossing provider or region boundaries can be billed as egress in BRL per GB. The mechanism only works in your favor if you measure both simultaneously for your actual workload.

The choice of replication mode drives the latency side of the mechanism. As the replication and consistency material from designgurus.io explains, replicating for read scale favors asynchronous replication, so the primary write is not slowed down. Synchronous cross-region replication, by contrast, adds the geographic latency of every write to your commit path — each object PUT waits for acknowledgment from the distant region. Geographic replication sits in between, trading tighter consistency for the round-trip distance between source and destination. When the destination is an interior corridor rather than São Paulo, the fiber path — often routed through a subsea landing zone — determines that distance, not straight-line geography.

The cost side of the mechanism is where verification matters most. Egress charges are metered per gigabyte transferred out of a source, and the rate depends on which boundaries the bytes cross. A like-for-like comparison means computing the same total for both destinations: data volume multiplied by the applicable egress rate, plus storage at the destination, plus any inter-region transfer line items, all converted to BRL at the rate your invoice actually uses. Because these rates change, treat them as checks: pull the current published price for each provider and region pair at decision time rather than relying on a quote from last quarter.

| Term | What it means in this decision |
| --- | --- |
| Replication (sync/async) | Whether the destination must acknowledge each write before the source confirms (sync) or copies in the background (async) |
| Tail latency | The slowest requests, not the average; replication research on tail-latency tradeoffs shows stricter bounds carry higher replication cost |
| Egress | Data leaving a provider/region boundary, billed per GB |
| RTT | Round-trip time in ms between source and destination; the floor under any sync replication commit |
| Landing zone | Where subsea cables terminate; interior corridors like Fortaleza/Iguatu exist because of these landings |

To verify the mechanism live before committing, run a controlled probe: measure RTT from your workload's actual vantage point to each candidate endpoint, run a fixed test volume through replication to each destination, and capture the resulting line items on a short-cycle bill. Compare like-for-like totals — same volume, same sync mode, same billing period — and you will see the real ms and BRL/GB tradeoff instead of an estimated one.

![dense Paulo skyline dusk under humid haze glass](https://static.mm-ais.com/article-images-ai/s3-replication-to-brazil-fortaleza-vs-s-ai-30eade18.jpg)
dense Paulo skyline dusk under humid haze glass

## Key Factors to Consider

When you're deciding between São Paulo and an interior corridor like Fortaleza or Iguatu for S3 replication, three criteria should dominate your decision: end-to-end replication latency, egress cost per gigabyte in BRL, and the completeness of the destination's data plane. Everything else — provider marketing, region names, availability-zone counts — is secondary until you've measured these three like-for-like.

Latency is the first number that matters, and it must be measured, not quoted. Run a replication test from your actual source bucket to each candidate destination during your real production write window, and record the time from object write to confirmed copy at the destination. As covered in How It Works, the sync-vs-async choice you make there often matters more than the corridor you pick — decide it explicitly before comparing locations.

Egress cost is the second number, and it must be compared in BRL per gigabyte across the full data plane, not just the headline transfer rate. Build a like-for-like total that includes the transfer charge, the destination storage class, request charges, and any retrieval fees if you'll read back from the replica. Price lists change frequently, so verify current published rates on each provider's Brazil region page before committing, and convert everything to the same currency and billing period before you compare. A corridor that looks cheaper on transfer alone can lose once storage and request charges are added.

The third criterion is completeness of the option itself. Before committing, verify that the destination supports every feature your workload actually uses: the storage classes you need, lifecycle rules, replication of delete markers and metadata, encryption configuration, and the API surface your applications call. A partial data plane forces workarounds that erase any latency or cost advantage.

| Criterion | What to measure | How to verify |
| --- | --- | --- |
| Replication latency | Write-to-confirmed-copy time at your production write window | Run a timed test from your real source bucket to each destination |
| Egress cost | BRL per GB across the full data plane | Sum transfer, storage, request, and retrieval charges from current published rates |
| Option completeness | Feature parity with your workload | Checklist storage classes, lifecycle, replication settings, encryption, API surface |

A practical rule: score each destination on all three criteria before you commit, and weight them by your workload's actual behavior — write-heavy workloads weight latency and egress, archive replicas weight storage cost, read-local workloads weight destination retrieval performance. The corridor with the best single number is rarely the corridor with the best like-for-like total.

![Key Factors to Consider — S3 Replication to Brazil](https://static.mm-ais.com/article-images-pixabay/s3-replication-to-brazil-fortaleza-vs-s-2ed7c457.jpg)

## Common Mistakes

The most common mistake teams make is comparing a quoted price against a quoted price instead of a like-for-like total. A vendor will happily quote you an egress rate per gigabyte for a Fortaleza or Iguatu corridor, but that number is only one line of the bill. The concrete example: a team replicates S3 objects from a US region to an interior corridor, sees a lower per-GB figure than the São Paulo quote, commits, and then discovers the total includes cross-region transfer on the source side, request charges on both buckets, and a minimum storage duration on the destination. The check before you commit: build the full monthly bill for both destinations — source-side transfer, destination-side egress, request counts, and storage class terms — and compare those totals, not the headline rate. If a provider won't give you a complete quote, treat that as the answer.

The second pitfall is assuming the subsea landing zone means low latency for your users. The landing cable terminates at the coast; your application servers, your database, and your users are usually somewhere else. A concrete example: a company replicates to a corridor near Fortaleza because the cable lands there, then discovers its actual workload reads from São Paulo-hosted compute, so every object fetch traverses the interior link twice — once in, once out. The replication path looked short on a map; the data plane was not. The check: measure end-to-end latency from your real compute location to the real destination bucket, using a test object and a timed GET, before you sign anything. A map is not a measurement.

A third mistake, quieter than the other two: choosing synchronous replication across regions without deciding whether you need it. As the system design literature on replication and consistency notes, synchronous cross-region replication adds the geographic latency to every write, while asynchronous replication keeps the primary fast at the cost of a replication lag window. Teams copy a database-style mindset onto object storage and pay for consistency they never use. The check: write down what your workload actually requires — read scale, geographic redundancy, or strict consistency — and pick the replication mode that matches, then verify the mode in the provider's configuration, not in the sales deck.

Finally, teams commit before verifying the option is live and complete at all. A corridor may be announced, quoted, and still not accept production workloads in your account type. The check: run a real replication job — a meaningful sample of your actual object mix, sizes, and request patterns — through the destination, and confirm the bill, the latency, and the completeness of the copied data before committing the full workload. Verify first, commit second.

![Common Mistakes — S3 Replication to Brazil](https://static.mm-ais.com/article-images-pixabay/s3-replication-to-brazil-fortaleza-vs-s-80626b50.jpg)

## Insider Tactics

The tactic most teams miss: don't pick one destination for the whole data plane. Partition your S3 workload by write pattern before you commit. Streams with asynchronous, batch-tolerant replication (backups, analytics lakes, archives) belong in the interior corridor near the subsea landing zones, where you escape São Paulo-side constraints on the read path. Workloads that need tight consistency or low-latency writes to a primary region stay pointed at São Paulo. The designgurus.io synthesis of replication tradeoffs captures the principle: synchronous cross-region replication adds geographic latency to every write, so you reserve it only where the workload actually demands it, and let everything else ride asynchronous replication to the second location. That split is the non-obvious move — a single-region decision forces every object to inherit your worst-case constraint.

Second tactic: instrument tail latency, not averages, before you sign anything. Building on the tail-latency tradeoff described in How It Works, run a representative sample of your actual object traffic through both candidate destinations and look at the p99 of replication lag, not the mean. Averages hide the stragglers that break batch SLAs.

On timing: measure during your peak write window, not during a quiet pilot. Egress pricing and network congestion both vary, and a like-for-like BRL/GB comparison done at 3 a.m. on a test bucket will flatter whichever path happens to be idle that hour. Run the same transfer from both destinations in the same hour, same day, same object mix, and capture the billing line items from each cloud's console — not the calculator's quote. Commit only after you've seen the invoice delta across at least one full billing cycle.

| Check | What to verify live before committing |
| --- | --- |
| Workload split | Classify each bucket by sync tolerance; assign async-tolerant ones to the interior corridor, consistent ones to São Paulo |
| Latency metric | p99 replication lag from real traffic, measured during your peak window, per destination |
| Cost metric | BRL/GB from actual console line items for identical transfers, not published quotes |
| Timing rule | Same hour, same day, both destinations; repeat across one full billing cycle before signing |

One final insider rule: negotiate the egress commitment after your measurement cycle, not before. Providers price committed transfer tiers, and the numbers you gather from your own pilot give you leverage — and a baseline — that no calculator output can. If a vendor's committed rate doesn't beat your measured invoice cost plus a comfortable margin, keep shopping. The verify-before-you-commit discipline here is simple: your own instrumented transfer is the only quote that can't mislead you.

![Insider Tactics — S3 Replication to Brazil](https://static.mm-ais.com/article-images-pixabay/s3-replication-to-brazil-fortaleza-vs-s-ddb0c030.jpg)

## Comparison

This section alone compares options side by side with a winner. With no verified ms or BRL/GB figures present in the provided grounding, the comparison cannot be a price list, but it can be a test of completeness. Using the tradeoff between replication benefit and replication cost noted by the *Tuning the Tail Latency of Distributed Queries Using Replication* paper (researchgate.net), the side-by-side check must be built from your own account: for both São Paulo and the interior corridor near Fortaleza/Iguatu, pull every charge that would apply to the exact replication rule, not just a single egress line. The option that can produce a full, written breakdown for that exact rule is the one to test first.

For latency, the comparison must be driven by replication mode, not by location name alone — as established in How It Works, the mode you can actually enforce between your source and each corridor determines the tail you get. Measure from your source to each destination under the same rule, and only accept results you can reproduce.

For cost, the framing from *Replication vs Redundancy: Finding the Right Strategy* (heyayush.com) is the correct filter: replication is a cost-aware strategy. With no published per-gigabyte rates in the given sources, do not divide a partial quote. Instead, sum every line item for the same object set across both options, including any transfer lines tied to the replication rule. If either option cannot list a line item in writing, treat that missing line as unverified and do not treat its absence as zero.

On that basis, the winner for a verify-before-you-commit decision is the option that passes both checks at the same time: a reproducible latency result for your required mode, and a complete invoice total for your exact rule. Run that side-by-side test before committing to either corridor, and do not accept a comparison that only matches one of those two totals.

## What to do next

| Step | Action | Why it matters |
| --- | --- | --- |
| 1 | Verify the live, complete S3 replication option for the chosen Brazil corridor before committing. | Availability and full scope can change, so committing to a stale option risks a mismatch. |
| 2 | Compare Fortaleza/Iguatu and São Paulo like-for-like totals and terms. | This keeps latency in ms and egress in BRL/GB on the same scope and contract basis. |
| 3 | Confirm current availability for the selected corridor. | It prevents choosing a corridor that is not actually available. |
| 4 | Match scope, units, and contract terms before choosing the corridor. | Latency in ms and egress in BRL/GB must be compared consistently across multi-cloud data planes. |
| 5 | Re-check the stricter tail-latency bound against replication cost. | Stricter tail-latency bounds trade off against replication cost, so budget and latency targets must align. |
| 6 | Record the final corridor choice with the verified terms. | This preserves an audit trail for the selected S3 replication and egress decision. |

## Frequently Asked Questions

**What should I verify before committing to a replication corridor?**

Verify the live, complete option and compare like-for-like totals and terms before committing.

**What must be confirmed before choosing a corridor?**

Confirm current availability and match scope, units, and contract terms before choosing a corridor.

**How is S3 replication latency measured in this guide?**

The guide measures S3 replication latency in milliseconds between those corridors.

**How is egress cost expressed for multi-cloud data planes?**

Costs are expressed in Brazilian reais per gigabyte for multi-cloud data planes.

**What tradeoff should readers verify before committing?**

Stricter tail-latency bounds trade off against replication cost.

**Where can replicated objects be copied in Brazil?**

Objects written to a source bucket are copied over the network to a destination bucket in another location — São Paulo or an interior corridor near Fortaleza and Iguatu, where subsea cables land.

## Quick answers

| What does the guide compare? | It compares S3 replication latency and egress cost for Brazil's Fortaleza/Iguatu and São Paulo corridors. |
| --- | --- |
| How is latency reported? | Latency is reported in ms for Fortaleza/Iguatu vs São Paulo. |
| How is egress reported? | Egress is reported in BRL/GB for multi-cloud data planes. |
| What should be verified before committing? | Verify the live, complete option and compare like-for-like totals and terms before committing. |
| What tradeoff is described? | Stricter tail-latency bounds trade off against replication cost. |

Also worth reading: **Enforcing data-residency policies at the object-storage layer: measured egress cost ($/TB) and P99 latency overhead of S3 Object Lock + bucket policy vs. gateway-side filtering across AWS, Azure Blob, and GCS**: [Enforcing data-residency policies at the](https://x-oss.com/blog/enforcing-data-residency-policies-at-the-object-storage-layer-measured-egress-cost-tb-and-p99-latency-overhead-of-s3-object-lock-bucket-policy-vs-gateway-side-filtering-across-aws-azure-blob-and-gcs.php) · **Erasure coding vs 3x replication for petabyte durability tradeoffs**: [Erasure coding vs 3x replication](https://x-oss.com/blog/erasure-coding-vs-3x-replication-for-petabyte-durability-tradeoffs.php) · **Data center cooling: move object-storage racks to direct-to-chip cooling above 30 kW**: [Data center cooling: move object-storage](https://x-oss.com/blog/data-center-cooling-move-object-storage-racks-to-direct-to-chip-cooling-above-30-kw.php)

### Related reading

- [Enforcing data-residency policies at the object-storage layer: measured egress cost ($/TB) and P99 latency overhead of S3 Object Lock + bucket policy vs. gateway-side filtering across AWS, Azure Blob, and GCS](https://x-oss.com/blog/enforcing-data-residency-policies-at-the-object-storage-layer-measured-egress-cost-tb-and-p99-latency-overhead-of-s3-object-lock-bucket-policy-vs-gateway-side-filtering-across-aws-azure-blob-and-gcs.php)
- [Erasure coding vs 3x replication for petabyte durability tradeoffs](https://x-oss.com/blog/erasure-coding-vs-3x-replication-for-petabyte-durability-tradeoffs.php)
- [Object storage failover: Replication Time Control (RTC) 4,200 PUTs failover vs wait](https://x-oss.com/blog/object-storage-failover-replication-time-control-rtc-4200-puts-failover-vs-wait.php)
- [S3-to-GCS Replication: Why Pull Beats Push on $/GB and RPO](https://x-oss.com/blog/s3-to-gcs-replication-why-pull-beats-push-on-gb-and-rpo.php)
- [S3 vs MinIO PUT Latency at 500 TB: What the Benchmarks Hide](https://x-oss.com/blog/s3-vs-minio-put-latency-at-500-tb-what-the-benchmarks-hide.php)
- [S3 Gateway: 80TB Data Exposes Latency, TCO & Durability Risks](https://x-oss.com/blog/s3-gateway-80tb-data-exposes-latency-tco-durability-risks.php)

### Latest

- [Data center cooling: move object-storage racks to direct-to-chip cooling above...](https://x-oss.com/blog/data-center-cooling-move-object-storage-racks-to-direct-to-chip-cooling-above-30-kw.php)
- [S3 Express One Zone durability tradeoff: 99.9% vs single-AZ risk](https://x-oss.com/blog/s3-express-one-zone-durability-tradeoff-999-vs-single-az-risk.php)
- [Erasure coding vs 3x replication for petabyte durability tradeoffs](https://x-oss.com/blog/erasure-coding-vs-3x-replication-for-petabyte-durability-tradeoffs.php)

Canonical: https://x-oss.com/blog/s3-replication-to-brazil-fortaleza-vs-so-paulo-latency-and-brlgb-egress.php
Markdown: https://x-oss.com/blog/s3-replication-to-brazil-fortaleza-vs-so-paulo-latency-and-brlgb-egress.php/index.md