Cloudnexa has received formal recognition of our Microsoft Workloads on AWS Service Delivery by AWS. This important recognition validates our technical expertise and experience on running Microsoft workloads on AWS. Cloudnexa not only knows how to effectively manage Microsoft workloads on AWS, we are also skilled in migrating and optimizing them.

What is the AWS Service Delivery Program?

The program validates that AWS partners have a deep understanding of AWS services, demonstrated experience, and proven customer success.

The AWS Service Delivery Program is designed to validate AWS Partners that have a deep understanding of AWS services, demonstrated experience, and proven customer success in delivering these services to customers.

AWS Partners are technically validated for having experience delivering and providing consultancy on specific AWS services to our customers. From helping customers run serverless code with AWS Lambda to deploying managed, secure, reliable, and high-performing, Windows-based solutions on Amazon EC2 Windows, AWS Service Delivery Partners are equipped to assist AWS customers with specific AWS services.

How does this benefit our clients?

Cloudnexa has the right expertise and tools to help our clients seamlessly migrate and modernize their Microsoft workloads on the cloud.

With over a decade of unmatched experience, Cloudnexa has the right expertise and tools to help our clients seamlessly migrate and modernize their Microsoft workloads on the cloud. Clients can gain access to a broad selection of services with deep functionality and lower the overall costs of running their Microsoft workloads. Clients can increase or decrease capacity within minutes—not hours or days—and commission one, hundreds, or even thousands of server instances simultaneously. Clients can get stronger security, faster performance, and greater reliability with globally dispersed Availability Zones and fewer downtime hours.

Key benefits include:

  • Take advantage of the breadth of security, compliance, and governance services for safely running your Microsoft workloads on AWS.
  • Gain access to a broader selection of services with deeper functionality and globally disbursed Availability Zones for greater reliability when you migrate your Microsoft workloads to AWS.
  • Leverage Amazon EC2 instances compatible with your Microsoft workloads and configurations to meet your price-to-performance requirements.

Want to learn how we can help you? Contact us.

I’m excited to announce that AWS has renewed Cloudnexa’s Premier Partner status. Cloudnexa has one of the longest tenures as an AWS Premier partner in the industry as we’ve been a Premier partner continuously since 2013. This continues to bring many fantastic benefits to our clients.

What does it mean to be an AWS Premier Partner?

AWS Premier Tier Partners are the most experienced AWS Consulting Partners and are recognized as leaders.

AWS has three partner tiers: Select, Advanced, and Premier. The Premier status is the most challenging status to achieve in the AWS partner network. AWS Premier Tier Partners are the most experienced AWS Consulting Partners and are recognized as leaders in their respective geographical, vertical, or horizontal markets. The AWS Premier Tier Partners have deep technical expertise with multiple Partner program validations and demonstrated success working with a larger number of AWS customers at scale in deploying solutions on AWS.

AWS Premier partners have to:

  • Meet AWS certification requirements for engineers.
  • Show rapid client growth.
  • Demonstrate new business recurring revenue year-over-year.
  • Achieve high customer satisfaction levels, including new public reference customers.

Premier partners go through an AWS executive-level selection process and work closely with the entire AWS Partner Executive Team to prove their capabilities over at least a 6-month period. Less than 1% of partners achieve the AWS Premier Partner Tier status worldwide!

How do our clients benefit from our AWS Premier Partner status?

Less than 1% of AWS partners achieve the AWS Premier Partner Tier status worldwide.

Cloudnexa clients benefit from our AWS Premier Partner status in the following ways:

  • Validated trust: AWS has thoroughly validated Cloudnexa’s capabilities, so clients have peace of mind that they are in the right hands, whether they’re migrating to the cloud or optimizing their environment.
  • Additional AWS funding: Cloudnexa has more AWS funding capabilities available which saves our clients money.
  • Client advocacy: Cloudnexa is in a strong position to advocate for our clients as we have AWS executive relationship sponsorships. We can escalate issues when needed to ensure resolution for our clients.
  • Early Adopter Program: Cloudnexa can also help our customers get early access to AWS services through AWS’ Early Adopter Program.
  • Knowledge and expertise: Cloudnexa has extensive knowledge and expertise from a rapidly growing client base to share best practices and guide clients effectively on their journey.

Learn more about how we can help you by contacting us.

Need to lower your cloud costs? Want to optimize your licensing agreement costs, but not sure how? You can save thousands of dollars through Cloudnexa’s trusted guidance.

AWS Spend Optimization

There are a lot of wasted costs in most IT environments. These include end of life, overprovisioning, underutilizing, orphaned resources, upgrade options, time, and commitment. When you meet with Cloudnexa, we will help you identify immediate cost savings as well as longer-term cost savings in these categories.

Lowering Cloud Spend

Clients typically save 20%-60% through Cloudnexa’s strategic guidance.

To lower cloud spend, the first step is to evaluate your current IT environment. The following are key categories that we will review with you to identify potential cost savings:

  • End of life (EOL): There are two categories to assess end of life—Service and Software. For Service EOL, it’s important to evaluate sunsetting sizing as AWS offerings are continually updating. Some instances are EOL and are more expensive to run. It’s important to reassess to lower costs. For Software EOL, products may be under an old licensing agreement that is no longer valid and making changes can save you money.
  • Overprovisioning: When companies have an issue in their infrastructure, they often use hardware or services to solve the issue rather than identifying the root cause and solving the problem. This leads to an overprovisioned environment. We will help you identify if this is the case with your environment.
  • Underutilizing: Things change over time. Companies may have provisioned a certain number of instances, but might not be using all of them currently. Whatever you provision, you pay for. Cloudnexa will help you look for underutilized provisioning.
  • Orphaned resources: When companies are busy, it’s easy to forget about resources. For example, you may have spun up some instances for testing. While you no longer need them for operations, they may still be running. We will help identify these orphaned resources.
  • Upgrade Options: Who doesn’t love upgrades? Leveraging the newest AWS offering within a service may increase performance and lower costs. Cloudnexa will provide trusted guidance for these key decisions.
  • Time: Time is one of the most precious commodities in the IT world. Doing these checks yourself usually takes longer and can lead to wasted savings. Leveraging Cloudnexa’s expertise will ensure that you start saving faster.
  • Commitment: Making AWS commitments can save you money. But how to commit and the commitment amount is much more complex. Cloudnexa can review AWS savings plans and reserved instances, making sure you commit to the correct commitment levels to save money. We typically see clients save 20-50% instantly by committing to appropriate levels.

Optimizing Licensing Costs

Is your licensing agreement up for renewal? Go through a Cloudnexa review before you make any decisions. Optimized License Assessments (OLAs) save customers on average 38% of their licensing costs by right sizing their existing licenses. Running unsupported technology causes compliance issues, and custom support agreements are a costly way for customers to remain in compliance.

Cloudnexa can help you optimize your licensing costs by completing a review to ensure you purchase the proper number of cores. We can help you optimize the licenses that you’re using. Our neutral, third-party reviews include:

  • Microsoft enterprise and licensing agreements to understand license rule changes and impacts.
  • Leverage industry-leading tools to collect data and assess measurements.
  • Analysis of existing on-prem and AWS licensing positions and impacts.

Our OLA process is as follows:

  • Collect: Determine prospective customer workloads to optimize and collect utilization data for the underlying workloads.
  • Analyze: Analyze the data to model cost and licensing optimization scenarios.
  • Plan: Review the results and build a business case or start a migration proof of concept.

Well Architected Review

An AWS Well-Architected Review helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for their applications and workloads. Based on five pillars—operational excellence, security, reliability, performance efficiency, and cost optimization—an AWS Well-Architected Review provides a consistent approach for customers and partners to evaluate architectures and implement designs that can scale over time.

Framework Overview

The AWS Well-Architected Framework describes the key concepts, design principles, and architectural best practices for designing and running workloads in the cloud. By answering a set of foundational questions, you learn how well your architecture aligns with cloud best practices and are provided guidance for making improvements.

