Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

AWS クイックスタートの更新 – Tableau、Splunk、Compliance、Alfresco、Symantec

AWS クイックスタートは AWS で人気のソリューションのデプロイをサポートします。各クイックスタートは AWS のソリューションアーキテクトやパートナーが設計し、セキュリティや高可用性における AWS のベストプラクティスを活用しています。テストまたは本番稼働環境ですぐにクイックスタートをご利用いただけます。シングルクリックで起動できるクイックスタートには、広範囲にわたる内容を取り上げたデプロイメントガイドと テンプレートが含まれています。クイックスタートは次の 7 つのカテゴリに分類されています。 開発運用 データベースとストレージ ビッグデータと分析 セキュリティ & コンプライアンス Microsoft & SAP ネットワークとアクセス その他 過去 2 か月間で 6 つの新しいクイックスタートをコレクションに追加し、合計数は 42 件になりました。次に、新しいクイックスタートの各カテゴリの概要をご紹介します。 Tableau Server (ビッグデータと分析) AWS クイックスタートの Tableau Server は で完全に機能する Tableau Server のデプロイをサポートします。デフォルト VPC でシングルノードを起動したり、新規または既存の VPC でマルチノードクラスターのデプロイメントができます。クラスターアーキテクチャについてはこちらをご覧ください: CloudFormation テンプレートは Tableau アクティベーションキーについてもプロンプトを表示します。 Splunk Enterprise (ビッグデータと分析) AWS クイックスタートの Splunk […]

Read More

SAP Database Migration Option(DMO)を使ったAWSへの移行

Somckit Khemmanivanhは、Amazon Web Services (AWS)のSAPソリューションアーキテクトです。 このブログ記事では、SAP Software Update Manager(SUM)の機能であるDatabase Migration Option(DMO)を使って、AnyDBデータベースからAWS上のSAP HANAに移行する方法を説明します。SAPでは、SAP社がサポートするSAP HANA以外のソース・データベース(DB2、Oracle、SQL Serverなど)を指すときに、AnyDBという用語を使用しています。ここでは、オンプレミス・アーキテクチャからAWSへの移行オプションについて説明します(ここで留意すべきは、SAP HANAがターゲット・プラットフォームでない場合、他にも多くの移行オプションがあることです。詳細はホワイトペーパーMigrating SAP HANA Systems to X1 Instances on AWSをご覧ください)。 SAP HANAは完全なインメモリーで、列指向に最適化され、また圧縮されたデータベースです。 SAP社により認定されたSAP HANAシステムでは、160+ GB RAMから2TB RAMまでのシステムでSAP HANAデータベースをスケールアップ構成として稼働できます。また、最大14TBまでの認定されたスケールアウト構成も利用可能です。AWSであれば、このシステム構成の柔軟性により、ビジネスとITのニーズに合わせて拡張することができます。もしこれ以上のメモリーを要求するワークロードがある場合は、ぜひご連絡ください。私たちは、お客様要件にお応えできるよう取り組みたいと考えています。 DMOの概要については、SAP Community Networkをご覧ください。大まかには、AnyDBで稼働するSAPシステムをSAP HANAデータベースに移行する際にDMOを使うことができます。また、DMOにより、SAPシステムのソフトウェア・アップグレードとユニコード変換を移行時に合わせて行うこともできます(Enhancement Package(EHP) 8以降、ユニコードは必須)。 標準的なDMOのプロセスでは、ソースのAnyDBをターゲットのSAP HANAデータベースにオンラインかつ直接移行します。 図1: SAP HANA DMOのプロセス 移行先がAWS上のSAP HANAシステムである場合、この直接の移行プロセスを容易にするためにネットワーク接続を確立する必要があります。加えて、標準的なDMOのプロセスにおいて、SAP Note 2277055 – Database Migration Option (DMO) of SUM 1.0 […]

Read More

AWSでの疎結合データセットの適合、検索、分析

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する(あるいは反論する)ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています(例えば、日時が間違っている、地理座標が間違っているなど)。 最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。 データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。 関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。 このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。 異なる3つのデータセットを適合させて索引付けし、検索可能にします。 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。 Amazon AthenaやAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

Read More

新機能 – TTL(Time to Live)機能を利用したDynamoDBアイテムの管理について

AWSを利用頂いている多くのお客様にDynamoDBは使用されています。速度と柔軟性がその理由で、Ad Tech( リファレンスアーキテクチャ )、Gaming( リファレンスアーキテクチャ )、IoT( リファレンスアーキテクチャ )、そして一貫した一桁のミリ秒のレイテンシを実現しアプリケーションを構築されています。また、DynamoDBはフルマネージドのデータベースで、テラバイトサイズのテーブルに対して毎秒何百万というリクエストを処理することができます。 多くのDynamoDBユーザーは、利用する時間が限られている、または時間の経過とともにアクセス頻度が低くなるデータを格納しています。 直近のログイン、試用版のサブスクリプション、アプリケーションのメトリックなどへの利用がそうです。 他にも保管できる期間に関する規制または契約上の制限の対象となるデータを保管します。 これまで、これらを実現するには独自の時間ベースのデータ管理を実装していました。 大規模なシステムでは、DynamoDBアイテムのスキャン、期間を管理するための日付属性の確認、および不要になったアイテムの削除要求を行う為のAmazon Elastic Compute Cloud(EC2)インスタンスを構築するなどの必要があり、これによりアプリケーションのコストと複雑さが増加していました。 新しいTime to Live(TTL)管理 について この普及した重要なユースケースを合理化するため、新しくTTL(Time to Live)機能の提供を開始しました。 アイテムの有効期限を属性で指定する事により、テーブル単位でこの機能を有効にすることができます。 属性が指定され、TTL管理が有効になると(1回のAPI呼び出しで両方の操作が処理されます)、DynamoDBは期限切れのアイテムを見つけて削除します。 この処理は、自動的かつバックグラウンドで行われ、テーブルへの読み取りまたは書き込みトラフィックには影響しません。 DynamoDBストリームを使用することで(詳細は、「 DynamoDBアップデート – トリガ(Streams + Lambda)+クロスリージョンレプリケーションアプリケーション」を参照)。実際の削除を処理またはアーカイブすることができます。 ストリーム内の他の更新レコードと同様に、削除は24時間単位で行われます。 AWS LambdaおよびDynamoDB Triggersを使用して、期限切れのアイテムをコールドストレージに移動したり、ログに記録したり、他のテーブルを更新したりすることができます。 テーブルのTTLを有効にして、必要な属性を指定する方法は次のとおりです。 指定する属性はDynamoDBのNumber型かつ、 UNIX時間でTTLの指定を行います。 上のスクリーンショットからわかるように、DynamoDB Streamsを有効にすることもできます。また、TTLを有効にすると削除されるアイテムのプレビューを見ることもできます。 また、コードからUpdateTimeToLive関数を呼び出しテーブルにTTLの有効化設定することも、 AWSコマンドラインインターフェイス(CLI)からupdate-time-to-liveコマンドを使用しテーブルでTTLを有効化設定することもできます。 TTL の利用事例(TUNE様)  AWSのお客様であるTUNEは既に、この機能をHasOffers製品の一部として活用しています。 HasOffersは、マーケティングキャンペーンの効果を分析し、大量の広告エンゲージメントデータをプロセスに保存するのに役立ちます。 キャンペーンの顧客定義の時間枠が過ぎると、データは不要になり、削除することができます。 TTL機能をTUNEで使用できるようにする前は手動で期限切れアイテムを識別し、古いデータを削除しました。 これは労力と激しく計算を必要とし、テーブルのプロビジョニングされたスループットの一部も消費する必要がありました。 今は各アイテムの有効期限を設定し、あとはDynamoDBに任せます。 失効したデータは自動的に消え、使用可能なスループットには影響しません。 その結果、TUNEは85テラバイトの古いデータを削除することができ、年間200,000ドル以上のコストを削減し、アプリケーションロジックも簡素化しました。 知っておくべきこと あなたのアプリケーションにTTLを使用することを検討する際、留意すべきことがいくつかあります。 […]

Read More

(速報) 2016年AWS Partner Network(APN) Award発表!

