What's New Qiita

20190821のAWSに関する記事は16件です。

  • 投稿日：2019-08-21T23:26:39+09:00

EC2インスタンスを立ち上げて、PHPを動かすまで

はじめに

インフラ初心者のエンジニアにEC2のインスタンスを立てる手順を教えることになりました。
私も専門領域外ですが、初心者がハマりそうなポイントとPHPを入れて動かすところまで書いてみます。

EC2インスタンス立ち上げる

インスタンスを立てる手順は既に分かりやすい記事が多数あるので省略。
こちらの記事がシンプルで分かりやすかったので、オススメです。

AWS EC2でWebサーバーを構築してみる
https://qiita.com/Arashi/items/629aaed33401b8f2265c

上記記事の手順に沿って、無事にApache動作確認できたとします。
もし導入中にハマったら、最後のセクションでハマりやすいポイントを書いたので参考にしてみてください。

PHPを入れる

sudo yum -y install php

実行すると以下の通り。

Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Resolving Dependencies
--> Running transaction check
---> Package php.x86_64 0:5.4.16-45.amzn2.0.6 will be installed
--> Finished Dependency Resolution

...

Installed:
  php.x86_64 0:5.4.16-45.amzn2.0.6                                                                                                                                                                          

Complete!

yumの場合、デフォルトだとPHPは5.4です。
PHP7はちょっと一工夫しないといけないので、初心者がいきなり7を入れようと頑張るよりは、まず5.4を入れて動くところまで確認したほうが良いかと思います。

index.phpを有効にする

vi /etc/httpd/conf/httpd.conf

vimは使い慣れていないと使いづらいかもしれません。
サーバでサクッと設定いじったりする際に使えると便利なので、この期に覚えてしまいましょう。

...
#
<IfModule dir_module>
    DirectoryIndex index.php index.html
</IfModule>

#
...

こう記述すると、ファイル名を指定せずアクセスした際にindex.phpが存在すれば表示し、存在しなければindex.htmlを表示します。

vimの操作が分からない方

  • vimは開いたときはコマンドモードで、文章の編集ができません。
  • iキーでインサートモード（文字入力ができるモード）に切り替わります。
  • インサートモード中にEscでコマンドモードに戻ります。基本的に、このインサートモードとコマンドモードを切り替えて使います。
  • 最初は超絶使いづらいですが、慣れるとサクサクコーディングできるようになります。

index.phpを追加し保存するには

  • コマンドモードで /index[Enter]
    • スラッシュの後に入力した文字で検索ができる
  • iキーでインサートモードに切り替え、index.phpの文字列をタイピングした後にEscでコマンドモードに戻る
  • コマンドモードで　:w[Enter]　:q[Enter]と入力
    • :wで保存(write)、:qでファイルを閉じる(quit)
    • :wq[Enter]と入力すると、保存しファイルを閉じる処理を一度に実行できる

設定を反映する

設定ファイルを変更してアクセスしても、まだ反映されません。
基本的にミドルウェアの設定を変更した場合、反映するには再起動が必要です。

sudo service httpd configtest

まずはconfigでsyntax errorがないかテスト。
慣れてくるとついつい即再起動しがちですが、syntax errorが起きているとApache起動に失敗してサービスが止まるので、必ずconfigtestでエラーが起きないことを確認する癖を付けましょう。

sudo service httpd graceful

gracefulで再起動します。
ちなみに再起動はgracefulじゃなくrestartでもできますが、restartはWebサーバにアクセスしているユーザーがいて子プロセスがあってもkillします。
gracefulは子プロセス終了まで待って設定を反映するので安全です。
ただしgracefulだと反映されない設定もあったりするので、その場合はrestartしましょう。

index.phpを配置する

vi /var/www/html/index.php

vimが開くので

<?php echo 'hoge' ?>

で保存し終了。

Apacheの設定がうまくいっていれば、Webブラウザで開いた際のページに「hoge」と書かれたページが表示されます。

ハマりやすいポイント

他にもあれば随時追加します。

EC2インスタンスにsshで入れない

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0666 for 'xxxxx.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key 'xxxxx.pem': bad permissions
ec2-user@xx.xx.xx.xx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

ハマることが非常に多いです。
秘密鍵のパーミッションが緩いとエラーになります。

sudo chmod 400 xxxxx.pem

でいけるはず。

Apacheの設定ファイルが見つからない／読み取り専用で編集できない

E45: 'readonly' オプションが設定されています (! を追加で上書き)

ミドルウェアのconfigいじったり起動／停止等を実行する際は一般ユーザーが簡単にいじれちゃうと困るので、基本的にrootユーザーで実行します。

sudo su -

index.phpが真っ白な画面になる

ソースを表示すると、phpファイルがそのままテキストとして表示されていませんか？
その場合はApacheの

...
#
<IfModule dir_module>
    DirectoryIndex index.php index.html
</IfModule>

#
...

が同じように記述されているか確認してください。

index.phpが読み取り専用で保存できない

/var/www/html/ディレクトリのパーミッションがおかしい可能性があります。
雑ですが777にパーミッションを変えてしまいましょう。

sudo chmod 777 /var/www/html/

以上です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T21:32:17+09:00

ぼくのかんがえたさいきょうのWordpress@AWS環境(Route53で取得したドメインを元にSSL証明書を発行編)

はじめに

当記事はぼくのかんがえたさいきょうのWordpress@AWS環境(概要編)
にて記載している作成手順(概要)の3の詳細になります。
AWS Certification Managerにて手順2のRoute53にて取得した独自ドメインを元に
SSL証明書(ワイルドカード証明書)を取得するまでを記載します。

手順

AWSにログインし、サービスから「Certification Manager」をクリックします。

AWS CertificateManagerの管理画面が表示されます。

超重要！！！！
AWS リージョンを 米国東部（バージニア北部）に切り替えます。

大事なことなのでもう一度、記述します。

A W S リ　ー　ジ　ョ　ン　を　米　国　東　部（　バ　ー　ジ　ニ　ア　北　部　）に　切　り　替　え　ま　す　。

Q「なぜ、東京リージョンではダメなの？」
A「CrondFrontでは米国東部（バージニア北部）リージョン以外で取得したAWS CertificateManagerの証明書は使用できまないからです。」
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-requirements.html#https-requirements-aws-region
image.png

リージョンを切り替えたら
左側の証明書のプロビジョニングの「今すぐ始める」をクリック

「パブリック証明書のリクエスト」を選択して「証明書のリクエスト」をクリック

ドメイン名の欄に
「.[取得した独自ドメイン]」と入力します。（を付けるのはワイルドカード証明書(hoge.saikyouawswordpress.comとかhuga.saikyouawswordpress.com)にするため）
入力したら「次へ」をクリック

今回は「DNSの検証」を選択して
「確認」をクリックします。

「確定とリクエスト」をクリックします。

画面が遷移するので「続行」をクリックします。

登録したドメインが検証保留中となっているのが確認できます。

ドメインの横にある右三角マーク(:arrow_forward:)をクリックすると
[Route53でのレコードの作成]というボタンが表示されるのでこれをクリックします。
（※下記の画像は検証が完了してしまっているのでボタンが非アクティブになっていますが、本来であればクリック可能です。）
そもそもボタンが表示されない！という場合は証明書発行に利用したドメインがRoute53で取得したドメインでない可能性があります。

確認画面に遷移するので作成をクリック

しばらくするとドメインの検証が完了し、
検証状態が成功となり証明書が利用可能となります。

以上で証明書の発行は完了です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T20:49:18+09:00

pythonでべたに使うもの(python3)

目的

pythonをちょこちょこ調べらながら書いていて、今後も使用するであろうものをまとめる。
※初心者向け

dict(辞書)からキーがなくても落ちない方法

下記のようにdictから取得すると実行時にエラーが発生してしまう。

dict = {}
print(dict['test'])
実行結果
Traceback (most recent call last):
  File "sample.py", line 2, in <module>
    print(dict['test'])
KeyError: 'test'

dictのgetメソッドを使用することで、キーがなくてもエラーにならずにNoneが返却される。

dict = {}
print(dict.get('test'))
実行結果
None

数値のチェック

# 数値であるかチェックします。
# 半角数値、少数の場合Trueを返します。
def isNum(num):
    return re.compile('^([1-9]\\d*|0)(\\.\\d+)?$').match(num) is not None

正の整数のチェック

# 正の整数(0を除く)であるかチェックします。
# 正の整数(0を除く)である場合Trueを返します。
def isPlusInteger(num):
    return re.compile('^[1-9]\\d*$').match(num) is not None

少数第1位で切り捨て

from decimal import Decimal,ROUND_DOWN

def roundDown(val):
    return Decimal(val).quantize(Decimal('0.1'), rounding=ROUND_DOWN)

少数を整数に切り捨て

from decimal import Decimal

# 整数に切り捨てます。
def truncateNum(val):
    return str(math.floor(Decimal(val)))

日付のフォーマット

from datetime import datetime

# YYYYMMDDをYYYY/MM/DDの形式にフォーマットします。
def dayFormat(day):
    return datetime.strptime(day, '%Y%m%d').strftime('%Y/%m/%d')

AWSで日本時間で現在日時を取得します。

def getNowTime():
    # AWSの時刻は、UTCなのでJSTに変換
    return datetime.now(timezone(timedelta(hours=+9), 'JST'))

最後に

メソッド名のセンスのなさが悩み。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T19:45:19+09:00

「AWS認定ソリューションアーキテクト - アソシエイト」に5日間で合格した話

AWS(Amazon Web Service)は言わずと知れたシェアNo.1のクラウドコンピューティングサービス1です。そのAWSの認定の中でも屈指の人気を誇る「AWS認定ソリューションアーキテクト - アソシエイト」を5日間の勉強で合格することができました。本当に月曜日に思い立って試験の申込みをして勉強を開始し、その週の土曜日の朝一の試験で合格しました。本記事はその合格に至るまでの体験談になります。

(本記事は自分のブログからの転載記事です。)

はじめに

最初にお断りしておきますが、AWS認定プログラムアグリーメントの規約により、認定試験を含む試験関連資料の内容については他言してはいけないことになっているので、その辺はAWSが公開している情報に準拠します。そして試験やAWS自体も今後変わっていくと思われるので、実際に受ける際には最新の情報を確認するようお願いします。

また、本記事は筆者の体験談になりますので、以下の条件に合わない人の参考にはならないかもしれないのでご注意ください。

  • 「AWS認定ソリューションアーキテクト - アソシエイト」に短期集中型かつ実践重視で合格したい中堅エンジニア
    • ITの基礎知識(OS、DB、ネットワーク、セキュリティ)があり、ソフトウェアの開発経験あり
    • AWSのサービスに関してEC2、VPC、S3くらいには触ったことはあるが、それ以外は自信がない
    • 書籍よりもハンズオンで実践的にAWSを使う技術を身につけたい
    • 夏休み等のまとまった連休を使って一気に資格を取りたい

「AWS認定」とは

まずは簡単にAWS認定についてどういったものなのかを説明したいと思います。すでにご存知の方はこの章は飛ばしてください。
AWS認定は簡単に言えば「AWSのプロ」を認定するためのもので、特徴としてはAWSの実務経験を強く意識した試験になっていると思います2。

AWS 認定は、業界で認められている資格情報を使用してクラウドの専門知識を認証することで、学習者が信頼性と自信を築くことと、組織が AWS を使用してクラウドを主導していくスキルのあるプロを識別することに役立ちます。


AWS認定 https://aws.amazon.com/jp/certification/

「AWS認定」の全体像

AWS認定は3つののレベルと専門領域から成り立っています。自分が合格した「AWS認定ソリューションアーキテクト - アソシエイト」は、その3つのレベルの認定のちょうど中間の「アソシエイト」レベルのもので、1年間のAWSを使った実務経験がある方が対象となっています。「ソリューションアーキテクト」とは、実際にAWSを使った安全かつ堅牢なソリューションを設計できる人材を指しています。

AWS 認定より引用

アソシエイトレベルには他にも「AWS 認定デベロッパー – アソシエイト」と「AWS 認定システムオペレーション (SysOps) アドミニストレーター – アソシエイト」があり、それぞれAWSを使った「開発」と「運用」の分野のプログラムになっています。上位レベルの「プロフェッショナル」には、「ソリューションアーキテクト」はそのまま上位認定がありますが、「開発」と「運用」は統合されて「AWS 認定 DevOps エンジニア – プロフェッショナル」という認定になっています。「プロフェッショナル」レベルは2年間の実務経験たある方が対象になっています。また、アソシエイトの下には「AWS 認定クラウドプラクティショナ」という基礎レベルの認定もあります。このレベルは特に区分けはされておらず半年の実務経験が想定されています。

