Amazon Web Services ブログ

本Blogは、クラウドにおける新しい常識”new normal”を考えるBlogの第五弾です。
多くのお客様は、より安全にサービスを提供するために多様なセキュリティを組み込み、また規制要件を満たしていくことで組織としての説明責任を果たそうとしています。
日本銀行様では、多くの金融機関のお客様がよりクラウドを活用したイノベーションをおこし、サービスを向上するために『金融システムレポート別冊』として「クラウドサービス利用におけるリスク管理上の留意点」（以下、本別冊とします）を発表しました。本Blogでは本別冊に基づき、組織がセキュリティを実践するために必要な考え方のいくつかを示してみたいと思います。

先日 (2020/11/18) 開催しました AWS Black Belt Online Seminar「形で考えるサーバーレス設計 サーバーレスユースケースパターン解説 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201118 AWS Black Belt Online Seminar 形で考えるサーバーレス設計 サーバーレスユースケースパターン解説 from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 業務系APIグループ企業間APIのユースケースですが、LambdaとRDSの組み合わせはコネクションの問題がありアンチパターンだと思っていたのですが、違うのでしょうか？ A. 確かにこれまではアンチパターンと言われていましたが、Amazon RDS Proxyがリリースされたことによって、AWS LambdaからAmazon RDSへのコネクションをプーリングして再利用できるようになったため、Amazon RDSの負荷を軽減することができるようになりました。従って今後はAWS LambdaとAmazon RDSの組み合わせも要件に合わせて検討できる構成となっています。 Q. Lambdaの質問になりますが、Lambda関数について、デフォルト設定では、参照権限を許可しない限り、別のAWSアカウント（第三者）から関数を呼ばれることはない、という理解であっていますでしょうか？ A. はい、その通りです。AWS Lambda関数のリソースポリシーで明示的に許可を与えない限り、他のアカウントからそのLambda関数を実行することはできません。 Q. API-Gatewayを使ってSPAアプリを開発しようとしたときに、HTMLファイルはS3に置くのが一般的でしょうか？ A. SPAのアプリケーションを開発する場合、HTMLやJavaScriptは静的なページなのでAmazon S3のWebホスティング機能を利用することにより、サーバーの構築を行うことなくWebの静的ページをホスティングすることが可能です。そのためAmazon API Gateway、AWS Lambda、Amazon DynamoDBなどと組み合わせることで、全てをサーバーレスで構成して実行することが可能となるため良く利用されます。 Q. APMのパターンはありますか？今日の時点で AWS […]

先日 (2020/11/17) 開催しました AWS Black Belt Online Seminar「Amazon QuickSight のBI機能を独自アプリケーションやSaaSに埋め込む」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201117 AWS Black Belt Online Seminar Amazon QuickSight のBI機能を独自アプリケーションやSaaSに埋め込む from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. Amazon QuickSight ACL で SSO ユーザーのグループとサブグループを使用できますか？ A. QuickSight内のグループ機能は、SSO（フェデレーション）先のグループとは独立して利用可能です。つまりSSOには関係なくQuickSightの中でグループを作り、ユーザを登録することが可能です。また、ADFSでフェデレーションする場合はAFDSとの設定時に、AD側のグループとQS側のグループをマッピングさせるルールを定義することが可能です。 Q. Name spaceの管理はGUIには無いのでしょうか？ A. 現時点ではName space機能はコマンドライン（CLI）もしくはAPIでの操作になります。 Q. マップのテーマのカスタマイズで詳細なマップに変更したり、といったことは可能でしょうか？ A. QuickSightの地図ビジュアルにおいては、利用者独自のマップに変更するということはできません。 Q. email認証を使って閲覧ユーザーを招待した時に送信されるメールの文面をカスタマイズすることはできますでしょうか？ A. GUIで登録した際に自動的に送付されるメッセージのカスタマイズはできませんが、CLIやAPIでユーザを登録すると、登録に必要なURLを取得することができます。 この際には自動ではメールは送信されませんので、お客様側の仕組みなどでURLとメッセージを添えてメールを送っていただくことで対応可能と思われます。 Q. QuichSightでExcelの近似曲線表示のような機能はございますか？ない場合，実現する手段はございますか？ A. […]

先日 (2020/11/11) 開催しました AWS Black Belt Online Seminar「AWS CodeStar & AWS CodePipeline」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201111 AWS Black Belt Online Seminar AWS CodeStar & AWS CodePipeline from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. CodeStarで構築される環境は CloudFormation のテンプレートとして公開されているのでしょうか？ A. AWS CodeStar テンプレートには AWS ランタイム依存関係をモデリングする AWS CloudFormation ファイルが含まれています。これはプロジェクト内に template.yml として保存されています。 AWS CodeStar User Guide: AWS CodeStar Project Templates […]

先日 (2020/10/28) 開催しました AWS Black Belt Online Seminar「Amazon CloudFront deep dive」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201028 AWS Black Belt Online Seminar Amazon CloudFront deep dive from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. AWS WAFやShieldがリリースされる以前はCloudFront単体でDDoS Protectionされていたと記憶していますが、それは今でも有効ですか？ A. すべての AWS のお客様は、追加料金なしで AWS Shield Standard の保護の適用を自動的に受けることができます。AWS Shield Standard は、ウェブサイトやアプリケーションを標的にした、最も一般的で頻繁に発生するネットワークおよびトランスポートレイヤーの DDoS 攻撃を防御します。AWS Shield Standard を Amazon CloudFront や Amazon Route […]

本記事は Mistplay のAI エンジニアであるSteven Wang氏によるゲスト投稿です。 Mistplay はモバイルゲーマー向けの世界トップクラスのロイヤルティプログラムです。数百万人のプレイヤーが Mistplay を使用して新しいゲームを発見し、ロイヤルティ報酬を獲得し、他のプレイヤーとつながっています。このプラットフォームにより、Playtika、Scopely、Peak などのモバイルゲームスタジオは、世界中のユーザーを獲得し、それらのユーザーと深く関わることができています。   Mistplay が AWS に移行した理由 Mistplay では十分な情報に基づいた意思決定を行い、計算されたリスクを取るにあたり、データに大きく依存しています。  Mistplay の Android アプリケーションは、ユーザーのインタラクションをキャプチャする大量のイベント情報を生成するため、チームにとって不可欠なデータソースとなっています。このデータは不可欠であり、ビジネス上の主要な疑問に答え、当社が可能な限り最高のユーザーエクスペリエンスを作る上で重要な役割を果たしています。 従来、Android アプリケーションは Firebase にイベントデータを送信するように設計されていました。そこから、デフォルトで利用可能な統合機能を使ってFirebase と BigQuery を統合し、 BigQuery でイベントデータを公開し、詳細に分析していました。 しかし当社のビジネスが成長するにつれ、既存のソリューションでは対処できないいくつかの課題に直面しました。たとえば、品質上・精度上の問題が増加し、処理データに影響を与えていることに気付きました。さらに、インフラストラクチャに対するコストが当社のビジネスと同じくらい急速に増加していました。料金モデルは理解しにくく、当社の使用パターンだと予想外に高額な請求が発生することがよくありました。 当社のデータが新しいホームを必要としていることは明らかでした。当社のイベント分析を AWS に移行することは自然な選択でした。当社では既に Amazon S3 と Amazon Athena を主要なデータレイクとして使用していたためです。  さらに、ツール類を1つのサービスセットで統合し、分析タスクを合理化し、AWS の下で既に実施されている既存のセキュリティ対策を活用したいと考えていました。最後に、AWS の明瞭な料金モデルのおかげで、予算作成が簡単に行えました。 本投稿では、Firebase と BigQuery から Amazon S3 および Amazon Athena に移行した方法と、分析機能、コスト構造、およびオペレーションがどのように改善されたかを説明します。   移行戦略 […]

クラウドで開始する場合、お客様のストレージ要件は少数の S3 バケットで構成されますが、バケットが拡大し、アプリケーションの移行が増えて、クラウドのパワーを実現されるようになると、複雑性が上がることがあります。お客様が 1 社で数十、数百のアカウントを持ち、多数の AWS リージョンにまたがって複数の S3 バケットを持っていることがあります。このような環境を管理しているお客様からは、組織全体でストレージがどのように使用されているかを把握し、コストを最適化し、セキュリティ体制を向上させることが難しいとの声が寄せられています。 S3 チームは 14 年以上にわたりお客様のストレージの最適化を支援してきた経験を活用して、Amazon S3 Storage Lens という新機能を構築しました。これは、ポイントインタイムメトリクス、トレンドライン、アクショナブルなレコメンデーションによって、組織全体でオブジェクトストレージを可視化できる初のクラウドストレージ分析ソリューションです。これらすべてを組み合わせると、異常の検出、コスト効率の特定、データ保護のベストプラクティスを適用できます。 S3 Storage Lens では、29 以上にのぼる使用状況、アクティビティメトリクス、インタラクティブ型ダッシュボードを使用して、組織全体、特定のアカウント、特定のリージョン、特定のバケット、特定のプレフィックス用のデータを集約することで、ストレージを把握、分析して最適化できます。このデータはすべて、S3 マネジメントコンソールからアクセスするか、または S3 バケットの raw データとしてアクセスが可能です。 すべてのお客様にデフォルトのダッシュボードを S3 Storage Lens には、S3 コンソールにインタラクティブ型ダッシュボードが含まれています。ダッシュボードでは、メトリクスのフィルタリングとドリルダウンを実行して、ストレージの使用状況を十分に把握できます。メトリクスはデータ保護やコスト効率などのカテゴリ別に整理されているため、関連するメトリクスを簡単に見つけられます。 使いやすくするために、すべてのお客様がデフォルトのダッシュボードを受け取ります。このダッシュボードで多くのお客様も十分かもしれませんが、変更したいのであれば、変更もできます。たとえば、別のツール (Amazon QuickSight、Amazon Athena、Amazon Redshift など) を使用して分析するために、S3 バケットにデータを毎日エクスポートするようにダッシュボードを設定したり、アップグレードしてアドバンストメトリクスとレコメンデーションを受け取ったりできます。 ダッシュボードの作成 独自のダッシュボードをゼロから作成もできます。これには、S3 コンソールに移動し、[Storage Lens] セクションの [ダッシュボード] のメニュー項目をクリックします。次に、[ダッシュボードの作成] ボタンをクリックします。 ダッシュボードに s3-lens-demo という名前をつけ、ホームリージョンを選択します。ホームリージョンとは、ダッシュボードのメトリクスデータが格納される場所です。ダッシュボードを有効にしました。つまり新しいメトリクスで毎日更新されることになります。 ダッシュボードでは、アカウント、リージョン、バケット、プレフィックスの全体にわたるストレージを分析できます。[ダッシュボードスコープ] セクションに組織内のすべてのアカウントおよびすべてのリージョンのバケットが含まれるようにしました。 S3 […]

全4回に渡ってお届けする連載ブログ「AWSが支えるCOVID-19との闘い」。前回に引き続き、第2回では、プロジェクト分析リーダである慶應義塾大学 野村准教授に、神奈川県を皮切りに始まったプロジェクトのローンチから、他県への展開、疫学的知見・分析手法・ノウハウを一般社会へ広く公開・還元したエピソードをご説明いただきます。 LINEアカウント「新型コロナ対策パーソナルサポート（行政）」のローンチ 2020年3月5日、LINEを活用した新型コロナウイルスに対する個別情報提供システム「新型コロナ対策パーソナルサポート（行政）」の運用を始めました。日本が新型コロナの感染拡大の入り口にあった当時、「今すぐ可能なアプローチで、できる限りのことがしたい」という趣旨の元、行政や民間、アカデミア等の有志が集まり、ローンチに至りました。 このプロジェクトはLINEを使って新型コロナウイルス感染症 (COVID-19) のハイリスク群や潜在的罹患者のスクリーニングとフォローアップ、軽症者支援を効率的に行うためのシステムです。さらに、ユーザーが入力したデータを集積し分析することで、感染拡大や風評等二次被害の防止、及び予防・治療を含む今後の感染症対策に資する対策を検討することも目的としております。 主体は神奈川県で、行政の情報提供、相談支援業務の一環として行なっています。LINE株式会社からは、本システムの開発と維持管理を提供して頂き、Amazon Web Services（AWS）には本プロジェクトのデータ保管スペースとしてAmazon Simple Storage Service (Amazon S3)を提供頂いており、ローンチ時に迅速な判断で対応して頂きました。神奈川県顧問として本プロジェクト進行を統括する一人である宮田裕章氏が主任教授を務める慶應義塾大学医療政策管理学教室が、アカデミアで取り組むデータ処理と対応策の検討を主に担っています。筆者は当教室の特任准教授としてアカデミアチームをリードしています。 ローンチまではわずか約2週間 プロジェクト実施におけるLINEシステムの負荷や県電話窓口業務の負担のシミュレーション、感染症専門的な観点からのユーザーへのフィードバック情報の適切性の検討、そして数理統計学的な観点からのアンケート項目や配信計画の設定など、関係有志の専門性を最大限に生かす形でプロジェクトは始動しました。そこからローンチまでは昼夜を問わずオンライン上で激しい議論を交え、わずか2週間でシステムの運用が始まりました。 アカデミアチームの編成と役割 データ処理については、疫学・公衆衛生学や社会科学からのアプローチという学際的な性格を持ち、高度な統計分析とコンピュータサイエンスに関する専門知識を擁するためのアカデミアチームが必要でした。今ではメンバーは10人以上おり、皆本業の大学・民間の所属組織で実務をこなしつつ、半数以上が博士号を持ち、研究・開発、提言やコンサルティング業を中心に、データ分析に特化した若手のチームです（本項下部にリスト）。 慶應義塾大学 研究室におけるプロジェクトメンバーとのディスカッション風景   ユーザーが入力した情報はAWSに蓄積され、アカデミアチームはそのデータを当時は毎週の頻度で分析・集計し、神奈川県の担当者らにフィードバック、必要に応じて知事会見用の資料作成の補助や内容確認を行い、最終的に分析結果を知事が会見等で発信しながら、県の感染拡大防止策に役立てて頂きました。 例えば、令和2年3月27日（金曜）の神奈川県知事の定例会見では、手洗いうがいなど、個人で出来る基本的な感染症対策は90％以上の回答ユーザーが行っている一方で、テレワークや時差通勤など、社会システムとしての実装が求められる対策は、ほとんど進んでおらず、わずか10%程度の実施率であったことが発表されました（参考1）。 （参考1 ） 出典：https://www.pref.kanagawa.jp/chiji/press-conference/2019/0327.html   また、令和2年4月1日（水曜）臨時会見では、回答ユーザーにおける発熱者割合が上昇傾向にあり、警戒を要することが発表されました。これらはAWS上の回答データをアカデミアチームが分析し、結果を県に提示し、知事が会見で発信する、という一連のシステム運用の事例です（参考2）。 （参考2） 出典：https://www.pref.kanagawa.jp/chiji/press-conference/2020/0401.html システムの他県への拡大と、データの可視化 一方で、神奈川県発祥の「新型コロナ対策パーソナルサポート（行政）」は、そのシステム運用を今では29都道府県に展開しています。そしてそのほとんどが3月中にローンチされました。AWS上に収集される回答ユーザーのデータを、アカデミアチームが分析し、個別に県にフィードバックするというサイクルには限界があるため、IQVIA ジャパンにAWS上でのデータのビジュアル化を設計・実装頂きました。収集されるデータを直にビジュアル化することで、データサイエンスを専門としない都道府県の担当者によるデータ解釈を容易にすると同時に、各種会見や感染拡大・防止活動のための自由な資料作成を可能にします。アカデミアチームによる監修や、各県担当者との同時説明会を得て、4月末には実装されました。 科学的知見を社会に発信 アカデミアチームでは、本プロジェクトを通して得られた新型コロナウイルス感染症に関する疫学的知見や、分析手法・ノウハウを一般社会へ広く公開し、還元していくことに力を入れています。例えば、発熱症状と新型コロナウイルス感染には時間的、空間的に有意な相関関係があることを示し、ウイルス検査が全国的に迅速に受けられない状況では、LINEのようなSNSを活用した症状モニタリングが非常に有用であることをまとめました成果を、査読付きの国際的英字誌に発表しました（文献1,2,3）。 （文献1） 出典：https://www.thelancet.com/journals/lanwpc/article/PIIS2666-6065(20)30011-0/fulltext （文献1) 出典：https://www.thelancet.com/journals/lanwpc/article/PIIS2666-6065(20)30011-0/fulltext   また、社会的距離政策を後押しするエビデンスとして、テレワークの実施と発熱症状には相関があり得ること（文献4）、上述の神奈川県知事会見で発表された予防行動に関するデータ（個人でできる予防と社会的サポートが必要なテレワークのような予防対策にはその実施率に大きな乖離があること）（文献5）、自粛要請・緊急事態宣言に伴う新型コロナウイルスの感染経路の変化について議論（文献6）、さらに、新型コロナウイルス感染症に罹患されている人が身近にいる人ほど、不安を抱えている人が多い可能性（文献7）などを発表しています。 また、英医学誌The Lancet Regional Healthの新型コロナウイルス感染症の症状モニタリングシステムに関するコメンタリー が、この日本の「新型コロナ対策パーソナルサポート（行政）」を大規模疫学モニタリングの事例として紹介し、国際的に高い評価を得ています（参考3）。 (参考3)  https://doi.org/10.1016/j.lanwpc.2020.100024 今後に向けて 「第3波」の流行に備えて日本では何が必要なのか、何を準備すべきかという点を個別具体的に考えるための一助として、「新型コロナ対策パーソナルサポート（行政）」から得られる知見を個人はもちろん、各自治体や政府、民間等に役立てて頂きたいと思っています。 アカデミアチームメンバー（五十音順敬称略　2020年10月現在） 瓜生真也、江口哲史、川島孝行、河村優美、史蕭逸、田上悠太、高柳慎一、野村周平、牧山幸史、松浦健太郎、宮田裕章、米岡大輔 アカデミアチーム発表論文（2020年10月現在） 1. […]

