## BridTV introduction

BridTV is a fast-growing technology company and enterprise-level video monetization solution. Thanks to their powerful HTML5 player, high-spec video platform and content management system, they are now devoted to helping their publishers grow and monetize their respective audiences. With offices based in Los Angeles (US) and Belgrade (SER), BridTV is swiftly climbing towards the very summit of online video publishing and advertising.

## Global AWS infrastructure costs optimization
 
BridTV's media streaming solutions are using a broad portfolio of AWS services including EC2, S3, RDS, Redshift and <a href="https://www.stormit.cloud/cloudfront/" target="_blank">CloudFront</a>. StormIT has been helping Brid optimize their global infrastructure costs so they can provide the high standard media streaming services to their publishers as well as sustain profit to support their rapid growth.

<p style="margin-left:15px">

"Customer service. Simple as that. There are many many options out there with respect to Cloud services and it all more or less looks the same. What stood out with StormIT is consistent, reliable and strong customer service. We feel like a true partner, not a number. That is one of the main reasons why I would very likely recommend StormIT."  

**Fabien Ricard, CEO**
</p>


BridTV is a fast-growing technology company and enterprise-level video monetization solution. 

BRID TV | Enterprise-level Video Monetization

medium_brid.png

small_brid.png

thumbnail_brid.png

brid.png

BRID TV - Enterprise-level Video Monetization

In this article, you will learn:

-   [**What is an application migration strategy?**](#what-is-application-migration-strategy)
-   [**Comparison of AWS 6 R’s strategies**](#comparison-aws-6-strategies)
-   [**Understanding AWS 6 R’s**](#understanding-the-aws-6-rs)
-   [**How to choose the right AWS migration strategy**](#decide-which-application-to-migrate)

If you were looking at migrating your existing applications to the AWS Cloud, you usually come across something called AWS 6 R’s model or 6 R’s of cloud migration. This originates from the [“5 R’s” model](https://www.gartner.com/en/documents/1485116/migrating-applications-to-the-cloud-rehost-refactor-revi) published by Gartner in 2010, which defined all the basic options to migrate a specific application to the cloud. Amazon Web Services (AWS) adopted this model and extended it to the 6 R’s: **R**e-host, **R**e-platform, **R**e-factor/**R**e-architect, **R**e-purchase, **R**etire and **R**etain. This post covers the basics for each of these and explains how to decide which AWS migration strategy to choose for your applications.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/13_aws_migration_strategies_1_54de659138.png" alt="AWS 6 R’s model" width="100%"></p>

<h2 id="what-is-application-migration-strategy">What is an application migration strategy?</h2>

Application migration strategy generally refers to the process of migrating the whole application environment and its computing infrastructure. This is usually driven by business decisions for <a href="https://www.stormit.cloud/blog/cloud-cost-optimization-strategies-and-tools/" target="_blank">cost optimization</a>, finding more agility, or simply because of the update of old systems. Here are some basic examples of general application migration:

<p style="margin-left:15px">
-   Migrate an application from one on-premises data center to another
-   From a public cloud to a private cloud environment or vice versa
-   From an on-premises server to a public cloud environment
-   Migrating an application from one cloud provider to another
</p>

Only the last two examples are relevant to application migration to AWS Cloud, and this post focuses on that topic.

<p style="text-align:center">**Working with our experienced team at StormIT, migrations to AWS are accomplished quickly and securely without undue business interruption.**</p>

<a href="https://insights.stormit.cloud/aws-cloud-readiness-assessment-enquiry" class="blog-post__big-buttons">BOOK A CLOUD READINESS CHECK</a>

<h2 id="comparison-aws-6-strategies">Comparison of the AWS 6 R’s strategies</h2>

These six strategies differ in their complexity, opportunity to optimize and effort (money and time). The graph below should help you understand which of the strategies is easiest and which is more complex.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/13_aws_migration_strategies_4_ce0a5f91cc.png" alt="6 R’s of cloud migration" width="90%"></p>

<h2 id="understanding-the-aws-6-rs">Understanding the AWS 6 R’s</h2>

Every AWS migration strategy has its **own journey** and the diagram below should help you understand what are required steps.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/13_aws_migration_strategies_2_596a53ef61.png" alt="" width="100%"></p>

### 1. Retire

After application discovery, you can also decide that you don't need these new applications in the future, so you’re just going to retire them. This is **just getting rid of them** as you’re not going to use them anymore.

### 2. Retain

You can decide to keep applications exactly as is, before a re-evaluation sometime in the future.

<p style="margin-left:15px">
#### An example of this app migration strategy:
-   Unsupported OS and applications
-   Legacy applications that do not have a business justification for migrating to the cloud
</p>

### 3. Re-host

One of the most basic ways of migrating to the AWS Cloud is simply to Re-Host something, and this is sometimes called, **“Lift and Shift”**. This means to take your applications or systems and move them exactly as is into the AWS Cloud environment.

This approach is great for organizations that need to migrate quickly, for example, data center leases that are about to expire.

For the majority of applications, this type of strategy is also the first step, because it’s easier to optimize/re-architect them once they’re already running in the AWS Cloud**.**

<p style="margin-left:15px">
#### Example:
-   Move MySQL database to an [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2) instance on AWS.
-   **This type of app migration strategy was used in our case study:** [**Times of Malta Seamlessly Migrates to AWS Cloud with StormIT**](https://www.stormit.cloud/blog/times-of-malta-migrates-to-aws/)

#### Pros

-   Speed of migration
-   Reduced risk of migration
-   Could be automated or assisted by tools.- [AWS + third-party tools](https://www.stormit.cloud/blog/best-aws-tools-for-migration/) natively support this migration strategy
-   Migration of whole systems (databases, VMs) with configuration

#### Cons

-   You may not use AWS services that give you operational advantages like managed databases, Amazon RDS, DynamoDB, Aurora, Amazon Redshift, and so on
-   Potentially inherit performance issues or other problems
</p>

### 4. Re-platform

We also have Re-Platform which is sometimes called Lift and Reshape, because you can potentially take advantage of some of the special capabilities of the AWS cloud.

<p style="margin-left:15px">
#### An example of this app migration strategy:

-   Take MySQL database, then deploy it using [Amazon RDS MySQL](https://aws.amazon.com/rds/mysql/)
-   Migrating your application to a fully managed platform like [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/)

#### Pros

-   Option to use services that are close to existing infrastructure without requiring code change
-   No dependency on OS, hypervisor or underlying physical hardware platform
-   Opportunity to utilize modern OS/DB features/functionality
-   In some cases, it is possible to use [automated tools](https://www.stormit.cloud/blog/best-aws-tools-for-migration/)

#### Cons

-   Requires additional planning and coordination and these projects may be time-consuming and costlier
-   Necessary knowledge of these “new” cloud services
</p>

### 5. Re-architect

This is the most advanced application migration strategy. Put simply it is a redesign of your application in a more cloud-native manner. In general, you create a [serverless](https://aws.amazon.com/serverless/) version of a legacy application.

<p style="margin-left:15px">
#### Example

-   Migrate your on-premises Oracle database to [Amazon Aurora PostgreSQL](http://aws.amazon.com/rds/aurora/)
-   You can choose to modernize your monolithic application by breaking it down into smaller microservices and leverage services like [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/), [AWS Lambda](https://www.stormit.cloud/aws-lambda/), or [AWS Fargate](https://aws.amazon.com/fargate)
-   **This type of app migration strategy was used in our case study:** [**InScope Choses StormIT and AWS for Deployment of their AML Solution**](https://www.stormit.cloud/blog/inscope-case-study/)

#### Pros

-   Highly increased efficiency, agility and improved cost
-   Eliminating dependency on custom hardware or proprietary technology platforms
-   No infrastructure/servers to maintain

#### Cons

-   Careful evaluation of partners/vendors required
-   Rearchitecting usually grows in time and effort
-   Requires a very good understanding of all aspects of the application, compliance, code, design, and so on
</p>

### 6. Re-purchase

This involves abandoning the existing software that you have and migrating to a cloud-first application. This migration can take two forms: transferring your software license from an on-premises server to AWS (e.g. using a [VM Import/Export](https://aws.amazon.com/ec2/vm-import/) tool), or completely replacing your current application with SaaS options. These solutions can usually be found via the [AWS Marketplace](https://aws.amazon.com/marketplace/search/results/?page=1&filters=FulfillmentOptionType&FulfillmentOptionType=Saas) or [AWS Service Catalog](https://aws.amazon.com/servicecatalog).


<p style="margin-left:15px">
#### Example:

-   Changing your [web application firewall(WAF)](https://www.stormit.cloud/blog/what-is-a-web-application-firewall/) to the one available on AWS(AWS WAF) with managed rules
-   Swapping a self-run email system for an online email-as-a-service offering

#### Pros

-   Reduces effort/increases speed of migration
-   Replace legacy systems with modern applications and SaaS

#### Cons

-   Difficulty with an understanding of dependencies in your current systems
-   Your team needs to learn how to administer a new cloud system
</p>

<p style="text-align:center">**If you want to know more about migration strategy or cloud migration, try reading about [StormIT migration strategy](https://www.stormit.cloud/blog/cloud-migration-strategy-with-stormit/) or visit our page about [cloud migration](https://www.stormit.cloud/aws-migration-services/).**</p>

<h2 id="decide-which-application-to-migrate">How to decide which application migration strategy to choose?</h2>

This decision always depends on the specifics of your current application. If you have two or more applications, you could, for example, **start with the simpler ones and migrate them**, and when you gain more knowledge and experience, migrate the more advanced applications.

Making the right decision also involves **understanding how your new environment will operate once you get your data to the cloud** and what the specific benefits of using an AWS Cloud environment are for your business.


Discover the 6 R's of AWS migration strategy with StormIT. Learn how to streamline your AWS migration for efficiency and success. Start your journey now.

The 6 R’s: AWS Migration Strategies | StormIT

large_6_RS_aws_migration_strategies.jpg

medium_6_RS_aws_migration_strategies.jpg

small_6_RS_aws_migration_strategies.jpg

thumbnail_6_RS_aws_migration_strategies.jpg

6_RS_aws_migration_strategies.jpg

The 6 R’s: AWS Migration Strategies

In this article, you will learn:

-   [**What is Amazon S3 Intelligent-Tiering?**](#what-is-amazon-intelligent-tiering)
-   [**How does S3 Intelligent-Tiering work?**](#how-s3-intelligent-tiering-works)
-   [**S3 Intelligent-Tiering benefits and why you should use it**](#s3-intelligent-tiering-benefits)
-   [**When S3 Intelligent-Tiering is not the right choice**](#when-s3-it-is-not-the-right-choice)
-   [**S3 Intelligent-Tiering pricing**](#s3-intelligent-tiering-pricing)
-   [**How to enable S3 Intelligent-Tiering**](#enable-S3-intelligent-tiering)
-   [**S3 Intelligent-Tiering news**](#S3-intelligent-tiering-news)

AWS (Amazon Web Services) launched **S3 Intelligent-Tiering** in 2018, which added the capability to take advantage of S3 without needing to have a deep understanding of your data access patterns. This solution should **reduce the amount of manual work you need to do to archive objects** with unpredictable access patterns which are not accessed for months at a time. In **2021 AWS announced news** about this storage class which you will find at the end of this article, but first, let’s look at what S3 intelligent tiering is and why you should use it.

<h2 id="what-is-amazon-intelligent-tiering">What is Amazon S3 Intelligent-Tiering?</h2>

Let's first look at the more general things around Amazon S3 and its storage classes so that you can better **understand why S3 Intelligent-Tiering is useful**.

Amazon Simple Storage Service (Amazon S3) is an object storage service provided by AWS. It can be used as a data store for a range of use cases, such as websites, mobile applications, backup and restore, archiving or keeping long-term archives for compliance purposes.

S3 provides different levels of **reliability and availability through its storage classes**. Each storage class has a different cost structure and guarantees about how quickly you can access your data. Some of them even have minimal storage duration.

<p style="margin-left:15px">
- **S3 Standard** : Designed for frequently accessed data.<br>
- **S3 Intelligent-Tiering** : Data with changing or unknown access patterns.<br>
- **S3 Standard-IA** : Designed for long-lived, infrequently accessed data.<br>
- **S3 One Zone-IA** : Designed for long-lived, infrequently accessed, non-critical data.<br>
- **S3 Reduced redundancy** : Frequently accessed, non-critical data.<br>
- **S3 Glacier Instant Retrieval** : Designed for archive data accessed once a quarter with instant retrieval in milliseconds.<br>
- **S3 Glacier Flexible Retrieval (formerly Glacier)** : Designed for infrequently accessed, archived critical data.<br>
- **S3 Glacier Deep Archive** : Long-term data archiving with retrieval times within 12 hours.<br>
</p>

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/24_S3_intelligent_tiering_1_c2c89726c2.png" alt="S3 Storage Classes" width="100%"></p>

### S3 Intelligent-Tiering

S3 Intelligent-Tiering is a storage class designed to optimize storage costs by automatically moving data to the most cost-effective access tier without affecting performance or operational overhead. It is available in all AWS Regions.

<div class="videoWrapper">
<iframe width=85% height="315" src="https://www.youtube.com/embed/yQETDhfv5dI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

AWS created S3 Intelligent-Tiering to **solve the problem of using the correct storage class** and optimizing costs when the access pattern is irregular. When access patterns change, S3 **Intelligent-Tiering automatically saves costs by moving data between access tiers**. This is the perfect storage class when you want to optimize the storage cost of data with unknown or unpredictable access patterns.

For a small monthly object monitoring and automation fee, **S3 Intelligent-Tiering monitors the access patterns** and moves the objects automatically from one tier to another.

#### Intelligent-Tiering will automatically choose between these tiers:

<p style="margin-left:15px">
-   **Frequent Access and Infrequent Access tier:** The first tier is optimized for frequent access, and the other one is optimized for infrequent access. These tiers provide customers with low latency and high throughput performance. **After 30 days** in the Frequently Accessed tier, objects that have not been used will be **moved automatically to the Infrequently Accessed tier**. The frequent access tier is priced as S3 standard, and the Infrequent Access tier is priced as S3 Standard-Infrequent Access.
-   **Archive Instant Access tier (new): After 90 days** in the frequently accessed tier, objects that have not been used will be **moved automatically to the Archive Instant Access tier**.
</p>

##### And you can also enable these two tiers for archive purposes and to further lower cost:

<p style="margin-left:15px">
-   **Archive Access tier:** This tier has the same performance and price as the S3 Glacier Flexible Retrieval storage class. It is used for files that are **not accessed for more than 90 days**, but you can create a custom policy.
-   **Deep Archive Access tier:** This tier has the same performance and price as the S3 Glacier Deep Archive storage class. It is used for files that are **not accessed for more than 180 days**, but you can create a custom policy.
</p>

<p style="text-align:center">
**Learn how to save 30% or more on your cloud computing bill immediately. Get a report that will pinpoint wasted resources, provide resource re-sizing recommendations, and ensure every dollar spent is optimized across your AWS Cloud environment.**
</p>
<a href="https://www.stormit.cloud/cloud-check-up/" class="blog-post__buttons">Get a cloud check-up</a>

<h2 id="how-s3-intelligent-tiering-works">How does S3 Intelligent-Tiering work?</h2>

#### After the 2021 update, it can be divided into two main solutions:

### 1. Automatic Access tiers + Deep Archive Access tier

Objects uploaded or transferred to S3 Intelligent-Tiering are automatically stored in the Frequently Accessed tier.

S3 Intelligent-Tiering works by **monitoring access and usage patterns** and then moving objects that have not been accessed for **30 consecutive days** to the **Infrequent Access tier**.

**After 60 days** in the Infrequently Accessed tier, objects that have not been used will be **moved automatically to the Archive Instant Access tier**. And if you activate the **Deep Archive Access tier**, these objects will be automatically moved after another 90 days (a total of 180 days).

Objects in the Deep Archive Access tier, will be retrieved within 12 hours.

If an object in any of the access tiers is accessed, it is automatically moved back to the Frequent Access tier.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/24_S3_intelligent_tiering_4_d99f106832.png" alt="Automatic Access tiers + Deep Archive Access tier" width="100%"></p>

### 2. Archive + Deep Archive Access tier

If you activate the **Archive Access tier**, S3 Intelligent-Tiering will **stop using the Archive Instant Access tier** and automatically move objects that have not been accessed for 90 days to **the Archive Access tier.** And if you activate the **Deep Archive Access tier**, these objects will be automatically moved after another 90 days (a total of 180 days).

When an object in any Archive Access Tier is restored, the object will move to the frequent access tier within a few hours and then be ready for retrieval. **Objects in the Archive Access tier will be retrieved within 3–5 hours**; if they are in the **Deep Archive Access tier, they will be retrieved within 12 hours**.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/24_S3_intelligent_tiering_2_e6a3b0ed51.png" alt="Archive + Deep Archive Access tier" width="100%"></p>

<h2 id="s3-intelligent-tiering-benefits">S3 Intelligent-Tiering benefits and why you should use it</h2>

Normally, **AWS customers can leverage lifecycle policies that are helpful in some ways**, but they’re a basic instrument. Lifecycle policies always apply to all objects (files) in a given S3 prefix (folder), but the **access patterns for objects can vary**. You might access some files very frequently while some are rarely accessed and used. This can lead to unnecessary storage bills.

By allowing AWS to determine the appropriate tiers for each object and transform them as needed, **customers can not only save money but can also save their time**, because you don’t have to decide at the start which files are best for which storage class.

<p style="margin-left:15px">
-   **Frequent and Infrequent Access tiers have the same low latency and high throughput performance as S3 Standard and save up to 40% on storage costs.**
-   **S3 Intelligent-Tiering is designed for durability of 99.999999999% of objects across multiple Availability Zones with 99.9% availability over a given year.**
-   **No operational overhead, no retrieval charges, and no minimum storage duration.**
</p>

<h2 id="when-s3-it-is-not-the-right-choice">When S3 Intelligent-Tiering is not the right choice</h2>

If S3 Intelligent-Tiering is right for your use case, it can help you **save some money on your AWS bill**. However, it is not suitable for all use cases. The following is a situation where it may not be the right choice. (Though there were more unsuitable situations in the past, after the 2021 update, this is the only remaining situation where S3 Intelligent-Tiering does not make sense.)

-   **Predictable access and usage patterns:** If your objects or whole folders have very predictable access patterns, you can handle them through object [lifecycle rules](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html). You just choose after what time your files should be transferred to another storage class. By doing this, you will avoid a monitoring fee.

<h2 id="s3-intelligent-tiering-pricing">S3 Intelligent-Tiering pricing</h2>

You pay for monthly storage, request and data transfer. When using Intelligent-Tiering you pay a **small monthly per-object fee** (\$0.0025 per 1000 objects) for monitoring and automation.

There is no retrieval fee in S3 Intelligent-Tiering and **no fee for moving data between tiers**.

<p style="margin-left:15px">
-   Objects in the **Frequent Access tier** are billed at the same rate as **S3 Standard.**
-   Objects stored in the **Infrequent Access tier** are billed at the same rate as **S3 Standard Infrequent Access**.
-   And objects in the **Archive Instant Access Tier** are billed at the same rate as **S3 Glacier Instant Retrieval**.
-   Objects stored in the **Archive Access tier** are billed at the same rate as S3 Glacier Flexible Retrieval (Formerly S3 Glacier) and objects stored in the Deep Archive Access tier are billed at the same rate as S3 Glacier Deep Archive.
</p>

**You can find standard rates for every S3 storage class on the official** [**AWS S3 pricing**](https://aws.amazon.com/s3/pricing/) **page.**

### S3 Intelligent-Tiering cost comparison

With a simple example, we can determine if the usage of S3 Intelligent-Tiering is really useful.

For this comparison, assume that you have some objects under a particular prefix (saved in one folder in the S3 bucket). Some are accessed frequently and some are not and you are not able to simply determine this.

#### Let’s use the following example which takes into account one year of usage:
<p style="margin-left:15px">
-   Objects are placed in the region: **Europe (Frankfurt) eu-central-1**.
-   We only use the **Automatic Access tiers** (Frequent, Infrequent, and Archive InstantAccess tier).
-   2,500,000 objects of 0.5MB each are placed into the S3 bucket.
-   Each month, half of the objects are modified twice by a PUT request.
-   Each month, half of the objects are read 15 times by a GET request.
</p>

#### Table with S3 Standard costs:
<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/24_S3_intelligent_tiering_5_13dc1f22b4.png" alt="S3 Standard costs" width="100%"></p>

#### Table with S3 Intelligent-Tiering costs:
<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/24_S3_intelligent_tiering_3_86cb22a9b6.png" alt="S3 Intelligent-Tiering costs" width="100%"></p>

**So, it should be possible to save approximately \$117 (18%) in this simplified example scenario when using S3 Intelligent-Tiering.**

<h2 id="enable-S3-intelligent-tiering">How to enable S3 Intelligent-Tiering</h2>

There are multiple ways of enabling S3 Intelligent-Tiering for data in the S3 bucket or for newly uploaded data.

### Enabling Intelligent-Tiering for folders and files

To set and update object storage classes, you can use the Amazon S3 console, AWS SDKs, or the AWS Command Line Interface (AWS CLI). For more information, see the official AWS documentation: [setting the storage class of an object](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html#sc-howtoset).

### Enabling S3 Intelligent-Tiering with lifecycle rules

You can add rules to an S3 Lifecycle configuration to tell Amazon S3 to transition objects from your current storage class to S3 Intelligent-Tiering. For more information, see the official AWS documentation: [setting lifecycle configuration on a bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html).

### More advanced ways of putting data into Intelligent-Tiering

You can configure S3 Intelligent-Tiering as your default storage class for newly created data, or you can choose to activate one or both of the archive access tiers using the API with [PutBucketIntelligentTieringConfiguration](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketIntelligentTieringConfiguration.html), the CLI, or the Amazon S3 console. See more: [using S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-intelligent-tiering.html).

<p style="text-align:center">
**Having problems with implementation? Let our certified cloud experts guide you.**
</p>

<a href="https://www.stormit.cloud/contact/" class="blog-post__buttons">Talk to a S3 specialist</a>

<h2 id="S3-intelligent-tiering-news">S3 Intelligent-Tiering news</h2>

AWS announced a few features and changes to their S3 Intelligent-Tiering during the AWS Storage Day 2021 and AWS re-Invent 2021.

<p style="margin-left:15px">
-   AWS is removing per-object monitoring and automation charges for **objects smaller than 128 KB**. When AWS released Intelligent-Tiering, objects smaller than 128 KB would never be transitioned to other access tiers and were billed at the usual rate. With these changes, S3 Intelligent-Tiering is the ideal storage class for data independent of object size.
-   You will **not be charged** for objects deleted, transitioned, or overwritten within the first 30 days in S3 Intelligent-Tiering. Previously S3 Intelligent-Tiering was not usable for objects that stayed there for less than 30 days, because this function had a minimum storage duration of 30 days.
-   The Amazon S3 Intelligent-Tiering automatically includes a **new Archive Instant Access tier** (similar to S3 Glacier Instant Retrieval) with further cost savings for data that needs millisecond retrieval.
</p>

**AWS' extensive service and pricing options provide the flexibility to effectively manage costs, learn more in our blog post:** [**Best Practices for Reducing AWS Bill**](https://www.stormit.cloud/blog/aws-cost-optimization/)


Reduce your AWS storage expenses with S3 Intelligent Tiering's automated cost-efficiency. Explore the benefits of smart data storage solutions.

S3 Intelligent Tiering: How it Helps to Optimize Storage Costs?

large_What_is_S3_intelligence.jpg

medium_What_is_S3_intelligence.jpg

small_What_is_S3_intelligence.jpg

thumbnail_What_is_S3_intelligence.jpg

What_is_S3_intelligence.jpg

Amazon S3 Intelligent Tiering: How it Helps to Optimize Storage Costs

In this article, you will learn:

-   [**Why you should migrate to AWS Cloud**](#why-migrate-to-aws)
-   [**StormIT cloud migration services**](#stormit-services-cloud-migration)
-   [**Cloud migration challenges and how to solve them**](#cloud-migration-challenges)
-   [**Useful tools for migration to AWS**](#list-of-8-popular-aws-migration-tools)

Before learning about some useful AWS migration tools and services, it’s important to answer the question of why you should consider migration to AWS Cloud and learn about AWS Cloud migration challenges.

<h2 id="why-migrate-to-aws">Why migrate to AWS?</h2>

Businesses of all sizes are being drawn to the cloud for a range of reasons. By migrating to AWS Cloud, **organizations will be able to focus on business innovation** instead of concentrating on maintaining their complex IT infrastructures.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/5_AWS_tools_8_e182940832.png" alt="why migrate to aws" width="100%"></p>

While every organization is going to have its unique motivations, there are four typical drivers for migrating current solutions to the AWS Cloud:

<p style="margin-left:15px">
-   **User agility and control:** The number one reason customers choose to move to the cloud is for the agility they gain. The AWS Cloud provides more than 200 services including everything from computing, storage, and databases, to continuous integration, data analytics, and artificial intelligence. With AWS, you can simply start hundreds of servers in minutes as opposed to the ten to 18 weeks it typically takes to start servers used on-premises.
-   **Flexibility and scalability:** Cloud computing allows businesses the flexibility to scale their IT resources up or down to meet sudden spikes in demand or unpredictable needs.
-   **Cost savings:** Cloud computing can lower your TCO (Total Cost of Ownership) because every AWS service is designed so that you only pay for what you use. A lot of potential customers of the cloud don’t know what to add to the real TCO of their current solution. We can help you with estimates of your current TCO.
-   **Security and compliance:** This is the highest priority for AWS. As an AWS user, you will leverage a network architecture and data centers built to meet the highest security requirements. You can use AWS security tools to monitor, control, and protect the information that is flowing into and out of your cloud resources.
</p>

**AWS has long been a leader in this industry**, offering all of the above benefits while adding new functions every year. It’s therefore good to look at what AWS is offering, especially as a recent [whitepaper](https://d1.awsstatic.com/enterprise-marketing/cloud-economics/idc-fostering-business-and-organizational-transformation-to-generate-business-value-with-aws.pdf) by IDC showed that customers who migrate to AWS can experience 51% reduced costs of operations, 62% increased IT staff productivity and 94% reductions in downtime.

<h2 id="stormit-services-cloud-migration">StormIT services related to cloud migration</h2>

StormIT offers control over the whole migration process and AWS consultancy for its every step.

<p style="margin-left:15px">
-   **Cloud Migration, Modernization, and Transformation**: Readiness assessment, business outcomes identification, selection of an appropriate migration plan, evaluation of your specific migration needs.
-   **Architecture design:** Design and deployment of high availability architectures, thorough assessment and security planning, non-disruptive to your business.
-   **Cloud Foundation:** AWS Cloud Adoption Framework principles, tailor-made workshops, best practices guidance.
-   **Cost Optimization and Enterprise Cloud Management Platform:** 24/7 monitoring for under-utilized assets, senior AWS Solution Architect consultancy, Cloudcheckr platform access.
</p>

<p style="text-align:center">**You can read more about our cloud migration process and related services here:**</p>
<a href="https://www.stormit.cloud/aws-migration-services/" class="blog-post__buttons">AWS migration services</a>

<h2 id="cloud-migration-challenges">Cloud migration challenges and solutions</h2>

There are some cloud migration challenges that companies will often have to solve. The actual solution is always very specific to the case. But a lot of problems **can be solved by working with an AWS Consulting partner** with the knowledge and experience needed for a successful migration to the AWS Cloud.

### Cost management

The costs of the process are connected to almost every part of the migration.

#### The parts of the process with the highest costs are:

<p style="margin-left:15px">
-   Rewriting/rebuilding application in the AWS
-   Investing in people and tools needed to migrate successfully
-   Training staff on the new systems
-   Performance issues including latency, dependencies on on-premise apps, and business interruptions
-   Bandwidth and data transfer costs
</p>

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/5_AWS_tools_7_cd43bb95ce.png" alt="Parts of the cloud migration process with the highest costs" width="100%"></p>

Solutions lie in the **evaluating, analysing and planning** of the whole process, and the **StormIT team can help you** with every step of your journey.

#### There is also the possibility to use two specific approaches:

-   **Choose a gradual migration process:** This approach has the advantage of breaking down what can be financially overwhelming into more manageable pieces over time.
-   **Start with hybrid cloud:** Full cloud migration may not always be the best option, because it can be very difficult and cost demanding to migrate some applications quickly and without disruption to your business. To begin with, you could choose to only use some of the services of the AWS Cloud. For instance, storage services for backups are always a good start.

### Other challenges and our solutions to them:

#### Legacy applications and what to do with them

Not every application can be moved easily. Which do you keep and **which do you rebuild in the AWS environment** and how?

**StormIT helps you identify the right AWS services** and to implement the right solution. We will answer your questions regarding how to migrate applications and which (if any) applications it is not possible to migrate.

#### Modernization of applications

What are your options for rebuilding applications so they perform optimally in AWS?

StormIT helps you identify the AWS cloud-native services which you can use from the start, **whether you should rebuild your whole architecture and if you can modernize in the future**.

#### Cloud management

Once you have moved your applications, what’s the best way, and **who are the best people to manage them**? Do you have enough knowledge to be able to manage everything yourself?

**StormIT offers** [**Cloud Foundation**](https://www.stormit.cloud/cloud-foundation/) **services** to those who need to learn how to properly use AWS Cloud themselves so they can make the most of every opportunity it offers. We are also able to manage everything for you, so you can focus on your main business goals.

#### Complexity of migration

Understand the complexity you’ll face when migrating and appropriately estimate the effort to get it done. Do you have the right plan for the whole process?

**StormIT plans the whole migration process for you**, so you don’t have to learn about the complexity of migrating to the cloud and the effort required for the process.

#### Dependencies

Resolve dependencies of infrastructure and applications by identifying connections between every component helping you reduce risk, time, and cost.

**StormIT identifies everything in your IT infrastructure** and learns about the dependencies of your applications.

<p style="text-align:center">**Learn more by reading our blog post:** [**Cloud Migration Strategy With StormIT**](https://www.stormit.cloud/blog/cloud-migration-strategy-with-stormit/)</p>

<h2 id="list-of-8-popular-aws-migration-tools">List of 8 best AWS migration tools for cloud migration</h2>

Over the years **AWS has created services and tools you can use for migration to AWS Cloud to help you simplify the process.** These services and tools can help you overcome some common challenges while other services are multifunctional, helping you with the whole process; some solutions can for instance simply collect information about your current progress or help you find third-party software you can use for migration.

### Most important AWS Cloud migration tools and services for the first phase of the migration which can help with the whole process:

### Migration tool n.1: AWS Migration Hub

The [AWS Migration Hub](https://aws.amazon.com/migration-hub/) is not a basic tool for helping with migration: it’s more of an **application in the AWS Management Console that can monitor other tools** used for migration and which also provides a single place to discover your existing servers, plan migrations, and track the status of each application migration. You can view the status of the servers and databases that you are migrating.

Some of the **tools integrated into AWS Migration Hub** are described later in this article, but in general, they can be divided according to their usage:

<p style="margin-left:15px">
-   **Discovery tools:** AWS Discovery Connectors, AWS Discovery Agents
-   **AWS Migration tools:** AWS Database Migration Service(DMS), AWS Server Migration Service(SMS), CloudEndure Migration
-   **AWS migration programs:** Professional Services, Migration Acceleration Program, Migration Partners Solutions
</p>

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/5_AWS_tools_2_b2f71d089a.png" alt="AWS Migration Hub" width="100%"></p>

### Migration tool n.2: AWS Cloud Adoption Readiness Tool (CART)

With [CART](https://cloudreadiness.amazonaws.com/#/cart) you can transform your idea of moving to the cloud into a detailed plan that follows AWS best practices. 

If you choose to use this tool, at first you will take an **online survey and an assessment report** which details your cloud migration readiness including information about your business, people, process, operations, and security. After you complete this survey, you can download a customized cloud migration assessment that describes your readiness and what you can do to improve it. 

**You can find an example of a readiness assessment report** [here](https://cloudreadiness.amazonaws.com/bfd2391ccfbac30513c6cc8b5c40e3ae.pdf).

### AWS Cloud migration tools and services for the second phase:**

### Migration tool n.3: AWS Application Discovery Services

The [AWS Application Discovery Services](https://aws.amazon.com/application-discovery/) help companies in the discovery and gathering of information about their on-premise solutions by identifying servers hosted in data centers. It **collects server specification information** (CPU & RAM utilization and disk I/O), and details of running processes and network communications between servers. After the discovery of your on-premise servers, you can export this data to a CSV file and use it to estimate the Total Cost of Ownership (TCO) of running on AWS.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/5_AWS_tools_4_55be9db642.png" alt="AWS Application Discovery Services" width="100%"></p>

### Migration tool n.4: AWS Control Tower

Formerly named AWS Landing Zone, the [AWS Control Tower](https://aws.amazon.com/controltower/) is intended for organizations that need to easily set up multiple accounts environments and assign these accounts to the right team in the organization structure. Control Tower will help you get started quickly with governance and best practices built-in.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/5_AWS_tools_5_b04130b08b.png" alt="AWS Control Tower" width="100%"></p>

### Best AWS data migration tools and services for the final migration phase:

### Migration tool n.5: AWS Marketplace

[AWS Marketplace](https://aws.amazon.com/marketplace) is a digital catalog with thousands of software listings from independent software vendors. It includes popular categories such as security, networking, storage, machine learning, business intelligence, and databases. **Users can quickly launch pre-configured software** with just a few clicks, and choose software solutions in Amazon Machine Images (AMIs), software as a service (SaaS), AWS CloudFormation, and other formats. The product can be free or it can have an associated charge. Every software product on AWS Marketplace has been through a curation process.

### Migration tool n.6: VMware Cloud on AWS (VMC)

[VMC](https://aws.amazon.com/vmware/) is useful for those who want to **find a way to use VMware in the AWS cloud** and leverage the benefits of the public cloud, such as scalability and cost savings.<br>
<br>
VMC on AWS allows you to quickly relocate hundreds of applications virtualized on vSphere to the AWS Cloud in just days and to maintain consistent operations with your VMware environments. You can easily use any of the AWS services, but you can also leverage your knowledge of VMware.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/5_AWS_tools_1_e9aaec79a7.jpg" alt="VMware Cloud on AWS" width="80%"></p>

### Migration tool n.7: AWS Database Migration Service (DMS)

The most popular data migration tool is [DMS](https://aws.amazon.com/dms/), which helps you **migrate your current databases to the AWS Cloud reliably, quickly, and securely**. The source database remains fully operational during the migration, minimizing downtime.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/5_AWS_tools_6_6f77e0a1df.png" alt="AWS Database Migration Service (DMS)" width="100%"></p>

**Some of the features of DMS:**

<p style="margin-left:15px">
-   **Continuous Data Replication:** Perform continuous data replication between an on-premise solution and AWS.
-   **Homogeneous Database Migrations:** Homogeneous database migration means that the source and target database engines are the same or are compatible like Oracle to Amazon RDS for Oracle, MySQL to Amazon Aurora, etc.
-   **Heterogeneous Database Migrations:** In heterogeneous database migrations the source and target databases engines are different, like in the case of Oracle to Amazon Aurora, Oracle to PostgreSQL, etc.
</p>

### Migration tool n.8: AWS Server Migration Service (AWS SMS)

This service **migrates on-premises servers to AWS**. [AWS SMS](https://aws.amazon.com/server-migration-service/) incrementally replicates your server VMs (VMware vSphere, Microsoft Hyper-V/SCVMM, and Azure virtual machines) as Amazon Machine Images (AMIs), making them ready for deployment on Amazon EC2 (AWS virtual machines).

**Benefits of using AWS SMS:**

-   **Simplify the migration process:** With just a few clicks in the AWS Management Console, you can begin migrating a group of servers. AWS SMS manages the whole migration process.
-   **Supports most commonly used operating systems**: You can simply start the replication of operating system images containing Windows and Linux distributions.
-   **Leverage the minimized downtime:** Replication is incremental and minimizes the business impact.

**There are more services and tools to help migrate to AWS Cloud, but this was the condensed list of the most useful.**

<p style="text-align:center">**Do you need help with migration to the cloud or do you have any questions regarding AWS tools and services for migration?**</p>
<a href="https://www.stormit.cloud/contact/" class="blog-post__buttons">Get help</a>



Discover top cloud migration tools for AWS and tips for efficient migration. Navigate the setup and streamline your cloud transition effortlessly.

8 Best AWS Cloud Migration Tools | StormIT

large_cloud-migration-tools.jpg

medium_cloud-migration-tools.jpg

small_cloud-migration-tools.jpg

thumbnail_cloud-migration-tools.jpg

cloud-migration-tools.jpg

8 Best AWS Cloud Migration Tools to Overcome Migration Challenges

In this article, you will learn:

-   [**Amazon API Gateway free tier**](#api-gateway-freetier)
-   [**API Gateway on-demand pricing**](#api-gateway-pricing)
-   [**Six Amazon API Gateway cost optimization tips**](#api-gateway-cost-optimization-tips)

[Amazon API Gateway](https://www.stormit.cloud/blog/api-gateway/) is the Amazon Web Services(AWS) solution for **connecting an API to the public Internet or a private network**. In a lot of cases, it’s an important piece of AWS architecture and it’s therefore equally **important to understand its pricing**. API Gateway is often also the **most expensive piece of AWS serverless infrastructure**, though depending on how it is used and optimized, costs can be kept very low.

In this blog post, we will cover AWS’s API Gateway pricing, the free tier, and how to optimize its costs.

<h2 id="api-gateway-freetier">Amazon API Gateway free tier</h2>

#### API Gateway is billed based on the usage:

<p style="margin-left:15px">
-   A number of requests per month to your API.
-   Connection minutes for Websocket APIs.
-   Cache memory size and minutes of its actual usage.
-   Additional charges, such as [Data transfer out (DTO)](https://www.stormit.cloud/blog/aws-data-transfer-pricing-how-to-reduce-costs/).
</p>

### API Gateway free-tier

API Gateway provides a free tier that **is available for 12 months after the initial sign-up date**. When this 12-month term expires or if your application use exceeds the tiers, you simply pay standard rates.

#### The monthly free tier includes:

<p style="margin-left:15px">
-   **1 million REST API calls**
-   **1 million HTTP API calls**
-   **1 million messages**
-   **750,000 connection minutes**
</p>

<h2 id="api-gateway-pricing">Amazon API Gateway on-demand pricing</h2>

### HTTP APIs

HTTP APIs are charged based on the number of API calls made. HTTP APIs calls are metered in 512 KB increments, so for example, 513 KB is metered as two requests.

This is the pricing in the Europe (Ireland) region:

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/40_api_gateway_pricing_4_a0a6353715.png" alt="" width="70%"></p>

### REST APIs

REST APIs are also charged based on the number of API calls made. This is the current pricing in the Europe (Ireland) region.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/40_api_gateway_pricing_5_80ceff4ce6.png" alt="" width="70%"></p>

### Websocket APIs*

Websocket APIs are charged based on the number of messages sent and received as well as the total number of connection minutes. Messages are metered in 32 KB increments, so for example, 33 KB is metered as two requests.

The table below shows the current pricing for messages in Europe (Ireland):

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/40_api_gateway_pricing_6_695c714dc8.png" alt="" width="70%"></p>

Connection Minutes are charged at **\$0.25** per million connection minutes.

### API gateway cache pricing

REST APIs provide the ability to provision a dedicated cache to improve performance. The pricing for the cache is based on the amount of memory provisioned.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/40_api_gateway_pricing_7_d4b8937404.png" alt="" width="70%"></p>

### Additional charges

There might also be other additional charges depending on how the API Gateway is being used such as:

<p style="margin-left:15px">
-   Data transfer: If you transfer data to the public Internet, you will be charged at the EC2 data transfer rate(0.09\$ per GB). Learn more about it in the cost optimization tip.
-   Cloudwatch: Includes pricing for metrics and dashboards.
-   [AWS Lambda](https://www.stormit.cloud/blog/aws-lambda-pricing/) and other services.
</p>

<h2 id="api-gateway-cost-optimization-tips">Six Amazon API Gateway cost optimization tips</h2>

The costs of Amazon API Gateway are often higher than of a Lambda itself and while these costs are adequate for the specific features (e.g. authentication management, caching, request/response transformation, proxying), there are a **couple of ways to generally save on its costs** or even not use it at all and choose other services from AWS.

![40_api-gateway-pricing-1.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/40_api_gateway_pricing_1_fef2008065.png)

### 1. Right type of API gateway

What you can do to optimize your API Gateway costs is to choose the right type of API Gateway. AWS offers both REST APIs and HTTP APIs. The HTTP API has more limited functionality but is also much cheaper. If it suits your needs you can save a lot of money by using it over the REST API.

For existing REST APIs, consider migrating to HTTP APIs. When planning for migration, see [Choosing between HTTP APIs and REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html) to compare HTTP API and REST API supported features.

### 2. API Gateway integration feature

Another great tip to save on your API Gateway bill is to use AWS service proxy integrations instead of combining a Lambda function to transfer/transform input data from the client. You can integrate API Gateway with other AWS services directly (e.g. Kinesis, DynamoDB, SQS, SNS, etc.) by using [API Gateway integration features](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-integration-types.html).

### 3. Cognito authentication

When your front-end is the only consumer of the backend APIs, you can l**everage Cognito to obtain IAM credentials for your users**. They can then invoke your Lambda functions safely using the AWS Javascript SDK and the temporary credentials. This solution allows you to achieve both authentication and authorization via IAM, **avoiding the need for an API Gateway** at the cost of reduced functionalities (you have to prepare your request on the frontend side, and also manage responses and errors in your Lambda code).

### 4. Replace API Gateway with ALB (Application Load Balancer)

As your application scales, consider replacing the API Gateway with an [ALB (Application Load Balancer)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html). Since ALB supports triggering the Lambda function, ALB could be a better choice for cost savings unless you’re using Amazon API Gateway’s unique features, such as authentication management, caching, and request/response transformation.

### 5. Reduce unnecessary API calls

Remove any unnecessary API calls and optimize your application to prevent them. As your application evolves we often end up with redundant and unnecessary API calls and these can add significantly to our costs.

### 6. Reduce data transfer costs

If you transfer data from API Gateway to the public Internet, you will **be charged at the standard data transfer rate** (0.09\$ per GB).

![40_api-gateway-pricing-2.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/40_api_gateway_pricing_2_af7e6146ad.png)

At StormIT we have helped many customers to optimize their overall spending on data transfer (egress bandwidth) from different industries with a broad range of use cases from web applications and blogs to media streaming and gaming.

Using a content delivery network such as [**Amazon CloudFront**](https://www.stormit.cloud/cdn-services/) **is essential to keeping data transfer costs low**. CloudFront moves your most accessed content to the “front” of the AWS network (i.e., PoPs), ensuring fast delivery to your end users. Data transfers into CloudFront from other AWS resources (S3, EC2, API Gateway) are free.

![40_api-gateway-pricing-3.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/40_api_gateway_pricing_3_65e3474e56.png)

Obviously, every project/case is unique, but we are confident that by smartly using CloudFront it is possible to achieve overall lower costs and improved performance.

<Calculator />

## Conclusion

Amazon API Gateway is one of the most popular serverless services from AWS. Customers are **charged based on a pay-as-you-go model** which is very cost efficient for some customers. This blog post introduced Amazon API Gateway pricing and should help you with the cost optimization of this service.


Navigate API Gateway pricing with StormIT: Effective strategies to lower costs and optimize your AWS usage. Save on AWS bills today!

Amazon API Gateway Pricing: 6 Tips to Control the Cost

large_API-gateway_pricing.jpg

medium_API-gateway_pricing.jpg

small_API-gateway_pricing.jpg

thumbnail_API-gateway_pricing.jpg

API-gateway_pricing.jpg

Amazon API Gateway Pricing: Six Tips to Control the Cost

In this article, you will learn:

-   [**How does AWS Lambda pricing work?**](#how-lambda-works)
-   [**How to calculate AWS Lambda costs**](#calculate-lambda-costs)
-   [**AWS Lambda vs Amazon EC2 cost comparison**](#lambda-vs-ec2-costs)
-   [**AWS Lambda cost advantages and disadvantages**](#lambda-cost-advantages-disadvantages)
-   [**Optimizing AWS Lambda Costs**](#lambda-cost-optimization)

There are plenty of benefits to going serverless, from low latency to scalability to simple deployment. **With** [**AWS Lambda**](https://www.stormit.cloud/aws-lambda/)**, you only pay for the time your code is running**. This model forever changes the relationship between application code and infrastructure costs. **The hardware is automatically provisioned with every aspect when needed and billed accordingly**. There is no need to manage and sometimes overprovision servers to cope with the load.

In this article, we’ll take a look at the AWS Lambda pricing model, some things you need to keep in mind when using it and how to optimize the cost of Lambda functions.

<h2 id="how-lambda-works">How does AWS Lambda pricing work?</h2>

### There are multiple AWS Lambda pricing options:

<p style="margin-left:15px">
-   **Free-tier:** The AWS Lambda free tier includes **one million free requests per month and 400,000 GB-seconds of compute time per month**, usable for functions powered by both x86 and Graviton2 processors, in aggregate.
-   **Lambda on-demand:** Your costs are determined by pay-as-you-go pricing and the actual usage of AWS Lambda.
-   **AWS Lambda saving plans:** These plans are a flexible pricing model that offers low prices on AWS Lambda usage in exchange for a commitment to a consistent amount of usage for a one- or three-year term. With these plans, you can save up to 17 percent.
</p>

In general, **Lambda functions run only when triggered** and the calculation of the cost of running your Lambda function is based on:

<p style="margin-left:15px">
-   **A number of executions/invocations.**
-   **Duration of the execution in milliseconds.**
-   **Memory size (Between 128 MB and 10 240 MB).**
-   **Usage of AWS Lambda provisioned concurrency**
</p>

**AWS uses GB-seconds as the main unit, so you will need to use this formula:**

![38_lambda-pricing-7.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/38_lambda_pricing_7_09b910fe55.png)

For each Lambda function, you can set the **maximum memory size and maximum function execution time.** The more memory you provision, the more CPU your function gets.

In general, you will need to add costs for DTO (data transfer out) and other services like Amazon API Gateway, Amazon S3, Amazon CloudFront, etc. But this blog post is focused on AWS Lambda.

**AWS Lambda request charges in Europe and US regions:**

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/38_lambda_pricing_1_6180d24ab4.png" alt="" width="80%"></p>

**Lambda GB second charges in Europe and US regions:**

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/38_lambda_pricing_2_9066093b53.png" alt="" width="80%"></p>

<h2 id="calculate-lambda-costs">How to calculate AWS Lambda costs</h2>

It’s best to go through a simple example when you need to understand how to do this.

### Here’s an example of AWS Lambda costs calculation.

We assume that this example organization is in Europe (Ireland), but this example will work for every US and European region because the pricing is the same for them:

<p style="margin-left:15px">
-   You allocate **512 MB of memory to your functions**.
-   Execute it **5 million times** in a month.
-   Run approximately for **200 milliseconds** each time.
</p>

Do not forget that AWS offers every account holder one million free requests and 400,000 GB-seconds of compute time monthly.

Thus, you calculate an AWS Lambda bill like this:

![38_lambda-pricing-4.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/38_lambda_pricing_4_ebc1e5472d.png)

This example takes into account only AWS Lambda pricing. You may pay more depending on the other AWS services you use with Lambda, such as data transfer charges.

<p style="text-align:center">
**Having problems with your AWS Lambda costs estimation? Contact us and our team of AWS certified specialists will help you with the calculations.**
</p>

<a href="https://www.stormit.cloud/contact/" class="blog-post__buttons">Contact us</a>

<h2 id="lambda-vs-ec2-costs">AWS Lambda vs Amazon EC2 cost comparison</h2>

Amazon EC2 can provide the stability that developers can take advantage of to build robust web applications, or it can **provide on-demand usage by Auto-Scaling**, which is primarily billed at the time the instances are running.

When comparing AWS Lambda pricing, it's important to understand the characteristics of your application. While **Lambda is billed based on the GB-seconds your function** uses during execution, **with EC2 you need to think more about machine design** as the cost increases with the size of the machine you choose, and you also need to add the cost of high availability, safety, and the compliance of these machines.

With **EC2 instances,** **you must fully develop/manage the contents of the machine**, from choosing a web server to launching application instances through middleware to respond to user requests. You also typically need to run EC2 instances across multiple AZs using an Elastic Load Balancer, which can incur significant costs.

Compare this to **AWS Lambda**, where **you only need to write your application's functions** at the most granular level. The developer's time investment can be higher, as can the costs involved. But you will most likely pay less for running, managing, and also for the high availability and security of these functions.

<h2 id="lambda-cost-advantages-disadvantages">AWS Lambda cost advantages and disadvantages</h2>

### Lambda cost advantages

Comparing a traditional resource (EC2 instance) to a serverless resource like AWS Lambda will always be use-case dependent, but there are a few cost advantages that can lend weight to choosing Function-as-a-Service (FAAS) architecture over a traditional approach:

![38_lambda-pricing-8.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/38_lambda_pricing_8_7c604b870a.png)

#### 1\. Low usage or light workloads = Low cost

For light workloads, AWS Lambda is cheap, especially if your usage falls under the fairly generous free usage tier. **Depending on your specific use case**, a simplified Lambda function infrastructure can **significantly outperform equivalent EC2 instances**, which require additional development and configuration.

#### 2\. Control and testing capabilities

If your Lambda charges are higher than you expected, you can quickly take control and try to change your code, change the memory size or limit the execution time.

#### 3\. Granularity

AWS Lambda gives you a more granular cost measurement than EC2, which is billed by time rather than resource usage. You can **get a per-execution view** of the resources used by your Lambda function, and you can use this data to more accurately predict the cost of future runs.

#### 4\. Cost-based pricing of your applications

With each run, **you can clearly see what expenses are incurred** by your organization. When this data is fed into a pricing model, it can be used to reduce the **cost per request**.

Combining this with a dynamic pricing, **you can change how much you charge users based on their actual resource usage**. This cost-based pricing allows you to ensure you're being fairly compensated for the effort you put into your app, rather than relying on a flat monthly fee that's profitable for only a portion of your user base.

### Lambda cost disadvantages/challenges

While the flexibility of Lambda over the traditional approach **gives you a lot of options in optimizing your application’s resource expenditures**, the serverless approach introduces some **unique challenges**. These challenges can add unpredictability to your application’s running costs if not carefully monitored and managed.

![38_lambda-pricing-5.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/38_lambda_pricing_5_1342819e1b.png)

#### 1\. Forecasting Costs

One of the hardest parts of optimizing an application is finding out exactly how many resources your application consumes. This is doubly challenging in a serverless environment, as each application path can include an indeterminate number of Lambda invocations. This complicates cost forecasting, adding confusion to infrastructure budgeting.

#### 2\. Cost explosions

Lambda can be very susceptible to cost increases due to heightened usage. While ideally this heightened usage results from an increasing user base, lending some predictability to the growth, there are several scenarios where you can end up with a large bill with very little warning. DDoS attacks, for example, can very quickly drive your Lambda bills through the roof.

Simple development bugs can result in greatly inflated costs if your developers, for example, **add an infinite loop or fail to make use of caching**.

#### 3\. Complexity and usage of other services

Building a robust serverless application doesn't stop at the invocation of your Lambda functions. You need services to store user data (Amazon S3), additional development and maintenance load for the disparate functions of your application, and so on.

Each of these elements has the potential to increase your costs in a way that wouldn’t necessarily be present in a more traditional EC2-based application.

<h2 id="lambda-cost-optimization">Optimizing AWS Lambda Costs</h2>

With the flexibility of serverless applications, you gain the advantage over traditional applications when it comes to optimizing execution costs. The granularity of AWS Lambda billing and how often you receive related information gives you a lot of flexibility in optimizing your application's resource usage.

![38_lambda-pricing-6.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/38_lambda_pricing_6_63042d955c.png)

### 1. AWS regions and data transfer

One of the ignored costs in AWS Lambda development is the [cost of data transfer](https://www.stormit.cloud/blog/aws-data-transfer-pricing-how-to-reduce-costs/) between AWS regions. If your AWS Lambda function uses AWS resources **spread across multiple regions**, you’re paying for the data transfer between those services. Moving your Lambda functions to the same region as the resources they depend upon can reduce your data transfer costs.

You’ll also be **charged for the data transfer between the internet and your functions** at standard EC2 data transfer rates **(0.09\$ per GB)**. At StormIT, we have helped many customers to **optimize their overall spending on data transfer (up to 60%) by using Amazon CloudFront CDN**.

<p style="text-align:center">
StormIT offers custom Amazon CloudFront** **pay-as-you-go pricing and you pay only for what you use.
</p>
<a href="https://www.stormit.cloud/cdn-cost-calculator/" class="blog-post__buttons">Estimate savings</a>

### 2. Optimize memory allocation

**Choosing the right size of** [**Lambda memory**](https://docs.aws.amazon.com/lambda/latest/operatorguide/computing-power.html) means that with AWS, you can set the memory, and in turn CPU, of your AWS Lambda functions. **There’s no need to over-provision**. It is **quite easy to switch to the memory option which will cover your new requirements**.

**AWS doesn’t allow you to customize the CPU for Lambda functions**, but the more memory you allocate, the more computing power you get. There are a few caveats to this strategy, though. **For example: over 2 GB of RAM, Lambda will allocate a second vCPU to the function.** In this case, single-threaded programs won’t see any speed gains from increasing memory. 

### 3. Writing efficient code

Quite simply, a Lambda function that runs in half the time is a function that costs you half the money. The execution time is proportional to the amount you charge. If the execution takes a long time, it is wise to change your function and iterate.

You can leverage the duration metric inside the CloudWatch or you can try using [AWS X-Ray](https://aws.amazon.com/xray/) to analyze and debug your applications.

### 4. Caching

If your code is not running, you will not be charged. **Proper** [**Lambda caching**](https://aws.amazon.com/blogs/compute/caching-data-and-configuration-settings-with-aws-lambda-extensions/) **methods can also have a significant impact on your AWS Lambda running costs**. By adding caching in your serverless functions or client-side caching in your front-end code, you can reduce costs by doing less work.

## Conclusion

There are other strategies to reduce cost and optimize it for your own needs and there are various choices to make to reduce costs and optimize them for your own needs.

The essential thing you need is to discover which of the given approaches best suits your personal needs. After finding out what you need, it will be easier to choose a more personalized way to reduce costs.

<p style="text-align:center">
**The StormIT team has the** [**AWS Service Delivery Program designation for AWS Lambda** ](https://www.stormit.cloud/blog/stormit-sd-aws-lambda/)**and helps organizations to redesign their legacy applications or release new ones by leveraging the AWS Lambda and other AWS serverless services.** **Got a question? Please get in touch.**
</p>


Optimize your AWS Lambda costs with essential strategies and insights. Learn how AWS Lambda pricing works and start saving!

AWS Lambda Pricing: Cost Optimization Approaches Guide

large_AWS_Lambda_Pricing.jpg

medium_AWS_Lambda_Pricing.jpg

small_AWS_Lambda_Pricing.jpg

thumbnail_AWS_Lambda_Pricing.jpg

AWS_Lambda_Pricing.jpg

In this article, you will learn:

-   [**What is an origin server?**](#what-is-an-origin-server)
-   [**Difference between an origin and edge server**](#origin-server-vs-edge-server)
-   [**How to reduce the origin server load** ](#reducing-origin-server-load)
-   [**Reducing server load with Amazon CloudFront CDN**](#reducing-server-load-cloudfront)

When talking about Content Delivery Network (CDN) you will nearly always see some reference to an origin or origin server. If you want to know what an origin server is, the difference between edge and origin servers, or how to reduce the load on the origin server, read more below.

<h2 id="what-is-an-origin-server">What is an origin server?</h2>

An origin server (origin) is a computer or **service where content is stored or computed and is designed to listen and respond to incoming requests**. An origin server can have for instance the original version of your website files (HTML, CSS, JS files). This term is usually used to identify the webserver from the cache (edge) server of a CDN.

The most used origin In the AWS Cloud environment is Amazon S3 bucket, Amazon EC2 instance, AWS Elemental MediaPackage, or Elastic Load Balancer.

<h2 id="origin-server-vs-edge-server">Origin server vs. edge server</h2>

An **origin server**, sometimes called a CDN origin server, is a computer or service, which is the last point of your network and receives all traffic when you are not using a CDN. Using an origin server without a CDN means that every request must be returned to the physical location of the origin server, regardless of where in the world it resides. This increases the load time, which increases the distance between the server and the client machine making the request.

An **edge server** is a computer or service that exists at the “edge" of the network. Edge servers are usually used as connections between different networks. CDN edge servers store content in strategic locations to take the load off of one or more origin servers. The main purpose of the edge server is to store content as close as possible to the requesting client machine and help by reducing latency and shortening page load time. An edge server is an edge device that provides an entry point into the network. Other edge devices can include routers.

A CDN origin server and edge server **work together to bring content to users**, as you can see in the picture below:

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/19_What_is_origin_server_1_18744a91fe.png" alt="origin server and edge server infographic" width="100%"></p>

<h2 id="reducing-origin-server-load">Reducing origin server load</h2>

### How CDNs reduce your server load

If you haven't used a content delivery network, it may be time to consider investing. CDN is a distributed network consisting of strategically placed edge servers that can quickly deliver web content to users around the world.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/16_What_is_RTT_6_df941de283.png" alt="what is cdn" width="100%"></p>

**CDN can reduce your server load** and speed up your website by caching the static content of your website. By storing copies of your website at access points around the world, CDN ensures that visitors receive content from servers that are geographically close to them.

Therefore, the [round-trip time](https://www.stormit.cloud/blog/what-is-round-trip-time-rtt-meaning-calculation/) is **greatly reduced**, and visitors from far away will not slow down for local users. Given that a typical site can contain up to 80% of static assets, using a CDN can **greatly help to offload data from the origin server**.

### Is it possible to offload all content delivery by CDN from my origin server?

Not likely. The main metric to understand for this is the [cache hit ratio](https://www.stormit.cloud/blog/cache-hit-ratio-what-is-it/). While most CDNs offload a considerable part of all content delivery tasks, the exact amount **depends on the CDN’s capabilities** and the particulars of your website, application or use case.

CDN edge servers will be able to cache static resources, including images, CSS stylesheets, and JavaScript files. This alone can save upwards of 60% of your bandwidth usage. More advanced CDNs, like [Amazon CloudFront](https://www.stormit.cloud/cloudfront/), can also cache dynamically generated content (e.g., API calls, ads that are computed on the fly). With such capabilities, caching hit potential increases to 70%–90%, or more.

<h2 id="reducing-server-load-cloudfront">Reducing server load with Amazon CloudFront CDN</h2>

Amazon CloudFront has a global network of edge locations and intelligent software that can deliver content to users around the world from the locations closest to users or with the best performance.

Parts of your website (such as HTML, images, style sheets, and JavaScript files) are served by cached copies stored in CloudFront edge locations and regional edge caches. For parts that are not cached locally, such as newly updated content or specific dynamic requests, CloudFront obtains them from your origin server through a fast and optimized path due to persistent connections on the global network privately managed by AWS.

With support for all HTTP methods, including GET, PUT, and POST, **CloudFront can speed up your entire website.**

Using the following advice can **help further with reducing server load**:

-   **Use CloudFront Origin Shield**: [Origin Shield](https://www.stormit.cloud/blog/origin-shield/) can further reduce the number of simultaneous requests that are sent to your origin for the same object. Requests for content that is not in Origin Shield’s cache are consolidated with other requests for the same object, resulting in as few as one request going to your origin.
  
<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/19_What_is_origin_server_2_68abe5f7ea.png" alt="" width="90%"></p>

-   **Optimize your cache hit ratio**: If you don’t know what a cache hit ratio is, consider reading our blog post [What is a Cache Hit Ratio?](https://www.stormit.cloud/blog/cache-hit-ratio-what-is-it/) first. You can also follow these [AWS recommendations](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html) to get a higher cache hit rate.
-   **There are even more things that you can do** on the application level to optimize server load further. For example, front-end optimization techniques include compression, minification, image optimizations, and removing render-blocking JavaScript. Another option is using [Lambda@Edge](https://www.stormit.cloud/blog/lambda-at-edge/) to run some of your application logic.

<p style="text-align:center">The StormIT team understands that a well-implemented **CDN will optimize your infrastructure costs, effectively distribute resources, and deliver maximum speed** with minimum latency.</p>

<a href="https://www.stormit.cloud/contact/" class="blog-post__buttons">Talk to a CDN specialist</a>

## Summary

Many factors can slow down the performance of an application or website. If reducing the origin server load does not make your website run smoother, then you may have other problems to solve. However, if you notice that the load on the origin server has peaked and is causing concern, consider using the above tips.

<p style="text-align:center">
To learn more about different Amazon CloudFront CDN functions and how they impact your performance, security and cost continue by reading the blogpost – [What is a CDN and Why Use it in Your Business?](https://www.stormit.cloud/blog/what-is-cdn/)
</p>



Learn: What is an origin server. Difference between an origin and edge server and how to reduce server load with Amazon CloudFront CDN

What is an Origin Server & How to Reduce its Load? | StormIT

large_origin-server.jpg

medium_origin-server.jpg

small_origin-server.jpg

thumbnail_origin-server.jpg

origin-server.jpg

What is an Origin Server & How to Reduce its Load?

In this article, you will learn:

-   [**What is Amazon Inspector?**](#what-is-amazon-inspector)
-   [**Benefits of Amazon Inspector**](#benefits-of-amazon-inspector)
-   [**How does Amazon Inspector work?**](#how-inspector-works)
-   [**Amazon Inspector agent installation**](#inspector-installation)
-   [**Amazon Inspector pricing**](#inspector-pricing)
-   [**Amazon Inspector vs. Amazon GuardDuty**](#inspector-vs-guardduty)
-   [**Integration with AWS Security Hub**](#inspector-and-aws-security-hub)

As the threat of attacks on the integrity, confidentiality, and availability of data within an organization continues to increase, finding an **easy way to monitor and improve the security in the AWS** (Amazon Web Services) environment is key.

AWS provides a wide range of security services to help you achieve the best level of security possible in your environment, and the **Amazon Inspector** service is just one of the services that can help.

This blog post will introduce what Amazon Inspector Classic is, how it works, its benefits, and also how to install the Amazon Inspector agent which is necessary for some of its features and enables you to get the most benefit out of it.

This blog post is about Amazon Inspector Classic, there is a [new version available from November 2021](https://docs.aws.amazon.com/inspector/v1/userguide/inspector-migration.html). Amazon Inspector has been completely rearchitected to automate vulnerability management and deliver near real-time findings to minimize the time to discover new vulnerabilities.

<h2 id="what-is-amazon-inspector">What is Amazon Inspector?</h2>

Amazon Inspector is an AWS automated service that collects vulnerabilities in your AWS environment and provides you with security findings reports. Currently, it is **mainly based on protecting your Amazon EC2 instance**. It checks your EC2 instances for unexpected **network accessibility** and against a **library of best practices, common compliance standards, and public libraries of known vulnerabilities**.

![28_Amazon-Inspector-2.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/28_Amazon_Inspector_2_dd27851275.png)

It then prioritizes these issues into **security findings** by severity level and describes how to resolve issues to protect your AWS environment. The severity levels are high, medium, and low. All of these indicate the existence of security issues that may lead to **compromised confidentiality, integrity, and availability of information in EC2 instances.**

![28_Amazon-Inspector-3.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/28_Amazon_Inspector_3_65acb96b14.png)

Every **security finding includes useful information** about the issue, but also recommendations on how to solve it.

![28_Amazon-Inspector-4.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/28_Amazon_Inspector_4_bb495c77bb.png)

<h2 id="benefits-of-amazon-inspector">Benefits of Amazon Inspector</h2>

<p style="margin-left:15px">
-   **Easy to integrate automated security:** easily implement Amazon Inspector to EC2 instances and use it for forensics, troubleshooting, or auditing purposes. Run security checks during the development process, or run them in a stable production environment.
-   **Deeply analyze Amazon EC2 instances: s**tay informed about the activity and configuration data of your instances. Reduce risk by checking security issues as soon as they appear.
-   **Find application security issues and solve them**: develop and iterate on new applications quickly, and assess compliance with best practices and policies. Proactively manage your security issues before they impact your applications or your production websites.
</p>

<p style="text-align:center">
**Achieve unrivaled security and compliance with the StormIT Cloud Check-Up. We perform a gap analysis with more than 600 Best Practice Checks to reduce risk, identify security vulnerabilities, and remediate compliance breaks in your AWS environment.**
</p>
<a href="https://www.stormit.cloud/cloud-check-up/" class="blog-post__buttons">Get a cloud check-up</a>

<h2 id="how-inspector-works">How does Amazon Inspector work?</h2>

Amazon Inspector performs and generates a findings report containing steps to keep the AWS environment safe. To use it, you need to define the EC2 instances that you want to check and for proper function, **install the Amazon Inspector agent**. You can also set the scheduled checks against your EC2 instances which can vary from 15 minutes to 12 hours and recur after a chosen number of days.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/28_Amazon_Inspector_1_44bf8e7bdc.png" alt="How does Amazon Inspector work" width="100%"></p>

After collecting all the required data, it is compared with the built-in **security rules packages** to identify security or compliance issues.

### Amazon Inspector rules packages

The main part of the Amazon Inspector is assessments/rules packages which are prepared by AWS security specialists for your use. Every rules package is focused on a different set of rules that your EC2 instance should meet.

#### Network assessment/rule package (Amazon Inspector agent is not required):

-   [Network Reachability](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_network-reachability.html): The rules in the Network Reachability package analyze your network configurations to find security vulnerabilities in your EC2 instances.

#### Host assessments/rules package (Amazon Inspector agent is required):

-   [Common vulnerabilities and exposures](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_cves.html): The rules in this package help verify whether the EC2 instances are exposed to common vulnerabilities and exposures (CVEs). For more information, see <https://cve.mitre.org/>.
-   [Center for Internet Security (CIS) Benchmarks](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_cis.html): The CIS Security Benchmarks program provides industry best practices to help organizations improve their security.
-   [Security best practices for Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_security-best-practices.html): Specific set of best practices in the AWS environment.

<h2 id="inspector-installation">Amazon Inspector agent installation and getting started</h2>

To get started with Amazon Inspector and the host assessments/rules package, you need to install an **Amazon Inspector agent** that enables access to your Amazon EC2 instances and applications running on them.

If you simply go through the steps in the [Amazon Inspector console](https://console.aws.amazon.com/inspector/home), you should be able to install this agent automatically by using [AWS System Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html). Just start by clicking “Get started” and go through the steps.

If you need to **install an agent manually**, here are some basic steps to install an Amazon Inspector agent on multiple types of operating systems.

### 1. Installing the Amazon Inspector agent on Amazon EC2 instance with Linux

#### To install the agent on a EC2 instance with Linux:

<p style="margin-left:15px">

**1.** Sign in/connect to your EC2 instance running a Linux-based operating system where you want to install the Amazon Inspector agent.<br>
<br>
**2.** Download the agent installation script by running the following command:<br>
<p style="margin-left:15px; background-color:Gainsboro">
wget https://inspector-agent.amazonaws.com/linux/latest/install
</p>

**3.** To install the agent, run:<br>
<p style="margin-left:15px; background-color:Gainsboro">
sudo bash install
</p>

**4.** You should see the confirmation in the console<br>

![28_Amazon-Inspector-6.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/28_Amazon_Inspector_6_e40778bcd2.png)
</p>

### 2. Installing the Amazon Inspector agent on Amazon EC2 instance with Windows

#### To install the agent on a Windows-based EC2 instance

<p style="margin-left:15px">

**1\. **Sign in to your EC2 instance with Windows where you want to install the agent.<br>

Download the following .exe file from the official AWS repository: [AWSAgentInstall](https://inspector-agent.amazonaws.com/windows/installer/latest/AWSAgentInstall.exe)<br>
<br>
**2\. **Run this file as an administrator or open a command prompt window as admin and run the file to install the agent.<br>
<br>
**3\. **After successful installation of the Amazon Inspector agent you can start using the host **assessments/rules package; just open the** [Amazon Inspector console](https://console.aws.amazon.com/inspector/home) and get started.<br>
</p>

<h2 id="inspector-pricing">Amazon Inspector pricing</h2>

Amazon Inspector pricing is based on **a number of Amazon EC2 instances** included in each check and depends on the **rules packages** you select for assessments.

### Free-tier

If you have never run an Amazon Inspector, you are eligible for **250 runs** with a host and network rules packages **at no cost during the first 90 days**. This means you can run Amazon Inspector checks ten times against 25 instances (250 runs) for free.

### Pricing example for those without the free tier:

In this example, all of your Amazon Inspector **runs include both host rules packages and the network reachability rules package**. Additionally, all of your EC2 instances have the Amazon Inspector agent on them.

So we assume **five runs against 15 instances**. You would therefore be charged for **75 host and network reachability instance assessments**.

The Amazon Inspector charges for your account for this billing period would be:

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/28_Amazon_Inspector_5_be008e3aae.png" alt="Amazon Inspector pricing example" width="100%"></p>

Adding up all the above, the total Amazon Inspector cost per billing period would be \$33.75. If you still have the free tier available, the above would be free.

Visit the [Amazon Inspector pricing page](https://aws.amazon.com/inspector/pricing/) if you need more information.


<h2 id="inspector-vs-guardduty">Amazon Inspector vs. Amazon GuardDuty</h2>

Both Amazon Inspector and Amazon GuardDuty are services that enhance the security of your AWS environment.

**Amazon Inspector** provides you with security checks of your AWS environment and **it only covers Amazon EC2**. There is an Amazon Inspector agent that you need to install to do a wider set of security checks.

In contrast, **Amazon GuardDuty helps with analyzing the entire AWS account**, can be quickly enabled, and monitors unusual account usage using a variety of **sources like AWS CloudTrail logs, DNS logs, and other** sources. Read more about it in our blog post: [What is Amazon GuardDuty? Definition, Pricing & Comparison](https://www.stormit.cloud/blog/amazon-guardduty/)


<h2 id="inspector-and-aws-security-hub">Integration with AWS Security Hub</h2>

Amazon Inspector can be used with the **AWS Security Hub.** Security Hub provides a **single place in the AWS environment to aggregate, organize, and prioritize security alerts** and discoveries from multiple AWS security services. Learn more in our blog post: [What is AWS Security Hub?](https://www.stormit.cloud/blog/aws-security-hub/)

Unlock the full potential of Amazon Inspector for AWS security. Learn its workings, benefits, and setup process to safeguard your cloud environment effectively.

Amazon Inspector: How to Get The Most Out Of It | StormIT

large_Amazon-Inspector.jpg

medium_Amazon-Inspector.jpg

small_Amazon-Inspector.jpg

thumbnail_Amazon-Inspector.jpg

Amazon-Inspector.jpg

Amazon Inspector: How to Get The Most Benefit Out of it

In this article, you will learn about:

-   [**The basics of Amazon Route 53 pricing**](#route53-pricing-basics)
-   [**Route 53 free tier**](#route53-free-tier)
-   [**A thorough overview on Route 53 pricing**](#route53-overview-pricing)
-   [**Route 53 domain registration pricing**](#route53-domain-name-pricing)
-   [**Route 53 hosted zones pricing**](#route53-hosted-zone-pricing)
-   [**Route 53 pricing example**](#route53-pricing-example)

Typically Route 53 doesn't tend to be a large cost center for the vast majority of businesses operating in the AWS Cloud. But when deciding where you will buy or host your domain name, it can be difficult to understand the final costs of Route 53.

This blog post will introduce the main elements of [Amazon Route 53 DNS](https://www.stormit.cloud/blog/amazon-route-53/) costs and explain which parts of this AWS service are free and which are paid.

<h2 id="route53-pricing-basics">The basics of Amazon Route 53 pricing</h2>

**First, it’s good to understand the main parts of what you will see on your AWS bill:**

![33_Route-53-pricing-5.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/33_Route_53_pricing_5_3d3559a4d3.png)

-   **DNS queries:** You pay for every DNS query answered by the Amazon Route 53 service (**except for queries** to Alias or A records which are routed to Elastic Load Balancers, AWS Elastic Beanstalk environments, CloudFront distributions, VPC endpoints, API Gateways, or Amazon S3 buckets).
-   **Hosted zones:** You pay a monthly price for each zone hosted with Route 53. A hosted zone holds information about how you want to route traffic for a specific domain, such as site.com, and its subdomains (videos.site.com, pics.site.com).
-   **Health checks:** These help you monitor the health and performance of your endpoints (web servers, and other resources). The first 50 AWS endpoint health checks are free. Health checks against non-AWS endpoints are paid.
-   **Health checks with optional features:** You will pay extra if you enable special functions for health checks, such as latency monitoring or fast checks (every 10s instead of the standard 30s).

<h2 id="route53-free-tier">Route 53 free tier</h2>

If you check the official AWS website about the [free tier](https://aws.amazon.com/free/), you will find that AWS doesn’t offer a free tier for Route 53. But here is a list of Route 53 functions/features that are, in fact, free. Knowing about these features will help you understand h**ow to avoid Route 53 charges.**

<p style="margin-left:15px">
-   To allow testing, a Route 53 **hosted zone that is deleted within 12 hours of creation is not charged**.
-   The **first 50 Health Checks of AWS endpoints** that are within or linked to their AWS account or billed to the same account as the health check are free of charge.
-   **DNS Queries to Alias records of other AWS services are free of charge**. This is crucial to know if you connect any hosted zone to AWS services, such as CloudFront CDN or Elastic Load Balancers, queries for this hosted zone will be free.
-   Generally, DNS queries are free when both of the following are true:
-   The domain or subdomain name (site.com or videos.site.com) and the record type (A) in the query match an Alias record.
-   The alias target is an AWS resource other than another Route 53 record.
</p>

<p style="text-align:center">
**Customers often open their monthly AWS Cloud bills, hoping they have saved money, only to find that unexpected AWS data transfer costs seem to have appeared from nowhere. Learn how to reduce your data transfer costs.**
</p>
<a href="https://www.stormit.cloud/blog/aws-data-transfer-pricing-how-to-reduce-costs/" class="blog-post__buttons">Learn more</a>

<h2 id="route53-overview-pricing">A thorough overview on Route 53 pricing</h2>

<h3 id="route53-domain-name-pricing">1\. AWS domain name pricing in Route 53</h3>

You pay **an annual charge for each domain name registered** via or transferred into Route 53. There is a limit of 20 domain name registrations per AWS account.

The fee to register a domain ranges from \$5 to several hundred dollars, depending on the top-level domain, such as \*.com or \*.org. View a list with [current AWS domain registration pricing](https://d32ze2gidvkk54.cloudfront.net/Amazon_Route_53_Domain_Registration_Pricing_20140731.pdf). You can't use Route 53 to register a domain that has a special or premium price.

For example, for a \*.com domain, the most popular, it will cost you around \$12 per year within Route 53.

![33_Route-53-pricing-7.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/33_Route_53_pricing_7_8565300555.png)

When you register a domain in Route 53, AWS **automatically creates a hosted zone** that has the same name as the domain. The fee for a hosted zone is \$0.50 per month.

<h3 id="route53-hosted-zone-pricing">2\. Hosted Zones</h3>

You'll need a hosted zone for each second-level domain (SLD). So, if you have site.com and site.net, you'll need two hosted zones. Subdomains (videos.site.com) are routed in the records of this hosted zone.

A hosted zone is charged at the time it's created (if not deleted within 12 hours of creation) and on the first day of each subsequent month.

<p style="margin-left:15px">
-   **For the first 25 hosted zones cost \$0.50 per month/hosted zone**
-   **And for additional hosted zones the cost is \$0.10 per month/hosted zone**
</p>

### 3. DNS Queries

Some of the query types are **charged based on the routing policy** that you choose when creating a new record for your hosted zone.

![33_Route-53-pricing-1.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/33_Route_53_pricing_1_554bdc877f.png)

#### a. Alias Queries**

Queries for qualifying Alias records are provided **at no additional cost** to Route 53 customers. You can create Alias records for all of the query types (standard, latency based, geo and geoproximity).

You can **create Alias records for AWS resources**, such as:

<p style="margin-left:15px">
-   Elastic Load Balancers
-   [Amazon CloudFront](https://www.stormit.cloud/cloudfront/) distributions
-   API Gateways
-   AWS Elastic Beanstalk environments
-   Amazon S3 buckets that are configured as website endpoints
-   For a complete list, see [Alias Target](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-alias.html#rrsets-values-alias-alias-target)
</p>

**For other queries, you will be charged based on the query type. If some of the queries do not fall into any of the categories below, they are charged the standard price, such as for a record that doesn't exist (ww1.site.com).**

#### b. Standard DNS queries (simple, weighted, failover, and multivalue)**
<p style="margin-left:15px">
-   **\$0.40 per million queries** – 0 to 1 Billion queries/month
-   \$0.20 per million queries – over 1 Billion queries/month
</p>

#### c. Geolocation-based queries**)

<p style="margin-left:15px">
-   **\$0.70 per million queries** – 0 to 1 Billion queries/month
-   \$0.35 per million queries -- over 1 Billion queries/month
</p>

#### d. Latency-based queries**

<p style="margin-left:15px">
-   **\$0.60 per million queries** – 0 to 1 Billion queries/month
-   \$0.30 per million queries – over 1 Billion queries/month
</p>

### 4\. Traffic Flow policies and records

Traffic Flow offers **a visual interface in which users can drag and drop elements** of traffic routes into a graphical diagram for easier management. You create a policy record when you associate an Amazon Route 53 Traffic Flow policy with a specific domain name (such as www.site.com).

<p style="margin-left:15px">
-   **\$50.00 per month for a Traffic Flow policy record**
</p>

![33_Route-53-pricing-4.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/33_Route_53_pricing_4_8093c1a3ef.png)

### 5. Health Checks

Route 53 health checks are a function that allows you to **monitor the health** of selected types of AWS resources or any endpoints that can respond to requests. [Learn more...](https://www.stormit.cloud/blog/route-53-health-check/)

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/33_Route_53_pricing_2_a00aff571b.png" alt="" width="90%"></p>

### 6. Route 53 resolver pricing**

The DNS Resolver service for VPCs integrates easily with DNS on your on-premises network.

![33_Route-53-pricing-9.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/33_Route_53_pricing_9_0b5e9296eb.png)

#### Route 53 Resolver endpoints**

A Route 53 Resolver endpoint requires two or more IP addresses. Each IP address corresponds with one elastic network interface (ENI).

<p style="margin-left:15px">
-   \$0.125 per hour for ENI
</p>

#### Recursive DNS queries to and from on-premises networks**

Only queries that pass through a Route 53 Resolver Endpoint (either inbound or outbound) will be charged.

<p style="margin-left:15px">
-   **\$0.40 per million queries** – 0 to 1 Billion queries/month
-   \$0.20 per million queries – over 1 Billion queries/month
</p>

<h2 id="route53-pricing-example">Route 53 pricing example</h2>

Let’s assume that we have a business website domain that we host in Route 53.

<p style="margin-left:15px">
-   **We have three domains:** site-test.com, site-test.net, and site-test.cloud .
-   Our **website uses one server outside of AWS Cloud** and does around 1,000,000 queries to it every month.
-   Our website is hosted on EC2 instances behind Application Load Balancers. This part is queried approximately 4,000,000 times a month to ALBs via an Alias record.
-   We use a **health checking feature in Route 53 for our non-AWS server and our ALB**, so we can be notified via SNS when there is something wrong. Health checks do not have any special features (latency, fast checking, etc.).
</p>

![33_Route-53-pricing-3.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/33_Route_53_pricing_3_997c896771.png)


Learn about the main elements of Amazon Route 53 DNS costs and which parts of this AWS service are free. 

Amazon Route 53 Pricing: How does it work? | StormIT

large_route_53_pricing_7.jpg

medium_route_53_pricing_7.jpg

small_route_53_pricing_7.jpg

thumbnail_route_53_pricing_7.jpg

route_53_pricing_7.jpg

Amazon Route 53 Pricing: How Does it Work?

Kubernetes has become the ubiquitous standard for container orchestration and has revolutionized the way we deploy and manage containerized applications. Despite its benefits of scalability, flexibility, and ease of management, for organizations that run their workloads on Kubernetes, cloud services cost remains a critical concern. One effective strategy for optimizing the costs of <a href="https://www.stormit.cloud/blog/basics-of-aws-eks/" target="_blank">Amazon Elastic Kubernetes Service (Amazon EKS)</a> workloads is leveraging Spot Instances.

In this article, we'll explore how to optimize Kubernetes workloads on AWS EKS for cost efficiency using spot instances.

## Understanding Spot Instances

Spot Instances are spare AWS EC2 capacity and a unique offering from Amazon EC2 that allows you to leverage unused computing power at significantly reduced rates with discounts often of up to 90% compared to on-demand instances. 

Being that Spot Instances are interruptible, meaning they can be reclaimed by AWS at any time, **they are ideal for fault-tolerant workloads, batch processing, and containerized applications that can handle interruptions gracefully**.

## Case Study: Schlieger Cost Optimization using Spot Instances

One of our customers, Schlieger, recently migrated from conventional servers to the AWS cloud. To manage their monthly cloud budget, they capitalized on the flexibility provided by Amazon EKS and strategically opted for Spot Instance worker nodes.

Our solution is a hybrid approach, where critical components run on On-Demand instances, while **non-critical workloads utilize Spot Instances**. It adheres to best practices by selecting multiple instance types for the node groups, ensuring that the chosen instances have equivalent CPU and memory resources. We deploy a cluster autoscaler that dynamically adjusts the number of nodes to ensure optimal resource utilization and application availability.

By leveraging a combination of On-Demand and Spot Instances worker nodes, we maintained a scalable and reliable workload with **the core benefit of 75–80% cost savings**.

Here are some additional best practices for effectively utilizing **Spot Instances** within your **Amazon EKS environment**:

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/spot_6a5557efe0.png" alt="spot instance infrastructure" width="100%"></p>


<p style="margin-left:15px">
- **Use Spot Fleet:** This allows the provisioning of a heterogeneous fleet of Spot Instances across multiple instance types, sizes, and Availability Zones. Spot Fleet automatically manages instance provisioning and maintains target capacity, enhancing workload availability and reliability.

- **Leverage Spot Blocks**: This offers a more predictable pricing model for Spot Instances by allowing organizations to reserve capacity for a specified duration (one to six hours). This can be beneficial for workloads with predictable runtime requirements, providing cost predictability while still benefiting from savings.

- **Graceful Termination Handling**: It is essential for Kubernetes workloads running on Spot Instances to implement mechanisms for graceful termination and rescheduling to handle interruptions effectively. This ensures minimal disruption to application availability and performance.
</p>

## Conclusion

Optimizing Kubernetes workloads on AWS EKS using Spot Instances is a smart strategy for cost-conscious businesses. By following best practices and leveraging Spot capacity, you can strike the right balance between cost efficiency and performance. At StormIT, we understand the importance of cost optimization in the AWS Cloud. That's why we offer our expertise in the Well-Architected Review framework with the option to focus specifically on the cost optimization pillar.

Learn how to optimize Kubernetes workloads on AWS EKS for cost efficiency using Spot Instances. Explore now...

Optimizing Kubernetes Workloads on AWS EKS for Cost Efficiency

large_eks-cost-opt-spot.JPG

medium_eks-cost-opt-spot.JPG

small_eks-cost-opt-spot.JPG

thumbnail_eks-cost-opt-spot.JPG

eks-cost-opt-spot.JPG

In this article, you will learn how to:

-   **[Create an S3 bucket and set it up for static website hosting](#create-s3-bucket)**
-   **[Create a record set in Route 53](#route-53-first)**
-   **[Set up a CloudFront distribution and link it with a custom domain](#cloudFront-distribution)**
-   **[Secure the connection via SSL and AWS Certificate Manager](#aws-certificate-manager)**

We will be hosting a static website in an S3 bucket. Then, we will set up a custom domain together with <a href="https://www.stormit.cloud/blog/amazon-route-53/" target="_blank">Route 53 DNS</a>. And finally, we will spin up a <a href="https://www.stormit.cloud/cloudfront/" target="_blank">CloudFront CDN</a>, link it with our custom domain via Route 53, and secure the whole connection using an SSL certificate and AWS Certificate Manager.

As mentioned, you are going to need a custom domain for this particular setup. You can get one online for free for example at <a href="https://www.freenom.com/" target="_blank">Freenom</a>.

If you want to learn how to deploy this type of architecture in an automated way using AWS CDK (Cloud Development Kit), you can watch our video: <a href="https://youtu.be/NRZEoXG59g0" target="_blank">Deploying a Static Website with HTTPS using CDK, TypeScript, CloudFront, S3, ACM and Route 53</a>

If you want, you can follow our instructions in the video below, that describes every step in AWS Management Console:

<div class="videoWrapper">
<iframe width="560" height="315" src="https://www.youtube.com/embed/FtNfhwyPMAs" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

**Our workflow today is going to be:**

- Set up an S3 bucket
- Set up records in Route 53
- Create a CloudFront CDN distribution
- Create an SSL certificate for HTTPS
- Link the CloudFront CDN, S3, custom domain and SSL certificate via Route 53

<h2 id="create-s3-bucket">S3 Bucket</h2>

In this section, we are going to create an S3 bucket, open the bucket for public acess, set it up for static website hosting and upload a simple static website to it. Finally we will test that everything is working correctly by trying to view our website from outside of AWS.

### First, we are going to create an S3 bucket:

-   Go to your AWS console and search for S3. Click it.
-   Click ‘Create Bucket’. Choose a *globally unique* bucket name and AWS region.
-   Untick “Block all public access” and confirm it, since we want our static website accessible from the internet.
-   That’s it, you don’t need anything else in this menu and can click ‘Create bucket’.

### Then we need to open the bucket to public:
-   Open the bucket you just created from the console. The bucket should be empty.
-   Click *Properties*, and then sroll down to *Static website hosting* and click 'Edit'.
-   Choose 'Enable' under "Static website hosting"
-   Choose "Host a static website".
-   Choose an Index document and an Error document. You can fill in “index.html” into both.
-   Hit *Save changes*.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/1_s3_settings_static_website_hosting_d13a6fb7a2.png" alt="S3 static website hosting settings" width="85%"></p>

### Finally, we have to edit the Bucket Policies.

-   In S3, o over to *Permissions.* Then *Bucket Policy*.
-   Here you need to fill in a policy which will allow the bucket to be publicly accessed. I recommend using the official AWS policy generator for these purposes, which can be found at: <a href="https://awspolicygen.s3.amazonaws.com/policygen.html" target="_blank">AWS Policy Generator</a>
-   At the generator, you need to choose *S3 bucket policy* as the Type of Policy. Principal will be “\*” (without quotes), and Actions will be “GetObject”.
-   Fill in your ARN, which can be found in AWS Console where you were about to fill in the bucket policy. There, at the top of the page you should be able to find the ARN in the format of *arn:aws:s3:::\<bucket_name\>.*

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/2_s3_settings_static_website_hosting_2160edf9c5.png" alt="aws policy generator settings" width="90%"></p>
<br>
-   **Important:** before you paste in the ARN, append a slash and asterisk at the end, so it will look something like: arn:aws:s3:::stormit-demos/\* (my bucket name is “stormit-demos1”). This will allow access to *everything* inside the bucket. Click *Add Statement.*

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/3_s3_settings_static_website_hosting_bf37835d0c.png" alt="" width="90%"></p>

-   Finally, click *Generate policy.* 

-   Copy the whole policy over to the S3 AWS console

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/4_s3_settings_static_website_hosting_9be6ab3136.png" alt="s3 bucket policy settings" width="90%"></p>

That’s it for our S3 Bucket setup. When you open your bucket, you should see a red bubble with white text *Publicly accessible* under the name of your bucket. If you do, everything is correct and we can proceed. 

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/5_s3_settings_static_website_hosting_3eeed5b53e.png" alt="Public s3 bucket" width="55%"></p>

### Next, we’re going to upload dummy website files into the bucket & test access to it:

-   <a href="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/demo_47738c0331.zip" target="_blank">Download a prepared static website</a>. You can use some other website if you’d like, but keep in mind that the next steps might be a bit different for you if you do.
-   In your AWS console inside your S3 Bucket hit *Upload*, then *Add files* and upload your index.html file. Hit *Upload*.
-   Click *Create folder* and create a folder called “images”. Do not use any encryption (default).
-   Navigate into the images folder you just created and upload the provided GIF image, same as when we uploaded the index.html.
-   Once both files are uploaded, click on index.html within the S3 bucket and locate “Object URL”. Click it. You should see a GIF of a puppy playing with a pillow (assuming you used the provided files).

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/6_s3_settings_static_website_hosting_646bd85f8d.png" alt="S3 index file path" width="70%"></p>

Congratulations – you’ve just set up an S3 bucket, uploaded a website and opened it for public access. Next, we’re going to set up routing in Route 53.

<p style="text-align:center">
**Learn in our blog post how the S3 Intelligent-Tiering storage class can help you deliver automatic cost savings by moving data between access tiers: <a href="https://www.stormit.cloud/blog/s3-intelligent-tiering-storage-class/" target="_blank">Amazon S3 Intelligent-Tiering: How it Helps to Optimize Storage Costs</a>**
</p>

<h2 id="route-53-first">Route 53 (first time around):</h2> 

Create hosted zone in Route 53:
-   In your AWS Console search for Route 53 under Services.
-   Under ‘DNS management’, click *Create hosted zone.*
-   Inside the ‘Domain name’ field input your domain name. You can obtain one for free from <a href="https://www.freenom.com" target="_blank">Freenom</a>.
-   ‘Type’ will be *Public hosted zone*.
-   Click *Create hosted zone.*
-   Now we need to link our domain with the records in Route 53. 
-   Note the values as marked on the picture. These are nameservers which we need to link with our domain, basically telling our domain “when someone tries to reach you, you redirect them to one of these servers”.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/7_s3_settings_static_website_hosting_f211272e1f.png" alt="Route 53 nameserver records" width="90%"></p>

-   Open a new tab in your browser (leave the Route 53 page with the nameservers open) and go to your domain management page, in my case freenom.com. Log in, open the list of your domains and click Manage Domain. Under Management Tools click Nameservers. You should see 5 text fields named Nameserver 1-5.
-   Go back to your Route 53 nameserver page and copy the URLs one by one to the fields in your domain management page. **Important:** copy the URLS over without the dot at the end. So for example you’d copy “ns-869.awsdns-44.net.” as “ns-869.awsdns-44.net” (without the dot at the end).

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/8_s3_settings_static_website_hosting_3562674084.png" alt="freenom nameservers settings" width="100%"></p>

-   Once you’ve copied everything, confirm by clicking *Change Nameservers*.
-   That’s it for Route 53 for now, but we will return to it later.

Now we want to set up an SSL certificate via the AWS Certificate Manager in order to secure our CloudFront custom domain with SSL.

<h2 id="aws-certificate-manager">AWS Certificate Manager</h2> 

-   In your AWS Console search for Certificate Manager and click the link.
-   Important: You have to select the AWS North Virginia region(US-East-1). CloudFront recognizes only this region as it's ACM certificates.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/12_s3_settings_static_website_hosting_62ee2a8006.png" alt="freenom nameservers settings" width="50%"></p>

-   Click *Get started* under Provision certificates
-   Click *Request a public certificate* and then *Request a certificate*.
-   Fill in the Domain name (in my case it is stormit-demos1.cf), click *Next*.
-   Choose a method of validation, I recommend DNS validation.
-   We do not need anything else, so continue clicking *Next* until you can *Confirm and request* the certificate.
-   On the next screen you’ll see that the certificate status is “Pending validation”. In order for it to get validated we need to link it with our Route 53 records, and we can do that by clicking on the “Certificate ID”.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/9_s3_settings_static_website_hosting_9c689edb9b.png" alt="" width="70%"></p>

-   Next click on *Create record in Route 53* button under *Domains*. 

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/10_s3_settings_static_website_hosting_6346fc946b.png" alt="" width="70%"></p>

-   Then click *Create records*.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/11_s3_settings_static_website_hosting_22c7456368.png" alt="" width="80%"></p>

-   That’s it for the Certificate Manager. It can take up to 30 minutes for the certificate to be issued so try to be patient.

After the certificate is issued, we can set up the last element in our deployment, which is a CloudFront distribution.

<h2 id="cloudFront-distribution">CloudFront Ditribution</h2> 

In this section, we are going to spin up a <a href="https://www.stormit.cloud/cloudfront/" target="_blank">CloudFront CDN</a> distribution with an S3 bucket so that when anyone tries to access our distribution, they will actually be accessing our S3 bucket while taking advantage of the speed of CloudFront.

### Create CloudFront distribution

-   In your AWS Console search for CloudFront and click the link.
-   Click *Create Distribution*. On the next page click *Get Started* in the Web section, since we will be wanting a web distribution.
-   You should see an **Origin settings** page with many options and fields.
-   For the **Origin Domain Name**, you will need to go back to your S3 management console (Services -\> S3), but leave the CloudFront setup page open. Once in the S3 management console, click on your bucket name, then click on *Properties* and scroll down to *Static website hosting*. Copy over the highlighted part of the Endpoint URL:

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/13_s3_settings_static_website_hosting_866ffc1b3c.png" alt="" width="70%"></p>

-   Go back to the CloudFront setup page and paste the URL inside the *Origin Domain Name* field*.* You may notice that AWS already offers you an S3 option from the drop down list, but that wouldn't point to the actual website.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/14_s3_settings_static_website_hosting_8a6d786e86.png" alt="" width="70%"></p>

### CloudFront SSL certificate:

-   Under Viewer Protocol Policy choose *Redirect HTTP to HTTPS*
-   Now scroll all the way down to the Alternate Domain Names (CNAMEs) field and type in your domain name without http(s), i.e. example_domain.com
-   Under **Settings**, choose *Custom SSL Certificate* for CloudFront SSL encryption*.* Click into the field below - the SSL certificate you provisioned earlier should be offered to you. Choose it.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/16_s3_settings_static_website_hosting_d11d96a4ca.png" alt="cloudfront cname and certificate settings" width="75%"></p>

-   That's it. Click *Create Distribution* at the very bottom of the page.
-   The distribution takes about 10-20 minutes to provision. Once it is provisioned (Status = Deployed, State = Enabled), you can test it by pasting the URL under Domain Name into your browser. You should see the website you uploaded into S3.

We are almost done, we have S3, CloudFront SSL certificate, but there's one more step we need to take. If you go ahead and try to load your domain name in your web browser, you'll notice that the page can't be loaded. That is because all we have to do now is to create a record in Route 53 and basically tell it to direct traffic from your domain to your CloudFront distribution.

<p style="text-align:center">**StormIT team has a proven track record of experience and delivered projects with Amazon CloudFront and is proud to be designated as the AWS Service Delivery Partner for the Amazon CloudFront CDN service.**
<br>
<br>
**We provide special pricing for organizations transferring as little as 1 TB of data per month and have saved companies up to 60% on their CDN data transfer-out costs.**</p>

<a href="https://www.stormit.cloud/cdn-cost-calculator/" class="blog-post__buttons" target="_blank">Estimate savings</a>

<h2 id="route53-second">Route 53 (revisited)</h2> 

-   Click *Services* and type in Route 53, click the link. Click the name of your hosted zone.
-   Click *Create record.* Choose *Simple routing,* click *Next* and then *Define record.*
-   Click the dropdown menu at Value/Route traffic to and choose *Alias to CloudFront distribution.*
-   Choose the distribution you provisioned previously.
-   Notice that the only available region is US East (N. Virgina)[us-east-1]. This is due to the fact that we provisioned an SSL Certificate via AWS Certificate manager. This service is only available in US East 1.
-   Click *Create Records*.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/17_s3_settings_static_website_hosting_af634ba615.png" alt="cloudfront cname and certificate settings" width="100%"></p>

And that's it. All you have to do now is wait a few minutes for the DNS records to update and try to load your domain name. If everything went correctly, you should see your static website distributed via CloudFront.

If not, please try to retrace your steps following this guide or have a look at our [Video Guide](https://www.youtube.com/watch?v=FtNfhwyPMAs&feature=emb_title&ab_channel=StormIT).

**Hope you enjoyed this guide and happy clouding!**



Create an S3 bucket and set it up for static website hosting and set up a CloudFront distribution, and secure the connection via SSL. Learn more...

Setup a CloudFront distribution with SSL, custom domain and S3

large_s3-diagram-cloudfront-acm-route53.png

medium_s3-diagram-cloudfront-acm-route53.png

small_s3-diagram-cloudfront-acm-route53.png

thumbnail_s3-diagram-cloudfront-acm-route53.png

s3-diagram-cloudfront-acm-route53.png

Setup an Amazon CloudFront distribution with SSL, custom domain and S3

In this article, you will learn:

-   [**Key benefits of using serverless computing**](#benefits-of-serverless)
-   [**The power of serverless technologies**](#power-of-serverless)

Serverless is a cloud computing model that automatically manages resource allocation for applications. Developers upload their code to the cloud environment where it is automatically launched, scaled and optimized without the need for explicit server management. This model enables more efficient use of resources and cost optimization, as you only pay for what your applications actually consume.

<h2 id="benefits-of-serverless">Key benefits of using serverless computing</h2>

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/Serverless_benefits_92f5533049.png" alt="serverless benefits" width="100%"></p>

### Efficiency and scalability

Serverless applications are **automatically scaled according to demand at any time and without the need for manual intervention**. This leaves you with peace of mind and means you don't have to spend your free time wondering if your application has leaked memory or hit your bare-metal limits. Serverless applications also require much less time to set up and manage than other self-scaling solutions exist.

### Low costs

**You only pay for the resources you use and when you use them**. Yes, on paper, serverless solutions are more expensive. However, there are no costs for idle servers and you can calculate how much you can save on DevOps. The entry price for infrastructure also starts very low, unlike legacy solutions.where the initial costs are usually much higher. Additionally, if you have a well-set business model, your bills rise slowly with your earnings. The pricing model is mostly pay-as-you-go, which you may be familiar with from mobile operators. Today, you can even pre-pay for some services and thus save on additional costs. This model is ideal for cases where you cannot predict the load your application will face.

### Speed up development

One of the other advantages that serverless technology brings is the acceleration of the development cycle. **Without having to deal with server and infrastructure management, you only need to learn basic serverless principles and that’s it.** Instead of dealing with additional server infrastructure, you set up and connect other services from the ecosystem, or create them yourself. But be careful, if you make it too complicated, you will end up where you were before.

<h2 id="power-of-serverless">The power of serverless technologies</h2>

In this series of articles, I would like to **share my experience with developing applications that take advantage of the power and flexibility of serverless technologies.** I’ve selected a set of common features inherent to a wide array of online applications into the following diagram. This diagram will serve as our foundation, where I'll walk you through one application component in each part to reveal the process of building serverless applications.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/Image_1_Servereless_Infrastructure_6988d4e708.png" alt="serverless architecture diagram" width="100%"></p>

We will divide this diagram into several application components that we will work with:

<p style="margin-left:15px">
-   <a href="https://www.stormit.cloud/blog/amazon-cognito-secure-login/" target="_blank">User authentication and proper security of user private data and identity.</a>
-   API interface used for communication between the frontend application and your backend services. In this case, there is one API for communicating with the front-end and another for receiving events from third-party services.
-   Data storage and distribution so your data can travel quickly and securely all over the world.
-   <a href="https://www.stormit.cloud/aws-lambda/" target="_blank">Serverless computing</a>, the engine of every piece of the application.
-   Fast and scalable database for application data in a serverless environment.
-   Processing background tasks such as sending emails or running cron jobs.
</p>

And as a bonus, I cannot forget to mention the management and deployment of the entire serverless environment by using irreplaceable IaC tools such as <a href="https://aws.amazon.com/cdk/" target="_blank">CDK</a>, <a href="https://www.serverless.com/" target="_blank">Serverless Framework</a> and <a href="https://www.terraform.io/" target="_blank">Terraform</a>. Those of you who have been in this sector for many years know what an invaluable tool it is in the field of DevOps.

## Thank you, Serverless!

Serverless technologies open up new possibilities for application development, **allowing developers to focus on innovation while the cloud automates the hassles of infrastructure management.** With our upcoming series of articles, we will guide you through the basics of the world of serverless technologies in AWS so that you can start using them to their full potential.

Explore the power of serverless computing. Discover how developers benefit from eliminating the hassle of server management. 

Serverless Series: Introduction to Serverless Technologies

large_serverless-intro-cover.JPG

medium_serverless-intro-cover.JPG

small_serverless-intro-cover.JPG

thumbnail_serverless-intro-cover.JPG

serverless-intro-cover.JPG

In this article, you will learn:

-   [**What is a DDoS attack and other general information about it**](#what-is-a-ddos)
-   [**StormIT solutions for a DDoS attack mitigation**](#stormit-solutions-for-ddos)
-   [**How to prevent DDoS attacks in general**](#general-ddos-attacks-mitigation)
-   [**DDoS mitigation in Amazon Web Services (AWS)**](#aws-ddos-mitigation)
-   [**How to counter DDoS attacks in the cloud with third-party solutions from AWS Marketplace**](#ddos-mitigation-on-aws-marketplace)

Before answering your question about how to protect against DDoS, you should understand what a DDoS attack is and what types of such attacks exist.

<h2 id="what-is-a-ddos">What is a DDoS (Distributed Denial-of-Service) attack?</h2>

It’s an **attempt to flood a network, system, or application** with more traffic, connections, or requests than it can handle. This can have disastrous effects for businesses and other types of organizations, such as governments.

For major websites and applications, even a **few seconds of downtime can result in a significant loss of revenue** and a disruption of services. DDoS is a non-intrusive attack which means the attacker doesn’t need admin access to your site or application to run it and this traffic can look normal at first.

A **DDoS attack is launched from numerous compromised devices** and also from several different networks, often distributed over the world in what is called a botnet. A botnet refers to a group of computers that have been infected by malicious software (malware). This is the main distinction from the Denial of Service (DoS) attack, which uses a single device (one network).

### Why do DDoS attacks exist?

DDoS attacks **can be launched for various reasons ranging from activism to state-sponsored disruption, with many attacks being carried out simply for profit**. Hiring services online for DDoS attacks is relatively inexpensive, especially in relation to the amount of damage they can cause.

### Why is DDoS a problem and what does it impact?

<p style="margin-left:15px">
-   **Availability of your applications or websites**: Attacks can last for hours or even days and block your users from normal usage of your applications.
-   **The financial impact on your business:** Lost revenue, increased expenses on IT infrastructure provisioning.
-   **Security of your data:** DDoS attacks can lead to data losses.
-   **The reputation of your applications:** The name of your brand takes damage and loses credibility.
</p>

### What are the common types of DDoS attacks?

DDoS attacks can be mainly divided by which layer of the <a href="https://en.wikipedia.org/wiki/OSI_model" target="_blank">OSI</a>
 model they attack.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/7_D_Do_S_attack_mitigation_6_51e26e9d84.png" alt="common types of DDoS attacks" width="100%"></p>

<p style="margin-left:15px">
-   **Application-Layer Attacks (layer 7) - HTTP floods, DNS query floods**: Composed of requests (HTTP GETs and DNS queries are popular) that are designed to consume application resources (memory, CPU, bandwidth). An example is an **attacker who continuously uses a website functionality** (submitting a contact form or any API requests) where he knows that it causes database and application processing so that the underlying web service is busy with malicious requests and can’t deliver to other users anymore. The main difficulty when trying to mitigate an Application**-**Layer attack is distinguishing between normal and malicious traffic.
-   **State-Exhaustion Attacks (layer 4) - SYN Flood:** Consume the TCP connection state tables present in many network infrastructure and security devices, including routers, firewalls, and load-balancers, as well as the application servers themselves. The **attacker quickly initiates a connection to a server without finalizing the connection**. These attacks can block access for legitimate users or make security devices inoperative, sometimes even leaving defenses wide-open to data exfiltration. This type of a DDoS attack was used in the <a href="https://en.wikipedia.org/wiki/2016_Dyn_cyberattack" target="_blank">DYN attack</a> in 2016 which resulted in major websites like Amazon, Twitter, Github, and others becoming unavailable.
-   **Volumetric Attacks (layer 3):** Also referred to as Network floods, and includes UDP floods (UDP reflection attacks) and ICMP floods. This type of attack occurs when a network is overwhelmed by a large amount of malicious traffic, causing your applications or services to become unavailable to users. Typically, this type of attack is described in 100s of Gbps, but some of the recent attacks have scaled to over 1Tbps.
</p>

<h2 id="stormit-solutions-for-ddos">StormIT solutions for a DDoS attack mitigation</h2>

When you become a StormIT customer, our experts become an extension of your team, designing and supporting a secure AWS infrastructure for your needs.

We offer AWS Edge Services (Amazon CloudFront, AWS WAF, Amazon Route 53 and AWS Shield) in our special bundles, so you can leverage DDoS protection and overall security for your applications.

The pricing of these bundles is mainly based on your monthly data transfer and we provide special pricing for organizations transferring as little as 1 TB of data per month.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/7_D_Do_S_attack_mitigation_7_2cf149b498.png" alt="ddos attack mitigation" width="100%"></p>

<p style="text-align:center">**You can read more about our offers here:**</p>
<a href="https://www.stormit.cloud/cdn-security/" class="blog-post__buttons" target="_blank">CDN Security</a>

<h2 id="general-ddos-attacks-mitigation">Approaches to DDoS attacks mitigation in general</h2>

At this point, you should understand that there is no easy way to avoid a DDoS attack, but there are some techniques to mitigate against such attacks:

<p style="margin-left:15px">
-   Continuous **monitoring of capacity** (system CPU load, inbound traffic load etc.), traffic type, and any critical infrastructure and service (e.g. firewalls etc.).
-   **Segmentation of internal to external networks** and of any network containing critical systems.
-   Use cloud-based hosting from a major cloud service provider with high bandwidth and CDN (content delivery network) that cache websites or application data. If you use a <a href="https://www.stormit.cloud/blog/what-is-cdn/" target="_blank">Content Delivery Network</a>, avoid disclosing the IP address of the origin web server, and use a firewall to ensure that only the CDN service can access this web server.
-   Implement **monitoring of availability with real-time alerts** to detect DDoS attacks and measure their impact.
</p>

### Some more specific techniques on how to mitigate DDoS attacks:

<p style="margin-left:15px">
-   **Plan scale of your infrastructure thoroughly:** the majority of DDoS attacks are based on large volume and trying to exhaust the capacity of your resources (bandwidth, server). For bandwidth make sure your hosting provider provides reliable internet connectivity that allows you to handle large volumes of traffic. For servers, it’s important that you can **quickly scale up or down on your computation resources** or that you have enough resources from the start. It is also a good idea to use load balancers to shift loads between servers to prevent overloading one of the servers.
-   **Reduce surface area of your network:** Create minimized “surface” area that can be attacked and build protections in a single place. Your application or resources should **block any communication from any ports, protocols or applications from unexpected sources.** You can use firewalls or <a href="https://en.wikipedia.org/wiki/Access-control_list" target="_blank">Access Control Lists</a> (ACLs) to control what traffic reaches your applications. You can also place your resources behind Content Delivery Network (CDN) or <a href="https://aws.amazon.com/elasticloadbalancing" target="_blank">load balancer</a>.
</p>

<p style="text-align:center">**Do you have any questions regarding DDoS protection of your application or infrastructure? Contact us and get a free consultation.**</p>
<a href="https://www.stormit.cloud/contact/" class="blog-post__buttons" target="_blank">Contact Us</a>

<h2 id="aws-ddos-mitigation">Amazon Web Services (AWS) Cloud DDoS mitigation</h2>

### Two ways to use AWS services for DDoS attacks mitigation:

-   **You already use AWS services (EC2, S3, RDS, etc..)** and want to know more about services they offer for DDoS mitigation.
-   **You have some other solution (on-premises, other cloud service provider)** and want to know more about how to mitigate DDoS attacks by using AWS services. A simple example of using AWS services for mitigation of DDoS with a server outside of AWS is a situation where, for example, for regulatory reasons you are not able to migrate your data or whole application to AWS servers, but you can leverage AWS infrastructure for DDoS attacks mitigation. This can be achieved by using AWS services that operate from edge locations.

### AWS services for DDoS mitigation

First, it’s good to see some architecture examples to help you understand the best way to mitigate and **protect your application against possible DDoS attacks.**

This reference architecture includes several **AWS Edge Services that can help you improve your web application’s resiliency against DDoS attacks**, but also secure your application and infrastructure in other ways. This architecture is intended **for those who use only AWS services.**

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/7_D_Do_S_attack_mitigation_5_4bfbcc632d.png" alt="cloud ddos protection, example of architecture" width="100%"></p>

And here is an example of an architecture **for those who use servers outside of AWS Cloud**.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/7_D_Do_S_attack_mitigation_2_96aaf45996.png" alt="cloud ddos protection, example of architecture, servers outside of AWS Cloud." width="100%"></p>

#### AWS Shield – service for the protection of 3 and 4 layer

At this point, it's clear that DDoS attacks are not going away. In fact, they're getting more powerful: <a href="https://aws-shield-tlr.s3.amazonaws.com/2020-Q1_AWS_Shield_TLR.pdf" target="_blank">AWS Shield Service mitigated a 2.3 terabit per second attack</a> in February 2020.

<a href="https://www.stormit.cloud/blog/what-is-aws-shield-how-does-it-work/" target="_blank">AWS Shield</a>
and <a href="https://www.stormit.cloud/aws-web-application-firewall/" target="_blank">AWS WAF</a> works well with Elastic Load Balancing, <a href="https://www.stormit.cloud/cloudfront/" target="_blank">CloudFront CDN</a>, and Amazon Route 53 DNS and protects your infrastructure from DDoS attacks of many types, shapes, and sizes.

##### There are two tiers of service:

**AWS Shield Standard** is available at no extra cost. It protects you from 96% of the most common attacks on **3 and 4 layers**. This protection is applied automatically and transparently to your Elastic Load Balancers, Amazon CloudFront distributions, and AWS Route 53.

**Benefits of AWS Shield Standard:**

-   **DDoS protection:** AWS Shield Standard inspects incoming traffic to your network and applies a combination of traffic signatures, anomaly algorithms, and other analysis techniques to detect malicious traffic. It sets some static thresholds for each of your resource types, but does not provide any custom protections.
-   **Visibility of attacks:** You are provided with general information about DDoS attacks on the AWS network. You can find this information in the AWS Management Console in the Global threat dashboard.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/7_D_Do_S_attack_mitigation_4_e3e1c14655.png" alt="AWS Shield Standard" width="90%"></p>

**AWS Shield Advanced.** This paid service provides additional DDoS mitigation capability, intelligent attack detection, and mitigation against attacks at the application (AWS WAF included) and network layers. Price starts at \$3000 per month.

**Benefits of AWS Shield Advanced:**

-   **Advanced real-time metrics and reports:** You can always find information about the current status of your DDoS protection and you can also see the real-time report with AWS CloudWatch metrics and attack diagnostics.
-   **Cost protection for scaling:** This helps you against bill spikes after a DDoS attack that can be created by scaling of your infrastructure in reaction to a DDoS attack.
-   **AWS WAF included:** Mitigate complex application-layer attacks (layer 7) by setting up rules proactively in AWS WAF to automatically block bad traffic.
-   You get **24×7 access to our DDoS Response Team (DRT)** for help and custom mitigation techniques during attacks. To contact the DRT you will need the <a href="https://aws.amazon.com/premiumsupport/plans/" target="_blank">Enterprise or Business Support levels</a>


<div class="videoWrapper">
<iframe width="560" height="315" src="https://www.youtube.com/embed/Wr1w3kMuRzs" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

#### AWS WAF – service for the protection of layer 7
AWS Web Application Firewall (WAF) helps against attacks **on** the **application layer 7**, such as SQL injection or cross-site scripting which attempts to abuse a weakness in your application. Due to the specific nature of these attacks, with AWS WAF you can easily create customized rules against malicious requests which could have characteristics like being disguised as good traffic or coming from bad IPs, unexpected geographies, etc.

As for other AWS services **you pay only for what you use based on how many rules you deploy** and how many web requests your web application receives, but you can look at our offer and get AWS WAF in one of our [StormIT bundles](https://www.stormit.cloud/cdn-services/).

You can read more about it in our blog post - [What is a Web Application Firewall (WAF) and Why Use It?](https://www.stormit.cloud/blog/what-is-a-web-application-firewall/) or watch the video below.

<div class="videoWrapper">
<iframe width="560" height="315" src="https://www.youtube.com/embed/W4hg--UYpq0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>
<br>
##### Specific features of AWS WAF:

-   If the number of connections exceeds a threshold, this connection will receive 403 forbidden error responses.
-   With WAF you can blacklist or whitelist requests using geographic restrictions from selected countries.
-   You can block specific IP Addresses.
<br>

#### Amazon CloudFront DDoS protection

CloudFront CDN is one of the Edge Services and can be used as a **“front door” to your applications and infrastructure**, as the primary **attack surface is moved away from critical content, data, code, and infrastructure.** CloudFront DDoS protection is automatic and provided by AWS Shield Standard but can be also used with AWS WAF or Shield Advanced.

<div class="videoWrapper">
<iframe width="560" height="315" src="https://www.youtube.com/embed/RakMxEblRrY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

If you want to know more about CloudFront pricing, consider reading [this article](https://www.stormit.cloud/blog/amazon-cloudfront-pricing-how-to-approach-it-and-save-money/).
<br>

#### Amazon Route 53 DNS
<a href="https://www.stormit.cloud/blog/amazon-route-53/" target="_blank">Route 53</a> is a highly available and scalable cloud Domain Name System (DNS) AWS service. It is one of the Edge Services designed to give developers and businesses a reliable and cost-effective way to route end users to Internet applications. Route 53 is automatically protected by Shield Standard but can be also used with AWS WAF or Shield Advanced. <br>

<div class="videoWrapper">
<iframe width="560" height="315" src="https://www.youtube.com/embed/P1pSZIzf4Rg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>
<br>

#### Amazon Elastic Load Balancing and AWS Auto Scaling

This is useful for those who use AWS resources as the origin for their applications. These two services can be used together to **protect your resources and your infrastructure against traffic spikes** because they can automatically scale-up and down the application infrastructure if needed.

**Amazon Elastic Load Balancing** distributes traffic automatically across multiple resources, such as EC2, DynamoDB tables, and Amazon Aurora Replicas.

<a href="https://www.stormit.cloud/blog/aws-auto-scaling/" target="_blank">AWS Auto Scaling</a> monitors your applications and automatically adjusts resource capacity to maintain steady and predictable performance at the lowest possible cost.

<h2 id="ddos-mitigation-on-aws-marketplace">How to get DDoS protection with third-party software solutions on AWS Marketplace?</h2>

There are more than 100 third-party Software as a Service (SaaS) solutions for <a href="https://aws.amazon.com/marketplace/search/results?x=0&y=0&searchTerms=DDoS" target="_blank">DDoS protection on AWS Marketplace</a>, but there are also offerings for Web Application Firewalls (WAFs) and other services. 

If you are thinking about a third-party solution, it is worth looking into these three offerings – <a href="https://aws.amazon.com/marketplace/search/results?page=1&filters=VendorId&VendorId=fb9c6078-b60f-47f6-8622-49d5e1d5aca7&searchTerms=DDoS" target="_blank">Citrix</a>, <a href="https://aws.amazon.com/marketplace/search/results?page=1&filters=VendorId&VendorId=74d946f0-fa54-4d9f-99e8-ff3bd8eb2745&searchTerms=DDoS" target="_blank">F5</a>, <a href="https://aws.amazon.com/marketplace/search/results?page=1&filters=VendorId&VendorId=243a3a4c-e35a-49b0-9061-3f354bb2254e&searchTerms=DDoS" target="_blank">Fortinet</a>.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/7_D_Do_S_attack_mitigation_1_0589bc6370.png" alt="AWS Marketplace" width="100%"></p>




Enhance your defense with essential DDoS attack mitigation techniques on AWS. Discover StormIT's strategies to protect servers effectively. Learn more now.

Cloud DDoS Protection: How to Prevent and Mitigate DDoS

large_ddos-protection.jpg

medium_ddos-protection.jpg

small_ddos-protection.jpg

thumbnail_ddos-protection.jpg

ddos-protection.jpg

Cloud DDoS Protection: How to Mitigate All Risks

In this article, you will learn:

-   **[What is a CDN?](#what-is-a-cdn)**
-   **[Why use a CDN?](#cdn-advantages)**
-   **[CDN pros and cons](#cdn-pros-and-cons)**
-   **[Amazon CloudFront CDN description, location, performance, and pricing](#cloudfront)**

A majority of today’s content on the internet is served from a physical location (server or data center), so the web content must travel to the user from these distinct locations to their computer through the internet. If this user is hundreds of kilometers away from your server, it is possible that your **website will load slowly to them** just because of the latency caused by this distance.

So theoretically if you need to serve your content to every continent and close to your users, you will **need a copy of your content on multiple servers**. This idea is great, but it **could be very expensive** and very complicated to manage.

<h2 id="what-is-a-cdn">What is a Content Delivery Network(CDN)?</h2>

Content Delivery Network (CDN) is a service used to accelerate the whole site delivery and it’s static and dynamic content, large file downloads, and video streaming from your server.

With a CDN this kind of **content can be cached (saved for some time)** in multiple locations at once, on servers all over the world. These locations are known as PoPs (Points of Presence), sometimes also as edge locations and they are **strategically located in populated areas** with the most demand.

When a user requests content from a website served through a CDN server, they are **automatically routed to the PoP**, which is the closest to them and if it is possible, this content is served to them from these caches. If not, it is served from other PoPs closest to the user or the <a href="https://www.stormit.cloud/blog/what-is-an-origin-server/" target="_blank">origin server</a> and then it can be cached for the next user. So the CDN serves the cached content instead of the origin servers doing it over again.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/4_what_is_cdn_cloudfront_3_5f5fb479a8.png" alt="How CDN works, infographics" width="90%"></p>

If the content is served through CDN servers, your users also **benefit from higher availability and reliability**, because a copy of your content is saved on servers around the world. It’s also possible that the majority of all requests will be served by the PoPs and your servers can benefit from less network traffic which improves their overall performance. This was a basic Content Delivery Network definition. But in today’s world, a **CDN provides much more functionality** like DDoS protection, an additional layer of security to your servers, traffic management, and more.

<p style="margin-left:15px;margin-right:15px; background-color:#f8f9f9; border-width:1px;border-style:solid;border-color:#b82e2f;padding:8px;">
**CDN meaning**<br>
_A content delivery network (CDN) is a network of caching servers (edge servers/PoPs) that serve digital content from locations that are geographically closest to visitors._<br>
</p>

<p style="margin-left:15px;margin-right:15px; background-color:#f8f9f9; border-width:1px;border-style:solid;border-color:#b82e2f;padding:8px;">
**CDN server, Edge location, Point of Presence(PoP) meaning**<br>
_These locations contain many caching servers that reduce the distance data must travel. Many of these data centers are strategically located for increased connectivity with nearby users and some CDNs can have multiple layers of these caching servers._
</p>

<h2 id="cdn-advantages">The advantages of a CDN and why should you use it</h2>

The main reason why businesses should consider a CDN is that the **content will be distributed to their users from the nearest location possible**, which in the end will lower the latency. And why is this so important? People will always look for ways to be somewhere faster, to avoid traffic jams or waiting in line, even if they gain only a couple of extra seconds of time. If you have a choice, you will choose the fastest route possible.

### And how much does speed actually matter in terms of website loading?

-   **One in four people will leave a webpage that takes more than 4 seconds to load**
-   **One in two people will leave a mobile site that takes longer than 10 seconds to load**
-   **Three in five won’t return to that site**
-   **46% of users won’t return to a poorly performing website**

### CDN is key to a fast and responsive site

It is key to have a fast and responsive site if you want to be successful in SEO (search engine optimization). Search engines like Google and others will give your site a score, also based on the performance of the website.

### Lower your cost for data transfer out

The second reason and **advantage of a Content Delivery Network** to take into consideration is that it will <a href="https://www.stormit.cloud/blog/aws-data-transfer-pricing-how-to-reduce-costs/" target="_blank">lower your cost for data transfer</a> from your origin server because the most desired content will be cached in PoPs and your origin server doesn’t have to serve as many requests as it would normally do.

### Cases when it may make less sense to implement a CDN

-   **Your website or application gets low traffic:** If you have a few users or customers, caching won’t really work. When you don’t have enough visitors, your content will not be cached, because it looks like that nobody needs it.
-   **Your customers or users are always from the same geographic location:** If you are running a website or application for a local user or a customer, you don’t need to cache your files all over the world.

<h2 id="cdn-pros-and-cons">What are the pros and cons of a CDN?</h2>

It’s useful to know a couple of pros and cons of a Content Delivery Network(CDN).

### General CDN benefits:

-   **Reliability, high availability, and better performance:** This is one of the main benefits of CDN usage. Data that should be accessible to your users at any time are replicated on multiple servers, so if your origin is unavailable, PoPs can easily manage that for you. You can also redirect users to other origin servers if one of them is not responding.
-   **Scalable service:** Protects your origin server from traffic spikes and it is easily and automatically scalable to your needs.
-   **Security:** Adds another layer of security to your origin and you are easily able to withstand DDoS attacks with specific functions. Protect not only your content but also your infrastructure behind it.

### CDN advantages for specific use cases:

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/4_what_is_cdn_cloudfront_2_909ce3425e.png" alt="CDN Benefits, infographics" width="100%"></p>

- **<a href="https://www.stormit.cloud/website-app-acceleration/" target="_blank">Websites and applications</a>:** Leverage low latency, high availability, and security.
- **<a href="https://www.stormit.cloud/gaming-cdn/" target="_blank">Gaming</a>:** Responsiveness, low latency, and reliability are what gamers look for. This is something that can be achieved by using a CDN.
-   **E-commerce:** A CDN helps to deliver the content of your e-commerce site faster and more efficiently.
-   **<a href="https://www.stormit.cloud/video-streaming-cdn/" target="_blank">Video streaming</a>:** A CDN minimizes buffering and delays and it’s the most reliable way to get your content in front of numerous viewers anywhere in the world.

### Possible cons and disadvantages to using a CDN:

Implementing a CDN comes with a lot of benefits and advantages to businesses, from improved performance to better security. But the CDN market is competitive and as in any other business, here is also important to choose a reliable partner for your project. **A CDN provider with a proven track record** for your use case, solid infrastructure, and accessible support. **If stability and reliability are what you are after, it is best to avoid free CDN services**, since any potential saving benefits will be outweighed by considerable disadvantages.

Some of those to look out for are:

-   **Location of edge servers:** If most of your users are located in a country where the CDN has no servers, the data on your website may have to travel further than without using any CDN. It’s best to do some research to find out where all the servers of the CDN provider are located and if your users are close to their servers.
-   **Support availability:** The question of the quality of the technical support arises when you have someone else responsible for running the CDN service. In case of a technical issue, even if rare, you should know how long it takes for the specialist to fix the problem and if there is enough capacity from their side to check the issue immediately or in very little time.
-   **Network filters and block access:** It is not uncommon for some countries or organizations to block entire domains or IP addresses of popular free CDN services. Often these types of regulations are connected to geographical, political, and commercial boundaries in the real world. It’s always good to look for CDN Services which have enough resources and can watch for such regulations.

<p style="text-align:center">
**Wanna find out how can a CDN help your particular project?**</p>
<a href="https://www.stormit.cloud/contact/" class="blog-post__buttons" target="_blank">Talk to a cdn specialist</a>

<h2 id="cloudfront">Amazon CloudFront CDN</h2>

**Amazon is offering its own CDN service called <a href="https://www.stormit.cloud/cloudfront/" target="_blank">CloudFront</a>**. Businesses can leverage multiple benefits of using a CDN from Amazon. It speeds up the distribution of static and <a href="https://www.stormit.cloud/blog/cloudfront-distribution-for-amazon-ec2-alb/" target="_blank">dynamic content</a> and it has some unique functionality for video streaming. It offers a lot of features and it can be easily managed via the AWS management console. CloudFront is tightly integrated with other AWS services, like Elastic Load Balancer, EC2, S3, etc.

<div class="videoWrapper">
<iframe width="560" height="315" src="https://www.youtube.com/embed/RakMxEblRrY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

Every modern website is often built using **static and dynamic content**. Static content includes text, images, style sheets, and other objects. Dynamic content includes components of the website that are personalized to each viewer. **CloudFront is designed for both.**

**If you want to know how to set up a CloudFront distribution for static website hosting, try reading our blog post:** <a href="https://www.stormit.cloud/blog/setup-an-amazon-cloudfront-distribution-with-ssl-custom-domain-and-s3/" target="_blank">Set up an Amazon CloudFront distribution with SSL and S3</a>

To deliver content to users, **CloudFront leverages a distributed network of PoPs** around the world. These PoPs or Edge locations consist of data centers specifically built to deliver content to your users. In addition to these Edge locations, Amazon has built bigger Regional CloudFront caches. These can save much more content than normal Edge caches. At this time **there are more than 400 edge locations and more than 13 regional caches** strategically located around the world.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/4_what_is_cdn_cloudfront_1_cc23a0af6f.png" alt="network of PoPs around the world" width="100%"></p>

### Security

Security of a CloudFront distribution is associated with its ability to connect to multiple AWS services such as <a href="https://www.stormit.cloud/blog/what-is-aws-shield-how-does-it-work/" target="_blank">AWS Shield</a>, <a href="https://www.stormit.cloud/aws-web-application-firewall/" target="_blank">AWS Web Application Firewall (AWS WAF)</a>, and <a href="https://www.stormit.cloud/blog/amazon-route-53/" target="_blank">Amazon Route 53</a> and to run smoothly with them to create multiple layers of security to withstand DDoS attacks and other possible threats. With Amazon CloudFront as an entry point to your network, you move possible attacks to its level and protect your underlying IT infrastructure.

You can also **easily set up SSL and TLS** for delivery of your content via HTTPS and use integrated services such as AWS Certificate Manager (ACM) to handle your certificates, or you can use your own.

Amazon CloudFront will also provide you with some **specific functions to restrict access to your website**. For example geo-restriction, so you can choose from which countries people connect to your website.

If you need to be **compliant with standards like PCI-DSS Level 1, HIPAA, and ISO 9001, ISO 27001, SOC (1, 2, and 3)**, because you handle sensitive data, CloudFront has got you covered.

### Availability

By using Amazon **CloudFront’s extensive network of PoPs** around the world your content can be saved in caches and distributed to your users during traffic spikes. This lowers the load on the origin servers and they are only used in times when really needed. This brings a higher availability to your users.

With CloudFront you can set up multiple origin servers for your content distribution and also an automatic failover, should your main server go offline.

### Performance

Amazon CloudFront always finds the **fastest way to deliver your content** by constantly measuring the speed of transfer through multiple routes to ensure that each request reaches your server as quickly as possible. For communication with other AWS services, **Amazon CloudFront uses AWS Backbone network** (Amazon’s custom-built network with the highest standards), which enables the effective transfer of data between Edge Locations and services like EC2, S3, etc. One of the main metrics of successful CDN is the <a href="https://www.stormit.cloud/blog/cache-hit-ratio-what-is-it/" target="_blank">Cache hit ratio</a> and <a href="https://www.stormit.cloud/blog/what-is-round-trip-time-rtt-meaning-calculation/" target="_blank">Round-trip time</a>.

### Pricing and cost-effectivity

Like with any other service from AWS, you only pay for what you use with pay-as-you-go pricing. There is no commitment and no minimum fee. There is also the **Free-Tier with 1TB (1000GB) of Data Transfer Out and 10 000 000 free requests via HTTP or HTTPS each month**. In general, you do not pay for transfers between AWS services and Amazon CloudFront. The overall cost depends on multiple factors such as Data Transfer Out, Number of HTTP/HTTPS requests, Invalidation, Field Level Encryption, or Log requests.

Read more about <a href="https://www.stormit.cloud/blog/amazon-cloudfront-pricing-how-to-approach-it-and-save-money/" target="_blank">CloudFront pricing</a>.


What is a CDN? What are the CDN benefits your business should consider? What are the pros and cons of using a Content Delivery Network?

What is a CDN? Uncover how it transforms website speed and security for the better. Get insights on boosting your online presence with StormIT.

What Is a CDN: Definition, Core Benefits & Use Cases | StormIT

large_what-is-a-cdn.jpg

medium_what-is-a-cdn.jpg

small_what-is-a-cdn.jpg

thumbnail_what-is-a-cdn.jpg

what-is-a-cdn.jpg

What Is a CDN: Definition, Core Benefits & Use Cases

In this article, you will learn:

-   [**What is AWS Shield?**](#what-is-aws-shield)
-   [**What is the difference between AWS WAF and AWS Shield?**](#aws-waf-vs-aws-shield)
-   [**The benefits of using AWS Shield DDoS protection**](#benefits-aws-shield)
-   [**How does AWS Shield work?** ](#how-aws-shield-work)
-   [**What does AWS Shield protect against?**](#what-shield-protect-against)
-   [**AWS Shield pricing**](#aws-shield-pricing)
-   [**How to test AWS Shield protection?**](#test-aws-shield)
-   [**StormIT CDN security solution with AWS Shield**](#stormit-solution-with-shield)

The first known Distributed Denial of Service (DDoS) attack occurred in 1996, targeting Panix, the oldest Internet Service Provider (ISP) in New York. Their network was flooded by SYN and was offline for several days. In the subsequent years, DDoS attacks have become common. [Cisco predicts](https://www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.html) that the **total number of DDoS attacks will double from 7,9 million in 2018 to more than 15,4 million by 2023.**

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/14_AWS_shield_4_0fe68d77c2.png" alt="number of DDoS attacks graph" width="90%"></p>

So how can you protect your websites and applications against these attacks? There are multiple types of DDoS attacks and in this article, you will read about the cloud-based service AWS Shield that mainly protects against DDoS attacks on layers 3 and 4r of the OSI model. You can read more about general [DDoS attack mitigation](https://www.stormit.cloud/blog/cloud-ddos-protection-how-to-mitigate-all-risks/) in our blog post.

<h2 id="what-is-aws-shield">What is AWS Shield?</h2>

AWS Shield is a managed AWS Cloud service for DDoS protection against all known infrastructure (layer 3 and 4) attacks.

AWS Shield is available at **two different tiers, AWS Shield Standard and AWS Shield Advanced**, and AWS Shield Advanced has a lot more power and protection on offer than the Standard version.

<div class="videoWrapper">
<iframe width="560" height="315" src="https://www.youtube.com/embed/Wr1w3kMuRzs" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

### AWS Shield Standard

AWS Shield Standard is free, and it offers DDoS protection against some of the more common layer 3, the network layer, and layer 4, the transport layer, DDoS attacks. This protection is **applied automatically** and transparently to your **Elastic Load Balancers, Amazon CloudFront distributions, and Amazon Route 53.**

<p style="text-align:center">**AWS Shield Standard is also available in the StormIT** [**CDN security**](https://www.stormit.cloud/cdn-security/) **solution.**</p>

### AWS Shield Advanced

This paid service provides additional DDoS mitigation capability, intelligent attack detection, and mitigation against attacks at the application (AWS WAF included) and network layers.

Shield Advanced also provides additional detection and mitigation against large and sophisticated DDoS attacks and near real-time visibility into attacks.

<h2 id="aws-waf-vs-aws-shield">What is the difference between AWS WAF and AWS Shield?</h2>

These two services are included in the AWS Edge Services ecosystem and provide DDoS protection. The difference between them is that **AWS WAF** <a href="https://www.stormit.cloud/blog/what-is-a-web-application-firewall/" target="_blank">(Web Application Firewall)</a> **provides protection on the application layer** and **AWS Shield protects the infrastructure layers** of the OSI model.

You will find more information about AWS Shield vs AWS WAF in the table below.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/14_AWS_shield_2_73de4f1d16.png" alt="AWS WAF vs. AWS Shield" width="85%"></p>

**AWS WAF is included in AWS Shield Advanced subscription**, so basically, AWS Shield is not a WAF(web application firewall), but if you use the Advanced subscription, you will get a WAF for free.

<h2 id="benefits-aws-shield">Benefits of using AWS Shield DDoS protection</h2>

There are some general benefits of using AWS Shield for the protection of AWS Cloud resources, but also the protection of third-party solutions (on-premises or other cloud providers):

<p style="margin-left:15px">
-   **Easy to use:** Like most AWS services, AWS Shield is an easy-to-use service designed to allow you to protect your applications quickly and easily. AWS Shield can be used for existing applications or new applications using the AWS Management Console. **No routing changes are required for enabling these protections.**
-   **Cost-efficient:** AWS Shield Standard is automatically enabled for all AWS customers at no additional cost. With AWS Shield Advanced, customers get AWS WAF and AWS Firewall Manager at no additional cost.
</p>

### Benefits of AWS Shield Standard:

<p style="margin-left:15px">
-   **Traffic monitoring:** AWS Shield Standard inspects incoming traffic to your network and applies a combination of traffic signatures, anomaly algorithms, and other analysis techniques to detect malicious traffic. It sets some static thresholds for each of your resource types, but does not provide any custom protections.
-   **DDoS mitigation:** Over 99% of infrastructure layer attacks detected by AWS Shield Standard are automatically mitigated in less than one second.
-   **Global threat dashboard:** You are provided with general information about DDoS attacks on the AWS network. You can find this information in the AWS Management Console in the global threat dashboard.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/14_AWS_shield_3_31b16864e8.png" alt="Global threat dashboard" width="100%"></p>
</p>

### Benefits of AWS Shield Advanced
<p style="margin-left:15px">
-   **Advanced real-time metrics and reports:** You can always find information about the current status of your DDoS protection and you can also see the real-time report with AWS CloudWatch metrics and attack diagnostics.
-   **Cost protection for scaling:** This helps you against bill spikes after a DDoS attack that can be created by scaling of your infrastructure in reaction to a DDoS attack.
-   **AWS WAF included:** Mitigate complex application-layer attacks (layer 7) by setting up rules proactively in AWS WAF to automatically block bad traffic.
-   **You get 24×7 access to our DDoS Response Team (DRT)** for help and custom mitigation techniques during attacks. To contact the DRT you will need the Enterprise or Business Support levels.
</p>

<h2 id="how-aws-shield-work>How does AWS Shield work?</h2>

A DDoS attack is made in an attempt to make an online service such as a website or web service unavailable by overwhelming it with malicious traffic. This is where AWS Shield comes in.

**Amazon Route 53, Elastic Load Balancer and Amazon CloudFront** DDoS protection is automatically provided by AWS Shield Standard, at no additional charge. 

To start using **AWS Shield Advanced** you will need to go through some basic steps. At the start, you will subscribe to AWS Shield Advanced and then choose which resources it will protect.

You can add **Advanced Shield** protection for any of the **following resource types:**

<p style="margin-left:15px">
-   [Amazon CloudFront](https://www.stormit.cloud/cdn-services/) distribution
-   [Amazon Route 53](https://www.stormit.cloud/blog/amazon-route-53/) hosted zone
-   AWS Global Accelerator
-   Elastic Load Balancer(ELB)
-   Amazon Elastic Compute Cloud (Amazon EC2) Elastic IP addresses
</p>

Shield Advanced protects only the resources that you specify. It’s best to read more about Shield Advanced in the [AWS tutorial](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-ddos.html) that describes how to get started with it.

As a general countermeasure against DDoS attacks, AWS's infrastructure is designed to be DDoS resilient and equipped with a DDoS mitigation system that can automatically detect and filter excess traffic 24/7.

<h2 id="what-shield-protect-against">What does AWS Shield protect against?</h2>

**AWS Shield Standard protects** your applications and websites against these types of DDoS attacks:

-   **State-Exhaustion Attacks (layer 4) - SYN Flood:** Consumes the TCP connection state tables present in many network infrastructure and security devices, as well as the application servers themselves. The attacker quickly initiates a connection to a server without finalizing the connection. These attacks can block access for legitimate users, sometimes even leaving defenses wide-open to data exfiltration.
-   **Volumetric Attacks (layer 3):** Also referred to as network floods, and includes UDP floods (UDP reflection attacks) and ICMP floods. This type of attack occurs when a network is **overwhelmed by a large amount of malicious traffic**, causing your applications or services to become unavailable to users.

**AWS Shield Advanced** protects your apps against the same attacks as Standard version with some specific function, but because it also includes AWS WAF, it protects against:

-   **Application-Layer Attacks (layer 7) - HTTP floods, DNS query floods**: Composed of requests (HTTP GETs and DNS queries are popular) that are designed to consume application resources. An example is an attacker who continuously uses a website functionality (submitting a contact form or any API requests) where he knows that it causes database and application processing.
-   **Other Application-Layer Attacks:** [SQL injection](https://en.wikipedia.org/wiki/SQL_injection) (SQLi), [Cross-site scripting](https://en.wikipedia.org/wiki/Cross-site_scripting) (XSS), [Remote file inclusion](https://en.wikipedia.org/wiki/File_inclusion_vulnerability) (RFI) and more web application attacks and threats from the OWASP Top 10 publication.

<h2 id="use-aws-shield-outside-of-aws">Can you use AWS Shield to protect applications or websites not hosted in AWS?</h2>

Yes, it is possible to use AWS Shield and other AWS Edge services (Amazon Route 53, Amazon CloudFront, and AWS WAF) with custom origins because you can set any public domain or IP as the origin in the CloudFront distribution setup or in Route 53. Learn more about our CDN solution in the last section of this article.

<h2 id="aws-shield-pricing">AWS Shield pricing</h2>

There is no charge for inbound data transfer on AWS and you do not pay for DDoS attack traffic that is mitigated by AWS Shield.

The table below describes the main difference between the pricing of Shield Standard and Shield Advanced.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/14_AWS_shield_5_18aeae5a2a.png" alt="AWS Shield pricing" width="85%"></p>

### AWS Shield Standard

AWS Shield Standard is built into the AWS services that you can use for your web applications. There are **no additional costs for AWS Shield Standard**.

### AWS Shield Advanced

AWS Shield Advanced is a paid service that provides additional protections for internet-facing applications. You will pay \$3000 per organization subscribed to AWS Shield Advanced with a subscription commitment of at least one year. If your organization has <a href="https://www.stormit.cloud/blog/aws-organizations-how-to-manage-multiple-aws-accounts/" target="_blank">multiple AWS accounts</a>, you will pay the monthly fee once.

#### Data Transfer Out Usage Fees (per GB) for AWS Shield Advanced

In addition to standard fees on Elastic Load Balancing (ELB), Amazon CloudFront, Amazon Route 53, AWS Global Accelerator, and Amazon Elastic Compute (EC2) you will have to pay **fees per GB of DTO from these services** when you choose to protect them with Shield Advanced.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/14_AWS_shield_1_b68f708367.png" alt="AWS Shield Advanced pricing" width="100%"></p>

#### Pricing example: AWS Shield Advanced protecting Amazon CloudFront distribution

If you enable Shield Advanced protection for your Amazon CloudFront distribution and you block any other possibility of connection to your resources such as EC2 or ELB behind it, you don’t need to protect any other services with Shield Advanced.

At the end of the month, you will pay the AWS Shield Advanced monthly fee of \$3,000. In addition to the monthly fee, you will be charged the AWS Shield Advanced usage-based fee of Data Transfer out at \$0.025 per GB.

<h2 id="test-aws-shield">Testing AWS Shield protection</h2>

**You can test AWS Shield**. The AWS Acceptable Use Policy describes the permitted and prohibited behaviors on AWS, including descriptions of prohibited security violations and network abuse. However, since DDoS simulation testing and other simulation events are often indistinguishable from these activities, AWS has formulated policies that allow their customers to request permission to conduct DDoS testing and vulnerability scanning. Visit the [Penetration testing page](https://aws.amazon.com/security/penetration-testing/) and [DDoS Simulation Testing policy](https://aws.amazon.com/security/ddos-simulation-testing/) for more details.

<h2 id="need-aws-shield-standard-or-advanced">Do you need AWS Shield Standard or Advanced?</h2>

In many cases, **AWS Shield Standard protection is sufficient to meet the needs of SMB businesses**. The StormIT team recommends using a combination of AWS WAF and other AWS services (Amazon CloudFront CDN, Route 53) as a strategy to complement this built-in protection that can often provide adequate attack protection and mitigation.

If your business is a likely target of large DDoS attacks and you need specific control over the whole process, or if you prefer to let AWS handle the majority of DDoS protection and mitigation responsibilities for layer 3, layer 4, and layer 7 attacks, AWS Shield Advanced might be the best choice. AWS Shield Advanced not only provides layer 3 and layer 4 protection and mitigation, but also includes AWS WAF at no extra charge and DRT assistance for layer 7 attacks. If you use AWS WAF and AWS Shield Standard, you must design your own layer 7 protection and mitigation processes.

<h2 id="stormit-solution-with-shield">StormIT CDN security solution with AWS Shield</h2>

StormIT team helps organizations protect their websites and applications against all commonly known attacks and exploits by leveraging the protection of **AWS Edge Services, such as Amazon CloudFront, AWS Shield Standard and AWS Web Application Firewall (AWS WAF)**. These services work seamlessly together to create a flexible, layered security perimeter and Distributed Denial-of-Service (DDoS) attack protection. The pricing of this solution is mainly based on your monthly data transfer. We provide [special pricing](https://www.stormit.cloud/cdn-services/) for organizations transferring as little as 1 TB of data per month.

We can provide this reference architecture to customers that are already using AWS Cloud or customers using third-party cloud solutions, or on-premises data centers.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/7_D_Do_S_attack_mitigation_7_2cf149b498.png" alt="" width="100%"></p>



AWS Shield is an AWS service for DDoS protection against all known infrastructure (layer 3 and 4) attacks. Learn more...

What is AWS Shield and How Does it Work? | StormIT

large_aws-shield.jpg

medium_aws-shield.jpg

small_aws-shield.jpg

thumbnail_aws-shield.jpg

aws-shield.jpg

What is AWS Shield and How Does it Work?

In this article, you will learn:

-   [**What is AWS Auto Scaling?**](#what-is-aws-auto-scaling)
-   [**How does AWS Auto Scaling work?**](#how-aws-auto-scaling-works)
-   [**Getting started with AWS Auto Scaling**](#aws-auto-scaling-getting-started)
-   [**AWS Auto Scaling vs. Amazon EC2 Auto Scaling**](#aws-auto-scaling-vs-ec2-auto-scaling)
-   [**AWS Auto Scaling vs. Elastic Load Balancing**](#aws-auto-scaling-vs-elastic-load-balancing)
-   [**AWS Auto Scaling benefits and disadvantages**](#aws-auto-scaling-benefits)
-   [**AWS Auto Scaling pricing**](#aws-auto-scaling-pricing)

Whether you are growing rapidly or demand is slowing and you need to scale down, AWS Auto Scaling can help. **Manual scaling is time-consuming and costly**, whereas automatic scaling adjusts capacity based on predictable performance and cost, helping you reduce waste and optimize AWS Cloud spend.

To help you better understand **AWS Auto Scaling** and its benefits, this blog post will introduce what AWS Auto Scaling is, how it works, its advantages and disadvantages, and more.

<h2 id="what-is-aws-auto-scaling">What is AWS Auto Scaling?</h2>

AWS Auto Scaling is a service in the AWS Cloud environment which enables you to configure scaling for selected AWS services that are part of your application in minutes. You can be sure that you’ll always have enough resources/instances to handle your application load, no matter how greatly or suddenly traffic may spike.

With AWS Auto Scaling, you can configure and manage the scaling of resources **through scaling plans.** This ensures that you add the computing power you need to handle the load on the application, and then remove it when it is no longer needed.

It’s useful for those who, **for example**, have an application that uses multiple Amazon EC2 instances and Amazon DynamoDB. AWS Auto Scaling can be used to manage resource provisioning for all of the EC2 Auto Scaling groups and DynamoDB tables in one place.

#### At this moment you can use AWS Auto Scaling to scale the following AWS services:

<p style="margin-left:15px">
-   **Amazon Elastic Compute Cloud (EC2) Auto Scaling groups**: Launch or terminate EC2 instances in an Auto Scaling group.
-   **Amazon EC2 Spot Fleet**: Launch or terminate instances from a Spot Fleet request.
-   **Amazon Elastic Container Service (Amazon ECS)**: Adjust the ECS tasks in response to load variations.
-   **Amazon DynamoDB**: Enable a DynamoDB table or a global secondary index to increase or decrease its provisioned capacity.
-   **Amazon Aurora**: Dynamically adjust the number of read replicas.
</p>

<p style="text-align:center">
**AWS Auto Scaling is focused on horizontal scaling** of these services. If you want to know more about horizontal scaling, read our blog post: [Scalability in Cloud Computing: Horizontal vs. Vertical Scaling](https://www.stormit.cloud/blog/scalability-in-cloud-computing-horizontal-vs-vertical-scaling/)
</p>

<h2 id="how-aws-auto-scaling-works">How does AWS Auto Scaling work?</h2>

AWS Auto Scaling scans your AWS Cloud environment and automatically discovers the scalable resources so you don’t have to manually identify them one by one.

You can find scalable resources by **CloudFormation stack, tag, or EC2 Auto Scaling groups**.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/25_AWS_auto_scaling_2_5bf95fa8b2.png" alt="scalable resources" width="100%"></p>

#### Here is a simple diagram of the whole process:

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/25_AWS_auto_scaling_1_b66015c25c.png" alt="How does AWS Auto Scaling work diagram" width="100%"></p>

### Two main components of AWS Auto Scaling are scaling plan and scaling strategy.

**The scaling plan** is the core component of AWS Auto Scaling and you can simply create it in the AWS Console. It's a set of directions for scaling your resources. If you work with AWS CloudFormation or add tags to scalable resources, you can set up scaling plans for different sets of resources.

**The scaling strategy** is within the scaling plan and includes everything that AWS Auto Scaling needs to know to properly scale your application resources. You can optimize for availability, for cost, or a balance of both.

Alternatively, you can also create your **own custom strategy**, per the metrics and thresholds you define. You can set separate strategies for each resource or resource type.

![25_AWS-auto-scaling-3.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/25_AWS_auto_scaling_3_dd4679444c.png)

### When choosing your scaling strategy, you can also choose these two specific features:

#### 1. Dynamic scaling

The number of instances is changed automatically based on information provided by a CloudWatch alarm which adjusts a number of instances in response to live changes in resource utilization(average CPU, network in/out). The intention is to provide enough capacity to maintain utilization at the target value.

**For example**, you can configure your scaling plan to keep the number of tasks that your ECS service runs at 75 percent of CPU. When the CPU utilization of your service rises above 75 percent (meaning that more than 75 percent of the CPU that is reserved for the service is being used), this triggers your scaling policy to add another task to your service to help out with the increased load.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/25_AWS_auto_scaling_4_6e6e774add.png" alt="Dynamic scaling" width="100%"></p>

#### 2. Predictive scaling

With predictive scaling, actions on your instances are based on the predictable traffic patterns of the application. Currently, **only the Amazon EC2 Auto Scaling group supports this feature**.

It works by **analyzing the historical records** of the specified load indicators (CPU utilization, network input/output) for the past 14 days, but you can set it to a **minimum of 24 hours of data**. Then it generates a forecast two days in advance and schedules a scaling action on your EC2 instances to adjust the capacity. The goal of predictive scaling is to make the scaling index as close as possible to the target value.

**For example**, you can enable predictive scaling and configure it to keep the average CPU utilization of your Auto Scaling group at 60 percent. Your forecast calls for traffic spikes to occur every day at 9a.m. Then it creates the future scheduled actions to make sure that your infrastructure is ready to handle that traffic ahead of time.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/25_AWS_auto_scaling_7_0d1902f3f6.png" alt="Predictive scaling" width="100%"></p>

<h2 id="aws-auto-scaling-getting-started">Getting started with AWS Auto Scaling</h2>

There is no exact simple way to enable this service in your AWS environment because it’s very specific to your use case. You can find a good manual for every step in the AWS official documentation: [Getting started with AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/auto-scaling-getting-started.html) or open [AWS Auto Scaling console](https://console.aws.amazon.com/awsautoscaling/), and try to go through the creation of a new AWS Auto Scaling plan.

<p style="text-align:center">
[![25_AWS-auto-scaling-6.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/25_AWS_auto_scaling_6_c60b0cfee0.png)](https://console.aws.amazon.com/awsautoscaling/)
</p>

<h2 id="aws-auto-scaling-comparison">Comparison of AWS Auto Scaling with other AWS services</h2>

<h3 id="aws-auto-scaling-vs-ec2-auto-scaling">AWS Auto Scaling vs. Amazon EC2 Auto Scaling</h3>

Sometimes, understanding the difference between these two AWS services can be confusing, so let's take a closer look at when it is best to use these services.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/25_AWS_auto_scaling_5_2fdb48a942.png" alt="AWS Auto Scaling vs. Amazon EC2 Auto Scaling" width="100%"></p>

The best way to use **AWS Auto Scaling** is to manage multiple resources. It allows you to use scaling policies to define dynamic scaling policies for **multiple EC2 Auto Scaling groups or other services**. Using AWS Auto Scaling to configure scaling for more services at once is much faster than managing the scaling strategy for each resource. If you want to create **predictive scaling for EC2 instances**, you should also use AWS Auto Scaling.

If you only need to scale one or a couple of Amazon EC2 Auto Scaling groups or if you are only interested in maintaining the health of your EC2 instances, use **Amazon EC2 Auto Scaling**. If you need to **set up scheduled or step scaling policies**, you should also use **EC2 Auto Scaling** because AWS Auto Scaling does not support this feature.

<h3 id="aws-auto-scaling-vs-elastic-load-balancing">AWS Auto Scaling vs. Elastic Load Balancing</h3>

**Elastic Load balancing** is the ability to evenly distribute traffic between your instances to ensure that none of these instances are overloaded by the traffic that they're receiving. There are three types of load balancers in AWS Cloud and they can be used to distribute traffic across instances created by AWS Auto Scaling or Amazon EC2 Auto Scaling.

<h2 id="aws-auto-scaling-benefits">AWS Auto Scaling benefits and disadvantages</h2>

### AWS Auto Scaling benefits
<p style="margin-left:15px">
-   **Setup auto scaling of multiple resources** : AWS Auto Scaling lets you set target utilization levels (CPU, Network In/Out) for multiple resources in a single place in the AWS Management Console.
-   **Improved cost management** : You can scale multiple services at once up or down (horizontally) according to the requirements of your organization. This allows you to save on the costs of managing these services.
-   **Reliability** : Automatic scaling is efficient and reliable. It’s also simpler to do in one place, and whenever scaling is initiated, AWS can send you notifications.
</p>

### Disadvantages of AWS Auto Scaling**

There are no major disadvantages to using AWS Auto Scaling, but here are some common things you should understand before implementing it.

<p style="margin-left:15px">
-   **Increase development complexity** : Integrating any type of auto scaling may make deployment and configuration more complicated. You need a separate service to synchronize your code changes.
-   **Regionally limited** : AWS Auto Scaling service **is only effective in one region** and it’s not possible to use it across resources in multiple regions. You’ll have to create AWS Auto Scaling in every region separately. So, if you have a multi-region application, it can be a challenge.
</p>

<h2 id="aws-auto-scaling-pricing>AWS Auto Scaling pricing</h2>

The AWS Auto Scaling service **is free to use**. You only pay for the AWS resources (EC2 instances, DynamoDB tables, etc..) and because the AWS Auto Scaling feature is enabled by Amazon CloudWatch metrics and alarms, you’ll pay the CloudWatch monitoring fees.

## Conclusion

Automatic scaling in AWS is a very broad topic and there are a lot of services that can be scaled automatically in AWS Cloud. The AWS Auto Scaling service helps you to do this in one place for your whole application, with for example EC2 instances, DynamoDB tables, and more.



Unlock the full potential of AWS Auto Scaling: from setup to benefits, learn everything you need for efficient resource management and cost savings.

AWS Auto Scaling: Everything That You Need to Know | StormIT

large_AWS_auto_scaling.jpg

medium_AWS_auto_scaling.jpg

small_AWS_auto_scaling.jpg

thumbnail_AWS_auto_scaling.jpg

AWS_auto_scaling.jpg

AWS Auto Scaling: Everything That You Need to Know

In this article, you will learn:

-   [**What is AWS Organizations?**](#what-is-aws-organizations)
-   [**AWS Organizations components and architecture**](#aws-organizations-components)
-   [**AWS Organizations use cases**](#aws-organizations-use-cases)
-   [**AWS Organizations pricing**](#aws-organizations-pricing)
-   [**AWS Organizations vs AWS IAM**](#aws-organizations-vs-iam)

When your AWS (Amazon Web Services) environment gets to the stage where you need to add new user accounts and manage multiple of them, you will need to find a way to do this in the simplest way possible. **Adding permissions that give these users access to the right resources in the AWS Cloud** is also potentially difficult. This is where AWS Organizations comes in.

In this blog post, we will look at what AWS Organizations is, its components, features and benefits, as well as the main difference between AWS Identity and Access Management (IAM) and AWS Organizations.

<h2 id="what-is-aws-organizations">What is AWS Organizations?</h2>

AWS Organizations is an account management service that allows you to **consolidate multiple AWS accounts into a single** organization that you create and centrally manage. AWS Organizations **includes account management and consolidated billing capabilities** to help you better meet your organization's budget, security and compliance needs.

![41_AWS-organizations-2.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/41_AWS_organizations_2_c9f7d506bc.png)

As an administrator of an organization, you can create and close AWS accounts in the organization and invite existing accounts to join the organization. It also offers a more flexible hierarchy of your AWS accounts and resource groups in the form of organizational units (OUs).

![41_AWS-organizations-1.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/41_AWS_organizations_1_b4895f1b83.png)

AWS Organizations is **a global service with a single endpoint for all AWS Regions**. You don't have to explicitly select a region.

<h2 id="aws-organizations-components">AWS Organizations components and architecture</h2>

For the right understanding of what AWS Organizations can do, it’s best to understand what components and what architecture it provides for your accounts and groups.

Below you can find a simple example of an AWS Organizations hierarchy.

![41_AWS-organizations-3.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/41_AWS_organizations_3_f03b01a41d.png)

**Let’s look at every part of this hierarchy on a more thorough level.**

### Management account

This is the AWS account that you use to create your organization. From the organization's management account, you can do the following:

<p style="margin-left:15px">
-   Create and close accounts in the organization
-   Manage invitations and invite other existing AWS accounts to your organization
-   Remove accounts from the organization
-   Apply policies to entities in your organization (roots, OUs, or accounts)
-   Enable integration with other supported AWS services

</p>

The management account has the responsibilities of a payer account and **is responsible for paying all charges that are accrued by the member accounts**.

### Member Account(s)

**These AWS accounts** make up all of the rest of the accounts in an organization.

A member account can be a member of only one organization at a time.

You can attach a policy to an account to apply controls to only that account.

<p style="margin-left:15px">
-   A New AWS account can be directly added to the organization.
-   Existing AWS accounts can be added (invited) to the organization.
</p>

### Organizational Unit (OU)

<p style="margin-left:15px">
-   An organizational unit is a group of AWS accounts within an organization.
-   An OU can also contain other OUs enabling you to create a hierarchy. This enables them to reflect the company’s structure.
-   One account cannot be added under two different OUs.
</p>

### Service Control Policy (SCP)

<p style="margin-left:15px">
-   [Service Control Policy (SCP)](https://www.stormit.cloud/blog/aws-scp-service-control-policy/) is a document that describes controls to be attached to the entire organization, OUs, or individual AWS accounts.
-   The policy defines the services and actions that users or a role can perform.
-   Policies are inherited through hierarchical connections in an organization.
</p>

## AWS Organizations features

AWS Organizations has two available feature sets:

<p style="margin-left:15px">
-   **Consolidated Billing features:** All organizations support this subset of features, which provides basic billing management tools.
-   **All features:** This feature set is the preferred way to work with AWS Organizations, and it includes Consolidating Billing features. When you create an organization, **enabling all features is the default**.
</p>

### Consolidated Billing

You can use this feature of AWS Organizations to consolidate billing and payment for multiple AWS accounts. Every organization in AWS Organizations has a management account that pays the charges of all the member accounts.

Consolidated billing has the following benefits:

<p style="margin-left:15px">
-   **One bill** – You get one bill for multiple accounts.
-   **Easy tracking** – You can track the charges across multiple accounts and download the combined cost and usage data.
-   **Combined usage** – You can combine the usage across all accounts in the organisation to share the volume pricing discounts, Reserved Instance discounts and Savings Plans.
</p>

An AWS Organization can be upgraded to using all features at any time, but to do so each member account must approve of the change.

### All Features of AWS Organizations

If your organisation has all features enabled, you can access the advanced central governance and management capabilities in AWS Organizations.

AWS Organizations offers the following features:

<p style="margin-left:15px">
-   **Manage multiple AWS accounts:** You can create groups of accounts and then apply policies to those groups and establish boundaries that define the policies, services and resources used by them.
-   **Control access and permissions:** Enforce policies across users based on teams, business divisions and projects.
-   **Share resources:** You can share that service across multiple users, both within and beyond the same AWS organisation.
-   **Use for free:** Activating this feature is free. The accounts are only charged for the AWS services and resources they consume.
</p>

#### Service Control Policy (SCP)

This type of policy determines which services and actions are available to users (or roles) for specified accounts. Note that **SCPs do not grant permissions; they instead act as a filter**. This means that the accounts, users and roles must already have these IAM permissions available.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/41_AWS_organizations_4_1c40e0601d.png" alt="" width="80%"></p>

#### Tag Policy

AWS tags are powerful because they are user-defined and flexible. However, they also create mistakes. This type of policy enforces tag standardisation across accounts in your organisation.

For more information, see [Tag policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)

#### Policies that configure automatic backups for the resources in your organisation's accounts

You can use backup policies to configure and automatically apply AWS Backup plans to resources across all your organization's accounts. For more information, see [Backup policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_backup.html)

#### Integration with other AWS services

You can leverage the multi-account management services available in AWS Organizations with selected AWS services. For a list of services and the benefits of using each service, see [AWS services that support AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html).

<h2 id="aws-organizations-use-cases">AWS Organizations use cases</h2>

<p style="margin-left:15px">
-   **Automate the creation of AWS accounts and categorize workloads using groups:** for example, you can create separate groups to categorize development and production accounts.
-   **Implement and enforce audit and compliance policies:** You can apply SCPs to ensure that users in your accounts only perform actions that meet your security requirements.
-   **Provide tools and access for your security:** You can use AWS Organizations to create a Security OU and provide them with read-only access to all of your resources.
-   **Share common resources across accounts:** AWS Organizations makes it easy for you to share critical central resources across your accounts. For example, you can share your central [AWS Directory Service](https://aws.amazon.com/directoryservice/?org_product_ow_directoryservice) Managed Microsoft Active Directory. Or you could use [AWS Service Catalog](https://aws.amazon.com/servicecatalog/?org_product_ow_servicecatalog) to share IT services hosted in designated. Additionally, you can ensure application resources are shared across your organization using [AWS Resource Access Manager](https://aws.amazon.com/ram/?org_product_ow_ram).
</p>

<p style="text-align:center">
**Achieve unrivaled security and compliance with the StormIT Cloud Check-Up. We perform a gap analysis with more than 600 Best Practice Checks to reduce risk, identify security vulnerabilities, and remediate compliance breaks in your AWS environment.**
</p>

<a href="https://www.stormit.cloud/cloud-check-up/" class="blog-post__buttons">Get a cloud check-up</a>

<h2 id="aws-organizations-pricing">AWS Organizations pricing</h2>

AWS Organizations is a feature of your AWS account **offered at no additional charge**. Therefore, basically every feature described in this article is for free and you can use it on any scale with as many accounts as your organization needs.

## What are the benefits of AWS Organizations?**

<p style="margin-left:15px">
-   **Quick and precise permission administration:** AWS accounts can be allocated to teams, workloads, or products. Separate accounts can provide custom environments and accommodate the differing security needs for each team.
-   **Apply boundaries:** Different projects within the organization may be exposed to different security and compliance requirements. You can easily enforce unique identity policies.
-   **Contain damage within logically isolated user accounts.** If a specific user account is compromised, only the resources assigned to that AWS Organizations' user account will be exposed to the higher risk.
-   **Easily managed billing:** The use of multiple accounts simplifies how you allocate AWS costs. You can use them to identify which projects or services are responsible for AWS charges.
</p>

<h2 id="aws-organizations-vs-iam">AWS Organizations vs AWS IAM</h2>

AWS organizations, especially SCPs, do not replace associating IAM policies with AWS accounts, groups and roles. AWS Organizations don’t work without AWS IAM, but if you have simple AWS infrastructure, you don’t need to use AWS Organizations.

**IAM policies** are used for AWS accounts to allow or deny them access to AWS services such as Amazon EC2 and Amazon S3, and specific AWS resources (such as selected S3 buckets) or API operations (such as S3) to create buckets.

![41_AWS-organizations-7.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/41_AWS_organizations_7_cc2aa890b8.png)

**IAM users** are a great way to manage employee access as one AWS account can have multiple IAM users and each can have their own permissions.

![41_AWS-organizations-6.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/41_AWS_organizations_6_17604d9ced.png)

**IAM roles** are used to authenticate service accounts. For example, if you're running the AWS CLI on an Amazon EC2 instance and want to permit it to manage an Amazon S3 bucket, you can use an IAM role to do so so you don't have to leave your credentials on the remote server.

![41_AWS-organizations-5.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/41_AWS_organizations_5_05fe3dbdd1.png)

However, **with AWS Organizations**, you can use SCPs to allow or deny access to specific AWS services for individual AWS accounts or groups of accounts in an OU. The specified action of the attached SCP affects all IAM users, groups and roles of the AWS account, including the root account identity.

#### Which one should you use?

The answer is basically both: IAM users and AWS Organizations do different things, but use Organizations only if you need it.

<p style="margin-left:15px">
-   **Separate your infrastructure:** Use AWS Organizations and create separate accounts for development and production.
-   **You may also want to create two more environments:** testing, which contains clean dummy data and staging, and a full production environment to capture any possible occurrences before they affect real customers/users.
-   Create multiple IAM users with proper policies applied in the development environment to provide managed access to your employees.
-   Production should only be updated by authorised personnel, including of course the IAM service accounts required for normal operation.
</p>

## Conclusion

AWS Organizations brings capabilities that help you reach your business goals around budget, security and compliance in complex AWS environments. This blog post should help you understand the basics of this service and decide if it is the right solution for you.


Navigate AWS Organizations: Streamline management of multiple AWS accounts, understand its benefits over AWS IAM, and implement effective strategies.

AWS Organizations: How to Manage Multiple AWS Accounts?

large_36.jpg

medium_36.jpg

small_36.jpg

thumbnail_36.jpg

36.jpg

In this article, you'll learn:

-   [**What is API Gateway and how does it work?**](#what-is-api-gateway)
-   [**How does an API Gateway work?**](#how-does-api-gateway-work)
-   [**Why use an API Gateway?**](#why-use-api-gateway)
-   [**API Gateway security**](#api-gateway-security)
-   [**Amazon API Gateway**](#amazon-api-gateway)

<p style="margin-left:20px">
-   [**Features of Amazon API Gateway**](#amazon-api-gateway-features)
-   [**Amazon API Gateway benefits**](#amazon-api-gateway-benefits)
-   [**Amazon API Gateway and AWS Lambda**](#amazon-api-gateway-lambda-example)
-   [**Does Putting CloudFront CDN in Front of API Gateway Make Sense?**](#amazon-api-gateway-cloudfront)
</p>

Application Programming Interfaces (APIs) are the primary way that external users are going to make calls to your application.

Now more than ever, **companies are modernizing their large legacy monolithic apps** into smaller individual **microservices**. These microservices are loosely coupled to make your application more scalable and highly available. However, the result of using a microservice architecture is that **more API calls are exchanged between your client and the microservice**.

In this blog post, we explore what you need to know about **a managed API Gateway**, its security, benefits, and also Amazon API Gateway basics, features, and how it interacts with AWS Lambda.

<h2 id="what-is-api-gateway">What is API Gateway and how does it work?</h2>

An API Gateway is a service that **sits before an API or set of microservices to facilitate requests** and the delivery of data.

For example, every time you use an app of your favorite social network or check travel prices for your next vacation, you're using an API.

An API Gateway is a way to **decouple the client interface from the backend**. When a client makes a request, the API gateway **breaks it into multiple requests**, routes them to the right services, produces a response, and keeps track of everything.

An API Gateway should also include:

<p style="margin-left:15px">
-   **Security**
-   **Caching**
-   **API composition and processing**
-   **API monitoring**
-   **Routing**
</p>

<h2 id="how-does-api-gateway-work">How does an API Gateway work?</h2>

API gateways **allow different applications/services to communicate with each other** and exchange data on and off the network. It receives requests (called "API calls") from internal and external sources, forwards them to the appropriate API, and then receives and transmits responses to the requesting user or device.

For **example**, suppose there is an application **user that needs to call four different services** as part of a process. Instead of having microservices calling each other directly, we do all the calls through the API Gateway.

![39_api-gateway-6.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/39_api_gateway_6_ac8b9013ba.png)

<h2 id="why-use-api-gateway">Why use an API Gateway?</h2>

At its most basic, an API Gateway accepts a remote request and returns a response. It is particularly useful for overcoming the challenge of offering your clients a simple and dependable experience.

### API Gateway benefits

<p style="margin-left:15px">
-   It helps to protect your APIs from overuse and abuse, and you can leverage an authentication/authorization and rate limiting.
-   It simplifies analytics and monitoring because it has these functions integrated.
-   If you are using a microservices architecture, a single request could require calls to dozens of distinct applications; an API Gateway will act as an intermediary between services.
-   At some point you’ll likely add new or update API services, but your users need to find all your services in the same place.
</p>

### Disadvantages and challenges of API Gateway
<p style="margin-left:15px">
-   It requires the setting of routing rules.
-   Risk of complexity due to all the API rules being in one place.
-   There is a possibility of a single point of failure.
</p>

<h2 id="api-gateway-security">API Gateway security</h2>

Generally, API gateway security can be divided into:

### Identity and Access management

Access control is the number-one security driver for API Gateway technology, serving as a governor of sorts so an organization can manage who can access an API and establish rules around how data requests are handled.

When all traffic is routed through an API Gateway, IT security experts tend to feel more confident that they have their finger on the pulse of an organization.

### API calls security

Gateways are a great way to route all API calls through a single place for evaluating, transforming, and securing them across the whole infrastructure. When all traffic is routed through a gateway, security specialists know what is happening and can make changes much more easily.

### DDoS and threat protection

Without threat protection, the API Gateway, its APIs, and the native services of the integration server are insecure. That means malware or any anonymous outsiders could easily attempt to propagate a series of attacks such as DDoS or SQL injection.

### Input Validations

Taking advantage of loose input validations allows a hacker to find the gaps in a system. Using existing inputs, an attacker will explore what is accepted or rejected and push what is possible until they find a way into an API and break down the system's integrity.

Here are the most common input validations.

<p style="margin-left:15px">
-   **Message size:** it is good to have message size limitations if you know with 100% certainty that you are not going to receive large messages.
-   **SQL injection:** SQL injection protection allows you to block requests that could cause an SQL injection attack.
-   **XML threat protection:** Malicious attacks on XML applications typically involve large, recursive payloads, XPath/XSLT or SQL injections, and CData to overwhelm the parser and eventually crash the service.
-   **Rate limiting:** Requiring authentication for all API users, and the logging of all API calls made allow API providers to limit the rate of consumption for all API users.
</p>

<h2 id="amazon-api-gateway">Amazon API Gateway introduction</h2>

Amazon API Gateway is a managed service that lets you easily handle common API tasks such as routing, security, caching, throttling, and monitoring.

Amazon API Gateway provides a highly scalable solution for creating and deploying these API types:

<p style="margin-left:15px">

-   **HTTP API:** Low-cost, low-latency REST API with built-in features like OIDC and OAuth2, and native CORS support.

[Build a CRUD API with Lambda and DynamoDB](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-dynamo-db.html)

-   **WebSocket API:** Build a WebSocket API with persistent connections for real-time use cases such as chat applications or dashboards.

[Building a serverless chat app with a WebSocket API, Lambda and DynamoDB](https://docs.aws.amazon.com/apigateway/latest/developerguide/websocket-api-chat-app.html)

-   **REST API:** Develop REST APIs that give you full control over requests and responses, as well as API management capabilities.

[Build an API Gateway REST API with Lambda integration](https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-with-lambda-integration.html)

-   **Private REST API:** Create a REST API that can only be accessed within an AWS Virtual Private Cloud (VPC).

</p>

AWS provides flexibility in choosing backend technologies such as [AWS Lambda](https://www.stormit.cloud/aws-lambda/) functions, AWS Step Functions state machines, or call HTTP(s) endpoints hosted on AWS Elastic Beanstalk, Amazon EC2, or any other hosted HTTP based services.

It can also allow backends to be simple web applications for web portal access or Amazon S3 buckets for providing access to static web content or documents.

![39_api-gateway-5.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/39_api_gateway_5_33791ea78a.png)

### Amazon API Gateway pricing

With Amazon API Gateway, you only pay when you use your API. There are no minimum fees or upfront payments.

For HTTP APIs and REST APIs, you only pay for the API calls you receive and the amount of data transferred. Private APIs do not incur data transfer charges. Learn more here: [Amazon API Gateway pricing](https://www.stormit.cloud/blog/amazon-api-gateway-pricing/).

<h2 id="amazon-api-gateway-features">Features of API Gateway</h2>

<p style="margin-left:15px">
-   Powerful, flexible [authentication](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html) mechanisms, such as AWS Identity and Access Management policies, Lambda authorizer, and Amazon Cognito user pools.
-   [Canary release deployments](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html) for safely rolling out changes.
-   [CloudTrail](https://docs.aws.amazon.com/apigateway/latest/developerguide/cloudtrail.html) logging and monitoring of API usage and API changes.
-   CloudWatch access logging and execution logging, including the ability to set alarms.
-   Support for [custom domain names](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html).
-   Integration with [AWS WAF](https://www.stormit.cloud/aws-web-application-firewall/) for protecting your APIs against common web exploits.
</p>

### Amazon API gateway caching to enhance responsiveness

You can enable API caching in Amazon API Gateway to cache your endpoint's responses. With caching, you can reduce the number of calls made to your endpoint and also improve the latency of requests to your API.

When you enable caching for a stage, API Gateway caches responses from your endpoint for a specified time-to-live (TTL) period in seconds.

Caching is charged by the hour and is not eligible in the AWS Free Tier.

![39_api-gateway-1.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/39_api_gateway_1_a94165c660.png)

<h2 id="amazon-api-gateway-benefits">Amazon API Gateway benefits</h2>

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/39_api_gateway_4_622a761615.png" alt="" width="80%"></p>

### Efficient and scalable

Run multiple versions of the same API simultaneously so you can quickly iterate, test, and release new versions. You pay for API calls and data transfer, and there are no minimum fees or upfront fees.

### Performance

Provide end users with the lowest possible API request and response latency by leveraging the global network of edge locations and [Amazon CloudFront CDN](https://www.stormit.cloud/cloudfront/). Limit traffic and authorize API calls to ensure backend operations can withstand traffic spikes and don't call backend systems unnecessarily.

### Monitor with ease

Monitor performance metrics and information on API calls, data latency, and error rates from the API Gateway dashboard, which allows you to visually monitor calls to your services using [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/).

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/39_api_gateway_2_f4f1505400.png" alt="" width="80%"></p>

### Flexible security

Authorize access to your APIs with AWS Identity and Access Management (IAM) and Amazon Cognito. If you use OAuth tokens, API Gateway offers native OIDC and OAuth2 support.

To support custom authorization requirements, you can execute [a Lambda authorizer](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) from AWS Lambda.

<h2 id="amazon-api-gateway-lambda-example">AWS Lambda and Amazon API Gateway example</h2>

Together with [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/), API Gateway forms **the app-facing part of the AWS serverless infrastructure**.

It’s also possible to combine these serverless services with, for example, **Amazon Cognito** for authorization/authentication purposes, and **Amazon DynamoDB** to play the role of the non-relational serverless database.

![39_api-gateway-3.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/39_api_gateway_3_2b7e834fa8.png)

For an app to call publicly available AWS services, you can use Lambda to interact with required services and expose Lambda functions through API methods in API Gateway.

**AWS Lambda runs your code on highly available computing infrastructure**. It performs the necessary execution and administration of computing resources.

To enable serverless applications, API Gateway supports [Lambda proxy integration](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-set-up-simple-proxy.html) or Lambda non-proxy integration:

<p style="margin-left:15px">
-   **Lambda-Proxy:** If you want a simple Integration and don’t need specifications or any other filters.
-   **Lambda Integration:** If you need to have more control over the workflow, generate sophisticated documentation, and SDK generation.
</p>

<p style="text-align:center">
**The StormIT team holds the** [**AWS Service Delivery Program designation for AWS Lambda**](https://www.stormit.cloud/blog/stormit-sd-aws-lambda/) and helps organizations to redesign their legacy applications or release new ones by leveraging the Amazon API Gateway and other AWS serverless services.**
</p>

<h2 id="amazon-api-gateway-cloudfront">Does Putting CloudFront in Front of API Gateway Make Sense?</h2>
Because API is used widely, it’s common that customers want to have a global API presence. But is it always sensible not to use your CloudFront distribution? This is a good question that we've tried to answer in our article: [Does Putting CloudFront CDN in Front of API Gateway Make Sense?](https://www.stormit.cloud/blog/cloudfront-in-front-of-api-gateway/)


Explore the key features of API Gateway and its impact on modern API security and management. Gain expert insights with StormIT.

API Gateway: What is it and why is it important? | StormIT

large_API_gateway.jpg

medium_API_gateway.jpg

small_API_gateway.jpg

thumbnail_API_gateway.jpg

API_gateway.jpg

A Beginner's Guide to API Gateway: What is it and Why is it Important?

In this article, you will learn:

-   [**What is Amazon GuardDuty?**](#what-is-guardduty)
-   [**GuardDuty implementation**](#guardduty-implementation)
-   [**GuardDuty findings**](#guardduty-findings)
-   [**Testing GuardDuty**](#testing-guardduty)
-   [**Comparison of GuardDuty**](#comparison-of-guardduty)
-   [**GuardDuty pricing**](#pricing-guardduty)

With the cloud, the collection and aggregation of accounts and network logs is simplified, but the security team's continuous analysis and inspection of event log data for potential threats can be difficult and time-consuming. AWS (Amazon Web Services) offers a service in the form of **Amazon GuardDuty**, which helps with automation and **analysis of** a vast amount of **CloudTrail events and VPC, S3, and DNS Query logs.**

<h2 id="what-is-guardduty">What is Amazon GuardDuty?</h2>

Amazon GuardDuty uses intelligent and continuous threat detection of your AWS accounts, data stored in Amazon S3, and workloads to reduce risk.

It's essentially a **security service** that keeps an eye on everything happening in your account at an infrastructure level, **alerting you to any undesirable behavior**.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/20_Amazon_Guardduty_1_7b6ad99106.jpg" alt="How Amazon GuardDuty works" width="100%"></p>

### Enable GuardDuty and start monitoring:
<p style="margin-left:15px">
-   **Abnormal API activity:** monitor for unusual API calls coming from an unknown malicious IP or domain.
-   **Attempts to disable AWS CloudTrail logging:** the attacker is trying to cover their tracks by disabling logging so you can't see where the attackers come from or exactly what they've done.
-   **Potential unauthorized deployment and compromised instances:** an attacker launching an EC2 instance into your VPC that could actually be a backdoor into your VPC.
-   **S3 bucket compromise:** activity indicating an S3 bucket compromise, such as suspicious patterns indicating credential misuse, unusual S3 API activity, unauthorized S3 access from known malicious IP addresses, and API calls to retrieve data in S3 buckets.
-   **Amazon Elastic Kubernetes Service (Amazon EKS) clusters:** continuously identify malicious behavior that threats container workloads. Amazon GuardDuty for EKS analyzes Kubernetes audit logs from existing and new Amazon EKS clusters in your accounts.
</p>

### Use cases
<p style="margin-left:15px">
-   **Protect your compute workloads:** detect when your EC2 instance is used to mine cryptocurrency or communicate with IP addresses and domains associated with known malicious actors.
-   **Protect your AWS credentials:** detect when your AWS credentials are used in a suspicious way, such as from IP addresses associated with known malicious actors, or in a way that deviates from their expected behavior.
-   **Protect your data stored in Amazon S3 buckets:** detect when data stored in your Amazon S3 buckets are accessed in a highly suspicious manner, such as when an unusual volume of objects is retrieved from an unusual location, or when the S3 bucket is accessed from IP addresses associated with known malicious actors.
</p>

### GuardDuty machine learning

GuardDuty uses machine learning to detect anomalies in the behavior of your account. So when you first set up GuardDuty **it takes between seven and 14 days to set a baseline** as it needs to establish what is normal behavior in your account. Once the baseline has been created GuardDuty can then actively begin monitoring your account. When active, you will only see findings if GuardDuty detects behavior that it considers a threat.

<h2 id="guardduty-implementation">Amazon GuardDuty implementation</h2>

### Implementation in the AWS Management Console

<p style="margin-left:15px">
1\. Set up and log into AWS account.<br>
2\. Open the GuardDuty console at <https://console.aws.amazon.com/guardduty/><br>
3\. Click on the **“Get Started”** button.<br>
4\. You are able to use GuardDuty and its threat detection with a 30-day free trial.<br>
</p>

<p style="text-align:center">**Amazon GuardDuty is possible to integrate with AWS Security Hub, learn more about it in our blog post:** [**What is AWS Security Hub? Definition, Benefits & Pricing**](https://www.stormit.cloud/blog/aws-security-hub/)
</p>

<h2 id="guardduty-findings">Amazon GuardDuty findings</h2>

The GuardDuty findings represent potential security issues detected in your AWS environment. You can view and manage your GuardDuty results on the "Findings" page of the GuardDuty console or using the GuardDuty CLI or API operations.

### Severity levels for GuardDuty findings

Each GuardDuty finding has an assigned severity level (Low, Medium, and High) and value (0.1 to 8.9) that reflects the potential risk.

<p style="margin-left:15px">
-   A **“Low” (0.1 – 3.9)** level indicates suspicious or malicious activity that was blocked before it compromised your resource.
-   A **“Medium”** **(4 – 6.9)** level indicates suspicious activity. For example, a large amount of traffic is being returned to a remote host that is hiding behind a network.
-   A **“High” (7 – 8.9)** level indicates that the resource in question (e.g. an EC2 instance or a set of IAM user credentials) is compromised and used for unauthorized purposes.
</p>

### Where to locate findings

Use the following procedure to view and analyze your GuardDuty findings.

<p style="margin-left:15px">
1\.  Open the GuardDuty console at <https://console.aws.amazon.com/guardduty/><br>
2\.  Choose **Findings** and then select a specific finding to view its details.<br>
![20_Amazon-Guardduty-2.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/20_Amazon_Guardduty_2_6ce016f32d.png)
</p>

The details for each finding will depend on the **Finding type, resources involved, and nature** of the activity.

<h2 id="testing-guardduty">Testing Amazon GuardDuty</h2>

If you want to test Amazon GuardDuty, try the following and generate findings.

### 1\. AWS GuardDuty tester tool for Linux

You can find the CloudFormation template for GuardDuty tester on AWS lab GitHub page with everything prepared: <https://github.com/awslabs/amazon-guardduty-tester>.

Just follow the [basic steps](https://github.com/awslabs/amazon-guardduty-tester#step-1) for creating an AWS environment with EC2 instances, VPC and everything will be set up for you. Then you will connect to one of the EC2 instances and start the script.

There are **six tests provided** that will be started by the **guardduty_tester.sh** script:
<p style="margin-left:15px">
1\.  Internal port scanning<br>
2\.  SSH Brute Force with Compromised Keys<br>
3\.  RDP Brute Force with Password List<br>
4\.  CryptoCurrency Mining Activity<br>
5\.  DNS Exfiltration<br>
6\.  Fake domain to prove that GuardDuty is working<br>
</p>

After running this script a couple of times, we got these results in the GuardDuty Findings:

![20_Amazon-Guardduty-3.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/20_Amazon_Guardduty_3_088bcee1f1.png)

### 2\. Generate sample Findings in GuardDuty Console

You can find the sample findings function in the GuardDuty console to help visualize the different Findings types that GuardDuty generates.

![20_Amazon-Guardduty-4.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/20_Amazon_Guardduty_4_c2faa8639b.png)

Sample findings can also be used **to test notifications or automation** that you have configured for findings.

After using this function, we got these results in the GuardDuty findings.

![20_Amazon-Guardduty-5.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/20_Amazon_Guardduty_5_2414c66b95.png)

<h2 id="comparison-of-guardduty">Comparison of Amazon GuardDuty</h2>

### Is Amazon GuardDuty an IDS or IPS?

No, it is not an **Intrusion Prevention System (IPS)** since it only alerts about an activity. You could build your actions on top of GuardDuty alerts with AWS Lambda, but it is not part of the service itself.

And it is not an **intrusion detection system (IDS)** either. IDS are usually aware of what is happening on the virtual instances and the better ones are even application-aware. GuardDuty only acts on Cloudtrail logs, VPC flow logs, and DNS query logs. **It has no idea what is running on your instances** and has no understanding of what is normal behavior for you or your business.

### What is the difference between Amazon Inspector and Amazon GuardDuty?

**Amazon Inspector** provides you with security assessments of your applications settings and configurations on your **EC2 instances** while Amazon GuardDuty helps with analyzing your entire AWS environment for potential threats.

Inspector only covers EC2 at the moment. GuardDuty, on the other hand, will continuously monitor your “AWS accounts, workloads, and data stored in Amazon S3” and alert you.

### Amazon GuardDuty vs Amazon Macie

GuardDuty is different from [Amazon Macie](https://www.stormit.cloud/blog/what-is-amazon-macie/). Macie only looks into S3 buckets and intelligently classifies data to help you ensure the proper access controls are applied to those data.

<h2 id="pricing-guardduty">Amazon GuardDuty pricing</h2>

You get the first 30 days for free so you can try out every function. After this period is up, you’ll be charged based on the quantity of CloudTrail Events and also on the volume of DNS Logs and Flow Logs as well. **You only have to pay for the detection capacity you use**, when you use it.

Find more about [GuardDuty pricing](https://aws.amazon.com/guardduty/pricing/) on the AWS official page.

You can find your current estimated total daily costs on the **“Usage“** page in the GuardDuty Console.

![20_Amazon-Guardduty-6.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/20_Amazon_Guardduty_6_b227a9591b.png)

**Pricing example** per month in the EU Central (Frankfurt) region:

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/20_Amazon_Guardduty_7_745382e190.png" alt="Pricing example for Amazon GuardDuty" width="100%"></p>

<p style="text-align:center">**StormIT team helps organizations protect their websites and applications against all commonly known attacks and exploits by leveraging the protection of AWS Edge Services.**</p>

<a href="https://www.stormit.cloud/cdn-security/" class="blog-post__buttons">Learn More</a>



Amazon GuardDuty uses intelligent and continuous threat detection of your AWS accounts. Learn more...

What is Amazon GuardDuty? Definition, Pricing & Comparison

large_amazon-guardduty.jpg

medium_amazon-guardduty.jpg

small_amazon-guardduty.jpg

thumbnail_amazon-guardduty.jpg

amazon-guardduty.jpg

In this article, you will learn:

-   [**What is Kubernetes?**](#what-is-kubernetes)
-   [**EKS Demo Deployment**](#eks-demo-deployment)

As the demand for scalable and efficient container orchestration solutions intensifies, **Kubernetes has emerged as a leading choice for managing containerized applications.** Amazon Web Services (AWS) caters to this need with its managed Kubernetes service, Amazon Elastic Kubernetes Service (EKS).

This article serves as a beginner's guide, explaining the fundamental concepts of AWS EKS and offering insights into why it has become a cornerstone in the world of container orchestration.

<h2 id="what-is-kubernetes">What is Kubernetes?</h2>

Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

Deploying and managing containerized applications at scale on bare-metal Kubernetes is demanding and presents challenges, such as operational complexity, possibility of node failure, backup and migration requirement, and the task of maintaining the servers. This is why we have managed Kubernetes services such as Amazon Elastic Kubernetes Service (EKS) to simplify Kubernetes adoption and operation.

Amazon EKS is an AWS variant of Kubernetes. It is an AWS-managed service that helps you to run Kubernetes on AWS cloud and on-premises data centers in an easier way.

### **Benefits of Amazon EKS**
<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/1_benefits_of_aws_eks_348598d312.png" alt="benefits of aws eks" width="100%"></p>

<p style="margin-left:15px">
-   **Highly available:** By design, EKS is highly available and fault tolerant.
-   **Scalability:** with tools such as cluster auto-scaler, EKS can seamlessly and automatically scale containerized applications to meet changing demands, without impacting application performance.
-   **Security:** EKS utilizes a combination of AWS IAM and role-base access control to secure your cluster.
-   **Serverless compute option:** To run your application using serverless computing, EKS supports AWS Fargate. This service removes the need to provision and manage servers.
-   **Observability:** EKS integrates with other AWS monitoring, observability and logging services, such as CloudWatch and Amazon Managed Service for Prometheus, to gain visibility into your Kubernetes clusters.
</p>

<h2 id="eks-demo-deployment">EKS Demo Deployment</h2>

EKS can be deployed using various methods, such as AWS management console, AWS CLI. CloudFormation, and Terraform, but we shall be using eksctl as the deployment tool. Eksctl offers a streamlined and user-friendly experience, abstracting the complexities of Kubernetes management and incorporating AWS best practices, making it an efficient and effective choice for both beginners and experienced users.

### Prerequisites:

-   **AWS CLI Installation:** Make sure you have the AWS CLI installed and configured with the necessary access rights. To install the latest version, see <a href="https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html" target="_blank">Installing, updating, and uninstalling the AWS CLI</a>

-   **kubectl Installation:** kubectl is used to interact with your Kubernetes clusters. To install or upgrade kubectl, see <a href="https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html" target="_blank">Installing or updating kubectl</a>.

-   **eksctl Installation:** eksctl is a command-line tool used to create and manage EKS clusters. To install eksctl see <a href="https://eksctl.io/installation/" target="_blank">eksctl installation guide</a>.

### Deployment Steps:

1\.  **Create a Cluster Configuration File:** Create a YAML configuration file for your EKS cluster. Specify parameters like region, node instance type, and cluster name. For example:

<p style="margin-left:15px; background-color:Gainsboro">
apiVersion: eksctl.io/v1alpha5<br> 
kind: ClusterConfig<br>
metadata:<br>
<p style="margin-left:15px">  
name: my-eks-cluster<br>  
region: us-west-2
</p>
nodeGroups<br>

<p style="margin-left:15px">   
-name: ng-1<br>
instanceType: t2.small<br>  
minSize: 2<br>
maxSize: 3<br>
</p>

</p>


2\.  **Create the EKS Cluster:** Use eksctl to create your EKS cluster by running the following command:

<p style="margin-left:15px; background-color:Gainsboro">
eksctl create cluster -f cluster-config.yaml
</p>

This command provisions the EKS cluster and associated resources.

3\.  **Configure kubectl:**

After the cluster is created, update your kubectl configuration to point to the new cluster:

<p style="margin-left:15px; background-color:Gainsboro">
aws eks --region us-west-2 update-kubeconfig --name my-eks-cluster
</p>

4\.  **Verify the Cluster:** Ensure that your cluster is running by checking the nodes:

<p style="margin-left:15px; background-color:Gainsboro">
kubectl get nodes
</p>

5\.  **Deploy an Application:** You can deploy a sample Nginx web server to test your cluster:

<p style="margin-left:15px; background-color:Gainsboro">
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx-app.yaml
</p>

Verify the deployment:

<p style="margin-left:15px; background-color:Gainsboro">
kubectl get deployments kubectl get pods
</p>

6\.  **Clean Up:** This ensures that you won't incur additional costs if you're done testing.
 To delete the cluster and associated resources, use:

<p style="margin-left:15px; background-color:Gainsboro">
eksctl delete cluster -f cluster-config.yaml
</p>


In conclusion, embrace the future of container orchestration with AWS EKS and unlock the full potential of your cloud-native journey. Now that you've gained insights into the benefits and capabilities of AWS EKS, it's time to take the next step.

Discover the essentials of AWS EKS in our beginner's guide to Kubernetes excellence. Learn more...

Embarking on Kubernetes: Unveiling the Basics of AWS EKS

large_kubernetes-intro-eks.JPG

medium_kubernetes-intro-eks.JPG

small_kubernetes-intro-eks.JPG

thumbnail_kubernetes-intro-eks.JPG

kubernetes-intro-eks.JPG

Embarking on Kubernetes Excellence: Unveiling the Basics of AWS EKS

## About BAUER MEDIA GROUP

Bauer Media Group is a multi-business organization that entertains, informs, and serves over 200 million people. Present in four Business Areas - Publishing, Audio, Online Comparison Platforms(OCPs), and SME Services, operating in 14 countries. With leading Online Comparison Platform (OCP) market positions in Spain, Sweden, Norway, Finland, Poland, Czech Republic and Slovakia. Bauer Media Group has over 16,000 employees in 14 countries and generated 2.2 billion Euros in annual revenue.

## Business Requirement
Bauer Media Group has acquired multiple OCPs within the EU to accelerate market penetration in Europe. **The customer had decided to replace the existing, in-house developed CRM for Salesforce** to improve the productivity of the sales team and gain a 360-degree overview of their customers across all countries.

The **challenge was legacy CRM solutions that were not inter-compatible** and every brand used its own in-house development. Business-critical logic and revenue were driven by legacy systems so it was not possible to replace them instantly without impacting the business productivity. 

## Bridging the gap and connecting legacy CRMs to Salesforce
The **challenge was to connect Salesforce and legacy systems with no changes to legacy systems in a short period of time**. Additionally, due to changes in the company, there was a lack of human resources knowledgeable about the existing solution.

To integrate Salesforce and legacy systems **StormIT designed the solution that leverages AWS Cloud and built the Integration Layer that did all the heavy lifting** in transforming the data and establishing the two-way synchronization. 

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/Bauer_Media_SFDC_1_64f142d3bd.png" alt="reference architecture bauer media 1" width="100%"></p>

The solution is **fully based on AWS Serverless technology**, leveraging services such as <a href="https://www.stormit.cloud/aws-lambda/" target="_blank">AWS Lambda</a>, <a href="https://www.stormit.cloud/blog/api-gateway/" target="_blank">Amazon API Gateway</a>, Amazon DynamoDB, Amazon AppFlow, Amazon EventBridge, etc. The integration layer is designed in such a way to be scalable, with minimum management overhead for the customer, and the customer would pay only for what they use. The logic is handled by multiple AWS Lambda functions and the data is stored in DynamoDB. For logging, Amazon CloudWatch is used.

**StormIT was able to deliver the solution in under 4 weeks at an extremely low cost for AWS services. **The customer is able to send the new demands/orders to SFDC (SalesForceDotCom) and propagate changes made from SFDC to Legacy Systems with low latency in nearly real-time. 


To integrate Salesforce and legacy systems StormIT designed the solution that leverages AWS Cloud and built the Integration layer.

BAUER MEDIA GROUP - Integration Platform Deployment in AWS Cloud

large_Bauer-Media-main-title-pic.jpg

medium_Bauer-Media-main-title-pic.jpg

small_Bauer-Media-main-title-pic.jpg

thumbnail_Bauer-Media-main-title-pic.jpg

Bauer-Media-main-title-pic.jpg

In this article, you will learn:

-   [**What is Amazon CloudFront origin access identity (OAI)?**](#what-is-cloudfront-oai)
-   [**Why should you use CloudFront S3 OAI?**](#why-cloudfront-oai)
-   [**Set up OAI for new CloudFront distributions**](#setup-cloudfront-oai-for-new)
-   [**Set up OAI for existing CloudFront distributions**](#setup-cloudfront-oai-for-existing)

When you set up an Amazon S3 bucket as the origin of an [Amazon CloudFront](https://www.stormit.cloud/cdn-services/) distribution, you give everyone permission to read the files in the bucket (public access). This allows anyone to access your files through CloudFront or using an Amazon S3 URL. CloudFront doesn't expose Amazon S3 URLs, but if your application serves any files directly from Amazon S3, or if someone provides a direct link to a specific file in Amazon S3, your users may still find these URLs.

In this blog post, you'll **learn about CloudFront origin access identities,** which address the need to secure and restrict public access to S3 buckets behind a CloudFront distribution.

**Recently AWS introduced a new function that replaces OAI, and it has a very similar name: CloudFront origin access control (OAC) and it brings some new features, read more in our blog post here: [Amazon Cloudfront Origin Access Control (OAC): New Features and How to Set it Up](https://www.stormit.cloud/blog/cloudfront-origin-access-control/)**

<h2 id="what-is-cloudfront-oai">What is Amazon CloudFront origin access identity (OAI)?</h2>

Amazon CloudFront OAI is a simple function of CloudFront distribution that you can enable when you select S3 buckets as origin. If you don’t use an OAI, the S3 bucket must allow public access.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_1_d0cc03fdbd.png" alt="" width="70%"></p>

OAI prevents users from **viewing your S3 files by simply using the direct URL** for the file, for example:

<p style="margin-left:15px">
app-private-bucket-stormit.s3.eu-central-1.amazonaws.com/pics/logo.png
</p>

Your **users can only use the URL of your CloudFront** distribution, for example: 
<p style="margin-left:15px">
d2whx7jax6hbi5.cloudfront.net/pics/logo.png
</p>

You can watch our video about OAI here:
<div class="videoWrapper">
<iframe width="560" height="315" src="https://www.youtube.com/embed/69DUk-vlL-g" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>


### S3 bucket static website endpoint and OAI**

You **cannot set OAI** for the S3 bucket **website endpoint**.

These two functions do not work together because **you are only able** set the OAI for S3 bucket directly:

<p style="margin-left:15px">
test-bucket-website-stormit-2022.s3.eu-central-1.amazonaws.com
</p>

And you are **not able to enable it for its website endpoint**:

<p style="margin-left:15px">
test-bucket-website-stormit-2022.s3-website.eu-central-1.amazonaws.com
</p>

One of the main reasons for using the **S3 static website hosting function** is that you can very **simply use** [redirection rules](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-page-redirect.html). This will **not work if you use the OAI** function in CloudFront.

The only way to set permissions when using CloudFront and the S3 website endpoint is through [restricting access to files on CloudFront custom origins](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-overview.html#forward-custom-headers-restrict-access) or [serving private content with signed URLs and signed cookies](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html).

### How does CloudFront OAI work?**

<p style="margin-left:15px">
1\. CloudFront OAI works by first creating a CloudFront user/permission called an origin access identity (OAI) and associating it with your distribution.

2\. Then it gives the OAI permission to read the files in your S3 bucket.

3\. You can then remove permission for anyone else to use Amazon S3 URLs to read the files.
</p>

![34-Cloudfront-OAI-6.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_6_fa4fe10129.png)


<h2 id="why-cloudfront-oai">Why should you use CloudFront S3 OAI?</h2>

So essentially what **we don't want is users to be able to browse to our S3 bucket using the S3 URL**. We want to **force them to use the CloudFront URL**. With an OAI, CloudFront sends authenticated requests to your S3 bucket. This means you can block public access to your S3 bucket while still allowing CloudFront to get objects from the bucket instead of going directly to your origin. Furthermore:

<p style="margin-left:15px">
-   **Data are more secure** and it’s simpler to monitor who has access to that data.
-   Access to your files should be **generally faster** when only CloudFront URL is used to deliver your objects instead of S3 because the objects are copied to the edge in order to be stored closer to your users.
-   It can help you [reduce the overall costs of Data transfer out](https://www.stormit.cloud/blog/aws-data-transfer-pricing-how-to-reduce-costs/), because serving data directly from S3 costs more than serving them through CloudFront distribution.
</p>

<p style="text-align:center">
**Save up to 60% on your CloudFront costs with StormIT optimized pricing.**
</p>
<a href="https://www.stormit.cloud/cdn-cost-calculator/" class="blog-post__buttons">Estimate savings</a>

<h2 id="setup-cloudfront-oai-for-new">Set up OAI for new CloudFront distributions</h2>

Let’s assume that we have an S3 bucket with videos that we need to share publicly through CloudFront distribution. We also need to cost optimize data transfer out and hide our S3 URLs, so we need to be sure that our users are only using CloudFront URLs.

![34-Cloudfront-OAI-16.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_16_80fe89e4a2.png)

<p style="margin-left:15px">
1\. Log in to the [CloudFront Console](https://console.aws.amazon.com/cloudfront/v3/home).<br>

2\. Click on **“Create Distribution”**.<br>

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_15_b557281c3c.png" alt="" width="50%"></p>

3\. Select S3 bucket as origin domain, choose **“Yes use OAI”** and click on **“Create new OAI”.**<br>

![34-Cloudfront-OAI-7.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_7_4d04f6c3c6.png)

4\. Name your OAI and click **“Create”**.<br>
<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_8_31563afe34.png" alt="" width="70%"></p>

5\. Next you need to select **“Yes, update the bucket policy”**. This will update the policies for your S3 bucket. It’s going to add a code which ensures that only this CloudFront distribution has access to your files in S3 buckets.<br>

![34-Cloudfront-OAI-9.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_9_4cf6af56b8.png)

If you choose **Yes, update the bucket policy**, CloudFront updates S3 bucket permissions to grant the specified OAI permission to read files in your bucket. However, **CloudFront does not remove existing permissions.** If you want to manually update permissions on your Amazon S3 bucket, choose **No, I will update the bucket policy**.

Example of CloudFront OAI S3 bucket policy:

<p style="margin-left:15px; background-color:Gainsboro">
{<br>
&nbsp;&nbsp;&nbsp;&nbsp;"Version": "2008-10-17",<br>
&nbsp;&nbsp;&nbsp;&nbsp;"Id": "PolicyForCloudFrontPrivateContent",<br>
&nbsp;&nbsp;&nbsp;&nbsp;"Statement": [<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Sid": "1",<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Effect": "Allow",<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Principal": {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E315IEIAPWW6YR"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;},<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Action": "s3:GetObject",<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Resource": "arn:aws:s3:::test-bucket-website-stormit-2022/*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;}<br>
&nbsp;&nbsp;]<br>
}<br>
</p>

6\. It’s also good to select **“Redirect HTTP to HTTPS”** or **“HTTPS only”** for this type of distribution.<br>

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_10_4c264ca16d.png" alt="" width="48%"></p>

7\. You can leave everything else as default. Click on **“Create distribution”**.<br>

8\. Do not forget to **block all public access** in permissions for your S3 bucket. You should also see a new bucket policy.<br>
</p>

![34-Cloudfront-OAI-11.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_11_7a19b486b6.png)

<h2 id="setup-cloudfront-oai-for-existing">Set up OAI for existing CloudFront distributions</h2>

<p style="margin-left:15px">
1\. Log in to the [CloudFront Console](https://console.aws.amazon.com/cloudfront/v3/home).

2\. If you already have an OAI, you can use it. If you don’t you can create it by clicking on “Origin access identities”.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_12_3dfa4d7ec5.png" alt="" max-width="100%"></p>

3\. Next click on **“Create origin access identity”**.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_13_2032e4d06e.png" alt="" max-width="100%"></p>

4\. Name your OAI and click on **“Create”**.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_2_6813c7d299.png" alt="" max-width="100%"></p>

5\. Go back to CloudFront distributions and select the one that has an S3 origin.

![34-Cloudfront-OAI-4.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_4_5f24ac6a02.png)

6\. Choose the **“Origins”** tab. Select the Amazon S3 origin, and then choose **“Edit”**.

![34-Cloudfront-OAI-3.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_3_3bdec0221e.png)

7\. For **S3 bucket access**, choose **“Yes use OAI”**. Select an **OAI** and **“Yes, update the bucket policy”**.

![34-Cloudfront-OAI-5.png](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_5_a98265b097.png)

8\. Choose **“Save changes”.** Note that it can take a while for the change to take effect and the CloudFront URLs to be used instead of the S3 URLs.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/34_Cloudfront_OAI_14_bdc0685cd2.png" alt="" max-width="100%"></p>

9\. **Do not forget to block all public access in permissions for your S3 bucket.**

</p>


Learn about CloudFront OAI, which addresses the need to restrict public access to S3 buckets. With OAI it’s simpler to monitor who has access to data.

Cloudfront Origin Access Identity (OAI): How to use it? | StormIT

large_cloudfront_oai.jpg

medium_cloudfront_oai.jpg

small_cloudfront_oai.jpg

thumbnail_cloudfront_oai.jpg

cloudfront_oai.jpg

Amazon Cloudfront Origin Access Identity (OAI): What it is and How to Use it?

In this article, you’ll learn:

-   **<a href="#ha-definition">High availability definition</a>**
-   **<a href="#aws-high-availability">AWS high availability</a>**
-   **<a href="#aws-high-availability-vs-fault-tolerance">AWS high availability vs. fault tolerance</a>**
-   **<a href="#aws-high-availability-best-practices">AWS high availability best practices</a>**

Businesses must now run their apps 24/7 in order to meet customer expectations. **Failure in their apps results in unavailability, which frustrates customers.** This leads to a loss of customer satisfaction, which eventually leads to a loss of business revenue.

In this article, we will introduce some basics about high availability infrastructures. How is high availability calculated and what it means. And **for those interested in AWS Cloud, we look at AWS's high availability architecture**, and its advantages, as well as an analysis of AWS computing, database, and storage services and what kind of availability they can bring.

<h2 id="ha-definition">High Availability definition</h2>

Failures in IT applications create downtime, which is a period of time when your system is not available for use or is unresponsive. **For some companies each minute of downtime costs thousands of dollars.**

High availability is a **system’s ability to function even when some components fail**. It guarantees continuous operability of systems for desirably long periods of time. High availability protects businesses against the risks brought by a system outage.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/High_availability_1_41e9fa1096.png" alt="high availability cluster" width="100%"></p>

High availability for systems is represented through a sequence of “9s”. A 100% availability translates to 0 minutes of downtime in a year, which is possible in the public cloud, but it usually comes with a cost so high that businesses tend to avoid it.

<p style="margin-left:15px">
-   **Three-nine availability, represented as 99.9%, allows 8 hours and 46 minutes of downtime per year.**
-   **Four-nine availability, 99.99%, allows 52 minutes and 36 seconds of downtime per year.**
-   **Five-nine availability, 99.999% which is the accepted standard for mission-critical operations, provides about 5 minutes and 15 seconds of downtime per year.**
</p>

Here is a simple graph of how availability is calculated for complex infrastructures:

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/High_availability_calculation_211e728a57.png" alt="high availability calculation" width="100%"></p>

The following elements help you implement highly available systems:

<p style="margin-left:15px">
-   **Reliability:** in the sense that the system continues operating even when critical components fail.
-   **Resiliency**: means that the system can simply handle failure without service disruption or data loss, and seamlessly recover from such failure.
-   **Redundancy**: ensures that critical system components have another identical component with the same data, which can take over in case of failure.
-   **Monitoring**: identifying problems in production systems that may disrupt or degrade service.
-   **Failover**: the ability to switch from an active system component to a redundant component in case of failure, imminent failure, degraded performance or functionality.
-   **Failback**: the ability to switch back from a redundant component to the primary active component when it has recovered from failure.
</p>

<h2 id="aws-high-availability">AWS high availability</h2>

The **AWS (Amazon Web Services) Cloud is unique in building high availible business applications** since AWS’ high availability delivers features that let you build these applications with little interaction and minimal upfront investment.

**AWS recommends following these guidelines:**

<p style="margin-left:15px">
-   **Design the system to have no single point of failure.** This can usually be achieved via load balancing, or by a pair of nodes in an active-standby configuration.
-   Prepare operating **procedures for manual or automatic mechanisms** to respond to, mitigate, and recover from the failure.
</p>

### AWS high availability with zones

AZs are **isolated places with servers (data centers) located within regions in which AWS operates**. At this moment there are 25+ regions and the minimum number of AZ in regions is two.

The use of multiple AZs enables customers to replicate workloads across the physical location.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/region_and_azs_439e61596d.png" alt="aws regions and avalability zones" width="100%"></p>

Depending on the workload, it can be difficult to configure deployment across multiple AZs, but almost every AWS service has it covered and you just need to use the right settings. We’ll cover this more thoroughly in the next section of this blog post.

### AWS Compute, Databases, and Storage High Availability

Most applications will rely on these AWS services, which can be divided depending on their usage in multi-tier applications:

<p style="margin-left:15px">
-   **Compute**: Compute dimension contains AWS services like Amazon EC2 and AWS Lambda.
-   **SQL Databases**: Amazon RDS and other managed SQL databases provide RDS high availability options.
-   **Storage Services**: Such as S3, EFS, and EBS.
</p>

In the sections that follow, we’ll look more closely at each.

#### AWS computing high availability

##### EC2 high availability

Amazon Elastic Compute Cloud (Amazon EC2) compute resources are made highly available by using multiple instances at the same time to collectively process incoming requests.

This group of Amazon EC2 instances can be managed with Amazon EC2 Auto Scaling.

You achieve a reasonably good level of high availability by using the following services and features:

<p style="margin-left:15px">
-   **Availability Zones (AZs)** allow you to distribute EC2 instances across many locations. They provide a much greater level of protection against failure, as the data center itself is removed as a single point of failure.
-   **Elastic Load Balancing (ELB)** allows you to launch several EC2 instances and spread traffic between them. As ELBs exist outside of any particular AZ, they are themselves insulated from AZs failure.
-   **Auto-scaling** allows for the health of Amazon EC2 instances to be monitored and also self-healed by spinning up new compute instances if an existing one fails, with feature support to help cater for stateful applications.
-   **Elastic IP addresses,** for example, can reroute a workload from one EC2 instance to another instantaneously.
</p>

##### Best practices for EC2 instance high availability

<p style="margin-left:15px">
-   It is recommended that you run EC2 instances in multiple AZs. If these zones become unavailable due to natural circumstances or power outage, Elastic Load Balancer can route traffic to operational AZ.
-   And if you need more than one instance in every AZ, it is recommended you use Auto Scaling which automatically increases the number of instances to meet your high traffic demands and save you money by stopping the instances which are no longer needed.
</p>

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/ec2_simple_high_availability_architecture_238f1c256f.png" alt="ec2 high availible architectures" width="85%"></p>

#### AWS Lambda high availability

<a href="https://www.stormit.cloud/aws-lambda/" target="_blank">AWS Lambda</a> has high availability built in and it runs your function in multiple AZs to ensure that it is available to process events in case of a zone failure.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/aws_lambda_simple_high_availability_architecture_c094f439e0.png" alt="ec2 high availible architectures" width="70%"></p>

#### AWS high availability for Amazon RDS

Amazon Relational Database Service (RDS) is similar in some ways to EC2 because RDS instances are EC2 instances managed by AWS. RDS's high availability is achievable by spreading multiple instances with the same data across AZs.

AWS supports two options of RDS for HA:

<p style="margin-left:15px">
-   **Amazon RDS Multi-AZ Deployments:** In Multi-AZ deployments, Amazon RDS automatically generates a primary DB instance and synchronously replicates the data to a standby instance in a separate AZ.

    This can be used for MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server.  
      
    In the event of an infrastructure (AZ) failure, Amazon RDS automatically switches to the backup database instance in the separate AZ.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/RDS_high_availability_architecture_53f8ba10f1.png" alt="ec2 high availible architectures" width="85%"></p>

-   **Amazon Aurora Multi-AZ** achieves high availability by replicating data six times across three AZs. But this only a storage layer.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/Aurora_replication_6_1022d7ea3e.png" alt="ec2 high availible architectures" width="100%"></p>

You can also choose to run one or more replicas in an Amazon Aurora DB cluster. RDS automatically promotes an existing Aurora Replica to be the new primary replica and changes server endpoints in the event of a primary replica failure in a DB cluster, allowing your application to continue running without human intervention.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/Aurora_replication_cluster_92652c85b3.png" alt="ec2 high availible architectures" width="100%"></p>

If a problem is detected and no replicas are provisioned, RDS will immediately spawn a new replacement DB instance for you, providing AWS RDS high availability for all your needs.

</p>

#### High Availability for AWS storage services

AWS offers storage for every use case and achieves high availability in a unique way.

##### Amazon Simple Storage Service (S3)

This service provides object storage for videos, pictures, documents, and more, offering secure, durable, and scalable object storage for a vast majority of projects in AWS.

S3 has high-availability built-in and offers 99.99% availability for object storage with 99.999999999% durability (based on storage type selected).

Depending on which storage tier you choose, data in an Amazon S3 storage bucket may be stored in just one AZ. Data will become unavailable if an S3 storage service disruption affects that AZ.

##### Amazon Elastic File Storage (EFS)

This option provides a managed file storage solution for Linux instances and offers an SLA of four-nine availability (99.99%). Amazon EFS can be used to provide redundancy across AZs, as well as providing the capability to mount the same filesystem concurrently from multiple Amazon EC2 instances.

##### Amazon Elastic Block Store (EBS)

This is a block storage service that is designed to work with Amazon EC2 instances and is highly scalable and high-performing.

Although Amazon EBS storage is internally replicated to several servers within an AZ, there is no redundancy outside of this zone. To achieve this, you would need to use Amazon EBS snapshots to create copies of the data in Amazon S3.

##### Amazon FSx

This is a high-performance file system. As a fully managed service, it handles hardware provisioning, patching, and backups Amazon FSx protects your data against failure by automatically replicating it inside or across AWS AZs.

#### Network high availability

One of the most important facets of highly available systems is the management of connectivity. In the event of a failure, clients need to be able to find any currently active nodes to re-establish communication and data operations.

##### Amazon Route 53 DNS

 provides highly available DNS services that can perform health checks on its targets and perform automatic failover for both active-active or active-passive configurations.

##### AWS NAT gateway high availability

NAT Gateway is a zone service. If you have resources communicating through it in multiple AZs, and if the NAT gateway’s AZ is down, resources in the other AZs lose Internet access too.

Depending on your business requirements, make sure to create NAT Gateways in at least two AZs.

##### Amazon API Gateway high availability

<a href="https://www.stormit.cloud/blog/api-gateway/" target="_blank">API Gateway</a> is not built into one AZ, so it is highly available from the start.

#### Monitoring

Monitoring is paramount when it comes to high availability, and for this AWS provides Amazon CloudWatch, which can be used to monitor most services.

<h2 id="aws-high-availability-vs-fault-tolerance">High availability vs. fault tolerance</h2>

The most basic difference between fault tolerance and high availability is this: A fault-tolerant environment has no service interruption but a significantly higher cost, while a highly available environment has a minimum service interruption but less cost.

Many businesses are willing to absorb a small amount of downtime with high availability rather than pay the much higher cost of providing fault tolerance.

It must be said that in the AWS Cloud the fault tolerance and high availability for some services can be so close together that you can say they are the same.

The typical example of AWS high availability vs fault tolerance is simple architecture with EC2 instances spread across AZs in the <a href="https://www.stormit.cloud/blog/aws-auto-scaling/" target="_blank">Auto Scaling</a> group and Application load balancer (ALB). This architecture can be seen as High-Available.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/ec2_simple_high_availability_architecture_238f1c256f.png" alt="ec2 high availible architectures" width="85%"></p>

If you take this architecture and copy it to another AWS region, it can be seen as fault-tolerant. You can also leverage Route 53 as DNS and route your users with weighted routing.

<p style="text-align:center"><img src="https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/Ec2_region_architecture_8e906eede7.png" alt="ec2 high availible architectures" width="85%"></p>

<h2 id="aws-high-availability-best-practices">AWS high availability best practices</h2>

Regardless of the specific AWS tools and services in use, the following best practices can help you:

<p style="margin-left:15px">
-   **Secure your credentials and environment:** You can have the best services available at any time in the public cloud, and everything set up perfectly for high availability, but if there is a breach in your system and the intruder decides to stop your services, it can mean downtime. Secure your environment with 
<a href="https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/security.html" target="_blank">AWS best practices</a> in mind and MFA.
-   **Be mindful of the expenses:** When creating infrastructure with high availability or redundancy, consider the cost of infrastructure. This should be compared to the benefits of the bill to determine if it is worth it. You can also <a href="https://www.stormit.cloud/blog/aws-cost-optimization/" target="_blank">use AWS cost optimization tools</a>.
-   **Anticipate and plan for software failures:** Creating effective incident response plans helps mitigate the risk of failures in the software. High availability doesn’t avert the possibility of software malfunctions.
-   **Data backups** are essential for maintaining data integrity and ensuring high availability. Data loss is a significant risk no matter where data is stored. This is due to issues such as data deletion or the failure of backup servers or application instances. Even with high availability protections in place, it's important to perform regular backups.
</p>

## Conclusion

This blog introduces you to high-availability systems and the services AWS provides to implement them. AWS's high availability requires minimal manual intervention and low up-front financial investment, making AWS the best choice for building applications and infrastructure.


Learn some basics about AWS high availability(HA) infrastructure, how HA is calculated and what it means. 

Learn some basics about AWS high availability(HA) infrastructure, how HA is calculated, and what it means. 

BRID TV - Enterprise-level Video Monetization

BridTV introduction

Global AWS infrastructure costs optimization

Similar blog posts