1. はじめに 今回は、S3の同一リージョンレプリケーションについて学んでみました。 S3には、クロスリージョンレプリケーション（CRR）, 同一リージョンレプリケーション（SRR）の二種類のレプリケーション方式があります。 ２つのレプリケーションは名前の通り、CRRはリージョン間でS3のオブジェクトのコピーを行い、SRRは同一リージョン内でS3オブジェクトのコピーを行うことをいいます。 今回この記事を書こうとしたきっかけは、いまいちユースケースが思いつかなかったためです。 なのでドキュメントを読んでユースケースを書いていこうと思います。 2. 構成図 図の左：同一リージョンレプリケーション（SRR）、図の右：クロスリージョンレプリケーション 3. 同一リージョンレプリケーションとは（SRR）？ 同一リージョンレプリケーション（SRR）とは、同じAWSリージョン内のS3バケット間でオブジェクトを自動的にコピーする機能です。 4.　同一リージョンレプリケーション（SRR）のユースケース 同一リージョンレプリケーションはどのようなユースケースで利用されるのでしょうか？ 4.1. ログの集約 １つ目のユースケースは、複数のバケットや複数のアカウントにログを保管している場合、ログを簡単にコピーすることができます。 そうすることによって、ログの管理をシンプルにすることができます。 4.2. 本番稼働アカウントとテストアカウント間のライブレプリケーション ２つ目のユースケースは、アプリケーションの開発・検証中に本番環境のS3バケットのデータで検証を行いたいケースがあります。 同一リージョンレプリケーションを利用することによって、本番環境アカウントのS3バケットのデータを開発アカウントのS3バケットにコピーすることで、 開発・検証中に本番相当のデータを利用できるようになります。 4.3. データ主権に準拠する必要がある場合 S3のバックアップを遠隔地保管したいケースがあります。この場合、国外のリージョンへの保管を検討することがあるともいます。 しかし、法律やコンプライアンスの規制によりデータを国外のリージョンに保管できないケースがあります。 この場合、同一リージョンの別アカウントにS3のデータをコピーするケースがあります。 5. SRRの便利機能 5.1. S3 Replication Time Control S3 Replication Time Control (S3 RTC) という機能があります。この機能を利用すると99.9%のオブジェクトが15分以内にコピーすることができます。 この機能は、ビジネス要件で１５分以内にコピーを完了させる必要がある場合、利用されることがあります。 6. レプリケーションでコピーされる設定・コピーされない設定 6.1. レプリケーションでコピーされるもの レプリケーション設定でコピーされる項目を一部列挙します。 レプリケーション設定の追加後に作成されたオブジェクト 暗号化されていないオブジェクト ユーザー提供のキー (SSE-C) を使用して暗号化されたオブジェクト、Amazon S3 マネージドキー (SSE-S3) の下で保管時に暗号化されたオブジェクト、および AWS Key Management Service (SSE-KMS) に保存されている KMS キーで暗号化されたオブジェクト レプリケート元オブジェクトからレプリカへのオブジェクトメタデータ 作成日、更新日付等 オブジェクトタグ、存在する場合。 S3 オブジェクトロックの保持情報 6.1. レプリケーションでコピーされないもの レプリケーション設定前のオブジェクトはレプリケーション先にコピーされません。 もしコピーした場合は、別途レプリケーションを実行する必要があります。

