- 1. Amazon Linux2023にMySQLのclientをインストールしてRDSに接続する
- 2. CLFクラウドのコンセプトについて(その2)
- 3. 【AWS】terraform で EC2を作成しようとしたところ InvalidGroup.NotFound が出る
- 4. Terraformのprovider等のバージョン制約と不整合について
- 5. 【AWS】CloudFront+Route53+ALB+AutoScaling+EC2で負荷分散Webサイトの作成方法
- 6. 【CLI,CDK】アクセスキーを用いたIAMユーザー認証について簡単にまとめた
- 7. AWS Certified Developer – Associate (DVA-C02) 合格体験記
- 8. AWS Certified Solutions Architect – Associate (SAA)試験合格体験記
- 9. Operationalize AWS WAF Web ACL logs with Amazon Security Lake のまとめ
- 10. ELB(ALB)のアクセスログをTerraformで有効化する
- 11. RDSへCSVファイルをインポート/エクスポートする方法
- 12. AWSでGitLabをセットアップし、CodeCommitにミラーリングする
- 13. AWSでCodeCommitとCodeBuildを使ってみる
- 14. VSCodeでgit commit/pushを操作する
- 15. LambdaのRubyでGitLabにリポジトリを作成、削除する
- 16. AWS Backupの最新機能「論理的にエアギャップされたボールト」について
- 17. EC2のスポットインスタンスのデータの確認と起動を試してみる
- 18. タグ付きAWS EC2の自動停止・自動起動
- 19. AWSマネジメントコンソールログイン通知をメールで受け取る
- 20. Lambdaレイヤーについて
Amazon Linux2023にMySQLのclientをインストールしてRDSに接続する
# 概要
AmazonLinux2からAmazonLinux2023に乗り換えるべく、同じ環境を作ります。https://qiita.com/tamorieeeen/items/d9b2af588f1dfd43120d
#環境
– AWS EC2
– OS: Amazon Linux 2023
– AMI: al2023-ami-2023.5.20240730.0-kernel-6.1-x86_64
– RDS
– engine: MySQL Community
– version: 8.0.35
# 構築手順
こちらの公式情報を参考に進めます。https://dev.mysql.com/doc/refman/8.0/ja/linux-installation-yum-repo.html
## 1. MySQL8.0のリポジトリを追加
最新のリポジトリはこちらで確認します。AL2023はFedoraベースのようですが、構成はRHEL9に似てるらしいのでRHEL9のパッケージを入れてみます。https://dev.mysql.com/downloads/r
CLFクラウドのコンセプトについて(その2)
# はじめに
AWS認定であるクラウドプラクティショナー(CLF)の出題範囲である、
クラウドのコンセプトについて学ぶ。## クラウドの分野について
* ①AWS クラウドの利点を定義する。
* ②AWS クラウドの設計原則を特定する。
* ③AWS クラウドへの移行の利点と戦略を理解する。
* ④クラウドエコノミクスのコンセプトを理解する。以上4項目がAWSの提示しているクラウドのコンセプトです。
今回はこの中から**②AWS クラウドの設計原則を特定する**を簡潔に解説します。## ②AWS クラウドの設計原則を特定する
こちらの項目では
**AWS Well-Architected フレームワーク**が対象知識となっています。
対象となるスキルは以下の2つです。
* ①Well-Archtectedフレームワークの柱の理解(運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性など)
* ②Well-Architected フレームワークのさまざまな柱の相違点の特定## Well-Architected フレームワー
【AWS】terraform で EC2を作成しようとしたところ InvalidGroup.NotFound が出る
## 概要
以下のterraformでEC2を作ろうとしたところSGグループが見つからない旨のエラーが出現
## tfファイル
“`
resource “aws_instance” “dev_test_01” {
ami = “ami-”
availability_zone = “ap-northeast-1a”
iam_instance_profile = “SSM_access_for_EC2”
instance_type = “t2.micro”
key_name = “dev-test-01”
private_ip = “192.168.10.1”
subnet_id = “subnet-”
security_groups = [“ec2-1”, “ec2-2”]
tags = {
Name = “dev-test-01”
}
vpc_security_group_ids = [“sg-1”, “sg-
Terraformのprovider等のバージョン制約と不整合について
# はじめに
どうも、@to-fmakです。入社5日目ですが、既存環境等のキャッチアップをしながら、2日ほど作業していました。
作業(Terraformコードを中心に見ていました)の際に見つけた課題ついてまとめてみました。# 背景
– インフラ設定変更が必要なため、あるTerraformリポジトリ(直近あまり更新されていない)で作業をすることに
– terraform initの際に、aws providerのバージョン制約により、バージョンの不整合が起きた# Terraform Providerバージョンの不整合について
※元々のソースコードやコンソール出力ではフルバージョンが記載されていますが、本記事ではマイナーバージョンをマスキングします。また、省略する部分は「…」とします。
## そもそも何が起きたのか
リポジトリの中身を覗いてみたら、.terraform.lock.hclが存在していました。
“`:.terraform.lock.hcl
provider “registry.terraform.io/hashicorp/aws” {
versio
【AWS】CloudFront+Route53+ALB+AutoScaling+EC2で負荷分散Webサイトの作成方法
## 構成図
パブリックVPCのEC2にApache/NginxのWebサーバーを立ち上げ、CloudFrontで公開し、Route53でルーティング、ACMでSSL認証を付ける構成である。Webサイトからのリクエストは、Cognitoの認証を付与したAPI GatewayでLambdaへリクエストする。![Imakara-Web-System.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/483556/840e81de-44a6-ce81-c70e-1de6e7cdfcf5.png)
## 事前準備
・パブリックVPC内にEC2を立ちあげ、Webサーバーを公開する## Route53の設定
1. Route53のコンソール画面を開く
https://us-east-1.console.aws.amazon.com/route53/v2/hostedzones#
1.登録済みドメインでドメインを登録を押す
1. 作成したいドメイン名を検索し、チェックアウトに進むを押し
【CLI,CDK】アクセスキーを用いたIAMユーザー認証について簡単にまとめた
# 経緯
CDKを使用する際に、CLIの認証情報を使用していることを知りました。普段アクセスキーを用いてCLIを叩いていて、その辺周辺の知識がふわふわしていたので復習、備忘録がてら記事を書きました。https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/configure-access.html
# 前提条件
記事を書くために調査をしていると、この記事でまとめている手法については本番環境などでは非推奨であることがわかりました。
あくまで開発環境や砂場環境などでの使用を前提とします。>警告
セキュリティリスクを避けるため、専用ソフトウェアの開発や実際のデータを扱うときは、IAM ユーザーを認証に使用しないでください。代わりに、AWS IAM Identity Center などの ID プロバイダーとのフェデレーションを使用してください。https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-authentication-user.html#cli-authentica
AWS Certified Developer – Associate (DVA-C02) 合格体験記
# 2024年8月9日にAWS Certified Developer – Associate (DVA-C02) 合格しました!
### 勉強期間
2024年7月20日〜8月9日
### AWSの経験
•AWS専門のクラウドスクールにて勉強中
•実務経験なし試験は、実際の開発を想定した問題で開発に必要な組み合わせを覚えることが重要だと感じました。
実務経験なしとは書いておりますがフロントエンドのデプロイの際にALB、EC2を構築した経験はあったため流れを掴みやすかったと感じています#### 試験対策に使ったリソース:
• AWS公式トレーニング
• クラウドテック
• クラウドライセンス前回と同様クラウドテックを1巡しその後AWS公式トレーニング動画を見て理解度を深め、クラウドライセンスで全問解いた後、ひたすらテストを繰り返しました。
SAAに比べると比較的文章しっかり読むことで解ける内容が多いと感じました。
次も頑張ります!
AWS Certified Solutions Architect – Associate (SAA)試験合格体験記
# 2024年7月6日にAWS Certified Solutions Architect – Associate (SAA) 合格しました!
勉強期間
2024年6月15日〜7月6日AWSの経験
•AWS専門のクラウドスクールにて勉強中
•実務経験なし試験は、AWSのサービスに関する幅広い知識が問われるものでした。なので覚えることも多く繰り返し演習問題をときました。
試験対策に使ったリソース:
• AWS公式トレーニング
• クラウドテック
• クラウドライセンスクラウドテックを1巡しその後AWS公式トレーニング動画を見て理解度を深め、クラウドライセンスで全問解いた後、ひたすらテストを繰り返しました。
短期間の受験だったのでまだ完全に理解できていないところも多々あります。
これからもさらに深く学び、次の認定試験に向けて頑張ります!
Operationalize AWS WAF Web ACL logs with Amazon Security Lake のまとめ
**はじめに**
こんにちは!企業のセキュリティ対策において、Webアプリケーションの保護は重要な課題です。AWS WAFは、Webアプリケーションを攻撃から守るための強力なツールですが、そのログを効率的に管理・分析することが重要になります。
![(2) Operationalize AWS WAF Web ACL logs with Amazon Security Lake _ Amazon Web Services (1).jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102361/7d285e88-5f9d-1392-396b-4c1cd0666eee.jpeg)**Amazon Security Lake:AWS WAFログ管理の進化**
従来、AWS WAFのログを管理するには、AWS Firewall Managerを使ってAmazon S3に集約し、Amazon Athenaで分析する必要がありました。
しかし、Amazon Security Lakeが登場したことで、このプロセスが
ELB(ALB)のアクセスログをTerraformで有効化する
ログ用のS3バケットを作成して、ALBのアクセスログを有効化しようとしたところ、S3の権限不十分でエラーが発生しました。
“`plaintext
│ Error: modifying ELBv2 Load Balancer (arn:aws:elasticloadbalancing:ap-northeast-1:************:loadbalancer/app/alb-prod/fbbd3f2304ff9285) attributes: InvalidConfigurationRequest: Access Denied for bucket: logs-prod. Please check S3bucket permission
“`
公式ドキュメントをみたら、普通にバケットポリシーの設定が漏れていました。https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/enable-access-logging.html
以下のTerraformコードでエラーを解消したので、参考
RDSへCSVファイルをインポート/エクスポートする方法
EC2にMySQLクライアントを入れている必要がある。
MySQLクライアントをインストールする作業はここでは割愛する。“`
ssh -i /Users/<ユーザーネーム>/Desktop/<キーペアファイル名>.pem ec2-user@<パブリックIPアドレス>
“`
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1828177/9a47a521-7bfe-3248-8946-f403723fa12a.png)RDSに接続します。RDSのエンドポイントはAWSのコンソールからRDSの「接続とセキュリティ」タブから取得する。
“`
mysql -u admin -p -h
“`
パスワードを要求されるので予め設定したパスワードを入力する。
パスワードが正しければ接続する。続いてデータベースを構築する。
“`
mysql> create database;
“`構築したデータベースを確認する。
“`
mysql> s
AWSでGitLabをセットアップし、CodeCommitにミラーリングする
## 概要
表題の通り## 参考ドキュメント
これをもとにいろいろカスタマイズする
## 注意事項
GitHubではOrganizationとリポジトリがあったが、GitLabでも同じものがあるが表現が違う。以下にまとめておく。| ツール | Organization | リポジトリ |
| ———- | ————– | ———— |
| GitHub | Organization | リポジトリ |
| GitLab | グループ | プロジェクト |
| CodeCommit | 存在しないかも | リポジトリ |間違っているかもしれないがこの認識で進めることにする。
## 作業環境
Windows11のWSL(Ubuntu)から行う## IAMポリシーの作成
1. IAMの画面を開く→左メニューのポリシーをクリック→ポリシーの作成をクリック
– アク
AWSでCodeCommitとCodeBuildを使ってみる
## 概要
表題の通りhttps://qiita.com/tmoritoki0227/items/0d8d8a693a38049e03cb
でGitLabからCodeCommitにミラーリング設定を行った。
次にGitLabに大量のリポジトリが必要となることを想定し、自動で作れるようにしたい。やり直すことも考えて削除も行えるようにしたい。
しかし、AWSのサービスではないGitLabとCodeBuildを連携するのは認証部分でハードルが高いので、まずはCodeCommitとCodeBuildを連携させることにする## CodeCommitで作業用リポジトリを作成する
このリポジトリにリポジトリの作成、削除に必要なファイルを格納する。### リポジトリ(プロジェクト)作成
1. http://35.75.155.254/gitlab を開く。ログインする
1. NewGroupを作成 ※すでにあるグループを使う場合はskipします
– Create group(画面名)
– Group name
– `hello` (任意で
VSCodeでgit commit/pushを操作する
## 間違えてたこと
wslなのでssh_configはwsl側で作っていたが、vscodeがwindowsの`C:\Users\user\.ssh\config`を見ていた## C:\Users\user\.ssh\config
“`bash
UserKnownHostsFile ~/.ssh/known_hostsHost git-codecommit.*.amazonaws.com # codecommitを扱うときはこれでよい
User XXXXXXX # AWS CodeCommit の SSH 公開キーのSSH キー ID
IdentityFile ~/.ssh/id_rsa # awsのec2にログインする鍵(と一緒にしている)
“`その後、普通にできる。
git cloneもwsl側にしなくても大丈夫だった。
Userは指定しないと、デフォルトec2-userでcodecommitにアクセスして失敗する
LambdaのRubyでGitLabにリポジトリを作成、削除する
## ruby版
AIにシェルからlambda用に変換してもらったらあっさり動いた。
RubyでGitLabにリポジトリを作成、削除する機能です。### リポジトリ作成
– https://github.com/tmoritoki0227/gitlab_project_create/blob/main/create_project.rb
– https://github.com/tmoritoki0227/gitlab_project_create/blob/main/projects_and_branches.txt### リポジトリ削除
– https://github.com/tmoritoki0227/gitlab_project_create/blob/main/delete_project_all.rb
AWS Backupの最新機能「論理的にエアギャップされたボールト」について
以下の最新情報を見かけたのでBackupの基本と最新機能について書いてみます。
AWS Backup 論理的にエアギャップされたボールトの一般提供開始を発表(直訳)
https://aws.amazon.com/about-aws/whats-new/2024/08/general-availability-aws-backup-logically-air-gapped-vault/# ■AWS Backupとは
まずAWS Backupについてですが、
AWS環境における一元的なデータバックアップソリューションという位置付けです。基本的な機能と利点を紹介します。
“`
・一元管理
EC2、EBS、RDS、S3など、複数サービスにまたがるバックアップを一元管理できます。・自動化
バックアップスケジュールの設定を自動化することで、定期的かつ計画的なバックアップが可能です。・復元の迅速化
万が一の障害発生時に、迅速にデータを復元できる点も大きな魅力です。
これにより、ダウンタイムを最小限に抑えることが可能です。
“`# ■補足
ここで出てくるワードについて先に
EC2のスポットインスタンスのデータの確認と起動を試してみる
要件が満たせるのならFargateとかの方が好ましいケースが多いとは思いますが、EC2を触る機会も多く且つスポットインスタンスを触ったことが無かったので雑に備忘録として記事にメモしつつスポットインスタンスの起動回りについて触れていこうと思います。また、割引率や中断率のデータの見方に関しても軽く触れておきます。
:::note warn
インフラ・クラウド回りは初心者なので知識が荒い点などはご容赦ください。
:::
:::note info
個人的にはAWSの画面は(翻訳精度などの面で)英語表示の方が好みなので画面のスクショも英語表示のままにしてあります。
:::# 起動前にスポットインスタンスの料金について調べる
大雑把な料金に関しては以下のページで対象のリージョンを選択して必要なインスタンスタイプを検索すれば確認することができます。
https://aws.amazon.com/jp/ec2/spot/pricing/
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/228
タグ付きAWS EC2の自動停止・自動起動
AWSで設定検証する際にEC2を立てて起動したままで無駄な課金を発生させてしまうことが多々あり、反省を込めてEC2の自動停止(+自動起動)の設定を記事にします。対象EC2の判別はタグ付けで行い、特定のタグが付いているEC2のみを対象とします。
# 本記事でのゴール
時間になったら特定のタグが付いているEC2を自動停止、自動起動する![スケジュールイメージ.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/655033/2fbd5ba6-d317-cd0a-143f-2b0d92519dc3.jpeg)
設定構成としてこんな感じです。
![EC2_自動停止_全体構成.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/655033/ea627f47-283a-33ed-a6f3-6a14c1085769.jpeg)[AWS EventBridge]で時間指定で、SSM内の実行したい内容を記述した[ドキュメント]を呼び出し
AWSマネジメントコンソールログイン通知をメールで受け取る
## 概要
AWSマネジメントコンソールにログインしたイベントを、メールで通知させる仕組みを構築します。知らないところで誰かに勝手にログインされても気がつけるようになります。CloudFormationテンプレートで、簡単に導入できるようにしました。## 構成
今回構築するシステム構成です。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3636209/fa201630-ed52-46a7-2f78-ad1b2f6a2529.png)
## 通知サンプル
以下のようなメールを受け取ることができます。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3636209/607b8c69-a3dd-4dbe-8253-431f347b45d9.png)
※ログ情報の一部をそのまま連携しただけなので、見た目が悪いです。本文の修正は、別の記事で紹介する予定です。
## 各コンポーネントの設
Lambdaレイヤーについて
## はじめに
Lambdaレイヤーについて、整理してみました。
Lambdaレイヤーとは、Lambda関数で使用するライブラリ、カスタムランタイム、設定ファイル、その他の依存関係をパッケージ化して共有するための機能です。レイヤーを使用することで、コードの再利用、デプロイの簡素化、バージョン管理が容易になります。レイヤーの作成と使用は、依存関係をディレクトリに配置し、ZIPファイルに圧縮してアップロードすることで簡単に行えます。また、不要になったレイヤーバージョンは削除することができます。これにより、複数のLambda関数で共通のコードやライブラリを効率的に管理できます。## Lambdaレイヤーの利点
**1.コードを再利用することができる**
共通のライブラリや依存関係をレイヤーとしてパッケージ化することで、複数のLambda関数で再利用できます。**2.デプロイをシンプルにすることができる**
レイヤーを使用することで、関数コードと依存関係を分離できます。**3.バージョンを管理して、依存関係の変更が他の関数に影響を与えないようにすることができる**
レイヤーはバー