- 1. AWS EC2(Elastic Compute Cloud)の概要
- 2. sagemakerを活用したモデル開発フロー
- 3. There was an error creating this change set (Part 1)
- 4. CloudFrontとElasticBeanstalkを使った際のHTTPS化
- 5. UMLを少しでも かわいく したかったのでAWSで解決した
- 6. 【ASW】AWS APIの認証・認可の仕組みを理解する【Signature V4】
- 7. [aws,rails]ancestryをawsにデプロイした時に反映されない状況の解決方法
- 8. AWS Cognitoのユーザー属性をAWS CLIから変更する
- 9. 言語別AWS SDKのパフォーマンスの一検証
- 10. EC2にSSH接続可能ユーザーを追加する
- 11. EKS (on Fargate) + ALB Ingress Controller環境をスクリプト1つで構築する
- 12. [小ネタ] Nuxt on AWS Lambda では serverMiddleware 使えばいいよねって話
- 13. S3を最速でhttps化する手順と全設定項目
- 14. Railsで作ったアプリをAWSでデプロイ⑨ 〜S3を利用する〜
- 15. AWS IoT CoreでBulk Provisioningを使ってIoTデバイスを一括登録してみる
- 16. S3に関するIAMユーザー作成
- 17. Railsで作ったアプリをAWSでデプロイ⑧ 〜Capistrano導入〜
- 18. Railsで作ったアプリをAWSでデプロイ⑦ 〜Nginx導入〜
- 19. Pythonを使ったBasic認証の設定
- 20. S3(Static website hosting) + ACM + CloudFront + Route53で静的コンテンツ公開
AWS EC2(Elastic Compute Cloud)の概要
#Amazon EC2とは
• 数分で起動し、1時間または秒単位の従量 課金で利用可能なAWSクラウド上の仮想サーバー
• サーバーの追加・削除、マシンスペック変 更も数分で可能
• 管理者権限(root / Administrator) で利用可能
• インスタンスという単位でサーバーが管理し、ボタンクリックや、CLIでインスタンスを作成可能
• EC2インスタンスはVPC内で起動するAZサービス
• OSまでは提供されているタイプを選択することで自動設定され、OSより上のレイヤーを自由に利用可能##EC2インスタンス作成手順
1.利用するAMIイメージ(OSセッティング)を選択
2.インスタンスタイプを選択
3.ストレージを選択
4.セキュリティグループを選択
5.SSHキーペアを設定#1. AMI (Amazon Machine Image) とは
インスタンス起動に必要なOSイメージ
sagemakerを活用したモデル開発フローSageMakerを活用したモデル開発フロー
https://qiita.com/noko_qii/items/41130f66afbb8e451f23
There was an error creating this change set (Part 1)
![1.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/456186/c63e7873-5c22-902f-2241-b9bfda91725a.jpeg)
![2.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/456186/af6eaca4-b93c-35b1-da8c-f6a291a06c9f.jpeg)##エラーメッセージ
There was an error creating this change set
1 validation error detected: Value ‘{InstanceId=}’ at ‘resourcesToImport.1.member.resourceIdentifier’ failed to satisfy constraint: Map value must satisfy constraint: [Member must have length less than or
CloudFrontとElasticBeanstalkを使った際のHTTPS化
CloudFrontとElasticBeanstalkを併用する構成の場合にどうやって通信をHTTPS化するを解説します。
# ざっくり概要
– CloudFrontだけじゃなく、ElasticBeanstalkの方にもドメイン名を指定しておくと便利です。
– ユーザーとCloudFront間の通信だけではなく、CloudFrontのオリジンとなるとElasticBeanstalk間の通信もHTTPS化します。
– ElasticBeanstalkはCloudFrontを経由しないアクセスを制限するために別途設定を追加します。![Untitled Diagram.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/47882/51d4d2cd-7058-e7b0-c6ce-f6977668f050.jpeg)
# ドメイン設定
CloudFrontの方をexample.com、ElasticBeanstalkの方をserver.example.comと設定することにします。# CloudFron
UMLを少しでも かわいく したかったのでAWSで解決した
#注:UML初心者に向けた記事です
AWS提供の画像を利用しますがAWSのサービスは使用しません。
—## 環境設定とねらい
Visual Studio Code だけでUMLを練習する環境を作ります。Mac, Windows, Linuxで動きます。—
## 用意するもの
– Visual Studio Code
– [PlantUML 拡張](https://marketplace.visualstudio.com/items?itemName=jebbs.plantuml)
– Java(ふつうは[入ってます](https://java.com/ja/))
– GraphViz([msiインストーラあり](https://graphviz.gitlab.io/_pages/Download/Download_windows.html))上記の手順についてわからない人は[Visual Studio Code で UML を描こう!](https://qiita.com/couzie/items/9dedb834c5aff09ea7b2)が完璧
【ASW】AWS APIの認証・認可の仕組みを理解する【Signature V4】
# はじめに
Amplifyを利用してアプリケーションを作る場合、Cognito User Pool/Cognito Identity Pool(Cognito Federated Identities)を利用してAPI GatewayでAuthorizationする方法が暗黙裡にデフォルトになっているように見えます。
よく使われるであろうと思われる割には、その仕組みについての説明があまり見当たらなかったので解説記事を書こうとしましたが、前提となる事項があまりにも多いことが分かったので、個別の記事として分離しました。本稿では、AccessKeyIdやSecretAccessKeyの使われ方、AWS APIにおけるSignature V4の仕組みなどについて解説します。
API GatewayのAuthorization方式として「AWS_IAM」という項目を選択できますが、本稿の内容を理解することで、この方式の具体的な仕組みついて理解できるようになります。# TL;DR
– AWSが提供する機能の殆ど、最終的にRESTFul APIとなる(本稿ではAWS APIと呼ぶ)
– A
[aws,rails]ancestryをawsにデプロイした時に反映されない状況の解決方法
#1.どんな状態だったか
ancestryを利用して、railsのプロジェクト内にあらかじめデータは作成してあり、ローカルでは動くのに本番環境で反映されないという状態でした#2.原因
ancestryはdb/seeds.rbにデータを保存するのですが、このseedファイルを利用するには、データベースの作成コマンドの他にseedを読み込むコマンドを打つ必要があるのですが、それを忘れてしまっていました。#3.解決方法
`RAILS_ENV=production bundle exec rails db:seed`というコマンドを打っていただければ反映できます。
※コマンドの説明
・本番環境なので`RAILS_ENV=production`が必要です
・読み込みを早くするためにrailsの実行コマンドの中からdb関係のコマンドがあえて除かれていることがあるので、`bundle exec`をつけています。(はじめに無しで実行してダメだったらつけていただいても良いと思います)#4.記事の目的
チーム開発をする時に、筆者のようにデプロイを担当する人間が知らない技術が取り込まれることはよ
AWS Cognitoのユーザー属性をAWS CLIから変更する
## 背景
AWS Cognitoユーザープール管理下のユーザの標準属性・カスタム属性値をAdmin権限的に変更するときに少し手間取ったので自分用メモとして…。
2020/03/12現在、コンソールからこの機能は利用できないので、AWS CLIで操作した場合の方法です。この操作が行えるIAM権限が必要となりますのでご注意ください。## 環境
– AWS CLI: `aws-cli/1.15.11 Python/2.7.16 Darwin/19.2.0 botocore/1.12.33`
– AWS CLI Command Referenceバージョン: 1.18.19## 解説
今回利用するコマンドの公式ドキュメントです。
[admin-update-user-attributes — AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/admin-update-user-attributes.html)
以下に、属性の値によって考慮すべ
言語別AWS SDKのパフォーマンスの一検証
# 背景
## タグについて
AWSはリソースに[タグ](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Using_Tags.html)の付与が可能です。AWSにおけるタグはリソースの管理や[コスト配分](http://blog.serverworks.co.jp/tech/2019/07/29/cost-alloc-tags-basic/)の用途で用いられ、タグの付与設計はAWSの運用において非常に重要なポイントとなります。
特に大規模な環境や組織になるとリソースに付与するタグは非常に多くなる傾向があります。## AWS SDK for Rubyのパフォーマンス
[こちらの記事](https://qiita.com/kure/items/19b1c17a56d81e2bb955)でも言及したようにAWS SDK for Ruby では、リソースにタグが大量に付与されている場合、一度に大量のリソースを取得する場合に大幅に時間がかかることがあります。
以下はEBSを例に、タグ付与のあり・なしとで、リソースの取得(d
EC2にSSH接続可能ユーザーを追加する
# 内容
EC2へSSH接続する際に公開鍵認証を使用して、Amazon Linux2であればec2-user以外で
接続できるようにするため新しいユーザーを作成する。# 対象機器
EC2(Amazon Linux2)# 参考手順
手順は以下のAWS公式を参考にしています。
[Amazon EC2 を使用してキーペアを作成する](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-key-pairs.html#having-ec2-create-your-key-pair)
[ユーザーアカウントを作成する](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/managing-users.html#create-user-account)# ハンズオン
## キーペアの作成(AWSマネジメントコンソール使用)
**EC2へ接続するキーペアが存在していれば実施不要です。**AWSマネジメントコンソールへログインし、[サービス]⇒[コンピュー
EKS (on Fargate) + ALB Ingress Controller環境をスクリプト1つで構築する
# はじめに
昨年の12月、みなさんが待ちに待ったEKS on Fargateが[正式発表](https://aws.amazon.com/jp/blogs/news/amazon-eks-on-aws-fargate-now-generally-available/)されました。
これによりノード管理から解放され、Fargateを利用するようになる人も増えるのではないかと思います。ただ、そこで問題になるのが EKS on Fargate におけるいくつかの制限です。
> – 各ポッドが使用できるのは最大 4 vCPU と 30Gb のメモリです。
> – パーシステントボリュームやファイルシステムで必要とされるステートフルなワークロードのサポートは、現時点ではありません。
> – Daemonsets、Privileged ポッド、または HostNetwork または HostPort を使用するポッドは実行できません。
> – 利用できるロードバランサーは、Application Load Balancer だけです。公式ブログ参考: [AWS Fargate 上の
[小ネタ] Nuxt on AWS Lambda では serverMiddleware 使えばいいよねって話
かなりの小ネタです。
[aws-serverless-express](https://github.com/awslabs/aws-serverless-express) を使うと Nuxt が Lambda で動くというのは既出記事でたくさんあるんですけど、そのほとんどが公式の通りに以下の様な実装になってます。
“`js
const awsServerlessExpressMiddleware = require(‘aws-serverless-express/middleware’)
app.use(awsServerlessExpressMiddleware.eventContext())
“``aws-serverless-express/middleware` のソースコードを読んでみたら、普通にNuxtの `serverMiddleware` で動きそうだったため、やってみたら動きましたとさ。
“`js:middleware/aws-serverless.js
const middleware = require(‘aws-serverless-expre
S3を最速でhttps化する手順と全設定項目
# 対象の読者
– とにかくS3を独自ドメインでhttps化したい人
– たまにこの要件に対応する度にググって調べている人
– S3をhttps化する手順と設定項目が全部記載されているマニュアルを探している人**https化対応前の構成**
**https化対応後の構成**
# 手順と設定項目
作業手順は以下の3つです。
1. ACM(Amazon Certificate Manager)で証明
Railsで作ったアプリをAWSでデプロイ⑨ 〜S3を利用する〜
前回までにCapistranoの自動デプロイを学習しました
今回はAWSが提供するS3という画像ストレージサービスがあるので、
投稿した画像はS3に保存されるよう設定していきたいと思いますまずS3のバゲットを作っていきます
S3用IAMユーザーでログインし、「S3」をサービスから検索します
すると
AWS IoT CoreでBulk Provisioningを使ってIoTデバイスを一括登録してみる
## 経緯
– IoT CoreでIoTデバイスを管理するようになるため、IoT Coreに大量のIoTデバイスを登録する必要がある
– Bulk Provisioning機能を使うことで、テンプレートを用いて複数のIoTデバイスを一括で登録する
– デバイス毎に異なる証明書やグループ、属性情報などを一括してプロビジョニングすることができる## 流れ
– Bulk Provisioningを実行するためのIAMロールを作成
– 初回だけ
– テンプレートを作成する
– 投入したいデータに応じてそのテンプレートを定義する
– 初回だけ
– 登録したいデータをまとめたJSONファイルを作成する
– 作成したJSONファイルをS3にアップロードする
– 登録する## 手順
#### 1.Bulk Provisioningを実行するためのIAMロールを作成
– `AWSIoTThingsRegistration` と `AmazonS3ReadOnlyAccess` の2つをAttachしたIotBulkProvisionigというRoleを作成#### 2.テンプ
S3に関するIAMユーザー作成
AWSが提供する画像ストレージサービスのS3を利用するためだけのIAMユーザーを作成します
ログイン画面→サービス→IAMと検索するとこの画面になるので、
個々のユーザー作成→グループの管理をクリックそのあとユーザーを追加をクリックするとこの画面にいきます
名前入力、項目チェックして次のステッ
Railsで作ったアプリをAWSでデプロイ⑧ 〜Capistrano導入〜
前回までにNginxというWebサーバを本番環境に導入しました
今回はCapistranoというgemを使って自動デプロイできるようにします
まず、ローカルのアプリにgemを導入します
“`rails:Gemfile
group :development, :test do
gem ‘capistrano’
gem ‘capistrano-rbenv’
gem ‘capistrano-bundler’
gem ‘capistrano-rails’
gem ‘capistrano3-unicorn’
end“`
gemを記述したらターミナルで以下を実行します
“`terminal:ローカル
bundle install
bundle exec cap install
“`Capistranoをインストールするとファイルがいくつか自動生成されるので必要なファイルをそれぞれ編集します
まずCapfileです“`rails:Capfile
require “capistrano/setup”
require “capistrano/depl
Railsで作ったアプリをAWSでデプロイ⑦ 〜Nginx導入〜
前回までにひとまずデプロイが完了しました
今回はWebサーバのNginxをEC2インスタンスに導入しようと思います
“`terminal:EC2インスタンス
$ sudo yum -y install nginx
“`
続いてNginxの設定ファイルを変更します“`terminal:
$ sudo vim /etc/nginx/conf.d/rails.conf
“`
vimコマンドで設定ファイルを開いて以下をコピペし自身のアプリに合わせて書き換えます“`terminal:/etc/nginx/conf.d/rails.conf
upstream app_server {
# Unicornと連携させるための設定。アプリケーション名を自身のアプリ名に書き換えることに注意。
server unix:/var/www/<アプリケーション名>/tmp/sockets/unicorn.sock;
}# {}で囲った部分をブロックと呼ぶ。サーバの設定ができる
server {
# このプログラムが接続を受け付けるポート番号
listen 80;
#
Pythonを使ったBasic認証の設定
# はじめに
LambdaでBasic認証って検索すると、Node.jsのものしか見つからなかったので書いてみた。
自身の備忘録も兼ねて。
Node.js版は、ぐぐるとすぐに出てくるので、ここでは触れないです。# コード
と言っても大したものではなく、Node.js版の焼き直しな感じです。
ただ、マルチアカウントに対応できるようになっている点はちょっと違う。“` Python
import json
import base64accounts = [
{
“user”: “user1”,
“pass”: “pass1”
},
{
“user”: “user2”,
“pass”: “pass2”
}
]def lambda_handler(event, context):
request = event.get(“Records”)[0].get(“cf”).get(“request”)
headers = request.get(“headers”)
S3(Static website hosting) + ACM + CloudFront + Route53で静的コンテンツ公開
静的コンテンツをサブドメインで公開したいとの要望を受けてセットアップした際の手順メモです。
# 前提条件/要件
* Route53で設定済みドメインのサブドメインとして公開する(レジストラのネームサーバーは設定済み)
* S3のStatic website hostingを利用する
* 証明書はACMで新規に発行する# S3のバケット作成/設定
## 名前とリージョン
* バケット名:今回利用するサブドメインと同じ名前にします。
* リージョン:東京リージョンを選択## オプションの設定
バージョニングなどの必要性はなかったので、デフォルトのままにしました。
## パブリックブロックアクセス
[パブリックアクセスをすべてブロック]のチェックを外します。
この後の手順でバケットポリシーで公開設定をします。
ACLによるアクセス制御は行わないので、ACL設定のブロックはチェックしてても良いはずですが、すべてチェック外れる設定にしました。## バケットポリシー
以下を参考に作成したバケットの`s3:GetObject`を許可するように設定します。
[ウェブサイト