1. はじめに AWSでAuorora, S3, EFSのバックアップ方法について検討していると、AWS Bacupというサービスがあることがわかりました。 RDSなどのサービスにはAWS Backupを利用せずに個別でバックアップ機能が備えられていますが、 AWS Backupを利用するメリット等、調べていました。 2. AWS Backupとは AWS Backupとは、AWSのさまざまなサービスにわたるバックアップを一元的に管理し、自動化するためのバックアップサービスです。AWS Backupを利用することで、複数のサービス（Amazon Aurora, Amazon S3, Amazon EFS, Amazon EC2, Amazon RDSなど）のバックアップを一元的に定義・実行できます。 ※この記事では、Amazon Aurora のバックアップについて取り扱います。 3. 構成要素 AWS Backupは、主に以下の3つの要素で構成されています。これらが連携することで、バックアップの**「どこに」「何を」「いつ・どのように」**実行するかを定義し、管理します。 3.1. バックアップボールト (Backup Vault) これは、作成されたバックアップデータが安全に保存される保管場所です。 保存場所: バックアップボールトは、バックアップされたリソースのデータが保管される場所です。 暗号化: バックアップデータは、KMSキーを使用して暗号化され、安全性が確保されます。 アクセス制御: IAMポリシーを使用して、誰が、いつ、どのようにボールト内のデータにアクセスできるかを厳密に制御できます。 ロック機能: ボールト内のバックアップを一定期間変更・削除できないようにロックする機能（Vault Lock）があり、コンプライアンス要件への対応に役立ちます。 3.2. バックアッププラン (Backup Plan) これは、**「いつ、どのように」**バックアップを作成するかを定義する要素です。 スケジュール設定: バックアップを作成する頻度（日次、週次、月次など）と時刻を定義します。 頻度とウィンドウ: バックアップジョブを実行する時間帯（バックアップウィンドウ）や、許容される完了時間を設定できます。 ライフサイクル設定: バックアップの保持期間を定義します。また、コールドストレージへの階層化（例：30日後に低コストのストレージに移行）のポリシーを設定し、コスト効率を高めることができます。 コピー設定: 異なるAWSリージョンや、別のAWSアカウントのバックアップボールトへ、自動的にバックアップをコピーする設定（クロスリージョン/クロスアカウントコピー）を含めることができます。 3.3. バックアップセレクション (Backup Selection) これは、**「どのAWSリソース」**をバックアッププランの対象とするかを定義するものです。 対象リソースの特定: 特定のAWSリソースタイプ（Aurora DBクラスタ、S3バケット、EFSファイルシステムなど）の中から、実際にバックアップを取得するインスタンスやボリューム、ファイルシステムを指定します。 4. メリット 4.1 一元管理 AWS Backupを利用することで、バックアップの一元管理を行うことが可能です。 Amazon Aurora のクラスターを複数管理しているアカウントがあるとします。 これらのクラスターごとでバックアップ設定を行うことは、手間がかかります。

1. はじめに この記事ではS3データレイクで自動テーブル作成とパーティション管理について記述していきます。 1.1 問題提起 データレイク（S3）にデータが蓄積されていく中で、分析に必要な「テーブル定義」やパーティションを手動で作成・更新することは非常に手間で非効率です。 また、手動で実施することによるミスも生じやすくなります。AWS Crawlerを利用することで、自動的にテーブル定義の作成やパーティションの追加を行うことが可能になります。 1.2. 具体例 新しいデータセットが追加されるたびに、AthenaでCREATE EXTERNAL TABLEを手打ちしている。 データが毎日増えるたびに、MSCK REPAIR TABLEやALTER TABLE ADD PARTITIONを実行し忘れてクエリに漏れが生じる。 3. AWS Glue Crawler とは AWS Glue Crawlerは、AWS GlueというAWSのフルマネージド型ETL（抽出・変換・ロード）サービスを構成する機能の一部です。 3.1. AWS Glue Crawlerの役割 データソースの走査（クロール） S3のファイルや各種データベースなどのターゲットデータストアに接続し、データを読み取ります。 スキーマの推論・解析 データの形式（CSV、JSON、Parquetなど）やカラム名、データ型などのスキーマ情報を自動で識別・推論します。 データカタログへの登録 推論したスキーマ情報に基づき、Glue Data Catalogにデータベースとテーブル定義を作成または更新します。 スキーマ変更の自動検出 定期的にクローラーを実行することで、データストアに新しいファイルが追加されたり、既存のデータのスキーマが変更されたりした場合も自動的に検出し、Data Catalogを更新できます。 3.2 メリット Glue クローラーを利用することで、分析対象のデータのスキーマを手動で定義する手間が削減されます。これにより、Amazon AthenaやAmazon Redshift Spectrumなどの他の分析サービスから、Data Catalogに登録されたメタデータを使って、すぐにデータにクエリを実行できるようになります。 4. 構築 AWS Glue CrawlerでS3のスキーマとパーティションを作成するための前準備です。 4.1. CloudFormationテンプレート（例） 以下、S3, Glue Crawler、Glue DataBaseのCloudFormationテンプレートです。 参考にしてみてください。 AWSTemplateFormatVersion: '2010-09-09' Description: AWS Glue Crawler, IAM Role, and S3 Bucket for Athena Partition Management Parameters: BucketName: Type: String Default: athena-partition-data Resources: AthenaDataBucket: Type: AWS::S3::Bucket Properties: BucketName: !Sub "${BucketName}-${AWS::AccountId}-${AWS::Region}" AccessControl: Private GlueCrawlerServiceRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: glue.amazonaws.com Action: sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSGlueServiceRole Policies: - PolicyName: S3AccessPolicy PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - s3:GetObject - s3:PutObject - s3:ListBucket Resource: - !GetAtt AthenaDataBucket.Arn - !Sub "${AthenaDataBucket.Arn}/*" GlueDatabase: Type: AWS::Glue::Database Properties: CatalogId: !Ref 'AWS::AccountId' DatabaseInput: Name: "glue-database-name" Description: Database for Athena queries AthenaPartitionCrawler: Type: AWS::Glue::Crawler DependsOn: GlueDatabase Properties: Name: athena-partition-update-crawler Role: !GetAtt GlueCrawlerServiceRole.Arn DatabaseName: !Ref GlueDatabase Targets: S3Targets: - Path: !Sub "s3://${AthenaDataBucket}/room_temperature_data/" SchemaChangePolicy: UpdateBehavior: LOG DeleteBehavior: LOG Outputs: DataBucketName: Description: "Data Bucket Name for CSV files" Value: !Ref AthenaDataBucket 4.2. S3のフォルダ構造 AWS Glue Crawlerがクロールする対象は、4.1 のTargets→S3Targets→Pathが room_temperature_data/ で指定します。 room_temperature_data/　配下のフォルダ構造をAWS Glue Crawlerが自動的に解析してパーティションの追加やスキーマの作成を行ってくれます。

1. はじめに AWS上でプロジェクトごとの料金を把握できていますか。 AWSアカウント上に複数のプロジェクトが稼働していて、特定のプロジェクトでどのくらい料金がかかっているか確認する方法を書いていきます。 プロジェクトごとに料金を把握するのに必要な要素は、 Billing and Cost Management の コスト配分タグ です。 コスト配分タグについて学んでいきましょう。 2. コスト配分タグとは？ コスト配分タグとは、AWSリソースにタグ付けを行い、コストをタグ単位で分析、可視化できる仕組みのことを言います。 2.1 コスト配分タグの概要 タグは、多くのAWSリソースにKey, Valueの形式で付与可能です。 リソースタイプ キー バリュー Lambda Project cloud-steps S3 Project cloud-steps このようにLambda, S3にProjectキーを付与することができます。 Projectごとにタグを設定するとcloud-stepsで利用しているリソースを抽出することができます。 2.1 「ユーザー定義タグ」と「AWS生成タグ」の違い ユーザー定義タグとAWS生成タグの違いについて説明します。 ユーザー定義タグとは、その名の通りユーザーがAWSリソースに対して定義できるタグのことです。 CloudFormationテンプレート例 VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 192.168.0.0/20 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name - Key: Project 一方で、AWS生成タグとは、AWSが自動的にAWSリソースに付与するタグのことをいいます。 AWSタグ例 aws:cloudformation:stack-id aws:createdBy aws:cloudformation:stack-name 3. コスト配分タグの使い方ステップ 3.1. タグの付与 タグをリソースに付与します。 タグの付与単位は各現場のタグの付与方針によります。 ここでは、プロジェクト単位でタグを付与します。 タグの設定意図は、プロジェクト単位のコストを可視化すとためです。 VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 192.168.0.0/20 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Project Value: cloud-steps 3.2. コスト配分タグ（ユーザー定義タグ）の有効化 AWSマネージメントコンソールの検索フォームから Billing and Cost Management 左メニューのコスト組織＞コスト配分タグをクリックする コスト配分タグ画面が表示されたらユーザー定義のコスト配分タグタブを選択 コスト配分タグとして有効化したいタグキーにチェックを入れる。※ここでは、cloud-stepsを選択 有効化ボタンをクリック 3.3. コスト配分タグ（AWS生成コスト配分タグ）の有効化（任意） AWSマネージメントコンソールの検索フォームから Billing and Cost Management 左メニューのコスト組織＞コスト配分タグをクリックする コスト配分タグ画面が表示されたらAWS生成コスト配分タブを選択 コスト配分タグとして有効化したいタグキーにチェックを入れる。※ここでは、aws:createdByを選択する 有効化ボタンをクリック 3.4. コストエクスプローラーの利用 AWSマネージメントコンソールの検索フォームから Billing and Cost Management 左メニューのコストと使用状況の分析＞Cost Explolerを選択する 右メニューのレポートパラメータのフィルター機能でユーザータグごとのコストを抽出する グループ化の条件＞ディメンション＞Tag＞Project フィルター＞タグ＞Project＞cloud-stepsをクリックする。 5. 躓いたポイント コスト配分タグは有効化直後反映されないことがあります。

