Logic Apps Hybrid – den kompletta guiden

När passar Logic Apps Hybrid?

Logic Apps Hybrid är rätt val när ni har data som inte får lämna ert nät men ändå vill utnyttja Azure-ekosystemet (managed connectors, utveckling i VS Code, styrning via Arc).

Arkitektur

Arkitekturen förklaras bäst i två diagram. Det första visar var saker bor: den fysiska topologin och gränsen mellan Azure och ert lokala nät. Det andra visar vad som händer över tid: den faktiska sekvensen från driftsättning till loggning när ett workflow körs.

Topologi: var komponenterna bor

Diagrammet nedan är uppdelat i två zoner med en brandväggslinje emellan.

Överst: Azure-sidan, kontrollplanet som hanterar styrning, secrets, loggning och managed connectors.

Under: ert lokala nät, där själva arbetet händer, inklusive Logic Apps-poddarna, SQL-databasen och SMB-utdelningen.

De två zonerna kopplas ihop av en enda linje: utgående TCP 443 från klustret till Azure. All verksamhetsdata stannar i den nedre zonen.

Diagram 1 — Infrastruktur-topologi. Hela dataplanet (Logic Apps-podar, SQL, SMB) ligger i ert nät. Azure-sidan hanterar konfiguration, observability och managed connectors via :443 utgående.

Runtime-flöde när ett workflow körs

När topologin är på plats kan ni följa vad som händer från att ni trycker “deploy” i VS Code till att workflow:et loggar sitt första resultat. Diagrammet numrerar de tio stegen i ordning.

Steg 1–6 är driftsättning och initiering: Arc tar emot definitionen, Container Apps-tillägget startar en pod-replika, poden monterar artefakt-volymen via SMB CSI-drivrutinen, läser anslutningssträngen från Key Vault och initierar SQL-schemana.

Steg 7–10 är själva körningen: SQL-persistens av körtillstånd och historik, läsning av transformer och scheman från artefakt-volymen, utgående anrop till managed connectors, och podd-loggar som Container Apps-tilläggets logProcessor skickar vidare till Log Analytics.

Notera markeringen längst ner: Log Analytics-arbetsytan måste vara kopplad redan vid installationen av tillägget. Det går inte att lägga till i efterhand.

Diagram 2 — Runtime-flöde. Sekvens från driftsättning till loggning. Initieringsfasen (1–6) förbereder poden, triggerbarriären skiljer init från körning, och körningsfasen (7–10) visar hur workflow-körningar persisteras i SQL, läser artefakter från SMB-volymen, anropar managed connectors och skickar loggar till Log Analytics via Container Apps-tillägget.

Tre saker att ha i minnet:

• Verksamhetsdata stannar on-prem. Workflow-körtillstånd och historik persisteras i er SQL-databas, och artefakter (transformer, scheman, DLL:er) ligger på er SMB-utdelning. Ingen verksamhetsdata lagras i Azure. Poden gör dock utgående anrop till Azure för managed connectors, för att läsa secrets från Key Vault och för att skicka loggar till Log Analytics.
• All kontrollplanstrafik är utgående på TCP 443. Arc-agenten, Container Apps-tillägget och själva poden initierar utgående sessioner från klustret till Azure-endpoints; svaren kommer tillbaka på samma session. Inga inkommande portar öppnas från Azure mot ert nät. Inom ert interna nät behöver poden däremot nätverksväg till SQL (TCP 1433) och SMB (TCP 445). Exponerar ni Envoy-ingressen (publik eller intern LB) tar den emot inkommande HTTP-trafik från sina egna klienter, men inte från Azure.
• Upp till 24 timmars frånkoppling stöds av Microsoft. Workflows som bara använder inbyggda connectors och lokala resurser (SQL, SMB, ingress-trafik) fortsätter köra även om anslutningen till Azure går ner. Workflows som anropar managed connectors, Key Vault eller andra Azure-tjänster misslyckas under frånkoppling. Podd-loggar buffras lokalt och skickas till Log Analytics när anslutningen är tillbaka; körhistoriken ligger redan säkert i er SQL-databas och påverkas inte.

Förberedelser innan ni sätter upp Logic Apps Hybrid

