- 1. 【AWS】高額請求にはもううんざり!RDSの自動起動で知らないうちに課金される状況の回避策を考えてみる。
- 2. Glueジョブの自己参照インバウンドルールに苦しめられている同士へ
- 3. Amazon Connect で自動認証を利用したコールフローを実装
- 4. Athenaで基礎からしっかり入門 分析SQL(Python・Pandasコード付き) #1
- 5. python3.7でローカルからLambda関数をデプロイする手順
- 6. SoracomBeamのUDP → HTTP/HTTPS エントリポイントを経由してAWS API Gatewayからレスポンスを取得する
- 7. 【Mac terminal】SSH接続でパーミッションエラーになる
- 8. CloudWatch Logs InsightにてAPI Gatewayのアクセスログ用のクエリを書いてみた
- 9. AWSの勉強してるときよく見る単語集その②
- 10. internalのNLBとログ出力用のS3バケットを構築するCloudformaitonの例
- 11. HTTPS通信でアクセス可能にする
- 12. CloudFormationでEC2インスタンスがALBのヘルスチェックに合格したらスタックの更新を続行する方法
- 13. ALBのヘルスチェック結果を確認するPowerShellスクリプトを書いてみた
- 14. ALBのリスナールールを自動で切り替えて、更新中だけメンテナンス画面を表示する方法
- 15. ALBのリスナールールを自動で切り替えるLambda関数
- 16. Lambda関数のCloudwatchEventsトリガー一覧を取得する
- 17. NginxのアクセスログからELBのヘルスチェックを除外する方法
- 18. [ Rails & Nuxt ] AWS ECSを使ってデプロイをする
- 19. AWS 認定セキュリティ–専門知識(SCS-C01)取得するまでにやったこと
- 20. 仮想MFAデバイスの設定時に発生した「エンティティは既に存在しています」の調査
【AWS】高額請求にはもううんざり!RDSの自動起動で知らないうちに課金される状況の回避策を考えてみる。
#はじめに
こんにちは。突然ですがAWSアカウントを検証用途などで自己保有していて、リソースの消し忘れで高額請求された経験のある方はいらっしゃいますか?
**わたしはあります。**しかも過去に2度も。。。
どちらもAuroraを終了ではなく停止にしていたことで、停止してから7日後に自動起動してしまい、請求が来た時に初めて課金額が高額になっていたことがわかった、という経緯でした。
私の場合はAWSの勉強をし始めたときに**「検証で利用したリソースは検証が終了したらすぐに削除すること」**と口酸っぱく言われていたのですが、「また使うかも?作り直すのも面倒だし、終了じゃなくて停止にしておこう」というもったいない精神が働いてしまって、2度も痛い目を見てしまいました。。
検証用リソースはすぐに削除するというのは大前提として、2度あることは3度あるとも言いますし、同じ失敗はしたくないのでリソースの削除を行わなかった場合の高額請求にならないための回避策を考えてみました。
#回避策
##構成図
回避策として、Auroraが起動したのをトリガーに、LambdaでAuroraを自動的に停止し
Glueジョブの自己参照インバウンドルールに苦しめられている同士へ
## 初めに
業務でGlueジョブのセキュリティグループを作成しようとした際に、「自己参照インバウンドルール」なるものに苦しめられ半日を溶かしたので、備忘録として残そうと思います。Glueジョブのセキュリティグループ作成につまずいている同士のお役にたてれば幸いです。
## 自己参照インバウンドルールって何?
### 公式のドキュメントを見てみる
公式のドキュメントには以下のように記載してあります。
https://docs.aws.amazon.com/ja_jp/glue/latest/dg/setup-vpc-for-glue-access.html> AWS Glue がコンポーネントと通信できるようにするには、すべての TCP ポートに対して自己参照のインバウンドルールを持つセキュリティグループを指定します。自己参照ルールを作成することで、ソースをすべてのネットワークではなく VPC 内の同じセキュリティグループに制限することができます。
日本語で書いてある気がするのですが、全く理解できませんした。
### 作成に成功した今だからわかる答え
自己参照インバウンド
Amazon Connect で自動認証を利用したコールフローを実装
**本記事では、Amazon Connect を使用したコンタクトセンターを想定し、着信があった際に自動認証を行った上でCCPへ着信させる方法を記載する。Amazon Connect 上で用意する電話番号の取得、ユーザー、ルーティングプロファイルなどの作成は割愛する。**
構成は以下のようなイメージ
Amazon Connect / Lambda / DynamoDB / SNS を使用する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1597898/7cd801f7-6a7d-3bf5-cf8a-56a30e181d23.png)#仕組みについて
① ユーザーが Amazon Connect の電話番号へ発信
② DynamoDB 上にある発信者番号のレコードを特定した場合、自動認証としてオペレーターと繋がる。
③ DynamoDB 上に発信者番号のレコードが存在しない場合、SMS を送信し、ワンタイムパスワード認証を実施する。
④ 認証が通れば発信者番号に Dynamo
Athenaで基礎からしっかり入門 分析SQL(Python・Pandasコード付き) #1
今まで複雑なデータ操作・分析などはPythonでやっており、SQLは普通のアプリ開発程度のライトなものしか触って来なかったのですが、やはり分析用の長いSQLなども書けた方がやりとり等で便利・・・という印象なので、復習も兼ねて記事にしておきます。
また、SQLに加えて検算も兼ねてPythonやPandasなどを使ったコードもSQLと併記していきます(Pythonで書くとどういった記述が該当するのかの比較用として使います)。
※長くなるのでいくつかの記事に分割します。本記事は1記事目となります。
# 特記実行
– お仕事がAWSなので合わせてDBはAWSのAthena(Presto)を利用していきます。BigQueryやRedshift、MySQLやPostgreSQLなどではある程度方言や使える関数の差などがあると思いますがご了承ください。
– 同様にお仕事がゲーム業界なので、用意するデータセットはモバイルゲームなどを意識した形(データ・テーブル)で進めます。
– Athenaなどでの分析利用が主なため、この記事ではテーブル作成・削除などにはほぼ触れずに読み込みや集計などをメイン
python3.7でローカルからLambda関数をデプロイする手順
# What’s this?
pipenvを利用してコマンド1発でローカル環境のソースコードをLmabda関数にデプロイする際の手順をまとめた記事です。# IAMからユーザー作成
最初にローカルからLambdaへのデプロイを実施するためのIAMユーザーを作成します。
IAM > ユーザー > ユーザーを追加からユーザーを作成します。今回はユーザー名「dev_user」で作成します。
アクセスの種類はプログラムによるアクセスにチェックします。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/566229/54d51d8c-0850-5bb1-de34-d8b3da250dd9.png)
アクセス権限は後から付与できるので一旦スキップしてユーザーを作成します。
ユーザー作成ができるとシークレットアクセスキーが発行されるのでダウンロードしてておきます。作成されたユーザーに対してLambdaのデプロイに必要なアクセス権限を追加します。
アクセス権限 > インラインポリシーの追加
SoracomBeamのUDP → HTTP/HTTPS エントリポイントを経由してAWS API Gatewayからレスポンスを取得する
SoracomBeamのUDP → HTTP/HTTPS エントリポイント + Raspberry Piを使用してAWS API Gatewayからレスポンスを取得する方法をまとめました
# はじめに
## SoracomBeam UDP → HTTP/HTTPS エントリポイントとは?
SoracomBeamのエンドポイントにUDPリクエストを送るとSoracomBeam側でHttpのPOSTリクエストに変換してくれる機能
この機能では嬉しいことにレスポンスを返してくれるため、UDPを使用しているにも関わらずHTTPのレスポンスを受け取ることができる
詳細は
https://users.soracom.io/ja-jp/docs/beam/udp-http/
に記載されています。なお、ポイントとしては
“`
リクエストBeam は送信されたメッセージを Base64 エンコードしたうえで以下のような JSON にし、HTTP POST リクエストのボディに設定します。
“`
の2点
– SoracomからはPOSTでメッセージは送られる
– メッセージはBase64にエン
【Mac terminal】SSH接続でパーミッションエラーになる
# はじめに
Mac使い一日目、いつも通りAWSのインスタンスにterminalを使ってログインしようとしたらパーミッションエラーが発生する。“`
Warning: Permanently added ‘52.196.196.190’ (ECDSA) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for ‘/Users/yanagimorisatsuki/Documents/SAA/udemy-sample-mac.pem’ are too open.
It is required that your private key files are
CloudWatch Logs InsightにてAPI Gatewayのアクセスログ用のクエリを書いてみた
##背景
API Gatewayを外部からの窓口とするシステムにて、システムへのアクセス数を集計する必要があったので、CloudWatchに出力しているアクセスログをインプットにAPI Gatewayへのリクエスト数を集計することにした。アクセスログは、API にアクセスしたユーザーと、呼び出し元が API にアクセスした方法を記録するログで、アクセスが発生する度に以下の形式のログレコードが生成される。
“`json:アクセスログの形式
{
“requestId”:”8d2f5138-019f-449c-bde7-432ff3cb49a1″,
“ip”: “103.4.xxx.xxx”,
“caller”:”-“,
“user”:”-“,
“requestTime”:”13/Feb/2021:07:45:36 +0000″,
“httpMethod”:”GET”,
“resourcePath”:”/hello”,
“status”:”200″,
“protocol”:”HTTP/1.1″,
“responseLength”:
AWSの勉強してるときよく見る単語集その②
## はじめに
[その①](https://qiita.com/pankata79/items/bbc511f4faba0ad574f4)の続きになります!
内容はざっくりです!
よろしくお願いします!(。・ω・)ノ゙## プロキシサーバー
プロキシサーバーとは**インターネットへのアクセスを代理で行うサーバー**のこと。通常はパソコンやモバイル端末を経由して直接Webサイトへアクセスし、サーバーがデータをブラウザに返すことで画面にサイトが表示される。
これに対してプロキシサーバーを使用するとブラウザで直接Webサイトにアクセスせずにプロキシサーバーにアクセスし、代わりにプロキシサーバーがサイトにアクセスし画面にサイトを表示してくれる。## スキーム
スキームとは**体系的な計画・計画を伴う枠組み・体系的な構想・基本的な仕組み**などの意味を持つ英単語。
単純な工程表や組織図のようなものではなく、関係する人や組織、モノ、システムなどの機能や役割、権利や権限、相互の関連性などを挙げ、また、これらの要素間のお金や情報、指示や手続きのなどの流れを体系立てて記述したものを意
internalのNLBとログ出力用のS3バケットを構築するCloudformaitonの例
private-nlb-httpsという名前のNLBと、ログ出力用のS3バケットです。これを元に設定作るようにシンプルにしてあります。
– HTTPSで受けてバックエンドは80で受ける設定です
– 証明書はACMにアップロード済みを想定しています
– NLBは2つのサブネットにデプロイすることを想定してたパターンです
– S3のバケットポリシーは[こちらの公式ドキュメント](https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/load-balancer-access-logs.html#access-logging-bucket-requirements)を参考にしています“`yaml
—
AWSTemplateFormatVersion: “2010-09-09”Parameters:
NLBName:
Type: String
NLBTargetGroupName:
Type: String
VpcId:
Type: AWS::EC2::V
HTTPS通信でアクセス可能にする
# 内容
この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
前回の記事「独自ドメインを設定する/障害時はSORRYページへ通信を流す」の続きです。
##### 前回の記事
https://qiita.com/zakinicof/items/6c973c1aed9ebdeeb845
前回までの構成はブログサービスにアクセスするのにHTTPで通信をしていました。
このままではセキュリティに問題があるため、よりセキュアなHTTPSで通信できるように設定を変更していきます。
HTTPS通信をするために必要な証明書を`AWS Certificate Manager`というAWSで証明書を管理できるサービスを利用します。
AWS Certificate Managerで証明書を発行してELBにアタッチすることでHTTPS通信を可能にしていきます。
その他、ELBのセキュリティグループでHTTPS通信を許可する設定の追加なども行なっていきます。
![スクリーンショット 2021
CloudFormationでEC2インスタンスがALBのヘルスチェックに合格したらスタックの更新を続行する方法
# 結論
[AWS::CloudFormation::Init](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-init.html)を使いましょう!
ということなのですが、ここで出てくる`cfn-init`やら`cfn-signal`にかなりハマったので、調査した結果と実際の使用方法を紹介します。# きっかけ
とあるプロジェクトで、
**「EC2がALBのヘルスチェックで`healthy`になるまで更新を一時停止したい」**
という目的がありました。## なぜ?
CloudFormationによるAuto Scalingグループの置換更新で起動したEC2インスタンスにアクセスできなかったためです。
問題は、
**「ALBのヘルスチェックの結果に関わらず、CloudFormationの更新が完了する」**
ということでした。
具体的には、新しく起動したEC2インスタンスに対するALBのヘルスチェックの結果が`unhealthy`なのに、古いAuto Scaling
ALBのヘルスチェック結果を確認するPowerShellスクリプトを書いてみた
CloudFormationからEC2インスタンスを起動する際、ALBのヘルスチェックをクリアするまで後続の処理を止めておきたいというときに作成したスクリプトです。
PowerShellの超初心者が書いた内容ですが、参考になれば幸いです。# スクリプト
“`powershell:HealthCheck.ps1
# UTF8にエンコード
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8# 起動したEC2インスタンス自身のIDを取得
$data = Invoke-WebRequest http://169.254.169.254/latest/meta-data/instance-id -UseBasicParsing
$id = $data.Content# ALBによるヘルスチェックの結果を取得
$state = Get-ELB2TargetHealth -TargetGroupArn <ターゲットグループのARN> -Target @{Id = $id} -Select TargetHealthDescri
ALBのリスナールールを自動で切り替えて、更新中だけメンテナンス画面を表示する方法
CloudFormationによるリリース時にメンテナンス画面とEC2のサイトを自動で切り替えるために、ALBによるリスナールールを使用しました。CloudFormationからでなくても自動切り替えは可能だと思うので、参考になれば幸いです。
# 経緯
Auto Scalingグループ内のEC2インスタンスが常時1台という要件のもと、CloudFormationによるリリース時に、一時的にALB配下に2台のEC2インスタンスが起動するタイミングがあり、新旧どちらのインスタンスにも接続できてしまう状況が発生しました。これを解決するために、リリース中(CloudFormationによる更新中)はメンテナンス画面を表示し、更新が完了したら新しいEC2に接続するという挙動を目指しました。更新が完了した時点で古いEC2インスタンスはALBから登録解除されているので、更新完了後は新しいEC2インスタンスにのみ接続されるようになります。# 構成図
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1
ALBのリスナールールを自動で切り替えるLambda関数
[SetRulePriorities](https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/APIReference/API_SetRulePriorities.html) APIを使用して、ALBのリスナールールを自動で切り替える関数です。
CloudFormationからSNS経由で通知を受け取り、CloudFormationによる更新中はメンテンナンス画面を表示し、更新が完了したらEC2のサイトを表示するというルールの切り替えを行います。# 概要
– ランタイム:`Node 14.x`
– アクセス権限:
– `AWSLambdaBasicExecutionRole`
– `ELB v2 SetRulePriorities`(カスタムポリシーで選択する)
– 環境変数
– `LogicalResourceId` : 更新するCloudFormationスタック名
– `ForwardRuleArn` : ターゲットグループへの転送ルールのARN
– `MaintenanceRu
Lambda関数のCloudwatchEventsトリガー一覧を取得する
# はじめに
最近、Lambda関数のトリガー画面が少し変わりました。
以前まではCloudwatch Eventsをトリガーに設定していた場合は、そのトリガーが有効なのか、無効なのかが表示されていました。
現在はその有効・無効が表示されなくなったので、元々設定されていたトリガーの状態がひと目でわからなくなりました。。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/296479/318c1c75-30a7-96aa-1729-0d4ece5f3211.png)# AWSCLIからCloudwatchEventsトリガーの一覧を取得する
現在、どのトリガーが有効かをマネジメントコンソール上から判断できるのはできますが、Cloudwatch Eventsのルール数や元々設定していたトリガーが多いとかなり面倒です。[^1] [^2]
AWSCLIで有効なCloudwatchEventsトリガーの一覧は下記で取得できます。“`bash
aws events list-rule-nam
NginxのアクセスログからELBのヘルスチェックを除外する方法
# 方法
/etc/nginx/nginx.confのhttpモジュールを以下のように編集。
“`conf
http {
/* 省略 */map $http_user_agent $log_ua {
~ELB-HealthChecker 0;
default 1;
}
access_log /var/log/nginx/access.log main if=$log_ua;/* 省略 */
}
“`
[ Rails & Nuxt ] AWS ECSを使ってデプロイをする
| No. | タイトル |
|:-:|:-:|
| 1 | [Dockerで開発環境を構築する](https://qiita.com/15recruit15/items/85ab5bbf6b900c004186) |
| 2 | [ログイン認証を機能を実装する](https://qiita.com/15recruit15/items/9d6803ad4aa412848a4f) |
| 3 | 記事投稿機能を実装する |
| 4 | [AWS ECSを使ってデプロイする](https://qiita.com/15recruit15/items/73eea044288bfdbb4fa0) |
| 5 | Circle CIを使って自動テスト•デプロイをする |
—
##はじめに
Rails & Nuxtでポートフォリオを作成するシリーズの第4弾になります。
全5部構成でDocker,CircleCI,AWS等のモダンな技術を組み込んだ作品を完成させる予定です。本章ではAWSのECSを利用してアプリのデプロイを行います。
以下、完成イメージ
![AWS_インフラ.png](htt
AWS 認定セキュリティ–専門知識(SCS-C01)取得するまでにやったこと
![qiita_2021-06-22_15h26_41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/534812/bdd82023-950b-aad7-92d4-77b02a624060.png)
## はじめに
DX 技術本部の yu-yama です。
AWS 認定セキュリティ–専門知識(SCS-C01)を取得したので取得までの流れを記します。
## 受験前の AWS 経験
AWS 経験は 4, 5 年で、コアサービスは開発側/運用側一通り触っており、以下の認定を取得しています。
1. SAA (2020年6月)
– [AWS 認定ソリューションアーキテクトアソシエイト\(SAA\-C02\)取得するまでにやったこと](https://qiita.com/yu-yama-sra-airline-erp/items/7d30c3772c3075837939)1. DVA (2021年1月)
– [AWS 認定 デベロッパー – アソシエイト\(DVA\-C01\)取得
仮想MFAデバイスの設定時に発生した「エンティティは既に存在しています」の調査
# 仮想MFAデバイスの設定時に発生した「エンティティは既に存在しています」の調査
## 背景
社内の方からAWSを利用したいのでアカウントの作成を依頼されました。
アカウントの作成後、セキュリティ強化のため、設定登録を必須としているMFAデバイスの登録を依頼。
ところが、以下のようなエラーが発生してしまいました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/589067/b773e3f4-c55d-0b2d-7d05-2f28239d40c4.png)## 参考
[AWS MFA 設定で「エンティティは既に存在しています」エラーの解決方法](https://qiita.com/codenote_net/items/055d1265d9fbb7ee142b)
## 環境
せっかくなので、先日構築したdocker desktop for Windowsに移設(コピー)したaws-cliのコンテナで作業してみることにします。
[]()
## コンテナの起動
まずはdo