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

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

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年までの期間で検索した結果が以下の通りです。

![スクリーンショット 2023-01-18 21.48.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221759/a55bbc2d-c442-481f-c7e9-30c5233ddabe.png)

後述する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”`
}
“`

### リクエストボディか

元記事を表示

ガロア群を計算するアプリケーション

# 初めに?

SageMath を使ってガロア群を計算するアプリケーションを作りました。?

– SageMath とは

https://www.sagemath.org/

– リポジトリはこちら

https://github.com/oiz-y/sage-lambda-container-app

# URL?

### https://www.galoisapp.com/

– 例

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621414/619ae679-2bf5-745e-84dc-034c6de5659d.png)

# 開発?

バックエンドは AWS Lambda というサーバーレスサービスを使っています。

– AWS Lambda とは

https://aws.amazon.com/jp/lambda/

– バックエンドのリポジトリはこちら

https://github.com/oiz-y/sage-lambda-container-backend

元記事を表示

【AWS】API Gateway+Lambdaの構成にX-Rayを有効化

# はじめに
DVA試験対策でAPI Gateway+Lambda構成にX-Rayを有効化して挙動を確認しました。
本記事では、この構成にX-Rayを有効化する方法を記載します。

# X-Rayとは
API GatewayやLambda等、各サービスの処理時間を記録するサービス
 処理時間をコンソール上で可視化
 どの処理でボトルネックが発生しているかを特定できる
 Lambdaでは、X-Ray SDKを使用することで、Lambda内のAWSサービスへのリクエスト処理時間も記録

# 構成

API Gateway+Lambda+DynamoDBの構成です。
Lambdaでは、DynamoDBテーブルにクエリし、返ってきたデータを返します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2485934/8f6df9f8-3165-8462-8c46-087649d37b8e.png)

・使用言語
Python(Lambdaでは3.9をランタイム環境として使用)

・開発環境
 OS

元記事を表示

S3のバケットポリシーで特定のユーザーのみ許可する方法

あまり記事を見かけなかったので、メモ程度に残しておこうと思います
## ①ブロックパブリックアクセスをオフにする
ブロックパブリックアクセスがオンになっていると、バケットポリシーが無視されます
## ②バケットポリシーを定義
以下を読み替えながらコピペしてみてください
##### ※ここでバケットポリシーを間違えると、権限エラーでバケットポリシーを編集できなくなるので注意が必要です!!!
“`
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “AllowUser”,
“Effect”: “Deny”,
“Principal”: “*”,
“Action”: “s3:*”,
“Resource”: “arn:aws:s3:::BUCKET_NAME/*”,
“Condition”: {
“ArnNotEquals”: {

元記事を表示

node.jsのアプリケーションをAWS ElasticBeanstalkにデプロイしてみる。

node.jsの非常に簡素なアプリケーションをAWS ElasticBeanstalkを用いて公開するやり方をまとめていく。
これは下の動画に従ったものであるので下の動画を見てもいい。また、公式のドキュメントにもnode.jsとExpressを用いたアプリケーションの公開の仕方があった。この記事では最低限のことしか書かないので実際に実用性のあるアプリケーションを公開する際には公式ドキュメントを参照してほしい。

https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/create_deploy_nodejs_express.html

まず、作業に移る前に必要なことがいくつかある。

Gitへの登録とAWSアカウントの作成である。
こちらは行っていることを前提に進めていく、難しい作業ではないので各自調べて行ってほしい。

そして、ElasticBeansをコマンド上で操作するためにEB CLIのダウンロードをする必要がある。

ht

元記事を表示

【AWS】RDS MySQL の作成(Part2)

# ~ はじめに ~
今回は、作成した[Webサーバー](https://qiita.com/ponponpoko/items/e5553ef3ace2e4cb5633)のデータをDBで管理するためRDSを作成し、
Webサーバーからアクセスできるようにします。

今回の記事は、長くなりそうなため3パートに分けて書く。
– [**Part1:RDS作成前の事前準備**](https://qiita.com/ponponpoko/items/4b57170e5617f3259300)
– [**Part2:RDS MySQLの作成**](https://qiita.com/ponponpoko/items/2187f2eef73135a18a59)
– [**Part3:WebサーバーからRDS MySQLに接続**]()

※ RDSで使用するDBエンジンは、[Amazon RDS for MySQL](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_MySQL.ht

[AWS][CloudWatch] collectd を使用してカスタムメトリクスを取得する

EBS のストレージ空き容量などは、デフォルトでは CloudWatch のメトリクスとして確認することができません。
[collectd](https://collectd.org/) を使用することで、デフォルトで取得できていないメトリクスをカスタムメトリクスとして送信できるようになります。

以下、Amazon Linux2 への設定手順のメモとなります。

# collectd のインストール

amazon-linux-extras を使用してインストール可能です。
デフォルト設定の状態で disk_used_percent と mem_used_percent が取得できるようになるので、このままでも良いでしょう。
他のメトリクスも取得したい場合は、ドキュメント参照してください。
[collectd を使用してカスタムメトリクスを取得する](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-custom-metrics-collectd.html)

【AWS IAM】特定のホストゾーンのみ閲覧できるポリシー設定

株式会社ビヨンド 大阪オフィスのラーメン王、ヒデです。

『このホストゾーンのみ閲覧できるユーザーを作りたいけど….. これってマジでどうやって作んのよ…….』

上記のことってありませんでしょうか?別会社さんに特定ホストゾーンの確認だけしてもらいたいけど、閲覧のみできる権限調整がわからないなどあると思います。

AWS のリファレンスや他の記事などの情報を元に調べましたが、かなり時間が掛かりました。。。しかし これを見れば、簡単に権限の設定ができますので、一緒に見ていきましょう!

▼ ブログ記事の詳細は コチラ から ▼

https://beyondjapan.com/blog/2022/12/create-specific-hostzone-read-policy

***

■ 株式会社ビヨンド

・コーポレートサイト:https://beyondjapan.com​​​
・採用サイト:https://recruit.beyondjapan.com
・Youtube(びよまるチャンネル):https://www.youtube.com/

aws-vaultの備忘録

aws-vaultについての備忘録です。

## インストール
“`php
brew install aws-vault
“`

## 認証情報登録
“`php
aws-vault add xxxxx
Enter Access Key ID: XXXXXXXXXXX
Enter Secret Access Key: XXXXXXXXXXX
“`

## 初期設定
追加された[profile xxxxx]の下にMFAなどの情報を設定する。
“`php:~/.aws/config
[profile xxxxx]
region=ap-northeast-1
output=json
mfa_serial=arn:aws:iam::XXXXXXXXXXXX:mfa/xxxxxxxxxx
“`

## 接続方法
“`php
aws-vault exec xxxxx
# 上記のコマンドを実行すると、aws-vaultで登録したキーチェーンのパスワードが求められる
# その後、MFAを入力する
Enter MFA code for arn:aws:iam::XXXXXXXXXXXX:mf

