- 1. AWS自動化の心得（IaC編）
- 2. Aurora Serverlessを使ってみた感想
- 3. AppSyncでネストされたクエリを発行できるようにする。
- 4. 【AWS SOA】EC2上でのCloudWatchメトリクス
- 5. 新しいソリューションの設計と既存のソリューションの継続的な改善のポイント
- 6. AWS認定 セキュリティ – 専門知識をAWS公式情報を用いて受験してみた
- 7. コスト管理のポイント
- 8. 移行の計画のポイントについて
- 9. 組織の複雑さに対する設計のポイント
- 10. AWS Lambda LayersへZenpyをデプロイしてみる
- 11. lambda_handlerの引数eventの中身を知る方法
- 12. API Gateway 開発者に読んでほしい、意味がわかると便利な実行ログ
- 13. Amazon FSx for Windowsのあれやこれやソイヤソイヤ
- 14. Amazon Linux2 でJava8の環境構築をしてみる
- 15. AWS CloudFormation(CFn) のテンプレート作成に必要なこと
- 16. ほぼ個人メモ EC2インスタンスのターミナルで日本語入力できるようにする方法
- 17. AWS認定デベロッパーアソシエイト(DVA) 合格体験記
- 18. Terraformでmoduleに対してfor_eachを使おうとしたらエラーだった話
- 19. EC2のEBS拡張
- 20. C言語をAWSで使用する場合の環境構築
AWS自動化の心得（IaC編）
インフラ、基盤の自動化が徐々に必須レベルに近い感じになってきていますので、下記の様な方に向けてAWS自動化の心得を書きます。
①AWS利用しているが、自動化やIaCの知識はない
②システムの自動化を頼まれたがちゃんと運用できるのか不安
③AWS運用を効率化したい
※①、②は2年前の私の心境。今はAWSを効率よく運用できていると感じてます
まず言っておきたいですが、自動化（IaC）は便利です。
AWSで初めて自動化担当となった方の不安を低減できれば良いなと思います。
なぜ自動化するのかと
Aurora Serverlessを使ってみた感想
# Aurora Serverlessの説明
一言でいうと自動でスケールして、アクセスがなければ勝手に停止するAWSのMySQL/PostgreSQLインフラです
2018年に一般公開された比較的新しいサービスで2020年になってもアップデートが続いています## Aurora Serverlessの利用用途
こちらの記事をご覧になると概要がわかると思います
https://dev.classmethod.jp/articles/lessons-learned-from-up-and-running-aurora-serverless/通常のAuroraとのコスト比較はこちらの記事にあります
https://dev.classmethod.jp/articles/calculate-amazon-aurora-serverless-costs/たまにしか接続しない開発環境のDBや、アクセス傾向が不規則なワークロードに適しています
ただ、常時稼働させてしまうと同スペックのDBインスタンスに対して60%割高になるため、安定したアクセスが常時続くのであれば通常のAuroraのほうが
AppSyncでネストされたクエリを発行できるようにする。
やりたいこと
=====“`graphql
query {
user(id: “Makutamoto”) {
id
posts {
userID
id
}
}
}
“`このような、ネストされたクエリを実行したいとします。
言い換えると、userフィールドの引数であるidをpostsのresolverでも受け取とりたいということです。解決策
=====
Response Mapping Templateの$context.sourceに親フィールドのレスポンスが格納されているので、それを使います。実行結果
—–
“`json
{
“data”: {
“user”: {
“id”: “Makutamoto”,
“posts”: [
{
“userID”: “Makutamoto”,
“id”: “id-1”
},
{
“userID”: “Makutamoto”,
【AWS SOA】EC2上でのCloudWatchメトリクス
#はじめに
AWS SOAではEC2上でのCloudWatchメトリクスの内容が出題されるので、本稿で取り上げたい。#EC2上でのCloudWatchメトリクス
EC2上でのCloudWatchメトリクスには以下の内容が含まれる。
##CPU
CPU使用率
クレジット使用状況・バランス
##ネットワーク
ネットワーク出力・入力
ネットワークバケットイン・アウト
##ステータスチェック
インスタンスステータス EC2 VMをチェック
システムステータス 基盤となるハードウェアをチェック
##ディスク
バイトと操作におけるディスク読み取り・書き込み※RAMはEC2上のメトリクスで扱われない
によると以下のような比率で出題されるとのことです。
`インシデント対応` が若干少なくなっていますが、対象となる領域に対してムラのない知識が求められていると考えます。|内容|比率|
|:–|–:|
|インシデント対応|12%|
|ログと監視|20%|
|インフラストラクチャのセキュリティ|26%|
コスト管理のポイント
#ポイント
コスト管理とはAWSを使う上での従量課金のメリットを享受するためにどのような管理と最適化を行うかについての内容である。
コスト管理では、コストエクスプローラやバジェットを使用してコストの分析を行う。実際のコストを考慮した設計では、マネージドサービスやコンテナ サービスを積極的に検討し、EC2使う場合にはオンデマンドかスポットかリザーブを使い分けることが問われる。
移行の計画のポイントについて
#ポイント
基本的にはオンプレからのクラウドへのマイグレーションに関するものである。移行時の検討内容としてはネットワーク・アプリケーション・データの三つに分類される。
#ネットワーク
ネットワークはオンプレ寛容とAWs環境の間のネットワーク接続やIPアドレス、ドメインをどのように維持しつつ移行していくのかが焦点となる。
#アプリケーション
アプリケーション移行では、AWsが保有する目ネージどサービスをどこまで活用し、既存のモノリシックなアプリケーションをどこまでクラウドネイティブな状態へ近付けるかが焦点となる。
#データ
データに関しては大容量のファイルやデータベースをどのようにAWSへ行こうするかを検討する。#まとめ
マネージド移行サービスは充実しており、その活用方法は複雑になっている。ユーザ要件に対して、最低限のソリューションを選択することが大切。#お世話になるサービス
* ネットワーク移行案件
* Route５３
* ダイレクトコネクト
* アプリケーション移行案件
* サーバーマイグレーションサービス
* データベースマイグレーションサー
組織の複雑さに対する設計のポイント
#ポイント
試験の４割を占める「組織、移行、コスト」に関してはAWsのクラウド案件で共通する事柄である。これらはクラウド固有の管理やガバナンスをどのように保つかという内容
企業のセキュリティポリシーに複雑な権限分離の要件があった場合には、アカウントレベルで環境を分けなければならない。また、それぞれの制御設計に対するガバナンス（管理）も求められる。IAMであればトレイルを設定する。VPCであればフローログを導入するなど。
AWS Lambda LayersへZenpyをデプロイしてみる
[Zendesk API](https://develop.zendesk.com/hc/en-us/categories/360000003388)をPythonから簡単に呼び出せるようにするラッパー[Zenpy](http://docs.facetoe.com.au/zenpy.html#)をAWS Lambda Layerに入れてみます。
# なぜLambda Layerを使うのか？
AWS Lambdaへプログラムをデプロイする際に関連するライブラリ群も一緒に入れる必要があります。そのため、複雑なプログラムになるとデプロイパッケージが肥大化しがちでした。
ライブラリやカスタムランタイム、その他の依存関係をまとめたZIPパッケージです。– AWS公式ドキュメント： [AWS Lambda レイヤー](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-layers.html)
# この記事で行うこと
AWS Lambda Layerへ`Zenpy`ライブラリをデプロイする。# 事前準備
*
lambda_handlerの引数eventの中身を知る方法
何かのイベントにフックしてlambdaを実行する際、eventの中身がわからくて困ったとき用メモ
“`
import json
import urllib.request
def post_slack(message):
send_data = {
“text”: message,
}
send_text = json.dumps(send_data)
request = urllib.request.Request(
‘slackのwebhookURL’,
data = send_text.encode(‘utf-8’),
method = “POST”
)
with urllib.request.urlopen(request) as response:
response_body = response.read().decode(‘utf-8’)def lambda_handler(event, context):
message =
API Gateway 開発者に読んでほしい、意味がわかると便利な実行ログ
API Gateway (REST API) では、開発やトラシューに役立つ実行ログ (Execution Logs) を出力することができます。
AWS サポートに問い合わせる際にも、この実行ログがあるとスムーズです。実行ログは、ステージから設定できます。
設定後、API Gateway にリクエストを投げると、CloudWatch Logs に出力されます。
ロググループ名は、API-Gateway-Execution-Logs_\/\<ステージ名> です。
 のテンプレート作成に必要なこと
