Amazon Web Services ブログ

いくつかの必須の EC2 リソースに対する長い ID を提供するための以前の仕事のフォローアップとして、当社は移行の期日を 2018 年 7 月に設定して、同じことを残りの EC2 リソースに対しても行っています。ユーザーごと、リージョンごと、タイプごとにオプトインして、コード、正規表現、データベーススキーマおよびデータベースクエリが期待通りに動作することを確認できます。 EC2 リソースのタイプについて ID を認識、処理、または保存するコードがある場合は、注意深く、この投稿をお読みください。知る必要があることは、次のとおりです。 移行期日 – お使いのコードおよびスキーマが新しい、長い ID を処理し、保存できるのは、2018 年 7 月までです。その後、長い ID はすべての新しく作成されたリソースにデフォルトで割り当てられます。既存のリソースの ID は、そのまま残り、機能し続けます。 詳細なリソースタイプ – 長い ID はすべてのタイプの EC2 リソースに対してサポートされ、希望に応じてオプトインすることができます。 できるだけ早く、テストアカウントから始めて、オプトインするようにお勧めします。このことは、コードを徹底的にテストし、コードを本番稼働させるためにプロモーションする前に、必要な変更を行うための時間を与えます。 その他のリージョン – 長い ID は、現在、AWS 中国 (北京) および AWS 中国 (寧夏) リージョンで使用可能です。 AMI のテスト – テストするために使用できる長い ID をもつ AMI を発行しました […]

空間コンテキストでプロセスを記述するデータは、私たちの日常生活のいたるところにあり、ビッグデータの問題を支配しています。たとえば、道路ネットワークや衛星からのリモートセンシングデータを記述する地図データは、どこへ行く必要があるか示してくれます。シミュレーションやセンサーからの大気データは、天気予報や気候モデルの基礎となります。GPS を備えたデバイスおよびセンサーは、ほぼすべてのモバイルデータに空間的なコンテキストを提供できます。 この記事では、Amazon のクラウドサービスで世界に公開されている膨大な (500 TB) オープン気象モデルデータセットの WIND ツールキットを紹介します。このデータにアクセスする方法と、こうしたデータに簡単にアクセスできるように開発されたオープンソースソフトウェアのいくつかを説明します。このソリューションでは、グリッド (ラスタ) 上に存在する地理空間データのサブセットを検討し、気象モデルから大規模なラスタデータへのアクセスを提供する方法を探索します。このソリューションでは、基礎的な AWS のサービスと、科学データ用によく採用されている形式である Hierarchical Data Format (HDF) を使用します。

こんにちは、ソリューションアーキテクトの廣瀬です。 先月 (2018/3/13) 開催致しました AWS Black Belt Online Seminar 「AWS Well-Architected Framework によるコスト最適化」の資料を公開致しました。当日、参加者の皆様から頂いた QA の回答と併せてご紹介致します。

AWS Cloud9 は 2017年11月の AWS re:Invent で発表されました。Cloud9 はブラウザベースの IDE で、サーバレスアプリケーションも含め、数多くのクラウド上の開発ユースケースに適しています。AWS CloudFormation を使うことで AWS CodeCommit と連携した AWS Cloud9 の開発環境を迅速に構築することができます。このブログでは、CloudFormation を使った Cloud9 環境の構築手順を説明します。さらに Cloud9 の環境で Python と Boto3 のコードを書き、 Troposphere を使って CloudFormation の YAML テンプレートを生成する方法についても説明します。

こんにちは、ソリューションアーキテクトの上原です。 先日(2018/3/06)開催致しました AWS Black Belt Online Seminar 「 働き方改革を実現する AWS のエンドユーザーコンピューティングサービス」の資料を公開いたしました。当日参加者の皆様から頂いた QA の回答と併せてご紹介致します。

