How Munich Re Automation Options Ltd constructed a digital insurance coverage platform on AWS

Underwriting for all times insurance coverage may be fairly handbook and sometimes time-intensive with plenty of re-keying by advisers earlier than underwriting selections may be made and insurance policies lastly issued. Within the digital age, individuals buying life insurance coverage need self-service interactions with their potential insurer. Folks need pace of transaction with time to cowl decreased from days to minutes. Whereas this has been achieved within the basic insurance coverage area with on-line automotive and residential insurance coverage journeys, this isn’t at all times the case within the life insurance coverage area. That is the place Munich Re Automation Options Ltd (MRAS) provides its prospects, a aggressive edge to shrink the quote-to-fulfilment course of utilizing their ALLFINANZ answer.

ALLFINANZ is a cloud-based life insurance coverage and analytics answer to underwrite new life insurance coverage enterprise. It’s designed to remodel the tip client’s journey, delivering all the pieces they should turn into a policyholder. The core digital companies provided to all ALLFINANZ prospects embrace Rulebook Hub, Threat Evaluation Interview supply, Resolution Engine, deep analytics (together with predictive modeling capabilities), and technical integration companies—for instance, API integration and SSO integration.

Present state structure

The ALLFINANZ software started as a standard three-tier structure deployed inside a datacenter. As MRAS migrated their workload to the AWS cloud, they checked out their regulatory necessities and the expertise stack, and selected the silo mannequin of the multi-tenant SaaS system. Every tenant is supplied a devoted Amazon Digital Non-public Cloud (VPC) that holds community and software elements, absolutely remoted from different major insurers.

As an entry level into the ALLFINANZ setting, MRAS makes use of Amazon Route 53 to route incoming site visitors to the suitable Amazon VPC. The routing depends on a mannequin the place subdomains are assigned to every tenant, for instance the subdomain allfinanz.tenant1.munichre.cloud is the subdomain for tenant 1. The diagram under exhibits the ALLFINANZ structure. Observe: not all hyperlinks between elements are proven right here for simplicity.

Determine 1. Present high-level answer structure for the ALLFINANZ answer

1. The answer makes use of Route 53 because the DNS service, which offers two entry factors to the SaaS answer for MRAS prospects:
   • The URL allfinanz.<tenant-id>.munichre.cloud permits person entry to the ALLFINANZ Interview Display screen (AIS). The AIS can exist as a standalone software, or may be built-in with a buyer’s wider digital point-of -sale course of.
   • The URL api.allfinanz.<tenant-id>.munichre.cloud is used for accessing the appliance’s Internet companies and REST APIs.
2. Site visitors from each entry factors flows via the load balancers. Whereas HTTP/S site visitors from the appliance person entry entry level flows via an Software Load Balancer (ALB), TCP site visitors from the REST API purchasers flows via a Community Load Balancer (NLB). Transport Layer Safety (TLS) termination for person site visitors occurs on the ALB utilizing certificates supplied by the AWS Certificates Supervisor.  Safe communication over the general public community is enforced via TLS validation of the server’s identification.
3. Not like software person entry site visitors, REST API purchasers use mutual TLS authentication to authenticate a buyer’s server. Since NLB doesn’t help mutual TLS, MRAS opted for an answer to go this site visitors to a backend NGINX server for the TLS termination. Mutual TLS is enforced by utilizing self-signed consumer and server certificates issued by a certificates authority that each the consumer and the server belief.
4. Authenticated site visitors from ALB and NGINX servers is routed to EC2 situations internet hosting the appliance logic. These EC2 situations are hosted in an auto-scaling group spanning two Availability Zones (AZs) to offer excessive availability and elasticity, due to this fact, permitting the appliance to scale to fulfill fluctuating demand.
5. Software transactions are endured within the backend Amazon Relational Database Service MySQL situations. This database layer is configured throughout multi-AZs, offering excessive availability and computerized failover.
6. The applying requires the aptitude to combine proof from information sources exterior to the ALLFINANZ service. This message sharing is enabled via the Amazon MQ managed message dealer service for Apache Lively MQ.
7. Amazon CloudWatch is used for end-to-end platform monitoring via logs assortment and software and infrastructure metrics and alerts to help ongoing visibility of the well being of the appliance.
8. Software program deployment and related infrastructure provisioning is automated via infrastructure as code utilizing a mixture of Git, Amazon CodeCommit, Ansible, and Terraform.
9. Amazon GuardDuty constantly displays the appliance for malicious exercise and delivers detailed safety findings for visibility and remediation. GuardDuty additionally permits MRAS to offer proof of the appliance’s robust safety posture to fulfill audit and regulatory necessities.

Excessive availability, resiliency, and safety

MRAS deploys their answer throughout a number of AWS AZs to fulfill high-availability necessities and guarantee operational resiliency. If one AZ has an ongoing occasion, the answer will stay operational, as there are situations receiving manufacturing site visitors in one other AZ. As described above, that is achieved utilizing ALBs and NLBs to distribute requests to the appliance subnets throughout AZs.

The ALLFINANZ answer makes use of non-public subnets to segregate core software elements and the database storage platform. Safety teams present networking safety measures on the elastic community interface degree. MRAS limit entry from incoming connection requests to ranges of IP addresses by attaching safety teams to the ALBs. Amazon Inspector displays workloads for software program vulnerabilities and unintended community publicity. AWS WAF is built-in with the ALB to guard from SQL injection or cross-site scripting assaults on the appliance.

Optimizing the present workload

One of many key advantages of this structure is that now MRAS can standardize the infrastructure configuration and guarantee constant versioning of the workload throughout tenants. This makes onboarding new tenants so simple as provisioning one other VPC with the identical infrastructure footprint.

MRAS are persevering with to optimize their structure iteratively, analyzing elements to modernize to cloud-native elements and evolving in the direction of the pool mannequin of multi-tenant SaaS structure wherever doable. For instance, MRAS centralized their per-tenant NAT gateway deployment to a centralized outbound Web routing design utilizing AWS Transit Gateway, saving roughly 30% on their general NAT gateway spend.

Conclusion

The AWS world infrastructure has allowed MRAS to serve greater than 40 prospects in 5 AWS areas world wide. This answer improves prospects’ expertise and workload maintainability by standardizing and automating the infrastructure and workload configuration inside a SaaS mannequin, in contrast with a number of variations for the on-premise deployments. SaaS prospects are additionally freed up from the undifferentiated heavy lifting of infrastructure operations, permitting them to give attention to their enterprise of underwriting for all times insurance coverage.

MRAS used the AWS Nicely-Architected Framework to evaluate their structure and listing key suggestions. AWS additionally provides Nicely-Architected SaaS Lens and AWS SaaS Manufacturing unit Program, with a set of assets to empower and allow insurers at any stage of their SaaS on AWS journey.