Written by Arun Kumar, Sr. Cloud Engineer and Ayush Ragesh, Cloud Solutions Architect, Powerupcloud Technologies
The client is a global pioneer and leader providing end-to-end gifting solutions and manage 260Mn+ transactions a year. With over 15000 points of sale across 16 countries, they needed to migrate their platform from an on-premise datacentre to the cloud. In addition, they needed to be ready and scale-able for one of the largest e-commerce sales in the country.
As determined with the client it was decided to host their primary DC on AWS and DR on Azure.
- The applications were spread across multiple VPCs which are connected to each other via VPC peering. Different VPCs for UAT, Management Production, etc.
- VPN tunnels are deployed from the client’s Bangalore location to AWS and Azure environment.
- Multiple Load Balancers are used to distribute traffic between different applications.
- NAT Gateways are used for Internet access to private servers.
- Cisco Firepower/Palo Alto as the firewall.
- CloudFormation for automated deployments on AWS.
- Cloudtrail for logging and KMS for encryption of EBS volumes and S3 data. Config for change management.
- Route53 is used as the DNS service.
- Guard Duty and Inspector will be configured for additional security.
- DR site will be deployed on Azure.
* Powerupcloud was able to successfully migrate the core for their largest client on AWS.
* The client was able to achieve the required scalability, flexibility and performance.
* The e-commerce sale day was a big success with zero downtime.
The customer initially wanted to use a Cisco Firepower firewall for IDS/IPS, DDOS, etc.SSL offloading needs to be done in the application server. So we decided to use Network Load Balancers. Instance-based routing was used so that the source IP addresses are available at the application server. The firewall needed 3 Ethernet cards for ‘trust’, ‘untrust’ and ‘management’.
In Cisco, by default, the eth0 is mapped management and we cannot change this. In Instance-based routing, the request always goes to eth0 while the request should go to ‘untrust’.
So we finally had to use a Palo Alto firewall where we can remap eth0 to ‘untrust’.