Amazon Web Services ブログ

Category: AWS Lambda

Lambda@Edge – エッジで HTTP リクエストを”賢く”処理する

昨年、Lambda@Edge のプレビューをアナウンスし、お客様に近いロケーションでHTTPリクエストを”賢く”処理する方法を説明しました。プレビューに応募しアクセスを許可された開発者は Lambda@Edge を有効に活用し、非常に有用な多くのフィードバックをいただきました。プレビュー中に HTTP レスポンスの生成、CloudWatch Logs のサポートを追加し、フィードバックに基いてロードマップを更新しました。 一般提供の開始 本日、 Lambda@Edge の一般提供を開始できることを嬉しく思います。次のように利用できます: A/B テストを行うために cookie を検査し、 URL を書き換える ユーザーエージェントヘッダに基づいて、特別なオブジェクトを返す オリジンにリクエストを許可する前に、特定のヘッダを検索することでアクセスコントロールを実装する ヘッダを追加、削除または変更して様々なキャッシュ済オブジェクトに誘導する HTTP レスポンスを生成する 古い URL 形式のサポート ヘッダや URL を変更または簡略化して、キャッシュ使用率を改善する 他のインターネットリソースへ HTTP リクエストを行い、その結果を使用してレスポンスをカスタマイズする

Read More

コンテナやサーバレスアプリのデプロイツールとしてのAWS CloudFormation

SA岩永です。AWS上にシステムを構築する際に、アプリケーションのデプロイをどのように行うか?については多様なやり方が考えられますが、今日はを使ったデプロイをご紹介したいと思います。CloudFormationはインフラ構築のツールとして考えられている方も多いと思いますが、最近は特にやといったComputeサービスへのアプリケーションデプロイツールとしての活用が進んでいます。AWSのリソースはやSDK等での操作が可能なので自作のツール等を使われるのはもちろん1つの選択肢ですが、もしCloudFormationを検討されたことのない方は、ぜひこの投稿を参考にして頂けるとありがたいです。 デプロイツールとしてのCloudFormationのメリット 最初に結論をまとめておきます。CloudFormationを使ったデプロイには以下の様なメリットがあります。 デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能 宣言的にデプロイが定義・実行できる アプリケーションに関連する他のAWSリソースも合わせて管理可能 現在お使いのデプロイツールで、逆に上記の様な観点で困ったことのある方は、この投稿をじっくり読んで頂くと良いと思います。 デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能 例えばCLIで行う様なデプロイツールの場合、そのツール自体のインストール等が必要になりますが、CloudFormationであればブラウザからテンプレートを指定するだけでデプロイできます。CloudFormationの一番のメリットはここです。アプリケーションの構成を記述したYAML or JSONのテンプレートファイルを用意するだけで、すぐにデプロイが可能です。 CloudFormationも実態はAWSのAPIを実行しながらリソースを作成・更新しますが、CloudFormationの場合にはAPIの実行そのものをCloudFormationのサービス側でやってくれます。例えばECSのデプロイで新しいTask Definitionを作成した後でそれを指定してServiceを更新するという依存関係のある2回のAPI操作を順番に実行する必要がありますが、CloudFormationに1回命令を送るだけで後のAPI操作はCloudFormationのサービスが代わりにやってくれます。なので、デプロイが終わるまで実行プロセスが待っている必要もないですし、複数人の排他的実行も実現できますし、さらに現在の状態と過去の履歴というデータの保存までもやってくれます。 もちろん、CloudFormation自体もAWSのサービスなので、CLI/SDKでの操作は可能です。もしもデプロイをCLIで実行して終わるまで待ちたい、ということであれば、aws cloudformation deployというコマンドを使うと更新が終わるまでポーリングしながら待ってくれます。この場合に必要なものはAWS CLIのインストールのみなので、そこまでハードルの高いものではありません。 宣言的にデプロイが定義・実行できる AWSのAPIを利用しながらデプロイツールを自作する場合には、リソースの作成順序に気を払いながら、かつ途中で失敗した場合のエラーハンドリング等も考慮しつつ手続き的に実装する必要があります。これはシンプルな構成であればそこまで難しくはないのですが、対応したい機能が徐々に増えてくるとだんだんと実装が複雑化してきてしまいます。 CloudFormationで使うテンプレートは、手続きを記述するのではなく、希望する状態を宣言的に定義するものです。そのため、複雑な構成であっても簡潔さを保って記述することができますし、多くのケースで各リソース間の依存関係も自動で判断されるので、実行順序を考えて記述する必要もありません。もちろん、テンプレートにはパラメータを設定することも可能なので、例えばECSであれば新しく作成したコンテナイメージ名をパラメータにしておくと、デプロイはそのパラメータを更新するだけで済みます。 アプリケーションに関連する他のAWSリソースも合わせて管理可能 ECSやLambdaは、それ単体だけで利用するケースよりも、他のAWSのサービスも合わせて利用されることが多いと思います。例えば、のRoleは良く使われますし、データベースとしてを使ったり、ECSのコンテナへの負荷分散にを使うことは非常に多く、場合によってはアプリケーションのデプロイ時にそれらのリソースの更新も行いたいケースもあります。 CloudFormationでは他のリソースも合わせて定義して操作させられるので、そういったケースに非常に強力なツールとなります。アプリケーションと同じテンプレートで作成することもできますし、昨年リリースされたCross Stack Referenceという機能を使うと、先に作成しておいたリソースをアプリケーション側から参照するといった使い方もできます。 CloudFormationを使ったECSのデプロイ例 こちらは、ECSへの継続的デプロイメントについて紹介した以下のブログをご参照頂くのが良いです。 AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント ブログで紹介されている構成では、GitHubへのコードのpushをトリガーにして、イメージのビルドからECSのServiceの更新まで一貫したものを紹介していますが、Service更新部分はCloudFormationテンプレートを使って実施しています。また、がデプロイ方式としてCloudFormationに対応しているので、簡単に設定することが可能です。 参考のために、Task DefinitionとServiceとIAM Roleを定義するYAMLテンプレート例を貼り付けておきます。 https://github.com/awslabs/ecs-refarch-continuous-deployment/blob/master/templates/service.yaml Resources: ECSServiceRole: Type: AWS::IAM::Role Properties: Path: / AssumeRolePolicyDocument: | { “Statement”: [{ “Effect”: “Allow”, […]