Cost Optimization Pillar

The cost optimization pillar focuses on avoiding unnecessary costs. Key topics include understanding and controlling where money is being spent, selecting the most appropriate and right number of resource types, analyzing spend over time, and scaling to meet business needs without overspending.

How to Start Saving Money

Customers who have engaged Cloudnexa have realized significant cost savings, improved their application performance, and eliminated risks.

Cloudnexa is an AWS Well-Architected Program partner and has in-depth training on the Well-Architected Framework. We can help you implement best practices, measure the state of your workloads, and make improvements where assistance is required. Customers who have engaged Cloudnexa have realized significant cost savings, improved the performance of their applications, and eliminated security risks and other high-risk issues.

We want our customers to have the best possible experience with cloud solutions. Follow our review process to make an informed decision:

1
Engage with Cloudnexa
2
AWS environment review
3
Present review findings
4
Schedule remediations

Learn more at https://www.cloudnexa.com/cloud-services/well-architected-reviews/ or schedule your review by contacting us.

Since the public release of AWS’s Elastic Compute Cloud (EC2) service, Cloudnexa has assisted customers with migrating their SQL Server infrastructures into the AWS cloud. Over the last decade, we’ve participated in countless projects of varying degree and difficulty and watched as the AWS ecosystem continuously evolves to provide increased compatibility for different SQL Server deployment models and migration methods.

Migration Methodologies

AWS provides a lot of flexibility when it comes to deployment options and target architectures for SQL Server workloads, but they can all be categorized as belonging to one of three general methodologies: Rehosting, Replatforming, and Refactoring.

Rehosting (Lift and Shift) is the relatively simple method of copying application and data bits from outside AWS into AWS. Classic examples include copying SQL Server database backups into a pre-provisioned AWS EC2 instance or moving self-contained virtual machines into a pre-configured target AWS account. Rehosting is probably the most common migration method due to its speed and relative simplicity. Most rehosting can be automated, although you may prefer to do this manually as you learn how to lift-and-shift your current SQL Server deployments to AWS.

Replatforming (Lift, Shift & Shape or Lift & Shape) is the compromise between Rehosting and Refactoring. When a SQL Server database is Replatformed in the cloud, it is modified to be more cloud-compatible, but without incurring too much change and risk. Replatforming to AWS RDS for SQL Server gives you a fully managed solution, decreased management overhead, single-click high availability, automated backups, the possibility for auto-scaled storage, and a number of easy migration options. Alternately, replatforming Microsoft SQL Server from Windows to Linux will save you on Windows licensing costs, while providing the same enterprise-ready platform with great performance and nearly the same number of supported features.

Refactoring is the most complex method of migrating to the cloud, the outcome being a fully cloud-native database. The effort and technical skills required to do this vary greatly but it is generally accepted that to successfully refactor you will need more advanced database and cloud aptitude than with any other migration method. An example refactoring target would be the AWS RDS Aurora platform. The target architectures in the remainder of this post specifically pertain to available options when following the Rehosting and Replatforming methodologies.

Target SQL Server Architectures on Amazon EC2

  • SQL Server Instance: A single implementation of SQL Server running on EC2 without any high availability capability.
  • SQL Server with Log Shipping: Log shipping lets you automatically send transaction log backups from a primary database instance to one or more secondary databases (also known as warm standby) on separate DB instances running on separate EC2 instances. Log shipping is often used as a disaster recovery solution but also can be used as a high availability solution.
  • SQL Server Transactional Replication: Transactional replication is a SQL Server technology that is used to replicate changes between two databases, including database objects like tables, stored procedures, views, and so on, as well as data. The replication process involves a publisher, a subscriber, and a distributor, all running on SQL instances on EC2.
  • SQL Server with Database Mirroring: Database mirroring takes a database located on an EC2 instance and provides a complete or almost complete read-only copy (mirror) of it on a separate DB instance, typically in a different availability zone (AZ). Note that although database mirroring is still available in SQL Server 2019, it is a deprecated feature which means it is no longer under active development and may be removed from a future version.
  • SQL Server Linked Servers: Linked servers allow you to join tables between database servers and distribute queries through stored procedures and views across servers, without needing to change your application source code or manage multiple connection strings in your web tier. Linked servers’ connectivity can be set up using combinations of on-premise SQL instances, SQL instances running on EC2, and AWS RDS SQL Server instances.
  • SQL Server on Linux: Starting with SQL Server 2017, SQL Server is available to run on Linux operating systems. Moving your SQL Server workloads to Linux provides both cost savings and performance improvements. SQL Server is currently supported on Red Hat Enterprise Server, SUSE Linux Enterprise Server, Ubuntu, and running in a container with Docker.
  • SQL Server Always On Availability Groups (AG)
    • Always On Basic Availability Groups: Starting with SQL Server 2016 SP1, SQL Server Standard edition provides basic high availability for a single, non-readable secondary database and listener per availability group. It also supports a maximum of two nodes per availability group with each node residing in a separate availability zone (AZ). Always On Basic Availability Groups replaces the deprecated Database Mirroring feature and provides a similar level of feature support.
    • Always On Availability Groups: SQL Server Always On availability groups is an advanced, enterprise-level feature to provide high availability and disaster recovery solutions. This feature is available if you are using SQL Server 2012 and later versions. It includes support for up to nine availability replicas, both asynchronous- and synchronous-commit modes, automatic and manual failover, readable secondary replicas, etc.
    • Distributed Availability Groups: A distributed availability group spans two separate availability groups. You can think of it as an availability group of availability groups. The underlying availability groups are configured on two different WSFC clusters. The availability groups that participate in a distributed availability group can be deployed across AWS regions.
  • SQL Server Always On Failover Cluster Instances (FCIs): An FCI is a single instance of SQL Server that is installed across Windows Server Failover Clustering nodes to provide high availability for the entire installation of SQL Server. If the underlying node experiences hardware, operating system, application, or service failures, everything inside the SQL Server instance is moved to another WSFC node. FCIs require some form of shared storage—disks on a storage area network (SAN), file shares on Server Message Blocks (SMBs), or locally attached storage with Storage Spaces Direct (S2D), SIOS Datakeeper, and most recently Amazon FSx—to provide resiliency and high availability. We will review the configuration and use of Amazon FSx for FCIs in an upcoming post.

Target SQL Server Architectures on AWS RDS

Amazon RDS supports DB instances running several versions and editions of Microsoft SQL Server, starting with SQL Server 2012. SQL Server Analysis Services (SSAS), Integration Services (SSIS), and Reporting Services (SSRS) are now also available on Single-AZ or Multi-AZ instances starting with Amazon RDS for SQL Server 2016 on both the Standard and Enterprise editions.

  • Single Availability Zone (AZ) QL Server Instance: A single SQL Server instance running on RDS without any high availability capability. All editions are supported (Express, Web, Standard, Enterprise).
  • Multi-AZ SQL Server Instances: Amazon RDS supports Multi-AZ deployments for DB instances running Microsoft SQL Server by using SQL Server Database Mirroring (DBM) or Always On Availability Groups (AGs). Multi-AZ deployments provide increased availability, data durability, and fault tolerance for DB instances. Amazon RDS supports Multi-AZ with Always On AGs for the following SQL Server versions and editions:
    • SQL Server 2019: Standard and Enterprise Editions
    • SQL Server 2017: Enterprise Edition 14.00.3049.1 or later
    • SQL Server 2016: Enterprise Edition 13.00.5216.0 or later

Amazon RDS supports Multi-AZ with DBM for the following SQL Server versions and editions, except for the versions noted previously:

  • SQL Server 2017: Standard and Enterprise Editions
  • SQL Server 2016: Standard and Enterprise Editions
  • SQL Server 2014: Standard and Enterprise Editions
  • SQL Server 2012: Standard and Enterprise Editions
  • SQL Server Read Replicas: SQL Server read replicase are available on the SQL Server Enterprise Edition engine for versions 2016-2019, and must be part of a multi-AZ deployment with Always On AGs. Up to five read replicas can be created from one source DB instance.

Migration Methods

Various methods are available to support migrating your SQL Server databases to AWS. Some of these most common methods and their characteristics are summarized in the following table:

In our next post, we will review the configuration and use of Amazon FSx for SQL Server FCIs, one of the more recent capabilities made available by AWS. Amazon FSx for Windows File Server provides fully managed, highly reliable, and scalable file storage that is accessible by using the Server Message Block (SMB) protocol, making it a suitable option to be used as shared storage in a Windows Server Failover Clustering node.

The content in this post references information from the following links. For additional details, please refer to these links:

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?view=sql-server-ver15

https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/ec2-sql-ha.html

https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.ReadReplicas.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.InstanceClasses

https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.SQLServer.Options.html

Deploying and managing SQL Server Always On Failover Cluster Instances (FCIs) in the cloud has traditionally required third-party software and a lot of overhead … until now. With the introduction of Amazon FSx for Windows File Server, we have a simple, AWS-native option for integrating fully managed, highly available shared storage to host our SQL databases.

Body:

As part of the SQL Server Always On offering, Always On Failover Cluster Instances (FCIs) leverage Windows Server Failover Clustering (WSFC) functionality to provide local high availability through redundancy at the server-instance level – namely a failover cluster instance (FCI). An FCI is a single instance of SQL Server that is installed across WSFC nodes, typically across multiple subnets and Availability Zones (AZs) in AWS. On the network, the FCI appears to be an instance of SQL Server running on a single computer. But the FCI actually provides failover from one WSFC node to another, if the active node becomes unavailable.

The SQL Server Always On FCI deployment option has been traditionally difficult to deploy and manage on AWS due to the shared storage requirement (shared storage needs to be accessible from all participating nodes). To get around this, a common deployment approach involved integrating third-party replication solutions such as SIOS DataKeeper or StarWind Virtual SAN, which allowed us to build the SQL Server cluster by simulating shared storage (disk data on the primary node was replicated to the secondary node). The solutions integrated with and extended WSFC functionality to manifest the FCI deployment scenario in AWS, but with increased management, overhead, and cost.

The introduction of AWS FSx for Windows File Server is a game changer. This fully managed service provides shared storage, can automatically replicate the data synchronously across two Availability Zones and provide high availability with automatic failure detection, failover and failback, and fully supports the SMB Continuous Availability (CA) feature. You can use Amazon FSx for Windows File Server as a shared storage tier for FCIs in two ways: as an SMB File Share Witness, and/or for Active SQL Server Data Files.

Using Amazon FSx as an SMB File Share Witness – WSFC deployments commonly deploy an SMB file share witness to maintain quorum of the cluster’s resources. The job of the witness is to provide an additional quorum vote when necessary to ensure that a cluster continues to run if there is a site outage. The witness file share can run on a Single-AZ file system and requires only a small amount of storage (32 GB should be sufficient) to hold quorum information (see diagram below).

Using Amazon FSx for Active SQL Server Data Files – Microsoft SQL Server can be deployed with an SMB file share as the storage option for active data files. Amazon FSx is optimized to provide shared storage by supporting continuously available (CA) file shares, which are specifically designed for applications like SQL Server that require uninterrupted access to shared file data. Note that it is required that you use CA shares on Multi-AZ file systems for all SQL Server deployments, whether HA or not. Amazon FSx provides file shares with the following characteristics and capabilities to host SQL Server databases:

  • Support for SMB versions 2.0 through 3.1.1.
  • Encryption in transit using SMB Kerberos.
  • Customizable performance (throughput and IOPS).
  • Multi-AZ deployment (HA) with support for SMB Continuous Availability (also known as SMB Transparent Failover).
  • Predictable cost with no charge for Inter-AZ data replication.
  • Single-AZ file system can be used as a target for SQL backups.

Configuration