Innan installationssekvensen måste fyra områden vara på plats: Kubernetes-plattform, SQL, SMB-utdelning och Azure-sidan. Bocka av listan innan ni går vidare.

Detaljerna per område:

Kubernetes-plattform

Microsoft stöder Logic Apps Hybrid på tre namngivna Arc-plattformar. Valet påverkar var podden fysiskt kör — och därmed hur trafiken till er on-prem SQL och SMB-utdelning ser ut.

• ✅ AKS (Azure Kubernetes Service) — rekommenderas för de flesta. Hanterat kontrollplan, inbyggd autoskalning, snabbast väg till POC och minst underhåll. Viktigt att förstå: klustret och därmed Logic Apps-podden körs i Azure. Varje workflow-anrop som läser eller skriver till on-prem SQL (TCP 1433) eller SMB (TCP 445) går från Azure ut till ert nät. Det kräver en stabil, privat nätverksväg — ExpressRoute eller Site-to-Site VPN — och ni får latens och egress-kostnader per anrop. Verksamhetsdata lagras fortfarande on-prem, men den är inte längre “nära” podden.
• AKS on Azure Local (tidigare Azure Stack HCI 23H2). Klustret körs on-prem på er HCI-hårdvara. Podden sitter i samma datacenter som SQL och SMB, så anropen går över ert interna LAN — ingen korsning av Azure-gränsen för datatrafik. Välj detta om ni redan har HCI-infrastruktur, har regulatoriska krav på att compute stannar on-prem, eller vill undvika latens/egress mot SQL och SMB.
• Arc-enabled Kubernetes on Windows Server. Klustret körs on-prem på Windows Server med Linux-noder (eller stöd för Windows-noder via Arc). Samma on-prem-fördelar som Azure Local men utan HCI-kravet. Välj detta om ni har en Windows-först-drift och vill köra K8s på befintlig hårdvara.

Tumregel:

• Vill ni ha äkta on-prem-drift av hela integrationsplattformen (podd + data)? Välj en av de två Arc-alternativen ovan.
• Är det enbart data-residency ni behöver och ni accepterar ExpressRoute/VPN-beroendet? AKS i Azure är enklast.

Krav oavsett plattform: autoskalning konfigurerad (en POC kan börja med min 1 och max 6 noder och trimmas efter last), kubectl och helm installerade på er driftsättningsmaskin. Aktuell lista över stödda Kubernetes-distributioner finns i Microsofts Limitations-avsnitt — Supported Azure Arc-enabled Kubernetes clusters.

SQL-databas

Använd befintlig SQL. Hybrid stöder fyra alternativ:

SQL-autentisering krävs. Managed identity stöds inte för storage provider. Anslutningssträngen måste innehålla användarnamn och lösenord och förvaras i Key Vault. Detta är ett hårt krav från Microsoft.

SMB-filutdelning (artefakt-lagring)

Artefaktlagringen är platsen där transformer, scheman och DLL:er lever. Logic Apps-podden monterar utdelningen vid start och läser artefakter under körning. Två alternativ:

• Windows-filutdelning on-prem. Vanligast, återanvänder AD-uppgifter
• Azure Files. Microsoft listar detta som ett testalternativ. Passar för POC eller om ni kör AKS i Azure, men går emot Hybrid-filosofin för produktion

Krav: unik sökväg per Logic App (inte per miljö), administratörsrättigheter på Windows-servern för att skapa utdelningen och sätta behörigheter (engångsjobb), ett AD-konto med läs/skriv-rätt som CSI-drivrutinen använder för att montera utdelningen, namnuppslagning av SMB-värden från klustret.

Azure-sidan

• Prenumeration med rätt att registrera resource providers: Microsoft.ExtendedLocation, Microsoft.Kubernetes, Microsoft.KubernetesConfiguration, Microsoft.App, Microsoft.OperationalInsights
• Key Vault för SQL-anslutningssträngar, SMB-uppgifter och eventuella certifikat
• Container Registry (ACR i Azure, eller en privat lokal spegling om ni sitter bakom proxy). Notera att Hybrid inte kan köras fullständigt air-gapped — Arc-agenten kräver utgående TCP 443 mot Azure, och Logic Apps-runtime-imagen pullas från MCR
• Log Analytics-arbetsyta. Måste anges vid installation av Container Apps-tillägget och kan inte läggas till i efterhand (se steg 5)

