That's how it works:

SageMaker controls the provisioning and management of the compute resources when you construct a serverless endpoint.

After that, you may ask the endpoint for inferences and get model predictions in return.

You only pay for what you use because SageMaker adjusts the computing resources up or down as necessary to handle the volume of your requests.

Let's begin writing some demo code:

import sagemaker
import boto3
sess = sagemaker.Session()
# sagemaker session bucket -> used for uploading data, models and logs
# sagemaker will automatically create this bucket if it not exists
sagemaker_session_bucket=None
if sagemaker_session_bucket is None and sess is not None:
    # set to default bucket if a bucket name is not given
    sagemaker_session_bucket = sess.default_bucket()

try:
    role = sagemaker.get_execution_role()
except ValueError:
    iam = boto3.client('iam')
    role = iam.get_role(RoleName='sagemaker_execution_role')['Role']['Arn']

sess = sagemaker.Session(default_bucket=sagemaker_session_bucket)

print(f"sagemaker role arn: {role}")
print(f"sagemaker bucket: {sess.default_bucket()}")
print(f"sagemaker session region: {sess.boto_region_name}")

Create Inference HuggingFaceModel for the Serverless Inference Endpoint

Our serverless endpoint runs on the distilbert-base-uncased-finetuned-sst-2-english model. This model is a DistilBERT-base-uncased fine-tune checkpoint tuned on SST-2 which is used for topic classification.

from sagemaker.huggingface.model import HuggingFaceModel
from sagemaker.serverless import ServerlessInferenceConfig

# Hub Model configuration. <https://huggingface.co/models>
hub = {
    'HF_MODEL_ID':'distilbert-base-uncased-finetuned-sst-2-english',
    'HF_TASK':'text-classification'
}

# create Hugging Face Model Class
huggingface_model = HuggingFaceModel(
   env=hub,                      # configuration for loading model from Hub
   role=role,                    # iam role with permissions to create an Endpoint
   transformers_version="4.17",  # transformers version used
   pytorch_version="1.10",        # pytorch version used
   py_version='py38',            # python version used
)

# Specify MemorySizeInMB and MaxConcurrency in the serverless config object
serverless_config = ServerlessInferenceConfig(
    memory_size_in_mb=4096, max_concurrency=10,
)

# deploy the endpoint endpoint
predictor = huggingface_model.deploy(
    serverless_inference_config=serverless_config
)

An HuggingFacePredictor object that can be used to request inference is returned by the.deploy() method. It's simple to submit queries to your endpoint and receive responses thanks to this HuggingFacePredictor.

data = {
  "inputs": "the mesmerizing performances of the leads keep the film grounded and keep the audience riveted .",
}

res = predictor.predict(data=data)
print(res)

Clean up

predictor.delete_model()
predictor.delete_endpoint()

When trying to automate the entire process, this handover causes a disconnect that makes things more difficult. More importantly, this separation frequently affects the overall delivery schedule and delays the project's effective conclusion.

Using a Continuous Integration and Continuous Delivery (CI/CD) approach, the main objective of this article is to illustrate one of the ways to close this apparent gap in model deployment and further automate the process. By demonstrating how an ML practitioner can better communicate with the application development and operations teams, I'll also introduce you to the idea of an agile, cross-functional team. By the end of the chapter, you will see how this methodology can consistently produce production-grade ML models and deploy them. We will concentrate on the following subjects in order to achieve this: CI/CD methodology introduction; automating machine learning with CI/CD; building a CI/CD pipeline on AWS

Introducing the CI/CD methodology

A highly well-liked mechanism for automating the creation and release of software into production is the CI/CD pattern. The basic idea behind this method is to deploy changes to production automatically and seamlessly after making incremental, dependable, and frequent modifications to the software code. Although this discipline has been around for a while and is used by many DevOps engineers, MLOps, or Machine Learning Operations, is beginning to gain traction within the ML practitioner community. Before delving into how this methodology might be used for ML, let's become familiar with the individual parts of the procedure, beginning with CI.

Creating or updating source artifacts

Other than initiating the full CI process, the source artefacts stage doesn't really do any particular tasks. In essence, this step acts as a repository for the source code or software components that make up the finished application. The pipeline begins when new software artefacts (such as new features) or updated software artefacts (such as bug patches) are added to this repository.

For instance, application developers contribute updates to the shared version control system (such as GitHub, Bitbucket, or AWS CodeCommit) when they modify the code, add new features, or correct application defects. These stored changes are called commits, with\seach commit having an associated description or message that describes why a particular\schange was done. To help other contributors understand what has been changed in the code and why, these commits summarise the history of all the modifications. A Pull Request can be opened by the developer after a commit has been made (PR).

Construction of pipeline assets

The various software artefacts (and their dependencies) are produced or compiled in the next stage of the pipeline. These assets, or assets that are specific to the current release or, to put it another way, assets that are specific to the current execution of the pipeline, are essentially the end product of building the source code artefacts into an asset that is specific to the current release. For instance, the build step can be used to create a Docker container image or to convert C++ code into a release binary.

Testing the pipeline assets

After the pipeline assets are constructed, the following stage of the pipeline involves testing them for functionality as well as integration into the larger design or application. At this level, developers use automated testing, testing scripts, or even a testing architecture (also known as a test environment or QA environment) to carry out system testing. This step's main objective is to ensure that built assets will work properly after being put into production. Application developers can ensure that the overall integrity of the solution, in its entirety, is preserved once it is released into production by testing the complete system.

Approving the release

The final step of the CI phase is to authorise the system or application for production once the integrity of the entire system or application has been tested. This step of the procedure can either include a human (or team) approving the test results, or it can be automated in cases when there are lots of code changes.

Creating a CI/CD pipeline on AWS

AWS offers a comprehensive collection of developer tools to meet the varied needs for hosting code as well as creating and delivering pipeline assets. We will leverage three key services from the AWS developer toolchain to build a CI/CD pipeline on AWS. We will use two additional services from the AWS development package to make the construction and automation of the pipeline even easier.

The following are the three essential elements of a CI/CD pipeline: • An element for keeping track of the numerous pipeline artefacts.

• A step in the construction of the various pipeline assets.

• A pipeline execution automation component.

AWS offers specialised services to meet the necessary capabilities of each of these three key components, particularly the following:

• AWS CodeCommit

• AWS CodeBuild

• AWS CodePipeline

• AWS CodeCommit is a cloud-based source code and version control service. In essence, it is the AWS-managed alternative to GitHub. CodeCommit used to store all the various pipeline and ML model artifacts.

• CodeBuild is the heart of the continuous integration phase of the CI/CD pipeline. This service is responsible for compiling or building the various artifacts into usable pipeline assets. In the case of ML release automation, CodeBuild builds the required model training and serves runtimes, as well as executing the data processing, model training, and model evaluation processes.

• AWS CodePipeline handles the continuous deployment phase of the CI/CD pipeline. This service contains the structure of the pipeline and is responsible for automating the task of releasing the trained model into production as a SageMaker hosted endpoint.

This post will introduce you to some of the AWS features that concentrate on machine learning (ML) solutions and ML automation.

The following topics will be covered: • Introduction to the AWS AI and ML landscape.

• Overview of SageMaker Autopilot.

• Using SageMaker Autopilot to overcome automation problems.

• Using the SageMaker SDK to automate the ML experiment.

Introducing the AWS AI and ML landscape

AWS offers a wide range of machine learning (ML) and artificial intelligence (AI) capabilities to its clients. AWS has collected and arranged these capabilities into what is often known as the AI/ML Stack in order to further aid its clients in understanding them. The main objective of the AI/ML stack is to offer the tools that a developer or an expert in machine learning could need, depending on their level of experience. In essence, it equips all developers, whether they are regarded as novices or experts, with AI and ML skills.

Overview of SageMaker Autopilot

The AWS service that offers AutoML capability to its users is called SageMaker Autopilot. The following SageMaker modules are pieced together by Autopilot into an automated framework to address the various AutoML requirements:

• SageMaker Processing: Using a streamlined and controlled experience, processing jobs handle the labor-intensive tasks and scalability requirements of organising, validating, and feature engineering the data.

• SageMaker Built-in Algorithms: SageMaker offers a number of pre-built algorithms that are suited to a variety of use case types, making it easier for ML practitioners to get started with model-building activities.

• SageMaker Training: Training jobs handle the labor-intensive scaling and provisioning operations related to setting up the necessary compute resources to train the model.

• Automatic Model Tuning: By enabling the ML practitioner to run numerous training jobs concurrently, each with a subset of the necessary parameters, model tuning or hyperparameter tuning scales the model tuning task. As a result, there is no longer a need to adjust, assess, and retrain the model in a sequential manner. In order to choose future hyperparameters that will better optimise the model, SageMaker model tuning by default creates a probabilistic model of the performance of previously used hyperparameters using Bayesian Search (although Random Search can also be used).

• SageMaker Managed Deployment: After an optimal model has been trained, SageMaker Hosting can be used to deploy a single model or a collection of models as a fully functional API for use by production applications in an elastic and scalable way.

These tools are connected by Autopilot to form an automated workflow. The raw data is the only component that the ML practitioner is required to provide. By just providing the data, Autopilot enables even a beginner in machine learning to automatically develop a model that is suitable for production.

Overcoming automation challenges with SageMaker Autopilot

• The difficulties associated with creating the optimal ML model, such as gathering and comprehending the data before creating the model that is most appropriate for the use case. • The difficulties brought on by the ML process itself, which is difficult, laborious, iterative, and continual.

For experimenting Sagemaker Autopilot, you can refer to this tutorial

SageMaker SDK Using for automating the ML experiment

The SageMaker SDK is essentially a higher-level SDK with an emphasis on ML exploration that utilises the base boto3 SDK. For instance, a machine learning practitioner would need to execute three different boto3 calls to deploy a model as a SageMaker hosted endpoint:

1. The machine learning practitioner must use the SageMaker training job's output artefact to instantiate a trained model. This is done by using the boto3.client("sagemaker") low-level SageMaker client's create model() method.
2. After that, the ML expert must construct a SageMaker hosted endpoint configuration that details the endpoint's extra configuration options as well as the underlying computer resources. The SageMaker client's create endpoint config() method is used for this.
3. The trained model is deployed with the endpoint settings using the create endpoint() method.

As an alternative, the ML practitioner might achieve the same result by executing the deploy() method on a model that has already been trained using the SageMaker SDK. The underlying model, endpoint setup, and endpoint deployment are all created by the SageMaker SDK. The SageMaker SDK greatly simplifies ML experimentation for the more seasoned ML practitioner. You will begin getting acquainted with the SageMaker SDK in the following part by working through an example to codify the AutoML experiment.

You can refere this link to implement your models using Sagemaker Autopilot and codify your Autopilot experiments.

An illustration of the CRISP-DM recommendations for designing a typical procedure that an ML practitioner might adhere to can be found in the graphic below:

After the data has been reviewed, the ML practitioner decides which modelling techniques are most appropriate for addressing the use case and extracting the most pertinent information from the data. These methods consist of the following:

1. Choosing the appropriate ML algorithm
2. Adding additional elements to the data (engineering new features) that can raise the general efficacy of the selected model.
3. Data separation into training and testing sets for model development and assessment

A model's suitability for use in production depends entirely on the quality of the data it was trained on. To extract the most pertinent features for model development and training, the data must be thoroughly evaluated and comprehended. Exploratory Data Analysis (EDA), which evaluates the statistical components of the data and may result in the creation of charts to better understand feature importance, can be used to achieve this. In order to help the trained model learn from these ideal properties, we may decide to collect additional vital data, delete uninteresting data, and maybe engineer new facets of the data.

In dealing with any problem, you have first do the following:

• Sourcing, ingesting, and understanding the data (EDA).
• Building the right model: In this stage, you have to select the most appropriate ML model / methodology to get the most accurate results / predictions.

Algorithms such as: • Linear regression • Support vector machines • Decision trees • Naïve Bayes • Neural networks