1. はじめに Lambda ✕ ApiGatewayでAPIを構築することが良くあります。 この構成をAWS SAM や CloudForamtionで構築することがありましたが、APIが数十個構築する必要があるとLambdaごとにテンプレートを作成するのが大変になります。 また、手作業でテンプレートをAWS SAM に記載すると追加漏れや修正漏れが発生することが、見受けられました。 こういった場面で CDK を利用するとスマートに構築することができます。 2. やりたいこと Lambdaを複数定義する。 API GatewayとLambdaを紐付ける。 IAM を別スタックに分離する。 CLoudWatch のロググループを明示的に作成する。 前提 AWS CLIインストール済みであること Python3.13インストール済みであること AWS CDKインストール済みであること 3. 構成 3.1. スタックの構成 AppStack IamStack ↓ ↓ [Lambda] [IAM Role] ↓ [LogGroup] ↓ [API Gateway] 3.2. ディレクトリ構造 . └── cdk_test ├── app.py ├── cdk.json ├── functions.json ├── lambda │ ├── lambda_1 │ │ └── handler.py │ ├── lambda_2 │ │ └── handler.py │ └── handler.py ├── requirements-dev.txt ├── requirements.txt ├── source.bat ├── stacks │ ├── __init__.py │ ├── app_stack.py │ └── iam_stack.py 4. Lambdaの定義をjsonで管理するメリット Lambdaの追加や設定の変更時にコードを修正する必要がなくなる。 5. 実装コード紹介 5.1 functions.json Lambdaを追加する際はこのjsonファイルに記述する。

1. はじめに CloudWatch Logsに出力されるログによってプログラムの処理フローを分岐する必要がある要件がありました。 これまでCloudWatch Logsを操作する機会がなかったため、boto3を用いたログのフィルタリング方法について備忘録として記事を残します。 2. CloudWatch Logsとは CloudWatch Logsは、Lambda、EC2、CloudTrail、Route53などのAWSリソースから出力されるログをモニタリング、保存、検索するためのサービスです。 AWSマネジメントコンソールからログの閲覧や文字列検索が可能なほか、例えば ERROR という文字列を検出したタイミングでCloudWatch Alarmをトリガーし、SNSで通知を行うこともできます。 3. 環境 AWS Lambda（Python 3.13） boto3 リージョン：us-west-2 4. boto3でCloudWatch Logsをフィルタリングする 4.1 boto3とは boto3は、PythonからAWSリソースを操作するための公式SDK（Software Development Kit）です。 ※ Lambdaを利用している場合、boto3はデフォルトで利用することができます。 今回はCloudWatch Logsのfilter_log_events APIを使い、特定のパターンにマッチするログを抽出します。 filter_log_eventsを利用して、Pythonでログの解析、分析に役立てることができます。 4.2 サンプルソースコード 以下のプログラムは、CloudWatch Logs に出力された過去1時間分のログから “START_DATE” と “SUCCESS” を含む JSON 形式のログメッセージを抽出し、START_DATE の中で最新の日付を1件だけ取得・表示する Lambda 関数です。 import boto3 import time from datetime import datetime, timedelta import json import logging logger = logging.getLogger("my_lambda_logger") logger.setLevel(logging.INFO) if not logger.handlers: handler = logging.StreamHandler() formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) client = boto3.client('logs', region_name='us-west-2') log_group_name = '/aws/lambda/log-group-name' def lambda_handler(event, context): end_time = int(time.time() * 1000) start_time = int((datetime.utcnow() - timedelta(minutes=60)).timestamp() * 1000) start_dates = [] next_token = None while True: kwargs = { "logGroupName": log_group_name, "startTime": start_time, "endTime": end_time, "filterPattern": '?START_DATE ?SUCCESS' } if next_token: kwargs["nextToken"] = next_token response = client.filter_log_events(**kwargs) for e in response.get("events", []): try: message = json.loads(e["message"]) if "START_DATE" in message: start_dates.append(message["START_DATE"]) except Exception as ex: logger.warning(f"Failed to parse message: {e['message']} -- {ex}") next_token = response.get("nextToken") if not next_token: break logger.info(f"Collected START_DATEs: {start_dates}") if start_dates: dt_dates = [datetime.strptime(d, "%Y-%m-%d") for d in start_dates] dt_dates.sort(reverse=True) latest_one = dt_dates[:1] latest_one_str = [d.strftime("%Y-%m-%d") for d in latest_one] else: latest_one_str = [] 4.3 filter_log_eventsの解説 filter_log_events は、指定したロググループの中から特定の条件にマッチするログイベントを抽出するための boto3 の API です。大量のログデータの中から、必要な情報を取得するのに適しています。

