Cut Logic Apps Standard Costs by 70% in Dev & POC Azure Environments

TL;DR

Logic Apps Standard runs on an App Service Plan --- which means you pay 24/7.

In dev and POC environments, that's unnecessary.

Deploy when you need it.
Tear down compute when you don't.
Keep storage. Keep run history.

Typical result: ~70% cost reduction.

The Core Idea

Logic Apps Standard runs on an App Service Plan (WS1).

That means compute is billed continuously --- even if no workflows are
running.

For non-production environments, that rarely makes sense.

Better approach:

• Deploy in the morning
• Work normally
• Tear down compute in the evening
• Keep the Storage Account intact

Run history is preserved because it lives in storage --- not in the App Service Plan.

The Problem

A typical Azure Pricing Calculator estimate shows:

• App Service Plan (WS1 × 730 hours): ~€152/month\
• Storage (example 1 TB, Hot LRS): ~€18/month\
• Total: ~€170/month

That models a 24/7 production setup.

But dev environments often run:

• 8 hours per day\
• ~20 business days per month

That's about 160 hours, not 730.

The Insight

Run history and workflow state are stored in the Storage Account.

So if you:

• Delete the Logic App
• Delete the App Service Plan
• Keep the Storage Account

All historical runs remain intact.

When you redeploy, the Logic App reconnects to the same storage.

Cost Impact Example

Instead of: €170/month (always-on)

If you run: 160 hours/month

Compute becomes approximately: €152 × (160 / 730) ≈ €33/month

Add storage (~€18 example):

≈ €51/month total. That's roughly 70% savings.

⚠ Storage costs vary by actual GB used and transaction volume.
The €18 example assumes 1 TB Hot LRS. Most dev environments use significantly less.

Daily Flow

Morning

Deploy infrastructure and workflows:

./deploy.sh <rg> <region> <mode>
./deploy-workflows.sh <rg> <logicapp-name> <path>

What the deploy script does:

# Switch to correct tenant/subscription
az login --tenant "$TENANT_ID"
az account set --subscription "$SUBSCRIPTION_ID"

# Create resource group
az group create --name "$RESOURCE_GROUP" --location "$LOCATION"

# Deploy Bicep template (creates App Service Plan, Logic App, Storage, App Insights)
az deployment group create \
  --name "$DEPLOYMENT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --template-file "$TEMPLATE_FILE" \
  --parameters "@${PARAM_FILE}"

What the workflow deployment does:

# Package workflows into ZIP
cd "$WORKFLOWS_PATH"
zip -r "$TEMP_ZIP" . -x "*.git*" -x "local.settings.json"

# Deploy ZIP to Logic App
az functionapp deployment source config-zip \
  --resource-group "$RESOURCE_GROUP" \
  --name "$LOGIC_APP_NAME" \
  --src "$TEMP_ZIP"

During the Day

• Run workflows
• Debug runs
• Inspect history
• Use monitoring

No functional difference from always-on.

Evening

Tear down compute:

./teardown.sh <rg> <logicapp-name> <asp-name> --force

What the teardown script does:

# Delete Logic App (keeps storage intact)
az webapp delete \
  --name "$LOGIC_APP_NAME" \
  --resource-group "$RESOURCE_GROUP"

# Delete App Service Plan (the expensive part)
az appservice plan delete \
  --name "$ASP_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --yes

# Storage Accounts are NOT deleted
# Application Insights is NOT deleted
# Run history remains in storage

Removes:

• Logic App
• App Service Plan

Keeps:

• Storage
• Run history
• Monitoring data

When To Use This

✅ Development environments
✅ Test environments
✅ POC and demo setups
✅ Low-frequency scheduled workloads

❌ Not for production

Production workloads should remain always-on to meet SLA and reliability
requirements.

Important Notes

• App Service is billed per hour (partial hours count as full).
• Do not tear down while workflows are running.
• Recurrence triggers do not "catch up" when offline.
• Storage cost scales with run history retention and transaction volume.
• Non-decryptable secrets warning (AZFD0007): During repeated teardown/redeploy cycles, you may see a diagnostic warning about "non-decryptable secrets backups." This is cosmetic and doesn't affect functionality. To clean it up, run:

  az rest --method POST \
    --uri "https://management.azure.com/subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{logicAppName}/syncfunctiontriggers?api-version=2022-03-01"

See Microsoft AZFD0007 Docs for details.

Standard vs Consumption

Why not just use Consumption?

Consumption is pay-per-execution and ideal for low-volume workloads.

Standard is preferred when you need:

• VNET integration
• Dedicated compute
• High throughput
• Advanced networking scenarios

This optimization applies specifically to Logic Apps Standard.

Bottom Line

If your Logic App isn't needed 24/7, you shouldn't pay for it 24/7.

• Deploy when needed.
• Tear down compute when idle.
• Keep storage. Keep history.
• Same workflows.
• Same performance.
• Lower cost.

References

Local Development:

• Building Logic Apps Locally with VS Code (HTTP, Blob, Queue & More)

Azure Documentation:

• Azure Logic Apps Standard Pricing
• Set up local development for Logic Apps Standard