DEV Community: S Uma Shankar Reddy

Amazon API Gateway for Serverless Applications

S Uma Shankar Reddy — Sat, 05 Sep 2026 16:05:13 +0000

Real-time message communication with WebSocket APIs

In a WebSocket API, the client and server can send messages to each other at any time. With a WebSocket connection, your backend servers can push data to connected users and devices, avoiding the need to implement complex polling mechanisms.

For example, you could build a serverless application using an API Gateway WebSocket API and Lambda function to send and receive messages to and from users in a chat room.

Architecture demonstrating bidirectional communication between users, API Gateway, and backend APIs.

In API Gateway, you can create a WebSocket API as a stateful frontend for an AWS service, such as Lambda or Amazon DynamoDB, or for an HTTP endpoint. The WebSocket API will then invoke your correct backend service based on the content of the messages it receives from client applications.

Benefits and use cases of WebSocket APIs

API Gateway WebSocket APIs are designed for bidirectional communication between your client and backend architecture. You can do this by using any WebSockets client such as a mobile app, chat app, AWS IOT device, or application dashboard.
Benefits and use cases of WebSocket APIs

When you connect the client to API Gateway, API Gateway will manage the persistence and state needed to connect it to your clients. Unlike a REST API, which receives and responds to requests, a WebSocket API supports two-way communication between your client applications and your backend.
WebSocket APIs are often used in real-time application use cases such as:

Chat applications

Streaming dashboards

Real-time alerts and notifications

Collaboration platforms

Multiplayer games

Financial trading platforms

By using WebSockets with API Gateway, your clients can send messages to a service and the services can independently send messages back to the clients. This bidirectional behavior creates more valuable interactions between your clients and services because the services can push data to clients without requiring clients to make an explicit request.
For WebSocket APIs, the API Gateway free tier currently includes one million messages (sent or received) and 750,000 connection minutes for up to 12 months.
Developing a WebSocket API in API Gateway

As you're developing your WebSocket API in API Gateway, there are a number of characteristics you need to choose for your API. These characteristics depend on your API's use case.

For example, you might want to only allow certain clients to call your API, or you might want it to be available to everyone. In addition, you might want an API call to invoke a Lambda function, make a database query, or call an application. All of these options will change the characteristics of the API as you design and deploy it.

Creating and configuring WebSocket APIs

To create a functional API, you must have at least one route, integration, and stage before deploying the API. The creation of APIs will be discussed in more depth in later lessons, but this overview walks through the creation of specifically a WebSocket API. Select each hotspot to learn a brief overview of what you need to create an WebSocket API.

API Gateway console displaying the Create a WebSocket API dashboard.

Using WebSocket routes

With WebSocket APIs in API Gateway, JSON messages can be routed to invoke a specific backend service based on message content. When a client sends a message over its WebSocket connection, this results in a route request to the WebSocket API. The request will be matched to the route with the corresponding route key in API Gateway.

There are three predefined routes that can be used with WebSocket APIs: $connect, $disconnect, and $default. In addition to the predefined routes, you can also create custom routes. Select each hotspot to learn about the predefined routes and custom routes API Gateway WebSocket APIs offer.

After configuring the WebSocket API routes, whether predefined or custom, the next step is to attach integrations to each route.

WebSocket API integrations

After setting up an API route, you must integrate it with an endpoint in the backend. A backend endpoint is also referred to as an integration endpoint and can be a Lambda function, an HTTP endpoint, or an AWS service action. The API integration has an integration request and an integration response option.
After configuring the WebSocket API routes, whether predefined or custom, the next step is to attach integrations to each route.

WebSocket API integrations

Integration request

To set up one-way communication for your WebSocket, you will attach an integration request to your route. Setting up an integration request involves the following:

Choosing a route key to integrate to the backend. As shown earlier in this lesson, this can include a predefined route key for $connect, $disconnect, $default, or a custom route.

Specifying the backend endpoint to invoke for each of the routes you choose, such as an AWS service or HTTP endpoint.

Configuring how to transform the route request data, if necessary, into integration request data by specifying one or more request templates.

Take note of the integration types listed for WebSocket APIs integration requests. Each of these will be discussed in further detail in a later lesson.

Integration response

WebSocket routes can be configured for two-way or one-way communication. If a route has a route response, it is configured for two-way communication. Otherwise, it is configured for one-way communication.

When a route is configured for two-way communication, an integration response helps you to configure transformations on the returned message payload, similar to integration responses for REST APIs.

If a route is configured for one-way communication then, regardless of any integration response configuration, no response will be returned over the WebSocket channel after the message is processed.

Designing REST APIs
The regional endpoint is designed to reduce latency when calls are made from the same AWS Region as the API. In this model, API Gateway does not deploy its own CloudFront distribution in front of your API. Instead, traffic destined for your API will be directed straight at the API endpoint in the Region where you’ve deployed it.

This endpoint type gives you lower latency for applications that are invoking your API from within the same Region (for example, an API that is going to be accessed from EC2 instances within the same Region).

The regional endpoint provides you with the flexibility to deploy your own CloudFront distribution or content delivery network (CDN) in front of API Gateway and control that distribution using your own settings for customized scenarios. An example of this might be to design for disaster recovery scenarios or implement load balancing in a very customized way.

Edge-optimized endpoint
The edge-optimized endpoint is designed to help you reduce client latency from anywhere on the internet. If you choose an edge-optimized endpoint, API Gateway will automatically configure a fully managed CloudFront distribution to provide lower latency access to your API.

This endpoint-type setup reduces your first hit latency for your API. An additional benefit of using a managed CloudFront distribution is that you don’t have to pay for or manage a CDN separately from API Gateway.

Private endpoint
The private endpoint is designed to expose APIs only inside your selected Amazon Virtual Private Cloud (Amazon VPC). This endpoint type is still managed by API Gateway, but requests are only routable and can only originate from within a single virtual private cloud (VPC) that you control.

This endpoint type is designed for applications that have very secure workloads, such as healthcare or financial data that cannot be exposed publicly on the internet. There are no data transfer-out charges for private APIs. However, AWS PrivateLink charges apply when using private APIs in API Gateway.

Building and Deploying APIs with Amazon API Gateway

1. Anatomy of the API Call

When deploying an API in Amazon API Gateway, a base invoke URL is generated based on your deployment stage.

https://{restapi_id}.execute-api.{region}.amazonaws.com/{stage_name}/{resource_path}

{restapi_id}: Unique identifier generated by AWS upon API creation.
{region}: The AWS Region where the API is hosted.
{stage_name}: The deployed environment/snapshot (e.g., dev, prod).
{resource_path}: The specific resource endpoint exposed to callers.

Custom Domain Names
To make URLs user-friendly and consistent across environments, attach a custom domain name (e.g., api.example.com). API Gateway integrates directly with AWS Certificate Manager (ACM) to manage SSL/TLS certificates.

2. Steps to Build an API in the Console

Choose API Type: Select REST API, HTTP API, or WebSocket API based on workload requirements.
Create Resources: Form a hierarchical tree of addressable endpoints starting at root (/). Use {param} syntax for path parameters.
Configure Proxy Integration (Optional): Setting up a greedy path parameter {proxy+} automatically provisions an ANY HTTP method to route all sub-paths and verbs to a single backend (HTTP endpoint or AWS Lambda).
Create Methods & Select Integration Type: Define standard HTTP verbs (GET, POST, PUT, DELETE, etc.) and specify how requests map to backends:
Lambda Function: Direct invocation of serverless compute.
HTTP Endpoint: Proxying to external or legacy HTTP/HTTPS APIs.
AWS Service: Direct integration with services like Amazon S3, DynamoDB, or Kinesis without intermediary compute.
Mock: Generates API responses without sending traffic to a backend (useful for testing or CORS handling).
VPC Link: Direct access to private resources inside a VPC (e.g., Application Load Balancers or Network Load Balancers).
Test Methods: Execute method calls directly within the console to view latency, response bodies, and simulated request/response state changes.

3. API Stages & Version Management

A stage is a named reference to a deployment representing a point-in-time snapshot of the API.

Stage Configuration: Caching, throttling thresholds, and usage plans are applied per stage.
Stage Variables: Environment-specific key-value pairs referenced via $stageVariables.variableName to dynamically point integration endpoints or Lambda function aliases at runtime.
Canary Deployments: Route a controlled percentage of traffic (e.g., 10%) to a new API version within the same stage to validate changes before promoting them.

4. Deployment Best Practices

Lambda Aliases + API Stages: Pair API Gateway stages with Lambda version aliases via stage variables to decouple deployments and prevent hardcoded ARNs.
Canary Releases: Safely test API revisions with real user traffic without spinning up new domains.
Infrastructure as Code (IaC): Use AWS SAM (Serverless Application Model) or OpenAPI/Swagger specifications to automate consistent, repeatable deployments across environments.

Knowledge Check: Correct Answers

The two true statements from the check are:

[x] If you choose to configure resource as a proxy, it will automatically create a special HTTP method called ANY.
[x] Integration options include Lambda Function, HTTP Endpoint, AWS Service, Mock, and VPC Link.

(Incorrect: API Gateway URLs **can* be customized with custom domain names. Console testing performs actual executions that modify backend state, even though log output inside the console is simulated.)*
Managing API Access
Managing access to APIs

