コンテナ・サーバレスがもたらす世界と開発者がAWS上で取り組むべきこと / Containers and Serverless Technology for Developers
はじめに お久しぶりです。2021年末以来の投稿になります。 先日、とある金融情報サービス系の会社に所属する知り合いの方から、「AWS × アプリケーション開発者 × コンテナ に関連したトピックで社内向け勉強会にて講演してくれないか?」とご相談をいただき、「コンテナ・サーバレスがもたらす世界と開発者がAWS上で取り組むべきこと」というタイトルでお話させていただきました。 その会社様は、これからまさにシステムをAWS上のコンテナ技術で刷新していく取り組みを推進されており、アプリケーション開発者に刺激を与えたり知見を獲得する上でも、ぜひお願いしたいとのことで、僭越ながらお話させていただきました。 ただ、今回の登壇内容は、勉強会の参加者のみならずその他の幅広いエンジニアの方々にも役立つのかな、との想いもありました。 そこで、先方に許可をいただき、多少デフォルメして資料を公開することにしました。
ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程 RDS の新しい高可用性オプションである Multi-AZ DB Cluster が一般提供となったためレポートします。Multi-AZ DB Cluster は従来の高可用性オプションの Multi-AZ DB Instance と比較して書き込み性能の向上とフェイルオーバーの高速化が期待できるオプションです。 New Amazon RDS for MySQL & PostgreSQL Multi-AZ Deployment Option: Improved Write Performance & Faster Failover なおプレビュー時の紹介はこちらのエントリーです。 Multi-AZ DB Cluster RDS には従来高可用性のためのオプションとして Multi-AZ Instance がありました。従来の Mu
DNSレコードをTerraformで管理していたドメインがありました。(Route53) IaC(Infrastructure as Code)は当然のようになっていてこのドメインもTerraformで管理していました。 しかし運用していくにつれ今の構成に不満点も出てきてて, なんかいい感じに出来ないかな~と思っていました。 Terraformで管理しているけど, 管理するレコード数が多くなるにつれ terraform plan や terraform apply の実行に時間がかかるようになってきた CircleCI使って自動化してるからデプロイ待たないで違うことしてればいいんだけど, そこまで何か違うことできるほど時間かかるわけじゃないから結局待っちゃってストレス そもそもコード化してるけど, このドメインに関していうとプルリク作ってレビューしてapply!みたいな慎重な手順は踏む必要
Containers Deep Dive on AWS App Runner VPC Networking AWS App Runner, introduced in 2021, is a fully managed service for running web applications and API servers. App Runner greatly simplifies the experience to build and run secure web server applications with little to no infrastructure in your account. You provide the source code or a container image, and App Runner will build and deploy your ap
Amazon Web Services (以下AWS)の利用開始時にやるべき設定作業を解説します。AWSの利用開始とは、AWSアカウントの開設を意味しますが、より安全に利用するため、AWSアカウント開設直後にやるべき設定がいくつかあります。この連載ではその設定内容を説明します。 AWS Organizationsを使用することで、複数のアカウントに自動的にこういった初期設定を行うことも可能ですが、この連載では新規で1アカウントを作成した場合を前提とします。複数アカウントの場合も、基本的な考え方は同じになります。 設定作業は全19個あり、作業内容の難しさや必要性に応じて以下3つに分類しています。 少なくともMUSTの作業については実施するようにしましょう。 MUST :アカウント開設後に必ず実施すべき作業 SHOULD :設定内容の検討または利用方法を決定のうえ、可能な限り実施すべき作業 B
tfaction という、 GitHub Actions で良い感じの Terraform Workflow を構築するための Action を開発しています。 今回は tfaction の導入ガイドのようなものを書こうかと思います。 AWS Account が必要です。 執筆時点で tfaction の最新バージョンは v0.4.5 です。 2022-02-07 追記 Getting Started を作成しました。 README に従っていけば tfaction の workflow を動かして terraform を実行するのを体験できると思います。 IAM OpenID Connect provider の作成 IAM OpenID Connect provider を作成します。 data "tls_certificate" "github" { url = "https://t
今更ですが、Serverless FrameworkでDynamoDBのローカル開発環境を構築するために、DynamoDB Localを導入したので、その記録です。 はじめに DynamoDB Local 自体は、そもそも aws 公式のツールです。 DynamoDB をローカル環境で利用できるように用意されています。 JRE 上で動作するので、Java6以上の実行環境が必要です。1 それを Serverless Framework で使うための Serverless DynamoDB Local というプラグインがあります。 プラグインを利用しなくても DynamoDB Localを利用することはできますが、serverless frameworkの設定と一緒にかけたり、seedなどのオプションがあり便利です。 Serverless Framework で DynamoDB Local
KINTO Technologies Advent Calendar 2021 - Qiita の1日目の記事です。 2021年12月現在、AWS SESでバウンスを処理するためには、どんな作業が必要/不要なのか。 AWSのドキュメントやサポートに確認した内容に基づいて説明します。 TL;DR 基本的に バウンス処理を自前で構築する必要はありません。 特に、バウンスレートを下げることだけが目的の場合は、 Account-level Suppression List が有効かどうか確認するだけでOKです。 AWS SNSからバウンス情報を取得して処理したり、自前のRDB/NoSQLを用意してメールアドレスのリストを保存することは不要です。 最新情報に基づいて設計を見直し、車輪の再発明はやめましょう。 この記事を読むために必要な前提知識 メールのバウンスとはなにか メールを送るときは、バウンス
Front-End Web & Mobile Simple serverless WebSocket real-time API with AWS AppSync (little or no GraphQL experience required) June 27, 2024: This blog post covers Amplify Gen 1. For new Amplify apps, we recommend using Amplify Gen 2. You can learn more about Gen 2 in our launch blog post. AWS AppSync simplifies application development by letting applications securely access, manipulate, and receive
For questions and answers about Amazon AWS Japan and the changes you are experiencing, please read through our FAQs below. 1. アマゾン ウェブ サービス ジャパン合同会社とは何ですか? 2022 年 2 月 1 日より、アマゾン ウェブ サービス ジャパン合同会社(AWS Japan) が、Amazon Web Services, Inc. (AWS Inc.) に代わり、日本国内の全てのアカウントに対する新しい AWS クラウドサービスの契約当事者となります。したがって、日本国内のすべてのアカウントは AWS Inc. ではなく、AWS Japan からクラウドサービスを購入することになります。日本国内の請求書払いのアカウントは、2021 年 11 月 1 日に、
tl; dr aws-sso-util を使うとコマンド一発で ~/.aws/config が生成できたりして便利なので使うべし。 AWS SSO とは 皆さん、AWS Single Sign-On (AWS SSO) というサービスを利用されていますか。 AWS SSO は 公式ページ によると下記のような記載がありますが、もっぱら前者の複数の AWS アカウントのアクセスに利用している方が多いでしょう。 複数の AWS アカウントとビジネスアプリケーションへのアクセスの一元的な管理を容易にし、割り当てられたアカウントとアプリケーションのすべてに対する 1 か所からのシングルサインオンアクセスをユーザーに提供できるようにする AWS のサービスです。 また、AWS CLI v2 からは ~/.aws/config に下記のような設定することで、CLI 作業でも AWS SSO による認証
tl;dr; 前置き モチベーション テンプレートリポジトリについて 頑張った点:Terraformを実行するための初期設定をCloud FormationやDeployment Managerで行うようにした tl;dr; github.com github.com 前置き 9月くらいにGitHub ActionsでOpenID Connector(以下OIDC)を用いた認証を利用することができるようになりました。 dev.classmethod.jp cloud.google.com CI上でAWSやGCPのAPIを利用する場合は通常IAM UserのAWS_ACCESS_KEY_IDやAWS_SECRET_ACCESS_KEY(AWSの場合)やサービスアカウントのキーファイル(GCPの場合)をリポジトリのSecretsに設定することになりますが、OIDCによりこれらの機微情報の生成自
はじめに サーバーレスに触れて数年が立ちました。 そろそろ人にある程度説明ができるレベルの知識と経験が備わったような気もするので、年末なのでまとめてみました。 サーバーレス気になっているけれども、という人に少しでもためになればいいなーと思います。 サーバーレス基礎 皆さん、サーバーレス設計という話を聞いたことはあるでしょうか? まずサーバーレスについて説明しますが、世の中にはたくさん解説記事があるのでそちらも適宜参照ください。 サーバーレスでも実際にはサーバーは存在する サーバーレスとは開発者がサーバーのことを意識しなくてもよい、ということ Function as a serviceに代表されるように、あるプログラムの実行環境を提供するが、プログラムの動作環境は開発者は意識する必要はない、というイメージ 恐らく、AWS Lambdaが一番理解しやすいと思います。 AWS Lambdaではプ
「AWS Amplify Advent Calendar 2021」 19日目の記事となります 記事の概要 2021/11/23に、Amplify GraphQL Transformer v2(以下v2と表記)が発表されました[1]。以前のGraphQL Transformer v1(以下v1と表記)から大幅なアップデートがいくつも入っており、Breaking Changeも少なからずあります。この記事では GraphQL Transformer v2の主な変更点 GraphQL Transformer v1からのMigration時の注意事項 の2点についてまとめてみました! 想定読者 Amplify CLIでGraphQL APIを利用している人 これから利用を検討しているが、既存のブログ記事などがv1で記述されており差分が知りたい人 話さないこと(及び参考資料) Amplify 自体
はじめに 皆さん、こちらの記事はご覧になりましたか?私も記事が出た当日に見てはいたのですが、同僚にも「めっちゃ速いよ!」と言われたのですが、スルーしてました。 でも、百聞は一見に如かずなんですよね。 re:Invent 2021のLeadership SessionであるAccelerating your serverless journey with AWS LambdaでSAM AccelerateとStep Functionsのデモが披露されていたのですが、それを見て、 「あ、すぐ使いたい」と思って、使ってみたのです。 ということで、今日は、こちらのブログで詳しく紹介されていますが、自分で試したことをまとめたいと思います なお、執筆時点(2021/12/06)で当機能はPublic Previewです。 サマリ SAM AccelerateはLambda関数のコードの変更時に迅速なデ
インフラ担当の柴田です。 この記事は、Japan APN Ambassadors Advent Calendar 2021の5日目のエントリです。 さて、今週はre:invent 2021が開催されていましたが、皆さんは参加されましたか。 私は、現地で参加したかったのですが時節柄難しく、オンラインで参加していました。 re:inventの開催時期になると、AWSでは新しいサービスやサービスのアップデートが大量に出てきます。私は楽しい反面、多すぎてもう何も分からないという感じになります。 そこで、何か1つ気になったサービスをまとめてみようと思い、今回はWell-Architected Frameworkに新たに追加されたサステナビリティの柱についてまとめてみました。 Well-Architected Frameworkと5本の柱 AWS Well-Architected Frameworkは
Let's dive into Filtering event sources for AWS Lambda functionsAWSlambdasqsKinesis はじめに 今まで、 Kinesis Data Streams + AWS Lambda Amazon SQS+ AWS Lambdaのバックエンド、 Amazon SNS + Amazon SQS + AWS Lambda といったアーキテクチャをお客様のアプリケーションの中に組み込んできた中で、よくやっていたのが、Lambda Functions内で処理すべきデータか判断する、あるいは、判断を後に任せてとりあえず全部処理したり、不要なデータをスキップしたりしていました。これは、従量課金制のLambdaに対して、本来、処理対象ではないはずの不要なデータを投入し処理し、AWSサービス利用料、処理時間等に多少なりとも影響があった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く