Amazon Web Services ブログ

AWS Direct Connect アップデート – Link Aggregation Groups, Bundles そして re:Inventの一部振り返り

AWS Direct Connect は、大規模な顧客に対してオフィス、データセンターやコロケーション設備におけるプライベートでハードウェア専有のネットワーク接続の設立を支援します。1 Gbps と 10 Gbps の接続を設立することで、顧客にとってはネットワークコストの削減、データ転送スループットの向上、そしてインターネット基盤で可能な接続よりもさらに安定したネットワーク接続を確立することができます。本日は、Direct Connect の新しい Link Aggregation 機能についてご紹介します。また、新しい Direct Connect バンドルについて、そして Direct Connect をどのように活用して AWS re:Invent 2016 年の最先端の顧客エクスペリエンスを提供していることについてもさらに詳しくお話ししたいと思います。

Link Aggregation グループ 顧客なかには自身のロケーションと 46 の Direct Connect ロケーションのうちの 1 つに複数の接続 (一般的にはポートと呼ばれる) を設立することをお望みの方もいらっしゃると思います。このような顧客のなかには、AWS の外部におけるネットワーク問題に対しても復元力がある高度な利用可能性をもったリンクの設立が希望でしょう。また、さらなるデータ転送スループットのみを必要とする場合もあります。このような顧客にとって重要なユースケースをサポートするために、最大で 4 つまでのポートの購入とそのすべてを単一管理の接続として扱うことができるサービスの提供が始まりました。これは、Link Aggregation グループ、あるいは LAG と呼ばれます。このサービスを設立すると、トラフィックはポートを通して個別のパケット接続レベルで負荷分散されます。すべてのポートは同時にアクティブとなり、単一の BGP セッションとして提供されます。グループ間のトラフィックは、動的 LACP (Link Aggregation Control Protocol、または ISO/IEC/IEEE 8802-1AX:2016) を通して管理されます。グループの作成時には、接続が有効となる際にアクティブとなるべきポートの最低数も指定する必要があります。複数のポートを持った新しいグループを注文して、既存のポートをこの新しいグループに加えることもできます。どちらの場合でも、すべてのポートは同じスピード (1 Gbps あるいは 10 Gbps) であることが必要です。グループとしてのすべてのポートは、AWS 側で同じデバイスとして接続されます。デバイスに空き容量がある限り、既存のグループにポートを追加することもできます (空き容量情報は Direct Connect Console から入手できるようになりました)。既存のグループの拡張を希望していても、デバイスに開放ポートがない場合には、新しいグループを注文して接続を移動するだけ十分です。コンソールから Link Aggregation を作成する方法を次に示します。まず、新しい LAG をゼロから作成します。

次に、既存の接続から LAG を作成します。


Link Aggregation グループは、 US East (Northern Virginia)US West (Northern California)US East (Ohio)US West (Oregon)Canada (Central)South America (Brazil)Asia Pacific (Mumbai)Asia Pacific (Seoul) リージョンで現在提供されており、今すぐ作成できます。 今月末には、そのほかのリージョンでもサービスの提供が可能になる予定です。

Direct Connect バンドル
re:Invent 2016 年にいくつかの新しい強力な Direct Connect バンドルが発表されました。それぞれのバンドルは、複雑性を低減してパフォーマンスを向上させた最先端のハイブリッドリファレンスアーキテクチャとなっています。新しいバンドルは次の通りです。Level 3 コミュニケーションパワー Amazon WorkSpaces – エンタープライズアプリケーションデータ接続、ユーザーワークスペース、そしてエンドポイントデバイスによって、信頼できるパフォーマンスとより向上したエンドユーザーエクスペリエンスを提供します: AT&T NetBond によって拡張された SaaS アーキテクチャ – AWS クラウドに移動したアプリケーション用に拡張された機能とユーザーエクスペリエンス: Megaport DX 搭載の Aviatrix ユーザーアクセス – AWS クラウドリージョン間、エンタープライズデータセンターと AWS 間、そして AWS への VPN アクセスにおける暗号化接続のサポート: Verizon の安全なクラウド相互接続 における Riverbed の Hybrid SDN/NFV アーキテクチャ – エンタープライズ顧客に安全で最適化された AWS サービスへのアクセスをハイブリッドネットワーク環境で提供します:

re:Invent 2016 年の Direct Connect
re:Invent の参加者とパートナーに最上のエクスペリエンスを提供するために、高度な利用性と完全な冗長化の通信を設立できる Level 3 を開発しました。このネットワークは、休憩セッション、認定試験、ハンズオンラボ、キーノート講演 (122 か国から 25000 人以上の閲覧者に向けたライブストリームを含む)、ハッカソン、ブートキャンプ、ワークショップをサポートするために利用されました。この re:Invent ネットワークは、10 Gbps 接続を使用し、各 2 接続が US West (Oregon)US East (Northern Virginia) です:

これは、すべての re:Invent イベントをサポートしました:

ここに、実現に至った方法とお客様ご自身で実現させる方法の詳細について役立つビデオ資料を紹介します。

Jeff;

Amazon Chime – 統合されたコミュニケーションサービス

私のように職場での日々を過ごしている方々は、職場仲間とのコミュニケーションに多くの時間を費やしていることと思います。毎日のように私は全世界の人々と通信し、お互いに協力関係を築いています。オフィスでコンピューターの前に座っている人もいれば、移動しながらスマートフォン端末を使って接続し、コミュニケーションしている人もいます。私たちはフレンドリーにチャットを交わし、頻繁に会合し、ドキュメントや画像を送受信し、画面を共有しています。長年のあいだ、多くの「ビジネス生産性」ツールには何かが欠けていました。こういったツールの多くには、1 つか 2 つのコミュニケーションモデルや協力スタイルのみが用意され、妨げとなることがありました。ライセンスの入手とトレーニングのコスト、そして社内以外の外部との協力関係へのサポートの欠如は、事態を悪化させるだけでした。今このような状況を変化させる時です。

Amazon Chime の紹介
今日は Amazon Chime についてお話ししたいと思います。この新しい統合されたコミュニケーションサービスは、ミーティングをこれまで以上に容易にし、さらに効果的にするためにデザインされています。Amazon Chime では、ワンクリックで高品質なサウンドとビデオのミーティングを始めることができます。ミーティングを始めると、チャット、コンテンツの共有、画面の共有がスムーズなエクスペリエンスとして実現でき、コンピューターや MAC のデスクトップ、iOS デバイスと Android デバイスに対応しています。Amazon Chime は完全に管理されたサービスとなるため、事前の投資、ソフトウェアの導入や常時のメンテナンスが必要ではありません。ユーザーは Amazon Chime アプリをダウンロードするだけで、数分で利用を開始できます。Amazon Chime の主な機能のいくつかを簡単にご紹介しましょう。

オンタイムミーティング – ミーティングのためにダイアルインする必要はもうありません。ミーティングのための長い識別子や同じく長いパスワードを入力する必要はありません。その代わりに、Amazon Chime はミーティングが開始する際にアラートを発信し、ワンクリックあるいはタップによって参加する (または、遅れての参加を知らせる) ことができます。

ミーティング名簿 – 冗長な「誰が参加したか」についての質問の代わりに、Amazon Chime は参加者、遅れての参加者、欠席者の名簿を視覚的に提供します。また、広範囲にアクセスできる消音機能が提供され、ほかの参加者が入力していたり、犬が吠えていた場合などに便利です。

広範囲なアクセスAmazon Chime はモバイル使用に構築され、アプリによるコンピューターとモバイルデバイスで実行できます。さらに、Amazon Chime ではひとつのデバイスからミーティングに参加し、その後シームレスに別のデバイスに移動できます。

簡単な共有 – 協力関係を築くことが Amazon Chime の中心となる機能です。ミーティングの参加者は、好きな時に画面を共有でき、許可を得る必要はありません。Amazon Chime のチャットルームでは、参加者が協力して作業でき、共有の履歴が作成されて暗号形式で保存されます。

高音質な通話Amazon Chime は、高音質で雑音のない音声とはっきりとしてクリアな HD ビデオをすべてのユーザーデバイスとほぼ全種類の会議室ビデオシステムに提供します。

Amazon Chime の実証
Amazon Chime の主な機能をまず主画面から実行してみましょう。

ミーティングをクリックし、続いて Outlook カレンダーまたは Google カレンダーにミーティングスケジュールを予定します。

Outlook カレンダーは Amazon Chime アドインを使用しています。Outlook にスケジュールをクリックするとこのアドインのインストールが求められます。通常通りにこのイベントを設定するだけです。

Amazon Chime は、ミーティング開始時にお知らせを発信します。

回答するをクリックし、音声オプションを選択するだけです。

こうして、ミーティングが始まります。別の人を招待したり、画面や希望するすべてのウィンドウの共有、webcam の使用などができます。

ミーティング開催中に変更できる数々のオプションがあります。

Amazon Chime には常時、1 対 1 のチャットとチャットルームも用意されています。新しいチャットルームの作成方法を示します。

チャットルームの作成後、ブロガーを招待し、長期の継続する会話を実現できます。これまで通り、機能の一部のみを紹介しています !今すぐ始めるには、Amazon Chime サイト にアクセスして、使い始めてみてください。

Amazon Chime Editions
Amazon Chime では、3 種類がご利用いただけます。

  • Basic Editionは無料で利用できます。このエディションでは、ミーティングへの参加、1 対 1 のビデオ通信、Amazon Chime のすべてのチャット機能ができます。
  • Plus Edition は、1人のユーザーにつき毎月 2.50 ドルで利用できます。 このエディションでは、すべての電子メールドメインの管理、1 ユーザーにつき 1 GB のメッセージ保存、そして Active Directory への接続をサポートしています。
  • Pro Edition は、1人のユーザーにつき毎月 15.00 ドルで利用できます。 このエディションでは、100 人まで参加できるミーティングが可能です。

Amazon Chime Pro は、30 日間の無料お試し期間をクレジットカードなしで提供しています。30 日の期間経過後、無料の Amazon Chime Basic を引き続きお好きなだけ利用することも、Amazon Chime Pro を 1人のユーザーにつき毎月 15.00 ドルで購入することもできます。事前のお支払いは必要なく、いつでも登録の変更およびキャンセルができます。

今すぐ始められます
Amazon Chime は今すぐご利用いただきます。サインアップして、今すぐ使い始めましょう !

Jeff;

既存のAmazon EC2インスタンスにIAM Roleがアタッチできるようになりました

AWS Identity and Access Management(IAM) のロール を利用することで、Amazon EC2上で実行するアプリケーションは、AWSが自動的に作成、配布、およびローテーションする一時的なセキュリティ資格情報を利用することができます。一時的な資格情報を使用することは、IAMのベストプラクティスとなっており、インスタンスで長期間の鍵の管理する必要がなくなります。IAM Roles for EC2 (EC2のIAMロール)を使用することで、長期的なAWSアクセスキーを手動またはプログラムで管理する必要もなくなります。そして本日、既存のEC2インスタンスにIAMロールをアタッチすることが可能になり、アプリケーションはAWSによって提供される一時的なセキュリティ資格情報を使用できるようにするよう設定できるようになりました。 また、既存のEC2インスタンスに添付されているIAMロールを変更することも可能になります。

このブログ記事では、AWS CLIを使用して既存のEC2インスタンスにIAMロールをアタッチする方法をご紹介します。

ソリューションの概要
このブログ記事のソリューションでは、

1. IAMロールの作成

2. IAMロールなしで起動された既存のEC2インスタンスにIAMロールをアタッチ

3. アタッチされているIAMロールの付け替え

この記事では、新しく作成されたIAMロールを”YourNewRole“とします。このロールに関連付けられたインスタンス・プロファイルを”YourNewRole-Instance-Profile“、 既存のインスタンスを”YourInstanceId“とすることにます。 これら(赤字)はアカウントのリソース名に置き換えてください。
ここでは、AWSコマンドラインインターフェイス(CLI)の設定が完了しており、IAMロールを作成する権限、EC2 APIを呼び出す権限を持っていることを前提としています。

IAMロールの作成

注:既存のIAMロールをアタッチする場合は、このポストの「IAMロールなしで最初に起動された既存のEC2インスタンスにIAMロールをアタッチ」に進んでください。 またAWSマネージメントコンソールを使用してIAMロールを作成してから、同じセクションに進むこともできます。

AWS CLIからIAMロールを作成する前に、信頼ポリシーを作成する必要があります。 信頼ポリシーは、EC2などのAWSサービスがアプリケーションに代わってIAMロールを引き受けることを許可します。 信頼ポリシーを作成するには、下記のポリシーをコピーし、YourNewRole-Trust-Policy.jsonという名前で保存したテキストファイルに貼り付けます。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

信頼ポリシーを作成すると、既存のEC2インスタンスにアタッチできるIAMロールを作成する準備が整いました。

AWS CLIからIAMロールを作成

1. AWS CLIから、create-roleコマンドを呼び出し、信頼ポリシー YourNewRole-Trust-Policy.jsonに基づいきYourNewRoleというIAMロールを作成します。


$aws iam create-role --role-name YourNewRole --assume-role–policy-document file://YourNewRole-Trust-Policy.json

このIAMロールにアカウントのリソースへのアクセス権を付与するに、attach-role-policyコマンドを呼び出します。 この例では、アカウント内のすべてのAmazon S3バケットとバケット内のオブジェクトへの読み取り専用アクセスがアプリケーションに必要であると想定しています。 そのため、AWS管理ポリシーである、AmazonS3ReadOnlyAccess を使用することにします。 AWS管理ポリシーの詳細については、「管理ポリシーの使用」を参照してください。


$aws iam attach-role-policy --role-name YourNewRole --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

3. create-instance-profileコマンドを呼び出し、続いてadd-role-to-instance-profileコマンドを実行し、IAMインスタンスプロファイル”YourNewRole-Instance-Profile“を作成します。 インスタンスプロファイルにより、EC2はIAMロール”YourNewRole“をEC2インスタンスに渡すことができます。 詳細については、「インスタンスプロファイルの使用」を参照してください。


$aws iam create-instance-profile --instance-profile-name YourNewRole-Instance-Profile

$aws iam add-role-to-instance-profile --role-name YourNewRole --instance-profile-name YourNewRole-Instance-Profile

YourNewRole“というIAMロールが正常に作成されました。

IAMロールなしで起動された既存のEC2インスタンスにIAMロールをアタッチ

これで、YourNewRoleというIAMロールをEC2インスタンスYourInstanceIdにアタッチする準備が整いました。 ロールを添付するには:

associate-iam-instance-profileコマンドを呼び出して、新しく作成されたIAMロールの”YourNewRole-Instance-Profile“、”YourNewRole“のインスタンスプロファイルをEC2インスタンス”YourInstanceId“にアタッチします。


$aws ec2 associate-iam-instance-profile --instance-id YourInstanceId --iam-instance-profile Name=YourNewRole-Instance-Profile

2. describe-iam-instance-profile-associationコマンドを呼び出すことで、IAMロールがインスタンスにアタッチされていることを確認します。


$aws ec2 describe-iam-instance-profile-associations

3. これで、IAMロールを使用してAWSリソースにアクセスできるようになるため、インスタンスから長期間保管した鍵を削除するようにアプリケーションを更新できます。

アタッチされたIAMロールの付け替え

役割の要件が変更され、IAMロールを介してEC2インスタンスに付与された権限を変更する必要がある場合は、IAMロールに関連付けられたポリシーを置き換えることもできます。 ただし、このIAMロールを使用する他のEC2インスタンスのアクセス許可も変更されます。

代わりに、replace-iam-instance-profile-associationを呼び出して、現在アタッチされているIAMロール”YourNewRole“を別のIAMロールに置き換えることができます。 次の例では、”YourCurrentAssociation-id“を使用して現在のiam-instance-profile-associationインスタンスを示し、”YourReplacementRole-Instance-Profile“を使用して、そのインスタンスに関連付ける置換インスタンスプロファイルを示します 。 これらのプレースホルダーを、適切なassociation-idとアカウントのIAMインスタンスプロファイル名に置き換えてください。


$aws ec2 replace-iam-instance-profile-association --association-id YourCurrentAssociation-id --iam-instance-profile Name=YourReplacementRole-Instance-Profile

注:YourCurrentAssociation-idは、describe-iam-instance-profile-associationsを呼び出すことで取得できます。

最後に

このブログ記事で紹介しました通り、インスタンスを再起動することなく、既存のEC2インスタンスにIAMロールをアタッチすることで、アプリケーションがAWSによって提供される一時的なセキュリティ資格情報を使用できるようにすることができます。 ミッションクリティカルなワークロードを終了することなく、EC2インスタンスにアタッチされたIAMロールを置き換えることもできます。

この投稿に関するコメントがある場合は、下記の「コメント」セクションに投稿してください。 ご質問やご提案がありましたら、IAMフォーラムでコメント下さい。

– Apurv

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

Amazon Rekognition の更新 – 顔の推定年齢範囲

Amazon Rekognition は当社の人工知能サービスの 1 つです。Rekognition では、画像内の物体、シーン、および顔を検出できるほか、顔を検出して比較することができます。Rekognition は、バックグラウンドで詳細な神経ネットワークモデルを使用して、毎日数十億の画像を分析しています (詳細については、「Amazon Rekognition – ディープラーニングによる画像の検出と認識」を参照してください)。Amazon Rekognition は、画像で見つけた顔ごとに属性の配列を返します。本日、推定年齢範囲という新しい属性を追加します。この値は年数で表され、整数のペアとして返されます。年齢範囲は重なる場合があります。つまり、5 歳の顔の推定範囲は 4~6 歳になるが、6 歳の顔の推定範囲は 4~8 歳となる場合があります。この新しい属性を使用すれば、公共安全アプリケーションの増強、人口動態の収集、必要な期間を対象とした写真の整理が可能になります。この新機能を少し楽しむため (私はこの投稿を金曜日の午後に書いています)、自分の写真アーカイブを掘り起こして、Rekognition に私の年齢を推定させてみました。答えは次のようになりました。最初から始めましょう。この写真では、おそらく私は 2 歳でした。

この写真は、1966 年の春に私の祖母の家で撮られたものです。

私は 6 歳でした。Rekognition は私の年齢を 6~13 歳と推定しました。

2003 年の私の最初の公式な Amazon PR 写真では、私は 43 歳でした。

これには 17 年の範囲があり、私の実年齢はちょうどその中間でした。そして私の最新の (2015 年後半) の PR 写真 (55 歳) です。

これもまたかなり幅がありますが、私の年齢はちょうど中間です。一般的に、顔の実年齢は Rekognition で示された年齢の範囲に収まりますが、正確に中間になることを当てにしないでください。この機能は提供が開始されており、今すぐ使い始めることができます。

Jeff;