Resource provider-registrering:

# Sätt rätt prenumerationskontext först
az account set --subscription "<subscription-id-eller-namn>"

# Registrera providers (--wait blockerar tills status = Registered,
# vilket krävs innan Arc-connect och extension-installation i steg 3 och 5)
az provider register --namespace Microsoft.ExtendedLocation --wait
az provider register --namespace Microsoft.Kubernetes --wait
az provider register --namespace Microsoft.KubernetesConfiguration --wait
az provider register --namespace Microsoft.App --wait
az provider register --namespace Microsoft.OperationalInsights --wait

# Verifiera att alla fem är Registered
for ns in Microsoft.ExtendedLocation Microsoft.Kubernetes Microsoft.KubernetesConfiguration Microsoft.App Microsoft.OperationalInsights; do
  echo -n "$ns: "
  az provider show --namespace $ns --query registrationState -o tsv
done

Behörigheter: vem behöver vad

Hybrid-installationen kräver rättigheter i fyra separata system. Bocka av behörigheterna innan ni börjar. Halvvägs in i sekvensen är det för sent att öppna en serviceticket.

Azure RBAC (prenumerations- och resursgruppsnivå)

Minsta behörighet för personen som kör installationen:

Microsoft Entra ID (tidigare Azure AD)

Hybrid-körningen kan inte använda managed identity för managed API connections (hårt krav från Microsoft). Ni måste därför skapa en app-registrering i Entra vars client ID och client secret används av Logic Apps-runtimen för att autentisera connector-anrop. Samma app-registrering används om ni vill göra zip-deploy från VS Code i stället för SMB-deploy.

Inga Microsoft Graph-behörigheter och ingen tenant-admin-consent behövs — appen används enbart som client credential för Logic Apps-runtimen, inte för att anropa Graph.

Om er Entra-admin är en separat person: lämna över client-id, object-id, tenant-id och client secret innan ni börjar steg 10.

Kubernetes RBAC (inuti klustret)

Efter installationen kan ni snäva in dagligdriftsrollerna, men själva installationen kräver full admin.

SQL Server (on-prem, Azure SQL eller Arc-enabled SQL)

Managed identity är inte ett alternativ här. Microsoft har låst storage provider till SQL-auth.

SMB-share (Windows-filutdelning eller Azure Files)

On-prem nätverk och brandvägg

• Utgående TCP 443 från klustret till Azure-endpoints (Arc, ARM, Container Registry, Log Analytics, managed connectors). Se Azure Arc-nätverkskrav för fullständig FQDN-lista.
• TCP 1433 från kluster till SQL Server (om on-prem)
• TCP 445 från kluster till SMB-servern
• DNS-upplösning av både Azure-endpoints och on-prem hostnames från klusternoderna

Sammanfattning. Vem ska ni ha i rummet:

1. Azure-admin med Subscription Contributor
2. Entra-admin med Application Administrator (skapar app-registrering för managed-connection auth)
3. DBA med server-admin på SQL-instansen
4. AD/fil-admin som kan skapa servicekonto och sätta share-/NTFS-rättigheter
5. Nätverks-/brandväggs-admin som kan öppna 443/1433/445 och DNS
6. Kubernetes-operatör med cluster-admin

I mindre organisationer är det samma person i flera roller, men besluten och godkännandena måste ändå finnas på plats innan installationen startar.

📘 Microsoft Learn: Prerequisites for Logic Apps hybrid deployment · 📘 Azure Arc-enabled Kubernetes — network requirements · 📘 Azure built-in roles

Installationssekvens: från tomt kluster till första workflow

Kör stegen i ordning. Varje steg beskrivs med vad som händer, varför, exakt kommando och hur ni verifierar att det gick rätt. Räkna med 2–4 timmar för hela sekvensen första gången, och under en timme när ni har gjort det en gång tidigare.

Tre vanliga misstag som kan stjäla veckor från er installation

Tre vanliga fallgropar som återkommer i Hybrid-POC:er. Lär er dem innan ni börjar. Det tar tio minuter att läsa och kan spara flera dagars felsökning.

