[Flutter]AWS Cognito Hosted UIでSignInした後リダイレクトはできてもトークンが取得できなかった

# 概要
Flutterでweb開発を行っており、ユーザ認証機能をつけようとAWS Cognitoを用いています。
### 環境
– Flutter 3.10.2
– amplify_flutter: 1.3.2
– amplify_auth_cognito: 1.3.2
– locahlhost:xxxxでホスティングしたローカル開発中

### 問題
ユーザプール作成やHosted UI認証画面の表示まではうまくいっていましたが、SignIn成功後にリダイレクトは成功するものの、リダイレクト後に認証情報を取得できないという問題にぶつかりました。
詳細には説明しませんが、大まかな登場人物は以下です。
“`
# Amplifyのconfig
await Amplify.addPlugin(AmplifyAuthCognito());
await Amplify.configure(amplifyconfig);
“`
“`
# 認証画面の表示
await Amplify.Auth.signInWithWebUI();
“`
“`
# セッション情報取得
await Ampli

AWS CloudFormation: 04. S3 (+ CloudFront + OAC) による静的ウェブサイトのホスティング

# 本記事について

– AWS CloudFormationを用いて、色々なアーキテクチャを構築していきます
– 本記事では、S3を用いて静的ウェブサイトのホスティングを、以下の2つの方法で行います
– S3の静的ウェブサイトホスティング機能による公開
– S3をオリジンとして、CloudFront + OAC (Origin Access Control) による公開
– [最新テンプレートはGitHubに配置しています](https://github.com/iwatake2222/aws_cloudformation_template)

# S3の静的ウェブサイトホスティング

## 構築するアーキテクチャ


– まず、S3バケットを作成します
– バケット名は `${OrganizationName}-${SystemN

AWS SSOのIDプロバイダを消してしまったら、許可セットを再保存すれば復旧できる

`AWSSSO_*_DO_NO_DELETE`というID Providerをうっかり消してSSOログインできなくなった方へ。

1. SSO自体を管理しているAWSアカウントにログインし、IAM Identity Centerへ向かう
2. AWSアカウントの一覧からID Providerを削除してしまったアカウントを探す
3. ユーザーとグループのうち、行のどれかのラジオボタンを選択し、「許可セットを変更」を選択する
4. 変更用画面にて、なにもせずそのまま「変更を保存」する

これで復旧できます

# 参考記事

下記記事は旧AWS SSOサービスの画面であり、IAM Identity Centerには復旧ボタンがありません

https://dev.classmethod.jp/articles/aws-sso-repair-identit

AWS EC2初期設定をユーザーデータで

AWSでサーバー構築する用になって数年経つのに、実は**ユーザーデータ**を使ったことがなかったので
ユーザーデータを使った初歩的なサーバー初期設定に挑戦してみました。
せっかくなので、**CloudFormation**とも組み合わせてみました。

## やったこと
・ホスト名変更
・システムロケール/時刻設定
・ユーザー/グループ作成
・パッケージ更新
・再起動

実際の設定値はこんな感じ
| 項目 | 設定値 |
| —- | —- |
| ホスト名 | test |
| システムロケール | ja_JP.UTF-8 |
| タイムゾーン | Asia/Tokyo |
| 作成ユーザー | testuser01 |
| 作成ユーザーのパスワード | p@ssw0rd |
| 作成ユーザー所属グループ | testgroup01,wheel |

## ユーザーデータ
CloudFormationのコードは後述しますが、先に今回の肝となるユーザーデータを、、、

“`yaml:ユーザーデータ
#!/bin/bash
groupadd testgroup01
usera

【備忘録】AWSのセキュリティ対策について学んだことまとめ ~インフラ編①~

初めて投稿します！
私は現場でAWSを利用したシステム開発をする機会が多いのですが、
アプリ開発が主で今までAWSのリソースを触ったり作ったりすることが
あまりなかったのですが最近AWS環境基盤のシステムのセキュリティを
チェックしていく業務を体験しまして、何がどうなっていれば
セキュリティ的に安全と言えるのか勉強するきっかけになりました。

これから記事をインフラ面、リソース面、AWSで用意されている
セキュリティ対策機能面などに分けて一般的にセキュリティは
何を考慮する必要があって、AWSに置き換えるとどこをどう
いじったらいいのかを自分なりに調べてまとめたことを
実際に試していこうと思います！

では前置きはそこそこに、さっそくタイトルにある通り本記事では
以下の図のような一般的なWebサーバーの構築をやっていき、
どこがセキュリティのポイントになるのか
構築する環境の説明から順を追って解説していきます～

![AWS構成図(EC2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3522793/

IBM Turbonomic で確認できるFinOps

ここで紹介されているサイトでTurbonomic の機能をUIを確認していきます。

https://qiita.com/YoHey/items/52bd8ec4464dbaa87a5f

Turbonmicの機能は、クラウド環境のFinOpsとアプリケーション監視です。
それぞれの画面は以下の通りで、統一的なビューになっています。

・Cloud Infrastructure FinOps

・Applicaition Monitoring

(備忘) AWS ECS – デプロイタイプを CodeDeploy に変えると terraform apply で ECSサービスに紐づくタスク定義の設定が更新できなくなる

# 背景

CodepipelineでのECSのデプロイ方法をECS(ローリング)からCodeDeploy(blue/green)に変えたい

# エラー内容

ECSサービスの デプロイタイプを CODE_DEPLOY にするとタスク定義の更新ができなくなる

“`
Unable to update task definition on services with a CODE_DEPLOY deployment controller.
Use AWS CodeDeploy to trigger a new deployment.
“`

terraform appley 時にECSサービスに紐づくタスク定義の内容に差分があると上記エラーが発生するようだ。

# 概要

CODE DEPLOYで blue/greenデプロイをする場合はECSサービスでタスク定義を管理するのではなくCODE DEPLOY で管理するらしい。

かと言ってECSサービスのタスク定義を未設定にはできないようだ。(どうしろと)

“`
Error: creating ECS Service (**

AWS ECS の blue/greenデプロイ実行でエラー

# エラー内容

ECSでサービスを更新してblue/greenデプロイが開始した直後のエラー

>A deployment group associated with an application that uses the ECS compute platform must contain a valid pair of target groups that identify a load balancer. The target ECS service must be configured using one of those two target groups.

## 解決

– blue/greenデプロイに使うターゲットグループ2個両方をECSで利用しているALBに関連付ける
– ターゲットグループの片方をECSサービスに関連付ける

で解決した

片方がECSサービスに紐づいていればデプロイによってもう片方は勝手にECSに紐づいてくれるみたいだ

# Listnerのエラー

これもデプロイ実行直後のエラー

“`
The ELB could not be updat

[AWS CDK]RaspberryPiからIoT Coreを経由してLambdaまで到達する構成をCDKで構築してみた

RaspberryPiからIoT Coreを経由してLambdaまで到達する構成をCDKで構築してみました。ここではAWS側を主に扱うため、RaspberryPi自身の設定は扱いません。

全コードはGithubを参照してください。
[Githubはここ](https://github.com/ShinyaT1994/cdk-iot.git)


## 前提条件
– AWS CDK v.2 がインストールされていること
– Python 3.x がインストールされていること
– AWSアカウントがあり、AWS CLIが設定されていること

※Cloud9を使うとこの辺りがPassできるため、Cloud9を使って今回の記事の内容は作成しています。

## 構築手順
### 1. CDKアプリの初期化
先ずはCDKアプリの初期化を行います。

“`

AWS CloudFormation: 03. S3バケットの作成とポリシー・アクセス許可の設定

# 本記事について

– AWS CloudFormationを用いて、色々なアーキテクチャを構築していきます
– 本記事では、S3バケットを作成します。そして、そのS3バケットへのポリシー・アクセス許可の設定を以下の2パターンで行います
– S3バケットポリシーによる設定
– IAM ポリシーによる設定
– [最新テンプレートはGitHubに配置しています](https://github.com/iwatake2222/aws_cloudformation_template)

# S3バケットポリシーによる設定

## 構築するアーキテクチャ


– まず、S3バケットを作成します
– バケット名は `${OrganizationName}-${SystemName}-bucket` とします
– ついでに、サンプルとして、I

Terraformのポイント（自分用）

# 目的
TerraformでAWSリソースを作成する時のポイントを、自分用に備忘録として記事にします。

# 構成図

# リソースの作成

## IAMを作成する
作成するリソース名は公式ドキュメントから確認します。（リンクから確認できます）
* [IAMユーザの作成](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_user)
* [アクセスキーの作成](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_access_key)
* [ログインプロファイルの作成](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_user_login_profile)

“`ruby:iam_user.tf
resource “aws_iam_user” “test-u

VPC Endpointをはじめから

# はじめに
AWS Hands-on for Beginners でハンズオンしてみたものをアウトプットする資料として記事にまとめました。

**【Network編#1】AWS上にセキュアなプライベートネットワーク空間を作成する**

# 構成図

VPCEndpointの**Gateway型**と**Interface型**を構築し、SSMとS3に接続を試すシンプルな構成図です。

# ハンズオンの流れ

ハンズオンのざっくりとした全体の流れは、以下の通りです。

①WEBインスタンスを構築し、SSM接続を許可するIAMロールを付与します。
②SSM接続の確認をします。
③Internalインスタンスを立て、SSM接続を許可するIAMロールを付与します。
④ルートテーブルを編集し、**NATゲートウェイ経由**でプライベートサブネット内か

AWS CDK で Infrastructure as Code する: EC2編

こんにちは。AWS勉強中の @masatomix です。
最近ずっとAWSのAWS CDKをいじってます。今回は、VPC上にEC2インスタンスを立てていきます！

## 前提

– [AWS CDK で Infrastructure as Code する: VPC編](https://qiita.com/masatomix/items/fc414e98d6d0091db90d) でVPCが構築できていること

## やってみる

作りたい環境はこんな感じ。


EC2につけるセキュリティグループの作成、EC2にログインするためのキーペアの作成、そしてEC2インスタンスを作成しています。インスタンスはよくあるAmazon Linuxのami (ami-00d101850e971728d)を指定しました。

作成したキーペア のダウンロードとか、そのへんものちほど説明していきます。

### CDKのソースコード

コードです。

“`typescript:lib/BastionStack.t

RDS for PostgreSQL のクラスターパラメータグループを作成する

こんにちは。インサイトテクノロジーの松尾です！

さて、本記事では RDS for PostgreSQL でクラスターパラメータグループを作成する方法についてご紹介します。

※実際、AWS コンソールからは変更できないため、私の方でも少しはまりました・・・。本記事が何かのお役に立てば幸いです。

## はじめに

クラスターパラメータグループの作成なんて AWS コンソールから指定して作成するだけでは？ と思われる方も多いかもしれません。
実際、Aurora などでクラスターパラメータグループを作成/修正された経験がある方も多いと思います。

ところで RDS for PostgreSQL でクラスターパラメータグループが必要になるのはどういったときでしょうか？

それは、マルチ AZ DB クラスターを使用するときです。

> マルチ AZ DB クラスターでは、DB クラスターパラメータグループが使用されます。

参考：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_WorkingWithDBCl

AWS Well-Architected Labs Operational Excellence 100 Labs INVENTORY AND PATCH MANAGEMENTメモ

# はじめに

https://www.wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/

:::note warn
記載内容は上記の翻訳ではなく、意訳、要約を含みます。
手順も一部省略している部分もあります。
詳細や正確な手順を知りたい場合は本家サイトを参照ください。

画面スクショは本記事作成当時のものであり、今後のアップデートにより差異が発生する可能性があることをご留意ください。
:::

## Introduction

本ハンズオンでInfrastructure as Code（以降、IaC と呼ぶ）とOperations as Codeの概念を学ぶことができます。

## Intro

クラウドでは、環境をコードで管理することができます。
ワークロード全体をコードで定義、更新したり、運用手順をスクリプト化してイベントをトリガーとして実行を自動化することもできます。
これによりヒューマンエラーを回避し、運用手順が一貫した手順となります。

## Set

パラメータストアに登録されている値をTerraform内で取得し活用する

# はじめに
あらかじめパラメータストアに登録されている秘匿情報を用いてTerraformでAWS環境を構築する、という事は多々あると思います。
公式ドキュメントに記載があるのですが、具体的な例を交えた端的な活用方法が余り見当たらないので、残しときます。

# RDSのユーザー名、パスワードを登録する
以下の様なパラメータがパラメータストアに登録されています。
* `/dev/rds/username`: データベースユーザー名
* `/dev/rds/password`: データベースパスワード

[Twelve-Factor Appの3.設定](https://12factor.net/ja/config)に従がって環境毎にパラメータを分けたい為、[階層パラメータ](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-paramstore-hierarchies.html)を用いて先頭に環境名(`/dev`)を付けています。

# パラメータを取得しRDSを構築する
いきなりTerraf

WebページのSorryページをALBとLambdaのみで自動切替できるようにしてみた

目的
—
– ALB配下のEC2が全停止したらSorryページを表示

上記を実装するにあたり色々調べたが一か所に集約されていなかったため
記事にまとめてみようと思う。

前提
—
– 既に運用中のWebサイトがある
– WebサイトをAWSで構築している

利用するサービス
—
– ALB
– Lambda
– CloudWatch

実装方法
—

– ALB

まずALBのリスナールールに通常のWebサイトを
ターゲットとするルールに加えて、メンテナンスページ用のルールを
追加する。

①リスナールールの作成
　→条件に「パス」=「*」
　→「固定レスポンスを返す」を選択
　→レスポンスコード：503
　→メッセージの形式：text/html
　→レスポンス本文：以下参照

“`html

Webサイト名を入力

現在、メンテナンス中です。以下の時間帯ではサービスがご利用いただけません

TerragruntでTerraformコードを「適度に」DRYにする

# Overview
terraformのコードをDRYに保ったり、CLI実行を簡素化できるツール `terragrunt` を検証します。
ユースケースとしては `workspace` 管理されているterraform環境を `terragrunt` に移植するようなケースを想定します。

# Terraformのworkspace機能とは
https://www.terraform.io/language/state/workspaces

Terraform標準機能のひとつで、複数環境で同じTerraformコードを共有する際に利用できるソリューションです。

backendを自動で環境別で管理できたり、Terraformコード内に `${terraform.workspace}` 変数を用いて環境名を注入できるので、DRY性高くTerraformのコードを記述できます。

# Terragruntとは
https://terragrunt.gruntwork.io/

TerraformのコードをDRYでメンテナンス容易に行えるツールみたいです。
今回は `backend.tf

マルチテナントサービスにおけるDynamoDBの設計を考えてみる

今回はマルチテナントサービスにおけるDynamoDBの設計を考えてみたいと思います。

マルチテナントサービスの開発にあたりDB設計やセキュリティ対策について調べた備忘録的な記事ではありますが参考になれば幸いです。

この記事では、AWSのNoSQLデータベースであるDynamoDBの設計戦略を紹介します。

## そもそもマルチテナントサービスとは何か
マルチテナントサービスとは、一つのアプリケーションインスタンスを複数の利用者や組織が共有する形態のサービスです。

## DynamoDBの複合主キーについて
DynamoDBでは、Partition KeyとSort Keyの二つからなるComposite Primary Key(複合主キー)を使うことができます。Partition Keyはデータをパーティションに分散させ、Sort Keyはそのパーティション内でのデータの並べ方を制御します。これにより、効率的なデータアクセスパターンが実現できます。

## マルチテナントのデータ設計の戦略

マルチテナントサービスのDB設計にはいくつかのパターンがありますが、
本記事では

AWS CloudFormation: 02. アプリケーションサーバーの構築と踏み台サーバー経由でのアクセス方法

# 本記事について

– AWS CloudFormationを用いて、色々なアーキテクチャを構築していきます
– 今回は、アプリケーションサーバーを構築します
– また、プライベートサブネットに配置されたアプリケーションサーバーへ踏み台サーバー経由でアクセスする方法についても記載します
– [最新テンプレートはGitHubに配置しています](https://github.com/iwatake2222/aws_cloudformation_template)

## 構築するアーキテクチャ


– VPCやサブネットといったインフラ周りは既に作成済みであるため、図中赤字のEC2、IAM Role、S3のみを作成します
– Private SubnetにEC2 インスタンスを配置します。記事内では便宜上これをアプリケーションサーバーとみなしますが