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

AWS上に構築したWordPressで「504 gateway timeout」が頻発した時の対処法

#概要
AWS上に構築したWordPressで「504 gateway timeout」が頻発したので、その際の対処方法を記載します。

#前提
AWS上に構築したWordpressは以下のようなアーキテクチャで動作しています。
route53は使用しないシンプルな構成になってます。

　インターネット
　↓
　ALB(セキュリティーグループのインバウンド設定:http,https)
　↓
　EC2(セキュリティーグループのインバウンド設定:http)

#事象
504 gateway timeoutが頻発した。
うまく表示される時もあれば、うまくいかないこともあったりと不安定な状態。
またページの読み込みもなんだか遅いような感覚。

#解消方法
上記の前提にもあるようにALB→EC2の通信は httpでしか疎通しないアーキテクチャになっている。

ALBのターゲットグループを確認したところ、http,httpsの両方が設定されていた。これをhttpのみ設定したところ504の事象が解消し、ページの読み込みが早くなった！

おそらくALBからhttpsでEC2に送った際に、EC2側で

【AWS完全に理解したへの道】データベース(RDS/ElastiCache/DynamoDB)基本編

[【AWS完全に理解したへの道】 VPC 基本編](https://qiita.com/y-u/items/40fa729d54ebab52fcb3)
に続く、データベース(RDS/ElastiCache/DynamoDB)基本編(項目の然るべき順序的なものは後で整理するかも)

AWSが提供しているデータベースサービスは以下の4つ。

1. リレーショナルデータベースサービス ： RDS
2. NoSQLデータサービス : DynamoDB
3. インメモリキッシュサービス : ElastiCache
4. データウェアハウスサービス : Redshift

## 1. RDS
RDSで選択できるデータベスエンジンは以下6種類。

1.1 Amazon Aurora
1.2 MySQL
1.3 MariaDB
1.4 PostgreSQL
1.5 Oracle
1.6 Microsoft SQL Server

### 1.1 Amazon Aurora
Amazon AuroraはMySQLと互換性のあるAWS独自のリレーショナルデータベースエンジン。
※各データベースエンジンの差

ElastiCache サービスの導入 – Nextcloud 環境の構築を通じて AWS での環境構築を体験する②

「Nextcloud 環境の構築を通じて AWS での環境構築を体験する」 の第 2 回となります。

これまでの記事が下記からどうぞ。

* 【第1回】[EC2 と RDS を利用した Nextcloud 環境の構築](https://qiita.com/S_Katz/items/756ca04ecece844ce503)

# はじめに
今回は、[前回記事](https://qiita.com/S_Katz/items/756ca04ecece844ce503) で作成した環境構成から キャッシュサービスである Redis を分離してみます。
この Nextcloud 環境において、 Redis は次の役割を担っております。

* セッション情報の保持
* ファイルロック情報の保持

このサービスを分離することで、将来的に EC2 サーバーをロードバランサ等を利用して複数台運用としても、上記情報を Web サーバーで共有することができるようになります。

前回の記事で環境を構築して Nextcloud の環境を少し理解されている方であれば、「あれ、他にも分離しなきゃいけないやつ

Cloud9とGithubを連携する方法

### 前提
* Githubのアカウントを持っている
* Cloud9を使用できる状態

### Cloud9でSSH認証の公開鍵を作成する
1. ./sshに移動する
`$ cd ~/.ssh`

2. 公開鍵を作成する
`$ ssh-keygen`

色々聞かれますが、とりあえずはEnterで進めて大丈夫です。

3.公開鍵ができているか確認する
`$ ls`

コマンド実行後、id_rsaとid_rsa.pubというファイルが出来てたらOKです。
→id_rsa.pubファイルの中身が公開鍵になります。

4.公開鍵をコピーする
`$ cat id_rsa.pub`

実行後に表示された、文字列をコピーしてください。

### Githubに公開鍵を登録する

Githubの`Settings`→`SSH and GPG keys`→`New SSH key`をクリック

![スクリーンショット 2020-01-11 0.34.04（2）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/32887

AWS CLI アカウントを切り替える方法

# はじめに
AWS CLIをインストールして便利になったんですが、
なぜか動かない（パスが通ってなかった）とか別のアカウントで操作したいけどどうすればいいか分からないとか、
時間がかかってしまったので、ここでまとめさせていただきます。

他にはまってしまっている方の役に立てば・・と思います。。

# AWS CLI
AWS コマンドラインインターフェイス (CLI) の略。
AWS サービスを管理するための統合ツールで、ターミナルにて操作できる。

## インストール
インストールについては下記リンクをご確認ください。

* AWS CLI のインストールと設定
* https://docs.aws.amazon.com/ja_jp/streams/latest/dev/kinesis-tutorial-cli-installation.html

## パスを通す
パスを通さないと動かないのでご注意を。。

“`
// ${ユーザー名}には、各環境毎に変更してください。
$ export PATH=/Users/${ユーザー名}/Library/Python/3.7/bi

特定のS3バケットのみ一覧表示と読み書きを許可するIAMポリシーの例

“`
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“s3:ListBucket”,
“s3:GetBucketLocation”,
“s3:PutObject”,
“s3:GetObject”,
“s3:DeleteObject”
],
“Resource”: [
“arn:aws:s3:::<バケット名>“,
“arn:aws:s3:::<バケット名>/*”
]
}
]
}
“`

はじめてAWSでデプロイする方法③（AWSセキュリティグループの設定）

## これまでの記事
[はじめてAWSでデプロイする方法①（インスタンスの作成）](https://qiita.com/nousi/items/f0ab345402362e43db80)
[はじめてAWSでデプロイする方法②（Elastic IPの作成と紐付け）](https://qiita.com/nousi/items/0fe964f0be7e1cfa2ca1)

## 前回までの流れ
作成したEC2インスタンスとElastic IPを紐付けして、パブリックIPを固定にした。

## 今回の流れ
###現状
現時点において、HTTP（www.サイトURL）で接続することはできない。
（ターミナルでEC2とSSH接続は可能。）

つまり、一般ユーザーは閲覧することはできない状態である。
なので、

EKSでPrivate IPが足りなくなった場合の対処

# はじめに

ある日、EKSで新しいServiceを作ろうとしたところ、Subnet内に利用可能なPrivateIPが足りずに失敗した。

“`
Warning CreatingLoadBalancerFailed 7m12s service-controller Error creating load balancer (will retry): failed to ensure load balancer for service xxxxx: InvalidSubnet: Not enough IP space available in subnet-xxxxx. ELB requires at least 8 free IP addresses in each subnet.
“`

このSubnetのサブネットマスクは255.255.255.0なので、256弱のPrivateIPが使えるはずであるが、各Node(m5.xlarge)に30のPrivateIPが割り当ていることが原因でPrivateIPが枯渇していた。

# ENIの割り当て

ENIの割り当て方法

VPC再構築に伴うDirect Connectとサイト間VPN接続の移行について

とあるAWS環境でDirect Connectでの接続と、VPN接続を両方行っているVPCの再構築を行うことになりました。
当初は「うわ、ルータ設定とか全部やり直しになんの！？」って思っていましたが、調べてみたら全然簡単でした。

だいぶ端折っていますが、環境はこんな感じ。


### AWS側
– 現行VPC(10.0.0.0/16)
– 新規構築VPC(新しいCIDRで再構築 10.1.0.0/16)
– VGW(これが無いと始まらない)
– Direct Connect Gateway(VGWを関連付け)
– カスタマーゲートウェイ(サイト間VPN用設定に必要)

### オンプレミス(顧客)側
– サブネット(10.100.0.0/16)

### オンプレミス(オフィス)側
– サブネット(192.168.0.0/24)

で、実際に

ローカル端末からEC2へホスト名でSSH接続する

#やりたいこと
AWS上に構築したEC2へローカル端末からホスト名でSSH接続できるようにしたい。

##構成

##AWSの設定
■セキュリティグループ
　・test-aに対するインバウンド
　　- TCPの22番ポートを許可
　　- ソース：マイIP
　・test-bに対するインバウンド
　　- TCPの22番ポートを許可
　　- ソース：10.0.1.0/24

##test-aの設定
[/etc/hosts]にtest-aとtest-bの情報を記載

“`
10.0.1.100 test-a
10.0.2.100 test-b
“`
##ローカル端末の設定
①[~/.ssh]配下に鍵ファイルを格納

②[~/.ssh]配下に[config]ファイルを作成し、以下を記載

“`
Host test-

ServerlessFramework+Slackで運行遅延情報をお知らせする

# はじめに
AWSLambdaで運行遅延情報をslackに通知するbotを作りました。
[運行遅延API](https://rti-giken.jp/fhc/api/train_tetsudo/)を利用して、遅延が発生して入れば運行会社のWEBから遅延内容をスクレイピングしてSlackにお知らせします。
何番煎じか分かりませんが、lambdaとnodejsで書かれた記事が見当たらなかったので紹介します。

# 作ったもの

GitHub
https://github.com/t-yasukawa/incoming-webhook

# 環境
– macOS Catalina 10.15.2
– VSCode 1.41.1
– AWS(Lambda, CloudFormation)
– Server

はじめてAWSでデプロイする方法②（Elastic IPの作成と紐付け）

## 前回の記事
[はじめてAWSでデプロイする方法①（インスタンスの作成）](https://qiita.com/nousi/items/f0ab345402362e43db80)の続きになります。
インスタンスの作成などを知りたい場合は、この記事を参照してください。

## 今回実施していくこと
作成したEC2インスタンスには、作成時にIPアドレスが””自動””で割り振られています。
これをパブリックIP（一般公開用のID）と言います。
しかし、””サーバーを再起動させるたびにこのパブリックIPが変わってしまうという欠点””を持っています。

そのため、パブリックIDを固定して、いちいち更新しないようにします。
この固定化したパブリックIDを『　Elastic IP　』と呼びます。

今回はその欠点を改善するために、『　EC2インスンタンスとElastic IP紐付け　』をしていきましょう。

## Elastic IPの作成
Elastic IPとは、AWSから割り振られた固定したパブリックIPアドレス。
このパブリックIPアドレスをEC2インスタンスに紐付けることで、インスタ

IoT@Loft ハンズオン #2 – Amazon FreeRTOSを用いた量産向けIoTマイコンデバイス開発プロトタイピング(2020年1月8日実施）を受講したよ

2020年1月8日　IoT@Loft ハンズオン #2- Amazon FreeRTOSを用いた量産向けIoTマイコンデバイス開発プロトタイピングが実施されました。
https://iotlofthandson2020jan.splashthat.com/

第1回AWS IoT@Loft スマートファクトリー IoT基盤構築プロトタイピングの2回目になります。
今回はSTM32を使用しAmazonFreeRTOSを触るハンズオンになります。
https://qiita.com/usashirou/items/426c2e96e7568b708ade

##使用機材：STM32L4 Discovery kit IoT node
https://www.stmcu.jp/design/hwdevelop/discovery/51734/
AmazonFreeRTOSは、STM32L4 Discovery kit IoT node用が用意されています。
はじめてAWSでデプロイする方法①（インスタンスの作成）

## AWSアカウントのリージョン設定をしよう
リージョンとは、AWSの物理的なサーバの場所を指定するものです。リージョンは世界各地に10箇所以上存在し、そのうちの一つは東京にあります。
リージョンを東京に設定していきましょう

### 手順
1. 　[コンソールにアクセス](https://ap-northeast-1.console.aws.amazon.com/console)　

2. 画面右上にある『　国　』を『アジアパシフィック（東京）を選択』

## EC2インスタンスを作成
「サーバーを生成する」といっても、AWSが全てのサーバを物理的に用意しているわけではなく、実際には「仮想マシン」と呼ばれるソフトウェアを利用しています。
この「仮想マシン」のことをAWSでは「EC2インスタン

AWS API GatewayのHTTP API(β版)がLambda関数に渡す値が想定と違っていた話

最近 AWSのAPI Gatewayに、HTTP API(β版)が実装された。
試してみたところ、ちょっとハマったので備忘録に。

“`html

“`
まずは、ありきたりなフォームを作成して、作成したHTTP APIにsubmitする。
統合先のLambda関数で確認すると、bodyの情報がREST API(Lambdaプロキシ統合を使用)のときと違う。

“`javascript
// Lambda関数(Node.js 12.x)
exports.handler = async event => {
console.log(event.body);
// REST API(Lambda

AWSに構築したWordPressをhttps対応してみた

# はじめに
「[AWSにWordPressを構築してみた](https://qiita.com/olaf_system/items/e5e17cd8ead71ec9a096)」
「[AWSに構築したWordPressに独自ドメインを割り当ててみた](https://qiita.com/olaf_system/items/46723a020456120ffd65)」
の続き。
WordPressを構築して独自ドメインを割り当ててSSL対応したところまで終わった。
が、WordPress側がhttpsに対応してないのでデザイン崩れが発生しているのと
httpでのアクセスがまだできる状態なのでその２つを対応していく。

# https対応設定
現状、こんな感じ。
LambdaでCognito認証(ユーザー認証)

#はじめに

SDKをローカルに持ってきてゴニョるサンプルは検索に引っかかるのですが、
クラウド側(Lambda関数内部)で完結するサンプルが見つからない…
よし、ならば投稿してしまえ。

[トップ](https://qiita.com/minmax/items/a36b081c073eff4a6533)
├[ユーザー作成](https://qiita.com/minmax/items/8c2aa57b76e09b8192ed)
├[ユーザー確認](https://qiita.com/minmax/items/ed4f81e61c2617d5c6cf)
└__ユーザー認証__　←イマココ

#ユーザー認証 (InitiateAuth)

##概要
通知されたIDとパスワードの組み合わせが正しいかを検証します。
登録された情報と一致した場合、ユーザー認証に必要なIDトークンを発行します。

##ドキュメント
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CognitoIdentityServiceProvider.ht

LambdaでCognito認証(ユーザー確認)

#はじめに

SDKをローカルに持ってきてゴニョるサンプルは検索に引っかかるのですが、
クラウド側(Lambda関数内部)で完結するサンプルが見つからない…
よし、ならば投稿してしまえ。

[トップ](https://qiita.com/minmax/items/a36b081c073eff4a6533)
├[ユーザー作成](https://qiita.com/minmax/items/8c2aa57b76e09b8192ed)
├__ユーザー確認__　←イマココ
└[ユーザー認証](https://qiita.com/minmax/items/12e65cd51d85f419faa5)

#ユーザー確認 (ConfirmSignUp)

##概要
作成したユーザーの連絡手段(メールアドレスor電話番号)が有効か確認します。
通知された確認コードが正しければ、ユーザーのアカウントステータスを「CONFIRMED」にします。

##ドキュメント
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CognitoIdentit

LambdaでCognito認証(ユーザー作成)

#はじめに

SDKをローカルに持ってきてゴニョるサンプルは検索に引っかかるのですが、
クラウド側(Lambda関数内部)で完結するサンプルが見つからない…
よし、ならば投稿してしまえ。

[トップ](https://qiita.com/minmax/items/a36b081c073eff4a6533)
├__ユーザー作成__　←イマココ
├[ユーザー確認](https://qiita.com/minmax/items/ed4f81e61c2617d5c6cf)
└[ユーザー認証](https://qiita.com/minmax/items/12e65cd51d85f419faa5)

#ユーザー作成 (SignUp)

##概要
通知されたIDとパスワード(とその他の情報)でユーザーアカウントを作成します。
続けて、登録したメールアドレスor電話番号に確認コードを通知します。

##ドキュメント
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CognitoIdentityServiceProvider.html

LambdaでCognito認証

#はじめに

SDKをローカルに持ってきてゴニョるサンプルは検索に引っかかるのですが、
クラウド側(Lambda関数内部)で完結するサンプルが見つからない…
よし、ならば投稿してしまえ。

__トップ__　←イマココ
├[ユーザー作成](https://qiita.com/minmax/items/8c2aa57b76e09b8192ed)
├[ユーザー確認](https://qiita.com/minmax/items/ed4f81e61c2617d5c6cf)
└[ユーザー認証](https://qiita.com/minmax/items/12e65cd51d85f419faa5) ※なお、続く認可はAPI Gatewayのオーソライザーにお任せします。

※メインはLambda関数のコードの紹介です。付随する情報は簡潔に記します。

#概要
ローカルにダウンロードしたSDKを使うのではなく、
クラウド側で用意されているSDKを使ってCognito認証しよう。
というのが今回のコンセプトです。

↓こちらを使います。
https://docs.aws.amazon.com/A