AWS関連のことを調べてみた2019年12月10日

[AWSであそぼう#02]独自ドメインを使用してHTMLページを公開する

# 目的
　この記事は、今話題のクラウドサービス「**AWS**（**Amazon Web Services**）」に触れてもらい、今後の自学自習のキッカケにしてほしいという目的で書きました。
　現在様々な企業がWebサービス展開の際に利用しているこのクラウドサービスについて、簡単な操作を通して、一緒に少しずつ学んで行きましょう。

# 学習目標
今回は、[前回の記事](https://qiita.com/d-yoshizaki/items/c50ec1e30a08d72c2dec)で紹介した、Amazon S3でHTMLページを公開する操作の応用編として、「**独自ドメインを使用したHTMLページの公開**」の方法を習得します。

## エンドポイントのおさらい
前回は、Amazon S3上にアップロード&公開したHTMLページにアクセスするには、「**エンドポイント**」と呼ばれる、下記のような特殊な形式の記述を使用しました。

“`
http://asobo-aws-2019.s3-website-ap-northeast-1.amazonaws.com
“`

しかし、実際

Amazon Connectのchat UIサンプルの利用方法

# はじめに
先月2019年11月に発表されたAmazon Connectのchat機能について、[githubにサンプル](https://github.com/amazon-connect/amazon-connect-chat-ui-examples)が載っていましたので、そちらを試してみました。
サンプルには、お客様に提供するchatUI・Amazon Connectのchatのサンプルコンタクトフローなどが記載されていました。
今回はこちらのサンプルの利用方法をまとめました。
# 構成
[こちら](https://github.com/amazon-connect/amazon-connect-chat-ui-examples/blob/master/cloudformationTemplates/asyncCustomerChatUX/images/asyncCustomerChatUX.png)を参考にしてください。
エンドユーザに対して提供するWebページを、CloudFrontにて提供しています。

そのため試す際には、CloudFrontへのアクセスができるようにし

mockmockでAmazon API Gatewayにデータを送るプロジェクトを作成する

この記事は、[mockmockアドベントカレンダー](https://qiita.com/advent-calendar/2019/mockmock)10日目の記事です。

今回は公式ドキュメントに載っていない、Amazon API Gatewayで作ったAPIに向けてデータを送る方法を書いてみます。

## プロジェクト認証
API Gateway宛にデータを送るプロジェクトを作る場合、サーバータイプを`General`にします。
独自に作成したサーバー向けにデータを送る場合に使うサーバータイプですが、
ユーザーの管理下にないホストに向かってデータを送信するのを防ぐため、認証作業が必要となります。
API Gatewayを使う場合、ココをクリアするのが一番の山場になります。

プロジェクトを作成する際に、mockmockから認証キーが提示されるので、
`http(s)://[送信先ホスト]/[認証用パス]`に対してリクエストを行い、認証キーが含まれるレスポンスが返れば認証となります。

方針としては、[チュートリアルAPI](https://console.mock-mock.com

お名前ドットコムからAWSへドメイン移管した話

うっかりお名前ドットコムでドメインを取ってしまったので、AWSへ移管した話になります。
手続きが面倒だなぁって人は初めからAWSでドメインを取ってくださいね。

#ステータス
・AWSまっさら。AWSを使おうとしてアカウントを取って「IAM（作業者用）アカウントはありますよ。」って状態。
・ドメイン：契約してから60日は立ってるけどWhois情報以外の設定は何もしてない、DNSレコードも初期状態のもの。とったドメインもAWSに移管できることを確認済み。

#事前準備
・お名前ドットコムの以下のURLにて、事前設定に必要な確認事項をチェックしましょう。
https://help.onamae.com/answer/8593
・AWSのドメイン移行マニュアルをチェックしましょう。
https://docs.aws.amazon.com/ja_jp/

ServerlessFrameworkとPythonでAWSを触ってみる

# はじめに

12月も早いもので中盤を迎えましたね。個人的なお話になりますがこの日はお誕生日なのでとってもハッピーな気分でいます。この記事もそんな気持ちで書いています。
最近、ServerlessFrameworkとAWSを触っているのでそれに関して自分なりにまとめてみました。使用したサービスは、LambdaとS3、SQS、API Gatewayなのでそのことについて書いてあります。

今回使用したコードは[ここ](https://github.com/masaemon/aws-serverless)にあります。

また、本記事を作成するにあたり以下の記事を参考にしました。
[とことんサーバーレス①：Serverless Framework入門編](https://qiita.com/hiroshik1985/items/6d979ff1afb56953b62e)
[Serverless FrameworkとS3で超簡単な投票システムを作った話](https://qiita.com/is_ryo/items/ffe59a06df500d530d14)
[Serverless Fr

AWS でプライベートなデータを共有する

写真を撮ったんだけど、これを AWS にアップロードして共有したい、という時があると思います。

pre signed url という機能があります。日本語では、「署名付き URL」というみたいです。
（参考）
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/PresignedUrlUploadObject.html

credential がわかっており、ansible が使えてしかも vault 設定をしていれば、簡単にそのパスを得られます。

ここに、上げておきました。

https://github.com/intrajp/aws_usecases

そろそろ年末かぁ。。

Amazon SageMaker 物体検出モデルの構築 ～Honey Bees～

[Amazon AI by ナレコム Advent Calendar 2019](https://qiita.com/advent-calendar/2019/knowcom-amazonai)の8日目の記事です。

AWS公式[機械学習トレーニング](https://aws.amazon.com/jp/training/learning-paths/machine-learning/exam-preparation/)の **Amazon SageMaker: Build an Object Detection Model Using Images Labeled with Ground Truth (Japanese) (Ground Truth のラベルが付いたイメージを使用して、オブジェクト検出モデルを構築)** を参考に、物体検出のモデル構築についてまとめてみました。

# 物体検出とは
今回は画像からミツバチの検出を行います。

クラスタリング（分類）・・・1枚の画像がどのタグに分類できるか
物体検出・・・1枚の画像の中から特定の物体の境界ボックス（BoundingBox）

家の環境（温度・湿度・大気圧）をAWSに蓄積して分析してみるの巻　その２

# 前回まで
– [家の環境（温度・湿度・大気圧）をAWSに蓄積して分析してみるの巻　その１](https://qiita.com/KG_/items/c4a50a072f992dde78a3)

# 今回の内容
今回は、AWS IoT向けにデバイスからpublishするところまで作業します。

# 先にデバイス側のコードを紹介
“`C:aws-iot-publish.ino
#include
#include
#include
#include
#include “BME280SPI.h”

#define JST 3600*9

const String wifiSSID = ““; // お使いのWiFiのSSIDを入力してください
const String wifiPass = ““; // お使いのWiFiのパスワードを入力してください

const uint8_t pinLED = 14;

AWSの多要素認証に1passwordが使えたけど使っちゃダメだと思った話

1passwordのアイテム編集画面で、フィールドタイプを眺めててふと思った。「ワンタイムパスワードってあるけど、これ、AWSで多要素認証するときの『仮想MFAデバイス』に使えるのでは」と。結論から言えば、使えた。快適。でもこれは多分「人をダメにするナントカ」的な快適さだ。やっちゃいけないやつだ。

# AWSの多要素認証

AWSでは、AWSアカウントの管理者であるrootユーザー（メールアドレスでログインする人）と、利用者であるIAMユーザー（ユーザーIDでログインする人）のどちらでも、多要素認証（MFA：Multi-Factor Authentication）を設定して認証を強化できる。

* 認証方法はパスワード認証＋ワンタイムパスワード（当人が知っていること＋当人が持っているもの）
* ワンタイムパスワードの生成には、専用のデバイスであるU2FセキュリティキーやハードウェアMFAデバイス、スマホアプリである仮想MFAデバイスのどちらかが使える
* [SMSによる認証](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide

AWS経験者がGCP Associate Cloud Engineerの資格を取ってみた

GCPの資格試験である「**Associate Cloud Engineer**」の試験に合格しました。
AWSを実務で1年半程度利用している私が、なぜGCPの資格試験を志し、何で勉強し、合格まで辿り着いたのかを纏めます。
実務ではAWSやってるけどGCP興味ある、っていう人はたくさんいると思うので、そのような方が読んでくれると嬉しいです。
# なぜGCP
GCPの資格試験を志した（それらしい）理由の説明をしようと思います。

以下に示すように、AWSに比べるとGCPのマーケットシェアはまだまだです。（AWSすごいですね）
ただ、成長率は他を圧倒しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/250926/4fcff19f-e8f1-0

クラウドはdhcpが当たり前

さて、つい最近とあるプロジェクトにて。
「Azureの設定的には、インタフェースには静的なIPを振りますが、OSの設定としてはdhcpを設定します」
と説明したところ
「そんなのあり得ない！」
という反応を受けました。
どうやら「クラウドに中途半端に詳しい人が勘違いしてることあるある」っぽいネタのようですので、解説していきたいと思います。

#Azure(やらAWSやら)では基本的にOS設定はDHCP
さて、皆さんはAzure、或いはAWSで新規に仮想マシンを建てる時、OSの中身はほぼデフォルト設定になっているという事は理解されているかと思います。
OSのデフォルト設定は、DHCP設定なのです。
つまり、事実として、OSはDHCP設定のままでいると、AzureなりAWSなりが設定している「ネットワークの設定」が設定される仕組みになっているのです。その際、サブネットマスクだの、デフォルトゲートウェイだの、DNSだのが自動で設定されるのです。

#DHCP設定しないとどうなるの？
こまる事だらけです。
特に[VMのクローンを作る]という時に大変困った事になります。
例えばOSの設定として、

AWS re:Inventを有意義に過ごすための10個のTips

これは[Media Doアドベントカレンダー](https://qiita.com/advent-calendar/2019/mediado)の何日目かわからない記事です。

先日、ラスベガスで開催されたAWS re:Invent2019に参加してきました。
そのときに「次行くときはこうしよう」と思ったことをTipsとしてまとめます。

## ①セッション予約は登録解禁後すぐやろう
re:Inventのセッション予約は、開催約2ヶ月前の日本時間深夜2時に開始されます。
そのとき、「明日の昼ぐらいに予約すればいいや」とか思っていると人気のセッションはすぐ埋まってしまっていました。

re:Invent全体の参加者約7万人に対して、セッションの会場は数百人程度なのですごい競争率です。なのでセッションの予約は開始直後にやってしまいましょう。

予約開始時にすぐ目当てのセッションを予約するには、当然それより前に公開されているセッション一覧に目を通しておく必要があります。re:Inventでのセッションの総数はおよそ3000個もあって、この一覧に目を通すことすら難しいので、サーバーレスとか機械

Now Available on Amazon SageMaker: The Deep Graph Library 和訳してみた

##はじめに
今回は、Julien Simon 氏が2019年12月3日に投稿した「Now Available on Amazon SageMaker: The Deep Graph Library」の内容を翻訳し、まとめてみました。本記事と Deep Graph については下記リンク参照。

■リンク
[Now Available on Amazon SageMaker: The Deep Graph Library](https://aws.amazon.com/jp/blogs/aws/now-available-on-amazon-sagemaker-the-deep-graph-library/)
[The Deep Graph Library](https://www.dgl.ai/)

##Now Available on Amazon SageMaker: The Deep Graph Library
###Deep Graph Library
Amazon SageMaker で、Deep Graph Library が利用できるようになったことを、発表します。
D

[AWS] re:Invent2019 の自分まとめ

# 概要

– re:Invent2019で発表された全てではありません
– 自社サービスで活用可能性がありそうなものを独自で抽出しています
– 全てを知る場合は `Whats’ New` の確認をおすすめします

# 新サービスにあるBeta/Previewについて

– [re:Invent 前に理解しておくべきベータ/プレビューサービスの扱いについて](https://dev.classmethod.jp/cloud/aws/understanding-aws-beta-services/)

# Amazon S3アクセスポイント

– [What’s New](https://aws.amazon.com/about-aws/whats-new/2019/12/amazon-s3-access-points-manage-data-access-at-scale-shared-data-sets/)
– [FAQ](https://aws.amazon.com/s3/faqs/#S3-Access-Points)

## 概要

– S3への新しいアクセス方法
– バケットポ

Serverless framework x CircleCI でAWS lambdaのローカル開発環境構築

Linc’well Advent Calendar10日目の記事です。

当社が展開するクリニックグループの [CLINIC FORの予約システム](https://reservation.clinicfor.life/) で、認証機能の一部にAWS Cognitoへの移行を進めております。

予約システム全体としてはモノリシックなRailsアプリケーションで開発をしてきたのですが、AWS CognitoをRailsアプリケーションの上に被すように実装する必要がり、連携をするためにAWS CognitoのTriggerをlambdaで実装する必要がでてきました。

この記事では、ローカル環境でのlambda開発、テストをどう構築したかをまとめます。

## lambda 開発環境構築

今回は、[Serverless Framework](https://github.com/serverless/serverless)を使って開発を進めます。Frameworkのinstallとprojectを作成します。

“`
npm install -g serverless
serverle

AWS基礎

AWSに関わることになったので、基本的なキーワード等について簡単にメモる。

最低限のキーワードをピックアップしているため、その他の気になるキーワードや詳細解説については[AWS公式サイト](https://docs.aws.amazon.com/ja_jp/)を参照ください。

## AWSのアカウント

AWSには**AWSアカウント**と**IAMユーザー**と呼ばれる２種類のアカウントがあります。

AWSアカウントとは、AWSサインアップするときに作成されるアカウントのことです。このアカウントでは、AWSアカウントの全てのサービスをネットワーク上のどこからでも操作できる権限を持っているため、**ルートアカウント**とも呼ばれています。

非常に危険なアカウントであるため、取り扱いには十分注意する必要があります。従って、日常的なタスクには、それが管理者タスクであっても、ルートユーザーを使用しないことが推奨されており、ルートユーザーは最初のIAMユーザーを作成するためだけに使用し、それ以外の操作はIAMユーザーを利用するというのがベストプラクティスとされています。

IAMユー

SREやクラウドエンジニアが読むと良さげな本まとめ

一年半ぐらい前にアプリケーションエンジニアからSREにコンバートした筆者が、いま役に立ってるなぁっていう本を紹介します。アプリケーションコードを書いてるときは下のレイヤの技術に興味なかったんですが、改めて勉強してみると楽しいです。

## コンピュータシステム

クラウド全盛とはいえ、コンピュータの仕組みはおさえておくと役立ちます。コレ系の本はわりと小難しいものが多いですが、個人的に楽しく読めた本を紹介します。

### [Raspberry Piで学ぶコンピュータアーキテクチャ](https://www.amazon.co.jp/dp/4873118654/)

Raspberry Piと銘打たれてますが、コンピュータアーキテクチャの歴史的な背景も踏まえて解説されています。プロセッサ・メモリ・ストレージ・ネットワーク・OS・プログラミングなど、コンピュータ単体の基本的な知識を学べます。　歴史をあわせて知ることができるため、知的好奇心がおおいに刺激され、楽しく読むことができます。この本が難しく感じられる場合は、[プログラムはなぜ動くのか](https://www.amazon.co.

AWS Transit Gateway Network Manager さっそく触ってみた

こんにちは、あやたこです。

ちょうどTrangit Gatewayを触る機会があったので、今回のre:Inventで発表されたNetwork Managerもついでに触ってみました

## 0.前提
既にTrangit GatewayでVPC又はVPNが接続されている必要があります
また、Network Manager が参照する Transit Gateway は同じAWSアカウント内にあるものとします

## 1.Global Networkを作成する
VPCサービスから Network Manager を開き、 Create a Global Network を選択します

Global Networkを識別するための名前を適宜入力する

Kinesisストリームのサーバーサイド暗号を試してみる

サーバーサイドでは、Kinesisストリームのストレージ I/O のタイミングで暗号・復号処理を行います。

とりあえずやってみたのでメモ。

#1.Kinesis ストリームを作成し、暗号化する#


#2.CLI で暗号化されたストリームを確認#

“`
$ aws kinesis describe-stream –stream-name test
{
“StreamDescription”: {
“KeyId”: “arn:aws:kms:ap-northeast-1:123456789012:key/c22d289b-669b-4e64-830b-30713982cccc”,　 ※
“EncryptionType”: “KMS”,　　　　　　　　　　　　　　　　　　　　　　　　　　　　

CodeCommit内のREADME.mdに埋め込む画像をS3から参照しようとしてもダメだった件について…

タイトル通りです。GitHubなら自身のリポジトリ内に置いた画像を配置してそこを参照することができるんですが、CodeCommitではできません。代替案としてS3に画像を配置してオブジェクトのURLを参照しようと３時間ほど格闘したんですが、どうやら無理みたいです。([参考](https://forums.aws.amazon.com/thread.jspa?threadID=273712))
今後の機能修正に期待ですね！あと、今まで曖昧だったAWSのJSONポリシーの書き方について勉強になりました！それは今度描きます！(笑)