Migrate a on-prem legacy app along with its data on the cloud to leverage Cloud specific features with a very thin monthly budget constraint.
Following aspects were considered as the need for moving to the Cloud:
Followibg aspects were considered in this whole activity:
Following are the top level infra bits to be considered while setting up the infrastructure:
Need to setup all the servers / instances inside a AWS Public Network. Earlier the thought process was to have a private network and expose the app via a load balancer mapped to a domain, but since that will introduce a need for having a NAT server which introduced a risk of going over-budget.
With public networks too we get a good level of external security from AWS hence for simplicity we will go with Public Network and solid Security groups which will provide the same security as that of a Private Network. Security Groups will be discussed later in this document.
Both of these servers resided in the Network created above, however master and slave were placed in different availability zones since we need separate physical locations for the master and slave server.
Complete code for the legacy app was migrated to an GIT Server which was used by the CI/CD pipelines. A appropriate GIT branching strategy was suggested to the cliene based on their development cycle.
We saw the need to have only one image created that of the legacy app. This helped us re-create the App Server in a quick and effortless mode. This image will be used for the following scenarios
Even though we have setup the database as a Master and Slave setup, there are chances that both may go down. In such cases it was a good to have daily / weekly backups taken of the databases and stored. At a given point of time we stored past 5 backups and clear the rest of them. We opted for AWS S3 for this as it is very cost effective and reliable.
It was better to have a static IP for the slave server too, but during failover we will switch the IP of master to the slave since changing the domain mapping of the lumus domains won’t be quick.
Covered 2 aspects:
External Security covered the external attacks aspects such as brute force attack etc. Security Groups is a concept introduced by AWS which basically tells us which server and port is accessible from where. For example, in normal situations apart from port 8080 (http) and 443 (https) no other port should be open to the outside world. Ports like 22 (SSH), 21 (FTP) and other ports should only be opened up on demand and that too only for a selected set of IPs. For Storage Backups, AWS provides role based access controls for each of the backup folders.
Internal Security deals with the internal server security. Scriptuit suggested Red Hat Enterprise Linux (RHEL) as the OS option. RHEL provides a very solid firewall / IP tables. Along with that we uninstalled / stopped any vulnerable services running. Each server had a password-less login which is vulnerable to dictionary attacks. The SSH access was made available only using keys and that too for specific IPs. Root access for each of the servers were disabled permanently.
Database access was restricted to only the apps. AWS Accounts access was limited and sharing the master AWS login was barred and AWS IAMs were used instead.
CI/CD pipelines were built for the following flows:
Considering all the above scenarios, following was the deployment architecture diagram:
Switch over plan to consisted of the following aspects:
One of the core reasons to migrate to the cloud was to use it's full Monitoring and Alerting Capability. Following metrics were monitored and alerts were setup: