Skip to content

1.5 - Manual Provisioning

Today we explore manual resource provisioning using the Azure Portal. This hands-on approach helps you understand what happens when resources are created and why automation is valuable.

  • How to create Azure resources manually through the Portal
  • Configuration options and decisions required for each resource
  • The time and effort involved in manual provisioning
  • Why manual approaches don’t scale for complex applications

Before diving in, review these resources:

  1. 📘 Azure Portal Overview - Understanding the Azure Portal interface
  2. 📘 Create Azure OpenAI Resource - Step-by-step resource creation
  3. 📘 Azure Resource Manager - Understanding resource management concepts

Remember our apartment analogy from Day 3? Manual provisioning is like:

Going to a furniture store, selecting a chair, paying for it, carrying it home, and assembling it yourself.

Process:

  1. Research chair options
  2. Drive to store
  3. Select specific chair
  4. Pay and load into car
  5. Drive home
  6. Unpack and assemble
  7. Position in room

Effort: Doable for one chair, exhausting for furnishing an entire apartment!

Let’s manually create a simple AI resource: an Azure OpenAI Service instance.

  • Azure subscription
  • Appropriate permissions (Contributor role)
  • Azure OpenAI Service access (requires application approval)

Step-by-Step: Creating Azure OpenAI Resource

Section titled “Step-by-Step: Creating Azure OpenAI Resource”
  1. Go to portal.azure.com
  2. Sign in with your Azure credentials
  3. Click “Create a resource”
  1. In the search box, type “Azure OpenAI”
  2. Select “Azure OpenAI” from results
  3. Click “Create”

Decisions to make:

  • Subscription: Which subscription to bill
  • Resource Group: Create new or use existing
    • Name: rg-retail-ai-dev
    • Region: East US
  • Region: Where to deploy (affects latency and availability)
    • Choose: East US
  • Name: Unique name for your resource
    • Example: openai-retail-assistant-dev
  • Pricing Tier: Standard S0

Time: ~2 minutes

Decisions to make:

  • Network Access: Public or private endpoint
    • Choose: All networks (for development)
    • Production would use private endpoint
  • Allow Azure services: Yes/No
    • Choose: Yes

Time: ~1 minute

Decisions to make:

  • Managed Identity: System-assigned or user-assigned
    • Choose: System-assigned (enabled)
  • Access Control: RBAC settings
    • Note: Configure after creation

Time: ~1 minute

Optional but recommended:

Time: ~1 minute

  1. Review all settings
  2. Read terms and conditions
  3. Click “Create”
  4. Wait for deployment (3-5 minutes)

Total time for one resource: ~10 minutes

After the resource is created, you still need to:

  1. Deploy a Model

    • Navigate to Azure OpenAI Studio
    • Click “Deployments”
    • Create new deployment
    • Select model (gpt-4, gpt-35-turbo)
    • Choose capacity (TPM)
    • Wait for deployment (~2 minutes)
  2. Get API Keys

    • Navigate to “Keys and Endpoint”
    • Copy Key 1 or Key 2
    • Note the endpoint URL
  3. Configure Content Filters

    • Set up content filtering policies
    • Configure severity thresholds
    • Apply to deployments

Additional time: ~5-10 minutes

Our retail AI app needs ~15 resources:

ResourceEst. TimeConfiguration Complexity
Resource Group2 minLow
Azure OpenAI10 minMedium
AI Search8 minHigh
Cosmos DB10 minHigh
App Service Plan5 minMedium
App Service7 minMedium
Container Registry5 minLow
Container Apps Environment8 minMedium
Container App10 minHigh
API Management15 minHigh
Application Insights5 minLow
Log Analytics Workspace5 minLow
Key Vault8 minMedium
Virtual Network12 minHigh
Storage Account7 minMedium

Total Estimated Time: 2-3 hours (for an experienced person!)

  • Hours spent clicking through forms
  • Waiting for resources to deploy
  • Context switching between services
  • Typos in names or settings
  • Inconsistent naming conventions
  • Forgotten configuration steps
  • Wrong regions or SKUs
  • No documentation of steps
  • Hard to create identical dev/test/prod
  • Knowledge locked in one person’s head
  • Onboarding new team members is painful
  • Can’t track changes over time
  • No code review process
  • No rollback capability
  • No audit trail
  • Environments slowly diverge
  • “Works on my machine” problems
  • Testing doesn’t match production
  • Debugging becomes nightmare
  • Can’t provision multiple environments quickly
  • Regional expansion is manual copy-paste
  • Disaster recovery is manual
  • No automation possible

Manual provisioning is acceptable for:

Learning and exploration - Understanding service options ✅ Quick experiments - Testing a single service ✅ One-off resources - Rarely changed, simple configurations ✅ Emergency fixes - When automation is broken

From this exercise, you should appreciate:

  1. Complexity: Even “simple” resources have many configuration options
  2. Time: Manual provisioning doesn’t scale
  3. Expertise: You need to know what every option means
  4. Documentation: Hard to remember or document all steps
  5. Consistency: Easy to make different choices each time

Tomorrow (Day 6) we’ll see how ARM/Bicep templates solve many of these problems through Infrastructure as Code.

Then on Day 7, we’ll discover how AZD templates go even further by:

  • Including application code
  • Providing sensible defaults
  • Enabling one-command deployment
  • Incorporating best practices

Reflect on manual provisioning:

  1. “What are the main risks of manually provisioning production infrastructure, and how can they lead to security vulnerabilities?”
  2. “How would you create a checklist or documentation for manually provisioning a complex multi-service application?”
  3. “What Azure Portal features help reduce errors when manually creating resources?”

Next: Day 6 - ARM Templates

Tomorrow we’ll explore Infrastructure as Code with ARM and Bicep templates—automating what we did manually today.