3つのレベルの外には5つの専門領域があって、それぞれ「セキュリティ–」、「ビッグデータ」、「高度なネットワーク」、「機械学習」、「Alexa スキルビルダー」になります。うーん、何か一つだけとてつもなく浮いている認定があるのですが、これは突っ込みどころなのでしょうか・・・ Alexaのスキル開発を「専門領域」と呼ぶには他の領域と比較してもニッチすぎる気が・・・ どうしてもAmazonが押したいのは理解できますが、せめてネーミングだけでも「音声自動化」とか汎用的なネーミングの方が違和感がなかった気がします(笑)。

「AWS認定ソリューションアーキテクト - アソシエイト」の認定試験について

「AWS認定ソリューションアーキテクト - アソシエイト」の認定試験の概要は以下のとおりです。以下はアソシエイトレベルの試験では共通しています。合格ラインに関しては720固定ですが、スコア自体はTOEICのように試験問題の難易度に応じて調整されるようです。

  • 試験時間
    • 130分間
  • 問題数
    • 65問
  • 回答タイプ
    • 択一選択問題: 選択肢には 1つの正解と3つの不正解
    • 複数選択問題: 5つの選択肢のうち、2つが正解
  • 合格ライン
    • 100～1000点の範囲のスコアでレポート
    • 最低合格スコアは720
  • 受験料金
    • 15,000 円（税別）/ 模擬試験 2,000円（税別）
  • 試験言語
    • 英語、日本語、韓国語、中国語 (簡体字)
  • 認定期間
    • 3年
    • 再認定時は同じ試験を50%割引で受けられる

試験範囲は以下のとおりです。

分野 試験における比重
分野 1 回復性の高いアーキテクチャを設計する
分野 2 パフォーマンスに優れたアーキテクチャを定義する
分野 3 セキュアなアプリケーションおよびアーキテクチャを規定する
分野 4 コスト最適化アーキテクチャを設計する
分野 5 オペレーショナルエクセレンスを備えたアーキテクチャを定義する
合計 100%

ご存知の方もいるかも知れませんが上記の分野は「Well-Architectedフレームワーク」に沿って決められているので、まずは「Well-Architectedフレームワーク」がどういったものかをざっくり理解してから試験に取り組んだほうがよいかと思われます。

スペック

さて、いよいよ本題の体験談に入っていきたいと思います。まずは試験を受ける前の自分の力量を以下に簡単に書き出してみました。

  • 基礎知識
    • OS、ネットワーク、DB、セキュリティの基本的な知識あり
  • クラウド関連
    • AWS
      • EC2関連、VPC、S3に関しては「開発」、「テスト」で利用するには問題ないレベル
      • その他の基本的なサービスに関しては名前と機能を知っているか若しくは軽く触った程度で、雑な知識と経験しかない
    • GCP,Azule
    • 少しだけ触ったことがある程度
    • Docker, Kubernetes
    • 利用経験あり
  • 開発経験
    • ミドルウェアやWebアプリを中心にいろいろ

まぁ、上記のとおりなので「初心者が5日間でとった！」みたいな衝撃的な内容ではないです。また、AWSに関してもEC2関連とVPC、S3といったAWSのキモは押さえており、その点だけでもかなり有利なのであまり参考にならない体験談かもしれません・・・

きっかけと動機と衝動

AWS認定試験を実際に受けようと思ったきっかけは「【未経験でも挫折しない】40時間でAWS認定ソリューションアーキテクトアソシエイトを取得する方法 - Qiita」という記事を読んでからでした。実はAWS認定自体は以前から知っていましたが、試験勉強よりも手を動かす方が好みなのでスルーしてきました。しかしこの記事ではUdemy3の以下の講座がオススメされており、しかしちょくちょくセールもやっているということだったので覗いてみたら、見事にセール中だったので釣られてしまいました・・・

とりあえずこのときは買っただけで満足して放っておいたのですが、夏休み中に急に天からとある言葉が降ってきたのです。「そうだ、AWS認定を受けよう」

試験の申し込み

思い立ったが吉日、さっそく試験の申込みをしました。試験日は自分の実力と確保可能な時間から考えて最短で合格できる期日を設定しました。そうすれば、最短の合格に向けてモチベーションを維持しやすくなると思ったからです。自分はちょうど夏休みで勉強時間が確保できる見込みがあったので、試験日を申込日(8/12)から5日後の8/17(土)にしました。ちなみに、試験は24時間以上前なら無料でキャンセル可能であり、試験の延期も可能なので試験を受ける気になったら申し込みを躊躇する理由はありません。

試験の申し込みは以下のページからアカウントを作成して申し込む必要があります。

試験のプロバイダーにはPSIとピアソンVUEがあるのですが、まずはピアソンVUEで試験会場を探してみることをオススメします。自分はピアソンVUEでしか受験したことがないので完全に私見になりますが、ピアソンVUEはAWS以外にも試験開催が豊富で安心して受験できます。今回は「武蔵小杉テストセンター」で受験しましたが、申し込みから受験まで特にトラブルはありませんでした。

勉強方法

正直言って、前述したQiita記事とほぼ同じです。ただし自分は書籍での勉強は行わず、UdemyのコースとWebで無料で公開されている問題だけを解きました。特にUdemyのコースをのハンズオンを重視して手を動かしながら、重要なサービスについてはきちんと理解するまで触りました。

  1. サンプル問題の確認
    • このページから「サンプル問題のダウンロード」をクリック
  2. Udemyのコースを受ける
  3. 公式模試を解く
  4. Web上の問題を解く

基本的には上記の順番で勉強したのですが、せっかく五日間で集中して終わらせたので、ここからは日付ごとにもう少し掘り下げて実施したことや感想、注意点を述べたいと思います。

一日目(月曜日)

まずは、試験概要の確認とサンプル問題の確認を行いました。どんな試験でもそうですが、合格を目指すならまず最初に試験の形式の把握と具体的な問題の傾向を把握することは一番最初にやるべきことだと思います。これをやらないと見当違いの対策をしてしまい後で後悔する可能性が高くなります。試験の概要とサンプル問題へのポインタは前述したとおりです。サンプル問題は初見で10問中5問しか正解できませんでした。つまりこのままでは確実に落ちるのでしっかりと対策を行う必要がありました(汗)。

次にUdemyのコースを受けました。基本的には動画で講義を観ながら適宜ハンズオンを実施する形式です。講義は時間がもったいないので1.75倍速で観ました。重要なところはブックマークができるようになっているので、セクションを見終わった段階で見直してメモに書き出してました。ハンズオンは動画を観ながらじっくりこなしています。知識と実際のAWSの感触は大分違うので、このハンズオンの内容レベルがきちんと身についていないと実務ではまったく役に立たないと思います。正直言って合格したいだけなら、ハンズオンをやらなくても「模擬試験」をたくさんこなせば合格は可能だと思います。しかし自分は実践的な能力の向上も欲しかったのでハンズオン重視で取り組みました。

  • セクション1 まずは知ってみる
  • セクション2 Day1対応の実施
  • セクション3 AWSとアソシエイト試験の概要
  • セクション4 IAM
  • セクション5 EC2

初日はUdemyのコースをセクション5まで進めました。ある程度知識があった箇所なので動画も理解している箇所はがんがん飛ばしてきいきました3。IAMは知っているようで、意外と理解できていない部分があったので勉強になりました。

ハンズオン後に重要なのEC2を起動したまま放置しないことです。使わないのなら停止して、できれば削除したほうが安く済みます。動画でも注意されますが、気をつけておかないとすぐに料金に跳ね返ってきます。なので忘れないようにCloudWatchの請求でアラームをしかけておくか定期的に「マイ請求ダッシュボード」で料金を確認する習慣をつけることをオススメします。

二日目(火曜日)

二日目の最初はVPCとS3のハンズオンをしっかりやりました。このふたつはAWSを代表するサービスなので、AWSのコンソールから一通りできることを確認して理解があやふやな箇所がないようにすることが肝要です。「Well-Architected Framework」はAWSが推奨するAWSを使った設計の方法論です。これは非常に重要なのでしっかりと理解すべきで、動画だけでなくホワイトペーパーもしっかり目を通して置く必要があります。クラウドではキャパシティプランニングやセキュリティの考え方が特にオンプレとは異なるので要注意です。

  • セクション6 VPC
  • セクション7 S3
  • セクション8 Well Architected Framework

三日目(水曜日)

三日目はクラウドの強みともいえる、高可用性、信頼の設計です。おなじみのマルチAZ構成のWebサーバをロードバランシングとオートスケールさせるやつです。さらにデータベース(RDS)を定期的にS3にスナップショットでバックアップをとりつつ、マルチAZ構成で自動フェールオーバできるようしてリードレプリカでスケールアウトさせる構成も学びます。

次にRoute53はDNSですが、ただのDNSではありません。基本的にはBINDでDNS運用の経験がある人なら特に問題なく利用可能ですが4、aliasレコードやルーティングポリシーやトラフィックフロー等、新しい機能や概念も出てくるのでしっかりと理解する必要があります。あと、ハンズオンでドメイン名を使うので持っていない人はドメイン名をお名前.comで早めに取得しておいた方が良いです5。DNSの反映には数時間から72時間かかるので、もしドメインを新規取得するなら早めにやっておくことをオススメします。

データベースではDynamo DBやAurora、EFSのハンズオンがあり、よく理解できていないところもあったので助かりました。そしてなぜかデータベースのセクションにIoTでよく用いられるKinesisのハンズオンも含まれていました。いや、ハンズオンは良かったのですが「なぜ、ここにいれたし」と思ってしまいました（笑）。

  • セクション9 信頼性の設計
  • セクション10 Route53
  • セクション11 データベース

四日目(木曜日)

四日目は一番楽しみにしていました。この日に学べるサービスは「ElastiCache」、「Lambda」、「CloudFormation」です。もちろん一番興味があったのはサーバレスの中核を成す「Lambda」で、FaaS(Function as a Service)をAWSでどのように実現していくのかを学びました。手を動かしてみると今までの知識だけの理解とは違い色々分かって面白かったです。特に「設計図」や「 Serverless Application Repository」等で簡単に始められて共有する仕組みがあり、他の人が作ったサーバレスアプリケーションを眺められたので勉強になりました6。「ElastiCache」は使い方が限られているので役割をしっかり押さえておけば大丈夫です。「CloudFormation」は実務では凄い有用ですし実際触ってみると嵌りどころが多い機能ですが、試験ではそこまで突っ込んだ内容は出ないと思われるので、時間がなければ役割とフォーマットだけ押さえておけば大丈夫です。

  • セクション12 キャッシュの活用
  • セクション13 サーバレス
  • セクション14 環境の自動化

五日目(金曜日)

五日目は最後の仕上げです。セキュリティと運用は座学だけかとおもったらCloudWatchのハンズオンがありました。CloudWatchもAWSのなかで重要なサービスなので手を抜かずしっかりとハンズオンして不安な箇所を潰しました。

あとはひたすら模擬試験を解くだけです。Udemyの模擬試験は試験と同じ65問ありますが、本番の130分もかからないです。早ければ1時間もかからないと思うので、見直しはせずさっさと確定して結果を見て、間違った箇所を復習するほうが効率は良いです。ただし、不安な箇所はなぜ最終的にその選択肢を選んだのかをメモしておくと、復習の際に役立ちます。Udemyの模擬試験は２回分あり、さらにおまけでクイズ形式の問題もついてくるので合計3回分あります。これらをしっかりと復習して間違えないようになればかなり自信は付くと思います。

公式模擬試験は問題数が少なく難易度も低めですが、本番とまったく同じUIと操作感なので本番で焦らないためにもぜひ受けておくことをおすすめします。試験終了後は問題を見ることができないので復習に必要な箇所はメモしておいてください。ちなみに自分のスコアは84%でした。
残りの時間はひたすらWeb上の問題を解きました。意外と知らない箇所があったので非常に役立ちました。

試験当日(土曜日)

試験は10:30からだったので、朝７時頃に起きて2時間程みっちり復習しました。具体的には模擬試験とWeb上の問題で不安な箇所をもう一度見直しました。

試験会場は武蔵小杉駅の北口正面にある武蔵小杉STMビルの7階のテストセンターでした。会場には15分前に来ることと指示があったので余裕をもって30分前に着きました。早すぎたかなとも思いましたが、とくに待たされることもなく試験を受けることができました。本人確認証には免許証と直筆サイン入りのクレジットカードを用意しました。試験前にはさらに直筆のサインと写真撮影を行い、荷物をポケットの中のものも含めてロッカーにいれて試験会場に入りました。試験はパーティションで区切られたパソコンで行う一般的なものです。集中できるようにイヤーマフや耳栓が置いてありました。

