Tag Archives: Amazon Lightsail

Enhancing site security with new Lightsail firewall features

Post Syndicated from Emma White original https://aws.amazon.com/blogs/compute/enhancing-site-security-with-new-lightsail-firewall-features/

This post is contributed by Mike Coleman, AWS Senior Developer Advocate – Lightsail

Amazon Lightsail provides an easy way to get started with AWS for many customers. The service balances ease of use, security, and flexibility. The Lightsail firewall now offers additional features to help customers secure their Lightsail instances. This update offers three new capabilities:

  • The ability to specify source IP addresses for firewall rules
  • Explicitly allowing or disallowing remote access to instances via Lightsail’s web-based console
  • Support for PING

This blog explores each of these new features in detail, starting with source IP addresses.

Before this update, any open ports in the Lightsail firewall were open to the internet. In many cases, this is a reasonable approach. For example, for new WordPress servers, you likely need broad public access.

However, in some cases you want to restrict access to an instance. If you are staging a new website and it’s not ready for publication, you may want to limit access. One way to ensure that only certain people can visit the site is to only allow certain IP addresses to connect.

Another common use case is limiting remote access to an instance. With the new changes to the Lightsail firewall, you would be able to limit SSH or RDP access by source IP address. Additionally, you can now enable or disable remote access via Lightsail’s built-in web client.

Access can be restricted from one or more IP addresses (for example, the IP address for your home computer) or a continuous range of IP addresses (such as the address range for your corporate network).

Next, I review how you configure these options to restrict remote access via SSH to a single source IP address.

Finding your IP address

Most computers do not have an internet routable IP address assigned. Internet routable IP addresses are scarce and usually assigned to your internet gateway device. The devices on the network are assigned private IP addresses. To communicate between the private IP network and the internet, the network router typically uses network address translation (NAT).

This tutorial assumes you are using NAT. This means the IP address used to restrict SSH access is the IP routable address of your network gateway device (usually your wireless router). Consequently, this limits access to all devices on the network behind this IP address.

There are many ways to find your internet routable IP address. You can log into your network gateway device and find it there (consult your device’s user manual for more details). Alternatively, use one of several public services to determine your IP address – search online for “what is my IP” to list several options.

Restricting SSH access to a single IP address

  1. Start by creating a new Lightsail instance – you can select any blueprint.
  2. Once the instance state shows Running, choose the name of the instance to open the Instance details page.
    firewall test instance
  3. Choose Networking from the menu.
    networking tab
  4. Scroll down to find the current firewall settings. Under Allow connections from, it lists Any IP address for all of the applications. To change this, choose the edit icon for the SSH rule.
    IP address
  5. Check the box next to Restrict to IP address and enter your internet routable IP address under Source IP or range.restrict IP address
    Note: The next section shows how to restrict access from Lightsail’s browser-based SSH client. Currently, Allow Lightsail browser SSH box is checked.
  6. Choose Save.

Now, SSH into your Lightsail instance from your local machine. You can learn more about how to connect to your Lightsail instance using SSH from our documentation.

You should be able to connect to your instance successfully. Next, you test the connection from a different IP address. You do this by restricting a different IP address, and attempting to connect again:

  1. Edit the SSH firewall rule again follows the instructions above. This time, under IP or IP Range enter 192.168.2.150.
  2. Choose Save.

Attempt to connect to your instance once more. The connection fails because your IP address does not match an IP address in the range.

Restricting access from the Lightsail browser-based SSH client

The browser-based SSH client makes it easy to access instances without needing to manage SSH keys on locally. However, there may be cases where you must disable browser-based access.

To do this:

  1. Navigate to the firewall rules for the instance you created earlier.
  2. Choose the edit icon for the SSH rule.edit IP address
  3. Uncheck the box next to Allow Lightsail browser SSH. Choose Save.
  4. From the menu, choose Connect, then choose Connect using SSH. The browser window opens, but you are not connected to the instance.

PING Support

There is now support for PING, a command line utility used to check if a computer is reachable over the network. PING sends a packet to a remote computer, which sends a simple response back. Before this release, you could not PING Lightsail instances.

To activate this feature, add a firewall rule:

  1. Navigate to the networking page for your instance.      add rule to firewall<
  2. Under the firewall section, choose +Add rule.
  3. From the application list, choose PING (ICMP). Choose Save.
  4. From a terminal window on your local machine, send a ping command to your Lightsail instance’s IP address. You can find the IP address from the Connect tab of the instance details page or from instance card on the Lightsail home page.
ping -c 5 192.168.2.143

You see a response similar to:

<ping -c 5 192.168.2.143
PING 192.168.2.143 (192.168.2.143): 56 data bytes
64 bytes from 192.168.2.143: icmp_seq=0 ttl=54 time=19.383 ms
64 bytes from 192.168.2.143: icmp_seq=1 ttl=54 time=16.821 ms
64 bytes from 192.168.2.143: icmp_seq=2 ttl=54 time=16.363 ms
64 bytes from 192.168.2.143: icmp_seq=3 ttl=54 time=27.335 ms
64 bytes from 192.168.2.143: icmp_seq=4 ttl=54 time=19.429 ms

--- 192.168.2.143 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 16.363/19.866/27.335/3.943 ms

Conclusion

In this blog I covered how you can increase the security of your Lightsail instances by taking advantage of three new features: source IP restrictions, limiting access to the Lightsail browser SSH and RDP clients, and the addition of PING (ICMP) as an application type. These new features provide you an extra level of flexibility and security when deploying applications on Lightsail.

To learn more about the Lightsail firewall, see the documentation. Additionally, there are Getting Started tutorials for Lightsail, including launching a LAMP stack application or .NET application.

Using AWS CodeDeploy and AWS CodePipeline to Deploy Applications to Amazon Lightsail

Post Syndicated from Emma White original https://aws.amazon.com/blogs/compute/using-aws-codedeploy-and-aws-codepipeline-to-deploy-applications-to-amazon-lightsail/

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

Introduction

Amazon Lightsail is the easiest way to get started in the cloud, allowing you to get your application running on your own virtual server in a matter of minutes. But, what do you do if you want to update that running application?

In order to automate the process of both deploying and updating software many developers are turning to automated workflows. AWS has a full complement of tools that allow you to build deployment pipelines to cover a wide array of use cases.

This blog post provides guidance on how to configure Lightsail to work with AWS CodePipeline and AWS CodeDeploy to automatically deploy (or update) an application every time you push a change to GitHub. Even though this tutorial provides detailed, step-by-step instructions, you may still want to read some of the docs (CodeDeploy and CodePipeline) if you’re unfamiliar with deployment pipelines.

After completing this walkthrough you’ll be on your way to implementing more complex pipelines that might include build and test steps.

 

Prerequisites

You need the following to complete this walkthrough:

  • A GithHub account in which to fork the demo code
  • git installed on your local machine, and a basic understanding on how to use it
  • An AWS account with sufficient privileges to create AWS Identity and Access (IAM) users, policies, and service roles as well as to create resources with the following services: Amazon S3, CodePipeline, CodeDeploy and Lightsail
  • The AWS CLI installed and configured on your local machine

 

Document Important Values

As you go through this tutorial, you’ll need to take note of a few key values. Open up a text editor of your choice, and copy and paste the template below into a new document. As you go through the guide, when instructed, copy the values into your text document

S3 Bucket Name:

Access Key ID:

Secret Key:

IAM User ARN:

Note: Both the Access key ID and Secret access key should be protected in the same manner you protect any sensitive username / password pair.

 

Solution Overview

The rest of this blog guides you through the process of setting up your deployment pipeline. You start by creating a service role for CodeDeploy, an Amazon S3 bucket, and an IAM user. After deploying these services, you create a Lightsail instance. You also install and configure the CodeDeploy agent, as well as registering the instance with CodeDeploy. Finally, you create an application in CodeDeploy, and configure CodePipeline to kick off a new deployment whenever you push changes to GitHub.

 

Create a service role

In AWS a service role is a role that an AWS service assumes to perform actions on your behalf. The policies that you attach to the service role determine which AWS resources the service can access and what it can do with those resources. Below you use AWS IAM to create a service role for CodeDeploy that has the necessary permissions to work with Lightsail.

  1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
  2. In the navigation pane, choose Roles, and then choose Create role.                                iam role
  3. On the Create role page, choose AWS service, and from the Choose the service that will use this role list, choose CodeDeploy.                                  iam role for service
  4. Near the bottom of the screen under Select your use case, choose CodeDeploy and click Next: Permissions.
  5. On the Attached permissions policy page, the default permission policy (AWSCodeDeployRule) is displayed. You can click on the policy name if you’d like to review the details of the policy.Click Next: Tags, and then click Next: Review.
  6. On the Create Role page, in Role name, enter a name for the service role (for example, CodeDeployServiceRole).role name
  7. Click Create role.

 

Create an S3 bucket

In this section, you create an Amazon S3 bucket to store the deployment artifact created by CodeDeploy. This artifact is a compressed file containing your source code files, and any scripts that need to run as part of the installation or update process.

  1. Sign in to the AWS Management Console and open the S3 console, and click Create Bucket. create s3 bucket
  2. Enter a name under Bucket name. The name must be unique across all of S3.
    Be sure to copy the S3 bucket name into your text document.
  3. Ensure Block all public access is checked.                             name s3 bucket
  4. Click Create bucket.

 

Create IAM policy

An IAM policy is a set of rules that, when attached to an identity or resource, defines their permissions. For this use case, you want a policy that only allows AWS CodeDeploy agent to read the S3 bucket you just created. In the next set of steps, you define the policy. Then in the subsequent section you apply that policy to an IAM user. That user ultimately is associated with the CodeDeploy agent running on your Lightsail instance.

  1. Sign in to the AWS Management Console and open the IAM console.
  2. In the navigation pane, choose Policies, and then choose Create policy. create iam policy
  3. Click on the JSON tab.                                                                                            JSON tab

