Category: General

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

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。 今日はリザーブドインスタンス（RI）の運用に役に立つツール、AWS Cost Explorerをご紹介します。リザーブドインスタンスはオンデマンド料金に比べて大幅な割引価格 (最大 75%) が適用される非常にコスト効果の優れたソリューションですが、購入後正しくそのライセンスが適応されているか、どれくらいRIで稼働インスタンスがカバーされているか、RIを追加で購入しコスト削減が見込めるか？等の確認が難しい、というお問い合わせをよくいただきます。 このCost ExplorerではAWSアカウントにおけるRIの利用状況をグラフィカルに表示してくれるツールがあり、RIを運用されているお客様にとってとても便利なツールとなります。 Cost Explorerには大きく3つの機能があります。 1. RIの使用状況(適用率)を確認できるRI Utilization 2. 稼働インスタンスに対するRIのカバー率を確認できるRI Coverage 3. 利用状況に応じたRIの提案を行なうRecommendation 現在対応しているサービスはAmazon EC2, Amazon RDS, Amazon Redshift, Amazon ElastiCache, Amazon Elasticsearch Service の5つです。 Cost Explorerへのアクセス URL：https://console.aws.amazon.com/billing/home#/costexplorer もし正しく表示されない場合は、以下の手順でコストエクスプローラーを有効化してください。 https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/ce-enable.html 画面左の[Cost Explorer]から各レポートへのアクセスが出ます。試しに[Cost & Usage]へアクセスしてみましょう。 AWSアカウントの費用状態が可視化されて表示されています。（Amazon Neptune や Amazon SageMakerが最近は動いていることがわかりますね！）この画面では、いろいろと値を操作することで別のデータを出すこともできますし、CSV出力も可能です。例えばRegion単位でコストを見ることもできます。 Reserved Utilization（予約の利用率） では2つ目のレポート。本題のRIの利用状況がわかる画面へ遷移してみます。 右側ペインでRIを適応可能なサービスを選ぶと、左側のペインに削減可能額や、（すでにRIを購入済の場合）削減された額などが表示され、全体像を一覧として把握することができます。ここで出てくる[ターゲットライン]は少し考え方がややこしいので注意が必要です。 お客様の中には、RIによるコスト削減とオンデマンドでいつでも変更可能なインスタンス構成を保持するために、意図的にRIを購入せず、オンデマンドで保持されるケースがあります。その場合例えばターゲットを80%と設定することで、残り20%をオンデマンドインスタンスに残しておくことでコスト削減と変更可能な柔軟性を両立することができます。 画面下には購入済RIの一覧が出てきます。こちらをクリックすることでさらに詳細なレポートを入手することができます。   […]

こんにちは、AWSソリューションアーキテクトの小林です。7月も中旬にさしかかり、そろそろ梅雨明けが待ち遠しい感じになってきました。まだ若干肌寒いのでシーズンは未だ来たらずですが、夏に食べたくなるのは素麺ですね。私は素麺が好きなのですが、いろいろな食べ方を工夫しています。最近お気に入りの食べ方は、麺つゆに種を抜いた梅干しを溶いて食べるやり方です。酸っぱい梅干しを使うのがコツなのですが、蒸し暑い時期にぴったりの爽やかな味になりますので、ぜひお試しあれ。