試験問題はだいたい1時間程で解き終わったので最初からもう一度見直して終了しました。合否はその場で表示されるので最後までページを進めてきちんと確認する必要があります。

認定に費やした勉強時間と費用

認定に費やした勉強時間と費用は以下のとおりです。月曜から金曜までは6時間集中してやったわけではなく、1時間やったら1時間休憩みたいな感じで疲れすぎないようにやりました。費用は2万以上かかりましたが、5日間AWSで充分遊べて認定も取れたのでいい買い物をしたなと思いました。

  • 勉強時間: 合計32時間
    • 月曜から金曜: 平均6時間 × 5日間
    • 土曜: 2時間(試験前の見直し時間)
  • 費用: 合計21,960円
    • 認定試験: 16,200円 (税込み)
    • 模擬試験: 2,160円 (税込み)
    • Udemy: 1,600円 (セール時の価格)
    • AWS使用料金: 約2000円

試験結果

試験結果は無事合格でした。スコアは以下のとおりです。見直しが終わった時点で「満点いけるかも?」と淡い期待を抱いたのですが、その幻想は無惨にも打ち砕かれました。もっと精進します・・・

まとめ

「AWS認定ソリューションアーキテクト - アソシエイト」に関してはすでに多くの記事が書かれているので、自分が書く必要があるのか迷ったのですが、短期集中型でハンズオン重視の記事は少なそうだったので書いてみました。

今回の経験で分かったのはAWSの試験問題は実務経験を想定しているので、単なる知識で解ける問題よりも具体的なシチュエーションを提示して、最適解を問うような問題が多いです。このような試験形態の場合は暗記中心の勉強だと足元をすくわれる可能性が高いので、愚直に「理論」と「実践」をバランス良く学ぶことが近道ではないのかと思いました。今回はUdemyのオンライン動画学習サービスを利用して、以下の要領で自分のペースで理解を深めるようにしたので正直暗記が苦手な自分でも試験勉強が苦になりませんでした。

  1. 座学で理論を身につける
  2. 手を動かして理論と現実のAWSを結びつける
  3. 模擬試験の問題のシチュエーションを「具体的なAWSのサービスと操作手順」でイメージをする
    • イメージできなかったら実際にAWSに触りながら理解を深める

なんか結局Udemyの回し者みたいな記事になってしまいましたが、もちろん筆者は単に教材に釣られた購入者に過ぎません(笑)。本記事が、「AWS認定ソリューションアーキテクト - アソシエイト」を受ける方の一助になれば幸いです。

おまけ：手を動かして学んだほうが良いAWSサービス

「AWS認定ソリューションアーキテクト - アソシエイト」の試験には、ある程度手を動かして学んで「肌感覚」で身につけておいた方が良いサービスが存在すると思っています。特に自分のように暗記が苦手な方や実践に重きを置く方にとって、AWSの「肌感覚」を身につけることはAWSが絡む様々な場面で強い味方になるはずです。以下は私見ですが手を動かした方がよいサービスを雑に分類してみました7。

  1. 絶対に手を動かして学んだほうが良い
    • EC2, VPC, IAM, S3, CloudWatch
  2. できれば手を動かして学んだほうが良い
    • RDS, DynamoDB, EFS, SNS, SQS, Route53, Lambda, API Gateway
  3. 余裕があれば手を動かして学んだほうが良い
    • ECR, ECS, EKS, Elastic Beanstalk, CloudFormation, CloudFront, ElastiCache
  4. 興味があれば手を動かして学んだほうが良い
    • Elasticsearch Service, Codeシリーズ, EMR
    • RedShift, Kinesis, OpsWorks, SES, Step Functions
  5. 知識として知っておいたほうが良い
    • Neptune, Storage Gateway, Direct Connect, Glacier, QuickSight, Data Pipeline
    • Key Management Service(KMS), Snowball, Glue, Organization, Batch
    • Service Catalog, System Manager, Trusted Advisor, SageMaker, Config
    • Cloud Trail, Cost Explorer, GuardDuty, Cognito, Athena, Inspector
    • WAF & Shield, Backup, CloudTrail, Lightsail, Directory Service

参考文献

  1. AWSは主にIaaS(Infrastructure as a Service)を提供しています。 ↩

  2. 実際に実務経験の有無を確認されるわけではありません。あくまで実務経験が必要なレベルだということだと思います。AWS認定のQ & Aにも認定に際する前提条件はないことが書かれていました。実際に「AWS認定ソリューションアーキテクト - アソシエイト」を合格された方の中には実務経験の無い方やAWSを触ったことが無い方もおられるようです。 ↩

  3. Udemy（ユーデミー）は、世界で2,400万人が利用する世界最大級のオンライン動画学習サービスです。 ↩

  4. Route53はWindowsサーバのDNSよりもBIND寄りの印象ですが、それをさらにシンプルにして使いやすくした感じです。さらにマネージドサービスでSLA100%を謳っています。すごい・・・ ↩

  5. 動画でも説明されていますが、Route53でドメインを購入すると結構お高いです。お名前.comなら「.work」ドメインを1円で販売していました(2019年8月18日時点)。 ↩

  6. せっかくなので、自分もいくつかサーバレスアプリケーションを作って「 Serverless Application Repository」に公開してみたいと思います。いつになるかは分かりませんが・・・ ↩

  7. 同じ分類内は順不同です。またこの手の分類に正解はないのでツッコミは不要です(笑)。 ↩

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T19:45:19+09:00

暗記が苦手な人間が「AWS認定ソリューションアーキテクト - アソシエイト」に5日間で合格した話

AWS(Amazon Web Service)は言わずと知れたシェアNo.1のクラウドコンピューティングサービス1です。そのAWSの認定の中でも屈指の人気を誇る「AWS認定ソリューションアーキテクト - アソシエイト」を5日間の勉強で合格することができました。本当に月曜日に思い立って試験の申込みをして勉強を開始し、その週の土曜日の朝一の試験で合格しました。本記事はその合格に至るまでの体験談になります。

(本記事は自分のブログからの転載記事です。)

(8/22 追記)

記事で紹介している以下のコースがちょうどUdemyでセール中で1200円になっています。(8/29日午後11時59分（太平洋夏時間）まで)

はじめに

最初にお断りしておきますが、AWS認定プログラムアグリーメントの規約により、認定試験を含む試験関連資料の内容については他言してはいけないことになっているので、その辺はAWSが公開している情報に準拠します。そして試験やAWS自体も今後変わっていくと思われるので、実際に受ける際には最新の情報を確認するようお願いします。

また、本記事は筆者の体験談になりますので、以下の条件に合わない人の参考にはならないかもしれないのでご注意ください。

  • 「AWS認定ソリューションアーキテクト - アソシエイト」に短期集中型かつ実践重視で合格したい中堅エンジニア
    • ITの基礎知識(OS、DB、ネットワーク、セキュリティ)があり、ソフトウェアの開発経験あり
    • AWSのサービスに関してEC2、VPC、S3くらいには触ったことはあるが、それ以外は自信がない
    • 書籍よりもハンズオンで実践的にAWSを使う技術を身につけたい
      • ぶっちゃけ暗記が苦手もしくは嫌い
    • 夏休み等のまとまった連休を使って一気に資格を取りたい

「AWS認定」とは

まずは簡単にAWS認定についてどういったものなのかを説明したいと思います。すでにご存知の方はこの章は飛ばしてください。
AWS認定は簡単に言えば「AWSのプロ」を認定するためのもので、特徴としてはAWSの実務経験を強く意識した試験になっていると思います2。

AWS 認定は、業界で認められている資格情報を使用してクラウドの専門知識を認証することで、学習者が信頼性と自信を築くことと、組織が AWS を使用してクラウドを主導していくスキルのあるプロを識別することに役立ちます。


AWS認定 https://aws.amazon.com/jp/certification/

「AWS認定」の全体像

AWS認定は3つののレベルと専門領域から成り立っています。自分が合格した「AWS認定ソリューションアーキテクト - アソシエイト」は、その3つのレベルの認定のちょうど中間の「アソシエイト」レベルのもので、1年間のAWSを使った実務経験がある方が対象となっています。「ソリューションアーキテクト」とは、実際にAWSを使った安全かつ堅牢なソリューションを設計できる人材を指しています。

AWS 認定より引用

アソシエイトレベルには他にも「AWS 認定デベロッパー – アソシエイト」と「AWS 認定システムオペレーション (SysOps) アドミニストレーター – アソシエイト」があり、それぞれAWSを使った「開発」と「運用」の分野のプログラムになっています。上位レベルの「プロフェッショナル」には、「ソリューションアーキテクト」はそのまま上位認定がありますが、「開発」と「運用」は統合されて「AWS 認定 DevOps エンジニア – プロフェッショナル」という認定になっています。「プロフェッショナル」レベルは2年間の実務経験たある方が対象になっています。また、アソシエイトの下には「AWS 認定クラウドプラクティショナ」という基礎レベルの認定もあります。このレベルは特に区分けはされておらず半年の実務経験が想定されています。

3つのレベルの外には5つの専門領域があって、それぞれ「セキュリティ–」、「ビッグデータ」、「高度なネットワーク」、「機械学習」、「Alexa スキルビルダー」になります。うーん、何か一つだけとてつもなく浮いている認定があるのですが、これは突っ込みどころなのでしょうか・・・ Alexaのスキル開発を「専門領域」と呼ぶには他の領域と比較してもニッチすぎる気が・・・ どうしてもAmazonが押したいのは理解できますが、せめてネーミングだけでも「音声自動化」とか汎用的なネーミングの方が違和感がなかった気がします(笑)。

「AWS認定ソリューションアーキテクト - アソシエイト」の認定試験について

「AWS認定ソリューションアーキテクト - アソシエイト」の認定試験の概要は以下のとおりです。以下はアソシエイトレベルの試験では共通しています。合格ラインに関しては720固定ですが、スコア自体はTOEICのように試験問題の難易度に応じて調整されるようです。

  • 試験時間
    • 130分間
  • 問題数
    • 65問
  • 回答タイプ
    • 択一選択問題: 選択肢には 1つの正解と3つの不正解
    • 複数選択問題: 5つの選択肢のうち、2つが正解
  • 合格ライン
    • 100～1000点の範囲のスコアでレポート
    • 最低合格スコアは720
  • 受験料金
    • 15,000 円（税別）/ 模擬試験 2,000円（税別）
  • 試験言語
    • 英語、日本語、韓国語、中国語 (簡体字)
  • 認定期間
    • 3年
    • 再認定時は同じ試験を50%割引で受けられる

試験範囲は以下のとおりです。

分野 試験における比重
分野 1 回復性の高いアーキテクチャを設計する
分野 2 パフォーマンスに優れたアーキテクチャを定義する
分野 3 セキュアなアプリケーションおよびアーキテクチャを規定する
分野 4 コスト最適化アーキテクチャを設計する
分野 5 オペレーショナルエクセレンスを備えたアーキテクチャを定義する
合計 100%

ご存知の方もいるかも知れませんが上記の分野は「Well-Architectedフレームワーク」に沿って決められているので、まずは「Well-Architectedフレームワーク」がどういったものかをざっくり理解してから試験に取り組んだほうがよいかと思われます。

スペック

さて、いよいよ本題の体験談に入っていきたいと思います。まずは試験を受ける前の自分の力量を以下に簡単に書き出してみました。

  • 基礎知識
    • OS、ネットワーク、DB、セキュリティの基本的な知識あり
  • クラウド関連
    • AWS
      • EC2関連、VPC、S3に関しては「開発」、「テスト」で利用するには問題ないレベル
      • その他の基本的なサービスに関しては名前と機能を知っているか若しくは軽く触った程度で、雑な知識と経験しかない
    • GCP,Azule
      • 少しだけ触ったことがある程度
    • Docker, Kubernetes
      • 利用経験あり
  • 開発経験
    • ミドルウェアやWebアプリを中心にいろいろ

まぁ、上記のとおりなので「初心者が5日間でとった！」みたいな衝撃的な内容ではないです。また、AWSに関してもEC2関連とVPC、S3といったAWSのキモは押さえており、その点だけでもかなり有利なのであまり参考にならない体験談かもしれません・・・

きっかけと動機と衝動

