Is RDS PostgreSQL Blue/Green Admissible for This Change?

Decide whether an exact RDS PostgreSQL DB-instance change fits physical or logical managed blue/green replication, with workload evidence, alternatives, identity...

Executive summary

Choose managed RDS Blue/Green Deployments only after the exact proposed change has passed its replication-method, workload and recovery gates. Do not select it merely because a second database sounds easier to reverse. For PostgreSQL, physical and logical paths offer materially different evaluation surfaces. A plan that depends on writing to a physical green database is inadmissible even if its engine and topology are supported. A logical major-upgrade plan can be equally unsuitable when the ordinary workload requires changes that its managed path cannot carry.

The useful output is an evidence-backed method decision, not a universal blue/green checklist. First identify the source resource and exact requested change. Then determine the documented method, test its hard constraints against the workload, compare plausible alternatives and prepare the application, identity and recovery contracts. A candidate can pass feature eligibility while remaining held for application evidence or cost approval. Keep those states separate so a supported feature does not become an unauthorized operation.

This paper supplies a fillable ledger and fictional incomplete packets. It records no AWS account execution, customer migration, measured downtime, accepted recovery or savings result. Primary documentation was checked on October 7, 2026; refresh it and the actual environment before a separately authorized exercise. The recommendation is conditional: use the managed feature when its restrictions fit the required change and the team can prove the later operational gates. Otherwise select a narrower intervention, a bounded in-place upgrade, a separately designed migration or a documented deferral.

1. Separate feature support, admissibility and execution acceptance

Feature support asks whether AWS offers the mechanism for the selected engine and deployment. Admissibility asks whether it can perform this change while respecting the workload's hard requirements. Execution acceptance asks whether the approved candidate actually produced the required result in the observed environment. These are three decisions with different evidence. An architect can complete a defensible paper assessment without having permission to create resources or move traffic.

Use five dispositions in the ledger: SUPPORTED for a cited capability, UNSUPPORTED for a documented conflict, UNKNOWN for missing or contradictory evidence, CANDIDATE for a proposal that passes the paper gates, and ACCEPTED only for the separately reviewed observations. A supported vendor capability is not an observed account outcome. A candidate may still have several unexecuted tests. Do not collapse these distinctions into a green score or an average that allows a failed data requirement to be outweighed by convenience.

The database owner records the technical method. The application owner defines the critical operation and uncertain-commit behavior. Security owns effective access and evidence handling; finance owns bounded overlap and retention funding. A service decision owner accepts the disruption and recovery consequences. An independent observer reviews the completed packet. These are responsibilities to assign for an actual change, not claims of customer execution or sign-off. Require a named person for each responsibility in the change record.

2. Establish the precise product boundary

The unit here is an RDS PostgreSQL DB instance and its relevant replicas. Multi-AZ DB-instance deployment and Multi-AZ DB cluster are different products. The current limitations reference permits the former and excludes the latter; it also excludes cascading and cross-Region read replicas. Aurora has separate documentation. Hold a proposal whose inventory cannot establish which deployment it is, rather than borrowing a diagram from another product.

The current availability reference lists all AWS Regions and PostgreSQL 11.1 and higher. That is not a promise that every historical minor, target combination or account configuration is currently admissible. Record the selected Region, source status, exact version and current supported target evidence. A broad feature page and an old screenshot do not close an exact-target question. Account quotas and operational prerequisites remain separate inputs.

Capture a sanitized resource inventory before interpreting the change: account, Region, engine, DbiResourceId, current identifier/ARN, topology, replicas, backups, parameter groups and pending changes. The DBInstance response distinguishes those fields. Preserve absent or denied fields as UNKNOWN with an owner and capture time. Do not treat a renamed instance, missing endpoint or unavailable read as proof of an unchanged physical resource.

