Author: AWS Japan

Amazon API Gateway で、堅牢でスケーラブルなアプリケーションバックエンドの構築と実行を簡単に素早く最近追加された使用プランで、API に関与するパートナー開発者のエコシステムを作成することができます。では、いくつかの用語を確認しながら始めましょう。 エンドポイント – HTTP リクエストに応答する URL (API Gateway によって提供される) です。これらのリクエストは、GET、PUT、POST などの HTTP メソッドを使用します。 リソース – エンドポイント内にある名前の付いたエンティティで、階層パスと呼ばれます。 動作 – 特定のリソース上で、HTTP リクエストに対応してコードが HTTP メソッドを使用して実行するアクションです。 統合 – エンドポイント、リソース、および HTTP メソッドと実際のアクションとの間でやり取りされる API Gateway マッピングです。 現在、API Gateway が提供する統合モデルを拡張して、新しい API エンドポイントの構築と既存のアプリケーションの移植を容易にするための複数の新しい機能をサポートしています。 greedy パス変数 – 一般的なパス ( /store/ など) に分類されるリクエストのグループのパスと動作を個別に指定する代わりに、パスへのすべてのリクエストを傍受してそれらを同じ機能にルーティングする、「greedy」ルートを指定できるようになりました。たとえば、単一の greedy パス (/store/{proxy+}) は、 /store/list-products, /store/add-product、および /store/delete-product) に対するリクエストを傍受します。 […]

Amazon RDS SQL Serverでローカルタイムゾーンをサポートしました。アプリケーションでお使いのタイムゾーンをAmazon RDS for SQL Serverインスタンスに設定頂けます。 こちらの機能はDBインスタンスのタイムゾーンをご指定の物に設定します。RDS for SQL Serverを作成する際にタイムゾーンを変更する場合は、AWS Management ConsoleのSelect your Time Zoneドロップダウンメニューを利用します。インスタンス作成後はタイムゾーンを変更することが出来ません。このオプションを変更すると、OSレベルでのタイムゾーンの変更が行われ、全てのdateカラムと値に影響がある点ご注意ください。その為、タイムゾーンの変更による影響を事前に調査することを推薦します。ローカルタイムゾーンを設定したデータベースインスタンスを作成する前に、テストデータベースインスタンスで変更を検証することをお勧めします。 Amazon RDS for SQL Serverのローカルタイムゾーンサポートに関する更に詳細な情報は、ドキュメントをご覧ください。 星野 (原文はこちら)

ご協力ありがとうございました!合計 25 人の内外部の寄稿者が、今回の週刊 AWS の作成に協力してくださいました。自分もぜひ参加していみたいという方は (re:Invent でランチ無料の可能性あり)、GitHub の週刊 AWS をご覧ください。 月曜日 9 月 12 日 AWS Compute Blog がブログ「Amazon ECS と Amazon CloudWatch ログでコンテナログを一元管理」を公開しました。 [backspaceblog] がアプリケーションのフロントエンドセキュリティ「責任分担 3 – ボットの特定と破棄」について説明しました。 John McKim が AWS の「サーバーレスフレームワークと Slack Webhooks」についてブログを公開しました。 Darin Briskman が「Redis でシンプルな自動入力機能サービスを作成: パート 1」についてブログを公開しました。 AWS Compute Blog が「Amazon ECS と Amazon CloudWatch ログでコンテナログを一元管理」を公開しました。 AWS Podcast が AWS […]

