Research Duquesne Advisory delivers in-depth analyses of Information and Communications Technologies, their implementations and their markets. Research is based on critical observation of the market by the analysts and their on-going contacts with the vendor community, together with hands-on, practical experience in consulting engagements.

Amazon API Gateway: what’s at stake?

Amazon API Gateway: what’s at stake?
While API management frameworks have been around for a good while, the arrival this summer of public cloud leader Amazon Web Services (AWS) in this small but highly strategic space of the IT market is an event of not inconsiderable consequence.

APIs – application programming interfaces - are the building blocks of modern ICT development, especially Mobile and, inevitably, the Internet of Things.

The most visible examples, of course, are Web APIs published for external use, which have rapidly proliferated over the last ten years, from around 100 in 2005 to perhaps 15000 now. However numerous, published APIs are only part of the picture, since it is widely estimated that developers create ten times as many private APIs for internal use within an enterprise.

These sheer volumes have translated into a significant market opportunity for API management tools and frameworks, and customers have a wide choice of suppliers, ranging from focused specialists to IT heavy hitters. With Amazon coming late to an already crowded playing field, it is entirely reasonable to ask: just what does AWS expect to accomplish and how does the company intend to do it?

Public APIs and the API Economy

In the world of Tech, API management is generally seen mostly as focused on publishing, managing and above all monetizing APIs for external use over the Internet.

Web APIs have “enabled” applications with a dizzying variety of services (everything from mapping, communications, content syndication and cognitive computing to mobile banking and hotel reservations) and have driven a multitude of creative new business models, catchily called the API Economy”.

A lot of money at stake in public APIs
  • Expedia Affiliate Network (EAN) provides hotel booking services to partners such as airline websites. EAN says that 90% of its $2 billion business is now done through Web APIs.
  • External APIs have become fundamental enablers of e-commerce, allowing business partners (on-line retailers like Amazon and e-Bay, suppliers, banks, parcel transporters ...) to integrate into an end-to--end process for the customer, which makes money for everyone.
  • SalesForce.com, a pioneer in both SaaS and APIs, launched in 2000 with an externally exposed API intended to facilitate integration with existing customer information systems. As things turned out, the SaleForce API also engendered a vibrant ecosystem of partner applications, making SalesForce an order of magnitude more valuable.
  • A recent example is provided by large U.S. banks – including Citigroup, BBVA Compass, Bank of America and Capital One - that are now exposing APIs to some of their proprietary software to developers in nimbler, unregulated tech companies. Their objective is to encourage faster innovation around their own banking products and services.
Business risks in API economics

There are of course some downside business risks in API economics. External applications using Web APIs are completely dependent on support by the provider. In November of last year, Netflix pulled the plug on its public API, effectively ending support for a number of third-party apps that made use of the API to get TV and movie show titles as well as other data from the streaming service.

Still, even if the excited 2014 talk about the “API Economy” has calmed down a bit this year (Netflix was a wake-up call), it is difficult to deny that there is a lot of business value at stake.

Private APIs may be an even bigger opportunity

The announcement of the Gateway in New York left us with the impression (right or wrong) that AWS had started by playing catch-up in Web API management but that, somewhere along the line, had realized that private APIs were an even more important issue for most “ordinary” (i.e. non Tech) companies ... and a potentially bigger opportunity for providers of API management frameworks.

In terms of development, private API creation outpaces public APIs by a factor of ten. In terms of “API traffic”, private API requests dwarf public APIs by several orders of magnitude. While Netflix is not a totally representative example, less than 0.3% of the approximately 5 billion API requests it handles each day came from its (now deceased) public API.

Digital business will drive even greater use of private APIs

APIs are well established best practice in modern ICT development and there are good reasons to think that their importance will only grow.
  • Continued proliferation and diversification of user devices
