All posts by Betsy Chernoff

Configuring and using monitoring and notifications in Amazon Lightsail

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/configuring-and-using-monitoring-and-notifications-in-amazon-lightsail/

This post is contributed by Mike Coleman | Developer Advocate for Lightsail | Twitter: @mikegcoleman

We recently announced the release of resource monitoring, alarms, and notifications for Amazon Lightsail. This new feature allows you to set alarm thresholds on your Lightsail instances, databases, and load balancers. When those alarm thresholds are breached, you can be notified via the Lightsail console, SMS text message, and/or email.

In this blog, I walk you through the process of setting your notification contacts, creating a new alarm, and testing out the notifications. Additionally, you can simulate a failure to see how that is represented in the metrics graph, console, and notification endpoints.

The alarm you create during this blog notifies you whenever there are two or fewer healthy instances attached to your load balancer. In a production workload, this is a fairly critical scenario. So, you can configure Lightsail to notify you as soon as it discovers the problem.

Prerequisites
To complete this walkthrough, you need three running Lightsail instances, placed behind a Lightsail load balancer. If you need with help getting that done, check out our documentation on instances and load balancers. Don’t worry about what’s running on your instance, it’s not important for the sake of this walkthrough.

Configuring notification contacts
To get started, create notification contacts for both email and SMS. You can create one email contact per AWS Region where Lightsail operates. If you find that you need to notify multiple people via email, you can create an email distribution list with those contacts. Then, set Lightsail to send the email notification to that distribution list.

For SMS, you can only create contacts in specific Regions. For an up-to-date list of those Regions, go here:

Let’s get started creating the notification contacts. First, log into the AWS Management Console, navigate to the Lightsail home page, and follow the steps below.

  1. Click Account near the top right of the Lightsail home page, and click account from the dropdown menu.Image showing the location of the account drop down 
  2. Scroll down to the Notification contacts section and click + Add email address. Ensure that the correct AWS Region is selected. Image showing the location of the region drop down on the add regional email contact dialogue box
  3. Enter the email address where you want Lightsail to send alarm notifications in the text box.
  4. Click Add contact. Then, click I understand. This signifies that you understand that a verification email is sent to the email address you entered, and that notifications are not sent to that address until it’s verified.You verify your email address in the next section.
  5. Scroll down and click + Add SMS number, and ensure that the correct AWS Region is selected.
  6. Choose the country/Region for the phone number you want to use (note: this can be different than your AWS Region), and enter the mobile number you want to receive notifications at.
  7. Click Add contact.

Verifying the notification contact email address

Return to the Lightsail home page. There should be a banner at the top of the page notifying you that your email address must be verified.

  1. Access the email account that you set up in the previous section. You should find an email with the subject AWS Notification – Subscription Confirmation
  2. Open the email.
  3. In the email body near the bottom there is a link to click to verify your email address. Click the verification link. A webpage loads, which lets you know that your email address was successfully verified.Image showing the location of the confirm subscription link in the verification email
  4. Refresh the Lightsail home page, and the verification banner should now be gone.

Creating an alarm

Now you have your notification contacts set. It’s time to create the actual alarm. An alarm is defined by choosing a metric to monitor, and defining a threshold value and schedule for evaluation.

In our example today, we’re going to look at the healthy host count metric. As the name implies, this metric tells us how many healthy hosts are connected to our Lightsail load balancer. In this example, there are three instances attached to the load balancer, and you want to know if one of them becomes unhealthy as soon as possible.  In other words, when there are two or fewer healthy instances.

Lightsail reports metrics every five minutes. So the cadence you set to be notified is the first time the metric reports back unhealthy in any five-minute window. Follow the steps below to configure the alarm.

  1. From the Lightsail home page click on Networking from the horizontal menu, and then click on the name of your load balancer.
  2. From the horizontal menu click on Metric.
  3. Ensure that Healthy host count is selected from the metric dropdown menu.
  4. Scroll down the page and click +Add alarm
  5. Use the dialog box and drop-down menu to set the threshold for healthy host count to Less than or equal to 2. Set the time values so that an alarm is raised if the threshold is exceeded 1 time within the last 5 minutes.
  6. Leave the check boxes checked for SMS and email notifications.
  7. The alarm is created, but Lightsail may display a message indicating that the alarm is in insufficient data state. This disappears in a few minutes.

Test to make sure that you actually receive a notification when the alarm threshold is breached.

  1. To test that the notifications are configured correctly, click the three dot menu for your alarm. Image showing the location of the three dot menu
  2. From the drop down menu, choose Test alarm notification. After a minute or two, you should get both a text and an email notification.

Triggering the alarm with a simulated instance failure

So, at this point you have an alarm set, and you know that the notifications are working properly. In this final, step you simulate a failure to ensure that it’s detected correctly by Lightsail. That the alarm then sends the appropriate notifications.

To simulate a failure, you’re simply going to stop one of the instances attached to your load balancer by following the steps below.

  1. Return to the Lightsail home page.
  2. Click on the three dot menu for one of your instances and click
  3. Click Stop again to confirm.
  4. Return to the Load Balancers metrics page, and notice that after a few minutes the graph shows a drop in the healthy host count. Shortly after the graph updates the alarm should breach, and you should receive your text and email notifications.Note: Since our alarm threshold is evaluated after 5 minutes, it may take a few minutes for the alarm to trigger and notifications to be sent.
  5. Once you receive your text and/or email notifications, return to the Lightsail home page. Notice there is also a notification banner at the top of the page.
  6. Click on the three dot menu for the instance you previously stopped, and click Start.
  7. Return the load balancer metrics screen and wait for the graph to update and show three healthy instances. You may need to refresh your web browser.

As mentioned previously you can create alarms for a wide variety of metrics across databases, load balancers, and instances. For a complete list of metrics, check out the Lightsail documentation.

Conclusion

So, that’s all there is to it. If you spun up new instances for this simulation, make sure to terminate those to eliminate extra costs. If you’ve already got some critical resources running in Lightsail, now is a good time to set up some alarms and notifications. If you don’t have anything currently running in Lightsail, why not take advantage of our free 30-day offer for Lightsail instances, and build something today. Need more? Reach out to me @mikegcoleman, and check out Lightsail’s landing page for other resources and tutorials.

It just got easier to discover and compare EC2 instance types

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/it-just-got-easier-to-discover-and-compare-ec2-instance-types/

Since 2007 we have introduced over 200 different instance types. Some of which include the new sizes of C5d and EC2 High Memory instances that were recently made available. This broad selection means that you get better price and performance for a wide variety of workloads. With over 200 instances to choose from, finding the right instance type can be challenging. To make it easier for customers to discover and compare EC2 Instance Types, we now have a new “Instance Types” section of the EC2 Console and two new APIs: DescribeInstanceTypes and DescribeInstanceTypeOfferings. With this offering, you have access to instance type specifications, supported features, Regional presence, pricing, and more.

Until now, cloud architects and DevOps engineers needed to reference multiple data sources and test multiple instance types before making a selection. This process was time consuming and needed to be repeated for each new workload and to continue to optimize existing workloads as needs evolved and new EC2 instance types and features were released. Now there is a single source of information for all instance types, enabling customers to compare options and have the latest information easily accessible, both programmatically and in the EC2 Console.

This blog walks you through how to take advantage of these new offerings so that you can find the right instance type for your workload. I demonstrate how to use filters to get a list of instance types that meet your requirements. I also show how to compare instance type to quickly identify the differences. Sample commands are included to help you get started with the AWS Command Line Interface.

Compare Instance Types

In the following steps, I walk through how to navigate the EC2 Console, so that you can find and compare instance types that meet your requirements.

  1. First, navigate to the new “Instance Types” section.

 

2. If needed, customize the information shown in the table by clicking the gear icon and toggle on or off attributes. This allows you to see

only the information that is important to you.

 

 

 

 

 

 

 

 

 

3. Next, to limit the list to only instance types that meet your workload requirement, search or set filters in the search bar. You can input search terms directly or use filters to filter specific attributes.

For example, setting “Current generation” to “true” displays only current generation instance types. Typing in the term “metal” limits results to only .metal instance types.  Ranges can be set using the “max” and “min” filters. For example, the “Min Memory (MiB)” filter limits the list to only instance type with at least the minimum memory required.

    

  1. To see all attributes for one instance type, click the check box in the leftmost column. To compare multiple instance types, select them all.

For example, in the following image I selected the three least expensive options that met my criteria.  The selected instances are shown side-by-side in the detail pane for easier comparison. The bold text in the detail pane highlights attributes that that are different between the compared instance types.

Access Instance Type information programmatically

This console experience is powered by the new APIs: DescribeInstanceTypes and DescribeInstanceTypeOfferings. You can use these APIs individually or in combination to return information about a specific instance type or to return instance types that meet your specifications.

Here are a few examples to get you started:

 

Similar to how you set filters in the console, the API responses can also be filtered. For example, the following command in the AWS CLI returns all current generation instance types.

aws ec2 describe-instance-types  --filter Name=current-generation,Values=true

You can also filter using partial strings. This comes in handy for fields with multiple parts. For example, the following command in the AWS CLI returns all C5d instance types. A partial string is needed because the instance type field also includes additional postscripts and the size.

aws ec2 describe-instance-types  —filter Name=instance-type,Values=c5d*

DescribeInstanceTypeOfferings can be called to verify that your preferred instance types are offered in a particular region. The following command in the AWS CLI returns a list of all instance types available in your current Region.

aws ec2 describe-instance-type-offerings

You can add this filter to limit the response to only instance types you are considering.

--filter Name=instance-type,Values=i3.metal,m5.metal,z1d.metal

Conclusion

More accessible instance type information makes it easier for you to discover and compare instance types and stay up to date on the latest offerings. It’s now quicker to get started with new workloads and to optimize the instance types used for running workloads. This is available in all commercial AWS regions. Read the documentation to learn more. Please feel free to leave your comments below!

Deploying a highly available WordPress site on Amazon Lightsail, Part 4: Increasing performance and scalability with a Lightsail load balancer

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/deploying-a-highly-available-wordpress-site-on-amazon-lightsail-part-4-increasing-performance-and-scalability-with-a-lightsail-load-balancer/

This post is contributed by Mike Coleman | Developer Advocate for Lightsail | Twitter: @mikegcoleman

This is the final post in a series about getting a highly available WordPress site up and running on Amazon Lightsail. For reference, the other blog posts are:

  1. Implementing a highly available Lightsail database with WordPress
  2. Using Amazon S3 with WordPress to securely deliver media files
  3. Increasing security and performance using Amazon CloudFront

In this post, you’ll learn how to stand up a Lightsail load balancer, create a snapshot of your WordPress server, deploy new instances from those snapshots, and place the instances behind your load balancer.

A load balancer accepts incoming web traffic and routes it to one or (usually) more servers. Having multiple servers allows you to scale the number of incoming requests your site can handle, as well as allowing your site to remain responsive if a web server fails. The following diagram shows the solution architecture, which features multiple front-end WordPress servers behind a Lightsail load balancer, a highly available Lightsail database, and uses S3 alongside CloudFront to deliver your media content securely.

