はじめに
これは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: 実際は先に検証用端末などが貸出されることも
クラウド化で解決される問題
ググると色々出てくる
代表的なものを挙げると・・・
・・・などなど
※クラウド移行でよく話題に上がるコストとセキュリティの件は、個人的には今のところケースバイケースとしか言えないと感じるのでここでは敢えて触れない
なによりも、
フルマネージド/サーバレス系サービスにより、低レイヤーのサーバ管理作業から解き放たれる
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」(東京)リージョンのみ
- コンソール画面はリージョン毎に別々になっている(S3など一部サービス除く)
- コンソール右上のプルダウンから切り替え
アベイラビリティーゾーン(AZ)
- 現実にAWSのインフラ(ハードウェア)群が置かれているデータセンター(のまとまり)単位?
- 各AZは地理的に独立している
- 分散配置させて耐障害性、可用性を高めるのが一般的(Multi-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ユーザの作成
管理用ユーザを作成する
- ユーザー名を入力
- 複数ユーザ同時に作成することも出来る
- 「プログラムによるアクセス」
- AWS CLI(コマンド)や開発ツールからも使用する場合にチェック
- 「アクセスキーID」と「シークレットキー」については後述
- 「AWSマネジメントコンソールへのアクセス」
- WEBコンソールログインに使用するユーザの場合にチェック
- 管理用ユーザなら必須、プログラム専用の場合は不要
- パスワード
- パスワードポリシーに違反する場合は登録できない
- 「ユーザーをグループに追加」
- 先ほど追加したグループを選択
- 生成されたユーザ情報が表形式で一覧表示される
- 「Eメールの送信」リンクから個々のアカウント毎に任意のメールアドレスに通知出来る
- 「.csv のダウンロード」からアカウント情報を"credentials.csv"というCSVファイルとしてDL出来る
- ファイル内容サンプル>
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にアクセスする際に使用する認証情報
- 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管理用のロールを作成してみる。
「EC2」>「EC2 Role for Simple Systems Manager」(SSM)を選択>次へ
導入 #3 コスト管理
請求ダッシュボード
我々のような貧乏プログラマが安心して使うためには費用の把握・分析は重要
アカウントメニュー(コンソール右上)>「請求ダッシュボード」
>直近のサービス利用料・今月分の予測料金などが確認できる
コストの詳細分析
「請求ダッシュボード」サイドメニュー>「コストエクスプローラ」
• AWS利用料金「見える化」ツール
• リージョンやサービス、リソース、タグ(※)ごとにフィルタリング・グルーピング可能
• 日次・月次などで表示期間の指定可能
• 棒グラフ/折れ線グラフで表示切り替え
※コストエクスプローラや予算機能でタグによるフィルタや条件指定を使用するには、あらかじめ「コスト配分タグ」を有効にしておく必要がある。必要になってから追加しても遅いので、最低限のカテゴリー分け用のタグだけでも最初に設定しておくとよい。
予算・請求アラームの設定
アカウントや任意のサービス毎に予算を設定し、閾値を超えたらメールが飛ぶように設定できる
「請求ダッシュボード」サイドメニュー>「予算」>「予算を作成」
※予算未作成時は画面が少々異なるが、「予算を作成」ボタンはあるはず
予算設定①:詳細
予算設定②:絞り込み
費用の算出対象をサービス・任意のタグなどで限定出来る
予算設定③:通知
現行コストまたは予算期間の予測合計値が指定した条件を満たした場合に通知を送る
- 閾値:金額($)か予算額の割合(%)で指定
- 連絡電子メール:カンマ区切りで複数指定可能
- SNSトピック:Amazon SNSを使ってメール以外にも通知できる
AWSの費用見積り
AWS Simple Monthly Calculator
- AWS公式の簡易見積りツール
- 使い方はこちらなど>操作説明書
Cloudcraft
- アーキテクチャ構成図作成WEBサービス
- 構成図に置いたEC2やRDSなどのノードから金額を自動で算出してくれる
~~ 実践編へつづく ~~
Special Thanks
当資料からリンクを貼らせて頂いた記事>