AWS関連のことを調べてみた2020年01月13日

AWS関連のことを調べてみた2020年01月13日

S3にAWS CLIからアップロードすると「Access Denied」が発生した

#概要
ラズパイで撮影した画像をS3に送る時に、「Access Denied」が発生してS3にアクセスすることができず、解消に手間取ったので備忘録。

#事象
aws s3 cp test.jpg s3://test/

上記のコマンドでS3へ画像を送ると以下のエラーが発生する。

upload failed: ./kaitlyn-baker-vZJdYl5JVXY-unsplash.jpg to s3://paytest009a/kaitlyn-baker-vZJdYl5JVXY-unsplash.jpg An error occurred (AccessDenied) when calling the PutObject operation: Access Denied

IAMポリシーとか、IAMロールとかいろいろ見たけどどれも問題なさそう。

**ちなみにIAMユーザーに対してS3フルアクセスの権限を与えているので、ポリシーレベルでは問題ないはず。**

#原因
**MFAでの認証が取れていないため、アクセス拒否されていた。**

会社のAWS環境でなく個人のA

元記事を表示

AWS プレフィックス「mi-」が付いたマシン

> AWS Management Console で、プレフィックス「mi-」が付いたマシンは、オンプレミスサーバーまたは仮想マシン (VM) マネージドインスタンスです。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/managed_instances.html

元記事を表示

Lambdaを使用し、最新 AMI の ID を取得する関数を作成

1.最新 AMI の ID を取得する関数をLambdaで作成
2.カスタムリソースを作成

> カスタムリソースは関連付けられた Lambda 関数を起動します。関数をカスタムリソースと関連付けるには、Fn::GetAtt 組み込み関数を使用して、ServiceToken プロパティ用に関数の Amazon リソースネーム (ARN) を指定します。AWS CloudFormation は、カスタムリソースの宣言に含まれている追加のプロパティ (Region や Architectureなど) を入力として Lambda 関数に送信します。Lambda 関数は、これらの入力プロパティの正しい名前と値を判断します。

3.リージョンとインスタンスタイプの組み合わせを指定することで最新AMIを起動

参考
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/walkthrough-custom-resources-lambda-lookup-amiids.html
> Amazon Elastic Co

元記事を表示

AWS Trusted Advisor

### 結構いろんなことができる

AWS再入門 AWS Trusted Advisor編


#### 一例
– 関連付けられていない Elastic IP Address
– EC2 リザーブドインスタンスの最適化
– 使用率の低いAmazon EC2 Instances
– 利用頻度の低いAmazon EBSボリューム
– アイドル状態の Load Balancer

### Trusted Advisor チェック結果を Amazon CloudWatch Events でモニタリングする
https://docs.aws.amazon.com/ja_jp/awssupport/latest/user/cloudwatch-events-ta.html
> CloudWatch イベント を使用する際には、Trusted Advisor ワークフローの一部として次のターゲットタイプを選択できます。
>
> – AWS Lam

元記事を表示

CodeDeployフックのベストプラクティス

アーカイブが展開された時点で実行権限があるように、アーカイブ化前に実行権限を与えましょう。

CodeDeployフックのベストプラクティス

元記事を表示

Aurora グローバルデータベースの利点

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html
Aurora グローバルデータベースの利点
Aurora グローバルデータベースは、専用のインフラストラクチャを使用して、プライマリ DB クラスターとセカンダリクラスターの間で変更をレプリケートします。Aurora グローバルデータベースには以下の利点があります。

Aurora グローバルデータベースによるレプリケーションは、プライマリ DB クラスターのパフォーマンスに対する影響が一切ないか、限定されます。DB インスタンスのリソースは、全面的に読み取りおよび書き込みのワークロードに当てられます。

変更は、最小限の遅れ (通常は 1 秒未満) で AWS リージョン間でレプリケートされます。

セカンダリクラスターは、災害対策の高速なフェイルオーバーを可能にします。通常、1 分未満でセカンダリクラスターを昇格させて書き込みに対応できます。

★リモートの AWS リージョンのアプリケーション

元記事を表示

【AWS Cloud9 / Laravel 5.8】make:authして認証画面を作ったけどリンク先が反応しない

スクリーンショット 2020-01-13 1.03.27.png

