AWS関連のことを調べてみた

CloudFormationでEC2を複数設置

EC2を複数台構築することなったので、CloudFromationを使って構築を進めていきたいと思います。

### AWS CloudFromationとは
AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、AWS およびサードパーティーのリソースをモデル化、プロビジョニング、管理することができます。
https://aws.amazon.com/jp/cloudformation/
とのことで、簡単に言うと「AWSのリソースをコードで作成・管理できるもの」といえると思います。
AWSのマネジメントコンソールからリソースの作成はできますが、すべてのリソースを削除したり、再作成するのは、大変です。なので、CloudFormation使ってリソースをコードで管理するのはとても便利です。

### 作成イメージ

TerraformでのECSのコンテナ定義の表記方法の違いの比較

# 概要
Amazon ECSをTerraformで構築する際にコンテナ定義の表記方法が公式ドキュメント[^1]に複数載っていたのですが、使い分けがよく分からなかったので調べてみました。例としてはECSを扱っていますが、TerraformでJSONを扱う時全般の話です。

# jsonencode関数を使用する場合
Terraformではjsonencodeという関数を使用すると、HCLの形式でJSONをインラインで定義することが可能です。以下は、jsonencode関数を使用してタスク定義を記述した例です。

“`tf
resource “aws_ecs_task_definition” “service” {
family = “service”
container_definitions = jsonencode([
{
name = “awesome-container”
image = “epic-image:latest”
cpu = 10
memory = 512

RDSの書き込み転送の使い所

## RDSの書き込み転送とは
簡単に言ってしまえば、リーダーインスタンスにきたクエリのうち対応している書き込み系のクエリをライターインスタンスに転送してくれる機能です。

詳細はドキュメントを参照してください。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding.html

## 使い所
結局、転送するだけでライターインスタンスで処理されるなら負荷の軽減にはならないし、あまり意味がない機能に見えますが、下記のような用途で使うと便利です。

* 普段は参照系のクエリしか使わないけど、たまに書き込み系のクエリも使いたい
* 書き込みの速度は気にしないけど、書き込み系と参照系のクエリを自動で適切なインスタンスに振り分けたい

## 実際に使っているケース
私の担当しているシステムで、ある日データベースのCPU使用率が異常に高い状態になりました。調べてみると処理の重たい参照系のクエリが phpMyAdmin から実行されていました。

AWS CLI と boto3 でできることの差分を確認してみる

# そもそものきっかけ

皆さん、AWS Bedrock には触っていますか？

Bedrock では、用意されている CLI が [bedrock](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/bedrock/index.html) と [bedrock-runtime](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/bedrock-runtime/index.html) の2つに分かれています。
後者 “-runtime” で用意されていたコマンドが、 [invoke-model](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/bedrock-runtime/invoke-model.html) 1つのみだった (2023年12月時点) のに気づいたことが、この記事を書くきっかけです。

# AWS CLI と

S3のオブジェクトに対してリファラー制限をかける

弊社営業から「該当のファイルを、管理画面からのみダウンロードできるようにして欲しい」との要望があったのでs3のバケットポリシー設定メモとして残します

詳しい要件を聞いてみると

– 弊社と契約しているクライアントさんがアクセスする管理画面上からのみファイルをダウンロードを許可して欲しい」
– 弊社と契約しているクライアントさん以外は見てほしくないと思ってはいるけど、ダウンロードした後にクライアントさんが他の企業に見せてもまぁしゃーない
– 上の理由から、最悪ネット上に流出しても会社的にそんなに困らない

という超ゆるゆる要件だったため、リファラー制限だけ入れておきますかという話でまとまった。（リファラーは簡単に偽装出来るのでセキュリティ的にはイマイチ。厳しい要件では絶対に利用しないで下さいね…）

## s3 のバケットポリシーサンプル

適宜変更して利用してください

“`json
{
“Version”: “2012-10-17”,
“Id”: “referer policy”,
“Statement”: [
{

ゾンビ化したS3バケットを復旧する

# はじめに
S3でバケットポリシーを使ったことがある方は、1回は以下のような光景を見たことがあるんじゃないでしょうか。

経験ある方は原因をご存じだと思いますが、これはバケットポリシーの設定ミスによって引き起こされる誰もアクセスできないS3バケットになります。
[この記事](https://dev.classmethod.jp/articles/delete-access-denied-bucket-policy/)だと、この状態のS3バケットを”ゾンビバケット”と呼んでいるようです。

今回はこのS3バケットを復旧させる手順を試してみました。

# 作業内容
## 前提
S3バケットポリシーには元々以下のポリシーが設定されていましたが、そこから間違ってCondition部分だけを削除してしまった、という想定とします。

“`
{
“

【画像付き】フラミンゴからベネチアンへの近道 AWS re:Invent

## 概要
AWS re:Invent2023に参加した際にフラミンゴからベネチアンへの近くをre:Invent玄人の方々に教えていただいたので共有します。省エネできるところは省エネしていきましょう！
なお、フラミンゴは10月中旬でも空きがあり、価格も比較的安いホテルでした。中庭で本物のフラミンゴを飼っています。（鳥インフルエンザにかかっていないときもあるようです。）

## re:Inventとは
re:Inventとは、AWSが主催する世界で最も大きなイベントです。
2023年は6つのホテル内で2000以上のセッションが行われました。

## フラミンゴからベネチアンへの標準ルート

Google Mapで調べると以下のルートが表示されます。

メインストリートを通るルートですが、信号や工事などで、Google Map以上の時間がかかって

AWS内にセキュアなリモートデスクトップ環境を作って自端末からVPNでつなぎたい

# はじめに
この記事はDevOps on AWS大全 実践編の一部です。
DevOps on AWS大全の一覧は[こちら](https://qiita.com/tech4anyone/items/c27e74f9ae569ced259f)。

この記事では開発環境のアーキテクチャを決める流れを解説しています。

具体的には以下流れで説明します。

– 解決したい課題の整理
– 今回使うAWSサービスの整理
– アーキテクチャの策定
– 策定したアーキテクチャで達成できたこと

AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。

# この記事を読んでほしい人
– DevOpsエンジニアがアーキテクチャを決めるときにどのような思考フローを踏んでいるか知りたい人
– セキュアな開発環境のアーキテクチャを知りたい人
– AWS Certified DevOps Engineer Professionalを目指している人

# 解決したい課題の整理
現在、解決したいと思っている課題は以下になります

DevOps on AWS大全 実践編

# はじめに
この記事ではDevOpsを切り口に実プロジェクトでどのようにアーキテクチャを策定していくかについて私がまとめている記事を目次形式でまとめます。

DevOpsで使う各サービスの超詳細解説は[こちら](https://qiita.com/tech4anyone/items/b06f88035d27c6ef13b2)にまとまっています。

# この記事を読んでほしい人
– AWSにおけるDevOpsを現場で採用したい人
– DevOpsの各サービスの説明ではなく各サービスをつなげたアーキテクチャの説明を知りたい人
– 私が書いている記事の前後性や一覧がわかりづらく困っている人

# DevOps on AWS実践編 目次
## 準備
1. AWS内にセキュアなリモートデスクトップ環境を作って自端末からVPNでつなぎたい
https://qiita.com/tech4anyone/items/6503fb9da262e8104435

継続執筆中

## CICDパイプライン

## モニタリング・ロギング

## 障害対応

## セキュリティ対策

LINEからのBedrockエージェント呼び出し①

Agents for Amazon Bedrockの振る舞いがなんとなく分かってきたのでLINEから呼び出してみます。まずは基本形として（？）LINEから自然言語で乗換検索を行えるようにします。

　


過去に作ったもの

AWS で気になること簡単なまとめ

まとめ中

AWS Azure 簡単な比較まとめ

比較

AWS 基礎的なことまとめ２

## 参考

AWS 基礎的なことまとめ１（作成中）

## 概要

## 参考

Amazon Connect 通話セッション数上限緩和申請とService Quotasでの確認

ジャーニーマン( @beajourneyman )です。

今回は「セゾン情報システムズ Advent Calendar 2023」のシーズン2の16日目の記事になります。シーズン2が立ち上がって後追いで追加エントリーしました。

# 今回のテーマ「Amazon Connect の通話セッション数上限緩和申請」
既存アカウントは、すでに適切な通話セッション数で運用されており、普段は実運用の中で、実際に利用されたセッション数をモニタリングしています。

これまで、既存アカウントで実運用中に拡張を行ってきましたが、今回は要件時点で必要な通話アカウントセッション数を見込んでいる状態で通話セッション数上限緩和を行ったので、申請と確認についてまとめます。

https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/amazon-connect-service-limits.html

ご注意：本エントリーの Amazon Connect のコンソールは基本的に「日本語」を選択しております。また、サポートケースを直接起票できない他社提供

S3 に新規バケットが作成されたら教えてほしい！ – AWS CloudTrail, Amazon CloudWatch による S3 バケットの構成管理 –

# はじめに

本記事は `プロもくチャット Adevent Calendar 2023` の 22 日目です！！

https://qiita.com/advent-calendar/2023/puromoku

# この記事のゴール
– `AWS S3` に新規バケットが作成された時、通知を受け取ることができるようになります。
– `AWS CloudTrail` により証跡情報を監視することができるようになります。
– `Amazon CloudWatch` でカスタムメトリクスを作成できるようになります。
– `Amazon CloudWatch Alerm` を作成できるようになります。

# 背景

AWS のリソースを扱うハンズオンを実施していると、いつの間にか S3 バケットが作成されていることがあり、後々「何のためのバケットなのかわからなくなる」という事態に直面しました。
これを回避するため、S3 バケットが新規作成されたら僕のメールアドレスに通知されるようにしたいと考えた次第です。
なお、通知を受け取るだけでは根本的な回避策にはならないため、今後実装を深掘りした

AWS Certified Advanced Networking – Specialty

## Site to Site VPN
– Site-to-Site VPN connection need **Public VIF**
– Acceleration is only supported for Site-to-Site VPN connections that are attached to a **Transit Gateway**
– Site-to-Site VPN cannot be modifed, **must be replaced**
– For dual-stack connectivity on the Site-to-Site VPN connection via a Transit Gateway, you **need to create two VPN connections**, one for the IPv4 stack and one for the IPv6 stack
– Site-to-Site VPN **does not** support jumbo frames

## Direct Connect
– Updati

1,800億フォロワーを分析するBitStarのインフラ構成

## はじめに
BitStarのCTOの山下です。
BitStarではYouTube, TikTok, Instagram, X (旧Twitter)等の各SNSプラットフォームのデータを構築しています。

YouTubeでは総登録者数230億人、チャンネル数300万件、動画8,000万件、コメント2億件からChatGPTや機械学習用いてデータ提供をしています。
同様にTikTok 670億・Instagram 800億・X (旧Twitter) 56億 計約1,800億フォロワー分のデータを収集し分析した情報を提供しています。

もちろん地球の人口は約80億人なので、地球人口ベースで1人が22フォローしている計算になります。
インターネット人口は約50億人ともいわれているので1人が36フォローしている計算にもなります。

そんな日々フォロワーが増加する世界を補足し続けているBitStarのインフラ構成を説明します。

## インフラ構成
### AWS構成概略
大前提BitStarではAWSを利用しています。
AWSでのインフラ構成図は下記の通りです。

![image.png](h

Terraformを利用する為の基本設定

# 目的
Udamy教材でTerraformの学習を始めたので、インプットの整理として記事を書きました。

## 教材

https://www.udemy.com/course/iac-with-terraform/

## main.tf
Terraformを書くために基本設定を<任意のファイル名>.tfファイルに記述する。
主に以下を記載していく。

●Terraformのバージョン指定
●デプロイ先のプラットフォーム指定
●外部定義するための変数指定（具体的な変数値はterraform.tfvarsで記述）

“`main.tf
#————————
# Terraform configuration
#————————
terraform {
#Terraformバージョンの指定
required_version = “バージョン”

#プロバイダの指定
required_providers {
aws = {
source = “hashicorp/aws”
versi

インフラエンジニアでなくても頭の片隅に置いておきたい、AWS CloudFrontの設定で要注意なこと

**この記事で伝えたいこと**

会員登録のあるサイトでは、CloudFrontのキャッシュポリシーは「Caching Disabled」にすること。さもないとユーザ間でセッション情報が共有されてしまう可能性がある。この問題が見つかった時に検索してもなかなか情報にたどり着かなかったので書き残しておきます。

※解決された方は筆者ではありません。（筆者はAWSについては全く詳しくないです）

# 経緯
Laravelによる新規ECサイト開発の中盤で発覚。テスト環境を複数人が操作していた時に、カートの中身がいつの間にか変わっている現象がたまに起こりました。カートの中身だけでなく、マイページで情報を参照したら他人のアカウントでいつの間にかログインしていることになっていました。どうやら複数人で同時にAuthを同じルートで参照することで後にアクセスした人がその前にアクセスした人のユーザ情報を参照してしまうようでした。

# 解決
結局は最初に書いたようにCloudFrontのキャッシュポリシーの初期設定が「Caching Disabled」になっていなかったことで意図せずユーザ情報を