If you want your application to have this functionality, you'd usually have to build your server and its logic. But we now live in an age of technological innovation, and tools have been created to help you minimize your development time.

This tool is called Firebase Remote Config — a cloud service that enables you change different functionalities of your app without releasing updates or asking users to update the app.

Overview

You can access the Remote Config feature in your project’s Firebase console. It is usually under the Release & Monitor section on the left sidebar.

There are two ways in which you can define your remote configurations:

1. Using Firebase.
2. Using a template file that is in JSON format.

We will focus on the first option, as the second option is a less intuitive approach.

Firebase Remote Config lets you define one or more keys during configuration. Keys can be of the following type:

• String
• Number
• Boolean
• JSON

These keys are used as the configurations for your application. For example, if you have a feature in your application that you would like to control through remote configurations, you could define a Boolean key titled enableFeatureX.

Each key you set has a few other settings that may be useful to you. For example, you can define a default value for a key (for example, false can be the default value of a Boolean key) or make it use a value that you have defined in your application.

Another cool thing you can do, by clicking on the Add new button in the image above, is to set the value of a key based on certain factors. You'll see these options when you click on the button:

• Conditional value.
• Experiment.
• Personalization.

Once you are done adding a key, make sure to publish your changes so they will be deployed.

The Conditional Value Option

You can configure how a value will be set to specific users based on various conditions.

Here, you can decide on what you want to test and how. You will discover several options when you click on the “Applies if” dropdown.

To illustrate the use of this feature, let’s say that you want to target iOS users in the US. You can do that using the “Applies if” dropdown and choosing Platform and then iOS.

After that, you can press the "and" button to add a condition for Country/Region and choose United States.

Make sure to also name your condition, otherwise, the Create condition button won’t be enabled.

Notice how the last field in defining a new condition window tells you how many users will be affected by this condition? That's a pretty cool feature.

The Experiment Option

This option lets you change the behavior of a value in your remote configurations before taking effect on all your users.

You can follow these steps to configure the experiment option:

• In the first step, you have to fill in the name and description of your experiment.
• Then, you have choose which application to target and how many users will be affected (percentage-wise) in the second step.
• The third step is to set up the metrics to measure this experiment. There are two types — the primary metrics and additional metrics.
• Lastly, you can decide on the number of A/B test groups for this experiment.

The Personalization Option

Last but not least is the option to tailor a specific value of your remote configurations to a user based on their own behavior.

You can define values the algorithm may supply to the user based on their behavior. These will be chosen by an objective you define (Step 2). This objective can range from the engagement time of the user to the amount of clicks they perform. In Step 3, you define a condition that will target users so that they will become personalized. Lastly, in Step 4, you add the name and description of this personalization.

Each option has much more to offer than what I have described here, so if you want to learn more, you can use one of the reference links at the bottom. Now that we understand what Remote Config is, let’s see how we can add it to our application.

How to Setup Firebase Remote Config

Before you can do anything related to applying remote configurations, you need to make sure you've added Firebase to your Android project. This has been documented here.

After you have done that, follow these steps:

Step #1 - Add the Firebase remote configuration library to your project inside your application build.gradle file

 implementation 'com.google.firebase:firebase-config-ktx'

There is an option to also import the Firebase Analytics module, but it is not required for remote configurations. It is used in other areas of remote configurations, such as defining a condition based on a specific event happening.

Step #2 - Use the RemoteConfig Object

After syncing your project, you can access the RemoteConfig object with this command:

val remoteConfig: FirebaseRemoteConfig = Firebase.remoteConfig

Step #3 - Define fetch interval

You can define how often your remote configurations will be fetched and updated. When you are still developing your application, setting this number to be relatively low is more ideal.

val remoteConfigSettings = remoteConfigSettings {                             minimumFetchIntervalInSeconds = 2000
}

If you set the **minimumFetchIntervalInSeconds** to be too low, Firebase will throw a FirebaseRemoteConfigFetchThrottledException, so use a low number only when you are testing things.

Step #4 - Set the configuration for the remote configuration

You can set the remote configuration using the code below:

remoteConfig.setConfigSettingsAsync(remoteConfigSettings)

Step #5 - Set default values

You can have application default values for your remote configurations. These can be created as an XML file inside the XML directory inside the res folder. Here’s what the code looks like:

:remoteConfig.setDefaultsAsync(R.xml.remote_config_defaults)

This XML file must have an underlying element of a map to wrap all your default values. For example, let’s imagine we have defined a key in remote configurations called my_key, whose value is 1. The XML for the default values will look like this:

<?xml version="1.0" encoding="utf-8"?>
<defaultsMap>
   <entry>      
      <key>my_key</key>     
      <value>1</value>   
    </entry>
</defaultsMap>

Remote configurations need to be fetched and activated. The fetch action fetches and stores your Remote Configurations inside the Remote Config object. The activation part is to make these values available to your application. That’s why there are two API methods:

• fetch (and later use activate)

remoteConfig.fetch().addOnCompleteListener { task ->               if                if (task.isSuccessful) {     
              //Remote Configurations fetch successfully          
           }         
        }.addOnFailureListener { error ->             
                //Remote Configurations fetch failure            
       }
-------------------------
remoteConfig.activate().addOnCompleteListener { task ->  
if (task.isSuccessful) {
        //Remote Configurations activation success   
        }  
   }.addOnFailureListener { error -> 
               //Remote Configurations activation failure
  }

• fetchAndActivate

remoteConfig.fetchAndActivate().addOnCompleteListener { task ->                                if (task.isSuccessful) {     
                //Remote Configurations fetched and activated successfully                }        
       }.addOnFailureListener { error ->           
       //Remote Configurations fetched and activated failure    
     }

Step #6 - Access configurations

Now that our remote configurations have been fetched and activated, we can access and use them in our application. We can do so by accessing the remoteConfig object and using one of the getter methods per the type of the value we set:

val myRemoteConfigValue: String = remoteConfig.getString("my_key")

Conclusion

Since your application will rely on remote configurations for its operation (or parts of it), it is crucial to decide how the application will behave if it does not arrive or takes too long to receive a response.

In essence, there are two ways to handle loading the remote configurations:

1. Your application boots up and waits for the remote configurations to be activated.
2. Your application boots up and does not wait for the remote configuration to be activated. Opting instead to use the remote configurations on the second application run.

It's important to understand that there is no option that is preferable over the other. It all depends on what your use case is and how you would like the user's experience to be when using your application. The first option guarantees that once your application is loaded, all the remote configurations that you have defined will be set and the user's experience will be smooth after the initial load time. If you have critical features that rely on the remote configurations, you will have to go with this option.

On the other hand, if your remote configurations concern a specific feature of your application that doesn't necessarily need to happen on the first initial launch, you might consider going for second option. That way, your application does not need to wait for the remote configurations to be received from Firebase and the logic inside your application can happen later.

There are good and bad implications for each of these methods, and it’s up to you to decide which is better suited for your application. If you choose the first option, you may add a loading screen that times out after a certain period. If you choose option two, it is recommended to create a default mechanism for features in your application and how they should work when the configuration has not yet been received.

There is more than we have discussed in this article, and I encourage you to investigate deeper things. I recently used Firebase Remote Configurations in an application I created that helps users schedule appointments.

You can check it out on the Google Play store.

And you can see the source code here:

If you want to read other articles I have written, you can find them below:

References

• Getting Started With Firebase For Android
• Remote Config Use Cases
• Remote Config Loading Strategies
• Remote Config Personalization

AWS is currently the most popular cloud service provider, as it owns around 33% of the cloud market.

Companies and organizations are looking for candidates with AWS skills. A way to showcase your AWS knowledge is by obtaining an AWS certification.

In this article, I will list the current AWS certifications and go into more detail about the Cloud Practitioner certification.

Let's get into it!

What Is AWS? Amazon Web Services Explained

Amazon Web Services (or AWS for short) is a cloud computing platform offered by Amazon.

The platform provides on-demand cloud computing services such as hosting for servers, storage, database management, networking, and security, to name just a few of them.

Many businesses use AWS, including big companies such as Airbnb, Netflix, LinkedIn, and Twitter. With that said, it is also used for personal projects.

What Is an AWS Certification?

An AWS certification is a credible way to demonstrate to an employer that you have the specific technical skills and competence to design, build, deploy, migrate, operate, and maintain well-architected AWS systems.

Obtaining an AWS certification and gaining cloud architecture expertise is a great way to kickstart a new career in tech and open doors in a fast-growing industry.

An Overview of the Different AWS Certification Types – Levels of AWS Certifications

Currently, there are four types of AWS certifications.

There is one foundational level certification – the Cloud Practitioner certification.

There are three associate level certifications – the Solutions Architect, the Developer and the SysOps Administrator certifications.

There are also two professional level certifications – the Solutions Architect and DevOps Engineer certifications.

And lastly, there are six specialty level certifications – the Advanced Networking, Data Analytics, Database, Machine Learning, Security and SAP on AWS certifications.

Choosing an AWS certification will depend on your experience level, professional goals, and interests.

Now, let's go into more detail on the fundamental AWS certification – the Cloud Practitioner certification.

What Does an AWS Cloud Practitioner Do?

An AWS cloud practitioner is responsible for the organization's cloud computing architecture. They resolve scalability challenges and handle high-risk issues.

The practitioner understands AWS's core design principles and best practices for architecture.

They know how to design, build, deploy, and monitor applications on the cloud within AWS platforms.

They gather insights into end-users' problems and pain points, leverage software and hardware systems to address those problems, and come up with solutions.

What Is the Average Salary for an AWS Cloud Practitioner?

According to data from Glassdoor, the estimated total pay for a cloud practitioner in the USA for 2023 is around $91,038 per year, with an average salary of $83,679 per year.

With that said, compensation is relative and will depend on your field and chosen industry, demand, previous experience, skills, and location. The average salary for a cloud practitioner may be higher in different regions in the USA and lower in other countries.

AWS Cloud Practitioner Certification Prerequisites

The AWS Cloud Practitioner certification is a great place to start your cloud computing learning journey and a new career in the cloud.

It is an entry-level certification intended to provide fundamental knowledge and a general overview of AWS and its infrastructure. It doesn't require any previous experience or specific prerequisites.

With that said, having an understanding of the AWS platform and cloud computing terminology and concepts can be helpful during your learning process.

To understand the core concepts of cloud computing and AWS, you can read through the AWS Cloud Essentials Guide by AWS.

AWS Cloud Practitioner Certification Curriculum

The four major topics you will learn while studying for the AWS Cloud Practitioner certification fall into the following categories:

• Cloud concepts (26%), such as learning about cloud computing topics, how cloud-based applications work and scale, the AWS core infrastructure, and its architectural principles.

• Security and compliance (25%), such as learning security and compliance best practices for the AWS platform.

• Technology (33%), such as learning about AWS services and tools and their use cases.

• Billing and pricing (16%), such as learning about AWS billing, pricing models, support, and account management.

To learn more about the curriculum, AWS provides a complete exam guide, which covers the key modules in detail.

AWS Cloud Practitioner Certification Study Materials

You first need to create an AWS account.

AWS provides a free 12-month subscription to become familiar with the AWS console and its services.

When it comes to courses, you can use the AWS cloud essentials learning plan built by AWS, which goes over the recommended curriculum. This course covers AWS cloud, services, pricing, and security.

freeCodeCamp also offers an extensive 13-hour study course.

It's also a good idea to go through some practice questions and practice exams by the official page on Amazon to test whether you are prepared enough for the certification exam.

AWS Cloud Practitioner Certification Exam Details

Once you've created your AWS certification account, to schedule the AWS Cloud Practitioner exam, sign in to aws.training and click "Certification", where you can register and schedule the exam online or at a location near you.

The exam level is foundational, and the exam code is CLF-C01.

The exam costs $100 and is available in English, French, German, Indonesian, Italian, Japanese, Korean, Portuguese, Simplified Chinese, Spanish, and Traditional Chinese.

The exam is 90 minutes long and consists of 65 multiple-choice, multiple-response questions. The minimum passing score is 700 points.

Lastly, the AWS certifications are valid for three years, and you will need to renew them once they expire.

Conclusion

Hopefully, you found this article helpful and have a better understanding of what the AWS Cloud Practitioner certification entails.

Thank you for reading, and best of luck on your exam.

IAM, or Identity and Access Management, is one of the most common terms you'll hear in cloud-native environments.

But what does it do? And if you're already familiar with IAM, how long did it take you to fully understand it?

I will explain the main concepts behind this massive family of software, with you, the busy engineer, in mind.

The fundamentals described here are vendor agnostic, though most of my experience is with AWS's implementation.

What Is IAM?

IAM is a complex system of entities (humans, applications, and so on) that request access to a system. It is also a hierarchical set of rules to grant or deny requested access.

Before we go any further, here are the main terms you'll encounter:

• Resource: Anything worth protecting. A storage service, virtual machine, etc.
• Policy: A set of rules that dictate who can and can't do something on a single resource or group of resources.
• Action: Anything someone can do inside the cloud environment. For example, creating a virtual machine.
• User: Well... A user :)
• Group: A group of users with the same permissions applied.
• Principal: A user or an application requesting access.
• Role: A set of powers assigned to a principal, usually for a limited amount of time.

Why IAM Is Useful

IAM is mainly used for authentication, authorization, granular access, and governance.

Let's see what those all mean:

• Authentication: The act over verifying who you are.
• Authorization: The act of identifiying if someone can perform the action they are requesting. This is usually combined with authentication, but not always.
• Granular access: Permissions that control each action that can happen on a resource. For example, a user might have permission to see firewall rules, but doesn't have permission to change them. This is implemented with Role-Based Access Control.
• Governance: The actions you take to know what is happening in your environment, mostly for reasons of budget, compliance, and proper access scope.

If you're a company of 1-3 people, then setting up a full-blown IAM solution is probably overkill. Buf if your team is larger than that, or you're planning to scale up, then you should start considering it.

Common Problems You Don't Use IAM

I believe you can see the benefits of an IAM solution.

Now let's take a look at some common problems organizations face in the absence of it.

It's Hard to Audit and Administer Access

Have you heard of cases where an employee had more access than they should? And additionally, no one knew?

This can be prevented with a properly set-up IAM solution.

Setting Up Accounts for New Hires Is a Pain

With an IAM solution in place, this would just be a matter of a few clicks. Namely, set up the users and add them to the IAM groups their teams use. That's it.

But without an IAM solution? You would need to set all the permissions for each account manually.

You might have a reference user to copy from, but does each new account need all the permissions the reference user has? Do you have special handling for user accounts that are less than 6 months old? Does the reference user have superuser permissions that should not be accidentally assigned to a new hire's account?

Offboarding People Is Time Consuming

Here you'll have similar problems to the new hire case above. But when a collegue is leaving, you'll need to change the password to all the accounts they potentially used.

This can turn ugly very fast, not to mention the side effects this has on other team memebers.

And you would have to do this for every script, application, and other resource whenever there's an offboarding. What if you have a team change 2-3 times per month? You and your team would have a hard time being productive.

Simple Things Require Human Intervention

Without an IAM solution, tasks like resetting a password or re-enabling an account that was locked need to be done manually.

Top-tier IAM solutions have a way to resolve such issues fast without much hassle.

Best Practices

If you've decided to set up IAM, here are some best practices. This is far from a full list, and is based on my personal experience. But I've seen these practices on more than one team, so they should work for you as well.

Never Grant Full Access... EVER

In a real-world scenario, you wouldn't want every user to have unlimited access to an account. Ideally, no one should full access to anything (apart from the account owner).

For example, if an employee's responsibility is to monitor logs, they should have read access only to that tool. They should not be able to restart a service, or view billing information.

Prefer Groups to Multiple Users

It's better to use groups instead of multiple users when you have a choice. Groups make administration exponentially easier.

For example, if a new person joins your organization as a developer, they can be added to an IAM group for developers. That new person will then inherit all the powers of that IAM group.

The alternative, creating a user for each group (reader_susan, admin_susan) is considered obsolete.

Prefer Roles on Existing Users to Creating a New User

When given the option, prefer assigning a role to an existing user rather than creating a new user.

For example, don't create an admin user and share the password between 10 people. Create an admin role and assign it to whoever needs it for a limited amount of time.

Audit Permissions Frequently

It is easy to make mistakes or perform malicious actions. At the very least, a company should audit permissions regularly, and ensure that only the proper people have the minimum level of access necessary for their roles.

You could also send an email to a certain team when a suspicious action happens. For example, assigning an admin role to a new hire.

Set Up Boundaries Beforehand

If an IAM solution allows for it, add boundaries to your ecosystem.

According to Amazon's documentation:

A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

(I know, I know — I promised to be vendor-agnostic 🙂)

In layman's terms, you can define the "maximum" permissions that can be assigned to anyone.

For example, a user will at most be able to view the logs from the relevant tool and restart a service. If someone attempts to get a role to create a new virtual machine they will be disallowed.

Conclusion

Thank you for reading this far. I hoped you enjoyed this introduction to IAM.

If you have any questions, please reach out to me on Twitter.

What is GitOps?

The first thing you need to know is that GitOps is a set of modern best practises for deploying and managing cloud native infrastructure and applications.

And it can an be a hard thing to get your head around if you have never worked with cluster management or application delivery before. But thankfully Cornelia does a great job explaining it in this 30 minute presentation.

Give it a watch, and then you can find the recap below.

So now that we have covered the basics of what GitOps are, here is a recap of its 4 main principles. Hopefully you can use them to start managing your own cluster with GitOps workflows.

Principles of GitOps

Describe Declaratively

By 'Declarative', all we mean is that we are writing our configuration as a set of facts directly in our source code on Git. This is now our single 'source of truth'.

For example I can declare my environments, such as a 'test environment', or a 'staging environment' or 'production' and so on, along with the application version that resides in that environment.

Make Sure State is Versioned

With our declarations now stored in a version controlled system and acting as our 'source of truth', we now have a single place from where everything is derived. We can spin up previous versions of the app easily, or perform rollbacks if we need.

Automate Change Approvals

We also need to allow any changes to our declared states to be automatically applied to our system. This is worth mentioning, because as we are now working in segregated environments, we no longer need cluster credentials to make changes in our system.

Alert on Differences

So now that we have the state of our system declared and versioned, we can use agents to check if everything is working as it should. This is considered a 'Feedback and Control Loop'. If something 'looks' different and not right, we will get alerted on this.

For a more in-depth look into these 4 principles, you can watch the Talk by Cornelia Davis above.

This article was written by Ania Kubow in support of the conference talk made by Cornelia Davis.

Code with Ania Kubów

Hello everyone. This channel is run by Ania Kubow. In this channel, I will be teaching you JavaScript,React, HTML, CSS, React-native, Node.js and so much more! A little bit about me:My background is in the financial markets, where I worked as a derivates broker our of University. After starting m…

YouTube

Passing the AWS Certified Cloud Practitioner Exam is one of the first steps to a career in cloud development. And freeCodeCamp just published my free 12-hour course that will help you prepare for the exam.

This exam mostly deals with cloud computing concepts. Even if you are new to coding, you should be able to prepare for this exam and earn the AWS certification.

This entire free course is now live on YouTube, and linked below. Before you dive into it, read this guide to help you decide whether the AWS Certified Cloud Practitioner certification is for you.

What is the AWS Certified Cloud Practitioner?

The Certified Cloud Practitioner is the entry-level AWS certification that goes through:

• The cloud fundamentals, for example Cloud Concepts, Cloud Architecture, and Cloud Deployment Models
• A close look at the AWS Core Services
• A quick look at the vast amount of AWS services
• Identity, Security, and Governance of the Cloud
• Billing, Pricing, and Support of AWS Services

The course code is CLF-C01 but its commonly referred to as the CCP.

Amazon Web Services is the leading Cloud Service Provider (CSP) in the world and the AWS Certified Cloud Practitioner is the most common starting point for people breaking into the cloud industry.

Consider the AWS Certified Cloud Practitioner if:

• You are new to cloud and need to learn the fundamentals
• You are in the executive, management, or sales level and need to acquire strategic information about cloud for adoption or migration
• You are a Senior Cloud Engineer or Solutions Architect who needs to reset or refresh your AWS knowledge after working for multiple years

No matter your path towards a cloud role, the AWS Certified Cloud Practitioner provides fundamental knowledge that you shouldn't skip.

How this course is different from the 2019 AWS Certified Cloud Practitioner course

This is the second edition of the AWS Certified Cloud Practitioner course released on freeCodeCamp. This edition has three times more content, and all previous content has been revised, expanded, and re-filmed.

I made these major updates because of some important changes that have been made to the AWS Certified Cloud Practitioner exam. In general AWS has increased the difficulty of this exam.

Overview of the AWS Certified Cloud Practitioner

The AWS Certified Cloud Practitioner is divided into 3 domains, each with their own weighting. The weighting determine the number of questions about that domain that will appear on the exam.

• Domain 1: Cloud Concepts at 26%
• Domain 2: Security and Compliance at 25%
• Domain 3: Technology at 33%
• Domain 4 Billing and Pricing at 16%

The official exam guide lists a very long list of possible services, technologies, and concepts that could appear on the exam. In actuality, only one third of the content that could appear will appear on the exam.

How do you get Certified?

Google uses Pearson Vue and PSI test centers to deliver the exam. You can take the exam in-person or online.

If you want to schedule the exam with either testing method, you do that via AWS Trainings Account.

There are 65 multiple-choice and multiple-select questions and you have to score 70% to pass.

The AWS Certified Cloud Practitioner costs $100 USD.

Can I simply watch the videos and pass the exam?

AWS has increased the difficulty of this exam. And while watching lecture videos is critical to passing, having hands-on experience and utilizing practice exams are essential if you want to pass the exam.

How much you need to study will vary, but on average it will require about 24 hours over 2 weeks to be prepared to successfully pass this AWS Certified Cloud Practitioner.

This course comes with a full free practice exam which you can redeem for free with no credit card by signing up on ExamPro.

ExamPro has multiple paid practice exams along with other study materials to increase your chances of passing.

Head on over to freeCodeCamp's YouTube channel to start working through the full 6-hour course.

Whenever I heard of the term “Cloud native”, my thoughts would usually go to Kubernetes. I used to think “Cloud native” was a phrase used for describing just Kubernetes.

But as I delved more into it, I realized my assumption was wrong. Cloud native isn't just about Kubernetes – it is so much more!

In this article, I will help you understand what Cloud native means, how the cloud computing delivery model works, its benefits, architectural principles, and more. Let's get started.

What is Cloud Native?

Cloud native is an approach to building and running apps that use the cloud computing delivery model.

The “cloud” is really just the internet, as cliché as it may sound. It is a network of servers where information, software, applications, and services are housed and accessed.

So what then is the cloud computing delivery model?

What is the Cloud Computing Delivery Model?

While the above definition of cloud native is great, you need to know what all the terms mean – like “cloud computing delivery model”. I certainly wondered what it was when I saw it on almost every cloud native definition on the internet.

First of all, it is helpful to know what cloud computing means to get a better understanding of the cloud computing delivery model.

What is cloud computing?

According to Techopedia,

Computing is the process of using computer resources (storage, networking, and computing power) to complete a given goal-oriented task.

Cloud computing offers on-demand availability of these computer resources (mentioned above) without direct active management by the user.

The Cloud computing delivery model represents a specific, pre-packaged combination of IT resources offered by a cloud provider.

There are a couple of cloud delivery models, but IaaS, PaaS, and SaaS are the most popular and widely used cloud delivery models.

What is Infrastructure as a Service (IaaS)?

This cloud computing delivery model focuses on providing infrastructure like servers, networking technology, storage, and data center space as a service to users.

This gives users the autonomy to decide what infrastructure is provisioned based on the different needs of their application. Popular examples of IaaS providers are Microsoft Azure and AWS.

What is Platform as a Service (PaaS)?

This is more focused on the development side of things by providing a platform for developers to deploy their apps to the cloud.

Some well-known examples of PaaS providers are Netlify and Heroku.

PaaS builds on top of IaaS, but unlike IaaS, it already handles the setup and configuration of the infrastructure your application needs.

In cases where users want more control of their infrastructure configurations, IaaS is a good choice.

What is Software as a Service (SaaS)?

This is the complete software product provided as a service to users that enables them to perform different activities.

For example, Gmail is a great SaaS cloud native application used by millions of people worldwide. As a user of Gmail, you will most likely not be concerned about how it was built or the underlying infrastructure, but you know for sure that you can use this software to send and receive emails.

What's the difference between Cloud Native Apps, Cloud Native Technologies, and Cloud Native Computing?

While learning about “Cloud Native”, I struggled with understanding the differences between cloud native, cloud native apps, cloud native technologies, and cloud native computing. I felt like they were all using the prefix cloud native but meant the same thing.

In fact, if you search for “What is Cloud native” on Google, you will see over ten resources on the search result page. And out of these ten resources, 4 of them define or talk about Cloud native. The other 4 are either Cloud native applications, Cloud native technologies, or Cloud native computing.

And to my surprise, these resources all had interchangeable definitions of what Cloud native meant, which got me confused. Was there a difference? Did these terminologies all mean the same thing?

I asked a couple of people about it and eventually understood the differences. So, here are my findings. 👇🏽

• Cloud native is an approach to building and running apps that exploits the advantages of the cloud computing delivery model.
• Cloud native applications are independent services, packaged as self-contained, lightweight containers that are portable and can be scaled rapidly based on the demand. They allow you to take advantage of the unique capabilities of the cloud.
• Cloud native technologies are the technologies used to build and scale cloud native applications, like Kubernetes, Helm, Docker, and others.
• Cloud native computing and cloud native mean the same thing. You can read the “Cloud native” definition above to understand better.

Cloud Native Architecture

Cloud native follows four architectural principles that help businesses ship products faster, implement their customer’s needs quickly, create value faster, and aid collaboration between developers and IT specialists.

Here are the four main principles that make cloud native architecture work:

Microservices

In microservices, you break the code down into independent modules. Each feature is a standalone service, and resources are assigned to the services only when you need them. Cloud native apps are built following this architecture.

Containers

Cloud native apps are packaged in containers. Containers provide isolation context for microservices making them highly accessible and easier to build, update, and scale.

CI/CD

Cloud native applications run on a continuous delivery model. This fosters collaboration between developers and the Operations team to enables them to build, deploy, and release software faster without affecting end-users or developers in other teams.

DevOps

Cloud native adopts DevOps as a practice to make continuous delivery and continuous integration (CI/CD) possible.

Benefits of building cloud native apps

There are a number of benefits to building cloud native apps:

• Independence: Because Cloud native apps use the Microservices architecture, it's possible to build cloud native apps independently of each other. This gives you the opportunity to build, manage, and deploy the different components of an application independently without affecting other components.
• Automation: Cloud native apps run on a continuous delivery model making it possible to ship software updates immediately.
• No downtime: Thanks to container orchestrators such as Kubernetes, you can deploy a software update with essentially zero downtime. If an instance of the application goes down, Kubernetes will automatically spin up another one for you immediately.
• Scalability: Cloud native apps enable flexible deployment options across the network making it easier to develop, deploy, and iterate on the application.
• Standards-based: Most cloud native services follow a set of standards championed by the CNCF Open Source organization. These standards have been vetted and approved by the community and are used by some of the biggest tech companies across the world. This helps reduce vendor lock-in and ensure that apps are built in the right way.

Summary

I hope you enjoyed reading this article. If you want to learn more about Cloud native, here are some useful resources for further reading:

• Cloud Native 101, VMware.
• How to start your Cloud native Kubernetes journey, Ambassador Labs.
• Understanding cloud-native apps, Red Hat.
• Cloud-Based, Cloud-Native, and Cloud-Enabled apps—What's the Difference?, PaperTrail.
• What is Cloud Native?, Oracle.
• What are Cloud Native applications?, VMware.

If you have any questions, you can ask me on Twitter.

In this article, I'll highlight what I mean by optimizing your costs in AWS cloud architecture. Then I'll share how you can do it with respect to the AWS Well-Architected framework.

The Problems of Maintaining IT Architecture

The traditional maintenance of IT infrastructure was not very, hmm, efficient? I don't really have the words to describe this issue, mostly because I'll never understand the pain of handling on-prem data centers.

But it involves provisioning the infrastructure, installing the OS and applications, configuring networking in a web of cables, constantly monitoring performance, and much more.

Imagine the effort required just to keep these data centers running – the procurement, the operations, building special facilities to keep the servers running, disaster recovery, and so on. It can take weeks if not months to scale this traditional infrastructure.

This kind of situation also influences the development of applications. Older applications were often built as monoliths and the overall risk of failure was high. What was your business again?

How Cloud Computing Helps

The emergence of cloud providers like AWS has changed this equation altogether. Imagine not having to do all of the above by yourself. Instead, a team of experts does it for you at a cost.

Cloud computing does just that. It has also introduced new ways for applications to be built. Applications that are developed using cloud capabilities are called cloud-native applications.

As I mentioned earlier, all of this comes at a cost. But if you compare those costs with the way traditional infrastructure was handled, it's still cheaper.

Still, that’s not all – it could be even cheaper if you manage your cloud services wisely. Cost Optimization is one of the pillars of an AWS Well-Architected Framework. This describes ways the costs can be optimized, not just by building cloud-native applications, but also other organizational aspects.

Cloud resources are scalable, easily managed, advanced, reliable, secure, cost-effective, and highly available. You don’t need to provision and pay for high-performing virtual machines from the beginning to manage a few traffic surges early on. This would be a typical lift and shift scenario.

Calculate Your Cloud Costs

If you are new to the cloud or are planning to migrate your existing workloads to AWS, AWS provides a nice service to calculate Total Cost of Ownership (TCO). It compares on-prem deployment with the costs which you would have to pay in the cloud.

The TCO calculator considers aspects like storage costs, network costs, server costs, and operational costs. It also provides you with an estimate for a lift and shift arrangement.

Estimations provided by TCO calculators can be further reduced by implementing below cost optimization pillars in cloud architectures, like:

1. Rightsizing
2. Increased elasticity
3. Choosing the right pricing model
4. Matching the demand
5. Measuring and monitoring

Cost Optimization Checklist

Rightsizing

It is very important to understand the capacity requirements of your application and its functions. Guessing the capacity usually results in a mismatch – we end up provisioning less which might cause us to lose customers, or we end up provisioning more where we end up paying for more than we need.

As a general rule, you should start small and monitor your usage for a while to establish a trend. Based on the trend you can scale out and purchase reserved instances or capacity which can help save computing costs up to 75%.

Increased elasticity

To accommodate occasional traffic surges automatically, it is important to implement elastic cloud architecture. This allows auto-scaling groups to scale in and scale out based on your needs. This is where you match the capacity to the demand.

Of course, this is not possible without monitoring your current usage. Monitoring helps you understand the compute requirements over time and allows you to define thresholds. You can use events which are generated this way to take scaling action.

Choosing the right pricing model

Every service offered by AWS comes with a pricing model. In the case of computing and storage, AWS offers various types of pricing models that, in essence, define the terms of managed services.

In the case of EC2 instances, the pricing model defines the availability and access at various levels. For example, on-demand instances can be created and destroyed anytime. On the other hand, reserved instances are fixed long-term instances that result in a cheaper expenditure.

There are other pricing models as well, like Spot instances, Dedicated instances, Dedicated hosts, and more.

Matching the demand

AWS Auto Scaling can be used to match the demand so that you pay less for periods when you're not active and only pay for times when demand surges. Over that period, you can also use reserved instances to further reduce your costs by committing to the long term. This is one example of cost optimization.

Moving to the cloud also calls for a cultural change in organizations, especially when it concerns cost optimization. Teams should be made aware of how the cloud works and what managed resources should be used in various scenarios.

You can form a Cloud Centre of Excellence (CCoE) to work across verticals to monitor and suggest better ways of implementing the Cost Optimization principles below.

1. Define and enforce tagging
2. Effective account structures
3. Design and use metrics
4. Design cost-based architectures

The Importance of Tagging

To deal with costs and answer expenditure-related questions, you should perform tagging as a best practice. Tagging of resources allows us to have greater visibility and more granular control over our cloud expenditures.

Standard tagging formats should be defined and enforced for each organization while creating cloud resources. The format may define aspects like the project, portfolio units, teams, and so on at an organizational level.

Going deeper, project-based conventions can also be defined to represent services supported by various cloud resources. However, be aware of the number of tags you choose – there shouldn’t be too many or too few tags defined. In general, tags can be categorized into two groups:

1. Technical – representing technical details like automation, security, and so on.
2. Strategic – representing organizational details like a cost center, access control, governance, and so on.

How to Track Your Cloud Computing Costs

There are a number of ways you can keep track of what you're spending on cloud computing. Let's look at the main ones now.

Cost Explorer

AWS provides a few highly useful services like Cost Explorer that gives you insight into your cloud spending over time. It offers a nice visual interface representing monthly or daily costs. It also gives you a default dashboard representing the monthly costs incurred per service.

AWS Cost Explorer helps you generate and export cost reports at a high level as well as granular and specific reports. You can build your reports and dashboard based on your interests and focus.

Cost Explorer helps you set budgets which helps monitor your costs. Budgets are a great way to keep your costs under control. Using budgets, you can define an expenditure baseline in AWS and set up threshold breach notifications.

For example, if the costs exceed more than 80% of the baseline budget, you can opt to get a notification which will then help you take action.

Cost Explorer also gives you rightsizing recommendations which help you identify where you might be provisioning more than the required infrastructure in terms of instance type, pricing model, and so on.

QuickSight

If you need a more detailed reporting tool, AWS offers its QuickSight service. It is a business analytic solution for cost reporting. It is fast and highly scalable and includes ML capabilities.

You can explore, analyze and collaborate on cost expenditure topics in a much better way. However, this is not a free service like Cost Explorer and it works on a pay-per-session basis.

AWS Trusted Advisor

AWS Trusted Advisor is a service that embodies a virtual service from AWS that advises you about the framework. It performs a series of checks with AWS best practices and highlights them in the below format if any actions are required.

1. no problem detected – meaning implementation is as per the required standards.
2. investigation recommended – for warnings.
3. action recommended – for any aspect which is totally out of place.

AWS Trusted Advisor continuously monitors how many of your provisioned resources you've used and generates recommendations. In the case of Cost Optimization, it highlights if any resources are underutilized, if instances are idle, whether reserved instances are going to expire, and more.

AWS CloudFront

You don't always have to wait for AWS Trusted Advisor to advise on optimizations before you take action. AWS CloudFront is a service that provides resource metrics that we can use to monitor performance ourselves and identify underutilized resources.

AWS CloudWatch is the easiest way to collect metrics since it integrates with several AWS Services directly. By gaining operational visibility and insights, you can act on improvements and optimize costs.

EC2 instance tenancy

AWS offers various options to provision a virtual machine on their infrastructure. These options are created to suit your need depending on how critical your service is.

In any given implementation, not all the services require dedicated high-performing nodes. Similarly, not everything can work on low compute and less available nodes.

This provides us with a gap to explore and define our compute infrastructure that is most suitable for the business and most cost-efficient. Let us take a look at some of the compute types (EC2) provided by AWS.

1. Reserved Instances – long-term commitment, low cost.
2. Spot instances – very low cost, uses sparing EC2 capacity, released when capacity not available, good for fault-tolerant applications.
3. On-Demand instances – no commitment, regular costs.
4. Dedicated instances – instances created from resources that are not shared.
5. Dedicated hosts – dedicated instance with access to hardware options like ports.
6. Reserved capacity – Reserved capacity can be purchased and used within an instance family. Instances can be resized, based on the normalization factor. Helps reduce cost with flexibility.

Based on your requirements, you can select the appropriate options from above to host your workload. For example, when you are sure that a certain node will exist for the long term, you can take advantage of reserved instances instead of on-demand instances and save up to 75% of the costs.

There is no point in provisioning an on-demand instance for loads that are ephemeral and non-critical. Spot instances can be used in this case that can help reduce costs up to 90%.

Rightsizing AWS Storage

AWS provides various types of storage and you can use appropriate storage based on how hot or cold you want your data to be stored. Various types of storage offered by AWS are Object, Block, File, Hybrid, Edge, and Backup.

Let's look at an example of object storage. Below are storage classes offered by AWS S3. Which object storage class you choose will depend on how frequently the data is accessed and what retention period you require.

1. Standard Storage – standard storage, regular costs, immediate access.
2. Standard Infrequent Access – reduced availability, reduced costs.
3. One Zone Infrequent Access – reduced redundancy, reduced costs.
4. Intelligent Tiering – for unknown access patterns, data is moved in and out of various classes based on file usage frequency.
5. Glacier – Long term storage, cheap, minutes or hours to retrieve.
6. Glacier Deep Archive – Longer-term storage, cheaper, hours to retrieve.

Lifecycle policies can be used to transition the old data to cheaper long-term storage.

Every type of storage comes with various levers which you can set appropriately to optimize your storage costs on AWS. I recommend making use of AWS Data Lifecycle Manager while provisioning your storage capabilities.

A Final note

There are many cost optimizations you can apply to resources in AWS, but how you apply these optimizations depends on your business priorities.

Mainly you need to decide if your focus is on costs or on time-to-market. The main bases of cost optimization are:

1. Time-based – to optimize over time.
2. Demand-based – to optimize based on demand/traffic.
3. Buffer-based – to optimize based on secondary workloads.

The cost optimization pillar of a well-architected framework suggests that while designing, developing, and deploying applications on AWS it is a good practice to keep cost optimization in perspective.

You should continually monitor your costs to reap the most benefits from your cloud investment.

In this post, we discussed various aspects of cloud cost optimization with respect to AWS Well-Architected Framework. If you have stuck with me up until now, cheers to you!

Hey, if you like this content, do consider subscribing, following, and sharing this blog post! Let'sDoTech, Instagram, Twitter, LinkedIn.

Businesses are trying to save money these days, so many are moving to the cloud. And a study suggests that the global public cloud services market will have grown 6.3% in 2020.

Cloud services revenue will go up to US$257.9 billion from US$242.7 billion in 2019. But as technologies grow more advanced, hackers are becoming better at using that tech to gain access to your mission-critical data. Cloud-based attacks rose 630% between January and April 2020.

With more data being stored in the cloud, businesses need to have robust security policies. They must also include best practices for dealing with data that's stored in cloud services like AWS.

With around 83% of enterprise workloads moving to the cloud by the end of 2020, there is a large amount of critical data that needs to be protected.

In this article, we will discuss some best practices that businesses should implement to protect the data they have moved to the cloud.

Go through the AWS documentation

The AWS docs detail the responsibilities of the client as well as those of AWS. The shared responsibility model states that AWS is responsible for protecting the infrastructure that runs the services offered on the AWS cloud.

The customer's responsibilities include the security configuration and management of the services they choose to use.

Source

Use Identity and Access Management

The AWS docs categorically state that the client needs to use Identity and Access Management (IAM) tools to safeguard their data. The AWS IAM tool allows you to manage users who will have access to the cloud.

IAM allows users to control access to certain resources. The tool also enables clients to create and manage AWS users and groups.

Source

Specific permissions are provided that allow or deny access to various AWS resources. If you wish to assign permissions to any one resource, you can create policies like the following:

• Actions: which service actions are allowed.
• Resources: for what resources you will allow those actions.
• Effect: whether you're denying or allowing access.
• Conditions: the requirements for which the actions will take effect.

Your webmaster can create one or more IAM users in the AWS account. You can create the users in the AWS Management Console, and you can add up to ten users at a time.

Use Multi-factor Authentication

While storing your data on AWS is fairly secure, you must still take precautions against unauthorized access to that data.

As suggested by AWS, you can use multi-factor authentication (MFA) for an extra layer of security. Using only your user ID and password may not be safe enough because hackers have developed many methods for breaking through your password.

Source

You can also control access to AWS's APIs using MFA. You can enable and manage a virtual MFA device for an IAM user in the AWS account.

Just login to the AWS Management Console and add MFA after choosing the user.

Have a Robust Security Apparatus in Place

Amazon's relational databases must be encrypted unless they're already encrypted at the storage level. IAM keys must be changed every three months.

You must also tag your EC2 instances logically as this can provide more information about the location of the instance and its usage. It also helps you maintain consistency in your environment.

Tagging can also help you manage your Amazon resources more effectively. Your webmaster can locate, classify, and identify the resources for their various needs.

Filtering can help you find and validate the standards of tagging undertaken in your organization. You can use automated tools to assist in the tagging process. There is a Resource Groups Tagging API to help you filter, manage and search tags.

Train your employees

While you are taking steps to enhance the security of your systems on AWS cloud, you must also organize periodic training sessions for your employees.

Studies show that hackers often target employees to gain access to protected networks. A small letdown in defenses can lead to a potential data breach that can damage your organization.

Your employees must be aware of the security protocols you're using to safeguard your data on AWS. If everyone in your organization is not aware of these protocols, you might have issues enforcing them.

When you introduce new processes, you should organize a short training session for your employees. You can also create self-learning videos and have a quiz at the end.

Use End-to-end Encryption

End-to-end encryption helps protect your data against unauthorized access - you just have to install an SSL certificate on AWS.

The AWS Management Console can use the SSL certificate between the console service endpoints and the client's browser. The SSL certificate will allow encrypted interaction between a browser and the webserver. The client browser can authenticate the identity of the control service endpoint.

Source

Using the HTTPS protocol can help protect your sensitive data. But you must also consider the additional resource requirements when your servers are handling hundreds of SSL/ TLS sessions.

To install the certificate, you need to convert the certificate and the intermediates to the PEM format. Then, you have to upload it to your AWS account and configure an HTTPS listener. Let's look at that process a bit more in-depth.

How to Install SSL on your AWS server

Once the CSR is generated and submitted to the certificate authority, the certificate authority verifies the details and issues an SSL certificate.

The private key file and certificate file both are in .CRT format. Once you have these two files, you need to upload them to the server.

• First Login to AWS and sign in onto AWS EC2.
• Then, browse the navigation menu >> click “Network Security” >> choose ‘Load Balancers’.
• Browse the main pane and select the Load Balancers icon while uploading the certificate.
• Now, click on the ‘Listeners’ tab and click on ‘Edit’ and ‘Add’.
• Choose HTTPS in the SSL certificate column and click on ‘change’ in the same column.
• Click the radio button “Upload a new SSL certificate to AWS Identity and Access Management (IAM)”. You can rename the certificate here too.
• In the private key field, paste the whole contents of the private key in the provided box “—–BEGIN RSA PRIVATE KEY—–” and “—–END RSA PRIVATE KEY—–”.
• In the public key certificate, paste the details of the certificate in the respective field “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–”.
• Finally, paste the certificate chain or CA Bundle.crt in the respective column “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–”.
• Click Save to complete the installation process. IAM will verify and confirm the installation after uploading the certificate.
• Restart your AWS EC2 instance to see the changes.

Have a Proper Recovery Policy in Place

You should have a robust backup and recovery policy in place. Even if your security is top-notch, backup and disaster recovery is critical.

AWS backup can help you find the right tools for a scalable backup and recovery solution. Their centralized backup process allows you to easily automate and centralize your backup.

Your webmaster can easily monitor this backup process for a number of AWS resources. Also, you can create backup policies in the AWS Backup console with only a few clicks.

To start your AWS backup, you have to sign into your AWS account and launch the AWS Backup console.

Next, create a backup plan and allocate the resources. The resources will get backed up based on your policy.

Once the resources are backed up, the user can monitor, restore, or modify them as necessary.

Below are few steps you should take to create a Disaster Recovery Plan (DRP):

• Create a set of instructions defining the rules and regulations relating to DRP. This is called Disaster Recovery Management Contingency Statement.
• Run a business impact analysis to get an idea of critical IT apps and components as well the impact of risks associated with the business.
• Take preventive, detective and corrective control measures that detect and minimize your risk ratio. Also, keeps security software updated, install fire alarms, run employee training sessions, and install network and server monitoring software.
• Find the application and business departments that will be impacted marginally during a failure (low failure assurance).
• Run tests to check whether changes occurred after each testing process. Management and employees should be trained for the disaster recovery process.

Use CloudTrail

CloudTrail helps with operational and risk auditing as well as compliance and governance of your AWS account.

Its services allow your webmaster to continuously monitor the activity on your AWS account. It also preserves a history of all activity across all your AWS services.

Source

CloudTrail will help you to track resources changes, analyze your security protocols, and detect unusual activity on your account. You must identify the data that is critical for your activities.

You can analyze CloudTrail's logs as they collect critical data about the usage of your AWS accounts. CloudTrail must be enabled across all geographies to give you these insights.

How to Set Up AWS CloudTrail

When you create a trail in your AWS account, it allows you to utilize other AWS services. With that, you can check the event data stored in CloudTrail's logs. CloudTrail comes by default when you create an AWS account.

Set Up Cloud Trail for All religions

Name your CloudTrail and choose ‘Yes’ for ‘Apply trail to all regions'. You should apply it to all regions even if you are just handling a single country. You can check other regions’ activity as a comparison to yours.

Select Event Log

You can log dissimilar events like management, data, and insight events. You should choose the event types based on your organization’s needs.

Enable Log File Validation

You should configure logs on your S3 bucket(s), which are by default encoded with SSE-S3 encryption. Under the storage location option, you can click on ‘Yes’ to ‘Enable log file validation’.

Configure CloudWatch Alarms

Once you create a trail in your AWS account, you can configure CloudWatch security by clicking the ‘configure’ button.

After that, enable IAM by clicking 'Create CloudWatch Alarms for Security and Network related API activity using CloudFormation template'.

When you do this, you will get a notification regarding any API security calls.

Now CloudTrail should be all set up.

Use AWS Trusted Advisor

AWS Trusted Advisor helps you keep an eye on all areas of your cloud services.

It watches over the cloud environment and the applications that run on it. It also allows you to scan your internal networks and compare them with AWS's standards.

You can access AWS Trusted Advisor from the AWS Management Console. All accounts have access to a few of the checks.

Businesses must subscribe to the Business or Enterprise levels of AWS support to get access to all the checks.

Source

You can get the following checks through AWS at no additional charge:

• Check IAM use: checks if the client is adhering to security best practices and whether users, groups, and roles have been created to control access to the AWS resources.
• Service limits check: Your position for the essential service limits for the different products is checked.
• MFA on root account check: checks if you use MFA.
• Security Groups (Specific Ports Unrestricted Check): This check is essential, and it informs the webmaster if access to your EC2 instances is too permissive. It helps prevent denial of service or hacking attacks.

Conclusion

As more and more businesses move their data onto the cloud, they have to take more precautions to manage that data safely and effectively.

This move to the cloud has resulted in more data breaches, and SSL certificates have become essential for secure AWS services.

I hope you've learned some best practices to help manage your AWS services in this article.

Static sites can host all kinds of websites from your personal portfolio, to a company landing page, or even a blog.

The main advantage of static sites is that they are simple to manage. They are also very cost-efficient. And with static sites, you don’t need complex content management services (CMS) that run on servers all the time (even if you don’t have any traffic).

In this post, you will learn how to host a static website in the AWS cloud in 4 steps, using AWS Amplify and Route 53. And the best part? It will cost you almost nothing every month.

What is a static website?

Static websites are website served from a storage server or a content delivery network (CDN). There is no need to have a running server creating the HTML files.

These websites are pre-built as HTML files that are stored somewhere on the internet and then served as they were built.

Static sites can have dynamic content, but it is handled on the client-side using JavaScript or some third party integrations using APIs.

Some benefits of using a static site are:

• They're easy to scale
• If you're using a CDN, loading times are fast
• They're cost-effective
• They're easy to maintain

For example, my personal website is a good example of a static site:

Marcia's personal website

What is AWS?

AWS stands for Amazon Web Services and is the most widely-adopted cloud platform. It has lots of different services to help you to develop and host your applications.

AWS also has data centers around the world and millions of customers use it.

Using the cloud for your applications you will lower the costs, help you become more agile, and allow you to innovate faster than if you were using your own on-premise servers.

Step 1 - Setup your AWS account

The first step in this process is to get an AWS account. You are going to host your static page in the cloud, and for that you must have a valid AWS account.

If you are just now creating your account the free tier should be sufficient for this project. The free tier will give you access to a lot of AWS services for free for the first 12 months.

For example, you will get 5GB of free storage. That is great, as we need storage to save our static site in the cloud.

Keep in mind that having an AWS account is free if you don’t use any services. You won’t be charged for creating the account, and if you don’t use the account nothing will be charged.

To create an AWS account you can follow the steps in this video:

Step 2 - Create your static site and configure it with AWS Amplify

Right now after reading that headline, you might be wondering, what is AWS Amplify?

AWS Amplify is an open-source framework that provides features to help you build cloud-native web and mobile applications. It has 4 components:

• the Amplify CLI
• the Amplify libraries
• the Amplify UI Components, and
• the Amplify Console.

The Amplify CLI helps you configure all the services you need to create a cloud backend to your application using the command-line interface.

The libraries help you integrate your client applications directly with the backend services.

The Amplify UI components are UI libraries specifically for React, React Native, Angular, Ionic, and Vue that will help you develop your cloud-native application easily.

Finally, the Amplify Console is an AWS service that provides a git-based workflow for continuous deployment and for hosting full-stack web and mobile applications.

In this post we are not going to use all the capabilities of AWS Amplify, we are just going to use the Console. But I recommend that you check out some tutorials on how to build more complex applications using AWS Amplify.

Create the static site

Now, you have everything you need to get started with your static site. For this demo, any static HTML will work. I just created a file called index.html and added this code inside of it:

<html>
    <h1>Hello Foobar</h1>
    <p>This is my super simple site</p>
</html>

Upload it to AWS Amplify Console

After we have the static site, the next step is to go to the AWS Amplify service in the AWS console.

Finding the AWS Amplify service in the AWS Console

Then when that service opens you will see something like this:

AWS Amplify console

Click the Connect app button and then you will be presented with this page:

Options for deploying your existing project

Then you can select Deploy without a Git provider and continue.

You will be presented with a page to manually deploy your app. There, you choose an app name and an environment name and then you can drag your application folder into the browser.

Starting a manual deployment in AWS Amplify

When the application finishes uploading you will see a message that says "Deployment successfully completed".

Now your website is hosted in the cloud. Go to the link that is under the Domain text. That will take you to your just deployed static site.

Step 3 - Buy a domain for your website

Now it is time to get a domain for your website. Sharing that Domain link is not very practical and a domain can be a simpler way to name your website.

