AWS Lambda & API Gateway support for ASGI

Overview

Mangum

Package version Build Status

PyPI - Python Version

Mangum is an adapter for using ASGI applications with AWS Lambda & API Gateway. It is intended to provide an easy-to-use, configurable wrapper for any ASGI application deployed in an AWS Lambda function to handle API Gateway requests and responses.

Documentation: https://mangum.io/

Features

  • API Gateway support for HTTP and REST APIs.

  • Compatibility with ASGI application frameworks, such as Starlette, FastAPI, and Quart.

  • Support for binary media types and payload compression in API Gateway using GZip or Brotli.

  • Works with existing deployment and configuration tools, including Serverless Framework and AWS SAM.

  • Startup and shutdown lifespan events.

Requirements

Python 3.6+

Installation

pip install mangum

Example

from mangum import Mangum

async def app(scope, receive, send):
    await send(
        {
            "type": "http.response.start",
            "status": 200,
            "headers": [[b"content-type", b"text/plain; charset=utf-8"]],
        }
    )
    await send({"type": "http.response.body", "body": b"Hello, world!"})


handler = Mangum(app)

Or using a framework.

from fastapi import FastAPI
from mangum import Mangum

app = FastAPI()


@app.get("/")
def read_root():
    return {"Hello": "World"}


@app.get("/items/{item_id}")
def read_item(item_id: int, q: str = None):
    return {"item_id": item_id, "q": q}

