Amazon Web Services ブログ

Amazon Chime の更新 – 既存の Active Directory を使用してドメインを要求

Amazon Chime については 2 月のブログ「Amazon Chime – 統合されたコミュニケーションサービス (Amazon Chime – Unified Communications Service)」で紹介し、世界中にいる相手と繋がったり共同作業を行う方法についてご説明しました。Amazon Chime はリリースされるとすぐに AWS チームが好んで使用するコミュニケーションツールになりました。私は 1 日に渡り、1 対 1 のチャットやグループチャットにいくつも参加しています。また、Amazon Chime を使用した会議に「チャイムイン」することも頻繁にあり、今後のリリースや講演のチャンスなどについて話し合っています。本日、その Amazon Chime に新しい 2 つの機能を追加することになりました。ドメインを独自のものとして要求したり、既存の Active Directory のサポートが可能になります。

ドメインの要求
ドメインを要求することで、そのドメイン内のユーザー全員による Amazon Chime の使用状況を管理できます。新社員を公式な方法で Amazon Chime に登録させることで、社員が退社した場合はそのアカウントを停止にすることができます。ドメインを要求するには、特定のドメイン名を所有していることをアサートし、ご自分のドメインの DNS エントリに TXT レコードを入力することでアサーションをバックアップします。お客様の組織が使用するメールアドレスのドメインおよびサブドメインそれぞれにおいて、この手順を行ってください。では次に、私が自分のドメインを要求したケースをお見せします。

[Verify this domain] をクリックすると Amazon Chime が私の DNS レコードを提供します。

そうすると、ドメインのステータスが [Pending Verification] に変わります。Amazon Chime が、予期していたように新しいレコードが存在することを確認するとステータスが [Verified] に変わり、チームアカウントがエンタープライズアカウントになります。

Active Directory のサポート
この機能はユーザーが既存の Active Directory のアイデンティティと認証情報を使用して Amazon Chime にサインインできるようにします。設定が完了すると、パスワードローテーションやパスワードの複雑なルール、多要素認証などアドバンスド AD セキュリティ機能を有効にして活用することができます。さらに、グループベースで Amazon Chime の Plus や Pro ライセンスの割り当てを管理することもできます (各ライセンスタイプの詳細についてはプランと料金表をご覧ください)。この機能を使うには Amazon Chime エンタープライズアカウントを使用している必要があります。チームアカウントをご利用されている場合は、操作を始める前に「エンタープライズアカウントを作成するには (Create an Enterprise Account)」に記載されている手順をご覧ください。次に AWS Directory Service でディレクトリをセットアップします。この時点ではオプションが 2 つあります。

  1. AWS Directory Service AD Connector を使用して、既存のオンプレミス Active Directory インスタンスに接続します。
  2. スタンドアロン使用で設定されている Microsoft Active Directory を使います。このオプションの詳細については「Microsoft AD Directory を作成するには (How to Create a Microsoft AD Directory)」をご覧ください。

ディレクトリの設定が完了したら [Settings] をクリックし [Active directory] を選択してドロップダウンメニューでご自分のディレクトリを選ぶと、Amazon Chime コンソールから接続できるようになります。

完了したら、ディレクトリ内の各グループを選び、適切なサブスクリプション (Plus または Pro) をグループベースで指定できます。希望通りの設定が完了したら、ユーザーが既存のディレクトリ認証情報で Amazon Chime にログインできるようになります。これらの新機能はすでに利用可能であり、すぐに使用を開始できます。Amazon Chime の詳細については AWS テックトークをご覧ください:「Amazon Chime で従来のミーティングを近代化 (Modernize Meetings with Amazon Chime)」: トークのプレゼンテーション:

Jeff;

SAP on AWSクラウド設計入門

Rahul Kabraは、Amazon Web Services(AWS)のパートナー ソリューション アーキテクトです。

SAPワークロードをAWS上に移行することを真剣に検討し始めると、AWS上のSAPアーキテクチャはどのようにすべきか、オンプレミスやプライベートクラウドで稼働する場合とどこが違うのか、ビジネスにどういった利点があるのか、おそらく気になってくるでしょう。この入門用のブログでは、これらのトピックの多くに触れ、AWS上へのSAPワークロードの移行および運用に向けた準備を整えるための重要な情報をお伝えします。

AWSがもたらす俊敏性と拡張性をSAPワークロードで実際に活用するために、AWS上のSAPランドスケープの設計では、考え方を少し変える必要があります。また、SAPアーキテクチャが様々なAWSサービスをどのように活用し、これまでに比べて可用性が高く、セキュリティが強化された環境が提供されているかを理解することも重要です。SAP on AWSの概要を理解するために、様々なアーキテクチャのコンポーネントを探ってみましょう。

SAP関連の主要なAWSサービス

以下が、SAPワークロードの展開を始めるために知っておいたほうがよい主要サービスの一部です:

  • Amazon VPC – Amazon Virtual Private Cloud(Amazon VPC)は、AWSクラウドの論理的に隔離された区画を提供し、すべてのAWSリソースを展開します。このサービスは、関連して許可されたネットワークトラフィックだけがVPCに出入りできるよう制御する仮想ネットワーキングの機能とセキュリティを提供します。SAPのためのVPC設計およびアーキテクチャパターンの詳細については、以前投稿したブログ「SAP on AWSにおけるVPCサブネットのゾーニングパターン」を参照してください。
  • Amazon EC2 – Amazon Elastic Compute Cloud(Amazon EC2)は、SAPアプリケーションサーバーとデータベースをインストールできる仮想ホストを提供します。AWSは、小規模で多目的のインスタンスからSAP HANAのようなインメモリーワークロードを実行できる大容量メモリーのインスタンスまで、SAPワークロードを実行するために認定された複数のインスタンスファミリーを提供しています。
  • Amazon EBS – Amazon Elastic Block Store(Amazon EBS)は、AWSが提供するブロックベースのストレージサービスであり、SAPアプリケーションおよびデータベースに関連するデータ、ログファイルおよびバックアップボリュームを格納するために使用します。AWSでは複数のEBSボリュームタイプを用意しており、SAPアプリケーションのSAPS、IOPS、スループット要件に合わせて活用することができます。
  • Amazon EFS – Amazon Elastic File System(Amazon EFS)は、多数のEC2インスタンスから接続できる共有ファイルシステムを提供します。このファイルストレージは、/usr/sap/transや/sapmnt/<SID>などの共有ファイルをマウントする必要があるSAPスケールアウト構成で特に役立ちます。
  • Amazon S3 – Amazon Simple Storage Service(Amazon S3)は、スケーラブルで耐久性の高いオブジェクトベースのストレージサービスで、SAPアプリケーションのバックアップとスナップショットの保存に使用できます。
  • Amazon Glacier – このサービスは、スケーラビリティが高く、耐久性に優れ、コスト効率の高いオブジェクトストレージで、コンプライアンスや規制上の理由から長期的なバックアップ、アーカイブ、データ保管に使用できます。
  • IAM – AWS Identity and Access Management(IAM)は、AWSユーザーとグループの作成および管理に使用します。また、IAMロールによりAWSリソースへのアクセスを安全に制御することができます。
  • CloudWatch – Amazon CloudWatchは、AWSリソースの監視サービスです。SAPワークロードのリソース利用状況を収集するとともに、AWSリソースの変更に自動的に対応するためのアラームを作成するのに重要です。
  • CloudTrail – AWS CloudTrailは、AWSアカウント内で行われたすべてのAPI呼び出しを記録します。APIコールに関する重要なメトリックを取得し、SAPリソースの証跡作成を自動化できる非常に有益なサービスです。
  • AWS CLI – AWSコマンドラインインターフェイス(CLI)は、コマンドラインまたはスクリプトを使用して様々なAWSサービスを管理、操作するために使用できるツールです。このブログ後半の”AWS自動化”の項でいくつかのAWS CLIコマンドの例を確認できます。
  • Route 53 – Amazon Route 53は、スケーラビリティと可用性の高いAWS上のDNSサービスです。ホステッドゾーン、トラフィックポリシーやドメインを作成したり、AWS以外のリソースにも接続することができます。

