Amazon Web Services ブログ

Elastic Network Adapter – Amazon EC2 向けの高性能パフォーマンスネットワークインターフェイス

AWS をご利用されているお客様の多くは、複数の EC2 インスタンスに渡り密結合のシステムを作成し、利用可能なすべてのネットワーク帯域幅を有効に活用されています。本日、AWS はこの非常に一般的なユースケースを対象に、今まで以上に優れたサポートを提供する Elastic Network Adapter (ENA) をリリース致しました。新しい X1 インスタンスタイプを対象とする ENA には追加費用もなく、プレイスメントグループ内で使用した場合、低レイテンシーで安定したパフォーマンスを最大 20 Gbps でご提供します。ENA のメリット
ENA は X1 インスタンスで見られる最新のプロセッサと合わせて運用できるように設計されています。こうしたプロセッサは多数の仮想 CPU (X1 の場合は 128) を含むため、ネットワークアダプターなどの共有リソースを効率的に使用することが重要です。高いスループットやパケット毎秒 (PPS) のパフォーマンスを提供しながら、ENA は数々の方法でホストプロセッサのロードを最小限に抑えます。以下の例をご覧ください。

  • チェックサム生成 – ENA はハードウェアの IPv4 ヘッダーチェックサム生成と TCP / UDP の一部のチェックサム生成を処理します。
  • マルチキューデバイスインターフェイス – ENA は複数の配信を使用し、キューを受信して内部のオーバーヘッドを削減します。
  • 受信側による実行 – ENA は適切な vCPU が処理するように着信パケットを誘導します。これにより障害を回避しキャッシュの有効性を高めることができます。

こうした機能は可能な限りプロセッサのワークロードを軽くし、ネットワークパケットと生成または処理を行う vCPU 間で短く効率的なパスを作成するために構築されています。ENA の使用
X1 インスタンス間で 20 Gbps のパフォーマンスを実現するには、プレイスメントグループから起動してください。ENA のその他のメリットは、低レイテンシーや安定したパフォーマンスをインターネットやプレイスメントグループ外からの通信においても提供することです。新しい ENA ドライバは最新の Amazon Linux AMI でご利用いただけます。また、近日中に Windows AMI にも対応する予定です。お客様自身の AMI での利用につき、ソースフォーム (Linux および Windows) でもご使用いただけます。ドライバは Intel の Data Plane Developer Kit (DPDK) を使用してパケットプロセスのパフォーマンスやスループットを高めます。ご自分で AMI を作成される場合は、 enaSupport の属性を設定してください。 コマンドラインからの作成については次をご覧ください。

$ aws ec2 modify-instance-attribute --instance-id INSTANCE_ID --ena-support true

ENA をサポートしていないインスタンスで AMI を使用することもできます。今後のプラン
上記の通り、現在 ENA は X1 でご利用いただけます。今後 EC2 インスタンスタイプでも使用可能になる予定です。

新たにアジアパシフィック(ムンバイ)リージョンがオープン

私たちはインドのムンバイに新たなリージョンをオープンしたことをお知らせ致します。インドでAWSをお使いのお客様は、サービスをより快適にお使いいただけるようになります。

新リージョン
アジアパシフィック(ムンバイ)リージョンは2つのアベイラビリティゾーンがあり、グローバル全体では35個になりました。本リージョンでは、Amazon Elastic Compute Cloud (EC2) (C4, M4, T2, D2, I2, とR3インスタンスが 利用可能)と Amazon Elastic Block Store (EBS), Amazon Virtual Private Cloud, Auto Scaling, とElastic Load Balancing などの関連サービスに対応します。

他にも以下のサービスに対応致します。

インドには3個所のエッジロケーション(ムンバイ、チェンナイ、ニュー・デリー)があります。それぞれ、Amazon Route 53, Amazon CloudFrontS3 Transfer Acceleration に対応します。AWS Direct Connectも以下のパートナー経由で利用できます。

アジアパシフィック(ムンバイ)リージョンは私たちの13番目のリージョン(AWS Global Infrastructureのマップはこちら)で、いつもの通りコンソール上のメニューで確認できます。

お客様
インドには75,000以上のアクティブなAWSのお客様がいて、様々な産業で幅広くご利用いただいています。本日のオープンにあたっては、いくつかのお客様にプレビュー公開しています。2社(Ola CabsとNDTV)はその経験と考察を十分に共有していただきました。

Ola Cabs のモバイルアプリは、インドにおける100以上の拠点間の乗り換えを再定義しました。AWSは、OLAがサービスにおいて顧客体験の提供に妥協することなく、新機能やサービスを素早くお客様に提供できるようイノベーションを継続的を支援しました。Ankit Bhati (CTOで共同創業者)は以下のように話しています。

