DynamoDB Global Tables: How They Work, Pricing With Examples, MREC vs MRSC, Setup in the Console, CLI and Terraform, and the New Disassociate Replica Option

DynamoDB global tables keep a copy of one DynamoDB table in several AWS Regions and replicate every write between them, so your application can read and write locally in each Region and keep running if one Region has a bad day. You make one by adding a replica to an existing table: in the console, open the table, choose Global tables, then Create replica; with the CLI, aws dynamodb update-table --replica-updates '[{"Create":{"RegionName":"us-east-1"}}]'. Pricing: every write is billed once in every Region as a replicated write unit, at the same price as a normal write ($0.625 per million on demand in US East), each replica stores a full copy, and adding a replica is billed as a table restore ($0.15 per GB in US East). Replication traffic between Regions itself is not billed. New since October 20, 2026: you can disassociate a replica, so a Region leaves the global table and keeps its table and data. The catch nobody expects: in a two-Region global table, disassociating one replica turns both tables into ordinary single-Region tables, and it cannot be undone.

Jake's shop started shipping to Ireland in the spring, and Irish customers complained that the order page felt slow. Ethan added an Ireland replica to the orders table on a Tuesday afternoon; it took twenty minutes and no code changes. Six months later the Irish warehouse closed, and Jake asked the reasonable question: "Can we stop copying everything to Ireland but keep the Irish order history for the accountant?" Until this week, the honest answer was "not without copying it somewhere first".

This guide explains what DynamoDB global tables are and how they work, the two consistency modes, what they really cost with worked examples, how to create one with the console, the CLI, Terraform and CloudFormation, the new disassociate option, and the behaviors and errors that surprise people in production. If DynamoDB itself is new to you, what Amazon DynamoDB is covers tables, keys and capacity first.

What a DynamoDB global table is, and how it works

A global table is a set of DynamoDB tables, called replicas, in different AWS Regions. All replicas share the same table name, the same primary key, and the same items. Your application talks to the replica in its own Region with the normal DynamoDB API, and DynamoDB copies each write to every other replica automatically. There is one replica per Region at most, and a global table has two or more of them.

Three things make global tables worth their price:

• Local speed everywhere. A customer in Dublin reads and writes the Ireland replica instead of crossing the Atlantic to Ohio. That was Jake's reason.
• Multi-active. Every replica accepts writes. There is no "primary" to promote during an outage; you move traffic to another Region and keep writing.
• Higher availability. Global tables carry a 99.999 percent availability SLA, against 99.99 percent for a single-Region table.

A replica is a full DynamoDB table in its own right: same durability as any table, its own capacity, its own metrics. There are two versions of the feature. Version 2019.11.21 is the current one and everything in this guide refers to it. Version 2017.11.29 is legacy; if describe-table shows "GlobalTableVersion": "2019.11.21", you are on the current version, and if it does not, check whether the table is a legacy global table and plan an upgrade. In Terraform, the separate aws_dynamodb_global_table resource is the legacy version; current global tables use replica blocks on aws_dynamodb_table.

Global tables also come in two ownership models. Same-account global tables keep every replica in one AWS account. Multi-account global tables put each replica in a different account, for isolation between business units or for separate security controls, with each replica billed to its own account. Multi-account global tables support only the eventually consistent mode described next.

MREC vs MRSC: the two consistency modes

When you create a global table you choose how replication behaves, and you cannot change it afterwards.

Multi-Region eventual consistency (MREC) is the default. A write is confirmed in the Region where it happened and copied to the other replicas asynchronously, typically within a second or less. If the same item is changed in two Regions at nearly the same moment, DynamoDB keeps the change with the latest internal timestamp, item by item: last writer wins. A strongly consistent read returns the latest version only if the item was last written in that same Region; an item last written elsewhere can be briefly stale. Conditional writes check the condition against the local copy.

Multi-Region strong consistency (MRSC) replicates each write synchronously to at least one other Region before the write succeeds. A strongly consistent read on any replica always returns the latest version, and conditional writes always check the latest version. The price is latency (every write waits for another Region) and a stricter shape:

A witness is MRSC's cheaper third member. It holds the replicated change data needed for MRSC's availability design, but you cannot read from or write to it, and it adds no replicated write, storage or replication transfer charges. Two replicas and a witness is the usual MRSC layout when you only need to serve traffic from two Regions.

