TelekomCLOUD for Business Customers

< Back to specifications

Elastic Cloud Server (ECS)

Virtual machines according to your demand

Via elastic cloud servers, the Open Telekom Cloud provides virtual machines (VM) in a total of nine performance classes. The performance classes address specific usage scenarios: graphic applications, virtual workplace systems, big data applications, high-performance scenario, or even SAP. In addition, there are four generic performance classes with different vCPU/RAM ratios. This results in more than 60¬†flavors ‚Äď with a bandwidth of up to 36¬†vCPUs and up to 940¬†GB of RAM. Each virtual machine requires a system disk and an operating system for the flavor. Up to 40¬†storage volumes can be attached to an ECS.

The two tables below show in which specifications Elastic Cloud Servers are available. Each of these virtual machines can be provisioned up to 500 times within one Open Telekom Cloud booking. The different flavors (combinations of virtualized hardware components) address different application scenarios. By installing operating systems, the complete virtual machines (VM) are created.

Resources for the flavors are provided from virtualized hardware pools. KVM and Xen are used for virtualization. From November 2017 onwards, the basic flavors will also be made available on KVM as hypervisor. In addition to the cluster for standard flavors, additional clusters are provided for disk-intensive, memory-intensive, and GPU instances.

Basic flavors

The four basic flavors offer ratios of 1:1, 1:2, 1:4, and 1:8 for vCPUs to RAM. An appropriate flavor can be selected depending on the requirements of the applications or the application scenario for RAM. The general purpose (s1) servers with a ratio of 1:4 handle a large number of standard scenarios, while the lower-cost Compute-I- (c1) and Compute-II- (c2) instances can be used with less RAM dependency. In case of high RAM dependency (e.g., for databases), the Memory Optimized Flavor (m1) is available. All ECS with basic flavors use Intel¬ģ Xeon¬ģ E5-2658A v3 processors (30MByte cache, 2.20¬†GHz).

Elastic Cloud Servers support horizontal and vertical scaling. This means that you can change the type of a booked virtual machine at any time (e.g., for changing from GP1 to GP5) or you can raise or lower the number of Elastic Cloud Servers manually or based on rules (via the OpenStack APIs).

All flavors can use the SATA, SAS, and SSD disk options. In order to use an Elastic Cloud Server, a block storage (Elastic Volume Service) is always required to provide the operating system.

 Compute ICompute IIGeneral PurposeMemory Optimized
vCPURAM (GB)RAM (GB)RAM (GB)RAM (GB)
11448
224816
4481632
88163264
16163264128
323264128-
60-128256512

Advanced Flavors

In addition to the basic flavors, the Open Telekom Cloud offers six more flavor classes designed for specific applications: high performance (HP), GPU optimized (GP), disk-intensive (DI), large memory (LM), and workspace (WP) and Field Programmable Arrays (FPGA). The specific workspace flavors are only available as a complete workspace service. The advanced flavors usually use Intel¬ģ Xeon¬ģ E5-2690 v3 processors (30MByte cache, 2.60 GHz).

 High PerformanceGPUWorkspaceDisk-intensiveLarge MemoryFPGA
vCPURAM (GB) + additional resourcesRAM (GB) + additional resourcesRAM (GB) + additional resourcesRAM (GB) + additional resourcesRAM (GB) + additional resources 
24, 8, 16 4   
48, 16, 328 + vGPU8 (+1 vGPU)****

32 + 3,6 TB

32 + 5,4 TB

128 
6  16   
816, 32. 6416 + vGPU, 64+GPU, 64 + GPU** (pass trough)16 + vGPU

64 + 7,2 TB

64 + 10,8 TB

128/ 256

88 + Xilinux

VU9P

12128**, 256**   256 
1632, 64, 128, 128*, 256*128 + 2 GPU*** 

128 + 14,4 TB

128 + 21,6 TB

470 
18    445 
    192 + 21,6 TB  
3264, 128, 256, 256*256 + 4 GPU*** 256 + 28,8 TB940 
36   256 + 43,2 TB890 
    540 + 43,2 TB  

* with InfiniBand/KVM
** NVidia M60 (KVM)
*** NVidia P100 (KVM)
**** vGPU optional

High Performance servers address high-performance scenarios, e.g., for particle physics, engineering sciences, or simulation/modeling. The ordered CPUs are not shared with other users for the duration of the order, which guarantees full performance over the entire period of use. Two of these flavors use Infiniband (16 vCPU with 128 GB RAM and 256 GB RAM) as network technology. 

For GPU-optimized flavors, a virtual graphics chip is added to the base resources. The virtualized graphics CPU pool is based on NVidia M60 cards. These flavors are particularly suitable for all applications that need to process images and moving images. Such instances are also generally used for cryptographic applications. Three flavors (8, 16, 32 vCPU) use GPU pass-through. All 2048 signal processors are used by one, two or four GPUs for a unique performance experience.

For disk-intensive flavors, local disks are added to the base resources. Instances of 1.8 TB disk space from a special pool are provided. By default, SR-IOV (Single Root I/O Virtualization) is used to achieve a bandwidth of 10 GB. These flavors are used when large amounts of data have to be transferred and processed, for example in big data analyses with a focus on Hadoop/MapReduce.