For that you need to go inside your AWS account to a service called Route53.

Finding the service Route53 in the AWS console

Then when Route 53 opens you can go to a link that says Register domain, and a page like this appears.

Here you need to choose a domain name. Domains are billed yearly and they have different costs depending on the ending (like .com, .net, and so on).

After you choose a domain name, you can add it to the card. Then just follow the instructions that Route53 provides.

Step 4 - Configure the domain in your AWS Amplify app

Now that you have the domain, it is time to get back to your AWS Amplify app – the one you just configured.

Then in the left, you click on the Domain management link and this page opens:

Adding a domain to your site

The domain text box will suggest the domain you just registered. Just pick it, accept all the default configurations, and then click Save.

After that, you will be directed to a page where the domain and the SSL certificate will be configured. You don’t need to do anything in that step, just wait until everything is configured. It takes a while so be patient.

Now you are done, so you can go to your new domain and see your static page.

How to update this site

Now every time you need to change something in your static site you need to go to AWS Amplify and update the files. Basically you'll just drop the directory in the Amplify app.

Updating your static site

Conclusion

Now you have a static site hosted in the cloud. This site is very scalable and reliable. The site is hosted using the AWS CDN called AWS CloudFormation, so this will make your site very fast for your users.

The total cost of hosting after your AWS account is older than 12 months will be around $0.50 USD to $4 USD per month, depending on how big your site is and how much traffic you get.

The other yearly cost you will have is the domain that can start from $9 USD per year.

And if you want to make this a bit more automated I recommend looking at AWS Amplify automatic deployments using Github.

Thanks for reading.

I’m Marcia Villalba, Developer Advocate for AWS and the host of a YouTube channel called FooBar where I have over 250 video tutorials on Serverless, AWS and software engineer practices.

• Twitter: https://twitter.com/mavi888uy
• Youtube: https://youtube.com/foobar_codes

• A little about AWS
• What are the benefits of serving from S3 and CloudFront?
• Before we start, you’ll need an AWS account
• Storing your website on S3
• Serving your website on S3
• Distributing your website on CloudFront
• Custom domain names
• Advanced AWS Usage
• Resources

A little about AWS

If you’re not familiar, AWS (Amazon Web Services) is a cloud service provider that gives developers opportunities to build pretty much anything they can imagine in the cloud.

Though their services extend beyond the likes of machine learning and artificial intelligence, we’re going to stick with the entry level services for the purpose of this guide that will allow us to easily host an HTML website.

Types of AWS services available

Building a site with S3 and CloudFront is a common recipe that small and high scale companies across the web use, but let’s break down what each service actually does.

Object storage with S3

S3 (Simple Storage Service) acts as your hosting for your static website. Think of it like a hard drive in the cloud which we’re not able to use it for processing purposes, but rather for simple file storage and access.

List of files from a static site in an AWS S3 bucket

When an app or website is compiled in static form, this is all we need to serve it to the people visiting our site. The HTML is sent in the initial request “as is” (unless there’s processing with your provider) and any additional work occurs after the page loads in the browser usually by JavaScript. This allows us to take this simple (and cheap) approach by serving these files from S3.

Content Delivery Network with CloudFront

CloudFront works as a CDN (Content Delivery Network) that sits in front of your website, caching the files, and serving them directly to the people visiting your site.

CDN Diagram

Where you host and serve your website from, typically called the origin, is the main source of your files and can serve the website itself. But putting a CDN in front of it provides the people accessing your content a shorter and faster way to make their request.

What are the benefits of serving from S3 and CloudFront?

Given the rise in the JAMstack era, many services are popping up that provide similar services for static sites that make it really easy to deploy. Some even come with a generous free tier like Netlify and Zeit!

But sometimes developers need a little bit more control over their services or they need to integrate into a larger cloud pipeline that’s already 99% percent in AWS, which is exactly where S3 shines. Also, chances are, during your first year you might still qualify for AWS’s free tier.

Fitting in to the AWS Well-Architected Framework

As a lead provider in cloud services, AWS has published many guides to help developers and teams strive for excellence in their solutions in terms of performance, cost, and security.

One particular guideline is their 5 pillars of what they describe as a “well-architected" infrastructure.

AWS Well-Architected Framework

By default, we check all of these boxes with our hosting solution by using S3 and CloudFront. Out of the box, the HTML and assets you serve will be fast, cheap, secure, and reliable.

The beauty of static and JAMstack sites

Building on top of the pillars, what you’re actually serving is a static HTML file and group of assets that won’t require any type of rendering resources on the initial request. Before this, a common problem was having to worry about a site crashing due to heavy load. But with S3 and CloudFront, your website is infinitely scalable.

On a similar note, when that server scales up as it's trying to serve millions of hits on your post that went viral, so will your costs. Serving a static site is cheap and can greatly reduce the cost associated with running a web server.

Before we start, you’ll need an AWS account

To work through this guide, you’ll need an AWS account. Luckily, it's free to create an account – you’ll only pay for the services used.

On top of that, AWS provides a generous free tier for some of its services. Some services provide only 12 months of a free tier (like S3) where others are always eligible for the free tier (like Lambda), so make sure to do your homework so you don’t rack up an unexpectedly high bill.

To create your account, head over to the AWS website and then continue on to get started: https://aws.amazon.com/.

Storing your website on S3

To get started, we’re going to begin with a simple HTML file that will serve as our website. This will allow us to focus more on the process of hosting rather than the intricacies of the website itself.

Creating our website file

Begin by creating a new folder called my-static-site. Inside that folder, let's create a new file called index.html and add the following to the file:

<!DOCTYPE html>
<html lang=“en”>
<head>
  <meta charset=“UTF-8”>
  <meta name=“viewport” content=“width=device-width, initial-scale=1.0”>
  <title>My Static Website</title>
</head>
<body>
  <h1>Hello World!</h1>
  <p>This is my static website. ?</p>
</body>
</html>

If you open this file from your computer in your favorite browser, you should now be seeing this.

Hello World! Opening a local webpage

Creating a new bucket

Head on over to your AWS account, log in, and navigate to your S3 console.

Once there, let’s create our bucket by clicking on the blue Create bucket button:

Creating a bucket in AWS S3

The first thing AWS wants us to do is enter a Bucket name. The bucket name must be globally unique, meaning, the name you use can be the only one in the world, so let’s try something like [yourname]-static-website, where I’ll use colbyfayock-static-website.

Naming a bucket in AWS S3

Next, let’s set the Region. This is the geographic location where AWS will host the bucket and your website. You’re probably fine with the default, but if you’d like, you can select the location closest to you if it’s permitted. Since I’m in Virginia, I’m going to stick with my default of US East (N. Virginia).

Setting the region of a bucket in AWS S3

Finally, hit the Create button on the bottom left of the page.

Note: even if you use the [yourname]-static-website pattern, there’s a chance the name will be taken. If it’s taken, AWS will show an error stating “Bucket name already exists,” at which point you’ll want to try a new name of your choosing.

Alternatively, you can hit Next for advanced usage, but for this guide, we’re okay with all of the defaults S3 provides.

If successful, you should now see your bucket in the list on the S3 console dashboard.

New bucket in AWS S3

Uploading your website to the bucket

Let’s navigate to our new bucket by clicking the row of our bucket. You’ll be greeted with a message stating “This bucket is empty. Upload new objects to get started,” so that’s what we’ll do.

Click the Upload button to get started.

Uploading files to AWS S3

You’ll then see a popup that will ask you to upload a file. Click on the Add files button and select your index.html file we created earlier.

Once selected, click the Upload button on the bottom left.

Selecting files to upload in AWS S3

And now your file is uploaded to S3!

Serving your website on S3

If you try to navigate to your index.html file and open it, you’ll notice a big ugly "Access Denied" message.

Access Denied to bucket file

This is because your file doesn’t currently have the permissions and settings necessary to serve the file to the public, so let’s fix that.

Setting up your bucket as a website

Navigate to the Properties tab inside of your bucket, then click Static website hosting.

Setting up an AWS S3 bucket for statice website hosting

Once there, we want to do a few things:

• Note down the Endpoint at the top of the block. We’ll use this to access our site later (you can always find this here again)
• Select the “Use this bucket to host a website” option
• Enter index.html in the Index document field
• Finally hit Save

Configuring an AWS S3 bucket for static website hosting

Setting up your bucket policy and permissions

Next, navigate to the Permissions tab. Here we’ll want to do 2 things: unblock all public access and add a Bucket Policy.

First, on the main page, let’s click Edit to unblock all access.

Configuring an AWS S3 bucket permissions

Then, uncheck the “Block all public access” checkbox and hit Save.

Allowing public access to an AWS S3 bucket

AWS will ask you to confirm these settings, as this may not always be what you want to do with your bucket. But for the purposes of hosting a website, we want the whole world to see, so type in the word “confirm” and hit the Confirm button.

After confirming, click the Bucket policy button and you’ll be taken to a text editor.

In this text box, we’ll want to paste the following snippet. Within this snippet, make sure to replace [your-bucket-name] with the name of your bucket, otherwise you will not be able to save this file.

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

This policy states that it’s allowing the public to perform a GetObject request on the S3 resource, which is your S3 bucket.

Setting up a public policy for an AWS S3 bucket

After you add the policy, click the Save button. Your should now see a message stating "This bucket has public access.”

Previewing your new bucket website

If you noted down the Endpoint from your Properties page, you can now visit that address to see your website. The endpoint should look like this:

http://[your-bucket-name].s3-website-[region-id].amazonaws.com

If you didn’t, jump back up a few steps to remind yourself how to find it or look under the Properties tab.

Hello World! Opening an AWS S3 website

Congrats, you're halfway there! ?

Distributing your website on CloudFront

Now that we have our static website being served from a bucket on S3, let’s take it up another level and serve it across the world using CloudFront.

Creating a CloudFront distribution

Navigate to your CloudFront dashboard and click the Create Distribution button.

Creating a new distribution in AWS CloudFront

Next, select Get Started under the Web delivery method.

Getting started with an AWS CloudFront distribution with Web delivery

Here, we’ll enter a few custom parameters to get our distribution set up.

Click into the Origin Domain Name field. Once selected, a dropdown list should appear where you can select the S3 bucket you just created. Go ahead and select your S3 bucket.

Setting the origin domain name in AWS CloudFront to your bucket

While you can customize most of the settings to your liking, for our purposes, we’re going to leave all as their default values except for one.

Scroll down to the Default Root Object field and type index.html.

Setting the Default Root Object for a distribution in AWS CloudFront

After, scroll down to the bottom and click Create Distribution in the bottom right.

Creating an AWS CloudFront distribution

Previewing your new CloudFront distribution

After hitting the Create button, it will take some time for your distribution to be created and set up. You’ll notice on the CloudFront Distributions list page that the Status of your new distribution is In Progress.

AWS CloudFront distribution deployment is In Progress

Once this completes, it will say Deployed. Then you can find your Domain Name in the same row.

AWS CloudFront distribution is Deployed

Using the value in the Domain Name column, open your distribution in your browser and success! You now are viewing your S3 bucket through CloudFront’s distribution network.

Hello World! Opening an AWS CloudFront website

Custom domain names

While most of us will probably want to use a custom domain name with our website, we’re not going to dive too deep into that this guide, as there are many ways to set that up depending on where you purchase your domain name.

However, here are a few things to consider.

HTTPS / SSL Certificate

If you’re creating your CloudFront distribution to use with a custom domain name, you'll most likely want to configure your distribution with an SSL certificate using AWS’s Certificate Manager. Alternatively you can provide your own certificate with tools like Let's Encrypt, but by using ACM, AWS makes it easy to pull in the records for use with your distribution.

Once in ACM, you’ll want to configure the certificate, map what domains and subdomains should match (typically *.domain.com), and then create your certificate to use with your distribution.

To get started, you can check out the AWS guide for requesting a public certificate.

CNAMEs and Aliases

A common approach to setting up a custom domain is to use a CNAME. CloudFront makes this pretty painless, as you’ll add it as a configuration option when you’re configuring your distribution.

To get started with setting up a CNAME in CloudFront, see the AWS guide.

If you’re using Route53 to manage your DNS, you can then set up an A record (alias) to point to your distribution. You can learn more using this guide.

Advanced AWS Usage

For this guide, we walked you through setting up a new static website and app using the AWS console. But whether you want to learn more, improve your deploy efficiency, or want to automate this process, you’ll want to take a it a step further with the AWS CLI or CloudFormation.

While we won’t walk you through how to use these tools here, we’ll get you started with a little bit of an idea of what you’re up against.

AWS CLI

The AWS CLI allows someone to perform AWS operations from the command line. This can be incredibly powerful when you want to script out your resource creation or if you simply prefer to do all of your work from the terminal.

Once set up locally, you’ll be able to perform actions like creating a bucket using the following command:

aws s3api create-bucket —-bucket [your-bucket-name] —-region [bucket-region]

To get started, check out the AWS CLI Github page or the AWS CLI User Guide .

AWS CloudFormation

AWS preaches “infrastructure as code.” It’s the idea that you can spin up your infrastructure using something that’s written in a file, where in this particular case, it would be a CloudFormation template. This allows you to have a repeatable process that will be the same each time you perform the deploy.

CloudFormation allows you to set up a configuration file that will deploy the services and resources of your choosing by pointing to that file with the CLI or by uploading it in the console.

Here’s an example from AWS of what that looks like for a static S3 bucket that could serve as a website.

AWS CloudFront template example

To get started, check out AWS’s CloudFormation example templates or their Get Started guide.

Resources

If you’re interested in getting deeper into the AWS ecosystem, here are a few resources to get started:

• AWS Certified Cloud Practitioner Training 2019 - A Free 4-hour Video Course (freeCodeCamp.org)
• Introducing The #AWSCertified Challenge: A Path to Your First AWS Certifications (freeCodeCamp.org)
• 10-Minute Tutorials (AWS)
• A Cloud Guru (Paid courses)
• AWS Case Studies (AWS)

Introduction

Elastic Kubernetes Service (EKS) is the fully managed Kubernetes service from AWS. It is deeply integrated with many AWS services, such as AWS Identity and Access Management (IAM) (for authentication to the cluster), Amazon CloudWatch (for logging), Auto Scaling Groups (for scaling worker nodes), and Amazon Virtual Private Cloud (VPC) (for networking). Many companies trust Amazon EKS to run their containerized workloads.

EKS uses IAM to provide authentication to your Kubernetes cluster (via the aws eks get-token command, or the AWS IAM Authenticator for Kubernetes). For authorization it relies on native Kubernetes Role Based Access Control (RBAC). IAM is used for authentication to your EKS Cluster. And you can manage the permissions for interacting with your cluster’s Kubernetes API through the native Kubernetes RBAC system.

How to create an IAM User

Go to your AWS Console where you will find the IAM service listed under the “Security, Identity & Compliance” group. Inside the IAM dashboard click on the Users tab and click the “Add User” button.

Create a new user and allow the user programmatic access by clicking on the "Programmatic access" checkbox. You do not need any particular permission for your user to access EKS. You can go ahead without selecting any permission.

After the user is created, you will have access to the user's Access Key ID and Secret Access Key. You will be required to use these keys in the next step.

Configure the AWS CLI

Configuring your AWS CLI with a new user is as simple as running the aws configure command and providing the AWS Access Key ID and the AWS Secret Access Key. The Default region name and Default Output format are optional, though.

$ aws configure --profile eks-user
AWS Access Key ID [None]: AKIAI44QH8DHBEXAMPLE
AWS Secret Access Key [None]: je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
Default region name [None]: us-east-1
Default output format [None]: text

Once configured you can test to see if the user is properly configured using the aws sts get-caller-identity command:

$ aws sts get-caller-identity --profile eks-user

If the user is properly configured with the aws cli utility you should see a response like the one shown below:

{
    "UserId": "AIDAX7JPBEM4A6FTJRTMB",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/eks-user"
}

Creating a Role and RoleBinding for the user

With your IAM user properly configured, you can go ahead and create a role for the user. This snippet of code creates a role named eks-user-role with a modest list permission to the pods resource in your cluster.

kind: Role
metadata:
  name: eks-user-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list"]

Save the above snippet of code in a file and then apply the Role to your Kubernetes cluster:

$ kubectl apply -f role.yaml

With the role configured you need to create a corresponding RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: eks-user-role-binding
subjects:
- kind: User
  name: eks-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: eks-user-role
  apiGroup: rbac.authorization.k8s.io

Save the above snippet of code in a file and then apply the Role Binding to your Kubernetes cluster:

$ kubectl apply -f role-binding.yaml

Adding the user to the aws-auth configmap

If you want to grant additional AWS users or roles the ability to interact with your EKS cluster, you must add the users/roles to the aws-auth ConfigMap within Kubernetes in the kube-system namespace.

You can do this by either editing it using the kubectl edit command:

$ kubectl edit configmap aws-auth -n kube-system

Or by importing the aws-auth ConfigMap and applying the changes:

$ kubectl get configmap aws-auth -n kube-system -o yaml > aws-auth.yaml

Add the user under the mapUsers as an item in the aws-auth ConfigMap:

data:
  mapUsers: |
    - userarn: arn:aws:iam::123456789012:user/eks-user
      username: eks-user
      groups:
      - eks-role

If the user is properly configured you should be able to list pods in the Cluster:

$ kubectl get pods --as eks-user

The --as flag impersonates the request to Kubernetes as the given user. You can use this flag to test permissions for any given user.

Configuring permissions for the user

The role which you defined previously only had permission to list pods. The eks-user cannot access any other Kubernetes resources like Deployments, ConfigMaps, Events, Secrets, logs or even shell into a given pod.

In a real-world scenario, you will need to provide permissions to a user to access the required resources. The below snippet of code provides access to resources such as events, pods, deployments, configmaps and secrets.

rules:
- apiGroups: [""]
  resources: ["events"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods", "pods/log", "pods/exec"]
  verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["list", "get", "create", "update", "delete"]

Add the above permissions to the role.yaml file and apply the changes, using kubectl apply -f.

Test, test and test!

Now go ahead and test to see if the permissions have been properly applied to the eks-user. You can test the same using the above mentioned --as USERNAME flag or set the eks-user as the default profile for the aws cli.

$ export AWS_PROFILE=eks-user

Once configured you can test to see if the user is properly configured using the aws sts get-caller-identity command:

$ aws sts get-caller-identity

You should see a response like the following, indicating the user is properly configured with your aws cli utility:

{
    "UserId": "AIDAX7JPBEM4A6FTJRTMB",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/eks-user"
}

Test the permissions of the user with the below-mentioned commands.

$ kubectl get pods
$ kubectl get secrets
$ kubectl get configmaps
$ kubectl get deployments
$ kubectl logs <pod-name>
$ kubectl exec -it <pod-name> sh
$ kubectl create configmap my-cm --from-literal=db_username=<USERNAME> --from-literal=db_host=<HOSTNAME>
$ kubectl create secret generic my-secret --from-literal=db_password=<SOME_STRONG_PASSWORD>

Simply put, the eks-user user should be able to perform all the actions specified in the verbs array for pods, secrets, configmaps, deployments, and events. You can read more about it here Kubernetes Authorization Overview.

Can-I or Not

You can use auth can-i to check if you have permission to a resource. To see if you have the permission to get pods simply run:

$ kubectl auth can-i get pods

The answer will be a simple yes or no. Amazing, isn’t it?

Wanna check if you have cluster-admin permissions? Fire this:

$ kubectl auth can-i "*" "*"

Wrap up

EKS provides the Kubernetes control plane with the backend persistence layer. The Kubernetes API server and the master nodes are provisioned and scaled across various availability zones, resulting in high availability and eliminating a single point of failure. An AWS-managed Kubernetes cluster can withstand the loss of an availability zone.

Access and authorization controls are critical for any security system. Kubernetes provides us with an awesome robust RBAC permission mechanism.

Originally published at faizanbashir.me

I recently started a personal project where I wanted to use a database in the cloud. There are quite a few to choose from. My main criteria was that it be something low or no cost.

Eventually I decided on Firestore, using the Spark Plan. This plan gives me 5Gb of storage, with 50K reads and 20K writes per day for free, which at the time seemed like plenty. I soon learned that a little carelessness can blow past those transaction limits pretty fast.

Firestore is a NoSQL document store database. Each NoSQL database is different and my a learning curve was steeper than expected. As you know, the best teacher is adversity, and I made my share of mistakes early on. One too many, though, and I’d hit the read or write limit of the plan, which sometimes could happen within an hour or two. Then it was time to call it a day.

Things are better now, so I offer these lessons learned:

Do start with the free plan

_Photo by [Unsplash](https://unsplash.com/@frankiefoto?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">frank mckenna / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Yes, it is easy to overshoot the plan’s limits, but those occurrences will force you to learn to be efficient with your reads and writes. You will become more cost-conscious of sequencing multiple database operations in an efficient way.

Start with a small dataset

_Photo by [Unsplash](https://unsplash.com/@rayhennessy?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Ray Hennessy / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

This may seem obvious, but by small I mean less than 100 documents total. On my project, I first created a collection with 10K documents. I later realized that I made a mistake in the data I loaded, fixed that, found another, went to fix that, but… TRANSACTION_RESOURCE_LIMIT_EXCEEDED. Welp, done for the day.

Take time in the design of your data model

_Photo by [Unsplash](https://unsplash.com/@kellysikkema?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Kelly Sikkema / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Like the carpenter’s axiom: “Measure twice, cut once”, you don’t want to be adjusting your JSON document fields and structure piecemeal. Oh, you will of course, but you’ll save yourself some transactions by practicing a little foresight. Write out a schematic of documents, their fields, and their relationships first. Visualization is the key to happiness.

Test and verify your data loading scripts

_Photo by [Unsplash](https://unsplash.com/@nasa?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">NASA / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

You’ll need scripts to populate the database from some other source. That is the time to:

• verify what you loaded is what you expected
• correctly handle the no-data case for fields

I made mistakes in both cases. First, when I loaded some string data into a document field, I hadn’t immediately noticed that those strings had quotes already, so the stored strings had embedded quotes. It didn’t seem that serious an issue, but it became a pain later when writing and testing searches on that field. Because there were a lot of documents, I spent a sizable portion of my daily write quota to clean that up.

In the second case, I discovered that Firestore has no mechanism for determining the existence of a property in a document (there is no undefined check). There is an exists test for documents, but not for document fields. The best practice is to populate missing data fields with null, and then do null equivalence tests in a where clause to find documents with “missing” properties.

What a small dataset won’t teach you

_Photo by [Unsplash](https://unsplash.com/@goodfreephoto_com?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Good Free Photos / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Once you worked out kinks on the small dataset, it is time to graduate to a larger one. With more documents to process, things like query efficiency, pagination and batch requests become important.

Read in chunks, write in chunks

_Photo by [Unsplash](https://unsplash.com/@picoftasty?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Mae Mu / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Batch operations allow for multiple read/writes on the database in a single transaction. This means that if any write operation fails, then all writes fail, and the database data retains its original state. Each operation in a batch counts toward the total read/write quotas, so as such it doesn’t help usage quotas. Also, when writing via batch operations, be aware there’s a 500 operation limit per batch.

Be careful when correlating two documents (i.e., for every A document, there is an association by reference to a B document). Don’t fetch all of one first, then iterate through the other. That’s a good way to chew up the transaction quota when debugging.

It is better to fetch a subset of the first collection, then iterate through it document by document. Associate these documents with document in the second collection by fetching one that matches criteria. Continue to do this until the entire first collection has been fetched. When debugging, you can verify everything looks like it is working correctly and, if not, kill the process before a lot of transactions are run.

How to limit query results

_Photo by [Unsplash](https://unsplash.com/@will0629?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Will Porada / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Firestore’s query language isn’t as richly expressive as SQL is, but there are still a number of ways to restrict your queries so that you don’t overfetch data. Although technically there is no size limit for a POST response body, in practical terms there is.

Some mechanisms for limiting query results:

where and compound where

You can chain multiple where clauses together, similar to adding conditional expressions to a single where clause in SQL.

citiesRef.where('state', '==', 'CO').where('name', '==', 'Denver');

limit and ranges

You can limit the number of documents returned by a query by using chaining a limit clause at the end of the query object.

let biggest = citiesRef.where('population', '>', 2500000)  .orderBy('population').limit(2);

You can also specify a range of records to retrieve via startAt/endAt or startBefore/endBefore constraints, which allows you to do cursor-based pagination.

let docRef = db.collection('cities').doc('SF');

return docRef.get().then(snapshot => {  let startAtSnapshot = db.collection('cities')    .orderBy('population')    .startAt(snapshot);  return startAtSnapshot.limit(10).get();});

in array query

You can look for specific matches in an array. This is good for enumerated values.

const usaOrJapan = citiesRef.where('country', 'in', ['USA', 'Japan']);

As demonstrated, it is possible to work within the limitations of the Spark Plan as you learn about Firestore. It’s free, which is always a good place to start.

Hiya folks!

In this tutorial I’ll show you how to host a static website with HTTPS on AWS with a custom domain. All this is possible using AWS free tier.

However, the services we are going to use do incur some small charges. Generally speaking these shouldn’t exceed $1/month.

We’ll be using a combination of the following AWS services:
—S3
— Route53
— Certificate manager
— CloudFront

Let’s get into it!

Setup your S3 buckets

First, you’ll need two S3 buckets, both should match your custom domain name with the second including the www subdomain.

Bucket 1: mywebsite.com
Bucket 2: www.mywebsite.com

The first bucket (mywebsite.com) is the main bucket for your site. This contains all your files and assets for your static website.

Next we setup this bucket for static site hosting. You can find this under the Properties tab of the bucket, and we’re going to keep the defaults provided here with the index of the site set to index.html.

We also need to make this bucket publicly accessible as a user’s browser will need to access the bucket’s files in order to render the website. We can do this by setting a Bucket Policy under the Permissions tab.

{       "Version": "2012-10-17",       "Statement": [        {            "Sid": "PublicReadGetObject",            "Effect": "Allow",            "Principal": "*",            "Action": "s3:GetObject",            "Resource": "MY_BUCKET_ARN"        }    ]}

This is a simple policy that will only allow public read access of objects in the bucket. Now, if you head to the endpoint defined in the static hosting config of the bucket, you should see your website.

Progress! But we can do better than that.

The second bucket (www.mywebsite.com) we will leave empty but configure to redirect to our first bucket using HTTP as the protocol (we’ll make it HTTPS later).

Redirect requests back to the main bucket using HTTP protocol

Your buckets are now ready to go!

Configure Domains with Route53

So your website is up and running but only accessible via the bucket endpoint and not your custom domain. Let’s change that.

Head to Route53. If you’ve registered your domain with the Amazon Registrar you should see that a hosted zone has been setup for you with two record sets. One for Name Server (NS) and one for SOA.

All we need to do is to create two more record sets to point to the S3 bucket endpoints.

For each record set:
— Type: A — IPv4 address
— Alias: Yes
— Alias Target: the S3 website endpoint that matches what you set for Name.

Creating a record set for www subdomain

Now we can head to the custom url…and voilà!
We’re almost there, but there’s one last thing we’re missing…

Note: If your domain is registered with another domain registrar (not Amazon) you’ll need to follow some different steps to set this up. Usually you’ll need to add a CNAME record with a value of the main S3 buckets endpoint.

Troubleshooting:
If you deleted the hosted zone Amazon created when you first registered the domain (I’ve done this because hosted zones do incur some charges), you’ll need to create a new hosted zone from scratch.

1. Select “Create Hosted Zone” and set the domain name, for example “mywebsite.com”
2. This will generate some new record sets for types NS and SOA.
3. Go into your registered domain and update the Name Servers values to those generated in the new NS record set.

Requesting a Certificate

Awesome, the site is now hosted using the custom url! However we can only access it via HTTP protocol.
We should always ensure our sites are secured using HTTPS protocol. This protects our site and users from malicious injection attacks and guarantees authenticity.

Head to Certificate Manager in AWS Console and request a new public certificate (this is free). You’ll be prompted to enter the domain names you wish to secure.

Before the certificate can be issued, Amazon needs to be able to verify that you own the specified domains.

You can choose from two verification methods: Email or DNS.

Email is generally simpler, but you’ll need to ensure you can access the email used to register the domain. Alternatively, if you used Amazon Registrar and Route53, you can select the DNS method. This requires you to add some specific record sets to the hosted zone, but this is mostly automated for you so it’s quite simple.

It can take a few minutes for the certificate to be issued after validation.
When its all done we can continue to the final step!

Configuring CloudFront

For the final step we are going to use CloudFront which allows us to use the new SSL certificate to serve the website with HTTPS. CloudFront also speeds up the distribution of web content by storing it at multiple edge locations and delivering from the closest edge location to a user.

We need two new web distributions, one for each S3 bucket. Head to CloudFront in the AWS Console and create the first web distribution.
There are lots of settings available to create a web distribution, but for the basics we only need to change five:

1. Origin Domain Name: Set this to the S3 website endpoint for one of the buckets. Important: This field will give you some auto-complete options with your S3 bucket names. However, using these can cause issues with redirecting to the bucket endpoint. So instead use the bucket endpoint directly.
2. Origin Id: This populated for you when you enter Origin Domain Name.
3. Viewer Protocol Policy: Set to “Redirect HTTP to HTTPS”.
4. Alternate Domain Names: This should match the name of the S3 bucket you’re pointing to. For example “mywebsite.com”.
5. SSL Certificate: Select “Custom SSL Certificate” and select your new certificate from the dropdown.

Do this again for the second S3 bucket.

The distributions can take a while to spin up, so while we wait, let’s do the finishing steps.

Back in S3, go to your secondary bucket (www.mywebsite.com), in the Properties tab and under Static Website Hosting set the redirect protocol to HTTPS.

Finally, head back to Route53. We need to update the custom A records we created to now target the CloudFront distributions rather than the S3 buckets. For each record, change the Alias Target and select the CloudFront distribution available in the dropdown.

Note: Again, if you are using another DNS service you’ll need to go update the CNAME record from there to point to the CloudFront domain name.

Huzzah!

And there you have it! Your beautiful website is now available at the custom domain and served with HTTPS!

_[From Giphy](https://giphy.com" rel="noopener" target="blank" title=")

Thanks for reading! I hope this guide was useful and enjoyable, I’d love to know if you found it helpful.