みなさん、こんにちは。Partner SA 酒徳です。 本日、東京ミッドタウン カンファレンスホールにてAWS Partner Summit 2017 – Japan が開催され、昨年2016年の功績を讃え、APN Awardの授与式も同時に行われました。 APN Awardは一年を通し、各分野において最もパフォーマンスを発揮されたAPNパートナー様が受賞されるアワードで、今年は下記5つの分野において受賞パートナー様が選出されました。 APN Awardを授与されましたパートナー様とその授与内容についてご紹介させて頂きます。 – APN Partner of the Year 2016 年間を通じて営業・技術・マーケテイング分野等のパートナーとしての総合力で判断し、 AWSのビジネスに最も貢献いただいたAPNパートナー様が受賞 – APN Rising Star of the Year 2016 APNに加入して頂き1年目にして、AWSビジネスに最も高く貢献頂いたAPNパートナー様が受賞 – APN Cloud Business of the Year 2016 AWSが企業のビジネスに大きく貢献いただき、市場に大きな影響を与えたAPNパートナー様が受賞 – APN Architecture of the Year 2016 AWSの利用アーキテクチャがクラウド利用上優れているものの中から、最も先進的、実用的、チャレンジングなものをAWS のソリューションアーキテクトが選定。同システムを構築したAPNパートナー様が受賞 – APN Reference […]

Read More

シャーディングされたシステムをAuroraに集約してリソースの消費を削減

リレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと2つの手法が上げられます。一般的にスケールアップの方が簡単に行えます(単純にスペックのいいマシンを購入するなど)。一方スケールアウトは、それぞれ独立したホストで稼働している複数のサーバへ、データベースをシャーディングする必要があり作業が煩雑になります。 難しさにも関わらずスケールアウトとが最近のトレンドとなってきています。コモディティハードウェアとシステムリソースへの要求の増加に伴いワークロードを効率的にシャーディングする必要が出てきました。シャーディングされたシステムの1つの欠点として管理コストがあげられます。もし4つのシャードを持っているとすると、4つのデータベースを管理する必要があります。しかし、たとえそうだとしてもスケールアウトはスケールアップよりコスト効率がいい場面が多かったのです。特にAmazon RDSの様なマネージドデータベースの登場によりリレーショナルデータベースの管理を軽減することが出来るようになったのがその1つの要因です。 しかし、なぜ過去形なのでしょうか? Amazon Auroraの登場によりスケールアップという選択肢が戻ってきたのです。Amazon Auroraは非常にスケールし、MySQL互換のマネージドデータベースサービスです。Auroraは2 vCPU/4 GiBメモリというスペックのインスタンスから、32 vCPU/244 GiBメモリ搭載のインスタンスまでを提供しています。Amazon Auroraは需要に応じてストレージが10 GBから64 TBまで自動的に増加します。また、将来のリードキャパシティの増加に備えて15インスタンスまで低遅延のリードレプリカを3つのアベイラビリティーゾーンに配置することが可能です。この構成の優れている点は、ストレージがリードレプリカ間でシャーディングされている点です。 シャーディングされたシステムを1つのAuroraインスタンスに集約、もしくは少数のシャードに集約しAuroraで稼働させることで多くのコストを節約する事が可能です。これがこのブログポストでお話したいことの全てです。 シャーディングされたシステムをAuroraに集約するために – まずはじめに – 多くのシャーディングされたシステムは標準的な方法で行うことが可能です。データはカスタマーIDなどの特定のキーを元に分割されており、何かしらマッピングを行う機能を用いてシャードに分割されています。この方法には様々な種類があり、1例として参照用のデータを別のシステムか1つのシャードに格納したり、全てのシャードに参照用のデータを配置するなどがあります。どのようにデータを分割しても、シャーディングの複雑さは通常、アプリケーションレイヤーにあり、シャードの統合は比較的容易に行えます。 多分皆さんは今、”利点はわかった。ではどうやってAuroraにデータを移行するのか”という疑問をお持ちかと思います。今回の例では、MySQLを利用して4つのシャードを持つシステムを利用していると仮定したいと思います。また、各シャードは他のシャードが持っているデータを持っていないものとします。また1つのシャードが参照用のデータを持っている前提とします。現在の構成は以下の図の様な構成になっていると思います。mapは各シャードへのアプリケーショントラフィックを表しています。 MySQLを運用しているため、Aurora documentationに記載されている方法を利用を利用可能です。簡単に移行を行うために、まずはじめに参照データのみが格納されているインスタンス1を移行します。しかし、どのシャードを最初に移行するかはそれほど重要ではありません。 移行が完了すると、マッピング機能はインスタンス1ではなくAuroraインスタンスを指します。システムは次の図のようになります。 残りのデータを移行する この時点で、Auroraが特定のワークロードをどれくらいうまく処理しているか評価し、必要な調整を行う必要があります。設定に問題がなくなれば、他のデータを移行する準備は完了です。では、シャード2をAuroraインスタンスに移行しましょう。しかし、どうやって?   AWS Database Migration Service (AWS DMS)を是非ご活用下さい!AWS DMSはこのようなマイグレーションにも対応するように作られました。シャード2からAuroraインスタンスへデータをコピーするためにDMSをご利用になれます。更に、シャード2にとランアクションを実行しながらこれらの作業が可能です。DMSは初期データのロードが完了すると、それらのトランザクションデータをシャード2から収集しAuroraインスタンスに適用します。DMSは継続的にシャード2からAuroraインスタンスへデータを移行し、シャード2の代わりにAuroraインスタンスの利用を開始させるまで同期させます。シャード2からAuroraインスタンスへ切り替える準備が出来たら、シャード2へのトランザクションを停止し、DMSが最後のトランザクションをAuroraインスタンスへ適用するまで待ち、mapの設定を、シャード2に向いていたトラフィックを直接Auroraインスタンスへ向くように変更します。設定が完了すると、システムは以下のような状態になります。 この時点から、Database Migration Serviceを残り2つのシャードをAuroraインスタンスへ移行するために利用出来ます。最終的にシステムは以下の様になります。   複雑なシャードの扱い方 これでシャーディングされたシステムが1つのAuroraインスタンスへマイグレーションが完了し、コストを削減することが出来ました!しかし、MySQLを利用し、クリーンなシャードを利用しているとう仮定で話をすすめてきました。もしこれらの仮定にそぐわない場合はどうでしょうか? それでは、シャードがクリーンな状態でない場合を見ていきましょう。例えば、システムが最初に2つのシャードで構成されていたとします。ある時点で、その2つのシャードを4つのシャードに分割したとします。 リシャードィングプロセスの一環として、シャード1と2のコピーを作成してシャード3と4を作成し、マッピング機能を更新しました。 結果は次のようになります。 この図は状況が複雑であるように見えます。 理想的には、このようなリシャードィングの際に、シャードに関係のないデータ、つまりグレーアウトされたデータをパージします。 しかし、必ずしも必要というわけではないし、時には難しいこともあるので、データをそのままにしておく事があります。 この方法では使用されていない冗長なデータを保持する”汚れた”シャードが発生します。 これらのシャードを統合しようとすると、アクティブなデータの行が、削除すべき重複した行と衝突する問題が発生します。 何をすべきか? シャードの統合を行う前に、利用していない行を削除することができます。 しかし、特にマッピング関数がID値のハッシュ(一般的な方法の1つ)で構成されている場合、利用していない行を特定するのは難しいかもしれません。 諦めないで下さい! 別のオプションがあるかもしれません。 各シャード内のデータが1つのデータベースに含まれている場合は、DMSを使用して、システムの各シャードをAuroraインスタンス内の単一のMySQLデータベースに統合できます。 次に、既存のマッピング・スキームを使用して、Auroraインスタンス内の適切なデータベースにトランザクションを転送できます。 […]

Read More

AWS ホットスタートアップ – 2017 年 2 月

