Amazon Web Services ブログ

【新リージョン】2018年に大阪ローカルリージョンを開設予定

皆様にうれしい発表があります。AWSは2018年に大阪に新たなリージョンを開設します。

本リージョンは、ローカルリージョンと呼ばれる新しい設計概念のデータセンターです。AWSのローカルリージョンは、旧来の単一データセンターのインフラ設計とは全く異なる、耐障害性の高い単一のデータセンターです。AWS アジアパシフィック(大阪)ローカルリージョンは、東京リージョンと連携して利用いただくことを想定しています。

東京リージョンには3つのアベイラビリティゾーン(データセンター群)を用意しているため、お客様はいずれか一つのデータセンターで障害が発生した場合でも支障をきたさない、耐障害性に優れ高い可用性を持つアプリケーション構築が可能となっています。

IT資産に対する災害対策として国内に地域的な多様性を重要視するお客さまは、東京リージョンを補完する形で大阪ローカルリージョンをご利用いただけるようになります。

当初、AWS アジアパシフィック(大阪)ローカルリージョンは招待制になります。詳細は、開設時期が近づきましたら改めて発表いたします。

Cloud Directory の更新 – Typed Links のサポート

今年始めに公開したブログ「Cloud Directory – 階層データの AWS クラウドネイティブディレクトリ (Cloud Directory, our cloud-native directory for hierarchical data)」では、厳密に型指定された入力の階層データを大量保存できるように設計された方法について説明しました。Cloud Directory は何百万というオブジェクトを保存するようにスケールできるので、様々なクラウドアプリケーションやモバイルアプリケーションに最適です。最初のブログ投稿では、どのようにして各ディレクトリに 1 つ以上のスキーマがあるか、そしてそれにより 1 つまたはそれ以上のファセットがあるかについて説明しました。各ファセットは、オブジェクトの必須の属性および許容される属性の一連を定義します。

Typed Links の概要
本日より、Typed Links のサポートを追加することで Cloud Directory モデルの表記枠を拡大しました。次のリンクを使用して複数の階層に渡りオブジェクトとオブジェクトの関係を作成できます。ディレクトリにある複数のタイプのリンクをそれぞれ定義することができます (各リンクの種類はディレクトリと関連付けているスキーマ 1 つの個別ファセットです)。タイプの他に、各リンクには一連の属性を与えることができます。Typed Links は、他のオブジェクトと関係する既存のオブジェクトを不注意に削除しないようにすることで、参照データの整合性を維持する上で役立ちます。たとえばロケーション、ファクトリー、フロア番号、ルーム、マシン、センサーなどのディレクトリがあるとします。こうした情報はそれぞれ階層内で豊富なメタデータ情報を含む Cloud Directory のディメンションとして表示することが可能です。Typed Links を定義し使用することで、様々な方法でオブジェクトを連携させたり、メンテナンス要件に繋がる Typed Links の作成、サービス記録、保証、安全情報などをリンクの属性を使用してソースオブジェクトと対象オブジェクト間の関係の追加情報を保存できます。そしてリンクタイプや属性の値をベースにクエリを実行することができます。たとえば、過去 45 日以内に消去されていないすべてのセンサーや、保証期間が過ぎたモーターをすべて探すことができます。指定されたフロアにあるすべてのセンサーを探したり、指定されたタイプのセンサーがあるフロアすべてを探すことができます。

Typed Links を使用する
Typed Links を使用するには、1 つ以上の Typed Link ファセットをスキーマに追加します。追加するには CreateTypedLinkFacet関数を呼び出します。次に AttachTypedLink を呼び出し、ソースオブジェクトと対象オブジェクト、Typed Link ファセット、そのリンクの属性を受け渡します。その他の便利な機能として GetTypedLinkFacetInformationListIncomingTypedLinks、および ListOutgoingTypedLinks があります。詳細や機能一覧を確認するには「Cloud Directory API リファレンス (Cloud Directory API Reference)」をご覧ください。オブジェクトと同様に、属性ルールを使用して属性値を制御できます。文字列の長さやバイト配列を制御したり、特定の一連の値への文字列を制限、特定範囲の数字に上限を指定することもできます。私の同僚が Typed Links の使用法を表したいくつかのサンプルコードを共有してくれました。ARN とファセット名はこちらです。

String appliedSchemaArn   = "arn:aws:clouddirectory:eu-west-2:XXXXXXXXXXXX:directory/AbF4qXxa80WSsLRiYhDB-Jo/schema/demo_organization/1.0";
String directoryArn       = "arn:aws:clouddirectory:eu-west-2:XXXXXXXXXXXX:directory/AbF4qXxa80WSsLRiYhDB-Jo";
String typedLinkFacetName = "FloorSensorAssociation";

最初のスニペットが Typed Link ファセットを作成します。 FloorSensorAssociation LABEL=[NAME] によって sensor_typemaintenance_date 属性、といった順番になります (属性名と値はリンクのアイデンティティの一部なので順番を無視することはできません)。

client.createTypedLinkFacet(new CreateTypedLinkFacetRequest()
                                .withSchemaArn(appliedSchemaArn)
                                .withFacet(
                                      new TypedLinkFacet()
                                          .withName(typedLinkFacetName)
                                          .withAttributes(toTypedLinkAttributeDefinition("sensor_type"),
                                                          toTypedLinkAttributeDefinition("maintenance_date"))
                                          .withIdentityAttributeOrder("sensor_type", "maintenance_date")));

