Amazon Web Services ブログ

 この記事では、コンプライアンス、災害復旧、データ主権などのユースケースについて、Amazon S3 レプリケーションのコストと使用の詳細をモニタリングする方法を確認します。 Amazon Simple Storage Service (Amazon S3) では、Cross-Region Replication (CRR) を使用して別の AWS リージョンの異なるバケットに、または Same-Region Replication (SRR) を使用して同じ AWS リージョン内部のバケット全体にデータを自動的かつ非同期に複製できます。SRR と CRR が連携して Amazon S3 レプリケーションを形成し、クロスアカウントレプリケーションなどのエンタープライズクラスのレプリケーション機能を提供し、偶発的な削除や Amazon S3 ストレージクラスへのレプリケーションを防ぎます。 CRR は、地理的に異なる場所にデータのコピーを保持することにより、コンプライアンス要件を満たし、レイテンシーを最小限に抑えるのに役立ちます。SRR は、開発者アカウントとテストアカウント間のライブレプリケーションを設定し、データの主権に関する法律を遵守するのに役立ちます。どちらの設定でも、Amazon S3 はソースバケット内のすべてのオブジェクトを宛先バケットに複製するか、オプションでオブジェクトのサブセットを複製します。CRR または SRR の両方で、プレフィックスとタグを使用して、複製可能なデータを制御できます。 大きなプロジェクトまたは特定のユースケース (コンプライアンス、災害復旧など) の一部として Amazon S3 レプリケーションに固有のコストと使用状況をモニタリングする方法に課題が生じます。 ユーザーは AWS のコストと使用状況レポートを使用して、アカウントおよびその AWS Identity and Access Management (IAM) ユーザーが使用する各サービスカテゴリーの […]

私（Jeff Barr: AWSのチーフエバンジェリスト）がこのブログに初めて投稿したのは（Welcome)、ちょうど 15 年前の今日のことになります。そのとき記した紹介の言葉のために、私のキャリアがこれほど新しくて常に変化する世界に入り込むことになるとは全く考えていなかったと言っても、今なら大丈夫でしょう。それから、このブログがどのように存在することになったかについての物語、私が気に入っている投稿のいくつか、執筆してブログに投稿するために実際に行っていることについてお話しするにもよい頃合いに思えます。 始まりのその前 1999 年前後のこと、私は Microsoft の Visual Basic チームの一員でした。XML が産声を上げたばかりで、Dave Winer が RSS について話し始めた頃です。VB6、XML、そして RSS が出会う交差点は私の好奇心を刺激し、私は片手間のプロジェクトとして Headline Viewer という小さなアプリを作り上げました。それをダウンロードできるようにしておいたところ、みんなはそれを気に入り、コンテンツの所有者は自分の RSS を含めてくれるよう私のところに送ってくるようになりました。フィードのリストは独り歩きを始め、みんなはアプリを欲しがると同じほどリストも欲しがりました。私もまた、サーバーのメルトダウンのため初期の自分の実体とでも言うべきものを失った後、その頃について記す 3 番目の個人ブログを始めました。 Aaron Swartz や他のみんなの激励により、私は Headline Viewer に手をかけるのをやめて、2001 年の末頃、フィードを集め、整理し、共有する Syndic8 立ち上げました。余暇を使って約 90,000 行の PHP コードを書きました。50 以上のテーブルを含む、非常に複雑な MySQL サーバーを中心としたものです。私はデータベースのホスティング、スケーリング、セキュリティ、そして管理について学びました。このサイトには、非常に広い範囲のクエリと更新操作をサポートする、XML-RPC ウェブサービスインターフェイスがありました。フィードのコレクションは最初の二、三年のうちに、ほぼ 250,000 のフィードを含むまでに成長しました。 そのときには気づいていなかったのですが、私の初期の XML、RSS、ブログ、ウェブサービスに関する経験は、やがてアマゾンに就職を申し込む時には、私を目立たせるほどのスキルとなっていました。ときには、私たちの趣味や個人的な関心が、ついにはキャリアを変えさせるほどの資産や特殊能力となることもあるのです。 E コマースとウェブサービス このようなことと並行して、私は 2000 年に Microsoft を退職し、当時は新しかったウェブサービスのコンサルティングを始めました。その当時、使われていたほとんどのウェブサービスは、キュートなデモ、株価情報、天気予報、通貨の変換以外の何者でもありませんでした。技術者なら、インターネットを行き交っていた関数コールを見て驚嘆したでしょうが、投資家は肩をすくめて通り過ぎるだけだったでしょう。 […]

Amazon QuickSight は、QuickSight アクションを通じて強化されたダッシュボードの対話機能を提供するようになりました。QuickSight アクションは、ダッシュボードでの単一のポイントアンドクリック操作を通じて高度なフィルタリング機能を提供します。アクションによって、ダッシュボード内のビジュアルをリンクして、あるビジュアル上の次元ポイントを選択すると、ダッシュボード内の他のビジュアル上の選択したポイントに関する詳細な洞察が得られるようにできます。したがって、概要から始めて、すべて同じダッシュボードシート内でビジネスメトリクスの詳細を掘り下げることができます。ダッシュボード内のどのビジュアルがインタラクティブであるか、これらのビジュアル間での相互作用を定義できます。この記事の執筆時点で、QuickSight アクションでは、フィルターアクションと URL アクションの 2 つの主要な対話機能を定義できます。Amazon QuickSight 内の URL アクションは新しいものではありませんが、URL アクションを作成するためのエントリポイントがアクションに統合されました。 QuickSight アクションは、少なくとも 1 つのディメンションを保持するサポート対象チャートに適用できます。この記事では、アクションの開始、ダッシュボードでのさまざまなアクションの設定、および設定されたアクションごとにさまざまな形式の対話機能を有効にする例を示します。 この記事では、次のデータセットを使用します。 B2B Sales このデータセットは、2016 年と 2017 年の架空の会社 ABCDO の注文詳細を保持しています。構築するダッシュボードは、業界、セグメント、地域別の販売指標を主要なディメンションとしてレポートし、購入された各注文のきめ細かい詳細も提供します。 Product Availability このデータセットは、ID ごとにすべての製品の利用可能な数量を保持しています。 前提条件 Amazon QuickSight ダッシュボードにアクションを実装する前に、ダッシュボードを作成および公開する方法を確認してください。 QuickSight アクションの使用を開始する このスクリーンショットは、上記の 2 つのデータセットから作成されたダッシュボードです。1 行目にカテゴリ、業種、地域ごとの売上。2 行目には四半期ごとの分野売上、分野ごとの業種売上。3 行目には総利益、売上、割引、販売数量。4 行目には注文詳細のピボット、5 行目には配送詳細のピボットを示しています。 始める前に、以下の用語に注意してください。 ソースビジュアル – アクションが作成されるビジュアルです。ソースビジュアル上のポイントを選択すると、アクションがトリガーされ、選択したディメンション値がフィルターとしてターゲットビジュアルに渡されます。 ターゲットビジュアル – ソースビジュアルで選択したディメンション値によってフィルタリングされるビジュアルです。 アクティベーション – […]