Verktygstips: Microsofts officiella troubleshoot.ps1 i Azure/logicapps/scripts/hybrid samlar automatiskt in nod-kapacitet, Arc-agentstatus, microsoft-app-environment-k8se-*-poddarnas hälsa, envoy LB-anslutning på port 443, CoreDNS-konfig och workflowapp-deploymenten. Kör den först när något går sönder — den sparar timmar av manuell kubectl describe.

1. Log Analytics kopplas inte in vid installation, måste göras om från grunden

Symtom: Ni installerar Container Apps-tillägget utan logAnalyticsConfig.customerId och sharedKey. Loggar dyker aldrig upp i Azure Monitor. Ni försöker lägga till arbetsytan i efterhand via az k8s-extension update. Det misslyckas tyst. Kommandot returnerar OK, men ingen loggning sker.

Orsak: Loggkonfigurationen sätts i tilläggets init-container, som bara körs vid första installationen. update ändrar parametrarna men kör inte om init-containern.

Lösning: Avinstallera tillägget helt (az k8s-extension delete) och installera om med rätt LAW-parametrar. Workflow-historik i SQL och artefakter på SMB-utdelningen överlever (de ligger externt), men custom location och connected environment måste återskapas och samtliga workflows redriftsättas. Räkna med driftstopp och flera timmars ombyggnad. Det är därför vi betonar detta i steg 4.

Förebygg: Skapa arbetsytan innan ni rör tillägget. Spara LAW_ID och LAW_KEY som miljövariabler. Lägg in dem i ett skript så ni aldrig kör installationen utan dem.

2. SMB-utdelning med fel behörigheter. Poddar startar inte

Symtom: Logic Apps-podden startar, försöker montera SMB-utdelningen och hamnar i CrashLoopBackOff. kubectl describe pod visar “Failed to mount volume: permission denied”.

Orsak: AD-kontot ni använde vid installationen har läsrättigheter men inte ändrarättigheter på utdelningen. Logic Apps behöver kunna skriva temporära filer dit.

Lösning:

# På Windows-filservern:
icacls "D:\logicapps-share" /grant "domain\serviceaccount:(OI)(CI)M" /T

M = modify, (OI)(CI) = objekt och containers, /T = rekursivt.

Glöm inte SMB-sharets egna behörigheter — NTFS Modify hjälper inte om själva utdelningen är exporterad som read-only. Kontrollera både Share permissions och Security på utdelningen.

Förebygg: Testa SMB-anslutningen från en testpodd innan ni gör första driftsättningen (se verifieringen i steg 8).

3. KEDA-autoskalaren är inte konfigurerad. Scale-to-zero fungerar inte

Symtom: Era Logic Apps-poddar går aldrig ner till 0 repliker när de är inaktiva. Runtime-debiteringen (vCPU-sekund och GB-minut) tickar på för varje replika även utan trafik, och poddarna håller nodkapacitet som annars kunde användas av andra workloads.

Orsak: KEDA-autoskalaren installeras av Container Apps-tillägget, men triggerkonfigurationen kommer inte automatiskt. Utan triggers vet KEDA inte vad den ska skala mot.

Lösning: Skala-konfigurationen ligger på den underliggande Container App-resursen (inte i workflow.json). Sätt scale.rules[] på revisionen — antingen via ARM/Bicep, az containerapp update, eller via portalen: Logic App → Scale → Add scale rule → HTTP. YAML-formen på Container App-resursen ser ut så här:

scale:
  minReplicas: 0
  maxReplicas: 10
  rules:
    - name: http-rule
      http:
        metadata:
          concurrentRequests: "10"

Förebygg: Bestäm minReplicas utifrån cold-start-tolerans. minReplicas: 0 krävs för verklig scale-to-zero; för produktions-workflows som inte tål första-träff-latensen, höj till 1. Kostnadseffekten för Hybrid är mestadels runtime-debiteringen (vCPU-sekund och GB-minut) — själva noden betalar ni redan för via AKS eller er egen hårdvara.

Verifiera att Logic Apps Hybrid fungerar

Kör dessa fyra verifieringar för att bekräfta att installationen är klar:

1. Alla poddar kör

kubectl get pods -n logicapps

Förväntat: alla poddar i status Running, ingen i Pending/CrashLoopBackOff.

