サーバーレスまたは AWS での Kubernetes

選択をサポートします

Amazon Web Services (AWS) では、お客様のビジネスニーズに合ったモダンアプリケーションを構築するための戦略を柔軟に選択できます。AWS 上でモダンアプリケーションを構築するための戦略を策定しようとしているお客様は、多くの場合、AWS Lambda とコンテナを使用した AWS 戦略モデルによるサーバーレス、または AWS での Kubernetes という 2 つの高レベルのアプローチのいずれかを採用します。

AWS は、お客様がワークロードに適したコンピューティングおよびサポートサービス (データベース、メッセージング、オーケストレーションなど) にアクセスできるように設計されています。AWS は、AWS Lambda などのイベント駆動型コンピューティングサービスや、AWS FargateAWS App Runner などのサーバーレスコンテナオプションを使用して、サーバーレスアプリケーションを作成する機能を提供します。 AWS は、Amazon Elastic Container Service (Amazon ECS) と、Amazon Elastic Kubernetes Service (Amazon EKS)、Red Hat OpenShift Service on AWS (ROSA)、Amazon Elastic Compute Cloud (Amazon EC2) 上のセルフマネージド Kubernetes などの Kubernetes オプションを使用してコンテナアプリケーションを構築する方法を提供します。

以降のコンテンツは、お客様の環境に最も適したアプローチを選択し、AWS でアプローチの実装を開始するのに役立ちます。

モダンアプリケーションの利点

モジュラーアーキテクチャパターンを使用して構築し、マネージドサービスの運用モデルを活用できます。

より環境的に持続可能で、高いスケーラビリティと回復力を備えたアプリケーションを構築できます。

イノベーションの加速、リスクの軽減、市場投入までの時間の短縮、総保有コスト (TCO) の削減を実現できます。

明確に定義された次のステップを実行して、本番ワークロードのクラウドでのデプロイを開始する準備を整えましょう。

ステップ 1: 基準を決定する

モダンアプリケーションはモジュラーアーキテクチャパターンを使用して構築されており、サーバーレス運用モデルを活用して、より持続可能で、高いスケーラビリティと回復力を備えたアプリケーションを構築できます。これらを使用すると、イノベーションの迅速化、リスクの軽減、市場投入までの時間の短縮、TCO の削減が可能になります。 新しいモダンアプリケーションを構築したり、既存のアプリケーションをモダナイズしたりする場合、アーキテクトやデベロッパーは多数のビルディングブロックを利用できますが、最重要要素の 1 つはコンピューティングサービスの選択です。AWS は、お客様が各自のワークロードに適したコンピューティングサービスにアクセスできるように設計されており、お客様がニーズを満たすために合理的だと判断したモダンアプリケーション開発戦略をサポートします。

