EC2 シニアプロダクトマネージャーの Taylor Anderson が自動化を利用して AMI メンテナンスとパッチ適用を合理化する方法についてご説明します。-Ana

去年 12 月の re:Invent でリリースした Amazon EC2 Systems Manager では、ソフトウェアインベントリの収集や OS パッチの適用、システムイメージの作成そして Windows や Linux のオペレーティングシステム設定などのプロセスを自動化することができます。こうした機能は自動設定や継続的に行う大規模なシステム管理を自動化し、Amazon EC2 やオンプレミスで実行しているインスタンスのソフトウェアコンプライアンスを維持することができます。Systems Manager には自動化の機能が含まれています。パッチの適用やエージェントの更新、Amazon Machine Image (AMI) にアプリケーションを組み込む場合に、この機能を使用することができます。自動化を使用することで、イメージの更新を手動で行うための時間や労力を省くことができます。代わりに、合理化し繰り返し可能で監査可能なプロセスを通じて AMI を構築することができます。先日、AWS は自動化に関する公開ドキュメントを初めてリリースしました。詳しくは AWS-UpdateLinuxAmi をご覧ください。

このドキュメントは Ubuntu、CentOS、RHEL、Amazon Linux AMI のパッチ適用を自動化できるようしたり、その他のサイト固有のパッケージと設定のインストールも自動化します。さらに、自動化ドキュメントを最初に書く必要を排除することで自動化を取り入れやすくしています。 AWS-UpdateLinuxAmi は、ご自分の自動化ワークフローを構築する場合にテンプレートとして使用することもできます。Windows ユーザーを対象にした、今後公開予定の AWS-UpdateWindowsAmi ドキュメントはこれと同等の内容を提供します。AWS-UpdateLinuxAmi は次のワークフローを自動化します。

1. ソース Linux AMI から一時 EC2 インスタンスを起動
2. インスタンスのアップデート
   • インスタンスでユーザー提供の更新前のフックを起動
   • 可能な場合にインスタンスの AWS ツールやエージェントを更新
   • ネイティブパッケージマネージャを使用してインスタンスのディストリビューションパッケージを更新
   • インスタンスでユーザー提供の更新後のフックを起動 (オプション)
3. 一時インスタンスを停止
4. 停止したインスタンスから新しい AMI を作成
5. インスタンスを終了

警告: 実行中のインスタンスから AMI を作成すると、インスタンスの認証情報、社外秘情報、その他の機密情報が新しいイメージに記録される可能性があります。この方法で作成した AMI を管理する場合は十分な注意が必要です。

自動化のロールおよびアクセス権限の設定

過去に自動化を使用したことがない場合は、IAM ロールとアクセス権限を設定してください。これには自動化のサービス作成、passrole を指定してユーザーがサービスロールを提供できるように承認したり、インスタンスロールを作成して System Manager でインスタンス管理を有効にすることも含まれています。詳細については「自動化用にアクセスを設定する」を参照してください。

自動化を実行

1. EC2 コンソールで [Systems Manager Services] > [Automations] を選択します。
2. [Run automation document] を選択します。
3. [Document name] で [AWS-UpdateLinuxAmi] を選択します。
4. ドキュメントの最新バージョンを選択します。
5. SourceAmiId に Linux AMI の ID を入力して更新します。
6. InstanceIamRole に、インスタンスを管理するために System Manager を有効にして作成したインスタンスロール名を入力します (AmazonEC2RoleforSSM 管理ポリシーを含んでいるもの)。詳細については「自動化用にアクセスを設定する」を参照してください。
7. [AutomationAssumeRole] に、自動化用に作成したサービスロールの ARN を入力します。詳細については「自動化用にアクセスを設定する」を参照してください。
8. [Run Automation] を選択します。
9. [Automation Steps] タブで進捗状況を監視し、ステップレベル出力を確認します。

実行が完了したら [Description] を選択してワークフローが返した出力を確認します。この例では AWS-UpdateLinuxAmi が新しい AMI ID を返しています。次に [Images] > [AMIs] を選択して新しい AMI を確認します。

自動化の使用に追加料金はかかりませんが、ワークフローで作成したリソースにはわずかな料金が発生します。「インスタンス削除」のステップに行く前に AWS-UpdateLinuxAmi を終了すると、ワークフローが作成した一時インスタンスは終了します。上記ステップの CLI チュートリアルについては「自動化 CLI チュートリアル: Linux AMI のパッチ適用」をご覧ください。

