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

Developers.IO 2019 Tokyo 登壇資料・レポートまとめ

## 2019年11月1日 ベルサール日本橋 開催のまとめです

– 本家のまとめ
https://dev.classmethod.jp/series/developers-io-2019-tokyo/
– 関連ツイートまとめ
https://togetter.com/li/1424055

## 注意事項
– 1日参加した自分向けのまとめでもあるので厳密な精査はしてません
– 登壇資料とレポートが少しごっちゃになっています
– 追加・修正があれば、コメントにてご指摘ください
– 本家だとプログラムに沿ったまとめが無かったのでまとめました

## まとめ

場所 | 時間 | セッション名 | 発表者 | URL
— | — | — | — | —
2 | 1 | 認証の標準的な方法は分かった。では認可はどう管理するんだい？ | 都元ダイスケ | https://www.slideshare.net/daisuke_m/cmdevio
3 | 1 | カルチャービルディング〜世界最強のAWSエンジニア集団の作り方〜 | 西澤徹訓 | https://dev.cla

RailsアプリでELB(AWS)をエンドポイントに常時SSL化したらアプリにアクセスできなくなった

一度デプロイに成功したアプリケーションが常時SSL化をしたところ、pcからならアクセスできるけどスマホからだとアクセスできない、なんてことになりました。

ものすっごい初歩的なところで１日かけてしまったので、自分への戒めも含めて投稿しようかと思います。

## 前提

・EC2インスタンスランニング状態(ポート：HTTP 80を開き、ソースはロードバランサのセキュリティグループを指定)
・ロードバランサのターゲットグループのステータスはHealty(ポート：HTTP 80を設定)
・ロードバランサのDNS名にはAレコードが設定されている
・ロードバランサのリスナー：HTTPS 443 (SSL認証書も紐づいている)
・コンソールからec2-userにログイン可能
・本番環境内のproduction.logにはFatalやErrorの記述なし
・Capistranoの自動デプロイにエラーなし

##### しかしアプリにアクセスできたりできなかったりする！！

## 結論

##### ELBのセキュリティグループインバウンドでソースにマイIPを指定していた

つまり、自宅のWifiな

AWSのVPC作成からEC2にsshログインまで

#AWS立ち上げ

今回、AWSを使用してEC2インスタンスにsshログインするまでの記事を投稿する

約一年ほど前にAWSでサーバを立ち上げてJavaやRDSを使用してネットワークやプログラムの
学習を行なっていたが諸事情により途絶えたので再開する

本記事の基本的な流れとしては下記になる
VPC作成→サブネット作成→EC2配置→sshログイン

##VPC作成(サブネット作成)
アプリケーションのプラットフォームを作成する
VPC環境をAWSコンソールから作成し、EC2のプラットフォームを作る

下記のキャプチャより、AWSコンソール画面のメニュー選択からネットワークとコンテンツ配信からVPCを選択する。

去年作成したが、あまり覚えていない・・・
どうやら下記がメインとなる設定画面のようだ

Alexaスキル(APL対応&スキル内課金あり)を開発したときにハマった5つのポイント（スキル名：マッチファンタジー）

初投稿です。
この度、初めてのAlexaスキルをストアに出しました。
今回は、画面付きのデバイスが増えている背景もあり画面付きデバイスに対応したスキルを開発したのですが、実装時にハマったポイントを共有しようと思います。

# どんな人が書いたの？
・Alexaスキルの開発は初めて
・個人でのWebアプリやスマホアプリ開発経験あり
・業務としての開発経験無し
・使える(触ったことある)言語はC#,F#,jｓ,python,ruby,C,Dart,etc…

# 対象読者
・Alexaスキルをこれから作ってみたいと思ってる人
・画面付きデバイス(Echo Show 5 等)用のスキルを開発したい人
・javascriptが読める人or何かしらプログラミングしたことある人

# 作ったスキル
マッチ売りの少女をモチーフとした様々な物語を毎日一話ずつ(スキル内課金すればいくつでも)聴くことが出来るスキルです。
また、物語の途中で選択肢が現れ、その選択肢によって後半のストーリーが変わるというアドベンチャーゲームのような要素もあります。

「マッチファンタジー」という名前で現在Amazonのス

Rails6のActionDispatch::HostAuthorizationとELBのヘルスチェックの共存