実装すべきモダンアプリケーション開発戦略を決定する前に、ワークロードの規模に基づいて基準を決定する必要があります。

  • 組織は、運用上の負担を AWS に移すマネージドサービスで標準化することで運用コストを削減するために、クラウドを選択する場合があります。高い抽象度のおかげで、デベロッパーと運営者は、差別化につながらない手間のかかる作業ではなく、独自の付加価値を生み出すための活動に集中できます。

    AWS サーバーレスを使用した構築では、より高い抽象度のサービスを利用して、インフラストラクチャの維持にかかる運用上のオーバーヘッドを AWS に移行します。

    AWS は、Kubernetes 向けのマネージドサービスもいくつか提供しています。これらのサービスでは、組織が管理する必要のあるテクノロジーレイヤーが異なっています。AWS は、設定を迅速に行えるように、アドオンや EKS Blueprints などのアクセラレーターも提供しています。

  • 多くの AWS のお客様は、広くサポートされているオープンソーステクノロジーを使用して標準化しています。オープンソースを使用することで、組織は適切なスキルを見つけることができ、ロックインに関するリスクをある程度回避できます。オープンソースのエコシステムで選択を誤ると、抽象化や自社開発の統合にロックインされてしまう可能性があります。さらに、さまざまなオープンソースコンポーネントを連携させる責任は、多くの場合、その選択を行った組織にあります。組織がオープンソース統合のメンテナンスに過度に多くの時間を費やすことはよくあることです。

    注:

    • これらの投資を行う際には、コミュニティソースおよび企業や財団からの支援を検討しましょう。これらのプロジェクトへの投資は、金銭的なものだけではありません。使用するテクノロジーに関するチームのトレーニングや教育にも投資する必要があります。 
    • また、これらのコンポーネントや関連する統合では通常アップデートが必要となるため、(これらの統合のメンテナンスに関わる作業により) 技術的負債が発生することもあります。
    • オープンソースの実装に関するアイデアについては、AWS オープンソースのブログをご覧ください。
  • モダンアプリケーション開発戦略を選択する際には、戦略がさまざまなワークロードパターンに対応していることが重要です。ワークロードパターンを理解することで、アーキテクチャをより簡単に選択できます。例えば、ウェブアプリケーション、API ベースのマイクロサービス、イベント駆動型アプリケーション、ストリーミングとメッセージング、データパイプライン、IT オートメーションなどです。一部のワークロードは、あるコンピューティング環境では別の種類のコンピューティング環境よりもパフォーマンスが向上したり、コスト効率が高くなったりします。

    AWS サーバーレスを使用して構築する場合、App Runner や AWS Batch などのサービスは、特定のワークロードタイプの要求をすぐにサポートするように設計されています。このアプローチを使用したワークロードでは、柔軟性が低下する代わりに、構築が容易になり、パフォーマンスが向上し、コスト効率が高まります。

    Kubernetes は、組織の必要に応じて、クラウドとオンプレミス環境全体で一貫性を提供します。

  • ワークロードは孤立して存在するわけではありません。ワークロードは、データベース、メッセージング、ストリーミング、オーケストレーション、その他のサービスなどのテクノロジーによってサポートされます。効果的なモダンアプリケーション開発戦略には、これらのサービスとの統合が必要です。マネージド統合により、基盤となるインフラストラクチャの管理と同様に運用上のオーバーヘッドも簡素化されます。

    AWS サーバーレスオプションは、AWS エコシステムに深く統合されています。AWS Lambda は、200 を超える他のサービスからのイベントをサブスクライブできます。例えば、AWS Lambda 拡張機能を使用すると、モニタリング、オブザーバビリティ、セキュリティ、ガバナンスツールとの統合が可能になります。Lambda は、実行環境で指定された関数を呼び出します。これにより、関数コードが実行される安全で分離されたランタイムが提供されます。 

    Kubernetes 向けの AWS マネージドサービスは、マネージドサービスとの統合を提供します。Kubernetes 自体に豊富なパートナーエコシステムが備わっており、他の多数のテクノロジーと統合できます。

  • 多くのお客様は、アイデアを検証するために実験を作成する必要があります。これらのプロトタイプは、新しいアプリケーションのアイデアとなる場合もあれば、失敗した場合には廃棄される場合もあります。健全な環境を実現するには、アイデアを迅速に作成、デプロイ、検証できる環境を提供する機能が不可欠です。この環境は、モダンアプリケーション開発戦略を策定する際に見落とされがちですが、社内でイノベーションを起こす能力は環境の影響を受けることがあります。迅速な構築、テスト、イテレーションに使用できるサービスをチームが利用できるようにすることは、新たなビジネスチャンスを見出す上で非常に価値のあることです。

  • 多くのお客様は、アプリケーションを別の環境で実行したり、簡単に移行または移動したりできるようにすることを希望しています。クラウドプロバイダーを変えるか、またはオンプレミスとクラウドの両方でアプリケーションを実行するかを、常に選択できるようにしておきたいと考えています。これには、多くの場合、人気の言語フレームワークや開発シナリオのサポートに関するニーズが含まれます。例えば、Java デベロッパーは Spring や Python を使用したい場合がある一方で、データエンジニアは PyTorch を使用したい場合があります。モダンアプリケーション開発アプローチを選択するだけでは十分ではありません。アプリケーションポータビリティを実現するには、ベストプラクティスとアーキテクチャが必要です。ソフトウェアアーキテクチャのコンピテンシーを構築し、コンピューティングサービス間で異なるビジネスロジックをより簡単に移植できるようにするパッケージを構築することをお勧めします。

    一部のテクノロジーを使用して構築されたアプリケーションは、一部のコンピューティングサービスでは他のサービスよりも効果的に実行できる場合があります。通常、コンテナサービスは、アーキテクチャの変更が必要となる Lambda よりもレガシーアプリケーションの移行ターゲットとして適しています。

  • アプリケーションポータビリティとオートメーションポータビリティの間には明確な違いがあります。ほとんどの場合、AWS サーバーレスと AWS Kubernetes のどちらを選択するかは、アプリケーションが移植可能であるかどうかとは実際にはほとんど関係がありません。代わりに、重要な要素となるのは、インフラストラクチャチームと DevOps チームが使用するツールです。AWS で Kubernetes アプローチを選択するお客様は、多くの場合、インフラストラクチャとデプロイツールがポータビリティを備えていることを望んでいます。

  • モダンアプリケーション開発にサーバーレスアプローチを採用するか、コンテナベースのアプローチを採用するかを決定する際には、組織のスキルが重要な要素となります。サーバーレスとコンテナの両方で、DevOps チームとサイト信頼性エンジニア (SRE) チームへのある程度の投資が必要になります。アプリケーションをデプロイするための自動パイプラインを構築することは、ほとんどのモダンアプリケーションで一般的です。

    選択内容によっては、管理コストが増大します。例えば、一部の組織は Kubernetes の実装を実行および管理するためのスキルとリソースを備えていますが、これは Kubernetes クラスターを管理するために強力な SRE チームに投資しているためです。これらのチームは、頻繁なクラスターのアップグレードに対応します (例えば、Kubernetes は年に 3 回のメジャーリリースがあり、古いバージョンは非推奨になります)。

    小規模なスタートアップでは少数の IT スタッフがそれぞれ複数の役割を担う場合がある一方で、大企業では本番環境で一度に数百のワークロードをサポートする場合があることを踏まえると、組織の規模は重要な要素です。

  • アーキテクチャの決定にはトレードオフが伴い、多くの場合、その 1 つはコストです。モダンアプリケーションでは通常、関連するコンポーネントの動的な性質により、そのコストの見積もりに苦労することになります。サーバーの固定セットのコストを見積もるのは簡単ですが、それらのサーバーがビジネス価値を生み出していない場合であっても、その料金を支払うことになります。

    どちらのアプローチでも、ワークロードのコスト目標を達成するための複数の手段を利用できます。いずれのアプローチを選ぶかに関する高レベルの選択では、リソースだけでなく、戦略の策定と維持にかかる労力も考慮する必要があります。AWS 料金見積りツールは、特定のワークロードのコストを理解するのに役立ちます。

  • セキュリティとコンプライアンスの要件を満たすことは、あらゆるワークロードの基礎的な側面です。両方の戦略にまたがって AWS のサービスを利用することで、厳しいコンプライアンス要件を満たすことができます。
     
    AWS サーバーレスを使用して構築すると、AWS Identity and Access Management (IAM) との統合を利用して、アクセス、ネイティブ AWS ネットワーキングコンストラクト、AWS ガバナンスツールのサポートを制御できます。
     
    AWS での Kubernetes では、Kubernetes と AWS の両方のセキュリティモデルを理解する必要があり、セキュリティポリシー間のマッピングが必要になる場合があります。Amazon EKS などのマネージド型の AWS のサービスは、EKS 上でアプリケーションを安全に実行するためのアクセラレーターを提供します。
  • AWS サーバーレスAWS での Kubernetes の両方を使用して構築すると、パフォーマンスが高く、スケーラブルで回復力のあるワークロードを構築できます。必要な技術要件を満たすことができます。最高レベルの抽象化を備えたサービスは、AWS アベイラビリティーゾーン全体の配置と環境のスケーリングを管理し、パフォーマンスを向上させ、回復力を高めます。抽象化レベルを低くすると、ワークロードのスケールをより詳細に制御できるようになります。主なトレードオフは、コストと管理の複雑さです。