まとめ

AWS-UpdateLinuxAmi を問題なく実行できたら、サービスやインスタンスロールのデフォルト値を作成することをおすすめします。AWS-UpdateLinuxAmi をベースに、ご自分の自動化ドキュメントを作成してワークフローをカスタマイズすることができます。詳細については「 自動化ドキュメントの作成」をご覧ください。ドキュメント作成が完了したら追加ステップを書いてワークフローに足すことができます。ステップ例をご覧ください。

• 新しい AMI ID で Auto Scaling を更新 (aws:invokeLambdaFunction アクションタイプ)
• 新しい AMI の暗号化されたコピーを作成 (aws:encrypedCopy アクションタイプ)
• RunPowerShellScript で Run Command を使用して新しい AMI を検証 (aws:runCommand アクションタイプ)

自動化はアプリケーションの組み込みに使う CI/CD パイプラインにとって大きな強化点となります。また、Jenkins で CLI 構築ステップとして呼び出すこともできます。こうした例の詳細については、自動化の技術文書を必ずご覧ください。

自動化、Amazon EC2 Systems Manager、Amazon CloudFormation、AWS Config、AWS OpsWorks やその他の管理サービスの更新については、新しい管理ツールのブログをフォローしてください。

リザーブドインスタンスは AWS のお客様がご利用されている EC2 の使用量に対し、大幅な割引を提供します (オンデマンドの料金に比べ最大 75% の割引)。また、特定のアベイラビリティーゾーン (AZ) で使用する RI を購入される際のキャパシティー予約においても同様です。去年後半には、リージョン内の AZ すべてを対象に割引を適用するリージョン RI をリリースし、今まで以上にリザーブドインスタンスの柔軟性を高めました。また、リザーブドインスタンスに関連付けられたインスタンスファミリーやその他のパラメーターを変更できるようにするコンバーティブル RI も提供しました。どちらのタイプの RI も管理に掛かるコストを削減し、追加オプションを提供します。リージョン RI を使用すると、RI 割引の対象になる AZ で起動することを心配せずにインスタンスをスタートできます。コンバーティブル RI を使用する場合、時間が経過するに連れて選択するインスタンスタイプやサイズが変わっても、RI が使用量に適しているか確認することができます。

インスタンスサイズの柔軟性
3 月 1 日より、すでにご利用されているリージョン RI の柔軟性が今まで以上に高まります。一括請求により、複数のアカウントで使用している場合でも、共有テナンシーを持つすべての Linux/UNIX RI をインスタンスファミリーと AWS リージョン内のあらゆるサイズのインスタンスに適用できるようになりました。これにより、RI の管理時間を節約したり、コンピューティングリソースをよりクリエイティブで革新的に使用できるようになります。新しい RI や既存の RI のサイズはインスタンスサイズに基づいた正規化係数により決定されています。

c4.8xlarge の RI をすでに所有しているとします。この RI はそのリージョン内で共有テナンシーを使用する Linux/UNIX C4 インスタンスで適用されるようになりました。例については次をご覧ください。

• c4.8xlarge インスタンス 1 件
• c4.4xlarge インスタンス 2 件
• c4.2xlarge インスタンス 4 件
• c4.large インスタンス 16 件

また、c4.4xlarge インスタンス 1 件と c4.large インスタンス 8 件といった他の組み合わせも含みます。RI が実行中のインスタンスよりも小さな場合は、オンデマンド料金の日割り計算で余分な容量のコストが請求されます。つまり c4.4xlarge の RI を購入し、大抵の場合そのインスタンスを使用していても、時々 c4.8xlarge インスタンスにスケールアップすることができます。大きいインスタンスには時間単位でオンデマンド料金の半分が請求されます (AWS は可能な限りコストを抑えた状態でお客様がコンピューティング能力にアクセスできるようにすることを目的としています)。大きなインスタンスの RI を所有していて、小さなインスタンスを実行している場合の RI には小さなインスタンスの料金が適用されます。ただし、未使用の予約が蓄積されることはありません。

提供開始
今すぐこの新たな柔軟性をご利用いただけます。これはリージョンの共有テナンシーを使用している Linux/UNIX RI で自動的に適用されます。お客様からの操作は必要ありません。

