Category: Amazon API Gateway

本投稿は、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 […]

皆さん、こんにちは！ モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー（日本語版）がAWSホワイトペーパーサイトで公開されましたので、その内容を紹介させて頂きます。このホワイトペーパーは、以前こちらのブログで紹介させて頂いたModern Application Development on AWS（英語版）の日本語版になります。   ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、「AWS モダンアプリケーション開発 – AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン」（日本語版）というタイトルの51ページのドキュメントで、 はじめに モダンアプリケーション開発 モダンアプリケーションの設計パターン AWSでのCI/CD まとめ の各章から構成されています。各章の簡単なご紹介は下記の通りです。

みなさんこんにちは！アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉です。 11月21日に「ビルシリーズ@六本木一丁目住友不動産六本木グランドタワー 第１回」を開催いたしました。今回は「初めてのサーバレスWebアプリケーションハンズオン」を実施しました。こちら「ビルシリーズとは？」とお思いの方も多いかと思いますので、開催報告と合わせてご説明いたします。 「ビルシリーズ」とは？ このイベントは、日頃AWSをご利用いただいているお客様に、AWSからの情報発信はもちろん、同じビルに拠点を構えるお客様同士の活発な意見交換と交流の場を定期的に作ることを目的としたものです（同じビルなので移動が楽！）。 今回、住友不動産六本木グランドタワーのFringe81様、BASE様、エブリー様、ディップ様で同じようなニーズがあり、このようなビル単位でのイベントを開催する運びとなりました。場所はFringe81様の素敵な大会場をお借りいたしました。Fringe81様ありがとうございました。 来月には住友不動産麻布十番ビルでも開催を予定しており、今後もこのようなビル単位で交流ができるようなイベントを開催していきたいと考えております。 当日の様子 当日は約40人のお客様にお越しいただき、イベントは終始盛り上がりを見せておりました。   まずはAWSJ 植本より、今回のビルシリーズの趣旨などを説明いたしました。   次に、AWSJ 木村より「サーバレスのご紹介 – ユースケースパターンを切り口に」というタイトルで、AWSのサーバレスプラットフォームについてご紹介いたしました。   続けてAWSJ 木村より「初めてのWebアプリケーションハンズオン」を実施いたしました。   ハンズオンの終了後、ご参加いただいた皆様と共に、簡単な懇親会を開催いたしました。   今回、AWSJより、アカウントマネージャー植本、藤田、細木、ソリューションアーキテクト上原、石見、小宮、木村がビルシリーズをサポートいたしました。こちらはソリューションアーキテクトの集合写真です。 貴社担当のアカウントマネージャから「ビルシリーズ」のお誘いがあるかもしれませんが、是非ご検討いただければと思います。それでは、次回のビルシリーズでお会いしましょう！   著者について 木村 公哉（Kimura, Koya） 香川県出身のソリューションアーキテクトです。好きなサービスはAWS AmplifyとAWS Lambda、Amazon Kinesisです。好きな食べ物はうどんです。   上原 誠（Uehara, Makoto） アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。

本記事は「新しいサーバーレスアプリ作成機能で CI/CD も作れます」のその後のステップとして記述しています。まだその記事を見ていない方は、まずはそちらをご覧ください。以下は、その機能で、テンプレートとして Serverlerss API backend を選択し、プロジェクトリポジトリとして CodeCommit を作成された結果を元に説明しています。CI/CD や CodeCommit をよくご存知の方は読み飛ばしていただいて構いません。 実行テスト 作成されたアプリケーションは、何も変更しなくてもすでに実行できる状態にあります。 例えば、ターミナルなどから以下のコマンドを実行してみてください（なお、下記のように日本語を含むデータで実行する場合は、ターミナルの文字コード設定が UTF-8 であることを確認ください）。 curl -d ‘{“id”:”001″,”name”:”テスト”}’ -H “Content-Type:application/json” -X POST https://<<API EndPoint>> DynamoDBのコンソールをみると、新しいデータが登録されることがわかります。もちろん、好みの REST API テストツール（ブラウザプラグインなど）を使っても構いません。 構成の確認 生成されたアプリケーションで、API 定義、Lambda 関数がどのように定義されているかを見るのは、サーバーレスを始めたばかりの開発者には参考になるかと思います。例えば、API Gateway の構成を見てみると、以下のように設定されていることがわかります。 名称で想像できる通り、3つの関数は、全件検索、データの書き込み、特定 ID のデータの取得のための処理であり、それらが対応する API に紐づけられています。この 3つの処理はよく使われる典型的なものですので、そのコードは、多くの処理で参考になるでしょう。 コードの編集 テンプレートベースのサーバーレスアプリ作成機能で設定された Lambda 関数がどういうものか、コンソールから確認してみましょう。作成したサーバーレスアプリケーションへ Lambda コンソールからアクセスし、その中のリソースのセクションを見ると Lambda Function タイプのものが作成されていることがわかります。 ここにあるリンクをクリックすれば、それぞれの Lambda 関数の画面に飛びますが、そのコードは表示されず、「インラインコード編集を有効にできません」と表示される場合があります。生成されたコードはどこにあるのでしょう? もう一度、Lambda […]

AWS Lambda のマネジメントコンソールに新しい「サーバーレスアプリケーションの作成」機能が追加されていることにお気付きですか? サーバーレス環境である Lambda ではすぐに処理実行環境が利用可能になり、Webのコンソールからロジックを実装するだけで容易にちょっとした処理を開発できます。一方で、この次のステップとして、 Lambda 関数だけでなく、アプリケーションとしての開発や管理ができていない 環境の再現（開発環境からステージングや本番環境へ）、デプロイの継続実行（CI/CD）の環境が整備できずに、Webコンソール上でいまだにコード変更している という話を聞くことがあります。実際には、デプロイ/環境設定のコード化（Infrastructure as Code: IaC）には AWS CloudFormation や Serverless Application Model（SAM）などがあり、CI/CD には CODEシリーズなどがあるのですが、サーバーレス開発を始めたばかりだと、そこへの次の一歩に二の足を踏まれているケースを見かけることがあります。 そんな方に向けた機能が、新しい「サーバーレスアプリケーションの作成」機能です。これを使うと、特定ユースケースのアプリケーションをテンプレートベースでひとまとめに作成し、CI/CD パイプラインまで一気に構築してくれます。 簡単に、この機能の利用ステップを紹介します。

Amazon Web Services (AWS)上でSAPワークロードを稼働している私たちのお客様は、同様にAWS上のデータレイクソリューションを使用することでデータと分析の変換に投資されています。これらのお客様は、さまざまなサードパーティソリューションを使用してSAPアプリケーションからデータを抽出することがあります。ただし、パフォーマンス向上とコスト削減のために、AWSソリューションを使用するネイティブ統合も必要とされています。 これらのお客様がSAPアプリケーションからデータを抽出するために使用する一般的なパターンは、IDocインターフェース/電子データ交換です。SAP NetWeaver ABAPベースのシステムは、長い間IDocをサポートしています。IDocは非常に安定したフレームワークであり、SAPシステムと非SAPシステム間でのマスターデータとトランザクションデータの配信を支えます。 SAP IDocをAmazon Simple Storage Service (Amazon S3)と統合するためのアーキテクチャ上のアプローチは、ブログ記事「Integrating SAP’s IDOC Interface into Amazon API Gateway and AWS Lambda」のように、既にSAPコミュニティで公開されています。しかしながら、これらのアプローチでは、本稼働環境で使用する上で重要なセキュリティ面がカバーされていません。不正なユーザーの脅威から守るためにビジネスクリティカルなAPIを保護することは重要です。 このブログ記事では、AWS Lambda オーソライザーとAmazon Cognitoで認証レイヤーを提供し、Amazon API Gatewayを使用してSAP IDocをAmazon S3に格納する方法を紹介します。