Read More

AWS X-Ray で AWS Lambda をサポート

本日、 で サポート の一般提供開始を発表しました。Jeff が GA で投稿したブログですでにご存知の方もいるかと思いますが (「Jeff の GA POST (Jeff’s GA POST)」)、X-Ray は分散アプリケーションの実行やパフォーマンス動作を分析する AWS サービスです。 複数の独立したコンポーネントを異なるサービスで実行するマイクロサービスベースのアプリケーションでは、従来の問題をデバッグする方法がうまく機能しません。アプリケーションでレイテンシーを分けることで、X-Ray はエラーや処理の低下、タイムアウトを迅速に診断することができます。それでは、シンプルな Lambda ベースのアプリケーションを構築し分析する方法をお見せしながら、独自のアプリケーションで X-Ray を使用する方法をご説明します。 今すぐ開始したい場合は、関数の設定ページで追跡を有効にすれば既存の Lambda 関数で簡単に X-Ray を使い始めることができます。 または で関数の tracing-config を更新してください (必ず –function-name も忘れずに): $ aws lambda update-function-configuration –tracing-config ‘{“Mode”: “Active”}’ トレースモードをオンにすると、Lambda は関数を追跡しようとします (アップストリームサービスによって追跡されないよう明示的に指示されていない限り)。オフの状態では、アップストリームサービスによって追跡するよう明示的に指示されている場合のみ関数が追跡されます。トレーシングモードをオンにすると追跡の生成が始まり、アプリケーションとその間のコネクション (辺) におけるリソースのビジュアル表現が見られるようになります。 X-Ray デーモンは Lambda 関数のいくつかのリソースを使用することがあります。メモリ制限に近付いている場合、Lambda はメモリ不足エラーを回避するために X-Ray デーモンを終了しようとします。では、複数のサービスを使用する簡単なアプリケーションを構築して新しい統合を試してみましょう。 20 […]

Read More

AWS チャットボットチャレンジを開催 – Amazon Lex と AWS Lambda を使用した対話式でインテリジェントなチャットボットを作成

AWS 2017 サンフランシスコサミットのリリース内容やお知らせを細かくチェックしていたユーザーなら Amazon Lex サービスの一般提供が開始し、今すぐご利用いただけるようになったことをすでにご存知かもしれません。Amazon Lex は、開発者が音声やテキストを使用するアプリケーションで対話式のインターフェイス構築を可能にするフルマネージド型の AI サービスです。Lex は Amazon Alexa を使用する Amazon Echo のようなデバイスと同じディープラーニングを使用しています。Amazon Lex のリリースにより、開発者は独自のアプリケーションで違和感のないユーザーエクスペリエンスやリアルな会話のやり取りを構築できます。Amazon Lex は Slack、Facebook Messenger、Twilio SMS に対応しています。こうした人気のチャットサービスを使用し、ユーザーの音声やテキストのチャットボットを簡単に発行することができます。Amazon Lex サービスを試し、独自のアプリケーションに優れた機能を追加するには、今が絶好のチャンスです。 さて、いよいよお知らせです。 この度 AWS チャットボットチャレンジを開催することになりました! AWS チャットボットチャレンジは、問題を解決したり今後のユーザーに向けた付加価値を追加する、他に例のないユニークなチャットボットを構築するチャンスです。AWS チャットボットチャレンジはアマゾン ウェブ サービスと Slack の協力により実現しました。 チャレンジ このチャレンジに参加する開発者は、Amazon Lex を使用して自然な対話式のチャットボットを構築し、バックエンドでロジックプロセスやデータプロセスを実行するために AWS Lambda と Lex の統合を利用することになります。対象となるボットは新しいものでも既存のものでも構いませんが、既存のボットの場合はこのチャレンジのエントリー期間中に Amazon Lex と AWS Lambda を使用できるように更新する必要があります。 ソリューション構築時の制限は、あなたの想像力のみです。それでは、以下にボット作成やデプロイにおける創作力をサポートするアドバイスをいくつかご紹介します。チャットボットをよりユニークにするためのアドバイスについては次をご覧ください。 Slack、Facebook […]

Read More

Amazon AppStream 2.0でデスクトップアプリケーションのストリームをスケールする

Deepak Sury, Principal Product Manager – Amazon AppStream 2.0 デスクトップアプリケーションを書き換えることなくWebブラウザにストリーミングしたいですか?Amazon AppStream 2.0はフルマネージドの、セキュアなアプリケーションストリーミングサービスです。このサービスでなにができるかを知るためのかんたんな方法はエンドユーザーエクスペリエンスを無料で試してみることです。 この記事では、AppStream 2.0環境をスケールさせて、コストを最適化する方法について解説します。さらにセットアップとモニタリングについていくつか付け加えます。 AppStream 2.0 ワークフロー Image Builderを使用して自分のアプリケーションをAppStream 2.0にインポートします。Image BuilderでAWS Management Consoleからデスクトップエクスペリエンスに接続して、自分のアプリをインストールしてテストすることができます。そして、Image Builderのスナップショットとしてイメージを作成します。 アプリケーションをふくむイメージを作成したあと、インスタンスタイプを選択してストリーミングインスタンスのフリートを起動します。フリートのそれぞれのインスタンスは1ユーザーだけで使用され、フリートで使用されるインスタンスタイプがアプリケーションパフォーマンスによる必要と適合するようにします。最後に、フリートをスタックにアタッチしてユーザーアクセスをセットアップします。以下の図はワークフローのなかでのそれぞれのリソースの役割を示しています。 図1: AppStream 2.0のワークフローを記述 AppStream 2.0のセットアップ 使いはじめるためには、コンソールのクイックリンクからサンプルのAppStream 2.0スタックをセットアップします。このサンプルでは、スタックにds-sampleという名前を付け、サンプルイメージを選択して、stream.standard.mediumインスタンスタイプを選んでいます。セットアップしたリソースはAWSコンソールまたは、以下のようにdescribe-stacksやdescribe-fleetsを使用して確認することができます: 図2: AppStream 2.0スタックの確認 図3: AppStream 2.0フリートの確認 ストリーミング環境へのユーザーアクセスをセットアップするには、既存のSAML 2.0準拠のディレクトリを使用することができます。ユーザーは既存の認証情報を使用してログインすることができます。別のやり方として、クイックにストリーミング接続をテスト、または自分のWebサイトからストリーミングセッションをスタートするには、ストリーミングURLを作成することができます。コンソールで、Stacks、Actions、Create URLを選択するか、以下のようにcreate-streaming-urlを呼び出します: 図4: ストリーミングURLの作成 ブラウザにストリーミングURLをペーストして、表示されたアプリケーションを開くことができます。 これでサンプル環境のセットアップができましたので、スケーリングに移りましょう。 AppStream 2.0のスケーリングとコスト最適化 インスタントオンのストリーミング接続を提供するために、AppStream 2.0フリートのインスタンスは常時稼働しています。稼働中のインスタンスに課金され、それぞれの稼働中のインスタンスは同時に1ユーザーのみを受け付けます。コストを最適化するには、インスタンスの稼働台数を同時にアプリをストリーミングしたいユーザー数にあわせます。このセクションではそのための3つのオプションを紹介していきます: フリートのオートスケーリング スケジュールをベースにした固定フリート スケジュールによるフリートのオートスケーリング フリートのオートスケーリング インスタンスの稼働台数を動的に更新するには、フリートのオートスケーリングを使用することができます。この機能はフリートのサイズを自動的に最小値と最大値の間でオンデマンドにスケールさせることができます。これはコンスタントにユーザーの需要が変動し、需要に応じてフリートを自動的にスケールさせたい場合に便利です。スケーリングポリシーのセットアップと管理の方法については、Fleet Auto […]

