Category: Best Practices

AWS で SaaS Business Lead を務める Oded Rosenmann による記事です。 SaaS（Software as a Service）提供モデルは、多くの企業にとってますます魅力的になっています。 新規および既存のアプリケーション・プロバイダが、この提供モデルで成功を収めたいと望んでいる一方で、SaaS への移行はビジネスに大きな影響を与える可能性もあります。 多くの企業にとって、SaaS への移行は大きな変化をもたらす出来事であり、企業は自社のビジネスをあらゆる側面から検討する必要があります。サービスとしてのビジネスを定義、構築および運用するためには、製品の販売、マーケティング、開発、サポート、収益化の方法など、評価しなければいけない検討事項がたくさんあります。

AWS SaaS Factory で Principal Partner Solutions Architect を務める Tod Golding による記事です。 SaaS (Software-as-a-Service) モデルへの移行は多くの企業にとって魅力的ですが、新しいマルチテナントアーキテクチャへの移行に必要な時間、労力、投資は大きな障壁となる場合があります。 多くの企業にとって、SaaS への移行には、新しいテクノロジーの習得、マルチテナント構造の実装、新しい運用ツールの作成、新しい課金体型の採用、といった作業を伴います。 こういった障壁は、SaaS への移行がビジネスを成長させ将来の成功の鍵になると考えている企業にとって、特に深刻な問題になる可能性があります。そのような企業の多くは、わざわざアプリケーションの再構築やコードの書き換えを行うことなく、そして時間やコストも奪われることなく、SaaS への移行を加速する方法を模索しています。 そういったニーズに対応するために、アマゾンウェブサービス (AWS) では、AWS SaaS Boost をリリースしました。

新年明けましておめでとうございます！アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉（@kimyan_udon2）です。私は年始早々、厳かな気持ちでこのブログを書き始めたのですが、気づけば2月に突入しておりました。皆様いかがお過ごしでしょうか？ 年をまたいで2020年11月27日に「Amplify Meetup #02」を開催しました。「Amplify Meetup」はAWS AmplifyのユーザーとAWS Amplifyに興味のあるエンジニアのみなさんでLTなどを通して盛り上がるコミュニティーイベントです。タイトルに「#02」とありますように、今回は第2回目の開催となります。第1回目の盛り上がりも開催報告ブログにまとまっております。継続して開催できたのは、ひとえにご参加いただいた皆様のおかげです。皆様ありがとうございます！

先日、AWS Fargate for Amazon ECS 経由でデプロイされたタスクの設定とメトリクスの収集体験を向上させる機能を発表しました。お客様からのフィードバックに基づき、以下の機能を追加しました。 環境ファイルのサポート シークレットバージョンと JSON キーを使用した、AWS Secrets Manager とのより深い統合 より詳細なネットワークメトリクスと、タスクメタデータエンドポイントを介して利用可能な追加データ この記事を通して、これらのアップデートについて深く掘り下げ、Amazon ECS for AWS Fargate にコンテナをデプロイすると、どこに価値をもたらすことができるかを説明します。まず、簡単なデモアプリケーションのデプロイから始めて、これらの各機能を説明します。

はじめに Amazon API Gateway の API キーの利用を検討したものの、API キーの制約によってプロダクトの要件を満たせないことがあります。その際、それぞれ Amazon Cognito を利用した認証と AWS WAF を用いた IP ベースのレート制限を利用するという代替案をご紹介いたします。 背景 筆者は普段、プロトタイピングソリューションアーキテクトとして、お客様のプロダクトのプロトタイプ作りをお手伝いさせていただいております。お客様の中には、ユーザー認証やアクセス制御として Amazon API Gateway の API キーの利用を検討している場合があります。しかし、API キーでお客様の要件を満たせるかどうかは、慎重に検討が必要です。 API キーには数の上限があります。Amazon API Gateway のクォータと重要な注意点 にも記載がある通り、1 アカウント、1 リージョンあたりの API キー数の上限は 500 です。そのため、多くのユーザーを抱える API では API キーによる認証は適さないと言えます。 API キーのセキュリティについても検討が必要です。API キーは有効期限が設定できないので、有効期限を設定可能な認証方法に比べ、漏洩した際のリスクが大きいです。 このように、 API キーは容易に利用が可能な反面、いくつかの考慮事項があるため、選定は慎重に行う必要があります。次の考察で、認証とアクセス制限について、それぞれ代替案をご紹介したいと思います。 考察 では、ユースケース別に代替案をご紹介いたします。 一つ目は、認証として API キーを利用したいケースです。それぞれのユーザーに対し、ユニークな API キーを割り当てることを想定しています。この場合、背景にて説明した API […]

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