• Training the model:
• Evaluating the trained model We can proceed to the model evaluation stage of the ML process after the model has been trained. The trained model is now assessed against the goals and success criteria laid out in the business use case with the intention of determining whether or not the trained model is prepared for production. some metrics can be used for evaluation like RMSE.

Important different steps for ML engineer / practitioner to consider:

• Use another model: It's important to take into account entails creating a brand-new model utilising a totally different method that nonetheless adheres to the use case. The ML expert might, for instance, do research using a different supervised learning, regression-based technique. Depending on the method, the data may also need to be reorganised to better match the needed input format.

• Tuning the existing model Hence, this stage of the process is alsoreferred to as hyperparameter optimization (HPO).

• Deploying the optimized model into production Insofar as some ML practitioners choose not to include this step in their ML process, model deployment is something of a murky area. For instance, some ML experts might believe that their only responsibility is to present a production-ready ML model that addresses the business use case. Once this model has been trained, it is simply given to the teams or owners who are responsible for developing the application so that they may test and incorporate the model into the application. To ensure that the trained model interacts properly with the application, some ML practitioners will collaborate with the application teams to deploy the model into a test or Quality Assurance (QA) environment.

Although the model deployment step in the accompanying diagram is when the CRISP-DM approach comes to an end, the process is actually ongoing. Once the model has been put into use in a production application, it needs to be closely watched to make sure it doesn't stray from its intended use and to guarantee that it regularly makes correct predictions on previously unknown or brand-new data. The ML practitioner will be required to restart the ML process in order to reoptimize the model and make it generalise to this new input should this circumstance emerge.

Implement the SmallestInfiniteSet class:

SmallestInfiniteSet() Initializes the SmallestInfiniteSet object to contain all positive integers. int popSmallest() Removes and returns the smallest integer contained in the infinite set. void addBack(int num) Adds a positive integer num back into the infinite set, if it is not already in the infinite set.

class SmallestInfiniteSet:
    import heapq
    def __init__(self):
        self.summary = list(range(1, 1001))
        heapq.heapify(self.summary)
        self.deleted = set()

    def popSmallest(self) -> int:
        A = heapq.heappop(self.summary)
        self.deleted.add(A)
        return A

    def addBack(self, num: int) -> None:
        if num in self.deleted:
            self.deleted.remove(num)
            heapq.heappush(self.summary, num)

Return the number of good nodes in the binary tree.

# Definition for a binary tree node.
# class TreeNode:
#     def __init__(self, val=0, left=None, right=None):
#         self.val = val
#         self.left = left
#         self.right = right

class Solution:
    def goodNodes(self, root: TreeNode) -> int:

      def checkNode(node,val):
        if(node == None):
            return 0

        op = 0
        if(node.val >= val):
            op = 1

        val = max(val,node.val)
        return op + checkNode(node.left,val) + checkNode(node.right,val)

      return checkNode(root,root.val)

Each number in candidates may only be used once in the combination.

Note: The solution set must not contain duplicate combinations.

class Solution:
    def combinationSum2(self, candidates: List[int], target: int) -> List[List[int]]:
        candidates.sort()
        res = []
        n = len(candidates)

        def backtrack(cur, pos, target):
            if target == 0:
                res.append(cur.copy())
                # return

            if target < 0:
                return
            prev = -1

            for i in range(pos, n):
                if prev == candidates[i]:
                    continue

                cur.append(candidates[i])
                backtrack(cur, i+1, target-candidates[i])
                cur.pop()

                prev = candidates[i]


        backtrack([], 0, target)        
        return res

For example, "0.1.2.201" and "192.168.1.1" are valid IP addresses, but "0.011.255.245", "192.168.1.312" and "192.168@1.1" are invalid IP addresses. Given a string s containing only digits, return all possible valid IP addresses that can be formed by inserting dots into s. You are not allowed to reorder or remove any digits in s. You may return the valid IP addresses in any order.

class Solution(object):
    def restoreIpAddresses(self, s):
        res = []
        if len(s) > 12:
            return res

        def backtrack(i, dots, curIP):
            if dots == 4 and i == len(s):
                res.append(curIP[:-1])
                return

            if dots > 4:
                return

            for j in range(i, min(i+3, len(s))):
                if (int(s[i: j + 1]) < 256) and (i == j or s[i] != "0"):
                    backtrack(j + 1, dots + 1, curIP + s[i: j+1] + ".")


        backtrack(0, 0, "")
        return res

You are given an integer array nums representing the data status of this set after the error.

Find the number that occurs twice and the number that is missing and return them in the form of an array.

from collections import Counter

class Solution(object):
    def findErrorNums(self, nums):
        """
        :type nums: List[int]
        :rtype: List[int]
        """

        def findMissing(ns):
            for i in range(1, len(ns) + 1):
                if i not in ns:
                    return i


        c = Counter(nums).items()
        res = 0 

        for k, v in c:
            if v == 2:
                res = k
                break 

        return [res, findMissing(nums)]

Implement the Trie class:

Trie() Initializes the trie object. void insert(String word) Inserts the string word into the trie. boolean search(String word) Returns true if the string word is in the trie (i.e., was inserted before), and false otherwise. boolean startsWith(String prefix) Returns true if there is a previously inserted string word that has the prefix prefix, and false otherwise.

class TrieNode():
    def __init__(self):
        self.children = {}
        self.endOfWord = False

class Trie:
    def __init__(self):
        self.root = TrieNode()

    def insert(word):
        cur = self.root
        for c in word:
            if c not in cur.children:
                cur.children[c] = TrieNode()
            cur = cur.children[c]
        cur.endOfWord = True

    def search(word):
        cur = self.root
        for c in word:
            if c not in cur.children:
                return False
            cur = cur.children[c]
        return cur.endOfWord

    def startsWith(prefix):
        cur = self.root
        for c in prefix:
            if c not in cur.children:
                return False
            cur = cur.children[c]
        return True

To obtain target, you may apply the following operation on triplets any number of times (possibly zero):

Choose two indices (0-indexed) i and j (i != j) and update triplets[j] to become [max(ai, aj), max(bi, bj), max(ci, cj)]. For example, if triplets[i] = [2, 5, 3] and triplets[j] = [1, 7, 5], triplets[j] will be updated to [max(2, 1), max(5, 7), max(3, 5)] = [2, 7, 5]. Return true if it is possible to obtain the target triplet [x, y, z] as an element of triplets, or false otherwise.

class Solution:
    def mergeTriplets(self, triplets: List[List[int]], target: List[int]) -> bool:
        good = set()

        for t in triplets:
            if t[0] > target[0] or t[1] > target[1] or t[2] > target[2]:
                continue
            for i, v in enumerate(t):
                if v == target[i]:
                    good.add(i)


        return len(good) == 3

Further, AWS KMS allows you to audit usage of your keys by providing logs of all API calls made on them to help you meet compliance and regulatory requirements.

Customers want to know how to effectively implement AWS KMS in their environment.

This whitepaper discusses how to use AWS KMS for each capability described in the AWS Cloud Adoption Framework Security Perspective whitepaper, including the differences between the different types of customer master keys, using AWS KMS key policies to ensure least privilege, auditing the use of the keys, and listing some use cases that work to protect sensitive information within AWS.

Identity and Access Management

The Identity and Access Management capability provides guidance on determining the controls for access management within AWS KMS to secure your infrastructure according to established best practices and internal policies.

AWS KMS and IAM Policies

You can use AWS Identity and Access Management (IAM) policies in combination with key policies to control access to your customer master keys (CMKs) in AWS KMS.

This section discusses using IAM in the context of AWS KMS. It doesn’t provide detailed information about the IAM service.

Policies attached to IAM identities (that is, users, groups, and roles) are called identity-based policies (or IAM policies).

Policies attached to resources outside of IAM are called resource-based policies.

In AWS KMS, you must attach resource-based policies to your customer master keys (CMKs).

These are called key policies. All KMS CMKs have a key policy, and you must use it to control access to a CMK.

IAM policies by themselves are not sufficient to allow access to a CMK, although you can use them in combination with a CMK key policy.

To do so, ensure that the CMK key policy includes the policy statement that enables IAM policies.

Key Policies

Key policies are the primary way to control access to CMKs in AWS KMS. Each CMK has a key policy attached to it that defines permissions on the use and management of the key.

The default policy enables any principals you define, as well as enables the root user in the account to add IAM policies that reference the key.

We recommend that you edit the default CMK policy to align with your organization’s best practices for least privilege.

To access an encrypted resource, the principal needs to have permissions to use the resource, as well as to use the encryption key that protects the resource.

If the principal does not have the necessary permissions for either of those actions, the request to use the encrypted resource will be denied.

Least Privilege / Separation of Duties

Key policies specify a resource, action, effect, principal, and conditions to grant access to CMKs.

Key policies allow you to push more granular permissions to CMKs to enforce least privilege.

For example, an application might make a KMS API call to encrypt data but there is no use case for that same application to decrypt data.

In that use case, a key policy could grant access to the kms:Encrypt action but not kms:Decrypt and reduce the possibility for exposure.

Additionally, AWS allows you to separate the usage permissions from administration permissions associated with the key.

This means that an individual may have the ability to manipulate the key policy, but might not have the necessary permissions to use the key for cryptographic functions.

Cross Account Sharing of Keys

Delegation of permissions to a CMK within AWS KMS can occur when you include the root principal of a trusted account within the CMK key policy.

The trusted account then has the ability to further delegate these permissions to IAM users and roles within their own account using IAM policies.

While this approach may simplify the management of the key policy, it also relies on the trusted accounts to ensure that the delegated permissions are managed.

The other approach would be to explicitly manage permissions to all authorized users using only the KMS key policy, which could make the key policy complex and less manageable.

Regardless of the approach you take, the specific trust should be broken out on a per key basis to ensure that you adhere to the least privilege model.

CMK Grants

Key policy changes follow the same permissions model used for policy editing elsewhere in AWS.

That is, users either have permission to change the key policy or they do not.

Users with the PutKeyPolicy permission for a CMK can completely replace the key policy for a CMK with a different key policy of their choice.

You can use key policies to allow other principals to access a CMK, but key policies work best for relatively static assignments of permissions.

To enable more granular permissions management, you can use grants.

Grants are useful when you want to define scoped-down, temporary permissions to use your CMK on your behalf in the absence of a direct API call from you.

Encryption Context

In addition to limiting permission to the AWS KMS APIs, AWS KMS also gives you the ability to add an additional layer of authentication for your KMS API calls utilizing encryption context.

The encryption context is a key-value pair of additional data that you want associated with AWS KMS-protected information.

This is then incorporated into the additional authenticated data (AAD) of the authenticated encryption in AWS KMS-encrypted ciphertexts.

If you submit the encryption context value in the encryption operation, you are required to pass it in the corresponding decryption operation.

You can use the encryption context inside your policies to enforce tighter controls for your encrypted resources.

Because the encryption context is logged in CloudTrail, you can get more insight into the usage of your keys from an audit perspective.

Be aware that the encryption context is not encrypted and will be visible within CloudTrail logs.

The encryption context should not be considered sensitive information and should not require secrecy.

Multi-Factor Authentication

To provide an additional layer of security over specific actions, you can implement an additional layer of protection using multi-factor authentication (MFA) on critical KMS API calls.

Some of those calls are PutKeyPolicy, ScheduleKeyDeletion, DeleteAlias, and DeleteImportedKeyMaterial.

This can be accomplished through a conditional statement within the key policy that checks for when or if an MFA device was used as part of authentication.

If someone attempts to perform one of the critical AWS KMS actions, the following CMK policy will validate that their MFA was authenticated within the last 300 seconds, or 5 minutes, before performing the action.

