Author: AWS Japan Staff


New – AWS Application Discovery Service – クラウド移行計画

1980年代半ばを振り返ると、私はウォールストリートに配置されたシステムを手掛けていました。多くのプロジェクトの制約により、マンハッタンにある高いデータセンターで、数えきれないほどの時間を費やして、デバッグのほとんどをオンサイトで行う必要がありました。データセンターは高層フロア全体を占めていました。

そこでの業務の終わりが近づいたころ、私は非公式のフロアツアーをしてみました。数十年に渡って調達され続けたハードウェアとソフトウェアのおかげで、シアトルにあるリビングコンピュータ博物館と同じくらい面白かったです。有名なブランドとモデルのハードウェアのほとんどがあり、不可解かつ複雑な配線で全体がつながっており、更新や変更作業には非常に不安がつきまとうような、関係者内でのみ理解できる情報とともに置かれていました。

今日では、多くのお客様が上述したようなレガシーな環境の大部分をAWSクラウドへ移行する計画があり、時間をかけて詳細を検討しています!

Application Discovery Service
AWS Application Discovery Service新しいAWS Application Discovery Service (シカゴで開催されたAWS Summitで最初の発表)は、現行環境を調査し、何が起こっているかを見極め、既存のアプリケーションのクラウド移行を成功させるために必要な情報を可視化します。

このサービスはAWS Cloud Adoption Frameworkの重要な部分です。このフレームワークはお客様のクラウドジャーニーを支援します。とりわけ、移行ステップの概要を記載します:

  1. 現在のIT資産を評価
  2. 調査と計画策定
  3. 構築
  4. 稼働

Application Discovery Serviceは、手作業でやる場合には時間がかかり退屈で複雑な処理を自動化するもので、ステップ2に焦点を当てています。

The Discovery Agent
始めるためには、移行元ホストに小型で軽量なエージェントをインストールするだけです。このエージェントは以下のシステム情報を収集します:

  • インストールされたアプリケーションとパッケージ
  • 実行中のアプリケーションとプロセス
  • TCP v4/v6 接続
  • カーネル種別とバージョン
  • カーネル構成
  • カーネルモジュール
  • CPUとメモリーの使用率
  • プロセスの生成と終了のイベント
  • ディスクとネットワークのイベント
  • TCP/UDPのリスニングポートと関連するプロセス
  • NIC情報
  • DNS、DHCPやActive Directoryの利用

このエージェントはオンライン、オフラインどちらでも実行できます。オフライン実行の場合、上述のリストにある情報を収集し、お客様が確認できるようローカルに保存します。 オンライン実行の場合、ポート443を使ったセキュアな接続でApplication Discovery Serviceに情報をアップロードします。この情報は、CLIコマンドとAPI関数の新しいセットによりアクセスできるリポジトリーに保存された後、関連付けられ、処理されます。

エージェントは、Ubuntu 14、Red Hat 6-7、CentOS 6-7、そしてWindows (Server 2008 R2、Server 2012、Server 2012 R2)上で実行可能です。今後オプションを追加する予定もあるので、お客様が必要とするものをぜひ教えてください。

Application Discovery Service CLI
Application Discovery Serviceには、エージェントによって収集された情報を照会するために利用できるCLIもあります。これはサンプルです:

describe-agents – 実行中のエージェントの一覧表示

start-data-collection – データ収集プロセスの開始

list-servers – 収集対象ホストの一覧表示

list-connections – 収集対象ホストで作成されたネットワーク接続の一覧表示。このコマンド(および記載していない他のいくつか)は、アプリケーションの依存関係を特定し、マップするのに役立ちます

Application Discovery Service APIs
いくつかの新しいAPI関数を使って、アップロードされた情報に注釈をつけたり、呼び出したりすることができます:

ListConfigurations – 検出対象ホストのサーバー、プロセス、接続の検索

DescribeConfigurations – 検出対象ホストの詳細情報の取得

CreateTags – 検出対象ホストに分類目的でのタグを追加

DeleteTags – 検出対象ホストからタグを削除

ExportConfigurationsApplication Discovery Service パートナーの分析および移行ツールを使ったオフライン処理と可視化のために、収集した情報をCSV形式でエクスポート

アプリケーションのインベントリーとネットワークの依存関係も、それぞれに適切な優先順位の決定や移行したいアプリケーションを決定するのに役立ちます。

今すぐ利用可能
AWS Application Discovery Serviceは、APNパートナーAWSプロフェッショナルサービスを通じて利用可能です。詳細は、Application Discovery Service User GuideApplication Discovery Service API Referenceを参照してください。

Jeff;

翻訳はPartner SA 河原が担当しました。原文はこちらです。

EC2 Run Commandアップデート – コマンドの管理と共有など

EC2 Run CommandはEC2インスタンスを便利にスケーラブルなやり方で管理することを可能にします(より詳細な情報は、わたしのブログ記事、New EC2 Run Command – Remote Instance Management at Scaleを参照してください)。

本日、この機能にいくつかの機能強化があります:

ドキュメント管理と共有 – カスタムのコマンドドキュメントを作成してほかのAWSアカウントまたはすべてのAWSユーザーに共有することができます。

事前定義コマンドの追加 – いくつかのあたらしい事前定義コマンドを使用してWindowsインスタンスの管理をシンプルにできます。

オープンソースのエージェント – インスタンス用エージェントのLinux版がGitHubのオープンソース形式で利用可能です。

ドキュメント管理と共有
Run Commandから実行するコマンドドキュメントの管理と共有ができるようになりました。これによって変動性を削減してエラーの元を取り除くことができるため管理プロシージャーに追加の厳格性をもたらします。さらにほかのAWSユーザーによって作成され共有されたコマンドドキュメントを利用することも可能です。

この機能はお客様からいただいたいくつかのシナリオをサポートするよう設計されました。あるお客様はひとつのアカウントでドキュメントを作成して同じ組織のなかにあるほかのアカウントに共有したいと思っていました。ほかのお客様は共通のタスクをパッケージして広いコミュニティに共有したいと思っていました。AWSパートナーは共通のセットアップとオファリングに固有の管理タスクをカプセル化したいと思っていました。

こちらが自分のドキュメント、公開されたドキュメント、そして自分に共有されたドキュメントを参照する方法です:

 

ドキュメントをクリックして内容を確認することができます:

そしてどのようなパラメータがあるのかがわかります:

さらに実行する前にドキュメントを調べることができます(とくにドキュメントが共有されたものである場合、これは強く推奨されたベストプラクティスです):

あたらしいコマンドを作成することができます(ビルトインのAWS-RunShellScriptコマンドをシンプルにしたバージョンを使用しています):

最後に、アップロードしてテストしたドキュメントを共有できます。パブリックまたは特定のAWSアカウントに共有可能です:

この機能に関する詳細はCreating Your Own Commandを参照してください。

事前定義コマンドの追加
多くのAWSのお客様はMicrosoft Windowsが稼動しているEC2インスタンスの保守と管理にRun Commandを使用しています。いくつかの共通オペレーションをシンプルに合理化するために設計された4つのあたらしいコマンドを追加しました:

AWS-ListWindowsInventory – インスタンス上のインベントリ情報を収集します(オペレーティングシステム、インストールされたアプリケーション、そしてインストールされたアップデート)。結果はS3バケットに保存できます。

AWS-FindWindowsUpdates – 適用されていないWindows Updateをリストします。

AWS-InstallMissingWindowsUpdates – 適用されていないWindows Updateをインストールします。

AWS-InstallSpecificWindowsUpdates – Knowledge Base (KB) IDで指定された特定のWindows Updateのセットをインストールします。

オープンソースのエージェント
インスタンス用Simple Systems Manager (SSM)エージェントのLinux版がGitHubのhttps://github.com/aws/amazon-ssm-agentで利用可能になりました。

このコードへのプルリクエストのサブミットを歓迎します(詳細はCONTRIBUTING.mdを参照してください)。

いますぐ利用可能
ここで説明した機能はいますぐ利用可能で米国東部(北バージニア)、米国西部(オレゴン)、ヨーロッパ(アイルランド)、米国西部(北カルフォルニア)、ヨーロッパ(フランクフルト)、アジアパシフィック(東京)、アジアパシフィック(シンガポール)、アジアパシフィック(シドニー)、そして南アメリカ(ブラジル)リージョンで今日からつかいはじめることができます。

より詳細は、Managing Amazon EC2 Instances Remotely (Windows) とManaging Amazon EC2 Instances Remotely (Linux)をお読みください。

Jeff;

翻訳は渡邉(@gentaw0)が担当しました。原文はこちらです。

週刊AWS – 2016年4月25日

今日5/6はゴールデンウィークの谷間の平日です。今日はお休みにして、どこかに出かけられている方も多いのではないでしょうか?私は今日は仕事の日ですが外出の予定がありませんでしたので、とあるコワーキングスペースで仕事をすることにしてみました。いつものオフィスとは環境が変わって、案外はかどるものですね。

それでは、いつものように先週AWSの世界で起こった出来事を振り返ってみましょう。

月曜日

4月25日

火曜日

4月26日

水曜日

4月27日

木曜日

4月28日

金曜日

4月29日

また、今週も外部ブログにて数多くの興味深い記事がポストされております。

P.S.
AWSの最新情報はTwitterでもお知らせしています。お気軽に@awscloud_jpをフォローください。
—-
ソリューションアーキテクト 小林正人

AWS CodePipeline が AWS CodeCommit との連携をサポートしました

AWS CodePipeline 内でモデル化されたソフトウェア リリース パイプラインのソース プロバイダとして AWS CodeCommit を選択できるようになりました。パイプラインのソース ステージで CodeCommit リポジトリとブランチを選択できます。

CodeCommit はフル マネージドなソース管理サービスで、企業がセキュアで高いスケーラビリティのプライベート Git リポジトリをホストすることを容易にします。CodeCommit は、独自のソース管理システムを運用する必要性やインフラストラクチャのスケーリングについて心配を不要にします。CodeCommit はソースコードからバイナリまであらゆる物のセキュアなストアとして利用することが可能で、既にお使いの Gitツールとともにシームレスに動作します。

この機能は CodePipeline コンソール、AWS CLIまたは AWS SDKを通じて利用を開始することができます。CodeCommit をソース プロバイダにしたシンプルな Pipeline の作成を学ぶには、こちらをご参照ください

 

CodePipeline のより詳細な情報は:

日本語訳はSA 福井 厚が担当しました。原文はこちらです。
https://aws.amazon.com/jp/about-aws/whats-new/2016/04/aws-codepipeline-adds-integration-with-aws-codecommit/

Redshiftアップデート:バックアップ不要表の指定、トランザクションのロック状況を出力する新しいビュー等

Redshiftに最近追加された新機能や、SASのRedshift対応強化についてアナウンスが出ていましたので、ご紹介します。

BACKUP NO オプションをCREATE TABLEで指定できるようになりました。名前の通り、この指定を付けた表はRedshiftの自動・手動SNAPSHOTでバックアップが取得されなくなります。Redshiftを活用する上で、一次的に中間データを置く表を作成することが良くあるのですが、これまではそのような一時表も自動SNAPSHOTの対象になっていました。このオプションでSNAPSHOT不要な表を指定することで、パフォーマンスの向上と、SNAPSHOTサイズの縮小が期待できます。

参照)BACKUP

MD5ハッシュの文字列を使ったCREATE USER/ALTER USERが利用可能になりました。クラスターバージョン1.0.1046以降で利用可能です。

通常CREATE USERを実行する際には、引数でパスワードを指定する必要があります。これをシェルスクリプトに書いて実行する場合を想定すると、そのファイルからパスワードが漏洩してしまうリスクがありました。今回の機能改善では、予めMD5ハッシュ化した文字列をCREATE USERのパスワードに指定する事が可能になりました。Redshiftは与えられたパスワードをMD5ハッシュ化して格納していますが、これをユーザが直接指定することが出来るようになったわけです。MD5ハッシュ化した文字は簡単にはパスワードに逆変換できないため、漏洩時のリスクを小さくすることが可能です(漏洩しても絶対大丈夫という意味ではありません)。

パスワードとユーザ名を連結した文字列をRedshiftのMD5関数に通すことで、必要なハッシュ化文字列が得られます。詳しくは以下のCREATE USERのマニュアルをご参照ください。PASSWORD引数の書き方の部分に例とともに解説があります。(※執筆時点では英語版にして確認する必要がありました)

参考)CREATE USER
新しいSVV_TRANSACTIONSビューが提供されました。このビューをクエリすることで今実行中のトランザクション一覧が得られます。granted列が’t’になっているトランザクションが、今ロックを保持している、つまり今実行されているSQLです。これが’f’の場合はロックを待っているSQLという事になります。このビューでロック競合で待たされているトランザクションを発見することが容易になります。

参考)SVV_TRANSACTIONS