The next important step for you to consider after you have successfully designed and deployed your API is how you will manage access and authorization for the API. API Gateway provides you with multiple, customizable options for:

Authorizing an entity to access your APIs
Providing more granular control
Controlling the amount of access through throttling
Before discussing these different use cases, you need to understand the different options for authenticating and authorizing your APIs in API Gateway.

Authorization and authentication comparison

Each of these, authorization and authentication, have advantages that should be matched to both your application needs and your organizational standards. This table shows a comparison of authorization and authentication options and features that they are compatible with.

Pay based on your monthly active users
Authorization for API Gateway

As shown in the comparison table, there are three main ways to authorize API calls to your API Gateway endpoints:

1
Use IAM and Signature version 4 (also known as Sig v4) to authenticate and authorize entities to access your APIs.

2
Use Lambda Authorizers, which you can use to support bearer token authentication strategies such as OAuth or SAML.

3
Use Amazon Cognito with user pools.

Each of the authorizing options has advantages that should be matched to your application needs and organizational standards. For example, you need to consider who consumes the API. If it’s external developers, you probably want to consider using Lambda Authorizers or Cognito.

Authorizing with IAM

If you have an internal service or a restricted number of customers, IAM is a great choice for authorization, especially for applications that use IAM to interact with other AWS services using IAM roles. To learn more about the signing process, select each hotspot.

API Gateway architecture illustrating Sig v4 credentials used for IAM authorization.

Lambda Authorizers

You also need to consider what you already have in place that should be used. If you are using an OAuth strategy as an organization, you may want to consider Lambda Authorizer. To learn more about Lambda Authorizers, select each hotspot.

API Gateway architecture highlighting a Lambda function performing authorization and an optional Policy cache.

To make it easy to get started with this method, you can choose the API Gateway Lambda Authorizer blueprint when creating your authorizer function from the Lambda console.

Lambda function console creation using API Gateway Lambda Authorizer blueprint to create the Lambda Authorizer.
To summarize, a Lambda Authorizer is simply a Lambda function that you can write to perform any custom authorization that you need. There are two types of Lambda Authorizers you should be aware of: Token and Request.

Lambda Authorizer token types

For token-type Lambda Authorizers, API Gateway passes the source token to the Lambda function as a JSON input. Based on the value of this token, your Lambda function will determine whether to allow the request.

To learn more about Lambda Authorizer tokens, select each hotspot.

Diagram highlighting the flow of token information through HTTP header to Lambda Authorizer.

Lambda Authorizer request types

Request-type Lambda Authorizers are useful if you need more information about the request itself before authorizing it.

To learn more about Lambda Authorizer requests, select each hotspot.

Diagram highlighting the flow of header information in request-type Lambda Authorizer.

Cognito Authorizers

As an alternative to using IAM or Lambda authorizers, you can use Amazon Cognito and a Cognito User Pool to control access to your APIs.

To learn more about Cognito Authorizers, select each hotspot.

API Gateway architecture highlighting the use of Cognito and OIDC tokens for authorization.

In the following section, match the authorizer in the column on the left with the correct description on the right.

If you're using the keyboard to navigate, TAB to the term on the left, press the SPACE BAR, then use the right arrow key to move to the column on the right. Press the SPACE BAR to match, then repeat for the next item. Press ENTER to submit.

Lambda Authorizer
Selectable item

Cognito Authorizer
Selectable item

IAM Authorizer
Selectable item

All requests are required to be signed using AWS Sig v4.
Selectable item

Amazon API Gateway supplies an authorization token to a Lambda function.
Selectable item

After a user is authenticated against the user pool, they obtain an OIDC token.
Selectable item
SUBMIT

Throttling and usage plans

Beyond just allowing or denying access to your APIs, API Gateway also helps you manage the volume of API calls that are processed through your API endpoint.

With API Gateway, you can set throttle and quota limits on your API consumers. This can useful for things such as preventing one consumer from using all of your backend system’s capacity or to ensure that your downstream systems can manage the number of requests you send through.

Keys on a key ring
API keys

With API Gateway, you can create and distribute API keys to your customers, which can be used to identify the consumer and apply desired usage and throttle limits to their requests. Customers include the API key through x-API-key header in requests.

Usage plans

You can use API keys with usage plans to set up some very specific plans that make sense for your use case. For example, you can perform API key throttling based on a rate and a burst per API key. API key usage can also be used to meter daily, weekly, and monthly usage.

You can set throttle and quota limits based on API keys through the usage plans feature. You can set up usage plans for:

API Key Throttling per second and burst
API Key Quota by day, week, or month
API Key Usage by daily usage records
Example of usage plans based on types of consumers

Using the information on API keys and usage plans, review this throttling example where you might throttle with usage plans for specific types of consumers.

To learn more, select each hotspot.

Diagram showing traffic from mobile apps, web sites, and services flowing to API Gateway. Mobile apps and services have a throttling limit called out.

With usage plans, you can create both the throttle rate limit and apply a daily quota.

Token bucket algorithm

Leaky bucket illustration highlighting flow of requests for throttling.
Burst: Maximum size of bucket
Rate: Number of tokens (requests) added to bucket
The method by which the limits are measured and throttled is based on the token bucket algorithm, which is a widely used algorithm for checking that network traffic conforms to set limits. A token, in this case, counts as a request and the burst is the maximum bucket size.

Requests that come into the bucket are fulfilled at a steady rate. If the rate at which the bucket is being filled causes the bucket to fill up and exceed the burst value, a 429 Too Many Requests error would be returned.

API Gateway sets a limit on a steady-state rate and a burst of request submissions per account and per Region. At the account level, by default, API Gateway limits the steady-state request rate to 10,000 requests per second. It limits the burst to 5,000 requests across all APIs within an AWS account. However, as discussed earlier, you can use usage plans to manage limits at a more granular level.

Throttling settings hierarchy

The type and level of throttling applied to a request is dependent on all of the limits involved and are applied in this order:

Per-client, per-method throttling limits that you set for an API stage in a usage plan
Per-client throttling limits that you set in a usage plan
Default per-method limits and individual per-method limits that you set in API stage settings
The account level limit
Which of the following statements are true? (Select THREE.) Select the correct answers and choose SUBMIT.

If you're using the keyboard to navigate, press TAB to navigate to the correct answer and press the SPACE BAR to select. Repeat these steps until all correct responses are checked, then press ENTER to submit.

You can throttle APIs with usage plans.

You cannot override the default stage level throttling.

The method by which limits are measured and throttled is based on the token bucket algorithm.

All consumers of an API must share the same quotas.

You can override default stage level throttling.

You cannot apply daily quotas to APIs with usage plans.

SUBMIT

IAM permissions

You learned how IAM policies are used as part of the authorization models as an earlier part of this lesson. Now, it's time to take a look at the types of permission controls you can implement using IAM policies. There are two types of IAM permissions for APIs:

Telephone
Multipurpose pocket knife tool
When it comes to granting access to your APIs, you need to think about two types of permissions:

1
Who can invoke the API: To call a deployed API, or refresh the API caching, the caller needs the execute-api permission.

2
Who can manage the API: To create, deploy, and manage an API in API Gateway, the API developer needs the apigateway permission.

Invoke permissions

For the execute-api permission, you need to create IAM policies that permit a specified API caller to invoke the desired API method. To apply this IAM policy on the API method, you need to configure the API method to use an authorization type of AWS_IAM.

This example grants "Allow" Invoke permissions on the POST method of mydemoresource API.

Screenshot of policy showing invoke permission.
When you do this, API Gateway will expect an IAM Sig v4 request for any requests that come to that API method. After you have associated this authorization type with your API method, you can then allow users with this permission to invoke your API. This could be an IAM user who represents an API caller; it could be an IAM group containing a set of IAM users; or it could be an IAM role assumed by a user, an EC2 instance, or an application running inside AWS.

For the execute-api permission, create IAM policies that permit a specified API caller to invoke the desired API method.

Manage permissions

To allow an API developer to create and manage an API in API Gateway, you need IAM permission policies that allow a specified API developer to create, update, deploy, view, or delete required API entities. To do that, create a policy using the apigateway:HTTP_VERB format, associated with the specific resource using the verb that you want to permit or deny in the policy.

Screenshot of policy showing apigateway permission.
In this example, the user with this policy is limited to perform the GET method requests on one of the API resources, but is permitted to take all of the actions (*) on the second resource.

To learn more about managing permission examples, see Amazon API Gateway identity-based policy examples(opens in a new tab).

Resource policies

Resource policies help you to further refine access for your APIs. While an IAM policy is used to grant permission to a user, group, or role, you can also apply policies directly on API Gateway using a resource policy. A resource policy is a JSON policy document that you attach to an API to limit access by users from a specified account, IP address range, VPC, or VPC endpoint. You can make this as granular as you need, and resource policies can be used in coordination with IAM policies to restrict access.

For example, you could use resource policies to provide access to another AWS account, or to limit access to your API from a particular set of IP address ranges. You can also use resource policies to grant access to specific VPCs or VPC endpoints.

For a full list of the conditions you can use within your resource policies, see Controlling access to an API with API Gateway resource policies(opens in a new tab) in the Amazon API Gateway Developer Guide.

