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

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

AWS ルートテーブルlocalメモ

AWSのルートテーブルにおける「**local**」というエントリは、**同じVPC内の通信**を指します。これは自動的に設定されるルートで、VPC内のリソース同士が通信できるようにするためのものです。具体的なポイントは以下のとおりです。

### 「local」の意味と役割
1. **VPC内通信を可能にするルート**:
– VPC内のサブネット間でのトラフィック(通信)を許可します。
– 例えば、同じVPC内のEC2インスタンス同士が、異なるサブネットに配置されていても、この「local」ルートによって通信が可能です。

2. **自動的に作成され、削除不可**:
– 「local」ルートはVPC作成時に自動で追加され、ユーザーが削除や編集できません。
– これはAWSがVPC内での基本的なネットワーク接続を保証するためです。

3. **CIDRブロックで範囲を指定**:
– 「local」ルートの宛先CIDRブロックは、そのVPCに設定されたアドレス範囲(例: 10.0.0.0/16)です。
– そのため、VPC内のすべてのサブネットがこのア

元記事を表示

ステートレスとステートフル(メモ)

AWS Firewall には、**ステートフル(stateful)** と **ステートレス(stateless)** のルールタイプがあり、それぞれ異なる用途や機能に適しています。AWS Firewall では、必要に応じてこれらのルールを使い分けてセキュリティポリシーを実現します。

### 1. ステートフル(Stateful)ルール
– **概要**:ステートフルルールは、トラフィックの**状態(ステート)を追跡**するため、各接続のセッション情報を保持します。
– **特徴**:
– 一度許可した接続に対する応答トラフィックは、自動的に許可されます。つまり、アウトバウンドで許可されたトラフィックのインバウンド応答を明示的に許可する必要はありません。
– ステートフルな追跡により、不正なトラフィックや攻撃を高精度に検出・防止できます。
– パケットレベルだけでなく、セッション全体を監視できるため、複雑なルール設定が可能です。
– **使用例**:
– 内部ネットワークからのアウトバウンドアクセスや、外部から内部へのインバウンド接続を追跡・制御する場面で使用。

元記事を表示

RDSのスロークエリ通知について

## はじめに
AWS RDSのスロークエリ通知は、RDSで発生する遅いクエリの実行時間を追跡し、パフォーマンスの改善に役立てるための重要な手法です。
スロークエリを検出し、適切な通知を設定することで、データベースのパフォーマンスの向上を図ることができます。この記事では、RDSスロークエリログの有効化から、AWSのサービスを活用した通知の仕組みまでを解説します。

## スロークエリとは?
スロークエリとは、指定した時間よりも長くかかるクエリを指します。例えば、インデックスが適切に設定されていない場合や複雑なクエリが実行される場合、スロークエリが発生しやすくなります。RDSでは、スロークエリを監視し、パフォーマンス改善に役立つ情報を得ることができます。

## RDSでのスロークエリログの有効化方法
AWS RDSでスロークエリを監視するためには、まずスロークエリログを有効にする必要があります。

### 設定手順
“`
1 RDSコンソールでターゲットのインスタンスを選択します。
2 パラメータグループを設定し、slow_query_logを1(有効)にします。
3 スロークエリロ

元記事を表示

AWS CodeCommitでGitリポジトリの基本操作を行う

AWS CodeCommitは、AWSクラウド上で管理できるGitベースのバージョン管理サービスです。
この記事では、CodeCommitで新しいリポジトリを作成し、基本的なGit操作を行う方法について説明します。

## 事前準備
– AWSアカウントが必要です。
– Gitがインストールされていることを確認してください。

## リポジトリのクローン
まず、AWS CodeCommitで作成したリポジトリをクローンします。

“`bash
git clone ssh://git-codecommit.[リージョン].amazonaws.com/v1/repos/[リポジトリ名]
“`

## ファイルの追加とコミット
次に、新しいHTMLファイルをリポジトリに追加します。

1. リポジトリのディレクトリに移動します。
“`bash
cd [リポジトリ名]
“`

2. `index.html` ファイルを作成します。
“`bash
echo ‘

Hello, CodeCommit!

元記事を表示

MFA有効ユーザーを利用しCLIを使う方法

## 概要
MFAを有効にしているユーザーを使い、CLIを使う方法について説明します。
かなり苦戦したので、記載します。
## 状況
*AdministratorAccessとMFAを認証をクリアした場合のみ各種操作が可能なポリシーを付与したユーザー*を利用して、通常通りCLIを使おうとすると、下記エラーになります。
“`
An error occurred (AccessDenied) when calling the ListBuckets operation: User: arn:aws:iam::[アカウント番号]:user/[利用しているユーザー名] is not authorized to perform: s3:ListAllMyBuckets with an explicit deny in an identity-based policy
“`
エラー文をストレートに取ると、s3:ListAllMyBucketsの実行権限がないと受け取れると思います。この状態で仮に別ポリシーでs3:ListAllMyBuckets