{
 "Sid": "MFACriticalKMSEvents",
 "Effect": "Allow",
 "Principal": {
    "AWS": "arn:aws:iam::111122223333:user/ExampleUser"
 },
 "Action": [
   "kms:DeleteAlias",
   "kms:DeleteImportedKeyMaterial",
   "kms:PutKeyPolicy",
   "kms:ScheduleKeyDeletion"
 ],
 "Resource": "*",
 "Condition":{
    " NumericLessThan ":{"aws: MultiFactorAuthAge":"300"}
  }
}

Detective Controls

The Detective Controls capability ensures that you properly configure AWS KMS to log the necessary information you need to gain greater visibility into your environment.

CMK Auditing

AWS KMS is integrated with CloudTrail. To audit the usage of your keys in AWS KMS, you should enable CloudTrail logging in your AWS account.

This ensures that all KMS API calls made on keys in your AWS account are automatically logged in files that are then delivered to an Amazon Simple Storage Service (S3) bucket that you specify. Using the information collected by CloudTrail, you can determine what request was made, the source IP address from which the request was made, who made the request, when it was made, and so on.

AWS KMS integrates natively with many other AWS services to make monitoring easy.

You can use these AWS services, or your existing security tool suite, to monitor your CloudTrail logs for specific actions such as ScheduleKeyDeletion, PutKeyPolicy, DeleteAlias, DisableKey, DeleteImportedKeyMaterial on your KMS key. Furthermore, AWS KMS emits Amazon CloudWatch Events when your CMK is rotated, deleted, and imported key material in your CMK expires.

CMK Use Validation

In addition to capturing audit data associated with key management and use, you should ensure that the data you are reviewing aligns with your established best practices and policies. One method is to continuously monitor and verify the CloudTrail logs as they come in.

Another method is to use AWS Config rules. By using AWS Config rules you can ensure that the configuration of many of the AWS services are set up appropriately.

For example, with EBS volumes you can use the AWS Config rule ENCRYPTED_VOLUMES to validate that attached EBS volumes are encrypted.

A CMK can have a tag applied to it for a variety of purposes.

The most common use is to correlate a specific CMK back to a business category (such as a cost center, application name, or owner).

The tags can then be used to verify that the correct CMK is being used for a given action.

For example, in CloudTrail logs, for a given KMS action you can verify that the CMK being used belongs to the same business category as the resource that it’s being used on. Previously, this might have required a look up within a resource catalog, but now this external lookup is not required because of tagging within AWS KMS as well as many of the other AWS services.

Infrastructure Security

The Infrastructure Security capability provides you with best practices on how to configure AWS KMS to ensure that you have an agile implementation that can scale with your business while protecting your sensitive information.

Customer Master Keys

Within AWS KMS, your key hierarchy starts with a CMK. A CMK can be used to directly encrypt data blocks up to 4 KB or it can be used to secure data keys, which protect underlying data of any size.

CMKs can be broken down into two general types: AWS-managed and customer-managed.

An AWSmanaged CMK is created when you choose to enable server-side encryption of an AWS resource under the AWS-managed CMK for that service for the first time (e.g., SSE-KMS).

The AWS-managed CMK is unique to your AWS account and the Region in which it’s used.

An AWS-managed CMK can only be used to protect resources within the specific AWS service for which it’s created. It does not provide the level of granular control that a customer-managed CMK provides.

For more control, a best practice is to use a customer-managed CMK in all supported AWS services and in your applications. A customer-managed CMK is created at your request and should be configured based upon your explicit use case.

Key Creation and Management

Since AWS makes creating and managing keys easy through the use of AWS KMS, we recommend that you have a plan for how to use the service to best control the blast radius around individual keys.

Previously, you may have used the same key across different geographic regions, environments, or even applications. With AWS KMS, you should define data classification levels and have at least one CMK per level.

For example, you could define a CMK for data classified as “Confidential,” and so on. This ensures that authorized users only have permissions for the key material that they require to complete their job.

You should also decide how you want to manage usage of AWS KMS.

Creating KMS keys within each account that requires the ability to encrypt and decrypt sensitive data works best for most customers, but another option is to share the CMKs from a few centralized accounts.

Maintaining the CMKs in the same account as the majority of the infrastructure using them helps users provision and run AWS services that use those keys. AWS services don’t allow for cross-account searching unless the principal doing the searching has explicit List* permissions on resources owned by the external account.

This can also only be accomplished via the CLI or SDK, and not through service console-based searches. Additionally, by storing the credentials in the local accounts, it might be easier to delegate permissions to individuals who know the IAM principals that require access to the specific CMKs.

If you were sharing the keys via a centralized model, the AWS KMS administrators would need to know the full Amazon Resource Name (ARN) for all users of the CMKs to ensure least privilege.

Otherwise, the administrators might provide overly permissive permissions on the keys.

Key Aliases

A key alias allows you to abstract key users away from the underlying Region-specific key ID and key ARN.

Authorized individuals can create a key alias that allows their applications to use a specific CMK independent of the Region or rotation schedule.

Thus, multi-Region applications can use the same key alias to refer to KMS keys in multiple Regions without worrying about the key ID or the key ARN.

You can also trigger manual rotation of a CMK by pointing a given key alias to a different CMK. Similar to how Domain Name Services (DNS) allows the abstraction of IP addresses, a key alias does the same for the key ID.

When you are creating a key alias, we recommend that you determine a naming scheme that can be applied across your accounts such as alias/Environment-Function-Service Team.

It should be noted that CMK aliases can’t be used within policies. This is because the mapping of aliases to keys can be manipulated outside the policy, which would allow for an escalation of privilege. Therefore, key IDs must be used in KMS key policies, IAM policies, and KMS grants.

Using AWS KMS at Scale

AWS recommends using envelope encryption to scale your KMS implementation. Envelope encryption is the practice of encrypting plaintext data with a unique data key, and then encrypting the data key with a key encryption key (KEK). Within AWS KMS, the CMK is the KEK.

You can encrypt your message with the data key and then encrypt the data key with the CMK. Then the encrypted data key can be stored along with the encrypted message.

You can cache the plaintext version of the data key for repeated use, reducing the number of requests to AWS KMS. Additionally, envelope encryption can help to design your application for disaster recovery. You can move your encrypted data as-is between Regions and only have to re-encrypt the data keys with the Region-specific CMKs.

Data Protection

The Data Protection capability addresses some of the common AWS use cases for using AWS KMS within your organization to protect your sensitive information.

Common AWS KMS Use Cases

Encrypting PCI Data Using AWS KMS

Since security and quality controls in AWS KMS have been validated and certified to meet the requirements of PCI DSS Level 1 certification, you can directly encrypt Primary Account Number (PAN) data with an AWS KMS CMK.

The use of a CMK to directly encrypt data removes some of the burden of managing encryption libraries.

Additionally, a CMK can’t be exported from AWS KMS, which alleviates the concern about the encryption key being stored in an insecure manner. As all KMS requests are logged in CloudTrail, use of the CMK can be audited by reviewing the CloudTrail logs.

It’s important to be aware of the requests per second limit when designing applications that use the CMK directly to protect Payment Card Industry (PCI) data.

Secret Management Using AWS KMS and Amazon S3

Although AWS KMS primarily provides key management functions, you can leverage AWS KMS and Amazon S3 to build your own secret management solution.

Create a new Amazon s3 bucket to hold your secrets. Deploy a bucket policy onto the bucket to limit access to only authorized individuals and services. The secrets stored in the bucket utilize a predefined prefix per file to allow for granular control of access to the secrets.

Each secret, when placed in the S3 bucket, is encrypted using a specific customer-managed KMS key. Furthermore, due to the highly sensitive nature of the information being stored within this bucket, S3 access logging or CloudTrail Data Events are enabled for audit purposes. Then, when a user or service requires access to the secret, they assume an identity within AWS that has permissions to use both the object in the S3 bucket as well as the KMS key. An application that runs in an EC2 instance uses an instance role that has the necessary permissions.

Encrypting Lambda Environment Variables

By default, when you create or update Lambda functions that use environment variables, those variables are encrypted using AWS KMS. When your Lambda function is invoked, those values are decrypted and made available to the Lambda code. You have the option to use the default KMS key for Lambda or specify a specific CMK of your choice.

To further protect your environment variables, you should select the “Enable encryption helpers” checkbox. By selecting this option, your environment variables will also be individually encrypted using a CMK of your choice, and then your Lambda function will have to specifically decrypt each encrypted environment variable that is needed.

Encrypting Data within Systems Manager Parameter Store

Amazon EC2 Systems Manager is a collection of capabilities that can help you automate management tasks at scale.

To efficiently store and reference sensitive configuration data such as passwords, license keys, and certificates, the Parameter Store lets you protect sensitive information within secure string parameters.

A secure string is any sensitive data that needs to be stored and referenced in a secure manner.

If you have data that you don't want users to alter or reference in clear text, such as domain join passwords or license keys, then specify those values using the Secure String data type. You should use secure strings in the following circumstances:

• You want to use data/parameters across AWS services without exposing the values as clear text in commands, functions, agent logs, or CloudTrail logs.
• You want to control who has access to sensitive data.
• You want to be able to audit when sensitive data is accessed using CloudTrail.
• You want AWS-level encryption for your sensitive data and you want to bring your own encryption keys to manage access.

By selecting this option when you create your parameter, the Systems Manager encrypts that value when it’s passed into a command and decrypts it when processing it on the managed instance. The encryption is handled by AWS KMS and can be either a default KMS key for the Systems Manager or you can specify a specific CMK per parameter.

Enforcing Data at Rest Encryption within AWS Services

Your organization might require the encryption of all data that meets a specific classification. Depending on the specific service, you can enforce data encryption policies through preventative or detective controls. For some services like Amazon S3, a policy can prevent storing unencrypted data. For other services, the most efficient mechanism is to monitor the creation of storage resources and check whether encryption is enabled appropriately. In the event that unencrypted storage is created, you have a number of possible responses ranging from deleting the storage resource to notifying an administrator.

Conclusion

AWS KMS provides your organization with a fully managed service to centrally control your encryption keys. Its native integration with other AWS services makes it easier for AWS KMS to encrypt the data that you store and process.

By taking the time to properly architect and implement AWS KMS, you can ensure that your encryption keys are secure and available for applications and their authorized users. Additionally, you can show your auditors detailed logs associated with your key usage.

Reference

Original paper

$ sudo apt-get update

$ sudo apt install git python3-pip build-essential wget
python3-dev python3-venv python3-wheel libxslt-dev
libzip-dev libldap2-dev libsasl2-dev python3-setuptools
libpng12-0 libjpeg-dev gdebi -y

• Download and install wkhtmltopdf :

$ wget https://github.com/wkhtmltopdf/wkhtmltopdf/
releases/download/0.12.5/wkhtmltox_0.12.5-1.trusty_amd64.
deb

$ sudo dpkg -i wkhtmltox_0.12.5-1.trusty_amd64.deb

If you find errors in a previous command, force install the dependencies with the following command:

$ sudo apt-get install -f

• Now, install the PostgreSQL database:

$ sudo apt install postgresql -y

Configure PostgreSQL:

$ sudo -u postgres createuser --superuser $(whoami)

Configure git :

$ git config --global user.name "Your Name"
$ git config --global user.email youremail@example.com

Create an odoo-14.0 virtual environment and activate it:

$ python3 -m venv ~/venv-odoo-14.0
$ source ~/venv-odoo-14.0/bin/activate

• Install the Python dependencies of Odoo in venv :

$ cd ~/odoo-dev/odoo/
$ pip3 install -r requirements.txt

• Create and start your first Odoo instances:

$ createdb odoo-test
$ python3 odoo-bin -d odoo-test –i base --addons-path=addons --db-filter=odoo-test$

• Clone the Odoo code base:

$ mkdir ~/odoo-dev
$ cd ~/odoo-dev
$ git clone -b 14.0 --single-branch --depth 1 https://github.com/odoo/odoo.git

• Point your browser to http://localhost:8069 and authenticate it by using the admin account and using admin as the password

Note

If you need RTL support, please install node and rtlcss via the following command:

sudo apt-get install nodejs npm -y
sudo npm install -g rtlcss

• Every node connected to an Internet Protocol (IP) network must have an IP address for communication purposes.

• As the internet continues to grow, so does the need for IP addresses.

• IPv6 is a version of the Internet Protocol that uses a larger address space than its predecessor, IPv4.

• This whitepaper focuses on best practices for adopting and designing IPv6-based networks on AWS Cloud.

• It covers IPv6 dual-stack networks for both internet-facing and private IPv6 networks use cases.

Intro

• An increasing number of organizations operate dual-stack IPv4/IPv6 networks.
• Carrier networks and ISPs were the first groups to start deploying IPv6 on their networks, with mobile networks leading the charge.

• Adoption of IPv6 has been delayed, partly due to NAT with IPv4, which takes private IP addresses and turns them into public IP addresses.

• An increasing number of organizations are adopting IPv6 in their environments, driven by the public IPv4 space exhaustion, private IPv4 scarcity, especially within large-scale networks, and the need to provide connectivity to IPv6-only clients.

• There is no onesize-fits-all approach with IPv6; however, there are best practices AWS customers can follow to plan and implement IPv6 into their existing cloud networks.

• This whitepaper explains key drivers for adoption and highlights best practices to guide you while leaving enough space for you to decide, based on your specific use case and implementation, how to approach IPv6 in your network.

Tenets for IPv6 adoption

• Adhering to the following tenets for IPv6 adoption can help make the process and decision more manageable:
  • Re-evaluate network controls — IPv6 offers opportunities to rethink your approach to perimeter security and make design decisions that further improve your security posture.
  • Design for scale — More usable IPv6 addresses doesn’t mean you can shortcut IP allocation and planning.
  • Phase your IPv6 adoption — Focus on your business needs to implement IPv6 where needed, and remember that IPv4 and IPv6 can be made to coexist as long as needed.

Internet Protocol version 6

• IPv6 is the next generation IP address standard intended to supplement and eventually replace IPv4, the original and ubiquitous IP address scheme.

• Every computer, mobile phone, home automation component, IoT sensor, and any other device connected to an IP-based network needs a numerical IP address to communicate with other devices.

• Public reachable IPv4 addresses are in short supply due to their widespread usage and constantly increasing demand stemming from the proliferation of connected devices globally.

• The last available block of new IP version 4 (IPv4) addresses was allocated back in 2011, and from that time on, everyone has been reusing a finite set of available addresses.

• IP version 6 (IPv6) is the replacement for IPv4, and it is designed to address the depletion of IP addresses, and change the way traffic is managed.

IPv6 addressing

The IPv6 address space is organized by using format prefixes, that logically divide it in the form of a tree so that a route from one network to another can easily be found.

The main categories of IPv6 addresses are:

  - Aggregatable global unicast addresses (GUA) — 2000::/3 

  - Unique-local unicast addresses (ULA) — FC00::/7 

  - Link-local unicast addresses — FE80::/10 

  - Multicast addresses — FF00::/8 

IPv6 adoption strategies and mechanisms

Working with customers, AWS observed the following two main drivers for IPv6 adoption.

• Network Address Translation is no longer sufficient to work around exhaustion and poses significant challenges with overlapping IP addresses.
• There are numerous organizational or regulatory mandates to adopt IPv6.

Following is a summary of IPv6 adoption drivers:

• Mandated IPv6 endpoints — Either mandated by a government policy or an industry regulator, and not necessarily tied to a particular use case.

• Interoperability with IPv6 networks — The last years have seen a growing population of IPv6-only clients, and as a result so have the number of organizations wanting to cater to this user base. With the number of mobile IPv6-only users, many companies find they can’t afford to lose that section of their potential user base.

• Public IPv4 exhaustion — As public IPv4 addresses become more scarce, allocating contiguous IP address ranges for public routing becomes more difficult and costly.

• Private IPv4 exhaustion — As private IPv4 (RFC1918) addresses become exhausted and too fragmented within organizations’ private networks, IPv6-only networks offer opportunities to address additional nodes.

IPv6 adoption strategy depends on the driving force behind it. You may have an immediate goal such as addressing private IPv4 exhaustion, or the ability to provide IPv6 service endpoints as per government mandate, with the long-term goal of fully converting to an IPv6 only network.

Following are the four main driving forces, and the corresponding adoption strategy:

• Private IPv4 exhaustion — The goal is to provision new nodes and allocate routable IP addresses without IP overlap, and without the challenge of sourcing contiguous and usable IP addresses.

• Adoption strategy — Configure IPv6-only routing between dual stack network segments, to facilitate communication using the IPv6 stack. Provide IPv6 to IPv4 interoperability layer, such as dual-stack load balancers.

• Public IPv4 exhaustion — The goal is to support IPv6 only nodes connecting to your public endpoints. As an example, you may have an API endpoint for data upload from IoT devices which are connected to an IPv6-only network. The IoT devices have IPv6 addresses, and the network does not provide interoperability layer to IPv4. Other devices may operate in IPv4 networks.

• Adoption strategy — Create dual-stack VPCs and subnets. Configure AWS services such as load balancers and edge service in dual-stack mode with corresponding DNS record on the AWS Cloud. Optionally, provide separate endpoints for IPv4 and IPv6 in dedicated IPv4-only or IPv6-only deployments.

Interoperability

Although operating in dual-stack mode solves a lot of the problems with IPv4 and IPv6 interoperability, it creates management overhead. For example, security becomes harder because you have to manage two sets of security rules, one for each network stack. Routing and troubleshooting become harder, and you have to maintain additional records to existing DNS names.

You may be able to avoid making the entire network dual-stack by focusing on implementing dual-stack at your border via load balancers. Existing segments of your network can continue to operate as IPv4 in most cases, and new segments are built with IPv6. Focus on implementing and operating interoperability layer where AWS services such as dual-stack VPC and load balancers, to help you solve interoperability challenges.

Planning IPv6 adoption in the AWS Cloud network

Elastic network interfaces in an IP network could operate in three different modes:

• IPv4-only mode — Your resources can communicate over IPv4, and if communicating to IPv6 nodes, require an interoperability layer.

• IPv6-only mode — Your resources can communicate over IPv6, and if communicating to IPv4 nodes, require an interoperability layer.

• Dual-stack mode — Your resources can communicate over both IPv4 and IPv6.

A separate interoperability layer is not required

IPv6 addressing plan on AWS

Coming up with an IPv6 addressing plan is one of the most important initial tasks for any organization proceeding with IPv6 adoption. For most organizations, IPv6 is deployed in parallel with IPv4 in existing IPv4 AWS and hybrid networks.

IPv4 addressing plans tend to grow over time, and consequently may be highly fragmented, not contiguous, or not big enough. Simply duplicating the IPv4 addressing scheme in some fashion in IPv6 might initially prove advantageous.

However, any temporary advantage gained by such a shortcut will ultimately be surpassed by the ease and efficiency of operation and design offered by a proper IPv6 addressing plan that incorporates the key benefits of the larger allocations possible with IPv6.

AWS-assigned IPv6 VPC CIDR

By default, Amazon provides one fixed size (/56) IPv6 CIDR block to a VPC. This range is assigned by the service, and consequently, you can’t assign contiguous IPv6 CIDR blocks to VPCs in the same Region or based on other custom-defined criteria.

For customers that have a large VPC footprint in AWS and prefer to use IP route summarization to simplify their overall environment, bring your own IPv6 (BYOIPv6) described, in the next section, may be the preferred solution.

BYOIPv6 VPC CIDR

Alternatively, if you own an IPv6 address space, you can import it into AWS using the Bring Your Own IPv6 service. The smallest IPv6 address range that you can bring is /48 for CIDRs that are publicly advertised by AWS, and /56 for CIDRs that are not publicly advertised by AWS.

You can also choose to bring a /48 and mark it as non-advertisable, keeping control of IP advertisements on your on-premises setup. After importing it, you can assign /56 ranges from the space to individual VPCs in the same account.

VPC subnet addressing

Although you can assign one /56 IPv6 CIDR block to a VPC, the VPC subnets are /64 fixed in length. This yields to the interface ID being /64 in length, in accordance with the general format of the IPv6 unicast addresses. Given the fixed size of the VPC CIDR and the subnet prefix, you have 8 bits for subnet allocation in the VPC, enabling you to create 256 subnets in the VPC.

Designing an IPv6 AWS Cloud network

Amazon VPC design

Planning and implementing network connectivity in AWS is usually one of the foundational tasks you perform when deploying workloads in AWS.

Following are some of the aspects typically considered:

• Amount and nature of Amazon VPCs required

• Amazon VPC CIDR range and IP address allocation including Bring Your Own IP (BYOIP) for public connectivity

• Number and type of subnets

• Number of availability zones to cover
• Permitted traffic paths
• Internet incoming and outgoing traffic options
• Hybrid connectivity
• Inter-VPC connectivity
• Scalability and expansion

VPC IP address assignment

Your VPC can operate in dual-stack mode—your resources can communicate over IPv4, IPv6, or both. IPv4 and IPv6 communication are independent of each other. You cannot disable IPv4 support for your VPC and subnets; you are required to allocate at least one IPv4 CIDR range to your VPC. In addition, you may associate up to one IPv6 CIDR block range per VPC.

Subnet address assignment

After you have associated an IPv6 prefix to a VPC, you can begin to assign one /64 IPv6 prefix to each subnet.

Note that these assignments are configured on a per-subnet basis, and it’s possible to have a mix of subnets with and without IPv6 within the same VPC.

This is useful in scenarios where you merely require IPv6 capability for a subset of the network as described in the drivers for adoption section.

The address assignment of resource within a subnet occurs at two levels:

• The Amazon VPC elastic network interface construct configuration
• A resource’s networking stack configuration

IP addressing of the elastic network interface

• Network-addressable resources deployed within a VPC must have an elastic network interface. Examples of resources include:

  • Amazon Elastic Compute Cloud (Amazon EC2) instances
  • Interface VPC endpoints
  • AWS Lambda functions (deployed in VPCs)
  • Amazon Relational Database Service (Amazon RDS) database instances

Elastic network interfaces are logical constructs in the VPC which represent a resource’s network adapter at runtime.

Each elastic network interface may have one or more IPv4 addresses as well as one or more IPv6 addresses.

This means you are not required to provision separate elastic network interfaces for IPv4 and IPv6, and there is no need to configure additional elastic network interfaces on your workloads to enable IPv6.

IP addressing at the resource’s networking stack

In IPv4, the preferred method for assigning IPv4 addresses is to use Dynamic Host Configuration Protocol (DHCP).

DHCP is based on IPv4’s broadcast mechanism that allows hosts to announce themselves to DHCP servers.

These servers can then offer an IP address lease to the client. IPv6 has no concept of broadcast and initially did not feature DHCP capability.

However, the community has become used to DHCP, and so RFC 8415 was developed to introduce DHCPv6.

In the absence of broadcast capability, DHCPv6 makes use of the well-known multicast address for all DHCP servers/relays, ff02::1:2.

Amazon VPC has built in support for address assignment via DHCP for both IPv4 and IPv6.

Address allocation works similar to static address reservation in traditional DHCP servers:

the IP address assigned to the elastic network interface construct determines the IP address the VPC DHCP infrastructure offers the resource requesting an address.

Amazon VPC also offers the ability to configure DHCP option sets which can be used to provide additional configuration information such as domain name or DNS servers to use. In a dual-stack design all IP addresses used in an option set need to be IPv4.

Supporting Amazon VPC services

AWS exposes a set of supporting services within customer VPCs at wellknown/reserved addresses.

These services are traditionally exposed from the IPv4 linklocal address range (169.254.0.0/16).

For AWS Nitro System instances , AWS also provides these services using IPv6 ULAs.

Instance Metadata Service (IMDS)

The instance metadata is information about your instance.

