サポーターズ様AWSソリューションアーキテクトの篠原英治(@shinodogg)です。約30名の理系学生の皆さまにAWSのサービスを組み合わせて、実際に動くサーバーレスなアーキテクチャを構築していただくにあたり、そもそもServerがLessとはどういうことか?といったところから解説させていただきました。ハンズオンは参加者同士で協力し合いながら、真剣ながらも楽しく進めていただくことができました。参加していただいた皆さま全員がハンズオンの内容をコンプリートすることができました!!懇親会でも興味深いお話を沢山聞かせていただき、ありがとうございました。今後もAWSの技術メンバーを中心に、このような活動を継続していきたいと思っております。サーバーレス/2-Teirアーキテクチャなハンズオンの開催にご興味がある方がいらっしゃいましたら、お近くのAWSの人間までお声がけいただければと思いますので、よろしくお願い致します。Seminar「AWSサービスの権限管理」の資料公開こんにちは、SAの舟崎です。Seminar「AWSサービスの権限管理」の資料が公開されました。Japanまた、頂いたご質問の回答の一部が以下となります。顧客毎にVPCを切っています。全てのサービスをVPC単位で権限を分離する簡便な方法はあまりありません。いうのもすべてのAPIがVPCを条件に判断できるわけではないからです。従いまして、どうしても干渉を避けたい場合はAWSアカウントを分けるという方法をご検討いただけたらと思います。EC2を構築した後にアプリチームに引き渡して、起動停止のみの権限を与えるという例がありましたが、その際特定のインスタンスのみをWebConsole上で表示させたいと思っています。どのように権限管理を行えばよいでしょうか?というのも、1アカウント内に複数プロジェクトのインスタンスが動いているため、引き渡すアプリチームに関係ないインスタンスはそもそも表示させないようにしたいと考えております。この制御はよく質問いただきますが、マネージメントコンソール上で特定のインスタンスのみ表示を許可することはできません。APIはリソースレベルのアクセス権限をサポートしておりません。Nothingの制御になります。IAMポリシーのアタッチ・デタッチにおいて、AWSが用意している強力なポリシーがあるとのことですが、それらの情報はどこかに公開されているのでしょうか。Webサイトなどで公開しているものではなく、皆様のIAM管理画面から参照いただけます。AWS管理ポリシーと呼ばれるもので、代表的なものはAdministratorAccessやIAMFullAccessなどです。サンプルで出されていたExcelシートのようなものは、どこかで公開されていますか?あれば非常に参考になるのでいただきたいのですが。申し訳ございませんが、こちらの資料は非公開となっております。IAMポリシーのサンプル(例えば、ホワイトリスト方式で中央管理型のポリシー作成する)を掲載しているサイトはありますでしょうか。申し訳ございませんが、ご要望のレベルのサンプルのポリシーは公開しておりません。AWSが用意しているというポリシーは個別に許可・禁止も可能という理解で良いのでしょうか。それともテンプレート的なセットものなのでしょうか。許可・禁止というよりも、どのユーザーやグループにアタッチ・デタッチするか、という操作になります。お客様がIAMの必要な権限をお持ちであれば、AWS管理ポリシーを任意のIAMユーザーやグループにアタッチ・デタッチ可能です。Accessと通常のIAMユーザー(パスワード認証)は併用することができます。MFAを割り当てられているユーザーにはIAMユーザーとパスワード、そしてMFAを利用するようにIAMを設定します。CloudTrailのSwitchRoleイベントを補足すると良いかと思います。クロスアカウントアクセスを行うと、スイッチした「元」のAWSアカウントのCloudTrailにSwitchRoleといイベントが記録されます。このイベントの詳細には、スイッチ元のAWSアカウントのユーザー、スイッチ先のAWSアカウント、スイッチ先のロールが記録されます。ADFSを利用した場合、ユーザーはまずブラウザでADFSにアクセスし、ADのアカウントとADのパスワードを入力します。ADFSがADに認証を依頼し、認証がOKであればマネージメントコンソールへのアクセスのためのトークンを発行します。ユーザーからするとADのユーザー名とパスワードしか入力していないのにマネージメントコンソールにログインできたように見えます。サードパーティ様の製品と関連いたしますので、ベストエフォートのご回答となることをご了承いただきたく思います。AMやAD等)が発行したSAMLアサーションの属性値を取得して決定しています。具体的には’https://aws.amazon.com/SAML/Attributes/RoleSessionName’という属性です。AM側でSAMLアサーションを生成する際にこの属性値に、例えばユーザーのメールアドレスなど組織内で一意かつ全員が必ず持っている情報を利用できればユーザーを特定することは可能です。属性の詳しい条件はこちらをご参照ください。http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.htmlまた一つのIdP上のユーザーを複数のAWSアカウントにマッピングすることもできます。Userのロールをマップする際にAWSアカウントIDも指定する仕組のためです。複数のロールがマッピングされたユーザーは、ログインの際にどのAWS上のロールでサインインするか選択する画面が表示されます。発信元IPアドレスによる制限も可能ですが、CloudFormationなどAWSのIPアドレスからAPIが呼び出される場合には注意が必要です。マネージメントコンソールからロールを作成する際に、「どのAWSサービスを信頼するか」という選択が可能です。「ロールの作成」→「ロールタイプの選択」→「AWSサービスロール」を選択すると、信頼するAWSサービスの一覧がご覧いただけます。詳しくはこちらをご参照ください。多くの方のご参加をお待ちしております。Balancing」資料公開こんにちは、ソリューションアーキテクト小川です。資料が公開されました。下記に資料と、当日頂いたQ&Aの回答と併せて掲載させて頂きます。ELBで可能なバランシング方式を教えてください。ラウンドロビン、セッション数管理等です。セッションが均等になると考えて下さい。TCPはラウンドロビンとなります。限定することが可能です。設定されたリソースからのみの接続に限定することが可能です。負荷テストの仕方でDNSクエリの仕方に注意とのことですが具体的にはTTLを減らすほかにどのような方法がありますか。OS側のDNSキャッシュのクリアも方法の一つと考えています。負荷生成ツール側で、名前解決処理を初回しか行わないことも考えられます。こちらはツールの仕様となりますので、ツール選定時にご注意ください。現時点では対応しておりません。明示的な制限値はございません。場合、基本的にはセッションが均等になります。2をご利用いただくことを推奨しております。以上トラフィックが増加する場合は、ご注意ください。現時点では対応しておりません。経由した通信量となります。通信量の合計となります。インストールも可能です。外部サイトですが、事例も公開されています。アドレスが追加となります。急激に負荷をかける場合は必要となります。以上トラフィックが増加するケースではご注意ください。ご認識の通りとなります。基本的にリソースは共有しません。構築しても相互に影響を及ぼすことはありません。アドレスが変更された際の挙動と承知しておりますが、ご指摘頂いたようなケースに対応する為、スケールアップして新たなELBのインスタンスが作成された場合においても、以前のインスタンスは即時に削除されません。以前のIPアドレスに対して名前解決がされてしまった場合を考慮し、一定期間存在します。具体的な期間に関しては公開されておりません。現時点では対応しておりません。利用料金は同じとなります。今回もたくさんのご参加とご質問をありがとうございました。と7月も開催予定です。皆様のご参加お待ちしております。オンラインセミナーのご案内こんにちは、SAの舟崎です。オンラインセミナーのご案内です。オンラインセミナーは、毎週テーマを決めて開催するセミナーです。AWSの初心者から上級者、ソリューションカットやサービスカットなど、様々な切り口でご提供しています。セミナーはすべて無料です。興味のあるテーマの時は、ぜひご参加ください。BlackBeltオンラインセミナーでは初となるインダストリー(業界)カットのセミナーを開催します。初回は公共分野向けとなります。(0)Bastionホスト経由のSSHセッションを記録する方法Bastionホストは、インターネットのような外部のネットワークから、プライベートネットワークへのアクセスを提供するためのサーバです。Bastionホストは潜在的な攻撃に晒されるため、突破される機会を最小化しておかければいけません。(VPC)内のプライベートサブネット内のLinuxインスタンスに対してSSHコネクションを許可するリスクを緩和するために利用できます。この記事では、BastionホストにLinuxインスタンスとの間で確立された全てのSSHセッションを記録させる方法についてご紹介します。SSHセッションを記録すれば、監査が可能になり、規制要件を順守する手助けとなります。ソリューションアーキテクチャこのセクションでは、ソリューションのアーキテクチャをお見せし、どうやってSSHセッションを記録するためのBastionホストを構成できるかを説明します。この記事の後段で、このソリューションをどのように実装し、テストするかについてのインストラクションを提供します。VPCによって、ユーザーが定義した仮想プライベートネットワーク上にAWSのリソースを起動することができます。EC2インスタンスで稼働します。Linuxインスタンスは、パブリックアクセスのできないサブネットに配置されており、Bastionホストが稼働しているEC2インスタンスに定義されたセキュリティグループからのSSHアクセスが許可されたセキュリティグループが設定されています。次の図に示すように、BastionホストのユーザーはLinuxインスタンスに接続するためにBastionホストに接続します。ユーザーは自身の要件に合うようにこのアーキテクチャを適用できます。Peeringで接続した構成をとることも可能です。重要なのはLinuxインスタンスに対するSSHトラフィックの唯一のソースがBastionホストであることです。SSHセッションを記録するためのこのブログ記事のソリューションはBastionホストのみで稼働し、Linuxインスタンスには特別な設定は必要ありません。Linuxインスタンス上でrootユーザーとしてコマンドを実行することでソリューションを構築することが出来ます。ネットワークセキュリティにとってクリティカルポイントとなるので、Bastionホストを強固にすることがベストプラクティスです。ハードニングには必要のないアプリケーションやサービスを無効にしたり、ネットワークスタックをチューニングしたりすることも含まれます。ついては議論しません。Linuxインスタンスにアクセスする際、SSHサーバであるOpenSSHのデフォルトの挙動では、インタラクティブなシェルが起動します。その代わりに、ここでは、scriptコマンドの中にインタラクティブシェルをラップするカスタムスクリプトを実行するようにOpenSSHを設定します。することで、scriptコマンドがキーボード入力やvimのようなフルスクリーンアプリケーションも含めてターミナルに表示されるもの全てを記録します。replayコマンドを利用して結果ログからセッションをリプレイすることも可能です。セクションのステップ・バイ・ステップの例を参照下さい。ローカルコンピューターとLinuxインスタンスの間に直接接続を作成でき、このソリューションをバイパスできるような幾つかのSSHフィーチャーを意図的にblockしていることに注意して下さい。ログファイルの上書きおよび改竄が可能。restart上記のコマンドはOpenSSHにログイン時にカスタムスクリプトを実行させます。このコマンドはSSHセッションを/var/log/bastionフォルダの中のログファイルに記録します。バケットにコピーされます。これは次のようになります。/usr/bin/bastion/sync_s3この時点で、OpenSSHはSSHセッションを記録するよう構成され、ログファイルはS3に保管されます。SSHを使用してLinuxインスタンス上で実行されたアクションの実行元を特定するために、Bastionホストのユーザーは、Bastionホスト上で個人ユーザーアカウントを持ち、個人のSSHキーペアでログインします。各ユーザーアカウントは、Bastionホストのユーザーがこのソリューションを無効化したり破ったり出来ないよう最低限必要な権限を与えられます。ユーザーアカウントの管理を容易にするため、BastionホストユーザーそれぞれのSSH公開鍵はS3バケットにアップロードされます。一定の間隔で、Bastionホストはこのバケットの中から公開鍵を取得します。新たにユーザーアカウントを作成する際には、SSH公開鍵をBastionホストにコピーし、そのユーザーがキーペアでログインできるようにします。BastionホストがJohnの公開鍵であるjohn.pubというファイルがバケットの中に見つかれば、ユーザーアカウントjohnを作成し、公開鍵を/home/john/.ssh/authorized_keysにコピーします。S3バケットから公開鍵が削除されれば、Bastionホストは関連するユーザーアカウントを削除します。個人アカウントの作成および削除は/var/log/bastion/users_changelog.txtにロギングされます。次のコマンドは個人アカウントを管理するためのシェルスクリプトを作成し、5分毎にそのスクリプトを実行するcronジョブをスケジューリングします。~/mycronBastionホストが稼働するインスタンスに関連付けられたキーペアを配布する時には十分注意して下さい。ログイン可能であり、このソリューションにダメージを与えたり改竄したりすることができるからです。パッチ適用等のルートアクセスが必要なオペレーションはスクリプト化し、自動化することができるので、インスタンスをキーペア無しで立ち上げることも考慮すべきです。S3バケットのパーミッションはバケットあるいはIAMポリシーを使って制限しなければいけません。ログファイルはコンプライアンスチームにのみ読み込み可能とし、SSH公開鍵はDevOpsチームによって管理させる事ができます。ソリューションを実装するソリューションのアーキテクチャをご理解いただいたら、あなたのAWSのアカウントにこのブログのソリューションを実装するために、このセクションのインストラクションに従って下さい。最初に、2つのキーペアを作成してください。最初キーペアはBationホストに関連付けるものです。Linuxインスタンスに関連付けるもので、BationホストユーザーのSSHキーペアとして利用されます。開いて、ナビゲーションバーからリージョンを選択します。タイプし作成をクリックします。してダウンロードします。sshuserという名前で別の鍵を作成するためにステップ3とステップ4を繰り返します。クリックしてください。入力後、後続のオンスクリーンインストラクションに従って下さい。VPCVPC内に新規のルートテーブルによってパブリックアクセスが可能な1つのパブリックサブネットVPC内にインターネットアクセスを持たない1つのプライベートサブネット1つのS3バケット。いうフォルダに保管される2つのセキュリティグループ。Linuxインスタンススタックの作成が完了したら(10分ほどかかります)、CloudFormationコンソールのOutputsタブをクリックし、S3バケット名、BastionホストのパブリックIPアドレス、LinuxインスタンスのプライベートIPアドレスを記録して下さい。フォルダを確認できます。してのログインを提供することを覚えているかもしれません。ソリューションをテストするには、Bastionホストに秘密鍵を保管すること無くBastionホストからLinuxインスタンスへ接続するためにSSHエージェントフォワーディングを利用します。SSHエージェントフォワーディングについては、このブログ記事を参照して下さい。してBastionホストにログインします。sshuser.pem]次のスクリーンショットに示すように、SSHセッションが記録されるというウェルカムメッセージが表示されます。KEYの値を書き留めてください。その後Linuxインスタンスに接続し、コマンドを幾つか実行してSSHセッションをクローズしてください。recorded]exitexitここで、たった今記録されたSSHセッションをリプレイします。それぞれのセッションは2つのログファイルを持ちます。1つはターミナルに表示されたデータを含んでおり、もう一つは、現実的なタイピングとアウトプットのディレイを持ったリプレイを可能にするタイミングデータを含んでいます。して接続してログファイルのローカルコピーからリプレイします。通常の環境では、2つの理由からBastionホストでリプレイをしないで下さい。利用は厳格に避けるべきであるということを思い出して下さい、2つ目は、Bastionホストは、S3バケットのログフォルダに対する読み取り権限を持たず、1日前より古いログはBastionホストから削除されるためです。その代わりに、S3バケットに対してログファイルをダウンロードしてリプレイするための充分な権限を持つ他のLinuxインスタンスを利用して下さい。$LOGFILE.dataこれで、作成したリソースをクリーンアップする為にCloudFormationスタックを削除できます。CloudFormationによって削除される前にS3バケットを空にしておく必要が有ることに注意して下さい。(バケットを空にするを参照)結論Bastionホストは、SSHを利用してプライベートネットワークにセキュアなアクセスを提供するネットワークセキュリティのスタンダードな要素です。このブログ記事ではこのBastionホストにSSHセッションを記録させる方法をお伝えしました。この記録はプレイバック可能で、監査目的に利用可能です。forumに投稿下さい。(翻訳はSA布目が担当しました。主要アップデートのふりかえり」資料公開こんばんは、テクニカルトレーナーの大場です。Seminarの資料が公開されました。主要アップデートのふりかえりを行いました。スピーカーはSAの小林よりお届けしました。Tokyo2016の開催時の状況や注目を集めたセッション、また本年度に行われた主要なアップデートについて、ご紹介しています。2016を改めてお楽しみいただければと思います。QAもブログの最後にまとめております。Japan下記にセミナー時に頂戴したQAを、可能な範囲で記載させて頂きます。ESPカタログと事例大全集を冊子でいただくことは可能でしょうか。Roadshowなどのイベントで入手頂くことが可能です。今のところ日本語のみですが、ご要望が多ければ出版のチャンスもあると思いますのでお知らせ下さい。長いID形式については下記をご参照下さい。現時点においては「新しいフォーマットは、新しく作成されるリソースにのみ適用され、既存のリソースが影響を受けることはありません。」との記述がありますので、新規リソースのみが対象となる予定です。SummitのWebサイトにてご案内をしております。dblink」を翻訳したものです。Redshiftはデータウェアハウス的な用途に特化したRDBですので、並列で多数アクセスされるOLTP的な操作は苦手です。そこでPostgreSQLと組み合わせて使うことでその弱点をカバーしようという内容になっています。Redshiftを活用する上で非常に有益な内容になっていると思いますので、ぜひ読んでみてください。AWSのソリューションアーキテクトSQLベースのデータベースをAWS上で選択しようとする際、いくつかの選択肢が考えられます。どれを選択するかを考えるのは難しいものです。Auroraを選択すべきなのはどういう時でしょうか?これに回答するには、まずワークロードの性質を把握し、その上で別の要素、例えばデータ量やクエリのアクセスパターンを把握する必要があります。設計や機能が異なるAWSサービスがあるということは、それぞれのサービスは異なるワークロードに対して強みや優位性を持っているということです。ジョブに適切なツールを選択するという事は結果としてトレードオフを生みます。場合によってはそのトレードオフが許容できない場合もあるでしょう。組み合わせて使うことで、列指向(カラムナ)ストアと、行指向(行ベース)ストアの間にあるトレードオフをどのように回避するかを説明します。OLAP)に優れています。OLTP)に強みがあります。Redshiftは列指向アーキテクチャを採用しており、これはデータがOLTP型データベースのような行ごとの格納ではなく、列の単位でディスク上は管理されているということです。列指向アーキテクチャは、表にある列のうち一部をクエリするようなケースでディスクI/Oを削減できるというアドバンテージがあります。列単位でデータを格納することで高い圧縮率を実現可能であり、I/Oの削減、より多くのデータ格納と、クエリ速度の向上を実現しています。PostgreSQLは行指向のアーキテクチャであり、少ない数の行に対してセレクト、インサート、アップデートを実行するような、一般的にはOLTPと呼ばれるワークロードでアドバンテージがあります。超並列処理)、シェアードナッシングのアーキテクチャです。Redshiftは、たった1つのクエリを実行する際にも多くのサーバ(ノードと呼ばれます)をまたがってコンピュートリソースを使用するということです。これは大量のデータに対して分析するクエリに素晴らしいパフォーマンスを提供します。対照的に、ほとんどのOLTP型データベースは各クエリの処理に1つのサーバ上の部分的なリソースしか使用しません。このアーキテクチャの差は、多くのOLTP型データベースはより多くの並列クエリを処理できる事に繋がります。Redshiftと比較して各クエリごとに消費するリソースをできるだけ小さくし、効率的に実行できるように設計されているからです。PostgreSQLと組み合わせて利用することは魅力的な提案になります。これら2つは相互に補完しあえるからです。PostgreSQLデータベースはMPP型データベースではありませんが、複数のインスタンスを他のインスタンスにリンクさせる機能を持っています。Redshiftに対して利用可能だということです。Redshiftが互換性を持っていることは、これら2つのシステムを接続して利用することを可能にします。Redshiftで処理をし、その結果をPostgreSQLに戻すことが可能になるのです。PostgreSQLを組み合わせて使うことで以下のメリットが得られます。Redshiftの後処理:例えば結果セットをPostgreSQLでJSONフォーマットに変換する上記ダイアグラムはエンドユーザと2つのデータベースの間のデータ・フローを示したものです。Redshiftに直接接続することも可能です。EC2上に設置し複数DBへの接続管理をシンプルにしても良いでしょう。PostgreSQL」を参照してください。PostgreSQLはリモートへのクエリ実行のための2つのエクステンションを利用できます。wrapper)である、postgres_fdwです。table)の作成を可能にします。外部テーブルはローカルにあるネイティブのテーブルと同じようにクエリできます。現時点ではそのクエリは全てがリモート側で実行されるわけではありません。postgres_fdwはアグリゲーション関数やLIMIT句等をリモートにプッシュダウン(処理をリモートのサーバに任せること)出来ないからです。外部テーブルに対してアグリゲーションクエリを実行した場合、アグリゲーションを実行するために必要な全データが一旦PostgreSQLに全て転送されます。これは大量の行を操作する場合に、利用が現実的では無いほど遅くなってしまいます。一つがdblinkと呼ばれる機能を実現するdblinkエクステンションです。Redshiftに送信するとを可能にします。大量のデータをRedshiftの機能で効率的にクエリし、結果セットだけをPostgreSQLの後続処理に返します。PostgreSQLインスタンスに接続し、以下のSQLコードを実行します。'<password>');上記を詳細に知りたい場合はPostgreSQLドキュメントのdblinkを参照してください。($REDSHIFT$)の間にあるクエリを送信します。decimal))に合わせてレコードセットとして返されます。これはこの後続でのジョイン等の処理を可能にしますこのクエリによるここまでの結果セットは以下の通りです:Redshiftへ投入したクエリから結果が変えると、PostgreSQLは後続処理を実行します。t1;ビューに対してクエリするSQLをより楽に書けるように、ここまでのクエリをビュー(VIEW)として定義することができます。以下がそのベーシックなクエリのビューです。v_sales;UDFを使ったクエリその他の方法としては、UDFを使ったクエリがあります。ビューを使う場合との違いとしては、UDFはその使用時にパラメータを渡すことができます。この前の例では、日付の範囲はクエリの中にハードコートされていました。UDFを使うことでクエリ時に任意の範囲を指定することができます。VOLATILE;この関数はPostgreSQLから以下のように実行することができます。'2008-02-01');このクエリを実行すると想定どおりの結果が返ってきます。マテリアライズド・ビューを利用してデータをキャッシュするデータが頻繁にアクセスされるようなケースでは、マテリアライズド・ビューを利用するのが良い方法になりえます。マテリアライズド・ビューはクエリ結果をキャッシュするため、実行を複数回実行することをスキップすることができます。ダッシュボードで頻繁にアクセスされる小規模なデータをキャッシュしておく場合等に有効です。以下のマテリアライズド・ビューはスポーツを好むユーザの数をカウントし、ステート(state)ごとにグルーピングします。マテリアライズド・ビュー作成のDDLは以下の通りです。Redshiftにクエリが発行されます。Redshiftへはクエリーは発行されず、代わりにPostgreSQLの中で結果セットが作成され、返されます。マテリアライズド・ビューへのクエリは通常のビューへのクエリと同じように利用できます。v_users_likes_by_state;マテリアライズド・ビューが保持するキャシュが有効でなくなる場合もあります。以下のSQLステートメントは、再度元のクエリーを実行することでマテリアライズド・ビューのキャッシュをリフレッシュします。Lambdaを利用することができます。Refreshed.");});});};上記Lambda関数の中ではpgモジュールが必要です。以下のコマンドでインストール可能です。PostgreSQLへデータをコピーする大量のデータがあるようなケースでは、マテリアライズド・ビューを利用するより、dblink関数を利用してデータをPostgreSQL上の表にコピーする方が良い場合があります。これはデータの最新部分だけをコピーすれば良いようなケースで有用です。マテリアライズド・ビューはリフレッシュ時にデータを頭から全体をコピーするために、速度面で不利になります。decimal);PostgreSQLはこのデータを読む際にインデックスを利用して最適化をし、BRINは時系列で並べられたデータにとって適切なインデックスになります。インデックスを作成するためのSQLは以下の通りです。(saletime);以下のクエリはdblink関数を利用してデータを表にインサートする方法を示しています。以下のように差分でデータをインサートすることで、マテリアライズド・ビュー全体をリフレッシュするよりも高速に更新を行います。Redshitに接続し、PostgreSQLの機能を活用する方法を説明しました。頻繁にアクセスされる小規模なデータセットをキャッシュし、大きいデータはマテリアライズド・ビューを作成してリフレッシュするか、データを表にコピーするかを選択することができます。キャッシュされていないデータへのクエリについては、さらに2つの選択肢があります:1つは通常のビューを作成すること、もう一つはUDFを作成し引数を受け取れるようにすることす。Redshiftの組み合わせは他にも多数の活用方法があります。PosrtgreSQL上のPostGISやLDAP(こちらはRDSには存在しないためEC2上に入れたPosrtgreSQLで)を活用する等です。これらについてはこのポストで扱う範囲を超えています。ご質問や指摘がある場合はコメントを残してください。Redshiftを学ぶ私達のお客さまは、データを使ってミッションを遂行したいと考えています。シンプルでコスト効率のよい解析手法の重要性は増す一方です。AWS」を紹介できる事を嬉しく思います。クラウドをデータウェアハウスソリューションのプラットフォームとして活用するための一助となるでしょう。AWS」は新しくリリースされた3日間のコースです。このコースはデータベースアーキテクト、データベース管理者、データベース開発者、そしてデータアナリスト/サイエンティスト向けにデザインされています。Redshiftを使用してクラウドベースのデータウェアハウスソリューションをデザインするための、コンセプト、戦略、そしてベストプラクティスを紹介しますまた、データウェアハウスのために、どのようにデータを収集し、格納し、準備するのかを学びます。S3といったサービスを使用します。加えて、このコースではデータを解析するために、BI(ビジネスインテリジェンス)ツールをどのように使うのかについても学びます。データウェアハウスソリューションを構築し、データからより多くを学ぼうとしている組織の方、現在利用中のデータウェアハウスを拡張しようとしている組織の方へ、このコースの受講をお勧めします。このクラスはAWSおよびAWSのトレーニングパートナーから提供されます(訳注:日本国内では2016年内の提供開始を予定)。開催予定をグローバルトレーニングスケジュールから探してください。Trainingのサイト(英語)にも詳細を記載しています。