— Jeff;

AWS re:Invent の初日に、私は EC2 インスタンスの更新に関する投稿で、入手次第、皆様に追加情報をお知らせすることを約束しました。本日は、15 か所の AWS リージョンで 6 つのサイズの新しい I3 インスタンスの提供を開始したことをお知らせします。このインスタンスは入出力量が多いワークロード用に設計されており、きわめて効率が高い NVMe SSD ストレージを備えています。4 KB ブロックで最大 330 万の IOPS を配信し、最大 16 GB/秒のシーケンシャルディスクスループットを実現します。このため、リレーショナルデータベース、NoSQL データベース、検索エンジン、データウェアハウス、リアルタイム分析、ディスクベースのキャッシュなど、高スループットと低レイテンシーを必要とするあらゆるワークロードに最適です。I3 インスタンスは、I2 インスタンスと比較すると、低コストで高密度のストレージを提供し、CPU コアあたりの IOPS とネットワーク帯域幅も大幅に増えます。

仕様
インスタンスサイズと関連仕様は次のとおりです。

上記の料金は US East (Northern Virginia) リージョンでのオンデマンドインスタンスの場合です。詳細については、EC2 料金表ページを参照してください。I3 インスタンスは、US East (Northern Virginia)、US West (Oregon)、US West (Northern California)、US East (Ohio)、Canada (Central)、South America (Brazil)、Europe (Ireland)、Europe (London)、Europe (Frankfurt)、Asia Pacific (Singapore)、Asia Pacific (Tokyo)、Asia Pacific (Seoul)、Asia Pacific (Mumbai)、Asia Pacific (Sydney)、および AWS GovCloud (US) リージョンで、オンデマンド、リザーブド、およびスポット形式でご利用できます。また、これらを専有ホストおよびハードウェア専有インスタンスとして使用することもできます。これらのインスタンスはハードウェア仮想化 (HVM) AMI のみをサポートしており、仮想プライベートクラウド内で実行する必要があります。NVMe ストレージによって可能になったパフォーマンスの利点を得るには、次のいずれかのオペレーティングシステムを実行する必要があります。

• Amazon Linux AMI
• RHEL – 6.5 以降
• CentOS – 7.0 以降
• Ubuntu – 16.04 または 16.10
• SUSE 12
• SP3 を使用する SUSE 11
• Windows Server 2008 R2、2012 R2、および 2016

I3 インスタンスでは最大 8 個の NVMe SSD が提供されます。最善のスループットを実現し、可能な限り多くの IOPS を取得するには、複数のボリュームを一緒にストライプ化するか、別の方法で I/O ワークロードをボリューム間で分散します。各 vCPU (仮想 CPU) は、2.3 GHz で実行する Intel E5-2686 v4 (Broadwell) プロセッサ上のハードウェアハイパースレッドです。このプロセッサは、Turbo Boost と NUMA とともに、AVX2 手順をサポートします。

提供開始
I3 インスタンスは 15 か所の AWS リージョンで利用可能になり、今すぐ使用を開始できます。

— Jeff;

お客様からビジネスのダイナミックさと、それを実現するためのアプリケーションがブロックストレージに求めるものについてご意見をうかがうことは、いつも興味深いものです。ビジネス状況の変化に伴ってブロックストレージへの要求も変化し、容量を追加したり、性能特性の異なるボリュームが必要になったりすることもあるはずです。今日では、24時間運用され続けるシステムも珍しくはありません。結果として、ダウンタイムやシステム運用への影響なく変更作業を行えることがお客様にとって重要な要素となってきます。

我々は長年にわたり、お客様の様々なユースケースをカバーするために、EBSに新機能を追加し続けてきました。例えば、2016年にはスループット最適化HDD(st1)とコールドHDD(sc1)という2種類のボリュームタイプをリリースしました。これらのボリュームをシステム運用への影響なく、パフォーマンス特性の変更やコスト削減を行うことで、階層化ストレージのように利用したいと考えるお客様がいらっしゃいます。言い換えると、お客様はEBSがより柔軟になることを望んでいるのです！

エラスティックボリューム
本日、EBSの新機能としてエラスティックボリュームをリリースいたしました。これは現行世代のEC2インスタンスにアタッチされた、全ての現行世代のEBSボリュームで利用可能です。お客様はボリュームサイズの拡張、パフォーマンスの調整、ボリュームタイプの変更を利用中に行うことができます。変更処理はオンラインで行われますので、お客様のアプリケーションは引き続き利用可能でダウンタイムはありません。

この新機能はリソース計画やチューニング、空き容量の管理といった作業を劇的にシンプル化してくれます。あるいは作業自体が不必要になるかもしれません。従来のやり方はダウンタイムを伴うため、変更の完了までプランニングやシステム停止の調整を含めると数週間から数ヶ月にわたる時間が必要でした。しかしこれからは、利用しているストレージインフラストラクチャをシンプルなAPIコールで簡単に変更することが可能になります。

• ワークロードの変化 – インフラ構築を急ぐ必要があり、汎用SSDボリュームを採用することにしました。システムをリリースし、運用を行っていくにつれて、スループット最適化HDDボリュームが最適であることに気づいたとしましょう。エラスティックボリュームの機能により、単純にボリュームタイプを変更するだけで対応が完了します。
• 突発的な需要への対応 – プロビジョンドIOPSボリューム上に構築したリレーショナルデータベースで、1ヶ月のほとんどの期間にわたり問題なく処理を行えるシステムがあります。ただし月末処理の関係で各月終わりの3日間は10倍のトラフィックを処理する必要があったとします。この場合は、エラスティックボリュームを利用して月末の3日間だけIOPSを高く設定し、処理が終わったら元に戻すという運用が可能です。
• ストレージの増加 – 100GBのボリュームで運用してきたシステムで、ディスク使用率が90%を超過したというアラームが発報しました。あらかじめ設定を行っておけば、ボリュームとファイルシステムの拡大を自動的にダウンタイム無しで行うこともできます。

エラスティックボリュームの利用

お客様はこれら全ての操作をAWSマネジメントコンソールやAPIコール、AWSコマンドラインインタフェース(CLI)で実行できます。これに加えて、AWS CloudFormationのスタック更新機能を利用することも可能で、対象のボリュームに必要な変更を行ってくれます。コンソールを利用する場合は、対象のボリュームを選択してアクションメニューから「Modify Volume」を選択するだけです:

ポップアップするウィンドウの中で、ボリュームタイプやサイズ、IOPS値(プロビジョンドIOPSボリュームの場合)を変更してください。これは75GBの汎用SSDボリュームを、20,000IOPSで400GBのプロビジョンドIOPSボリュームに変更する例です:

変更ボタンをクリックしたら、確認ウィンドウが表示されるので問題が無ければ「YES」をクリックします:

ボリュームの「状態」に変更処理の進捗状況(modifying、optimizing、completed)が表示されます:

次のステップは追加されたストレージ領域を利用できるようにするために、ファイルシステムを拡張することです。作業の詳細についてはLinuxでEBSボリュームのストレージ領域を拡張するかWindowsでEBSボリュームのストレージ領域を拡張するを参照してください。ボリュームの状態が最適化中に変わったら(通常数秒で変わります)、ファイルシステムの拡張作業を行うことができます。新しいボリュームの容量やタイプはすぐに利用可能になりますが、最適化の処理は最大で24時間を要する場合があります。コストについて補足すると、ボリュームの状態がoptimizingになったタイミングで新構成を基準に計算されることになります(変更自体のコストはかかりません)。

エラスティックボリュームの自動オペレーション
手動オペレーションでの変更も充分に魅力的ですが、自動化を行うたくさんのチャンスがあります。いくつかのアイデアをお見せしてみましょう:

• 正しいサイジング – IOPS上限か、それに近いレベルに到達しているかをCloudWatchで監視しアラームを上げるよう設定します。アラームが上がったらIOPS値の増加や、ボリュームタイプの変更を行うための承認プロセスを開始し、変更作業の準備を進めます。同様にCloudWatchのカスタムメトリクスを利用して空き容量をモニタリングして、拡張のための承認プロセスを開始することもできます。
• コストの削減 – CloudWatchメトリクスや予め設定したスケジュールに従ってIOPSの削減やボリュームタイプの変更を行います。（背景：先週、大学のセキュリティ管理者と会話する機会がありました。彼は学内の全てのサーバから1日に10GBのログを収集し、60日間に渡って保持するという仕事をしています。ほとんどのファイルは参照されることはなく、参照が必要になったときでもアクセス速度はそれほど求められません。この場合、1日分のログを書き込むための汎用SSDボリュームを作成し高速な書き込みを実施し、完了したらスループット最適化HDDに変更することでコストを最適化することができます。）