Make two pre-creation inputs explicit. The managed limitations exclude master passwords managed with AWS Secrets Manager. Record the actual password-management state and dated evidence, not secret contents. A known unsupported state excludes this proposed mechanism until a separately reviewed alternative exists; an unknown state holds admission. For a physical PostgreSQL candidate, creation preparation requires enabled automated backups. Record method applicability, actual backup state and evidence. Disabled or unknown required backups do not clear the pre-creation gate. This is not a complete prerequisite catalog or an instruction to mutate credentials or backup settings.

3. Determine the replication method from the change

AWS's PostgreSQL method table assigns physical replication to supported same-major changes, including minor upgrades and no engine upgrade. A major upgrade requested at creation uses logical replication for sources 16.1 and higher, 15.4+ within 15, 14.9+ within 14, 13.12+ within 13, 12.16+ within 12, and 11.21+ within 11. Older listed minors do not support that major-upgrade path. This dated rule is not a permanent version recommendation.

Record the source version and target version as complete strings, not merely 15 and 16. Preserve whether the engine change is requested during deployment creation or proposed afterward. A same-major green database is not a staging shortcut for an eventual manually applied major upgrade. The source table, actual submitted request and observed environment belong beside one another. If they disagree, investigate before calling the method known; never infer logical replication simply from the words blue/green.

The create API defines Source as the production ARN, TargetEngineVersion and target instance/parameter/storage options. It is a cross-product API, so a cluster field's existence does not admit a Multi-AZ DB cluster here. Keep a proposed request inert until the exact parameters and independent permissions have been reviewed. An accepted creation response starts provisioning; it does not establish the requested engine, replication health or application behavior.

4. Use the method decision map without mistaking it for approval

Method-selection reference, not an observed deployment. Blue branches identify candidates to investigate; the brown hold boundary prevents unsupported or unknown inputs from being interpreted as another automatic migration path.

Use the map to identify the next evidence request. It does not rank logical above physical or predict availability. A method is useful only relative to the proposed work. If the business needs an engine-major change, a same-major physical candidate does not satisfy that requirement. If the team only needs a parameter or instance adjustment, adding a major upgrade may introduce unnecessary workload restrictions and compatibility work. Narrowing the change can be a technically better outcome than finding a more elaborate migration.

The owner should be able to explain each branch in the actual packet without reading the diagram aloud. Which exact fact establishes the product boundary? Which change invokes the selected method? Which required test is impossible on the chosen green environment? Which requirement forced the rejected alternative? If the answers are missing, revise the packet. Visual clarity helps expose these questions but does not supply the missing facts.

5. Assess the physical evaluation surface honestly

Physical green is strictly read-only: no green schema changes and no manual major upgrade after creation. The source cannot be an external logical publisher or subscriber. These are method-specific constraints, not optional testing preferences. Reject a candidate that requires a writable green fixture or plans to create physical green first and upgrade its major later. Do not issue a session setting to try to evade the boundary.

There is still useful evaluation work. The application owner can examine permitted reads, authentication, plans and selected configuration against declared expectations. Record the build and driver versions, role, query population, data age and loading conditions. A read-only smoke test demonstrates only that scope. It cannot prove insert-generated identities, trigger effects, worker behavior or transaction retries after promotion. Assign those gaps a separate isolated writable test design or a bounded post-transition acceptance plan approved by the service owner.

The decision is not that read-only testing is weak or useless. It is that its coverage must match its claim. A reporting-only workload may obtain most of its relevant evidence through reads; a booking writer cannot. Explain which behaviors can be assessed before switch and which remain unobserved. If the service cannot accept the remaining uncertainty, select a different evaluation mechanism. Do not reduce the acceptance criteria merely to make managed staging appear sufficient.

6. Build the logical workload inventory before freezing a date

For the managed logical path, catalog data and activity across every database. Unlogged tables, existing or changed large objects, automated partition creation, external replication and background extensions need explicit dispositions. AWS requires pg_partman, pglogical and pgactive disabled on blue, pg_cron disabled on green, and applicable pgAudit library configuration maintained. DDL can degrade replication; DCL is not propagated. The managed limitations govern this path, not a self-managed repair recipe.