ステップ 2: 管理する量を決定する

モダナイゼーションの主な利点の 1 つは、運用上の責任を変更できることです。これにより、リソースを解放して、より付加価値の高いイノベーション駆動型の活動を行うことができるようになります。統合、スケーリング、セキュリティ設定、プロビジョニング、パッチ適用などを管理しながらコードを構築および実行できる Amazon EC2 から、ユーザーによって管理されるのがアプリケーションコードのみである AWS Lambda などのサーバーレス機能まで、モダナイゼーションのさまざまなレベルで責任共有オプションを幅広く用意しています。

ステップ 3: ユースケースを決定する

デフォルトの戦略 (AWS を使用したサーバーレス、または AWS での Kubernetes) 内で、ワークロードごとに最も適切なコンピューティングオプションを評価することをお勧めします。

AWS でのサーバーレス戦略のユースケースの例としては、ドキュメント処理システムの構築やウェブサイトのワークロードの処理などが考えられます。その戦略において、主にイベント駆動型のドキュメント処理ワークロードを構築するために AWS Lambda を選択し、トランザクションウェブサイトに必要な低レイテンシーとスケーラビリティのために AWS App Runner を選択することができます。

一方、コンテナ (および AWS での Kubernetes) のユースケースの例としては、既存のアプリケーションのマイクロサービスへの移行に対する進歩的なアプローチの一部として行われる作業が考えられます。多くのレガシーミドルウェアアプリケーションは、コンテナにかける労力を最小限に抑えながら変更できます。

