DEV Community: Van Hoang Kha

AWS Bookstore Demo App

Van Hoang Kha — Fri, 21 Oct 2022 10:08:41 +0000

AWS Bookstore Demo App

AWS Bookstore Demo App is a full-stack sample web application that creates a storefront (and backend) for customers to shop for fictitious books. The entire application can be created with a single CloudFormation template. Try out the deployed application here!

You can browse and search for books, look at recommendations and best sellers, manage your cart, checkout, view your orders, and more. Get started with building your own below!

Outline

Overview
Instructions
- Getting started
- Cleaning up
Architecture
Implementation details
- Amazon DynamoDB
- Amazon API Gateway
- AWS Lambda
- Amazon ElastiCache for Redis
- Amazon Neptune
- Amazon ElasticSearch
- AWS IAM
- Amazon Cognito
- Amazon Cloudfront and Amazon S3
- Amazon VPC
- Amazon Cloudwatch
- AWS CodeCommit, AWS CodePipeline, AWS CodeBuild
Running your web application locally
Considerations for demo purposes
Known limitations
Additions, forks, and contributions
Questions and contact

Overview

The goal of AWS Bookstore Demo App is to provide a fully-functional web application that utilizes multiple purpose-built AWS databases and native AWS components like Amazon API Gateway and AWS CodePipeline. Increasingly, modern web apps are built using a multitude of different databases. Developers break their large applications into individual components and select the best database for each job. Let's consider AWS Bookstore Demo App as an example. The app contains multiple experiences such a shopping cart, product search, recommendations, and a top sellers list. For each of these use cases, the app makes use of a purpose-built database so the developer never has to compromise on functionality, performance, or scale.

The provided CloudFormation template automates the entire creation and deployment of AWS Bookstore Demo App. The template includes the following components:

Database components

Product catalog/shopping cart - Amazon DynamoDB offers fast, predictable performance for the key-value lookups needed in the product catalog, as well as the shopping cart and order history. In this implementation, we have unique identifiers, titles, descriptions, quantities, locations, and price.
Search - Amazon Elasticsearch Service enables full-text search for our storefront, enabling users to find products based on a variety of terms including author, title, and category.
Recommendations - Amazon Neptune provides social recommendations based on what user's friends have purchased, scaling as the storefront grows with more products, pages, and users.
Top sellers list - Amazon ElastiCache for Redis reads order information from Amazon DynamoDB Streams, creating a leaderboard of the “Top 20” purchased or rated books.

Application components

Serverless service backend – Amazon API Gateway powers the interface layer between the frontend and backend, and invokes serverless compute with AWS Lambda.
Web application blueprint – We include a React web application pre-integrated out-of-the-box with tools such as React Bootstrap, Redux, React Router, internationalization, and more.

Infrastructure components

Continuous deployment code pipeline – AWS CodePipeline and AWS CodeBuild help you build, test, and release your application code.
Serverless web application – Amazon CloudFront and Amazon S3 provide a globally-distributed application.

You can choose to customize the template to create your own bookstore, modify it to make a different type of store, or change it to make a completely different type of web application.

AWS Bookstore Demo App is built on-top of AWS Full-Stack Template, which provides the foundational services, components, and plumbing needed to get a basic web application up and running. Users can build on top of AWS Full-Stack Template to create any application they envision, whether a travel booking tool, a blog, or another web app. This AWS Bookstore Demo App is just one example of what you can create using AWS Full-Stack Template.

Watch the recorded talk and demo here.

Instructions

**IMPORTANT NOTE: Creating this demo application in your AWS account will create and consume AWS resources, which **will cost money. We estimate that running this demo application will cost ~$0.45/hour* with light usage. Be sure to shut down/remove all resources once you are finished to avoid ongoing charges to your AWS account (see instructions on cleaning up/tear down below).*

Getting started

To get AWS Bookstore Demo App up and running in your own AWS account, follow these steps (if you do not have an AWS account, please see How do I create and activate a new Amazon Web Services account?):

Log into the AWS console if you are not already. Note: If you are logged in as an IAM user, ensure your account has permissions to create and manage the necessary resources and components for this application.
Choose one of the Launch Stack buttons below for your desired AWS region to open the AWS CloudFormation console and create a new stack. AWS Bookstore Demo App is supported in the following regions:

Region name	Region code	Launch
US East (N. Virginia)	us-east-1
US West (Oregon)	us-west-2
EU (Ireland)	eu-west-1
EU (Frankfurt)	eu-central-1

Continue through the CloudFormation wizard steps
1. Name your stack, e.g. MyBookstore
2. Name your S3 bucket (must be lowercase and has to be unique across all existing bucket names in Amazon S3). See bucket naming rules.
3. Provide a project name (must be lowercase, letters only, and under twelve (12) characters). This is used when naming your resources, e.g. tables, search domain, etc.
4. After reviewing, check the blue box for creating IAM resources.
Choose Create stack. This will take ~20 minutes to complete.
Once the CloudFormation deployment is complete, check the status of the build in the CodePipeline console and ensure it has succeeded.
Sign into your application
1. The output of the CloudFormation stack creation will provide a CloudFront URL (in the Outputs table of your stack details page). Click the link or copy and paste the CloudFront URL into your browser.
2. You can sign into your application by registering an email address and a password. Choose Sign up to explore the demo to register. The registration/login experience is run in your AWS account, and the supplied credentials are stored in Amazon Cognito. Note: given that this is a demo application, we highly suggest that you do not use an email and password combination that you use for other purposes (such as an AWS account, email, or e-commerce site).
3. Once you provide your credentials, you will receive a verification code at the email address you provided. Upon entering this verification code, you will be signed into the application.

Advanced: The source CloudFormation template is available here. If you want to maintain low latency for your app, this deeplink will create an identical stack, but with additional triggers to keep the Lamdba functions "warm" (CloudFormation template here). For more information, see the Considerations for demo purposes section.

Cleaning up

To tear down your application and remove all resources associated with AWS Bookstore Demo App, follow these steps:

Log into the Amazon S3 Console and delete the buckets created for the demo app.
- There should be two buckets created for AWS Bookstore Demo App. The buckets will be titled "X" and "X-pipeline", where "X" is the name you specified in the CloudFormation wizard under the AssetsBucketName parameter.
- Note: Please be **very careful* to only delete the buckets associated with this app that you are absolutely sure you want to delete.*
Log into the AWS CloudFormation Console and find the stack you created for the demo app
Delete the stack

Remember to shut down/remove all related resources once you are finished to avoid ongoing charges to your AWS account.

Architecture

Summary diagram

High-level, end-to-end diagram

Frontend

Build artifacts are stored in a S3 bucket where web application assets are maintained (like book cover photos, web graphics, etc.). Amazon CloudFront caches the frontend content from S3, presenting the application to the user via a CloudFront distribution. The frontend interacts with Amazon Cognito and Amazon API Gateway only. Amazon Cognito is used for all authentication requests, whereas API Gateway (and Lambda) is used for all API calls interacting across DynamoDB, Elasticsearch, ElastiCache, and Neptune.

Backend

The core of the backend infrastructure consists of Amazon Cognito, Amazon DynamoDB, AWS Lambda, and Amazon API Gateway. The application leverages Amazon Cognito for user authentication, and Amazon DynamoDB to store all of the data for books, orders, and the checkout cart. As books and orders are added, Amazon DynamoDB Streams push updates to AWS Lambda functions that update the Amazon Elasticsearch cluster and Amazon ElasticCache for Redis cluster. Amazon Elasticsearch powers search functionality for books, and Amazon Neptune stores information on a user's social graph and book purchases to power recommendations. Amazon ElasticCache for Redis powers the books leaderboard.

Developer Tools

The code is hosted in AWS CodeCommit. AWS CodePipeline builds the web application using AWS CodeBuild. After successfully building, CodeBuild copies the build artifacts into a S3 bucket where the web application assets are maintained (like book cover photos, web graphics, etc.). Along with uploading to Amazon S3, CodeBuild invalidates the cache so users always see the latest experience when accessing the storefront through the Amazon CloudFront distribution. AWS CodeCommit. AWS CodePipeline, and AWS CodeBuild are used in the deployment and update processes only, not while the application is in a steady-state of use.

Implementation details

Note: The provided CloudFormation template contains only a portion of the resources needed to create and run the application. There are web assets (images, etc.), Lambda functions, and other resources called from the template to create the full experience. These resources are stored in a public-facing S3 bucket and referenced in the template.

Amazon DynamoDB

The backend of AWS Bookstore Demo App leverages Amazon DynamoDB to enable dynamic scaling and the ability to add features as we rapidly improve our e-commerce application. The application create three tables in DynamoDB: Books, Orders, and Cart. DynamoDB's primary key consists of a partition (hash) key and an optional sort (range) key. The primary key (partition and sort key together) must be unique.

Books Table:

BooksTable {
  id: string (primary partition key)
  author: string
  category: string (index, GSI)
  cover: string (url to s3 file)
  name: string 
  price: number
  rating: number
}

The table's partition key is the ID attribute of a book. The partition key allows you to look up a book with just the ID. Additionally, there is a global secondary index (GSI) on the category attribute. The GSI allows you to run a query on the category attribute and build the books by category experience.

For future updates to the application, we plan to return the results of a search/filter by category via Elasticsearch. Additionally, there is no “description” attribute, as this sample application does not feature pages for individual books. This may be something users wish to add.

Orders Table:

OrdersTable {
    customerId: string (primary partition key)
    orderId: string (uuid, primary sort key)
    books: bookDetail[]
    orderDate: date 
}

bookDetail {
    bookId: string
    customerId: string
    quantity: number
    price: number
}

The order table's partition key is the customer ID. This allows us to look up all orders of the customer with just their ID.

Cart Table:

CartTable {
    customerId: string (primary partition key)
    bookId: string (uuid, primary sort key)
    price: number
    quantity: number
}

The cart table stores information about a customer's saved cart.

Amazon API Gateway

Amazon API Gateway acts as the interface layer between the frontend (Amazon CloudFront, Amazon S3) and AWS Lambda, which calls the backend (databases, etc.). Below are the different APIs the application uses:

Books (DynamoDB)

GET /books (ListBooks)

GET /books/{:id} (GetBook)

Cart (DynamoDB)

GET /cart (ListItemsInCart)

POST /cart (AddToCart)

PUT /cart (UpdateCart)

DELETE /cart (RemoveFromCart)

GET /cart/{:bookId} (GetCartItem)

Orders (DynamoDB)

GET /orders (ListOrders)

POST /orders (Checkout)

Best Sellers (ElastiCache)

GET /bestsellers (GetBestSellers)

Recommendations (Neptune)

GET /recommendations (GetRecommendations)

GET /recommendations/{bookId} (GetRecommendationsByBook)

Search (Elasticsearch)

GET /search (SearchES)

AWS Lambda

AWS Lambda is used in a few different places to run the application, as shown in the architecture diagram. The important Lambda functions that are deployed as part of the template are shown below, and available in the functions folder. In the cases where the response fields are blank, the application will return a statusCode 200 or 500 for success or failure, respectively.

ListBooks
Lambda function that lists the books in the specified product category

ListBooksRequest {
    category?: string (optional parameter)  
}

ListBooksResponse {
    books: book[]
}

book {
    id: string
    category: string
    name: string 
    author: string
    description: string
    rating: number
    price: number
    cover: string
}

GetBook
Lambda function that will return the properties of a book.

GetBookRequest {
  bookId: string
}

GetBookResponse {
    id: string
    category: string
    name: string 
    author: string
    description: string
    rating: number
    price: number
    cover: string
}

ListItemsInCart
Lambda function that lists the orders a user has placed.

ListItemsInCartRequest {

}

ListItemsInCartResponse {
    orders[]
}

order {
    customerId: string
    bookId: string
    quantity: number
    price: number
}

AddToCart
Lambda function that adds a specified book to the user's cart. Price is included in this function's request so that the price is passed into the cart table in DynamoDB. This could reflect that the price in the cart may be different than the price in the catalog (i.e. books table) perhaps due to discounts or coupons.

AddToCartRequest {
    bookId: string
    quantity: number
    price: number
}

AddToCartResponse {

}

RemoveFromCart
Lambda function that removes a given book from the user's cart.

RemoveFromCartRequest {
    bookId: string
}

RemoveFromCartResponse {

}

GetCartItem
Lambda function that returns the details of a given item the user's cart.

GetCartItemRequest {
    bookId: string
}

GetCartItemResponse {
    customerId: string
    bookId: string
    quantity: number
    price: number
}

UpdateCart
Lambda function that updates the user's cart with a new quantity of a given book.

UpdateCartRequest {
    bookId: string
    quantity: number
}

UpdateCartResponse {

}

ListOrders
Lambda function that lists the orders for a user.

ListOrdersRequest {

}

ListOrdersResponse {
    customerId: string 
    orderId: string
    orderDate: date
    books: bookDetail[]
}

bookDetail {
    bookId: string
    price: number
    quantity: number
}

Checkout
Lambda function that moves the contents of a user's cart (the books) into the checkout flow, where you can then integrate with payment, etc.

CheckoutRequest {
    books: bookDetail[]
}

bookDetail {
    bookId: string
    price: number
    quantity: number
}

CheckoutResponse {

}

In addition to the above, the Checkout Lambda function acts as a sort of mini-workflow with the following tasks:

Add all books from the Cart table to the Orders table
Remove all entries from the Cart table for the requested customer ID

GetBestSellers
Lambda function that returns a list of the best-sellers.

GetBestSellersRequest {

}

GetBestSellersResponse {
    bookIds: string[]
}

GetRecommendations
Lambda function that returns a list of recommended books based on the purchase history of a user's friends.

GetRecommendationsRequest {

}

GetRecommendationsResponse {
    recommendations: recommendation[]
}

recommendation {
    bookId: string
    friendsPurchased: customerId[]
    purchases: number
}

customerId: string

GetRecommendationsByBook
Lambda function that returns a list of friends who have purchased this book as well as the total number of times it was purchased by those friends.

GetRecommendationsByBookRequest {
    bookId: string
}

GetRecommendationsByBookResponse {
    friendsPurchased: customerId[]
    purchased: number
}

customerId: string

Other Lambda functions
There are a few other Lambda functions used to make AWS Bookstore Demo App work, and they are listed here:

Search - Lambda function that returns a list of books based on provided search parameters in the request.
updateSearchCluster - Lambda function that updates the Elasticsearch cluster when new books are added to the store.
updateBestsellers - Updates Leaderboard via the ElastiCache for Redis cluster as orders are placed.

Amazon ElastiCache for Redis

Amazon ElastiCache for Redis is used to provide the best sellers/leaderboard functionality. In other words, the books that are the most ordered will be shown dynamically at the top of the best sellers list.

For the purposes of creating the leaderboard, AWS Bookstore Demo App utilized ZINCRBY, which “Increments the score of member in the sorted set stored at key byincrement. If member does not exist in the sorted set, it is added with increment as its score (as if its previous score was 0.0). If key does not exist, a new sorted set with the specified member as its sole member is created.”

The information to populate the leaderboard is provided from DynamoDB via DynamoDB Streams. Whenever an order is placed (and subsequently created in the Orders table), this is streamed to Lambda, which updates the cache in ElastiCache for Redis. The Lambda function used to pass this information is UpdateBestSellers.

Amazon Neptune

Neptune provides a social graph that consists of users, books. Recommendations are only provided for books that have been purchased (i.e. in the list of orders). The “top 5” book recommendations are shown on the bookstore homepage.

Amazon Elasticsearch

Amazon Elasticsearch Service powers the search capability in the bookstore web application, available towards the top of every screen in a search bar. Users can search by title, author, and category. The template creates a search domain in the Elasticsearch service.

It is important that a service-linked role is created first (included in the CloudFormation template).

AWS IAM

ListBooksLambda
AWSLambdaBasicExecutionRole

dynamodb:Scan - table/Books/index/category-index

dynamodb:Query - table/Books

GetBookLambda
AWSLambdaBasicExecutionRole

dynamodb:GetItem - table/Books

ListItemsInCartLambda
AWSLambdaBasicExecutionRole

dynamodb:Query - table/Cart

AddToCartLambda
AWSLambdaBasicExecutionRole

dynamodb:PutItem - table/Cart

UpdateCartLambda
AWSLambdaBasicExecutionRole

dynamodb:UpdateItem - table/Cart

ListOrdersLambda
AWSLambdaBasicExecutionRole

dynamodb:Query - table/Orders

CheckoutLambda
AWSLambdaBasicExecutionRole

dynamodb:PutItem - table/Orders

dynamoDB:DeleteItem - table/Cart

Amazon Cognito

Amazon Cognito handles user account creation and login for the bookstore application. For the purposes of the demo, the bookstore is only available to browse after login, which could represent the architecture of different types of web apps. Users can also choose to separate the architecture, where portions of the web app are publicly available and others are available upon login.

User Authentication

Email address

Amazon Cognito passes the CognitoIdentityID (which AWS Bookstore Demo app uses as the Customer ID) for every user along with every request from Amazon API Gateway to Lambda, which helps the services authenticate against which user is doing what.

Amazon CloudFront and Amazon S3

Amazon CloudFront hosts the web application frontend that users interface with. This includes web assets like pages and images. For demo purposes, CloudFormation pulls these resources from S3.

Amazon VPC

Amazon VPC (Virtual Private Cloud) is used with Amazon Elasticsearch Service, Amazon ElastiCache for Redis, and Amazon Neptune.

Amazon CloudWatch

The capabilities provided by CloudWatch are not exposed to the end users of the web app, rather the developer/administrator can use CloudWatch logs, alarms, and graphs to track the usage and performance of their web application.

AWS CodeCommit, AWS CodePipeline, AWS CodeBuild

Similar to CloudWatch, the capabilities provided by CodeCommit, CodePipeline, and CodeBuild are not exposed to the end users of the web app. The developer/administrator can use these tools to help stage and deploy the application as it is updated and improved.

Running your web application locally

If you haven't setup Git credentials for AWS CodeCommit before, head to the IAM Console. If you have already you can skip to step 5.
Choose your IAM user.
Choose the Security credentials tab. Scroll to the bottom and choose Generate underneath HTTPS Git credentials for AWS CodeCommit.
Download and save these credentials. You will use these credentials when cloning your repository.
Go to the CodeCommit console and find your code repository.
Choose the HTTPS button underneath the Clone URL column.
Open up your terminal, type git clone paste the Clone URL and hit enter.
Once the repository has created, run npm install.
After all dependencies have been downloaded, run npm run start.

You're done! Any future updates you make to your repository will get pushed to your code pipeline automatically and published to your web application endpoint.

Considerations for demo purposes

In order to make AWS Bookstore Demo App an effective demonstration from the moment it is created, the CloudFormation template kicks off a Lambda function we wrote to pre-load a list of books into the product catalog (the Books table in DynamoDB). In the same way, we used a Lambda function to pre-load sample friends (into Neptune) and manually populated the list of Best Sellers (on the front page only). This enables you to sign up as a new user and immediately see what the running store would look like, including recommendations based on what friends have purchased and what the best-selling books section does.
You will notice that the Past orders and Best sellers pages are empty at first run. These are updated as soon as an order is placed.
For the purposes of this demo, we did not include a method to add or remove friends, and decided that every new user will be friends with everyone else (not the most realistic, but effective for this demo). You are welcome to play around with changing this, adding friend control functionality, or manually editing friendships via the bookstore-friends-edges.csv file.
Web assets (pages, images, etc.) are pulled from a public S3 bucket via the CloudFormation template to create the frontend for AWS Bookstore Demo App. When building your own web application (or customizing this one), you will likely pull from your own S3 buckets. If you customize the lambda functions, you will want to store these separately, as well.
Checkout is a simplified demo experience that customers can take and implement a real-world payment processing platform. Similarly, the View Receipt button after purchase is non-functional, meant to demonstrate how you can add on to the app.
The CloudFormation template referenced in #2 of the Getting started section is everything you need to create the full-stack application. However, when the application is newly created, or hasn't been used in some time, it may take a few extra seconds to run the Lamdba functions, which increases the latency of operations like search and listing books. If you want to maintain low latency for your app, this deeplink creates an identical stack but with additional triggers to keep the Lamdba functions "warm." Given that these triggers make the Lamdba functions run more frequently (every 10 minutes, on a schedule), this will add a small amount to the overall cost to run the application. The benefit is a more responsive application even when the Lamdba functions are not being regularly called by user activity.

Known limitations

The application was written for demonstration purposes and not for production use.
Orders are backed by DynamoDB, but no mechanism exists to recreate the best sellers list in the unlikely scenario of a Redis failure.
Upon the first use of a Lambda function, cold start times in a VPC can be slow. Once the Lambda function has been warmed up, performance will improve. See #6 in Considerations for demo purposes for more information.
The application is not currently designed for for high availability. You can increase the availability of the application by configuring the Amazon Elasticsearch, Amazon Neptune, and Amazon ElastiCache clusters with multiple instances across multiple AZs.
The application enables multiple users to sign into the application but the social graph is single user. As a result, different users will see the same social graph. Further, when new books are purchased, that state is not reflected in the social graph.
There are some network errors observed on Firefox. We are looking into this.

Additions, forks, and contributions

We are excited that you are interested in using AWS Bookstore Demo App! This is a great place to start if you are just beginning with AWS and want to get a functional application up and running. It is equally useful if you are looking for a sample full-stack application to fork off of and build your own custom application. We encourage developer participation via contributions and suggested additions. Of course you are welcome to create your own version!

Please see the contributing guidelines for more information.

For a more basic example of a full-stack web application, check out AWS Full-Stack Template upon which AWS Bookstore Demo App was built. As mentioned in the Overview section, AWS Full-Stack Template provides the foundational services, components, and plumbing needed to get a basic web application up and running. Users can build on top of AWS Full-Stack Template to create any application they envision, whether a travel booking tool, a blog, or another web app. This AWS Bookstore Demo App is just one example of what you can create using AWS Full-Stack Template.

Cost-Effective AWS Architectures for Wordpress

Van Hoang Kha — Wed, 19 Oct 2022 11:33:30 +0000

Cost-Effective AWS Architectures for Wordpress (and other websites)

‍
Cost-Effective Architectures on AWS for WordPress. Step through Amazon's reference architecture to see what solution is right for you.

AWS Wordpress Reference Architecture

For a beginner or someone looking to run a small blog or e-commerce site, this diagram is crazy complicated. I started writing this post because I wanted to understand the reasons behind recommending an architecture like this by breaking it down into the individual components and services.

What is all that stuff for?
What do I really need?
How much is it going to cost me?

This post works through an example that starts with a simple single-server deployment and adds one AWS service or feature at a time to build up to the complex diagram at the top. We will look into the benefit and the cost of each one so that you can make educated decisions on how to deploy your architecture. The estimated costs are for comparative purposes; every deployment will be different. Be sure to analyze your unique situation before deploying services that will cost you money.

In reality, most implementations will not be the simplest nor the most complex, but somewhere in the middle.

There are sites like wordpress.com, SquareSpace, and Wix, that will host your site for you. Amazon also offers LightSail, a managed solution for deploying WordPress (and other types of sites). One of these may be the cheapest and easiest solution, but there are also several reasons an individual or small business would want to run their own site. You may or may not want to use Wordpress, and I’m not going to debate whether on not that is the right idea. This post has information that is applicable to many different types of sites hosted on AWS.

In its simplest form, we could run Wordpress on a single server like the diagram below. All we need is an EC2 instance running Wordpress, a simple VPC with an internet gateway, and DNS configured to point our domain name to this server.

So how does this simple diagram become the complicated one above? The short answer is that all that stuff provides scalability, availability, redundancy, speed, and configurability.

If you are considering deploying or scaling up your site, I hope this post will help you decide the most cost-effective way to do it. What AWS Services can you take advantage of that will give you the best bang for your buck? And what services will leave you feeling taken advantage of with high costs and little return?