This trend is well underway, especially in Mobile. A striking example (once again!) is Netflix, which uses its internal APIs to support content delivery to over 800 different kinds of devices. Another Tech example is Evernote, which delivers its user workspace service through APIs to a variety of fixed and mobile user devices. Ordinary companies are also increasingly doing the same sort of thing, to communicate with the various devices of employees, customers and business partners.
  • The emergence of the Internet of Things (IoT)
While it’s still early days for the Internet of Things, the IoT is an inevitable use case for APIs. As companies build “connected products” and municipalities become “intelligent cities”, information systems will have to be able to talk with an ever growing number and variety of “smart objects”. The IoT could well trigger the next jump step in API creation and usage.
  • Leveraging existing systems for digital business
New digital business applications have to interact with a dizzying variety of user devices and smart objects, but they also need to tap into the value in existing applications and data bases. Well defined APIs into existing systems – which, if the past is any guide, will remain business critical for a very long time - are the only well architected way to do it.

More broadly, APIs will be the connecting tissue of information systems in the digital transformation.

The API management framework market

What frameworks do

If “don’t reinvent the wheel” is one (of several) good reasons for using APIs, the same can be said of API frameworks. Each API has its own specific core function, but all of them need things like access security, support for multiple versions, usage metering and some level of performance management, not to mention SDK’s and assorted development tools. At a minimum, API frameworks mutualise these functions, allowing developers to focus on what their code should do while, not incidentally, helping managers ensure some control over how, which, where and by whom APIs are being used.

In effect, the framework serves as a shared “API front-end”, handling requests and providing mutualised functions before handing them over to the actual API. For public API management, the leading frameworks also provide sophisticated usage analytics to help optimize revenue generation from partners and other third parties as well as support for billing.

Leading players

The market for API management is still largely “on premises”, but the cloud based part is growing the fastest. Leading players include: API management pioneers such as Mashery (now an Intel company), MuleSoft and Apigee, all launched circa 2004-2006; CA Technologies and Axway who both entered the market in the 2012-2013 timeframe through acquisitions; IBM since the launch in 2013 of the internally developed IBM API Management V2.0, followed by the launch of a cloud based offering in 2014; and, last but far from least, Microsoft (also leveraging an acquisition) with Azure API Management launched in 2014 for its rapidly growing public cloud.

Needless to say, AWS will be facing plenty of tough competition in this market.

Overview of the Amazon API Gateway

Amazon Web Services formally launched its API Gateway in July on the New York stop of the 2015 AWS Summit Tour. Matt Wood, general manager for product strategy at AWS, told conference attendees that the new service enables developers to create resources, attach methods and deploy APIs “in a matter of minutes.”

How it works: the API call flow

While the Gateway supports both public and private APIs, the current focus of the new service - as can be seen on the diagram – is on Web APIs, used externally by mobile apps and websites.

Calls come in over the Internet from mobile devices, websites and other services. To minimize network latency for API end users, Amazon leverages its CloudFront network of 54 Point of Presence (PoPs) worldwide.

Going through the Gateway, APIs can directly invoke:

  • AWS EC2 endpoints, presumably running user code that provides the service

  • AWS Lambda functions: an event-driven service through which IT infrastructure is dynamically allocated to user microservices, an architecture which is particularly interesting for applications involving the Internet of Things.

  • Public http endpoints: any and all endpoints that can be publicly accessed over the Internet allowing, for example, a Web API to integrate other public APIs into the service it provides to end users.

  • Any other AWS service via the Gateway, for example Amazon Kinesis, a service for real-time data processing over large, distributed data streams. Gateway customers can proxy calls directly to Kinesis endpoints, harnessing Kinesis capabilities for massive data ingestion and exposing it to third party developers as if it was their own API

Overall, this is very much an Internet architecture, which is fair enough for public Web APIs but less compelling for private APIs. The Gateway endpoints are public to the Internet and the service cannot – for the moment anyway - work in an AWS Virtual Private (VPC).