注: 一部の組織は、さまざまなワークロードに対応したり、デベロッパーが選択したりできるように、複数のオプションやワークロードパターンをサポートします。

次の表には、コンピューティングサービスを選択する際に考慮すべき他の多くのユースケースが記載されています。

ステップ 4: ワークロードを比較して適切に選択する

AWS は、Amazon ECS、AWS Fargate を利用するサーバーレスコンテナ、AWS App Runner などのさまざまなコンテナオプションと、Amazon EKS、ROSA、Amazon EC2 でのセルフマネージド Kubernetes などのさまざまな Kubernetes オプションを提供しています。

次の比較表は、ワークロード要件に基づいてアプローチを決定するのに役立ちます。両方のアプローチの要素を選択したり、妥協点を見つけたりできるほか、異なるアプローチを使用する異なるチームを構成することもできます。非常に大規模な企業において、さまざまな戦略を策定している部門があることは珍しくありません。

 

  AWS を使用するサーバーレス AWS での Kubernetes
ワークロード 特定のワークロードに最適化された特定のサービスにより、さまざまなワークロードパターンをサポートします。AWS Lambda を非同期的なワークロードに使用し、AWS Fargate を同期的なワークロードに使用することが考えられます。 クラウドまたはオンプレミスのデータセンター間で一貫したデプロイモデルが好まれる場合に、幅広いワークロードパターンをサポートします。
アーキテクチャの特徴 パフォーマンス、スケーラビリティ、信頼性、コストの最適化を提供する特定のサービスを使用して、ほとんどのアーキテクチャとパターンをサポートします。 テクノロジースタック全体での一貫性が好まれるほとんどのアーキテクチャをサポートします。いくつかのレベルの最適化が利用可能ですが、統合と管理において、より多くの労力が必要になります。
統合 AWS サーバーレスは、多くのマネージドサービスとの統合を提供します。AWS Lambda などの一部のオプションでは、200 を超えるサービスをサブスクライブし、マネージド型でイベントを受信できます。  多くのパートナーが AWS 統合を提供しています。 Kubernetes 向けの AWS マネージドサービスは、AWS のサービスとの統合を提供します。Kubernetes 向けのパートナーエコシステムは豊富で、他のオープンソーステクノロジーとの統合を提供します。多くのテクノロジーパートナーは、Kubernetes 統合を検証するための最初の選択肢として EKS を使用しています。
プロトタイピング AWS サーバーレスは、お客様がコードを迅速に記述、デプロイ、変更できるように最適化されており、事前に多くの選択を必要としない、迅速なプロトタイピング作業を行うための便利なオプションとなっています。 Kubernetes の戦略を採用しているお客様は、多くの場合、プロトタイピング専用の特別なクラスターを設定し、他の環境と同様に維持する必要があります。
オーバーヘッド AWS サーバーレスは、マネージドサービスを最大限に活用することに重点を置いて設計されており、サーバー、ネットワーキング、統合の管理にかかる労力を最小限に抑えることができます。 AWS は、Kubernetes 向けにいくつかのパターンを提供しています。これは、AWS がアドオンや EKS Blueprints などのアクセラレーターを提供するものの、テクノロジーの複数のレイヤー (クラスターやクラウドネットワーキングなど)、または Kubernetes や AWS のセキュリティロールを管理する必要があることを意味する場合があります。
エコシステム AWS には、AWS のサービス上に構築され、ソリューションと統合を提供するパートナーの大規模なエコシステムがあります。AWS は、さまざまな分野において、多くのオープンソーステクノロジーを使用し、それらを基盤として構築されています。 Kubernetes は、あらゆるクラウドで主要なサポートが提供されており、膨大な量のコミュニティサポートを受けることができる大規模なエコシステムです。  CNCF を取り巻く環境は、広大なエコシステムの一例です。AWS は、お客様がこれらの人気のあるツールを採用するのに役立つアドオンやブループリントを提供しています。
アプリケーションポータビリティ アプリケーションアーキテクチャ (マネージドサービスまたはサービスを使用するアプリケーション向け) は、ビジネスロジックを Lambda、App Mesh、または ECS から他のコンピューティング環境に簡単に移植できるように設計できます。 Kubernetes はほとんどのクラウドとオンプレミスで利用でき、ほとんどのワークロードは移植可能です。コード内のサービスメッシュに依存する特定の Kubernetes パターン (Istio や、KNative などのプログラミングモデル) では、アプリケーションは Kubernetes を必要とし、Kubernetes 以外には移植できません。一部の機能により、特定のバージョンにロックされる可能性があります。さまざまな Linux ビルドまたは特定のハードウェア (ARM または AMD) をサポートするには、イメージを再構築する必要がある場合があります。
オートメーション オープンテクノロジーに基づくオプションを使用した AWS 固有のオートメーションサポート。AWS CloudFormation、AWS サーバーレスアプリケーションモデル (AWS SAM)、および一部の AWS Cloud Development Kit (AWS CDK) ライブラリはその一例です。お客様は、Terraform などのオープンソースオプションを使用できます。AWS の多くのお客様は、Jenkins などのオープンソース DevOps ツールを使用しています。 Kubernetes で戦略を策定するお客様は通常、Kubernetes を自動化するツールを使用することを選択します。クラスター作成のオートメーションが必要であり、AWS API、AWS CloudFormation などの AWS ツール、または CDK を使用できます。多くのお客様が Terraform などのテクノロジーを使用しています。AWS EKS Blueprints は、クラスターやアドオンを作成するための、Terraform と CDK 向けのアクセラレーターの一例です。多くのお客様は、Kubernetes API を使用してデプロイするために Flux や ArgoCD などの GitOps ツールを採用したり、ネイティブクラウドリソースをプロビジョニングするために AWS Controllers や Crossplane などのツールを使用したりし始めています。
組織の規模とスキル 一部の企業は、主要なクラウドで標準化し、最初に AWS サーバーレスを選択しています。これは、SRE チームを設けるための資金/リソースはある可能性があるものの、全社的に AWS を採用することで、俊敏性を最適化し、運用コストを削減することにしたからです。 中規模から大規模の企業 (または、さまざまなクラウドやオンプレミスのデータセンターで実行する製品を販売するソフトウェアベンダー) は、Kubernetes ファーストのアプローチを採用することがよくあります。成功しているお客様は通常、多くのクラスターを管理、実行、維持するインフラストラクチャチームや SRE チームにはるかに多くの投資を行っています。
スケーラビリティ/回復力 AWS Lambda のお客様は、関数が呼び出されている間のみ料金を支払います。Lambda が適切ではない場合は、Fargate や ECS を利用できます。ハードウェアアーキテクチャのさらなる選択肢と、コンピューティング料金オプション (AWS EC2 スポットインスタンスなど) を提供します。 AWS での Kubernetes のアプローチは、パフォーマンス、スケーラビリティ、回復力の要件を満たすために適切に設計 (Well-Architected) されています。EKS では、AWS EC2 スポットや Graviton などのオプションを使用することもできます。
セキュリティ AWS サーバーレスのアプローチでは、AWS のセキュリティ、ネットワーキング、および慣行を利用します。 Kubernetes のアプローチでは、Kubernetes セキュリティと AWS セキュリティの両方を理解する必要があり、Kubernetes セキュリティポリシーの AWS ポリシーに対するマッピング、コンテナイメージとランタイムの保護、サードパーティーのコンテナツールの検証などの運用上のオーバーヘッドが発生します。  

