Tag:

aws

3 major microservice monitoring categories cover image

3 Important Ways To Monitor Your Microservices

by corey.walker March 1, 2023

Monitoring is a major element in a great DevOps workflow. Without monitoring, teams cannot quickly react to and correct issues with their services. This limits the ability of teams to continuously integrate (CI) and/or continuously deploy (CD). CI/CD is a major component of DevOps. Thus having great monitoring is essential to having a smooth and productive DevOps workflow. In this post, we will discuss 3 important ways to monitor your microservices to have an effective DevOps workflow.

Internal Microservice Monitoring

Internal monitoring refers to monitors that are themselves microservices within your environments. These monitors run tests frequently against other microservices to verify they are running as expected. This type of monitoring normally has more in-depth testing than external monitoring which we will discuss later.

With internal monitoring, you can run anything from a simple up/down ping test all the way to complex integration-like tests on a frequent basis. This type of monitor is normally set up to run anywhere from 1-minute intervals and longer. This allows for quick detection of any issues after changes to an environment or dependent services that have issues. These monitors alerting in a timely fashion allows for quick recovery times for self-induced issues. It can also alert for dependent service issues.

There is a downside to internal monitors inside the same environment that your other microservices are running in. They are listed below.

Lack of Insight If Environment Is Completely Unreachable

If the connection to the service completely goes down, there isn’t any monitoring able to alert you of any issues. That’s a major issue especially if you are providing a critical service for others or your business. If you are not notified swiftly when services are non-operational in the middle of the night when others are dependent on them, bad things can happen. Thus quick notification of any outages is a must.

More Effort to Create and Maintain

Internal monitors normally require custom coding of essentially another microservice whose sole purpose is to monitor other microservices. This entails quite a bit more effort to create as well as the ongoing effort to maintain code changes and security & compliance. However, with more in-depth tests, it will save a lot of time by giving detailed error messages which reduce debugging time.

External Microservice Monitoring

External monitoring is another way of monitoring your microservices. This entails using a third-party service such as DataDog, New Relic, AWS CloudWatch, Dynatrace, Sentry, or similar platforms.

What external monitoring allows you to do is to maintain visibility into the status of your microservices. You can still be alerted in a timely fashion even if the whole environment is unavailable.

External monitors are normally not as extensive or run as frequently as internal monitors as it costs a good amount of money to run a lot of nontrivial tests on these platforms. This is why it is best to have a good combination of the two to cover all of your alerting needs. Create more in-depth and complex monitors that will run more frequently to detect issues with any aspect of the service itself when it is running and available, and utilize external monitors to run less complex tests at a more infrequent interval to detect the more major issues that may hinder your services.

Application Performance Monitoring

The last major component of a great monitoring solution is Application Performance Monitoring (APM). This entails installing a component onto your server, container, or mobile app to track how the application is behaving while it is running. This will allow tracking of patterns that may need attention and/or fixes implemented. Some examples may include seeing consistent issues with certain browsers, desktop or mobile OS types and versions, higher than expected memory usage or memory leaks, and other similar types of issues.

Some examples of APM integrations include New Relic, DataDog, Firebase Crashlytics, Sentry, and more. Jadd the APM component to your platform running your app or service and let it report the details to the platform of choice. You can then set up alerts on the chosen platform to alert your team in whichever way you deem best that is an option provided.

Conclusion

Being able to thoroughly monitor your microservices is an essential part of a comprehensive DevOps workflow. Without great monitoring, great DevOps practices are nonexistent. You must be able to know that your services are doing what they are expected to do and do them efficiently. Otherwise, you will constantly be trying to debug issues well after your customers are experiencing them which is never a good thing.

Now, go out there and set up these 3 important ways to monitor your microservices! Happy monitoring!

March 1, 2023 0 comments

Tutorials

Best Monitor Tool For AWS Lambda – Sentry

by corey.walker May 17, 2021

written by corey.walker

AWS Lambda is one of the most, if not THE most, popular serverless computation services available today. Millions of companies and developers use it to run computations that do not need to keep state. One of the main issues with AWS Lambda is the ability to monitor the function for errors and performance. That’s where Sentry monitoring comes in. So let’s learn how about the best monitor tool for AWS Lambda – Sentry!

Intro to Sentry Monitoring Service

Sentry is a monitoring service that integrates well with many different types of applications. It has a great array of functionality and options for different monitoring needs. In this post, we set up Sentry to give more insights into your functions’ performance and errors!

There are a couple of options for how to configure Sentry to monitor AWS Lambda functions. One requires a bit more money as it deploys a CloudFormation stack to your account. This will automatically monitor any/all Lambda functions you want in that region. The other option is to add a bit of wrapper code to your Lambda function. This automatically allows your Lambda function to send monitoring events to Sentry. Both are relatively easy to configure. However, in the long run, the CloudFormation stack method will be easier to maintain if cost isn’t an issue.

Setting Up the Sentry’s AWS Lambda CloudFormation Stack

Deploying the Sentry CloudFormation Stack to your AWS account and enabling the functions you wish to have monitored is the easier method. The steps to do this can be found here (note: you must have a paid plan to choose this option).

All you need for this option is to deploy the CloudFormation stack and select the functions you wish to monitor. That’s it! You will pay a fee for whatever resources the CloudFormation stack utilizes in monitoring your Lambda functions. However, this solution is much more maintainable and easier to add monitoring to already deployed functions than the manual methods.

Setting Up Sentry’s AWS Lambda Function Wrapper

Another option for setting up Sentry to monitor AWS Lambda functions is to install Sentry packages to your project. Then configure Sentry to use your project and organization and then wrap your AWS Lambda function.

The first step is to install the Sentry Serverless package into your Lambda project. If you are using Node.js for your lambda function, run the following:

npm install --save @sentry/serverless

After the package is installed, add the following to your Lambda function before the handler method:

const Sentry = require("@sentry/serverless"); 

Sentry.AWSLambda.init({         
     dsn: "https://[email protected]/0",  <<<--- Add your custom project DSN URL here       
    // We recommend adjusting this value in production, or using tracesSampler   
    // for finer control   
    tracesSampleRate: 1.0, 
});

After you set up the configuration settings for Sentry, wrap the Lambda function with the Sentry Serverless wrapper method:

exports.handler = Sentry.AWSLambda.wrapHandler(async (event, context) => {  
     // Your handler code 
});

If you are using Typescript for your AWS Lambda function, you need to perform a few additional steps. Follow the steps here to get your TypeScript Lambda project setup.

Tracking Lambda Function Performance

Another option Sentry provides for AWS Lambda monitoring is monitoring runtime performance. This option gives insight into whether your functions take too long to run and hamper your user’s experience and/or increase costs; both of which are definitely unwanted. This insight can let you pinpoint what may be causing the long runtime and to resolve it ASAP. Check out the options for configuring performance monitoring here.

Conclusion

Sentry can be an excellent addition for monitoring many important aspects of your AWS Lambda functions. Make sure to like this post and leave a comment if you liked this post. Also, make sure to share it with those you believe it will also help!

May 17, 2021 0 comments

Tutorials

How To Secure AWS S3 Resources – Part 2

by corey.walker June 5, 2020

written by corey.walker

In my previous post in this series about how to secure AWS S3 resources, I talked about the importance of securing your AWS S3 resources by making sure the proper permissions were set up for your buckets as well as the objects you place in those buckets.

In this post, we will talk about the different ways to encrypt the objects in your S3 buckets. Encrypting your S3 data is very important so attackers cannot steal your data. Let’s get into the meat of this post, shall we?

Check out our video tutorial related to this post:

YouTube video about AWS S3 encryption and security

Server-Side Encryption Options

Server-side encryption only encrypts data once it has reached the server and before it is stored on disk for uploads. It will decrypt the data on the server before returning it to the user for retrievals. Thus the data will be traveling over the internet unencrypted unless, of course, you are using TLS/SSL/HTTPS connections.

Using Standard AWS S3 AES-256 Encryption

Always selecting the default AWS S3 AES-256 encryption is the easiest way to get S3 server-side encryption. The key for this encryption method is managed by AWS S3 and is not configurable. You can find more information about this default encryption method here. The main gist is that when you create a new bucket, you can set the option to always encrypt all objects in that bucket using this method. Below you will find a screenshot of where the option is when creating a new S3 bucket:

Using KMS Managed Key Encryption

As you can see in the screenshot above, there is another encryption option using KMS Managed Keys. This is a great option if you want to control the rotation of your keys or delete them to render your data useless in case of a breach. You can also use different encryption keys for your development and production data if desired. HOWEVER, there is one major caveat that many smaller companies may really want to know about before using that option.

If you choose the KMS Managed key option, every object put into the bucket or read from the bucket will incur a lookup of that KMS key. Pricing for using KMS keys can be found here. If you add or request files in your S3 bucket many times each day, this cost can add up quickly. Just keep that in mind when choosing your encryption option for your bucket.

