AI Gateway on ECS and Container Apps

All three items come from the same request. Send your Organisation ID and the signup email address to the Palo Alto Networks team.

The Client Auth Key has a lifecycle you do not control. Because the scope is the organisation, the same key authenticates your non-production deployments, so treat a development copy with production care. No expiry period and no rotation procedure are published, so plan on a request to Palo Alto Networks whenever you need either. If the key is exposed, request a replacement through the same channel, then re-run step 1 and step 2 in every environment that holds it.

You read your Organisation ID off the SCM URL, and it becomes ORGANISATIONS_TO_SYNC. If you sync more than one organisation, the value is comma-separated.

Six steps in this guide require you to send something to Palo Alto Networks and wait for someone on their side to act. Each one blocks the step it sits in, and the first two can be raised before you build anything, so raise them now rather than at the step that needs them. Use the channel named in the Before you start callout for all of them.

No turnaround is published for any of these requests, so treat each one as an unknown wait when you schedule the work. The two allow-listing requests are the ones worth raising on day one: without them, step 4 stops while infrastructure built in step 2 sits idle.

Both tables ask for rights to create roles or role assignments, which is close to account-wide privilege on AWS and subscription-wide on Azure. Review the plan output for any policy broader than the rows above before applying. The deploying principal needs role-creation rights for the duration of the apply; scope it to the deployment's resource group or use a dedicated deployment role rather than a standing grant. Whether Owner is required on Azure to create the step 1 Key Vault role assignment is not documented; User Access Administrator on the vault's resource group is the narrower grant to try first.

This question comes up on every AWS engagement, and the published documentation does not answer it.

With create_cluster = true, which is what every published example uses, the module builds an ECS cluster whose only capacity provider is backed by an EC2 Auto Scaling group. The instance_type, min_asg_size, max_asg_size, and desired_asg_size variables exist precisely because tasks run on container instances you own. The documented path is EC2-backed ECS, not Fargate.

The task definition itself is Fargate-capable. It declares requires_compatibilities = ["EC2", "FARGATE"] with awsvpc networking, and the service attaches through a capacity provider strategy rather than a hard-coded launch type. The gateway's 1024 CPU units and 2048 MiB are also a valid Fargate size combination. The pieces for a Fargate deployment are therefore in place.

Reaching Fargate means bypassing the module's cluster creation:

• Create the ECS cluster yourself with the FARGATE and FARGATE_SPOT capacity providers registered.
• Set create_cluster = false, and supply cluster_name and capacity_provider_name pointing at that cluster.

If the requirement behind the question is "no servers to patch" rather than "Fargate specifically", Azure Container Apps satisfies it today with no such caveat, and on AWS a Bottlerocket-based Auto Scaling group gets most of the way there.

All AI Gateway metering is token-based. Every AI transaction through the gateway (prompts, MCP interactions, and A2A traffic) draws down flex credits by token usage, and you license the instance against your maximum expected monthly token consumption.

The token conversion is the industry standard:

1 token = 4 characters of text

estimated monthly tokens = total characters sent and received per month / 4

billion tokens per month = estimated monthly tokens / 1,000,000,000

Example: 12,000,000,000 characters per month
  tokens   = 12,000,000,000 / 4 = 3,000,000,000
  billions = 3,000,000,000 / 1,000,000,000 = 3

To build the estimate, inventory the applications, agents, and MCP servers that will route through the gateway, and for each one approximate: requests per month, average prompt size (including system prompts and context), and average response size. Sum the character counts, divide by 4, and add headroom for growth.

The deployment profile is the licensing object that funds AI Gateway. You create it in the Customer Support Portal (not Strata Cloud Manager), from the credit pool that holds your flex credits. Creating it and finishing setup (next step) is what activates the gateway for your tenant.