元記事を表示

DynamicFrameをRedshiftにロードする際のファイル形式にParquetを指定するとError code 15007が発生する

“`
error: Spectrum Scan Error
code: 15007
context: File ‘https://s3.ap-northeast-1.amazonaws.com/xxx.snappy.parquet’ has an incompatible Parquet schema for column ‘s3://xxx
query: 00000
location: dory_util.cpp:1671
process: worker_thread [pid=000]
“`

デフォルトはCSVで、Parquetに変更することでエラーが発生する。

#### 原因1
##### CSV形式
– データはテキストとして保存される
– 各フィールドは文字列として扱われ、データ型の情報は含まない
– Redshiftにデータをロードする際、必要に応じてデータ型のキャストや変換が自動的に行う

##### Parquet形式
– データとともにスキーマ情報(データ型、列名など)を持つ
– 各フィールドのデータ型が明示的に定義され、厳

元記事を表示

【新卒1年目】合格記② AWS Certified Cloud Practitioner

# はじめに
AZ-900に引き続き資格を取得しました!!
合格記として記します。

# AWS Certified Cloud Practitionerとは
” AWS Certified Cloud Practitioner は、AWS クラウド、サービス、用語の基礎的かつ高度な理解を持っていることを証明します。 ”

https://aws.amazon.com/jp/certification/certified-cloud-practitioner/

# 使用した教材

■ Udemy「CLF-C02版】この問題だけで合格可能!AWS 認定クラウドプラクティショナー 模擬試験問題集」
https://www.bing.com/ck/a?!&&p=3d2dc5a0cd712e76f137fa127d7cebb0063c053560261340f4852d7a867787cfJmltdHM9MTczMDMzMjgwMA&ptn=3&ver=2&hsh=4&fclid=12549f4b-4c21-60a2-30e4-8b1f4de86166&psq=%e3%80%90CLF-C0

元記事を表示

【新卒1年目】合格記① AZ-900 Microsoft Certified: Azure Fundamentals

# はじめに
入社してから3ヶ月経ち仕事というものに慣れてきました。
社会人になり、初めての試験合格!**AZ-900合格!**
勉強録として記します。

# AZ-900 Microsoft Certified: Azure Fundamentalsとは
” クラウドの概念、Azure のコア サービス、および Azure の管理とガバナンスの機能とツールに関する基本的な知識を示します。 ”

https://learn.microsoft.com/ja-jp/credentials/certifications/azure-fundamentals/?practice-assessment-type=certification

# 使用した教材

■ 合格対策Microsoft認定 AZ-900:Microsoft Azure Fundamentals テキスト&問題集第2版
Amazon : https://amzn.asia/d/80ez7me

■ Udemy「最短で合格!Azure Fundamentals AZ-900 試験対策問題集」
https://www.bin

元記事を表示

TerraformでAurora MySQLを構築し、RDS Data APIを使用する。

# はじめに
皆様お疲れ様です!
株式会社TechoesインフラチームのTです!

今回は9/26にAmazon Aurora MySQL で RDS Data API のサポートを開始したようなので早速Terraformを使用して実践してみようと思います。
# 実行環境
– Windows : 11 Home 23H2
– Terraform : v1.9.7
– aws cli : 2.11.22
# RDS Data APIについて
### 概要
RDS Data APIを利用することでHTTPSエンドポイントを介してRDS,Auroraに接続やDBドライバを管理することなくSQLの実行が可能になる。
接続時にSecret Managaerの情報を使用するため、認証情報を渡す必要がない

### 料金
最初の10億件のリクエストは100万回あたり0.42USD、10 億件を超えた場合は0.24USD
### 制約
– サポートしているエンジンが限定的
 現時点で Aurora Mysqlと Aurora PostgreSQLのみをサポート
– サポートしているインスタンスクラ

元記事を表示

Lambda(Node.js)のDockerイメージをデプロイしてみた。(その3,EC2上でDocker上のLambdaを実行してデバック)

# はじめに
LambdaをDockerイメージでデプロイする方法を、調査する機会があったので自分の備忘用にメモ書きを残します。

今回は、Dockerを起動して動作確認をする所をメモ書きします。
実行環境は、前回からの続きです。

