Infrastructure overview¶
AMS expects a working Azure landing zone and Kubernetes platform. You choose how to create each resource. This page is a checklist of capabilities the charts assume — not a prescribed IAC layout.
Must-have capabilities¶
Kubernetes cluster (AKS)¶
- AKS cluster sized for your module mix (start conservatively; scale node pools as you add modules and observability).
- Workload identity / managed identity patterns as required by your security baseline.
- Ability for nodes to pull images from your Azure Container Registry (or the registry that holds AMS images).
Ingress path into the cluster¶
Most AMS Azure installs use Application Gateway with an ingress controller (for example AGIC) so HTTP(S) traffic reaches Ingress resources.
You need:
- A public or private Application Gateway (per your network design)
- Listener and routing that can terminate TLS for the AMS hostname
- Controller that watches Kubernetes Ingress objects
Alternative ingress controllers are fine if your platform team standardizes on them — charts still emit Ingress resources.
DNS and TLS¶
- A DNS name for the shared AMS host (example:
ams.customer.com) - A TLS certificate (public CA or private PKI) available to the ingress layer
- A Kubernetes TLS Secret name that ingress and module values can reference (for example
wildcard-tls)
Identity and secrets plane¶
Depending on how you run AMS:
- Azure Key Vault plus Secrets Store CSI Driver (if charts sync secrets from Key Vault)
- Or Kubernetes Secrets you create manually / via your own pipelines
Data services¶
Confirm with each chart’s release values, but plan for:
- PostgreSQL (or compatible) for modules and Keycloak as required
- Object storage (Azure Blob / compatible) when observability or application features need buckets
Exact database names and connection strings come from your environment — wire them through Helm values or Key Vault, not through these docs.
Nice-to-have / environment-specific¶
| Item | Why it appears |
|---|---|
| Private endpoints / Private Link | Hardening for SQL, Key Vault, ACR |
| Jump VM or bastion | Operator access when AKS API is private |
| Azure Monitor / Defender | Org security baselines |
| Network policies / firewalls | Egress control for private clusters |
What “bring your own” means in practice¶
For each row below, document your chosen method (portal, Terraform, existing runbooks) in your internal wiki. AMS release docs only need the resulting names and endpoints.
| Resource | Example outcome you will plug into Helm |
|---|---|
| AKS | Cluster name, resource group, kubeconfig access path |
| Application Gateway | Frontend IP / FQDN, AGIC identity |
| DNS | ams.example.com → gateway |
| TLS | Secret wildcard-tls in target namespaces |
| ACR | Login server; pull secret or AcrPull on kubelet identity |
| Key Vault | Vault URI; CSI SecretProviderClass if used |
| PostgreSQL | Host, database names, credentials location |
Namespaces (typical)¶
Exact namespaces can follow your release values. Common patterns:
| Workload | Typical namespace |
|---|---|
| Command Center / shared AMS apps | ams |
| ARE | are (or shared ams depending on release layout) |
| Keycloak | keycloak |
| Observability | observability |
| Adapters | dedicated adapter namespaces or a shared adapters namespace |
| Ingress chart | usually ams with the shared host |
Create namespaces before helm install if your process does not let charts create them.