Author: AWS Japan

このブログでは、AWS IoT Core Rule EngineのHTTPアクションを使って任意のHTTPS エンドポイントへ追加コードなしもしくは変更してデータを送る方法を紹介します。この機能を使用すると、AWS IoTを独自のウェブサービスと統合できます。中間サービスの使用に伴う追加Latencyの発生や複雑さはありません。 この機能の詳細については、HTTPアクションのドキュメントを参照してください。 AWS IoTルールを初めて使用する場合は、このチュートリアルをご覧ください。 本ブログの前提: AWS IoTのコンソールにログイン可能もしくはAWS CLIがインストール済みであること あなたがすでに証明局(CA)により署名された確かな証明書が存在するHTTPSをもっていること HTTPSエンドポイントのログへアクセス可能もしくは、エンドポイントへ送ったメッセージを読むことができること 本ブログでは以下をウォークスルーします コンソールでトピックに基づくHTTPアクションルールを作成します コンソールでルールの宛先の確認と有効化 HTTPアクションルールの作成をAWS CLIで実施 置換用のテンプレートを使わずにHTTPアクションを定義 HTTPアクションのhaeaderと認証を定義 ルールの宛先をAWS CLIを使って管理する 作成 確認 更新 リスト 削除

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 この週刊AWSは、一週間のAWSでの新発表や新サービスについて厳選してコンパクトにまとめる…というのがコンセプトなのですが、先週は厳選してもコンパクトならない量の発表がありました。AWS Storage Dayと銘打ってストレージサービス周りの発表が一度に行われたりもしましたね。 そういうわけで、今回は”特大号”でお届けします。早速先週の主なアップデートについて振り返っていきましょう。

みなさんこんにちは！アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉です。 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） アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。