# イメージをビルドする

“`shell
cd
cd DeployProject
docker build -t deployproject:test1 .
“`
-t オプションで、「名前:タグ」を指定しながらビルドします。

前回、Dockerファイルに「COPYコマンド」など正常に動くか確認します。

# デバック用の端末用意
デプロイする前の動作確認は、Teratermの端末を3枚用意するとデバック作業が楽でした。

Teratermは、「File」→「Duplicate session」で同じ接続端末を増やせるので3枚に増やして、下記の用な配置でデバックしてました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281768/d2af27f

元記事を表示

CloudFront Continuous Deployment を試した

# CDN の設定変更

– CDN は変更に時間がかかったりすることがある
– なので,staging distribution という別の設定を追加して,その動作を確認してから反映させられたりするので便利という機能がある

## 見た感じ

– continuous deployment を作成すると
– 2つのdistribution ができる
– primary distribution / staging distribution
– 反映するには,promote すればよい
– distribution を切り替えるのかと思ったけど,既存の primary 側に設定を反映してそうだった

## ステージング状態だと

– staging に向ける方法が2種類ある
– 荷重
– header
– header を使った方が良さそうに感じてはいる
– cache したりして,header が付かないミスに注意する

## ハマったところ

– 何故か primary distribution と link してくれ

元記事を表示

Flutter Web APP + Amazon S3 Bucket

# アホまぬけ登録画面
## 定数
“`bash
BACKET_NAME=aho-maru.dashi-user && REGION=us-east-1
APP_NAME=aho_marudashi_app && APP_ROOT=~/app/flutter/$APP_NAME
“`
* バケットウェブサイトエンドポイントURL
“`bash
BACKET_URL=http://$BACKET_NAME.s3-website-$REGION.amazonaws.com && echo $BACKET_NAME
“`
## 通常開発時ルーチン
* ビルド&デプロイコマンド
“`bash
cd $APP_ROOT && git add . && git commit -m “regular update” && git push -u origin main
flutter build web && aws s3 sync build/web s3://$BACKET_NAME/ && aws s3 ls s3://$BACKET_NAME/
“`

元記事を表示

LocalStack と Docker Compose でローカル AWS S3 環境を構築してみた – セットアップから主要な操作まで

## はじめに

LocalStack は知っていたけど、実際に触ったことが無かったので、LocakStack で S3 を起動して、主要な機能を触ってみました。

## セットアップ