private TypedLinkAttributeDefinition toTypedLinkAttributeDefinition(String attributeName) {
 return new TypedLinkAttributeDefinition().withName(attributeName)
 .withRequiredBehavior(RequiredAttributeBehavior.REQUIRED_ALWAYS)
 .withType(FacetAttributeType.STRING);
}

次のスニペットは 2 つのオブジェクト間にリンクを作成します (sourceFloortargetSensor)、 sensor_type watermaintenance_date 2017-05-24:

AttachTypedLinkResult result = 
    client.attachTypedLink(new AttachTypedLinkRequest()
                               .withDirectoryArn(directoryArn)
                               .withTypedLinkFacet(
                                   toTypedLinkFacet(appliedSchemaArn, typedLinkFacetName))
                                   .withAttributes(
                                        attributeNameAndStringValue("sensor_type", "water"),
                                        attributeNameAndStringValue("maintenance_date", "2017-05-24"))
                                   .withSourceObjectReference(sourceFloor)
                                   .withTargetObjectReference(targetSensor));

private TypedLinkSchemaAndFacetName toTypedLinkFacet(String appliedSchemaArn, String typedLinkFacetName) {
   return new TypedLinkSchemaAndFacetName()
              .withTypedLinkName(typedLinkFacetName)
              .withSchemaArn(appliedSchemaArn);
}

最後のスニペットは sensor_type watermaintenance_date2017-05-20 から 2017-05-24 の範囲で受信した Typed Link すべてを列挙します。

client.listIncomingTypedLinks(
    new ListIncomingTypedLinksRequest()
        .withFilterTypedLink(toTypedLinkFacet(appliedSchemaArn, typedLinkFacetName))
        .withDirectoryArn(directoryArn)
        .withObjectReference(targetSensor)
        .withMaxResults(10)
        .withFilterAttributeRanges(attributeRange("sensor_type", exactRange("water")),
                                   attributeRange("maintenance_date", 
                                                  range("2017-05-20", "2017-05-24"))));

private TypedLinkAttributeRange attributeRange(String attributeName, TypedAttributeValueRange range) {
   return new TypedLinkAttributeRange().withAttributeName(attributeName).withRange(range);
}

private TypedAttributeValueRange exactRange(String value) {
   return range(value, value);
}

詳細については「オブジェクトとリンク (Objects and Links)」を「Cloud Directory 管理ガイド (Cloud Directory Administration Guide)」でご覧ください。

今すぐ利用可能
Typed Links は今すぐご利用いただけます。

Jeff;

Amazon Lightsail、東京リージョンにて提供開始

こんにちは、ソリューションアーキテクトの塚田です。
お待たせしました。現在開催中のAWS Summit Tokyo 2017 キーノートにてアマゾンウェブサービスジャパン株式会社社長の長崎からアナウンスがあったとおり、Amazon Lightsail が東京リージョンにやってきました!


インスタンスの作成時に、リージョンとアベイラビリティゾーンで東京(ap-northeast-1)を選択することができます。


Tokyo, Zone A (ap-northeast-1a)を選んでインスタンスの作成をすすめると…

東京リージョンにLightsailのサーバが立ちました!

また、東京リージョンでも料金は変わらず、月額$5〜のプランが利用可能になっています。

色々とはかどりますね。

 

(more…)

AWS上へのSAP移行 FAST with the SAP Rapid Migration Test Program

Somckit Khemmanivanhは、Amazon Web Services(AWS)のSAPソリューションアーキテクトです。

お客様がオンプレミス環境でSAP HANA以外のデータベース(AnyDB)で稼働するSAPアプリケーションを利用されている場合、AWSが提供するSAP Rapid Migration Test Programにより、今すぐAWS上のSAP HANA(あるいはSAP ASE)ベースのアプリケーションに移行していただけます。SAP Rapid Migration Test Program(Fast AWS and SAP Transformationを略したFASTとも呼んでいます)では、SAPアプリケーション(SAP ECCやSAP Buisness Warehouse)をAnyDBで稼働中のお客様のSAP HANA on AWS移行、またはSAP ASE on AWS移行を支援するため、SAPとAWSが協力して開発した一連のプロセス、手順、ツールを提供します。

お客様自身の社内リソース、リモートコンサルティング、またはコンサルティングパートナーを活用し、FASTを適用することで、SAPシステムをAWS上に移行し、同時にSAP HANAにアップグレードすることができます。AWSは、AWSプラットフォームの柔軟性とスケールが評価され、このイニシアチブの開発およびローンチパートナーとしてSAP社に選ばれました。SAPとAWSはプログラムのパイロット段階から連携し、わずか48時間で、またインフラストラクチャコストはわずか1,000ドルで移行が完了できることを確認しています。

FASTの一環として、SAPアプリケーションの移行テストを加速させるために、SAP社はSoftware Update Manager(SUM)のDatabase Migration Option(DMO)を機能拡張しています(SAP Note 2377305を参照、SAPノートの閲覧にはログイン認証が必要です)。このSUM 1.0 SP 20の機能拡張は、DMO with System Moveと呼ばれ、特別なエクスポートおよびインポートプロセスにより、オンプレミス環境からAWS上に直接移行することができるようになっています。AWS Quick Start for SAP HANAでAWS上にSAP HANAインスタンスを迅速に展開し、SAPアプリケーションを素早く構築することができます。さらに、SAPフラットファイルをAWS上に転送するときに、Amazon S3Amazon EFS (AWS Direct Connect経由)、AWS Storage GatewayのファイルインターフェースAWS SnowballといったAWSサービスもご利用いただけます。