AWS AppSyncはGraphQLのマネージドサービスで、単一または複数のデータソースのデータに安全にアクセスしたり、操作したり、結合するための柔軟なAPIを作成でき、アプリケーション開発をシンプルにすることができます。多くの場合、異なったデータソースは異なったユースケースに合わせて最適化され、データが配信されるスピードも異なっていることでしょう。その基になるGraphQLスキーマで定義されているデータフィールドもかなり多様です。

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング シニアエバンジェリストの亀田です。先日公開した第一弾はいかがでしたでしょうか。今日は第二弾、11月20日から11月21日（米国時間基準）分をお届けします。 11月20日 AWS Lambdaが、イベントソースとしてAmazon SQS FIFOキューをサポートしました Amazon SQSは、分散ソフトウェアコンポーネントとマイクロサービス間で確実に通信するための完全に管理されたメッセージキューサービスであり、SQS標準キューとSQS FIFOキューの2つをサポートします。FIFOキューは、標準キューを改良および補完し、メッセージが送受信される正確な順序を保持することが可能な、単一のキュー内で複数の順序付けされたメッセージグループを許可するメッセージグループをサポートします。 このアップデートにより、処理の順序は、メッセージグループ内のメッセージの順序に従うようになります。 AWS Storage Gatewayは、VMware上のHA構成をサポートし、新しいパフォーマンス監視メトリックスを追加しました VMware vSphere High Availability（VMware HA）と統合された一連のヘルスチェックを通じてVMware上で高可用性が提供するようになりました。この機能強化により、オンプレミスのVMware環境またはAWS上のVMware CloudにデプロイされたStorage Gatewayは、60秒以内にほとんどのサービス中断から自動的に回復します。ストレージゲートウェイ管理コンソールに埋め込まれたAmazon CloudWatchレポートにより、キャッシュ使用率、ゲートウェイアクセスパターン、スループットとI / Oメトリックスを継続的に可視化できるようになり、割り当てられたストレージ、コンピューティング、ネットワークリソースをより簡単に最適化できるようになりました Amazon RDS for Oracleは、sqlnet.oraパラメーターのALLOWED_LOGON_VERSION_SERVERおよびALLOWED_LOGON_VERSION_CLIENTをサポートしました SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメーターを使用して、Oracle DBインスタンス用にAmazon RDSに接続するときに許可される最小認証プロトコルを設定し、SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメーターを使用して、クライアントに許可される最小認証プロトコルを設定することができます。 AWS Config Conformance Packがリリースされました Conformance Packは、共通のフレームワークとパッケージモデルを使用して、ポリシー定義から監査および集計レポートに至るまで、AWSリソースの構成コンプライアンスを大規模に管理するのに役立ちます。AWS Organizationsと統合され、AWS Configルールと修復アクションのコレクションをパッケージ化して、組織全体で単一のエンティティとして一緒にデプロイできます。Conformance Packは、AWS Configルール（管理またはカスタム）および修復アクションのリストを含むYAMLテンプレートを作成することにより作成できます。こちらのサンプルテンプレートをご覧ください。 AWS Configがサードパーティリソースをサポートしました 新しいAPIを使用して、GitHubリポジトリ、Microsoft Active Directoryリソース、またはオンプレミスサーバーなどのサードパーティリソースの構成をAWS Configに公開できるようになりました。この設定データがAWS Configに公開された後、AWS ConfigコンソールとAPIを使用してリソースインベントリと設定履歴を表示および監視できます。AWS Config rulesまたはConformance Packsを作成して、これらのサードパーティリソースをベストプラクティス、内部ポリシー、および規制ポリシーに対して評価することもできます。これにより、AWS […]

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング シニアエバンジェリストの亀田です。 12月2日から6日にかけて米国ネバダ州ラスベガスで開催されるre:Invent 2019がいよいよ近づいてきています。 例年通り、re:Invent が始まる前に非常に多くのアップデートが毎日発表されています。その量が多く、また一部日本語化がされていないことなどから整理が大変だということを多くのお客様から頂いており、昨年同様2019年11月15日以降の発表分を一覧表形式にて日本語でまとめて行きたいと思います。 今回は11月15日から11月19日（米国時間基準）分です。 11月15日 Amazon Redshift がインスタンスをまたいだリストアに対応しました 異なるサイズまたは実行中の異なるノードタイプのクラスターに Redshift スナップショットを復元できるようになりました。これにより、スナップショットの復元ワークフローが簡素化されます。 Amazon SNS にデッドレターキュー (DLQ) をサポートしました Amazon Simple Notification Service (SNS) のサブスクリプションにデッドレターキュー (DLQ) を設定して、未送信のメッセージをキャプチャできることになりました。これにより、サブスクリプションがエンドポイントに届かない場合にメッセージを保存しておけるため、アプリケーションの復元性と耐久性が向上します。 Amazon Redshift でデータウェアハウスの管理とモニタリングを改善する新しいコンソールが発表 新しい Redshift コンソールの新しいモニタリングダッシュボードでは、可用性ステータス、クラスターとクエリのパフォーマンス、イベント、アラームなどのすべての関連情報を統合することにより、管理者はすべての Redshift クラスターを単一ページから簡単に監視できます。これにより、管理者はワークロードに関連するアクティビティを速やかに把握することができます。 Amazon WorkSpaces が WorkSpaces Directory API をリリースしました Amazon WorkSpaces API を使用して、ディレクトリを WorkSpaces に登録し、ディレクトリの詳細を変更できるようになりました。新しい API を使用すると、WorkSpaces にディレクトリを登録するか、デフォルトの ワークスペース 作成設定、セルフサービスのアクセス許可、アクセスコントロールなどのディレクトリレベルの […]

先日 (2019/11/14) 開催しました AWS Black Belt Online Seminar「 AWS Transit Gateway 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20191113 AWS Black Belt Online Seminar AWS Transit Gateway   AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. TGW を使う場合、DXGW も一緒に使う必要がありますか？TGW のみでも利用できるのでしょうか？ A. Direct Connect を使う場合は、DXGW を一緒に使う必要があります。構成については、こちらをご参照ください Q. VPC をアタッチするときに指定するサブネットをアタッチ専用のサブネットとする必要性について、もう少し具体例を挙げて説明していただきたいです。そのサブネットの内部のEC2 インスタンスのルーティングに影響あるとのことでしたが、どのような影響があるのか？などを教えていただきたいです。 A. Transit Gateway (TGW) のアタッチメントがついているサブネットと同一のサブネットに EC2 インスタンスが存在する場合に、その EC2 インスタンスはTGWと同じルーティングテーブルを参照します。 例えば　インライン監査用の VPC の TGW の ENI […]

