Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

This is what we do in the implementation phase:

Set up remote access to the customer's Amazon EC2 instance

WSO2 does all the Managed Cloud deployments in an Amazon Virtual Private Cloud (Amazon VPC). A VPC enables you to launch Amazon Web Services (AWS) into a virtual network that you define. A VPC improves the security of your data by providing network-level control and isolation for the AWS. You can keep your data and configurations in a private space and expose them through the DMZ. This virtual network closely resembles a traditional network but with improved security and scalability. 

We access the customer's Amazon EC2 instance over SSH only, with a Bastion host working as the SSH gateway. The Bastian host can either reside in the VPC or in the customer's data center as depicted in the diagram below:

  • The Bastian host in the VPC:  The Bastion host is in the public subnet and allows SSH traffic only to the WSO2 network via a non-standard port. All other hosts are configured to accept SSH requests from the Bastion host only.
    Image Removed 

Set up a domain name system (DNS)

The Domain Name System (DNS) is a server that translates domain names, which are alphanumeric and can be easily remembered by humans, to numerical IP addresses that are recognized by the Internet. The DNS is the Internet's primary directory service that determines which physical server a request should be routed to, when a visitor calls a domain name over the Internet.

For the servers in the customer's data center to connect to the virtual machines in the Amazon VPC, we need the domain-name-to-IP mappings set up in a DNS server. Customers can either use their own DNS servers for this, or allow WSO2 to use the Amazon Route53 service, as depicted in the diagrams below:

    • The DNS in the VPC: WSO2 uses an Amazon Route53 instance to maintain the domain-name-to-IP mappings related to the Managed Cloud. 
      Image Removed 
    • The DNS in the customer's data center: WSO2 provides the domain-name-to-IP mappings related to the Managed Cloud to the customer, who manages the DNS server in the customer's data center.
      Image Removed 

Set up an SMTP server

SMTP is shortened for Simple Mail Transfer Protocol, which is an Internet standard for email transmission. An SMTP server is a computer running SMTP, and which delivers email messages to their corresponding recipients.

The customers can either use their own SMTP servers, or allow WSO2 to use Amazon SES. If the customer does not use Amazon SES, s/he is to share the SMTP credentials of the customer's email server

 Shown below is how an SMTP server in the customer's data center communicates with the WSO2 EC2 instance in the Amazon VPC:

Image Removed

Diagram: SMTP server communicates with the WSO2 EC2 instance

Set up an NTP server

NTP is shorted for Network Time Protocol, which is a networking protocol for synchronising time over a network. Shown below is how the NTP server in the customer's data center communicates, over NTP, with the WSO2 virtual machines in the Amazon VPC. The customer is to share the NTP server details with WSO2 and ensure that the virtual machines where the WSO2 products are running on can reach the NTP server through the customer's firewall.

Image Removed

DiagramNTP server communicates with the WSO2 EC2 instance

Set up a connection to the customer's data center

If the customer wants to connect his/her private AWS network with the data center that is managed by WSO2, the following options are available:

  • Set up a direct connection to the customer's data center from the AWS. An Internet Service Provider (ISP) must be available.
    Image Removed 
  • Set up a connection using an Internet Protocol Security (IPsec) VPN. The data center managed by WSO2 needs to have hardware supported by AWS. Also, the customer must provide the following:  

    • An Internet-routable IP address for the customer's gateway's external interface.
    • A BGP Autonomous System Number (ASN), if the customer needs dynamic routing.
    • IP prefixes in Classless Inter-Domain Routing (CIDR) to advertise to the VPC, if the customer uses static routing.
    • The hardware vendor, model and the software version of the router.
    Image Removed

Set up the environments

The WSO2 Managed Cloud offering is for hosting and maintaining WSO2 products in a Amazon EC2 instance that the customer purchases. Here are the tasks performed by the WSO2 Managed Cloud team when setting up the environments. For additional services, the customer can purchase WSO2 Support.

 Tasks within the WSO2 Managed Cloud SLATasks covered by WSO2 Support services
1Set up an AWS account upon the customer's request (excluding the costs pertaining to the hosting services).

Develop and deploy applications and services.


