AWS初心者のための勉強会資料【入門編】〜結局AWSって何なの？〜
AWS初心者のための勉強会資料【入門編】〜結局AWSって何なの？〜:
今回はAWS勉強会入門編として、AWSとは何なのか？ AWSのサービス概要や特徴などを解説していきます。
この記事のゴールは基本サービスであるEC2を触れるようになるための事前知識をマスターすることです。
※ 本記事は超入門編であり、サービスについて細かい説明は行なっておりません。各サービスには公式ドキュメントへのリンクを貼っているので、詳細を知りたい方はそちらをご参照ください。
AWSとは何者なのでしょうか。最初にAWSのイメージを掴むために概要の説明を行います。
AWSはAmazon Web Servicesの略です。まずは公式サイトの説明を見てみましょう。
Amazon.com社内で培われた技術を「クラウド」の形態で提供するサービスとのこと。Amazon.comは言わずと知れた世界最大級のECサービスですね。
それではAWSの誕生とそれからの沿革を見ていきましょう。AWSが誕生するまでの秘話からエッセンスをピックアップします。
つまり、AWSは元々はAmazon社内の課題を解決するために開発された技術で、それをAmazon以外の人々や企業でも使えるようにしたサービスということですね。
AWSの沿革についてはこちらに概略が書かれています。
ここまで「クラウドサービス」という言葉が出てきていますが、AWSの具体的な話しを進める前にクラウドについて確認しておきましょう。
引用元：クラウドとは？
上記の説明にあるように、クラウドとはITビジネスを展開するために必要なリソースを、オンデマンドで利用することができるサービスです。オンデマンド(on demand)とは必要な時に必要なだけ利用するということです。
従来はITでビジネスを展開しようと考えた時、必要なサーバ等のハードウェアやその置き場所、各種ソフトウェア、ライセンスなど全て自社で調達しなければなりませんでした。クラウドを使うことでインフラ調達のコストを抑えつつ迅速に行い、製品を素早く市場に投入したり、削減できた資金をより新しい価値を生むことに投資することができるようになります。
クラウドはこのようなメリットがあり、日本政府もクラウド・バイ・デフォルト原則として、これからは政府情報システムをクラウドベースで検討するという提言を出しています。
クラウドはそのサービス形態によって「IaaS」「PaaS」「SaaS」の3つに分類されます。
IaaSとは仮想サーバやOS、ネットワークなどのITインフラをインターネット上のサービスとして提供する形態です。ユーザはビジネス要件に応じてハードウェアのスペック、OSの種類などを必要に応じて選択することができます。クラウドサービスの分類の中で最もユーザの自由度が高い形態です。
PaaSとはアプリケーション開発のプラットフォームをサービスとして利用できる形態です。ハードウェアやOSに加えて、開発に必要なライブラリ、ミドルウェア、データベースなどもサービスとして提供され、ユーザは自社のアプリケーション開発に集中することができます。
SaaSは完成されたソフトウェア製品をインターネット経由で利用する形態です。ユーザ自身が開発や運用を行うことはありません。SaaSアプリケーションの一般的な例の１つにGmailなどのウェブメールサービスがあります。
これらのクラウドの分類は以下のような図で説明されることが一般的です。大まかにはサービスとして提供されるレイヤが多いほどユーザが自身で用意する必要が少なくなりますが、カスタマイズ性は乏しくなります。ユーザはビジネス要件に応じて適切なサービス携帯を柔軟に選択する必要があります。
引用元：知っておきたいIaaS、PaaS、SaaSの違い
Gartnerによると2017年のクラウドサービス市場でAWSは51.8%のシェアを誇り、マジック・クアドラントにおいてもビジョンの完全性と実行能力に優れた「リーダー」と評価されています。
引用元：Worldwide IaaS Public Cloud Services Market Share(Gartner)
引用元：Gartner’s IaaS Magic Quadrant
※マジック・クアドラントについてはこちらを参照。
横軸がビジョンの完全性、縦軸がその実行能力を評価しています。
Google、Microsoft、IBMといった名だたるIT企業がクラウドサービス市場に参入していますが、その中でも先進性・シェア共にAWSが圧倒的に優位に立っているということがわかります。
なぜこれほどまでにAWSが広く受け入れられているのでしょうか。AWSによる公式のOverviewにて、AWSを他のサービスと区別する違いは以下の5つだと述べられています。
AWSでは様々なプログラミングモデルや言語、OSなどをAWS社内で培われたナレッジに基いてサービスとして提供されます。ユーザはビジネス要件に応じてそれらを柔軟に組み合わせ、より少ない投資で導入することができます。
AWSではハードウェア等の初期投資が不要で、オンデマンドで必要な分だけリソースを確保し、使ったリソース分にだけ課金されます。またAWSを使うことでビジネスを迅速に展開でき、このこともコスト低減に役立ちます。結果としてトータルのROI(Return On Investment)を高めることができます。
ビジネス要件に応じて素早くリソースを拡張したり縮小することができます。例えばECサイトの場合、特典期間に通常の2~3倍のトラフィックが発生することがあります。従来のITではこのような瞬間的なトラフィックに対応するためにはインフラへの投資が必要でした。AWSではELB(Elastic Load Blancer)とAuto-Scalingを導入することで、自動的にクラウドリソースを増減することができます。
セキュリティの面でもメリットがあります。物理的側面ではAWSは世界中にデータセンタ保有しており、部外者は入室できないなど、長年の経験に基づいて堅牢なセキュリティ対策を実施しています。ユーザがAWS上に保管するデータは暗号化が可能です。AWSのサービスを利用する際には権限を持たないアクセスを制限することでセキュリティを担保します。これはユーザがAWSのセキュリティベストプラクティスを正しく理解してシステムを構築しなければならないため、これらを導入するためのドキュメントを提供しています。
AWSは毎年数百万ユーザが利用し数十億ドルの売上を誇るAmazon.comのインフラストラクチャを長年運用してきた経験があります。既存のIT資産をAWSへ移行するには、今までのサービスが継続して提供できるように様々なことを考えなければいけません。AWSを利用するば既存IT資産をシームレスにクラウドへ移行できます。AWSの豊かな経験に基づくインフラストラクチャはスケーラビリティ、セキュリティ、信頼性、コスト効率に置いてユーザの期待を満たす、またはそれ以上の結果をもたらします。
ここまででAWSとは何なのかイメージは掴めてきたでしょうか？
ここからはAWSのサービスを利用する上で、知っておくべき事前知識をいくつか説明していきます。
マネジメントコンソールはAWSのサービスを利用するためのWebユーザインタフェースです。ブラウザからアクセスして使うもので、AWSを利用する方法のうち最も基本的なものです。(玄人向けにはAWS CLIやAWS SDK、AWS API Gatewayなどがあります。)
マネジメントコンソールではAWSのアカウントを管理したり、サービスを検索したりすることができます。AWSを利用する上で最も多く使用するツールになります。
AWSマネジメントコンソールのサービス検索画面。100以上のサービスを利用することができます。
AWSを利用するために最初に作成するアカウントをルートアカウントと言います。
ルートアカウントの作成にはメールアドレスとクレジットカードが必要です。アカウントを作成しただけでは課金はされませんが、サービスを利用すると利用量に応じて登録したクレジットカードに請求がくるので注意が必要です。
AWSではルートアカウントを用いることは非推奨とされています。ルートアカウントはAWSの全てのサービス・リソースに対するアクセス権限を持つため、アカウントをハッキングされたり、オペレーションミスが発生した際のリスクが高いためです。
公式ドキュメントにもこのことが書かれています。
ルートアカウントはMFA(Multi-Factor Authentication：多要素認証)を設定し、管理者のみが利用できる状態とすることが望ましいです。(MFAは「二段階認証」ともよく呼ばれます。)
定常業務ではルートアカウントの代わりにIAMというサービスをユーザアカウント管理に利用します。
IAMとはIdentity and Access Managementの略で、ユーザーに対して AWSへのアクセスを安全に制御するための仕組みです。
アクセス権限を付与される実体としてはIAMユーザーとIAMロールの2種類があり、アクセス権限はポリシーとしてこれらに関連づけられます。
IAMユーザーはパスワードを用いてAWSマネジメントコンソールにサインインすることができます。
ルートアカウントと異なり、それぞれのIAMユーザーに許される権限は、ポリシーによってコントロールすることができます。
管理者によって必要最小限の権限を持つIAMユーザーを作成され、その認証情報を担当者に共有し使用する流れとなります。
なお、IAMユーザーもルートアカウントと同様にMFAの設定は推奨です。
IAMロールは許可される権限がポリシーで定義されるという点ではIAMユーザーと同じですが、それ単体でサインインすることはできません。
IAMユーザーは1人につき1つ割り当てられるべきなのに対し、IAMロールは複数の人に関連づけることができます。
これだけだと何のために必要なのかと思われるかも知れませんが、応用的な活用として一時的セキュリティ認証情報(AWS STS)を使用して動的に一時ユーザーを作成する際に、権限付与に使われます。(よく分からなくても構いません。)
AWSのグローバルインフラストラクチャについて理解していきましょう。
引用元：AWSのデータセンター
データセンターとは大量のサーバーを収容し、電力を確保し、安全に稼働させ続ける施設のことです。
AWSは独自のデータセンターを世界中に多数保有しています。独自に構築することで強固なセキュリティ、地震や洪水などの自然災害対策、電力効率の改善などを実現しています。
AWSのデータセンターは世界各地に存在しており、地理的に離れたロケーションのことをリージョンと言います。
2018年12月現在、世界中に20のリージョンが存在しており、さらに4つの新しいリージョンが追加される予定です。
引用元：グローバルインフラストラクチャ
日本では東京リージョンと大阪リージョンが利用できます。
※ただし大阪は「ローカルリージョン」であり招待制となっています。(2018年12月現在)
マネジメントコンソールでは現在のリージョンをヘッダ右側部分で確認することができ、リージョンの切り替えも自由に行えます。うっかり意図しないリージョンでサービスを利用しないよう、しっかりと確認しておきましょう。
リージョンによってはコスト単価や利用可能サービスが微妙に異なります。新しいサービスはまず米国東部（バージニア北部）リージョンに導入され、徐々に他のリージョンに広がっていくことが多いです。
リージョンはさらに複数のアベイラビリティゾーンで構成されています。
アベイラビリティゾーン(Availability Zone、AZと略されます)はリージョンを構成する要素で、それ自体複数のデータセンタで構成され、高い耐障害性を提供します。
リージョンとAZの関係は以下の図が分かりやすいです。
引用元：リージョンとアベイラビリティゾーン
この図の通り、リージョンは複数のAZから構成されています。
リージョン間は「東京とロンドン」のように地理的に遠く離れているため、通信にはレイテンシ(遅延)が発生します。(数十〜数百msec)
一方で同一リージョン内のAZ間では高速なNWが敷設され、数msecという低レイテンシを実現しています。
ビジネスの観点からはITシステムの可用性は非常に重要な指標です。可用性とは「システムがどれだけ停止せずにユーザーへサービスを提供できるか？」ということです。
例えばECサイトであればシステムトラブルにより停止してしまうと、その時間の分だけ売上の機会を喪失してしまいます。大規模なシステムであれば僅かな停止が大きな損失へと繋がってしまいます。
可用性を向上する1つの手段として、システムの冗長化があります。そして、物理的に分散させることで障害発生時のシステム停止のリスクを低減させることができます。
AWSで冗長構成を実現する方法としてMulti-AZ構成があります。以下の図のように複数のAZに分散してシステムを稼働させることで、一方のインスタンス障害やAZ障害が発生しても、他方のシステムでサービスの提供を継続させることができます。
(図)
可用性はMulti-AZで良いではないかと思われるかもしれませんが、重要なシステムでは数十年に一度起こるような大災害でもサービスを提供し続けなければならない場合もあります。これはDR(Disaster Recovery、災害復旧)という考え方であり、AWSで実現するための方法はリージョン間レプリケーションです。
(図)
物理的に離れた別のリージョンにシステムのバックアップを取っておくことで、メインのリージョンが停止するような大災害が起こっても、バックアップリージョンでシステムを直ちに稼働させ、サービスを提供することができます。
リージョン間レプリケーションはDR以外にもグローバルに展開するサービスで各地からのアクセスレイテンシを低下させるために使われることもあります。
なお、リージョンやAZは「東京」「シンガポール」のように大雑把なロケーションしか分からず、データセンターの詳細な位置は公開されていません。セキュリティの観点から当然ですね。
リージョンとAZについて詳しく知りたい方はこちらをご覧ください。
次にAWSの最も基本的なサービスであるVPC(Amazon Virtual Private Cloud)について学びましょう。
VPCとは仮想プライベートクラウドのことで、ユーザーごとに独立したクラウドリソースを論理的に切り出してサービスとして提供する機能です。
AWSのインフラストラクチャ上では膨大な数のユーザーのシステムが稼働していますが、VPCのおかげで他ユーザーの状況を気にせずに、自社のサービスを構築することができます。
プライベートな空間ということで、VPCではプライベートIP空間がCIDR形式(10.0.0.0/16など)で割り当てられます。
VPCは1つのリージョンの中に作られます。リージョン内の複数のAZを利用することはできますが、リージョン間を跨って作ることはできません。
以下はVPCの例です。CIDRブロックが割り当てられていることが分かります。
VPCの中にサブネットを作成し、サブネットの中にEC2インスタンスを作成するのがAWSにおけるIaaS利用の第一歩です。
サブネットはVPC内に作ることができるより小さなネットワークです。新しいサブネットを作る際は VPCのCIDRの範囲内からサブネットのCIDRを指定します。
EC2インスタンスを利用するためにはサブネットが欠かせません。VPCに直接EC2インスタンスをデプロイすることはできません。
ポイントはサブネットは単一のAZにしか作れないということです。複数のAZに跨ったサブネットを作ることはできません。
よって、EC2を利用して先ほど説明したMulti-AZ構成とするためには、AZごとにサブネットを作成し、それぞれのサブネットに分散させてEC2インスタンスをデプロイすることが必要となります。
VPCは仮想とはいえプライベートな空間ですので、基本的に通信は内部に閉じており、外部と通信することはできません。しかし、サービスとしてインターネット公開したり、開発中に会社のPCからEC2インスタンスにログインしたりするためにはVPC外部と通信できないといけないですよね？
このような場合はVPCが外部と通信するための出口としてゲートウェイを作成します。
VPCが外部と通信するためのゲートウェイとして主に以下のものがあります。
VPCにインターネットゲートウェイを作成すると、VPC内部のEC2インスタンスがインターネット接続が可能になります。
インターネット接続のためにはパブリックIPアドレスが必要です。VPC内のEC2インスタンスは基本的にプライベートIPアドレスしか持っていませんから、別に割り当ててあげる作業が必要です。EC2インスタンスにパブリックIPを割り当てる方法の1つとしてElastic IPアドレスがあります。
なお、AWSアカウント作成時に最初から作られているVPCには、インターネットゲートウェイが1つ割り当てられています。
仮想プライベートゲートウェイはVPCと外部環境をVPN接続したり、専用線接続するために必要なコンポーネントです。
これらの場合はプライベートIPのままVPC外部と通信を行うことができます。
VPCと専用線接続を行うためのサービスはAWS Direcr Connectと言います。
それぞれの接続イメージ図を公式ドキュメントから示します。サービスの詳細については各ドキュメントを参照してください。
仮想プライベートゲートウェイを用いたVPN接続の例
引用元：AWSマネージドVPN接続
仮想プライベートゲートウェイを用いたDirect Connect接続の例
引用元：AWS Direct Connectとは
話が大きく変わりますが、クラウドサービスにおけるセキュリティの観点で非常に重要な概念について説明します。
このご時世、ITサービスにはセキュリティの担保が必須となっています。クラウドサービスの場合、インフラストラクチャはクラウド事業者が提供し、その上のアプリケーションはユーザーが開発するということが良くあります。
このような場合に、クラウド事業者の責任範囲とユーザーの責任範囲を定義するものが責任共有モデルと呼ばれるものです。
AWSにおける責任共有モデルの考え方はこちらに書かれています。
どこまでがユーザーが責任を負わなければいけないかは、AWSのサービスによって異なります。
大雑把には「クラウドサービスの分類」で説明したIaaS/PaaS/SaaSの図のうち、「クラウドサービス」と書かれている領域はAWSの責任範囲であり、それより上の領域はユーザーの責任範囲となります。
IaaSの場合、責任共有モデルは"クラウド内のセキュリティ"はユーザーの責任範囲、"クラウドのインフラストラクチャ"はAWSの責任範囲となっています。
以下、この図の場合の責任範囲を説明しましょう。
リージョンやAZ、データセンター内に存在するサーバーのセキュリティはAWSが責任を持って管理します。
サービスとして提供するCPU、ストレージなどのリソース、アカウント管理のためのデータベース、リージョンやAZの物理的なネットワーキングはAWSが責任を持って管理します。
ここでいうソフトウェアとはユーザーに論理的に分離されたサーバーリソースを提唱するための仮想化ソフトウェア(ハイパーバイザ)のことです。仮想化ソフトウェアについてはAWSが責任を持って管理します。
ユーザーにサービスとして提供される仮想マシンをインスタンスと呼びます。この図におけるサーバーはインスタンスと解釈してください。インスタンス上に記録されるデータの保護やインスタンスに流れるネットワークトラフィックの保護はユーザの責任範囲です。
インスタンス上のOSやファイアウォールの管理はユーザーの責任範囲です。従ってインスタンスOSのセキュリティパッチやソフトウェアライブラリの更新はユーザが行う必要があります。
AWSではファイアウォール機能を提供するマネージドサービスとしてセキュリティグループがあります。セキュリティグループを活用して、適切に通信を制御することもユーザーの責任です。
インスタンス上にデプロイするアプリケーションのセキュリティ対策はユーザの責任範囲です。
ユーザーがデプロイしたアプリケーションが持つデータはユーザの責任範囲です。
PaaSやSaaSではIaaSに比べてAWSの責任範囲がより広くなります。
大雑把にはPaaSはIaaSのものに加えて④⑤もAWSの責任範囲となり、ユーザーは自身がデプロイするアプリケーションの管理に集中することができます。
SaaSの場合は全ての領域がAWSの責任となり、ユーザーは管理する必要がありません。サービスとして利用するのみとなります。
AWSのコストについて考えてみましょう。最初の方でAWSはコスト効率が良いという説明がありましたが、何も考えずに使っていてはむしろ従来のIT資産よりもコストが高くなることもあり得ます。
クラウドサービスでは従来以上にコスト管理が重要となってきます。
クラウドサービスの課金体系の特徴は、オンデマンドに使った分だけ料金を支払うということです。これにより初期投資を行わなくて済むというメリットがあります。
一方で使った分だけ課金されるため、きちんと管理しないと無尽蔵にコストが増えていってしまいます。
予算の管理をおろそかにして、目の前の欲しいものをひたすらに買い続けていると、気づいた時には貯金が底を尽きてしまうようなものです。
よってクラウドサービスにおけるコスト管理で最も重要なのはコストの把握、可視化です。
可視化できないものは管理もできないとは良く言ったものです。
まずはコストを把握してみましょう。
マネジメントコンソールのヘッダー部分のアカウントをクリックし、プルダウンから「請求ダッシュボード」をクリックします。
請求ダッシュボードでは月額コストを把握できます。
下記のグラフでは「先月の月額コスト」「今月の1日から本日までにかかったコスト」「今月の月額コスト予測」が表示されています。
「料金明細」をクリックすると、サービス毎のより詳細なコストを確認できます。
これらを定期的に確認し、余計なコストが発生していないかを把握し、コスト削減のためのアクションを打てるようになります。
より詳細にコストを分析するツールとしてコストエクスプローラー(Cost Explorer)があります。
コストエクスプローラではサービスやリージョン、タグなど様々な条件でフィルタを掛けることができます。ユーザーがフィルタ条件をカスタマイズすることで、コストを様々な観点から分析することが可能となります。
結果はグラフ表示されるため、コストの可視化としても利用できます。
以下はサービスごとのコストを可視化した例です。
横軸の単位は「日別」「月別」から選択することができ、最大過去13ヶ月までのコストデータを表示することができます。
なお、デフォルトではコスト管理系のサービスはルートアカウントのみ権限があります。
IAMユーザーでコスト管理サービスを利用するためには、ルートアカウントにてIAMユーザーへコスト管理サービスへのアクセスを許可してください。(参考はこちら)
コスト分析と同じく重要なのがコスト見積もりです。AWSではWeb UIベースの簡易見積もりツールとしてAWS Simple Monthly Calculatorが利用できます。
AWS Simple Monthly Calculatorでは、利用するサービスやインスタンスを1つずつ入力していくと、1ヶ月あたりのトータルコストが表示されるようになっています。
詳細までは決まらなくとも大まかなコスト感を掴むにはこのサービスで十分です。新しくAWSでのシステム構築する場合、まずはこのツールを利用してコスト見積もりを行ってみましょう。
AWSには膨大なサービスが提供されており、全てを理解することは容易ではありません。
幸いなことにAWSは公式ドキュメントが非常に充実しているので、必要に応じて読み込んで理解を深めましょう。
AWSのドキュメントは以下の3つが基本となります。
AWSではBlack Belt Online Seminar シリーズとしてオンラインセミナーが展開されており、その資料が公開されています。各サービスの概要が分かりやすく説明されており、入門編として非常にオススメのコンテンツです。
コンテンツの一覧はこちら。膨大な量の資料があることが分かりますね。
AWS初心者にオススメの資料をピックアップします。まずは以下の資料を一通り読んでみましょう。
Black Beltを読むコツとしては、サービスの詳細な仕様まで理解しようとせず、大まかな特徴をイメージできることをゴールとしてサクサク読んでいくことです。
「こんなにたくさん読まないといけないのか・・・」と気を落とさず。サクサク読んでいくのがコツですよ！
サービスの概要をざっとキャッチアップするのにはBlack Beltが適していますが、より細かい仕様まで正しく理解するにはドキュメントを読み込みましょう。
AWSドキュメントにはユーザーガイド、開発者ガイド、APIリファレンス、チュートリアルなどがあり、こちらに一覧がまとまっています。
「このサービスの特徴や仕様を細かく調べたい！」という時にはAWSドキュメントを当たってみましょう。
なお、サービス名でググってもこれらのドキュメントがヒットすることが多いです。検索も活用していきましょう。
AWSの技術的なノウハウ、ベストプラクティスを学ぶためにはホワイトペーパーが適しています。一覧はこちら。
こちらも膨大な量のドキュメントが存在しています。必要に応じてピックアップして読み込んでいきましょう。
なお、ホワイトペーパーは英語しか存在しないドキュメントも数多く存在します。
英語が苦手な方にとってはしんどいかもしれませんが、ここは良い機会と考えリーディングにチャレンジしてみましょう。
技術の世界では最新の情報は英語でしか流通していないことが多く、英語のドキュメントを読破する能力は必ず役立ちます。筆者も英語はすこぶる苦手だったのですが、AWSのホワイトペーパーを通じて少しずつリーディングも苦にならなくなっていきました。
オススメのホワイトペーパーをいくつか挙げておきます。
(※1) AWS S3は拡張性と耐久性に優れたクラウドストレージサービスです。
(※2) AWS EMRはHadoopなどのビックデータフレームワークを簡単に実行できるサービスです。
今回はAWS勉強会入門編として、AWSとは何なのか？ AWSのサービス概要や特徴などを解説していきます。
この記事のゴールは基本サービスであるEC2を触れるようになるための事前知識をマスターすることです。
※ 本記事は超入門編であり、サービスについて細かい説明は行なっておりません。各サービスには公式ドキュメントへのリンクを貼っているので、詳細を知りたい方はそちらをご参照ください。
AWSについて
AWSとは何者なのでしょうか。最初にAWSのイメージを掴むために概要の説明を行います。
AWSとは何か？
AWSはAmazon Web Servicesの略です。まずは公式サイトの説明を見てみましょう。アマゾン ウェブ サービス（AWS）は、米アマゾン・ドット・コムを支えてきた技術がベースとなるクラウドサービスです。柔軟で耐久性と拡張性に優れており、世界で数百万以上、日本でも10万以上のお客様が利用しています。Amazon.com社内で培われた技術を「クラウド」の形態で提供するサービスとのこと。Amazon.comは言わずと知れた世界最大級のECサービスですね。
AWSの歴史
それではAWSの誕生とそれからの沿革を見ていきましょう。AWSが誕生するまでの秘話からエッセンスをピックアップします。AWSはAmazon社内のビジネス課題を解決するために生まれました。例えばAmazonは顧客の過去の注文データを全て保管しています。これにより以前購入した商品のお知らせや精度の高いレコメンドを行えるようになりました。全ての注文データを保存するためには大容量かつデータが失われることのないストレージサービスが必要となり、ここからAmazon S3(※1)が誕生しました。またアフェリエイトプログラムの成長に伴い、支払計算システムの処理所用時間の遅延が課題となっており、この解決のために大規模バッチ処理を並列で行えるAmazon Elastic MapReduce(EMR)(※2)が生まれましたAWSはAmazonのビジネス課題を解決するために作り上げたITを誰でもサービスとして利用できるようにしたものです。一般的にはクラウドコンピューティングと呼ばれています。つまり、AWSは元々はAmazon社内の課題を解決するために開発された技術で、それをAmazon以外の人々や企業でも使えるようにしたサービスということですね。
AWSの沿革についてはこちらに概略が書かれています。
クラウドサービスとは？
ここまで「クラウドサービス」という言葉が出てきていますが、AWSの具体的な話しを進める前にクラウドについて確認しておきましょう。「クラウド」とは、クラウドサービスプラットフォームからインターネット経由でコンピューティング、データベース、ストレージ、アプリケーションをはじめとした、さまざまなITリソースをオンデマンドで利用することができるサービスの総称です。引用元：クラウドとは？
上記の説明にあるように、クラウドとはITビジネスを展開するために必要なリソースを、オンデマンドで利用することができるサービスです。オンデマンド(on demand)とは必要な時に必要なだけ利用するということです。
従来はITでビジネスを展開しようと考えた時、必要なサーバ等のハードウェアやその置き場所、各種ソフトウェア、ライセンスなど全て自社で調達しなければなりませんでした。クラウドを使うことでインフラ調達のコストを抑えつつ迅速に行い、製品を素早く市場に投入したり、削減できた資金をより新しい価値を生むことに投資することができるようになります。
クラウドはこのようなメリットがあり、日本政府もクラウド・バイ・デフォルト原則として、これからは政府情報システムをクラウドベースで検討するという提言を出しています。
政府情報システムは、クラウド・バイ・デフォルト原則、すなわち、クラウドサービスの利用を第一候補として、その検討を行うものとする。
クラウドサービスの分類
クラウドはそのサービス形態によって「IaaS」「PaaS」「SaaS」の3つに分類されます。
IaaS(Infrastructure as a Service)
IaaSとは仮想サーバやOS、ネットワークなどのITインフラをインターネット上のサービスとして提供する形態です。ユーザはビジネス要件に応じてハードウェアのスペック、OSの種類などを必要に応じて選択することができます。クラウドサービスの分類の中で最もユーザの自由度が高い形態です。
PaaS(Platform as a Service)
PaaSとはアプリケーション開発のプラットフォームをサービスとして利用できる形態です。ハードウェアやOSに加えて、開発に必要なライブラリ、ミドルウェア、データベースなどもサービスとして提供され、ユーザは自社のアプリケーション開発に集中することができます。
SaaS(Software as a Service)
SaaSは完成されたソフトウェア製品をインターネット経由で利用する形態です。ユーザ自身が開発や運用を行うことはありません。SaaSアプリケーションの一般的な例の１つにGmailなどのウェブメールサービスがあります。これらのクラウドの分類は以下のような図で説明されることが一般的です。大まかにはサービスとして提供されるレイヤが多いほどユーザが自身で用意する必要が少なくなりますが、カスタマイズ性は乏しくなります。ユーザはビジネス要件に応じて適切なサービス携帯を柔軟に選択する必要があります。
引用元：知っておきたいIaaS、PaaS、SaaSの違い
AWSの評価
Gartnerによると2017年のクラウドサービス市場でAWSは51.8%のシェアを誇り、マジック・クアドラントにおいてもビジョンの完全性と実行能力に優れた「リーダー」と評価されています。引用元：Worldwide IaaS Public Cloud Services Market Share(Gartner)
引用元：Gartner’s IaaS Magic Quadrant
※マジック・クアドラントについてはこちらを参照。
横軸がビジョンの完全性、縦軸がその実行能力を評価しています。
Google、Microsoft、IBMといった名だたるIT企業がクラウドサービス市場に参入していますが、その中でも先進性・シェア共にAWSが圧倒的に優位に立っているということがわかります。
AWSの特徴
なぜこれほどまでにAWSが広く受け入れられているのでしょうか。AWSによる公式のOverviewにて、AWSを他のサービスと区別する違いは以下の5つだと述べられています。
Flexible(柔軟性)
AWSでは様々なプログラミングモデルや言語、OSなどをAWS社内で培われたナレッジに基いてサービスとして提供されます。ユーザはビジネス要件に応じてそれらを柔軟に組み合わせ、より少ない投資で導入することができます。
Cost-effective(コスト効率)
AWSではハードウェア等の初期投資が不要で、オンデマンドで必要な分だけリソースを確保し、使ったリソース分にだけ課金されます。またAWSを使うことでビジネスを迅速に展開でき、このこともコスト低減に役立ちます。結果としてトータルのROI(Return On Investment)を高めることができます。
Scalable and elastic(拡張性と弾力性)
ビジネス要件に応じて素早くリソースを拡張したり縮小することができます。例えばECサイトの場合、特典期間に通常の2~3倍のトラフィックが発生することがあります。従来のITではこのような瞬間的なトラフィックに対応するためにはインフラへの投資が必要でした。AWSではELB(Elastic Load Blancer)とAuto-Scalingを導入することで、自動的にクラウドリソースを増減することができます。
Secure(セキュリティ)
セキュリティの面でもメリットがあります。物理的側面ではAWSは世界中にデータセンタ保有しており、部外者は入室できないなど、長年の経験に基づいて堅牢なセキュリティ対策を実施しています。ユーザがAWS上に保管するデータは暗号化が可能です。AWSのサービスを利用する際には権限を持たないアクセスを制限することでセキュリティを担保します。これはユーザがAWSのセキュリティベストプラクティスを正しく理解してシステムを構築しなければならないため、これらを導入するためのドキュメントを提供しています。
Experienced(経験豊かな)
AWSは毎年数百万ユーザが利用し数十億ドルの売上を誇るAmazon.comのインフラストラクチャを長年運用してきた経験があります。既存のIT資産をAWSへ移行するには、今までのサービスが継続して提供できるように様々なことを考えなければいけません。AWSを利用するば既存IT資産をシームレスにクラウドへ移行できます。AWSの豊かな経験に基づくインフラストラクチャはスケーラビリティ、セキュリティ、信頼性、コスト効率に置いてユーザの期待を満たす、またはそれ以上の結果をもたらします。ここまででAWSとは何なのかイメージは掴めてきたでしょうか？
ここからはAWSのサービスを利用する上で、知っておくべき事前知識をいくつか説明していきます。
マネジメントコンソール
マネジメントコンソールはAWSのサービスを利用するためのWebユーザインタフェースです。ブラウザからアクセスして使うもので、AWSを利用する方法のうち最も基本的なものです。(玄人向けにはAWS CLIやAWS SDK、AWS API Gatewayなどがあります。)マネジメントコンソールではAWSのアカウントを管理したり、サービスを検索したりすることができます。AWSを利用する上で最も多く使用するツールになります。
AWSマネジメントコンソールのサービス検索画面。100以上のサービスを利用することができます。
ルートアカウント
AWSを利用するために最初に作成するアカウントをルートアカウントと言います。ルートアカウントの作成にはメールアドレスとクレジットカードが必要です。アカウントを作成しただけでは課金はされませんが、サービスを利用すると利用量に応じて登録したクレジットカードに請求がくるので注意が必要です。
AWSではルートアカウントを用いることは非推奨とされています。ルートアカウントはAWSの全てのサービス・リソースに対するアクセス権限を持つため、アカウントをハッキングされたり、オペレーションミスが発生した際のリスクが高いためです。
公式ドキュメントにもこのことが書かれています。
ベストプラクティスとして、ルートユーザー は日常業務に使用しないでください。代わりに、IAM エンティティ (ユーザーおよびロール) を作成します。ルートアカウントはMFA(Multi-Factor Authentication：多要素認証)を設定し、管理者のみが利用できる状態とすることが望ましいです。(MFAは「二段階認証」ともよく呼ばれます。)
定常業務ではルートアカウントの代わりにIAMというサービスをユーザアカウント管理に利用します。
IAM(Identity and Access Management)
IAMとはIdentity and Access Managementの略で、ユーザーに対して AWSへのアクセスを安全に制御するための仕組みです。アクセス権限を付与される実体としてはIAMユーザーとIAMロールの2種類があり、アクセス権限はポリシーとしてこれらに関連づけられます。
IAMユーザー
IAMユーザーはパスワードを用いてAWSマネジメントコンソールにサインインすることができます。ルートアカウントと異なり、それぞれのIAMユーザーに許される権限は、ポリシーによってコントロールすることができます。
管理者によって必要最小限の権限を持つIAMユーザーを作成され、その認証情報を担当者に共有し使用する流れとなります。
なお、IAMユーザーもルートアカウントと同様にMFAの設定は推奨です。
IAMロール
IAMロールは許可される権限がポリシーで定義されるという点ではIAMユーザーと同じですが、それ単体でサインインすることはできません。IAMユーザーは1人につき1つ割り当てられるべきなのに対し、IAMロールは複数の人に関連づけることができます。
これだけだと何のために必要なのかと思われるかも知れませんが、応用的な活用として一時的セキュリティ認証情報(AWS STS)を使用して動的に一時ユーザーを作成する際に、権限付与に使われます。(よく分からなくても構いません。)
リージョンとアベイラビリティゾーン
AWSのグローバルインフラストラクチャについて理解していきましょう。
AWSのデータセンター
引用元：AWSのデータセンター
データセンターとは大量のサーバーを収容し、電力を確保し、安全に稼働させ続ける施設のことです。
AWSは独自のデータセンターを世界中に多数保有しています。独自に構築することで強固なセキュリティ、地震や洪水などの自然災害対策、電力効率の改善などを実現しています。
リージョン
AWSのデータセンターは世界各地に存在しており、地理的に離れたロケーションのことをリージョンと言います。2018年12月現在、世界中に20のリージョンが存在しており、さらに4つの新しいリージョンが追加される予定です。
引用元：グローバルインフラストラクチャ
日本では東京リージョンと大阪リージョンが利用できます。
※ただし大阪は「ローカルリージョン」であり招待制となっています。(2018年12月現在)
マネジメントコンソールでは現在のリージョンをヘッダ右側部分で確認することができ、リージョンの切り替えも自由に行えます。うっかり意図しないリージョンでサービスを利用しないよう、しっかりと確認しておきましょう。
リージョンによってはコスト単価や利用可能サービスが微妙に異なります。新しいサービスはまず米国東部（バージニア北部）リージョンに導入され、徐々に他のリージョンに広がっていくことが多いです。
リージョンはさらに複数のアベイラビリティゾーンで構成されています。
アベイラビリティゾーン(AZ)
アベイラビリティゾーン(Availability Zone、AZと略されます)はリージョンを構成する要素で、それ自体複数のデータセンタで構成され、高い耐障害性を提供します。リージョンとAZの関係は以下の図が分かりやすいです。
引用元：リージョンとアベイラビリティゾーン
この図の通り、リージョンは複数のAZから構成されています。
リージョン間は「東京とロンドン」のように地理的に遠く離れているため、通信にはレイテンシ(遅延)が発生します。(数十〜数百msec)
一方で同一リージョン内のAZ間では高速なNWが敷設され、数msecという低レイテンシを実現しています。
可用性を向上させる工夫
ビジネスの観点からはITシステムの可用性は非常に重要な指標です。可用性とは「システムがどれだけ停止せずにユーザーへサービスを提供できるか？」ということです。例えばECサイトであればシステムトラブルにより停止してしまうと、その時間の分だけ売上の機会を喪失してしまいます。大規模なシステムであれば僅かな停止が大きな損失へと繋がってしまいます。
可用性を向上する1つの手段として、システムの冗長化があります。そして、物理的に分散させることで障害発生時のシステム停止のリスクを低減させることができます。
AWSで冗長構成を実現する方法としてMulti-AZ構成があります。以下の図のように複数のAZに分散してシステムを稼働させることで、一方のインスタンス障害やAZ障害が発生しても、他方のシステムでサービスの提供を継続させることができます。
(図)
可用性はMulti-AZで良いではないかと思われるかもしれませんが、重要なシステムでは数十年に一度起こるような大災害でもサービスを提供し続けなければならない場合もあります。これはDR(Disaster Recovery、災害復旧)という考え方であり、AWSで実現するための方法はリージョン間レプリケーションです。
(図)
物理的に離れた別のリージョンにシステムのバックアップを取っておくことで、メインのリージョンが停止するような大災害が起こっても、バックアップリージョンでシステムを直ちに稼働させ、サービスを提供することができます。
リージョン間レプリケーションはDR以外にもグローバルに展開するサービスで各地からのアクセスレイテンシを低下させるために使われることもあります。
なお、リージョンやAZは「東京」「シンガポール」のように大雑把なロケーションしか分からず、データセンターの詳細な位置は公開されていません。セキュリティの観点から当然ですね。
リージョンとAZについて詳しく知りたい方はこちらをご覧ください。
VPC(Amazon Virtual Private Cloud)
次にAWSの最も基本的なサービスであるVPC(Amazon Virtual Private Cloud)について学びましょう。VPCとは仮想プライベートクラウドのことで、ユーザーごとに独立したクラウドリソースを論理的に切り出してサービスとして提供する機能です。
AWSのインフラストラクチャ上では膨大な数のユーザーのシステムが稼働していますが、VPCのおかげで他ユーザーの状況を気にせずに、自社のサービスを構築することができます。
プライベートな空間ということで、VPCではプライベートIP空間がCIDR形式(10.0.0.0/16など)で割り当てられます。
VPCは1つのリージョンの中に作られます。リージョン内の複数のAZを利用することはできますが、リージョン間を跨って作ることはできません。
以下はVPCの例です。CIDRブロックが割り当てられていることが分かります。
VPCの中にサブネットを作成し、サブネットの中にEC2インスタンスを作成するのがAWSにおけるIaaS利用の第一歩です。
サブネット
サブネットはVPC内に作ることができるより小さなネットワークです。新しいサブネットを作る際は VPCのCIDRの範囲内からサブネットのCIDRを指定します。EC2インスタンスを利用するためにはサブネットが欠かせません。VPCに直接EC2インスタンスをデプロイすることはできません。
ポイントはサブネットは単一のAZにしか作れないということです。複数のAZに跨ったサブネットを作ることはできません。
よって、EC2を利用して先ほど説明したMulti-AZ構成とするためには、AZごとにサブネットを作成し、それぞれのサブネットに分散させてEC2インスタンスをデプロイすることが必要となります。
VPC外部との通信
VPCは仮想とはいえプライベートな空間ですので、基本的に通信は内部に閉じており、外部と通信することはできません。しかし、サービスとしてインターネット公開したり、開発中に会社のPCからEC2インスタンスにログインしたりするためにはVPC外部と通信できないといけないですよね？このような場合はVPCが外部と通信するための出口としてゲートウェイを作成します。
VPCが外部と通信するためのゲートウェイとして主に以下のものがあります。
| ゲートウェイの種類 | アイコン | 説明 |
|---|---|---|
| インターネットゲートウェイ | インターネットに接続するためのゲートウェイ | |
| 仮想プライベートゲートウェイ | VPCと外部環境の間にVPN接続や専用線接続を行うためのゲートウェイ |
インターネットゲートウェイ
VPCにインターネットゲートウェイを作成すると、VPC内部のEC2インスタンスがインターネット接続が可能になります。インターネット接続のためにはパブリックIPアドレスが必要です。VPC内のEC2インスタンスは基本的にプライベートIPアドレスしか持っていませんから、別に割り当ててあげる作業が必要です。EC2インスタンスにパブリックIPを割り当てる方法の1つとしてElastic IPアドレスがあります。
なお、AWSアカウント作成時に最初から作られているVPCには、インターネットゲートウェイが1つ割り当てられています。
仮想プライベートゲートウェイ
仮想プライベートゲートウェイはVPCと外部環境をVPN接続したり、専用線接続するために必要なコンポーネントです。これらの場合はプライベートIPのままVPC外部と通信を行うことができます。
VPCと専用線接続を行うためのサービスはAWS Direcr Connectと言います。
それぞれの接続イメージ図を公式ドキュメントから示します。サービスの詳細については各ドキュメントを参照してください。
仮想プライベートゲートウェイを用いたVPN接続の例
引用元：AWSマネージドVPN接続
仮想プライベートゲートウェイを用いたDirect Connect接続の例
引用元：AWS Direct Connectとは
責任共有モデル
話が大きく変わりますが、クラウドサービスにおけるセキュリティの観点で非常に重要な概念について説明します。このご時世、ITサービスにはセキュリティの担保が必須となっています。クラウドサービスの場合、インフラストラクチャはクラウド事業者が提供し、その上のアプリケーションはユーザーが開発するということが良くあります。
このような場合に、クラウド事業者の責任範囲とユーザーの責任範囲を定義するものが責任共有モデルと呼ばれるものです。
AWSにおける責任共有モデルの考え方はこちらに書かれています。
どこまでがユーザーが責任を負わなければいけないかは、AWSのサービスによって異なります。
大雑把には「クラウドサービスの分類」で説明したIaaS/PaaS/SaaSの図のうち、「クラウドサービス」と書かれている領域はAWSの責任範囲であり、それより上の領域はユーザーの責任範囲となります。
IaaSの場合、責任共有モデルは"クラウド内のセキュリティ"はユーザーの責任範囲、"クラウドのインフラストラクチャ"はAWSの責任範囲となっています。
以下、この図の場合の責任範囲を説明しましょう。
AWSの責任領域
① グローバルインフラストラクチャ
リージョンやAZ、データセンター内に存在するサーバーのセキュリティはAWSが責任を持って管理します。
② サーバーリソース
サービスとして提供するCPU、ストレージなどのリソース、アカウント管理のためのデータベース、リージョンやAZの物理的なネットワーキングはAWSが責任を持って管理します。
③ ソフトウェア(ハイパーバイザ)
ここでいうソフトウェアとはユーザーに論理的に分離されたサーバーリソースを提唱するための仮想化ソフトウェア(ハイパーバイザ)のことです。仮想化ソフトウェアについてはAWSが責任を持って管理します。
ユーザの責任領域
④ インスタンス上のデータやネットワークトラフィック
ユーザーにサービスとして提供される仮想マシンをインスタンスと呼びます。この図におけるサーバーはインスタンスと解釈してください。インスタンス上に記録されるデータの保護やインスタンスに流れるネットワークトラフィックの保護はユーザの責任範囲です。
⑤ OS、ネットワーク、ファイアウォール
インスタンス上のOSやファイアウォールの管理はユーザーの責任範囲です。従ってインスタンスOSのセキュリティパッチやソフトウェアライブラリの更新はユーザが行う必要があります。AWSではファイアウォール機能を提供するマネージドサービスとしてセキュリティグループがあります。セキュリティグループを活用して、適切に通信を制御することもユーザーの責任です。
⑥ アプリケーション
インスタンス上にデプロイするアプリケーションのセキュリティ対策はユーザの責任範囲です。
⑦ アプリケーション上のデータ
ユーザーがデプロイしたアプリケーションが持つデータはユーザの責任範囲です。
PaaSやSaaSの場合
PaaSやSaaSではIaaSに比べてAWSの責任範囲がより広くなります。大雑把にはPaaSはIaaSのものに加えて④⑤もAWSの責任範囲となり、ユーザーは自身がデプロイするアプリケーションの管理に集中することができます。
SaaSの場合は全ての領域がAWSの責任となり、ユーザーは管理する必要がありません。サービスとして利用するのみとなります。
AWSのコスト
AWSのコストについて考えてみましょう。最初の方でAWSはコスト効率が良いという説明がありましたが、何も考えずに使っていてはむしろ従来のIT資産よりもコストが高くなることもあり得ます。クラウドサービスでは従来以上にコスト管理が重要となってきます。
使った分だけ課金
クラウドサービスの課金体系の特徴は、オンデマンドに使った分だけ料金を支払うということです。これにより初期投資を行わなくて済むというメリットがあります。一方で使った分だけ課金されるため、きちんと管理しないと無尽蔵にコストが増えていってしまいます。
予算の管理をおろそかにして、目の前の欲しいものをひたすらに買い続けていると、気づいた時には貯金が底を尽きてしまうようなものです。
よってクラウドサービスにおけるコスト管理で最も重要なのはコストの把握、可視化です。
可視化できないものは管理もできないとは良く言ったものです。
コストの把握と分析
まずはコストを把握してみましょう。マネジメントコンソールのヘッダー部分のアカウントをクリックし、プルダウンから「請求ダッシュボード」をクリックします。
請求ダッシュボードでは月額コストを把握できます。
下記のグラフでは「先月の月額コスト」「今月の1日から本日までにかかったコスト」「今月の月額コスト予測」が表示されています。
「料金明細」をクリックすると、サービス毎のより詳細なコストを確認できます。
これらを定期的に確認し、余計なコストが発生していないかを把握し、コスト削減のためのアクションを打てるようになります。
コストエクスプローラー
より詳細にコストを分析するツールとしてコストエクスプローラー(Cost Explorer)があります。コストエクスプローラではサービスやリージョン、タグなど様々な条件でフィルタを掛けることができます。ユーザーがフィルタ条件をカスタマイズすることで、コストを様々な観点から分析することが可能となります。
結果はグラフ表示されるため、コストの可視化としても利用できます。
以下はサービスごとのコストを可視化した例です。
横軸の単位は「日別」「月別」から選択することができ、最大過去13ヶ月までのコストデータを表示することができます。
なお、デフォルトではコスト管理系のサービスはルートアカウントのみ権限があります。
IAMユーザーでコスト管理サービスを利用するためには、ルートアカウントにてIAMユーザーへコスト管理サービスへのアクセスを許可してください。(参考はこちら)
コストシミュレーションツール
コスト分析と同じく重要なのがコスト見積もりです。AWSではWeb UIベースの簡易見積もりツールとしてAWS Simple Monthly Calculatorが利用できます。AWS Simple Monthly Calculatorでは、利用するサービスやインスタンスを1つずつ入力していくと、1ヶ月あたりのトータルコストが表示されるようになっています。
詳細までは決まらなくとも大まかなコスト感を掴むにはこのサービスで十分です。新しくAWSでのシステム構築する場合、まずはこのツールを利用してコスト見積もりを行ってみましょう。
AWSの資料
AWSには膨大なサービスが提供されており、全てを理解することは容易ではありません。幸いなことにAWSは公式ドキュメントが非常に充実しているので、必要に応じて読み込んで理解を深めましょう。
AWSのドキュメントは以下の3つが基本となります。
① Black Belt
AWSではBlack Belt Online Seminar シリーズとしてオンラインセミナーが展開されており、その資料が公開されています。各サービスの概要が分かりやすく説明されており、入門編として非常にオススメのコンテンツです。コンテンツの一覧はこちら。膨大な量の資料があることが分かりますね。
AWS初心者にオススメの資料をピックアップします。まずは以下の資料を一通り読んでみましょう。
Black Beltを読むコツとしては、サービスの詳細な仕様まで理解しようとせず、大まかな特徴をイメージできることをゴールとしてサクサク読んでいくことです。
| 分類 | サービス名 | リンク |
|---|---|---|
| コンピューティング | AmazonEC2 | こちら |
| コンピューティング | Elastic Load Balancing(ELB) | こちら |
| コンピューティング | Auto Scaling | こちら |
| データベース | Amazon RDS | こちら |
| ストレージ & コンテンツ配信 | Amazon EBS | こちら |
| ストレージ & コンテンツ配信 | Amazon S3 | こちら |
| ネットワーキング | Amazon VPC | こちら |
| 管理ツール | Amazon CloudWatch | こちら |
| 管理ツール | AWS CloudFormation | こちら |
| セキュリティ & アイデンティ | AWS IAM | こちら |
② AWSドキュメント
サービスの概要をざっとキャッチアップするのにはBlack Beltが適していますが、より細かい仕様まで正しく理解するにはドキュメントを読み込みましょう。AWSドキュメントにはユーザーガイド、開発者ガイド、APIリファレンス、チュートリアルなどがあり、こちらに一覧がまとまっています。
「このサービスの特徴や仕様を細かく調べたい！」という時にはAWSドキュメントを当たってみましょう。
なお、サービス名でググってもこれらのドキュメントがヒットすることが多いです。検索も活用していきましょう。
③ ホワイトペーパー
AWSの技術的なノウハウ、ベストプラクティスを学ぶためにはホワイトペーパーが適しています。一覧はこちら。こちらも膨大な量のドキュメントが存在しています。必要に応じてピックアップして読み込んでいきましょう。
なお、ホワイトペーパーは英語しか存在しないドキュメントも数多く存在します。
英語が苦手な方にとってはしんどいかもしれませんが、ここは良い機会と考えリーディングにチャレンジしてみましょう。
技術の世界では最新の情報は英語でしか流通していないことが多く、英語のドキュメントを読破する能力は必ず役立ちます。筆者も英語はすこぶる苦手だったのですが、AWSのホワイトペーパーを通じて少しずつリーディングも苦にならなくなっていきました。
オススメのホワイトペーパーをいくつか挙げておきます。
| タイトル | リンク |
|---|---|
| アマゾン ウェブ サービスの概要 | こちら |
| AWS Well-Architected フレームワーク | こちら |
| AWS セキュリティのベストプラクティス | こちら |
| 伸縮性の自動化 | こちら |
| AWS Well-Architected フレームワーク – コスト最適化の柱 | こちら |
AWSを学ぶメリット
最も使われている
フルスタックエンジニアになれる
Well Architectを知ることができる。
(※1) AWS S3は拡張性と耐久性に優れたクラウドストレージサービスです。(※2) AWS EMRはHadoopなどのビックデータフレームワークを簡単に実行できるサービスです。
コメント
コメントを投稿