Cloud & Server Experts

Adresy URL funkcji AWS Lambda: Wbudowane punkty końcowe HTTPS dla jednofunkcyjnych mikroserwisów

6 kwietnia 2022

Organizacje adaptują architektury mikroserwisów, aby budować niezawodne i skalowalne aplikacje przy użyciu AWS Lambda.

Aplikacje te składają się z wielu funkcji bezserwerowych (ang. serverless), które wdrażają logikę biznesową. Każda funkcja jest mapowana na punkty końcowe, metody i zasoby API przy użyciu usług takich jak Amazon API Gateway i Application Load Balancer.

Czasami jednak wystarczy prosty sposób na skonfigurowanie punktu końcowego HTTPS przed funkcją bez konieczności uczenia się, konfigurowania i obsługi dodatkowych usług poza Lambdą. Na przykład może zajść potrzeba zaimplementowania obsługi webhooka lub prostego walidatora formularzy, który działa w ramach pojedynczej funkcji Lambda.

Na początku kwietnia 2022 roku, AWS ogłosił ogólną dostępność Lambda Function URLs, nowej funkcji, która pozwala dodawać punkty końcowe HTTPS do dowolnej funkcji Lambda i opcjonalnie konfigurować nagłówki Cross-Origin Resource Sharing (CORS).

Pozwala to skupić się na tym, co ważne, podczas gdy AWS zajmie się konfiguracją i monitorowaniem wysoce dostępnej, skalowalnej i bezpiecznej usługi HTTPS.

Jak działa Lambda Function URLs

Utwórz nowy adres URL funkcji i zamapuj go na dowolną funkcję. Każdy adres URL funkcji jest globalnie unikalny i może być powiązany z aliasem funkcji lub niekwalifikowanym ARN funkcji, który niejawnie wywołuje wersję $LATEST.

Na przykład, jeśli zmapujesz adres URL funkcji na wersję $LATEST, każda aktualizacja kodu będzie natychmiast dostępna za pośrednictwem adresu URL funkcji. Z drugiej strony polecamy mapowanie adresu URL funkcji na alias, dzięki czemu można bezpiecznie wdrażać nowe wersje, przeprowadzać testy integracji, a następnie aktualizować alias, gdy będziesz gotowy. Pozwala to również na wdrożenie ważonego kierowania ruchu i bezpiecznych wdrożeń.

Funkcja Lambda Function URLs w użyciu

Możesz skonfigurować adres URL funkcji dla nowej lub istniejącej funkcji. Zobaczmy, jak zaimplementować nową funkcję do obsługi webhooka.

Tworząc nową funkcję, zaznaczamy opcję Enable function URL w Advanced Settings.

Tutaj wybieramy typ uwierzytelniania: AWS_IAM lub NONE. Nasz webhook użyje niestandardowej logiki autoryzacji opartej na podpisie podanym w nagłówkach HTTP. Dlatego wybierzemy AuthType None, co oznacza, że Lambda nie będzie sprawdzać żadnych podpisów AWS IAM Sigv4 przed wywołaniem naszej funkcji. Zamiast tego wyodrębnimy i zweryfikujemy niestandardowy nagłówek w naszym module obsługi funkcji w celu autoryzacji.

Adresy URL funkcji AWS Lambda: Wbudowane punkty końcowe HTTPS dla jednofunkcyjnych mikroserwisów

Należy pamiętać, że podczas korzystania z AuthType None, polityki oparte na zasobach naszej funkcji muszą nadal wyraźnie zezwalać na publiczny dostęp. W przeciwnym razie nieuwierzytelnione żądania zostaną odrzucone. Uprawnienia można dodawać programowo przy użyciu interfejsu API AddPermission. W takim przypadku konsola Lambda automatycznie dodaje dla nas niezbędną politykę, ponieważ rola uprawnień, której używamy, jest upoważniona do wywoływania API AddPermission na naszym koncie.

Jednym kliknięciem możemy włączyć również CORS. Domyślna konfiguracja CORS zezwala na wszystkie źródła. Następnie po utworzeniu funkcji dodamy bardziej szczegółowe opcje. Jeśli nie znasz CORS, jest to mechanizm bezpieczeństwa oparty na nagłówkach zaimplementowany przez przeglądarki, aby upewnić się, że tylko niektóre hosty mogą ładować zasoby i wywoływać interfejsy API.

Jeśli strona może korzystać z Twojego interfejsu API, musisz uwzględnić kilka nagłówków CORS, które deklarują dozwolone źródła, metody i niestandardowe nagłówki. Nowe adresy URL funkcji zadbają o to za Ciebie, więc nie musisz implementować tego wszystkiego w swoim module obsługi Lambda.

Kilka sekund później dostępny jest adres URL funkcji. Można też bez problemu znaleźć i skopiować go w konsoli Lambda.

Adresy URL funkcji AWS Lambda: Wbudowane punkty końcowe HTTPS dla jednofunkcyjnych mikroserwisów

Kod funkcji obsługującej nasz webhook w Node.js wygląda tak:

exports.handler = async (event) => {
    
    // (optional) fetch method and querystring
    const method = event.requestContext.http.method;
    const queryParam = event.queryStringParameters.myCustomParameter;
    console.log(`Received ${method} request with ${queryParam}`)
    
    // retrieve signature and payload
    const webhookSignature = event.headers.SignatureHeader;
    const webhookPayload = JSON.parse(event.body);
    
    try {
        validateSignature(webhookSignature); // throws if invalid signature
        handleEvent(webhookPayload); // throws if processing error
    } catch (error) {
        console.error(error)
        return {
            statusCode: 400,
            body: `Cannot process event: ${error}`,
        }
    }

    return {
        statusCode: 200, // default value
        body: JSON.stringify({
            received: true,
        }),
    };
};

Kod wyodrębnia kilka parametrów z nagłówków żądań, ciągu zapytania i treści. Jeśli znasz już strukturę zdarzeń udostępnianą przez API Gateway lub Application Load Balancer, powinno to wyglądać bardzo znajomo.

Po zaktualizowaniu kodu postanawiamy przetestować URL funkcji z klientem HTTP.

Na przykład, oto jak można zrobić to za pomocą curl:

$ curl "https://4iykoi7jk2kp5hhd5irhbdprn40yxest.lambda-url.us-west-2.on.aws/?myCustomParameter=squirrel"
    -X POST
    -H "SignatureHeader: XYZ"
    -H "Content-type: application/json"
    -d '{"type": "payment-succeeded"}'

Lub za pomocą skryptu Pythona:

import json
import requests

url = "https://4iykoi7jk2kp5hhd5irhbdprn40yxest.lambda-url.us-west-2.on.aws/"
headers = {'SignatureHeader': 'XYZ', 'Content-type': 'application/json'}
payload = json.dumps({'type': 'payment-succeeded'})
querystring = {'myCustomParameter': 'squirrel'}

r = requests.post(url=url, params=querystring, data=payload, headers=headers)
print(r.json())

