Skip to main content
Skip table of contents

Prerequisites to deploying in AWS


This article outlines the prerequisites for deployment of the Delphix Engine on AWS. The setup user should have experience launching and configuring instances in the Amazon Web Services environment. Review and complete the tasks in the next section before deployment.


  1. Review Checklist of information required for installation and configuration.

  2. Make sure that the Amazon account being used to deploy the Delphix Engine has an appropriate level of enablement to subscribe to the Delphix Engine for AWS subscription.

  3. Determine which virtual private cloud (VPC) is being used when launching the virtualization instance. To maximize performance, deploy the Delphix Engine instance in the same VPC/subnet in which the virtual databases (VDBs) will be created.

    1. Provisioning a VDB requires a compute instance running the same database engine as the source. Please note, however, that the target instance only needs storage to accommodate the OS, database platform binaries, etc., because Delphix delivers all of the data files.

  4. Make sure that the necessary ports are open.

    1. Using the Delphix Engine for AWS will require connections to source and target database servers. Such connections require various ports to be open, enabling communications. For a detailed list of the network and port requirements, click the link that corresponds with the relevant database platform:

      1. Network and connectivity requirements for oracle environments

      2. Network access requirements for SQL server environments

      3. Network and connectivity requirements for SAP ASE base environments

      4. Network and connectivity requirements for Db2 environments

  5. Update Security Group settings to accommodate the necessary connections.

    1. Select the same Security Group that the current (or future) non-production EC2 compute nodes utilize.

    2. Modify the Security Group to allow access to all of the networking ports used by the Delphix Engine and the various source and target platforms. See links above for information about specific port configurations.

  6. Allocate storage.

    1. To properly size the initial storage capacity and determine the number and size of EBS Provisioned IOPs Volumes required, download and utilize the Delphix-dynamic-data-platform-storage-calculator.

      It is helpful to first create a list of the data sources intended for making dSources. A data source is typically a production database linked to the Virtualization Engine, enabling to create virtual, full, read-write copies of the source within minutes. The list should include the database name, platform (for example, Oracle or SQL Server), current size (in GB), the estimated number of virtual copies, and retention period (in days) of snapshots (backup copies).

    2. All data storage volumes must be EBS volumes. Delphix recommends using a minimum total of four disks to run the Delphix Engine. One disk is used for the boot device. The other four equally sized disks will be used for data storage. This also enables the Delphix Engine to achieve higher I/O rates by queueing more I/O operations to its storage.

    3. Provisioned IOPs EBS volumes are highly recommended.

  7. During the Manual Deployment option, use the guidelines outlined in Virtual machine requirements for AWS EC2 platform.

Geographic distribution in regions and availability zones

The latency will be directly related to not just the Availability Zone configuration, but more specifically the geographies of those zones. The latencies can vary from tens to hundreds of milliseconds if the zones are geographically diverse (US West to US East would certainly be expected to perform better than US West to Europe). AWS advertises that all AZs in a given region are interconnected with high-bandwidth and low-latency networking per this AWS article.

Applications that are performance-sensitive will benefit from colocating the target servers and Engine in the same region if possible. Another possibility is building a failover strategy for those highly sensitive servers, enabling them to failover to another AZ in the instance where an Engine needs to be failed over. The architecture selected and geographies will also naturally be dependent on your redundancy requirements (your organization may require geographically diverse failover options beyond the ~60 miles advertised within a region).

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.