AWS データベースの顧客は、Amazon Elastic Compute Cloud (Amazon EC2) ホストを仮想プライベートクラウド (VPC) で起動してデータベースクライアントとして使用する必要がないため、費用を節約し、シームレスに拡張し、高可用性の実現します。EC2 ホストのプロビジョニングまたは管理を必要とせず実行するアプリケーションを、サーバーレスアプリケーションと呼んでいます。 この記事では、データベースが公開されていない場合でも、URL から AWS データベースを照会する方法について示します。この方法は、serverless-to-serverless クエリのために Amazon Aurora Serverless データベースに対しても実行が可能です ! Amazon Neptune 、Amazon Relational Database Service (Amazon RDS) for MySQL 、または Amazon RDS for PostgreSQL の各 Python スクリプトの選択を提供しています。また、次の 2 つのコンポーネントを設定して作成する方法についても説明します。 バックエンドデータベースに対してクエリを実行する AWS Lambda 関数 URLにアクセスする際に Lambda 関数を呼び出す　API Gateway REST API これらのコンポーネントを簡単に可能な AWS CloudFormation テンプレートを提供します。また、厳密には […]

re:Invent 2017 で登場した Amazon SageMaker は機械学習モデルを規模に応じてビルド、トレーニング、デプロイするためのサーバーレスデータサイエンス環境を提供します。お客様はまた、Scikit-learn など、最も身近なフレームワークで作業できます。 このブログ記事では次の 2 つの目標に沿って進めていきます。まずは、Amazon SageMaker がモデルのトレーニングやホストのためにどのようにコンテナを使用するかについて、高水準の説明を行います。続いて、Amazon SageMaker で Scikit モデルのトレーニングおよびホスト用に Docker コンテナをビルドする方法について説明します。 概要では、モデルのトレーニングとホスト用に Amazon Elastic Container Service (ECS) からロードされた Docker イメージが Amazon SageMaker 上でどのように実行されるかについて説明します。また、トレーニングコードや推論コードなど、SageMaker Docker イメージの仕組みについても説明します。 そのため、Amazon SageMaker で Scikit モデルをビルド、トレーニング、デプロイする方法についてのみ興味をお持ちの場合は、概要の部分を飛ばしてお読みください。SageMaker で最小限の手間で Scikit モデルをコンテナ化するかについて、ハンズオンでもご覧いただけます。 目次 Amazon SageMaker 用コンテナの概要 Scikit-学習との連携のビルド Amazon SageMaker 用コンテナの概要 SageMaker は、ユーザーがアルゴリズムをトレーニングし、デプロイできるように、Docker コンテナの用途を拡張します。開発者とデータサイエンティストたちは、コンテナを活用することで Docker をサポートするあらゆるプラットフォームで着実に稼動する標準化されたユニットにソフトウェアをパッケージングできるようになります。コンテナ化することで、コード、ランタイム、システムツール、システムライブラリ、設定などのすべてを 1 か所にまとめ、環境から分離し、どこで開始するかに関係なく、一貫したランタイムを確保します。 […]