Erase the content in the editor window, and paste in the code from below.

NOTE: Be sure to replace <S3 Bucket Name> with the name of the S3 bucket you created in the previous step.

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Action": [

        "s3:Get*",

        "s3:List*"

      ],

      "Resource": [

        "arn:aws:s3:::<S3 Bucket Name>/*"

      ]

    }

  ]

}

JSON editor revised

  1. Click Review policy.
  2. Enter CodeDeployS3BucketPolicy for the policy name.
  3. Click Create policy.

Create an IAM user

Because you cannot assign an IAM role to a Lightsail instance, you need to create your IAM user with the appropriate permissions. In this case the user will need to be able to list the contents of the S3 bucket you just created.

  1. Stay in the IAM console.
  2. In the navigation pane, choose Users, and then choose Add user.                                      IAM user creation
  3. Enter LightSailCodeDeployUser for the User name and click Programmatic access under Select AWS access type (you use programmatic access since this user account will never need to log into the console). Click Next: permissions.        set user name
  4. Click Attach existing polices directly. Enter CodeDeployS3BucketPolicy in the search box, and check the box next to the CodeDeployS3BucketPolicy policy.                                        attach policies to the S3 bucket
  5. Click Next: Tags. Click Next: Review. Click Create user.
  6. Copy the Access key ID and Secret access key into your text document. You will need to click Show to display the secret access key. Note: If you do not copy these values now, you cannot go back and retrieve them from the console. You will need to create a new set of credentials

.access key and secret access key

       7. Click Close.

8. Click on the user you just and copy the User ARN into your document.  USR ARN

At this point you created an S3 bucket where CodeDeploy can store your build artifact, as well as the IAM components you need (a service role, IAM Policy, and an IAM user) to configure the CodeDeploy agent. In the next step, you actually deploy a Lightsail instance with the CodeDeploy agent, and then you register that instance with CodeDeploy

Create a Lightsail instance and install the CodeDeploy agent

In this section you create the Lightsail instance where you want your code to run. In order for the instance to work with CodeDeploy you must install the CodeDeploy agent. The agent installation is done by providing a startup script that runs when the instance is first created.

  1. Log in to the AWS Management Console, and navigate to the Lightsail home page.
  2. Click Create instance.
  3. Lightsail instance location
  4. Ensure that you’re creating your instance in the correct AWS Region.
  5. Under Pick your instance image click on Linux/Unix. Click on OS Only. Select Amazon Linux.instance image lightsail
  6. Scroll down and click + Add launch script. In the code below paste in your Access key ID, Secret access key, and IAM User ARN from your text document. Also replace <Desired Region> with the Region that you deployed instance into (e.g. us-west-2).

After you edit the code below, paste it into the launch script edit window. The configuration below allows the CodeDeploy agent run with the permissions you assigned to the IAM user earlier. These permissions allow the CodeDeploy agent to download the deployment artifact created by the CodeDeploy service from the S3 bucket where it will be stored. Additionally, the agent will use the information in the artifact to deploy or update your application.

mkdir /etc/codedeploy-agent/

mkdir /etc/codedeploy-agent/conf

cat <<EOT >> /etc/codedeploy-agent/conf/codedeploy.onpremises.yml

---

aws_access_key_id: <Access Key ID>

aws_secret_access_key: <Secret Access Key>

iam_user_arn: <IAM User ARN>

region: <Desired Region>

EOT

wget https://aws-codedeploy-us-west-2.s3.us-west-2.amazonaws.com/latest/install

chmod +x ./install

sudo ./install auto

     6. Enter codedeploy for the instance name under Identify your instance. Click Create Instance.

Verify the CodeDeploy agent

Wait about 5-10 minutes for the instance to boot up and run the startup script.

In this section you verify that the CodeDeploy agent is up and running, register your instance with CodeDeploy, and, finally, tag the instance.

Note: You will be using the command line for both your Lightsail instance and on your local machine. Pay careful attention to the instructions to ensure you’re issuing the commands on the right command line.

  1. Start an SSH session by clicking on the terminal icon next to the name of your instancessh session for instance
  2. On the command line of the Lightsail terminal session enter the command below to verify the CodeDeploy agent is running.

sudo service codedeploy-agent status

You should see a response similar to the one below (the PID will be different):

The AWS CodeDeploy agent is running as PID 2783

      3. Enter the command below using the AWS CLI in a terminal session on your local machine to register your Lightsail instance with CodeDeploy.

NOTE: Replace <IAM User ARN> with the value in your document and the <Desired Region> with the appropriate Region.
NOTE: If you did not name your Lightsail instance codedeploy you will need to adjust the –instance-name parameter accordingly.
NOTE: The command does not provide any output

aws deploy register-on-premises-instance --instance-name codedeploy --iam-user-arn <IAM User ARN> --region <Desired Region>

  1. Enter the following command using the AWS CLI in a terminal session on your local machine to tag your Lightsail instance in CodeDeploy. The tag will be used by CodeDeploy to know where to install your code.
    NOTE: If you did not name your Lightsail instance codedeploy you will need to adjust the –instance-name parameter accordingly.
    NOTE: Replace <Desired Region> with the appropriate Region.
    NOTE: The command does not provide any output

aws deploy add-tags-to-on-premises-instances --instance-names codedeploy --tags Key=Name,Value=CodeDeployLightsailDemo --region <Desired Region>

      5. Enter the command below using the AWS CLI in a terminal session on your local machine to verify your machine was successfully registered:
          NOTE: Replace <Desired Region> with the appropriate Region.

aws deploy list-on-premises-instances --region <Desired Region>

You should see output similar to:

{
"instanceNames": [
     "codedeploy"
  ]
}

At this point you are now ready to setup your actual code deployment using CodePipeline and CodeDeploy.

Setup the application in CodeDeploy

  1. Navigate to the CodeDeploy console, make sure you’re in the correct Region, and click Create application.codedeploy create application
  2. Enter CodeDeployLightsailDemo for the Application name and select EC2/On-premises under Compute platform. Click Create application.
  3. In the Deployment groups section Click Create deployment group.
  4. Enter CodeDeployLightsailDemoDeploymentGroup for the Deployment group name.
  5. Click in the text box for Enter a service role and select the service role you created earlier (CodeDeployServiceRole)
  6. Under Environment configuration check the box for On-premises instances. Under Key enter Name and under Value enter. environment configuration
  7. Under Load balancer uncheck Enable load balancing.
  8. Click Create deployment group.

 

Fork the GitHub Repo

In this section, you connect your GitHub account to CodePipeline so that whenever you push a change to GitHub your new code will automatically be deployed. For this tutorial, I placed a small demo application in a GitHub repository. These next steps guide you through forking that code into your own GitHub account.

  1. Sign into GithHub.
  2. Navigate to the demo repository: http://github.com/mikegcoleman/codedeploygithubdemo
  3. To the right of the repository name at the top click the Forkfork github
  4. Click on the account that you want to fork the repository into.
    After a few seconds the fork process completes, and you are redirected to the new repo in your account.

Setup CodePipeline

As the name implies, CodePipeline allows you to create an automated set of steps for your application deployment. For instance, build and test processes that must happen before a final deployment step. In this example you’re going to build a very simple pipeline that will redeploy your application when a change is pushed to the associated GitHub repository.

  1. Navigate to the CodePipeline console, ensure you’re in the correct Region, and click Create pipeline.
  2. Enter CodeDeployLightsailDemoPipeline for the Pipeline name.
  3. Click on Advanced Settings. Under Artifact store click the radio button next to Custom Location. Click into the Bucket text box and select the S3 bucket you created earlier. Click Next.codepipeline advanced settings
  4. From the Source provider drop down choose Click Connect to GitHub and follow any prompts to authorize CodePipeline to access your GitHub account.
    1. Note: If you’ve connected GitHub previously there will not be any additional prompts.
  5. Click in the Repository text box and select the repository you forked earlier. The name should be <your github username>/codedeploygithubdemo.
  6. Click in the Branch box and choose Click Next. Since there isn’t a build stage click Skip build stage and confirm by clicking Skip.
  7. Choose AWS CodeDeploy from the Deploy provider Ensure the appropriate Region is selected. Choose CodeDeployLightsailDemo from the Application name list. Choose CodeDeployLightsailDemoDeploymentGroup from the Deployment group list.
    1. Click Next.
    2. Click Create pipeline.codedeploy configuration
  8. You’ll be taken to the details page for your pipeline, and can watch the status of the pipeline update. Once the Deploy step has a status of succeeded feel free to move on to the next section.                                                                                           source for code

 

Test and Update the Application

In this final section you to verify the application deployed, and then you’ll make an update to the application to kick off a new deployment. Finally, you’ll verify that the update was successfully pushed to your server.

  1. Navigate in your web browser to the IP address of your Lightsail instance. You can find the IP address on the card for your instance on the Lightsail home page. You should see a simple webpage displayed.
    ip address
  2. Move to the command line of your local machine, and clone the GitHub repository, being sure to insert your GitHub username.NOTE: If you are using SSH to authenticate to GitHub adjust the GitHub command accordinglygit clone https://github.com/<your github username>/codedeploygithubdemoYou should see output similar to the following:

    Cloning into 'codedeploygithubdemo'...
    remote: Enumerating objects: 49, done.
    remote: Counting objects: 100% (49/49), done.
    remote: Compressing objects: 100% (33/33), done.
    remote: Total 49 (delta 25), reused 36 (delta 12), pack-reused 0
    Unpacking objects: 100% (49/49), done.

  3. Change into the directory with the website code:cd codedeploygithubdemo
  4. Using an editor of your choice edit the html file by changing the background color to purple:background-color: purple;
  5. Push the changes to GitHub by issuing each of the following commands one at a time:git add index.html
    git commit -m “new background color”
    git push origin master
  6. Navigate back to the CodePipeline console and click on the name of your pipeline. You should see that the change from GitHub has been picked up and the pipeline is deploying your website. Once the pipeline has successfully completed move to the next step.
  7. Reload to demo website to see that the background color has changed.

