The Capacity Billing Model That Creates Overspend
Power Pages licensing is capacity-based: you purchase session packs rather than per-user licences. An authenticated session is defined as a single user logging in and interacting with a Power Pages site — regardless of how long the session lasts or how many pages are visited. An anonymous session is defined as a single user visit to a Power Pages site without logging in. Session counts reset monthly. The capacity model creates a specific overspend pattern that per-user licensing avoids: if your user count is predictable but your session frequency is variable, capacity billing can produce wide monthly cost variance that is difficult to budget and easy to exceed.
The key commercial distinction: authenticated sessions are consumed at $0.20–$0.40 per session at EA rates (depending on volume tier); anonymous sessions are consumed at $0.02–$0.04 per session. The 10x price differential between authenticated and anonymous sessions is the primary lever for reducing Power Pages licensing costs — any use case that does not require user identity and personalisation can potentially be re-architected as anonymous access, reducing the per-session cost by 90%.
How Sessions Are Counted
Understanding Microsoft's session counting methodology is essential for budgeting Power Pages correctly. An authenticated session begins when a user logs in and ends after 24 hours of inactivity (not after logout). A user who logs in at 9am, works for 30 minutes, leaves the browser open, and logs back in at 4pm the same day consumes one session. A user who works on Monday and again on Wednesday consumes two sessions. This 24-hour inactivity window is relatively generous — in practice, most users consume one session per working day rather than one session per login event.
Anonymous sessions are counted per unique browser visit, defined by a cookie. A single user who visits the site from their desktop browser and their mobile device in the same month consumes two anonymous sessions. A user who clears browser cookies and revisits consumes an additional session. For high-traffic anonymous portals — customer self-service sites, public tender portals, regulatory disclosure pages — the session count can grow substantially faster than your registered user count might suggest. Building a realistic session forecast requires analysing your web analytics data, not counting your user population.
Session packs and EA commitment
Power Pages sessions are purchased in packs within your EA. The standard pack structure includes 100 authenticated sessions/month and 1,000 anonymous sessions/month as the base unit. Enterprises with substantial portal traffic negotiate larger pack commitments at progressively lower per-session rates. The critical negotiation point: session packs purchased in your EA are consumed monthly — unused sessions do not roll over. Over-provisioning session packs produces the same waste as over-provisioning user licences: you pay for capacity you do not consume. Accurate session forecasting, based on actual web traffic data rather than maximum theoretical usage, is the foundation of correct Power Pages procurement.
Classifying Use Cases by Session Type
The most impactful decision in Power Pages licensing is the authenticated versus anonymous classification for each portal deployment. Authenticated portals require users to log in — they are appropriate for personalised experiences, transactional workflows, data submission, and any scenario where the portal needs to know who the user is and what data they should see. Anonymous portals serve users who do not log in — they are appropriate for public information, read-only content, general FAQs, document libraries accessible to all, and any scenario where personalisation is not required.
The classification error that drives overspend: organisations deploy authenticated portals by default because the Power Pages template sets authenticated access as the default, and developers do not challenge whether login is actually necessary for the use case. A supplier qualification portal where suppliers simply download a requirements document does not require authenticated access. A regulatory compliance disclosure page accessible to all employees does not require login. A product knowledge base for field service engineers who all see the same content does not require user identity. Re-classifying these portals as anonymous does not reduce their functionality — it reduces their per-session cost by 90%.
| Use Case | Login Required? | Correct Session Type | Monthly Cost (1,000 sessions) | Saving vs Authenticated |
|---|---|---|---|---|
| Customer self-service account portal | Yes — personalised data | Authenticated | $200–$400 | — |
| Supplier onboarding with document submission | Yes — identity required | Authenticated | $200–$400 | — |
| Employee HR self-service (benefits, payslips) | Yes — personal data | Authenticated | $200–$400 | — |
| Public product/service information portal | No — same for all | Anonymous | $20–$40 | $180–$360/mo |
| Regulatory compliance document library | No — read-only | Anonymous | $20–$40 | $180–$360/mo |
| Field service knowledge base (uniform access) | No — same content all users | Anonymous | $20–$40 | $180–$360/mo |
Dataverse Interaction and Add-On Costs
Power Pages sites that read from or write to Dataverse consume Dataverse capacity — storage and API calls — in addition to session packs. This is the second hidden cost layer in Power Pages deployments. Each authenticated session that touches Dataverse consumes API requests (counted as API call capacity) and data read/write operations (counted against Dataverse database storage). For portals with high-volume form submissions, customer data retrieval, or complex multi-table queries, the Dataverse consumption add-on can rival or exceed the session pack cost.
The Dataverse database storage pricing is $40/GB/month (database), versus $2/GB/month for Dataverse file storage — a 20x differential. Organisations that store documents, attachments, and binary files in Dataverse database rows rather than as file/blob storage are paying 20x more than necessary for that storage. This is a common architecture pattern in Power Pages deployments built by developers who follow the default data model without considering the storage cost implications. Auditing your Dataverse table structure for binary storage misalignment is a fast, high-value cost reduction exercise for any Power Pages deployment with significant attachment or document volumes.
Overage Risk and Monitoring
Power Pages overage — consuming more sessions than your EA commitment covers — is billed through Azure at list PAYG rates, which are higher than EA committed rates. For organisations that have deployed Power Pages for external-facing portals (customer portals, partner portals, public self-service sites), session volumes can spike unpredictably — during product launches, annual renewal cycles, regulatory compliance deadlines, or high-traffic marketing campaigns. Without monitoring and alerting, these spikes produce unexpected Azure charges that bypass the EA commercial controls entirely.
The governance controls that prevent overage surprises are straightforward: configure session count monitoring in the Power Platform Admin Centre, set alert thresholds at 70% and 90% of your committed session pack, and establish a process for requesting emergency session pack additions when a threshold is breached. Proactive session monitoring is a four-hour implementation task that prevents five-figure overage charges. The absence of this monitoring in most enterprise Power Pages deployments reflects the fact that the deployment team and the procurement team rarely communicate about capacity utilisation — the developer who builds the portal does not know the session commitment, and the procurement manager who bought the capacity does not know the portal's traffic pattern.
Power Pages session overage is billed through Azure at PAYG rates — outside your EA commercial controls. Configure session monitoring at 70% and 90% of your monthly commitment before any external portal launch. For high-traffic external deployments, consider negotiating an overage protection provision in your EA: a contractual rate cap or rollover mechanism that prevents PAYG billing. See our guide on Power Platform licensing for the full negotiation framework.
EA Negotiation Strategy for Power Pages
Power Pages is among the least understood Power Platform components at EA renewal time, which creates opportunity: most Microsoft account teams quote Power Pages based on maximum theoretical portal deployments rather than validated usage. The negotiation starting position is a usage audit — actual session consumption from the Power Platform Admin Centre for the last 6–12 months, segmented by authenticated and anonymous. This data typically shows that committed session packs are over-provisioned by 30–50% relative to actual consumption.
The second negotiation lever is the authenticated-to-anonymous reclassification commitment. Identify portals in your estate where login is not technically required and commit to re-architecting them as anonymous before the next renewal. Quantify the authenticated session reduction this produces. Microsoft account teams are generally willing to adjust Power Pages commitments downward when presented with a documented reclassification plan — the alternative is you underconsume your committed packs.
The third lever is overage protection provisions. For organisations with external-facing portals that experience seasonal or campaign-driven traffic spikes, negotiate an overage buffer provision — an agreed rate for sessions above the monthly commitment that is equal to or lower than your EA per-session rate, preventing the PAYG spike billing described above. This provision is achievable in most EA negotiations for portals with documented traffic patterns. For the full context on Power Platform EA negotiation, see Power Platform licensing complete guide and EA negotiation leverage points. For true-up implications of session overage, see Microsoft true-up compliance guide.
4-Step Action Plan
Step 1 — Audit actual session consumption. Export session utilisation from the Power Platform Admin Centre for the last 12 months, broken down by authenticated and anonymous and by portal. Identify your actual monthly consumption versus your committed pack. Document the gap — this is the over-provision figure you negotiate against at renewal.
Step 2 — Reclassify portals by session type. Review every Power Pages portal in your estate. For each portal, answer: does this portal require user identity to function correctly? If not, reclassify it as anonymous and plan the re-architecture. Quantify the session cost reduction this produces.
Step 3 — Audit Dataverse storage architecture. Identify tables in your Power Pages-related Dataverse environment that store binary files or large attachments in database rows. Calculate the storage cost differential versus moving those files to Dataverse file storage. Plan the migration as a cost reduction action before the next EA renewal.
Step 4 — Implement session monitoring. Configure Power Platform Admin Centre monitoring and alerting for all external-facing portals. Set alerts at 70% and 90% of monthly session pack commitment. Establish a response process for threshold breaches before the next portal launch or high-traffic period. Contact us through our M365 optimisation service if you need support structuring the full Power Platform commercial review.