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

Redashのデータソースを作成する

前回の記事でAWSのRDSにデータをインポートしてデータの準備が出来ましたので、今回はRedashにログインしてデータソースを作成してみたいと思います。

## Redashへのログイン

① 最初にAWSのEC2インスタンスとRDSが起動されていることを確認します。
​　 起動されていない場合は、起動しておいてください。
② EC2インスタンスのパブリックIPアドレスをコピーします。
③ コピーしたIPアドレスをブラウザのURLに入力します。
④ Redashの初期設定画面が表示されますので、各項目を入力し、「セット

AWS CLI(命令的)とTerraform, CloudFormation(宣言的)の違い

AWS CLIにてターミナルから、AWSリソースの作成をすることや、IaC(Infrastructure as Code)のTerraformやCloudFormationでAWSリソースをコード化することはもはや今の時代普通となってきてはいるが、今回はこれらの技術を触り始めたばかりの人にこの両者の違いを命令的、宣言的な言葉から説明しようと思います。

#両者の違い

「EC２インスタンスを１つ作る」を例に取る。

##AWS CLI (命令的) は How を指定する。
“`
EC２インスタンスを１つ作るとなったら：
　-VPC作って〜
　-AZ作って〜
　-サブネット作って〜
　-インスタンスタイプはこれを指定して〜 etc…
“`
命令的では、EC２インスタンスを１つ作るためには何から用意して、どのようになどのlow level=Howの指定をする。

##Terraform, CloudFormation (宣言的) はWhatを指定する。

“`
EC２インスタンスを１つ欲しい！
“`

宣言的は最終的なDesired State=What,欲しい物を指定する。

Amplify + AppSync + React + Typescriptで簡単アプリ作成【完成】

# 概要
前回の記事の続きを書いていきます。
前回の記事をみたい人は[こちら](https://qiita.com/keito1024/items/6c0980b253cb52fae6cc)

## クライアントからAPIを呼び出す
プロジェクト内でAppSyncを仕様するために, 提供されているライブラリを使用していきます。

“`sh
$ yarn add aws-amplify aws-amplify-react
“`
package.jsonを確認してインストールがされたことを確認してください。
確認できたら早速、エントリーポイントであるindex.tsxにインポートしましょう。

“`tsx
import ‘./index.css’;

import Amplify from ‘aws-amplify’; // <--- ライブラリインポート import React from 'react'; import ReactDOM from 'react-dom'; import App from './App'; import config from './aws-ex

Amazon ECS Workshop #2 ~コンテナのデプロイ~

# 環境構成図
本投稿では下図の構成図のコンポーネントを構築していきます。

タイトルにあるコンテナのデプロイに進む前の環境準備部分がかなり多くなりますが、ご了承ください。
※IAM周りの権限は適宜付与している前提で進めていきます。

コンテナ＆ECSに関する各コンポーネントの簡単な説明は下記をご参照ください。
[introduction編](https://qiita.com/itoumke/items/3b0b5a6956d3c1f071cb)

# 環境準備
## CloudFormation実行環境
![クライアント環境.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/640480/1ff5068b-089c-05b3-b016-57a7b272145b.p

【AWS】AWS Ground Stationなるサービスについてちょっと調べてみた

#AWS Ground Stationを調べてみる経緯
AWSマネジメントコンソールを触っている際、サービス一覧に「衛星」のカテゴリが気になったのでちょっと調べてみることにしました。
#AWS Ground Stationってなにもの
###ざっくり説明
・人工衛星が取得したデータをAWSに送ることが出来るサービスのようです。
・地上に自前でアンテナを用意する必要は無くAWSが設置したGround Station(地上にあるアンテナ)で人工衛星からデータを受信することが出来るようです。
・人工衛星との通信時間をスケジューリングして使用するようです。
・人工衛星から送られてきたデータはEBS、EFS、S3に保存することが出来るようです。
・現在使用できるアンテナは、「米国東部 (オハイオ)」「米国西部 (オレゴン)」「中東 (バーレーン)」「欧州 (ストックホルム)」「アジアパシフィック (シドニー)」「欧州 (アイルランド)」の6つ
[AWS公式サイトの概要説明](https://aws.amazon.com/jp/ground-station/)
#どんなことに使用するの？
###・

AWS愛用者がまよぶGCP:GoogleAppEngineの特長

務めている会社や家でもAWSしか利用したことがあったのですが、転職先にGCPを使う可能性が出てきたので、GCPを勉強しようと思います。

WEBエンジニアとして使う可能性が高い、GoogleAppEngineについて調べました。

# GoogleAppEngineの特長
## 複数バージョン管理
GAEでは、1つのWebアプリケーションに他してい複数のバージョンを配置可能。
バージョンの切り替えなどができるため、デプロイの動作確認で問題なければ、すぐに新しいバージョンに切り替えたりすることができる

## トラフィック分割
サービスの各バージョンに対してユーザからのトラフィックを分割可能。
アプリケーションの新機能のリリースだけを切り分けてのトラフィックの確認も可能。

## 自動スケーリング
サービスへ負荷が増大した際に自動的にアプリケーションを動作させるインスタンスを増やし、負荷が低下しあ場合は自動的にインスタンスを減らしてくれる。

# 参考
[Google Cloud Platform 実践Webアプリ開発 ストーリーで学ぶGoogle App Engine]
(https:

AWS認定ソリューションアーキテクトに合格しました

AWS認定ソリューションアーキテクト(SAA)に合格したので、忘れないうちに記録を残しておきます。

## 1. 受験した動機
業務で担当しているプロダクトのインフラがAWSで構築されていて、EC2やRDS、S3をなんとなく触っていた程度でした。
ちなみにエンジニア歴は8ヶ月です。

業務で実際に触るAWSのサービスは限られるのですが、

– もっとAWSの全体像を理解して知識を深めたい
– インフラの基礎を勉強したい

といった理由でSAAの勉強をはじめました。

## 2. 取得してみて
まず「SAAを取得すること」と「AWSでインフラが構築できるようになること」は別物です。

合格してみて強く感じますが、ただ資格の勉強をしても実際にAWSを使えるようにはなりません。業務や個人サービスで実際に手を動かして初めて使えるスキルとなるので、SAAはその準備程度として捉えたほうが良さそうです。

SAAを取得するメリットとしては、

– AWSでインフラを構築する際の現時点でのベストプラクティスを理解できる
– AWSの様々なサービスの特徴を理解し、組み合わせることで最適な設計のイメージが

AWSサービスのみでサーバーを監視してみる

# この記事
インフラエンジニアをやっています。

AWSを業務で使い始めて始めにやったことを思い出すと、EC2とCloudWatchでした。

監視ソフトウェアを使わずとも、それこそ最低限の監視であればスッと始められるし料金も知れてるので、今回はその内容を少し書きます。

設計ではなく手法の話になります。

対象読者はAWSを使って監視というものを試したことがない方、あるいはSAA試験対策の一貫になったりするかと思います。

# 監視の種類
あくまでサーバーの監視ってどんなのだっけ？というお話。

**死活監視**
サーバー息してる？といういわゆるping応答の監視


**リソース監視**
リソースという言葉は広い意味で取れるが、例えば**CPUやストレージ容量**といった基本的なもの
ずっとCPUが90％以上だったら、サーバーが超人気なのか

LaravelをRDSと繋ぐ

# TL;DR

– RDSを構築して、RDS情報をenvs/配下の値を適切に埋める
– envファイルに設定したい文字列に#がある時はダブルクオーテーションで括る

—

# RDS構築

一連の流れを説明とともに記述します。詳しいことは載っていないので注意です。
また、今回はRDSをパブリックサブネットに配置します。
（外部から繋ぎたいため）

本来はVPC内のプライベートサブネットに置き、
EC2などからしか接続させないようにするのがオーソドックスかと思います。

1. VPC作成
2. VPC > インターネットゲートウェイからインターネットゲートウェイを作成し、VPCにアタッチ
3. VPC > ルートテーブルから、VPCのルートテーブルにサブネットの関連づけをする
2. VPC > サブネットからパブリックサブネットを2つ作る (※1)
3. EC2 > セキュリティグループからRDS用のセキュリティグループ作成。
今回はパブリックサブネットに置くので、外部（XServer）のIPをインバウンドとして設定
4. RDS > サブネットグループを先に作成

Amplify + AppSync + React + Typescriptで簡単アプリ作成①

# 概要
前々から聞いたことがあったけど使ってなかったAmplifyとReactを使って、簡単なアプリ作るがこの記事のゴールです。

## 事前チェック
各種環境のバージョンチェックしましょう。(これらが全て使える環境が整っている前提)

“`shell
$ create-react-app –version
3.4.1
$ node -v
v12.18.0
$ npm -v
6.14.4
$ amplify –version
4.27.1
“`

## React App 作成する
クライアントアプリの雛形をつくっていきます。

“`shell
$ create-react-app client-app –template typescript
$ cd client-app
$ yarn start
“`

おなじみの画面が出ると思いますこれでひとまずクライアント側の準備はOKです。
![app-page.cfe4dfdb.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/165705/a

DynamoDBはどんなCRUD操作が可能か確認する

# はじめに
[以前の記事](https://qiita.com/neruneruo/items/71ad99629e9b11648222)で書いたように、DynamoDBはちゃんとキャパシティ管理さえしてあげれば、サーバレスで高性能でかなり良い感じなデータベースだ。

ただし、データベースと言ってもRDBとは違うので、そちらに慣れている人にはハマりどころが多々ある。

DynamoDBではどんなCRUD操作が可能かを確認しておこう。

# 前提条件
前提条件はあまりないが、以下の記事くらいを読んでおくと入りが良いとおもう。

– 【Qiita】[AWS DynamoDBと仲良くなれるかもしれないまとめ](https://qiita.com/yu-croco/items/66fd1a662dd64b8eb348)

特に、LSI、GSIはちゃんと理解しておかないと混乱することになるのでしっかり覚えておこう。

# 事前準備
今回は、以下のような仕様のデータベースを管理する前提とする。
– 社員ID(項目名:“`id“`)をキーとする社員管理テーブルを想定
– 社員は複数の部署(項目

[AWS] Lambda関数のユニットテストをローカル環境で実行してみよう

# 前提
今回は、以下のような前提で検証してみたいと思います。

– SAM
– Lambda
– Python3.8
– pytest
– moto（モック）
– DynamoDB

なお、SAMを使用すると、Dockerん環境を使って擬似的にローカル環境にDynamoDBなどを構築することができますが、今回は、ユニットテスト（将来的な自動テスト）を見据えてのテストについて検証してみたいと思います。

# プロジェクト作成
では、まず最初にプロジェクトを作成します。
もし、SAMでのプロジェクト作成がよくわからない方は、事前に

– [[AWS] Serverless Application Model (SAM) の基本まとめ](https://qiita.com/herohit-tool/items/420f4a7b294cfcf56ed7)
– [[AWS] Serverless Application Model (SAM) でAPI Gateway + Lambda + DynamoDBなサンプルを作成してみる](https://qiita.com/herohit-tool

別アカウントのS3にレプリ_ただのメモ書き

GudardDutyのログは仕様上暗号化されてS3に出力される。そのログをS3レプリケーションで別のAWSアカウントにレプリケーションしたい

アカウントA ==> アカウントB

## 環境

* アカウントA

* GuardDutyログを暗号化するKMSキー：gd-test-src
* GuardDutyログを保存するS3バケット：gd-src
* GuardDuty有効化

* アカウントB
* KMSキー：gd-test-dst
* アカウントAのGuardDutyログのレプリ先S3バケット：gd-test-dst

### S3バケット作成

**アカウントBで操作**

S3バケットgd-dstを作成
バージョニング有効化

### KMSの作成

**アカウントAで操作**

CMKを”gd-test-src”で作成

キーポリシーに以下を追加

“`json:
{
“Sid”: “Allow GuardDuty to use the key”,
“Effect”: “Allow”,
“Principal”: {

AWS勉強 振り返りまとめ (2)

AWS ソリューションアーキテクト アソシエイト受験に向けて取り組んできた勉強において、
振り返っておくと良さそうな部分をまとめてみました (その2) :bear:
同じように AWS の勉強をしている方の参考になれば嬉しいです :penguin:

前はこれ :point_right: [AWS勉強 振り返りまとめ (1)](https://qiita.com/kumashun/items/c873f519eb1c377056f7)

## Load Balancing 系
– 静的/動的なスケーリング
– 静的 : desired-capacity が固定
– 動的 : desired-capacity が可変 = Auto Scaling (それはそう)
– **ステップスケーリングポリシー**
– CloudWatch から取得できるメトリクスの値に応じて増やす台数を調整できる。
– e.g. cpu 使用率 60% => 1台, ~ 70% => 2, ~ 80% => 3
– ELBのターゲットグループを設定すれば、ELB構成を利用してELBの

AWS勉強 振り返りまとめ (1)

AWS ソリューションアーキテクト アソシエイト受験に向けて取り組んできた勉強において、
振り返っておくと良さそうな部分をまとめてみました (その1) :bear:
メモ程度の内容ですが、同じように AWS の勉強をしている方の参考になれば嬉しいです :penguin:

続き :point_right: [AWS勉強 振り返りまとめ (2)](https://qiita.com/kumashun/items/0b8c733ddca0fc6c8083)
## IAM
– 1アカウントあたりのIAMの制限(数)
– IAMユーザー : 5000
– IAM ユーザーは10個のIAMグループに所属可能
– IAMグループ : 300
– IAMロール : 1000
– **AWS Organizations** は IAM のアクセス管理を容易にするサービス。
– アクセス権限自体の編集を行うものではない。

## EC2
– EBS のボリュームタイプ

タイプ | ユースケース | 最大スループット[MiB/sec] | 料金 [USD/G

AWS クイックスタートで Pivotal Cloud Foundry (VMware Tanzu Application Service) をサクッとたててみた

## はじめに

3 年ほど前に Cloud Foundry ネタで社外イベントに登壇したのですが、ひょんなことから社内勉強会でリバイバル発表することになりました。さすがに 3 年前とは成熟度の面で差があると思い、最新情報をキャッチアップするために Cloud Foundry 環境構築に踏み切りました。

Ubuntu on WSL へのローカルデプロイを試みましたが、絶対的なメモリ不足により断念せざるを得ませんでした。続いて、mac へのローカルデプロイは試行錯誤の上、なんとかうまくいきましたが、リソース的にはギリギリです（何か別の重いアプリを起動するとスワップが発生してしまう）。

Cloud Foundry のように複数の役割を持ったノードが協調し合って成立する仕組みをローカルデプロイすること自体に無理があるのかも知れません。ありがたいことに AWS クイックスタートに「AWS での Pivotal Cloud Foundry」が用意されていますので、今回はその手順をまとめておきたいと思います。

### 前提条件

– AWS アカウントを持っていること
– VMware Ta

AWS IoT + Cognito + IAM + Amplifyでユーザ認証・IoTデバイスと通信するAndroidアプリ

## 目的
IoTデバイス（例えばLEDや各種センサ、それらを接続したRaspberry Piなど）をモバイルアプリから操作したい時、あるユーザが所有しているデバイス以外は操作できないようにデバイスとユーザは一意に紐付けられている必要があります。
上記を実現するためにAWS IoT・Cognito・IAM・Amplifyを使用してユーザ認証機能を実装し、ユーザに紐付けられたデバイスとMQTTメッセージを双方向にやり取りできるAndroidアプリを作成します。

ソースコード→[GitHub](https://github.com/sutoo-the-cat/SignedInPubSub)

## 使用環境

– Windows 10
– Android Studio 4.0.1
– Kotlin 1.4.0
– Amplify CLI 4.27.3
– Pixel 3a（Android 10）

## 前提条件

– AWSアカウント作成済み
– AWS IAMユーザ作成済み
– [Amplify](https://docs.amplify.aws/lib/q/platform/and

AWS上にサーバーを作る（序章）

# 序章について
この記事を書くに至った経緯を掲載しておきます。
## こういう人向け
僕は今までパブリッククラウドと呼ばれるクラウドサーバーの類は使ったことがない。
なぜなら料金が「使った分だけ:scream:」という青天井の料金体系なので、

* 会社では・・・不明瞭な料金のせいで「・・・で、結局月々いくらかかんの？」に回答できなく予算を通せず
* 個人では・・・操作ミスで巨額の支払いが来るのが怖くて申し込みすらできず

たぶんこういう人って多いはず。
そして、外部公開用のサーバーは星の数ほどあるけれど、社内向けあるいは外から見られては困るサーバー（開発用途、テスト用途、勉強用なので自己資金）を作ってみたい人いきたいと思いますので、用途にマッチしている人。
そんな人に読んでもらえるとありがたいです。
## スキルについて
僕はこんなレベルの人間です。

* オンプレでサーバーを作ったことがある
* VirtualBox、KVM、vmware ESXiで仮想マシンを作ったことがある
* レンタルサーバー会社で借りた共用レンタルサーバーを使ったことがある
* レンタルサーバー会社で申し

AWS FireLens 用 fluentd コンテナの開発時のみを追加する

# 問題

FireLens でユーザー独自の fluentd を使う場合、設定ファイルに以下のような <source> セクションが自動で追加される。

“`conf:fluent.conf@type unix
path /var/run/fluent.sock
@type forward
bind 127.0.0.1
port 24224

“`

設定ファイルに上記のような記述が既にされていた場合、重複が生じてしまい以下のようなエラーが発生してしまう。

“`text
[error]: unexpected error error_class=Errno::EADDRINUSE error=#
“`

fluentd コンテナをローカル環境などで開発する段階においては、何らかの <source> がないと入力が得られ

ECRのイメージをプルするCodebuildをTerraformで作る

## はじめに
ECRに保存しているイメージをCodebuildで使用したかったので、その設定をTerraformでやってみました。
Terraformを使用したからといって特別なことをやっているわけではありませんが、備忘録として。

## 環境
– Terraform : 0.12.29
– Terraform aws provider : 3.3.0

## ECRリポジトリ

以下のようなECRリポジトリを作成します。
このリポジトリにCodebuildで動かすイメージを保存していきます。

“`.tf
resource “aws_ecr_repository” “example” {
name = “example”
image_tag_mutability = “MUTABLE”

image_scanning_configuration {
scan_on_push = true
}
}
“`

公式のガイドを参考に、CodebuildからイメージをプルできるECRのポリシーを設定します。

[AWS ECRサン