Using Customer Managed Key Encryption

AWS S3 now allows customers to provide their own encryption key(s) to encrypt and decrypt their S3 objects. There are a few ways of using customer-managed keys to encrypt your data:

Using an AWS SDK for your project’s programming language such as AWS Java SDK or AWS .NET SDK
You can also use the AWS REST API if you are using a different language than one of those listed above, or if you need direct access to the HTTP REST API

Client-Side Encryption

There is also the option to encrypt your data before sending it over to AWS S3 and decrypt it after receiving data from AWS S3. Adding Client-Side encryption in addition to server-side encryption enhances security. This also adds processing time and additional load on the client as it needs to do extra work.

There are numerous SDKs for different languages that support client-side encryption for S3 objects.

You can use either a Customer Master Key that is stored in AWS KMS, or you can use an encryption key that is stored within your application. You can find more information about AWS S3 client-side encryption here.

June 5, 2020 0 comments

Tutorials

How To Secure AWS S3 Resources – Part 1

by corey.walker April 11, 2020

written by corey.walker

Do you or your company use Amazon Web Services (AWS) S3 to store data used for your applications? Then you’re going to want to make sure you secure and control access to that data. That way it’s not accessible by attackers! In this series of articles, I help explain how to secure your AWS S3 resources.

Check out our related YouTube video:

Controlling Access To S3

Setting Default Accessibility Options For Entire Account

The very first thing you’ll want to do is make the data accessible to only the people and processes that NEED access to it. In the majority of cases, this means making it inaccessible to everyone on the internet. You’ve probably seen stories of data in S3 being exposed to the whole internet due to faulty permissions (or no restrictions at all).

There may be reasons why you want your S3 bucket to be publicly accessible, such as when hosting a static website. So you need to verify which buckets should be kept openly accessible and which can be marked private. Marking a bucket as publicly inaccessible can break applications that need the public access. Be sure to note which ones are which before proceeding to the next step which will lock down all buckets in an account.

The first thing to do is set the account settings to block internet access to your S3 buckets by default. To do that, visit Block public access (account settings), and if Block all public access is set to Off, click Edit and then click to select all checkboxes and then click Save Changes. This will make all current buckets private and then make the default for future buckets to be private as well. This is a great default option if a majority of buckets in your account will be publicly inaccessible. If you have more buckets needing public access than not, the next section will be a better option.

Setting Accessibility Options When Creating a Bucket

When first creating a new AWS S3 bucket, on the Set Permissions screen during the setup configuration, you want to make sure to select the Block all public access option to disable all public access to objects in that S3 bucket. A screenshot of what this looks like is as follows:

Screenshot of available AWS S3 bucket permissions

This will block all access to the S3 bucket by default except for the account that created it. This means no services, applications, etc that need data from this bucket can see it now without using an AWS IAM policy or by utilizing AWS IAM roles.

Setting Accessibility Options For Specific Buckets

You can update settings for existing buckets if you have already created S3 buckets you need to secure. First, visit the list of S3 buckets you have created by visiting the AWS S3 Console and selecting the bucket to update. Once the selected bucket is opened, visit the Permissions Tab as shown in the screenshot below. Then click on Block Public Access. Now, click on the Edit button on the right-hand side of the screen.

Screenshot of applied AWS S3 bucket permissions

Make sure Block all public access is checked and click Save on the right side of your screen.

This sets your S3 bucket to be inaccessible from any process, application, and user that does not have explicit permissions. This could have broken some applications or processes that may have been able to see those resources before. DON’T FRET! All you need to do now is set up an IAM policy specifying the exact actions and resources you wish to allow access to. Then attach it to an AWS IAM Role, and grant each process and application access using that role. Check out Assume an IAM Role via AWS CLI on how to do this via the CLI. Another good read is Creating a Role to Delegate Permissions to an IAM User.

You can also create an IAM policy for specific IAM users. Do this by also creating an IAM Group, attaching the IAM policy, and assigning the specified users to that group.

Conclusion

You should now be able to manage access to your S3 buckets to only allow access to authorized users and processes. Part 2 of this blog series goes over different encryption options for your S3 resources to keep your data confidential. So go check that out as well!

April 11, 2020 0 comments

Tutorials

How To Setup Multi-Region DNS Fail-over In AWS

by corey.walker October 15, 2019

written by corey.walker