1. はじめに Lambdaから別AWSアカウントのリソースにアクセスする要件がたまにあります。 別AWSリソースにアクセスすることをクロスアカウントアクセスといいます。 ただ、私はクロスアカウントアクセスという単語を耳にしたことがありますが、自分自身で設定をおこなったことがなかったので、一度設定をしてみました。 ここでは、LambdaからクロスアカウントのS3にアクセスするための設定をまとめます。 2. 前提 AWSアカウントを２つ用意していること。 LambdaがあるアカウントをAアカウント、S3があるアカウントをBアカウントとする。 3. 関連知識 クロスアカウントアクセスに必要な知識を解説します。 3.1 AWS Security Token Service (AWS STS) とは AWS Security Token Service (以下、AWS STS) とは、AWSリソースへのアクセスコントロールできるサービスで一時的な認証情報発行します。 AWS STSは、クロスアカウントのアクセスや他要素認証などに利用されます。この一時的なクレデンシャルは数分~最大12時間までの有効期限を設定できます。 3.2 Assume Roleとは **Assume Role（アシュームロール）**とは、一時的に別の権限を持ったロールを使えるようにする仕組みです。 AWSでは、通常IAMユーザーやLambdaなどが操作を行いますが、Assume Roleを使うと、 一時的な認証情報を作成して、そのロールを引き受けて、そのロールが持っている権限でAWSサービスにアクセスできます。 この一時的な認証情報は**AWS STS（Security Token Service）**が発行します。 4. AWS構成図 5. クロスアカウントアクセスするための設定 5.1 Aアカウント側のLambdaの実行ロール Lambda実行ロール作成します。 クロスアカウントアクセスするために重要なのが、sts.AssumeRoleを付与しやポリシーを作成することです。 Resourceには、クロスアカウント先のロールを取得します。 ここでは、アカウントBに作成するS3にアクセスするための、ロールを作成し、そのロールを引き受けられるように設定します。 AWSTemplateFormatVersion: '2010-09-09' Resources: LambdaExecutionRole: Type: AWS::IAM::Role Properties: RoleName: 'lambda-execution-role' AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - sts:AssumeRole Path: / Policies: - PolicyName: 'allow-cloud-watchlogs-access' PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - logs:CreateLogStream - logs:PutLogEvents - logs:DescribeLogStreams - logs:CreateLogGroup Resource: '*' - PolicyName: 'allow-access-s3-bucket' PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: sts:AssumeRole Resource: arn:aws:iam::{アカウントB}:role/CrossAccountLambdaAccessRole 5.2 Lambdaのアプリケーションコード STSでアカウントBのCrossAccountLambdaAccessRoleへの一時的な認証情報を取得し、アカウントAのLambdaがCrossAccountLambdaAccessRoleを引き受けます。

1. はじめに Application Load Balancerを構築を簡単に構築したので、構築手順と構成をまとめておきます。 2. CloudFormationテンプレート 2.1. VPCの作成 VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 192.168.0.0/20 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: 'vpc' 2.2. インターネットゲートウェイの作成 VPCにアタッチするインターネットゲートウェイを作成する InternetGateway: Type: AWS::EC2::InternetGateway Properties: Tags: - Key: Name Value: 'internet-gateway' AttachGateway: Type: AWS::EC2::VPCGatewayAttachment Properties: VpcId: !Ref VPC InternetGatewayId: !Ref InternetGateway 2.3. ルートテーブルの作成 パブリックサブネット用のルートテーブルをサブネットごとに作成する。 Az1PublicRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Az1PublicRoute: Type: AWS::EC2::Route DependsOn: GymManagementAttachGateway Properties: RouteTableId: !Ref Az1PublicRouteTable DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway Az1PublicSubnetRouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref EcsPublicSubnetAZ1 RouteTableId: !Ref Az1PublicRouteTable Az2PublicRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Az2PublicRoute: Type: AWS::EC2::Route DependsOn: GymManagementAttachGateway Properties: RouteTableId: !Ref Az2PublicRouteTable DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway 2.4. パブリックサブネットの作成 パブリックサブネットは、ALBの使用上、複数作成する必要あります。

