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

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

Amazon EKS 上でKarpenter + HPA のスケーリングの動作を確認する

# はじめに

本記事は、[Amazon EKS](https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/what-is-eks.html) 上でNode のオートスケーラーである[Karpenter](https://aws.amazon.com/jp/blogs/news/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) とPod のオートスケーラーである[Horizontal Pod Autoscaler(HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) を組み合わせたスケーリングの動作を確認をした際の作業メモです。

主に、次の2点について記載しています。
– 動作確認をした環境の構築手順
– 簡単なスケーリングの動作確認

Karpenter と HPA を導入する際の参考になれば幸いです

元記事を表示

初心者がわかるVPCとは?

## VPCとは

一言で言うと自分用のバーチャルなクラウド環境。

## VPC の規模感

AWS > Region > Availability Zone > VPCといった感覚。

![https://i.gyazo.com/13207fb617b6f7184b9092cd8e74c10c.png](https://i.gyazo.com/13207fb617b6f7184b9092cd8e74c10c.png)

### Region(リージョン)

– 地理的に独立したAWSのリソース群。
– Regionの中ごとにいろんなサービスが存在している。
– Regionごとに存在しているサービスが違う。

### AvailabilityZone

– 冗長的な電力源・ネットワーク・接続機能を備えているデータセンター。
– Regionの中で切り離されて分離している。
– 例えばAvailabilityZone Aが潰れてもAvailabilityZone Bがあれば大丈夫。

### VPC

– Regionに属していて複数のAvailabilityZoneにまたがっている

元記事を表示

AWS クーポンの適用方法

AWSからクーポンコードをいただいたのだが、公式サイトの手順とクーポン適用画面のUIが変更されていて戸惑ったのでメモ

下記の公式サイトを参考に適用する

https://aws.amazon.com/jp/apply-coupon/

# 前提条件
クーポンを適用するAWSアカウントにログインしていること

# クーポン適用手順

1. 画面右上のアカウント名をクリックして、`請求ダッシュボード`をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1719666/2e71dc9c-67c5-9055-f1d9-91e4917e47e7.png)
1. 画面左の`クレジット`をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1719666/89372adc-dcf9-3cef-4889-eacbf7951979.png)
1. 画面中央の`クレジットを適用`をクリック

元記事を表示

ECSハンズオンをやったメモ

# はじめに

今どきの新人は新人研修でコンテナ周りの扱いを一通りやって簡単なサービスを作るところまで行くらしい。
いいなぁ新人は。僕は教えてくれる人がいないから自分で勉強するしかない。
ハンズオンという良い勉強資材があるらしい。

https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-hands-on/

今回はこれをやりました。

https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-ECS-2022-reg-event.html?trk=aws_introduction_page

# ECRでリポジトリ作る
WebコンソールでECRのページにいく。左のメニューからリポジトリを選択。
リポジトリを作成→リポジトリ名を記入してそのまま作成。
URIをコピーしておく。12ケタ.dkr.ecr.ap-northeast-1.amazonaws.com/h4b-ecs-helloworldという風になってるはず。

# Cloud9で作業
Cl

元記事を表示

AWS SSOを使ってSonarQubeにSAML認証でログインする

IAM Identity Center(旧AWS SSO)でSonarQubeをアプリケーション登録する手順を確認した時のメモ。
作業手順としては以下のようになる。
1. AWSで雛形のアプリケーションの作成
2. SonarQubeの設定変更
3. AWSで残りのアプリケーション設定

なお、SonarQubeは構築済みであることが前提となる。

## AWS側作業その1
IAM Identity Centerからアプリケーションの割り当ての中のアプリケーションを選択し、「アプリケーションの追加」をクリックする。\

「事前統合アプリケーション」でSonarQubeを入力し、出てきたものをクリックして次へを押す。\
「アプリケーションを設定」の表示名と説明を好きなもので埋めて一旦SonarQubeに移動する。

## Son

元記事を表示

IAM の Switch Role の設定方法

アカウントが増えてくると、それぞれのアカウントでどうやって効率よくサインインするか、ということが問題になります。

Single Sign On はひとつの手段でしょうが、Switch Role 機能を利用するのもよいと思います。

ここでは、ひとつのアカウントから、他のアカウントに Switch Role する方法を述べます。
他のアカウントが、3つあるとします。

Switch Role 元のアカウントで作成するポリシー(Development グループにアタッチ)
ポリシー名:OrganizationAccountAccessRoleDevAssumePolicy