Record who can introduce the prohibited activity, including release automation, tenant provisioning, partition jobs, administration and extension workers. A code freeze that excludes administrative jobs is incomplete evidence. An operator promising not to run DDL does not control a scheduler that creates tomorrow's partition. The inventory needs its scope, capture method, pending schedule and closure evidence. If the owner cannot stop a required incompatible operation for the whole coexistence window, choose another method or reduce the change.

The PostgreSQL 18 logical restrictions separately distinguish table data, schema, sequences and large objects. They explain engine mechanics, not permission to manually modify RDS-managed replication. Bind the engine version when using that reference; verify the corresponding documentation for another major. A binary value in an ordinary column is not automatically a PostgreSQL large object. Have the database owner classify actual storage and access paths, not guess from the application's filename or MIME type.

7. Treat keys, sequences and derived views as different questions

The preparation guide calls for primary keys; the managed considerations allow a reviewed REPLICA IDENTITY FULL alternative. PostgreSQL documents type and performance limits for that alternative. Do not label it a universal switch that makes every keyless table safe. Record table identity, update/delete use, types, chosen treatment and representative overhead evidence. A unique-looking application column is not necessarily the database identity used by replication. Preparation, engine restrictions.

Sequence generation and copied key values are separate acceptance items. RDS synchronizes sequences at switchover, but unusually numerous sequences can lengthen that work. Materialized views need their own refresh disposition. Those managed considerations should lead to a concrete writer and freshness test, not to an unreviewed sequence-reset command. Keep the identifiers of accepted synthetic operations so a later observer can investigate collisions or missing derived results.

For each derived view, ask whether stale results are acceptable during the selected observation window and who may refresh it. A dashboard that looks plausible can be wrong while all base rows are present. Define the fixture's expected answer independently from the candidate query. Identify permissions and resource load for any refresh. This paper does not prescribe a universal query count or throughput threshold; choose representative operations from the workload's actual obligations and retain failures in the reported population.

8. Prove coexistence capacity rather than promising catch-up

Logical preparation requires applied parameter settings and adequate worker, sender and slot capacity; source WAL retention also needs storage. Review the creation prerequisites as owned changes, including any reboot, rather than silently treating preparation as read-only. Inspect every database and the intended peak period. A parameter-group name is configuration intent; the applied runtime and absence of pending incompatible changes are separate evidence.

Measure the generation and apply relationship over representative peaks and recovery periods. AWS describes single-threaded green logical apply, so more CPU does not automatically remove the constraint. Its best practices identify memory and replication-slot disk signals. Use method-appropriate lag observations, workload generation, free storage and a dated trend. An empty metric query is UNKNOWN until dimensions, permissions and collection interval are explained. A quiet-period zero is not a peak-capacity test.

The operator records a storage floor, lag growth trigger, observation deadline and escalation owner before coexistence. If the approved bound is crossed, stop progressing toward switchover and protect the source through the separately approved incident/change procedure. Do not drop a managed slot, disable ordinary work or increase spending merely to make a chart green. Explain whether the remaining evidence permits continuing staging, rebuilding later or abandoning this method. A failure to catch up is useful method-selection evidence, not a reason to remove the workload from the test.

9. Preserve application acceptance independently of service status

Define a small critical-operation population with the application owner: authenticated reads, expected denials, write-dependent outcomes on an appropriately isolated target, transaction failure, reconnect and uncertain commit. Record the exact release, driver, parameter configuration, extensions and dataset treatment. Use synthetic or approved de-identified data and inert external adapters. A staging copy can contain sensitive records and privileged routines even when nobody has switched production traffic to it.