1. Log in to the Palo Alto Networks Customer Support Portal.
2. In the left navigation, expand Products and select Software NGFW Credits. (Flex credits for every Software NGFW and Prisma AIRS product, AI Gateway included, come from the same pools, so this is the right page.)
3. Locate the credit pool that will fund the gateway and click its name (or its row) to open the pool page; if several are listed, open the one with the most remaining credits. Item 8 shows how many credits this profile will draw; if that number exceeds the pool's remaining credits, close the dialog without creating the profile and repeat from this item with another pool. The pool page shows total credits, the allocated and consumed meters, the expiration date, and, at the bottom, the Current Deployment Profiles table.
4. Before creating anything, scroll to the Current Deployment Profiles table. If a row with product type AI-GW and the Profile Name you chose (or planned to choose) already exists from an earlier attempt, do not create another; it already holds a credit allocation. Skip to Licensing step 3 and use that row's Finish Setup link. An AI-GW row with a different name belongs to another deployment; leave it alone and create yours. If you created a profile by mistake, open the vertical ellipsis (More Options) at the far right of its row and select Delete; Palo Alto Networks documents this control for other Software NGFW credit profiles, including Prisma AIRS ones. If the menu offers no Delete, open an admin case in the Customer Support Portal or ask your account team to remove the profile and return its credits.
5. Click Create New Profile (above the Current Deployment Profiles table).
6. In the Create Deployment Profile: STEP 1 dialog, the products are laid out in labeled columns. Find the column headed Prisma AIRS: and click AI Gateway within it so its option is selected. The dialog calls this the firewall type because the same wizard provisions Software NGFW products; AI Gateway is not a firewall, and selecting it here is correct. Click Next.
7. Complete the FORM stage:
   • Deployment — select the option matching your deployment model: Managed Service if you chose SaaS, Self Service (DIY) if you chose Hybrid. The field is informational and does not change the credit allocation or the usage limit; if undecided, choose Managed Service.
   • Profile Name — a descriptive name, for example AI-Gateway-Deployment-Profile.
   • Billion tokens per month — the billions figure you calculated in Licensing step 1.
   • Bundled — no action needed. Strata Cloud Manager Pro is bundled with AI Gateway automatically and cannot be deselected. Its cost is included in the credit estimate you see in the next item, so that estimate covers more than AI Gateway alone.
   • Notes — optional.
8. Click Calculate Estimated Cost. The dialog shows how many credits this profile will draw and how many remain available in the pool; this is the flex credit allocation.
9. Click Create Deployment Profile. The dialog closes and returns you to the Software NGFW Credits credit pool page, with your new profile listed in the Current Deployment Profiles table at the bottom.

Credit pool page with the Create New Profile button (steps 3 to 5):

STEP 1: find the Prisma AIRS column and select AI Gateway (step 6):

▶ See screenshots — the FORM stage field by field

FORM: choose the Deployment type (step 7):

FORM: name the profile (step 7):

FORM: enter the monthly token volume (step 7):

Estimated cost in credits (step 8):

Created profile row (verification):

Mapping the deployment profile to a Tenant Service Group (TSG) is the link that connects Strata Cloud Manager and the Strata Logging Service to your AI Gateway. The TSG you map becomes the AI Gateway organization. The activation form labels the TSG as the Tenant.

1. On the same Software NGFW Credits credit pool page from Licensing step 2, scroll to the Current Deployment Profiles table and click the Finish Setup link on your AI-GW profile row. If you navigated away after the last step, get back via Products → Software NGFW Credits and reopen the same pool. The Activate Subscriptions based on Deployment Profile(s) page opens.
2. Under Select Customer Support Account, choose the support account used to create the deployment profile.
3. Under Specify the Recipient, select the Tenant that will own the gateway. This is the TSG. To confirm which name is yours, open the hub with the account you used in the prerequisites above, select Common Services → Tenant Management, find the tenant you work in, and select the matching Tenant here. If only one tenant is listed, select it.
4. Under Select Region, choose your region (for example, United States - Americas). The form will not proceed without it.
5. Under Select Deployment Profile(s), check the AI Gateway profile you created (its services column reads Strata Cloud Manager Pro, AI Runtime Security Gateway). Profiles already associated with this tenant are pre-checked; leave them checked, so the selected count will read higher than one. Unchecking a pre-checked profile removes its association when you activate. Click Done.
6. Leave Data Loss Prevention and Additional Services (including Cloud Identity Engine) at their pre-populated defaults; AI Gateway uses neither. A greyed-out DLP field is expected.
7. Check Agree to the Terms and Conditions, then click Activate.

