よくある質問

Q: モダンアプリケーションとはどのようなものですか?

モダンアプリケーションは、最新のテクノロジー、アーキテクチャ、ソフトウェア配信プラクティス、運用プロセスを組み合わせたアプリケーションです。チーム全体の価値実現の速度、頻度、整合性、安全性を高めることができます。通常、モダンアプリケーションでは疎結合化された分散型テクノロジーを活用して、イベント駆動型のサーバーレスコンポーネントを重視することで面倒な単純作業を削減できるので、チームがより多くの時間を顧客のための価値創造に充てられるようになります。また、運用とセキュリティのツールを活用することで、高いデプロイ信頼性と一貫性が実現されています。そのため、1 日に何度も安全にデプロイすることが可能です。モダンアプリケーションのインフラストラクチャ、セキュリティ、デプロイなどの機能は自動化されているため、手動プロセスや大規模な管理体制での運用よりもスピーディです。

Q: 企業ではどのようにモダンアプリケーションを構築していますか?

通常、アプリケーションの機能を狭めることで、俊敏性を高め、運用やリスク管理をしやすくします。そのようなアプリケーションの開発者は、作業に適したツールの選択を重視し、選択したアーキテクチャをアプリケーションの目的にぴったり合わせるようにします。例えば、アドレスと連絡先情報などとの間の関連性を示すために統合されるデータにはリレーショナルデータベースを使用しますが、ある人とその友人、家族、同僚のさまざまなグループなどとの強いつながりを管理し、可視化するにはグラフデータベースを活用します。後者をリレーショナルデータベースで構築することも可能ですが、その課題に最も適しているのはグラフデータベースです。そこを出発点として、選択されたツールの運用管理を最小化し、AWS のビルディングブロックをできる限り活用することを目標にします。そのようにして、企業はモダンアプリケーションの管理と維持を、可能な限りオートメーションを使用して実施しています。こうして、モダンアプリケーションは軽量で信頼性、スケーラビリティ、安全性を備えたものとなり、アプリケーションの所有者はより迅速かつ頻繁に価値の提供を実現できます。

Q: AWS でのモダンアプリケーション構築にはどのような独自性や利点がありますか?

企業は AWS の幅広いサービスと機能を使用して、想像力をかき立てるさまざまなアプリケーションを構築できます。現在、AWS Lambda、AWS Step Functions、Amazon API Gateway、AWS Fargate といった AWS 提供のサーバーレス機能は拡大を続けており、画一的で面倒な作業の負担から開発者を解放しています。拡大と成熟を続ける AWS の開発者ツールによって、インフラストラクチャとデプロイのオートメーションにより DevOps プラクティスを実現できます。AWS Cloud9 を使用したシンプルなサーバーレス開発環境も用意されています。ビルドからコミット、リリースに至るまで、AWS ではフルセットのツールが提供され、伸縮性のある継続的デリバリーを、過去のサービスのように運用面で不安を感じることなく実現できます。さらに、AWS はマイクロサービスアーキテクチャをその最初期から導入しているため、組織によるマイクロサービスアーキテクチャの構築と管理についての深い専門知識とツールが蓄積されています。

Q: マイクロサービスの境界線はどこに設定されていますか?

マイクロサービスの境界線を設定するとき、考慮すべき最も重要な要素はスコープと依存関係です。目標とするところは、サービスのスコープを十分小さなものにすることです。1 つのチーム (通常 5～10 人) が、他のサービスや他のチームからは独立したサービスを所有し、管理、スケール、デプロイを担当することができるようにします。境界は、サービスの機能を文脈として設定および特定され、通常は単一のデータまたはビジネスドメインに含まれます。サービスの規模は、サービスを所有するチームの所有権と自律性ほど重要ではありません。例えば、支払いの送信やリクエストの機能を持つ決済マイクロサービスは、サービスインターフェイス (通常 API と呼ばれる) によって結合された、ストレージ、統合、コンピューティングの各コンポーネントによって構成されることになります。1 つのチームでも効率的にサービスの所有や管理ができます。

Q: クラウドに移行するべきですか、それとも先にモノリスを分割すべきですか?