Read More

AWS のサイトですか?AWS Lambda を使用したドメインの識別

以下のゲスト投稿で、私の同僚である Tim Bray は IsItOnAWS.com を構築した方法について説明しています。このサイトは、AWS の IP アドレスレンジのリストと Tim が記述した Lambda 関数を使用して、お気に入りのウェブサイトが AWS で実行されているかどうかを調べることを目的としています。 AWS のサイトですか? クリスマスの時期に遊び半分でプログラミングをしていたら、おもしろい Lambda 関数ができました。きっと気に入ってもらえると思います。指定したドメイン名 (または IP アドレス) (IPv6 でも可能) が、公表されている AWS IP アドレスレンジ に含まれているかどうかを調べてくれます。IsItOnAWS.com で実際に試してみることができます。構築の過程では、1 つの Lambda 関数で別の Lambda 関数を作成しています。JSON 形式の IPv4 および IPv6 CIDR で提供されているレンジのリストはここです。説明書はここで、Jeff Barr のブログ もあります。以下は、JSON 形式の IP レンジの例です。 { “syncToken”: “1486776130”, “createDate”: “2017-02-11-01-22-10”, “prefixes”: [ […]

Read More

AWS のサイトですか? AWS Lambda を使用したドメインの識別

以下のゲスト投稿で、私の同僚である Tim Bray は IsItOnAWS.com を構築した方法について説明しています。このサイトは、AWS の IP アドレスレンジのリストと Tim が記述した 関数を使用して、お気に入りのウェブサイトが AWS で実行されているかどうかを調べることを目的としています。 AWS のサイトですか? クリスマスの時期に遊び半分でプログラミングをしていたら、おもしろい Lambda 関数ができました。きっと気に入ってもらえると思います。指定したドメイン名 (または IP アドレス) (IPv6 でも可能) が、公表されている AWS IP アドレスレンジ に含まれているかどうかを調べてくれます。IsItOnAWS.com で実際に試してみることができます。構築の過程では、1 つの Lambda 関数で別の Lambda 関数を作成しています。JSON 形式の IPv4 および IPv6 CIDR で提供されているレンジのリストはここです。説明書はここで、Jeff Barr のブログ もあります。以下は、JSON 形式の IP レンジの例です。 { “syncToken”: “1486776130”, “createDate”: “2017-02-11-01-22-10”, “prefixes”: [ { […]

Read More

Amazon ECS におけるコンテナ インスタンス ドレイニングの自動化方法

同僚のMadhuri Periが素晴らしい記事を書いてくれました。AutoScalingグループのクラスタをスケールダウンする際にインスタンスからタスクを事前に削除するために、コンテナ インスタンス ドレイニングを利用する方法です。 —– Amazon ECSクラスタでは、クラスタからインスタンスを削除する必要があるタイミングというのがいくつかあります。例えば、システムを更新するとき、Dockerデーモンを更新するとき、あるいはクラスタのサイズをスケールダウンするときなどです。コンテナ インスタンス ドレイニング機能によって、クラスタ上のタスクに影響を与えることなく、コンテナインスタンスを削除することができます。この機能により、コンテナインスタンスがDRAINING状態である間はそのインスタンスに対して新しいタスクの配置がスケジュールされないようになり、利用可能なリソースがあればサービスがタスクをクラスタ上の他のコンテナインスタンスに移動してくれ、インスタンスを削除する前にタスクの移動が成功したことを待機できるようになります。 コンテナインスタンスの状態は、手動でDRAININGに変更することが可能です。しかしこの記事では、これらのプロセスを自動化するためにAutoScalingグループとAWS Lambdaを利用してコンテナ インスタンス ドレイニングを行う方法を説明します。 Amazon ECS オーバービュー Amazon ECSはコンテナ管理サービスです。クラスタやEC2インスタンスの論理グループ上でDockerコンテナの実行、停止、そして管理を容易にしてくれます。ECSを使ってタスクを実行するとき、タスクはクラスタに配置されます。Amazon ECSは指定されたレジストリからコンテナイメージをダウンロードし、そしてそのイメージをクラスタ内のコンテナインスタンス上で実行します。 コンテナ インスタンス ドレイニングの状態を扱う AutoScalingグループはライフサイクルフックをサポートしています。ライフサイクルフックは、インスタンスの起動や削除の前に独自の処理を完了するために呼び出されます。今回の例では、ライフサイクルフックは、2つの処理を実行するLambdaファンクションを呼び出します。 ECSコンテナインスタンスの状態をDRAININGに変更します。 コンテナインスタンス上にタスクが1つも残っていないことを確認します。もしドレイニング中のタスクがまだ存在する場合は、Lambdaファンクションを再度呼び出すためにSNSにメッセージを送信します。 コンテナインスタンス上で実行中のタスクがなくなるか、あるいはライフサイクルフックのハートビートタイムアウト(サンプルのCloudFormationテンプレートではTTL15分に設定)に達するか、どちらかの状態になるまでLambdaによってステップ2が繰り返されます。その後、制御はオートスケーリングのライフサイクルフックに戻され、そのインスタンスは削除されます。このプロセスを次の図に示します。 試してみましょう! この記事で説明した一連のリソースをセットアップするためにCloudFormationテンプレートを使用します。このCloudFormationテンプレートを使用するには、あなたのアカウントのS3バケットにLambdaデプロイメントパッケージをアップロードする必要があります。このテンプレートは次のリソースを作成します。 VPCと関連するネットワーク要素(サブネット、セキュリティグループ、ルートテーブルなど。) ECSクラスタ、ECSサービス、そしてサンプルのECSタスク定義 削除のライフサイクルフックと2つのEC2インスタンスが設定されたAutoScalingグループ Lambdaファンクション SNSトピック Lambdaを実行するために必要なIAMロール CloudFormationスタックを作成し、インスタンスの終了イベントをトリガーすることによってどのようにこのスタックが機能するのか見ていきます。 Amazon EC2のコンソールにおいて、AutoScalingグループを選択し、CloudFormationによって作成されたAutoScalingグループの名前(CloudFormationテンプレートのリソースのセクションから)を選択します。 操作、編集を選択し、インスタンスの希望の数を “1” に減らすようにサービスを更新します。これによって、2つのインスタンスのどちらか一方で終了プロセスが開始されます。 AutoScalingグループのインスタンスタブを選択します。1つのインスタンスのライフサイクルの状態が “Terminating:Wait” という値を示すはずです。 この状態になると、ライフサイクルフックが発火してSNSにメッセージが送信されます。そして、SNSメッセージトリガーに反応してLambdaファンクションが実行されます。 Lambdaファンクションによって、ECSコンテナインスタンスの状態がDRAININGに変更されます。その後、ECSサービススケジューラによってこのインスタンス上のタスクは停止され、利用可能なインスタンス上でタスクが起動されます。 ECSのコンソールに移動すれば、コンテナインスタンスの状態がDRAININGになっていることを確認できます。 タスクが全て完了すると、AutoScalingグループのアクティビティ履歴でEC2インスタンスの削除を確認できます。 どのように動作しているか 少しLambdaファンクションの内部的な動作を見てみましょう。ファンクションはまず最初に、受け取ったイベントのLifecycleTransitionの値が autoscaling:EC2_INSTANCE_TERMINATING にマッチするかをチェックします。 # もし受け取ったイベントがインスタンス終了中ならば・・・ if ‘LifecycleTransition’ […]

Read More

AWS Lambda – 2016 年を振り返って

2016 年は AWS Lambda、Amazon API Gateway、そして、サーバーレスコンピューティングテクノロジーにとって、控えめに言ってもすばらしい年となりました。もしかすると、AWS Lambda および Amazon API Gateway でのサーバーレスコンピューティングについて耳にしたことがない方がいらっしゃるかもしれませんので、これらのすばらしいサービスについてご紹介したいと思います。AWS Lambda を使用すると、サーバーをプロビジョニングまたは管理しなくてもコードを実行できます。このイベント駆動型のサーバーレスコンピューティングサービスにより、開発者は、ほぼすべての種類のアプリケーションまたはバックエンドで機能を簡単にクラウドへ移行できます。Amazon API Gateway は非常にスケーラブルで、信頼性が高く、堅牢な API を大規模にすばやく構築するのに役立ち、作成した API の維持およびモニタリングの機能も提供します。2016 年のサーバーレスの勢いの締めくくりとして、AWS チームは re:Invent でサーバーレスソリューションの構築をさらに簡単にする強力なサービス機能を発表しました。その機能には次のものがあります。 AWS Greengrass: Lambda および AWS IoT を使用して、接続された IoT デバイスのローカルでのコンピューティング、メッセージング、データのキャッシングを実行します。https://aws.amazon.com/blogs/aws/aws-greengrass-ubiquitous-real-world-computing/ Lambda@Edge Preview: グローバル AWS エッジロケーションでコードを実行でき、Amazon CloudFront のリクエストに応じてトリガーされることで、エンドユーザーのネットワークレイテンシーを削減できる Lambda の新しい機能です。https://aws.amazon.com/blogs/aws/coming-soon-lambda-at-the-edge/ AWS Batch Preview: 今後予定されているバッチジョブとしての Lambda 統合を含む AWS コンピューティングサービスにおけるワークロードの計画、スケジューリング、実行のコンピューティング用バッチです。https://aws.amazon.com/blogs/aws/aws-batch-run-batch-computing-jobs-on-aws/ AWS X-Ray: マイクロサービスアーキテクチャを使用してビルドされたもの、Java、Node.js、.NET で記述されたもの、EC2、ECS、AWS […]

Read More

AWS LambdaのC#サポートの発表

本日、AWS Lambdaのサポート言語としてC#を発表しました。新しいオープンソースの.NET Core 1.0ランタイムを使用すると、さまざまな一般的な.NETツールからC#コードをAWS Lambdaに簡単に公開できます。 .NET開発者は、C#言語と使い慣れた.NETツールを使用して、Lambda関数とサーバーレス アプリケーションを作成できます。 Visual Studio、Yeoman、およびdotnet CLIにおけるツール サポートによって、C#で記述された個々のLambda関数またはサーバーレスアプリケーション全体をLambdaおよび Amazon API Gatewayに簡単に展開できます。 LambdaはAWSサーバーレスプラットフォームの中核です。もともと2015年に発売されたLambdaでは、インフラストラクチャやスケーリングを心配することなく、Node.js、Python、およびJavaコードをAWSに展開することができます。これにより、開発者はアプリケーションのビジネスロジックに集中でき、インフラストラクチャの維持と拡張に時間を費やす必要がありません。今日まで、.NET開発者はこのモデルを利用することができませんでした。サポートされている言語のリストにC#を追加し、サーバーレスアプリケーションを作成すためにLambdaとAPIゲートウェイを利用する新しいカテゴリの開発者ができたことを嬉しく思っています。   C#でのLambda 単純なC#ラムダ関数を見てください。 既にNode.js、Python、JavaでLambdaを使っていたなら、これはよく分かるはずです: using System; using System.IO; using System.Text; using Amazon.Lambda.Core; using Amazon.Lambda.DynamoDBEvents; using Amazon.Lambda.Serialization.Json; namespace DynamoDBStreams { public class DdbSample { private static readonly JsonSerializer _jsonSerializer = new JsonSerializer(); [LambdaSerializer(typeof(JsonSerializer))] public void ProcessDynamoEvent(DynamoDBEvent dynamoEvent) { Console.WriteLine($”Beginning to process {dynamoEvent.Records.Count} […]

Read More