AWS関連のことを調べてみた2022年07月12日

AWS関連のことを調べてみた2022年07月12日
目次

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

# 概要
Cloudwatchで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
– AmazonSSMFu

元記事を表示

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

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

## オンプレミスとAWSの接続方法
専用線、またはVPNを利用した接続は以下の3つがあります。
・ 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 がおすすめ。
![Screen Shot 2022-07-11 at 20.18.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/44959/0e35f205-37f1-1be1-b9b4-58cc0783b050.png)

## 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ドキュメントの公開を可能に

元記事を表示

AWS Hands-on for Beginners 〜Serverless 編〜  #2

## はじめに
勉強していることをなんとなくメモっていきます。

行うこと
https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-hands-on/
サーバーレスアーキテクチャで翻訳 Web API を構築する
自分宛のメモを残していきます。

本人情報
IT現場雑用員(一生エクセル触ってる人)
社会人2年目、脳死資格取得男、最近SAPに受かった。

AWS Hands-on for Beginners 〜Serverless 編〜  #1  の続きです。

## DynamoDBについて
### DynamoDBの特徴
**1. フルマネージド型のNoSQLデータベースサービス**
マネージドサービスなのでソフトウェアのインストールなどは必要にならず、起動さえできればすぐにデータベースとして使い始められます。キーバリュー型のデータベースであり、セッション情報の管理などにも使われます。

**2. 3つのAZに保存されるので信頼性が高い**
RDSは自分でマルチAZを有効する必要がありますが、Dynamo

元記事を表示

AWSにてチーム開発をする際のTerraformの設定

# はじめに
AWSにてチーム開発をする際の設定です。
CloudFormationでは意識しないような設定がTerraformでは必要です。
チーム開発のために下記のリソースを別途構築する必要があります。

– S3をBackendとし、terraform.tfstateを管理する。
– DynamoDBにてlockをし、開発者の “`terraform apply“` の実行の排他制御をする。

Terraformのバージョンは “`v1.1.6“`とする。