Nie zapomnij w swoich testach ustawić Content-type żądania na application/json lub text/*, w przeciwnym razie body będzie domyślnie zakodowane w base64 i będziesz musiał je zdekodować w module obsługi Lambda.

Oczywiście w tym przypadku mówimy o webhooku, więc ta funkcja będzie otrzymywać żądania bezpośrednio z systemu zewnętrznego, z którym się integrujemy. Musimy tylko podać im adres URL funkcji publicznej i zacząć otrzymywać zdarzenia.

W tym konkretnym przypadku nie potrzebujemy żadnej konfiguracji CORS. W innych przypadkach, gdy adres URL funkcji jest wywoływany z przeglądarki, musielibyśmy skonfigurować jeszcze kilka parametrów CORS, takich jak Access-Control-Allow-Origin, Access-Control-Allow-Methods i Access-Control-Expose-Headers Możemy łatwo przeglądać i edytować te parametry CORS w konsoli Lambda lub w naszych szablonach IaC. Oto jak to wygląda w konsoli:

Adresy URL funkcji AWS Lambda: Wbudowane punkty końcowe HTTPS dla jednofunkcyjnych mikroserwisów

Należy również pamiętać, że każdy adres URL funkcji jest unikalny i mapowany na określony alias lub wersję $LATEST funkcji. Pozwala to zdefiniować wiele adresów URL dla tej samej funkcji. Na przykład możesz zdefiniować jedną do testowania wersji $LATEST podczas projektowania i jedną dla każdego etapu lub aliasu, takiego jak staging, production itd.

Wsparcie dla Infrastructure as Code (IaC)

Możesz zacząć konfigurować adresy URL funkcji Lambda bezpośrednio w szablonach IaC, korzystając z AWS CloudFormation, AWS SAM i AWS Cloud Development Kit (AWS CDK).

Na przykład, oto jak zdefiniować funkcję Lambda i jej publiczny adres URL za pomocą AWS SAM, w tym mapowanie aliasów:

WebhookFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: webhook/
      Handler: index.handler
      Runtime: nodejs14.x
      AutoPublishAlias: live
      FunctionUrlConfig:
        AuthType: NONE
        Cors:
            AllowOrigins:
                - "https://example.com"

Jeśli posiadasz istniejące funkcje Lambda w szablonach IaC, możesz zdefiniować nowy adres URL funkcji za pomocą kilku linijek kodu.

Cennik funkcji URL

Adresy URL funkcji są uwzględnione w cenie żądania Lambda i czasu trwania. Na przykład wyobraźmy sobie, że wdrażasz pojedynczą funkcję Lambda z 128 MB pamięci i średnim czasem wywołania 50 ms. Funkcja otrzymuje co miesiąc pięć milionów żądań, więc koszt wyniesie 1,00 USD za żądania i 0,53 USD za czas trwania. Łączna suma wynosi 1,53 USD miesięcznie we wschodnim regionie USA (N. Virginia).

Kiedy używać adresów URL funkcji, a kiedy Amazon API Gateway

Adresy URL funkcji najlepiej sprawdzają się w przypadkach użycia, w których należy zaimplementować mikroserwis jednofunkcyjny z publicznym endpoint’em, który nie wymaga zaawansowanych funkcji API Gateway, takich jak weryfikacja żądań, ograniczanie przepustowości, niestandardowe mechanizmy autoryzacji, niestandardowe nazwy domen, plany użytkowania lub buforowanie.

Na przykład podczas wdrażania programów obsługi webhook, walidatorów formularzy, przetwarzania płatności mobilnych, umieszczania reklam, wnioskowania uczenia maszynowego i tak dalej. Jest to również najprostszy sposób na wywołanie funkcji Lambda podczas prac badawczo-rozwojowych bez wychodzenia z konsoli Lambda lub integrowania dodatkowych usług.

Amazon API Gateway to w pełni zarządzana usługa, która ułatwia tworzenie, publikowanie, utrzymywanie, monitorowanie i zabezpieczanie interfejsów API na każdą skalę. Użyj API Gateway, aby skorzystać z takich możliwości, jak autoryzacja JWT, walidacja i transformacja żądań/odpowiedzi, plany użytkowania, wbudowana obsługa AWS WAF i tak dalej.

Dostępność

Adresy URL funkcji są obecnie ogólnie dostępne we wszystkich komercyjnych regionach AWS, w których dostępna jest funkcja Lambda, z wyjątkiem regionów AWS Chiny. Wsparcie jest również dostępne za pośrednictwem wielu partnerów AWS Lambda Partners, takich jak Datadog, Lumigo, Pulumi, Serverless Framework, Thundra, Dynatrace, Site24x7 i HashiCorp (Terraform).

Sprawdź dokumentację Lambda Function URLs.

źródło:AWS

Hostersi Sp. z o.o.

Jankowicka 7
44-200 Rybnik
Poland

NIP: 642-300-73-08
REGON: 240692928
KRS: 275333