Author: AWS Japan

昨日、.NET Core 2.0がリリースされ（訳注：このブログ記事の原文は2017/8/15に発行されています）、AWSでは .NET Coreプラットフォームに追加された新機能と完成度にとても興奮しています。今後数か月以内に、AWSサービスをアップデートして、.NET Core 2.0のファーストクラスのサポートを提供します。 2つの簡単な方法ですぐにAWS上で.NET Core 2.0を使い始めることができます。   AWS Elastic Beanstalkの利用 Elastic Beanstalkを使用すると、Webアプリケーションを簡単に展開できます。現在、.NET Frameworkおよび.NET Core 1.1がサポートされています。 Elastic Beanstalkプラットフォームは、すぐに.NET Core 2.0をサポートするように更新されるでしょう。 それまではデプロイメントパッケージをカスタマイズして、デプロイ中のインスタンスに.NET Core 2.0をインストールするようにBeanstalkに指示することができます。 ASP.NET CoreアプリケーションがBeanstalkにデプロイされると、AWS-windows-deployment-manifest.jsonというJSONマニフェストがツールキットによって作成され、Beanstalkにアプリケーションのデプロイ方法を指示します。 以前のブログ記事では、このマニフェストのカスタマイズ方法について説明しました。 この機能を使用して、デプロイ前にPowerShellスクリプトを実行して.NET Core 2.0をインストールすることができます。 最初のステップとして、ASP.NET Core 2.0プロジェクトにaws-windows-deployment-manifest.jsonというファイルを追加します。 aws-windows-deployment-manifest.jsonのプロパティウィンドウで、[Copy to Output Directory]フィールドを必ず[Copy Always]に設定してください。 このファイルは、通常、ツールキットによって生成されますが、ツールキットがファイルがすでに存在することが判明した場合は、代わりにデプロイメントウィザードで指定された設定で既存のファイルを変更します。   次に、下の内容をコピーしてaws-windows-deployment-manifest.jsonに貼り付けます。 これはASP.NET Coreアプリケーションをデプロイし、デプロイの前に./Scripts/installnetcore20.ps1 PowerShellスクリプトを実行することを示しています。   { “manifestVersion”: 1, “deployments”: { “aspNetCoreWeb”: [ { […]

CodePipeline の更新 – CloudFormation スタックの継続的デリバリーワークフローの構築で、 Jeff BarrはInfrastructure as Codeについてと、AWS CodePipelineを継続的デリバリーに使用する方法について説明しています。　本ブログ記事では、ソースリポジトリとしてAWS CodeCommitを、ビルドおよびテストツールとしてAWS CodeBuildを使用した、AWS CodePipelineを使ったネストされたCloudFormationスタックの継続的デリバリーについて説明します。手動承認プロセスに従ってCloudFormationチェンジセットを使用してスタックをデプロイします。 AWS CodePipelineでは、次の4つのステージでパイプラインを作成します。 Source (AWS CodeCommit) Build and Test (AWS CodeBuild および AWS CloudFormation) Staging (AWS CloudFormation　および 手動承認) Production (AWS CloudFormation および 手動承認) 次の図に、パイプラインのステージと、各ステージのアクション、およびステージ間の遷移を示します。 CloudFormationテンプレート、テストスクリプト、およびビルドスペックファイルは、AWS CodeCommitリポジトリに格納されています。これらのファイルは、AWS CodePipelineのパイプラインのSourceステージで使用されます。 AWS::CloudFormation::Stackリソースタイプは、親スタックから子スタックを作成するために使用されます。 CloudFormationスタックリソースでは、S3バケットに格納される子スタックのテンプレートを必要とします。テンプレートファイルの場所は、リソース定義のPropertiesセクションにURLとして指定されます。 次のテンプレートは、3つの子スタックを作成します。 Security (IAM, セキュリティグループ) Database (RDSインスタンス) Web stacks (Auto ScalingグループのEC2インスタンス, ELB) Description: Master stack […]

今回、新ツール、SAM Local のベータ版がリリースされました。これにより、簡単にサーバーレスアプリケーションをローカルに構築してテストできるようになります。この記事では、SAM Local を使用し、クイックアプリケーションの構築、デバッグ、デプロイを実行します。これにより、エンドポイントに curl コマンドを使用してタブやスペースで投票できるようになります。AWS は サーバーレスアプリケーションモデル（SAM）を昨年導入しました。これにより、デベロッパーはサーバーレスアプリケーションをより簡単にデプロイできるようになっています。SAM の基本にまだなじみがない場合は、私の同僚である Orr が SAM の使用方法について書いた素晴らしい記事を参照してください。5 分ほどで読めます。基本的に、SAM は AWS CloudFormation 上に構築された強力なオープンソース仕様で、サーバーレスインフラストラクチャをコードとして簡単に保持できるようにすることを目的としています。また、可愛いマスコットもついてきます。 SAM Localでは、SAM の優れた点をすべてローカルマシンで利用できます。 以下を使って、AWS Lambda 関数をローカルに開発してテストすることができます。 sam local Docker Amazon Simple Storage Service（S3）、Amazon DynamoDB、Amazon Kinesis、Amazon Simple Notification Service（SNS）など、既知のイベントソースからの関数の呼び出しをシミュレートできます。 SAM テンプレートからローカルな Amazon API Gateway を開始し、ホットリロードで関数を素早く繰り返すことができます。 SAM テンプレートを素早く検証し、さらに、その検証を linters や IDE で統合できます。 Lambda 関数についてインタラクティブなデバッグサポートを利用できます。 SAM Local のインストール方法はいくつかありますが、NPM を使用するのが一番簡単です。 […]

なんとも忙しい 1 週間でした。Tara、Randall、Ana と私は、AWS Summit ニューヨークでの発表に関するブログ投稿を休みなく作成していました。手始めにその概要をご紹介しておきます。 Amazon Macie – この新しいサービスは、コンテンツを大規模に検出、分類、セキュリティ保護するうえで役立ちます。Macie は Machine Learning と自然言語処理 (NLP) を使用してパターンを検索し、疑わしい動作について警告します。また、ガバナンス、コンプライアンス、および監査に役立ちます。Tara の投稿をお読みになれば、Macie の使用方法をおわかりいただけます。つまり、対象のバケットを選択し、分類設定をカスタマイズして、Macie Dashboard で結果を確認します。 AWS Glue – Randall の投稿 (豪華なアニメーション GIF 付き) では、この新しい ETL (抽出、変換、ロード) サービスについて紹介しています。Glue はサーバーレスでフルマネージド型です。投稿からおわかりのように、Glue はお客様のデータをクロールし、スキーマを推測して、Python で ETL スクリプトを生成します。お客様は、幅広い変換で場所から場所へデータを移動するジョブを定義し、それぞれをコードで表して人間が読み取れる形式で保存します。Glue は開発エンドポイントとノートブックを使用して、ビルドするスクリプトのテスト環境を提供します。また、Amazon Athena と Amazon Glue の統合や、Amazon EMR での Apache Spark および Hive についても発表しました。 AWS Migration Hub – この新しいサービスは、アプリケーションポートフォリオの […]

Carmen PuccioとMandus Mombergによる記事。 CarmenとMandusは、AWSパートナーソリューションアーキテクトで、移行に注力しています。 オンプレミス環境からクラウドへのソフトウェアやサービスの移行は、独自の考慮事項と要件を伴うことは明らかです。移行結果に自信を持たせるには、容易に拡張できる移行戦略が必要です。つまり、ワークフローの大部分を自動化する必要があります。なぜクラウド内の自動化が重要であるのかに関する文書が不足しているわけではありません。この記事では、AWSアドバンスト・テクノロジーパートナーであるCloudEndureを使用して自動化された移行を実行する方法を説明し、自動化されたテストを組み込むことに重点を置いて、アプリケーションが移行後に期待どおりに動作することを確信できます。 オンプレミスからAWSへのワークロードの移行には、慎重な計画と正確な実行が必要です。クラウドに移行するにはさまざまな戦略がありますが、移行を容易にするツールも数多くあります。すべての移行ツールは、ダウンタイムとアプリケーションワークロードの影響を最小限に抑え、AWSへの移行を容易にし、データ損失を最小限に抑える、という共通の目標を持っています。 ワークロードをクラウドにすばやく移動したい場合、通常リホスト方式（リフト＆シフト）に従います。リホスト実行時の課題の1つは、移行されたアプリケーションが期待どおりに実行されていることを手動で確認するのにかかる時間です。適切な移行を検証するための自動化および迅速なテストパイプラインを組み込んだ移行は、成功する可能性が高いだけでなく、反復可能なプロセスを活用し、手動検証時間を短縮することで効率を向上させます。 ソリューションの概要 このブログ記事で説明するソリューションでは、CloudEndureとAWS Database Migration Service（AWS DMS）を使用し、ソースAmazon VPCから目的のAmazon VPCへ、オンプレミスからAWSへの、Go Gitサービス（Gogs）の移行について説明します。このデモのために2つの異なるVPCを使用していますが、このブログポストで使用しているツールの自動化と組合せによって、オンプレミスからAWSへの移行を容易に実現することができます。CentOS 7が稼働するモックソース環境の設定では、AWS CloudFormationとAnsibleの組合せを選択しましたので、あなたのテスト用AWS環境でご確認することができます。 CloudEndureはアプリケーションサーバの移行を担当し、AWS DMSはEC2インスタンス上で実行されているMySQLサーバからGogs DBを、完全に管理されたAmazon RDSデータベースに再構築する役目を負います。このデモンストレーションのためDMSを活用し、RDSへのデータベースのレプリケート方法を示しました。もう1つの選択肢として、データベース移行において、CloudEndureによるEC2へのリホストを行うことができます。 CloudEndureは起動時に、移行後のインスタンスでカスタム後処理スクリプトを呼び出す機能があります。この機能を使用すると、カスタム構成を実行し、自動化された承認テストを実行して、移行されたサーバでアプリケーションが正常に動作していることを確認できます。 移行の信頼性のため、AWS Lambda、AWS SNS、AWS SQS、CloudEndureの後処理機能を活用して、一連のテストを実行するための自動テストパイプラインを構築しています。すべてのテストが正常に完了すると、ソース環境から構築されたイメージを使用して高可用性Gogs環境をデプロイするAWS CloudFormationテンプレートが自動的に起動されます。 次の図は、この記事で取り上げる移行プロセスを示しています。 プロセスの仕組みは次のとおりです。 Ansibleは、AWS Application Discovery Service、CloudEndureエージェント、およびGogsソースサーバの再設定およびテストに使用されるスクリプトをインストールします。 AWS DMSは、GogsソースDBサーバを宛先RDSインスタンスに移行します。 CloudEndureエージェントが実行されると、ブロックレベルのコピーが開始され、GogsソースサーバとAWSの初期同期が実行されます。 CloudEndureが初期同期を完了すると、Continuous Data Protection（CDP）エンジンは新しいデータのリアルタイム同期を開始し、サーバはAWSでのテスト準備完了としてマークされます。 CloudEndure.pyスクリプトはconfig.ymlファイルのhosttomigrate変数に基づいて移行を開始します。 （この変数は、CloudEndureダッシュボードにインスタンス名として表示されます）。 CloudEndure.pyスクリプトはCloudEndure APIを呼び出し、ソースインスタンスの最新のスナップショットからテストインスタンスを開始します。 CloudEndureは、最新のスナップショットから宛先に新しいインスタンスを起動し、CloudEndure.shポストプロビジョニングスクリプトを実行します。このスクリプトは次の処理を行います。 DMSが複製しているRDSインスタンスを指すようにGogsを再構成し、Gogsサービスを再起動します。 Gogsサービスが稼動しているかどうかを確認します。稼働している場合、CloudEndure.shポストプロビジョニングスクリプトはCloudEndure_PostProcessing.pyスクリプトを呼び出します。このスクリプトはCloudEndure Pass / Fail SNSトピックに成功通知を送信します。メッセージの例は次のようになります。 “Message”: “{“instanceId”: ” i-0bb669daff4b1eea1″,”Pass”: […]

本日とてもエキサイティングなご報告をさせていただきます。LumberyardのソースがGitHubで公開されました。コミュニティーの皆様からの特に多いご要望の1つでしたが、ようやく実現でき大変嬉しいです。こちらのURL（www.github.com/aws/Lumberyard）をご確認ください。 ゲームを制作する事はチャレンジングですが、GitHubを活用することで2つの手法が容易になります。   LumberyardをGitHubから取得できます。 これまでは、Lumberyardを標準インストーラーからインストールする事がLumberyardを入手いただく唯一の方法で、ソースを含めたすべてのLumberyardが新たに別のディレクトリに保存されました。ですので継続的にLumberyardをアップグレードすることはうんざりする作業だったかもしれませんが、GitHubを活用することで劇的に変わります。   本日よりLumberyardソースコードをGitHubリポジトリから容易に直接取得して管理する事が可能となります。新たなバージョンのLumberyardをインテグレートすることも今までよりとてもシンプルな操作で可能です。そして、今後の新たなLumberyardのリリースは別々のブランチで提供されますので、任意のバージョンのインテグレートも可能となります。さらに！あなた自身のGitHubアカウントを作成してGitHubであなたのプロジェクトを管理したり、リモートリポジトリであなたのチームとの共同作業も容易にできるようになります。 Lumberyardの改良やバグ修正を送っていただく事も可能です。 これまでは、Lumberyardの開発者は最大50行までのLumberyardのコードをフォーラムを通して送っていただく事が可能でしたが、簡易な修正にしか適用できませんでした。（このような状況にもかかわらず、これまで修正を送っていただいた皆様に御礼を申し上げます！）本日より、GitHubを活用することで、どのようなサイズの改良やバグ修正でも容易にLumberyardチームに送っていただく事が可能となります。プルリクエストにより、必要となるコードを複数のファイルにまたがるような場合でも、正確な方法で管理できます。皆様からのフィードバックとサポートは我々を突き動かす大きな要因で、皆様とともにこのエンジンを創り上げていける事はとてもエキサイティングです。 メインブランチで安定したLumberyardを提供し続けていく事は我々にとってとても重要ですので、プルリクエストがすぐにはマージされるわけではなく、承認された変更は将来のリリースに反映される可能性があるということにご留意ください。継続的にプルリクエストは確認させていただきます。プルリクエストが採用されました皆様はリリースノートにクレジットさせていただきます！ もう一点、我々のリポジトリからフォークする事も可能です（詳しくはリポジトリ中のReadme.mdファイルをご参照ください）がLumberyardは引き続き「AWS Customer Agreement」と「Lumberyard Service Terms」の元にライセンスされております。この点にご留意いただければ公開リポジトリとすることも可能ですので、ログインせずに取得する事も可能となります。 いつでもお気軽にご意見をお聞かせください。今後の数ヶ月でScript Canvasや新たなアニメーションツール等さらにいくつかのエキサイティングな要素の提供も予定していますのでお見逃しなく！Lumberyardに関します様々な情報はチュートリアルやコミュニティフォーラム、さらにドキュメントからも得られます。 LumberyardのGitHub公開に関します詳細はこちら（www.github.com/aws/Lumberyard）をご参照ください。 本記事の作者について Todd Gilbertsenは1980年台からゲームエンジンの制作、ビデオゲームだけでなく、様々なソフトウエア開発のプロフェッショナルとして活動を続けており、ゲーム開発者がクリエイティブに開発を進めるためのツールやテクノロジーの開発をする事に情熱を注いでおります。ToddはLumberyradのシニア・テクニカルプロダクトマネージャーです。 (翻訳は下田が担当しました。原文はこちら)

【注意】セミナーの実施日程について更新がありました．最新の実施日程は，こちらをご覧ください． こんにちは。プロフェッショナルサービスの宮本です。AWS Black Belt オンラインセミナー9月の配信についてご案内させて頂きます。ソリューションカットでは、AWSにおけるDDoS対策について、サービスカットでは、BlackBelt初開催となる、AppStream2.0や、多くの機能アップデートが行われたサービスを中心にお送りいたします。   9月の開催予定 サービスカット 9/6(水) 18:00-19:00 Amazon AppStream 2.0 9/13(水) 18:00-19:00 Amazon Aurora 9/19(火) 18:00-19:00 AWS DMS ※通常とは異なり、火曜日開催となりますのでご注意ください。 9/27(水) 18:00-19:00 Amazon CloudFront + AWS Lambda@Edge ソリューションカット 9/5(火) 12:00-13:00 AWSでのDDoS対策 お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

Jeffと私が初めてこのサービスを聞いたとき、私たちはMacieという名前の意味が知りたくなりました。もちろん偉大な研究者であるJeffは、Macieという名前を調べ、二つの意味があることを発見しました。フランス語とイギリス英語両方からの語源があり、典型的な少女の名前で、様々な意味を持っていました。Macieの一つめの意味は”武器”を意味する名前です。もう一つの意味は、力強く、さっぱりとした、優しい人の表す名前です。ある意味、これらの定義はふさわしいです。本日、私たちはAmazon Macieという新しいセキュリティサービスの提供開始を喜んで発表します。機械学習によって、AWS上に保存された機密情報の特定し、データ侵害、情報漏えい、Amazon Simple Storage Service (S3)への不正アクセスから保護をします。よって、Amazon Macieが、あなたの保存データを悪意のあるアクセスから保護する、”さっぱりとした”ユーザーインターフェースを備えた”優しい”サービスとして、AWS顧客にとって”力強い””武器”になることを私は想像できるのです。ふー、喋り過ぎました。たった一文でMacieの全てを表現するなんて！やはり、私はみなさんとAmazon Macieの凄さを共有するのに興奮しています。 Amazon Macieは、Amazon S3に保存されているデータを自動的に発見し分類する、機械学習を用いたサービスです。しかし、Macieはそれだけではありません。一度Macieであなたのデータが分類されれば、それらにビジネス価値が割り当てられ、継続的に監視し、アクセスパターンに基づいて疑わしい振る舞いを検知します。Macieの主要機能は以下です。 データセキュリティの自動化：データの分析、分類、処理し、過去のパターン、データに対するユーザー認証、データアクセス場所、アクセス時間を把握する データセキュリティと監視：利用ログデータの監視して異常検知したり、CloudWatch EventsやLambdaによってレポートされる問題を自動解決する プロアクティブなデータ保護のためのデータ可視性：保存データの詳細を管理者向けに可視化すると同時に、手動入力いらずで即時保護を提供する データ調査とレポート：管理者向けにレポーティングやアラートを構成可能にする どのようにAmazon Macieはこれらを実現するのか？ 自然言語解析(NLP)の機械学習アルゴリズムを使って、MacieがS3バケットにあるデータの分類を自動化します。加えて、Amazon Macieはデータアクセスパターンを動的に分析する予測分類アルゴリズムも利用し、学習によって疑わしい振る舞いの可能性を知らせてくれます。Macieは個人特定情報(PII)や機密個人情報(SP)を検知するエンジンとしても動作します。MacieはAWS CloudTrailを利用しながら、継続的にS3バケットへのPUTリクエストのCloudTrailイベントを確認し、自動的に新しいオブジェクトの分類をほぼリアルタイムで行います。 MacieがAWSクラウド上のセキュリティやデータ保護にとって強力な道具であるだけでなく、ガバナンスやコンプライアンス要件、監査基準などにおいてもあなたを助けます。多くの人は既に、現時点でEUの最も厳しいプライバシー規制である、2018年5月25日に施行される一般データ保護規則(GDPR)を知っています。Amazon Macieは個人特定情報(PII)を認識し、ダッシュボードとアラート機能を提供することで、顧客にデータの暗号化や仮名化によるGDPRへの準拠を可能にします。Lambdaクエリと共に利用すると、MacieはGDPRの懸念に対応する協力な道具になります。 Amazon Macieサービスツアー それではAmazon Macieの詳細を見るためのツアーを開始しましょう。 まず最初に、私はMacieのコンソールにログインし、Macieのセットアップ処理を始めます。Get Startedボタンを押すことで私のデータの分類と保護を開始することができます。 下画面の通り、Amazon Macieサービスを有効化するには、このサービス用の適切なIAMロールを作成しなければなりません。また、私のアカウントでAWS CloudTrailを有効化する必要があるでしょう。 私はこれらのロールを作成し、私のアカウントでAWS CloudTrailサービスを有効化しました。Macieをより簡単にセットアップするために、Macieユーザーガイドから提供されているCloudFormationのサンプルテンプレートを利用することもできます。それは、必要なIAMロールとポリシーを作成するので、あとやるべきことはCoudTrailドキュメントに記載されている通りに証跡を設定するだけです。 もしあなたが複数のAWSアカウントをもっている場合は、Macieサービスを有効化したアカウントがマスターアカウントになることに注意してください。他のアカウントもMacieサービスと連携できますが、それらはメンバーアカウントということになります。メンバーアカウントのユーザーは、Macieコンソールにアクセスするために、マスターアカウントへフェデレートアクセスするためのIAMロールを使う必要があるでしょう。 さあ、IAMロールが作られ、CloudTrailが有効化されたら、Enable MacieボタンをクリックしてMacieによるデータ監視と保護を開始しましよう。 あるアカウントで一度Macieサービスが開始すると、サービス画面が表示され、そのアカウントにおける既存アラートが表示されます。今回、私はサービスを開始した直後なので、アラートはまだ存在していません。 Macieサービスのツアーで、ここから私のS3バケットとMacieを連携していきましょう。ただし、Macieが監視を開始するだけであれば、あなたはS3バケットを指定する必要はありませんでした。なぜならサービスは既に情報の分析や処理のためのAWS CloudTrail管理APIを使用しているからです。このMacieツアーでは、私は特定のバケットにおけるCloudTrailのいくつかのオブジェクトレベルAPIイベントを監視しようと思います。 S3と連携するために、MacieコンソールのIntegrationsタブに移動します。Integrationsタブでは、二つの選択肢：AccountsとServicesがあります。AccontsオプションはメンバーアカウントがMacieと連携するために使用され、あなたのデータ保存ポリシーを設定します。特定のS3バケットとMacieを連携したい時は、ServicesタブからServicesオプションをクリックします。 MacieとS3サービスを連携させると、証跡とS3バケットが作成され、S3データイベントに関するログが保存されます。始めるには、Select an accountドロップダウンを使いアカウントを選択します。アカウントが選択されると、連携可能なサービスが表示されます。Addボタンをクリックして、Amazon S3サービスを選択します。 さて、Macieに分析させたいバケットを選択したので、Review and Saveボタンを押して確認画面に行き、オブジェクトレベルロギングを行うことを確認してからSaveボタンをクリックします。 次に、このMacieツアーでは、どのようにMacieのデータ分類をカスタマイズするか見ていきましょう。 前述の通り、Macieは自動的にあなたのデータを監視し、分類します。Macieがあなたのデータを特定すると、ファイルとコンテントタイプでそのデータオブジェクトを分類します。また、Macieはサポートベクターマシン(SVM)も使用し、ファイルのメタデータに加えてS3オブジェクト内のコンテンツも分類します。深層学習/機械学習の研究分野において、サポートベクターマシンは教師あり学習モデルであり、データの分類や回帰分析のための学習アルゴリズムを持っています。Macieは、たくさんのコンテンツタイプのデータによってSVMを学習させ、あなたが書いたかもしれないソースコードが含まれていようとも、データコンテンツの正確な検知に最適化されます。 Macieはデータオブジェクトやファイルに対して一つのコンテンツタイプを割り当てますが、あなたはコンテンツタイプやファイル拡張子を有効化や無効化することもできます。それにより、それらオブジェクトをMacieサービスの分類対象に含めたり除外することができます。Macieがデータを分類したら、1から10までのリスクレベルがそのオブジェクトに割り当てられます。10が最もリスクが高く、1が最もリスクレベルが低いです。 Macieのデータ分類をカスタマイズするためには、Settingsタブに行きます。Macieの分類設定にて、有効化や無効化が可能な選択肢が表示されます。 このMacieツアーでの例として、File extensionを選んでみましょう。Macieが追跡し、分類に使用するファイル拡張子のリストが表示されます。 テストのために、Androidアプリケーションのインストールファイルであるapkファイル拡張子を編集し、ドロップダウンリストからNo […]

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー8月の配信について，ご案内させて頂きます。今後の配信予定について一部変更があったため，改めて最新版の配信予定についてお知らせいたします．   8月の開催予定   サービスカット 8/2(水) 18:00-19:00 AWS X-ray 8/9(水) 18:00-19:00 Amazon DynamoDB 8/23(水) 18:00-19:00 AWS MobileHub ソリューションカット 8/22(火) 12:00-13:00 Deployment on AWS 8/29(火) 12:00-13:00 Amazon Redshift テーブル設計詳細ガイド お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

1週間に約1回、私はシアトルのエグゼクティブブリーフィングセンターで現在の有力なAWSのお客様に話します。一般的に私はイノベーションプロセスに重点を置いていますが、アプリケーションの移行を含む他のトピックについても議論することがあります。企業がアプリケーションポートフォリオを移行する場合、企業は構造化された整然としたやり方でそれを実行したいと考えています。これらのポートフォリオは、通常、何百もの複雑なWindowsおよびLinuxアプリケーション、合理的なデータベースなどで構成されています。お客様は、進め方についてはまだ不確実であることがわかります。これらの顧客と一緒に働く時間を費やした後、彼らの課題は一般的に次の3つの主要カテゴリに分類されることがわかりました。 ディスカバリー – お客様は、各アプリケーションを動かす全ての部分について、深くて完全な理解を得たいと考えています。 サーバー＆データベース移行 – オンプレミスのワークロードとデータベースのテーブルをクラウドに転送する必要があります。 追跡/管理 – 大規模なアプリケーションポートフォリオと複数の移行が並行して行われるため、アプリケーション中心の方法で進捗状況を追跡および管理する必要があります。 ここ数年、私たちは最初の2つの課題に取り組む一連のツールを立ち上げました。 AWS Application Discovery Serviceはシステム情報の検出と収集のプロセスを自動化し、AWS Server Migration Serviceはクラウドへのワークロード移行を処理し、AWS Database Migration Serviceは最小のダウンタイムでリレーショナルデータベース、NoSQLデータベース、データウェアハウスを移行します。 RacemiやCloudEndureなどのパートナーは、独自の移行ツールも提供しています。 新しいAWS Migration Hub 今日、これらAWSサービスとパートナー移行ツールをAWS Migration Hubに統合しています。ハブは、前述のツールへのアクセスを提供し、移行プロセスをガイドし、Migration Acceleration Program（MAP）で説明されている方法論および原理に従って、各移行の状況を追跡します。 ここにメイン画面があります。移行プロセス（ディスカバリー、移行、および追跡）の概要を示します。 「Start discovery」をクリックすると、移行プロセスのフローが表示されます。 ディスカバリー手順をスキップしてすぐに移行を開始することもできます。 AWS移行サービス（Server Migration ServiceまたはDatabase Migration Service）のデータ、パートナーツール、またはAWS Application Discovery Serviceによって収集されたデータを使用し、サーバーリストが作成されます。 自分用の最初のアプリケーションを作成するには、「Group as application」を選択することができます。 移行するアプリケーションを特定したら、そのアプリケーションをHubの「Applications」セクションで追跡できます。 移行ツールは承認されている場合、アプリケーションの移行ステータスページに表示するために、ステータスの更新と結果を自動的にMigration Hubに送信します。ここでは、Racemi DynaCenterとCloudEndure Migrationが担当する部分の移行を実施したことがわかります。 Migration Hub Dashboardをチェックすると、移行のステータスを追跡できます。 Migration Hubは、AWSと移行パートナーの移行ツールと連携して動作します。詳しくは、Integrated Partner […]