AWS認定試験を実際に受けようと思ったきっかけは「【未経験でも挫折しない】40時間でAWS認定ソリューションアーキテクトアソシエイトを取得する方法 - Qiita」という記事を読んでからでした。実はAWS認定自体は以前から知っていましたが、試験勉強よりも手を動かす方が好みなのでスルーしてきました。しかしこの記事ではUdemy3の以下の講座がオススメされており、しかしちょくちょくセールもやっているということだったので覗いてみたら、見事にセール中だったので釣られてしまいました・・・

とりあえずこのときは買っただけで満足して放っておいたのですが、夏休み中に急に天からとある言葉が降ってきたのです。「そうだ、AWS認定を受けよう」

試験の申し込み

思い立ったが吉日、さっそく試験の申込みをしました。試験日は自分の実力と確保可能な時間から考えて最短で合格できる期日を設定しました。そうすれば、最短の合格に向けてモチベーションを維持しやすくなると思ったからです。自分はちょうど夏休みで勉強時間が確保できる見込みがあったので、試験日を申込日(8/12)から5日後の8/17(土)にしました。ちなみに、試験は24時間以上前なら無料でキャンセル可能であり、試験の延期も可能なので試験を受ける気になったら申し込みを躊躇する理由はありません。

試験の申し込みは以下のページからアカウントを作成して申し込む必要があります。

試験のプロバイダーにはPSIとピアソンVUEがあるのですが、まずはピアソンVUEで試験会場を探してみることをオススメします。自分はピアソンVUEでしか受験したことがないので完全に私見になりますが、ピアソンVUEはAWS以外にも試験開催が豊富で安心して受験できます。今回は「武蔵小杉テストセンター」で受験しましたが、申し込みから受験まで特にトラブルはありませんでした。

勉強方法

正直言って、前述したQiita記事とほぼ同じです。ただし自分は書籍での勉強は行わず、UdemyのコースとWebで無料で公開されている問題だけを解きました。特にUdemyのコースをのハンズオンを重視して手を動かしながら、重要なサービスについてはきちんと理解するまで触りました。

  1. サンプル問題の確認
    • このページから「サンプル問題のダウンロード」をクリック
  2. Udemyのコースを受ける
  3. 公式模試を解く
  4. Web上の問題を解く

基本的には上記の順番で勉強したのですが、せっかく五日間で集中して終わらせたので、ここからは日付ごとにもう少し掘り下げて実施したことや感想、注意点を述べたいと思います。

一日目(月曜日)

まずは、試験概要の確認とサンプル問題の確認を行いました。どんな試験でもそうですが、合格を目指すならまず最初に試験の形式の把握と具体的な問題の傾向を把握することは一番最初にやるべきことだと思います。これをやらないと見当違いの対策をしてしまい後で後悔する可能性が高くなります。試験の概要とサンプル問題へのポインタは前述したとおりです。サンプル問題は初見で10問中5問しか正解できませんでした。つまりこのままでは確実に落ちるのでしっかりと対策を行う必要がありました(汗)。

次にUdemyのコースを受けました。基本的には動画で講義を観ながら適宜ハンズオンを実施する形式です。講義は時間がもったいないので1.75倍速で観ました。重要なところはブックマークができるようになっているので、セクションを見終わった段階で見直してメモに書き出してました。ハンズオンは動画を観ながらじっくりこなしています。知識と実際のAWSの感触は大分違うので、このハンズオンの内容レベルがきちんと身についていないと実務ではまったく役に立たないと思います。正直言って合格したいだけなら、ハンズオンをやらなくても「模擬試験」をたくさんこなせば合格は可能だと思います。しかし自分は実践的な能力の向上も欲しかったのでハンズオン重視で取り組みました。

  • セクション1 まずは知ってみる
  • セクション2 Day1対応の実施
  • セクション3 AWSとアソシエイト試験の概要
  • セクション4 IAM
  • セクション5 EC2

初日はUdemyのコースをセクション5まで進めました。ある程度知識があった箇所なので動画も理解している箇所はがんがん飛ばしてきいきました3。IAMは知っているようで、意外と理解できていない部分があったので勉強になりました。

ハンズオン後に重要なのEC2を起動したまま放置しないことです。使わないのなら停止して、できれば削除したほうが安く済みます。動画でも注意されますが、気をつけておかないとすぐに料金に跳ね返ってきます。なので忘れないようにCloudWatchの請求でアラームをしかけておくか定期的に「マイ請求ダッシュボード」で料金を確認する習慣をつけることをオススメします。

二日目(火曜日)

二日目の最初はVPCとS3のハンズオンをしっかりやりました。このふたつはAWSを代表するサービスなので、AWSのコンソールから一通りできることを確認して理解があやふやな箇所がないようにすることが肝要です。「Well-Architected Framework」はAWSが推奨するAWSを使った設計の方法論です。これは非常に重要なのでしっかりと理解すべきで、動画だけでなくホワイトペーパーもしっかり目を通して置く必要があります。クラウドではキャパシティプランニングやセキュリティの考え方が特にオンプレとは異なるので要注意です。

  • セクション6 VPC
  • セクション7 S3
  • セクション8 Well Architected Framework

三日目(水曜日)

三日目はクラウドの強みともいえる、高可用性、信頼の設計です。おなじみのマルチAZ構成のWebサーバをロードバランシングとオートスケールさせるやつです。さらにデータベース(RDS)を定期的にS3にスナップショットでバックアップをとりつつ、マルチAZ構成で自動フェールオーバできるようしてリードレプリカでスケールアウトさせる構成も学びます。

次にRoute53はDNSですが、ただのDNSではありません。基本的にはBINDでDNS運用の経験がある人なら特に問題なく利用可能ですが4、aliasレコードやルーティングポリシーやトラフィックフロー等、新しい機能や概念も出てくるのでしっかりと理解する必要があります。あと、ハンズオンでドメイン名を使うので持っていない人はドメイン名をお名前.comで早めに取得しておいた方が良いです5。DNSの反映には数時間から72時間かかるので、もしドメインを新規取得するなら早めにやっておくことをオススメします。

データベースではDynamo DBやAurora、EFSのハンズオンがあり、よく理解できていないところもあったので助かりました。そしてなぜかデータベースのセクションにIoTでよく用いられるKinesisのハンズオンも含まれていました。いや、ハンズオンは良かったのですが「なぜ、ここにいれたし」と思ってしまいました（笑）。

  • セクション9 信頼性の設計
  • セクション10 Route53
  • セクション11 データベース

四日目(木曜日)

四日目は一番楽しみにしていました。この日に学べるサービスは「ElastiCache」、「Lambda」、「CloudFormation」です。もちろん一番興味があったのはサーバレスの中核を成す「Lambda」で、FaaS(Function as a Service)をAWSでどのように実現していくのかを学びました。手を動かしてみると今までの知識だけの理解とは違い色々分かって面白かったです。特に「設計図」や「 Serverless Application Repository」等で簡単に始められて共有する仕組みがあり、他の人が作ったサーバレスアプリケーションを眺められたので勉強になりました6。「ElastiCache」は使い方が限られているので役割をしっかり押さえておけば大丈夫です。「CloudFormation」は実務では凄い有用ですし実際触ってみると嵌りどころが多い機能ですが、試験ではそこまで突っ込んだ内容は出ないと思われるので、時間がなければ役割とフォーマットだけ押さえておけば大丈夫です。

  • セクション12 キャッシュの活用
  • セクション13 サーバレス
  • セクション14 環境の自動化

五日目(金曜日)

五日目は最後の仕上げです。セキュリティと運用は座学だけかとおもったらCloudWatchのハンズオンがありました。CloudWatchもAWSのなかで重要なサービスなので手を抜かずしっかりとハンズオンして不安な箇所を潰しました。

あとはひたすら模擬試験を解くだけです。Udemyの模擬試験は試験と同じ65問ありますが、本番の130分もかからないです。早ければ1時間もかからないと思うので、見直しはせずさっさと確定して結果を見て、間違った箇所を復習するほうが効率は良いです。ただし、不安な箇所はなぜ最終的にその選択肢を選んだのかをメモしておくと、復習の際に役立ちます。Udemyの模擬試験は２回分あり、さらにおまけでクイズ形式の問題もついてくるので合計3回分あります。これらをしっかりと復習して間違えないようになればかなり自信は付くと思います。

公式模擬試験は問題数が少なく難易度も低めですが、本番とまったく同じUIと操作感なので本番で焦らないためにもぜひ受けておくことをおすすめします。試験終了後は問題を見ることができないので復習に必要な箇所はメモしておいてください。ちなみに自分のスコアは84%でした。
残りの時間はひたすらWeb上の問題を解きました。意外と知らない箇所があったので非常に役立ちました。

試験当日(土曜日)

試験は10:30からだったので、朝７時頃に起きて2時間程みっちり復習しました。具体的には模擬試験とWeb上の問題で不安な箇所をもう一度見直しました。

試験会場は武蔵小杉駅の北口正面にある武蔵小杉STMビルの7階のテストセンターでした。会場には15分前に来ることと指示があったので余裕をもって30分前に着きました。早すぎたかなとも思いましたが、とくに待たされることもなく試験を受けることができました。本人確認証には免許証と直筆サイン入りのクレジットカードを用意しました。試験前にはさらに直筆のサインと写真撮影を行い、荷物をポケットの中のものも含めてロッカーにいれて試験会場に入りました。試験はパーティションで区切られたパソコンで行う一般的なものです。集中できるようにイヤーマフや耳栓が置いてありました。

試験問題はだいたい1時間程で解き終わったので最初からもう一度見直して終了しました。合否はその場で表示されるので最後までページを進めてきちんと確認する必要があります。

認定に費やした勉強時間と費用

認定に費やした勉強時間と費用は以下のとおりです。月曜から金曜までは6時間集中してやったわけではなく、1時間やったら1時間休憩みたいな感じで疲れすぎないようにやりました。費用は2万以上かかりましたが、5日間AWSで充分遊べて認定も取れたのでいい買い物をしたなと思いました。

  • 勉強時間: 合計32時間
    • 月曜から金曜: 平均6時間 × 5日間
    • 土曜: 2時間(試験前の見直し時間)
  • 費用: 合計21,960円
    • 認定試験: 16,200円 (税込み)
    • 模擬試験: 2,160円 (税込み)
    • Udemy: 1,600円 (セール時の価格)
    • AWS使用料金: 約2000円

試験結果

試験結果は無事合格でした。スコアは以下のとおりです。見直しが終わった時点で「満点いけるかも?」と淡い期待を抱いたのですが、その幻想は無惨にも打ち砕かれました。もっと精進します・・・

まとめ

「AWS認定ソリューションアーキテクト - アソシエイト」に関してはすでに多くの記事が書かれているので、自分が書く必要があるのか迷ったのですが、短期集中型でハンズオン重視の記事は少なそうだったので書いてみました。

今回の経験で分かったのはAWSの試験問題は実務経験を想定しているので、単なる知識で解ける問題よりも具体的なシチュエーションを提示して、最適解を問うような問題が多いです。このような試験形態の場合は暗記中心の勉強だと足元をすくわれる可能性が高いので、愚直に「理論」と「実践」をバランス良く学ぶことが近道ではないのかと思いました。今回はUdemyのオンライン動画学習サービスを利用して、以下の要領で自分のペースで理解を深めるようにしたので正直暗記が苦手な自分でも試験勉強が苦になりませんでした。

  1. 座学で理論を身につける
  2. 手を動かして理論と現実のAWSを結びつける
  3. 模擬試験の問題のシチュエーションを「具体的なAWSのサービスと操作手順」でイメージをする
    • イメージできなかったら実際にAWSに触りながら理解を深める

また、短期集中型の利点ですが、暗記な苦手な人や忘れやすい人でも、短い期間だけ覚悟を決めればいいだけなので大分気が楽になります。また試験のストレスやプレッシャーに弱い人でも短期間であれば耐えられるという人も多いとおもうので、そういう方にも短期集中型をオススメします。逆に短期集中型の欠点は、当然まとまった休暇（予定なし）が確保しづらいということですね・・・まぁ工夫するしかないです。

なんか結局Udemyの回し者みたいな記事になってしまいましたが、もちろん筆者は単に教材に釣られた購入者に過ぎません(笑)。本記事が、「AWS認定ソリューションアーキテクト - アソシエイト」を受ける方の一助になれば幸いです。

おまけ：手を動かして学んだほうが良いAWSサービス