2 月を終わるにあたって、Tina Barr が再びすばらしいスタートアップ企業をいくつかご紹介します。 -Ana 今月は、5 社の革新的でホットなスタートアップ企業をご紹介します。 GumGum – イメージ内広告という分野を作成、一般化。 Jiobit – 保護者が子供を追跡するためのスマートタグ。 Parsec – PC ゲーマー用のハードウェアと場所の柔軟性を向上。 Peloton – 家庭でのインドアサイクリングとフィットネス教室を変革。 Tendril – 自宅所有者のエネルギー消費を減らす。 1 月のスタートアップをすべてお読みになっていない場合は、ぜひこちらからご確認ください。 GumGum (カリフォルニア州サンタモニカ) GumGum はイメージ内広告という分野を開発し、一般化したことでよく知られています。Ophir Tanz 氏によって 2008 年に設立された同社は、ソーシャルメディア、論説、さまざまな業界のブロードキャストを通じて毎日作成される膨大なコンテンツ内に留まっている価値を解放するという目標を掲げています。GumGum は 2,000 以上の大手出版社でキャンペーンを行っており、4 億人以上のユーザーがこれを見ています。イメージ内広告は GumGum によって開発され、顧客の注目が既に集まっている場所に、非常に目立つ広告を配信するプラットフォームを企業に提供してきました。GumGum は画像認識技術を使用して、関連するイメージの状況に応じたオーバーレイ、あらゆる画面サイズに適応するバナー、または周囲のコンテンツにシームレスに融合するフィード内プレースメントとして、対象を絞り込んだプレイスメントを配信しています。GumGum は、Visual Intelligence を使って、ブランドに関連するあらゆるイメージや動画についてソーシャルメディアやブロードキャスト TV を検索し、視聴者についてと、視聴者がソーシャルメディアでそのブランドにどのようにかかわっているかをより良く理解できるようにしています。GumGum はイメージ処理と広告配信オペレーションに AWS を利用しています。現在、AWS のインフラストラクチャを使って、世界中で 1 分あたり 1300 万件のリクエストを処理し、毎日 30 TB […]

Read More

新機能 – Time to Live (TTL) を使用した DynamoDB 項目の管理

AWS のお客様は を十分に活用しています。お客様は、その速度と柔軟性を気に入り、一貫性がある数ミリ秒台のレイテンシーを活かした広告技術 (リファレンスアーキテクチャ)、ゲーム(リファレンスアーキテクチャ)、IoT (リファレンスアーキテクチャ)、およびその他のアプリケーションを構築しています。また、DynamoDB はマネージ型のサーバーレスデータベースとして、数テラバイトというサイズのテーブルに対する 1 秒あたり数百万件ものリクエストを処理するようにスケールできる点も好評です。多くの DynamoDB ユーザーは、有効期限があるデータや、時間とともにアクセス頻度が低くなるデータを保存している場合があります。最近のログイン、トライアルのサブスクリプション、またはアプリケーションのメトリクスを追跡する場合もあります。保存期間が規制または契約で制限されるデータを保存している場合もあります。このような場合、これまでは独自の時間ベースのデータ管理を導入していました。大規模なケースでは、DynamoDB 項目のスキャン、データ属性のチェック、不要になった項目の削除リクエストの発行などを行うためだけに、数個の インスタンスを実行することもありました。これに伴って、アプリケーションのコストと複雑さが増大しました。 新しい Time to Live (TTL) による管理 この一般的で重要なユースケースを効率化するため、当社は本日から、新しい Time to Live (TTL) 機能の提供を開始します。この機能をテーブルごとに有効にし、項目の有効期限を含む項目属性を指定できます。項目属性を指定して TTL 管理を有効にすると (1 回の API コールで両方のオペレーションを実行できます)、DynamoDB が、有効期限が切れた項目を見つけて削除します。この処理は自動的にバックグラウンドで実行され、テーブルに対する読み取りまたは書き込みトラフィックに影響を与えることはありません。DynamoDB ストリーム(詳細については、「Sneak Preview – DynamoDB Streams」を参照) を使用して、実際の削除を処理またはアーカイブできます。削除は、ストリームの他の更新レコードのように、ローリング期間の 24 時間ベースで使用できます。有効期限が切れた項目については、AWS Lambda および DynamoDB トリガーを使用してコールドストレージへの移動、ログへの記録、または他のテーブルの更新を行うことができます。テーブルに対して TTL を有効にし、必要な属性を指定する方法を次に示します。 属性は DynamoDB の数値データ型とする必要があり、UNIX エポック時間形式に従って秒数として解釈されます。上記のスクリーンショットからおわかりのように、DynamoDB ストリームを有効にして、TTL を有効にしたときに削除される項目のプレビューを表示することもできます。また、コードから UpdateTimeToLive 関数を呼び出すか、 update-time-to-live コマンドを […]

Read More

AWS Organizations – 複数の AWS アカウントのポリシーベースの管理