Which to choose? For most applications, including Jake's shop, MREC: it is the default, it works with existing data, transactions, TTL and multiple accounts, and "last writer wins" is fine when each customer's data is mostly written in one Region. Choose MRSC when two Regions must never disagree, even for a second: account balances, inventory that can be sold from either side, anything where a lost concurrent update is a real problem. And test the write latency in your three Regions first, because each write waits for a cross-Region round trip.

Global table vs global secondary index (they are unrelated)

The word "global" means two different things in DynamoDB, and searches mix them up constantly. A global table copies a whole table across Regions. A global secondary index (GSI) is an index inside one table that lets you query by a different key, "global" because it spans all of the table's partitions. A local secondary index (LSI) shares the table's partition key and must be created with the table.

They do meet in one place: a GSI on a global table exists in every Region. Create a GSI on one replica and DynamoDB creates it on all of them, and every Region pays for the index writes. That is part of the pricing below.

Global table vs single-Region table

Searches for "global tables vs local tables" usually mean this: what changes when an ordinary (single-Region) table becomes global? Less than people fear, and mostly in the bill:

The last row is the pleasant surprise: the API is the same. The application chooses which Region's endpoint to call (usually the nearest one, and another one during an outage), and everything else, including keys, queries and indexes, works as before.

DynamoDB global tables pricing, with examples

Global tables have no fee of their own. You pay for the same things as any DynamoDB table, but several of them now happen once per Region. Prices below are on-demand, US East (N. Virginia), from the AWS price list for October 2026; other Regions differ slightly.

On provisioned capacity the same idea applies with replicated write capacity units (rWCU) at $0.00065 per hour, provisioned in every Region, and replication itself consumes that write capacity, so a busy replica can throttle if you size it for local writes only. Two warnings about older articles: replicated writes used to cost more than normal writes, but on-demand replicated writes were cut by 67 percent in November 2024 and are now the same price; and some guides still list cross-Region transfer charges for replication, but DynamoDB no longer charges cross-Region data transfer for global table replication.

Worked example: Jake's orders table. 10 million writes a month, items under 1 KB, 30 million reads, 40 GB of data, one GSI on order status.

(Storage ignores the free tier to keep the comparison simple.) The pattern is the useful part: writes, index writes and storage scale with the number of Regions; reads do not, because each read happens in one Region only. A read-heavy table becomes global cheaply; a write-heavy table with several GSIs gets expensive fast. Time to Live deletes follow the same rule: the delete is free in the Region where TTL removes the item, but the replicated delete is billed in every other Region. On-demand vs provisioned shows when switching capacity mode cuts the bill further.

Jake looked at the three columns and asked whether Ireland was worth $22.50 a month. Ethan's answer was a screenshot of the order page loading in a second instead of three, and the Irish conversion rate next to it.

How to create a DynamoDB global table (console and CLI)

You do not create a global table directly: you create an ordinary table, then add replicas to it. Before you start, check that the table's throughput quotas are the same in every target Region; replica creation fails if, for example, the source table's maximum read capacity exceeds the destination Region's table quota. In the console:

1. Open the table in the DynamoDB console, in its current Region.
2. Choose the Global tables tab, then Create replica.
3. Pick the Region. For MRSC, choose the strong consistency option when you add the first replicas to an empty table, and pick the third Region for a replica or a witness.
4. Choose Create replica. The table status changes to UPDATING; existing items are copied to the new Region (the restore charge), and the replica turns ACTIVE when it is ready. Your application keeps working on the source table throughout.
5. Repeat for more Regions, one at a time: only one replica operation can run on a global table at once.

With the AWS CLI, the same thing is one update-table call per replica, sent to the table's current Region. MREC replication reads changes from DynamoDB Streams, so streams are on for every replica of an MREC global table and cannot be turned off while it is global.

# 1. an ordinary table in US East (Ohio)
aws dynamodb create-table \
  --table-name orders \
  --attribute-definitions AttributeName=customer,AttributeType=S AttributeName=order_id,AttributeType=S \
  --key-schema AttributeName=customer,KeyType=HASH AttributeName=order_id,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
  --region us-east-2

