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

AWSサーバレスで（SPAではなく）画面遷移型のWebアプリをつくる

# 経緯
AWSサーバレスを採用してWebアプリ（画面）を作ることになりました。コンシューマ（一般ユーザ）向けの画面ではなく、企業向けの管理画面です。

メンバーの皆さんにReactとかを学んでいただく時間的な余裕はなかったため、SPAではなく、メンバーの皆さんに経験のある「画面遷移型」の構成にしました。

ただ、AWSサーバレスで画面遷移型のWebアプリを作る、という事例を見つけることができず、実現方式をあれこれ考える必要がありました。構成が固まるまでに悩んだことや、自分なりの解を記事にすることで、同じようなことに悩まれている方のヒントになればと思ってます。

# アーキテクチャ

ポイントは以下のとおりです。

* Lambdaでは[aws-

Amplify + AppSync(graphQL) + DynamoDB でどんな感じでリソース作られるのか見てみる

だいたいこのあたりのシリーズです。

Amplify + AppSync + Cognitoで読み書きの制御を試してみる
https://qiita.com/ikegam1/items/4868b8a2b473e7ec8f85

## やる事
amplify側で `amplify add api` やら `amplify push`やらするとして、DynamoDB側のGSIとか制御できるのかどうか気になったので試してみる回です。

## 目次

1. 初期設定
2. スキーマ作成
3. DynamoDB確認
4. 参考

## 1. 初期設定

今回は下記が終わっているものとします。

– amplify cilインストール (4.24.3 でした)
– `amplify add auth`によるcognitoの設定
– `npx create-react-app react-amplified` reactかつ *react-amplified* ってプロジェクトフォルダで進める
– プロジェクトフォルダ内での `amplify init`
– 実行環境はWSL2上のubuntu18

Amazon LightsailでFX自動売買サーバーを構築する

FX自動売買をするため、MetaTrader4（MT4）にてEA（自動売買プログラム）を
24時間365日動かす環境として、[Amazon Lightsail](https://aws.amazon.com/jp/lightsail/)を使ってみた

# 概要
## Amazon Lightsailとは
– VPS（仮想専用サーバ）を提供するサービス
– ネットワークからサーバーまでの構築および接続設定までマネージドされている
– 追加でELBによる冗長構成、RDS、CDNを利用可能
– バックアップをEC2にエクスポート可能
– 冗長構成をとっている場合はSLAは99.99%

### 最低限の料金
– インスタンス
– ストレージ
– データ転送（1TB/月を超えた分）

### EC2ではなくLightsailを選んだ背景
– とりあえず動かす環境がほしい
– 構築コストが比較的低い
– 細かいネットワーク要件は不要
– 非機能要件が難しくない
– 大量の通信なし
– 計算量も多くない（EAによる）
– 維持費が明確
– 導

ECSなコンテナにSSM Parameter Storeの値を渡して保持させる

# はじめに
ECSの環境変数機能のちょっとニッチな使い方。
コンテナに固め込んで起動することから、動的に変更することができなくなるので注意。環境情報はコンテナから切り離すというプラクティスから離れるアンチパターンであることを意識して、コンテナ化するプロダクトがクラウドにリフトするだけのケース等やむを得ない場合だけ利用することを推奨。

# SSM Parameter Storeの参照方法
コンテナのアプリケーションからSDKを使って参照するという方法もあるが、もっとお手軽に実装するのが、ECSの(正確にはタスク定義の)環境変数を使うのが良い。

[以前の記事](https://qiita.com/neruneruo/items/ff6747a4129a5b52e6c6#ecs%E3%81%A7%E3%82%82%E8%B5%B7%E5%8B%95%E3%81%97%E3%81%A6%E3%81%BF%E3%82%88%E3%81%86)で書いた「コンテナの編集」⇒「環境変数」から設定可能だ。プルダウンで「ValueFrom」を選択して、Parameter StoreのARNを指定する

AWS EC2 Linuxにオプションモジュールをインストール

# 症状
WordPressの管理者画面のサイトヘルスに「1件の致命的な問題」が出てる＞＜
内容は、以下の通り。
> **1つ以上の必須モジュールが存在しません**
PHP モジュールはサイトの稼働に必要なほとんどのタスクをサーバー上で実行します。変更はサーバー管理者が実施する必要があります。
– オプションのモジュール dom がインストールされていないか、無効化されています。
– オプションのモジュール mbstring がインストールされていないか、無効化されています。
– オプションのモジュール imagick がインストールされていないか、無効化されています。
– 必須モジュール gd がインストールされていないか、無効化されています。

# 環境
– AWS Amazon EC2 Linux 2
– php 7.4.7
– WordPress

# 対処法
上で「インストールされていないか、無効化されています」と言われているものをインストールして、httpd.serviceを再起動する。

“`
$ sudo yum install -y php php-dom
$ s

AWS-SAA試験勉強メモ3

###CIDR表記
X.Y.Z.W/24
なら、X.Y.Z.Wと255.255.255.0をそれぞれ2進数にあらわしたものの積を取る

☆「/24」の部分が、2進数表記のサブネットマスクで頭からの1の個数

###Auto ScalingグループへのEC2インスタンスへのアタッチ可能になる条件

– インスタンスがrunnning
– インスタンス起動時のAMIが存在する
– インスタンスが他のauto scalingグループに属していないこと
– インスタンスがAuto Scalingと同じAZにあること

補足：Auto Scalingグループは複数のリージョンにまたがることは出来ない

###CloudTrailログファイル
アカウントのAPIアクティビティログファイルをS3に送信

###S3Glacier無料取り出し枠
無料取り出し枠=10GB/月

###S3のオブジェクト削除

– DELETE API
→単一のオブジェクト削除

– Multi-Object Delete API
→複数のオブジェクト（1つのHTTPリクエストで最大1000のオブジェクト削除）

AWS Redshiftでテーブルとそのカラム、データ型の一覧を抽出するメモ

## この記事について

Redshift上に格納している複数のテーブルについて、まとめてドキュメント化する必要があり、こういうの↓がCSVで欲しかったのでそのためのクエリをまとめた。
ほぼ[参考記事](https://qiita.com/foursue/items/021c12d52f7b79f0ded4)のクエリを改変しただけです(@foursue 様ありがとうございます)がメモまで

| table_id | schema_name | table_name | column_number | column_name |column_datatype|
—-|—-|—-|—-|—-|—-|
| 1 | user | demographic | 1 | uuid | VARCHAR |
| 1 | user | demographic | 2 | age | INT |
| 1 | user | demographic | 3 | gender | VARCHAR |
| 1 | user | demographic | 4 | country | VA

クロスアカウント・クロスリージョンなCodePipelineを実行する

# はじめに
[以前の記事](https://qiita.com/neruneruo/items/0daf2b30c59582007c4e)で、クロスアカウントなパイプラインを実行するコツをまとめてみた。

今回は、さらにこの2つのイベント連携部分をクロスリージョンにするにはどうしたら良いかを考えた。

最初に結論を書いておくと、CodePipelineのクロスリージョンアクションを使うのが良い、ということだ。

【AWS公式】[CodePipeline でクロスリージョンアクションを追加する](https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/actions-create-cross-region.html)

# 検討経緯
以下の記事を参考にして、CodePipelineの完了時にS3にファイルを突っ込んでトリガしたり、サービス側アカウントにSNSトピックを置いて、CodePipelineの完了時にビルドアカウント側からPublishしてリージョン跨ぎのLambdaを起動したりした。

【参考】【Deve

俺のAWSセキュリティ管理

個人的にAWSのセキュリティ管理のためにつかっているものをザっと並べてみました。
セキュリティ管理に終わりはないので、随時アップデートや新サービスが登場したら利用していこうとおもいます。

##使用サービス一覧
**アカウント管理**
・IAM(ユーザー、ロール、グループ、ポリシー)
**履歴の記録**
・Cloud Trails
・AWS Config
**ログ(履歴)の保存**
・S3
**検知**
・Guard Duty
・IAM Access Analyzer
・Security Hub
**通知**
・SNS
・CloudFormation
**請求系**
・Cost Explorer
・AWS Budgets
**AWS CLI**
・AWS Vault
**外部アプリ**
・spark
・1password
・Authy

##各詳細
**アカウント管理**
・IAMはrootユーザーを使わないでIAMユーザーを使用。権限は最小限に。
**履歴の保存**
・Cloud Trailsですべての証跡ログを記録する。
・AWS Configで特定のリソースの変更履歴を記録する。

IAMユーザーとIAMロールは似ていることのメモ

#なぜIAMユーザーとIAMロールを比べるか
IAMの勉強をしていると、概念が多いことやAWS独自の用語、位置関係と複雑なことが多くいつも混乱しがちです。特にIAMのユーザー、ポリシー、ロールの概念は非常に初心者にとっては難しいと思います。そしていつもポリシーに注目がいきがち。ただ、IAMユーザーとIAMロールが非常に似ているということを理解してからだいぶIAMあたりの概念の理がしやすくなったのでメモとして。
##IAMユーザーとIAMロールは似ている
自分なりにIAMユーザーとロールについて表現してみました。

“`
IAMユーザーとは、IAMアイデンティティでありアクセス許可ポリシーをもつAWS IDである。
“`
(以下細かい説明)
**アクセス許可ポリシー** ＝　ポリシーによって付与されるアクセス許可(IAMユーザーよりIAMグループに付与することが推奨)
**AWS ID** =　「そのユーザーはだれか」

“`
IAMロールとは、IAMユーザーと同様にIAMアイデンティティであり特定のアクセス権限(アクセス許可ポリシー)をもつAWS IDであり、
AWSサービス

AWS CopilotでSpringBootアプリケーション(Kotlin)をECSにデプロイする

# 概要
AWS Copilotを使い、AWS ECS x Fargateへアプリケーションをデプロイしてみます。

# AWS Copilotとは？
– 「Copilot」を和訳すると「副操縦士」
– AWSが提供するECS CLIの後継
– 従来のECS CLIより**簡単にFargateへのコンテナデプロイを実現できる**
– 詳しくは[AWSのブログ](https://aws.amazon.com/jp/blogs/news/introducing-aws-copilot/)を参照
– AWS Copilotのソースコードは[github](https://github.com/aws/copilot-cli)に公開されている

簡単に言うと、**「ちゃんと動くDockerfile」**があれば、`$ copilot init` とか `$ copilot deploy` といった**簡単なコマンドだけでECSにアプリケーションをデプロイできるよ！**というツールです。

# モチベーション
– 従来であれば、こうしたECS環境を使った公開アプリケーションを開発しようとしたとき

Terraform で AWS VPC の環境づくり[入門]

# やりたいこと

terraform の大まかな流れが知りたい。
とりあえず AWS VPC の環境を作成して、確認後廃棄。

# 各種ファイルの用意

## VPC 本体

### vpc.tf

“`tf
variable “aws_region” {}

provider “aws” {
version = “~> 3.1”
region = var.aws_region
}

variable “project_prefix” {}
variable “vpc_cidr” {}

resource “aws_vpc” “vpc” {
cidr_block = var.vpc_cidr
instance_tenancy = “default”

enable_dns_support = true
enable_dns_hostnames = true

tags = {
Name = “${var.project_prefix}-vpc”
}
}
“`

## 変数の設定

### test.tfvars

“`t

AWS VPC の設定を terraform init [入門]

`terraform init` に成功するまでに少し詰まったので、構文理解のためにも成功前後のファイル差分と解決までの道程を残しておく。

# やること

`terraform init` まずはこれだけ。

# init 成功ファイル

## vpc.tf

“`tf
provider “aws” {
version = “~> 3.1”
}

variable “project_prefix” {}
variable “vpc_cidr” {}

resource “aws_vpc” “vpc” {
name = “${var.project_prefix}-vpc”
cidr_block = var.vpc_cidr
instance_tenancy = “default”

enable_dns_support = true
enable_dns_hostnames = true

tags = {
Name = var.project_prefix
}
}
“`

# エラー解決の道程

#

Amazon Personalize では Role だけではなく S3 バケットにもポリシーを書く必要がある

# 概要
Amazon Personalize にデータをインポートするときに S3 のバケットポリシーも記載する必要があり、少しはまったので共有します。

# やり方
## Role のポリシー

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

AWSのt2.2xlargeをhibernationしながら常用する

AWSは、2018年末辺りから、[インスタンスの休止（ハイバネーション）](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Hibernate.html)ができるようになりました。
しばらくは、Amazon Linuxでしか使えなかったのですが、[2019年にUbuntuでも使えるようになり](https://aws.amazon.com/jp/about-aws/whats-new/2019/07/amazon-ec2-hibernation-now-available-ubuntu-1804-lts/)、必要な時だけ立ち上げ、終わったら休止というのができるようになりました。

たとえば、時間のかかるビルドをするときに、ビルドが終わったら休止しておけば、コストを抑えられますし、シャットダウンと違って、エラーの確認も再開後すぐにできます。

しかし、休止をAWS Consoleからするのでは面倒です。そのため、実行中のインスタンスから休止できるコマンドを作成します。

“`hibernate.sh
#!/bin/sh

[AWS] 安価で簡単にRedmineの環境を作成・管理できるよ！そうLightsailならね

# Redmine
今更説明する必要もありませんが、Webベースのプロジェクト管理ツールです。
AWSでは、DB（PostgreSQL、MySQL）や全文検索（Elasticsearch）、あるいはコンテナ管理（Kubernetes）など、様々なOSSをマネージドサービスとして提供されていますが、残念ながらプロジェクト管理や課題管理をしてくれるサービスがありません（2020年8月現在）。

これらのサービスを利用しようと思ったら、

* EC2インスタンス上で起動
* ECSでRedmineのコンテナを起動

少なくともAWS上で、ということを考えると、この辺がすぐに思い浮かぶと思います。

などが考えられると思います。
が、しかし、もっと簡単な方法があるのです。それも定額で。

# Amazon Lightsail
AWSでの仮想サーバといえば、すぐに思い浮かぶのは、やはりEC2だと思います。
EC2は、多種多様なインスタンスやOSの選択ができる一方、課金がインスタンスの稼働時間に依存するため、気がつくと高額になっている、なんてことも実はない話ではありません。
しかし、Lightsa

メモ：Elastic IPアドレスの一覧を取得する

# バージョン
“`bash
$ aws –version
aws-cli/2.0.25 Python/3.7.4 Darwin/19.5.0 botocore/2.0.0dev29
“`

“`bash
$ jq –version
jq-1.6
“`

# コマンド
“`bash
aws ec2 describe-addresses | jq ‘.Addresses[].PublicIp’ > eip.csv
“`

AWS AmplifyのAuthで取得した認証情報をAWS SDKのCredentialProviderChainを利用して埋め込む

前回からの続き

[AWS Amplify Libraryで取得した認証をAWS SDKで利用する](https://qiita.com/kent-hamaguchi/items/425cd178beb22555835c)

**CredentialProviderChainから認証が通ってAWS SDKの処理が動いた時点で書き込んでおり、肝心の認証情報が失効したあとの自動更新はまだ確認していません。確認できたら追記します。**

とりあえず、調べてもほとんど情報が出てこない、“`CredentialProviderChain“`の使い方メモ的にでも残しておく。

# やること

Amplifyの “`Auth.currentUserCredentials()“` で取得した認証情報は1時間で失効する。この方法で取得した認証情報をAWS SDKに引き継いで利用する場合などにおいて、1時間以上時間が空いたあとに処理を再開すると使えなくなる。

( SPAなどでアプリケーションを提供していて、1時間以上画面を放置した場合とか)

それを回避するために、自前で認証情報が失効するタイム

FlutterとAWSで始めるサービス開発 (8)Cognitoの認証情報を使ってAPIを呼び出す

# はじめに
「[(5)AWS Cognitoでログイン](https://qiita.com/makotomi/items/a0b05e8819270072780b)」や、「[(7)AWS Cognito Googleでログイン](https://qiita.com/makotomi/items/e7ee81006a9505d468a0)」で、Cognitoを使ったログイン処理を一通り実装完了しました。今回はそれら認証情報がないと呼び出せないAPIを実装していきたいと思います。前回まででCognito ユーザープールからID Tokenを取得するところまではできています。APIを呼び出すために、ID Tokenを要求し、それを検証してから実行するAPIを作っていきます。つまり、ログインした場合だけサービスのAPIを呼び出せるというモデルを実現するための構成です。認証した上でさらに特定の権限を持っているユーザーだけが利用できるといったAPIも考えられますが、今回はそこまでは踏みこみません。

# 参考文献

– 公式サイト
– [サインイン後に API Gateway および La

EC2にPostgreSQLをインストールする方法（動作確認用）

# インストール

“`
sudo yum update # 省略していい
sudo yum install postgresql postgresql-libs postgresql-server # 何をインストールしているのか未調査
sudo service postgresql initdb # これをしないと起動できないらしい
sudo service postgresql start
sudo service postgresql status
sudo chkconfig postgresql on # EC2起動時にPostgreSQLを起動してくれるらしい
“`

# psqlを使う
postgresqlインストール時に作られるpostgresユーザに切り替える。
このユーザじゃないとpsqlを使えない。

“`
sudo su – postgres
psql
create database testdb;
\l
\c testdb
“`

# メモ
postgresユーザに切り替えるのが不便で分かりにくい。
安全のための設定と思われる。

# 参考
Amaz