SUM DMOツールは、AnyDBからSAP HANAへのデータ変換時に、OS更新、リリースアップグレード/エンハンスメントパッケージの適用およびユニコード変換まで同時に実行できます。実行記録はフラットファイルに書き込まれ、AWSプラットフォーム上で迅速に展開されたSAP HANA環境に転送されます。DMO with System Moveの次の段階で、フラットファイルがインポートされ、抽出されたデータ、コード、および設定を使用して移行先のSAPアプリケーションを構築します。関連する主要なステップの概念的な流れは次のとおりです。

ステップ1では、SUM DMOツールを使用して、SAPソースデータをフラットファイルの形式でストレージ格納先にエクスポートします。利用用途や要件に応じて、この格納先は、既に設定済みの既存のAWSサービス(Amazon EFSやファイルゲートウェイなど)、またはソースサーバ上のローカルファイルシステムになります。ステップ2では、エクスポートされたフラットファイルをAWS上に転送します(注:ストレージ格納先の機能によっては、ファイルをAWS上に明示的に転送する必要はありません。例えば、Amazon EFSまたはAWS Storage Gatewayのファイルゲートウェイを使用した場合、ファイルは自動的にAWSに転送されます)。ファイルを転送している間に、AWS Quick Start for SAP HANAを使用してSAP HANA環境を展開し、オプションでSAP HANAもインストールします。SAP HANAの標準的な展開時間は、SAP HANAの大規模スケールアウトシステムの場合でも、30分から1時間未満です。最後に、ステップ3で、新しく展開されたSAP HANA環境に実際にフラットファイルをインポートする作業が行われます。

SAP Rapid Migration Test Programでは、SAP HANAライセンスを持っていないお客様は、SAPアカウントチームから限られたテストライセンスを取得することができます。お客様は、自身でDMO with System Moveを使用することも、AWS Partner Network(APN)のSAPパートナーに支援依頼することもできます。

私たちは、AWS上でのSAPアプリケーションの利用経験についてお聞きしたいと思っています。ご不明な点がありましたら、ぜひお気軽にお問合せください。

閲覧ありがとうございました!

– Somckit

翻訳はPartner SA 河原が担当しました。原文はこちらです。

政府統一基準に対応したAWSクラウド利用のセキュリティリファレンス提供の取り組み@パブリックセクターシンポジウム ~AWS Summit Tokyo 2017~

 

政府統一基準に対応したAWSクラウド利用のセキュリティリファレンスについて

 

アクセンチュア株式会社、株式会社NTTデータ、PwCあらた有限責任監査法人、富士ソフト株式会社は共同で、内閣サイバーセキュリティセンター(NISC)制定の政府統一基準に対応したAWSクラウド利用のセキュリティリファレンスを作成し、2017年3月23日より無償提供を開始しました。本リファレンスは、2016年8月31日に改訂された「政府機関の情報セキュリティ対策のための統一基準(平成28年度版)」を背景としており、クラウドの選定および利用の際のガイドラインやセキュリティ要件等の基準が追加されたことに対して、AWSクラウド環境におけるセキュリティ対応策の詳細を網羅的に提示しています。

サイバーセキュリティ基本法に基づいてNISCが制定する政府統一基準(以下、NISC統一基準)は、国内の政府機関が実施すべきセキュリティ対策の指針として幅広く利用されています。一方で、その要件やチェック項目は複雑かつ広範にわたるため、AWSクラウド等のクラウドを利用する際に、そのガイドラインや要件を満たすことを確認することは容易ではありませんでした。このたび共同開発した本リファレンスは、各社の情報セキュリティ対策に関する知見と実績を結集したものです。政府統一基準への準拠のノウハウを具体的に提示することにより、各政府機関が安全で信頼性の高いシステムを実現することを支援できるものと期待しています。

 

パートナー各社の取り組み

 

2017年5月30日に開催された「パブリックセクタ― シンポジウム ~AWS Summit Tokyo 2017 – Dive Deep Day~」にて、本リファレンスの作成者であるパートナー各社によるパネルディスカッションが行われ、各社の取り組みが紹介されました。

(more…)

6 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。プロフェッショナルサービスの宮本です。AWS Black Belt オンラインセミナー 6 月の配信についてご案内させて頂きます。6 月は、AWSの新サービス、機能追加のご紹介や、5月30日から6月2日まで4日間に渡って開催予定のAWSサミットの振り返り、Lambda書籍発売を記念したLambdaの網羅的なサービス解説など幅広いラインナップでお送ります。

6 月の開催予定

サービスカット

6/7(水) 18:00-19:00 Amazon Redshift Update – 最近追加された新機能とRedshift Spectrumの解説
6/14(水) 18:00-19:00 検討中
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/20(火) 12:00-13:00 Lambda書籍発売記念

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカーおよびスタッフ一同、みなさまのご参加をお待ちしております。

Amazon EC2 Container Service – リリースに関する要約、お客様事例、コードについて