Wordpress Architecture

Looking at the Wordpress application itself, it does four main things (architecturally speaking).

Hosts static content (CSS, javascript, theme files)
Hosts dynamic content (using PHP - see below)
Stores database content (blog posts and page content)
Stores uploaded files (i.e., pictures) on the file system

In the simple setup, all of these functions are provided by the single EC2 host. As the architecture grows, you will see that we can offload each of these functions to other AWS services, as shown in the diagram below.

Also, we need to know a little bit about PHP and how it works. Wordpress is written in PHP, which is a server-side scripting language. This means that as users visit the site, the PHP code loads data from the database and dynamically creates the HTML needed for our web browsers to show content. The web server has to compute the HTML code every time for every page visited by every user. For high traffic sites, this can be a lot of computation.

Assumptions & Cost Estimations

For this example, we need to make some assumptions. Let's say we are planning on building a personal blog with a healthy amount of traffic - around 10,000 visitors per month. This is a good amount of traffic for a personal blog or small business website, but still much less traffic than what some WordPress sites see. Costs for some of the services we add below are proportional to the traffic volume the site receives, while others are not dependent on traffic volume at all. I will point this out as we add the various services.

EC2, RDS, and ElastiCache are all priced by instances and offer many different pricing options and payment plans. We will look at different instance types and sizes, but the price will always be based on the 1-year standard plan reserved instance. This will help us to compare apples to apples. However, you could potentially save more money with a different payment plan.

Amazon also has different rates for some services based on region. For all the cost estimations in this post, I used the us-east-1 region prices, but this shouldn't affect things that much.

1. The Simple Setup

The simple setup is Wordpress running on a single EC2 instance with your domain name pointed to your server's public IP address.

You can use Amazon's Route 53 or your own registrar's DNS service. Route 53 costs 50 cents per month, and your registrar (i.e., GoDaddy) is usually free. The EC2 instance cost can vary significantly depending on what instance type and purchasing plan you choose. Setting up a simple, low traffic site shouldn't require anything more significant than a t3.small instance, which costs $8.92/mo on the annual plan.

It's worth noting that we have not addressed any backup scheme. This instance could die anytime, and you could lose everything: the entire database, all themes, and configs, all blog posts, etc. You should employ a backup strategy with this setup, but that is a separate topic for another day.

Estimated Monthly Cost: $9.42

2. Add CloudFront

Adding CloudFront is one of the best things you can do for your website. CloudFront is a content delivery network (CDN). There are several CDN providers, but CloudFront is the service offered by Amazon. CDNs copy the content on your server to locations around the world.

This setup has some distinct advantages to you:

Your users will experience faster load times. With the edge locations likely closer to them than your primary server, they will see a speed boost.
CloudFront serving your webpages means that it offloads compute utilization from your server, allowing you to possibly use a smaller instance size than you would otherwise need.Static content is cached and served to users directly from CloudFront's edge locations. (Your server still has to handle dynamic content and service requests for static content from the CloudFront servers as they update their cache.) CloudFront can also terminate SSL/TLS, saving more compute capacity on your server.
The speed boost seen by users is also recognized by search engines and will help boost your site's SEO. Pages that load faster will be ranked better and have a better chance of showing up at the top of Google search results.

Added Monthly Cost: $2.75 (rough estimate based on 10,000 page views)

Total Monthly Cost: $12.17

Note that CloudFront costs can significantly increase with increased traffic volume. If you have monetized your site, increased traffic should mean more revenue for you, and this won't be an issue.

3. Add RDS

Move your database off of the main EC2 instance to Amazon Aurora. Amazon Aurora is a MySQL compliant, fully managed database from Amazon. In doing this, we do need to create a new private subnet for the Aurora instance. Adding the subnet will not cost us any more, but will provide better security for your data.

Using Aurora will give you the following benefits:

As a fully-managed database, you do not need to be worried about OS patches or software upgrades. When you manage the database on your main EC2 instance, you should always make sure these things are up-to-date to avoid security vulnerabilities. Aurora handles this for you.
Simple backups with more features and flexibility than the simple setup.
Better security with a private subnet. Having your database run on a server that is publicly addressable on the internet is generally considered poor security practice. You can better defend an instance running in a private subnet using access control lists and security groups.

Added Monthly Cost: $19.83 (Aurora Instances only; no backup storage)

Total Monthly Cost: $32.00

4. Add Multiple Availability Zones w/ Load Balancer

So far, although we have added a couple of new services, we still have a few spots that could be a single point of failure. If the one EC2 instance or the one Aurora DB instance goes down, the site will be unavailable. To guard against this, you can add redundancy with a second EC2 instance and a read-replica instance for Aurora. A good way to implement this is to use a separate availability zone (AZ). This does come with increased costs. We need to add two additional servers as well as an application load balancer.

Even with the significant cost jump, this solution has the following benefits:

EC2 server redundancy. If one of the EC2 servers fails, the other seamlessly picks up all the traffic.
Aurora DB failover. As a managed database service, Aurora DB will automatically handle any failures. Unlike the EC2 configuration, where both servers are essentially the same, the database servers operate in a master and read-replica configuration. This means that data can be read from either server, but only written to the master. If the read-replica is the one that fails, the master handles all the traffic (both read and write). If the master fails, Aurora recognizes this and converts the read-replica to function as the master.
Reduced server load. The application load balancer distributes users across the EC2 instances. Likewise, with 2 DB instances, reads are distributed between the two, reducing the load on each.
Availability Zone separation. Some failures that could make your EC2 instance or DB unavailable are due to software bugs, running out of disk space, or other similar issues. Simple redundancy can mitigate these types of failures. But what if there's an issue that impacts the entire data center? Amazon availability zones are designed to be independent and separate. An event (power outage, weather, etc.) affecting their data center for one AZ will not impact any other AZ. When you deploy your solution to multiple AZs, you benefit from this logical and physical separation.

The reference architecture diagram shows the use of only two AZs, but you could use more to make your website even more robust. The template generatorfor this architecture assumes you are setting up three AZs. For costing this example, we will assume only two AZs. We need to add only one additional EC2 instance, one additional Aurora instance, and an application load balancer.

Added Monthly Cost: $45.18

Total Monthly Cost: $77.18

5. Add Auto-Scaling

In the previous architecture setup, we went from one to two EC2 instances. Adding auto-scaling allows you to spin up as many EC2 instances as you need to meet the current demand. For this relatively small website, two servers are plenty. The nice thing about auto-scaling is that you don't pay for it unless you use it. You can add auto-scaling to your site as a just in case measure to make sure your users always have access. If you are hosting a blog and a specific post goes viral, auto-scaling can provision servers to handle the spike in traffic, and will only create additional cost for you while you have the spike. Auto-scaling will then shutdown unneeded servers when the spike is over.

For this example, we could set up the auto-scaling group to be a minimum of 2 (the instances we set up in the last step) and a max of 10. If you generally have a low amount of traffic, only the two servers will be on, but your site will still handle large spikes in demand.

Added Monthly Cost: $0.00 (unless there's a spike in traffic)

Total Monthly Cost: $77.18

6. Add Private Subnets w/ NAT

Move the EC2 instances to a private subnet. In a previous step, We created private subnets for the Aurora DB servers. There, we discussed the security benefit of putting servers into private subnets. We can do this for the EC2 instances as well. In this configuration, the application load balancer is publicly addressable on the internet, while all our other servers (so far) are not. While this adds security, it comes with a catch: the EC2 instances can no longer reach the internet! While this isn't a problem for your users, you need internet access to update and maintain the servers. This includes security and OS patches or software upgrades. To give these servers internet access, we need to add a NAT gateway or NAT instance. The NAT gateway is easier to configure and requires less maintenance; therefore, I recommend the NAT Gateway over the NAT instance.

NAT gateways have a high cost compared to the other services we have implemented. The reference architecture adds a NAT to both subnets. Each will run about $40 per month if they run continuously. Here are a couple of things to know about NATs on AWS:

A NAT gateway in one subnet can be accessed by instances in other private subnets, even in other AZs
You probably don't need to run NAT gateways all the time. Since these are used for outbound internet access only, and the use case for this is likely OS patches and software updates, you can probably turn these on only when performing those duties. If you can, I recommend not running these instances all the time or only using one instance. If you only turn on these instances when you need them, they will cost you almost nothing per month. However, since we are looking at the reference architecture, which adds two of them (all the time), we will include their full-time use in the cost estimate, but you can do this cheaper.

Added Monthly Cost: $65.70

Total Monthly Cost: $142.88

7. Add Caching w/ Memcached

Memcached is an open-source, high-performance, distributed memory caching system. The AWS ElastiCache service provides a choice between Redis and Memcached for in-memory caching. We don't need to discuss the differences here as the reference architecture specified Memcached, so we will use that. It does not make a big difference in the pricing. A cache is meant to speed things up, so is it worth it? The two main benefits you can expect to get from using the cache are:

Faster response times for your users (and for search engine SEO).
Less burden on your database instances that could allow you to select smaller instance types.

The cache in this architecture sits between the EC2 instances and the database servers. This helps speed up the PHP code executing on the EC2 instances by returning database queries faster. This brings the most benefit for sites that are mostly static (like blogs and small business websites). Stress-test analysis demonstrates that using a cache like Memcached can significantly improve the performance of the server.

Added Monthly Cost: $31.67

Total Monthly Cost: $174.55

8. Add EFS

Amazon Elastic File System (EFS) is a shared file system (similar to NFS) that allows each of your EC2 instances access to the same shared disk space. Wordpress stores uploaded files (like pictures in blog posts) to the local filesystem. With multiple EC2 instances, an uploaded file may be uploaded on one instance and need to be accessed by another instance. Shared disk space is essential to simplify the EC2 configuration, especially when using autoscaling. Using EFS, you can make the web tier completely stateless, so running and scaling EC2 servers is as easy as just turning them on and off. There is no need to synchronize files between nodes in the cluster.

The main benefit of using EFS is the stateless Web tier. When EC2 instances startup, they mount the EFS drive and are off to the races. Without EFS, you need to find a solution that synchronizes files between your EC2 instances.

Added Monthly Cost: $15.00

Total Monthly Cost: $189.55

9. Add Bastion Host

Bastion hosts provide you secure access to your EC2 instances that are in private subnets. While the private subnets offer better security by blocking some attack vectors from the bad guys, they also prevent you from directly accessing the instances over the internet. The Bastion host option could be included with #6 (adding private subnets) in this post, but I did want to discuss it separately.

AWS recommends bastion hosts to provide better security, but they come with additional costs. Both in the actual AWS bill you receive and the additional administrative burden of more EC2 hosts (the whitepaper only shows one Bastion host, but puts it in an autoscaling group suggesting that you might need to add more to handle the increased load).

Since only system administrators use these hosts to monitor and maintain the site, you would only need to set up auto-scaling for very busy sites. As an alternative, you could use public subnets combined with AWS EC2 Systems Manager, access control lists, security groups, CloudWatch, and CloudTrail, which may provide a cheaper way to achieve a similar security posture.

Added Monthly Cost: $8.83

Total Monthly Cost: $198.38

10. Add S3 for Static Content

Amazon Simple Storage Service (S3) is one of the more popular services on AWS. It provides a simple interface for storing files in the cloud in "buckets." You are probably already familiar with this service. In addition to simply storing files, it can be used to host static websites at a very low cost.

You can turn on website hosting for a specific bucket and add that bucket as an origin for CloudFront. This allows you to run a static website without any server at all. In this example, we will offload the static content hosting from the EC2 Wordpress instance by moving the static site files (CSS, JavaScript) to S3. This can be done using a WordPress plain like W3 Total Cache. The main benefit of using S3 for static content is to lighten the load on the EC2 instance. Implementing this last step, the EC2 instance is now only charged with processing the PHP and rendering the HTML files for users.

Added Monthly Cost: $5.00

Total Monthly Cost: $203.38

Conclusion

There we have it. You can run a WordPress site using the Amazon reference architecture for about $200 per month. Remember, I am not recommending this and all of these services for everyone. I hope that this guide helps you choose the right services for you.

Other topics to explore (maybe for another time) as you implement WordPress on AWS:

Backups - Depending on how you back up the database and file system content, you could add high costs.
WAF - Web Application Firewall can provide additional security and defend against denial of service attacks. I am surprised WAF is not included in the reference architecture but may be something to consider.

Thanks for reading!

References

Author: Hoang Kha

Run event-driven workflows with Amazon EKS and AWS Step Functions

Van Hoang Kha — Sun, 04 Sep 2022 14:36:35 +0000

Introduction
Event-driven computing is a common pattern in modern application development with microservices, which is a great fit for building resilient and scalable software in AWS. Event-driven computing needs to be push-based with event-driven applications that are run on-demand when an event triggers the functional workflow. Tools that help you minimize resource usage and reduce costs are essential. Instead of running systems continuously while you wait for an event to occur, event-driven applications are more efficient because they start when the event occurs and terminate when processing completes. Additionally, event-driven architectures with Smart Endpoints and Dump Pipes patterns further decouple services, which makes it easier to develop, scale, and maintain complex systems.

This post demonstrates a proof-of-concept implementation that uses Kubernetes to execute code in response to an event. The workflow is powered by AWS Step Functions, which is a low-code, visual workflow service that helps you build distributed applications using AWS services. AWS Step Functions integrates with Amazon Elastic Kubernetes Service (Amazon EKS), making it easy to build event-driven workflows that orchestrate jobs running on Kubernetes with AWS services, such as AWS Lambda, Amazon Simple Notification Service (Amazon SNS), and Amazon Simple Queue Service (Amazon SQS), with minimal code.

Calling Amazon EKS with AWS Step Functions
AWS Step Functions integration with Amazon EKS creates a workflow that creates and deletes resources in your Amazon EKS cluster. You also benefit from built in error-handling that handles task failures or transient issues.

AWS Step Functions provide eks:runJob service integration that allows you to run a job on your Amazon EKS cluster. The eks:runJob.sync variant allows you to wait for the job to complete and retrieve logs.

We use AWS Step Functions to orchestrate an AWS Lambda function and a Map state ("Type": "Map") that runs a set of steps for each element of an input array. A Map state executes the same steps for multiple entries of an array with the state input.

Solution overview
The following diagram demonstrates the solution to run a sample event-driven workflow using Amazon EKS and AWS Step Functions.

For this demonstration, we use AWS Cloud Development Kit (AWS CDK) and first deploy a set of AWS CDK stacks to create and deploy necessary infrastructure, as shown in the previous diagram. AWS Step Functions invoke when an input file appears in the configured Amazon Simple Storage Service (Amazon S3) bucket.

AWS Step Functions starts the following process when a new file appears in the Amazon S3 bucket:

AWS Step Functions create a File Splitter Kubernetes job that runs in an Amazon EKS cluster. The job reads the input file from the Amazon S3 bucket and splits the large input file into smaller files, saving them to an Amazon Elastic File System (Amazon EFS) persistent volume.
File Splitter Kubernetes job uses the unix split command to chunk the large files into smaller ones, with each file containing a maximum of 30,000 lines (which is configured using MAX_LINES_PER_BATCH environment variable).
File splitter Kubernetes job saves the path of the split files in Amazon ElastiCache (Redis) that are used for tracking the overall progress of this job. The data in the Redis cache gets stored in the following format:
Screenshots showing the format of data stored in Redis cache.

AWS Step Functions orchestrate a Split-file-lambda AWS Lambda function that reads the Redis cache and returns an array of split file locations as the response.
AWS Step Functions orchestrate a Map state that uses split files array as input and create a parallel Kubernetes jobs in your Amazon EKS cluster to process these split files in parallel, with a MaxConcurrency = 0. Each Kubernetes job receives one split file as input and performs the following:
Read the individual split file from the Amazon EFS location.
Process each row in the file and generate ConfirmationId for each OrderId field available for each row in the input file which inserts this information to orders Amazon DynamoDB table. All DynamoDB writes are batched to a maximum of 25 rows per request.
Create a Comma-separated values (CSV) file in a Amazon EFS file location, with each row of the file containing both ConfirmationId and OrderId written in batch.
Update Amazon ElastiCache by removing the split file (path) from Redis set using rdb.SRem command.
Finally, merge the output split files in the Amazon EFS directory and upload them to the Amazon S3 bucket.
It’s very important to settle on a right value for the maximum number of rows a split input file can contain. We set this value via MAX_LINES_PER_BATCH environment variable. Giving a smaller value will end up with too many split files creating many Kubernetes jobs, whereas setting a large value eaves too little scope for parallelism.
Walkthrough
Prerequisites
You need the following to complete the steps in this post:

AWS CLI version 2
AWS CDK version 2.19.0 or later
yarn version 1.22.0
Node version 17.8.0 or later
NPM version 8.5.0 or later
Docker-cli
Kubectl
Git
Let’s start by setting a few environment variables:

git clone https://github.com/aws-samples/containers-blog-maelstrom cd containers-blog-maelstrom/batch-processing-with-k8s/ yarn install
Bootstrap AWS Region
The first step to any AWS CDK deployment is bootstrapping the environment. cdk bootstrap is a tool in the AWS CDK command-line interface (CLI) responsible for preparing the environment (i.e., a combination of AWS account and Region) with resources required by AWS CDK to perform deployments into that environment. If you already use AWS CDK in a Region, then you don’t need to repeat the bootstrapping process.

Execute the following commands to bootstrap the AWS environment:

cdk bootstrap aws://$ACCOUNT_ID/$AWS_REGION
Deploy the stack
The AWS CDK code create one stack with the name file-batch-stack, which creates the following AWS Resources:

An Amazon VPC and all related networking components (e.g., subnets).
An Amazon EKS cluster
An AWS Step Function with different states to orchestrate the event-driven batch workload process
An Amazon S3 bucket to store the input file and merged output file
An Amazon EvenBridge rule to trigger an AWS Step Function based on write events to Amazon S3 bucket
An Amazon ElastiCache (Redis) to store split file details
An AWS Lambda to create an array of split files
An Amazon EFS file store to store temporary split files
An Amazon DynamoDB Orders table to store the output details of processed order
Run cdk list to see the list of the stacks to be created.

$ cdk list file-batch-stack
Run the following command to start the deployment:

cdk deploy --require-approval never
Please allow a few minutes for the deployment to complete. Once the deployment is successful, you will see the following output:

✅ file-batch-stack
Outputs:
`file-batch-stack.KubernetesFileBatchConstructInputBucketName610D8598 = file-batch-stack-kubernetesfilebatchconstructinpu-
file-batch-stack.KubernetesFileBatchConstructMultithreadedstepfuctionF3358A99 = KubernetesFileBatchConstructfilebatchmultithreaded0B80AF5A-
file-batch-stack.KubernetesFileBatchConstructfilebatchEFSFileSystemId9139F216 = fs-
file-batch-stack.KubernetesFileBatchConstructfilebatcheksclusterClusterName146E1BCB = KubernetesFileBatchConstructfilebatchekscluster6B334C7D-
file-batch-stack.KubernetesFileBatchConstructfilebatcheksclusterConfigCommand3063A155 = aws eks update-kubeconfig —name KubernetesFileBatchConstructfilebatchekscluster6B334C7D- —region us-east-2 —role-arn arn:aws:iam:::role/file-batch-stack-KubernetesFileBatchConstructfileb-
file-batch-stack.KubernetesFileBatchConstructfilebatcheksclusterGetTokenCommandAD6928E0 = aws eks get-token —cluster-name KubernetesFileBatchConstructfilebatchekscluster6B334C7D- —region us-east-2 —role-arn arn:aws:iam:::role/file-batch-stack-KubernetesFileBatchConstructfileb-
file-batch-stack.KubernetesFileBatchConstructfilebatcheksclusterMastersRoleArn52BC348E = arn:aws:iam:::role/file-batch-stack-KubernetesFileBatchConstructfileb-

Stack ARN:
arn:aws:cloudformation:us-east-2::stack/file-batch-stack/`
Start the workflow
To verify that the deployed solution is working, you can upload sample file test.csv under the payload folder to the input bucket. Run the following command from the root directory:

S3_BUCKET_NAME=$(aws cloudformation describe-stacks \ --stack-name "file-batch-stack" \ --region $AWS_REGION \ --query 'Stacks[0].Outputs[?starts_with(OutputKey,KubernetesFileBatchConstructInputBucketName)].OutputValue' \ --output text) echo $S3_BUCKET_NAME aws s3api put-object \ --bucket $S3_BUCKET_NAME \ --key test.csv \ --body payload/test.csv
The following image shows a line from the input file:

Screenshot showing the format of data in the input file.

When a new file is uploaded to the Amazon S3 bucket, the AWS Step Function state machine is triggered using an Amazon EventBridge Rule. Navigate to the AWS Managed Console and select the state machine created by the AWS CDK (the CDK output includes the name).

The AWS Step Function execution looks like the execution details, as described in the Solution overview section, and shown in the following diagram:

Once the workflow completes successfully, you can download the response file from the Amazon S3 bucket.

Run following command:

aws s3 cp s3://$S3_BUCKET_NAME/test.csv_Output .

Cleanup
You continue to incur cost until you delete the infrastructure that you created for this post. Use the following command to clean up the resources created for this post:

aws s3 rb s3://$S3_BUCKET_NAME --force aws dynamodb delete-table --table-name Order cdk destroy
AWS CDK asks you:

Are you sure you want to delete: file-batch-stack (y/n)?

Enter y to delete.

Conclusion
This post showed how to run event-driven workflows at scale using AWS Step Functions on Amazon EKS and AWS Lambda. We provided you with AWS CDK code to create the cloud infrastructure, Kubernetes resources, and the application within the same codebase. Whenever you upload a file to the Amazon S3 bucket, the event triggers a Kubernetes job.

You can follow the details in this post to build your own serverless event-driven workflows that run jobs in Amazon EKS clusters.

Containers in the Cloud

Van Hoang Kha — Sat, 03 Sep 2022 09:49:31 +0000

ECS - Elastic Container service

ECS is container orchestration service
ECS helps to run Docker containers and EC2 machines
ECS is made of:
- ECS EC2: running ECS tasks an user-provisioned EC2 instances
- Fargate: running ECS tasks on AWS provisioned compute instances (serverless)
- EKS: running ECS on AWS powered Kubernetes
- ECR: Docker Container Registry hosted on AWS
ECS and Docker are very popular for micro-services
IAM security and roles are at the task level

Concepts

ECS cluster: set of EC2 instances
ECS service: application definitions running on ECS cluster
ECS tasks + definition: containers running to create the application
ECS IAM roles: roles assigned to ECS tasks

ECS - ALB integration

Application Load Balancer has a direct integration feature with ECS called port mapping
This allows us to run multiple instances of the same application on the same EC2 machine
Use cases:
- Increase resiliency even if the application is running on one EC2
- Maximize utilization of CPU cores
- Ability to perform rolling updates without impacting application uptime

ECS Setup and Config file

Run an EC2 instance, install the ECS agent with ECS config file or use ECS-ready Linux AMI (still need to modify the config file)
ECS Config file is at /etc/ecs/ecs.config
Config settings:
- ECS_CLUSTER: to which cluster belongs the EC2 instance
- ECS_ENGINE_AUTH_DATA: authenticate to private registries
- ECS_AVAILABLE_LOGGING_DRIVERS: used for enabling CloudWatch logging
- ECS_ENABLE_TASK_IAM_ROLE: enable IAM roles for an ECS tasks

ECS - IAM Task Roles

The EC2 instance running the containers should have an IAM role allowing it to access the ECS service for the ECS agent
Each task inherits EC2 permissions
ECS IAM task role: role dedicated to each task separately
Define a tas role: we can use the taskRoleArn parameter in the task definition

Fargate

When launching an ECS cluster, we have to create our EC2 instances, which means basically we are managing the underlying infrastructure
With Fargate, this is eliminated since this AWS service is serverless
We have to provide task definitions and AWS will run the container for us
To scale we just have to increase the task number

ECR - Elastic Container Registry

Store, manage and deploy container in AWS
Fully integrated with IAM and ECS
Data is sent over HTTPS and encrypted at rest

Amazon EKS

EKS = Elastic Kubernetes Service
It is a way to launch managed Kubernetes clusters on AWS
Kubernetes is an open-source system for automatic deployment, scaling and management of containerized applications
It is an alternative to ECS having a different API
EKS supports EC2 if we want to deploy worker nodes or Fargate to deploy serverless containers

AWS RDS - Relational Database Service

Van Hoang Kha — Sat, 03 Sep 2022 09:37:15 +0000

AWS RDS - Relational Database Service

It is a managed database service for relational databases
It allows us to create databases in the cloud that are managed by AWS
RDS offerings provided by AWS:
- PostreSQL
- MySQL
- MariaDB
- Oracle
- Microsoft SQL Server
- Aurora
Advantages of AWS RDS over deploying an relational database on EC2:
- RDS is a managed service, meaning:
  - Automated provisioning, OS patching
  - Continuous backups and restore to specific timestamp (Point in Time Restore)
  - Monitoring dashboards
  - Read replicas
  - Multi AZ setup
  - Maintenance windows for upgrades
  - Scaling capability (vertical and horizontal)
  - Storage backed by EBS (GP2 or IO)
Disadvantages:
- No SSH into the instance which hosts the database

RDS Backups

Backups are automatically enabled in RDS
AWS RDS provides automated backups:
- Daily fill backup of the database (during the maintenance window)
- Transaction logs are backed-up by RDS every 5 minutes which provides the ability to do point in time restores
- There is a 7 day retention for the backups which can be increased to 35 days
DB Snapshots:
- There are manually triggered backups by the users
- Retention can be as long as the user wants
- Helpful for retaining the state of the database for longer period of time

RDS Read Replicas

Read replicas helps to scale the read operations
We can create up to 5 read replicas
These replicas can be within AZ, cross AZ or in different regions
The data between the main database and the read replicas is replicated asynchronously => reads are eventually consistent
Read replicas can be promoted into their own database
Use case for read replicas:
- Production database is up and running taking on normal load
- There is a new feature for running some reporting for analytics which may cause slow downs and may overload the database
- To fix this we can create read replicas for reporting
Read replicas are used for SELECT operations (not INSERT, UPDATE, DELETE)
Network cost for read replicas:
- In AWS there is network cost if data goes from one AZ to another
- In case of cross AZ replication, additional costs may incur because of network traffic
- To reduce costs, we could have the read replicas in the same AZ

RDS Multi AZ (Disaster Recovery)

RDS Multi AZ replication is done using synchronous replication
In case of multi AZ configuration we get one DNS name
In case of the main database goes down, the traffic is automatically re-routed to the failover database
Multi AZ is not used for scaling
The read replicas can be set up as Multi AZ for Disaster Recovery

RDS Security

Encryption

AWS RDS provides rest encryption: possibility to encrypt the master and read replicas with AWS KMS - AES-256 encryption
- Encryption has to be defined at the launch time
- If the master is not encrypted, the read replicas cannot be encrypted
- Transparent Data Encryption (TDE) is available for Oracle and SQL Server
In-flight encryption: uses SSL certificates to encrypt data from client to RDS in flight
- It is required SSL a trust certificate when connecting to database
- To enforce SSL:
  - PostgeSQL: rds.force_ssl=1 in the AWS RDS Console (Parameter Groups)
  - MySQL: GRANT USAGE ON *.* To 'user'@'%' REQUIRE SSL;
Encrypting RDS backups:
- Snapshots of un-encrypted RDS databases are un-encrypted
- Snapshots of encrypted RDS databases are encrypted
- We can copy an un-encrypted snapshot into an encrypted one
Encrypt an un-encrypted RDS database:
- Create a snapshot
- Copy the snapshot and enable encryption for the snapshot
- Restore the database from the encrypted snapshot
- Migrate application from the old database to the new one and delete the old database

Network Security and IAM

Network security:
- RDS databases are usually deployed within a private subnet
- RDS security works by leveraging security groups (similar to EC2), they control who can communicate with the database instance
Access management:
- There are IAM policies which help control who can manage an AWS RDS database (through the RDS API)
- Traditional username/password can be used to login into the database
- IAM-based authentication can be used to login into MySQL and PostgreSQL
IAM authentication:
- IAM database authentication works with MySQL and PostgreSQL
- We don't need a password to authenticate, just an authentication token obtained through IAM and RDS API calls
- The token has a lifetime of 15 minutes
- Benefits:
  - Network in/out must be encrypted using SSL
  - IAM is used to centrally manage users instead of DB credentials
  - We can manage IAM roles and EC2 instance profiles for easy integration

Security Summary

Encryption at rest:
- It is done only when the database is created
- To encrypt an existing database, we have create a snapshot, copy it as encrypted, and create an encrypted database from the snapshot
Our responsibility:
- Check the ports/IP/security groups inbound rules
- Take care of database user creation and permissions or manage them through IAM
- Create a database with or without public access
- Ensure parameter groups or DB is configured to only allow SSL connections
AWS responsibility:
- DB patching
- Underlying OS patching and updates

EFS - Elastic File System

Van Hoang Kha — Sat, 03 Sep 2022 09:36:24 +0000

EFS - Elastic File System

EFS is a managed NFS (network file system) that can be mounted on many EC2 instances
EFS works with EC2 instances across multi AZs
EFS is highly available, scalable, but also more expensive (3x GP2) than EBS
EFS is pay per use
Use cases: content management, web service, data sharing, Wordpress
Uses NFSv4.1 protocol
We can use security groups to control access to EFS volumes
EFS is only compatible with Linux based AMIs (not Windows)

EFS Performance and Storage Classes

EFS Scale
- Thousands of concurrent NFS clients, 10 GB+ per second throughput
- It can grow to petabyte scale NFS automatically
Performance mode (can be set at EFS creation time)
- General purpose (default): recommended for latency-sensitive use cases: web server, CMS, etc.
- Max I/O - higher latency, throughput, highly parallel, recommended for big data, media processing
Storage tiers: lifecycle manage feature
- Standard: for frequently accessed files
- Infrequent access (EFS-IA): there is a cost to retrieve files, lower price per storage

EBS vs EFS

EBS volumes
- Can be attached to only one instance at a time
- Are locked at the AZ level
- GP2: IO increases if the disk size increases
- IO1: can increase IO independently
- To migrate an EBS across AZ:
  - Take a snapshot
  - Restore the volume from the snapshot
- Root EBS volumes get terminated by default in the EC2 instance is terminated (this feature can be disabled)
EFS
- Can be mounted to multiple instances across AZs via EFS mount targets
- Available only for Linux instances
- EFS has a higher price point than EBS
- EFS is pay per second, we can leverage EFS-IA for cost saving

EBS - Elastic Block Storage

Van Hoang Kha — Sat, 03 Sep 2022 09:35:33 +0000

EBS - Elastic Block Storage

An EC2 instances loses its root volume when it is manually terminated
Unexpected terminations may happen
Sometimes we need a way to store instance data somewhere
An EBS (Elastic Block Store) Volume is a network drive which can be attached to an EC2 instance
It allows for the instances to persist date
EBS is a network drive:
- It uses the network to communicate with the instance, which can introduce latency
- It can be detached from an EC2 and attached ot another
EBS volumes are locked to an AZ
To move a volume across, we need to create a snapshot
EBS volumes have a provisioned capacity (size in GB and IOPS)
Billing is done for all provisioned capacity even if the capacity is not fully used

EBS Volume Types

EBS Volumes can have 4 types:
- GP2 (SSD): general purpose SSD volume that balances price and performance
- IO1 (SSD): highest performance SSD volume for mission-critical low-latency or high-throughput workloads
- ST1 (HDD): low cost HDD volume designed for frequent access, throughput-intensive workloads
- SC1 (HDD): for less frequently accessed data
EBS Volumes are characterized in Size | Throughput | IOPS (I/O Operations per second)
Only GP2 and IO1 can be used as boot volumes

EBS Volume Types - Deep Dive

GP2

Recommended for most workloads
Can be system boot volume
Can be used for virtual desktops, low-latency applications, development and test environments
Size can range from 1GiB to 16TiB
Small GP2 volumes can burst IOPS to 3000
Max IOPS is 16000
We get 3 IOPS per GiB, which means at 5334GiB we are the max IOPS size

IO1

Recommended for business critical applications which require sustained IOPS performance, or more than 16000 IOPS per volume
Recommended for large database workloads
Size can be between 4Gib and 16 TiB
The maximum ratio of provisioned IOPS per requested volume size is 50:1
Max IOPS for IO1/2 volumes is 64000 IOPS for instances built on Nitro System and 32000 for other type of instances

ST1

Recommended for streaming workloads
It has fast throughput at low price
Can not be a root volume
Size can be between 500Gib and 16TiB
Max IOPS is 500
Max throughput 500 MiB/Sec

SC1

Throughput oriented storage for large volumes of data which is infrequently accessed
Can not be a boot volume
Max IOPS is 250, max throughput 250MiB/sec

Limits

SSD, General Purpose – gp2 – Volume size 1 GiB – 16 TiB – Max IOPS/volume 16,000
SSD, Provisioned IOPS – i01 – Volume size 4 GiB – 16 TiB – Max IOPS/volume 64,000 – HDD, Throughput Optimized – (st1) – Volume size 500 GiB – 16 TiB
- Throughput measured in MB/s, and includes the ability to burst up to 250 MB/s per TB, with a baseline throughput of 40 MB/s per TB and a maximum throughput of 500 MB/s per volume
HDD, Cold – (sc1) – Volume size 500 GiB – 16 TiB.
- Lowest cost storage – cannot be a boot volume – These volumes can burst up to 80 MB/s per TB, with a baseline throughput of 12 MB/s per TB and a maximum throughput of 250 MB/s per volume: HDD, Magnetic – Standard – cheap, infrequently accessed storage – lowest cost storage that can be a boot volume

EBS Snapshots

Snapshots are incremental - only the changed blocks are backed up
EBS backups use IO and we should not run them while the application is handling a lot of traffic
Snapshots are stored in S3 (we are not able to see them)
It is not necessary to detach the volume to do a snapshot, but it is recommended
An account can have up to 100k snapshots
We can make an image (AMI) out of a snapshot, snapshots can be copied across AZs
EBS volumes restored from snapshots need to be pre-warmed (using fio or dd commands to read the entire volume)
Snapshots can be automated using Amazon Data Lifecycle Manager

EBS Migrations

EBS Volumes are locked to a specific AZ
To migrate it to a different AZ (or region) we have to do the following:
- Create a snapshot from the volume
- (optional) Copy the volume to a different region
- Create a volume from the snapshot in the AZ of choice

EBS Encryption

When we create an encrypted EBS volume, we get the following:
- Data at rest is encrypted inside the volume
- All the data in flight moving between the instance and the volume is encrypted
- All snapshots are encrypted
- All volumes created from the snapshots will be encrypted
Encryption and decryption are handled transparently by EBS system
Encryption may have a minimal impact on latency
EBS Encryption leverages keys from KMS (encryption algorithm is AES-256)
Copying an unencrypted snapshot allows encryption
Encrypt an unencrypted EBS volume:
1. Create an EBS snapshot from the volume
2. Copy the snapshot an enable encryption on the process
3. Create a new EBS volume from the snapshot (the volume will be encrypted)
4. Attach the encrypted volume to an instance

EBS vs Instance Store

Some instances do not come with a root EBS volume
Instead, they come with an instance store (ephemeral storage)
An instance store is a physically attached to the machine (EBS is a network drive)
Pros of instance stores:
- Better I/O performance
- Good for buffer, cache, scratch data, temporary content
- Data survives a reboot
Cons of instance stores:
- On stop or termination of the instance, the data from the instance store is lost
- An instance store can not be resized
- Backups of an instance store must be done manually by the user
An instance store is:
- A physical disk form the physical server where the EC2 instance runs
- Very Hight IOPS disk
- A disk up to 7.5 TiB, stripped to reach 30 TiB
- A block storage (just like EBS)
- Can not be increased in size
- An ephemeral storage (risk of data loss if hardware fails)

EBS RAID Options

EBS is already redundant storage (replicated within an AZ)
If we want to increase IOPS of if we want to mirror an EBS volume we can mount EBS volumes in parallel RAID settings
RAID is possible as long as the OS supports it
Some RAID options are:
- RAID 0
- RAID 1
- RAID 5, RAID 6 are not recommended for EBS
RAID 0: used for increased performance. We can combine to or more volumes and what we get is the total number of disk space and I/O
- If one of the disks fail, all the logical data is lost
- Use cases:
  - Applications with lot of IOPS but without the need for fault-tolerance
  - A database with builtin replication
RAID 1: used for increased fault-tolerance. Mirroring a volume to another.
- If one the disks fails, the logical volume will still work
- We have to send the data to two EBS volumes at the same time
- Use cases:
  - Applications that need increased fault-tolerance
  - Applications which need to service disks

Auto Scaling Groups

Van Hoang Kha — Sat, 03 Sep 2022 09:33:01 +0000

Auto Scaling Groups

Applications may encounter different amount of load depending on their usage span
In cloud we can create and get rid of resources (servers) quickly
The goal of an Auto Scaling Group (ASG) is to:
- Scale out (add more EC2 instances) to match the increased load
- Scale in (remote EC2 instances) to match a decreased load
- Ensure we have a minimum and a maximum number of machines running
- Automatically register new instances to a load balancer

ASG Attributes

Launch configuration - consists of:
- AMI + Instance Type
- EC2 User Data
- EBS Volumes
- Security Groups
- SSH Key Pair
Min size, max size, initial capacity
Network + subnets information
Load balancer information
Scaling policies - what will trigger a scale out/scale in

Auto Scaling Alarms

It is possible to scale an ASG based on CloudWatch alarms
An alarm monitors a metric (such as Average CPU)
Metrics are computed for the overall ASG instances
Based on alarms we can create:
- Scale-out policies
- Scale-in policies

Auto Scaling New Rules

It is possible to define "better" auto scaling rules managed directly by EC2 instances, for example:
- Target Average CPU Usage
- Number of requests on teh ELB per instance
- Average Network In/Out
These rules are easier to set up and to reason about then the previous ones

Auto Scaling Based on Custom Metrics

We can scale based on a custom metric (ex: number of connected users to the application)
In order to do this we have to:
1. Send a custom metric request to CloudWatch (PutMetric API)
2. Create a CloudWatch alarm to react to values of the metric
3. Use the CloudWatch alarm as a scaling policy for ASG

ASG Summary

Scaling policies can be on CPU, Network, etc. and can even be based on custom metrics or based on a schedule
ASGs can use launch configurations or launch templates (newer version)
- Launch configurations allow to specify one instance type
- Launch templates allow to use a spot fleet of instances
To update an ASG, we must provide a new launch configuration/template. The underlying EC2 instances will be replaced over time
IAM roles attached to an ASG will be assigned to the launched EC2 instances
ASGs are free. We pay for the underlying resources being launched (EC2 instances, attached EBS volumes, etc.)
Having instances under an ASG means that if they get terminated for any reason, the ASG will automatically create new ones as a replacement
ASG can terminate instances marked as unhealthy by a load balancer and obviously replace them
Health checks - we can have 2 types of health checks:
- EC2 health checks - instances is recreated if the EC2 instance fails to respond to health checks
- ELB health checks - instance is recreated if the ELB health checks fail, meaning that the application is down for whatever reason

ASG Scaling Policies

Target Tracking Scaling
- Most simple and easy to setup
- Example: we want the average ASG CPU to stay around 40%
Simple/Step Scaling
- Example:
  - When a CloudWatch alarm is triggered (example average CPU > 70%), then add 2 units
  - When a CloudWatch alarm is triggered (example average CPU < 30%), then remove 1 unit
Scheduled Actions
- Can be used if we can anticipate scaling based on known usage patterns
- Example: increase the min capacity to 10 at 5 PM on Fridays

Scaling Cool-downs

The cool-down period helps to ensure that our ASG doesn't launch or terminate additional instances before the previous scaling activity takes effect
In addition to default cool-down for ASG we can create cool-downs that apply to specific simple scaling policy
A scaling-specific cool-down overrides the default cool-down period
Common use case for scaling-specific cool-downs is when a scale-in policy terminates instances based in a criteria or metric. Because this policy terminates instances, an ASG needs less time to determine wether to terminate additional instances
If the default cool-down period of 300 seconds is too long, we can reduce costs by applying a scaling-specific cool-down of 180 seconds for example
If our application is scaling up and down multiple times each hour, we can modify the ASG cool-down timers and the CloudWatch alarm period that triggers the scale

Suspend and Resume Scaling Processes

We can suspend and then resume one or more of the scaling processes for our ASG. This can be useful when we want to investigate a configuration problem or other issue with our web application and then make changes to our application, without invoking the scaling processes.
We can manually move an instance from an ASG and put it in the standby state
Instances in standby state are still managed by Auto Scaling, are charged as normal, and do not count towards available EC2 instance for workload/application use. Auto scaling does not perform health checks on instances in the standby state. Standby state can be used for performing updates/changes/troubleshooting etc. without health checks being performed or replacement instances being launched.

ASG for Solutions Architects

ASG Default Termination Policy
1. Find the AZ which has to most number of instances
2. If there are multiple instances to choose from, delete the one with the oldest launch configuration
Lifecycle Hooks
- By default as soon as an instance is launched in an ASG, the instance goes in service
- ASGs provide the ability to perform extra steps before the instance goes in service
- Also, we have he ability to perform some actions before the instance is terminated
- Lifecycle hooks diagram: https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html
Launch Templates vs. Launch Configurations
- Both allow to specify the AMI, the instance type, a key par, security groups and the other parameters that we use to launch EC2 instances (tags, user-data, etc.)
- Launch Configurations are considered to be legacy:
  - They must be recreated every time
- Launch Templates:
  - They can have multiple versions
  - They allow parameter subsets used for partial configuration for re-use and inheritance
  - We can provision both On-Demand and Spot instances (or a mix of two)
  - We can use the T2 unlimited burst feature
  - Recommended by AWS

Elastic Load Balancers

Van Hoang Kha — Sat, 03 Sep 2022 09:29:59 +0000

Scalability and High Availability

Scalability means that an a system can handle greater loads by adapting
We can distinguish two types of scalability strategies:
- Vertical Scalability (scale up/down)
  - Increase the size of the current instance (ex. from a t2.micro instance migrate to a a t2.large one)
  - Vertical scalability is common for non distributed systems, such as databases
  - RDS, ElastiCache are services that can scale vertically
- Horizontal Scalability (scale out/in)
  - Increase the number of instances on which the application runs
  - Horizontal scaling implies having a distributed system
  - It's easy to scale horizontally thanks to could offerings such as EC2
High Availability means running our application in at least 2 data centers (AZs)
- The goal of high availability is to survive a data center loss
High Availability can be:
- Passive
- Active
Load balancers can scale but not instantaneously - contact AWS for a "warm-up"
Troubleshooting:
- 4xx errors are client induced errors
- 5xx errors are application induced errors (server side errors)
- Error 503 means that the load balancer is at capacity or no registered targets can be found
- If the load balancer can't connect to the application, it most likely means that the security group blocks the connection
Monitoring:
- ELB access logs will log all the access requests to the LB
- CloudWatch Metrics will give aggregate statistics (example: connections counts)

Load Balancing Basics

Load balancers are servers that forward internet traffic to multiple other servers (most likely EC2 instances)
Why use load balances?
- Spear load across multiple downstream instances
- Expose a single point of access (DNS) to the application
- Seamlessly handle failures of downstream instances (by using health checks)
- Do regular health checks to registered instances
- Provide SSL termination (HTTPS) for the website hosted on the downstream instances
- Enforce stickiness for cookies
- High availability across availability zones (load balancer can be spread across multiple AZs, not regions!!!)
- Cleanly separate public traffic from private traffic
An ELB (Elastic Load Balancer) is a managed load balancer which means:
- AWS guarantees that it will be working
- AWS takes care of upgrades, maintenance and high availability
- An ELB provides a few configuration options for us also
- It costs less to setup our custom load balancer, but it will be a lot more effort to maintain on the long run
- An ELB is integrated with many AWS offering/services, it will be more flexible than a custom LB

Health Checks

They enable for a LB to know if an instance for which traffic is forwarded is available to reply to requests
The health checks is done using a port and a route (usually /health)
If the response is not 200, then the instance is considered unhealthy

Types of Load Balancers on AWS

AWS provides 4 type of load balancers:
- Classic Load Balancer (v1 - old generation): supports HTTP, HTTPS and TCP
- Application Load Balancer (v2 - new generation): supports HTTP, HTTPS and WebSockets
- Network Load Balancer (v2 - new generation): supports TCP, TLS (secure TCP) and UDP
- Gateway Load Balancer (new generation - see VPC section of the notes)
It is recommended to use the new versions
We can setup internal (private) and external (public) load balancers on AWS

Classic Load Balancers (CLB)

They support 2 types of connections: TCP (layer 4) and HTTP(S) (layer 7)
Health checks are either TCP or HTTP based
CLBs provide a fixed hostname: XXX.region.elb.amazonaws.com

Application Load Balancers (ALB)

They are a layer 7 type load balancers (only HTTP or HTTPS)
They allow load balancing to multiple HTTP applications across multiple machines (target groups). Also they allow to load balance to multiple applications on the same EC2 instance (useful in case of containers)
They have support for HTTP2 and WebSockets.
They support redirects, example for HTTP to HTTPS
They provide routing tables to different target groups:
- Routing based on path in URL
- Routing based on the hostname
- Routing based on query strings an headers
ALBs are great fit for micros-services and container based applications
ALBs have port mapping features to redirect to dynamic ports in case ECS
Target groups can contain:
- EC2 instances (can be managed by an Auto Scaling Group)
- ECS tasks (managed by ECS itself)
- Lambda Functions - HTTP request is translated to a JSON event
- IP Addresses - must be private IP addresses
ALBs also provide a fixed hostname (same as CLBs): XXX.region.elb.amazonaws.com
The application servers behind the LB can not see the IP of the client who accessing them directly, but they can retrieve for X-Forwarded-For header. The port can be fetched from X-Forwarded-Port and the protocol from X-Forwarded-Proto

Network Load Balancers (NLB)

Network load balancers (layer 4) allow to:
- Forward TCP and UDP traffic to the registered instances
- Handle millions of requests per second
- Less latency ~100ms (vs 400ms for ALB)
NLBs have one static IP per AZ and supports Elastic IPs (can be used when whitelisting is necessary)
Use case for NLBs: NLBs are used for extreme performance in case of TCP or UDP traffic (example: video games)
Instances behind an NLB don't see traffic coming from the load balancer, they see traffic as it was coming from the outside world => no security group is attached to LB => security group attached to the target EC2 instance should be changed to allow traffic from the outside (example: 0.0.0.0/0, on port 80)

Stickiness

It is possible to implement stickiness in case of CLB and ALB load balancers
Stickiness means that the traffic from the same client will be forwarded to the same target instance
Stickiness works by adding a cookie to the request which has an expiration date for controlling the stickiness period
Possible use case for stickiness: we have to make sure that the user does not lose his session data
Enabling stickiness may bring imbalance to the load over the downstream target instances

Cross-Zone Load Balancing

With Cross-Zone Load Balancing enabled each LB instance distributes traffic evenly across multiple AZs
Otherwise, ech LB node distributes requests evenly only in the AZ where it is registered
Classic Load Balancer:
- Cross-zone load balancing is disabled by default
- No additional charges for cross zone load balancing if the feature is enabled
Application Load Balancer:
- Cross-zone load balancing is always on, can not be disabled
- No charges applied for cross zone load balancing
Network Load Balancer:
- Cross-zone load balancing is disabled by default
- Additional charges apply if the feature is enabled

SSL/TLS Certificates

An SSL certificate allows traffic to be encrypted between the clients and the load balancers. This ia called encryption in transit or in-flight encryption
SSL - Secure Socket Layer
TLS (newer version of SSL) - Transport Layer Security
Nowadays TLS are mainly used, but we are still referring to it as SSL
Public SSL certificates are issued by a Certificate Authority
SSL certificates have an expiration dates and they must be renewed
SSL termination: client can talk with a LB using HTTPS but internal traffic can be routed to a target using HTTP
Load balancer can load an X.509 certificate (which is a SSL/TLS server certificate)
We can manage certificates in AWS using ACM (AWS Certificate Manager)
HTTPS Listener:
- We must specify a default certificate
- We can add an optional list of certificates to support multiple domains
- Clients can use SNI (Server Name Indication) to specify which hostname want to reach
- Ability to specify a security policy to support older versions of SSL/TLS (for legacy clients like Internet Explorer 5 lol:) )