先日 (2019/5/14) 開催しました AWS Black Belt Online Seminar「Amazon API Gateway」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190514 AWS Black Belt Online Seminar Amazon API Gateway from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. API GatewayかLambdaのどちらかの採用を検討するにはどのようにしたらいいでしょうか (とくにコスト面で) A. Web APIとして公開する場合は、AWS Lambdaの手前にAmazon API Gatewayを配置することによって疎結合化がなされ、実装を隠蔽化できるという利点があります。 ただシンプルにAWS SDK等を利用し直接Lambdaを呼び出したいケースであれば、必要な権限を呼び出し元のアプリケーションに付与した上でLambdaのみを利用する構成もご検討頂けます。 (例：呼び出し元がAmazon Elastic Compute Cloud (EC2) であればそのIAMロール、呼び出し元がブラウザやモバイルアプリであれば、Amazon CognitoのIDプールを利用したAWS Credentialsを利用)。 また、Lambda関数をバックエンドとしてHTTPリクエストを受け付ける他の方法としては、Elastic Load Balancing (ELB) の一種である Application Load […]

本日より、任意のサーバーをプロビジョニングして管理することなく、Amazon API GatewayでWebSocket APIを使用して双方向通信アプリケーションを構築できます。 HTTPベースのAPIは、リクエスト/レスポンスモデルを使用して、クライアントがサービスにリクエストを送信し、サービスがクライアントに同期して応答します。 WebSocketベースのAPIは本質的に双方向です。 これは、クライアントがメッセージをサービスに送信し、サービスが独立してメッセージをクライアントに送信できることを意味します。 この双方向の振る舞いにより、クライアント/サーバーとのやりとりがより豊富になります。これは、明示的なリクエストをする必要のないクライアントにデータをプッシュできるためです。 WebSocket APIは、チャットアプリケーション、コラボレーションプラットフォーム、マルチプレイヤーゲーム、金融取引プラットフォームなどのリアルタイムアプリケーションでよく使用されます。 このブログでは、WebSocket APIとAPI Gatewayを使用してサーバーレスのリアルタイムチャットアプリケーションを構築する方法について説明します。

あなたは分散型サービス拒否 (DDoS) 攻撃やその他のサイバー攻撃の影響からビジネスを守るために働いており、アプリケーションの可用性と応答性を確保し、サービスに対するお客様の信頼を維持したいと考えています。また、攻撃に対応するためにインフラストラクチャをスケールする必要がある場合でも、不必要なコスト上昇を避けたいと考えています。 AWS はインターネット上の攻撃を防ぎ、高可用性・セキュリティの確保および回復力を得られるように、ツール・ベストプラクティスおよびサービスを提供することをお約束します。私達は最近、2018 年版の DDoS に対する AWS のベストプラクティス（英語のみ）のホワイトペーパーをリリースしました。今回のアップデートでは、 DDoS 攻撃への対策を強化するのに役立つ、以下の新しく開発された AWS サービスを考慮に入れています: 追加された AWS サービス: AWS Shield Advanced、AWS Firewall Manager および AWS Application Load Balancer のような新世代の ELB 追加された AWS サービスの機能: AWS WAF Managed Rules、AWS WAF Rate Based Rules、新しい世代の Amazon EC2 インスタンスおよび API Gateway のリージョン API エンドポイント このホワイトペーパーは、DDoS 攻撃に対する回復力のあるアプリケーションを構築するための規範的な DDoS ガイダンスを提供します。ボリューム型攻撃やアプリケーション層に対する攻撃など、さまざまな攻撃タイプを紹介し、各攻撃タイプを管理する上で最も効果的なベストプラクティスを説明します。また、DDoS 緩和戦略に適合するサービスや機能および、それぞれがどのようにアプリケーションを保護するのに役立つのかについて要点を説明します。 原文: AWS […]