1. はじめに 今回は、AWS Systems Manager の Session Manager を利用して、踏み台サーバー（Bastion Host）の代替手段を構築する方法を紹介します。 Session Manager を活用することで、従来の踏み台サーバーに比べてセキュリティや運用性が向上します。たとえば、SSH鍵の管理や開放ポートの運用から解放され、よりシンプルかつセキュアなアクセス環境を実現できます。 2. Session Managerとは AWS Session Managerは、AWS System Manager の機能の１つで、EC2インスタンスやオンプレミスサーバーに対して、安全にサーバーにアクセス可能にするサービスです。 2.1 Session Managerを利用するメリット ポートを開く必要がない・鍵管理不要 従来の踏み台サーバーには、sshの22番ポートを開く必要がありますが、AWS Session Managerを利用すれば、ポートを開く必要がなくセキュアに踏み台サーバーを運用することが可能になります。また、sshキーの管理が不要になります。 ポート転送 EC2インスタンスで動いているアプリケーションに対して、ローカルPCのローカルポートからアクセスできるようになります。また、ローカルPCからEC2インスタンスを踏み台にして、プライベートサブネットに配置されているRDSなどのデータベースにアクセス可能になります。 3. 実際の構成図 4. AWS Session Managerで踏み台サーバー構築する 4.1. VPCを作成する VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 192.168.0.0/20 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: 'vpc' 4.2. プライベートサブネットを作成する PrivateSubnetAZ1: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC AvailabilityZone: !Select [0, !GetAZs ''] CidrBlock: 192.168.0.0/24 MapPublicIpOnLaunch: false Tags: - Key: Name Value: 'private-subnet-az1' PrivateSubnetAZ2: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC AvailabilityZone: !Select [2, !GetAZs ''] CidrBlock: 192.168.1.0/24 MapPublicIpOnLaunch: false Tags: - Key: Name Value: 'private-subnet-az2' 4.3. データベースを構築する RdsDbCluster: Type: 'AWS::RDS::DBCluster' Properties: AvailabilityZones: - !Select [0, !GetAZs ''] - !Select [2, !GetAZs ''] BackupRetentionPeriod: 7 DBClusterIdentifier: !Sub '${ProjectName}-database' DBClusterParameterGroupName: !Sub '${ProjectName}-aurora-parameter-group' DatabaseName: gym_db DBSubnetGroupName: !Sub '${ProjectName}-aurora-subnet-group' Engine: 'aurora-mysql' Port: 3306 MasterUsername: 'admin_user' MasterUserPassword: "DBのパスワード" PreferredBackupWindow: '17:20-17:50' PreferredMaintenanceWindow: 'sun:15:00-sun:16:00' VpcSecurityGroupIds: - !ImportValue SgDbSecurityGroup StorageEncrypted: true EnableIAMDatabaseAuthentication: false # 通常のAuroraかAurora Serverlessか選択可能 EngineMode: 'provisioned' DeletionProtection: false EnableHttpEndpoint: false AuroraSubnetGroup: Type: AWS::RDS::DBSubnetGroup Properties: DBSubnetGroupDescription: 'subnet group' DBSubnetGroupName: 'aurora-subnet-group' SubnetIds: - !Ref PrivateSubnetAZ1 - !Ref PrivateSubnetAZ2 AuroraClusterParameterGroup: Type: AWS::RDS::DBClusterParameterGroup Properties: Description: Aurora MySQL 8.0 cluster parameter group DBClusterParameterGroupName: 'aurora-parameter-group' Family: aurora-mysql8.0 Parameters: time_zone: Asia/Tokyo character_set_database: utf8mb4 Tags: - Key: Name Value: 'aurora-cluster-param-group' DbInstance: Type: AWS::RDS::DBInstance Properties: AllowMajorVersionUpgrade: false # DBインスタンスの変更を即時反映させるかメンテナンスウィンドウ時に反映させるか ApplyImmediately: true AutoMinorVersionUpgrade: false # 自動バックアップの保持期間 BackupRetentionPeriod: 0 DBClusterIdentifier: !Ref RdsDbCluster DBInstanceClass: db.t3.medium DBInstanceIdentifier: 'db-instance' DBSubnetGroupName: 'aurora-subnet-group' DeleteAutomatedBackups: true Engine: aurora-mysql PreferredMaintenanceWindow: 'sun:17:00-sun:17:30' PubliclyAccessible: false 4.4. EC2を作成する BastionInstance: Type: AWS::EC2::Instance Properties: AvailabilityZone: !Select [0, !GetAZs ''] DisableApiTermination: false IamInstanceProfile: !Ref BastionInstanceProfile ImageId: ami-07b0c09aab6e66ee9 InstanceType: t2.small Monitoring: true SecurityGroupIds: - !Ref BastionSecurityGroup SubnetId: !Ref PrivateSubnetAZ1 Tags: - Key: Name Value: 'bastion-instance' BastionInstanceProfile: Type: "AWS::IAM::InstanceProfile" Properties: Path: "/" Roles: - !Ref SessionManagerRole 4.5. VPCエンドポイント SsmEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub 'com.amazonaws.${AWS::Region}.ssm' VpcId: !Ref VPC VpcEndpointType: Interface SubnetIds: - !Ref PrivateSubnetAZ1 - !Ref PrivateSubnetAZ2 PrivateDnsEnabled: true SecurityGroupIds: - !Ref SsmVpcEndpointSg Tags: - Key: Name Value: 'logs-vpc-endpoint' SsmMeessagesEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub 'com.amazonaws.${AWS::Region}.ssmmessages' VpcId: !Ref VPC VpcEndpointType: Interface SubnetIds: - !Ref PrivateSubnetAZ1 - !Ref PrivateSubnetAZ2 PrivateDnsEnabled: true SecurityGroupIds: - !Ref SsmVpcEndpointSg Tags: - Key: Name Value: 'logs-vpc-endpoint' 4.6. IAM Resources: SessionManagerRole: Type: 'AWS::IAM::Role' Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - 'sts:AssumeRole' Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore Outputs: SessionManagerRole: Value: !Ref SessionManagerRole Export: Name: SessionManagerRole 4.8. セキュリティグループ BastionSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: "Security group for Bastion host using Session Manager" VpcId: !Ref VPC SecurityGroupEgress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: 0.0.0.0/0 - IpProtocol: tcp FromPort: 3306 ToPort: 3306 CidrIp: 0.0.0.0/0 SsmVpcEndpointSg: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: "Allow SSM traffic" VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: 0.0.0.0/0 4.9. SSMプラグインをローカルPCにインストールする 以下のページを参考にSSMプラグインをPCにインストールする。