企業には、最初のうち、クラウド移行の前にリファクタリングが必要だと考える傾向があります。移行前にリファクタリングが必要な場合もありますが、最小限の作業で移行できる、最も高速な方法を探すことを推奨します (最小限のリファクタリング)。クラウドでリファクタリングを実施した場合は、最終アーキテクチャやアプリケーションの構成が、オンプレミスとは大きく異なるものになるのが現実です。例えば、クラウドでは AWS のビルディングブロックを使用することで、違う方法でリファクタリングを行うことができます。オンデマンドで利用できるクラウドインフラストラクチャを活用すれば、リファクタリングとテストへの投資を削減することもできます。

Q: モダンアーキテクチャによってどのようにセキュリティを強化できますか?

マイクロサービスによって、小規模の自律的なチームによって所有され運用される小規模なシステムを実現できますが、マイクロサービス構築に利用できるテクノロジーは、オートメーション、スケーリング、セキュリティについての新たな機会を開くものでもあります。

AWS のお客様である Travelex は、モダンアーキテクチャによってセキュリティを強化する方法を示す好例です。Travelex は世界各地で信頼を得ている通貨両替業者で、130 か国に展開しています。同社では、モノリシックなオンプレミスデータセンターモデルから脱却することで、リリースのペースをそれまで (年間 8 回) より高速化し、セキュリティも強化したいと考えました。同社には金融規制に対する準拠に関する数十年にわたる経験がありましたが、クラウドワークロードに対する認可を求めることは初めてでした。

同社はセキュリティが向上した設計により、認可を取得することができました。また、Docker や Amazon Elastic Container Service、さらには AWS Key Management Service、Amazon VPC、Amazon ウェブアプリケーションファイアウォールなどを含むセキュリティ管理フレームワークを使用し、マイクロサービスアーキテクチャをデプロイすることも可能でした。同社では、自動化され、監査可能で不正を防ぐデプロイを作成しています。また、不具合の影響範囲を狭めるため、すべてのコンテナを 24 時間後に破棄し、新しいセキュリティ証明書を使って再度デプロイするプロセスを設計し、機密性のある設定内容の紛失や盗難の影響を最小限にとどめています。以前の低頻度モデルでは年間 8 回だったデプロイを、1 週間に何百回も実施できるようになり、オートメーションの実装により全体的なセキュリティ体制が向上しました。

Q: チームにオーナーシップと自律性を発揮させるには、どのようなチームを構築できますか?

Amazon には、ピザ 2 枚のチームという考え方があります。これは 2 枚のピザで食事が足りるほど小さなチームという意味で、通常 5～10 人です。そのチームは、自分のチームのアプリケーションに対して全面的なオーナーシップと自律性を持ち、デリバリーに必要なスキルすべてを備えています。ハンドオフ、チーム間のコミュニケーション、依存関係は最小限になっています。クラウド移行を進めると同時にアジャイルプラクティスと DevOps プラクティスを採用する組織は、ますます増えています。これらのプラクティスとテクノロジーは単独でも価値がありますが、真の俊敏性を発揮し、実現する価値を最大化するためには、組織がこれらのプラクティスをピザ 2 枚のチームのコンセプトと組み合わせて、スピードと自律性を最大限に高めることが必要です。結局のところ、この種の変革には、ピザ 2 枚のチームの効果性を最大化するために、これまでとは違う行動様式と構造が必要になります。チームが自分たちで構築したものを所有し、運用することを容易にするため、通常の共有サービスモデルが縮小される傾向にあります。

例えば、Cox Automotive では、大規模アジャイル開発フレームワーク (SAFe) をエンタープライズ全体で実施し、AWS オールイン化を進め、構築者が運用者となる環境を整備することで、スタッフ、プロセス、テクノロジーの変革に乗り出しました。Cox Automotive では、スクラムやカンバン、または他のアジャイル手法を使用した小規模チームが構築されました。所有権と自律性を発揮させるため、各チームは通常 8～10 人サイズで構成されており、これは Amazon のピザ 2 枚のチームと非常によく似ています。組織的なデリバリー、運用、テクノロジー戦略の実施により、Cox Automotive では、SAFe の上部レベルに製品、エンジニアリング、アーキテクチャ、ビジネスの各分野のリーダーからなるチームを立ち上げ、IT とビジネスの一体化を進めました。その結果、いっそう透明性の高い、共同作業に適した環境を実現しています。このモデルによって、優先順位の関係性が明確になり、各チームは顧客の問題を解決する際に関係する状況を把握できるようになりました。 

Q: チームを維持するにはどうすればよいですか?

