AWS関連のことを調べてみた2020年11月14日

【UnauthorizedOperation】EC2インスタンス作成時にエラーが起きたので備忘録

## 概要

DockerホストからEC2インスタンス上でコンテナ起動時にエラーがおきました。
AWSもDockerもDockerマシンも学習中を始めたばかりでエラーが起きたときに手探りで進めているという感覚ですが、解決できたので備忘録としてまとめさせていただきます。また、同じエラーに悩まれている方がいれば、その方の一助となれば幸いです。遠回りをしているかもしれませんが、そのときはご意見を頂きたく存じます。

## 仮説検証

まずこちらが今回のエラー文です。エラー文から考えられることを仮説検証してエラーを解決していきます。

“`terminal:ターミナル
% docker-machine create –driver amazonec2 –amazonec2-open-port 8000 –amazonec2-vpc-region ap-northeast-1　
(EC2インスタンス名) Couldn’t determine your account Default VPC ID : “UnauthorizedOperation: You are

Elastic BeanstalkでLaravelとNuxt.jsをデプロイした時のメモ

# 概要
– 構成
　
– Elastic BeanstalkでEC2とRDSを立てる
– ドメインと証明書を取得して設定する
– ロードバランサーとセキュリティグループを設定する
– EB Cliを使用する

# Elastic BeanstalkでNuxt.jsをデプロイ
AWSコンソール
– Elastic BeanstalkでNode.jsプラットフォームの環境を作成
– [設定] – [ソフトウェア] – [変更]でノードコマンドに“`npm run eb-start“`を入力
– [設定] – [ソフトウェア] – [変更]で環境変数を設定

ローカル環境
– eb initを実行
– /package.json内の“`scripts“`に“`”eb-start”: “npm run build && npm run start”,“`を追加
– npm installで失敗する場合
– /.npmrcファイルを

Ansibleでユーザパスワードを変更してSSMパラメータストアにパスワードを保存する

##実現したいこと
Ansibleを使用してTargetサーバのユーザのパスワードを変更します。
変更後のパスワードはAWS Systems Managerの一機能であるパラメータストアに保存したいと思います。
パラメータストアは無料でリージョンごとに10000個までのパラメータを管理することができます。

[前回](https://qiita.com/latin1/items/111aac5bd222370aeb70)に引き続き、Docker + Ansibleの環境で以下を実現します。
①ランダムパスワードを生成する
②ユーザのパスワードを変更する
③SSMパラメータストアにパスワードを保存する

##設定
DockerとAnsibleの細かい設定は前回の記事と同じであるため省略します。
変更するのはmain.ymlです。

まずは、15文字のランダムなパスワードを生成します。
次に、生成されたパスワードを表示します。
生成されたパスワードを対象のユーザに設定します。
最後にAWS CLIコマンドでパラメータストアにパスワードを保存します。

ssm put-parameterの補

【AWS】より安全に使うためにCloudWatchを設定する

AWSを利用してからルートユーザー、IAMユーザー共にMFA（多要素認証）は設定していましたが、コストに関して通知（CloudWatch）が来るように設定できることは後から知りました。

それぞれの目的
・MFA→不正アクセスを防ぐ
・CloudWatch→サービスの使い過ぎを防ぐ（指定した金額以上になったら通知が来る）

その際の設定を備忘録として書いていきます。

ログイン後、サービスの検索からCloudWatchを検索。

CloudWatchを選択。
AWSの正体

AWSとはAmazonが提供する仮想的にサーバ環境構築をしたり、データを保存したり、データベースを扱えるクラウドコンピューティングサービスである。

仮想化されたことによりコストが最低限に抑えられ、インフラ構築が容易になったが、その代わりその実体が何なのかいまいち掴みきれない。

ここではその仮想化された実体を追う。

#AWSのwebサーバはどこにあるのか
そもそも仮想化と言ってはいるが、実体がないわけではない。
AWSのwebサーバはデータセンター内にちゃんと物理的に存在している。

#データセンターとは
AWSで使用される数千数万のサーバを管理している施設。具体的な所在地は明記されていないが、世界各地に点在している。その拠点がある地域のことをリージョンと呼ぶ。
また、そのデータセンターが隣接した塊をアベイラビリティーゾーンと呼んでいる。団地をアベイラビリティーゾーン、その中の建物の一つがデータセンターだと考えるとわかりやすいかもしれない。
下記はデータセンターの記事。ぴんと来ない方はこちらを見てみるとよい。
https://aws.amazon.com/jp/compliance

【AWS】【初心者】wordpressのブログシステムを構築する(パラシつき)　④

この記事は、【AWS】【初心者】wordpressのブログシステムを構築する(パラシつき)　③
「 https://qiita.com/gbf_abe/items/bc729c19bcc2095de9bf 」の続きです。

# お詫び
11月入ってお仕事が忙しくなって更新止めてしまいました…(システム作り切って満足しちゃいました)
~~もうサボらないので~~ゆるして…

# 前回まででやったこと
|順番|内容 |
|—|—————————-|
|① |VPC構築 |
|② |サブネット分割 |
|③ |EC2(パブリック)構築 |
|④ |WebサーバにApacheをインストール |
|⑤ |EC2(プライベート)構築 |
|⑥ |NATゲートウェイ構築 |
|⑦ |DBサーバにMariaDBをインストール |
|⑧ |Webサーバにword

初心に戻ってAWSでスケーラブルなウェブサイトを作成する

次の通り王道の構成ですが、昔とUIも変わってるということもあり、初心に戻ってAWSでスケーラブルなウェブサイトを作成する基礎の内容です。


#1.VPCの作成#

「VPCウィザードの起動」より設定を行います。

・ステップ 1: VPC 設定の選択
「1 個のパブリックサブネットを持つ VPC」を選択。

・ステップ 2: ステップ 2: 1 個のパブリックサブネットを持つ VPC
**VPC:10.0.0

AWS Lambda Python3.8 から Slack へメッセージを送る設定を terraform で作成する

【個人備忘録】lambdaからslackへメッセージを送るシンプル設定

# 概要
* Slack API へのメッセージ送信に関して
* [slackweb ライブラリ](https://pypi.org/project/slackweb) は使わない (ローカル環境にライブラリインストールしてあれやこれやがめんどくさい)。
* Python標準ライブラリの urllib を使う。
* Slack API へ渡す情報は、Lambdaの環境変数に設定する。

* Terraform での Lambda 作成に関して
* aws provider の バージョンは 2.48.0
* Lambda関数コード（pythonソースコード）は、**terraform archive provider** の data ソース **archive_file** を使って zip にしてから、deployする。

* 送信イメージ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14

AWS の API Gateway (HTTP API) 経由で Lambda に繋いで POST データを処理するメモ

取り急ぎ忘れないようにめもめも。

* POSTパラメータは `event[‘body’]` に入っている。
* API Gateway の設定で `isBase64Encoded` が有効であると、Base64エンコードされる

APIに投げるときにJSONエンコードしたものを渡すと、Base64デコード後にJSONが取れる。
その際は、リクエストクエリのパースではなく、JSONのパース処理を行う。

“`python
import json
import base64
import urllib.parse