Now that you understand the basics of resource policies for API Gateway, these examples show how you can limit access for users, IP addresses, and by VPC.

Screenshot of a resource policy showing permission by account for specific actions.
Limiting access by user example

In this example, the resource policy allows a user from another AWS account (account-id:user/George) to perform GET requests on the pets resource of our API.

Limiting by IP address example

This resource policy denies any user with a source IP address in one of two specified ranges from accessing the API.

This is done by specifying an effect of DENY and an IpAddress condition with an array of source IP addresses.

Screenshot of a resource policy that denies users who aren't within a given IP address range.
Screenshot of a resource policy that denies anyone coming from a specific VPC ID.
Limiting by VPC example

This resource policy denies anyone (indicated by the principal = *) who is NOT coming from the VPC specified as the sourceVpc within the Condition.

Since the Principal in the policy is set to "*", other authorization types can be used alongside the resource policy. However, if the Principal is set to "AWS," authorization will fail for all resources not secured with AWS_IAM authorization, including unsecured resources.

Resource policies and authentication methods

Resource policy and authentication methods work together to grant access to your APIs. As illustrated below, methods for securing your APIs work in aggregate. To learn more, expand each of the following four categories.

API Gateway resource policy only

Lambda Authorizer and resource policy

IAM authentication and resource policy

Cognito authentication and resource policy
To see flow charts and tables to help you sort through your specific use case, see How API Gateway resource policies affect authorization workflow(opens in a new tab) in the Amazon API Gateway Developer Guide.

Which of the following statements are true? (Select THREE.) Select the correct answers and choose SUBMIT.

You must choose between using resource policies or configuring an authorizer to secure an API.

You can grant permission to invoke an API with execute-api.

You can grant permission to manage an API with
apigateway.

Resource policies can restrict access by account.

You can grant permission to manage an API with
execute-api.
CloudWatch Metrics for API Gateway

After your APIs are deployed, you can use CloudWatch Metrics to monitor performance of deployed APIs. API Gateway has seven default metrics out of the box:

•
Count: Total number of API requests in a period

•
Latency: Time between when API Gateway receives a request from a client and when it returns a response to the client; this includes the integration latency and other API Gateway overhead

•
IntegrationLatency: Time between when API Gateway relays a request to the backend and when it receives a response from the backend

•
4xxError: Client-side errors captured in a specified period

•
5xxError: Server-side errors captured in a specified period

•
CacheHitCount: Number of requests served from the API cache in a given period

•
CacheMissCount: Number of requests served from the backend in a given period, when API caching is turned on

With these metrics, you can monitor details such as the following:

•
How often your APIs are being called

•
The number of invocations to your API

•
The latency of the API responses

•
If there are any errors, and if so, whether they are 400 errors or 500 errors

•
Whether your cache is being hit or how many times the backend needed to be called while caching was enabled

In addition, consider the value of turning on detailed metrics so you can see these metrics at the method level. This is where you would be able to see details about gets, posts, deletes, and so on.

You can turn on detailed metrics from the Stage settings.

Calculating API Gateway overhead

Two key metrics that are used to calculate the API Gateway overhead of deployed APIs are the Latency and IntegrationLatency CloudWatch Metrics.

1
The latency metric gives you details about how long it takes for a full round-trip response, from the second your customer invokes your API to when your API responds with the results. This is a full round-trip duration of an API request through API Gateway.

2
Integration latency is how long it takes for API Gateway to make the invocation to your backend and receive the response.

The difference between these two metrics gives you your API Gateway overhead. Together, these metrics can help you fine-tune your applications and see where the bottlenecks are.

CloudWatch Logs for API Gateway

In addition to CloudWatch Metrics, you can also learn a lot about how your APIs are performing from CloudWatch Logs. API Gateway has two types of CloudWatch logs built in. To learn about a category, choose the appropriate tab.

Execution Logging

Access Logging
The first type is execution logging, which logs what’s happening on the roundtrip of a request. You can see all the details from when the request was made, the other request parameters, everything that happened between the requests, and what happened when API Gateway returned the results to the client that’s calling the service.

Execution logs can be useful to troubleshoot APIs, but can result in logging sensitive data. Because of this, it is recommended you don't enable Log full requests/responses data for production APIs. In addition, there is a cost component associated with logging your APIs.

API Gateway console page showing where you can implement execution logging from the stages page.
Access logging is fully customizable using JSON formatting. If you need to, you can publish them to a third-party resource to help you analyze them.

Troubleshooting Exercise – Execution Logs
To experience these monitoring and troubleshooting tools in action, this scenario outlines a situation where your customers are reporting errors while trying to use the FAQ API. You bring up the dashboard for the API being called, and notice a spike in 4xx errors around the time of the reports. Continue through the steps to learn more about the errors your customers are experiencing, then diagnose the root cause of this issue.

Lambda dashboard showing some 400 errors.
Step 1
Review the metric in CloudWatch
Hover over the data for more details including the time associated with the error spike. Choose Logs for the details of logs for that time frame.

Screenshot of CloudWatch metric for 400 errors with mouse hovering over spike in graph to get date and time details.
Step 2
Open the execution log
Pick the execution log associated with the API. The log name has the API ID and the stage name in its name. In this example, it's the last one on the list.

Screenshot of list of logs available highlighting the one named to match the API.
Step 3
Look for errors in the log
There are 2 error lines: one that mentions throttle limit exceeded and one that indicates a 429 error.

Screenshot of the execution log showing error that key throttle limit was exceeded on httpMethod GET Limit:1 Burst:5.
Step 4
Check potential throttling settings
Because the error indicated throttling, the next step would be to check how throttling is applied to this API and method. Review the next four slides to decide which setting is generating the error.

Setting 1
Usage plan: API Key Throttling
Screenshot of API GET method showing that there is no API key in use for this method.
Setting 2
Method throttling at stage level
Screenshot of stage editor for method showing choice to override for method and throttling settings of rate = 1 burst = 5.
Setting 3
Stage level defaults
Screenshot of stage editor for this API showing the default method throttling set for a rate of 50 and a burst of 75.
Setting 4
Account Limits
Screenshot of Account Settings text that indicates that your current account level throttling rate is 1000 requests per second with a burst of 5,000 requests.
Which of these appears to be the root cause in the troubleshooting scenario? Select the correct answer and choose SUBMIT.

If you're using the keyboard to navigate, press TAB to navigate to the correct answer, press the SPACE BAR to select, and press ENTER to submit.

API Key throttling on the method

Throttling on the method at the stage level

Default throttling limits on the stage

Account level limits

SUBMIT

Monitoring with X-Ray and CloudTrail

There are two AWS tools you should understand to analyze your API use and performance: AWS X-Ray and AWS CloudTrail.

The AWS X-Ray service icon.
(opens in a new tab)

AWS X-Ray

You can use X-Ray to trace and analyze user requests as they travel through your Amazon API Gateway APIs to the underlying services. With X-Ray, you can understand how your application is performing to identify and troubleshoot the root cause of performance issues and errors. X-Ray gives you an end-to-end view of an entire request, so you can analyze latencies and errors in your APIs and their backend services. You can also configure sampling rules to tell X-Ray which requests to record, and at what sampling rates, according to criteria that you specify.

To summarize, with X-Ray, you can trace and analyze requests as they travel through your APIs to services:

Analyze latencies and debug errors in your APIs and their backend services.
Configure sampling rules to focus on specific requests.
AWS CloudTrail

The second service, CloudTrail, captures all API calls for API Gateway as events, including calls from the API Gateway console and from code calls to your API Gateway APIs.

Using the information collected by CloudTrail, you can determine the request that was made to API Gateway, the IP address from which the request was made, who made the request, when it was made, and additional details. You can view the most recent events in the CloudTrail console in Event history.

To summarize, CloudTrail captures all API calls for API Gateway as events.

IP address, requester, and time of request are included.
Event history can be reviewed.
Create a trail to send events to an Amazon Simple Storage Service (Amazon S3) bucket.
The AWS CloudTrail service icon.
(opens in a new tab)

X-Ray trace examples

These examples reflect an AWS X-Ray trace for a GET method request for the FAQ-API on the Demo stage. The GET method for this API is configured with a proxy integration to Lambda. When the GET request is received, Lambda invokes the FAQ Lambda function.

This first example demonstrates API Gateway Latency metrics for a Lambda cold start. To learn more about the sections of the X-Ray trace, select each hotspot.

Screenshot of X-Ray trace for API call to Lambda function behind API Gateway.

Diving deeper into the example, this image shows a deeper look at the Lambda portion of this trace. To learn more about this example, choose the right arrow to move to the next image and the left arrow to move to the previous image. To use the zoom feature, choose the zoom image button.

1 of 3

As shown, the entire duration for the Lambda cold start is 232 ms, with a billable duration of 26 ms.

Next, this example demonstrates the API Gateway Latency metrics for a Lambda warm start. To learn more about the sections of the X-Ray trace, select each hotspot.

X-Ray trace showing API Gateway integrated with Lambda function with a warm start.

1 of 3