新しいモダンアプリケーションを構築したり、既存のアプリケーションをモダナイズしたりする場合、アーキテクトやデベロッパーは多数のビルディングブロックを利用できますが、最重要要素の 1 つはコンピューティングサービスの選択です。

組織が構築およびデプロイするワークロードやアプリケーションのタイプを知ることは、モダンアプリケーション開発戦略を選択するうえで重要です。各ワークロードには異なる特性や要件があります。例えば、ドキュメント処理ワークロードでは、トランザクションウェブサイトとは大きく異なるレイテンシーおよび稼働時間に関する要件を満たす必要があります。

ステップ 5: よくある落とし穴を回避する

環境における標準化を理解する

複数のワークロードパターンを実行している多くの組織は、効果的にサポートおよび実行できる一連のパターンを標準化したいと考えています。一部の大規模な組織は、コンピューティングオプションを標準化し、ほとんどのワークロードを実行するためにデフォルトのプラットフォームを選択しつつ、必要に応じて例外を設けようと試みています。

標準化は、一貫性を提供するとともに、組織が雇用する必要がある専門スキルを持つ人材の数を最小限に抑えるのに役立ちます。これらは優先すべきコンピューティングの選択肢とされ、他のオプションはその優先すべき選択肢が機能しない場合にのみ検討されることになる可能性があります。多くの場合、標準の選択は一連のワークロードを効果的にサポートしますが、困難を伴うワークロードもあります。そのため、一部の組織は、さまざまなワークロードに対応したり、デベロッパーが選択したりできるように、複数のオプションやワークロードパターンをサポートします。

