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

【2024/09アップデート】Redshiftで、Amazon Qを利用したクエリ自動作成が使えるようになりました

# はじめに
株式会社ジールの @oreo_tです。
2024/9/17のアップデートで、RedshiftでAmazon Qを利用したクエリ生成ができるようになりましたので紹介しようと思います。
「こういうデータが見たい」というのを言葉で書くことによって、その内容に合わせてAmazon QがRedshiftで実行できるクエリを生成してくれるというものです。
以下、公式情報のリンクです。
https://aws.amazon.com/about-aws/whats-new/2024/09/amazon-q-generative-sql-amazon-redshift/

# 設定方法
まずAWSのコンソールからRedshiftの画面を開き、「クエリエディタv2」を選択します。

クエリエディタの画面が開けたら、左のメニューから歯車のアイコンを選択

Amazon SQSを使用してEvent Bridgeでタスク起動失敗時に通知を送ってみる

# 概要

EventBridge + ECSを使用したバッチ処理実行を行う時、何らかの理由でECSタスクが起動できないエラーが発生することがあります。この記事では、エラー内容を確認するためのSQSを使用した仕組みを考えてみます。また、SQSに入ったメッセージを検知して、CloudWatchから通知を送信する仕組みも考えてみます。

なお、EventBridgeからECSタスクを起動する方法についてはAWS公式に説明があるため、本記事では省略します。

[Amazon EventBridge スケジューラを使用して Amazon ECS タスクをスケジュールする](https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

# 今回使用する技術
**Amazon SQS**
キューにメッセージを保存しておくサービス。今回はEventBridgeでイベント実行が失敗した際にメッセージを保管しておく場所として使用します。

**A

【AWS】API Gateway Privateについて

API Gatewayは、下図の通り4種類あります。プライベート API Gateway の「プライベート」とは、「パブリックから直接アクセスできない」となるだけで、あなただけがアクセスできるプライベートネットワーク内の API という意味ではありません。（だって、それって VPC ですよね。API Gateway は VPC に属しません）
なので、AWS のプライベートネットワーク内においては特に制限をしない限り、誰でもアクセスできる API Gateway です。
プライベート API GatewayはIn

Amazon Linux 2023にPHPとWordPressをインストールする方法

## はじめに
Amazon Linux 2023(AL2023)で作成したEC2にPHPとWordPressをインストール機会がありましたので、インストール方法について自分のための備忘録を兼ねて記載します。
## 前提
・AWSアカウントがあること
・Amazon Linux 2023のEC2が作成済みであること
・作成したEC2にパブリックIPでアクセスできること
※ターミナルエミュレーターとしてTera Termを利用しています。
## やること
※今回はバージョンを指定してインストールするやり方になります
・PHPは「8.1」のヴァージョンをインストールします。
・WordPressは「6.0.1」のヴァージョンをインストールします。

## PHPをインストール
EC2にログインできている状態で以下のコマンドを入力します。
ルートユーザーに移行します。
“`
[ec2-user@]$ sudo su root
“`
最新のアップデートを確認します。
“`
[ec2-user@]$ dnf update
“`
PHP 関連の利用可能なパッケージのリストを表示します。

Cloudflare Zero Trust と Amazon Cognito の Single Logout (SLO) について考える

# セッション管理
以下の記事にある通り、Cloudflare Zero Trust の ID 認証先に Amazon Cognito を OIDC で連携することができます。

https://qiita.com/khayama/items/dcd5b2fc51b7435e1765

その際には、それぞれのユーザセッションはそれぞれの Cookie にて管理されます。

– Cloudflare Zero Trust
– `CF_Authorization` Cookie で管理されます。

https://developers.cloudflare.com/cloudflare-one/identity/authorization-cookie/

– Amazon Cognito
– `cognito`、`cognito-fl` Cookie が使用されます。

https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens

[WARNING]: ! Unable to write cache: {“code”:”ERR_BAD_REQUEST”,”message”:”Request failed with status code 404″})}の解決方法

## はじめに

amplifyでいつものようにデプロイを行うと、なぜかデプロイが転けてしまい、
解決に時間がかかったのでまとめます。

## 問題と原因

CDを走らせると以下のような警告が出ました。

“`bash
[WARNING]: ! Unable to write cache: {“code”:”ERR_BAD_REQUEST”,”message”:”Request failed with status code 404″})}
“`

原因としては、すでに削除したリモートブランチと同じ名前のローカルブランチを作成し、
プッシュしてPRを立てると、リモートブランチ側との整合性が取れなくなり、キャッシュエラーが起きたみたいです。

## 解決方法

シンプルにAmplifyのGUIにある、プロジェクトキャッシュ削除をするだけで解消しました。
amplify.ymlに`envCache –set stackInfo “”`を書いてもいけるみたいです。

## おわりに

こういうエラーは大元のコードがどういう処理をしているかが見えないのでデバッグしづらいですね。
ほなま

APIGatewayとStepFunctionでの非同期実行時に使えるマッピングテンプレートの工夫