Set up the virtual machines and networking in the customer's AWS.

Execute IT management tasks (e.g., creating users).


Deploy the WSO2 products that the customer purchased, according to the deployment architecture that was created in the Planning phase.

Execute quality assurance on the system.

(WSO2 will outsource Vulnerability Assessment and Penetration tests to third-party consultants.)


Create user accounts with admin privileges for the customer to log in to the Management Consoles of the WSO2 products. 

Conduct trainings on WSO2 products.

5Guarantee the availability of the Managed Cloud (See Support and Maintenance). 
6Upgrade the WSO2 products and install software patches upon request. 


If the customer wants to synchronize his/her monitoring with that of WSO2, the operations teams from both sides need to agree on certain technical requirements such as additional agents that must be installed on hosts, how to expose dashboards to other networks, how to send alerts to additional email addresses and phones etc.  

Implement security

Network and infrastructure-level securityAs the Managed Cloud solutions are deployed in AWS, they inherit the security measures mentioned in
Operating system security
  • The Amazon Machine Image (AMI) instances can be either or both of the following:
    • Red Hat and Ubuntu instances that are secured using the Center for Internet Security (CIS) standards.
    • Regular Red Hat and Ubuntu instances that are not hardened by the CIS standards.
  • Operating system patches and updates:
    • Customer must buy a subscription to receive official Red Hat patches and updates.
    • Can download Ubuntu patches and updates from the official Ubuntu repositories.

Implement backup and disaster recovery

A disaster is a system failure that cannot be recovered using its own resources. WSO2 provides disaster recovery only upon the customer's request. If requested, WSO2 maintains the recovery scripts and backups in a geographically separate location, and in a different AWS region (DR site). In the event of a disaster, WSO2 sets up the system at the DR site using the backups and recovery scripts. 

The backup and disaster recovery process is shown in the diagram below:

Image Removed

Diagram: The backup and disaster recovery process

Note the following regarding the backup and disaster recovery process:

  • All backup processes are automated.
  • Backups are taken of hosted artifacts such as web applications and services, application and system logs, and databases related to the solution, including WSO2 product databases.
  • Backups are taken from the primary setup to the DR site daily, although this frequency can change depending on the size of the data and the rate that the data changes.
  • The customer can request log and artifact backups for the last three months, anytime.
  • WSO2 cannot provide database backups immediately upon the customer's request. This is because the database backups are stored in a way unique to the Amazon RDS, and it requires some time to be extracted properly.
  • The following have to be determined after a drill (test run) of the recovery process:
    • Recovery Point Objective (RPO): the point in time at which the system was last in a well-known state. This depends on the backup frequency.
    • Recovery Time Objective (RTO): how much time will be taken to recover the system to the last well-known state.
  • WSO2 stores all artifact and log backups in AWS and archives them to Amazon Glacier upon the customer's request.
  • WSO2 takes database backups as Amazon RDS snapshots. 
  • If there are Elastic Block Storage (EBS) volumes in the deployment, WSO2 takes daily snapshots using the AWS-provided snapshot feature.

Manage users and permissions

Manage artifacts

Artifacts are resources such as scripts, patches, updates, and services that run on top of the WSO2 products. 

  • The customer is responsible for storing, versioning, updating, removing, testing and verifying artifacts in the non-production environment.
  • The customer hands over tested and verified artifacts to WSO2 to be deployed in the production environment.
  • WSO2 ensures the security and availability of the artifacts deployed in the production environment.
  • WSO2 is responsible for storing, versioning, updating and removing artifacts in the production environment.

Hand over the environments

WSO2 is to hand over the production environment to the customer with:

  • URLs of the WSO2 products deployed in the Managed Cloud.
  • Credentials with admin privileges to access the Management Consoles of the WSO2 products.

Tip: Note that WSO2 can facilitate the following upon the customer's request:

  • Arrange a third-party consultant to carry out penetration tests.
  • Provide reports and dashboards on the production environment.
  • Arrange trainings and workshops for the customer.
  • Provide read-only access to the monitoring dashboards and the log viewer.

Next, go to Support and Maintenance.You can implement your WSO2 Managed Cloud instance in the following ways:

Children Display