Graphic showing the final HA architecture including 3 servers behind a load balancer, S3 alongside cloudfront, and a highly-available database

Prerequisites

This post assumes you built your WordPress site by following the previous posts in this series.

Configuring SSL requires a registered domain name and sufficient permissions to create DNS records for that domain.

You don’t need AWS or Lightsail to manage your domain, but this post uses Lightsail’s DNS management. For more information, see Creating a DNS zone to manage your domain’s DNS records in Amazon Lightsail.

Deploying the load balancer and configuring SSL

To deploy a Lightsail load balancer and configure it to support SSL, complete the following steps:

  1. Open the Lightsail console.
  2. From the menu, choose Networking.
  3. Choose Create Load Balancer.
  4. For Identify your load balancer, enter a name for your load balancer.

This post names the load balancer wp-lb.

  1. Choose Create Load Balancer.

The details page for your new load balancer opens. From here, add your initial WordPress server to the load balancer and configure SSL.

  1. For Target instances, choose your WordPress server.

The following screenshot indicates that this post chooses the server WordPress-1.

screenshot showing an instance being selected from the drop down

 

  1. Choose Attach.

It can take a few seconds for your instance to attach to the load balancer and the Health Check to report as Passed. See the following screenshot of the Health Check status.

 Picture of healh check status

  1. From the menu, choose Inbound traffic.
  2. Under Certificates, choose Create certificate.
  3. For PRIMARY DOMAIN, enter the domain name that you want to use to reach your WordPress site.

You can either accept the default certificate name Lightsail creates or change it to something you prefer. This post uses www.mikegcoleman.com.

  1. Choose Create.

The following screenshot shows the Create a certificate section.

Picture of the Create a Certificate section

Creating a CNAME record

As you did with CloudFront, you need to create a CNAME record as a way of validating that you have ownership of the domain for which you are creating a certificate.

  1. Copy the random characters and the subdomain from the name field.

The following screenshot shows the example record information.

screenshot showing the portion of the name value that needs to be copied

  1. Open a second copy of the Lightsail console in another tab or window.
  2. Choose Networking.
  3. Choose your domain name.
  4. Choose Add record.
  5. From the drop-down menu, choose CNAME record.

The following screenshot shows the drop-down menu options.

Screenshot showing CNAME record selected in the dropdown box

  1. For Subdomain, enter the random characters and subdomain you copied from the load balancer page.
  2. Return to the load balancer page.
  3. Copy the entire Value
  4. Return to the DNS page.
  5. For Maps to, enter the value string.
  6. Choose the green check box.

The following screenshot shows the CNAME record details.

Screenshot showing the completed cname record and green checkbox highlighted

  1. Return to the load balancer page and wait a few minutes before refreshing the page.

You should see a notification that the certificate is verified and ready to use. This process can take several minutes; continue refreshing the page every few minutes until the status updates. The following screenshot shows the notification message.

Screenshot showing the verification complete message for the load balancer ssl certificate

  1. In the HTTPS box, select your certificate from the drop-down menu.

The following screenshot shows the HTTPS box.

screenshot showing the newly validated certificate in the drop down box

  1. Copy the DNS name for your load balancer.

The following screenshot shows the example DNS name.

Screenshot showing the DNS name of the load balancer

  1. Return to the Lightsail DNS console and follow steps 13 through 23 as a guide in creating a CNAME record that maps your website address to the load balancer’s DNS name.

Use the subdomain you chose for your WordPress server (in this post, that’s www) and the DNS name you copied for the Maps to field.

The following screenshot shows the CNAME record details.

screenshot showing the completed cname record for the load balancer

Updating the wp-config file

The last step to configure SSL is updating the wp-config file to configure WordPress to deliver content over SSL.

  1. Start an SSH session with your WordPress server.
  2. Copy and paste the following code into the terminal window to create a temporary file that holds the configuration string that will be added to the WordPress configuration file.