AWS コストエクスプローラーは、AWS 使用量の視覚化、理解、管理に役立つ強力なツールです (詳細については、「The New Cost Explorer for AWS」を参照してください)。サービスまたはリンクされたアカウント別に使用量を表示でき、日または月単位を選択できます。アカウント、期間、サービス、またはお客様が特に関心を持っているタグに基づいて、カスタムフィルターを作成することもできます。使用量の可視性をさらに高めるため、いくつかの追加のフィルタリングオプションを導入しました。現在では、さらにきめ細かなレベルでフィルタリングし、最も基本的な課金単位までズームインして費用を表示できるようになりました。また、ズームアウトし、AWS 使用量および請求の主要コンポーネントに合った高位のレベルで使用量を分類することもできます。 ズームイン お気付きかと思いますが、AWS は使用量を非常に詳細なレベルで追跡できます。S3 ストレージの毎時のギガバイト、EBS 使用量の毎月のギガバイト、毎時の EC2 使用量、内部または外部へのデータ転送ごとのギガバイトなどです。これらの費用を、[Usage Type] フィルタリングオプションを使用して詳細に確認できるようになりました。コストエクスプローラーに移動して [Filtering] メニューから [Usage Type] を選択すると、基本的な請求単位に基づいてフィルタリングできるようになりました。たとえば、m4.xlarge インスタンスの毎日の使用量を表示できます。 ズームアウト 詳細情報が必要なときもあれば、概要が必要なときもあります。RDS の使用量、S3 API リクエストの使用量、EBS 磁気ストレージの使用量を知りたいときもあります。この操作は、[Usage Type Group] を基にしてフィルタリングすることで実行できます。私の毎日の EC2 使用量は次のとおりです フィルタリングに使用できる他の使用量タイプグループをいくつか次に示します (メニューの高さについては、ブラウザで特別な操作を行っています)。 今すぐ利用可能 これらの新機能は今すぐすべての AWS リージョンで利用できます。 — Jeff;

AWS CloudFormation では、テンプレートを作成して、スタック全体 (関連する AWS リソースのコレクション) を宣言により表すことができます。スタックを定義し、希望のリソースとそれらの相互関係を指定および設定して、スタックの必要な数のコピーを起動できます。CloudFormation では、リソースを自動的に作成およびセットアップし、リソース間の順序付けの依存関係の対応に配慮することもできます。現在、CloudFormation には 3 つの重要な機能を追加中です。 YAML Support – CloudFormation テンプレートを YAML で記述できるようになりました。 クロススタック参照 – あるスタックから値をエクスポートし、別のスタックで使用できるようになりました。 簡略化された置換 – テンプレート内で文字列の置換をより簡単に行うことができます。 それらについて説明します。 YAML のサポート CloudFormation テンプレートを YAML (「YAML はマークアップ言語ではない」の頭文字) で記述できるようになりました。これまでは、テンプレートは JSON で記述されていました。YAML と JSON の表現力は同等ですが、YAML は人間が読み取れる形式であるよう設計されているのに対して、JSON は (正直なところ) そうではありません。YAML ベースのテンプレートでは句読点の使用が少なく、記述と読み取りがかなり簡単です。また、コメントの使用が許可されます。CloudFormation は、ハッシュ結合、エイリアス、および一部のタグ (バイナリ、imap、ペア、TIMESTAMP、セット) の例外を除き、実質的にすべての YAML をサポートします。 YAML で CloudFormation テンプレートを記述する場合、同じ最上位の構造 (Description、Metadata、Mappings、Outputs、Parameters、Conditions、および Resources) を使用します。これは、パラメーター定義を図示したものです。 […]

AWS のオープンデータチームのメンバーで私の同僚、Joe Flasher が新たな Earth on AWS プロジェクトについて説明するため、ゲスト投稿者としてブログを公開しました。 — Jeff;   AWS は地球観測衛星のランドサット 8 号が撮影した画像を集めた公開データセット、Landsat on AWS を 2015 年 3 月にリリースしました。Landsat on AWS をリリースしてから 1 年以内に記録された Landsat データのリクエスト数は 10 億件を超え、AWS はユーザーによる革新的なデータの使用方法から様々なインスピレーションを得ています。Landsat on AWS はクラウド内でのデータ共有により、従来の IT インフラストラクチャによる帯域幅やストレージ、メモリや処理能力の制限なしに地球的規模のアプリケーションを構築することが可能になりました。 そして本日、AWS がリリースした Earth on AWS により、今後はクラウド内で大容量の地理空間データセットの利用が可能になったため、アルゴリズムをローカルマシンにダウンロードせずにアルゴリズムをデータに持ち込めるようになりました。Earth on AWS では誰でも自由にデータを使えるだけでなく、リソースを提供することでデータをどのように使用できるか説明する情報も提供しています。また、Earth on AWS データセットを利用した調査方法の 公開プロポーザル も受け付けています。 使用可能なデータを追加 現在、Earth on AWS […]