多くの企業では、個人と組織の習熟度が変わり続ける状況を踏まえて、継続的な教育プログラムを準備しています。クラウド導入の初期段階では、安全なランディングゾーン、コスト管理、クラウドサービスとサーバーレスなどの概念に重点を置いた、基礎的なトレーニングを推奨します。そこをスタート地点に、Well Architected レビューを活用し、組織全体での学習とアーキテクチャの進化を促すようにしてください。クラウドの基礎が据えられたら、ソフトウェア開発のライフサイクルとオートメーションに取り組み、DevSecOps を活用したアジャイルアプローチを目指すようにします。トレーニング内容はスタート地点によって異なるでしょう。

Q: 過渡的なアーキテクチャと組織構造をさらに戦略的な位置へと移していくのに必要となる基本要素は何ですか?

戦略的な位置で実施する前に、組織がリーダーのかかわり方、サポート、変化に焦点を合わせることを多く目にします。リーダーによる行動とサポートは、移行の失敗と成功に直接影響するものです。多くの組織は、もっと戦略的な移行作業に乗り出す前に、クラウド、アジャイル開発、DevOps のプラクティスに手を出しています。新しいテクノロジーやプラクティスの導入においてトレーニングは主要な面の 1 つであるとはいえ、究極的にビジネスの俊敏性を高めるのは行動様式を変え、ゲートからガードレールに移行することです。現在の高速道路について考えてみてください。車線が引かれ、出入り口があり、追い越し車線と速度制限が設定されています。車は昼でも夜でも必要なときに自由に進入および退出でき、他の方法よりもずっと早く目的地に到着できます。各チームに対して、そのような種類の環境を整えたいと思います。規則が周知され、スピードと柔軟性を損なわない方法で一貫して施行されている環境です。構想を現実化するために必要となる行動と信念をしっかりと理解しておくことが、リーダーにとって重要な出発点となります。

Q: マイクロサービスアーキテクチャを有意義なしかたで導入する準備として、カルチャーにはどのような変化が必要ですか?

理想的なのは、組織での構造とデリバリーの手法を、製品やサービスに対する自律性とオーナーシップを持った小規模チームへと変化させるところから始めることです。カルチャーや組織構造の変化なしにマイクロサービスを導入することも可能ではありますが、サービスを導入してもらい、重複を排除するのに苦労するかもしれません。まとまりのある戦略やデリバリーモデルがなければ、求めた結果は得られないでしょう。変化のためのアプローチに唯一の正解はありませんが、誤った方法は確実に存在します。達成しようとしている目標に焦点を合わせることから始めましょう。どのような課題を解決しようとしているでしょうか。うまく解決できたかどうかはどのようにしてわかるでしょうか。 少しずつ課題に取り組み、それを繰り返していきます。

Q: チームへの CI/CD 導入をどのように開始できますか?

最新化を続ける過程では、継続的インテグレーション (CI) および継続的デプロイ (CD) ツールを使用すると、急速な変化に伴うリスクを最小限に抑えるのに役立ちます。実践において、多くの組織はまず継続的インテグレーションを導入し、最初のいくつかのアプリケーションでは本番デプロイを手動で実施します。そのようにしてリリースプロセスの最終段階にヒューマンチェックを行えるようにします。いくつかのサービスが相互に通信する場合や、既存アプリケーションへの統合が特殊な通信を必要とする複雑なものである場合は、CI を検討する必要があります。通常、プラクティスに習熟し、オートメーションが推進されていくと、組織として自信を持ってリリースすることや、自動化されたセーフティチェックを安心して使用できるようになります。多くの場合、このタイミングで CI/CD への移行を実施し、手動ステップを排除できます。

Q: 価値の提供をスピードアップさせるための鍵は何ですか?

スピードアップの最も簡単な方法は、行程を減らすことです。価値の提供速度に優れた組織では、何をするべきかがよく統制されています。学習と優先順位の見直しが継続的に行われ、時間、エネルギー、お金が最も価値ある活動に集中されます。スピードアップに役立つツール、テクニック、テクノロジーがいくつかあります。継続的デリバリーパイプラインによって、インフラストラクチャ、セキュリティ、デプロイ、テスト、ロールバックを自動化することはその代表例です。これにより、デプロイの一貫性を向上させ、平均修復時間を短縮し、障害発生率を改善させながら、デプロイ頻度を高めることができます。クラウドでは、ジョブに適したツールを選択しながら、運用とメンテナンスの負荷を減らすことができます。こうして、ミスマッチによる無駄を回避しながら、価値に焦点を合わせられます。AWS Lambda、AWS Fargate、Amazon DynamoDB といったフルマネージド型サーバーレスサービスを選択すれば、運用とメンテナンスの手間を省けます。ジョブに適したツールを重視し、画一的な作業を最小限に抑えることで、もっと多くの時間を自身のビジネスやお客様に価値を提供するソリューション構築に充てられるようなります。さらに、ソリューションをシンプルにすることで、変更のコストを下げ、ピボットや反復の速度を上げることができます。