さらに多くの Amazon 風力および太陽光発電所が稼働!

風力発電所AWS の持続可能性の最前線でのすばらしいニュースで新年が始まりました。

2016 年末に 3 つの風力および太陽光プロジェクトが新たに稼働し、AWS データセンターの電力を賄う送電網にエネルギーを供給しています。簡単なまとめとして、re:Invent 2016 で、副社長兼特別エンジニアの James Hamilton がメインステージで、当社は 2016 年末までに 40% の再生可能エネルギーで電力を賄うという目標を超えたこと、さらに AWS チームとエネルギーパートナー様の取り組みにより、2017 年末までに 50% を賄うという新しい目標を設定したことを発表しました。2016 年初頭に本稼働を開始したインディアナ州ベントン群にある Amazon Wind Farm Fowler Ridge に加えて、3 つの新しいプロジェクトが 12 月にオンラインになりました。これには以下が含まれます。

Amazon Wind Farm US East – 当社はまず昨年 7 月に、Amazon Wind Farm US East に関して Avangrid Renewables (当時の名前は Iberdrola Renewables) との提携を発表し、風力発電所の建設を開始しました。これはノースカロライナ初となる商業規模の風力発電所です。また、アメリカ東南部においても最初の風力発電所の 1 つで、ノースカロライナのパスクォタンク群とパーキマンス郡にまたがるものです。

Amazon Solar Farm US East – AWS はバージニア州アッコマック郡に Amazon Solar Farm US East を建設するべく、2015 年 6 月に Community Energy と提携しました。この発電所は、年間約 170,000 メガワット時間の太陽エネルギーを発電します。現在、バージニアで 5 つの追加の太陽光発電所を建設中で、2017 年中にはオンラインになる見込みです。

Amazon Wind Farm US Central – 2015 年 11 月に、当社はオハイオ州ポールディング群に 100 メガワットの風力発電所を建設するべく、EDP Renewables と提携しました。この発電所は、年間約 320,000 メガワット時間の風力エネルギーを発電します。これに続き、Amazon Wind Farm US Central 2 (オハイオ) が 2017 年中に稼働する予定です。

これまで、AWS は合計 10 個の再生可能エネルギープロジェクトを発表し、これらの風力および太陽光発電所では、260 万メガワット時間のエネルギーを発電する見込みです。これは年間に米国の 240,000 世帯の電力を賄うために十分なエネルギーです。当社の長期的な目標である 100% の再生可能エネルギーという目標への道のりをフォローするには、ぜひ AWS & Sustainability ウェブページをご覧ください。

Amazon は、AWS グローバルインフラストラクチャへの電力供給に焦点を当てた持続性の取り組みを超えて、全社的にその他のクリーンエネルギー活動についてもいくつか調査中です。その他のプロジェクトには、Amazon Wind Farm Texas (テキサス州スカリー郡の 253MW の風力発電所、グリーンルーフ) や、シアトルの Amazon オフィスの暖房用に再生エネルギーを使用する District Energy Project などがあります。

Amazon の持続性に関する取り組みの詳細については、www.amazon.com/sustainability を参照してください。

SAP HANA on AWSの展開 – どのような選択肢が?

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

SAPアプリケーションをSAP HANAプラットフォーム上に移行、または新規で構築する予定がありますか?もしそうであれば、AWSがSAP HANAのワークロードを実行するためにどのような選択肢を提供しているか知りたいのでは、と思っています。本ブログ記事では、SAP HANAに必要となる主なインフラストラクチャ・コンポーネントおよびAWS上にSAP HANA仮想アプライアンスを構築するためのビルディング・ブロックについて説明します。本記事により、展開方法について深くご理解いただけると幸いです。本記事は、ブログシリーズとして、SAP on AWSに関する様々な情報を公開する最初の記事ですので、頻繁に確認していただければと思います。

SAP HANA Tailored Data Center Integration (TDI) モデルに準拠している場合、メモリー、コンピュート、ストレージ、そしてネットワークの4つがSAP HANAに必要となる主要なインフラストラクチャ・コンポーネントになります。これらの中で、メモリーがデータサイズに依存する唯一の変数となっています。コンピュート、ストレージ、ネットワーク要件はメモリーサイズから算出されるか、あらかじめ定義されています。例えば、メモリーサイズに基づいたコンピュートに必要なコア数の決定には、SAP社が設定した標準的なコアとメモリー比率の要件があります。ストレージについては、メモリーサイズに関係なく、SAP HANA Hardware Configuration Check Tool (HWCCT) ガイドに記載されているように、異なるブロックサイズやその他のKPIにおける特定のスループット要件を満たす必要があります。 最後にネットワークですが、特にスケールアウト構成において、メモリーサイズに関係なく、SAP HANAのノード間で最小9.5 Gbpsのスループットを実現する必要があります。

ここ数年、AWSはSAP社と密に連携して、AWSプラットフォーム上でSAP HANAのワークロードを実行するためのコンピュートおよびストレージ構成の認証を取得しています。どのように我々はこれを実現したのでしょうか。その答えは、 AWSがAmazon Elastic Compute Cloud (Amazon EC2)のインスタンスを様々なメモリーサイズで設計し、コンピュートのための適切なコアとメモリー比率を含むSAP HANAの厳しい性能要件を満たすことです。加えて、Amazon Elastic Block Store (Amazon EBS)は多くの場合にTDIモデルのストレージKPIを満たしています。そしてEC2インスタンスのネットワーク帯域幅は、スケールアウト構成のノード間通信で必要な9.5 Gbpsを満たしています。

それではこれらのビルディング・ブロックと構成オプションについて詳細をみていきましょう。

メモリーとコンピュート

AWSでは様々なワークロードに対応できるよう、いくつかのEC2インスタンスのタイプをご用意しています。 メモリー最適化のR3とR4インスタンス、そして大容量メモリー最適化のX1インスタンスといったSAP HANAのワークロードに最適な2つのEC2インスタンスのタイプがあります。これらのインスタンスファミリーは、SAP HANAのようなインメモリーワークロード専用に設計されています。このインスタンスタイプとインスタンスファミリーにはSAP HANAのワークロードを実行するための様々なコンピュートオプションがあります。OLAP(online analytical processing)用途、例えばSAP Business Warehouse on HANAやSAP BW/4HANA、データマートなどにおいて、SAP社の完全サポート対象として244GiBから2TBまで垂直方向に、また最大14TBまで水平方向にスケールすることができます。AWSラボでは、最大25ノードの展開、つまり合計50 TBのRAMのテストに成功していることもご認識ください。OLTP(online transaction processing)用途、例えばSAP Business Suite on HANA、SAP S4/HANA、SAP CRMなどにおいては、今日現在で244GiBから2TBまで垂直にスケールすることが可能です。最新のCPU世代でAWSが新しいインスタンスタイプを提供し続けるにあたり、弊社はSAPと密に連携して、それらのインスタンスタイプでもSAP HANAのワークロードのために認証を取得していくつもりです。SAP HANAワークロードの本稼働環境で使用できる認定EC2インスタンスタイプをすべて表示するには、SAP社が認定およびサポートするSAP HANAハードウェアディレクトリーのCertified IaaS Platformsのページを参照してください。特定のインスタンスファミリーでは、非本稼働用途においてr3.2xlargeやr4.2xlargeといった小さいインスタンスサイズを使用することでTCOを削減することもできます。クラウドネイティブなインスタンスにより、SAP HANAのメモリー利用量に合わせて64GiBから2TBに増やすことを、またはその逆に減らすことも、数分でシームレスに変更できる柔軟性があることも覚えておいてください。SAP HANAの導入において、これまでにはない俊敏性がもたらされます。

次の表と図は、これまで説明してきたメモリーとコンピュートの選択肢を整理したものです。

HANA_on_AWS

本稼働ワークロードの選択肢
インスタンスタイプ メモリー (GiB) vCPU SAPS
x1.32xlarge 1,952 128 131,500
x1.16xlarge 976 64 65,750
r4.16xlarge 488 64 76,400
r3.8xlarge 244 32 31,920
非本稼働ワークロードの選択肢
インスタンスタイプ メモリー (GiB) vCPU SAPS
r4.8xlarge 244 32 38,200
r4.4xlarge 122 16 19,100
r4.2xlarge 61 8 9,550
r3.4xlarge 122 16 15,960
r3.2xlarge 61 8 7,980
 — SAP Business One, version for SAP HANAについてはこれ以外のインスタンスとメモリーサイズが利用可能です。このトピックは別のブログを参照してください。

ストレージ

AWSでは、SAP HANAの永続ブロックストレージに複数のオプションを用意しています。性能重視のデータやログボリューム用に2つのSSD-backed EBSボリュームタイプ(gp2io1)があり、またSAP HANAバックアップ用にコスト最適化および高いスループットのHDD-backed EBSボリューム(st1)があります。

  • 汎用SSD (gp2) ボリュームタイプでは、ボリュームあたり最大160MB/sのスループットを実現できます。TDIモデルの要件である最大400MB/sのスループットを達成するためには、SAP HANAのデータとログファイル用に3つのボリュームをストライピングする必要があります。
  • プロビジョンドIOPS SSD (io1) ボリュームでは、ボリュームあたり最大320MB/sのスループットを提供し、スループット要件を満たすには少なくとも2つのボリュームをストライピングする必要があります。
  • スループット最適化HDD (st1) ボリュームでは、大きなブロックサイズでのシーケンシャルな読み書きで最大500MB/sのスループットを実現できます。そのため、st1はSAP HANAバックアップの保存先に理想的な候補となります。

