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

【AWS】「AWS Well-Architected Framework」や「ベストプラクティス」を紐解く会（社内勉強会）を実施しました

# はじめに
最近、めちゃんこ暑くて、絶賛とろけてます。
換気のために窓を開けると、熱風が注ぎ込んできますね！

どーも、のぶこふです。

ついったでも少し呟いたのですが、社内向けに「[W-A](https://aws.amazon.com/jp/architecture/well-architected)」や、[AWS をはじめる 10 のことシリーズ「AWS でアーキテクチャ設計を検討する上で知っておくべき 10 のこと (+1)」](https://pages.awscloud.com/JAPAN-event-OE-At-least-10-Architecting-2020-reg-event-LP.html?aws_introduction_page)を紐解く会を実施しました。

社内向けに「AWS Well-Architected Framework（6）」と「ベストプラクティス（11）」を紐解く会を行う予定。
資料はまだ無い。

— のぶこふ (@nobkovskii) June 10, 2022

## モチベーション

クラスメソッドさんの研修に参加させていただいて、W-Aの大切さを改めて実感したので、これは社内にも還

ECS Execでトラブルが起きたら、amazon-ecs-exec-checkerを使ってみよう

ECS Execは、ECSで稼働しているコンテナに対しコマンドを実行できる仕組みです。

ローカル環境だと出ないエラーが出てしまって、原因がわからない場合や、
VPC内のリソース以外からはRDSへの接続が許可されていない場合に活躍します。
仰々しい名前が付いていますが、独立したサービスではなく、SSMでコンテナに接続する感じです。
AWS CLIが入っていれば、ぜひ試してみてください。

導入方法は下記のドキュメントを御覧ください。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/ecs-exec.html

さて、ECS Execするための設定なのですが、
簡単そうに見えて、ネットワークなどの設定によっては、一発で繋がらない事もあります。
AWS Execでは色々と隠蔽されているのもあり、トラブルの原因を探るのはなかなか難しい。
(よくあるのは、ssmmessagesへの権限付与が足りないとか..VPC Endpointがないとか..)

そんなときに役立つのが、 `amazon-ecs-exec-checke

lambdaのメモリとCPU数はどこが切れ目なのか調べてみた

すでにほかの記事でも触れられていますが、lambdaはメモリを増やすとCPUが増えるようです。

https://qiita.com/hamadu/items/12303d9f9cb800db14d3
https://aws.amazon.com/jp/lambda/faqs/

128MBでもすでに2つ割り当てられていたり最大でも6つだったりどこが区切れなのか調べてみました。

ソースコードは以下に置いてあります。

https://github.com/misogihagi/lambda-cpuinfo

## 結果

128MBごとに増やした結果です。ざっくりいうと3GB,5GB,7GB,9GBでスレッドが一つ増えるみたいです。


“`json:vega-light
{
“data”: {
“values”: [

SnykでOSSプロジェクトの脆弱性をチェックしてOSS貢献？！

# Snykとは？

> Snyk helps software-driven businesses develop fast and stay secure. Continuously find and fix vulnerabilities for npm, Maven, NuGet, RubyGems, PyPI and more.

翻訳

> Snyk は、ソフトウェア駆動型ビジネスの迅速な開発と安全性の維持を支援します。npm、Maven、NuGet、RubyGems、PyPIなどの脆弱性を継続的に発見し、修正します。

# 使ってみた。???

初めて使ってみましたが、 **超簡単** です。

ログイン後の画面???


`GitHub`を選択します。???

【Terraform】ECSの環境変数をSSMを利用して設定する

# 初めに

現在作成中のポートフォリオは、`Terraform`を利用して`AWS`にデプロイをしています。

`ECS`のコンテナに対して、`enviroment`から環境変数を渡していましたが変数の追加などがあった際、タスク定義を書き換える必要がありめんどくさいです。

`SSM`を通して環境変数を渡すことでタスク定義を書き換えずに更新できます。

## 環境

– terraform v1.0.2
– provider AWS v3.38.0

# 環境変数を SSM に登録する

`task definition`の`secretsのvalueFrom`に`SSMのarn`を追加する必要があります。

まずは`ssm_parameter`を作成します。

変数自体は`terraform.tfvars`に書きます。

“`terraform:ssm.tf
resource “aws_ssm_parameter” “secret” {
name = “ENV_FILE”
type = “SecureString”
value = var.env_file
}
“`

AWS SAP勉強中に学んだこと

# はじめに
今はAWSソリューションアーキテクトプロフェッショナル試験（以下、SAP）の勉強しています。
勉強中に学んだことを記事にしていこうと思います。

# セキュリティグループとネットワークACL
セキュリティグループは、EC2、ELB、RDSなどの**インスタンス**に適用するファイアウォール機能です。
ネットワークACLは、**サブネット**に適用するファイアウォール機能です。

| | セキュリティグループ | ネットワークACL |
|:-:|:-:|:-:|
| 適用先 | **インスタンス** | **サブネット** |
| 制御項目 | プロトコル（TCPやUDPなど）、ポート範囲、CIDR、**セキュリティグループ** | プロトコル、ポート範囲、CIDR |
| デフォルトの状態 | 全てのアクセス

[AWS]VPCエンドポイント：ゲートウェイ型とインタフェース型の違い

VPCエンドポイントは以下の３種類があります。
a) ゲートウェイ型
b) インターフェイス型
c) Gateway Load Balancer型

c)は特徴的で他と動作も異なるので選択に迷う場面は無いと思いますが
a)とb)は似たような機能で違いがわかりにくいので整理してみます。

