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

AWS関連のことを調べてみた2021年01月24日
目次

AWS基礎から学習①-EC2の環境構築-

今回、AWSの基礎を学び直す目的でEC2の環境構築と接続まで行ったので、その過程と自分なりに気になったポイントを書いていこうと思います。
自分用の備忘録として残していますが、これからAWSの基礎学習を始める方の参考になればと思います。
今回は踏み台用EC2を使って作業用EC2にログインするところまで。

#環境
・MacOS
※macOsとwindowsでは操作方法が異なる部分があるので、ご注意してください。
・AWSサービス(2021/1/22時点)
※各種設定画面は都度アップデートされていますので画像と異なる場合があります。

#目次
[1.VPCの作成](#1-VPCの作成)
[2.サブネットの作成](#2-サブネットの作成)
[3.インターネットゲートウェイの作成とアタッチ](#3-インターネットゲートウェイの作成とアタッチ)
[4.サブネットのルートテーブルの設定](#4-サブネットのルートテーブルの設定)
[5.EC2(踏み台サーバー)の作成](#5-EC2(踏み台サーバー)の作成)
[6.EC2(踏み台サーバー)に接続](#6-EC2(踏み台サーバー)に接続)
[7.EC

元記事を表示

AWS java SDKでDynamoDBテーブル情報を取得してみる

# この記事について

将来的に書く予定の「JavaFX で DynamoDB Viewer作ってみた」記事の1ステップ。
結構大きな話になると思うので、少しずつ技術ポイント毎に記事を書いて、ある一定程度の要件を満たせた段階で前述まとめ記事書く予定。

第一回記事:[DynamoDBの情報を読み込んでJavaFXで表示してみる](https://qiita.com/silverbox/items/eba824a9f003df67181e)
第二回記事:[JavaFXで動的にテーブル列を設定する](https://qiita.com/silverbox/items/904a01d561014d800696)

※前回の記事が基本になってます。メソッドなど再説明していない部分があります。

# 今回の進捗

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/530376/0f9e40cd-a84f-efe2-87a4-4111008b1fc8.png)

今回終了時のソースはこちら。[Githu

元記事を表示

EC2インスタンスにパブリックIPが付与されなかった話

EC2にパブリックIPが付与されてない

ある時EC2をパブリックサブネットに立ち上げた時のこと。
EC2インスタンスにPublic IPが付与されていないことを発見↓![スクリーンショット 2021-01-23 23.50.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1049410/c2f55c09-7f43-8ac4-0b78-a915a710f313.png)

AWS認定のソリューションアーキテクトでもよく出てくるこの事象。
この原因について、試験での答えは大体こう⇨「サブネットのパブリックIPv4アドレスの自動割り当てが有効になっていない」

了解了解、座学で知ってます。サブネットを確認しましょう。
あれ、サブネットの設定では自動割り当てが有効になっているな、、、↓
![スクリーンショット 2021-01-24 0.07.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/10494

元記事を表示

Lambda(Python)でDynamo DBに接続しようとした際に”Unable to marshal response: Object of type SSLError is not JSON serializable”が出た件について

下記の記事を参考にして、Amplifyプロジェクト内にDynamo DBに接続するLambda関数を実装していたところ、タイトルにあるエラーが出ました。

[AWS API GatewayとLambdaでDynamoDB操作](https://business.ntt-east.co.jp/content/cloudsolution/column-try-20.html#section-03)

この記事では、その対処方法を備忘録代わりに記載します。

# 環境

– Windows10 20H2
– WSL2 – Ubuntu-20.04
– Amplify CLI 4.41.0
– Python 3.8.5
– pipenv 2020.11.15

# 症状
冒頭の記事を参考にして、一部を書き換えながら試していたとき、タイムアウトのエラーが起こりました。

“`
START RequestId: 04359089-637f-48f3-aa2b-e7649c53e4d1 Version: $LATEST
{‘OperationType’: ‘SCAN’}
END RequestI

元記事を表示

AWS re:Invent 2019: SaaS Tenant Isolation Patterns(SaaS テナント分離パターン) (ARC372-P)

動画 https://www.youtube.com/watch?v=fuDZq-EspNA

![スクリーンショット 2021-01-23 21.45.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/f2e70846-da74-7361-c577-61414198f9d8.png)

> テナント分離は、SaaS アーキテクチャーの最も基本的な側面の 1 つです。すべての SaaS プロバイダーは、提供するテナントリソースの分離と安全を確保する手段について考察する必要があります。その際の課題となるのは、各リソースタイプ(コンピューティング、ストレージ、その他)で、異なる分離アプローチが要求されるということです。このセッションでは、分離オプションの全体像を概観できる、明確なロードマップを作成します。さまざまなマルチテナントモデルと AWS のサービスに広がる分離を達成するための、戦略についてもハイライトしていきます。SaaS ソリューションに分離を導入する際のアプローチに影響を与え得る考

元記事を表示

AWS ソリューションアーキテクト 資格取得タイムトライアル 1日目

## 始めること
AWS ソリューションアーキテクトの資格取得に向けた勉強にタイムトライアル的な要素を加えて、何日で資格取得なるかを計測することで楽しくお勉強しようという試みです!
目標は勉強時間20時間でクリアしてみたいと思っています(適当)
また、勉強した内容をここにアウトプットして、メモ&復習用途としても利用しています。

## 筆者の人物像
* 普段はフロントエンドとバックエンドがメイン(reactとnode.js)
* AWSの実務経験はなし
* 個人学習で紫本とudemyの教材を1本実施
* dockerやk8s、rhelなどのインフラ業務経験はあり

## 学習の動機
1. 単純にAWSの知識が欲しい
1. 実務経験がない部分を客観的な知識として資格で補いたい
1. 転職を考え始めたので、少しでも有利な状況にしたい

## 使う教材
模試は受ける予定ですが、基本的には[改訂新版 徹底攻略 AWS認定 ソリューションアーキテクト − アソシエイト教科書](https://www.amazon.co.jp/改訂新版-AWS認定-ソリューションアーキテクト-アソシエイト教科書[

元記事を表示

簡単Webサイトホスティング④CloudFrontのリアルタイムログをKibanaで可視化する

# はじめに

Amazon Web Services(AWS)が提供する、“Amazon CloudFront“ や “Amazon S3“ と呼ばれるサービスを組み合わせることで、 **HTMLやJavaScript、画像、ビデオなどで構成される静的Webサイトの配信基盤** を[**安価に構築**](https://aws.amazon.com/jp/websites/)することができます。本記事では、リソースのセットアップを自動で行うことのできる、“AWS CloudFormation“ を用いることで、これらの配信基盤を **ミスなく迅速に構築** する手順をご説明します。なお、今回使用する CloudFormation テンプレートは、以下の GitHub リポジトリで公開しています。

+ [AWSCloudFormationTemplates/static-website-hosting-with-ssl](https://github.com/eijikominami/aws-cloudformation-templates/blob/master/sta

元記事を表示

最安値に挑戦!AWSとRTX1210の拠点間VPN接続

AWSで拠点間VPN接続をするのであれば、通常はマネージドサービス(AWSサイト間VPN接続)を使います。しかし、[0.048USD/hourの費用][2]、1か月(744時間)で35ドル強の費用が掛かり、個人で使うには厳しい金額です。
そこで、できるだけ安く拠点間VPNを行うための方法を模索し、定期的にQiitaに載せていたのですが、ようやく実現したのでこの記事でまとめておきます。

# 節約のポイント
– AWS側のVPNサーバとしてEC2を利用し、ソフトウェアはLinuxベースのstrongSwanを使用
– ~~EC2のインスタンスタイプは、現状AWSで最安値であるT4g.nanoを利用~~
– リザーブドインスタンスが余っていたため、今回はt3.nanoで構築しています
– OSはminimalイメージを活用し、EBS 2GBで運用
– 自宅側の固定IP費用を削減するため、IPv6で接続

# 接続構成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/776880/8c2e07

元記事を表示

AWS Translateを使ってGo言語で翻訳するサンプル

タイトルの通りですが、[公式ドキュメント](https://docs.aws.amazon.com/sdk-for-go/api/service/translate/)にサンプルが含まれていなかったので記事にしました。

サンプルソースはGithubにも置いてあります。
https://github.com/yuukimiyo/go-aws-translate

簡単なコードですが、[73言語](https://docs.aws.amazon.com/translate/latest/dg/what-is.html#what-is-languages.html)(2021年1月現在)の双方向翻訳が可能な簡易ツールとして使えます。
Public Domainですので、コピペなどご自由に。

“`golang
package main

import (
“flag”
“fmt”

“github.com/aws/aws-sdk-go/aws”
“github.com/aws/aws-sdk-go/aws/session”
“github.com/aws/aws-sdk-go/

元記事を表示

AWSへDockerホストのプロビジョニングをする際にcredentialsがない旨のエラーが表示される

AWSへDockerホストのプロビジョニングをする際に、アクセスキーやシークレットキーを記述したcredentialsファイルを作成して、AWSにDocker Engineが動作するインスタンス作成するコマンドを実行したところ、下記エラーが出力されました。

“`linux
$ docker-machine create –driver amazonec2 –amazonec2-open-port 8000 –amazonec2-region ap-northeast-1 aws-sandbox
Error setting machine configuration from flags provided: amazonec2 driver requires AWS credentials configured with the –amazonec2-access-key and –amazonec2-secret-key options, environment variables, ~/.aws/credentials, or an instance role
“`

元記事を表示

はじめてのAmazon EKS (k8s経験者用 )

今更ながら、k8sは使ってるがAmazon EKSはちゃんと使ったことないので気になったポイントまとめ
※2021年1月時点

# [1] Amazon EKSとは

– AWSが提供する`マネージドKubernetes`サービス(2018 GA)
– Masterにあたる**コントロールプレーン**(etcd含む)がサーバレス的に提供され、Worker部分は統合された**EC2(NodeGroup)**か**Fargate**でクラスタを構成する
– re:Invent 2020にて**EKS Anywhere**という新サービスが発表され、オンプレミス環境のKubernetesの管理拡張も可能になる予定(GCPのAnthos的な感じ)
– 参考:オンプレ利用想定のディストリビューション EKS Distro:https://github.com/aws/eks-distro

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/112537/4170d36a-7992-727c-3

元記事を表示

CloudFront+API Gateway構成ではHostヘッダに気をつけよう

## TL;DR
CloudFrontのオリジンにAPI Gatewayを追加したい時には、
Origin Request Policyにて、`AllViewer`の設定で全てのヘッダをバイパスするように設定するとエラーとなる。
原因はCloudFront向きの`Host`ヘッダの情報をAPI Gatewayにそのままバイパスしてしまうため。

## はじめに
よく知られていることですが、API Gatewayは内部的にCloudFrontの仕組みを利用しているため、
レスポンスデータのキャッシュやスケーラビリティの確保については、CloudFrontをユーザー側で用意しなくても、
CloudFrontのメリットを受けられるようになっています。
しかしながら、例えば

– WAFによるアクセス制限の仕組みを利用したい
– キャッシュ設定をより細かく設定したい
(`Maximum TTL`, `Minimum TTL`、`Invalidation`等)

などのユースケースにて、意図的にAPI Gatewayの前段にCloudFrontを置きたくなることがあります。

今回自分もキャッシ

元記事を表示

Amazon Linux 2のhostname変更方法

##### はじめに
AmazonLinux2でEC2を立ち上げ、 `hostsファイル` と `networkファイル`を編集してhostnameを変更後にLinuxを再起動後に再度SSH接続してもhostnameが変更されていないという場面で遭遇しました。
そのため、AmazonLinux2でのhostname変更方法の忘備録を残しておきたいと思います。

##### 変更方法

`hostnamectl`コマンドでhostnameを変更する

“`
# hostnamectlコマンドで変更前のhostnameを確認する
[ec2-user@ip-10-0-11-229 ~]$ hostnamectl 
Static hostname: ip-10-0-11-229.ap-northeast-1.compute.internal ←変更前のhostname
Icon name: computer-vm
Chassis: vm
Machine ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

元記事を表示

AWSアクセスキーをGithubにあげてしまった時の対処方法

WEBサービス開発歴7ヶ月目に突入しましたにこと申します。

先日、GithubにAWSアクセスキーをあげてしまいました。

その時は事の重大さをわかっておらず、言われるがままにコマンドをうち対処が出来たのですが、調べれば調べるほど「とんでもないことをしていた・・・!」ということがわかりました。

[AWSで不正利用され80000ドルの請求が来た話](“https://qiita.com/koyama9876/items/add70cba3cccdb7fa995”)
[初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。](“https://qiita.com/mochizukikotaro/items/a0e98ff0063a77e7b694”)

もう今後アクセスキーをあげることはないですが、愚かな人間なのでまた何らかを間違えてやってしまうかもしれません・・・。

二度とないことを誓いつつ、もし万が一やらかしてしまった場合、また同じようにアクセスキーをあげてしまったような方に向け、手順をしっかり残したいと思います。

# まずはざっくりと手順の確認

元記事を表示

【自分用メモ】AWS認定SysOpsアドミニストレーター-アソシエイト試験対策メモ

#はじめに
本記事は、AWS-SOA試験の対策をしている上で覚えておくべきだと感じたことをメモとして残しておくものです。
主に問題演習中に連続して間違えたものを記載しています。
SOA試験に関する記事は[こちら](https://qiita.com/msengnsoni/items/da6faebbf934e11bc643)

#AWS CLI
・Auto Scalingグループを削除したい場合
最小サイズと希望する容量を0に → delete – auto -scaling – group コマンドを使用

#EC2
mojikyo45_640-2.gif
・インスタンスタイプ
R – RAMのR メモリが必要
C – CPUのC 高性能なCPUが必要
M – MidiumのM バランスの取れたインスタンス郡

元記事を表示

Amazon ECS (Fargate起動) 構築方法メモ

* AWS CLIからAmazon ECSのクラスター構築、タスク登録、サービス登録をFargate起動設定で行う方法についてのメモ。

## 作成手順

### 前提条件

* シェルスクリプトからAWS CLIを実行して作成する。

* クラスター構築~サービス設定まで。アプリデプロイは別途実施する。

![ecs_fagate.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/586535/32077211-16eb-bb24-ae41-2cc9da7f2530.png)

### 1. クラスター構築

* ECSクラスター`test-fargate-cluster`を作成する。

“`shell
aws ecs create-cluster –cluster-name test-fargate-cluster
“`

### 2. Fargate起動用タスク定義登録

* Fargate起動タスク定義を登録する。

“`shell
task_definition

元記事を表示

AWS セキュリティグループ 作成方法 メモ

* AWS CLIを用いたセキュリティグループ作成方法をメモする。

## 用語メモ

### インバウンド(送信元)

* 外部から対象セキュリティグループへのアクセス設定

### アウトバウンド(宛先)

* 対象セキュリティグループ内部から外部へのアクセス設定

## セキュリティグループ作成

* シェルスクリプトからセキュリティグループを作成し、以下のようなインバウンド・アウトバウンド設定を行う。
* VPCはすでに作成済みとする。

### 1. セキュリティグループ作成

* 作成後、セキュリティグループIDを取得し、デフォルト設定を削除する。

“`shell
RES=$(aws ec2 create-security-group –vpc-id ${YOUR_VPC_ID} –group-name sg-test –description “SG for Test”)
SG_TEST=$(echo ${RES} | jq -r “.GroupID”)
aws ec2 revoke-security-group-egress –group-id ${S

元記事を表示

AWS EBで「Unhandled exception during build: invalid literal for int() with base 8: ‘493’」エラーの対処

## 概要
AWSのElastic Beanstalkで.ebextensionsを利用時にデプロイでエラー発生
(ちなみにPHPでLaravel)

“`/var/log/cfn-init.log
2021-01-23 02:10:56,395 [ERROR] ———————–BUILD FAILED!————————
2021-01-23 02:10:56,395 [ERROR] Unhandled exception during build: invalid literal for int() with base 8: ‘493’
Traceback (most recent call last):
File “/opt/aws/bin/cfn-init”, line 171, in
worklog.build(metadata, configSets)
File “/usr/lib/python2.7/site-packages/cfnbootstrap/construction

元記事を表示

re:Invent 2020 ストレージ関連の新サービス、アップデートまとめ

re:Invent2020で発表されたEBS、EFS、S3等のストレージ関連サービスのアップデートをまとめてみました。

[re:Invent スペシャル企画 まだまだやるよ!宇宙一 回数の多い re:Cap week8](https://jawsug-yokohama.connpass.com/event/201083/)
でこのあたりをキャッチアップしますので是非ご参加ください!

# EBS
## gp3 volumes for EBS
– 3,000 IOPS、125MB/sのベースライン・パフォーマンス
– 最大16000IOPS

JAWS-UG横浜のre:Cap week1で発表した資料に詳しいことは残しています。

https://aws.amazon.com/jp/blogs/news/new-amazon-ebs-gp3-volume-lets-you-provision-performance-separate-from-ca

元記事を表示

AWSでproduction.logが肥大化した時の対処方法 & ログローテート方法

AWS初学者です。

Railsで個人的にアプリを作っておりまして、AWSにデプロイしています。
昨日も新しい機能を追加したため、変更内容をAWSにデプロイしようとしたところエラーが発生しました。

EC2にSSH接続し、「df -h」で容量を確認したところ、 
「/dev/xvda1」の使用率が100%に…

「どこの容量が多いのか」をさらに深掘りして調べてみたところ、

「/var/www/アプリのディレクトリ名/shared/log/production.log」

というログファイルがかなり多いことがわかりました。その容量はなんと3G!?
今まで放っておいた自分を反省しました?

そして、何とかproduction.logを軽量化し、正常にデプロイさせることができたので、その方法をアウトプットしていきたいと思います。

(ちなみに、「どこの容量が多いか」を調べる方法については、こちらの記事で説明しています:容量がいっぱいでAWSにデプロイできなかった時の対

元記事を表示

OTHERカテゴリの最新記事