重要な点の1つとして、それぞれのEBSボリュームがAWSのアベイラビリティゾーン内で自動的に複製されることで、障害から保護され、高い可用性と耐久性を提供することがあります。 これにより、性能を最大限に引き出すためにオペレーティングシステムレベルでRAID 0アレイが構成でき、一方でボリュームの保護(RAID 10またはRAID 5)は心配する必要がなくなります。

ネットワーク

SAP HANAのネットワーク性能は、特にスケールアウト構成において重要な要素になります。すべてのEC2インスタンスは一定のネットワーク帯域幅を提供しており、X1のような最新のインスタンスファミリーでは、SAP HANAの要求に合わせて最大20 Gbpsのネットワーク帯域幅を提供します。さらに多くのインスタンスでは、Amazon EBSストレージ接続のための独立したネットワーク帯域幅を持っています。例えば、もっとも大きいX1インスタンス(x1.32xlarge)では、20 Gbpsのネットワーク帯域幅と10 Gbpsの専用ストレージ帯域幅を持ちます。 R4インスタンス(r4.16xlarge)では、20 Gbpsのネットワーク帯域幅と12 Gbpsの専用ストレージ帯域幅を持ちます。 以下はSAP認定インスタンスのネットワーク機能の簡単な概要になります。

本稼働ワークロードの選択肢
インスタンスタイプ ネットワーク帯域幅 (Gbps) EBS専用の帯域幅 (Gbps)
x1.32xlarge 20 10
x1.16xlarge 10 5
r4.16xlarge 20 12
r3.8xlarge 10*

* ネットワークとストレージのトラフィックは同じ10 Gbps ネットワークインターフェイスを共有

オペレーティングシステム(OS)

SAP社では、SUSE Linux Enterprise Server(SLES) またはRed Hat Enterprise Linux(RHEL)上でのSAP HANAの実行をサポートしています。どちらのOSディストリビューションもAWS上でサポートされます。さらに、お客様はAWS Marketplaceで提供されるSUSEまたはレッドハットのSAP HANA固有イメージを使って容易に開始することができます。また、お客様自身のOSサブスクリプションを持ち込むことも可能です。SAP HANA on AWSのOSに関する選択肢の詳細については、今後のブログ記事をご期待ください。

すべてをまとめて構築

“AWSがTDI同様にSAP HANAのビルディング・ブロックを提供するのは素晴らしいことですが、AWS上でこれらのコンポーネントをまとめてSAPの要件を満たすシステムを構築するにはどうすればよいですか?”と思うかもしれません。AWSのお客様からも数年前にこの質問を受けており、AWS Quick Start for SAP HANAを開発しました。 このクイックスタートでは、AWS CloudFormationテンプレート(Infrastructure as Code)とカスタムスクリプトを利用して、ストレージやネットワークを含むAWSインフラストラクチャ・コンポーネントの展開を支援します。クイックスタートは、SAP HANAインストールに必要となるオペレーティングシステムの設定も行います。また、お客様自身のSAP HANAソフトウェアとライセンスを持ち込むことで、SAP HANAソフトウェアのインストールもできます。クイックスタートは、世界中の多くのAWSリージョンで使用できるセルフサービスのツールです。SAP HANAシステムのインフラストラクチャの展開は、シングルノードであるかスケールアウトシステムであるかに関係なく、一貫して予測可能で繰り返し可能な方法で、1時間未満で提供されます。SAP HANAクイックスタートの実行は、AWS re:Invent 2016 カンファレンスにてSAP社との共同講演で実演した録画されたデモをご覧ください。

SAP HANAの構築には、AWSクイックスタートを利用したインフラストラクチャの展開を強く推奨します。ただし、クイックスタートを使用できない場合(たとえば、独自のOSイメージを使用する場合など)には、SAP HANA環境を手動で構築し、ビルディング・ブロックを自分で配置することができます。ストレージとインスタンスタイプについては必ずrecommendations in the Quick Start guideに従ってください。この特定の目的のために、SAP HANA on AWS – Manual Deployment Guideでステップ・バイ・ステップの手順も提供しています。(RHELを含む最新OSバージョンの手順を含む本ガイドはすぐに更新される予定です。)

バックアップとリカバリー

信頼性の高い方法でSAP HANAデータベースをバックアップおよびリストアする機能は、ビジネスデータを保護する上で非常に重要です。SAP HANA純正のツールを使用してデータベースをEBSボリュームにバックアップし、最終的にバックアップされたファイルをAmazon Simple Storage Service (Amazon S3)に移行することで、耐久性を高めることができます。Amazon S3は、スケーラビリティと耐久性に優れたオブジェクトストレージのサービスです。Amazon S3のオブジェクトは、リージョン内の複数の施設に重複して格納され、99.999999999の耐久性を実現します。Commvault、EMC NetWorker、Veritas NetBackup、IBM Spectrum Protect(Tivoli Storage Manager)などのエンタープライズクラスのバックアップソリューションを選択することもできます。これらのソリューションは、Amazon S3およびSAP HANA Backintインタフェースと統合されています。これらのパートナーソリューションは、SAP HANAデータベースをAmazon S3に直接バックアップし、エンタープライズクラスのソフトウェアを使用したバックアップ・リカバリーの管理に役立ちます。

高可用性(HA)と災害対策(DR)

HAとDRは、SAP HANA上で実行されるビジネスクリティカルなアプリケーションにとって重要です。AWSは、アップタイムとリカバリーの要件(RTO / RPO)に応じたHAとDRソリューションを構成できるよう、世界中の複数のAWSリージョンと各AWSリージョン内の複数のアベイラビリティゾーンを含むいくつかのビルディング・ブロックを提供しています。コスト最適化ソリューションまたはダウンタイム最適化ソリューションのどちらを探している場合でも、SAP HANA HA/DRアーキテクチャにいくつかの独自オプションを用意しています — これらの詳細については、SAP HANA HA/DR guideを参照してください。今後のブログ記事でこのトピックについて詳しく説明する予定です。

移行

実際の移行には、SAP標準のツールセットとして提供されるSAP Software Provisioning Manager(SWPM)やDatabase Migration Option(DMO) of the Software Update Manager(SUM)、または3rdパーティーの移行ツールを使って、任意のデータベースで実行されているSAPアプリケーションをSAP HANA on AWSに移行できます。 SAPのAWSへの移行プロセスは、一般的なオンプレミスの移行シナリオとほぼ変わりません。オンプレミスのシナリオでは、通常、同じデータセンター内にソースシステムとターゲットシステムが存在します。AWSに移行する場合の唯一の違いは、ターゲットシステムがAWS上に存在することです。そのため、AWSを自社のデータセンターの拡張と考えることができます。また、移行中に、オンプレミスのデータセンターでエクスポートされたデータをAWSに転送するための様々なオプションもあります。これらの選択肢の理解をより深めるために、Migrating SAP HANA Systems to X1 Instances on AWSを参照することをお勧めします。

その他の検討事項として、運用、サイジング、スケーリング、Amazon CloudWatchのようなAWSサービスとの統合、ビッグデータソリューションなどがあります。これらは今後のブログ記事で詳細を取り上げる予定です。それまでの間に、AWS Quick Start for SAP HANAを使ってSAP HANA on AWSを開始してみてはいかがでしょうか。AWS上で実行されるSAPワークロードの詳細については、SAP on AWS websiteのホワイトペーパーもご覧ください。

最後に、現在利用可能なシステムサイズを超えて拡張するシステムが必要な場合は、当社までご連絡ください。 私たちはお客様の要件について話し合い、その実装に関してご協力いただけることを嬉しく思います。

– Sabari

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

タスクIAMロールとパラメータストアを利用したAmazon ECSアプリケーションの秘密情報管理

同僚のStas Vonholskyが、Amazon ECSアプリケーションの秘密情報管理に関する素晴らしいブログを寄稿してくれました。

—–

コンテナ化されたアプリケーションとマイクロサービス指向のアーキテクチャが普及するにつれて、アプリケーションデータベースにアクセスするためのパスワードなどの秘密情報を管理することは、より困難かつ重要になっています。

いくつか課題の例を挙げます:

  • dev、test、prodなどのさまざまなアクセスパターンをコンテナ環境全体でサポートしたい
  • ホストレベルではなくコンテナ/アプリケーションレベルで秘密情報へのアクセスを隔離したい
  • サービスとしても、他サービスのクライアントとしても、アクセスが必要である疎結合なサービスが複数存在する

この記事では、Amazon ECS上で動作するコンテナアプリケーションの秘密情報管理をサポートする、新しくリリースされた機能に焦点を当てています。同僚のMatthew McCleanもAWSセキュリティブログに、S3とDockerを使用してECSベースのアプリケーションの秘密情報を管理する方法についての素晴らしい記事を公開しています。この記事では、コンテナパラメータ変数を使って秘密情報を受け渡し/保存する際の制限について説明しています。

多くの秘密情報管理ツールは、次のような機能を提供しています。

  • 高セキュアなストレージシステム
  • 集中管理機能
  • セキュアな認証と認証メカニズム
  • 鍵管理および暗号化プロバイダとの統合
  • アクセスのための安全な導入メカニズム
  • 監査
  • 秘密情報のローテーションと失効

Amazon EC2 Systems Manager パラメータストア

パラメータストアは、Amazon EC2 Systems Managerの1機能です。秘密情報のための集中化/暗号化されたデータストアを提供し、Run CommandやステートマネージャーなどのSystems Managerの他の機能と組み合わせることで多くの利点をもたらします。このサービスはフルマネージドで、高い可用性・セキュリティを持っています。

