Category: Management Tools

AWS CloudFormation を使用すると、AWS リソースのコレクション (「スタック」) を制御された予想可能な方法で作成、管理、および更新できます。CloudFormation を使用して、本番ワークロードを稼働するためのスタックの更新が 1 日に何十万回も実行されています。お客様は、初回のテンプレートを定義した後、要件が変わるとテンプレートを修正します。 通常「コードとしてのインフラストラクチャ」と呼ばれるこのモデルを使用すると、開発者、アーキテクト、および運用担当者の各チームが AWS リソースのプロビジョニングと構成を詳細に制御できるようになります。この制御と説明責任の詳細さは、CloudFormation を使用する際に最もはっきりとわかる利点の 1 つです。ただし、CloudFormation には、それほどはっきりとはわからないものの、同じくらい重要な利点がいくつかあります。 整合性 – CloudFormation チームは、AWS チームと連係して、リソースの作成、更新、および削除のセマンティクスについて、新しく追加されたリソースモデルでも整合性を保つようにしています。また、EBS ボリュームや RDS ボリュームの暗号化用の KMS キーなど、関連リソースの再試行、べき等性、および管理について説明できるようにしています。 安定性 – どのような配信システムでも、結果整合性に関連する問題は頻繁に発生し、必ず対処する必要があります。CloudFormation チームではこのような問題を十分認識しており、変更のプロパゲーションが必要な場合には、配信を実行する前に、自動的にそのプロパゲーションが完了するのを待つ仕組みになっています。多くの場合、CloudFormation チームはサービスチームと連係して、API と成功シグナルが CloudFormation で適切に使用できるよう調整されていることを確認します。 均一性 – CloudFormation では、スタックが更新される際に、インプレース更新とリソース置換のいずれかが選択されます。 この作業はすべて一定の時間がかかり、関連サービスが公開または更新される前にテストを完了できない場合もあります。 更新のサポートの向上 先述のように、AWS の多くのお客様が、本番スタックの更新を管理するのに CloudFormation を使用しています。お客様は、既存のテンプレートを編集 (または新しいテンプレートを作成) した後、CloudFormation の更新スタックオペレーションを実行して、変更を有効にします。 新しいテンプレートやパラメータ値に合わせてスタックが更新される際に CloudFormation が実行する変更の詳細について知りたい、というお問い合わせが、多くのお客様から寄せられています。変更のプレビューを行い、その変更が期待通りであることを確認してから、更新を実行するためです。 CloudFormation のこの重要なユースケースに対応するために、「変更セット」という概念を導入しました。変更セットを作成するための第 1 段階として、お客様は、更新対象のスタックに対する変更内容を送信します。CloudFormation では、更新対象のスタックが新しいテンプレートやパラメータ値と比較され、変更セットが作成されます。お客様は、この変更セットを確認してから、適用 […]

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく（1台のインスタンスから何千台のインスタンスまで）費用対効果の高いキャパシティを複数プールからリソース提供します。この強力なEC2機能の詳細については、こちらのブログを参照下さい。【AWS発表】Amazon EC2 スポットフリート API – 一度のリクエストで数千台のスポットインスタンスを制御、【AWS発表】Spotフリート – コンソール、フリートスケーリング、CoudFormationに対応。 私は各スポットフリートを一つの集合体として考えます。フリートが起動すると、それぞれが独立したグループのEC2インスタンスとして起動します。スポット価格の変化や、フリートキャパシティの変更に伴いインスタンスの状態は変化しますが（可能な限り費用対効果を高めるよう変化）、フリート自体はその属性を保持します。 新しいスポットフリート メトリックス スポットフリートの管理、監視、拡張性をより簡単にするために、CloudWatchに新しいスポットフリート用メトリックが追加されました。メトリックスは、複数のディメンションからアクセスできます：スポットフリート毎、スポットフリートが構成されているアベイラビリティゾーン毎、フリート内のEC2インスタンスタイプ、アベイラビリティゾーン、インスタンスタイプ等。 下記メトリックスは各スポットフリート毎に取得されます。（これらメトリックスを取得するためには、EC2詳細モニタリングを有効にする必要があります） AvailableInstancePoolsCount BidsSubmittedForCapacity CPUUtilization DiskReadBytes DiskReadOps DiskWriteBytes DiskWriteOps EligibleInstancePoolCount FulfilledCapacity MaxPercentCapacityAllocation NetworkIn NetworkOut PendingCapacity StatusCheckFailed StatusCheckFailed_Instance StatusCheckFailed_System TargetCapacity TerminatingCapacity  メトリックのいくつかは、スポットフリートの入札プロセスのヒントとなるかもしれません。例えば、 AvailableInstancePoolsCount – スポットフリートのリクエストに含まれるインスタンス・プールの数を示します。 BidsSubmittedForCapacity – スポットフリート キャパシティの入札数を示します。 EligibleInstancePoolsCount – スポットインスタンスリクエストの対象となるインスタンスプールの数を示します。いずれか（1）スポット価格がオンデマンド価格より高い場合、または（2）入札価格がスポット価格よりも低い場合にはプールが不適用となります。 FulfilledCapacity – フリートキャパシティを満たす容量の合計を示します。 PercentCapacityAllocation – 特定ディメンションに割り当てられた容量の割合を示します。特定のインスタンスタイプに割り当てられた容量のパーセントを決定するために、インスタンスタイプと共に使用することができます。 PendingCapacity – ターゲットキャパシティと利用済みキャパシティの差異を示します。 TargetCapacity – スポットフリート内の現在要求されたターゲットキャパシティを示します。 TerminatingCapacity – スポットインスタンスの終了通知を受けたインスタンスのインスタンスキャパシティを示します。 これらのメトリックスは、スポットフリートの全体的なステータスとパフォーマンスを決定する手助けになります。メトリック名からも分かりますが、スポットフリート毎に消費されるディスク、CPU、およびネットワークリソースを確認することができます。また、スポットキャパシティ確保のために入札の前にどのような傾向があるかを確認することができます。それに加え、アベイラビリティゾーン、インスタンスタイプをまたいだ下記メトリックスも取得できます。 CPUUtilization DiskReadBytes […]