環境における統合を理解する

一部の組織では、オープンソース統合のメンテナンスに、許容範囲を超える時間を費やしていることがよくあります。

これらの投資を行う際には、コミュニティソース、および/または企業や財団からの支援を検討することをお勧めします。これらのプロジェクトへの投資は金銭的なものだけでなく、知識資本や潜在的な技術的負債への投資でもあります。なぜなら、これらのコンポーネントや関連する統合は通常、更新を必要とするからです。詳細については、AWS オープンソースブログをご覧ください。

アーキテクチャの特性を理解する

幅広いアーキテクチャをサポートできることが重要です。AWS でシステムを構築する際の意思決定の長所と短所を理解するためのガイドとして、AWS Well-Architected フレームワークを活用することをお勧めします。さらに、フレームワークを使用することで、信頼性、スケーラビリティ、安全性、効率性、コスト効率の高いシステムを設計して、クラウド内で運用するためのアーキテクチャのベストプラクティスを学ぶことができます。

ステップ 6: アプローチを決定する

組織とワークロードの規模、パターン、ビジネス要件に基づいて、両方のアプローチの特定の要素を選択したり、異なるチームに異なるアプローチを採用させたりする必要がある場合があります。各チームが異なる戦略を採用することは珍しいことではありません。

AWS サーバーレスと AWS

  • AWS LambdaAWS App RunnerAmazon ECSAWS Fargate などの AWS マネージドサービスおよびツールを、最初の選択肢として検討します。 
  • プロビジョニング、DevOps、インフラストラクチャオートメーション、セキュリティ、ネットワーキング、オブザーバビリティ/運用など、AWS に関するルールの策定に投資します。
  • 生産性を高め、運用上の負担を最小限に抑えます。

