*AWSアカウント*はAWSのサービスを利用する際に、**AWS側にアカウント登録をすることで払い出してもらうアカウント**です。アカウントと聞くと、Microsoftの「Active Directory」のように人に紐づくアカウントをイメージしますが、AWSアカウントは賃貸住宅を借りる際の、*借家とマスターキー*のようなものです。マスターキーとなるAWSアカウントは複数持つことも可能です。この*AWSアカウントを取得することで、AWSが提供するさまざまなサービスを利用*することができます。

### AWSアカウントを作成すると何ができる？

*AWSアカウント自体は、無料で作成*できます。AWSのサービスであるAmazon EC2やAmazon S3など、様々な**主要サービスには一定の条件で無料利用枠が設けられており、12ヶ月間それらのサービスを無料で利用することが可能**です。

例えば仮想サーバーを必要とする際には、*Amazon EC2を月間750時間×12ヶ月間の無料利用*が可能です。他、ストレージサービスの*Amazon S3は5GBまでのストレージを12ヶ月*、データベースサービスの*Amazon RDSも12ヶ月間無料で利用*できます。

つまり、*お試し利用からシステム構築まで12ヶ月間はすべて無料で利用*が可能ということです。 

**AWSアカウントの作成には、必要なものがいくつかあります。アカウント登録で戸惑うことがないよう、あらかじめ準備**しておきましょう。

*1.AWSアカウント名*
▪Eメールアドレス…AWSアカウントのルートユーザーのIDとなります。

*2.AWSアカウント名*
 アカウントID数字12桁が払い出されますが、管理しやすいように名前の割り当てができます。

 （ルートユーザー権限があれば後から変更ができます）

*3.連絡先情報*
▪氏名
▪住所
▪電話番号 等

*4.支払情報* （※アカウント作成だけで請求は発生しません）
▪クレジット/デビットカード番号情報
▪請求先住所情報
▪電話もしくはSMS利用が可能な端末（本人確認用途で利用します）

*5.サポートプランの検討*
アカウントの用途や受けたいサポート内容に応じて、必要なプランを選択します。初めての利用で個人であれば、*「ベーシックプラン」を選択*しておけばよいでしょう。（詳細は以下参照）

*▪ベーシックプラン*
▪開発者プラン
▪ビジネスプラン
▪エンタープライズプラン