AWSサイジングと性能

AWSプラットフォームであれば、セルフサービス方式で正しいタイプとサイズのコンピューティングリソースを展開でき、ハードウェアに大きな初期投資をする必要はありません。AWSに移行することの主な利点の1つに、ビジネスニーズの変化に合わせてリソースを調整できる拡張性と柔軟性が手に入ることが挙げられます。例えば、AWSは、SAPランドスケープをお客様の近くで安全かつ高可用な方法で運用できるよう、16のリージョンと42のアベイラビリティゾーンからなるグローバルフットプリントを提供しています。従来のオンプレミスの構成と異なり、AWSクラウドにおいては、以下に示すようにコンソールでの数クリックの操作や、簡単なAPI呼び出しで、SAP用EC2インスタンスのサイズを変更できます。

AWSマネジメントコンソールから既存のEC2インスタンスのサイズ変更

お客様が必要とする大量のリソースをすぐに利用でき、また使った分のお支払いで済みます。これにより、インフラストラクチャの設計者は、新しいプロジェクトのコンピューティング/メモリーのサイジング要件を決定する際に、バッファを加味したり推測したりすることが不要になります。また、月末や決められた期間のような特別なイベントの間だけ、既存のホストへの容量の追加やSAPアプリケーションまたはデータベース層を拡張することが容易にできます。AWSでは、リソース要件を満たすためにメモリー最適化、コンピュート最適化のインスタンスタイプを提供しており、SAP社と密に連携してどちらもSAP認定を取得しています。SAP認定EC2インスタンスのリストは、SAPノート1656099を参照してください(SAPノートの閲覧にはSAP Support Portalのユーザーが必要です)。

AWS上でSAPアプリケーションを設計するということは、すべてのSAPアプリケーションを常に稼働させる必要はないということです。サンドボックス、トレーニング、デモシステムなど、重要ではないSAPシステムのほとんどは、使用していないときには停止することができ、コストを削減できる可能性があります。

AWS上で性能を実現するための1つに、ストレージの設定方法があります。EBSボリュームはアベイラビリティゾーン内で複製されるため、データ損失から保護されています。このような理由から、EBSボリュームで最大限の性能を出すためには、RAID 0によるストライピングでよいです。これは大半のオンプレミス環境では不可能です。様々なEBSボリュームタイプと性能特性の詳細については、ブログ「SAP HANA on AWSの展開 – どのような選択肢が?」も参照してください。これらのEBSボリュームは、HANA以外のデータベースにももちろん使用できます。

AWS自動化

AWSはクラウドオートメーションのリーダーであり、基盤となるリソースをプログラム的にスクリプト化して、予測可能かつ繰返し可能な方法で操作、拡張するための複数の選択肢を提供しています。スクリプトの実行により、SAPアプリケーションサーバーの新規作成、バックアップやスナップショットの取得、最初から新しいインスタンスを構築するなど、SAPの操作を自動化できます。

稼働中のSAP HANAデータボリュームのスナップショットをバックアップ用に取得し、それらのボリュームを復元することがいかに簡単かを示す例をいくつか紹介します。これらのコマンドは容易に作成することができ、crontabやその他の時間駆動のジョブスケジューラツールからバックアップ/リカバリーの操作スクリプトの一部として簡単に実行できます。

例1: 稼働中のHANAデータボリュームのスナップショット取得

  1. SAP HANAインスタンスの停止:
    sudo su – <sid>adm -c "HDB stop"
  2. ファイルシステムの静止:
    umount /hana/data
  3. インスタンスにアタッチされているSAP HANAボリュームのIDを識別:
    aws ec2 describe-volumes --region=us-west-2 --filters Name=attachment.instance-id,Values=i-03add123456789012 Name=tag-value,Values="HANA*" --query 'Volumes[*].{ID:VolumeId,Tag:Tags}'Response:

    [
        {
            "Tag": [
                {
                    "Value": "HANA_root",
                    "Key": "Name"
                }
            ],
            "ID": "vol-071111111111111"
        },
        {
            "Tag": [
                {
                    "Value": "HANA_data #1",
                    "Key": "Name"
                }
            ],
            "ID": "vol-082222222222222"
        },
        {
            "Tag": [
                {
                    "Value": "HANA_data #2",
                    "Key": "Name"
                }
            ],
    		"ID": "vol-0733333333333"
         }
    ]
    
  4. SAP HANAボリュームのスナップショットを取得:
    aws ec2 create-snapshot --region=us-west-2 --volume-id vol-07222222222222 --description "HANA Server Data volume #1"; aws ec2 create-snapshot --region=us-west-2 --volume-id vol-08333333333333 --description "HANA Server Data volume #2
  5. SAP HANAデータボリュームのマウント(この操作はスナップショットがPending状態になれば可能):
    mount /hana/data
  6. SAP HANAを起動:
    sudo su - <sid>adm -c "HDB Start"

例2: スナップショットからデータを復元し、既存のホストにアタッチ

  1. スナップショットから新しいボリュームを作成:
    aws ec2 create-volume --region us-west-2 --availability-zone us-west-2a --snapshot-id snap-1234abc123a12345a --volume-type gp2
  2. EC2インスタンスに新しく作成したボリュームをアタッチ:
    aws ec2 attach-volume --region=us-west-2 --volume-id vol-4567c123e45678dd9 --instance-id i-03add123456789012 --device /dev/sdf
  3. 読込処理を最適化するためにボリュームの初期化(本番環境では強く推奨):
    fio --filename=/dev/xdf --rw=randread --bs=128k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize
  4. SAP HANAデータに関連付けられた論理ボリュームをマウント:
    mount /dev/mapper/hanaexpress-lvhanaexpressdata /hana/data
  5. SAP HANAを起動:
    sudo su - <sid>adm -c "HDB Start"