CloudFrontを使ってTerraMap APIにリクエストする

## この記事を作成した背景
外部APIにリクエストする際、APIキーをセットするタイプのAPIだとJavaScriptから直接リクエストしたときにAPIキーが見えてしまうためセキュアではなく、無駄なリクエストを消費する懸念があります。
サーバーサイドプログラムを実装し、APIキーをセットしてプロキシサーバーとして利用することもプログラム実装や環境構築の手間がかかります。
地図システム開発支援Web APIであるTerraMap APIはAPIキーをセットするタイプのAPIであり、サーバーサイドプログラムの実装や自前でインフラ構築することなく、容易にTerraMap APIにリクエストする方法を考えてみました。

## 概要説明
今回は[CloudFront](https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)をリバースプロキシとして利用して[TerraMap API](https://www.mapmarketing.co.jp/terramap-api

DatabricksにおけるクロスアカウントS3アクセス(実践編)

こちらを昨年書きましたが、より詳細な手順にまとめます。

https://qiita.com/taka_yayoi/items/a534bdcdfc37e1142c93

# 全体像

以下では、AWSアカウントIDが``であるDatabricksをデプロイしたAWSアカウントAと、AWSアカウントIDが``であるアクセス先のS3バケットがあるAWSアカウントBを考えます。

![Screenshot 2023-01-19 at 15.09.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/140ac95c-a1b3-1da8-b707-ddad1a5612f7.png)

この作業では、以下のロールARN、インスタンスプロファイルのARNを使用します。

– `arn:aws:iam:::role/deployment-acct-cross-account-s3

(AWS) タグ付けできるリソース一覧みたいな資料

なかなかタグ付けできるAWSリソースが網羅されている資料がないが、
こちらのドキュメントにある程度網羅されている気がする。
(Resource Groups & Tag Editorの仕様が出ているドキュメントなので、
結局、タグ付けできるリソース全てがまとまっているのではないかと、あくまで予想。)
https://docs.aws.amazon.com/ja_jp/ARG/latest/userguide/supported-resources.html

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80683/32126b4e-7260-4e07-d7b7-9caec2c4f525.png)

【AWS】自動デプロイ後にアクセスしたら502 Bad Gateway

## 結論
deploy.rbに記載ミスがあった。
なんとこれだけです。

## 経緯
AWSへのデプロイに初挑戦。
手動でのデプロイ時点では上手く行っていたのに自動デプロイを試みると502 Bad Gatewayとエラー。
なんじゃこりゃ、、、?

## 502 Bad Gateway とは
とりあえずググってみた。

“`
502 Bad Gatewayとは、ウェブサイトのサーバーの通信状態に問題があることを示すエラーメッセージです。
以下のようなエラー画像が表示されます。
“`
参考:https://blog.hubspot.jp/502-bad-gateway

通信状態? 
AWS側の不具合やらこっちのWifiが原因ってことかな?
、、、ってそんなわけあるかーーー!

## 原因
以下の記事を参考に原因究明。
https://qiita.com/kana_web/items/638a5d605870558879a4

こちらの記事から、ファイルとディレクトリの位置関係を洗い出すことに。

### currentディレクトリに移動できるか確認してみる
“` :ターミ

猫先生のツイートを取得してLINEに通知するテンション爆上げなツールを作ってみた

# 猫先生とは?
「Re:ゼロから始める異世界生活」の作者:長月達平先生の愛称です。
https://ja.wikipedia.org/wiki/Re:%E3%82%BC%E3%83%AD%E3%81%8B%E3%82%89%E5%A7%8B%E3%82%81%E3%82%8B%E7%95%B0%E4%B8%96%E7%95%8C%E7%94%9F%E6%B4%BB

# このツールの目的
##### 目的は「最新話がアップされたことを知る」
[小説家になろう](https://syosetu.com/) というサイトで絶賛連載中のRe:ゼロですが、
最新話の更新日については特に決まっておらず、完全な不定期、神出鬼没です。
ただ、「最新話書いたから○○時にアップするね」的なことをご自身のTwitterで呟かれていることを知り、
じゃあそのツイート取得して通知するようにすれば、いちいちサイト巡回しなくてもいんじゃね?
と考えたことがきっかけでした。。(サイト巡回してた時期がありました・・・

## 処理の流れ
やっていることはシンプルで、

EventBridgeで毎朝2:00

(AWS) NAT Gatewayの監視方法について

NATGWの監視方法について

* NATGWのモニタリング項目
* https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway-cloudwatch.html
* **BytesOutToSource** の値(単位: Byte)が **BytesInFromDestination** の値より少ない場合、NAT ゲートウェイの処理中、またはトラフィックが NAT ゲートウェイによりアクティブにブロックされている間に、データ損失が発生する可能性があり
* [Metric Math を使用する](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/using-metric-math.html)
* [メトリクスの数式に基づく CloudWatch アラームの作成 ](https://docs.aws.amazon.com/ja_jp/AmazonCl

RDS のバックアップはリージョンを超える

Amazon RDS のクロスリージョンバックアップを試していきたいと思います。
なので、ゴールとしては、バックアップが別のリージョンに作成されることとします。

具体的には、東京リージョンにある Amazon RDSのスナップショットが、大阪のリージョンに作成されたら、今回は検証が成功したということにします。

▼ ブログ記事の詳細は コチラ から ▼

https://beyondjapan.com/blog/2023/01/rds_cross_region_replication

***

■ 株式会社ビヨンド

・コーポレートサイト:https://beyondjapan.com​​​
・採用サイト:https://recruit.beyondjapan.com
・Youtube(びよまるチャンネル):https://www.youtube.com/@beyomaruch
・Twitter:https://twitter.com/beyondjapaninfo
・Instagram:https://www.instagram.com/beyond

AWS Athena 公式ページ

AWS Athena 公式ページを備忘メモ。
https://aws.amazon.com/jp/athena/

ユーザーズガイド
https://docs.aws.amazon.com/athena/latest/ug/what-is.html

【AWS】RDS作成前の事前準備(Part1)

# ~ はじめに ~
今回は、作成した[Webサーバー](https://qiita.com/ponponpoko/items/e5553ef3ace2e4cb5633)のデータをDBで管理するためRDSを作成し、
Webサーバーからアクセスできるようにします。

今回の記事は、長くなりそうなため3パートに分けて書く。
– [**Part1:RDS作成前の事前準備**](https://qiita.com/ponponpoko/items/4b57170e5617f3259300)
– [**Part2:RDS MySQLの作成**](https://qiita.com/ponponpoko/items/2187f2eef73135a18a59)
– [**Part3:WebサーバーからRDS MySQLに接続**]()

※ RDSで使用するDBエンジンは、[Amazon RDS for MySQL](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_MySQL.ht