Q: Lambda やコンテナを使うタイミングはどうすればわかりますか?

モダンアプリケーション構築の俊敏性を最大限に高めるために AWS Lambda やコンテナを選択するお客様は増え続けています。何を選ぶかは、ワークロード複雑さ、通常のタスクのランタイム、呼び出しパターンにより大きく変わってきます。コンテナはコードをパッケージ化する方法として最も人気のある選択肢です。アプリケーション設定の移植性と柔軟性に優れているため、レガシーアプリケーションの最新化に非常に適したツールです。Lambda を使用すると、最高度のシンプルさを達成できます。作成が必要なのはビジネスロジックのコードのみです。

コンテナではコード、設定内容、依存関係を単一オブジェクトにパッケージ化する方法が標準化されているため、任意の場所で実行し、すばやくスケールし、CPU とメモリの使用率を細かく設定することができます。実際のところ、コンテナワークロードの大部分は AWS で実行されています。コンテナの実行に必要なコンピューティングには、Amazon EC2 や AWS Fargate を使用できます。Fargate では、コンテナをサーバーレスで実行できます。また、Amazon ECS や Amazon EKS などのオーケストレーションサービスも必要になります。

Lambda のコードは、S3 への新規ファイルの追加や、DynamoDB への新規テーブルエントリなど、イベントやトリガーに応答して実行される場合もあれば、API コールで直接実行される場合もあります。Lambda に用意されているイベントトリガーは 115 種類で、市場のどの製品より多くなっています。コードさえアップロードすれば、高可用性を実現しながらコードを実行およびスケーリングするために必要なことは、すべて Lambda により行われます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金は発生しません。お客様は、ほとんどすべてのアプリケーションやバックエンドサービスを、サーバーのプロビジョニングや管理を必要とせずに実行できます。

Q: どのコンテナオーケストレーションサービスを選択すればよいですか?

これは、自分が現在持っている専門知識、および運用のしやすさやアプリケーション設定のコントロールの好みによって決まります。操作を最小限に済ませたいのであれば、AWS Fargate を推奨します。サーバーの管理を必要とせずにコンテナを実行できる唯一のコンピューティングエンジンです。Fargate を使用する場合は、コンテナイメージを作成し、実行方法と実行環境を定義し、リソース分の料金を支払います。これにより、適切なインスタンスタイプを選択すること、インスタンスの保護、パッチ適用、アップグレードを行うこと、クラスターをスケールすることが不要になります。

AWS での構築に習熟しており、コンテナインフラストラクチャの一部として主に AWS のツールとサービスを使用する予定の場合には、Amazon ECS でコンテナを実行するのが最適です。AWS では、ECS をゼロから構築し、ロードマップを完全にコントロールしているためです。IAM、CloudWatch、Autoscaling、Secrets Manager、各ロードバランサーといった AWS のサービスとの統合を、お客様が慣れた方法でコンテナのデプロイとスケールを行いながら、すばやくネイティブにできるようになっています。

Kubernetes の運用を希望する場合は、Amazon EKS を推奨します。クラウドで Kubernetes を運用する、最高度に信頼できる方法です。EKS は複数の AWS アベイラビリティーゾーンにまたがって実行されることで、冗長性と回復性が組み込まれているため、高い信頼性を有しています。また、EKS のお客様に対して最新のセキュリティパッチが適用された状態を確保します。つまり、最新バージョンの修正内容を、サポートされていないバージョンに適用し、EKS アプリケーションに信頼性と可用性の問題が発生するのを防ぎます。

Q: 自分で管理するよりもサーバーレステクノロジーを選択するとよいのは、どのような場合ですか?