私たちは、乗り換えの選択肢提供と利便性の提供のため、数十億のインド人が使えるモバイルアプリをAWSのテクノロジーを使って作っています。最高の顧客体験、お客様へ新機能やサービスの提供においてさらに早くイノベーションを起こすこと、その為にテクノロジーは実現の鍵です。これにより、インドで100以上もの都市と55万ものドライバーのパートナーの役に立っています。様々なAWSのビッグデータ関連のサービスを利用し、ペタバイト級の解析とディープラーニングを行い、お客様が必要な時にドライバーとすぐに近づける仕組みを提供しています。AWSなら、100もの遅延の少ないAPIにより、毎日数百万のリクエストのあるスケーラビリティの高いマイクロサービスベースのプラットフォームに対して、一日に30以上もの変更を加えることが可能になります。私たちもアジアパシフィック(ムンバイ)リージョンを試してみました。素晴らしいですし、顧客体験をさらに強化するのに役立つでしょう。

 


NDTVは、世界で数百万もの人々に視聴されている、インドで主要なメディアです。NDTVは2009年からAWSを使用しており、映像やウェブプラットフォームで利用しています。2014年5月のインド総選挙の間、NDTVは5億ヒットから130億ヒットにもなる、通常の26倍ものウェブトラフィックを投票日に予測しており(通常は40万ヒット/秒)、すべてAWS上で動作しています。Kawaljit Singh Bedi (CTO of NDTV)によると、

NDTVはインドでのプレビューにおいて、AWSインフラの信頼性や安定性に関して信頼できる結果を報告できたことをうれしく思います。技術チームが実施したインドでのテストにおいて、ネットワークの遅延が他の代替手段よりも少ないことを確信しました。昨年ウェブとモバイルのトラフィックは30%以上も増加し、e子アースやプラットフォーム連携し地域を拡大していく際にアジアパシフィック(ムンバイ)リージョンが使用できることにワクワクしています。リージョンオープン時点で提供されるサービスポートフォリオ、低遅延、素晴らしい信頼性、インド国内の規制当局の要望事項との合致など、NDTVは現状からすべてAWSへミッションクリティカルアプリとITインフラを移行することを決めました。

 

 


他にも以下のようなお客様がいらっしゃいます。

 

Tata Motors Limited インドを代表する自動車製造メーカーはテレマティクスシステムをAWS上で実現しています。車両オーナーが車両の状況を即時把握するソリューションとして使用しています。AWSはTata Motorsがイノベーションと顧客体験をさらに俊敏にできるよう支援しました。

redBus はインドを代表するウェブ、モバイル、バス会社を経由してチケットを販売するプラットフォームです。redBusは現在67,000ものルートをカバーし、バス会社は1,800にも上ります。2010年の200万から、年間4000万ものバスチケットの販売に規模が拡大しました。繁忙期には毎分100チケット以上にもなります。redBusはSaaSアプリを開発し、独自のチケットや席管理を自分で操作できる選択肢をバス会社に与えました。redBusはAWSを使ってシンガポールやペルーなど新たな地域にもグローバルに展開しています。

Hotstar は85,000時間ものドラマ、映画やスポーツイベントなどを映像ストリーミングするインド最大のプラットフォームです。2015年2月に開始し、Hotstarは最速で世界中いたるところで使われるようになったアプリのひとつです。6,800万ユーザにダウンロードされ、動画再生の高いテクノロジーとデバイスとプラットフォーム間の品質の良さで視聴者を魅了しています。

Macmillan India はインドの教育市場において120年以上もの間出版事業を展開しています。AWSを使用するにあたり、Macmillan Indiaは重要なエンタープライズのアプリケーションであるビジネスインテリジェンス(BI)、販売・流通、材料管理、財務経理、人事、CRMなどをチェンナイにあるデータセンターからAWSに移行しました。移行によりMacmillan IndiaはSAPの可用性をほぼ100%にし、インフラの設定作業を6週間から30分に短縮しました。

パートナー
インドの幅広いパートナと共に働けることをうれしく思います。いくつかご紹介します。

  • AWS プレミアコンサルティングパートナー – BlazeClan Technologies Pvt. Limited, Minjar Cloud Solutions Pvt Ltd, Wipro.
  • AWS コンサルティングパートナー – Accenture, BluePi, Cloudcover, Frontier, HCL, Powerupcloud, TCS, Wipro.
  • AWS テクノロジーパートナー – Freshdesk, Druva, Indusface, Leadsquared, Manthan, Mithi, Nucleus Software, Newgen, Ramco Systems, Sanovi, Vinculum.
  • AWS マネージドサービスプロバイダー – Progressive Infotech, Spruha Technologies.
  • AWS Direct Connect パートナー – AirTel, Colt Technology Services,  Global Cloud Xchange, GPX, Hutchison Global Communications, Sify, Tata Communications.

インドのAmazonオフィス
2011年以降インドに6つのオフィスを開設しました。デリ、ムンバイ、ハイデラーバード、バンガロール、プネ、チェンナイにあります。オフィスでは、エンタープライズ、政府機関、教育機関、中小・中堅企業、スタートアップ、開発者など幅広いカスタマーベースを支援します。

サポート
AWS Supportで準備しているサポートのすべてが対象(Basic, Developer, Business, Enterprise)です。長期契約なしに、上限なしで顧客および支払いに関するサポートをご利用いただけます。