# 2. add replicas, one at a time (MREC is the default)
aws dynamodb update-table --table-name orders --region us-east-2 \
  --replica-updates '[{"Create":{"RegionName":"us-east-1"}}]'

aws dynamodb update-table --table-name orders --region us-east-2 \
  --replica-updates '[{"Create":{"RegionName":"eu-west-1"}}]'

# 3. check the replicas
aws dynamodb describe-table --table-name orders --region us-east-2 \
  --query 'Table.{Status:TableStatus,Mode:MultiRegionConsistency,Version:GlobalTableVersion,Replicas:Replicas[*].{Region:RegionName,Status:ReplicaStatus}}'

For an MRSC table, start from an empty table and add the second replica and a witness (or two replicas) in one request with the consistency mode:

aws dynamodb update-table --table-name ledger --region us-east-2 \
  --replica-updates '[{"Create":{"RegionName":"us-east-1"}}]' \
  --global-table-witness-updates '[{"Create":{"RegionName":"us-west-2"}}]' \
  --multi-region-consistency STRONG

A quick replication check: write an item in one Region and read it from another a few seconds later.

aws dynamodb put-item --table-name orders --region us-east-2 \
  --item '{"customer":{"S":"aoife"},"order_id":{"S":"o-1001"}}'

aws dynamodb get-item --table-name orders --region eu-west-1 \
  --key '{"customer":{"S":"aoife"},"order_id":{"S":"o-1001"}}'

To remove a replica and delete its table, use a Delete action with the Region name. Read the disassociate section first if you want to keep that Region's data. And enable deletion protection on every replica you care about: it is set per replica, not once for the global table.

DynamoDB global tables in Terraform

In the AWS provider for Terraform, a current-version global table is an aws_dynamodb_table with one replica block per extra Region. The configuration below defines an MREC table in three Regions and an MRSC table with two replicas and a witness; it validated cleanly against AWS provider 6.70.0 with Terraform 1.16.5:

provider "aws" { region = "us-east-2" }

# MREC global table: Ohio (home) + N. Virginia + Ireland
resource "aws_dynamodb_table" "orders" {
  name             = "orders"
  billing_mode     = "PAY_PER_REQUEST"
  hash_key         = "customer"
  range_key        = "order_id"
  stream_enabled   = true
  stream_view_type = "NEW_AND_OLD_IMAGES"
  deletion_protection_enabled = true

  attribute {
    name = "customer"
    type = "S"
  }
  attribute {
    name = "order_id"
    type = "S"
  }

  replica {
    region_name                 = "us-east-1"
    propagate_tags              = true
    deletion_protection_enabled = true
  }
  replica {
    region_name                 = "eu-west-1"
    propagate_tags              = true
    deletion_protection_enabled = true
  }
}

# MRSC global table: two replicas + a witness, three Regions in total, created empty
resource "aws_dynamodb_table" "ledger" {
  name         = "ledger"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "account"

  attribute {
    name = "account"
    type = "S"
  }

  replica {
    region_name      = "us-east-1"
    consistency_mode = "STRONG"
  }

  global_table_witness {
    region_name = "us-west-2"
  }
}

The replica block also accepts kms_key_arn (a customer managed key in that Region) and point_in_time_recovery. A wrong mode is caught before anything is created:

Error: expected consistency_mode to be one of ["EVENTUAL" "STRONG"], got STRONGEST

Two Terraform cautions. Removing a replica block tells Terraform to remove that replica, which deletes its table in that Region; provider 6.70.0 has no disassociate setting, so to keep a Region's table, disassociate it with the CLI first (next section), then remove the block and run terraform plan to confirm there is nothing left to change. And do not use aws_dynamodb_global_table for new work; that resource manages the legacy 2017.11.29 version.

CloudFormation: the resource-type trap

In CloudFormation, use AWS::DynamoDB::GlobalTable, with a Replicas list, and define all replicas in one stack in one Region. CloudFormation does not coordinate a global table across several regional stacks; defining each replica in its own stack produces drift errors on replica updates.

