Amazon Web Services ブログ

re:Invent で Amazon Rekognition をリリースし (「Amazon Rekognition – ディープラーニングがサポートする画像の検出と認識 (Amazon Rekognition – Image Detection and Recognition Powered by Deep Learning))、本年初頭にイメージモデレーションを追加しました。本日は、有名人の認識を追加します。Rekognition のトレーニングにより、政治、スポーツ、芸能、ビジネス、メディアなどの分野の有名人や著名人を多数識別できるようになりました。このリストはグローバルで、頻繁に更新されます。この機能にアクセスするには、新しい RecognizeCelebrities関数を呼び出します。既存の DetectFaces 関数によって返される境界ボックスおよび顔ランドマーク機能に加えて、新しい関数では認識される有名人に関する情報が返されます。 “Id”: “3Ir0du6”, “MatchConfidence”: 97, “Name”: “Jeff Bezos”, “Urls”: [ “www.imdb.com/name/nm1757263” ] Urls は、有名人に関する追加情報を提供します。現在、この API は IMDB コンテンツへのリンクを返します。今後は他のソースを追加する可能性があります。この機能をお試しになるには、AWS Management Console で有名人の認識デモをお使いください。 イメージアーカイブを持っている場合は、有名人別にインデックスを作成できます。有名人の認識とオブジェクトの検出を組み合わせて使用して、あらゆる種類の検索ツールを構築することもできます。イメージが S3 にすでに保存されている場合は、そこで処理できます。この新機能には、いろいろな面白い使い方があるかと思います。ご意見ご感想をお寄せいただき、皆様がどのようなものをビルドしたかお知らせください。 — Jeff;

私が最初に AWS Greengrassについて投稿したのは、re:Invent期間中でした。(AWS Greengrass -ユビキタス, 現実世界におけるコンピューティング) 我々は、ご興味をお持ちいただいたお客様を招待制という限定プレビューのかたちでローンチさせていただきました。 そのときに私がお知らせしたように、多くのAWSの顧客は、接続が遅く、時には断続的、信頼できない場合がある、現場でデータを収集して処理したいと考えています。Greengrassでは、AWSプログラミングモデルを小型で簡単なフィールドベースのデバイスに拡張することができます。 AWS IoTとAWS Lambdaをベースに構築されており、AWS Cloudで利用可能な多様なサービスへのアクセスをサポートしています。 一般利用可能 今日、Greengrassは米国東部（バージニア）と米国西部（オレゴン）のリージョンで一般利用可能になっています。プレビュー中、AWSのお客様はGreengrassでの実践的な体験を得て、その周辺のアプリケーションやビジネスの構築を開始できました。これらの初期の成功のいくつかをこの記事の後半で共有します。

Amazon S3とHadoop Distributed File System（HDFS）の間で大量のデータを移動する必要があったものの、データセットが単純なコピー操作には大きすぎるということはありませんでしたか？ EMRはこれを救うことができます。ペタバイト級のデータの処理と分析に加えて、EMRは大量のデータの移動もできます。 Hadoopエコシステムでは、DistCpがデータを移動するためによく使用されます。 DistCpは、MapReduceフレームワークの上に構築された分散コピー機能を提供します。 S3DistCpは、S3で動作するように最適化されたDistCpの拡張機能であり、いくつかの便利な機能が追加されています。 S3DistCpは、HDFSとS3の間でデータを移動するだけでなく、ファイル操作のスイスアーミーナイフです。この記事では、S3DistCpを使用するための基本的なユースケースから始めて、さらに高度なシナリオまでのヒントについて説明します。 変換なしにファイルをコピーまたは移動する ファイル圧縮を変更しつつコピーする ファイルを段階的にコピーする 1つのジョブで複数のフォルダをコピーする パターンに基づいてファイルを集約する サイズが1TBを超えるファイルをアップロードする S3DistCpステップをEMRクラスターにサブミットする

