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

Amazon Virtual Private Cloud Connectivity Options（VPCからVPCへの接続）を整理してみた

# 背景・目的
先日、[Amazon Virtual Private Cloud Connectivity Options（Customer NetworkからVPCへ）を整理してみた](https://qiita.com/zumax/items/f95729145d371f087cf0)で、Customer NetworkとVPC間の接続パターンを整理しました。

今回は、VPC間の接続パターンを整理します。

# まとめ
下記に接続オプションをまとめます。※1

※1 [Amazon VPC から Amazon VPC への接続オプション](https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html)をコピーしています。最新の情報はドキュメントをご確認ください。

| オプション | ユースケース|利点|制限事項|
|:–|:–|:–|:–|
|VPC ピアリング|2 つ

【AWS】S3バケットのファイル作成をトリガーにLambdaを実行する

# はじめに
AWSのS3バケットにファイルをアップロードすることをトリガーにしてLambda関数を実行する方法について勉強したので備忘録も兼ねて本記事にまとめています。本記事では、S3バケットとLambda関数の設定手順、およびトリガーの設定方法を記載する。

# 環境
python 3.12

# S3側の準備
Lambdaから指定するバケットを作成します。

2. Amazon S3 > バケット > バケットを作成 を選択。
2. 任意のバケット名を入力し、右下のバケットを作成をクリック。（本記事ではバケット名を`test-lambda-trigger1`とします。）


# Lambda側の準備

## 関数の作成
1. Lambda > 関数 > 関数の作成 から新規でLambdaを作成します。
2. 任意の関数名を入力し

Amazon Virtual Private Cloud Connectivity Options（Customer NetworkからVPCへ）を整理してみた

# 背景・目的
私は、普段、オンプレミスとAWS 間のネットワーク設計など触れる機会がなく、知識も乏しいので整理しようと思います。

# まとめ
下記に接続オプションをまとめます。※1

※1 [ネットワークから Amazon VPC への接続オプション](https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)をコピーしています。最新の情報はドキュメントをご確認ください。

| オプション | ユースケース | 利点 | 制限事項|
|:–|:–|:–|:–|
|AWS Site-to-Site VPN|インターネット経由で個々の VPC への AWS マネージド IPsec VPN 接続|既存の VPN 機器とプロセスの再利用

既存のインターネット接続の再利用

AWS マネージド高可用性 VPN サービス

静的ルートまたは動的ボー

AWSのログインをパスキーにしよう！

# AWSでパスキーを使ってログインができるようになりました！

この神アップデートでいままで面倒くさかったトークンを入力する作業が不要になりました！
地味に6桁の数字を入力するのが大変だった…

## やり方

1. IAMにアクセスして、ユーザーを選択します。　セキュリティ認証情報から MFA デバイスの割り当てを選択します。

2. 一番上のパスキーまたはセキュリティキーを選択します。

3. するとWindows Helloが立ち上がるので好きな方法で認証します。
![MakePasskey

AWS EKSにNginxを建てよう ~ロードバランサーを添えて~

# 前提条件　

– EKSクラスターを作成している
– kubectl がAWS EKSクラスターに接続されている

まだしていない人は以下の記事を参照してください。

https://qiita.com/Takkesan/items/83ed99a36bca5b105d97

# 本編

## 1. Nginxのデプロイファイルを作成する

以下のようなファイルを作成します。

“`yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
purpose: serve-web
annotations:
description: Deployment for the nginx web server
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
name: nginx-p

コマンドでAWS EKS のクラスターを作ろう

# 前提条件

– AWSアカウント
– AWS CLI
– kubectl
– eksctl

# 本編

::: note warn
この記事では料金が発生するので使い終わったらクラスターを削除してください。
その方法を最後に記載しています。
:::

## クラスターを作ってみよう

“`Bash
eksctl create cluster –name 好きな名前 –nodes-min=インスタンスの数 –region 好きなリージョン
aws eks –region 好きなリージョン update-kubeconfig –name 好きな名前
“`
上記のようなコマンドを実行すると、EKSクラスターが作成されます。

私は以下のようにコマンドを実行しました。
ここでは、クラスター名をsampleService、ノード数を2、リージョンをus-west-2に設定しました。
“`Bash
eksctl create cluster –name sampleService –nodes-min=2 –region us-west-2
“`
::: note

【AWS SageMaker】Notebookインスタンスにてバッチ変換で組み込みアルゴリズムXGBoostの推論を行ってみた

# 背景
SageMakerで学習済みモデルを使って推論を行う際、その学習済みモデルのエンドポイントを作成していましたが、バッチ変換を用いる事で、わざわざエンドポイントを作成しなくても推論を行えそうなため(※)、バッチ変換を試してみる事にしました。

(※おそらく、内部的にはエンドポイントは作成されていて、推論完了後に自動でエンドポイントが削除されていると思います。)

https://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/batch-transform.html

# 環境
sagemaker 2.219.0

# 試した事(概要)
こちらの記事で作成した学習済みXGBoostモデルを使って、バッチ変換で、Nishikaのテスト(test)データを推論してみます。

https://qiita.com/bouru_sumisu/items/0d24018ce647996d9768

# 試した事(詳細)
こちらの記事の5.7.まで行っていて、学習済みXGBoostモデルの***model.tar.gz***ファイルは作成済みの

スタートアップ/自社開発企業のWeb&データインフラ基盤でありそうな構成

# はじめに
スタートアップや自社開発企業でインフラ環境を0から構築する際、よくある構成を列挙してみました。
※この記事は個人の見解に基づいています。もし偏見があるように感じられたら、申し訳ございません。
※クラウドは、AWS前提とさせてください。

# 全体構成図
ざっくり、こんな感じかなと思いました。

# 環境構成
dev, prod用のAWSアカウントが必要なので、二つあるといいかなと思いました。
理想は、金銭的に余裕があればですが、stg用のアカウントも欲しいです。

# IaC
Terraformが使いやすく、いいかなと思いました。
手動で実行した方が早いので、スキルさえあればそんなにヒューマンエラーが発生するものでもないです。
そのため、最初のうちは無理してGitHub Actions

踏み台サーバ経由の多段SSH接続を設定する

WebサーバやDBサーバをプライベートサブネットに作成した場合、踏み台サーバを用意し、踏み台サーバにSSHで接続し、そこからWebサーバやDBサーバに接続します。
この場合、踏み台サーバが乗っ取られた場合に、他のサーバにも侵入されるリスクが大きくなってしまいます。
また、sshコマンドを2回入力する必要がある、秘密鍵ファイルを踏み台サーバに転送する必要があるといった作業の手間があります。
そこで、ローカル端末にある秘密鍵のみを利用した、多段SSH接続を設定します。

# 多段SSH接続を設定する
ホームディレクトリの.sshフォルダにconfigという名前のファイルを作成し、以下を記述してください。
“`
Host bation
Hostname xx.xx.xx.xx (踏み台サーバのパブリックIP)
User ec2-user
IdentityFile ~/.ssh/xxxxx.pem

Host web01
Hostname xx.xx.xx.xx (WebサーバのプライベートIP)
User ec2-user
IdentityFile ~/.ssh/xxxxx.pem
Pr

豆腐文字が倒せない・・・？

# 豆腐文字？
あなたは、豆腐文字　をご存じでしょうか？？

こういうやつです⇒（□□）

Pythonのmatplotlib を使ってグラフを作成すると
おおよそ日本語に対応していないフォントなので
□□　になっていまうこと　ありますよね・・・。

「matplotlib 文字化け」等で検索すると、便利ライブラリ「japanize-matplotlib」を使った解決法があります。
また、日本語に対応しているフォントを追加して、手動で設定する方法もあります。

ー参考記事ー

https://qiita.com/uehara1414/items/6286590d2e1ffbf68f6c

https://qiita.com/katuemon/items/5c4db01997ad9dc343e0

公式：japanize-matplotlib

https://pypi.org/project/japanize-matplotlib/

これで解決することが多いのですが、ドツボにはまってどうしようもない・・・
という方向けの記事になります！

# AWSのSagemaker Stud

ゴールデンイメージってなんだっけを改めて調べてみた

# ゴールデンイメージとは？
事前に構成された環境をマシンイメージ化し、テンプレートとして使えるようにしたもの。
このイメージは、新しいハードウェアや仮想マシンに迅速にデプロイするための使用されるってことみたいです。

### ゴールデンイメージを使用することの利点
– 一貫性：全てのデプロイメントが同じ設定とソフトウェアを持つため、一貫性が保たれます。
– 時間と労力の節約：手動でのインストールや設定作業を省略できるため、時間と労力を節約できます。
– セキュリティと管理の容易化：標準された環境を保つことで、セキュリティ対策や管理が容易になります。

# 【本題】AWS上のゴールデンイメージは？
AWSにおけるゴールデンイメージは、Amazon Machine Image(AMI)と呼ばれています。
AMIは、特定のインスタンスの設定を保存したテンプレートで、以下の内容が含まれます。

– オペレーティングシステム(OS)：WindowsとかLinuxのこと
– アプリケーションソフトウェア：ソフトウェアとかミドルウェア、ツール、サービスなど
– アプリケーションサポートファイル：設

LambdaでSESが受信したメールを一括取得する

# 導入
こんにちは。エンジニアのFuMiSanです。

特殊なパターンですが、Amazon Simple Email Service (SES)で受信したメールをLambdaで一括処理することがあったので、備忘録的に残しておきます。

# 実装内容

今回作成したLambdaは、CloudWatch Eventsで毎日23時に実行することを想定しています。
SESの取得範囲は、前日の23時から当日の23時までのものになります。
また、SESから取得したデータの加工に関しては、割愛しています。

## Lambdaソース

“`python
import boto3
from datetime import datetime, timedelta

def lambda_handler(event, context):
# SES クライアント
ses_client = boto3.client(‘ses’, region_name=’your-region’)

# 今日の日付を取得
today = datetime.utcnow().date()

【AWS】AWS CodeArtifactをAWS CodeBuildで検証する（準備編）

## はじめに

この記事では「この前リリースされた機能って実際に動かすとどんな感じなんだろう」とか「もしかしたら内容次第では使えるかも？？」などAWSサービスの中でも特定の機能にフォーカスしたり、サービス間連携を検証していく記事です。
主な内容としては実践したときのメモを中心に書きます。（忘れやすいことなど）誤りなどがあれば書き直していく予定です。

今回はAWS CodeBuildでAWS CodeArtifactを使うとどうなるのかを検証するために環境をセットアップします。

## そもそもAWSのCodeシリーズとは

AWSには「Code」と名のつくサービスがいくつかあります。いくつか抜粋してみると以下のようなものがあります。

– AWS CodeCommit
– AWS CodeBuild
– AWS CodeDeploy
– AWS CodePipeline
– AWS CodeArtifact
– AWS CodeGuru
– AWS CodeDeploy

Amazon CodeCalystというサービスもありますが、これもCodeシリーズに含まれるのかは不明です。

AmazonLinux2023にCloudWatchAgentをパラメータストアも使用してSSMで設定する

数年ぶりに CloudWatch Agent をセットアップしようと思ったらセットアップの方法が増えていたのでやってみました。

# 環境情報

対象の EC2 インスタンスは、ネットワーク設定上 SSM と通信可能な状態にしてあります。

“`shell-session
$ ec2-metadata –ami-id
ami-id: ami-0a390a03d7ac1e284
$ cat /etc/system-release
Amazon Linux release 2023.4.20240513 (Amazon Linux)
$ uname -a
Linux example.ap-northeast-1.compute.internal 6.1.79-99.164.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Feb 27 18:02:23 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
“`

# IAM ロールの設定

対象の EC2 インスタンスに必要な権限を付与します。

AWS 管理の以下ポリシ

HULFT10 for Container Services 拡張性構成の考え方

## 1. はじめに
こんにちは、すぎもんです:smile:

いわゆる「コンテナ版HULFT」であるHULFT10 for Container Services(以下**CS版**)を少しずつ触っております。
CS版では従来のクライアントOSインストール版HULFT(以下**OS版**)と異なり、AWSのインフラ構成（インスタンス数、ストレージ、DB、ネットワーク等）によりファイル転送のパフォーマンス向上（同時集配信数、全体スループットの向上）が期待できます。このコンテンツでは、HULFT10の集配信性能を高めるためのAWS構成の考え方、気を付けるべきポイントなどを考えてみます。

## 2. OS版とCS版の拡張対応方法
### 2-1. OS版
基本的に、CPU, メモリ、ネットワークなどの増強でボトルネックを解消するアプローチです。ロードバランサー対応はされていないため、スケールアップでの対応になります。

### 2-2. CS版
ロードバランサーによる分散処理（タスク起動数を増やす）ことで全体スループットを上げるアプローチです。ロードバランサー対応のアーキテクチャとな

HULFT10 for ECS 可用性構成の考え方

## 1. はじめに
こんにちは、すぎもんです:smile:

いわゆる「コンテナ版HULFT」であるHULFT10 for Container Services(以下**CS版**)を少しずつ触っております。
CS版では従来のクライアントOSインストール版HULFT(以下**OS版**)と異なり、AWSのインフラ構成（インスタンス数、ストレージ、DB、ネットワーク等）により耐障害性やVup等のメンテナンス時間の縮小などが期待できます。このコンテンツでは、HULFT10の可用性を高めるためのAWS構成を考えてみます。

## 2. CS版とOS版の可用性を担保するアーキテクチャの違い

### 2-1. OS版（HA型クラスタを採用）
OS版では、耐障害性を確保するためにHA（High Availability）型クラスタが採用されています。これにより、障害が発生しても自動的にフェイルオーバーが行われ、ダウンタイムを最小限に抑えることが可能です。

### 2-2. CS版（負荷分散型クラスタを採用）
CS版では、負荷分散型クラスタが採用されており、スケールアウトやリソースの最適化

HULFT10 for ECS EC2とFargate 実行インスタンス選択の考え方について

## 1. はじめに
こんにちは、すぎもんです:smile:

いわゆる「コンテナ版HULFT」であるHULFT10 for Container Servicesを少しずつ触っております。
HULFT10 for Container ServicesでAWS上にコンテナを利用したソフトウェアの設定を行う際にはEC2版とFargate版のいずれかを選択することができます。この記事では、それぞれの特徴と、どちらを選択すべきかの指針となる情報を考察してみます。

## 2. EC2版とFargate版の特徴

**EC2版**

– EC2版は実行エンジンのスペック（CPU、メモリ、ネットワーク等）の最適化が可能です。具体的には、アプリケーションのニーズに応じて、インスタンスの種類やサイズを自由に選択できるため、リソースの効率的な利用が可能です。これにより、高パフォーマンスが求められるワークロードに対しても柔軟に対応できます。加えて、手動によるチューニングが可能なため、特定の要件に合わせた微調整が行いやすい点が魅力。

– ストレージはEFS、S3の両方を利用できます。EFS（Elastic

ssm-agentを利用したportforwardingの設定

ssm-agentを利用したportfowerdingの利用方法は以下の通りです

## IAMの権限に関して
IAMのSSM-userには下記ロールを割り当てておくこと

・AmazonEC2ReadOnlyAccess
・AmazonSSMFullAccess

## 設定手順
①Session Manager plugin のインストール
　※下記はローカルで実行します。

“`
curl “https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip” -o “sessionmanager-bundle.zip”
unzip sessionmanager-bundle.zip
sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
“`

②aws accountのcredenti

shyaml で yaml を parse して shell script で楽したい

## tldr;

`shyaml` を使うと yaml を shell script で parse して value を使えて楽だよ

## requirements

1. `Python` && `pip` がインストールされている
2. [`shyaml`]() がインストールされている
* なければ `pip install shyaml`

## `shyaml` の使い方

“`
cat /path/to/my.yml | shyaml get-value path.of.my.yaml.field
“`

## example

例えば project root dir に以下の yaml があるとします。

“`yaml:.elasticbeanstalk/config.yml
branch-defaults:
develop:
environment: my-eb-env-develop
main:
environment: my-eb-env-main
environment-defaults:
my-eb-env-t

RDSがフェイルオーバーした際、ECSで動作しているRuby on Railsを再起動する仕組みを構築した

# 概要
`RDS`がフェイルオーバを行うと`Ruby on Rails`(以下、`Rails`)では、ダウンしたDBを参照する現象が発生します。この問題により、`DB`を参照出来ない為、`Rails`が動作しなくなります。今回は、`RDS`のフェイルオーバーが行われたら、`RDS`のイベントサブスクリプション、`SNS`、`Lambda`を使用して、`ECS`で起動している`Rails`の`puma`を再起動する処理を構築しました。今回は、その実装方法を記載します。

# 前提条件
– `ECS`で`Ruby on Rails`の環境が動作している
– `Amazon aurora`(postgres)を使用している (RDSでも今回の実施は可能)
– `Terraform`を使用している (webコンソールから設定する事も可能)

# Lambdaの処理を動かす為の技術選定
フェイルオーバーが行われた事を`Lambda`に通知する機能として、RDSの[イベントサブスクリプション](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/