SAP on AWSで自動化を活用する方法は他にもあります:

  • Amazon Machine Images(AMI)を使用してSAPインスタンスの新しいコピーを作成できます。
  • AWS CloudFormationを使用して新しいSAPインスタンスの作成を自動化、AWS Quick Startを活用してクラウド内に新しいSAP HANA環境の展開を実現できます。

複数のアベイラビリティゾーンおよびまたはリージョンを使った可用性と災害対策

従来のオンプレミス構成のSAPシステムでは、同じ物理データセンター内で高可用性(HA)を取る必要がありました。対照的に、AWSは同じリージョン内の複数のアベイラビリティゾーンにまたがったHAを構成できます。アベイラビリティゾーンは、物理的に隔離されたデータセンターの集合体で、ネットワークのレイテンシーが低く、同じ地理的リージョンに接続されています。いくつかのお客様にとっては、この構成で災害復旧(DR)シナリオとしても十分ですが、そうでない場合、TCOの度合いによって国や都市の異なる2つ目のリージョンの利用といった複数の選択肢を用意しています。以下のSAP分散アーキテクチャの例をご覧ください。

AWS上のSAP分散アーキテクチャ

SAP運用

オンプレミス環境と比較して、AWSではAmazon CloudWatchやAWS CloudTrailなどの監視サービスを使うことができ、SAPシステムの運用においてこれまで以上の透明性と説明責任が得られます。AWSリソースへのきめ細かいセキュリティとアクセス制御には、IAMロールとポリシー、セキュリティグループ、そしてネットワークACLを使うことができます。

  • 監視サービス – CloudWatchやCloudTrailのようなサービスは、リソース使用率を監視するのにも役立ちます。CloudWatchを使用すると、ハードウェア障害が発生した場合に、インスタンスを監視して自動的に復旧するアラームを作成できます。詳細はAWSドキュメントをご覧ください。
  • セキュリティ – IAMはAWSリソースへの洗練されたアクセス制御を可能にするだけでなく、AWSアクセスキーをコピーすることなく、異なるサービス間の安全な通信を可能とするロールも作成できます。詳細はAWSドキュメントをご覧ください。
  • バックアップ – Amazon S3連携をサポートするバックアップツールのいずれかを使用する場合、S3バケットに直接データベースをバックアップできます。そうでない場合は、AWS上で既存のバックアップツールを使用して、EBSボリュームにファイルをエクスポートしてからAmazon S3と同期することもできます。

AWS簡易見積りツール

AWSでは、ハードウェアと運用コストを包括的に把握することが難しいオンプレミスの世界とは異なり、オンデマンドやリザーブドインスタンスを含むEC2インスタンスの様々な支払い方法とインフラストラクチャのコストをマッピングするツールを提供しています。

次のステップ

SAP on AWSの詳細については、以下のリソースをご覧ください:

– Rahul

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

EC2 の料金の値下げ – リザーブドインスタンス & M4 インスタンス

AWS の拡大が進むに連れて、お客様へ提供するサービス価値も高めて行けるように努めています。サプライヤと協力してコスト低減を実現しながら、今まで以上に効率的でコスト効率が良い方法でハードウェアやソフトウェアを構築できるようにしています。定期的そして頻繁にコスト低減を行っているほか、お客様が AWS を利用する上で最適化できるオプションもご提供しています。たとえばリザーブドインスタンス (2009 年にリリース) は、オンデマンド料金に比べ Amazon EC2 ユーザーに大幅な割引を提供します。また、特定のアベイラビリティーゾーンで使用するキャパシティー予約においても同様です。AWS をご利用のお客様は様々な方法でリザーブドインスタンスを購入し管理されています。前払いでより大幅な値下げを利用するお客様もいれば、最初に何も払わずに小さな (とはいっても、かなりの額にはなりますが) 割引をご利用されるお客様もいらっしゃいます。また、その中間を取って一部前払いして先述の 2 つのオプションの間に位置する割引料金をご利用され、満足されている方もいます。このようにお客様の幅広い好みにお応えすべく、AWS では大半の現行世代のインスタンスタイプを対象に 3 年契約の前払いなしスタンダードリザーブドインスタンスをオプションを追加しました。さらに、前払いなしリザーブドインスタンス、コンバーティブルリザーブドインスタンス、汎用 M4 インスタンス (オンデマンドおよびリザーブドインスタンス) の料金の値下げも行うことになりました。これで 61 回目の AWS 料金の値下げとなります。詳細はこちらをご覧ください (すべての変更および値下げは即座に有効になります)。3 年契約のスタンダード RI で前払いなしのオプションを追加 – これまでは 1 年契約のスタンダード RI で前払いなしのオプションをご提供していました。そして本日より、3 年契約の C4、M4、R4、I3、P2、X1、T2 スタンダードリザーブドインスタンスで前払いなしのオプションも開始しました。前払いなしリザーブドインスタンスの料金を低く設定 – C4、M4、R4、I3、P2、X1、T2 インスタンスタイプで、前払いなし 1 年契約のスタンダードと 3 年契約のコンバーティブルリザーブドインスタンスを対象に、最大 17% までの料金値下げを行いました。新しい料金はインスタンスタイプやオペレーティングシステム、リージョンにより異なります。いくつかのリージョンにおける Linux の前払いなしリザーブドインスタンスの平均値下げは次の通りです。

米国東部 (バージニア北部) 米国西部 (オレゴン) 欧州 (アイルランド) アジアパシフィック (東京) アジアパシフィック(シンガポール)
C4 -11% -11% -10% -10% -9%
M4 -16% -16% -16% -16% -17%
R4 -10% -10% -10% -10% -10%

コンバーティブルリザーブドインスタンスをより安価に – コンバーティブルリザーブドインスタンスはインスタンスファミリーや RI と関連のある他のパラメーターをいつでも変更できるようにします。これにより、アプリケーションの展開や変更の必要が発生した場合に RI インベントリを調整することができます。3 年契約のコンバーティブルリザーブドインスタンスの料金を大方の現行世代のインスタンス (C4、M4、R4、I3、P2、X1、T2) で、最大 21% まで値下げしました。いくつかのリージョンにおける Linux のコンバーティブルリザーブドインスタンスの平均値下げは次の通りです。

米国東部 (バージニア北部) 米国西部 (オレゴン) 欧州 (アイルランド) アジアパシフィック (東京) アジアパシフィック(シンガポール)
C4 -13% -13% -5% -5% -11%
M4 -19% -19% -17% -15% -21%
R4 -15% -15% -15% -15% -15%

このような値下げは、その他ほぼすべてのリージョンでも有効になる予定です。M4 インスタンスをより安価に – M4 Linux インスタンスの料金を最大 7% まで引き下げました。新価格については EC2 リザーブドインスタンスの料金表ページEC2 料金表ページまたは AWS 料金表 API をご覧ください。詳細 次のブログは EC2 リザーブドインスタンスモデルに追加した改良点の詳細情報について説明しています。

  • 「EC2 リザーブドインスタンスの新たなインスタンスサイズの柔軟性 (New – Instance Size Flexibility for EC2 Reserved Instances)」 – このブログはインスタンスファミリーやリージョン内で複数のインスタンスサイズに単一の RI を使用する方法について説明しています。
  • 「EC2 リザーブドインスタンスの更新 – コンバーティブル RI のリージョン別メリット (EC2 Reserved Instance Update – Convertible RIs and Regional Benefit)」 – このブログはリージョン別メリットと (リージョン内でどの AZ でもインスタンスを実行できるように、キャパシティーの予約を適用しない) インスタンスファミリーや他のパラメーターの変更を許可するコンバーティブル RI について説明しています。
  • 「EC2 リザーブドインスタンスモデルを単純化 (Simplifying the EC2 Reserved Instance Model)」 – このブログは 3 つの支払いオプションを紹介しています (全前払い、一部前払い、前払いなし)。

詳細は AWS 料金表リザーブドインスタンスのよくある質問をご覧ください。

Jeff;

【AWS Database Blog】AWS Database Migration Service におけるイベント通知

こんにちは。ソリューションアーキテクトの江川です。本日は、AWS のプロダクトマネージャーである Eran Schitzer が、AWS Database Blogに投稿したEvents and Notifications in AWS Database Migration Service を翻訳してご紹介します。


先日、AWS Database Migration Service (AWS DMS) に新機能が追加され、Amazon Simple Notification Service (Amazon SNS)を介して、Email や テキストメッセージ、HTTP エンドポイントへの通知といった形で、DMS のイベント通知を受け取れるようになりました。

お客様は2種類のイベント(DMS インスタンスに関連するイベントと、レプリケーションタスクに関連するイベント)をサブスクライブし、通知を受信できます。DMS インスタンスに関連するイベントには、可用性、設定変更、作成、削除、メンテナンスに関するイベントが含まれます。例えば、DMS インスタンスがメンテナンスにより停止すると、通知がトリガーされます。

レプリケーションタスクに関連するイベントには、タスクの開始、停止、終了、Full Load の完了、CDC の開始などのイベントが含まれます。例えば、移行タスクとしてすべてのデータを移行し終えると、“Full Load completed” という通知がトリガーされます。もし、タスクが Full Load に続けて、CDC を実行する(つまり、Full Load が開始してからのデータの変更をレプリケーションする)設定となっていた場合は、続けて “CDC started” という通知がトリガーされます。

さらに、AWS DMS ではイベントが様々なカテゴリに分類されており、ユーザーは AWS DMS コンソール、AWS DMS API を使って、そのカテゴリをサブスクライブできます。サブスクライブすることにより、そのカテゴリに関するイベントが起きた際に、通知されます。例えば、特定のレプリケーションインスタンスについての “creation(作成)”カテゴリをサブスクライブした場合、レプリケーションインスタンスが作成されているなどのような、レプリケーションインスタンスに影響を与える creation に関連したイベントが起きた際はいつでも通知がなされます。

下記の一覧は、現時点で DMS レプリケーションインスタンスについてサブスクライブできるカテゴリを示しています。

  • Configuration change(設定変更)—レプリケーションインスタンスの設定が変更されています
  • Creation(作成)—レプリケーションインスタンスが作成されています
  • Deletion(削除)—レプリケーションインスタンスが削除されています
  • Maintenance(メンテナンス)—レプリケーションインスタンスのオフラインメンテナンスが実行中です
  • Low storage—レプリケーションインスタンスの空きストレージが少なくなっています
  • Failover(フェイルオーバー)—Multi-AZ インスタンスのフェイルオーバーに関連するイベント。フェイルオーバーの有効化、開始、完了など。
  • Failure(失敗)—レプリケーションインスタンスで、ストレージ障害やネットワーク障害が発生しました

下記の一覧は、現時点で DMS レプリケーションタスクについてサブスクライブできるカテゴリを示しています。

  • State change— レプリケーションタスクが開始もしくは停止されました
  • Creation(作成)—レプリケーションタスクが作成されました
    Deletion(削除)—レプリケーションタスクが削除されました
  • Failure(失敗)—レプリケーションタスクが失敗しました

AWS DMS によるイベントとイベントカテゴリの一覧は、ドキュメントのイベントと通知の使用を参照してください。

AWS DMS イベントをサブスクライブするには、以下の通り行います。

  1. Amazon SNS トピックを作成します。このトピックには、どんなタイプの通知を受け取りたいか、受け取るアドレスや電話番号を設定します。
  2. AWS マネジメントコンソール、AWS CLI, もしくは AWS DMS API を通じて、AWS DMS イベント通知のサブスクライブを行います。
  3. AWS DMS のイベント通知を受け取るための承認メールもしくは SMS メッセージを受け取り、E メール、SMS メッセージ内のリンクをクリックして、サブスクライブの確認を行います。

サブスクライブしたことを確認すると、AWS DMS コンソールの Event Subscriptions セクションにて、お客様のサブスクリプションのステータスが更新されます。

そして、イベント通知の受信が開始されます。

コンソールを使ったテーブルマッピングについての詳細は、DMS ドキュメントを参照ください。

AWS Database Migration Service 全般に関する詳細は、こちらのウェブサイトを参照ください。

AWS HIPAA 対応サービス発表についての詳細情報

AWS では、HIPAA 対応サービスの発表がいくつかありました。AWS ヘルスケアおよびライフサイエンスグローバルテクニカルリーダーの Patrick Combes、および AWS ヘルスケアおよびライフサイエンスパートナーソリューションアーキテクトの Aaron Friedman が、その全貌についてお知らせするためにこの投稿を書いています。

-Ana


ここ数週間の間に、次の AWS のサービスが BAA に追加されたことをお知らせいたします。 Amazon API GatewayAWS Direct ConnectAWS Database Migration ServiceAmazon SQS。これら 4 つのサービスはすべて AWS へのおよび AWS を通じてのデータの移動を容易にするため、お客様がこれらのサービスを使用してヘルスケアにおけるソリューションをどのように促進できるか楽しみです。これらのサービスのそれぞれのユースケースは膨大なので、お客様が Protected Health Information (PHI) でこれらのサービスを使用できるいくつかの方法を取り上げます。