2. SQL-scheman skapade

Anslut till er SQL-instans och kör:

SELECT TABLE_SCHEMA, COUNT(*) AS tables
FROM INFORMATION_SCHEMA.TABLES
GROUP BY TABLE_SCHEMA;

Förväntat: dt, dc, dq-scheman finns, vardera med flera tabeller.

3. Log Analytics tar emot loggar

Kör denna KQL-query i Azure Portal → Log Analytics workspace → Logs:

ContainerAppConsoleLogs_CL
| where ContainerAppName_s startswith "la-"
| take 20

Förväntat: minst en rad per driftsatt Logic App under de senaste 24 timmarna.

4. Exempelworkflow körs från början till slut

Trigga ert exempelworkflow med curl (steg 10). Kontrollera i Azure Portal → Logic App → Run history att körningen blev grön. Den auktoritativa statusen finns i Run history — Microsoft dokumenterar inte de interna tabellnamnen i dt/dc/dq, så ni ska inte skriva egna queries mot dem (schemat kan ändras mellan runtime-versioner). Komplettera med en räkning i SQL för att bekräfta att tabellerna fylls:

SELECT TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA IN ('dt','dc','dq')
ORDER BY TABLE_SCHEMA, TABLE_NAME;

Förväntat: flera tabeller per schema, och nya rader som tillkommit efter er körning (titta på sys.dm_db_index_usage_stats eller gör en COUNT(*) före och efter).

Om alla fyra är gröna har ni en fungerande Logic Apps Hybrid. Ni kan börja bygga integrationer.

Produktionshärdning för Logic Apps Hybrid: vad ni behöver kontrollera

Innan ni släpper på trafik i miljön, stäm av den här listan. Punkterna är sammanställda från Logic Apps- och Container Apps on Arc-dokumentationen samt Azure Well-Architected Frameworks pelare (Reliability, Security, Operational Excellence) — Microsoft publicerar i dagsläget ingen egen WAF-service-guide för Logic Apps Hybrid, så pelarna är den auktoritativa källan för kvalitetskrav. Ingen punkt är “nice-to-have” i en produktionssättning.

Reliability

Security

Operational Excellence

SHOULD-nivå (rekommenderat)

KEDA-trimning (min/max repliker, HTTP-skalningsregler), retry- och idempotensmönster, blue/green-driftsättning via två connected environments, SQL-dimensionering mot samtidig körvolym, tak för LAW-ingestion (Basic Logs på pratglada tabeller). Se:

• Logic Apps — business continuity & disaster recovery
• Securing Logic Apps
• AKS core concepts — cluster components
• Container Apps on Azure Arc — operations

Nästa steg: från POC till produktion med Logic Apps Hybrid

En körande POC är en början, inte slutet. Innan ni går i produktion:

• Observabilitet. Sätt upp App Insights-integration, definiera KQL-frågor för SLA-mätning och larm på fel
• DR-strategi. SQL-backup (point-in-time restore i minst 7 dagar), SMB-replikering och dokumenterad återställningsprocedur
• Multi-cluster. Separera dev/test/prod och överväg multi-region för kritiska workflows
• CI/CD. Gå från portal-driftsättningar till pipeline-driftsättningar (Azure DevOps, GitHub Actions) med automatiserade tester
• Kostnadsuppföljning. Tagga alla resurser, sätt budgetlarm och följ vCPU- och minnesförbrukning per workflow

Resurser

Microsoft Learn

• Set up Logic Apps hybrid deployment — prerequisites
• Create single-tenant Standard workflow on Azure Arc
• Connect Kubernetes to Azure Arc
• Container Apps on Azure Arc overview
• Azure Arc custom locations
• SQL storage for Logic Apps Standard

GitHub

• Azure/logicapps — scripts/hybrid (setup- och troubleshoot-skript)
• kubernetes-csi/csi-driver-smb — SMB CSI-drivrutin
• kedacore/keda — KEDA autoscaler

Vanliga frågor om Logic Apps Hybrid

Behöver vi Azure Stack HCI för Logic Apps Hybrid?