As shown, the entire duration for the Lambda warm start is 18 ms, with a billable duration of 1 ms. Compared to the metrics from the Lambda cold start, the warm start steeply decreases the duration that the Lambda function must run.

Troubleshooting Exercise – Access Logs and X-Ray
To experience these monitoring and troubleshooting tools in action, this scenario outlines a situation where a single customer reports getting an access denied error trying to call the API between 9:45 and 10 am. The IP address of the reporter was 207.172.87.12. Continue through the steps to look at two ways to troubleshoot this report.

Step 1
Review errors with access logs
Check the name of the CloudWatch Group for access logging on this API stage.

Screenshot of setting up access logging on the API stage.
Step 2
Open the access log in CloudWatch
Select the access log for this API stage.

Screenshot of selecting the access log from within CloudWatch.
Step 3
Select a log event for the time frame
There are log events for 9:48 - 9:52, so let’s review the detail on one of those.

Screenshot of Select log events for the time period.
Step 4
Review errors
In the details of this log event, you can see a successful connection (200 status) from one IP address but a 403 error for the attempt to access from 207.172.87.12.

Screenshot showing a 403 error associated with IP address 207.172.187.12.
Step 5
Review errors with X-Ray
Alternatively, you could look at the X-Ray trace for this event. Open X-Ray, select Traces, and set the Group by to ClientIP.

Screenshot of selecting Traces and setting the Group by to ClientIP.
Step 6
Select Trace
Select one of the available traces from the list.

Screenshot of selecting an available trace from the list.
Step 7
Review error reported in trace
You can quickly see there was an error on this request. If you hover over the error icon, you can see explicit details indicating that the user is not authorized to perform execute-api:invoke on the resource due to an explicit deny.

Screenshot of error indicating that the user is not authorized to perform execute-api:invoke on the resource due to an explicit deny.
What might be the cause?
Consider a few configuration options to determine the root cause of this permission error.

Option 1
Authorization settings
Screenshot of Authorization settings showing no authorization method is selected.
Option 2
Resource policy
Screenshot of Resource Policy that includes the IP address in question with explicit deny.
What appears to be the root cause in the troubleshooting scenario? Select the correct answer and choose SUBMIT.

If you're using the keyboard to navigate, press TAB to navigate to the correct answer, press the SPACE BAR to select, and press ENTER to submit.

The user lacks the IAM policy required.

Lambda Authorizer requires a token that has not been provided.

The resource policy associated with this API prevents access.

Data Mapping and Request Validation in API Gateway

API Gateway allows you to validate incoming data, transform payloads, and standardize error structures before requests ever hit your backend compute or services.

1. Data Transformations with Mapping Templates

When client request schemas and backend integration interfaces differ (e.g., a client sending/expecting JSON while a legacy SOAP backend requires XML), API Gateway handles the transformation using Velocity Template Language (VTL) mapping templates.

Integration Request Mapping: Transforms the client’s request payload, query parameters, or headers before passing them to the backend integration.
Integration Response Mapping: Transforms the backend response before returning it as the final Method Response to the client.

Key VTL Variables

Variable	Core Utility
`$input`	Accesses request data via methods like `$input.body`, `$input.json('$.path')`, `$input.params()`, and `$input.path('$.element')`.
`$stageVariables`	Retrieves stage-specific environment variables (e.g., `$stageVariables.endpointUrl`).
`$util`	Provides string and encoding utilities: `escapeJavaScript()`, `parseJson()`, `urlEncode()`, `urlDecode()`, `base64Encode()`, and `base64Decode()`.

2. Offloading Request Validation

Performing basic structural checks at the gateway layer prevents unnecessary downstream invocations (saving compute costs and reducing backend load).

Validation Checks:
Parameters: Verifies that required headers, query string parameters, or path variables exist and are non-empty.
Body Models: Uses JSON Schema Draft 4 definitions to validate the payload structure, data types, required fields, and allowed enum values (e.g., enforcing make must be "Tesla" or "Hyundai").
Early Rejection: If validation fails, API Gateway drops the call and returns an immediate 400 Bad Request without hitting downstream resources.

3. Customizing Gateway Responses

When a request is blocked or fails at the perimeter (e.g., invalid auth, throttled request, validation failure), API Gateway generates a Gateway Response directly.

You can customize Gateway Responses to adhere to organizational API standards:

Modify the HTTP status code (e.g., converting a raw 403 to a standardized response).
Inject CORS or custom security headers.
Redefine the error payload body structure (JSON/XML) for standard error types like DEFAULT_4XX, DEFAULT_5XX, RESOURCE_NOT_FOUND, or UNAUTHORIZED.

Day 4: AWS Lambda Foundations

S Uma Shankar Reddy — Sat, 22 Aug 2026 05:15:55 +0000

To understand event driven architectures like AWS Lambda, you need to understand the events themselves. This section dives in to how events initiate functions to invoke the code within.

Invocation models for running Lambda functions

Event sources can invoke a Lambda function in three general patterns. These patterns are called invocation models. Each invocation model is unique and addresses a different application and developer needs. The invocation model you use for your Lambda function often depends on the event source you are using. It's important to understand how each invocation model initializes functions and handles errors and retries.

To learn more about the different invocation models, select each tab.

Synchronous invocation

When you invoke a function synchronously, Lambda runs the function and waits for a response. When the function completes, Lambda returns the response from the function's code with additional data, such as the version of the function that was invoked. Synchronous events expect an immediate response from the function invocation.

With this model, there are no built-in retries. You must manage your retry strategy within your application code. Lambda sends the events directly to the function and sends the function response directly back to the invoker.

The following AWS services invoke Lambda synchronously:

Amazon API Gateway
Amazon Cognito
AWS CloudFormation
Amazon Alexa
Amazon Lex
Amazon CloudFront

invoking Lambda synchronously: follow developer guide here https://docs.aws.amazon.com/lambda/latest/dg/invocation-sync.html

Asynchronous invocation:
When you invoke a function asynchronously, events are queued and the requestor doesn't wait for the function to complete. This model is appropriate when the client doesn't need an immediate response.

With the asynchronous model, you can make use of destinations. Use destinations to send records of asynchronous invocations to other services. (Select the Destinations tab for more information.)

The following AWS services invoke Lambda asynchronously:

Amazon SNS
Amazon S3
Amazon EventBridge
invoking Lambda asynchronously,follow AWS Lambda Developer Guide
https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html

A destination can send records of asynchronous invocations to other services. You can configure separate destinations for events that fail processing and for events that process successfully. You can configure destinations on a function, a version, or an alias, similarly to how you can configure error handling settings. With destinations, you can address errors and successes without needing to write more code.
configure destination for asynchronous invocation:
https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-destinations
The following diagram shows a function that is processing asynchronous invocations. When the function returns a success response or exits without producing an error, Lambda sends a record of the invocation to an EventBridge event bus. When an event fails all processing attempts, Lambda sends an invocation record to an Amazon Simple Queue Service (Amazon SQS) queue.

Polling invocation:
This invocation model is designed to integrate with AWS streaming and queuing based services with no code or server management. Lambda will poll (or watch) these services, retrieve any matching events, and invoke your functions. This invocation model supports the following services:
Amazon Kinesis
Amazon SQS
Amazon DynamoDB Streams
With this type of integration, AWS will manage the poller on your behalf and perform synchronous invocations of your function.
The configuration of services as event triggers is known as event source mapping. This process occurs when you configure event sources to launch your Lambda functions and then grant theses sources IAM permissions to access the Lambda function.
Lambda reads events from the following services:
Amazon DynamoDB
Amazon Kinesis
Amazon MQ
Amazon Managed Streaming for Apache Kafka (MSK)
self-managed Apache Kafka
Amazon SQS
https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html

Understanding AWS Lambda Permissions: Execution Roles vs. Resource-Based Policies
When building serverless applications, securing your AWS Lambda functions requires a two-sided approach. Because Lambda is deeply integrated with AWS Identity and Access Management (IAM), you have to explicitly define both who can invoke the function (inbound) and what the function can do once it is running (outbound).

To configure this properly, you will use two distinct types of IAM policies.

The Execution Role (Outbound Permissions) The execution role dictates what your Lambda function is allowed to do within your AWS environment. Lambda assumes this role whenever the function is invoked.

Actionable Permissions: The IAM policy attached to this role defines exactly which AWS services the function can interact with (for example, writing to a DynamoDB table or reading from an S3 bucket).

The Trust Policy: The role must include a trust policy granting the Lambda service permission to AssumeRole. This is what allows AWS to act on your behalf.

Least Privilege: Always start with the most restrictive permissions and only add what is strictly necessary. You can use IAM Access Analyzer to review your AWS CloudTrail logs and automatically generate a policy template containing only the permissions your function actually used.

Resource-Based Policies (Inbound Permissions) While the execution role handles what the function does, the resource-based policy (also called a function policy) determines which principals are allowed to trigger it.

Defining the Principal: A principal can be an IAM user, an IAM role, another AWS service (like Amazon S3 or API Gateway), or a completely different AWS account.

Cross-Account Access: Resource policies are the easiest way to grant cross-account access. For example, if a Production S3 bucket needs to invoke a Lambda function in a Dev account, you simply add a resource-based policy to the Dev function allowing that specific S3 service to invoke it.

