Amazon Web Services ブログ

コストアロケーションタグがAmazon DynamoDBに対応しました

by AWS Japan Staff | on | in Amazon DynamoDB |

Amazon DynamoDBのテーブルにタグを設定可能になりました。タグは多くのAWSサービスでサポートしている、シンプルでユーザがカスタマイズ可能なキー・バリューのペアです。DynamoDBのタグ対応は DynamoDBの利用料金の可視化に有効です。テーブル毎にタグを設定でき、タグ毎に料金を参照出来ます。

様々な環境(development/staging/production)で複数のDynamoDBテーブルを持っているシナリオを例に上げてご説明します。DynamoDBテーブルにタグを設定出来ます。例として、keyにEnvironment、valueにDevelopment, Staging, Productionとそれぞれ設定します。

DynamoDBコンソールでどのように設定するか見ていきましょう。設定を行う前にListTagsOfResourceとTagResourceのAPI操作を行う適切な権限を持っているか確認をして下さい。

  1. AWS Management Consoleにサインインをし、https://console.aws.amazon.com/dynamodb/からDynamoDBコンソールを開きます
  2. Tablesを選択し、設定を行ないたいテーブルを選択します
  3. Settingsタブで、Tagsをナビゲーションメニューから選択します
  4. Add Tagsセクションで、KeyにEnvironment、ValueにDevelopmentを入力し、Apply Changesをクリックします

Settings

標準の動作では、新しく追加されたキーはbillingでは無効化されています。以下の手順でBilling Consoleよりアクティベートを行えます:

  1. AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます
  2. ナビゲーションメニューからCost Allocation Tagsを選択します
  3. User-Defined Cost Allocation Tagsセクションから、タグキー内の Environmentタグ横のチェックボックスを選択し、Activateをクリックします

CostAllocationTags

アクティベート済みのコストアロケーションタグがある場合、AWS Cost Explorerからタグ付けされたAWSリソースのコストを簡単にブレークダウンして閲覧出来ます:

  1. AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます
  2. ナビゲーションメニューからCost Explorerを選択し、Launch Cost Explorerを選択します
  3. 左上のメニューからMonthly costs by serviceを選択し、右のメニュー内の Time rangeから閲覧したいタイムレンジを指定します
  4. Filteringセクション内のFilter byからTagを選択します
  5. タグキーのオートコンプリートフィールドから Environmentを選択、Developmentをタグバリューのオートコンプリートセクションから選択し、Applyをクリックします

Filtering

指定したタグ(Environment=Development)でコストがフィルタリングされます。コストはタグをAWSリソースに指定した時点から表示されます

SaveReport

DynamoDB Management Console, AWS CLIやAWS SDKからDynamoDBテーブルに50個までタグを設定出来ます。DynamoDBテーブルに設定されている、Global secondary indexes (GSIs) と local secondary indexes (LSIs)にもDynamoDBテーブルで設定したタグが自動的に設定されます。DynamoDBのタグサポートは全てのAWSリージョンで利用可能です。

更に詳細な、AWSリソースでのタグの活用はこちらをご覧下さい。

— Nitin Sagar(product manager for DynamoDB) (翻訳は星野が担当しました。原文はこちら)

RDS MySQL DBインスタンスからAmazon Aurora Read Replicaを作成可能になりました

by AWS Japan Staff | on | in Amazon Aurora, Amazon RDS |

24時間365日稼働しているアプリケーションが利用しているデータベースエンジンを他のデータベースエンジンに移行するにはいくつかの方法を使う必要があると思います。データベースをオフラインにせずに移行する良い方法として、レプリケーションを利用する方法があります。

本日、Amazon RDS DB for MySQLインスタンスを Amazon AuroraにAurora Read Replicaを作成して移行する機能をリリースしました。マイグレーションは、まず既存のDBスナップショットを作成し、そこからAurora Read Replicaを作成します。レプリカのセットアップが完了後、ソースデータベースとのレプリケーションの設定を行い最新のデータをキャッチアップします。レプリケーションラグが0になればレプリケーションが完了した状態です。この状態になった後に、 Aurora Read Replicaを独立したAurora DB clusterとして利用可能で、アプリケーションの設定を変更しAurora DB clusterに接続します。

マイグレーションはテラバイトあたり数時間かかります。また、6TBまでのMySQL DBインスタンスに対応しています。InnoDBテーブルのレプリケーションはMyISAMテーブルのレプリケーションよりもやや高速で、圧縮されていないテーブルの利点も受けられます。

RDS DBインスタンスをマイグレーションするためには、 AWS Management ConsoleからRDSのコンソールを選択し、Instance Actionsを選択します。その後、Create Aurora Read Replicaを選択するだけです:

rds_migrate_aurora_pick_src

そして、データベースインスタンスの情報やオプションを入力し、Create Read Replicaをクリックします:

rds_migrate_setup_aurora

コンソール上でマイグレーションの進捗状況を閲覧出来ます:

rds_migrate_progress

マイグレーション完了後、Aurora Read Replicaでレプリカラグが0になるのを待ちます(SHOW SLAVE STATUSコマンドをレプリカで実行し、“Seconds behind master”を監視します)。その後、ソースのMySQL DBインスタンスへの新しいトランザクションを停止し、Aurora Read ReplicaをDBクラスタに昇格させます:

rds_aurora_pick_promote
新しいクラスタが利用可能になるまで待機します(通常は1分程度):

rds_aurora_new_cluster

最後に、アプリケーションの設定をクラスタのread/writeエンドポイントを利用するように設定し完了です!

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

Amazon Aurora Clusterに監査機能を追加

by AWS Japan Staff | on | in Amazon Aurora, Amazon RDS |

re:InventでMySQLデータベースと互換性があり、コマーシャルデータベースの性能と可用性、オープンソースデータベースのコストパーフォーマンスの両面をそなえた、Amazon Auroraの新機能を発表しました。

今日、advanced auditing機能が全てのお客様にご利用頂けるようになったことを発表致します。

advanced auditingとは

Auditingとは特定のイベントを収集して手動もしくは他のアプリケーションで分析出来るように提供する機能を指します。これらのログはコンプライアンス規定やガバナンスのベースになる情報として利用可能です。advanced auditingの例には、ログ分析、ユーザーアクションの監査(過去のイベントおよび、ニアリアルタイムの脅威検出など)、セキュリティ関連のイベントに設定されたアラームのが含まれます。 Auroraのadvanced auditing機能は、データベースのパフォーマンスに与える影響を最小限に抑えながら、これらの機能を提供するように設計されています。

advanced auditingを利用するには

まずはじめに、advanced auditingを有効にし、audit logを参照します。

advanced auditingの有効化

DBクラスタパラメータグループにあるパラメータを設定することでadvanced auditingの有効化や設定を行うことができます。これらのパラメータの変更がDBクラスタの再起動は必要ありません。また、動作は Aurora DB instance parametersと同様です。

機能を有効/無効化するために server_audit_loggingパラメータを利用します。server_audit_eventsパラメータでどのイベントをログに記録するか設定します。

server_audit_excl_usersserver_audit_incl_usersパラメータでどのユーザを監査対象にするか設定可能です:

  • server_audit_excl_usersとserver_audit_incl_usersが未指定の場合(デフォルト値)は全てのユーザが記録されます
  • server_audit_incl_usersにユーザを設定し、server_audit_excl_usersを指定しない場合、server_audit_incl_usersに指定したユーザのみ記録されます
  • server_audit_excl_usersにユーザを設定し、server_audit_incl_usersを指定しない場合、server_audit_excl_usersに指定したユーザ以外が記録の対象になります
  • server_audit_excl_usersとserver_audit_incl_usersに同一のユーザを設定した場合は、server_audit_incl_usersの優先度が高いため記録の対象になります

advanced auditingのパラメータの詳細を以下でご説明します

server_audit_logging 監査ログの有効/無効化を指定します。標準ではOFFになっているので、ONに指定することで有効になります

  • Scope: Global
  • Dynamic: Yes
  • Data type: Boolean
  • Default value: OFF (disabled)

server_audit_events イベントのリストをカンマで区切って指定します。リスト中のエレメント間にスペースは入れなように気をつけて下さい

  • Scope: Global
  • Dynamic: Yes
  • Data type: String
  • Default value: Empty string
  • 有効な値: 以下のイベントの好きな組み合わせを指定可能
    • CONNECT – ユーザ情報を含む、接続の成功・失敗・切断を記録
    • QUERY – シンタックスや権限不足で失敗したクエリを含む、全てのクエリ文字列とクエリの結果をplane textで記録
    • QUERY_DCL – DCLクエリのみを記録 (GRANT, REVOKEなど)
    • QUERY_DDL – DDLクエリのみを記録 (CREATE, ALTERなど)
    • QUERY_DML – DMLクエリのみを記録 (NSERT, UPDATEなど)
    • TABLE – クエリの実行で利用されたテーブルを記録

