Merge pull request #309095 from mbender-ms/agic-clarity-components

AGIC | Maintenance | CAMP | Assisted with clarify and improving Acrolinx on article

Author: denrea

articles/application-gateway/for-containers/application-gateway-for-containers-components.md

@@ -5,88 +5,85 @@ services: application-gateway
 author: mbender-ms
 ms.service: azure-appgw-for-containers
 ms.topic: concept-article
-ms.date: 12/4/2025
+ms.date: 12/05/2025
 ms.author: mbender
 # Customer intent: "As a cloud architect, I want to understand the components of Application Gateway for Containers, so that I can effectively configure and manage traffic routing to backend services in my cloud deployment."
 ---
 
 # Application Gateway for Containers components
 
-This article provides detailed descriptions and requirements for components of Application Gateway for Containers. Information about how Application Gateway for Containers accepts incoming requests and routes them to a backend target is provided. For a general overview of Application Gateway for Containers, see [What is Application Gateway for Containers](overview.md).
+This article provides detailed descriptions and requirements for components of Application Gateway for Containers. It explains how Application Gateway for Containers accepts incoming requests and routes them to a backend target. For a general overview of Application Gateway for Containers, see [What is Application Gateway for Containers](overview.md).
 
 ### Core components
 
 - An Application Gateway for Containers resource is an Azure parent resource that deploys the control plane.
-- The control plane is responsible for orchestrating proxy configuration based on customer intent.
-- Application Gateway for Containers has two child resources; associations and frontends.
-  - Child resources are exclusive to only their parent Application Gateway for Containers and may not be referenced by another Application Gateway for Container resource.
+- The control plane orchestrates proxy configuration based on customer intent.
+- Application Gateway for Containers has two child resources: associations and frontends.
+  - Child resources belong exclusively to their parent Application Gateway for Containers and can't be shared with other Application Gateway for Containers resources.
 
 ### Application Gateway for Containers frontends
 
 - An Application Gateway for Containers frontend resource is an Azure child resource of the Application Gateway for Containers parent resource.
-- An Application Gateway for Containers frontend defines the entry point client traffic should be received by a given Application Gateway for Containers.
-  - Each frontend provides a unique FQDN that can be referenced by a customer's CNAME record.
-  - A frontend can't be associated to more than one Application Gateway for Containers.
-  - Private IP addresses are currently unsupported.
-- A single Application Gateway for Containers can support more than one frontends.
-
->[!Tip]
->A frontend represents a unique entry point for client traffic. Multiple hostnames (such as contoso.com and fabrikam.com) can resolve to the same frontend. If isolation is required, for example, to use the same hostname across different environments, create separate frontends. This allows each environment to reference the same hostname while maintaining distinct routing behavior.
+- An Application Gateway for Containers frontend defines the entry point client traffic uses for a given Application Gateway for Containers.
+  - You can't associate a frontend with more than one Application Gateway for Containers.
+  - You can create a CNAME record by using the unique FQDN that each frontend provides.
+  - Private IP addresses aren't currently supported.
+- A single Application Gateway for Containers can support more than one frontend.
 
 ### Application Gateway for Containers associations
 
 - An Application Gateway for Containers association resource is an Azure child resource of the Application Gateway for Containers parent resource.
-- An Application Gateway for Containers association defines a connection point into a virtual network. An association is a 1:1 mapping of an association resource to an Azure Subnet that has been delegated.
-- Application Gateway for Containers is designed to allow for more than one associations.
-  - At this time, the current number of associations is currently limited to 1.
+- An Application Gateway for Containers association defines a connection point into a virtual network. An association is a 1:1 mapping of an association resource to a delegated Azure Subnet.
+- Application Gateway for Containers is designed to allow for more than one association.
+  - At this time, the current number of associations is limited to 1.
 - During creation of an association, the underlying data plane is provisioned and connected to a subnet within the defined virtual network's subnet.
 - Each association should assume at least 256 addresses are available in the subnet at time of provisioning.
-  - A minimum /24 subnet mask for each deployment (assuming no resources have previously been provisioned in the subnet).
-    - If n number of Application Gateway for Containers are provisioned, with the assumption each Application Gateway for Containers contains one association, and the intent is to share the same subnet, the available required addresses should be n*256.
+  - A minimum /24 subnet mask for each deployment (assuming no resources are previously provisioned in the subnet).
+    - If you plan to deploy multiple Application Gateway for Containers resources that share the same subnet, calculate the required addresses as *n×256*, where *n* equals the number of Application Gateway for Containers resources. This assumes each contains one association.
   - All Application Gateway for Containers association resources should match the same region as the Application Gateway for Containers parent resource.
 
 ### Application Gateway for Containers ALB Controller
 