インフラストラクチャと運用の管理がお客様のビジネスのコアコンピテンシーとなっているのでない限り、そのような作業の負担を減らし、お客様にメリットをもたらすイノベーションを重視することをお勧めします。多くのお客様が、サーバーレスを優先的に検討するアプローチを採用し、やむを得ない理由がない限りはサーバーレステクノロジーを使用するようになっています。サーバーレステクノロジーにより、開発者はビジネスロジックに焦点を合わせることができ、基盤となるインフラストラクチャを管理する複雑な作業を省けます。アプリケーションを構成する機能について十分な知識がある場合、サーバーレスによってそれらの機能を個別のコンポーネントに分解できるので、開発者には結果に集中してもらうことができます。

Q: サーバーレステクノロジーを使用することで、マルチクラウド戦略への影響はありますか?

サーバーレステクノロジーを使用するという決定は、クラウドプロバイダーを選ぶ中での全体的な決定の一部であり、多くの場合マルチクラウド戦略への影響をそれ以上与えるものではありません。企業がクラウド戦略を立てるとき、多くの場合最初のうちはクラウド内のワークロードを 2～3 社のプロバイダーに均等に振り分けたいと考えるものです。しかし、実際の評価段階に入ると、その路線を採用する企業はごくわずかです。多くの企業はいくつかの理由からプロバイダーを 1 社に絞ります。1 つの理由として、複数のクラウドの運用は困難です。開発チームに複数のクラウドプラットフォームに精通してもらうことが必要になります。また、チームは特定のプロバイダーがさまざまな機能を提供していてもそれを十分に活用できなくなります。各クラウドで提供されているプラットフォームに共通している部分のみで標準化する必要があるためです。最後の点として、ワークロードを複数のクラウドプロバイダーに分散させてしまうと、購買力が落ち、ボリュームディスカウントを受ける機会も減ってしまいます。そのため、大多数のお客様は主に 1 社のインフラストラクチャまたはクラウドプロバイダーを使用することにしています。

Q: モダンアプリケーションによってセキュリティはどのように向上しますか?

モダンアプリケーション設計の主要な構成要素は、セキュリティを "早い段階から何度も" 開発プロセスに組み込むことです。アイデア化、設計、開発、テスト、ローンチの各段階で、セキュリティ、リスク、コンプライアンスの要素が検討されます。主要なセキュリティ管理を自動化し、CI/CD パイプラインのセキュリティトリガーも自動化することは、開発プロセスにおけるセキュリティの把握に役立つのみでなく、手動介入の必要も排除されます (テストと修復)。

Q: クラウドとモダンアプリケーションを導入することで、セキュリティのプラクティスとオプションはどのように変化しますか?

モダンアプリケーションでは、インフラストラクチャがコードであるのと同様、セキュリティもコードになります。セキュリティ管理の組み込みとインフラストラクチャのモニタリングの自動化は、多くの組織において根本的な変化をもたらします。自己修復インフラストラクチャの設計と構築が可能になるためです。さらに、サーバーレステクノロジーを利用すると、アプリケーションの攻撃対象領域が大幅に減少します。コードに潜在的な脆弱性があっても、必要なときにしか実行されないためです。

例えば、Verizon ではさらに 1,000 種類のビジネスで重要なアプリケーションとデータベースを AWS に移行しようとしていました。それで、セキュリティ検証プロセスをスケールする方法が必要になりました。インフラストラクチャチームのみでなく、何千人もの開発者にクラウドリソースへの直接アクセスを委ねることが必要でした。また、Verizon では、開発者がハードウェアとセキュリティのチェック完了を待たされることなく、お客様への新たな価値の提供にもっと多くの時間を充てられるようにする必要があると考えました。そこで、自動化されたセキュリティ検証プロセスが開発されました。チームがそれぞれのタイムラインに従って新しいアプリケーションを開発できるようにするものです。最初のステージとして、このプロセスでは、まず基本的な設定ルールの分析が行われます。その後、デプロイや、ログ記録、アクセス権設定、暗号化の確認に使用されていきます。第 2 ステージでは、検証されたテンプレートが実地検証のためにテスト環境にデプロイされ、AWS ネイティブの設定サービスによってデプロイされたシステム設定が監査されます。最後の第 3 ステージでは、3P (防御的、予防的、予知的) 脆弱性評価が実行され、OS のパッチ適用漏れやその他の脆弱性がないかチェックされます。プロセスが完了すると、その結果にデジタル署名がなされます。そして、自動化されたデプロイパイプラインでチェックが実行され、アプリケーションの本番使用が承認されるかどうか判定されます。この検証プロセスに合格しなければ、デプロイされません。