本日、AWS Config Rules Repositoryをリリースしました。AWS Config Rules Repository はコミュニティベースで、カスタマイズされたAWS Config Ruleを提供します。この新リポジトリを利用することで、AWSリソースのセキュリティに関するベストプラクティスに対し、評価とコンプライアンス評価の自動化が可能になります。 AWS Config Rules は、AWSリソースの定期的なセキュリティとコンプライアンスチェックを自動で行い、セキュリティ設定における手動作業の削減をサポートするサービスです。 AWS Config Rules Repository を使うことで、コンプライアンスチェックの自動化を加速させ、お客様はAWSコミュニティに集約された専門的な知識を簡単に利用できるようになります。それに加え、レポジトリは無料で公開されており、それぞれが独自に管理されています。それぞれのルールのコードが丸ごと共有されているため、そこから学び、コミュニティに貢献することもできます。全般的なセキュリティ専門家からの声とAWSユーザの観点からのセキュリティ専門家からの声を合わせることで、知見を高めることができればと思います。 以前のポストで述べたように、Center for Internet Securityと連携し、AWSアカウントを保護するための業界のベストプラクティスを確立しました。このリポジトリには、これらのベストプラクティスとの整合性を維持するのに役立つルールが幾つかあります。下記は現在、アクセス権を持っているカスタムルールのサンプルです： CloudTrailがすべての地域で有効になっているかの確認 すべてのアカウントで多要素認証（MFA）が有効になっているかの確認 ルートアカウントに対しキーが存在していないかの確認 AWS Identity and Access Management (IAM) にIAM Policyが存在しているかの確認 キーのローテーションが行われているかの確認 皆さんのAWSアカウントにこれらのルールを使用をする際には、GitHubの上のReadmeファイルを参照してください。是非このレポジトリを活用頂き、皆さんのカスタムルールをAWSコミュニテイで共有下さい！ Chad 翻訳は酒徳が担当しました。本文はこちら：http://blogs.aws.amazon.com/security/post/TxES3UX2Z5BQRU/Announcing-the-AWS-Config-Rules-Repository-A-New-Community-Based-Source-of-Custo