Rails6の[ActionDispatch::HostAuthorization](https://github.com/rails/rails/pull/33145)設定と[okcomputer](https://github.com/sportngin/okcomputer)を利用した `Nginx – Rails – RDS` という経路のヘルスチェックの共存に少しコツが必要だったので記事にしました。

## ActionDispatch::HostAuthorization
https://github.com/rails/rails/pull/33145
Rails6から追加された、[DNSリバインディング攻撃](https://en.wikipedia.org/wiki/DNS_rebinding)から保護する新機能です。

下記のように設定することで、指定したホスト以外からのアクセスはエラーとなります。

“`ruby
Rails.application.config.hosts << "product.com" ``` ## okcomputer https://

AWSで作成したWordPressのサイトをSSL化する

##はじめに
自分はインターネット初心者です。
無料枠が残っているAWSを有効活用するためにEC2を使い、WordPressでブログでも書こうと思った際、SSL化がよくわからなかったので記事に残しておく事にしました。
正直なぜこれで動いてるのかわかりません。(色々な記事を参考にしてもうまくいかなかった)
この記事を参考にしてSSL化する際は自己責任でお願いします。

##いろいろやる
Certificate Managerで証明書を発行し、ロードバランサーの作成、Route 53でドメイン名とELBとの関連付けまでは他の方々と同じです。
##WordPressにログインし、プラグインをインストール
WordPressにログイン後、メニューの「プラグイン」から「新規追加」を選択。
AWS Cloud9でherokuコマンドがnot foundになった時の対処法

Railsチュートリアルの6.4でherokuコマンドを見失ったので対処法のメモ。
１．herokuコマンドみつからないエラー
　■入力したコマンド
　`$ heroku run rails db:migrate`

　■エラー内容
　`bash: heroku: command not found`

　■やったこと
　[Cloud9でHerokuが使えない時の対処法](https://qiita.com/bdogrep/items/8620dbba5e4c3fd859df)

　■結果
　上記記事内のコマンドを上から実行していったときに、新たなエラーに遭遇。

２．herokuをアップデートしなさいエラー
　■エラー内容
　$ heroku -v
　 › Warning: heroku-cli update available from 7.0.9
　 › to 7.29.0.

　■やったこと
　`$ heroku update`

　■結果
　heroku-cli: Updating CLI… not updatable

３．herokuアップデートできませんエ

CloudWatchLogsのログをElasticSearchに流す

# 概要
CloudWatchLogsからElasticSearchにログを流します。
ログを流す際にLambdaを経由する形になります。

CloudWatchLogsのアクションからロググループを選んで「Amazon Elasticsearch Serviceへのストリーム」を選択します。

あとは画面に従って設定するだけです。

# 注意点

## ロール
VPC内のElasticSearchに書き込みたい場合はLambdaにAWSLambdaVPCAccessExecutionRoleをつけましょう。

## セキュリティーグループ
ElasticSearchにアクセスできるようにセキュリティグループを設定してください。

## Lam

【AWS EC2】Amazon Linux 2にJenkinsをインストールする

# 概要
AWS EC2(AMI: Amazon Linux 2)にJenkinsをインストールして8081番ポートでアクセスできるようにする

## 環境
– AWS EC2
– OS: Amazon Linux 2
– AMI ID: amzn2-ami-hvm-2.0.20190823.1-x86_64-gp2
– セキュリティグループ: SSH 22 / TCP 8080 / TCP 8081 を開けておく
– Jenkins
– version: 2.202

# 構築手順
## 1. JDK 8 をインストール
– Amazon Linux 2にはデフォルトでJavaが入っていないのでインストールする
– Jenkins 2.164(2019-02)以降はJava 8 or Java 11が必要

“`console
$ sudo yum install -y java-1.8.0-openjdk-devel.x86_64
$ sudo alternatives –config java
$ java -version
openjdk version “1.

マルチクラウド環境におけるサーバ証明書の運用　Let’s Encrypt/AWS/Azure

# はじめに
本記事は、マルチクラウド環境におけるサーバ証明書の運用についての記事になります。

マルチクラウド環境でサーバ証明書を使用している場合は、環境によって対応手順が異なります。また、ワイルドカードでサーバ証明書を取得していている場合は、留意事項があるケースが多いので注意が必要です。

本記事では、実際に運用での失敗を経験した上で、サーバ証明書の運用時のポイントなどを簡潔にまとめています。

## サーバ証明書の発行

### Let’s Encrypt
Let’s Encryptでサーバ証明書を発行する場合は、certbotをインストールして発行します。Standaloneプラグインを使用する際は、以下のコマンドを実行します。Webサーバーを停止させずにサーバ証明書を取得したい場合は、Webrootプラグインを使用します。

`# certbot certonly -a standalone -d ＜URL＞ –email ＜メールアドレス＞`

ワイルドカードの場合は、以下のコマンドを実行します。

`# certbot certonly –manual -d ‘*.

AWS Lambdaでのコールドスタートのメモリの罠と、Invoke Lambdaでのタイムアウトの罠

# 問題の経緯
API Gateway経由、ALB経由でAPI化しているLambdaを構築していた。
ALB経由Lambdaの中には、VPCに含んでいるものもあった。
そのLambdaからは別のLambdaもいくつかInvokeしていた。
実装を一通り終わってテストしていると、どうもレスポンスが早いときと、遅いとき、酷いとタイムアウト（API Gatewayは30秒制約あるし。。）することがあった。

# 調査した結果
調査してみると、どうにもInvokeしている部分が怪しかった。
やっぱりVPC Lambdaだとコールドスタートのせいで遅いのかなぁと思いながらログから調査していった。
Invoke自体は実行されているが、何故かInvoke先のLambdaにログが来ていない。。。。
もしかして、コールドスタートから起き上がる前にタイムアウトしてる？？と思い、Lambda関連のドキュメントを漁りながら、やっぱりLambdaを定期実行して、コールドスタート回避するしかないのかなぁと思っていると下記の記事を発見。。。。
[VPC Lambdaのコールドスタートにお悩みの方へ捧ぐコールドスター

CloudFormationでDynamoDBのオートスケーリングを設定する

# テンプレート

“`yaml
AWSTemplateFormatVersion: 2010-09-09
Resources:
sampleScalableTarget:
Type: “AWS::ApplicationAutoScaling::ScalableTarget”
Properties:
MaxCapacity: 100 # 最大キャパシティー
MinCapacity: 1 # 最小キャパシティー
ResourceId: !Sub table/sample-table # テーブル名を指定する「table/」の後にテーブル名を指定する
RoleARN: !GetAtt ScalingRole.Arn
ScalableDimension: “dynamodb:table:ReadCapacityUnits” # 書き込みキャパシティーユニットの場合は、「dynamodb:table:WriteCapacityUnits」
ServiceNamespace: dynamodb
sa

CodePipeLineからLambda呼び出しを行うCloudFormationテンプレートの定義

# はじめに
CodePipeLineが終わったらSlackに通知を送るために、最後にLambda呼び出したかった。
作成したものを備忘として記録。

# テンプレート

“`yaml
# CodePipeLine
Pipeline:
Type: AWS::CodePipeline::Pipeline
Properties:

・・・(lambda以外は省略)

Stages:

・・・(lambda以外は省略)

– Name: lambda
Actions:
– Name: lambda
ActionTypeId:
Category: Invoke
Owner: AWS
Version: 1
Provider: Lambda
Configuration:

AWSについて

# AWSについて
– 自分のメモ書きなのでそのへんはご了承ください
– AWSはIaaSのため、コンテナ化を想定している

## ECR
– Amazon ECR は、Docker コンテナイメージの保存と管理を容易にする高可用性でセキュアなプライベートコンテナレポジトリです。

## ECS
– Amazon ECS は AWS クラウドで Docker コンテナを実行するための高度にスケーラブルで、高パフォーマンスのコンテナオーケストレーションサービスです。
– kubernetesを適度に簡単にしてくれたもの
– 起動タイプが2つある。
– fargate起動タイプ
– EC2起動タイプ

## Fargate
– AWS Fargate は、インフラストラクチャのデプロイや管理をせずに Docker コンテナを実行できる Amazon ECS のテクノロジーです。
– Fargate 起動タイプでは、お客様に必要なのは、コンテナ内のアプリケーションのパッケージ化、CPU 要件やメモリ要件の指定、ネットワーキングポリシーや IAM ポリシーの定義、アプリケーションの起動

AWS re:Invent チケット売り切れの歴史

#はじめに
2012年から毎年年末にラスベガスで開催しているAWSの年次イベント AWS re:Invnet のチケットは毎年売り切れるほど人気があるプレミアチケットです。
2019年のチケット（Full conference pass）代は1799USDです。
購入を迷っていると売り切れてしまうことがありますので、例年の売り切れ傾向を調べてみました。

# 売り切れ年表
確認できる範囲でいつ売り切れたのか調べてみました。
なお、ソースとなる情報は公式もしはそれに準じるものを優先しています。公式情報が見つからなかった場合は個人/企業のブログ記事の日付を参考にしております。

| 開催年 | 開催期間 |売り切れ日|ソース|
|—|—|—|—|
|2012 | 2012/11/27～11/29 | 2012/11/09 |https://twitter.com/awsreinvent/status/266626817362911232 |
|2013 | 2013/11/12～11/15 | 不明 |N/A |
|2014 | 2014/11/11～11/14 | 201

毎週起動する RDS を毎週停止させる CodeBuild

# 背景

RDSの停止ができるようになりましたが、停止してから1週間経過すると、ふたたび起動してきます。停止したのは、停止しておきたい理由があるから停止したのに、おまえ何で起動さした？

毎週手作業でやるのも微妙。Lambdaでbotoするのを書くのもダルい。

CodeBuild で毎週実行させて awscli でやるのが究極に簡単でした。

# buildspec.yml

コンテナイメージは awscli が入るなら何でも良いです。作例では `amazonlinux:2` を使っています。

“`yaml
version: 0.2

env:
variables:
RDS_NAME: “RDSインスタンス名”

phases:
install:
commands:
– yum install -y awscli
build:
commands:
– aws rds stop-db-instance –db-instance-identifier ${RDS_NAME}
“`

# IAM

CodeBuild

AWSのポリシー一覧

英語が読めないので噛み砕いた日本語に翻訳しますlol
一応ほどほどにアクセス検証も行なっております。

# ポリシーの注意事項
・**カスタムポリシー**：自分でゼロから作れるポリシー。使い回しできます。
・**インラインポリシー**：カスタムポリシーのように細かく設定できますが、使い回す様な保存はできません。

# Lambda
## ・Lambdaで関数を作成する

| サービス名 |実際の表記 |あればリソース|そして解説 |
|:—————–|—————|——-|————————————————–|
| Lambda　　　　　　　　|lambda:CreateFunction||Lambdaの関数の作成
※リソースが必要|
||〃|全てのリソース|とりあえずこれにしておいて|
|IAM|iam:PassRole|arn:aws:iam::*:role/{Lambda関数名}|Lambda関数名から始まるロールを既存のロールとして読み込

AWSへデプロイしてみよう（〜仮想サーバへデプロイ その４）

## 13.EC2でのデータベースの設定
まずは PostgreSQL をインストールします。

“`
$ sudo su –
$ yum -y install postgresql94 postgresql94-server postgresql94-devel postgresql94-contrib postgresql94-docs
$ /etc/init.d/postgresql94 initdb
[起動]
$ /etc/init.d/postgresql94 start
“`

設定ファイルを編集します。

“`
$ vi /var/lib/pgsql94/data/postgresql.conf
“`

三番目のトピックにある、listen_addressesのコメントを解除（先頭の#を削除）して、設定を’localhost’から’*’に編集してください。

“`

#——————————————————————————
# CONNECTIONS AND A

AWS（EC2）でwordpressとphpmyadminをサクッと立ち上げる

AWS（EC2）では、WordPress＋phpmyadminのマシンイメージが用意されています（MarketPlace）。イメージを利用すれば、サクっと立ち上げてphpmyadminまで直ぐに使えてテスト等に便利です。ここでは、およそ10分（＋待ち時間5分）でphpmyadminへ最速でアクセスする迄の手順をご紹介します。

# 事前に用意するもの
awsアカウント（無料枠で十分）
putty / puttygen（他のターミナルでもOKです）

# インスタンス作成

まず、EC2インスタンスを作成します。「インスタンス作成」ボタンを押し、「ステップ 1: Amazon マシンイメージ (AMI)」画面で「AWS Marketplace」→検索窓で「wordpress」→「WordPress Certified by Bitnami and Automattic」で「選択」ボタンを押します。
![01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280104/a10bf567-9f25-c949-

EC2 AutoScaling を初めて試そうとした場合にスケーリングが動かなかった話

# 経緯

– EC2 AutoScaling の検証のために自分のAWSアカウントに初めてScaling Groupを生成
– コンソールから実施していたが、この時生成に失敗
– しばらく経過して再生成すると成功
– CPUを `yes >> /dev/null` で 100% にしてみたものの、待てども待てどもスケーリングが開始されない

# 理由

– 初回生成時のエラーは初回IAM Roleの生成エラーによるもの
– 結果、スケーリングルールに紐づくCloudWatch 系列が一切作成されない状態でスケーリングポリシーが作成されてしまっていた
– インスタンス数の増減のイベントはCloudWatchのアラームベースなので、当然インスタンス数の増減も発生しない (手動でterminateすると元の希望数に保ってくれる動きは見せてくれたが)

# まとめ

AWS Management Consoleは便利ですが、ちょくちょくこういったリソース生成の順序周りでエラーが発生する気がします（忘れたけど、何回か遭遇した気がする）。
生成時にエラーが出た場合、そのタイミングで生成されたリソ