The configuration of this setup is also significantly less complex than previous deployment methodologies. You can follow these high-level steps as a general guide:

  1. Create your domain-joined, Multi-AZ Amazon FSx file system.
  2. Determine your required file system characteristics.
  3. Determine applicable network settings.
  4. Select your Active Directory.
  5. Create the Microsoft SQL Server file share on your file system and set proper permissions and availability settings.
  6. Map a share (eg. D$) using the FSx systems’ DNS name and create a folder (eg. SQL) within it.
  7. Sett the ContinuouslyAvailable property of the file share to “True”.
  8. Grant SMB share permissions to the appropriate identities (the SQL service account, a global group for DBAs, and another Global Group in which all SQL Servers are members).
  9. Edit and set NTFS permissions, granting “Full Access” to the target folder to the same set of identities (the SQL service account, a global group for DBAs, and another Global Group in which all SQL Servers are members).
  10. Install SQL Server as failover cluster instance on the first node.
  11. Install SQL Server as failover cluster instance on the second node.

Benefits

There are several benefits in migrating to Amazon FSx for shared SQL storage which can apply to customers in many different use cases. Consider these scenarios:

  • Customers who use Enterprise Edition licenses to support AG groups can now use Standard Edition licenses which will save ~50–60% in license costs, not to mention simplifying the complexity and ongoing management of the SQL deployment (although you can run Basic AGs on SQL Server Standard Edition starting from SQL Server 2016, only one database per AG is supported which becomes a challenge when reconciling multiple databases, listeners and private IPs, EC2 instance type and ENI private IP constraints, etc.).
  • Customers with third-party storage replication solutions, will be able to save on licensing, administration and support, while simplifying and consolidating their technology footprint by using another AWS native service instead.
  • Customers with existing on-premise or hybrid deployments are likely using a combination of FCI and AG (FCI for high availability within a primary data center site, and AG to provide a disaster recovery solution across sites). AWS’s Availability Zone architecture and Amazon FSx’s support for highly available shared storage deployed across multiple Availability Zones now make it possible for them to eliminate the need for separate high availability and disaster recovery solutions, again reducing costs and simplifying deployment complexities.

For additional information on the technologies referenced in this article, please feel free to contact us directly. You can also reference this links:

https://aws.amazon.com/sql/

https://aws.amazon.com/fsx/windows/

https://docs.aws.amazon.com/fsx/latest/WindowsGuide/sql-server.html

https://www.sios-apac.com/tag/sql-server-failover-cluster-instance/

https://www.starwindsoftware.com/resource-library/starwind-virtual-san-aws-ec2-deployment-guide/

In this post, I’ll discuss why we migrated from WordPress to the JAMstack and never looked back. Later on, I’ll show you how to set up a JAMstack website with a headless CMS, AWS CloudFront, and S3 as a complete serverless stack.

A few months ago, our development team was tasked with building a quoting tool to facilitate the sales cycle. This feature would be similar to another module, in a different codebase. We’d want to reuse as much of this code as possible, as the module was quite complex.

After weighing out our options, we decided to port our existing WordPress website to the JAMstack. This decision not only included the new feature request, but concerns over security, cost, and maintenance of our current stack.

What is the JAMstack?

The JAMstack is an architecture designed to make websites faster, more secure, and easier to scale. It relieves the burden of patching, scaling, and maintaining any traditional servers.

What is a headless CMS?

A headless CMS (content management system) decouples the content and presentational layers. It provides content via an API, which any web or native applications can consume.

The 5 Pillars of the AWS Well-Architected Framework for JAMstack

It seems fitting to use the well-architected framework to discuss our migration decision.

1. Operational Excellence

The JAMstack architecture allows us to utilize our existing technologies and workflows which include:

  • Git — for version control, using a branch-based workflow
  • Build Tools — WebPack to help transpile, compile, lint, and optimize our code
  • CI/CD — to test, build and deploy our applications
  • CDN — AWS Cloudfront with an S3 origin

Using these battle-tested tools, we can make incremental changes with confidence.

2. Security

WordPress exposes many points of attack. Think SQL injection, outdated themes/plugins, and unauthorized logins.

While there are still concerns over any APIs you use, your production code comprises of read-only static files.

