Category: General

AWS Single Sign-On で AWS Command Line Interface (CLI) を使ったアクセスが簡単にご利用できるようになりました。AWS Single Sign-On (AWS SSO) のユーザポータルに既存の企業内の認証情報を使ってサインインして、AWS アカウントとパーミッションセットを選択すると、AWS CLI で使用できる一時的な認証情報を取得できるようになりました。 AWS SSO は複数の AWS アカウントやビジネスアプリケーションへのシングルサインオンでのアクセスを集中管理できるサービスです。AWS の一時的な認証情報は AWS CLI などの開発者用ツールで AWS サービスを管理するための短期間限定の認証を簡単に実現する方法です。 これまで AWS アカウントのリソースにアクセスするのに CLI を使ってコマンドを実行する場合は、各アカウントごとにパスワードを記憶しておき、サインインして認証情報を一度取得する必要がありました。今回、AWS SSO は各 AWS アカウントにサインインして認証情報を取得する必要をなくします。代わりに、AWS SSO ユーザポータルに既存の企業内の認証情報を使ってサインインし、権限が与えられた AWS アカウントの一時的な認証情報を取得して CLI でアカウント内のリソースにアクセスすることができます。一時的な認証情報は、許可されている権限に制限されています。 このブログ記事では、AWS SSO ユーザポータルから一時的な認証情報を取得して、AWS CLI で AWS アカウント内のリソースにアクセスする方法を紹介します。まず、権限が与えられているアカウントのパーミッションセットのための短期間限定の認証情報を取得する方法を説明します。そして、認証情報を使う３つの方法を紹介します。 紹介するシナリオでは、”AnyCompany”の管理者をしており、２つの AWS アカウントに対して AWS CLI […]

本日(2018/02/20)、インターリージョンVPCピアリングが AWSの欧州(ロンドン)、欧州 (パリ)、アジアパシフィック (ムンバイ)、アジアパシフィック (シドニー)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、カナダ (中部) 、南アメリカ(サンパウロ) が、従来の米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、欧州(アイルランド)に加えて利用可能になりました。 インターリージョンVPCピアリングでは、Gateway、VPNコネクション、ネットワークアプライアンスなどを使う事なく、別なリージョンで稼働しているEC2インスタンス、RDSデータベース、LambdaファンクションなどのVPCリソースに対してPrivate IPアドレスにて通信が可能です。 インターリージョンVPCピアリングは、リージョン間のリソース共有や地理的な冗長性を得るためのデータレプリケーションに関して、シンプルかつコスト効率の良い方法となります。インターリージョンVPCピアリングはVPCと同様な水平方向のスケール、冗長、高可用性テクノロジーにより構築されており、単一障害点や帯域のボトルネック無しに暗号化します。インターリージョンVPCピアリングのトラフィックは常にグローバルAWSバックボーンにとどまり、パブリックなインターネットを横断することは無く、一般的な悪用であったりDDoS攻撃のような脅威を減らすことができます。 インターリージョンVPCピアリングコネクションによって転送されたデータのコストは、インターリージョン間の通常のデータ転送費用となります。 さらなる情報については、Amazon VPC Peeringのドキュメントをご参照下さい。 翻訳は SA菊池が担当いたしました。 原文：こちら