SAS/ACCESSのRedshift対応が拡張され、自動的なプッシュダウン等がRedshiftに対して有効になりました。これまでもSASからRedshiftへ接続してデータ分析を行う事が可能でしたが、機能拡張され、 Implicit pass-through機能が有効になりました。これはSASへのクエリの一部をSQLに変換してRedshift側に移譲(プッシュダウン)し、パフォーマンスを向上させる事が可能になっています。 SAS 9.4M3から対応されています。この他にも機能拡張されておりますので、詳細はSAS/ACCESSのWebサイトをご覧ください。同様に、分析ソフトとしては、SPSS (IBM)もRedshiftへのプッシュダウンに対応しています。

参考)SAS/ACCESS

(原文):https://aws.amazon.com/jp/about-aws/whats-new/2016/04/amazon-redshift-announces-enhancements-to-data-loading-security-and-sas-integration/

翻訳:下佐粉 昭(@simosako

GE Oil &Gas 社 – クラウドでデジタルトランスフォーメーション

GE Oil & Gas 社は、親会社の General Electric 社によって行われた一連の買収の結果、1980 年代後半に誕生した、同社の比較的新しい部門です。現在、GE Oil &Gas 社は、親会社のデジタル革命を主導しています。下記のゲスト投稿は、GE Transportation の CTO で、以前は GE Oil & Gas 社のクラウド設計者であった Ben Cabanas 氏が、2016 年にオーストラリアのシドニーで行われた AWS Summit における同氏の最新のプレゼンテーションのテーマであった、大規模エンタープライズのクラウド移行に必要な主要ステップについて書かれたものです。

詳細については、AWS によるエンタープライズクラウドコンピューティングを参照してください。

Jeff;


課題と変革
GE Oil & Gas は、GE を前進させる重要戦略である、GE のデジタル革命の最前線に立っています。この部門を取り巻く環境として、この業界は激しい競争とコスト課題に直面しており、技術革新を受け入れることが不可欠になっています。GE の CIO である Jim Fowler 氏が言及しているように、今日製造業で成功するには、デジタルイノベーターになる必要があります。

クラウドへの移行は、GE のこの革新の中核部分です。もちろん、これは、これほどの規模、グローバルリーチ、業界における役割を持った、エンタープライズ内の大きな部門にとって、「言うは易く行うは難し」です。GE Oil & Gas では、11 の異なるリージョンと 7 つのリサーチセンターにおいて、45,000 人以上の従業員が働いています。GE Oil & Gas の掘削システムは世界の海底油田掘削装置の約 85% で使用されているほか、GE Oil & Gas では、業界全体の利益になる、エネルギー関連の研究開発作業に年間 50 億 USD を支出しています。この作業全体を支援するため、GE Oil & Gas では約 900 のアプリケーションを使用しています。GE 全体では、使用されるアプリケーションの数が 約 9,000 にもなります。これらのアプリケーションの多くには 100 人以下のユーザーしかいませんが、事業ビジネスには欠かせないものであり、これらのアプリケーションをクラウドに移行することは大事業です。

GE Oil & Gas のクラウドへの道程は、2013 年後半に少数の目標を設定することで始まりました。GE Oil & Gas では作業現場および生産作業の生産性を向上させる必要がありました。ダウンタイムを短縮するとともにオペレーションを改善できるアプリケーションとソリューションの構築方法が検討されました。最も重要なことは、IT のプロセスおよびインフラストラクチャの俊敏性およびスピードを改善すると同時に、コストも削減する必要があったということです。

反復型のステップ
AWS プロフェッショナルサービスおよび Sogeti と協力し、非常にイテレーティブなアプローチにより、2013 年にクラウドへの取り組みを開始しました。初めは、何がわかっていないかもわかっておらず、アジャイルや、アプリケーションをクラウドに移行する方法について学習する必要がありました。今にして思えば、後日の成功とクラウドの採用を速めることにつながった、極めて重要なステップを踏んでいたのです。例えば、技術上の重要な知的財産を社内に保持できるよう、AWS テクノロジーのトレーニングおよび集中訓練のために 50 人を超える従業員をシアトルに送りました。GE Oil & Gas では、AWS で動作するモニタリング、バックアップ、DNS、および SSO 自動化などの基盤サービスを構築しました。これらにより、約 1 年後、運用成熟度が高まり、クラウドへのプロセスが加速化されました。この間にわかったことは、AWS を使用した方が、これまで社内で達成できたものよりはるかに速いペースでシステムを構築できるということです。

AWS への移行により GE Oil & Gas にコスト/運用面の利点がもたらされた

GE Oil & Gas では耐障害性を実現するような設計を行い、可能な限り多くの機能を自動化して管理時間を削減しました。自動化は最優先で考慮する必要のある事項のため、GE Oil & Gas では、コーポレートガバナンスとセキュリティ作法を犠牲にすることなく継続的な開発をサポートする、疎結合されたマイクロサービスを組み合わせた「ボットアーミー」を作成しました。クラウド内に GE を隔離して保護できるようなスマートな設計を使用してすべてのレイヤーにセキュリティを組み込み、TCO、ベンチマーク、KPI、および業績など、可能な限り多くの項目の測定に着手しました。また、アカウンタビリティをより明確にし、ポートフォリオ内のアプリケーションのアーキテクチャとビジネス価値を把握できるよう、すべての項目をタグ付けしました。

前進
これらのあらゆる努力がいま実を結ぼうとしています。現在までに、TCO を 52% 削減できました。削減に寄与した要素にはいくつかあります。例えば、ボット対応自動化、セルフサービスのプッシュ、動的ストレージ割り当て、状況に応じた低コスト VM の使用、不要なコンピューティングインスタンスの停止、および Oracle から Amazon Aurora への移行などです。これらの節約が達成できたのは、突き詰めて言えば、正しいことを行った結果です。

これまでに得られた別の大きな収穫は、生産性の向上です。より回復性のあるクラウド対応アプリケーションを使用し、セルフサービス機能に注力したため、GE Oil & Gas の環境は、DevOps、ArchOps などその他すべての Ops から、自動化とオーケストレーションを使用して効率的にスケールし、大勢の人員がいなくても移行できる、NoOps 環境に近づきつつあります。また、サポートチケットが 50% 削減できたほか、悪影響のある業務停止およびインシデントが 98% 低減しました。これらは予想外のメリットであり、コスト削減と同じぐらい価値があるものです。

大規模な組織にとって、クラウドへの道のりは長期間にわたるプロセスです。しかし、GE Oil & Gas では明白な利点を見出しており、出力されるメトリックスからいくつかの結論を引き出すことができます。NoOps は GE Oil & Gas の将来像であり、自動化はスピードと俊敏性にとって欠かせませんが、強固なモニタリングおよび自動化を行うにはスキル、時間、およびコストの投資が必要です。一連の必要なスキルと情熱を持つ人員が必須であり、社内に優秀な人材を豊富に擁する必要があります。大きな業務革新で発生する摩擦や抵抗を最小限に抑えるには、社内の業務リーダーおよびアプリケーション責任者との協力が不可欠です。そして、AWS が価値をもたらしてくれるサービスプロバイダであることを、身を持って経験してきました。AWS は、変革により GE Oil & Gas のビジネスと従業員の付加価値を高め、レガシー IT にどっぷり浸かっていた GE Oil & Gas をはるかに俊敏でコスト効率の高い組織へと移行するのをサポートしてきてくれました。

– GE Transportation 最高技術責任者 Ben Cabanas

 

Amazon RDS MySQLにてMySQL 5.6から5.7へ数クリックでアップグレード出来るようになりました

本日よりAmazon RDS for MySQLデータベースにて、MySQL 5.6から5.7へマネージメントコンソールやAPIを使用して数クリックでアップグレード出来るようになりました。

MySQL 5.7では以下の様な新機能が利用可能になり、MySQL 5.6よりパフォーマンスが向上しています

  • Native support for the JSON data type and built-in JSON functions
  • Optimizer improvements for better EXPLAINing, parsing, and query performance
  • GIS Spatial Extensions
  • Improved parallel replication using logical clock mode
  • Improved InnoDB scalability and temporary table performance
  • Improved tablespace discovery during crash recovery
  • Dynamic buffer pool resizing

MySQL 5.7.11へアップグレードを行う前に、RDS for MySQL upgrade documentationをよくお読みになり、アプリケーションの互換性があるか十分にテストを行って下さい。 Amazon RDSではこれらのプロセスを簡単に行うことが出来ます。まず現在のデータベースインスタンスのスナップショットを取得し、スナップショットより新規インスタンスを作成します。この新しく作成したデータベースインスタンスをMySQL 5.7.11へアップグレードし、アプリケーションのテストを行います。

MySQL 5.7.11でアプリケーションが正常に動作することが確認出来たら、AWSマネージメントコンソールでアップグレードを行うデータベースインスタンスを選択し、ModifyオプションよりMySQL 5.7.11を選択し、ウィザードにしたがってアップグレードを行って下さい。アップグレードは標準で次のメンテナンスウインドウで実行されますが、Apply Immediatelyを選択するとアップグレードを即時実行することも可能です。

どちらの場合でも、アップグレードが完了するまでの数分間データベースインスタンスへ接続出来なくなる点ご注意下さい。

翻訳は星野が担当しました。(原文はこちら)

MariaDB audit plug-inがRDS MySQLとMariaDBでご利用可能になりました

MariaDB audit plug-inがRDS MySQL (5.6.29と5.7.11) とRDS MariaDB 10.0.24 にてご利用頂けるようになりました。MariaDB audit plug-inはアプリケーションの問題を切り分けるためや、コンプライアンスに準拠するためにデータベースのイベントのログを取得することが可能です。プラグインの主な機能は以下の通りです。

  • Enabling and disabling the audit plug-in – オプショングループよりプラグインを有効・無効化出来ます。オプショングループにMARIADB_AUDIT_PLUGINオプションが追加されています。このオプションを設定したオプショングループをRDSインスタンスへ付与することでロギングが有効になります。無効にする場合は、このオプショングループをRDSインスタンスから削除します。
  • SERVER_AUDIT_EVENTS変数 – この変数では取得するイベントの種類を設定可能です。(CONNECTION: ユーザが接続・切断したイベント, QUERY: クエリとその結果, TABLE: クエリによってアクセスされたテーブル)
  • SERVER_AUDIT_EXCL_USERSSERVER_AUDIT_INCL_USERS変数 – この変数で、どのユーザを監査対象にするか・しないかを設定可能です。SERVER_AUDIT_INCL_USERSの設定が優先され、標準では全てのユーザが記録対象となっています。

MariaDB audit plug-in for RDS MySQL, MariaDBはRDSが利用可能なリージョン全てでご利用可能です。

翻訳は星野が担当しました。 (原文はこちら)

セキュリティ脆弱性診断サービスであるAmazon Inspectorの一般利用開始

我々は、Amazon Inspectorがプレビューを経て全てのお客様に一般利用可能となったお知らせが出来ることを嬉しく思います。
Amazon Inspectorは、セキュリティ脆弱性診断サービスです。これは、Amazon EC2上で稼働するお客様のアプリケーションのセキュリティやコンプライアンス適合の改善を支援します。Amazon Inspector は、自動的にアプリケーションを評価し、脆弱性やベストプラクティスからの逸脱がないかどうかを確認し、重大性の順に結果を表示した詳細なリストを作成します。Amazon Inspector には、共通のセキュリティベストプラクティスや脆弱性の定義に対応した何百ものルールが収められたナレッジベースが備えられており、それらはAWS のセキュリティ研究者によって定期的に更新されます。
Amazon Inspectorは前払いの投資も必要ありませんし、追加的なソフトウェアライセンスや保守費用、専用のハードウェアも必要ありません。
お客様はご利用分のみの支払であり、それは柔軟なユースケース、たとえば継続的デプロイメントやオートスケールなどへの対応(それらはホスト毎やIP毎の支払モデルでは難しいものでしょう)を提供します。
Amazon Inspectorは、90日の無償利用を含みます。
ぜひともより詳細な情報を得るためにAmazon Inspectorの製品詳細ページをご覧になってください。

 

原文はこちら。日本語訳は市崎が担当しました。

週刊AWS – 2016年4月18日

ついこの間に新年のご挨拶をしたと思っていたら、あっという間に4月も下旬になってしまいました。今週末からゴールデンウィークですが、今年は5/2と5/6をお休みにすると10連休になります。

この機会に旅行に出かける方も多いかもしれませんが、もしも時間が空いたらAWSのことを思い出してみてください!米国時間で4/18,19にAWS Summit Chicagoが開催され数多くの発表が行われました。かなりのボリュームがありますので、この機会に最新情報をキャッチしてみてはいかがでしょうか?(概要はこちらのWebページこちらの資料をご覧ください)

それでは、いつものように先週AWSの世界で起こった出来事を振り返ってみましょう。

月曜日

4月18日

火曜日

4月19日

水曜日

4月20日

木曜日

4月21日

金曜日

4月22日

また、今週も外部ブログにて数多くの興味深い記事がポストされております。

P.S.
AWSの最新情報はTwitterでもお知らせしています。お気軽に@awscloud_jpをフォローください。
—-
ソリューションアーキテクト 小林正人