20191112のAWSに関する記事は29件です。

AWS SAM CLI を使って、ローカルでLambda環境を構築する

はじめに

AWS SAM CLIを使って、Lambda環境をローカルで構築できると聞いて構築してみました。
チュートリアルでオプションになっているローカルで動作させるところをゴールとしています。
なので、開発者ガイドに書かれているようなIAMやS3は設定しません。AWS CLI もインストールしません。
ローカルのLambdaは、Docker コンテナで動作します。

また、この記事では下記の開発者ガイドを参考にしています。
各コマンドが何を行っているか詳細が書かれているので、気になる方は参照してみてください。

この記事は、2019年11月時点で作業記録です。

環境

  • CentOS Linux release 7.6.1810
  • Docker 19.03.1
  • python 3.7.5(Lambdaのruntimeが3.7なので揃えてみました)

AWS SAM CLI のインストール

pipでインストールします。

$ pip install aws-sam-cli
$ sam --version
SAM CLI, version 0.31.0

これだけです。

サンプルAWS SAMアプリケーションをダウンロードする

AWS SAM CLIのバージョンによって、ダウンロード時のコマンドが変わります。
SAM CLI version 0.30.0 より新しい場合は、下記のコマンドになります。

$ sam init --runtime python3.7 --dependency-manager pip --app-template hello-world --name sam-app

Quick start templates may have been updated. Do you want to re-download the latest [Y/n]: y

特に何も表示されずに、完了しました。
sam-app ディレクトリが出来ています。

$ cd sam-app/
$ ls
README.md  events  hello_world  template.yaml  tests
$ ls hello_world/
__init__.py  app.py  requirements.txt
$ ls tests/
unit
$ ls tests/unit/
__init__.py  test_handler.py

template.yaml のあるディレクトリで下記コマンドを実行します。

$ sam build
Building resource 'HelloWorldFunction'
Running PythonPipBuilder:ResolveDependencies
Running PythonPipBuilder:CopySource

Build Succeeded

Built Artifacts  : .aws-sam/build
Built Template   : .aws-sam/build/template.yaml

Commands you can use next
=========================
[*] Invoke Function: sam local invoke
[*] Package: sam package --s3-bucket <yourbucket>

ビルドされたファイルを確認します。

$ ls .aws-sam/build/
HelloWorldFunction  template.yaml

アプリケーションをローカルでテストする

テストには下記の2つの方法があります。
- APIを起動してリッスンさせる方法
- 1回だけ起動させる方法

順に試します。
なお、コンテナimageは、両方とも同じものを使用します。

APIを起動してリッスンさせる方法

下記コマンドで、起動します。
初回起動時には、「Fetching lambci/lambda:python3.7 Docker container image......」の記述の箇所でコンテナimageのダウンロードが始まります。

$ sam local start-api
Mounting HelloWorldFunction at http://127.0.0.1:3000/hello [GET]
You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions, changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template
2019-11-12 00:10:20  * Running on http://127.0.0.1:3000/ (Press CTRL+C to quit)

※ここで別ターミナルを起動してcurlを実行(詳細、後述)
Invoking app.lambda_handler (python3.7)

Fetching lambci/lambda:python3.7 Docker container image......
Mounting /home/user01/python375/sam-app/.aws-sam/build/HelloWorldFunction as /var/task:ro,delegated inside runtime container
START RequestId: ebf27a72-6c64-15f8-7ace-996a84d48b4f Version: $LATEST
END RequestId: ebf27a72-6c64-15f8-7ace-996a84d48b4f
REPORT RequestId: ebf27a72-6c64-15f8-7ace-996a84d48b4f  Duration: 6.58 ms       Billed Duration: 100 ms Memory Size: 128 MB     Max Memory Used: 18 MB
No Content-Type given. Defaulting to 'application/json'.
2019-11-12 00:11:32 127.0.0.1 - - [12/Nov/2019 00:11:32] "GET /hello HTTP/1.1" 200 -

crtl + c で停止します。

別のターミナルを起動して、curlを実行します。

$ curl http://127.0.0.1:3000/hello
{"message": "hello world"}

"hello world" が返ってきています。

待ち受けの間はコンテナが存在していません。
接続のたびにコンテナが起動しています。
確認のため、さらに別のターミナルを起動します。

$ docker container ls
CONTAINER ID        IMAGE                     COMMAND                  CREATED             STATUS                  PORTS               NAMES
005c0e19f8b4        lambci/lambda:python3.7   "/var/rapid/init --b…"   1 second ago        Up Less than a second                       quirky_merkle

※コンテナの起動時間は、非常に短いです。curlコマンド実行後に何度も連続実行して、1回くらいしか表示されません。

1つ目のターミナルで、apiを起動。
2つ目のターミナルで、curlを実行。
3つ目のターミナルで、コンテナの確認を行っています。

1回だけ起動させる方法

下記コマンドで、起動します。

$ sam local invoke "HelloWorldFunction" -e events/event.json
Invoking app.lambda_handler (python3.7)

Fetching lambci/lambda:python3.7 Docker container image......
Mounting /home/user01/python375/sam-app/.aws-sam/build/HelloWorldFunction as /var/task:ro,delegated inside runtime container
START RequestId: 22c90126-252a-1c9f-204a-a554f10d922b Version: $LATEST
END RequestId: 22c90126-252a-1c9f-204a-a554f10d922b
REPORT RequestId: 22c90126-252a-1c9f-204a-a554f10d922b  Duration: 6.08 ms       Billed Duration: 100 ms Memory Size: 128 MB     Max Memory Used: 20 MB
{"statusCode":200,"body":"{\"message\": \"hello world\"}"}

最後の行で、"hello world" が返ってきています。

最後に

クラウドにデプロイしないためなのか、想像していたより簡単に実現できました。
AWS SAM CLIコマンドリファレンス に、「sam local start-lambda」の記載がありました。
まだまだ、使い方があるようです。

今回はチュートリアルにそって実行しているだけでした。
時間を見つけて、「sam local start-lambda」あたりも試してみたいです。

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

AWSに登録したら一番最初にやること

目的

このエントリーはIAMのダッシュボード画面のセキュリティステータスを全て完了させるのが目的です。

AWSを利用するにあたって必ずしも必要な設定ではないですが、アカウントが乗っ取られたり悪用されて身に覚えのない請求が発生する可能性を最小限に止めることができます。

免責

社内カリキュラム利用を想定し、一部簡略化して記載しています。

不明な点があれば質問してください。

共同編集のリクエストもOKです。

早速始める

AWSにルートユーザーでログインする

ルートユーザーであることを確認してログインしてください。

ルートユーザーでログイン.png

AWSマネジメントコンソールからIAMを開く

「サービスを検索する」にてIAMを検索しましょう。

AWSマネジメントコンソールからIAM画面を開く.png

IAMのダッシュボード画面に遷移します。

IAMのアクセスキーをロックする

IAMはIdentity and Access Managementの略です。

ユーザーやグループ、ロール、権限等を管理できます。

ここでルートユーザーアカウントをロック(=削除)します。

※「無効化」だと後述するダッシュボードのセキュリティステータスが完了にならないため注意してください。

ルートユーザーのアクセスキーを削除する.png

IAMユーザーを作成し、管理者権限を付与する

グループを作成し、そのグループに管理者権限を付与します。

次にユーザーを作成し、権限を付与したグループにそのユーザーを割り当てます。

※直接ユーザーに管理者権限を付与することも可能ですが、ダッシュボードのセキュリティステータスが完了になりません。

グループに管理者権限を付与し、ユーザーを割り当てる

グループを作成し、AdministratorAccessのポリシーを付与してください。

Administratorsグループを作成.png

その後ユーザーを作成し、そのグループに追加してください。

ユーザーを管理者権限グループに割り当てる.png

多要素認証(MFA)を設定する

まずMFAデバイスに認証アプリをインストールしてください。

Google_Authenticatorをインストールする.png

次に表示された認証キーをAWS画面に入力してください(6桁入力が2回あります)。

認証番号を入力する.PNG

ダッシュボードに戻り、以下のようになっていれば設定完了です。

ルートユーザーからログアウトし、以降は管理者権限のユーザーでAWSを利用してください。

お疲れ様でした。

ダッシュボードのセキュリティステータスが5:5になれば完了.png

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

aws cliの煩わしいけどよく使うコマンド

region取得したい時

aws configure get region

account ID抽出したい時

$ aws sts get-caller-identity --query Account --output text

何かあれば追記予定

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

TerraformでMFAを利用しながらAWSリソースへアクセスする方法

今回は

aws-vaultを使ってみます

前提

  • 下記設定が終了していること

    • ~/.aws/config
    • ~/.aws/credentials
  • source_profileの指定をしないこと

使い方(MacOSの場合)

Brew caskでインストール

$ brew cask install aws-vault

プロファイルを作成、アクセスキーとシークレットキーを入力

$ aws-vault add PROFILE_NAME

aws-vault ls で登録したプロフィールが確認できる

$ aws-vault ls 

aws-vault から一時的なアクセスキーを渡してプロセスを実行

$ aws-vault exec home -- aws s3 ls
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Serverless FlameworkでAPI Gatewayのバイナリメディアタイプを設定する方法

表題の件、日本語文献だとserverless-plugin-custom-binaryを用いるパターンが散見されるが、
内容が古く、Version1系の説明が多い
現時点(2019/11)ではVersion2(それもリリースは2018/6)で、設定方法が変わっている

  • Version2
plugins:
  - serverless-plugin-custom-binary
custom:
  apiGateway:
    binaryMediaTypes:
      - image/jpeg

https://www.npmjs.com/package/serverless-plugin-custom-binary#usage

  • Version1
plugins:
  - serverless-plugin-custom-binary
custom:
  apigatewayBinary:
    types:
      - image/jpeg
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

爆速でyamllintを.yml形式以外のファイルにも適用する

.yml形式以外のファイルにも、yamllintを適用する方法

  1. yamllintを実行するディレクトリに下記内容の.yamllintを置く

※yamllintのデフォルト設定では、.yaml.yml.yamlintの3形式しかサポートしていないため、追加で拡張子を指定する必要があります。

---
extends: default

yaml-files:
  - '*.dig' # 今回追加したいファイル形式
  - '*.yaml'
  - '*.yml'
  - '.yamllint'

  1. $ yamllint . で動作確認する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(改善提案)

改善提案の確認

TrustedAdvisorは、運用実績から学んだベストプラクティスを活用しています。AWS環境を検査し、システムの可用性とパフォーマンスを向上させたりセキュリティギャップを埋める機会がある場合には、推奨事項を提案する。

使用ユーザー

  1. IAMユーザー

