A large-scale security organization offering advanced integrated and technology-based security solutions was looking to move its entire legacy setup to AWS cloud.
LTI-Powerup steered the client through a smooth migration process along with providing them round-the-clock managed services for all their applications and services on the cloud. LTI-Powerup also ensured the client could derive maximum benefits from automated deployments and enhanced DevOps capabilities.
The client is a leading innovative Singapore-based operations-technology organization that provides commercial supplementary-armed security forces to government as well as private organizations. They build and manage customized security solutions for complex and crucial operations offering unique integrated security systems that comprise of modern technology, facilities management, security management, customer service and human resources.
The goal being to constantly develop and deliver collaborative and integrated security services that drive operational efficiency and fruitful business outcomes.
The client intended to deploy all their internal web, application, and databases onto the cloud. They were looking for an experienced consulting firm that would help them –
Migrate to AWS,
Manage the applications 24/7 and
Build DevOps capabilities along with it.
LTI-Powerup, premier and trusted consulting partner of AWS, facilitated the migration of the client’s entire on-premise setup to AWS cloud followed by instrumentation of DevOps practices, managed services, and cloud best practices.
LTI-Powerup’s cloud experts engaged with the client to understand and implement migration strategies for their current on-premise setup that was to be moved to AWS.
A high available architecture was designed to host the primary site on availability zone – A whereas disaster recovery of workloads were recommended to be hosted on availability zone – B in the AWS Singapore region. The purpose of positioning multiple independent availability zones was to ensure business continuity in case of unforeseen setbacks and to strengthen AWS resiliency strategy.
The applications and database workloads were hosted on AWS EC2 services for better compute security and capacity.
Elastic Load Balancing (ELB) would automatically help distribute the incoming application or network traffic and route requests to registered EC2 instances, containers, or IP addresses in multiple Availability Zones depending upon the load capacity and reachability it could support.
ELB is capable of scaling the load balancer according to the variation in the incoming traffic over a length of time.
Ever since, developers were able to design and deploy scalable, tolerant, versioned and more consistent architecture on cloud.
AWS systems patch manager provisioned centralized patching of all the servers while AWS NTP service was used for time synchronization of all instances running on VPC across all AWS public regions. Servers were accessed through openVPN access server, which supports all major operating systems including desktop and mobile platforms.
AWS CloudFormation allowed provisioning a collection of related AWS infrastructure using a simple text file, which acts as a template that can be used to design and build one-click deployments. Alternatively known as Infrastructure as code, it simplified and accelerated provisioning and management on AWS. These deployed solutions became more reliable and adhered to all AWS recommended best practices.
AWS Identity and Access Management (IAM) assisted in creating and managing user access to AWS services and resources via secure encryption keys. AWS users and groups were formed with pre-defined access permissions using IAM.
Amazon S3 (Amazon Simple Storage Service) capacitated data storage at one place that could be accessed with easy-to-use application interfaces. Amazon S3 easily managed data and access controls for the client as it is designed for 99.9999% of data durability. It helped protect data from failures and threats, consequently enhancing scalability, availability and application performance.
With S3 object Lambda, customized codes could be run to process or modify the data as it is returned to an application. AWS Lambda functions enabled codes to run virtually on any infrasructure fully managed by AWS without having to provision or manage for servers. With Lambda, backup automation could be stimulated along with triggering alerts to monitor backup statuses.
This brought down costs dramatically as the client ended up paying only for the consumed compute time. It also warranted code scalability with high availability.
AWS CloudWatch is a metrics repository that helped monitor client’s resources and applications on cloud. Operational data logs, metrics and events could be viewed and tracked via consolidated automated dashboards.
Opensource solutions like Grafana and Sensu were configured for detailed monitoring of AWS EC2 resources.
AWS CloudTrail was implemented to capture event history of the client’s Amazon web services account activity. CloudTrail facilitated cloud governance, adhering to compliance as well as operational and risk auditing of the entire client AWS accounts.
AWS Key Management Service (KMS) was used to encrypt data volumes. It helped control data usage across AWS services and AWS KMS could also be integrated with AWS CloudTrail to provide logs of all key usage in order to meet regulatory and compliance needs.
AWS Config helped assess, track and evaluate the configurations, inventory and changes related to AWS resources whereas Amazon GuardDuty aided in continuous monitoring and intelligent detection of unauthorized threats or malicious activity to protect the client’s AWS accounts, workloads, and data stored in Amazon S3.
With the migration to AWS, the client was able to seamlessly integrate the migrated applications with its on-premise legacy systems generating technical agility across the organization.
The AWS well-architected framework facilitated greater scalability, high availability and operational flexibility of applications helping them boost their customer support, service and retention.
The client was able to continuously and proactively monitor systems, detect as well as resolve issues in real time on automated basis, invariably enhancing security, reliability and application performance.
The backup and disaster recovery solutions were more efficient and trouble-free with the move to AWS.
The client was able to create standard templates for infrastructure deployment ensuring speed, consistency and minimal or zero component-level failures.
Financial Ruler is a comprehensive financial planning and management platform that is looking at moving to cloud to tighten security around its data and architecture while ensuring reliability, performance efficiency as well as cost and compliance optimization. LTI to restructure and migrate their infrastructure to AWS for higher availability and scalability.
The client is an all-inclusive social media platform for financial planning that offers services such as asset management, budgeting, retirement planning, and managing your financial data repository all under one roof. They also provide financial projections by converting available complex data into easy-to-view reports and charts along with augmented intelligence tools via integrated technologies to enhance their clients’ usage and experience.
The client is currently running its day-to-day business operations on an external network system and is planning to migrate and host its existing applications in the AWS cloud mainly for future scalability, reliability and high availability.
LTI , a premier and trusted consulting partner of AWS is to re-architect the client’s applications by setting up high-availability application and database layers to help them migrate to cloud efficiently with minimal downtime and optimum infrastructure security.
LTI ’s cloud experts engaged with the customer to understand their requirements, application setup, current architecture and network to draft a suitable cloud migration strategy.
LTI also facilitated assessment and scalability of the entire architecture on cloud along with devising a progressive plan of action for security and compliance, establishing database high availability and minimizing overall infrastructure costs.
Currently the application is a monolithic setup where the application and database are both hosted on a single physical server.
LTI proposes re-architecting the current setup to a three-tier architecture by splitting the web, applications and database servers to rebuild it as a service-oriented scalable design.
This method helps organizations to take full advantage of cloud-native capabilities. In this case, the proposed AWS architecture has allowed them to easily add capacity, strengthen security and accelerate productivity.
The AWS setup
Using root accounts for deployments is not advisable as per AWS recommended security best practices. To securely access different AWS services, MFA enabled IAMaccounts with least permissible access were created and users were given access to only those services, which were needed.This was to ensure an additional layer of security was in place, in case credentials got compromised.
AWS web application firewall (WAF) was setup to secure the web applications hosted on AWS from hacks and cyber attacks.
NAT gateway was provisioned comprising of VPCs with public and private subnets to enable Internet access for servers in the private subnet. Network was designed using appropriate CIDR range, subnets and route tables.
LTI helped configure Network Access Control Lists (NACLs) based on security requirements to control traffic at the subnet level where rules are defined to control traffic from required IP addresses.
They created security groups to control traffic at the VM layer and opened only required ports with least access. IP whitelisting for various third party providers was also covered at the security group level.
SSL certificates were deployed on the load balancers to protect data in transit. Customers could either bring in their own SSL certificates or use public SSL certificates from AWS for free.
A load balancer serves as the single point of contact and distributes incoming application traffic across multiple targets such as EC2 instances, in multiple availability zones. This elevates the availability of the client’s application.
LTI established required config rules, abolished default VPCs across all regions and accounts and enabled VPC flow logs to capture IP traffic data across the network interfaces on cloud. VPN tunnels were also to be enabled between AWS, customer locations and data centers.
Enabling CloudTrail helped the client capture all API activities in the account.
LTI provisioned EC2 instances, which are virtual servers in AWS EC2 service that help run web applications on the AWS infrastructure. Subsequently, they configured web and application servers providing EC2 instances for MongoDB – primary, secondary and arbiter setup. It is a document-oriented cross platform NoSQL cloud database service for modern applications.
LTI devised auto scaling for these application instances that support it and took MongoDB backup to restore data on master MongoDB instance on AWS, thus enabling replication between primary, secondary and arbiter MongoDB servers.
The primary is the only member in the replica set that receives read/write operations. However, server name cannot be defined for the same. A secondary maintains the copy of the primary data set and applies operations from the primary’s operations log to replicate data on to its own data set. Arbiters are MongoDB instances that are part of a replica set that don’t require any dedicated hardware but also do not hold any data. Arbiters can be added to the setup if a replica set has an even number of members.
Post migration checks were essential and LTI ensured an end-to-end application validation was conducted and any issues if found in the infrastructure configuration were fixed swiftly.
To enable going live on production, the Amazon Route 53, an AWS DNS web service and the Amazon CloudFront services were both configured successfully to dispense highly scalable and secure web applications, data and APIs across the globe on cloud. AWS WAF enabled application protection via its WAF policies. It also helped cleanup unwanted data logs on the production environment, set the app in maintenance mode, helped restart all necessary components, performed application validation and updated the DNS to point to AWS.
AWS Monitoring and Logging
Inducted the CloudWatch tool, which provides infrastructure and application monitoring of all the applications, resources and services that run on cloud and on-premise. It helps collect operational data logs, metrics and events through automated backups that can be viewed in consolidated form on dashboards. Appropriate alarms were configured in CloudWatch to notify the customer when certain thresholds were crossed. Amazon SNS were used for notifications.
AWS Config service enabled assessment, audit and evaluation of all AWS resources. Config monitored and recorded all AWS resource configurations in accordance with AWS best practices for change management. It can eventually automate evaluated records against expected configurations as well.
LTI supported AWS infrastructure operations by leveraging AWS services in the following areas:
Continuous cost optimization through rightsizing EC2 instances, scheduling, upgrading instances to latest generation and deleting unused cloud-based storage volumes.
AWS Server Management provided 24/7 support for server monitoring, disaster recovery in case of server outage or compromise, speedy response time along with environment and app monitoring.
Security management was administered via AWS cloud security services that helped the client meet their security and compliance requirements, ascertained data protection and confidentiality with stringent measures in place for any security threats, enabled secure scaling, provided greater visibility and automated security tasks.
AWS Network Services ensured consistent network availability, data integrity and 24/7 monitoring of cloud infrastructure that can run workloads with high throughput and lowest latency requirements. AWS network capabilities are one of the largest globally and can deliver client applications and content across the world over a private network.
AWS Backup enables backup policy configurations from a centrally managed console to confirm that application data across AWS services are backed up and secure. It supports automated backup processes and maintains consolidated backup activity logs for all AWS services.
DR support minimizes downtime and data loss by enabling speedy and reliable recovery of physical, virtual and cloud-based servers into AWS cloud. This simplifies architecture implementation and protects enterprise applications and databases without compromising business continuity.
AWS Audit Manager provides continuous audit of AWS usage to assess risks and compliance against industry standards. It provides prebuilt frameworks that are mapped to the client’s AWS resources to ensure if regulatory controls are being abided by. Audit manager facilitates automated collection of data for assessment on daily, weekly or monthly basis as per client’s requirement.
With the migration to AWS, the client acquired a much more strengthened, secure and efficient infrastructure. Application and server performances got more coherent.
Database is now fully secured with prevention of unauthorized public access and static data stored in AWS S3 bucket is encrypted.
Moving to cloud signified cost optimization by eliminating unwanted costs and managing expenses without overspending.
The AWS well-architected framework offered operational flexibility and excellence, took care of monitoring the systems on a continuous and automated basis and helped recover from quick service or infrastructure disruptions if any.
Thus, the client has reaped benefits of up to 30% in operational savings and up to 25% in AWS infrastructure savings while also improving their operational SLAs, security, and compliance posture.
Customer: A leading healthcare research, data & technologies company
A leading healthcare research, data and technologies company was seeking recommendations on cloud optimization & best practices. Powerup conducted a detailed study & analysis to provide the customer team with suggestions on cost optimization, security audit and AWS best practices.
The customer is a leading healthcare research and consulting company that provides high-value healthcare industry analysis and insights. They create patient-centric commercialization strategies that drive better outcomes and access, improving the lives of patients globally.
The customer helps businesses achieve commercial excellence through evidence-based decision making processes like expert consultation, proprietary data and analysis via machine learning artificial intelligence.
The customer utilizes nearly all the tools that AWS offers to build, upgrade & maintain their infrastructure as per ongoing requirements. They are looking at cost optimization for all of their 17 AWS accounts. They plan to initiate cost-saving strategies to their AWS master account by –
Identifying the number of servers running idle and help create reserved instances.
Deploy upgraded servers based on recommendations.
Implement resource tagging for business unit-wise billing.
Install CloudHealth agent to maintain multiple accounts and
Automate lifecycle policies for backup maintenance.
The tagging is required to be done on a total of 490+ EC2, 70+ RDS and S3 servers that would be based on P&L, projects, stage, application owner, roles, support contact, function and cost savings heads to name a few.
The team was ill-equipped with the techniques of downsizing and was uncertain about how reports could be utilized to their maximum advantage in order to minimize costs.
Applying AWS user data as a benchmark, Powerup created a CloudHealth agent inventory list and identified missing agents for the customer. They worked closely with the customer’s DevOps team to gain access to servers, to install CloudHealth agent on the remaining 300+ systems. Once done, agent check-in was verified to confirm 100% coverage. Installation was automated for new resources launch and a restriction was imposed on launching any instance without agent set up. Reserved Instance (RI) recommendation was obtained through the CloudHealth tools with the intent to reduce costs.
Phase 2 – Tagging and Governance
In the cloud environment, tags are identifiers that are affixed to instances. Powerup helped the customer incorporate 100% tagging based on appropriate business reviews. The objective was to strengthen inventory tag lists by classifying all instances under their respective heads. Instances were classified as per AWS best practices to initiate cost controls.
ParkmyCloud is a self-service SaaS platform that is implemented to help identify and terminate wasted cloud spend. It was scheduled periodically on customer’s Dev/QC/Staging environments and no machines were launched without proper tagging. It helped keep a check on auto-scaling groups to ensure tagging, as well as help, identify and implement governance rules as alert checks on resources, from being launched without proper tagging, sizing or approvals. Categorization of assets based on its name when tags are missing could be detected easily. Automating tagging and enabling termination policy for an instance helped in better-cost management along with providing the customer with accurate findings, recommendations and a strategic roadmap.
Phase 3 – Rightsizing and instance type consolidation
Powerup created a database instance inventory list to recognize and review the outdated version of servers. They also identified instances that required reconfiguration and upgradation. They imported instance right-sizing recommendations from data collected from CloudHealth tools that stated suitable suggestions for new instance type and size. It ensured appropriate process flow of right-sizing checks, added business intelligence around recommendations and smoothly transitioned all suggestions to the customer team. These recommendations helped them cut down on costs significantly.
Phase 4 -Security Audit
With the help of CloudHealth security audit report, the customer could study, analyze and prioritize summary findings by order of criticality and business requirements in a consolidated format. Recommended resolutions helped them validate security loopholes and facilitated suggestions on security fixes to the customer DevOps team. It also enabled them to generate backup services and POC reports which assisted them in checking how reports performed. This enabled them to update alert thresholds to meet business expectations and requirements.
Using RI recommendations will help the customer cut down their monthly bills on EC2 and RDS by 30% .
The new EC2 version instance recommendation can help them save a minimum of 8% of costs while guaranteeing the high-quality performance.
The customer was able to regulate their billing and cost console using CloudHealth and AWS billing dashboard.
Restricted resources provisioned without proper tags and CloudHealth agent promotes easy maintenance of multiple accounts by using a single console.
Customer: The fastest-growing cinema business in the Middle East
The customer is the fastest-growing cinema business in the Middle East who is intending to migrate their core movie ticket management and booking application on to AWS. Currently, it is a colocation data center that needs to be migrated for better scalability and availability followed by implementation of DevOps optimisation, disaster recovery, log analysis, and managed services.
Case – Migration
Type – RePlatform
Number of VM’s – 50
Number of applications migrated – 5
Approximate size of DB – 250 GB
The customer is the fastest-growing cinema business in the Middle East, which is the leading shopping mall, communities, retail, and leisure pioneer across the Middle East, Africa, and Asia. They are a prominent exhibitor in the middle east with a significant regional presence.
The customer is planning to migrate their core movie ticket management and booking application from their colocation data center (DC) to AWS for better availability and scalability. Migration to AWS was to facilitate the customer to move their production workload as-is without many architectural changes and then focus on DevOps optimisation.
Powerup proposed a 2 phased approach in migrating the customer applications to AWS.
Phase 1 – As-is migration of applications from on-premise set up to AWS cloud along with the migration of databases for better scalability and availability.
Phase 2 – Implementation of DevOps optimisation.
Post this, Powerup’s scope of work for the customer also included Disaster Recovery (DR) implementation, setting up EKK for log analysis and AWS managed services.
Powerup will study the customer’s environment and prepare a blueprint of the overall architecture. They will identify potential servers and database failure points and will accordingly fix the automation of backups.
Powerup to work in coordination with the customer team to,
export application and data from on-premise architecture to AWS using either Amazon Import/Export functionality or over the internet.
Restore data on the cloud and enable database replication between on-premise and Amazon data stores to identify differential data.
Implement the monitoring agents and configure backups.
Conduct load testing if required as well as system and user acceptance accessibility tests to identify and rectify vulnerabilities.
Post-deployment and stabilization, Powerup completed the automation of the infrastructure using AWS Cloud formation and code deployment automation to save operational time and effort.
Post phase 1 as-is migration of the customer’s applications, Powerup’s DevOps team will perform weekly manual and automated audits and share reports with the customer team.
Weekly reports on consolidated uptime of applications, total tickets logged, issue resolution details and actionable plans will be shared with the customer team. Powerup will also run a Vulnerability Assessment & Penetration Testing (VAPT) on cloud coupled with quarterly Disaster recovery (DR) drills for one pre-selected application in the cloud platform to ensure governance is in place.
DevOps is also responsible for seamless continuous integration (CI) typically handled by managing a standard single-source repository, automating the build, track the build changes/progress and finally automating the deployment.
Disaster Recovery (DR)
Powerup to understand customer’s compliance, Recovery Point Objective (RPO) and Recovery Time Objective (RTO) expectations before designing the DR strategy.
Configure staging VPC, subnets and the entire network set up as per current architecture.
Set up network access controls, create NAT gateway and provision firewall for the DR region.
Initiate CloudEndure console, enable replication to AWS staging server, create failover replication to DR site from CloudENdure dashboard to conduct DR drill.
Verify and analyze RTO and RPO requirements.
EKK set up
The AWS EKK stack (Amazon Elasticsearch Service, Amazon Kinesis and Kibana) act as an alternative to ELK, an open-source tool by Amazon to engage in and visualize data logs. Powerup’s scope involved gathering information on environment and providing access to relevant users to create an AWS ElasticSearch service and AWS Kinesis service. The intent was to install and configure the Kinesis agent on the application servers in order to push the data logs and validate the log stream to the Kibana dashboard. This set up would help configure error and failure logs, alerts, anti-virus logs and transition failures. The EKK solution is known to provision for analyzing logs and debugging applications. Overall, it helps in managing a log aggregation system. Know more on EKK implementation here.
The first step is to study the customer’s cloud environment to identify potential failure points and loopholes if any.
Powerup DevOps team will continuously monitor the customer’s cloud infrastructure health by keeping a check on CPU, memory and storage utilization as well as URL uptime and application performance.
OpenVPN will be configured for the secure exchange of data between the customer’s production setup on AWS and the individual cinema locations. The web, application and database servers are implemented in High Availability (HA) mode. Databases are implemented on Amazon EC2 with replication enabled to a standby server. Relational database service (RDS) may be considered if there are no dependencies from the application end.
Security in the cloud is a shared responsibility between the customer, cloud platform provider and Powerup. Powerup will continuously analyze and assist the customer with best practices around application-level security.
The security monitoring scope includes creating an AWS organization account and proxy accounts with multi-factor authorization (MFA) for controlled access on AWS. Powerup to also set up an Identity and Access Management (IAM), security groups as well as network components on customer’s behalf.
The powerup team has helped setting up the VPN tunnel from AWS to different customer theatre locations [31 different locations].
Enable server-side encryption and manage Secure Sockets Layer (SSL) certificates for the website. Monitor logs for security analysis, resource change tracking, and compliance auditing. Powerup DevOps team to track and monitor firewall for the customer’s environment and additionally mitigate distributed denial-of-service (DDoS) attacks on their portals and websites.
Anti-virus tools and intrusion detection/prevention to be set up by Powerup along with data encryption at the server as well as storage level. Powerup DevOps team will continuously monitor the status of automated and manual backups and record the events in a tracker. In case of missed automatic backups, a manual backup will be taken as a corrective step. Alerts to also be configured for all metrics monitored at the cloud infrastructure level and application level.
Migration helped the customer achieve better scalability and availability.
DevOps tool helped automate manual tasks and facilitated seamless continuous delivery while AWS cloud managed services provisioned the customer to reduce operational costs and achieve maximum optimization of workload efficiency.
The customer is an international clinical-stage biopharmaceutical company focusing on cellular immunotherapy treatments for cancer is looking at adopting cloud services for the very first time. They plan to structure their database on Google cloud platform. The intention is to enhance performance and have efficient research outputs from their applications especially since they handle large volumes of data. They were also looking at the ability to scale at any point of time during peak loads along with complete automation of continuous integration and continuous deployment (CI/CD) process for easier deployments and better auditing, monitoring and log management.
The customer is a clinical-stage biopharmaceutical organization with the scientific vision of revolutionizing the treatment of cancer. They specialize in the research, clinical development and commercialization of cancer immunotherapy treatments. The combination of technologies from its academic, clinical and commercial research partners have enabled the company to create a fully integrated approach to the treatment of cancer with immunotherapy. They plan to work with Powerup to use Google Cloud Platform (GCP) as its cloud platform for their Cancer Research program.
The customer plans to use Google Cloud Platform (GCP) as its cloud platform for their Cancer Research program. Data scientists will be using a Secure File Transfer Protocol (SFTP) server to upload data on an average of one to two times a month with an estimated data volume of 2-6 TB per month.
The data transferred to GCP has to undergo a two-step cleansing process before uploading it on a database. The first step is to do a checksum to match the data schema against the sample database. The second step is transcoding and transformation of data after which the data is stored on a raw database.
Greenfield setup on GCP
Understanding customer needs while also understanding the current python models and workflows to be created were the first steps in initiating this project. Post these preliminary studies and sign-off, a detailed plan and solution architecture document formed a part of the greenfield project deliverables.
The set up included shared services, logging UAT and production accounts. The Cloud Deployment Manager (CDM) was configured to manage their servers, networks, infrastructure and web applications. Cloud Identity and Access Management (IAM) roles were created to access different GCP services as per customer specification, which helped in securely accessing another service.
On-premise connectivity is established via VPN tunnels.
The data scientists team have built nearly 50+ python/R models that help in the data processing. All the models are stored in GitHub currently. Python model will meet performance expectations when deployed and CI/CD pipelines to be created for 48 python models.
Once the data arrives on the database, the customer wants the python code to process the data and store the results on an intermediate database.
Multiple folders were created to deploy production, UAT and management applications. Cloud NAT was set up to enable internet access, Virtual Private Cloud (VPC) peering done for inter-connectivity of required VPCs and SFTP server was deployed on Google Compute Engine.
Once data gets uploaded on the raw GCS, checksum function will be triggered to initiate data cleansing. In the first phase, the data schema will be verified against a sample database after which the data will be pushed to transcoding and transformation jobs. Processed data will be stored to GCS.
All the python/R models will be deployed as a docker image on a Kubernetes cluster that is managed by Google ensuring that GCP is taking care of high availability and scaling.
The customer will have multiple workflows created to process data that in turn would be able to define all the workflows for python model executions.
The customer team will view the current data through a web application.
The processed data also has to be synced back to the on-premise server. An opensource antivirus tool is used to scan and verify data before migrating to Google Cloud Storage (GCS).
Monitoring and Logging
Monitoring tools such as stackdriver for infrastructure and application monitoring as well as log analytics was used as it supported features like tracing, debugging and profiling to monitor the overall performance of the application.
Additional tools such as Sensu to monitor infrastructure, Cloud Audit logging that checks Application Program Interface (API) activities, VPC flow logs to capture network logs and FluxDB as well as Grafana to store data on the database and visualize and create dashboards respectively were utilised.
Stackdriver logging module ensures centralized logging and monitoring of the entire system.
Security and Compliance
IAM with least permissible access and Multi-Factor Authentication (MFA) be enabled as an additional layer of security for account access. The databases won’t have direct access to critical servers like database and app servers. Firewall rules will be configured at the virtual networking level for effective protection and traffic control regardless of the operating system used. Only the required ports will be opened to give access to the necessary IP addresses.
Both data in transit and at rest are by default encrypted in GCP along with provisions for static code analysis and container image-level scanning.
Setup CI/CD pipeline using Jenkins which is an open-source tool that facilitates modern DevOps environment. It bridges the gap between development and operations by automating building, testing and deployment of applications.
After the successful deployment of code, code integration and log auditing got simpler. The customer was able to handle large blocks of data efficiently and auto-scaling at any point of time during new product launches and marketing events became effortless. This improved their performance as well.
The customer was also able to scale up without worrying about storage and compute requirements. They could move into an Opex model on the cloud by paying as per usage.
Moving to GCP enabled the customer to save 20% of their total costs as they could adopt various pricing models and intelligent data tiering.
The customer is UAE’s aviation corporation catering over 70 million passengers as of date. Passenger service system (PSS), their ticket booking application was a legacy system that they intended to migrate to a cloud environment while ensuring they manage to leverage administered services of cloud by conducting a Migration Readiness Assessment & Planning (MRAP).
Passenger Service System (PSS) was the existing ticket booking application for the customer. The objective was to understand this legacy system and then recommend how it can be migrated to AWS while leveraging the cloud-native capabilities via an MRAP assessment. The focus would be application modernization rather than a lift & shift migration to the cloud. The customer team intends to leverage managed services of cloud and go serverless, containers, open source etc. wherever possible. The customer team also wants to move away from the commercial Oracle database to a more open-source AWS Aurora PostgreSQL database due to the high licensing costs imposed by Oracle.
MRAP is critical to any organization that plans to adapt to the cloud as this tool-based assessment checks their application’s ability to cloud. Powerup was approached to perform MRAP on their existing set up to propose a migration plan as well as a roadmap, post its analysis.
The customer’s MRAP Process
To begin with, the RISC Networks RN150 virtual appliance, an application discovery tool that poses as an optional deployment architecture was configured and installed on the customer’s existing PSS Equinix data centre (DC) to collect data and create a detailed tool-based assessment to understand the existing set up ‘s readiness to migration.
Application stacks were built for the applications in scope and assessments as well as group interviews were conducted with all stakeholders. Data gathered from stakeholders were cross-verified with the information provided by the customer’s IT and application team to bridge gaps if any. Powerup team would then work on creating a proposed migration plan and a roadmap.
A comprehensive and detailed MRAP report included the following information:
Existing overall architecture
The existing PSS system was bought from a vendor called Radixx International, which provided three major services:
Availability service, an essential core service mainly used by online travel agencies (OTAs), end-users and global distribution system (GDS) to check the availability of their customer’s flights. It’s base system contained modules like Connect Point CP (core), payments, the enterprise application (Citrix app) all written in .NET and the enterprise application for operation and administration written in VB6.
Reservation service was used in booking passengers’ tickets where data was stored in two sessions, Couchbase and the Oracle database. The webpage traffic was 1000:1 when compared to availability service.
DCS System (Check-in & Departure Control Systems) is another core system of any airline, which assists in passenger check-in, baggage check-in and alerting the required officials. It is a desktop application used by airport officials to manage passengers from one location to another with the availability of an online check-in module as well.
Existing Database: Oracle is the current core database that stores all critical information consisting of 4 nodes – 2 Read-Write nodes in RAC1 & another 2 (read-only nodes) in RAC2. All availability checks are directed to the read-only Oracle nodes. The Oracle database nodes are heavily utilized roughly at 60-70% on an average with currently 14 schemas within the Oracle database accessed by the various modules. Oracle Advanced Queuing is used is some cases to push the data to the Oracle database.
Recommended AWS Landing zone structure
The purpose of AWS Landing Zone is to set up a secure, scalable, automated multi-account AWS environment derived from AWS best practices while implementing an initial security baseline through the creation of core accounts and resources.
The following Landing Zone Account structure was recommended for the customer:
AWS Organizations Account:
Primarily used to manage configuration and access to AWS Landing Zone managed accounts, the AWS organizations account provides the ability to create and financially manage member accounts.
Shared Services Account:
It is a reference for creating infrastructure shared services. In the customer’s case, Shared Services Account will have 2 VPCs – one for management applications like AD, Jenkins, Monitoring Server, Bastion etc. and other Shared services like NAT Gateway & Firewall. Palo Alto Firewall will be deployed in the shared services VPC across 2 Availability Zones (AZ)s and load balanced using AWS Application Load Balancer.
AWS SSM will be configured in this account for patch management of all the servers. AWS Pinpoint will be configured in this account to send notifications to customer – email, SMS and push notifications.
Centralized Logging Account:
The log archive account contains a central Amazon S3 bucket for storing copies of all logs like CloudTrail, Config, CloudWatch logs, ALB Access logs, VPC flow logs, Application Logs etc. The logging account will also host the Elasticsearch cluster, which can be used to create custom reports as per customer needs, and Kibana will be used to visualize those reports. All logs will be pushed to the current Splunk solution used by the customer for further analysis.
The Security account creates auditor (read-only) and administrator (full-access) cross-account roles from a security account to all AWS Landing Zone managed accounts. The organization’s security and compliance team can audit or perform emergency security operations with this setup and this account is also designated as the master Amazon GuardDuty account. Security Hub will be configured in this account to get a centralized view of security findings across all the AWS accounts and AWS KMS will be configured to encrypt sensitive data on S3, EBS volumes & RDS across all the accounts. Separate KMS keys will be configured for each account and each of the above-mentioned services as a best practice.
Powerup recommended Trend Micro as the preferred anti-malware solution and the management server can be deployed in the security account.
This account will be used to deploy the production PSS application and the supporting modules. High availability (HA) and DR will be considered to all deployments in this account. Auto-scaling will be enabled wherever possible.
UAT Account – Optimized Lift & Shift:
This account will be used to deploy the UAT version of the PSS application. HA and scalability are not a priority in this account. It is recommended to shut down the servers during off-hours to save cost.
Based on the understanding of the customer’s business a Hot Standby DR was recommended where a scaled-down version of the production setup will be always running and will be quickly scaled up in the event of a disaster.
UAT Account – Cloud-Native:
The account is where the customer’s developers will test all the architectures in scope. Once the team has made the required application changes, they will use this account to test the application on the cloud-native services like Lambda, EKS, Fargate, Cognito, DynamoDB etc.
Application Module – Global Distribution Systems (GDS)
A global distribution system (GDS) is one of the 15 modules of the PSS application. It is a computerized network system that enables transactions between travel industry service providers, mainly airlines, hotels, car rental companies, and travel agencies by using real-time inventory (for e.g., number of hotel rooms available, number of flight seats available, or number of cars available) to service providers.
The customer gets bookings from various GDS systems like Amadeus, Sabre, Travelport etc.
ARINC is the provider, which connects the client with various GDS systems.
The request comes from GDS systems and is pushed into the IBM MQ cluster of ARINC where it’s further pushed to the customer IBM MQ.
The GMP application then polls the IBM MQ queue and sends the requests to the PSS core, which in turn reads/writes to the Oracle DB.
GNP application talks with the Order Middleware, which then talks with the PSS systems to book, cancel, edit/change tickets etc.
Pricing is provided by the Offer Middleware.
Topology Diagram from RISC tool showing interdependency of various applications and modules:
Any changes in the GDS architecture can break the interaction between applications and modules or cause a discrepancy in the system that might lead to a compromise in data security. In order to protect the system from becoming vulnerable, Powerup recommended migrating the architecture as is while leveraging the cloud capabilities.
Proposed Migration Plan
IBM MQ cluster will be setup on EC2, and auto-scaling will be enabled to maintain the required number of nodes thus ensuring availability of EC2 instances at all times. IBM MQ will be deployed in a private subnet.
Amazon Elastic File System (Amazon EFS) will be automatically mounted on the IBM MQ server instance for distributed storage, to ensure high availability of the queue manager service and the message data. If the IBM MQ server fails in one availability zone, a new server is created in the second availability zone and connected to the existing data, so that no persistent messages are lost.
Application Load Balancer will be used to automatically distribute connections to the active IBM MQ server. GMP Application and PNL & ADL application will be deployed on EC2 across 2 AZs for high availability. GMP will be deployed in an auto-scaling group to scale based on the queue length in the IBM MQ server and consume and process the messages as soon as possible whereas PNL & ADL to scale out in case of high traffic.
APIS Inbound Application, AVS application, PSF & PR application and the Matip application will all be deployed on EC2 across 2 AZs for high availability in an auto-scaling group to scale out in case of high traffic.
GMP and GMP code sharing applications will be deployed as Lambda functions. The lambda function will run when a new message comes to the IBM MQ.
PNL & ADL application will be deployed as a Lambda function and the function will run when there is a change in the PNR number in which case a message must be sent to the airport.
AVS application will be deployed as Lambda functions where it will run when a message will be sent to the external systems.
Matip application will be deployed as a Lambda function and will run when a message will be sent using the MATIP protocol.
PFS & PR application will be deployed as Lambda functions. The lambda function will run when a message will be sent to the airport for booking.
APIS Inbound application will be deployed as a Lambda function and it will run when an APIS message will be sent to the GDS systems.
For all the above, required compute resources will be assigned as per the requirement. Lambda function will scale based on the load.
Application modifications recommended
All the application components like GMP, AVS, PNL & ADL, PFS & PR, Matip, etc are currently in .NET. which have to be moved into .NET Core to be run as Lambda functions. The applications are recommended to be broken down into microservices.
Oracle to Aurora Database Migration
AWS schema conversion tool (SCT) is run on the source database, which will generate a schema conversion report that will help understand interdependencies of existing schemas, and how they can be migrated on to Aurora PostgreSQL. The report will contain database objects some that can be directly converted by the SCT tools and the rest, which would need manual intervention. For Oracle functionalities that are not supported in Aurora PostgreSQL, the application team must write custom code to migrate those. Once all the schemas are migrated, AWS Database Migration Service will be used to migrate the entire data set from Oracle to Aurora.
Oracle to Aurora-PostgreSQL Roadmap
Lift & shift:
The current Oracle database will be moved to AWS as-is without any changes in order to kick-start the migration. The Oracle database can run on AWS RDS service or EC2 instances. One RDS node will be the master database in read/write mode. The master instance is the only instance to which the application can write to. There will be 3 additional read-replicas spread across 2 AZs of AWS to handle the load that is coming in for read requests. In case the master node goes down one of the read replicas is promoted as the master node.
Migrate the Oracle schemas to Aurora:
Once the Oracle database is fully migrated to AWS, the next step is to gradually migrate the schemas one by one to Aurora – PostgreSQL. The first step is to map all the 14 schemas with each application module of the customer. The Schemas will be migrated based on this mapping, wherever there are non-dependent schemas on other modules, it will be identified and migrated first.
The application will be modified to work with the new Aurora schema. Any functionality, which is not supported by Aurora, will be moved to application logic.
DB links can be established from Oracle to Aurora, however, it cannot be established from Aurora to Oracle database.
Any new application development that is in progress should be compatible and aligned with the Aurora schema.
Finally, all the 14 schemas will be migrated onto Aurora and the data will be migrated using DMS service. The entire process is expected to take up to 1 year. There will be 4 Aurora nodes – One Master Write & 3 Read Replicas spread across 2 AZs of AWS for high availability.
The assessment posed as a roadmap to move away from Oracle to PostgreSQL saving up to 30% in Oracle License cost. It also provided a way forward for each application towards cloud-native.
Current infrastructure provisioned was utilized at around 40-50% and a significant reduction in the overall total cost of ownership (TCO) was identified if they went ahead with cloud migration. Less administration by using AWS managed services also proved to be promising, facilitating smooth and optimized functioning of the system while requiring minimum administration.
With the MRAP assessment and findings in place, the customer now has greater visibility towards cloud migration and the benefits it would derive from implementing it.
Customer: One of India’s top media solutions company
The powerup cloud helped the customer completely transform their business environment through complete automation. Our design architecture and solution engineering improved business process efficiency, without any manual intervention, resulting in turnaround time is decreased by more than 90%. Now most of their applications running on the cloud, the customer has become one of most customer-friendly media companies in India.
The customer’s team wants to concentrate on building applications rather than spending time on the infrastructure setup and dependencies packages installed and maintained on the servers. The proposing solution needs to be a quick & scalable one so that business performance will be improved significantly.
Focusing on workload and transaction volume, we designed a customer-friendly, network optimized, a highly agile and scalable cloud platform that enabled cost optimization, effective management, and easy deployment. This helped reducing interventions and cost overheads.
We used AWS native tool CloudFormation to deploy the infrastructure as code, the ideology behind this is deployed infra as well as we can use it for Disaster Recovery.
CloudFormation template implemented in Stage & prod environment based on the best practice of AWS by subjecting the severs to reside in private subnets and internet routing with the help of Nat-gateway.
To remove the IP dependencies for a better way to manage failures, the servers and the websites are pointed to the Application load balancers where a single load balancer we managed to have multiple target groups in the view of cost optimization.
Base Packages Dependency:
This solution must remove the dependency of the developer to install the packages on the server to support the application.
The packages need to be installed on the infra setup, so the developer can deploy the code using the code deployer services rather than spending time to install dependencies.
Hence, we proposed & implemented the solution via Ansible, With the help of ansible we can able to manage multiple servers under a single roof. We have prepared a shell script that will install the packages on the server.
The architecture majorly differentiated in the means of Backend & frontend Module.
Backend Module where the java application will be running, hence a shell script will run the backend servers which will install the Java-8 versions and creates a Home path based on standard path, so home path execution of application will be always satisfied by this condition.
Frontend Module which more likely of Nginx combined with node.js which achieved by the same methodology.
The application’s logs and other backup artifacts are managed in the secondary EBS volume which the mount point to the fstab entries are also automated.
The Main part of deployment achieved by the code-deployer hence the servers should be installed with code-deployment agents during the server setup which is also done through ansible.
User access is another solution, where the access to the servers restricted for some people in the development team and the access will be provided to the server with the approval of their leads.
We had, dev, qa, psr, stage and prod environments we clubbed all the servers in the ansible inventory and generated a public key and private key and passed them on the standard part. When the user adds scripts runs, ansible will copy the public keys and create a user on the destination server by pasting the public key in the authorized file.
This method will be hidden the pub key from the end-user when the user asked to removed using ansible we will delete those users from the server.
Monitoring with sensu:
Infra team is responsible for monitoring the infra, hence we created a shell script that will install the sensu on the destination server for monitoring using ansible.
By implementing these solutions, the development was less worried about the packages dependencies which allowed them to concentrate on their app development and fixing bugs and user access got streamlined.
Bastion with MFA settings:
The servers in the environment can get accessed only by the bastion server which acts as the entry point.
This bastion server was set up with the MFA mechanism, where each user must access the server with MFA authentication as a security best practice.
In one of the legacy account, SSL offloaded at the server level with a lot of Vhosts. Hence renewing certificates will take time to reduce the time we used SSL with ansible to rotate the certificates in a quick time with less human efforts.
Automation in Pipeline :
Base packages installation on bootup which reduces one step of installation.
User access with automatic expiry condition.
In addition to the on-going consulting engagement with the customer for enhancement, and designing a system to meet the client’s need, Powerupcloud also faced some challenges. The Infra has to be created in quick time with 13 servers under the application load balancers, which includes Networking, compute and load balancers with target groups. The Instances were required to install with certain dependencies to run the application smoothly. As a result, the development process became more complicated.
The solution was also expected to meet the very high level of security, continuous monitoring, Non-stop 24X7 operation, High availability, agility, scalability, less turnaround time, and high performance, which was a considerable challenge given the high business criticality of the application.
To overcome these challenges, we established a predictive performance model for early problem detection and prevention. Also, started a dedicated performance analysis team with active participation from various client groups.
All the changes in configuration are smoothly and rapidly executed from the viewpoint of minimizing load balance and outage time.
Business Result & outcome
With the move to automation, the customer’s turn-around time decreased by 30%. This new system also helped them reduced capital investments as it is completely automated. The solution was designed in-keeping with our approach of security, scalability, agility, and reusability.
Successful implementation of the CloudFormation template.
The customer is one of the largest Indian entertainment companies catering to acquiring, co-producing, and distributing Indian cinema across the globe. They believe that media and OTT platforms can derive maximum benefit in terms of multi-tenant media management solutions provided by the cloud. Therefore, they are looking at migrating their existing servers, databases, applications, and content management system on to cloud for better scalability, maintenance of large volumes of data, modernization, and cost-effectiveness. The customer intends to also look at alternative migration strategies like re-structuring and refactoring if need be.
The customer is a global Indian entertainment company that acquires, co-produces, and distributes Indian films across all available formats such as cinema, television and digital new media. The customer became the first Indian media company to list on the New York Stock Exchange. It has experience of over three decades in establishing a global platform for Indian cinema. The company has an extensive and growing movie library comprising over 3,000 films, which include Hindi, Tamil, and other regional language films for home entertainment distribution.
The company also owns the rapidly growing Over The Top (OTT) platform. With over 100 million registered users and 7.9 million paying subscribers, the customer is one of India’s leading OTT platforms with the biggest catalogue of movies and music across several languages.
Problem statement / Objective
The online video market has brought a paradigm shift in the way technology is being used to enhance the customer journey and user experience. Media companies have huge storage and serving needs as well as the requirement for high availability via disaster recovery plans so that a 24x7x365 continuous content serving is available for users. Cloud could help media and OTT platforms address some pressing business challenges. Media and OTT companies are under constant pressure to continuously upload more content cost-effectively. At the same time, they have to deal with changing patterns in media consumption and the ways in which it is delivered to the audience.
The customer was keen on migrating their flagship OTT platform from a key public cloud platform to Microsoft Azure. Some of the key requirements were improved maintainability, scalability, and modernization of technology platforms. The overall migration involved re-platforming and migrating multiple key components such as the content management system (CMS), the Application Program Interfaces (APIs), and the data layer.
Powerup worked closely with the client’s engineering teams and with the OEM partner (Microsoft) to re-architect and re-platform the CMS component by leveraging the right set of PaaS services. The deployment and management methodology changed to containers (Docker) and Kubernetes.
Key learnings from the project are listed below:
Creating a bridge between the old database (in MySql) and a new database (in Postgres).
Migration of a massive volume of content from the source cloud platform to Microsoft Azure.
Rewriting the complete CMS app using a modern technology stack (using Python/Django) while incorporating functionality enhancements.
Setting up and maintaining the DevOps pipeline on Azure using open source components.
Modernized infrastructure powered by Azure, provided improved scalability and stability. The customer was able to minimize infrastructure maintenance using PAAS services. Modular design set-up enabled by migration empowered the developers with the ability to prototype new features faster.
The customer’s environment on AWS was facing scalability challenges as it was maintained across a heterogeneous set of software solutions with many different types of programming languages and systems and there was no fault-tolerant mechanism implemented. The lead time to get a developer operational was high as the developer ended up waiting for a longer duration to access cloud resources like EC2, RDS, etc. Additionally, the deployment process was manual which increased the chances of unforced human errors and configuration discrepancies. Configuration management took a long time which further slowed down the deployment process. Furthermore, there was no centralized mechanism for user management, log management, and cron job monitoring.
For AWS cloud development the built-in choice for infrastructure as code (IAC) is AWS CloudFormation. However, before building the AWS Cloudformation (CF) templates, Powerup conducted a thorough assessment of the customer’s existing infrastructure to identify the gaps and plan the template preparation phase accordingly. Below were a few key findings from their assessment:
Termination Protection was not enabled to many EC2 instances
IAM Password policy was not implemented
Root Multi-Factor Authentication (MFA) was not enabled
IAM roles were not used to access the AWS services from EC2 instances
CloudTrail was not integrated with Cloudwatch logs
S3 Access logs for Cloudtrail S3 bucket was not enabled
Log Metric was not enabled for Unauthorised API Calls; Using ROOT Account to access the AWS Console; IAM Policy changes; Changes to CloudTrail, CloudConfig, S3 Bucket policy; Alarm for any security group changes, NACL, RouteTable, VPCs
SSH ports of few security groups were open to Public
VPC Flow logs were not enabled for few VPCs
Powerup migrated their monolithic service into smaller independent services which are self-deployable, sustainable, and scalable. They also set up CI/CD using Jenkins and Ansible. Centralized user management was implemented using FreeIPA, while ELK stack was used to implement centralized log management. Healthcheck.io was used to implement centralized cron job monitoring.
CloudFormation (CF) Templates were then used in the creation of the complete AWS environment. The template can be reused to create multiple environments in the future. 20 Microservices in the stage environment was deployed and handed over to the customer team for validation. Powerup also shared the Ansible playbook which helps in setting up the following components – Server Hardening / Jenkins / Metabase / FreeIPA / Repository.
The below illustrates the architecture:
Different VPCs are provisioned for Stage, Production, and Infra management. VPC peering is established from Infra VPC to Production / Stage VPC.
VPN tunnel is established between the customs office to AWS Infra VPC for the SSH access / Infra tool access.
All layers except the elastic load balancer are configured in a private subnet.
Separate security group configured for each layer like DB / Cache / Queue / App / ELB / Infra security groups. Only required Inbound / Outbound rules.
Amazon ECS is configured in Auto-scaling mode. So the ECS workers will scale horizontally based on the Load to the entire ECS cluster.
Service level scaling is implemented for each service to scale the individual service automatically based on the load.
Elasticache (Redis) is used to store the end-user session
A highly available RabbitMQ cluster is configured. RabbitMQ is used as messaging broker between the microservices.
For MySQL and Postgresql, RDS Multi-AZ is configured. MongoDB is configured in Master-slave mode.
IAM roles are configured for accessing the AWS resources like S3 from EC2 instances.
VPC flow logs/cloud trail / Cloud Config are enabled for logging purposes. The logs are streamed into AWS Elasticsearch services using AWS Lambda. Alerts are configured for critical events like instance termination, IAM user deletion, Security group updates, etc.
AWS system manager is used to manage to collect the OS, Application, instance metadata of EC2 instances for inventory management.
AMIs and backups are configured for business continuity.
Jenkins is configured for CI / CD process.
CloudFormation template is being used for provisioning/updating of the environment.
Ansible is used as configuration management for all the server configurations like Jenkins / Bastion / FreeIPA etc.
Sensu monitoring system is configured to monitor system performance
New Relic is configured for application performance monitoring and deployment tracking
Amazon Redshift, free IPA, Amazon RDS, Redis.
IaC enabled customers to spin up an entire infrastructure architecture by running a script. This will allow the customer to not only deploy virtual servers, but also launch pre-configured databases, network infrastructure, storage systems, load balancers, and any other cloud service that is needed. IaC completely standardized the setup of infrastructure, thereby decreasing the chances of any incompatibility issues with infrastructure and applications that can run more smoothly. IaC is helpful for risk mitigation because the code can be version-controlled, every change in the server configuration is documented, logged, and tracked. And these configurations can be tested, just like code. So if there is an issue with the new setup configuration, it can be pinpointed and corrected much more easily, minimizing the risk of issues or failure.
Developer productivity drastically increases with the use of IaC. Cloud architectures can be easily deployed in multiple stages to make the software development life cycle much more efficient.
Tools used & AWS Services used – Compute – EC2,EKS,ECR,Lambda, Shared storage – SFTP,EFS, Database – RDS Postgres, Advanced networking – Route53, route 53 resolver , custom DHCP, Security – AWS IAM, Active Directory, CloudTrail, AWS Config, IAAS CloudFormation, Other Services – Terraform, Jenkins with sonarQube, Nexus and Clair
The customer is regarded as global insurance giants of the financial sector. ABS is their consolidated insurance system that they are looking at migrating to AWS along with its supporting applications. They also wanted Powerup to create a Disaster Recovery facility on AWS and make the ABS insurance system available as a backup solution for one of their esteemed banking clients while also catering to a business continuity strategy, automation of applications and security & compliance.
The Customer is a German multinational, one of the leading integrated financial services company, headquartered in Munich. Their core business caters to offering products and services in insurance and asset management.
Problem statement / Objective
ABS is a monolithic application while the supporting applications are microservices-based. Hence, a microservice architecture which can seamlessly integrate with the customer’s core insurance module was needed.
They wanted Powerup to deploy their applications on production as well as on a secondary (Disaster Recovery) DR facility on AWS using a Continuous Integration (CI)/ Continuous Deployment (CD) pipeline. This was to serve as a Business Continuity solution for one of their esteemed banking clients.
For business continuity, the customer anticipated the Recovery Time Objective (RTO) of less than 4hr and Recovery Point Objective (RPO) of not more than 24 hours.
In addition to infrastructure deployment, all application deployments were requested to be automated by the client. Being a financial services company, the customer is bound by multiple regulatory and compliance-related obligations for which Cloud Best Security practices were also to be instrumented.
AWS Landing Zone was set up with the following accounts – Organization Account, Production Account, Dev, Pre-Prod, Management, DR, Centralized Logging & Security Account.
The operational unit consisted of the customer business system (i.e., CISL (Core insurance layer), RAP (Rich Application), MFDB (Core application Database), CTRLM (Batch job automation)) and Non-ABS (Non-customer business system i.e., dispatcher).
All Logs will be centrally stored in the logging account. All management applications like Control-M, AD, Jenkins etc. will be deployed in the management account.
ABS application is deployed across multiple AZs and load balanced using AWS Application load balancer. Non-ABS applications are microservices-based and talk to the ABS running to process or fetch the required data based on request. Close to over 10 microservices are running on Docker within the EKS cluster.
Auto-scaling is enabled at the service level as well as EC2 level to scale out the microservices based on the load. The application uses Active Directory to authenticate.
Amazon Elastic Kubernetes Service (EKS) backed the highly available, reliable and decoupled API services which are accessible only inside the customer’s private global shared network. Each module is segregated with the namespace.
Jenkins pipelines were used to build automation, Nexus tool to store artifacts and Clair for checking vulnerabilities. Build Artifact Vulnerability management was made easy with the aid of SonarQube.
Active passive Disaster recovery
Actively synchronised AWS Secure File Transfer Protocol (SFTP) is the active directory and private file storage space on the cloud.
Powerup methodically designed and tested a cross-account and cross-region disaster recovery strategy. At the time of live deployment, docker images are tagged (with versioning) and shipped to Amazon Elastic Container Register (ECR) DR account. Encrypted (Amazon Machine Image) AMIs and Relational Database Service (RDS) snapshots are passively shipped to DR account with a Recovery Point Objective (RPO) of 3 hours.
Custom coupled Lambda functions are used to generate, ship and eliminate encrypted AMIs and snapshots to DR accounts with no human intervention as a backup solution.
Advanced strategy to ensure the best security
Custom cloud formation template helped in monitoring AWS API calls made to Change or update configurations of IAM roles / SecurityGroups inbound or outbound rules/ EC2. Granular rules are followed in the AWS config for maintaining and remediating as per regulatory compliance.
The customer’s network setup was the biggest issue faced. In AWS, the network was completely private, an environment without Internet Gateway (i.e., direct internet access) and Network Address Translation (NAT) because of which a custom Dynamic Host Configuration Protocol (DHCP) option set had to be used to cope up with an existing custom DNS server which was set up in the customer Shared Service account alongside a custom proxy setup for the internet. The most challenging part was registering the worker nodes to Master in EKS as some of the internal kubelet components were failing due to enterprise proxy and custom DNS servers. In order to fix this, AWS private link, route 53 resolver and Kubernetes configMap were fine-tuned effectively.
The ABS insurance application was successfully deployed on AWS environment while meeting all security & high availability guidelines as per the stated compliance directives.
During load tests, the application was found to be able to handle 200 concurrent users successfully.
Microservices helped in ‘easier to build and maintain’ application programming interface (API) services. Flexibility and scalability of different API applications were also achieved.
The customer could maintain the lifecycle of identifying, investigating and prioritizing vulnerabilities in code as well as containers without any compromise.
The customer could now implement strong access and control measures and maintain an information security policy.
Tabletop run-through and DR scenario simulations ensured business continuity.