LocalStack を管理する方法としては、[LocalStack CLI](https://docs.localstack.cloud/getting-started/installation/#localstack-cli), [LocalStack Desktop](https://docs.localstack.cloud/user-guide/tools/localstack-desktop/) などの専用のツールもありますが、今回はプロジェクトの扱いやすさを考えて、[Docker-Compose](https://docs.localstack.cloud/getting-started/installation/#docker-compose) を利用します。

### Docker-Compose で起動する

docker-compose.yml を作成して、S3 を利用できるよう

元記事を表示

VPCフローログの取得(S3へ保存)

こんにちは。
VPCフローログの取得とログをS3へ保存する設定をします。

S3に保存するメリット、デメリットを簡単に記載。
メリット
– Athenaなどログ分析を利用できる
– S3は長期データ保存に向くため大量のデータをコスト効率よく保存できる

デメリット
– リアルタイム分析や検知に不向き

ログ取得から通知設定をしたい場合はCloudWatch logsがおすすめのようです。

## フローログの設定

設定はとても簡単でした。以下、設定の流れです。
・S3バケットの作成(S3操作)
・ログを取得したいVPCでフローログの設定(VPC操作)

### S3の設定

バケット作成ですが、特に詳細な設定は不要です。

### VPCの設定
まずは設定したいVPCを選択、フローログタブをクリックしてフローログ作成をクリック。
(私はすでに作成しているので画像にフローログ設定が表示されています。)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3902743/217fee34-7

元記事を表示

【AWS】Amazon Linux 2023 でCloudWatch設定

この前何気にAmazonLinux2023で初めてCloudWatch設定をしました。
そしてアクセスログをAmazon Linux 2と同様にCloudWatchで設定しようとすると、見事に罠にハマってしまった為問題と改善策を記録しようと思い本記事を記載します。

# 前提
AWS
EC2 AmazonLinux2023
IAMロールでCloudWatchLogsFullAccessを適用
Nginxをミドルウェアとして利用
socket通信を利用するためにphp-fpmも利用
今回監視したいのは以下3つ
– nginxのアクセスログ
– nginxのエラーログ
– php-fpmのエラーログ

# 失敗した内容
対象とするインスタンスでCloudWatch Logsと連携するためにはエージェントをインストールする必要があるので、Amazon Linux 2と同様に以下コマンドを実行しました。
“`
dnf install -y awslogs
Last metadata expiration check: 3:12:45 ago on Mon Nov 4 23:01:38 20

元記事を表示

AWSのデータベースサービス比較

## 概要
– SAAの勉強をしていてAWSのデータベースの違いが曖昧だったのでざっくり特徴をまとめてみる
– 参考書とネットの情報を元に自分なりにまとめたので認識違う部分があったらゴメンナサイ

## AWSの主要なDBサービス
– 試験で問われる主要なサービスは大きく下記の通り
– Amazon RDS
– Amazon Aurora
– Amazon Redshift
– Amazon DynamoDB
– Amazon ElastiCache
– 今回はこれらのDBサービスの特徴を比較する
– ざっくりとしたサマリは下記の通り
※列数が多くて表にすると見づらいので画像貼ったけどそれでも見づらい。。。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3757184/382369e1-415a-4c74-9095-3143c396c0ff.png)

## Amazon RDS
### 概要
– マネージドで提供されるRDBサービス
– 下記

元記事を表示

Ubuntu で Kubeadm により k8s 環境構築実験(5)

[Ubuntu で Kubeadm により k8s 環境構築実験(4)](https://qiita.com/intrajp/items/43f33da0e324c22d0ca7)の続きです。

ワーカーノード2が、Not Ready になっている問題です。

もう一度、describe してみました。
“`bash
ubuntu@Worker-Node2:~$ kubectl describe node worker-node2
Name: worker-node2
Roles:
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=worker-node2
ku

元記事を表示

Amazon WorkSpacesメモ

Amazon WorkSpacesは、AWSが提供する仮想デスクトップインフラストラクチャ(VDI)サービスです。これにより、ユーザーはクラウド上でWindowsやLinuxのデスクトップ環境を仮想的に利用でき、インターネット接続があればどこからでもデスクトップにアクセス可能です。企業内でのリモートワーク、BYOD(Bring Your Own Device)環境、柔軟なデバイスアクセスが求められるシナリオに最適です。

### Amazon WorkSpacesの主な特徴
1. **フルマネージドのVDI**
Amazon WorkSpacesはAWSが完全に管理しているため、インフラのセットアップやメンテナンスが不要です。仮想デスクトップのセットアップ、ソフトウェアのインストール、パッチ適用などの運用管理がAWSによって行われます。

2. **スケーラブルな仮想デスクトップ**
必要に応じて、デスクトップのリソース(CPU、メモリ、ストレージなど)を柔軟に設定・変更できます。また、企業規模に合わせて数十台から数千台の仮想デスクトップを迅速に展開可能です。

3

元記事を表示

AWS Directory Serviceメモ

AWS Directory Serviceは、AWSが提供するクラウドベースのディレクトリサービスで、Microsoft Active Directory(AD)の機能をAWS環境で使用できるようにします。特に、既存のオンプレミスのADと統合したり、完全にAWS上で新たなADを構築したりするのに役立ちます。これにより、Windows環境のシングルサインオンやセキュリティ設定の管理を、クラウド上で簡単に行えます。

### AWS Directory Serviceの主なタイプ
1. **AWS Managed Microsoft AD**
AWSがフルマネージドで提供するMicrosoft Active Directory。Windows Server Active Directoryと同様の機能を持ち、既存のオンプレミスADとAWS ADをディレクトリ信頼関係で接続することも可能です。これにより、既存の認証情報やポリシーをAWSリソースに対しても活用できます。

2. **Simple AD**
Microsoft ADの基本機能を備えた軽量ディレクトリサービスで

元記事を表示

Go AWS SDKを使用してEC2インスタンスにコマンドを実行する

## はじめに
GoのAWS SDKを使用してAWSのEC2インスタンスにコマンドを送信し、その結果を取得してみました。sshで接続してからのコマンド実行ではなく、AWS Systems Manager (SSM)の機能を使用してEC2インスタンスにコマンドを実行させました。

### 前提条件

* **SSM Agentのインストール**: EC2インスタンスにSSM Agentがインストールされている必要があります。これにより、EC2のインスタンスがAWS Systems Managerと通信できるようになります。多くのAWS提供のAMIにはSSM Agentが事前にインストールされています。また、今回やりませんでしたが、手動でインストールすることもできます

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html

* **権限の設定**: コマンドを実行するためには、IAMロールやポリシーを設定し、必要な権限を付与する必要

元記事を表示

OTHERカテゴリの最新記事