Size Limits: Resource policies have a size limit. If you need to grant invocation access to dozens of different accounts, you might hit this limit and need to use cross-account IAM roles instead.

Accessing Resources in a VPC
If your function needs to access isolated resources inside a Virtual Private Cloud (VPC), it requires additional configuration (like subnet and security group IDs). Crucially, your execution role will need the AWSLambdaVPCAccessExecutionRole managed policy. This gives Lambda the permissions to create, describe, and delete Elastic Network Interfaces (ENIs).

Additionally, you can use interface VPC endpoints (powered by AWS PrivateLink) to establish a private connection between your VPC and Lambda. This ensures that traffic between your VPC and Lambda APIs never traverses the public internet, completely bypassing the need for an internet gateway or NAT device.

Tip for Easier Management: Managing these policies manually can get tedious as your application grows. Tools like the AWS Serverless Application Model (AWS SAM) simplify this by allowing you to define policies, inline documents, or templates directly alongside your infrastructure code, automatically scoping permissions to the resources used by your application.

title: "Authoring AWS Lambda Functions: Design Patterns, Best Practices, and Deployment"
published: false
description: "Learn the best practices for writing AWS Lambda function code, design patterns, and deployment strategies."

tags: aws, serverless, lambda, programming

AWS Lambda enables developers to run code without provisioning or managing servers. While the serverless model abstracts infrastructure concerns, authoring efficient, maintainable, and scalable Lambda functions requires a solid grasp of Lambda's programming model, architectural best practices, and automated deployment tooling.

1. The AWS Lambda Programming Model

Lambda is designed to let you bring your own code and work with familiar development tools. Rather than rewriting core logic to fit a proprietary paradigm, you make minimal adjustments to adapt your code to Lambda’s event-driven model.

Supported Languages & Environments

Lambda natively supports major runtimes:

Node.js
Python
Java
Go
C# / .NET
Ruby
PowerShell
Custom Runtimes (via the Lambda Runtime API)

AWS provides plugins and toolkits for popular IDEs, including Visual Studio Code, IntelliJ, Eclipse, and PyCharm.

2. Anatomy of a Lambda Function: The Handler Method

The handler method is the entry point that AWS Lambda executes when your function is invoked. When the handler exits or returns a response, the execution completes, and the container becomes available to process subsequent events.

def lambda_handler(event, context):
    # Process event and execute business logic
    return {
        'statusCode': 200,
        'body': 'Success'
    }

Configuring Your Lambda Functions:
When building and testing serverless applications, function performance and cost efficiency depend heavily on three core configuration settings: Memory, Timeout, and Concurrency.

Configuring these settings requires testing your functions against real-world scenarios and peak traffic. Monitoring and tuning these values ensures both cost optimization and a predictable customer experience.

1. Memory Allocation: The Compute Lever

In AWS Lambda, memory is not just RAM—it is the master dial for all compute resources.

Allocation Limits: You can allocate between 128 MB and 10,240 MB (10 GB) to a single function (in 1-MB increments).
Proportional Scaling: Lambda allocates CPU power, network bandwidth, and disk I/O linearly in proportion to the amount of configured memory.
Multi-threading: At 1,769 MB of memory, a function is allocated the equivalent of one full vCPU. Allocating above this threshold provides multiple vCPUs, enabling multi-threaded execution.
Timeout: Setting Guardrails The timeout value defines the maximum duration a function can execute before Lambda forcibly terminates it.

Maximum Timeout: 900 seconds (15 minutes) per single invocation.

Fail Fast Pattern: Setting the timeout to the 15-minute maximum is rarely ideal for production. Set your timeout slightly above the expected P99 duration after load testing. If an upstream dependency hangs, a tight timeout prevents requests from stalling indefinitely and running up compute bills.

1-ms Billing Precision: Lambda bills execution runtime in 1-millisecond increments. Avoiding unnecessarily prolonged runtimes directly reduces overall costs.

Understanding Lambda Billing Mechanics Lambda follows a pay-for-what-you-use pricing model based on two primary dimensions:

Total Requests: Billed per invocation (including console test invocations and event-driven triggers).

Compute Duration (GB-Seconds): Calculated from the moment your code begins executing until it returns or terminates, rounded up to the nearest 1 ms.

⚠️ Key Takeaway: You are billed for the allocated memory, not the memory your code actually consumes. If you allocate 10 GB to a function that only consumes 2 GB, you pay the 10 GB rate for the duration of the execution.

AWS Free Tier
1,000,000 free requests per month.

400,000 GB-seconds of compute time per month.

The Balance Between Memory, Speed, and Cost Counterintuitively, increasing memory can sometimes lower your total AWS bill.

Because CPU scales proportionally with memory, a CPU-bound workload running with 1,024 MB may finish in half the time of the same code running at 512 MB. Even though the hourly compute rate is higher, the drastically reduced duration can result in a lower total cost in GB-seconds.
Deploying and Testing Serverless Application:
Transitioning from traditional server-based application development to serverless architecture requires a shift in how you think about environments, testing, and deployments. In this post, we’ll explore the differences between the two paradigms, and learn how frameworks like the AWS Serverless Application Model (AWS SAM) and deployment tools like AWS CodeDeploy simplify the process of shipping reliable serverless applications.

1. The Deployment Analogy: Moving In vs. Building from Scratch

To understand the difference between traditional and serverless deployments, consider the real-world analogy of buying a house.

Server-Based Deployments: The Prebuilt House

In a server-based model, your deployment environment is like a pre-existing house. Before you move in, you know the layout, the infrastructure, and the constraints (e.g., three bedrooms, two bathrooms). You don’t need to know how the foundation was poured; you just work with what is already there.

When you deploy, you pack your code into boxes and hand it to a DevOps team (the movers). The movers take your boxes to the designated environment (the house) and unpack them onto running server instances. The environment sits idle, waiting for your code.

Serverless Deployments: The Blueprint

A serverless deployment is like designing and building a house from a blueprint. You must specify every detail: the number of rooms, the wiring, the plumbing, and the exact placement of windows.

In AWS, this blueprint is the AWS CloudFormation template (Infrastructure as Code). A CloudFormation template specifies every detail of the Lambda function and the exact environment required to run it. With this blueprint, AWS provisions the exact "house" your application needs every time it deploys, allowing you to replicate identical environments across multiple AWS accounts seamlessly.

2. Shifting the Developer Workflow

The transition to serverless changes the day-to-day workflow for developers, particularly around testing.

Feature	Server-Based Workflow	Serverless Workflow
Development	Pull down local copy of the app.	Author code bundled with CloudFormation (blueprint).
Testing	Local IDE debugging, deploying to persistent test servers.	Cloud-native testing. Local emulation (via SAM CLI) is limited; true testing happens in isolated cloud accounts.
Deployment	Hand off code to DevOps to update existing long-running instances.	Deploy code + infrastructure as a single immutable package (Stack) to the cloud.

Because serverless relies heavily on cloud-native integrations (e.g., IAM roles, API Gateway, DynamoDB), fully recreating the environment locally is impossible. Instead, developers deploy dedicated stacks to isolated sandbox AWS accounts to perform realistic testing.

3. Simplifying with AWS SAM

Writing raw CloudFormation JSON or YAML can quickly become complex. A simple API endpoint backed by a database might require over 100 lines of boilerplate for IAM roles, API mappings, and table definitions.

AWS SAM (Serverless Application Model) simplifies this. SAM acts as a streamlined shorthand for CloudFormation. It transforms simplified instructions into a fully detailed CloudFormation template during deployment.

Benefits of AWS SAM:

Environmental Parity: Ensures you deploy the exact same stack definition to Development, Staging, and Production.
Simplified Experimentation: Without the overhead of maintaining server instances, you can easily spin up isolated cloud stacks for different Git feature branches, only paying for the exact invocations you trigger.

4. Mitigating Risk: Versions and Aliases

One challenge with serverless deployments is that updates can go live instantly, potentially overwriting a working production function. To mitigate this risk, AWS Lambda uses Versions and Aliases.

$LATEST Version: The default, mutable version of your function. Every time you upload code, it updates $LATEST.
Published Versions: An immutable snapshot of your code and configuration (e.g., Version 1, Version 2). Once published, a version cannot be changed.
Aliases: A named pointer (e.g., PROD, TEST) that routes traffic to a specific published version. Instead of hardcoding version numbers into your API Gateway or event sources, you point them to an Alias. When you deploy a new version, you simply update the Alias to point to it.

Test Using Alias Routing (Traffic Splitting)

Aliases can point to a maximum of two Lambda function versions simultaneously to facilitate traffic splitting. For example, you can route 90% of traffic to Version 1 and 10% to Version 2 to safely test a new release. Both versions must share the same runtime role and dead-letter queue (DLQ) configuration.

5. Safe Deployments with AWS CodeDeploy

Lambda integrates directly with AWS CodeDeploy to automate rollouts and manage traffic shifting safely. CodeDeploy supports three primary traffic-shifting strategies:

Canary: Traffic is shifted in two increments. (e.g., 10% of traffic is shifted to the new version. If successful after a set time, the remaining 90% is shifted).
Linear: Traffic is shifted in steady, predetermined increments every X minutes (e.g., 10% every 5 minutes).
All-at-Once: Shifts 100% of traffic to the new version immediately.

