The Panda Kaltura AWS Cluster – The Virtual Private Cloud, Security and Elastic Load Balancing

Virtual Private Cloud

Amazon Virtual Private Cloud (VPC) is a service that enables you to define a virtual network and launch AWS resources into it.

In our Kaltura AWS cluster we use a VPC with private and public subnets. The private networks include the Kaltura instances which should not be accessible from outside the private network: the database server, NFS instance, batch instances. The instances in the public subnet can send and receive inbound traffic directly from the Internet, whereas the instances in the private subnet can’t. Instead, the instances in the private subnet can access the Internet by using a network address translation (NAT) instance which you must launch into the public subnet.

The VPC operates much like a traditional network. It is logically isolated from other virtual networks in the AWS cloud. The VPC can be configured: you can select its IP address range, create subnets, and configure route tables, network gateways, and security settings.

To protect the AWS resources in each subnet, you can use multiple layers of security, including security groups and network access control lists (ACL).

  • Security groups—Act as a firewall for associated Amazon EC2 instances, controlling both inbound and outbound traffic at the instance level. Supports allow rules only.
  • Network access control lists (ACLs)—Act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level. Support allow and deny rules.

Each instance that you launch into a default subnet has a private IP address and a public IP address. These instances can communicate with the Internet through an Internet gateway. An Internet gateway allows your instances to connect to the Internet through the Amazon EC2 network edge. Your default VPC includes an Internet gateway.


There’s no additional charge for using Amazon VPC. You pay the standard rates for the instances and other Amazon EC2 features that you use. Note: you will be billed for instance hours for the NAT instance set up for you when creating a VPC.

Elastic Load Balancing

In our Kaltura AWS cluster, we use a load balancer for the Kaltura API servers. Each load balancer has a unique Domain Name System (DNS) name. For example, if you create a load balancer named myLB in the US East (Northern Virginia) Region, your load balancer might have a DNS name such as You should point your Kaltura domain, for example to the load balancer which handles the API instances using a CNAME record.

Elastic Load Balancing automatically distributes incoming web traffic across multiple Amazon Elastic Compute Cloud (Amazon EC2) instances. Many EC2 instances can be associated with a load balancer. This provides the following benefits:

Monitoring: The load balancer monitors the traffic to those instances. If one of them fails, it routes the traffic to the other instances. When the instance will be restored, traffic will flow to it again.

Durability: Provide robustness to your service, as the instances behind the load balancer can be spread across multiple availability zones. Instances behind a single load balancer cannot span regions however.

Encryption: The ability to take over the encryption and decryption work from the Amazon EC2 instances, and manage it centrally on the load balancer.

Stickiness: Support for the sticky session feature, which is the ability to “stick” user sessions to specific Amazon EC2 instances.

Single domain name: Because the load balancer is the only computer that is exposed to the Internet, you don’t have to create and manage public domain names for the instances that the load balancer manages.

When used in an Amazon Virtual Private Cloud (Amazon VPC), support for creation and management of security groups associated with your load balancer to provide additional networking and security options.

Using Auto Scaling with Elastic Load Balancing makes it easy to increase or decrease your back-end capacity to meet varying traffic levels. For example, you could set a condition declaring that when the number of healthy instances behind a load balancer goes down to two, two or more instances are launched.


The service is, as with all AWS services, pay per use. You pay for each hour or portion of an hour that the service is running, and you pay for each gigabyte of data that is transferred through your load balancer.

More pricing information can be found here: Elastic Load Balancing Pricing.