Conclusion

Congratulations on finishing this tutorial. You should now have an understanding of how to automate the deployment and updating of your application running on Lightsail using CodeDeploy and CodePipeline. As a next step, you might want to try and deploy a more complex application to Lightsail, including adding a build step. You can find information on how to do that in AWS CodeBuild documentation.

 

 

 

Using Load Balancers on Amazon Lightsail

Post Syndicated from Emma White original https://aws.amazon.com/blogs/compute/using-load-balancers-on-amazon-lightsail/

This post was written by Robert Zhu, Principal Developer Advocate at AWS. 

As your web application grows, it needs to scale up to main performance and improve availability. A Load Balancer is an important tool in any developer’s tool belt. In this post, I show how to load balance a simple Node.js web application using the Amazon Lightsail Load Balancer. I chose Node.js as an example, but the concepts and techniques I discuss work with any other web application stack such as PHP, Djago, .net, or even plain old HTML. To demonstrate these concepts, I deploy a load balancer that splits traffic between two Amazon Lightsail instances using round-robin load balancing. Compared to other load balancing solutions on AWS, such as our Application Load Balancer and Network Load Balancer, the Lightsail Load Balancer is simpler, easier to use, and has a fixed cost of $18/month, regardless of how much bandwidth you use or how many connections are open.

Launch the Cluster

For the demo, first create a cluster consisting of two Lightsail instances. To do so, navigate to the Lightsail console, and launch two micro Lightsail instances using the Ubuntu 18.04 image.

After you select your Region and OS, select an instance plan and identify your instance. Make sure that your instances have enough memory and compute to run your application. For this demo, the smallest instance size suffices.

Instance plan and name

 

Once your instances are ready, click each instance and open an SSH session and run the following commands:

 

sudo apt-get update

sudo apt-get -y install nodejs npm

git clone https://github.com/robzhu/colornode

cd colornode && npm install

 

The above commands update APT package registry, and install Node.js and npm, in order to run the application. When installing npm, select “yes” when you see the following prompt:

npm prompt

Once installation is complete, you can run “node -v” and “npm -v” to make sure everything works. While this is an older version of Node.js, you should be able to use it without any issues. Remember to run these steps for both instances.

The application

Let’s take a tour of the application. Here’s the main.js source file:

 

const color = require("randomcolor")();

const name = require("./randomName");

const app = require("express")();

app.get("/", (_, res) => {

  res.send(`

    <html>

      <body bgcolor=${color}>

      <h1>${name}</h1>

    </html>

  `);

});


app.get("/health", (_, res) => {

  res.status(200).send("I'm OK");

});

app.listen(80, () => console.log(`${name} started on port 80`));

 

Upon startup, the application generates a random name and color. It then uses express-js to serve responses to requests at two routes: “/” and “/health”. When a client requests the “/” route, you respond with an HTML snippet that contains the name and color of the application. When a client requests the “/health” route, you respond with HTTP status code 200. Later, I use the health route to enable Lightsail to determine the health of a node and whether the load balancer should continue routing requests to that node.

 

You can start the application by running “sudo node main.js”. Do this for both instances, and you should see two distinct webpages at each instance’s IP address:

images of two instance urls

 

Launch the Load Balancer

To create a load balancer, open the Network tab in the Lightsail console and click Create load balancer.

Networking tab of Lightsail console

On the next page, name your load balancer and click Create load balancer. After that, a page shows where you can add target instances to the load balancer:

target instances

From the dropdown menu under Target instances, select each instance and attach it to the load balancer, like so:

 

target instances 2

image of first loadbalancer

Once both instances are attached, copy the DNS name for your load balancer and paste it into a new browser session. When the load balancer receives the browser request, it routes the request to one of the two instances. As you refresh the browser, you should see the returned response alternate between the two instances. This should clearly illustrate the functionality of the load balancer.

Health Checks

Over time, your instances inevitably exhibit faulty behavior due to application errors, network partitions, reboots, etc. Load balancers need to detect faulty nodes in order to avoid routing traffic to them. The simplest way to implement a load balancer health check is to expose an HTTP endpoint on your nodes. By default, the Lightsail Load Balancer performs health checks by issuing an HTTP GET request against the node IP address directly. However, recall that the application serves a simple HTTP 200 response at the “/health” route. You can configure the Load Balancer to use this route to perform health checks on our nodes instead.

 

Within your Lightsail console, open your load balancer, click Customize health checking, and enter health for the route:

health check screenshot

 

Now, the Lightsail load balancer uses http://{instanceIP}/health to perform the health check. You can further customize your load balancer by using a custom domain and adding SSL termination.

 

The custom health check feature allows us to implement deeper health check logic. For example, if you want to make sure that the entire application stack is running, you can write a test value to the database and read it back. That would give our application a much higher assurance of functionality, rather than returning Status Code 200 at an HTTP endpoint.

 

Conclusion

In summary, you created a Lightsail Load Balancer and used it to route traffic between two Lightsail instances serving our demo application. If one of these instances crashes or becomes unreachable, the load balancer will automatically route traffic to the remaining healthy nodes in the cluster based on a customizable HTTP health check. In comparison to other AWS load balancing solutions, the Lightsail Load Balancer is simpler, easier, and uses a fixed-pricing model. Please leave feedback in the comments or reach out to me on Twitter or email!

 

In a follow-up post, I walk through some more advanced concepts:

  • SSL termination
  • Custom Domains
  • Deep health check
  • Websocket connections

 

About the Author

Robert Zhu is a principal developer advocate at AWS.

Email: [email protected]

Twitter: @rbzhu

Building a Photo Diary Ghost on Amazon Lightsail

Post Syndicated from Emma White original https://aws.amazon.com/blogs/compute/building-a-photo-diary-ghost-on-amazon-lightsail/

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

Ghost is a simple and flexible alternative to WordPress. With Ghost, you can build a beautiful company website, personal portfolio, photo diary, or anything in between.

In this post, I show you how to start a photo diary using Ghost on Amazon Lightsail, AWS’ easiest solution for hosting virtual private servers. Compared to Amazon EC2, Amazon Lightsail takes care of advanced concepts like VPCs, Security Groups, and IAM policies for you until you want to re-engage those services. Amazon Lightsail also bundles monthly network transfer with the instance, whereas Amazon EC2 charges separately for network transfer.

There are two easy ways to get up and running with Ghost on Lightsail:

1. Using the Ghost Blueprint

Lightsail includes a number of common instance images known as “Blueprints.” When you launch a Blueprint, the selected software is installed and preconfigured, along with any dependencies. This is especially handy for Ghost because it saves you from having to install and configure MySQL. You can find our click-to-launch stacks in the Amazon Lightsail console, as shown in the following image.

Lightsail has pre-built Blueprints for you to launch entire applications with your VPS.

To launch a Blueprint instance, navigate to the Lightsail console. Then, select “Apps + OS” on the “Create Instance” page, and choose “Ghost.” Select the $5/month instance (this is the cheapest instance that meets the minimum requirements for running Ghost and its database on a single box).

 

Once the instance is up and running, find its IP address and open it in your browser. It may take a few minutes for Ghost to start running, during which you may see an error in the browser. As you can see, it is easy to start running Ghost on Amazon Lightsail with the Blueprint.

 

2. Running Ghost in a Container

As an alternative to launching a Ghost Blueprint, you can also run Ghost within a Docker container. In order to run Ghost within a container, you must install Docker on the Lightsail instance. Compared to the Blueprint approach, there are two advantages:

  1. Ability to run other applications on your Lightsail instance, such as forums, static websites, APIs, etc.
  2. Painless upgrades to new Ghost versions. When a new version of Ghost is released, you can upgrade with just a single command.

To run Ghost in a container complete the following steps.

  1. Create a Lightsail Instance (select Ubuntu 18.04).
  2. Connect to it using Lightsail’s browser-based SSH client. Once the instance is up and running, run the following commands to install Docker on your Lightsail instance after connecting:

sudo apt-get update && sudo apt-get install docker.io -y

sudo systemctl start docker

sudo systemctl enable docker

       3. To make sure Docker is installed and running, run:

sudo docker run hello-world 

You should see:

      4. Start the ghost container by running:

sudo mkdir /var/lib/ghost

sudo mkdir /var/lib/ghost/content

sudo docker run -d --name blog -p 80:2368 -v /var/lib/ghost/content:/var/lib/ghost/content ghost

The last command runs the “ghost” container from the public Docker registry. It also maps port 80 (HTTP) on the host to port 2368 inside the container where Ghost is listening for HTTP requests. The -v argument maps a path on the host to a path inside the container. This way, any blog content is persisted into /var/lib/ghost/content and doesn’t disappear when you stop/delete/upgrade the container. The -d argument tells Docker to run the container in detached mode.

 

Now you can test your new blog.

  1. Find the public IP address of your Lightsail instance by selecting Manage from the Instance menu: You can find your IP address by clicking "Manage" on the instance.
  2. Paste the IP address into a browser, and you should see your brand new Ghost blog:After following these steps, you will see Ghost being served from the IP address of your VPS.

 

Installing a Custom Theme

You can customize the look and feel of your Ghost blog by installing a custom theme. There are plenty of free and paid themes online. If you’re a designer, you can even build your own theme from scratch.

For my photo diary, I use the London theme. Download the theme by clicking “Clone or download” > “Download ZIP.”

To download the London theme from Github, click on "Clone or download" and then click "Download ZIP".

 

Next, we need to log into the Ghost admin console. If you launched your Ghost instance using the Lightsail blueprint, follow these steps:

  1. SSH into your Ghost instance
  2. You should see the Bitnami welcome message and a bitnami_credentails file under your home directory.After SSHing into your Lightsail blueprint instance, you'll see a bitnami_credentials file in your home directory.
  3. Display the default admin user name and password by typing cat bitnami_credentials.
  4. Use your credentials to administer your ghost instance at http://INSTANCEIPADDRESS/ghost.

If you launched Ghost within a Docker container, then you can administer Ghost by going to http://INSTANCEIPADDRESS/admin.

Once you are logged into the Ghost admin console, click on Settings > Design > Upload a theme.

In the left menu, click on settings, design, then click "upload a theme" on the main page.

You then see a pop-up prompt to upload the theme file. Drag and drop the theme file you downloaded above. Once the upload is complete, click “activate.”

The london theme is perfect for showcasing your photographs

Refresh your ghost blog IP address in another tab, and you should see a bold, new look and feel.

The Ghost admin console is also used for managing content, plugins, users, and more. For example, you can use header and footer scripts to inject code to add features like analytics and comments. By combining these features, you can make your Ghost blog stand out and fit your workflow.

Managing DNS with Lightsail

If you want to add a custom domain for your blog, you can manage that domain within Lightsail. By managing all your DNS records in one place, you can simplify your workflows.

For example, Lightsail offers the ability to assign Static IP addresses to instances, and then automatically associate an A record to a static IP address. This is a quality-of-life improvement that helps you avoid typing the wrong IP address.

Here are the steps to manage your domain with Lightsail:

  1. Register your domain with a domain registrar, such as Route 53 or GoDaddy.
  2. Once registered, create a DNS Zone within Lightsail and note the nam eservers.
  3. In your domain registrar, replace the domain name servers with your Lightsail DNS Zone name servers. If you’re using Route 53, do not replace the name servers in the default hosted zone. Here’s a video that makes everything clear.
  4. After creating your DNS Zone in Lightsail, you can now associate A (address) records with your Lightsail instances.

Once you have a custom domain, you’ll want to consider adding SSL. Here are step-by-step instructions for issuing an SSL certificate using Let’s Encrypt and terminating SSL using NGNIX.

Conclusion

While Ghost is already a very flexible platform, the Ghost community constantly adds new plugins, themes, extensions, and features. Hosting Ghost yourself is a great way to learn some basic server workflows and get the most out of your Ghost blog. And with Lightsail, it’s simple and cheap! Please feel free to contact me with comments and questions. Go ahead and start running Ghost on Amazon Lightsail.

 

About the Author: 
Robert Zhu is a Principal Developer Evangelist at Amazon Web Services. He focuses on APIs, Web, Mobile, and Gaming. Prior to joining AWS, he worked on GraphQL at Facebook. While at Microsoft, he worked on the .net Framework, Windows Server, and Microsoft Game Studios. In his spare time, he loves learning about history, economics, and psychology. You can reach him @rbzhu on twitter or directly via telepathy.

Amazon Lightsail Database Tips and Tricks

Post Syndicated from Emma White original https://aws.amazon.com/blogs/compute/amazon-lightsail-database-tips-and-tricks/

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

Managed Databases on Amazon Lightsail are affordably priced, and incredibly easy to run. Lightsail databases offer a solid foundation on which to build your application.  You can leverage attractive features like one-click high availability, automatic backups, and a choice of database engines to support your Lightsail apps.

While it’s super simple to do an initial deployment on Amazon Lightsail, I often get questions about how to perform some standard management tasks. Some examples of these tasks are scaling up a database or accessing that database with command line tools. I am also asked how to handle a scenario when you find that you need some of the advanced features found in Amazon Relation Database Service (RDS).

This blog answers these questions and offers general guidance on how to address these issues.

Scale Up Your Database

When I first deploy resources to the cloud, I always choose the least expensive option. Often times, that choice works out and everything runs fine. But sometimes, this results in under sizing resources, which necessitates a move to resources with more horsepower.

If this happens with your Lightsail databases, it’s straightforward to move your database to a larger size. Additionally, you can check the metrics page in the Amazon Lightsail console to see your database performance, and to determine if you need to upgrade.

Let’s walk through how to size up your database.

Start by creating a snapshot of your instance.

  1. Navigate to the Lightsail home page and click databases
  2. Click on the name of your database
  3. From the horizontal menu, click on Snapshots & restoreScreenshot of the snapshot and restore choice
  4. Under Manual Snapshot click + Create snapshotscreenshot of where to hit create snapshot
  5. Give the snapshot a name
  6. Click Create

It takes several minutes for the snapshot creation process to complete. Once the snapshot is available, you can create your new database instance choosing a larger size.

  1. Click the three-dot menu to the right of the snapshot you just created
  2. Choose Create new database
  3. Under Choose your database plan, select either a Standard or High Availability If you’re running a mission critical application, you definitely want to choose the high availability option. Standard is great for test environments or workloads where your application can withstand downtime in the event of a database failure.
  4. Choose the size for your new database instance
  5. Give your database instance a name
  6. Click Create database

The new database is created after several minutes.

Lightsail generates a new password when you create a new database from a snapshot. You can either use this newly generated password, or change it. You can change the password using the following steps:

  1. From the Lightsail home, page click Databases
  2. Scroll down to the Connection details section
  3. If you want to use the auto-generated password, click Show in the password box to display the password
    Otherwise complete steps 4 and 5 to specify a new password.
  4. Under Password, click Change password
  5. Enter a new password and click Save
    It will take a few minutes for the password to update

Now, go into your application. Configure the application to point the new database using the new endpoint, user name, and password values.

Note: It’s out of the scope for this blog to cover how to configure individual applications. Consult your application documentation to see how to do it for your specific application.

Command Line Access

There may be times when you need to work on your database using command line tools. You cannot connect directly to your Lightsail database instance. But, you can access the database remotely from another Lightsail instance.

You can also make your instance accessible via the public internet, and access it remotely from any internet-connected computer. However, I wouldn’t recommend this from a security perspective.

You first must create a new Lightsail instance to get started accessing your Lightsail database via the command line. I recommend basing your instance on Lightsail’s LAMP blueprint because there are MySQL command line tools already installed.

To create a new LAMP instance, do the following:

  1. From the Lightsail home page, click Create Instance
  2. Make sure you create the instance in the same Region as your Lightsail databaseinstance location image
  3. Under Select a blueprint, choose LAMP (PHP 7)blueprint selection
  4. Since you’re only using this instance to run MySQL command line tools, you can choose the smallest instance size
  5. Give your instance a name
  6. Click Create Instance

It takes a few minutes for your new instance to start up.

To check that everything is working correctly, use the MySQL command line interface.

Make sure you have the database user name, password, and endpoint. These can be found by clicking on the name of your database under the Connection details section.

  1. Use either your own SSH client or the built-sin web client to access the Lightsail instance you just created
  2. On the command line, enter the following command substituting the values for your database
mysql \
--host <lightsail database endpoint> \
--user <lightsail database username> \
--password

For example:

mysql \
--host ls-randomchars.us-east-2.rds.amazonaws.com \
--user dbmasteruser \
--password

Notice that you don’t actually put the password on the command line.

3. When prompted enter the password (note that the password will not show up when you enter it)

4. You should now be at the MySQL command prompt

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 87482
Server version: 5.7.26-log Source distribution

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

From here, you can use the command line as you normally would.

Migrating From a Managed Database to Amazon RDS

One of the great things about Lightsail is that it’s easy to get started quickly. It also gives you an easy migration path to more advanced AWS services, should you ever need them. For instance, you might se tup your database on Lightsail, and then realize that it could benefit from read replicas to handle growing traffic. Fortunately, it’s a pretty straightforward process to migrate your data from Lightsail to RDS.

 

Deploy an Amazon RDS database

First, make sure you have an RDS database running the same engine in the same Region as your Lightsail instance, and in your default Amazon VPC. For example, if your Lightsail database is running MySQL in the Oregon Region, RDS should also be running MySQL in the Oregon Region and in the default VPC. If you’re not sure how to create an RDS database, check out their documentation.

Make sure to note the username and password for your new database.

Create a Lightsail Instance

You also need a Lightsail instance with the MySQL command line tools installed. You can set one up by following the instructions in the previous section of this blog.

Enable VPC Peering

To get started, ensure that the Lightsail VPC can communicate. You do this by enabling VPC peering in Lightsail, and modifying the security group for RDS to allow traffic from the Lightsail VPC.

  1. Return to the Lightsail console home page and click Account in the top-right corner. Choose Account from the pop out menu.
  2. Click Advanced on the horizontal menu
  3. Under VPC peering, ensure that the Enable VPC peering box is checked for the region where your database is deployed.
    enable vpc peering screenshot

Adjust the RDS database security group

The next step is to edit the security group for the RDS instance to allow traffic from the Lightsail subnet.

  1. Return to the RDS console home page
  2. Under Resourcesclick on DB Instances
  3. Click on the name of the database you want to migrate data into
  4. Under Connectivity and securityclick on the security group nameconnectivity and security configuration