コンプライアンス
各AWSリージョンは、ISO 27001, ISO 9001, ISO 27017, ISO 27018, SOC 1, SOC 2, and PCI DSS Level 1など現地の法律や規律に準拠するよう準備されています。AWSはサードパーティによって評価されるinformation Security Management System (ISMS)に準拠しています。これらの評価は、AWSウェブサイトや認証や監査報告書を弊社のホームページや要望によりお客様へ提供することで、幅広い要望事項に対応します。

詳しくはこちらをご覧ください。さらにAWSを学ぶにはAWS Cloud Compliance と Data Privacy FAQ をご覧ください。

使ってみましょう
アジアパシフィック(ムンバイ)リージョンがオープンし、本日からご利用いただけます!追加の情報として、移行方法のドキュメント、お客様の事例、トレーニングやイベントの情報、インドでのパートナー一覧などがこちらから参照いただけます。

私たちはインドでの販売状況を記録(AISPLとして知られています)しています。詳細についてはAISPLカスタマーアグリーメントを参照ください。

Jeff;

(翻訳は石橋が担当しました。原文はこちらです。)

 

Amazon Elastic File System が 3 つのリージョンで利用可能に

AWS のストレージ製品ラインは時間とともに豊かに多様な成長を遂げてきました。単一のストレージクラスで開始した Amazon S3 は現在、定期的かつ低頻度にアクセスされる、アーカイブ済みのオブジェクト向けの複数のストレージクラスを提供しています。同様に、単一のボリュームタイプで始まった Amazon Elastic Block Store (EBS) も、現在は 4 種類の SAN スタイルブロックストレージを提供しており、各ストレージが特定のアクセスパターンやデータタイプ向けに設計されています。オブジェクトストレージおよびブロックストレージへの対応は S3 および EBS によってカバーされていることから、AWS は次にファイルシステムに注目を向けました。AWS は、複数の EC2 インスタンス向けに、完全マネージド型ファイルシステムへの低レイテンシーの共有アクセスを提供するため、昨年 Amazon Elastic File System (EFS) を発表しました。そしてこのたび、EFS が US East (Northern Virginia)、US West (Oregon)、Europe (Ireland) の各リージョンでも本稼動使用できるようになりました。本日の発表に至るまで、AWS は長期のプレビュー期間にわたり、実に幅広いお客様のユースケースを検討してきました。EFS プレビューは、大規模かつ高スループット処理ワークロード、および多様なコンテンツとウェブ配信に最適でした。プレビュー期間、こうしたワークロードに対する EFS パフォーマンスについてポジティブなフィードバックが多数寄せられました。一方、レイテンシーの変化に影響を受け、ファイルシステムメタデータを多用するワークロードについても同様に優れたサポートを提供してほしいというご要望もいただきました。こうしたフィードバックへの取り組みの結果、本日のラウンチは非常に幅広いユースケースに対応できる設計となっています。これまで、お客様には EFS に大変ご満足いただき、すぐにでも使用を開始したいというご意見をいただいております。

EFS を構築した理由
AWS をご利用の多くのお客様から、拡張可能なファイルストレージをより簡単に管理する方法を提供してほしいというご要望をいただいてきました。こうしたお客様には、共通の名前空間と、企業または部署別のファイル階層への簡単なアクセスによってメリットを受ける、ウェブサーバ群やコンテンツ管理システムを稼動している方もいらっしゃいます。一方、多数の大規模ファイルを作成、処理、削除する HPC およびビッグデータアプリケーションを運用して、著しく変化するストレージ利用とスループットの需要に対応しているお客様もいらっしゃいます。また、AWS のお客様は、高可用性、高耐久性とともに、アクセスと変更に対しても強力な整合性を提供するモデルを求めてきました。

Amazon Elastic File System
EFS では、POSIX 準拠のファイルシステムを作成して、NFS 経由で 1 つ以上の EC2 インスタンスにアタッチできます。このファイルシステムは必要に応じて拡大/縮小するため (一定の上限はなく、ペタバイト規模まで拡張可能)、ストレージスペースや帯域幅を事前にプロビジョニングする必要はありません。料金が発生するのは、使用したストレージ分のみです。EFS は、ファイル、ディレクトリ、リンク、メタデータのコピーを複数のアベイラビリティーゾーンに保存することで、データを保護します。複数のクライアントが同時にアクセスする大規模なファイルシステムのサポートに必要なパフォーマンスを提供できるよう、Elastic File System パフォーマンスもストレージにあわせて拡張します (この点については後ほど詳しくご説明します)。それぞれの Elastic File System は 1 つの VPC からアクセス可能で、VPC 内で作成するマウントターゲットを介してアクセスされます。VPC のどのサブネットでもマウントターゲットを作成することができます。各マウントターゲットへのアクセスは、通常通りセキュリティグループを使ってコントロールされます。EFS には 2 つの異なるパフォーマンスモードがあります。1 つめのモードは、デフォルトの汎用モードです。数十、数百、数千の EC2 インスタンスがファイルシステムに同時アクセスする場合を除き、このモードを使用します。もう 1 つのモード I/O 最大は、より高レベルの集計スループットと 1 秒あたりのオペレーション数にあわせて最適化されますが、ファイルオペレーションのレイテンシーがわずかに高くなります。ほとんどの場合は汎用モードから開始し、関連する CloudWatch メトリックス (PercentIOLimit) を監視してください。汎用モードの I/O 制限のプッシュを開始する場合は、I/O 最大モードで新しいファイルシステムを作成し、ファイルを移行すれば、さらに高いスループットと 1 秒あたりのオペレーション数を活用することができます。

