## AWSを利用して開発環境を構築する

ITエンジニアの皆さんにとって、**最適なシステム開発環境を手にすることは大きな関心事であり、課題**でしょう。開発プロジェクトが決まっても、*開発環境の構築に手間取り、開発着手が遅れるという事例も少なくありません*。

そのような問題を解消する方法として、AWSの開発環境を利用するという方法があります。まず、従来の開発環境の構築方法について確認し、AWSを利用すると、それがどう変わるのかを検証していきましょう。

開発環境は、効率的・効果的なシステム開発を行うための環境です。この**開発環境の構築には、「開発者が自由に、快適な使える環境」や「本番環境と同一環境」が求められる**のが普通です。

また、一般的にはチーム体制で、複数の開発エンジニアによって使える環境であることが必要です。

こうした条件を満たすために、オンプレミス環境では、本番で利用するサーバーやデータベースソフトなどを先行導入するケースが一般的でした。中には、テスト機と本番機として、2セットを購入するケースもあり、*経営陣から見ると、「無駄使いが多いシステム部門」という偏見を招く*ことも少なからずありました。

### AWS Cloud9は開発環境構築で最も手軽な方法

クラウドサービスが普及するまで、開発環境を整えるのは本番環境を構築するのと同じくらい大変なことでした。今はクラウドサービスが豊富にあり、早ければ10分ほどで開発環境を整えることが可能です。その中でも、**1年間無料で試せるAWSのCloud9が注目を浴びています**。AWSでは、*必要な時に必要なだけサーバー・ストレージ・データベースを利用することができる*ので使い勝手が良さが人気の理由です。

では続いてAWS Cloud9について見ていきましょう。「Cloud9」のネーミングの由来は"Cloud nine"で、"seventh heaven"と同様に、とても幸せな気持ちを表すときに使われる"Cloud nine"です。

そんな**Cloud9はブラウザを利用したIDE**で、JavaScriptやPythonなど、*プログラミングに必要な言語やツールが用意され、直ぐに開発作業に着手することができる*点が特徴です。"

先ほどIDEという言葉が出てきたので、IDEについて確認しておきましょう。**IDEは、英文では*I*ntegrated *D*evelopment *E*nvironmentと記し、統合開発環境のこと**を指します。IDEでは、アプリケーションの開発に必要となる言語・エディタ・コンパイラ・デバッガーソフトウェアなどが全て揃っており、開発者にとっては大変便利なサービスです。*AWSはクラウド環境でのIDEをCloud9として提供*しています。

Cloud9がクラウドベースの便利なIDEであることは分かったと思います。**AWS Cloud9の利用メリット**は数多くありますが、ここでは、代表的なメリットを挙げてみましょう。

### ブラウザだけで直ぐに開発に着手できる

AWS Cloud9はブラウザ上で利用できるツールです。一般的なIDEでは、必要なソフトウェアをローカル環境にインストールし、プログラミング環境を構築しなければならないため、その手間がかかります。一方、**Cloud9はインターネットに繋げてブラウザさえあれば、直ちに利用を始めることが可能**で、面倒な環境構築の必要性がありません。

**AWS Cloud9は、JavaScript・PHP・Python・Rubyなどの主要な言語に対応**しており、プログラミングのツールが予め用意されています。*必要な言語が揃い、開発に必要なファイル・SDK・プラグインなどのインストールの必要がなく、また各種設定も不要*です。これがCloud9のメリットであり、人気の秘密です。

### チームメンバーと共同作業が可能

AWS Cloud9では、クラウド環境でプラウザベースのため、離れた場所にいる**チームメンバーとも共同で開発作業が行えます**。

共同作業では*他のチームメンバーのコーディング内容を同時に確認ができ、相互にIDE内でチャットを利用して連携*ができるため、開発作業の効率が上がります。

AWS Cloud9では、**コードやプログラムをサーバーレスで実行可能なサービス「Lambda」をローカルで利用することができます**。AWS Lambdaをローカル環境で利用することで、*サーバー上でのプログラムデバッグ時間が削減でき、またEC2の利用料金削減*に繋げられます。（トライアル期間中はEC2は基本的に無料）

*AWS Cloud9は、最初の1年間は無料*で利用が可能です。**追加料金なしで、コード編集やデバッグ機能などを無料で利用可能**なのはありがたいですね。また、AWS Cloud9の開発環境では、*LinuxサーバーやWindowsサーバー（英文タイプ）を無料で利用できます*。AWS Cloud9自体は無料ですが、無料枠には制限があり、その制限を超えたり、有料オプションを選択したりすると利用料金がかかる点は予め理解しておきましょう。

AWS Cloud9は、仮想サーバーサービスの**AWS EC2を利用する場合に、利用した分だけ課金される従量課金**です。ただし、*無料利用枠でAWS Cloud9を利用する場合は、AWS EC2の1年間無料利用が可能*です。ちなみに、無料利用できるサービスは次の通りです。

*■コンピューティング：Amazon EC2　750 時間/月*

*■ストレージ：Amazon S3　5GBの標準ストレージ*

*■データベース：Amazon RDS　750 時間*

*■コンピューティング：AWS Lambda　1,000,000 件/月の無料リクエスト*

以上のような、*約70のサービスが無料で1年間試用*できます。

AWS Cloud9を利用する際には、以下の手順を踏む必要があります。