handler = Mangum(app)
Issues
  • Refactor handlers to be separate from core logic

    Refactor handlers to be separate from core logic

    Okay here is a BIG one. This refactors out all of the logic for each event source into their own classes. This helps encapsulate all the messy logic for each event source into one place. It also makes it easier to add new event sources as we choose. I namespaced the handlers with "AWS" with thoughts that this could actually apply to other serverless implementations over on Azure, GCP, etc. if needed.

    I wanted to get this in front of you sooner rather than later so you could take a look. It needs a couple more lines of coverage and I'm going to go back and look through some of the issues to make sure I have them covered in tests and they're still working (regression is no good)

    It might be easier to look at the repo at my commit, not just the changes.

    Let me know what you think, big changes like this are scary but it feels a lot cleaner.

    opened by four43 17
  • AWS WebSocket support

    AWS WebSocket support

    I've removed the existing WebSocket support as part of https://github.com/jordaneremieff/mangum/issues/127 with the intention of developing it outside of this package, then later migrating it back in (if it makes sense to do so). My main concern is that I want to avoid impacting the stability of the HTTP implementation which is the primary use-case, and the maintenance burden was too much for the amount of capacity I have to spare currently. I also want to re-design it with broadcast support as an initial requirement rather than a feature added on later.

    I think a new project might use Mangum as a dependency, or could end up looking something like this:

    from mangum import Mangum
    from mangum_ws import MangumWebSocket
    
    def handler(event, context):
        if 'eventType' in event['requestContext']:
            asgi_handler = MangumWebSocket(app)
        else:
            asgi_handler = Mangum(app)
    
        return asgi_handler(event, context)
    

    Not really sure. I haven't been motivated to take this up for awhile, but if anyone wants to give it a shot I can help where possible.

    feature websockets 
    opened by jordaneremieff 17
  • Deploying FastAPI as Lambda Function

    Deploying FastAPI as Lambda Function

    from fastapi import FastAPI
    from mangum import Mangum
    
    app = FastAPI()
    
    @app.get("/")
    def hello_world():
        return {"hello": "world"}
    
    handler = Mangum(app)
    

    ERROR:

    [ERROR] TypeError: __call__() takes 2 positional arguments but 4 were given
    Traceback (most recent call last):
      File "/var/task/mangum/__init__.py", line 123, in __call__
        raise exc
      File "/var/task/mangum/__init__.py", line 118, in __call__
        response = self.asgi(*args, **kwargs)
      File "/var/task/mangum/__init__.py", line 178, in asgi
        response = asgi_cycle(self.app, body=body)
      File "/var/task/mangum/__init__.py", line 38, in __call__
        asgi_instance = app(self.scope, self.receive, self.send)
    

    I tried this, but could not import AWSLambdaAdapter

    from mangum.platforms.aws.adapter import AWSLambdaAdapter
    

    Can you please provide a working example of this?

    opened by chgangaraju 17
  • Problems with FastAPI/Starlette Gzip middleware

    Problems with FastAPI/Starlette Gzip middleware

    (First off, awesome package. Being able to use an actual framework on Lambda without writing any 'transformation' code myself has been incredible.)

    I'm attempting to use Starlette's GZipMiddleware with FastAPI right now, and our front-end is sending a accept-encoding: gzip, deflate, br header.

    When I configure the middleware like so...

    APP = FastAPI()
    # ... other middleware
    APP.add_middleware(
        GZipMiddleware,
        minimum_size=512,
    )
    HANDLER = Mangum(APP, enable_lifespan=False)
    

    ... I receive the following error.

    Exception in ASGI application
    
    Traceback (most recent call last):
      File "/var/task/mangum/protocols/http.py", line 39, in run
        await app(self.scope, self.receive, self.send)
      File "/var/task/fastapi/applications.py", line 142, in __call__
        await super().__call__(scope, receive, send)  # pragma: no cover
      File "/var/task/starlette/applications.py", line 134, in __call__
        await self.error_middleware(scope, receive, send)
      File "/var/task/starlette/middleware/errors.py", line 178, in __call__
        raise exc from None
      File "/var/task/starlette/middleware/errors.py", line 156, in __call__
        await self.app(scope, receive, _send)
      File "/var/task/starlette/middleware/base.py", line 26, in __call__
        await response(scope, receive, send)
      File "/var/task/starlette/responses.py", line 200, in __call__
        await send({"type": "http.response.body", "body": b"", "more_body": False})
      File "/var/task/starlette/middleware/errors.py", line 153, in _send
        await send(message)
      File "/var/task/mangum/protocols/http.py", line 97, in send
        self.response["body"] = body.decode()
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte
    

    I had initially thought it might be due to the minimum_size parameter but removing that did not work. If I removed the middleware completely then my Lambda works perfectly fine.

    I'm a little confused by the "body": b"" part, since this Lambda is returning data, and when I test locally running the same APP with uvicorn I have no issues - body is compressed and status code is 200.

    Is there something I need to do to configure Mangum for compression? Am I reading the stack trace wrong?

    ** FastAPI 0.48.0 Mangum 0.7.0 Python 3.6.8

    opened by kevlarr 15
  • Gracefully hanlde exceptions that happen after successful request.

    Gracefully hanlde exceptions that happen after successful request.

    With the current implementation, any exception in the ASGI app will make mangum return a response with 500, even though the application may have already correctly generated a valid response. In those cases we want to return the valid response and log the error, rather than fail.

    One example where this would manifest: failures in BackgroundTasks in FastAPI.

    This makes it inline with running FastAPI (and other ASGI) applications standalone where failures in the background tasks will return not make the whole request fail.

    opened by tasn 12
  • issue in reading .woff/.ttf/.woff2 (font extension) files

    issue in reading .woff/.ttf/.woff2 (font extension) files

    Hi. There is an issue in reading font files from the AWS API gateway proxied to AWS Lambda. It is reading it as a text file.

    in protocols/http.py body is not encoded in base64 body = base64.b64encode(body) and giving error in self.response["body"] = body.decode()

    It should return header with content-type as font/*

    opened by arvindjangra1996 12
  • 🚧 Add event source detection

    🚧 Add event source detection

    • add event source types
    • add event source detection
    • use event source type in scope creation

    This PR is a one-step closet to support different event sources.

    Also, we should construct responses according to the request type, that work is out of the PR scope though.

    opened by emcpow2 11
  • Double url-encoding of query string with ALB

    Double url-encoding of query string with ALB

    I've found that if I send a get request to FastAPI like GET eg.com/something?name=John+Smith then the database query generated uses literally John+Smith. Same situation using %20.

    It seems that Mangum is doing a second round of url-encoding on the query strings, so when FastAPI (or whatever might sit in the middle) decodes the query string it gets the once-encoded version back.

    I'm working with an Application Load Balancer.

    I'm not 100% sure what the correct behaviour should be, or whether the URL encoding behaviour should be different between API gateway and ALB.

    I'll create a pull request with a failing test for this in a moment.

    Some references:

    https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html "If the query parameters are URL-encoded, the load balancer does not decode them. You must decode them in your Lambda function."

    with ALB source, serverless-wsgi decodes and then encodes the query strings before passing off to WSGI: https://github.com/logandk/serverless-wsgi/blob/f8d5a92f63901ed25d1a09ae19fcaa791e22436f/serverless_wsgi.py#L82-L93

    Related issues from serverless-express https://github.com/vendia/serverless-express/issues/241 https://github.com/vendia/serverless-express/issues/219

    bug 
    opened by jurasofish 10
  • [Feature Request] Support for custom loggers

    [Feature Request] Support for custom loggers

    We are using the logger from aws-lambda-powertools-python. It's a logging tool from AWS, that can be quite helpful when it comes to debugging, especially when using CloudWatch Log Insights.

    I would like to use this logger with Mangum as well.

    I was thinking the constructor could accept a logger_class parameter, which when set is used instead of logging.getLogger. Alternatively, following logging.setLoggerClass, a function that can set which logger is used in adapter.get_logger.

    I tried using logging.setLoggerClass directly, but that results in a RecursionError; the AWS logger doesn't inherit logging.Logger properly, but instead instantiates an internal logger from logging.getLogger. If you think I should report the recursion error on the AWS repo instead, please let me know. I am quite new to Python, and don't know whether this behavior acceptable.

    feature 
    opened by aksel 10
  • Feature - Websockets

    Feature - Websockets

    Issue #132

    This is an attempt to re-introduce WebSockets support in the project. It's still just a draft, but I wanted to put something together as soon as possible to discuss and shape the solution. The implementation is basically the same as the one present in this branch. The PR was getting way too big, and I decided to drop the support to broadcast for now. Maybe we can handle this in another PR/issue.

    I've left a few TODO comments in the code on points where we should keep an eye, but overall my main questions would be these:

    • What's the best approach to instantiate the WebSocketCycle? Right now, I'm picking the protocol based on the lambda event. I think it's the best solution from the user standpoint, as the configuration stays the same as it already is, and we can support both HTTP and WebSocket connections in the same ASGI app. But it's possible to use a separate adaptor class as well.
    • The Scope format is slightly different for the WebSocket connection, but I kept using the same as HTTP.
    • Binary payloads seem to be unsupported by API GW. They suggest a workaround, though. Not sure if we should try to support this.
    • Subprotocols won't be supported, as the application is only called on the MESSAGE event (but the HTTP headers are exchanged on CONNECT).
    websockets 
    opened by eduardovra 9
  • Support multiple serverless platforms

    Support multiple serverless platforms

    This comment [1] explains how to use Mangum with the serverless framework. Since serverless supports multiple providers (e.g., Azure), would it be possible that Mangum enables ASGI support for other providers too?

    [1] https://dev.to/anilgrexit/comment/gkfo

    feature 
    opened by lsorber 9
  • Overwriting read-only Lambda@Edge headers

    Overwriting read-only [email protected] headers

    Hooking up a Mangum lambda to CloudFront as EventType: origin-request returns a 502 response: "The Lambda function result failed validation: The function tried to add, delete, or change a read-only header."

    According to the documentation, the Content-Length Header is one of the read-only headers for origin-request events. Not quite sure why. But it's certainly one of the headers returned when calling the lambda. I use the lambda to handle API requests, so it needs IncludeBody, which is only available with origin-request.

    I was able to get around this by hijacking the response:

    def handler(event, context):
        response = Mangum(app, lifespan="off")(event, context)
        if 'headers' in response:
            response['headers'].pop('content-length')
        return response
    
    help wanted improvement 
    opened by UnderSampled 1
  • Multiple event loops in custom handlers

    Multiple event loops in custom handlers

    Discussed in https://github.com/jordaneremieff/mangum/discussions/256

    Originally posted by jrobbins-LiveData March 20, 2022 The Mangum doc shows this example of how one might handle a custom event:

    def handler(event, context):
        if event.get("some-key"):
            # Do something or return, etc.
            return
    
        asgi_handler = Mangum(app)
        response = asgi_handler(event, context) # Call the instance with the event arguments
    
        return response
    

    I need to handle an incoming AWS EventBridge event. I want to invoke the same method that my HTTP API handler is also invoking -- and it is an async method.

    Here's what I am using

    def handler(event: LambdaEvent, context: LambdaContext) -> dict:
        if "requestContext" in event:
            logger.debug("HTTP API")
            response = fastapi_handler(event, context)
        else:
            logger.debug("Not HTTP API")
            loop = asyncio.get_event_loop()
            response = loop.run_until_complete(app_logic())
        return response
    

    My question(s): Is this the correct pattern to use? In the Mangum source, I see code like this, so I am trying to fit in. My code seems to work, but I read in the Python docs that get_event_loop() is

    Deprecated since version 3.10: Deprecation warning is emitted if there is no running event loop. In future Python releases, this function will be an alias of get_running_loop().

    Which made me wonder if I were doing this correctly?

    help wanted improvement 
    opened by jordaneremieff 1
  • api_gateway_base_path not supported for ALB?

    api_gateway_base_path not supported for ALB?

    Summary

    • Mangum supports events from AWS API Gateway and AWS ALB.
    • Mangum has a api_gateway_base_path argument to strip the prefix of the http path before passing to the underlying app
    • api_gateway_base_path works as expected for API Gateway events
    • As far as I can tell, api_gateway_base_path does not work for ALB events.

    I looked at https://mangum.io/http/ and the GitHub issues and couldn't find this mentioned anywhere.

    My Setup

    • Python 3.9
    • mangum 0.12.4
    • starlette 0.17.1

    Simplified version of my lambda handler:

    def public_foo_function:
        print("Public foo function")
    
    def private_bar_function:
        print("Private bar function")
    
    app = Starlette(
        routes=[
            Route(
                path="/public/foo",
                endpoint=public_foo_function,
            ),
            Route(
                path="/private/bar",
                endpoint=private_bar_function,
            ),
        ]
    )
    
    mangum = Mangum(
        app,
        api_gateway_base_path="/prefix",
    )
    
    def main(event, context):
        return mangum(event, context)
    

    An external API Gateway v2 HTTP has a route /prefix/public/{proxy+} integrated with the lambda. An internal ALB has a listener rule /prefix/private/* integrated with the lambda.

    Requests to <api gateway url>/prefix/public/foo arrive in the lambda and public_foo_function is called, as expected.

    From within my VPC, internal requests to <alb url>/prefix/private/bar arrive in the lambda and Starlette returns Not Found 404. This is unexpected.

    As a workaround, if I change the private route in Starlette app from /private/bar to /prefix/private/bar, private_bar_function is called.

    Considerations

    api_gateway_base_path does have 'api gateway' in the name, and ALB is not an API Gateway. So there's an argument it could be intentional?

    But, I expected mangum to behave consistently for all of its supported input events.

    improvement 
    opened by ShedPlant 2
  • Will this project accept PR for supporting another vendor apart from AWS?

    Will this project accept PR for supporting another vendor apart from AWS?

    I was trying to use ASGI in aliyun fc, a serverless service that is similar to aws lambda, and found this library.

    it seems that Mangum only supports aws for now. Will this project accept PR for supporting another vendor apart from AWS?

    maybe 
    opened by CNLHC 1
  • handle host headers with trailing :

    handle host headers with trailing :

    The handlers currently crash if the host header has a trailing : (for example example.com:). Ideally this header would still propagate down so we can return a user error (4XX) for an invalid host header.

    opened by fcjr 1
  • Allow Mangum to remove certain aws reponse headers from api gateway response

    Allow Mangum to remove certain aws reponse headers from api gateway response

    Problem: Currently Mangum injects the following headers in the api gateway response for an aws lambda integration

    x-amz-apigw-id
    x-amzn-requestid 
    x-amzn-trace-id
    

    This exposes additional information that the client doesn't need to know.

    Proposal:

    Allow Mangum to take optional parameter say exclude_header_keys=[] at the application mounting step.

    An Example of that would look like.

    
    from fastapi import FastAPI
    
    app = FastAPI()
    
    handler = Mangum(app, exclude_header_keys=[]
    
    improvement 
    opened by amieka 2
Releases(0.15.0)
  • 0.15.0(Apr 24, 2022)

    What's Changed

    • :recycle: Relax type annotations, refactor custom handler inferences, naming by @jordaneremieff in https://github.com/jordaneremieff/mangum/pull/259

    Full Changelog: https://github.com/jordaneremieff/mangum/compare/0.14.1...0.15.0

    Source code(tar.gz)
    Source code(zip)
  • 0.14.1(Mar 7, 2022)

    What's Changed

    • :pushpin: Remove references to Python 3.6, update setup.py. by @jordaneremieff in https://github.com/jordaneremieff/mangum/pull/246

    Full Changelog: https://github.com/jordaneremieff/mangum/compare/0.14.0...0.14.1

    Source code(tar.gz)
    Source code(zip)
  • 0.14.0(Mar 3, 2022)

    What's Changed

    • Removing Websocket from docs by @aminalaee in https://github.com/jordaneremieff/mangum/pull/241
    • Replace abstract handlers, customer handlers, type annotations, refactoring. by @jordaneremieff in https://github.com/jordaneremieff/mangum/pull/242

    Full Changelog: https://github.com/jordaneremieff/mangum/compare/0.13.0...0.14.0

    Source code(tar.gz)
    Source code(zip)
  • 0.13.0(Feb 25, 2022)

    What's Changed

    • Remove WebSocket support and misc cleanup/removals by @jordaneremieff in https://github.com/jordaneremieff/mangum/pull/234
    • Replace awslambdaric-stubs with new types, refactor import style. by @jordaneremieff in https://github.com/jordaneremieff/mangum/pull/235
    • Improve logging by @aminalaee in https://github.com/jordaneremieff/mangum/pull/230

    New Contributors

    • @aminalaee made their first contribution in https://github.com/jordaneremieff/mangum/pull/230

    Full Changelog: https://github.com/jordaneremieff/mangum/compare/0.12.4...0.13.0

    Source code(tar.gz)
    Source code(zip)
  • 0.12.4(Feb 7, 2022)

    What's Changed

    • HTTP Gateway V2: Remove use of obsolete multiValueHeaders by @IlyaSukhanov in https://github.com/jordaneremieff/mangum/pull/216
    • mypy - Argument "api_gateway_base_path" to "Mangum" has incompatible type "str"; expected "Dict[str, Any]" by @relsunkaev in https://github.com/jordaneremieff/mangum/pull/220
    • Added explicit python3.9 and 3.10 support by @relsunkaev in https://github.com/jordaneremieff/mangum/pull/224
    • Fix aws_api_gateway handler not accepting combined headers and multiValueHeaders by @Feriixu in https://github.com/jordaneremieff/mangum/pull/229

    New Contributors

    • @IlyaSukhanov made their first contribution in https://github.com/jordaneremieff/mangum/pull/216
    • @relsunkaev made their first contribution in https://github.com/jordaneremieff/mangum/pull/220
    • @Feriixu made their first contribution in https://github.com/jordaneremieff/mangum/pull/229

    Full Changelog: https://github.com/jordaneremieff/mangum/compare/0.12.3...0.12.4

    Source code(tar.gz)
    Source code(zip)
  • 0.12.3(Oct 6, 2021)

  • 0.12.2(Aug 11, 2021)

  • 0.12.1(Jul 23, 2021)

  • 0.12.0(Jul 16, 2021)

  • 0.11.0(Mar 19, 2021)

    0.11.0

    • Remove deprecated enable_lifespan parameter #109.

    • Include API Gateway v2 event cookies in scope headers #153. Thanks araki-yzrh!

    • Support ELB and fix APIGW v2 cookies response #155. Thanks araki-yzrh!

    • Add flake8 to CI checks #157. Thanks emcpow2!

    • Add type hints for lambda handler context parameter #158. Thanks emcpow2!

    • Extract ASGI scope creation into function #162. Thanks emcpow2!

    0.10.0

    • Remove WebSocket support to focus on HTTP #127.

    • Support multiValue headers in response #129. Thanks @koxudaxi!

    • Fix duplicate test names #134. Thanks @a-feld!

    • Run tests and release package using GitHub Actions #131. Thanks @simonw!

    • Only prefix a slash on the api_gateway_base_path if needed #138. Thanks @dspatoulas!

    • Add support to Brotli compress #139. Thanks @fullonic!

    0.9.2

    • Make boto3 dependency optional #115

    0.9.1

    • Bugfix lifespan startup behaviour and refactor lifespan cycle, deprecate enable_lifespan parameter, document protocols. #108

    0.9.0

    • Resolve issue with rawQueryString in HTTP APIs using wrong type #105

    • Implement new WebSocket storage backends for managing connections (PostgreSQL, Redis, DyanmoDB, S3, SQlite) using a single dsn configuration parameter #103

    pre-0.9.0

    I did not maintain a CHANGELOG prior to 0.9.0, however, I still would like to include a thank you to following people:

    @lsorber @SKalt @koxudaxi @zachmullen @remorses @allan-simon @jaehyeon-kim

    Your contributions to previous releases have greatly improved this project and are very much appreciated.

    Special thanks to @tomchristie for all of his support, encouragement, and guidance early on, and @rajeev for inspiring this project.

    Source code(tar.gz)
    Source code(zip)
  • 0.10.0(Oct 3, 2020)

  • 0.9.0(May 9, 2020)

    • Improve documentation (https://github.com/erm/mangum/issues/48)

    • Resolve issue with rawQueryString in HTTP APIs using wrong type (https://github.com/erm/mangum/issues/105)

    • Implement new WebSocket storage backends for managing connections (PostgreSQL, Redis, DyanmoDB, S3, SQlite) using a single dsn configuration parameter (https://github.com/erm/mangum/issues/100)

    • Refactor ASGI lifespan handlers and automatically detect if lifespan is supported by an application (https://github.com/erm/mangum/issues/62)

    • Decouple WebSocket support from DynamoDB to allow alternative WebSocket storage backends (https://github.com/erm/mangum/issues/52)

    • Improving logging throughout the various classes

    Source code(tar.gz)
    Source code(zip)
  • 0.9.0b1(May 3, 2020)

    • Refactor ASGI lifespan handlers and automatically detect if lifespan is supported by an application (https://github.com/erm/mangum/issues/62)

    • Decouple WebSocket support from DyanmoDB to allow alternative WebSocket storage backends (https://github.com/erm/mangum/issues/52)

    • Implement new WebSocket storage backends for managing connections (PostgreSQL, Redis, DyanmoDB, S3, SQlite)

    • Improving logging throughout the various classes

    Source code(tar.gz)
    Source code(zip)
Owner
Jordan Eremieff
Hello
Jordan Eremieff
ASGI specification and utilities

asgiref ASGI is a standard for Python asynchronous web apps and servers to communicate with each other, and positioned as an asynchronous successor to

Django 1k Jun 17, 2022
A modern API testing tool for web applications built with Open API and GraphQL specifications.

Schemathesis Schemathesis is a modern API testing tool for web applications built with Open API and GraphQL specifications. It reads the application s

Schemathesis.io 1.3k Jun 23, 2022
AWS Lambda & API Gateway support for ASGI

Mangum Mangum is an adapter for using ASGI applications with AWS Lambda & API Gateway. It is intended to provide an easy-to-use, configurable wrapper

Jordan Eremieff 954 Jun 20, 2022
Aws-lambda-requests-wrapper - Request/Response wrapper for AWS Lambda with API Gateway

AWS Lambda Requests Wrapper Request/Response wrapper for AWS Lambda with API Gat

null 1 May 20, 2022
aws-lambda-scheduler lets you call any existing AWS Lambda Function you have in a future time.

aws-lambda-scheduler aws-lambda-scheduler lets you call any existing AWS Lambda Function you have in the future. This functionality is achieved by dyn

Oğuzhan Yılmaz 58 Jun 3, 2022
Python + AWS Lambda Hands OnPython + AWS Lambda Hands On

Python + AWS Lambda Hands On Python Criada em 1990, por Guido Van Rossum. "Bala de prata" (quase). Muito utilizado em: Automatizações - Selenium, Beau

Marcelo Ortiz de Santana 8 Dec 1, 2021
Using AWS's API Gateway + Lambda + Python to run a simple websocket application. For learning/testing

Using AWS's API Gateway + Lambda + Python to run a simple websocket application. For learning/testing. The AWS Resources seemed overly complex and were missing some critical gotchas in setting up a system like this.

Seth Miller 11 May 24, 2022
Zappa makes it super easy to build and deploy server-less, event-driven Python applications on AWS Lambda + API Gateway.

Zappa makes it super easy to build and deploy server-less, event-driven Python applications (including, but not limited to, WSGI web apps) on AWS Lambda + API Gateway. Think of it as "serverless" web hosting for your Python apps. That means infinite scaling, zero downtime, zero maintenance - and at a fraction of the cost of your current deployments!

Zappa 1.7k Jun 20, 2022
A simple URL shortener app using Python AWS Chalice, AWS Lambda and AWS Dynamodb.

url-shortener-chalice A simple URL shortener app using AWS Chalice. Please make sure you configure your AWS credentials using AWS CLI before starting

Ranadeep Ghosh 1 Jun 14, 2021
Lambda-function - Python codes that allow notification of changes made to some services using the AWS Lambda Function

AWS Lambda Function This repository contains python codes that allow notificatio

Elif Apaydın 3 Feb 11, 2022
SSH-Restricted deploys an SSH compliance rule (AWS Config) with auto-remediation via AWS Lambda if SSH access is public.

SSH-Restricted SSH-Restricted deploys an SSH compliance rule with auto-remediation via AWS Lambda if SSH access is public. SSH-Auto-Restricted checks

Adrian Hornsby 29 Jun 14, 2022
A suite of utilities for AWS Lambda Functions that makes tracing with AWS X-Ray, structured logging and creating custom metrics asynchronously easier

A suite of utilities for AWS Lambda Functions that makes tracing with AWS X-Ray, structured logging and creating custom metrics asynchronously easier

Amazon Web Services - Labs 1.5k Jun 20, 2022
POC de uma AWS lambda que executa a consulta de preços de criptomoedas, e é implantada na AWS usando Github actions.

Cryptocurrency Prices Overview Instalação Repositório Configuração CI/CD Roadmap Testes Overview A ideia deste projeto é aplicar o conteúdo estudado s

Gustavo Santos 2 Oct 19, 2021
AWS-serverless-starter - AWS Lambda serverless stack via Serverless framework

Serverless app via AWS Lambda, ApiGateway and Serverless framework Configuration

 Bəxtiyar 3 Feb 2, 2022
A Python library to utilize AWS API Gateway's large IP pool as a proxy to generate pseudo-infinite IPs for web scraping and brute forcing.

A Python library to utilize AWS API Gateway's large IP pool as a proxy to generate pseudo-infinite IPs for web scraping and brute forcing.

George O 317 Jun 19, 2022
AWS API Gateway Websocket Asynchronous Notifications Pusher

AWS API Gateway Websocket Asynchronous Pusher Fast AWS API Gateway websockets notifications' pusher using Python AsyncIO for managing asynchronous and

OBytes 5 May 15, 2022
AWS Lambda Fast API starter application

AWS Lambda Fast API Fast API starter application compatible with API Gateway and Lambda Function. How to deploy it? Terraform AWS Lambda API is a reus

OBytes 6 Apr 20, 2022
Python Flask API service, backed by DynamoDB, running on AWS Lambda using the traditional Serverless Framework.

Serverless Framework Python Flask API service backed by DynamoDB on AWS Python Flask API service, backed by DynamoDB, running on AWS Lambda using the

Andreu Jové 0 Apr 17, 2022
ASGI support for the Tartiflette GraphQL engine

tartiflette-asgi is a wrapper that provides ASGI support for the Tartiflette Python GraphQL engine. It is ideal for serving a GraphQL API over HTTP, o

tartiflette 99 May 31, 2022
ASGI support for the Tartiflette GraphQL engine

tartiflette-asgi is a wrapper that provides ASGI support for the Tartiflette Python GraphQL engine. It is ideal for serving a GraphQL API over HTTP, o

tartiflette 99 May 31, 2022
Drop-in MessagePack support for ASGI applications and frameworks

msgpack-asgi msgpack-asgi allows you to add automatic MessagePack content negotiation to ASGI applications (Starlette, FastAPI, Quart, etc.), with a s

Florimond Manca 102 Jun 20, 2022
An AWS Pentesting tool that lets you use one-liner commands to backdoor an AWS account's resources with a rogue AWS account - or share the resources with the entire internet 😈

An AWS Pentesting tool that lets you use one-liner commands to backdoor an AWS account's resources with a rogue AWS account - or share the resources with the entire internet ??

Brandon Galbraith 276 Mar 3, 2021
Automated AWS account hardening with AWS Control Tower and AWS Step Functions

Automate activities in Control Tower provisioned AWS accounts Table of contents Introduction Architecture Prerequisites Tools and services Usage Clean

AWS Samples 12 Jun 16, 2022
AWS Interactive CLI - Allows you to execute a complex AWS commands by chaining one or more other AWS CLI dependency

AWS Interactive CLI - Allows you to execute a complex AWS commands by chaining one or more other AWS CLI dependency

Rafael Torres 2 Dec 10, 2021
Jenkins-AWS-CICD - Implement Jenkins CI/CD with AWS CodeBuild and AWS CodeDeploy, build a python flask web application.

Jenkins-AWS-CICD - Implement Jenkins CI/CD with AWS CodeBuild and AWS CodeDeploy, build a python flask web application.

Ning 1 Jan 1, 2022
Implement backup and recovery with AWS Backup across your AWS Organizations using a CI/CD pipeline (AWS CodePipeline).

Backup and Recovery with AWS Backup This repository provides you with a management and deployment solution for implementing Backup and Recovery with A

AWS Samples 3 Mar 5, 2022
A toolkit for developing and deploying serverless Python code in AWS Lambda.

Python-lambda is a toolset for developing and deploying serverless Python code in AWS Lambda. A call for contributors With python-lambda and pytube bo

Nick Ficano 1.4k Jun 15, 2022
Criando Lambda Functions para Ingerir Dados de APIs com AWS CDK

LIVE001 - AWS Lambda para Ingerir Dados de APIs Fazer o deploy de uma função lambda com infraestrutura como código Lambda vai numa API externa e extra

Andre Sionek 11 Mar 24, 2022