Do you have an API hosted on AWS API Gateway? Do you wonder how you can deploy that API into multiple regions around the globe and have automatic fail-over protection in case one region goes offline so that your API keeps on working without any intervention? Well, you came to the right blog post. In this post, I will show you how to set up and configure your AWS Route53 DNS entries, health checks, and AWS API Gateway APIs in order to have that automatic multi-region DNS fail-over protection you’re looking for.

Initial Multi-Region DNS Fail-over Configuration

The first thing we need to do is have a domain setup in AWS Route 53. Once you have a domain, we also need to set up a hosted zone in Route 53 for that domain. Inside this hosted zone is where we will add the DNS records we need as part of our automatic DNS fail-over configuration. Once you have a domain name and hosted zone setup, let’s get going on configuring automatic DNS fail-over!

First things first, we need to have the desired API deployed to AWS API Gateway in each of the AWS regions we want in our setup. If you do not have that yet, you can follow this guide as an example of how to create an API using HTTP front-end with AWS Lambda as the back-end for processing the requests. You will need an endpoint on your API that will respond to GET requests and be able to return a status code of 2XX in order for our health checks to know that our API is healthy in each region.

Creating An SSL/TLS Certificate

Once you have that, you will need to create an SSL certificate on AWS Certificate Manager in each of the same regions to use with your domain which we will use in the next step. You will need to verify the entries you add to your SSL certificate. If you are using Route 53 as we have discussed in this article, you can expand each of the domain name listings and add it to Route 53. We then just need to wait on the verification to be complete before moving on to the next step.

Now that you have your API deployed to AWS API Gateway and we have an SSL certificate for our domain, we need to set up a custom domain name in AWS API Gateway in each of our AWS regions. Go to the AWS API Gateway console and click Create Custom Domain Name. It will open up a form to create a new custom domain which you should fill out as follows:

For Domain Name, fill in your desired domain for this API. (e.g. examplecorp.com)
Choose HTTP Protocol
Security Policy: TLS 1.2 (1.2 is the latest and most secure as of this writing. If there is a newer version as you’re reading this, choose it instead)
Endpoint Configuration: Regional (this selection is important!)
Choose the SSL certificate you created in the previous steps, then click Save

Cool. Now we have everything configured in API Gateway. Let’s move on to Route 53 to finish up our automatic multi-region DNS fail-over!

Configuring Health Checks

We now need to set up the health checks that allow us to automatically determine if a certain region is unavailable. We will use this to route our traffic accordingly. Visit the AWS Route 53 Console then click on Health Checks in the left-hand menu and then click Create health check.

Under the first section under Configure health check, give this health check a name that would specify the region, service, and environment this is being used for so we can keep things organized and easy to know what health check is monitoring what. A good name may be something like Production — US-East-1 — API for example. For What to monitor, select Endpoint.

Monitor Endpoint Configuration

Now, in the Monitor an endpoint section, use the following configuration:

Specify endpoint by: Domain Name
Protocol: HTTPS (this is required to be HTTPS because we use API Gateway API stage generated URLs which are HTTPS)
Domain Name: This will be the Invoke URL generated for the API stage in API Gateway such as dev, prod, etc after deploying an API. Template URL for where you can find it is https://console.aws.amazon.com/apigateway/home?region=us-east-1#/apis/{{API_ID}}/stages/dev and an example URL is dk0bnnfwn2.execute-api.us-east-1.amazonaws.com
Leave Port as default since it is determined by the protocol you selected
For Path, enter the stage name for the URL you copied above (e.g. dev, production, etc) followed by the endpoint path you want the health check to monitor. (The one I mentioned earlier that needed to have a GET method and return a 2XX status code). For example, a valid path could be dev/health

You can expand the Advanced Configuration section and change some of the options if you wish. One I would possibly really consider modifying is the list of Health Checker Regions. You have to choose at least 3 regions, choose 3 for development APIs, and additional for my production APIs.

CloudWatch Alarms

Click Next and on the next screen, you can set up CloudWatch alarms when the health check fails for the number of consecutive times specified in the Advanced Configuration section on the first page. Continue on and create the health check.

Repeat the above steps for each of the regions you wish to deploy your API, remembering to grab the correct Invoke URL for the API in each region. Now you should have all of your health checks in place. Let’s move on to the last piece of the puzzle, the DNS entries in your hosted zone for your domain.

Creating Route53 Record Sets

Let’s get the last piece configured now. Head over to the AWS Route 53 Console once again, and click on Hosted Zones in the left menu, then click on the hosted zone for your domain. Click on Create Record Set and enter the following details:

