DEV Community: frankgg

One curl, No Login, and a 71.9% Cut on Azure's Biggest SAP HANA VM

frankgg — Sun, 08 Nov 2026 13:55:44 +0000

We run SAP AI Lab — two of us, one in ML systems, the other in enterprise information systems. No affiliation with SAP or Microsoft, just a shared habit of reading pricing APIs instead of press releases.

A while back a friend who manages an S/4HANA estate vented the standard complaint: "RISE is one contract, so why does my Azure bill still exist?" That question turned into the most useful arithmetic we've ever done, and it starts with a single flagship VM.

The number that changed our mind about reservations

Azure's largest memory-optimized HANA SKU, Standard_M832is_16_v3 (832 vCPU, 15,200 GiB RAM), lists at $163.856 per hour pay-as-you-go in East US. Same VM, reserved for one year: $834,816 prepaid for the term. Reserved for three years: $1,209,163.

Do the math against 730 hours a month and the discounts are 41.8% for one year and 71.9% for three years. For a two-node high-availability HANA pair that's roughly $239,200/month at list pay-as-you-go versus ~$67,200/month amortized on a three-year reservation. All figures are Azure Retail Prices API rows for East US, USD, retrieved as of 2026-11-08 — list prices, not your negotiated rate, but the ratios held across every SKU we queried.

The uncomfortable part: nobody is hiding this. The Azure Retail Prices API needs no authentication. This curl prints the exact rows we're quoting:

curl -s "https://prices.azure.com/api/retail/prices?\$filter=armSkuName eq 'Standard_M832is_16_v3' and armRegionName eq 'eastus' and type eq 'Reservation'"

One trap for first-time queriers: reservation rows report unitOfMeasure as "1 Hour", but retailPrice is the prepaid total for the whole term. Read it as a monthly rate and you'll understate your cost by three orders of magnitude in a slide deck, which we have seen happen.

Why the subscription quote is not the estate cost

The reservation lever matters even under RISE with SAP, because SAP procures the infrastructure and the subscription price is built on these same public meters. What the bundle does not cover, though, is everything outside the contracted systems:

Custom apps, data lakes, and analytics running on your tenant land on your Azure bill.
Satellite SAP systems under BYOL do too, and count toward your Microsoft consumption commitment.
Implementation partner fees land on neither invoice — the classic line item nobody models.

