An application can be deployed to a zone, which is a combination of an environment and a region. This lists all the zones which can be deployed to manually (dev and perf), deployed to in production using deployment.xml (prod), or which is implicitly used to verify prod deployments (test and staging):

dev aws-us-east-1c
perf aws-us-east-1c
test aws-us-east-1c
prod aws-us-east-1c
prod aws-us-west-2a
prod aws-eu-west-1a
prod aws-ap-northeast-1a

If your deployment requires zones not listed here, contact us to have it made available.

If the application application requires zone-specific configuration, use environment and region variants.

Routing control

Vespa Cloud has two mechanisms for manually controlling routing of requests to a zone:

  • Endpoint configuration. This is changed by updating deployment.xml and redeploying
  • The application API

The example below describes the latter mechanism.

Inspect current routing status

With a tenant name foo and an application named bar, the routing status for the default instance of the application in zone can inspected at the following path:

$ curl | jq .
  "deployments": [
      "routingMethod": "exclusive",
      "instance": "foo:bar:default",
      "environment": "prod",
      "region": "aws-us-east-1c",
      "status": "in",
      "agent": "system",
      "changedAt": 0

In this particular example, the status of zone is in and the zone should be receiving requests.

Set zone out

In case of a production emergency, a zone can be manully set out to prevent it from receiving requests:

$ curl -XPOST | jq .
  "message": "Set global routing status for in to OUT"

Inspecting the status will now show the status set to out.

Set zone in

To set the zone back in and have it continue receiving requests:

$ curl -XDELETE | jq .
  "message": "Set global routing status for in to IN"