🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Building a culture of API Excellence (API208)
In this video, Srijan Bhattacharya, Senior Product Manager at Amazon API Gateway, addresses API fragmentation challenges in enterprise organizations managing tens of thousands of APIs across multiple accounts and business units. He introduces Amazon API Gateway Portals, a fully managed developer portal solution that centralizes API discovery, documentation, and governance. The session covers the API excellence mindset, treating APIs as products with single-threaded owners, and demonstrates how Portals enables organizations to create API products, share them across accounts, control documentation freshness, configure scoped access with Cognito, customize branding, and allow developers to test APIs directly from the portal, transforming API chaos into streamlined discovery.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
The Challenge of API Fragmentation: Quantifying the Problem and Defining API Excellence
Every successful digital transformation story starts with APIs, but here is the thing: building great APIs is just half of the battle. The other half is perhaps the more difficult part, which is making the APIs discoverable, accessible, and used by all of your developers. Hello everyone, I'm Srijan Bhattacharya. I'm a Senior Product Manager with the Amazon API Gateway Service team, and I'm here to talk to you about building a culture of API excellence with Amazon API Gateway and the tools that it provides.
In the next 20 minutes, I'll be walking you through a framework that will help you turn API chaos into a streamlined discovery mechanism. It will help you cut operational risk and further your journey into building a culture of API excellence. We will be covering three key areas in this talk. First, we will quantify the problem that a fragmented API ecosystem will result in. Next, we will put some definition around what the culture and mindset of API excellence looks like. Finally, we will introduce the platform solution that ties all of this together.
Let's start by getting a quick pulse check to understand the true scale of the problem that you're facing today. I want you to think about your organization and silently answer the three questions that come up. First, how many business units or major product areas does your organization have? Take a quick mental note of that number. This number is your first variable, and it represents the organizational silos that you operate in. Next, how many AWS accounts do you envision having under each of these organizations that you have? We know that you don't use just one account, hopefully not. If you are using multiple accounts, this immediately multiplies the complexity.
Finally, if you think about the number of APIs that you have in each of those accounts, and if you have truly embraced API Gateway, you might have about 600 of them. You can immediately understand the scale of the problem that you're dealing with. You're not just looking at random APIs, but you're looking at an ecosystem that has hundreds of thousands of APIs. For an organization of your scale, enterprises, we see that number being somewhere around tens of thousands of APIs. This gives you the total surface area of your APIs that you want to secure and make discoverable.
The immediate challenges that come to mind, if you multiply these numbers, are significant. How do your developers actually discover these APIs today? How many Slack messages, meetings, or tickets does it take for you to find the right endpoint? Second, how often does it happen that you discover the same functionality being available across multiple endpoints? You might have one or two endpoints that do more or less the same thing. Third, how do you reliably know which one is to be sunset and which one is in active mode? Fourth, what happens when a new account rolls in? Say you have an acquisition that has been done and you have a new organization that has been onboarded with a new account. How do you even know if there is an overlap between the acquisition and your own organization?
Finally, who is specifically in charge of keeping all of this API landscape or the catalog that you have clean and up to date? As you think through these problems, you will realize that the fundamental issue that you're facing is API fragmentation. This API fragmentation creates several problems. The first one is that it will slow down your discovery. Slow discovery, as you know, will lead to poor onboarding mechanisms for your teams. They will take more time to get productive. It also will inhibit reuse. When your developers are on a digital treasure hunt trying to find the right endpoint and if they don't find it, they reinvent the wheel and rediscover functionality that already exists, which adds to the API sprawl again.
Thirdly, it actually hides risk. The API sprawl creates a security blind spot where you have large swaths of ungoverned APIs, resulting in a shadow IT organization almost. You cannot really secure what you can't see, which leaves you exposed from a compliance perspective.
The solution to this API sprawl is not to build more but to organize what you already have and catalog it in a very nice manner. Now, let's talk a little bit about the API excellence mindset. My goal with this slide is to give you a common framework for you to think through how you want to classify all of these APIs. So to capture the full value of your API investment, you need to start thinking about your APIs as products. Think of APIs as a long-term strategic asset that needs to be enhanced, maintained, and modified. It would be prudent for us to think of them as products that serve both your internal and external customers to achieve an outcome.
Amazon API Gateway Portals: A Platform Solution for Streamlined API Discovery and Management
Next, you need to start thinking about working backwards from your API consumers and not from your backends. You need to make sure that you're not walking through any one-way doors when you're designing your APIs. Finally, every API product needs to have a single-threaded owner who is responsible for the quality, success, operational excellence, usability, and adoption of the APIs. This will eliminate redundancy and maximize your returns on your API investment. So to solve all of these problems, we recently announced the launch of Amazon API Gateway Portals. Amazon API Gateway Portal is an AWS-native, fully managed developer portal that helps you manage API chaos and streamline discovery across your accounts. You can control documentation freshness, enable scoped access, and have this all cataloged while staying inside the AWS boundary without having to manage any additional infrastructure.
You can stand up a branded portal and this will give you access to all of your APIs. Developers can find and try those APIs. Security organizations will gain visibility across the organization without having to export all of these configurations, and platform teams will cut duplication and governance drift. So let's dive a little deeper into what the developer portal entails and what it enables you to do. First, you are able to create products using Amazon API Gateway Portals. When you create products, you can pick endpoints and you can pick a particular path, a particular stage, and add that into the abstraction that we call an API product.
Once you've done that, you can then move on to sharing these products. When you're sharing these products, if you have multiple accounts, you can create products in each of these accounts and share them over to the account where you are actually trying to build the portal. This will allow you to have a unified portal and provide a unified front for all of your APIs. Next, you can control your documentation freshness. From a documentation perspective, we allow you to get started very quickly, and we will pull in the documentation from your API Gateway runtime. If you're happy with that documentation, you can go ahead with that, or you can actually overwrite it and put in your own documentation there.
Finally, we allow you to configure the ability to try that API out from a consumer perspective. Once you've created this portal and these products, you can actually enable your developers to try the API out right from the portal so that they don't have to go back and forth over Slack messages. Now that you've created all of these API products, let's talk about the portal itself. The portal is going to house all of these products together. From a portal perspective, we first allow you to have scoped access. You can use Cognito user pools to restrict scope to this developer portal.
Second, you can choose between a default domain name or a custom domain name so that it aligns with the branding guidelines of your organization. Finally, we give you the ability to get portal-based metrics as to how often people are visiting the portal that you have created. The next thing that I want to talk about is once you've created the portal itself, the housing and casing that will hold all of your APIs, you can add all of your API products not only from the account that you are creating the portal on, but also from across other accounts from where the API products have been shared to you. This will allow you to present a unified portal.
If you choose, you can also have distinct portals for each of the accounts that you have, but you can also have a unified portal for your organization with this. You can also customize the look and feel and branding guidelines for your organization. You can put your logo on it and follow the color schemes for your organization, which will help you adhere to your organization's branding guidelines.
You can then generate a preview of your developer portal. This will allow you to check that everything is perfect from a look and feel perspective, from the products that you've created, and from the ability to try out the features or the APIs. Then you can finally publish the developer portal. To walk you through at a high level to summarize, Amazon API Gateway Portals allow you to go from API commit to API adoption in four simple steps.
You can continue to use your current documentation or edit the documentation and then create API products and add them to the developer portal. You can configure scoped access and customize the custom domain name feature on the developer portal. You can also control the branding on the developer portal. Finally, once you publicize the developer portal's URL, your API consumers, whether internal or external, can come and try out the APIs that you have hosted on that portal.
There are a couple of QR codes here which will lead you to the launch blog and the documentation for the developer portal. If you want to learn more about this feature, I'm happy to talk to you offline and walk you through more details of the feature that we have launched recently. Thank you so much, everyone. Please complete the survey at the end on your mobile apps. I'm happy to take questions offline. Thank you.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)