Three planes under one name
A partner sends an order request while Ada changes tomorrow’s rate limit. Those are two different paths. The request goes through the gateway; the configuration change goes through the management plane. Meanwhile, a new developer opens the portal to learn how to call the API. Put one person on each path before learning the three plane names. Then choose a tier whose actual features and capacity fit those paths.
Keep the three parts separate when troubleshooting: a portal sign-up problem differs from a policy rejection at the gateway. A management-plane deployment may change runtime behavior after configuration propagates. Do not assume every in-flight request is guaranteed unaffected or that a tier change has a universal downtime pattern. Use a test API, revision or rollout plan appropriate to the risk.
- The three planes
- Gateway — the runtime data plane every request flows through. Management plane — the control surface where APIs, products, and policies are defined. Developer portal — the consumer-facing site for discovery and sign-up. Only the gateway is in the request's path; the other two shape what it does.
Which plane handles each moment?
The warehouse sends GET /products/42 with its subscription key. Write down which plane handles each of these, then check:
You change the rate limit on the products API.
The request is checked against that limit and forwarded to the backend.
A new partner developer reads how to call /products.
Check your answer
1 is the management plane (configuration). 2 is the gateway, the data plane, where every live request passes. 3 is the developer portal. Tiers (§3) differ mostly in how much of each plane you get and where it can sit on a network; decide that after this picture is clear.
Gateway policy and backend balancing
An API gateway reads request details and applies routing, authentication or rate-limit policies you configure. A load balancer distributes traffic among backend instances and often performs health checks. APIM can also route to a backend pool and load-balance among its members, so the jobs can overlap. Whether an existing load balancer stays depends on its health, network and application requirements; draw the actual request path before removing it.
Any gateway control applies only to requests that pass through it. If the backend remains directly reachable, configure network restrictions and backend authentication so callers cannot bypass the intended policy. APIM’s managed identity can authenticate to a supporting backend; it is not, by itself, a network firewall. Check tier networking support against the current feature matrix.
The first APIM decision is a billing decision.
The tiers — what you actually buy
Choose an APIM tier from its capabilities, intended environment and current price. Consumption bills by request above its allowance; the other tiers have ongoing unit charges, and v2 can add request charges above a threshold. The classic and v2 lines have different networking and migration paths. Use the current comparison and pricing calculator before committing a SKU.
| Tier | Billing | Fits | Watch for |
|---|---|---|---|
| Consumption | Per-request above allowance | Variable traffic when its feature set fits | No developer portal or rate-limit-by-key; subscription limits are available |
| Developer | Ongoing unit charge | Non-production dev and test | No SLA; do not use for production partner traffic |
| Basic / Standard / Premium (classic) | Ongoing unit charges | Production options; Premium supports VNet injection and managed multi-region | Check networking, capacity and current price by tier |
| Basic v2 / Standard v2 / Premium v2 | Unit charges; check request overages | Basic v2 for dev/test; Standard v2 and Premium v2 for production | Networking and multi-region support differ from classic; read the current grid |
Consumption lacks a developer portal and the rate-limit-by-key policy, although it does support subscription-based rate limits. Developer is non-production and has no SLA. Basic v2 has an SLA but Microsoft describes it for development and testing. For this production partner example, Standard v2 is the smallest v2 tier Microsoft identifies as production-ready and it supports the portal and per-key policies. Check the current matrix for private backends, inbound endpoints, regions and costs before deploying.12
Play it through
Place a non-production lab and a production partner API on tiers that fit both features and production guidance. Compare current pricing after the exercise.
When APIM earns it — and when it does not
A gateway adds cost, latency and an operating surface. One internal API with one team and no shared gateway requirements may be simpler with controls in the backend. External partners, several backends, shared access policies or self-service onboarding can justify APIM. Count the actual consumers, list the policies and network requirements, and compare the gateway’s cost with maintaining those controls in each service.
Say the anti-pattern out loud so you catch it in reviews: standing up a Premium APIM in front of a single internal service "for consistency," or "so we're ready to scale," months before a second consumer exists. That is paying enterprise gateway prices to solve a problem you do not have yet — the mirror image of the middleware team that refuses APIM when partners are already knocking. The senior move is to name the variable (consumers you do not control) and let it, not fashion, decide.
Choosing the smallest tier that carries the story
Campux needs a production gateway for three partners, a developer portal and a per-partner limit. Consumption lacks the portal; Developer has no SLA; Basic v2 has an SLA but Microsoft describes it for development and testing. Standard v2 is the production-ready v2 choice in this case. It supports the portal and per-key policy and can connect to a network-isolated backend if that becomes a requirement. Premium v2 has additional isolation and scale features; classic Premium currently supports managed multi-region deployment. Record the exact required features and compare the current tier matrix before purchase.
The design note should say: Standard v2 selected for a production partner API with self-service onboarding and per-partner limits. Reassess if backend isolation, availability zones, capacity or multi-region deployment becomes a requirement; verify current features and estimated cost before deployment. This gives a reviewer a reason to challenge or approve the tier without pretending the price is fixed forever.
The planes, put on the wire
Assemble the picture before the next part imports an API into it. You have chosen a tier, which provisioned a gateway at a public hostname like campux-apim.azure-api.net. Behind it, the management plane is where you will define the catalog API, the Partner product, and the policies — none of which a request touches until the gateway is told to apply them. And the developer portal is sitting empty, waiting for products to publish. Part C fills the gateway with an API; Part D gives it behaviour; Part E opens the portal.
The tier line in the design review
A diagram proposes Premium APIM for one internal service. Ask which features require it: backend isolation, availability zones, managed multi-region deployment, capacity or a partner portal. If none applies, compare a simpler tier or no separate gateway. Record a current pricing estimate and the expected traffic before claiming savings.
Continue with a supplied build
Follow the same fictional catalogue through this track. The supplied contract and worked checks let you practise without an Azure estate; the optional import/mock path makes real gateway requests. Each step states what it proves and what it does not.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B — the policy is configured through the management plane. The gateway applies the resulting policy when the configuration reaches it. Do not infer from the diagram that every in-flight request is guaranteed unaffected, or that a change needs no testing. Use a revision or controlled rollout for a risky policy and watch the gateway’s responses. The developer portal is not where the policy executes.
C — Standard v2. The question says production. Microsoft describes Basic v2 for development and testing even though it has an SLA. Standard v2 is production-ready and supports the required portal and per-key policy. Consumption lacks the portal, Developer is non-production without an SLA, and Premium v2 adds capabilities not requested here. Check the current feature table and pricing estimate before choosing the actual SKU.
Uncontrolled consumers, per-consumer metering, and several backends behind one product. Each is a chore that multiplies per consumer and has no clean home in a single app, which is the definition of gateway work. The two rejects are the twin failure modes. The single internal service with one caller is the textbook "when not to" — middleware suffices, and APIM would be a hop and a bill for no one. And "looks enterprise-ready" is buying an operational surface to decorate a diagram, which Class 32 will bill you for every month. The discipline: a gateway is justified by a problem you have, named as a variable (consumers you do not control), never by a posture you want to project.
# APIM design notes
1. The gateway is the only plane in the request path;
if it's down, partner traffic stops.
2. We'll define APIs, products, and policies on the
management plane, via Bicep in the repo.
3. APIM can balance backend pools, so we can drop
our existing load balancer without testing its job.
4. The developer portal is where partners sign up;
it isn't in the request hot path.
Line three assumes too much. APIM can load-balance across a configured backend pool, but that does not prove the existing load balancer’s health checks, networking and distribution rules are covered. Map the backend topology and test the replacement before removing anything. The gateway remains the runtime path for API requests; the management plane configures it and the developer portal handles discovery and sign-up.
Agree with the instinct, then correct the category error. Starting small and moving up is exactly right as a habit — it is what §4 preaches. The mistake is not the instinct; it is treating this as a scale decision when it is a capability decision. "Move up later if we need to" assumes the missing pieces are about size, so a bigger box fixes them. But the developer portal and per-key limiting are not on Consumption at any volume — they are simply absent from that tier. The "if" is already resolved: we know we need both, today, because the partner story is the whole point.
Consumption does not have the developer portal, so starting there cannot meet the stated onboarding plan. Moving from the Consumption line to a v2 tier is a migration rather than assuming a simple resize; check the current migration guidance and plan for configuration, keys, DNS and partner cutover. Choose a production-ready tier before inviting partners to rely on it.
List all requirements before pricing: production status, portal, per-partner policy, network path, region and expected request volume. Standard v2 fits this one-region production example. Premium v2 or classic Premium may become necessary for other requirements. Record a current feature-matrix link and calculator estimate in the decision.
Open with the qualifying question, because agreeing too fast is a junior tell. "Before I agree, I want one number: how many consumers do we not control? And two capability questions: do we need to meter or bill per consumer, and do we need VNet integration or multiple regions?" That shows the interviewer you know a gateway is a cost and an operational surface, not a default — and that you have a specific variable, not a vibe, deciding it. If the honest answer is "one internal caller, no billing, one region," the senior move is to say APIM is probably overkill here.
Explain the three parts: the gateway processes API requests using configured policies; the management plane stores and deploys API definitions and policies; the developer portal supports discovery and sign-up. A management change can alter gateway behavior after it propagates, so test it and observe live traffic during rollout.
For a production partner API requiring a portal, I would compare production-ready tiers and choose Standard v2 here after checking current features and cost. I would evaluate Premium v2 for full VNet injection and classic Premium if managed multi-region deployment were required. The choice follows requirements, not a fixed price from a lesson.
Five things worth carrying out of this part
- APIM is three planes under one name: the gateway (runtime, in the request path), the management plane (config, not in the path), and the developer portal (sign-up, not in the path). Knowing which plane a change lands on tells you its blast radius.
- The gateway applies configured API policies. APIM backend pools can also balance traffic; retain or remove a separate load balancer only after checking the actual backend topology.
- An APIM tier sets capabilities and cost. Consumption lacks a portal; Developer has no SLA; Basic v2 is positioned for dev/test; Standard v2 and Premium v2 are production-ready v2 tiers.
- Pick the smallest tier that carries the features the story actually needs, and write down why. Reaching for Premium "to be ready" is a cost anti-pattern; refusing APIM when partners are knocking is the mirror one.
- The variable that decides whether APIM earns its keep is the number of consumers you do not control. One internal caller: skip it. Partners, billing, or several backends as one product: it pays.
- Consumption has no fixed monthly instance charge and bills requests above an allowance. Features and limits differ from other tiers; the missing developer portal is what excludes it from this particular onboarding design. Check Microsoft’s cost guidance for current billing behavior. ↩
- Microsoft’s feature comparison currently lists Standard v2 for isolated backends, Premium v2 for VNet injection, and classic Premium for managed multi-region deployment. These capabilities and regional availability can change; verify the matrix and pricing before selecting a SKU. ↩
Choose an API Management tier you can defend, and know which tier is the anti-pattern for a small team.
Play the lesson above to stamp this class.