「AWS認定ソリューションアーキテクト - アソシエイト」の試験には、ある程度手を動かして学んで「肌感覚」で身につけておいた方が良いサービスが存在すると思っています。特に自分のように暗記が苦手な方や実践に重きを置く方にとって、AWSの「肌感覚」を身につけることはAWSが絡む様々な場面で強い味方になるはずです。以下は私見ですが手を動かした方がよいサービスを雑に分類してみました7。

  1. 絶対に手を動かして学んだほうが良い
    • EC2, VPC, IAM, S3, CloudWatch
  2. できれば手を動かして学んだほうが良い
    • RDS, DynamoDB, EFS, SNS, SQS, Route53, Lambda, API Gateway
  3. 余裕があれば手を動かして学んだほうが良い
    • ECR, ECS, EKS, Elastic Beanstalk, CloudFormation, CloudFront, ElastiCache
  4. 興味があれば手を動かして学んだほうが良い
    • Elasticsearch Service, Codeシリーズ, EMR
    • RedShift, Kinesis, OpsWorks, SES, Step Functions
  5. 知識として知っておいたほうが良い
    • Neptune, Storage Gateway, Direct Connect, Glacier, QuickSight, Data Pipeline
    • Key Management Service(KMS), Snowball, Glue, Organization, Batch
    • Service Catalog, System Manager, Trusted Advisor, SageMaker, Config
    • Cloud Trail, Cost Explorer, GuardDuty, Cognito, Athena, Inspector
    • WAF & Shield, Backup, CloudTrail, Lightsail, Directory Service

参考文献

  1. AWSは主にIaaS(Infrastructure as a Service)を提供しています。 ↩

  2. 実際に実務経験の有無を確認されるわけではありません。あくまで実務経験が必要なレベルだということだと思います。AWS認定のQ & Aにも認定に際する前提条件はないことが書かれていました。実際に「AWS認定ソリューションアーキテクト - アソシエイト」を合格された方の中には実務経験の無い方やAWSを触ったことが無い方もおられるようです。 ↩

  3. Udemy（ユーデミー）は、世界で2,400万人が利用する世界最大級のオンライン動画学習サービスです。 ↩

  4. Route53はWindowsサーバのDNSよりもBIND寄りの印象ですが、それをさらにシンプルにして使いやすくした感じです。さらにマネージドサービスでSLA100%を謳っています。すごい・・・ ↩

  5. 動画でも説明されていますが、Route53でドメインを購入すると結構お高いです。お名前.comなら「.work」ドメインを1円で販売していました(2019年8月18日時点)。 ↩

  6. せっかくなので、自分もいくつかサーバレスアプリケーションを作って「 Serverless Application Repository」に公開してみたいと思います。いつになるかは分かりませんが・・・ ↩

  7. 同じ分類内は順不同です。またこの手の分類に正解はないのでツッコミは不要です(笑)。 ↩

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T19:14:54+09:00

FSx for Windowsでvssやってみたら日本語EC2(Windows)だと失敗する件

すごく久しぶりに投稿です。
サポってました。1年ぶりです。

Amazon FSx for Windowsでvss設定をEC2 Windows 日本語からやる方法

FSx for WindowsでVolume Shadow Copyがサポートされたとのことでやってみました。

参考：AWSドキュメント

FSx for Windowsの作成等は、みなさんいろいろ記事かかれてるので、割愛します。

実施環境は以下です。

  • AWS MicrosoftAD
  • 管理用EC2(AMI：Windows_Server-2016-Japanese-Full-Base-2019.07.12 - ami-0bc8442658e36a4d2)
    • AWS MicrosoftAD参加後、FSx fow WindowsボリュームをZドライブにマウントした状態
  • FSx for Windowsボリューム 1つ

ドキュメントのとおり実施しても失敗します。(タイトルどおり)

fsx_vss_result.png

英語OSだと成功します。

やることは上記URLのリンクにあるようにするだけです。

FSxFileSystem-DNS-Nameは環境毎の実際のDNS名に置き換えてください。
例：fs-xxxxxxxxx.ドメイン名

Invoke-Command -ComputerName FSxFileSystem-DNS-Name -ConfigurationName FSxRemoteAdmin -scriptblock {Set-FsxShadowStorage -Default}

Invoke-Command -ComputerName FSxFileSystem-DNS-Name -ConfigurationName FSxRemoteAdmin -scriptblock {Set-FsxShadowCopySchedule -Default}

補足
Invoke-Command
コマンド、スクリプトを対象のサーバ(ローカル or リモート)で実行し、結果をローカルに返す

scriptblock
実行したいコマンド、スクリプト

日本語OSから実施するには！？

エラー内容から、要はセッション先とのローカライズの問題っぽいです。

これでいけます。

$usSession = New-PSSessionOption -Culture en-US -UICulture en-US
Invoke-Command -ComputerName FSxFileSystem-DNS-Name -SessionOption $usSession -ConfigurationName FSxRemoteAdmin -scriptblock {Set-FsxShadowStorage -Default}

Invoke-Command -ComputerName FSxFileSystem-DNS-Name -SessionOption $usSession -ConfigurationName FSxRemoteAdmin -scriptblock {Set-FsxShadowCopySchedule -Default}

vssの実行スケジュールを変更したい場合はここを参照すればオッケーです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T18:02:00+09:00

特定のEC2起動停止専用のIAMユーザー

はじめに

AWSにて特定のEC2サーバのみを起動停止するだけのユーザーを作ることになりました。

  • 対象となるサーバは今後増えることが予想されるため、
    対象かどうかの判定にはインスタンスIDではなくタグを用いて判別しています。
  • そのユーザーのアクセス元IPは固定IPであることから、
    そのフィルタも入れることでセキュリティを向上させています。
  • ほかのEC2サーバの詳細な情報はそのユーザーには知られたくないため、
    AWSCLIからのみのアクセスとします。

作業

それでは実際に設定してみます。
ポリシーを作ってIAMユーザーに割り当て、
そのIAMユーザーのアクセスキーを使ってCLIで起動停止コマンドを発行する。
という流れです。

設定（ポリシー編）

IAM > ポリシー > ポリシーの作成 からポリシーを作ります。
ここではec2StartStopPolicyとします。
ポリシーのJSONは以下の通りです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",    // (1)
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "xxx.xxx.xxx.xxx/32",
                        "yyy.yyy.yyy.yyy/32"
                    ]
                }
            }
        },
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/タグのキー": "タグの値" // (2)
                }
            }
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "ec2:DescribeInstanceStatus",
            "Resource": "*"  // (3)
        }
    ]
}

説明

  • (1) 固定IP許可について
    指定したIP以外からの操作は拒否。という形になります。
    記載例のように複数指定することもできます。
  • (2) タグによる操作権限
    付与したタグのキー/値がここで指定したものと一致するEC2サーバだけが起動停止可能になります。
  • (3) 起動停止ステータスへの権限管理
    EC2サーバが起動しているのか停止しているのかを知るためのActionがec2:DescribeInstanceStatusになります。
    このActionには制限を加えることができません。

設定（ユーザー編）

IAM > ユーザー > ユーザーを追加 からIAMユーザーを作ります。

  • ユーザー名
    ここでは ec2StartStopUser とします
  • アクセスの種類
    プログラムによるアクセス にだけチェック
  • アクセス許可の設定
    既存のポリシーを直接アタッチ を選択し、ec2StartStopPolicy を指定

アクセスキーID/シークレットアクセスキーのペアが生成されますのでメモっておきます。

設定（CLI編）

Amazonのマニュアルを参考にCLIをインストールして設定します。

CLIに先ほど作成したec2StartStopUserユーザーのアクセスキーID/シークレットアクセスキーを設定します。
CLIに設定がされたかどうかはaws configure listで確認できます。

EC2構築

適当にEC2インスタンスを起動します。
ポリシーの"ec2:ResourceTag/タグのキー": "タグの値"で許可設定したとおりにタグを設定します。
起動したらインスタンスIDをメモっておきます。

確認

AWSCLIからコマンドを発行して、期待した設定どおりになっているかを確認します。
使用するコマンドは以下の通りです。

  • 確認
    aws ec2 describe-instance-status --instance-ids [instance-id]
  • 起動
    aws ec2 start-instances --instance-ids [instance-id]
  • 停止
    aws ec2 stop-instances --instance-ids [instance-id]

起動前の確認

c:\>aws ec2  describe-instance-status --instance-ids i-XXXXXXXXXXXXXXXXX
{
    "InstanceStatuses": []
}

起動していないので、何も情報が取れません。

起動

c:\>aws ec2 start-instances --instance-ids i-XXXXXXXXXXXXXXXXX
{
    "StartingInstances": [
        {
            "CurrentState": {
                "Code": 0,
                "Name": "pending"
            },
            "InstanceId": "i-XXXXXXXXXXXXXXXXX",
            "PreviousState": {
                "Code": 80,
                "Name": "stopped"
            }
        }
    ]
}

しばらく待つと起動します。

起動後の確認

c:\>aws ec2  describe-instance-status --instance-ids i-XXXXXXXXXXXXXXXXX
{
    "InstanceStatuses": [
        {
            "AvailabilityZone": "ap-northeast-1a",
            "InstanceId": "i-XXXXXXXXXXXXXXXXX",
            "InstanceState": {
                "Code": 16,
                "Name": "running"
            },
            "InstanceStatus": {
                "Details": [
                    {
                        "Name": "reachability",
                        "Status": "passed"
                    }
                ],
                "Status": "ok"
            },
            "SystemStatus": {
                "Details": [
                    {
                        "Name": "reachability",
                        "Status": "passed"
                    }
                ],
                "Status": "ok"
            }
        }
    ]
}

runningになっていることが確認できます。

停止

c:\>aws ec2 stop-instances --instance-ids i-XXXXXXXXXXXXXXXXX
{
    "StoppingInstances": [
        {
            "CurrentState": {
                "Code": 64,
                "Name": "stopping"
            },
            "InstanceId": "i-XXXXXXXXXXXXXXXXX",
            "PreviousState": {
                "Code": 16,
                "Name": "running"
            }
        }
    ]
}

しばらく待つと停止します。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T15:57:55+09:00

RHEL8でコマンド実行時に Failed to set locale, defaulting to C と表示される

環境

  • RHEL8（AWS EC2）

発生内容

AWS EC2でRHEL8インスタンス作成後、アップデートを実行しようとしたら行頭にFailed to set locale, defaulting to C と表示される。

$ sudo yum update
Failed to set locale, defaulting to C
Last metadata expiration check: 1:02:55 ago on Wed Aug 21 03:56:44 2019.
Dependencies resolved.
：
：

原因

  • 日本語の言語パッケージがインストールされていなかった。
$ sudo yum -y install langpacks-ja

で解決。

また、日本語の言語パッケージをインストールしたことによって、日本語のテキスト入力も可能になった。（インストール以前は文字化けしていた。）

以下、対応経過メモ

AWS EC2でRHEL8インスタンス作成後、アップデート実行するも件の現象発生。
↓
ロケール値が正しく設定されていないとそうなるらしい。
↓
現在のロケール値確認。エラーがでている。そんなファイルないって。

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=ja_JP.UTF-8
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=

↓
設定可能なロケール値も確認。ja_JP.UTF-8は見つからず。

$ locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
C.utf8
POSIX
en_AG
en_AU
en_AU.utf8
：
：

↓
インストール済みの言語パッケージ確認。ja無し

$ sudo yum list installed langpacks-*
langpacks-en.noarch

↓
インストール可能な言語パッケージ確認。ja発見

$ sudo yum list langpacks-*
:
:
langpacks-ja.noarch
:

↓
jaのパッケージインストール実行。

$ sudo yum -y install langpacks-ja

↓
再度、現在のロケール値確認。さきほどのlocale: Cannot set 〜云々のエラーが表示されなくなった。

$ locale
LANG=ja_JP.UTF-8
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=

↓
アップデート実行。Failed to set locale, defaulting to Cの表示なくなる。かつ、メッセージが日本語に置き換わる。

$ sudo yum update
メタデータの期限切れの最終確認: 1:04:39 時間前の 2019年08月21日 03時56分44秒 に実施しました。
依存関係が解決しました。
：
：

参考

第7章 言語パックのインストールおよび使用 - Red Hat Customer Portal
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/installing-using-langpacks

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T15:27:58+09:00

『レストラン口コミサイト』の制作過程

はじめに

ポートフォリオ用で制作したサイトのまとめです。
現在の進行状況を随時更新していきます。

現状

現在やっている作業

画像が編集画面で出ないので、修正中
ブックマーク機能の実装
dockerの導入

実装済み機能

レストラン投稿機能
レストラン名での検索機能
ジャンルやシーンでの検索機能
コメント機能
ユーザー登録、削除機能
投稿の削除機能

未実装機能（実装予定）

単体テスト
統合テスト
管理ユーザー機能

アプリ概要

使用した技術

