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

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

Amazon SNSへの複数メールアドレス設定と既存メールアドレスの変更はできない?

# Amazon SNSとは
Amazon SNS (Amazon Simple Notification Service)は、フルマネージド型メッセージングサービス。
サブスクリプション対象としてSQSやLambda、HTTPエンドポイント、SMSなどが選べるが、本記事ではエンドポイント「Eメール」に関して投稿する。
※内容は2022/06/20時点

## 既存サブスクリプションのメールアドレス変更
編集画面に遷移しても、既存のメールアドレス(エンドポイント)は変更できない。
いったん削除してから再度購読するしかなさそう。

## サブスクリプションにメールアドレスを複数設定
どうやら1サブスクリプションにつき1メールアドレスの模様。
スペース、セミコロン、カンマで区切ってみたが無効だと怒られる。
数名であれば手作業でも良いが、大人数になるとなかなか大変。
対象者だけを含めたメーリングリストを作成できる環境であれば良いが…
![SNS.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2519630/1

元記事を表示

AWS Systems Manager / Incident Managerの設定例

# AWS Systems Managerとは
AWSリソースだけでなくオンプレミスに構築されたサーバも対象とし、運用負荷を大幅に減らすことができる。
一口にSystems Managerといっても機能は多岐にわたり、2022/06時点では18もの機能が存在する。
https://aws.amazon.com/jp/systems-manager/features/#Explorer

本記事ではSystems Managerの中でも、インシデント管理を行うIncident Manager関して記載する。

# Incident Managerとは
CloudWatchAlarmやEventBridge(旧CloudWatchEvents)のイベントをトリガーとして
インシデント起票し、その後の自動復旧の実行や、メール/電話による通知が可能なサービス。
昨今話題のSOAR(Security Orchestration, Automation and Response)に近いサービス。
– インシデントへの対応プランと連絡先を定義できる
– インシデント発生時に対応するためのRunboo

元記事を表示

CloudWatchで通知抑制は出来るのか?

# やりたいこと
CloudWatchAlarmで監視しているインスタンスAがCPU高騰した際に、
CloudWatchAlarmのSNS(Eメール)にて、
初回のみ指定のメールアドレスに通知し、2回目以降は通知さない。

# 結論、できない!
##### サポート回答
>CloudWatchAlarmには上記要件を実現する機能は存在しておらず、
初回のみアラームのアクションを実行するといった対応は出来かねます。

# 対応策
##### サポート回答
CloudWatchAlarmのDisableAlarmAction API(AWS CLIのdisable-alarm-actionコマンド)にて、
アクションの実行を無効化をする。

## 具体的には?
##### サポート回答
CloudWatchAlarmの通知先をSNSではなくLambdaを選択し、
DisableAlarmActionを実行したうえで、次回以降のアクションを無効化する方法。
**CloudWatchAlarm –> SNS –> Lambda –> SNS –> Eメール**

1つ目と2つ目のSNS

元記事を表示

WorkSpaces認証失敗をCloudTrailもしくはCloudWatchで監視したい

# やりたいこと
証明書が導入されていない端末、もしくは合致しない証明書を導入している端末からWorkSpacesへアクセスがあった際、認証に失敗したことを監視したい。

# AWSサービス概要
– CloudTrail
ログインなどのユーザアクティビティとAPI操作をログに記録
– CloudWatch
条件に合致した場合アラームで通知を行うなど、AWSリソースの状態を監視
– WorkSpaces
仮想デスクトップサービス
– AWS Managed Microsoft AD
Active Directoryのマネージドサービス
– AD Connector
オンプレに存在するActive Directoryへのゲートウェイサービス
– Simple AD
比較的小規模な環境で利用するユーザー向けのActive Directory

## 結論、ログイン時の「認証失敗」エラーは監視できない
– サポート回答 ※2022/05/17時点
>AWS Managed Managed ADもしくはSimple ADを用いてWorkSpacesを利用する場合は、
ログイン失敗時にログの記録が

元記事を表示

AWSの一時クレデンシャルを使ってAWSコンソールにアクセスする方法

## はじめに

AWSへのアクセス管理のためにAWS SSOを導入している場合など、IAMロールベースで複数のAWSアカウントを運用するシチュエーションでは、スイッチロールの起点となるAWSアカウントをあまり増やしたくないなどの課題から、[ロール連鎖](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_terms-and-concepts.html)の形で権限を振り出す運用方法を取りたい場合があります。
しかし、ロール連鎖で得た権限を扱う際の実運用上の大きな問題として、AWSコンソールがロール連鎖のスイッチロールに対応していない、という点があります。
APIベースではロール連鎖に対応しているので、AWS CLIなどで一時クレデンシャルベースでAssumeRoleしていけば、最終的に目的のIAMロールの一時クレデンシャルを得ることは可能ではありますが、AWSに対する操作を行ううえで、すべてCLIなどで賄うのは大分つらいものがあります。

幸いAWSは、一時クレデンシャルを元に、そのクレデンシャルの権限でコンソ

元記事を表示

AWS CLIで取得したAmazon CloudWatch Metricsのget-metric-statisticsの結果を、jqでCSVに変換する

# What’s?

Amazon CloudWatch Metricsから統計情報を取得した結果を、CSVに変換したいなというメモです。

# 環境

今回の環境は、こちらです。

“`shell
$ aws –version
aws-cli/2.7.21 Python/3.9.11 Linux/5.4.0-122-generic exe/x86_64.ubuntu.20 prompt/off
“`

AWSのクレデンシャルは、環境変数で設定しているものとします。

“`shell
$ export AWS_ACCESS_KEY_ID=…..
$ export AWS_SECRET_ACCESS_KEY=…..
$ export AWS_DEFAULT_REGION=…..
“`

# お題

Amazon RDSの`CPUUtilization`を対象にしましょう。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/rds-metrics.html

こちらをAWS CLIで取得し、jq

元記事を表示

AWS IoT CoreからTimestreamにルーティングする際、デバイスで付与した日時をタイムスタンプにするIoT Ruleの作り方

# はじめに
Timesteramが東京リージョンで使えるようになりました!
IoTのデータを保存する際に、デバイスで付与した日時をタイムスタンプとして使用するためのIoTルールの設定の方法を記載します。

# 前提
– デバイス~AWS IoT Coreは接続済み
– Timestreamのテーブルは作成済み
– IoTルールからTimestreamに書き込むためのIAM Roleは作成済み

### サービスにつけた名前など
– Timestreamデータベース名:ts-test
– Timestreamテーブル名:ts-table
– メモリストアの保存時間:3時間
とりあえず3時間にした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/155165/fef4c153-6871-d38c-9d60-34f94038fb94.png)

この記事では、**IoT Rule**の作成方法を記載します。

### IoT CoreのTopicに送信するデータ
日時は日本時間で、タイムゾ

元記事を表示

Elastic IPの無料枠について

# 背景
– AWSを勉強中
– 出来るだけ無料枠を使いたくて調査実施
– ログインが面倒なので、固定IPを取得したい
– EIPの料金設定が以外と面倒だったのでまとめる

# まとめ
– EC2とEIPを完全に無料枠で利用する条件が絶妙(さすがAWS)
– 以下の制約を気にする必要有
– EIP制約
– Elastic IP アドレスに関連付けられているインスタンスが実行中である
– EC2
– 1 か月に最大 750 時間が無料枠
– EC2を停止していると、EIPの料金が発生
– EC2は1か月に最大750時間が無料枠
– 1台以上のEC2を利用するとしたら、利用時間以外は停止しておきたい

# 参考
– [EIPで料金発生するパターンとしないパターン #AWS](https://dev.classmethod.jp/articles/cost-of-eip/)
– [すべての Amazon EC2 インスタンスが終了されているにも関わらず、Elastic IP アドレスの料金が請求されているのはなぜですか?](https://

元記事を表示

AWS AmazonLinux2 ホスト名の変更

# 概要
– AmazonLinux2の初期設定についてのまとめ
– /etc/cloud/cloud.cfgの設定
– hostnamectlによるホスト名の変更
– /etc/hostnameの変更確認(念のため)

# Amazon Linuxのホスト名の変更
– [Amazon Linux インスタンスのホスト名の変更](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/set-hostname.html)
– 上記リンクを参照に設定

– /etc/cloud/cloud.cfgの設定
“`
// [preserve_hostname: true]の記載があるか確認
# cat /etc/cloud/cloud.cfg | grep preserve_hostname

// なければ末尾に追記
vi /etc/cloud/cloud.cfg
————————–
# host名設定
preserve_hostname: true

元記事を表示

AWS AmazonLinux2 EPELリポジトリ設定

# 概要
– OS初期設定時に必要な設定の一つ
– 以下の2点についてまとめた
– リポジトリの設定:EPELリポジトリについて
– yum updateにて最新化

# リポジトリの設定:EPELレポジトリについて
– EPELとは、
– [CentOSなどで使う、EPELってなんだ?](https://qiita.com/charon/items/f5732694515d174851b3)
– EPELは、Extra Packages for Enterprise Linuxの略
– エンタープライズLinux用の高品質な追加パッケージセットが含まれている
– 標準のリポジトリでは提供されていないパッケージを利用することが可能

# Amazon Linux2でEPELリポジトリを利用する方法
– [AWSサイト](https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-install-extras-library-software/)
– [Amazon Linux

元記事を表示

AWS AmazonLinux 日本語化(locale設定)

# 概要
– Amazon Linuxの初期設定、日本語化についてまとめた

# 日本語化
– localectlコマンドにて変更等を実施する

– ロケールの確認
“`
# localectl status
▼コマンド実行結果
————————————
System Locale: LANG=en_US.UTF-8
VC Keymap: n/a
X11 Layout: n/a
————————————
“`

– 日本語化
“`
// 変更可能なロケールの確認
localectl list-locales | grep -i jp

// 日本語に設定変更
localectl set-locale LANG=ja_JP.utf8

// 変更確認
localectl status
▼コマンド実行結果
————————————
System Locale: LANG=ja_JP.utf8

元記事を表示

AWS AmazonLinux 時刻同期設定

# 背景
– 2022/08/04時点の情報
– AWSの時刻同期についてのまとめ

# 目次
1. タイムゾーンの設定
2. 時刻同期設定

# 環境
“`
# uname -a
Linux CMS_ALLIN_01 5.10.130-118.517.amzn2.x86_64 #1 SMP Wed Jul 13 16:51:52 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

# cat /proc/version
Linux version 5.10.130-118.517.amzn2.x86_64 (mockbuild@ip-10-0-43-203) (gcc10-gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1), GNU ld version 2.35-21.amzn2.0.1) #1 SMP Wed Jul 13 16:51:52 UTC 2022

# cat /etc/system-release
Amazon Linux release 2 (Karoo)
“`

# タイムゾーンの設定

元記事を表示

Athenaを使ってAWSリソースの削除ログをみつける

### Athenaを使ってAWSリソースの削除ログをみつける

– KMSが削除されてしまったので、その犯人探し

“`
SELECT *
FROM “$DBNAME”.”$TABLENAME”
CROSS JOIN UNNEST(resources) AS t (resource)
WHERE eventSource = ‘kms.amazonaws.com’
AND resource.arn = ‘arn:aws:kms:ap-northeast-1:XXXXXXXXXXXX:key/YYYYYYYYYYYY’
AND NOT eventName = ‘Decrypt’
limit 100;
“`

元記事を表示

ElasticBeanstalkで動かしているRailsプロジェクトにpuma_worker_killerを導入する

## 起きた問題
ElasticBeanstalkで動かしているRailsプロジェクトのメモリ使用率が高止まりしていました。
プロセスを見てみるとPumaが主な要因でした。
[![Image from Gyazo](https://i.gyazo.com/1b8f9882a59b3dace952534fe78ea802.png)](https://gyazo.com/1b8f9882a59b3dace952534fe78ea802)

メモリを解放するために、インスタンスの自動入れ替えも検討しましたが、ElasticIPの自動付与問題の課題があり、今回は`puma_worker_killer`というgemを使用してみることにしました。

puma_worker_killerの公式ページ
https://github.com/zombocom/puma_worker_killer

## 前提
– ElasticBeanstalk環境 (Ruby 2.7 running on 64bit Amazon Linux 2/3.4.7)
– EC2インスタンス数:1台 (ElasticIP付き

元記事を表示

Lihgtsail上のWordpressで急に負荷が上がった時の対応

AWSサービスの一つLightsailは、EC2以上に簡単に仮想サーバを作って利用できるので便利です。

# 起こった現象
早速、今あるWordPressベースのWebサイトをどんどんこちらに移行を進めています。
WordPressサイトを7,8個Lightsail上に移行させて稼働させたところ、急にCPU使用率が上がってレスポンスが全く返ってこなくなってしまいました。

topやpsコマンド、Apacheのerror_logなどを確認しながら原因を調べていたのですが今までにない現象だったのでなかなか原因救命に手こずりました。

結果的に原因はphp-fpmでした。今まで全く触ったことがなかったので設定変更もちょっと怖い分野。。。
以下の記事も参考にさせていただきながら、試しに静的構成にして同時稼働数も抑えたところ無事に安定しました。

https://qiita.com/YasumiJP/items/fd36b4a7df08f92d2da4

# 具体的な対応内容
LightsailはBitnamiベースなので参考にした記事とは設定ファイルのある場所が異なります。
具体的には、~/s

元記事を表示

UnityからCognitoUserPool認証を使用してAppSyncに接続する

# はじめに
AppSyncで出回っている認証方法はデフォルト設定のAPI-KEYのものが大半だが、そこには罠があり最長1年で有効期限となってしまう。
その対策として自動更新の仕組みを入れる必要があるが、仕組みを入れたことを忘れそうなので認証期限の長いCognito認証の方法を調べてみました。

# 基本的なGraphQLへの接続方法

えどさんの記事が非常に参考になります。
以降はこの記事を補完する形で記載します。

https://edom18.hateblo.jp/entry/2021/12/11/105140

# Cognito設定
## 初期設定
### デフォルト設定でUserPoolを作成する
* アプリクライアントを作成する
* トークンの期限を設定する(Max10年)
* クライアントシークレットを生成のチェックを外す
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1336886/72d9c2c5-2916-07ba-276c-c2e

元記事を表示

AWS SDK Rubyでスタブを行う

## はじめに
AWS SDKを使用したコードに対してテストを記述したい場合、AWSのSDKで用意されているClientStubsを使用して、スタブを行うことが可能です。
ドキュメント自体は公式が出しているものがありますが、この例だけではやりたいこと(`Aws::S3::Client`以外のインスタンスを使うケース)が実現できなかったので、今回調べたことについてまとめました。

## 環境
– Ruby: 2.7.1
– aws-sdk: 3.1.0
– aws-s3-sdk: 1.114.0

## 公式ドキュメントから
https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/ClientStubs.html

このドキュメントにあるように`Aws::ClientStubs`というモジュールが、各サービスに対応したClientクラスにincludeされています。

今回はS3を使って、その例を紹介します。

このモジュールに定義されているのは`api_requests`, `stub_data`,`stub_respo

元記事を表示

AWSで始めるCI/CD 〜CI/CDの仕組み〜

## はじめに

AWSでCI/CDを実装する時、Code兄弟を使うことが多くあります。
[AWSで始めるCI/CD 〜Code兄弟達の紹介〜](https://qiita.com/hiroaki-u/items/b527264093eeb1e406e2)でも記載していますが、Code兄弟は『CodeCommit』『CodeBuild』『CodeDeploy』『CodePipeline』を指しており僕が勝手にそう呼んでいるだけです笑。
※ちなみにCode兄弟を使用しなくても実装することは可能です。

本記事ではAWSのCode兄弟でCI/CDを実装する時の仕組みを見ていきます。
「仕組み」というと少し仰々しいですが、要はサービス間の動きを見て、どのようにCI/CDが実行されているのか理解していこうという趣旨です。
– どのようにCI/CDのトリガーを検知しているのか?
– アーティファクトファイルはどこに保存されているのか?
– そもそもCI/CDとはなんなのか?

等もし疑問に思っている方がいらっしゃったら是非呼んでいってください〜!
ちなみに一応本記事は以下の2部構成になっているの

元記事を表示

AWSで始めるCI/CD 〜Code兄弟達の紹介〜

## はじめに
みなさんCI/CDのツールって何を使っていますか??
『Jenkins』『Circle CI』『GitLab』その他諸々色々ありますよね。
今回取り上げるのはAWSのサービスを使ったCI/CDです。

AWSでCI/CDを構築するにはCode兄弟が必要になります。
ちなみにCode兄弟は以下のサービスをまとめてそのように呼んでいます。
『CodeCommit』『CodeBuild』『CodeDeploy』『CodePipeline』
※ Code兄弟は僕が勝手にそう読んでいるだけで公式ではありません笑

今回の記事では、AWSで構築するCI/CDの仕組みや、その時出てくるサービス(Code兄弟)の紹介していきます!
長くなってしまったので2つに分けました。
※ハンズオンというよりは、各サービスやAWSでのCI/CDの仕組みを書いた記事になりますので、ご注意ください。

– [AWSで始めるCI/CD 〜Code兄弟達の紹介〜(本記事)](https://qiita.com/hiroaki-u/items/b527264093eeb1e406e2)
– [AWSで始めるC

元記事を表示

AWS Load Balancer Controller v2.3.0 から導入された Optimized SG rules について

[AWS Load Balancer Controller](https://github.com/kubernetes-sigs/aws-load-balancer-controller) v2.3.0 から導入された **optimized security group rules** という機能について記載します。
直訳すると、**最適化されたセキュリティグループルール** です。

なにコレ?という感じですが、
ALBに独自で作成したセキュリティグループを割り当てた際は、これまではクラスタのセキュリティグループにALBからのインバウンドトラフィックの許可を別で管理する必要がありました。
しかし、この機能の導入によりコントローラが自動で管理してくれるようになります。

## TL;DR
結論を先に書くと以下のとおりです。
### 前提
– v2.3.0+
– Kubernetes 1.16+ (v2.3.0時点)
– cert-manager v1.5.3+ (v2.3.0時点)
– 最新バージョンは下記参照
– https://github.com/kuberne

元記事を表示

OTHERカテゴリの最新記事