**メールアドレスやパスワード入力・アカウント選択・基本情報入力・支払方法・セキュリティ・サポートプラン選択の6ステップの手順**がありますが、予め必要なものを用意しておくと10分程度完了します。

*参考 : [「AWS Cloud9 の開始方法」](https://aws.amazon.com/jp/cloud9/getting-started/)*

AWS Cloud9の利用にあたっては、最初に**メールアドレスとパスワードが必要**です。最初にAWSアカウントを作成しますが、AWSアカウントの作成にはメールアドレスとパスワードの入力が前提です。

AWSに登録するメールアドレスは、AWSとのやり取りに利用します。また、複数人でAWSからの通知情報などを共有する場合には、*メーリングリストの利用が可能*です。

AWSのアカウントは、**個人利用の「パーソナル」と、法人利用の「プロフェッショナル」の2種類がある**ため、利用目的にあわせてアカウント種類を選びます。

「パーソナル」と「プロフェッショナル」には、AWS上で利用できる機能に差はありませんが、*「プロフェッショナル」を選択するとアカウントの作成時に「会社名」の入力が必要*です。

AWSアカウントの種類選択をしたら、続いて基本情報を入力します。

アカウントの作成に必要となる**基本情報は、氏名・（会社名）・連絡先電話番号・国・住所・郵便番号**です。これらの項目をすべて入力し終えたら、利用規約の*「AWSカスタマーアグリーメント」*に同意し、【続行ボタン】をクリックします。

AWS Cloud9の利用にあたり、利用料金の支払い方法について入力を行います。無料利用枠での登録でも、支払い方法の入力は必須です。

*料金支払い手段は、クレジットカードとデビットカードの2種類だけ*です。支払い代行を利用する場合を除いて、口座振替はできません。**利用できるクレジットカードは、VisaやMasterCardなどの国際ブランドのカード**です。カード情報と請求先住所を入力すると、支払い方法に関する入力が完了します。

*入力したカードの有効性を確認するために、1USD/EURでの請求が発生しますが、有効性が確認された後に、その請求が削除され相殺*されます。

支払方法の入力が済むと、次は**新規に作成したアカウントの本人確認が目的で「セキュリティチェック」**があり、電話またはSMSによるセキュリティチェックが行われます。

AWSから認証コードが送られてくるため、その受取り方法及び国コード（81）を選択し、電話番号を入力するとスマホなどに4桁の検証コードが届きます。その検証コードを入力して合致すれば、本人確認が完了します。

最後のステップで、AWSサポートプランを選択します。

**無料利用枠での登録の場合は「ベーシックプラン」と、有料サービスには「開発者プラン」「ビジネスプラン」に加え、「エンタープライス゜」の3種類があります**。このいずれかを選択すると、AWS Cloud9の利用が可能です。

有料サービスのAWSサポートプランは、AWSアカウント作成後に検討してから申し込みをすることができるため、よく分からない場合は、無料の「ベーシックプラン」を選択しておいても構いません。以下に、参考程度に各プランの内容についてまとめました。

他にも*エンタープライズプランがあり、ミッションクリティカルなシステム、大規模システムなど影響の大きなシステム*を抱えるユーザーに向けたサービスです。月額15,000USDとかなり高額ですが、専門家の強力なサポートが強みです。

無料プランのベーシックプランでは、*サービス状態ダッシュボード・製品 FAQ・リソースセンターやフォーラム、および健全性チェックサポート*など、**一通りのサポートが無料提供**されます。それら以外の製品操作や設定方法、障害原因の切り分けなど、技術的な問題に関する対応を求める場合は有償プランの選択が必要があります。

開発者プランは有償サポートで、月額29USD（約3,100円）が必要ですが、**ベーシックプランの機能に加え、クラウドサポートアソシエーツの利用、システム障害対応などの機能が追加**されます。

*本格的なシステム開発での利用、AWSの有識者がいないチーム利用の場合は、この開発者プランを選択することをおすすめ*します。

ビジネスプランでは、**本格的な開発や本番環境移行などで、より踏み込んだサポートを受けられます**。

利用料金は月額100USD（約10,600円）ですが、プロによる*日本語サポートを24時間365日利用可能*です。ビジネスに直結する障害などは、初回応答時間が1時間以内と素早い対応をしてもらえます。

ここまで、**AWS Cloud9の概要・利用メリット・料金・利用手順などを解説してきました**。

AWS Cloud9は、あっという間に登録できて、クラウド上でシステム開発環境がすぐに作れ、チーム利用ができる大変便利なAWSのサービスです。個人利用や無料での利用も可能なため、*ITエンジニアの皆さんはぜひAWS Cloud9の利用を*検討してみてください。

一般的に開発環境の構築は手間とコストが掛かりますが、AWSのCloud9を利用すれば、そうした問題を一瞬でクリアできます。個人でも開発環境を簡単かつ無料で構築できる「AWS Cloud9」について解説します。ITエンジニアの皆さんはぜひ試してみてください。

クラウドのIDEサービスである「AWS Cloud9」を利用すると、無料で簡単に開発環境の構築が可能である

ブラウザが利用できる環境であれば、全ての開発環境が整った「AWS Cloud9」をチームで同時に使うことが可能

「AWS Cloud9」は個人からエンタープライズまで利用可能なメリット満載のクラウドサービスである

AWS Cloud9を利用すれば無料で開発環境を入手できるのか？

DX時代が到来しましたが、*DXに関してはさまざまな誤解や混乱があります*。ここでは、ITエンジニアの皆さんがDXに関する認識を改め、**DXを自身の成長と活躍にどう生かせば良いのか、AIとの関連も交えて**探っていきます。

*DX（デジタルトランスフォーメーション）*は最早、流行語ではなくなり、一般社会にすっかり定着してきました。経営層が株主総会などで、企業の重点取組事項に「DX推進」を掲げる事例も増えています。また、企業によっては「DX推進部」などの専門部署を設け、DX化に注力する姿勢を示しているところも少なくありません。

DX推進組織を作るのは間違いではないのですが、*経営者が「DX=デジタル化」「DX=AI導入」といった誤解を払拭しないまま進めている企業もあり、一部でDXの失敗や混乱の原因*となっています。

**DXはデジタルの力を借りて、企業の競争力を高めることです。デジタル化が目的ではありません**。ここを見誤ると、DX推進に失敗します。ここはITエンジニアとしても押さえておきたいところです。

### DXは組織変革、デジタルによる業務改革

**DXの目的は大きく変化する社会環境やビジネス環境に対応し、強い経営を目指すこと**です。社会が大きく変わっている以上、仕事のやり方を変え、組織も変わらなくてはなりません。

コロナ禍で在宅ワーク・テレワークが推奨されましたが、DXに取組み、リモート会議やテレワークにコロナ禍の前から取り組んでいた企業は直ちに対応できました。一方、DXを単なるデジタル化と捉えた企業は、仕事のやり方も組織変革も行わず、ただ単にAIなどの最新技術を導入しただけで終わっています。*企業そのものが変わらなければ、DXとは呼べません*。

*DXの推進には3段階*があります。もちろんデジタル化は必須ですが、**DX実現に至るまでに「デジタイゼーション（Digitization）」と「デジタライゼーション（Digitalization）」の2つの段階を経る必要があります**。

*従来アナログで行っていた業務をデジタル化すること*です。例えば、稟議書や申請書など、紙ベースで行っていたものをペーパーレスにしたり、電話や書類で行っていたコミュニケーションをメールやLINEに切り替えたりといったものが該当します。

*デジタル化によって生成・蓄積されたデータを活用し、業務全体を効率化すること*などを指します。DXは最初にデジタイゼーションを進め、デジタライゼーションに移行が完了していることがその前提なのです。

この2つのステップを飛ばしてDXに取り組むのは、体力づくや準備運動を飛ばしていきなりプールに飛び込むようなものです。*DXは最新技術を取り入れることだけではなく、人や組織が変わっていなければ、絵に描いた餅で終わってしまう*リスクがあります。

以上2つのステップを経て、初めてDXのステップに至ることができるということを認識しておく必要があります。

DX推進において、よくあるのが**「DX=AI」という誤解**です。では、AIとは何なのでしょう？*AIを導入すると何が変わる*のでしょうか？

AIの定義は完全に定まっているわけではありませんが、*AIとは"Artificial Intelligence"の略語で、人工知能と訳されています*。AIとコンピューターの違いは、**AIには「学習・推論・判断」といった機能が備わっている**点です。そこで、人の作業をAIが行うことが可能となり、しかも24時間365日、AIは不眠不休で働き続けることができる点が強みです。

AIの進化は目を見張るものがあり、実際に一部の仕事はAIに置き換わっています。AI技術を駆使した無人店舗が登場したり、AIを搭載したコンシェルジュがお客の案内を行ったり、**少しずつ人間の仕事がAIやAIを搭載したロボットによって置き換わっています**。タクシー運転手の仕事も自動運転技術の発達によって無くなっていくと言われています。

一方で、*AIが進展することで生まれる仕事*もあります。AIを開発したり、管理する仕事です。データサイエンティスト、AIエンジニアは益々需要が高まるでしょう。

資格がものを言う、税理士や公認会計士の仕事も将来は無くなるかもしれません。弁護士の仕事もAIがかなりの部分を肩代わりするかもしれません。ただし、*AIは人の仕事を奪うのではなく、人の仕事を手助けし、分業を図りながら共存する関係*へと進化していくでしょう。

さて、先ほども少し触れましたが、DXとAIを混同している人がいると述べました。では実際のところ、*DXとAIは何が違うのか*を見ていきましょう。

### AIはDXを進める上での1つの手段

AIやRPAなどの最新デジタル技術を単に導入しただけではDXの実現はできません。先ほど述べた通り、*DXに到達するためには「デジタイゼーション」と「デジタライゼーション」というステップを踏む必要*があります。

DX実現には、これらのステップを踏みながら、併せてAIをDX実現に向けた1つの手段として、*AIをどう活用するのかという戦略*が必要です。すなわち、**組織変革、ビジネス革新がDXの目的であるのに対し、AIはあくまでもそれらを実現するための手段**だということなのです。ここを見誤ると、DXは失敗します。

ここでRPAという言葉が登場しました。**AIとRPAは同列で扱われることがありますが、それぞれ概念は異なります**。その違いを確認しておきましょう。

*RPAは"Robotic Process Automation"の略語*で、コンピューター上で行われている処理や作業を人に代って自動化する技術のことです。**RPAによって人間が繰り返し行うような定常的業務の自動化が図れる**ことから、*RPAはデジタルレイバー（仮想知的労働者）*とも呼ばれます。

AIには「学習・推論・判断」といった機能が備わり、人の脳と同じような働きを持っています。一方、RPAは作業などの指示をされた事は行いますが、「学習・推論・判断」は行えません。

RPAはあくまでも人が教えた通りに動きますが、*RPAをAIと組み合わせることで、AIが人の代わりに判断と指示を行い、その指示に従ってRPAが作業をすることで、高度な自動化を実現する*ことができます。例えば、自動運転自動車などがその例です。

ただし、あくまでもAIはコンピューターであるため、トラブルやハッキングのリスクはあります。緊急時の対応を誰が行うのか、イレギュラー時の対応や法制度面の整備など、実用化に向けた解決すべき課題が残されています。

ここまでDXとAIを題材にして、ITエンジニアとしてDXについて知っておきたいことを述べてきました。DXの重要性はよく理解頂いたと思いますが、皆さん方が**DX人材と活躍する上で何が必要なのか**について、*DXに求められる人材像*から探っていきたいと思います。

*DX推進に必要な人材について、独立行政法人情報処理推進機（IPA）が、6つの職種を示しています*。これはアンケート調査によって洗い出したものですが、以下参考まで載せておきましょう。

「DXやデジタルビジネス」の実現を主導できるリーダー格の人材

「DXやデジタルビジネス」の企画や立案・推進等を担える人材

「DXやデジタルビジネス」に関するシステムの設計ができる人材

*4.データサイエンティスト／AIエンジニア：*

「DXに関するデジタル技術」AI・IoT等に強く、データ解析にも精通した人材

「DXやデジタルビジネス」に関するユーザー向けのシステムデザインを担当できる人材

上記以外のデジタルシステムの実装、インフラ構築等を担える人材

*参考:[デジタル・トランスフォーメーション推進人材の機能と役割のあり方に関する調査～調査結果サマリ～](https://www.ipa.go.jp/files/000073017.pdf)*

以上、IPAのレポートからDX推進に必要な人材像を挙げてみましたが、デジタル技術の活用などによって企業の優位性を確保するためには、*幅広いスキルを有する人材の必要性*がお分かり頂けたかと思います。

DXを推進していく人材には、**基礎的なIT知識から始まり、データの利活用に関する理解、UI・UX志向などのさまざまなスキルが必要**であり、自ら積極的にそうしたスキルの習得を目指す必要があります。

**DX人材になる最大のメリットは、活躍の場が広がりや収入アップが期待できる点**です。また、DX人材を目指すことによって*スキルアップやキャリアアップ*を図ることができます。

DX人材は引く手あまたであり、職探しで困ることはないでしょう。そして、*DX開発・DX推進で得たノウハウやスキルは必ずその後の仕事にも活かせます*。組織変革や新製品・新サービスの開発にまで関われ、ITという枠を越えて活躍機会が広がります。日本はDX推進によって、世界のトップグループへの返り咲きを目指します。この*国策ともいうべきDXに、1人でも多くのITエンジニアの皆さんが参画*されることを期待しています。

2018年に日本経済の再生に向けて経済産業省が提唱したDXですが、その広がりと共に誤解や混乱が生まれています。AIの導入がDXという誤解もあり、正しい理解がDXの推進には重要です。ここでは、DXの目的、DX実現の手段であるAIについて解説していきます。

DXはデジタルの力を借りて、企業の競争力を高めることであり、デジタル化は目的ではない

DXによる組織変革、ビジネス革新がDXの目的であるのに対し、AIはあくまでもそれらを実現するための手段

DX人材は基礎的なIT知識から始まり、データの利活用に関する理解、UI・UX志向などのさまざまなスキルが必要

DXにAIは必要な要素であるが、AI導入はDX推進とイコールではない

## AWSのセキュリティは万全か？

皆さん、よくご存知のAWSはAmazonが展開する世界最大のクラウドサービスですが、セキュリティ面でも世界最高クラスのサービスが提供されています。そのため、AWSを利用する際には、利用者側で用意するものが無いと信じている方も少なくありません。確かに、AWSにはセキュリティ面でもさまざまな強固なセキュリティ対策が施されており、利用者側はセキュリティ対策が不要と考えがちですが、それは大きな誤りです。

**AWSには「責任共有モデル」と呼ばれるものがあり、利用者側もクラウド内のセキュリティ確保に一定の責任を負っています**。基本的に、AWSは不沈艦と言えるほどの強固なセキュリティによって守られていますが、搭乗員の健康管理に関しては自己管理と認識しておく必要があります。ここでは、*AWSのウィルス対策をはじめとするセキュリティ対策*について解説していきます。

### AWSを利用してセキュリティ事故を起こすとどうなる？

セキュリティ事故は、報道されないものを含めると膨大な件数があると言われています。自社の機密情報漏洩・サーバー攻撃によるサービス停止・データの改ざんや破壊などさまざまありますが、**最も影響が大きいのは個人情報の漏洩**です。

*個人情報が漏洩すると、顧客に直接被害が及び、企業のブランドイメージの失墜ばかりか、株価下落、売上低下、さらには顧客への補償などで、時には企業の経営そのものが危うくなることすらあります*。また、被害がAWSやAWS利用者に及び、*損害賠償請求を受けるリスク*もあります。これほどセキュリティ事故は多大な損害を被るということをまず認識しておきましょう。

AWSには「責任共有モデル」という考え方があります。**「責任共有モデル」は、AWSが提供する数々のインフラやサービスについて、AWSが直接責任を負うべき部分と、利用者が責任を負うべき部分を明確に分けて、責任の分界点を明らかにする考え方**です。*AWSが責任を負っている範囲は具体的にはハードウェア・ソフトウェア・ネットワーク関連・AWSのサービスを提供している施設（データセンター）*です。AWSの責任範囲で発生した障害や事故で、利用者に損害を与えた場合にはAWSが損害賠償責任を負います。

一方、AWSが提供しているサービス以外の部分が利用者側の責任範囲となりますが、責任を負う範囲は、AWSクラウドサービスの利用している範囲によっても異なります。

参照：*[責任共有モデル – アマゾン ウェブ サービス (AWS)](https://aws.amazon.com/jp/compliance/shared-responsibility-model/)*

「責任共有モデル」のAWS側の責任範囲について、もう少し詳しく述べます。「責任共有モデル」における**AWS側の責任範囲は、主にAWSサービスの基本となっているインフラの部分**です。以下、主な責任範囲を列挙します。

AWSの施設（データセンター）は、非常に強固な物理的セキュリティによって守られていますが、万が一、*データセンターそのものが災害などによって停止という事態に陥ると、他のAWSのデータセンターで処理を継続できるような仕組み*になっています。これを**ディザスタリカバリ（disaster recovery - DR）**と言います。この施設の管理はAWSの最初の責任範囲です。

### 2：インフラストラクチャの管理

AWSのデータセンター内には、さまざまなインフラ設備があります。*電源・空調・ネットワーク・サーバー・ストレージなどは24時間監視下にあり、冗長化も含めて完全無停止を前提に設計され、稼働*しています。**このインフラストラクチャの管理は、AWSの2つめの責任範囲**です。

### 3：ハイパーバイザー（ホストOS）

**AWSはホストOSの稼働を保障しています**。これがAWSの3つ目の責任範囲です。そのために*厳格なアクセス管理が行われるよう、多要素認証に基づき、外部からのアクセスが非常に厳しい仕様*となっています。利用者側が作業を完了した後は、都度システムへの付与特権とアクセス権を削除するとともに、全てのアクセスのログが保管される仕組みです。

AWSの「責任共有モデル」では、**AWSが提供しているサービス以外の部分はユーザー側で責任**を負うことになります。

IaaSのようなホスティングサービスでは、**ゲストOSの管理や運用は利用者側の責任範囲**です。

*仮想サーバーであるAmazon EC2 インスタンスを利用する場合は、ゲストOSの更新・セキュリティパッチの適用・アプリケーションなどの管理・ファイアウォールの構成については利用者が責任を負う*形となります。

Amazon EC2 のサービスはIaaS（Infrastructure as a Service ）のため、**ネットワークの設定を含むセキュリティ構成や管理は利用者側の責任**で行う必要があります。

Amazon EC2では、利用者がEC2のインスタンス内に**インストールしたアプリケーションは、利用者側で管理したり、運用したりする責任**を負います。

**AWSサービスの中で扱うデータは、暗号化を含めてそのデータの管理は利用者責任**となります。また、データはオーナー（利用者）以外の者がその管理方法を決めることはできません。

前記のデータの暗号化と同様、AWSのサービスの利用者の**アカウント・アカウントに紐づくシステム・利用者側のデータに対するアクセス権限の管理や運用も、利用者が責任をもって行う**必要があります。

## AWSで利用者が行うべきセキュリティ対策とは

では、これらの問題を防ぐための対策としては、どのようなものがあるのでしょうか？ここでは、**AWSを使用する際の具体的なセキュリティ対策**をご紹介します。詳しくは、*[AWS アカウントのセキュリティを改善するための 10 個の項目](https://aws.amazon.com/jp/blogs/news/top-10-security-items-to-improve-in-your-aws-account/)*を参照してください。

### セキュリティグループをしっかり設定する

利用者に際して、まず初めに**セキュリティグループの設定**を行いましょう。*AWSが標準装備しているファイアウォールのことをセキュリティグループと称し、EC2インスタンスに対して適用*します。

セキュリティグループでは、EC2インスタンスへの*アクセス許可の範囲とトラフィックの制御*が行えます。特に開発環境ではセキュリティ被害に遭いやすい傾向があるため、*インバウンドルール（アクセス制限のルール）は厳しく設定*し、必要がない人には公開しないことです。

### 認証情報を定期的に確認し、無効化する

ログの管理も重要なセキュリティ対策の1つです。**定期的に認証情報を確認し、怪しい認証がないかどうか確認**しましょう。また、1度発行したIDで90日間以上利用されていないものは、確認をとって削除するようにします。休眠状態のIDが不正アクセスに利用されるケースがよくありますので、*不要なIDは極力使わない*ようにすべきです。

さらに、*ソフトウェアのバージョン管理もしっかり行いましょう*。セキュリティに脆弱性が発見されると、その脆弱性が攻撃の標的になりがちです。セキュリティパッチの有無を定期的にチェックし、ソフトウェアのバージョンを常に細心に保つことが重要です。

### マルウェア・ウィルス対策を施す

AWSは強固なセキュリティ対策が施されているとはいえ、インターネットに向けて公開された環境にあります。ソフトウエアの脆弱性を利用して、*マルウェアやウィルスなどの不正プログラムが侵入してくるリスクはゼロではありません*。また、自社のシステム内で利用しているメールシステムやWebシステムを経由してウィルス感染するリスクもあります。**マルアェア対策、コンピューターウィルス対策は利用者の責任と心得て、アンチウィルスソフトなどの適用を図る**必要があります。

### 多要素認証（MFA）を利用する

**MFAとは、簡単に言えば2段階認証のような仕組み**です。一般によく使われるログインIDとパスワード認証に加えて、さらにもう別の認証要素を組み合わたものです。*これを有効にしておくと、第三者による不正ログインを防ぐ*ことができます。

上記以外にもセキュリティレベルを高めるための方法は幾つかあり、AWSは10項目のセキュリティ対策を提唱しています。その他には**脆弱性診断サービスを利用して、自社のシステム特有の脆弱性がないか否かを検証することが求められます**。AWSには脆弱性診断のオプションサービスとして*[Amazon Inspector](https://aws.amazon.com/jp/inspector/)*がありますので、こちらを利用しても構いませんし、自社の協力会社などのサービスを利用しても構いません。いずれにせよ、*自社システムの脆弱性を定期的に診断することで、セキュリティの強化を図る*ことができます。

## AWSを正しく利用し、クラウド利用の効果を最大化しよう

いかがでしたか？AWSは鉄壁のセキュリティで守られているから、セキュリティ対策は不要と思われていた方にはがっかりされた方がいるかもしれません。しかし、実は*AWSはオンプレミスの場合と比べて、利用者側が行うべきセキュリティ対策はかなり限定されており、その負担も軽減されています*。セキュリティ基準の厳しい金融系のシステムでもAWSを利用しているほどです。

AWSは直ぐに利用できて大変便利なクラウドサービスですが、*利用する側がセキュリティ管理を疎かにすると、大きな事故につながる可能性を排除することはできません*。AWS側は、AWSの責任による事故などは補償をしますが、逆に利用者側の責による事故に対して一切補償はありません。さらに、事故がAWSや他の利用者に影響を及ぼした場合は、損害賠償請求の可能性を否定できません。

**AWSは「責任共有モデル」という両者の責任の分界点を明確にしています。つまり双方が責任の分担をしなければ、安全の確保やセキュリティの担保ができないということ**です。セキュリティ確保の責任は、この記事をお読みになったITエンジニアの皆さん1人1人にあるという自覚を持ち、AWSを正しく利用して、その*利用効果の最大化*を図っていきましょう。

AWSは強固なセキュリティ対策が施され、ユーザー側はセキュリティ対策が不要と考えがちですが、これは大きな誤りです。AWSは「責任共有モデル」により、ユーザーもクラウド内のセキュリティに一定の責任を負います。ここでは、AWSのウィルス対策について解説します。

AWSには「責任共有モデル」という考え方があり、セキュリティ対策の責任はそれぞれが負うことになっている

AWS利用で、利用者側の対策不備によってセキュリティ事故が発生した場合は利用者がその全ての責任を負う

セキュリティ対策で利用者側が行うべき10の項目があり、これらを正しく行ってAWS利用効果の最大化を図ろう

AWSの利用で、セキュリティやウィルス対策の責任は誰が負う？

AWSのストレージサービスである*Amazon S3*は*Amazon Simple Storage Service*の略で、オブジェクトストレージのサービスを指します。*オブジェクトストレージ*とはデータをオブジェクトとしてWebアクセスするもので、簡単にいえば**ファイルを保管する倉庫**の役割を持ちます。
参考：[AWS Amazon S3](https://aws.amazon.com/jp/s3)

### Amazon S3の特徴とメリットは？

*Amazon S3*は*スケーラビリティ*と*データの可用性*を高めたサービスで、最大*5TB*までのオブジェクトを**データ総量の制限なく利用できる**特徴を持ちます。

具体的な特徴としては*99.999999999%の耐久性*を実現できる設計がされており、安定したサービス提供がされています。さらに、S3 ストレージクラスの分析機能により階層化できるので*性能を維持*しながら*コストを低減*することが可能です。加えて、*セキュリティを維持*しながら*安価*にサービスが利用できる点もメリットとして挙げられます。

Amazon S3の利用料金は、*従量課金制*を取っています。以下の**6つのコスト要素**により料金が計算され、料金は安価に設定されています。

・*ストレージ料金*
　S3バケットという保存領域に保存するオブジェクトのサイズ・オブジェクトを保管した期間の長さ・ストレージクラスにより計算されます。
・*リクエストとデータ取り出しの料金*
　S3 バケットとオブジェクトに対して行われた、PUT・COPY・POST・LIST・GET・SELECT・ライフサイクル移行・データ取り出しに対して費用が発生します。
・*データ転送と転送高速化の料金*
　インターネットおよびS3バケットで発生した転送データが料金支払いの対象となります。
・*データ管理機能および分析機能の料金*
　ストレージ管理機能と分析 （Amazon S3 インベントリ・S3 ストレージクラス分析・S3 Storage Lens・S3 オブジェクトタグ付け）により費用が発生します。
・*レプリケーション*
　プライマリコピーとレプリケーション PUT リクエストのストレージに関して、データ転送料金が発生します。
・*S3 Object Lambda*
　AWS Lambda 関数の利用とアプリケーションに戻るデータ量に応じて費用が発生します。

Amazon S3では、*AWS無料枠*が設定されていますので有効活用しましょう。新規サインアップにより、S3標準ストレージクラスで 5GB の Amazon S3 ストレージ・20,000 GETリクエスト・2,000 PUT・COPY・POSTあるいは LISTリクエスト・データ送信15GB を毎月、1年間に渡りAWS無料枠として利用できます。*無料利用枠の使用量*は毎月計算され、*自動的に請求額に適用*されます。未使用分は持ち越しできないのでご注意ください。

*Amazon S3*では、ストレージサービスを構成するに当たりいくつかの用語が定義されています。ここでは、Amazon S3を有効活用する上で必要となる**代表的な用語**を説明していきます。

・*バケット*
　バケットとは、Amazon S3に格納するオブジェクトの入れ物（コンテナ）を指します。バケットにより格納先のネームスペースが確定し、アクセスコントロールや使用状況レポートの集計に活用されます。

・*オブジェクト*
　オブジェクトとはAmazon S3に格納される単位となります。オブジェクトはデータ自体を指すオブジェクトデータとデータ管理用メタデータから成ります。

・*キー*
　キーとはバケット内のオブジェクトを管理するための固有の識別子を指します。URLからバケットとキーを参照することでオブジェクトへアクセスすることが可能となります。
参考：[AWS Amazon S3 ユーザーガイド](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/s3-userguide.pdf)

### Amazon S3のストレージクラスとは？

Amazon S3では、*サービスレベル・条件に応じて*いくつかのクラスが設定されています。それを*ストレージクラス*と呼びます。各クラスは以下のように分類されます。

・*S3 標準*
　汎用的な一般使用を想定したストレージクラス
・*S3 Intelligent - Tiering*
　アクセスパターンを分析し階層化することで自動コスト削減するストレージクラス
・*S3 標準 - 低頻度アクセス*
　長期保管でアクセス頻度の低いデータ、アクセス速度は標準的なストレージクラス
・*S3 1 ゾーン - 低頻度アクセス*
　アクセス頻度の低いデータで再作成可能なデータ、アクセス速度は標準的なストレージクラス
・*S3 Glacier*
　長期バックアップとアーカイブ用、1分から 12 時間の取り出しを想定したストレージクラス
・*S3 Glacier Deep Archive*
　長期アーカイブ用、1年に 1-2 回の頻度で12 時間以内の復元を想定したストレージクラス
・*S3 Outposts*
　オンプレミス用ストレージクラス

各ストレージクラスは耐久性設計は同一であるものの、アクセスパフォーマンスや可用性に違いを持ちます。したがって、**用途に応じてストレージクラスを選択する**必要があります。

*Amazon S3*を使うには、*S3バケット*を**最初に作成**しておきます。その後バケットにオブジェクトを*アップロード*して追加したり、オブジェクトの*ダウンロード*やフォルダへの*コピー*が可能となります。詳細は以降でお話しします。

*Amazon S3*を利用するためには、**事前準備が必要**です。利用にあたり以下のステップに従い*構築を進めていきます*。

（1） *AWSアカウントのサインアップ*
AWSではサービス利用のためにAWSアカウントが必要です。Amazon S3においても同様にアカウントサインアップを行ってください。

（2） *S3バケットの作成*
Amazon S3では、データ保存庫としてS3バケットを最初に作成します。作成するためにはAWSマネジメントコンソールより、Amazon S3コンソールを起動し「バケットの作成」を選択します。ここでバケット名を指定し、バケットを作成します。

（3） *バケットの削除*
バケットが不要になった場合は、Amazon S3コンソールからバケットの削除が可能です。しかし、バケットの削除は元に戻りません。そのため同じバケット名を使いたい場合はバケットを空にするかオブジェクトを削除し、むやみにバケット自体の削除をしないよう注意しましょう。

### オブジェクトのアップロード方法は？

*Amazon S3*では、**ファイルタイプを問わず**バケットにオブジェクトを追加することで*アップロードが可能*です。

AWS SDKやREST APIおよびAWS CLIからのアップロードは、1回あたり最大*5GB*のオブジェクトをアップロード可能です。同様に、マルチパートアップロードAPIを利用することで、最大*5TB*のサイズのオブジェクトがアップロード可能となります。
Amazon S3コンソールを用いたアップロードでは、最大*160GB*のオブジェクトをアップロード可能です。

*Amazon S3コンソール*を用いたアップロードの場合は、AWSマネジメントコンソールよりAmazon S3コンソールを起動し「バケットリスト」からバケットを指定します。オブジェクトタブからアップロードを選択し、ファイル追加により**アップロード**を行います。

*AWS SDK*を使用する場合は、.NET・Java・JavaScript・PHP・Ruby等の開発言語でPUTオブジェクトリクエストを発行することでアップロードが可能です。*REST API*の場合は、PUTリクエストによりアップロードできます。*AWS CLI*の場合もPUTリクエストを用います。

### オブジェクトのダウンロード方法は？

*Amazon S3コンソール*を用いてオブジェクトのダウンロードを行う場合は、AWSマネジメントコンソールより、Amazon S3コンソールを起動し「バケットリスト」からバケットを指定します。オブジェクトタブからオブジェクトを選択し、オブジェクトアクションにより**ダウンロード**を行います。

*AWS SDK*を使用する場合は、.NET・Java・JavaScript・PHP・Ruby等の開発言語でGETオブジェクトリクエストを発行することでオブジェクトのダウンロードが可能です。*REST API*の場合は、GETリクエストによりダウンロードできます。*AWS CLI*の場合もGETリクエストを用います。

留意点としては、*オブジェクトダウンロード*については*データ転送料金が適応される*ことです。オブジェクトダウンロードの**範囲やサイズは最低限に留める**のが良いでしょう。

### オブジェクトのフォルダへのコピーの方法は？

オブジェクトのフォルダへのコピーするには、コピーオペレーションを実行します。コピーできるサイズは最大*5GB*です。

*Amazon S3コンソール*を用いたコピーの場合は、AWSマネジメントコンソールより、Amazon S3コンソールを起動し「バケットリスト」からバケットを指定します。必要に応じてフォルダ作成により新規にターゲットフォルダを作成します。次に、オブジェクトタブからオブジェクトを選択し、オブジェクトアクションにより**コピー**を行います。コピー先は例として以下のように指定可能です。
s3://バケット名/フォルダ名/.

*AWS SDK*を使用する場合は、.NET・Java・JavaScript・PHP・Ruby等の開発言語でCOPYオブジェクトリクエストを発行することでオブジェクトのコピーが可能です。*REST API*の場合はPUTリクエストによりコピーできます。*AWS CLI*の場合もPUTリクエストを用います。

### オブジェクトのフォルダへの移動の方法は？

*Amazon S3コンソール*を用いてオブジェクトを移動する場合は、AWSマネジメントコンソールより、Amazon S3コンソールを起動し「バケットリスト」からバケットを指定します。必要に応じてフォルダ作成により新規にターゲットフォルダを作成します。次に、オブジェクトタブからオブジェクトを選択し、オブジェクトアクションにより**移動**を行います。移動先はコピー操作時と同様の指定を行います。

*AWS SDK*を使用する場合は、.NET・Java・JavaScript・PHP・Ruby等の開発言語でCOPYオブジェクトリクエストとDELETEオブジェクトを併用することでオブジェクト移動が可能です。*REST API*の場合は、PUTリクエストにより同等の処理ができます。*AWS CLI*の場合は、MVリクエストを用います。

### オブジェクトを削除するには？

*Amazon S3コンソール*を用いてオブジェクトを削除する場合は、AWSマネジメントコンソールより、Amazon S3コンソールを起動し「バケットリスト」からバケットを指定します。次に、オブジェクトタブからオブジェクトを選択し、「最新バージョン」や指定バージョンのオブジェクトを選択し「**ゴミ箱**」アイコンをクリックします。同様に、*バケットを空にする*ことも可能です。

*AWS SDK*を使用する場合は、.NET・Java・JavaScript・PHP・Ruby等の開発言語でDELETEオブジェクトリクエストを発行することでオブジェクト削除が可能です。*REST API*の場合は、RESTリクエストにより削除できます。*AWS CLI*の場合もDELETEリクエストを用います。

## Amazon S3を用いてデータ保存の最適化を図りましょう

AWSのAmazon S3は、格安なストレージサービスとして*ウェブサイトやモバイルアプリケーション*から汎用的に利用することができます。また、*データレイク・IoT デバイスやビッグデータ分析*の大容量ストレージとしての活用や、*企業向けストレージシステム*としても利用者が多いです。他にも*バックアップおよび復元、アーカイブ*等多岐に渡る利用用途が挙げられます。

Amazon S3は多岐に利用することが可能であるため、AWSのサービスを有効活用するためにもAmazon S3による*データ保存や格納先*として**最適化を図る**ことをお勧めします。

AWSのストレージサービスとなるAmazon S3は、あらゆるタイプのデータを安価に格納することができるため利用者が増えています。ここではAmazon S3の特徴に加えて、実際のアップロードやダウンロード等の使い方について説明していきます。

Amazon S3は、AWSのオブジェクトストレージのサービスを指します

Amazon S3の使い方はAmazon S3コンソールの他、AWS SDKやREST APIおよびAWS CLIを用います

Amazon S3は、保存するデータのファイルタイプは問わないため多用途に活用可能です

Amazon S3の使い方は？AWSのストレージサービスを解説！

AWSの特徴は、*サービスの豊富さ*と*提供範囲の広さ*です。自社サービス提供エリアにおいて*均一なサービス*を提供するために、地域を**物理的なロケーション**に分割してサービス提供しています。その物理的なロケーション分割単位を「*リージョン*」と言います。

AWSは継続的にサービス提供地域を拡大し、その地域をカバーするリージョンを開設しています。
参考：[AWS グローバルインフラストラクチャ](https://aws.amazon.com/jp/about-aws/global-infrastructure/regions_az/)

### AWSのアベイラビリティゾーンとは？

AWSの*アベイラビリティゾーン（AZ）*とは、1つのリージョンを*冗長性・信頼性・可用性*を確保した、*1つ以上のデータセンター*で構成する単位を指します。アベイラビリティゾーンは、*複数の独立した場所*に設置されており、冗長的な電力源・ネットワーク、そして接続機能により*相互に接続され運用されています*。

*アベイラビリティゾーン*により、自然災害やデータセンター障害発生時においても**ビジネス影響を最小にすること**を目的としています。

### AWSのサービスエンドポイントとは？

AWSの*サービスエンドポイント*とは、AWSのサービスにプログラム接続するための**接続情報**を指します。具体的には、以下のリージョンエンドポイントに対して接続リクエストを発行します。

「*protocol://service-code.region-code.amazonaws.com*」

protocolはhttps等で、service-codeとは利用サービスの名称です。region-codeとは、指定するリージョンコードを指します。この*AWS サービスエンドポイント*を指定することで、リージョンとその提供サービスが利用可能となります。
参考：[AWS サービスエンドポイント](https://docs.aws.amazon.com/ja_jp/general/latest/gr/rande.html)

サービス・ツール・技術の記事（65ページ目）