Deploying Pexip Infinity on Amazon Web Services (AWS)

The Amazon Elastic Compute Cloud (Amazon EC2) service provides scalable computing capacity in the Amazon Web Services (AWS) cloud. Using AWS eliminates your need to invest in hardware up front, so you can deploy Pexip Infinity even faster.

You can use AWS to launch as many or as few virtual servers as you need, and use those virtual servers to host a Pexip Infinity Management Node and as many Conferencing Nodes as required for your Pexip Infinity platform.

AWS enables you to scale up or down to handle changes in requirements or spikes in conferencing requirements. You can also use the AWS APIs and the Pexip Infinity management API to monitor usage and bring up / tear down Conferencing Nodes as required to meet conferencing demand, or allow Pexip Infinity to handle this automatically for you via its dynamic bursting capabilities.

Pexip publishes Amazon Machine Images (AMIs) for the Pexip Infinity Management Node and Conferencing Nodes. These AMIs may be used to launch instances of each node type as required.

This flowchart provides an overview of the basic steps involved in deploying the Pexip Infinity platform on AWS:

Deployment options

There are three main deployment options for your Pexip Infinity platform when using the AWS cloud:

  • Private cloud: all nodes are deployed within an AWS Virtual Private Cloud (VPC). Private addressing is used for all nodes and connectivity is achieved by configuring a VPN tunnel between the corporate network and the AWS VPC. As all nodes are private, this is equivalent to an on-premises deployment which is only available to users internal to the organization.
  • Public cloud: all nodes are deployed within the AWS VPC. All nodes have a private address but, in addition, public IP addresses are allocated to each node. The node's private addresses are only used for inter-node communications. Each node's public address is then configured on the relevant node as a static NAT address. Access to the nodes is permitted from the public internet, or a restricted subset of networks, as required. Any systems or endpoints that will send signaling and media traffic to those Pexip Infinity nodes must send that traffic to the public address of those nodes. If you have internal systems or endpoints communicating with those nodes, you must ensure that your local network allows such routing.
  • Hybrid cloud: the Management Node, and optionally some Conferencing Nodes, are deployed in the corporate network. A VPN tunnel is created between the corporate network and the AWS VPC. Additional Conferencing Nodes are deployed in the AWS VPC and are managed from the on-premises Management Node. The AWS-hosted Conferencing Nodes can be either internally-facing, privately-addressed (private cloud) nodes; or externally-facing, publicly-addressed (public cloud) nodes; or a combination of private and public nodes (where the private nodes are in a different Pexip Infinity system location to the public nodes). You may also want to consider dynamic bursting, where the AWS-hosted Conferencing Nodes are only started up and used when you have reached capacity on your on-premises nodes.

Private, public and hybrid cloud deployment options

All of the Pexip nodes that you deploy in the cloud are completely dedicated to running the Pexip Infinity platform— you maintain full data ownership and control of those nodes.

Limitations

The following limitations currently apply:

  • Pexip Infinity node instances that are hosted on AWS can be deployed in one or many regions within AWS. However, if you deploy nodes across multiple AWS regions, it is your responsibility to ensure that there is a routable network between the AWS data centers, so that inter-node communication between the Management Node and all of its associated Conferencing Nodes can succeed. Pexip is unable to provide support in setting this AWS network up.

    Each AWS region contains multiple Availability Zones. A Pexip Infinity system location is equivalent to an AWS Availability Zone.

    Note that service providers may deploy multiple independent Pexip Infinity platforms in any AWS location (subject to your licensing agreement).

  • SSH access to AWS-hosted Pexip Infinity nodes requires key-based authentication. (Password-based authentication is considered insufficiently secure for use in the AWS environment and is not permitted.) An SSH key pair must be assigned to each instance at launch time. You can create key pairs in AWS via the EC2 Dashboard Key Pairs option, within the AWS account used to launch the Pexip Infinity instances, or use third-party tools such as PuTTYgen to generate a key pair and then import the public key into AWS.

    Note that:

    • When the Management Node has been deployed, you can assign and use your own SSH keys for the Management Node and any Conferencing Nodes — see Configuring SSH authorized keys for details.
    • If you are using a Linux or Mac SSH client to access your instance you must use the chmod command to make sure that your private key file on your local client (SSH private keys are never uploaded) is not publicly viewable. For example, if the name of your private key file is my-key-pair.pem, use the following command: chmod 400 /path/my-key-pair.pem

    See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html for more information about creating a key pair.

  • We do not support AWS deployments in China.

Recommended instance types and call capacity guidelines

AWS instances come in many different sizes. In general, Pexip Infinity Conferencing Nodes should be considered compute intensive and Management Nodes reflect a more general-purpose workload. Our Server design recommendations also apply to cloud-based deployments.

For deployments of up to 30 Conferencing Nodes, we recommend using:

  • Management Node: an m5.xlarge instance.
  • Transcoding Conferencing Nodes: a c5.2xlarge instance.
  • Proxying Edge Nodes: either c5.xlarge or c5.2xlarge.

This should provide capacity for approximately 17 HD / 39 SD / 324 audio-only calls per Transcoding Conferencing Node.

Larger instance types may also be used for a Transcoding Conferencing Node, but the call capacity does not increase linearly so these may not represent the best value. However, we recommend that you do not use c5 or c4 instances with 36 vCPU or higher.

Note that you can switch between c4 and c5 AWS instance families for existing VMs. To do this you must power down the VM, change its family, and then power the VM on again.

Dedicated versus standard instances

Within AWS you can select dedicated or standard instances:

  • We recommend that each Conferencing Node instance is run as a dedicated instance (tenancy). This is to avoid oversubscription of Conferencing Nodes, which can lead to calls dropping and media quality problems.
  • We also recommend that the Management Node is run as a dedicated instance. However, small and medium deployments supporting up to approximately 100 concurrent calls could use a standard instance for the Management Node provided there is no significant use of the management API.
  • If the platform is solely used for One-Touch Join (OTJ) then you can use standard instances for both the Management Node and Conferencing Nodes.

IP addressing

Within a VPC, an instance's private IP addresses can initially be allocated dynamically (using DHCP) or statically. However, after the private IP address has been assigned to the instance it remains fixed and associated with that instance until the instance is terminated. The allocated IP address is displayed in the AWS management console.

Public IP addresses may be associated with an instance dynamically (at launch/start time) or statically through use of an Elastic IP. Dynamic public IP addresses do not remain associated with an instance if it is stopped — and thus it will receive a new public IP address when it is next started.

Pexip Infinity nodes must always be configured with the private IP address associated with its instance, as it is used for all internal communication between nodes. To associate an instance's public IP address with the node, configure that public IP address as the node's Static NAT address (via Platform > Conferencing Nodes).

Assumptions and prerequisites

The deployment instructions assume that within AWS you have already:

  • signed up for AWS and created a user account, administrator groups etc
  • created a Virtual Private Cloud network and subnet
  • configured a VPN tunnel from the corporate/management network to the VPC
  • created or imported an SSH key pair to associate with your VPC instances
  • created a security group (see Configuring AWS security groups for port requirements)
  • decided in which AWS region to deploy your Pexip Infinity platform (these guidelines assume that all Pexip Infinity node instances that are hosted on AWS are deployed in the same AWS region).

For more information on setting up your AWS environment, see http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html.

Next steps

To deploy and manage your Pexip Infinity platform nodes see: