Amazon Web Services ブログ

Tag: Serverless

サーバーレス LAMP スタック – Part 3: Webサーバーの置き換え

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 この投稿では、Web サーバーを使用せずにサーバーレス PHP アプリケーションを構築する方法を学びます。 この投稿の後半で、bref および Serverless Visually Explained の作成者である Matthieu Napoli が FastCGI Process Manager の実装を Lambda 関数内で使うことでそれを可能にする方法を説明しています。Bref は、PHP 用のオープンソースのランタイム Lambda レイヤーです。 また、プライベート Amazon S3 バケットから静的アセットを安全に提供およびキャッシュするように Amazon CloudFront を構成する方法を示します。動的リクエストは、その後 Amazon API Gateway にルーティングされ、単一の AWS Lambda 関数にルーティングされます。 これらのサービスを組み合わせることで、PHP アプリケーション用の従来の Web サーバーを置き換えることができます。 サンプルコードについては、この GitHubリポジトリ にアクセスしてください。 サーバーレス LAMP スタックアーキテクチャについては、この投稿で説明しています。Web アプリケーションは2つのコンポーネント(静的アセットと動的コンテンツを生成するバックエンドアプリケーション)に分割されます。Lambda […]

Read More

サーバーレス LAMP スタック – Part 2: リレーショナルデータベース

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 この投稿では、サーバーレスアプリケーションで Amazon Aurora MySQLリレーショナルデータベースを使用する方法を学びます。Amazon RDS Proxy を使用してデータベースへの接続をプールおよび共有する方法と、構成を選択する方法を示します。この投稿のコード例は PHP で記述されており、この GitHubリポジトリにあります。なお、この概念自体は、AWS Lambda でサポートされている他のランタイム言語にも適用できますので、PHP に限定しない内容としてお読みいただけます。 サーバーレス LAMP スタック このサーバーレス LAMP スタックアーキテクチャについては、この記事で説明しています。このアーキテクチャでは、PHP Lambda 関数を使用して、Amazon Aurora MySQL データベースの読み取りと書き込みを行います。 Amazon Aurora は、MySQL および PostgreSQL データベースに高いパフォーマンスと可用性を提供します。基盤となるストレージは、最大64 テビバイト(TiB)まで需要に応じて自動的に拡張されます。 Amazon Aurora DB インスタンスは、パブリックアクセスを防止するために仮想プライベートクラウド(VPC)内に作成されます。 Lambda 関数から Aurora データベースインスタンスに接続するには、同じ VPC にアクセスするようにその Lambda 関数を設定する必要があります。 RDS データベースに直接接続すると、データベースのメモリ不足が発生する可能性があります。これは、データベース接続の急増、または高速で開閉する多数の接続が原因です。これにより、クエリが遅くなり、アプリケーションのスケーラビリティが制限される可能性があります。この問題を解決するために、Amazon RDS Proxy が実装されました。 […]

Read More

新しいサーバーレス LAMP スタック – Part 1: 概要紹介

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 これは、PHP 開発者向けの投稿シリーズの第一弾です。このシリーズでは、PHP でサーバーレステクノロジーを使用する方法を説明します。サーバーレスアプリケーションを構築するために利用できるツール、フレームワーク、戦略や、なぜ今始めるべきかについて説明します。 今後の投稿では、Laravel や Symfony などの PHP フレームワークとともに構築された Web アプリケーションに AWS Lambdaを使用する方法を示します。Lambda を Web ホスティング機能の代替として使用することから、分離されたイベント駆動型のアプローチに移行する方法を示します。最小限のスコープの複数の Lambda 関数を他のサーバーレスサービスと組み合わせて、パフォーマンスの高いスケーラブルなマイクロサービスを作成する方法について説明します。 まずは、カスタムランタイム API を使用して Lambda で PHP を使用する方法を学びます。サンプルコードについては、この GitHubリポジトリにアクセスしてください。 サーバーレスLAMPスタック 従来の PHP アプリケーションの課題 スケーラビリティは、従来の LAMP スタックの伝統的な課題です。スケーラブルなアプリケーションとは、非常に多様なレベルのトラフィックを処理できるアプリケーションです。PHP アプリケーションは、多くの場合、必要に応じて Web サーバーを追加することにより、水平方向にスケーリングされます。これは、リクエストをさまざまな Web サーバーに転送するロードバランサーを介して管理されます。サーバーを追加するたびに、ネットワーキング、管理、ストレージ容量、バックアップと復元のシステム、およびアセット管理インベントリの更新に関するオーバーヘッドが増加します。さらに、水平方向にスケーリングされた各サーバーは独立して実行されます。これにより、構成の同期が困難になる可能性があります。 従来の LAMP スタックアプリケーションによる水平スケーリング 各サーバーには独自のディスクとファイルシステムがあり、開発者がユーザーセッションを処理するメカニズムを追加する必要があることが多いため、新しいストレージの課題が発生します。 サーバーレステクノロジーを使用すれば、開発者のためにスケーラビリティが(自動で)管理されます。トラフィックが急増した場合、サービスが拡張され、追加のサーバーを展開する必要なく、需要に応えます。これにより、アプリケーションをプロトタイプから本番環境にすばやく移行できます。 サーバーレス LAMP アーキテクチャ 従来の Web […]

Read More

VPC設定にAWS Lambda IAM条件キーを使用する

本投稿は、Senior Developer Advocate, Julian Woodの寄稿によるものです。 AWS Identity and Access Management(IAM)条件キーを使用して、AWS Lambda 関数のAmazon Virtual Private Cloud(VPC)設定を制御できるようになりました 。 IAM条件キーを使用すると、IAMポリシーステートメントが適用される条件をさらに絞り込むことができます。関数を作成および更新する権限を付与するときに、IAMポリシーで新しい条件キーを使用できます。 VPC設定の3つの新しい条件キーは、lambda:VpcIds、lambda:SubnetIds、そして、 lambda:SecurityGroupIds です。キーにより、ユーザーが1つ以上の許可されたVPC、サブネット、およびセキュリティグループに接続された関数のみをデプロイできるようにすることができます。ユーザーが許可されていないVPC設定で関数を作成または更新しようとすると、Lambdaは操作を拒否します。 LambdaとVPCの関係を理解する Lambdaの実行環境はすべて、Lambdaサービスが所有するVPC内で動作します。 Lambda関数は、Lambda API を呼び出すことによってのみ呼び出すことができます。関数が実行される実行環境への直接のネットワークアクセスはありません。 非VPC接続のLambda関数 Lambda関数がカスタマーアカウントのVPCに接続するように構成されていない場合、関数はパブリックインターネットで利用可能なすべてのリソースにアクセスできます。これには、他のAWSサービス、APIのHTTPSエンドポイント、またはAWS外のサービスとエンドポイントが含まれます。関数はVPC内のプライベートリソースに直接には接続できません。 VPC接続のLambda関数 Lambda関数を設定して、カスタマーアカウントのVPC内のプライベートサブネットに接続できます。 Lambda関数がカスタマーアカウントVPCに接続するように設定されている場合も、そのLambda関数は引き続きAWS LambdaサービスVPC内で実行されます。この場合、Lambda関数はすべてのネットワークトラフィックをカスタマーアカウント内VPC経由で送信し、このカスタマーVPCのネットワーク制御に従います。これらのコントロールを使用して、セキュリティグループ とネットワークACL を設定し関数が接続可能な範囲を制御できます。Lambda関数からの送信トラフィックは独自のネットワークアドレス空間から送信され、VPCフローログ を使用してネットワークを可視化できます。 パブリックインターネットを含むネットワークロケーションへのアクセスを制限できます。 カスタマーアカウント内のVPCに接続されたLambda関数は、デフォルトではインターネットにアクセスできません。関数にインターネットへのアクセスを許可するには、送信トラフィックをパブリックサブネットのネットワークアドレス変換(NAT)ゲートウェイ にルーティングできます。 Lambda関数を設定してカスタマーアカウント内のVPCに接続すると、AWS Hyperplane によって管理される共有Elastic Network Interface(ENI)が使用されます。この接続により、VPC-to-VPC NATが作成され、クロスアカウントに接続されます。これにより、Lambda関数からプライベートリソースへのネットワークアクセスが可能になります。 AWS Lambda サービスVPCからVPC-to-VPT NATを利用しカスタマーVPCへ Hyperplane ENIは、Lambdaサービスが制御し、カスタマーアカウント内のVPCに存在するマネージドネットワークインターフェースリソースです。複数の実行環境がENIを共有して、カスタマーアカウントのVPC内のリソースに安全にアクセスします。カスタマー側からのLambda実行環境(LambdaサービスVPC内)への直接のネットワークアクセスは出来ないことにご注意ください。 ENIはいつ作られるのか? Lambda関数が作成されるか、そのVPC設定が更新されると、ネットワークインターフェイスの作成が行われます。関数が呼び出されると、実行環境は事前に作成されたネットワークインターフェースを使用し、そのインターフェースへのネットワークトンネルをすばやく確立します。これにより、コールドスタート時のネットワークインターフェースの作成と接続に関連していたレイテンシが削減 されています。 どのくらいの数のENIが必要か? ネットワークインターフェイスは実行環境全体で共有されるため、通常、関数ごとに必要なネットワークインターフェイスはほんの一握りです。アカウント内の関数全体で一意のセキュリティグループとサブネットのペアごとに、個別のネットワークインターフェイスが必要です。同じアカウントの複数の関数が同じセキュリティグループとサブネットのペアを使用する場合、同じネットワークインターフェイスを再利用します。このように、複数の関数を備えているが、ネットワークとセキュリティの構成が同じである単一のアプリケーションは、既存のインターフェース構成の恩恵を受けることができます。 関数のスケーリングは、ネットワークインターフェイスの数に直接関係しなくなりました。Hyperplane […]

Read More

AWS Lambda関数の状態の追跡

本投稿は、AWS Lambda の Senior Developer Advocate, Chris Munns の寄稿によるものです。 AWS Lambda関数は、AWS Identity and Access Management(IAM)ロールやAmazon Virtual Private Cloud(Amazon VPC)、ネットワークインターフェイスなど、正常に実行するために他のAWSサービスのリソースを必要とすることがよくあります。関数を作成または更新すると、Lambdaはユーザーに代わって、関数の実行を可能にするのに必要なリソースをプロビジョニングします。ほとんどの場合、このプロセスは非常に高速で、関数を呼び出したり変更する準備はすぐにできます。ただし、この種のアクションで時間がかかってしまうこともあります。 リソースが作成または更新されているときの関数の現在の「状態」をより把握できるように、AWS LambdaのLambda APIアクションによって返される関数情報にいくつかの追加属性が含まれるようになりました。この変更は、関数の呼び出し方法やコードの実行には影響しません。 この投稿では、Lambda関数が到達する可能性のある多様な状態、それらに遷移する条件、およびLambdaサービスが関数をさまざまな状態に遷移させる方法について説明します。詳細については、AWS Lambdaのドキュメント、Lambda APIを使用した関数の状態のモニタリング をご覧ください。 Lambda関数の状態について Lambda関数が通過する主なライフサイクルは2つあります。これは、Lambda関数が初めて作成されるのか、それともすでに存在し更新されるのかによって異なります。フローに入る前に、関数の状態について説明します。 Pending Pendingは、すべての関数が作成されたときに通過する最初の状態です。Pending中にLambdaはリソースを作成または設定しようとします。関数はアクティブ状態のときにのみ呼び出すことができるため、関数を操作する呼び出しやその他のAPIアクションは失敗します。関数作成直後に関数の呼び出しや更新をするように構築された自動化処理は、関数がPendingからActiveに移行したかどうかを最初に確認するように実装する必要があります。 Active 関数の最初の作成中にリソースの構成またはプロビジョニングが完了した後、Activeになります。関数は、Active状態でのみ呼び出すことができます。 関数の更新中、状態はActiveに指定されたままですが、Activeな関数の更新の状態を表すLastUpdateStatusと呼ばれる別の属性があります。更新中、呼び出しは、更新操作が正常に完了するまで関数の以前のコードと設定内容にて実行され、更新完了後、新しいコードと設定が使用されます。 Failed Failed状態は、リソースの設定またはプロビジョニングのいずれかが失敗したことを表す状態です。 Inactive Lambdaサービスが設定されたリソースを回収するのに十分な時間アイドルになっている関数は、Inactive状態に移行します。Inactive状態の関数を呼び出すと、失敗し、それらのリソースが再作成されるまで関数はPending状態に設定されます。リソースの再作成に失敗した場合、関数はInactive状態に戻ります。 すべての状態について、StateReasonとStateReasonCodeの2つの属性が設定されています。どちらも問題のトラブルシューティングのために存在し、現在の状態に関する詳細情報を提供します。 LastUpdateStatusについて InProgress InProgress状態は、既存の関数で更新が行われていることを示します。関数がInProgress状態にある間、関数呼び出しは関数の以前のコードと設定にルーティングされます。 Successful Successful 状態は、関数の更新が完了したことを示します。関数が更新されると、次の更新までこの状態がセットされたままになります。 Failed Failed状態は、関数の更新が失敗したことを示します。変更は中止され、関数の以前のコードと設定がActive状態のままになり使用可能となります。 すべてのLastUpdateStatus値には、LastUpdateStatusReasonとLastUpdateStatusReasonCodeの2つの属性が設定されています。これらは、更新に関する問題のトラブルシューティングに役立ちます。 関数状態のライフサイクル ある状態から別の状態への関数状態の遷移は、関数に対して実行されるアクションに完全に依存しています。関数の状態から状態に手動で移動する方法はありません。 関数の状態のライフサイクル   すべての関数について、主要な状態のライフサイクルは次のようになります。 作成時に、関数はPending状態になります 必要なリソースが正常に作成されると、Active状態に移行します リソースまたは関数の作成が何らかの理由で失敗すると、Failed状態に移行します […]