AWS Glue には、ネストされた JSON をリレーショナルデータベースに簡単にインポートできるカラムに変換することによって抽出、変換、ロード (ETL) プロセスをシンプル化する、Relationalize と呼ばれるトランスフォームがあります。Relationalize は、ネストされた JSON を JSON ドキュメントの最外部レベルでキーと値のペアに変換します。変換されたデータでは、ネストされた JSON からの元のキーのリストが、ピリオドで区切られた形で維持されます。 サンプルユースケースを使って Relationalize がどのように役立つかを見てみましょう。 Relationalize の実行例 ビデオゲームの開発者が、JSON 形式で保存されたデータに基づいてプレイヤーの行動についてのレポートを実行するために Amazon Redshift などのデータウェアハウスを使用したいとしましょう。サンプル 1 は、ゲームからのユーザーデータ例を示しています。「User1」という名前のプレイヤーには、ネストされた JSON データ内に種族、クラス、ロケーションなどの特徴があります。さらに下に行くと、プレイヤーの武器情報に追加のネストされた JSON データが含まれています。開発者がデータウェアハウスに対してこのデータの ETL を行いたい場合、コードではネストされたループや再帰的関数を用いなければならないかもしれません。 サンプル 1: ネストされた JSON { “player”: { “username”: “user1”, “characteristics”: { “race”: “Human”, “class”: “Warlock”, “subclass”: “Dawnblade”, “power”: 300, “playercountry”: “USA” }, […]

この記事は、Full 360 のソリューションアーキテクトである Jeremy Winters と Ritu Mishra によるゲスト投稿です。2 人によると、「Full 360 はクラウドファースト、クラウドネイティブのインテグレーターで、2007 年の創立以来の忠実なクラウド信者です。私たちの焦点は、クラウドへの旅におけるお客様の援助であり続けています。ビッグデータとウェアハウジング、アプリケーション近代化、そして Cloud Ops/戦略といった私たちの業務分野は、深いだけではなく、明確な専門知識を表しています。」 AWS Glue は、簡単でコスト効果の高い方法でデータの分類、消去、強化、およびさまざまなデータストア間を確実に移動することができる、完全マネージド型 ETL (抽出、変換、ロード) サービスです。 10年もの間クラウド内にデータウェアハウスソリューションを構築してきた企業として、Full 360 はカスタマーソリューションで AWS Glue をどのように活用できるかについて興味を持っていました。この記事では、当社が Amazon Redshift データ統合ユースケースのための AWS Glue の使用からの得た経験と教訓について詳しく説明していきます。 UI ベースの ETL ツール 当社では、re:Invent 2016 で AWS Glue が発表された当時からそのリリースを心待ちにしていました。私たちの顧客の多くは、データ変換パイプラインを管理するための使いやすい UI ベースのツールを探しています。しかし当社の経験では、どの生産パイプラインの複雑性も、それらを作成するために使われたテクノロジーに関わらず、解消しづらい傾向にあります。Full 360 では, データ統合を処理するためにコンテナにデプロイされたクラウドネイティブなスクリプトベースのアプリケーションを構築しており、スクリプトベースの変換は、発生するデータ問題に対応するために必要なロバスト性と柔軟性のバランスを提供すると考えています。 AWS Glue は、スクリプトを記述することを好む開発者と、UI ベースのインタラクションを望むユーザー両方の要望に応えます。データのソースとターゲットを選択することにより、UI を使ってジョブを初期に作成することが可能です。AWS Glue は内部で Python […]

本日 日本で2番目、ローカルリージョンとしては AWS 初となる、 Asia Pacific (Osaka) Local Region（以下、AWS 大阪ローカルリージョン）がご利用いただけるようになりました。 2017 年 5 月 31 日 AWS Summit Tokyo 2017 の基調講演にて、 2018 年より利用できるお知らせをしました。AWS 東京リージョンをお使いのお客さまにおいては、規制対応のため補完的なインフラストラクチャを準備し、アベイラビリティゾーン間を地理的に離す必要のある特定のアプリケーションの運用が可能になる点、多くの反響をいただきました。 AWS 東京リージョンが開設した 2011 年から、お客様は、同リージョンの 4 つのアベイラビリティゾーンを利用することで、いずれか 1 つのデータセンターで障害が発生した場合でも支障をきたさない、優れた耐障害性と高可用性を持つアプリケーション構築が可能になりました。すべての AWS リージョンは、複数かつ地理的に分離されたアベイラビリティゾーンから構成されます。アベイラビリティゾーンとは、 1 つの障害が可用性に影響を与えるリスクを大幅に減らすために、十分地理的に離れた地点に位置する一方で、迅速なフェイルオーバーが求められる事業の継続性に関わるアプリケーションのニーズを満たすために、十分近い距離に位置する独立したテクノロジーインフラストラクチャです。また、各アベイラビリティゾーンは、独立した電源および冷却システム、物理的セキュリティを擁し、大容量な光ファイバーネットワークを通じて Amazon のグローバルバックボーンネットワークに接続しています。AWS 大阪ローカルリージョンは、当初、単一のアベイラビリティゾーンのみを提供し、データセンター間をこれまで以上に地理的に離すことで、特定のアプリケーションのニーズに対応します。 AWS 大阪ローカルリージョンは、通常の AWS リージョンと同じように、他の AWS リージョンから独立し、 AWS リージョン内に独立した API エンドポイントを有します。大阪ローカルリージョンは、東京から 400 キロメートル離れた地点に位置しているため、 AWS 東京リージョンからさらに離れた場所に、拡張可能なデータセンターが必要なお客様に適しています。 IT 資産に対する追加の対策として、国内に地域的な多様性を重要視するお客さまは […]

こんにちわ。プロダクトマーケティング エバンジェリストの亀田です。 日々セミナーなどで皆さんにいろいろなコンテンツをお届けしていますが、その中でとても多くの再演要望をいただいているセミナーがあります。今回その「見積もり作成のハンズオン」をオンデマンドウェビナーとしてご提供することができるようになりました。お申込みをいただければ、いつでも皆さんが必要な時に視聴できるようになっています。是非こちらからお申込みください。 全部で3部構成となっています。 Part 1： Amazon EC2、Amazon RDS 等 主要サービスの費用について基本的な考え方をまとめています。   Part 2： 概算費用算出における検討事項のポイントやお支払方法についてまとめています。 クラウドは IT リソースの伸縮が自由であり、オンプレミス型の IT とは考え方が異なる部分が多くあります。見積もり作成において、そのあたりの注意点が含まれています。また日本円支払い、請求書支払いについてもまとめました。 Part 3： 実際の練習問題をもとに簡易見積もりツールを用いて、皆さんに見積もりを作成いただくハンズオン形式になっています。AWS の提供するクラウドサービスは、従量課金で費用想定が複雑だと思われるかたもいらっしゃるかもしれません。実際は、非常に簡易に概算費用の予測が可能となっています。是非お試しください。 より複雑な構成での概算費用が必要な方は、担当アカウントマネージャにお問い合わせいただくか、こちらのお問い合わせフォームまでお問い合わせください。 また、見積もりではなく、 AWS の基本的なコンセプトなどの独習をご希望される方は、弊社シニアプロダクトマーケティングマネージャー 石橋による、はじめての AWS オンデマンドウェビナーを合わせてご視聴ください。   – プロダクトマーケティング エバンジェリスト 亀田

こんにちは。ゲームソリューションアーキテクトの吉田です。 昨日1/24(水)に第２回となるGaming Tech Nightを開催し、多くのゲーム開発者、インフラエンジニアの方々にご参加いただきました。Gaming Tech Nightは過去2016年に開催された、ゲームに特化した技術情報をお届けすることを目的としたAWS主催のイベントでしたが、今年からは定期開催イベントとして新しく生まれ変わりました。記念すべき再開１回目となる今回は、re:Born(再始動)というタイトルでサーバレスやCI/CDなど複数のテーマで計４セッションをお届けしました。   サーバレスアーキテクチャ入門 ~ Game Server Services 丹羽様 Game Server Services株式会社 代表取締役社長CEOの丹羽様より、サーバレスアーキテクチャについてご講演いただきました。入門というタイトルですが、サーバレスの定義から実装に関する注意点、実際に丹羽様が構築・運用する中で習得されたノウハウなどが詰まった内容の濃いセッションでした。これからサーバレスをはじめる方だけでなく、すでに構築・運用されている方々にも非常に参考になるポイントが多かったのではないかと思います。登壇資料はGS2 Blogで公開されています。   AWSにおけるモバイルゲーム向けAPIサーバの実装2018 ~ ソリューションアーキテクト 畑 ソリューションアーキテクトの畑より、モバイルゲームを対象としたAWSにおけるAPIサーバ実装について解説しました。典型的な実装パターンである３層Webアプリケーションパターンをはじめ、API Gateway+Lambda+DynamoDBを利用したサーバーレスアーキテクチャ、アプリケーション上で実装されたAWS SDKを通じて各AWSサービスのAPIに直接アクセスする2-Tierアーキテクチャなどの実装ポイントをご紹介しました。また、現在Public Preview中であるAWS AppSyncによる実装パターンにも触れました。API用のクエリ言語であるGraphQLは、クライアント〜サーバ間で共有される型が利用できたり、クライアント側からサーバのレスポンスデータの形式を指定できたりとモバイルゲームでも応用できる多くの利点があります。AWS AppSyncはマネージドなGraphQLのサービスであり、ゲーム開発者の方にもインフラを意識することなくご利用いただけます。ぜひPreviewにご参加ください。 Serverless backendformobilegame and_aws-appsync_gamingtechnight-2 from Amazon Web Services Japan   AWS上で実現するゲーム開発CI/CDパイプライン ~ ソリューションアーキテクト 森 ソリューションアーキテクトの森からは、AWSのCode系サービスを利用したゲーム開発におけるCI/CDパイプラインの実装例の解説とデモを披露しました。ソースコードをCodeCommitにpushし、CodeBuildによるビルド、CodeDeployによるステージング環境へのデプロイ、そしてステージングでのテスト完了後に再度CodeDeployを使って本番環境にという一連の流れをCodePipelineを自動化することが可能です。特にコードのビルドについては、ビルド用で常にインスタンスを確保されているお客様も多いと思いますが、CodeBuildはビルド実行時間のみの課金となりますので、コストが削減できるケースも多いと思います。ぜひゲーム開発のCI/CDにおいてもAWSのマネージドサービスをご活用ください。 Gaming cicd-pipeline gaming-technight-2 from Amazon Web Services Japan   AWSを最大限活用したロングヒット戦略 ~ Amazon […]

私たちは、AWS Glue の ETL(Extract、Transform、Load)を実行するためのスクリプトにおけるScalaのサポートを発表することに興奮しています。Scala が好きな人達は強力な武器を1つ手に入れることになり喜んでくれるでしょう。AWS Glue では Apache Spark をデータ加工のエンジンとして使用していますが、Scala は Apache Spark のネイティブな言語です。 洗練された言語としての機能が使える以外にも、Glue のスクリプトをScala で書くことはPython で書くことに比べて2つの利点があります。まずは、Python とApache Spark のScala ランタイム(JVM)の間でデータを移す必要がないので、Scala は大量のデータ移動を伴う加工整形処理がより高速です。サードパーティのライブラリで独自の変換を作成したり関数を呼び出すことができます。 次に、Scala はJava と互換性があるように設計されているため、外部Java クラスライブラリの関数をScala から呼び出すことが簡単です。 そのため、Scala のコンパイル結果は Java と同じバイトコードになりますしデータ構造を変換する必要もありません。 これらの利点を説明するために、GitHubアーカイブから入手可能なGitHub パブリックタイムラインの最近のサンプルを分析する例を説明します。このサイトはGitHubサービスへのパブリックリクエストのアーカイブで、コミットとフォークから、イシューとコメントまで35種類以上のイベントタイプを記録しています。 この記事は、タイムラインのネガティブなイシューを特定するScala スクリプト作成の方法を紹介します。このスクリプトではタイムラインサンプルのイシュー イベントを引き出し、Stanford CoreNLPライブラリのセンチメント推定機能を使用してタイトルを分析し、最もネガティブなイシューを浮き彫りにしています。 入門 スクリプトを作成する前に、AWS Glue Crawler を使ってデータ構造と特性を理解します。また、開発エンドポイントとZeppelin ノートブックをセットアップすることで、データをインタラクティブに探索してスクリプトを作成することもできます。 データをクロールする この例で使われているデータセットは、GitHub アーカイブからAmazon S3 のサンプルデータセットバケットにダウンロードされています。場所は以下の通りです： s3://aws-glue-datasets-<region>/examples/scala-blog/githubarchive/data/ <region>をあなたの作業中のリージョンに置き換えて最適なフォルダを選択してください。例えばap-northeast-1 などです。AWS Glue Developer Guide […]

本日 東京リージョンにて、新たにアベイラビリティゾーンを追加しました。東京リージョンは、追加のアベイラビリティゾーンを合わせ、4つのアベイラビリティゾーンになりました。 AWSは、世界中に18の物理的なリージョンと51のアベイラビリティゾーンがあります。本日追加されたアベイラビリティゾーンは、シンガポールリージョンに続き52番目となり、東京リージョンでAWSのクラウドコンピューティングをご利用の10万以上のお客さまにご利用いただけます。 アベイラビリティゾーンは、自然災害やデータセンター単位の障害などビジネスに影響を与えるリスクを最小化するよう地理的に影響を受けない十分離れた場所にあり、フェイルオーバーを実現し事業継続性を確保できるインフラストラクチャです。各アベイラビリティゾーンは、独立した電源、空調、物理的なセキュリティを備え、広帯域でハイスピードの光回線のバックボーンに接続されています。AWSのお客さまは、アプリケーションを複数のアベイラビリティゾーンを利用することで高い耐障害性を実現することができます。また、100以上の Amazon CloudFront エッジロケーションにより遅延を最小化しつつ、ウェブサイト、アプリケーションおよびコンテンツの配信が可能となります。 すでに東京リージョンをお使いのお客さまは、追加されたアベイラビリティゾーンにおいて、東京リージョンで利用可能なすべてのサービスを利用できます。

あけましておめでとうございます。パートナーソリューションアーキテクトの相澤です。2018年1月のAWS Black Belt オンラインセミナーの配信についてご案内させて頂きます。 昨年度開催された、re:invent 2017の振り返りは、みなさまお済みでしょうか？　多くの新サービス、新機能が発表されましたが、2018年1月のBlackBeltでは、その振り返りをしていきたいと思います。 1月16日(火) 12:00～13:00 Machine Learning / Database 1月17日(水) 18:00～19:00 Compute、Container / Network 1月23日(火) 12:00～13:00 IoT / DevOps 1月24日(水) 18:00～19:00 Security / Other お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。