今回はRails+mysql+AWS+bootstrapでアプリを作っていきます。
AWSではEC2＋S3を使用し、デプロイをしました。
credentials.yml.encのまとめ記事
AWSデプロイでのエラーまとめ

解決したい事とアプリへの想い

アプリを作ろうとしたキッカケはレストランの口コミサイトは数多くあるが、数が多すぎて大事な日にいく様なレストラン
(グランメゾン)の情報を探すのに困っていました。
みんなも同じ様な経験をしているのと、私が元調理師と言うのも合わさってかよく友達からオススメのレストランを聞かれる事があったので、私の知っているレストランをベースにまとめようとしたのがキッカケです。

出来ること、価値

オススメのレストランの投稿と、その投稿に対してコメントする事も出来ます。
簡単にコメント出来る様にしたかったのでログイン無しで出来るようにしました。
また、グランメゾンの様なレストランの場合、値段や場所よりもお店の雰囲気であったり、利用目的が優先されるので、利用シーンの登録とそこからの検索機能を実装しました。

課題と反省

①如何に投稿の質を保つか（機能面）
元々は1ユーザー1投稿しか出来ない仕様で進めていましたが、投稿しようとしたレストランが既にあった場合、どうするかと言う問題が発生してしまいました。
既にあった場合、投稿出来なくするか投稿出来て、なんらかの情報で紐づけるの二択ですがどちらも根本的解決にはなりませんでした。
投稿出来なくする場合、他の投稿をする→質を保つと言う意味でこの方式を取ろうと思ったのに、それが出来なくなってしまう
情報で紐づける→必ず共通する情報が少ない。店名は特に鮨屋や料亭に多いですが、同じ様な名前が多いです。また、鮨〇〇を〇〇と表記すると紐付けられなくなってしまいます。
なので紐づけするとしたら住所や電話番号で紐づける必要があると思いました。書いている段階で気が付いたので、その様な形で実装していきます。

②テストを後回しにしてしまった(実装面)
実際にアプリを公開する想定で進めていましたが、テストを後回しにしてしました。都度書いていくのが理想ですが、後回しにしてしまったので、次に作るときには反省を生かして書いていきたいです。

詰まった所

主にQiitaにてまとめています。
都度追加します。

まとめ

まとまり次第追加します。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T14:39:23+09:00

cognito-idpを使ってサインアップとかパスワード変更を試す

はじめに

CLIによるサインアップとパスワード変更を行いたかったので、その辺りを色々実際に使ってみつつコマンドをまとめてみました。

サインアップ

以下は電話番号、Eメール、名前をセットする例です

$ aws cognito-idp sign-up \
--client-id <アプリクライアントID> \
--ユーザ名 <ユーザ名> \
--password <パスワード> \
--user-attributes \
Name="phone_number",Value=“<電話番号>",\
Name="email",Value="<ユーザのメールアドレス>" \
Name="name",Value=<ユーザ名>

参考：sign-up — AWS CLI 1.16.222 Command Reference

ユーザ作成（管理者として）

$ aws cognito-idp admin-create-user \
--user-pool-id <ユーザプールID> \
--ユーザ名 <ユーザ名> \
--user-attributes Name="email",Value="<ユーザのメールアドレス>" \
--temporary-password <パスワード>

参考：admin-create-user — AWS CLI 1.16.222 Command Reference

ユーザのパスワード設定（管理者として）

前置き。
admin-create-userで作成した状態では、FORCE_CHANGE_PASSWORDになっています。
このステータスのユーザは自身でパスワードを設定する変更が必要という状態です。

image.png
引用：ユーザーアカウントのサインアップと確認 - Amazon Cognito

Confirmedにするためには「admin-initiate-auth」でセッション情報を取得し、取得したセッション情報を「admin-respond-to-auth-challenge」のsessionに指定します。

$ aws cognito-idp admin-initiate-auth \
--user-pool-id <ユーザプールID> \
--client-id <アプリクライアントID> \
--auth-flow ADMIN_NO_SRP_AUTH \
--auth-parameters ユーザ名=<ユーザ名>,PASSWORD=<パスワード> \

$ aws cognito-idp admin-respond-to-auth-challenge \
--user-pool-id <ユーザプールID> \
--client-id <アプリクライアントID> \
--challenge-name NEW_PASSWORD_REQUIRED \
--challenge-responses NEW_PASSWORD=<パスワード>,ユーザ名=<ユーザ名> \
--session <sessionid>

参考：admin-initiate-auth — AWS CLI 1.16.222 Command Reference / admin-respond-to-auth-challenge — AWS CLI 1.16.222 Command Reference

ちなみに、スクリプト化した時は上記が連動するように次のようにしました。

echo 'サインインしてセッションを取得します...'
aws --profile $profile cognito-idp admin-initiate-auth \
--user-pool-id $userpoolId \
--client-id $clientId \
--auth-flow ADMIN_NO_SRP_AUTH \
--auth-parameters USERNAME=$USERNAME,PASSWORD=$PASSWORD \
> result-admin-initiate-auth.txt

sessionid=`cat result-admin-initiate-auth.txt | grep Session | cut -d ":" -f 2 | tr -d '"' | sed '$s/.$//' `

aws --profile $profile cognito-idp admin-respond-to-auth-challenge \
--user-pool-id $userpoolId \
--client-id $clientId \
--challenge-name NEW_PASSWORD_REQUIRED \
--challenge-responses NEW_PASSWORD=$PASSWORD,USERNAME=$USERNAME \
--session $sessionid

パスワード忘れ

$ aws cognito-idp forgot-password \
--client-id <アプリクライアントID> \
--ユーザ名 <ユーザ名>

参考：forgot-password — AWS CLI 1.16.222 Command Reference

ユーザ削除

$ aws cognito-idp admin-delete-user \
--user-pool-id <ユーザプールID> \
--ユーザ名 <ユーザ名>

参考：admin-delete-user — AWS CLI 1.16.222 Command Reference

さいごに

誰かの参考になれば幸いです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T12:18:09+09:00

コンソールからRDSのリーダーを追加するときの注意点

要約

AWSコンソールからRDSでリーダーを追加するとき、AZを選択してからインスタンスタイプを変更するとAZの選択が"指定なし"に戻るので注意しましょう。

経緯

RDSのスペックを下げたかったので、フェイルオーバーでやろうと思ってインスタンスタイプが1段階低いリーダーを追加した。
CLI派だけどこのくらいならコンソールでいいやと思ってコンソールから実施した。
ap-northeast-1aに作りたかったのでAZを指定したつもりだったのに、ap-northeast-1cに作成されたのでやり直した。

検証

以下、やり直し時の検証

AZはap-northeast-1aが要件なので、AZを選択。
SnapCrab_RDS · AWS Console - Google Chrome_2019-8-21_10-45-48_No-00.png

インスタンスタイプを変更。
SnapCrab_RDS · AWS Console - Google Chrome_2019-8-21_10-46-10_No-00.png

AZが指定なしに戻ってる！！！！
SnapCrab_RDS · AWS Console - Google Chrome_2019-8-21_10-46-22_No-00.png

結論

コンソールから作業するときは実行前に確認しましょう。
これだからコンソールは嫌いなんだ…

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T12:11:37+09:00

Dockerを使ってAWS Lambdaのデプロイパッケージをビルドする（Python 3.7）

はじめに

https://aws.amazon.com/jp/lambda/
最近AWS Lambdaを使用する機会が増え、Python3.7のデプロイパッケージのビルド処理を汎用化したので共有します。

AWS Lambdaではライブラリなどを一つのzipファイルにまとめたものをパッケージとしてアップロードする必要があります。
Windowsで開発する場合、OSの違いからライブラリをそのままzipするだけだと動かない場合もあります。
そこで、Dockerを使ってLambdaの環境を再現したうえでパッケージを作成するという処理を実装してみました。

ソース

https://github.com/yusukey0720/lambda_packager_python
↑にいい感じにまとめてみたので参考にしてください。

使い方

※Dockerがインストールされていること。

requirements.txt

  • ここに必要なライブラリを記載。
./src/requirements.txt
numpy
pandas

lambda_function.py

  • ここに処理を記載する。
./src/lambda_function.py
def lambda_handler(event, context):
    # some functions

ビルドする

  • 下記のコマンドからビルド処理を実行する。
    • Dockerが立ち上がる
    • requirementsをインストール
    • ソースをzipする
    • distに出力される
sh build.sh

デプロイ

  • distに出力されたファイルをs3にアップロード
  • AWSコンソール画面からs3のパスを入力して保存

さいごに

やはりDockerは便利ですね。
s3のアップロードやzipの反映まで自動化できるとより便利になるなと感じました。
不明点等あればコメントください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T10:45:50+09:00

AWS CLI + JSONファイルでDynamoDBにデータを登録する

準備

DynamoDBに登録ためのJSONファイルを作成する。
・フォーマット
カラム・レコード毎にカンマでつなぐ。

2レコード登録するフォーマット
{
    "【テーブル名】": [
        {
            "PutRequest": {
                "Item": {
                    "【カラム名】": {
                       "【データ型】" : "【データ】"
                    },
                    "【カラム名】": {
                       "【データ型】" : "【データ】"
                    }
                }
            }
        },
        {
            "PutRequest": {
                "Item": {
                    "【カラム名】": {
                       "【データ型】" : "【データ】"
                    },
                    "【カラム名】": {
                       "【データ型】" : "【データ】"
                    }
                }
            }
        }
    ]
}

・サンプル

sample.json
{
    "sample-table": [
        {
            "PutRequest": {
                "Item": {
                    "id": {
                       "S" : "aaa"
                    },
                    "age": {
                       "N" : "29"
                    }
                }
            }
        },
        {
            "PutRequest": {
                "Item": {
                    "id": {
                       "S" : "bbb"
                    },
                    "age": {
                       "N" : "30"
                    }
                }
            }
        }
    ]
}

AWS CLIで登録

準備したJSONファイルを使って登録。

aws dynamodb batch-write-item --request-items file://sample.json

※JSONファイルのパスは格納場所に合わせて変えること。
　サンプルは、カレントディレクトリにJSONファイルがある前提。

注意

JSONファイルには、24個のレコードが上限。
24個を超える場合は、エラーになるのでファイルを分けて複数回コマンドを実行する必要がある。

最後に

上限があったり、JSONファイルの作成がめんどいので、boto3使ってpythonで登録するプログラムを作った方が楽かも。
ちょっとしたデータを登録するときには有効だと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T09:00:15+09:00

AWS CDKでAWS::CloudFormation::Init タイプを使ってEC2インスタンスの環境構築ができるようにしてみた

前回、AWS Cloud Development Kit(AWS CDK)を利用してEC2インスタンスを立ち上げてみたのですが、AWS CDKでAWS::CloudFormation::Initタイプが利用できるのかも確認してみました。

AWS Cloud Development Kit(AWS CDK)でEC2インスタンスを立ち上げてみる - Qiita
https://qiita.com/kai_kou/items/e35fd8c6af7dff9f2624

AWS::CloudFormation::Init タイプについては下記をご参考ください。

AWS::CloudFormation::Init タイプを使ってEC2インスタンスの環境構築ができるようにしてみた - Qiita
https://qiita.com/kai_kou/items/e1ef9fa6fb0375dcf15f

前提

  • AWSアカウントがある
  • AWS CLIが利用できる
  • Node.jsがインストール済み

実装

前回記事の実装をベースにしてAWS::CloudFormation::Initタイプの定義を追加しました。

AWS Cloud Development Kit(AWS CDK)でEC2インスタンスを立ち上げてみる - Qiita
https://qiita.com/kai_kou/items/e35fd8c6af7dff9f2624

import cdk = require('@aws-cdk/core');
import ec2 = require('@aws-cdk/aws-ec2/lib');

