Claude in Australia: Recheck Residency Before Your Next Rollout

A Sydney application, an Australian account or an “APAC” setting does not, by itself, establish where a Claude request was processed. Before rollout, identify the exact service your application calls, test that route, and connect the request to evidence of its processing destination. Then assess processing separately from stored data, logs, backups, tools and support.

This guide was reviewed against information checked on 30 September 2026. It covers Amazon Bedrock and Claude Platform on AWS as distinct paths. It does not establish a residency setting for the direct Anthropic API. The procedure is designed to help engineering and procurement teams make a traceable deployment decision; it is not legal advice or a conclusion about whether a particular deployment satisfies a law, contract or internal policy.

Prerequisites

Before starting, identify the team accountable for the application route and arrange access to the configuration and evidence needed for the chosen service. You do not need customer data to conduct the initial test. Prepare a synthetic prompt, a test identity authorised to use the route, a separate identity or route that should be denied, and a way to record UTC timestamps and correlation identifiers.

Gather the deployment details that distinguish this implementation from another one: service name, environment, account or tenant reference, endpoint or application route, model selection, inference profile or other applicable control, and the people who can retrieve request-linked evidence. Avoid putting credentials, secrets or real customer content in the worksheet.

If the destination requirement is expressed as “Australia,” clarify what your organisation intends that to mean before testing. For example, is the requirement about the location of inference processing, stored account data, both, or additional categories such as logs and backups? A broad label is not a testable acceptance criterion. Write down the categories and the destination expectation for each one, and flag any category for which the owner cannot yet identify evidence.

For Amazon Bedrock, ensure that an operator can inspect the relevant CloudTrail event for the test request. For Claude Platform on AWS, identify the people who can consult its own service documentation and verify its applicable controls. If you cannot obtain the evidence required for the intended service, record that as an unresolved prerequisite rather than treating the absence of evidence as a pass.

Tip: Keep the first run small. One synthetic request with a known expected response is easier to trace than a batch, and it avoids mixing an application bug with uncertainty about the service route.

flowchart TD
  accTitle: Verify processing location for the actual request route
  accDescr: Identify the service route, send synthetic input, correlate request evidence and check the observed region. Missing evidence leaves residency unresolved.
  A["Identify actual service route"] --> B["Send synthetic test request"]
  B --> C["Correlate request evidence"]
  C --> D{"Approved region demonstrated?"}
  D -->|"Yes"| E["Record processing result"]
  D -->|"No or unknown"| F["Hold and investigate"]

This diagram separates a working request from a verified processing destination. An expected response confirms only that the request returned; the regional decision depends on correlated service evidence. Storage, logging and connected tools require their own checks.

Step 1: Name the exact service path

Start with the call your application actually makes, not the product name used in a slide deck or procurement request. Trace from the application component to the configured endpoint or SDK path, then record the service in plain language. If an intermediary, proxy or internal gateway changes the destination, include it in the route description. The objective is to make clear which service’s settings and evidence apply to this particular request.

“Claude on AWS” can describe distinct offerings. Amazon Bedrock has its own inference configuration and request evidence. Claude Platform on AWS has separate residency controls and documentation. Treat them as different paths and verify each against its own service-specific material; do not use evidence from one as a substitute for the other. Claude Platform on AWS publishes separate residency documentation.

Record enough detail to let another engineer reproduce the path without exposing credentials. A useful description might say: “staging application, service A, account reference ending 42, application gateway route /assist, configured profile reference X.” Use actual internal identifiers in your controlled record, not in a public article or ticket. If a developer can select between routes at runtime, record how the test pins or observes the selected route.

This step catches a common source of false confidence: the platform team checks one configuration while the application sends traffic through another. A diagram may show a Sydney-hosted application, but the request might be routed through a different provider path, account or profile. The evidence package must describe the path responsible for the tested inference, not merely the location of nearby infrastructure.

Step 2: Define the residency question by data category

Residency discussions often combine several different questions. Processing concerns where a request is handled. Storage concerns where account or service data is retained. Logs and backups may have their own destinations and retention arrangements. A connected tool can receive information outside the model request path, while support processes may involve separate access or handling. Do not assume that a setting governing inference answers all of these questions.

Build a category worksheet before interpreting a product setting. For each category, state what information is in scope, the destination the organisation expects, what evidence can support the answer, who owns that evidence and the current status. Use “not verified” when the team has not established an answer. “Not applicable” should include a short reason; it should not be a convenient substitute for investigation.

The table is a working aid, not a claim that every category is controlled by the same mechanism. An inference event can help answer the processing question while leaving storage, backup or support questions open. Keep the scope of each piece of evidence narrow: state precisely what it demonstrates and what remains outside it.

Set an acceptance rule before making the test request. For example: “The request is accepted as a processing-location pass only if it can be matched to evidence identifying a destination on our approved Australian list.” That wording makes a missing event, unclear profile or unexpected destination a defined outcome. It prevents an expected model response from being mistaken for proof about location.

Step 3: Inspect the setting for the chosen path

For Amazon Bedrock, inspect the inference profile actually configured for the request and read its documented routing behaviour. Geographic profiles route within their specified geography; global profiles can route across supported commercial regions. The source region is not proof of the final destination, and APAC is not equivalent to Australia. AWS identifies additionalEventData.inferenceRegion in CloudTrail as a field that can help identify the actual processing region. Check the exact profile and model rather than assuming an Australia-only option exists. Review AWS’s cross-region inference guidance.

Treat a profile label as configuration evidence, not as the end of the investigation. Record the identifier, the environment in which it is configured and the application component that uses it. If a deployment has more than one profile, establish which profile handles the tested request and what happens when the primary route is unavailable. Do not infer a destination from a region name that describes only the calling resource.

For Claude Platform on AWS, use its own documented controls and evidence path. Write down the control as configured, the service and account context, and the evidence that connects the control to the request or deployment. Do not copy a Bedrock result into this record. If the platform team cannot establish how the relevant control applies to the intended route, keep the residency status unresolved and ask the appropriate service or procurement owner to close that gap.

The output of this step should be a short, reviewable configuration note, not a general assurance statement. It should say what was inspected, by whom, when, and which request route it governs. A reviewer should be able to distinguish “we selected a setting intended to constrain routing” from “we observed evidence that this request was processed at an approved destination.” Those are different strengths of evidence.

Step 4: Prepare a controlled request

Use a prompt with no personal, confidential or customer information. For a basic path check, one suitable synthetic input is: Return the text RESIDENCY-TEST-01 exactly. Record the expected output as RESIDENCY-TEST-01. This is a deliberately simple functional check: it helps show that the intended application route returned a response and that the application handled it as expected. It does not establish where the request was processed.

Generate or record a correlation identifier that can be connected to the application log and, where available, the service event. Record the request time in UTC, the deployment environment, the configured service path and the profile or control in use. Keep the raw prompt and response only where your test record requires them; the synthetic marker is usually sufficient to show what was sent and expected.

Run the request through the same application route, credentials and configuration intended for production. A test sent from a developer’s console may be useful for learning, but it does not demonstrate that the deployed application uses the same route. If production traffic can select among routes, document the selection mechanism and show which route handled this test. Avoid changing multiple variables between the test and the proposed production configuration.

Capture the observed output and compare it with the expected value. If the text differs, the response is missing, or the application cannot associate the request with its identifier, record a functional failure and resolve it before interpreting the residency result. Functional success and residency evidence are separate fields in the record; do not collapse them into one green status.

Step 5: Match the request to location evidence

For a Bedrock test, locate the CloudTrail event corresponding to the request and inspect the processing-region evidence, including additionalEventData.inferenceRegion where available. Match the event using the timestamp and the identifiers or other request details your service records make available. Save a reference to the event or a controlled copy consistent with your retention practices, alongside the configuration snapshot and test record.

Compare the observed destination with the organisation’s approved destination list, not with a broad geographic label. If the result identifies an APAC location that is not specifically approved as Australia, it does not meet an Australia-specific acceptance rule. If the event cannot be found, the relevant field is absent, or the evidence cannot be tied confidently to the test request, mark the result unresolved. Do not infer a pass from the application’s AWS region or from the expected response.

For Claude Platform on AWS, apply the evidence method that belongs to that service and its configured control. Record what the service-specific evidence actually establishes and any limits on interpretation. If your team cannot tie the available evidence to the tested route, say so. The aim is not to force every service into the same evidence format; it is to make the basis for each service’s conclusion visible and reviewable.

A useful result has three parts: the configuration that was intended to govern the call, evidence associated with the call or deployment, and a clear comparison against the requirement. A configuration snapshot alone says what the team set. An event alone may be hard to interpret without the route and profile. The comparison turns those materials into a bounded decision: pass, fail or unresolved for the specific question tested.

Step 6: Test the access boundary separately

A location check cannot show whether your application’s access controls work. Run a separate access test through the intended route. First, use the authorised test identity and confirm that it can make the synthetic request. Then attempt the same operation with a deliberately unauthorised identity or route that should be denied under your design. Record the observed result and the control point that rejected it.

The acceptance condition should be explicit. For example, the authorised request succeeds and is traceable, while the unauthorised attempt is rejected before it can complete the model call. If the second attempt succeeds, stop and investigate the access path. If the request is denied but the team cannot tell where it was denied, improve the evidence before relying on the test. This is an application access test; it does not establish how a provider handles information beyond that boundary.

Keep the access outcome distinct from the residency outcome. A request can be processed in an approved location but exposed through an overly broad application route. Conversely, a tightly restricted route does not establish a processing destination. Use separate fields and separate owners if different teams operate the access controls and the service configuration.

Step 7: Work through a hypothetical deployment

Consider a hypothetical Australian retailer preparing to pilot an internal support assistant. The application and its source records are hosted in Sydney. The team’s written requirement says “customer support prompts must be processed in Australia,” but an early design note refers only to “APAC.” The product owner initially treats those phrases as interchangeable. The engineering lead pauses the release and turns the broad statement into a specific processing-location acceptance rule.

The team first traces the live application route and discovers that the staging workload calls Bedrock through a configured inference profile. It records the profile, account context and route, then checks the profile’s documented behaviour. Because the requirement is Australia-specific, the label “APAC” does not settle the question. The team sends the synthetic marker through staging, saves the UTC timestamp and correlation identifier, and finds the corresponding CloudTrail event.

In this hypothetical, the event identifies a destination that the retailer has not approved as Australian. The prompt returns the expected marker, and the application behaves correctly, but the processing-location test fails the written acceptance rule. The team does not describe the result as “mostly compliant” or infer that the Sydney application server fixes it. It pauses this route, asks the service owner to assess an available configuration that meets the stated requirement, and repeats the test only after the route changes.

The team also reviews its other data categories. It identifies the tool that searches support records and records what information the application passes to it. It separately assigns owners to confirm storage, logging, backups and support handling. Those questions do not become verified merely because the model request test has a clear result. The pilot decision is therefore limited: the tested route is not accepted for the stated processing requirement, and the other categories remain open until their own evidence is recorded.

This scenario illustrates why the request result, the location evidence and the broader data inventory need separate fields. It does not establish that a particular profile or alternative is available for every model or account. The decision depends on the service configuration actually available to the team and evidence tied to its own route.

Step 8: Record failures and decide what happens next

Define three outcomes before testing. Pass means the evidence meets the stated acceptance rule for the tested question. Fail means available evidence contradicts the rule, such as a destination outside the approved set. Unresolved means the team lacks enough evidence to determine whether the rule was met. These outcomes make uncertainty visible instead of turning it into an informal exception.

A missing CloudTrail event is not the same as a confirmed out-of-region request, but it is also not a pass. The practical response is to check the time window, account and request correlation, then confirm whether the relevant logging and evidence path is available. If the team still cannot tie the event to the request, retain the unresolved status and do not represent the test as proof of Australian processing.

An unexpected destination calls for a different response. Preserve the configuration and event reference, stop treating the route as approved for the stated requirement, and identify whether the cause is a profile choice, route selection or a misunderstanding of the service behaviour. Change one relevant variable at a time, then rerun the controlled test. Keep the failed result in the record so a later pass does not erase the reason the configuration changed.

A successful location result paired with a failed access test also blocks rollout under a design that requires both conditions. Investigate whether the unauthorised identity reached the application, gateway or model route, and correct the control at the layer responsible. Do not use the residency result to waive an access failure. Likewise, an access denial does not resolve missing evidence about processing location.

For changes that can cause repeated requests or external actions, keep retries and side effects within the design review for that system rather than assuming a location check solves them. The separate treatment of idempotency for long-running agents is relevant when a request path can trigger consequential tool actions. The concern here remains the residency evidence and route decision.

Step 9: Make the record reproducible

A reviewer should be able to understand what was tested without reconstructing a conversation from chat messages. Store the service name, environment, route, account reference, configuration identifier, data categories in scope, test timestamp, correlation identifier, expected and observed output, access-test result, evidence reference and decision. Record the tester and reviewer by role or internal identity according to your recordkeeping practice.

Include a short evidence note for each category: what the material demonstrates, its date, and what it does not demonstrate. For example, a request-linked processing-region event can support the processing decision for that request. It does not, by itself, answer the location of stored account data or backups. This qualification is useful because a screenshot or log excerpt can otherwise be reused later as broader assurance than it supports.

Keep the record near the deployment configuration or in the evidence system your organisation already uses. Avoid a separate spreadsheet that nobody updates unless there is a clear owner and review trigger. If teams need separate AWS accounts to clarify ownership, environment boundaries and evidence responsibility, treat that as an organisational design decision rather than a residency control by itself. AWS describes account separation and ownership as AWS organisational design concerns.

For procurement, connect the technical record to the service and terms being purchased. Ask which exact service path is in scope, what evidence is available for each data category, and which statements apply to that path. The questions in Foundry procurement checks offer a related procurement lens, but do not treat findings about one offering as findings about another.

Step 10: Set recheck triggers

A test becomes less useful when the implementation changes and nobody knows that the old evidence no longer describes the active route. Recheck when the service path, model selection, inference profile, account configuration, application gateway or data-handling design changes. Recheck as well when service documentation or applicable contractual terms change in a way that could affect your recorded conclusion.

Assign an owner to compare the current deployment with the tested configuration. That comparison should ask whether the same route and controls are still in use, whether the evidence mechanism remains available and whether each data category still has an accountable owner. Set the review interval according to the organisation’s change process and risk tolerance rather than inventing a universal schedule.

Use change records to preserve the sequence: prior configuration, reason for change, new configuration, test evidence and decision. If a team rolls back, record whether the prior path was retested or merely restored. A rollback can return an application to an old setting without proving that the setting still behaves as expected or that its evidence remains accessible.

If a production route supports multiple destinations or fallback behaviour, test and document those branches as part of the route design. A successful test of the normal path does not automatically describe what happens during a service disruption. The acceptance rule should identify which fallback outcomes are acceptable, how the application selects them, and what evidence is available to evaluate a request that takes a different branch.

Printable rollout worksheet

Copy this section into your deployment record. Mark a box only when the accompanying evidence is attached or directly referenced. Use “unresolved” rather than leaving a blank when a question has been considered but cannot yet be answered.

Service and scope

• Service path named: Record the precise service, environment, account or tenant reference, endpoint or application route, and any intermediary that can affect routing.
• Route confirmed in the application: Identify how the deployed component selects its service path and how the test confirms that the intended route handled the request.
• Data categories listed: Separate input and output processing, stored account data, logs, backups, tools and support; mark each verified, unresolved or not applicable with a reason.
• Australia-specific requirement stated: Identify the approved destination and clarify which categories the requirement covers.

Configuration and test

• Service-specific control inspected: Record the configured profile or residency control, its context and the documentation or evidence used to interpret it.
• Synthetic request recorded: Save the test prompt, expected response, observed response, UTC time and correlation identifier.
• Location evidence matched: Link the request or deployment to service-specific evidence and compare the identified destination with the approved list.
• Access test completed: Record the authorised test result and the unauthorised attempt, including whether the latter was rejected as intended.
• Failure outcome classified: Mark each issue pass, fail or unresolved; name an owner and next action for every non-pass.

Decision and maintenance

• Decision is bounded: State exactly which question the result answers and which data categories remain open.
• Evidence is reviewable: Store the configuration snapshot, event or other evidence reference, test record, date and responsible roles together.
• Recheck triggers assigned: Name the changes that require a new test and the owner responsible for checking the route after a change.
• Rollout decision recorded: State whether the tested route is accepted, paused or awaiting evidence, and identify who can change that status.

A completed worksheet is useful only if its conclusion matches its evidence. A box marked for processing should point to evidence about processing; it should not rely on a nearby server’s region, a product label or an unrelated service’s result. If evidence is missing, preserve that gap in the decision record.

Summary: make the claim no broader than the test

The practical sequence is to name the service path, define the data categories, inspect that service’s own controls, run a synthetic request through the intended application route, and match it to appropriate evidence. Test access separately. Record pass, fail or unresolved against explicit criteria, then recheck when the route or relevant configuration changes.

The central discipline is to keep claims bounded. A Sydney deployment is not proof of Australian inference. A response that matches the expected text is not proof of location. A processing-region result does not answer every storage, log, backup, tool or support question. For a separate Azure architecture, use the relevant Foundry procurement and runtime boundaries and gather evidence for that design rather than transferring an AWS result.

Treat the record as an operational decision aid, not a permanent certificate. Reliability measures should describe completed work and the evidence available for it; the distinct topic of AI agent SLOs addresses that broader measurement problem. For the rollout decision, keep the immediate question narrow: can this specific route meet the stated Australian residency requirement, and can the team show why?

If your organisation needs help translating a residency requirement into service boundaries, repeatable tests and a maintainable platform record, Platform Design & Engineering is an appropriate next step. The final decision should remain specific to the service, configuration, evidence and terms your organisation has actually reviewed.

WANT TO TALK THROUGH YOUR SITUATION?

Talk it through with us. Thirty minutes, no slides.