Amazon Web Services ブログ

Amazon Polly は、テキストを生きた話し声に変換する AWS のサービスです。Amazon Polly に 9 つのリージョンが追加され、Polly が利用可能なリージョンの合計数が 14 となったことを発表いたします。さらに、韓国語サポートの開始、テキスト読み上げ機能ポートフォリオへのインド英語音声の追加を発表いたします。新しい韓国語の女性音声 Seoyeon、およびインド英語音声の Aditi をご紹介します。 Amazon Polly は、世界中のお客様に対して最大の安定性と最小のレイテンシーを提供するべく、以下の 14 の AWS リージョンで提供されます: アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、南米 (サンパウロ)、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、および米国西部 (オレゴン)。 Amazon Polly は re:Invent 2016 で発表されて以来、最も多いリクエストの 1 つとして、追加言語のサポートがありました。お客様からの最も多くのリクエストがあった言語の 1 つが韓国語です。お客様の需要にお応えして、最初の韓国語音声 Seoyeon を発表いたします。

AWS は AWS Deep Learning AMI に Conda ベースの AMI と Base AMI という 2 つの新しいバージョンを利用可能にしたことを発表しました。このブログでは、新しい AMI を最大限に活用するための手順と追加リソースについてご説明します。 Conda マネージド型環境を取り入れた新しい Deep Learning AMI Amazon Linux と Ubuntu を対象にした新しい Deep Learning AMI には、人気のオープンソースパッケージと環境管理ツールである Conda を使用して作成したディープラーニング用の Python 環境がプリインストールされています。Conda マネージド型 Python 環境は、Apache MXNet、TensorFlow、Caffe2、PyTorch、Keras、CNTK、Theano を含む、人気のディープラーニングフレームワーク用に事前設定されています。また、Python 環境にはそれぞれ Python 2 と Python 3 が含まれています。AWS マネジメントコンソールを使用して AWS EC2 インスタンスにログインすると、Conda 環境すべてを含むリストがコンソールメッセージとして表示されます。 次のコマンドを実行すると、このリストを取得できます。 conda […]

この度、AWS Deep Learning AMI の新しい 2 つのバージョンの提供を開始しました。人気のオープンソースパッケージと環境ツールの Conda を使用して作成したディープラーニングフレームワーク用に別の Python 環境を使用する Conda ベースの AMI、そして独自のカスタマイズしたディープラーニングモデルをデプロイするための GPU ドライバとライブラリを使用する Base AMI です。 学会と業界の両方に渡り、ディープラーニングテクノロジーはフレームワーク、アルゴリズム、そして新しい方法や理論に渡り、急速に進化しています。そのため、素早く安全にアルゴリズムをテストしたり、フレームワークの特定のバージョンの最適化、テストやベンチマークの実行、新しく始めるプロジェクト開始の共同作業などにおいてツールを必要とする開発者達にとって複雑の原因になっています。そこで、AWS Deep Learning AMI においても、そうした自由と柔軟性を提供するために仮想環境を追加することにしました。また、新たに開発者用リソースもセットアップすることで、これまで以上に AMI の理解を深めたり、プロジェクトに適切な AMI を選択したり、ハンズオンチュートリアルを利用できるようにしています。 Conda ベースの Deep Learning AMI Conda ベースの AMI は Conda を使用して作成したディープラーニングの Python 環境にプリインストールされています。各 Conda ベースの Python 環境は、人気のディープラーニングフレームワークの公式 pip パッケージと、その依存関係を含むように設定されています。たとえば、ニューラルネットワークモデルをトレーニングするためのディープラーニングコードを実行する準備が整い、完全に仕上がった仮想環境とお考えください。ステップバイステップガイドでは、任意のディープラーニングフレームワークを使用した環境をアクティブ化する方法や、シンプルな 1 行のコマンドを使用して環境を切り替える方法について説明しています。 AMI のメリットは他にもあります。AMI の環境は相互に孤立した自己完結型のサンドボックスとして稼働します。つまり、サンドボックス内でディープラーニングのコードを実行すると、実行時の環境を完全に見通し全体的に管理することができます。AMI の他のディープラーニング環境を中断してしまう心配なく、新しいソフトウェアパッケージをインストールしたり、既存のパッケージのアップグレードや環境変数を変更することができます。実行環境でこのレベルの柔軟性と詳細管理を行えるということは、一貫性のある再生可能な方法でディープラーニングモデルのテスト実行やパフォーマンスのベンチマークが行えることを意味しています。 最後に、AMI は Jupyter […]