先にお伝えしたように、新たに追加された領域を利用できるようにするためにはファイルシステムをリサイズする必要があります。この手順をお見せするために、私の同僚がCloudWatch Events、AWS Lambda、EC2 Systems Managerを利用したPythonとPowerShellのサンプルスクリプトを提供してくれました。このルールはEBSから送信される情報に基づきmodifyVolumeというイベントにマッチし、logEventsというLambdaファンクションを起動します:

このファンクションは対象となるボリュームを特定し、これがEC2 Systems Managerで管理されるインスタンスにアタッチされていることを確認したうえでメンテナンス用のタグ情報を付与します:

def lambda_handler(event, context):
    volume =(event['resources'][0].split('/')[1])
    attach=ec2.describe_volumes(VolumeIds=[volume])['Volumes'][0]['Attachments']
    if len(attach)>0: 
        instance = attach[0]['InstanceId']
        filter={'key': 'InstanceIds', 'valueSet': [instance]}
        info = ssm.describe_instance_information(InstanceInformationFilterList=[filter])['InstanceInformationList']
        if len(info)>0:
            ec2.create_tags(Resources=[instance],Tags=[tags])
            print (info[0]['PlatformName']+' Instance '+ instance+ ' has been tagged for maintenance' )

その後に、EC2 Systems Managerがメンテナンス用のタグが付与された全てのインスタンスでPowerShellスクリプトを起動します。このスクリプトはインスタンスのディスクとパーティションの情報を参照し、拡張を必要とする全てのドライブとファイルシステムについて、許容可能な最大サイズまで拡張を行います。以下がスクリプトの抜粋です:

foreach ($DriveLetter in $DriveLetters) {
	$Error.Clear()
        $SizeMax = (Get-PartitionSupportedSize -DriveLetter $DriveLetter).SizeMax
}

本日からご利用頂けます
エラスティックボリュームの機能は本日今すぐにご利用頂くことができます！特殊なケースにおける例外や、制約についてはドキュメント(本記事執筆時点では英語版)をご確認ください。

— Jeff;
(日本語版はSA小林が翻訳しました。原文はこちら)

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 酒徳が担当しました。原文はこちらです。

Matt Wood の投稿
当社は Alexa から Amazon Go まで Amazon のすべての領域でディープラーニングを広範に使用し、これまで多くのディープラーニングエンジンを試してきました。そして 1 つのエンジンがディープラーニングを実行するための最もスケーラブルで効率的な方法として出現しました。その理由により、Amazon のエンジンとして MXNet が選択されました。MXNet はオープンソースの最新鋭のディープラーニングエンジンであり、これにより開発者は高度なカスタム人工知能システムを構築することができます。

このようなシステムのトレーニングは、そのスケールとパフォーマンスにより、MXNet では著しく高速です。たとえば、よく使用される画像認識ネットワークの Resnet では、MXNet は他のエンジンと比較して 2 倍のスループットを実現し、同等のモデルを半分の時間でトレーニングできます。また、MXNet は数百の GPU にわたって線形に近いスケーリングを示しますが、他のエンジンのパフォーマンスでは、規模に見合った増加は見られません。

Amazon には重要なチームがあり、MXNet コミュニティと連携して、この進化に継続的に取り組んでいます。チームは MXNet に対して Apache Incubator に参加し、Apache Software Foundation のプロセス、財産管理、支援活動、およびコミュニティイベントを活用することを提案しました。幸い、この提案は受け入れられました。Apache MXNet への投資は開始点にあり、当社はコミュニティと連携して既に重要になっているユーティリティを拡大していくことを楽しみにしています。MXNet の使用開始を希望される場合は、AWS Re:Invent で私が行った基調講演をご覧になり、AWS ディープラーニング AMI のインスタンス (またはクラスター全体) を起動してください。これには MXNet と、プリコンパイルされ、すぐに使用できるサンプルコードが含まれています。また、推奨モデリングに関する Leo のプレゼンテーションとチュートリアルもご覧ください。