def lambda_handler(event, context):

# POSTパラメータがBASE64でエンコードされているのでデコードする
decoded_body = base64.b64decode(event[‘body’]).decode()
# POSTパラメータをdict型に変換
post_params = urllib.parse.parse_qs(decoded_body)

result = {}

無限くら寿司ガチャを作ってみた

10月からスタートしたGoToEatキャンペーン皆さんは使用していますか？
[農林水産省 GoToEatキャンペーン](https://gotoeat.maff.go.jp/)

私はちょくちょく使用していたのですが、なんでも巷で「無限くら寿司」というものが流行っているらしい。
GoToEatでもらえるポイントで食事をして、その食事でまたポイントが貰えるので、くら寿司を何回もお得に食べられるといったものです。（モラル的な話はおいておきます）
[くら寿司公式GoToEatキャンペーンページ](https://www.kurasushi.co.jp/topic/000971.html)

GoToEatでポイントをもらうためには、くら寿司で一人あたりランチは税込み500円、ディナーは税込み1000円以上食事をする必要があります。
そこで、くら寿司のメニューを該当価格を超えるくらいでランダムで表示される「無限くら寿司ガチャ」を作ってみました。

作ったwebアプリはこちら↓
[**無限くら寿司ガチャ**](http://ec2-13-231-170-155.ap-northeast-1.co

AWS 認定 ソリューションアーキテクト – アソシエイトを受けてきました

#結果
合否：合格しました
点数：769(720点が合格ラインなのでギリギリ)
期間：1ヶ月間
1ヶ月間といっても、業務時間のほとんどを資格勉強だったため、他の方よりも勉強時間は長いです。(約170時間)

#モチベーション
・現在参画している案件にて資格取得を命じられたこと
・資格手当が支給されて、年収が少し上がる
・転職などに有利にはたらく可能性がある
・資格未保持のため、何かが欲しかった

##前提
AWSは実務未経験で、遊びで触ったことがあります。
そのため、事前知識は少しだけありました(EC2やS3など)

#勉強方法
・udemyの試験突破講座を見る
・udemyの模擬試験を受け、分からなかった用語をひたすら調べる
詳しくは最後に詳細で書きます

#試験の感触
######難易度：実際の試験＜udemyの講座に付随する模擬試験＜＜udemyの模擬試験問題集

他の方の体験談をみるに、試験回ごとの難易度の差はかなりあるのではないかと思います。
私は難易度の低いラッキーな回に受けることができましたが、運が悪いとudemyの模擬試験問題集レベルになってしまうかもしれません。
難し

AWS CLIでAmazon CloudWatchのアラームの発砲をテストする

# はじめに
ローカルPCからAWS CLIを利用して、Amazon CloudWatchのアラームのステータスを強制的に変更し、Slackなどに発砲するか試験します。
発砲試験のために、アラームに設定している内容を変更するのは、試験内容にはならないことに注意です。
アラームの内容にもよりますが、アラームの数が多いとその分通知が飛ぶため、本来確認すべき内容が分からなくなう可能性があるため、アラーム名を直接指定する形にしています。

# スクリプト

“`sh:test_alerm.sh
#!/bin/sh

cd `dirname $0`

test_alerm () {

ALERM_NAME=$1
echo “test alerm: ${ALERM_NAME}”

aws cloudwatch set-alarm-state \
–alarm-name ${ALERM_NAME} \
–state-value ALARM \
–state-reason ‘【テストでやんす！！！！】’
}

test_alerm [アラーム名]

AWSの鍵の管理について

(随時更新)

鍵の管理はAWSで行うか、ユーザー自身で行うかの二つの方法がある

# 鍵の管理はユーザー鍵の保管はAWSで行うときのサービス

## AWS KMS
鍵管理をするサービス
鍵はAWS情に保管される
* 暗号化キーの作成
* 暗号化キー有効無効の管理
* 暗号化キーの削除

## CloudHSM
Hardware Security Module
専用ハードウェアモジュールにより暗号キーを保護する
専用サーバーを使うのでかなり強固な仕組み
欧州などのセキュリティ基準が厳しい国ではこちらを使うことになる

HSM自体はユーザーのVPCに配置される

AWSのEBSの再確認

# はじめに
今更ですがAWSの基礎の学習をしています。今回は普段（というか今まで全く）気にしていなかった、EBSの動作の再確認をしました。

# やること
– ボリュームをインスタンスにアタッチして、そのボリュームを他のインスタンスに再アタッチしてちゃんとデータが残っていることを確認する。
– ストレージと言えばS3ばかりだったが、ローカルボリューム(EBS)も保存領域といういみでは使えるということの再確認。

# 作業の流れ
1. ebsの作成
2. ebsをインスタンスAにアタッチ
3. インスタンスAで、ebsにファイルを作成(hoge.txt)
4. インスタンスBに、ebsを再アタッチ
5. インスタンスBで、ebs内を確認してhoge.txtがあるかを確認

# 1. ebsの作成

![ボリューム | EC2 Management Console 0002-11-13 12-23-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/9884/4f06ad14-e423-6e9b-916c

新しいElastic Load Balancerが来たぞ！

#えぇ！？セキュリティアプライアンスでスケーリングを！？
できらぁ！！
[Introducing AWS Gateway Load Balancer](https://aws.amazon.com/jp/about-aws/whats-new/2020/11/introducing-aws-gateway-load-balancer/)

要約すると、第三者パーティのセキュリティアプライアンス（FortinetとかDeepSecurityとか）が
実装されたELBが使えるよって感じかな。

**え、ヤバない？**

今までインスタンス毎にCloud One Workload Security(旧:Deep Security as a Service)とか入れてたのを、
こいつフロントにかますだけで良くなるってことでしょ？

**ヤバない？**

まだ日本には実装されていないので、シドニーリージョンとかで試してみようかな。
ただ、アプライアンスのライセンス費用がどれくらいかかるのか、それが気になるところ。

[AWS ゲートウェイロードバランサー製品概要](https://aws.ama

[AWS CloudFormation] IoTルールの定義

# `AWS::IoT::TopicRule`を使用したIoTルール定義

構文については[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-iot-topicrule.html)参照
ただし、以下のように記載されている`YAML`例が`YAML`ではなく`JSON`

英語サイトの場合は、`YAML`例はちゃんと`YAML`になっている
ただし、bool値の箇所が`’true’`と文字列になっている（ただしくは`true`）等の誤りがあったりするので注意
![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/695430/c697

Principalに指定したリソースがないとIAM Roleの作成に失敗する

#概要

AWSでクロスアカウントでアクセスする際にAssumeRoleを行うための設定をします。
例えばアクセス元のアカウントをA、アクセス先のアカウントをBとすると、アカウントBのAWSアカウントにAssumeRoleを許可するためのIAM Roleを作成します。
今回、このアカウントBに該当するアカウントで、IAM Roleを作成しようとして失敗しました。オチとしてはタイトルの通りなのですが、なぜ失敗したのか原因を調べたところ、IAMってちゃんと考えられてるな、と感心したので記事にしました。

#構成

今回はAWS Organizationsでアカウント管理をしている環境において、メンバーアカウントのLambdaからマスターアカウントのOrganizationsサービスが提供しているAPIを実行する場合を例として取り上げたいと思います。Organizationsの部分が例としては少し特殊かと思いますが、基本的にクロスアカウントでAPIを実行する場合は同じような構成になるかと思います。

![qiita_assumerole.png](https://qiita-image-st

AWS IoT Core の シャドウ機能についての調査まとめ

## シャドウ概要

AWS IoT Coreでは、ラズパイなどのエッジ端末をモノ(Thing)として登録し、その状態を保持する機能を持っています。この「状態(state)」がシャドウ(shadow)です。

アプリケーションでは、この状態の変更を通してデバイスを操作します。

状態には**”reported”**、**”desired”**の2つの要素が存在します。

– **”desired”**： アプリケーションとして期待する状態を示すのに使用します。アプリケーションで状態の変更要求を出す場合は、この状態を更新します。
– **“reported”**： デバイス自身がどういった状態なのかを示すのに使用します。この状態を変更するのは基本的にはデバイス自身です。

![image.png](https://qiita-image-store

DynamoDB オンデマンドモード ≠ エラーなしのアクセスし放題

# 問題

DynamoDB をオンデマンドモードにして運用していればテーブルへのアクセス集中による対処(スロットリング）は気にしなくても良い。 **というのは間違った認識である。**

[オンデマンドの DynamoDB テーブルを使用していますが、まだスロットルされています。なぜでしょうか?](https://aws.amazon.com/jp/premiumsupport/knowledge-center/on-demand-table-throttling-dynamodb/) にあるように、例えオンデマンドモードであってもスロットリングは発生する。

## そもそもリクエスト単位って何？

ここの説明に書いてある「リクエスト単位」というのは何を意味するのだろうか？　読み込み・書き込みがあるが、今回は書き込み側に絞ってみていく。

定義は [ここ](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html) に書いてある

AWS SQS FIFOの並列動作について書いておく

## AWS SQSではグループIDが異なれば並列で動くのか？

標準SQSであれば受信可能なメッセージから極力FIFOで処理されていきますが、基本的には順序保証なくどんどん消化されます。
トリガーにLambdaが設定されていれば、複数のLambdaインスタンスにより処理されていきます。

ではFIFOはどうなのか？

FIFOはグループID単位で順序を保証します。
ではグループIDが異なっていればどうなるか？

例えば

1番目 グループID:A 8:00:01にキュー登録
2番目 グループID:A 8:00:02にキュー登録
3番目 グループID:B 8:00:03にキュー登録
4番目 グループID:C 8:00:04にキュー登録

とした場合。
トリガーのLambdaは10秒処理がかかるとします。

この場合は
１番目→３番目→４番目→２番目

の順でメッセージを取得していきます。
このとき、３番目の実行タイミングは１番目が実行中のときに開始しますので、8:00:03に処理開始します。
４番目も同じく、8:00:04に処理を開始します。
２番目のキューは１番目の処理が完了してから