cat <<EOT >> ssl_config.txt
if (\$_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') \$_SERVER['HTTPS']='on';
EOT
  1. Copy and paste the following sed command into your terminal window to add the SSL line to the configuration file.
sed -i "/define( 'WP_DEBUG', false );/r ssl_config.txt" \
/home/bitnami/apps/wordpress/htdocs/wp-config.php
  1. The sed command changes the permissions on the configuration file, so you’ll need to reset them. See the following code:
sudo chown bitnami:daemon /home/bitnami/apps/wordpress/htdocs/wp-config.php

You also need to update two variables that WordPress uses to identify which address is used to access your site.

  1. Update the WP_SITEURL variable (be sure to specify https) by running the following command in the terminal window:
wp config set WP_SITEURL https://<your wordpress site domain name>

For example, this post uses the following code:

wp config set WP_SITEURL https://www.mikegcoleman.com

You should get a response that the variable updated.

  1. Update the WP_HOME variable (be sure to specify https) by issuing the following command in the terminal window:
wp config set WP_HOME https://<your wordpress site domain name>

For example, this post uses the following code:

wp config set WP_HOME https://www.mikegcoleman.com

You should get a response that the variable updated.

  1. Restart the WordPress server to read the new configuration with the following code:
sudo /opt/bitnami/ctlscript.sh restart

After the server has restarted, visit the DNS name for your WordPress site. The site should load and your browser should report the connection is secure.

You can now finish any customization of your WordPress site, such as adding additional plugins, setting the blog name, or changing the theme.

Scaling your WordPress servers

With your WordPress server fully configured, the last step is to create additional instances and place them behind the load balancer so that if one of your WordPress servers fails, your site is still reachable. An added benefit is that your site is more scalable because there are additional servers to handle incoming requests.

Complete the following steps:

  1. On the Lightsail console, choose the name of your WordPress server.
  2. Choose Snapshots.
  3. For Create instance snapshot, enter the name of your snapshot.

This post uses the name WordPress-version-1. See the following screenshot of your snapshot details.

Screenshot of the snapshot creation dialog

  1. Choose Create snapshot.

It can take a few minutes for the snapshot creation process to finish.

  1. Click the three-dot menu icon to the right of your snapshot name and choose Create new instance.

The following screenshot shows the Recent snapshots section.

Screenshot showing the location of the three dot menu

To provide the highest level of redundancy, deploy each of your WordPress servers into a different Availability Zone within the same region. By default, the first server was placed in zone A; place the subsequent servers in two different zones (B and C would be good choices). For more information, see Regions and Availability Zones.

  1. For Instance location, choose Change AWS Region and Availability Zone.
  2. Choose Change your Availability Zone.
  3. Choose an Availability Zone you have not used previously.

The following screenshot shows the Availability Zones to choose from.

screenshot showing availability zone b selected

  1. Give your instance a new name.

This post names the instance WordPress-2.

  1. Choose Create Instance.

You should have at least two WordPress server instances to provide a minimum degree of redundancy. To add more, create additional instances by following steps 1–10.

Return to the Lightsail console home page, and wait for your instances to report back Running.

Adding your instances to the load balancer

Now that you have your additional WordPress instances created, add them to the load balancer. This is the same process you followed previously to add the first instance:

  1. On the Lightsail console, choose Networking.
  2. Choose the load balancer you previously created.
  3. Choose Attach another.
  4. From the drop-down menu, select the name of your instance.

The following screenshot shows the available instances on the drop-down menu.

screenshot showing the WordPress instances in the load balancer drop down

  1. Choose Attach.
  2. Repeat steps 3–5 for any additional instances.

When the instances report back Passed, your site is fully up and running.

Conclusion

You have configured your site to provide a good degree of redundancy and performance, while delivering your content over secure connections. S3 and CloudFront allow your site to deliver static content over a secured connection, while the Lightsail load balancer and database make sure your site can keep serving your customers in the event of a failure.

If you haven’t got one already, head on over and create a free AWS account, and start building your own WordPress site – or whatever else might think of!

Deploying a Highly available WordPress site on Amazon Lightsail, Part 3: Increasing security and performance using Amazon CloudFront

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/deploying-a-highly-available-wordpress-site-on-amazon-lightsail-part-3-increasing-security-and-performance-using-amazon-cloudfront/

This post is contributed by Mike Coleman | Developer Advocate for Lightsail | Twitter: @mikegcoleman

The previous posts in this series (Implementing a highly available Lightsail database with WordPress and Using Amazon S3 with WordPress to securely deliver media files), showed how to build a WordPress site and configure it to use Amazon S3 to serve your media assets. The next step is to use an Amazon CloudFront distribution to increase performance and add another level of security.

CloudFront is a content delivery network (CDN). It essentially caches content from your server on endpoints across the globe. When someone visits your site, they hit one of the CloudFront endpoints first. CloudFront determines if the requested content is cached. If so, CloudFront responds to the client with the requested information. If the content isn’t cached on the endpoint, it is loaded from the actual server and cached on CloudFront so subsequent requests can be served from the endpoint.

This process speeds up response time, because the endpoint is usually closer to the client than the actual server, and it reduces load on the server, because any request that CloudFront can handle is one less request your server needs to deal with.

In this post’s configuration, CloudFront only caches the media files stored in your S3 bucket, but CloudFront can cache more. For more information, see How to Accelerate Your WordPress Site with Amazon CloudFront.

Another benefit of CloudFront is that it responds to requests over HTTPS. Because some requests are served by the WordPress server and others from CloudFront, it’s important to secure both connections with HTTPS. Otherwise, the customer’s web browser shows a warning that the site is not secure. The next post in this series shows how to configure HTTPS for your WordPress server.

Solution overview

To configure CloudFront to work with your Lightsail WordPress site, complete the following steps:

  1. Request a certificate from AWS Certificate Manager.
  2. Create a CloudFront distribution.
  3. Configure the WP Offload Media Lite plugin to use the CloudFront distribution.

The following diagram shows the architecture of this solution.

Image showing WordPress architecture with Lightsail, CloudFront, S3, and a Lightsail database

Prerequisites

This post assumes that you built your WordPress site by following the previous posts in this series.

Configuring SSL requires that you have a registered domain name and sufficient permissions to create DNS records for that domain.

You don’t need AWS or Lightsail to manage your domain, but this post uses Lightsail’s DNS management. For more information, see Creating a DNS zone to manage your domain’s DNS records in Amazon Lightsail.

Creating the SSL certificate

This post uses two different subdomains for your WordPress site. One points to your main site, and the other points to your S3 bucket. For example, a customer visits https://www.example.com to access your site. When they click on a post that contains a media file, the post body loads off of https://www.example.com, but the media file loads from https://media.example.com, as depicted in the previous graphic.

Create the SSL certificate for CloudFront to use with the S3 bucket with the following steps. The next post in this series shows how to create the SSL certificate for your WordPress server.

  1. Open the ACM console.
  2. Under Provision certificates, choose Get started.
  3. Choose Request a public certificate.
  4. Choose Request a certificate.
  5. For Domain name*, enter the name of the domain to serve your media files.

This post uses media.mikegcoleman.com.

  1. Choose Next.

The following screenshot shows the example domain name.

Screen shot showing domain name dialog

  1. Select Leave DNS validation.
  2. Choose Review.
  3. Choose Confirm and request.

ACM needs you to validate that you have the necessary privileges to request a certificate for the given domain by creating a special DNS record.

Choose the arrow next to the domain name to show the values for the record you need to create. See the following screenshot.

Screen shot showing verification record

You now need to use Lightsail’s DNS management to create the CNAME record to validate your certificate.

  1. In a new tab or window, open the Lightsail console.
  2. Choose Networking.
  3. Choose the domain name for the appropriate domain.
  4. Under DNS records, choose Add record.
  5. From the drop-down menu, choose CNAME record.

The following screenshot shows the menu options.

Screen shot showing CNAME record selected in dropdown box

  1. Navigate back to ACM.

Under Name, the value is formatted as randomcharacters.subdomain.domain.com.

  1. Copy the random characters and the subdomain.

For example, if the value was _f836d9f10c45c6a6fbe6ba89a884d9c4.media.mikegcoleman.com, you would copy _f836d9f10c45c6a6fbe6ba89a884d9c4.media.

  1. Return to the Lightsail DNS console.
  2. Under Subdomain, enter the value you copied.
  3. Return to the ACM console.
  4. For Value, copy the entire string.
  5. Return to the Lightsail DNS console.
  6. For Maps to, enter the value you copied.
  7. Choose the green checkmark.

The following screenshot shows the completed record details in the Lightsail DNS console.

screen shot showing where the green checkmark is and completed domain record

ACM periodically checks DNS to see if this record exists, and validates your certificate when it finds the record. The validation usually takes approximately 15 minutes; however, it could take up to 48 hours.

To track the validation, return to the ACM console. You can periodically refresh this page until you see the status field change to Issued. See the following screenshot.

Screenshot highlighting the updated status of the domain validation

Building the CloudFront distribution

Now that you have the certificate, you’re ready to create your CloudFront distribution. Complete the following steps:

  1. Open the CloudFront console.
  2. Choose Create distribution.
  3. Under Web, choose Get Started.
  4. For Origin Domain Name, select the S3 bucket you created for your WordPress media files.

The following screenshot shows the options available in the Origin Domain Name drop-down menu. This post chooses mike-wp-bucket-s3-amazonaws.com.

Screenshot of the S3 bucket selected from the Origin Domain Name dialog

By default, WordPress does not pass information that indicates when to clear an item in the cache; specifying how to configure that functionality is out of the scope of this post.

Because WordPress doesn’t send this information, you need to set a default time to live (TTL) in CloudFront.

As a starting point, set the value to 900 seconds (15 minutes). This means that if you load a post, and that post includes media, CloudFront checks the cache for that media. If the media is in the cache, but has been there longer than 15 minutes, CloudFront requests the media from your WordPress server and update the cache.

While 15 minutes is a reasonable starting value for media, the optimal value for the TTL depends on how you want to balance delivering your clients the latest content with performance and cost.

  1. For Object Caching, choose Customize.
  2. For Default TTL, enter 900.

The following screenshot shows the TTL options.

Image of TTL options

CloudFront has endpoints across the globe, and the price you pay depends on the number of endpoints you have configured. If your traffic is localized to a certain geographic region, you may want to restrict which endpoints CloudFront uses.

  1. Under Distribution Settings, for Price Class, choose the appropriate setting.

This post chooses Use All Edge Locations. See the following screenshot. You should choose a setting that make sense for your site. Choosing only a subset of price classes will reduce costs.

Screenshot showing the choices for price classes

  1. For Alternate Domain Names (CNAMEs), enter the name of the subdomain for your S3 bucket.

This name is the same as the subdomain you created the certificate for in the previous steps. This post uses media.mikegcoleman.com.

Assign the certificate you created earlier.

  1. Choose Custom SSL Certificate.

When entering in the text field, the certificate you created earlier shows in the drop-down menu.

  1. Choose your certificate.

The following screenshot shows the drop-down menu with custom SSL certificates.

Screenshot showing the previously created SSL certificate being selected

  1. Choose Create Distribution.

It can take 15–30 minutes to configure the distribution.

The next step is to create a DNS record that points your media subdomain to the CloudFront distribution.

  1. Return to the CloudFront console, choose the ID of the distribution.

The following screenshot shows available distribution IDs.

screen shot showing the distribution ID highlighted

The page displays the distribution ID details.

  1. Copy the Domain Name

The following screenshot shows the distribution ID details.

Screenshot showing the domain name highlighted in the distribution details

  1. Return to the Lightsail DNS console.
  2. Choose Add record.
  3. Choose CNAME record.
  4. For Subdomain, enter the subdomain you are using for the S3 bucket.

This post is using the domain media.mikegcoleman.com, so the value is media. 

  1. For Maps to, enter the domain name of the CloudFront distribution that you previously copied.

The following screenshot shows the CNAME record details.

Screenshot of the completed DNS CNAME record

  1. Choose the green check box.
  2. Return to the CloudFront console.

It can take 15–30 minutes for the distribution status to change to Deployed. See the following screenshot.

Screenshot of the updated CloudFront distribution status

Configuring the plugin

The final step is to configure the WP Offload Media Lite plugin to use the newly created CloudFront distribution. Complete the following steps:

  1. Log in to the admin dashboard for your WordPress site.
  2. Under Plugins, choose WP Offload Media Lite.
  3. Choose Settings.
  4. For Custom Domain (CNAME), select On.
  5. Enter the domain name for your S3 bucket.

This post uses media.mikegcoleman.com as an example.

  1. For Force HTTPS, select On.

This makes sure that all media is served over HTTPS.

  1. Choose Save Changes.

The following screenshot shows the URL REWRITING and ADVANCED OPTIONS details.

Screenshot of the cloud distribution network settings in the S3 plugin

You can load an image from your media library to confirm that everything is working correctly.

  1. Under Media, choose Library.
  2. Choose an image in your library.

If you don’t have an image in your library, add a new one now.

The URL listed should start with the domain you configured for your S3 bucket. For this post, the URL is media.mikegcoleman.com.

The following screenshot shows the image details.

Screenshot highlighting the URL of the S3 asset

To confirm that the image loads correctly, and there are no SSL errors or warnings, copy the URL value and paste it into your web browser.

Conclusion

You now have your media content served securely from CloudFront. The final post in this series demonstrates how to create multiple instances of your WordPress server and place those behind a Lightsail load balancer to increase performance and enhance availability.

If you haven’t got one already, head on over and create a free AWS account, and start building your own WordPress site – or whatever else might think of!

Deploying a highly available WordPress site on Amazon Lightsail, Part 2: Using Amazon S3 with WordPress to securely deliver media files

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/deploying-a-highly-available-wordpress-site-on-amazon-lightsail-part-2-using-amazon-s3-with-wordpress-to-securely-deliver-media-files/

This post is contributed by Mike Coleman | Developer Advocate for Lightsail | Twitter: @mikegcoleman

This is the second post in a series focusing on how to build a highly available WordPress site on Amazon Lightsail. The first post, Implementing a highly available Lightsail database, explained how to deploy a WordPress instance with a standalone MySQL database on Lightsail. The post also discussed how both the database and web server’s file system store WordPress data.

This post shows you how WordPress stores shared media files (such as pictures and videos) on Amazon S3. S3 is a managed storage service that provides an affordable, performant, and secure method for storing a variety of data. This post interfaces between WordPress and S3 with the WP Offload Media Lite plugin from Delicious Brains. The plugin takes any file uploaded to WordPress and copies it over to S3, where your other WordPress instances can access it.

Prerequisites

This post requires that you have deployed your WordPress instance and configured it to work with a standalone MySQL database in Lightsail. For more information, see the first post in this series.

Because this post uses additional AWS services beyond Lightsail, you need an AWS account with sufficient privileges to the rest of AWS.

Solution overview

This solution includes the following steps:

  1. Create an AWS IAM user.
  2. Update the WordPress configuration file with those user credentials.
  3. Install and configure the actual plugin.
  4. Test the solution by uploading an image to WordPress.

Creating an IAM User

To relocate your media files to S3, WordPress needs credentials proving it has the correct permissions. You create those credentials by adding a new IAM user and assigning that user a role that includes the necessary S3 permissions. After creating the credentials, add them to your WordPress configuration file.

  1. Open the AWS Management Console.
  2. Navigate to the IAM Console.
  3. From the Dashboard, choose Users.

The following screenshot shows the Dashboard pane.

Users selection from the IM menu in WordPress

 

 

4. At the top of the page, choose Add user.

The following screenshot shows the Add user button.

Add User button highlighted

 

 

 

 

5. In Set user details, for User name, enter a name.

This post uses the name wp-s3-user.

6. For Access type, select Programmatic access.

The following screenshot shows the Set user details section.

Set user details

7. Choose Next: Permissions. 

8. Choose Attach existing policy directly.

9. In the Filter polices field, enter S3.

10. From the search results, select AmazonS3FullAccess.

11. From the search results, select AmazonS3FullAccess.

The following screenshot shows the Set permissions section.Set permissions.

  1. Choose Next: Tags.
  2. Choose Next: Review.
  3. Choose Create user.

The page displays the credentials you need to configure the WP Offload Media Lite plugin.

  1. Under Secret access key, select Show.
  2. Save the Access Key ID and Secret Access Key for reference.

To download a CSV file with the key information, choose the Download .csv file button.

If you navigate away from this screen, you can’t obtain the credentials again and need to create a new user. Be sure to either download the CSV or record both values in another document. Treat these credentials the same way you’d treat any sensitive username/password pair.

Connecting to your WordPress instance

Connect to your WordPress instance by using your SSH client or the web-based SSH client in the Lightsail console.

  1. In the terminal prompt for your WordPress instance, set two environment variables (ACCESS_KEY and SECRET_KEY) that contain the credentials for your IAM user.

To set the environment variables, substitute the values for your IAM user’s access key and secret key into the following lines and enter each command one at a time at the terminal prompt:

ACCESS_KEY=AKIAIOSFODNN7EXAMPLE

SECRET_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

The next step is to update your WordPress configuration file (wp-config) with the credentials.

  1. Enter the following command:

cat <<EOT >> credfile.txt
define( 'AS3CF_SETTINGS', serialize( array (
  'provider' => 'aws',
  'access-key-id' => '$ACCESS_KEY',
  'secret-access-key' => '$SECRET_KEY',
) ) );
EOT

This command creates a file with the credentials to insert into the configuration file.

  1. Enter the following sed command:

sed -i "/define( 'WP_DEBUG', false );/r credfile.txt" \
/home/bitnami/apps/wordpress/htdocs/wp-config.php

This command inserts the temporary file you created into the WordPress configuration file.

It changes the permissions on the WordPress configuration file.

  1. To reset the permissions, enter the following code:

sudo chown bitnami:daemon /home/bitnami/apps/wordpress/htdocs/wp-config.php

  1. Restart the services on the instance by entering the following command:

sudo /opt/bitnami/ctlscript.sh restart

After the services restart, your WordPress instance is configured to use the IAM credentials and you are ready to configure the WP Offload Media Lite plugin.

Installing and configuring the plugin

Now that the configuration file holds your credentials, you can move on to installing and configuring the plugin.

The next step requires you to log in to the WordPress dashboard, and to do that you need the Bitnami application password for your WordPress site. It’s stored at /home/bitnami/bitnami_application_password.

  1. Enter the following cat command in the terminal to display the password value:

cat /home/bitnami/bitnami_application_password

  1. Log in to the administrator control panel of your WordPress site.

You can access the WordPress login screen at http://SiteIpAddress/wp-admin, where SiteIpAddress is the IP address of your WordPress instance, which you can find on the card for your instance in the Lightsail console.

The following screenshot shows the location of the IP address.

Site IP Address inside the Lightsail Console

For example, the instance in the preceding screenshot has the IP address 192.0.2.0; you can access the login screen using http://192.0.2.0/wp-admin.

  1. For login credentials, the default user name is user.
  2. For the password, use the Bitnami application password you recorded previously.

After signing in, install and configure the WP Offload Media Lite plugin by following these steps:

  1. Under Plugins, choose Add New.

The following screenshot shows the navigation pane.

Navigation pain in WordPress

  1. On the Add New pane, in the Keyword field, enter WP media offload.

The following screenshot shows the Keyword search bar.

Keyword Searchbar in WordPress

  1. The results display the WP Offload Media Lite plugin.
  2. Choose Install Now.

The following screenshot shows the selected plugin.

WP media offload plugin

After a few seconds, the Install Now button changes to Activate.

  1. Choose Activate.

The main WordPress plugins screen opens.

  1. Scroll down to WP Offload Media Lite.
  2. Choose Settings.

The following screenshot shows the selected plugin.

  1. From the Settings page, choose Create new bucket.

An S3 bucket is a unique container that stores all your WordPress files.

The following screenshot shows the Media Library options for your plugin.

Media Library options for your plugin

  1. For Region, select the Region that matches the Region of your WordPress instance.

This post uses the Region US West (Oregon). The following screenshot shows the selected Region.

AWS Region in S3

The following screenshot from the Lightsail console shows your displayed Region.

Region in Lightsail console

  1. Enter a name for your S3 bucket.
  2. Choose Create New Bucket.

Your WordPress website is now configured to upload files to the S3 bucket managed by the WP Offload Media Lite plugin.

Troubleshooting

If you received an error indicating that access to your S3 was denied, check the public permissions for S3 by following these steps:

  1. Open the S3 console.
  2. From the menu, choose Block public access (account settings).
  3. Choose Edit.
  4. Clear Block all public access.
  5. Choose Save.
  6. In the text box, enter confirm.
  7. Choose Confirm.

This setting ensures that none of your buckets are publicly accessible. If you clear the setting, make sure to verify that permissions are set correctly on your buckets.

  1. Return to the WordPress console, and refresh the Offload Media Lite page.

You should no longer see the error.

  1. Choose Save Changes.

Testing the plugin

To confirm that the plugin is working correctly, upload a new media file and verify it’s being served from the S3 bucket.

  1. From the WordPress console, choose Media, Add new.

The following screenshot shows the WordPress console menu.

  1. Upload a file by either dragging and dropping a file into the field, or choosing Select and selecting a file from your local machine.
  2. After the file uploads, choose Edit.

The following screenshot shows the Edit option on the plugin thumbnail.

In the Edit Media pane, the File URL should point to your S3 bucket. See the following screenshot.

WordPress console menu

  1. Copy that URL into a browser and confirm your file loads correctly.

Conclusion

In this post you learned how to install and configure the Media Offload Lite plug-in. Your media files are now centrally served out of S3. You are ready to finalize the look and feel of your site and scale out the front end. A subsequent post in this series explores that process.

Deploying a highly available WordPress site on Amazon Lightsail, Part 1: Implementing a highly available Lightsail database with WordPress

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/deploying-a-highly-available-wordpress-site-on-amazon-lightsail-part-1-implementing-a-highly-available-lightsail-database-with-wordpress/

This post is contributed by Mike Coleman | Developer Advocate for Lightsail

This post walks you through what to consider when architecting a scalable, redundant WordPress site. It discusses how WordPress stores such elements as user accounts, posts, settings, media, and themes, and how to configure WordPress to work with a standalone database.

This walkthrough deploys a WordPress site on Amazon Lightsail. Lightsail is the easiest way to get started on AWS, and it might be the easiest (and least expensive) way to get started on WordPress. You can launch a new WordPress site in a few clicks with one of Lightsail’s blueprints, for a few dollars a month. This gives you a single Lightsail instance to host your WordPress site that’s perfect for a small personal blog.

However, you may need a more resilient site capable of scaling to meet increased demand and architected to provide a degree of redundancy. If you’re a novice cloud user, the idea of setting up a highly available WordPress implementation might seem daunting. But with Lightsail and other AWS services, it doesn’t need to be.

Subsequent posts in this series cover managing media files in a multi-server environment, using CloudFront to increase site security and performance, and scaling the WordPress front-end with a Lightsail load balancer.

What’s under the hood?

Even though you’re a WordPress user, you may not have thought about how WordPress is built. However, if you’re moving into managing your WordPress site, it’s essential to understand what’s under the hood. As a content management system (CMS), WordPress provides a lot of functionality; this post focuses on some of the more essential features in the context of how they relate to architecting your highly available WordPress site.

WordPress manages a variety of different data. There are user accounts, posts, media (such as images and videos), themes (code that customizes the look and feel of a given WordPress site), plugins (code that adds additional functionality to your site), and configuration settings.

Where WordPress stores your data varies depending on the type of data. At the most basic level, WordPress is a PHP application running on a web server and database. The web server is the instance that you create in Lightsail, and includes WordPress software and the MySQL database. The following diagram shows the Lightsail VPC architecture.

Lightsail's VPC Architecture

The database stores a big chunk of the data that WordPress needs; for example, all of the user account information and blog posts. However, the web server’s file system stores another portion of data; for example, a new image you upload to your WordPress server. Finally, with themes and plugins, both the database and the file system store information. For example, the database holds information on what plugins and which theme is currently active, but the file system stores the actual code for the themes and plugins.

To provide a highly available WordPress implementation, you need to provide redundancy not only for the database, but also the content that may live on the file system.

Prerequisites

This solution has the following prerequisites:

This post and the subsequent posts deal with setting up a new WordPress site. If you have an existing site, the processes to follow are similar, but you should consult the documentation for both Lightsail and WordPress. Also, be sure to back up your existing database as well as snapshot your existing WordPress instance.

Configuring the database

The standalone MySQL database you created is not yet configured to work with WordPress. You need to create the actual database and define the tables that WordPress needs. The easiest method is to export the table from the database on your WordPress instance and import it into your standalone MySQL database. To do so, complete the following steps:

  1. Connect to your WordPress instance by using your SSH client or the web-based SSH client in the Lightsail console. The screenshot below highlights the icon to click.

WordPress icon for connecting through SSH

  1. From the terminal prompt for your WordPress instance, set two environment variables (LSDB_USERNAME and LSDB_ENDPOINT) that contain the connection information for your standalone database.

You can find that information on the database’s management page from the Lightsail console. See the following screenshot of the Connection details page.

the Connection details page

  1. To set the environment variables, substitute the values for your instance into the following code example and input each line one at a time at the terminal prompt:

LSDB_USERNAME=UserName

LSDB_ENDPOINT=Endpoint

For example, your input should look similar to the following code:

LSDB_USERNAME=dbmasteruser

LSDB_ENDPOINT=ls.rds.amazonaws.com

  1. Retrieve the Bitnami application password for the database running on your WordPress instance.

This password is stored at /home/bitnami/bitnami_application_password.

Enter the following cat command in the terminal to display the value:

cat /home/bitnami/bitnami_application_password

  1. Copy and paste the following code into a text document and copy the password

cat /home/bitnami/bitnami_application_password

You need this password in the following steps.

  1. Enter the following command into the terminal window:

mysqldump \

 -u root \

--databases bitnami_wordpress \

--single-transaction \

--order-by-primary \

-p > dump.sql

This command creates a file (dump.sql) that defines the database and all the needed tables.

  1. When prompted for a password, enter the Bitnami application password you recorded previously.

The terminal window doesn’t show the password as you enter it.

Now that you have the right database structure exported, import that into your standalone database. You’ll do this by entering the contents of your dump file into the mysql command line.

  1. Enter the following command at the terminal prompt:

cat dump.sql | mysql \

--user $LSDB_USERNAME \

--host $LSDB_ENDPOINT \

-p

  1. When prompted for a password, enter the password for your Lightsail database.

The terminal window doesn’t show the password as you enter it.

  1. Enter the following mysql command in the instance terminal:

echo 'use bitnami_wordpress; show tables' | \

mysql \

--user $LSDB_USERNAME \

--host $LSDB_ENDPOINT \

-p

This command shows the structure of the WordPress database, and verifies that you created the database on your Lightsail instance successfully.

  1. When prompted for a password, enter the password for your standalone database.

You should receive the following output:

Tables_in_bitnami_wordpress

wp_commentmeta

wp_comments

wp_links

wp_options

wp_postmeta

wp_posts

wp_term_relationships

wp_term_taxonomy

wp_termmeta

wp_terms

wp_usermeta

wp_users

This test confirms that your standalone database is ready for you to use with your WordPress instance.

Configuring WordPress

Now that you have the standalone database configured, modify the WordPress configuration file (wp-config.php) to direct the WordPress instance to use the standalone database instead of the database on the instance.

The first step is to back up your existing configuration file. If you run into trouble, copy wp-config.php.bak over to wp-config.php to roll back any changes.

  1. Enter the following code:

cp /home/bitnami/apps/wordpress/htdocs/wp-config.php /home/bitnami/apps/wordpress/htdocs/wp-config.php.bak

You are using wp-cli to modify the wp-config file.

  1. Swap out the following values with those for your Lightsail database:

wp config set DB_USER UserName

wp config set DB_PASSWORD Password

wp config set DB_HOST Endpoint

The following screenshot shows the example database values.

example database values

For example:

wp config set DB_USER dbmasteruser

wp config set DB_PASSWORD ‘MySecurePassword!2019’

wp config set DB_HOST ls.rds.amazonaws.com

To avoid issues with any special characters the password may contain, make sure to wrap the password value in single quotes (‘).

  1. Enter the following command:

wp config list

The output should match the values on the database’s management page in the Lightsail console. This confirms that the changes went through.

  1. Restart WordPress by entering the following command:

sudo /opt/bitnami/ctlscript.sh restart

Conclusion

This post covered a lot of ground. Hopefully it educated and inspired you to sign up for a free AWS account and start building out a robust WordPress site. Subsequent posts in this series show how to deal with your uploaded media and scale the web front end with a Lightsail load balancer.

Building a pocket platform-as-a-service with Amazon Lightsail

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/building-a-pocket-platform-as-a-service-with-amazon-lightsail/

This post was written by Robert Zhu, a principal technical evangelist at AWS and a member of the GraphQL Working Group. 

When you start a new web-based project, you figure out wha kind of infrastructure you need. For my projects, I prioritize simplicity, flexibility, value, and on-demand capacity, and find myself quickly needing the following features:

  • DNS configuration
  • SSL support
  • Subdomain to a service
  • SSL reverse proxy to localhost (similar to ngrok and serveo)
  • Automatic deployment after a commit to the source repo (nice to have)

new projects have different requirements compared to mature projects

Amazon Lightsail is perfect for building a simple “pocket platform” that provides all these features. It’s cheap and easy for beginners and provides a friendly interface for managing virtual machines and DNS. This post shows step-by-step how to assemble a pocket platform on Amazon Lightsail.

Walkthrough

The following steps describe the process. If you prefer to learn by watching videos instead, view the steps by watching the following: Part 1, Part 2, Part 3.

Prerequisites

You should be familiar with: Linux, SSH, SSL, Docker, Nginx, HTTP, and DNS.

Steps

Use the following steps to assemble a pocket platform.

Creating a domain name and static IP

First, you need a domain name for your project. You can register your domain with any domain name registration service, such as Amazon Route53.

  1. After your domain is registered, open the Lightsail console, choose the Networking tab, and choose Create static IP.

Lightsail console networking tab

  1. On the Create static IP page, give the static IP a name you can remember and don’t worry about attaching it to an instance just yet. Choose Create DNS zone.

 

  1. On the Create a DNS zone page, enter your domain name and then choose Create DNS zone. For this post, I use the domain “raccoon.news.DNS zone in Lightsail with two A records
  2. Choose Add Record and create two A records—“@.raccoon.news” and “raccoon.news”—both resolving to the static IP address you created earlier. Then, copy the values for the Lightsail name servers at the bottom of the page. Go back to your domain name provider, and edit the name servers to point to the Lightsail name servers. Since I registered my domain with Route53, here’s what it looks like:

Changing name servers in Route53

Note: If you registered your domain with Route53, make sure you change the name server values under “domain registration,” not “hosted zones.” If you registered your domain with Route53, you need to delete the hosted zone that Route53 automatically creates for your domain.

Setting up your Lightsail instance

While you wait for your DNS changes to propagate, set up your Lightsail instance.

  1. In the Lightsail console, create a new instance and select Ubuntu 18.04.

Choose OS Only and Ubuntu 18.04 LTS

For this post, you can use the cheapest instance. However, when you run anything in production, make sure you choose an instance with enough capacity for your workload.

  1. After the instance launches, select it, then click on the Networking tab and open two additional TCP ports: 443 and 2222. Then, attach the static IP allocated earlier.
  2. To connect to the Lightsail instance using SSH, download the SSH key, and save it to a friendly path, for example: ~/ls_ssh_key.pem.

Click the download link to download the SSH key

  • Restrict permissions for your SSH key:

chmod 400 ~/ls_ssh_key.pem

  • Connect to the instance using SSH:

ssh -i ls_ssh_key.pem [email protected]_IP

  1. After you connect to the instance, install Docker to help manage deployment and configuration:

sudo apt-get update && sudo apt-get install docker.io
sudo systemctl start docker
sudo systemctl enable docker
docker run hello-world

  1. After Docker is installed, set up a gateway using called the nginx-proxy container. This container lets you route traffic to other containers by providing the “VIRTUAL_HOST” environment variable. Conveniently, nginx-proxy comes with an SSL companion, nginx-proxy-letsencrypt, which uses Let’s Encrypt.

# start the reverse proxy container
sudo docker run --detach \
    --name nginx-proxy \
    --publish 80:80 \
    --publish 443:443 \
    --volume /etc/nginx/certs \
    --volume /etc/nginx/vhost.d \
    --volume /usr/share/nginx/html \
    --volume /var/run/docker.sock:/tmp/docker.sock:ro \
    jwilder/nginx-proxy

# start the letsencrypt companion
sudo docker run --detach \
    --name nginx-proxy-letsencrypt \
    --volumes-from nginx-proxy \
    --volume /var/run/docker.sock:/var/run/docker.sock:ro \
    --env "DEFAULT_EMAIL=YOUREMAILHERE" \
    jrcs/letsencrypt-nginx-proxy-companion

# start a demo web server under a subdomain
sudo docker run --detach \
    --name nginx \
    --env "VIRTUAL_HOST=test.EXAMPLE.COM" \
    --env "LETSENCRYPT_HOST=test.EXAMPLE.COM" \
    nginx

Pay special attention to setting a valid email for the DEFAULT_EMAIL environment variable on the proxy companion; otherwise, you’ll need to specify the email whenever you start a new container. If everything went well, you should be able to navigate to https://test.EXAMPLE.COM and see the nginx default content with a valid SSL certificate that has been auto-generated by Let’s Encrypt.

A publicly accessible URL served from our Lightsail instance with SSL support

Troubleshooting:

Deploying a localhost proxy with SSL

Most developers prefer to code on a dev machine (laptop or desktop) because they can access the file system, use their favorite IDE, recompile, debug, and more. Unfortunately, developing on a dev machine can introduce bugs due to differences from the production environment. Also, certain services (for example, Alexa Skills or GitHub Webhooks) require SSL to work, which can be annoying to configure on your local machine.

For this post, you can use an SSL reverse proxy to make your local dev environment resemble production from the browser’s point of view. This technique also helps allow your test application to make API requests to production endpoints with Cross-Origin Resource Sharing restrictions. While it’s not a perfect solution, it takes you one step closer toward a frictionless dev/test feedback loop. You may have used services like ngrok and serveo for this purpose. By running a reverse proxy, you won’t need to spread your domain and SSL settings across multiple services.

To run a reverse proxy, create an SSH reverse tunnel. After the reverse tunnel SSH session is initiated, all network requests to the specified port on the host are proxied to your dev machine. However, since your Lightsail instance is already using port 22 for VPS management, you need a different SSH port (use 2222 from earlier). To keep everything organized, run the SSH server for port 2222 inside a special proxy container. The following diagram shows this solution.

Diagram of how an SSL reverse proxy works with SSH tunneling

Using Dockerize an SSH service as a starting point, I created a repository with a working Dockerfile and nginx config for reference. Here are the summary steps:

git clone https://github.com/robzhu/nginx-local-tunnelcd nginx-local-tunnel

docker build -t {DOCKERUSER}/dev-proxy . --build-arg ROOTPW={PASSWORD}

# start the proxy container
# Note, 2222 is the port we opened on the instance earlier.
docker run --detach -p 2222:22 \
    --name dev-proxy \
    --env "VIRTUAL_HOST=dev.EXAMPLE.com" \
    --env "LETSENCRYPT_HOST=dev.EXAMPLE.com" \
    {DOCKERUSER}/dev-proxy

# Ports explained:
# 3000 refers to the port that your app is running on localhost.
# 2222 is the forwarded port on the host that we use to directly SSH into the container.
# 80 is the default HTTP port, forwarded from the host
ssh -R :80:localhost:3000 -p 2222 [email protected]

# Start sample app on localhost
cd node-hello && npm i
nodemon main.js

# Point browser to https://dev.EXAMPLE.com

The reverse proxy subdomain works only as long as the reverse proxy SSH connection remains open. If there is no SSH connection, you should see an nginx gateway error:

Nginx will return 502 if you try to access the reverse proxy without running the SSH tunnel

While this solution is handy, be extremely careful, as it could expose your work-in-progress to the internet. Consider adding additional authorization logic and settings for allowing/denying specific IPs.

Setting up automatic deployment

Finally, build an automation workflow that watches for commits on a source repository, builds an updated container image, and re-deploys the container on your host. There are many ways to do this, but here’s the combination I’ve selected for simplicity:

  1. First, create a GitHub repository to host your application source code. For demo purposes, you can clone my express hello-world example. On the Docker hub page, create a new repository, click the GitHub icon, and select your repository from the dropdown list.Create GitHub repo to host your application source code
  2. Now Docker watches for commits to the repo and builds a new image with the “latest” tag in response. After the image is available, start the container as follows:

docker run --detach \
    --name app \
    --env "VIRTUAL_HOST=app.raccoon.news" \
    --env "LETSENCRYPT_HOST=app.raccoon.news" \
    robzhu/express-hello

  1. Finally, use Watchtower to poll dockerhub and update the “app” container whenever a new image is detected:

docker run -d \
    --name watchtower \
    -v /var/run/docker.sock:/var/run/docker.sock \
    containrrr/watchtower \
    --interval 10 \
    APPCONTAINERNAME

 

Summary

Your Pocket PaaS is now complete! As long as you deploy new containers and add the VIRTUAL_HOST and LETSENCRYPT_HOST environment variables, you get automatic subdomain routing and SSL termination. With SSH reverse tunneling, you can develop on your local dev machine using your favorite IDE and test/share your app at https://dev.EXAMPLE.COM.

Because this is a public URL with SSL, you can test Alexa Skills, GitHub Webhooks, CORS settings, PWAs, and anything else that requires SSL. Once you’re happy with your changes, a git commit triggers an automated rebuild of your Docker image, which is automatically redeployed by Watchtower.

I hope this information was useful. Thoughts? Leave a comment or direct-message me on Twitter: @rbzhu.

Optimizing NGINX load balancing on Amazon EC2 A1 instances

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/optimizing-nginx-load-balancing-on-amazon-ec2-a1-instances/

This post is contributed by Geoff Blake | Sr System Development Engineer

In a previous post, Optimizing Network Intensive Workloads on Amazon EC2 A1 Instances, I provided general guidance on tuning network-intensive workloads on A1 instances using Memcached as the example use case.

NGINX is another network-intensive application that, like Memcached, is a good fit for the A1 instances. This post describes how to configure NGINX as a load balancer on A1 for optimal performance using Amazon Linux 2, highlighting the important tuning parameters. You can extract up to a 30% performance benefit with these tunings over the default configuration on A1. However, depending on the particular data rates, processing required per request, instance size, and chosen AMI, the values in this post could change for your particular scenario. However, the methodologies described here are still applicable.

IRQ affinity and receive packet steering

Turning off irqbalance, pinning IRQs, and distributing network processing to specific cores helps the performance of NGINX when it runs on A1 instances.

Unlike Memcached in the previous post, NGINX does not benefit from using receive packet steering (RPS) to spread network processing among all cores or isolating processing to a subset of cores. It is better to allow NGINX access to all cores, while keeping IRQs and network processing isolated to a subset of cores.

Using a modified version of the script from the previous post, you can set IRQs, RPS, and NGINX workers to the following mappings. Finding the optimal balance of IRQs, RPS, and worker mappings can benefit performance by up to 10% on a1.4xlarge instances.

Instance typeIRQ settingsRPS settingsNGINX workers
a1.2xlargeCore 0, 4Core 0, 4Run on cores 0-7
a1.4xlargeCore 0, 8Core 0, 8Run on cores 0-15

NGINX access logging

For production deployments of NGINX, logging is critically important for monitoring the health of servers and debugging issues.

On large a1.4xlarge instance types, logging each request can become a performance bottleneck in certain situations. To alleviate this issue, tune the access_log configuration with the buffer modifier. Only a small amount of buffering is necessary to avoid logging becoming a bottleneck, on the order of 8 KB. This tuning parameter alone can give a significant boost of 20% or more on a1.4xlarge instances, depending on the traffic profile.

Additional Linux tuning parameters

The Linux networking stack is tuned to conserve resources for general use cases. When running NGINX as a load balancer, the server must be tuned to give the network stack considerably more resources than the default amount, for the prevention of dropped connections and packets. Here are the key parameters to tune:

  • core.somaxcon: Maximum number of backlogged sockets allowed. Increase this to 4096 or more to prevent dropping connection requests.
  • ipv4.tcp_max_syn_backlog: Maximum number of outstanding SYN requests. Set this to the same value as net.core.somaxconn.
  • ipv4.ip_local_port_range: To avoid prematurely running out of connections with clients, set to a larger ephemeral port range of 1024 65535.
  • core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem, net.ipv4.tcp_mem: Socket and TCP buffer settings. Tune these to be larger than the default. Setting the maximum buffer sizes to 8 MB should be sufficient.

Additional NGINX configuration parameters

To extract the most out of an NGINX load balancer on A1 instances, set the following  NGINX parameters higher than their default values:

 

  • worker_processes: Keeping this set to the default of auto works well on A1.
  • worker_rlimit_nofile: Set this to a high value such as 65536 to allow many connections and access to files.
  • worker_connections: Set this to a high value such as 49152 to cover most of the ephemeral port range.
  • keepalive_requests: The number of requests that a downstream client can make before a connection is closed. Setting this to a reasonably high number such as 10000 helps prevent connection churn and ephemeral port exhaustion.
  • Keepalive: Set to a value that covers your total number of backends plus expected growth, such as 100 in your upstream blocks to keep connections open to your backends from each worker process.

Summary

Using the above tuning parameters versus the defaults that come with Amazon Linux 2 and NGINX can significantly increase the performance of an NGINX load balancing workload by up to 30% on the a1.4xlarge instance type. Similar, but less dramatic performance gains were seen on the smaller a1.2xlarge instance type as well. If you have questions about your own workload running on A1 instances, contact us at [email protected].

 

Why AWS is the best place for your Windows workloads, and how Microsoft is changing their licensing to try to awkwardly force you into Azure

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/why-aws-is-the-best-place-for-your-windows-workloads-and-how-microsoft-is-changing-their-licensing-to-try-to-awkwardly-force-you-into-azure/

This post is contributed by Sandy Carter, Vice President at AWS. It is also located on LinkedIn

Many companies today are considering how to migrate to the cloud to take advantage of the agility and innovation that the cloud brings. Having the right to choose the best provider for your business is critical.

AWS is the best cloud for running your Windows workloads and our experience running Windows applications has earned our customers’ trust. It’s been more than 11 years since AWS first made it possible for customers to run their Windows workloads on AWS—longer than Azure has even been around, and according to a report by IDC, we host nearly two times as many Windows Server instances in the cloud as Microsoft. And more and more enterprises are entrusting their Windows workloads to AWS because of its greater reliability, higher performance, and lower cost, with the number of AWS enterprise customers using AWS for Windows Server growing more than 400% in the past three years.

In fact, we are seeing a trend of customers moving from Azure to AWS. eMarketer started their digital transformation with Azure, but found performance challenges and higher costs that led them to migrate all of their workloads over to AWS. Why did they migrate? They found a better experience, stronger support, higher availability, and better performance, with 4x faster launch times and 35% lower costs compared to Azure. Ancestry, a leader in consumer genomics, went all-in on development in the cloud moving 10 PB data and 400 Windows-based applications in less than 9 months. They also modernized to Linux with .NET Core and leveraged advanced technologies including serverless and containers. With results like that, you can see why organizations like Sysco, Edwards Life Sciences, Expedia, and NextGen Healthcare have chosen AWS to upgrade, migrate, and modernize their Windows workloads

If you are interested in seeing your cost savings over running on-premises or over running on Azure,  send us an email at [email protected] or visit why AWS is the best cloud for Windows.

Deploying an Nginx-based HTTP/HTTPS load balancer with Amazon Lightsail

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/deploying-an-nginx-based-http-https-load-balancer-with-amazon-lightsail/

In this post, I discuss how to configure a load balancer to route web traffic for Amazon Lightsail using NGINX. I define load balancers and explain their value. Then, I briefly weigh the pros and cons of self-hosted load balancers against Lightsail’s managed load balancer service. Finally, I cover how to set up a NGINX-based load balancer inside of a Lightsail instance.

If you feel like you already understand what load balancers are, and the pros and cons of self-hosted load balancers vs. managed services, feel free to skip ahead to the deployment section.

What is a load balancer?

Although load balancers offer many different functionalities, for the sake of this discussion, I focus on one main task: A load balancer accepts your users’ traffic and routes it to the right server.

For example, if I assign the load balancer the DNS name: www.example.com, anyone visiting the site first encounters the load balancer. The load balancer then routes the request to one of the backend servers: web-1, web-2, or web-3. The backend servers then respond to the requestor.

A load balancer provides multiple benefits to your application or website. Here are a few key advantages:

  • Redundancy
  • Publicly available IP addresses
  • Horizontally scaled application capacity

Redundancy

Load balancers usually front at least two backend servers. Using something called a health check, they ensure that these servers are online and available to service user requests. If a backend server goes out of service, the load balancer stops routing traffic to that instance. By running multiple servers, you help to ensure that at least one is always available to respond to incoming traffic. As a result, your users aren’t bogged down by errors from a downed machine.

Publicly available IP addresses

Without a load balancer, a server requires a unique IP address to accept an incoming request via the internet. There are a finite number of these IP addresses, and most cloud providers limit the number of statically assigned public IP addresses that you can have.

By using a load balancer, you can task a single public IP address with servicing multiple backend servers. Later in this post, I return to this topic as I discuss configuring a load balancer.

Horizontally scaled application capacity

As your application or website becomes more popular, its performance may degrade. Adding additional capacity can be as easy as spinning up a new instance and placing it behind your load balancer. If demand drops, you can spin down any unneeded instances to save money.

Horizontal scaling means the deployment of additional identically configured servers to handle increased load. Vertical scaling means the deployment of a more powerful server to handle increased load. If you deploy an underpowered server, expect poor performance, whether you have a single server or ten.

Self-managed load balancer vs. a managed service

Now that you have a better understanding of load balancers and the key benefits that they provide, the next question is: How can you get one into your environment?

On one hand, you could spin up a Lightsail load balancer. These load balancers are all managed by AWS and don’t require any patching or maintenance on your part to stay up-to-date. You only need to name your load balancer and pick instances to service. Your load balancer is then up and running. If you’re so inclined, you can also get a free SSL (secure socket layer) certificate with a few extra clicks.

Lightsail load balancers deploy easily and require essentially no maintenance after they’re operational, for $18 per month (at publication time). Lightsail load balancer design prioritizes easy installation and maintenance. As a result, they lack some advanced configuration settings found with other models.

Consequently, you might prefer to configure your load balancer if you prioritize configuration flexibility or cost reduction. A self-hosted load balancer provides access to many advanced features, and your only hard cost is the instance price.

The downsides of self-hosting are that you are also responsible for the following:

  • Installing the load balancer software.
  • Keeping the software (and the host operating system) updated and secure.

Deploying a NGINX-based load balancer with Lightsail

Although many software-based load balancers are available, I recommend building a solution on NGINX because this wildly popular tool:

  • Is open source/free.
  • Offers great community support.
  • Has a custom Lightsail blueprint.

Prerequisites

This tutorial assumes that you already have your backend servers deployed. These servers should all:

  • Be identically configured.
  • Point to a central backend database.

In other words, the target servers shouldn’t each have database copies installed.

To deploy a centralized database, see Lightsail’s managed database offering.

Because I’ve tailored these instructions to generic website and web app hosting, they may not work with specific applications such as WordPress.

Required prerequisites

Before installing an optional SSL certificate, you need to have the following:

  • A purchased domain name.
  • Permissions to update the DNS servers for that domain.

Optional prerequisites

Although not required, the following prerequisites may also be helpful:

  • Familiarity with accessing instances via SSH.
  • Using basic LINUX commands. 

Deploy an NGINX instance

To begin, deploy an NGINX instance in Lightsail, choosing the NGINX blueprint. Make sure that you are deploying it into the same Region as the servers to load balance.

Choose an appropriate instance size for your application, being aware of the amount of RAM and CPU, as well as the data transfer. If you choose an undersized instance, you can always scale it up via a snapshot. However, an oversized instance cannot as easily be scaled down. You may need to rebuild the load balancer on a smaller-sized instance from scratch.

Configure HTTP load balancing

In the following steps, edit the NGINX configuration file to load balance HTTP requests to the appropriate servers.

First, start up an SSH session with your new NGINX instance and change into the appropriate configuration directory:

cd /opt/bitnami/nginx/conf/bitnami/

Make sure that you have the IP addresses for the servers to load balance. In most cases, traffic shouldn’t flow from your load balancer to your instances across the internet. So, make sure to use the instance’s private IP address. You can find this information on the instance management page, in the Lightsail console.

In this example, my three servers have the following private IP addresses:

  • 192.0.2.67
  • 192.0.2.206
  • 192.0.2.198

The configuration file to edit is named bitnami.conf. Open it using your preferred text editor (use sudo to edit the file):

sudo vi bitnami.conf

Clear the contents of the file and add the following code, making sure to substitute the private IP addresses of the servers to load balance:

# Define Pool of servers to load balance upstream webservers { 
server 192.0.2.67 max_fails=3 fail_timeout=30s; 
server 192.0.2.206 max_fails=3 fail_timeout=30s;
server 192.0.2.198 max_fails=3 fail_timeout=30s;
}