# 実行環境の準備
[AWS CloudFormationを動かすためのAWS CLIの設定](https://qiita.com/miyabiz/items/fed11796f0ea2b7608f4)を参考にしてください。

※ CloudFormationと同じです。

# S3とDynamoDBを構築する
1. [terraform-aws-tfstate-backend](https://github.com/cloudposse/terraform-aws-tfstate-backend)を利用する。

元記事を表示

AWS Client VPNとAzure P2S 機能比較 02~AWS Client VPN クライアントPC設定編~

# AWS Client VPNとAzure P2Sを比較してみた
[前回の記事](https://qiita.com/drafts/5dc7de8f3cde645959b2)からの続きです。
AWS Client VPNでオンプレミスのPCをAWSのVPCに接続し、その際にインターネットに出るIPアドレスをAWSの固定IPアドレスにする、という構成です。
ネットワークの用語でいうと**フルトンネル**(フルトンネリング)という構成です。
NAT GatewayにElastic IPアドレスを設定し、AWS Client VPNでインターネットに出る際、IPアドレスをElastic IPアドレスに固定する(固定IPアドレスにする)というシナリオです。
今回はAWS Client VPNのクライアントPC側の設定です。
Azure P2Sは証明書インストールとP2Sのエージェントインストールのみなので大した作業ではないのですが、AWS Client VPNは運用観点も絡めるとまぁまぁ面倒な設定があるので比較のためにも記事にしました。

## AWS Client VPNの構成図と本記事の

元記事を表示

【ECS】LaravelからElasticCacheに接続しようとしたら「Unable to find the socket transport “ssl” – did you forget to enable it when you configured PHP?」というエラーが出た【AWS】

## 前提情報
– PHP7.4
– Laravel 6.x
– ECS/Fargate

## エラーの原因と詳細
ローカル環境にあるredisコンテナには接続できたので、次にAWS上でElascitCacheの動作確認をするため、ECS/Fargate環境へデプロイしたら`Unable to find the socket transport “ssl” – did you forget to enable it when you configured PHP?`というエラーが発生してElasticCacheへ接続できない状況でした。

Redisクライアント(phpredis)から外部(ElasticCache)へ接続するときに、PHPのOpenSSLモジュールが有効になっていないのが原因っぽい。(Redisに限らず、外部へHTTPS接続する際にはOpenSSLモジュールを有効にしないといけないようです)

というか、そもそも[LaravelのドキュメントにOpenSSLは必須だよ](https://laravel.com/docs/9.x/deployment#server-r

元記事を表示

Fargate で構築した Laravel と WordPress の コンテナを 読み取り専用(ReadOnly)にする

# はじめに

Fargate で Laravel や WordPress を構築後、セキュリティを高める方法として、`読み取り専用(readonlyRootFilesystem)` を有効にする方法があります。
この設定を行なうと、コンテナ内のファイルやディレクトリが読み取り専用となり、マルウェア等に対してセキュリティーが高めることができます。

ただし、全てを読み取りにはできず、一時的に書き込みが必要なディレクトリがサーバー内にありますので、一部のディレクトリを読み書き可能なボリュームとしてマウントし、残りは読み込み専用にすることが必要です。

今回は、Fargate で構築した Laravel と WordPress を読み取り専用にする方法について方法を記載します。

ちなみに、`読み取り専用(readonlyRootFilesystem)` を有効にすると、Fargate Execが使用できないデメリットがあります。

# 事前構築

– 下記の記事でwordpressをfargateで構築
– ソースはDockerfileのみ

https://qiita.com/hir

元記事を表示

AWS EKSの運用は実家の猫に任せてお前は先に行け

どうも、僕です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242714/a4972451-89ba-0d7f-b01e-30cb68fd4fed.png)

# CatOps
DevOps が Developers を運用に引きずり込む為のマインドセットだとすれば CapOps は猫を運用に引きずり込む為のマタタビセットと言えるでしょう。今回は実家でおやつを食べてばかりのあいつにも手伝ってもらいます。彼のおもちゃの半分ぐらいは私がAWSをこねくり回して得た給与によって供給されているのでこれは当然の義務とも言えます。

# Amazon Web Services Cat-Like Interface (AWS CLI)
作業用のIAMロールを作ります。仕事じゃないのでアクセス許可は雑です。

– AmazonEC2ContainerRegistryFullAccess
– AmazonEC2FullAccess
– AWSCloudFormationFullAccess
– [Ek

元記事を表示

3大クラウドのIoTサービスに接続してみた

AWS / Azure / GCP のIoTサービスへの接続比較です。
個人ブログには設定方法を画面キャプチャをつけて詳細に説明してますので興味がありましたらご参照ください。

# AWS IoT Core

* クライアントIDは任意の文字列
* 証明書発行機能がある
* 純粋なMQTTブローカーに一番近い印象

| 項目 | 値 |
| — | — |
| プロトコル | mqtts |
| ホスト名 | AWS IoTの設定画面で表示されるエンドポイント |
| ポート番号 | 8883 |
| クライアントID | 任意の文字 |
| ユーザー名 | 未指定 |
| パスワード | 未指定 |
| CAファイル | [Amazon Root CA 1](https://www.amazontrust.com/repository/AmazonRootCA1.pem)を保存したファイル |
| クライアント証明書 | デバイス証明書 |
| プライベートキー | プライベートキー |

* Publish
任意のトピック名に対してPublishが可能です。(一部A

元記事を表示

[AWS] Step FunctionsのoutputPath、resultPath、resultSelectorを使いこなす

# はじめに

AWS Step Functions の各タスクへの入力は、inputPathでJSON pathを指定することで、雑多な入力から必要な項目だけを拾うことができます。

出力側にはoutputPath、resultPath、resultSelectorというものがありますが、どうにも動作がわからなかったので調べてみようと思い立ちました。

と、勢い込んでみたものの、AWS Console に[Data flow simulator](https://console.aws.amazon.com/states/home?#/simulator) というよいものがありました。この記事読むより、シミュレーターで試してみたほうがよいです。

でも、めげずに書いてみます。

# 動作を確認した環境

## Lambda

入力と出力を確かめたいだけなので、値を返すだけのLambdaを作りました。これをStep Functionsの中で呼び出してみます。

“`ts:
export const sampleLambdaHandler = async (event: unknown

元記事を表示

OTHERカテゴリの最新記事