Category: AWS CloudFormation

今日(2018/9/6)、AWS CloudFormation の強力な新機能である マクロ (Macros) を紹介できることを嬉しく思います。開発者は CloudFormation マクロ を使って CloudFormation テンプレートのネイティブ記法を拡張できるようになりました。これは AWS Lambda による変換処理を呼び出すことで実現されています。みなさんご存知の Serverless Application Model も同様のテクノロジで実現されていますが、今回の機能は、変換処理を、あなたのアカウントの、あなたが作成した Lambdaファンクションを使用して、完全にカスタマイズすることができます。（AWS初心者の方へ）CloudFormation はインフラストラクチャを （YAML や JSON の） コードでモデリングし定義するために重要なツールです。CloudFormation は AWS 全体とそのサービスが依存するコアな構成要素です。

皆さんに AWS Cloud Development Kit (CDK) の開発者プレビューをご案内できることを嬉しく思います。現在の対応言語は TypeScript、 JavaScript そして Java で、.NET と Python を近々ご案内予定です。AWS CDK はソフトウェア開発のフレームワークであり、クラウドのインフラストラクチャをコードで定義して CloudFormation でプロビジョニングできます。CDK は AWS のサービスと統合され、高レベルかつオブジェクト指向の抽象概念を使ってAWS リソースを定義できます。CDK によってモダンなプログラミング言語を使ってAWS インフラストラクチャを見通しよく効率よく定義できるため、アプリケーションからインフラストラクチャまで一貫した開発体験 (development experience) が得られます。

Chef サーバは、テスト済みの信頼できるクックブックを対象ノードの run list に簡単に追加できるハブであるべきです。しかしながら、クックブックのテストを実行し、Chef サーバへ配信する作業は手間のかかるタスクです。このプロセスをシンプルかつ迅速にするために、私たちは AWS の技術を活用してテストの実行と Chef サーバへのクックブックの配信を統合したパイプラインを構築しました。これによりクックブック開発の定型的ながらも重要な部分を自動化できます。

最新の Amazon Linux AMI を取得するシンプルな方法が必要ですか？ AWS Systems Manager Parameter Store はすでに最新の Windows AMI を取得できます。今回、最新の Linux AMI も取得できるよう機能が拡張されました。各 Amazon Linux AMI は、固有の 公開パラメータストア名前空間 を持ちます。AMIの名前空間をクエリすることで、指定したリージョンのイメージIDを得ることができます。

大規模なデータおよびデータレイクのワークロード用にサーバーレスETL（抽出、変換およびロード）アプリケーションを開発するためにAWS Glueはますます普及しています。 ETLアプリケーションをクラウドベースのサーバーレスETLアーキテクチャに変換する組織は、ソースコードからビルド、デプロイ、プロダクトデリバリまで、シームレスでエンドツーエンドの継続的なインテグレーションおよび継続的なデリバリ（CI / CD）パイプラインが必要です。優れたCI / CDパイプラインを持つことで、組織はプロダクションリリース前にバグを発見し、より頻繁にアップデートを提供することができます。また、開発者が高品質のコードを書いたり、ETLのジョブリリース管理プロセスを自動化したり、リスクを軽減したりするのに役立ちます。 AWS Glueは、フルマネージドのデータカタログとETLのサービスです。これは、データの発見、変換、およびジョブスケジューリングなどの困難で時間のかかる作業を簡素化し自動化します。 AWS Glueは、データソースをクロールし、CSV、Apache Parquet、JSONなどの一般的なデータフォーマットとデータタイプ用に事前に作成された分類子を使用してデータカタログを構築します。 AWS Glueを使用してETLアプリケーションを開発する場合、CI / CDの次のような課題に直面する場合があります。 ユニットテストによる繰り返しの開発 継続的なインテグレーションとビルド ETLパイプラインをテスト環境にプッシュする ETLパイプラインをプロダクション環境にプッシュする 実データを使用したETLアプリケーションのテスト（live test） データの調査と検証 この記事では、AWS Developer Tools（AWS CodePipeline、AWS CodeCommit、AWS CodeBuildなど）とAWS CloudFormationがサポートするサーバーレスAWS Glue ETLアプリケーションのCI / CDパイプラインを実装するソリューションを紹介します。 ソリューションの概要 次の図は、ワークフローのパイプラインを示しています。 このソリューションでは、AWS CodePipelineを使用して、ETLアプリケーションのソースコードのテストおよびステージへのデプロイを制御および自動化することができます。 このソリューションは、以下のステージを含むパイプラインで構成されています。 1.）Source Control：このステージでは、デプロイするETLジョブのAWS Glue ETLジョブソースコードとAWS CloudFormationテンプレートファイルの両方がバージョン管理にコミットされます。 バージョン管理にAWS CodeCommitを使用することにしました。 ETLジョブソースコードとAWS CloudFormationテンプレートを取得するには、gluedemoetl.zipファイルをダウンロードします。 このソリューションは、以前の記事、AWS Glue と Amazon S3 を使用してデータレイクの基礎を構築するに基づいて開発されました。 2.）LiveTest：このステージでは、AWS […]

