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

図解で、AWS新サービスでローコード・アプリ開発を理解する。Honeycode

# 図解で、AWS新サービスでのアプリ開発を理解する（簡易アンケート回答＆集計アプリ）AWS Honeycode
パソコンもしくはスマホでアンケートに回答し、AWS Workbook（表データ）を経由して、アンケート結果を集計して表示するアプリのテンプレートが提供しているので、日本語版へと改造しながらアプリ制作過程を理解しようと思う。


## AWSが提供するテンプレート
AWS Honeycode で新しいアプリを作るときは、最初に[Create workbook]を実行し、(1) CSVファイルから作成する、(2) テンプレートから作成する、(3) イチから自分で作成する、の３つから開発方法を選ぶ。ここではテンプレート[Simple Survey]から作成してみた。

## 画面レイアウトの設計（モバイル用）を日本語版に改造したもの
画面(

AWS ソリューションアーキテクト アソシエイト試験 合格体験記(SAA-C02)　おすすめ教材や難しく感じた点

#はじめに
2020年7月24日、AWSソリューションアーキテクト アソシエイト試験(以下、SAA)に、2度目の受験で合格しました。
1度不合格を経験していることもあり、合格結果をみた時は声が出るぐらい嬉しかったです！

SAAを受験してみて、難しいと感じたところやおすすめ教材を書いていきたいと思います。
これから受験を予定されている方やリベンジに燃えている方は、参考にして頂けると幸いです。

##私の経歴
– SIer勤務5年目。これまでは主に検証作業をしており、最近やっと開発プロジェクトに参画できた
– 勉強をはじめるまでAWSの経験はなし。インフラ知識もほとんどなく、DNSとかの単語を多少知っている程度

##合格までの道のり
| 日付|内容 |
|:———–|:—————————————|
| 2019年9月 | AWS案件にアサインされたことを機に勉強開始 |
| ～ | 仕事に忙殺されながらudemy(後述)で勉強|
| 2020年5月 | 受験を決意してテストセンターに赴くも、あえなく不合格。コロナ禍だ

AWS EC2 (Ubuntu) で DNS のスタブリゾルバ 127.0.0.53 と Amazon Provided DNS の関連を確認する

# はじめに
AWS で VPC を構築した時、VPC 内のインスタンスが参照する DNS サーバ ( Amazon Provided DNS ) のアドレスは 「 VPC のネットワークアドレス + 2 」です。
例えば VPC のネットワークアドレスが 10.0.0.0 であれば、DNS サーバのアドレスは 10.0.0.2 です。
[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Subnets.html)に書いてあるので、間違いありません。

しかし、EC2 インスタンスの OS を Ubuntu とした場合、参照先の DNS サーバはデフォルトで **127.0.0.53** となっているように見えます。
本記事では、この **127.0.0.53** について深堀りし、Amazon Provided DNS との関連を確認した結果を備忘録としてまとめます。

# 想定される参照先 DNS サーバのアドレス

検証用のクライアント (EC2) のプライベート IP アドレスは、以下で示さ

PulumiでAWSにWEBアプリの最小構成を構築する

# はじめに
Pulumiはプログラミング言語（現在サポートされているのは、JavaScript、TypeScript、python、go、C#）によりインフラをコード管理するためのツールです。

Pulumiを使ってpythonでAWSにWEBアプリを動かすための基本的な構成を構築してみて気づいたことなどを書いてみます。

pulumi環境構築事などについては下記のチュートリアルを参考にしてください
https://www.pulumi.com/docs/get-started/aws/

# 実行環境
python: 3.7.7
pulumi: 2.7.1
aws-cli: 1.18.102

# 構成について
### 構成図

### 今回作

【AWS-SAA】選択肢でたまに出題されるAWSサービス

#はじめに
教材ではあまり触れられないが、問題集などの選択肢でたまに出題されるサービスについて備忘録を兼ねて、AWSのサイトの内容を中心に簡単にまとめていきたい。(たまに出題されると思ったのは私の主観での判断なので、その点ご了承ください。)

#サービス一覧

API Gateway

簡単にAPIの作成、公開、保守、モニタリング、保護を行えるフルマネーフド型サービス。トラフィック管理、CORS サポート、認可とアクセスコントロール、スロットリング、モニタリング、API バージョン管理など、最大数十万規模の同時 API コールの受け入れと処理に伴うすべてのタスクを取り扱う。

Athena

Amazon S3 内のデータを標準SQLを使用して簡単に分析するサービス。即時にデータのクエリを実行し、数秒で結果取得。料金は実行したクエリに対してのみ。

Cognito

ウェブアプリケーションおよびモバイルアプリに簡単にユーザーのサインアップ/サインインおよびアクセスコントロールの機能を追加できる。Facebook、Google、Amazonなどの

Golangはじめて物語(第3話: CodePipeline+SAM+LambdaでCI/CD編)

# はじめに
[前回](https://qiita.com/neruneruo/items/fe292262836ac068e2ea)というか[第一話](https://qiita.com/neruneruo/items/1ef52f908e4497103a59)の続編。
第一話ではServerless Frameworkを使ったが、今回はCodePipelineを使って自動起動するパイプラインを使ってみようと思う。となると、セオリー(だと思ってるの)はSAMをCloudFormationで起動するパターンだろう。

golangのアプリケーションそのものの話は薄めというか、ほぼ入っていないのであしからず。

# 前提条件
・golangのアプリケーションは[第一話](https://qiita.com/neruneruo/items/1ef52f908e4497103a59)のものをほぼ流用するので、読んでいる前提
・[別の記事](https://qiita.com/neruneruo/items/e2e4fd70c90e2dbdc67f)で書いたTerraformのサブモジュールを

QuickSight ネームスペース(マルチテナンシー)

# QuickSightのネームスペースとは

ネームスペースを複数作ることでQuickSight上の最上位の空間を分割することができます。
例えばSaaS事業者の方がお客様である会社A、会社Bごとにネームスペース(空間)を分けて様々な干渉を無くすことができます。いわゆるマルチテナンシーの機能になります。わかりやすくスッキリしてマルチテナンシーできますね。

### aws cli v2を最新にする

まずは新しい機能が使えるようにaws cliをアップデートしておく。今回はaws cli v2を使っています。
Macにインストールの場合、手順は公式通り以下を実施します。これによって20200724段階での最新(?)のv2.0.34となりました。

“`bash
curl “https://awscli.amazonaws.com/AWSCLIV2.pkg” -o “AWSCLIV2.pkg”
sudo installer -pkg ./AWSCLIV2.pkg -target /
“`

バージョンの確認

“`bash
aws –version
aws-cli/2.0.34

GitHubActions+S3+CloudFrontでキャッシュクリアしてSPAをデプロイする

# はじめに

## ここでやってること

1. 前回は[Dockerでsvelteの開発環境を作成](https://qiita.com/mkin/items/22272dc052e9cdf80a8b)しました
2. 今回は、**svelteをGitHubにpushしたら、GitHubActionsがbuildしてS3にアップロード & CloudFrontのキャッシュ消去して配信**します（svelteでなくても設定自体は可能です）

## AWSの設定

### 1. S3にアップロード用のバケットを作成

今回はCloudFrontで配信するので「パブリックアクセスをすべてブロック」して作成します。
この記事では`svelte-spa`というバケット名で作成しています。
（よくこのシンプルな名前で取れたな…

### 2. CloudFrontを設定

Create Distribution > Web(Get Startedボタンクリック)

– `Restrict Bucket Access` : S3へのアクセスを不可にするためYesを選択
– `Grant Read

【AWS】git pushでEC2にも自動デプロイ(CodeDeploy / CodePipeline)

この記事では、

・ローカルのソースコードを更新してコミット
　　　↓
・Githubにプッシュ
　　　↓
・EC2上のソースコードも自動更新

する設定法を備忘録としてまとめておきます。
ローカル環境を更新して、さらにそこから手動でEC2にデプロイするのが面倒だったので
自動デプロイ化を取り入れてみたのですが、だいぶ作業が効率化されて楽になってように感じます。

#今回利用するAWSリソースについて

自動デプロイを実現するために、今回は以下のAWSリソースを利用します。

①VPC（パブリックサブネット）/InternetGateway
②IAM
③EC2
④CodeDeploy
⑤CodePipeline

※別途Githubアカウントも必要になります

#設定の手順について

###①IAMロールの作成

###②EC2を作成し、CodeDeployエージェントをインストール

###③ローカル環境とGithub上での設定

###④CodeDeployの設定

###⑤CodePipelineの設定

#①IAMロールの作成

EC2用に、
以下の２種類のポリシー

AWSガチで何もわかってない人がECSでWordPressをデプロイするまで

AWSはネットワークが独学難しく、半ば挫折気味でした。

AWSだと「Hello World！」を出すまでが非常に難しく(VPC、サブネット、ルーティングetc）まずは手を動かしてみるのにいい題材はないだろうか？

…と考えていたところ、ECSでWordPressをデプロイしてみるのが非常に簡単でオススメだということで、実際にやってみました。

## 必要なもの

– **docker for mac**
https://docs.docker.com/docker-for-mac/install/
– **docker-compose**
docker for macに同梱
– **AWSアカウント**
https://aws.amazon.com/jp/?nc2=h_lg
– **ecs cli**
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ECS_CLI_installation.html
少し複雑なので、Homebrew(https://brew.

ElasticBeanstalkのアプリケーションログをCloudWatchで捕捉したい

サーバのログ問題ってあると思いますが、皆さんはどうされていますか？
よくあるパターンはfluentdで特定のログ保存用サーバに送るパターンだと思います。
他にもDatadogやInsight7でトラッキングする方法などありますが、いずれも設定が大変でエージェント仕掛けたりとかCloudFormation仕掛けたりとか挫折しやすいです（実際今回の記事書くときにもやってみたけど正直何度もサポートに聞く羽目になったし、仮に設定できても有料なのも痛い）。

あとdmsgとかアクセスログとかの保存は簡単だけど、アプリケーションログに関しては保存していないケースも多くて情報探すのにも苦労しました。

ElasticBeansTalkで作成したサーバのアプリケーションログは1時間とかでローテーションしてしかも消えてしまったり、AWSの管理画面でログのダウンロードしても出てこなかったりという問題があります。

ローカルでテストしているときはエラーのハンドリングは難しくないけど、本番じゃないと発生しない問題にはどう対処すればいいのか悩ましいところです。エラーのトラッキングはSentryも仕掛けているけど

AWS Honeycodeで役に立ちそうなTips

いつも忘れないように、コンセプトから。

###コンセプト
・お金かけてまでやりたくないのでほぼ無料でAWSを勉強する
　→ちょっとしたサービスを起動すると結構高額になりやすい。
・高いレベルのセキュリティ確保を目指す
　→アカウントを不正に使われるととんでもない額を請求されるので防ぐ

今回はAWSのHoneycodeをもうちょっと勉強してみました。何かを作るというよりは、コミュニティサイトを眺めて学習する感じです。自分の疑問を解決する記事を探してみました。
　
　
　

#####スプレッドシートにデータを入れるけど、Excelみたいな関数は何が使えるの？

ちょっと古い記事なのでもっと増えているかもしれませんが、ある程度まとまってました。これなら英語が苦手でも感覚的にわかりそうです。
https://honeycodecommunity.aws/t/honeycode-functions/90

#####複数のTablesを組み合わせるのはどうするの？

SQLでいう結合というかリレーションに関する疑問です。ここは以下の「Tasks-to-Project」の部分を見るとわかりや

AWS; Amazon workbook って何だ？

# AWSはついにOfficeアプリまで浸食しに行くのか、Microsoft Excel や Google Spreadsheet的なやつ。
AWS Honeycode はローコード・ノーコードつまり、プログラミング言語を書かなくてもスマホアプリやWEBアプリを開発できる開発環境のサービス。現在AWSからプレビュー提供中（2020/6月～, 7月現在）。Honeycodeで開発するアプリのデータを保存したり取り出したりするデータベースとしてExcelみたいな Amazon workbook が使える。


## ならば Amazon workbook を調べてみよう
何ができるのか？

– **【保存】**オンラインストレージ（Amazon Drive）に作成した「表データ（amazon workbook）」を扱える。アップロードやダウンロード

LambdaとDjangoの相性ってどうなの？？

# 忙しい人へ
結論とまとめを最初にのせときます

## 結論
Djangoのようなフルスタックフレームワークではあまり良いとは言えない
フルスタックフレームワーク使うならECSを使った方が良いらしい

## まとめ
> Lambdaのコールドスタートで時間かかるのでは？

結構かかります

> DjangoのプロジェクトをLambdaにアップロードしたら、Lambdaのアップロードサイズ制限に引っかかるのでは？

かかる可能性はあります
ただよほど入れなければ大丈夫なはず

> REST APIを作る時に、DjangoのルーティングとAPI Gatewayの組み合わせって相性悪くね？

実害はないと思うけど悪いと思います

> Django使うってことはサーバーレスなのにサーバー立ち上げるってこと？

その通りです

# 前置き
この記事はあくまでも私見です
これが絶対正しいということではないのでご了承ください

# 前提
zappaというデプロイツールを用いての検証

# 本題
LambdaとDjangoの組み合わせにした時の疑問点がいくつかあった
その疑問点をひとつづ

AWS Copilot

# AWS Copilot？
– ”Amazon ECS が AWS でコンテナをデプロイして操作するための新しい CLI ”とのこと
– Copilot(そのまま英訳を検索すると副操縦士)
– AWS Copilot CLI **(preview)**
– この辺りを参考にサンプルを触ってみようと思います
– https://github.com/aws/copilot-cli
– https://github.com/aws/copilot-cli/wiki

# 作業環境
– macOS Catalina(10.15.5)
– 以下の通りCopilotはAWS CLIの認証情報を参照するため、設定は事前に実施しておきます
– **Copilot uses the same credentials as the AWS CLI** [(引用元)](https://aws.amazon.com/blogs/containers/introducing-aws-copilot/)

# インストール
[インストール方法](https://gi

isucon9 の portal を Amazon Linux2 で動かすメモ

MEMO: 必要あれば ports を適宜変更すること

“`bash

sudo yum -y update
sudo timedatectl set-timezone Asia/Tokyo
sudo yum -y install docker
sudo systemctl start docker
sudo systemctl enable docker

sudo curl -L “https://github.com/docker/compose/releases/download/1.26.2/docker-compose-$(uname -s)-$(uname -m)” -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

sudo yum -y install git

sudo reboot

git clone git@github.com:chibiegg/isucon9-portal.git
cd isucon9-portal

docker-compose b

同一リージョンS3バケット間で大きなサイズのファイルをコピーする

# 概要
* 東京リージョンのs3バケットにあるサイズの大きなファイルを、リージョン内の別のバケットに効率よくコピーする方法を検討した。

# 課題
* 対象ファイルは、4Kの動画ファイル（.MOVまたは.MXF)でサイズは 大きいものだと数ギガから数十ギガバイトである。このサイズだと、Multipart Uploadの利用が前提である。
* 時間と費用を最小限にしたい。

# 仮説
* boto3 s3 clientに、copyという関数が用意されていて、

> This is a managed transfer which will perform a multipart copy in multiple threads if necessary.

と記載されいるので、これを使えばよさそうである。しかし、The transfer configuration に何を設定すればよいのかわからない。
参考 : https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3.html#S3.Cl

【学習メモ】AWSでApacheインストールまで進まなかった原因

#概要

“`
$ chmod 400 tt-manager-ssh-key.pem
$ ssh -i “[SSH認証キー.pem]” [ユーザー名]@[パブリックIPアドレス]

__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|

$ sudo systemctl start httpd.service
sudo: systemctl: コマンドが見つかりません
$ sudo systemctl status httpd.service
sudo: systemctl: コマンドが見つかりません
“`

#結論

概要欄で既に発覚しているのですが、

EC2インスタンスを作成する際に、AMIを、**Amazon linux2**ではなく、**Amazon linux**で作成していた。。。！！

“`
__| __|_ )
_| ( / Amazon Linux AMI←←←これ
___|\___|___|
“`

AWS Honeycodeを評価してみる

いつも忘れないように、コンセプトから。

###コンセプト
・お金かけてまでやりたくないのでほぼ無料でAWSを勉強する
　→ちょっとしたサービスを起動すると結構高額になりやすい。
・高いレベルのセキュリティ確保を目指す
　→アカウントを不正に使われるととんでもない額を請求されるので防ぐ

今回はAWSのHoneycodeを試してみたので、その評価をまとめます。

###簡単な流れから

まず、Honeycodeのアカウントですが、AWSのアカウントとは別になっています。β版なので、正式版になると統合されるかもしれませんが、現状では全く別です。なので、Honeycodeにアクセスして新規アカウントを作成するひつようがあります。

作成すればサインインすることができます。現状ではAWSアカウントのようにMFAなどの設定はできないようです。

サインインしたあ

Gitのサブモジュール機能とTerraformのモジュール機能で実現するCI/CDパイプラインの量産(Lambda編)

# はじめに
Terraformのモジュール機能は最初はありがたみを感じられなかったので使わなかったものの、CI/CDパイプラインをいろいろと量産するようになってくると、いちいち過去のtfファイルを流用しようとして「どれが最新だったっけ……」と悩むようになったので、そろそろリポジトリ管理をするべきなのでは、と考えていた。

そんな折、Gitのサブモジュール機能を知って「これってもしかして組み合わせれば「おれの考えた最強量産型CI/CDパイプラインができるのでは？」と思い、作ってみた。

# 全体構成
今回は以下のような構成だ。

“`メインモジュール
terraform-mainmodule-lambdapipeline
├── .gitmodules
├── main.tf
└── modules
├── 01_variables.tf
├── 02_iam.tf
├── 03_s3.tf
├── 04_cloudwatchlogs.tf
├── 05_codepipeline.tf
└── 06_cloudformation_par