Instances can introspect this at runtime by querying the IMDS available to it at 169.254.169.254.

For Nitro-based instances, AWS also provides this service at the fd00:ec2::254 IPv6 endpoint.

Route 53 DNS resolver

Amazon VPC features a built-in DNS resolver which resides at VPC_CIDR_BASE + 2 and 169.254.169.253.

IPv6 enabled Nitro instances can access the service via fd00:ec2::253.

Amazon Route 53 Resolver and DNS in general is discussed at greater length in the Designing DNS for IPv6 section of this document.

Network Time Protocol server

Amazon VPC provides a Stratum-3 NTP server at 169.254.169.123.

Nitro-based IPv6 enabled instances can reach this server via fd00:ec2::123.

Amazon VPC connectivity options for IPv6

There are a growing number of ways in which Amazon VPCs can connect to each other.

Many of these options are detailed in the VPC to VPC connectivity section of the Building a Scalable and Secure Multi-VPC AWS Network Infrastructure whitepaper .

AWS recommends you read the following subsections alongside, and it follows the same structure while providing additional insight regarding IPv6 operation as both papers cover:

• VPC peering
• AWS Transit Gateway
• VPC subnet sharing
• AWS PrivateLink

VPC peering

VPC peering is the simplest method for VPC-to-VPC connectivity.

It supports both intraand inter-Region connectivity.

The peering itself is IP protocol agnostic.

After you establish peering, you must configure one or more static routes defining which prefixes are reachable.

Both IPv4 and IPv6 prefixes may be routed across the same peering.

The following diagram depicts a VPC peering between two VPCs supporting IPv4 and IPv6 simultaneously.

The peering is agnostic, and the subnet route tables are the deciding factor for which prefixes are reachable.

AWS Transit Gateway

It is a scalable highly available way to establish network connectivity between multiple VPCs.

A Transit Gateway is a Regional construct, and attaches VPCs within the same Region.

Transit Gateways located in different AWS Regions can establish a peering relationship, enabling global connectivity for your network.

IPv6 connectivity into Transit Gateway

You use a Transit Gateway attachment to connect a VPC to a Transit Gateway.

An attachment deploys an elastic network interface into each subnet you select.

Traffic is routed into Transit Gateways using static routes in VPC subnet routing tables with the attachment as the next-hop.

The attachments themselves are IP protocol agnostic, and you can route IPv4 and IPv6 prefixes via the same attachment.

To support IPv6, the elastic network interface s used by the attachments need to have IPv6 addresses assigned to them.

IPv6 traffic within and between Transit Gateways

A Transit Gateway attachment is both a source and a destination of packets.

You can attach the following resources to your Transit Gateway:

• VPCs
• One or more VPN connections
• One or more AWS Direct Connect gateways
• One or more Transit Gateway Connect attachments
• One or more Transit Gateway peering connections

A Transit Gateway has one or more routing tables.

A routing table can receive its entries through a combination of static route configuration and dynamic propagations from other attachments (VPC, Direct Connect, Site-to-Site VPN, or Connect Peering). In either case, IPv6 routes are supported.

AWS Transit Gateway Connect Attachments for IPv6

You can create a Transit Gateway Connect attachment to establish a connection and dynamic routing between a transit gateway and third-party virtual appliances (such as SD-WAN appliances).

These attachments take the form of IP Generic Routing Encapsulation (GRE) protocol tunnels and enable dynamic exchange of routing information between an EC2 instances in a VPC and a TGW.

Route exchange is facilitated by a Border Gateway Protocol (BGP) peering. TGW connect peers support IPv6 using Multi-Protocol BGP (MP-BGP) and a /125 CIDR block from the well-known fd00::/8 unique local address range.

Multiprotocol BGP (MP-BGP) is an extension to BGP that enables BGP to carry routing information for multiple network layers and address families. MP-BGP can carry the unicast routes used for multicast routing separately from the routes used for unicast IP forwarding.

AWS PrivateLink

AWS PrivateLink provides private connectivity between VPCs, AWS services, and customer on-premises networks, without exposing traffic to the public internet.

AWS PrivateLink makes it easy to connect services across different accounts and VPCs to significantly simplify your network architecture.

AWS PrivateLink does not currently support IPv6. However, PrivateLink has the useful property of abstracting the IP addressing used between source and destination.

In the meantime, it’s possible to operate a dual-stack setup for the purpose of communicating via PrivateLink endpoints.

It is possible for a workload to use IPv6 for most communication and use IPv4 purely for accessing the IPv4 address of the PrivateLink endpoint.

VPC sharing

VPC sharing allows VPC owners to share a subnet across AWS accounts.

You may share dual-stack subnets the same way as IPv4-only ones.

IPv6 resources deployed into a shared subnet function identical to those deployed into non-shared subnets.

Amazon VPC internet access

Internet reachable IPv6 resources

Elastic network interfaces retain their IPv6 addresses throughout their lifetime.

For IPv4, elastic network interfaces can have zero or more Elastic IP addresses associated with them.

An Elastic IP address defines a static 1:1 NAT relationship between an elastic network interface’s IPv4 address and a public internetroutable address.

In IPv6, VPC addressing is already globally unique, and therefore Elastic IP addresses are not required.

Amazon assigned IPv6 addresses are automatically publicly advertised whereas for BYOIP ranges this is optional.

In either case, resources deployed only have IPv6 internet reachability if their subnet’s routing table contains IPv6 destinations (such as ::/0) via either an internet gateway or outbound traffic-only internet gateway.

Hybrid connectivity design

Hybrid connectivity scenarios are a reality for many customers.

Two methods for addressing these: AWS Direct Connect and AWS managed Site-to-Site VPN.

AWS previously published the Hybrid Connectivity whitepaper, which focused on designs and considerations around these solutions, and most of that content remains relevant.

However, that paper does not consider IPv6. This section assumes you are acquainted with the aforementioned document, and it focuses only on the best practices and differences compared to IPv4 implementations.

AWS Direct Connect

AWS Direct Connect is a cloud service solution that makes it easy to establish a dedicated network connection from customer premises to AWS.

Different aspects of the Direct Connect service deal with different layers of the OSI model.

The choice of IPv6 only affects configuration related to Layer 3, so many aspects of Direct Connect configuration such as physical connections, link aggregation, VLANs, and jumbo frame are no different from IPv4 use cases.

Where IPv6 does differ is when it comes to addressing and configuration of BGP peerings on top of a virtual network interface (VIF). There are three types of VIFs:

• Private
• Transit
• Public

Transit and Private VIF IPv6 peerings — Whereas in IPv4 you are free to choose your own addressing for the logical point-to-point, in IPv6, AWS automatically allocates a 125 CIDR for each VIF, and it’s not possible to specify custom IPv6 addresses.

Advertising IPv6 prefixes from AWS

When associating a Direct Connect Gateway directly with a VGW you can specify “Allowed Prefixes .

Think of this like a traditional “prefix-list” filter, controlling the prefixes advertised to your customer gateway. With IPv4, specifying no filter equates to 0.0.0.0/0 — no filtering.

With IPv6, not specifying a value here results in all advertisements being implicitly blocked.

Amazon-managed VPN

AWS Site-to-Site VPN connectivity configuration comprises multiple parts:

1. The customer gateway, which is the logical representation of the onpremises VPN end point.
2. The VPN connection.
3. The local device configuration on the VPN appliance, represented by the customer gateway.

Any AWS S2S VPN connection consists of two tunnels. It is this connection that defines the IP addressing, ISAKMP, IPsec, and BGP peering parameters.

Designing DNS for IPv6

The core concept of DNS is unchanged from IPv4. From a Layer 3 perspective, DNS is just another application, and therefore, by virtue of the OSI/ISO model provided abstraction, agnostic to the chosen network layer protocol.

Regardless of the IP version, there is a deep link between DNS and the IP layer.

The DNS specification has adapted and introduced an additional type to accommodate IPv6 addresses.

In IPv6 the equivalent of the IPv4 “A” records are AAAA records.

This means that it is possible to use IPv4 as the network protocol to connect to a DNS server and resolve an IPv6 (AAAA) record.

PTR records

A pointer (PTR) record translates an IP address to its domain name.

IPv6 addresses are reverse mapped under the domain IP6.ARPA.

IPv6 reverse maps use a sequence of nibbles separated by dots with the suffix “.IP6.ARPA” as defined in RFC 3596.

For example, the reverse lookup domain name corresponding to the address 2001:db8:1234:1a00:1:2:3:4 would be 4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.a.1.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa

Alias records

Amazon Route 53 supports alias records.

Route 53 alias records are mapped internally to the DNS name of alias targets such as AWS resources.

Route 53 monitors the IP address associated with an alias target's DNS name for scaling actions and software updates.

The authoritative response from Route 53 name servers contains an A record (for IPv4 addresses) or AAAA record (for IPv6 addresses) with the IP address of the alias target.

DNS resolution within a host

External configuration aside it is up to a host’s networking stack at runtime to resolve DNS records.

When configured as dual-stack, most modern operating systems default to preferring IPv6.

In other words, when a query for a FQDN returns both an A and AAAA record the OS prefers to use the AAAA record and establishes IPv6 connectivity to the target.

Amazon Route 53 DNS records

In AWS, Amazon Route 53 provides DNS capabilities. Route 53 provides features for two use cases:

• Public DNS for externally hosted content
• DNS capability within a VPC both from a resolver and authoritative name server standpoint

Public IPv6 DNS resolution

For externally queryable DNS, you can use Route 53 public hosted zones, with both A and AAAA records.

Route 53 health checks support health checking IPv6 services.

The name servers exist both for IPv4 and IPv6, meaning clients wanting to resolve a FQDN hosted on Route 53 public hosted zone can do so natively.

DNS resolution within a VPC

Amazon VPC comes with Route 53 Resolver, which provides a built-in capability for resolving DNS names.

This resolver is reachable either on 169.254.169.253 or VPC_CIDR_NETWORK + 2 for IPv4 and fd00:ec2::253 for Nitro-based IPv6 hosts.

Requests sent to this resolver are resolved against the combination of private hosted zones associated with the VPC, and any (shared) resolver rules

IPv6 security and monitoring considerations

Network-level access control

Amazon VPCs feature two network access control mechanisms, and these exist irrespectively of which version of the IP protocol is used (IPv4 or IPv6):

• Security groups (SGs) at the elastic network interface level
• Network access control lists (network ACLs) at the subnet level

VPC Flow Logs

VPC Flow Logs is a feature that enables you to capture information about the IPv6 traffic going to and from network interfaces in your VPC.

VPC Flow Logs for IPv6 traffic works the same as IPv4 where you can create flow logs at the VPC level, the subnet level, or the network interface level.

If you create VPC Flow Logs at a VPC or subnet level, every network interface in that VPC or subnet is monitored.

The flow log records can use the default format or the custom format.

With a custom format, you specify which fields are included in the IPv6 flow log records and in which order.

VPC Logs default format:

VPC Traffic Mirroring

VPC Traffic Mirroring is a complementary feature to flow logs that copies entire packets, including their payload of network traffic from a specified elastic network interface of an Amazon EC2 instance.

Traffic Mirroring copies inbound and outbound IPv4 and IPv6 traffic from the network interfaces that are attached to your Amazon EC2 instances.

You can send the mirrored traffic to the network interface of another EC2 instance, or a Network Load Balancer that has a UDP listener (listening on UDP port 4789 - VXLAN).

The mirrored traffic is sent to the traffic mirror target by means of the source VPC IPv4 route table.

Note that all mirrored traffic is encapsulated in an IPv4 packet.

Traffic Mirroring mirrors both your IPv4 and IPv6 traffic.

No special configuration is necessary to enable Traffic Mirroring for your IPv6 traffic, whether the traffic mirror source and the target are in the same VPC.

Or in a different VPC connected via VPC peering or a Transit Gateway (as long as the traffic mirror source can route to the traffic mirror target by IPv4).

AWS Web Application Firewall

