- 1. ハマりポイントから学ぶ ALB と NLB の違い
- 2. AWSにARMプロセッサー環境のOpenShiftをデプロイ
- 3. Lambdaで画像分類AIをサーバレスAPI化して得た5つの知見
- 4. デプロイ時に「No space left on device」が出た時の対処法
- 5. オンプレミスから Elastic on AWS への Elastic ワークロード移行を自動化するための10のステップ
- 6. Laravel 9 を ECS on Fargateで運用にするにあたり、Tipsまとめ
- 7. Elastic と AWS：すぐに使用できる統合プラットフォームでログとメトリックをシームレスに取り込む
- 8. SPA+CloudFrontマルチオリジン構成で「/」以外へのアクセスをルーティングする
- 9. Terraformで作ったAWSリソースの情報をWebpackで動的にJavascriptに埋め込む方法
- 10. AWS WAFをAPI Gatewayに設定してみた
- 11. Amazon EC2にJavaアプリをデプロイする方法（war&jar）
- 12. AWS公式資料で挑むSCS認定(29)-こんな時どうする(全分野その6)
- 13. [AWS SAM] Preflight(OPTIONS)をLambda関数で自作する(複数originの許可対応)
- 14. AWS VPCエンドポイント メモ
- 15. AWS Internet Gateway と NAT Gateway メモ
- 16. [AWS SAM] CORS対応のためのシンプルなOPTIONメソッドをSAMで自動生成する
- 17. API Gatewayを試してみた（REST API）
- 18. Amazon Connect Streams で独自アプリケーションと連携できる カスタム CCP を作成してみた
- 19. AWS公式資料で挑むSCS認定(28)-こんな時どうする(全分野その5)
- 20. API Gatewayを試してみた
ハマりポイントから学ぶ ALB と NLB の違い
# はじめに
NLB を利用した構成でハマったポイントがあったため、ALB との違いを交えて紹介します。構成図はこちらです。
NLB を選んだ理由は L4 でトラフィックルーティングしたかったからです。
ALB を挟んで SSL オフロードしたりせず、HTTPS のまま EC2 まで到達させます。# ポイント
ポイントとなる ALB との相違点は下記になります。* NLB は Security Group をアタッチできない
* NLB はクロスゾーン負荷分散はデフォルトで無効# ハマリポイント1 ｜ NLB からのヘルスチェックに失敗する
### 事象
ターゲットグループで設定しているヘルスチェックが成功せず、`Unhealthy` 状態になっていました。
ヘルスチェックのプロトコルは `TCP` 、ポートは `T
AWSにARMプロセッサー環境のOpenShiftをデプロイ
# はじめに
今回は、OpenShift4.10でGAとなった、ARMプロセッサー環境へのOpenShiftインストールを試してみます。# ARMプロセッサーとは
ARMプロセッサーとは、ARM社が開発しライセンス販売を主体に提供しているCPUで、様々な企業がARMアーキテクチャを活用した独自CPUを作成しています。近年ではAppleがM1プロセッサーを作成したことで一般的な認知度も上がってきていますが、かねてよりiPhoneやAndroidスマホ、カーナビやゲーム機など様々なシーンで使われてきました。2017年で210億以上の出荷実績があり、後述するようにサーバ環境でも積極的に活用されてきているので、今後ますます出荷台数が増えていくことが予想されます。
このARMプロセッサーですが、高い消費電力性能が大きなメリットとして挙げられます。そのため、このCPUを活用することで、よりコストパフォーマンスの高い環境を構築しサービスを提供できるのではないか、ということで注目されています。
しかしこのような進化を遂げたのはスマートフォンが登場してからになるため、PC/サーバーのCPU
Lambdaで画像分類AIをサーバレスAPI化して得た5つの知見
AWS上でAIを実現する場合は通常SageMakerを使いますが、軽量なモデルを使う場合であればサーバーレスで実現することもできると思い環境を構築しました。実際に構築することで得た知見を5つ紹介します。
以下のチュートリアルで作成した犬と猫を見分けるモデルを使用しました。
https://www.tensorflow.org/tutorials/images/classification?hl=ja
// 余談ですが、言語表示を英語にすると、犬と猫の識別ではなく、花の分類に題材が変わります。
# TenslorFlowのライブラリーはCPU版を指定する
Lambdaでの推論はCPUで行いますので、TensorFlowのライブラリーもCPU版を指定します。
また、内部で使用するKerasのバージョンも合わせておかないとエラーとなりま
デプロイ時に「No space left on device」が出た時の対処法
# 前提条件
Rails 6.1.3
Ruby 2.6.5
# エラーメッセージ
“`
DEBUG [c2dc48df] 不能: No space left on device
tar: vendor/bundle/ruby/2.6.0/gems: mkdir 不能: No space left on device
“`# 結論
このコマンドを打てばいいです。“`サーバー環境
$ sudo rm -rf /var/www
“`
“`
$ sudo mkdir -p /var/www/$APP_NAME
“`“`
$ sudo chown `whoami`:`whoami` /var/www/$APP_NAME
“`# 補足
“`
$ df -i
ファイルシス Iノード I使用 I残り I使用% マウント位置
devtmpfs 121336 292 121044 1% /dev
tmpfs 123584 2 123582 1% /dev/shm
tmpfs
オンプレミスから Elastic on AWS への Elastic ワークロード移行を自動化するための10のステップ
皆様こんにちは！
Elastic テクニカルプロダクトマーケティングマネージャー/エバンジェリストの鈴木章太郎です。
Elastic の Qiita の Organization もでき、個人のエントリとは別に、その中のエントリとしても、ブログを定期的に書いていきたいと思います。こちらの組織は、メインは弊社のソリューションアーキテクト4名、コンサルタント3名、ですが、僕も技術マーケッターとしてブログを書いていきますので、よろしくお願いします。自己管理の Elastic ワークロードを Elasticon Amazon Web Services（AWS） に移行して、コスト、時間、スケールの効率を活用する準備はできていますか？AWS で開発したベストプラクティスとツールを活用して、迅速でスムーズな移行を保証します。セルフサービスの移行パスオプションを実行してから、移行を自動化するための簡単な「ハウツー」手順を実行してみましょう。
# オンプレミスデータセットを AWS 環境の Elastic に追加するためのパスの選択
オンプレミスデータセットを AWS 環境の Elastic
Laravel 9 を ECS on Fargateで運用にするにあたり、Tipsまとめ
# はじめに
下記の続きになります。タイトル通り、Fargateを運用にするにあたり、Tipsまとめます。https://qiita.com/holdout0521/items/241df305a90af3ccf973
# 事前構築
下記の記事で、fargateを構築済みhttps://qiita.com/holdout0521/items/241df305a90af3ccf973
ソースに関して、mainブランチは、この記事の対応前のソースになります。
この記事の対応後のソースは、feature/tipsブランチにあります。https://github.com/yuji-hirai/laravel-ecs
# tips
– envファイルをs3に保管
– Basic認証とヘルスチェックを通す
– Laravel.logをCloudWatchLogsに出力
– EFSを利用
– AWS Graviton2を利用し、コスト削減# envファイルをs3に保管
envファイルは、`API_KEY`などがあるため、GitHubに載せたくないです。
envファイルをS3
Elastic と AWS：すぐに使用できる統合プラットフォームでログとメトリックをシームレスに取り込む
皆様こんにちは！
Elastic テクニカルプロダクトマーケティングマネージャー/エバンジェリストの鈴木章太郎です。
Elastic の Qiita の Organization もでき、個人のエントリとは別に、その中のエントリとしても、ブログを定期的に書いていきたいと思います。こちらの組織は、メインは弊社のソリューションアーキテクト4名、コンサルタント3名、ですが、僕も技術マーケッターとしてブログを書いていきますので、よろしくお願いします。## Elastic AWS 統合プラットフォームについて
多くの組織は、俊敏性とコスト効率のメリットのためにアマゾンウェブサービス（AWS）を使用しています。アプリケーション、インスタンス、およびコンテナーをすばやくスピンアップするときは、環境全体の操作の包括的なビューを維持し、さまざまなソースからリ
SPA+CloudFrontマルチオリジン構成で「/」以外へのアクセスをルーティングする
# やりたいこと
AWS CloudFront ではリクエストパスのパターンに応じて、１つのドメインから複数のオリジンにアクセスを振り分けることができます。
以下のように、S3 でフロントエンドの SPA を配信し、バックエンドを API Gateway で提供するようなマルチオリジン構成を考えます。
# SPA を CloudFront + S3 で配信する時の問題点
SPA を CloudFront + S3 で配信する時に問題になるのが、ルートパス (“/”) 以外の URL に直接アクセスしたときに 403 エラーが発生するという現象です。
例えば `https://example.com/page1` という URL にアクセスしたとき、実際に S3 上に `/page1` というオブジェクトが存在しないため、403
Terraformで作ったAWSリソースの情報をWebpackで動的にJavascriptに埋め込む方法
# はじめに
Javascriptで開発をしていると困るのが、Terraformで作ったAWSリソースのURIが動的に払い出されてしまうため、開発環境とプロダクション環境で冪等にスクリプトを作れないということがあるのではなかろうか。今回は、Webpackを使ってどんな環境でも同じコードベースで動作するように定義することをチャレンジしてみたい。
なお、今回の例ではフロントエンドのフレームワークにはVue.jsを使用している。
Vue.jsの基本的な文法や環境構築は別途前提知識として備えていることを前提としているのでご留意いただきたい。# Javascriptの設定
さて、URIはどこに埋め込んでも良いが、main.jsなりapp.jsなりのメインに、Vue.mixinを使って埋め込むのがシンプルで良いのではなかろうか。
定数なので、グローバルとして保持しても特に問題ないだろう。
今回は、Javascriptの環境変数として保持しておきつつ、バンドル版にパックするときに置換する仕組みとする。
これにより、ローカルテスト時は環境変数をlocalhostにしてあげればモックに向けて通
AWS WAFをAPI Gatewayに設定してみた
# 背景・目的
[API Gatewayを試してみた（REST API）](https://qiita.com/zumastee/items/b11bb6653f3f46adb674)で作成したAPIに、AWS WAFを設定してみます。# サマリ
– WAFは簡単に構築でき、AWSリソースに簡単にアタッチ可能でした。
– ルールが最新化されていき信頼性が高いと感じました。
– AWS Managerdルール、Market Placeのベンダールールが豊富にあり、要否を判断するには、深い知識が求められ選定が難しそうと感じました。# 概要
## そもそもWAFとは？
– [Wikipedia](https://ja.wikipedia.org/wiki/Web_Application_Firewall)の内容を以下に抜粋します。
> Web Application Firewall（略称:WAF、ワフ）とはウェブアプリケーションの脆弱性を悪用した攻撃からウェブアプリケーションを保護するセキュリティの一種[1]。– Web Application Firewallの略。ワフといい
Amazon EC2にJavaアプリをデプロイする方法（war&jar）
Amazon EC2にJavaアプリをデプロイする方法をwarファイルとjarファイルそれぞれメモとしてまとめます。
これはAWSでEC2インスタンスを作っている前提でまとめていますので、ご了承願います。ちなみにEC2はLinux2です。
# warファイルのデプロイ
## １、EC2にJava17をインストール
EC2にJava17をインストールします。Javaのバージョンは適宜読み替えてください。
OpenJDKをダウンロード
“`
$ wget https://download.java.net/java/GA/jdk17/0d483333a00540d886896bac774ff48b/35/GPL/openjdk-17_linux-x64_bin.tar.gz
“`ダウンロードしたものを展開
“`
$ tar xvf openjdk-17_linux-x64_bin.tar.gz
“`展開したものを移動
“`
$ sudo mv jdk-17 /opt/
“`パスを通す
“`
$ sudo tee /etc/profile.d/jd
AWS公式資料で挑むSCS認定(29)-こんな時どうする(全分野その6)
##### [前回] [AWS公式資料で挑むSCS認定(28)-こんな時どうする(全分野その5)](https://qiita.com/mingchun_zhao/items/c393843c62f253cf8cba)
## はじめに
引き続き、「こんな時どうする」です。
「分野1: インシデント対応」ネタ切れ寸前。。。## 分野1: インシデント対応
– 特定IPからVPCサブネットへDDoS攻撃が報告された
– NACL(ネットワークアクセスコントロールリスト)のインバウンドルールで、問題IPからのアクセスを拒否
– ※ SG(セキュリティグループ)は拒否ルール設定できない(許可のみ)– EC2インスタンスへのアクセス侵害が報告された、セキュリティグループでリソースへの無制限アクセスが許可されていないかチェックしたい
– AWS Trusted Advisorを使用し、セキュリティグループをチェック
– リソースへの無制限アクセスを許可するルールがないか確認
– 無制限アクセスは、悪意あるアクティビティ(
[AWS SAM] Preflight(OPTIONS)をLambda関数で自作する(複数originの許可対応)
# この問題にぶつかるまでの経緯
– 単純でないリクエストでPreflightリクエストが送られるが、そこで特定の2種のoriginからのリクエストのみパスさせたい
– 本番環境では `Access-Control-Allow-Origin: “*”` はもちろんだめなので
– しかし、`Access-Control-Allow-Origin: “https:hoge.com,https:huga.com”` のような形式で複数のorigin を指定することはApiGatewayの仕様上できないらしい
– ではどうするか？次のように考えた
– PreflightリクエストはOPTIONS
– OPTIONSメソッドを自分で作ったLambda関数に統合して、定義したホワイトリストに合致するoriginからのリクエストだった場合パスさせるようにする# 対応方法まとめ
– 複数originのCORS許可対応をさせたいメソッドについて
– (下記手順内の例ではExampleFunctionというGE
AWS VPCエンドポイント メモ
* VPCエンドポイントについてメモする。
## 概要
* VPCと他サービスの通信を可能にするVPCコンポーネント。
* VPC内のインスタンスとVPC外のサービスをプライベート接続で通信できる。
* インターネットゲートウェイを経由せずに済む。## 用途
* セキュリティ上の理由でインターネットに接続せずにサービス接続したい場合に利用する。
## 3種類のエンドポイント
* 次の3種類のエンドポイントが存在する。
* インターフェイスエンドポイント
* ゲートウェイエンドポイント
* Gateway Load Balancer エンドポイント### インターフェイスエンドポイント
* サービスのエンドポイントとENI(Elastic Network Interface)をPrivateLinkでリンクするエンドポイント
* `Static NAT` : プライベート IP とパブリック IP が 1 対 1 で変換する。
* internet Gatewayとのやり取り
* パブリックサブネット：〇
* プライベートサブネット：×## NAT Gateway
* プライベートサブネット内のインスタンスからVPC外のサービスに接続するためのAWSコンポーネント。
[AWS SAM] CORS対応のためのシンプルなOPTIONメソッドをSAMで自動生成する
# 前置き
– 正直この記事はどうでもよくて、本当に書きたい記事の説明のための内容だったりします…
# 対象となる状況
– シンプルなCORS対応のためのOPTIONSメソッドを全メソッドに付与したい
– 例えば、動作確認のため「許可するoriginは ”*(全て)” または “任意の1origin” 」でOKな状況など# 環境
– macOS: Big Sur v11.6.1(Intel)
– バックエンド(Lambda関数を呼び出すAPIをSAMで構築する)
– SAM CLI: 1.42.0
– Runtime: node.js 14.x (Typescript)# 手順
## 1. API GatewayにCORSを設定する
– template.ymlに次の記載を行い `$ sam deploy` することで、GETやPOSTが設定されているエンドポイントにOPTIONSが自動で付与される
“`template.yml
Globals:
Api:
++ Cors:
++ Al
API Gatewayを試してみた（REST API）
# 背景・目的
以前、「[API Gatewayを試してみた](https://qiita.com/zumastee/items/1625106991a680cd41a3)」でAPI GatewayをHTTPで作成したが今度はREST APIを作成します。# 実践
## REST APIの作成
1.REST APIを選択し、「構築」をクリックします。
2.以下を入力し、「APIの作成」をクリックします。
## リソースの作成
1.プルダウンから「リソースの作成」をクリックします。
デフォルトの CCP より、更に便利な機能を利用したいときに、自分たちで独自のカスタムCCPを構築できます。カスタムCCP は、Amazon Connect Streams という npm や GitHub で公開されているライブラリを活用して、自分たちの好きなようにカスタマイズできます。JavaScript を経由して Amazon
AWS公式資料で挑むSCS認定(28)-こんな時どうする(全分野その5)
##### [前回] [AWS公式資料で挑むSCS認定(27)-こんな時どうする(全分野その4)](https://qiita.com/mingchun_zhao/items/6e46410c6e6a9f230c6c)
## はじめに
「こんな時どうする」佳境入りましたが、
予防接種3回目も頭痛や熱出るんですね。## 分野1: インシデント対応
– AWS Configによりコンプライアンス違反が通知された、すぐEC2インスタンスを終了させたい
– CloudWatch Eventsを使用し、AWS Lambda関数をスケジュールする
– Lambda関数を使って、EC2インスタンスを終了させる
– ※ イベント管理は、CloudWatch EventsよりAmazon EventBridge がより多くの機能を提供## 分野2: ログとモニタリング(監視)
– EC2インスタンスにアタッチされたEBSボリュームが暗号化されているか監視したい
– AWS Configのルール識別子`ENCRYPTED_VOLUMES`を使用し監視
API Gatewayを試してみた
# 背景・目的
– [LambdaからDynamoDBを操作する](https://qiita.com/zumastee/items/93f9301e7c8cea8883c0)で作成したLambdaをWebリクエストをもとに実行したい。
– 今回は、API Gatewayを使って実行する。
– 本ページでは、まずAPI Gatewayのチュートリアルを対象とし、実際に接続する方法は次回以降に試す。
# 概要
## API Gatewayとは
– REST、HTTP、WebSocketなどのAPIを作成、公開、維持、モニタリング、セキュア化するためのサービス
– 最大で数十万個の同時 API コールの受け入れ処理に伴うすべてのタスクを取り扱う## 特徴
– ステートフル (WebSocket) およびステートレス (HTTP と REST) API のサポート。
– 強力で認証メカニズム
– IAMポリシー
– Lambdaオーソライザー関数
– Cognitoユーザプール
– API発行するための開発者ポータル
– 変更を安全に進めるためのCanaryリリ
