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

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

ACMで「保留中の検証」から変わらない、からのACMの理解

## はじめに 

Amazon Certificate Manager(ACM)でSSL証明書を発行しようとしたところ、ステータスが「保留中の検証」からずっと変化がなく困りました。  
調べたところ、CNAMEレコードの登録が必要であることが判明し、実施したところ無事に解決しました。  
その期にACMが証明書を発行するまでの流れについて調べてみましたので、そこで理解したことについても書きたいと思います。

前提:証明書を発行するドメインはAWSで取得しました。DNSサーバーはRoute53を使用します。

## 「保留中の検証」の解決  

まず調べたところDNSによる検証の場合、証明書IDをクリックした先の画面で表示されるCNAME名とCNAME値を、Route53に登録する必要があることがわかりました。Route53で手動で値を入力し登録したところ、無事にステータスが「発行済み」に変わりました。  
その後に気づいたのですが、ACMのコンソールにある「Route53でレコードを作成」をクリックすれば、CNAME名とCNAME値を自動で入力してくれます。気付きませんでした…。

元記事を表示

ASWのVPCについて

AWSを扱う上で必須となるVPCについて勉強をしたので自身の理解・復習また文章力の向上のためアウトプットさせていただきます。

はじめに

実際にAWSコンソールで触っていく前に今回の勉強で必要な用語の勉強をしましたので以下で説明します。
・リージョン
・アベイラビリティゾーン
・VPC

リージョン

AWSはクラウドサービスを提供するために、世界各地にデータセンターを保有しています。よってAWSサービスを利用する際には、このデータセンターの一部を使っている事になります。
これらのデータセンターは、「リージョン」という単位で地理的に分割して管理されています。
リージョンとリージョンの間は完全に分離されておりますのであるリージョンで障害が発生しても、他のリージョンに影響が及ぶことはありません。

リージョンはその地域の法律に準拠しているので、データ保護法等について考える必要も少なくなります。

データ保護法等については

元記事を表示

【AWA SSA -C03】AWS Solution Architect Associateになぜ合格できたかわからないがとりあえず受かってよかった話

こんにちは。torippy1024です。
先日ですが、AWS Solution Architect Associate試験に合格しました。
自分でもなぜ合格できたのかさっぱりわからないのですが、とりあえず受かったのでこういう人もいるよ、という体験記を載せておきます。

誰のなんの参考になるのかわかりませんが、こういう人もいる程度に読んでいただければと思います。(運が良くて本当に良かった・・・という体験記です。これから受ける人はしっかりと勉強して望んでいただきたいと思います)

# 私のAWSに関する背景知識や経験
– 2015年にAWS Developer Associtateを取得したことがある。(はるか昔、まだ日本出始めたくらい・・・。めっちゃ勉強して落ちて、2回目で合格したのでめっちゃ嬉しかった・・・)それから、資格更新はしていない。
– 実務経験はほぼなし。提案フェーズでアーキテクチャ検討などはしたことがあるが、その際も採用には至らず。設計・構築・運用したことはなし。研修でEC2やRDSやS3を使ったWEBサイトは構築したことがある。ELBとAuto Scalingを使ってW

元記事を表示

Auroraのスケジュール起動・停止でつまずいたこと

# つまづいたこと
コスト削減のため、Amazon Auroraのスケジュール起動・停止を実現しようとAWS所有SSMドキュメントおよびEventBridgeで実装しようとしていたのですが、何度トライしても**Auroraクラスター**が停止されず、パラメーターなども何度も変更しながら試行錯誤をしていました。

結論から書きますと「**Aurora**と**RDS**ではスケジュール起動・停止に使用するAWS自己所有SSMドキュメントは異なる」という事が原因でした。

# 不正解
こちらの「**AWS-StartRdsInstance**」および「**AWS-StopRdsInstance**」でずっとトライしていましたが、一向に停止される気配無し。あくまで**RDS**向けとの事。
![AWS-StartStopRdsInstance.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/143947/a4a1535a-1dc4-d907-e3fa-e48a8087e0ca.jpeg)

# 正解
こちらの「

元記事を表示

【AWS】Lambdaのベストプラクティス

こんばんは。kitonです。
DVAの勉強中にLambdaのベストプラクティスについての問いが耳が痛くなるほど出てたので、勉強の合間でまとめました。

# ベストプラクティス

## やったほうが良いこと

### Lambdaハンドラーをコアロジックから分離
– 関数の単体テストが実行しやすくなる。