And the entitlement pool (you'll see it called RPE in deal collateral) is genuinely opaque: as of 2026-11-08 SAP publishes no definition, no pool size, no conversion terms — it lives in order forms. Our blunt recommendation: get the pool's inventory, eligible products, expiry, and renewal impact in writing before signing. Most RISE cost overruns trace back to answers assumed for questions never asked.

Two smaller numbers that surprised us, same as-of date: the identical M-series SKU bills $38.27/hour more on Windows than Linux (~$335k/year on one always-on VM), and a 100 TiB backup repository moves from ~$2,130/month on hot blob storage to ~$101/month on archive — a 21x swing that one lifecycle policy fixes.

And a sizing warning, because reservations only help if the footprint is right: the HANA tier boundary is a step function, not a ramp. Doubling vCPUs from 416 to 832 costs about 3.0x, not 2x — the flagship SKUs carry a per-vCPU premium. The same asymmetry runs the other way on the SAP side: the FUE ratios in the service description guide (1 FUE = 5 core users, 30 self-service users) are locked into your order form for the full term, so an inflated headcount estimate stays oversized for years. Measure twice, subscribe once.

What we'd do on your Monday morning

Reserve the stable production core first — it usually carries the entire savings program by itself. Then reconcile your Azure export against the entitlement list quarterly: bundled systems already include SAP-managed backup inside the subscription, and we keep finding teams paying twice for the same protection ($80/month per HANA protected instance, incidentally, is the meter we checked).

The full walkthrough with all the pricing sources and checklists is on our site: RISE with SAP Cost Breakdown: What You Pay on Azure. It includes the exact queries for storage, backup, and egress meters, the eight-point reduction checklist, and the packaging context in our RISE with SAP on Azure guide if you want to know which systems the bundle covers before pricing them.

Microsoft Retired the SAP Landing Zone Docs. We Rebuilt Them from the Git Archive.

frankgg — Sun, 08 Nov 2026 13:54:38 +0000

We run SAP AI Lab — two of us, one in ML systems, one in enterprise information systems, entirely independent of SAP and Microsoft. This spring our lab finally got approval to move a real SAP landscape to Azure, and before touching a single VM we spent three weeks arguing about landing zones. Half our search results led nowhere. Here's what we settled on, verified as of 2026-11-08.

The pages we needed were gone

The Cloud Adoption Framework once shipped SAP-specific enterprise-scale landing zone docs describing an "SAP on Azure construction set" of six design areas: identity and access, network topology, management and monitoring, business continuity/DR, security-governance-compliance, and platform automation and DevOps. Those pages are now retired from the live English site — requesting them today redirects to the generic landing zone overview. Nothing officially documented replaces their SAP-specific checklists one-for-one.

So we went to the archive: the docs repository on GitHub, read at a pinned commit. Two recommendations from there we adopted verbatim — run at least two SAP management groups so production and non-production get distinct controls, and keep the core SAP platform in dedicated subscriptions. When a fact comes from a 2021 revision, we label it as archived rather than pretending the live page exists. If you're designing this now, plan on doing the same archaeology.

What the live framework does still say — and it's enough

The current subscription design area explicitly names SAP, alongside high-performance computing and IoT, as a "large specialized workload" that should use separate subscriptions to avoid running up against platform limits. Three reasons we now repeat in every review meeting: a subscription is a scale unit, a management boundary, and a policy boundary — "development environments have more relaxed policy requirements than production environments." A 2 TB-in-memory database box does not want to share a quota namespace or a policy scope with your chatbot demo.

Our tree, after two failed drafts: tenant root → Online (platform: identity, connectivity, management, security subscriptions — the design area is blunt that you "do not combine platform responsibilities into a single subscription") → a workload management group named SAP, with SAP-DEV, SAP-TEST, and SAP-PRD as separate children. Production under its own management group child is what makes "deny by default in prod, relaxed in dev" a two-click policy assignment instead of an exception spreadsheet. One counterintuitive mercy: subscriptions are global logical containers, so you do not need one per region — the primary-plus-secondary DR pair shares a subscription unless it's independently managed.

The gotcha that cost us two days

A service principal with only Contributor cannot grant permissions to what it deploys. The SAP Deployment Automation Framework planning doc is explicit that automation identities also need User Access Administrator — and our first control-plane deployment failed for two days before we found that one line:

az role assignment create \
  --assignee <your-application-ID> \
  --role "User Access Administrator" \
  --scope /subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>

Two smaller landmines, same price bracket. Every dedicated spoke subscription eats your account's subscription count, and the defaults are not generous — we requested a quota increase before creating the sixth spoke. And the archived governance page recommended excluding SAP database servers from automatic endpoint-protection policy installs; we nearly learned that one the painful way during a HANA storage-layer test.

Then, and only then, the compute

The sequencing that actually worked: management groups and policy scopes → control plane (the DAF's hub subscription with deployer VMs, Key Vault, firewall, Bastion) → workload zones → systems. For one system instead of a landscape, Azure Center for SAP solutions and its Virtual Instance for SAP solutions resource bakes the separation-of-duties RBAC in for you — the framework and ACSS are complementary, not a decision between tribes. Naming is governance too: fight the DAF convention (DEV-WEEU-SAP01-INFRASTRUCTURE) after you've deployed anything and you'll be miserable; decide it in the review meeting, not in the Terraform state.

The full walkthrough with all the pricing sources and checklists is on our site: Azure Landing Zone for SAP in 2026 — the complete management-group layout, commit-pinned archive citations, and what we verified versus guessed. The compute decisions that come after this carve-out live in our HANA deployment guide, and the contract-side reading is in RISE with SAP on Azure.

Copilot Borrows Joule's Eyes: How the SAP–Microsoft Integration Actually Gates Your Data

frankgg — Sun, 08 Nov 2026 13:45:20 +0000

We run SAP AI Lab — two of us, one in ML systems, the other in enterprise information systems. Independent blog, no endorsement from SAP or Microsoft, and we like asking the questions enterprise architects ask at 2 a.m.

Ours, this autumn: a friend managing a mixed SAP/M365 estate said "we bought Copilot licenses, so SAP data is in Copilot now, right?" It isn't, and the reason why it isn't turned out to be the most interesting part.

The mental model that makes everything else click

The managed integration between SAP Joule and Microsoft 365 Copilot — generally available since February 2026 (SAP News DE listing, 2026-02-09, "Allgemeine Verfügbarkeit"; Microsoft's operational doc last updated 2026-09-11; our verification pass as of 2026-11-08) — is bidirectional. In Teams, a buyer types @Joule Show me open purchase orders that are past their expected delivery dates and the answer comes back into the chat. Inside Joule, the same user can ask for their own emails and Teams chats. Reversibility is the point: neither copilot owns the user.

But here's the governance shape: Copilot borrows Joule's eyes, and Joule sees only what the mapped SAP user is permitted to see. The request path is Entra ID authenticating the Microsoft 365 user → SAP Cloud Identity Services mapping that identity to their SAP user → Joule executing against S/4HANA under that SAP identity, with the same OData-level permissions they'd have in Fiori. SAP's documentation says Joule use cases "follow the same configurations and permissions as those on the Web." Nobody is opening a side door into your ERP; the division of labor is explicit — SAP does the natural-language processing for SAP tasks, Microsoft owns the Copilot/Teams experience, and the join between them is an identity trust, nothing more.

Which explains the most confusing support ticket in this whole area: when a supported question returns "no data" for user B but works for user A, that is expected behavior, not a bug. Either user B lacks the SAP-side role, or their Entra→SAP provisioning was never completed — the #1 documented failure mode. Check SAP roles first, IAS mapping second.

Licensing has teeth on both sides

Buying one side buys you an icon that returns nothing. You need Microsoft 365 Copilot seats and the SAP entitlements for Joule. On the SAP side, Business AI activation is entitlement-driven through the AI Activation Dashboard in SAP for Me, on the new AI Unit SKU 8019164 (released 2025-05-20); the legacy SKU 8018592 still activates individual features but not through the new package flow. Mark two dates in the planner: the simplified activation flow arrived April 1, 2026, and the legacy IAS-based activation path started deprecating May 1, 2026. Teams still on the old path hit walls and need their SAP account engineer to migrate SKUs.

Where Azure OpenAI actually sits

Every Azure architect asks this, so we'll be precise about what the sources support. Documented: Joule runs on SAP BTP, whose model-serving layer is the generative AI hub in SAP AI Core, and SAP's AI Core documentation explicitly lists Azure OpenAI models — "additional selected models from OpenAI are supported via Azure," with Azure Content Safety and Prompt Shield in the hub's safety layer. Inferred: the GPT models behind Joule scenarios are served through Azure OpenAI infrastructure. Not documented: that every prompt lands on an Azure OpenAI model — the hub is deliberately multi-provider (Claude, Gemini, Llama are in the catalog), and some GPT-4 endpoints are deprecated in favor of GPT-4.1 per SAP Note 3437766. For a compliance review, ask which model serves your scenarios.

Also be honest about the boundaries we verified: standard Joule and Copilot scenarios only — custom Copilot Studio agents do not ride this bridge (that's a different track with its own connector licensing), and the integration can't answer what Joule itself can't do. Our own gaps list, which we'd rather admit than smooth over: no English-language SAP press item pins the GA date, and prompt-retention specifics across the Copilot→Joule boundary aren't documented in the sources we could reach.

The full walkthrough with all the pricing sources and checklists is on our site: SAP Joule + M365 Copilot on Azure: How It Actually Works, including the worked request trace and the seven rollout pitfalls. If the managed bridge's "standard scenarios only" is where you chafe, the open-protocol path is our A2A integration guide, and the vocabulary cleanup is the Business AI terminology map.

There Is No Box in SAP's Launchpad for Your Azure OpenAI Key

frankgg — Sun, 08 Nov 2026 13:43:41 +0000

We run SAP AI Lab — two of us, one in ML systems, the other in enterprise information systems; independent blog, endorsed by neither vendor. Wiring Azure OpenAI into SAP BTP is the most common "first AI project" for SAP architects in 2026, and we watched two attempts fail the same way before we got it right ourselves. Verified as of 2026-11-08.

Both teams started with the same sentence in their design doc: "register our Azure OpenAI endpoint in SAP AI Launchpad." There is no such registration. The Launchpad has no form where you paste your own *.openai.azure.com URL and API key. What actually exists are two genuinely different paths, and confusing them is the single biggest source of failed setups.

Path A: SAP-managed capacity — your keys are never involved

The Generative AI hub in SAP AI Core offers Azure OpenAI models (gpt-4o, gpt-4o-mini, the gpt-4.1 family) through the azure-openai executable, running on SAP-managed Azure capacity. Your application authenticates with a BTP service key; SAP's Azure credentials never surface to you, and there is nothing to grant on your Azure subscription. This is the fast, well-trodden path — billed through your SAP AI Core subscription.

Except it's gated by one line item nobody reads: the hub and its foundation-models/orchestration scenarios are not available in the Free or Standard service plans — you need the AI Core extended plan. Every time a colleague posts "the Generative AI hub is missing from my Launchpad," the answer is the service plan, not a bug, not a permission. If you're setting up a subaccount and identity layer first, our BTP subaccount + Entra SSO walkthrough covers that hour.

Path B: bring your own — call your own resource, directly

If the requirement is "inference must run on our subscription, quota, and region" — billing against your own enterprise agreement — the path is REST from your BTP application straight to your Azure OpenAI deployment. The API key works, but the production answer is Entra ID with a data-plane role: Cognitive Services OpenAI User (role ID 5e0bd9bd-7b93-4f28-af87-19fc36ad61bd) permits inference but not key reading or deployment management, with a token scoped to https://cognitiveservices.azure.com/.default. One trap, straight from our incident log: management-plane roles govern the resource; if you assigned only those, chat/completions still 401s until the data-plane assignment exists. And the second-most-common 404 on this endpoint is semantic: the URL takes the deployment name, not the model name — two very different strings.

The orchestration layer most teams skip and shouldn't

On Path A, the orchestration executable gives you a pipeline you'd otherwise rebuild badly in app code: grounding → templating → masking → input/output filtering → model configuration, invoked as one POST to /v2/completion. Our favorite two features: a masking module with SAP Data Privacy Integration that anonymizes entities (emails, phone numbers) before the prompt reaches the model and re-substitutes on the way out; and turning modules from an object into an array converts the call into a fallback chain — gpt-4o degrading to gpt-4o-mini when the first fails. Small API honesty note: max_tokens is deprecated in the current spec — use max_completion_tokens, and if a parameter is silently dropped, the X-Orchestration-Dropped-Model-Params response header tells you which.

Two residency caveats before your compliance meeting: in SAP's model-availability matrix, Yes* means a model may be served cross-region for load balancing — pin regions and check the matrix before promising EU-only processing. And no, Cloud Connector is not your egress proxy: it tunnels to private networks behind it; it does not proxy arbitrary outbound REST to Azure's public endpoint.

The full walkthrough with all the pricing sources and checklists is on our site: Connect Azure OpenAI to SAP BTP: Generative AI Orchestrator Setup — the complete CLI sequence, the Launchpad role collection, the working masking payload, and the error-by-error troubleshooting table. For what the same model layer means for Joule users, see our Joule + M365 Copilot guide.

We Wired SAP Joule to an Azure AI Foundry Agent. The Protocol Was the Easy Part.

frankgg — Sun, 08 Nov 2026 13:36:33 +0000

We run SAP AI Lab — two of us, one in ML systems, one in enterprise information systems, independent of both vendors whose acronyms appear below. When SAP put A2A at the center of its BTP agentic stack at TechEd Berlin 2025 and Microsoft shipped an A2A endpoint in Foundry Agent Service, we tried to connect the two and wrote down every wall we hit. All facts below re-verified against SAP and Microsoft documentation as of 2026-11-08.

First, one line of context for anyone arriving late: the Agent2Agent protocol is the open standard for agents calling other agents — an Agent Card published at /.well-known/agent-card.json, then tasks with a real lifecycle (submitted → working → terminal states, with input-required for "a human must approve this"). It complements MCP rather than competing: MCP gives each agent depth against its tools, A2A gives the system reach across an organizational boundary. Google donated it to the Linux Foundation in 2025, where MCP also lives now, and both SAP and Microsoft ship first-party support.

The protocol mechanics were fine. The platform edges are where we lost an afternoon. Three constraints shaped the entire design.

1. Joule waits ~60 seconds. Plan your task topology around that.

The SAP side is clean on paper: a custom agent built in Joule Studio (GA since December 2025) with the namespace joule.ext, a capability file using agent-request against a BTP HTTP destination, deployed with the Joule Studio CLI. Two gotchas the docs make painful: the destination URL must point at the agent's base without the /.well-known/ suffix — Joule appends it itself — and the whole call is synchronous with a budget of roughly 60 seconds. A credit-block review that takes four minutes cannot live behind that timeout. Long work must become a task you surface through a status update or a follow-up turn that passes the same contextId and taskId back. Design for handoff, not for holding the connection.

2. The Foundry inbound endpoint will not stream to you.

Microsoft exposes an existing prompt agent as an A2A endpoint — genuinely no bespoke glue — but read the limits before sketching architecture: incoming A2A is text modality only, no SSE streaming, tasks and contexts retained 60 days after last write, and v1.0 bound to JSON-RPC only (no gRPC). Enablement isn't in the portal; it's a REST PATCH against the agent's endpoint/protocols/a2a path. Even if your SAP-side agent streams, cross this boundary with GetTask polling. We rebuilt a pretty streaming demo into a poll loop in about forty minutes.

3. Omit the version, and you silently get the old one.

This is the one we'd tattoo on a client laptop. One Foundry endpoint serves both A2A v1.0 (generally available) and v0.3 (preview). Today, omitting the version falls back to v0.3 — not the GA version. Pin it explicitly with the A2A-Version: 1.0 header or the versioned card path, and note that conflicting signals return HTTP 400 version-ambiguous. Pinning matters because v1.0 reshuffled the wire format: message/send became SendMessage, the kind discriminator and final flag are gone, enums are SCREAMING_SNAKE_CASE, and transport details moved into supportedInterfaces with a per-interface protocolVersion. Every v0.3-era snippet in your notes needs a moment of suspicion before you reuse it.

Two security notes while we're here. A public agent card advertises your skills to anyone probing the well-known URI — gate it, or serve an authenticated extended card. And on the Azure side, an A2A caller needs the Foundry Agent Consumer role at project or agent scope; key-based and anonymous card access aren't supported.

Our reference build uses a2a-sdk 1.3.0 (Python 3.12+) — the SDK handles wire format, task store, and streaming so your code is just an executor class. If the card format itself is what you're wrestling with, the Agent Card deep-dive covers URI, capabilities, and skills field by field, and the model layer behind your agents is its own integration project.

The full walkthrough with all the pricing sources and checklists is on our site: A2A Protocol with SAP Joule & Azure AI Foundry: A Practical Guide — step-by-step build, the working executor code, the destination setup, and the smoke tests we run before registering any endpoint.

The Azure CLI Extension That Doesn't Exist — And Is Probably in Your SAP Runbook

frankgg — Sun, 08 Nov 2026 13:35:50 +0000

We run SAP AI Lab — two of us, one in ML systems, the other in enterprise information systems. We're independent and not affiliated with SAP or Microsoft, which is exactly why we rebuild deployment runbooks from primary sources instead of trusting them: a blog post is a snapshot, and this area moves. Our findings below trace to Microsoft Learn pages last updated between October 2025 and August 2026, verified as of 2026-11-08. Last month we nearly got burned anyway.

`az extension add --name azure-ha` will fail, and it should

While checking a SAP HANA high-availability runbook line by line against Microsoft Learn, we searched the Azure CLI extension index for azure-ha — the extension several tutorials, blog posts, and (increasingly) AI-generated runbooks tell you to install. It does not exist. Nothing by that name ships in the index. If a runbook says otherwise, it is stale or hallucinated.

What the real HA enablement actually consists of, per Microsoft's current docs (all pages we cite were updated between October 2025 and August 2026):

the az workloads command group — Azure Center for SAP solutions, backed by the Microsoft.Workloads resource provider you must register first;
the az hana module from the Azure/azure-hanaonazure-cli-extension repository;
inside the guest, fence-agents-azure-arm plus SBD/Pacemaker (sudo zypper -n install fence-agents-azure-arm on SLES).

None of it is named azure-ha. The lesson generalizes: verify every CLI incantation against the official index before it reaches a production runbook, because confident-sounding fiction propagates fast.

The second silent failure: certification lists

The other trap that cost us a full afternoon of re-reading: NetWeaver-certified is not HANA-certified. The source of truth for HANA on Azure VMs is the SAP HANA hardware directory, not the older NetWeaver VM list in SAP note 1928533. Microsoft's own reference tables mark E16v3 and E32v3 as "VM type not HANA certified" — and a system on those SKUs sails along until it silently misses HANA's storage latency KPIs (250 MB/s read and write on /hana/log at 1 MB I/O, ≥400 MB/s read on /hana/data).

What storage design looks like now

If your mental model is P30/P40 LUN arithmetic, most of it is obsolete. The pattern today is Premium SSD v2 with rules you can memorize in one sitting: size /hana/data at 1.2× VM RAM, /hana/log at 0.5× RAM (capped at 500 GiB above 1 TiB), /hana/shared at 1× RAM. A single v2 disk tops out at 1,200 MB/s and 80,000 IOPS, so the big M-series machines need striped sets.

And caching, the most-mistaken setting on Premium SSD v1: /hana/data gets None or read-only; /hana/log gets None plus Write Accelerator — mandatory on M-series with v1 disks, and it only works on those families; /hana/shared gets read-only. Premium SSD v2 and Ultra Disk simplify all of this by offering no caching options at all and meeting the latency KPIs without Write Accelerator.

Two gotchas we'd rather hand you than watch you find: every VM SKU has an aggregate storage throughput budget, and an oversized /hana/data volume whose savepoints saturate it will starve redo-log writes — throughput at or below the VM's limit, deliberately. And HANA System Replication requires the same storage type on every replica for data, and likewise for log; mixing Premium SSD on the primary with Ultra on the replica is unsupported, however tempting the benchmark looked.

One networking note worth stealing before you build: attach NICs with Accelerated Networking at VM creation, give the HANA VMs no public IP and manage them through Azure Bastion, and keep virtual network appliances out of the path between the app layer and the database — Microsoft marks that unsupported because it can double latency and break Pacemaker-to-SBD heartbeats, which turns a stretchy dev box into a very confident false failover.

The full walkthrough with all the pricing sources and checklists is on our site: Deploy SAP HANA on Azure: VM Sizing, Storage & Configuration Guide — including the 14-point pre-hdblcm checklist and the NSG port table where HSR silently breaks (3xx13, 3xx15, 3xx40–3xx98). If you're closer to the invoice than to the OS disk, the cost side of these SKUs, meter by meter, is in our RISE cost breakdown, and the subscription layout that makes these rules enforceable is in our Azure landing zone guide.