Rollback Mechanisms

CodeDeploy ensures safety through testing and monitoring options:

Hooks: Execute pre-traffic and post-traffic Lambda functions to run automated sanity checks before routing production traffic, and again after the shift completes.
Alarms: Integrate with Amazon CloudWatch to monitor error rates during the rollout. If an alarm triggers, CodeDeploy automatically halts the deployment and rolls traffic back to the previous version.

⚠️ Best Practice: When CodeDeploy triggers a rollback, the entire CloudFormation template being deployed rolls back. Keep your SAM/CloudFormation templates scoped as concisely as possible (ideally, one template per microservice) to minimize the blast radius of a rollback.

Summary & Key Takeaways

Serverless is Infrastructure as Code: Your deployment artifact is your code plus your environment blueprint (CloudFormation/SAM).
Cloud-First Testing: Shift away from local monolith testing toward deploying ephemeral stacks in isolated AWS accounts.
Versions & Aliases: Never use $LATEST in production. Publish immutable versions and route traffic using Aliases.
Automated Safety: Use AWS CodeDeploy for Canary or Linear traffic shifting, backed by CloudWatch alarms and validation hooks.

Monitoring and Troubleshooting:
AWS Lambda abstracts away underlying infrastructure, but you still need deep visibility into how your code performs in the cloud. Effective monitoring and troubleshooting are critical for maintaining high availability and optimizing the performance of your serverless applications.

This post covers how to use native AWS services—Amazon CloudWatch, Lambda Insights, and AWS X-Ray—to monitor, trace, debug, and troubleshoot your Lambda functions.

1. Built-In Monitoring with Amazon CloudWatch

AWS Lambda automatically monitors functions on your behalf and reports native telemetry to Amazon CloudWatch. Without any extra configuration, Lambda automatically tracks request volume, execution duration, and error rates.

To effectively monitor the health of your serverless applications, you should understand these core built-in metrics:

Metric	Description
Invocations	The total number of times your function code is executed, including successful runs and errors.
Duration	The amount of time your function code spends processing an event (billed in 1-ms increments).
Errors	The number of invocations that fail due to errors in your code or timeouts.
Throttles	The number of invocation requests rejected because your function reached its concurrency limit.
ConcurrentExecutions	The number of function instances processing events simultaneously across your account or specific function.
IteratorAge	(For stream sources like Kinesis or DynamoDB) The age of the latest record in the event batch when Lambda receives it. High age indicates processing is falling behind.
DeadLetterErrors	The number of times Lambda fails to send a discarded event payload to a configured Dead-Letter Queue (DLQ).

2. Deep System Visibility with CloudWatch Lambda Insights

While standard CloudWatch metrics provide a high-level overview, Amazon CloudWatch Lambda Insights acts as an advanced diagnostic solution. It collects, aggregates, and summarizes system-level metrics (like CPU and memory usage) and diagnostic events (like cold starts and worker shutdowns).

How It Works

Lambda Insights uses a CloudWatch Lambda extension, which is attached to your function as a Lambda Layer. When enabled, the extension collects system-level metrics and emits a single performance log event for every invocation. CloudWatch parses these logs using Embedded Metric Format (EMF) to generate granular dashboards without adding high-latency overhead to your code.

The Lambda Insights Dashboard

The console provides two primary operational views:

Multi-Function Overview: Aggregates runtime metrics for all Lambda functions within the current AWS account and Region. This view is essential for identifying over-utilized or under-utilized functions at a glance.
Single-Function View: Drills down into the specific runtime metrics of an individual function. Use this view to troubleshoot individual request anomalies, memory leaks, or specific cold start spikes.

3. Distributed Tracing with AWS X-Ray

In a microservices architecture, a single user request might traverse an API Gateway, trigger a Lambda function, read from DynamoDB, and push a message to SQS. AWS X-Ray helps you visualize these connected components, identify performance bottlenecks, and trace requests that result in errors across the entire call flow.

X-Ray processes trace data generated by your Lambda functions to create an interactive Service Map and searchable trace summaries.

Use Cases for AWS X-Ray

Tuning Performance: Pinpoint exactly which downstream service is slowing down your Lambda function.
Call Flow Visualization: Map out the exact path of API calls and AWS service interactions.
Bottleneck Identification: View the timing of an invocation broken down into sub-segments.

Analyzing Cold Starts vs. Warm Starts

When analyzing X-Ray traces, you will immediately see the performance difference between a Cold Start and a Warm Start.

Cold Start Traces: When an event (e.g., an S3 object creation) triggers a new Lambda environment, the X-Ray trace will show a distinct Initialization (Init) phase. This is the time AWS takes to provision the underlying container, load the runtime, and execute your deployment package initialization code.
Warm Start Traces: If a subsequent S3 object is uploaded while the container is still active, the X-Ray trace will show a significantly faster execution. The Initialization phase is entirely absent because the runtime environment and SDK connections are already established and reused.

Summary & Key Takeaways

Tool / Concept	Best Used For
CloudWatch Standard Metrics	Tracking baseline health: Invocations, Duration, Errors, and Throttles.
CloudWatch Lambda Insights	Profiling system-level diagnostics: Memory utilization, CPU usage, and aggregate cold start analysis via Lambda Layers.
AWS X-Ray	Distributed tracing: Visualizing end-to-end call flows, mapping downstream dependencies, and measuring exactly where time is spent during a cold or warm start.

Day3 Lab with Serveless development.Getting into the Serverless Mindset

S Uma Shankar Reddy — Fri, 14 Aug 2026 07:27:41 +0000

If you were to build a simple web service today, you might instinctively deploy a web application on a single server, like an Amazon EC2 instance, connected to a database. As traffic grows, you'd add a load balancer, set up an Auto Scaling group, and spread your instances across multiple availability zones.

This traditional architecture is proven and common. But it also comes with a lot of "undifferentiated heavy lifting"—managing host configurations, patching operating systems, and monitoring server health. These tasks are critical, but they aren't unique to your business.

What if you could hand all of that over to AWS? Enter the serverless mindset.

The 4 Pillars of Serverless

When we talk about an architecture being "serverless," we are referring to four core characteristics:

No Server Management: You never have to provision, patch, or manage hosts.
Flexible Scaling: The platform scales automatically based on the unit of work (e.g., database reads/writes or HTTP requests), not CPU or memory.
Automated High Availability: Fault tolerance is baked into the platform by default. You don't have to engineer your way around single points of failure.
Never Pay for Idle: You are only charged for the exact compute time you consume. If a function runs for 300 milliseconds, you pay for 300 milliseconds. If there's no traffic, you pay nothing for compute.

Changing How You Think About Applications

Migrating from a server-based model to a serverless one requires a few fundamental paradigm shifts:

1. Shift to Event-Driven Design

In a traditional model, you might ask, "What data am I storing, and what operations do I perform against it?"

In a serverless world, you need to ask, "What events should trigger an action in my system?"
Everything becomes an event. An HTTP request, a new file dropped in an S3 bucket, or a change in a DynamoDB table can automatically trigger an AWS Lambda function to execute your custom business logic.

2. Embrace Managed Services

Don't just rely on Lambda; leverage the broader AWS serverless ecosystem to handle primitive application concerns.

Use Amazon API Gateway to manage restful APIs, authentication, and throttling.
Use Amazon DynamoDB or S3 instead of managing your own database clusters.
Use AWS Step Functions to coordinate microservices without writing custom code for retries or error handling.

3. Unlock Massive Parallelization

Because you never pay for idle capacity, you no longer have to worry about over-provisioning servers for highly parallel tasks.

Take video transcoding as an example. Traditionally, a single server might process a video file serially over 4 to 6 hours. By using serverless architecture, you can split that video into tiny time-slices, spin up thousands of Lambda functions to process them concurrently, and merge them back together.

The result? A 4-hour job drops to 10 minutes, and because of Lambda's pricing model, it often costs significantly less than maintaining the infrastructure to do it the old way.

The Bottom Line

Serverless amplifies the benefits of cloud computing. By removing the burden of infrastructure management, it drastically lowers operational costs and eliminates the waste of paying for idle CPU cycles. But most importantly, it gives your engineering teams their time back—allowing them to stop managing servers and start focusing on the code that actually differentiates your business.

Day 2 with AWS skill builder topic is Serverless Development

S Uma Shankar Reddy — Thu, 13 Aug 2026 07:06:34 +0000

get started developing applications for the AWS serverless platform and how your life as a developer changes when you move from a traditional application development environment to a serverless one.

There are a number of benefits that our customers realize when moving to a serverless architecture, including an improved cost model for their infrastructure and the ability to scale their costs along with the usage of their application.

The AWS serverless platform is comprised of a number of different services that take care of everything from compute to api management, data persistence and messaging. In this course will be focused on the AWS Lambda service, which is a serverless compute platform that allows you to bring your own code.

Now this course assumes that you're already familiar with the basics of the AWS Lambda service. But to review, AWS Lambda allows you to bring your own code and have it run in response to events. So, when an event source triggers your function, your code is run and it can interact with other downstream services such as databases and message streams.

Now it's important to understand that the permission model for Lambda has two different components.