Amazon Relational Database Service (RDS)は構築や運用管理、スケーリングなどを行うプロセスを簡単に行えるクラウド上のリレーショナルデータベースです。現在6つのデータベースエンジン(Amazon Aurora, Oracle, Microsoft SQL Server, PostgreSQL, MySQL,  MariaDB) をサポートしており、RDSはクラウド上で動作するアプリケーションの基本となるサービスとなりました。 2013年後半にPostgreSQLサポートを発表し、PostgreSQLの新バージョンや新機能を追加し続けてきました。 2014年11月 – Read Replicas, version 9.3.5, Trigger-based Replication, and Three New Extensions. 2015年3月  – Version 9.4.1, Enhanced Monitoring, Enforced SSL Connections. 2015年11月 – Point and Click Upgrade from Version 9.3 to 9.4. 2016年4月  – Versions 9.3.12, 9.4.7, and 9.5.2. 2016年6月 […]

今月始めに継続学習のメリットについて説明したブログを公開し、継続学習と昇給、効率性の向上や転職の傾向が減少する関連性について表したインフォグラフィックをご紹介しました。AWS のイノベーションのペースは、いつも何か新しいことを学べるチャンスがあることを意味しています。これを実践するには AWS のオンラインセミナーに参加するのも 1 つの方法です。AWS ではこうしたオンラインセミナーをデザインする上でトレーニングと教育の面を考慮しています。そうすることで、参加者は新しい AWS サービスを使い始める準備を整えることができるほか、既存のサービスを別の方法で活用するための知識を得ることができると考えています。9 月に開催するオンラインセミナーにも素晴らしい内容が揃っています。いつもながら受講は無料ですが、すぐに満席になってしまうため、お早目の登録をお勧めします。開催時間はすべて太平洋標準時、所要時間は 1 時間です。 9 月 20 日 午前 9:00 – 詳細: ビッグデータ分析に Amazon Redshift を使用 午前 11:30 – コンテナを大規模にモニタリング 9 月 21 日 午前 9:00 – Cognito ユーザープールの使用開始について: アプリで簡単にユーザーのサインアップとサインインを追加 午前 11:30 – データウェアハウスを Amazon Redshift に移行する場合のベストプラクティス 午後 1:00 – Amazon Elasticsearch Service のログ分析 9 月 22 […]

これは、週刊 AWS 第 3 回目のコミュニティ型エディションです。これを実現するために貢献してくださった 15 名の内外部寄稿者に感謝申し上げます。寄稿を希望される場合は、GitHub の週刊 AWS をご覧ください。 月曜日 9 月 5 日 John McKim が AWS のサーバーレスフレームワークと GraphQL についてブログを公開しました。 火曜日 9 月 6 日 AWS Config を使用して設定変更に関係する API イベントの表示が可能になったことを AWS が公表しました。 本稼働環境で AWS SDK for C++ の使用が可能になったことを AWS が公表しました。 IAM Service Last Accessed Data がアジアパシフィック (ムンバイ) リージョンで利用可能になったことを AWS が公表しました。 AWS Security Blog […]

機能向上を行うたびにAmazon Auroraはパワフルかつ簡単にご利用頂けるようになってきました。ここ数ヶ月で、MySQLバックアップからAuroraクラスタを作成する機能や、クロスリージョンレプリケーション、アカウント間でのスナップショットの共有、フェイルオーバー順を指定可能になったり、他のクラウドやオンプレミス環境のデータベースからAuroraへ移行などを追加してきました。 本日、Auroraのリードレプリカの機能を向上する、クラスタレベルのリードエンドポイントを追加しました。皆様のアプリケーションは今まで通り特定のレプリカに対して直接クエリを実行することが可能です。しかし、今回追加したリードエンドポイントを利用するように変更することで、負荷分散や高可用性といった2つの大きな利点を得ることが出来ます。 Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間でコネクションのロードバランシングが可能になります。これは、リードワークロードを分散することで利用可能なレプリカ間でリソースを効率的に活用することができ、よりよりパフォーマンスを得ることが可能になります。フェイルオーバーの際には、もしアプリケーションが接続しているレプリカがプライマリインスタンスに昇格した場合コネクションは一旦クローズされます。その後、再接続を行うことでクラスタ内の他のレプリカにリードクエリを実行することが可能です。 Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイント経由で接続することが出来ます。Availability Zoneの可用性の問題が万が一発生した場合、リードエンドポイントを利用することで最小限のダウンタイムでリードトラフィックを他のレプリカに実行可能です。   Find the Endpoint リーダーエンドポイントはAurora Consoleで確認可能です: この便利な機能は本日からご利用可能です！ — Jeff; (翻訳は星野が担当しました。原文はこちら)