Large memory flavors address in-memory/SAP HANA scenarios. Extensive RAM resources of up to 940¬†TB are provided, as the data is processed in RAM during in-memory computing. Massive Memory Flavors use Intel¬ģ Xeon¬ģ E7-8880 processes. Here too, SR-IOV (Single Root I/O Virtualization) is used as standard.

With the FPGA flavor, the Open Telekom Cloud offers a server type that achieves immense performance gains for special application scenarios with hardware-related programming. Currently the FPGA flavor is available in a beta mode for interested users.

More information on the workspace Flavors is available under Workspace Service in the Services section. 

The ECS service is offered in three different price models: the Elastic model is charged on an hourly basis, with the Reserved model, the user books VMs for at least 12 months and receives a discount. In the simple Reserved model, the user pays fixed monthly installments, with payment of the full amount in advance (Reserved Upfront), he receives an additional discount.

ECS Elastic

Elastic instances can be ordered and canceled as required. Billing takes place on a per-hour basis. Only the time in which the ordered instances are active (i.e., have the status "Running") is billed. The first hour counts from one minute of use. The displayed prices are the hourly rate of the respective instance.

We recommend the elastic instances in particular because of their flexibility for test environments in which the function and dimensioning of a live environment can be estimated or new versions can be checked. They are also suitable as a short-term extension of an environment to absorb peak loads.

Sample calculation ECS Elastic 

  • You start a general purpose ECS instance with 4 vCPU and 16 GB RAM on January 1 at 12 noon.
  • You start a second instance of the same type on January 5 at 12 noon.
  • Both instances run until 12 noon on January 10 and are then stopped.
  • For the first instance, 12 hours will be charged on January 1, 8 x 24 hours from January 2 to 9, and 12 hours on January 10, i.e., a total of 216 hours.
  • For the second instance, 12 hours are charged for January 5 and 10 each, and 4 x 24 hours for January 6 to 9, a total of 120 hours.
  • As both instances are of the same type, they appear as a single item on the bill, in this example 336 hours of the "General Purpose, 4vCPU, 16 GB RAM" instance type.
Type of instanceStartFinishTotal
1. Elastic General Purpose (4v CPU, 16 GB)1. January, 12 noon10. January, 12 noon216 hours
2. Elastic General Purpose (4vCPU, 16 GB)5. January, 12 noon10. January, 12 noon120 hours
   336 hours in total

ECS Reserved

Reserved instances can be reserved for a period of 12, 24, or 36 months. They are not fixed to a specific instance, but only to the type of instance, and are billed even if the instance is inactive.

We recommend that you use the reserved instances for application scenarios in which a system is operated with similar load over a long period of time, for example for a webshop.

A fixed amount is settled monthly, which does not change with price adjustments. The longer the chosen reservation period, the cheaper the monthly rates will be. During the first three months, it is possible to upgrade to larger instance types. The binding is extended by the months that have passed and the corresponding price for the reservation is due. The available allowance corresponds to the length of the respective month (days x 24 hours).

Sample calculation for ECS Reserved

  • January:¬†you configure a general purpose instance in the Open Telekom Cloud and use it continuously from January¬†1. From January¬†15, you order a reserved package for this instance type, which is valid from January¬†15.
  • February:¬†at midnight on February¬†1, a second instance of the same type is started to absorb a spike in utilization. This is then stopped again together with the first instance after precisely 10¬†days (=240¬†hours x 2). At midnight on February¬†21, the first instance is started up again (192¬†hours).
  • March:¬†the current instance is shut down on March¬†29th.
UsageJanuaryFebruary (28 days)March
Reserved408 hours672 hours744 hours
Used744 hours672 hours696 hours
Billed (Reserved + Elastic)408 + 336 hours672 + 0 Stunden744 + n0 hours

ECS Reserved Upfront

Reserved Upfront instances are the most attractive in terms of price. They can be ordered for 12, 24, or 36 months. A fixed amount is calculated at the beginning of the term. It is not possible to switch to a larger instance within the first three months. In the subsequent months, the Reserved Upfront instances are also shown on the bill as a Reserved Upfront package, without being charged for.

Sample calculation for ECS Reserved Upfront

  • January:¬†you configure a general purpose instance in the Open Telekom Cloud and use it continuously from January¬†1. From January¬†15, you order a Reserved Upfront package for this instance type, which is valid from January¬†15.
  • February:¬†at midnight on February¬†1, a second instance of the same type is started to absorb a spike in utilization. This is then stopped again, with the first, after precisely 10 days. On February¬†20, the first instance is started up again.
  • March:¬†the current instance is shut down on March¬†29th.
UsageJanuaryFebruary (28 days)March
Reserved408 hours672 hours744 hours
Used744 hours672 hours696 hours
Billed (Reserved + Elastic)8.760 + 366 hours+ 0 hours+ 0 hours

Please note:

  • These examples are valid for all¬†ECS types.
  • If the autoscaler is used to start or stop instances, then this is charged as if it had been manually started.
  • Metering of consumption stops the moment the instance is no longer active, i.e., when the status is "stopped." It does not have to be deleted from the console.
  • After the end of the Reserved Upfront runtime, the system calculates the amount according to Elastic again.
  • If the Elastic¬†Volume Storage (EVS) associated with the instance is not deleted, it is still charged for a stopped instance.