▶ See screenshots

Activation page: select the Customer Support Account (step 2):

Region is required before activation can proceed (step 4):

Locate the AI Gateway profile in the deployment profile table (step 5):

Check the AI Gateway profile and click Done; the other checked rows are existing associations, left in place on purpose (step 5):

Leave DLP and Cloud Identity Engine at their pre-populated defaults (step 6):

Agree to the terms and activate (step 7):

With licensing in place, complete setup from inside SCM:

1. Log in to Strata Cloud Manager.
2. In the left navigation, select AI Security → Home.
3. On the Home page, locate the AI Gateway card under Select a feature to begin onboarding. On a fresh tenant (status Not Started) it offers three actions: Go to Gateway Registration, Launch AI Gateway, and Deploy Hybrid. Seeing the card is all you need here; this guide installs the data plane with Terraform rather than through those actions.

▶ See screenshots

The AI Security entry in the left navigation (step 2):

The AI Security menu with Home at the top and the AI Gateway section below (step 2):

The AI Gateway onboarding card with its three actions (step 3):

Both platform deployment pages describe a second connection, running from the management plane inbound to your gateway over a VPC endpoint service on AWS or a private endpoint on Azure, with an IP allow-list as the alternative. Do not build it for an AIRS gateway.

Palo Alto Networks confirmed on 2026-09-27 that private link is not supported with Strata Cloud Manager today, and that the only network connectivity between a gateway and the cloud is outbound from the gateway. The inbound procedures on those pages belong to the Portkey product, which shares the deployment tooling but not this part of the architecture.

Four things follow from that:

• Do not create a VPC endpoint service, and do not authorise arn:aws:iam::299329113195:root in your account.
• Do not add 54.81.226.149, 34.200.113.35, or 44.221.117.129 to allowed_lb_cidrs or to any network security group rule. Your load balancer admits your own applications and nothing else.
• Your gateway registers and appears in Strata Cloud Manager on outbound connectivity alone. If it does not appear, the cause is in 4.1 or 4.2 rather than a missing inbound path.
• The lb_type choice in step 2.2 is now yours to make on its merits. It no longer has to be a Network Load Balancer to back an endpoint service.

Replace <GATEWAY_ENDPOINT> with the load balancer DNS name, the Container Apps FQDN, or your custom hostname. Use https wherever you configured TLS in step 3. The ECS configuration in step 2.2 creates an internal load balancer, so run this from a host inside the VPC, or through ECS Exec on a gateway task, rather than from your laptop. On ACA with the built-in ingress the FQDN is public and you can run it from anywhere. Append the listener port if your endpoint does not listen on 443.

PORTKEY_API_KEY is a workspace API key, created in Strata Cloud Manager under the workspace this gateway syncs, in Phase 3 of the AI Gateway Deployment Guide. Create one there and copy it here before running the request, and use the same key each time you re-run this check. OPENAI_API_KEY is your own provider key.

export OPENAI_API_KEY=<your-openai-key>
export PORTKEY_API_KEY=<your-gateway-workspace-key>

curl 'https://<GATEWAY_ENDPOINT>/v1/chat/completions' \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "x-portkey-provider: openai" \
  -H "x-portkey-api-key: $PORTKEY_API_KEY" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [{"role": "user", "content": "What is a fractal?"}]
  }'

A passing check here proves the path, not the capacity. The deployment is still the single-task first deployment from step 2, so raise the task or replica count and enable autoscaling as described in Scaling and Upgrades before it carries real traffic.

The ECS module supports blue/green and canary rollouts through gateway_deployment_configuration. Container Apps handles this with its own revision model instead, so there is no equivalent block on ACA.

# Blue/green
gateway_deployment_configuration = {
  enable_blue_green = true
}

# Canary
gateway_deployment_configuration = {
  enable_blue_green = false
  canary_configuration = {
    canary_bake_time_in_minutes = 5
    canary_percent              = 10
  }
}

Two things carry versions, and they are not linked: the Terraform module, pinned by the ?ref= on the source, and on ACA the gateway image, pinned by gateway_image.tag.

