Amazon Web Services ブログ

CloudFormation スタックセットを利用した 複数のAWSアカウントやリージョンを横断したリソース展開

AWS CloudFormation は、AWS を利用するお客様の Infrastructure as Code モデルの実現に役立ちます。環境やアプリケーションを手作業でセットアップする代わりに、テンプレートを構築しそれを使用することで必要な全てのリソース ― これら一連のリソースは CloudFormation スタックと呼ばれます ― を作成します。このモデルでは、手作業に起因する失敗が発生する可能性が排除され、効率性が増し、時間が経過しても一貫した設定が保証されます。 本日、CloudFormation がよりいっそう便利になる新機能についてご紹介したいと思います。この新機能は、複数の AWS アカウントおよび/または複数のリージョンを利用する状況において Infrastructure as Code を実践するときにお客様が直面する課題の解決に役立つように設計されています。 アカウント ― 以前お話したように、多くの組織で多数の AWS アカウントが使用されます。AWS アカウントを階層化し、組織単位、あるいはOU(詳しく知りたい場合は「AWS Organizations – 複数の AWS アカウントのポリシーベースの管理」をお読みください)へグルーピングするために AWS Organizations が利用されています。事業、アプリケーション、そしてデベロッパーに対して複数のアカウントが運用されます。またアプリケーション毎に、開発、テスティング、ステージング、そして本番のそれぞれに対して別々のアカウントが作成されることもあります。 リージョン ― 巨大な(かつ今なお成長し続ける)AWS のリージョンもまた大いに活用されています。2つかあるいはそれ以上のリージョンにまたがるグローバルアプリケーションが構築され、洗練されたマルチリージョン・ディザスタリカバリ・モデルが実装されています。また、S3、Aurora、PostgreSQL、そして MySQL のデータをリアルタイムにレプリケートし、国や地域の規制にしたがって機密データを保管および処理するための場所を選択します。 複数のアカウントやリージョンへのこのような展開は、ガバナンスと一貫性に関していくつかの新しい課題をともないます。新しく作成される各アカウントが社内の標準に従って設定されていることを確認したいと、お客様は言われます。とりわけ、IAM ユーザーと IAM ロール、VPC と VPC サブネット、セキュリティグループ、コンフィグルール、ロギング、そして AWS Lambda 関数を、信頼性があり一貫した方法でセットアップしたいと望まれます。 スタックセットのご紹介 これらの重要なご要望を解決するために、本日 CloudFormation […]

Read More

3つのトレーニングコースを新設(※日本では2コース開催)

エキスパートから学ぶことができる AWS トレーニングでは、実践的なスキルや AWS クラウドの活用方法について知識を増やすことができます。本日より、トレーニングブートキャンプでもっとも人気のある 3 つ (AWS re:Invent や AWS グローバルサミット でお馴染みです) のコースが、AWS によるインストラクター主導トレーニングの一部として含まれるようになりました。 サーバーレスデータレイクの構築– AWS サービスでのサーバーレスデータレイクソリューションの設計、構築、操作の方法を説明します。 クラウドへの転換を成功させる秘訣 – ワークロードをクラウドに移行させる際に必要となる適切な戦略、スタッフ、移行プラン、財務管理方法について説明します。技術的に高度な専門知識は必要ありません。 AWS でコンテナ対応マイクロサービスを実行 – Amazon EC2 Container Service (ECS) を使用してコンテナ対応アプリケーションの管理とスケーリングする方法を説明します。 こうした 1 日コースはエキスパートトレーナーから専門的なトピックの詳細を学びたい方を対象にしています。 コースカタログ一覧で詳細を見たり、お近くで開催される講座を AWS トレーニングと認定ポータルで検索することができます。チーム専用にプライベートのオンサイトトレーニングセッションをご希望の場合は、こちらからお問い合わせください。 — Jeff; 日本ではお客様向けの新規2コースを9月から開始: AWS Summit Tokyo 2017 のBoot Campメニューで選考提供した以下の2コースを、この秋より定期コースとしてリリースします。いずれも1日コースです。お申込みいただけるようになりましたら、改めてご案内致します。 ·         Running Container-Enabled Microservices on AWS: 9/19(火)@西新宿会場 ·         Building a […]

Read More

Amazon CloudWatch における高解像度メトリクスとアラーム

Amazon CloudWatch は 2009 年以来 AWS の重要な要素となっています。3 つの同時リリース (Auto Scaling、Elastic Load Balancing) の 1 つとして公開された CloudWatch は、AWS リソースや AWS クラウドで実行するアプリケーションをモニタリングする非常に強力なサービスに進化しました。CloudWatch カスタムメトリクス (2011 年にリリース) は CloudWatch でビジネスおよびアプリケーションメトリクスを保存できるようにし、グラフ表示や CloudWatch アラームをベースにアクションを開始することができます。数年間に渡り CloudWatch にいくつもの強化点を施してきたことは言うまでもありません。最近ではメトリクス保存期間の延長 (およびユーザーインターフェイスの更新)、ダッシュボード、ダッシュボードでの API/CloudFormation のサポート、ダッシュボードにアラームなどを追加してきました。 最初はメトリクスを 5 分間隔で保存していましたが、ユーザーから寄せられたリクエストに応え、2010 年にこれを 1 分間隔に変更しました (詳細モニタリング)。これについては高い評価を頂きましたが、そろそろレベルアップさせる時期が来ました。AWS をご利用されているお客様は 1 日に多数の動画をストリーミングしたり、フラッシュセールを行ったり、コードをいくつもデプロイしたりしています。さらに、状況が変わるに連れてすばやくスケールインまたはスケールアウトするアプリケーションも実行しています。こうした様々な状況において 1 分間隔では詳細性に欠けることになります。また、重要で一時的な増加を見逃してしまう可能性もあります。異種 (でありながら関連性のある) イベントを時間と関連付けるのは困難です。何か支障があった場合の MTTR (mean time to repair – 平均修復時間) に時間が掛かることもあるでしょう。 […]

Read More

Amazon S3バケットのアクセス設定に関する注意喚起メールにつきまして

2017年7月19日前後より、Amazon Web Services(AWS)の一部のお客様に対し、“Securing Amazon S3 Buckets” という件名のメールをご送付させていただきました。Amazon S3 のバケットポリシーやアクセスコントロールリスト(ACL)の設定の不備によって、Amazon S3 上の重要なデータが漏洩するセキュリティリスクに対する注意喚起となります。Amazon S3 のバケットポリシーや ACLの設定について、この注意喚起メールを必要な設定の見直しのきっかけにしていただければと思います。なお、メールを受け取られたお客様に、必ずしも問題があることを示すものではありません。   メールが送られた契機について   重要なデータが漏洩した事例のいくつかを調査した結果、バケット ACL を “All Users” や “All Authenticated AWS Users” に設定されているお客様はセキュリティリスクが高いと判断しています。該当するお客様は、設定の見直しを推奨すべくメールをお送り致しましたので、アクセスが広く許可されていることが本当に正しい状態か、今一度ご確認ください。

Read More

HBase on Amazon S3を使用してリードレプリカクラスタをセットアップする

多くのお客様は、低コスト、データ耐久性、スケーラビリティなど、Amazon S3をデータストレージとしてApache HBaseを実行することの利点を活用しています。 FINRAのような顧客は、HBase on S3アーキテクチャーに移行し、ストレージをコンピュートから切り離し、S3をストレージレイヤーとして使用するという多くの運用上の利点とともに、コストを60%削減しました。 HBase on S3を使用すると、クラスタを起動して、長いスナップショット復元プロセスを経る必要がなく、S3内のデータに対してすぐにクエリを開始することができます。 Amazon EMR 5.7.0の発表により、HBase on S3の高可用性と耐久性をクラスタレベルにさらに一歩進化させることができます。S3上の同じHBaseルートディレクトリに接続できる複数のHBase読み取り専用クラスタを開始できます。これにより、リードレプリカクラスタを介して常にデータにアクセスできることを保証し、複数のアベイラビリティゾーンにわたってクラスタを実行できます。 この記事では、HBase on S3を使用したリードレプリカクラスタの設定をご案内します。

Read More

CloudFormation スタックセットを使ったリソースのプロビジョニング

AWS CloudFormation は AWS をご利用されているお客様がコードとしてのインフラストラクチャモデルを実装するのに役立ちます。環境やアプリケーションのセットアップを手動で行う代わりに、同機能はテンプレートを構築して CloudFormation スタックと呼ばれる必要なリソースすべてを作成するために使うことができます。このモデルは手動によるエラーを排除し、効率性の向上や、設定における一貫性を長期に渡り保つことを可能にします。 そこで、今回はこれまで以上に CloudFormation を便利にする最新の機能強化についてご紹介します。この機能は、複数の AWS アカウントや AWS リージョンなどの状況で、コードとしてインフラストラクチャを使用する場合に直面するチャレンジに対応しやすくするように設計されています。手短にご説明します。 アカウント – 以前ご説明したように、多くの組織が複数の AWS アカウントを使用していますが、AWS Organizations でアカウント階層化し、組織単位 (OU) でグループにしています (詳細は「複数の AWS アカウントのポリシーベース管理 – AWS Organizations (AWS Organizations – Policy-Based Management for Multiple AWS Accounts)」をご覧ください)。AWS のお客様はビジネスユニット、アプリケーション、開発者に渡り複数のアカウントを使用しています。アプリケーションごとの開発、テスト、ステージング、実稼働環境にそれぞれ別のアカウントを作成するのが一般的になっています。 リージョン – また、AWS をご利用のお客様は多数の (現在も増加中) AWS リージョンを 大いに利用しています。2 つまたはそれ以上のリージョンに渡りグローバルアプリケーションを構築し、洗練されたマルチリージョンの災害対策モデルの実装、S3、Aurora、PostgreSQL、MySQL データをリアルタイムでレプリケートし、国内および地域に適用される規制に準拠する方法で機密データの保存先や処理を行う場所を選びます。 複数のアカウントやリージョンへの拡大は、ガバナンスや適合性に見合うための新たなチャレンジを伴っています。AWS のお客様は各アカウントが必ず内部基準に合うようにしたいと言っています。特に IAM ユーザーとロール、VPC、VPC サブネット、セキュリティグループ、設定ルール、ロギング、AWS Lambda […]

Read More

Amazon AppStream 2.0 のGPU強化によるストリーミングインスタンス

re:Invent 2016 でリリースした Amazon AppStream 2.0 についてお知らせします。このアプリケーションストリーミングサービスは、デスクトップブラウザに Windows アプリケーションを配信することができます。 フルマネージド型の AppStream 2.0 は、多目的、コンピュート最適化、メモリ最適化のストリーミングインスタンスでアプリケーションを実行することにより、一貫性のあるスケーラブルなパフォーマンスを提供し、安全で忠実度の高いストリーミングプロトコルの NICE DCV を介して配信します。エンタープライズおよび公的機関のお客様は、レガシーアプリケーションストリーミング環境の代わりにオンプレミスでインストール済みの AppStream 2.0 をすでにご利用されています。こうしたお客様は AppStream 2.0 を使用して、商用アプリケーションおよびビジネスアプリケーションをデスクトップ ブラウザに配信しています。ISV をご利用されているお客様はコードを変更せずに、AppStream 2.0 を使用してアプリケーションをそのままクラウドに移動しています。こうしたお客様はデモ、ワークショップ、企業の SaaS プランなどに注目しています。 高評価を頂いている AppStream 2.0 には新しい機能が迅速に追加されています (AWS の平均に比べても速い方です)。今年に入ってからすでに image builder、SAML 2.0 のフェデレーティッドアクセス、CloudWatch モニタリング、Fleet Auto Scaling、シンプルなネットワークセットアップ、ユーザーファイル用の永続的ストレージ (Amazon S3 によりバックアップ)、VPC セキュリティグループのサポート、ユーザー向けのウェブポータルを含む組み込みのユーザー管理が追加されています。 新しい GPU によるストリーミングのインスタンス 専用のデザイン、エンジニアリング、HPC、メディアアプリケーションをユーザーに提供するために AppStream 2.0 を使用したいというリクエストを数多く頂きました。こうしたアプリケーションは、通常グラフィックスを集中的に使用し GPU (グラフィックスプロセッシングユニット) と組み合わせた高額で高性能の […]

Read More

Hightail — クラウド上での創造的なコラボレーションを支援