AWS Cloud9 は 2017年11月の AWS re:Invent で発表されました。Cloud9 はブラウザベースの IDE で、サーバレスアプリケーションも含め、数多くのクラウド上の開発ユースケースに適しています。AWS CloudFormation を使うことで AWS CodeCommit と連携した AWS Cloud9 の開発環境を迅速に構築することができます。このブログでは、CloudFormation を使った Cloud9 環境の構築手順を説明します。さらに Cloud9 の環境で Python と Boto3 のコードを書き、 Troposphere を使って CloudFormation の YAML テンプレートを生成する方法についても説明します。

多くの画像に対してリサイズを行ったり、新しいデザインレイアウトにウォーターマークを付与したり、ブラウザのサポートのためにフォーマットの最適化を行ったことはありませんか？ 画像毎に事前処理を行う必要なく、必要に応じてその場ですぐに画像を自動生成できないかとおもったことはありませんか？ Lambda@Edge はそれらを可能にし、ユーザーの利便性を向上させ、帯域使用量を削減します。

Carmen PuccioとMandus Mombergによる記事。 CarmenとMandusは、AWSパートナーソリューションアーキテクトで、移行に注力しています。 オンプレミス環境からクラウドへのソフトウェアやサービスの移行は、独自の考慮事項と要件を伴うことは明らかです。移行結果に自信を持たせるには、容易に拡張できる移行戦略が必要です。つまり、ワークフローの大部分を自動化する必要があります。なぜクラウド内の自動化が重要であるのかに関する文書が不足しているわけではありません。この記事では、AWSアドバンスト・テクノロジーパートナーであるCloudEndureを使用して自動化された移行を実行する方法を説明し、自動化されたテストを組み込むことに重点を置いて、アプリケーションが移行後に期待どおりに動作することを確信できます。 オンプレミスからAWSへのワークロードの移行には、慎重な計画と正確な実行が必要です。クラウドに移行するにはさまざまな戦略がありますが、移行を容易にするツールも数多くあります。すべての移行ツールは、ダウンタイムとアプリケーションワークロードの影響を最小限に抑え、AWSへの移行を容易にし、データ損失を最小限に抑える、という共通の目標を持っています。 ワークロードをクラウドにすばやく移動したい場合、通常リホスト方式（リフト＆シフト）に従います。リホスト実行時の課題の1つは、移行されたアプリケーションが期待どおりに実行されていることを手動で確認するのにかかる時間です。適切な移行を検証するための自動化および迅速なテストパイプラインを組み込んだ移行は、成功する可能性が高いだけでなく、反復可能なプロセスを活用し、手動検証時間を短縮することで効率を向上させます。 ソリューションの概要 このブログ記事で説明するソリューションでは、CloudEndureとAWS Database Migration Service（AWS DMS）を使用し、ソースAmazon VPCから目的のAmazon VPCへ、オンプレミスからAWSへの、Go Gitサービス（Gogs）の移行について説明します。このデモのために2つの異なるVPCを使用していますが、このブログポストで使用しているツールの自動化と組合せによって、オンプレミスからAWSへの移行を容易に実現することができます。CentOS 7が稼働するモックソース環境の設定では、AWS CloudFormationとAnsibleの組合せを選択しましたので、あなたのテスト用AWS環境でご確認することができます。 CloudEndureはアプリケーションサーバの移行を担当し、AWS DMSはEC2インスタンス上で実行されているMySQLサーバからGogs DBを、完全に管理されたAmazon RDSデータベースに再構築する役目を負います。このデモンストレーションのためDMSを活用し、RDSへのデータベースのレプリケート方法を示しました。もう1つの選択肢として、データベース移行において、CloudEndureによるEC2へのリホストを行うことができます。 CloudEndureは起動時に、移行後のインスタンスでカスタム後処理スクリプトを呼び出す機能があります。この機能を使用すると、カスタム構成を実行し、自動化された承認テストを実行して、移行されたサーバでアプリケーションが正常に動作していることを確認できます。 移行の信頼性のため、AWS Lambda、AWS SNS、AWS SQS、CloudEndureの後処理機能を活用して、一連のテストを実行するための自動テストパイプラインを構築しています。すべてのテストが正常に完了すると、ソース環境から構築されたイメージを使用して高可用性Gogs環境をデプロイするAWS CloudFormationテンプレートが自動的に起動されます。 次の図は、この記事で取り上げる移行プロセスを示しています。 プロセスの仕組みは次のとおりです。 Ansibleは、AWS Application Discovery Service、CloudEndureエージェント、およびGogsソースサーバの再設定およびテストに使用されるスクリプトをインストールします。 AWS DMSは、GogsソースDBサーバを宛先RDSインスタンスに移行します。 CloudEndureエージェントが実行されると、ブロックレベルのコピーが開始され、GogsソースサーバとAWSの初期同期が実行されます。 CloudEndureが初期同期を完了すると、Continuous Data Protection（CDP）エンジンは新しいデータのリアルタイム同期を開始し、サーバはAWSでのテスト準備完了としてマークされます。 CloudEndure.pyスクリプトはconfig.ymlファイルのhosttomigrate変数に基づいて移行を開始します。 （この変数は、CloudEndureダッシュボードにインスタンス名として表示されます）。 CloudEndure.pyスクリプトはCloudEndure APIを呼び出し、ソースインスタンスの最新のスナップショットからテストインスタンスを開始します。 CloudEndureは、最新のスナップショットから宛先に新しいインスタンスを起動し、CloudEndure.shポストプロビジョニングスクリプトを実行します。このスクリプトは次の処理を行います。 DMSが複製しているRDSインスタンスを指すようにGogsを再構成し、Gogsサービスを再起動します。 Gogsサービスが稼動しているかどうかを確認します。稼働している場合、CloudEndure.shポストプロビジョニングスクリプトはCloudEndure_PostProcessing.pyスクリプトを呼び出します。このスクリプトはCloudEndure Pass / Fail SNSトピックに成功通知を送信します。メッセージの例は次のようになります。 “Message”: “{“instanceId”: ” i-0bb669daff4b1eea1″,”Pass”: […]

AWS CloudFormation は、AWS を利用するお客様の Infrastructure as Code モデルの実現に役立ちます。環境やアプリケーションを手作業でセットアップする代わりに、テンプレートを構築しそれを使用することで必要な全てのリソース ― これら一連のリソースは CloudFormation スタックと呼ばれます ― を作成します。このモデルでは、手作業に起因する失敗が発生する可能性が排除され、効率性が増し、時間が経過しても一貫した設定が保証されます。 本日、CloudFormation がよりいっそう便利になる新機能についてご紹介したいと思います。この新機能は、複数の AWS アカウントおよび/または複数のリージョンを利用する状況において Infrastructure as Code を実践するときにお客様が直面する課題の解決に役立つように設計されています。 アカウント ― 以前お話したように、多くの組織で多数の AWS アカウントが使用されます。AWS アカウントを階層化し、組織単位、あるいはOU（詳しく知りたい場合は「AWS Organizations – 複数の AWS アカウントのポリシーベースの管理」をお読みください）へグルーピングするために AWS Organizations が利用されています。事業、アプリケーション、そしてデベロッパーに対して複数のアカウントが運用されます。またアプリケーション毎に、開発、テスティング、ステージング、そして本番のそれぞれに対して別々のアカウントが作成されることもあります。 リージョン ― 巨大な（かつ今なお成長し続ける）AWS のリージョンもまた大いに活用されています。2つかあるいはそれ以上のリージョンにまたがるグローバルアプリケーションが構築され、洗練されたマルチリージョン・ディザスタリカバリ・モデルが実装されています。また、S3、Aurora、PostgreSQL、そして MySQL のデータをリアルタイムにレプリケートし、国や地域の規制にしたがって機密データを保管および処理するための場所を選択します。 複数のアカウントやリージョンへのこのような展開は、ガバナンスと一貫性に関していくつかの新しい課題をともないます。新しく作成される各アカウントが社内の標準に従って設定されていることを確認したいと、お客様は言われます。とりわけ、IAM ユーザーと IAM ロール、VPC と VPC サブネット、セキュリティグループ、コンフィグルール、ロギング、そして AWS Lambda 関数を、信頼性があり一貫した方法でセットアップしたいと望まれます。 スタックセットのご紹介 これらの重要なご要望を解決するために、本日 CloudFormation […]

AWS CloudFormation は AWS をご利用されているお客様がコードとしてのインフラストラクチャモデルを実装するのに役立ちます。環境やアプリケーションのセットアップを手動で行う代わりに、同機能はテンプレートを構築して CloudFormation スタックと呼ばれる必要なリソースすべてを作成するために使うことができます。このモデルは手動によるエラーを排除し、効率性の向上や、設定における一貫性を長期に渡り保つことを可能にします。 そこで、今回はこれまで以上に CloudFormation を便利にする最新の機能強化についてご紹介します。この機能は、複数の AWS アカウントや AWS リージョンなどの状況で、コードとしてインフラストラクチャを使用する場合に直面するチャレンジに対応しやすくするように設計されています。手短にご説明します。 アカウント – 以前ご説明したように、多くの組織が複数の AWS アカウントを使用していますが、AWS Organizations でアカウント階層化し、組織単位 (OU) でグループにしています (詳細は「複数の AWS アカウントのポリシーベース管理 – AWS Organizations (AWS Organizations – Policy-Based Management for Multiple AWS Accounts)」をご覧ください)。AWS のお客様はビジネスユニット、アプリケーション、開発者に渡り複数のアカウントを使用しています。アプリケーションごとの開発、テスト、ステージング、実稼働環境にそれぞれ別のアカウントを作成するのが一般的になっています。 リージョン – また、AWS をご利用のお客様は多数の (現在も増加中) AWS リージョンを 大いに利用しています。2 つまたはそれ以上のリージョンに渡りグローバルアプリケーションを構築し、洗練されたマルチリージョンの災害対策モデルの実装、S3、Aurora、PostgreSQL、MySQL データをリアルタイムでレプリケートし、国内および地域に適用される規制に準拠する方法で機密データの保存先や処理を行う場所を選びます。 複数のアカウントやリージョンへの拡大は、ガバナンスや適合性に見合うための新たなチャレンジを伴っています。AWS のお客様は各アカウントが必ず内部基準に合うようにしたいと言っています。特に IAM ユーザーとロール、VPC、VPC サブネット、セキュリティグループ、設定ルール、ロギング、AWS Lambda […]