3. Reliability / 4. Performance Efficiency

JAMstack websites are pre-built during deployment. This means that the production site is static and serverless by default. We were able to reduce the complexity of maintaining and patching our old servers.

These sites can also be served entirely from a CDN providing unrivaled performance compared to a traditional server-side rendered webpage. CDNs are also redundant by nature and scale effortlessly.

5. Cost Optimization

By replacing our traditional servers with a simple CDN and S3 origin, we saw drastic cost savings per month.

Set up a Jamstack

Most Jamstack applications are composed of multiple services giving developers the opportunity to pick and choose the right tools for the job.

Our walkthrough stack will include:

Set up Gatsby

I covered how to set up a gatsby blog in a previous blog post. Please follow this link and instructions. Once finished, jump back here to continue.

Set up Contentful

Alright, we now have a working Gatsby Blog 🎉. The next step will be to migrate our blog to Contentful. Markdown is great for developers, but let’s give our team an easier interface to work with.

Sign up for Contentful

Head over to the signup page: https://www.contentful.com/sign-up/

Once you finished signing up, should you see a screen similar to this:

Setup our BlogPost content model

We’ll configure everything we need in Contentful, then jump back to Gatsby to finish the integration.

First, click on the “Content model” nav item.

Click the “Add content type” button.

Fill in the form and click the “Create” button.

Time to add some fields:

Let’s start by defining the Title of the blog post.

Click the Text option.

Fill in the form.

Add the Slug Field:

  1. Click “Add field” button (same step from Title field)
  2. Click “Text” option (same step from Title field)

Click the “Validation” tab nav item.

Add the Description Field:

  1. Click “Add field” button (same step from Title field)
  2. Click “Text” option (same step from Title field)

Add the Body Field:

  1. Click “Add field” button (same step from Title field)
  2. Click “Text” option (same step from Title field)

Save the content model.

Create our first blog post

Navigate to the content page and click “Add Blog Post”.

Fill out the content form.

Integrate Contentful into Gatsby

We now need to get Gatsby fetching data from Contentful. Luckily Gatsby has an official plugin to make this a breeze. I won’t give a step-by-step during this step, as I think Gatsby does a great job with their installation instructions.

Please follow this documentation to setup the gatsby-source-contentful plugin: https://www.gatsbyjs.com/plugins/gatsby-source-contentful/

Note: to find your space ID and access token go to Settings > API keys > click on “Example Key 1”. From there you should be able to copy your keys.

Modify codebase

We’ll need to update these 3 files:

  • gatsby-node.js: used during the build process to create a page for each contentful blog post
  • src/pages/index.js: to display a list of blog posts
  • src/template/blog-post.js: to show each individual blog post

To see all necessary changes, please review this commit: https://github.com/frankhock/hot-new-blog/commit/41084c53f522e01a023f1f4c1ecba1c5e3b919a5

Set up AWS Amplify Hosting

We’ve saved the best for last. It’s time to deploy our application.

To get started, navigate to this url: https://aws.amazon.com/amplify/hosting/

Click the “Get started for free” button.

If you’ve been following along up until this point, good job. If not, you can clone the demo repository from here: https://github.com/frankhock/hot-new-blog

When ready, click GitHub as our repo source, then click “Continue”.

Select your repository from the select menu, then your branch, and lastly click “Next”.

Amplify will auto-detect our Gatsby site and generate the correct settings. So nothing to do there. Click on “Advanced settings” then type in our CONTENTFUL_ACCESS_TOKEN environment variable key/value. Once finished, click “Next”.

On the Review page, click “Save and deploy”.

At this point, Amplify will redirect you to your application dashboard page and you should see your application provisioning. We’re almost there.

After 3-4 minutes, you should see all build steps turn green. We’re now live.

Click the link on the screenshot to view your new deployed blog. Nice job!

Wrapping Up

While I hope you learned how to get a simple blog up and running using Gatsby and AWS Amplify, I recommend learning more about benefits of the JAMstack.

Below are some great resources to check out: