More than 5 years have passed since last update.

新人プログラマの為のAWS入門～導入編～

Last updated at 2017-12-21Posted at 2017-12-17

1 / 44

はじめに

これはTech Fun Advent Calendar 2017の一記事です。

社内向けに書いたAWS入門資料を多少リライトしたものになります。
元は勉強会用に作成したものなので、記事としては説明不足＆スライドの見た目調節により読みにくくなっているかもしれません。
(Qiitaスライドを使用している理由は単に一度使ってみたかったから；)

また筆者はAWS二年生くらいの若輩です。
筆者自身まだまだAWSおよびその他諸々も分からないことだらけですので、間違いや改善点の指摘は大歓迎です。

ターゲット層

WEBサービスのプログラミングはできるけどインフラはあまり馴染みがない
AWS(クラウド)触ってみたいけど、何から手を着けていいか分からない
最近流行りのサーバレスとかちょっと触ってみたい

などといったエンジニアが実際にAWSのサービスを自分で試せるようになるまでの障害を極力取り除きたいというのが主な趣旨です。

今回は導入編という事で、そもそもクラウドを使う意義や利点についてと、AWSを利用する上で必須となりそうなアカウント作成～ユーザ・権限・コスト管理などの話をまとめます。

導入 #1 クラウドサービス(AWS)の特徴

前知識：クラウドとオンプレ

そもそもWEBシステムに必要なサーバ全てをオンプレミスで自社管理するのは相当大変。

※『オンプレミス』とは・・・

サーバやネットワークなどの情報システムに必要な物理環境(とそれを支えるソフトウェア)などを全て自前で用意すること
クラウドサービス台頭前からの一般的なサーバインフラ調達形態を指す
しばしば『クラウド』との対比用語として用いられる

一般的な3層構成に必要なサーバ

Webサーバ
アプリケーションサーバ
バックエンド(DB)サーバ

・・・これらが開発用・検証用・本番用など環境ごとに1セットずつ必要。冗長化する場合は更に各サーバ毎に2～数倍+α分増える。(※開発用サーバなどは併用することもあり)

オンプレでのサーバ調達

調達業者リストアップ
サービス要件からの必要機能洗い出し・スペックなどの見積もり ※1
機材発注（届くまで数週間～数か月待ち？※2）
配線・ラッキング(機材設置作業)、サーバの基本設定など
ソフトウェアのインストール、アプリのセットアップなど
性能、不具合検証（<=ここでようやく実環境でのサービス稼働を確認できる）
場合によっては交換・再発注など

⇒クラウドと比べて圧倒的に時間が掛かる！！

※1: 要求機能の見積もりなどをまとめて業者に依頼、相見積を取ることなども多い
※2: 実際は先に検証用端末などが貸出されることも

クラウド化で解決される問題

ググると色々出てくる
代表的なものを挙げると・・・

サーバ調達時間の短縮
機材設置や環境整備が不要
冗長化・スケーリングが容易（物理デバイスの抽象化）
インフラ構成のコード化(IaC)、再利用性向上

・・・などなど

※クラウド移行でよく話題に上がるコストとセキュリティの件は、個人的には今のところケースバイケースとしか言えないと感じるのでここでは敢えて触れない

なによりも、

フルマネージド／サーバレス系サービスにより、低レイヤーのサーバ管理作業から解き放たれる

ex)

S3(クラウドストレージ) => 可用性や耐久性などをAWS側で保証
RDS(データベース) => DBインスタンス・ミドルウェアの管理やレプリケーションなどの設定をほぼお任せ
AWS Lambda, Batch => サーバ管理なしでコードを実行できる

AWSの提供サービス

・・・は、ちょっと数が多すぎ＆頻繁に更新されるので、

各自気になったものや他の一覧記事などを都度ググる方針で。

(ザッと概要を俯瞰するならこちらの記事がおススメ)

公式の説明を読んでも何が出来るサービスか分かりづらいものも多いので、実際の企業の導入事例などを調べて具体的な活用法から把握するのも良いかも。
＞https://aws.amazon.com/jp/solutions/case-studies-jp/

[補足] AWSサービスの提供地域

AWSには「リージョン」と「アベイラビリティーゾーン」という概念がある。

FYI: AWSグローバルインフラストラクチャ

リージョン(Region)

サービスの提供地域ごとの区分け
いくつかのアベイラビリティーゾーンにより構成される
リージョンによって提供サービスに差異がある
- 新サービスは大抵「us-east-1」(バージニア北部)リージョンでリリースされ、徐々に他のリージョンに展開される
リージョンを跨る通信・サービス連携は制限が多い
日本は今のところ「ap-northeast-1」(東京)リージョンのみ
- 2018年に大阪(ローカル)リージョン追加予定
コンソール画面はリージョン毎に別々になっている(S3など一部サービス除く)
- コンソール右上のプルダウンから切り替え

アベイラビリティーゾーン(AZ)

現実にAWSのインフラ(ハードウェア)群が置かれているデータセンター(のまとまり)単位？
各AZは地理的に独立している
- 分散配置させて耐障害性、可用性を高めるのが一般的(Multi-AZ)
AZを跨る通信・サービス連携は比較的容易
- が、ネットワーク構成などでは気を付けないとハマるケースも

リージョンとAZの関係

(引用：リージョンとアベイラビリティーゾーンに関する概念)