For a major version, valid target availability is not application compatibility. The upgrade-choice guide warns about incompatible behavior and separate extension upgrades. The major-upgrade procedure adds prechecks, logs, statistics and replica consequences. Keep extension support, extension change approval and observed behavior separate. Do not drop an extension because a precheck example happens to mention one.

The BlueGreenDeployment status contract describes provisioning, availability and switch states. None is a business test result. Preserve status details, tasks, source/target mappings and observation times alongside application evidence. A deployment marked available with untested application behavior is still held at the application's gate. A completed switch with an unresolved operation is not accepted service restoration. This separation makes the packet useful when control-plane and user-level observations disagree.

10. Assess the real connection and Proxy path

Current RDS Proxy blue/green guidance supports RDS PostgreSQL, provided blue is already a proxy target before deployment creation. Registering it afterward is blocked. During transition PostgreSQL can return AdminShutdown; promotion drops existing proxy connections and applications must reconnect. Target API readback can lag routing until completion. Proxy reduces a routing delay; it does not promise uninterrupted transactions or settle an uncertain committed write.

Inventory direct connections, proxy connections, pooled clients, scheduled consumers and any configuration that pins an address or caches a name. Identify who owns reconnect, deadline and retry behavior. A client that retries a statement after a connection failure must follow the business operation's existing uncertainty contract, not assume failure means no commit. The session-pinning article owns reuse diagnosis. This paper asks whether the already chosen connection path is admissible and testable for this transition.

Do not silently repair the deployment by adding a proxy after creation or changing drivers on the eve of switch. Each is a separate change with a changed test basis. If the packet has no evidence that the actual workers use the reviewed endpoint, hold the client gate. Include an application-level observer who can resolve one timed-out synthetic operation from durable state. A proxy console or database connection count cannot replace that evidence.

11. Distinguish a managed switch rollback from post-write recovery

The switch guide describes health/lag/write guardrails, connection interruption and an explicit timeout range of 30–3,600 seconds, default 300. A stopped unfinished switch is rolled back by RDS. After a completed switch, replication between the environments stops and retained blue is read-only. These are different boundaries. Retained blue is not an automatically synchronized failback system, and manual promotion of green is not managed switchover.

Document two recovery decisions. Before completion, the observer needs the actual switch outcome and current identities before proposing another attempt. After the new production resource accepts writes, the service owner needs a way to preserve or explicitly account for those operations. Returning a hostname or enabling writes on retained blue cannot supply absent data. The migration authority paper owns the broader reverse-synchronization and recovery argument; do not duplicate it as an invented managed RDS feature.

For a logical candidate, audit any session override of read-only behavior. AWS warns that writes escaping the transition fence can leave inconsistencies if switch rolls back. Do not rely solely on a parameter screenshot. Switch recommendations. A safe rehearsal specification includes a known operation identity, a recorded interruption and its observed disposition. It remains NOT EXECUTED here. Account authorization, effect isolation and an approved recovery procedure are prerequisites to running it.

12. Map stable names to changing resource and recovery evidence

Identity/provenance comparison, not a reverse-replication architecture. BLUE and GREEN are fictional immutable identity labels. Current ARNs and identifiers are captured separately; no history-merging or automatic failback connector exists.

The stable production name is a routing convenience, not resource continuity. DbiResourceId remains with its instance, while identifier and endpoint assignment change. The new production instance has its own PITR history, beginning with green creation rather than inheriting earlier blue history. Retained blue preserves its own history while retained. Use its resource ID for prior-blue recovery. Identity and recovery considerations.

Build a before-and-after record for each actual consumer. Does it address a name, ARN, resource ID, proxy target or checkpoint? What read proves the new mapping? What application observation proves that the consumer is using it? What historical record must still identify blue? Store those answers with capture times. Do not overwrite all historical identifiers with the current production identifier: that makes an old backup or audit event appear to belong to another resource.