The trap is converting an existing table. You cannot change a resource from AWS::DynamoDB::Table to AWS::DynamoDB::GlobalTable by editing its type in the template; attempting it can delete your table. The safe path is: set the table's DeletionPolicy to Retain, remove it from the stack, add replicas in the console (which makes it a global table), then import it into the stack as an AWS::DynamoDB::GlobalTable resource. A GlobalTable with a single Region behaves like a normal table, so new tables can start as GlobalTable and gain Regions later with a stack update.

Another surprise from the template: when a new replica is created, it starts with the source Region's provisioned capacity settings, including the auto scaling maximum, whatever your template says. If that maximum exceeds the destination Region's table quota, creation fails with an error mentioning insufficient TableMaxReadCapacityUnits limits. Raise the quota or lower the source maximum first. If a stack update fails halfway, UPDATE_ROLLBACK_FAILED explains how to get it moving again.

Disassociate a replica: leave a global table and keep the data (new)

Since October 20, 2026, an MREC global table (version 2019.11.21, same-account or multi-account) can let a replica leave without deleting it. The table stays in its Region and account with the same name and ARN, keeps its data, indexes, Streams, TTL, backups, encryption, billing mode and table class, and from then on is billed as an ordinary single-Region table. Typical reasons: a Region you no longer serve (Jake's Ireland), an account leaving a shared multi-account table, or a copy kept for audit or testing.

Four rules decide what happens:

• Two replicas means two single-Region tables. With three or more replicas, the one you disassociate leaves and the rest stay global. With exactly two, both become standalone tables.
• It cannot be undone. You cannot reattach the table to the global table it left. To rejoin, copy any changes you need into the remaining global table, delete the standalone table, and add a fresh replica.
• Data catches up first, one way. DynamoDB picks a cut-off point after it accepts the request and waits until every remaining replica has received all writes made directly to the leaving replica up to that point. The leaving table keeps serving reads and writes throughout, but it may miss the very latest writes from other Regions.
• Protected by default. Every replica has disassociation protection turned on, separate from deletion protection. You must turn it off, in its own request, before disassociating.

The steps, run against the replica that is leaving, from its own Region and with credentials for the account that owns it:

1. Turn off disassociation protection (this does not stop replication):

   aws dynamodb update-table --table-name orders --region eu-west-1 \
     --no-disassociation-protection-enabled

2. Wait for it: repeat until the table is ACTIVE and DisassociationProtectionEnabled is false.

   aws dynamodb describe-table --table-name orders --region eu-west-1 \
     --query 'Table.{Status:TableStatus,Protection:DisassociationProtectionEnabled,Replicas:Replicas}'

3. Disassociate, in a separate request, with the mode set explicitly:

   aws dynamodb update-table --table-name orders --region eu-west-1 \
     --replica-updates '[{"Disassociate":{"RegionName":"eu-west-1","DisassociationMode":"WAIT_FOR_REPLICATION"}}]'

4. Confirm membership, not just status. Wait for ACTIVE, then check that Replicas no longer lists the other Regions, and check from a remaining replica that Ireland is gone. ACTIVE alone proves nothing: if disassociation rolls back, the table also returns to ACTIVE, still a member of the global table.

The IAM permissions are dynamodb:UpdateTable and dynamodb:DisassociateTableReplica on the local replica's table ARN, plus dynamodb:DescribeTable to watch it. DisassociateTableReplica is a permission only; the API call is still UpdateTable.

Update your tools first. The feature needs a current AWS CLI or SDK. An AWS CLI 1.46.2 install (botocore 1.43.62) rejected both steps before sending anything:

$ aws dynamodb update-table --table-name Music --region us-west-2 --no-disassociation-protection-enabled
Unknown options: --no-disassociation-protection-enabled

$ aws dynamodb update-table --table-name Music --region us-west-2 \
    --replica-updates '[{"Disassociate":{"RegionName":"us-west-2","DisassociationMode":"WAIT_FOR_REPLICATION"}}]'
Parameter validation failed:
Unknown parameter in ReplicaUpdates[0]: "Disassociate", must be one of: Create, Update, Delete

With boto3 and botocore 1.43.118, the same requests passed validation, and leaving out the mode was caught on the client: Missing required parameter in ReplicaUpdates[0].Disassociate: "DisassociationMode". The only accepted mode is WAIT_FOR_REPLICATION.

Disassociation is blocked while any replica is INACCESSIBLE_ENCRYPTION_CREDENTIALS, REPLICATION_NOT_AUTHORIZED, ARCHIVING or ARCHIVED; while another replica operation is running; and for a replica that was used as the source for a new replica in the last 24 hours. It is not available for MRSC tables or legacy 2017.11.29 global tables, and in a multi-account table each account can disassociate only its own replica.

Jake got his answer the week it launched. Ethan disassociated the Ireland replica on a Thursday; the Irish orders stayed exactly where they were, the replicated write charges for Ireland stopped, and the accountant got a read-only role on a table that would never change again. "So it's like moving out but keeping your furniture," Jake said. Ethan said that was close enough.

Multi-account global tables

A multi-account global table spreads its replicas across AWS accounts as well as Regions: one replica per account, so a table with three replicas needs three accounts. It is used to isolate business units, apply different security controls per account, or bill each copy to its owner. It supports MREC only, and its replicas share one set of settings: capacity mode, throughput, auto scaling, indexes, Streams and TTL are always the same everywhere, without the per-replica overrides a same-account table allows (read auto scaling policies are the one exception).

1. Start from a single-Region table in the first account. Multi-account global tables can only be built from a regional table, not from a same-account global table.
2. Turn on settings replication on that table (GlobalTableSettingsReplicationMode set to ENABLED; in the console, the Global tables tab, Settings Replication, Enable).
3. Add a resource policy to every replica that allows the replication service principal, replication.dynamodb.amazonaws.com, the actions dynamodb:ReadDataForReplication, dynamodb:WriteDataForReplication and dynamodb:ReplicateSettings (scoped with aws:SourceAccount and aws:SourceArn to the participating tables), and allows the trusted accounts dynamodb:AssociateTableReplica. Replication goes both ways, so each account mirrors the other's policy.
4. Create the replica from the other account, in its own Region, pointing at the source table:

   aws dynamodb create-table --table-name orders --region us-east-1 \
     --global-table-source-arn arn:aws:dynamodb:us-east-2:111122223333:table/orders \
     --global-table-settings-replication-mode ENABLED \
     --resource-policy file://replica-policy.json

   No key schema is needed: it comes from the source table. In the console this is Create table, then Create from another account, listing every existing replica's ARN.

That request shape (table name, source ARN, ENABLED mode and policy, with no key schema) passed validation with botocore 1.43.118. For multi-account tables, ENABLED is the only supported mode; same-account replicas show ENABLED_WITH_OVERRIDES.

Disassociation is also the migration path from a same-account to a multi-account global table: disassociate a replica, keep its table and data as a regional table, and use that table as the source of a new multi-account global table.

Permissions, the replication role, and the 20-hour trap

Replication runs under a service-linked role, AWSServiceRoleForDynamoDBReplication, which DynamoDB creates in your account the first time you make a global table. You never manage it, but you can break it. If a table's resource policy, or a broad Deny in an organization policy, blocks the permissions that role needs, replication to and from that replica stops and the replica's status becomes REPLICATION_NOT_AUTHORIZED. Then the clock starts:

• MREC: if the replica stays REPLICATION_NOT_AUTHORIZED for more than 20 hours, it is irreversibly converted to a single-Region table. No warning email undoes it; the Region has left the global table.
• MRSC: writes and strongly consistent reads fail with AccessDeniedException straight away, and after seven days in that state the replica becomes permanently inaccessible for them.

The safe pattern for a strict Deny statement is to exclude the DynamoDB service-linked roles from it, with a condition such as:

"Condition": {
  "StringNotEquals": {
    "aws:PrincipalArn": [
      "arn:aws:iam::111122223333:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication",
      "arn:aws:iam::111122223333:role/aws-service-role/dynamodb.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_DynamoDBTable"
    ]
  }
}

The second ARN is the auto scaling role, which provisioned global tables need for the same reason. Ethan added a CloudWatch alarm on replica status the day he read about the 20 hours. "A security review shouldn't be able to quietly shrink the database," he said.

Replication latency and monitoring

For MREC tables, DynamoDB publishes a CloudWatch metric called ReplicationLatency, in milliseconds, for every source and destination Region pair. It measures the time from a write in one replica to its appearance in another. Typical values depend mostly on distance: Oregon to California is quicker than Oregon to Cape Town. Replication usually completes within a second.

• Alarm on it. A rising ReplicationLatency means writes are not reaching another Region promptly; the documented response is to move traffic to another Region for a while.
• Read your own writes in the same Region. After a write in Ohio, a read in Ireland a few milliseconds later may not see it. Keep a user's session in one Region where possible.
• MRSC has no such metric, because writes are synchronous; watch write latency and ReplicatedWriteConflictException counts instead.

You can rehearse a Region failure without waiting for one. Both modes work with AWS Fault Injection Service, which can isolate one replica (pause replication to and from it) so you can test how your application shifts traffic and recovers. During such an experiment on MRSC, eventually consistent reads still work, but table setting changes are not allowed.

What behaves differently on a global table

A replica is a normal table for reads and writes, but a few features change meaning once the table is global:

• Streams. On MREC, Streams are always on, and each replica's stream can differ slightly because replication may merge several quick changes into one. Order is kept per item, not across items. If a Lambda function should react only to changes made in its own Region, store the Region in an attribute and filter on it; why a Streams trigger does not fire covers event filters.
• Transactions. On MREC, TransactWriteItems is atomic only in the Region where it runs; other Regions can briefly see part of a transaction while it replicates. On MRSC, transactions are not supported. TransactionCanceledException covers transaction errors in general.
• TTL. TTL settings are synchronized across MREC replicas, and an expiry in one Region is replicated as a delete everywhere. MRSC does not support TTL.
• Capacity. Replication consumes write capacity on provisioned replicas, so size them for all writes, not just local ones. Read capacity can be set per replica; write capacity and auto scaling are kept in step.
• Backups. Point-in-time recovery and backups on one replica may be enough for your recovery goals; AWS Backup can copy backups across Regions. What AWS Backup is explains vaults and copies.
• Deleting the source. The table used to create a new replica cannot be deleted until 24 hours after that replica was created.
• Disabling a Region. If you disable an opt-in Region that holds replicas, those replicas are permanently converted to single-Region tables 20 hours later.
• Encryption. Each replica can use its own KMS key in its own Region. If a replica's key becomes unusable, the replica goes to INACCESSIBLE_ENCRYPTION_CREDENTIALS, which also blocks disassociation; KMS errors covers key policies.

Global table errors and what they mean

When not to use a global table

Global tables solve two problems: users far from your Region, and surviving a Region outage while still accepting writes. If you have neither, there are cheaper answers:

• Backup only? Point-in-time recovery plus cross-Region backup copies protect the data for a fraction of the cost of a live replica, with a slower recovery.
• Reads far away, writes in one place? A cache or a read-only copy fed by Streams can be enough, though a global table is often simpler.
• Tiny write volume? Then a global table is cheap, and the simplicity may win anyway; the cost table above tells you.
• Need SQL joins across Regions? Then the question is the database, not the replication; DynamoDB is the wrong tool whether global or not.

Troubleshooting by symptom

An item written in one Region is missing in another

MREC replication is asynchronous. Wait a second and read again, and check ReplicationLatency for that Region pair.

Two Regions show different values for the same item

Both were written at nearly the same time. Last writer wins; the item converges to the later write.

My bill tripled after adding two Regions

Writes, GSI writes and storage are billed per Region. Check write volume and the number of GSIs; reads are unchanged.

Provisioned replica throttles writes

Replication uses write capacity too. Size every replica for all writes, not only local ones.

Disassociate command not recognized

Your CLI or SDK is older than the feature. Update it and retry.

Replica creation failed

Check the destination Region's table quotas against the source's capacity settings, and the KMS key in that Region.

Lambda processes the same change in every Region

Each replica has its own stream. Store the writing Region in the item and filter events on it.

Transaction looks half-applied in another Region

MREC transactions are atomic only in their own Region. Read from the Region that wrote, or design for it.

Frequently asked questions

The Ireland table is still there, frozen at the day the warehouse closed, and the accountant has never once asked Ethan for help with it. Jake considers that the best review a database has ever had.

Revision note. Written October 23, 2026, three days after DynamoDB global tables gained replica disassociation. "Measure twice, cut once," the proverb says, and with disassociation that is literal: there is no second cut back.