On the front end the event sources that are allowed to trigger your Lambda function are controlled by an IAM resource policy and the resources that your function is allowed to interact with are controlled by the execution role.

So, if you were to have an Amazon S3 bucket triggering a Lambda function, which then put some data into a DynamoDB table for instance, the Amazon S3 permissions to invoke the function would be managed by the resource policy, while the DynamoDB access for your code itself would be managed by the execution role.

WRITE LAMBDA FUNCTIONS

So, let's get started by taking a look at some of the best practices for writing code for Lambda functions. Oftentimes when developers get started with AWS Lambda, they use the AWS Management Console to write their first functions.

However, when you start developing production applications, it's important to move away from that initial experimental kind of phase and start using standard application development tools and practices that you're used to.

One of the most important lessons to take away from this is that all of the best practices that you've learned about software development still apply when it comes to developing serverless applications. You should still be writing good quality, object-oriented code and build and deploy your applications using standard industry practices.

So, let's talk a little bit about how you might organize the code within your Lambda function. Every Lambda function has a handler method. You can think of a handler method, like a main method in a JAVA application. And remember that when you're building Lambda functions, just like it doesn't make sense to include all of the business logic and all of the code for your application into a single main method, you should also be splitting up the functionality of your Lambda functions into multiple classes and functions that are called from that primary entry point.

A typical layout for a Lambda function might look something like this, where we divide the functionality into multiple layers. It starts with the handler function that we just talked about where you would set up your function configuration. Any of the Lambda specific code needed to integrate with the Lambda runtime should go here, but you shouldn't include any of the actual business logic for the function in the entry point itself.

Instead, you would put that business logic into a controller class that's responsible for handling the actual event itself and doing all of the business specific functionality for that particular method.

Finally, service classes can be used to abstract away any external services that your function needs to interface with and provide business interfaces into those external services.

MANAGING SERVERLESS APPLICATION

Transcript
–
So now that we've taken a look at some of the best practices for writing code for your Lambda function, let's talk a little bit about the overall development work flow that's necessary when you move from a traditional application environment into a serverless model.

Just like we talked about, the best practices for writing code when it comes to using Lambda don't really change from a traditional application development world. Also, the tool chain that you're using shouldn't have to change much, either. You should still be using standard source control, IDEs. build and deployment tools when you're building functions in Lambda as you would when you're building traditional applications.

The one addition to that is using a serverless application framework to help manage all of the components of the application. In a traditional application, you would typically use a build tool like Maven or Gradle to create a compiled application binary that then goes and gets deployed onto a cluster of servers. In the serverless world, there's an additional step where you need to package and deploy your code out to the Lambda service, and you're probably going to be breaking your code up across multiple different Lambda functions and resources. And this is where an application framework really becomes valuable.

Typically, when you're deploying a serverless application, there are a number of different steps required in order to actually move from development into a running application. This includes building the code, zipping it up, sending it to Amazon S3, managing all of the different execution roles, and IAM policies, creating the function API and other resources that are integrated to your application, and then finally updating those integrations and creating any other components that are necessary. Now, typically, when we think about a complex process like this, we would use a tool like AWS CloudFormation to script out and declare all of the different resources that need to be created, and to help with the orchestration there.

However, with a serverless application, there are a lot of different resources that need to be created. So even to create a relatively simple API for instance, that has a single method with one function backing it and maybe a simple DynamoDB table, there are a number of different resources and configuration components that you would need to define inside of a CloudFormation template in order to get that application launched.

One of the main benefits of using an application framework such as the AWS Serverless Application Model (SAM) is that the code required to define all of those application components is dramatically simplified.

So now we can take a look at an example SAM template here, where we're defining a function as well as the events sources and API structure, all in a few lines of code. So, compared to the previous CloudFormation template that would've taken potentially hundreds of lines to define our application, we can now do the same thing in much, much less code. It makes it more maintainable and easier to develop and scale overall as you build larger and larger applications.

So, let's talk a little bit more about AWS SAM, which is an example of one of these application frameworks. AWS SAM provides a CLI that allows you to easily package and deploy your applications. The first step in packaging a new application is to run the SAM package command. That command is going to take all of the function code or compiled binaries within your application, create a zip archive that's ready to be deployed to Lambda, and upload that to Amazon S3.

It's then going to modify the template definition that you have to update the code uri from a local system path to the S3 path that's been created by the tool in the previous step. So now, instead of you being responsible for zipping and packaging this application, the tool itself is automating all of that process for you.

Once you've created a package template using the SAM CLI, it can then be deployed using the AWS CloudFormation service. So, this allows us to simplify the overall deployment process we looked at previously to two simple CLI commands. And now we can manage our application deployment across multiple accounts and environments easily and repeatably in order to provide an automated deployment mechanism.

So now that we have a good mechanism for packaging and deploying applications, let's talk about how you should be organizing your application code into a source code repository. Oftentimes customers struggle to decide how many functions should live within a single repository. On the one hand, you could put a single function inside of an individual repository and create a new repository for every single individual Lambda function that you create. Or you could put all of the functions that you build into a single source code repository. However, both of these options have drawbacks and really require a different mindset when you're thinking about how to organize the repositories.

Instead of being focused on individual functions, think about how your application is divided into services. A service should be comprised of one or more functions, along with all of the other AWS services, and resources necessary for that particular piece of functionality to work.

Each of those services can then be defined in an individual template and stored in a single repository. This way you have a separate repository for every service but still have multiple Lambda functions in each one of your repositories.

There are a couple of different ways you can approach providing developers with a dedicated sandbox environment. On the one hand, you can create separate accounts for each developer. This is typically the most flexible and provides the best isolation between developers. However, there is some overhead that you need to be aware of in terms of your ability to secure and monitor all of these different accounts. Assuming your organization already has the infrastructure in place to create and manage multiple AWS accounts effectively, this is probably the best way to go.

On the other hand, you can use a single shared development account that all developers use to deploy multiple stacks into. The nice thing about using a framework like we discussed in the previous section, is that each developer can deploy the same code multiple times, using something like AWS SAM and simply create multiple stacks within the same environment and test different versions of the code side by side.

Manual:

TEST AND DEBUGGING SERVERLESS APPLICATION

Demystifying Amazon ECS: A Hands-On Guide to Container Orchestration

S Uma Shankar Reddy — Wed, 12 Aug 2026 07:54:43 +0000

As I continue to dive deeper into backend development and cloud infrastructure, I've realized that understanding how to effectively deploy and manage containers is a game-changer. Mastering cloud orchestration tools is also a huge differentiator for fresh graduates stepping into the fast-paced tech industry. Recently, I completed a comprehensive lab on Amazon Elastic Container Service (ECS), and I want to share a walkthrough of that experience.

If you are familiar with Docker and basic networking (like TCP ports and Load Balancers), this guide will help you understand how AWS manages containerized applications at scale.

Here are a few snapshots from the lab environment to give you an idea of the interface and objectives:

The Architecture Overview
Before deploying anything, it's crucial to understand the environment. For this walkthrough, the foundational infrastructure was already provisioned.

Here is the architecture diagram of the environment we are working with:

Key Components:

Amazon VPC: Configured with two public subnets across separate Availability Zones for high availability.

Network Load Balancer (NLB): Routes external internet traffic to our containers.

Auto Scaling Group: Manages the underlying EC2 instances that will host our containers.

Amazon ECS Cluster: The logical grouping of our EC2 instances and tasks.

Step 1: Registering a Task Definition
In ECS, a Task Definition acts as the blueprint for your application. It’s a JSON file that tells ECS exactly how to run your Docker container, specifying details like CPU/memory allocation, port mappings, and volume mounts.

For this lab, I created a task definition family named yourApp-demo. Using a JSON configuration, I defined two containers:

simple-app: Uses the httpd:2.4 image, maps port 80, and mounts a shared volume to the Apache document root.

busybox: Uses a basic busybox image and runs a shell script to continuously generate an index.html file (saying "Congratulations!") into that shared volume.

This setup perfectly demonstrates how sidecar containers can interact via shared volumes.

Step 2: Creating an ECS Service
With the blueprint ready, the next step is to actually run it. An ECS Service ensures that your desired number of tasks are constantly running and automatically replaces any that fail.

Here is how I configured the service:

Service Name: myFirstService

Launch Type: EC2 (I opted for EC2 over Fargate, meaning the tasks run on instances we manage via the Auto Scaling Group).

Service Type: Replica (Maintains a specific number of instances; I started with a desired task count of 1).

Load Balancing: Connected to the pre-provisioned Network Load Balancer on port 80 to expose the app to the internet.

After waiting a few minutes for the deployment to complete, I grabbed the NLB's DNS name, pasted it into my browser, and successfully viewed the "Congratulations!" sample app page!

Step 3: Zero-Downtime Application Updates
One of the most powerful features of ECS is its ability to handle rolling updates smoothly. If you need to push a new version of your backend code, you don't want your users to experience downtime.

To test this, I simulated an application update:

Created a New Revision: I duplicated the original task definition but tweaked the shell script in the busybox container to output "Thank You!" instead of "Congratulations!".

Updated the Service: I navigated back to myFirstService and updated it to use the (LATEST) revision of the task definition.