AWS CloudFormation を使うと、インフラストラクチャ全体を、テキストによりモデリングできます。この方法により、インフラストラクチャをコードのように扱うことが可能になり、ソフトウェアのバージョン管理やアーキテクチャ上の変更をデプロイ前にチームでレビューするなど、ソフトウェア開発のベストプラクティスを適用できるようになります。 初期段階でコンソールや AWS Command Line Interface (CLI) から作成された AWS リソースは、CloudFormation での管理が必要となる場合があります。たとえば、お客様 (あるいは他のチーム) で、 IAM ロール、仮想プライベートクラウド、または RDS データベースなどを移行の初期段階で作成し、その後、それらを同じスタックに組み入れ最終的なアプリケーションの形に仕上げるための作業時間を割いているとします。こういった場合、CloudFormation を使いリソースをゼロから再作成して、オリジナルのリソースから設定やデータを移行することも多くなります。 お客様によるこれらの手順を簡単にするため、 今回、CloudFormation スタックに既存のリソースをインポートすることが可能になりました。 リソース自体を削除せずに、スタックから除外することは、これまでも DeletionPolicy を Retain に設定することで可能でした。ここに、新なインポート機能も加わることで、利用範囲がさらに広がります。例として、現状では次のことが可能です。 既存リソースをインポートしながら新規のスタックを作成する。 すでに作成済みのスタックに既存リソースをインポートする。 スタック間でリソースの移行をする。 検出されたドリフトを修復する。 親スタックから子スタックを削除した後、別の親からインポートし直すことで、 ネストされたスタックのリファクタリングを行う。 CloudFormation スタックに既存リソースをインポートするには、以下のことが必要です。 インポートするリソースと (既存の) スタックに既に組み込まれているリソースを含む、スタック全体を記述したテンプレート。 インポートする各リソースのテンプレートには、 DeletionPolicy 属性が必要です。これにより、オペレーションの巻き戻しが安全かつ簡単に行えるようになります。 各ターゲットリソース固有の識別子。例としては、インポートをしたい Amazon DynamoDB テーブル、もしくは Amazon Simple Storage Service (S3) バケットの名前などが挙げられます。 リソースのインポート処理中、CloudFormation では次のことをチェックします。 インポートされるリソースが、同じリージョンにある別のスタックに属していないか (IAM ロールなどグローバルなリソースの場合ご注意ください) […]

先日 (2019/11/07) 開催しました AWS Black Belt Online Seminar「 AWS認定にチャレンジしよう – まずはクラウドプラクティショナーから 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20191106 AWS Black Belt Online Seminar AWS認定にチャレンジしょう – まずはクラウドプラクティショナーから from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 試験の予約画面で、「このサイトのご利用を続けるには、人口統計学情報を更新/確認してください」が表示されますが、これはブラウザーの設定の問題でしょうか？ A. ログイン後にこのメッセージが表示された場合は、「人口統計」のリンクをクリックして、プロファイルのアップデートをお願いいたします。 Q. 会社が変わって、APNパートナーから一般ユーザーになったため、メールアドレス等が変更になっているのですが、問い合わせ先や変更手順に関してご教授いただけますか？ A. こちらの「AWS クラウドに関するお問い合わせ」ページより、「AWS トレーニング・認定試験に関するお問い合わせ」内の「AWS の認定試験に関するご質問、お問い合わせ」を選択の上、ご連絡ください。 Q. テストは英語になりますでしょうか。日本語での対応はしておりますでしょうか。 A. 日本語、中国語 (簡体字)、英語、韓国語に対応しています。 — 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。   […]

こんにちは。PSA(パートナーソリューションアーキテクト) の大林です。 11月13日に、「AWS Data Lake ハンズオンセミナー」を開催いたしました。去年から行ってきた恒例のワークショップで第10回目となります。去年から引き続き盛況で、今回も80名以上のお客様にご参加頂きました。 はじめに、AWSにおけるデータ活用のベストプラクティスである Amazon S3 を中心とした Data Lake について解説し、ビッグデータ分析基盤の考え方として有名なラムダアーキテクチャの解説を行いました。 当イベントでは、Amazon Athena や Amazon Redshift の各 AWS サービスを駆使して実際にラムダアーキテクチャを構築することがゴールです。とはいえ全てを構築するのはボリュームが大きいため、スピードレイヤー or バッチレイヤー or 全部入りでコース分けて取り組めるようハンズオンコンテンツを用意しました。最初にコースの説明を行い、出席いただいたお客様ご自身の課題に合わせてコースを選択頂き、ハンズオンを行っていただきました。今回は、サポートするソリューションアーキテクト5名で対応させていただきました。 今回参加できなかった方も、ソリューションアーキテクトのサポートを受けながらハンズオンを行いログ分析を初めてみてはいかがでしょうか？ 「AWS Data Lake ハンズオンセミナー」は、来年も継続開催予定です。皆様のご参加お待ちしております。

 AWS クラウドをデプロイするベストプラクティスには、複数のアカウントや複数のリージョンを使用することが含まれます。複数のアカウントは、リソースを分離し、問題の影響を軽減するセキュリティと請求の境界を提供します。複数のリージョンにより、高度な分離、エンドユーザーの低レイテンシー、およびアプリケーションのデータ復元力が保証されます。これらのベストプラクティスには、複雑な問題のモニタリングとトラブルシューティングが伴います。 集中運用チーム、DevOps エンジニア、およびサービス所有者は、複数のリージョンおよび多くのアカウントで実行されているアプリケーションを監視、トラブルシューティング、および分析する必要があります。アラームを受信すると、オンコールエンジニアはダッシュボードにログインして問題を診断する必要があり、他のアカウントにログインして複数のアプリケーションコンポーネントまたは依存関係の追加のダッシュボードを表示する必要があります。サービス所有者は、サービスの可用性に影響を与える可能性のあるアプリケーションリソース、共有リソース、またはアプリケーション間の依存関係を可視化する必要があります。複数のアカウントおよび/または複数のリージョンを使用すると、根本原因の分析のためにコンポーネントを相互に関連付けるのが難しくなり、解決までの時間が長くなります。 本日発表された Amazon CloudWatch クロスアカウントクロスリージョンダッシュボードにより、お客様は高レベルの運用ダッシュボードを作成し、ワンクリックでさまざまなアカウントの特定のダッシュボードへのドリルダウンを利用できます。その際、異なるアカウントへのログインとログアウト、またはリージョンの切り替えを行う必要はありません。アカウントおよびリージョン全体のパフォーマンスおよび運用データを可視化、集計、および要約する機能は、摩擦を軽減し、解決までの時間を短縮するのに役立ちます。クロスアカウントクロスリージョンは、たとえば他のアカウントやリージョンのアラーム/リソース/メトリックのみを表示したい場合、ダッシュボードを構築せずにナビゲーションのみに使用することもできます。 Amazon CloudWatch クロスアカウントクロスリージョンダッシュボードアカウントのセットアップ クロスアカウントクロスリージョンダッシュボードの使用は簡単で、必要に応じて AWS Organizations と統合することもできます。Organizations を使用して複数の AWS アカウントを制御および管理することにより、この記事でこれから紹介するとおり、ログインせずに、CloudWatch コンソールを使用して組織内のどのアカウントの titletitleAmazon CloudWatch ダッシュボード、メトリクス、アラーム間でも移動できます。もちろん、単一のアカウントに対してクロスリージョンダッシュボードをセットアップすることもできます。この記事では、Organizations との統合を利用します。 このブログ記事の助けになるように、Organizations コンソールを使用して組織を作成し、他のいくつかのアカウントを参加させました。前述のように、Organizations を使用すると、後でダッシュボードを設定するときにアカウントを簡単に選択できます。また、Organizations を使用せずにカスタムアカウントセレクターを事前入力することもできます。これにより、ダッシュボードを作成する際、アカウントを覚えたり、必要なときにアカウント ID を手動で入力したりする必要がなくなります。組織のセットアップ方法の詳細については、「AWS Organizations ユーザーガイド」を参照してください。組織のセットアップが完了したら、アカウントの設定を開始する準備が整いました。 私の最初のタスクは、ダッシュボードを作成するアカウントを識別して設定することです。これが私のモニタリングアカウントです (そして、複数持つことができます)。次に、モニタリングするアカウント (Organizations のメンバーアカウントと呼ばれる) を識別する必要があります。これらのアカウントは、モニタリングアカウントとデータを共有するように設定します。このモニタリングアカウントには、CloudWatch が各メンバーアカウントでロールを引き受けることを許可するための Service Linked Role (SLR) が必要です。クロスアカウントのクロスリージョンオプションを有効にすると、コンソールはこのロールを自動的に作成します。各メンバーアカウントを設定するには、アカウント内からモニタリングアカウントとのデータ共有を有効にする必要があります。 モニタリングアカウントから始めて、CloudWatch コンソールホームから、左側のナビゲーションパネルで [Settings] を選択します。Cross-Account Cross-Region がページの上部に表示されているので、[Configure] をクリックして開始します。 これにより、データ共有を有効にするためにメンバーアカウントでも使用する設定画面が表示されます。今のところ、モニタリングアカウントで [Edit] オプションをクリックして、クロスアカウントのクロスリージョンオプションを表示します。 モニタリングアカウントの最後のステップは、AWS Organization […]

多くのエンタープライズやビジネスが、データストレージ要件に対するメリットを、AWS ストレージサービスから得られる立場にいらっしゃるでしょうし、多くの場合、それに気付いてもいないかもしれません。AWS に飛び乗る準備はできているという一部の方たちも、その仕様については把握しきれていないことと思います。AWS では、そういった事情を考慮し、ストレージサービスのオプション追加に加え、皆様のビジネスニーズに対応できる機能の追加も継続的に行っています。これから開始するお客様がデータストレージの要件に最も適したサービスを選択しようとしている場合、あるいは、現状でご使用のストレージについて、その組み合わせを最適化する知識を学ぼうとしている場合でも、一歩進んだトレーニングリソースはお力添えになれると思います。AWS トレーニングと認定には、AWS ストレージに関する 30 を超えるトレーニングコースが用意されています。これらのトレーニングはデジタルフォーマットで提供されるので、お客様と同僚の方達は時と場所を問わずオンラインで学習していただけます。さらに、ご提供しているデジタルコースは完全に無料です。 以下のリストで、ストレージにフォーカスした全コースについてご確認ください。複数の機能について、基礎、中級、上級の各レベルでコースが用意されています。AWS ストレージ初心者の方であれば、「AWS Storage Offerings」コースがお勧めです。ここでは、多くの AWS ストレージサービスのご紹介をしています。このコースを手始めに、学ぶ範囲を広げていくことができます。ご自身の要件に合ったコースを AWS ストレージのためのトレーニングページから選択する際、下のリストをご参照ください。 ストレージ以外にも関心があり、ご自身の仕事内容に関係するトレーニングにも時間を割きたいとお考えですか? ご用意したコースには、アーキテクト、開発者、DevOps の方達が、仕事上のスキルを向上させるためのものもあります。これらのコースではインストラクターの指導を受けつつ実験が行え、その内容にはクラウドソリューションの設計法、クラウド向けの開発法、クラウドのインフラストラクチャを管理およびモニタリングする方法などが含まれます。AWS トレーニングと認定にも、そういった職務のための認定が含まれますので、ご自身のスキルが仕事に適合しているかを検証することが可能です。各職務とソリューション領域に関するラーニングパスはこちらでご確認いただけます。 AWS トレーニングと認定により、お客様は実践的なクラウドスキルを通じて、適正や自信そして信頼を獲得することができ、将来のキャリアを革新的なものとして構築できます。当社のコースに参加し、早速トレーニングを始めてください。 このブログ記事にあるコメントセクションでは、皆様のお気に入りのコース、あるいは、学びたい内容になどに関するご意見をお待ちしております。AWS トレーニングと認定ウェブサイトでご自身に合ったトレーニングを見つけましょう。

先日 (2019/10/29) 開催しました AWS Black Belt Online Seminar「 Elastic Load Balancing (ELB) 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20191029 AWS Black Belt Online Seminar Elastic Load Balancing (ELB) from Amazon Web Services Japan   AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. なぜ NLB だけ暖気不要なのでしょうか？ A. AWS Hyperplaneと呼ばれる特殊なAWS独自の負荷分散技術を用いているためです。 AWS Hyperplaneに関しては、こちらの資料のP17 – P21をご確認ください。 Q. ALB のルーティング機能を用いると API Gateway を用いた時と同じようなかたちで REST API などの Web […]