System Manager API、AWS CLI、およびAWS SDKを使用してパラメータストアにアクセスできるため、汎用の秘密情報管理ストアとして使用することができます。秘密情報は簡単にローテートしたり取り消したりすることができます。パラメータストアはAWS Key Management Service (KMS)と統合されているため、デフォルトまたはカスタムのKMSキーを使用して特定のパラメータを暗号化できます。 KMSキーをインポートすることで、独自のキーを使用して機密データを暗号化することも可能です。

パラメータストアへのアクセスはIAMポリシーによって実現にされ、リソースレベルのアクセス許可をサポートします。特定のパラメータまたは名前空間にアクセス権を持つIAMポリシーを使用して、これらのパラメータへのアクセスを制限することができます。 CloudTrailログを有効にすると、パラメータへのアクセスを記録することも可能です。

Amazon S3も上記の機能の多くを持つので、集約秘密情報ストアの実装にも使用できますが、パラメータストアにはさらに次のような利点があります。

  • アプリケーションライフサイクルのさまざまなステージをサポートするためのネームスペースを簡単に作成できる
  • インスタンスまたはコンテナからKMSキーにアクセスし、ローカルメモリ内で復号化を実行することで、アプリケーションからパラメータの暗号化を抽象化するKMS統合機能を提供する
  • パラメータの変更履歴を保管できる
  • 他の多くのアプリケーションで使用されるS3とは別に制御できる
  • 複数システムを実装する際のオーバーヘッドを削減する構成情報ストアとなる
  • 使用料がかからない

注:本記事の公開時点では、Systems ManagerはVPCプライベートエンドポイント機能をサポートしていません。プライベートVPCからのパラメータストアエンドポイントへのより厳密なアクセスを強制するには、限られたIPアドレスセットからのみにアクセスを制限するIAMポリシーConditionとともに、Elastic IPアドレスを持つNATゲートウェイを使用します。

タスクIAMロール

Amazon ECSタスク用のIAMロールを使用すると、タスク内のコンテナが使用するIAMロールを指定することができます。 AWSサービスと対話するアプリケーションは、AWSクレデンシャルでAPIリクエストに署名する必要があります。ECSタスクIAMロールは、Amazon EC2インスタンスプロファイルがEC2インスタンスにクレデンシャルを提供するのと同じように、コンテナアプリケーションのクレデンシャルを管理する方法を提供します。

AWSクレデンシャルを作成してコンテナに配布したり、EC2インスタンスロールを使用する代わりに、IAMロールをECSタスク定義またはRunTask API操作に関連付けることができます。詳細については、IAM Roles for Tasksを参照してください。

タスク用のIAMロールを利用することで、集約パラメータストアを使用してアプリケーションまたはコンテナを安全に導入および認証することができます。秘密情報管理機能へのアクセスには、次のような機能が含まれている必要があります。

  • 使用されたクレデンシャルのTTL制限
  • きめ細やかな認可ポリシー
  • リクエストを追跡するためのIDのログ保存
  • デプロイされたコンテナまたはタスクと関連するアクセス権との間をマッピングできるスケジューラの統合サポート

タスクIAMロールは、ロールが定義されているコンテナ内からのみロールクレデンシャルにアクセスできるため、これらのユースケースをうまくサポートします。このロールは一時的なクレデンシャルを提供し、これらは自動的にローテーションされます。IAMポリシーは、送信元インスタンス、送信元IPアドレス、時刻などのオプション条件をサポートされています。

ソースとなるIAMロールは、一意のAmazonリソースネームに基いてCloudTrailログで識別でき、アクセス許可はいつでもIAM APIまたはコンソールで取り消すことができます。パラメータストアはリソースレベルの権限をサポートするため、特定のキーと名前空間へのアクセスを制限するポリシーを作成できます。

動的な環境の関連付け

多くの場合、環境を移動する際にもコンテナイメージは変更されず、イミュータブルなデプロイメントと結果再現性を保証します。変更されうるものは構成情報、この文脈では具体的には秘密情報です。たとえば、データベースとそのパスワードは、ステージング環境と本番環境で異なる場合があります。正しい秘密情報を取得するためにどのようにアプリケーションを指定すればよいでしょうか?

1つのオプションは、環境変数として環境タイプをコンテナに渡すことです。次に、アプリケーションは環境タイプ(prod、testなど)を相対キーパスに連結し、関連する秘密情報を取得します。ほとんどの場合、この方法では多数の独立したECSタスク定義が生まれてしまいます。

IAMロールは、“environment type”などの単一のCloudFormationパラメータで、パラメータストア、KMSキーおよび環境プロパティへのアクセスを提供します。

このアプローチを利用することで、一般的なCloudFormationテンプレートに基づいた単一のタスク定義をサポートすることができます。

ウォークスルー:タスクIAMロールを使用してパラメータストアリソースに安全にアクセスする

このウォークスルーはNorth Virginiaリージョン(us-east-1)向けに構成されています。同じリージョンを使って試すことをお勧めします。

Step 1: KMSキーとパラメータを作成する

最初に、既定のセキュリティポリシーを使用して、いくつかのパラメータを暗号化するためのKMSキーを作成します。

  • prod-app1  –  app1の秘密情報を暗号化するために使用されます
  • license-key  – ライセンス関連の秘密情報を暗号化するために使用されます
aws kms create-key --description prod-app1 --region us-east-1
aws kms create-key --description license-code --region us-east-1

両方のコマンドの出力のKeyIdプロパティを確認してください。ウォークスルー全体でKMSキーを識別するために使用します。

次のコマンドで、パラメータストアに3つのパラメータを作成します。

  • prod.app1.db-pass(prod-app1 KMSキーで暗号化)
  • general.license-code(license-key KMSキーで暗号化)
  • prod.app2.user-name(暗号化されていない標準文字列として保存)
aws ssm put-parameter --name prod.app1.db-pass --value "AAAAAAAAAAA" --type SecureString --key-id "<key-id-for-prod-app1-key>" --region us-east-1
aws ssm put-parameter --name general.license-code --value "CCCCCCCCCCC" --type SecureString --key-id "<key-id-for-license-code-key>" --region us-east-1
aws ssm put-parameter --name prod.app2.user-name --value "BBBBBBBBBBB" --type String --region us-east-1

Step 2: IAMロールとポリシーを作成する

ここで、後で作成するECSタスクと関連付けるロールとIAMポリシーを作成します。

IAMロールの信頼ポリシーは、ecs-tasksエンティティがロールを引き受けることを許可する必要があります。

{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Sid": "",
       "Effect": "Allow",
       "Principal": {
         "Service": "ecs-tasks.amazonaws.com"
       },
       "Action": "sts:AssumeRole"
     }
   ]
 }

上記のポリシーを、ecs-tasks-trust-policy.jsonという名前のファイルとしてローカルディレクトリに保存します。

aws iam create-role --role-name prod-app1 --assume-role-policy-document file://ecs-tasks-trust-policy.json

次のポリシーはロールにアタッチされ、後でapp1コンテナに関連付けられます。 prod.app1.*という名前空間パラメータおよびライセンスコードパラメータへのアクセスと、prod.app1.db-passパラメータを復号化するために必要な暗号化キーへのアクセスが許可されています。名前空間リソースのパーミッション構造は、さまざまな階層を構築するのに便利です(環境、アプリケーションなどに基づいています)。

次のポリシーの<key-id-for-prod-app1-key>を関連するKMSキーのキーIDに、<account-id>をあなたのアカウントIDに置き換えてください。

{
     "Version": "2012-10-17",
     "Statement": [
         {
             "Effect": "Allow",
             "Action": [
                 "ssm:DescribeParameters"
             ],
             "Resource": "*"
         },
         {
             "Sid": "Stmt1482841904000",
             "Effect": "Allow",
             "Action": [
                 "ssm:GetParameters"
             ],
             "Resource": [
                 "arn:aws:ssm:us-east-1:<account-id>:parameter/prod.app1.*",
                 "arn:aws:ssm:us-east-1:<account-id>:parameter/general.license-code"
             ]
         },
         {
             "Sid": "Stmt1482841948000",
             "Effect": "Allow",
             "Action": [
                 "kms:Decrypt"
             ],
             "Resource": [
                 "arn:aws:kms:us-east-1:<account-id>:key/<key-id-for-prod-app1-key>"
             ]
         }
     ]
 }

上記のポリシーを、app1-secret-access.jsonという名前のファイルとしてローカルディレクトリに保存します。

aws iam create-policy --policy-name prod-app1 --policy-document file://app1-secret-access.json

次のコマンドの<account-id>はあなたのアカウントIDに置き換えてください:

aws iam attach-role-policy --role-name prod-app1 --policy-arn "arn:aws:iam::<account-id>:policy/prod-app1"

Step 3:S3バケットにテストスクリプトを追加する

以下のスクリプトファイルを作成し、access-test.shという名前をつけてアカウントのS3バケットに追加します。オブジェクトがパブリックアクセス可能であることを確認し、オブジェクトリンクを書き留めておいてください。

例えば、https://s3-eu-west-1.amazonaws.com/my-new-blog-bucket/access-test.shのようになります。