Unityはゲーム業界をはじめ、映画や自動車業界など幅広い分野で利用されている仮想環境エンジンです。ユーザーはUnityで提供されるツールを通して、独自の物理法則、地形、キャラクターを作成することが可能です。Unity Machine Learning Agents Toolkit (ML-Agents)はオープンソースプロジェクトで、Unityで構築した仮想環境内で動作する強化学習エージェントを作成することが可能です。強化学習とは機械学習の一種であり、エージェントはある環境上の一連のアクションに対して受け取る総報酬を最大化するための方策を学習します。SageMakerにおける強化学習の取り組みについてはこちらのブログを参照ください。Unity ML-Agentsは強化学習エージェントの作成において広く使われているツールであり、作成された強化学習エージェントはレベルデザイン、バグ検出、チート検出など様々な用途で応用されています。より複雑な環境における強化学習エージェントの作成には、分散学習、ハイパーパラメータチューニングなどにおいて効率よくコンピューティングリソースを配置することが重要となります。このブログでは、SageMaker RLとUnity ML-Agentsを統合し、フルマネージドな環境で効率よくコンピューティングリソースを配置し強化学習エージェントを作成する方法について紹介します。 SageMaker RLを使う利点 Amazon SageMaker はフルマネージドサービスであり、機械学習モデルを迅速に構築、トレーニング、デバッグ、デプロイなどをするための様々な機能を提供しています。SageMaker RLはこのSageMaker上で動作し、ビルド済みのRL ツールキットを提供しています。SageMaker RLを用いることで、容易にRL環境を構築でき、TensorflowやPyTorchといったフレームワークを使用した強化学習が可能です。学習、推論ジョブはSageMakerによって管理されており、お客様は強化学習エージェントの作成に多くの時間を割くことができます。また、SageMaker RLは複数のサンプルノートブックを提供しており、どのように強化学習をロボティクス、オペレーションズ・リサーチ、金融に利用するのかなどを学ぶことが可能です。以下に紹介するソリューションもこのサンプルノートブックからすぐさま利用可能です。 SageMaker RL – Unity ML-Agents integrationの利用方法 今回利用するSageMaker RLの学習ジョブの構成は以下のようになっています。強化学習ツールとしてはRay-RLLibを使用しています。分散学習、アルゴリズム構築、ネットワーク構築、パラメータ設定などをRay-RLLib上で管理することで煩雑な作業を減らすことが可能です。Unity環境はOpenAI Gym環境としてラップすることでRay-RLLibからはUnity独自の仕様を意識することなく一般的な強化学習タスクとして扱えます。そして、学習を実行するリソースや設定についてはSageMakerで管理しています。 では、実際にこの構成で強化学習エージェントを作成する方法を順を追って説明します。 セットアップ はじめに、ノートブックの環境設定を行います。下記を実行することで、API実行用のIAMロール、S3バケットの設定やPythonライブラリのインポートなど環境設定を行うなうことができます。 import sagemaker import boto3 # set up the linkage and authentication to the S3 bucket sage_session = sagemaker.session.Session() s3_bucket = sage_session.default_bucket() s3_output_path = ‘s3://{}/’.format(s3_bucket) print(“S3 […]

今回はクラウドにおける安全なデータの廃棄において取り上げた安全なデータ廃棄をどのように実践するかをお伝えします。

AWS Cloud Development Kit（AWS CDK）は、使い慣れたプログラミング言語でクラウドインフラストラクチャを定義し、AWS CloudFormation を通じてプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。AWS CDK は、次の 3 つの主要なコンポーネントで構成されています。 再利用可能なインフラストラクチャ・コンポーネントをモデリングするためのコアフレームワーク CDK アプリケーションをデプロイするための CLI AWS Construct Library（クラウドリソースを抽象化し、実績のあるデフォルト値をカプセル化する高レベルのコンポーネントのセット） CDK を使用すると、cdk deploy を実行するだけで、ワークステーションから AWS クラウドにアプリケーションを簡単にデプロイできます。これは、初期開発およびテストを行う場合に最適ですが、本番ワークロードをデプロイするためには、より信頼性の高い自動化されたパイプラインを使用する必要があります。 CDKアプリケーションを継続的にデプロイするために、お好みのCI/CDシステムを利用することが可能ですが、より簡単で、かつすぐに利用可能な方法をお客様はご要望でした。これはCDKの中核的な理念に適合します。つまりクラウドアプリケーションの開発を可能な限り簡素化して、お客様が関心のある部分に集中することです。 CDK Pipelines の開発者プレビューリリースをお知らせします。CDK Pipelines は、AWS CodePipeline によって CDK アプリケーションの継続的なデプロイパイプラインを簡単にセットアップできる高レベルのコンストラクトライブラリです。この投稿では、CDK Pipelines を使用して、AWS Lambda と連携した Amazon API Gateway エンドポイントを 2 つの異なるアカウントにデプロイする方法について説明します。