# はじめに
APIGatewayには、**最大29秒までの実行時間制限**があります。しかし、意外と簡単にその制限を超えてしまうことがあります。
最近では、申請をすればこの制限を延ばせるようですが、そもそも**長時間待たせる設計は良くない**と考え、下記のように非同期実行に変更しました。

# 本題
StepFunctionとAPIGatewayの非同期実行については、多くの情報が既にあるのでここでは詳細は割愛します。
今回は私が実践したアプローチをご紹介します。

1. APIGatewayからStepFunctionを非同期で実行します。この際、**実行完了を待たず**に、StepFunctionの**実行ARN**をすぐにレスポンスとして返します。
2. そのARNを使って、StepFunctionの**実行が完了しているかを確認**します。

StepFunctionに渡すデータの形式は決まっており、以下のような形になります。

“`
// リクエストのマッピングテンプレート
#set($input = $input.json(‘$’))
{
“input”:

CodeCommitとGitLabを操作するテスト

# CodeCommitの設定
AWS CLIインストール
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html

IAMユーザ→セキュリティ認証情報タブ→アクセスキー

“`
aws configure
“`
ここでアクセスキーを入力するよ。以下のファイルが生成される。これでawsにアクセスできるはず

“`bash:疎通確認
aws ec2 describe-instances
“`

“`C:\Users\XXXXX\.aws/credential
[default]
aws_access_key_id = XXXX
aws_secret_access_key = YYY
“`

“`C:\Users\XXXXX\.aws/config
[default]
region = ap-northeast-1
output = json
“`

これも必要になるかも
IAMユーザ→セキュリティ認証情報タブ→AWS CodeCommit の HTTPS Gi

AWS 認定 DevOps Engineer – Professional(DOP-C02) 合格体験記

# 本記事の概要
AWS 認定 DevOps Engineer – Professional(DOP-C02)を取得したので振り返りや学習方法をまとめます。（以下DOPとします）
経歴としては文系新卒でSIerに入社しIT、AWS歴は約1年です。


# なぜ資格取得を目指したか
これまで頼りにさせていただいたチームの先輩が転職することになり、自分もAWS領域では早く1人前にならねばと思ったことと、自分が業務で使用しているサービスについて意識的に学習する時間を作ろうと思ったことがきっかけです。

# 業務、学習状況
入社から一貫してAWSを使用したサーバレスでのアプリケーション構築に携わっています。
特に使用しているサービスは、APIGateway,SQS,Lambda,EvevtBridge,DynamoDB,Codeシリーズです。

ECRの脆弱性対策(ベーシックスキャンと拡張スキャン)

## ECRの脆弱性対策
ECRには、コンテナイメージ内の脆弱性の特定をする**イメージスキャン**がある。
イメージスキャンは、以下2種類。
– ベーシックスキャン
– 拡張スキャン

|| ベーシックスキャン | 拡張スキャン |
|:———–|:————|:————|
| スキャン対象 |OS| OS
プログラミング言語 |
| スキャンのタイミング | ECRへのプッシュ時
手動 | ECRへのプッシュ時
自動連続 |
| スキャン内容 | 脆弱性情報 | 脆弱性情報
診断結果に基づく対応策の表示
修正バージョン |
| スキャン結果の確認方法 | ECRコンソール | Inspectorコンソール
ECRコンソール
SecurityHubコンソール |
| 料金 | 無料 | ECRでは料金発生しないが、Inspectorのコストがかかる
[東京リージョンの場合]
1 か月あたりの Amazon ECR へのプッシュ時に最初にスキャンされたコンテナイメージ数：イメージごとに

WSL2でAWSを使うための環境構築（Node/Python）

## 目次

– VSCodeのインストール
– WSL2(Ubuntu)の構築
– node.js環境構築
– python環境構築
– その他開発環境構築
– aws関係

## VSCodeのインストール

– Windows環境で行う
– インストール方法は省略
– WSLでの利用に備えて最低限以下のExtensionを入れる
[Remote Development](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack)

## WSL2(Ubuntu)の構築

### 参考記事
– 下記の記事が大変分かりやすいためそちらを参照
[WSL2 のインストールとアンインストール](https://qiita.com/zakoken/items/61141df6aeae9e3f8e36)

– 過去にUbuntu環境を作っていたがそのパスワードがわからなくなった場合
[wsl でパスワードを忘れてしまった際の対処](https://qiita.

AWSのSAAをYoutubeで1か月勉強して受けた結果

## はじめに

### スペック
AWS
– 構築　3か月
– CloudFormationを触っていた
– 逆にコンソールからの構築経験なし

ネットワーク
– 構築・運用　3年半
– FW、LB、SWあたりのコンフィグは触れる

## 勉強法

### Youtube

– SAAの参考問題を解説してくれている動画を暇なときひたすら見る
– 問題でわからないサービスがでてきたら解説動画を見る

下記の関連動画を見ていました。ご参考までに。
同じチャンネルに大量の動画が上がっているかと思います。

### 問題解説の動画