アマゾン ウェブ サービス（AWS）では2019年 夏にクラウドサポートエンジニア（CSE）とソリューションアーキテクト（SA）の新卒向けインターンシップを開催します。今回の記事では昨年度AWSのオフィス（目黒）で行われたCSEインターンシップについてご紹介します。   クラウドサポートエンジニア（CSE）とは アマゾン ウェブ サービス（AWS）は、世界中で数百万のお客様に選ばれているクラウドサービスです。クラウドサポートエンジニア（CSE）は、AWSをご利用頂いているお客様の技術的課題の解決や、より効果的に使っていただくための提案をするエンジニアポジションで、お客様からのサポートケース（テキスト/電話/チャット）を通し、サービスの使い方からアーキテクチャのベストプラクティス、高度なトラブルシューティング方法など様々な技術情報を提供し、より良いソリューションを提案します。また、カスタマーコミュニティへのチュートリアルの提供や技術関連記事の投稿、各種イベントへの登壇などAWSの啓蒙活動も行なっており、活動は多岐に渡ります。最先端の幅広い技術領域の習得と活用ができるポジションです。   CSEインターンシップの概要 CSEインターンシップは、クラウドサポートエンジニアの業務の一部や問題解決の手順を実際に体験できるプログラムです。本インターンシップでは、AWSのサービスについて実践的な研修を受け、個人及びグループ課題に取り組みます。ご自身の技術力を活かすことはもちろん、研修や課題解決を通してスキルアップを目指すことも可能です。また、新入社員や海外で活躍する日本人エンジニアとのオンライン座談会も予定しておりますので、AWSの社風、キャリアパス等についてもご理解いただける場となります。   以下は昨年のインターンシップにおける実際のスケジュールです。 Day 1 【AM】CSEの仕事紹介、ハンズオン 【PM】CSE疑似体験ゲーム（トラブルシューティング） Day 2 【AM】SAの仕事紹介、アイデアソン 【PM】プロジェクト（AWSを使ったアプリケーション作成） Day 3 【AM】AWSの紹介、プロジェクト（続） 【PM】サポート事例の紹介、プロジェクト（続） Day 4 【AM】シアトルCSEとのオンライン座談会、プロジェクト（続） 【PM】ダブリンCSEとのオンライン座談会、プロジェクト（続） Day 5 【AM】プロジェクト（続） 【PM】プロジェクト発表会、オフィスツアー         インターンシップ参加者の声 昨年のインターンシップへ参加し、現在CSEとして活躍している東 峻太朗さんと栗原 佳輝さんの声をインタビュー形式でお届けします。   Q）お二人がインターンシップに参加したきっかけは？   東）“AWS” という単語をたまたま耳にし、「ネットで調べてみるか」と興味本位で調べるうちに、インターンシップの存在を発見しました。CSEはAmazon の IT 部門なのかな？と最初は思っていましたが、提供しているサービスやお客様活用事例等を見ているうちに、「何か新しそう、面白そうな予感がする」「インターンシップに行って、会社のことをより詳しく知りたい！」と、そんな気持ちになりました。 栗原）大学院1年生の夏に就活に向けてインターンシップ先を探していたのですが、研究室の都合上あまり長期のインターンシップに応募することはできませんでした。そんな中、先輩から AWS が大阪で5日間の短期インターンシップを開催することを教えていただきました。最初は AWS のことをよく知りませんでしたが、調べていくうちに […]

みなさん、こんにちは。AWSソリューションアーキテクトの下佐粉（しもさこ）です。 今週も週刊AWSをお届けします。このシリーズでは、毎日のようにリリースされるAWSの新機能や新サービスを一週間単位でコンパクトに紹介しています。毎週火曜か水曜ぐらいを目処に更新しています。 6月はAWS Summit Tokyo & AWS Summit Osakaという2つの大きなイベントがあったのですが、これの対応でバタバタしていたら7月になっていました。もう1年の半分が終わってしまったのかと思ってビックリしています。今回は7月第1週アップデートからのピックアップですが、米国は7/4が独立記念日（祝日）だった関係でアップデートは7/1～7/3からのピックアップになっています。 では先週のアップデートを見ていきましょう。

IoTデバイスを管理する上で、プロビジョニングは一つの重要な事項です。プロビジョニングとは、IoTデバイスをプラットフォームあるいはシステムに登録するプロセスです。デバイスのブートストラップ処理において、中間者攻撃などを防止するために、デバイスとIoTエンドポイントの間で相互認証を確立することが大事です。デバイス認証で現状最もセキュアな方法はデバイス証明書を使用することであり、一般的にデバイスアイデンティティ管理の第一選択肢でもあります。 このブログでは、AWS IoT CoreとAWS IoT Device Managementでブートストラップ証明書を使ったプロビジョニング方法について深掘りしていきます。AWS IoT Coreは、接続されたデバイスがクラウドのアプリケーションや他のデバイスとセキュアかつ簡単に通信することを実現するマネージド型のクラウドサービスです。AWS IoT Device Managementは大規模なIoTデバイスのセキュアなオンボード、管理、モニタリング、遠隔操作を実現するサービスです。 ブートストラップ証明書とは？なぜ必要なのか？ 今回は、WiFi接続が可能な歯ブラシを取り扱う”SmartTeeth”という架空な会社のユースケースについて考えていきましょう。SmartTeethは歯ブラシの生産をサードパーティに委託しています。サードパーティの生産会社は、歯ブラシがクラウドと繋がる際のデバイス証明書を歯ブラシに組み込む必要があります。ただし、SmartTeethは歯ブラシが顧客の手元に届いてから、クラウドとどのような通信を許可するか制限したいと考えています。 初期の証明書は、歯ブラシがクラウドに繋がって自分自身を登録し、必要な権限一式が付与された証明書をリクエストすることのみを許可している状況が理想的です。さらに、このプロセスが自動化されており、SmartTeethの顧客からは透過的であること、そして歯ブラシが初めて接続する時、クラウドで必要なリソースが全て作成され、初期の証明書と実用フェーズの証明書を入れ替える部分をファシリテートする形が理想的です。 以下の図は歯ブラシの購入後に初期クレデンシャルを実用フェーズのクレデンシャルに置き換えるフローを示しています。     とあるSmartTeethの顧客がブートストラップ証明書をインストールするとします。ブートストラップ証明書は、デバイスの生産段階で各デバイスに実装される一意で低レベルの権限を持つ証明書です。この証明書には、デバイスがIoT Coreに接続し、最終的な証明書を取得するための特定のMQTTトピックとやりとりをする権限のみが定義されたAWS IoTポリシーが紐づいています。 デバイスプロビジョニングワークフロー ブートストラップ証明書を利用したデバイスプロビジョニングには3つのステップが含まれます: デバイス組立 デバイス登録 デバイスアクティベーション デバイス組立 デバイス組立とはデバイス生産プロセスにおいてサプライヤーが証明書をデバイスに埋め込むタイミングを指しています。このタイミングで一意なブートストラップ証明書がデバイスに格納されます。 このアプローチでは以下の条件を満たす必要があります: CA証明書がAWS IoT Coreに登録されており、デバイス証明書の自動登録が有効化されている デバイスには登録されたCA証明書によって署名されたデバイス証明書が生産時に格納されている デバイス登録 デバイス登録とはAWS IoT Coreのモノ(thing)としてデバイスを登録することを指しています。このプロセスでは以下の項目を実施する必要があります: AWS IoT Coreでモノとブートストラップ証明書を登録する IoTポリシーを作成し、ブートストラップ証明書にアタッチする ブートストラップ証明書とモノを関連づける 実用フェーズの証明書を(inactive状態で)AWS IoT Coreでプロビジョンする モノをAWS IoT モノのグループに、またはタイプを追加する ただし、これらを実施する前に、一つ重要なステップがあります。デバイスのサプライヤーは許可されたデバイスのリストを提供する必要があります(これをホワイトリストとも呼びます)。このファイルはデバイスIDのリストのみ、または他の属性情報を含んでいても構いません： cat ./allowed-device-list.txt demo001 demo002 demo003 デバイス登録プロセスでは、許可されたデバイスのリストに照会し、そのデバイスがサプライヤーにより保証されていることを確認します。また、ブートストラップ証明書が顧客指定のCAによって署名されていることも確認します。 […]

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。 AWS Backupが東京リージョンに対応しましたのでお知らせいたします。 AWS Backup は、クラウド内で AWS のサービス全体のデータのバックアップの一元化と自動化を簡単に実行できる、完全マネージド型のバックアップサービスです。 バックアップポリシーを一元的に設定し、Amazon EBS ボリューム、Amazon RDS データベース、Amazon DynamoDB テーブル、Amazon EFS ファイルシステム、AWS Storage Gateway ボリュームなどの AWS リソースのバックアップアクティビティを監視することができます。バックアップ対象には Storage Gateway ボリュームのサポートが含まれているため、作成したバックアップに既存のオンプレミスデータを含めることができます。 バックアップスケジュールを作成することができ、バックアップの開始時刻、バックアップの頻度、バックアップウィンドウを指定し、AWS リソースを自動的にバックアップします。バックアップを自動的に保持または失効させる、バックアップ保持ポリシーを設定することも可能で、自動バックアップ保持管理では、バックアップを保持する期間を限定できるため、古い不必要なバックアップがストレージ利用料金を押し上げることを防ぎ、バックアップストレージコストを簡単に最小化できます。 AWS Key Management Service (KMS) と連携しバックアップデータの暗号化も可能です。 Amazon EBSのバックアップ設定を行うサンプル 1.マネージメントコンソールでAWS Backupの画面にいきます。 2.[バックアッププランの作成]を押し、[新しい作成プランの]を選び、バックアッププランに名前を付けます。 3.[ルール名]を入力し、スケジュールを設定します。[バックアップウインドウのカスタマイズ]を選びバックアップを行いたい任意の時間を選択します。 4.[数時間以内にバックアップを開始]でバックアップを行う時間を指定します。 この設定は3.のの[バックアップウインドウ]の時間と連携して動作します。 バックアップウィンドウは、そのバックアップウィンドウの開始時刻と、ウィンドウの期間 (時間単位) で構成されます。バックアップジョブは、このウィンドウ内で開始されます。使用するバックアップウィンドウがわからない場合は、AWS Backup が推奨するデフォルトのバックアップウィンドウの使用を選択できます。デフォルトのバックアップウィンドウは、午前 5 時 (UTC 時間) 開始に設定され、8 […]