Hightail (旧社名: YouSendIt) は、世界各地の 5,000 万人以上の専門家が優れたコンテンツをユーザーに提供できるよう支援することで、創造的な作業の確認、改善、承認方法を合理化しています。Hightail は、ファイル共有会社として 2004 年に設立されて以来、付加価値のある創造的なコラボレーションサービスの提供へと戦略的方向を転換し、著名な顧客を数多く獲得しています。 本日のゲスト投稿では、Hightail の技術担当上級副社長である Shiva Paranandi 氏が、同社が実施したオンプレミスからクラウドへのペタバイト単位のデータ移行について語ります。クラウドベンダーの評価プロセスと、すべてを AWS に移行した理由が述べられています。 Hightail はユーザーが大きなファイルを簡単に共有して保存できる方法を提供するために設立されましたが、それ以降、創造的なコラボレーションツールへと進化してきました。当社は、ユーザーがデジタル資産を管理、共有するだけの場所ではなく、創造的なチームを作り、顧客とつながり、創造的なワークフローを開発して、最初から最後までプロジェクトを管理できる場所になりました。現在では、Lionsgate や Jimmy Kimmel Live! といった有名ブランドのコラボレーションサービスの原動力となっています。当社は、国内外の顧客が増える中で、製品開発とユーザーへのサービスに対して社内的により傾注する必要がありました。独自のデータセンターの運営には、予定していたよりも多くの時間、費用、人材が必要になることがわかりました。 より迅速に反復して顧客のニーズを満たし、市場までの時間を大幅に改善する手法が必要でした。データセンターのコストを削減し、世界各地の特定のリージョンで迅速にスケールアップする柔軟性が必要だったのです。新しい場所でのデータセンターの設営には長い時間がかかり、当社が達成できる成長ペースの妨げとなっていました。さらに、使用することもないストレージキャパシティーを所有することになる、ニーズに先回りした購入にはうんざりしていました。頻繁に使用しないデータを非アクティブなストレージに保持する一方で、顧客のリクエストに応じてそのデータを迅速に取り出せることでコストを削減する、階層型で非常にスケーラブルなストレージソリューションが必要でした。当社の主な推進力は俊敏性と革新であり、クラウドはそれらを強力に可能にしてくれます。それを踏まえて、ストレージとコンピューティングインフラストラクチャの管理にリソースを投入するのではなく、ビジネスを差別化する構想に時間とコストを費やすことができる、クラウドファーストのポリシーを採用することに決定しました。 AWS とクラウド競合他社の比較 移行の開始にあたって、まず AWS、Google、IBM、Microsoft を含むさまざまなクラウドベンダーの評価を行いました。当社にとっては明らかに AWS が抜きん出た選択肢でした。ある時点では、ニーズを満たすために複数のクラウドプロバイダーからのサービスを組み合わせることを検討しましたが、最適なルートは AWS を単独で使用することであると判断しました。トレーニング、同期、サポート、システムの可用性、それに他の移行や管理の要素を考慮すると、複数のクラウドを使用する手法は実用的ではありませんでした。最善のコスト削減と、ほかに例を見ないパートナーソリューションのエコシステムにより、他のベンダーは必要なく、すべてを AWS に移行することを選択しました。 AWS に移行することで、ギガバイトあたりの最低料金、リッチなエコシステムへのアクセス、社内の迅速な人材開発、SOC II コンプライアンスの維持が可能になりました。エコシステムは特に当社にとって重要で、非常に多くのパートナーを持つ AWS は競合他社とは一線を画していました。実際に、イメージのプレビュー、ビデオのエンコード、プレゼンテーションの提供などのサービスについて当社が依存しているすべてのベンダーは既にこのネットワークに参加しているため、既存の投資や専門知識を簡単に利用することができました。別のプロバイダーを選択していれば、既に正しく稼働しているプラットフォームからの移行が必要になりますが、これは当社にとって望ましい結果ではありませんでした。また、AWS のテクノロジーについて社内で開発できる人材の数も驚くべきものでした。AWS の使用に関する内部チームのトレーニングは、AWS カンファランス、トレーニング教材、サポートなどの利用可能なツールを使用した簡単なプロセスです。 ペタバイト単位のデータの移行 AWS を選択したことで、作業が簡単になりました。多くの場合、社内で使用していたよりも優れた機能が提供されました。オンプレミスストレージから AWS に数ペタバイトのデータを簡単に移行できました。AWS の Direct Connect により高速に処理を進めることができたため、3 か月ほどですべてのデータをプッシュできました。それによるユーザーへの影響はありませんでした。AWS Key […]

Read More

Amazon Kinesis Streams のサーバーサイド暗号化

昨今ではスマートホーム、ビッグデータ、IoT デバイス、携帯電話、ソーシャルネットワーク、チャットボット、ゲームコンソールなどが一般的に普及しており、ストリーミングデータはごく普通のことになりました。Amazon Kinesis Streams は、何千ものストリーミングデータソースから毎時間ごとにテラバイト単位のデータをキャプチャ、処理、分析、保存できるカスタムアプリケーションの構築を可能にしています。Amazon Kinesis Streams では、アプリケーションが同じ Kinesis ストリームから同時にデータを処理することができるので、並列処理システムを構築することができます。たとえば、処理済みのデータを Amazon S3 だけに送信するようにし、Amazon Redshift で複雑な分析を行ったり、AWS Lambda を使用する堅牢なサーバーレスストリーミングソリューションを構築することもできます。 Kinesis Streams では消費者が複数のストリーミングユースケースを利用できるようにしていますが、今後は Kinesis Streams でサーバー側の暗号化 (SSE) をサポートすることにより、移動中のデータをより効率的に保護できるようになりました。この新しい Kinesis Streams の機能により、データのセキュリティを強化したり、組織のデータストリーミングで必要となる様々な規制とコンプライアンス要件を満たすことができます。 Kinesis Streams は Payment Card Industry Data Security Standard (PCI DSS) のコンプライアンスプログラムで AWS 対象範囲内サービスの 1 つになっているほどです。PCI DSS は、主要な金融機関が設立した PCI Security Standards Council が管轄する専有情報のセキュリティ基準です。PCI DSS コンプライアンスは、カード所有者のデータやサービスプロバイダを含む機密性の高い認証データを保存、処理、転送する機関すべてに適用されます。AWS Artifact を使用して、PCI […]

Read More

新機能 – EC2 Auto Scalingのターゲットトラッキングポリシー

先日DynamoDBのAuto Scalingについてお伝えし、そこでDynamoDBテーブルのキャパシティ管理を自動化するためにどのように複数のCloudWatchアラームを利用しているかをお見せしました。その裏では、これからいくつかの異なるAWSサービスに渡って利用が予定されている、もっと一般化されたApplication Auto Scalingのモデルを使うことでこの機能を実現しています。 新しいAuto Scalingのモデルはターゲットトラッキングと呼ばれる重要な新しい機能を含んでいます。ターゲットトラッキングを使ってAuto Scalingのポリシーを作成する時には、特定のCloudWatchメトリクスに対してターゲットとなる値を選択します。Auto Scalingはそのメトリクスがターゲットに向かう様に適切な(スピーカーで言う)つまみを回し、合わせて関連するCloudWatchアラームも調整します。どういったメトリクスであれアプリケーションにとって意味のあるもので必要なターゲットを指定するという方法は、元々あるステップスケーリングポリシーの様に手動でメトリクスのレンジと閾値を設定するよりも、一般的にはより簡単で直接的なやりかたです。しかし、より高度なスケーリング戦略を実装するために、ターゲットトラッキングとステップスケーリングを組み合わせることも可能です。例えば、スケールアウトにはターゲットトラッキングを使い、スケールインにはステップスケーリングを使う等が考えられます。 EC2に新しい機能 本日、EC2 Auto Scalingにターゲットトラッキングのサポートを追加しました。Application Load Balancerのリクエスト数、CPU負荷、ネットワークトラフィック、またはカスタムメトリクスによるスケーリングポリシーを作成することができます(ターゲット毎のリクエスト数というメトリクスは新しいもので本日のリリースの一部になります)。 これらメトリクスは重要な特徴が共通しています: EC2インスタンスを追加することで(全体の負荷が変化していない時に)、メトリクスを下げることになります。もしくはその逆もです。 ターゲットトラッキングを使ったAuto Scaling Groupを作るのは簡単で、ポリシーの名前を入力し、メトリクスを選択し、希望するターゲットの値を設定するだけです: スケールイン側のポリシーを無効にすることもできます。その場合、手動でスケールインしたり、別のポリシーを使うことができます。 ターゲットトラッキングポリシーは、、、またはAWS SDKでも作成することができます。 以下は、ターゲットトラッキングを使おうとする時に頭にいれておくべき項目になります: 1つのAuto Scaling Groupに対して、異なるメトリクスを参照している複数のターゲットを設定することができます。スケーリングは常に一番高いキャパシティを求めるポリシーに従います。 メトリクスのデータが不十分な時はスケーリングは発動しません。 Auto Scalingはメトリクスの急速で一時的な変動を補い、関連するキャパシティの急激な変動を最小化しようと努力します。 カスタムメトリクスでのターゲットトラッキングはAuto Scaling APIやで設定することができます。 多くのケースで、1分間隔で入ってくるメトリクス(詳細モニタリングとも言われます)に応じてスケールするように選択すべきです。5分間隔のメトリクスをスケーリングの基本にすると、反応時間が遅くなってしまいます。 本日から利用可能です この新しい機能は本日から利用可能で、追加料金無しに使い始められます。より詳しくは、Auto Scalingユーザガイドのターゲットトラッキングスケーリングをご覧ください。 — Jeff; 原文: New – Target Tracking Policies for EC2 Auto Scaling (翻訳: SA岩永)

Read More