The recovery owner records earliest/latest restorable bounds, backup identity, required time and exact source. PITR guidance describes restoring to a new instance, not rewinding the serving instance in place. A recovery time earlier than green's history requires a separately supported source path. If history or access is unknown, retain the recovery hold and its funding consequence. No restoration or recoverability claim follows from this paper's synthetic identity diagram.

13. Review security and integration remapping as owned work

Separate AWS control-plane authority, database privileges and business authority. The blue/green permission guide distinguishes creation, switch and deletion permissions and warns about generated-resource naming constraints. Do not give the evidence observer mutation privileges simply because it is convenient. A wildcard policy pasted into a whitepaper is not least-privilege proof. Have security review effective resource/tag conditions and dependent actions for the exact proposed request.

For direct IAM database authentication, the database-access policy guide uses DB resource IDs in the connection ARN. For client authentication through RDS Proxy it instead specifies the proxy resource ID. Distinguish those hops and review the proxy-to-database authentication basis separately, rather than replacing every client policy with GREEN's DB resource ID. Inventory each actual role and DB user, prepare the intended mapping, and test allowed and denied access on the permitted evaluation surface. A successful privileged connection is not the application role's test. Preserve a negative authorization case and identify which evidence remains impossible before promotion.

Treat monitoring, audit consumers, backup selectors, associated roles and existing replication consumers as independently owned integrations. The current limitations page calls out remapping and checkpoint consequences. A repeated name is insufficient continuity evidence. Record an exact readback and next action for each affected consumer, and stop the relevant acceptance gate if required evidence is unavailable. Minimize payloads in the ledger, control access to extracts and set evidence retention deliberately. Engineering records do not establish legal or regulatory compliance.

14. Compare real alternatives against the same constraints

Managed physical candidate: appropriate when the same-major change and read-only evaluation surface fit. Its advantage is a provider-managed transition rather than a custom applier. Its constraint is inability to demonstrate arbitrary green writes or transform schema there. Reject it if the required change is actually a major upgrade or application-level remodeling. State the missing behavior and why a separate test is or is not acceptable. Do not sell its relative simplicity as proof of lower total risk.

Managed logical candidate: appropriate when an eligible major-upgrade source and workload restrictions fit. It permits a different major but adds a coexistence contract around workload objects, changes and apply capacity. Reject it for a hard incompatibility that cannot be removed within the accepted window, not merely because another method is familiar. Measure the proposed workload rather than assuming a provider recommendation supplies capacity. A larger instance and longer timeout are hypotheses to test, not ways to average away incorrect data.

Bounded in-place upgrade: appropriate when a funded interruption is more acceptable than replication complexity. Use the current exact-target and major-upgrade procedure for prechecks, extensions, replicas and recovery. Newer source versions have changed slot-retention rules; do not mechanically drop every logical slot from an older runbook. Its obligations include an actual rehearsal, application acceptance, disruption communication and backup recovery evidence. A logical-path blocker does not prove this alternative works. Upgrade procedure.

Separately designed migration: appropriate when required restructuring or integration behavior cannot fit the managed mechanism. It needs independently designed capture, comparison, writer fencing and post-write recovery. DMS or another tool is not an automatic exemption from workload limitations. Use the existing data reconciliation paper for semantic evidence. This paper does not invent a replacement CDC recipe. Narrow or defer when reducing the change closes the hard conflict or when no option has a funded, testable recovery contract. Give deferral an owner, trigger and evidence deadline.

15. Fund coexistence, failure and recovery retention separately

Build a resource-duration estimate with the financial owner. Include the proposed green topology, any retained blue resources, storage/backups, replication headroom, telemetry and required observation period. Use dated Region/class rates and actual configuration rather than a fabricated savings percentage. Separate expected duration from the downside case in which a workload conflict forces rebuilding or an application failure extends retention. A budget notification is an alert, not an automatic hard spending cap.