みなさん、こんにちは。AWSソリューションアーキテクトの小林です。AWS Summit Tokyo 2019に引き続き、AWS Summit Osaka 2019も無事に終了いたしました。大阪会場にもたくさんのお客様にお越し頂き、本当にありがとうございました。7/5(金)に東京・大阪双方のサミットのダイジェストと、2019年前半の重要アップデートをまとめてお伝えするウェビナーを開催させて頂きますので、こちらにもぜひご参加ください。どのセッションやコンテンツも学ぶべき点があり、全部ご紹介したいところなのですがが時間制約の都合上、断腸の思いでご紹介する内容の絞り込みを進めています…… 週刊AWSのブログポストはコンパクトにまとめるのをモットーにしています。ですが今週はRE:INFORCEの兼ね合いもあってか、重要なアップデートが多数発表されました。今回は特大号ということで、通常よりは多めになっていますのでご承知おきくださいませ。

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。 AWS Service Quotasがリリースされましたのでお知らせいたします。 AWSのアカウントには、すべてのお客様に可用性と信頼性の高いサービスを提供し、またオペレーションミスなどによる意図しない支出からユーザーを保護するためのクォータ（制限）を実装しています。 従来、その制限値は以下のページにAWSにおける全アカウント共通の汎用の設定値一覧としてまとまっており https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_service_limits.html 個別のAWSアカウントの設定状態を把握することは難しいのが実情でした。 今回実装された新しいサービス AWS Service Quotasでは、AWSアカウント単位、サービス単位で制限値の確認と上限緩和申請を出すことができるようになりました。AWS Organizations と統合し、新しいアカウントでクォータを簡単に設定することもできます。サービスクォータを使用して、AWS Organizations を通じて作成した新しいアカウントに適用される定義済みクォータリクエストテンプレートを設定するだけです。 サンプル：Amazon EC2のサービス制限の確認と緩和申請を行う １．以下のURLへアクセスします https://console.aws.amazon.com/servicequotas/ ２．画面左のAWSサービスを押します ３．AWSサービス、のところに【EC2】と入力します ４．EC2を選択します ５．EC2が持っているサービスのクォータ一覧が表示されます。 ６．例えばVPCで設定できるElastic IPを増やすために [ Number of EIPs – VPC EIPs]を選択してみましょう。 クォータはAWSデフォルトの5が設定されています。 ７．クォーターを引き上げる場合【クォータ引き上げリクエスト】を押します ８．引き上げたい値を入力して【リクエスト】ボタンをおします。以上で申請が完了です。 この際、入力されるべき値は、引き上げたい数ではなく、引き上げ後の絶対値で入力する必要があります。以下のように ダッシュボードで、リクエストの状態が確認できます。   従来は、サポートから個別にチケットを作成する必要がありましたが、この機能によりAWSアカウントの状態を把握しやすくなり、またリクエストも簡易に上げることができるようになりました。従来のサポートチケットでは日本語等ローカル言語でのやり取りとなっていましたが、こちらの機能は全リージョン一括で英語で処理されます。 是非ご利用ください。 – プロダクトマーケティング エバンジェリスト 亀田    

先日 (2019/6/18) 開催しました AWS Black Belt Online Seminar「AWS Config」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190618 AWS Black Belt Online Seminar AWS Config from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 設定タイムラインで、特定時点の設定を反映させることはできますでしょうか？（巻き戻しの意） A. 特定時点の設定を反映させる（巻き戻す）機能はございません。ただし、特定時点の設定内容を確認することができますので、その内容から手動で設定を修正することは可能です。 Q. AWS Configを使うと自動的にCloud TrailがONになるのでしょうか？ A. CloudTrailはデフォルトで有効ですので、AWS Configの利用にかからわずONになっております。 https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-getting-started.html Q. カスタムルールの設定は作成した本人でしか変更ができない認識であっておりますでしょうか。あっている場合、カスタムルールを変更した人が退任した場合の対処方法が確立できるのでしょうか。 A. カスタムルールの設定変更は、作成した本人以外でも、権限をもったユーザであれば可能です。 一例ですが、こちらのフルアクセスのポリシーを持ったユーザでお試しください。 Q. クロスアカウントでConfig等の利用料を発生させるアカウントを１つのアカウントに集中させて、管理することは可能でしょうか？ A. AWS Organizationsを利用したアグリゲータの場合は、AWS Organizationsの組織の一括請求を利用して、他のアカウントのサービス利用料をまとめることが可能です。 （Configのアグリゲータ機能を利用した場合は、Config等の利用料は各アカウントにかかります） Q. SageMakerについて、AWS Configは使えますか ? A. […]