物理的にはゲートウェイ型はルーターとして動作するのに対し、インタフェース型はENIがアタッチされる形になります。この違いを頭の片隅においていると動作の違いもわかりやすくなると思います。

## 料金
| タイプ | 内容 |
|:–|:–|
|ゲートウェイ型| 無料　|
|インタフェース型 | データの転送とサービス利用時間に応じて課金|

ここは違いがはっきりしていますね。ゲートウェイ型が無料なのはとても嬉しいです。

## 対応サービス

| タイプ | 内容 |
|:–|:–|
|ゲートウェイ型| AmazonS3、DynamoDBのみサポート|
|インタフェース型 | 主要なサービスをほとんどサポート |

利用できるサービスは圧倒的にインタフェース型が多くなります。
対応サー

AWS認定DevOpsエンジニアプロフェッショナルを受験した時の話

## この記事の概要
2022/07/03
**AWS認定DevOpsエンジニア – プロフェッショナル**
(AWS Certified DevOps Engineer – Professional (DOP-C01))
を受験したので、その時の記録

復習用ノートとして、また後で見返して今後の資格試験受験時の参考用にまとめます。

## 試験の概要


プロフェッショナルレベルの試験で、CI/CDなど短い周期でリリースを繰り返すアジャイルな開発のインフラ環境の構築や運用などに関する知識が問われます。
この試験では「AWSインフラストラクチャとアプリケーションのテストとデプロイを自動化する能力が認定されます。」とのこと。
AWS公式より引用：[引用元](https://aws.amazon.com/jp/ce

AthenaでクエリできるようにGlacierのオブジェクトの復元、コピーを行う

# AthenaでのGlacierオブジェクトの制限

Athenaでは `Amazon S3 Glacier Flexible Retrieval`と`Amazon S3 Glacier Deep Archive`ストレージクラスのオブジェクトに関してはクエリされません。
また、[マニュアル](https://docs.aws.amazon.com/ja_jp/athena/latest/ug/other-notable-limitations.html)にあるように、`Amazon S3 Glacier Flexible Retrieval`と`Amazon S3 Glacier Deep Archive`ストレージクラスのオブジェクトを復元したとしてもデータの参照は行われないので、参照を行うためにはコピーを行い別オブジェクトを作成する必要があります。
これらの処理を実行するPythonスクリプトを作成してみました。

# オブジェクトの復元を行うスクリプト

第１引数にバケット名、第２引数にキー名を指定して実行します。指定したオブジェクトの復元をおこなったら処理が完了します。

雰囲気で分散システム使ってるやついる!?

**？？？：雰囲気で分散システム使ってるやついる!?**
**？？？：いねぇよな！！！！！**

**むっそ：んなわけねぇよ、いるんだよ！！ここによぉ！！**
(終)

# はじめに
なんか分散システムっぽいのは使えてるけど、いまいち詳しいことは知らないってひとが多いと思います。私もです。

別に分散システムの仕組みを知らなくても問題なかったりするものですが、いざシステム障害などが起きると **これそもそもの仕組み知らんと無力じゃね？** ってなったりします。(無情にもやばいバグが時々起きたりします)

今回は分散システムにわか勢による分散システムを知るのに良さそうなリンクをまとめたり感想を書いていこうかと思います。

# 分散システムを考え始めたきっかけ
## DynamoDB嘘松事件

### 事件前の実装
現在開発しているプロダクトで下記のような処理がありました。
(先人の過去の遺物が残っていてあまり良くないアーキテクチャになってます)

> フロントエンドのUIでhogeアイテムの変更イベントが発生
⇒ A REST APIをたたく(hogeアイテムのステータスを更新する

【AWS CLI】s3 rmでdryrunを使って削除対象を確認

# S3でファイルを一括で削除したいが必要なファイルは絶対に消したくない！
awscliのs3のrmコマンドで `–recursive` オプションを使ってファイルを一括削除したいが、includeやexcludeの指定を失敗して削除しては行けないファイルを削除してしまうことを防ぎたいと思いました。

“`shell
aws s3 rm –recursive s3://example-backet/aiueo/12345/ –include “*foo*” –exclude “*bar*”
“`

例えば上記コマンドを実行したいと思っても本当に削除対象が自分が削除したいものなのかは実行してみないとわかりません。
実行してからファイルの復活はできませんし、削除前にコピーしておいて…とかはよっぽど出ない限りやりたくありません。

# –dryrunオプションを使う
そういうときにdryrunオプションを使うと、実行はしないが、実行したかのようなcli上の確認が取れます

>Checks whether you have the required permissions f

Windowsでgit-secretsを導入するとVisual Studioでコミットできなくなる問題の対応

# 問題点

Windows環境でgit-secretsを導入すると、Git Bash上では問題なく動作しますが、Visual Studio上でコミットすると、`/usr/bin/env: ‘bash’: No such file or directory` というエラーが表示され、コミットできなくなります。

# 原因

git-secretsで利用しているスクリプトのシバンに`#!/usr/bin/env bash`が指定されているのが原因でした。

# 対策

git-secretsで利用しているスクリプトのシバンを`#!/usr/bin/env bash`から`#!/bin/sh`に変更します。具体的には以下のファイルの先頭行を変更しました。

– %USERPROFILE%\\.git-secrets
– （ローカルリポジトリのルート

Amazon Lookout for Equipmentで予兆保全

## はじめに
Amazon Lookout for Equipmentに関してまとめた記事になります。
2022年7月時点ではドキュメントが少ないので、実際に検証した内容に関して記載します。

## 製造業における課題
製造業における課題は以下の通り、様々なものが存在します。
1. 機械が完全に壊れると修理費用が高い
1. 機械が使えなくなった際のダウンタイム
2. サプライチェーンの分断
2. メンテナンス作業の属人化
2. システムのブラックボックス化

上記以外にもその他、沢山存在しますが、最近では特に1と2がクリティカルな課題とお聞きします。

機械が故障すると、ダウンタイムが発生し、必要とする方々へ必要とする分の供給ができなくなるなど、顧客満足度に影響する課題になりえます。
また、機械が完全に壊れてからの修理費費用と壊れる前のメンテナンス費用では雲泥の差があるとされ、修理期間にも影響を及ぼすそうです。

こういった課題を解決としてのAI活用としては、予知保全/予兆保全があげられます。
> 予知保全（Predictive Maintenance）は、機械の故障の兆候をとらえて

新卒はアソシエイトを取りたい

## 自分のスペック
とある会社に新卒で入社し、データ基盤エンジニアの開発や運用などやってます。（今は2年目)
受験時は、実務経験は数ヶ月程度でサーバレス系のサービスとデータ系を知ってる感じでした。
テストはec2などが多いので結局、一部は初心者とさほど変わりません。

## 何でAWS認定ソリューションアーキテクト　アソシエイトを取ろうと思ったか？

業務でawsを使うことが多いのと、新卒で取れたらかっこいいなと思ったので挑戦しました。
他にも知らないサービスを知ってた方が何かと便利で良いかなぐらいで勉強しました。

## 勉強期間
基本は以下の感じで、業務後や休日カフェで勉強したりしてました。
期間：3週間
平日：1-2時間
土日：5-7時間
トータル：45時間

## 利用教材
AWS認定資格試験テキスト AWS認定ソリューションアーキテクト – アソシエイト 改訂第2版
→人によってawsの各サービス知識が0の方にはおすすめ、ある程度知ってる人はblackbeltやclassmethodさんの記事で十分かも
https://www.amazon.co.jp/AWS%E8%AA

AWS ElasticBeanstalkでeb-engin.logにはSUCCESSと出るが、WEBコンソールではERRORになる

# 状況
## eb-engin.log
ちゃんとSUCCESS！と出てます。

## WEBコンソール
ERRORが出ています。（訳：デプロイが中止してる間に、新しいバージョンがデプロイされたっぽいよ。もう一回デプロイしてね）

# 原因
EB > 設定 > ローリング更新とデプロイ > コマンドタイムアウト
が短いから

# 対処
EB > 設定 > ローリング更新とデプロイ > コマンドタイムアウト
を3600秒に変更したら成功しました。

Visual Studio CodeでAWS構成図やシーケンス図を含めたMarkdownを作成する

# はじめに

Visual Studio CodeでMarkdownを作成するときに、内部にdraw.ioで作成したAWS構成図やシーケンス図などを簡単に埋め込む方法をメモしておきます。最終的なイメージは以下のようになります。


# 前提条件

– Visual Studio Codeをインストールしていること。

# 事前準備

Visual Studio Codeで以下の拡張機能をインストールします。

– Markdown All in One
– Markdown Preview Enhanced
– Draw.io Integration
– PlantUML

# 記載方法

まずは適当にMarkdownファイルを作成します。ここではtest.mdとします。
Markdownの基本的な記載方法については割愛します。

“`

AWS VPC/サブネットを作成する(2022年)

## 目標
こんな感じのVPCとサブネットの構成を作る

## 手順

– AWSのマネジメントコンソールからVPCを作成クリック
VPCの作成画面からサブネットの作成まで一気にできるようです。(VPCなどタブをクリック)
下記画像の赤線部分を編集しています。

VPCのCIDERブロック設定


サブネットのCIDERブロック設定とVPCエンドポイントをなしにする
![VPC２.png](https://qiita-image-store.s3.ap-nor

AWS CDK + TypeScript でサーバレス開発その1 : Hello world!

# 概要

AWS CDKでサーバレス環境を構築するシンプルな方法のメモ。

# 前提

– 筆者の環境はMac + VSCode。
– AWS CDKを使ったことがある。
– Node.jsがインストールされている。

# 手順

## 雛形の作成

aws-cdkを使ってプロジェクトの雛形を作成する。

“`bash:ターミナル
mkdir project-name
cd project-name
cdk init app –language typescript
“`

TypeScriptは直接ts-nodeが実行するので、typescriptパッケージはアンインストールしておく。tsconfig.jsonも削除する。

“`bash:ターミナル
npm uninstall typescript
rm tsconfig.json
“`

package.jsonからtsc関連のスクリプトも削除しておく。

“`diff:package.json
“scripts”: {
– “build”: “tsc”,
– “watch”: “tsc -w”,

VPCフローログを試してみた(勉強メモ用)

## VPCフローログとは

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs.html

>VPC フローログは、VPC のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャできるようにする機能です。フローログデータは Amazon CloudWatch Logs または Amazon S3 に発行できます。フローログを作成したら、選択した送信先でそのデータを取得して表示できます。
>・フローログは、以下のような多くのタスクに役立ちます。
・制限の過度に厳しいセキュリティグループルールを診断する
・インスタンスに到達するトラフィックをモニタリングする
・ネットワークインターフェイスに出入りするトラフィックの方向を決定する
>フローログデータはネットワークトラフィックのパスの外で収集されるため、ネットワークのスループットやレイテンシーには影響しません。ネットワークパフォーマンスに影響を与えるリスクなしに、フローログを作成または削除できます。

## 構成図

下記環

SnowconeのJobステータスがImportingから遷移しなかった件

## 経緯
Snowfamilyの一つであるSnowconeを使用してS3バケットでデータの移行を行った。
5日経ってもJobのステータスが「Importing」だったためサポートに問い合わせをした。
結果として初歩的なミスだったものの、問い合わせをしなければ事象が発見できない(コンソール画面では確認できない)ため、メモとして残しておく。

## 何がよくなかったか。
・Snowcone Jobの作成時に、IAMロールはデフォルトを使用。
・格納先のS3バケットは暗号化されている。

***つまりは、SnowconeがS3バケットへデータを書き出す際に使用するKMSへの権限が不足していた。***

## やったこと
・SnowconeにアタッチされているIAMロールへ暗号化に使用している鍵への権限を追加
・サポートへ連絡しJobの再実行を依頼

## まとめ
Snowconeはまだ日本語の記事が少なく手探り状態だったこともあるが、よく確認せずにデフォルトのIAMロールを使用したことが原因。(~~ポップアップも出るのにガン無視していた~~