内閣官房と総務省より「第二期政府共通プラットフォームにおけるクラウドサービス調達とその契約に係る報告書」（以下、『報告書』）が発行されました（令和２年８月５日付）。   今回の『報告書』は、内閣官房IT総合戦略室・総務省行政管理局の２府省により構成される「政府共通プラットフォームの構築・活用推進及び政府におけるクラウドサービス利用検討」プロジェクトチーム、クラウド利用戦略・企画担当の皆様より、作成・取りまとめをいただいた報告書となります。　後述の引用部分の記載のとおり、今回の『報告書』は、第一号の政府重点プロジェクトに指定された政府共通プラットフォームにおける「クラウドサービス調達」に関して、２府省共同で組成されたプロジェクトチームが調達方法（契約内容を含む）を検討し、実際の調達手続を行った”事例紹介”として執筆されています。 なお、『報告書』中で複数回「AWS」への言及がありますが、その理由に関しましては、 ”＞「第二期政府共通プラットフォームの設計・開発等業務の請負」の調達においては、採用するクラウドサービス事業者を問わず、一般競争入札・総合評価落札方式により審査及び入札を実施し、平成31年3月に設計開発事業者が決定した。その際、Amazon Web Services（以下、「AWS」という。）を前提とした提案が採用されたことから、本プラットフォームについてAWS前提での設計開発を開始することとなった（p.2）” ──旨、『報告書』において説明いただいております。 ２万字近い『報告書』のなかでは、これまで政府調達・公共調達において、クラウドサービスを調達する際に直面しがちだった幾つかの典型的な課題に関し、先進的な整理が試みられており、いくつもの有益な提言が含まれています。 今回のブログでは、AWSジャパン・パブリックセクターより『報告書』の概要と、読み取られるべきインパクトについて解説します。 調達の背景と、事例紹介の『報告書』 今回の『報告書』の冒頭では、報告書作成の「背景」が記載されています（「１．背景等」）。クラウドに期待されるメリット、政府情報システムにとってのクラウドの重要性、そして調達・契約に至る検討の経緯が仔細に記載されており、少々長文となりますが重要な導入部分であるため、以下に引用します（着色強調は、ブログ筆者。他の引用箇所も同様）。 　”近年、急速に進化し発展したクラウドサービスは、正しい選択を行えば、コスト削減に加えて、情報システムの迅速な整備、柔軟なリソースの増減、自動化された運用による高度な信頼性、災害対策、テレワーク環境の実現等に寄与する可能性が大きく、政府情報システムにおいても、クラウドサービスを利用することで様々な課題が解決されることが期待される。 　このことから、現在、多方面にわたり、クラウドサービスの利用が増加してきている状況において、政府情報システムにおけるクラウドサービスの利用に係る基本方針[脚注1]が決定され、クラウド・バイ・デフォルトの原則を具体化し、各府省が、クラウドサービスを採用し、かつ、クラウドサービスを効果的に利用するための基本的な考え方が示されたところである。また、政府情報システムにおける予算要求から執行までの一元的なプロジェクト管理[脚注2]において、政府情報システムの一元的な管理体制の構築により、クラウドサービスの経費の合理化やサービスレベルの向上を実現するため、内閣官房IT総合戦略室が各府省を牽引してクラウド化を強力に推し進めるとともに、政府全体を代表してクラウドサービス事業者（以下「CSP」という。）と交渉し、政府が本来有する巨大な調達主体としてのバイイング・パワーを発揮してスケールメリットを確保することが不可欠とされたところである。 　本報告は、この一元的プロジェクト管理の第一号として政府重点プロジェクトに指定された政府共通プラットフォーム（以下「政府共通PF」という。）における第二期政府共通PFのクラウドサービス調達に関して、「政府共通プラットフォームの構築・活用推進及び政府におけるクラウドサービス利用検討」プロジェクトチームのクラウド利用戦略・企画担当（以下「PFPJ」という。）が調達方法（契約内容を含む）を検討し、総務省において実際の調達手続を行った事例として紹介するものである。 [脚注1] ｢政府情報システムにおけるクラウドサービスの利用に係る基本方針｣（2018年（平成30年）6月7日各府省情報化統括責任者（CIO）連絡会議決定） [脚注2] ｢政府情報システムの予算要求から執行の各段階における一元的なプロジェクト管理の強化について｣（令和元年6月4日デジタル・ガバメント閣僚会議） ❖「クラウド × 政府調達」の各論点に指針を提示 以下、AWSの理解による今回の『報告書』の要点・ハイライトをご紹介させていただきます。 ❖再掲：『報告書』の要点（『報告書』本体へのリンクはこちら）   要点①：クラウドサービスの「分離調達」を実施 『報告書』では、「＞クラウドサービスの調達では、システムの設計開発とクラウドサービスをセットで調達する場合やシステムの設計開発と分離して、クラウドサービスの提供をメインとして調達する場合などが考えられる」との２パターンを理論的に想定しています。　従来の公共調達においては、圧倒的に前者、つまりはシステムの設計開発とクラウドサービスとを”セット”で調達する「一括調達」が圧倒的に多く観察される調達形態でした。 しかしながら、今回の「＞政府共通PFにおいては、後者の分離したクラウドサービスの提供とこれに関連したアカウント管理のための役務提供を含む調達」の方式が選定され、調達が実施されています。（「システムの設計開発」を担う事業者等は、後続の別個の調達単位にて選定される立て付けとなっています。） 要点②：随意契約ではなく「一般競争契約」を選定 政府調達においては「競争性」をどのように担保するか、つまりは、一般競争契約を行うか／随意契約を行うか──の判断分岐が生じます。 今回の調達においては、「＞クラウドサービスの調達方法に関して、国内外様々なCSPが提供しており、現行の会計法令からすれば、原則、一般競争契約による調達を検討することが望まし」いものと整理され、調達が実施されました。 要点③：最低価格ではなく「総合評価」方式で調達 『報告書』において詳述されているとおり、政府調達においては「落札方式については、最低価格落札方式か総合評価落札方式かを検討する必要がある」とされています（＊登場する調達・会計法令関連の用語に関しても『報告書』本体に詳細な脚注が付されているので、ご参照ください）。 今回の調達では、「＞クラウドサービスの安全性やサービス・レベル・アグリーメント（以下「SLA」という。）等に関する要求要件を調達仕様に明記する場合や役務提供などの複合的な要素がある場合は、クラウドサービスの内容、種類等から総合的に判断する必要があるため、総合評価落札方式によることが適当」と整理をし、「最低価格落札方式」ではなく、「総合評価落札方式」を選定した旨、経緯が記載されています。 要点④：直接契約ではなく「間接契約」を締結 一般の商流を考えた場合、大きく分けて「＞クラウドサービスの契約方法については、CSPと直接契約する場合と中間事業者を介して、クラウドサービスの提供を受ける間接契約」の２パターンが想定されます（『報告書』では、これらの中間に位置するような契約形態に関しても言及があります点、ご留意ください）。 今回の『報告書』では、直接契約・間接契約のメリットをそれぞれ比較考慮したうえで、「＞支払業務について国内の中間事業者を活用することで、サービス毎の支払を取りまとめ、従来どおりの請求書をベースにして支払ができるため、直接契約に比べ支払業務を円滑に行えるメリットが発揮されるケースがある」と整理し、間接契約を締結するに至った経緯が説明されています。なお、将来的に「直接契約」を選択する場合の論点に関しても『報告書』では記載されており、CSPとしても直接・間接契約のどちらをもお選びいただける商流スキームを提供しております。 要点⑤：CSPと中間事業者に課す「サービス提供条件」を分離 従来の公共調達では、プライムとして提案する応札企業が、提供する役務に関して主たる責任を専一的に負う慣行、およびそれを求める契約書上の記載が続いてきました。しかし、One to Many、多くの顧客に均一なサービス利用条件を提供するビジネスモデルに基づくCSPにとって、個別の調達案件ごとにカスタムされた利用条件・契約条件を提示することは至難の業であり、政府調達と言えども「責任共有モデル」の境界を踏み越え、役務受託に伴う責任を調達者側はCSPに求めるべきではありませんし、CSP側もそうした責任の受任を確約することができません。では、公共調達において調達者側が求めたい”責任”と、CSP側が負い切れる”責任”とのギャップを、どのように埋めることができるでしょうか？今回の『報告書』では、要点④で述べた「中間事業者」に対して求める”責任”とのコンビネーションにおいて、このギャップを乗り越える工夫が行われ、応札者にとっての参入機会の拡大も図られた旨、記載されています。 ”当該クラウドサービスの利用に関する約款等に基づき、契約の相手方である中間事業者の負うべき責任の範囲等についてあらかじめ承諾を受けることを求める旨の追加的な条項を設定した。この条項は、本来クラウドサービスの利用者がCSPの約款等に基づき、利用に関する条件等を容認した上で利用するものであるが、国の契約においては、中間事業者が契約の相手方となる場合、委託先となる中間事業者が、すべての責任を負うことで、量的にも質的にも負いきれない筋違いの責任を求められる可能性があると判断し、結果として入札不調を招く恐れがあることからこのような条項を設定した。 　 　 例えば、国の契約の場合、一般的には損害賠償請求の上限など示されていないことが多いが、CSPが提供するサービスの約款等において一定の上限が決められている場合、中間事業者が、契約の相手先である国に対して、すべての責任を負うことになるため、中間事業者が負うクラウドサービス提供における責任範囲等に関して、契約段階で発注者側に承諾を得ることで調達に参加する中間事業者の不安を解消し、参入機会の拡大にも繋がるものと考えられる ”。 上記の発想を踏まえ、今回の『報告書』では、”＞CSPと中間事業者それぞれの役割分担に照らして責務や安全性の水準を「クラウドサービスの条件」及び「請負者のサービス提供条件」とに分割し調達仕様書上で求め”る工夫を行った旨、調達の経緯が説明されています。 要点⑥：従量課金を「単価契約」で実現 クラウドの特徴でありメリットの一つとして挙げられることの多い「従量課金」。従来の公共調達においては、固定額で契約を取り結ぶ「総価契約（固定価額での契約）」が支配的な契約類型であり、「従量課金」、ひいてはクラウドとの相性が悪いのでは？────との疑問が提起されてきました。 今回の『報告書』では、「＞国の契約においては、総額をもって契約する総価契約が原則であるが、特例として、契約上の数量が確定できないものについて、単価を契約の主目的とし、期間を定めてその供給を受けた実績数量を乗じて得た金額の代価を支払うことができる契約形態として、単価契約が認められている」との解釈をベースとし、クラウド採用に伴う“従量課金”への対応を、総価契約でも概算契約でもなく、「単価契約」で実現しています。具体的な入札時の応札価格の試算の手法等に関しては、『報告書』本体をぜひご覧ください。 要点⑦：利用サービスの種類を限定せず、随時の追加が可能と整理 政府予算からの支出が行われる以上、予算要求時点での精確な利用サービスの「種類」、その「ボリューム」が積算根拠として明記されることが、日本の公共調達では長らく求められてきました。『報告書』においても、上記の原則に関し、「＞単価契約も総価契約と同様に、歳出予算の制限を前提とすることから、単価のほか契約期間に対応したクラウドサービスの利用量を予定しておくことが必要であり、調達時には歳出予算の範囲内でクラウドサービスの契約ができるようにする必要がある」と、上記の原則を踏襲する整理を行っています。 他方で、今回の『報告書』ではもう一歩踏み込み、以下のような記載をもって、利用するクラウドサービスの追加が調達実施の時点以降も可能となる整理を行うことで、各利用機関にとって提供される柔軟性・迅速性が大幅に高まっています。（強調は、ブログ筆者） ”ただし、クラウドサービスの調達を単価契約とする場合は、クラウドサービスの種類を調達仕様書に明記できることやサービス毎に単価が、契約書の内訳として明記できることが重要となるため、契約期間中に単価が変動した場合や新たなサービスが追加される場合は、原則として、変更契約が必要となる。しかし、利用開始前に迅速に変更契約することは現実的には困難であり、サービスの継続的な提供に大きな影響が発生する。そのため、単価が公表されていることや利用量が確認できること等の条件を満たし、請求金額を検証できることを前提とするが、契約変更に係る事務負担軽減のため、例えば、契約書において、変更契約の条件に「単価変動やサービス追加の際は、契約時と同等の割引率や割増率を適用するものとする。」などと明記し、毎回変更契約せずに効率的に契約事務を行う工夫も考えられる。今般、政府共通PFでは、このような方法により、クラウドサービスの価格変動や追加サービスに柔軟に対応した契約方法として単価契約を採用した。” 要点⑧：複数年契約のメリットを認識しつつも「単年度契約」を実施 […]