- 投稿日:2019-11-12T23:33:43+09:00
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.pytemplate.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」あたりも試してみたいです。
- 投稿日:2019-11-12T23:30:50+09:00
AWSに登録したら一番最初にやること
目的
このエントリーはIAMのダッシュボード画面のセキュリティステータスを全て完了させるのが目的です。
AWSを利用するにあたって必ずしも必要な設定ではないですが、アカウントが乗っ取られたり悪用されて身に覚えのない請求が発生する可能性を最小限に止めることができます。
免責
社内カリキュラム利用を想定し、一部簡略化して記載しています。
不明な点があれば質問してください。
共同編集のリクエストもOKです。
早速始める
AWSにルートユーザーでログインする
ルートユーザーであることを確認してログインしてください。
AWSマネジメントコンソールからIAMを開く
「サービスを検索する」にて
IAM
を検索しましょう。IAMのダッシュボード画面に遷移します。
IAMのアクセスキーをロックする
IAMは
Identity and Access Management
の略です。ユーザーやグループ、ロール、権限等を管理できます。
ここでルートユーザーアカウントをロック(=
削除
)します。※「
無効化
」だと後述するダッシュボードのセキュリティステータスが完了にならないため注意してください。IAMユーザーを作成し、管理者権限を付与する
グループを作成し、そのグループに管理者権限を付与します。
次にユーザーを作成し、権限を付与したグループにそのユーザーを割り当てます。
※直接ユーザーに管理者権限を付与することも可能ですが、ダッシュボードのセキュリティステータスが完了になりません。
グループに管理者権限を付与し、ユーザーを割り当てる
グループを作成し、
AdministratorAccess
のポリシーを付与してください。その後ユーザーを作成し、そのグループに追加してください。
多要素認証(MFA)を設定する
まずMFAデバイスに認証アプリをインストールしてください。
次に表示された認証キーをAWS画面に入力してください(6桁入力が2回あります)。
ダッシュボードに戻り、以下のようになっていれば設定完了です。
ルートユーザーからログアウトし、以降は管理者権限のユーザーでAWSを利用してください。
お疲れ様でした。
- 投稿日:2019-11-12T21:26:14+09:00
aws cliの煩わしいけどよく使うコマンド
- 投稿日:2019-11-12T21:13:59+09:00
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
- 投稿日:2019-11-12T20:31:09+09:00
Serverless FlameworkでAPI Gatewayのバイナリメディアタイプを設定する方法
表題の件、日本語文献だと
serverless-plugin-custom-binary
を用いるパターンが散見されるが、
内容が古く、Version1系の説明が多い
現時点(2019/11)ではVersion2(それもリリースは2018/6)で、設定方法が変わっている
- Version2
plugins: - serverless-plugin-custom-binary custom: apiGateway: binaryMediaTypes: - image/jpeghttps://www.npmjs.com/package/serverless-plugin-custom-binary#usage
- Version1
plugins: - serverless-plugin-custom-binary custom: apigatewayBinary: types: - image/jpeg
- 投稿日:2019-11-12T20:05:38+09:00
爆速でyamllintを.yml形式以外のファイルにも適用する
- 投稿日:2019-11-12T19:50:20+09:00
【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(改善提案)
改善提案の確認
TrustedAdvisorは、運用実績から学んだベストプラクティスを活用しています。AWS環境を検査し、システムの可用性とパフォーマンスを向上させたりセキュリティギャップを埋める機会がある場合には、推奨事項を提案する。
使用ユーザー
- IAMユーザー
手順
AWSにサインインします。
- アカウント、ユーザー名、パスワードを入力してサインインします。
アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする『AWSマネジメントコンソール』画面にある「サービスを検索」にTrustedAdvisorと入力し、検索結果から《TrustedAdvisor》をクリックし、TrustedAdvisorコンソール(https://console.aws.amazon.com/trustedadvisor/)を開きます。
参考サイト
- 投稿日:2019-11-12T19:49:53+09:00
【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(脅威監視)
脅威監視の設定
GuardDutyは、CloudTrailイベントログ、VPCフローログ、DNSログを分析し、疑わしいアクティビティーを検知するサービスです。
使用ユーザー
- IAMユーザー
手順
AWSにサインインします。
- アカウント、ユーザー名、パスワードを入力してサインインします。
アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする『AWSマネジメントコンソール』画面にある「サービスを検索」にGuardDutyと入力し、検索結果から《GuardDuty》をクリックし、GuardDutyコンソール(https://console.aws.amazon.com/guardduty/)を開きます。
AWS Configコンソールを初めて開く場合や新しいリージョンで開く場合に、次のページが表示されるので《今すぐ始める》をクリックします。
参考サイト
- 投稿日:2019-11-12T19:49:07+09:00
【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(リソース管理)
リソースの管理の設定
- AWS Configは、リソース管理に役立つ機能を提供するサービスです。
- 記録するリソースの選択、記録を保存するS3バケット、設定を確認するためのルールを設定します。
使用ユーザー
- IAMユーザー
手順
AWSにサインインします。
- アカウント、ユーザー名、パスワードを入力してサインインします。
アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする『AWSマネジメントコンソール』画面にある「サービスを検索」にConfigと入力し、検索結果から《Config》をクリックし、AWS Configコンソール(https://console.aws.amazon.com/config/)を開きます。
AWS Configコンソールを初めて開く場合や新しいリージョンで開く場合に、次のページが表示されるので《今すぐ始める》をクリックします。
赤枠の部分を設定し、《次へ》をクリックします。
「グローバルリソース(AWS IAM リソースなど)を含める」は、どこか1つのリージョンのみ設定してください。設定が完了しました。
Configルールで非準拠のリソースの管理
リソースの設定が最適な設定であるかどうかを評価する。
使用ユーザー
- IAMユーザー
手順
AWSにサインインします。
- アカウント、ユーザー名、パスワードを入力してサインインします。
アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする『AWSマネジメントコンソール』画面にある「サービスを検索」にConfigと入力し、検索結果から《Config》をクリックし、AWS Configコンソール(https://console.aws.amazon.com/config/)を開きます。
Configルールで非準拠のリソースの管理
1つ以上のリソースの設定履歴を取得する。
使用ユーザー
- IAMユーザー
手順
AWSにサインインします。
- アカウント、ユーザー名、パスワードを入力してサインインします。
アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする『AWSマネジメントコンソール』画面にある「サービスを検索」にConfigと入力し、検索結果から《Config》をクリックし、AWS Configコンソール(https://console.aws.amazon.com/config/)を開きます。
参考サイト
- 投稿日:2019-11-12T19:43:24+09:00
【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(操作ログの取得・閲覧)
操作ログの取得
- CloudTrailは、AWSアカウントに対して「誰が」「いつ」「何を」したかログを記録・取得できるサービスです。
- 過去90日間より前のイベントの記録を保持する場合は、証跡情報を作成しS3にログを記録する。
- ログを使用して、監査対応やトラブル発生時の原因調査等が可能になります。
使用ユーザー
- IAMユーザー
手順
AWSにサインインします。
- アカウント、ユーザー名、パスワードを入力してサインインします。
アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする『AWSマネジメントコンソール』画面にある「サービスを検索」にCloudTrailと入力し、検索結果から《CloudTrail》をクリックし、CloudTrailコンソール(https://console.aws.amazon.com/cloudtrail/)を開きます。
操作ログの閲覧
- 過去90日以内のログであれば『CloudTrailコンソール』画面のイベント履歴から閲覧する。
- 過去90日間より前のログはS3バケットから直接ダウンロードして閲覧する。
使用ユーザー
- IAMユーザー
手順
AWSにサインインします。
- アカウント、ユーザー名、パスワードを入力してサインインします。
アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする『AWSマネジメントコンソール』画面にある「サービスを検索」にCloudTrailと入力し、検索結果から《CloudTrail》をクリックし、CloudTrailコンソール(https://console.aws.amazon.com/cloudtrail/)を開きます。
- 過去90日間より前のログは以下のリンクを参考に見てください。
参考サイト
- 投稿日:2019-11-12T19:41:09+09:00
【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(IAMユーザー設定)
MFA(Multi-Factor Authentication:多要素認証)の設定
ログイン時に多要素認証を強制するための設定します。
この設定によりパスワード漏洩のリスクを低減する事ができます。使用ユーザー
- IAMユーザー
手順
AWSにサインインします。
- アカウント、ユーザー名、パスワードを入力してサインインします。
アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする『仮想MFAデバイスの設定』画面がでますので、画面の指示に従って操作をしていきます。
- スマホにアプリをダウンロードします。
一般的にはAndroid、iOSともにGoogle Authenticator(Google 認証システム) アプリを利用しますが、
今回は、クラウドにバックアップができるのでMicrosoftのMicrosoft Authenticator アプリを利用したいと思います。
Microsoft Authenticator アプリも時間ベースのワンタイムパスワード(TOTP)を標準サポートしているので利用可能です。
以下のリンクよりアプリをダウンロードしてインストールします。 1
Android版 Microsoft Authenticator アプリ
iOS版 Microsoft Authenticator アプリ
- 《QRコードの表示》をクリックします。
![]()
- QRコードが表示されますのでそのままにします。1
![]()
- Microsoft Authenticator アプリを起動し、『アカウント』画面を表示します。1
![]()
- Android版は、『アカウント』画面の右上の《 ⁝ 》を、iOS版は右上の《+》タップします。1
![]()
- Android版のみ、ドロップダウンの中から《アカウントの追加》をタップします。1
![]()
- 『アカウント追加』画面の《他のアカウント(Google、Facebook など)》をタップします。1
![]()
- QRコードのスキャンモードに切り替わるので表示してあるQRコードをスキャンし、アカウントを追加します。
- Microsoft Authenticator アプリにアカウントが追加されており、数字が表示されているのを確認します。
- 『仮想MFAデバイスの設定』画面の下部のMFAコード1にその数字を入力し、最大30秒待つと数字が切り替わるので、切り替わった数字をMFAコード2に入力します。
![]()
- 《MFAの割り当て》をクリックします。
![]()
- 登録完了の画面が表示されたら《閉じる》をクリックします。
![]()
- 登録が完了し、登録内容が表示されます。
![]()
※ 画面はAndroid版です。 ↩
- 投稿日:2019-11-12T18:54:11+09:00
【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(IAMユーザーの作成)
IAM(Identity and Access Management)グループの作成
IAMユーザーに直接ポリシーを付与する事も可能だが、管理が煩雑になるためグループを作成して付与したポリシーを個人ではなくグループで管理する。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインする『AWSマネジメントコンソール』画面にある「サービスを検索」にIAMと入力し、検索結果から《IAM》をクリックし、IAM コンソール(https://console.aws.amazon.com/iam/)を開きます。
ポリシー一覧から「AdministratorAccess」のチェックボックスをチェックし、《次のステップ》をクリックします。
IAM(Identity and Access Management)ユーザーのパスワードポリシー設定
IAMユーザーのパスワードの文字の組み合わせなどの条件を設定や定期的なパスワード変更期間の設定をする。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインするポリシーに応じてチェックを付け、《変更の保存》をクリックします。
- パスワードの最小文字数を強制する
パスワードの最小文字数を指定します。(設定値:6〜128)- 1文字以上のアルファベット大文字(A~Z)を必要とする
パスワードにアルファベット大文字(A~Z)を最低1文字使用する必要があるか指定します。- 1文字以上のアルファベット小文字 (a~z)を必要とする
パスワードにアルファベット小文字(a~z)を最低1文字使用する必要があるか指定します。- Require at least one number
パスワードに数字(0~9)を最低1文字使用する必要があるか指定します。- Require at least one non-alphanumeric character(!@#$%^&()_+-=[]{}|')
パスワードに記号(!@#$%^&()_+-=[]{}|')を最低1文字使用する必要があるか指定します。- Enable password expiration
パスワードの有効期限を日数で設定します。有効期限経過後はパスワード変更が必要にまります。(設定値:1~1095)- Password expiration requires administrator reset
有効期限経過後のパスワード変更が管理者しかできない(ユーザー自身での変更は不可)設定にします。この設定を有効にする前に管理者が複数ユーザー存在することを確認します。- Allow users to change their own password
ユーザーが自分自身のパスワードを変更できるか指定します。- Prevent password reuse
過去に利用したパスワードの再利用を禁止できます。(設定値:1~24)IAM(Identity and Access Management)ユーザーの作成
ルートユーザーを極力利用しないようにするため、代わりとなる管理者用のユーザーを作成します。
このユーザーはルートユーザー同様に全ての権限を有するユーザーにします。
必要に応じて権限を変更(アクセス制限)できる所がルートユーザーとの違いになります。管理者用ユーザー以外のユーザーを作成する場合は、必要最小限のポリシーを付与するようにしてください。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインする「ユーザー名」に適当なユーザー名を入力し、「AWSマネジメントコンソールへのアクセス」のチェックボックスをチェックします。
このユーザー名がAWSへサインインするためのユーザー名になります。
「プログラムによるアクセス」は、後から設定できるのでここでは設定しません。
「コンソールのパスワード」の「カスタムパスワード」を選択し、パスワードを入力する。
「パスワードのリセットが必要」のチェックボックスのチェックを外し、《次のステップ:アクセス権限》をクリックします。1
入力するパスワードは別途設定してあるパスワードポリシーに準拠する必要があります。
参考サイト
今回は自分で利用するユーザーのためこの設定にしています。 ↩
- 投稿日:2019-11-12T18:50:24+09:00
【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(準拠法、管轄裁判所設定)
準拠法と管轄裁判所の変更
- 準拠する法律を日本の法律に変更する。
- 第一審裁判所を東京地方裁判所に変更する。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインする『AWSマネジメントコンソール』画面にある「サービスを検索」にartifactと入力し、検索結果から《AWS Artifact》をクリックし、AWS Artifact コンソール(https://console.aws.amazon.com/artifact/)を開きます。
内容確認後、「NDA を確認済みで、同意する場合はここをチェックしてください」のチェックボックスをチェックし、《NDA に同意し、日本準拠法に関するAWSカスタマーアグリーメント変更契約 をダウンロードする》をクリックします。PDFファイルがダウンロードされます。
「本変更契約の条件をダウンロードし確認した。」、「本変更契約の条件に同意する」、「本変更契約の条件は機密事項であること並びにAWS Artifact NDA秘密保持契約に服することを了解し、これに同意する。」のチェックボックスをチェックし、《このアカウントの日本準拠法に関するAWSカスタマーアグリーメント変更契約に同意する》をクリックします。
参考サイト
- 投稿日:2019-11-12T18:48:02+09:00
【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(請求設定)
請求書のメール通知、無料利用枠接近および超過アラート通知設定
- 請求書を指定したメールアドレス宛に毎月送付する。
- 無料利用枠の限界に近づいた場合および超過した場合にアラートを通知する。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインする「電子メールでPDF版請求書を受け取る」、「無料利用枠の使用のアラートの受信」のチェックボックスをチェックし、Eメールアドレスに通知を受け取るEメールアドレスを入力して《設定の保存》をクリックします。
予算の設定
AWSの利用料金が設定した予算(Budgets)を超過した場合や、月末時点の予測金額が超過する場合にアラートを通知する。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインする「コスト予算」を選択し、《予算の設定》をクリックします。
今回は初めて作る場合にお勧めのコスト予算を作成します。
特に指定があるわけではないので好きな予算を作成してください。
『予算の設定』画面で必要な設定を行い、《アラートの設定》をクリックします。
- 名前 一覧に表示される名前になります。後で変更はできません。
- 間隔 予算を集計する間隔(月別、四半期別、年別)
- Budget Effective Dates 定期予算を選択すると、間隔で指定した期間が終わった場合に自動でカウントをリセットしてくれる。
- 予算額 修正されましたを選択する。 上限となる予算額を設定する。(例では$100)
- フィルタリング、詳細オプション デフォルトのまま。
『アラートの設定』画面で必要な設定を行い、《予算の確認》をクリックします。
- アラートのしきい値 予算額の割合または実際の金額を指定できます。
- 連絡電子メール 複数個指定できます。
- 新しいアラートの追加で複数個アラートを設定できます。
Cost Explorerの有効化
- AWSの料金や使用量をグラフィカルに表示するツールです。コスト分析などに使えます。
- 有効化してから利用するまでに最大24時間かかります。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインする参考サイト
- 投稿日:2019-11-12T18:44:44+09:00
【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(アカウント設定)
アカウントIDの確認
この数字でアカウントを特定します。各種問い合わせやIAMユーザーのログインで使用します。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインする支払い通貨の変更
毎月の支払を円払いに変更します。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインする「お支払い通貨の設定」の《設定》をクリックします。
円払いに対応しているクレジットカードはVISAとMasterカードのみです。
画像はそれ以外のカードのため設定ボタンが出ていません。
詳細は、AWS支払の円払いへの切り替え方法についてを参照してください。代替の連絡先の設定
AWSから受け取る通知の連絡先をカテゴリ毎(請求、操作、セキュリティ)に追加します。
この設定を行ってもルートユーザーには引き続きすべての通知が届きます。使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインするIAM(Identity and Access Management)ユーザーに請求情報のアクセス権付与
管理者権限を持つIAMユーザーでも請求情報にアクセスできないためできるように設定する。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインする
- 投稿日:2019-11-12T18:41:09+09:00
【Windowsユーザーでクラウド初心者向け】AWSアカウント作成後にやった方が良い初期設定(ルートユーザー設定)
MFA(Multi-Factor Authentication:多要素認証)の設定
ログイン時に多要素認証を強制するための設定します。
この設定によりパスワード漏洩のリスクを低減する事ができます。使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインする『仮想MFAデバイスの設定』画面がでますので、画面の指示に従って操作をしていきます。
- スマホにアプリをダウンロードします。
一般的にはAndroid、iOSともにGoogle Authenticator(Google 認証システム) アプリを利用しますが、
今回は、クラウドにバックアップができるのでMicrosoftのMicrosoft Authenticator アプリを利用したいと思います。
Microsoft Authenticator アプリも時間ベースのワンタイムパスワード(TOTP)を標準サポートしているので利用可能です。
以下のリンクよりアプリをダウンロードしてインストールします。 1
Android版 Microsoft Authenticator アプリ
iOS版 Microsoft Authenticator アプリ
- 《QRコードの表示》をクリックします。
![]()
- QRコードが表示されますのでそのままにします。1
![]()
- Microsoft Authenticator アプリを起動し、『アカウント』画面を表示します。1
![]()
- Android版は、『アカウント』画面の右上の《 ⁝ 》を、iOS版は右上の《+》タップします。1
![]()
- Android版のみ、ドロップダウンの中から《アカウントの追加》をタップします。1
![]()
- 『アカウント追加』画面の《他のアカウント(Google、Facebook など)》をタップします。1
![]()
- QRコードのスキャンモードに切り替わるので表示してあるQRコードをスキャンし、アカウントを追加します。
- Microsoft Authenticator アプリにアカウントが追加されており、数字が表示されているのを確認します。
- 『仮想MFAデバイスの設定』画面の下部のMFAコード1にその数字を入力し、最大30秒待つと数字が切り替わるので、切り替わった数字をMFAコード2に入力します。
![]()
- 《MFAの割り当て》をクリックします。
- 登録完了の画面が表示されたら《閉じる》をクリックします。
![]()
- 『セキュリティ認証情報』画面に戻ると登録内容が表示されます。
![]()
アクセスキーの削除
アクセスキーは、AWS コマンドラインツール、AWS SDK等を利用する場合に必要になります。
このキーが悪意のある第三者に漏洩した場合に、ルートユーザーの強い権限でAWS コマンドラインツールが利用できてしまいます。
全てのリソースにアクセスできますので漏洩リスクはとても怖いものです。ですのでAmazonでもルートユーザーは通常使用しない事が推奨されています。
ルートユーザーのアクセスキーを使用する場面もありませんので、リスクとなるキーは事前に削除しましょう。
使用ユーザー
- ルートユーザー
手順
AWSにサインインします。
- Eメールアドレスとパスワードを入力してサインインします。
ルートユーザーを使用してコンソールにサインインするアクセスキーが作成されていない事を確認します。(アカウントを作成時にはアクセスキーは作成されていないはずです)
作成されていた場合は、AWS アカウントのルートユーザー のアクセスキーの作成、無効化、削除を参照して削除してください。参考サイト
- AWS を安全に使うために(IAM のベストプラクティス)
- お使いの AWS アカウントのルートユーザーの仮想 MFA デバイスを有効にする (Console)
- Microsoft Authenticator アプリのヘルプ(Amazon アカウントを追加する)
- AWS アカウントのルートユーザー のアクセスキー管理
- AWS アカウントのルートユーザー のアクセスキーの作成、無効化、削除
※ 画面はAndroid版です。 ↩
- 投稿日:2019-11-12T18:37:46+09:00
【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の開設
- AWSアカウントを作成してコンソールにサインインする
- AWSアカウント作成後にやった方が良い初期設定
Amazon Connect構築
- Amazon Connectの開設
参考サイト
- 投稿日:2019-11-12T18:05:35+09:00
Qwiklabs(GCPとAWSのラボ環境)について
Qwiklabsとは
これ
https://www.qwiklabs.com/?locale=jaGCPと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がいいと思う。
参考リンク
- 投稿日:2019-11-12T17:32:47+09:00
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
まとめ
- DLQ設定は非同期呼び出しでのみ有効
- SQSをイベントソースにした場合は同期呼び出し
- サービスごとに呼び出し方法を確認するべし
- 投稿日:2019-11-12T17:22:32+09:00
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。
- 投稿日:2019-11-12T15:39:27+09:00
[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-clidockerのインストール
最初にbrewでdockerをインストールしたのですが、うまく動かず結局公式サイトからdmgをDLしてインストールしました。Lambdaの動作環境を用意するために使われます。AWS Toolkitを入れてVSCodeからLambda関数を実行するときに自動でdocker環境が立ち上がります。
Install Docker Desktop for MacVSCodeからAWSへの接続
EXTENSION追加
VSCodeの左側のタブからAWS Toolkit for Visual Studio Codeを追加します。これで左側のタブにAWSのアイコンが表示されます。
認証情報の設定
インストール後、
cmd+shift+P
でawsコマンドウィンドウを表示し、Create Credentials Profile
を実行します。エディタ若しくはコマンドウィンドウの指示に従い、AWSアカウントのACCESS KEYとSECRET ACCESS KEYを入力します。このawsコマンドにより新たにAWSユーザを作成できます。これは
.aws/
配下にvimでcredentialsというファイルを作成または編集する操作と同じです。.aws/config
ファイルが存在する場合はそれと合わせて読み込まれます。
AWSへ接続
AWSのアイコン→
Connect to AWS
をクリックします。.aws/credentials
または.aws/config
に定義されたユーザが自動で表示されるためその中から選択します。アプリケーションの作成
Create new SAM Application
を選択します。
次に、Runtimeに使用する言語を選択します。筆者はPython3.7を選択しました。
ワークスペースとなるフォルダを選択し、アプリケーションの名前をつけます。すると自動的にtemplate.yaml
が立ち上がります。template.yamlAWSTemplateFormatVersion: '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環境が立ち上がり、ローカルで関数が走ります。何かの不具合があればここでエラーが表示されるため、落ち着いて対応しましょう。
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を覗いてもらえば何かのオブジェクトが保存されていることを確認できます。
今まで同様
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できたと言ってもいいでしょう。
- 投稿日:2019-11-12T15:37:06+09:00
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
- 投稿日:2019-11-12T15:37:06+09:00
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
- 投稿日:2019-11-12T15:35:31+09:00
【覚書】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の設定
- イベントソースマッピングで使えるキューは標準キュー
- Lambda関数側のロールに、キューに対して下記のアクセス権限が必要
こんな感じにするヨロシ
"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に落ちるメッセージが増えてしまうので注意
- 投稿日:2019-11-12T15:12:04+09:00
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)AWSサンプル TTS pic.twitter.com/OTwYQ9mY5D
— utaca.rich (@RichUtaka) May 11, 2019
- 投稿日:2019-11-12T13:51:15+09:00
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ロールをアサインする。
(参考)
- https://www.slideshare.net/AmazonWebServicesJapan/20180613-aws-black-belt-online-seminar-aws-cloud9
- https://teratail.com/questions/213688
- https://eksworkshop.com/prerequisites/workspaceiam/
サービス > IAMで左のメニューからロールを選択し、「ロールの作成」をクリックし、「AWSサービス」と「EC2」を選択して次のステップ。
「AdministratorAccess」にチェックして次のステップへ。
タグはそのままにして次のステップへ。
ロールに「cloud9-admin」のような適当な名前をつけて、「ロールを作成」。
サービス > EC2で左のメニューからインスタンスを選択し、Cloud9のインスタンスを選択して、アクション > インスタンスの設定 > IAMロールの割り当て/置換を選択し、先ほど作成したIAMロールを割り当てる。
Cloud9で右上の設定アイコンから、AWS SETTINGSの「AWS managed temporary credentials」を無効にする。
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 awsclieksctl
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.yamlapiVersion: 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 ansibleTerraform
tfenvを使って入れる。
brew search tfenv brew install tfenv tfenv --version tfenv list-remote tfenv install 0.12.12jq
apt-get install jq # brew install jq # pip install jq
- 投稿日:2019-11-12T10:38:42+09:00
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は忘れずにね☆
- 投稿日:2019-11-12T10:13:39+09:00
Amazon S3でSPAをサクッと公開する
はじめに
ストレージサービスとして有名&優秀なAmazon S3ですが、実は「静的ウェブサイトホスティング」という機能を使うことで、Vue.jsやReactで作ったSPAを簡単に公開することができます。また、AWS CLI を使用することでコマンド一発でサクッとデプロイすることができます。
herokuやfirebaseなどの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等)が揃っている状態にしましょう。
ちなみにVue.jsでのプロジェクト開始方法およびビルド方法はこちらの記事(Vue CLI スタートガイド)にまとめてありますので、フロントフレームワークを全く触ったことないという方はこちらを参考にしてみてください。
S3用のIAMユーザ作成
AWSルートアカウントの作成
AWSを初めて使うという方はAWSルートアカウントを作成しましょう。
こちらを参考にすると良いと思います。
AWS アカウント作成の流れ | AWSS3用のIAMユーザの作成
ルートアカウントは全権限アカウントのため全てのAWSリソースへのアクセスができてしまいます。このルートアカウントで作業を続けることはセキュリティ上よろしくないので、S3のみ使用可能なIAMユーザを別途作成し、今後の作業はこのS3用IAMユーザで行います。
まずルートアカウントでログインし、マネジメントコンソールからIAMへ移動します(検索バーで「iam」と打てば出てきます)。
「ユーザー」メニューを選択すると、作成したIAMユーザの一覧が表示されます。
今回は新規でユーザを作成するので、青色ボタンの「ユーザーを追加」をクリックしましょう。
IAMユーザを作成するための設定画面が表示されます。
- ユーザー名は任意の名前で構いません(公開しようとしているSPA用のIAMユーザであることが分かるネーミングだと良いです)
それ以外はデフォルトの設定で問題ありません。
IAMユーザの作成が完了すると一覧に表示されるので、問題なく作成されているか確認しましょう。
IAMユーザの作成が完了したら、早速ログインしてみましょう。
右上にIAMユーザ名 @ アカウント名
と表示されていれば問題なくログインできています。
S3以外のサービスへのアクセスがブロックされているか確認するために、試しにIAMを開いてみましょう。
先ほどIAMユーザを作成した画面に移動しても「アクセス権限が必要です」と表示され、ユーザを新規作成できないようになっているはずです。
このように、利用用途ごとにIAMユーザを作成してAWSサービスへの権限を切り分け、意図しない操作が実行されないようにしましょう。
S3でSPAを公開
先ほどログインしたS3用IAMユーザで作業を進めます。
バケットの作成
S3の画面へ移動し、青色の「+バケットを作成する」ボタンをクリックしましょう。
バケット作成に際しての設定画面が表示されるので、情報を入力しましょう。
- バケット名:任意の文字で構いません。ここで設定したバケット名が後ほど静的ホスティングする際のURLの一部として使われるので、それっぽい名前を付けましょう。
- リージョン:これも任意で構いませんが、「アジアパシフィック(東京)」を選択するのが無難です。
![]()
それ以外の設定は一旦デフォルトのままで問題ないです。
バケットが作成されるとバケット一覧に表示されるようになります。
コンテンツのアップロード
バケット名をクリックするとバケットの詳細画面に遷移することができます。
青色の「アップロード」ボタンをクリックし、公開したいSPAの各ファイル(index.htmlとcss/js/imgフォルダ等)をローカルからアップロードしましょう。
初回アップロード時にバケットの設定について色々と聞かれますが、全てデフォルトで問題ないです。
無事アップロードが完了するとこのような画面になると思います。
静的ウェブサイトホスティング機能の設定
「プロパティ」タブへ移動し、「Static website hosting」の設定を行います。
上記の設定が完了したら「保存」ボタンをクリックしましょう。
なお、この画面で表示されている「エンドポイント」のURLがウェブサイトへのアクセス用URLになります。が、今の状態でこのURLにアクセスしようとしても403エラーが返ってきてしまいます。URLでのアクセスを許可するために、次の章で説明するバケットポリシーを設定しましょう。
バケットポリシーの設定
S3に格納したオブジェクトが不用意にネットに晒されないよう、デフォルトでは外部からS3バケットへのアクセスは全て拒否するようになっています。先ほど403エラーが返ってきたのもそのためです。正しくWebページを表示させるためにはURLによる外部からのリクエストを明示的に許可する必要があります。
アクセス制御に関することは「アクセス制御」タブで行います。
まず、「ブロックパブリックアクセス」を開きます。「編集」をクリックし、以下の設定を行います。
- 「パブリックアクセスをすべてブロック」のチェックを外します
- 下から2つ目、「新しいパブリックバケットポリシーを介して...」のチェックを外します
- 一番下、「任意のパブリックバケットポリシーを介して...」のチェックを外します
![]()
これでバケットポリシーによるアクセス許可設定が有効になります。ここの設定を行わないと、いくらバケットポリシーで許可の設定を行ってもブロックされてしまうので注意しましょう。
次に「バケットポリシー」を開き、エディタ欄に以下の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ページが表示されるようになっているはずです。
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 awscli3: ルートアカウントでS3用IAMユーザのアクセスキーとシークレットアクセスキーを生成・取得します。IAMメニューで先ほど作成したS3用IAMユーザを選択し、「認証情報」タブの「アクセスキーの作成」ボタンをクリックします。アクセスキーとシークレットアクセスキーが表示されるので、手元に控えておきましょう。
4:ターミナルに
aws configure
と入力しS3を操作するための設定を行います。Access Key ID
とSecret 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/ --recursive1行目はシェルスクリプトを走らせるためのおまじないです。詳しく知りたい方はこちらの記事(#!/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.json
のscripts
ブロックで設定できます。
"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にアクセスするとしっかり変更が反映されていますね。
おわりに
これでローカルで作成していた静的ウェブサイトを公開できるようになりました。
デプロイもコマンド一発で簡単にできるようになったので、開発速度もかなり向上したんじゃないでしょうか。個人的な今後としては、LambdaやDynamoDBを利用したサーバーレスAPIとの通信にチャレンジしてみたいと思います。
- 投稿日:2019-11-12T00:45:43+09:00
【初心者】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の通信を表示する。
構成図
作業手順
インスタンス作成
- インスタンス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接続を行う。
- x.x.x.233(手元のPC)から、10.0.1.249(インスタンス1のENI)へのssh通信が、インスタンス2にてキャプチャできている。また、パケットがVXLANでカプセル化されていることも確認できる。
所感
- 今までNetwork型IDSはAWSには設置不可という考え方だったが、TargetとしてIDSを指定すればそれも可能になりそう。
参考
- (公式ブログ)最新 – VPC トラフィックミラーリング – ネットワークトラフィックを捉えて検査する
- [新機能] EC2 インスタンス(Nitro)の通信内容をVPC側からミラーする VPC Traffic Mirroring が発表されました!
- GUIの画面付きで説明してあり分かりやすい。
- AWS re:Inforce2019 re:Cap LT
- Traffic Mirroringの仕組みが図解されており分かりやすい。