export class UseCdkEc2Stack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    let vpc = ec2.Vpc.fromLookup(this, 'VPC', {
      vpcId: this.node.tryGetContext('vpc_id')
    });

    const cidrIp = this.node.tryGetContext('cidr_ip');
    const securityGroup = new ec2.SecurityGroup(this, 'SecurityGroup', {
      vpc
    });
    securityGroup.addEgressRule(ec2.Peer.anyIpv4(), ec2.Port.allTraffic());
    securityGroup.addIngressRule(ec2.Peer.ipv4(cidrIp), ec2.Port.tcp(22));


    let ec2Instance = new ec2.CfnInstance(this, 'myInstance', {
      imageId: new ec2.AmazonLinuxImage().getImage(this).imageId,
      instanceType: new ec2.InstanceType('t3.small').toString(),
      networkInterfaces: [{
        associatePublicIpAddress: true,
        deviceIndex: '0',
        groupSet: [securityGroup.securityGroupId],
        subnetId: vpc.publicSubnets[0].subnetId
      }],
      keyName: this.node.tryGetContext('key_pair')
    });

    ec2Instance.addOverride('Metadata', {
      'AWS::CloudFormation::Init': {
        'config': {
          'commands': {
            'test': {
              'command': "echo $STACK_NAME test",
              'env': {
                'STACK_NAME': this.stackName
              }
            }
          },
        }
      }
    });

    let userData = ec2.UserData.forLinux();
    userData.addCommands(
      '/opt/aws/bin/cfn-init',
      `--region ${this.region}`,
      `--stack ${this.stackName}`,
      `--resource ${ec2Instance.logicalId}`
    );
    userData.addCommands('echo', 'hoge!');
    ec2Instance.userData = cdk.Fn.base64(userData.render());

    new cdk.CfnOutput(this, 'Id', { value: ec2Instance.ref });
    new cdk.CfnOutput(this, 'PublicIp', { value: ec2Instance.attrPublicIp });
  }
}

公式ドキュメントを漁ってみたものの良い情報が得られず、下記Issueを参考にしました。

Add support for AWS::CloudFormation::Init · Issue #777 · aws/aws-cdk
https://github.com/aws/aws-cdk/issues/777

ec2: cfn-init support in ASGs · Issue #1413 · aws/aws-cdk
https://github.com/aws/aws-cdk/issues/1413

feat(aws-ec2): add support for CloudFormation::Init by rix0rrr · Pull Request #792 · aws/aws-cdk
https://github.com/aws/aws-cdk/pull/792

追加した実装は以下となります。
ポイントとしてec2Instance.addOverride() でメタデータを追加してAWS::CloudFormation::Init タイプで定義を追加します。
/opt/aws/bin/cfn-init の--resource オプションでリソース名を指定するのにec2Instance を作ってからuserData を設定することで、ec2Instance.logicalId が利用できるようにしています。ベタ書きでもいいっちゃいいですね。

    ec2Instance.addOverride('Metadata', {
      'AWS::CloudFormation::Init': {
        'config': {
          'commands': {
            'test': {
              'command': "echo $STACK_NAME test",
              'env': {
                'STACK_NAME': this.stackName
              }
            }
          },
        }
      }
    });

    let userData = ec2.UserData.forLinux();
    userData.addCommands(
      '/opt/aws/bin/cfn-init',
      `--region ${this.region}`,
      `--stack ${this.stackName}`,
      `--resource ${ec2Instance.logicalId}`
    );
    userData.addCommands('echo', 'hoge!');
    ec2Instance.userData = cdk.Fn.base64(userData.render());
(略)

デプロイしてみる

> cdk deploy \
  -c vpc_id=vpc-xxxxxxxx \
  -c key_pair=cdk-test-ec2-key \
  -c cidr_ip=xxx.xxx.xxx.xxx/32

This deployment will make potentially sensitive changes according to your current security approval level (--require-approval broadening).
Please confirm you intend to make the following modifications:

Security Group Changes
┌───┬──────────────────────────┬─────┬────────────┬────────────────────┐
│   │ Group                    │ Dir │ Protocol   │ Peer               │
├───┼──────────────────────────┼─────┼────────────┼────────────────────┤
│ + │ ${SecurityGroup.GroupId} │ In  │ TCP 22     │ xxx.xxx.xxx.xxx/32 │
│ + │ ${SecurityGroup.GroupId} │ Out │ Everything │ Everyone (IPv4)    │
└───┴──────────────────────────┴─────┴────────────┴────────────────────┘
(NOTE: There may be security-related changes not in this list. See http://bit.ly/cdk-2EhF7Np)

Do you wish to deploy these changes (y/n)? y
UseCdkEc2Stack: deploying...
UseCdkEc2Stack: creating CloudFormation changeset...
 0/4 | 14:30:29 | CREATE_IN_PROGRESS   | AWS::CDK::Metadata      | CDKMetadata
 0/4 | 14:30:30 | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroup | SecurityGroup (SecurityGroupDD263621)
 0/4 | 14:30:32 | CREATE_IN_PROGRESS   | AWS::CDK::Metadata      | CDKMetadata Resource creation Initiated
 1/4 | 14:30:32 | CREATE_COMPLETE      | AWS::CDK::Metadata      | CDKMetadata
 1/4 | 14:30:35 | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroup | SecurityGroup (SecurityGroupDD263621) Resource creation Initiated
 2/4 | 14:30:37 | CREATE_COMPLETE      | AWS::EC2::SecurityGroup | SecurityGroup (SecurityGroupDD263621)
 2/4 | 14:30:39 | CREATE_IN_PROGRESS   | AWS::EC2::Instance      | myInstance
 2/4 | 14:30:40 | CREATE_IN_PROGRESS   | AWS::EC2::Instance      | myInstance Resource creation Initiated
 3/4 | 14:30:56 | CREATE_COMPLETE      | AWS::EC2::Instance      | myInstance
 4/4 | 14:30:59 | CREATE_COMPLETE      | AWS::CloudFormation::Stack | UseCdkEc2Stack

 ✅  UseCdkEc2Stack

Outputs:
UseCdkEc2Stack.PublicIp = xxx.xxx.xxx.xxx
UseCdkEc2Stack.Id = i-xxxxxxxxxxxxxxxxx

Stack ARN:
arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/UseCdkEc2Stack/72304c90-b41d-11e9-b604-129cd46a326a

デプロイできたらSSHアクセスして実行ログを確認してみます。

> ssh -i cdk-test-ec2-key \
  ec2-user@xxx.xxx.xxx.xxx


$ cat /var/log/cfn-init.log

2019-08-01 05:31:11,740 [INFO] -----------------------Starting build-----------------------
2019-08-01 05:31:11,740 [INFO] Running configSets: default
2019-08-01 05:31:11,741 [INFO] Running configSet default
2019-08-01 05:31:11,742 [INFO] Running config config
2019-08-01 05:31:11,746 [INFO] Command test succeeded
2019-08-01 05:31:11,746 [INFO] ConfigSets completed
2019-08-01 05:31:11,746 [INFO] -----------------------Build complete-----------------------


$ cat /var/log/cfn-init-cmd.log

2019-08-01 05:31:11,742 P2090 [INFO] ************************************************************
2019-08-01 05:31:11,742 P2090 [INFO] ConfigSet default
2019-08-01 05:31:11,743 P2090 [INFO] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2019-08-01 05:31:11,743 P2090 [INFO] Config config
2019-08-01 05:31:11,743 P2090 [INFO] ============================================================
2019-08-01 05:31:11,743 P2090 [INFO] Command test
2019-08-01 05:31:11,746 P2090 [INFO] -----------------------Command Output-----------------------
2019-08-01 05:31:11,746 P2090 [INFO]    UseCdkEc2Stack test
2019-08-01 05:31:11,746 P2090 [INFO] ------------------------------------------------------------
2019-08-01 05:31:11,746 P2090 [INFO] Completed successfully.


$ cat /var/log/cloud-init-output.log

(略)
Updated:
  bind-libs.x86_64 32:9.8.2-0.68.rc1.60.amzn1
  bind-utils.x86_64 32:9.8.2-0.68.rc1.60.amzn1
  kernel-tools.x86_64 0:4.14.133-88.105.amzn1
  python27-jinja2.noarch 0:2.7.2-3.16.amzn1
  vim-common.x86_64 2:8.0.0503-1.46.amzn1
  vim-enhanced.x86_64 2:8.0.0503-1.46.amzn1
  vim-filesystem.x86_64 2:8.0.0503-1.46.amzn1
  vim-minimal.x86_64 2:8.0.0503-1.46.amzn1

Complete!
Cloud-init v. 0.7.6 running 'modules:final' at Thu, 01 Aug 2019 05:31:11 +0000. Up 18.18 seconds.
hoge!
Cloud-init v. 0.7.6 finished at Thu, 01 Aug 2019 05:31:11 +0000. Datasource DataSourceEc2.  Up 18.77 seconds

ユーザーデータの/opt/aws/bin/cfn-init コマンド実行でメタデータにAWS::CloudFormation::Init タイプで指定したコマンドが実行されました。やったぜ。

まとめ

メタデータの指定について、もっと良い実装ができそうですが、ひとまずAWS CDKでもAWS::CloudFormation::Init タイプを利用できるのが確認できたので満足です。

参考

AWS Cloud Development Kit(AWS CDK)でEC2インスタンスを立ち上げてみる - Qiita
https://qiita.com/kai_kou/items/e35fd8c6af7dff9f2624

AWS::CloudFormation::Init タイプを使ってEC2インスタンスの環境構築ができるようにしてみた - Qiita
https://qiita.com/kai_kou/items/e1ef9fa6fb0375dcf15f

Add support for AWS::CloudFormation::Init · Issue #777 · aws/aws-cdk
https://github.com/aws/aws-cdk/issues/777

ec2: cfn-init support in ASGs · Issue #1413 · aws/aws-cdk
https://github.com/aws/aws-cdk/issues/1413

feat(aws-ec2): add support for CloudFormation::Init by rix0rrr · Pull Request #792 · aws/aws-cdk
https://github.com/aws/aws-cdk/pull/792

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T08:31:13+09:00

(社内勉強会) AWS サーバレスAPIハンズオン

概要

AWSにてWebAPIをサーバレスで構築するハンズオンです。

ハンズオンの内容

  1. AWSコンソールからAPIGatewayにてモックAPIを構築する
  2. AWSコンソールから手動でAPIGatewayとLambdaを構築する
  3. SAM（Serverless Application Model)により自動でAPIGatewayとLambdaを構築する（※時間が足りれば）

事前準備

  • AWSアカウント登録
  • AWS CLIインストール
  • SAM CLIインストール

AWSCLIのインストール

下記ページからWindowsのMSIをダウンロードして、インストールお願いします。
https://aws.amazon.com/jp/cli/

コマンドプロンプトにて下記コマンドを実行し、バージョンが表示されればOK

$ aws --version
aws-cli/1.16.212 Python/3.6.0 Windows/10 botocore/1.12.202
```![1.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/10978/baa42ebc-a53b-9029-4bf5-9825423fb806.png)


## SAMCLIのインストール
下記ページからWindowsのMSIをダウンロードして、インストールお願いします。
https://aws.amazon.com/jp/serverless/sam/

コマンドプロンプトにて下記コマンドを実行し、バージョンが表示されればOK

$ sam --version
SAM CLI, sam --version 0.19.0
```

1. AWSコンソールからAPIGatewayにてモックAPIを構築する

AWSマネジメントコンソールからログイン
https://console.aws.amazon.com/console/home

[APIGateway]

API作成

今すぐはじめるを選択
1. 「REST」を選択
2. 「新しいAPI」を選択
3. API名："test"
4. エンドポイントタイプ：「リージョン」
5. APIの作成ボタン押下

モデル作成

モデルを選択
1. 「作成」ボタン押下
2. モデル名："user"
3. コンテンツタイプ："application/json"
4. モデルのスキーマを下記の通り登録

{
  "$schema" : "http://json-schema.org/draft-04/schema#",
  "title" : "User Schema",
  "type" : "object",
  "properties" : {
    "userId" : { "type" : "string" },
    "userName" : { "type" : "string" }
  }
}

メソッド作成

GETメソッドを作成します。
1.「アクション」→「メソッド作成」
2. 「GET」を選択
3. 統合タイプ：Mock → 保存

統合レスポンス

  1. メソッドレスポンスのステータス：200を選択
  2. マッピングテンプレート：Content-Typeを"application/json"で登録。
  3. テンプレートの生成で「User」を選択して下記の通り登録し、保存ボタン押下
#set($inputRoot = $input.path('$'))
{
  "userId" : "1",
  "userName" : "test"
}

テスト実行

レスポンス本文が下記の通りとなればOK

{
  "userId": "1",
  "userName": "test"
}

デプロイ

アクション→APIのデプロイ
デプロイされるステージ：「新しいステージ」
ステージ名：dev
デプロイボタン押下

ステージ[dev]を選択
エクスポート：Swaggerの形式でエクスポート

補足

  • Swagger＋Postman拡張の形式でエクスポートすると、Postmanから簡単にAPIをコールできます。
  • APIクライアント開発チームにAPIスキーマとモックAPIを提供することで、APIロジック実装との並行開発が可能になります。

2. AWSコンソールから手動でAPIGatewayとLambdaを構築

[AWS Lambda]