Price the recovery promise independently of the normal staging window. If the accepted recovery requirement needs pre-green history, the retained source has a purpose and a cost owner. A fixed deletion date cannot override that requirement merely because the switch completed. Conversely, retaining a resource forever without a requirement or reviewer is not a recovery plan. The data owner specifies the history needed; finance specifies funded duration; the service owner resolves a conflict before admission.

Define operational actions at the approved time or spending boundary. Stop new staging work, preserve evidence and ask the named owner whether to extend, narrow or abandon. Do not automatically delete databases, backups, slots or integrations. Cleanup needs exact targets and separate authority after recovery requirements are resolved. Record unresolved charges as UNKNOWN and retain their follow-up owner. A successful change can still have unclosed financial evidence; a failed change can still produce useful admissibility evidence without becoming a success claim.

16. Complete the reusable change-to-method ledger

Copy this packet into an access-controlled change record. Attach evidence references rather than credentials or raw customer rows. Each requirement row needs status, capture time, owner, invalidating change and the next permitted action. Start with UNKNOWN, then promote individual rows only when the supporting observation exists. Separate the documented selection rule from actual method evidence. The latter can include approved request/readback, parameter and replication observations, and a service clarification where needed; no universal ReplicationMethod response field is assumed.

Packet ID/revision/date / accountable decision owner:
Database / application / security / finance / observer owners:
Account/Region / current DB identifier and ARN / DbiResourceId:
Product and topology / every replica / current pending changes:
Exact source version / requested target / dated valid target evidence:
Requested change / creation-time versus later change / excluded work:
Current feature evidence / method-rule source and date:
Master-password management state / dated evidence / unsupported or UNKNOWN gate:
Automated-backup method applicability / actual enabled state / evidence / gate:
Documented method / actual-method evidence / contradictions:
Physical evaluation coverage / impossible green-write tests:
All databases / tables and identity / types / update-delete usage:
Unlogged data / large objects / required derived views:
DDL/DCL writers and schedules / partition creation / freeze ownership:
Extensions / workers / external publishers-subscribers / disposition:
Applied parameters / slots-worker capacity / WAL/storage evidence:
Peak generation/apply observations / lag / stop thresholds:
Application build / driver / fixtures / expected vs observed outcomes:
Client endpoint/proxy target before creation / reconnect/unknown commits:
Pre/post resource mapping / IAM and integrations / evidence owner:
PITR source resource and earliest/latest times / required recovery time:
Switch timeout / disruption budget / guardrail and observer evidence:
Post-write recovery contract / known operation identities / open risks:
Parallel/retained resource list / dated rates / downside duration/budget:
Alternative considered / exact disqualifying requirement:
Required row -> SUPPORTED/UNSUPPORTED/UNKNOWN -> source/observation:
Row owner / capture time / invalidator / next permitted action:
Current disposition: HOLD / ALTERNATIVE / CANDIDATE FOR REHEARSAL:
Separate execution authority / window / exact mutable resource list:
NOT EXECUTED until actual authorized results and independent acceptance:
Cleanup/retention decision / exact targets / subsequent readback:

The compact conclusion should point to the rows that decide the method. For example: logical candidate held because scheduled partition creation is required and not controlled; bounded in-place candidate selected for separate rehearsal because a downtime window exists. That is more useful than saying migration risk is medium. Preserve the rejected option and criterion so a later reviewer can recognize when a changed requirement justifies reconsideration. Do not present a signed empty worksheet as technical evidence.

17. Challenge the ledger with fictional missing-evidence packets

These cases are stipulated tabletop inputs, never AWS responses. Their expected dispositions are specified before any account exercise. A: supported same-major candidate, but its test plan writes to green and manually upgrades its major later. Reject that plan as physical-path incompatible. A successful read does not cure it. B: eligible logical-major candidate whose scheduler must create new partitions and whose large-object inventory is missing. Hold for incompatibility resolution and UNKNOWN data coverage, not for another lag screenshot.

C: source/target and object inventory fit on paper, but peak apply capacity, reconnect and application checks have not run. Classify CANDIDATE FOR REHEARSAL, not accepted production. D: creation already occurred without the intended proxy registration; the proposal now assumes proxy can be added. Hold that connection design and select a separately reviewed disposition. E: production name appears unchanged after fictional switch, while IAM still selects BLUE and the required recovery point predates green. Hold integration/recovery acceptance even if a privileged SQL read succeeds.

F: fictional deployment says switch completed, but the observer cannot settle an interrupted operation and the retained source lacks later writes. Do not route back automatically. Hold the operation under its original identity and invoke the approved post-write recovery contract. G: all paper rows fit, but the actor lacks a funded execution window. Technical candidacy does not authorize creation or switch. H: one required catalog read is denied and a reviewer replaces it with zero objects. Fail that packet's evidence gate: denied access remains UNKNOWN.

I: a fictional physical candidate has unknown password-management evidence and no observed automated-backup state. Hold both prerequisite rows, even if its version and same-major change fit. A separate stipulated Secrets Manager-managed master-password state excludes the proposed managed mechanism; stipulated disabled physical-path backups fail the pre-creation gate. Neither input authorizes changing credentials, enabling backups or creating green. These are additional tabletop expectations, not executed service checks.

The independent reviewer should test that a deliberately bad classifier cannot pass these cases. The local validator may check stipulated classification logic and required text; it cannot simulate RDS. Real rehearsals need the selected engine/configuration, safe data, application and observer access, a finite window, spending approval, effect isolation and separately scoped stop/cleanup. Specify expected outcomes before running them, retain every required case and report NOT EXECUTED when absent. A passing tabletop classification is useful preparation, not migration evidence.

18. Close the method decision without overclaiming completion

Review checklist: what clears this method decision?

• Establish the exact DB-instance product, full source and target versions, requested creation-time change and documented replication method. UNKNOWN prerequisite evidence holds; a known unsupported requirement selects another method or narrows the change.
• Check password-management state and method-applicable backups explicitly. For logical candidates, retain all-database object, identity, extension and scheduled-writer evidence. For physical candidates, exclude impossible green-write and later-major tests.
• Explain which application behaviors the permitted green surface can evaluate and which need another isolated test. Record peak coexistence capacity and the source-protection stop boundary separately from eligibility.
• Verify the actual connection path, prior Proxy registration where applicable, reconnect behavior and uncertain-operation handling. A stable endpoint is not uninterrupted execution.
• Preserve pre/post resource identities, integration and IAM mappings, and the source of each required recovery time. Retained blue is not a synchronized post-write return path.
• Fund overlap and recovery retention, appoint the observer and separate execution authority, and retain the rejected alternative's exact conflict. Candidate status permits a rehearsal review, not automatic creation, switch or cleanup.

The decision is ready for a scoped rehearsal review when the exact product/change/method is supported, hard workload conflicts are closed or select an alternative, required evidence has owners, and the proposed tests can answer the unresolved questions within the funded boundary. Execution approval remains a separate record. Subsequent acceptance requires actual observed method/state, application outcomes, identity/integration remapping, recovery evidence and an owned retention/cleanup result. A published framework cannot approve a reader's database operation.

Reopen the decision after a version change, new extension, new writer, changed partition schedule, altered proxy path, changed recovery requirement or expired source evidence. A candidate label is bound to its packet revision. The paper's limitations include no authenticated resource inventory, workload measurements, tested IAM policy, executed upgrade, observed charge or human domain signature. No customer outcome or compliance conclusion is inferred. Retain documentation checks separately from observations of the actual AWS workload.

The next useful step is one completed ledger for the actual proposed change, with the database and service owners able to explain why the chosen method fits and what would stop it. Use the database constraint matrix for broader datastore selection and the existing migration/reconciliation resources for authority and semantic correctness. An optional Ampity AWS consultation can review that bounded packet. Reading this paper does not require contact details or authorize changes, spend or production traffic movement.