今回は、去年 Amazon EC2 Container Service に追加したいくつかの機能に関する概要と、お客様事例やコードについてご紹介します。このサービスは EC2 インスタンスのマネージド型クラスターの範囲内で Docker コンテナをいくつでも実行しやすくします。また、同サービスはコンソールAPICloudFormationCLIPowerShell のサポートも備えています。簡単にアクセスできるように、Linux や Windows Docker イメージを EC2 Container Registry に保存できます。

リリースの要約
それでは ECS の最新機能と、その使用方法を説明したブログをいくつか見てみましょう:「アプリケーションの負荷分散 (Application Load Balancing)」- 去年は「アプリケーションロードバランサー (application load balancer)」のサポートを追加しました。この高性能なロードバランシングオプションはアプリケーションレベルで実行され、コンテンツベースのルーティングルールで定義することができます。ダイナミックポートをサポートし、複数のサービスでの共有が可能なため、コンテナ内でマイクロサービスを実行しやすくなります。詳細については「サービスロードバランシング (Service Load Balancing)」をご覧ください。

タスクで使用する IAM ロール – ECS タスクに IAM ロールを割り当てることでインフラストラクチャを安全にできます。これにより、各タスクごとに細かく設定しアクセス許可を付与できるので、各タスクが必要とするアクセス許可を割り当てることが可能です。詳しくは「タスクで使用する IAM ロール (IAM Roles for Tasks)」をご覧ください。

サービス Auto Scaling – 需要の変化に応じるため、サービス (タスク) のスケールダウンやスケールアップに関するスケーリングポリシーを定義できます。お客様は必要なタスクの最小数および最大数を選択し、1 つまたはそれ以上のスケーリングポリシーを作成するのみです。あとはサービス Auto Scaling で処理されます。この機能を活用するには「サービス Auto Scaling (Service Auto Scaling)」をご覧ください。

Blox – コンテナベース環境の Scheduling は、インスタンスにタスクを割り当てる際のプロセスです。ECS は 3 つのオプションを提供します: 自動 (すでに組み込まれている サービススケジューラー)、手動 (RunTask 関数を使用)、カスタム (ご自分で提供するスケジューラーを使用)。Blox は one-task-per-host タイプをサポートするオープンソーススケジューラーです。今後、他のタイプにも対応する可能性も充分にあります。これはクラスターの状態を監視し、モニタリングエージェントやログコレクター、その他のデーモンスタイルのタスクを実行するのに適しています。

Windows – Linux コンテナをサポートする ECS をリリースしたほか Windows Server 2016 Base with Containers の実行もサポートするようになりました。

コンテナインスタンスのドレイン – クラスターをスケールダウンしたりシステムを更新するために、実行中のクラスターからインスタンスを削除することが必要な場合も時にはあるでしょう。インスタンスの状態をより管理しやすくするため、今年始めに一連のライフサイクルフックを追加しました。ライフサイクルフックと Lambda 関数を使用して、新しい作業にスケジュールを設定することなく、インスタンスから既存の作業のドレインプロセスを自動化する方法については「Amazon ECS でコンテナインスタンスのドレインを自動化する (How to Automate Container Instance Draining in Amazon ECS)」をご覧ください。

コードを使用した CI/CD パイプライン* – コンテナはソフトウェアの導入を簡素化し、CI/CD (継続的インテグレーション / 継続的デプロイメント) パイプラインにとって理想的なターゲットです。過去に公開したブログ「AWS CodePipeline、AWS CodeBuild、Amazon ECR、AWS CloudFormation を使用し Amazon ECS で行う継続的デプロイメント (Continuous Deployment to Amazon ECS using AWS CodePipeline, AWS CodeBuild, Amazon ECR, and AWS CloudFormation)」では、複数の AWS サービスを使用して CI/CD パイプラインを構築し動作させる方法について説明しています。

CloudWatch Logs の統合 – このリリースでは、一元管理と分析に使用する CloudWatch Logs にログ情報を送信するタスクを実行するコンテナ設定が可能になりました。Amazon ECS コンテナエージェントをインストールし awslogs ログドライバーを有効にするだけです。CloudWatch Events – タスクの状態またはコンテナインスタンスが変更すると、ECS は CloudWatch Events を生成します。こうしたイベントは Lambda 関数を使用してクラスターの状態を監視できるようにします。Elasticsearch クラスターでイベントをキャプチャし保存する方法については「Amazon ECS Event Stream でクラスターの状態を監視する (Monitor Cluster State with Amazon ECS Event Stream)」をご覧ください。

タスク配置のポリシー – このリリースでは、クラスター内のコンテナインスタンスでタスク配置における細かな管理設定を提供しました。クラスター制約、カスタム制約 (場所、インスタンスタイプ、AMI、属性)、配置戦略 (スプレッドまたはビンパック) を含むポリシーを作成し、コードを作成することなく使用できるようにします。詳細については「Amazon ECS タスク配置のポリシー (Introducing Amazon ECS Task Placement Policies)」をご覧ください。

EC2 Container Service の実行
金融サービス、ホスピタリティ企業、家電メーカーなど様々な分野における大規模なエンタープライズから急成長中のスタートアップ企業まで、AWS をご利用のお客様は Amazon ECS を使用して独自のマイクロサービスアプリケーションを本稼働環境で使用しています。Capital One、Expedia、Okta、Riot Games、Viacom といった企業は Amazon ECS に依存しています。

