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

マルチクラウド環境におけるサーバ証明書の運用　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は便利ですが、ちょくちょくこういったリソース生成の順序周りでエラーが発生する気がします（忘れたけど、何回か遭遇した気がする）。
生成時にエラーが出た場合、そのタイミングで生成されたリソ

コンテナ上からbastion経由でRDSに接続する

#はじめに
Docker container上で動くPythonからAWSのRDSインスタンスに接続したくなりました。

VPCのプライベートサブネットにRDSを配置しているために直接接続することができないため、
パブリックサブネットにEC2インスタンスを立ててBastion（踏み台）として機能させます。
というのが以前までのベストプラクティス？のようでした（[注記](#注記)参照）。

今回も上記方法で接続してみました。

#前提
AWS RDSインスタンスが構築されていること。
bastionとして機能させるEC2インスタンスが立ち上がっていること。
RDSのセキュリティグループでEC2(bastion)からの接続が許可されていること（[参考ページ](https://dev.classmethod.jp/cloud/aws/rds-portforward/#toc-2)）。
EC2(bastion)のセキュリティグループでSSH接続が許可されていること。

検証環境
Windows10 Pro
Docker for Windows 2.1.0.3
RDSインスタンス：MySQL 5

Amazon ECRのイメージスキャン結果をSlackに通知する

## はじめに
2019/10/28 Amazon ECR でコンテナイメージの脆弱製スキャン機能が利用可能になりました！
しかもスキャン機能自体の利用は無料です。最高。
https://aws.amazon.com/jp/about-aws/whats-new/2019/10/announcing-image-scanning-for-amazon-ecr/

いずれ [AWS Chatbot](https://aws.amazon.com/jp/chatbot/) が対応してくれそうですが、
それまでの繋ぎでスキャン結果を Slack に通知する Lambda 関数を作成しました。
Amazon EventBridge（CloudWatch Events）と組み合わせて利用します。
## 結果イメージ
イメージ名をクリックするとスキャン結果の

Linuxのバージョンを確認する方法

# コレを実行する
“`text
# CentOS, RedHat系
$ cat /etc/redhat-release

# Amazon
$ cat /etc/system-release
“`

## こんな感じになる
– 環境 : MacのVirtualBoxに作った仮想マシンのCentOS

– 環境 : AWSのインスタンス

“`bash
# CentOS
$ cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
# Amazon
$ cat /etc/system-release
Amazon Linux release 2 (Karoo)
“`

# 参考
– [付帯手順 – さくらVPSのCentOSバージョン確認](ht

GitHub の Permission denied (publickey) で躓いたけど解決した時の話

#はじめに
AWSにRailsアプリをデプロイする過程で、
Gitとの連携がうまくいかなかったので、解決策をメモに残します。
##接続確認
鍵登録後 SSH コマンドで GitHub に挨拶してみます。

“`
$ ssh -T git@github.com
を実行してみて、

Hi [account_name] You’ve successfully authenticated, but GitHub does not provide shell access.
がかえってくれば接続 OK です。
これを目指します。
“`
##パーミッションをチェックする
今回は大丈夫でしたが
鍵のパーミッションがゆるい場合、以下のように
デカデカと警告が出るのでこちらはすぐ分かります。

“`
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

サーバーの PHP バージョンは 5.3.29 ですが WordPress 5.2.4 は 5.6.20 以上のみでご利用になれます。への対策

「AmazonWebServices基礎からのネットワーク＆サーバー構築 改訂版」でハンズオンに挑戦中です。

良著ですがAmazonのレビューにもあるように、出版から時間が経っているので、そのままやるとハマります。

## 環境
– MacOS 10.14.6
– WordPress 5.2.4

## エラー内容

『8-3 WebサーバーにWordPressをインストールする』で、WordPress:latest(5.2.4)をインストール後、Apacheを再起動するとトップページにエラー。

`「サーバーの PHP バージョンは 5.3.29 ですが WordPress 5.2.4 は 5.6.20 以上のみでご利用になれます。」`

もしくは

`「お使いのサーバーの PHP では WordPress に必要な MySQL 拡張を利用できないようです。」`

## 解決法

WebサーバーのPHPと関連モジュールのバージョンを7.3にアップデートすると解決しました。

## 手順

※AWSでWebサーバーが構築されている状態を前提とします。

まず、現在のPHPのバージョン

AWS初心者がLambdaでLINE BOIを作る

LINE BOTでオウム返しのBOTを作ります。
正直AWSを触ったことが無いので、よく分からず困ったので同じように困る人が出ないように
記事にすることにしました。

言語・ツール選定
私はRaspberry pi & PHPでLine botを作ったことが有る。
内容としては位置情報を渡すと近くのコンビニを教えてくれるものだ。
しかし、Raspberry piでLine botを作ると、常にRaspberry piを起動しておく必要があり電力的に優しくなく、
サーバの構築や認証鍵の設定が面倒だった。
そこでサーバレスのLine Botを作ろうと思いました。
私が選択したのはLambda+Node.js。
選択肢としてGAS(Google App Script)もあったけれど今後の拡張性を考えた時、
ES6が簡単に使えない(変換すれば使えるが面倒な)のが嫌だと思ったのでやめました。

環境構築
LINE Developers
https://developers.line.me/ja/
↑LineBotを作るためにアカウント取得する
【公式】クラウドならアマゾン ウェブ サービス （A

AWS/GCP/OCIサービス比較

# AWS、GCP、OCI(Oracle Cloud Infrastructure)の主なサービス比較

|カテゴリ|AWS|GCP|OCI|
|:—-|:—-|:—-|:—-|
|リージョン|AZ(アベイラビリティ・ゾーン)|ゾーン|AD(Availability Domain(可用性ドメイン))|
|ネットワークおよびコンテンツ配信|VPC|VPC|VCN(Virtual Cloud Network)|
|ネットワークおよびコンテンツ配信|ELB(Elastic Load Balancing) |Cloud Load Balancing|Load Balancing|
|ネットワークおよびコンテンツ配信|DX(Direct Connect)|Cloud Interconnect|FastConnect|
|ネットワークおよびコンテンツ配信|サブネット|サブネット|サブネット|
|ネットワークおよびコンテンツ配信|ルートテーブル|ルート|ルートテーブル|
|ネットワークおよびコンテンツ配信|IGW(Internet Gateway)|IGW(Internet Gat

「セキュアで堅牢なAWSアカウント」を実現する CloudFormationテンプレート – ②パスワードポリシーの自動修復

# はじめに

AWSにはアカウントやリソースへの脅威検知に対応した、**AWS Security Hub**, **Amazon Inspector**, **Amazon GuardDuty**, **AWS CloudTrail**, **AWS Config** などのサービスが用意されています。

また、[**CIS AWS Foundations Benchmark**](https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf) という**セキュリティガイドライン**が公開されており、このガイドラインは、**AWSアカウントをセキュアに保つために必要なAWSのセキュリティ設定**を集めた**ベストプラクティス集**として活用できます。自身のAWSアカウントがこのガイドラインにどの程度準拠しているのかを確認/監査する手段として、**AWS Security Hub**で、**CIS AWS Foundations Standard**という機能が提供されています。

本

AWS環境改善メモ

# 前置き
– 基本の部分は情報あるけど、アカウントの分け方はあまり記事としてまとまってない

# 基本
– 親アカウントは1つだけど、子アカウントを色々作れるよ
– 子アカウントを適切に分けて作ると便利だよ

## Organization
– 親AWS account id = 契約（請求はここでまとまる）

## Unit
– 親アカウントから複数の子アカウントを作るだけでなく、グループ分けができるようになった
– ユニットは、作って階層構造の切り替えが比較的容易にできる
– ユニットにはSCPを設定できる

### 例
– UnitA <- SCP1 - account1 - account2 - UnitB <- SCP2 → IAM - account3 - account4 - UnitC ## SCP(サービスコントロールポリシー) - Allow - Deny ## アカウントの分け方 - アカウントをサービスごとに作る - ユニットを環境ごとに分ける ### 例 - Unit Service - 本番 - account-Servic