AWS の事業提携の追補 (BAA) の適用を受けるすべての HIPAA の対象サービスと同様に、PHI は、保管時または転送時に暗号化される必要があります。HIPAA のホワイトペーパー を参照することをお勧めします。これは、PHI を保存、処理、および転送するための AWS の HIPAA 対応サービスの設定方法について説明しています。そしてもちろん、PHI に該当しないアプリケーション部分については、90 以上のサービスを使用して、ユーザーに最適なエクスペリエンスを提供することができます。HIPAA のアーキテクチャに関するアイデアは、ウェブサイトでご覧いただけます。

Amazon API Gateway
Amazon API Gateway は、ウェブサービスで、開発者はこれを利用することにより、あらゆる規模で、簡単に API の作成、配布、監視、保護が行えます。PHI を使用して、API Gateway を安全に通過することができるようになりました。患者/プロバイダディレクトリ、患者ダッシュボード、医療機器レポート/テレメトリー、HL7 メッセージ処理などのアプリケーションは、AWS またはクライアントプレゼンテーションレイヤー内で実行している任意の数と種類のアプリケーションに情報を安全に受け入れ配信できます。特に楽しみなのは、ヘルスケア情報を交換するうえで Amazon API Gateway をお客様がどのように活用するかです。Fast Healthcare Interoperability Resources (FHIR) 仕様は、エンティティ間で医療情報を共有する方法に関する次世代の標準となりそうです。RESTful アーキテクチャを強力にサポートすることにより、FHIR は、Amazon API Gateway の API 内で簡単に体系化することができます。FHIR の詳細については、AWS 医療コンピテンシーパートナーである Datica に、優れた入門書があります。

AWS Direct Connect
Johnson & Johnson のような当社のヘルスケアおよびライフサイエンスのお客様の一部は、ハイブリッドアーキテクチャを活用し、オンプレミスインフラストラクチャを AWS クラウドに接続する必要があります。AWS Direct Connect を使用すると、AWS とデータセンター、オフィス、またはコロケーション環境間にプライベート接続を確立することができます。これにより、多くの場合、ネットワークのコスト削減、帯域幅のスループットが向上し、インターネットベースの接続よりも均質なネットワーク体験を提供できます。ハイブリッドアーキテクチャ戦略に加えて、AWS Direct Connect は、AWS への安全なデータ移行を支援することができます。これは Amazon S3 や Amazon EMR など、PHI の保管と処理に HIPAA の対象サービスを幅広く使用するための第一歩です。さらに、サードパーティー/外部でホストされたアプリケーションやパートナー提供のソリューションに接続したり、エンドユーザーをクラウドベースの電子カルテシステムなどの同じヘルスケアアプリケーションに安全かつ確実に接続することができます。

AWS Database Migration Service (DMS)
現在までに、お客様は、AWS Database Migration Service を通じて 20,000 を超えるデータベースを AWS に移行しました。お客様は、クラウド移行戦略の一環として DMS を使用することが多く、今やそれを PHI を含むコアデータベースを安全かつ容易に AWS クラウドに移行するために使用することもできます。DMS を使用した移行中でもソースデータベースは完全に利用可能な状態に保たれるので、データベースを AWS に移行する際に、ビジネスクリティカルなアプリケーションのダウンタイムは最小限に抑えられます。このサービスは、患者ディレクトリ、支払い/トランザクションレコードデータベース、収益管理データベースなどのアイテムを AWS に安全に転送するために利用できるようになりました。

Amazon Simple Queue Service (SQS)
Amazon Simple Queue Service (SQS) は、あらゆる規模での、分散されたソフトウェアコンポーネントおよびマイクロサービス間での信頼性の高い通信のためのメッセージキューイングサービスです。想定されるお客様による PHI での SQS の使用方法は、HL7 または FHIR メッセージをアプリケーションの他の部分に渡すアプリケーションコンポーネント間の要求をバッファすることです。PHI を含むメッセージが、受信した順に渡され、受信した順に配信され、使用者が処理して削除するまで使用できるように、SQS FIFO などの機能を活用できます。これは、病院での患者記録の更新または支払い情報の処理を行うアプリケーションにとって重要です。

では、始めましょう。
ヘルスケアアプリケーションの一環として、新しい HIPAA 対応サービスをお客様がどのように使用されるのか、とても楽しみです。あなたが一番楽しみにしているのはどんな点ですか。下にコメントを残してください。

New – Amazon Simple Queue Service (SQS) でサーバー側の暗号化を導入

AWS シリーズの中でも尊敬に値するサービスの 1 つ、Amazon Simple Queue Service (SQS) は多くのアプリケーションにおいて欠かせない一部を担っています。「Amazon SQS でより優れたアーキテクチャを実現 (Amazon SQS for Better Architecture)」や「Amazon SQS と Amazon DynamoDB で大量のメッセージを処理する (Massive Message Processing with Amazon SQS and Amazon DynamoDB)」などのプレゼンテーションは、SQS をどのように使用すれば復元力とスケーラブルが高いアプリケーションを構築できるのか説明しています。そして今回、サーバー側の暗号化をサポートすることでその SQS がさらに便利になりました。今後は AWS Key Management Service (KMS) による暗号化キーを使用して、スタンダードと FIFO キューの両方で SQS 暗号化済みメッセージを保存するオプションが提供されます。このオプションはキューの作成時に選ぶことができます。また、同時に既存のキューで設定することも可能です。SSE はメッセージ本文を暗号化しますが、キューのメタデータやメッセージのメタデータまたはキューごとのメトリクスは対象外になります。既存のキューに暗号化を追加しても、過去のメッセージは暗号化の対象にはなりません。同様に、暗号化を解除しても過去のメッセージの暗号化がキャンセルされることはありません。

暗号化したキューを作成
新しいバージョンの AWS Management Console では、便利なグラフィックを使用してスタンダードと FIFO キューのどちらかを選択できます。

キューとオプションの Dead Letter Queue に属性を設定することができます。

Use SSE を確認し希望のキーを選択できるようになりました。

各顧客やリージョン独自の AWS マネージド型カスタマーマスターキー (CMK) を使用したり、ご自分のキーを作成して管理することができます。ご自分のキーを使用する場合は、メッセージの暗号化や複合化を許可するため、KMS キーポリシーを必ず更新してください。データ再利用期間を設定することもできます。この間隔は SQS がどれだけ頻繁に KMS からの暗号情報を更新するか、1 分から 24 時間の範囲でコントロールすることができます。間隔を短くすると、セキュリティプロフィールを向上させることができますが、KMS のコストは上昇します。詳細は「SQS SSE のよくある質問 (SQS SSE FAQ)」や「サーバー側の暗号化 (Server-Side Encryption)」のドキュメントをご覧ください。

今すぐ利用可能
サーバー側の暗号化は US West (Oregon) リージョンと US East (Ohio) リージョンで今すぐご利用いただけます。その他でも今後リリース予定です。暗号化の使用は無料となりますが、SQS が KMS に向けたコールを発信する場合は有料になります。詳細は「カスタマーマスターキー (CMK) 使用料の料金を推定するには (How do I Estimate My Customer Master Key (CMK) Usage Costs)」をご覧ください。