In the code, you used the keyword upstream to define a pool (named webservers) of three servers to which NGINX should route traffic. If you don’t specify how NGINX should route each request, it defaults to round-robin server routing. Two other routing methods are available:

  • Least connected, which routes to the server with the fewest number of active connections.
  • IP hash, which uses a hashing function to enable sticky sessions (otherwise called session persistence).

Discussion on these methods is out of scope for this post. For more information, see Using nginx as HTTP load balancer.

Additionally, I recommend max_fails and fail_timeout to define health checks. Based on the configuration above, NGINX marks a server as down if it fails to respond or responds with an error three times in 30 seconds. If a server is marked down, NGINX continues to probe every 30 seconds. If it receives a positive response, it marks the server as live.

After the code you just inserted to the file, add the following:

# Forward traffic on port 80 to one of the servers in the webservers group server {
listen 80; location / {
   proxy_pass http://webservers;
   }
}

This code tells NGINX to listen for requests on port 80, the default port for unencrypted web (HTTP) traffic and forward such requests to one of the servers in the webservers group defined by the upstream keyword.

Save the file and quit back to your command prompt.

For the changes to take effect, restart the NGINX service using the Bitnami control script:

sudo /opt/bitnami/ctlscript.sh restart nginx

At this point, you should be able to visit the IP address of your NGINX instance in your web browser. The load balancer then routes the request to one of the servers defined in your webservers group.

For reference, here’s the full bitnami.conf file.

# Define Pool of servers to load balance
upstream webservers {
server 192.0.2.67 max_fails=3 fail_timeout=30s;
server 192.0.2.206 max_fails=3 fail_timeout=30s;
server 192.0.2.198 max_fails=3 fail_timeout=30s;
}
# Forward traffic on port 80 to one of the servers in the webservers group server {
listen 80; location / {
proxy_pass http://webservers;
}
}

Configure HTTPS load balancing

Configuring your load balancer to use SSL requires three steps:

  1. Ensure that you have a domain record for your NGINX load balancer instance.
  2. Obtain and install a certificate.
  3. Update the NGINX configuration file.

If you have not already done so, assign your NGINX instance an entry with your DNS provider. Remember, the load balancer is the address your users use to reach your site. For instance, it might be appropriate to create a record that points http://www.yourdomain.com/ at your NGINX load balancer. If you need help configuring the DNS in Lightsail, see DNS in Amazon Lightsail.

Similarly, to configure your NGINX instance to use a free SSL certificate from Let’s Encrypt, follow steps 1–7 in Tutorial: Using Let’s Encrypt SSL certificates with your Nginx instance in Amazon Lightsail. You handle step 8 later in this post,

After you configure NGINX to use the SSL certificate and update your DNS, you must modify the configuration file to allow for HTTPS traffic.

Again, use a text editor to open the bitnami.conf file:

sudo vi bitnami.conf

Add the following code to the bottom of the file:

server {
     listen 443 ssl;
     location / {
          proxy_pass http://webservers;
     }
     ssl_certificate server.crt;
     ssl_certificate_key server.key;
     ssl_session_cache shared:SSL:1m;
     ssl_session_timeout 5m;
     ssl_ciphers HIGH:!aNULL:!MD5;
     ssl_prefer_server_ciphers on;
}

This code closely resembles the HTTP code added previously. However, in this case, the code tells NGINX to accept SSL connections on the secure port 443 (HTTPS) and forward them to one of your web servers. The rest of the commands instruct NGINX on where to locate SSL certificates, as well as setting various SSL parameters.

Here again, restart the NGINX service:

sudo /opt/bitnami/ctlscript.sh restart nginx

Optional steps

At this point, you should be able to access your website using both HTTP and HTTPS. However, there are a couple of optional steps to consider, including:

  • Shutting off direct HTTP/HTTPS access to your web servers.
  • Automatically redirecting incoming load balancer HTTP requests to HTTPS.

It’s probably not a great idea to allow people to access your load-balanced servers directly. Fortunately, you can easily restrict access:

  1. Navigate to each instance’s management page in the Lightsail console.
  2. Choose Networking.
  3. Remove the HTTP and HTTPS (if enabled) firewall port entries.