本投稿は Richard Nguyen と Michael Hausenblas による寄稿を翻訳したものです。 コンテナセキュリティは、開発者、セキュリティ運用エンジニア、およびインフラ管理者を含む、さまざまなアクティビティとツールで構成されます。クラウドネイティブサプライチェーンの重要な要素の 1 つは、コンテナイメージをスキャンして脆弱性を検出し、そこから行動に移せる洞察を得ることです。 私たちはコンテナロードマップのIssue 17で、AWSネイティブソリューションを提供することがいかにお客様にとって重要であるかを学び、そして、ECRイメージスキャン機能を一般公開いたしました。この投稿では、ECR ネイティブのソリューションについて説明し、ユースケースの一つである「定期スキャン」の実装戦略を説明します。 Scanning 101 最初にコンテナスキャンに関する用語を解説し、前提知識を合わせましょう。 コンテナスキャンに精通している場合は、このセクションをスキップいただいても大丈夫です。 概念的には、コンテナセキュリティの一部としてのスキャンは次のようになります。 コンテナ化されたアプリケーションを見てみると、開発者（developer）がContinuous Integration（CI）パイプラインでコンテナイメージをbuildし、これらのアーティファクトをECRにプッシュしています。一方、セキュリティ運用エンジニア（secops）は、1つもしくは複数のECRリポジトリと、ECSやEKSなどのコンテナオーケストレーターを管理しています。この文脈でいうと、コンテナセキュリティは共同の責任であるということに着目することが重要で、developerと secops の役割は、クラウドネイティブのサプライチェーン全体のセキュリティに対処するために連携しています。たとえば、developerは、コンテナのUSER を定義し、イメージ内の不要なビルドツールを削除して攻撃対象領域を最小限に抑えるといった、セキュアなコンテナイメージをbuildするための推奨プラクティスに従います。同様に、secops も、runtimeポリシーを検証して適用するといったことを行ないます。 さらに、2種類のスキャンに分類することができます。 Static scanning (静的スキャン) ：デプロイ前のフェーズで実行されるため、developers (もしくは secops) はコンテナが実行される前に脆弱性に気づくことができます。ECR イメージスキャン機能は、このカテゴリに分類され、コンテナイメージ内の OS パッケージをスキャンして、既知のセキュリティ上の脅威公開リストである共通脆弱性識別子 (CVE) を検出します。ECR イメージスキャン機能を利用すれば、独自のスキャンインフラを設定したり、サードパーティのスキャンライセンスを購入したりする必要はありません。 Dynamic scanning (動的スキャン)：ランタイム環境で実行されるスキャンのことです。テスト環境、QA 環境、または本番環境で、すでに実行されているコンテナの脆弱性を特定することが可能であり、ビルド時点でインストール済みのソフトウェアに脆弱性が含まれていることが後日発覚した際や、ゼロデイの脆弱性なども検出可能です。動的（またはランタイム）コンテナセキュリティについては、CNCF Falcoなどのオープンソースソリューションから、Aqua Security、Trend Micro、Twistlock など、AWS コンテナコンピテンシーパートナーが提供するサービスまで、サードパーティ製のさまざまなオプションが利用可能です。 みなさまからお寄せいただいたフィードバックとさまざまな選択肢の評価結果に基づき、我々は人気のあるオープンソースプロジェクトであるCoreOS ClairをECRイメージスキャン機能で利用して脆弱性の静的解析を実行することに決定しました。イメージスキャン機能を備えるように ECR API、AWS CLI、SDK の拡張を行い、CI パイプラインやコマンドラインで使用しやすい形で、スケーラブルで信頼性の高いマネージドサービスを実装しました。 具体的な現実世界のユースケースから始めましょう。ECRでのコンテナイメージの定期スキャンです。 […]