Mapbox は、カスタムマップを設計し公開するプラットフォームです。同企業は ECS を使用してバッチ処理のアーキテクチャをサポートし、マップのサポートに使用する 1 億マイルのセンサーデータを毎日収集し処理しています。スポットインスタンスを使用して ECS でバッチ処理アーキテクチャの最適化も行います。Mapbox のプラットフォームは 5,000 件以上のアプリをサポートし、毎月 2 億人以上のユーザーをターゲットにしています。そのバックエンドは ECS で実行され、毎日 13 億件のリクエストに対応しています。同社が最近行った ECS への移行に関する詳細は「Amazon ECS に切り替えるメリット (We Switched to Amazon ECS, and You Won’t Believe What Happened Next)」をご覧ください。

旅行会社の Expedia は、マイクロサービスアーキテクチャで同社のバックエンドを設計しました。Docker の普及に伴い、スピードのあるデプロイメントや環境の可搬性に Docker を取り入れることにしました。ALB から IAM ロール、VPC の統合まで、優れた統合性を備えているため、すべてのコンテナ調整に ECS を使用することにしました。これにより、既存の AWS インフラストラクチャで ECS がとても使いやすくなりました。ECS により、デプロイやコンテナ化されたアプリケーションの負担を軽減できるようになりました。Expedia はすべてのアプリケーションのうち 75% を ECS の AWS で実行し、毎時間 40 億件のリクエストを処理できるようにしています。詳しくは Kuldeep Chowhan のブログ「Amazon ECS を使用して本稼働環境で Expedia が何百件ものアプリケーションを実行している方法 (How Expedia Runs Hundreds of Applications in Production Using Amazon ECS)」をご覧ください。

Realtor.com は住宅の購入販売において現在売りに出されている不動産物件の包括的なデータベースを提供しています。同社が AWS に移行してから ECS を使用することでサポートビジネスが成長し、現在では毎月の閲覧者数が 5,000 万人を超え、ピーク時には毎秒 250,000 件のリクエストが記録されています。ECS は同社がクラウドインフラストラクチャの使用率を高めながら、よりすばやくコードをデプロイすることをサポートしています。同社が ECS、Kinesis、その他の AWS サービスをどのように活用しているかは「Realtor.com の導入事例 (Realtor.com Case Study)」をご覧ください。Instacart は、食品同日配送サービスのサポートに ECS をどのように利用しているのか説明しています:

Capital One は、ECS を使用してオペレーションやインフラストラクチャの管理を自動化しているのか説明しています:

Code Clever の開発者は ECS を独自の作業ベースに使用しています。例: Rack はオープンソースの PaaS (Platform as a Service) です。これは分離されている VPC で実行するインフラストラクチャの自動化に集中し、セキュリティにはシングルテナントで構築されたサービスを使用します。

Empire もオープンソース PaaS です。Heroku のようなワークフローを提供し、マイクロサービスに重点を置いた小規模および中規模のスタートアップ企業をターゲットにしています。Cloud Container Cluster Visualizer (c3vis) は、ECS クラスター内でリソースの使用率を可視化します:

今後もお楽しみに!
この他にも ECS の新機能を構築中です、乞うご期待ください!

Jeff;

ランサムウェア「WannaCry」に関するAWSへの影響について

 

2017年5月12日頃からWannaCry(別名、WCry、WanaCrypt0r 2.0、Wanna Decryptorなど)と呼ばれるランサムウェア(身代金マルウェア)による被害が世界中から報告されはじめました。日本でも複数の大手企業がこのマルウェアに感染したというニュースが報道されています。

このマルウェアは、ファイル共有および印刷共有サービスを提供するWindows SMBサーバー上に存在する脆弱性を悪用します。デフォルトでは、SMBサーバーはUDPポート137/138およびTCPポート139/445で動作します。また、Windowsオペレーティングシステムの複数のバージョンが対象で、Microsoft社は、この脆弱性を解消するため、2017年3月14日にMicrosoft Windows SMB Server(4013389)の重要なセキュリティ更新プログラムをリリースしました。詳細は、Microsoft MSRC blog もしくは Microsoft Security Bulletin MS1​​7-010 をご参照ください。

 

WannaCryによるAWSサービスへの影響

 

EC2 Windows

 

Amazon EC2上のWindowsに関しては、AWSから提供されている2017.04.12以降のリリースのAMIであれば、この脆弱性の被害を受けていません。また、自動更新が有効になっている場合も、この脆弱性は解消されています。2017.04.12より前のAMIを使用している、かつ、自動更新を有効にしていないお客様は、前述のセキュリティ更新プログラムをインストールすることをお勧めします。

AWSでは、セキュリティのベストプラクティスに従い、セキュリティグループの設定を確認し、その必要のあるインスタンスおよびリモートホストに対してのみ前述のポートへのアクセスを許可することを、常にお勧めしています。デフォルトでは、EC2セキュリティグループはこれらのポートをブロックします。

AWSのWindows AMIのリリースノートはこちらです。

 

WorkSpaces

 

Amazon WorkSpacesに関しては、2017 年4月15日以降にWorkSpaceを作成した、または、自動更新を有効にしたAmazon WorkSpacesのお客様は、この脆弱性の影響を受けません。 2017年4月15日より前にWorkSpaceを作成し、自動更新を有効にしていないお客様は、セキュリティ更新プログラムをインストールするか、 WorkSpaceを終了して再作成することをお勧めします。

 

Directory Service

 