例)
“`
exports.myHandler = function(event, context, callback) {
var foo = event.foo;
var bar = event.bar;
var result = MyLambdaFunction (foo, bar);

callback(null, result);
}

//コアロジックから分離しているところがポイント
function MyLambdaFunction (foo, bar) {
// MyLambdaFunction logic here
}

“`

### 実行環境を再利用
– ハンドラー外でSDKクライアントとデータベース接続を初期化し、静的情報を/tmpディレクトリにキ

元記事を表示

カスタムSSMドキュメント + EventBridgeでECSのスケジュール起動・停止(CDK)

# 概要
カスタムSSMドキュメント + EventBridgeでECSをスケジュール起動・停止(**正確には停止ではなく、ECSのタスク数を0に変更**)するCDKサンプルコード(TypeScript)を紹介します。

ECSの起動・停止させるカスタムSSMドキュメントをSSMDocumentスタックで作成して、CfnOutputでEventスタックに渡してEventBridgeによるスケジュール実行させます。

開発環境やSTG環境のECSをスケジュールに従って起動・停止するだけでもコスト削減効果が見込めると思います。

# ファイル構成
ファイル構成は以下です。
* bin/
* main.ts
* lib/
* SsmDocuments/
* SsmDocumentsStack.ts
* Events/
* EventsStack.ts

# サンプルコード

## bin/main.ts

“`typescript:bin/main.ts
#!/usr/bin/env node

import ‘source-map-

元記事を表示

injector(DIコンテナ)の隠蔽

[前々回](https://qiita.com/odxdoge/items/6031419f9461a8775d98)と[前回](https://qiita.com/odxdoge/items/2d1924e7d4fbe92e9969)の続きです。
クラスの依存関係の管理方法について解説しました。
injectorの実用的なテクニックについて深掘りします。

## アーキテクチャ設計と実装

今までのコードでDIの考え方について解説してきました。また、その実装をライブラリを使って実現する方法についても示してきました。このようにアプリケーションのアーキテクチャを設計し、決定した場合、その後実装を行うはずです。
しかし、実際にAWS Lambdaで実装すると、ひとつ思うことがあります。
lambda handlerの最初にinjectorインスタンスを作成し、設定を行う必要があり、複数のLambdaを運用すると重複したコードになります。

これにはいくつかの問題が挙げられます。
– 関係するすべてのLambda実装者がinjectorについて理解している必要があります。
– injecto

元記事を表示

SSMのRun CommandでAnsibleを実行してみる

# はじめに
Terraformの勉強を始めたので備忘録を兼ねて行ったことを投稿しようと思います。
以下の4つの投稿内容を実施した上で今回の内容を行います。
[TerraformをインストールしてTerraformでAWS上にEC2作ってみる](https://qiita.com/kakita-yzrh/items/1357a219b4a891a441ff)
[TerraformでIAMを設定してEC2にセッションマネージャー経由で接続してみる](https://qiita.com/kakita-yzrh/items/980f3209d587e7e349a6)
[Terraformでセキュリティグループを設定してEC2にhttp接続する](https://qiita.com/kakita-yzrh/items/6bdc11f2882c67a949ad)
[TerraformでS3とIAMロールを構築してEC2からS3にアクセスしてみる](https://qiita.com/kakita-yzrh/items/acc23e9aa1880fec3e38)

## IAMロールの変更
まず、

元記事を表示

【更新中】

# はじめに
東大が公開しているAWSのハンズオン資料をもとに、実際に勉強してみました。今年の夏は毎日本当に暑いので、せっかく家に長く居る時間、勉強しようと思います。
この記事では、ハンズオンの内容を自分の言葉で簡単にふりかえりつつ、つまずきポイントや感想をまとめようと思います。

# 資料
* [AWSによるクラウド入門](https://tomomano.gitlab.io/intro-aws/#_%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB)
* [【参考】Windows 10へNode.jsをインストールする](https://qiita.com/echolimitless/items/83f8658cf855de04b9ce)
* [【参考】AWS CDK version 2(Python)でインフラ環境を構築する手順](https://go-journey.club/archives/16796#AWS_CLI_%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%8

元記事を表示

EC2 Instance Connectエンドポイント経由でWindows ServerにRDP接続してみた

## EC2 Instance Connectの概要

– 略称はEIC。2023年6月のアップデートでエンドポイント機能が登場。
– エンドポイント機能を使うとプライベートサブネットにあるEC2インスタンスにssh/rdpで接続できる
– session managerと異なりssm agentのインストールとEC2インスタンス側のSSMへのアクセス権付与&ルーティング設定が不要で管理が楽

## 参考ドキュメントとイメージ図
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect-Endpoint.html

![](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/ec2-instance-connect-endpoint.svg)

## RDPの場合の設定手順

### インスタンス起動
– VPCとsubnetはすでにあるものとする。また、Microsoft Rem

元記事を表示

ほぼゼロコスト!AWSとSlackbotを使った勤務管理アプリを開発してみた

面倒くさい作業、自動化したくありませんか?(挨拶)

現在参画しているプロジェクトでは、毎月末にExcelの勤務表(勤務日の勤務時間を記入したファイル)を作成して提出しています。
ただでさえ忙しい月末の勤務終了後に作っているので毎回バタバタしちゃいます…

正直面倒くさい!…ということで夢を叶えてくれるSlackbotを作成しました。
リポジトリも公開しますので是非みてみてください!

https://github.com/aki-kii/workforce-buddy

::: note warn
プロジェクトの勤務表は基本的に社外秘です。
本記事でもサンプルテンプレートから勤務表を作成していますので、情報の扱いにはくれぐれもご注意ください。
:::
## Botの紹介
作成したのはSlackbot「勤務管理くん」です!
(※一般公開はしていません)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2703623/caa98128-dee1-d940-db24-e6c4181cb

元記事を表示

AWS CLIでEC2インスタンスを起動・停止する

## 概要
AWS CloudShell から コマンドライン(AWS CLI)で EC2 インスタンスを起動・停止します

### [AWS CloudShell](https://docs.aws.amazon.com/ja_jp/cloudshell/latest/userguide/welcome.html)
AWS が提供するブラウザベースのシェル環境です

### [AWS Command Line Interface (aws-cli)](https://aws.amazon.com/jp/cli/)
コマンドラインシェルを使用して AWS サービスとやり取りするためのオープンソースツールです
https://github.com/aws/aws-cli/tree/v2

## 環境
– AWS CloudShell
– aws-cli 2.13.3

## 手順の流れ
1. [EC2 インスタンスのステータス確認](#1-EC2-インスタンスのステータス確認)
2. [EC2 インスタンスの起動](#2-EC2-インスタンスの起動)
3. [EC2 インスタ

元記事を表示

【AWS】ECSタスクでHello World

## 使用するコンテナ
https://hub.docker.com/_/hello-world
コンテナを実行すると、以下のメッセージが出力されます。
“`
Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the “hello-world” image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently read

元記事を表示

AWS Glue でCodeWhispererがサポートされたので試してみた

# 背景・目的
[AWS Glue StudioでAmazon CodeWhispererをサポートされた](https://aws.amazon.com/jp/about-aws/whats-new/2023/07/aws-glue-studio-amazon-codewhisperer/)ので、試してみました。

:::note info
2023/7/30現在で、バージニアリージョンのみ提供となります。
:::

# まとめ
– Glue Studioのノートブックで利用が可能
– 2023/7/30現在、バージニアリージョンのみ提供

# 実践
## 前提
### IAMロールの作成
1. IAM画面で、「ロールを作成」をクリックします。
1. IAMポリシーの追加画面で、①「AWSGlueServiceNotebookRole」を選択し、②「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/ec8418de-1648-b678-92

元記事を表示

Lambdaで「libcrypt.so.1: cannot open shared object file: No such file or directory」を解消

# はじめに

今回の記事は、Ruby3.2でLambdaを使用しようとしたときに、「/var/lang/bin/ruby: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory」というエラーが出たので、”**力業**”で解消したときのお話です。もしかしたらRubyでも[こちら(Pythonです)](https://github.com/keithrozario/Klayers)のように、出来上がったレイヤーを配布しているかもしれませんので、お時間ある方は探してみてください。

# なぜエラーがでたのか?

Lambdaでは最近Rubyの3.2のランタイムが提供されるようになりました。しかし、Rubyのランタイムが依存しているLinux依存のライブラリまでは網羅されていないため、見つけることができずタイトルにあるエラーが出てしまいました。

# どのように解消したのか?

別の環境でライブラリをLambdaのレイヤーとし

元記事を表示

ConftestをCodeBuildで実行

# はじめに
CFnテンプレートをチェックできるConftestについて、以前記事にしました。

https://qiita.com/a_b_/items/994f5eec5a415ed57269

これをCodeBuildの中で使ってみようと思います。CodeBuildの簡単な使い方は以下になります。

https://qiita.com/a_b_/items/80cb3fe41b4efec1a271

# やってみた

## 環境

CodeBuild周りの環境は、以前作ったCFnテンプレートをそのまま用います。

https://qiita.com/a_b_/items/80cb3fe41b4efec1a271#cfn%E3%81%A7%E4%BD%9C%E3%82%8B

## ファイル

以下の3ファイルを作成します。

– sampleCreateRole.yaml
– policy/rolePolicy.rego
– buildspec.yml

まずはREGOファイルです。
“`rego:policy/rolePolicy.rego
package main
imp

元記事を表示

Descheduler for KubernetesでPod(レプリカ)の再スケジュールを促す

# この記事の目的
WorkerNode上で起動するPod(レプリカ)数の偏りを自動的に解消するためにDescheduler for Kubernetesを導入したお話をざっくりと書いて残しておきます。

# 前提
Descheduler for Kubernetesのバージョンは0.26.1です。
次のGitHubリポジトリに記載されている手順に従ってデプロイします。
https://github.com/kubernetes-sigs/descheduler

5分間隔でJob Podを作成して処理が終わったら捨てたかったので私はCronJobを選びました。
`kustomize build ‘github.com/kubernetes-sigs/descheduler/kubernetes/cronjob?ref=v0.26.1’ | kubectl apply -f -`

# Deschedulerをどのような場面で効かせたかったか
– とあるWorkerNodeが障害によってダウンし、新しいWorkerNodeをクラスタに追加したとき
– シンプルに新しいWorkerNo

元記事を表示

AWS Public IPv4 Address有償化に向けて、全AWSアカウントの公開IP一覧を出す

2024年2月より、公開用のIPv4アドレス(elastic ip含む)が1つ約500円/月の有償化が決まりました。

# すべてのPublic IP利用を抽出
`AWS Config Advanced Query`が便利です
スコープをaws_allにして、

“`sql
SELECT
accountId,
configuration.association.publicIp,
configuration.interfaceType,
availabilityZone,
resourceId,
tags,
configuration
WHERE
resourceType = ‘AWS::EC2::NetworkInterface’
AND configuration.association.publicIp > ‘0.0.0.0’
ORDER BY
accountId,
configuration.interfaceType
“`

# EIPだけ抽出

公開用ipはEIPだけではないものの、EIPもそれなりの量になります。
全A

元記事を表示

AWSのRHELのmanコマンドを日本語化する

以下のページにアクセスする。
https://linuxjm.osdn.jp/download.html

全体のアーカイブから最新のアーカイブファイルへのリンクを右クリックし、リンクのコピーをする。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3502854/6ec27aec-c614-4488-ea63-adfcac59a27c.png)

以降はAWSのRHELにSSH接続後のコマンドライン上での操作。

rootにスイッチする。
~~~shell
sudo su –
~~~

curlコマンドで先ほどコピーしたリンク先からアーカイブファイルを取得。(例はコピーしたリンク先が右記だった場合の例:https://linuxjm.osdn.jp/man-pages-ja-20230715.tar.gz)
~~~shell
curl -O https://linuxjm.osdn.jp/man-pages-ja-20230715.tar.gz
~~~

tarコマンドでアーカイブファイ

元記事を表示

Patch Manager 本番・検証環境で時間を分けて自動パッチ適用をしてみた

# はじめに

AWS Systems Manager に、Patch Manager と呼ばれる自動パッチ適用を提供してくれる機能があります。AWS 上はもちろん、オンプレミス側のマシンも含めたパッチ適用の自動化と管理ができます。なお、Patch Manager は、パッチファイルそのものを提供してくれるわけは**ありません**。rpm や Windows Update で利用するパッチファイルは、OS が参照している先から利用します。通常はインターネットで公開されている Amazon Linux の Repository などから取得する考え方になります。

今回の記事は、「本番環境」と「検証環境」の 2 環境が 1 AWS アカウントにあるときに、先に「検証環境」に適用して、一定時間後に「本番環境」に適用する手順を確認します。いきなり「本番環境」に適用してしまって問題を発生させたくないので、安全をみて「検証環境」から先にパッチ適用をします。

# 本番・検証環境用の BaseLine を用意

本番環境と検証環境で、対象とするパッチ基準をそれぞれ用意したいので、Baselin

元記事を表示

OTHERカテゴリの最新記事