Det beror på var podden måste köras. Om ni kan låta Logic Apps-podden köra i Azure räcker AKS i Azure — SQL och SMB stannar då on-prem (nådda via ExpressRoute/VPN), men själva meddelandebearbetningen går genom Azure. Om ni har regulatoriska eller datasuveränitetskrav som säger att även podden måste köras i ert eget datacenter behöver ni en Arc-ansluten Kubernetes-distribution som körs on-prem — typiskt AKS on Azure Local (tidigare Azure Stack HCI) eller ett annat Arc-stött kluster (OpenShift, vanilj-K8s). Välj alltså först data-path, sedan distro.

Hur länge kan klustret vara frånkopplat från Azure?

Upp till 24 timmar utan dataförlust. Workflows fortsätter köra lokalt, körhistoriken buffras lokalt, och när anslutningen återställs synkroniseras allt upp till Log Analytics och Arc. Längre än 24 timmar riskerar ni att missa kritiska uppdateringar från kontrollplanet.

Vilka portar måste öppnas in till vårt nät?

Inga portar öppnas från internet mot ert nät. Trafiken mot Azures kontrollplan initieras utgående på TCP 443 från klustret, och svaren kommer tillbaka på samma session. Om podden körs on-prem räcker det; om podden körs i Azure (AKS-i-Azure) måste er on-prem-brandvägg däremot tillåta inkommande TCP 1433 (SQL) och TCP 445 (SMB) från Azure-subnätet via ExpressRoute/VPN. Envoy-ingressen (publik eller intern LB) tar dessutom emot inkommande HTTP från sina klienter. Säkerhetsfördelen jämfört med traditionell SaaS-integration är att ingenting exponeras publikt mot internet.

Kan vi använda befintlig on-prem SQL Server?

Ja. Logic Apps Hybrid stöder SQL Server on-prem, Azure SQL Database, Azure SQL Managed Instance och Arc-enabled SQL. Ni behöver bara en databas där Logic Apps-runtime kan skapa schemana dt, dc och dq. Befintlig BizTalk-SQL kan ofta återanvändas (i en separat databas på samma instans).

Stöds managed identity?

Nej, inte för Hybrid. Container Apps på Arc stöder inte managed identities för apparna, och Microsofts Hybrid-dokumentation listar dessutom managed identity-autentisering för connector-operationer som icke-stödd. I praktiken innebär det att både storage provider (SQL-anslutningen) och managed connectors kräver andra autentiseringsmetoder: anslutningssträngar och service principals, förvarade i Key Vault.

Kan vi migrera befintliga BizTalk-workflows direkt?

Nej, BizTalk-orkestreringar måste portas om till Logic Apps workflow-definition, och Logic Apps har heller ingen pipeline-modell — custom pipeline-komponenter (DLL:er) portas därför inte. Däremot lever de rena dataartefakterna vidare: XSD-scheman återanvänds direkt, och XSLT-maps (också de som skapades via BizTalks .btm-mappar, som kompileras till XSLT) kan driftsättas till Logic Apps Hybrid via SMB-utdelningen. Custom .NET-logik från pipelines behöver skrivas om som Logic Apps-actions eller flyttas till Azure Functions. Det gör migrationen enklare än en omskrivning från grunden, men inte en ren “lift-and-shift”.

Vilka Azure-regioner stöds?

Regionstödet byggs ut löpande — verifiera alltid aktuell lista på MS Learn innan ni planerar, eftersom regioner tillkommer utan varsel. Aktuell lista finns i Microsofts Limitations-avsnitt — Supported Azure regions (per april 2026: Central US, East Asia, East US, North Central US, Southeast Asia, Sweden Central, UK South, West Europe, West US). Sweden Central är normalt rätt val för svenska kunder.

Hur mycket kostar det i månaden?

Två kostnadsposter: (1) workflow-körning debiteras per vCPU-sekund och GB-minut för Logic Apps-containrarna, (2) er egen K8s-hårdvara (om on-prem) eller AKS-nodkostnaden (om Azure). Resurstilldelning (vCPU och minne per replika) och antal repliker konfigureras i Logic App-manifestet. Se Microsofts prissida för aktuella taxor. Kontakta oss för en uppskattning utifrån er volym och infrastruktur.

Har ni frågor om uppsättningen eller vill diskutera er BizTalk-migration? Kontakta Contica →