#!/bin/bash
#This is simple bash script that is used to test access to the EC2 Parameter store.
# Install the AWS CLI
apt-get -y install python2.7 curl
curl -O https://bootstrap.pypa.io/get-pip.py
python2.7 get-pip.py
pip install awscli
# Getting region
EC2_AVAIL_ZONE=`curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone`
EC2_REGION="`echo \"$EC2_AVAIL_ZONE\" | sed -e 's:\([0-9][0-9]*\)[a-z]*\$:\\1:'`"
# Trying to retrieve parameters from the EC2 Parameter Store
APP1_WITH_ENCRYPTION=`aws ssm get-parameters --names prod.app1.db-pass --with-decryption --region $EC2_REGION --output text 2>&1`
APP1_WITHOUT_ENCRYPTION=`aws ssm get-parameters --names prod.app1.db-pass --no-with-decryption --region $EC2_REGION --output text 2>&1`
LICENSE_WITH_ENCRYPTION=`aws ssm get-parameters --names general.license-code --with-decryption --region $EC2_REGION --output text 2>&1`
LICENSE_WITHOUT_ENCRYPTION=`aws ssm get-parameters --names general.license-code --no-with-decryption --region $EC2_REGION --output text 2>&1`
APP2_WITHOUT_ENCRYPTION=`aws ssm get-parameters --names prod.app2.user-name --no-with-decryption --region $EC2_REGION --output text 2>&1`
# The nginx server is started after the script is invoked, preparing folder for HTML.
if [ ! -d /usr/share/nginx/html/ ]; then
mkdir -p /usr/share/nginx/html/;
fi
chmod 755 /usr/share/nginx/html/
# Creating an HTML file to be accessed at http://<public-instance-DNS-name>/ecs.html
cat > /usr/share/nginx/html/ecs.html <<EOF
<!DOCTYPE html>
<html>
<head>
<title>App1</title>
<style>
body {padding: 20px;margin: 0 auto;font-family: Tahoma, Verdana, Arial, sans-serif;}
code {white-space: pre-wrap;}
result {background: hsl(220, 80%, 90%);}
</style>
</head>
<body>
<h1>Hi there!</h1>
<p style="padding-bottom: 0.8cm;">Following are the results of different access attempts as expirienced by "App1".</p>
<p><b>Access to prod.app1.db-pass:</b><br/>
<pre><code>aws ssm get-parameters --names prod.app1.db-pass --with-decryption</code><br/>
<code><result>$APP1_WITH_ENCRYPTION</result></code><br/>
<code>aws ssm get-parameters --names prod.app1.db-pass --no-with-decryption</code><br/>
<code><result>$APP1_WITHOUT_ENCRYPTION</result></code></pre><br/>
</p>
<p><b>Access to general.license-code:</b><br/>
<pre><code>aws ssm get-parameters --names general.license-code --with-decryption</code><br/>
<code><result>$LICENSE_WITH_ENCRYPTION</result></code><br/>
<code>aws ssm get-parameters --names general.license-code --no-with-decryption</code><br/>
<code><result>$LICENSE_WITHOUT_ENCRYPTION</result></code></pre><br/>
</p>
<p><b>Access to prod.app2.user-name:</b><br/>
<pre><code>aws ssm get-parameters --names prod.app2.user-name --no-with-decryption</code><br/>
<code><result>$APP2_WITHOUT_ENCRYPTION</result></code><br/>
</p>
<p><em>Thanks for visiting</em></p>
</body>
</html>
EOF

Step 4:テストクラスタを作成する

最新のECS AMIとECSエージェントを持つ新しいECSテストクラスタを作成することをお勧めします。次のフィールド値を使用します。

  • クラスタ名:access-test
  • EC2インスタンスタイプ:t2.micro
  • インスタンス数:1
  • キーペア:インスタンスにSSHして実行中のコンテナを操作したい場合を除き、EC2キーペアは必要ありません。
  • VPC:デフォルトVPCを選択します。わからない場合は、Amazon VPCコンソールで172.31.0.0/16のIPレンジのVPCのIDを探してください。
  • サブネット:デフォルトVPC内のサブネットを選択します。
  • セキュリティグループ:CIDRブロック0.0.0.0/0からのポート80のインバウンドアクセス用の新しいセキュリティグループを作成します。

他のフィールドはデフォルト設定のままにします。

パブリックNGINXコンテナとapp1用に作成したロールに依存するシンプルなタスク定義を作成します。利用可能なコンテナリソースやポートマッピングなどのプロパティを指定します。commandオプションは、コンテナにテストスクリプトのダウンロードおよび実行に利用されます。このテストスクリプトはAWS CLIをコンテナにインストールし、いくつかのget-parameterコマンドを実行し、結果を含むHTMLファイルを作成します。

次のコマンドの<account-id>はアカウントIDに、<your-S3-URI>はStep 3で作成したS3オブジェクトのリンクに置き換えてください。

aws ecs register-task-definition --family access-test --task-role-arn "arn:aws:iam::<account-id>:role/prod-app1" --container-definitions name="access-test",image="nginx",portMappings="[{containerPort=80,hostPort=80,protocol=tcp}]",readonlyRootFilesystem=false,cpu=512,memory=490,essential=true,entryPoint="sh,-c",command="\"/bin/sh -c \\\"apt-get update ; apt-get -y install curl ; curl -O <your-S3-URI> ; chmod +x access-test.sh ; ./access-test.sh ; nginx -g 'daemon off;'\\\"\"" --region us-east-1
aws ecs run-task --cluster access-test --task-definition access-test --count 1 --region us-east-1

アクセスの確認

タスクが実行状態になったら、インスタンスのパブリックDNS名を確認し、次のページに移動します。

http://<ec2-instance-public-DNS-name>/ecs.html

コンテナからアクセステストを実行した結果が表示されます。

テスト結果がすぐに表示されない場合は、数秒待ってからページを更新してください。

ポート80のインバウンドトラフィックがインスタンスにアタッチされたセキュリティグループで許可されていることを確認してください。

静的HTMLページに表示される結果は、コンテナから次のコマンドを実行する場合と同じものになります。

prod.app1.key1

aws ssm get-parameters --names prod.app1.db-pass --with-decryption --region us-east-1
aws ssm get-parameters --names prod.app1.db-pass --no-with-decryption --region us-east-1

必要なKMSキーとパラメータにアクセスできるポリシーがあるため、この2つのコマンドはどちらも実行可能なはずです。

general.license-code

aws ssm get-parameters --names general.license-code --no-with-decryption --region us-east-1
aws ssm get-parameters --names general.license-code --with-decryption --region us-east-1

“no-with-decryption”パラメータを持つ最初のコマンドだけが動作するはずです。指定したポリシーでは、パラメータストアのパラメータへのアクセスは許可されていますが、KMSキーへのアクセスは許可されていません。 2番目のコマンドは、アクセス拒否エラーで失敗するはずです。

prod.app2.user-name

aws ssm get-parameters --names prod.app2.user-name –no-with-decryption --region us-east-1

prod.app2の名前空間に関連付けられている権限がないため、このコマンドはアクセス拒否エラーで失敗するはずです。

仕上げ

料金が発生しないように、すべてのリソース(KMSキーやEC2インスタンスなど)を削除することを忘れないでください。

まとめ

集約秘密情報管理は、コンテナ化された環境のセキュリティにとって重要な機能です。

ユーザーは、パラメータストアとタスクIAMロールを使用することで、アプリケーションが必要なキーのみにアクセスすることができるKMSキーと統合されたアクセスレイヤーおよび集約秘密情報ストアを構築することができます。

秘密情報管理レイヤはパラメータストア、Amazon S3、Amazon DynamoDB、またはVaultやKeyWhizなど、どんなソリューションで実装されている場合でも、秘密情報の管理・アクセスのプロセスに不可欠なものです。

(翻訳はSA千葉が担当しました。原文はこちらです。)

暗号化を用いたセキュアな Amazon EMR

ここ数年で、エンタープライズ企業において Apache hadoop エコシステムを用いて、センシティブであったり、きわめて秘匿性が高かったりするデータを扱う、重要なワークロードを走らせるケースが非常に増えてきています。そうしたワークロードの特性により、エンタープライズ企業ではしっかりした組織/業界全体のポリシーや、規制、コンプライアンスのルールを定めています。それに基づいて、機密データの保護や、権限のない人がアクセスできないようにすることが求められています。

こうしたポリシーにおいては一般的に、データストアに保存されているとき、そしてデータを転送しているときの両方で暗号化が要求されます。Amazon EMR では “セキュリティ設定” を使うことで、AWSキーマネジメントサービス (KMS) からお客様自身が用意した暗号化要素まで、さまざまな暗号化キーや証明書を指定することができます。

暗号化設定についてのセキュリティ設定を作り、クラスター作成の際に、その設定を当てることができます。セキィリティ設定を一度作っておくことで、いくつものクラスターにその設定を簡単に適用可能です。

o_Amazon_EMR_Encryption_1_

この投稿ではEMRのセキュリティ設定による、複数段階のデータ暗号化のセットアッププロセスを概観します。暗号化について深く見ていく前に、データ暗号化が必要な状況を整理しましょう。

保存時のデータ

  • Amazon S3にあるデータ – EMRのS3クライアントサイド暗号化
  • ディスク上のデータ – Linux Unified Key System (LUKS) による、Amazon EC2 のインスタンスストアボリューム(ブートボリュームを除く)、クラスターインスタンスにアタッチされた Amazon EBS
    ボリューム

