AWS関連のことを調べてみた2022年06月05日

AWS関連のことを調べてみた2022年06月05日
目次

Workload Identity連携で、AWS Cloud9からPythonでGCP操作

# はじめに
AWSからGCPの操作がセキュアにできるWorkload Identity連携を、Cloud9上からPythonで試してみたので記事にしました。

# まとめ
– 認証ファイルのパスを、環境変数`GOOGLE_APPLICATION_CREDENTIALS`にセットする
– 対象プロジェクトを指定するために、別途環境変数`GCLOUD_PROJECT`にセット
– Cloud9から行う場合は、使用しているEC2にIAMロールを付与して使う
– Pythonライブラリをインストールする際、ローカルにインストールする`pip install -t .`だとうまくいかない

# 参考
GCP側の手順やCloud9の設定は以下のページが詳しいです。

https://tech.nri-net.com/entry/2021/07/01/111020

# やったこと
## GCP側
前回の記事をそのままやっています。

https://qiita.com/a_b_/items/f30b85be4f44ed1f620c#gcp%E5%81%B4

こちらで作られたファイルをそ

元記事を表示

ローカルにてLambda関数を組む二つ方法まとめ(VSCode,Pycharmなど)

方法としては下記の2種類です。

# 1、Dockerを利用してローカルで実行
手順は[この記事](https://qiita.com/zukakosan/items/9c01aba5ff537382c856)の通りですが、実際設定・実行する時は二つ問題が発見しました。
①VSCodeにの`app.py`ファイルには`Run Locally | Debug Locally | Configure`が表示せず、代わりに`AWS: Add Debug Configuration | AWS: Edit Debug Configuration`が表示しました。記事の[ここに書いている内容](https://qiita.com/zukakosan/items/9c01aba5ff537382c856#vscodeでlambdaをローカルテスト)と違います。なんか仕様変更らしいです。
`Add Debug Configuration`或いは`Edit Debug Configuration`をクリックしたら、`launch.json`デバッグ設定を追加しまして、`Edit SAM Debug C

元記事を表示

AWSで気づいたら課金されていたから調べた

■なんか請求来た
AWSで何となくインスタンスを作って遊んだのが1年前。その後何となくほかの無料サービスも使った気がする。
1年くらい放置していたらなぜが請求が来るようになった。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218589/f73df9c2-ea46-d2ad-7d30-8b63ca377045.png)

■止めたいので頑張って調べた
請求止めたい。
まずはインスタンスがないか調べてみた。
サービス>コンピューティング>EC2>ダッシュボードの画面を開く。
・・・インスタンスは「0」と表示されている。どうも放置したままのインスタンスはなさそうだ。

次にググったりしながらAWSコスト管理で、何に課金されているか調査してみた。
サービス>コスト管理>Cost Exploereの画面を開く。
・・・「EC2その他」に$1.9ほどコストが発生している。インスタンスないのに?
   EC2のオプションとか生き残っているのかな?
   データだけ残っているのかな?
   ???

元記事を表示

【boto3】API Gateway経由で一定時間以上起動しているEC2インスタンスを検知し、ユーザーに通知する

# はじめに

ご覧いただきありがとうございます。

業務の中でAmazon SageMakerを利用しているお客様と話すことがあります。
使用するノートブックインスタンスのスペックが高いので、起動し続けるとお金がかかります。

連続稼働時間を検知して自動通知を行えないかと試行錯誤する中で、そもそも普段使用しているEC2インスタンスの連続稼働時間を検知してユーザー通知する方法についても検討を行いました。

Lambdaを使用して「EC2インスタンスが一定時間以上稼働しているか確認して、1時間以上稼働していたらユーザー通知を行う」という検証を行ってみました。

# 概要

(★)がついているセクションは、手を動かして頂く項目です。

1. 今回の構成
2. 下準備(★)
3. EC2の連続稼働時間を検知するには?(★)
4. EC2をSysmtes Managerで扱えるようにする(★)
5. LambdaからEC2の連続稼働時間を取得する(★)
6. 稼働時間が一定時間を超えた場合、SNS通知を管理者に送る(★)
7. API Gatewayを経由した手動実行(★)
8. (おまけ

元記事を表示

API Gateway の Lambda オーソライザーをやってみた

# はじめに

API Gateway を使うとインターネット上に REST API を公開できます。インターネット上に公開する際に、特定のユーザーやシステムにのみアクセスを制限させたい場合があります。そういったときには、API Gateway の認証機能が便利に使えます。

API Gateway の認証機能にはいくつか種類があります。

– リソースポリシー
– IAM アクセス許可
– Lambda オーソライザー
– Cognito オーソライザー

それぞれの詳細が気になる方は、次の AWS Document をチェックしてみてください。
https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-control-access-to-api.html

今回は、Lambda オーソライザーを触っていきたいと思います。Lambda オーソライザーを使うことで、API Gateway に独自の認証機能を付与することが出来ます。

Lambda オーソライザーのざっくりイメージはこんな感

元記事を表示

【MongoDB】0から調べたMongoDB

## きっかけ
– とある案件でAWS DocumentDBを構築することになり、検証も兼ねてクエリ等実行する必要があったため、書籍を読んで勉強しました。

## 注意
– 書籍(英語)を読みながらメモをとったため、そもそもの理解が間違えている可能性もありますので、参考にされる際はご留意ください。

### 基礎コンセプト
– ドキュメント
– RDBの行に当たる
– キーはデータ型、大文字小文字で区別される
– キーの重複は不可
– コレクション
– RDBのテーブルに当たる
– Dynamic Schema(コレクション内に異なる形のドキュメントを持つ)
– コレクションを組織するためにサブコレクションという命名方法が使える(.で分ける。eg) blog.posts, blog.authors`)
– 機能上のメリットはなし

### ツール
– MongoDB shell
– MongoDB client
– Shellによる基本操作(CRUD)
– Create
– `db.movies.insertOne({name : “hogehoge”})`

元記事を表示

できるだけ安くブログを立ち上げたいので色々比較してみた

# はじめに
ブログ立ち上げてうきうきアフィリエイト生活!ってところはまだ見当がつかないけど
ブログ立ち上げるとなると
 ・サーバ構築
 ・WordPressセットアップ
 ・ドメイン取得
 ・アフィリエイト契約
 ・Googleアナリティクス設定
などが実践的に試せそうだな!って思ったので。実益も兼ねて挑戦しようと思う。

# 先に結論:amazon LightSail × WordPressでの構築がオススメ
ある程度、技術的に明るい人ならこの方式が一番いいかなって思いました。
「ブログ書きたいだけなんで、他は何も考えたくないんやー」って人はきっとConoHa WINGがいいんだろうと思いました。

# 選択肢を調べてみよう

こちらでは、ConoHa WINGの「WordPressかんたんセットアップ」を活用してのブログ構築を推奨している。
「WINGパックのベーシックプラン(1年契約、月額931円)」を契約したらいいよってことだそうです。

https://liberaluni.com/blog-3steps

こちらはもう少し技術的な要素が多く、amazon LightSai

元記事を表示

Certificate Authority Authentication (CAA) エラーにより、1 つ以上のドメイン名が検証に失敗しました。

# はじめに
Xserverで管理しているドメインのサブドメインに対してACMの証明書をリクエスト。
この際表題のエラーが発生。

# 原因
すでに他サービスで当該ドメインの証明書が発行されている。
今回は別チームが開発中のShopifyアプリで当該サブドメインのSSL設定が既にされてあった。

# 参考:CAAとは?

https://help.sakura.ad.jp/ssl/2347/?article_anchor=js-nav-0

元記事を表示

ECSをApp Meshで管理する際の、メッシュ内外の通信パターンについて

Elastic Container Service (ECS)をApp Meshで管理する際の以下通信パターンについて、自分なりの理解を整理
– メッシュ外 -> メッシュ内
– メッシュ内 -> メッシュ内
– メッシュ内 -> メッシュ外

## App Meshとは
App Meshは、AWS上においてサービスメッシュを提供するサービスです
サービスメッシュそのものについては、YouTubeにてAWS Japanの公式があげている[こちら](https://www.youtube.com/watch?v=ZwfdLAClzsc)の動画がわかりやすいです

App Meshは「仮想サービス」、「仮想ゲートウェイ」、「仮想ノード」、「仮想ルータ」などといった要素で構成されており、
これらの繋がりは[こちら](https://aws.amazon.com/jp/blogs/containers/introducing-ingress-support-in-aws-app-mesh/?nc1=h_ls)の公式ブログに載っているアーキテクチャ図がシンプルでわかりやすいです

本記事において

元記事を表示

【初心者】機械学習の分類・回帰の実装方法を試してみた

# 背景・目的
私は、現在データエンジニアリングを生業としています。普段は、データ基盤の構築や、パフォーマンスチューニングなどビックデータに関する業務に従事しています。
ビックデータの収集や、蓄積、分析などの環境構築の経験はそこそこありますが、機械学習による予測や分類などのスキルは持ち合わせていませんでした。
今まで機械学習を避け続けてきましたが、一念発起し学ぼうと思います。

学び方としては、AWS Certified Machine Learning – Specialty(以降、ML試験という。)の勉強を通して、理解を深めていきます。ML試験のガイドの第2分野に、探索的データ解析が登場しましたのでそこから学びたいと思います。

今回は、**機械学習の用途や種類**について学びたいと思います。

> 3.1 ビジネス上の課題を機械学習の課題として捉え直す
> 機械学習を使用する/使用しないタイミングを判断する
> 教師あり学習と教師なし学習の違いを知る

なお、過去の機械学習の調べてみたシリースは下記にまとめています。
– 2.探索的データ分析
– 2.1.モデリング用のデータをサ

元記事を表示

平日に起動するLambda関数を作成してみた

## 概要

平日の営業時間は処理を実行したいが、土日祝日は処理を動かしたくないケースがあるかと思います。
そこで平日のみLambdaを実行し、土日祝日はLambdaを実行しないようにする構成をCloudFormationで作成します。

## 今回の構成を作成する前に

まずは、月~金に処理を実行し、土日は処理を実行しない場合の構成をCloudFormationで作成してみます。

### 構成
構成としては以下のようなシンプルな形になります。

![構成図-1.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/78cd9af3-d899-dd43-3133-902f7c0122a3.png)

### リソースの作成に使用するファイル
リソースの作成には以下のテンプレートを使用します。

“`template.yaml
AWSTemplateFormatVersion: ‘2010-09-09’
Description: “Periodic Execution Function Templ

元記事を表示

Cloudfront + S3 + API GatewayでSPAとAPIを公開する時のTips

良くあるこのパターンですが、自分なりに辿り着いたプラクティスを紹介しておきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33070/b35f713b-1eb6-dcaa-59a3-01107fb26fef.png)

## 先に結論
– SPA: Cloudfront Functionsを使って拡張子付きのパスを/index.htmlに変更する
– API: Behaviorで/apiをAPI Gatewayに向ける

## 背景
今まで、Cloudfront + S3 でVueやAngular等のSPAアプリケーションを公開する場合、
存在しないパスにリクエストすることで、S3が403もしくは404を返す。
そのため、Cloudfront側でカスタムエラーページを作成し、/index.htmlにリダイレクトするような設定をしていた。

### よくある悩み1(SPAのパス問題)
本来キャッチすべき404があった場合でも気にせずリダイレクトされてしまう。
例えばCSSやJSの

元記事を表示

CloudFormationでS3レプリケーションを試してみた

## はじめに

本記事ではS3レプリケーション機能を使用して、S3オブジェクトが同一アカウントバケット間でレプリケーションされることを確認します。
なお、AWSリソース作成にはCloudFormationを使用します。

※S3やCloudFormationなどの具体的なサービスの説明は、本記事では割愛します。

## 概要

### 作成するAWSリソース

同一アカウントでS3オブジェクトをレプリケーションする際には、以下のAWSリソースを作成します。

※S3レプリケーションの詳しい内容を知りたい方は、[AWS公式サイト](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/replication.html)などをご参照ください。

| リソース | 概要 |リソース物理名|
|:———-:|:————————:|:————————:|
| S3バケット | 1.レプリケーション元

元記事を表示

DynamoDBのトランザクション処理についてAWS CLIで検証してみた

## はじめに
業務で、DynamoDBで2つのテーブルを扱う必要がでてきたのでトランザクション処理について動作検証しました。

## DynamoDBのトランザクションについて

DynamoDBが公式に機能として提供しています。

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/transactions.html

CLIの場合は、transact-write-itemsを使うことでデータ更新時のトランザクション処理を実装できるようだったので、ためしてみました。

https://docs.aws.amazon.com/cli/latest/reference/dynamodb/transact-write-items.html

https://amazon-dynamodb-labs.workshop.aws/hands-on-labs/explore-cli/cli-transactions.html

## 準備
2つのテーブルを作成
CLI用のアクセスキー取得及び設定
以下コマ

元記事を表示

Terraform でAWS 環境にDockle + git-secrets を組み込んだCIを構築する

# はじめに

コンテナセキュリティのガイドライン [NIST SP800-190(アプリケーションコンテナセキュリティガイド)](https://www.ipa.go.jp/files/000085279.pdf) では、イメージのリスクの1つとして **「イメージの設定の不備」** について言及されています。
さらに、NIST SP800-190 では、このリスクへの対策として、 **「セキュアな設定のベストプラクティスへの準拠を検証および実施するためのツールとプロセスを採用すること」** を推奨しています。

本記事では、この **「イメージの設定の不備」** へのリスク対策ツールとして、**Dockle** と**git-secrets** を採用し、このツール群を組み込んだCI パイプライン(ビルドのプロセス)をTerraform でAWS 環境に構築する方法を記載しています。

コンテナイメージのセキュリティ対策の一例として参考になれば幸いです。

# Terraform で構築する全体構成図
EC2のインスタンス接続にて、Apacheを起動する

・EC2にてインスタンスを起動→画面上部の接続を押す
・EC2 Instance Connectから接続
・Amazon Linuxのコマンドラインにて下記コマンドを入力
“`
$ sudo systemctl start httpd
“`
(https://www.youtube.com/watch?v=xXuAX1ctg9E&list=PLh6V6_7fbbo8gYuNbxWXuZhTmfxzYcL9A&index=2より)

EC2入門を動画にて勉強中なので、動画中を探し直さなくて良いように自分用メモ。
前回でpart5くらいまで続けて進めていたので、インスタンスを再起動したらApacheも止まることを知らずpart1から見直して探しました(・_・`)
よく考えたらxamppだって再起動後はstartを押さないと起動できないので、それと同じでしょうか。

元記事を表示

[AWS] [EC2] 踏み台サーバーに秘密鍵を送る方法

### 今回やりたかったこと
AWSについて勉強中です。
踏み台サーバー(パブリックサブネットに作成したEC2)に
秘密鍵(〇〇.pem)をコピーし、
バッチサーバー(プライベートサブネットに作成したEC2)にSSHで入りたい

### 前提
環境はcloud9です。
VPC内にパブリックサブネットとプライベートサブネット、EC2は既に構築してあります。

### 結論

注意:cloud9側で!
“`terminal:terminal
scp -i ~/.ssh/〇〇.pem ~/.ssh/〇〇.pem ec2-user@踏み台サーバーのパブリックipアドレス:.ssh/〇〇.pem
“`
上記コマンドで自分はできました。
cloud9側の秘密鍵が違うディレクトリにある場合は適宜変えてください!
scpはcp(コピー)をs(シークレット)にするコマンドです。大事なものはこのコマンドで送ります。

例↓
“`terminal:terminal
scp -i ~/.ssh/test.pem ~/.ssh/test.pem ec2-user@35.77.102.64:.ssh/tes

元記事を表示

さっくり解説するAmazon API Gateway

## はじめに
今回はAmazon API Gateway編です。
今まで以上に用語が多いですが、なるべく分かりやすい解説をしてみようと思います。

# Amazon API Gatewayとは

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/392337/417f63ac-7cfc-b52a-a95a-949bd3636ac1.png)

公式ドキュメントによると、

>フルマネージド型サービスの Amazon API Gateway を利用すれば、デベロッパーは規模にかかわらず簡単に API の作成、公開、保守、モニタリング、保護を行えます。API は、アプリケーションがバックエンドサービスからのデータ、ビジネスロジック、機能にアクセスするための「フロントドア」として機能します。API Gateway を使用すれば、リアルタイム双方向通信アプリケーションを実現する RESTful API および WebSocket API を作成することができます。API Gateway は、コ

元記事を表示

【2022年6月】AWS Amplify CLI セットアップマニュアル

# はじめに

いままでのAmplifyCLIのセットアップは下記の記事を参考にずっと行ってきましたが、そろそろバージョンも新しくなってきたので最新版でのセットアップ方法をまとめていきたいと思います。

[AWS Amplify CLIの使い方〜インストールから初期セットアップまで〜](https://qiita.com/Junpei_Takagi/items/f2bc567761880471fd54)

こちらの記事は、2018年に書かれており、Amplifyの始まりたての頃の記事ですが、初期の頃から本当にお世話になりました。ありがとうございます!!

# 環境
Amplify CLI 8.3.1
Node.js 14.19.2
npm 6.14.17

# セットアップ方法
## インストール
今回は、`8.3.1`のバージョンで設定を行っていきます。

“`console
$ npm install -g @aws-amplify/cli@8.3.1
“`

## AWSアカウントの紐付け

まずは以下のコマンドを実行します。

“`console
$ amplify co

元記事を表示

aws-vault で AWS Profile に対応していない AWS ツールを使おう!

## 困りごと

最近では AWS アカウントは MFA が有効化されてたり、Assume role でクロスアカウントで認証をしてたりします。
その為、AWS CLI では以下の様に `–profile {profile-name}` を用いて認証をしています。

“`shell
aws s3 ls –profile your-aws-profile
“`

しかし、世の中の AWS にアクセスするツールの全てが「AWS Profile を指定する機能」に対応している訳ではありません。
Terraform CLI 等、多くのツールは実行シェル上に、ただ単に以下の環境変数がセットされている事を期待しています。

“`shell
AWS_REGION=ap-northeast-1
AWS_ACCESS_KEY_ID=xxxxxxxxxxxxxxxx
AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxx

# Switch role (Assume role) の場合は、以下も必要.
AWS_SESSION_TOKEN=xxxxxxxxxxxxxxxx
`

元記事を表示

OTHERカテゴリの最新記事