手順

  1. AWSにサインインします。

    1. アカウント、ユーザー名、パスワードを入力してサインインします。
      アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面にある「サービスを検索」にTrustedAdvisorと入力し、検索結果から《TrustedAdvisor》をクリックし、TrustedAdvisorコンソール(https://console.aws.amazon.com/trustedadvisor/)を開きます。
    image.png

  3. 『trustedadvisorコンソール』画面に各種改善提案が表示されます。
    image.png

参考サイト

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

【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(脅威監視)

脅威監視の設定

GuardDutyは、CloudTrailイベントログ、VPCフローログ、DNSログを分析し、疑わしいアクティビティーを検知するサービスです。

使用ユーザー

  1. IAMユーザー

手順

  1. AWSにサインインします。

    1. アカウント、ユーザー名、パスワードを入力してサインインします。
      アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面にある「サービスを検索」にGuardDutyと入力し、検索結果から《GuardDuty》をクリックし、GuardDutyコンソール(https://console.aws.amazon.com/guardduty/)を開きます。
    image.png

  3. AWS Configコンソールを初めて開く場合や新しいリージョンで開く場合に、次のページが表示されるので《今すぐ始める》をクリックします。
    image.png

  4. 《GuardDutyの有効化》をクリックします。
    image.png

  5. 『GuardDutyコンソール』画面に脅威監視の結果が表示されます。
    image.png

参考サイト

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

【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(リソース管理)

リソースの管理の設定

  • AWS Configは、リソース管理に役立つ機能を提供するサービスです。
  • 記録するリソースの選択、記録を保存するS3バケット、設定を確認するためのルールを設定します。

使用ユーザー

  1. IAMユーザー

手順

  1. AWSにサインインします。

    1. アカウント、ユーザー名、パスワードを入力してサインインします。
      アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面にある「サービスを検索」にConfigと入力し、検索結果から《Config》をクリックし、AWS Configコンソール(https://console.aws.amazon.com/config/)を開きます。
    image.png

  3. AWS Configコンソールを初めて開く場合や新しいリージョンで開く場合に、次のページが表示されるので《今すぐ始める》をクリックします。
    image.png

  4. 赤枠の部分を設定し、《次へ》をクリックします。
    image.png
    「グローバルリソース(AWS IAM リソースなど)を含める」は、どこか1つのリージョンのみ設定してください。

  5. ポリシーに合ったルールを選択し、《次へ》をクリックします。
    image.png

  6. 内容を確認し、《確認》をクリックします。
    image.png

  7. 設定が完了しました。

Configルールで非準拠のリソースの管理

リソースの設定が最適な設定であるかどうかを評価する。

使用ユーザー

  1. IAMユーザー

手順

  1. AWSにサインインします。

    1. アカウント、ユーザー名、パスワードを入力してサインインします。
      アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面にある「サービスを検索」にConfigと入力し、検索結果から《Config》をクリックし、AWS Configコンソール(https://console.aws.amazon.com/config/)を開きます。
    image.png

  3. 設定したルールに準拠しているかチェック結果を確認できます。
    image.png

  4. 非準拠のリソースを確認するため、「ルール名」から対象のルールをクリックします。
    image.png

  5. 非準拠のリソースが確認できます。
    image.png

Configルールで非準拠のリソースの管理

1つ以上のリソースの設定履歴を取得する。

使用ユーザー

  1. IAMユーザー

手順

  1. AWSにサインインします。

    1. アカウント、ユーザー名、パスワードを入力してサインインします。
      アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面にある「サービスを検索」にConfigと入力し、検索結果から《Config》をクリックし、AWS Configコンソール(https://console.aws.amazon.com/config/)を開きます。
    image.png

  3. 設定履歴を確認したい「リソース」から対象のリソースをクリックします。
    image.png

  4. リソースの一覧が表示されるので確認したいリソースをクリックします。
    image.png

  5. 《設定タイムライン》をクリックします。
    image.png

  6. 変更履歴のタイムラインが表示されるので確認したい履歴をクリックします。
    下にスクロールすると変更内容等が確認できます。
    image.png

参考サイト

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

【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(操作ログの取得・閲覧)

操作ログの取得

  • CloudTrailは、AWSアカウントに対して「誰が」「いつ」「何を」したかログを記録・取得できるサービスです。
  • 過去90日間より前のイベントの記録を保持する場合は、証跡情報を作成しS3にログを記録する。
  • ログを使用して、監査対応やトラブル発生時の原因調査等が可能になります。

使用ユーザー

  1. IAMユーザー

手順

  1. AWSにサインインします。

    1. アカウント、ユーザー名、パスワードを入力してサインインします。
      アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面にある「サービスを検索」にCloudTrailと入力し、検索結果から《CloudTrail》をクリックし、CloudTrailコンソール(https://console.aws.amazon.com/cloudtrail/)を開きます。
    image.png

  3. 『CloudTrailコンソール』画面のメニューから《証跡情報》をクリックします。
    image.png

  4. 《証跡の作成》をクリックします。
    image.png

  5. 赤枠の部分をポリシーに基づいて設定し、《作成》をクリックします。
    image.png

操作ログの閲覧

  • 過去90日以内のログであれば『CloudTrailコンソール』画面のイベント履歴から閲覧する。
  • 過去90日間より前のログはS3バケットから直接ダウンロードして閲覧する。

使用ユーザー

  1. IAMユーザー

手順

  1. AWSにサインインします。

    1. アカウント、ユーザー名、パスワードを入力してサインインします。
      アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面にある「サービスを検索」にCloudTrailと入力し、検索結果から《CloudTrail》をクリックし、CloudTrailコンソール(https://console.aws.amazon.com/cloudtrail/)を開きます。
    image.png

  3. 『CloudTrailコンソール』画面のメニューから《イベント履歴》をクリックします。
    image.png

  4. 『イベント履歴』画面が表示されます。フィルターで条件による抽出も可能です。
    image.png

参考サイト

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

【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(IAMユーザー設定)

MFA(Multi-Factor Authentication:多要素認証)の設定

ログイン時に多要素認証を強制するための設定します。
この設定によりパスワード漏洩のリスクを低減する事ができます。

使用ユーザー

  1. IAMユーザー

手順

  1. AWSにサインインします。

    1. アカウント、ユーザー名、パスワードを入力してサインインします。
      アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする
  2. 『IAMコンソール』画面のメニューから《ユーザー》をクリックします。
    image.png

  3. ユーザー一覧からMFAを設定するユーザーをクリックします。
    image.png

  4. 《認証情報》をクリックします。
    image.png

  5. 「サインイン認証情報」の「MFAデバイスの割り当て」の《管理》をクリックします。
    image.png

  6. 『MFAデバイスの管理』画面がでますので、《仮想MFAデバイス》が選択されている状態で《続行》をクリックします。
    image.png

  7. 『仮想MFAデバイスの設定』画面がでますので、画面の指示に従って操作をしていきます。
    image.png

    1. スマホにアプリをダウンロードします。
      一般的にはAndroid、iOSともにGoogle Authenticator(Google 認証システム) アプリを利用しますが、
      今回は、クラウドにバックアップができるのでMicrosoftのMicrosoft Authenticator アプリを利用したいと思います。
      Microsoft Authenticator アプリも時間ベースのワンタイムパスワード(TOTP)を標準サポートしているので利用可能です。
      以下のリンクよりアプリをダウンロードしてインストールします。 1
      Android版 Microsoft Authenticator アプリ
      iOS版 Microsoft Authenticator アプリ
      image.png
    2. 《QRコードの表示》をクリックします。
      image.png
    3. QRコードが表示されますのでそのままにします。1
      image.png
    4. Microsoft Authenticator アプリを起動し、『アカウント』画面を表示します。1
      image.png
    5. Android版は、『アカウント』画面の右上の《 ⁝ 》を、iOS版は右上の《+》タップします。1
      image.png
    6. Android版のみ、ドロップダウンの中から《アカウントの追加》をタップします。1
      image.png
    7. 『アカウント追加』画面の《他のアカウント(Google、Facebook など)》をタップします。1
      image.png
    8. QRコードのスキャンモードに切り替わるので表示してあるQRコードをスキャンし、アカウントを追加します。
    9. Microsoft Authenticator アプリにアカウントが追加されており、数字が表示されているのを確認します。
    10. 『仮想MFAデバイスの設定』画面の下部のMFAコード1にその数字を入力し、最大30秒待つと数字が切り替わるので、切り替わった数字をMFAコード2に入力します。
      image.png
    11. 《MFAの割り当て》をクリックします。
      image.png
    12. 登録完了の画面が表示されたら《閉じる》をクリックします。
      image.png
    13. 登録が完了し、登録内容が表示されます。
      image.png

  1. ※ 画面はAndroid版です。 

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

【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(IAMユーザーの作成)

IAM(Identity and Access Management)グループの作成

IAMユーザーに直接ポリシーを付与する事も可能だが、管理が煩雑になるためグループを作成して付与したポリシーを個人ではなくグループで管理する。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面にある「サービスを検索」にIAMと入力し、検索結果から《IAM》をクリックし、IAM コンソール(https://console.aws.amazon.com/iam/)を開きます。
    image.png

  3. 『IAMコンソール』画面のメニューから《グループ》をクリックします。
    image.png

  4. 《新しいグループの作成》をクリックします。
    image.png

  5. 「グループ名」に適当なグループ名を入力し、《次のステップ》をクリックします。
    image.png

  6. ポリシー一覧から「AdministratorAccess」のチェックボックスをチェックし、《次のステップ》をクリックします。
    image.png

  7. 内容を確認し、《グループの作成》をクリックします。
    image.png

  8. 『IAMコンソール』画面に戻ると登録したグループが表示されています。
    image.png

IAM(Identity and Access Management)ユーザーのパスワードポリシー設定

IAMユーザーのパスワードの文字の組み合わせなどの条件を設定や定期的なパスワード変更期間の設定をする。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『IAMコンソール』画面のメニューから《アカウント設定》をクリックします。
    image.png

  3. 《パスワードポリシーを変更する》をクリックします。
    image.png

  4. ポリシーに応じてチェックを付け、《変更の保存》をクリックします。
    image.png

    1. パスワードの最小文字数を強制する
      パスワードの最小文字数を指定します。(設定値:6〜128)
    2. 1文字以上のアルファベット大文字(A~Z)を必要とする
      パスワードにアルファベット大文字(A~Z)を最低1文字使用する必要があるか指定します。
    3. 1文字以上のアルファベット小文字 (a~z)を必要とする
      パスワードにアルファベット小文字(a~z)を最低1文字使用する必要があるか指定します。
    4. Require at least one number
      パスワードに数字(0~9)を最低1文字使用する必要があるか指定します。
    5. Require at least one non-alphanumeric character(!@#$%^&()_+-=[]{}|')
      パスワードに記号(!@#$%^&
      ()_+-=[]{}|')を最低1文字使用する必要があるか指定します。
    6. Enable password expiration
      パスワードの有効期限を日数で設定します。有効期限経過後はパスワード変更が必要にまります。(設定値:1~1095)
    7. Password expiration requires administrator reset
      有効期限経過後のパスワード変更が管理者しかできない(ユーザー自身での変更は不可)設定にします。この設定を有効にする前に管理者が複数ユーザー存在することを確認します。
    8. Allow users to change their own password
      ユーザーが自分自身のパスワードを変更できるか指定します。
    9. Prevent password reuse
      過去に利用したパスワードの再利用を禁止できます。(設定値:1~24)

IAM(Identity and Access Management)ユーザーの作成

ルートユーザーを極力利用しないようにするため、代わりとなる管理者用のユーザーを作成します。

このユーザーはルートユーザー同様に全ての権限を有するユーザーにします。
必要に応じて権限を変更(アクセス制限)できる所がルートユーザーとの違いになります。

管理者用ユーザー以外のユーザーを作成する場合は、必要最小限のポリシーを付与するようにしてください。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『IAMコンソール』画面のメニューから《ユーザー》をクリックします。
    image.png

  3. 《ユーザーを追加》をクリックします。
    image.png

  4. 「ユーザー名」に適当なユーザー名を入力し、「AWSマネジメントコンソールへのアクセス」のチェックボックスをチェックします。
    このユーザー名がAWSへサインインするためのユーザー名になります。
    「プログラムによるアクセス」は、後から設定できるのでここでは設定しません。
    image.png

  5. 「コンソールのパスワード」の「カスタムパスワード」を選択し、パスワードを入力する。
    「パスワードのリセットが必要」のチェックボックスのチェックを外し、《次のステップ:アクセス権限》をクリックします。1
    入力するパスワードは別途設定してあるパスワードポリシーに準拠する必要があります。
    image.png

  6. 「ユーザーをグループに追加」を選択します。
    image.png

  7. 先ほど作成したグループのチェックボックスをチェックして《次のステップ:タグ》をクリックします。
    image.png

  8. タグは設定しないので、《次のステップ:確認》をクリックします。
    image.png

  9. 内容を確認し、《ユーザーの作成》をクリックします。
    image.png

  10. 内容を確認し、《閉じる》をクリックします。
    image.png

  11. 『IAMコンソール』画面に戻ると登録したグループが表示されています。
    image.png

参考サイト


  1. 今回は自分で利用するユーザーのためこの設定にしています。 

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

【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(準拠法、管轄裁判所設定)

準拠法と管轄裁判所の変更

  • 準拠する法律を日本の法律に変更する。
  • 第一審裁判所を東京地方裁判所に変更する。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面にある「サービスを検索」にartifactと入力し、検索結果から《AWS Artifact》をクリックし、AWS Artifact コンソール(https://console.aws.amazon.com/artifact/)を開きます。
    image.png

  3. 『AWS Artifactコンソール』画面のメニューから《契約》をクリックします。
    image.png

  4. 《日本準拠法に関するAWSカスタマーアグリーメント変更契約 をダウンロードして確認する》をクリックします。
    image.png

  5. 説明が表示されるので内容を確認します。
    image.png

  6. 内容確認後、「NDA を確認済みで、同意する場合はここをチェックしてください」のチェックボックスをチェックし、《NDA に同意し、日本準拠法に関するAWSカスタマーアグリーメント変更契約 をダウンロードする》をクリックします。PDFファイルがダウンロードされます。
    image.png

  7. 「本変更契約の条件をダウンロードし確認した。」、「本変更契約の条件に同意する」、「本変更契約の条件は機密事項であること並びにAWS Artifact NDA秘密保持契約に服することを了解し、これに同意する。」のチェックボックスをチェックし、《このアカウントの日本準拠法に関するAWSカスタマーアグリーメント変更契約に同意する》をクリックします。
    image.png

  8. 契約状態がアクティブになり準拠法と管轄裁判所の変更ができました。
    image.png

参考サイト

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

【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(請求設定)

請求書のメール通知、無料利用枠接近および超過アラート通知設定

  • 請求書を指定したメールアドレス宛に毎月送付する。
  • 無料利用枠の限界に近づいた場合および超過した場合にアラートを通知する。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面の右上にある《アカウント名》をクリックします。
    image.png

  3. ドロップダウンリストが出ますので、その中から《マイ請求ダッシュボード》をクリックします。
    image.png

  4. 『請求情報とコスト管理ダッシュボード』画面の左側にある《Billingの設定》をクリックします。
    image.png

  5. 「電子メールでPDF版請求書を受け取る」、「無料利用枠の使用のアラートの受信」のチェックボックスをチェックし、Eメールアドレスに通知を受け取るEメールアドレスを入力して《設定の保存》をクリックします。
    image.png

  6. 月初3営業日くらいにPDFの請求書がEメールで送られてきます。
    image.png

予算の設定

AWSの利用料金が設定した予算(Budgets)を超過した場合や、月末時点の予測金額が超過する場合にアラートを通知する。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面の右上にある《アカウント名》をクリックします。
    image.png

  3. ドロップダウンリストが出ますので、その中から《マイ請求ダッシュボード》をクリックします。
    image.png

  4. 『請求情報とコスト管理ダッシュボード』画面の左側にある《Budgets》をクリックします。
    image.png

  5. 『AWS Budgets』画面の《予算を作成》をクリックします。
    image.png

  6. 「コスト予算」を選択し、《予算の設定》をクリックします。
    今回は初めて作る場合にお勧めのコスト予算を作成します。
    特に指定があるわけではないので好きな予算を作成してください。
    image.png

  7. 『予算の設定』画面で必要な設定を行い、《アラートの設定》をクリックします。
    image.png

    1. 名前 一覧に表示される名前になります。後で変更はできません。
    2. 間隔 予算を集計する間隔(月別、四半期別、年別)
    3. Budget Effective Dates 定期予算を選択すると、間隔で指定した期間が終わった場合に自動でカウントをリセットしてくれる。
    4. 予算額 修正されましたを選択する。 上限となる予算額を設定する。(例では$100)
    5. フィルタリング、詳細オプション デフォルトのまま。
  8. 『アラートの設定』画面で必要な設定を行い、《予算の確認》をクリックします。
    image.png

    1. アラートのしきい値 予算額の割合または実際の金額を指定できます。
    2. 連絡電子メール 複数個指定できます。
    3. 新しいアラートの追加で複数個アラートを設定できます。
  9. 内容を確認し、《作成》をクリックします。
    image.png

  10. 『AWS Budgets』画面に戻ると登録したBudgetsが表示されています。
    image.png

Cost Explorerの有効化

  • AWSの料金や使用量をグラフィカルに表示するツールです。コスト分析などに使えます。
  • 有効化してから利用するまでに最大24時間かかります。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面の右上にある《アカウント名》をクリックします。
    image.png

  3. ドロップダウンリストが出ますので、その中から《マイ請求ダッシュボード》をクリックします。
    image.png

  4. 『請求情報とコスト管理ダッシュボード』画面の左側にある《Cost Explorer》をクリックします。
    image.png

  5. 《コストエクスプローラーを有効化》をクリックします。
    image.png

参考サイト

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

【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(アカウント設定)

アカウントIDの確認

この数字でアカウントを特定します。各種問い合わせやIAMユーザーのログインで使用します。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面の右上にある《アカウント名》をクリックします。
    image.png

  3. ドロップダウンリストが出ますので、その中から《マイアカウント》をクリックします。
    image.png

  4. 「アカウント設定」の「アカウントID」を確認する。
    image.png

支払い通貨の変更

毎月の支払を円払いに変更します。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面の右上にある《アカウント名》をクリックします。
    image.png

  3. ドロップダウンリストが出ますので、その中から《マイアカウント》をクリックします。
    image.png

  4. 「お支払い通貨の設定」の《設定》をクリックします。
    image.png
    円払いに対応しているクレジットカードはVISAとMasterカードのみです。
    画像はそれ以外のカードのため設定ボタンが出ていません。
    詳細は、AWS支払の円払いへの切り替え方法についてを参照してください。

代替の連絡先の設定

AWSから受け取る通知の連絡先をカテゴリ毎(請求、操作、セキュリティ)に追加します。
この設定を行ってもルートユーザーには引き続きすべての通知が届きます。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面の右上にある《アカウント名》をクリックします。
    image.png

  3. ドロップダウンリストが出ますので、その中から《マイアカウント》をクリックします。
    image.png

  4. 「代替の連絡先」の《設定》をクリックします。
    image.png

  5. 代替の連絡先を設定したい箇所に情報を入力して《更新》をクリックします。
    image.png

  6. 代替の連絡先が設定されました。
    image.png

IAM(Identity and Access Management)ユーザーに請求情報のアクセス権付与

管理者権限を持つIAMユーザーでも請求情報にアクセスできないためできるように設定する。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面の右上にある《アカウント名》をクリックします。
    image.png

  3. ドロップダウンリストが出ますので、その中から《マイアカウント》をクリックします。
    image.png

  4. 「IAMユーザー/ロールによる請求情報へのアクセス」の《編集》をクリックします。
    image.png

  5. 「IAMアクセスのアクティブ化」のチェックボックスをチェックし、《更新》をクリックします。
    image.png

  6. IAM ユーザー/ロールによる請求情報へのアクセスが有効になりました。
    image.png

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

【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(ルートユーザー設定)

MFA(Multi-Factor Authentication:多要素認証)の設定

ログイン時に多要素認証を強制するための設定します。
この設定によりパスワード漏洩のリスクを低減する事ができます。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面の右上にある《アカウント名》をクリックします。
    image.png

  3. ドロップダウンリストが出ますので、その中から《マイセキュリティ資格情報》をクリックする。
    image.png

  4. 『セキュリティ認証情報』画面の《多要素認証(MFA)》をクリックします。
    image.png

  5. 《MFAの有効化》をクリックします。
    image.png

  6. 『MFAデバイスの管理』画面がでますので、《仮想MFAデバイス》が選択されている状態で《続行》をクリックします。
    image.png

  7. 『仮想MFAデバイスの設定』画面がでますので、画面の指示に従って操作をしていきます。
    image.png

    1. スマホにアプリをダウンロードします。
      一般的にはAndroid、iOSともにGoogle Authenticator(Google 認証システム) アプリを利用しますが、
      今回は、クラウドにバックアップができるのでMicrosoftのMicrosoft Authenticator アプリを利用したいと思います。
      Microsoft Authenticator アプリも時間ベースのワンタイムパスワード(TOTP)を標準サポートしているので利用可能です。
      以下のリンクよりアプリをダウンロードしてインストールします。 1
      Android版 Microsoft Authenticator アプリ
      iOS版 Microsoft Authenticator アプリ
      image.png
    2. 《QRコードの表示》をクリックします。
      image.png
    3. QRコードが表示されますのでそのままにします。1
      image.png
    4. Microsoft Authenticator アプリを起動し、『アカウント』画面を表示します。1
      image.png
    5. Android版は、『アカウント』画面の右上の《 ⁝ 》を、iOS版は右上の《+》タップします。1
      image.png
    6. Android版のみ、ドロップダウンの中から《アカウントの追加》をタップします。1
      image.png
    7. 『アカウント追加』画面の《他のアカウント(Google、Facebook など)》をタップします。1
      image.png
    8. QRコードのスキャンモードに切り替わるので表示してあるQRコードをスキャンし、アカウントを追加します。
    9. Microsoft Authenticator アプリにアカウントが追加されており、数字が表示されているのを確認します。
    10. 『仮想MFAデバイスの設定』画面の下部のMFAコード1にその数字を入力し、最大30秒待つと数字が切り替わるので、切り替わった数字をMFAコード2に入力します。
      image.png
    11. 《MFAの割り当て》をクリックします。
    12. 登録完了の画面が表示されたら《閉じる》をクリックします。
      image.png
    13. 『セキュリティ認証情報』画面に戻ると登録内容が表示されます。 image.png

アクセスキーの削除

アクセスキーは、AWS コマンドラインツール、AWS SDK等を利用する場合に必要になります。
このキーが悪意のある第三者に漏洩した場合に、ルートユーザーの強い権限でAWS コマンドラインツールが利用できてしまいます。
全てのリソースにアクセスできますので漏洩リスクはとても怖いものです。

ですのでAmazonでもルートユーザーは通常使用しない事が推奨されています。

ルートユーザーのアクセスキーを使用する場面もありませんので、リスクとなるキーは事前に削除しましょう。

使用ユーザー

  1. ルートユーザー

手順

  1. AWSにサインインします。

    1. Eメールアドレスとパスワードを入力してサインインします。
      ルートユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面の右上にある《アカウント名》をクリックします。
    image.png

  3. ドロップダウンリストが出ますので、その中から《マイセキュリティ資格情報》をクリックする。
    image.png

  4. 『セキュリティ認証情報』画面の《アクセスキー (アクセスキー ID とシークレットアクセスキー)》をクリックします。
    image.png

  5. アクセスキーが作成されていない事を確認します。(アカウントを作成時にはアクセスキーは作成されていないはずです)
    image.png
    作成されていた場合は、AWS アカウントのルートユーザー のアクセスキーの作成、無効化、削除を参照して削除してください。

参考サイト


  1. ※ 画面はAndroid版です。 

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

【Windowsユーザーでクラウド初心者向け】Amazon Connectでコールセンターを作る

注意

現在、こちらのドキュメントは作成中ですので随時更新されるはずです。

前振り

  • 初めてAWSのアカウントを開設してAmazon Connectを試作したのでこの知見を忘れないようにメモとして残しておくため ⁻ 同じように初めて触る人がいるかと思い何かの役に立てれば良いな

想定ユーザー

  • これまでAWSやAzureといったクラウドサービスを全く触ったことがない
  • 基本はWindowsユーザー(ADなんか触った事があると良いかも)
  • Webの知識をある程度持っている(Webシステムを作ったことがあればなお良し)
  • HTML、CSS、JavaScriptの知識をある程度持っている

なぜQiitaに投稿するの

熱い思いを文章で(長いので、時間の無い人は次の結論へ)

Amazon Connectで何かをしようと思って検索すると、たいていの事はクラスメソッド株式会社が運営するDevelopers.IOに記事があり実現方法が記載されています。

私も、参考にさせてもらって進めることができました。ありがとうございます。
しかし、HowToサイトではないので全部の手順は書いていないです。(AWSになれている人にはわかる説明がちゃんと書いてあります)
今回、Amazon Connectを利用するために初めてAWSを触ったので、書いてある説明を理解するのに色々と調べて時間がかかりました。
このままでは、調べた内容を忘れてしまうと思ったので自分の備忘録として投稿することにしました。
うまくいけば、社内での説明用資料やプレゼン用資料に使えるかななんて思ったりもしています。

なのでDevelopers.IOの記事を引用させてもらう事も多いですが、もうこれで怒られない!テキスト、スクショ、SNS埋め込み等の引用マナーまとめましたにも書いてある通り自分の記事になるようしたいと思います。

コールセンターを作る

ここからコールセンターを作るための説明をします。
作りながら機能は増やしていこうと思っています。

目的

  • 手間と費用をかけずにコールセンターに必要と思われる最低限の機能を実装して運用する。
  • お客様と自社のコールセンター担当者の双方がWin、Winの関係になれる。

機能

  • ガイダンスによる業務の選択
  • 通話内容の録音
  • 営業時間内のみ電話を受け付け、時間外は留守番電話になる。
  • お客様の電話番号の通知
  • 外線への電話転送

目次

AWSの開設

  1. AWSアカウントを作成してコンソールにサインインする
  2. AWSアカウント作成後にやった方が良い初期設定
    1. ルートユーザー設定
    2. アカウント設定
    3. 請求設定
    4. 準拠法、管轄裁判所設定
    5. IAMユーザーの作成
    6. IAMユーザー設定
    7. 操作ログの取得・閲覧
    8. リソース管理
    9. 脅威監視
    10. 改善提案

Amazon Connect構築

  1. Amazon Connectの開設

参考サイト

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

Qwiklabs(GCPとAWSのラボ環境)について

Qwiklabsとは

これ
https://www.qwiklabs.com/?locale=ja

GCPとAWSのラボ環境を一時的に払い出してくれて、ハンズオンができるサービス。

ラボ

ラボのカタログ

  • レベルや長さ、料金、言語などでフィルターかけられる
  • 無料のラボもある 例: Introduction to AWS Lambda
  • 日本語に対応しているラボもある
  • 全サービスあるわけじゃない(例えばCognito関連のラボ探したけどなかった)
  • クエストっていう「テーマに沿っていくつかラボを集めたやつ」もある。

クレジットの仕組み

https://support.google.com/qwiklabs/answer/9139480?hl=ja

チャージしたクレジットの有効期限は6ヵ月

クレジットはグループ間で共有できるらしい
https://support.google.com/qwiklabs/answer/9120705

$55で1ヶ月ラボやり放題(Advantage Subscription)
$495で1年間ラボやり放題とかもある

見た感じ、1ラボ 0〜35クレジットぐらい(1クレジット=$1 まとめて購入でディスカウントあり)

やってみた感想

むかし何かのトレーニングで初めてQWIKLABSを触ったとき、時間に追われ焦りながら終わらせたときはあんまり有用に思えなかったが、あとで再度理解するために能動的に自分でやるラボ決めてやったり、じっくり手順理解しながらやると、だいぶ理解の助けになった。

ドキュメントベースで学んだ後、さぁ手を動かすぞという時に1から自分でやるのもいいがラボ活用するのもありだなぁと思った。リソース消し忘れとか気にしなくていいし。

アウトプット

あまり触れたことのなかった「GCPの触り」と「AWSのビッグデータ周り」はQwiklabsも活用して学び、以下の資格もとることができました。

メンバー加入時のトレーニングとして

英語が苦手じゃなければ、稟議でAdvantage Subscriptionを買って適したクエストやってみてもらって
ラボのあと内容説明してもらったり、少しカスタムしたものを自分で検証アカウントに1から構築してもらうのもいいかも。

ラボ繰り返しやったり、他にも気になるラボあればできるので Advantage Subscriptionがいいと思う。

参考リンク

Qwiklabsヘルプ

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

Lambdaのデッドレターキュー(DLQ)設定は非同期呼び出しでのみ有効

はじめに

SQSをイベントソースにしてLambdaを実行する仕組みを検証している際、DLQの設定を行っているのに、実行に失敗した際のメッセージがDLQに移動しない!という状況に陥りました。

そもそもSQS側にDLQの設定があるので、どちらを利用すればいいのかというのを確かめるために検証していたのですが、少しハマったので共有します。

SQSをイベントソースにした場合のLambda呼び出しは「同期呼び出し」

これが分かっていなかったため、ずっと「非同期呼び出し」に関する説明を追っていました。

非同期呼び出しの場合、実行が失敗すると2回まで再試行を行う、という説明があるのですが、CloudwatchLogsで実行ログを確認しても再試行している様子がありません。念のため、ドキュメントで説明に使っているX-rayというサービスも使って実行のトレースをしてみましたが、実行は1度きりしか行っていないよう。

なぜ1回しか呼び出されないのか、その答えを求めて調べていると、今回の答えにたどり着きました。気づくきっかけになったのは以下の記事です。

https://qiita.com/keni_w/items/dc651c9fc794f5a8ad64

これをきっかけに公式のドキュメントでもSQSは「同期呼び出し」であることがわかり、またDLQは「非同期呼び出し」の場合のみ有効であることがわかりました。

なおAWSのサービスからLambdaを呼び出す場合は、そのサービスがどの呼び出し方をしているかを確認するのが手っ取り早いです。

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-services.html

まとめ

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

AWSアカウントを作成した際のセキュリティ設定

やったこと

ひさびさにAWSアカウントを作成する機会があったので、行ったセキュリティ関係の設定についてまとめてみました。

rootアカウントのMFA設定

  • 必須レベル
  • ユーザーパスワードだけで全てのことが出来てしまうので、作ったらMFA設定して保管

IAMの請求アクセス有効化

  • これをしないとIAMユーザーから請求情報にアクセスできない。
  • AWSは細かい従量課金を伴うため、コスト管理にIAMユーザーのチェックがあった方がいい
  • 不要なコストが発生していないかチェックが必要

課金アラートの設定

  • いくら気を付けていても、ある程度の不用意な課金は発生するので、アラート設定は必要

CloudTrailの有効化

  • API証跡は有効化しましょう。何かあったときには必須。

IAMユーザー・グループの作成

  • AWSではユーザーの使いまわしはNG。
  • 使いまわしは誰がどんな操作したかがわからなくなります。
  • 今までユーザーを共有していた方もAWSではやめましょう。
  • 退職したりした人でも操作できてしまうかもしれません。
  • 適切な権限、最小の権限を付与すべき、全員同じグループやとりあえずAdministratorAccessは×
  • アクセスキーは必要になったら作成。(デフォルト作成しない)

IAMユーザーのパスワードポリシー設定

  • 文字数や英数混在、有効期間など
  • 緩い設定をしてしまう人は必ずいます。ポリシーで制限しましょう。

IAMユーザーのMFA設定

  • 所属組織次第かもしれませんが、通常AdministratorAccessなど上位の権限を持ったユーザーはMFAアクセス必須とすべきです。
  • 個人的にはポリシーで縛るべきだと思う。

IPアドレス制限

  • AWSマネジメントコンソールはインターネット上のサービスです。
  • ということは自宅からでもアクセスできます。MFA設定してもVPN/専用線接続しても同じ。
  • なのでIAMポリシーでIPアドレス制限が必要です。(CFなど一部サービスは使えないのでその場合AssumeRoleなど検討)
  • 自分のグローバルIP以外からの操作を拒否するポリシーを持ったグループをユーザーに付与することを推奨。個別ポリシーでもOK。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS SAM]VSCodeでLambda関数をローカルで開発する

目的

AWS Lambdaはコンソール画面からエディタを利用して編集ができます。ローカルファイルをアップロードするにはzip形式でファイルをアップロードする必要がある他、そもそもブラウザが使いづらいという問題点があります。今回はAWS Toolkit for VSCodeを利用してAWS SAMによるLambda開発を行ってみることを目的とします。

自らも初学者であり、他の記事で分からなかった点を補完しながら書いているため初学者向けだと思います。

AWS SAM

AWS(Serverless Application Model)CloudFormationをサーバーレスアプリケーション用に変形したものらしく、裏ではCloudFormationが動きます。
基本的には公式ドキュメントに従えばHello Worldまでは可能です。
https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/serverless-sam-cli-install-mac.html

流れ

awscliのインストール

awscliをインストールすることでawsコマンドが使えるようになります。
pip若しくはbrewでインストールしましょう。筆者はmacユーザかつpythonの管理が面倒だったのでbrewで入れました。サイトには「pipが最も簡単な方法」 と書いてありました。

aws-sam-cliのインストール

aws-sam-cliをインストールすることでsamコマンドが使えるようになります。
pip若しくはbrewでインストールしましょう。筆者はmacユーザかつpythonの管理が面倒だったのでbrewで入れました。brew tapは非公式のパッケージをbrew対象に追加するために利用します。

brew tap aws/tap
brew install aws-sam-cli

dockerのインストール

最初にbrewでdockerをインストールしたのですが、うまく動かず結局公式サイトからdmgをDLしてインストールしました。Lambdaの動作環境を用意するために使われます。AWS Toolkitを入れてVSCodeからLambda関数を実行するときに自動でdocker環境が立ち上がります。
Install Docker Desktop for Mac

VSCodeからAWSへの接続

EXTENSION追加

VSCodeの左側のタブからAWS Toolkit for Visual Studio Codeを追加します。これで左側のタブにAWSのアイコンが表示されます。
スクリーンショット 2019-11-08 16.48.31.png

認証情報の設定

インストール後、cmd+shift+Pでawsコマンドウィンドウを表示し、Create Credentials Profileを実行します。エディタ若しくはコマンドウィンドウの指示に従い、AWSアカウントのACCESS KEYとSECRET ACCESS KEYを入力します。

このawsコマンドにより新たにAWSユーザを作成できます。これは.aws/配下にvimでcredentialsというファイルを作成または編集する操作と同じです。.aws/configファイルが存在する場合はそれと合わせて読み込まれます。
スクリーンショット 2019-11-08 16.51.52.png

AWSへ接続

AWSのアイコン→Connect to AWSをクリックします。.aws/credentialsまたは.aws/configに定義されたユーザが自動で表示されるためその中から選択します。

アプリケーションの作成

Create new SAM Applicationを選択します。
スクリーンショット 2019-11-08 17.06.33.png
次に、Runtimeに使用する言語を選択します。筆者はPython3.7を選択しました。
スクリーンショット 2019-11-08 17.06.46.png
ワークスペースとなるフォルダを選択し、アプリケーションの名前をつけます。すると自動的にtemplate.yamlが立ち上がります。

template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  test2

  Sample SAM Template for test2

# More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
Globals:
  Function:
    Timeout: 3

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Properties:
      CodeUri: hello_world/
      Handler: app.lambda_handler
      Runtime: python3.7
      Events:
        HelloWorld:
          Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
          Properties:
            Path: /hello
            Method: get

Outputs:
  # ServerlessRestApi is an implicit API created out of Events key under Serverless::Function
  # Find out more about other implicit resources you can reference within SAM
  # https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api
  HelloWorldApi:
    Description: "API Gateway endpoint URL for Prod stage for Hello World function"
    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
  HelloWorldFunction:
    Description: "Hello World Lambda Function ARN"
    Value: !GetAtt HelloWorldFunction.Arn
  HelloWorldFunctionIamRole:
    Description: "Implicit IAM Role created for Hello World function"
    Value: !GetAtt HelloWorldFunctionRole.Arn

以下のようなファイル群が生成されています。

$ tree myapp
myapp
├── README.md
├── events
│   └── event.json
├── hello_world
│   ├── __init__.py
│   ├── app.py
│   └── requirements.txt
├── template.yaml
└── tests
    └── unit
        ├── __init__.py
        └── test_handler.py

この中でhandlerはapp.pyに記載されています。requirements.txtに必要なパッケージを記載しておけばデプロイ時に自動で追加されます。

VSCodeでLambdaをローカルテスト

app.pyのハンドラ上部にRun Locally | Debug Locally | Configureの選択肢が表示されます。Run Locallyを選択すると必要なdocker環境が立ち上がり、ローカルで関数が走ります。何かの不具合があればここでエラーが表示されるため、落ち着いて対応しましょう。
スクリーンショット 2019-11-08 17.16.39.png

Preparing to run app.lambda_handler locally...
Building SAM Application...
Build complete.
Starting the SAM Application locally (see Terminal for output)
Running command: sam local invoke awsToolkitSamLocalResource --template /tmp/aws-toolkit-vscode/vsctkvGlUHf/output/template.yaml --event /tmp/aws-toolkit-vscode/vsctkvGlUHf/event.json --env-vars /tmp/aws-toolkit-vscode/vsctkvGlUHf/env-vars.json
Invoking app.lambda_handler (python3.7)
2019-11-08 17:19:07 Found credentials in shared credentials file: ~/.aws/credentials

Fetching lambci/lambda:python3.7 Docker container image......
Mounting /tmp/aws-toolkit-vscode/vsctkvGlUHf/output/awsToolkitSamLocalResource as /var/task:ro,delegated inside runtime container
START RequestId: df0da3ce-bd4d-1e44-3c27-8ac942c1a17e Version: $LATEST
END RequestId: df0da3ce-bd4d-1e44-3c27-8ac942c1a17e
REPORT RequestId: df0da3ce-bd4d-1e44-3c27-8ac942c1a17e  Duration: 5.88 ms   Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 23 MB  
{"statusCode":200,"body":"{\"message\": \"hello world\"}"}
Local invoke of SAM Application has ended.

このように出力されればOKです。なお、テストイベントにbodyを追加したい場合は、CodeLensのConfigureをクリックすると一向上の階層の.aws/templates.jsonが開き、eventが空なので要素を追加すれば渡されます。

templates.json
{
    "templates": {
        "test1/template.yaml": {
            "handlers": {
                "app.lambda_handler": {
                    "event": {
                       "bodyとか":"ここに要素を追加"
                    },
                    "environmentVariables": {}
                }
            }
        }
    }
}

VSCodeからのデプロイ

デプロイするにはS3バケットが必要になります。これは、パッケージ化した一連のコード群を配置するためです(多分)。デプロイ後にS3を覗いてもらえば何かのオブジェクトが保存されていることを確認できます。
スクリーンショット 2019-11-08 17.49.01.png

今まで同様cmd+shift+Pでウィンドウを開き、Deploy SAM Applicationを選択します。

template.yamlとリージョン、S3バケット名、Stack名を聞かれるので入力します。Stack名とは、CloudFormationにおけるリソースグループ名のようなものです。Stack名は新規の名前を入力すれ新規Stackが作成され、既存の名前を入力するとアップデートされます。

CloudFormationがリソースの作成を含むため、Create権限を持ったRoleで実行する必要があります。変更が必要な場合は、.aws/configで定義します。

Starting SAM Application deployment...
Building SAM Application...
Packaging SAM Application to S3 Bucket: {バケット名} with profile: {プロファイル名}
Deploying SAM Application to CloudFormation Stack: localDeployTest2 with profile: {プロファイル名}
Successfully deployed SAM Application to CloudFormation Stack: localDeployTest2 with profile: {プロファイル名}

このように出力されれば完了です。CloudFormation,Lambda関数,API gatewayが作成されます。ブラウザを開いてコンソールから確認してみましょう。

CloudFormationのStackを消去すると関連するリソースを全て削除することができます。便利ですね。

あとは、実際にコードを変更したらデプロイする、を繰り返せば良さそうですね。ここまでできればHello Worldできたと言ってもいいでしょう。

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

AWS CloudSearch Suggester を JSON で設定する

AWS CLI で CloudSearch の Suggester を設定しようとして、少し迷ったため、備忘録として置いておきます。

ファイルの設置

設定したいパラメータを入れた json を適当な場所に設置しておきます。

  • name.json
{
  "SuggesterName": "name",
  "DocumentSuggesterOptions": {
    "SourceField": "name",
    "FuzzyMatching": "low"
  }
}

実行

置いた Json を指定して command line で実行する。

$ aws cloudsearch define-suggester --domain-name $domain --cli-input-json file://$file

ループ処理する場合は

#!/bin/sh

domain=$1
json_files_path="../config"

if [ -z $domain ]; then
    echo "usage: mkfield <domain> <mode>"
    echo ""
    echo "domain: `aws cloudsearch list-domain-names`"
    echo ""
    exit -1
fi

for file in `\find $json_files_path -name '*.json' | sort`; do
    echo ""
    echo "############################"
    echo "run... aws cloudsearch define-suggester --domain-name $domain --cli-input-json file://$file"
    aws cloudsearch define-suggester --domain-name $domain --cli-input-json file://$file
done

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

AWS CloudSearch の Suggester を JSON で設定する

AWS CLI で CloudSearch の Suggester を設定しようとして、少し迷ったため、備忘録として置いておきます。

ファイルの設置

設定したいパラメータを入れた json を適当な場所に設置しておきます。

  • name.json
{
  "SuggesterName": "name",
  "DocumentSuggesterOptions": {
    "SourceField": "name",
    "FuzzyMatching": "low"
  }
}

実行

置いた Json を指定して command line で実行する。

$ aws cloudsearch define-suggester --domain-name $domain --cli-input-json file://$file

複数設定する場合

#!/bin/sh

domain=$1
json_files_path="../config"

if [ -z $domain ]; then
    echo "usage: mkfield <domain> <mode>"
    echo ""
    echo "domain: `aws cloudsearch list-domain-names`"
    echo ""
    exit -1
fi

for file in `\find $json_files_path -name '*.json' | sort`; do
    echo ""
    echo "############################"
    echo "run... aws cloudsearch define-suggester --domain-name $domain --cli-input-json file://$file"
    aws cloudsearch define-suggester --domain-name $domain --cli-input-json file://$file
done

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

【覚書】SQSイベント駆動でLambdaを動かす

やりたいこと

  • S3にデータを配置し、配置されたデータのイベントをSQSにpushする
  • SQSにenqueueされたイベントから、Lambdaをinvokeする
  • invokeされたLambdaで、S3に配置されたファイルを処理する

仕様の再確認

S3への権限付与

  • S3バケットにSQSへのイベント発行権限を与える。SQSのアクセス許可にプリンシパルとして加える。
{
  "Version": "2012-10-17",
  "Id": "arn:aws:sqs:us-west-2:101619051410:PracticeQueue/SQSDefaultPolicy",
  "Statement": [
    {
      "Sid": "Sid1234567890",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:us-west-2:1234567890:PracticeQueue",
      "Condition": {
        "StringEquals": {
          "aws:SourceArn": "arn:aws:s3:::your-bucket-name"
        }
      }
    }
  ]
}

Lambdaの挙動

  • LambdaはSQSキューをポーリングしている
    • キューでメッセージが利用可能になると、Lambdaは即座にメッセージを5バッチまで取ってしまうので注意
  • キューのメッセージを含むイベントで、関数を同期実行する
    • 同期実行なので、DLQの設定は不要
    • エラー時の再実行については、基本的にSQS側で扱う
  • メッセージは「バッチ」と呼ばれるひとまとまりで取得される
    • バッチサイズ(1つのバッチに含まれるメッセージの数)は、イベントソースマッピングを行う時に指定可能
    • 最大バッチサイズは10、最小バッチサイズは1
  • Lambdaは1回のポーリングで5バッチまでメッセージを取得し、Lambda関数を起動する

バッチのサンプル

{
    "Records": [
        {
            "messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
            "receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
            "body": "test",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1545082649183",
                "SenderId": "AIDAIENQZJOLO23YVJ4VO",
                "ApproximateFirstReceiveTimestamp": "1545082649185"
            },
            "messageAttributes": {},
            "md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
            "eventSource": "aws:sqs",
            "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
            "awsRegion": "us-east-2"
        },
        {
            "messageId": "2e1424d4-f796-459a-8184-9c92662be6da",
            "receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...",
            "body": "test",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1545082650636",
                "SenderId": "AIDAIENQZJOLO23YVJ4VO",
                "ApproximateFirstReceiveTimestamp": "1545082650649"
            },
            "messageAttributes": {},
            "md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
            "eventSource": "aws:sqs",
            "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
            "awsRegion": "us-east-2"
        }
    ]
}
  • 1分あたり最大60インスタンスまでバッチを読み込みできる
  • イベントソースマッピングで並列処理できるバッチの最大数は1000
  • メッセージにバッチが読み込まれると、メッセージは可視性タイムアウトに入る
    • 関数が正常にバッチを処理すると、そのメッセージをキューから削除
    • 関数が正常に終了しなかった場合は、可視性タイムアウトの後、再びメッセージが表示される
      • スロットリング
      • エラー
      • タイムアウトなど
  • 1回のポーリングで5バッチのメッセージを取得し、関数を実行する
  • ソースキューの可視性タイムアウトをLambda関数のタイムアウトの最低6倍とっておけば、Lambda関数のタイミングでキューを処理できる
    • スロットリングによってLambda関数が実行出来なかった場合、次のバッチ実行までにタイムアウト1回分の猶予がとられるらしい
      • これによって、最低でも1つ分のスロットが空いて処理が走れるようになる
  • キューの再処理ポリシーでmaxReceiveCount(メッセージ再処理回数)5に設定すれば、Lambda関数の同時実行数が1であった場合でも、同時に5個キューイングされたメッセージが、スロットリングによって喪失することはない

SQSの設定

こんな感じにするヨロシ

    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "sqs:DeleteMessage",
                "sqs:ReceiveMessage",
                "sqs:GetQueueAttributes"
            ],
            "Resource": [
                "arn:aws:sqs:us-west-2:123456789102:QueueA",
                "arn:aws:sqs:us-west-2:123456789102:QueueB"
            ]
        }
    ]
}
  • DLQは必ず設定すること
    • その後のエラーハンドリングも設計しておく
  • 可視性タイムアウトの時間と、maxReceiveCount(最大処理回数)の設定に気をつけること

パラメータの決め方

考えねばならないパラメータ

  • Lambda関数の最大同時実行数
    • 並列して走らせるLambda関数の数
    • これを超えるとスロットリングが発生し、キューの処理が遅延する
  • Lambda関数のタイムアウト時間
    • これはそのままの意味
    • 最大15分
  • SQSキューの可視性タイムアウトの時間
    • このアーキテクチャに関してはこのパラメータが、メッセージの処理がエラーになった場合のリトライまでの待機時間に相当する
      • 可視性タイムアウトを抜けて利用可能になったメッセージは、即座にポーリングされてLambda関数で走る・・・というところがポイント
    • スロットリングしてしまった場合には、これにLambda関数のタイムアウト時間分が追加される
      • これのおかげで、スロットリングによる再実行の回数を少なく抑えられるしくみ
  • SQSキューの最大再処理回数
    • 何回リトライを許容するかを決めるパラメータ

決め方

  • 並列処理数上限
    • DBに接続したりする場合はコネクション数の上限とか、相手先の負荷次第
    • 5以上にしておくと、大量のジョブを同時に受けた時に、ポーリングの都度スロットリングされなくて済む
  • 実行時間上限
    • 処理の内容見合い
    • スロットリング時、現状の処理が終了しているか否かに関わらず、タイムアウト1回分追加の待ち時間が生じるので、不必要に実行時間を長くし過ぎると、スロットリング発生時に処理が極端に滞る
  • リトライの頻度
    • 平均実行時間、並列処理数上限などを合わせて考える
    • 平均的にこれくらいの時間で終わるよな・・・という辺りの可視性タイムアウトにしておけば、まずまず処理が進んでくれるはず
  • リトライ回数の上限
    • 何回リトライしてDLQに落とすか決める
    • リトライの頻度等と合わせて考える

まとめ

  • LambdaはSQSキューをポーリングしている
    • キューでメッセージが利用可能になると、Lambdaは即座にメッセージを取得する
    • 同時に5バッチ(1バッチ=1〜10メッセージ)取得され、それぞれにLambda関数が起動する
  • ジョブの管理等(リトライ・エラーハンドリング等)はSQS側で制御する
    • 最大再処理回数
    • 可視性タイムアウト
    • DLQ
  • スロットリングが発生すると、メッセージはエラーとしてキューに残る
    • 次のポーリングは、Lambda関数のタイムアウト1回分後に再開される
    • 取得されたメッセージは可視性タイムアウトの時間を過ぎると、再取得可能になる
      • つまり、この頻度でリトライを繰り返す
    • 処理が正常終了したら、メッセージは削除される
  • メッセージのリトライ回数が少なすぎると、DLQに落ちるメッセージが増えてしまうので注意
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Text to Speech

AWS喋らせよう!(備忘録 貧乏録)

#!/usr/local/bin/python3.6
# AWS
from boto3 import Session
from botocore.exceptions import BotoCoreError, ClientError
from contextlib import closing
import os,sys,subprocess

session = Session(region_name="us-west-2")
polly = session.client("polly")
ttsdt=[
    ('Ivy'   ,"Thank you for calling. I'm sorry but I can't answer your call right now. Please leave a message at  the tone . I'll get back to you as soon as possible."),
    ('Joey'  ,"Thank you for calling. I'm sorry but I can't answer your call right now. Please leave a message at  the tone . I'll get back to you as soon as possible."),
    ('Mizuki',"お電話ありがとうございます。ただいま、電話に出ることができません。ピーッという音が鳴りましたら[発信音の後に]、メッセージをお願いします。こちらからすぐにお電話いたします。"),
    ('Takumi',"お電話ありがとうございます。ただいま、電話に出ることができません。ピーッという音が鳴りましたら[発信音の後に]、メッセージをお願いします。こちらからすぐにお電話いたします。")
]
for id,tx in ttsdt:
    print(tx)
    try:
        response = polly.synthesize_speech(Text=tx, OutputFormat="mp3", VoiceId=id)
    except (BotoCoreError, ClientError) as error:
        print(error)
        sys.exit(-1)
    if "AudioStream" in response:
        with closing(response["AudioStream"]) as stream:
            output = id+".mp3"
            try:
                with open(output, "wb") as file:
                    file.write(stream.read())
            except IOError as error:
                print(error)
                sys.exit(-1)
            print("synthesize_speech OK ->>" + output)
            subprocess.Popen(['mpg123', '-q',output ]).wait()
    else:
        print("Could not stream audio")
        sys.exit(-1)

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

Cloud9環境のセットアップメモ

Windows PCを使う必要があり、Macに慣れていて快適な環境ではなかったので、Cloud9上に作業環境を作ったメモ。
ここで作業とは、kubectlを使ったりterraformを使ったリ、シェルスクリプトを書いたリを想定。

Cloud9環境をデプロイ

AWSコンソールで、サービス > Cloud9から、「Create Environment」をクリック。
環境に名前をつけ、好みのスペックを選択。以下を選択。

項目
Name MyWorkspace
Environment type Create a new instance for environment (EC2)
Instance type m4.large (8 GiB RAM + 2 vCPU)
Platform Ubuntu Server 18.04 LTS
Cost-saving setting After 30 minutes (default)

設定値を確認して環境を作成。

IAMロールをアサイン

Cloud9は呼び出したAWSアカウントが利用可能な全てのAWSリソースに対するAWSアクションを許可する一時的なクレデンシャルで利用できるが、cloud9-で始まるロールとのインタラクションを除くIAM系は制限されている。このため、この一時的なクレデンシャルだとeksctlコマンドが失敗する。なので一時的なクレデンシャルではなくEC2インスタンスにIAMロールをアサインする。

(参考)

サービス > IAMで左のメニューからロールを選択し、「ロールの作成」をクリックし、「AWSサービス」と「EC2」を選択して次のステップ。

image.png

「AdministratorAccess」にチェックして次のステップへ。

image.png

タグはそのままにして次のステップへ。

image.png

ロールに「cloud9-admin」のような適当な名前をつけて、「ロールを作成」。

image.png

サービス > EC2で左のメニューからインスタンスを選択し、Cloud9のインスタンスを選択して、アクション > インスタンスの設定 > IAMロールの割り当て/置換を選択し、先ほど作成したIAMロールを割り当てる。

Cloud9で右上の設定アイコンから、AWS SETTINGSの「AWS managed temporary credentials」を無効にする。

image.png

Homebrewを導入

Macっぽく使いたかったので、Homebrew (Linuxbrew)を入れる。

(参考)

Homebrewのサイトに記載のコマンドを実行。

sh -c "$(curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install.sh)"

以下を実行。

test -d ~/.linuxbrew && eval $(~/.linuxbrew/bin/brew shellenv)
test -d /home/linuxbrew/.linuxbrew && eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv)
test -r ~/.bash_profile && echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.bash_profile
echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.profile

このあとの各ツールがapt-getでもbrewでもpipでも入れられたりするので、どれを使うかはいちいち迷うかもしれない。

AWS CLI

デフォルトで入っているので、aws configureコマンドを実行してリージョンだけ設定しておく。

以下のコマンドで別途導入することも可能。

pip install awscli
# brew install awscli

eksctl

eksctlをインストールする。

brew tap weaveworks/tap
brew install weaveworks/tap/eksctl

kubernetes-cliとaws-iam-authenticatorも入る。

brew install kubectx
brew install kube-ps1

.bashrcに以下を追加。

source "/home/linuxbrew/.linuxbrew/opt/kube-ps1/share/kube-ps1.sh"
KUBE_PS1_SUFFIX=') '
PS1='$(kube_ps1)'$PS1
kubeoff

デフォルトで非表示にしているが、kubeonを実行するとkube-ps1のプロンプトが表示される。

東京リージョンにEKSクラスタを作成

試しにクラスタを作ってみる。

sample1-clusterconfig.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: sample
  region: ap-northeast-1

nodeGroups:
  - name: ng
    instanceType: m5.large
    desiredCapacity: 3

このファイルを指定してクラスターを作成。

sotosugi:~/environment $ eksctl create cluster -f sample-clusterconfig.yaml
[ℹ]  eksctl version 0.7.0
[ℹ]  using region ap-northeast-1
[ℹ]  setting availability zones to [ap-northeast-1c ap-northeast-1a ap-northeast-1d]
[ℹ]  subnets for ap-northeast-1c - public:192.168.0.0/19 private:192.168.96.0/19
[ℹ]  subnets for ap-northeast-1a - public:192.168.32.0/19 private:192.168.128.0/19
[ℹ]  subnets for ap-northeast-1d - public:192.168.64.0/19 private:192.168.160.0/19
[ℹ]  nodegroup "ng" will use "ami-02e124a380df41614" [AmazonLinux2/1.14]
[ℹ]  using Kubernetes version 1.14
[ℹ]  creating EKS cluster "sample" in "ap-northeast-1" region
[ℹ]  1 nodegroup (ng) was included (based on the include/exclude rules)
[ℹ]  will create a CloudFormation stack for cluster itself and 1 nodegroup stack(s)
[ℹ]  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=ap-northeast-1 --name=sample'
[ℹ]  CloudWatch logging will not be enabled for cluster "sample" in "ap-northeast-1"
[ℹ]  you can enable it with 'eksctl utils update-cluster-logging --region=ap-northeast-1 --name=sample'
[ℹ]  2 sequential tasks: { create cluster control plane "sample", create nodegroup "ng" }
[ℹ]  building cluster stack "eksctl-sample-cluster"
[ℹ]  deploying stack "eksctl-sample-cluster"
[ℹ]  building nodegroup stack "eksctl-sample-nodegroup-ng"
[ℹ]  --nodes-min=3 was set automatically for nodegroup ng
[ℹ]  --nodes-max=3 was set automatically for nodegroup ng
[ℹ]  deploying stack "eksctl-sample-nodegroup-ng"
[✔]  all EKS cluster resources for "sample" have been created
[✔]  saved kubeconfig as "/home/ubuntu/.kube/config"
[ℹ]  adding identity "arn:aws:iam::221193251029:role/eksctl-sample-nodegroup-ng-NodeInstanceRole-QFBSLXDG07HK" to auth ConfigMap
[ℹ]  nodegroup "ng" has 0 node(s)
[ℹ]  waiting for at least 3 node(s) to become ready in "ng"
[ℹ]  nodegroup "ng" has 3 node(s)
[ℹ]  node "ip-192-168-22-44.ap-northeast-1.compute.internal" is ready
[ℹ]  node "ip-192-168-60-210.ap-northeast-1.compute.internal" is ready
[ℹ]  node "ip-192-168-67-211.ap-northeast-1.compute.internal" is ready
[ℹ]  kubectl command should work with "/home/ubuntu/.kube/config", try 'kubectl get nodes'
[✔]  EKS cluster "sample" in "ap-northeast-1" region is ready
sotosugi:~/environment $ 

クラスターを確認。

sotosugi:~/environment $ eksctl get cluster                                                                                                                                                                                                          
NAME    REGION
sample  ap-northeast-1
sotosugi:~/environment $ aws eks list-clusters
{
    "clusters": [
        "sample"
    ]
}
sotosugi:~/environment $ kubectl get node
NAME                                                STATUS   ROLES    AGE     VERSION
ip-192-168-22-44.ap-northeast-1.compute.internal    Ready    <none>   5m42s   v1.14.7-eks-1861c5
ip-192-168-60-210.ap-northeast-1.compute.internal   Ready    <none>   5m45s   v1.14.7-eks-1861c5
ip-192-168-67-211.ap-northeast-1.compute.internal   Ready    <none>   5m47s   v1.14.7-eks-1861c5
sotosugi:~/environment $ 

aws-iam-authenticatorを使った認証情報が設定されている。

sotosugi:~/environment $ kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://63DC5E16450F58024D02113D66CFE7FE.sk1.ap-northeast-1.eks.amazonaws.com
  name: sample.ap-northeast-1.eksctl.io
contexts:
- context:
    cluster: sample.ap-northeast-1.eksctl.io
    user: i-0233cb7248d878398@sample.ap-northeast-1.eksctl.io
  name: i-0233cb7248d878398@sample.ap-northeast-1.eksctl.io
current-context: i-0233cb7248d878398@sample.ap-northeast-1.eksctl.io
kind: Config
preferences: {}
users:
- name: i-0233cb7248d878398@sample.ap-northeast-1.eksctl.io
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - sample
      command: aws-iam-authenticator
      env: null
sotosugi:~/environment $ 

最近はaws-iam-authenticatorを使わなくても認証できる模様。

aws eks update-kubeconfig --name sample

Ansible

pip install ansible
# brew install ansible

Terraform

tfenvを使って入れる。

brew search tfenv
brew install tfenv
tfenv --version
tfenv list-remote
tfenv install 0.12.12

jq

apt-get install jq
# brew install jq
# pip install jq
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Apache httpdをlinuxにインストールする

環境

-Linux AWS
-iOS

コード

実行環境はAWSのLinuxサーバです

$ yum -y install httpd                   //インストール
.
.
.
完了しました!
$ sudo systemctl enable httpd.service    //自動起動の設定
$ sudo systemctl start httpd.service   //起動
$ systemctl status httpd.service
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since 火 2019-11-12 01:22:16 UTC; 2s ago
     Docs: man:httpd.service(8)
 Main PID: 4283 (httpd)
   Status: "Processing requests..."
   CGroup: /system.slice/httpd.service
           ├─4283 /usr/sbin/httpd -DFOREGROUND
           ├─4284 /usr/sbin/httpd -DFOREGROUND
           ├─4285 /usr/sbin/httpd -DFOREGROUND
           ├─4286 /usr/sbin/httpd -DFOREGROUND
           ├─4287 /usr/sbin/httpd -DFOREGROUND
           └─4288 /usr/sbin/httpd -DFOREGROUND

11月 12 01:22:16 <AWS プライベートDNS> systemd[1]: Starting The Apache HTTP Server...
11月 12 01:22:16 <AWS プライベートDNS> systemd[1]: Started The Apache HTTP Server.
$ sudo systemctl stop httpd.service       //停止

以上です

なにが言いたいかというとsudoは忘れずにね☆

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

Amazon S3でSPAをサクッと公開する

はじめに

ストレージサービスとして有名&優秀なAmazon S3ですが、実は「静的ウェブサイトホスティング」という機能を使うことで、Vue.jsやReactで作ったSPAを簡単に公開することができます。また、AWS CLI を使用することでコマンド一発でサクッとデプロイすることができます。herokufirebaseなどのPaaSが充実している昨今、あまりS3でやるメリットない気もしますが。今回はその手順についてまとめてみました。

(ちなみに私がVue.jsをよく使うのでちょくちょくVue.jsが登場しますが、Reactでも同様の操作ができるはずなので、適宜読み替えていただければと思います。)

お値段

まず一番大事なお金の話から。
S3の料金は「利用したストレージの容量」「リクエスト件数」「リクエストに対するデータ送信量」の3軸で計算されます。

ストレージ料金
最初の 50 TB/月 0.025USD/GB
リクエスト料金
PUT、COPY、POST、または LIST リクエスト リクエスト 1,000 件あたり 0.0047USD
GET、SELECT および他のすべてのリクエスト リクエスト 1,000 件あたり 0.00037USD
データ転送料金
1 GB まで/月 0.00USD/GB
次の 9.999 TB/月 0.114USD/GB

料金 - Amazon S3 | AWSより一部抜粋

例えば、配信するコンテンツのデータサイズが1MB、リクエスト件数が100件/日の場合、
ストレージ料金:0.000025USD
リクエスト料金:0.00111USD
データ転送料金:0.228USD
で、合計約 0.229USD/月 (日本円で約 25.19円/月)です。ばちくそ安いですね。

アカウント開設から1年以内の無料枠を利用すればほぼ0円に抑えられると思います。
※参考 - AWS クラウド無料利用枠

SPAの準備

各フレームワークでのビルドを実行し、
index.htmlと各フォルダ(css/js/img等)が揃っている状態にしましょう。
スクリーンショット 2019-11-12 9.28.31.png

ちなみにVue.jsでのプロジェクト開始方法およびビルド方法はこちらの記事(Vue CLI スタートガイド)にまとめてありますので、フロントフレームワークを全く触ったことないという方はこちらを参考にしてみてください。

S3用のIAMユーザ作成

AWSルートアカウントの作成

AWSを初めて使うという方はAWSルートアカウントを作成しましょう。
こちらを参考にすると良いと思います。
AWS アカウント作成の流れ | AWS

S3用のIAMユーザの作成

ルートアカウントは全権限アカウントのため全てのAWSリソースへのアクセスができてしまいます。このルートアカウントで作業を続けることはセキュリティ上よろしくないので、S3のみ使用可能なIAMユーザを別途作成し、今後の作業はこのS3用IAMユーザで行います。

まずルートアカウントでログインし、マネジメントコンソールからIAMへ移動します(検索バーで「iam」と打てば出てきます)。
スクリーンショット 2019-11-10 22.48.28.png

「ユーザー」メニューを選択すると、作成したIAMユーザの一覧が表示されます。
今回は新規でユーザを作成するので、青色ボタンの「ユーザーを追加」をクリックしましょう。
スクリーンショット 2019-11-10 22.52.02.png

IAMユーザを作成するための設定画面が表示されます。

  • ユーザー名は任意の名前で構いません(公開しようとしているSPA用のIAMユーザであることが分かるネーミングだと良いです)
  • 「AWS マネジメントコンソールへのアクセス」にチェックを入れ、ログインパスワードを設定しましょう
    スクリーンショット 2019-11-10 23.05.31.png

  • 「既存のポリシーを直接アタッチ」から、AmazonS3FullAccessを選択し、チェックを入れましょう
    スクリーンショット 2019-11-10 23.10.52.png

それ以外はデフォルトの設定で問題ありません。

IAMユーザの作成が完了すると一覧に表示されるので、問題なく作成されているか確認しましょう。
スクリーンショット 2019-11-10 23.19.27.png

IAMユーザの作成が完了したら、早速ログインしてみましょう。
右上にIAMユーザ名 @ アカウント名と表示されていれば問題なくログインできています。
スクリーンショット 2019-11-11 9.57.50.png

S3以外のサービスへのアクセスがブロックされているか確認するために、試しにIAMを開いてみましょう。
先ほどIAMユーザを作成した画面に移動しても「アクセス権限が必要です」と表示され、ユーザを新規作成できないようになっているはずです。
スクリーンショット 2019-11-11 10.01.22.png

このように、利用用途ごとにIAMユーザを作成してAWSサービスへの権限を切り分け、意図しない操作が実行されないようにしましょう。

S3でSPAを公開

先ほどログインしたS3用IAMユーザで作業を進めます。

バケットの作成

S3の画面へ移動し、青色の「+バケットを作成する」ボタンをクリックしましょう。
バケット作成に際しての設定画面が表示されるので、情報を入力しましょう。

  • バケット名:任意の文字で構いません。ここで設定したバケット名が後ほど静的ホスティングする際のURLの一部として使われるので、それっぽい名前を付けましょう。
  • リージョン:これも任意で構いませんが、「アジアパシフィック(東京)」を選択するのが無難です。 スクリーンショット 2019-11-11 10.23.26.png

それ以外の設定は一旦デフォルトのままで問題ないです。

バケットが作成されるとバケット一覧に表示されるようになります。
スクリーンショット 2019-11-11 10.31.27.png

コンテンツのアップロード

バケット名をクリックするとバケットの詳細画面に遷移することができます。
青色の「アップロード」ボタンをクリックし、公開したいSPAの各ファイル(index.htmlとcss/js/imgフォルダ等)をローカルからアップロードしましょう。
初回アップロード時にバケットの設定について色々と聞かれますが、全てデフォルトで問題ないです。
無事アップロードが完了するとこのような画面になると思います。
スクリーンショット 2019-11-11 10.49.53.png

静的ウェブサイトホスティング機能の設定

「プロパティ」タブへ移動し、「Static website hosting」の設定を行います。

  • 「このバケットを使用してウェブサイトをホストする」にチェックを入れます
  • 「インデックスドキュメント」にindex.htmlを指定します スクリーンショット 2019-11-11 10.52.54.png

上記の設定が完了したら「保存」ボタンをクリックしましょう。

なお、この画面で表示されている「エンドポイント」のURLがウェブサイトへのアクセス用URLになります。が、今の状態でこのURLにアクセスしようとしても403エラーが返ってきてしまいます。URLでのアクセスを許可するために、次の章で説明するバケットポリシーを設定しましょう。
スクリーンショット 2019-11-11 11.00.11.png

バケットポリシーの設定

S3に格納したオブジェクトが不用意にネットに晒されないよう、デフォルトでは外部からS3バケットへのアクセスは全て拒否するようになっています。先ほど403エラーが返ってきたのもそのためです。正しくWebページを表示させるためにはURLによる外部からのリクエストを明示的に許可する必要があります。

アクセス制御に関することは「アクセス制御」タブで行います。

まず、「ブロックパブリックアクセス」を開きます。「編集」をクリックし、以下の設定を行います。

  • 「パブリックアクセスをすべてブロック」のチェックを外します
  • 下から2つ目、「新しいパブリックバケットポリシーを介して...」のチェックを外します
  • 一番下、「任意のパブリックバケットポリシーを介して...」のチェックを外します スクリーンショット 2019-11-11 22.28.31.png

これでバケットポリシーによるアクセス許可設定が有効になります。ここの設定を行わないと、いくらバケットポリシーで許可の設定を行ってもブロックされてしまうので注意しましょう。

次に「バケットポリシー」を開き、エディタ欄に以下のJSONをバケット名を置き換えて貼り付けましょう。
このJSONはsample-hosting-kiyokiyoバケットへのGetリクエストを許可するバケットポリシーです。AWS公式チュートリアルのものをそのまま抜粋しました。バケット名の部分のみ、自分が作成したバケット名に置き換えるのを忘れないようにしましょう。

{
   "Version":"2012-10-17",
   "Statement":[{
    "Sid":"PublicReadForGetBucketObjects",
         "Effect":"Allow",
      "Principal": "*",
       "Action":["s3:GetObject"],
       "Resource":["arn:aws:s3:::sample-hosting-kiyokiyo/*"
       ]
     }
   ]
 }

これで外部からS3に格納したファイルを取得できるようになりました。
先ほど403エラーが返ってきたURLでアクセスし直すと、今度は正しくWebページが表示されるようになっているはずです。
スクリーンショット 2019-11-11 22.45.49.png

S3へのデプロイコマンドを作る

上記の手順でWebページの公開はできるようになりましたが、Webページを更新するたびにIAMユーザでログインし、S3バケットに格納してあるファイルを削除して、ローカルにある新しいファイルをアップロードし直す、というのはかなり面倒です。Vue.jsでは
npm run serveでローカルサーバーを起動し、
npm run buildでビルドを行うことができます。
それと同じノリで、
npm run deployで、S3へのデプロイができるよう設定を組みましょう。

AWS CLI を使用する

AWS CLI を使うと、ターミナル等のコマンドラインツールからAWSサービスを操作できるようになります。これを利用して、S3上の対象バケットにあるファイルを削除し、ローカルにある新規ファイルをアップロードするスクリプトを組みます。

こちらの記事でAWS CLI を使うための手順がまとめられているので参考にしてみてください。
【初心者向け】MacユーザがAWS CLIを最速で試す方法 | Developers.IO

かいつまんで説明しますと、

1:まずpipをインストールします(Python3.4以降であればPythonのインストールと同時に使えるそうです)。pip -Vと打ってバージョンが表示されれば問題ないです。

$ pip -V
pip 19.3.1 from /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pip (python 3.7)

2:次にAWS CLI をインストールします

$ pip install awscli

3: ルートアカウントでS3用IAMユーザのアクセスキーとシークレットアクセスキーを生成・取得します。IAMメニューで先ほど作成したS3用IAMユーザを選択し、「認証情報」タブの「アクセスキーの作成」ボタンをクリックします。アクセスキーとシークレットアクセスキーが表示されるので、手元に控えておきましょう。
スクリーンショット 2019-11-11 23.24.42.png

4:ターミナルにaws configureと入力しS3を操作するための設定を行います。Access Key IDSecret Access Keyに先ほど取得した情報を入力しましょう。Default regionはS3バケットで指定したリージョン(アジアパシフィック(東京)の場合はap-northeast-1)を入力しましょう。Default output formatはとりあえずtextで問題ありません。

$ aws configure
AWS Access Key ID [None]: XXXX
AWS Secret Access Key [None]: XXXXXXXX
Default region name [None]: ap-northeast-1
Default output format [None]: text

動作確認として、aws s3 lsでS3に登録しているバケットが一覧表示されればOKです。

$ aws s3 ls
2019-11-11 22:45:22 sample-hosting-kiyokiyo

デプロイ用のシェルスクリプトを組む

index.html等が格納されているディレクトリをdistとします。
distと同じ階層にデプロイ用のスクリプトを記載したdeploy-s3.shを配置します。
ディレクトリ構造のイメージはこんな感じです。

(any directory)
 ├dist/
 │ ├css/
 │ ├img/
 │ ├js/
 │ └index.html
 └deploy-s3.sh

deploy-s3.shの中身はこんな感じで書きます。

deploy-s3.sh
#!/bin/sh

aws s3 rm s3://sample-hosting-kiyokiyo/ --recursive
aws s3 cp dist s3://sample-hosting-kiyokiyo/ --recursive

1行目はシェルスクリプトを走らせるためのおまじないです。詳しく知りたい方はこちらの記事(#!/bin/sh は ただのコメントじゃないよ! Shebangだよ!)とかが参考になると思います。
2行目ではsample-hosting-kiyokiyoバケットの中身を再帰的(--recursive)に削除(rm)しています。
3行目ではdistディレクトリの中身をsample-hosting-kiyokiyoバケットにコピー(cp)しています。

AWS CLI でできることはこちらのAWS CLI Command Referenceにまとまっているので、他のスクリプトを走らせたい方は調べてみてください。

デプロイ用コマンドを作る

最後に、npm run deployと入力したら先ほど作成したdeploy-s3.shが呼び出されるようにします。
npm runコマンドはpackage.jsonscriptsブロックで設定できます。
"deploy": "bash deploy-s3.sh"をscriptsブロック内に追加しましょう。

package.json
{
  (省略)
  "scripts": {
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build",
    "lint": "vue-cli-service lint",
    "deploy": "bash deploy-s3.sh"
  },
  (省略)
}

これで作業としては完了です。
試しにローカルでの変更をS3にデプロイできるか確かめてみましょう。

まず、ローカルで適当に変更を行います。
サンプルとして今回はとりあえずApp.vueのHelloWorldタグを以下のように変えてみます。

(変更前)
<HelloWorld msg="Welcome to Your Vue.js App"/>
(変更後)
<HelloWorld msg="Hi! My name is Kiyokiyo! Nice to meet you!"/>

ビルドコマンドを走らせます。

$ npm run build

これでローカルのdistディレクトリ以下に必要なファイルが揃いました。

最後にデプロイコマンドを走らせます。

$ npm run deploy

S3上のファイルがdeleteされ、ローカルのファイルがS3にアップロードされたことが、ターミナルの出力からも分かると思います。

WebページのURLにアクセスするとしっかり変更が反映されていますね。
スクリーンショット 2019-11-12 9.17.36.png

おわりに

これでローカルで作成していた静的ウェブサイトを公開できるようになりました。
デプロイもコマンド一発で簡単にできるようになったので、開発速度もかなり向上したんじゃないでしょうか。

個人的な今後としては、LambdaやDynamoDBを利用したサーバーレスAPIとの通信にチャレンジしてみたいと思います。

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

【初心者】AWS VPC Traffic Mirroring を使ってみる

目的

  • オンプレ時代にネットワークにTAPを入れてwireshark等でパケットキャプチャするような仕事があったが、同じようなことをAWSでできると聞いたため、どんなものかを確認してみることにした。

VPC Traffic Mirroring とは(自分の理解)

  • 特定のENIを通るトラフィックをミラーリングして、別のENIもしくはNLBに出力できる。

やったこと

  • インスタンス1(Amazon Linux2) と インスタンス2(WS2019) を作成する。インスタンス2には、RDP用のENIとミラーリングを受ける用のENIの2つをアタッチする。
  • インスタンス1にアタッチしたENIをミラーリングのSource、インスタンス2にアタッチしたENIをミラーリングのTargetに設定する。
  • インスタンス1にssh接続する。そのパケットをインスタンス2のwiresharkでキャプチャして、sshの通信を表示する。

構成図

vpc-trafficmirror.png

作業手順

インスタンス作成

  • インスタンス1(Amazon Linux2),インスタンス2(WS2019) を作成する。VPC Traffic Mirroringを行うには、SourceとなるENIをアタッチするインスタンスがNitro世代である必要あり(2019/11時点)。そのため、今回はインスタンス1は、t3.nanoを使用する。インスタンス2は何でもよい。
  • インスタンス2には追加のENIをアタッチする。追加したENIはOS上ではethernet 3として認識された。
  • インスタンス2にWireshark(パケットキャプチャ用ツール)をインストールする。

VPC Traffic Mirroringの設定

VPCのメニュー画面にて、以下の順で設定を行う。

  • Targetの設定: 
    • ミラーリングの出力先となるENIもしくはNLBをTargetとして設定する。
    • 今回は出力先はインスタンス2の追加ENI(RDPに使わないほう)を指定する。
  • Filterの設定: 
    • Sourceのトラフィックに対し、ミラーリングに出力させる前にFilterをかけることができる。
    • 今回はtcp全てを取得するよう設定する。
  • Sessionの設定: 
    • 「SourceのENI」、「Filter」、「Target」の3つを組み合わせて、Traffic MirroringのSessionを作成する。
    • 今回はSourceはインスタンス1のENIとし、FilterとTargetは先に作ったものを使用する。
    • ミラーリングを行う際、元のパケットがVXLANでカプセル化される。VXLANのVNI(識別用ID)が自動設定される。

ssh トラフィックのミラーリングとパケットキャプチャ

  • インスタンス2でWiresharkを起動し、ethernet 3の通信をキャプチャする設定にした上で、手元のPCからインスタンス1へssh接続を行う。

gamen04a.png

  • x.x.x.233(手元のPC)から、10.0.1.249(インスタンス1のENI)へのssh通信が、インスタンス2にてキャプチャできている。また、パケットがVXLANでカプセル化されていることも確認できる。

所感

  • 今までNetwork型IDSはAWSには設置不可という考え方だったが、TargetとしてIDSを指定すればそれも可能になりそう。

参考

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