転送中のデータ

  • EMRからS3に転送中のデータ、またはその逆 – EMR の S3 クライアントサイド暗号化
  • クラスター内のノード間で転送中のデータ – Secure Socket Layer (SSL) による MapReduce の in-transit 暗号化と、Simple Authentication と Security Layer (SASL) による Spark の shuffle 暗号化
  • ディスクに溢れたデータ、またはシャッフルフェーズの最中にキャッシュされたデータ – Spark の shuffle 暗号化、またはLUKS 暗号化

暗号化の手順

この投稿のために、転送中、保存時の暗号化に使うためのセキュリティ設定を作りましょう。

  • EMRやS3にあるデータに対して、LUKS 暗号化やS3 クライアントサイド暗号化のための KMS キー
  • MapReduce のshuffle 暗号化で使用する SSL 証明書
  • EMR クラスタが立ち上げられる環境。プライベートサブベットで EMR を立ち上げて、S3 からデータを取得するための VPC エンドポイントを設定します
  • EMR セキュリティ設定

この手順で説明するすべてのスクリプトとコードスニペットは、aws-blog-emrencryption Github レポジトリから取得できます。

KMS キーの生成

この手順では鍵管理について、データやディスクを暗号化するために使用する暗号化キーを、簡単に生成、管理できるマネージドサービスの、AWS KMS を使用します。

2つの KMS マスターキーを生成します。ひとつは EMR外のデータを暗号化する S3 クライアントサイド暗号化キーとして、もうひとつはローカルディスクを暗号化するための LUKS 暗号化のキーとして使用します。 Hadoop MapReduce フレームワークは HDFS を使用します。Spark は、ワークロードの中でメモリから溢れた中間データを一時的に保存する先として、各スレーブインスタンスのローカルファイルシステムを使用します。

鍵を生成するために、kms.json という AWS CloudFormation スクリプトを使用します。スクリプトの中で、キーの エイリアス名またはディスプレイ名を指定します。エイリアスは “alias/エイリアス名” 形式で、エイリアス名はアルファベット、アンダースコア、ダッシュのみで構成される必要があります。

o_Amazon_EMR_Encryption_2

キーの作成が終わったら、Outputs として ARN が表示されます。

o_Amazon_EMR_Encryption_3

SSL 証明書の作成

SSL 証明書によって、Mapreduce のシャッフル中にデータがノード間を転送されるときに、データの暗号化が行われます。

o_Amazon_EMR_Encryption_4

この手順では、OpenSSL で 2048-bit RSA 秘密鍵による X.509 自己署名証明書を作成します。これを使って EMR クラスタのインスタンスにアクセスします。画面に従って、証明書発行に必要な情報を入力します。

cert-create.sh を使って、zip ファイルに圧縮した SSL 証明書を生成します。zip 圧縮済みの証明書を S3 にアップロードし、S3 のプレフィックスをメモしておきます。セキュリティ設定を構成するときには、この S3 プレフィックスを使用します。

重要
この例は、あくまで proof-of-concept のデモにすぎません。自己署名証明書を使うことは推奨されませんし、潜在的なセキュリティリスクを孕みます。実運用システムでは、信頼できる認証局が発行した証明書を使ってください。

カスタムプロバイダの証明書には、TLSArtifacts プロバイダインタフェースを使用してください。

環境の構築

EMR クラスタをプライベートサブネットに構築します。もしすでに VPC があり、パブリックサブネットにクラスターを立てたい場合には、このセクションを飛ばして、セキュリティ設定の作成のセクションに進んでください。

クラスターをプライベートサブネット内に立てるためには、以下のリソースが必要です。

  • VPC
  • プライベートサブネット
  • パブリックサブネット
  • 踏み台サーバ
  • マネージド NAT ゲートウェイ
  • S3 VPC エンドポイント

EMR クラスターをプライベートサブネットに立てる際には、クラスターに SSH で入るための踏み台サーバかジャンプサーバが必要になります。クラスターの起動が終わったら、KMS からデータキーを取得するためにインターネットに接続する必要があります。プライベートサブネットからは直接インターネットに接続できないので、マネージド NAT ゲートウェイ経由でトラフィックの経路を制御します。S3 に対して、高信頼性を確保して安全に接続するために、S3 VPC エンドポイントを使用します。

o_Amazon_EMR_Encryption_5

CloudFormation コンソールで、environment.json テンプレートを使って、環境構築用の新しいスタックを作成します。

パラメタとして、踏み台サーバのインスタンスタイプと、そのサーバに SSH アクセスするための EC2 キーペアを入力します。適切なスタック名とタグを指定します。例えば、私の作成したスタックのレビューステップのスクリーンショットは、以下の通りになります。

o_Amazon_EMR_Encryption_6

スタックの作成が終わったら、Outputs タブを開いて VPC、踏み台サーバ、プライベートサブネットのIDをメモしておきます。これらはあとで EMR クラスタを立ち上げる際に使用します。

o_Amazon_EMR_Encryption_7

セキュリティ設定の作成

セキュアな EMR クラスタを立ち上げる前の最終ステップは、セキュリティ設定の構成です。EMR の S3 クライアントサイド暗号化と、先ほど作成した KMS キーを用いたローカルファイルの LUKS 暗号化について、セキュリティ設定を作成します。さらに MapReduce のシャッフルで暗号化を行うために、先ほど作成して S3 にアップロードしておいた SSL 証明書も使用します。

o_Amazon_EMR_Encryption_8

EMR クラスターの立ち上げ

さて、これでプライベートサブネットに EMR クラスタを立ち上げることができるようになりました。まずサービスロールとして、サービスポリシー内の AmazonElasticMapReduceRole が EMR に割り当てられていることを確認します。デフォルトのサービスロールは EMR_DefaultRole です。詳しくはIAMロールを使用したユーザーアクセス権限の設定を参照してください。

環境の設定セクションでメモしておいた VPC ID とサブネット ID の中で、EMR クラスタを立ち上げます。Network EC2 Subnet フィールドで、それらの値を選択してください。続いてクラスタの名前とタグを入力します。

o_Amazon_EMR_Encryption_9

最後のステップはプライベートキーの選択です。ここでは、セキュリティ設定の作成セクションで作っておいたセキュリティ設定を適用します。そして Create Cluster をクリックします。

o_Amazon_EMR_Encryption_10

これで作成した環境の上で、クラスタが立ち上がりました。続いてマスターノードに入ってスクリプトを実行します。EMR コンソールページからクラスタの IP アドレスを取得します。HardwareMaster Instance Group と選択して、マスターノードのプライベート IP アドレスをメモします。

o_Amazon_EMR_Encryption_11

マスターノードはプライベートサブネット内にあるので、まず踏み台サーバに SSH で入り、そこからさらにマスターノードに接続します。踏み台サーバと Hadoop マスタへの SSH については、ssh-commands.txt ファイルをみてください。踏み台サーバへのアクセスについてのさらなる詳細は、Securely Connect to Linux Instances Running in a Private Amazon VPC のエントリーを参照してください。

マスターノードに入った後は、Hive や Spark のスクリプトを実行します。動作確認用として、GitHub /code ディレクトリには PySpark の test.py と Hiveの test.q スクリプトが含まれています。

まとめ

この投稿の中で、データの暗号化が必要な複数のパターンについて述べ、各パターンでどうやって暗号化するかについての手順を説明しました。そして暗号化の前提要件である KMS キーの作成、SSL 証明書の発行、強力なセキュリティ設定による EMR クラスタの立ち上げについて、順を追って解説しました。そして VPC 内のプライベートサブネットでのクラスター起動によって、データをセキュアに
保つとともに、EMR クラスターにアクセスするために踏み台サーバを活用することができました。

もし疑問や助言があれば、ぜひおしらせください。

