Support VNET for Basic Tier of APIM
Our APIs are deployed to Service Fabric cluster in a VNET. If we want to expose our APIs through APIM, we have to use the Premium Tier of APIM since that's the only tier where VNET support is included.
Premium Tier of APIM has bunch of other features like AD authentication, Multi-region support, 4000 reqs/sec etc., which we don't need and don't care.
Why are all those features clubbed together and provided as an all or nothing solution?
Basic Tier fits our use case perfectly, if only we can deploy it in a VNET.
Service Fabric integration with APIM is one of it's coolest features and can help in it's adoption. But Microsoft strategy of artificially inflating the pricing and forcing customers to pay for features they don't need isn't going to work well.
Right now, the only way to use Service Fabric in production with APIM is to pay $7000 per cluster. Think about it for a minute.Yes, there are other ways to implement APIM but any advantage Service Fabric has over Kubernetes or Docker swarm is being thrown away. The pricing level will deter most customers from even trying the platform.
It's a cool integration but out of reach of most people!
Aaron Guimond commented
I just had to deploy a client to a non-MS API management solution because of the poor structuring of the APIM service plans. They needed VNET AND an SLA. At 3600/month they wanted none of it. I'm an Azure guy through and through and this kind of thing just makes it hard to sell the service. Now the client has a foot in with another CSP, something I was trying to avoid. Who is making these decisions? You don't need to give it away but this is a bit much.
Ram Ramakrishnan commented
It looks like the upcoming consumption pricing plan also will not support VNET. So the only choice is premium which is way too expensive to even consider for us right now. We are researching alternate solutions.
We have been using Azure since the real early days in 2012. What was great about the cloud and Microsoft's ethos at the time (which they had right) is that it was all about scale as you grow and pay for what you need. Unfortunately as Azure has grown clearly the 'old' marketing folks have moved departments, taken over and completely missed the point. Large swaths of Microsoft's Azure services are now unusable because they have adopted this strategy of adding BASIC / absolutely necessary functionality and features - like security - (deploying to VNETs) to only the highest tiers which have ridiculous prices. Therefore for a lot of deployments where API Managment and other Azure services could be utilised MS have priced themselves out of the market / consideration. Apps are built without including their services and as they say small Acorns in time grow into large oak trees. Once built these apps will be around for years and if they contain competitors offerings they won't be rewritten / replaced anytime soon. Even as an SME with reasonable budget for most projects we can't justify £2400 p/m for API management for a particular service, £900 p/m for Azure secure app environment (this not even including VMs), and various other disproportionate costs to simply run a various low volume services in a particular project securely - which is a must have requirement. AWS have this right. Create, maintain, and secure APIs at any scale.
Phil Murray commented
Completely agree. Providing a secure solution should not require a full enterprise tier. Come on Microsoft, you want us to us the platform but we can only do so if the security and pricing models are compatible.
Trond Olsen commented
VNET support would be appreciated in lower sub-licensing tiers, or the consumption-based tier. This will allow growth of Azure integration services from Logic Apps to more Biztalk-like functionality. We primarily need VNET support to avoid routing client traffic over internet.
Any status updates?
Would love to get some feedback from MS regarding this. It's a dealbreaker for our customers if we can't use apim with vnet for a reasonable price.
Chris Buchanan commented
Agreed. Even if this was part of the standard tier it would go a long way to help secure APIs by minimizing the attack vector.
Would love to use this but the current pricing is impossible to justify. Our use cases all require the APIs to be secured off the general internet but volumes only warrant the basic tier. Pricing highly for basic security features will always preclude this technology from regulated industry startups.
Just did a POC with my team demonstrating Service Fabric integration following the tutorial with APIM Developer sku only to find that the only production sku supporting this is Premium. Ridiculous. A backend API isn’t truly backend unless it is on a private network. At a minimum Standard sky should support VNET integration. This limitation is currently a blocker for us.
Agree with other comments.
We'd love to use APIM for our internal middleware layer. We could only achieve this with the appropriate degree of security using APIM connected to VLAN in internal mode.
This is only available on Premium tier which would cost around $43,000 pa.
This is unjustifiable for our workload.
Other on premise products like Mulesoft are significantly cheaper than this.
This should be a feature of all tiers.
By bundling all the features rather than throughput into the Premium tier you're completely pricing us out of this product.
You have a whole "how-to" on combining App Gateway with APIM so you get the best of WAF combined with APIM and then discover it'll cost at least £2000 a month just for the APIM.
Having VNET support for basic or standard tiers is crucial for us and would help make our organizations transition to Azure much easier.
We are in the government space and having the ability to utilize the APIM with VNET capabilities not only helps us protect our internal resources that should not be available to the outside but also ensures that we stay compliant with federal guidelines and laws.
Additionally, like others have mentioned we cannot currently justify the monthly cost of the premium tier right now as our current projections would not be even close to taking advantage of some of the features such as the cache size, scale out units, and maximum throughput.
Andy Thierer commented
The initial price tag for using APIM with VNET support in production is much to high. Especially if one doesn't need the additional features like multi-region deployment "oversized" cache, etc.
Our use case is to keep the backend services in a private VNET without the hassle of setting up mTLS for each and every api. We don't even now how many requests we'll see per day in the first months/year. That's why we would like to start with reasonable expenditure and upgrade along the road as we see more apis published and requests/sec rising.
Nearly EUR 2,500 per month for VNET support seems daunting.