AWS Directory Serviceに関しては、2017/05/20時点でパッチ適用作業が完了しました。お客様による対応は必要ありません。Amazon Simple AD、 AD Connector、AWS Cloud Directory はこの問題の影響を受けていません。最新情報につきましては、下の原文へのリンク先をご参照ください。

 

Elastic Beanstalk

 

AWS Elastic Beanstalkに関しては、2017 年5月4日以降のWindowsサーバーで構築された環境は、本問題の影響を受けません。ただし、既存のElastic Beanstalk Windows環境のアップデートは常に推奨しています。AWS管理コンソールから、もしくは、環境を再構築することでアップデート可能です。Elastic Beanstalkの現時点での最新のリリースノートはこちらです。

 

AWSによるセキュリティ速報(原文)は、こちらをご覧ください。

 

AWSサービスの効果的な使い方

 

Amazon Inspectorは、Amazon EC2インスタンスに対してエージェントを導入し、セキュリティ診断を行うサービスです。CVE(共通脆弱性識別子)のルールパッケージに基づいた診断も可能で、WannaCryに関連するCVE-2017-0143からCVE-2017-0148の脆弱性の検証ができます。AWS管理コンソール、CLI、APIから診断を実行できます。診断結果は、AWS管理コンソールで表示したり、エグゼクティブサマリー含むPDF形式のレポートとしても取得できます。

AWSコンソール上でのAmazon Inspector 結果一覧画面例

 

AWSコンソール上でのAmazon Inspector 結果詳細画面例

 

詳しくは、Amazon Inspector ユーザーガイドをご覧ください。

 

Amazon EC2 Systems Managerは、Amazon EC2インスタンスおよびオンプレミスサーバーに対してエージェントを導入し、ソフトウェアインベントリ収集やOSパッチ適用、OS構成変更などを一元的に管理できるサービスです。インスタンスに対して、シェルスクリプトやPowerShellコマンドの実行、パッチ適用の時間指定や定期実行などの管理タスクを簡単に自動化できます。今回のような、Windowsのセキュリティ更新プログラム適用にもご利用いただけます。詳しくは、Amazon EC2 Systems Manager ユーザーガイドをご覧ください。

 

推奨するAWSソリューション

 

今回のようなランサムウェアに対する最も有効な対策は、常日頃からバックアップを取得・管理し、セキュリティ推奨構成を保っておくことです。AWSではバックアップ&復旧に関する各種ソリューションの情報が提供されています。

上記の情報も参考に、これからも安心・安全なAWSライフをご満喫ください。

桐山 隼人, セキュリティソリューションアーキテクト
坪 和樹, クラウドサポートエンジニア
長谷川 淳, クラウドサポートエンジニア

EC2インメモリ処理のアップデート: 4TBから16TBのメモリ搭載インスタンスと34TBのSAP HANAスケールアウト

毎月数回、シアトルのエグゼクティブブリーフィングセンターでお客様と話をします。私たちのイノベーションのプロセスを説明し、各AWS製品のロードマップがお客様の要望とフィードバックによってどのように決められているかやりとりします。

その良い例が、SAP社のビジネスソリューションのポートフォリオにとってAWSを魅力的な場所にするための私たちの取り組みです。長年にわたり、お客様はAWS上で大規模なSAPアプリケーションを本番環境で稼働しており、このワークロードに対応するように設計されたEC2インスタンスを提供することに努めてきました。SAPシステムは間違いなくミッションクリティカルであり、SAP社はいくつかのEC2インスタンスのタイプとサイズで彼らの製品を利用できるよう認定しています。私たちは、AWSをSAP製品にとって堅牢で信頼できる基盤にし、認定を取得するために、SAP社と密に連携しています。

ここで、この分野での最も重要なお知らせを簡単にまとめておきます:

2012年6月 – AWS上で利用可能なSAP認定ソリューションの範囲を拡大しました

2012年10月 – AWS上でSAP HANAインメモリデータベースを本番稼働できるようになりました

2014年3月 – 最大244GBのメモリを搭載したcr1.8xlargeインスタンスでSAP HANAが本番稼働し、テスト用途のクラスタはさらに大きく作成できるようになりました

2014年6月 – r3.8xlargeインスタンスのSAP認定と合わせて、SAP HANA導入ガイドとAWS CloudFormationテンプレートを公開しました

2015年10月 – SAP HANA、Microsoft SQL Server、Apache SparkやPrestoを実行するために設計された2TBメモリを搭載したx1.32xlargeインスタンスを発表しました

2016年8月 – X1インスタンスのクラスタを使用して、最大7ノードつまり14TBメモリの本番稼働SAP HANAクラスタを作成することができるようになりました

2016年10月 – 1TBメモリを搭載したx1.16xlargeインスタンスを発表しました

2017年1月 – r4.16xlargeインスタンスでSAP HANA認定を取得しました

現在、幅広い業界のお客様がSAPアプリケーションをAWS上で本番稼働させています(SAPとAmazon Web Servicesのページには、多くのお客様成功例が掲載されています)。

私の同僚のBas Kamphuisが最近、SAPとクラウドによるデジタルジャーニーのナビゲートという記事を書きました(閲覧には登録が必要)。彼は、デジタルトランスフォーメーションにおけるSAPの役割について説明し、それをサポートするクラウドインフラストラクチャの主要な特性を検証しながら、他のホスティングオプションと比較してクラウドのほうが多くの利点を提供していると指摘しています。彼がこの記事でこれらの利点をどのように紹介しているかは以下のとおりです:

SAPアプリケーションの本稼働環境としてAWSがより良い場所になるよう、引き続き取り組んでいます。私たちが取り組んでいることのいくつかを以下に示します:

  • より大きなSAP HANAクラスタ – スケールアウトのSAP HANAクラスタを最大17ノード(34TBメモリ)まで構成できるようになりました
  • 4TBのインスタンス – 今度、4TBメモリ搭載のx1e.32xlargeインスタンスを提供します
  • 8から16TBのインスタンス – 16TBまでのメモリを搭載したインスタンスを計画しています

詳細をみてみましょう!

より大きなSAP HANAクラスタ
SAP社と連携し、x1.32xlargeインスタンスを使用した最大17ノード(34TBメモリ)のスケールアウトクラスタでSAP認定を取得したことをお知らせします。これは、現在のクラウドプロバイダから提供される最大のスケールアウト構成であり、AWS上で非常に大きなSAPワークロードを展開することができます(詳細は、SAP HANA認定ハードウェアディレクトリx1.32xlargeインスタンスを参照してください)。スケールアウトクラスタの構築および展開方法については、SAP HANA on AWSクイックスタートを参照してください。

メモリ重視のX1ファミリの拡張
お客様のご要望に対応し、確実な成長経路を提供するために、このインスタンスファミリおよび他のインスタンスファミリに引き続き投資します。

今年後半には、複数のAWSリージョンで、オンデマンドとリザーブドインスタンス両方の形式のx1e.32xlargeインスタンスを利用できるようにする予定です。このインスタンスは、(x1.32xlargeの2倍の)4TBのDDR4メモリ、128個のvCPU(4つの2.3 GHz Intel ® Xeon® E7 8880 V3プロセッサ)、高いメモリ帯域幅および大きなL3キャッシュを提供します。このインスタンスはVPC専用で、レイテンシとジッターを最小限に抑えながら、Elastic Network Adapterを使用して最大20Gbpsのネットワーク帯域幅を提供します。また、デフォルトでEBS最適化が行われており、最大14GbpsのEBSへの専用スループットが設定されます。

いくつかのシェルのスクリーンショットです。最初に、dmesgでブート時のカーネルメッセージを表示します:

次に、lscpuでvCPUとソケット数を他の多くの興味深い項目と共に表示します:

そして、topでは約900のプロセスを表示しています:

SAP HANA Studioの画面です:

以下の図からわかるように、この新しいインスタンスにより、大規模クラスタの認定と合わせて、EC2上でSAPを実行するためのスケールアウトオプションとスケールアップオプションの組合せを広げます。

長期的なメモリ重視のロードマップ
大規模なSAP導入の計画にはかなりの時間がかかることも分かっているので、ロードマップの一部を共有したいと考えています。

現在、サードパーティのコロケーション施設でより大規模なSAP HANA認定サーバを稼働させ、AWS Direct Connectを使用してAWSインフラストラクチャに接続することができますが、お客様は既に利用されているX1インスタンスのようなクラウドネイティブソリューションを必要としていると仰っています。

このご要望を満たすために、私たちはより多くのメモリを持つインスタンスを計画しています!2017年から2018年にかけて、8TBから16TBのメモリのEC2インスタンスを提供する予定です。これらの今後のインスタンスは、x1e.32xlargeと共に、より大きなシングルノードのSAP導入およびマルチノードのSAP HANAクラスタの作成、さらに他のメモリ重視のアプリケーションやサービスの実行を可能にします。また、小規模なインスタンスで限界に達するときに役立ついくつかのスケールアップへの余力も提供します。

できるだけ早く私たちの計画に関する詳細情報を共有していきます。

SAPPHIREで会いましょう
AWSは、SAPPHIREの539番ブースに出展しており、ブース内のシアターで私たちのチームやお客様、パートナーからの一連のセッションを予定しています。また、イベントを通じて多くのセッションに関与しています。例えば以下のようなものです(詳細は、SAP SAPIRE NOW 2017を参照してください)。

SAP Solutions on AWS for Big Businesses and Big Workloads – 5月17日水曜正午から、Bas Kamphuis (General Manager, SAP, AWS)とEd Alford氏 (VP of Business Application Services, BP)が講演

Break Through the Speed Barrier When You Move to SAP HANA on AWS – 5月17日水曜午後12時30分から、Paul Young氏 (VP, SAP)とSaul Dave氏 (Senior Director, Enterprise Systems, Zappos)が講演

AWS Fireside Chat with Zappos (Rapid SAP HANA Migration: Real Results) – 5月18日木曜午前11時から、Saul Dave氏 (Senior Director, Enterprise Systems, Zappos)とSteve Jones (Senior Manager, SAP Solutions Architecture, AWS)が講演

Jeff;

追伸 – もし、SAPの経験をお持ちで、そのキャリアをクラウドで活かしたい場合は、プリンシパルプロダクトマネージャー(AWSクイックスタート)SAPアーキテクトのポジションにご応募ください。

翻訳はPartner SA 河原が担当しました。原文はこちらです。

AWS X-Ray で AWS Lambda をサポート