server_audit_excl_users ログに記録しないユーザをカンマ区切りで指定します。エレメント間にスペースは入れないよう気をつけて下さい。接続・切断のイベントはこの設定に影響を受けないため記録されます。server_audit_excl_usersに指定されていたとしてもserver_audit_incl_usersにも指定されていた場合は、server_audit_incl_usersの優先度が高いため記録の対象になります

  • Scope: Global
  • Dynamic: Yes
  • Data type: String
  • Default value: Empty string

server_audit_incl_users ログに記録するユーザをカンマ区切りで指定します。エレメント間にスペースは入れないよう気をつけて下さい。接続・切断のイベントはこの設定に影響を受けません。ユーザがserver_audit_excl_usersに指定されていたとしても、server_audit_incl_usersの優先度が高いため記録の対象になります

  • Scope: Global
  • Dynamic: Yes
  • Data type: String
  • Default value: Empty string

audit logを参照する

AWS Management Consoleからaudit logを参照可能です。Instancesページから、DBクラスタを選択し、Logを選択します。

audit-log

MariaDB Audit Pluginの事をご存知であれば、auditingについてAuroraが取っているアプローチとの幾つかの違いに気づくかと思います。

  • Aurora advanced auditingのタイムスタンプはUnix timeフォーマットで記録されます
  • イベントは複数のログファイルに記録され、ログはシーケンシャルには並んでいません。必要に応じてファイルの結合やタイムスタンプやquery_idを使用してソートを行えます。Unixをお使いの場合は以下のコマンドで実現出来ます。 cat audit.log.* | sort -t”,” -k1,1 –k6,6
  • ファイル数はDBインスタンスサイズに応じて変化します
  • ファイルのローテーションは100MB毎に行われ、閾値の変更は行なえません

MySQLからマイグレーションした後のAurora advanced auditingの有効化は方法が異なります。 Audit logの設定はDBクラスタ向けのパラメータグループで行ないます。

Auroraがどのようにadvanced auditingを実装したか

監査機能はコマーシャルデータベスでもオープンソースデータベース一般的に利用出来る機能です。この機能は一般的にパフォーマンスへ大きな影響を与えます。特にデータベースの利用率が高い場合は顕著です。Auroraでの実装の1つのゴールは様々な情報をパフォーマンスの犠牲なくユーザに提供することです。

パフォーマンスを維持するために

パフォーマンスの課題をどの様に解決したか理解するために、私達のadvanced auditingの実装とMariaDB Audit Pluginの実装を比較してみます。MySQL Community Editionではnative audit logを提供していないため、私たちは比較のためにこちらを利用します。そして、 MariaDB Audit Pluginはオープンソースコミュニティの中で、これらの制約を埋める一般的なオプションとしてあげられます。

MariaDB Audit Pluginは、シングルスレッドでシングルミューテックスを処理と各イベントの書き出しに利用します。このデザインは、ログの書き出しのボトルネックに起因するパフォ=マンスの低下を起こしますが、イベントの順序を厳密に保存することが出来ます。もし、このアプローチをAuroraに利用すると、データベースエンジンの期待するスループットや高いスケーラビリティにより、パフォーマンスへのインパクトが更に大きくなってしまいます。

高いパフォーマンスを維持するために、イベント処理とイベントの書き出しロジックを再設計しました。入力面では、ラッチフリーキューを他のスレッドをロックすること無くaudit logを保存するために利用しました。出力面では、ラッチフリーキューから複数のファイルへイベントを書き出すためにマルチスレッドモデルを利用しています。このファイルを処理することで、イベント順に並んだ1つの監査ログとして生成出来ます。

advanced-auditing-how

ログフォーマット

audit logは各インスタンスのローカル(エフェメラル)ディスクに保存されます。各Auroraインスタンスは4つのログファイルに書き込みます。

  • Encoding: UTF-8
  • ファイル名パターン: audit.log.0-3.%Y-%m-%d-%H-%M-rotation
  • 保存場所: /rdsdbdata/log/audit/ (各ホスト毎)
  • ローテーション: 各ログファイル毎に100MBで、現在は変更不可。4つのログファイルの内、もっとも大きなファイルサイズが100MBになった場合、システムは新しいログファイルのセットへローテーションを行ないます
  • クリーンアップ: ディスクスペースを解放するために、ディスク消費量やファイルの世代に応じて古くなったaudit logを削除します
  • ログフォーマット: timestamp,serverhost,username,host,connectionid,queryid,operation,database,object,retcode
