AWS関連のことを調べてみた2023年02月17日

ChatGPTに「パブリックサブネットとプライベートサブネットを含むVPCを作成するAWS Cloudformationのテンプレート教えて」と聞いてみた

標題通りです、結果出てきたコードが下記、動くかどうか試してはないけど十分に実用に耐えるんではないかと思う。

—
#### 質問（１）パブリックサブネットとプライベートサブネットを含むVPCを作成する　AWS Cloudformationのテンプレート教えて

出力されたコード

“`ruby:qiita.rb
{
“Resources”: {
“MyVPC”: {
“Type”: “AWS::EC2::VPC”,
“Properties”: {
“CidrBlock”: “10.0.0.0/16”,
“Tags”: [
{
“Key”: “Name”,
“Value”: “MyVPC”
}
]
}
},
“PublicSubnet”: {
“Type”: “AWS::EC2::Subnet”,
“Pro

【読書】社会人1年目で読んだ本をおすすめ度とともに紹介する

大畑です。

大学を卒業し、22年新卒社会人になってから早くも1年が経とうとしています。
もう数ヶ月で後輩ができ、新卒カードは有効期限切れになるのが信じられません。( ；∀；)

私はインフラ領域を担当しており、この一年は特にAWSに触る機会がとても多く、AWS資格も３つ取りました。

今回はこれから社会人になる2023年新卒の方、またAWSをこれから触りたい方向けに、

「社会人一年目で読んだ本をおすすめ度と共に紹介する」

をお送りします。

# 社会人一年目で読んだ本　（AWS編）

AWSにまつわる本をまとめました。

資格取得のための本も載せているため、これからAWSの資格取得を目指される方もぜひご覧ください。

### AWSの仕組みと技術がしっかりわかる教科書

内容：AWSとは何かから始まり、主要なサービ

ヒューマンエラーの少ないCloudFormationテンプレートの作り方

こんばんは、大畑です。

私事ですが、AWSを学び始めて半年ほどが経ちました。

業務でAWSを使用したクラウド環境の構築を行う際に、CloudFormationというサービスをよく触ります。

CloudFormationはクラウド基盤をコード化する（IaC : Infrastructure as Code）ことで

・Git等を使用したインフラ基盤のバージョン管理ができる
・構築を自動化し、業務効率化できる
・開発環境のクラウド基盤を複製し、ステージング環境、本番環境に同等の構成が作れる

など、様々なメリットを受けることができます。

一方で、yamlやjsonでコードを記述する際や、CloudFormationをコンソールから使用する際にはどうしても人の手が加わります。
これはエラーの原因となりえるため、なるべく排除していきたいところです。

ということで今回は

「ヒューマンエラーの少ないCloudFormationテンプレートの作り方」

について書いていきたいと思います。

# 【初心者向け】CloudFormationとは

> AWS CloudFormati

【AWS】CloudFormtionでブログサービスを構築してみた(05.Waf編)

# 01.はじめに
[【AWS】CloudFormtionでブログサービスを構築してみた(概要編)](https://qiita.com/1k5/items/4f6d61373e80f824bd9a)の最終回である。
過去に公開した記事は下記の通りである。
・[【AWS】CloudFormtionでブログサービスを構築してみた(概要編)](https://qiita.com/1k5/items/4f6d61373e80f824bd9a)
・[【AWS】CloudFormtionでブログサービスを構築してみた(01.Network編)](https://qiita.com/1k5/items/d268697691ef2ef3dd0e)
・[【AWS】CloudFormtionでブログサービスを構築してみた(02.EC2,RDS,ALB編)](https://qiita.com/1k5/items/5acca0ee627ec37b56da)
・[【AWS】CloudFormtionでブログサービスを構築してみた(03.S3,CloudFront編)](https://qiita.com/1

【AWS】CloudFormtionでブログサービスを構築してみた(04.Route53編)

# 01.はじめに
[【AWS】CloudFormtionでブログサービスを構築してみた(03.S3,CloudFront編)](https://qiita.com/1k5/items/a19cb65bb749b985970c)の続きである。
過去に公開した記事は下記の通りである。
・[【AWS】CloudFormtionでブログサービスを構築してみた(概要編)](https://qiita.com/1k5/items/4f6d61373e80f824bd9a)
・[【AWS】CloudFormtionでブログサービスを構築してみた(01.Network編)](https://qiita.com/1k5/items/d268697691ef2ef3dd0e)
・[【AWS】CloudFormtionでブログサービスを構築してみた(02.EC2,RDS,ALB編)](https://qiita.com/1k5/items/5acca0ee627ec37b56da)
・[【AWS】CloudFormtionでブログサービスを構築してみた(03.S3,CloudFront編)](https:

【AWS】CloudFormtionでブログサービスを構築してみた(03.S3,CloudFront編)

# 01 はじめに
[【AWS】CloudFormtionでブログサービスを構築してみた(02.EC2,RDS,ALB編)](https://qiita.com/1k5/items/5acca0ee627ec37b56da)の続きである。
過去に公開した記事は下記の通りである。
・[【AWS】CloudFormtionでブログサービスを構築してみた(概要編)](https://qiita.com/1k5/items/4f6d61373e80f824bd9a)
・[【AWS】CloudFormtionでブログサービスを構築してみた(01.Network編)](https://qiita.com/1k5/items/d268697691ef2ef3dd0e)
・[【AWS】CloudFormtionでブログサービスを構築してみた(02.EC2,RDS,ALB編)](https://qiita.com/1k5/items/5acca0ee627ec37b56da)

`この記事で扱うものはコンポーネントは下記である。`
1.S3
2.CloudFront

# 02 構成図
下記のオレンジ枠

【AWS】CloudFormtionでブログサービスを構築してみた(02.EC2,RDS,ALB編)

# 01.はじめに
【AWS】CloudFormtionでブログサービスを構築してみた(概要編)の続きである。
過去に公開した記事は下記の通りである。
・[【AWS】CloudFormtionでブログサービスを構築してみた(概要編)](https://qiita.com/1k5/items/4f6d61373e80f824bd9a)
・[【AWS】CloudFormtionでブログサービスを構築してみた(01.Network編)](https://qiita.com/1k5/items/d268697691ef2ef3dd0e)

`この記事で扱うものはコンポーネントは下記である。`
1.EC2
2.ALB
3.RDS(スナップショットを復元する)

`また、テンプレートを投入後、手作業が発生するのでこちらも対応する。`
`SSM経由でEC2にログインして実施する`
1.[こちら](https://qiita.com/1k5/items/32bbe213596aabcf3a59)でスナップショットを復元したRDSの接続先が
http\://localhost:500になっている(S

【AWS】CloudFormtionでブログサービスを構築してみた(01.Network編)

# 01.はじめに
[【AWS】CloudFormtionでブログサービスを構築してみた(概要編)](https://qiita.com/1k5/items/4f6d61373e80f824bd9a)の続きである。
今回から実際のコードを記述する。
`この記事で扱うものはコンポーネントは下記である。`
1.VPC

2.Internet Gateway

3.Route Table

4.セキュリティグループ

5.サブネット

6.VPCエンドポイント

7.Route53(ゾーン登録のみ)
　　※後続の証明書発行でゾーン登録が
　　　必要になるのでこのタイミングでゾーンだけ作成しておく。[参考](https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/dns-validation.html)
　　　
# 02.構成図
構成図にすると下記のようになる。
![構成図２-Network.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1050566/bd

AWS EC2インスタンスで、OSのテンプレートに入れておくと便利なもの②

[前回](https://qiita.com/If_it_bleeds-we_can_kill_it/items/9280b6aa74263963d552)の続き。

前回はRHELにSSM-AgentとCloudwatchAgentをインストールした。
このあとはIAMロールの設定を行う。

IAMよりロールを作成。

AWSサービスを選ぶ。

ユースケースとしてEC2を選ぶ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazona

【AWS】CloudFormtionでブログサービスを構築してみた(概要編)

# 01.はじめに
マネジメントコンソールで構築したブログサービスをコード化したいと思い、構築してみた。
簡潔に言うとEC2にWordpressをインストールして、ブログサービスを公開するものである。
また、障害時にはSorryページを配信する。
なお、今回使用したEC2のAMIとRDSのスナップショットは[こちら](https://qiita.com/1k5/items/32bbe213596aabcf3a59)で取得したものを使用している。
一部コード化できていない部分はあるが(後述)、概ねCloudFormtionで構築している。
なお、一つの記事にすると長すぎるので下記要領で分割して記事を公開する。

・[【AWS】CloudFormtionでブログサービスを構築してみた(01.Network編)](https://qiita.com/1k5/items/d268697691ef2ef3dd0e)
・[【AWS】CloudFormtionでブログサービスを構築してみた(02.EC2,RDS,ALB編)](https://qiita.com/1k5/items/5acca0ee6

AWS EC2インスタンスで、OSのテンプレートに入れておくと便利なもの

AWSでEC2インスタンスのOSといえば、いつもAmazon Linux2を使っていた。昔はAmazon Linuxの時代もあったけれど、いつの間にかサポート期限が切れて、AL2切替対応とかを騒ぎながらやってた時期もあったな。。。

Amazon Linux2も気が付けばサポート期限が近い。2025年まで期限はあるが、5年以上使う場合、ライフサイクルが短い。
このためRed Hat Enterprise Linux を選定したが、使ってるディストリビューションが同じFedoraだから、さほど困ることはなかった。ただ、ハマりポイントはあるので、そこをご紹介。

AWSで複数のEC2インスタンスを構築するとき、1台マスター的なOSテンプレートを作って、それをAMIコピーするとデプロイの時短となる。VMware時代もやっていた手法。

備忘兼メモ。以下はLinux（RHEL8.6）での手順だが、手順は異なれど、Windowsも同様に設定しておくといいと思います。

# 前提
・EC2インスタンスがインターネットに接続できること。
※またはSSMのエンドポイントが接続できるインスタンスである

CodeBuild operational notification 対応

# 課題
AWS から CodeBuild operational notification が届きました。

> We are reaching out to you because you ran a build using the Ubuntu standard 4.0 [1] Docker Image, in the last 30 days.
Starting March 30, 2023, AWS CodeBuild will be moving these images to an unsupported status and they will not be cached on the build hosts anymore.
>
> You may continue using these images for your builds, but will notice an increase in provisioning latency after March 30, 2023.
These images will also not be getting any n

ERROR: `GLIBC_2.29′ not found ｜Ruby AWS SAM で Nokogiri 使用時の回避方法