# はじめに
## CloudFormationのテンプレートとは？
一言でいうとただの「設定ファイル」です。
作成、変更、削除、連携する設定、大きい設定から細かい設定、AWSにあるシステムの設定項目のほぼ全てが設定できます。# 必要な知識・スキル
## 大前提
– AWSの何らかの構築ができること## テンプレートファイルの作り方
– リファレンスを読んで、AWSの構築した設定を再現すればできますAWS リソースおよびプロパティタイプのリファレンス
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.htmlでもこれだけでは難しいし時間がかかります。
## 少し手軽なやり方
1. 画面でAWSの何かをつくる
1. former2で設定を読み取る
1. former2でテンプレートファイルを作る
1. テンプレートファイルを手動で清書する(テンプレートの分割、パラメータ化等)– 参考リンク
[former2](h
ほぼ個人メモ EC2インスタンスのターミナルで日本語入力できるようにする方法
# 目的
– EC2インスタンスにログイン後に日本語入力をできるようにする方法をかんたんにまとめる
# 実施
1. EC2インスタンスにログインして下記コマンドを実行することで日本語の入力が可能になる。
“`terminal
$ sudo echo “LANG=ja_JP.UTF-8” > /etc/sysconfig/i18n
$ sudo yum install -y man-pages-ja
“`
AWS認定デベロッパーアソシエイト(DVA) 合格体験記
受験月：2020/10
AWS認定デベロッパーアソシエイトに合格して嬉しくなっちゃったので記事を書かせてください。#自己紹介
* web系エンジニア2年目、普段はweb、モバイルアプリの設計開発をしています。
* AWS実務経験、インフラ実務経験共に無し。
* AWSは研修で軽く触った程度でした。
* 会社にAWS知識所有者が少ないとのことで受けることになりました。#勉強方法
1. まずはAWSについてあまりにも基礎知識が無かったため、下記リンクのudemyの動画講義を一通り受けました。
udemyに登録した後の14時間限定セールみたいなので1600円ほどで購入できました。
[Ultimate AWS Certified Developer Associate 2020 – NEW!](https://www.udemy.com/course/aws-certified-developer-associate-dva-c01/)2. サービスの特徴や用語などがある程度分かってきたのでudemyの問題集にも手を出してみました、初回の演習が45%しかとれず絶望しました。
Terraformでmoduleに対してfor_eachを使おうとしたらエラーだった話
#前提
会社の業務でTerraformでリソースを管理することが多いのですが、CloudWatch AlarmsをTerraformのmoduleで管理し、for_eachを使って似たようなCloudWatch Alarmを作ろうとしたらエラーがでたお話です。API Gateway + Lambda関数のREST APIの構成に対して、それぞれのLambdaに対して1つのCloudWatch Alarmを作成しようとしました。基本的には同じメトリクス、同じ名前空間で、関数名が違うだけのCloudWatch Alarmをいくつか作ることになります。そこでmodule＋for_eachで簡単に作ろうとしたのですが、エラーが出た話です。
また、監視対象のLambda関数は特定のaliasを持っているものとします。例えば、本番用のLambdaだけ監視したいなど。
筆者はTerraform初心者ですので、何か間違っている点などがあれば、コメントをいただけるとありがたいです。
#結論
terraformのバージョンが0.12系だと、moduleで定義されたリソースに対してfor_each
EC2のEBS拡張
EC2のEBSのボリュームを拡張する話です。
“`bash
[]$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 2.0G 0 2.0G 0% /dev
tmpfs 2.0G 92K 2.0G 1% /dev/shm
tmpfs 2.0G 448K 2.0G 1% /run
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/xvda1 100G 27G 74G 27% /
tmpfs 395M 0 395M 0% /run/user/40503
“`パーティションを拡張する
“`bash
[]$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=4096 old: size=209711071 end=209715167 new: size=
C言語をAWSで使用する場合の環境構築
#前提
業務でC言語を使用することになったので事前学習でドットインストールで勉強することに。
しかし、ドットインストールの[C言語入門](https://dotinstall.com/lessons/basic_c)は、ローカル環境構築の前提。
ローカル環境構築ではロケットスタートできないためAWSでポチれる環境構築方法を調べた#環境
Windows10
AWS cloud9#やりかた
AWS cloud9よりcreate envirmentをしワークスペースを作成する。
あとは普通に「xxxx.c」と拡張子ｃのファイルを作成すればよい。
ちなみにC言語はコンパイル必須なので、gcc -o hello hello.cでコンパイルしたのち、./helloでバッシュ実行している。
“`c:hello.c
ec2-user:~