Read More
Lambda Thumb

新機能 – Lambda関数の共有ファイルシステム – Amazon Elastic File System for AWS Lambda

本投稿は AWS の Chief Evangelist (EMEA)であるDanilo Pocciaによる寄稿です。 AWS Lambda関数がAmazon Elastic File System(EFS)をマウントできるようになったことを非常に嬉しく思います。EFSは、高可用性と耐久性のために複数のアベイラビリティーゾーン(AZ)にまたがってデータを格納するスケーラブルでエラスティックなNFSファイルシステムです。このように、使い慣れたファイルシステムインターフェイスを使用して、関数単体、および複数のLambda関数のすべての同時実行環境にわたってデータを保存および共有できます。 EFSは、強力な整合性やファイルロックなどの完全なファイルシステムアクセスセマンティクスをサポートしています。 Lambda関数を使用してEFSファイルシステムを接続するには、EFSアクセスポイントを使用します。これは、ファイルシステムへのアクセス時に使用するオペレーティングシステムのユーザーとグループを含むEFSファイルシステムへのアプリケーション固有のエントリポイント、ファイルシステムのアクセス許可、およびファイルシステム内の特定のパスへのアクセスを制限できます。これにより、ファイルシステム構成をアプリケーションコードから切り離しておくことができます。 同一のアクセスポイント、または異なるアクセスポイントを使用して、複数の関数から同じEFSファイルシステムにアクセスできます。たとえば、異なるEFSアクセスポイントを使用して、各Lambda関数はファイルシステムの異なるパスにアクセスしたり、異なるファイルシステムのアクセス許可を使用したりできます。 同じEFSをAmazon Elastic Compute Cloud(EC2)インスタンス、Amazon ECSとAWS Fargateを使用するコンテナ化されたアプリケーションや、オンプレミスサーバーと共有できます。このアプローチに従って、異なるコンピューティングアーキテクチャ(関数、コンテナ、仮想サーバー)を使用して同じファイルを処理できます。たとえば、イベントに反応するLambda関数は、コンテナで実行されているアプリケーションによって読み取られる構成ファイルを更新できます。または、Lambda関数を使用して、EC2で実行されているWebアプリケーションによってアップロードされたファイルを処理できます。 このようにすると、いくつかのユースケースではLambda関数によって実装がより容易になります。例えば: /tmpで使用可能な容量(512MB)より大きいデータを処理またはロードする。 頻繁に変更されるファイルの最新バージョンをロードする。 モデルやその他の依存関係をロードするためにストレージ容量を必要とするデータサイエンスパッケージを使用する。 呼び出し間で関数の状態を保存する(一意のファイル名またはファイルシステムロックを使用)。 大量の参照データへのアクセスを必要とするアプリケーションの構築。 レガシーアプリケーションをサーバーレスアーキテクチャに移行する。 ファイルシステムアクセス用に設計されたデータ集約型ワークロードとの相互作用。 ファイルを部分的に更新する(同時アクセス用のファイルシステムロックを使用)。 アトミック操作でファイルシステム内のディレクトリとそのすべてのコンテンツを移動する。 EFSの作成 EFSをマウントするには、Lambda関数がEFSマウントターゲットに到達できるAmazon Virtual Private Cloud(VPC)に接続されている必要があります。ここでは、簡単にするために、各AWSリージョンで自動的に作成されるデフォルトのVPC を使用しています。 Lambda関数をVPCに接続する構成にすると、ネットワーク環境の変化に伴う変更が必要になることがある点に注意してください。 Lambda関数がAmazon Simple Storage Service(S3)またはAmazon DynamoDBを使用している場合は、それらのサービスのゲートウェイVPCエンドポイントを作成する必要があります。 Lambda関数がパブリックインターネットにアクセスする必要がある場合、たとえば外部APIを呼び出す場合は、NATゲートウェイを構成する必要があります。通常、デフォルトVPCの構成は変更しません。特定の要件がある場合は、AWS Cloud Development Kitを使用してプライベートおよびパブリックサブネットで新しいVPCを作成するか、これらのAWS CloudFormationのサンプルテンプレートのいずれかを使用します。このようにすることで、ネットワークをコードとして管理できます。 EFSコンソールで、[Create file system]を選択し、default のVPCとそのサブネットが選択されていることを確認します。すべてのサブネットで、同じセキュリティグループを使用してVPC内の他のリソースへのネットワークアクセスを提供するデフォルトのセキュリティグループを使用します。 次のステップでは、ファイルシステムにNameタグを付け、他のすべてのオプションをデフォルト値のままにします。 次に、[Add access […]

Read More

高速、低コストで、より良いAPIの構築 – HTTP APIが利用可能(GA)になりました

本投稿は、Senior Developer Advocate, AWS Serverless Applications のEric Johnsonの寄稿によるものです。 2015年7月、AWSはAmazon API Gatewayを発表しました。これにより、開発者はさまざまな種類のアーキテクチャのフロントに配置して安全でスケーラブルなAPIを迅速に構築できるようになりました。それ以来、API Gatewayチームは顧客向けの新しい機能とサービスを構築し続けています。 図1: API Gateway機能追加タイムライン 2019年初頭、チームは現在のサービスを評価し、API Gatewayの次の姿がどうあるべきか計画を立てました。新しい言語と技術によるプロトタイプを作成し、RESTおよびWebSocket APIの構築から学んだ教訓を適用し、そして、顧客のフィードバックを入念に調べました。その結果として、Amazon API GatewayのHTTP APIが完成しました。これは、より高速で、より低コストで使い易くなるように、ゼロから構築されたサービスです。要するに、HTTP APIはAPIを構築するためのより良いソリューションを提供します。APIを構築していて、HTTP APIが要件に合っている場合は、HTTP APIから始めるのが良いでしょう。   より速く ほとんどのユースケースで、HTTP APIはレイテンシを最大60%削減します。開発者は、最小限のレイテンシと最大限の機能を備えたアプリケーションの構築に苦心しており、アプリケーションプロセスに関係する各サービスがレイテンシを追加する可能性があることを理解しています。 図2: すべてのサービスがレイテンシを追加   これを念頭に置いて、HTTP APIは、API Gatewayサービスのレイテンシオーバーヘッドを削減するように構築されています。リクエストとレスポンスの両方を足し合わせても、すべてのリクエストの99%(p99)でHTTP APIからの追加レイテンシが10ミリ秒未満になります。   より低コストで Amazonでは、中核となるLeadership Principles の一つとして、Frugality(倹約)があります。私たちは、費用対効果の高い方法で物事を行い、その節約がお客様に還元されることを信じています。新しいテクノロジーが利用可能になり、ほぼ5年間にわたりAPI Gatewayを運用し得た専門知識により、より効率的に実行するためにHTTP APIを構築しました。 図3: REST / HTTP APIの価格比較 us-east-1の価格設定を使用して説明します。図3は、1か月あたりの1億回、5億回、および10億回のリクエストのコスト比較を示しています。全体的に、HTTP APIは、API Gateway REST APIと比較して少なくとも71%低コストです。   よりシンプルに HTTP […]

Read More

AWS LambdaでAmazon RDS Proxyを使用する

本投稿は、Principal Solutions Architectである George Maoの寄稿によるものです。   更新 – (2020年6月30日 PDT): MySQLおよびPostgreSQL対応のAmazon RDS Proxyが一般にご利用可能になりました。 更新 – (2020年4月8日 PDT): PostgreSQL 互換の Amazon RDS Proxy (プレビュー)を発表しました。プレビューではバージョン10.11と11.5がサポートされています。 AWSサーバーレスプラットフォームは、デマンドに応じて自動的に拡張するアプリケーションを構築することができます。大量アクセスがある間、 Amazon API Gateway と AWS Lambda は負荷に応じて自動的にスケールします。 多くの場合、開発者は、Lambda関数からリレーショナルデータベースに保存されたデータにアクセスする必要が出てきます。しかし、Lambdaからデータベースへの多すぎるコネクションにより過負荷にならないようにすることは難しい場合があります。リレーショナルデータベースの最大同時接続数は、データベースのサイズによって異なります。 これは、各コネクションがデータベースサーバー上のメモリとCPUリソースを消費するためです。Lambda関数は数万の同時接続数までスケールできるため、それに対応するには、データベースはクエリを実行するだけでなく、コネクションを維持するためにより多くのリソースが必要になります。 スケーリングの詳細については、アーキテクチャブログの投稿「サーバーレスアプリを大規模に設計する方法」も参照してください。 RDSを使用したサーバーレスアーキテクチャ Lambdaは数万の同時リクエストに応じて簡単にスケールできるため、そのような状況において、この設計ではバックエンドのリレーショナルデータベースに高い負荷がかかります。通常は、リレーショナルデータベースは、Lambdaのスケーラビリティに応じた同時接続を受け入れるように設計されていません。 Amazon RDSのデータベースプロキシ 本日(2019年12月3日 PST)、Amazon RDS Proxyのプレビューを発表できることを嬉しく思います。 RDS Proxyは、アプリケーションとRDSデータベースの間の仲介役として機能します。RDS Proxyは、必要となるデータベースへのコネクションプールを確立および管理し、アプリケーションからのデータベース接続を少なく抑えます。 データベースへのSQL呼び出しを行うアプリケーションには、RDS Proxyを使用できます。ただし、サーバーレスのコンテキストでは、これによりLambda利用の体験がどのように改善されるかに焦点を当てています。RDS Proxyは、Lambda関数からデータベースに直接流れるすべてのデータベーストラフィックを処理します。 Lambda関数は、データベースインスタンスではなくRDS Proxyと対話します。RDS Proxyは、Lambda関数の同時実行によって作成された大量の同時接続をスケーリングするために必要なコネクションをプーリングします。これにより、Lambdaアプリケーションは、Lambda関数呼び出しごとに新しいコネクションを作成するのではなく、既存のコネクションを再利用できます。 RDS Proxyは自動的にスケーリングされるため、データベースインスタンスでコネクション管理に必要なメモリとCPUリソースが少なくなります。また、暖機されたコネクションプールを使用することでパフォーマンス向上にもつながります。RDS Proxyを使用すると、アイドル接続のクリーンアップとコネクションプールの管理を処理するコードが不要になります。Lambda関数コードは、より簡潔でシンプルとなり、保守性が向上します。 Amazon […]

Read More

Kinesis と DynamoDB をイベントソースにする際の AWS Lambda の新しいスケーリング管理

AWS Lambda は、Amazon Kinesis Data Streams と Amazon DynamoDB ストリームのイベントソースで利用可能な、新しいスケーリングパラメータを導入しました。Parallelization Factor は、各シャードにおける Lambda 関数呼び出しの同時実行数を増やす設定を可能にします。このパラメータは、デフォルトでは 1 です。これによって、処理されるレコードの順序を保証しながら、シャード数を過大にスケールすることなく、より高速なストリーム処理が可能になります。

Read More

Lambda@Edge デザインベストプラクティス

Lambda@Edge をより活用いただくために Lambda@Edge ベストプラクティスシリーズと題したブログを連載します。この中ではいくつかのユースケースを用いて Lambda@Edge をどのように利用すればよいか、CI/CD パイプラインにどのように組み込むべきか、ビジネスニーズに応える形で組み込まれていることを担保するためにはどのように考えればよいか等について取り上げます。 記念すべき初回は Lambda@Edge のデザインベストプラクティスについて取り上げます。いくつか一般的なユースケースをもとに関数をどのタイミングで実行するのが良いのか、それはどのような観点で選択されるべきかということについてパフォーマンス及びコスト最適化の観点から推奨構成について説明していきたいと思います。

Read More