(翻訳はSA志村が担当しました。原文はこちら

今すぐ利用可能に – Lumberyard Beta 1.7

Lumberyardをローンチしてから1年も経っていないとは信じられません。お客様の反応とLumberyardとのエンゲージメントは私たちの期待を超えており、2017年にはお客様の進展を加速させることができて非常に興奮しています。Cloud Imperiumのような業界で最も野心的な開発者を含むあらゆるタイプのゲーム開発者から、信じられないほどつながっている世界を築いています。今日では、発売以来の最大のリリースで新年を始めることができて嬉しく思っています。 Lumberyard Beta 1.7には、403以上の新機能、改善点、修正点が含まれており、ここからダウンロードできます。

今回のリリースでは好きなことがたくさんあります。Lumberyardを使いやすくし、プロフェッショナルなゲーム開発者がもっと使いやすいようにするために、いくつかのアップデートをお伝えしたいと思います。私たちのチームはアクセシビリティについて考えており、チームの洗練さや品質、チームの規模や構成にかかわらず、私たちの選択肢があなたのビジョンを達成することを決し妨げないようにしたいと考えています。 アクセシビリティを測定する最も重要な方法の1つは、「顧客がどれくらい迅速に資産を取得して再利用できるのか」という問題です。ゲーム開発者にとって最も反復的なタスクの1つは、プロジェクト資産の作成と管理です。アーティスト、デザイナー、ゲームプレイエンジニアにとっては、1日に数百回から数千回の時間がかかるため、アセットを数秒で処理することができれば、チームのスピードに大きな違いが生まれます。加速を達成するための当社の戦略は、LumberyardのAsset Processorと、Lumberyard Beta 1.7を初めて導入したAsset Browserです。資産プロセッサーを使用すると、資産をほぼすぐにエンジンに取り込むことができます。ファイル(MayaやPhotoshopなど)をフォルダに保存するだけで、Asset Processorはそのファイルをソースアートからゲーム用アセットに自動的に処理します。元に戻ってアセットを編集すると、Lumberyardは変更を認識し、バックグラウンドで数秒で自動的に更新します。

1.7での新しいLumberyard Asset Browser Previewを使用すると、エディタ内の使い慣れたビューで使用可能なすべてのアセット(エディタ、Gem、プロジェクトフォルダ内のソースフォルダとファイルを含む)を表示し、シーン内のアセットをドラッグ&ドロップできます。エディタからワンステップでソース資産にアクセスすることができれば、特にプロジェクトで複数の出力を生成できる複雑なソースアセット(たとえば、メッシュとマテリアルの両方を含む単一の.fbxファイル)を使用する場合は、処理速度が大幅に向上します。また、Lumberyard Asset Processorを使用して、資産が変更、削除、または追加されると、新しい資産ブラウザが自動的に更新されます。 Asset Browserの基礎となるAPIはLumberyardバスシステムに公開されているので、独自のプラグインやコントロールを作成している場合は、ファイルサイズ、名前、場所、資産を作成したソース、資産などの豊富な情報にアクセスできます。他のどの資産が同時に生産されたか アクセシビリティについて考えるもう一つの方法は、Lumberyardエディタ自体のレイアウトと情報アーキテクチャです。 Lumberyard Editorには、基本的な編集者や照明ツールなどのさまざまな機能があり、ジャンル固有のツール(道路や川のツールなど)があります。時間の経過とともに自然に成長するフィーチャの量は、効率的に整理されていなければ、学習することが難しくなります。さらに、両方のゲームチームが新しい専門的な役割を創り出し、DCCツールが進化するにつれ、ベストプラクティスは長年にわたって進化しています。このため、Lumberyard Beta 1.7では、最高品質の、最も野心的なゲームを構築するための機能を失うことなく、Lumberyardのアクセシビリティを向上させるために、Editor Editorのコアに加えたいくつかの変更点をご紹介します。デフォルトのエディタレイアウト自体は少し違って見えます:

lumberyard-editor-1.7-1024x610

(以前のバージョンのLumberyardをインストールしている場合は、現在のレイアウトを上書きしませんが、[View – Layouts – Component Entity Layout]を選択して新しいレイアウトに切り替えることができます)

上記の内容は、Editor UXの改良の第1段階です。私たちは、社内外の多くのゲーム開発者にインタビューし、新しいコンポーネントエンティティシステムと顧客からのフィードバックを基にしたメインエディタインタフェースの再構成と合理化を開始しました。以前はゲームオブジェクトを作成するために、12種類のオブジェクトタイプの中から選択し、ロールアップバーの複数のレイヤーをナビゲートしてカスタマイズしなければなりませんでした。今では、単純な右クリックで作成できるゲームエンティティの1つのタイプとなりました。エンティティのコンポーネントを編集し、そのエンティティで使用するファイルを選択し、すべてのレベルのエンティティを切り替えるのは、すべてメインウィンドウで行われます。エンティティのネストされたプレハブ(「スライス」)を簡単に作成することもできます。メインウィンドウを右クリックするだけです。

次にUXチームのリストでは、ツールバーとトップメニューを合理化しながら、自分の役割や好みに基づいてレイアウトを深くカスタマイズすることができます。私たちは、顧客からより多くのデータとフィードバックを収集しています。あなたがアイデアを持っているなら、それについて聞きたいのです。フォーラムで、私達がどこに向かうのかのプレビューをご覧ください。
モバイルデベロッパーにとって、「使いやすい」とは、可能な限り短時間でエディターからデバイスにゲームを展開できることを意味します。そのため、ゲームを編集してから再生することができます。 Lumberyard Beta 1.7には、エディタに新しいデプロイメントツールが含まれているため、ワンクリックでエディタからAndroidデバイスにリリース、プロファイル、またはデバッグビルドをわずか数秒で展開できます。以前は、エンジニアはコマンドラインツールのみを使用してモバイルビルドを導入する必要がありました。これで、チームの誰もがAndroidビルドをエディタからデバイスに展開できます。
私たちのチームは、エディタをより使いやすくすることでより速く反復できるようにすることに加えて、マルチプレイヤーゲームをより簡単に作成できるようにするために多くの時間を費やしています。PCとコンソールゲームの上位80%がマルチプレイヤーをフィーチャーし、Twitchでストリーミングされるトップゲームの90%がマルチプレイヤーゲームです。だから、他のエンジンよりもマルチプレイヤーを簡単にするためのシステムとサービスをリリースしても、ゲーム開発者からの肯定的なフィードバックを引き続き得ることは驚くことではありません。この目的のために、私たちのネットワークチームは、コンポーネントエンティティのワークフローと高性能なネットワークレイヤ、GridMateを使用して完全に構築された新しいマルチプレイヤーサンプルをリリースしました。GridMateは効率的な帯域幅使用と低遅延通信を目的として設計されています。 30分以内に、新しいサンプルを起動して実行して、自分のマルチプレイヤーゲームやプロトタイプの出発点として使用できます。サンプルは現在PCをサポートしており、すぐにモバイルプラットフォームとコンソールプラットフォームをサポートするようにサンプルを拡張します。

AresScreenshotHighRes-1024x587

これらの例は、Lumberyardを世界最高クラスの使いやすいエンジンにするための、我々が継続的に行った変更のサンプルです。それは、我々はちょうど始まっていると言いました。業界の進化に伴い、より多くの人々がプレイし、ファンはさらに高品質のコンテンツを要求しています。私たちはあなたの能力が向上し、最も野心的なビジョンを達成し、ファンの愛するゲームを構築します。エンジニア、アーティスト、ゲームデザイナー、またはまだ発明されていない新しい役割を持つことができます。 Visual Studio 2015のサポート、VRの球面ビデオ再生のサポート、Perforce Helixとの統合、Geppetto文字ツールのUXの改良、オーディオ、照明、複合図形、アニメーションをサポートする新しいコンポーネントエンティティなど、このアップデートにはさらに多くのものがあります。 Twitch ChatPlayとMetastreamのアップデート、最新のAWS 1.0.24 SDKとの統合などが含まれます。 Lumberyard Beta 1.7の新機能の詳細については、こちらのリリースノートを参照してください。

Amazon Lumberyardを使い始めるには、LumberyardのウェブサイトでLumberyardをダウンロードしてください。 Lumberyardの新機能について詳しくは、チュートリアルフォーラムドキュメントを参照してください。

(翻訳はSA 森が担当しました。原文はこちら)

Amazon WorkSpaces の更新 – SSD ボリュームとコストオプティマイザ

長い間ブログをお読みいただいているお客様は、私が Amazon WorkSpaces を非常に気に入ってフルタイムで使用していることをご存知かと思います (詳細については、「Amazon WorkSpace がお気に入りです!」を参照してください)。さまざまなデバイスウェブブラウザからアクセスできる単一の環境があることにより、作業に集中し、多くの問題を軽減することができます。本日は、SSD ボリュームと WorkSpaces 用の新しいコストオプティマイザについてご紹介します。

新しい SSD ボリューム
本日より、新しく起動されたすべての Amazon WorkSpaces では、ルートボリュームおよびユーザーボリューム用に汎用 SSD ストレージが追加料金なしで使用されます。これらのボリュームにより、マグネティックボリュームよりもパフォーマンスが向上するため、ディスクのレイテンシーの影響を受けるアプリケーションを実行するときに、より高速な起動時間とより良いユーザーエクスペリエンスが得られます。既存の WorkSpaces は、再構築してストレージに SSD ボリュームを使用するようアップグレードすることができます (これにより、システムドライブ (C:) は元の状態にリストアされ、最新の自動スナップショットのコンテンツを使用してデータドライブ (D:) が再作成されます)。システムドライブの既存データはすべて失われます。新しい SSD ボリュームの追加料金はなく、Amazon WorkSpaces が運用されているすべてのリージョンで利用できます (両方の詳細については、WorkSpaces の料金表ページを参照してください)。SSD ストレージの利点を得るため、コンソールから新しい WorkSpaces を起動できます。目的のバンドルを選択し、通常どおり作業を続行します。

WorkSpaces コストオプティマイザ
当社のお客様は、Amazon WorkSpaces を多くの異なる方法で使用しています。単一の組織内でフルタイムで使用するお客様もいれば、移動中や特定のプロジェクトでパートタイムで使用するお客様もいます。WorkSpaces では、お客様のニーズを満たすため、時間別および月別の請求オプションと、必要に応じてそれらを切り替える機能を提供しています。新しい Amazon WorkSpaces コストオプティマイザでは、この柔軟性に基づき、WorkSpaces 使用量データを分析し、結果に基づいて最もコスト効果の高い請求オプションを自動的に適用します。コストオプティマイザは、AWS CloudFormation テンプレートを通じてデプロイされる AWS ソリューションとして提供されます。このソリューションでは、CloudWatch イベントCloudWatch ログAWS Lambda 関数、Amazon S3AWS Directory ServiceWorkSpaces API を含む、複数の異なる AWS のサービスや機能が利用されます。その概要を次に示します。

Lambda 関数は 1 日 1 回実行されます。ログデータを分析し、最もコスト効果の高い請求オプションを判断してから、ModifyWorkSpaceProperties 関数を呼び出してオプションを設定します。すべての変更は S3 バケットに記録されます。このソリューションはそのまま使用したり、お客様独自の環境に合わせてカスタマイズしたりできます。また、分解して、イベント、ログ記録、サーバーレスコード、および API の組み合わせを使用し、組織の効率を興味深い方法で高める方法を確認することも可能です。

Jeff;