AWS Implementation

This is what we do in the implementation phase:

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

The other method of access is when WSO2 does all the Managed Service 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. This virtual network closely resembles a traditional network but with improved security, reliability, and scalability.

The customers peer their VPC(s) within the WSO2-managed VPC, which is an extension of the WSO2 corporate network as shown in the diagram below:

Diagram: Remote access to the customer's EC2

This setup allows WSO2 Cloud Ops to access the customer's Production and non-production VPCs. This connectivity is built up on top of an IPSec VPN tunnel and a VPC peer interface that are managed by the AWS. 

 The customer is to provide the following:

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. If the customer doesn't use Amazon Route53 services, s/he is to share the DNS name mappings for the IP addresses provided by WSO2.

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

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:

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 synchronizing time over a network. Shown below is how the NTP server in the customer's data center communicates, over NTP, with the 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.

Diagram: NTP server communicates with the WSO2 EC2 instance

Set up a connection to the customer's data center

If the customer wants to connect their private AWS network with the data center that is managed by WSO2, the following options are available. 

The customer ensures ingress and egress traffic through the firewall between the customer's data center and WSO2 Managed Deployment. WSO2 shares the product ports through which WSO2 products communicate with the data center services.

• Set up a direct connection to the customer's data center from the AWS. An Internet Service Provider (ISP) must be available.
   

• 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.
  

Set up the environments

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

Implement monitoring and alerting

• Monitoring dashboards: WSO2 hosts monitoring services and collects statistics  about resource utilization (i.e., disk, CPU, memory, and JVM heap usage) and application health. All statistics collected are presented using  dashboards. WSO2 requires direct access to all monitoring  dashboards, and will grant read-only access to the customer upon the customer's request.
• Application monitoring:  WSO2 product runtimes are monitored by the WSO2 Operations team. WSO2 is not responsible for monitoring the  services deployed on top of the WSO2 product runtimes. They must be managed by the customer.
• Alerts and notifications:  WSO2 requires an email server with SMTP Authentication enabled to send direct email alerts and notifications to other servers. If the customer cannot provide an email server, WSO2 uses Amazon Simple Email Service (SES). We need support from the customer to verify the domain and set up DomainKeys Identified Mail (DKIM) which is an email validation system designed to detect email spoofing.  
  
  The monitoring and alerting implementation is depicted in the diagram below:
       
  Diagram: Monitoring and alerting implementation
  
  If the customer's environment that is managed by WSO2 cannot be reached through the Internet, the customer must facilitate an HTTP proxy server for WSO2 to receive alerts. The diagram below depicts this scenario:
    
  Diagram:  Monitoring and alerting implementation when the customer's environment cannot be reached through the Internet

If the customer wants to synchronize their 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

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:

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

• The WSO2 operations team will have accounts with admin privileges to the Linux servers and will provide read-only access to the customers upon request. 
  
• If the customer creates and owns the AWS account: 
  
  • The customer must share multi-factor-authentication-enabled identity and access management (IAM) users with access to the AWS management console.
  • The customer must share IAM users with sufficient privileges to invoke the AWS APIs and share the access and secret keys with WSO2.
  • The IAM users should have admin privileges to the following services:
    • Amazon VPC
    • Amazon Elastic Compute Cloud (EC2)
    • Amazon Relational Database Service (RDS)
    • Amazon Simple Storage Service (S3) (optional)
    • Amazon Simple Email Service (SES) (optional)
    • Amazon Route53 services (optional)
    • Amazon Glacier (optional)
• For the IAM permissions required to set up your AWS, see this IAM policy that grants the WSO2 Dev Ops team the necessary permissions to essential AWS services.

Manage environments and artifacts

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

• All non-production environments (e.g., Dev, Test, Pre-Prod, etc.) should be architecturally identical to the production environments.
• WSO2 can set up non-production environments, reset, and upgrade them upon the customer's request.
• In case of a migration or an upgrade, the customer and WSO2 account manager are to decide how to handle the migration of customer-specific data and any custom codes.
• WSO2 does not monitor and take backups of non-production environments. If there is an issue in a non-production environment, the customer is expected to open a hosting incident in the bug tracking system.
• 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.
• WSO2 installs software patches and upgrades WSO2 products upon the customer's request. Security patches provided by the OS vendor are installed automatically.

Manage logs and backups

We manage the following types of logs:

• Audit logs: These are generated by the Linux audit daemon and capture all important/privileged system activities.
• Application logs: These are Carbon-level logs that capture all activities related to WSO2 Carbon servers. Carbon is the base platform on top of which all WSO2 products are built.
• System logs: These are Linux syslog and the auth.log files.

Note the following:

• WSO2 uses the Amazon Cloud Watch service to collect and manage logs.
• All log types mentioned above are stored in a private Amazon S3 bucket. An agent in each host collects and streams log events into the S3 bucket.
• If the customer has log management and analysis tools in place, WSO2 can forward the logs to the customer.
• WSO2 stores logs onsite for 30 days and then archives them to Amazon Glacier Vault.

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 Service.
• Credentials with admin privileges to access the Management Consoles of the WSO2 products.

Next, go to Support and Maintenance.