Skip to content

README.md

Latest commit

 

History

History
787 lines (538 loc) · 31.7 KB

README.md

File metadata and controls

787 lines (538 loc) · 31.7 KB

Infrastructure Documentation

This directory contains the Infrastructure as Code (IaC) for the MyToDoApp application, implemented using Azure Bicep templates. These templates are designed to be deployed using the Azure Developer CLI, as they rely on a number of hooks implemented as a number of PowerShell scripts that run before and after these templates in order to complete the configuration.

Prerequisites

Before deploying this infrastructure, the preup.ps1 script is run by azd to prepare the environment. This script:

  • Creates Azure AD app registrations for web and API authentication
  • Creates the Azure AI Services account
  • Discovers available Azure AI Foundry models and quota in the target region
  • Sets environment variables that the Bicep templates consume

The Bicep templates then use these environment variables to deploy model deployments and configure authentication settings. For detailed information about the pre-deployment preparation, see the Scripts Documentation.

Architecture Overview

The application consists of:

  • Frontend Web App: Flask application with user authentication and UI implmented in Python (see App Documentation)
  • Backend API: Data API Builder (DAB) providing REST/GraphQL endpoints (see API Documentation)
  • Database: Azure SQL Database with Entra ID authentication
  • AI Services: Azure AI Foundry for intelligent recommendations
  • Session Storage: Azure Cache for Redis with Entra ID authentication
  • Monitoring: Application Insights and Log Analytics

All services use Azure Entra ID (Azure AD) authentication with managed identities for secure, passwordless connections.

For information about the deployment lifecycle scripts, see the Scripts Documentation.

Azure Verified Modules (AVM)

This infrastructure leverages Azure Verified Modules (AVM) wherever possible to ensure best practices, maintainability, and consistency. AVM modules are community-maintained, Microsoft-endorsed Bicep modules that provide:

  • Consistent patterns across all Azure resources
  • Built-in features for diagnostics, role assignments, locks, and tags
  • Regular updates aligned with Azure API changes
  • Best practices for security, reliability, and performance
  • Community support and extensive documentation

Modules Using AVM

The following infrastructure modules use Azure Verified Modules:

Module AVM Module Path Version Benefits
identity.bicep avm/res/managed-identity/user-assigned-identity 0.4.2 Built-in role assignment support, consistent output structure
keyvault.bicep avm/res/key-vault/vault 0.13.3 Simplified RBAC, automatic private endpoint support, diagnostic settings
applicationinsights.bicep avm/res/operational-insights/workspace and avm/res/insights/component 0.12.0 and 0.6.1 Integrated monitoring solution with workspace management and role assignments
acr.bicep avm/res/container-registry/registry 0.9.3 Built-in diagnostics, RBAC configuration, support for geo-replication

Custom Modules (Not Using AVM)

Some modules remain custom-built due to specific requirements not fully supported by available AVM modules:

Module Reason for Custom Implementation
redis.bicep Uses Azure Cache for Redis API version 2024-11-01 with Entra ID authentication and access policy assignments (accessPolicyAssignments). AVM Redis module does not yet support these advanced Entra ID features required for passwordless authentication.
database.bicep Requires specific SQL Server configuration for Entra ID-only authentication mode and serverless database tier with custom auto-pause settings. Post-deployment schema creation via PowerShell script.
aiservices.bicep Deploys Azure AI Services (formerly Cognitive Services) with multiple AI Foundry model deployments (chat and embedding models). Requires dynamic model selection based on regional quota availability determined by pre-deployment scripts.
aca.bicep, aca-app.bicep, aca-api.bicep Deploy Azure Container Apps with complex custom environment variables, managed identity integration, and dynamic configuration from multiple sources. Requires tight integration with Key Vault secrets and runtime environment setup. Split into three modules for better separation of concerns (environment, frontend app, backend API).
authentication.bicep Simple deployment script module that stores authentication configuration in Key Vault secrets. Not a resource deployment module.

Future AVM Migration

As Azure Verified Modules mature and add support for newer API features (especially Entra ID authentication patterns, heavily used in this demo application), we will continue to migrate custom modules to AVM. This ensures the infrastructure benefits from community improvements while maintaining all required functionality.

Main Bicep File

main.bicep

This is the orchestration file that deploys all infrastructure components. It:

  • Defines all resource naming conventions using a unique resource token
  • Coordinates the deployment order through module dependencies
  • Passes configuration parameters to individual modules
  • Outputs important values (connection strings, endpoints) back to Azure Developer CLI (azd)

