Rearchitect AWS EKS web application for Azure Kubernetes Service (AKS)

2024-12-13

Now that you have a better understanding of the platform differences between AWS and Azure, let's examine the web application architecture on AWS and the modifications needed to make it compatible with Azure Kubernetes Service (AKS).

Yelb application architecture

The Yelb sample web application consists of a front-end component called yelb-ui and an application component called yelb-appserver.

Architecture diagram of the Yelb web application.

The yelb-ui serves JavaScript code to the browser. This code is compiled from an Angular application. The yelb-ui component might also include an nginx proxy depending on the deployment model. The yelb-appserver is a Sinatra application that interacts with a cache server (redis-server) and a Postgres back-end database (yelb-db). Redis Cache stores the number of page views, while PostgreSQL persists the votes. Both services are deployed on Kubernetes without using any managed service for storing data on AWS or Azure.

The original Yelb application is self-contained and doesn't rely on external services, so you can migrate it from AWS to Azure without any code changes. On Azure, you can use Azure Cache for Redis and Azure Database for PostgreSQL as replacements for the Redis Cache and PostgreSQL services deployed on AKS.

The sample Yelb application allows users to vote on a set of alternatives (restaurants) and dynamically updates pie charts based on the number of votes received. The application also keeps track of the number of page views and displays the hostname of the yelb-appserver instance serving the API request upon a vote or a page refresh. This feature enables you to demo the application independently or collaboratively.

Screenshot of the Yelb service interface.

Architecture on AWS

To help protect web applications and APIs from common web exploits, AWS offers AWS Web Application Firewall (WAF) and AWS Firewall Manager.

Map AWS services to Azure services

To recreate the AWS workload in Azure with minimal changes, use an Azure equivalent for each AWS service. The following table summarizes the service mappings:

Service mapping	AWS service	Azure service
Web access firewall	AWS Web Application Firewall (WAF)	Azure Web Application Firewall (WAF)
Application load balancing	Application Load Balancer (ALB)	Azure Application Gateway Application Gateway for Containers (AGC)
Content delivery network	Amazon CloudFront	Azure Front Door (AFD)
Orchestration	Elastic Kubernetes Service (EKS)	Azure Kubernetes Service (AKS)
Secrets vault	AWS Key Management Service (KMS)	Azure Key Vault
Container registry	Amazon Elastic Container Registry (ECR)	Azure Container Registry (ACR)
Domain Name System (DNS)	Amazon Route 53	Azure DNS
Caching	Amazon ElastiCache	Azure Cache for Redis
NoSQL	Amazon DynamoDB	Azure Database for PostgreSQL

For a comprehensive comparison between Azure and AWS services, see AWS to Azure services comparison.

Architecture on Azure

In this solution, the Yelb application is deployed to an AKS cluster and is exposed via an ingress controller like the NGINX ingress controller. The ingress controller service is exposed via an internal (or private) load balancer. For more information on how to use an internal load balancer to restrict access to your applications in AKS, see Use an internal load balancer with Azure Kubernetes Service (AKS).

This sample supports installing a managed NGINX ingress controller with the application routing add-on or an unmanaged NGINX ingress controller using the Helm chart. The application routing add-on with NGINX ingress controller provides the following features:

Easy configuration of managed NGINX ingress controllers based on Kubernetes NGINX ingress controller.
Integration with Azure DNS for public and private zone management.
SSL termination with certificates stored in Azure Key Vault.

For other configurations, see the following articles:

The Yelb application is secured with an Azure Application Gateway resource deployed in a dedicated subnet within the same virtual network as the AKS cluster or in a peered virtual network. You can secure access to the Yelb application using Azure Web Application Firewall (WAF), which provides centralized protection of web applications from common exploits and vulnerabilities.

Solution architecture design

The following diagram shows the recommended architecture on Azure:

The solution architecture consists of the following:

The Application Gateway handles TLS termination and communicates with the backend application over HTTPS.
The Application Gateway Listener uses an SSL certificate obtained from Azure Key Vault.
The Azure WAF Policy associated to the Listener runs OWASP rules and custom rules against the incoming requests and blocks malicious attacks.
The Application Gateway Backend HTTP Settings invoke the Yelb application via HTTPS on port 443.
The Application Gateway Backend Pool and Health Probe call the NGINX ingress controller through the AKS internal load balancer using HTTPS.
The NGINX ingress controller uses the AKS internal load balancer.
The AKS cluster is configured with the Azure Key Vault provider for Secrets Store CSI Driver add-on to retrieve secrets, certificates, and keys from Azure Key Vault via a CSI volume.
A SecretProviderClass retrieves the same certificate used by the Application Gateway from Azure Key Vault.
An Kubernetes ingress object employs the NGINX ingress controller to expose the application via HTTPS through the AKS internal load balancer.
The Yelb service is of type ClusterIP and is exposed via the NGINX ingress controller.

For comprehensive instructions on deploying the Yelb application on AKS using this architecture, see the companion sample.

Alternative solutions

Azure offers several options for deploying a web application on an AKS cluster and securing it with a web application firewall:

The Application Gateway Ingress Controller (AGIC) is a Kubernetes application, so you can leverage Azure's native Application Gateway L7 load-balancer to expose cloud software to the Internet for your Azure Kubernetes Service (AKS) workloads. AGIC monitors the Kubernetes cluster it's hosted on and continuously updates an Application Gateway so that selected services are exposed to the Internet.

The Ingress Controller runs in its own pod on the AKS cluster. AGIC monitors a subset of Kubernetes Resources for changes, translates the state of the cluster to an Application Gateway specific configuration, and applies it to Azure Resource Manager (ARM). For more information, see What is Application Gateway Ingress Controller?.

The following table outlines advantages and disadvantages of the Application Gateway Ingress Controller (AGIC):

Advantages	Disadvantages
* Native integration: AGIC provides native integration with Azure services, specifically Azure Application Gateway, which allows for seamless and efficient routing of traffic to services running on AKS. * Simplified deployments: Deploying AGIC as an AKS add-on is straightforward and simpler compared to other methods. It enables a quick and easy setup of an Application Gateway and an AKS cluster with AGIC enabled. * Fully managed service: AGIC as an add-on is a fully managed service, providing benefits such as automatic updates and increased support from Microsoft. It ensures the Ingress Controller remains up-to-date and adds an extra layer of support.	* Single cloud approach: AGIC is primarily adopted by customers who adopt a single-cloud approach. It might not be the best choice if you require a multicloud architecture where deployment across different cloud platforms is a requirement. In this case, you might want to use a cloud-agnostic ingress controller such as NGINX, Traefik, or HAProxy to avoid vendo-lockin issues.

Advantages

Disadvantages

* Native integration: AGIC provides native integration with Azure services, specifically Azure Application Gateway, which allows for seamless and efficient routing of traffic to services running on AKS.
* Simplified deployments: Deploying AGIC as an AKS add-on is straightforward and simpler compared to other methods. It enables a quick and easy setup of an Application Gateway and an AKS cluster with AGIC enabled.
* Fully managed service: AGIC as an add-on is a fully managed service, providing benefits such as automatic updates and increased support from Microsoft. It ensures the Ingress Controller remains up-to-date and adds an extra layer of support.

* Single cloud approach: AGIC is primarily adopted by customers who adopt a single-cloud approach. It might not be the best choice if you require a multicloud architecture where deployment across different cloud platforms is a requirement. In this case, you might want to use a cloud-agnostic ingress controller such as NGINX, Traefik, or HAProxy to avoid vendo-lockin issues.

For more information, see the following resources:

Azure Application Gateway for Containers provides load balancing and dynamic traffic management for applications in Kubernetes clusters.

Key features

Azure Application Gateway for Containers builds upon the capabilities of Application Gateway Ingress Controller (AGIC) and allows you to use Azure's native Application Gateway load balancer. Key features include:

Load balancing: Efficiently distributes incoming traffic across multiple containers for optimal performance and scalability.
Gateway API implementation: Supports the Gateway API, allowing you to define routing rules and policies in a Kubernetes-native way.
Custom health probes: Define custom health probes to monitor container health and automatically route traffic away from unhealthy instances.
Session affinity: Provides session affinity, routing subsequent requests from the same client to the same container for a consistent user experience.
TLS policy: Supports TLS termination, allowing SSL/TLS encryption and decryption to be offloaded to the gateway.
Header rewrites: Rewrite HTTP headers of client requests and responses from backend targets using the IngressExtension custom resource definition. For more information, see Ingress API and Gateway API.
URL rewrites: Modify the URL of client requests, including hostname and/or path, and include the newly rewritten URL when initiating requests to backend targets. For more information, see Ingress API and Gateway API.

Limitations

Currently, Azure Application Gateway for Containers doesn't support the following features:

For more information, see Deploying an Azure Kubernetes Service (AKS) Cluster with Application Gateway for Containers.

Azure Front Door is global layer 7 load balancer that securely exposes and protects workloads running in AKS using the Azure Web Application Firewall and an Azure Private Link service.

This solution uses Azure Front Door Premium, end-to-end TLS encryption, Azure Web Application Firewall, and a Private Link service to securely expose and protect a workload that runs in AKS.

Azure Front Door TLS and Secure Sockets Layer (SSL) offload capability to terminate TLS connections and decrypt incoming traffic at the front door. Azure Front Door reencrypts the incoming traffic before forwarding it to the AKS-hosted web application. This practice enforces end-to-end TLS encryption for the entire request process, from the client to the origin. For more information, see Secure your origin with Private Link in Azure Front Door Premium.

The NGINX ingress controller exposes the AKS-hosted web application. It's configured to use a private IP address as a front-end IP configuration of the kubernetes-internal internal load balancer, and it uses HTTPS as the transport protocol to expose the web application. For more information, see Create an ingress controller by using an internal IP address.

We recommend this solution for scenarios where you're deploying the same web application across multiple regional AKS clusters for business continuity and disaster recovery, or even across multiple cloud platforms or on-premises installations. In this case, Front Door can forward incoming calls to one of the backends (also known as origins) using one of the following routing methods:

Latency: Latency-based routing ensures that requests are sent to the lowest latency origins acceptable within a sensitivity range. In other words, requests get sent to the nearest set of origins in respect to network latency.
Priority: You can set priorities to origins when you want to configure a primary origin to service all traffic. The secondary origin can be a backup in case the primary origin becomes unavailable.
Weighted: You can assign a weight to your origins when you want to distribute traffic across a set of origins evenly or according to the weight coefficients. Traffic gets distributed by the weight value if the latencies of the origins are within the acceptable latency sensitivity range in the origin group.
Session affinity: You can configure session affinity for your frontend hosts or domains to ensure requests from the same end user gets sent to the same origin.

For more information, see Use Azure Front Door to secure AKS workloads.

Share via