この投稿は Otavio Ferreira, Sr Manager, SNS の寄稿によるものです 郵便システムにおいて、デッドレターキューは配信不能な郵便物を取り扱うための施設です。pub/sub メッセージングモデルにおけるデッドレターキュー (DLQ: dead-letter-queue) は、トピックに対して発行されたメッセージがサブスクライブしているエンドポイントに配信できなかった場合に、そのメッセージを送ることができるキューを表します。 Amazon SNS による DLQ サポートによって、アプリケーションはメッセージ配信における各種故障モードに対する、さらなる耐久力と回復力を持つことが可能になりました。 メッセージの配信失敗と再試行を理解する Amazon SNSがサブスクライブされたエンドポイントにアクセス出来ない場合、メッセージの配信は失敗します。このような状況は大きく2つの原因によって引き起こされます: クライアントエラー。ここでクライアント (メッセージ送信者) は SNS となります。 サーバーエラー。ここではサーバーは、例えば Amazon SQS や AWS Lambda のようにサブスクリプションのエンドポイント (メッセージ受信者) をホストするシステムとなります。 クライアントエラー クライアントエラーは、 SNS の保持しているメタデータが最新ではない場合に発生します。クライアントエラーの発生するよくある原因としては、エンドポイントの所有者がエンドポイントを削除した場合が挙げられます。例えば SNS に紐付いたサブスクリプションを削除することなく、SNS トピックにサブスクライブした SQS キューを削除してしまったような場合です。やはりよくある別の例としては、エンドポイントに適用されたポリシーに対して、SNS がメッセージを配信することを阻害するような変更を加えてしまった場合が挙げられます。 これらのエラーは、クライアントがメッセージの配信を試みたにもかかわらず、クライアントの視点からエンドポイントがアクセス不能となっていることが原因で発生するため、クライアントエラーとして取り扱われます。SNS はクライアントエラーの結果として失敗したメッセージの配信を再試行することはありません。 サーバーエラー サーバーエラーは、サブスクライブしているエンドポイントを実行しているサーバーが利用できないか、または SNS からの有効なリクエストを処理できなかったことを表す例外応答を返した場合に発生します。 サーバーエラーが発生した場合、SNSは線形、指数的のいずれかのバックオフ機能に基づいて配信を再試行します。SQS や Lambda 上で実行される AWS […]

本記事は「新しいサーバーレスアプリ作成機能で 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 Key Management Service (AWS KMS) が KMS API エンドポイントに接続する際に使われる Transport Layer Security (TLS) ネットワーク暗号化プロトコルにおけるポスト量子暗号ハイブリッド鍵交換をサポートしました。この投稿では、ポスト量子暗号 TLS とは何か、 ハイブリッド鍵交換とは何か、 なぜこれらの技術が重要か 、この機能でどのようなメリットを得られるのか、そしてフィードバックの方法について説明します。 ポスト量子暗号 TLS とは? ポスト量子暗号 TLS は、ポスト量子暗号の暗号プロトコルを追加する機能です。 AWS はオープンソースの TLS 実装である s2n を使用しています。2019年6月に AWS はポスト量子暗号 s2n をリリースしました。これは、IETF ドラフトで定義されている２種類のポスト量子暗号ハイブリッド暗号スイートを実装しています。暗号スイートは、従来型とポスト量子暗号の両方のセキュリティ保護を行う暗号鍵交換方式を指定するものです。 ポスト量子暗号 TLS の重要性 大規模な量子コンピュータは、TLS 接続の暗号鍵交換で使用されている既存の公開鍵暗号を破る可能性があります。大規模な量子コンピューターは現時点で利用可能ではありませんが、長期的なセキュリティ保護のニーズについて考え、準備しておくことが重要です。記録された TLS トラフィックは将来的に大規模な量子コンピュータで復号出来る可能性があります。TLS 接続の上で送信されているデータの長期間の機密性維持が必要なアプリケーションを開発している場合、大規模な量子コンピュータが実用化され、悪意を持った人に利用可能になる前にポスト量子暗号に移行することを検討するべきでしょう。AWS はこの機能の提供について取り組んでおり、お客様にも準備して頂きたいと考えています。 AWS は大規模な量子コンピュータの実現を待つのではなく、今この機能を提供します。 お客様は、アプリケーションに対する潜在的なパフォーマンス影響を計測することが可能です。また、お客様は、ポスト量子暗号スキームによってもたらされる追加の利点を得ることが可能です。AWS はこの機能が既に存在する KMS エンドポイントへの接続に関するセキュリティーのバーを向上させると考えていると共に、新しい暗号スイート帯域利用率やレイテンシに影響を与えると考えています。また、TLS 接続を中継する中間システムにも影響を与える可能性があります。将来に渡るサービスの改善のために AWS はこれらのお客様環境における影響についてフィードバックして頂きたいと考えています。 ポスト量子暗号 […]