- 1. CIS Amazon Web Services Foundations Benchmark v1.3 -> v1.4 の変更点
- 2. AWS CloudFormationからConfig適合パックをデプロイする
- 3. [ AWS EKS編 ] AWS Fargate & ECR で Golang の Webアプリをデプロイする
- 4. AWSの API Gatewayを使ってLambdaを実行する。
- 5. AWS CLIとShellであれこれするTips
- 6. T系インスタンスについてざっくり理解する
- 7. ローカル端末からIAMユーザのポリシー制限+MFA+STSで安全にアクセスキーを使用する
- 8. wordpressサイトをterraformで構築する
- 9. AWS（VPC/EC2/RDS/Routes53）デプロイ時のエラー
- 10. AWS：Rekognitionとpythonで顔の分析を行ってみる
- 11. S3へクロスアカウントでファイルアップロードしたときの権限エラーについて
- 12. S3へのクロスアカウントアクセスを設定してみた
- 13. CloudEndure Migrationを使ってオンプレミスサーバーをAmazon EC2に移行する
- 14. CodeDeploy – EC2デプロイのログデータの確認方法
- 15. Lambdaを定期的に実行する
- 16. lambdaでnpm moduleを使う方法
- 17. CloudFormationでALBアクセスログ設定時のエラー
- 18. SAAの勉強でわからなかった用語をメモ
- 19. AWS Cloud9で「Failed to write to XXX」エラーがでてファイル保存ができない際の対応
- 20. Ruby・Railsで作ったポートフォリオをPHP・Laravelでリメイクしてみた
CIS Amazon Web Services Foundations Benchmark v1.3 -> v1.4 の変更点
CIS Amazon Web Services Foundations Benchmarkのv1.4が出ていたので、v1.3との変更点を確認しました。
## 1 Identity and Access Management
### 1.12 Ensure credentials unused for 45 days or greater are disabled (Automated)
変更前）
1.12 Ensure credentials unused for 90 days or greater are disabled (Automated)> 説明）
AWS IAM users can access AWS resources using different types of credentials, such as passwords or access keys. It is recommended that all credentials that have been unused in 45 or greater days be deactivated o
AWS CloudFormationからConfig適合パックをデプロイする
AWSのConfig適合パックを、ConfigではなくCloudFormationからデプロイする方法です。
## テンプレートの書き方
CloudFormationテンプレートは、例えば次のように書きます。
“`yaml
AWSTemplateFormatVersion: 2010-09-09
Resources:
MyConformancePack:
Type: AWS::Config::ConformancePack
Properties:
ConformancePackName: my-conformance-pack
TemplateBody: |-
“`ここで、`
` は、デプロイしたい適合パックのテンプレートに置き換えます。例えば、次のようにします。 “`yaml
AWSTemplateFormatVersion: 2010-09-09
Resources:
MyConformancePack:
Type
[ AWS EKS編 ] AWS Fargate & ECR で Golang の Webアプリをデプロイする
# はじめに
コンテナ基盤でwebサービスを運用する際には、kubernetesというコンテナオーケストレーションサービスを用いることが多いそうなので、kubernetesの基本的な部分に関して学習をしたのち、
AWS EKSにてwebアプリをデプロイしてみた。# kubernetesについて
kubernetesの基本的な概念について把握をするために、まずはじめに公式のチュートリアルをざっとこなしてみた。https://kubernetes.io/ja/docs/tutorials/
公式チュートリアルを一通りこなした後は、EKSにてデプロイすることに挑戦した。
以前、AWS ECSにてコンテナ基盤でwebアプリをデプロイしたことがあったため、
デプロイするための大まかな流れについてはイメージがしやすかった。# EKSにデプロイ
AWS EKSへのデプロイについては基本的にAWSの公式ドキュメントを参考にして試行錯誤しながら行なった。## 事前準備
EKSのリソースを操作するためには、ローカル上で実行する、 `kubectl` , `eksctl` コマンドをインス
AWSの API Gatewayを使ってLambdaを実行する。
## はじめに
先日、S3へのファイルアップロードをトリガーに、別のS3にそのファイルをコピーする簡単なLambdaを作成してみたが、今度は`API Geteway`経由でLambdaを実行する方法を試してみたので、その時の内容をメモとして残しておく。
※ 先日の記事はこちら。[**【AWSのLambdaを使ってS3間のファイルコピーを試してみた。】**](https://qiita.com/smiler5617/items/66eb929bd6bac7737615)## 今回やってみたい事
####片方のS3バケットの特定のプレフィックス中身を全て、もう片方のバケットに移動するLabmda①、および移動後のバケット中身（csvレコード）を取り出すLambda②を作成し、それらのLambdaをAPI Gateway経由で実行できる様にする。
 | [.PublicIp, .AllocationId]’
“`下記のように一覧される。^のnotを外せばAWS Resourceに紐付いたEIP一覧
T系インスタンスについてざっくり理解する
#はじめに
T3,M4,C4など様々なインスタンスタイプがありますが、
ややクセがあるT系のインスタンスタイプについて理解が深まる機会があったので
そちらについて書いておこうと思います。#T系インスタンスとは
・T2インスタンス
>T2 インスタンスは、ベースラインレベルの CPU パフォーマンスを提供するバースト可能パフォーマンスインスタンスで、ベースラインを超えるレベルにパフォーマンスをバーストさせる機能を備えています。・T3インスタンス
>T3 インスタンスは、ベースラインレベルの CPU パフォーマンスを提供する次世代のバースト可能な汎用インスタンスタイプで、いつでも必要な時間だけ CPU 使用率をバーストさせる機能を備えています。T3 インスタンスはバランスの取れたコンピューティング、メモリ、およびネットワークのリソースを提供し、使用中に一時的なスパイクが生じる中程度の CPU 使用率を持つアプリケーション向けに設計されています。以上が公式ドキュメントからの引用になります。
簡単に言えば、普段はしょぼい（ベースラインレベルCPU）けど
必要に応じてパワーアップ（バ
ローカル端末からIAMユーザのポリシー制限+MFA+STSで安全にアクセスキーを使用する
# 目的
AWSCLIを使う場合、EC2インスタンスの場合はインスタンスにEC2ロールを付与するなどで使うことができるがローカルの端末からAWSCLIを使う時にどうしてもIAMユーザのアクセスキーが必要となる。ベストプラクティスに則ってアクセスキーを発行する場合、流出時の影響を最小限にするためIAMユーザのポリシーを制限してアクセスキーを発行すると思うのだが、プライベートな学習用途などで使う場合最小ポリシーでキーを発行するとAWSCLIのちょっとした操作がAccessDeniedされまくって面倒。そこでIAMユーザのポリシー制限+MFA+STSを使ってなるべく安全かつ便利にアクセスキーを使用できるようにする。# 手順
## 実際に作業するIAMロールを作成する
行いたい操作ができるポリシーを付与したIAMロールを作成する。ロールの作成時に「信頼されたエンティティ」に別のAWSアカウントを指定してアカウントIDに自身のAWSアカウントのアカウントIDを入力する。また、オプションの「MFAが必要」にチェックをつける。それ以降は好きなポリシーを設定してください。ただ、IAM操作系のポリシ
wordpressサイトをterraformで構築する
#本記事のゴール
https://qiita.com/chanP_yamazaki/items/3691d624a3510236458a「AWSでwordpressを動かす」1~5までの内容をほぼほぼ網羅した構成をterraformで構築する
# 参考資料
https://registry.terraform.io/providers/hashicorp/aws/latest/docs#terraformのインストール
インストール
公式サイトからバイナリをDLして解凍
https://learn.hashicorp.com/tutorials/terraform/install-cli“`
$ mkdir -p ~/Applications/terraform
$ mv DLしたterraformファイル ~/Applications/terraform/
$ export PATH=$PATH:~/Applications/terraform/
“`#プロジェクトのディレクトリ構成
“`
project
┣━ main.tf
┣━ network.tf
AWS（VPC/EC2/RDS/Routes53）デプロイ時のエラー
## はじめに
AWS（VPC/EC2/RDS/Routes53）を使用してポートフォリオアプリをデプロイしました。参考にしたQiita記事を貼り付けておきます。
– https://qiita.com/take18k_tech/items/5710ad9d00ea4c13ce36
この記事では、上記記事を参考にデプロイした際のエラーについて解決方法を記載します。
## 開発環境
– Ruby 2.7.2
– Rails 6.1.4
– Docker
– MySQL
– CircleCI(RSpec、Rubocop)## デプロイしたアプリのインフラ構成図
– 参考（デプロイしたポートフォリオのアプリ）↓
– http://target-01.work/
## エラー内容
### yumがアップデー
AWS：Rekognitionとpythonで顔の分析を行ってみる
#AWSのサービスを色々使って、理解を深める。
AWSの勉強をしていたら予想以上に色々できることに驚いた。
AWSを自由自在に使えたら便利なのでは？と思い付き、やってみた。
###参考
①_Qiita記事（コードの内容）
https://qiita.com/banquet_kuma/items/560787299b83fb924ff7
②_AWS_Rekognition公式入門ガイド
https://aws.amazon.com/jp/rekognition/resources/
③_AWS_Rekognition detect_facesオペレーション
https://docs.aws.amazon.com/ja_jp/rekognition/latest/dg/faces-detect-images.html###内容
1. IAMユーザーの作成2. AWS CLI と AWS SDK をインストールして設定
※基本は参考③を見ながら実行しました。
※アクセスキーのデータは参考①のpythonのライブラリ「configparser」を使用３. コードの記述及び
S3へクロスアカウントでファイルアップロードしたときの権限エラーについて
#はじめに
S3へクロスアカウントアクセスの設定をした際に、
アップロードしたファイルがダウンロードできない(Access Denied)になってしまったので
そのときの対応について書いておこうと思います。#原因
EC2など(アカウントA)→S3(アカウントB)とクロスアカウントでアップロードした際に
アップロードしたオブジェクトの所有者がアカウントA側になってしまっていることが原因。S3のコンソールからアップロードしたファイルのアクセス許可を確認すると
このような画面になっているはず。
#解決方法
アップロード時のコマンドに「–acl bucket-owner-full-control」を追加する。やってみた↓
“`
aws s3api put-object –bucket
S3へのクロスアカウントアクセスを設定してみた
#はじめに
・S3（アカウントA）←EC2（アカウントB）というアカウントまたぎのアクセスを設定する機会があったので、設定方法を残しておきます。#概要
そもそもS3へのアクセスを設定する方法は主に以下の２つ
①S3アクセス用のIAMユーザを発行し、
EC2にアクセスキー・シークレットアクセスキーを埋め込んでしまう
（セキュリティ的に非推奨：参照↓）
https://zenn.dev/yutaro1985/articles/daa2aaa6cc9907#%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%82%AD%E3%83%BC%E3%82%92%E5%85%B1%E6%9C%89%E3%81%97%E3%81%AA%E3%81%84
②IAMロールを作成し、IAMロールにS3へのアクセス権があるIAMポリシーをアタッチ、
作成したIAMロールをEC2にアタッチする。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/cross-account-access-s3/①のやり方だと
CloudEndure Migrationを使ってオンプレミスサーバーをAmazon EC2に移行する
#1.CloudEndure Migration#
– エージェント型サーバ移行サービス
– エージェントインストール時のOS再起動は不要。
– 物理/仮想マシンを問わない。
– 管理コンソールはSaaSで提供。– ブロック単位の差分転送（暗号化）
– ニアゼロダウンタイム移行を実現。– 様々な移行OSをサポート。
– Windows Server 2003/2008/2012/2016/2019
– CentOS,RHEL,OEL,SUSE,Ubuntu,Debian– エージェントのインストール後90日間無料で移行。
#2.仕組み#
①CloudEndure用IAMユーザを作成し、CloudEndure Consoleから認証
②移行対象のソースマシンにCloudEndure Agentをインストール
③データは常に非同期で転送
④ステージング領域にレプリケーションサーバーが作成され、データをEBSにレプリケーション
⑤カットオーバー実行後、ステージングEBSから、スナップショットが作成され、コンバーターインスタンスにアタッチ→変換→ターゲットEC
CodeDeploy – EC2デプロイのログデータの確認方法
CodeDeployで作成されたログデータを表示するには、CloudWatch or インスタンスにログインしてログファイルを確認します。今回は後者です。
デプロイ先のEC2にssh接続し以下のコマンドで確認できます。
“`
tail -F /var/log/aws/codedeploy-agent/codedeploy-agent.log
“`## 参考
[公式サイト](https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/deployments-view-logs.html)
Lambdaを定期的に実行する
## 前提
定期的に実行したいLambdaが作成されていること。## 手順
1. 定期実行用のCloudWatch Events のルールを作成する
1. 1.のイベントをLambdaに紐づける### 定期実行用のCloudWatch Events のルールを作成する
Amazon CloudWatch Events とは
ざっくり言うと、AWSの各種リソースを監視して、設定したルールに該当した時にイベントを発火させるサービス。
>Amazon CloudWatch Events では、Amazon Web Services (AWS) リソースの変更を記述した、システムイベントのほぼリアルタイムのストリーミングを配信します。すぐに設定できる簡単なルールを使用して、ルールに一致したイベントを 1 つ以上のターゲット関数またはストリームに振り分けることができます。CloudWatch Events が発生すると、運用上の変更が認識されます。CloudWatch Events は、オペレーションの変更に応答し、必要に応じて、応答メッセージを環境に送り、機能をアクティブ化し、変
lambdaでnpm moduleを使う方法
## 前提
Lambda Functionが作成されていること。
ローカル環境にnpmがインストールされていること。## 手順
必要な作業は下記
1. 使いたいnpmライブラリをローカルにインストールしてzip化する
1. Lambda Layerを1.のzipをもとに作成し、Lambda Functionと紐づける
1. Lambda Functionのコード上からnpmライブラリを呼び出すLambda Layerとは
>Lambdaレイヤーは、追加のコードまたはデータを含むことができる .zip ファイルアーカイブです。レイヤーには、ライブラリ、 カスタムランタイム 、データ、または設定ファイルを含めることができます。レイヤーを使用すると、コードの共有と責任の分離を促進し、ビジネスロジックの記述をより迅速に繰り返すことができます。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-layers.html### 使いたいnpmライブラリをローカルにインストールしてzip化する
今回はnpmラ
CloudFormationでALBアクセスログ設定時のエラー
#1. 背景
CloudFormationでALBを構築する際、アクセスログ設定を記述したがバケットポリシー関連でエラーが出てハマったので、備忘録として書きます。#2. エラーメッセージ
以下のようなメッセージが出てハマりました。“`
Access Denied for bucket: {バケット名}. Please check S3bucket permission (Service: AmazonElasticLoadBalancing; Status Code: 400; Error Code: InvalidConfigurationRequest; Request ID: XXXXX; Proxy: null)
“`#3. YAML記述（修正前）
ALB, S3記述箇所は以下。（東京リージョンでデプロイ前提なのでPrincipalは直打ちしてます。）“`yaml:template.yml
# ————————————————————#
# S3 for Inter
SAAの勉強でわからなかった用語をメモ
### Route53 DNSのレコードタイプについて
Aレコード： IPv4でホスト名とIPアドレスの関連付けを定義する
AAAAレコード： IPv6でホスト名とIPアドレスの関連付けを定義する
CAAレコード： ドメイン名の登録者が、登録されたドメイン名に対応する証明書の発行を許可する認証局（Certification Authority：CA）を指定するリソースレコード
CNAMEレコード： 別名に対する正式名を指定するためのリソースレコード acme.example.com などの現在のレコードの名前に対する DNS クエリを、別のドメイン (example.com、example.net など) またはサブドメイン (acme.example.com、zenith.example.org など) にマッピング
DSレコード： 親ゾーンに設定される、子ゾーンのDNSKEYリソースレコードを参照するリソースレコード
MXレコード： mail exchange（メールサーバー、メールを配送するホスト）を指定するためのリソースレコード
NAPTRレコード： 名前付け権限ポインタ (N
AWS Cloud9で「Failed to write to XXX」エラーがでてファイル保存ができない際の対応
#エラー内容
・Cloud9でスクリプトを編集して保存しようとしたら、“`Failed to write to [scriptの本文] [object Object].“`のエラーが表示されファイルが保存できなくなった。
#原因
**EC2がマウントしているEBSボリュームに空き容量がないため。**“`
ec2-user:~/environment $ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 474M 0 474M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 460K 492M 1%
Ruby・Railsで作ったポートフォリオをPHP・Laravelでリメイクしてみた
# 目次
| 番号 | 項目 |
|:-:|:–|
| 1 | [はじめに](https://qiita.com/Yuhei_K/items/06805f3ac8607f77952f#1%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB) |
| 2 | [URL](https://qiita.com/Yuhei_K/items/06805f3ac8607f77952f#2url) |
| 3 | [2つの言語を学習した理由](https://qiita.com/Yuhei_K/items/06805f3ac8607f77952f#32%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E%E3%82%92%E5%AD%A6%E7%BF%92%E3%81%97%E3%81%9F%E7%90%86%E7%94%B1) |
| 4 | [工事現場情報サイト（PHP、Laravelで作成）](https://qiita.com/Yuhei_K/items/06805f3ac8607f77952f#4%E5%B7%A5%E4%BA%8B%E7%8F%