複数の AWS アカウントを管理しているお客様が少なくありません。いくつかの理由が考えられます。AWS を徐々に導入して全体に広げている組織では、個別のチームや部門が一元管理されることなくクラウドコンピューティングに移行している場合があります。合併や買収を通じて成長している組織では、既存のアカウントを引き継ぐ場合があります。厳格なコンプライアンスのガイドラインに従うため、またはアプリケーション間に強い隔離障壁を設けるための通常の対策として複数のアカウントを作成する場合もあります。さらに開発、テスト、実稼働の目的別に異なるアカウントを使用する場合もあります。アカウント数が増大すると、全体をスケーラブルに管理する方法が必要になります。お客様は、チーム、部門、アプリケーションごとのアカウントを個別に扱わずに、アクセスコントロールポリシーを定義して全体、一部、または個別のアカウントに簡単に適用する方法を求めています。このようなお客様は、さらに請求やコスト管理にも関心が高い場合が多く、ボリュームディスカウントやリザーブドインスタンスなどの AWS の料金面でのメリットを、より広範囲にアカウントに反映できることを希望しています。 AWS Organizations がプレビューから一般公開へ このユースケースの重要性が増していることから、本日より、AWS Organizations のプレビューを終了して一般提供を開始します。AWS Organizations では複数の AWS アカウントを一元管理できます。組織単位 (OU) の階層構造を作成して各アカウントを OU に割り当て、さらにポリシーを定義して階層構造の全体、特定の OU、または特定のアカウントに適用できます。また、既存の AWS アカウントを招待して組織に追加できます。新規アカウントを作成することもできます。以上のすべての機能は、、、および AWS Organizations API から利用できます。AWS Organizations の理解に役立つ重要な用語と概念をいくつか紹介します (ユーザーが組織の AWS アカウント全体に対して全権を持ち、マスターアカウントを担当する管理者であることを前提とします)。 組織は、管理対象の AWS アカウントの統合セットです。新しい組織を作成して、サービスコントロールポリシーなどの高度なアカウントレベルのコントロールを実装できます。組織の管理者は、アカウント別に許可および拒否する AWS API 関数やリソースのリストを管理できます。たとえば、先端 R&D チームには広範な AWS のサービスへのアクセス権を与え、メインストリームの開発およびテストアカウントにはアクセス権を一部制限できます。または、実稼働環境では、HIPAA の準拠に該当する AWS のサービスに限ってアクセスを許可できます。AWS の既存のお客様は、一括請求 (コンソリデーティッドビリング) と呼ばれる AWS の機能を利用している場合があります。この機能で支払いアカウントを選択すると、複数の AWS アカウントのアカウントアクティビティを 1 つの請求書にまとめてコストを一元管理できます。今回のリリースで、現在一括請求をご利用のお客様は、AWS Organizations […]

Read More

週刊 AWS – 2017 年 2 月 20 日

お客様からのご要望にお応えして、この「マイクロ」版の週刊 AWS を作成しています。当社からのすべてのお知らせ、当社のすべてのブログのコンテンツ、およびコミュニティで作成された AWS コンテンツをできるだけ多く含めました。今後、ツールや自動化の準備が整い次第、他のセクションもご紹介していきたいと思っています。 月曜日 2 月 20 日 Amazon Athena が AVRO データのクエリをサポートし、米国東部 (オハイオ) リージョンで利用可能になり、Looker と統合されることを発表しました。 AWS Marketplace 出品セルフサービスでソフトウェアベンダーによる既存製品の編集が可能になることを発表しました。 Amazon CloudWatch がダッシュボードでアラームをサポートするようになったことを発表しました。 が適切な DynamoDB パーティションキーの選択に関するアドバイスを公開しました。 N2WS がクラウド開発者に対して Amazon Lightsail を使用しているか質問するブログを公開しました。 火曜日 2 月 21 日 が Amazon QuickSight での SPICE データセットの更新予定に関するブログを公開しました。 が Amazon Elasticsearch Service のアクセスコントロールを設定する方法に関するブログを公開しました。 が家族史産業の将来に関するブログを公開しました。 1Strategy が OpenVPN アクセスサーバーを使用した AWS 環境への安全な接続に関するブログを公開しました。 […]

Read More