私が re:Invent 中に公開した投稿 (「AWS Greengrass – ユビキタスなリアルワールドコンピューティング」) で、初めて AWS Greengrass についてご紹介しました。その時点で限定プレビューの Greengrass の提供を開始し、関心をお持ちの場合はぜひサインアップしていただくよう皆様にお願いしました。そのときに説明したように、AWS の多くのお客様はフィールドでのデータの収集と処理を希望していますが、フィールドでの接続は低速で、中断したり信頼性が低くなったりすることが少なくありません。Greengrass では、AWS のプログラミングモデルを小型でシンプルなフィールドベースのデバイスに拡張することができます。これは AWS IoT と AWS Lambda 上に構築されていて、AWS Cloud で利用できる、増え続けるさまざまなサービスへのアクセスがサポートされます。Greengrass では、フィールドで実行され、AWS リージョンへ継続的な高帯域幅接続に依存しないコンピューティング、メッセージング、データキャッシュ、および同期の各サービスにアクセスできます。Python 2.7 で Lambda 関数を記述し、デバイスシャドウを使用して状態を維持しながら、クラウドから Greengrass デバイスにデプロイできます。デバイスと周辺機器は、クラウドを経由しないローカルメッセージングを使用して相互に通信できます。 一般提供を開始 本日、AWS は US East (Northern Virginia) および US West (Oregon) リージョンで Greengrass の一般提供を開始しました。プレビュー中に AWS のお客様は Greengrass を実際に体験し、アプリケーションやビジネスの構築を開始できました。これらの初期的な成功のいくつかは、この投稿の後半でお知らせします。Greengrass Core コードは各デバイスで実行されます。デバイスに Lambda アプリケーションをデプロイして実行し、セキュアなネットワークでローカル MQTT […]

私は実際の経験を非常に重視しています。ごくまれな状況を除いて、私のブログの投稿は、該当のサービスを使用してから書いています。「私は Amazon WorkSpace がお気に入りです」という投稿をお読みになっていれば、Amazon WorkSpaces が私にとって最も重要な生産性ツールの 1 つであることをご存知かと思います。お客様ご自身で、WorkSpaces を無料でお試しいただく機会についてお話したいと思います。 新しい Amazon WorkSpaces の無料利用枠では、2 つの標準バンドル WorkSpaces を起動し、最大 2 か月まで 1 か月あたり合計 40 時間ご使用になれます。Windows Server を利用した Windows 7 または Windows Server 10 のデスクトップ体験を選択できます。どちらのオプションにも、Internet Explorer 11、Mozilla Firefox、7-Zip、および Amazon WorkDocs と 50 GB のストレージが含まれています。無料利用枠を利用するには、AutoStop モードで WorkSpaces を実行する必要があります。これはデフォルトで選択されます。未使用の時間は最初の月の末日に期限切れになり、無料利用枠は 2 か月目の末日に期限切れになります。 その後は、Amazon WorkSpaces 料金表ページに記載されている時間レートで課金されます。使用を開始するには、クイックステップの手順に従って、無料利用枠の対象となるバンドルを選択してください。 本特典は、現在 WorkSpaces が利用可能なすべての AWS リージョンでご利用いただけます。 — Jeff;

こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー 6 月の配信に関しまして、テーマが確定しましたので改めてご案内させて頂きます。6 月は、AWSの新サービス、機能追加のご紹介や、5月30日から6月2日まで4日間に渡って開催されたAWS Summit Tokyo 2017の振り返りなど幅広いラインナップでお送りいたします。また今年から開始したオンラインハンズオンの開催もありますので、ふるってご参加いただければと思います。 ※ 2017/6/6追記: 6/20に予定していたAWS Lambda回は都合により7月に延期になりました。 6 月の開催予定 サービスカット 6/7(水) 18:00-19:00 Amazon Redshift Update – 最近追加された新機能とRedshift Spectrumの解説 6/14(水) 18:00-19:00 AWS Snowball 6/21(水) 18:00-19:00 Server Migration Service Application Discovery Service 6/28(水) 18:00-19:00 AWS Code Services Part 2 ソリューションカット 6/13(火) 12:00-13:00 AWS Summit Tokyo 2017 まとめ ハンズオン 6/28(水) 14:00-16:30 […]

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。 VPCサブネットのゾーニングパターンに関するシリーズ記事の第1回目では、SAPアプリケーションへのいくつかの接続方法を紹介し、内部専用接続のためのAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンについて詳細を説明しました。この第2回となる記事では、従来のアプリケーションにおけるネットワークのゾーニングをAWS上でどのように実装できるか説明します。 従来のオンプレミス環境の実装モデルでは、アプリケーションは様々なネットワークゾーンに分離されています： 制限付きゾーン: これは最も安全なゾーンで、機密データを管理します。例えば、会計や人事ソリューション、コンテンツリポジトリやファイルサーバー用のデータベースをここに配置します。 イントラネットゾーン: このゾーンは、制限付きゾーン内のデータベースにアクセスするアプリケーションサーバーを対象としています。例えば、SAP Advanced Business Application Programming(ABAP)、Java Central ServicesといったSAPアプリケーションサーバーをここに配置します。企業ネットワークに接続されるエンドユーザーのデバイスもこのゾーンにも配置されます。 エクストラネットゾーン: このゾーンには、SAP Process Orchestration(PO)やSAP Process Integration(PI)、SSH File Transfer Protocol(SFTP)サーバー、SAP TREXなどのミドルウェアを配置します。このゾーンは、外部ゾーンと内部ゾーンの間の中間ゾーンとして機能します。 外部ゾーン: このゾーンでは、インターネットに直面しているアプリケーションとアプライアンスを管理し、内部ゾーンのアプリケーションの入口または出口のポイントとして機能します。このゾーンに配置されるソリューションの例としては、Network Access Translation(NAT)インスタンス、リバースプロキシ、およびSAProuterです。 管理/共有サービスゾーン: 上記のすべてのゾーンで必要とされるMicrosoft Active Directory、管理サーバー、SAP Solution Manager、あるいはDNSサーバーなどのアプリケーションをこのゾーンに配置します。 インターネットゾーン: このゾーンは管理しませんが、ビジネスパートナーやSaaSプロバイダなどが管理するアプリケーションに接続するときは、このゾーンと連携します。 図 1：様々なネットワークゾーン 従来の環境では、ファイアウォールのルールを定義することによってゾーン間のトラフィックの流れを制御しています。AWSでは、サブネットレベルのステートレスなファイアウォールであるネットワークアクセスコントロールリスト(ネットワークACL)、インスタンスまたはElastic Network Interfaceレベルのステートフルなファイアウォールであるセキュリティグループ、そしてトラフィックがどこに向けられるかを決定する一連のルールとなるルートテーブルを使用してトラフィックの流れを制御します。 では、これらのゾーンをどのようにAWSに合わせて展開するのでしょうか？ 前回の記事で紹介したアーキテクチャでは、私たちは暗黙的にゾーンを定義し、サブネットレベルでアプリケーションを分離しています。エクストラネットゾーンを除くすべてのゾーンについて説明しました。 図 2：サブネットレベルの分離によるネットワークゾーンの配置 もちろん、サブネットはAWS上のアプリケーションを分離する唯一の方法ではありません。ゾーンごとに異なるVPCを使用してアプリケーションを限定することもできます。例えば、管理ゾーンに専用のVPCを作成し、VPCピア接続を使用して、(他のVPC内にある)他のゾーンと接続することができます。ただし、SAPアプリケーションサーバーやデータベースなど、密接に関連するコンポーネントを別々のVPCに分けることはお勧めしません。 […]