1. はじめに 今回は、ECS FargateをCloudformationで構築する方法を説明していきます。 ECSについて、興味があったのですが、学習できていませんでした。最近時間ができたので、ECS Fargateを構築したので、構築手順をまとめました。 2. ECSとは ECS（Amazon Elastic Container）とは、コンテナ化されたアプリケーションをデプロイ、管理、スケーリングするためのコンテナ管理サービスです。 2.1 ECSを構成する構成要素 2.1.1 クラスター クラスターは、サービスとタスクをグループ化する要素です。 2.1.2 サービス サービスは、コンテナ化されたアプリケーションの実行とスケーリングを容易にする、フルマネージド型のコンテナオーケストレーションサービスです。 サービスで設定できる項目 クラスター サービスやタスクを実行するクラスターを設定する タスク定義 実行するコンテナのリソースや環境変数など デプロイメント ローリングアップデートやCode ターゲット数 サービスが維持するタスク数を設定。 ロードバランサ タスクのトラフィックを分散する ヘルスチェック タスクの健全性を監視する AutoScaling タスク数を自動で増減。CPU使用率やメモリの使用率に基づいて増減する。 ローンチタイプ ECS2かFargateを設定する 2.1.3 タスク タスクは、１つ以上のコンテナをまとめて実行する単位です。ECSでは、アプリケーションをデプロイ・実行する最小単位です。 タスクの実行内容は、タスク定義に基づきます。 タスクで設定できる項目 使用するDockerイメージ コンテナごとのCPU/メモリ割当て ポートマッピング 環境変数 ログ設定 4. 構成図 5. 構築手順 プライベートサブネットにECSを作成する方法です。 5.1 VPC VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 192.168.0.0/20 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: 'vpc' EcsPrivateSubnetAZ: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC AvailabilityZone: !Select [0, !GetAZs ''] CidrBlock: 192.168.0.0/24 MapPublicIpOnLaunch: false Tags: - Key: Name Value: 'ecs-private-subnet' SgEcsSecurityGroup: Type: AWS::EC2::SecurityGroup DependsOn: AlbSecurityGroup Properties: GroupDescription: 'sg-ecs-security-group' GroupName: 'sg-ecs-security-group' SecurityGroupEgress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: 0.0.0.0/0 Tags: - Key: Name Value: 'sg-ecs' VpcId: !Ref VPC EcrVpcEndpointSg: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Allow HTTPS for VPC Endpoints VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: 0.0.0.0/0 CloudWatchVpcEndpointSg: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Allow HTTPS for VPC Endpoints VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: 0.0.0.0/0 SourceSecurityGroupId: !Ref SgEcsSecurityGroup #---------------------------------------------# # VPC Endpoint # #---------------------------------------------# # プライベートサブネットのECSからECRからイメージ取得するために必要 ECRApiEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub 'com.amazonaws.${AWS::Region}.ecr.api' VpcId: !Ref VPC VpcEndpointType: Interface SubnetIds: - !Ref EcsPrivateSubnetAZ PrivateDnsEnabled: true SecurityGroupIds: - !Ref EcrVpcEndpointSg Tags: - Key: Name Value: 'ecr-api-endpoint' # プライベートサブネットのECSからECRからイメージ取得するために必要 ECRDockerEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub 'com.amazonaws.${AWS::Region}.ecr.dkr' VpcId: !Ref VPC VpcEndpointType: Interface SubnetIds: - !Ref EcsPrivateSubnetAZ PrivateDnsEnabled: true SecurityGroupIds: - !Ref EcrVpcEndpointSg Tags: - Key: Name Value: 'dcr-endpoint' # プライベートサブネットのECSからCloudwatchにログ出力するために必要 CloudWatchEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub 'com.amazonaws.${AWS::Region}.logs' VpcId: !Ref VPC VpcEndpointType: Interface SubnetIds: - !Ref EcsPrivateSubnetAZ PrivateDnsEnabled: true SecurityGroupIds: - !Ref CloudWatchVpcEndpointSg Tags: - Key: Name Value: 'logs-vpc-endpoint' 5.2 クラスター作成 ECSCluster: Type: AWS::ECS::Cluster Properties: ClusterName: cluster CapacityProviders: - FARGATE ClusterSettings: - Name: containerInsights Value: enabled 5.3 サービス作成 ECSService: Type: 'AWS::ECS::Service' Properties: ServiceName: ecs-service Cluster: !Ref ECSCluster TaskDefinition: !Ref FargateTaskDefinition DesiredCount: 1 LaunchType: FARGATE DeploymentController: Type: CODE_DEPLOY NetworkConfiguration: AwsvpcConfiguration: AssignPublicIp: DISABLED SecurityGroups: - !Ref SgEcsSecurityGroup Subnets: - !Ref EcsPrivateSubnetAZ LoadBalancers: - ContainerName: dynamo ContainerPort: 8080 TargetGroupArn: !Ref TargetGroup 5.4 タスク定義作成 FargateTaskDefinition: Type: AWS::ECS::TaskDefinition Properties: ContainerDefinitions: # ECRのリポジトリを指定する - Name: test Image: !Sub '${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/xxxxxxx' Cpu: 0 PortMappings: - Name: test ContainerPort: 8080 HostPort: 8080 Protocol: tcp AppProtocol: http Essential: true LogConfiguration: LogDriver: awslogs Options: awslogs-group: /ecs/tests awslogs-region: !Sub ${AWS::Region} awslogs-stream-prefix: ecs Family: ecs-family-name ExecutionRoleArn: !Sub 'arn:aws:iam::${AWS::AccountId}:role/ecs-task-execution-role' NetworkMode: awsvpc Cpu: 1024 Memory: 3072 5.5 ECSロール作成 EcsTaskExecutionRole: Type: AWS::IAM::Role Properties: RoleName: 'ecs-task-execution-role' AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: ecs-tasks.amazonaws.com Action: sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy Policies: - PolicyName: AllowCloudWatchLogsAccess PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - logs:CreateLogStream - logs:PutLogEvents - logs:DescribeLogStreams - logs:CreateLogGroup Resource: '*' 6. まとめ ECSをCloudFormationで構築してみました。以前、AWSマネジメントコンソールで作成したことがありました。