Twitter で @apachemxnet をフォローするか、オープンソースプロジェクトの更新について新しい Apache MXNet ページを参照してください。

2016年末最後の数秒をカウントダウンする場合は、最後に1秒を追加するのを忘れないようにしてください！

次回のうるう秒（通算27回目）が、UTC（世界標準時）の2016年12月31日 23:59:60として挿入されます（訳注：日本標準時では2017年1月1日 8:59:60になります）。これは地球上での時刻（協定世界時）と太陽時（天文時）とのずれを小さくするために行われ、この結果、UTCでは今年最後の1分は61秒あることになります。

• 参考）「うるう秒」挿入のお知らせ（総務省）

前回のうるう秒の際に出した情報（事前にご確認ください – AWSでのうるう秒対応）は引き続き有効で、今回も同様に処理されますが、少しの違いと進展があります:

AWS調整時刻（AWS Adjusted Time） –うるう秒挿入前後の24時間の期間にわたって、うるう秒の1秒を少しずつ分散します（UTCで12月31日の11:59:59から、2017年1月1日12:00:00まで）。AWS調整時刻と協定世界時はこの期間が終了後に同期します。（訳注：この期間の１秒をごくわずかに遅くすることで、追加される１秒を長い時間のなかに分散する方法であり、これは前回うるう秒挿入時と同じ挙動です。詳しくは前回の情報をご確認ください。）

Microsoft Windows – Amazonによって提供されたMicrosoft WindowsのAMIを利用しているインスタンスは、AWS調整時刻に従います。

Amazon RDS – 大多数のAmazon RDS インスタンスは （UTCで設定されている場合）“23:59:59” を2回記録します。しかし、Oracle 11.2.0.2、11.2.0.3、12.1.0.1 はAWS調整時刻に従います。Oracle 11.2.0.4と12.1.0.2について詳細な情報が必要な場合はAWSサポートにお問い合わせください。

サポートが必要ですか？
このうるう秒挿入についてご質問がある場合は、AWSサポートにコンタクトいただくか、EC2フォーラムにポストしてください。

— Jeff;

翻訳：下佐粉　昭（@simosako）

原文：https://aws.amazon.com/blogs/aws/look-before-you-leap-december-31-2016-leap-second-on-aws/

去年、EC2 Run Command をご紹介して、最初に EC2 インスタンスで、次いでハイブリッドおよびクラウド間の環境で大規模なリモートのインスタンス管理をするための使い方をご説明しました。その過程で、Linux インスタンスのサポートを追加したため、EC2 Run Command は幅広く応用できる非常に便利な管理ツールになりました。

ファミリーへようこそ
Werner が EC2 Systems Manager を AWS re:Invent で発表したので、ついにお話しできるようになりました。これは、同じように便利な 8 つの機能と共に EC2 Run Command の強化版を含む新しい管理サービスです。EC2 Run Command と同様に、Windows と Linux を実行するインスタンスとサービスで構成されたハイブリッドおよびクラウド間の環境をサポートします。AWS Management Console を開き、管理するインスタンスを選択して、実施するタスクを定義します (API および CLI のアクセスも可能)。機能拡張と新機能の概要を次に示します。

Run Command – コマンドの実行速度を制御し、エラー率が高くなりすぎたときにコマンドの発行を停止できるようになりました。
State Manager – 定期的に適用される、ポリシーで定義されたシステム設定を維持します。
パラメーターストア – ライセンスキー、パスワード、ユーザーリスト、その他の値の一元管理型 (オプションで暗号化された) ストレージを提供します。
メンテナンス時間 – 更新のインストール、その他のシステムメンテナンスの時間枠を指定します。
ソフトウェアインベントリ – 各インスタンスから、詳細なソフトウェアおよび設定のインベントリ (ユーザー定義の追加を含む) を収集します。
AWS Config 統合 – 新しいソフトウェアインベントリ機能との組み合わせで、AWS Config は、ソフトウェアインベントリの変更をインスタンスに記録できます。
パッチ管理 – インスタンスのパッチ適用プロセスを簡略化および自動化します。
自動化 – AMI の構築およびその他の継続的な AMI に関連するタスクを簡略化します。それぞれについて見てみましょう。

Run Command の改善
同時コマンドの実行回数を制御できるようになりました。これは、コマンドリファレンスが内部更新やパッチサーバーのような共有の限定リソースであり、多すぎるリクエストによるオーバーロードを避けたい場合、役立ちます。この機能は現在 CLI および API からアクセスできます。同時実行数を 2 に制限する CLI の例を示します。

$ aws ssm send-command \
  --instance-ids "i-023c301591e6651ea" "i-03cf0fc05ec82a30b" "i-09e4ed09e540caca0" "i-0f6d1fe27dc064099" \
  --document-name "AWS-RunShellScript" \
  --comment "Run a shell script or specify the commands to run." \
  --parameters commands="date" \
  --timeout-seconds 600 --output-s3-bucket-name "jbarr-data" \
  --region us-east-1 --max-concurrency 2

タグやタグ値によるさらに興味深い形式があります。 --targets を次の代わりに指定 --instance-ids:

$ aws ssm send-command \
  --targets "Key=tag:Mode,Values=Production" ... 

オプションでエラーの上限や失敗率を指定して、エラーが返ってくる場合にコマンドの発行を停止することもできます。

$ aws ssm send-command --max-errors 5 ... 
$ aws ssm send-command --max-errors 5% ...

State Manager
State Manager は、インスタンスをドキュメントにより定義されたとおりの定義済みの状態に保つのに役立ちます。ドキュメントを作成し、それをターゲットインスタンスのセットに関連付けてから、ドキュメントが適用されるタイミングと頻度を指定する関連付けを作成します。Message of the Day ファイルを更新するドキュメントを示します。

そして、これが関連付けです (現在のインスタンス、および後で起動され、同じようにタグ付けされる他のインスタンスに適用されるようタグを使用)。

タグを使用してターゲットを指定することにより、将来も関連付けに十分対応できるようになり、動的なオートスケールの環境で期待どおりに機能するようになります。関連付けをすべて表示することが可能です。また、新しい関連付けを選択し、[Apply Association Now] をクリックすることにより新しい関連付けを実行することができます。

パラメーターストア
この機能はインスタンスに分散するライセンスキー、パスワード、その他のデータのストレージと管理を簡略化します。各パラメータには型 (文字列、文字列リスト、安全な文字列) があり、暗号化された形式で格納できます。パラメータの作成方法を示します。

そして、次がコマンドでのパラメータの参照方法です。

メンテナンス時間
この機能により、更新のインストールおよび他のシステムメンテナンスの時間枠の指定ができます。毎週土曜日 4 時間の時間枠を設ける方法は次の通りです。

時間枠を作成してから、インスタンスのセットを割り当てる必要があります。インスタンス ID またはタグを使用して行うことができます。

次にメンテナンスの時間帯に実行するタスクを登録する必要があります。たとえば、Linux シェルスクリプトを実行できます。

ソフトウェアインベントリ
この機能は一連のインスタンスのソフトウェアおよび設定についての情報を収集します。アクセスするには、[Managed Instances]、[Setup Inventory] をクリックします。

インベントリのセットアップは、AWS が所有するドキュメントとインスタンスのセットとの間に関連付けを作成します。 ターゲットを選択し、スケジュールを設定し、インベントリを実行する項目のタイプを特定してから、[Setup Inventory] をクリックします。

インベントリを実行後、インスタンスを選択してから [Inventory] タブをクリックして結果を確認します。

詳細な分析用に結果をフィルタリングすることができます。たとえば、開発ツールとライブラリのみを表示するために、AWS コンポーネントのリストを絞り込むことができます。

また、インベントリによるクエリをすべてのマネージドインスタンスに対して実行できます。4.6 より前のバージョンの .NET を実行している Windows Server 2012 R2 インスタンスを見つける方法は次のとおりです。

AWS Config 統合
インベントリの結果を AWS Config にルーティングして、アプリケーション、AWS コンポーネント、インスタンス情報、ネットワーク設定、および Windows アップデートの変更を継続して追跡することができます。この情報にアクセスするには、インスタンスの Config タイムライン上の [Managed instance information] をクリックします。

下部に表示される 3 行は、インベントリ情報へつながっています。以下にネットワーク設定を示します。

パッチ管理
この機能は、Windows インスタンスのオペレーティングシステムを最新の状態に保つのに役立ちます。パッチは、定義したメンテナンス時間中に適用され、ベースラインに対して実行されます。ベースラインは、分類または重大度に基づいてパッチを自動的に承認するためのルールと、承認または拒否するパッチの明示的なリストを指定します。私のベースラインを次に示します。

各ベースラインは 1 つ以上のパッチグループに適用できます。パッチグループ内のインスタンスには、[Patch Group] タグがあります。 私のグループに Win2016 という名前をつけました。

それから、値をベースラインに関連付けます。

次のステップでは、AWS-ApplyPatchBaseline ドキュメントを使用して、メンテナンス時間中にパッチを適用できるようにします。

マネージドインスタンスのリストに戻って、フィルタのペアを使用し、どのインスタンスにパッチが必要かを調べることができます。

自動化
最後に大切な点ですが、自動化機能は一般的な AMI の構築および更新タスクを簡略化します。たとえば、AWS-UpdateLinuxAmi のドキュメントを使用して、毎月新しい Amazon Linux AMI を構築することができます。

この自動化を実行すると、次のようになります。

今すぐ利用可能
このブログで紹介した EC2 Systems Manager のすべての機能は今日から無料でご利用いただけます。管理したリソースに対してのみ料金を支払います。

— Jeff;

インターネットは、特にモバイルアプリケーション、コネクテッドデバイス、そしてIoTの分野で引き続き成長しており、それが業界全体のIPv6への移行に拍車をかけています。米国政府機関は2010年に定められた指令に従って、パブリックに公開されたサーバーとサービスをできるだけすみやかにIPv6に移行するように取り組んでいます。128ビットのアドレス空間を持つIPv6では十分な拡張の余地があり、新しいアプリケーションやユースケースへの道が開かれます。

EC2のIPv6

今年の初めに、S3 (Transfer Accelerationを含む)、CloudFront、WAF、および Route 53のIPv6サポートを開始しました。本日、新しい大きなステップとして、Virtual Private Cloud (VPC) およびEC2インスタンスのIPv6サポートを開始しました。米国東部 (オハイオ) リージョンを皮切りに、他のリージョンも対応を進めていきます。

IPv6サポートは、新規および既存のVPCで利用できます。マネジメントコンソール上でチェックボックスにチェックを入れるだけで、VPCごとにオプトインすることができます (APIとCLIもサポートされます)。

(more…)

AWSのお客様はT2インスタンスを使う時に得られるコスト効率のよい、バーストベースのモデルを好まれています。これらのお客様は webサーバや開発環境、継続的なインテグレーション用のサーバ、テスト環境、そして小さなデータベース等の一般的な用途でのワークロードを動作させるのにT2インスタンスを使います。これらのインスタンスは豊富なベースラインパフォーマンスと、必要に応じてフルコアのプロセッシングパワーにまで透過的にスケールアップを提供します。（もしこちらがあなたにとって新しいニュースであれば、バースト可能な性能を持つ新しい低コストEC2インスタンスをご参照ください）

本日２つの新しいより大きなT2インスタンスサイズを追加します。- 16GiB メモリの t2.xlargeと32GiB メモリのt2.2xlarge です。これらの新しいサイズにより、お客様はより大きなリソースの要件のアプリケーション向けに T2のバーストモデルの価格とパフォーマンスのメリットを享受頂けます。（t2インスタンスのレンジを拡大するのは、今回が3度目になります；昨年の6月にt2.largeを、昨年の12月にt2.nanoを追加しました。

こちらがT2インスタンスのすべてのサイズ向けのスペックになります。（価格は最近のEC2の値下げを反映しています。US Eastリージョンの料金になります。）

既存のワークロードを新しいインスタンスへ移行できる可能性のある方法がこちらになります。

• t2.largeのワークロードで、より多くのメモリを得るためにt2.xlargeまたはt2.2xlargeへスケールアップ可能
• c4.2xlargeの断続的なワークロードをt2.xlargeへ移行することで、近いバーストパフォーマンスにて、わずかにコスト削減が可能
• m4.xlargeの断続的なワークロードをt2.xlargeへ移行することで、より高いバーストパフォーマンスにて、わずかにコスト削減が可能

新しいインスタンスはすべてのAWSリージョンにてオンデマンドおよびリザーブドインスタンスとして本日から利用可能です。

–Jeff
翻訳は舟崎が担当しました。原文はこちらです。