Jeff;

AWS ホットスタートアップ – 2017 年 4 月

春到来に伴い Tina Barr のスタートアップ企業を紹介するブログです。お楽しみください!

-Ana


今月も引き続き、AWS を利用しているホットなスタートアップ企業を紹介していきます。今回は 3 つの新しいスタートアップ企業を紹介します。

  • Beekeeper – 社員同士のコミュニケーションをよりシンプルに
  • Betterment – 誰でも簡単に投資をスタート
  • ClearSlide – 業界をリードするセールスエンゲージメントプラットフォームを提供

3 月のホットスタートアップを見逃しましたか? 大丈夫、こちら からご覧いただけます。

Beekeeper (スイス、チューリッヒ) Beekeeper のロゴ
チューリッヒ工科大学 (ETH Zurich) 卒業の Flavio Pfaffhauser
Christian Grossmann は、人々を結び付けるためのテクノロジーを構築することに熱心です。学生のソーシャルコミュニティから始まったそれは、すぐに Beekeeper になりました。Beekeeper は、仕事場において社員がどこからでもコミュニケーションを取り合うことを可能にするプラットフォームです。Flavio と Christian は自分達の目的に適った方法で、人々がエンゲージするソーシャルプラットフォームの構築方法を学びました。すると、様々なビジネスから各社の特別なプロセスとニーズに対応できるプラットフォームをリクエストされるようになりました。このプラットフォームは、デスクに向かっていたり出先にいたとしても、まるですぐ隣に相手が座っているかのように感じられるものを作りたいというコンセプトから始まりました。2012 年に創設された Beekeeper は、情報交換、コミュニケーション、ピアコラボレーションの改善に焦点を当てています。そして組織にとって、社員の声に耳を傾けることが非常に大切であると考えています。「まずはモバイル、デスクトップも OK (“Mobile First, Desktop Friendly”)」なプラットフォームは、シンプルかつ直観的なインターフェイスで、複数のオペレーティングシステムを簡単に 1 つのエコシステムにすることができます。インターフェイスは企業のブランドやアイデンティティに合わせてスタイルしたりカスタマイズすることができます。社員はいつでもどこにいても、プライベートチャットやグループチャット、ビデオ、ファイル共有、フィードバックに関するアンケート調査などを通じて同僚とコミュニケーションを取り合うことができます。Beekeeper の分析ダッシュボードで、リーダーシップチームはディスカッションで何がトレンディングトピックになっているのか確認したり、社員のエンゲージメントやアプリ使用をリアルタイムでトラッキングすることができます。Beekeeper は現在 137 か国に渡り、サービス業や建設業、運送業そしてその他の業界で利用されています。Beekeeper は同社のエンジニア達が顧客サービスの問題に集中できるようにする AWS を好んで使用しています。同社はそのインフラストラクチャ構築に Amazon EC2Amazon S3Amazon RDS などのサービスを使用しています。これらはすべてテクニカルチームが管理タスクに煩わされることなく作業を進行できるようにしています。Amazon Elastic TranscoderAmazon QuickSight は、分析ダッシュボードの構築やデータウェハウスを実行するための Amazon Redshift で使用されています。最新情報については Beekeeper の公式ブログをご覧ください。

Betterment (ニューヨーク州、ニューヨーク)
Betterment のロゴ
Betterment は個人のファイナンシャルゴールにかかわらず、誰もが簡単に利用できる投資方法の提供を目標としています。2008 年、Jon Stein は業界に新たなイメージを与え、自らが経験したミスを将来の投資家達が回避できるようにすることを目的として同企業を設立しました。当時、資金を投資する方法としては自分で行うか別の誰かに依頼するといったように、一般的にあまりオプションがありませんでした。そして残念ながら、ファイナンシャルアドバイザーというのは、実際にはクライアントにとってベストではなくても特定の投資を勧めるように報酬を受け取っている場合もあります。Betterment は顧客にとって最善の利益となり個人のファイナンシャルゴールに適った投資だけを選択します。そして現在、同社は 240,000 人の顧客を抱え資産 80 億ドル以上を管理する、インディペンデントで最大規模のオンライン投資アドバイザーとなりました。Betterment はテクノロジーを使用して投資をより簡単そして効率的にしながら、確定申告後の利益を増やせるように顧客をサポートしています。同社は幅広いファイナンシャルプランニングサービスを提供し、顧客のライフゴールにフィットするようにプランを立てるようにしています。投資プランを開始するには、まず顧客は年齢、年金口座の状況、年収を入力します。すると Betterment が推奨投資額やその個人に適したアカウントタイプをお勧めします。従来の投資サービスが低コストでは提供できない方法で、同社は顧客の投資を管理しています。Betterment のエンジニア達は常にできる限り早急に顧客の資金を最大限に活用できるようにするため、業界で変化し続けるテクノロジーの構築に取り組んでいます。AWS は Betterment のプロビジョンインフラストラクチャを容易にしたり、これまでチーム全体が管理する必要のあった様々なサービス機能のオフロードを可能にする柔軟性を提供しています。クラウドを始めたばかりの頃、Betterment は Amazon EC2Amazon RDS Amazon S3 のスタンダード実装を使用していました。完全に AWS の使用を開始してからは Amazon RedshiftAWS LambdaAWS Database Migration ServiceAmazon KinesisAmazon DynamoDB などのサービスを活用するようになりました。そして現在では開発、テスト、機能のデプロイ、機能強化において 20 種類以上の AWS サービスを日常的に使用しています。Betterment の詳細はこちらをご覧ください。

