AWS関連のことを調べてみた

AWS関連のことを調べてみた
目次

KubernetesとEKSの学習記録 Part 3

# 概要
仕事でKubernetes(AWSのEKS)を利用する機会が出てきたため学習します。

学習ステップとしては以下のようにしてみようと思っています。
1. Kubernetesの基本用語の理解
2. Kubernetes公式チュートリアルやってみる
3. EKSの基本用語理解
4. EKSでサービスを作ってみる

今回はステップ3 「EKSの基本用語理解」

この記事はそのメモやまとめです。
すでに設定済みの項目がいくつかある。
試行錯誤しながらやったので、手順として不要かもしれない。**あくまでメモ用。**

## ECSについて理解する。
AWSでContainerを使おうとするとECS or EKSになると思うので、まずはECSについて用語を含めて理解していく。

### ECS
https://aws.amazon.com/jp/ecs/
> Amazon Elastic Container Service (ECS) はフルマネージドのコンテナオーケストレーションサービスであり、コンテナ化されたアプリケーションをより効率的にデプロイ、管理、スケールするのに役立ちます

元記事を表示

API Gatewayで/{proxy+}メソッドを活用する方法

## はじめに
こんにちは、開発部の天津炒飯です。

CloudFormationのLambda Functionでパスごと、Eventsを一つずつ書くことで苦労した経験があるかもしれません。
API Gatewayの “ /{proxy+} “ メソッドを使用すると、異なるパスに対するルーティングを簡単に実現できますが、意外と日本語の情報が少ないです。
私はPythonのWebフレームワークであるFastAPIを使用したので、この記事ではFastAPIを使用してAPI Gatewayの “ /{proxy+} “ メソッドを活用する方法に焦点を当てます。

## 1. /{proxy+}メソッドとは
“ /{proxy+} “ メソッドは、ワイルドカードパスを表すもので、異なるパス構造のリクエストを同じAPIエンドポイントにルーティングするのに役立ちます。
例えば、 “ /products/{proxy+} “ は “ /products/item1 “ や “ /products/category1/item2 “ など、様々なパスに対応できます。

##

元記事を表示

3コミュニティ共催イベント「awsカーニバル」を開催しました(経緯説明編)

# 札幌でイベントやったので、開催報告です

このブログは、「JAWS-UG(AWS Users Group – Japan) Advent Calendar 2023」の1日目の記事です。

https://qiita.com/advent-calendar/2023/jaws-ug

長くなってしまったので、開催までの経緯をまとめるところまでを書きたいと思います。

## AWSカーニバルとは

開催概要から引用すると

> AWSのユーザコミュニティは常に進化をし続け、スタートアップからエンタープライズまでたくさんの知見が溜まっています。 今回はそんな日本中のawsを活用しプロダクトを運用、グロースしてきた方々から、0->1を生むときに必要なAWSの知見。そこからグロースするときに陥った課題をどのようにAWSを利用し解決してきたのか。そんな話を中心としたお話を集めたイベントとなります。
また、このイベントはAWS公式3大コミュニティーである、「AWS Startup Community」「JAWS-UG」「Amplify Japan User Group」のコラボイベントとして

元記事を表示

Werner先生の Keynote を聞いて、テクノロジーとビジネスの間にいる自分が勇気をもらった話

# Keynote with Dr. Werner Vogels

AWS re:Invent 2023 に現地参加して、Werner 先生の Keynote が深く刺さったので、記録を残していきます。

この記事は弊社のアドベントカレンダー1日目です。
ラスベガスはまだ30日なのですが、書いていきます。

https://qiita.com/advent-calendar/2023/htb-dev-team

## AWS re:Invent 2023 に参加してきました

AWS Hero に認定いただいているのですが、他の現地参加している Hero で動ける方で、デイリーリキャップイベントを行っていました。
(Heroに関しての話はまた、どこかで)
本日3日目は Werner 先生の Keynote についての振り返りを行いました。

https://jaws-ug.doorkeeper.jp/events/166368

基本的には、日本の方に向けて、少しでも伝われば、

元記事を表示

AWS ログイン中のアカウントがrootアカウントかどうかを確認する

## 概要

AWSにログイン中のアカウントがrootアカウントかどうかを確認する方法をまとめる。

## 方法

1. 右上の自分の名前をクリックし、プルダウンを開く。
1. 「セキュリティ認証情報」をクリックする。

![セキュリティ認証情報___IAM___Global.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306417/ab834103-4f64-de27-dc44-aef65b8a2ef9.png)

1. アカウント詳細の部分に「Eメールアドレス」が表示されている場合、rootユーザーでログインしているはず。

– rootユーザー

![セキュリティ認証情報___IAM___Global.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306417/096fde1f-3202-ea06-8003-4f5e2e04f212.png)

– 非rootユーザー

元記事を表示

SSOとスイッチロールでAWSのアカウント管理を楽にした話 (2/2)

# 0.はじめに
## 概要
* 本記事は前半 (AWS側) と後半 (IDaaS側) の2部構成です。
* こちらは後半 (IDaaS側) です。前半 (AWS側) は[こちら](https://qiita.com/ot_kaneda/items/ec8cefa7e518ea1fcaa1)。
* この記事では、社内でIDaaSからAWSへのシングルサインオン (以下、SSO) および案件で利用する各AWSアカウントへのスイッチロールを連携させた際の背景や手順などを紹介します。
* 多数のWebサービスとAWSアカウントを抱え、ユーザー管理に頭を悩ませているシステム管理者の方に読んでいただければと思っています。

# 1. 大まかな流れ
– 2部構成で、本記事ではIDaaS側で実施する内容を記載しています。
– 弊社ではCloudGateを利用していますが、おそらくは他のIDaaSでも実施内容は概ね同じかと思います。
## AWS側
1. 踏み台となるAWSアカウントの用意
1. IAM Identity Centerの設定
1. スイッチロール作成
– → [

元記事を表示

SSOとスイッチロールでAWSのアカウント管理を楽にした話 (1/2)

# 0.はじめに
## 概要
* 本記事は前半 (AWS側) と後半 (IDaaS[^1] 側) の2部構成です。
* こちらは前半 (AWS側) です。後半 (IDaaS側) は[こちら](https://qiita.com/ot_kaneda/items/e9f8e5a8911c8cd395cc)。
* この記事では、社内でIDaaSからAWSへのシングルサインオン (以下、SSO) および案件で利用する各AWSアカウントへのスイッチロールを連携させた際の背景や手順などを紹介します。
* 多数のWebサービスとAWSアカウントを抱え、IAMユーザー管理に頭を悩ませているシステム管理者の方に読んでいただければと思っています。

### やりたいこと概略図
* before
![aws-before.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2349419/89bafc79-a8eb-0bdb-bdf6-46f2b5e0d7eb.png)
* 今までは複数アカウントのIAMユーザーを

元記事を表示

AWS Secrets Managerに登録された秘密鍵から公開鍵を作る方法

“`bash:AWS Secrets Managerに登録された秘密鍵から公開鍵を作る方法
$ ssh-keygen -y -f <(aws secretsmanager get-secret-value --secret-id {secret名} --query 'SecretBinary' --output text --profile {profile名} | base64 --decode) > {公開鍵}.pub
“`

# はじめに
AWS Secrets Managerにバイナリで登録された秘密鍵のペアになる公開鍵を作りたい。
なんとなくローカルに秘密鍵を出力してそこから公開鍵をつくらず、ローカルに秘密鍵出力するのも嫌だしワンライナーでやってみたかった。

:::note warn
ご利用および鍵の取り扱いは自己責任でお願いいたします。
:::

# コマンドの説明
– 環境
– Windows 11 Pro
– aws-cli/2.13.25
– base64 (GNU coreutils) 8.32

## AWS Secrets Man

元記事を表示

“The Five-Factor Serverless“ AWS Lambda の9年を振り返りつつ、これからを考える。

re:Invent 2023の Werner Vogels のセッションスライドを振り返りつつ。
![IMG_1515.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/6088/0b1e7504-e6d2-85fd-dc9f-39101c7618fb.jpeg)

[AWS Lambda は、2014年にGAしました。](https://aws.amazon.com/jp/about-aws/whats-new/2014/11/13/introducing-aws-lambda/)
Lambda 以外にこの年は Auroraや Codeシリーズなども発表されており、大変盛り上がった re:Inventになったことを記憶している人も多いのではないでしょうか。
![IMG_1517.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/6088/b9de0f4b-94a0-2ec3-41ac-7e629ebafa17.jpeg)

元記事を表示

AWSでAuto Scaling Groupsを用いた耐障害性を考える

# はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧は[こちら](https://qiita.com/tech4anyone/items/b06f88035d27c6ef13b2)。

この記事ではAuto Scaling Groupsを耐障害性の観点から超詳細解説しています。

具体的には以下流れで説明します。

– Auto Scaling Groupsのスケーリングポリシーとターミネートポリシー
– Auto Scaling Groupsのライフサイクルとイベント通知
– Auto Scaling Groupsのウォームプール
– Application Auto Scaling

AWSの区分でいう「Level 200:トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。

# この記事を読んでほしい人
– Auto Scaling Groupsを採用するときのベストプラクティスを説明できるようになりたい人
– Computeリソースの耐障害性に不安を感じている人
– AW

元記事を表示

Amazon Qに関する情報まとめてみた

# はじめに

re:invent盛り上がってますね!
この記事では今回の目玉発表であったAmazon Qについてのアップデートや関連するブログについて簡単にまとめています。
※ほぼ自分のための備忘録ですのであらさがあることはご容赦ください

# Amazon Qとは

2023年11月28日に、[生成AIを活用したアシスタント](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-amazon-q-preview/)として発表されました。現時点ではプレビュー版です。
Amazon Qは、特にビジネス用途に特化しているとされていて、社内のストレージ等と接続することでさまざまなコンテンツ、リポジトリにまたがる知識からの質問・回答、レポート要約、記事の作成を実行出来ます。

## ビジネス用途関連のブログ

下記ではビジネス用途で利用する際の例が記載されています。ブログの中では、AWS Blogを学習させてその内容に関する質問をする手順が簡単に記載されています。

https://aws.amazon.com/blogs/aws/i

元記事を表示

負債化してしまったAWSのあれこれをコンテナ基盤に乗せて資産化する

[AWS Containers Advent Calendar 2023](https://qiita.com/advent-calendar/2023/aws-containers) 1日目の記事です。

定期的にちょこっとスクリプトを叩くなど、補助的な役割をするEC2やLambda、
みなさんの環境にもたくさんあると思います。
もちろんこれらは素晴らしいサービスであり、
我々の日々の運用を支えてくれるものです。
ただ、これらをきちんと保守するフローや仕組みがあれば良いのですが
弊社の場合はそれがなく、負債となっていました。
このため負債を解消すべく、コンテナ化しつつアプリケーション側の実行基盤に載せ替えることで
運用保守をしやすくする改善活動を続けています。

## こんなこいるかな

みなさんのAWSアカウントの中に、こんな子はいないでしょうか。

– cron起動で、RDSにSQLを流してメトリクスを取っているレジェンドEC2
– 定期的にOpenSearchのmergeをしているレジェンドLambda

サービスを提供するメインのインフラ基盤の傍らで、細かい管理系の処理を行っ

元記事を表示

AWS Glueを使用したS3からRDS(MySQL)へのデータ取り込み2

## Glue・RDS間の接続

まずはRDSへの接続から作っていく。

Glue→Connectionを選択し、「Create connection」ボタンを押下。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/390179/3a311941-f0ab-949a-1c52-12f35ad8d34d.png)

Name: 任意の名称を入力
Connection type: Amazon RDS
Database engine: MySQL
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/390179/8e31a83a-b09f-fa52-3d67-a9ab56f0acbf.png)

Database instances: 接続対象のRDSインスタンス
Database name:接続対象のデータベース名を入力
Credential type:Username and passwordを選

元記事を表示

AlexaでBedrockに質問をするスキル開発

# はじめに
こちらは
– [Alexa×BedrockでAWS最新ニュースキャッチアップアプリ コンセプト・設計](https://qiita.com/SawaShuya/private/a22645e54d75667c5148)
– [AWS Lambdaで自作RSSリーダー開発](https://qiita.com/SawaShuya/private/aa007d310bfd12c751af)
– [Self hosted AWS LambdaによるAlexaスキル開発](https://qiita.com/SawaShuya/private/2395a08f57c8988f3163)
– **AlexaでBedrockに質問をするスキル開発 (本記事)**

の連載記事です。前段の項目が完了していることを前提として書かれております。
本記事では以下のアーキテクチャの作成を目指して解説をしていきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/918398/59c74b9a-a

元記事を表示

AWS Lambdaで自作RSSリーダー開発

# はじめに
こちらは

– [Alexa×BedrockでAWS最新ニュースキャッチアップアプリ コンセプト・設計](https://qiita.com/SawaShuya/private/a22645e54d75667c5148)
– **AWS Lambdaで自作RSSリーダー開発 (本記事)**
– [Self hosted AWS LambdaによるAlexaスキル開発](https://qiita.com/SawaShuya/private/2395a08f57c8988f3163)
– [AlexaでBedrockに質問をするスキル開発](https://qiita.com/SawaShuya/private/46c47068dd2573359c8b)

の連載記事です。本記事では以下のアーキテクチャの作成を目指して解説をしていきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/918398/bca51a92-e2aa-7dc0-f93f-f5daed47ba18.pn

元記事を表示

【AWS re:Invent 2023】re:Inventでヘルシー生活に目覚めそうな件

# はじめに

現地は2023年11月30日、本日4日目になります。本当にあっという間で寂しい限りです:cold_sweat:
連日ネットワーキングの場にも参加し、充実した期間でした。

さて、アメリカといえばピザやハンバーガー等高カロリーなものが多く日本と比べて意識しないとヘルシーに過ごすのが難しいというイメージがありました。

しかしre:Inventでは、ヘルシーな食事や取り組みが複数あり日本にいるより美意識があがるかも?と思いましたので、現地レポートとしてその様子をまとめてみたいと思います。

# アクティビティ

会議中にはアクティビティセッションとして、ヨガ体験と5Kランが開催されました!

日本にいますと運動が中々できていませんでしたが、海外といういつもと違う環境なのでチャレンジしてみようと思えますしヘルシーな1日を送ることができました🏃‍♂️

私はヨガに参加しましたが、頭をすっきりさせて自分自身と向き合う時間を強制的に30分取れたことで頭がすっきりしてヘルシーな気持ちになりました。

ヨガ体験の様子はこちらの記事でまとめておりますので、ぜひご覧ください!

https

元記事を表示

社内日報を内製化しよう(実装編)

# 経緯
https://qiita.com/miyasaka-anyplus/items/93cb293994dcf57ab4be

# 構成

構成はメインにAWS基盤を利用しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502127/ad92c2b7-c4a3-0c6f-e4fd-12aa7eeb6ff1.png)

– 開発言語: Vue
– フロント: S3 + Cloudfront
– API: APIGateway + Lambda
– DB: DynamoDB
– 認証: Cognito

# アプリダイジェスト

### ログイン画面

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502127/c6f073a7-a116-a455-c79b-9faa2f341175.png)

### メニュー画面

![image.png](https://qiita-

元記事を表示

Amazon Managed GrafanaからRDSの時系列データをリアルタイムに表示してみる

# はじめに

Amazon Managed Grafanaを使った時系列データのクエリの実装例が少なかったので記事を書いてみました。

– 以前、Grafanaは少しだけ記事にしました。
– https://qiita.com/jnit/items/49f4954f8a7667e4a440#%E6%89%80%E6%84%9F

– 最近OpenSearchがニューラル検索に対応し、「リアルタイム可視化」という点でGrafanaとOpenSearchの棲み分けの方向性が明確になってきたように思います。
– https://aws.amazon.com/jp/about-aws/whats-new/2023/11/amazon-opensearch-neural-search/
– 個人的には単純なリアルタイム可視化であればGrafanaがよいのではと思います。

## 構成

各サービスのデータ連携は、すべてVPC内でセキュアに通信するようにしてみます。

![image.png](https://qiita-image-store.s3.ap-northea

元記事を表示

とりあえずEC2上でCGI連携のnginx+React+Laravelアプリを動かしてみよう

### 1. 概要
こんな記事のタイトルにしてみましたが、要はCGIでアプリを動かしてみましょうという記事です。
ですので、「CGIなんて知っているよ〜(笑)」というエンジニアの皆さんは、そっと「閉じる」ボタンを押してください。多分、初歩的なことしか書いていないので、、、

で、この記事を読んで、「勉強になった」と思ってもらう想定する読者層は、
* 開発はしたことあるけど、リリースまではしたことないエンジニア

かなと思っています。

### 2. 記事作成のきっかけ
開発を中心に対応していた私は「CGI」のことを知らなかったので、
「え、、、フロント側って“`npm serve“`とかで動いてないの!?」
「Laravelって“`php artisan serve“`で動いてないの!?」みたいな感じでした。

もしかしたら同じ思考のエンジニアの方々がいれば、何かの助けになるかと考え、
このテーマで記事を書いてみようと思いました。

ただ、この記事のタイトル通り「とりあえず動かしてみよう」のレベルで、実際に手を動かして、とりあえず大枠を把握しようというお話です。

ですので、機

元記事を表示

AWS CodeDepoly デプロイ時にエラーになった場合のログの確認方法(EC2)

##

– CodeDeployにてエラーになった場合にログを見る方法を簡単にまとめる。

## 方法

複数の方法があるようだが、今回はEC2インスタンスにログインし、デプロイ時のログファイルを実際に確認する。

1. EC2インスタンスにssh接続する。
1. 下記を実行してサーバー内のログファイルを確認する。

“`
less /var/log/aws/codedeploy-agent/codedeploy-agent.log
“`

元記事を表示

OTHERカテゴリの最新記事