AWS Systems Managerを使うと、マネージドインスタンスへのパッケージデプロイの順序を制御できます。マネージドインスタンスとして管理できるものには、Amazon Elastic Compute Cloud（Amazon EC2）インスタンス、他のクラウド環境で稼働するVMを含む仮想マシン（VM）、そしてオンプレミスサーバーがあります。ハイブリッドインフラストラクチャの構成管理手順を自動化したいお客様もいらっしゃるでしょう。そのためには、特定のマネージドインスタンス上で特定のパッケージを順序立てた方法で実行し、インストール順序においてそれぞれのパッケージが干渉し合わないようにする必要があります。現在、Systems Manager Distributorパッケージを使用することで、マネージドインスタンスにソフトウェアパッケージを公開できます。ただし、それらが1回限りのインストール用に構成されている場合、パッケージの実行はマネージドインスタンスで同時に発生する可能性があります。

当社のお客様は、世界中のあらゆるユーザーにサービスを提供する必要があるアプリケーションを構築しています。お客様の話を聞くと、AWS で Active Directory (AD) 対応のアプリケーションを構築することは快適であるものの、グローバルに動作させることは本当に課題になり得るとのことです。 お客様は、AWS Directory Service for Microsoft Active Directory によって時間と費用を節約し、AD 対応アプリケーションの実行に必要なすべての機能が得られたと語っています。ただし、グローバル化したい場合は、リージョンごとに独立した AWS マネージド Microsoft AD ディレクトリを作成する必要がありました。その後、各リージョン間でデータを同期するソリューションを作成する必要があります。このレベルの管理オーバーヘッドは大きく、複雑で、コストも高くなります。また、AD 対応のワークロードをクラウドに移行しようとしたため、お客様のペースも低下しました。 本日は、複数の AWS リージョンで単一の AWS マネージド Microsoft AD をデプロイできる新機能についてお伝えします。マルチリージョンレプリケーションと呼ばれるこの新しい機能は、リージョン間のネットワーク接続を自動的に設定し、ドメインコントローラーをデプロイし、複数のリージョン間ですべての Active Directory データを複製します。これにより、これらのリージョンに存在する Windows および Linux ワークロードは AWS マネージド Microsoft AD に接続し、低レイテンシー、ハイパフォーマンスで使用できるようになります。 AWS マネージド Microsoft AD を利用すると、AD 対応のアプリケーションやワークロードの AWS への移行の費用効果が高くなり、グローバルな運用が簡単になります。さらに、自動マルチリージョンレプリケーションにより、マルチリージョンの耐障害性が得られます。 AWS は、ユーザー、グループ、グループポリシーオブジェクト (GPO)、スキーマなど、すべてのカスタマーディレクトリデータを複数のリージョン間で同期できるようになりました。AWS は、自動化されたソフトウェア更新、モニタリング、リカバリ、および基盤となる AD インフラストラクチャのセキュリティをすべてのリージョンにわたって処理するため、お客様はアプリケーションの構築に専念できます。Amazon […]