導入 #2 アカウント作成／ユーザ・権限設定

アカウント作成

メールアドレスとクレジットカードを用意し、こちらの手順に従って登録

⇒アカウントID(とルートユーザ)が発行される。

※アカウントID＝AWSの契約単位ごとに割り振られる12桁の数字ID。
　注：後述するIAMユーザのIDとは別もの。ログイン時などに混同しないように。

管理コンソール画面にログイン

こちらからログインする。

AWSコンソールへのログインは、

アカウントID(ルートユーザ)でのログイン
IAMユーザ(後述)でのログイン

の2種類ある。

アカウント作成直後はルートユーザしか存在しないので、メールアドレスとパスワードを入力してルートユーザとしてログイン。

　↓

※常時でのAWSログインは、適切な権限設定を施したIAMユーザでログインし、ルートアカウントは極力使用しないようにすべき
※新規にAWSアカウントを作成したら、まず最初にIAMコンソールのセキュリティステータスの項目を全て対応するのが無難

IAMユーザ作成後はアカウントIDを入力し※、次ページでユーザ名／パスワードを入力する。

※または [https://{アカウントID}.signin.aws.amazon.com/console] にアクセスすることで、IAMユーザ用のログイン画面に直接飛べる。

IAMロール・ユーザ作成

AWS IAM とは・・・

AWS上のサービスやリソースへのアクセス制御の仕組み
ユーザ／グループ／ロール単位でのアクセス制御・認証認可を設定できる
プログラムからAWSサービスを使用する際も必要
- IAMにより権限を設定したロール or アカウントを発行して利用する
権限は一まとまりの設定ごとにポリシーとして管理
- 各ロールやユーザに必要十分なポリシーをアタッチして使用する
- 下記のようなJSON形式で、対象操作・リソース毎に細かく設定できる

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:*:*"
        }
    ]
}

⇒ポリシージェネレータで作成できる

・・・ポリシーの書き方の詳細は気が向いたらまた別記事で。

IAMグループの作成

管理用ユーザ(Admin)グループを作成する

IAM＞サイドメニュー「グループ」＞「新しいグループの作成」

作成するグループ名を入力

グループに適用するポリシー(権限)を選択

内容確認＞「グループの作成」

IAMユーザの作成

管理用ユーザを作成する

IAM＞サイドメニュー「ユーザー」＞「ユーザーを追加」

作成するユーザー情報を入力

ユーザー名を入力
- 複数ユーザ同時に作成することも出来る
「プログラムによるアクセス」
- AWS CLI(コマンド)や開発ツールからも使用する場合にチェック
- 「アクセスキーID」と「シークレットキー」については後述
「AWSマネジメントコンソールへのアクセス」
- WEBコンソールログインに使用するユーザの場合にチェック
- 管理用ユーザなら必須、プログラム専用の場合は不要
パスワード
- パスワードポリシーに違反する場合は登録できない

権限(グループ)設定

「ユーザーをグループに追加」
- 先ほど追加したグループを選択

内容確認

結果画面

生成されたユーザ情報が表形式で一覧表示される
「Eメールの送信」リンクから個々のアカウント毎に任意のメールアドレスに通知出来る
「.csv のダウンロード」からアカウント情報を"credentials.csv"というCSVファイルとしてDL出来る
- ファイル内容サンプル＞

credentials.csv

User name,Password,Access key ID,Secret access key,Console login link
user1,,AKIAJXXXXXXXXXXXXXXX,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX,https://123456789012.signin.aws.amazon.com/console
user2,,AKIAJYYYYYYYYYYYYYYY,YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY,https://123456789012.signin.aws.amazon.com/console

※値は実際のものと変更済み

AWSアクセスキーIDとシークレットアクセスキーについて

プログラムからAWSのAPIにアクセスする際に使用する認証情報
- AWS CLIやAWS SDKなどで使用
IDと紐づくユーザ／ロールと同様の権限が与えられる
コード上で使用する際、下記のようにいくつかパターンがある
- コマンドの引数オプションなどで直接指定する
- 設定ファイルに記述したものを読み込む
- システムの環境変数に設定しておく
参考：Java用SDKでの認証情報の使用
※これらの情報が書かれた設定ファイルやスクリプトなどは基本的にリポジトリには上げないこと！！
- 流出すると大変なことになる

IAMロール

AWSの権限(ポリシー)設定の集合体。
まとまった権限をユーザやグループに付与できる。

また自分のAWSアカウントユーザ以外に特定の権限を発行することも。

他のAWSアカウントのユーザ／サービスからのアクセス
SAMLなどを用いたOpenIDによる外部サービスからのアクセス

補足：AssumeRole・・・

AWSアカウントの恒久的なユーザ(IAMユーザ)以外に、AWSリソースへの一時的なアクセス権限を与える機能。
Security Token Serivce (STS) により指定したIAMロールと同様の権限が発行される。

使用例：
- EC2やLambdaなどの Instance Profile
- Cognito Identity Pool のユーザ等に適用するロール
- ...etc
実際に発行されるのは自動生成された有効期限付きのアクセスキーIDとシークレットキー
- 万一漏洩しても期限を過ぎれば無効になるので安全
- ロールの権限を変更すれば発行されたIDにも反映される

試しにEC2管理用のロールを作成してみる。

IAM＞サイドメニュー「ロール」＞「ロールの作成」