AWS Web Application Firewall (AWS WAF) lets you monitor the HTTP(S) requests that are forwarded to an Amazon CloudFront distribution, an Amazon API Gateway REST API, an Application Load Balancer, or an AWS AppSync GraphQL API.

With AWS WAF, the services that are associated with the protected resources can respond either with the requested content or with HTTP 403 status code based on conditions that are specified, such as the IP addresses (either IPv4 or IPv6) that the request originate from.

Web ACL

You use the rules in a web ACL to block or allow web requests based on criteria which includes IP addresses or address ranges that requests originate from.

The IP set match statement inspects the IP address of a web request against a set of IP addresses and address ranges.

Use this to allow or block web requests based on the IP addresses (either IPv4 or IPv6) that the requests originate from.

AWS WAF IP sets supports all IPv4 and IPv6 CIDR ranges except for 0.0.0.0/0 and ::/0.

AWS Shield

It provides protection against DDoS attacks.

A DDoS attack can prevent legitimate users from accessing a service and can cause the system to crash due to the overwhelming traffic volume.

All of the AWS Shield detection and mitigations work with IPv4 and IPv6 without any impact to performance, scalability, or availability of the service

AWS Network Firewall

AWS Network Firewall is a stateful, managed, network firewall and intrusion detection and prevention service for Amazon Virtual Private Cloud (Amazon VPC).

AWS Network Firewall does not currently support IPv6. In the dual-stack mode, you can still use AWS Network Firewall to filter IPv4 traffic going to and coming from an internet gateway, NAT gateway, or over VPN or AWS Direct Connect.

AWS Systems Manager

Resources managed by AWS Systems Manager must have IPv4 connectivity to Systems Manager’s endpoints.

For example, to connect to an EC2 instance using Systems Manager Session Manager, the instance must be running dual-stack and must have an IPv4 connectivity to the internet or AWS PrivateLink VPC endpoint.

Similarly, on-premises resources must also be in dual-stack network mode

Scaling the dual-stack network design in AWS

Elastic Load Balancing

ELB automatically distributes your incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones.

It supports the following types of load balancers: Application Load Balancers, Network Load Balancers, and Classic Load Balancers.

Both load balancer types support internet-facing and internal load balancer schemes.

You create internet-facing Application Load Balancers and internet-facing Network Load

Conclusion

There are multiple driving forces behind IPv6 adoption. This paper describes what they are and explains how you can respond to them.

It also explains differences between IPv4 and IPv6 where applicable, and covers interoperability between both network stacks.

As always, security remains paramount and so this paper covered how to evolve your perimeter design to take advantage of IPv6 protocol features.

Remember that IPv6 only makes a difference at the network layer of the networking stack.

Many connectivity and security elements, especially in cloud native applications, are handled at higher layers and are therefore not affected.

AWS offers comprehensive IPv6 support in Amazon VPC and AWS services running at the edge of AWS Cloud.

You can adopt IPv6 at your own pace and focus on use cases where you will benefit the most from the adoption.

Reference

Original paper

Dapr codifies the best practices for building microservice applications into open, independent, building blocks that enable you to build portable applications with the language and framework of your choice. Each building block is independent and you can use one, some, or all of them in your application.

Here is a link for creating a Dapr project with Node.JS and the Dapr-JS SDK: https://lnkd.in/dJEHmsaH

Dapr-JS SDK Docs

import { DaprClient, DaprServer, HttpMethod, CommunicationProtocolEnum } from "dapr-client";

const daprHost = "127.0.0.1"; // Dapr Sidecar Host
const daprPort = "3500"; // Dapr Sidecar Port of this Example Server
const serverHost = "127.0.0.1"; // App Host of this Example Server
const serverPort = "50051"; // App Port of this Example Server 

// HTTP
const server = new DaprServer(
     serverHost, serverPort, 
     daprHost, daprPort
); 

const client = new DaprClient(daprHost, daprPort);

// GRPC 
const server = new DaprServer(
    serverHost, serverPort, 
    daprHost, daprPort, 
    CommunicationProtocolEnum.GRPC
 );

const client = new DaprClient(
     daprHost, daprPort, 
     CommunicationProtocolEnum.GRPC
 );

You can find it here

Further, AWS KMS allows you to audit the usage of your keys by providing logs of all API calls made on them to help you meet compliance and regulatory requirements.

Customers want to know how to effectively implement AWS KMS in their environment.

This whitepaper discusses how to use AWS KMS for each capability described in the AWS Cloud Adoption Framework Security Perspective whitepaper, including the differences between the different types of customer master keys, using AWS KMS key policies to ensure least privilege, auditing the use of the keys, and listing some use cases that work to protect sensitive information within AWS.

Identity and Access Management

The Identity and Access Management capability provides guidance on determining the controls for access management within AWS KMS to secure your infrastructure according to established best practices and internal policies.

AWS KMS and IAM Policies

You can use AWS Identity and Access Management (IAM) policies in combination with key policies to control access to your customer master keys (CMKs) in AWS KMS.

This section discusses using IAM in the context of AWS KMS. It doesn’t provide detailed information about the IAM service.

Policies attached to IAM identities (that is, users, groups, and roles) are called identity-based policies (or IAM policies).

Policies attached to resources outside of IAM are called resource-based policies.

In AWS KMS, you must attach resource-based policies to your customer master keys (CMKs).

These are called key policies. All KMS CMKs have a key policy, and you must use it to control access to a CMK.

IAM policies by themselves are not sufficient to allow access to a CMK, although you can use them in combination with a CMK key policy.

To do so, ensure that the CMK key policy includes the policy statement that enables IAM policies.

Key Policies

Key policies are the primary way to control access to CMKs in AWS KMS. Each CMK has a key policy attached to it that defines permissions on the use and management of the key.

The default policy enables any principals you define, as well as enables the root user in the account to add IAM policies that reference the key.

We recommend that you edit the default CMK policy to align with your organization’s best practices for least privilege.

To access an encrypted resource, the principal needs to have permissions to use the resource, as well as to use the encryption key that protects the resource.

If the principal does not have the necessary permissions for either of those actions, the request to use the encrypted resource will be denied.

Least Privilege / Separation of Duties

Key policies specify a resource, action, effect, principal, and conditions to grant access to CMKs.

Key policies allow you to push more granular permissions to CMKs to enforce least privilege.

For example, an application might make a KMS API call to encrypt data but there is no use case for that same application to decrypt data.

In that use case, a key policy could grant access to the kms:Encrypt action but not kms:Decrypt and reduce the possibility for exposure.

Additionally, AWS allows you to separate the usage permissions from administration permissions associated with the key.

This means that an individual may have the ability to manipulate the key policy, but might not have the necessary permissions to use the key for cryptographic functions.

Cross Account Sharing of Keys

Delegation of permissions to a CMK within AWS KMS can occur when you include the root principal of a trusted account within the CMK key policy.

The trusted account then has the ability to further delegate these permissions to IAM users and roles within their own account using IAM policies.

While this approach may simplify the management of the key policy, it also relies on the trusted accounts to ensure that the delegated permissions are managed.

The other approach would be to explicitly manage permissions to all authorized users using only the KMS key policy, which could make the key policy complex and less manageable.

Regardless of the approach you take, the specific trust should be broken out on a per key basis to ensure that you adhere to the least privilege model.

CMK Grants

Key policy changes follow the same permissions model used for policy editing elsewhere in AWS.

That is, users either have permission to change the key policy or they do not.

Users with the PutKeyPolicy permission for a CMK can completely replace the key policy for a CMK with a different key policy of their choice.

You can use key policies to allow other principals to access a CMK, but key policies work best for relatively static assignments of permissions.

To enable more granular permissions management, you can use grants.

Grants are useful when you want to define scoped-down, temporary permissions to use your CMK on your behalf in the absence of a direct API call from you.

Encryption Context

In addition to limiting permission to the AWS KMS APIs, AWS KMS also gives you the ability to add an additional layer of authentication for your KMS API calls utilizing encryption context.

The encryption context is a key-value pair of additional data that you want associated with AWS KMS-protected information.

This is then incorporated into the additional authenticated data (AAD) of the authenticated encryption in AWS KMS-encrypted ciphertexts.

If you submit the encryption context value in the encryption operation, you are required to pass it in the corresponding decryption operation.

You can use the encryption context inside your policies to enforce tighter controls for your encrypted resources.

Because the encryption context is logged in CloudTrail, you can get more insight into the usage of your keys from an audit perspective.

Be aware that the encryption context is not encrypted and will be visible within CloudTrail logs.

The encryption context should not be considered sensitive information and should not require secrecy.

Multi-Factor Authentication

To provide an additional layer of security over specific actions, you can implement an additional layer of protection using multi-factor authentication (MFA) on critical KMS API calls.

Some of those calls are PutKeyPolicy, ScheduleKeyDeletion, DeleteAlias, and DeleteImportedKeyMaterial.

This can be accomplished through a conditional statement within the key policy that checks for when or if an MFA device was used as part of authentication.

If someone attempts to perform one of the critical AWS KMS actions, the following CMK policy will validate that their MFA was authenticated within the last 300 seconds, or 5 minutes, before performing the action.

{
 "Sid": "MFACriticalKMSEvents",
 "Effect": "Allow",
 "Principal": {
    "AWS": "arn:aws:iam::111122223333:user/ExampleUser"
 },
 "Action": [
   "kms:DeleteAlias",
   "kms:DeleteImportedKeyMaterial",
   "kms:PutKeyPolicy",
   "kms:ScheduleKeyDeletion"
 ],
 "Resource": "*",
 "Condition":{
    " NumericLessThan ":{"aws: MultiFactorAuthAge":"300"}
  }
}

Detective Controls

The Detective Controls capability ensures that you properly configure AWS KMS to log the necessary information you need to gain greater visibility into your environment.

CMK Auditing

AWS KMS is integrated with CloudTrail. To audit the usage of your keys in AWS KMS, you should enable CloudTrail logging in your AWS account.

This ensures that all KMS API calls made on keys in your AWS account are automatically logged in files that are then delivered to an Amazon Simple Storage Service (S3) bucket that you specify. Using the information collected by CloudTrail, you can determine what request was made, the source IP address from which the request was made, who made the request, when it was made, and so on.

AWS KMS integrates natively with many other AWS services to make monitoring easy.

You can use these AWS services, or your existing security tool suite, to monitor your CloudTrail logs for specific actions such as ScheduleKeyDeletion, PutKeyPolicy, DeleteAlias, DisableKey, DeleteImportedKeyMaterial on your KMS key. Furthermore, AWS KMS emits Amazon CloudWatch Events when your CMK is rotated, deleted, and imported key material in your CMK expires.

CMK Use Validation

In addition to capturing audit data associated with key management and use, you should ensure that the data you are reviewing aligns with your established best practices and policies. One method is to continuously monitor and verify the CloudTrail logs as they come in.

Another method is to use AWS Config rules. By using AWS Config rules you can ensure that the configuration of many of the AWS services are set up appropriately.

For example, with EBS volumes you can use the AWS Config rule ENCRYPTED_VOLUMES to validate that attached EBS volumes are encrypted.

A CMK can have a tag applied to it for a variety of purposes.

The most common use is to correlate a specific CMK back to a business category (such as a cost center, application name, or owner).

The tags can then be used to verify that the correct CMK is being used for a given action.

For example, in CloudTrail logs, for a given KMS action you can verify that the CMK being used belongs to the same business category as the resource that it’s being used on. Previously, this might have required a look up within a resource catalog, but now this external lookup is not required because of tagging within AWS KMS as well as many of the other AWS services.

Infrastructure Security

The Infrastructure Security capability provides you with best practices on how to configure AWS KMS to ensure that you have an agile implementation that can scale with your business while protecting your sensitive information.

Customer Master Keys

Within AWS KMS, your key hierarchy starts with a CMK. A CMK can be used to directly encrypt data blocks up to 4 KB or it can be used to secure data keys, which protect underlying data of any size.

CMKs can be broken down into two general types: AWS-managed and customer-managed.

An AWSmanaged CMK is created when you choose to enable server-side encryption of an AWS resource under the AWS-managed CMK for that service for the first time (e.g., SSE-KMS).

The AWS-managed CMK is unique to your AWS account and the Region in which it’s used.

An AWS-managed CMK can only be used to protect resources within the specific AWS service for which it’s created. It does not provide the level of granular control that a customer-managed CMK provides.

For more control, a best practice is to use a customer-managed CMK in all supported AWS services and in your applications. A customer-managed CMK is created at your request and should be configured based upon your explicit use case.

Key Creation and Management

Since AWS makes creating and managing keys easy through the use of AWS KMS, we recommend that you have a plan for how to use the service to best control the blast radius around individual keys.

Previously, you may have used the same key across different geographic regions, environments, or even applications. With AWS KMS, you should define data classification levels and have at least one CMK per level.

For example, you could define a CMK for data classified as “Confidential,” and so on. This ensures that authorized users only have permissions for the key material that they require to complete their job.

You should also decide how you want to manage usage of AWS KMS.

Creating KMS keys within each account that requires the ability to encrypt and decrypt sensitive data works best for most customers, but another option is to share the CMKs from a few centralized accounts.

Maintaining the CMKs in the same account as the majority of the infrastructure using them helps users provision and run AWS services that use those keys. AWS services don’t allow for cross-account searching unless the principal doing the searching has explicit List* permissions on resources owned by the external account.

This can also only be accomplished via the CLI or SDK, and not through service console-based searches. Additionally, by storing the credentials in the local accounts, it might be easier to delegate permissions to individuals who know the IAM principals that require access to the specific CMKs.

If you were sharing the keys via a centralized model, the AWS KMS administrators would need to know the full Amazon Resource Name (ARN) for all users of the CMKs to ensure least privilege.

Otherwise, the administrators might provide overly permissive permissions on the keys.

Key Aliases

A key alias allows you to abstract key users away from the underlying Region-specific key ID and key ARN.

Authorized individuals can create a key alias that allows their applications to use a specific CMK independent of the Region or rotation schedule.

Thus, multi-Region applications can use the same key alias to refer to KMS keys in multiple Regions without worrying about the key ID or the key ARN.

You can also trigger manual rotation of a CMK by pointing a given key alias to a different CMK. Similar to how Domain Name Services (DNS) allows the abstraction of IP addresses, a key alias does the same for the key ID.

When you are creating a key alias, we recommend that you determine a naming scheme that can be applied across your accounts such as alias/Environment-Function-Service Team.

It should be noted that CMK aliases can’t be used within policies. This is because the mapping of aliases to keys can be manipulated outside the policy, which would allow for an escalation of privilege. Therefore, key IDs must be used in KMS key policies, IAM policies, and KMS grants.

Using AWS KMS at Scale

AWS recommends using envelope encryption to scale your KMS implementation. Envelope encryption is the practice of encrypting plaintext data with a unique data key, and then encrypting the data key with a key encryption key (KEK). Within AWS KMS, the CMK is the KEK.

You can encrypt your message with the data key and then encrypt the data key with the CMK. Then the encrypted data key can be stored along with the encrypted message.

You can cache the plaintext version of the data key for repeated use, reducing the number of requests to AWS KMS. Additionally, envelope encryption can help to design your application for disaster recovery. You can move your encrypted data as-is between Regions and only have to re-encrypt the data keys with the Region-specific CMKs.

Data Protection

The Data Protection capability addresses some of the common AWS use cases for using AWS KMS within your organization to protect your sensitive information.

Common AWS KMS Use Cases

Encrypting PCI Data Using AWS KMS

Since security and quality controls in AWS KMS have been validated and certified to meet the requirements of PCI DSS Level 1 certification, you can directly encrypt Primary Account Number (PAN) data with an AWS KMS CMK.

The use of a CMK to directly encrypt data removes some of the burden of managing encryption libraries.

Additionally, a CMK can’t be exported from AWS KMS, which alleviates the concern about the encryption key being stored in an insecure manner. As all KMS requests are logged in CloudTrail, use of the CMK can be audited by reviewing the CloudTrail logs.

It’s important to be aware of the requests per second limit when designing applications that use the CMK directly to protect Payment Card Industry (PCI) data.

Secret Management Using AWS KMS and Amazon S3

Although AWS KMS primarily provides key management functions, you can leverage AWS KMS and Amazon S3 to build your own secret management solution.

Create a new Amazon s3 bucket to hold your secrets. Deploy a bucket policy onto the bucket to limit access to only authorized individuals and services. The secrets stored in the bucket utilize a predefined prefix per file to allow for granular control of access to the secrets.

Each secret, when placed in the S3 bucket, is encrypted using a specific customer-managed KMS key. Furthermore, due to the highly sensitive nature of the information being stored within this bucket, S3 access logging or CloudTrail Data Events are enabled for audit purposes. Then, when a user or service requires access to the secret, they assume an identity within AWS that has permissions to use both the object in the S3 bucket as well as the KMS key. An application that runs in an EC2 instance uses an instance role that has the necessary permissions.

Encrypting Lambda Environment Variables

By default, when you create or update Lambda functions that use environment variables, those variables are encrypted using AWS KMS. When your Lambda function is invoked, those values are decrypted and made available to the Lambda code. You have the option to use the default KMS key for Lambda or specify a specific CMK of your choice.

To further protect your environment variables, you should select the “Enable encryption helpers” checkbox. By selecting this option, your environment variables will also be individually encrypted using a CMK of your choice, and then your Lambda function will have to specifically decrypt each encrypted environment variable that is needed.

Encrypting Data within Systems Manager Parameter Store

Amazon EC2 Systems Manager is a collection of capabilities that can help you automate management tasks at scale.

To efficiently store and reference sensitive configuration data such as passwords, license keys, and certificates, the Parameter Store lets you protect sensitive information within secure string parameters.

A secure string is any sensitive data that needs to be stored and referenced in a secure manner.

If you have data that you don't want users to alter or reference in clear text, such as domain join passwords or license keys, then specify those values using the Secure String data type. You should use secure strings in the following circumstances:

• You want to use data/parameters across AWS services without exposing the values as clear text in commands, functions, agent logs, or CloudTrail logs.
• You want to control who has access to sensitive data.
• You want to be able to audit when sensitive data is accessed using CloudTrail.
• You want AWS-level encryption for your sensitive data and you want to bring your own encryption keys to manage access.

By selecting this option when you create your parameter, the Systems Manager encrypts that value when it’s passed into a command and decrypts it when processing it on the managed instance. The encryption is handled by AWS KMS and can be either a default KMS key for the Systems Manager or you can specify a specific CMK per parameter.

Enforcing Data at Rest Encryption within AWS Services

Your organization might require the encryption of all data that meets a specific classification. Depending on the specific service, you can enforce data encryption policies through preventative or detective controls. For some services like Amazon S3, a policy can prevent storing unencrypted data. For other services, the most efficient mechanism is to monitor the creation of storage resources and check whether encryption is enabled appropriately. In the event that unencrypted storage is created, you have a number of possible responses ranging from deleting the storage resource to notifying an administrator.

Conclusion

AWS KMS provides your organization with a fully managed service to centrally control your encryption keys. Its native integration with other AWS services makes it easier for AWS KMS to encrypt the data that you store and process.

By taking the time to properly architect and implement AWS KMS, you can ensure that your encryption keys are secure and available for applications and their authorized users. Additionally, you can show your auditors detailed logs associated with your key usage.

Reference

Original paper

1. Machine learning: From front end to inference

Explore a real-world scenario for creating an end-to-end solution using machine learning in this lab. Create a web front end that receives user input and evaluates it using a machine learning model. Then, create and run a machine learning backend application using different AWS services.

2. Develop your ML project with Amazon SageMaker

Learn how to use Amazon SageMaker to create a whole machine learning project from start to finish in this workshop. With SageMaker Data Wrangler, get started with data exploration and analysis, data purification, and feature engineering. After that, save features in SageMaker Feature Store, extract features for training with SageMaker Processing, train a model with SageMaker training, and finally deploy it with SageMaker hosting. Learn to utilise SageMaker Studio as an IDE and SageMaker Pipelines to orchestrate the machine learning workflow.

3. Get started with AWS computer vision services

We can use computer vision to improve our ability to comprehend the visual world around us. This session will provide you an overview of AWS computer vision services and show you how these pre-trained and configurable machine learning (ML) capabilities can help you get up and running quickly, even if you don't have any ML experience. Learn how to install these models on your preferred device and execute inferences locally, or how to use cloud APIs for your specific computing requirements. Investigate how AWS clients such as Shutterstock, Mirror, Tyson, and Persona use the AWS machine vision edge and cloud models for media analysis, content control, and quality inspection.

4. Applying AWS machine learning to next-gen DevOps

While DevOps technology has advanced significantly in recent years, it remains challenging. Concurrency, security, and the handling of sensitive data all necessitate expert judgement and frequently elude established techniques such as peer code reviews and unit testing. Even for companies that can afford to hire experienced code reviewers, the rapid pace at which software is generated generates large volumes of complex code that are impossible to manually examine. Learn how the AWS next-gen DevOps portfolio may assist enhance your developer's experience with machine learning (ML) capabilities to construct automation and more proactive methods that enable teams to innovate faster and with confidence by attending this chalk presentation.

5. Prepare data for ML with ease, speed, and accuracy

In this session you will discover how to use Amazon SageMaker to prepare data for machine learning in minutes. SageMaker provides data preparation tools that make it easier to label, prepare, and analyse your data. Walk through a complete data-preparation workflow, including how to use SageMaker Ground Truth to label training datasets, as well as how to extract data from numerous data sources, convert it using SageMaker Data Wrangler's prebuilt visualisation templates, and construct model features. Learn how to use SageMaker Feature Store to establish a repository for storing, retrieving, and sharing features to increase productivity.

Introduction

• Amazon Aurora MySQL (Aurora MySQL) is a managed relational database engine, wire-compatible with MySQL 5.6 and 5.7. Most of the drivers, connectors, and tools that you currently use with MySQL can be used with Aurora MySQL with little or no change.

• Aurora MySQL database (DB) clusters provide advanced features such as:

  • One primary instance that supports read/write operations and up to 15 Aurora Replicas that support read-only operations.

  • Each of the Replicas can be automatically promoted to the primary role if the current primary instance fails.

  • A cluster endpoint that automatically follows the primary instance in case of failover.

  • A reader endpoint that includes all Aurora Replicas and is automatically updated when Aurora Replicas are added or removed.

  • Ability to create custom DNS endpoints containing a user-configured group of database instances within a single cluster.

  • Internal server connection pooling and thread multiplexing for improved scalability.

DNS endpoints

• An Aurora DB cluster consists of one or more instances and a cluster volume that manages the data for those instances.

• There are two types of instances:

  • Primary instance – Supports read and write statements. Currently, there can be one primary instance per DB cluster.

  • Aurora Replica – Supports read-only statements.

    • A DB cluster can have up to 15 Aurora Replicas.
    • The Aurora Replicas can be used for read scaling, and are automatically used as failover targets in case of a primary instance failure.

• Amazon Aurora supports the following types of Domain Name System (DNS) endpoints:

  • Cluster endpoint – Connects you to the primary instance and automatically follows the primary instance in case of failover, that is, when the current primary instance is demoted and one of the Aurora Replicas is promoted in its place.

  • Reader endpoint – Includes all Aurora Replicas in the DB cluster under a single DNS CNAME. You can use the reader endpoint to implement DNS round robin load balancing for read-only connections.

  • Instance endpoint – Each instance in the DB cluster has its own individual endpoint. You can use this endpoint to connect directly to a specific instance.

  • Custom endpoints – User-defined DNS endpoints containing a selected group of instances from a given cluster.