# Pinned, the only correct form for a deployment you care about
source = "github.com/Portkey-AI/portkey-gateway-infrastructure//terraform/ecs?ref=v2.0.0"

To upgrade, change the ref, run terraform init -upgrade, read the plan carefully, and apply to a non-production environment first.

Separate state per environment, one backend config each. On ECS:

# dev/backend.config
bucket = "portkey-tfstate-<account-id>"
key    = "portkey-gateway/dev.tfstate"
region = "us-east-1"

# prod/backend.config
bucket = "portkey-tfstate-<account-id>"
key    = "portkey-gateway/prod.tfstate"
region = "us-east-1"

terraform init -reconfigure -backend-config=dev/backend.config
terraform apply

The root module you built in step 2.2 passes literal arguments to the module block and declares no root variables, so -var-file has nothing to feed and Terraform rejects every entry in the file as undeclared. Keep a separate directory per environment instead, each with its own main.tf and backend.config, and change environment in the module block.

Keep environment distinct per deployment. It feeds resource naming, and two environments sharing a value will collide. Repeat step 1 for each environment as well: the secret names include ${environment}, so a new environment needs its own pair of secrets and its own ARNs before its first apply.

terraform destroy

Work through the following after the destroy. Revocation comes first, because it is the only part that matters if the teardown is happening because something went wrong.

1. Schedule deletion of the step 1 secrets, and ask Palo Alto Networks to invalidate the Client Auth Key unless the organisation is being redeployed.
2. Delete the interface VPC endpoint created in step 4.2.
3. Remove the three management plane addresses from any allow-list you added outside the module.
4. Remove the Key Vault role assignment created in step 1.1, and purge the vault if the name is to be reused inside 90 days.
5. Delete or lock down the Terraform state bucket or storage account, which holds every prior state version.

These questions come up in the field and the published material does not currently answer them. Raise them with the product team rather than inferring an answer, and treat anything below as unresolved when writing a customer commitment.

• Throughput sizing — no requests-per-second figures for either platform. The published CPU and memory numbers are minimums to run, not a capacity model.
• ECS Fargate — not documented. See ECS Fargate under Deployment Requirements for what the module actually supports.
• Upgrade and rollback — no compatibility matrix between module versions and gateway image versions, no supported upgrade path, no tested rollback.
• Region placement and data residency — Strata Cloud Manager runs in the Americas only today, with other regions planned, and prompt bodies land there on the default log store. Retention and custody for that store are still unpublished.
• Air-gapped deployment — no documented configuration for an environment with no path to portkey.ai.
• TLS inspection — behavior of the outbound links through an intercepting proxy is not described, and streaming through one is untested.
• On-premises — confirmed supported but with no published procedure for these two platforms.
• Load balancer listener port and protocol — neither the ECS nor the ACA module exposes a listener-port variable, so the value is chosen inside the module and no page states it, while your own security group and firewall rules depend on it. Read it from the created listener. The Kubernetes pages do publish theirs, and that value does not carry across to these two platforms.
• Source restriction on built-in ACA ingress — the module variable that restricts source addresses on the built-in ingress is not documented, so a network_mode = "none" deployment has no in-module way to keep its public FQDN off the open internet.
• ALB TLS policy and HTTP listener — the TLS security policy the module applies, and whether it also creates a port 80 listener, are not published. No cipher suite or minimum TLS version appears on any platform page for any of the five deployment targets, so this is a gap in the product documentation rather than one page's omission.

This guide is derived from the published self-hosting documentation and from the Terraform module source.

• ECS — self-hosting/hybrid-deployments/aws/ecs
• Azure Container Apps — self-hosting/hybrid-deployments/azure/aca
• Architecture — self-hosting/hybrid-deployments/architecture
• Terraform modules — Portkey-AI/portkey-gateway-infrastructure, paths terraform/ecs and terraform/aca, each with its own docs/ directory and variables reference

The doc pages are published twice, on docs.portkey.ai/docs/aigw/ and on portkey.ai/docs/, and the two versions differ. See SOURCES.md in this directory for which to prefer and where the local mirrors are.