Name: desired domain/subdomain mapping you want for this API (e.g. api.examplecorp.com).
Record type: CNAME
Alias: No
TTL: 300 (5m)
Value: This is the value of Target Domain Name generated when you created the custom domain in API Gateway. Copy that value and paste it here
Routing Policy: Latency
Select the region that matches the custom domain Target Domain Nameyou just pasted, and then give this policy a name that distinguishes it from the other regions and environments you may use.
Associate With Health Check: Yes then select the health check that corresponds with the same region and environment that matches the other values for this CNAME record
Click Create
Follow the same steps for all other regions you deployed your API to

Conclusion

That’s it! Now whenever one of your regions is unavailable for whatever reason, it will take just a few minutes (<5 minutes) for your other regions to pick up the load. The response times may be a little slower than the desired region since these are latency-based routing rules. However, your application should keep on working after the health checks fail the specified number of times and fail-over occurs! Congratulations! You have now set up automatic multi-region DNS fail-over using AWS Route53 and API Gateway!

October 15, 2019 0 comments

Tutorials

How To Deploy Multiple Environments Using Serverless

by corey.walker October 1, 2019

written by corey.walker

Do you currently use a serverless configuration for any applications or interested in migrating a current application to use serverless? Have you wondered how you can easily configure your CI/CD pipeline to easily deploy to multiple environments such as development, staging, and all production environments? With the Serverless Framework you can do just that. Continue reading to find out how.

Intro To Serverless Framework

Currently, I use the Serverless Framework to deploy to multiple environments and regions on the AWS cloud. I deploy to our development, staging, and production environments. Our development and staging environments are deployed in 2 different regions. Our production environment is deployed to 4 regions. So I have a serverless.yml file with many properties found in the docs for serverless.yml found here.

Configuration

All properties that remain the same for all environments and/or regions go into the serverless.yml base file
For all properties that are different between each environment such as development, staging, and production, I have another config file with the following naming convention under my config/ directory (the same naming I have is not required, but just what i use):
config/config.dev.yml, config/config.stg.yml, config/config.prod.yml, etc

Following this guide, I add all the needed custom properties to those environment-specific config files, and then in the main serverless.yml file, I create the same property but then reference the property from the environment/stage specified on the serverless deploy -s {stage}CLI command. I use a combination of both the stage CLI parameter and setting an ENV variable in a bash script before calling serverless deploy. Then I can also use ${env:ENV} to reference that value inside serverless.yml .

Environment Specific Configurations

Here’s an example of an environment-specific YAML configuration file I have for environment-specific variables:

stageSuffix: -${self:provider.stackSuffix, 'dev'}
lambda:
  versioning: false
prune:
  automatic: ${self:lambda.versioning}
  number: 5
api:
  domain: api.dev.${self:custom.domain}
storage:
  bucket: dev.${self:provider.region}.${self:custom.domain}
slackChannel: 'dev-slack-channel'

And inside serverless.yml, I reference those values by doing the following:

environment:
  ENV: ${env:ENV, 'dev'}
  STAGE: ${opt:stage, 'dev'}
  REGION: ${opt:region, 'us-east-1'}
  SLACK_CHANNEL: ${file(./config/config.${self:provider.stage}.yml):slackChannel}

Also, using a lot of shell environment-based variables allows you to make your serverless config even more decoupled away from specific projects/microservices since you then can just create a .env file specific to each project, create a bash script to run your serverless deploycommands, and before running serverless deploy, run source .env and many values can be populated easily by just supplying your .env file

Lastly, here’s an example of the bash script we use to run our serverless deploy commands that will supply many of our values in serverless.ymlwith values from a .env file instead of manually finding and replacing all the values between all our different microservices:

set -evif [[ -e "./secret.env" ]]; then
    source "./secret.env"
fi
if [[ -e "./.env" ]]; then
    source "./.env"