SNI - Server Name Indication

SNI solves the problem of being able to load multiple SSL certificates onto one web server
There is a newer protocol which requires the client to indicate the hostname of the target server in the initial SSL handshake
- In case of AWS this only works for ALB, NLB and CloudFront (no CLB!)

ELB - Connection Draining

Feature naming:
- In case of a CLB is called Connections Draining
- If we have a target group: (ALB, NLB) it is called Deregistration Delay
Connection draining is the time to complete in-flight requests while the instance is de-registering or unhealthy. Basically it allows the instance to terminate whatever it was doing
The LB will stop sending new requests to the target instance which is in progress of de-registering
The time period of the connection draining can be set between 1 seconds to 3600 seconds
It also can be disabled (set the period to 0 seconds)

AWS EC2

Van Hoang Kha — Sat, 03 Sep 2022 09:27:47 +0000

It mainly consists of the following capabilities:
- Renting virtual machines in the cloud (EC2)
- Storing data on virtual drives (EBS)
- Distributing load across multiple machines (ELB)
- Scaling the services using an auto-scaling group (ASG)

Introduction to Security Groups (SG)

Security Groups are the fundamental of networking security in AWS
They control how traffic is allowed into or out of EC2 machines
Basically they are firewalls

Security Groups Deep Dive

Security groups regulate:
- Access to ports
- Authorized IP ranges - IPv4 and IPv6
- Control of inbound and outbound network traffic
Security groups can be attached to multiple instances
They are locked down to a region/VPC combination
They do live outside of the EC2 instances - if traffic is blocked the EC2 instance wont be able to see it
It is good to maintain one separate security group for SSH access
If the request for the application times out, it is most likely a security group issue
If for the request the response is a "connection refused" error, then it means that it is an application error and the traffic went through the security group
By default all inbound traffic is blocked and all outbound traffic is authorized
A security group can allow traffic from another security group. A security group can reference another security group, meaning that it is no need to reference the IP of the instance to which the security group is attached

Elastic IP

When an EC2 instance is stopped and restarted, it may change its public IP address
In case there is a need for a fixed IP for the instance, Elastic IP is the solution
An Elastic IP is a public IP the user owns as long as the IP is not deleted by the owner
With Elastic IP address, we can mask the failure of an instance by rapidly remapping the address to another instance
AWS provides a limited number of 5 Elastic IPs (soft limit)
Overall it is recommended to avoid using Elastic IP, because:
- They often reflect pool arhcitectural decisions
- Instead, us e a random public IP and register a DNS name to it

EC2 User Data

It is possible to bootstrap (run commands for setup) an EC2 instance using EC2 User data script
The user data script is only run once at the first start of the instance
EC2 user data is used to automate boot tasks such as:
- Installing update
- Installing software
- Downloading common files from the internet
- Any other start-up task
THe EC2 user data scripts run with root user privileges

EC2 Instance Launch Types

On Demand Instances: short workload, predictable pricing
Reserved: known amount of time (minimum 1 year). Types of reserved instances:
- Reserved Instances: recommended long workloads
- Convertible Reserved Instances: recommended for long workloads with flexible instance types
- Scheduled Reserved Instances: instances reserved for a longer period used at a certain schedule
Spot Instances: for short workloads, they are cheap, but there is a risk of losing the instance while running
Dedicated Instances: no other customer will share the underlying hardware
Dedicated Hosts: book an entire physical server, can control the placement of the instance

EC2 On Demand

Pay for what we use, billing is done per second after the first minute
Hast the higher cost but it does not require upfront payment
Recommended for short-term and uninterrupted workloads, when we can't predict how the application will behave

EC2 Reserved Instances

Up to 75% discount compared to On-demand
Pay upfront for a given time, implies long term commitment
Reserved period can be 1 or 3 years
We can reserve a specific instance type
Recommended for steady state usage applications (example: database)
Convertible Reserved Instances:
- The instance type can be changed
- Up to 54% discount
Scheduled Reserved Instances:
- The instance can be launched within a time window
- It is recommended when is required for an instance to run at certain times of the day/week/month

EC2 Spot Instances

We can get up to 90% discount compared to on-demand instances
It is recommended for workloads which are resilient to failure since the instance can be stopped by the AWS if our max price is less then the current spot price
Not recommended for critical jobs or databases
Great combination: reserved instances for baseline performance + on-demand and spot instances for peak times

EC2 Dedicated Hosts

Physical dedicated EC2 server
Provides full control of the EC2 instance placement
It provides visibility to the underlying sockets/physical cores of the hardware
It requires a 3 year period reservation
Useful for software that have complicated licensing models or for companies that have strong regulatory compliance needs

EC2 Dedicated Instances

Instances running on hardware that is dedicated to a single account
Instances may share hardware with other instances from the same account
No control over instance placement
Gives per instance billing

EC2 Spot Instances - Deep Dive

With a spot instance we can get a discount up to 90%
We define a max spot price and get the instance if the current spot price < max spot price
The hourly spot price varies based on offer and capacity
If the current spot price goes over the selected max spot price we can choose to stop or terminate the instance within the next 2 minutes
Spot Block: block a spot instance during a specified time frame (1 to 6 hours) without interruptions. In rare situations an instance may be reclaimed
Spot request - with a spot request we define:
- Maximum price
- Desired number of instances
- Launch specifications
- Request type:
  - One time request: as soon as the spot request is fulfilled the instances will be launched an the request will go away
  - Persistence request: we want the desired number of instances to be valid as long as the spot request is active. In case the spot instances are reclaimed, the spot request will try to restart the instances as soon as the price goes down
Cancel a spot instance: we can cancel spot instance requests if it is in open, active or disabled state (not failed, canceled, closed)
Canceling a spot request does not terminate the launched instances. If we want to terminate a spot instance for good, first we have to cancel the spot request and the we can terminate the associated instances, otherwise the spot request may relaunch them

Spot Fleet

Spot Fleet is a set of spot instances and optional on-demand instances
The spot fleet will try to meet the target capacity with price constraints
AWS will launch instances from a launch pool, meaning we have to define the instance type, OS, AZ for a launch pool
We can have multiple launch pools from within the best one is chosen
If a spot a fleet reaches capacity or max cost, no more new instances are launched
Strategies to allocate spot instances in a spot fleet:
- lowerPrice: the instances will be launched from the pool with the lowest price
- diversified: launched instances will be distributed from all the defined pools
- capacityOptimized: launch with the optimal capacity based on the number of instances

EC2 Instance Types

R: applications that needs a lot of RAM - in-memory cache
C: applications that need good CPU - compute/database
M: applications that are balanced - general / web app
I: applications that need good local I/O - databases
G: applications that need GPU - video rendering / ML
T2/T3 - burstable instances
T2/T3 unlimited: unlimited burst

Bustable Instances (T2/T3)

Overall the performance of the instance is OK
When the machine needs to process something unexpected (a spike load), it can burst and CPU can be very performant
If the machine bursts, it utilizes "burst credits"
If all the credits are gone, the CPU becomes bad
If the machine stops bursting, credits are accumulated over time
Credit usage / credit balance of a burstable instance can be seen in CloudWatch
CPU credits: bigger the instance the faster credit is earned
T2/T3 Unlimited: extra money can be payed in case the burst credits are used. There wont be any performance loss

AMI

AWS comes with lots of base images
Images can be customized ar runtime with EC2 User data
In case of more granular customization AWS allows creating own images - this is called an AMI
Advantages of a custom AMI:
- Pre-install packages
- Faster boot time (on need for the instance to execute the scripts from the user data)
- Machine configured with monitoring/enterprise software
- Security concerns - control over the machines in the network
- Control over maintenance
- Active Directory out of the box
An AMI is built for a specific region (NOT GLOBAL!)

Public AMI

We can leverage AMIs from other people
We can also pay for other people's AMI by the hour, basically renting the AMI form the AWS Marketplace
Warning: do not use AMI which is not trustworthy!

AMI Storage

An AMI takes space and they are stored in S3
AMIs by default are private and locker for account/region
We can make our AMIs public and share them with other people or sell them on the Marketplace

Cross Account AMI Sharing

It is possible the share AMI with another AWS account
Sharing an AMI does not affect the ownership of the AMI
If a shared AMI is copied, than the account who did the copy becomes the owner
To copy an AMI that was shared from another account, the owner of the source AMI must grant read permissions for the storage that backs the AMI, either the associated EBS snapshot or an associated S3 bucket
Limits:
- An encrypted AMI can not be copied. Instead, if the underlying snapshot and encryption key where shared, we can copy the snapshot while re-encrypting it with a key of our own. The copied snapshot can be registered as a new AMI
- We cant copy an AMI with an associated billingProduct code that was shared with us from another account. This includes Windows AMIs and AMIs from the AWS Marketplace. To copy a shared AMI with billingProduct code, we have to launch an EC2 instance from our account using the shared AMI and then create an AMI from source

Placement Groups

Sometimes we want to control how the EC2 instances are placed in the AWS infrastructure
When we create a placement group, we can specify one of the following placement strategies:
- Cluster - cluster instances into a low-latency group in a single AZ
- Spread - spread instances across underlying hardware (max 7 instances per group per AZ)
- Partition - spread instances across many different partitions (which rely on different sets of racks) within an AZ. Scale to 100s of EC2 instances per group (Hadoop, Cassandra, Kafka)

Placement Groups - Cluster

Pros: Great network (10Gbps bandwidth between instances)
Cons: if the rack fails, all instances fail at the time
Use cases:
- Big data job that needs to complete fast
- Application that needs extremely low latency and high network throughput

Placement Groups - Spread

Pros:
- Can span across multiple AZs
- Reduces risk for simultaneous failure
- EC2 instances are on different hardware
Cons:
- Limited to 7 instances per AZ per placement group
Use case:
- Application that needs to maximize high availability
- Critical applications where each instance must be isolated from failure

Placement Groups - Partitions

Pros:
- Up to 7 partitions per AZ
- Can have hundreds of EC2 instances per AZ
- The instances in a partition do not share racks with the instances from other partitions
- A partition failure can effect many instances but they wont affect other partitions
- Instances get access to the partition information as metadata
Use cases: HDFS, HBase, Cassandra, Kafka

Elastic Network Interfaces - ENI

Logical component in a VPC that represents a virtual network card
An ENI can have the following attributes:
- Primary private IPv4 address, one or more secondary IPv4 addresses
- One Elastic IP (IPv4) per private IPv4
- One Public IPv4
ENI instances can be created independently from an EC2 instance
We can attach them on the fly to an EC2 instances or move them from one to another (useful for failover)
ENIs are bound to a specific available zone
ENIs can have security group attached to them
EC2 instances usually have a primary ENI (eth0). In case we attach a secondary ENI, eth1 interface will be available. The primary ENI can not be detached.

EC2 Hibernate

We can stop or terminate EC2 instances:
- If an instance is stopped: the data on the disk (EBS) is kept intact
- If an instance is terminated: any root EBS volume will also gets destroyed
On start, the following happens in case of an EC2 instance:
- Fist start: the OS boots and EC2 User data script is executed
- Following starts: the OS boots
- After the OS boot the applications start, cache gets warmed up, etc. which may take some time
EC2 Hibernate:
- All the data from RAM is preserved on shut-down
- The instance boot is faster
- Under the hood: the RAM state is written to a file in the root EBS volume
- The root EBS volume must be encrypted
Supported instance types for hibernate: C3, C4, C5, M3, M4, M5, R3, R4, R5
Supported OS types: Amazon Linux 1 and 2, Windows
Instance RAM size: must be less then 150 GB
Bare metal instances do not support hibernate
Root volume: must be EBS, encrypted, not instance store. And it must be large enough
Hibernate is available for on-demand and reserved instances
An instance can not hibernate for more than 60 days

EC2 for Solution Architects

EC2 instances are billed by the second, t2.micro is free tier
On Linux/Mac we can use SSH, on Windows Putty or SSH
SSH is using port 22, the security group must allow our IP to be able to connect
In cas of a timeout, it is most likely a security group issue
Permission for SSH key => chmod 0400
Security groups can reference other security groups instead of IP addresses
EC2 instance can be customized at boot using EC2 User Data
4 EC2 launch modes:
- On-demand
- Reserved
- Spot
- Dedicated hosts
We can create AMIs to pre-install software
An AMI can be copied through accounts and regions
EC2 instances can be started in placement groups:
- Cluster
- Spread
- Partition

Git basic

Van Hoang Kha — Tue, 30 Aug 2022 08:56:00 +0000

Git and Git Flow

Git Cheat Sheet

Index

Set Up
Configuration Files
Create
Local Changes
Search
Commit History
Branches & Tags
Update & Publish
Merge & Rebase
Undo
Git Flow

Setup

Show current configuration:

$ git config --list

Show repository configuration:

$ git config --local --list

Show global configuration:

$ git config --global --list

Show system configuration:

$ git config --system --list

Set a name that is identifiable for credit when review version history:

$ git config --global user.name “[firstname lastname]”

Set an email address that will be associated with each history marker:

$ git config --global user.email “[valid-email]”

Set automatic command line coloring for Git for easy reviewing:

$ git config --global color.ui auto

Set global editor for commit

$ git config --global core.editor vi

Configuration Files

Repository specific configuration file [--local]:

<repo>/.git/config

User-specific configuration file [--global]:

~/.gitconfig

System-wide configuration file [--system]:

/etc/gitconfig

Create

Clone an existing repository:

There are two ways:

Via SSH

$ git clone ssh://user@domain.com/repo.git

Via HTTP

$ git clone http://domain.com/user/repo.git

Create a new local repository in the current directory:

$ git init

Create a new local repository in a specific directory:

$ git init <directory>

Local Changes

Changes in working directory:

$ git status

Changes to tracked files:

$ git diff

See changes/difference of a specific file:

$ git diff <file>

Add all current changes to the next commit:

$ git add .

Add some changes in <file> to the next commit:

$ git add -p <file>

Add only the mentioned files to the next commit:

$ git add <filename1> <filename2>

Commit all local changes in tracked files:

$ git commit -a

Commit previously staged changes:

$ git commit

Commit with message:

$ git commit -m 'message here'

Commit skipping the staging area and adding message:

$ git commit -am 'message here'

Commit to some previous date:

$ git commit --date="`date --date='n day ago'`" -am "<Commit Message Here>"

Change last commit:

Don't amend published commits!

$ git commit -a --amend

Amend with last commit but use the previous commit log message

Don't amend published commits!

$ git commit --amend --no-edit

Change committer date of last commit:

GIT_COMMITTER_DATE="date" git commit --amend

Change Author date of last commit:

$ git commit --amend --date="date"

Move uncommitted changes from current branch to some other branch:

$ git stash
$ git checkout branch2
$ git stash pop

Restore stashed changes back to current branch:

$ git stash apply

Restore particular stash back to current branch:

{stash_number} can be obtained from git stash list

$ git stash apply stash@{stash_number}

Remove the last set of stashed changes:

$ git stash drop

Search

A text search on all files in the directory:

$ git grep "Hello"

In any version of a text search:

$ git grep "Hello" v2.5

Show commits that introduced a specific keyword

$ git log -S 'keyword'

Show commits that introduced a specific keyword (using a regular expression)

$ git log -S 'keyword' --pickaxe-regex

Commit History

Show all commits, starting with newest (it'll show the hash, author information, date of commit and title of the commit):

$ git log

Show all the commits(it'll show just the commit hash and the commit message):

$ git log --oneline

Show all commits of a specific user:

$ git log --author="username"

Show changes over time for a specific file:

$ git log -p <file>

Display commits that are present only in remote/branch in right side

$ git log --oneline <origin/master>..<remote/master> --left-right

Who changed, what and when in <file>:

$ git blame <file>

Show Reference log:

$ git reflog show

Delete Reference log:

$ git reflog delete

Move / Rename

Rename a file:

Rename Index.txt to Index.html

$ git mv Index.txt Index.html

Branches & Tags

List all local branches:

$ git branch

List local/remote branches

$ git branch -a

List all remote branches:

$ git branch -r

Switch HEAD branch:

$ git checkout <branch>

Checkout single file from different branch

$ git checkout <branch> -- <filename>

Create and switch new branch:

$ git checkout -b <branch>

Switch to the previous branch, without saying the name explicitly:

$ git checkout -

Create a new branch from an exiting branch and switch to new branch:

$ git checkout -b <new_branch> <existing_branch>

Checkout and create a new branch from existing commit

$ git checkout <commit-hash> -b <new_branch_name>

Create a new branch based on your current HEAD:

$ git branch <new-branch>

Create a new tracking branch based on a remote branch:

$ git branch --track <new-branch> <remote-branch>

Delete a local branch:

$ git branch -d <branch>

Rename current branch to new branch name

$ git branch -m <new_branch_name>

Force delete a local branch:

You will lose unmerged changes!

$ git branch -D <branch>

Mark `HEAD` with a tag:

$ git tag <tag-name>

Mark `HEAD` with a tag and open the editor to include a message:

$ git tag -a <tag-name>

Mark `HEAD` with a tag that includes a message:

$ git tag <tag-name> -am 'message here'

List all tags:

$ git tag

List all tags with their messages (tag message or commit message if tag has no message):

$ git tag -n

Update & Publish

List all current configured remotes:

$ git remote -v

Show information about a remote:

$ git remote show <remote>

Add new remote repository, named <remote>:

$ git remote add <remote> <url>

Rename a remote repository, from <remote> to <new_remote>:

$ git remote rename <remote> <new_remote>

Remove a remote:

$ git remote rm <remote>

Note: git remote rm does not delete the remote repository from the server. It simply removes the remote and its references from your local repository.

Download all changes from <remote>, but don't integrate into HEAD:

$ git fetch <remote>

Download changes and directly merge/integrate into HEAD:

$ git remote pull <remote> <url>

Get all changes from HEAD to local repository:

$ git pull origin master

Get all changes from HEAD to local repository without a merge:

$ git pull --rebase <remote> <branch>

Publish local changes on a remote:

$ git push remote <remote> <branch>

Delete a branch on the remote:

$ git push <remote> :<branch> (since Git v1.5.0)

$ git push <remote> --delete <branch> (since Git v1.7.0)

Publish your tags:

$ git push --tags

Configure the merge tool globally to meld (editor)

$ git config --global merge.tool meld

Use your configured merge tool to solve conflicts:

$ git mergetool

Merge & Rebase

Merge branch into your current HEAD:

$ git merge <branch>

List merged branches

$ git branch --merged

Rebase your current HEAD onto <branch>:

Don't rebase published commit!

$ git rebase <branch>

Abort a rebase:

$ git rebase --abort

Continue a rebase after resolving conflicts:

$ git rebase --continue

Use your editor to manually solve conflicts and (after resolving) mark file as resolved:

$ git add <resolved-file>

$ git rm <resolved-file>

Squashing commits:

$ git rebase -i <commit-just-before-first>

Now replace this,

pick <commit_id>
pick <commit_id2>
pick <commit_id3>

to this,

pick <commit_id>
squash <commit_id2>
squash <commit_id3>

Undo

Discard all local changes in your working directory:

$ git reset --hard HEAD

Get all the files out of the staging area(i.e. undo the last `git add`):

$ git reset HEAD

Discard local changes in a specific file:

$ git checkout HEAD <file>

Revert a commit (by producing a new commit with contrary changes):

$ git revert <commit>

Reset your HEAD pointer to a previous commit and discard all changes since then:

$ git reset --hard <commit>

Reset your HEAD pointer to a remote branch current state.

$ git reset --hard <remote/branch> e.g., upstream/master, origin/my-feature

Reset your HEAD pointer to a previous commit and preserve all changes as unstaged changes:

$ git reset <commit>

Reset your HEAD pointer to a previous commit and preserve uncommitted local changes:

$ git reset --keep <commit>

Remove files that were accidentally committed before they were added to .gitignore

$ git rm -r --cached .
$ git add .
$ git commit -m "remove xyz file"

Git-Flow

Index

Setup
Getting Started
Features
Make a Release
Hotfixes
Commands

Setup

You need a working git installation as prerequisite. Git flow works on OSX, Linux and Windows.

OSX Homebrew:

$ brew install git-flow-avh

OSX Macports:

$ port install git-flow

Linux (Debian-based):

$ sudo apt-get install git-flow

Windows (Cygwin):

You need wget and util-linux to install git-flow.

$ wget -q -O - --no-check-certificate https://raw.githubusercontent.com/petervanderdoes/gitflow/develop/contrib/gitflow-installer.sh install <state> | bash

Getting Started

Git flow needs to be initialized in order to customize your project setup. Start using git-flow by initializing it inside an existing git repository:

Initialize:

You'll have to answer a few questions regarding the naming conventions for your branches. It's recommended to use the default values.

git flow init

To use default

git flow init -d

Features

Develop new features for upcoming releases. Typically exist in developers repos only.

Start a new feature:

This action creates a new feature branch based on 'develop' and switches to it.

git flow feature start MYFEATURE

Finish up a feature:

Finish the development of a feature. This action performs the following:

1) Merged MYFEATURE into 'develop'.

2) Removes the feature branch.

3) Switches back to 'develop' branch

git flow feature finish MYFEATURE

Publish a feature:

Are you developing a feature in collaboration? Publish a feature to the remote server so it can be used by other users.

git flow feature publish MYFEATURE

Getting a published feature:

Get a feature published by another user.

git flow feature pull origin MYFEATURE

Tracking a origin feature:

You can track a feature on origin by using

git flow feature track MYFEATURE

Make a Release

Support preparation of a new production release. Allow for minor bug fixes and preparing meta-data for a release

Start a release:

To start a release, use the git flow release command. It creates a release branch created from the 'develop' branch. You can optionally supply a [BASE] commit sha-1 hash to start the release from. The commit must be on the 'develop' branch.

git flow release start RELEASE [BASE]

It's wise to publish the release branch after creating it to allow release commits by other developers. Do it similar to feature publishing with the command:

git flow release publish RELEASE

(You can track a remote release with the:

git flow release track RELEASE

command)

Finish up a release:

Finishing a release is one of the big steps in git branching. It performs several actions:

1) Merges the release branch back into 'master'

2) Tags the release with its name

3) Back-merges the release into 'develop'

4) Removes the release branch

git flow release finish RELEASE

Don't forget to push your tags with

git push --tags

Hotfixes

Hotfixes arise from the necessity to act immediately upon an undesired state of a live production version. May be branched off from the corresponding tag on the master branch that marks the production version.

Git flow hotfix start:

Like the other git flow commands, a hotfix is started with

$ git flow hotfix start VERSION [BASENAME]

The version argument hereby marks the new hotfix release name. Optionally you can specify a basename to start from.

Finish a hotfix:

By finishing a hotfix it gets merged back into develop and master. Additionally the master merge is tagged with the hotfix version

git flow hotfix finish VERSION