Securing API Gateways with AWS ALB and Mutual TLS Authentication

Australia's regulated industries — from the big four banks in Sydney and Melbourne to healthcare providers handling My Health Record data — are tightening API security to comply with the Privacy Act 1988 and the Notifiable Data Breaches scheme. Mutual TLS has become a practical answer for organisations that need cryptographically strong client identity without leaning entirely on short-lived tokens. AWS Application Load Balancers now offer native mutual TLS termination, which lets infrastructure teams in Brisbane boardrooms and Perth operations centres protect north-south traffic without bolting on a third-party gateway.

When combined with Amazon API Gateway, an ALB fronted with mTLS gives you defence-in-depth: the load balancer validates client certificates at the TLS handshake, while API Gateway continues to enforce throttling, usage plans, and Lambda authorisers. The following walkthrough covers the configuration steps, certificate requirements, and operational realities that come up when rolling this out across Australian workloads.

Understanding Mutual TLS and Why It Matters for APIs

Standard TLS authenticates the server to the client. Mutual TLS flips the script by requiring the client to present an X.509 certificate during the TLS handshake, which the server then validates against a trusted certificate authority. Once the certificate chain is verified, the server extracts the certificate subject and passes it downstream as HTTP headers, giving backend services a reliable client identity.

For Australian financial services operating under APRA CPS 234, mTLS shrinks the attack surface for credential stuffing and replay attacks. It also removes the need to manage shared secrets with partners and suppliers, which matters for energy companies in the Pilbara coordinating telemetry with downstream logistics partners.

Prerequisites: Certificates, Trust Stores, and AWS ACM

Before touching the load balancer, you need a private CA hierarchy. Most teams in Melbourne and Sydney use AWS Private Certificate Authority, which integrates directly with ACM and supports short-lived certificates. Export the root CA certificate and any intermediate CAs as a PEM bundle — this becomes the trust store the ALB uses to validate incoming client certificates.

Generate client certificates for each calling service or partner. In Australian government contexts, such as data.gov.au integrations, certificate subject fields typically encode the agency's ABN or a recognised service identifier. Store client certs in AWS Secrets Manager or Hashicorp Vault, and rotate them on a schedule that aligns with the ACSC's Essential Eight recommendations.

Configuring the ALB Listener for mTLS

Create an HTTPS listener on port 443 and upload the server certificate in ACM. Under the security policy, choose a modern TLS policy such as ELBSecurityPolicy-TLS13-1-2-2021-06, which the ACSC considers appropriate for protecting sensitive data. Enable mutual authentication and paste the PEM trust store bundle into the advertised CA certificate field.

Set the client certificate handling mode to "verify" — the ALB rejects any handshake where the client cert fails to chain back to a trusted issuer. For partners connecting from interstate offices over the NBN, certificate verification happens during the first handshake, so the overhead is negligible compared to the alternative of running a full authentication request through the application layer.

Setting Up Target Groups and Backend Authentication

Map the verified client cert through to a target group running API Gateway or EC2 instances. The ALB injects the client certificate into request headers, commonly X-Amzn-Mtls-Clientcert, which API Gateway can forward as a context value into Lambda authorisers. This lets a Lambda function decide whether the calling system holds a valid role within your tenancy.

For internal microservices running on Amazon ECS in the ap-southeast-2 Sydney region, you can chain validation through IAM and service-to-service mTLS. Hybrid teams connecting from on-premises in Adelaide or Canberra benefit from this layering because legacy systems often lack native client certificate support, and the ALB takes on that responsibility.

Integrating with API Gateway and Lambda Authorisers

When API Gateway sits behind an mTLS ALB, disable IAM authorisation on the gateway itself to avoid double handshakes. Instead, configure a Lambda authoriser that inspects the certificate subject, issuer DN, and serial number. Reject requests whose certificates are revoked against an OCSP responder or a local CRL hosted in S3.

This pattern works well for Australian fintechs processing payments between AEST and AEDT business windows, where certificate revocation lists can be cached for the duration of a trading day. Logging the certificate fingerprint to CloudWatch also helps satisfy audit trails required by the Notifiable Data Breaches scheme if a compromised key is later identified.

Troubleshooting Common mTLS Issues

The most common problem Australian teams encounter is a failed chain validation because the trust bundle only contains the root, not the intermediate. Upload the full chain in PEM order — leaf, intermediates, root — even though only the issuer side matters for verification. Another frequent gotcha is a client cert signed by a different region; Private CA resources are regional, so a cert issued in Sydney will not automatically trust a CA created in Frankfurt.

A third issue involves TLS version mismatches with older partners. Some government agencies still run Java 8 clients that default to TLS 1.0, which the modern security policies reject. Negotiate an upgrade path, or carve out an exception only when justified under ACSC guidance.

Operational Considerations and Monitoring

Track failed handshakes through ALB connection logs in S3. Alert on spikes — a sudden surge of failed mTLS validations from a single CIDR range is often a misconfigured partner integration or an active probing attempt. Certificate expiry monitoring should be automated, since Australian regulators expect certificates protecting payment data to never lapse.

Review trust store contents quarterly. Remove revoked or replaced CAs, and document the business owner of each issuer. Operational discipline here keeps the trust chain tight and avoids the messy rollback of accidentally trusting a partner's test CA in production.

Practical Recommendations for Rolling Out ALB mTLS

• Start with a non-production workload in the ap-southeast-2 region to validate the trust chain before exposing anything to partners.
• Use AWS Private CA rather than running your own OpenSSL hierarchy, because ACM integration removes most of the plumbing.
• Pin the ALB security policy to TLS 1.3 where clients allow it; fall back to TLS 1.2 only for legacy peers.
• Forward the verified client certificate header to API Gateway and have a Lambda authoriser apply business rules on top.
• Cache OCSP responses to keep verification latency low, especially for high-throughput fintech and telco integrations.
• Automate certificate rotation with shorter validity periods, aligned with the ACSC's advice on cryptographic hygiene.

When configuring the operator dashboards and partner portals that sit alongside this stack, pay attention to the small trust signals those interfaces project, such as what is a favicon, since brand consistency reinforces the same posture that mTLS enforces at the network layer for Australian users.