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

AWS初心者がSQSでキューを作成してみる

どうも!最近ソリューションアーキテクトアソシエイトを無事取得することができましたがまだまだサービスに慣れていないのでAWS初心者を名乗って行こうかと思っているSATO論外です！
今回はAWSのキューイングサービスであるSQSを触って実際に動かして行こうかと思います

#SQSとは？
[Amazon Simple Queue Service](https://aws.amazon.com/jp/sqs/)の略です。
完全マネージド型のメッセージキューイングサービスでマイクロサービス・分散システム・サーバレスアプリケーションの切り離しとスケーリングが可能です。
主に送信側のアプリケーションと受信側のアプリケーションのポーリング処理の中継役(キューをため込んでポーリング処理を実施)として使用するサービスとなります。
疎結合化を進めるためにSAAの試験でも結構な確率で出てくる項目となりますので是非覚えていて損はありません

#実際に触ってみる

###SQSの作成
– AWS マネジメントコンソールからSQSを検索して移動、キューを作成をクリック
　AWS Copilot Pipelineを触ってみた

#きっかけ
[前回AWS Copilotを触ってみました](https://qiita.com/takeh/items/23d7b3300dc008bb9dbc)が、その時はpipelineをうまく動かせませんでした。
しかし、その後うまく動いたので今回はcopilot pipelineの話を書こうと思います。

#動かなかった原因
なぜ動くようになったのかは不明です…
とりあえずcopilotに新バージョンが出ていたのでバージョンを上げて色々試していたら動きました…

“`bash
$ copilot –version
copilot version: v0.2.0
“`

#Copilotのセットアップ
まずはCopilotをセットアップします。セットアップに使うファイルややり方は[前回記事](https://qiita.com/takeh/items/23d7b3300dc008bb9dbc)同様です。

“`bash
# 必要なファイル
.
├── Dockerfile
└── index.html

0 directories, 2 files
“`

“

Chromebook(ASUS C101PA)でAWS CodeDeployチュートリアルやってみた

#概要
CodeDeployが気になっていたのでAWS公式のチュートリアルをやってみた。
何もしないと忘れそうなので、作業メモとして残す。

##作業環境・使用サービス
– 作業端末
– chromebook (ASUS C101PA)
– Secure Shell App (SSH接続用)
– AWSサービス(東京リージョン)
– EC2（Amazon Linux 2 AMI (HVM), SSD Volume Type）
– AWS CodeDeploy
– AWS CodePipeline
– github

##1. IAM準備
EC2用とCodeDeploy用のIAMロールを準備する。
・EC2用
　IAMロール作成画面でAWSサービス ＞ EC2を選択。
　↓
　ポリシーに”AmazonEC2RoleforAWSCodeDeploy”を指定。
　↓
　タグは飛ばす。
　↓
　任意のロール名を入力し、ロールの作成。

・CodeDeploy用
　IAMロール作成画面でAWSサービス ＞ CodeDeployを選択。
　↓
　ユースケー

CPUバーストUnlimitedのEC2さんに乱暴したら課金された

[秘密鍵を10億個作ろう](https://qiita.com/umihico/items/c99b41c818c13531f83c)として遊休サーバーを使い始めたら、CPUバーストがUnlimitedであることに気づきました。危ない危ない。

以下のコマンドでEC2が自分の望む状態になるようコントロールしましょう。

“`bash
# 一覧を出す。
$ aws ec2 describe-instance-credit-specifications
{
“InstanceCreditSpecifications”: [
{
“InstanceId”: “i-1234567890abcdef0”,
“CpuCredits”: “unlimited”
},
{　
“InstanceId”: “i-1234567890abcdef0”,
“CpuCredits”: “unlimited”
}
]
}

# インスタ

AWS EC2 Konga導入

# 環境
Amazon Linux AMI release 2018.03

# インストールコマンド
“`
$ curl -sL https://rpm.nodesource.com/setup_14.x | sudo bash –
$ sudo yum install -y nodejs
$ sudo npm install bower gulp sails -g
$ sudo yum install git
$ git clone https://github.com/pantsel/konga.git
$ cd konga
$ npm install
$ cd konga
$ cd config
$ cp -pr local_example.js local.js
$ npm start
“`
起動すると、1338番ポートでGUIサービスが起動します。
セキュリティグループで外部（自分のIP）からTCP/1338番ポートに繋がるようにして、ブラウザからアクセスしましょう。

# 設定
– NEW CONNECTION

“`
Name： （任意でユニークな名前）
Kon

ELB (ALB) のヘルスチェックが Request timed out になって悩んだ

ぜんぜん大した話ではないのですが、検索しても答えが見つからず、しばらく悩んだので。

## ロードバランサのアウトバウンドルールが閉じていた

リクエストが通るには、

* ロードバランサに設定したセキュリティグループのアウトバウンドルール
* インスタンスに設定したセキュリティグループのインバウンドルール

の双方で接続を許可する必要があります。

インスタンスのインバウンドルールばかり見ていて、ロードバランサのアウトバウンドルールが閉じていることになかなか気づきませんでした。。 😥

## その他

ALB のセキュリティグループの推奨設定が以下にあります。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest

2020年のAWSでいい感じWordpressインフラを組んでみる

これまでちょこちょこ[AWS関連の記事を書いてきた](https://qiita.com/cumet04)のですが、
そういえば一般的な1システム全体のことを書いたものが無いなと気付きました。

じゃあせっかくなので1システムをキッチリ組んで思考メモをまとめよう、ということでやってみました。

題材と前提
———-

オーソドックスな題材がいいなということで、RailsかWordpressあたりかと思ったのですが、
最近[Fargate+EFSが実装されたとき](https://qiita.com/cumet04/items/4b5cbdb29d76c72eb26c)に
「Fargateで冗長化Wordpressやってみたいな」と思っていたところだったためWordpressにしました。
※実際にはFargateではなくEC2になりましたが…

その他前提としては、

* 可能な限り実運用を意識する
* 冗長化を行う
* 開発環境・本番環境はAWSアカウントレベルで分離し、それぞれ関係ないリソースは原則置かない
* Infrastructure as Codeを意識する

Railsアプリで画像の保存先をS3に変更する。その2

## はじめに
[前回の記事](https://qiita.com/ysda/items/49fa6e8318c874a57b9e)からの続きです。

## 安全にAWSのキーを扱えるようにする
AWSキーの漏洩を防ぐため、キーの内容は環境変数に設定します。
環境変数が分からない人はググって調べてみましょう！

## AWSのキーの設定
carrierwave.rbのなかに[:access_key_id]や[:secret_access_key]といった記載がありました。
ここには予め設定したキーが入り、Rails5.2では「credentials.yml.enc」というファイルで管理されます。

それではcredentials.yml.encをエディタで開いてみましょう。
以下のように暗号化された文字列が表示されると思います。
![スクリーンショット 2020-07-26 23.23.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/429077/ab3cebe2-4098-b91b-c917-

Serverlessフレームワークで${aws:username}を使う

Serverlessフレームワークで`${aws:username}`のような[IAM ポリシーエレメント(IAM Policy Elements)](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_variables.html)を使用するとエラーとなります。

“`bash

Invalid variable reference syntax for variable aws:username. You can only reference env vars, options, & files. You can check our docs for more info.

“`

Serverlessの[Valuables](https://www.serverless.com/framework/docs/providers/aws/guide/variables/)と記法が被っているからですね。

# 対処法
以下のように`provider`に`variableSyntax`を

AWS Lambda 用の Java11 コードを docker-lambda 環境でローカル開発するメモ

Docker に慣れちゃうと、別にインストールしても問題ないものまでコンテナ上で動かしたくなりません？特に更新が激しいものはアップデートの導入が面倒なので、つい Docker image を探しがち。

というわけで、AWS Lambda で実行する Java 11 コードを、[docker-lambda](https://github.com/lambci/docker-lambda) を用いてローカル環境で開発・テスト実行させてみました。Docker 以外はインストール不要なので、気軽に試せて良い感じです。

ググってみても python や nodejs の説明ばかりヒットする気がしたので、簡単なメモとしてまとめておきます。

# docker-lambda とは

[docker-lambda](https://github.com/lambci/docker-lambda) は AWS Lambda 開発環境を Docker ベースで提供するものです。以下、概要部分を簡単に訳しておきますね。

> インストールされているソフトウェアとライブラリ、ファイル構造と権限、環境変数、

AWS EC2でKong

AWS EC2でKongを利用してみようとしたら躓いたのでメモ。

[aws market place](https://aws.amazon.com/marketplace/pp/Kong-Inc-Kong/B06WP4TNKL)にあるものを使うとインスタンスの起動までしてくれる。便利。

Kongの記事で「nanoでもすごい性能を発揮したよ！」（参照：[Kong、他社API管理製品の14倍の性能を実測](https://www.webapi.tokyo/kong%E3%80%81%E7%AC%AC%E4%B8%89%E8%80%85%E3%83%99%E3%83%B3%E3%83%81%E3%83%9E%E3%83%BC%E3%82%AF%E3%81%A7%E3%80%81%E4%BB%96%E7%A4%BEapi%E7%AE%A1%E7%90%86%E8%A3%BD%E5%93%81%E3%81%AE14%E5%80%8D%E3%81%AE/)）と出てたので、nanoでも動くと思ってインスタンスを作ってみた。
ただ、sshで入っても動いている気配がない。

仕方なく、とりあえず「

【Postfix/Dovecot】メールサーバ構築（EC2利用）

##目標
AWS EC2上にPostfixとDovecotをインストールし、メールサーバ（SMTPサーバ・POP/IMAPサーバ）を構築する。

##前提
・メールサーバとして利用するEC2が構築済みであること。
・ドメインを取得し、DNSに登録されていること（※１）。
・**注意点として、AWSEC2はデフォルトだと、EC2⇒インターネットの25番ポート宛て通信が制限されており不可となっております（スパムメールの踏み台に利用されることを回避するためで、許可するには別途AWSへ申請を行う必要があるよう）（※２）。**

※１　以下記事で、ドメイン取得、及びDNS登録（AWS Route53利用）を実施致しました。
[AWS Route53を利用してEC2へ独自ドメインアクセス](https://qiita.com/aWdfcfG2jLr73pe/items/4a141a880351cf655de9)

※２　参考AWSドキュメント
[EC2 インスタンスからポート 25 の制限を削除するにはどうすればよいですか?](https://aws.amazon.com/jp/premiumsu

AWS認定 ソリューションアーキテクト プロフェッショナル（SAP-C01）に合格しました。

AWS認定のアソシエイト資格3種類合格したので
より知識の定着を図るために
AWS認定 ソリューションアーキテクト プロフェッショナル（SAP-C01）を続けて受験し合格しました。

#合格時のAWS歴
（業務歴的には）半年
個人学習歴的には1年程度

#点数推移
1回目→728点（2020-05-31）
2回目→840点（2020-07-26）

#難易度について
他の方もまとめている通り、難易度が高いです。
問題文と選択肢がSAAの比ではなく長文かつ、
最適なソリューションを選択肢を比較して（怪しい日本語を）咀嚼して回答しなければなりません。
試験時間（180分）はかなり長いですが、それでも厳しい時間制限です。（75問あるので、1問にかけられる時間は3分）

#勉強法
勉強期間は、合計で4か月程度（集中すればもっと短縮できたはず）

SAAと違ってBlackBeltで概要をつかむだけでは合格は厳しいかと思うので
可能であれば、実際にマネジメントコンソール上で操作して勉強したいのですが、
SAPはDMSなどの移行サービスも試験範囲に含まれたり、Organizationsのエンタープ

S3バケットポリシーでエラーが出た際の対応【this policy contains invalid Json】

S3のバケットポリシーの登録で、一見問題なさそうなコードにエラーが出て少しはまりました。

## エラー内容
this policy contains invalid Json
[画像]([](https://gyazo.com/9697b735d2fe4fa937c974c5f40da800))

## コード
“`
{
“Version”: “2012-10-17”,
“Id”: “Policy1544152951996”,
“Statement”: [
{
“Sid”: “Stmt1544152948221”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::IAMユーザーのarn情報:user/IAMユーザー名”

EKSのコンテナログをFluent Bitで収集しCloudWatch Logsに集約する

# はじめに
EKS上のログを収集してそれをCloudWatch Logsに集約するには[fluentd-cloudwatch](https://github.com/helm/charts/tree/master/incubator/fluentd-cloudwatch)をデプロイするのが定番のパターンです。
これをFluent Bitでも行えるようにAWSが公式で[aws-for-fluent-bit](https://hub.helm.sh/charts/aws/aws-for-fluent-bit)を公開しているので試してみました。

# 環境
macOS Mojave 10.14.6
EKS 1.16
Helm 2.14.3
Helmfile 0.122.0

# 導入手順
EKSやHelm Tillerは既にデプロイ済みであるとします。
Fluent BitはデフォルトでCloudWatch LogsにアクセスするためのIAM Roleが付与されないので自分で設定していく必要があります。

## IAM Roleの用意
Fluent BitがCloudWatch Logsに

AWS Well-Architected Labsのご紹介

# AWS Well-Architected Framework
「AWSのベストプラクティスに沿って設計/構築/運用したいけど、何をどうすればベストプラクティスになるのか分かってないな〜」と思っているそこのあなた。**AWS Well-Architected Framework**を使いましょう。**オペレーショナルエクセレンス、セキュリティ、信頼性、パフォーマンス効率、コスト最適化**の5つの柱についてAWSのベストプラクティスに沿っているかをチェックできます。AWS Well-Architected Frameworkには以下3種類があります。

### 1. AWS Well-Architected ホワイトペーパー
ベストプラクティスが記載されたドキュメントです。都度更新が入るので、最新のドキュメントは[公式ページ](https://aws.amazon.com/jp/architecture/well-architected/?ref=wellarchitected-ws&wa-lens-whitepapers.sort-by=item.additionalFields.s

Lambda＋SAMテンプレートのBlue/Greenデプロイメントで「デプロイの再試行」した際の動作を検証する

# はじめに
デプロイ運用は、Blue/Greenでシームレスにサービス移行できるのも重要だが、デプロイに失敗した際のロールバックと再デプロイをスムースに行えることも重要だ。

Canaryなデプロイにおける自動ロールバックについては、[過去の記事](https://qiita.com/neruneruo/items/2e7bf289f375ccc91356)で調査を行ったので、今回は手動ロールバックと再デプロイについての動作検証を行う。

なお、最初に断っておくと、この方法は結果的に期待した動作になっているが、途中でエラーが出たりして怪しさ満点である。もう少しちゃんとした検証が必要かもしれない。

# 前提条件
– Lambda＋SAMテンプレートでの基本的な動作の仕様を理解している([過去の記事](https://qiita.com/neruneruo/items/73906cdc3c2aa699644f)で紹介済み)
– デプロイは以下の仕様とする
– Prodのエイリアスを使用してCanaryの向き先を制御する(SAMテンプレートで“`AutoPublishAlias: P

Amazon EFS CSI DriverがGAした件

# AmazonがEFS CSI DriverのGAをアナウンスした

参考: https://aws.amazon.com/about-aws/whats-new/2020/07/amazon-efs-csi-driver-now-generally-available/

# EFSをPersistent Volumeとして使う場合の、以前までの方法
Kubernetesのincubatorリポジトリ内に、Amazon EFS用のPV Provisionerがある
これを用いることで、EFSをPVとして使用できる。
こちらは、CSIを用いていないため、CSI Driver経由でEFSが使用できることは嬉しい。

[eft-provisioner](https://github.com/kubernetes-incubator/external-

AWS CDKをTypeScriptで使い始める単純な例

## AWS CDKとTypeScriptのインストール

“`
sudo npm install -g aws-cdk
sudo npm install -g typescript
“`

* macOSの人はsudoは不要
* typescriptがインストール済みの場合typescriptは不要

## 作業用ディレクトリ作成

“`
mkdir my-cdk && cd my-cdk
“`

## テンプレートプロジェクトの作成

“`
cdk init app –language typescript
“`

## EC2パッケージを入れる

“`
npm install @aws-cdk/aws-ec2
“`

[@aws-cdk_aws-ec2.Instance](https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ec2.Instance.html)

## サンプルのファイルを開く

ファイルは、`lib/tutorial-stack.ts`にある。

“`typescript

CloudFrontを使ってs3パケットを公開したらAccess Deniedになり、ハマるポイントが多いのでまとめてみた

いきなりですが、AWS基盤で独自のwebサイトを作りたいと思っています。

HTMLやCSSなどフロントのコンテンツは別のサービスを使っていい感じに作るとして、AWSを使うメリットはバックエンドがいい感じにできることです。

登竜門となるのが、s3といったストレージサービスに格納したファイルをいかにしてCloudFrontに乗っけるのか、という部分になると思います。

雑なイメージですが、AWSであれば以下のような構成にすることでいい感じに作れます。

詳しい作り方は、ぜひAWS公式のハンズオンなどを見てみてください。

[“AWS 上で静的な Web サイトを公開しよう！” 編を公開しました！- Monthly AWS Hands-on for Beginners 2020年5月号 | Amazon Web Services ブログ](