Elastic File System の動作
Elastic File System の作成、マウント、アクセスは非常に簡単です。私は AWS Management Console を使用しました。EFS API、AWS Command Line Interface (CLI)、またはAWS Tools for Windows PowerShell を使うオプションもあります。コンソールを開き、[Create file system] ボタンをクリックしました。

次に、VPC の 1 つを選択し、パブリックサブネットにマウントターゲットを作成しました。

私のセキュリティグループ (corp-vpc-mount-target) では、EC2 インスタンスがポート 2049 のマウントポイントにアクセスできます。以下はインバウンドルールです。アウトバウンドルールも同じです。

Name タグと Owner タグを追加し、汎用パフォーマンスモードを選択しました。

次に、情報を確認して、[Create File System] をクリックしました。

すぐにファイルシステムを使用できるようになりました (マウントターゲットもその後 1 分ほどで準備が完了しました)。

[EC2 mount instructions] をクリックし、EC2 インスタンスにファイルシステムをマウントする方法を確認しました。

ファイルシステムを /efs としてマウントすると、以下のようになりました。

多くのファイルをコピーし、しばらく NFS ステータスを確認していました。

コンソールに、ファイルシステムによる消費容量のレポートが表示されます (この情報は 1 時間ごとに収集され、収集後 2~3 時間で表示されます)。

 

CloudWatch メトリックス
各ファイルシステムは、CloudWatch に以下のメトリックスを提供します。

  • BurstCreditBalance – バーストレベルのスループットで転送可能なデータ量。
  • ClientConnections – ファイルシステムに接続されているクライアント数。
  • DataReadIOBytes – ファイルシステムから読み込まれるバイト数。
  • DataWriteIOBytes – ファイルシステムに書き込まれるバイト数。
  • MetadataIOBytes – 読み込み/書き込みされるメタデータのバイト数。
  • TotalIOBytes – 前述の 3 つのメトリックスの合計。
  • PermittedThroughput – ファイルシステムのサイズに基づいた最大許容スループット。
  • PercentIOLimit – 汎用モードで利用可能な I/O の割合。

これらのメトリックスは CloudWatch コンソールで確認できます。

 

EFS バースト、ワークロード、パフォーマンス

各 EFS ファイルシステムで可能なスループットは、ファイルシステムの拡張とともに増加します。ファイルベースのワークロードは通常スパイクが発生しやすく、短期間は高レベルのスループットが要求され、それ以外の期間は要求されるスループットのレベルが下がります。EFS は、必要に応じて高スループットレベルに対応してバーストするよう設計されています。すべてのファイルシステムは、100 MB/秒スループットまでバーストできます。1 TB を超えるファイルシステムではストレージ TB あたり 100 MB/秒までバースト可能です。例えば、2 TB のファイルシステムでは 200 MB/秒まで、10 TB のファイルシステムでは 1,000 MB/秒スループットまでバースト可能です。1 TB を超えるファイルシステムでは、使用時間の半分ファイルシステムが使われていない場合、残りの半分の時間はバーストし続けることができます。EFS ではクレジットシステムを使ってファイルシステムがバースト可能なタイミングを判断します。各ファイルシステムは、ファイルシステムのサイズに応じたベースラインレート (ストレージ 1 TB あたり 50 MB) でクレジットを蓄積し、データの読み込み/書き込み際にこれを使用します。クレジットが蓄積すると、ファイルシステムでベースラインレートを超えるスループットを利用できるようになります。実際の運用例で考えてみましょう。

  • 100 GB のファイルシステムでは 1 日 72 分まで最大 100 MB/秒のバーストが可能です。または、連続して 5 MB/秒までバーストできます。
  • 10 TB のファイルシステムでは、1 日 12 時間最大 1 GB/秒まで、または連続して 500 MB/秒バーストが可能です。

クレジットシステムの仕組みについては、ファイルシステムパフォーマンスについての EFS ドキュメントを参照してください。この機能をよく理解するために、数日間ファイルをコピーして連結してみたところ、結局 2 TB を超えるファイルシステムの容量が使用されました。ファイルコレクションが 1 TB を超えると、使用量にあわせて PermittedThroughput メトリックスも上昇することがわかりました。以下は、表示された内容です。