AWS Database Migration Service (AWS DMS) は、簡単かつ安全なAWSへのデータベース移行の手助けをします。AWS Database Migration Service は広く使われている商用データベースとオープンソースデータベースに対応しています。このサービスはOracleからOracleのような同一プラットフォームでの移行に対応していますし、Oracleから Amazon Aurora や、Microsoft SQL Server からMySQLのような異なるプラットフォーム間での移行にも対応しています。移行元のデータベースは移行中も完全に動作しつづけたままであり、データベースに依存するアプリケーションのダウンタイムを最小限に抑えます。 AWS Database Migration Service を使用したデータレプリケーションは、AWS Schema Conversion Tool (AWS SCT) と緊密に統合されており、異なるプラットフォーム間でのデータベース移行プロジェクトを簡略化します。異なるプラットフォーム間での移行には AWS SCT を使用できますし、同一プラットフォームであれば移行元エンジンの純正スキーマ出力ツールが使えます。 この投稿では、Oracle Database のデータウェアハウスから Amazon Redshift へのデータ移行にフォーカスします。 以前の AWS SCT では、Oracle Database のビューやファンクションなどのカスタムコードを Amazon Redshift と互換性のあるフォーマットに変換できませんでした。ビューとファンクションを変換するには、最初に Oracle Database スキーマをPostgreSQLに変換し、それから Amazon Redshift と互換性のあるビューとファンクションを抽出するスクリプトを実行する必要がありました。 お客様のフィードバックに基づいたアップデートの後、AWS SCT と […]

この投稿では、商用データベースから Amazon Aurora への移行を容易にするために AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) をどのように使えるかの概要をお伝えします。今回は、Oracleから Amazon Aurora with MySQL Compatibility への移行にフォーカスします。 データベースエンジンの変更は不安を伴うかもしれません。しかし、Amazon Aurora のようなスケーラビリティやコスト効果の高いフルマネージドサービスのバリュープロポジションは、それに挑戦する価値を生み出します。その手順を簡単にするツールがある場合は特にです。データベースをあるエンジンからほかのものに移行するとき、主に2つのことを考慮する必要があります。スキーマとコードオブジェクトの変換と、データ自身の移行と変換です。幸いにも、データベースの変換と移行の両方を容易にするツールをAWSは用意しています。 AWS Schema Conversion Tool は移行元データベースのスキーマとカスタムコードの大部分を新しい移行先データベースと互換性のあるフォーマットに自動的に変換することで、異なるプラットフォーム間でのデータベース移行をシンプルにします。このツールが変換するカスタムコードには、ビューやストアドプロシージャ、ファンクションを含みます。このツールで自動変換できない一部のコードは明確に示されるので、ユーザー自身でそれを変換することができます。AWS Database Migration Service は最小限のダウンタイムでデータを簡単かつ安全に移行することを手助けします。 すばらしい！ では、どこから始まれば良いのでしょう？ AWS SCT での移行手順 通常、移行の最初のステップは実現可能性と作業量のアセスメントです。現行のOracleからAuroraにデータベースを移行するために要する作業量の大枠な概要を AWS SCT は生成することができます。SCTはいくつかのOS上で動作しますが、このブログではWindows上で動かします。SCTをダウンロードするためには、マニュアルの AWS Schema Conversion Tool のインストールと更新 をご覧ください。SCTのマニュアル全体を見たい場合は AWS Schema Conversion Tool […]

皆様にうれしい発表があります。AWSは2018年に大阪に新たなリージョンを開設します。 本リージョンは、ローカルリージョンと呼ばれる新しい設計概念のデータセンターです。AWSのローカルリージョンは、旧来の単一データセンターのインフラ設計とは全く異なる、耐障害性の高い単一のデータセンターです。AWS アジアパシフィック（大阪）ローカルリージョンは、東京リージョンと連携して利用いただくことを想定しています。 東京リージョンには3つのアベイラビリティゾーン（データセンター群）を用意しているため、お客様はいずれか一つのデータセンターで障害が発生した場合でも支障をきたさない、耐障害性に優れ高い可用性を持つアプリケーション構築が可能となっています。 IT資産に対する災害対策として国内に地域的な多様性を重要視するお客さまは、東京リージョンを補完する形で大阪ローカルリージョンをご利用いただけるようになります。 当初、AWS アジアパシフィック（大阪）ローカルリージョンは招待制になります。詳細は、開設時期が近づきましたら改めて発表いたします。