昨年開催された AWS re:Invent で AWS OpsWorks for Chef Automate を公開しました。これはユーザーが AWS マネージド型の独自の Chef Automate サーバーを利用できるようにするものです。そして、ユーザーからのフィードバックを元に構築した Puppet Enterprise を OpsWorks に追加しました。 Puppet Enterprise は、管理されている各ノードでデプロイした puppet-agent を介してプロビジョニング、設定、インスタンスの管理を自動化できるようにします。設定は 1 回定義することができ、自動ロールバックとドリフト検出で何千件ものノードに適用することができます。AWS OpsWorks for Puppet Enterprise は、既存の Puppet マニフェストでシームレスに連動させながら、独自の Puppet マスターを管理する必要を排除します。 OpsWorks for Puppet Enterprise は、ユーザーの代わりに Puppet マスターサーバーを管理し、インストール、アップグレード、バックアップといった運用タスクを行います。また、ノード登録を簡素化したり、ノードのブートストラップの便利なスターターキットも提供しています。詳細については次をご覧ください。 Managed Puppet Master の作成 OpsWorks で Puppet マスターを作成するのは簡単です。まず、OpsWorks コンソールの [Puppet] セクションにアクセスし [Create […]

今年初めにリリースした x1e.32xlarge インスタンスは、4 TB のメモリを持つ 4 つの AWS リージョンを対象に利用可能となりました。そのリリースから 2 か月後の現在、ユーザーはハイパフォーマンスリレーショナルと NoSQL データベース、メモリ内データベース、そして大量のメモリを活用できる他のエンタープライズアプリケーションに、このインスタンスを使用しています。 X1e のサイズを 5 つ追加 メモリ最適化 X1e シリーズにインスタンスサイズを 5 つ追加しました。ラインアップは次の通りです。 モデル vCPU メモリ (GiB) SSD ストレージ (GB) ネットワーキングパフォーマンス x1e.xlarge 4 122 120 最大 10 Gbps x1e.2xlarge 8 244 240 最大 10 Gbps x1e.4xlarge 16 488 480 最大 10 Gbps x1e.8xlarge 32 976 960 […]

※11/20追記 直前のお知らせとなり申し訳ありません。11/21(火) 12:00-13:00に開催を予定しておりました「AWS上の位置情報」ですが、講師の都合により延期となりました。事前登録いただいておりました皆様、申し訳ございませんでした。また、改めて開催予定日を案内させていただきます。   こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー11月の配信についてご案内させて頂きます。初めてご紹介するNLB (Network Load Balancer) を中心としたELBのセッションをはじめ、今月も様々なテーマを取り扱います。 また今年もAWS re:Inventの開催期間中に現地からの生中継で最新アップデートをお伝えする回を予定しておりますので、こちらもぜひご登録いただければと思います。                   11月の開催予定 サービスカット 11/1(水) 18:00-19:00 Amazon EMR 11/15(水) 18:00-19:00 ELB Update – Network Load Balancer(NLB)と関連サービス 11/22(水) 18:00-19:00 AWS WAF – OWASP Top10脆弱性緩和策 – ソリューションカット 11/9(木) 12:00-13:00 Amazon Pinpoint で始めるモバイルアプリのグロースハック  ※ 通常の開催曜日と異なりますのでご注意ください 12/1(金) 12:00-13:00 […]

Aravind Kodandaramaiah は AWS パートナープログラムのパートナーソリューションアーキテクトです。 はじめに AWS ワークロードを実行するお客様は Amazon DynamoDB と Amazon Aurora の両方を使用していることがよくあります。Amazon DynamoDB は、どのような規模でも、一貫した、数ミリ秒台にレイテンシーを抑える必要のあるアプリケーションに適した、高速で柔軟性の高い NoSQL データベースサービスです。データモデルの柔軟性が高く、パフォーマンスが信頼できるため、モバイル、ウェブ、ゲーム、広告、IoT、他の多くのアプリケーションに最適です。 Amazon Aurora は、MySQL と互換性のあるリレーショナルデータベースエンジンで、オープンソースデータベースのコスト効率性と簡素性を備えた、高性能の商用データベースの可用性とスピードをあわせもったエンジンです。Amazon Aurora は、MySQL よりも最大 5 倍のパフォーマンスを発揮するだけでなく、商用データベースのセキュリティ、可用性、および信頼性を 10 分の 1 のコストで実現します。 DynamoDB と Aurora を連携させるために、カスタムウェブ解析エンジンを構築して、毎秒数百万のウェブクリックが DynamoDB に登録されるようにしたとします。Amazon DynamoDB はこの規模で動作し、データを高速に取り込むことができます。また、このクリックストリームデータを Amazon Aurora などのリレーショナルデータベース管理システム (RDBMS) にレプリケートする必要があるとします。さらに、ストアドプロシージャまたは関数内で SQL の機能を使用して、このデータに対してスライスアンドダイスや、さまざまな方法でのプロジェクションを行ったり、他のトランザクション目的で使用したりするとします。 DynamoDB から Aurora に効率的にデータをレプリケートするには、信頼性の高いスケーラブルなデータレプリケーション (ETL) プロセスを構築する必要があります。この記事では、AWS Lambda と Amazon […]

自律走行シリーズ 1 回目のブログでは、Donkey カーの構築と Amazon EC2 インスタンスでパイロットサーバーをデプロイしました。そして、2 回目のブログでは Donkey カーの運転を学び、Donkey カーが自律走行を学びました。今回のブログでは、Donkey カーから AWS にテレメトリをストリーミングするプロセスをご紹介します。スケーラブルで信頼性が高く、当社の接続済み自律走行車など様々な接続済みデバイスに対し多機能な一連のサービスを提供する AWS IoT を使用します。 1) AWS 自律走行車を構築し re:Invent の Robocar Rally でレースに参加 2) 自律走行車の構築 パート 2: 自律走行車の運転 3) 自律走行車の構築 パート 3: 自律走行車の接続 4) 近日中に公開予定 AWS IoT のセットアップ 自律走行車は運転中に絶え間なくテレメトリをストリーミングします。自律走行車が稼働していない場合は収集するテレメトリがないため、リソースを使用しないことで無駄を避けます。ワークロードに対応するため、アーキテクチャ全体の稼働においてはサーバーレステクノロジーに依存します。開始するには、まず AWS IoT を使用してフリートモニタリングサービスを設計します。同じ基本的なアーキテクチャを使用して、その数に制限なく自律走行車に使用できます。次の図はフリートモニタリングサービスのアーキテクチャを示しています。 同ソリューションのコンポーネントは、論理的な機能 (および AWS のサービス) 別に色分けされ、ソリューションの各コンポーネントが安全でスケーラブルであり、完全に使用量ベースであることが示されています。この種のオペレーションモデルは様々なビジネスモデルで役立ち、幅広いサイズの顧客にとっても便利です。週末に趣味で自律走行車をレースしてラップタイムを比較したり、自動車メーカーが独自の接続された車両プラットフォームを開発したい場合でも、AWS IoT は安全でスケーラブルな使用量ベースのコスト構造を提供しています。 このソリューションは緑の網掛け部分の Donkey カーから始めます。次にデータが IoT サービスを通過してピンクのセクションに移動します。このセクションは DynamoDB の短期間用データストレージです。その後、S3 […]

–この記事はAWS セキュリティ・アシュアランス本部の寄稿です– 2016年12月に AWS Artifact のサービスが開始され監査レポート等コンプライアンスに関する重要な情報を提供してきましたが、2017年11月より同サービスにおいて、日本のお客様に向けて「日本準拠法に関する AWS カスタマーアグリーメント変更契約」の手続きが可能な新機能の提供を開始しました。これにより、AWS Artifact を通じて日本準拠法に関する AWS カスタマーアグリーメント変更契約をリアルタイムに締結または終了することが可能となっています。 日本準拠法に関する AWS カスタマーアグリーメント変更契約とは、現在お客様がご利用中の AWS アカウントに適用されている、 AWS カスタマーアグリーメントの準拠法および管轄裁判所を変更する契約を指します。この契約を有効にすることで、 AWS カスタマーアグリーメントの準拠法を日本法に変更し、更に、同契約に関するあらゆる紛争に関する第一審裁判所を東京地方裁判所に変更することができます。 従来、AWSカスタマーアグリーメントの準拠法および管轄裁判所を変更する際に、その都度、書面で契約を締結して頂く必要がありましたが、AWSアカウントのマネジメントコンソールからお客様ご自身で受諾（有効に）することで、お客様の手間を省略することが可能となっています。 AWSでは今後も日本のお客様の声に耳を傾け、サービスの拡充に努めていきます。 【AWS Artifactの操作方法】 AWS Artifactを使用した日本準拠法に関するAWSカスタマーアグリーメントの変更方法、操作方法については下記のリンクから動画をご参照ください。より詳細なAWS Artifactの情報については以下のartifactのページをご参照ください。 https://aws.amazon.com/jp/artifact/   【留意事項】  日本準拠法に関する AWS カスタマーアグリーメントは、請求連絡先アドレスが日本国内にあるアカウントに対してのみ提供されるものです。 複数のアカウントをお持ちのお客様の場合、アカウント毎に有効にして頂く必要があります。 既に個別に書面でカスタマーアグリーメントの準拠法および裁判管轄を変更する契約を取り交わしているお客様については、再度締結いただく必要はございません。 その他の詳細については下記のページをご参照ください。 https://aws.amazon.com/jp/artifact/faq/   – AWS セキュリティ・アシュアランス本部    

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。 VPCサブネットのゾーニングパターンに関するシリーズ記事の第1回目では、SAPアプリケーションへのいくつかの接続方法を紹介し、内部専用接続のためのAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンについて詳細を説明しました。第2回目では、従来のアプリケーションにおけるネットワークのゾーニングをAWS上でどのように実装できるか説明しました。このシリーズの最後の記事として、内部接続と外部接続の両方を必要とするSAPアプリケーションの接続パターンを説明します。外部ソースからの接続は管理されていてもよく(つまり、既知の外部の関係者を含む)、管理されていない(つまり、公開されていてもよい)場合もあります。両方のシナリオについて説明します。 内部および管理された外部接続 外部向けインターフェースに対する信頼された外部の関係者からの接続と、内部向けインターフェースに対するSAPと非SAPシステム間またはどちらかの間の接続が必要となる、SAP Process Orchestration(PO)とSAP Process Integration(PI)がこのシナリオの典型的な例です。内部向けインターフェースは簡単に管理できます。基本的には、ルートテーブル、ネットワークアクセスコントロールリスト(ACL)、およびセキュリティグループに適切なトラフィックを定義します。しかしながら、外部接続を安全に提供することには課題があります。そこで、信頼できる外部の関係者からのトラフィックの入口と出口に着目しましょう。典型的な選択肢が4つあります。 入口と出口の両方のための仮想プライベートネットワーク(VPN)接続 入口用のElastic Load Balancing、および出口用のネットワークアドレス変換(NAT)ゲートウェイ NATデバイス(NATインスタンスまたはNATゲートウェイ) リバースプロキシ VPN接続 (入口と出口) 信頼できる外部の関係者と専用の仮想接続を作成する場合は、VPCでVirtual Private Gateway(VGW)を使用するか、パブリックサブネット内にAWS Marketplaceで公開されているような独自のソフトウェアVPNサーバを使用することで、サイト間IPsec VPN接続を確立できます。 注釈   この記事のアーキテクチャ図では、簡単にするために単一のアベイラビリティゾーンで示しています。実際には、高可用性を実現するために、少なくとも2つのアベイラビリティゾーンにわたってソリューションを構成することをお勧めします。 図 1: 管理された外部接続のためのVPNコネクション Elastic Load Balancing (入口) / NATゲートウェイ (出口) Elastic Load Balancingには、次の3つのタイプがあります。 Classic Load Balancer Network Load Balancer Application Load Balancer […]