Hi Reader ππ½,
I hope you are alright and you're enjoying the summer.
Tobi & I are currently thinking hard about what comes next. In the past few months, we focused on publishing more content on our blog & social media. We want to have as much high-quality content covering AWS as possible. But we do see a lack of hands-on projects that can be used in the real world. We're not only talking about a simple API with a Lambda function. But about projects that are required if you work for a company. Setting up a landing zone, configuring the identity center (SSO), and setting up a proper development workflow with sandbox accounts. We feel like this is missing a lot. We'll probably focus on that in the near future π
Enough about our thoughts, let's dive right into today's topic: API Gateway.
Here is a one-pager about API Gateway.
β
AWS API Gateway is a fully-managed API from AWS. It is a crucial part of your serverless applications because it acts as the front door to the internet.
AWS API Gateway has a lot of different options and configuration opportunities. For example:
API Gateway is beginner-friendly as itβs easy to deploy your first API and there are no upfront or idling costs you need to fear.
AWS API Gateway comes in three different flavors, with very different feature sets and different pricing. A small wrap-up before going into details:
As said before, API Gateway is not just an HTTP mediator - itβs a feature-rich, high-value, and little error-prone front door to your applications ecosystem.
When working with REST or HTTP gateways, an API consists of programmable resources that can be mapped to specific HTTP methods and paths. These resources are connected to integration endpoints where requests are forwarded. Transformations can be applied to modify requests according to the backend's expectations, including validations. After receiving the response from the integration, response transformations can be applied before returning it to the client.
API Gateway provides powerful authorizer capabilities for authentication and authorization. Let's explore two key options:
By leveraging these authorizers, you can secure your APIs, protect routes and methods, and customize the authentication and authorization process to suit your specific requirements.
Weβve learned about the different API Gateway types, which leads us to two prominent use cases.
The typical web application is a client-server combination: a frontend, e.g. a web page or a mobile app. A backend server to communicate with the frontend.
On the serverless side, your backend is a construct of one or multiple Lambda functions that include your business logic. Exposing those functions to the internet is done via a REST or HTTP API Gateway that allows you to actively enforce rate-limiting, request validation, transformation, routing, authentication, and authorization without writing much or any code at all.
Many applications require real-time communication between the clients and the backend. If you look at messaging apps, you donβt want all your clients to actively poll for new messages every few seconds as it causes unnecessary server load and also causes a high latency between a message that has been sent and the actual delivery at the receiver.
With WebSockets API Gateway a client can open a connection to the gateway that is fully managed by the gateway itself. The only thing that needs to be actively implemented is how connection events are handled and what you want to do with those connections. A common pattern is to save the connection identifiers that are provided by the gateway to DynamoDB. Via a connection identifier, you can actively push messages to the corresponding client.
We hope you enjoyed this issue. Let us know what you think about this issue and our future plans with the AWS Fundamentals Community π―
β
Join our community of over 9,300 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.
AWS FOR THE REAL WORLD β±οΈ Reading time: 8 minutes π― Main Learning: Migrating from Edgio to CloudFront π Blog Post π» GitHub Repository Hey Reader ππ½After a busy week in Prague, both Tobi and I (Sandro) delivered our talks and we got quite some good feedback! We will share them in a separate newsletter soon.But this newsletter is all about accessing S3 within a VPC via Gateway endpoints vs. Internet routing. We know these networking issues are not the fanciest onces (looking at you AI) but...
Hey Reader ππ½ We've been talking a lot about how great SST's switch to Pulumi was, and many of you have asked us how to use plain Pulumi directly. So today, we're sharing our quick guide to Pulumi - a tool we're really excited about since it lets us build infrastructure with languages we already know and love. No more learning weird syntax - just TypeScript, Python, or whatever we're comfortable with! We spent the last few days playing with it, and here's what we've learned... AWS Community...
Newsletter Header AWS FOR THE REAL WORLD β±οΈ Reading time: 8 minutes π Main Learning: Migrating from Edgio to CloudFront βοΈ Blog Post π» GitHub Repository Hey Reader ππ½ this newsletter is about π₯ AI π€ We haven't talked too much about AI, Bedrock, MCPs, and agents yet - so we want to change that. Please let us know if this it interests you to build AI on AWS, or if you are much more interested on hands-on fundamentals services. Should we focus on AI Services? Yes, I want to learn to build...