こんにちは、にゃーんです。昨日Laravelを始めたばかりの者です。
たぶん初心者すぎて笑える内容です。どうか温かい目で見てあげてください。
間違いやまずい部分があれば訂正しますので、ご指摘あればお待ちしています。

#トラブル内容

####以下のサイトを参考にAWS Cloud9に登録して開発環境を整えた。
(バージョンはphp7.1、Laravelは5.8)

>参考: [AWS Cloud9 で Laravel を使ってみた。【環境構築】](
https://iwasawa-officialweb.com/2018/11/03/aws-cloud9-%E3%81%A7-laravel-%E3%82%92%E4%BD%BF%E3%81%A

元記事を表示

Amazon Linux2にPython3 -Django – mod_wsgi をインストール

#Pythonを使う案件が増えてきた!
プログラミング系の雑誌ではPythonがよく取り上げられていましたが、実案件でもPythonを使うことが増えてきました。
Pythonを使う大きな理由は、AI(機械学習)ライブラリが充実していることです。
今回もAIを使うのでPythonを使います。
WEBのアプリケーション・サーバー(中継?)としてはDjangoを使います。

また、インフラ側のクラウドはAWS(Amazon Web Service)です。
AWSを使う理由は。。。流行でしょうか。。。
他のクラウドでもいいと思うのですが、皆使っているという理由が多いような気が。。。

#EC2サーバーの準備
AWSのEC2インスタンス(仮想サーバー)を作成します。
あらかじめアプリケーションに特化したAMI(マシンイメージ)を選ぶこともでき、PythonやDjangoに特化したBitnami等のイメージも用意されているのですが、今回は一般的な、Amazon Linux2 (64bit版)を使い、Djangoをインストールします。
Amazon Linux2はCentOS7ベースに近いので、この

元記事を表示

AWS Amplify フレームワークの使い方Part3〜API設定編〜

# はじめに
AmpifyシリーズのPart3はAppSyncを利用できるようになるまでを解説していきます。

# APIの設定
`$amplify add api`から `$amplify push`まで。

## AmplifyにAPIを追加
まずはおなじみのコマンドから実行し、APIの設定を進めていきます。

“`console
$ amplify add api
“`
## サービスを選択
今回は、AppSyncを利用したいので、GraphQLを選択します。

“`console
? Please select from one of the below mentioned services GraphQL
“`
## API名設定
何でもいいですが、管理しやすいプロジェクト名などでいいと思います。

“`console
? Provide API name: API名
“`
## 認証形式
今回は、Cognitoを使った認証設定にしています。特段CRUDの権限を制限しない場合は、API KEYでOKです。(その他の選択肢は未検証)
Cognitoを選択すると、まだ

元記事を表示

AWS AmplifyのAuth.signUpでNoUserPoolError: Authentication Error

# 前提
AWS Amplifyでamplify add authした後に、Auth.signUp呼んだらエラー起きた場合。

# エラー内容

ConsoleLogger.js?36de:84 [ERROR] 59:18.392 AuthError -
Error: Amplify has not been configured correctly.
This error is typically caused by one of the following scenarios:

1. Make sure you're passing the awsconfig object to Amplify.configure() in your app's entry point
See https://aws-amplify.github.io/docs/js/authentication#configure-your-app for more information

元記事を表示

AWS AmplifyでVue.jsを使いたいときに読むべきドキュメント

# AWS Amplifyとは
mBaaSサービスの一つ。Firebase使ったら負けかなと思ったので手を出してみました。が、しかし、いきなりハマったので早速記事として残しておく。

# 結論
FRAMEWORK SUPPORTという章があるが、それをいきなり読むのは地雷。
Getting Startedで手を動かしながら理解を深めたのち、次に、FRAMEWORK SUPPORT(Vue)を読むとよい。
(Getting Startedだけ読んでもダメということが分かったので、Getting Started => FRAMEWORK SUPPORTの順に読むべしという内容に変更しました。)

## Getting Started(Vue)
https://aws-amplify.github.io/docs/js/start?platform=vue
Vue.jsのプロジェクトの作り方から、AWS Amplifyの初期化、APIモジュールの追加、デプロイしてAWS環境上で動作させるところまで一通り学べる。ここから始めるのが良い。

ドキュメントのトップ
https://aws-ampl

元記事を表示

[備忘録] AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト(SBクリエイティブ刊)

この記事は[AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト(SBクリエイティブ刊)](https://www.sbcr.jp/product/4797397390/)読了時の備忘録です。
正誤に関する情報が含まれていますが、公式の正誤表に反映されるまでのラグを考慮してQiitaでも公開しています。(出版社にはこのページのURLを送付しています)

## 底本

2019年5月30日 初版第2冊発行のデータを元にした2019年7月1日 電子版第2版を底本としています。

## 気になった点

| ページ | 元の記述 | 訂正やメモ |
|:--|:--|:--|
| 28 | DyanamoDB | DynamoDB |
| 55 | 0.95USD | 前述の0.129USDより価格が上がってしまっているので0.095USD? |
| 116 | 通信の暗号化; | 通信の暗号化: (めちゃ細かい) |
| 134 | (表の2つ目の)max_execution_time | [Redshiftのドキュメント](https://docs.aws.am

元記事を表示

不断のDevOps パイプライン: DynatraceとAWSで、シフトライト、シフトレフト、セルフヒーリングを実装する

######本記事は、[Dynatraceブログ](https://www.dynatrace.com/news/blog) にポストされた [” Unbreakable DevOps Pipeline: Shift-Left, Shift-Right & Self-Healing / Andreas Grabner ”](https://www.dynatrace.com/news/blog/unbreakable-devops-pipeline-shift-left-shift-right-self-healing/) の日本語翻訳(部分編集あり)になります。

本ブログは、[チュートリアル ”Dynatrace-AWS-DevOps Tutorial”](https ://github.com/Dynatrace/AWSDevOpsTutorial) の技術解説であり、シフトライト、シフトレフト、及びセルフヒーリング(自己修復)を、どのように継続的デリバリとディプロイメントパイプラインに実装するか、その方法について説明するものです。

このチュートリアルでは、フルスタックモニタリ

元記事を表示

【AWS完全に理解したへの道】 EC2 基本編

【AWS完全に理解したへの道】 EC2 基本編
[IAM 基本編](https://qiita.com/y-u/items/cef40fd249947687810e)
[VPC 基本編](https://qiita.com/y-u/items/40fa729d54ebab52fcb3)
[S3 基本編](https://qiita.com/y-u/items/9517ab2570a4e823fbb8)
[データベース(RDS/ElastiCache/DynamoDB)基本編](https://qiita.com/y-u/items/0d4a9e4ec6844b16b65c)

# EC2(Amazon Elastic Compute Cloud)
ハードウェアに事前投資することなく、必要な数の仮想サーバを起動して、セキュリティやネットワーキングの設定、ストレージの管理を行う。要件変更や需要増に対して、迅速に拡張または縮小できる。
# EC2に関連する主要コンポーネント
ここでは深く掘り下げないが、EC2に連携しているサービスは以下の図のような感じ。

元記事を表示

S3ファイルやDynamoDBレコードの自動削除

# S3ファイルやDynamoDBレコードの自動削除

この記事は[サーバーレスWebアプリ Mosaic](https://mosaic.w2or3w.com "Mosaic")を開発して得た知見を振り返り定着させるための[ハンズオン記事](https://qiita.com/w2or3w/items/87b57dfdbcf218de91e2)の1つです。

以下を見てからこの記事をみるといい感じです。
* [Lambda(Python) + Rekognition で顔検出](https://qiita.com/w2or3w/items/48bc05684c6dafbf5253)

## はじめに
S3やDynamoDBって、もちろん長期的に保存したい用途に利用することもありますが、一時的なデータ保存場所として利用するケースも多いですよね。ワタシのMosaicなんかも、30分くらいで消えてしまって何ら問題ありません。
そんな時は自動的に削除される仕組みがありますので、それを利用しましょう。

## コンテンツ
### S3ファイルの自動削除
上で「30分くらいで消えてしまって何ら問

元記事を表示

(Python)AWSの請求金額を取得する

# はじめに
AWS アカウントを取得したので、請求を管理したいと思う。
予定外の出費はできる事なら避けたい。
そこで、Python を使用して AWS の Cost Explorer から請求情報を取得する。

# 環境
実行環境は以下

```
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.1
BuildVersion: 19B88

$ python --version
Python 3.7.4
```

# API 仕様
- 合計請求額を表示する。
- 各サービスごとの詳細請求額を表示する。
- 請求金額取得対象期間は以下とする。
- START : API 実行日を含む月の1日
- END : API 実行日の前日
- API 実行日が1日だった場合、前月の請求額を表示する。

# API 実行日と実行月の1日を取得する
`datetime`パッケージを使用して以下のように実行日と実行月の1日を取得するメソッドを作成する。

```
from datetime import datetime, t

元記事を表示

AWSのセキュリティ

出展:[AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー](https://www.amazon.co.jp/AWS%E8%AA%8D%E5%AE%9A%E8%B3%87%E6%A0%BC%E8%A9%A6%E9%A8%93%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-AWS%E8%AA%8D%E5%AE%9A-%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%BC-%E5%B1%B1%E4%B8%8B-%E5%85%89%E6%B4%8B/dp/4797397403/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=3ERB303UT76DT&keywords=aws%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%83%97%E3%83%A9%E3%82

元記事を表示

AWSに構築したWordPressのエラーページを変更してみた

# はじめに
「[AWSにWordPressを構築してみた](https://qiita.com/olaf_system/items/e5e17cd8ead71ec9a096)」
「[AWSに構築したWordPressに独自ドメインを割り当ててみた](https://qiita.com/olaf_system/items/46723a020456120ffd65)」
「[AWSに構築したWordPressをhttps対応してみた](https://qiita.com/olaf_system/items/d80aa943107eb2cfcb20)」
の続き。

構築した時に利用したWordPressのAMIがnginxを利用していたのでそれ用の設定。

とりあえずちょっと調べたところによると既にWordPressにはエラーページが用意されているみたい。
https://xxxxxxxxx/?error=404
こんな感じでアクセスするとエラーページが表示される。
でも今、適当なURLでアクセスするとnginx側の404ページが表示される。

</p></blockquote>
</blockquote>
<aside class='widget widget-post'>
<div class='tag-cloud-link'>WordPress</div>
<div class='tag-cloud-link'>AWS</div>
</aside>
<div><a style='width:100%;' class='btn__link' href='https://qiita.com/olaf_system/items/7cee5134e6fae56f359e'>元記事を表示</a></div>
<h3 id=WordPressにGoogleAnalyticsを導入してみた

# はじめに
「[AWSにWordPressを構築してみた](https://qiita.com/olaf_system/items/e5e17cd8ead71ec9a096)」
「[AWSに構築したWordPressに独自ドメインを割り当ててみた](https://qiita.com/olaf_system/items/46723a020456120ffd65)」
「[AWSに構築したWordPressをhttps対応してみた](https://qiita.com/olaf_system/items/d80aa943107eb2cfcb20)」
の続き。

WordPressの準備は終わったので次はPVを確認するためにGoogleAnalyticsを導入していく。

# 設定
## Googleアカウント作成
まずはじめにGoogleアカウントを作成する。
作り方は割愛。

## GoogleAnalyticsの設定
次にGoogleAnalyticsを設定する。

https://analytics.google.com/analytics/web/provision/?authu

元記事を表示

APIGatewayにCognitoオーソライザーをSwaggerで設定する(CloudFrontも少し)

# 背景
AWS使ってサーバーレスで自分用の家計簿的なwebサービスを勉強も兼ねて開発中。メイン機能は大分出来てきて、あとは残課題の対応という形。[前の記事](https://qiita.com/silverbox/items/b3c8a53aa4baa3d02ff8)でCognitoは対応していたが、フロント部分のみ。APIGateway部分にはCognito制御をしていない。せっかくCognito使ってるので、APIGateway側でも制御を入れたい。

# まずAWS側設定
### 手法検討
色々ページを見ていると、CloudFormationでやっているケースあればSwaggerでやってるケースもあり。今回、API部分はSwaggerでやっているのでSwaggerで出来る部分はSwaggerでやりたい。

### やってみた。
色々なページを参考にさせてもらうと、lambdaで認証しているケースが多い。世の中はlambdaで認証チェックするのが主流らしい。Cognitoでやろうという所はあまりないらしい。色々試してみたが、swagger書式でないとか言われたり、エラーは出なかっ

元記事を表示

OTHERカテゴリの最新記事