“`
{
“Version”: “2012-10-17”,
“Statement”: {
“Effect”: “Allow”,
“Action”: “sts:AssumeRole”,
“Resource”: [
“arn:aws:iam:::role/OrganizationAccountAccessR

元記事を表示

AWS LambdaのPythonアップデート手順について

# はじめに
LambdaにおけるPython3.6のサポート終了についてAWSから通知があり、
Python3.6からPython3.9にアップデートする必要がありました。
アップデート作業の備忘として、AWSコンソールでの操作手順をまとめてみました。

# アップデート対象の確認

AWSコンソールにログインし、Lambdaの関数一覧画面に遷移します。
「ランタイム」欄に使用している言語のバージョンが表示されています。
今回はPython3.6を使用している「cwlog_S3export」を例に記載します。
![Lambda_update1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2740559/d5f4167f-1fb7-d6a5-bebc-0eb5badec70f.png)

# アップデート作業

関数名を押下し、関数の詳細画面を表示します。
デフォルトで「コード」タブが表示されており、最下部にスクロールすると「ランタイム設定」欄が表示されます。
「ランタイム設定」欄の「編集」を押下し、

元記事を表示

module化したterraformをfor eachでリファクタリング →moved block で再作成防ぐ

前提:module化してある
概要:再作成防ぐ楽な方法ないのか模索
①for eachのリファクタリングで関連するリソースをすべてmoved blockで定義 → 王道
②module 名を無理やり変えてmoduleで作成されるリソースはすべてmovedで切り替えるといった手法を取る → 楽にできたら神
https://www.terraform.io/language/modules/develop/refactoring#enabling-count-or-for_each-for-a-module-call
結論:結局①に落ち着いた

### 本編

#### module側
変更前
“`
“`

変更後
“`
resource “aws_efs_file_system” “a-efs” {
for_each = var.efs-list
encrypted = true
performance_mode = “generalPurpose”
throughput_mode = “bursting”
tags = {

元記事を表示

Lambdaのレイヤーの参照方法

Layerに配置したファイルは `/opt`で参照可能。
試しに表示してみる。

Google fontから[Noto Sans Japanese](https://fonts.google.com/noto/use#how-are-noto-fonts-organized)をダウンロードし、`.font.zip`にしてLayerにアップロード。
Lambda側でLayer参照の設定をしてから以下を実行

“`js
const fs = require(‘fs’);

exports.handler = function(event, context){
fs.readdir(‘/opt/’, function(err, files){
console.log(files);
context.done(null, err);
});
}
“`

Cloud Watchに以下のように出力される
“`
[ ‘.font’ ]
“`

さらに`.font`ディレクトリの中身を表示してみる
“`js
const fs = requir

元記事を表示

第4回 The Twelve-Factor App on AWS & Django(AWSのアカウントを作成しよう)

# 目次
– [第1回 The Twelve-Factor App on AWS & Django(The Twelve-Factor Appとは)](https://qiita.com/satsuma0711/items/3b928d0e5670a633f9d8)
– [第2回 The Twelve-Factor App on AWS & Django(バックエンドAPIを作ろう)](https://qiita.com/satsuma0711/items/850d57ad1557d0f8dddb)
– [第3回 The Twelve-Factor App on AWS & Django(フロントエンドSPAを作ろう)](https://qiita.com/satsuma0711/items/67d35253a237c976415f)
– 第4回 The Twelve-Factor App on AWS & Django(AWSのアカウントを作成しよう) ← 今回

# はじめに
[前前回](https://qiita.com/satsuma0711/items/850d57ad15

元記事を表示

AWS入門用にEC2-ApacheでHP公開してからやったこと

# AWS入門用にEC2-ApacheでHP公開してからやったこと

## 記事の内容

[初めてEC2を触ってみたので手順をまとめた](https://qiita.com/gnk263/items/27323fe3103a2a59ba27)
こちらの記事を参考にEC2でApacheを起動し簡単なページを表示した後にやったことをまとめた。

## 目的

セキュリティを強化する。
勉強用にいくつかのサービスを触ってみる。

## 背景

業務系アプリケーションエンジニアが私用で簡単なHPを公開する必要があった。
加えて近日中にCertified Cloud Practitioner 認定を受験する予定だが、似たような名前のサービスが多く覚えるのが大変だったため、勉強がてらAWSで環境構築することにした。
静的WEBサイトの公開だけならS3でもできるが、本業がwebアプリのSEなので、後学のためApacheで公開した。
– __できるだけプラクティスに沿ったものの、あくまで勉強用ということで、そのまま本番環境で使う類のものではないことをご理解ください。__
– __料金はよく確認し

元記事を表示

ECS上で運用中のシステム向け、メンテンナンスモード導入

## 入る前に
こんにちは:) アプリケーションエンジニアのキムです。
今日は現在チームで運用中のECS Fargateベースのシステムに新たにメンテモードを作った経験談を残してみたいと思います。
この機能については、すでに様々な方法が存在して、たくさんいろんな方法を導入して運用してると思います。
今回案内する方法は、その中のただ一つの方法に過ぎないと思います。
このような方法を選択して運用してるところもあるんだーレベルでの受け入れでお願いします。

## 前提条件
現在、私と私たちのチームが運用中のサービスの場合、基本的にはメンテナンスモードがあえて存在する必要がない構造です。
今回このような作業を行うことになった背景は、当サービスより上位にあるサービスが一定期間ベースでメンテナンス作業を行っていますが、その際、影響を受けるいくつかの状況が発生したため、当チームでもその対応が必要となりました。
そのため、巨大なサービス、アプリケーションに比べて比較的簡単に作業できる方法を採用したことを予めお知らせします。

## システム運用状況
![image.png](https://qiita

元記事を表示

AWS Direct Connect ゲートウェイとは

## オンプレミスとAWS VPCを接続するもの
ひとつのVIFを用いたプライベート接続で世界の全リージョンの複数のVPCと閉域で通信することができる。

追加の費用は不要であり無料で利用することができる。ロケーションと同一リージョンへの通信の遅延などは心配はありません。

複数のデータセンターをDXGWに接続することはできるがDXGWを経由して他のデータセンターへ繋ぐことはできない。
※日本拠点DRMC→DXGW→シンガポール拠点DC
×これはできないよ。

## Direct Connectのパートナー経由のタイプ
パートナの提供サービスは(占有型・共有型)の二つがあります。

・占有型
connectionははお客様へお渡しするもの、その中で自由でVIFを設定することができます。
物理帯域は1G,10Gを占有しているのでVIFはシェアする形になります。
帯域制御が必要な場合はそれは顧客側の機器で実現する。

・共有型
connectionはパートナーが所有している。パートナーの機能拡張で、帯域保証型でベストエフォートが様々である。

またAWSが認可しているパートナー制度もあり、

元記事を表示

Security Hub の AWS Foundational Security Best Practices を眺めた感想

# はじめに
Security HubのルールのAWS Foundational Security Best Practicesの内容を眺める機会がありました。
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html
こういうルールがあるのかぁと意識できていなかった部分もあるので、それらを中心に感じた分類分け書いてみます
なお、セキュリティ要件やシステム要件と照合し、適切に設定することが本筋ではあるので、一旦、個人の感想と思ってもらえればと思います。

# 書く内容
ルールを個人的な観点として以下3個にグループ化してみました。

– だいたい組み込んでいるんじゃないか系
– あんまり意識されていなくてやってないんじゃないか系
– へぇこれもベストプラクティスに含まれるんだ系

またこれらに分類されていないものは特段コメントはいらないかな、と思ったものです。
主に含めていないものは、暗号化、パブリックIPやパブリックセグメントへの配置、

元記事を表示

【AWS】Cognitoのユーザープール作成後にカスタム属性が消えたお話

概要
以前インフラエンジニアとして働いていた現場での出来事。アプリチームからの依頼でCognitoのユーザープールを作成。アプリチームに引き渡し、帰ったらゲームをしようと思いながら休んでいたら…

アプリチーム「ユーザープールのカスタム属性1つ足りなかったので追加してください」
自分「ごめんなさい、今すぐ追加しますorz」

こんな感じでユーザープール作成時にカスタム属性を1つ入れ忘れミスしちゃったーと思いつつ、心の中のもう1人の自分がこんな事を思っていた。

「いや、そのカスタム属性の設定した記憶があるぞ…」

思い立ったが吉日、Slackでそのカスタム属性を検索すると、、以前にも同じカスタム属性が足りないとアプリチームから指摘されている人を発見!
これは単なるヒューマンエラーじゃないと思い検証の結果、とある条件下においてCognitoのユーザープール作成後にカスタム属性が消える現象を確認したので以下に記す。

環境・条件
・AWS Console (CLIは試してないです)
・AWS Cognitoのユーザープール作成時
・標準属性として存在する属性をあえてカスタム属性として設定し

元記事を表示

AWSのDBの種類まとめ(LTの記事起こし)

[JAWS-UG 朝会 #33](https://jawsug-asa.connpass.com/event/240120/) で DB の種類についてのまとめ LT をしました。
資料は公開していますが、LT内で喋った内容の補足を含めて記事公開します。
(だいぶ期間空いてしまいましたが…)

## はじめに

### この記事で紹介する内容について

前述の通り、 [JAWS-UG 朝会](https://jawsug-asa.connpass.com/) でお話しした内容の補足記事です。

AWSのDBそれぞれについて、1枚絵レベルで説明していきます。

なお、この整理は [AWS エバンジェリストシリーズ AWSの基礎を学ぼう](https://awsbasics.connpass.com/) での学びの復習を目的としたものです。これに興味を持った方は、こちらの受講もお奨めします。

登壇時の資料は、こちらから確認できます。

https://twitter.com/98lerr/status/1523813119088152576?s=20&t=QiiAHAhY

元記事を表示

[社内勉強会資料] CloudFormationで構築する自動デプロイ環境 ~ 6/6

# 第6回 終わりに(自動デプロイの動作確認と作成したリソース削除)
第6回は、自動デプロイの動作確認と作成したリソース削除について記述します。
それからオープントーンで行った卒業試験について説明します。

前回:[[社内勉強会資料] CloudFormationで構築する自動デプロイ環境 ~ 5/6](https://qiita.com/toru-yamagishi/items/52e1d2719edbefdcc73e)

## 自動デプロイの動作確認
1. デプロイ前のWebページを確認します。
– 自動デプロイが完了したら、AWSマネジメントコンソールから、EC2の画面へ移動します。
– 左メニューから「ロードバランサー」を選択します。
– fargate.yaml実行時に作成したALBを選択して、「DNS名」をコピーします。
– コピーしたDNS名のURLにアクセスして画面を表示し、Hello Worldが表示されていることを確認します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com

元記事を表示

[社内勉強会資料] CloudFormationで構築する自動デプロイ環境 ~ 5/6

# 第5回 CloudFormationテンプレートの実行(CodePipeline)
さて第5回の今回は、本記事に記載のCloudFormationテンプレートを用いて、自動デプロイ(CodePipeline)を構築していきます。

前回:[[社内勉強会資料] CloudFormationで構築する自動デプロイ環境 ~ 4/6](https://qiita.com/toru-yamagishi/items/801612fd72347e98bcd7)

## CloudFormationで作成するリソース
* CloudFormationテンプレートを使って、以下のAWSリソースを作成します
* IAM
* Role
* S3
* Bucket
* CodePipeline
* CodeBuild

## CloudFormationテンプレート
### deploy-backend.yaml
“`yaml
AWSTemplateFormatVersion: “2010-09-09”
Description: “Buil

元記事を表示

[社内勉強会資料] CloudFormationで構築する自動デプロイ環境 ~ 4/6

# 第4回 CloudFormationテンプレートの実行(IAM)
さて第4回の今回は、本記事に記載のCFnテンプレートを用いて、自動デプロイの実行に必要な権限(IAMロール)を構築していきます。

前回:[[社内勉強会資料] CloudFormationで構築する自動デプロイ環境 ~ 3/6](https://qiita.com/toru-yamagishi/items/c9a2d877a5de553a4c4f)

## CloudFormationで作成するリソース
* CloudFormationテンプレートを使って、以下のAWSリソースを作成します
* IAM
* ManagedPolicy
* S3
* Bucket

## CloudFormationテンプレート
### policy.yaml
“`yaml
AWSTemplateFormatVersion: “2010-09-09”
Description: “Policy for pipeline works”

Parameters:
ProjectName:

元記事を表示

[社内勉強会資料] CloudFormationで構築する自動デプロイ環境 ~ 3/6

# 第3回CloudFormationテンプレートの実行(ECS)
さて第3回の今回は、本記事に記載のCloudFormationテンプレートを用いて、自動デプロイのデプロイ先となるECSとECRを構築していきます。

前回:[[社内勉強会資料] CloudFormationで構築する自動デプロイ環境 ~ 2/6](https://qiita.com/toru-yamagishi/items/580f49d158aecfc52473)

## CloudFormationで作成するリソース
* CloudFormationテンプレートを使って、以下のAWSリソースを作成します。
* ECR
* ALB
* Listener
* TargetGroup
* ECS
* Cluster
* Service
* TaskDefinition
* IAM
* Role
* CloudWatch
* LogGroup

## CloudForma

元記事を表示

OTHERカテゴリの最新記事