ClearSlide (カリフォルニア州サンフランシスコ)
ClearSlide はセールスエンゲージメントプラットフォーム業界をリードし、すべてのカスタマーインタラクションに問題のないよう完全な統合ツールを提供しています。2009 年の設立以来、ClearSlide はカスタマーエクスペリエンスを改善する方法を模索し、セールスリーダーやチーム、マーケティング、カスタマーサポートチームなどに向けて数々のツールを開発してきました。このプラットフォームは顧客がすぐにコンテンツ、コミュニケーションチャネル、詳細情報にアクセスできるようにすることで、顧客がより良い決断を下し管理できるためのサポートを提供しています。ClearSlide は Comcast、The Sacramento Kings、The Economist など何千社という企業に同サービスを提供し、これまでに毎分 7.5 億件のエンゲージメントを生成してきました。ClearSlide はセールスプロセスにおけるすべての面でソリューションを提供しています。ClearSlide はセールスリーダーに向けてエンゲージメントダッシュボードを提供し、取引上の可視性やコーチング、販売数を正確に予測する方法を改善できるようにしています。マーケティングやセールスチームにおいては、販売者を適切なコンテンツに正確なタイミングで正しい関連性に向けて導き、コンテンツの ROI を最大限にするための情報を提供します。セールス担当においては、ClearSlide を使用することでコミュニケーション、コンテンツ、分析を 1 つのプラットフォームエクスペリエンスで統合することができます。メール、直接の会話、オンラインミーティング、ウェブ、ソーシャルなどを使用してコミュニケーションを取ることができます。現在、ClearSlide の顧客は成功した取引の割合が 10 – 20% 上昇したことを報告しています。また、新しい担当者のオンボーディングに費やす時間を 25% 削減し、販売費 50-80% の削減に成功したことが分かっています。ClearSlide は幅広い AWS サービスを使用していますが、Amazon EC2Amazon RDS がもっとも大きな影響を同社のビジネスにもたらしました。EC2 を使用することで、成長過程にあるスタートアップ企業にとって重要なポイントとなるコンピューティング性能のスケールが簡単にできます。また、開発から統合そしてステージングから本稼働まで、デプロイメント時に一貫性を提供します。RDS はオーバーヘッドを削減し ClearSlide がデータベースインフラストラクチャをスケールできるようにします。AWS は時間のかかるデータベース管理タスクを行うことができるので、ClearSlide は運用費を削減し顧客に対してより計画性をもって対応することが可能になります。ClearSlide を使用することで 22% も販売サイクルを短縮した LiveIntent のビデオをご覧ください。最新情報については同社の Twitter をフォローしてください。今月も AWS を利用している素晴らしいホットスタートアップをご覧いただき、ありがとうございました。

-Tina

ローカルのMosquitto MQTT BrokerをブリッジにAWS IoTを使う

AWS SDKまたはAWS IoT Device SDKを使用して、数百万のオブジェクトをAWS IoTに安全に接続できます。
製造業におけるIoTの場合、オブジェクトは複数の理由でゲートウェイに接続されます。
センサーは非常に制約され、クラウドに直接接続できないことや、センサーはプロトコルとしてMQTTが使えないまたは、 ゲートウェイ上でローカルに分析と処理を実行する必要があります。

ローカルMQTTブローカーの1つの機能は「ブリッジ」と呼ばれ、MQTTメッセージを交換できるように、ローカルMQTTブローカーをAWS IoTに接続することができます。 これにより、オブジェクトがAWS IoTと双方向で通信し、AWSクラウドの恩恵を受けることができます。

この記事では、この機能が非常に便利で、実装方法を示すユースケースについて説明します。

 

MQTTブローカーをAWS IoTにブリッジする理由

IoTではセキュリティが最も重要であり、AWS IoTブローカーには、クライアント証明書付きのTLS 1.2などに基づいてデバイスを認証および認可する高度なセキュリティビルトインが組み込まれています。

従来のIoTデプロイメントを使用している場合は、MQTTブローカーにユーザー名やパスワードなどの他の認証メカニズムを使用してオブジェクトをすでに接続している可能性があります。 MQTTブローカーは、センサーがデプロイされる非常に近い場所(ローカルMQTTブローカー)もしくはクラウドの中に構築されています。

現在のセキュリティ標準をAWS IoTのものに合わせてアップグレードする予定で、AWS IoTのスケーラビリティとルールエンジンの恩恵を受けるには、従来のMQTTブローカーをAWS IoTにブリッジすることができます。これは、現在のシステムのアップグレードを待たずにすばやく導入できる簡単な一時的なソリューションです。単一のブローカーを超えるスケーリングはこの記事の範囲には含まれていませんが、Mosquitto MQTT Brokerのブリッジ機能に焦点を当てます。

MosquittoのようなオープンソースのMQTTブローカーは、Linuxのような多くのオペレーティングシステムにインストールすることができます。ローカルデバイスにMosquittoをインストールすると、Mosquitto bokerの機能(ローカルでのメッセージの永続化、ローカルでのログのアクティビティ)をローカルで有効にするだけでなく、ローカルデバイスにMosquittoをインストールすることで、AWS IoTにデータを送信するための特別なコードを開発する必要がありません。

(more…)

AWS Storage Gateway でファイルインターフェイス

AWS re:Invent のレビュー」といったブログカテゴリを追加した方がいいかもしれませんね。去年の 11 月、AWS Storage Gateway に重要な機能を追加しましたが、忙しすぎてその調査やブログを書く時間を取れずにいました。Storage Gateway は既存のアプリケーションと AWS Cloud の間に位置するマルチプロトコルストレージアプライアンスです。お使いのアプリケーションやクライアントオペレーティングシステムは (設定によりますが) ゲートウェイをファイルサーバー、ローカルディスクボリュームまたは仮想テープライブラリ (VTL) と見なします。その背景でゲートウェイはコスト効率が良く耐久性のある安全なストレージに Amazon Simple Storage Service (S3) を使用しています。Storage Gateway はデータをローカルでキャッシュし、帯域幅の管理機能を使用してデータ転送を最適化します。Storage Gateway はインストールや設定そして実行が簡単な自己完結型の仮想アプライアンスとして提供されています (詳細は「Storage Gateway のユーザーガイド (Storage Gateway User Guide) 」をご覧ください)。既存の環境でクラウドストレージのスケールや耐久性そしてコスト面におけるメリットを活用できます。既存のファイルやディレクトリを S3 に移動するプロセスを減らし、ドラッグアンドドロップ (または CLI ベースのコピー) でシンプルに移動できます。その他多くの AWS サービスと同様に、2012 年にリリースされてから Storage Gateway にいくつもの機能が追加されてきました (「AWS Storage Gateway – AWS クラウドストレージと既存のオンプレミスアプリケーションを統合 (The AWS Storage Gateway – Integrate Your Existing On-Premises Applications with AWS Cloud Storage)」)。Storage Gateway をリリースした時点で、ストレージボリュームの作成や iSCSI デバイスにアタッチできたほか、ボリュームすべてを保存したり、ゲートウェイでもっとも頻繁にアクセスされているデータのキャッシュを保存するオプションを提供します。そして、これらはすべて S3 でサポートされています。そしてその後、仮想テープライブラリのサポートを追加しました (「AWS Storage Gateway で仮想テープライブラリを作成 (Create a Virtual Tape Library Using the AWS Storage Gateway)」)。今年に入ってからは読み取り専用のファイル共有、ユーザーアクセス権限のスカッシュ、および追加/削除されたオブジェクトのスキャンを追加しました。新しいファイルインターフェイス AWS re:Invent で 3 つめのオプションをリリースしました。今回はそれについてご紹介します。オンプレミスサーバーやデスクトップにマウントできる仮想ファイルサーバーとして Storage Gateway を使用できるようになりました。データセンターまたはクラウドでセットアップが完了すると、設定済みのバケットを NFS マウントポイントとして利用できるようになります。アプリケーションは NFS 上でファイルの読み取りや書き込みを行うだけです。背景ではゲートウェイがネイティブにアクセスできる S3 バケットでこうしたオペレーションをオブジェクトレベルにします。ファイルゲートウェイを作成するには Storage Gateway コンソールにアクセスし [Get started] をクリックしてから [File gateway] を選択します。