※プランの詳細は[AWS サポートのプラン比較](https://aws.amazon.com/jp/premiumsupport/plans/)を参照

## AWSアカウントを登録してみよう

AWSアカウント登録の準備が整ったら、実際に登録してみましょう。**数分で登録でき、個人の方でも無料で自身のクラウド環境を手に入れる**ことができます。

AWSアカウントの登録は以下のリンクから行えますので、ぜひ試してみてください。

*Step1: AWS アカウントの作成*
[AWSにサインアップ](https://portal.aws.amazon.com/billing/signup#/start)からAWSアカウントの新規登録を行います。

最初に、Eメールアドレス・パスワード・アカウント名を入力します。**パスワードは8文字以上で、大文字・小文字・数字・記号から最低3種類を選択**します。*AWSアカウント名は自分の名前で構いません*。（例 : Ab12345+）

*Step2: 連絡先情報を入力*
アカウントの種類として「プロフェッショナル」と「パーソナル」があるので、企業や教育機関などはプロフェッショナル、*個人はパーソナルを選択*します。連絡先の項目を全て入力してください。

*Step3: 支払い情報を入力*
クレジットカード情報や請求先情報（連絡先と異なる場合）を入力します。料金の請求はありません。

*Step4: SMS または電話によるアカウント認証*
本人確認のための電話番号を設定します。SMSによるテキストメッセージか、音声通話のいずれかを選択し、リージョンコードが日本（+81）になっていることを確認し、電話番号を入力します。続いて、セキュリティチェック欄に表示されている画像の文字を入力します。次に「SMSを送信する」をクリックすると、**登録した電話番号にSMSで認証コードが送られます。この認証コードを入力すると本人確認が終了**します。

*Step5: サポートプランの選択*
▪ベーシックプラン/開発者プラン/ビジネスプランの選択を求める画面が表示されますので、プランを選択します。

AWSアカウントを作成した後、デフォルトで*ルートアカウントと呼ばれるユーザーが作成されます*。

ルートアカウントは非常に強い権限をもつアカウントで、マネジメントコンソールの操作、API経由での操作などが全て行えてます。**万が一ルートアカウントの情報が漏洩すると、AWS上に構築したシステム環境を完全に乗っ取られてしまい、また個人情報漏洩にもつながり大変危険ですので、きちんと保護しましょう**。

### AWS アカウントのセキュリティ改善10項目

AWSは世界最大のクラウドサービスですが、**利用する側のセキュリティ対策が甘かったり、セキュリティ意識が低かったりするとセキュリティ事故が起こります**。実際にAWSアカウントが乗っ取りに遭い、暗号通貨のマイニングで利用された事件などもあります。

そうしたセキュリティ事故や事件を防ぐために、AWS の情報セキュリティ責任者（CISO）のステファン・シュミット氏が2019年に提唱した「クラウド・セキュリティのための上位10項目」を参考に、*利用者自らがセキュリティ改善に努める必要*があります。以下、10項目を箇条書きでご紹介します。

*①アカウント情報を正しく保つ*
*②多要素認証（MFA）を利用する*
*③シークレットをハードコードしない*
*④セキュリティグループに制限をかける*
*⑤明確なデータポリシーを持つ*
*⑥CloudTrail ログの集約化*
*⑦IAM ロールを確認する*
*⑧Finding/結果に対してアクションをとる*（GuardDutyのみではありません）
*⑨キーをローテーションする*
*⑩開発サイクルに参加する*

詳細は以下、AWSのサイトをご参照ください。

[AWS アカウントのセキュリティを改善するための 10 個の項目](https://aws.amazon.com/jp/blogs/news/top-10-security-items-to-improve-in-your-aws-account/)

**IAM（Identity and Access Management）はAWSのサービスの1つで、「認証」や「認可」の設定が行えます**。*「認証」や「認可」を正しく設定*することによって、AWS利用者やAWSのサービスの*アクセス権限や範囲をコントロール*できます。イメージとしては、MicrosoftのActiveDirectryでユーザーごとに払い出される*ADアカウントと似ています*。IAMは、日本では「アイアム」と発音されることが多いようですが、英語では「アイ・エー・エム」とアルファベットをそのまま発音しています。

IAMの理解の前に、**IAMが行っている「認証」と「認可」の意味ついて確認**しましょう。認証と認可は、似て非なる言葉です。これを分かりやすく述べると以下の違いになります。

　*▪認証→ ID・パスワードにより利用者が本人であるかどうかを確認すること*

　*▪認可→ 認証された利用者にリソースへのアクセスや操作の権限を与えること*

続いて、IAMの機能について説明します。IAMには主に以下の機能があります。

IAMユーザーは、Microsoftの「Active Directoryアカウント」と同様に**利用者個人に紐づくアカウント**です。

それぞれのIAM Userに対しては以下のバスワードやアクセスキーを発行することができます。発行できるのは、いずれも英数字・記号のテキスト情報のみです。

*1.マネジメントコンソールにログインする際に必要となるパスワード*

*2.アクセスキー（Access Key）およびシークレットアクセスキー（Secret Access Key）*

IAMポリシーでは**「AWS上 のどのリソースに対し、どのような操作を許可するか」**という*「操作の権限」*を定めます。

ポリシーは*「IAMユーザー」「IAMグループ」、「IAMロール」にアタッチ*（割り当て）して使い、*アタッチされたそれぞれに権限*が与えられます。

例えば、AWS S3（ストレージサービス）に対して全ての操作ができる権限ポリシーを作成し、IAMユーザーのAさんにアタッチ（割り当て）すると、AさんはAWS S3に対してすべての操作が可能となります。

IAMポリシーは大きく分けて以下**3種類のポリシー**があります。

*▪AWS管理ポリシー*
利用者のアクセス許可割り当てを簡略化するために、AWS側が提供する事前定義された管理ポリシーです。

*▪カスタマー管理ポリシー*
利用者が設定するポリシーのことです。IPアドレス制御などが可能で、AWS管理ポリシーよりも細かい制御が行えます。

*▪インラインポリシー*
インラインポリシーとは、AWS管理ポリシーやカスタマー管理ポリシーよりも細かく、1つのIAMユーザーやIAMロールなどにアタッチする場合に利用します。

AWSの権限がIAMユーザーやIAMグループ、すなわち*「人」に対して割り当て（アタッチ）*されるのに対して、**IAMロールは主にEC2などの「インスタンス」に対して権限を割り当てる仕組み**です。

「人」が行う操作に対する権限はIAMユーザーやグループにポリシーを割り当て（アタッチ）し、*「インスタンス」が行う操作の権限はロールに対してポリシーを割り当て（アタッチ）する*のです。

AWSを利用する上では、セキュリティを保護する上で権限管理が重要であることは理解できたと思います。最後に、**AWS利用において守ってほしいこと**をまとめました。

### ルートユーザーを使うリスク

AWSアカウントは、デフォルトでルートユーザー（ルートアカウント）の権限が付与されます。

*ルートユーザー*は、すべてのリソースにアクセスできるばかりか、アカウント停止などの重要操作を行えるため、普段は*使用を制限*すべきです。**ルートユーザーを使用する代わりに、一般ユーザーには必要なアクセス権限を設定したIAMユーザーを利用してもらう**ようにしましょう。

システムユーザー全員に対し、*個々に付与する権限レベルと認証情報*を設定すると*IAM ユーザー*を作成ができます。それぞれのIAMユーザーが、*いつ・どんな操作をしたのか、ログを取得*することができますので、**必ずシステムユーザーごとにIAMユーザーを1つ付与する**ことが必要です。

そのためには、システムユーザーごとの権限を明確に定義し、必要以上の権限を付与しないよう気を付ける必要があります。

AWSは直ぐに利用できて大変便利ですが、**利用する側が管理を疎かにすると大きなリスクと隣り合わせになる**という問題をはらんでいます。AWS側は、AWSの責任による事故などは補償をしますが、逆に利用者側の責による事故に対して一切補償はしません。*すべて自己責任*です。

さらに、利用者側の不備、不注意でAWSや他の利用者に損害を与えた場合は、利用者側が損害賠償責任を負います。このような*事態を招かないためにも、最低限以下のことはルールと考え、遵守*しましょう。

*1.ルートユーザー（AWSアカウント）は普段は使わない*

*2.利用する人ごとにIAMユーザーを払い出し、必ず払い出されたIAMユーザーを用いてAWSにアクセスする*

ここまで、AWSアカウントについて基本的なことを解説してきました。**セキュリティ確保の責任はITエンジニアである皆さん1人1人にあるという自覚を持って、AWSを正しく利用しましょう**。

AWSアカウントはAWSの利用を始める上で重要なIDです。AWSアカウントが乗っ取られると、重要な情報が盗まれるリスクもあり、このセキュリティ管理には万全の対策が必要です。ここではITエンジニアとして知っておくべきAWSアカウントの設定や管理について解説します。

AWSアカウントの意味や目的、正しい管理方法

AWSを正しく利用する上で不可欠のIAMについて、AWSアカウントの違いや管理の重要性

AWSの利用に当たっては利用者自身が正しいセキュリティ管理を徹底しなければならない

ITエンジニアが知っておくべきAWSアカウントのセキュリティ管理

AWS（Amazon Web Service）は、”GAFA”の1つであるAmazonが提供するクラウドサービスのことです。AWSは、*世界のIaaS市場で45%のシェア*を占め、2位のAzure(Microsoft)18%を大きく引き離しています。日本でも、**日本政府が行政サービスのDX化を狙いにAWSを政府共通プラットフォームとして採用する**など、注目を集めています。

本記事ではAWSの概要や活用策に触れ、エンジニアの皆さんの今後の成長に役立てて頂きたいと考えています。

AWSとはAmazonが提供するクラウドコンピューティングサービスの総称です。

クラウドコンピューティングとは、インターネットを利用してサーバーや各種ストレージ、データベースやソフトウェアなどのインフラサービスを利用することです。**クラウドコンピューティング環境を利用する場合は、1台のPCとインターネット接続環境があれば、さまざまなインフラを必要な分だけ利用できる**のです。AWSはこのクラウドコンピューティングサービスをあらゆる企業や行政組織、個人に提供することで成り立っています。

企業内システムの多くは、オンプレミスという形態で、企業内に独自のコンピューターやネットワークを設けてシステムを運用してきました。オンプレミスは初期投資のみならず、所有コストや運用コスト、セキュリティリスクなど大きな負担を抱えていました。

しかし、**AWSを採用すると、初期費用も減価償却費も掛からず、システムを稼働させることができます。システム監視、セキュリティ対策、災害対策もすべてAWSが行ってくれます。**企業規模の拡大によるハードの増強などもAWS側で柔軟に対応してくれるのです。このように、システムの自社所有に伴う問題をすべてAWSが吸収してくれることが、各社がこぞってAWSを採用する理由なのです。

AWSの対抗サービスとしてMicrosoft社が提供するクラウドサービスAzureがあります。両者はほぼ同じようなサービスを提供しており、企業がクラウド移行を図る際には常に比較検討されます。

その中で**Azureの決め手はOffice365との連携**でしょう。Microsoft製品を多く使う企業では、アカウント管理も含めてシームレスにクラウド環境への移行ができる利点があります。

クラウドエンジニアを目指す方必見！Azureを分かりやすく紹介！

AWSの概要についてより深く理解するため、ここではAWSのメリットとデメリットについて解説します。**クラウド移行を図る際は、必ず自社におけるメリットとデメリットをよく検討した上で採用**をする必要があります。

*1.初期コストを抑えられる*
自前でサーバー構築を行うオンプレミス環境では、必ず初期コストや時間が掛かりますが、**クラウドサービスでは基本的に大きな初期コストは必要なく、単期間でスタートができます。**

ただし、クラウドサービスの基本はIaaS(Infrastructure as a Service)です。提供されるのは仮想サーバーやネットワークなどのインフラであり、*OSやミドルウェアなどは別途ライセンス料が発生*します。家に例えると、建物は提供されますが内装や家具・備品などは別料金というわけです。

*2.リスクヘッジができる*
オンプレミスの場合は、サーバーダウンによる営業損失、ハッキングなどによる情報漏洩はすべて自社責任です。そのため、併せて災害対策やセキュリティ対策を施す必要がありますが、AWSに移行することで、これらの責任の多くがAWSに移転します。**AWS責任で起きた問題に対してはAWSが補償してくれる**ようになるので、リスクヘッジが可能となります。

*3スケーラビリティが担保される*
オンプレミスでは、事業拡大に伴うデータ量の増加への対応を自前で行わなければなりません。それとともに、**サーバーの増強、リプレイスといった対応を迫られますが、AWSでは企業側はその対応の必要がなくなります。**もちろん、AWSは従量課金制を基本としていますので、データ量の増加などに伴いランニングコストは増加しますが、サーバーがキャパシティオーバーでパンクするといった心配はありません。

*1.ランニングコストは決して安くはない*
**AWSは初期コストの安さがメリットですが、反面ランニングコストは安くはありません。**家庭用プリンターは2万円程度で買えるのに、インク代が数千円も掛かるのと似ています。AWSは自前で莫大な投資を行い、ランニングで利益を上げるビジネスモデルになっているのです。

しかし、コスト比較をする際に顧客側が見逃しているポイントが幾つかあります。オンプレミスのサーバーやハードの償却費用と比較して、AWSのランニング費用は明らかに高くなります。

*しかし、オンプレミスの場合の家賃、水光熱費、人件費、セキュリティ対策費用、災害対策費用などを含めるとAWSのランニング費用が低いケースが多い*のです。そこを見誤ると、「AWSは高い」というAWS批判に繋がります。

*2.コンテンツはあくまでも自前*
AWSを利用すると、システム部門を大きく縮小できると考える経営者がいますが、それは大きな誤解です。**AWSが提供するのはあくまでもインフラであり、情報システムは企業側が用意しなければなりません。**そのコンテンツについては利用者側である企業が全責任を負わなくてはならないのです。

オンプレミスからAWS移行を果たした後、**運用やインフラ管理から解放された情報システム部門は企画や情報活用面で機能を果たしていくべき**でしょう。

AWS移行とは、オンプレミスで運用している自社システムの稼働をAWSに移すことを意味します。この**AWS移行ではいくつかの確認ポイントがあり、これを行わないとAWSのメリットが半減するばかりか、場合によっては移行に失敗することがあります**ので、必ず確認を行うべきです。以下そのポイントについてまとめてみました。

### Ⅰ.移行可能な要素の洗い出し

*1.ハードウェア*
**オンプレミスで利用中のハード(サーバーやネットワーク機器)はAWSに移行できません。**AWS移行対象外のシステムでの利用、売却等の対応を検討しておく必要があります。

*2.ソフトウェア*
**OSやミドルウェアなどのライセンスがAWS側で継続利用が可能か否か**を検討します。これらはつい忘れがちなので、すべて棚卸をして行き先を決めておく必要があります。

### Ⅱ.移行による影響範囲の検討

AWS移行に際しては、システムごとの移行シミュレーションを行いますが、中には移行するメリットがないシステムもいくつか出てきます。

移行するシステム、移行しないシステムの切り分けが必要です。移行しないシステムがある場合、システム間連携を考慮しておく必要があります。ここを見逃すと、オンプレミスで残したシステムがシステム間連携ができないために正常稼働しないなどの問題を生じますので、**移行計画は綿密に行なわなければなりません。**

AWS移行に際しては、新システムの開発と同様に、機能要件に加えて非機能要件の確認が必要です。例えば、基幹システムがオンプレミスからクラウドに移行することで、従業員が利用する回線がイントラネットからインターネット回線にシフトしていきます。

そうすると、従来のインターネット回線ではキャバシティオーバーをしてしまい、レスポンス低下による業務への影響などが生じます。**可用性、運用変更、キャパシティなどの面から事前の十分な検討と対策が必要です。**

### Ⅳ.コストシミュレーション

AWS移行に際しては、以上述べてきた事項について検討し、シミュレーションをしていくことになります。そのために場合によっては*外部コンサルタントやエンジニア*の確保が必要になることもあります。AWS側からの見積もり資料だけで予算措置をすると、後から想定外のコストが発生してしまい、AWS移行がとん挫する可能性もあります。

AWS側にもそうした知見を持った営業やエンジニアが多くいますので、力を借りながら**緻密な移行プランを立てる**ことが大事です。

インフラエンジニアはキツイのか？その仕事内容やスキル、将来性を解説！

ここまでAWSの特徴やAWS移行のポイントなどについて解説してきました。実はAWSには「AWS認定資格」という制度が用意されており、この資格取得がさまざまな面でメリットにつながると考えられます。ここからは「AWS認定資格」について解説します。

システムエンジニアがキャリアアップするのにおすすめの資格を解説！

**AWS認定資格は、クラウドサービスに関する知見を問う、AWS主催の資格試験**です。

AWS主催の資格認定だけに、大変*信頼度が高く*、AWS認定資格を有するだけで、*クライアントからの信頼度*が増すばかりか、就職(転職)の際にも資格を有することが大きなアドバンテージになります。

[AWS認定](https://aws.amazon.com/jp/certification/)

エンジニアとしてニーズが高いAWS資格、その理想的な勉強方法

AWS認定資格は、エンジニアにとってはクラウドやAWSに関する知見を有する証明となり、**AWS案件に関われる機会が増えます。また雇用側にとっても、AWS案件を進めやすくなり、自社の強みになります。**

ただし、AWS認定資格は*有効期限が2年*と短く、それが逆にAWSへの信用につながっています。ITの技術は日進月歩で変化していますので、最新の技術を学びたい人にとってもAWS認定資格はおすすめできます。

AWSのソリューションアーキテクトとは？取得方法やメリットを解説

冒頭で述べた通り、官製DXをAWSが受注したように、**DXの潮流はクラウドコンピューティングの利用が大前提**になっています。これからのエンジニアはDXと関わる機会が圧倒的に増えてくるでしょう。逆に言えば、**クラウドに詳しいことがDX時代に対応するエンジニアのスキル要件**とも言えます。

この記事をお読みいただいたエンジニアの皆さんが、アジャイル開発手法に加えクラウドコンピューティング技術も身に付けて、DX時代に存分にスキルを活かし活躍されることを祈っています。

DXとは？その意味と日本の現状、DX推進の障壁となる要因を分かりやすく解説！

DXの取組事例に学ぶDX成功のポイントとITエンジニアへの期待

DX時代を迎えて、クラウドコンピューテイングに関する知見が必須となっています。世界最大のクラウドコンピューティングサービスであるAWSの概要、メリット・デメリット、AWS移行に加え、DX時代に活躍できるエンジニアにおすすめのAWS認定資格についても紹介します。

1.AWSは世界シェアNo.1のクラウドサービスだが、検討や準備はしっかり行うことが大切

2.オンプレミスからAWSへの移行する際はポイントをしっかり押さえておこう

3.DXエンジニアとして活躍するためにAWS認定資格を取得しよう

DX時代を勝ち抜くエンジニアを目指してAWS移行に詳しくなろう!

AWSの記事（19ページ目）