- 1. Amazon Route 53とAWS WAFとAmazon CloudFrontとAmazon S3で独自ドメインホスティング環境を構築してみた
- 2. 【AWS】EBSをスナップショット取った時のサイズはどんな感じ
- 3. 【AWS】VPC同士を接続してみた（Transit Gateway 編）
- 4. Windows環境でAWS CLIを使えるようにする手順+エラーケース。
- 5. Lambdaテンプレート_AWS SAM版
- 6. S3から別アカウントのS3バケットへデータ移行（cp/mv/syncコマンドの違い）
- 7. AWSのストレージのコスト比較
- 8. cloudwatchのアラームをslackに通知
- 9. AWS DBまとめ
- 10. AWS MWAA (Amazon Managed Workflows for Apache Airflow) からSecretManagerを使用してBigQueryに接続する
- 11. 【AWS】EC2というサービスと各種設定項目
- 12. 実務２ヶ月でAWS ソリューションアーキテクトプロフェッショナルをとった話。
- 13. 【AWS】ターゲットグループでEC2のヘルスチェックが失敗した
- 14. Amazon AppStream 2.0 をネイティブアプリケーションモードで動かしてみた
- 15. EC2インスタンスの通信状態をpingコマンドで調べる。セキュリティグループでインバウンドルールの設定が必要。
- 16. IPアドレスを固定する（Elastic IPアドレスの設定）
- 17. Amazon AppStream 2.0 で、ローカル環境とファイルのやり取りを行ってみた
- 18. 送信元IPアドレスとVPCエンドポイントに基づいてAWSマネジメントコンソールへのアクセスを制限したい
- 19. IAMのポリシーにジョブ機能ってあるけどこれなに？
- 20. AWS S3ストレージクラスまとめ
Amazon Route 53とAWS WAFとAmazon CloudFrontとAmazon S3で独自ドメインホスティング環境を構築してみた
### Amazon Route 53とAWS WAFとAmazon CloudFrontとAmazon S3で独自ドメインホスティング環境を構築してみました :tada:
事前準備
– 事前にAmazon S3に公開したいファイル一式をアップロード
– 設定は非公開のままでOK
## 構築の流れ
1. [Amazon Route 53で独自ドメイン購入登録](https://qiita.com/dayjournal/items/945613577b3056ec4f71#amazon-route-53%E3%81%A7%E7%8B%AC%
【AWS】EBSをスナップショット取った時のサイズはどんな感じ
#気になったこと
仮に100GBのボリュームに10GBの使っていたらスナップショットのサイズはどんな感じ？
10GB分？
100GB分？なんとなく100GBな気がする。
10GBだったら、AWS惚れちゃう。#結果
| ストレージ容量 |スナップショットサイズ|
|:-:|:-:|
|10GB|10GB|
|100GB|100GB|#乾燥
そりゃそうか。
なお、データの保存先はS3とのことだが、ユーザーから見えるS3バケットには保存されない。
S3の特殊な領域に保存されるとのこと。
公式のマニュアルには記載がないが、調べるとS3に保存されるといろんな人が言っている。参考
https://aws.amazon.com/jp/premiumsupport/knowledge-center/ebs-snapshot-billing/
【AWS】VPC同士を接続してみた（Transit Gateway 編）
## 概要
ピアリング接続された2つのVPC間の通信を、Transit Gatewayを使用した接続に移行してみた際の備忘録です。[前回](https://qiita.com/sshimoyama/items/a1d828de38658bcc1875)は、VPCを2つ作成しVPCピアリングによって接続しましたが、今回はその接続をTransitGatewayに切り替えて同じようにVPC間の接続を確認してみます。
### なぜ？
VPCピアリングは1対1のVPC間相互通信を行う場合には非常に有用なサービスです。設定もとても簡単でしたね。
しかし、VPCピアリングには以下のような弱点も存在します。
– ピアリング接続を経由して、その先のVPC、インターネットゲートウェイ、VPN接続等に直接ルーティングすることは出来ない。（隣まではいけるが、「隣の隣」には行けない）
– 相互接続するVPCの数が増えた場合、フルメッシュ構成をとる必要があるため設定が煩雑になる。詳細は以下のドキュメントが非常にわかりやすいです。
■サポートされていない VPC ピア接続設定
https://do
Windows環境でAWS CLIを使えるようにする手順+エラーケース。
# はじめに
タイトルの通りです。備忘録として残しておきます。
AWS CLIのインストール手順自体は、公式ドキュメントに記載されています。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-windows.html
「AWS CLIっていまいち分からない！」という方は、なんだかんだ言ってブラックベルトを見るのが手っ取り早いと思います。
>公式動画
>[[AWS Black Belt Online Seminar] AWS Command Line Interface](youtube.com/watch?v=1FexvzegG3o)本記事の対象環境は以下となります。
・Windows10
・Windows PowerShell、VScodeなどのローカル環境からの利用。手順は以下となります。
|順番|内容|
|:—|:–|
|1.|Python3をインストール|
|2.|AWS CLIをインストール|
|3.|AWS CLIの初期設定|# 1. Python3
Lambdaテンプレート_AWS SAM版
# はじめに
以前、CloudFormationで単純なLambda関数を作成するテンプレートを記事にしました。
https://qiita.com/a_b_/items/12e3002998d22dfb6385
今回は、AWS SAMで作りましたのでそちらも記事にします。
Cloud9上のAWS Toolkitで実行することを想定しています。# テンプレート
以下に、テンプレートの解説をしていきます。
## フォルダ構成
CloudFormationとは異なり、ファイルが複数に分かれています。フォルダの構成を以下のようにしました。
“`
sample-sam
├── function
│ ├── function.py
│ └── requirements.txt
└── template.yaml
“`– `function/function.py`
– Lambda関数のスクリプトを記述するファイル。
– `function/requirements.txt`
– Lambda関数で使うPythonのライブラリを記述するファイル。
S3から別アカウントのS3バケットへデータ移行（cp/mv/syncコマンドの違い）
# はじめに
S3バケットを別のAWSアカウントへデータ移行したので、
その時に学習した内容（移行方法・cp/mv/syncコマンドの違い）をまとめておきます。# データ移行方法
##### 1.“ cp “コマンド
:::note
データをsourceバケットに残したままにしておきたいならcpコマンド
:::##### 2.“mv“コマンド
:::note
データを移動(sourceからデータが消える)したいならmvコマンド
※削除権限も付与する必要がある
:::##### 3.“sync“コマンド
:::note
データを定期的にコピーしたいなら“sync“
※ちなみに、自動でコピーし続けたいならレプリケート機能
:::# 【手順】データの移行 “cp/mv/sync“
1. 【sourceアカウント】IAMカスタマーポリシーを作成し、IAMユーザーへアタッチ
2. 【targetアカウント】targetバケットのオブジェクト所有者をバケット所有者が優先される設定か確認
3. 【targetアカウント】targetバケットのバケットポリシ
AWSのストレージのコスト比較
気になったので。
リクエスト数とかスループットとかはいったん無視。
感覚で把握しておきたい感じ。
サービスの特性とかは、他の方の記事をご参照ください。100GB*720時間（1か月）
| サービス | USD |
|:-:|:-:|
|EBS(汎用SSD(gp2))|11.80|
|EFS|9.38|
|FSx|13.8|
|S3|2.5|
|S3 Glacier Instant Retrieval|0.5|
|S3 Glacier Deep Archive|0.2|
|消す！|0|# 感想
EBSとそれ以外のストレージサービスはコストで比較してもしょうがない感じ。
シングルAZでよければ、EBSだしマルチAZにしたければそれ以外。
EFS or FSxはOSで決まる。とにかくS3が安いので、コスト圧縮のポイント。
*
新システムならS3を最初から利用
– オンプレから引っ越したシステムは、なる早でS3にファイルを移動
- WEBサーバー
- IISログとかはCloudWatchに異動して、その後S3。
- バッチサーバー<
cloudwatchのアラームをslackに通知
#SNSでトピック作る
#CloudWatchでアラートを設定
説明にアラート出た理由書いとく
通知先を作ったSNSのやつにする
#slackのincomming webhookを発行
#lambdaで関数作成
トリガーを作ったSNSのやつにする
環境変数に以下追加
hookurl #slackのincomming webhookのurl
slackchannel #通知したいslackのチャンネル名
コードに以下入れる
必要であればtextの部分を編集する‘text’: “ \nアラーム名: %s\nステータス: %s\nアラーム理由: %s\n説明: %s” % (alarm_name, new_state, reason, alarm_description)
“`
import boto3
import json
import logging
import osfrom urllib.request import Request, urlopen
from urllib.error import URLError, HTTPErrorHOOK_UR
AWS DBまとめ
#AWSで用意されているDBの種類
* RDS
* DynamoDB
* RedShift
* ElastiCache
* Neptune
* Athena## RDS
* リレーショナルデータベース（RDB）
* 以下のDBエンジンをサポートしている
* Amazon Aurora
* PostgreSQL
* MySQL
* MariaDB
* Oracle Database
* Microsoft SQL Server### Amazon Aurora
* AWSが開発したRDB
* PostgreSQL,MySQLと互換性がある
⇒アプリを変更することなくAuroraにデータ移行でき、さらにこれらのDBエンジンより高スループットらしい。
* 構成
* 3ヶ所のAZにある
* SQL処理を担う**データベースインスタンス**（図上側）
* ストレージを担う**クラスターボリューム**（図下側）
* データベースインスタンスのうち1つ(図のAZa上)は、**プライマリデータベースインスタン
AWS MWAA (Amazon Managed Workflows for Apache Airflow) からSecretManagerを使用してBigQueryに接続する
# はじめに
最近、業務でデータ基盤の構築を行なっており、その中で色々検討した結果ワークフロー構築にMWAAを利用することになりました。
AirflowをAWSのマネージドサービスとして扱えるので、主要リソースをAWS上に構築している場合非常に便利ですよね！ただ今回、Data Lake, Data WarehouseとしてBigQueryを利用したく、その接続周りで少々困ったのでまとめておきます。
# 実行準備
以下は作成済みである前提で進めて行きます。– GCP側
– プロジェクト
– BigQueryにについて操作可能なGCPのサービスアカウント
– BigQueryのテーブル (テーブル間でデータのやりとりを行うので、2テーブル用意をしてください)#### BigQueryテーブル
テーブルについては以下の2つのテーブルを用意しました。– data_sources.users
から他の記事もご覧ください。
随時更新中ですのでお探しの内容に関する記事がない場合はコメントいただければ優先して記事にしようと思っています。また、投稿日が古い記事に関しては、現在のマネコンのUIと異なる場合がございます。
内容が異なる場合はコメントいただけると幸いです。本記事は、EC2というサービスと各種設定項目についてまとめた記事になります。
#EC2について
EC2が何か分からない方に向けて記載していこうと思います。知ってるわ！という方は飛ばしてください。EC2（Amazon Elastic Compute Cloud）は、475 以上のインスタンスと、最新のプロセッサ、ストレージ、ネットワーク、オペレーティングシステム、購入モデルを選択でき、ワークロードのニーズに最適に対応できる、最も幅広く、最も深いコンピューティングプラットフォームを提供するサービスになります。
簡単に言うと仮想サーバを
実務２ヶ月でAWS ソリューションアーキテクトプロフェッショナルをとった話。
### はじめに
実務経験約２ヶ月程度(正確には２ヶ月と17日)でAWSソリューションアーキテクトのアソシエイトとプロフェッショナルを取得した話です。おすすめの教材などを発信します。教材や情報が少なくて困った記憶があるので、ソリューションアーキテクトを取得しようとしている方の役に立てれば幸いです。### 経歴
2021年の4月1日からエンジニアとしてのキャリアをスタート。大学はロシア語専攻、前職は法務部。
ソリューションアーキテクトのアソシエイトレベルを4月10日に取得(入社２週間目)。点数は751/1000(合格点は720以上)
その後プロフェッショナルレベルを6月17日に取得。点数は815/1000(合格点は750以上)
当時のAWS自体を利用した経験としては自作アプリをAWSのEC2にデプロイした程度。業務でAWSを使った経験はほぼなかった。### 試験を受けたきっかけ
* インフラ周りの知識が壊滅的すぎた。独学でプログラミングを学び自作アプリを作る程度にはなれたものの、インフラ周りの知識が圧倒的に不足していると感じていました。エンジニアを志すまで全く情報工学系の知識
【AWS】ターゲットグループでEC2のヘルスチェックが失敗した
ターゲットグループで、EC2インスタンスのヘルスチェックが失敗していた。
## 試したけどダメだったこと
– Apacheの再起動
– EC2インスタンスを再起動
– Elastic IPの関連付けを解除
– 再度Elastic IPを関連付けるなどなど。ちなみにElastic IPを解除した直後数分のみヘルスチェックが成功していた。
## 解決方法
1. (学習用のため)EC2インスタンスに設定していたドメインを解除
2. EC2インスタンスにドメインを再設定
3. Apacheを再起動
Amazon AppStream 2.0 をネイティブアプリケーションモードで動かしてみた
# はじめに
[前回の記事](https://qiita.com/sugimount-a/items/dbfb9dbd5f60147c61b4)では、Amazon AppStream 2.0 の Workshop を行い、基本的なアプリケーションを操作する内容を確認しました。
今回は、Amazon AppStream 2.0 の専用クライアントをつかって、ネイティブアプリケーションモードで動かしてみようと思います。
ネイティブアプリケーションモードは、2020年2月に追加された機能で、ストリーム配信されているアプリケーションが、あたかもローカルで動かしているような感覚で操作できる機能です。従来の機能では、アプリケーション内の画面転送でしたが、よりスムーズに違和感がなくリモートアプリケーションを利用するための機能です。
今回の記事は、ネイティブアプリケーションモードを試してみる内容です。
# ネイティブアプリケーションモードを動かす
AppStream 2.0 の専用クライアントを稼働して、Start in native application mode のチェックをオン
EC2インスタンスの通信状態をpingコマンドで調べる。セキュリティグループでインバウンドルールの設定が必要。
EC2インスタンスの通信状態を`ping`コマンドで調べたところ、タイムアウトになった。
ブラウザからアクセスすることはできる。
# 解決方法
セキュリティグループのインバウンドルールで下記の設定をして、pingコマンドによる通信を許可する。
– タイプ 全てのICPM-IPv4
– リソースタイプAnywhere-IPv4
– ソース 0.0.0.0/0
結果
（今回は特に設定を変更せず）右下の【割り当て】を押下する。
Elastic IPアドレス自体の作成は完
Amazon AppStream 2.0 で、ローカル環境とファイルのやり取りを行ってみた
# はじめに
[前回の記事](https://qiita.com/sugimount-a/items/dbfb9dbd5f60147c61b4)では、Amazon AppStream 2.0 の Workshop を行い、基本的なアプリケーションを操作する内容を確認しました。
今回は、AppStream 2.0 を利用する中で、ローカルとリモート環境感でファイルを受け渡したいと思うことがあると思います。
主なファイルの受け渡し方法は2種類あります。
– Home Folder を使った、ファイルのダウンロード・アップロード
– ローカルドライブのシェア (AppStream2.0 の専用Client のみ)それぞれの操作方法を確認してみましょう。
# Home Folder を使った受け渡し
Home Folder を使うことで、ローカルからファイルをアップロードしたり、AppStream 2.0 のリモート環境で生成したファイルをローカル側にdownloadできます。この Home Folder は、バックエンド側で自動的に S3 と同期されています。仕組みや
送信元IPアドレスとVPCエンドポイントに基づいてAWSマネジメントコンソールへのアクセスを制限したい
#はじめに
セキュリティ要件によりAWSマネジメントコンソールへのアクセスをIPアドレスで制限したい場合があります。
しかし__AWSマネジメントコンソールにログインするIPアドレスを制限することはできません。__
代わりにIAMポリシーのグローバル条件キーであるaws:SourceIpを使用して権限でAWSサービスへの操作が可能なIPアドレスを制限することが可能です。https://aws.amazon.com/jp/premiumsupport/knowledge-center/iam-restrict-calls-ip-addresses/
基本的には公式で紹介されているAssumeRoleを使用した解決できますが、AssumeRoleを使用せず直接IAMユーザの権限を使用してAWSの操作が可能なポリシーを作成する方法を紹介します。
Direct ConnectやVPNでプライベートな接続を行っている環境でインターネットへの接続がプロキシで制限されている場合等を想定しています。#課題
前述した通り公式で紹介されているポリシーでソースIPに基づいてアクセスの制限を行うこと
IAMのポリシーにジョブ機能ってあるけどこれなに？
## 勉強前イメージ
正直良くわからん・・・
## 調査
### IAMとポリシーについて
Identity and Access Management の略で、AWSのサービス。
ユーザを作ったり、そのユーザに対してサービスへのアクセス等の制御を行うことができます。
そしてポリシーとはユーザに対して「s3へのアップロードのみの権限」や、「EC2の閲覧のみの権限」など各サービスへの制御を行うものを指します。
今回そこに「ジョブ機能」というのがあったので調べてみました。
ちなみにマネジメントコンソールだとIAMのポリシーの以下になります。
### ジョブ機能 とは
職務機能のAWS管理ポリシーと呼ばれていて、AWS管理ポリシーの一部です。
A
AWS S3ストレージクラスまとめ
AWS SAAの勉強に向けたまとめなので、詳細は以下ページを参考にしてください。
[AWS公式 S3ストレージクラスの説明](https://aws.amazon.com/jp/s3/storage-classes/)#ストレージクラスの種類
* スタンダード
* 標準低頻度アクセス
* 1ゾーン低頻度アクセス
* 低冗長化ストレージ
* Glacier Flexible Retrieval（旧名：Glacier）
* Glacier Deep Archive
* Intelligent-Tiering##スタンダード
* デフォルトのストレージクラス
* **3ヶ所のAZ**で冗長化
* 耐久性は 99.999999999%（通称：イレブンナイン）##標準低頻度アクセス
* 耐久性はスタンダードと同じ
* **読み取りに対して課金**
⇒長期保管やバックアップ向き##低冗長化ストレージ
* **2か所のAZ**で冗長化するため安価##Glacier Flexible Retrieval（旧名：Glacier）
* Glacier(=氷河)は、低頻度アクセス