This is a regrettable omission. Many companies developing new applications in the cloud – with plenty of private APIs - are doing so in their own secure VPCs. These customers will expect a version of the service that works in a VPC. They will also expect to be able to access private http endpoints, to integrate data from “on premises” legacy systems into new cloud applications.

Pragmatic access security

Leaving aside the VPC issue, Amazon offers its own security tools and technologies to authorize access to APIs and control service operation access. In addition to AWS Identity and Access Management (IAM), customers can use AWS Sigv4 to sign and authorize API calls, with verification of signed calls handled by the Gateway using the same technology AWS has built for its own APIs. This allows developers to centralize access control into policy documents, and achieve separation of concerns between their app’s logic, and the authorization code.

For customers already using OAuth tokens or other authorization mechanisms, the Gateway can be set up to forward the token headers to the back end for verification.

This is an entirely sensible approach that leverages and integrates existing AWS security tools and technologies while accommodating a customer’s existing investments as needed.

Performance management: a perennial technical headache... and a business issue

Performance management is a big concern for API providers, due to growing volumes, API traffic spikes and, most importantly, the need for predictable performance – despite unpredictable requests and workloads - to guarantee the quality of the user experience. Poor performance can easily translate into lost business, for example, for providers of reservation services for cars or restaurants or whatever. If the API generated confirmation SMS takes too long to arrive, the mobile customer will quickly take her business elsewhere.

Performance has always been a maddeningly complicated problem, because it depends on so many different, often interacting, factors. In the case of services delivered through Web APIs, the situation is even more complicated because everything is distributed and anything on the chain can be a bottleneck.

API providers typically have at least some shared, “front-end” tools in place, for example, to deal with call traffic spikes as well as to optimize data reuse by successive calls. On the back-end, specific application architectures can (as always) create difficult performance issues, together with the scalability of the underlying infrastructure, a level at which “dynamic provisioning” of resources may be essential. Not to mention the eternal problem of network latency.

In the domain of API performance management, the Amazon Gateway does provide (or integrate with) some helpful features including:
Caching: the output of API calls can be saved to avoid calling backend systems unnecessarily.
Throttling: call traffic management so that back-end operations can withstand traffic spikes ... but of course at the cost of reduced performance for the calls that have been throttled
Amazon CloudFront: the Gateway is integrated with CloudFront to take advantage of the AWS network of edge locations to reduce latency for API requests and responses.
Denial of Service protection: the Gateway offers DDoS protection out of the box, automatically dealing with malicious requests or lower level attacks, such as SYN floods, without impacting the customer’s backend.

A useful addition to this list – although not by any means a “silver bullet” - would be analytical tools to monitor and analyse API performance, beyond the volume and latency metrics currently provided.

Development: “more to come”

The Gateway provide two essential development functions
• Versioning : to manage multiple versions of the API
• Generation of customised client SDK tool kits (iOS, Android, JavaScript)

Another point worth mentioning is that open source tools are provided for the upload of existing Swagger API descriptions, since Swagger is close to being a “de facto standard”.

Even so, top competitors are much more advanced. IBM API Management, for example, is well integrated with its BlueMix PaaS. In this area, there is work to be done.

Limited support for Web API economics

The Amazon Gateway does of course provide API Keys to Meter Usage by 3rd Party Developers, through CloudWatch Logs. In its current version, however, it does not include the sorts of sophisticated usage analytics (or even billing support) which leading players offer in a variety of vertical markets, to optimize monetization and value creation.

Disruptive pricing

The pricing of the new service undercuts many competitors, with “pay as you go” at $3.50 per million API calls plus standard Amazon data transfer fees. There are no minimum fees or upfront commitments as is often the case. In line with usual Amazon practice, low prices will certainly be a recurring argument for the Gateway, but pricing is unlikely to be the key factor in customer decisions.

In short

The Amazon API Gateway can fairly be described for the moment as a somewhat “feature light”, lower level foundation offering. It has all the basics but is short of a number of features (billing, sophisticated analytics, various development tools...) already offered by established players.

Given the company’s commitment and engineering resources, however, the new service can reasonably be expected to reach competitive par within a year or so.

Amazon and API Economics

Web API market opportunities

With the launch of the Amazon API Gateway, the company is staking out a position in the API economy, even if it is arriving in a crowded playing field with a lower level “foundation” offering.

In the near term, the Gateway has a natural market with the thousands of young SaaS companies in the AWS cloud who, however happy, are essentially “captive” customers. AWS can now provide them with an entirely reasonable, low cost solution to help them manage their Web APIs.

More broadly, API management is still largely done “on premises”, and established competitors are well entrenched in many big companies. That could of course change. Amazon is a company that fervently believes in the absolute inevitability of the public cloud for almost everyone... and it can certainly afford to play a “long game”.

As companies develop more new applications in the Amazon cloud, the Gateway will become an increasingly logical and attractive option. In the meantime, the company will leverage its scale to undercut competitors on price while progressively catching up on functionality.

Private API management for Amazon customers

The announcement of the Amazon API Gateway this summer in New York left us with the impression (right or wrong) that the company had started out by playing catch-up in Web API management but that, somewhere along the line, had realized that Private APIs were the real opportunity.

The natural market, of course, is customers that are building new applications in the Amazon cloud. For them, the big advantage of the Gateway – more important than the low price - is that it is designed to work well with all the other services that AWS delivers.

A key example is the integration of the Gateway with AWS Lambda, a compute service that runs user microservices in response to events and automatically manages server resources as required. This approach is, of course, particularly well adapted to IoT applications in which “events” coming from a multitude of “smart objects” can trigger the microservices needed to handle them. In this sort of “server-less” architecture, developers can focus on the business logic of the microservices, which serve as reusable application building blocks.

Taking a broader perspective, the vision appears to be: as user devices proliferate, as the Internet of Things takes off and as digital business accelerates, infrastructure will fade into the background and the cloud will morph into a complete set of business services, accessible through APIs.

If that’s the vision, then the launch of the Amazon API Gateway is a very strategic announcement indeed. What’s important is not so much the modest “tolls” that the friendly gatekeeper can collect on API calls. What is really at stake is a strategic position at the architectural cross-roads of enterprise information systems, in the Amazon cloud.


In the perspective of the much hyped “API economy”, the Amazon API Gateway can be seen as late to market and light on the sophisticated Web API management features of established competitors. There is a good deal of truth in this, but it may not matter, since AWS should have little difficulty in reaching competitive par.

On the private API side, which we see as potentially more important, the biggest omission is the lack of support for Virtual Private Clouds. While Amazon (as usual) isn’t saying much about its roadmap, it is not unreasonable to expect that a VPC version – together with access to private http endpoints for legacy integration - is already in the works.

Overall, the new service does have a big competitive advantage with AWS customers: it runs in the Amazon cloud and was designed to work with all the other AWS services. As customers develop new applications in the cloud, the Amazon API Gateway will become - over time - an increasingly attractive option. Fortunately, Amazon is a company with a good deal of strategic patience.

Sunday, October 4th 2015
Duquesne Advisory
Newsletter To subscribe to the Duquesne Advisory Newsletter, please enter your e-mail address.

Duquesne Advisory

Duquesne Advisory is a European firm, dedicated to researching, understanding and advising clients worldwide on opportunities and trends in Information and Communications technology.


Duquesne Advisory delivers in-depth analyses of Information and Communications Technologies, their implementations and their markets. Research is based on critical observation of the market by the analysts and their on-going contacts with the vendor community, together with hands-on, practical experience in consulting engagements.


The analysts of Duquesne Advisory leverage the Firm’s ongoing market and technology research to undertake high added value consulting engagements for both ICT users and ICT providers. Focused on client service, their approach is rigorous and methodical, and at the same time pragmatic and operational.