This restriction shuts down access via the internet while still allowing communications between the load balancer and the servers over the private AWS network.

In many cases, there’s no good reason to allow access to a website or web app over unencrypted HTTP. However, the load balancer configuration described to this point still accepts HTTP requests. To automatically reroute requests from HTTP to HTTPS, make one small change to the configuration file:

  1. Edit the conf file.
  2. Find this code:
server {
listen 80; location / {
proxy_pass http://webservers;
}
}
  1. Replace it with this code:
server {
listen 80;
return 301 https://$host$request_uri;
}

The replacement code instructs NGINX to respond to HTTP requests with a “page has been permanently redirected” message and a citation of the new page address. The new address is simply requested one, only accessed over HTTPS instead of HTTP.

For this change to take effect, you must restart NGINX:

sudo /opt/bitnami/ctlscript.sh restart nginx

For reference, this is what the final bitnami.conf file looks like:

# Define the pool of servers to load balance
upstream webservers {
server 192.0.2.67 max_fails=3 fail_timeout=30s;
server 192.0.2.206 max_fails=3 fail_timeout=30s;
server 192.0.2.198 max_fails=3 fail_timeout=30s;
}
# Redirect traffic on port 80 to use HTTPS
server {
listen 80;
return 301 https://$host$request_uri;
}
# Forward traffic on port 443 to one of the servers in the web servers group
server {
     listen 443 ssl;
     location / {
          proxy_pass http://webservers;
     }
     ssl_certificate server.crt;
     ssl_certificate_key server.key;
     ssl_session_cache shared:SSL:1m;
     ssl_session_timeout 5m;
     ssl_ciphers HIGH:!aNULL:!MD5;
     ssl_prefer_server_ciphers on;
}

Conclusion

This post explained how to configure a load balancer to route web traffic for Amazon Lightsail using NGINX. I defined load balancers and their utility. I weighed the pros and cons of self-hosted load balancers against Lightsail’s managed load balancer service. Finally, I walked you through how to set up a NGINX-based load balancer inside of a Lightsail instance.

Thanks for reading this post. If you have any questions, feel free to contact me on Twitter, @mikegcoleman or visit the Amazon Lightsail forums.

Celebrating 10 years of Microsoft Windows Server and SQL Server on AWS! Happy Birthday!

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/compute/celebrating-10-years-of-microsoft-windows-server-and-sql-server-on-aws-happy-birthday/

Contributed by Sandy Carter, Vice President of Windows on AWS and Enterprise Workloads

Happy birthday to all of our AWS customers! In particular, I want to call out Autodesk, RightScale (now part of Flexera), and Suunto (Movescount) – just a few of our customers who have been running Microsoft Windows Server and Microsoft SQL Server on AWS for 10 years! Thank you for your business and seeing the value of Windows on AWS!

So many customers trust their Windows workloads on AWS because of our experience, reliability, security, and performance. IDC (a leading IT Analyst) estimates that AWS accounted for approximately 57.7% of total Windows instances in public cloud IaaS during 2017 – nearly 2x the nearest cloud provider.

Our Windows on AWS customers benefit from the millions of active customers per month across the AWS Cloud. Ancestry, the global leader in family history and consumer genomics, has over 6000 instances on AWS. Nat Natarajan, Executive Vice President of Product and Technology at Ancestry just spoke with us in Seattle. I loved hearing how they are using Windows on AWS.

“AWS provides us with the flexibility we need to stay at the forefront of consumer genomics, as the science and technology in the space continues to rapidly evolve. We’re confident that AWS provides us with unmatched scalability, security, and privacy.”

Reliability is one the reasons why NextGen Healthcare, provider of tailored healthcare solutions for ambulatory practices and healthcare providers around the world, trusts AWS to run their SQL Server databases. One of the foundations of our reliability is how we design our Regions. AWS has 18 Regions around the globe, each of which are made up of two or more Availability Zones. Availability Zones are physically separate locations with independent infrastructure engineered to be insulated from failures in other Availability Zones. Today we have 55 Availability Zones across these 18 Regions, and we’ve announced plans for 12 more Availability Zones and four more Regions.

I talk to so many of our customers every week who tell me that their Windows and SQL Server workloads run better on AWS. For example, eMarketer enables thousands of companies around the world to better understand markets and consumer behavior. This helps them get the data they need to succeed in a competitive and fast changing digital economy. They recently told me how they started their digital transformation initiative on another public cloud.

“We chose to move our Microsoft workloads to AWS because of your extensive migration experience, higher availability, and better performance. We are seeing 35% cost savings and thrilled to see 4x faster launch times now.” – Ryan Hoffman, Senior Vice President of Engineering

One of the things I get asked about more and more is, can you modernize those Windows apps as well? Using serverless compute on AWS Lambda, Windows containers, and Amazon Machine Learning (Amazon ML), you can really take those Windows apps into the 21st century! For example, Mitek, the global leader in mobile capture and identity verification software solutions, wanted to modernize their Mobile Verify application to accelerate integration across multiple regions and environments. They leveraged Windows containers using Amazon ECS so they could focus their resources on developing more features instead of servers, VMs, and patching. They reduced their deployment time from hours to minutes!

We know .NET developers love using their existing tools. We created tools such as AWS Toolkit for Visual Studio and AWS Tools for Visual Studio Team Services (VSTS) to provide integration into many popular AWS services. Agero tells us how easy it is for their .NET developers to get started with AWS. Agero provides connected vehicle data, roadside assistance, and claims management services to over 115 million drivers and leading insurers.

“We experimented with AWS Elastic Beanstalk and found it was the simplest, fastest way to get .NET code running in AWS.” Bernie Gracy, Chief Digital Officer

Of course, most of our customers use Microsoft Active Directory on-premises for directory-based identity-related services, and some also use Azure AD to manage users with Office365. Customers use AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) to easily integrate AWS resources with on-premises AD and Azure AD. That way, there’s no data to be synchronized or replicated from on-premises to AWS. AWS Managed AD lets you use the same administration tools and built-in features such as single sign-on (SSO) or Group Policy as you use on-premises. And we now enable our customers to share a single directory with multiple AWS accounts within an AWS Region!

This birthday is significant to us here at Amazon Web Services as we obsess over our customers. Over 90% of our roadmap items are driven directly from you! With hundreds of thousands of active customers running Windows on AWS, that’s a lot of great ideas. In fact, did you know that our premier serverless engine, AWS Lambda, which lets you run .NET Core without provisioning or managing servers, came directly from you, our customers?

Some of you wanted an easier way to jumpstart Windows Server projects on AWS, which led us to build Amazon Lightsail, giving you compute, storage and networking with a low, predictable price. Based on feedback from machine learning practitioners and researchers, we launched our AWS Deep Learning AMI for Windows so you can quickly launch Amazon EC2 instances pre-installed with popular deep learning frameworks including Apache MXNet, Caffe and Tensorflow.

Licensing Options

Our customer obsession means that we are committed to helping you lower your total cost of ownership (TCO). When I talk to customers, they tell me they appreciate that AWS does not approach their cloud migration journey as a way to lock-in additional software license subscriptions. For example, TSO Logic, one of our AWS Partner Network (APN) partners, described in a blog the work we did with one of our joint customers, a privately-held U.S. company with more than 70,000 employees, operating in 50 countries. We helped this customer save 22 percent on their SQL Server workloads by optimizing core counts and reducing licensing costs.

Delaware North, a global leader in hospitality management and food service management, uses our pay-as-you-go licenses to scale-up their SQL Server instances during peak periods, without having to pay for those licenses for multiple years. Many customers also use License Mobility benefits to bring their Microsoft application licenses to AWS, and other customers, such as Xero, the accounting software platform for small and medium-sized businesses, reduce costs by bringing their own Windows Server Datacenter Edition and SQL Server Enterprise Edition licenses to AWS on our Amazon EC2 Dedicated Hosts. And, we also have investment programs to help qualified customers offset Microsoft licensing costs when migrating to the AWS Cloud.

We know that many of you are thinking about what to do with legacy applications still using the 2008 versions of SQL Server and Windows Server. I hear from many leaders who don’t want to base their cloud strategy on software end-of-support. AWS provides flexibility to easily upgrade and modernize your legacy workloads. ClickSoftware Technologies, the SaaS provider of field service management solutions, found how easy it was to upgrade to a current version of SQL Server on AWS.

“After migrating to AWS, we upgraded to SQL Server 2016 using SQL Server 2008 in compatibility mode, which meant we did not have to make any application changes, and now have a fully supported version of SQL Server.” – Udi Keidar, VP of Cloud Services, ClickSoftware

Did you know you can also bring your Microsoft licenses to VMware Cloud on AWS? VMware Cloud on AWS is a great solution when you need to execute a fast migration – whether that’s due to running out of data center space, an upcoming lease expiration, or a natural disaster such as the recent hurricanes. Massachusetts Institute of Technology (MIT) started with a proof of concept (POC) and moved their initial 300 VMs in less than 96 hours, with just one employee. Over the next three months they migrated of all of their 2,800 production VMs to VMware Cloud on AWS.

Looking Forward

Next month, I hope you’ll join me at AWS re:Invent to learn “What’s New with Microsoft and .NET on AWS” as well as the dozens of other sessions we have for Windows on AWS for IT leaders, DevOps engineers, system administrators, DBAs and .NET developers. We have so many new innovations to share with you!

I want to thank each you for trusting us these last ten years with your most critical business applications and allowing us to continue to help you innovate and transform your business. If you’d like to learn more about how we can help you bring your applications built on Windows Server and SQL Server to the cloud, please check out the following resources and events or contact us!

  1. https://aws.amazon.com/windows/
  2. https://aws.amazon.com/sql/
  3. https://aws.amazon.com/directoryservice/
  4. https://aws.amazon.com/windows/windows-study-guide/
  5. AWS .NET Developer Center

Upcoming Events

  1. October 23, 2018 Webinar: Migrating Microsoft SQL Server 2008 Databases to AWS
  2. Live with AM & Nicki – A fun new twitch.tv series to show you how to build a modern web application on AWS!
  3. November 26-30 2018 re:Invent: Check out the complete list of sessions for Windows, SQL Server, Active Directory and .NET on AWS!

 

 

 

AWS Online Tech Talks – April & Early May 2018

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/aws/aws-online-tech-talks-april-early-may-2018/

We have several upcoming tech talks in the month of April and early May. Come join us to learn about AWS services and solution offerings. We’ll have AWS experts online to help answer questions in real-time. Sign up now to learn more, we look forward to seeing you.

Note – All sessions are free and in Pacific Time.

April & early May — 2018 Schedule

Compute

April 30, 2018 | 01:00 PM – 01:45 PM PTBest Practices for Running Amazon EC2 Spot Instances with Amazon EMR (300) – Learn about the best practices for scaling big data workloads as well as process, store, and analyze big data securely and cost effectively with Amazon EMR and Amazon EC2 Spot Instances.

May 1, 2018 | 01:00 PM – 01:45 PM PTHow to Bring Microsoft Apps to AWS (300) – Learn more about how to save significant money by bringing your Microsoft workloads to AWS.

May 2, 2018 | 01:00 PM – 01:45 PM PTDeep Dive on Amazon EC2 Accelerated Computing (300) – Get a technical deep dive on how AWS’ GPU and FGPA-based compute services can help you to optimize and accelerate your ML/DL and HPC workloads in the cloud.

Containers

April 23, 2018 | 11:00 AM – 11:45 AM PTNew Features for Building Powerful Containerized Microservices on AWS (300) – Learn about how this new feature works and how you can start using it to build and run modern, containerized applications on AWS.

Databases

April 23, 2018 | 01:00 PM – 01:45 PM PTElastiCache: Deep Dive Best Practices and Usage Patterns (200) – Learn about Redis-compatible in-memory data store and cache with Amazon ElastiCache.

April 25, 2018 | 01:00 PM – 01:45 PM PTIntro to Open Source Databases on AWS (200) – Learn how to tap the benefits of open source databases on AWS without the administrative hassle.

DevOps

April 25, 2018 | 09:00 AM – 09:45 AM PTDebug your Container and Serverless Applications with AWS X-Ray in 5 Minutes (300) – Learn how AWS X-Ray makes debugging your Container and Serverless applications fun.

Enterprise & Hybrid

April 23, 2018 | 09:00 AM – 09:45 AM PTAn Overview of Best Practices of Large-Scale Migrations (300) – Learn about the tools and best practices on how to migrate to AWS at scale.

April 24, 2018 | 11:00 AM – 11:45 AM PTDeploy your Desktops and Apps on AWS (300) – Learn how to deploy your desktops and apps on AWS with Amazon WorkSpaces and Amazon AppStream 2.0

IoT

May 2, 2018 | 11:00 AM – 11:45 AM PTHow to Easily and Securely Connect Devices to AWS IoT (200) – Learn how to easily and securely connect devices to the cloud and reliably scale to billions of devices and trillions of messages with AWS IoT.

Machine Learning

April 24, 2018 | 09:00 AM – 09:45 AM PT Automate for Efficiency with Amazon Transcribe and Amazon Translate (200) – Learn how you can increase the efficiency and reach your operations with Amazon Translate and Amazon Transcribe.

April 26, 2018 | 09:00 AM – 09:45 AM PT Perform Machine Learning at the IoT Edge using AWS Greengrass and Amazon Sagemaker (200) – Learn more about developing machine learning applications for the IoT edge.

Mobile

April 30, 2018 | 11:00 AM – 11:45 AM PTOffline GraphQL Apps with AWS AppSync (300) – Come learn how to enable real-time and offline data in your applications with GraphQL using AWS AppSync.

Networking

May 2, 2018 | 09:00 AM – 09:45 AM PT Taking Serverless to the Edge (300) – Learn how to run your code closer to your end users in a serverless fashion. Also, David Von Lehman from Aerobatic will discuss how they used [email protected] to reduce latency and cloud costs for their customer’s websites.

Security, Identity & Compliance

April 30, 2018 | 09:00 AM – 09:45 AM PTAmazon GuardDuty – Let’s Attack My Account! (300) – Amazon GuardDuty Test Drive – Practical steps on generating test findings.

May 3, 2018 | 09:00 AM – 09:45 AM PTProtect Your Game Servers from DDoS Attacks (200) – Learn how to use the new AWS Shield Advanced for EC2 to protect your internet-facing game servers against network layer DDoS attacks and application layer attacks of all kinds.

Serverless

April 24, 2018 | 01:00 PM – 01:45 PM PTTips and Tricks for Building and Deploying Serverless Apps In Minutes (200) – Learn how to build and deploy apps in minutes.

Storage

May 1, 2018 | 11:00 AM – 11:45 AM PTBuilding Data Lakes That Cost Less and Deliver Results Faster (300) – Learn how Amazon S3 Select And Amazon Glacier Select increase application performance by up to 400% and reduce total cost of ownership by extending your data lake into cost-effective archive storage.

May 3, 2018 | 11:00 AM – 11:45 AM PTIntegrating On-Premises Vendors with AWS for Backup (300) – Learn how to work with AWS and technology partners to build backup & restore solutions for your on-premises, hybrid, and cloud native environments.

Our Newest AWS Community Heroes (Spring 2018 Edition)

Post Syndicated from Betsy Chernoff original https://aws.amazon.com/blogs/aws/our-newest-aws-community-heroes-spring-2018-edition/

The AWS Community Heroes program helps shine a spotlight on some of the innovative work being done by rockstar AWS developers around the globe. Marrying cloud expertise with a passion for community building and education, these Heroes share their time and knowledge across social media and in-person events. Heroes also actively help drive content at Meetups, workshops, and conferences.

This March, we have five Heroes that we’re happy to welcome to our network of cloud innovators:

Peter Sbarski

Peter Sbarski is VP of Engineering at A Cloud Guru and the organizer of Serverlessconf, the world’s first conference dedicated entirely to serverless architectures and technologies. His work at A Cloud Guru allows him to work with, talk and write about serverless architectures, cloud computing, and AWS. He has written a book called Serverless Architectures on AWS and is currently collaborating on another book called Serverless Design Patterns with Tim Wagner and Yochay Kiriaty.

Peter is always happy to talk about cloud computing and AWS, and can be found at conferences and meetups throughout the year. He helps to organize Serverless Meetups in Melbourne and Sydney in Australia, and is always keen to share his experience working on interesting and innovative cloud projects.

Peter’s passions include serverless technologies, event-driven programming, back end architecture, microservices, and orchestration of systems. Peter holds a PhD in Computer Science from Monash University, Australia and can be followed on Twitter, LinkedIn, Medium, and GitHub.

 

 

 

Michael Wittig

Michael Wittig is co-founder of widdix, a consulting company focused on cloud architecture, DevOps, and software development on AWS. widdix maintains several AWS related open source projects, most notably a collection of production-ready CloudFormation templates. In 2016, widdix released marbot: a Slack bot supporting your DevOps team to detect and solve incidents on AWS.

In close collaboration with his brother Andreas Wittig, the Wittig brothers are actively creating AWS related content. Their book Amazon Web Services in Action (Manning) introduces AWS with a strong focus on automation. Andreas and Michael run the blog cloudonaut.io where they share their knowledge about AWS with the community. The Wittig brothers also published a bunch of video courses with O’Reilly, Manning, Pluralsight, and A Cloud Guru. You can also find them speaking at conferences and user groups in Europe. Both brothers are co-organizing the AWS user group in Stuttgart.

 

 

 

 

Fernando Hönig

Fernando is an experienced Infrastructure Solutions Leader, holding 5 AWS Certifications, with extensive IT Architecture and Management experience in a variety of market sectors. Working as a Cloud Architect Consultant in United Kingdom since 2014, Fernando built an online community for Hispanic speakers worldwide.

Fernando founded a LinkedIn Group, a Slack Community and a YouTube channel all of them named “AWS en Español”, and started to run a monthly webinar via YouTube streaming where different leaders discuss aspects and challenges around AWS Cloud.

During the last 18 months he’s been helping to run and coach AWS User Group leaders across LATAM and Spain, and 10 new User Groups were founded during this time.

Feel free to follow Fernando on Twitter, connect with him on LinkedIn, or join the ever-growing Hispanic Community via Slack, LinkedIn or YouTube.

 

 

 

Anders Bjørnestad

Anders is a consultant and cloud evangelist at Webstep AS in Norway. He finished his degree in Computer Science at the Norwegian Institute of Technology at about the same time the Internet emerged as a public service. Since then he has been an IT consultant and a passionate advocate of knowledge-sharing.

He architected and implemented his first customer solution on AWS back in 2010, and is essential in building Webstep’s core cloud team. Anders applies his broad expert knowledge across all layers of the organizational stack. He engages with developers on technology and architectures and with top management where he advises about cloud strategies and new business models.

Anders enjoys helping people increase their understanding of AWS and cloud in general, and holds several AWS certifications. He co-founded and co-organizes the AWS User Groups in the largest cities in Norway (Oslo, Bergen, Trondheim and Stavanger), and also uses any opportunity to engage in events related to AWS and cloud wherever he is.

You can follow him on Twitter or connect with him on LinkedIn.

To learn more about the AWS Community Heroes Program and how to get involved with your local AWS community, click here.