Lambda関数作成

  1. サービスから「Lambda」を選択
  2. 関数の作成ボタンを押下
  3. 「一から作成」を選択
  4. 関数名："getUser"
  5. ランタイム：「Python3.7」 ※言語はお好みで
  6. 実行ロール：「基本的なLambdaアクセス権限でロールを作成」
  7. 関数の作成ボタンを押下

Lambda関数のテスト

  1. テストボタン押下
  2. イベント名："test"
  3. 作成ボタン押下
  4. コードを編集
import json

def lambda_handler(event, context):

    response = {
        'userId': '1234567890',
        'userName': 'hirata'
    }

    return {
        'statusCode': 200,
        'body': json.dumps(response)
    }

ファイルを上書き（Ctrl+S)して、保存ボタン押下
テストボタン押下

実行結果の下記の通りに表示されたらOK

{
  "statusCode": 200,
  "body": "{\"userId\": \"1234567890\", \"userName\": \"hirata\"}"
}

[APIGateway]

APIGatewayからLambda関数を呼ぶ設定を行う

  1. サービスから「API Gateway」を選択
  2. 先程作成したAPI「test」を選択
  3. GETメソッド選択
  4. 統合リクエストを選択
  5. 統合タイプ：「Lambda 関数」に変更
  6. Lambdaプロキシ統合の仕様：OFF
  7. Lambdaリージョン：「ap-northeast-1」を選択
  8. Lambda関数：「getUser」を入力
  9. デフォルトタイムアウトの使用：ON
  10. 保存ボタン押下

APIテスト

APIGatewayのGETメソッドのテストを実行
下記のように結果が返ってこればLambda関数が呼ばれたことが確認できます。

[レスポンス本文]

{
  "statusCode": 200,
  "body": "{\"userId\": \"22872\", \"userName\": \"hirata\"}"
}

3. SAMにより自動でAPIGatewayとLambdaを構築

SAMとは

AWS サーバーレスアプリケーションモデル
https://aws.amazon.com/jp/serverless/sam/

サーバーレスアプリケーション構築用のオープンソースフレームワーク

準備

IAMユーザー作成

AWSマネジメントコンソールにログイン
1. サービスから「IAM」を選択
2. ユーザーを選択
3. 「ユーザーを追加」ボタン押下
4. ユーザー名："SAM"
5. アクセスの種類：「プログラムによるアクセス」を選択 → 「次のステップ」ボタン押下
6. 「既存のポリシーを直接アタッチ」を選択
7. 「AWSCloudFormationFullAccess」「AWSLambdaFullAccess 」「AmazonAPIGatewayAdministrator」「IAMFullAccess」を検索してチェック→「次のステップ」ボタン押下　※
8. そのまま「次のステップ」ボタン押下
9. そのまま「ユーザーの作成」ボタン押下
10. 作成完了画面にて「.CSVのダウンロード」ボタンを押下（後で利用するので大事に保管してください）

※本来は必要最低限の権限を付与しますがハンズオンのため割愛

S3バケット作成（sam-deploy-test-{社員番号})

  1. サービスから「S3」を選択
  2. 「バケットを作成する」ボタン押下
  3. バケット名："sam-deploy-test-{社員番号}"※ → 次へボタン押下
  4. オプションの設定：そのまま次へボタン押下
  5. アクセス許可の設定：そのまま次へボタン押下
  6. 確認：「バケットを作成」ボタン押下

※同じ名前のバケットを作成できないため

ローカル環境にAWS認証情報設定

ローカル環境のコマンドプロンプトにて下記コマンド実行
先程ダウンロードしたCSVを確認してアクセスキーとシークレットキーを入力

$ aws configure
AWS Access Key ID [None]: {Access key ID}
AWS Secret Access Key [None]: {Secret Access Key}
Default region name [None]: ap-northeast-1
Default output format [None]: json

SAM実行

プロジェクト作成

$ sam init --runtime python3.7 --name test

作成されたtestフォルダに移動
testフォルダの中身を確認

hello_world ←ここにLambdaで実行するソースファイルが入っています
tests
.gitignore
event.json
README.md
template.yaml ←SAMテンプレート

デプロイパッケージ作成

$ sam package --s3-bucket sam-deploy-test-{社員番号} --output-template-file packaged.yaml --no-verify
・・・
Successfully packaged artifacts and wrote output template to file packaged.yaml.

package.yamlファイルが作成され、S3に「sam-deploy-test-{社員番号}」のバケットとその中にデプロイ用のファイルがアップロードされます。

※プロキシ経由の場合は下記実行しておく

SET HTTPS_PROXY=http://{ユーザー}:{パス}@{ホスト}:{ポート}

デプロイ

$ sam deploy --template-file packaged.yaml --stack-name api --no-verify --capabilities CAPABILITY_IAM

・・・・
Successfully created/updated stack - api

デプロイは、WEBコンソールのCloudformation画面からも可能です。

確認

スタック作成結果は、コンソールのCloudformation画面にて確認
APIGatewayのAPI、Lambda関数が作成されているのを確認

最後はお片付けとして、コンソールのCloudformation画面にてスタック削除することで、作成されたAPIとLambdaが削除されます。

おまけ

AWSのサーバレスAPI環境をコード化することでデプロイ自動化が可能

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-08-21T03:21:16+09:00

たった3コマンドでAWSリソースの見れる一覧を作成する

ある日突然Excel方眼紙好きの上司（権限を持っていてもAWSコンソール上へは頑なにサインインしようとしないものとする）から「AWSで使用しているリソースの一覧を作成せよ」との命を受けたとします。
本稿に記載の3コマンドをコピペしてExcelで見れる一覧を軽々と作成する事で、今日から貴方も出来るエンジニアに成りましょう！

環境情報

コマンドはEC2インスタンス上で実行します。
使用した環境のOS, カーネル, AWSCLI, jqコマンドのバージョンは以下の通りです。

バージョン確認
$ cat /etc/system-release
Amazon Linux release 2 (Karoo)
$ uname -a
Linux hogehuga.ap-northeast-1.compute.internal 4.14.77-81.59.amzn2.x86_64 #1 SMP Mon Nov 12 21:32:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ aws --v
aws-cli/1.15.80 Python/2.7.14 Linux/4.14.77-81.59.amzn2.x86_64 botocore/1.10.79
$ yum list installed | grep jq 
jq.x86_64                             1.5-1.amzn2.0.2                @amzn2-core

json解析用のjqコマンドがもしインストールされていなければ以下コマンド等を用いてインストールします。

# yum -y install jq

権限設定

一覧作成コマンドを使用するEC2インスタンスに、以下のポリシーがアタッチされたIAMロールを割り当てます。
※aws configureコマンドでも権限の付与は可能ですがセキュリティの観点からAWSベストプラクティスに従ってIAMロールを使用する方が良いです。

EC2のみ権限を付与する場合
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:DescribeInstances",
            "Resource": "*"
        }
    ]
}
RDSのみ権限を付与する場合
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "rds:DescribeDBInstances",
            "Resource": "*"
        }
    ]
}
Elasticacheのみ権限を付与する場合
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "elasticache:DescribeCacheClusters",
            "Resource": "*"
        }
    ]
}
上記3サービスの権限を全て付与する場合
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "rds:DescribeDBInstances",
                "elasticache:DescribeCacheClusters"
            ],
            "Resource": "*"
        }
    ]
}

一覧作成

EC2

$ aws ec2 describe-instances | jq -r '.Reservations[].Instances[]' > ec2_instance_list.json

$ echo '"Name","インスタンスの状態","インスタンスID","インスタンスタイプ","VPC ID","テナンシー","アベイラビリティゾーン","プラットフォーム","パブリック DNS (IPv4)","IPv4 パブリックIP","プライベート IP"' > ec2_instance_list.csv
$ aws ec2 describe-instances | jq -r '.Reservations[].Instances[] | [ ( .Tags[]| select(.Key == "Name") | .Value ) // "", .State.Name, .InstanceId, .InstanceType, .VpcId, .Placement.Tenancy, .Placement.AvailabilityZone, .Platform, .PublicDnsName, .PublicIpAddress, .PrivateIpAddress ] | @csv' >> ec2_instance_list.csv
$ iconv -f UTF-8 -t SHIFT_JIS ec2_instance_list.csv > ec2_instance_list-shift_jis.csv

RDS

$ aws rds describe-db-instances > rds_instance_list.json

$ echo '"DB 識別子","DB クラスター識別子","ステータス","サイズ","エンジン","エンジンバージョン","ストレージタイプ","ストレージ","IOPS","リージョンと AZ","マルチ AZ","DB サブネットグループ名","VPC ID","パラメータグループ","パフォーマンスインサイト","バックアップ保持期間","バックアップウィンドウ","マイナーバージョン自動アップグレード","メンテナンスウィンドウ","作成時刻"' > rds_instance_list.csv
$ aws rds describe-db-instances | jq -r '.DBInstances[] | [  .DBInstanceIdentifier, .DBClusterIdentifier, .DBInstanceStatus, .DBInstanceClass, .Engine, .EngineVersion, .StorageType, .AllocatedStorage, .Iops, .AvailabilityZone, .MultiAZ, .DBSubnetGroup.DBSubnetGroupName, .DBSubnetGroup.VpcId, .DBParameterGroups[].DBParameterGroupName, .PerformanceInsightsEnabled, .BackupRetentionPeriod, .PreferredBackupWindow, .AutoMinorVersionUpgrade, .PreferredMaintenanceWindow, .InstanceCreateTime ] | @csv' >> rds_instance_list.csv
$ iconv -f UTF-8 -t SHIFT_JIS rds_instance_list.csv > rds_instance_list-shift_jis.csv

Elasticache

$ aws elasticache describe-cache-clusters > elasticache_node_list.json

$ echo '"ノード名","クラスター名","ステータス","ノードのタイプ","モード","エンジンのバージョン","送信中の暗号化","保管時の暗号化","アベイラビリティーゾーン","サブネットグループ","パラメータグループ","バックアップの保存期間","バックアップウィンドウ","マイナーバージョン自動アップグレード","メンテナンスウィンドウ","クラスター作成時刻"' > elasticache_node_list.csv
$ aws elasticache describe-cache-clusters | jq -r '.CacheClusters[] | [  .CacheClusterId, .ReplicationGroupId, .CacheClusterStatus, .CacheNodeType, .Engine, .EngineVersion, .TransitEncryptionEnabled,.AtRestEncryptionEnabled, .PreferredAvailabilityZone, .CacheSubnetGroupName, .CacheParameterGroup.CacheParameterGroupName, .SnapshotRetentionLimit, .SnapshotWindow, .AutoMinorVersionUpgrade, .PreferredMaintenanceWindow, .CacheClusterCreateTime ] | @csv' >> elasticache_node_list.csv
$ iconv -f UTF-8 -t SHIFT_JIS elasticache_node_list.csv > elasticache_node_list-shift_jis.csv

それぞれのコマンドでは以下の処理を実行しています。

  1. 行目：各サービスのリソース一覧をほぼ未加工のjson形式で作成します。
    1. 作成したjsonは抜き出したい項目を手動で確認する場合に使用しました。
    2. 一覧を作成するだけなら実行不要です。
  2. 行目：一覧のヘッダーをcsvファイルの先頭行に書き込んでいます。
    1. 一覧にヘッダー行が不要であれば実行不要です。
  3. 行目：返り値(json)から欲しいデータだけをcsv形式で抜き出して、指定ファイルに追記しています。
  4. 行目：作成したcsvファイルのshift_jis版ファイルを変換して作成します。
    1. ヘッダーに日本語を使用している為にcsvをExcelで開いた際に文字化けしてしまう問題の対処です。
    2. Excelを使用しない場合やヘッダーに文字化けする文字（日本語等）を使用しない場合は実行不要です。

3行目のみ実行した場合でも一覧の作成は可能です。
取得するインスタンスIDを指定したり、インスタンスの状態によって取得するインスタンスをフィルターしたい場合は、AWS CLIを使ってEC2インスタンスの情報を取得する - Qiitaを参考に--instance-idsオプションや--filterオプションを用いてフィルタリングします。

参考

マネジメントコンソールで参照可能なサービスを制限する ｜ DevelopersIO
AWS CLIを使ってEC2インスタンスの情報を取得する - Qiita
軽量JSONパーサー『jq』のドキュメント：『jq Manual』をざっくり日本語訳してみました ｜ Developers.IO

describe-instances — AWS CLI 1.16.211 Command Reference
describe-db-instances — AWS CLI 1.16.211 Command Reference
describe-cache-clusters — AWS CLI 1.16.211 Command Reference

Linux ファイルの文字コード確認・変換 - Qiita

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