- 1. クロスアカウント・クロスリージョンなCodePipelineを実行する
- 2. 俺のAWSセキュリティ管理
- 3. IAMユーザーとIAMロールは似ていることのメモ
- 4. AWS CopilotでSpringBootアプリケーション(Kotlin)をECSにデプロイする
- 5. Terraform で AWS VPC の環境づくり[入門]
- 6. AWS VPC の設定を terraform init [入門]
- 7. Amazon Personalize では Role だけではなく S3 バケットにもポリシーを書く必要がある
- 8. AWSのt2.2xlargeをhibernationしながら常用する
- 9. [AWS] 安価で簡単にRedmineの環境を作成・管理できるよ!そうLightsailならね
- 10. メモ:Elastic IPアドレスの一覧を取得する
- 11. AWS AmplifyのAuthで取得した認証情報をAWS SDKのCredentialProviderChainを利用して埋め込む
- 12. FlutterとAWSで始めるサービス開発 (8)Cognitoの認証情報を使ってAPIを呼び出す
- 13. EC2にPostgreSQLをインストールする方法(動作確認用)
- 14. 【今日から始めるAWS】LambdaでLINEのbotをつくる
- 15. 【AWS】 押さえておくべきポイント <IAM, Security Group, AMI>
- 16. AWS Dynamo DBへのcsvインポートを手軽に実装(Windows・無料)
- 17. AWSとAzureの比較(リージョン・AZ)
- 18. AWSサーバレス環境でSPARQLエンドポイントを作ろうとしたが上手くいかなかった話
- 19. 【AWS】Cross-Account CICD
- 20. EC2 Amazon Linux 2 + nginx で Laravel の環境構築の際によく使うコマンド
クロスアカウント・クロスリージョンなCodePipelineを実行する
# はじめに
[以前の記事](https://qiita.com/neruneruo/items/0daf2b30c59582007c4e)で、クロスアカウントなパイプラインを実行するコツをまとめてみた。今回は、さらにこの2つのイベント連携部分をクロスリージョンにするにはどうしたら良いかを考えた。
最初に結論を書いておくと、CodePipelineのクロスリージョンアクションを使うのが良い、ということだ。
【AWS公式】[CodePipeline でクロスリージョンアクションを追加する](https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/actions-create-cross-region.html)
# 検討経緯
以下の記事を参考にして、CodePipelineの完了時にS3にファイルを突っ込んでトリガしたり、サービス側アカウントにSNSトピックを置いて、CodePipelineの完了時にビルドアカウント側からPublishしてリージョン跨ぎのLambdaを起動したりした。【参考】【Deve
俺のAWSセキュリティ管理
個人的にAWSのセキュリティ管理のためにつかっているものをザっと並べてみました。
セキュリティ管理に終わりはないので、随時アップデートや新サービスが登場したら利用していこうとおもいます。##使用サービス一覧
**アカウント管理**
・IAM(ユーザー、ロール、グループ、ポリシー)
**履歴の記録**
・Cloud Trails
・AWS Config
**ログ(履歴)の保存**
・S3
**検知**
・Guard Duty
・IAM Access Analyzer
・Security Hub
**通知**
・SNS
・CloudFormation
**請求系**
・Cost Explorer
・AWS Budgets
**AWS CLI**
・AWS Vault
**外部アプリ**
・spark
・1password
・Authy##各詳細
**アカウント管理**
・IAMはrootユーザーを使わないでIAMユーザーを使用。権限は最小限に。
**履歴の保存**
・Cloud Trailsですべての証跡ログを記録する。
・AWS Configで特定のリソースの変更履歴を記録する。
IAMユーザーとIAMロールは似ていることのメモ
#なぜIAMユーザーとIAMロールを比べるか
IAMの勉強をしていると、概念が多いことやAWS独自の用語、位置関係と複雑なことが多くいつも混乱しがちです。特にIAMのユーザー、ポリシー、ロールの概念は非常に初心者にとっては難しいと思います。そしていつもポリシーに注目がいきがち。ただ、IAMユーザーとIAMロールが非常に似ているということを理解してからだいぶIAMあたりの概念の理がしやすくなったのでメモとして。
##IAMユーザーとIAMロールは似ている
自分なりにIAMユーザーとロールについて表現してみました。“`
IAMユーザーとは、IAMアイデンティティでありアクセス許可ポリシーをもつAWS IDである。
“`
(以下細かい説明)
**アクセス許可ポリシー** = ポリシーによって付与されるアクセス許可(IAMユーザーよりIAMグループに付与することが推奨)
**AWS ID** = 「そのユーザーはだれか」“`
IAMロールとは、IAMユーザーと同様にIAMアイデンティティであり特定のアクセス権限(アクセス許可ポリシー)をもつAWS IDであり、
AWSサービス
AWS CopilotでSpringBootアプリケーション(Kotlin)をECSにデプロイする
# 概要
AWS Copilotを使い、AWS ECS x Fargateへアプリケーションをデプロイしてみます。# AWS Copilotとは?
– 「Copilot」を和訳すると「副操縦士」
– AWSが提供するECS CLIの後継
– 従来のECS CLIより**簡単にFargateへのコンテナデプロイを実現できる**
– 詳しくは[AWSのブログ](https://aws.amazon.com/jp/blogs/news/introducing-aws-copilot/)を参照
– AWS Copilotのソースコードは[github](https://github.com/aws/copilot-cli)に公開されている簡単に言うと、**「ちゃんと動くDockerfile」**があれば、`$ copilot init` とか `$ copilot deploy` といった**簡単なコマンドだけでECSにアプリケーションをデプロイできるよ!**というツールです。
# モチベーション
– 従来であれば、こうしたECS環境を使った公開アプリケーションを開発しようとしたとき
Terraform で AWS VPC の環境づくり[入門]
# やりたいこと
terraform の大まかな流れが知りたい。
とりあえず AWS VPC の環境を作成して、確認後廃棄。# 各種ファイルの用意
## VPC 本体
### vpc.tf
“`tf
variable “aws_region” {}provider “aws” {
version = “~> 3.1”
region = var.aws_region
}variable “project_prefix” {}
variable “vpc_cidr” {}resource “aws_vpc” “vpc” {
cidr_block = var.vpc_cidr
instance_tenancy = “default”enable_dns_support = true
enable_dns_hostnames = truetags = {
Name = “${var.project_prefix}-vpc”
}
}
“`## 変数の設定
### test.tfvars
“`t
AWS VPC の設定を terraform init [入門]
`terraform init` に成功するまでに少し詰まったので、構文理解のためにも成功前後のファイル差分と解決までの道程を残しておく。
# やること
`terraform init` まずはこれだけ。
# init 成功ファイル
## vpc.tf
“`tf
provider “aws” {
version = “~> 3.1”
}variable “project_prefix” {}
variable “vpc_cidr” {}resource “aws_vpc” “vpc” {
name = “${var.project_prefix}-vpc”
cidr_block = var.vpc_cidr
instance_tenancy = “default”enable_dns_support = true
enable_dns_hostnames = truetags = {
Name = var.project_prefix
}
}
“`# エラー解決の道程
#
Amazon Personalize では Role だけではなく S3 バケットにもポリシーを書く必要がある
# 概要
Amazon Personalize にデータをインポートするときに S3 のバケットポリシーも記載する必要があり、少しはまったので共有します。# やり方
## Role のポリシー“`json
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Action”: [
“s3:ListBucket”
],
“Effect”: “Allow”,
“Resource”: [
“arn:aws:s3:::バケット名”
]
},
{
“Action”: [
“s3:GetObject”,
“s3:PutObject”
],
“Effect”: “Allow”,
AWSのt2.2xlargeをhibernationしながら常用する
AWSは、2018年末辺りから、[インスタンスの休止(ハイバネーション)](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Hibernate.html)ができるようになりました。
しばらくは、Amazon Linuxでしか使えなかったのですが、[2019年にUbuntuでも使えるようになり](https://aws.amazon.com/jp/about-aws/whats-new/2019/07/amazon-ec2-hibernation-now-available-ubuntu-1804-lts/)、必要な時だけ立ち上げ、終わったら休止というのができるようになりました。たとえば、時間のかかるビルドをするときに、ビルドが終わったら休止しておけば、コストを抑えられますし、シャットダウンと違って、エラーの確認も再開後すぐにできます。
しかし、休止をAWS Consoleからするのでは面倒です。そのため、実行中のインスタンスから休止できるコマンドを作成します。
“`hibernate.sh
#!/bin/sh
[AWS] 安価で簡単にRedmineの環境を作成・管理できるよ!そうLightsailならね
# Redmine
今更説明する必要もありませんが、Webベースのプロジェクト管理ツールです。
AWSでは、DB(PostgreSQL、MySQL)や全文検索(Elasticsearch)、あるいはコンテナ管理(Kubernetes)など、様々なOSSをマネージドサービスとして提供されていますが、残念ながらプロジェクト管理や課題管理をしてくれるサービスがありません(2020年8月現在)。これらのサービスを利用しようと思ったら、
* EC2インスタンス上で起動
* ECSでRedmineのコンテナを起動少なくともAWS上で、ということを考えると、この辺がすぐに思い浮かぶと思います。
などが考えられると思います。
が、しかし、もっと簡単な方法があるのです。それも定額で。# Amazon Lightsail
AWSでの仮想サーバといえば、すぐに思い浮かぶのは、やはりEC2だと思います。
EC2は、多種多様なインスタンスやOSの選択ができる一方、課金がインスタンスの稼働時間に依存するため、気がつくと高額になっている、なんてことも実はない話ではありません。
しかし、Lightsa
メモ:Elastic IPアドレスの一覧を取得する
# バージョン
“`bash
$ aws –version
aws-cli/2.0.25 Python/3.7.4 Darwin/19.5.0 botocore/2.0.0dev29
“`“`bash
$ jq –version
jq-1.6
“`# コマンド
“`bash
aws ec2 describe-addresses | jq ‘.Addresses[].PublicIp’ > eip.csv
“`
AWS AmplifyのAuthで取得した認証情報をAWS SDKのCredentialProviderChainを利用して埋め込む
前回からの続き
[AWS Amplify Libraryで取得した認証をAWS SDKで利用する](https://qiita.com/kent-hamaguchi/items/425cd178beb22555835c)
**CredentialProviderChainから認証が通ってAWS SDKの処理が動いた時点で書き込んでおり、肝心の認証情報が失効したあとの自動更新はまだ確認していません。確認できたら追記します。**
とりあえず、調べてもほとんど情報が出てこない、“`CredentialProviderChain“`の使い方メモ的にでも残しておく。
# やること
Amplifyの “`Auth.currentUserCredentials()“` で取得した認証情報は1時間で失効する。この方法で取得した認証情報をAWS SDKに引き継いで利用する場合などにおいて、1時間以上時間が空いたあとに処理を再開すると使えなくなる。
( SPAなどでアプリケーションを提供していて、1時間以上画面を放置した場合とか)
それを回避するために、自前で認証情報が失効するタイム
FlutterとAWSで始めるサービス開発 (8)Cognitoの認証情報を使ってAPIを呼び出す
# はじめに
「[(5)AWS Cognitoでログイン](https://qiita.com/makotomi/items/a0b05e8819270072780b)」や、「[(7)AWS Cognito Googleでログイン](https://qiita.com/makotomi/items/e7ee81006a9505d468a0)」で、Cognitoを使ったログイン処理を一通り実装完了しました。今回はそれら認証情報がないと呼び出せないAPIを実装していきたいと思います。前回まででCognito ユーザープールからID Tokenを取得するところまではできています。APIを呼び出すために、ID Tokenを要求し、それを検証してから実行するAPIを作っていきます。つまり、ログインした場合だけサービスのAPIを呼び出せるというモデルを実現するための構成です。認証した上でさらに特定の権限を持っているユーザーだけが利用できるといったAPIも考えられますが、今回はそこまでは踏みこみません。# 参考文献
– 公式サイト
– [サインイン後に API Gateway および La
EC2にPostgreSQLをインストールする方法(動作確認用)
# インストール
“`
sudo yum update # 省略していい
sudo yum install postgresql postgresql-libs postgresql-server # 何をインストールしているのか未調査
sudo service postgresql initdb # これをしないと起動できないらしい
sudo service postgresql start
sudo service postgresql status
sudo chkconfig postgresql on # EC2起動時にPostgreSQLを起動してくれるらしい
“`# psqlを使う
postgresqlインストール時に作られるpostgresユーザに切り替える。
このユーザじゃないとpsqlを使えない。“`
sudo su – postgres
psql
create database testdb;
\l
\c testdb
“`# メモ
postgresユーザに切り替えるのが不便で分かりにくい。
安全のための設定と思われる。# 参考
Amaz
【今日から始めるAWS】LambdaでLINEのbotをつくる
#はじめに
30代未経験からエンジニア転職をめざすコーディング初学者のYNと申します。お読みいただきありがとうございます。
コーディング初学者にとってのAWS入門といえば`Lambda`!、サーバレスアプリを作ろう!、ということでメッセージをオウム返ししてくるLINEのbotをつくりました。
下記参考記事をそのままコピーした内容になってしまったのですが、学習ログとして投稿させていただきました。* [LambdaではじめてのLINE Botを作る](https://dev.classmethod.jp/articles/lambda-line-bot-tutorial/#toc-2)
* [AWS Lambdaを使ってLINEBotを作ってみよう!](https://qiita.com/shinbunbun_/items/ae09364504002d0c25f1)#今回やったこと
下記のように、こちらが送ったテキストメッセージをそのまま返答してくれる、オウム返しbotを作ります。
【AWS】 押さえておくべきポイント <IAM, Security Group, AMI># はじめに
以下のリンクがシンプルでわかりやすい説明のため、とても参考になりました。[【AWS初心者がインフラ設計/構築を理解するために、まず最初におさえるべきキーワード15選】]
(https://qiita.com/Futo_Horio/items/318d89eccdbf5697f8bf#00-aws%E3%81%AE%E5%9F%BA%E6%9C%AC%E6%A6%82%E5%BF%B5)## 対象範囲
– [S3 と CloudFront で静的 WEB サイトを構築](https://qiita.com/sayaka-tamura/items/531eaa6b302964583edd)
– [EC2 Linux で Web サーバを構築](https://qiita.com/sayaka-tamura/items/70c169aba1eaaab99c7b)上記記事内で実践した内容には以下が含まれています。
## 使用した機能
1. [リージョン (Region)](https://qiita.com/Futo_Horio/items/318d89eccd
AWS Dynamo DBへのcsvインポートを手軽に実装(Windows・無料)
#はじめに
[Tech Dive様の記事](https://tech-dive.xyz/2020/03/22/dynamodb%E3%81%B8csv%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92%E7%B0%A1%E5%8D%98%E3%81%AB%E3%82%A4%E3%83%B3%E3%83%9D%E3%83%BC%E3%83%88%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95/) を大変参考にさせて頂きました。この場を借りて御礼申し上げます。この記事は上記内容をWindows環境で実施した際の備忘録になります。
#筆者の環境
・Windows 10
・Git Bash#手順
1. [Python3](https://www.python.org/downloads/) のインストール2. Pandasのインストール `pip install pandas`
3. [aws cli](https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cl
AWSとAzureの比較(リージョン・AZ)
※個人の調査によるものです。誤りがあればご指摘ください
※2020/8/8現在の情報をもとにまとめました。AWSとAzureのリージョンなどの考え方を比較しました。
## AWS
| 分類レベル | 名称 | 定義 |
| — | — | — |
| レベル小 | データセンター | 1つの物理的なデータセンター |
| レベル中 | アベイラビリティゾーン (AZ) | 1 つの AWS リージョン内でそれぞれ切り離され、冗長的な電力源、ネットワーク、そして接続機能を備えている **1 つ以上のデータセンター**のことです。各 AZ はそれぞれ他の AZ から物理的に意味のある距離、つまり数キロメートル離れていますが、すべて 100 km 以内 (互いに 60 マイル) に配置されています。 |
| レベル大 | リージョン | 1 つの地理的エリアにある、**複数の、それぞれが隔離され物理的にも分離された AZ** によって構成されています。1 つのデータセンターを 1 つのリージョンとして定義することが多い他のクラウドプロバイダーとは違い、全 AWS リージ
AWSサーバレス環境でSPARQLエンドポイントを作ろうとしたが上手くいかなかった話
個人的に[SPARQLエンドポイント](https://ja.wikipedia.org/wiki/SPARQL)を作るときに、運用やメンテナンスが楽になればということでサーバレスでSPARQLエンドポイント作れないかと思い、AWSのサーバレス環境での構築に挑戦してみました。
結論から言うと、ちゃんと動きましたが、期待してたよりもうまくいきませんでした。
一応今回使ったコードは以下で公開していますが、利用される場合は以下を最後まで読まれることをお勧めします。
## 環境
– [AWS Lambda](https://aws.amazon.com/jp/lambda/)
– [Amazon API Gateway](https://aws.amazon.com/jp/api-gateway/)
– [Amazon Cloudfront](https://aws.amazon.com/jp/cloudfront/)Lambda と API Gatew
【AWS】Cross-Account CICD
![000.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/688363/62768cb8-d719-f82e-07aa-fb899a444aa0.jpeg)
#要件(ソースアカウント)
##IAM
CodePipeline用IAM RoleはターゲットアカウントのCodeBuildとCodeDeployのIAM RoleをAssumeできる必要がある。##S3
Bucket PolicyはターゲットアカウントのRootを許可する。##KMS
ソースアカウントでCMKを作成し、ターゲットアカウントのRootを許可する。##CodeCommit
通常通りに作成する。
##EventBridge
CodeCommitのRepositoryの特定のBranchが作成または更新した際に、CodePipelineを起動する。
“`yaml
Events:
Type: AWS::Events::Rule
Properties:
EventBusName: defau
EC2 Amazon Linux 2 + nginx で Laravel の環境構築の際によく使うコマンド
## yumアップデート
“`
sudo yum update -y
“`## nginxのインストール
“`
sudo amazon-linux-extras install nginx1.12 -y// nginxの起動
sudo systemctl start nginx// 自動起動設定(これをやっておくとEC2再起動などの際に自動で起動してくれる)
sudo systemctl enable nginx// nginxのステータス確認(起動失敗時などに調査で使用する)
systemctl status nginx.service
“`## PHPのインストール
“`
sudo amazon-linux-extras install php7.3// Laravelを動かすためには php-xmlとphp-mbstringが必要
sudo yum install php-xml php-mbstring
“`## Composerのインストール
“`
sudo curl -sS https://getcomposer.org/inst