AWS Control Towerでマルチアカウント管理環境を構築してみた


### AWS Control Towerでマルチアカウント管理環境を構築してみました :tada:

[AWS Control Tower](https://aws.amazon.com/controltower)とは、セキュアなAWSマルチアカウント管理環境を構築できるサービスです。[AWS Organizations](https://aws.amazon.com/organizations)や[AWS SSO](https://aws.amazon.com/single-sign-on)も自動で設定されるので、手動でのアカウント作成に比べて手軽に設定可能です。以前会社で導入して便利だったので、今回は個人アカウントにも導入してみました。個人アカウントでは追加でproduction・staging・develop・test環境を構築し管理しています :thumbsup:

詳細として下記について説明します。

–

【AWS CDK v2】VPC LambdaからAWS Batchにジョブを投入する構成を作ってみた

# はじめに
AWS Batchにジョブを投入する方法はいくつかありますが、今回はVPC LambdaからAWS Batchにジョブを投入する構成をAWS CDKで作ってみました。

# 構成図
VPC LambdaからAWS Batchにジョブ投入のリクエストを送る流れを示した図です。
VPC Lambdaは実際にはVPCの外にあり、ENI、VPC Endpointを経由してAWS Batchにジョブ投入のリクエストを送信することになります。


# 動作環境
“`bash
$ cdk –version
2.30.0 (build 1529743)
$ node –version
v14.19.3
“`

# やってみた
前提として、VPC、サブネットはすでに作成済であるとします。

## AWS Batchを作る

まず、次のような

【Athena】Prepared Statementを試してみた

# 背景・目的
[こちら](https://aws.amazon.com/jp/about-aws/whats-new/2022/07/amazon-athena-enhances-console-api-parameterized-queries/)の記事を読んで、Athenaでパラメータ化されたクエリが強化されたということを知ったので、試してみたいと思います。

なお、自分は知りませんでしたが、パラメータ化されたクエリ自体は以前から利用可能で、今回は強化されたとのことでした。
今回のアップデートによりは、コンソールからパラメータ化されたクエリが利用できるようになったようです。

# まとめ
* AthenaでもPrepared Statementが使える。
* マネコン、API、CLIから利用可能。

# 概要
## パラメータ化されたクエリ
実行時に、異なるパラメータ値で同じクエリを再利用することで、再利用性、シンプル化、SQLインジェクション攻撃を防ぐことができます。

## 考慮事項と制限事項
* Athenaエンジンバージョン2のみ
* SELECT、INSERT INTO

Resolver のクエリのログ記録を他アカウントのS3バケットに保存する方法

やりたいこと

Route53 Resolverのクエリのログ記録先を他アカウントのS3バケットに保存する

参考サイト

バケットポリシー書いてるサイト

ポリシーのリージョン指定方法

S3バケットポリシー

“`

{
“Version”: “2012-10-17”,
“Id”: “CrossAccountAccess”,
“Statement”: [
{
“Ef

Athenaのunloadが業務で必要だったので試してみた

## 結論
クエリを実行した結果、s3に想定したファイルが出力がされた
また、CLIからも実行可能

## 実行
以下のクエリを記載しathenaのコンソール上から実行
“`
UNLOAD (SELECT
hoge,
fuga,
piyo
FROM
db.table) TO ‘s3://xxxxx/xxx/’
WITH (format = ‘AVRO’)
“`
→指定のS3にavro形式でファイルが出力された

AWS CLIを利用してクエリを出力することが可能なのか？
以下のCLIを実行
“`
aws athena start-query-execution \
–query-string　”UNLOAD (SELECT hoge,　fuga,　piyo　FROM　db.table) TO ‘s3://xxxxx/xxx/’ WITH (format = ‘AVRO’)”
“`
結果を確認
“`
aws athena get-query-execution –query-execution-id xxxxxxxx | jq ‘.QueryExec

[AWS] CloudFront に適用されてるセキュリティポリシーをリストアップしたい

AWSダッシュボードで表示されたり検索できればいいんだけど、できないので
（表示可能な列にセキュリティポリシーを表示されればよかったんですが…

ってことで、aws-cli で出力して、jq で整形しましょうかね

“`bash
$ aws cloudfront list-distributions –max-items 100 \
| jq -r ‘.DistributionList.Items[]|[.Id,.ViewerCertificate.SSLSupportMethod,.ViewerCertificate.CloudFrontDefaultCertificate,.ViewerCertificate.MinimumProtocolVersion]|@csv’

“EXXXXXX

AWSの無料利用枠超過はどうやって判断するの？

# 概要
久々の投稿になりますが、AWSが提供している無料利用枠を活用してAWSの学習を行っています。
UdemyやAWSが提供しているハンズオンを活用して、AWSのサービスを使っている時に「無料枠」に収まっているのか気になりました。
というか、このまま放っておいて、課金破産とか想像すると夜も眠れません。なので、確認方法を調べてみました。既に誰かが調べているかもしれませんが、備忘として残しておきます。

# 前提・注意事項
・2022年7月時点の情報です。画面イメージは頻繁は時期によって変化するはずです
・他に適切な方法もあるかもしれません。あくまでも個人的な調査結果、判断なので、もし間違ってたり、他に簡単な方法等あればコメント頂けると泣いて喜びます私もアップデート事項等あればこのページを更新します。
・個人情報に関する項目についてはマスクしています

# 調査内容
## 今どのくらい使っているのか確認する
アカウント名を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/367069

「OCI Functions」と「 AWS Lambda」の比較

# 全体な比較

||OCI Functions|AWS Lambda|
|–|–|–|
|リリース|2019年7月|2014年11月|
|ベース|[Fn Project](https://fnproject.io/)|N/A|
|サポート言語|✔ Java
✔ Python
✔ Ruby
✔ Go
✔ Node.js
✔ C# (.NET)
[ドキュメント](https://docs.oracle.com/ja-jp/iaas/Content/Functions/Tasks/languagessupportedbyfunctions.htm)をご参照ください。|✔ [Java](http://docs.aws.amazon.com/lambda/latest/dg/java-lambda.html)
✔ [Python](http://docs.aws.amazon.com/lambda/latest/dg/python-lambda.html)
✔ [Ruby](https://docs.aws.amazon.com/lamb

Cloudwatchでインスタンスを監視をする

# 概要
CloudwatchAgentを用いたEC2インスタンスの監視をやります。

## エンドポイントを作る
プライベートサブネットからCloudWatch Agentを利用する場合は下記のエンドポイントを作成する必要があります。
VPCからエンドポイントを作成してください。

“`
com.amazonaws.ap-northeast-1.monitoring
com.amazonaws.ap-northeast-1.ec2
com.amazonaws.ap-northeast-1.logs
“`

## IAMポリシーを作る
下記の権限を持つポリシーを作成し、CloudwatchAgentを入れるEC2にアタッチします。
– CloudWatchAgentServerPolicy

エラーに苦しんだら下記を当ててください。正直権限的にやりすぎなので切り分けなどの目的で行うことを推奨します。
– AmazonEC2ReadOnlyAccess
– CloudWatchFullAccess
– AmazonSSMFullAccess

## セキュリティグループに穴をあける

[AWS]オンプレミスからSite-to-Site VPNを利用してS3にアクセスする

オンプレミスからS3にアクセスするには色々な方法がありますが、今回は 「AWS Site-to-Site VPN」を使い、オンプレミスとAWS間をVPN接続し、オンプレミスからS3にアクセスするパターンをご紹介します。

## オンプレミスとAWSの接続方法
専用線、またはVPNを利用した接続は以下の３つがあります。
・　Direct Connect
・　Client VPN
・　Site-to-Site VPN

「Direct Connect」は専用線を利用した接続になるので最もセキュアかつ安定した通信が行えますが、導入は時間がかかり費用も高額になります。
「Client VPN」、「Site-to-Site VPN」はインターネット回線を利用できるので比較的安価に利用出来ますが、通信の安定性では「Direct Connect」よりは劣ります。
今回はオンプレとAWSを常時接続するイメージで「　Site-to-Site VPN」を利用します。

## Site-to-Site VPNの概要
・　VPCに関連付けされたトランジットゲートウェイ、または仮想プライベートゲートウェイを経由

AWS認定高度なネットワーキング専門知識勉強メモ

はじめに

[AWS認定高度なネットワーキング-専門知識](https://aws.amazon.com/jp/certification/certified-advanced-networking-specialty/)受験のために整理した勉強メモです。

受験当時の私の知識がベースになっているため、網羅的な内容になっていないことをはじめにお断りしておきます。

– 参考文献
[要点整理から攻略する『AWS認定 高度なネットワーキング-専門知識』](https://www.amazon.co.jp/%E8%A6%81%E7%82%B9%E6%95%B4%E7%90%86%E3%81%8B%E3%82%89%E6%94%BB%E7%95%A5%E3%81%99%E3%82%8B%E3%80%8EAWS%E8%AA%8D%E5%AE%9A-%E9%AB%98%E5%BA%A6%E3%81%AA%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AD%E3%83%B3%E3%82%B0-%E5%B0%82%E9%96%80%E7%9F%A

【AWS CDK Workshop】CDK PipelinesのセクションをCodeCommitではなくGitHubでやってみた

# はじめに
AWS CDKの勉強のために[CDK Workshop](https://cdkworkshop.com/)をやりました。このWorkshopの[CDK Pipelinesのセクション](https://cdkworkshop.com/20-typescript/70-advanced-topics/200-pipelines.html)ではCodeCommitを使っています。ただ、実際の業務ではGitHubを使うことが多いので、勉強がてらGitHubに変更してやってみました。

# [CDK Pipelinesのセクション](https://cdkworkshop.com/20-typescript/70-advanced-topics/200-pipelines.html)をCodeCommitではなくGitHubでやる方法
Workshopのセクション毎に手順を記載します。

## [GETTING STARTED WITH PIPELINES](https://cdkworkshop.com/20-typescript/70-advanced-topics/200

AWS Black Belt Online Seminarで学んだAWS Configをまとめる

会社でAWS Configについて理解が浅いため、一度動画を見て学び自分用にまとめることとした。
視聴した動画は[こちら](https://www.youtube.com/watch?v=vnqX0gMj6jw)

## AWS Configとは
構成管理にまつわる課題として、実設定とドキュメントとの整合性の乖離や管理コスト、コンプライアンス準拠への負担が挙げられる。これらの課題をクリアして構成管理を楽にしましょうという機能がAWS Config。

概要は次の通り。
* AWSリソースのインベントリ管理、構成変更のためのフルマネージド型サービス
* AWSリソース構成変更をロギング（保存期間はデフォルト7年間）
* 履歴も保存
* 構成情報を定期的にスナップショットしてS3に保存
* SNSを用いた通知も可能
* 構成変更の追跡、セキュリティ分析、トラブルシューティング、コンプライアンス準拠を容易にできる

## AWS Configの各機能の役割
保管する3つの処理として、次のものがある。
* ストリーム
* リソースが作成/変更/削除されるたびに作成
* 構成スト

Codebuild での Docker build 時 に ssh キーを使う方法

# はじめに
ハマったので備忘録として。

# 手順
## 1. Systems Manager の Parameter Store で設定する

こんな感じで。
Type は String でもよいけど、セキュアなデータなので個人的にには SecureString がおすすめ。

## 2. buildspec.yml で使うように記述する

“`yaml
version: 0.2

env:
parameter-store:
SECRETS_GITHUB: github-deploy-key
variables:
DOCKER_BUILDKIT: “1”

phases:
pre_build:
commands:

Terraform 入門から精通まで（コマンド整理）

## 概要
今回、Terraformによく使われたコマンドをご紹介させていただきます。

## コマンドリスト
– terraform init
– terraform fmt
– terraform plan
– terraform apply
– terraform state list
– terraform state show
– terraform output
– terraform refresh
– terraform destroy

## 参照DOC
https://registry.terraform.io/providers/hashicorp/aws/latest/docs

## 前提条件
– リソースを作成するためのAWSの権限設定をもつiamユーザーのアクセスキー(access_key,secret_key)
## 説明

### terraform init
ワークスペースを初期化するコマンド。
Terraform を実行するためには、1番初めに terraform init でワークスペースを初期化することが必須となっています。terraform

無料枠で使っていたはずのAWSから$200の請求が届いたお話

## はじめに

このようなタイトルになっていますが、100%自分のミスで$200の請求が来ました。

自分はAWSを勉強するため、12ヶ月間の[AWS無料枠](https://aws.amazon.com/jp/free/?all-free-tier.sort-by=item.additionalFields.SortRank&all-free-tier.sort-order=asc&awsf.Free%20Tier%20Types=*all&awsf.Free%20Tier%20Categories=*all)というもの利用してアカウントを作成しました。

当時の自分は注意事項等をほとんど読まなかったので「**これでAWSは1年間使い放題や。たくさん勉強するで〜**」意気込んでいました。

AWSを利用し始めてから3ヶ月後に請求の通知が届いていたので内容を確認すると「**$200**」との記載が。

勉強利用でしか使っていなかったと思っていたので、通知が届いた瞬間は震え上がりました。

結果的には全額は支払わずに済んだのですが、このような過ちをAWS初心者の人が起こさないため(高額

Direct Connect GatewayでVPC間が疎通してしまうことがある

# 概要

AWSの同一Direct Connect Gateway(以下DXGW)に接続したVPC間で通信が可能になっていました。以下、結論です。

– ドキュメントを読むと「単一の Direct Connect ゲートウェイにアタッチされた仮想インターフェイス間の直接的な通信」はサポートされていない、となっている
– 仮想プライベートゲートウェイの関連付け — https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/virtualgateways.html
– 実は、「スーパーネットが、同じ Direct Connect ゲートウェイおよび同じ仮想インターフェイス上に関連付けられている接続された仮想プライベートゲートウェイ（VGW）を持つ 2 つ以上の VPC にわたってアドバタイズされる場合です。この場合、VPC は Direct Connect エンドポイントを介して互いに通信できます。」という仕様により通信できてしまうようだ
– Direct Connect ゲートウェイ — htt

Cognitoの USER_SRP_AUTHフロー や パスワード付きカスタム認証フローで必要な「SRP_A」を計算する (js, ts限定)

## SRP_A ってなに？
Cognitoに用意されている認証フローのうち、下記で必要になるパラメータだよ。
* USER_SRP_AUTHフロー
* パスワード検証付きカスタム認証フロー

https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html

上記フローでは、広く標準化された鍵交換プロトコルである **Secure Remote Password プロトコル (SRP)** を使っていて、 SRP_A はそれに関連する **「大きな整数」で生成された値** だよ。

## Cognito使ったことあるけどSRP_Aなんて聞いたことない。これっていつ使うの？
Cognitoが用意してくれるログインエンドポイント＋トークンエンドポイントを使う構成や、Amplify UI にお任せする場合には、あまり登場しない部分かもしれないね。

でも、自分で Cognito の各種 API をコールしていく実装なら、必要にな

Rustのlambda_http辛すぎなのでaxumしてみた

# 目的
AWS LambdaでAPIっぽいことをするには[lambda_http](https://crates.io/crates/lambda_http)を使うことになるんですが、HTTPの低レイヤーを相手にすることが多くて辛いです。
何かいいものが無いかと調べていたら、数日前に[axum-aws-lambda](https://crates.io/crates/axum-aws-lambda)というものが出来ていたのでこれを使ってみました(この記事を書いた日からだと27日前でした)。

# コード
## lambda_httpだけでやってみる。
“`rust:Cargo.toml
[package]
name = “web”
version = “0.1.0”
edition = “2021”

[dependencies]
lambda_http = “0.5.2”
serde_json = “1”
tokio = { version = “1”, features = [“full”] }

“`

“`rust:main.rs
use lambda_http::{

Swagger、結局どう使うの？ を整理してみた

## 概要

Swaggerとは、REST APIの設計を楽にするよう作られたツールです。

とはいえ、作成したAPIサーバに対し、どのように使用するのか・メリットは何か、がいまいち整理できていなかったので、今更ながら実際に使用してみることで整理をしてみました。

API開発者目線の使用感を記載するため、Swagger部分だけでなく、ソースコード開発からAPI公開までの工程について構築手順を記載していきます。

## 想定読者

* Swaggerの使い方の一例を知りたい方

## 目次
* 全体構成図
* 構築方法
* APIサーバ
* Swagger
* GitHub
* API Gatewayへインポート
* 所感
* まとめ

## 全体構成図

今回は以下を使用して構成しました。
* APIサーバは、spring bootで開発しビルドしたjarファイルをECS上でコンテナとして構築した。
* API Gatewayを用いてAPIを公開した。
* APIドキュメントの公開はGitHub Pagesを用いた。(GitHubと連携しAPIドキュメントの公開を可能に