-- An Application Gateway for Containers ALB Controller is a Kubernetes deployment that orchestrates configuration and deployment of Application Gateway for Containers by watching Kubernetes both Custom Resources and Resource configurations, such as, but not limited to, Ingress, Gateway, and ApplicationLoadBalancer. It uses both ARM / Application Gateway for Containers configuration APIs to propagate configuration to the Application Gateway for Containers Azure deployment.
-- ALB Controller is deployed / installed via Helm.
+- An Application Gateway for Containers ALB Controller is a Kubernetes deployment that orchestrates configuration and deployment of Application Gateway for Containers by watching Kubernetes both Custom Resources and Resource configurations, such as, but not limited to, Ingress, Gateway, and ApplicationLoadBalancer. It uses both ARM and Application Gateway for Containers configuration APIs to propagate configuration to the Application Gateway for Containers Azure deployment.
+- Deploy or install ALB Controller with Helm.
 - ALB Controller consists of two running pods.
-  - alb-controller pod is responsible for orchestrating customer intent to Application Gateway for Containers load balancing configuration.
-  - alb-controller-bootstrap pod is responsible for management of CRDs.
+  - alb-controller pod orchestrates customer intent to Application Gateway for Containers load balancing configuration.
+  - alb-controller-bootstrap pod manages CRDs.
 
 ### Application Gateway for Containers security policy
 
 - An Application Gateway for Containers security policy defines security configurations, such as WAF, for the ALB Controller to consume.
-- More than one security policy may be referred by a single Application Gateway for Containers resource.
+- A single Application Gateway for Containers resource can refer to more than one security policy.
 - At this time, the only security policy type offered is `waf` for web application firewall capabilities.
 - The `waf` security policy is a one-to-one mapping between the security policy resource and a Web Application Firewall policy.
-  - Only one web application firewall policy may be referenced in any number of security policies for a defined Application Gateway for Containers resource.
+  - You can reference only one web application firewall policy in any number of security policies for a defined Application Gateway for Containers resource.
 
 ## Azure / general concepts
 
 ### Private IP address
 
-- A private IP address isn't explicitly defined as an Azure Resource Manager resource. A private IP address would refer to a specific host address within a given virtual network's subnet.
+- A private IP address isn't explicitly defined as an Azure Resource Manager resource. A private IP address refers to a specific host address within a given virtual network's subnet.
 
 ### Subnet delegation
 
-- Microsoft.ServiceNetworking/trafficControllers is the namespace adopted by Application Gateway for Containers and may be delegated to a virtual network's subnet.
-- When delegation occurs, provisioning of Application Gateway for Containers resources doesn't happen, nor is there an exclusive mapping to an Application Gateway for Containers association resource.
-- Any number of subnets can have a subnet delegation that is the same or different to Application Gateway for Containers. Once defined, no other resources, other than the defined service, can be provisioned into the subnet unless explicitly defined by the service's implementation.
+- Microsoft.ServiceNetworking/trafficControllers is the namespace adopted by Application Gateway for Containers and you can delegate it to a virtual network's subnet.
+- When you delegate, you don't provision Application Gateway for Containers resources, nor is there an exclusive mapping to an Application Gateway for Containers association resource.
+- Any number of subnets can have a subnet delegation that is the same or different to Application Gateway for Containers. Once defined, you can't provision other resources into the subnet unless explicitly defined by the service's implementation.
 
 ### User-assigned managed identity
 
 - Managed identities for Azure resources eliminate the need to manage credentials in code.
-- A User Managed Identity is required for each Azure Load Balancer Controller to make changes to Application Gateway for Containers.
+- You need a user-assigned managed identity for each Azure Load Balancer Controller to make changes to Application Gateway for Containers.
 - _AppGw for Containers Configuration Manager_ is a built-in RBAC role that allows ALB Controller to access and configure the Application Gateway for Containers resource.
 
- > [!Note]
-> The _AppGw for Containers Configuration Manager_ role has [data action permissions](../../role-based-access-control/role-definitions.md#control-and-data-actions) that the Owner and Contributor roles do not have. It is critical proper permissions are delegated to prevent issues with ALB Controller making changes to the Application Gateway for Containers service.
+ > [!NOTE]
+ > The _AppGw for Containers Configuration Manager_ role has [data action permissions](../../role-based-access-control/role-definitions.md#control-and-data-actions) that the Owner and Contributor roles don't have. It's critical to delegate proper permissions to prevent issues with ALB Controller making changes to the Application Gateway for Containers service.
 
 ## How Application Gateway for Containers accepts a request
 
-Each Application Gateway for Containers frontend provides a generated Fully Qualified Domain Name managed by Azure. The FQDN may be used as-is or customers may opt to mask the FQDN with a CNAME record.
+Each Application Gateway for Containers frontend provides a generated fully qualified domain name managed by Azure. You can use the FQDN as-is or mask it with a CNAME record.
 
-Before a client sends a request to Application Gateway for Containers, the client resolves a CNAME that points to the frontend's FQDN; or the client may directly resolve the FQDN provided by Application Gateway for Containers by using a DNS server.
+Before a client sends a request to Application Gateway for Containers, the client resolves a CNAME that points to the frontend's FQDN, or the client directly resolves the FQDN provided by Application Gateway for Containers by using a DNS server.
 
 The DNS resolver translates the DNS record to an IP address.
 
@@ -98,34 +95,34 @@ A set of routing rules evaluates how the request for that hostname should be ini
 
 ### HTTP/2 Requests
 
-Application Gateway for Containers supports both HTTP/2 and HTTP/1.1 protocols for communication between the client and the frontend. The HTTP/2 setting is always enabled and can't be changed. If clients prefer to use HTTP/1.1 for their communication to the frontend of Application Gateway for Containers, they may continue to negotiate accordingly.
+Application Gateway for Containers supports both HTTP/2 and HTTP/1.1 protocols for communication between the client and the frontend. The HTTP/2 setting is always enabled and can't be changed. If clients prefer to use HTTP/1.1 for their communication to the frontend of Application Gateway for Containers, they can continue to negotiate accordingly.
 
 Communication between Application Gateway for Containers and the backend target is always via HTTP/1.1, except for gRPC, which uses HTTP/2.
 
 ### Modifications to the request
 
-Application Gateway for Containers inserts three extra headers to all requests before requests are initiated from Application Gateway for Containers to a backend target:
+Application Gateway for Containers inserts three extra headers to all requests before it initiates requests to a backend target:
 
 - x-forwarded-for
 - x-forwarded-proto
 - x-request-id
 
-**x-forwarded-for** is the original requester's client IP address. If the request is coming through a proxy, the header value appends the address received, comma delimited. In example: 1.2.3.4,5.6.7.8; where 1.2.3.4 is the client IP address to the proxy in front of Application Gateway for Containers, and 5.6.7.8 is the address of the proxy forwarding traffic to Application Gateway for Containers.
+**x-forwarded-for** is the original requester's client IP address. If the request comes through a proxy, the header value appends the address it receives, comma delimited. For example: 1.2.3.4,5.6.7.8; where 1.2.3.4 is the client IP address to the proxy in front of Application Gateway for Containers, and 5.6.7.8 is the address of the proxy forwarding traffic to Application Gateway for Containers.
 
-**x-forwarded-proto** returns the protocol received by Application Gateway for Containers from the client. The value is either http or https.
+**x-forwarded-proto** returns the protocol Application Gateway for Containers receives from the client. The value is either http or https.
 
-**x-request-id** is a unique guid generated by Application Gateway for Containers for each client request and presented in the forwarded request to the backend target. The guid consists of 32 alphanumeric characters, separated by dashes (for example: aaaa0000-bb11-2222-33cc-444444dddddd). This guid can be used to correlate a request received by Application Gateway for Containers and initiated to a backend target as defined in access logs.
+**x-request-id** is a unique guid that Application Gateway for Containers generates for each client request and presents in the forwarded request to the backend target. The guid consists of 32 alphanumeric characters, separated by dashes (for example: aaaa0000-bb11-2222-33cc-444444dddddd). You can use this guid to correlate a request that Application Gateway for Containers receives and initiates to a backend target as defined in access logs.
 
 ## Request timeouts
 
-Application Gateway for Containers enforces the following timeouts as requests are initiated and maintained between the client, Application Gateway for Containers, and backend.
+Application Gateway for Containers enforces the following timeouts as it initiates and maintains requests between the client, Application Gateway for Containers, and backend.
 
 | Timeout | Duration | Description |
 | ------- | --------- | ----------- |
-| Request Timeout | 60 seconds | time for which Application Gateway for Containers waits for the backend target response. |
-| HTTP Idle Timeout | 5 minutes | idle timeout before closing an HTTP connection. |
-| Stream Idle Timeout | 5 minutes | idle timeout before closing an individual stream carried by an HTTP connection. |
-| Upstream Connect Timeout | 5 seconds | time for establishing a connection to the backend target. |
+| Request Timeout | 60 seconds | Time that Application Gateway for Containers waits for the backend target response. |
+| HTTP Idle Timeout | 5 minutes | Idle timeout before closing an HTTP connection. |
+| Stream Idle Timeout | 5 minutes | Idle timeout before closing an individual stream carried by an HTTP connection. |
+| Upstream Connect Timeout | 5 seconds | Time for establishing a connection to the backend target. |
 
->[!Note]
->Request timeout strictly enforces the request to complete in the defined time irrespective if data is actively streaming or the request has started to idle. For example, if you are serving large file downloads and you expect tranfers to take greater than 60 seconds due to size or slow transfer rates, consider increasing the request timeout value or setting it to 0.
+> [!NOTE]
+> Request timeout strictly enforces the request to complete in the defined time irrespective if data is actively streaming or the request is idle. For example, if you're serving large file downloads and you expect transfers to take greater than 60 seconds due to size or slow transfer rates, consider increasing the request timeout value or setting it to 0.