- 1. 【GitHub Actions】Fargateへの自動デプロイ時にハマったことと対応まとめ
- 2. re:Invent 2022 データベース関連の新サービス、アップデートまとめ
- 3. AWS SAAを勉強するうえで引っかかったところや要メモのまとめ
- 4. Auroraのカスタムエンドポイントが変更中も利用できるようになってた
- 5. DynamoDBのテーブルのレコード数をカウントし、CloudWatchでメトリクス表示する
- 6. LambdaでDataSyncのタスクの実行を自動化させる
- 7. ローカル環境のMySQLにAWSAuroraのDBデータをインポートする方法
- 8. AmazonConnectで日本の電話番号取得にサポート問い合わせが必要だった件について
- 9. Athena でのテーブルの作成（Hive DDL）
- 10. Lambda→SNS→Chatbot→Slackへの通知がうまくいかない
- 11. SalesforceのイベントをAppFlowに伝える方法
- 12. aws cli で組織子アカウントの課金をOU単位で振り分けした
- 13. aws cli で組織子アカウントのサービス単位課金を抽出したい
- 14. CloudWAN④セグメント二つ、VPCアタッチメントによるマルチリージョン構成
- 15. CloudWAN③セグメント一つ、VPCアタッチメントによるマルチリージョン構成の構築
- 16. CloudWAN②CloudWANの初期設定
- 17. ECS Fargate ソフトウェア・アップデートの更新確認方法と手順まとめ
- 18. AWSのアクセスキーからどのAWSアカウント、どのIAMユーザーかを確認する
- 19. FinOpsとは クラウド利用のコスト最適化を本質的に考えるために知っておくべきワード
- 20. Goを使ってDynamoDBに一括書き込み
【GitHub Actions】Fargateへの自動デプロイ時にハマったことと対応まとめ
# 概要
下記記事を参考にGitHub ActionsでのCI/CDを構築した。– test
https://zenn.dev/ryouzi/articles/cd6857c08e60e7
– deploy
https://qiita.com/hatsu/items/a70d5c49a39561836751
※ubuntuとcheckoutについてはそれぞれ最新バージョンに変更して利用した。
– ubuntu→latest
– checkout→v3テストの方は特に問題なく設定できたが、デプロイではハマる箇所が多かったためまとめ。
# 環境
– アプリ
– ruby 3.0.2
– rails 6.1.4
– mysql 8.0.31
– インフラ
基本的にこちらの記事の通り。https://qiita.com/hatsu/items/22e11e94a0a981d78efa
HTTPSでアクセスできるようSSL化まで行っている、
ローカル→(HTTPS)→ALB→(HTTP)→Fargate⇄RDS
の状態。# 発生したエラーと対応
re:Invent 2022 データベース関連の新サービス、アップデートまとめ
# re:Invent 2022で発表されたデータベース関連のアップデートをまとめました
## Amazon Aurora Zero ETL integration to Redshift
https://aws.amazon.com/jp/about-aws/whats-new/2022/11/amazon-aurora-zero-etl-integration-redshift/– Aurora で扱うペタバイト規模のトランザクションデータに対して Amazon Redshift を使用し、ほぼリアルタイムの分析や機械学習 (ML) を実現
– Aurora に書き込まれたトランザクションデータは、数秒以内に Amazon Redshift で利用可能
– 複雑なデータパイプラインを構築および維持して抽出、変換、ロード (ETL) 処理を行う必要なし
– 米国東部 (バージニア北部) リージョンで、MySQL 8.0 と互換性のある Amazon Aurora MySQL 3 の限定プレビューとして利用可能## Amazon RDS Optimized Reads および
AWS SAAを勉強するうえで引っかかったところや要メモのまとめ
# AWS SAA 合格した感想など
去る2022年12月、AWS SAA（ソリューションアーキテクトアソシエイト）を合格しました。先立って合格していたCLF（クラウドプラクティショナー）と合わせると、6週間くらいの学習期間だったと思います。
採点されない問題が出題される（＝範囲外の難しい問題が何故か出る）ため、一見出題される問題の内容はCLFでも意外と難しく感じられましたが、やはり輪をかけてSAAのほうが難しかった印象です。実際に出題された内容云々よりは、学習範囲、とくに03に内容がアップデートされていたりするので、引っかかるところが多く、学習しながら乱雑にまとめていたメモがあるので後進のために投下しておきます。
なお、ガチのメモなので、「ここまではわかっているけどここで引っかかった」という、私の脳みそのメモリ番地にアクセスしないと書いてあることの前提条件がわからない内容も多分に含まれます。
ですので、逆にこの中途半端な内容をもとに自らの知識とのすり合わせを行ったり、不明な点を調べるなどするとさらにブラッシュアップされるのではないでしょうか。物は言いようですが。以下、乱雑に
Auroraのカスタムエンドポイントが変更中も利用できるようになってた
# 以前まで（公式ドキュメントによると、2022/3/18前まで）
Auroraカスタムエンドポイントは変更中に一時的に接続エラーとなる場合があり
カスタムエンドポイントのメンバーを変更したりするためにシステムを停止する必要がありました。> You can’t connect to or use a custom endpoint while the changes from an edit action are in progress\. It might take some minutes before the endpoint status returns to **Available** and you can connect again\.
勘弁してくれよAWSって思いながら、実際にカスタムエンドポイントを変更している最中に
クライアントエラーするのかテストをしたことがあり
記載の通り、数十秒繋がらなくなる場合があるという結果が出ていました。クライアント側がリトライするように実装すればいいんですけどね。。。
# ひっそりと更新されてた
https://g
DynamoDBのテーブルのレコード数をカウントし、CloudWatchでメトリクス表示する
2023年1月現在、DynamoDBのレコード数を確認する
CloudWatchメトリクスがないためこの記事を投稿しました。# 全体の流れ
# 構築するリソース
・DynamoDB 適当のもの ・Lambda ランタイム： Python3.9 ・EventBridge 1分ごとにLambdaをトリガーするスケジュール ・IAMロール/IAMポリシー Lambda実行ロールとEventBridgeがLambdaを呼び出すロール
# 0. まずはじめに
手順1以降のコピー&ペーストを行いやすいように、AWSアカウントIDを変数に割り当てる“`shell:CLI
ex
LambdaでDataSyncのタスクの実行を自動化させる
# 概要
AWS DataSyncで作成したタスクをコンソール上ではなく、イベント駆動型でAmazon S3からAmazon EFSにデータ転送を行います。具体的には下記の流れを想定しています。
1. Amazon S3にファイルをアップロードします。
2. それがトリガーとなってAWS LambdaがAWS DataSyncを実行します。
3. AWS DataSyncでアップロードされたファイルをAmazon EFSに同期します。
4. Amazon EC2上でマウントされたEFSファイルシステム内を確認します。
# 注意事項
* AWSサービスに知見のある方を対象にしていますが、そうでもない方にも試して頂けると嬉しいです！
* 一つのリージョンでリソースを構築します。今回は東京リージョンで作成しま
ローカル環境のMySQLにAWSAuroraのDBデータをインポートする方法
タイトルの内容を作業する際にイメージできていなかったので、備忘録として残します。
## この記事で分かること
– **DB(MySQL)のインポート、エクスポート方法**
– **AWSへのssh方法(ローカル環境→踏み台サーバー接続→本番環境サーバー接続)**
– **AWSのDBデータをローカルにコピー(インポート)する方法**行きましょう！
## DB(MySQL)のインポート、エクスポート方法
### エクスポート
“`bash
$ mysqldump -u migration_user -p –set-gtid-purged=OFF –no-tablespaces -R -h hoge-aurora.cluster-ro-fuga.ap-northeast-1.rds.amazonaws.com hogefuga > hoge.sql
“`
ホスト名はamazon-aurora。
データベース名はhogefuga。
これらをhoge.sqlというファイル名でエクスポートします。オプションの意味は以下の通りです。
mysqldump:DBのバックアップ
AmazonConnectで日本の電話番号取得にサポート問い合わせが必要だった件について
# 前提条件
この記事は、2023/01頃に書かれています。# ドキュメントの手順
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/claim-phone-number.html
管理コンソールから取得できるとドキュメントには記載されていますが、管理コンソールからは取得できません。
昔は管理コンソールから取得できていた時代もありました。
（はじめてAmazonConnectを触った頃は出来ていたのになぁ～・・・）# 番号払い出しの流れ
+ AmazonConnectのインスタンス作成（申請にはインスタンスのARNが必要）
+ 身分証明・会社証明などの書類準備（起票前に準備が望ましい）
+ AWS管理コンソールからサポートケースを起票(Service limit increase)からの起票（日本の電話番号を取得したい旨を記載）
+ 申請用のリッチテキストファイル（IdentityDetails.rtf）をサポート担当から貰える
+ 必要書類をS3にアップロードする
+ 承認OKがでれば番号が貰える（３
Athena でのテーブルの作成（Hive DDL）
## 初めに
Athena のテーブル作成には、次の方法がある。
– ①AWS Glue クローラ
– ②Athena のテーブル作成フォーム
– ③Hive DDLhttps://docs.aws.amazon.com/ja_jp/athena/latest/ug/creating-tables.html#to-create-a-table-using-the-wizard
ここでは、主に③で作成する場合の項目について理解を深めるために、要点を纏めてみようと思います。
## CREATE EXTERNAL
|パラメータ|説明|
|—|—|
|EXTERNAL|常に EXTERNAL キーワードが使用される。
EXTERNAL キーワードを指定せずに CREATE TABLE を使用すると、Athena でエラーが発生する。|
|[IF NOT EXISTS]|既に同じ名前のテーブルが存在している場合はテーブルの作成を行わないようにする。|
|[db_name.]table_name|Athena のテーブル名では大文字と小文字は区別されない。
Apa
Lambda→SNS→Chatbot→Slackへの通知がうまくいかない
## はじめに
Lambdaで取得した内容をSlackへ通知させようとしたときの話です。
以前、CloudWatchアラームをSlackへ通知させるために「SNS→Chatbot→Slack」の構成で実装した経験があったため、今回もその構成を使用したのですが、Slackへ通知されない、エラーも出ない、という状況に陥りました。## 原因
原因調査のために色々と調べていたところ、こちらの記事を発見しました。* [Amazon SNS から AWS Chatbot を経由した通知がうまくいかない原因と対処方法](https://dev.classmethod.jp/articles/tsnote-support-chatbot-launch-001/)
Chatbotは、[ドキュメント](https://docs.aws.amazon.com/chatbot/latest/adminguide/related-services.html)に記載しているサービスからの通知のみサポートしているとのことで、Lambdaがそのサービスの中にないことが原因と判断しました。
## 対処方法
SalesforceのイベントをAppFlowに伝える方法
# 概要
– SalesforceのイベントをAppFlowに伝える方法を2通り紹介したいと思う。
# AppFlowを使ったSalesforce同期
– 今まではSalesforce（以降SF）の情報をアプリケーションに同期する方法は下記のようなものが一般的だった。
– アプリケーション側でAPIを用意する。
– SFからアプリケーションのAPIのエンドポイントにリクエストを送る。
– 現在下記のような同期方法もあります。一見すると工程が増えて複雑ですが、諸事情により「SFからリクエストを投げる」部分の実装がなくてもSFの情報をアプリケーションに同期する事ができる。
– AppFlowにてSFの任意のオブジェクト
aws cli で組織子アカウントの課金をOU単位で振り分けした
Organizations使っていて、OU単位での課金情報取ろうとすると
大概`じゃあCostCategolyを使って`みたいな話になるんですが`そうじゃねえんだよ`OUさえ分けてればアカウント単位での利用料金を
自動で振り分けしてレポートされるようにしたいんだよ
という思いで作ったスクリプトです。“`
#!/bin/cshset LASTMONTH=` date +%Y-%0m-01 -d ‘1 month ago’`
set THISMONTH=` date +%Y-%0m-01`
set REGION=us-east-1
set PROFILE=orgprofileecho TimePeriod : $LASTMONTH to $THISMONTH
echo Region : $REGION
echo PROFILE : $PROFILEaws ce get-cost-and-usage –profile ${PROFILE} –region ${REGION} –time-period Start=${LASTMONTH},End=${THISMO
aws cli で組織子アカウントのサービス単位課金を抽出したい
ちょいコツがいる処理だったので備忘も兼ねて投稿
組織アカウントのプロファイルでサービス単位の課金情報は
こんな風にSERVICE の DIMENSIONで取れますが
“`
aws ce get-cost-and-usage –profile ${PROFILE} –region ${REGION} –time-period Start=${LASTMONTH},End=${THISMONTH}\
–granularity MONTHLY –metrics UnblendedCost –group-by Type=DIMENSION,Key=SERVICE \
“`子アカウント(LINKED ACCOUNT)単位での情報を取ろうとすると、既にDIMENSIONが
使われていて指定できない。
でも子アカウント毎に都度profile作るのは面倒だしメンテもしたくない。
サポートに訊いたら`–filter使えや`って話だったので早速設定。
https://docs.aws.amazon.com/ja_jp/cli/latest/reference/ce/get-c
CloudWAN④セグメント二つ、VPCアタッチメントによるマルチリージョン構成
前回はCloudWANのセグメント作成、VPCアタッチメントの作成を行いました。
今回はさらにセグメントを一つ追加し、追加セグメントに所属させるVPCアタッチメントを作成していきます。
前回のおさらい的な内容となるため、不要な方はこの記事を飛ばして次回の記事（セグメント間の通信）に移動していただくのが良いかと思います。# 前回の構成確認
前回の設定内容を確認します。
前回は、CloudWANにCOMMONセグメントを作成し、COMMONセグメントに所属するVPCアタッチメントを追加しました。
今回はここにCOMMON2セグメントを追加し、COMMON2セグメントに所属させるVPCアタッチメントを作成します。今回の設定内容を図にしたものがこちらです。前回同様、VPCやEC2の構築手順は割愛し、CloudWANの手順のみ記載します。
かなり
CloudWAN③セグメント一つ、VPCアタッチメントによるマルチリージョン構成の構築
前回はCloudWANの初期設定を行いました。
今回からは、CloudWANの具体的な構築を行っていきます。
CloudWANのコンソールは少し癖があり、TransitGatewayの構築とは異なる部分が多くあります。
この記事で構築の際の注意点などをお伝えしていこうと思います。ぜひ最後までお付き合いください。# 設定内容
今回の設定内容を構成図で確認します。
前回作成した「COMMON」というセグメントに、東京リージョン・パリリージョンのVPCを接続します。
東京リージョンのEC2から、パリリージョンのEC2へpingが通ることを確認します。
# 構築の流れ
先ほどの構成図を少し詳細にした図がこちらです。まずはグローバルネットワークの設定を行います。
グローバルネットワークの名前・説明・タグを入力し、「次へ」を押下します。
 タブから [クラスタ] (Cluster) | [サービス] (
AWSのアクセスキーからどのAWSアカウント、どのIAMユーザーかを確認する
CircleCIでセキュリティインシデントが発生してしまったようです。[^1]
[^1]: https://circleci.com/ja/blog/jan-4-2023-incident-report/
漏洩した恐れのあるAWSのアクセスキーのリストがAWSから送られてきました。
対処としてはキーをローテートすればよいそうです。ただAWSアカウント、IAMユーザーともにそれなりの数があり、対象のキーをすべてマネジメントコンソールから手作業で確認するのは骨が折れそうです。調べたところAWS CLIで確認できるそうで便利でした。
確認は二段階で、1. AWSアカウントの特定
1. IAMユーザーの特定になります。AWSアカウントはAWS CLIで該当のAWSアカウントの権限が無くても確認できるようです。JWTのようにアクセスキー内にアカウント情報が入っているのかもしれません。
## アクセスキーからAWSアカウントを調べる
`sts get-access-key-info` を使い、`AKIAxxxxxxxxxxxxxx` というキーに付いて調べるときには下記のように
FinOpsとは クラウド利用のコスト最適化を本質的に考えるために知っておくべきワード
# はじめに
FinOpsという言葉をご存知でしょうか？CCoEとして2023年のクラウド利用のコスト最適化について調べていたところ、FinOpsというワードに辿り着きました。
参考までにGoogle Trendsで「すべての国」を対象に、2018年から2022年までの期間で検索した結果が以下の通りです。
後述するFinOps Foundationが設立されたのが2019年で、2022年以降に動向の変化が見られました。
対象を日本で絞ると動向の変化はなく、日本ではまだあまり注目されていないように見えますが、FinOpsについて興味を持ったのでまとめました。組織でクラウド利用を見直したいという方々の参考になれば幸いです。
## FinOpsの必要性
Flexera社によって公開されてい
Goを使ってDynamoDBに一括書き込み
aws-sdk-goを使ってDynamoDBを操作するメモです。
こちらの[リンク](https://docs.aws.amazon.com/ja_jp/code-library/latest/ug/go_2_dynamodb_code_examples.html)を見ながら基本的なCRUDは一通りできたのですが、一括処理はうまくできませんでした。
一括書き込みの箇所についてデモを作成しようと思います。### 環境
`go version 1.17.2``aws-sdk-go v1.44.180`
### 前提
DynamoDBにユーザ情報を一括登録する想定です。
ユーザ情報はHTTPリクエストボディから受け取ります。
Lambda上で受け取ったデータを構造体に変換し、DynamoDBに書き込みます。### 構造体を定義
ユーザ情報を表現する構造体を定義します。“`go:main.go
type User struct {
ID string `json:”id”`
Name string `json:”name”`
}
“`### リクエストボディか