What happens behind the scenes?
ECS gracefully spins up a new task with the updated definition. Once it registers as healthy, ECS drains the connections from the old task and shuts it down. Refreshing the browser seamlessly revealed the new "Thank You!" message without any service interruption.

Step 4: Scaling the Service Capacity
Handling traffic spikes is a core requirement for modern applications. ECS makes dynamic scaling incredibly straightforward.

To scale up:

I updated myFirstService again.

Changed the Desired tasks from 1 to 2.

By checking the deployment events, I could watch the ECS scheduler spring into action, provisioning a second task and distributing it appropriately across the cluster to ensure high availability. If traffic were to drop, scaling down is just as easy—ECS would gracefully terminate the excess tasks to save resources.

Final Thoughts
Stepping through this lab provided a fantastic, practical look at how Amazon ECS bridges the gap between raw Docker containers and enterprise-grade deployment. By mastering Task Definitions, Services, Rolling Updates, and Scaling, building a robust, highly available backend becomes a much more manageable reality.

If you're looking to automate this further in a production environment, exploring the underlying AWS CloudFormation templates used to build this architecture is a great next step!

i wanted to know if i can additionally change the code and costumize it so,
This JSON code is an Amazon Elastic Container Service (ECS) Task Definition. Think of it as a blueprint that tells AWS exactly how to run and configure your application’s Docker containers.

What makes this specific code interesting is that it perfectly demonstrates the Sidecar Pattern. Instead of putting everything into one massive container, it splits the workload between two containers that work together and share a storage volume.

Here is a breakdown of how it works and how you can customize it for your own projects.

🔍 Deconstructing the Code

1. The Main Server (`simple-app`)

The Job: This container is running an Apache HTTP web server ("image": "httpd:2.4").
Networking: It maps port 80 on the host to port 80 on the container (portMappings), which is the standard port for web traffic.
Storage: It mounts a volume named my-vol to the /usr/local/apache2/htdocs directory. This is the exact folder where Apache looks for files to serve to visitors.

2. The Sidekick (`busybox`)

The Job: This container uses a lightweight Linux image ("image": "busybox"). It doesn't serve web traffic; its only job is to run a script in the background.
The Script: The command section contains a shell script loop that continuously writes an HTML file—complete with a "Congratulations!" message and the current date/time—and saves it as index.html.
The Connection: Notice the "volumesFrom" block? It connects to the simple-app container's volume. By writing that index.html file into the shared space, the Apache server automatically serves it to anyone who visits the website.

🛠️ How to Customize It

You can modify this JSON to fit almost any architecture. Here are a few ways to tailor it:

Swap the Web Server

If you prefer a different web server, you can easily change the image in the simple-app definition. For example, you could swap "image": "httpd:2.4" to "image": "nginx:latest". You would just need to update the containerPath to Nginx's default web directory (/usr/share/nginx/html).

Deploy a Custom Backend

If you are pushing further into backend development, you probably won't be using a shell script to generate static HTML. You can completely replace this dual-container setup with a single container running your own code.

Change the "image" to point to your own Docker image hosted on Amazon ECR or Docker Hub (e.g., a Python container running a Django or FastAPI backend).
Remove the busybox container entirely.
Update the containerPort to match whatever port your backend framework listens on (like 8000 or 5000).

Adjust Compute Resources

Right now, the containers are allocated very few resources ("memory": 300, "cpu": 10). If your application does heavy data processing, you will need to scale these up.

CPU: Measured in CPU units (1024 units = 1 vCPU). You might bump this to 256 or 512.
Memory: Measured in MiB. You could increase this to 512 or 1024.

Add Environment Variables

Real-world applications usually need configuration data, like database passwords or API keys. You can inject these by filling out the currently empty "environment": [] array:

"environment": [
  {"name": "DATABASE_URL", "value": "your_db_connection_string"},
  {"name": "ENVIRONMENT", "value": "production"}
]

CyberArena – Interactive Cyber Security Simulation & Threat Analysis Platform

S Uma Shankar Reddy — Sat, 23 May 2026 15:03:44 +0000

Excited to share my latest project — CyberArena, an interactive Cyber Security Simulation & Threat Analysis Platform built using Python, Flask, SQLite, Docker, HTML/CSS, and JavaScript.

🔐 Features include:
• AI-based Threat Analyzer
• Phishing Simulation
• Base64 Payload Analysis
• RSA Encryption Demo
• Steganography Detection
• Leaderboard & Gamification System
• Responsive Cyberpunk Dashboard UI

This project helped me strengthen my understanding of:
✔ Cybersecurity concepts
✔ Threat analysis workflows
✔ Authentication systems
✔ Python backend development
✔ Docker deployment
✔ Responsive UI design

The platform is inspired by real-world SOC Analyst and Cyber Security Analyst workflows, including phishing detection, suspicious activity analysis, and security reporting.

🚀 Live Demo:
https://cyberarena-interactive-cyber-attack.onrender.com/

💻 GitHub:
https://github.com/omu47/CyberArena-Interactive-Cyber-Attack-Simulation-Threat-Analysis-Platform

Currently continuing to scale the project with plans for SIEM-style monitoring, PostgreSQL, Kafka, Kubernetes, and advanced AI-powered threat intelligence features.

Will really love to connect and if you want to contribute please do dm , don't waste time in thinking

Building ThreatPulse IDS: An AI-Powered Intrusion Detection System

S Uma Shankar Reddy — Wed, 20 May 2026 14:26:52 +0000

Late at night, while most people scroll through social media, millions of unseen packets travel silently across networks every second.

Some are harmless.
Some carry attacks.

That thought made me curious:
“How do cybersecurity systems actually detect threats in real time?”

So I decided to stop just reading about cybersecurity…
and build something real.

That’s how ThreatPulse IDS started.

At first, it was just a small Python script trying to capture packets using Scapy. Then came errors, crashes, threading problems, Windows packet sniffing issues, Npcap setup struggles, broken Flask reloads, database redesigns, and endless debugging sessions.

But slowly, the project evolved.

I built a system that can monitor live TCP, UDP, and ICMP traffic, detect DDoS-like behavior, identify port scans, flag suspicious IPs, and even use Machine Learning to detect anomalous traffic patterns using Isolation Forest.

Then I connected everything to a real-time SOC-style dashboard using Flask-SocketIO, added SQLite storage for persistent monitoring, created live charts, alert systems, and automated PDF security reports.

What started as curiosity became a fully working AI-powered Intrusion Detection System.

This project taught me something important:

Cybersecurity is not just about tools.
It’s about understanding behavior, patterns, networks, and building systems that can react before humans even notice something is wrong.

ThreatPulse IDS is still growing.
Next steps include GeoIP tracking, SIEM integration, threat intelligence feeds, Docker deployment, and advanced analytics.

But this project already represents something bigger for me:
proof that learning by building is the fastest way to grow.

From raw packets…
to intelligent threat detection.
click to view

DEV Community: S Uma Shankar Reddy

Amazon API Gateway for Serverless Applications

Building and Deploying APIs with Amazon API Gateway

1. Anatomy of the API Call

2. Steps to Build an API in the Console

3. API Stages & Version Management

4. Deployment Best Practices

Knowledge Check: Correct Answers

Data Mapping and Request Validation in API Gateway

1. Data Transformations with Mapping Templates

Key VTL Variables

2. Offloading Request Validation

3. Customizing Gateway Responses

Day 4: AWS Lambda Foundations

tags: aws, serverless, lambda, programming

1. The AWS Lambda Programming Model

Supported Languages & Environments

2. Anatomy of a Lambda Function: The Handler Method

1. Memory Allocation: The Compute Lever

1. The Deployment Analogy: Moving In vs. Building from Scratch

Server-Based Deployments: The Prebuilt House

Serverless Deployments: The Blueprint

2. Shifting the Developer Workflow

3. Simplifying with AWS SAM

4. Mitigating Risk: Versions and Aliases

Test Using Alias Routing (Traffic Splitting)

5. Safe Deployments with AWS CodeDeploy

Rollback Mechanisms

Summary & Key Takeaways

1. Built-In Monitoring with Amazon CloudWatch

2. Deep System Visibility with CloudWatch Lambda Insights

How It Works

The Lambda Insights Dashboard

3. Distributed Tracing with AWS X-Ray

Use Cases for AWS X-Ray

Analyzing Cold Starts vs. Warm Starts

Summary & Key Takeaways

Day3 Lab with Serveless development.Getting into the Serverless Mindset

The 4 Pillars of Serverless

Changing How You Think About Applications

1. Shift to Event-Driven Design

2. Embrace Managed Services

3. Unlock Massive Parallelization

The Bottom Line

Day 2 with AWS skill builder topic is Serverless Development

Demystifying Amazon ECS: A Hands-On Guide to Container Orchestration

🔍 Deconstructing the Code

1. The Main Server (simple-app)

2. The Sidekick (busybox)

🛠️ How to Customize It

Swap the Web Server

Deploy a Custom Backend

Adjust Compute Resources

Add Environment Variables

CyberArena – Interactive Cyber Security Simulation & Threat Analysis Platform

Building ThreatPulse IDS: An AI-Powered Intrusion Detection System

1. The Main Server (`simple-app`)

2. The Sidekick (`busybox`)