VMware ESXi または Amazon EC2 のホストプラットフォームを選択します。

プレミスで Storage Gateway をホストし、永続的または一時的なクラウドへのブリッジとして使用するお客様が多くなるのではないかと思います。このオプションのユースケースには、バックアップ、移行、アーカイブ、分析、ストレージ階層化、大量のコンピューティングを伴うプロセスの簡略化が含まれています。クラウドにデータが入り次第、複数のストレージ階層化 (不定期なアクセスや Glacier はアーカイブに最適です)、ストレージ分析、タグ付けなど様々な S3 の機能を活用できるようになります。私のオンプレミスにはあまりデータがないので、このブログ用として EC2 インスタンスで Storage Gateway を実行します。インスタンスを起動し画面に表示される手順ごとに設定します。適切なインバウンドセキュリティグループルールを作成します (HTTP アクセスのポート 80 と NFS のポート 2049)。キャッシュとして使用するために汎用目的の SSD ストレージ 150 GiB を追加しました。

インスタンスが起動したら、そのパブリック IP アドレスを取得し、新に開始したゲートウェイと繋げるために使用します。

タイムゾーンを設定しゲートウェイの名前を指定したら [Activate gateway] をクリックします。

次にローカルストレージをキャッシュとして設定し [Save and continue] をクリックします。

ゲートウェイが実行され、コンソールでも表示されています。

次に [Create file share] をクリックし、NFS シェアを作成して S3 バケットと関連付けます。

ご覧のように、ここでストレージクラスを選択することができます (自分のニーズまたはユースケースに合わせて Standard または Standard – Infrequent Access を選択)。この時点でゲートウェイはバケットにファイルをアップロードする必要があります。[Create a new IAM role] をクリックすると、ロールとポリシーを作成できます (詳細は「Amazon S3 Destination にアクセス権限を付与する (Granting Access to an Amazon S3 Destination)」をご覧ください)。設定を確認し [Create file share] をクリックします。

ところで Root スカッシュは AWS Storage Gateway の機能で野菜の名前ではありません (念のため)。これが有効になっていると (デフォルトでは有効) root (user id 0) が所有するものとして到着したファイルは user id 65534 にマップされます (従来は nobody)。新しいファイルと新しいディレクトリにデフォルト権限をセットアップすることもできます。新しいシェアがコンソールで表示され、数秒で利用が可能になります。

コンソールに Linux、Microsoft Windows、macOS の適切なマウントコマンドが表示されます。このコマンドはインスタンスのプライベート IP アドレスを使用します。大方の場合、その代わりにパブリックアドレスの使用をおすすめします (説明の必要もないと思いますが、パブリック NFS シェアを作成する場合は慎重に行ってください。そして接続を許可している IP アドレスを詳細に管理することもお忘れなく)。S3 コンソールでバケットを調べます (jbarr-gw-1)。予想どおり空でした。

次に EC2 インスタンスでシェアをマウントし、いくつかのファイルをコピーします。

コンソールに戻ると、予想どおりバケット内に新しいフォルダ (jeff_code) を見つけることができます。その中にはシェアにコピーしたファイルがあります。

お分かりのように、ファイルは S3 に直接コピーされ、通常の S3 オブジェクトになっています。つまり、既存の S3 ツール、コード、分析を使用してプロセスできることを意味しています。以下の例をご覧ください。

  • 分析 – 新しい S3 メトリクスと分析を使用して、バケット全体またはその中のディレクトリツリーを分析することができます。
  • コードAWS LambdaAmazon Rekognition はイメージのアップロードをプロセスする場合に使用できます。アイデアやコードについては「サーバーレスの画像認識について (Serverless Photo Recognition)」をご覧ください。Amazon Elasticsearch Service を使用していくつかまたはすべてのファイルをインデックスしたり Amazon EMR で大量のデータをプロセスすることができます。
  • ツール – バケット内にある既存のオブジェクトをプロセスしたり、S3 API を使用して新しいオブジェクトを作成することができます。作成または削除を行うコードまたはスクリプトが RefreshCache 関数を呼び出し、バケットに関連しているゲートウェイのコンテンツを同期するようにします (同じバケットで複数の読み取り専用ゲートウェイにポイントすることで、マルチサイトデータディストリビューションワークフローを作成できます)。また、バックアップの送信先としてシェアを使用することで、ファイル中心のバックアップツールを活用することもできます。

ゲートウェイはファイルのメタデータすべてを S3 メタデータとして保存します (所有者、グループ、権限など)。

Storage Gateway リソース Storage Gateway の詳細については次をご参照ください。プレゼンテーション – 「AWS Storage Gateway の詳細について (Deep Dive on the AWS Storage Gateway)」: ホワイトペーパー – 「ハイブリッドアーキテクチャのファイルゲートウェイ – 概要とベストプラクティス (File Gateway for Hybrid Architectures – Overview and Best Practices)」: 最近のビデオ:

今すぐ利用可能
この優れた AWS 機能は去年の 11 月よりご利用可能になっています。

Jeff;

新しい Samsung DeX と Samsung Galaxy S8/S8+ で Amazon WorkSpaces を使用

テクノロジーの進化とその改良を見るのは実に面白いものです。たとえば、最近の携帯電話にはハイエンドなデスクトップが備えるほどの解像度を持つ画面が使用されているほか、接続性や携帯性においても複数のオプションが提供されています。今週初めに、最新の Samsung Galaxy S8+ スマートフォンと、独自の新しいコンパニオンデバイス、Samsung DeX Station を試す機会に恵まれました。まず、スマートフォンに Android 向けの Amazon WorkSpaces クライアントをインストールし、WorkSpace の登録コードを入力してログインしてみました。これら一連の操作は、こちらの新しいビデオでご覧いただけます。

DeX にはキーボードとマウス用の USB コネクターが含まれています。Bluetooth で操作することもできます。冷却ファン、時間を短縮できるスマートフォンの充電器、HDMI とイーサネットポートも含まれています (スマートフォンのデータ通信または Wi-Fi 接続の使用も可)。すべて一緒にすれば、どこにいてもクラウドベースのデスクトップにアクセスできます。滞在先のテレビやモニターを使用すれば、企業ネットワークのフルアクセスでファイルやその他のリソースにアクセスできるので、旅先の荷物も軽くなります。

Jeff;

PS – 私の WorkSpace についてもう少し詳しく知りたければ「Amazon WorkSpace が大活躍 (I Love my Amazon WorkSpace)」をご覧ください。