The security group dialog appears. From here you can add an entry for the Lightsail subnet.

  1. Click the Inbound tab near the bottom of the screen
  2. Click the Edit button
  3. Click Add rule in the pop-up box
  4. From the Type drop-down choose MySQL/Aurora
  5. In the source box, enter 172.26.0.0/16 (this is the CIDR address for the Lightsail subnet)inbound rules
  6. Click Save

Migrate the data from the Lightsail Database to RDS

Now that Lightsail resources can talk with your RDS database, you can do the actual migration.

The initial step is to use mysqldump to export your database information into a file that can be imported into RDS. mysqldump has many options. In this case, you export a database named tasks. Choose the appropriate database for your use case, as well as any other options that make sense.

  1. Use either your own SSH client or the built-in web client to access the Lightsail instance you just created.
  2. Use the following mysqldump command to create a backup of your database to a text file (dump.sql). Substitute the connection values for your Lightsail database. These values  are on the details page of your database under Connection details. The database name must be specific to your environment.
mysqldump \
--host <lightsail database endpoint> \
--user <lightsail database username> \
--databases <database name> \
--password \
> dump.sql

For example:

mysqldump \
--host ls-randomchars.us-west-2.rds.amazonaws.com \
--user dbmasteruser \
--databases tasks \
--password \
--set-gtid-purged=OFF \
> dump.sql

Now that you have a database backup, you can import that into your RDS instance. You need the connection details from your RDS database. Use the username and password from when you created the database. You can find the endpoint on the details page of your database under Connectivity and security (See the following screenshot for an example).

endpoint and port for connectivity and security

If you are not already, return to the terminal session for the Lightsail instance that has the MySQL tools installed.

To import the data into the RDS database you must provide the contents of the dump.sql file to the mysql command line, too. The cat command lists out the file, and by using | (referred to as a pipe) we can send the output directly from that command into mysql.

cat dump.sql | \
mysql \
--host <RDS database endpoint> \
--user <RDS user> \
--password

For example:

cat dump.sql | \
mysql \
--host database.randomchars.us-west-2.rds.amazonaws.com \
--user dbmasteruser \
--password

You can also use the mysql command to see if the database was created (this is similar to what we did when we passed in the file in the previous step. Instead, this time we’re using echo to pipe in the command show databases;)

echo "show databases;| \
mysql \
--host <RDS database endpoint> \
--user <RDS user> \
--password

For example:

echo "show databases;" | \
mysql \
--host database.randomchars.us-west-2.rds.amazonaws.com \
--user dbmasteruser \
--password

From here, you reconfigure your application to access your new RDS database.

Conclusion

In this post I reviewed some common tasks that you might want to do once you created your Amazon Lightsail database. You learned how to scale up the size of your database, how to access it with command line tools, and how to migrate to RDS.

If you’ve not yet deployed a Managed Database on Lightsail why not head over to the Lightsail console and create one now. If you need a bit of guidance to get started, we have a workshop at https://lightsailworkshop.com that will show you how to use Lightsail to deploy a two-tier web application using a MySQL database backend. Please feel free to leave comments and questions for future blog posts.

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.

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 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.

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.

New – Managed Databases for Amazon Lightsail

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/new-managed-databases-for-amazon-lightsail/

Amazon Lightsail makes it easy for you to get started with AWS. You choose the operating system (and optional application) that you want to run, pick an instance plan, and create an instance, all in a matter of minutes. Lightsail offers low, predictable pricing, with instance plans that include compute power, storage, and data transfer:

Managed Databases
Today we are making Lightsail even more useful by giving you the ability to create a managed database with a couple of clicks. This has been one of our top customer requests and I am happy to be able to share this news.

This feature is going to be of interest to a very wide range of current and future Lightsail users, including students, independent developers, entrepreneurs, and IT managers. We’ve addressed the most common and complex issues that arise when setting up and running a database. As you will soon see, we have simplified and fine-tuned the process of choosing, launching, securing, accessing, monitoring, and maintaining a database!

Each Lightsail database bundle has a fixed, monthly price that includes the database instance, a generous amount of SSD-backed storage, a terabyte or more of data transfer to the Internet and other AWS regions, and automatic backups that give you point-in-time recovery for a 7-day period. You can also create manual database snapshots that are billed separately.

Creating a Managed Database
Let’s walk through the process of creating a managed database and loading an existing MySQL backup into it. I log in to the Lightsail Console and click Databases to get started. Then I click Create database to move forward:

I can see and edit all of the options at a glance. I choose a location, a database engine and version, and a plan, enter a name, and click Create database (all of these options have good defaults; a single click often suffices):

We are launching with support for MySQL 5.6 and 5.7, and will add support for PostgreSQL 9.6 and 10 very soon. The Standard database plan creates a database in one Availability Zone with no redundancy; the High Availability plan also creates a presence in a second AZ, and is recommended for production use.

Database creation takes just a few minutes, the status turns to Available, and my database is ready to use:

I click on Database-Oregon-1, and I can see the connection details, and have access to other management information & tools:

I’m ready to connect! I create an SSH connection to my Lightsail instance, ensure that the mysql package is installed, and connect using the information above (read Connecting to Your MySQL Database to learn more):

Now I want to import some existing data into my database. Lightsail lets me enable Data import mode in order to defer any backup or maintenance operations:

Enabling data import mode deletes any existing automatic snapshots; you may want to take a manual snapshot before starting your import if you are importing fresh data into an existing database.

I have a large (13 GB) , ancient (2013-era) MySQL backup from a long-dead personal project; I download it from S3, uncompress it, and import it:

I can watch the metrics while the import is underway:

After the import is complete I disable data import mode, and I can run queries against my tables:

To learn more, read Importing Data into Your Database.

Lightsail manages all routine database operations. If I make a mistake and mess up my data, I can use the Emergency Restore to create a fresh database instance from an earlier point in time:

I can rewind by up to 7 days, limited to when I last disabled data import mode.

I can also take snapshots, and use them later to create a fresh database instance:

Things to Know
Here are a couple of things to keep in mind when you use this new feature:

Engine Versions – We plan to support the two latest versions of MySQL, and will do the same for other database engines as we make them available.

High Availability – As is always the case for production AWS systems, you should use the High Availability option in order to maintain a database footprint that spans two Zones. You can switch between Standard and High Availability using snapshots.

Scaling Storage – You can scale to a larger database instance by creating and then restoring a snapshot.

Data Transfer – Data transfer to and from Lightsail instances in the same AWS Region does not count against the usage that is included in your plan.

Amazon RDS – This feature shares core technology with Amazon RDS, and benefits from our operational experience with that family of services.

Available Now
Managed databases are available today in all AWS Regions where Lightsail is available:

Jeff;

Compute Abstractions on AWS: A Visual Story

Post Syndicated from Massimo Re Ferre original https://aws.amazon.com/blogs/architecture/compute-abstractions-on-aws-a-visual-story/

When I joined AWS last year, I wanted to find a way to explain, in the easiest way possible, all the options it offers to users from a compute perspective. There are many ways to peel this onion, but I want to share a “visual story” that I have created.

I define the compute domain as “anything that has CPU and Memory capacity that allows you to run an arbitrary piece of code written in a specific programming language.” Your mileage may vary in how you define it, but this is broad enough that it should cover a lot of different interpretations.

A key part of my story is around the introduction of different levels of compute abstractions this industry has witnessed in the last 20 or so years.

Separation of duties

The start of my story is a line. In a cloud environment, this line defines the perimeter between the consumer role and the provider role. In the cloud, there are things that AWS will do and things that the consumer will do. The perimeter of these responsibilities varies depending on the services you opt to use. If you want to understand more about this concept, read the AWS Shared Responsibility Model documentation.

The different abstraction levels

The reason why the line above is oblique is because it needs to intercept different compute abstraction levels. If you think about what happened in the last 20 years of IT, we have seen a surge of different compute abstractions that changed the way people consume CPU and Memory resources. It all started with physical (x86) servers back in the 80s, and then we have seen the industry adding abstraction layers over the years (for example, hypervisors, containers, functions).

The higher you go in the abstraction levels, the more the cloud provider can add value and can offload the consumer from non-strategic activities. A lot of these activities tend to be “undifferentiated heavy lifting.” We define this as something that AWS customers have to do but that don’t necessarily differentiate them from their competitors (because those activities are table-stakes in that particular industry).

What we found is that supporting millions of customers on AWS requires a certain degree of flexibility in the services we offer because there are many different patterns, use cases, and requirements to satisfy. Giving our customers choices is something AWS always strives for.

A couple of final notes before we dig deeper. The way this story builds up through the blog post is aligned to the progression of the launch dates of the various services, with a few noted exceptions. Also, the services mentioned are all generally available and production-grade. For full transparency, the integration among some of them may still be work-in-progress, which I’ll call out explicitly as we go.

The instance (or virtual machine) abstraction

This is the very first abstraction we introduced on AWS back in 2006. Amazon Elastic Compute Cloud (Amazon EC2) is the service that allows AWS customers to launch instances in the cloud. When customers intercept us at this level, they retain responsibility of the guest operating system and above (middleware, applications, etc.) and their lifecycle. AWS has the responsibility for managing the hardware and the hypervisor including their lifecycle.

At the very same level of the stack there is also Amazon Lightsail, which “is the easiest way to get started with AWS for developers, small businesses, students, and other users who need a simple virtual private server (VPS) solution. Lightsail provides developers compute, storage, and networking capacity and capabilities to deploy and manage websites and web applications in the cloud.”

And this is how these two services appear in our story:

The container abstraction

With the rise of microservices, a new abstraction took the industry by storm in the last few years: containers. Containers are not a new technology, but the rise of Docker a few years ago democratized access. You can think of a container as a self-contained environment with soft boundaries that includes both your own application as well as the software dependencies to run it. Whereas an instance (or VM) virtualizes a piece of hardware so that you can run dedicated operating systems, a container technology virtualizes an operating system so that you can run separated applications with different (and often incompatible) software dependencies.