どのファイルシステムでも同じように、スループットはワークロードの特徴に左右されます。平均 I/O サイズ、EFS への同時接続数、ファイルアクセスのパターン (ランダム/シーケンシャル)、リクエストモデル (同期/非同期)、NFS クライアント構成、NFS クライアントを実行する EC2 インスタンスのパフォーマンス特性のそれぞれがポジティブまたはネガティブな影響を及ぼします。要約すると以下のようになります。

  • 平均 I/O サイズ – 小さいファイルに関連付けられたメタデータを NFS プロトコル経由で管理する作業、および耐久性と可用性の高いデータにするための EFS 側の作業が組み合わさって、オペレーションあたりのオーバーヘッドが作られます。一般的に、オペレーションあたりのオーバーヘッドは、より大量のデータで償却されるため、全体的なスループットは平均 I/O サイズに合わせて高まります。また、通常、読み込みにかかる時間は書き込みよりも高速です。
  • 同時接続数 – 各 EFS ファイルシステムは、数千のクライアントからの接続に対応できます。(複数の EC2 インスタンスからの) 高度に並列化された動作を実行できる環境では、多数の同時オペレーションに対応する EFS の機能が効果を発揮します。
  • リクエストモデル – マウント時間に async オプションを含めることで、ファイルシステムへの非同期書き込みを有効にすると、保留中の書き込みがインスタンス上でバッファされた後、非同期に EFS に書き込まれます。sync オプションでマウントされたファイルシステムにアクセスしたり、キャッシュをバイパスするオプション (例: O_DIRECT) を使ってファイルを開くと、代わりに EFS に対する同期リクエストが発行されます。
  • NFS クライアント構成 – 一部の NFS クライアントでは、読み込み/書き込みバッファに対して今日の標準よりもはるかに小さい値がデフォルトで使用されています。1 MiB への引き上げを検討してください (これは mount コマンドに対するオプションです)。EFS では NFS 4.0 または 4.1 クライアントを使用でき、4.1 の方が高いパフォーマンスを提供します。
  • EC2 インスタンス数 – 大量の I/O を処理するアプリケーションでは、大量のメモリや処理能力が必要となることがあります。十分なメモリと処理能力を用意し、適切なインスタンスサイズとタイプを選択してください。非同期読み込み/書き込みを実行する場合、カーネルでのキャッシュに追加のメモリが使用されます。また、EFS ファイルシステムのパフォーマンス特性は、EBS 最適化インスタンスの使用に左右されない点に注意してください。

ファイルシステムのベンチマークは技術と科学の融合です。成熟した信頼できるツールを使用し、複数回これらのツールを実行して、上記の検討事項に照らしながら結果を確認するようにしてください。期待されるパフォーマンスに関する詳しいデータは、Amazon Elastic File System ページでご確認いただけます。

ご利用について
EFS は、US East (Northern Virginia)、US West (Oregon)、Europe (Ireland) リージョンで、今日から使用を開始できます。料金は、保存データの量に応じて、1 日数回にわたるサンプルに基づき 1 か月あたりギガバイト単位で請求されます。通常通り日割り計算となり、US East (Northern Virginia) リージョンでの 1 か月の料金は、1 GB あたり 0.30 USD となります。最低料金やセットアップ料金はありません (詳しくは、EFS 料金表ページをご覧ください)。利用無料枠対象のお客様については、1 か月あたり最大 5 GB までの EFS ストレージを無料でご利用いただけます。

Jeff;

※6月末現在Amazon Elastic File Systemは東京リージョンで未提供です。対応リージョンは順次拡大の予定です。

 

 

AWS CodePipeline で、失敗したアクションのリトライが可能に

AWS CodePipeline で、アクション失敗後のリトライが出来るようになりました。以前は、手動でパイプライン全体をリスタートするか、失敗したアクションをリトライするために、パイプラインの Source Stage へ新たな変更をコミットする必要がありました。

CodePipeline 内でアクションがうまく完了しなかった場合、そのアクションは失敗し、パイプラインが停止し、パイプラインを通じた更新を止めてしまいます。本日から、パイプライン全体をリスタートする必要なく、失敗したアクションをリトライできます。

本機能はマネジメントコンソール、 AWS CLI, AWS SDK, API を使用して、利用可能です。リトライ機能の詳細は こちらをご覧下さい。

CodePipelineに関する詳細:

翻訳は江川が担当しました。原文はこちら

【新機能】 暗号化された EBS スナップショットのクロスアカウントコピー

AWS は既に、 Amazon Elastic Block Store (EBS) ボリュームとスナップショットの暗号化をサポートし、AWS Key Management Service (KMS)によって暗号化キーの保管、管理が行うことができます。また、他の AWS アカウントへの EBS スナップショットのコピーをサポートし、スナップショットから新しいボリュームを作成することができます。本日、暗号化された EBS スナップショットをAWS リージョン間で移動できる柔軟性とともに、アカウント間でコピーする機能が追加されました。

このアナウンスは、3つの重要な AWS のベストプラクティスのもとに作られました。

  1. 定期的にEBS ボリュームのバックアップを取得する
  2. 環境(開発、テスト、ステージング、本番)毎にアカウントを作成し、複数アカウントを利用する
  3. バックアップを含めた、データ(保管時のデータ)の暗号化を行う

暗号化された EBS ボリュームとスナップショット

では、実際にこの機能を利用してみたいと思います。まずは、振り返りの意味もこめて、IAM コンソールを使って、暗号化キーを作成します。

 

そして、暗号化キーを指定し(他のアカウントにコピーを行う場合、カスタムキーを利用する必要があります)、暗号化された EBS ボリュームを作成します。

続けて、暗号化された EBS スナップショットをボリュームから作成できます。

 

今ご覧いただいたように、私は既に長いボリュームIDとスナップショットID を私のAWS アカウントで有効にしています(こちらに関しての詳細は、They’re Here – Longer EBS and Storage Gateway Resource IDs Now Available をご確認ください)。

クロスアカウントコピー

今までご覧いただいたことに、何も新しいものはありませんでした。では、新しい部分に入っていきましょう!他のアカウントに暗号化された EBS スナップショットのコピーを作成するには、下記の4つのシンプルなステップを実施する必要があります:

  1. スナップショットに関連づけられたカスタムキーを共有先アカウントと共有する
  2. 暗号化された EBS スナップショットを相手先アカウントと共有する
  3. 共有先アカウントで、スナップショットのコピーを作成する
  4. 新しいボリュームを作成するために作成したコピーを利用する

上記の最初の2ステップを実施するには、共有先アカウント番号が必要です。ここから、IAM コンソールを通じて、どのように共有先アカウントにカスタムキーを共有するかを記していきます:

そして、暗号化された EBS スナップショットを共有します。共有するスナップショットを選択し、Modify Permissions(権限の変更)をクリックします。

共有先のアカウント番号を入力し、Save(保存)をクリックします。

 

 

暗号化されたスナップショットを一般公開することは出来ないので、ご注意ください。

次のステップに移る前に、少し権限について補足させてください!下記に、ポリシーやロールを設定するために知っておくべきことを記しました:

Source Account(スナップショットの共有元アカウント) – 共有元アカウントのIAM ユーザー、ロールは、 ModifySnapshotAttribute 関数を呼び出すことが出来る必要があり、オリジナルのスナップショットに関連づけられる鍵に対して、 DescribeKeyReEncypt 操作を実行できる必要があります。

Target Account(スナップショットの共有先アカウント) –共有先アカウントのIAM ユーザー、ロールは、オリジナルのスナップショットに関連づけられる鍵に対して、DescribeKey, CreateGrant, Decrypt の操作を実行できる必要があります。加えて、CopySnapshot の呼び出しに関連づけられた鍵に対して、CreateGrant, Encrypt, Decrypt, DescribeKeyGenerateDataKeyWithoutPlaintext 操作を実行できる必要があります。

では話を戻して、スナップショットのコピーを行いましょう。

共有先アカウントに切替え、 Snapshots(スナップショット) タブを表示し、Private Snapshots(プライベートスナップショット) をクリックします。スナップショット ID (スナップショット名はタグとして保存されますが、コピーされません)経由で、共有されたスナップショットを確認し、チェックボックスで選択し、Action(アクション) から Copy(コピー) をクリックします:

 

コピーされるスナップショットに使用する暗号化キーを選択します(ここでは、アジアパシフィック(東京)リージョンにスナップショットをコピーします)。

コピーに対して新しい鍵を利用することで、2つのアカウント間での分離レベルが高くなります。コピー操作中に、新しい鍵を使ってデータは再暗号化されます。

今すぐご利用可能です

この機能は AWS Key Management Service (KMS)が利用可能な全リージョンで利用可能です。データボリューム、ルートボリュームで利用できるように設計され、全てのボリュームタイプで利用可能ですが、現時点では暗号化されたAMIを共有するために利用することは出来ません。スナップショットをコピーし、新しいイメージとして登録することで、スナップショットを利用して、暗号化されたブートボリュームを作成できます。

— Jeff; (翻訳は江川が担当しました。原文はこちら)

 

 

AWS OpsWorksがCentOSをサポート

AWS OpsWorksを使って、CentOS 7が動作するAmazon EC2およびオンプレミスサーバを構成および管理することができるようになりました。

Chef 12 OpsWorksエージェントを使って、CentOSインスタンスを管理することが出来ます。CentOSは、OpsWorksが他のOS向けにサポートしている機能と同じ機能をサポートします。CentOSのサポートについての詳細は こちら をご覧ください。

OpsWorksの詳細:
製品ページ
ドキュメント