AWS SAMでLambdaを動かそうとした時、以下のエラーが出たため修正した。
M1だと発生するのかもしれない。

“`zsh
$ sam local invoke HelloWorldFunction –event events/event.json
Invoking app.lambda_handler (ruby2.7)
Local image was not found.
Removing rapid images for repo public.ecr.aws/sam/emulation-ruby2.7
Building image…………………………………………………………………………………………………………………………………………………………………………………………………….

AmazonLinux2に最新のMariaDBをyumインストール

# AmazonLinux2へのMariaDBのインストール

通常の方法でMariaDBを導入する場合、次のような感じになります

“`
$ sudo yum -y update
$ sudo yum -y install mariadb-server
“`

これでインストールされるMariaDBのディストリビューションは `mariadb-server.x86_64 1:5.5.68-1.amzn2` (MariaDB 5.5.68) になります。

これを最新のディストリビューションにするためには、オフィシャルページの通り、yumのレポリストを作成（編集）して、その情報に基づいてインストールすることになります。

https://mariadb.org/download/?t=repo-config

念のためですが、バージョンが新しければ新しいほど良いというわけではありませんので、必要に応じて導入するバージョンを選択してください。（今回はサーバー設定からのスクラッチビルドだったため、ついでに最新版にしてみました）

https://qiita.com/katzueno/i

CloudTrail LakeでQuickSightのログを監査してみる

# はじめに

CloudTrailはAWSにおける全てのAPIを記録することができます。
**QuickSightのログはCloudTrailに出力されます。**

QuickSight側にログ閲覧インターフェースがあれば便利なのですが、、残念ながらCloudTrailの仕様にも慣れる必要があります。

ログの概要を確認するだけであればCloudTrailのメニューである「イベント履歴」(直近90日間)だけで済みますが、**ログを詳細に調査しはじめると、そこから急激に深い海に足を踏み入れる**ことになります。

**深い海とはAthenaやCloudTrail Lakeを指します。**
従来、CloudTrailの詳細なログ調査は「AthenaでCloudTrail用のテーブルを作ってSQL文をかく」という方法がスタンダードでした。最近はCloudTrail LakeというSQLインターフェースができました。これによりテーブル作成の手間が省けるようにはなりましたが、中身はAthenaとほぼ変わらずSQL文を駆使していく形になります。

**CloudTrail LakeやAthena

Lambdaの定期実行をEventBridgeのルールからスケジューラへ

# Lambda関数のスケジュール実行

Lambda関数を定期的に実行したい場合、今までは **EventBridge ルール** の cron式を使ってスケジュールをセットすることが多かったと思います。

その後、**EventBridge スケジューラ** が登場しました。

AWSとしては、スケジュールは EventBridge スケジューラ を推奨しているようです。

# Lambda関数のエイリアスやバージョンの実行は？

## 今まで（移行時に課題あり）

じゃあ **EventBridge スケジューラ** に移行してみよう、と進めていたところで、困りました。

Lambda関数のバージョンやエイリアスを普段よく使っているのですが、バージョンやエイリアスの選択が画面上にありませんでした。
で、仕方なく EventBridge スケジューラ には移行できないなあ、とあきらめていました。

以下リンクの記事で見ると、添付の画像ではLambda関数のバージョンやエイリアスは選べそうにないですよね。

https://dev.classmethod.jp/articles/am

nodejsでaws-sdkを使った時にハマったこと

# はじめに

`AWS Lambda` `runtime: nodejs`を使って
`S3`にファイルをアップロードしようとした際につまづいたことをメモ。

# 環境

* aws-lambda
* runtime: nodejs 14.*

# 結論

#### `aws-sdk`にはV2とV3がある

#### そして、私の環境ではV2だと動きませんでした。

クラメソにも記事がありました。

https://dev.classmethod.jp/articles/aws-sdk-for-javascript-v2-v3-diff/

# 導入方法の違い

“`bash
// V2
$ npm install aws-sdk

// V3
$ npm install @aws-sdk/client-s3
“`

# S3へオブジェクトをuploadするときの違い

## V2の場合

“`typescript
import * as AWS from ‘aws-sdk

RDSでスナップショットを別のAWSアカウントに共有、復元したい

## 目的

クロスアカウントでRDS移行したいとか、障害切り分けの際に別の環境で再現したいというケースがあったので
手順を書いてみました。

## やったこと

### ソース側AWSアカウント

#### ソースRDSの手動スナップショットを取得する。


RDSのコンソールからスナップショットを選択しスナップショットを取得します。


(スナップショットのサンプル)

#### ターゲット側AWSアカウントからのアクセスを許可したKMSキーを使ってスナップショットを暗号化コピーする。

![image.

EC2上のWindowsサーバーのイベントログ、パフォーマンスカウンターの情報をCloudWatchに出力してみた

## はじめに
稼働中のEC2インスタンスについて、インスタンスのモニタリングやCloudWatchではCPU使用率、ネットワーク送受信量、ディスク読み書きなど、限られたリソース情報しか確認する事ができません。

また、OS(Windows)の障害やセキュリティ的に注意が必要なイベントが発生した場合も、インスタンスにリモートデスクトップ接続をするなどして、Windowsのイベントログなどを確認する必要があります。

SystemsManagerの管理下にあるインスタンスについては、フリートマネージャーやセッションマネージャーでインスタンスにアクセスして、OSのパフォーマンス状況(Windowsであればパフォーマンスモニターのカウンター)、Sysログ(Windowsの場合イベントログ)などを確認する事ができますが、多くのインスタンスが稼働している環境では、これではまともに運用監視する事ができません。

以前は、Zabbixなどをインスタンスに入れてEC2インスタンスの運用監視をしたりしていましたが、現状では、SystemsManagerやCloudWatchエージェントを利用する事で、C

ChatGPTにLambda（Node.jsランタイム）で環境変数を参照する方法を聞いてみた

# やったこと
ググるのがめんどくさかったのでChatGPTに聞いてみました。

## 質問

“`
> LambdaのNode.jsランタイムで環境変数の参照の仕方を教えて
“`

## 回答
AWS LambdaのNode.jsランタイムでは、環境変数を参照するために `process.env` オブジェクトを使用します。このオブジェクトには、Lambda関数の実行時に設定されたすべての環境変数が含まれます。

以下は、Lambda関数内で環境変数を参照する方法の例です。

“`
exports.handler = async (event, context) => {
// 環境変数の参照
const myVar = process.env.MY_VAR;
console.log(`MY_VARの値: ${myVar}`);

// 他の処理
// …
};
“`

上記の例では、`process.env.MY_VAR` を使用して、`MY_VAR` という名前の環境変数の値を参照しています。Lambda関数が実行される