Key Features:

  • Uses user-assigned managed identity for all Azure service authentication
  • Deploys resources in the correct dependency order
  • Generates unique revision suffixes for container app deployments
  • Calculates deployment capacities for OpenAI models based on available quota

Configuration Parameters

main.parameters.json

This file contains all the configurable parameters used by main.bicep. The Azure Developer CLI (azd) automatically substitutes values from your environment during deployment.

Required Parameters

Parameter Source Description
environmentName AZURE_ENV_NAME The name of your azd environment (e.g., "dev", "prod")
aadAdminLogin NAME Your Azure AD user email/name for admin access
aadAdminObjectId OBJECT_ID Your Azure AD user object ID for RBAC assignments
webAppClientSecret CLIENT_SECRET Client secret for the web app registration
webAppClientId CLIENT_ID Application ID of the web app registration
apiAppIdUri API_APP_ID_URI Application ID URI for the API (format: api://<guid>)
cognitiveservicesname AZURE_OPENAI_ACCOUNT_NAME Name for the Azure AI Foundry account
cognitiveservicesLocation AZURE_LOCATION Azure region for deployments

Azure AI Foundry Chat Model Parameters

These parameters are automatically discovered and set by the preup.ps1 script based on available quota in the target region:

Parameter Source Description
chatGptDeploymentVersion chatGptDeploymentVersion Model version (e.g., "0613", "1106")
chatGptSkuName chatGptSkuName SKU tier (e.g., "Standard", "GlobalStandard")
chatGptModelName chatGptModelName Model name (e.g., "gpt-35-turbo", "gpt-4") - prefers "mini" models
availableChatGptDeploymentCapacity availableChatGptDeploymentCapacity Available capacity in tokens per minute (TPM)

Azure AI Foundry Embedding Model Parameters

These parameters are automatically discovered and set by the preup.ps1 script:

Parameter Source Description
embeddingDeploymentVersion embeddingDeploymentVersion Embedding model version
embeddingSkuName embeddingDeploymentSkuName SKU for embeddings
embeddingModelName embeddingDeploymentModelName Embedding model name (e.g., "text-embedding-ada-002") - prefers "small" models
availableEmbeddingDeploymentCapacity availableEmbeddingDeploymentCapacity Available embedding capacity

Feature Flags

Parameter Default Description
restoreOpenAi false Set to true to restore a soft-deleted Azure AI Foundry account
useFreeLimit false Set to true to use Azure SQL Database free tier

Note: The azd CLI automatically reads these values from your .azure/<env-name>/.env file during deployment. The ${VARIABLE} syntax in the JSON is replaced with actual values at deployment time.

Infrastructure Modules

modules/identity.bicep

Creates a user-assigned managed identity that serves as the security principal for all Azure resources in the application.

Uses Azure Verified Module: avm/res/managed-identity/user-assigned-identity:0.4.2

What it does:

  • Deploys a user-assigned managed identity using AVM
  • Defines a custom role for deployment scripts
  • Assigns the "Managed Identity Operator" role to itself
  • Grants permissions needed for Azure CLI deployment scripts

Why it's needed:

  • Enables passwordless authentication across all Azure services
  • Provides a single identity for RBAC role assignments
  • Allows the application to access Azure resources securely without storing credentials

Outputs:

  • identityid: Resource ID of the managed identity
  • clientId: Client ID for authentication
  • principalId: Principal ID for role assignments

modules/keyvault.bicep

Deploys Azure Key Vault for secure storage of application secrets and configuration values.

Uses Azure Verified Module: avm/res/key-vault/vault:0.13.3

What it does:

  • Deploys an Azure Key Vault using AVM with RBAC authorization enabled
  • Configures built-in role assignments for the managed identity and admin user
  • Both assigned the Key Vault Secrets User role via AVM's roleAssignments parameter
  • Stores secrets for all sensitive configuration values

Why it's needed:

  • Stores sensitive configuration like connection strings, API keys, and OAuth credentials
  • Provides secure, auditable access to secrets at runtime
  • Eliminates hardcoded credentials from application code

Secrets stored:

  • Authentication: AUTHORITY, CLIENTID, CLIENTSECRET
  • Database: SQLCONNECTIONSTRING
  • Redis: REDISCONNECTIONSTRING
  • OpenAI: AZUREOPENAIENDPOINT
  • Application Insights: APPLICATIONINSIGHTSCONNECTIONSTRING

AVM Benefits:

  • Simplified RBAC configuration through declarative roleAssignments array
  • Automatic support for private endpoints, diagnostic settings, and locks
  • Consistent parameter naming across all Key Vault configurations

modules/authentication.bicep

Stores Azure AD authentication configuration in Key Vault.

What it does:

  • Stores the OAuth authority endpoint (Azure AD login URL)
  • Not a typical resource module—just stores auth config values
  • Uses deployment scripts to set Key Vault secrets

Why it's needed:

  • Centralizes authentication configuration
  • Makes the Azure AD authority URL available to containers via Key Vault

Outputs:

  • AUTHORITY: Azure AD tenant login endpoint

modules/redis.bicep

Deploys Azure Cache for Redis with Entra ID authentication for session storage.

What it does:

  • Creates an Azure Cache for Redis (Basic C0 SKU by default)
  • Enables Entra ID authentication and disables access keys
  • Grants "Data Owner" access policy to the managed identity
  • Grants "Data Owner" access policy to the admin user
  • Configures TLS 1.2+ with SSL-only connections

Why it's needed:

  • Stores user session data (login state, cached todos)
  • Provides fast, distributed session storage across container replicas
  • Uses Entra ID for passwordless authentication (no Redis password needed)
  • Enables horizontal scaling of the web application

Key features:

  • Passwordless authentication using Entra ID tokens
  • The managed identity name is used as the Redis username
  • Connection string format: rediss://<identity-name>@<hostname>:6380/0

Outputs:

  • redisHostName: Redis server hostname
  • redisSslPort: SSL port (6380)
  • entraConnectionString: Entra-authenticated connection string

modules/database.bicep

Deploys Azure SQL Database with Entra ID authentication using the Azure Verified Module (AVM).

What it does:

  • Creates an Azure SQL Server with Entra ID-only authentication
  • Creates a "todo" database with serverless General Purpose SKU (name configurable via SQL_DATABASE_NAME env var, default: todo)
  • Configures the managed identity as the SQL admin
  • Grants the admin user SQL admin access for local development
  • Optionally enables Azure SQL Database free tier
  • Stores connection string in Key Vault

Post-deployment configuration:

After the database is created, the postprovision.ps1 script runs to:

  • Grant database roles (db_datareader, db_datawriter, db_ddladmin) to the managed identity
  • Create the dbo.todo table schema with JSON validation constraints
  • Configure external user mapping for passwordless authentication

Why it's needed:

  • Stores todo items and user data
  • Provides ACID transactions and relational queries
  • Uses Entra ID authentication (no SQL passwords)
  • Serverless SKU auto-pauses to save costs

Database configuration:

  • SKU: GP_S_Gen5_4 (4 vCores serverless)
  • Max size: 32 GB
  • Auto-pause delay: 60 minutes
  • Authentication: Azure AD only (no SQL auth)

Connection string format:

Server=tcp:<server>.database.windows.net,1433;Initial Catalog=todo;Authentication=Active Directory Default;

Security note: This module includes a permissive firewall rule (0.0.0.0 - 255.255.255.255) for this sample app. For production, replace with restricted IP ranges or private endpoints.

modules/aiservices.bicep

Deploys Azure AI Services (Azure AI Foundry) with chat and embedding model deployments.

Prerequisites:

This module requires the Azure AI Services account to already exist (created by preup.ps1) and uses environment variables set by that script to configure the model deployments.

What it does:

  • References the existing Azure AI Services account (kind: AIServices)
  • Deploys a chat model based on parameters from preup.ps1 (e.g., GPT-4o-mini, GPT-3.5-turbo)
  • Deploys an embedding model based on parameters from preup.ps1 (e.g., text-embedding-3-small)
  • Grants "Cognitive Services OpenAI Contributor" role to managed identity
  • Grants "Cognitive Services OpenAI Contributor" role to admin user
  • Stores endpoint and deployment name in Key Vault
  • Optionally restores a soft-deleted OpenAI account

Why it's needed:

  • Powers AI-driven todo recommendations and prioritization
  • Provides natural language understanding for todo descriptions
  • Generates embeddings for semantic search (future feature)

Model deployments:

  1. Chat model: For conversational AI and text generation
    • Capacity determined by available quota (divided by 10)
    • SKU configured based on regional availability
  2. Embedding model: For semantic similarity and search
    • Default: text-embedding-ada-002
    • Used for future recommendation features

Key features:

  • Disables local auth (key-based) in favor of Entra ID
  • Supports custom subdomain for consistent endpoint URLs
  • Configurable public network access
  • Batch deployment of models (@batchSize(1) for sequential deployment)

modules/applicationinsights.bicep

Deploys Azure Monitor Application Insights and Log Analytics workspace for application monitoring and telemetry.

Uses Azure Verified Modules:

  • Log Analytics Workspace: avm/res/operational-insights/workspace:0.12.0
  • Application Insights Component: avm/res/insights/component:0.6.1

What it does:

  • Deploys a Log Analytics workspace using AVM for log aggregation
  • Deploys an Application Insights component using AVM linked to the workspace
  • Configures built-in RBAC role assignments for the managed identity and admin user
  • Both assigned the Monitoring Metrics Publisher role via AVM's roleAssignments parameter
  • Disables local auth, requiring Entra ID for all access

Why it's needed:

  • Provides real-time monitoring of application performance and availability
  • Captures logs, metrics, and distributed traces
  • Enables alerts and diagnostics for proactive issue detection

Configuration:

  • Log Analytics: PerGB2018 SKU, 30-day retention, 1GB daily quota
  • Application Insights: Workspace-based (not classic), public network access enabled

AVM Benefits:

  • Split into two focused modules following single-responsibility principle
  • Built-in diagnostic settings configuration
  • Standardized parameter structure for monitoring resources
  • Simplified RBAC configuration through declarative roleAssignments arrays

modules/acr.bicep

Deploys Azure Container Registry (ACR) for storing and managing container images.

Uses Azure Verified Module: avm/res/container-registry/registry:0.9.3

What it does:

  • Deploys an Azure Container Registry using AVM with Basic SKU
  • Enables admin user credentials (for simplified local development)
  • Configures diagnostic settings via AVM's diagnosticSettings parameter
  • Sends logs to Log Analytics workspace
  • Adds RBAC role assignment for the managed identity via AVM's roleAssignments parameter
  • Assigns AcrPull role for secure image pulling

Why it's needed:

  • Stores Docker container images for the frontend and API
  • Provides a private registry for secure image distribution
  • Integrates with Azure Container Apps for automated deployment

Configuration:

  • Basic SKU (cost-optimized for small workloads)
  • Admin user enabled for docker login support
  • Diagnostic logs integrated directly into AVM module configuration

AVM Benefits:

  • Built-in diagnostics configuration eliminates separate resource creation
  • Declarative RBAC assignments through roleAssignments parameter
  • Support for geo-replication, webhooks, and advanced security features

Outputs:

  • name: Name of the Container Registry
  • loginServer: FQDN for Docker login (e.g., myregistry.azurecr.io)

modules/aca.bicep

Deploys the shared Azure Container Apps managed environment.

What it does:

  • Creates a Container Apps managed environment with Application Insights integration
  • Configures Log Analytics workspace for container app logs
  • Assigns the user-assigned managed identity to the environment
  • Grants ACR pull permissions to the managed identity for image deployment
  • Enables zone redundancy settings (currently disabled for cost optimization)

Why it's needed:

  • Provides a shared runtime environment for all container apps
  • Centralizes logging and monitoring configuration
  • Manages networking and ingress for container apps
  • Enables secure communication between containers

Outputs:

  • containerAppEnvId: Resource ID of the Container Apps environment (used by app and API modules)
  • applicationInsightsConnectionString: Connection string for telemetry

modules/aca-app.bicep

Deploys the frontend web application container (see App Documentation).

What it does:

  • Deploys the frontend web app container in the shared environment
  • Configures external ingress on port 80 with HTTPS-only access
  • Sets up startup probe for managed identity readiness
  • Configures environment variables for Key Vault, Redis, OpenAI, and API access
  • Stores the redirect URI in Key Vault for Azure AD configuration
  • Uses a bootstrap image initially (replaced by azd deploy)

Configuration:

  • Resources: 0.5 vCPU, 1Gi memory
  • Scaling: 0-3 replicas based on HTTP requests (10 concurrent per replica)
  • Startup probe: Checks /startupz endpoint with 15s initial delay

Frontend (App) features:

  • Flask application with Azure AD authentication (see App Documentation)
  • Session management via Redis
  • Calls backend API with OAuth2 client credentials flow
  • OpenAI integration for recommendations
  • Startup probe waits for Redis MI token availability

Environment variables:

  • KEY_VAULT_NAME: Key Vault for secrets
  • REDIS_CONNECTION_STRING: Entra-authenticated Redis connection
  • AZURE_CLIENT_ID: Managed identity client ID
  • APPLICATIONINSIGHTS_CONNECTION_STRING: Telemetry
  • AZURE_OPENAI_DEPLOYMENT_NAME: Chat model name
  • API_URL: Backend API GraphQL endpoint
  • API_APP_ID_URI: API app registration URI for token requests

Outputs:

  • appRedirectUri: Frontend URL for Azure AD redirect configuration
  • appFqdn: Fully qualified domain name of the frontend app

modules/aca-api.bicep

Deploys the backend API container (see API Documentation).

What it does:

  • Deploys the backend API container in the shared environment
  • Configures external ingress on port 5000 with HTTPS-only access
  • Sets up environment variables for database, authentication, and Azure AD validation
  • Stores the API URL in Key Vault for frontend configuration
  • Data API Builder (DAB) provides automatic REST/GraphQL generation
  • Uses a bootstrap image initially (replaced by azd deploy)

Configuration:

  • Resources: 0.25 vCPU, 0.5Gi memory
  • Scaling: 0-3 replicas based on HTTP requests (10 concurrent per replica)

Backend (API) features:

  • Data API Builder (DAB) for automatic REST/GraphQL generation (see API Configuration)
  • JWT validation using Azure AD (v1.0 endpoint)
  • Filters data by user OID for multi-tenancy
  • Connects to SQL Database using managed identity
  • Managed Identity token wait logic via custom entrypoint

Environment variables:

  • DATABASE_CONNECTION_STRING: SQL Database connection (Entra ID auth)
  • REDIS_CONNECTION_STRING: Session storage
  • APPLICATIONINSIGHTS_CONNECTION_STRING: Telemetry
  • AZURE_CLIENT_ID: Managed identity client ID
  • CLIENT_ID: Web app client ID
  • API_APP_ID_URI: Full app ID URI (e.g., api://guid)
  • API_APP_ID: Just the GUID portion for JWT audience validation
  • TENANT_ID: Azure AD tenant for token issuer validation

Outputs:

  • apiUrl: Backend GraphQL endpoint URL (e.g., https://<fqdn>/graphql/)
  • apiFqdn: Fully qualified domain name of the API container

Container Apps Module Architecture

The Container Apps deployment is split into three focused modules for better maintainability and separation of concerns:

  1. aca.bicep - Shared environment infrastructure

    • Container Apps managed environment
    • Log Analytics integration
    • ACR pull role assignment

  2. aca-app.bicep - Frontend application (see App Documentation)

    • Flask web application
    • User interface and authentication
    • OpenAI integration for recommendations

  3. aca-api.bicep - Backend API service (see API Documentation)

    • Data API Builder (DAB)
    • GraphQL/REST endpoints
    • Database integration

This modular approach allows:

  • Independent updates to frontend or API without redeploying the shared environment
  • Clearer separation of responsibilities
  • Easier testing and troubleshooting of individual components
  • Better alignment with microservices architecture patterns

Deployment order:

  1. Environment (aca.bicep) - Creates shared infrastructure
  2. API (aca-api.bicep) - Deploys backend service, outputs API URL
  3. App (aca-app.bicep) - Deploys frontend, consumes API URL from step 2

Scaling:

  • Both containers: Min replicas: 0 (scale to zero when idle)
  • Both containers: Max replicas: 3
  • Both containers: Scale trigger: 10 concurrent HTTP requests per replica

Security:

  • All ingress is HTTPS-only
  • Uses managed identity for ACR image pull
  • No secrets exposed in environment variables (uses Key Vault)

Deployment Process

When you run azd up or azd deploy, the following happens:

  1. Pre-deployment (preup.ps1):

    • Creates Azure AD app registrations (web app and API)
    • Creates Azure AI Services account
    • Discovers available Azure AI Foundry models and quota
    • Selects optimal chat and embedding models (prefers "mini" and "small" models)
    • Stores configuration in azd environment

  2. Infrastructure provisioning (azd provision runs main.bicep):

    • Deploys main.bicep with parameters from main.parameters.json
    • Modules are deployed in dependency order:
      1. Identity, Key Vault, Redis
      2. Authentication, Database, ACR, Application Insights, AI Services
      3. Container Apps Environment (aca.bicep)
      4. API Container (aca-api.bicep)
      5. Frontend Container (aca-app.bicep) - depends on API URL from previous step

  3. Post-provisioning (postprovision.ps1):

    • Grants managed identity database roles on SQL Database
    • Creates dbo.todo table schema
    • Configures external user for passwordless database access

  4. Application deployment (azd deploy):

  5. Post-deployment (postdeploy.ps1):

    • Updates Azure AD app redirect URIs with deployed container app URLs
    • Configures logout redirect URLs

  6. Post-up (postup.ps1):

    • Displays connection information and next steps
    • Outputs application URLs

For detailed information about all deployment lifecycle scripts, see the Scripts Documentation.

Local Development

To run the application locally, you need these environment variables (azd automatically creates .azure/<env>/.env):

# From main.bicep outputs
KEY_VAULT_NAME=<keyvault-name>
REDIS_CONNECTION_STRING=<redis-connection>
APPLICATIONINSIGHTS_CONNECTION_STRING=<app-insights>
API_URL=<api-graphql-url>
AZURE_CLIENT_ID=<managed-identity-client-id>

# From Key Vault (retrieved by app at runtime)
AUTHORITY=<azure-ad-authority>
CLIENTID=<web-app-client-id>
CLIENTSECRET=<web-app-client-secret>

Your local Azure CLI or Visual Studio login will be used for managed identity authentication during development.

For more details on running the application locally:

Security Best Practices

This infrastructure follows Azure security best practices:

✅ Passwordless authentication using Entra ID for all services
✅ Managed identities for service-to-service authentication
✅ RBAC with least-privilege role assignments
✅ Key Vault for secrets management
✅ HTTPS-only ingress for container apps
✅ TLS 1.2+ for Redis and SQL connections
✅ Audit logging via Application Insights and Log Analytics
✅ Azure AD-only auth for SQL Database (no SQL passwords)

⚠️ For Production:

  • Remove the permissive SQL firewall rule (0.0.0.0 - 255.255.255.255)
  • Use Private Endpoints for SQL, Redis, and Key Vault
  • Enable Key Vault soft delete and purge protection
  • Increase Container Apps max replicas based on load
  • Set up availability zones for high availability
  • Configure Azure Front Door or Traffic Manager for global distribution

Resource Naming Convention

All resources follow this pattern: todoapp-<service>-<resourceToken>

Where <resourceToken> is a unique string generated from:

toLower(uniqueString(resourceGroup().id, environmentName, location))

Example resources:

  • todoapp-kv-abc123def456 (Key Vault)
  • todoapp-redis-abc123def456 (Redis Cache)
  • todoapp-sql-abc123def456 (SQL Server)
  • todoapp-app-abc123def456 (Web App Container)
  • todoapp-api-abc123def456 (API Container)

This ensures:

  • Resources are uniquely named across Azure subscriptions
  • Resources from different environments don't conflict
  • Resources can be identified by environment and location

Troubleshooting

OpenAI Deployment Fails

  • Issue: Model quota not available in region
  • Solution: Run azd env set AZURE_LOCATION <region> with a different region, then azd provision
  • Details: See preup.ps1 for model selection logic

Container App Startup Probe Failing

  • Issue: Managed identity token not available
  • Solution: Increase initialDelaySeconds in startup probe configuration (default is 15 seconds)
  • Details: See API troubleshooting for MI token wait configuration

Redis Authentication Fails

  • Issue: Access policy assignment not propagated
  • Solution: Wait 5 minutes for RBAC to propagate, or restart the container app

API Returns 401 Unauthorized

  • Issue: JWT token validation mismatch
  • Solution: Verify API_APP_ID_URI and API_APP_ID environment variables match the token audience
  • Details: See API configuration for required authentication variables

Database Connection Fails

  • Issue: Database permissions not configured correctly
  • Solution: Re-run post-provisioning script: pwsh scripts/postprovision.ps1
  • Details: See postprovision.ps1 for database setup requirements

Cost Estimation

Approximate monthly costs (pay-as-you-go, US West region):

Service SKU Est. Monthly Cost
Azure SQL Database Serverless GP_S_Gen5_4 $150 (with auto-pause)
Azure Cache for Redis Basic C0 (250MB) $16
Azure Container Apps 0.5 vCPU, 1GB RAM $30 (3 replicas)
Azure AI Foundry Standard, 100K tokens $10
Application Insights 1GB/day $2
Key Vault Standard $1
Container Registry Basic $5
Total ~$214/month

Cost optimization tips:

  • Use Azure SQL Database free tier (useFreeLimit: true)
  • Scale container apps to zero when idle
  • Use reserved capacity for OpenAI in production
  • Implement Azure Front Door caching for static content

Related Documentation

Project Documentation

Azure Resources