翻訳は舟崎が担当しました。(原文はこちら

Amazon RDS for OracleでOracle Repository Creation Utility (RCU) と April PSU Patchesをご利用頂けるようになりました

本日から、Amazon RDS for Oracleにて、Fusion Middlewareコンポーネント向けスキーマを作成するためにOracle Repository Creation Utility (RCU) 12c をご利用頂けるようになりました。こちらの機能は新規に起動する Amazon RDS Oracle 12c 及び 11gデータベースのバージョン”11.2.0.4.v8″, “12.1.0.1.v5” 及び “12.1.0.2.v4″でご利用可能です。これらのバージョンはApril 2016 Oracle Patch Set Updates (PSU)を含んでいます。バージョン“11.2.0.4.v8”,  “12.1.0.2.v4” はOracle GoldenGate向けの推薦パッチを含んでいます。また、“grant option” を利用してSYS objectsに権限を付与する機能を追加しています。

新規にOracle “11.2.0.4.v8”, “12.1.0.1.v5” と “12.1.0.2.v4” DBインスタンスを作成するにはAWS Management Consoleの”Launch DB Instance Wizard”を利用して、所望のDBバージョンを指定して数クリックで起動可能です。既存のデータベースインスタンスをアップグレードするためには、AWS Management Console中の”Modify”オプションを選択し、所望のデータベースエンジンバージョンを選択します。本番環境のデータベースをアップグレードする前に、本番環境のデータベースインスタンスのスナップショットからテスト用のデータベースインスタンスのリストアを行い、アップグレード手順やアップグレードにかかる時間の確認とアプリケーションの新しいデータベースバージョンでの互換性を確認することを推薦します。

Amazon RDS for OracleでRCUを利用するための詳細は、Amazon RDS for OracleでOracle Repository Creation Utilityためのステップ・バイ・ステップガイドをご覧ください。SYS objectsへgrant privileges を行う方法については、Oracle DBインスタンスページの Common DBA Tasksページをご覧ください。Amazon RDS for Oracle DBエンジンリリースノートページをご覧頂くことで、更に詳細をご確認頂けます。

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

【AWS発表】新機能:Service Last Accessed Dataからのより詳細な情報取得

昨年末にAWS Identity and Access Management (IAM) で、IAMエンティティ(ユーザー、グループ、ロール)がAWSサービスに最後にアクセスした時刻を表示する機能としてService Last Accessed Dataをリリースしました。この機能は、最小限の権限付与に大きく役立つツールです。

本日、Service Last Accessed Dataの情報が追加され、どの権限を削除できるかをより簡単に識別することができるようになりました。

今回のリリースで、IAMエンティティとポリシーについて次のような情報にアクセスできます:

  • マネージドポリシーやグループに関連付けられている全てのIAMユーザーおよびロールのLast Accessed Data
  • あるIAMユーザー、ロール、グループに対して、サービスの権限を与えている全てのポリシー

これらの追加された詳細データによってアクセスパターンやポリシー構成がより理解しやすくなります。結果として、より良い情報を元に権限管理の決断をくだせます。

この記事では、新しいより詳細なService Last Accessed Dataをウォークスルーし、どのように権限管理をより効果的に行うかについて説明します。

 

マネージドポリシーあるいはグループに関連付けられた全てのIAMユーザーおよびロールの最終アクセス履歴を参照する

 

あなたが、ユーザーやアプリケーションのセキュリティを管理する責任をもつIAMの管理者だと想像して下さい。全ての権限が必要ないIAMユーザーやロールに対して、ポリシーが広すぎる形で適用されていないかどうかを知りたいと思うことでしょう。これまでは、マネージドポリシーのアクセスアドバイザータブでは、サービスがいつ最後にアクセスされたかが表示されていましたが、どのユーザーあるいはロールが最後にアクセスしたのかを特定するためには、AWS CloudTrailのログをサーチする必要がありました。今回の機能によって、次のスナップショットに示すように、エンティティによるアクセス列のリンクをクリックすることにより、どのユーザーあるいはロールがそのサービスに最後にアクセスしたかだけではなく、そのサービスに関連付けられた全てのユーザーやロールがいつ最後にアクセスしたのかをすぐに見ることが出来るようになりました。

 

例えば、次のスクリーンショットは、あるマネージドポリシーで付与されているAmazon EC2の権限についての情報を表示しています。見ての通り、ポリシーをアタッチされている全てのユーザーやロールが実際にEC2にアクセスしているわけではありません。つまり、このユーザーやロールのうちの幾つかは、剥奪可能な過大な権限を持っていることを示しています。

 

あるユーザー、ロール、グループに対してサービスの権限を付与している全てのポリシーを参照する

 

さきほどと同じように、あなたが最小権限の原則を適用しようとしているIAM管理者であることを想像してください。あるユーザーやロールに対するService Last Accessed Dataを参照した後に、ユーザーやロールから必要ないポリシーを削除したりデタッチしたりしたいと思うかもしれません。この手助けとして、ユーザーのアクセスアドバイザータブで、どこで権限が付与されているかをクイックに見るために、ポリシーのアクセス権限内のサービス権限のリンクをクリックして下さい。そうすれば、AWS管理ポリシーやIAMグループから継承されたポリシーが表示されます。ダイアログボックスの中でポリシーの名前をクリックすることでそのポリシーを参照でき、簡単に変更を行うことが出来ます。

 

次のスクリーンショットは、あるIAMユーザーに付与されているEC2に対する権限のソースを示しています。見ての通り、複数のマネージドおよびインラインポリシーが定義されていて、幾つかのポリシーをクリーンナップあるいは統合する事が適切であるということを示唆しています。

 

Service Last Accessed Dataをより詳細に参照できる機能によって、権限管理がより容易になります。より詳細化されたService Last Accessed Dataについてコメントがある方は、下記のコメント欄にお願いします。ご質問のある方は、IAMフォーラムへの投稿をお願い致します。

– Zaher (翻訳はSA布目が担当しました。原文はこちら)

Amazon RDS for PostgreSQLでcross-region read replicaをご利用頂けるようになりました

本日から、ディスク暗号化のされていないAmazon RDS for PostgreSQLデータベースインスタンスでcross-region read replicaをAWS Management Consoleで数クリックするだけで簡単にご利用頂けるようになりました。この機能をご利用頂くことによって、地理的に離れた場所にユーザ向けに読み取りレイテンシを軽減することが可能になったり、ディザスタリカバリ目的でデータベースのバックアップを作成することも可能です。また、簡単にデータベースを他のAWSリージョンに移行することも出来るようになりました。

ディザスタリカバリ: お使いのデータベースのディザスタリカバリ目的でcross-region read replicaをお使い頂けます。万が一、メインでお使いのリージョンがご利用いただけない状態になったと場合、リードレプリカを昇格させることで事業継続を行えます。

スケーリング: cross-region read replicaをご利用頂くことで、地理的に分散した環境で読み取りワークロードを分散することが可能です。こうすることによって、ユーザに近いデータベースから読み取りを行うことでリード遅延を軽減することが可能です。

クロスリージョンマイグレーション: もし他のAWSリージョンに簡単にデータベースを移行したい場合、クロスリージョンレプリケーションをお使い頂くことで作業を軽減出来ます。移行先のリージョンでリードレプリカを作成し、リードレプリカが利用可能になった後に昇格を行い、アプリケーションが新しいマスターデータベースを使うようにアプリケーションの設定を変更します。

この機能は、全てのRDS PostgreSQL( 9.5.2 , 9.4.7以上)データベースでご利用頂けます。このバージョンよりも古いデータベースインスタンスで、こちらの機能をご利用になりたい場合はデータベースのバージョンアップを行う必要があります。RDS PostgreSQLのcross-region replicationの詳細はRDSドキュメントをご覧ください。

翻訳は星野が担当しました。原文はこちら

Amazon RDS for SQL ServerのマルチAZサポートが東京、シドニー、サンパウロリージョンで使用可能になりました!

以下は、「Amazon RDS adds Multi-AZ support for SQL Server in Tokyo, Sydney and Sao Paulo AWS Regions」の翻訳です。

原文:https://aws.amazon.com/jp/about-aws/whats-new/2016/06/amazon-rds-for-sql-server-add-multiaz-support-three-regions/

翻訳:下佐粉 昭 (@simosako)


2016年6月9日発表:

Amazon RDSにおいて、Aazon RDS for SQL ServerのマルチAZデプロイメントサポートを3つのリージョンに追加でご提供を開始いたします。アジアパシフィック (東京) 、アジアパシフィック (シドニー) 、南米 (サンパウロ) のAWSリージョンです。このオプションはSQL Serverをミラーリングする技術によって、エンタープライズグレードのワークロードをSQL Serverで実行したいという要件に適合させることを可能にします。マルチAZデプロイメントオプションは、データを2つのアベイラビリティゾーン(AZ)間で自動的にレプリケーションさせることによって、より高い可用性とデータの耐久性を実現しています。アベイラビリティゾーンは物理的に離れたロケーションに設置され、他のアベイラビリティゾーンの障害から隔離し、独立したインフラとなるよう設計されています。

SQL ServerインスタンスをマルチAZデプロイメントを有効にして起動する、もしくは既存インスタンスをマルチAZデプロイメントに変更した場合、Amazon RDSは自動的にプライマリデータベースを1つのアベイラビリティゾーンに作成し、”スタンバイ”レプリカデータベースを別のアベイラビリティゾーンに設置した上で、それらを同期させます。計画メンテナンスが実行される場合や、予期しないサービス障害が発生した場合、Amazon RDSはSQL Serverを常に最新状態にあるスタンバイデータベースに対して自動的にフェイルオーバーさせます。これにより、データベースのオペレーションを人が介入することなく迅速に復旧させることが可能です。

マルチAZデプロイメントはMicrosoft SQL Server 2008R2と2012のスタンダードエディション(Standard Edition)とエンタープライズエディション(Enterprise Edition)で利用可能です(訳注:SQL Server 2014もサポートされています)。Amazon RDS for SQL ServerのマルチAZによって提供される対障害性機能はSQL Serverをクリティカルなプロダクション環境で稼動する場合に最適です。

Amazon RDS for SQL ServerのマルチAZデプロイメントは、上記リージョン以外にも米国東部 (バージニア北部) 、米国西部 (オレゴン)、欧州 (アイルランド) 、アジアパシフィック (ソウル) の各AWSリージョンで利用可能です。

より詳細な情報はドキュメントの「ミラーリングによる SQL Server マルチ AZ を使用する」をご覧ください。