本日、AWS X-RayAWS Lambda サポート の一般提供開始を発表しました。Jeff が GA で投稿したブログですでにご存知の方もいるかと思いますが (「Jeff の GA POST (Jeff’s GA POST)」)、X-Ray は分散アプリケーションの実行やパフォーマンス動作を分析する AWS サービスです。

複数の独立したコンポーネントを異なるサービスで実行するマイクロサービスベースのアプリケーションでは、従来の問題をデバッグする方法がうまく機能しません。アプリケーションでレイテンシーを分けることで、X-Ray はエラーや処理の低下、タイムアウトを迅速に診断することができます。それでは、シンプルな Lambda ベースのアプリケーションを構築し分析する方法をお見せしながら、独自のアプリケーションで X-Ray を使用する方法をご説明します。

今すぐ開始したい場合は、関数の設定ページで追跡を有効にすれば既存の Lambda 関数で簡単に X-Ray を使い始めることができます。

または AWS Command Line Interface (CLI) で関数の tracing-config を更新してください (必ず --function-name も忘れずに):

$ aws lambda update-function-configuration --tracing-config '{"Mode": "Active"}'

トレースモードをオンにすると、Lambda は関数を追跡しようとします (アップストリームサービスによって追跡されないよう明示的に指示されていない限り)。オフの状態では、アップストリームサービスによって追跡するよう明示的に指示されている場合のみ関数が追跡されます。トレーシングモードをオンにすると追跡の生成が始まり、アプリケーションとその間のコネクション (辺) におけるリソースのビジュアル表現が見られるようになります。

X-Ray デーモンは Lambda 関数のいくつかのリソースを使用することがあります。メモリ制限に近付いている場合、Lambda はメモリ不足エラーを回避するために X-Ray デーモンを終了しようとします。では、複数のサービスを使用する簡単なアプリケーションを構築して新しい統合を試してみましょう。


20 代が持つスマートフォンということで、 pictures 自分のスマホは自撮りの写真でいっぱいです (10000+!)。ということで、この機会に写真をすべて分析してみることにしました。Java 8 ランタイムを使用して、Amazon Simple Storage Service (S3) バケットにアップロードした新しい画像に反応するシンプルな Lambda 関数を作成します。写真には Amazon Rekognition を使用し、検出したラベルを Amazon DynamoDB に保存します。

サービスマップ

まず、X-Ray のボキャブラリーをいくつか確認しておきましょう: サブセグメントセグメントトレースです。 分かりましたか? サービスグラフを生成するために X-Ray が処理するトレースをサブセグメントとセグメントが構成している、ということを覚えておけば X-Ray を理解しやすいと思います

サービスグラフは見やすいビジュアル表現を提供します (様々なリクエストへの応答を別の色で表示)。アプリケーションロジックを実行しているコンピューティングリソースは、実行している作業に関するデータをセグメント形式で送信します。サブセグメントを作成すれば、データに関する注釈を追加したり、コードのタイミングをより細かく設定することができます。アプリケーションを経由するリクエストのパスは、トレースを使用して追跡されます。トレースでは、1 つのリクエストで生成されたセグメントをすべて収集します。つまり、S3 からの Lambda イベントを DynamoDB まで簡単に追跡することができるので、エラーやレイテンシーがどこで発生しているか把握することができます。

では、S3 バケットを作成してみましょう。このバケットの名称は selfies-bucketにします。DynamoDB テーブルは selfies-table、あとは Lambda 関数です。ObjectCreated で S3 バケットの Lambda 関数にトリガーを追加します。Lambda 関数コードは実にシンプルです。こちらでご覧ください。コードの変更なしに、JAR の aws-xray-sdk と aws-xray-sdk-recorder-aws-sdk-instrumentor パッケージを含むことで Java 関数で X-Ray を有効にすることができます。アップロードした写真をいくつかトリガーして X-Ray のトレースを見てみましょう。

データが取れました!トレースの 1 つをクリックすれば呼び出しの詳細情報を見ることができます。

最初の AWS::Lambda セグメントでは、関数のドウェル時間、実行待機時間、試行された実行数を見ることができます。次の AWS::Lambda::Function セグメントにはいくつかのサブセグメントが見られます。

  • 初期設定のサブセグメントには関数ハンドラが実行する前の時間すべてが含まれます。
  • アウトバウンドサービスコール
  • 任意のカスタムセグメント (簡単に追加可能)

どうやら DyamoDB 側で問題が発生しているようです。エラーアイコンをクリックすれば、より詳しい情報と例外のスタックトレースを見ることができます。書き込みキャパシティーユニットが不足しているので、DynamoDB に調整されたことが分かります。数回のクリックまたは簡単な API コールで追加できます。そうするとサービスマップに表示される緑が増えていきます。

X-Ray SDK は X-Ray へのデータ放出をとても簡単にしますが、トークに X-Ray デーモンを使用する必要はありません。Python を使用している場合は fleece という rackspace からライブラリを確認できます。X-Ray サービスは興味深いものをたくさん備えています。詳細については「未定義 ()」ドキュメントをご覧ください

個人的に @awscloudninja ボットで使用していますが、これはとても優れていると思います。ただし、これは公式のライブラリではなく AWS がサポートしていない点にご留意ください。時間節約、デバッグや操作に対する労力においても便利なので、個人的には今後のプロジェクトすべてで X-Ray を使う予定です。皆さんがどのように構築するのか楽しみにしています。使えそうなトリックやハックを見つけたら、ぜひお知らせください!

– Randall