Providing a high quality Cloud service is impossible without providing a sufficient range of tools that allow to manipulate networking settings within the created Cloud infrastructures. EPAM Cloud includes a number of solutions that cover both connection and security aspects of the subject
- Cloud Computing Service (C2S)
- Cloud Networking Service (CNS)
- Cloud Block Storage Service (CBS)
- Infrastructure Scheduling Service (CRON)
- Cloud Identity Service (SSH)
- FTP to AWS S3 Service (FTP2S3)
- Auto Configuration Service (ACS)
- Cloud Monitoring Service (CMS)
- Cloud Formation Service (CFS)
- Log Aggregation Service (LAS)
- Load Balancer Service (LBS)
- Relational Database Service (RDB)
- Docker Service (DOS)
- Kubernetes as a Service (KUB)
- Hybris as a Service (HAS)
- Magento as a Service (MAS)
- ATG as a Service (ATG)
- Jenkins as a Service (JaS)
- Gerrit as a Service (GAS)
- Sonar as a Service (SQS)
- Artifactory as a Service (AFS)
- Adobe AEM as a Service (AEM)
- Sitecore as a Service (SAS)
- Hadoop Data Platform (HDP)
- Messaging Service (MES)
- Ambari Service (AAS)
- Splunk as a Service (SPS)
- Cloud Support Service (CSS)
Cloud Networking Service (CNS)
This topic contains the following sections:
Have a Question?
The current page gives the general information on the service and the main workflows. However, while working with the services, our users encounter new questions they need assistance with. The most frequently asked questions on EPAM Cloud Services are gathered on the Cloud Services FAQ page. Visit the page to check whether we have a ready answer for your question.
Working with VLANs
By default, all the VMs run in EPAM regions are created in a default VLAN (Virtual Local Area Network). This gathers them within internal EPAM network and makes them inaccessible from Internet.
However, there is an opportunity to put your project VMs in a specific VLAN that can be created by request to the Help Desk. Typically, the need arises when it is necessary to apply additional security measures to the data stored on the VMs.
Each project has access to specific VLANs that were assigned to it. To see the list of the VLANs available for the project in a specific region, run the or2-describe-vlans (or2dvlans) command:
or2dvlans -p project -r region
To move a VM to a VLAN, use the or2-move-instance-to-vlan (or2mivlan) command:
or2mivlan -p project -r region -i instance_id -v vlan_id
A VM that was moved to a non-default VLAN, cannot be returned.
Related CLI Commands
The table below provides the list of service-related commands and their descriptions:
|or2-describe-vlans||or2dvlans||Describes the VLANs available for the project|
|or2-move-instance-to-vlan||or2mivlan||Moves a VM to the specified VLAN|
|or2-allocate-static-ip||or2alsip||Allocates a static IP to the project|
|or2-associate-static-ip||or2assip||Associates a static IP with the specified instance|
|or2-describe-static-ips||or2dsip||Describes static IPs available for the project|
|or2-disassociate-static-ip||or2dissip||Disassociates a static IP from a VM|
|or2-release-static-ip||or2relsip||Removes the specified IP from the project pool|
Further on this page, you can find the examples of the commands usage for network manipulations.
Demilitarized Zones (DMZ)
By default, the VMs in EPAM Cloud, are not accessible for external connections. However, there is often a need to provide access to these VMs from outside EPAM network.To arrange the access, the users submit the Expose Server to Internet request on EPAM Service Portal.
After the request is submitted, the Security team performs a number of checks on the VM and places the VM to the DMZ. After that, the external access to the VM is allowed.
Still, the VM description details (retrieved by or2-describe-instances command) won't include the VMs external IP. The connection details will be given to the VM's owner via email.
As the VMs in EPAM Cloud by default are not accessible from Internet, they do not have a public IP, and have only the private one. As it was mentioned above, the public IP is granted to a VM during the exposure to internet, but the information on this IP is given only to the VM owner and cannot be retrieved by Orchestration tools
AWS and Azure instances have both public and private IP addresses by default.
Both Public and Private IPs can change when the VM is stopped and then started again. This is a normal behaviour for resources hosted in Cloud. However, it may cause issues when one needs to have a static IP address to connect to their VM.
To solve this issue, EPAM Cloud provides the possibility to get static IPs for your VMs in EPAM and AWS regions (the feature is not available in Azure).
The process consists of two common steps:
- Allocating a static IP for the specific project in the given region
- Assigning the static IP to the given VM
Please note that the commands related to Static IPs manipulation have different effect for AWS and EPAM-based infrastructure. In AWS, they deal with public IPs, and the manipulations do not need the VM to have any specific state. In EPAM Cloud, these commands deal with private IPs, and you will have to stop your VM before initiating any IP changes.
The general flow for getting a static IP for your VM is quite simple: first, you allocate a static IP to your project, and then you associate one of the allocated and free Static IPs with the VMs on this project:
Below, you can see the examples of static-ip related commands usage:
Allocates a random static IP for a project:
or2alsip -p project -r region
To allocate a specific static IP to your project, you can use the -f, --fixed-ip flag followed by an IP to be allocated:
or2alsip -p project -r region -f address
Assigns a static IP to a VM:
or2assip -p project -r region -i instance_id -a address
Describes static IPs available for the project:
or2dsip -p project -r region
Disassociates a static IP from a VM:
or2dissip -p project -r region -a address
Removes the specified IP from the project pool:
or2relsip -p project -r region -a address
All commands used for static IP management are not available in the EPAM-MSQ3 region.
Security Groups is an Amazon solution that provides virtual firewalls to control traffic for the instances within one group or another. When you run a VM in AWS (either via Amazon Management Console or EPAM Orchestration tools), you can associate one or several security groups with this VM.
It is possible to update security group rules at any time. To do it, you need to get access to AWS management console by calling the or2-aws-management-console (or2awsmc) command:
or2awsmc -p project
When you call the command, Orchestrator generates a temporary access URL and sends it to your e-mail
For more details on AWS security groups, please visit this page.
The more detailed information on networking manipulation commands can be found in the Maestro CLI User Guide
Providing the tools that allow controlling the access to the VMs in Cloud is not the full scope of measures taken to ensure sufficient network security in Cloud. There is also a number of network security checks performed automatically and monitored by the Cloud Support team.
- Cloud Trail Service was activated for all AWS accounts. The service monitors all API calls that are performed in AWS. This information can be used to solve different troubleshooting tasks. Currently, the service helps to detect the moments when VMs change their security group from Default to 0.0.0.0/0 and become available via Internet. The service activates special software that checks each VM where the change is detected. The information on the changes is sent to a special report. Once in a month, all the VMs in 0.0.0.0/0 group are re-scanned.
- For EPC-based instances, there is a procedure of monthly scanning the VMs in DMZ - those that are in a high risk zone, because they are exposed to Internet and can be accessed from outside EPAM network.