Verizon の自動化されたセキュリティ検証プロセスは、お客様がオートメーションと AWS クラウドを活用してチーム内に自律性を生み出し、安全かつ迅速に業務を進められるようにすることで、ビジネスの俊敏性がどのように高められるかを示す一例です。 

Q: サーバーレス環境ではどの部分のセキュリティを自分で確保することが必要ですか。 ツールやプロセスは変化しますか?

以下の 2 点に注目します。1 – 開発や運用するアプリケーションコードのセキュリティをベストプラクティスに従って確保する (OWASP トップ 10 など)。2 – 管理するインフラストラクチャのセキュリティを確保する。クラウドのベストプラクティスに従い、アイデンティティ、発見的コントロール、インフラストラクチャのセキュリティ、データ保護、インシデント対応を重視する。

Q: このまったく新しい分野に既存の自社セキュリティポリシーを実装するにはどうすればよいですか?

多くの企業は、セキュリティを特定の製品やサービスと同一視するのではなく、セキュリティの結果や統制目標に注目し、それらが達成されるようにすることで良い結果を得ています。そうするためには、通常、対象範囲を広げ、セキュリティとコンプライアンスの目標に注目したセキュリティポリシーを再度作成することが必要になります。ランブックレベルでは、そのプラットフォームのコントロールが、関連ポリシーに記載されたセキュリティ目標を達成している、または上回っているかを詳細に明らかにします。

Q: 用途に合わせて最適なデータベースを選択するにはどうすればよいですか?

お客様は独自のパフォーマンスおよびビジネス要件に応じた、スケーラブルで高性能かつ機能的なアプリケーションを求めています。アプリケーションに合ったデータベースを選択するには、これらの要件に加えデータモデルおよびデータアクセスのパターンを考慮に入れる必要があります。
AWS ではお客様のあらゆるニーズに対応するために、以下の専用データベースサービスを提供しています。

• フルマネージド型リレーショナルデータベースの Amazon RDS、商用グレードのリレーショナルデータベースの Amazon Aurora、および Amazon Aurora Serverless をはじめとする最新の機能設定
• 規模に関係なく数ミリ秒台のパフォーマンスを実現する、key-value およびドキュメントデータベースの Amazon DynamoDB
• グラフデータベースに最適な Amazon Neptune
• MongoDB のワークロードをサポートする、フルマネージド型ドキュメントデータベースの Amazon DocumentDB
• IoT および運用アプリケーションに適した時系列データベースサービスの Amazon Timestream
• 台帳データベースの Amazon Quantum Ledger Database (QLDB)
• 複数の AWS リージョンにわたり、1 秒未満のレイテンシーで書き込みをレプリケートする Amazon Aurora Global Database

Q: レガシーデータベースと長期のライセンス契約を抱えています。最新のデータベースに移行するにはどうすればよいですか?

Database Freedom は従来のデータベースエンジンから、AWS のクラウドネイティブデータベースに移行するお客様のサポートを目的とした独自のプログラムです。Database Freedom では、MySQL および PostgreSQL 互換のクラウド向けリレーショナルデータベース Amazon Auroraをはじめ、Amazon RDS for PostgreSQL、MySQL、MariaDB、Amazon Redshift、Amazon DynamoDB、Amazon EMR、Amazon Kinesis、Amazon Neptune、Amazon QLDB、Amazon Timestream、Amazon DocumentDBへの移行をサポートしています。また AWS Schema Conversion Tool と AWS Database Migration Service により、こうしたサービスへの迅速かつ安全なデータベースの移行を支援します。
対象となるお客様には技術的な状況および移行目標に応じ、アプリケーションアーキテクチャ、移行戦略、プログラム管理、従業員教育に関するアドバイスを提供します。さらに移行の実現可能性を検証する PoC (概念実証) のほか、

AWS プロフェッショナルサービスチームおよびDatabase Freedom パートナーのネットワークを通した AWS への移行をサポートします。あらゆるデータベース技術を専門とするこれらのチームおよび組織では、数多くのデータベース、アプリケーション、データウェアハウスを AWS に移行してきた豊富な経験を活かしています。対象となるお客様には、移行にかかる費用負担を軽減するためのサービスクレジットも付与されます。

これまでに 3M、Verizon、Capital One、Intuit、Ryanair、Amazon.com などが Database Freedom のプログラムを活用しました。

Database Freedom の詳細については、こちらからお問い合わせください。