- 1. 【備忘録】Amazon FSx for Windows File Serverを触ってみた
- 2. App RunnerのVPCコネクタを使ってRDSへ接続してみた
- 3. EC2へのアクセス元IPを特定する方法
- 4. CloudWatch Logsでフィルタを用いて特定ログを検出してみた
- 5. Amazon Bedrockの新機能「Prompt Flows」Conditionノードの使用例の実行
- 6. 【AWS-SAA勉強記】第5回_Amazon CloudFront、Global Accelerator編
- 7. Getting started with Amazon Q Developer – Part 1、2の要約
- 8. Amazon Route53のトラフィックルーティングとELBのトラフィック分散について
- 9. 運用上の優秀性解説 要約
- 10. AWS CloudShellをCloud9の代わりでBedrockの学習に使えるか?
- 11. 【AWS】IAM ユーザーの作成手順
- 12. ACMを使ってSSLサーバー証明書を発行する
- 13. 【AWS Amplify】GitHub連携でVueアプリをAmplifyへデプロイする手順
- 14. 【AWS】一つのメトリクスフィルターが二つのアプリのログを検知してしまう現象の解決方法
- 15. 初代 “AWS Jr. Champion” になり、翌年に “AWS Top Engineer” になった話
- 16. 【アップデート】S3が条件付き書き込みをサポートしました
- 17. GitHubActionsからCloudFormationを実行する
- 18. 【AWS】Lambda関数削除手順【Lambda】
- 19. lambda share
- 20. CLFクラウドのコンセプトについて(その4)クラウドエコノミクスのコンセプトを理解する
【備忘録】Amazon FSx for Windows File Serverを触ってみた
## はじめに
今後FSx for Windows File Serverを触るかもしれないということで、フライングしてハンズオンしてみました。
誰かの助けになればと思い、備忘録として残します。
こちらのページを参考にハンズオンをしていきます。https://docs.aws.amazon.com/ja_jp/fsx/latest/WindowsGuide/getting-started.html
## FSx for Windows File Serverの設定
### Step0 事前準備
今回作業用のVPCを作成します。
パブリックサブネットとプライベートサブネットを2つずつ、NATゲートウェイやエンドポイントは不要です。
次のStepから公式ドキュメントを参考にFSxを使用するための前提条件を満たしていきます。https://docs.aws.amazon.com/ja_jp/fsx/latest/WindowsGuide/walkthrough01-prereqs.html
### Step1 Active Directoryのセットアップ
まずはActive D
App RunnerのVPCコネクタを使ってRDSへ接続してみた
# はじめに
こんにちは。[前回記事](https://qiita.com/duora0406/items/be56724d963784fbe59e)では、「とりあえずApp Runnerを動かしてみる。」というところに焦点を当てて紹介しました。確かにApp Runnerはとても便利なサービスではあるのですが、もしも、App Runnerを実サービスで利用する場合、下記の部分が気になるのではないでしょうか。* App RunnerからDBに通信することはできるの?
* App Runnerって接続制御はできるの?
* App Runnerでログってとれるの?今回は、App RunnerからVPC内に作成したDBへ接続する構成を構築してみます。App Runnerを利用している方の参考になれば幸いです。
# VPCコネクタについて
App Runner側で作られたVPCはAWSコンソールで見えないので、App Runnerが作ったVPCにRDSやサブネットなどNWのリソースを作ることはできません。そんなときに利用するのが、VPCコネクタになります。詳細は、[アップデート
EC2へのアクセス元IPを特定する方法
最近、EC2のAuto Scalingグループがスケールアップした際に、ALB(Application Load Balancer)のリクエスト数が急に増えましたが、IPアドレスからリクエストが来ているのかが分からなかったのでメモ程度に残します。
**方法:**
1. **ELBのアクセスログを確認する:**
最初に試すべきは、ALB(Application Load Balancer) のアクセスログを確認することです。このログには、どのIPアドレスからリクエストが送られてきたかが記録されています。ログは、AWSコンソールやCLIから取得できます。この方法で、リクエスト元のIPアドレスを簡単に特定できます。
ALBのアクセスログはS3に保存されています。※以下からは確認できないので注意
Auto Scalingログ
Auto Scalingログは、イベントやアクティビティを記録するためのものであり、リクエスト元のIPアドレスを含みません。したがって、リクエスト元IPを特定するためには、Auto Scalingログを使用することはできません。
CloudWatch Logsでフィルタを用いて特定ログを検出してみた
## CloudWatch Logs とは
CloudWatch Logs は、EC2 インスタンスや Lambda function などのログを管理し、検索できる便利なサービスです。今回は、特定のログ情報をフィルタする方法について紹介します。
CloudWatch Logsでフィルターパターンで正規表現を用いることができるのですが、苦戦したので参考にしていただけば幸いです。### 前提条件
– 対象とするLog groupが存在する### 1.フィルタの作成
CloudWatch Logs のコンソールにログインします。
左側のナビゲーションペインで、[Log groups] を選択します。
対象とする log group を選択し、「フィルタイベント」をクリックします。### 2. フィルタパターンの作り方
フィルタパターンを作成する際には、「応答時間が1秒以上かかったリクエスト」や「エラーメッセージ」などの特定の条件を抽出することができます。
パターンは、 { $.duration > 1.00 } や { $.errorMessage != null} のように
Amazon Bedrockの新機能「Prompt Flows」Conditionノードの使用例の実行
# はじめに
今回はAmazon Bedrockの新機能「Prompt Flows」のConditionノードを使って、入力されたテキストが日本語であればその要約を出力し、それ以外の言語であれば日本語に翻訳し、その要約を関西弁で出力するアプリケーションの例を実行してみました。「Prompt Flows」は、ノードを配置して生成AIのワークフローを開発・管理できるサービスです。
https://aws.amazon.com/jp/bedrock/prompt-flows/
今回アプリケーションの作成にあたって、以下のサイトを参考にしました。
# 導入
アプリケーションの全体像は以下の通りです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3806967/73090223-e94d-e916-2a65-b0dca225d6bc.png)アプリケーショ
【AWS-SAA勉強記】第5回_Amazon CloudFront、Global Accelerator編
この記事は作者本人がAWS-SAAの学習を通じて、曖昧や覚えづらい部分をサービス単位でまとめたものです。
特に、概要だけではイメージがわきづらいので、できるだけユースケースを活用して理解しやすいようにしています。
教材はSHOEISHAの[AWS教科書 AWS認定ソリューションアーキテクトアソシエイト テキスト&問題集](https://www.amazon.co.jp/AWS%E6%95%99%E7%A7%91%E6%9B%B8-AWS%E8%AA%8D%E5%AE%9A%E3%82%BD%E3%83%AA%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%88%E3%82%A2%E3%82%BD%E3%82%B7%E3%82%A8%E3%82%A4%E3%83%88-%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%EF%BC%86%E5%95%8F%E9%A1%8C%E9%9B%86-%E7%85%A4%E7%94%
Getting started with Amazon Q Developer – Part 1、2の要約
このツールは、開発者がコードを作成したり、既存のコードを修正したり、トラブルシューティングを行う際に役立ちます。
## Q Developerでできること
Q Developerは、コードの作成、修正、トラブルシューティングの3つの主要な機能を提供します。
### 1. コードの作成と修正
* 新しい機能を追加したり、既存のコードを改善したりすることができます。
* 例えば、ウォレットアプリケーションに新しい機能を追加したい場合、Q Developerにコメントで指示すると、それに対応するコードを提案してくれます。
* 提案されたコードはそのまま受け入れることも、修正することもできます。### 2. トラブルシューティング
* コードのエラー原因を特定し、解決策を提案してくれます。
* 例えば、Lambda関数でエラーが発生した場合、Q Developerにエラーメッセージを提示すると、原因を特定し、解決策を提案してくれます。### 3. アーキテクチャのアイデア出し
* アプリケーションのアーキテクチャを設計する際に、Q Developerは様々なアイデアを提案し
Amazon Route53のトラフィックルーティングとELBのトラフィック分散について
## 勉強前イメージ
Amazon Route53のトラフィックルーティング機能とElastic Load Balancingのトラフィック分散機能の存在については知っていたが、これらのユースケースや違いについてよくわからない…## Amazon Route53とは
#### 概要
ドメイン名の登録やDNSレコードの管理、ドメインのルーティングなどのDNSに関連する機能の提供
#### 主な機能
1. ネームサーバーとしての利用
2. **トラフィックのルーティング**
3. リソースの正常性
## Elastic Load Balancing(ELB)とは
#### 概要
ほかのサービスへのトラフィックを複数のターゲットに自動的に分散し、安定稼働をサポートするサービス
#### 主な機能
1. **トラフィック分散**
2. メンテナンスや障害対応
3. サーバーのエルスチェック
4. セキュリティ強化## 調べてみた結果
##### そもそも用途が違う!
運用上の優秀性解説 要約
## 概要
AWS運用には、安定運用と問題対応力が求められる。
成功の鍵は「運用上の優秀性」にある。**運用上の優秀性**とは、サービスを安定的に稼働させ、問題発生時に迅速に対応できる状態を指します。AWS運用を成功させるには、以下の**5つの設計原則**を意識することが重要です。
**1. 運用をコードとして実行する:**
– 環境全体をコードで管理することで、環境構築や更新を自動化し、一貫性を保てます。
– アプリケーションコードと同じように、環境構築、更新、運用手順もコードとして定義します。**2. 元に戻せる小さな変更を頻繁に行う:**
– 少しずつ変更を加えることで、失敗した場合でも簡単に元に戻せます。
– AWSサービスを活用し、コンポーネントを定期的に更新できるようにワークロードを設計します。**3. 運用手順を定期的に改善する:**
– 定期的に手順を見直し、改善することで、ワークロードに合わせて柔軟に対応できます。
– 定期的なゲームデーを実施して手順を評価します。**4. 障害を予測する:**
– 潜在的な問題点を事前に把握し、適切な対策を講じるこ
AWS CloudShellをCloud9の代わりでBedrockの学習に使えるか?
## 前書き
ご存知の通り、2024年7月29日からCloud9がサービス終了しました。
![91A93842-19F2-4A3A-9D77-7B91135D0A32.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/320164/b25a6ca4-ef40-4772-c2da-efbe7546602b.jpeg)最近、Cloud9を使ってBedRockの学習をしている筆者にとって、まさに青天の霹靂です。
いくつか代替案を探してみたところ、`AWS CloudShell`にたどり着きました。:::note warn
注意
2024年8月20日時点で使用していますが、これがAWS CloudShellの正しい使い方かは確信が持てません。慎重に使いましょう。
:::## やり方
セットアップの手順は、以下の記事に詳しく書かれています。
https://qiita.com/moritalous/items/708d56d5c10c5832d169
ここでは、必要な作業の一部を抜粋してご紹介しま
【AWS】IAM ユーザーの作成手順
# はじめに
この記事では、AWS IAM ユーザーの作成手順について記載します。https://docs.aws.amazon.com/iam/
:::note
以後の画面キャプチャは 2024年8月時点のものです。
:::# ユーザー作成画面へのアクセス
IAM のダッシュボード左側メニューから「Users」をクリックします。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318188/c1ec6c8f-c72f-3da1-c8c2-8eac7db21404.png)
ユーザー一覧が表示されます。右上の「Create user」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318188/adf5a845-2059-844b-c7b4-0925e10a0af5.png)
# Step 1 Specify user details
ユーザー名やマネージ
ACMを使ってSSLサーバー証明書を発行する
AWSマネジメントコンソールからACM(AWS Certificate Manager)を表示します。
ACMのトップページの[証明書をリクエスト]をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14202/4bbae4fc-31ea-8f7d-bd02-b4370937ba78.png)
証明書をリクエストページが表示されます。
[次へ]をクリックしてください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14202/3adfa2c8-6958-2b45-b6e9-f6cabee8f39e.png)パブリック証明書をリクエストページが表示されます。
完全修飾ドメイン名を入力してください。
入力後、[リクエスト]をクリックしてください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.a
【AWS Amplify】GitHub連携でVueアプリをAmplifyへデプロイする手順
# 1. 概要
この記事では、 AWS AmplifyにGithubを連携し、Vueアプリをデプロイする手順を記載しています。# 2. 目次
1. 概要
1. 目次
1. 手順
1. 事前準備
1. Vueアプリを作成する
1. Githubにアップロードする
1. AWS Amplifyにデプロイする
1. マネジメントコンソールをひらく
1. AWS Amplifyをひらく
1. AWS Amplifyでアプリ作成する
1. 動作確認
1. 参考資料# 3. 手順
### 3.1. 事前準備
##### 3.1.1. Vueアプリを作成する
参考:[yarn とは?(+ Mac に
【AWS】一つのメトリクスフィルターが二つのアプリのログを検知してしまう現象の解決方法
# 概要
AWS CloudWatch Logsで一つのメトリクスフィルターが二つのアプリのログを検知してしまう現象が発生。
備忘録も兼ねて、原因と対応方法を紹介します。# 前提と原因
元々CloudWatch Logsのロググループの下には既存アプリのアプリログに使用中のログストリーム一つしかなかったのですが、今回新規アプリを導入するにあたり新規アプリログ用にログストリームをもう一つ追加しました。アプリごとにログストリームを設けて、それぞれにメトリクスフィルターを適用してあげる、という構成です。こんなイメージで構成を考えていました。
“`
└── app_log_group
├── hoge_app_log_stream
└── foo_app_log_stream
“`しかし、これが問題でした。
なぜなら、CloudWatch Logsのメトリクスフィルターは、特定のロググループに対して設定できますが、特定のログストリームを直接指定することはできないためです。
https://docs.aws.amazon.com/AmazonCloudWat
初代 “AWS Jr. Champion” になり、翌年に “AWS Top Engineer” になった話
# はじめに
お疲れ様です。@yuki_ink です。先日 **2024 Japan AWS Top Engineers** が発表され、ありがたいことに、その1名として認定していただきました!
https://aws.amazon.com/jp/blogs/psa/2024-japan-aws-top-engineers/
この結果は、**2023 Japan AWS Jr. Champion** としての活動なしにはあり得ませんでした。
ということで、Jr. Champion になるまでの話となった後の話、Jr. Champion としての1年間で私が大切にした考え方などを、体験談的に残しておきたいと思います。### 目次
初代 “AWS Jr. Champion” になり、翌年に “AWS Top Engineer” になった話
(**別題: Jr. Champion になって人生変わった!!**)1. 自己紹介
1. Jr. Champion とは?
1. Jr. Champion になる前
1. Jr. Champion になった後
1. Top Engine
【アップデート】S3が条件付き書き込みをサポートしました
こんばんは。Koderaです。
Amazon S3で条件付き書き込みのサポートが開始されました。
https://aws.amazon.com/about-aws/whats-new/2024/08/amazon-s3-conditional-writes/## アップデート内容
Amazon S3 では、オブジェクトを作成する前にオブジェクトが実際に存在しているか確認できる条件付き書き込みがサポートされました。
データのアップロード時にアプリケーションが既存のオブジェクトを上書きするのをより簡単に防ぐことができます。
対象は、汎用バケットとディレクトリバケットの両方です。アップデートのメリットは、複数のクライアントを持つ分散アプリケーションが、共有データセット間でデータを同時並行で更新できるようになったことです。
データをアップロードする前にオブジェクトの存在を確認するために追加のAPIリクエストの利用する必要がなくなります。## conditional writes(条件付き書き込み)とは
S3への条件付き書き込みでは、書き込みリクエストに追加のヘッダーを使います。
条
GitHubActionsからCloudFormationを実行する
# はじめに
今回はS3をCloudFormationとGithubActionsを使って、構築していきたいと思います。
GitHubActionsとAWSの連携からS3作成までやっていきたいと思います。# 目次
1.AWSとGitHubActionsの連携
2.S3の構築
3.最後に
4.参考# 1.AWSとGithubActionsの連携
AWSとGitHubActionsの連携はOpenID Connectを使用します。
前提として、GitHubのリポジトリ、AWSアカウントは作成済みとします### 1-1.AWSにてIDプロバイダの追加
AWSのマネジメントコンソールからIAMロール>IDプロバイダ>プロバイダを追加へと進みます。
プロバイダ設定にて下記設定を入力し、プロバイダを追加をクリックし登録します。
| 項目 |入力内容|
|:———–:|:————:|
|プロバイダのタイプ | OpenID Connect |
|プロバイダのURL | https://token.actions.githubusercontent.com |
【AWS】Lambda関数削除手順【Lambda】
1). Lambdaを開き、削除対象の関数のラジオボタンを押し、「アクション」から「削除」を選択します。
![1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3817084/bbcde979-f26b-8bc1-9ea2-b6d17051ee2f.jpeg)2). 赤枠に「削除」と入力し、「削除」を押します。
![2.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3817084/a399c879-2cb7-4fb7-2863-b1e384e5f296.jpeg)3). 正常に削除されたことを確認して「閉じる」を押して完了です。
![3.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3817084/77b2d509-ea72-ee8a-e93f-7f02bca959c0.jpeg)
lambda share
“`
export const handler = async (event) => {
try {const jsonObject = event;
const formattedMessage = `Security Hubが以下の重要度の異常を検知しました: ${jsonObject[“Security Hubが以下の重要度の異常を検知しました”]}
Account ID: ${jsonObject[“Account ID”]}
発生時間: ${jsonObject[“発生時間”]}
ProductArn: ${jsonObject[“ProductArn”]}
検出内容: ${jsonObject[“検出内容”]}`;return formattedMessage;
} catch (error) {
return `Error: ${error.message}`;
}
};
CLFクラウドのコンセプトについて(その4)クラウドエコノミクスのコンセプトを理解する
# はじめに
AWS認定であるクラウドプラクティショナー(CLF)の出題範囲である、
クラウドのコンセプトについて学ぶ。## クラウドの分野について
* ①AWS クラウドの利点を定義する。
* ②AWS クラウドの設計原則を特定する。
* ③AWS クラウドへの移行の利点と戦略を理解する。
* ④クラウドエコノミクスのコンセプトを理解する。以上4項目がAWSの提示しているクラウドのコンセプトです。
今回はこの中から**④クラウドエコノミクスのコンセプトを理解する**を簡潔に解説します。こちらの項目では
– ①クラウドエコノミクスの側面
– ②クラウド移行によるコストの削減
の二つが対象知識となっています。
対象スキルは以下の6つです。
– ①変動費と引き合わせた固定費の役割の理解
– ②オンプレミス環境に関連するコストの理解
– ③さまざまなライセンス戦略の相違点の理解
(Bring Your own License[BYOL]モデルとライセンス込みモデルの比較など)
– ④適正なサイジングのコンセプト理解
– ⑤オートメーションの利点の特定
(AWS