Connection handling in Aurora MySQL and MySQL

• MySQL Community Edition manages connections in a one-thread-per-connection fashion.
• This means that each individual user connection receives a dedicated operating system thread in the mysqld process.

• Issues with this type of connection handling include:

  • Relatively high memory use when there is a large number of user connections, even if the connections are completely idle.
  • Higher internal server contention and context switching overhead when working with thousands of user connections.

Common misconceptions

The following are common misconceptions for database connection management:

• If the server uses connection pooling, you don’t need a pool on the application side. This isn’t true for workloads where connections are opened and torn down very frequently, and clients run relatively few statements per connection.

• Idle connections don’t use memory. This isn’t true because the operating system and the database process both allocate an in-memory descriptor for each user connection. What is typically true is that Aurora MySQL uses less memory than MySQL Community Edition to maintain the same number of connections. However, memory usage for idle connections is still not zero, even with Aurora MySQL.

• Downtime depends entirely on database stability and database features. This isn’t true because the application design and configuration play an important role in determining how fast user traffic can recover following a database event.

Best practices

The following are best practices for managing database connections and configuring connection drivers and pools.

Using smart drivers

The cluster and reader endpoints abstract the role changes and topology changes occurring in the DB cluster. However, DNS updates are not instantaneous.

In addition, they can sometimes contribute to a slightly longer delay between the time a database event occurs and the time it’s noticed and handled by the application.

Aurora MySQL exposes near-real-time metadata about DB instances in the INFORMATION_SCHEMA.REPLICA_HOST_STATUS table.

mysql> select server_id, if(session_id = 'MASTER_SESSION_ID',
'writer', 'reader') as role, replica_lag_in_milliseconds from
information_schema.replica_host_status;

+-------------------+--------+-----------------------------+
| server_id | role | replica_lag_in_milliseconds |
+-------------------+--------+-----------------------------+
| aurora-node-usw2a | writer | 0 |
| aurora-node-usw2b | reader | 19.253999710083008 |
+-------------------+--------+-----------------------------+
2 rows in set (0.00 sec)

For the purpose of this whitepaper, a smart driver is a database driver or connector with the ability to read DB cluster topology from the metadata table.

It can route new connections to individual instance endpoints without relying on high-level cluster endpoints.

A smart driver is also typically capable of load balancing read-only connections across the available Aurora Replicas in a round robin fashion.

The MariaDB Connector/J is an example of a third-party Java Database Connectivity (JDBC) smart driver with native support for Aurora MySQL DB clusters.

Application developers can draw inspiration from the MariaDB driver to build drivers and connectors for languages other than Java.

It’s a good idea to evaluate the use of smart drivers in your setup.

Note that if a thirdparty driver contains Aurora MySQL–specific functionality, it doesn’t mean that it has been officially tested, validated, or certified by AWS.

Also note that due to the advanced built-in features and higher overall complexity, smart drivers are likely to receive updates and bug fixes more frequently than traditional (bare bones) drivers.

You should regularly review the driver’s release notes and use the latest available version whenever possible.

DNS caching

Unless you use a smart database driver, you depend on DNS record updates and DNS propagation for failovers, instance scaling, and load balancing across Aurora Replicas.

Currently, Aurora DNS zones use a short Time-To-Live (TTL) of five seconds.

Ensure that your network and client configurations don’t further increase the DNS cache TTL.

Remember that DNS caching can occur anywhere from your network layer, through the operating system, to the application container.

For example, Java virtual machines (JVMs) are notorious for caching DNS indefinitely unless configured otherwise.

Here are some examples of issues that can occur if you don’t follow DNS caching best practices:

• After a new primary instance is promoted during a failover, applications continue to send write traffic to the old instance.

• Data-modifying statements will fail because that instance is no longer the primary instance.

• After a DB instance is scaled up or down, applications are unable to connect to it.

• Due to DNS caching, applications continue to use the old IP address of that instance, which is no longer valid.

• Aurora Replicas can experience unequal utilization, for example, one DB instance receiving significantly more traffic than the others.

Connection management and pooling

Always close database connections explicitly instead of relying on the development framework or language destructors to do it.

There are situations, especially in container based or code-as-a-service scenarios, when the underlying code container isn’t immediately destroyed after the code completes.

In such cases, you might experience database connection leaks where connections are left open and continue to hold resources (for example, memory and locks).

Connection scaling

The most common technique for scaling web service capacity is to add or remove application instances in response to changes in user traffic.

Each application server can use a database connection pool.

This approach causes the total number of database connections to grow proportionally with the number of application instances.

For example, 20 application servers configured with 200 database connections each would require a total of 4,000 database connections.

If the application pool scales up to 200 instances (for example, during peak hours), the total connection count will reach 40,000. Under a typical web application workload, most of these connections are likely idle.

In extreme cases, this can limit database scalability: idle connections do take server resources, and you’re opening significantly more of them than you need.

Also, the total number of connections is not easy to control because it’s not something you configure directly, but rather depends on the number of application servers.

• Tune the connection pools on application instances. Reduce the number of connections in the pool to the acceptable minimum.

• This can be a stop-gap solution, but it might not be a long-term solution as your application server fleet continues to grow.

• Introduce a connection proxy between the database and the application.

• On one side, the proxy connects to the database with a fixed number of connections.
• On the other side, the proxy accepts application connections and can provide additional features such as query caching, connection buffering, query rewriting/routing, and load balancing.

Transaction management and autocommit

With autocommit enabled, each SQL statement runs within its own transaction.

When the statement ends, the transaction ends as well. Between statements, the client connection is not in transaction.

If you need a transaction to remain open for more than one statement, you explicitly begin the transaction, run the statements, and then commit or roll back the transaction.

With autocommit disabled, the connection is always in transaction.

You can commit or roll back the current transaction, at which point the server immediately opens a new one.

Running with autocommit disabled is not recommended because it encourages longrunning transactions where they’re not needed.

Recommendations:

• Always run with autocommit mode enabled. Set the autocommit parameter to 1 on the database side (which is the default) and on the application side (which might not be the default).

• Always double-check the autocommit settings on the application side. For example, Python drivers such as MySQLdb and PyMySQL disable autocommit by default.

• Manage transactions explicitly by using BEGIN/START TRANSACTION and COMMIT/ROLLBACK statements. You should start transactions when you need them and commit as soon as the transactional work is done.

Connection handshakes

A lot of work can happen behind the scenes when an application connector or a GUI tool opens a new database session.

Drivers and client tools commonly run series of statements to set up session configuration (e.g, SET SESSION variable = value).

This increases the cost of creating new connections and delays when your application can start issuing queries.

The cost of connection handshakes becomes even more important if your applications are very sensitive to latency.

OLTP or key-value workloads that expect single-digit millisecond latency can be visibly impacted if each connection is expensive to open.

For example, if the driver runs six statements to set up a connection and each statement takes just one millisecond to run, your application will be delayed by six milliseconds before it issues its first query.

Load balancing with the reader endpoint

Because the reader endpoint contains all Aurora Replicas, it can provide DNS-based, round robin load balancing for new connections. Every time you resolve the reader endpoint, you'll get an instance IP that you can connect to, chosen in round robin fashion.

DNS load balancing works at the connection level (not the individual query level). You must keep resolving the endpoint without caching DNS to get a different instance IP on each resolution.

Designing for fault tolerance and quick recovery

In large-scale database operations, you’re statistically more likely to experience issues such as connection interruptions or hardware failures. You must also take operational actions more frequently, such as scaling, adding, or removing DB instances and performing software upgrades. The only scalable way of addressing this challenge is to assume that issues and changes will occur and design your applications accordingly.

Server configuration

There are two major server configuration variables worth mentioning in the context of this whitepaper: max_connections and max_connect_errors.

Configuration variable max_connections

The configuration variable max_connections limits the number of database connections per Aurora DB instance.

The best practice is to set it slightly higher than the maximum number of connections you expect to open on each instance.

If you also enabled performance_schema, be extra careful with the setting.

The Performance Schema memory structures are sized automatically based on server configuration variables, including max_connections.

The higher you set the variable, the more memory Performance Schema uses.

In extreme cases, this can lead to out-ofmemory issues on smaller instance types.

Configuration variable max_connect_errors

The configuration variable max_connect_errors determines how many successive interrupted connection requests are permitted from a given client host.

If the client host exceeds the number of successive failed connection attempts, the server blocks it.

Conclusion

Understanding and implementing connection management best practices is critical to achieve scalability, reduce downtime, and ensure smooth integration between the application and database layers. You can apply most of the recommendations provided in this whitepaper with little to no engineering effort. The guidance provided in this whitepaper should help you introduce improvements in your current and future application deployments using Aurora MySQL DB clusters.

Reference

Original paper

In this part, we will handle infrastructure review of all app.

Once the application is pushed to the Repository, the CodePipeline will be triggered and CodeBuild will run the set of commands to dockerize the application and push it to the Amazon ECR repository.

CodeBuild will in turn run the kubectl commands to create the Blue and Green services on the EKS clusters if it does not exist.

For the first time, it will pull the Flask demo Application from the Dockerhub and deploy it on Blue as well as Green service. It should say "Your Flask application is now running on a container in Amazon Web Services" as shown below:

In rare conditions, it may occur that Blue and Green service shows the same output of "Amazon Web Services", depending upon the timing of the first initial release-changes propagating through the CodePipeline.

However, in subsequent runs, it will deploy the Codebuild created an application on the Green service only and the updated text will show "Amazon EKS" instead of "Amazon Web Services".

This change in text is introduced by the amazon-eks-cicd-codebuild-eks-bg/flask-docker-app/Dockerfile with the line setting the "ENV PLATFORM".

Once done, the CodePipeline will remain blocked by the Approval Stage.

ACCESS EKS

We will access the EKS resources via 2 methods shown below:

(a) Review via AWS Console:

Go to Services -> EKS -> Clusters -> Select the Cluster and confirm its Status is “Active”.

Go to Services -> EC2 -> Instances -> Ensure the EKS worker nodes (EC2) are in “running” state.

Go to the Services -> EC2 -> Load Balancer Ensure that the correct Load-Balancer is selected: Go to the Load Balancer -> “Listeners” tab -> Review the Listener rules.

Now under Load Balancing -> Target groups, select the Monitoring Tab -> Ensure that both the EKS worker nodes are “healthy”. It takes a few minutes after the application is deployed to have the Instances become “healthy”.

From the Description tab, note down the DNS name for accessing the application. This allows for the users to access and test the application deployed on the Green Service.

Thus if dns name is “dns-alb”, this application can be accessed via:

http://dns-alb.us-east-2.elb.amazonaws.com/?group=green

``

(b) Review via Terminal CLI:

If not already done in the earlier step, access the EKS cluster from your Cloud9 Terminal and run the command that is provided in the output of the CloudFormation under the field “ClusterConfigCommand”. Copy-paste this command so that your kubectl commands will point to the required EKS Cluster. Once the config command is run, execute the following commands:

kubectl get nodes -n flask-alb

kubectl get deploy -n flask-alb

kubectl get pods -n flask-alb

kubectl get svc -n flask-alb

kubectl get ingress -n flask-alb

CHECK CODEPIPELINE

Go to Services -> CodePipeline -> Pipelines -> CdkStackEksALBBg-[unique-string] Review the Stages and the CodeBuild Projects to understand the implementation. Once the Application is deployed on the Green service, access it as mentioned above: http://?group=green.

It is to be noted that container exposes port 5000, whereas service exposes port 80 (for blue-service) OR 8080 (for green-service) which in turn is mapped to local host port on the EC2 worker node instance.

After testing is completed, go to the Approval Stage and Click Approve. This will trigger the CodePipeline to execute the next stage to run the “Swap and Deploy” stage where it swaps the mapping of target-group to the blue / green service. Thus now access the Application via Blue Service and confirm if the updated application is reflected correctly.

In the next part, we will handle the code change and canary deployment. Stay tuned! :)