And now the tricky part. Modern containers-based solutions are usually implemented in two main logical pieces:

  • A containers control plane that is responsible for exposing the API and interfaces to define, deploy, and lifecycle containers. This is also sometimes referred to as the container orchestration layer.
  • A containers data plane that is responsible for providing capacity (as in CPU/Memory/Network/Storage) so that those containers can actually run and connect to a network. From a practical perspective this is typically a Linux host or less often a Windows host where the containers get started and wired to the network.

Arguably, in a specific compute abstraction discussion, the data plane is key, but it is as important to understand what’s happening for the control plane piece.

In 2014, Amazon launched a production-grade containers control plane called Amazon Elastic Container Service (ECS), which “is a highly scalable, high performance container management service that supports Docker … Amazon ECS eliminates the need for you to install, operate, and scale your own cluster management infrastructure.”

In 2017, Amazon also announced the intention to release a new service called Amazon Elastic Container Service for Kubernetes (EKS) based on Kubernetes, a successful open source containers control plane technology. Amazon EKS was made generally available in early June 2018.

Just like for ECS, the aim for this service is to free AWS customers from having to manage a containers control plane. In the past, AWS customers would spin up EC2 instances and deploy/manage their own Kubernetes masters (masters is the name of the Kubernetes hosts running the control plane) on top of an EC2 abstraction. However, we believe many AWS customers will leave to AWS the burden of managing this layer by either consuming ECS or EKS, depending on their use cases. A comparison between ECS and EKS is beyond the scope of this blog post.

You may have noticed that what we have discussed so far is about the container control plane. How about the containers data plane? This is typically a fleet of EC2 instances managed by the customer. In this particular setup, the containers control plane is managed by AWS while the containers data plane is managed by the customer. One could argue that, with ECS and EKS, we have raised the abstraction level for the control plane, but we have not yet really raised the abstraction level for the data plane as the data plane is still comprised of regular EC2 instances that the customer has responsibility for.

There is more on that later on but, for now, this is how the containers control plane and the containers data plane services appear:

The function abstraction

At re:Invent 2014, AWS introduced another abstraction layer: AWS Lambda. Lambda is an execution environment that allows an AWS customer to run a single function. So instead of having to manage and run a full-blown OS instance to run your code, or having to track all software dependencies in a user-built container to run your code, Lambda allows you to upload your code and let AWS figure out how to run it at scale.

What makes Lambda so special is its event-driven model. Not only can you invoke Lambda directly (for example, via the Amazon API Gateway), but you can trigger a Lambda function upon an event in another AWS service (for example, an upload to Amazon S3 or a change in an Amazon DynamoDB table).

The key point about Lambda is that you don’t have to manage the infrastructure underneath the function you are running. No need to track the status of the physical hosts, no need to track the capacity of the fleet, no need to patch the OS where the function will be running. In a nutshell, no need to spend time and money on the undifferentiated heavy lifting.

And this is how the Lambda service appears:

The bare metal abstraction

Also known as the “no abstraction.”

As recently as re:Invent 2017, we announced (the preview of) the Amazon EC2 bare metal instances. We made this service generally available to the public in May 2018.

This announcement is part of Amazon’s strategy to provide choice to our customers. In this case, we are giving customers direct access to hardware. To quote from Jeff Barr’s post:

“…. (AWS customers) wanted access to the physical resources for applications that take advantage of low-level hardware features such as performance counters and Intel® VT that are not always available or fully supported in virtualized environments, and also for applications intended to run directly on the hardware or licensed and supported for use in non-virtualized environments.”

This is how the bare metal Amazon EC2 i3.metal instance appears:

As a side note, and also as alluded to by Jeff, i3.metal is the foundational EC2 instance type on top of which VMware created their own VMware Cloud on AWS service. We are now offering the ability to any AWS user to provision bare metal instances. This doesn’t necessarily mean you can load your hypervisor of choice out of the box, but you can certainly do things you wouldn’t be able to do with a traditional EC2 instance (note: this was just a Saturday afternoon hack).

More seriously, a question I get often asked is whether users could install ESXi on i3.metal on their own. Today this cannot be done, but I’d be interested in hearing your use case for this.

The full container abstraction (for lack of a better term)

Now that we covered all the abstractions, it is time to go back and see if there are other optimizations we can provide for AWS customers. When we discussed the container abstraction, we called out that while there are two different fully managed containers control planes (ECS and EKS), there wasn’t a managed option for the data plane.

Some customers were (and still are) happy about being in full control of said instances. Others have been very vocal that they wanted to get out of the (undifferentiated heavy-lifting) business of managing the lifecycle of that piece of infrastructure.

Enter AWS Fargate, a production-grade service that provides compute capacity to AWS containers control planes. Practically speaking, Fargate is making the containers data plane fall into the “Provider space” responsibility. This means the compute unit exposed to the user is the container abstraction, while AWS will manage transparently the data plane abstractions underneath.

This is how the Fargate service appears:

Now ECS has two “launch types”: one called “EC2” (where your tasks get deployed on a customer-managed fleet of EC2 instances), and the other one called “Fargate” (where your tasks get deployed on an AWS-managed fleet of EC2 instances).

For EKS, the strategy will be very similar, but as of this writing it was not yet available. If you’re interested in some of the exploration being done to make this happen, this is a good read.

Conclusions

We covered the spectrum of abstraction levels available on AWS and how AWS customers can intercept them depending on their use cases and where they sit on their cloud maturity journey. Customers with a “lift & shift” approach may be more akin to consume services on the left-hand side of the slide, whereas customers with a more mature cloud native approach may be more interested in consuming services on the right-hand side of the slide.

In general, customers tend to use higher-level services to get out of the business of managing non-differentiating activities. For example, I recently talked to a customer interested in using Fargate. The trigger there was the fact that Fargate is ISO, PCI, SOC and HIPAA compliant, which was a huge time and money saver for them because it’s easier to point to an AWS document during an audit than having to architect and document for compliance the configuration of a DIY containers data plane.

As a recap, here’s our visual story with all the abstractions available:

I hope you found it useful. Any feedback is greatly appreciated.

About the author

Massimo is a Principal Solutions Architect at AWS. For about 25 years, he specialized on the x86 ecosystem starting with operating systems and virtualization technologies, and lately he has been head down learning about cloud and how application architectures are evolving in that space. Massimo has a blog at www.it20.info and his Twitter handle is @mreferre.

Amazon Lightsail Update – More Instance Sizes and Price Reductions

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/amazon-lightsail-update-more-instance-sizes-and-price-reductions/

Amazon Lightsail gives you access to the power of AWS, with the simplicity of a VPS (Virtual Private Server). You choose a configuration from a menu and launch a virtual machine (an instance) preconfigured with SSD-based storage, DNS management, and a static IP address. You can use Linux or Windows, and can even choose between eleven Linux-powered blueprints that contain ready-to-run copies of popular web, e-commerce, and development tools:

On the Linux/Unix side, you now have six options, including CentOS:

The monthly fee for each instance includes a generous data transfer allocation, giving you the ability to host web sites, blogs, online stores and whatever else you can dream up!

Since the launch of Lightsail in late 2016, we’ve done our best to listen and respond to customer feedback. For example:

October 2017Microsoft Windows – This update let you launch Lightsail instances running Windows Server 2012 R2, Windows Server 2016, and Windows Server 2016 with SQL Server 2016 Express. This allowed you to build, test, and deploy .NET and Windows applications without having to set up or run any infrastructure.

November 2017Load Balancers & Certificate Management – This update gave you the ability to build highly scalable applications that use load balancers to distribute traffic to multiple Lightsail instances. It also gave you access to free SSL/TLS certificates and a simple, integrated tool to request and validate them, along with an automated renewal mechanism.

November 2017Additional Block Storage – This update let you extend your Lightsail instances with additional SSD-backed storage, with the ability to attach up to 15 disks (each holding up to 16 TB) to each instance. The additional storage is automatically replicated and encrypted.

May 2018Additional Regions – This update let you launch Lightsail instances in the Canada (Central), Europe (Paris), and Asia Pacific (Seoul) Regions, bringing the total region count to 13, and giving you lots of geographic flexibility.

So that’s where we started and how we got here! What’s next?

And Now for the Updates
Today we are adding two more instances sizes at the top end of the range and reducing the prices for the existing instances by up to 50%.

Here are the new instance sizes:

16 GB – 16 GB of memory, 4 vCPUs, 320 GB of storage, and 6 TB of data transfer.

32 GB – 32 GB of memory, 8 vCPUs, 640 GB of storage, and 7 TB of data transfer.

Here are the monthly prices (billed hourly) for Lightsail instances running Linux:

512 MB
1 GB2 GB4 GB8 GB16 GB32 GB
Old$5.00$10$20$40$80
New$3.50$5$10$20$40$80$160

And for Lightsail instances running Windows:

512 MB1 GB2 GB4 GB8 GB16 GB32 GB
Old$10$17$30$55$100
New$8$12$20$40$70$120$240

These reductions are effective as of August 1, 2018 and take place automatically, with no action on your part.

From Our Customers
WordPress power users, developers, entrepreneurs, and people who need a place to host their personal web site are all making great use of Lightsail. The Lightsail team is always thrilled to see customer feedback on social media and shared a couple of recent tweets with me as evidence!

Emil Uzelac (@emiluzelac) is a well-respected member of the WordPress community, especially in the area of WordPress theme development and reviews. When he tried Lightsail he was super impressed with the speed of our instances calling them “by far the fastest I’ve tried”:

As an independent developer and SaaS cofounder, Mike Rogers (@mikerogers0) hasn’t spent a lot of time working with infrastructure. However, when he moved some of his Ruby on Rails projects over to Lightsail, he realized that it was easy (and actually fun) to make the move:

Stephanie Davis (@StephanieMDavis) is a business intelligence developer and honey bee researcher who wanted to find a new home for her writings. She settled on Lightsail, and after it was all up and running she had a “. . . a much, much better grasp of the AWS cloud infrastructure and an economical, slick web host”:

If you have your own Lightsail success story to share, could I ask you to tweet it and hashtag it with #PoweredByLightsail ? I can’t wait to read it!

Some new Lightsail Resources
While I have got your attention, I’d like to share some helpful videos with you!

Deploying a MEAN stack Application on Amazon Lightsail – AWS Developer Advocate Mike Coleman shows you how to deploy a MEAN stack (MongoDB, Express.js, Angular, Node.js) on Lightsail:

Deploying a WordPress Instance on Amazon Lightsail – Mike shows you how to deploy WordPress:

Deploying Docker Containers on Amazon Lightsail – Mike shows you how to use Docker containers:

Jeff;

AWS Online Tech Talks – May and Early June 2018

Post Syndicated from Devin Watson original https://aws.amazon.com/blogs/aws/aws-online-tech-talks-may-and-early-june-2018/

AWS Online Tech Talks – May and Early June 2018  

Join us this month to learn about some of the exciting new services and solution best practices at AWS. We also have our first re:Invent 2018 webinar series, “How to re:Invent”. Sign up now to learn more, we look forward to seeing you.

Note – All sessions are free and in Pacific Time.

Tech talks featured this month:

Analytics & Big Data

May 21, 2018 | 11:00 AM – 11:45 AM PT Integrating Amazon Elasticsearch with your DevOps Tooling – Learn how you can easily integrate Amazon Elasticsearch Service into your DevOps tooling and gain valuable insight from your log data.

May 23, 2018 | 11:00 AM – 11:45 AM PTData Warehousing and Data Lake Analytics, Together – Learn how to query data across your data warehouse and data lake without moving data.

May 24, 2018 | 11:00 AM – 11:45 AM PTData Transformation Patterns in AWS – Discover how to perform common data transformations on the AWS Data Lake.

Compute

May 29, 2018 | 01:00 PM – 01:45 PM PT – Creating and Managing a WordPress Website with Amazon Lightsail – Learn about Amazon Lightsail and how you can create, run and manage your WordPress websites with Amazon’s simple compute platform.

May 30, 2018 | 01:00 PM – 01:45 PM PTAccelerating Life Sciences with HPC on AWS – Learn how you can accelerate your Life Sciences research workloads by harnessing the power of high performance computing on AWS.

Containers

May 24, 2018 | 01:00 PM – 01:45 PM PT – Building Microservices with the 12 Factor App Pattern on AWS – Learn best practices for building containerized microservices on AWS, and how traditional software design patterns evolve in the context of containers.

Databases

May 21, 2018 | 01:00 PM – 01:45 PM PTHow to Migrate from Cassandra to Amazon DynamoDB – Get the benefits, best practices and guides on how to migrate your Cassandra databases to Amazon DynamoDB.

May 23, 2018 | 01:00 PM – 01:45 PM PT5 Hacks for Optimizing MySQL in the Cloud – Learn how to optimize your MySQL databases for high availability, performance, and disaster resilience using RDS.

DevOps

May 23, 2018 | 09:00 AM – 09:45 AM PT.NET Serverless Development on AWS – Learn how to build a modern serverless application in .NET Core 2.0.

Enterprise & Hybrid

May 22, 2018 | 11:00 AM – 11:45 AM PTHybrid Cloud Customer Use Cases on AWS – Learn how customers are leveraging AWS hybrid cloud capabilities to easily extend their datacenter capacity, deliver new services and applications, and ensure business continuity and disaster recovery.

IoT

May 31, 2018 | 11:00 AM – 11:45 AM PTUsing AWS IoT for Industrial Applications – Discover how you can quickly onboard your fleet of connected devices, keep them secure, and build predictive analytics with AWS IoT.

Machine Learning

May 22, 2018 | 09:00 AM – 09:45 AM PTUsing Apache Spark with Amazon SageMaker – Discover how to use Apache Spark with Amazon SageMaker for training jobs and application integration.

May 24, 2018 | 09:00 AM – 09:45 AM PTIntroducing AWS DeepLens – Learn how AWS DeepLens provides a new way for developers to learn machine learning by pairing the physical device with a broad set of tutorials, examples, source code, and integration with familiar AWS services.

Management Tools

May 21, 2018 | 09:00 AM – 09:45 AM PTGaining Better Observability of Your VMs with Amazon CloudWatch – Learn how CloudWatch Agent makes it easy for customers like Rackspace to monitor their VMs.

Mobile

May 29, 2018 | 11:00 AM – 11:45 AM PT – Deep Dive on Amazon Pinpoint Segmentation and Endpoint Management – See how segmentation and endpoint management with Amazon Pinpoint can help you target the right audience.

Networking

May 31, 2018 | 09:00 AM – 09:45 AM PTMaking Private Connectivity the New Norm via AWS PrivateLink – See how PrivateLink enables service owners to offer private endpoints to customers outside their company.

Security, Identity, & Compliance

May 30, 2018 | 09:00 AM – 09:45 AM PT – Introducing AWS Certificate Manager Private Certificate Authority (CA) – Learn how AWS Certificate Manager (ACM) Private Certificate Authority (CA), a managed private CA service, helps you easily and securely manage the lifecycle of your private certificates.

June 1, 2018 | 09:00 AM – 09:45 AM PTIntroducing AWS Firewall Manager – Centrally configure and manage AWS WAF rules across your accounts and applications.

Serverless

May 22, 2018 | 01:00 PM – 01:45 PM PTBuilding API-Driven Microservices with Amazon API Gateway – Learn how to build a secure, scalable API for your application in our tech talk about API-driven microservices.

Storage

May 30, 2018 | 11:00 AM – 11:45 AM PTAccelerate Productivity by Computing at the Edge – Learn how AWS Snowball Edge support for compute instances helps accelerate data transfers, execute custom applications, and reduce overall storage costs.

June 1, 2018 | 11:00 AM – 11:45 AM PTLearn to Build a Cloud-Scale Website Powered by Amazon EFS – Technical deep dive where you’ll learn tips and tricks for integrating WordPress, Drupal and Magento with Amazon EFS.

 

 

 

 

Give Your WordPress Blog a Voice With Our New Amazon Polly Plugin

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/give-your-wordpress-blog-a-voice-with-our-new-amazon-polly-plugin/

I first told you about Polly in late 2016 in my post Amazon Polly – Text to Speech in 47 Voices and 24 Languages. After that AWS re:Invent launch, we added support for Korean, five new voices, and made Polly available in all Regions in the aws partition. We also added whispering, speech marks, a timbre effect, and dynamic range compression.

New WordPress Plugin
Today we are launching a WordPress plugin that uses Polly to create high-quality audio versions of your blog posts. You can access the audio from within the post or in podcast form using a feature that we call Amazon Pollycast! Both options make your content more accessible and can help you to reach a wider audience. This plugin was a joint effort between the AWS team our friends at AWS Advanced Technology Partner WP Engine.

As you will see, the plugin is easy to install and configure. You can use it with installations of WordPress that you run on your own infrastructure or on AWS. Either way, you have access to all of Polly’s voices along with a wide variety of configuration options. The generated audio (an MP3 file for each post) can be stored alongside your WordPress content, or in Amazon Simple Storage Service (S3), with optional support for content distribution via Amazon CloudFront.

Installing the Plugin
I did not have an existing WordPress-powered blog, so I begin by launching a Lightsail instance using the WordPress 4.8.1 blueprint:

Then I follow these directions to access my login credentials:

Credentials in hand, I log in to the WordPress Dashboard:

The plugin makes calls to AWS, and needs to have credentials in order to do so. I hop over to the IAM Console and created a new policy. The policy allows the plugin to access a carefully selected set of S3 and Polly functions (find the full policy in the README):

Then I create an IAM user (wp-polly-user). I enter the name and indicate that it will be used for Programmatic Access:

Then I attach the policy that I just created, and click on Review:

I review my settings (not shown) and then click on Create User. Then I copy the two values (Access Key ID and Secret Access Key) into a secure location. Possession of these keys allows the bearer to make calls to AWS so I take care not to leave them lying around.

Now I am ready to install the plugin! I go back to the WordPress Dashboard and click on Add New in the Plugins menu:

Then I click on Upload Plugin and locate the ZIP file that I downloaded from the WordPress Plugins site. After I find it I click on Install Now to proceed:

WordPress uploads and installs the plugin. Now I click on Activate Plugin to move ahead:

With the plugin installed, I click on Settings to set it up:

I enter my keys and click on Save Changes:

The General settings let me control the sample rate, voice, player position, the default setting for new posts, and the autoplay option. I can leave all of the settings as-is to get started:

The Cloud Storage settings let me store audio in S3 and to use CloudFront to distribute the audio:

The Amazon Pollycast settings give me control over the iTunes parameters that are included in the generated RSS feed:

Finally, the Bulk Update button lets me regenerate all of the audio files after I change any of the other settings:

With the plugin installed and configured, I can create a new post. As you can see, the plugin can be enabled and customized for each post:

I can see how much it will cost to convert to audio with a click:

When I click on Publish, the plugin breaks the text into multiple blocks on sentence boundaries, calls the Polly SynthesizeSpeech API for each block, and accumulates the resulting audio in a single MP3 file. The published blog post references the file using the <audio> tag. Here’s the post:

I can’t seem to use an <audio> tag in this post, but you can download and play the MP3 file yourself if you’d like.

The Pollycast feature generates an RSS file with links to an MP3 file for each post:

Pricing
The plugin will make calls to Amazon Polly each time the post is saved or updated. Pricing is based on the number of characters in the speech requests, as described on the Polly Pricing page. Also, the AWS Free Tier lets you process up to 5 million characters per month at no charge, for a period of one year that starts when you make your first call to Polly.

Going Further
The plugin is available on GitHub in source code form and we are looking forward to your pull requests! Here are a couple of ideas to get you started:

Voice Per Author – Allow selection of a distinct Polly voice for each author.

Quoted Text – For blogs that make frequent use of embedded quotes, use a distinct voice for the quotes.

Translation – Use Amazon Translate to translate the texts into another language, and then use Polly to generate audio in that language.

Other Blogging Engines – Build a similar plugin for your favorite blogging engine.

SSML Support – Figure out an interesting way to use Polly’s SSML tags to add additional character to the audio.

Let me know what you come up with!

Jeff;

 

AWS Online Tech Talks – January 2018

Post Syndicated from Ana Visneski original https://aws.amazon.com/blogs/aws/aws-online-tech-talks-january-2018/

Happy New Year! Kick of 2018 right by expanding your AWS knowledge with a great batch of new Tech Talks. We’re covering some of the biggest launches from re:Invent including Amazon Neptune, Amazon Rekognition Video, AWS Fargate, AWS Cloud9, Amazon Kinesis Video Streams, AWS PrivateLink, AWS Single-Sign On and more!

January 2018– Schedule

Noted below are the upcoming scheduled live, online technical sessions being held during the month of January. Make sure to register ahead of time so you won’t miss out on these free talks conducted by AWS subject matter experts.

Webinars featured this month are:

Monday January 22

Analytics & Big Data
11:00 AM – 11:45 AM PT Analyze your Data Lake, Fast @ Any Scale  Lvl 300

Database
01:00 PM – 01:45 PM PT Deep Dive on Amazon Neptune Lvl 200

Tuesday, January 23

Artificial Intelligence
9:00 AM – 09:45 AM PT  How to get the most out of Amazon Rekognition Video, a deep learning based video analysis service Lvl 300

Containers

11:00 AM – 11:45 AM Introducing AWS Fargate Lvl 200

Serverless
01:00 PM – 02:00 PM PT Overview of Serverless Application Deployment Patterns Lvl 400

Wednesday, January 24

DevOps
09:00 AM – 09:45 AM PT Introducing AWS Cloud9  Lvl 200

Analytics & Big Data
11:00 AM – 11:45 AM PT Deep Dive: Amazon Kinesis Video Streams
Lvl 300
Database
01:00 PM – 01:45 PM PT Introducing Amazon Aurora with PostgreSQL Compatibility Lvl 200

Thursday, January 25

Artificial Intelligence
09:00 AM – 09:45 AM PT Introducing Amazon SageMaker Lvl 200

Mobile
11:00 AM – 11:45 AM PT Ionic and React Hybrid Web/Native Mobile Applications with Mobile Hub Lvl 200

IoT
01:00 PM – 01:45 PM PT Connected Product Development: Secure Cloud & Local Connectivity for Microcontroller-based Devices Lvl 200

Monday, January 29

Enterprise
11:00 AM – 11:45 AM PT Enterprise Solutions Best Practices 100 Achieving Business Value with AWS Lvl 100

Compute
01:00 PM – 01:45 PM PT Introduction to Amazon Lightsail Lvl 200

Tuesday, January 30

Security, Identity & Compliance
09:00 AM – 09:45 AM PT Introducing Managed Rules for AWS WAF Lvl 200

Storage
11:00 AM – 11:45 AM PT  Improving Backup & DR – AWS Storage Gateway Lvl 300

Compute
01:00 PM – 01:45 PM PT  Introducing the New Simplified Access Model for EC2 Spot Instances Lvl 200

Wednesday, January 31

Networking
09:00 AM – 09:45 AM PT  Deep Dive on AWS PrivateLink Lvl 300

Enterprise
11:00 AM – 11:45 AM PT Preparing Your Team for a Cloud Transformation Lvl 200

Compute
01:00 PM – 01:45 PM PT  The Nitro Project: Next-Generation EC2 Infrastructure Lvl 300

Thursday, February 1

Security, Identity & Compliance
09:00 AM – 09:45 AM PT  Deep Dive on AWS Single Sign-On Lvl 300

Storage
11:00 AM – 11:45 AM PT How to Build a Data Lake in Amazon S3 & Amazon Glacier Lvl 300

AWS Online Tech Talks – November 2017

Post Syndicated from Sara Rodas original https://aws.amazon.com/blogs/aws/aws-online-tech-talks-november-2017/

Leaves are crunching under my boots, Halloween is tomorrow, and pumpkin is having its annual moment in the sun – it’s fall everybody! And just in time to celebrate, we have whipped up a fresh batch of pumpkin spice Tech Talks. Grab your planner (Outlook calendar) and pencil these puppies in. This month we are covering re:Invent, serverless, and everything in between.

November 2017 – Schedule

Noted below are the upcoming scheduled live, online technical sessions being held during the month of November. Make sure to register ahead of time so you won’t miss out on these free talks conducted by AWS subject matter experts.

Webinars featured this month are:

Monday, November 6

Compute

9:00 – 9:40 AM PDT: Set it and Forget it: Auto Scaling Target Tracking Policies

Tuesday, November 7

Big Data

9:00 – 9:40 AM PDT: Real-time Application Monitoring with Amazon Kinesis and Amazon CloudWatch

Compute

10:30 – 11:10 AM PDT: Simplify Microsoft Windows Server Management with Amazon Lightsail

Mobile

12:00 – 12:40 PM PDT: Deep Dive on Amazon SES What’s New

Wednesday, November 8

Databases

10:30 – 11:10 AM PDT: Migrating Your Oracle Database to PostgreSQL

Compute

12:00 – 12:40 PM PDT: Run Your CI/CD Pipeline at Scale for a Fraction of the Cost

Thursday, November 9

Databases

10:30 – 11:10 AM PDT: Migrating Your Oracle Database to PostgreSQL

Containers

9:00 – 9:40 AM PDT: Managing Container Images with Amazon ECR

Big Data

12:00 – 12:40 PM PDT: Amazon Elasticsearch Service Security Deep Dive

Monday, November 13

re:Invent

10:30 – 11:10 AM PDT: AWS re:Invent 2017: Know Before You Go

5:00 – 5:40 PM PDT: AWS re:Invent 2017: Know Before You Go

Tuesday, November 14

AI

9:00 – 9:40 AM PDT: Sentiment Analysis Using Apache MXNet and Gluon

10:30 – 11:10 AM PDT: Bringing Characters to Life with Amazon Polly Text-to-Speech

IoT

12:00 – 12:40 PM PDT: Essential Capabilities of an IoT Cloud Platform

Enterprise

2:00 – 2:40 PM PDT: Everything you wanted to know about licensing Windows workloads on AWS, but were afraid to ask

Wednesday, November 15

Security & Identity

9:00 – 9:40 AM PDT: How to Integrate AWS Directory Service with Office365

Storage

10:30 – 11:10 AM PDT: Disaster Recovery Options with AWS

Hands on Lab

12:30 – 2:00 PM PDT: Hands on Lab: Windows Workloads

Thursday, November 16

Serverless

9:00 – 9:40 AM PDT: Building Serverless Websites with [email protected]

Hands on Lab

12:30 – 2:00 PM PDT: Hands on Lab: Deploy .NET Code to AWS from Visual Studio

– Sara

Amazon Lightsail Update – Launch and Manage Windows Virtual Private Servers

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/amazon-lightsail-update-launch-and-manage-windows-virtual-private-servers/

I first told you about Amazon Lightsail last year in my blog post, Amazon Lightsail – the Power of AWS, the Simplicity of a VPS. Since last year’s launch, thousands of customers have used Lightsail to get started with AWS, launching Linux-based Virtual Private Servers.

Today we are adding support for Windows-based Virtual Private Servers. You can launch a VPS that runs Windows Server 2012 R2, Windows Server 2016, or Windows Server 2016 with SQL Server 2016 Express and be up and running in minutes. You can use your VPS to build, test, and deploy .NET or Windows applications without having to set up or run any infrastructure. Backups, DNS management, and operational metrics are all accessible with a click or two.

Servers are available in five sizes, with 512 MB to 8 GB of RAM, 1 or 2 vCPUs, and up to 80 GB of SSD storage. Prices (including software licenses) start at $10 per month:

You can try out a 512 MB server for one month (up to 750 hours) at no charge.

Launching a Windows VPS
To launch a Windows VPS, log in to Lightsail , click on Create instance, and select the Microsoft Windows platform. Then click on Apps + OS if you want to run SQL Server 2016 Express, or OS Only if Windows is all you need:

If you want to use a Powershell script to customize your instance after it launches for the first time, click on Add launch script and enter the script:

Choose your instance plan, enter a name for your instance(s), and select the quantity to be launched, then click on Create:

Your instance will be up and running within a minute or so:

Click on the instance, and then click on Connect using RDP:

This will connect using a built-in, browser-based RDP client (you can also use the IP address and the credentials with another client):

Available Today
This feature is available today in the US East (Northern Virginia), US East (Ohio), US West (Oregon), EU (London), EU (Ireland), EU (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Mumbai), Asia Pacific (Sydney), and Asia Pacific (Tokyo) Regions.

Jeff;