パラメータ 説明
timestamp 秒精度のログが記録された時点のUnixタイムスタンプ
serverhost ログが記録されたホスト名
username 接続ユーザ
host ユーザの接続元ホスト
connectionid ログを記録するためのコネクションID
queryid 関連するテーブルやクエリを特定するために利用するクエリID。TABLEイベントでは複数行記録される
operation 記録されたactionタイプ (CONNECT, QUERY, READ, WRITE, CREATE, ALTER, RENAME, DROP)
database USEコマンドで指定されたデータベース名
object QUERYイベントでは、実行されたクエリ。TABLEイベントではテーブル名
retcode ログを記録するためのリターンコード

他の方法と比較を行った場合

前述のように、多くのデータベースでは監査ログ機能が提供されていますが、監査機能が有効になっているとパフォーマンスが低下します。参照のみのワークロードを用いて、8xlargeインスタンス使用し、MariaDB Audit Pluginを有効にしたMySQL 5.7とパフォーマンス比較を行ないました。以下の結果のとおり、MySQLではAudit log機能が有効になっていると性能の大幅な低下が起こっています。Auroraでの性能低下は抑えられています。Auroraでは、15%の低下で抑えられていますが、MySQL5.7では65%の低下となっています。結果として、audit機能が有効になっている場合、AuroraのパフォーマンスはMySQL 5.7と比較して倍以上に向上しました。

advanced-auditing-benchmark

Advanced auditingは本日からご利用頂けます!機能の詳細はドキュメントをご覧ください。

