Migrating 3 tier web application to AWS (Re-hosting/lift-and-shift)

The Current Architecture

Before migrating any workload to the cloud, you need to assess the right migration strategy for you. I wrote some questions that you should ask to evaluate your systems.

Deployment Overview

The current application will be migrated as it is to the AWS Cloud. There will be no code changes required other than changing the connection config.

The Oracle database will be deployed in an EC2 instance. (Oracle RDS was not chosen for this migration because code changes might be required. Also, there are possible dependencies on some Oracle services and DB server file system)

Tape backups will be replaced with scheduled backups and an S3 deep archive. You can use the AWS Storage Gateway file interface to directly back up the database to Amazon S3. AWS Storage Gateway file interface provides an NFS mount for S3 buckets. Oracle Recovery Manager (RMAN) backups written into the Network File System (NFS) mount are automatically copied to S3 buckets by the AWS Storage Gateway instance.

Backups will be stored in S3 and moved to the S3 deep archive to save costs. An Application Load balancer will replace the on-prem load balancer.

New Architecture

High availability

The application will be deployed in two AWS availability zones. This will guarantee the application availability even if one AZ goes down. The primary DB will be syncing with the second instance on the other AZ. This instance will be on standby. If in case of a failure in the AZ 1, the stand by DB will automatically be brought up to serve the requests from the application servers. An application load balancer — ALB will be used to divide the load between two AZs. ALB will ensure the traffic will be sent only to the available and healthy server. It will stop sending traffic to a web server if in case the server health check fails.

Performance

Auto-scaling cannot be used in the current application because the web application is storing the user session (stateful application). The application needs to be refactored to support auto-scaling.

AWS Cloud-front can be used to cache static content from different geographical locations to provide faster access.

Security

Authenticating users: On-prem AD and SSO will authenticate the organisation’s employees to the cloud infra.

Use IAM policies and best practices to provide only the required amount of access to the users.

Data Security in transit: All client applications will communicate over HTTPS. SSL/TLS will be deployed on the application load balancer, and only HTTPS traffic will be allowed from the Internet. Certificate manager is used to manager SSL certificates and be associated with the ALB.

Data security at rest: All EC2 instance volumes will be encrypted. Furthermore, data in EFS and S3 will be encrypted.

Application security: The web application firewall prevents vulnerabilities such as DDoS attacks, cross-site scripting, cookie poisoning, parameter tampering, etc.

All application servers will be deployed in a private subnet that allows only inbound traffic from the ALB in the public subnet.

Moreover, four security groups will enable managing traffic flows securely.

• Web DMZ security group will allow port 443 traffic from the internet.
• In the Web SG — Allow traffic from the Web DMZ SG
• In the App SG — Allow traffic from Web SG
• In the DB SG — Allow traffic from App SG

A NAT gateway will be used to download security patches for web and app servers. This is required to keep the security and software patches to be updated.

Application support and maintenance: application engineers can perform code deployments from the corporate network to the servers via the site-to-site VPN. This connectivity will be used for application support and deployments.

Monitoring and alerts

Cloud watch will be used to monitor system performances and health. If in case of any issue, Cloud watch will trigger alerts to the application support team. Cloud trail can be used to monitor user activities for audit purposes.

Backups

Scheduled backups will be enabled in the database with an appropriate retention period. After the retention period, the backups will be moved to S3 Glacier deep archive to save costs using S3 life cycle management.

In addition, manual periodical snapshots of the DB can be taken and moved to S3 Glacier deep archive.

Disaster recovery

The same infrastructure set can be deployed in another AWS region for disaster recovery purposes. The region should be selected based on corporate compliance policies.