Accept the Customer Site, Not Just the AWS Deployment

Set application acceptance for a customer site that loses its AWS connection, including local acknowledgement, backlog capacity, identity and recovery ownership.

A migrated application is ready for a customer site only when the site's normal, disconnected and recovery workflows meet agreed requirements. An AWS health check cannot establish that a warehouse operator can resolve a private hostname, renew an identity, capture work safely or reconcile it after a connection returns. Include those dependencies in acceptance before removing the old local path.

This article helps an application owner and migration buyer define that site acceptance. The output is a per-operation record covering what remains usable during an interruption, what must stop, and who completes recovery. It does not choose a universal VPN topology or prescribe production fault injection. The site and all rates, durations and capacity values in the example are fictional.

1. Follow an operator's complete transaction

Choose a concrete action at the site, such as capturing a dispatch scan and receiving central acceptance. Trace the device, local network, name resolution, identity provider, AWS entry point, application and downstream acknowledgement. Add local printers, file shares or directories where that action actually needs them. The migration boundary follows the required contribution, not the list of servers copied into AWS.

Assign an owner to each dependency. A cloud team may own the application while the customer owns the router, DNS forwarder, device clock and local credentials. A connectivity supplier may own only the circuit. A support plan needs a way to identify which owner has the next action when the application is healthy but the site cannot use it.

Distinguish the location of the user from the process that sends the request. A desktop client, local gateway and cloud worker can make different network and identity decisions. For an S3-specific route, the existing caller-path article owns endpoint eligibility. Here the question is whether the full site workflow remains acceptable when one of its contributions disappears.

2. Give each operation an interruption policy

“Works offline” is too broad for an acceptance criterion. A cached catalogue, a captured event and an authoritative inventory reservation have different correctness requirements. Decide what each operation may acknowledge and what the operator should see while disconnected.

Choose these behaviors with the application and business owners. Do not add a writable local cache merely to keep the screen responsive. The design needs explicit ownership of conflicts, expiry and reconciliation. A device returning success before its durable acceptance point can lose work even though the operator followed the procedure.

Keep local capture distinct from the central business result. The label “pending delivery” should not become “dispatch accepted” until the receiving system has accepted the intended operation. If a timeout leaves central completion uncertain, look up the operation's recorded identity before replay. An outage must not turn one physical scan into two accepted dispatches.

3. Review the network, DNS and identity separately

AWS Site-to-Site VPN provides two tunnels per connection, but the customer-side device and its dependencies still matter. AWS documents a separate redundant-connection design for customer gateway device failure. Two AWS tunnels through one failed site device do not establish a usable second site path.

Have the network owner identify which failures the actual design tolerates: tunnel, device, power, circuit and upstream connectivity. Do not describe two interfaces on one device as independent without examining their shared failure points. The acceptance record should state a tested failure scope, rather than borrowing the word redundant from a diagram.

Route 53 VPC Resolver documentation describes inbound and outbound endpoints and conditional forwarding for hybrid DNS. Verify the actual direction needed by the application. Reaching an IP address does not establish that the site's normal hostname resolves, and a successful name lookup does not establish application authorization.

Include an expired identity and a renewed identity in the test plan, not only the session that was already open before the interruption. The applicable identity system determines validity and renewal behavior. Reconnection must not require an unapproved local administrator account or broader cloud access. A site that works only with a cached privileged session has not demonstrated its normal operating path.

4. Calculate the local acceptance budget

Consider a fictional site that captures 12 events per minute while its AWS path is unavailable. It has capacity for 300 locally accepted pending events. A permitted interruption lasts 20 minutes, starting with an empty backlog. Assume capture remains possible and those local records survive the stipulated interruption.

The interruption creates 12 × 20 = 240 pending events. That fits the 300-event count limit, leaving 60 places. It does not by itself prove the local device has sufficient storage, write endurance or recovery protection. Those are separate implementation checks against the required local failure conditions.

When the path returns, assume the receiving system can accept 30 events per minute while 12 new events per minute continue to arrive. The net drain is 30 - 12 = 18 events per minute. The steady-rate estimate is 240 / 18 = 13⅓ minutes, or 13 minutes 20 seconds, to empty the backlog. Network restoration at minute 20 therefore does not mean recovery is complete at minute 20.

These are fluid, constant-rate calculations, not a forecast of individual event latency. Real requests have discrete sizes, variable processing times, retries and destination limits. Retain per-operation outcomes when evaluating deadlines or duplicate handling; a net-rate estimate cannot demonstrate that every event met its required age.

The count limit is reached after 300 / 12 = 25 disconnected minutes under these assumptions. A 35-minute outage would present 420 events. With no other accepted destination, at least 120 cannot be admitted into this 300-place buffer. Define the visible stop or alternate approved workflow before that point. Silently dropping them, extending an unbounded queue or presenting false success fails the proposed contract.

5. Accept recovery through business acknowledgements

Record which operation identities were locally accepted, which reached central acceptance, which failed and which remain unresolved. A receiver's durable result should let an authorised retry distinguish already completed work from work still needing delivery. Preserve the result needed for a legitimate repeat without duplicating its business effect.

Agree the ordering rule for operations that affect the same entity. A later correction cannot safely overtake an earlier dispatch if that changes business meaning. Equally, one blocked entity should not indefinitely prevent unrelated work unless that ordering is part of the requirement. Test the selected rule, including a malformed record and a receiver rejection.

If the receiving rate falls to the arrival rate, the backlog no longer shrinks. If it falls below arrivals, the backlog grows after the connection returns. The operator needs a bounded admission or escalation response, not a permanent “recovering” message. Application capacity and local operating procedures belong in the same recovery discussion.

Use the cross-cloud probe playbook when commissioning a permitted route measurement or failure rehearsal. This site record supplies its business requirements and acceptance boundaries. It does not replace the playbook's destination controls, workload limits, retained failures and restoration evidence.

6. Bring one site acceptance record to the migration review

Before scheduling a live move, use synthetic fixtures in an isolated environment to check disconnection, full buffer, lost acknowledgement, local restart and identity renewal. A later site exercise needs approved targets, a site operator, a stop control and an agreed restoration procedure. Do not disconnect the customer's live network simply to complete a worksheet.

For each operation, record its user-visible status, local acceptance point, central result, required identity, dependency owners, interruption limit and recovery deadline. Add the buffer limit, expected arrival/drain basis, reconciliation owner and the exact evidence needed to close outstanding work. A site-level aggregate should not hide one operation that cannot continue safely.

Choose among retaining a local contribution, redesigning the workflow, narrowing the supported interruption or deferring that site. Cloud placement alone does not decide which alternative is suitable. Do not retire the previous path until the accepted operating boundary and post-move recovery are supported by actual observations.

Start with the site's most interruption-sensitive transaction. Ask the site and application owners to agree what the operator may truthfully acknowledge during an outage, then identify the first missing dependency or capacity assumption. A migration review with Ampity can use that record to scope the next bounded assessment.