fiBRANCH="${CIRCLE_BRANCH:-$BRANCH}"if [[ $# -gt 0 ]]; then
    REGION="$1"
fiif [[ -n "$REGION" ]]; then
    REGION="$REGION"
else
    REGION="us-east-1"
fiif [[ "$BRANCH" == "development" ]] || [[ "$BRANCH" =~ ^issue-* ]]; then
    ENV="dev"
elif [[ "$BRANCH" == "staging" ]]; then
    ENV="stg"
elif [[ "$BRANCH" == "master" ]]; then
    ENV="prod"
fiif [[ "$BRANCH" =~ ^issue-* ]]; then
    export STAGE="feature"
    export STACK_SUFFIX="$BRANCH"
    export API_BASE_PATH_SUFFIX="-$BRANCH"
    "$(dirname "$0")"/create_domain.sh -s "$STAGE" -r "$REGION"
    "$NODE_MODULES_CLI_DIR"/serverless deploy -v -s "$STAGE" -r "$REGION"
else
    export STACK_SUFFIX="$ENV"
    "$(dirname "$0")"/create_domain.sh -s "$ENV" -r "$REGION"
    "$NODE_MODULES_CLI_DIR"/serverless deploy -v -s "$ENV" -r "$REGION"
fi

and the .env file we use to supply the variable values:

export BRANCH="$(git branch | grep \* | cut -d ' ' -f2)"
export ENV="dev"
export STACK_PREFIX="{STACK_PREFIX_HERE}"
export STACK_SUFFIX="$ENV"
export APP="{APP_ID_HERE}"
export APP_NAME="{APP_NAME_HERE}"
export COMPONENT="{COMPONENT_NAME_HERE}"
export REGION="us-east-1"
export DYNAMODB_ENDPOINT="dynamodb.$REGION.amazonaws.com"
export GITHUB_USERNAME="{GITHUB_USERNAME_HERE}"
export DB_TABLE_NAME="$COMPONENT"
export DOMAIN="{DOMAIN_NAME_HERE}"
export EMAIL_SUPPORT="support@${DOMAIN}"
export NODE_PRESERVE_SYMLINKS=1
export TEST_DEPLOYMENT_SUFFIX="-test"
export SLACK_CHANNEL="slack-channel-${ENV}"
export API_VERSION="v1"
export API_BASE_PATH=""
export API_BASE_PATH_PREFIX=""
export API_BASE_PATH_SUFFIX=""
export NODE_MODULES_CLI_DIR="./node_modules/.bin"

Conclusion

Let me know what you think and if you also see any improvement I myself could make to this process!

October 1, 2019 0 comments

Tutorials

How To Deploy To AWS Via The Serverless Framework

by corey.walker June 30, 2019

written by corey.walker

So, you’ve heard all the hype around serverless and wanted to delve in to see what all the hype is about? Here’s a quick simple way to get started in serverless using the Serverless Framework. We’ll be using AWS Cloud using AWS API Gateway, AWS DynamoDB, and AWS Lambda.

Initial Setup

The first thing you will need to do is make sure you have Node.js version ≥ 8 and npm installed. To check whether it is installed, run the following command inside a terminal shell.

node -v
npm -v

If you do not have Node.js version ≥ 8 installed, there are a couple of ways to install it. The first and easier way is visiting the Node.js download web page and download the version you wish to install.

The other way, which is just a little more involved, is to use NVM (Node Version Manager). NVM allows you use have multiple versions of Node.js running on a single system and easily switch between them. To install NVM, run the following in a terminal shell:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

This will install NVM into the current user’s profile instead of being system wide. You will need to quit and restart the terminal application in order for the terminal to pick up the nvm command. Now we need to install Node.js using NVM by doing the following:

nvm install {node version}
nvm use {node version}

Installing AWS CLI

The next to do is install the AWS Command Line Interface (CLI). To do that, you can follow this guide to get that setup. Now let’s setup our AWS credentials so we can actually deploy this sample application to AWS. If you don’t already have AWS IAM credentials pair, you will need to get that. Make sure it has the permissions to create/update/delete CloudFormation templates, API Gateway resources, and Lambda functions. Once you have AWS credentials, follow this guide to setup your credentials so that the Serverless Framework can use them.

Installing Serverless Framework CLI

The next thing you’ll want to do is install the Serverless Framework. You do this by running the following command inside a Terminal shell:

npm install serverless -g

This will install the Serverless Framework as a global package for your machine. If you wish to just install it inside a project’s directory as a dependency of a node application, you can leave off the -g part of the command when you are inside a node project directory.

Creating the Serverless Framework Application

Next, you will want to create a serverless application. There are many different parameters to customize the serverless project for using different languages, cloud providers, etc. However we will be using values to create a Node.js/Typescript based application with AWS as cloud provider. To create and initialize this project, we will run the following commands inside the terminal shell:

serverless create --template aws-nodejs-typescript --path {my-service}
cd {my-service} && npm install

Now open the new {my-service} directory. You should see a project structure that looks like the following:

File listing for new serverless framework project

The Serverless Framework packages your application into a zip package that is deployed via a AWS CloudFormation stack. If you open the serverless.yml file, you will see something like the following:

service:
  name: my-service
#app: your-app-name
#tenant: your-tenant-name# Add the serverless-webpack plugin
plugins:
  - serverless-webpackprovider:
  name: aws
  runtime: nodejs10.xfunctions:
  hello: 
    handler: handler.hello
    events:
      - http:
          method: get
          path: hello

Let’s go over the different pieces of this default template.

service: This will be used to create the name of your AWS CloudFormation stack. The default naming convention of the Serverless Framework is to use {service.name}-{stage}. The stage value can be passed in via CLI argument or default value of production.
plugins: This section allows you to extend functionality of the Serverless Framework using multiple plugins from a list of available plugins. There are plugins for many different tasks. These include adding tags to numerous AWS resources, using versioning in AWS Lambda along with auto pruning old versions, and many many others.
provider: This section specifies all configuration for the cloud provider you wish to deploy your Serverless application to. As of this writing, they support deploying to AWS, Microsoft Azure, Google Cloud, IBM OpenWhisk, Kubeless, Cloudflare, spotinst, and fn as can be seen here. We will be using AWS, whose Serverless config file options are all listed here.
functions: This section is where we configure our AWS Lambda function specification. This section will tell serverless where to find the code in your local project. As well as what AWS API Gateway endpoints will use the Lambda function, what tags and environment variables to assign to the Lambda function, etc.

To deploy this sample application to AWS, run the following command:

serverless deploy -v [-r {desired region}]

Conclusion

Congratulations! You have deployed a Serverless based application to AWS API Gateway and AWS Lambda! In order to test this out, sign into the AWS Cloud Console, select the region you deployed your application to form the upper right menu, then go to the API Gateway service page. You should see your serverless application API listed on the left menu. Click that API, click Stages in the left sub-menu, and then click on the deployed stage. You should now see an Invoke URL link for your API in the right half of the page. Copy that link, paste it in your browser and append /hello to the end of that URL and hit Enter/Return. You should get the desired response that was created in your handler.ts file from the template application!

Now that you have a feeling for how easy it is to deploy Serverless applications to AWS, leave your feedback in the responses section and let me know what you all do with this framework and what you all think of this tutorial!

June 30, 2019 0 comments

Tutorials

How To Host Angular Apps on AWS S3 and CloudFront

by corey.walker March 26, 2019

written by corey.walker

Almost every company and many people without a legal business entity would like to setup a web site for some reason or another. Some only need a static website for informational purposes, such as listing their business address, contact information and services and/or products they offer. Others need a dynamic website that can constantly be updated with new data by people other than those who setup the website. One easy and robust way to setup a simple Angular website that is robust and scales well is to serve it on AWS (Amazon Web Services) S3 and AWS CloudFront.

Intro To AWS S3

AWS S3 is an object storage service offered from Amazon Web Services where you can create “buckets” where you can store almost all types of files in many different regions around the world. You can store Terabytes or more of almost any kind of data. You only pay for the amount of storage you use (you get 5GB free and only pay for the storage above that free tier.) Check out full pricing for AWS S3 here

Intro To AWS CloudFront

AWS CloudFront is a globally distributed caching service that can take the data in an AWS S3 bucket and push it to edge locations around the world so the requests to the content are much quicker for the end users. This is because the request will be routed to the nearest edge location to the user. This is a great use for static websites that would like to see great performance load times for their static website.

Creating an Angular 7 Application

Install the Angular CLI via npm : npm install -g @angular/cli
Create a new Angular application: ng new {project-name}
Run the build command to get a version of the app suitable to deploy to AWS S3: ng build
– This will create a directory named dist with all the resources to be deployed within this directory

That is all that is needed on the Angular side to try out deploying a static website to AWS S3

Setting Up AWS S3

Login to Amazon Web Services
Create an AWS S3 bucket to hold your static website resources such as HTML, CSS, JavaScript, and image files
Click on the bucket you just created and then click the Properties tab
– Choose Use this bucket to host a website
– For both Index Document and Error Document put index.html for the value
– Click Save
Now click on the Permissions tab then Bucket Policy
– Insert the following for the bucket policy (make sure to replace {bucket-name} with the actual bucket name you created). This will allow public access to the contents of your bucket, which is what you want if hosting a website in S3

{
 “Version”: “2012–10–17”,
 “Statement”: [
   {
     “Sid”: “PublicReadGetObject”,
     “Effect”: “Allow”,
     “Principal”: “*”,
     “Action”: “s3:GetObject”,
     “Resource”: “arn:aws:s3:::{bucket-name}/*”
   }
 ]
}

NOTE: I normally also add the default AES-256 encryption for all of my AWS S3 buckets. It does not interfere with the hosting of a website and thus, definitely recommended unless you wish to use KMS which is perfectly fine as well and probably better, although more expensive by far). It can be found under Properties > Default Encryption for your bucket

Your AWS S3 bucket should now be ready to host a static website! Now let’s move onto the other pieces of the setup.

AWS S3 And CloudFormation Setup

Upload contents to your S3 bucket

Login to Amazon Web Services
Go to AWS S3 in the AWS Console
Upload your files and folders to your AWS S3 bucket (Do not include the dist/ parent directory, just the contents inside it)

Verify you can view your static website by visiting your bucket’s public URL

Go to AWS S3 and click on the S3 bucket hosting your website
Click on the Properties tab and then Static Web Hosting
Click on the Endpoint url specified at the top of that section to verify if your website is setup

Create an AWS CloudFront distribution

Navigate to AWS CloudFront via the AWS Console
Click on Create Distribution
Under Web click Get Started
For Origin Domain Name choose the S3 bucket you specified to host your website
For Viewer Protocol Policy the best option is Redirect HTTP to HTTPSalthough any will work, but normally its better to redirect users to HTTPS if they try to hit the HTTP endpoint
Under Distribution Settings choose where all you wish to have your static content distributed to. For now, US, Canada, and Europe will work fine. (The more locations its sent to, the more expensive it will be)
If you already have a domain name you wish to use for this website, enter the domain name for Alternate Domain Names (CNAMEs) field
Enter index.html for Default Root Object
Click Create Distribution button and wait for the listing to show Enabled for State (this normally takes a little while as it pushes all the content to all the edge locations)
You can now check that the distribution is live by visiting the URL listed under Domain Name for your distribution

Customizing Domain Name

If you have a custom domain name you want to use with your CloudFront distribution, you need to setup a few things in AWS Route 53
Navigate to AWS Route 53 via the AWS Console
Click on Hosted Zones then Create Hosted Zone
Enter your domain name and choose Public Hosted Zone
Click on the hosted zone you just created
Make sure the Name Servers are correct based on where you registered your domain name at. Either create or edit to use the name server provided by your domain registrar
Create a new Record Set and choose A — IPv4 Address for Type
Choose Yes for Alias then select your CloudFront Distribution from the list
Click Create
Wait a few minutes for the DNS changes to propagate and try visiting your website using your custom domain name

Conclusion

Congrats! You now have a static Angular website running on AWS S3, AWS CloudFront, and AWS Route 53!

March 26, 2019 0 comments

aws

Internal Microservice Monitoring

Lack of Insight If Environment Is Completely Unreachable

More Effort to Create and Maintain

External Microservice Monitoring

Application Performance Monitoring

Conclusion

Share this:

Like this:

Intro to Sentry Monitoring Service

Setting Up the Sentry’s AWS Lambda CloudFormation Stack

Setting Up Sentry’s AWS Lambda Function Wrapper

Tracking Lambda Function Performance

Conclusion

Share this:

Like this:

Server-Side Encryption Options

Using Standard AWS S3 AES-256 Encryption

Using KMS Managed Key Encryption

Using Customer Managed Key Encryption

Client-Side Encryption

Share this:

Like this:

Controlling Access To S3

Setting Default Accessibility Options For Entire Account

Setting Accessibility Options When Creating a Bucket

Setting Accessibility Options For Specific Buckets

Conclusion

Share this:

Like this:

Initial Multi-Region DNS Fail-over Configuration

Creating An SSL/TLS Certificate

Configuring Health Checks

Monitor Endpoint Configuration

CloudWatch Alarms

Creating Route53 Record Sets

Conclusion

Share this:

Like this:

Intro To Serverless Framework

Configuration

Environment Specific Configurations

Conclusion

Share this:

Like this:

Initial Setup

Installing AWS CLI

Installing Serverless Framework CLI

Creating the Serverless Framework Application

Conclusion

Share this:

Like this:

Intro To AWS S3

Intro To AWS CloudFront

Creating an Angular 7 Application

Setting Up AWS S3

AWS S3 And CloudFormation Setup

Upload contents to your S3 bucket

Verify you can view your static website by visiting your bucket’s public URL

Create an AWS CloudFront distribution

Customizing Domain Name

Conclusion

Share this:

Like this: