Choose the AWS region before selling a cluster through PD AWS Neptune. The region determines where the customer’s cluster runs and affects application latency, available instance classes and engine versions. A database near the application still needs an appropriate private network path.

Review the deployment location

1. Identify where the application that will use Neptune runs.
2. Open the package’s Module settings and review Region.
3. Check the proposed instance plan and engine version for that region.
4. Ask the AWS administrator to confirm the region’s VPC, subnet and account prerequisites.
5. Save the defaults and review the actual accepted order or service selections before provisioning.

The module uses the region’s default VPC when arranging its dedicated firewall group. An AWS region shown in a selector is not proof that the account has the required network, capacity or permissions there. It also does not establish that every displayed plan and engine version can be ordered together.

Keep the connection test in context

The module-panel connection test uses its own default test region and first active account. Passing it does not verify creation in the region selected on this package. Check the offering’s saved account association separately.

Plan a move deliberately

Changing a package default does not migrate an existing Neptune cluster or its data. Keep the original application connection and resource intact while the AWS administrator plans a destination, data transfer and cutover. Record the source and destination separately and establish how the destination will be managed before changing the original service or retiring its resources. Another creation request does not move the graph or attach a separately restored cluster. See private-network planning for connectivity prerequisites.

See the PD AWS Neptune Blesta guide for related tasks, or explore PD AWS Neptune.