- 1. TerraformによるS3バケット管理とライフサイクルの最適化
- 2. EC2とRDSでWeb環境構築するよ！（第２回：EC2編）
- 3. AWS CLOUD PRACTIONERの資格修得のための勉強の方法
- 4. KEDAを使用してEKSのAutoScalingを組む
- 5. aws cliでS3バケット内の全オブジェクトの情報を取得する
- 6. EC2とRDSでWeb環境構築するよ！（第１回：VPC編）
- 7. 【AWS】Elastic Load BalancingとAuto Scalingの連携による効果的なトラフィック分散
- 8. AWS Cloud Practitioner取ったけど何も理解してない話
- 9. 【AWS】インスタンスタイプ 〜スポット、リザーブド、オンデマンド、専有の比較〜
- 10. 【AWS】デッドレターキュー 〜失敗したメッセージを管理する方法〜
- 11. 【AWS】S3 Intelligent-Tieringの概要
- 12. Amazon EventBridgeについて整理してみた
- 13. CloudFormationで起動テンプレートを使用したインスタンス作成時の注意点
- 14. 【初めてのAWS】チームの勤怠管理システムを作ってみた（その２）
- 15. Cloud9で作成したDjangoをコンテナイメージ化してECRにpushする
- 16. Amazon QuickSightを用いて社内SEの貢献・負荷を可視化してみた。
- 17. AWS APIGateway(HTTP API)とCognitoを統合
- 18. S3バケットに保存したログを NewRelic へ転送する
- 19. インフラエンジニアさんに手引してもらいながらlambdaのIP固定化をやってみたときのメモ（NATゲートウェイ不使用）
- 20. AWS Certified Solutions Architect – Associate
TerraformによるS3バケット管理とライフサイクルの最適化
最近、手動で作成された既存のS3バケットをTerraformの管理下に置いて、ライフサイクルポリシーを設定したので、そのときのメモを残します。
# 手順
## ステップ1: Terraformリソースの定義
既存のS3バケットをTerraformリソースとして定義します。以下は`example-dev`という名前の開発用バケットの設定例です。“`hcl
resource “aws_s3_bucket” “example_dev” {
bucket = “example-dev”tags = {
Environment = “dev”
}
}
“`## ステップ2: ライフサイクルポリシーの設定
次に、バケットのデータに対するライフサイクルポリシーを設定します。このポリシーは、データを30日後に`STANDARD_IA`ストレージクラスに移行し、90日後に削除するよう設定します。“`hcl
resource “aws_s3_bucket_lifecycle_configuration” “example_dev_lifecycle” {
EC2とRDSでWeb環境構築するよ！（第２回：EC2編）
EC2とRDSのWeb環境構築の第２回目です。
第１回：VPC編はこちら
https://qiita.com/kikurage2030/items/1b30272cb15033f2ca11## サービスの全体象
作りたいサービスの概要はこんな感じです。
EC2にWebサーバを立ててPHPのプログラムがMySQLにアクセスしてテーブルの情報を表示する画面を作ります。
いわゆる一般的なWebシステムの構成でWebサーバはPublicサブネットに公開し、DBサーバはPrivateサブネットでEC2のみのアクセスを許可する制御とします。このシリーズで取り組む内容は
第１回：VPC・サブネット周りの作業
第２回：EC2の構築 ここ！
第３回：ドメインの登録
第４回：RDSの構築
第５回：Web環境の構
AWS CLOUD PRACTIONERの資格修得のための勉強の方法
## AWS cloud practitionerの資格を取る最も確実な方法
1. AWS training centerの６時間の教育を受け取ること:
AWS Training Centerでは、AWS Cloud Practitionerの基礎知識を習得するための6時間の集中トレーニングが提供されています。このトレーニングでは、クラウドコンピューティングの基本概念やAWSサービスの概要など、試験範囲に必要な知識を習得することができます。教育プログラムの完了後、AWSの基本的な概念について理解を深めることができます。1. UDEMYのAWS cloud practitioner模擬試験を２回繰り返す：
UDEMYで提供されているAWS Cloud Practitioner模擬試験は、試験の形式や内容に沿った実践的な学習を提供します。2回繰り返すことで、問題の形式や解答方法を理解し、試験に対する自信をつけることができます。また、無料で利用できる別のサイトよりもUDEMYの方が信頼性が高く、質の高い模擬試験を提供しています。1. それでもクラウドや模擬試験の概
KEDAを使用してEKSのAutoScalingを組む
# 記事概要
EKSにてKEDAを利用してAutoScalingをCloudWatchMetricsをもとに組む# 対象読者
– EKSを使用してAutoScalingが組みたい
– KEDAを使用したサービスを作りたい# KEDAを使用したスケーリング
## 前提条件
– EKSのバージョンが1.29
– EKSにて[アプリケーションロードバランサー](https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/alb-ingress.html)が実装されている
– [Metrics Server](https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/metrics-server.html)が実装されている
– [クラスターオートスケーラー](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)が実装されている## 構築
aws cliでS3バケット内の全オブジェクトの情報を取得する
# はじめに
S3バッチオペレーションを試したいなーと思ったのですが、インプットに以下の形式のcsvが必要なようでした。> CSV 形式のマニフェスト（バージョン ID なし）の例を以下に示します。
> Examplebucket,objectkey1
> Examplebucket,objectkey2
> Examplebucket,objectkey3
> Examplebucket,photos/jpgs/objectkey4
> Examplebucket,photos/jpgs/newjersey/objectkey5
> Examplebucket,object%20key%20with%20spaces
>
> バージョン ID を含む CSV 形式のマニフェストの例は次のとおりです。
> Examplebucket,objectkey1,PZ9ibn9D5lP6p298B7S9_ceqx1n5EJ0p
> Examplebucket,objectkey2,YY_ouuAJByNW1LRBfFMfxMge7XQWxMBF
> Examplebucket,objec
EC2とRDSでWeb環境構築するよ！（第１回：VPC編）
AWSは部分的にこれまでもちょこちょこ仕事で弄ってきたけど体系的にメジャーサービスを構築したことがなかったのでEC2やRDSを使ったWeb画面（PHP）を構築してみたのでメモ。
## サービスの全体象
作りたいサービスの概要はこんな感じです。
EC2にWebサーバを立ててPHPのプログラムがMySQLにアクセスしてテーブルの情報を表示する画面を作ります。
いわゆる一般的なWebシステムの構成でWebサーバはPublicサブネットに公開し、DBサーバはPrivateサブネットでEC2のみのアクセスを許可する制御とします。このシリーズで取り組む内容は
第１回：VPC・サブネット周りの作業
第２回：EC2の構築
第３回：ドメインの登録
第４回：RDSの構築
第５回：Web環境の構築
を予定しています。今回は第一回：VPC編となります。
【AWS】Elastic Load BalancingとAuto Scalingの連携による効果的なトラフィック分散
# はじめに
AWS上でWebアプリケーションを運用する際、トラフィックの変動に合わせて、サーバーリソースを自動的にスケールさせることが重要です。そこで活躍するのが、**Auto Scaling**です。さらに、Auto Scalingと連携することで、トラフィックを効果的に分散できるのが**Elastic Load Balancing (ELB)**です。本記事では、ELBとAuto Scalingを組み合わせることで、どのように**トラフィックを最適に分散**できるのかを解説します。# Elastic Load Balancingの役割
### 1-1. トラフィックの分散
ELBは、**複数のEC2インスタンスに対して、トラフィックを自動的に分散する機能**を持っています。これにより、特定のインスタンスに負荷が集中することを防ぎ、アプリケーションのパフォーマンスを維持できます。### 1-2. ヘルスチェック
ELBは、各インスタンスに対して定期的にヘルスチェックを行います。異常が検知されたインスタンスには、トラフィックを送信しません。これにより、サービスの可用性を高
AWS Cloud Practitioner取ったけど何も理解してない話
# 1週間くらいでAWS Cloud Practitionerに合格できました！
でもタイトルの通り全然理解出来てません。;;
点数もギリギリだったし
逆にあんまよく分かんなくっても合格できるということでこれから受ける方はなんとなくで頑張ってください！## やったこと
前提としてAWSの実務経験、知識は何もありません。クラウドってすごそーて感じでした。
1. [AWS認定クラウドプラクティショナー(改訂第2版)](https://www.amazon.co.jp/-/en/gp/product/B0C73QX2CT/ref=ppx_yo_dt_b_d_asin_title_351_o03?ie=UTF8&psc=1)1. Udemy 【CLF-C02版】この問題だけで合格可能！AWS 認定
【AWS】インスタンスタイプ 〜スポット、リザーブド、オンデマンド、専有の比較〜
# はじめに
AWSは、ユーザーのニーズに合わせて選べる様々なインスタンスタイプを提供しています。それぞれのインスタンスタイプには、メリットとデメリットがあり、使用目的に応じて適切に選択することが重要です。ここでは、スポットインスタンス、リザーブドインスタンス、オンデマンドインスタンス、専有インスタンスの概要を説明し、それぞれの使い分け方を表にまとめました。# 1. スポットインスタンス
### 概要
スポットインスタンスは、AWSの未使用の計算容量を利用して、オンデマンド料金よりも最大90％割引で利用できるインスタンスです。ただし、AWSがキャパシティを必要とする場合、2分前の通知で中断される可能性があります。
### メリット
– オンデマンド料金と比較して、最大90％の割引で利用できる
– 柔軟なインスタンスタイプとサイズを選択可能
– 中断の可能性を考慮して設計されたワークロードに適している### デメリット
– インスタンスが中断される可能性がある
– 長期的な運用には向かない
– 中断による影響を最小限に抑えるためのシステム設計が必要# 2. リザーブドインス
【AWS】デッドレターキュー 〜失敗したメッセージを管理する方法〜
# はじめに
分散システムにおいて、メッセージキューは重要な役割を果たします。しかし、メッセージの処理が失敗することがあります。そこで、デッドレターキュー (DLQ) の出番です。DLQは、**処理できないメッセージを一時的に保存する**特別なタイプのメッセージキューです。この記事では、DLQの仕組み、利点などについて説明します。# デッドレターキューとは？
デッドレターキューは、通常のメッセージキューと並んで存在し、**エラーを含むメッセージや、宛先が指定されていないメッセージを格納**します。受信者が送信メッセージへの応答またはその処理に失敗した場合、ソフトウェアはそのメッセージをDLQに移動します。これにより、通常のキューがブロックされるのを防ぎます。# デッドレターキューの利点
– **通信コストの削減**：失敗しているメッセージについては有効期限が切れるまで処理を試みるより、数回試行した後にDLQに移動する方がよいでしょう。
– **トラブルシューティングの改善**：誤ったメッセージをDLQに移動すると、デベロッパーはエラーの原因の特定に集中できます。# デッドレ
【AWS】S3 Intelligent-Tieringの概要
# はじめに
クラウドストレージを使う上で、コストパフォーマンスは重要な要素です。**Amazon S3 Intelligent-Tiering** は、オブジェクトへのアクセスパターンを自動的に監視し、最適な階層に移動させることで**コストを最小限に抑える**賢いストレージクラスです。# 自動アクセス階層
S3 Intelligent-Tiering には、以下の3つの自動アクセス階層があります。### 高頻度アクセス階層
頻繁にアクセスされるオブジェクトに使用され、低レイテンシーと高スループットを提供します。
### 低頻度アクセス階層
**30日間アクセスされないオブジェクトが自動的に移行**されます。高頻度アクセス階層と同等のパフォーマンスを保ちつつ、コストを抑えられます。
### アーカイブインスタントアクセス階層
**90日間アクセスされないオブジェクトが自動的に移行**されます。低レイテンシーと高スループットを維持しながら、さらにコストを削減できます。# オプションの階層
S3 Intelligent-Tiering には、以下の2つのオプションの階層があり
Amazon EventBridgeについて整理してみた
# 背景・目的
EventBridgeについて、過去に使用したことはあり、何となくわかったつもりのため、知識として整理したいと思います。# まとめ
下記に特徴を整理します| 特徴 | 説明 |
|:–|:–|
|概要|・イベントを介したアプリケーション同士を接続するサーバレスサービス
・イベント駆動型アプリケーションを構築できる|
|EventBridgeのメリット|イベント駆動型アーキテクチャにより、下記が期待できる
・俊敏性を高い
・信頼性が高い
・スケーラブル|
|可能なこと|ソースからのイベントをルーティングできる
・イベントの取り込み
・フィルタリング
・変換
・配信|
|処理方法|・イベントバスとパイプの2つがある
・併用も可能|
|EventBus|・イベントを受信するルーター
・ゼロ個以上の送信先やターゲットに配信。
・イベントをさまざまなソースから多数のターゲットにルーティング
・オプションでターゲットに配信する前にイベントを変換する必要がある際に使用|
|イベント|・単純なイベントは
CloudFormationで起動テンプレートを使用したインスタンス作成時の注意点
# この記事を読んでもらいたい人
AutoScalingサーバをCloudFormation(以下CFn)で作成しようとしている人。# 留意事項・前提
下記に記載する話は、AutoScalingサーバ作成時に限った話ではないですが、一例としてAutoScalingサーバを扱います。CFnを利用して起動テンプレートからEC2を起動する場合も同様のはずです。
また、下記に記載する方法でないといけないことはなく、あくまで一例になります。# この記事で伝えたいこと
AutoScalingGroupと起動テンプレートを同じファイルで記述したほうが良い。
AutoScalingGroupと起動テンプレートを分けて記載すると大変なのでやめる。# テンプレートを分けた場合
LaunchTemplateとAutoScalingGroupを別々のテンプレートで記載した場合、下記のような記載方法になります。
※LaunchTemplateはAMIIDを指定するものとします。“`LaunchTemplate.yaml:
AWSTemplateFormatVersion: “2010-09-
【初めてのAWS】チームの勤怠管理システムを作ってみた（その２）
# 1. 初めに
勤怠管理システムの全貌としては以下の3つである。3本に分けて残していく。今回はその２！
[その１：名前を選択して「出勤」or「退勤」ボタンを押し、記録する](https://qiita.com/waiiioss/items/6c2ca747a55d3dca9224)
その２：勤怠記録のデータを可視化する <--IMAKOKO その３：過去の勤怠を編集できるようにする **本Qiitaの内容** * LambdaからDynamoDBのデータ取得 * 可視化手法 今回はJSが大きく絡んでくる # 2. Lambda関数からDynamoDBのデータ取得 前回作ったDynamoDBでアクセスして、データを取得するためのコードを書く。今回のコードは引数にユーザーのインプットがあるわけではなく、データベースにある情報を全て取ってくるというモノなので、特に面白いことはない。 淡々と書こう。当然だけど文字列と数値の扱いは気をつけよう！ロールの付与も当然しよう！Lambda関数->設定->アクセス権限でロール名と書いてあるところからロールの管理をする。前回書いたハンズオンをやって
Cloud9で作成したDjangoをコンテナイメージ化してECRにpushする
こんにちは。
株式会社クラスアクト インフラストラクチャ事業部の大塚です。前回Cloud9(Django) + S3 + SQS + Lambda + SNSの環境を構築し、Djangoで作成したWebアプリケーションを経由してS3にデータをアップロードすると、SNSで登録しているメールアドレスに通知が飛ぶ環境を作成しました。
環境は以下のようなイメージです。
この環境の構築手順は以下となります。[1]から順番に見て頂ければ同じ環境を作れるはずです。
https://qiita.com/ohtsuka-shota/items/db74a418dabc261d9126
今回はCloud9で作ったDjango環境をコンテナイメージに変換し、それをECRにpushしていきたいと思います。
この次の記事
Amazon QuickSightを用いて社内SEの貢献・負荷を可視化してみた。
# :tent: 背景
1. 弊社では生産性管理ツールを導入しているが、いまいち活用されていない
2. よって貢献度と負荷が客観的にわかりずらい
3. **なんかそれっぽいの作ってやってる感を出したい**正直3つめの理由が8割なので、肩ひじ張らずにゆるーくやっていきます。
# :sparkler: データ構想
とはいえせっかく作るからには実際に役立つものを作りたい。
まずは可視化する項目を考えてみる。– 貢献度
– 売上
– 生産性
– 負荷
– 稼働時間
– 残業時間
– その他
– 学習時間こんなもんかな？
これくらいなら使用してるツールやシステムからとってこれそうだ:ok_hand:# :bar_chart: データ活用方法
分析する項目が決まったところで、どのように魅せるか考えてみる。(見せるのではなく魅せる←ココ大事)Amazon QuickSightでは以下のようなビジュアルが用意されているよう。
とCognitoを統合
# やりたいこと
フロントエンド(ここではReactアプリ)から、APIGateway経由でLambda関数を実行するときにCognitoで認証されたユーザーからのリクエストのみをAPIGatewayで受け付けるようにしたい
※備忘録に近い内容です# 作成手順
###### ①Lambda関数を作成
何でも良いのでLambda関数を作成
とりあえず作成したときに出来上がるHelloLambdaのままとした
(ここでやりたいことはLambdaの中身は関係ないので)
“`
export const handler = async (event) => {
// TODO implement
const response = {
statusCode: 200,
body: JSON.stringify(‘Hello from Lambda!’),
};
return response;
};
“`###### ②APIGateway作成
・HTTP APIを作成
・Authorization設定
オーソライザーのタイプ：JWT
IDソース：$
S3バケットに保存したログを NewRelic へ転送する
# はじめに
S3に保存されるALBやCFtなどのアクセスログを NewRelic へ転送するための設定を行います。# 設定
NewRelic が AWS Serverless Application Repository に Lambdaアプリケーション を提供しているのでそれを利用します。
設定の流れとしては **[Lambdaアプリケーションのデプロイ](https://qiita.com/drafts/7eee1445b8fea7308c54/edit#aws-lambda%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4) > [Lambdaトリガーの追加](https://qiita.com/drafts/7eee1445b8fea7308c54/edit#aws-lambda-%E3%83%88%E3%83%AA%E3%82%AC%E3%83%BC%E3%81%AE%E8%BF%BD%E
インフラエンジニアさんに手引してもらいながらlambdaのIP固定化をやってみたときのメモ（NATゲートウェイ不使用）
## 概要
LambdaのIPをElastic IPを使って固定化した話をメモ的にまとめる
## 前提
下記の記事を参考に、インフラエンジニアさんに手引してもらいながらlambdaのIP固定化をしてみた
https://zenn.dev/nix/articles/7dd29a1e9edc55
## 内容
### lambdaに紐づくネットワークインターフェースを探す
どうやらパブリックなVPCにlambdaが設置されている場合、「ネットワークインターフェイス」が自動的に作られるらしい。下記の手順でネットワークインターフェースを探した。（パブリックなVPCにlambdaが設置されていないとネットワークインターフェイスはつくられないと思う）
1. マネジメントコンソールでEC2を開く
1. サイドバーで「ネットワークインターフェイス」を開く
1. 「lambda」で検索をかける
1. ヒットした内容の「説明」にlambda名が記載されているはずなので見つける
1. lambdaに紐づくネットワークインターフェイスの「ネットワークインターフェイス ID」と「プライベートIPv
AWS Certified Solutions Architect – Associate
# 概要
AWS SAA資格を取得する必要があるので、ブログ投稿しながら、資格準備をしようと思います。# AWS SAAとは
AWS技術に関する知識と、さまざまなAWSサービスにわたる技術を検証する試験です。
この試験は以下の主要な範囲を含みます:
1. コンピューティング、ネットワーク、ストレージ、データベースの AWS サービス、および AWS のデプロイと管理サービスに関する知識およびスキル
2. AWS 上でのワークロードのデプロイ、管理、そしてオペレーション、およびセキュリティコントロールとコンプライアンス要件の実装に関する知識およびスキル
3. AWS マネジメントコンソール、および AWS コマンドラインインターフェース (CLI) の使用に関する知識とスキル AWS Well-Architected フレームワーク、AWS ネットワーク、セキュリティサービス、AWS グローバルインフラストラクチャに関する理解
4. 提示された技術的要件を満たす AWS のサービスを特定し、AWS ベースのアプリケーションの技術的要件を定義する能力# 準備過程
1. 試験内容
