How IAG accelerated service-to-service communication with Amazon VPC Lattice

Insurance Australia Group Limited (IAG) is the largest general insurance company in Australia and New Zealand. It operates major insurance brands like NRMA Insurance, CGU, SGIO, and NZI. IAG’s modern serverless digital engineering platform is built on AWS to host digital components, microservices, and customer experiences. It provides unified patterns, consistent delivery, and strong governance, allowing fast, secure, and scalable development. It is Platform-as-a-Service (PaaS) with consistent controls, governance, tooling, and DevSecOps practices. This platform allows millions of customers to manage and purchase their insurance products through various digital channels and experiences.

Prerequisites

Before proceeding, you should be familiar with the following concepts:

• A basic understanding of Amazon Virtual Private Network (Amazon VPC) networking concepts.
• Familiarity with Amazon VPC Lattice and its key features such as Lattice Service Networks and Lattice Services. In IAG’s solution, only Lattice Services are used (not Resources) because the targets are HTTP/Lambda endpoints.
• A basic understanding on AWS Serverless architectures and how AWS Lambda is used to represent different microservices.

Previous state architecture

IAG built an Acrux serverless platform based on microservices interacting with each other, with different AWS Lambda Functions acting as services. If a service wants to make a request to another service, it does so through the public API Gateway across the internet, meaning the request from the source service needs to route through an AWS Transit Gateway and exit through a forward proxy in order to reach the target service Lamda (which actually lives in the same subnet all along).

Figure 1: Service-to-Service connectivity through egress Proxy

The following steps show how traffic flows from Service-A to Service-B.

• (1)  Service A Lambda performs a DNS lookup for Service B custom domain (e.g. serviceb.example.com). Route 53 Private Hosted Zone resolves domain name and returns publicly routable IP address.
• (2)  Service A sends a request through the AWS Transit Gateway (TGW). The TGW route table is configured so that the destination CIDRs are routed through the TGW.
• (3)  TGW routes traffic to Egress VPC where a forward proxy fleet will route traffic to the internet.
• (4)  The request will be routed to the public Amazon API Gateway
• (5)  Amazon API Gateway will forward the request to Service B

This approach introduces traffic overhead across multiple network layers, increasing latency for the source service. The problem compounds when the target microservice needs to communicate with downstream services—each additional hop through the public internet further degrades performance, creating a cascading latency effect. The source service also has the API Gateway endpoint of the target service hardcoded in it’s codebase, meaning anytime the target service endpoint is updated, the source service also needs to update its code.

Solution overview

A solution was required to address the suboptimal network connectivity from one service to another. In 2024, IAG explored different options to solve this problem, and they came across Amazon VPC Lattice. Amazon VPC Lattice that allows secure and simplified network connectivity between services. IAG ran a proof-of-concept and proved technically that the solution is viable.

In their implementation, IAG created three Lattice Service Networks (Development, Staging, and Prod) for clear separation of environments – all in their Management AWS account. Each Service Network is shared with its matching AWS account using AWS Resource Access Manager (RAM) for example, a Development Service Network shared with Development AWS Account. The VPC in each of these accounts is then associated with its respective Service Network. The following figure depicts this:

Figure 2: IAG Lattice Service Network design

An Auth Policy is created and associated to each of the Service Networks, allowing traffic only from the VPC where all the Lambda functions exist. Below is an example Auth Policy on a Service Network allowing traffic only from a particular VPC.

{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "vpc-lattice-svcs:Invoke",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "vpc-lattice-svcs:SourceVpc": "vpc-0123456789abcdefg"
        }
      }
    }
  ]
}

IAG created Lattice services specifically for any AWS Lambda function required to be called by other service, making them accessible and discoverable through VPC Lattice. These services all exist in one VPC. The following figure shows the new architecture using VPC Lattice and how two services communicate, taking an example of the production environment.

Figure 3: Service-to-Service connectivity using VPC Lattice

• (1)  As before, Service-A Lambda resolves Service-B’s custom domain (e.g. serviceb.example.com) via Route 53, but now the Private Hosted Zone maps it to the VPC Lattice service FQDN rather than the public internet path. The resolver returns an IP address managed by VPC Lattice.
• (2)  Service-B connects to the service using HTTPS.
• (3)  Requests are sent to the Service-B destination target, which is an AWS Lambda function. Lambda target groups are limited to a single Lambda function target.

So instead of routing through the AWS Transit Gateway and out to the internet through the egress fleet, IAG have reduced the number of hops. The overall security posture has also improved because traffic now routes privately on AWS network, along with improving operational efficiency by removing unnecessary touch points.

Performance testing

Following the migration to Amazon VPC Lattice, IAG observed significant performance improvements. IAG used JMeter and Selenium for their testing, which included tools that allowed them to measure latency between services between AWS Lambda functions with and without VPC Lattice. Testing showed that IAG reduced average inter-service latency by 46% to 83% across their main services on their Serverless platform, with P95 latency ranging from 15% to 92%. This is an improvement to IAG’s previous architecture.

Considerations

• IAG is currently using Service Network Auth Policy to permit anonymous access by the Lambda function services from the same VPC (coarse-grained auth policy). IAG is pushing for the consumers of the platform to configure their Lattice services with their own Auth Policy and only accepting requests from approved Lambda functions by using SigV4 signing.
• Today, the platform uses a 1:1 Service Network–to–VPC association model. IAG is evolving this to support cross-account VPC associations by introducing Route 53 private hosted zones for each custom domain and attaching the relevant environment VPCs to the appropriate environment-specific zone.
• The event structure received by platform consumers is different from the standard AWS API Gateway event format. As a result, teams were required to make updates to their handler functions to correctly parse incoming events.

Conclusion

The move to Amazon VPC Lattice delivered latency reductions of 46–83% across IAG’s core serverless services. For teams running serverless microservices on AWS, VPC Lattice provides a way to simplify inter-service networking while reducing latency. IAG’s results show what is possible when replacing multi-hop public internet routing with direct connectivity within AWS.

To learn more about VPC Lattice, refer to the VPC Lattice documentation.

About the authors