注: こちらの機能はAurora version 1.10.1からご利用頂けます (https://forums.aws.amazon.com/ann.jspa?annID=4349)

— Sirish Chandrasekaran (product manager at Amazon Web Services) (翻訳は星野が担当しました。原文はこちら)

Amazon ECS Task Placement Policyのご紹介

by AWS Japan Staff | on | in Amazon ECS |

本日、Amazon ECSはクラスタ上にどのようにしてタスクを配置するかを汎用的に制御することのできる機能を発表しました。以前は、特定のリソースの要求(例えば、特定のインスタンスタイプ)を満たすコンテナインスタンス上にタスクを配置する必要がある時は、カスタムスケジューラを作成してリソースをフィルタし、発見し、グループ化する必要がありました。

次の図は、新しいタスク配置処理の概要を示しています:

これによって、コードを一切書かずともタスクがどのように配置されるかをカスタマイズすることができます。ECSは、インスタンスタイプやアベイラビリティゾーンの様な組み込み済の属性を付与していますし、加えてカスタムの属性もサポートしています。例えば、environment=productionといった属性でコンテナインスタンスをラベル付することができ、これらのリソースを見つけるためにList APIで操作することや、RunTaskとCreateService API操作でこれらのリソース上にタスクを配置することができます。

また、bin packspreadといったplacement strategy (配置戦略)を使って、タスクがさらにどこに配置されるかを定義することもできます。ポリシーを連鎖させて洗練された配置を達成することもできます。例えば、g2.*のインスタンス上にのみタスクを配置し、アベイラビリティゾーンに渡って幅広く(spread)配置し、そして各ゾーンではメモリを基準にタスクをなるべく詰め込む(bin pack)というポリシーを作成できます。

はじめに、attribute (属性)を見てましょう。インスタンスタイプ等の組み込み済の属性を使って、コンテナインスタンスを見つけ、その上にタスクを配置することができます。以下の例では、クラスタ上の全てのt2インスタンスを見ることができます:

aws ecs list-container-instances --filter "attribute:ecs.instance-type matches t2.*"
{
    "containerInstanceArns": [
        "arn:aws:ecs:us-east-1:123456789000:container-instance/40f0e62c-38cc-4cd2-a28e-770fa9796ca1",
        "arn:aws:ecs:us-east-1:123456789000:container-instance/eb6680ac-407e-42a6-abd3-1bbf57d7401f",
        "arn:aws:ecs:us-east-1:123456789000:container-instance/ecc03e17-6cbd-4291-bf24-870fa9796bf2",
        "arn:aws:ecs:us-east-1:123456789000:container-instance/fbc03e17-acbd-2291-df24-4324ab342a24",
        "arn:aws:ecs:us-east-1:123456789000:container-instance/f9a69f54-9ce7-4f1d-bc62-b8a9cfe8e8e5"
    ]
}

続いて、us-east-1aのアベイラビリティゾーンにあるt2インスタンスのみをリストしています:

aws ecs list-container-instances --filter "attribute:ecs.instance-type matches t2.* and attribute:ecs.availability-zone == us-east-1a"
{
    "containerInstanceArns": [
        "arn:aws:ecs:us-east-1:123456789000:container-instance/40f0e62c-38cc-4cd2-a28e-770fa9796ca1",
        "arn:aws:ecs:us-east-1:123456789000:container-instance/eb6680ac-407e-42a6-abd3-1bbf57d7401f",
        "arn:aws:ecs:us-east-1:123456789000:container-instance/ecc03e17-6cbd-4291-bf24-870fa9796bf2"
    ]
}

カスタム属性はECSのデータモデルを自身のカスタムメタデータ用にキーバリューのペアを使って拡張します。以下の例では、stack=prodという属性を特定のコンテナインスタンスに追加しています:

aws ecs put-attributes --attributes name=stack,value=prod,targetId=40f0e62c-38cc-4cd2-a28e-770fa9796ca1,targetType=container-instance

これで、stack=prodという属性が付いていないコンテナインスタンスを見ることができます:

aws ecs list-container-instances --filter "attribute:stack != prod"
{
    "containerInstanceArns": [
        "arn:aws:ecs:us-east-1:123456789000:container-instance/eb6680ac-407e-42a6-abd3-1bbf57d7401f",
        "arn:aws:ecs:us-east-1:123456789000:container-instance/ecc03e17-6cbd-4291-bf24-870fa9796bf2",
        "arn:aws:ecs:us-east-1:123456789000:container-instance/fbc03e17-acbd-2291-df24-4324ab342a24",
        "arn:aws:ecs:us-east-1:123456789000:container-instance/f9a69f54-9ce7-4f1d-bc62-b8a9cfe8e8e5"
    ]
}

それでは、これらの属性をタスクのスケジューリングで使ってみましょう。constraint (制約)は、ECSがスケジューリングを決める時に評価される属性を基準としたルールのことです。constraint (制約)はMemberOfDistinctInstanceを使ってタスクを配置するためにクラスタ内でインスタンスのサブセットを作成します。以下の例では、5つのタスクを、t2.smallかt2.mediumでus-east-1dのアベイラビリティゾーンではないインスタンスに起動しています:

aws ecs run-task --task-definition myapp --count 5 --placement-constraints type="memberOf",expression="(attribute:ecs.instance-type == t2.small or attribute:ecs.instance-type == t2.medium) and attribute:ecs.availability-zone != us-east-1d"

constraint (制約)に加えて、RunTask API操作する時やCreateService APIを使って新しいサービスを作成する時にはplacement strategy (配置戦略)も利用可能です。戦略のタイプは定義されていますが、カスタマイズしたり組み合わせることができます。サポートされる戦略タイプはRandom (ランダム)、Binpack (詰め込み)、そしてSpread (幅広く)です。以下の例では、アベイラビリティゾーンに渡って幅広く配置しながら、各ゾーンではメモリを基準に詰め込みをしています。

aws ecs run-task --task-definition myapp --count 9 --placement-strategy type="spread",field="attribute:ecs.availability-zone" type="binpack",field="memory"

広く配置して各ゾーンではメモリを基準に詰め込むが、g2.*のインスタンスタイプのみにタスクを配置したいと思ったとします。

placement policy (配置ポリシー)をECSコンソールで定義するために、Create serviceを選択します。Task placementセクションの中で、AZ Balanced BinPackというplacement template (配置テンプレート)を選び、Editを選択します。

これでテンプレートをベースにしてカスタムポリシーを作成できます。テンプレートのConstraintセクションに、以下を追加します:

attribute:ecs.instance-type=~g2.*

これで、G2インスタンス上のみにタスクを配置し、タスクはアベイラビリティゾーンに渡って幅広く、そして各ゾーンではメモリが最も残り少ないインスタンスに配置するサービスを作ることができました。

まとめ

本日より、新しい属性をECSオブジェクトに追加し、より細かくECSリソースにクエリし、そして直接タスクを配置することができます。

ECS上のタスク配置についてより詳しく知りたい方は、Amazon ECS開発者ガイドのトピックか、re:Inventのセッションをご覧下さい。

ご質問やコメントがありましたら、以下のコメント欄をご利用下さい。

原文: Introducing Amazon ECS Task Placement Policies (翻訳: SA岩永)

Amazon Route 53 および AWS Shield を使用した DDoS リスクの軽減

by AWS Japan Staff | on | in Amazon Route53, AWS Shield |

2016 年 10 月後半に、著名な DNS プロバイダーが、複数のサービス妨害攻撃で構成された大規模なサイバー攻撃の標的となりました。数千万の IP アドレスからの大量の DNS 参照で構成された攻撃により、多くのインターネットサイトやサービスが北米および欧州のユーザーに対して利用できなくなりました。プリンター、カメラ、家庭用ネットワークゲートウェイ、さらにはベビーモニターといったさまざまなインターネッツ接続デバイスで構成されたボットネットを使用して、この分散サービス妨害 (DDoS) 攻撃が実行されたと考えられます。これらのデバイスは Mirai マルウェアに感染し、1 秒あたり数百ギガバイトのトラフィックを生成しました。多くの企業ネットワークや教育ネットワークは、このような規模のボリューメトリック攻撃を吸収するだけのキャパシティーを持っていません。この攻撃や、それ以前のその他の攻撃を受けて、さまざまなタイプの DDoS 攻撃に対してより弾力性の高いシステムを構築できるようにするための推奨事項やベストプラクティスについてお客様から当社に問い合わせがありました。簡単な回答としては、スケール、耐障害性、および緩和を組み合わせ (詳細については「AWS Best Practices for DDoS Resiliency」ホワイトペーパーを参照)、Amazon Route 53 および AWS Shield を利用することです (詳細については、「AWS Shield – Protect Your Applications from DDoS Attacks」を参照)。

スケール – Route 53 は数多くの AWS エッジロケーションでホストされ、大量の DNS トラフィックを吸収することができるグローバルな対象領域を作成します。Amazon CloudFrontAWS WAF を含むその他のエッジベースのサービスにもグローバルな対象領域があり、大量のトラフィックを処理することができます。

耐障害性 – 各エッジロケーションには、インターネットへの数多くの接続があります。これにより、多様なパスが可能になり、障害の分離と阻止に役立ちます。また、Route 53 はシャッフルシャーディングエニーキャストストライピングを使って可用性を高めます。シャッフルシャーディングでは、委託セットの各ネームサーバーがエッジロケーションの一意のセットに対応します。この配置によって耐障害性が向上し、AWS のお客様間の重複が最小化されます。委託セットの 1 つのネームサーバーが利用できない場合、クライアントシステムまたはアプリケーションは別のエッジロケーションのネームサーバーを再試行し、レスポンスを受け取ります。エニーキャストストライピングは、最適な場所に DNS リクエストをダイレクトするために使用されます。これは、負荷を分散して DNS レイテンシーを減らす効果があります。

緩和 – AWS Shield Standard は、現在の最も一般的な攻撃の 96% からお客様を保護します。これには、SYN/ACK フラッド、反射攻撃、および HTTP スローリードが含まれます。私の投稿で前に述べたように、この保護は自動的かつ透過的に Elastic Load Balancing、CloudFront ディストリビューション、および Route 53 リソースに無料で適用されます。保護 (決定的パケットフィルタリングと優先順位をベースとしたトラフィック形成を含む) はすべての AWS エッジロケーションにデプロイされ、わずか数秒のオーバーヘッドですべてのトラフィックを検査します。すべては完全に透過的な方法で実行されます。

AWS Shield Advanced には、追加の DDoS 緩和機能、DDoS Response Team への年中無休のアクセス、リアルタイムのメトリクスとレポート、および DDoS コスト保護が含まれます。詳細については、「DDoS Resiliency」ホワイトペーパーを参照し、Route 53 エニーキャストについてご覧ください。

Jeff;

新機能 – AWS OpsWorks for Chef Automate

by AWS Japan Staff | on | in AWS OpsWorks |

AWS OpsWorks は、Chef を使用したアプリケーションの設定と実行に役立ちます。ドメイン固有言語 (DSL) を使って、アプリケーションのアーキテクチャと各コンポーネントの設定を定義するクックブックを記述します。Chef サーバーは、設定プロセスで不可欠な要素です。このサーバーはすべてのクックブックを保存し、各インスタンス (Chef の用語ではノード) の状態情報を追跡します。Chef サーバーは新しく起動されたインスタンスが設定されるときは重要なパスにあるため、信頼性が高い必要があります。多くの OpsWorks および Chef ユーザーは、この重要なアーキテクチャコンポーネントを自分でインストールして維持しています。本稼働スケールの環境では、これによりバックアップ、復元、バージョンのアップグレードなどをユーザーが処理する必要があります。

新しい AWS OpsWorks for Chef Automate
今月初めに、AWS OpsWorks for Chef AutomateAWS re:Invent ステージから開始されました。Chef Automate サーバーは、わずか 3 回のクリックで起動し、数分以内に使用を開始することができます。Chef Supermarket をはじめ、Test KitchenKnife などのコミュニティツールからのコミュニティクックブックを使用できます。Chef Automate を使用すると、アプリケーションのインフラストラクチャのライフサイクルを通じてインフラストラクチャを管理できます。たとえば、新しく起動した EC2 インスタンスは自動的に Chef サーバーに接続し、自動関連付けスクリプトを使用して、指定されたレシピを実行できます (詳細については、「AWS OpsWorks for Chef Automate でのノードの自動的な追加」を参照)。登録スクリプトを使用して、Auto Scaling グループを通じて動的に作成された EC2 インスタンスを登録し、オンプレミスサーバーを登録できます。

詳しく見る
OpsWorks コンソールから Chef Automate サーバーを起動してみましょう。開始するには、[Go to OpsWorks for Chef Automate] をクリックします。

[Create Chef Automate server] をクリックし、サーバーに名前を付けます。次にリージョンを選択し、適切な EC2 インスタンスタイプを選択します。

SSH キーペアの 1 つを選択するか、SSH からオプトアウトします。

最後に、ネットワーク (VPC)、IAM、メンテナンスウィンドウ、およびバックアップの設定を指定します。

[Next] をクリックし、設定を確認して、[Launch] をクリックします。起動プロセスにかかる時間は 20 分未満です。その時間中に、スターターキットとともに Chef Automate ダッシュボードのサインイン認証情報をダウンロードできます。

すべての Chef Automate サーバーを一目で表示できます。

サーバー名 (ここでは BorkBorkBork) をクリックし、[Open Chef Automate dashboard] をクリックします。次に、認証情報を入力してログインします。

ダッシュボードを次に示します。

ノードを表示して管理できます。

ワークフローを管理する

ほかにもさまざまな機能があります。バックグラウンドでは、起動プロセスによって AWS CloudFormation テンプレートが呼び出されます。このテンプレートにより、EC2 インスタンス、Elastic IP アドレス、およびセキュリティグループが作成されます。

今すぐご利用可能
AWS OpsWorks for Chef Automate は、US East (Northern Virginia)US West (Oregon)、および Europe (Ireland) リージョンで今すぐご利用できます。料金はサーバーに接続されたノードの数と時間数に基づきます。詳細については、Chef Automate の料金表ページを参照してください。AWS Free Tier の一部として、12 か月当たり最大 10 ノードまでは無料で使用できます。

Jeff;

毎日集計される料金表の通知 ~ AWS料金表API

by AWS Japan Staff | on | in General |

昨年、AWS のお客様とパートナーから、AWS のサービスの料金を取得するためのシステム的な方法を求める要望が寄せられました。このニーズに対して、昨年 12 月に 13 の AWS のサービスの料金を対象とした AWS の料金表 API を発表しました。この API は、ダウンロード用に JSON および CSV 形式で料金表データを提供し、お客様は AWS のサービスの料金を問い合わせることができます。料金表 API では、Amazon SNS 通知を通じて料金変更の更新情報を受け取ることもできます。

AWS 料金表の API の拡張
過去 3 か月に、当社は AWS の料金表 API サービスを拡張し、すべての AWS のサービスについて料金表データを提供するようにしました。クラウドベースのソリューションの構築またはクラウドへのオンプレミスワークロードの移行に関するコスト分析を行っているお客様は、AWS のサービスの包括的な料金表にこれまでよりも簡単にアクセスできます。これにより、お客様とパートナーは、クラウドソリューションの予算、予測、および計画をより詳細に管理できます。AWS の料金表 API の拡張に加えて、お客様はサインアップして割引料金、新しいサービスやインスタンスタイプの通知を受け取ることができます。通知の受信のサブスクライブの際は、更新情報を受け取るタイミングをカスタマイズでき、1 日 1 回、または料金の更新が発生するたびに設定できます。1 日 1 回の通知を選択した場合、SNS 通知にはその日に適用されたすべての料金変更が含まれます。料金表 API にサブスクライブした場合に受け取る E メール通知のサンプルを次に示します。

料金表 API の使い方を簡単に見てみましょう。最初に、料金表 API を介して料金情報にアクセスし、オファーインデックスファイルとオファーファイルという 2 種類のファイルをダウンロードします。オファーインデックスファイルは JSON ファイルとして利用でき、サポートされている AWS のサービスと、関連するサービスオファーファイルの URL が記載されています。このオファーファイルでは、単一の AWS のサービスに関する製品や料金が一覧表示され、CSV または JSON ファイル形式として利用できます。両方とも単純なダウンロードリンクを介してアクセスでき、簡単な方法で料金表データファイルを入手できます。

今すぐ料金表 API の使用を開始し、いずれの AWS のサービスについても、料金表データを入手できます。AWS の料金表 API の拡張によりすべての AWS のサービスが対象になったことで、料金表 API へのサブスクライブにより、最新の AWS の割引料金の情報を受け取るとともに、新しいサービスの紹介を受けることができます。

AWS の料金表 API の詳細、および API 通知へのサブスクライブ方法の詳細については、サービスについて紹介している前の AWS ブログ投稿、および AWS の料金表 API の使用に関するドキュメントを参照してください。

– Tara

事前にご確認ください – AWSにおける2016年12月31日(日本時間2017年1月1日)のうるう秒

by AWS Japan Staff | on | in Amazon EC2, Amazon RDS, General |

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調整時刻と協定世界時はこの期間が終了後に同期します。(訳注:この期間の1秒をごくわずかに遅くすることで、追加される1秒を長い時間のなかに分散する方法であり、これは前回うるう秒挿入時と同じ挙動です。詳しくは前回の情報をご確認ください。)

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 Systems Manager – EC2 およびオンプレミスのシステムの設定と管理

by AWS Japan Staff | on | in Amazon EC2 |

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

ファミリーへようこそ
WernerEC2 Systems ManagerAWS 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;

AWS コストエクスプローラーの更新 – リザーブドインスタンス使用率レポート

by AWS Japan Staff | on | in AWS Cost Explorer |

コストエクスプローラーは、レポートおよび分析ツールを使用して AWS の使用率を管理できるようにするツールです (詳細については、「The New Cost Explorer for AWS」を参照してください)。1 回クリックするだけでサインアップし、AWS コストの視覚化、傾向の分析、使用率のパターンの確認ができます。使用率は、事前定義された一連のビュー (サービス別、リンクされたアカウント別、日次など) で確認できます。関心のある特定の領域にドリルインしたり、カスタムフィルタを設定したりできます。エンタープライズ規模の AWS のお客様は、リザーブドインスタンスで実現されるコスト削減 (オンデマンドと比較した場合、最大 75%) を常に活用できます。こうしたお客様は、一般的に数千ものリザーブドインスタンス (RI) のサブスクリプションを持っていて、それらを十分に活用できていることを確認したいと考えています。

新しいリザーブドインスタンス使用率レポート
本日、コストエクスプローラーに新しいリザーブドインスタンス使用率レポートが追加されます。リンクされたアカウント間で分散された数千のサブスクリプションにユーザーが増えても、組織全体にわたり RI 全体の使用率を追跡し、管理する機能が得られます。また、1 年前まで遡って、使用率全体または個別の RI の使用率を確認することもできます。さらに、1 年前まで遡って、使用率全体または個別の RI の使用率を確認し、RI 使用率のしきい値を定義して、それに対する実際の使用率をモニタリングすることもできます。事前に定義されたターゲットを使用率が下回っている RI サブスクリプションが見つかった場合、ドリルダウンしてアカウントの所有者、インスタンスタイプ、および未使用の時間を確認できます。また、コストエクスプローラーで提供される既存のフィルタリング関数にすべてアクセスできます。私は数千のリザーブドインスタンスを所有していないので、サンプルのスクリーンショットとテストデータを使って、このレポートの外観と使用方法を示します。新しいレポートはコストエクスプローラーのメニューから日次または月次で利用できます (このメニューには、私が定義した 3 つのレポートが含まれています)。

RI 使用率の日次レポートを次に示します。

RI は RI 使用率の降順に表示されています。デフォルトでは、最も使用されていない RI がリストの先頭に表示されます。クリックすると、時間の経過に伴う使用率と、RI に関する詳細情報が表示されます。

特定の RI に注目するため、インスタンスタイプまたはその他の属性別にフィルタできます。

必要な時間範囲も設定できます。インスタンスタイプでフィルタして時間範囲を設定することで、先月に d2.8xlarge RI を十分に活用したことを次のように確認できます。

使用率ターゲットを目的の割合に設定でき、それが基準線としてグラフに表示されます。ここでは、6 月に使用率が 80% を下回ったことがわかります。

ここから日次ビューに切り替えて拡大 (クリックしてドラッグ) すると、詳細を表示できます。

前述したように、リンクされたアカウント、リージョン、および各 RI のその他の側面でフィルタすることもできます。

今すぐ利用可能
このレポートは今すぐ使い始めることができます。

Jeff;