AWS での Kubernetes

  • Kubernetes を主なコンピューティングプラットフォームインターフェイスとして使用します。
  • 複数の Kubernetes クラスターや、その上のワークロードおよびツールの実行と管理に関するルール、GitOps などの高度なパターンを採用します。
  • さまざまなエコシステムやパートナーツールと統合します。
  • Kubernetes をご利用のお客様は、特定のユースケースでマネージド AWS サービスや、AWS Lambda などの他のコンピューティングオプションを利用できます。

アプローチを実装する

ご使用の環境のワークロードに最適なアプローチを決定したので、アプローチの実装を開始するのに役立つ、次のリソースを確認することをお勧めします。

  • AWS でのサーバーレスの概要
    サーバーレスファースト戦略を採用して、アプリケーションスタック全体の俊敏性を高めるようにモダンアプリケーションを構築します。このガイドでは、スタックの 3 つのレイヤー (コンピューティング、統合、データストア) すべてに対応するサーバーレスサービスについて説明します。
    サーバーレスのウェブアプリケーションを構築する
    このチュートリアルでは、AWS Lambda、Amazon API Gateway、AWS Amplify、Amazon DynamoDB、Amazon Cognito を利用して、シンプルなサーバーレスウェブアプリケーションを作成する方法を学習します。
    サーバーレスコンピューティングの実践的なワークショップ
    これらの無料のガイド付きワークショップでは、AWS Lambda、AWS Step Functions、Amazon API Gateway、Amazon DynamoDB、Amazon Kinesis、Amazon S3 などのサービスを利用してサーバーレスアプリケーションやマイクロサービスを構築するための基本をご紹介します。
    AWS Fargate: コンテナ向けサーバーレスコンピューティング
    AWS Fargate は、サーバーレスで従量制料金のコンピューティングエンジンであり、サーバーを管理することなくアプリケーションの構築に注力することを可能にします。AWS Fargate は、Amazon Elastic Container Service (Amazon ECS) と Amazon Elastic Kubernetes Service (Amazon EKS) の両方との互換性を備えています。
    AWS App Runner の概要
    AWS App Runner を利用すると、インフラストラクチャやコンテナの使用経験がなくても、コンテナ化されたウェブアプリケーションや API サービスを構築、デプロイ、実行できます。
  • Kubernetes アプローチを選択する
    Amazon Elastic Kubernetes Service (EKS) マネージド Kubernetes サービスを利用して、AWS クラウドとオンプレミスのデータセンターで Kubernetes を実行する場合のオプションを確認してください。
    Amazon EKS の開始方法
    Amazon EKS の使用を開始するためのステップバイステップのガイドと、役立つブログ、動画、詳細なチュートリアルへのリンクを提供します。
    Amazon EKS ワークショップ
    Amazon EKS を最大限に活用する方法に関するステップバイステップの手順を確認しましょう。
    AWS Controllers for Kubernetes (ACK) のご紹介
    ACK は、Kubernetes から AWS のサービスを直接管理できるようにするツールです。ACK を使用すると、AWS のサービスを利用するスケーラブルで可用性の高い Kubernetes アプリケーションを簡単に構築できます。
    Red Hat OpenShift Service on AWS とは
    ROSA で ROSA API およびツールを使用して Kubernetes クラスターを作成し、あらゆる AWS のサービスにアクセスできるようにする方法を詳しくご覧ください。

    ベストプラクティス

    セキュリティ

    セキュリティは、Kubernetes クラスターとアプリケーションを設定および維持するための重要なコンポーネントです。Amazon EKS はデフォルトで、安全なマネージド Kubernetes クラスターを提供しますが、安全な実装を実現するために、クラスターの一部として実行するノードとアプリケーションを設定する必要があります。詳細については、「Amazon EKS Best Practices Guide for Security」をご覧ください。

    ホストセキュリティ

    ソフトウェアの脆弱性や意図しないネットワークのエクスポージャーがないかを確認するために、継続的に AWS ワークロードをスキャンする自動脆弱性管理サービスである Amazon Inspector を利用します。

このページはお役に立ちましたか?