オンプレミスのユーザー管理者が、AWS Managed Microsoft ADとも呼ばれる “AWS Directory Service for Microsoft Active Directory” を管理できるようになりました。 Active Directory（AD）信頼と新しいAWS委任ADセキュリティグループを使用すると、オンプレミスADディレクトリのグループメンバシップを管理することで、オンプレミスユーザーに管理アクセス許可を与えることができます。これにより、管理を実行できるユーザーを簡単に管理できます。また、管理者は、オンプレミスのAD資格情報を使用して既存のワークステーションにサインインして、AWS Managed Microsoft ADを管理できるため、管理者の作業が楽になります。 AWSは、AWS Managed Microsoft ADディレクトリに新しいドメインローカルADセキュリティグループ（AWS委任グループ）を作成しました。各AWS委任グループには、一意のAD管理者権限があります。新しいAWS委任グループのメンバーであるユーザーは、ユーザーの追加、細かいパスワードポリシーの構成、Microsoftエンタープライズ認証局の有効化などの管理タスクを実行するためのアクセス許可を取得します。 AWS委任されたグループは、範囲内のドメインローカルなので、オンプレミスADに対するAD信頼を使用してそれらを使用できます。これにより、AWS Managed Microsoft ADを管理するために別個のIDを作成して使用する必要がなくなります。代わりに、選択したオンプレミスユーザーを必要なAWS委任グループに追加することで、管理者に権限の一部またはすべてを付与できます。オンプレミスのADセキュリティグループをAWS委任グループに追加することで、これをさらに簡素化できます。これにより、オンプレミスのADセキュリティグループからユーザーを追加したり削除したりして、AWS Managed Microsoft ADの管理者権限を管理できるようになります。 このブログでは、オンプレミスのユーザーに権限を委任して、管理タスク（AWS Managed Microsoft ADディレクトリの細かなパスワードポリシーの設定）を実行する方法を説明します。この記事の手順に従うことで、グループマネージドサービスアカウントとKerberos制約付き委任の構成などの他の管理アクセス許可をオンプレミスのユーザーに委任できます。   背景 これまで、AWS Managed Microsoft ADは、組織単位（OU）にADセキュリティグループを作成し、これらのAWS委任グループに共通管理アクティビティを許可することによって、ディレクトリの管理者権限を委任していました。ディレクトリ内の管理者ユーザーは、OU内にユーザーアカウントを作成し、これらのユーザーにこれらのAWS委任グループの1つ以上にディレクトリを追加してディレクトリを管理する権限を与えていました。 ただし、オンプレミスADフォレストへの信頼をAWS Managed Microsoft ADに構成した場合、オンプレミスディレクトリのユーザーをこれらのAWS委任グループに追加することはできませんでした。これは、AWSがグローバルスコープのAWS委任グループを作成し、別のフォレストからのユーザーの追加を制限するためです。そのため、管理目的でAWS Managed Microsoft ADに異なるユーザーアカウントを作成する必要がありました。その結果、AD管理者は、通常、AWS Managed Microsoft ADの追加の資格情報を覚えておく必要がありました。 これに対処するために、AWSはドメインローカルスコープを持つ新しいAWS委任グループを、AWS Delegated Groupsと呼ばれる別個のOUに作成しました。ドメインローカルスコープを持つこれらの新しいAWS委任グループは柔軟性が高く、他のドメインやフォレストからのユーザーやグループの追加を可能にします。これにより、管理者ユーザは社内のユーザおよびグループの管理者権限をAWS Managed Microsoft ADディレクトリに委任できます。 備考: […]

こんにちは、ソリューションアーキテクトの上原です。 先日(2018/2/28)開催致しました AWS Black Belt Online Seminar「Amazon QuickSight」の資料を公開いたしました。当日参加者の皆様から頂いた QA の回答と併せてご紹介致します。

AWS X-Ray は、開発者がマイクロサービスやサーバレス・アーキテクチャで構築された本番環境のアプリケーションを分析及びデバッグすることを手助けし、顧客への影響を定量化します。AWS X-Ray を使うと、アプリケーション及びそのアプリケーションが依存しているサービスがどのように振る舞っているかを把握し、パフォーマンスの問題やエラーに対する根本原因の究明やトラブルシュートを行うことができます。これらの洞察を駆使してアプリケーションの問題点を見つけ出し最適化の機会を得ることができます。 このブログ記事では、X-Ray がアプリケーションにおける遅延やエラー、あるいは失敗の増加を検知したときに、どうすれば Amazon CloudWatch と Amazon SNS を使って通知を受信することができるのかをお見せします。特に、エンドユーザがあなたのアプリケーションを利用していて遅延の増加やサーバサイドのエラーに遭遇した際にEメールや SMS メッセージを通して通知を受け取るためにはどうすればよいでしょうか。サンプルアプリケーションを使ってお見せしたいと思います。サンプルアプリケーションは、コードを修正することによってアラームやイベントをカスタマイズすることも可能です。