[{"content":"","date":"6 November 2024","permalink":"/tags/automation/","section":"Tags","summary":"","title":"automation"},{"content":"","date":"6 November 2024","permalink":"/categories/automation/","section":"Categories","summary":"","title":"Automation"},{"content":"","date":"6 November 2024","permalink":"/tags/aws/","section":"Tags","summary":"","title":"aws"},{"content":"","date":"6 November 2024","permalink":"/categories/aws/","section":"Categories","summary":"","title":"AWS"},{"content":"When setting up access to your AWS accounts governed by AWS Control Tower, you have two options:\nAllow Control Tower to configure account access with IAM Identity Center. Configure IAM Identity Center or another access method yourself. If you decide to let Control Tower manage account access with IAM Identity Center, the setup process can be straightforward or complex, depending on your Control Tower configuration. For instance, using CDK can make the process less smooth.\nIn this article, we’ll explore how to properly set up AWS account access with IAM Identity Center when deploying the Landing Zone via CDK.\nIn case you’re unfamiliar, AWS Control Tower is a service that simplifies the provisioning, setup, and governance of a secure, multi-account AWS environment, known as a Landing Zone. For more information, consult the Control Tower User Guide.\nIAM Identity Center configuration using the console # As shown in the image below, configuring IAM Identity Center through the console is as simple as selecting an option. AWS Control Tower will handle:\nEnabling IAM Identity Center if it isn’t already enabled. Creating a preconfigured directory with user groups and permission sets. Setting up essential user groups and permission sets. Naturally, I expected the same streamlined experience with CDK—but this wasn’t exactly the case.\nIAM Identity Center Configuration When Deploying Control Tower with CDK # First of all, CDK currently lacks an L2 construct for Control Tower ( AWS CDK documentation). This means you’ll need to use an L1 construct instead. If you’re unfamiliar with CDK constructs, refer to the constructs documentation.\nBasically, L1 constructs map directly to individual AWS CloudFormation resources, so you’ll need to reference CloudFormation resources and configure properties accordingly.\nLet’s review the Control Tower Landing Zone CloudFormation reference:\nType: AWS::ControlTower::LandingZone Properties: Manifest: Tags: - Tag Version: String Among the properites, Manifest and Version are required. The Manifest property specifies the Landing Zone configuration, but there’s little documentation explaining the necessary configurations for it. 💔\nTo be honest, I had a hard time finding clear documentation on the manifest file. This page was all I found, but it lacks a detailed explanation of each property. For instance, it’s not immediately clear that the accessManagement.enable property enables IAM Identity Center.\nBelow is an example of the Landing Zone CDK resource configuration:\nconst landingZone = new CfnLandingZone(this, \u0026#39;LandingZone\u0026#39;, { manifest: { ... accessManagement: { enabled: true } ... }, version: \u0026#39;3.3\u0026#39; }) Setting accessManagement.enable to true instructs Control Tower to create the user groups and permission sets, but it doesn’t actually enable IAM Identity Center. This resulted in the following error:\nError AWS Control Tower failed to set up your landing zone completely: The management account does not contain an IAM Identity Center directory. This means I needed to enable IAM Identity Center first.\nEnabling IAM Identity Center # Since I was using CDK, my initial approach was to create an IAM Identity Center instance in my CDK stack. However, I had to abandon this idea quickly.\nThe documentation for AWS::SSO::Instance states that you can only create an instance for a standalone AWS account that isn’t managed by AWS Organizations or a member account within an organization—clearly, not my case.\nI looked for alternative ways to enable IAM Identity Center without using the console, as I wanted to avoid manual steps, but had no luck. According to the documentation here:\nTo enable IAM Identity Center, you must sign in to the AWS Management Console as a user with administrative credentials in your AWS Organizations management account. Thus, it appears the console is the only option.\nTo enable it, go to the IAM Identity Center dashboard and click on Enable. It only takes a few seconds.\nOnce enabled, you’ll notice no user groups or permission sets are yet available. But no worries, Control Tower will create them.\nNow that IAM Identity Center is enabled, I could proceed with deploying Control Tower.\nThe deployment succeeded, and I confirmed that IAM Identity Center was enabled in the Landing Zone settings.\nReturning to the IAM Identity Center dashboard, I saw that Control Tower created:\nThe AWS Control Tower Admin user. 8 user groups. 6 permission sets. Conclusion # Automating Control Tower deployment is convenient but presents some integration challenges with IAM Identity Center. Today, we reviewed ways to address these limitations.\nIf you have feedback or alternate solutions, please reach out via email or LinkedIn.\nThat’s all folks, stay tuned! 🚀\nResources # Control Tower User Guide Working with AWS IAM Identity Center and AWS Control Tower IAM Identity Center and AWS Organizations AWS::ControlTower Construct Library AWS::SSO::Instance Reference ","date":"6 November 2024","permalink":"/posts/deploying-control-tower-with-cdk-iam-identity-center-integration/","section":"Posts","summary":"When setting up access to your AWS accounts governed by AWS Control Tower, you have two options:\nAllow Control Tower to configure account access with IAM Identity Center. Configure IAM Identity Center or another access method yourself. If you decide to let Control Tower manage account access with IAM Identity Center, the setup process can be straightforward or complex, depending on your Control Tower configuration.","title":"AWS Control Tower with CDK: set up IAM Identity Center"},{"content":"","date":"6 November 2024","permalink":"/tags/awscommunity/","section":"Tags","summary":"","title":"awscommunity"},{"content":"","date":"6 November 2024","permalink":"/categories/","section":"Categories","summary":"","title":"Categories"},{"content":"","date":"6 November 2024","permalink":"/tags/cdk/","section":"Tags","summary":"","title":"cdk"},{"content":"","date":"6 November 2024","permalink":"/categories/cdk/","section":"Categories","summary":"","title":"CDK"},{"content":"","date":"6 November 2024","permalink":"/tags/controltower/","section":"Tags","summary":"","title":"controltower"},{"content":"","date":"6 November 2024","permalink":"/categories/controltower/","section":"Categories","summary":"","title":"ControlTower"},{"content":"","date":"6 November 2024","permalink":"/tags/governance/","section":"Tags","summary":"","title":"governance"},{"content":"","date":"6 November 2024","permalink":"/tags/iamidentitycenter/","section":"Tags","summary":"","title":"iamidentitycenter"},{"content":"","date":"6 November 2024","permalink":"/categories/iamidentitycenter/","section":"Categories","summary":"","title":"IAMIdentityCenter"},{"content":"Here you will find all posts grouped by year.\n","date":"6 November 2024","permalink":"/posts/","section":"Posts","summary":"Here you will find all posts grouped by year.","title":"Posts"},{"content":"","date":"6 November 2024","permalink":"/tags/","section":"Tags","summary":"","title":"Tags"},{"content":"","date":"6 November 2024","permalink":"/","section":"The-indie-coder","summary":"","title":"The-indie-coder"},{"content":"","date":"20 April 2024","permalink":"/tags/lambda/","section":"Tags","summary":"","title":"lambda"},{"content":"","date":"20 April 2024","permalink":"/categories/lambda/","section":"Categories","summary":"","title":"Lambda"},{"content":"","date":"20 April 2024","permalink":"/tags/lambdaextension/","section":"Tags","summary":"","title":"lambdaextension"},{"content":"","date":"20 April 2024","permalink":"/tags/optimization/","section":"Tags","summary":"","title":"optimization"},{"content":"","date":"20 April 2024","permalink":"/tags/performance/","section":"Tags","summary":"","title":"performance"},{"content":"","date":"20 April 2024","permalink":"/categories/performance-and-optimiztion/","section":"Categories","summary":"","title":"Performance and Optimiztion"},{"content":"More than one and half year ago AWS announced the launch of the AWS Parameters and Secrets Lambda Extension.\nThis extension allows you to retrieve secrets and parameters from AWS Secrets Manager and AWS Systems Manager, respectively, without using the APIs. By doing so, you can avoid the associated costs and the need to manage the caching of values manually.\nThe announcement claims that using these extensions instead of the APIs can improve performance and decrease costs.\nTo verify the accuracy of these claims, I decided to use AWS Lambda Power Tuning, specifically leveraging the comparison function provided by the UI tool.\nIs it true that using Lambda Extensions will improve performance and decrease costs?\nLet\u0026rsquo;s find out!\nThe tool for the test: AWS Lambda Power Tuning # AWS Lambda Power Tuning is a user-friendly and opensource tool that helps you to improve the performance of your Lambda functions.\nYou simply specify the Lambda function you want to enhance and the memory values you want to test. Then, the tool runs multiple versions of your function with different memory settings. It measures their execution time and calculates the associated costs, providing insights into performance improvements.\nYou can find comprehensive documentation on how to deploy and execute AWS Lambda Power Tuning in the repo linked below.\nalexcasalboni/aws-lambda-power-tuning AWS Lambda Power Tuning is an open-source tool that can help you visualize and fine-tune the memory/power configuration of Lambda functions. It runs in your own AWS account - powered by AWS Step Functions - and it supports three optimization strategies: cost, speed, and balanced. JavaScript 5467 378 The test # For this test, I have created two lambdas:\ngetSecretWithSecretsManagerAPI: it retrieves the secret using the Secrets Manager API (sdk v3). getSecretWithLambdaExtension: it retrieves the secret using the Secrets Lambda Extension. Both functions:\nUse nodejs20.x runtime Use arm64 architecture Are deployed in eu-west-1 region To perform the test, I configured and executed an AWS Step Functions state machine. The state machine allowed me to specify memory values to allocate to the Lambda functions. I chose to run the state machine for memory values ranging from 128 MB to 3008 MB.\nAfter running the state machine once for each Lambda function, I used the tool\u0026rsquo;s UI to compare the results.\nWhile understanding AWS Step Functions is not necessary for comprehending the results of this article, it\u0026rsquo;s worth mentioning how the test was conducted for transparency. The focus here is on interpreting the test results rather than the technical details of the testing process. The results # The execution time for the lambda that retrieves the secret using the Secrets Manager API varies from 46 seconds with 128 MB to 24 seconds with 512 MB. Beyond 512 MB, the execution time remains more or less stable at 24 seconds.\nOn the other hand, the execution time for the lambda that retrieves the secret using Lambda Extension ranges from 23 milliseconds with 128 MB to 5 seconds with 512 MB. Beyond 512 MB, the execution time remains stable at around 5 seconds.\nThe test confirms the expectations: the lambda that retrieves the secret using Lambda Extension is always more performant and cheaper than the lambda that retrieves the secret using Secrets Manager API.\nBelow are two tables comparing the execution time and costs for the two functions.\nOn average, the Lambda function that uses Lambda Extension to retrieve the secret is 282% faster than the one using the Secrets Manager API.\nOn average, the Lambda that uses Lambda Extension to retrieve the secret is 271% cheaper than the one using Secrets Manager API.\nConclusions # At the beginning of the article we aimed to answer to the question:\nIs it true that using Lambda Extensions will improve performance and decrease costs?\nThe test show that yes, using Lambda Extension for retrieving secrets from Secrets Manager is consistently faster and more cost-effective across different memory configurations.\nThat\u0026rsquo;s all folks! 🚀\nIf you have questions or would like to provide feedback, email me at martina.theindiecoder@gmail.com.\nResources # AWS Parameters and Secrets Lambda Extension announcement\nAWS Lambda Power Tuning tool\nUse AWS Secrets Manager secrets in AWS Lambda functions\n","date":"20 April 2024","permalink":"/posts/secrets-manager-api-vs-lambda-extension/","section":"Posts","summary":"More than one and half year ago AWS announced the launch of the AWS Parameters and Secrets Lambda Extension.\nThis extension allows you to retrieve secrets and parameters from AWS Secrets Manager and AWS Systems Manager, respectively, without using the APIs. By doing so, you can avoid the associated costs and the need to manage the caching of values manually.","title":"Secrets Manager API vs Lambda Extension: performance comparison"},{"content":"","date":"20 April 2024","permalink":"/tags/secretsmanager/","section":"Tags","summary":"","title":"secretsmanager"},{"content":"","date":"20 April 2024","permalink":"/categories/secretsmanager/","section":"Categories","summary":"","title":"SecretsManager"},{"content":"","date":"20 April 2024","permalink":"/tags/serverless/","section":"Tags","summary":"","title":"serverless"},{"content":"","date":"20 April 2024","permalink":"/categories/serverless/","section":"Categories","summary":"","title":"Serverless"},{"content":"","date":"9 April 2024","permalink":"/categories/aws-billing/","section":"Categories","summary":"","title":"AWS Billing"},{"content":"","date":"9 April 2024","permalink":"/tags/billing/","section":"Tags","summary":"","title":"billing"},{"content":"","date":"9 April 2024","permalink":"/tags/costexplorer/","section":"Tags","summary":"","title":"costexplorer"},{"content":"","date":"9 April 2024","permalink":"/categories/costexplorer/","section":"Categories","summary":"","title":"CostExplorer"},{"content":"Recently I began tagging resources in my primary AWS account. I use this account as a playground where I can experiment with services and occasionally host side projects.\nAs I\u0026rsquo;ve recently hosted new projects, I figured it was time to have a better understanding of costs, hence the decision to implement tagging.\nAWS offers a suite of services and tools called Cloud Financial Management, among which is AWS Cost Explorer.\nAWS Cost Explorer is a tool that allows you to analyze the costs and usage of your AWS resources. It provides a user-friendly interface to visualize your data, allowing you to manipulate several parameters to customize your reports. You can adjust the time period, group data by various dimensions, and filter data based on different criteria.\nOne such criterion for grouping and filtering data is Tags.\nSo I tagged my resources, but I was surprised to realize that the tags were not included among the filters.\nTurns out, you have to activate tags to make them show up.\nIn many projects I\u0026rsquo;ve worked on, there\u0026rsquo;s usually a team that handles costs behind the scenes. So even though I\u0026rsquo;ve spent a lot of time with AWS Cost Explorer, I didn\u0026rsquo;t realize I needed to activate tags myself.\nLet\u0026rsquo;s see how to enable tags for cost allocation.\nEnabling tags for billing # Log in into your console and navigate to Billing and Cost Management.\nIn the side menu, go to the Cost Organization section and click on Cost Allocation Tags.\nYou will see a view with two tabs:\nUser-defined cost allocation tags: where tags defined by you are listed. AWS generated cost allocation tags: where tags automatically generated by AWS, depending on the services you\u0026rsquo;ve used, are listed. Example:\nAs mentioned before, this is my experimental account, so the tags I\u0026rsquo;ve created are somewhat random. I recommend utilizing tag categories suggested by AWS You can find them here. Select the tags you would like to activate and click on Activate button. The activation was not retroactive until the 27th of March 2024, when it was announced the support for it up to twelve months.\nThe retroactive application is not automatic. You can read more about how to request a backfill of cost allocation tags here.\nHere the retroactive application announcement.\nConclusions # This quick article reminded you to activate tags explicitly if you want to use them for cost allocation and showed you how to do it.\nI hope you find this post helpful. See you next time folks! 🚀\nReferences # AWS Cost Explorer\nActivating user-defined cost allocation tags\nRetroactive application announcement\nBackfill cost allocation tags\n","date":"9 April 2024","permalink":"/posts/enabling-aws-tags-for-billing/","section":"Posts","summary":"Recently I began tagging resources in my primary AWS account. I use this account as a playground where I can experiment with services and occasionally host side projects.\nAs I\u0026rsquo;ve recently hosted new projects, I figured it was time to have a better understanding of costs, hence the decision to implement tagging.","title":"Enabling AWS tags for billing"},{"content":"","date":"9 April 2024","permalink":"/tags/tagging/","section":"Tags","summary":"","title":"tagging"},{"content":"","date":"9 April 2024","permalink":"/categories/vscode/","section":"Categories","summary":"","title":"VSCode"},{"content":"","date":"28 January 2024","permalink":"/authors/","section":"Authors","summary":"","title":"Authors"},{"content":"","date":"28 January 2024","permalink":"/tags/containers/","section":"Tags","summary":"","title":"containers"},{"content":"","date":"28 January 2024","permalink":"/categories/containers/","section":"Categories","summary":"","title":"Containers"},{"content":"","date":"28 January 2024","permalink":"/tags/redhat/","section":"Tags","summary":"","title":"redhat"},{"content":"","date":"28 January 2024","permalink":"/categories/redhat/","section":"Categories","summary":"","title":"RedHat"},{"content":"Why # The release of applications through lightweight containers has practical advantages, as the images contain all the dependencies necessary for the correct functioning of the application. However, the benefits of containerization can be lost if these images are too large and therefore require several minutes for the application to start.\nIn this post, we\u0026rsquo;ll see how to use Red Hat\u0026rsquo;s Universal Base Images (UBI) as a base to build images for your containers that are lightweight and secure for your applications.\nCreate Applications # Red Hat provides basic images for building cloud-based applications and web applications in containers. With these images, reliability, security, performance, and image lifecycle features are already built in and verified by people working in this company, so you can create a containerized application using a UBI image, push it to your preferred registry, easily share it, and distribute it on platforms other than Red Hat.\nWhat they are # Each UBI image is based on Red Hat Enterprise Linux (alias RHEL), the most widely used enterprise-level Linux distribution of the last two decades. Building the container image on an RHEL software base ensures that the image is reliable, secure, and freely distributable. You don\u0026rsquo;t need to be a Red Hat customer to use or redistribute UBI images: just use them and let Red Hat manage the base images for you at no cost.\nWhere to find them # They are readily available on both the Red Hat Container Catalog and the official Red Hat repository on Docker Hub.\nIf we were to choose between the two options, we should prefer to use the Red Hat Catalog console because it displays various information such as image size, version, security checks, the list of installed packages, the Dockerfile, and various options available for pulling the image.\nWhich image to use # Red Hat\u0026rsquo;s Universal Base Images are offered in different formats:\nMicro: a reduced image that uses the underlying host\u0026rsquo;s package manager to install packages, typically using Buildah or a multi-stage build with Podman. Minimal: defines a reduced image that uses microdnf as the package manager. Standard: an image designed to be the base layer for all containerized applications, middleware, and utilities. Init: designed to run a system with a process ID of 1 (corresponding to the Linux init process) to run multiple services within a container. Example # Let\u0026rsquo;s look at a small use case for Python: we\u0026rsquo;ll use a sample application that we\u0026rsquo;ll package into a UBI image.\nThe code for the sample applications, including the Dockerfile, is available on this GitHub repository.\nHere\u0026rsquo;s the Dockerfile:\nFROM registry.access.redhat.com/ubi8/ubi RUN yum install -y python3.11-pip-wheel python3.11-wheel python3.11-pip; WORKDIR /app COPY ./requirements.txt ./app ./ RUN mkdir -p /.local; \\ chown -R 1001:0 /.local; \\ chmod -R ug+rwX /.local; \\ pip3 install -r requirements.txt; EXPOSE 8000 CMD [\u0026#34;uvicorn\u0026#34;, \u0026#34;main:app\u0026#34;, \u0026#34;--host\u0026#34;, \u0026#34;0.0.0.0\u0026#34;, \u0026#34;--port\u0026#34;, \u0026#34;8000\u0026#34;] For the Python example, we use the official Red Hat UBI standard base image, version 8.\nThe yum command installs the Python executable, while the WORKDIR command specifies the directory where the application is located within the container image, and the RUN command installs dependencies.\nThe COPY command copies the Python requirements file into the UBI image, which will then be used by the RUN command to install dependencies.\nThe EXPOSE command specifies the port on which the application will listen, usually 8000 for FastAPI.\nFinally, the CMD ommand specifies the command that will be executed when the container is run.\nBelow are the commands to build and run the image:\ndocker build -t python-ubi8 . docker images | grep -i python-ubi8 docker run -it -p 8000:8000 -d python-ubi8 The cURL command should return the following response:\ncurl -vk http://localhost:8000 \u0026gt;\u0026gt;\u0026gt; * Trying ::1:8000... * TCP_NODELAY set * Connected to localhost (::1) port 8000 (#0) \u0026gt; GET / HTTP/1.1 \u0026gt; Host: localhost:8000 \u0026gt; User-Agent: curl/7.68.0 \u0026gt; Accept: */* \u0026gt; * Mark bundle as not supporting multiuse \u0026lt; HTTP/1.1 200 OK \u0026lt; date: Mon, 19 Jun 2023 09:22:48 GMT \u0026lt; server: uvicorn \u0026lt; content-length: 18 \u0026lt; content-type: application/json \u0026lt; * Connection #0 to host localhost left intact {\u0026#34;Hello\u0026#34;:\u0026#34;World!\u0026#34;} The final size of the image is only 320 MB:\n$ docker images \u0026gt;\u0026gt;\u0026gt; REPOSITORY TAG IMAGE ID CREATED SIZE python-ubi8 latest 50c12e1ca549 55 minutes ago 320MB Clearly, these sizes could be further reduced by using a minimal UBI image, perhaps with pre-installed Python, as in the following example:\nFROM registry.access.redhat.com/ubi8/ubi-minimal RUN microdnf install -y python3 WORKDIR /app COPY ./requirements.txt ./app ./ RUN python3 -m pip install -r /app/requirements.txt EXPOSE 8000 CMD [\u0026#34;uvicorn\u0026#34;, \u0026#34;main:app\u0026#34;, \u0026#34;--host\u0026#34;, \u0026#34;0.0.0.0\u0026#34;, \u0026#34;--port\u0026#34;, \u0026#34;8000\u0026#34;] In this case, the sizes are halved since unnecessary packages have already been removed:\n$ docker images \u0026gt;\u0026gt;\u0026gt; REPOSITORY TAG IMAGE ID CREATED SIZE python-ubi8 latest c4f0d7e3049c 8 minutes ago 161MB Conclusions # The use of UBIs offers greater reliability, security, and peace of mind for your containerized applications.\nMoreover, you can freely distribute containerized applications based on UBI to your friends (and enemies) on both Red Hat and non-Red Hat platforms, benefiting from the security checks performed periodically.\nIn the example seen earlier, we used a simple UBI8, but there are already ready-made ones with Python and other languages pre-installed and configured by default: why not give it a try?\nUseful Resources # GitHub Repository UBI Official Documentation RHEL: What is it? Docker - Per cominciare bene con Docker e Kubernetes Kubernetes - Guida per gestire e orchestrare i container Original post published on TheRedCode.it ","date":"28 January 2024","permalink":"/posts/secure-and-lightweight-containers-with-redhat/","section":"Posts","summary":"Why # The release of applications through lightweight containers has practical advantages, as the images contain all the dependencies necessary for the correct functioning of the application. However, the benefits of containerization can be lost if these images are too large and therefore require several minutes for the application to start.","title":"Secure and Lightweight containers with Red Hat"},{"content":"","date":"28 January 2024","permalink":"/tags/security/","section":"Tags","summary":"","title":"security"},{"content":"","date":"28 January 2024","permalink":"/categories/security/","section":"Categories","summary":"","title":"Security"},{"content":"","date":"28 January 2024","permalink":"/authors/serenasensini/","section":"Authors","summary":"","title":"serenasensini"},{"content":"","date":"14 January 2024","permalink":"/categories/aws-cli/","section":"Categories","summary":"","title":"AWS-CLI"},{"content":"","date":"14 January 2024","permalink":"/tags/awscli/","section":"Tags","summary":"","title":"awscli"},{"content":"","date":"14 January 2024","permalink":"/tags/container/","section":"Tags","summary":"","title":"container"},{"content":"","date":"14 January 2024","permalink":"/tags/devcontainer/","section":"Tags","summary":"","title":"devcontainer"},{"content":"","date":"14 January 2024","permalink":"/categories/devcontainer/","section":"Categories","summary":"","title":"devcontainer"},{"content":"","date":"14 January 2024","permalink":"/tags/docker/","section":"Tags","summary":"","title":"docker"},{"content":"","date":"14 January 2024","permalink":"/categories/docker/","section":"Categories","summary":"","title":"Docker"},{"content":"If you work with AWS, you must have used AWS credentials at least once to run commands through the AWS CLI, CDK CLI, or SAM CLI.\nWhen developing in a Dev Container, you don\u0026rsquo;t have access to your local file system. So, if you try to run an AWS command in the Dev Container, you will encounter some sort of \u0026ldquo;missing credentials\u0026rdquo; error.\nHow can you fix this?\nIt is quite easy to overcome this issue. Remember that a Dev Container is a Docker Container. Therefore, you can use a bind mount to link the directory and the files that contain AWS credentials configurations (a.k.a. the .aws directory).\nIf you want to read more about Bind Mount, here\u0026rsquo;s the link.\nAdding a bind mount to a Docker Container # In Docker, you can add bind mounts using the --mount flag when running docker run:\ndocker run --mount type=bind,source=/.aws,target=/home/vscode/.aws,readonly Let\u0026rsquo;s dive into the command and try to understand each part.\nFirst of all, as explained in the docs, --mount consists of multiple key-value pairs, separated by commas and each consisting of a key=value pair.\nThe order of the key-value pairs is not significant. Let\u0026rsquo;s see which keys are set in our command:\ntype: the type of the mount, which is bind. source(or src): represents the local path to find the directory we want to mount. In this case the path of our .aws directory. target(or dst or destination): represents the path where our local directory will be mounted in the container. readonly option, which is used when the container does not need write access. In our case, the Dev container only need to read credentials, not to write them. In case you are using SSO to login, you will need to remove readonly option because new temporary credentials will be added. More details about the --mount flag can be found here.\nNow that we have understood how to add a bind mount to a Docker container, let\u0026rsquo;s see how to do this using the devcontainer specification.\nAdding a bind mount in a Dev container defined with devontainer.json. # When using devontainer.json, you can set the command under mounts property:\n{ \u0026#34;mounts\u0026#34;: [ \u0026#34;source=${localEnv:HOME}/.aws,target=/home/vscode/.aws,type=bind,readonly\u0026#34; ] } it looks pretty much the same, the only difference is the value of source:\nlocalEnv:HOME, is a pre-defined variable. You can find the list of available variables you can use in devcontainer.json here.\nThe semantic here is:\nprint the value of HOME variable that is on the local machine.\nIn this case I want the value of the variable HOME, since I am wokring on mac. For Windows users, the mounts the variable to select is USERPROFILE. Therefore, the specification property would look like:\n{ \u0026#34;mounts\u0026#34;: [ \u0026#34;source=${localEnv:USERPROFILE}/.aws,target=/home/vscode/.aws,type=bind,readonly\u0026#34; ] } A note.\nIf you want define a devcontainer.json that is not dependent on any specific IDE, you can use the following:\n{ \u0026#34;mounts\u0026#34;: [ \u0026#34;source=${localEnv:HOME}/.aws,target=/.aws,type=bind,readonly\u0026#34; ], \u0026#34;containerEnv\u0026#34;: { \u0026#34;AWS_CONFIG_FILE\u0026#34;: \u0026#34;/.aws/config\u0026#34;, \u0026#34;AWS_SHARED_CREDENTIALS_FILE\u0026#34;: \u0026#34;/.aws/credentials\u0026#34; }, } In this way, you can set any path as your target, but you have to specify the custom config and credentials paths using respectevely, AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE env variables.\nYou can read more about it on the following pages:\nGetting started with Docker Environment variables to configure the AWS CLI Checking the result # How can you check if we actually managed to mount the .aws on your Dev Container?\nThe easiest way is to check in Docker Desktop. If go to Containers section and then click on the one of your interest, there you should see something like this: Also, we can look at the Inspect tab and if you scroll to Mounts property, you should see something like the following: Here, you can also see that readonly option was applied as well.\nConclusion # In this article we have seen how to use AWS credentials in a Dev Container. I have created a repository on gitHub which contains an example that applies what we have seen today, to run AWS CLI commands. Enjoy it!\nThat\u0026rsquo;s all folks! 🚀 Stay tuned!\nReferences # Bind Mounts docker run command DevContainer Specification Merge Logic Variables in devcontainer.json Getting started with Docker Environment variables to configure the AWS CLI ","date":"14 January 2024","permalink":"/posts/use-aws-credentials-in-a-dev-container/","section":"Posts","summary":"If you work with AWS, you must have used AWS credentials at least once to run commands through the AWS CLI, CDK CLI, or SAM CLI.\nWhen developing in a Dev Container, you don\u0026rsquo;t have access to your local file system. So, if you try to run an AWS command in the Dev Container, you will encounter some sort of \u0026ldquo;missing credentials\u0026rdquo; error.","title":"Use AWS Credentials in a Dev Container"},{"content":"Last Updated: 7th of January, 2024\nThis Privacy Policy explains how TheIndieCoder.cloud collects, uses, and protects your personal information when you visit our static website. By using our website, you consent to the practices described in this policy.\nInformation We Collect # We do not collect any personal information directly through our website. The only information we collect is through Google Analytics, a web analytics service provided by Google, Inc. (\u0026ldquo;Google\u0026rdquo;). Google Analytics uses cookies to collect information about how visitors use our website. The information collected is aggregated and anonymized, and it is used to generate statistical reports on website activity.\nThe information collected by Google Analytics includes:\nYour IP address (anonymized) The type of browser and device you are using The pages you visit on our website The time you spend on our website We do not have access to any personally identifiable information through Google Analytics.\nUse of Information # The information collected through Google Analytics is used solely for the purpose of analyzing website traffic and improving user experience. We do not use this information to identify individual visitors or to track their activities beyond our website.\nThird-Party Disclosure # We do not sell, trade, or otherwise transfer your information to third parties. The information collected through Google Analytics is used for internal purposes only and is not shared with external entities.\nManaging Cookies # You can control the use of cookies through your browser settings. Most web browsers allow you to block or delete cookies, and you can choose to opt-out of Google Analytics tracking by using the Google Analytics Opt-out Browser Add-on.\nUpdates to This Privacy Policy # We may update this Privacy Policy from time to time to reflect changes in our practices or for other operational, legal, or regulatory reasons. The updated policy will be posted on our website with the last updated date.\nContact Us # If you have any questions or concerns about this Privacy Policy, please contact us at martina.theindiecoder@gmail.com.\n","date":"7 January 2024","permalink":"/privacy-policy/","section":"The-indie-coder","summary":"Last Updated: 7th of January, 2024\nThis Privacy Policy explains how TheIndieCoder.cloud collects, uses, and protects your personal information when you visit our static website. By using our website, you consent to the practices described in this policy.\nInformation We Collect # We do not collect any personal information directly through our website.","title":"Privacy Policy"},{"content":"Some weeks ago, I spoked about the benefits of using Dev Containers in Open Source projects.\nIn the article, I also provided a definition of a Dev Container and described the benefits of using them. You can find it here.\nToday I would like to do something more practical and share with you a minimum configuration to setup Dev Containers for your Hugo website.\nPrerequisites # Whether you are a macOS user or a Windows user, you need to have the following installed:\nVisual Studio Code VS Code Dev Containers extension Docker Desktop I have prepared this guide as a macOS user, so I have not tried to run Dev Containers on Windows or Linux. If you are a Windows or Linux user, please refer to the Visual Studio Code documentation for installation instructions.\nIf you have installed the tools above, you are ready to define and create a Dev Container to develop your Hugo website.\nDev Container Setup # In the bottom left of your VS Code window, you should see a button like the one below: Click on it, and a setup wizard will pop up in the middle of the window. The first step is to select the template you would like to use. For our case, we know that Hugo feature works on Debian or Linux distributions with the apt package manager installed. So, select Debian.\nAt this point, you will have to set the version of the Debian distirbution. My mac has new-generation cpu (Apple silicon), so I had to select bullseye. Refer to Debian template Readme file to select the right version for you. Finally, let\u0026rsquo;s add the features needed. To build your website with Hugo, you need, in most cases, Git and Go. Check the prerequisites needed here.\nLet\u0026rsquo;s add Hugo, Git and Go features.\nClick OK.\nVisual Studio Code creates the devcontainer.json file and adds it to the .devcontainerin the root directory.\nThis is how the devcontainer.json file looks like:\n{ \u0026#34;name\u0026#34;: \u0026#34;Debian\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/base:bullseye\u0026#34;, \u0026#34;features\u0026#34;: { \u0026#34;ghcr.io/devcontainers/features/git:1\u0026#34;: {}, \u0026#34;ghcr.io/devcontainers/features/go:1\u0026#34;: {}, \u0026#34;ghcr.io/devcontainers/features/hugo:1\u0026#34;: {} } } We are ready to run the container.\nLet\u0026rsquo;s click on the button at the bottom of the VS Code sidebar. We will see the wizard popping up again. Select Reopen in Container option.\nVisual Studio Code will reopen the project in a new window, even though it looks the same. You can notice that a label appeared next to the Dev Container extension icon. The container is up and running so now we can start to develop our Hugo Website.\nCreate Hugo website # First of all, we have to create a new site. In the root folder then run:\nhugo new site . --force In the project I have created, I have installed Hugo Winston theme. Let\u0026rsquo;s see how.\nIn the root folder run:\ngit clone https://github.com/zerostaticthemes/hugo-winston-theme.git themes/hugo-winston-theme As a last step, let\u0026rsquo;s copy the example content located in mynewsite/themes/hugo-winston-theme/exampleSite/.\ncp -a themes/hugo-winston-theme/exampleSite/. . We are now ready to build and serve our new site. Let\u0026rsquo;s run:\nhugo server Usually, Hugo Server is available at http://localhost:1313/. If you reach localhost, you could see we got a 404. This is due to the fact we have installed Hugo, but in the Hugo Wiston theme installation guide, it is said to have hugo extended version.\nLet\u0026rsquo;s fix this.\nIn Readme file of Hugo features, you can see that among the available options there is extended, which is a boolean. Let\u0026rsquo;s add that to the devcontainer.json. It should look like this:\n{ \u0026#34;name\u0026#34;: \u0026#34;Debian\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/base:bullseye\u0026#34;, \u0026#34;features\u0026#34;: { \u0026#34;ghcr.io/devcontainers/features/git:1\u0026#34;: {}, \u0026#34;ghcr.io/devcontainers/features/go:1\u0026#34;: {}, \u0026#34;ghcr.io/devcontainers/features/hugo:1\u0026#34;: { \u0026#34;extended\u0026#34;: true } } } Since we have changed the Dev Container specification, VS Code will notify us to rebuild the container in order to see the changes, using a popup like this one: Let\u0026rsquo;s click on Rebuild button.\nWe need to build and serve the site again.\nhugo server Now at localhost, your website should be available and working as expected.\nIf we want to automate the building and the serving actions, we can add a postStartCommand property, with hugo server set, to the devcontainer.json file.\n{ \u0026#34;name\u0026#34;: \u0026#34;Debian\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/base:bullseye\u0026#34;, \u0026#34;features\u0026#34;: { \u0026#34;ghcr.io/devcontainers/features/git:1\u0026#34;: {}, \u0026#34;ghcr.io/devcontainers/features/go:1\u0026#34;: {}, \u0026#34;ghcr.io/devcontainers/features/hugo:1\u0026#34;: { \u0026#34;extended\u0026#34;: true } }, \u0026#34;postStartCommand\u0026#34;: \u0026#34;hugo server\u0026#34; } In this way, the next time you start the container again, the hugo server command will be run automatically.\nWrap up # That\u0026rsquo;s all, folks! 🚀\nWe have seen how to create a minimum configuration to set up Dev Containers for your Hugo website. I have created a project on GitHub that you could fork and start to develop your hugo website using Dev Containers.\nYou can find it here. Enjoy it!\nResources # Hugo feature\nGit feature\nGo Feature\nHugo Winston Theme\n","date":"14 December 2023","permalink":"/posts/dev-container-setup-for-hugo/","section":"Posts","summary":"Some weeks ago, I spoked about the benefits of using Dev Containers in Open Source projects.\nIn the article, I also provided a definition of a Dev Container and described the benefits of using them. You can find it here.\nToday I would like to do something more practical and share with you a minimum configuration to setup Dev Containers for your Hugo website.","title":"Dev Container Setup for Hugo"},{"content":"","date":"14 December 2023","permalink":"/tags/devcontainers/","section":"Tags","summary":"","title":"devcontainers"},{"content":"","date":"14 December 2023","permalink":"/categories/devcontainers/","section":"Categories","summary":"","title":"DevContainers"},{"content":"","date":"14 December 2023","permalink":"/tags/hugo/","section":"Tags","summary":"","title":"hugo"},{"content":"","date":"14 December 2023","permalink":"/categories/hugo/","section":"Categories","summary":"","title":"Hugo"},{"content":"","date":"14 December 2023","permalink":"/tags/vscode/","section":"Tags","summary":"","title":"vscode"},{"content":"","date":"1 December 2023","permalink":"/categories/dev-containers/","section":"Categories","summary":"","title":"Dev Containers"},{"content":"","date":"1 December 2023","permalink":"/categories/open-source/","section":"Categories","summary":"","title":"Open Source"},{"content":"","date":"1 December 2023","permalink":"/tags/opensource/","section":"Tags","summary":"","title":"opensource"},{"content":"During my first two weeks at Cloud Enablers I have started to look into Development Containers, among other things.\nDevelopment (or, in their short form, Dev) Containers are containers used for software development purposes. They are containers enriched with all the content and metadata necessary to be able to code inside them.\nI have to admit that just reading the definition made me think, \u0026ldquo;Ok, then what? Why I should develop my code inside a container?\u0026rdquo;\nThings got a bit clearer when I learned the benefits of using Dev Containers.\nWhat are the benefits of using Dev Containers? # Using Dev Containers allows you to:\nUse consistent tooling and library versions. Speed up development process. Reduce system conflicts. Facilitate the onboarding process. Centralize build and test automation. With Dev Container you can create reproducible, pre-configured, isolated Dev environments.\nReproducible because, no matter the machine you are going to work on, once the container is up, the status of the project will be the same.\nPre-configured because you can specify which dependencies, IDE extensions, and libraries should be installed in order for you to immediately start to code.\nAnd finally, isolated because it will be completely independent from your local machine and any of the sofwares installed on it.\nLet\u0026rsquo;s look at how we can define a Dev Container.\nDev Container Specification # The way you can add content and metadata to your container is by using the Development Container Specification.\nDevelopment Container Specification consists of a devcontainers.json file.\nDepending on the tool or service you will use you, will find the JSON file in one of the following paths:\n.devcontainer/devcontainer.json devcontainer.json .devcontainer/\u0026lt;folder\u0026gt;/devcontainer.json I have been using VS Code, and the format used in that case is .devcontainer/devcontainer.json.\nBelow you can see and example of a devcontainers.json file.\n{ \u0026#34;name\u0026#34;: \u0026#34;the name of the dev container\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/typescript-node\u0026#34;, /* Product specific properties, defined in supporting tools */ \u0026#34;customizations\u0026#34;: { /* VS Code customization */ \u0026#34;vscode\u0026#34;: { \u0026#34;extensions\u0026#34;: [ \u0026#34;yoavbls.pretty-ts-errors\u0026#34;, \u0026#34;infeng.vscode-react-typescript\u0026#34; ] } }, /* Features to add to the dev container. More info: https://containers.dev/features. */ \u0026#34;features\u0026#34;: { \u0026#34;ghcr.io/devcontainers/features/aws-cli:1\u0026#34;: {}, \u0026#34;ghcr.io/devcontainers/features/git:1\u0026#34;: {}, \u0026#34;ghcr.io/devcontainers-contrib/features/aws-cdk:2\u0026#34;: {}, \u0026#34;ghcr.io/devcontainers-contrib/features/zsh-plugins:0\u0026#34;: {} }, /* Use \u0026#39;postCreateCommand\u0026#39; to run commands after the container is created. */ \u0026#34;postCreateCommand\u0026#34;: \u0026#34;npm install\u0026#34; } In the example I have reported just a few parameters to help you understand the concept of Dev Containers. For more properties, you can find the reference here.\nimage is the name of the image you want to get from a container registry, and that will be used to create the dev container. This parameter is required, unless you would like to define the image yourself in a Dockerfile: in that case build.dockerfile would be required.\nIn the customizations parameter you will find the specific-tool properties. In the case above, I am using VS Code and defining which extensions I would like to install when creating the container.\nAny feature represents, instead, a unit of code, or software you would like to install. In this example, I would like to install the AWS CLI, git, AWS CDK and the zsh shell.\nIf defined, postCreateCommand represents the commmand that will be run after the container is created. In my case, I would like that after the container is created, the npm install will be run.\nMost popular supporting tools # Dev Containers is a concept, a standard, a format that can be supported by several tools and services. I have been using VS Code, but GitHub Codespace is also quite popular.\nYou can find other supporting tools here.\nCan you see the power now?\nOne of the first thing I have thought after delving into the topic was \u0026ldquo;This would be wonderful to have in Open source projects!\u0026rdquo;.\nDev Containers and Open Source: the perfect match! # Maybe it\u0026rsquo;s me, but I often give up on contributing to some really interesting open source projects because it takes hours to try to setting up the whole environment and often the try is a complete failure. Thousands of errors to fix, it\u0026rsquo;s late at night and my sleeping slot is reducing dastrically. It is not worth it; I can\u0026rsquo;t.\nImagine cloning the open-source repo, open VS Code, launching the container with a bunch of clicks and in a couple of seconds (minutes in the case of bigger projects) a new VS Code window opens up, showing you the source code and being ready to develop. How awesome is that?\nNo more painful software installations and conflicts to fix with your installed tools on your machine, Way fewer issues in gitHub repos like \u0026ldquo;it does not work on OS XXX version XXX\u0026rdquo; and for sure, more people would feel more comfortable contributing.\nAWS CDK for instance added a Dev Container specification and thanks to that I have started to contribute to the project.\nWrap up # With Dev Container you can create reproducible, pre-configured, isolated Dev environments. This pecularity makes them perfect to use in open-soucrce projects to make the development easy and fast for all the contributors. Dev Containers are quite new standard and I have the impression that more and more teams and developer have started to use them. However, I still wish more open-source projects would provide a Dev Container setup for contributing.\nThat\u0026rsquo;s all folks! Let me know what do you think about this article at martina.theindiecoder@gmail.com.\nSee you soon! 🚀\nResources # Development Containers Visual Studio Code Dev Containers ","date":"1 December 2023","permalink":"/posts/dev-containers-and-open-source/","section":"Posts","summary":"During my first two weeks at Cloud Enablers I have started to look into Development Containers, among other things.\nDevelopment (or, in their short form, Dev) Containers are containers used for software development purposes. They are containers enriched with all the content and metadata necessary to be able to code inside them.","title":"Simplifying Open Source Contributions with Dev Containers"},{"content":"","date":"1 December 2023","permalink":"/tags/tools/","section":"Tags","summary":"","title":"tools"},{"content":"","date":"1 December 2023","permalink":"/categories/tools/","section":"Categories","summary":"","title":"Tools"},{"content":"","date":"30 October 2023","permalink":"/tags/reliability/","section":"Tags","summary":"","title":"reliability"},{"content":"","date":"30 October 2023","permalink":"/categories/reliability/","section":"Categories","summary":"","title":"Reliability"},{"content":"","date":"30 October 2023","permalink":"/series/reliability-pillar/","section":"Series","summary":"","title":"Reliability pillar"},{"content":"In the previous article of this series, we delved into the Reliability pillar structure, describing the Design Principles and the structure of the best practices.\nIf you missed it or need a recap, you can find it here or access it through the dropdown menu at the beginning of the page.\nAfter two introductory articles, we finally start with the First Reliability Pillar question, which is part of Foundations:\nHow do you manage Service Quotas and constraints?\nFirst of all, let\u0026rsquo;s define what Quotas and constraints are.\nService Quotas # One characteristic of the cloud is its ability to acquire and release resources quickly, on-demand. This might give you the impression of working with limitless resources, but that\u0026rsquo;s not entirely correct, especially when working with serverless architectures.\nEach AWS service has limits, known as service quotas, and they refer to the maximum number of resources or operations that an AWS account can use or perform applying either to a specified region in most cases, or globally at the account level. Service quotas are often soft limits set by AWS, meaning you can request an increase if necessary.\nWhy does AWS set these limits?\nIf service quotas are soft limits and you could request an increasing, why does AWS set them?\nThe reason lies in the multi-tenancy nature of the cloud: to prevent any single account from consuming an excessive amount of resources, potentially affecting the performance of other accounts in the same region.\nConstraints # In contrast to service quotas, which are set by AWS, Constraints refer to physical hardware limits. As the name suggests, these are hard limits. For example, you cannot increase the storage capacity of a physical disk unless you use a different physical disk.\nBest Practices # Now that we have clarified what service quotas and constraints are, let\u0026rsquo;s list the best practices for managing them:\nAware of service quotas and constraints Manage service quotas across accounts and regions Accommodate fixed service quotas and constraints through architecture Monitor and manage quotas Automate quota management Ensure that a sufficient gap exists between the current quotas and the maximum usage to accommodate failover Each best practice is detailed, so I won\u0026rsquo;t summarize them here. I strongly recommend reading them carefully. Instead, I\u0026rsquo;ll share some work experience and provide you with a practical solution to monitor and manage quotas that align with most of the best practices. You can find the links to each best practice documentation page in the Resource section.\n💡 3 main things to keep in mind # Using AWS Service Quotas to check quotas and request history. Recognizing that some quotas and constraints can impact your architectural decisions. Understanding that some quotas and constraints can impact your production environment. Using AWS Service Quotas to check quotas and request history # AWS Service Quotas is a service that allows you to view applied and default quota values for almost all AWS services in a certain region. You can customize the dashboard to display services of interest. Additionally, you can navigate services, explore quotas, request increases for adjustable quotas, and track quota request history.\nThis service is accessible not only through the console but also via the CLI and AWS SDK, facilitating quota management automation (refer to Best Practices).\nI\u0026rsquo;ve created a lambda to automate request Quotas increase. You can find the code here.\nIn the following snippet you can see how the to the request to perform service quotas increase looks like.\nimport { ServiceQuotasClient, RequestServiceQuotaIncreaseCommand } from \u0026#34;@aws-sdk/client-service-quotas\u0026#34;; export const requestServiceQuotaIncrease = async ( quotaCode: string, serviceCode: string, desiredValue: number ) =\u0026gt; { const config = {}; const client = new ServiceQuotasClient(config); const input = { // RequestServiceQuotaIncreaseRequest ServiceCode: serviceCode, // required QuotaCode: quotaCode, // required DesiredValue: desiredValue, // required }; const command = new RequestServiceQuotaIncreaseCommand(input); const response = await client.send(command); return response; }; In order to make the request, you need to know:\nserviceCode: the identifier of the related service for which you want to request a quota increase. quotaCode: the identifier of the quota for which you want to request an increase. desiredValue: the desired value you would like to set for the quota. To obtain the serviceCode value for an Amazon Web Services service, you can use the ListServices operation. In order to select the service code, you need to know the service name.\nTo find the quotaCode for a specific quota, you can use the ListServiceQuotas operation. In order to select the service code, you need to know the service name.\nMoreover, both the operations return a paginated result. Look at the gitHub repo to see how I managed to retrieve serviceCode and quotaCode for a service and quota of interest.\nI have tried to increase Lambda Concurrent Executions service quota.\nLambda Concurrent Executions is the maximum number of events that functions can process simultaneously in the current region. The AWS default quota value is 1000 but when you create a new account you will see that the Applied quota value is 10. AWS will automatically increase the value based on the usage, until 1000. After that you have to make a request.\nTo make sure my increase request would be accepted, I\u0026rsquo;ve tried to increase the applied quota from 10 to 20.\nBased on my solution, I have triggered the lambda with the following input parameters:\n{ serviceName: \u0026#39;AWS Lambda\u0026#39;, quotaName: \u0026#39;Concurrent executions\u0026#39;, desiredValue: 20 } The request returns 200 and I could see under AWS service Quotas \u0026gt; Quota request history page that a new request was submitted. And after some minutes I could see that the quota increased in the Lambda dasboard. Recognizing that some quotas and constraints can impact your architectural decisions # I am going to give an example of quota that could impact your architectural decisions. In the design phase, when you\u0026rsquo;re developing an Event-driven architecture and considering using SQS, not be aware of SQS quotas could be crucial. For instance, the message payload limit of 256 KiB and you are not aware of it. Without this knowledge, you may start development only to realize during testing that SQS cannot handle your message payloads. Or worse, you might realize that only when your new feature is in production, necessitating a rollback to square one.\nUnderstanding that some quotas and constraints can impact your production environment # Certain services can reach their quotas over an extended period. Each lambda function version and layer version consumes storage. The Lambda Function and layer storage quota represent the available storage for deployment packages and layer archives in the current Region. As you deploy more functions and updates, storage consumption increases.\nIf you reach the 75 gigabyte limit, you won\u0026rsquo;t be able to deploy any more lambda functions. Therefore, monitoring this quota is of utmost importance.\nMonitor and manage Lambda quotas # If you\u0026rsquo;re working with a serverless paradigm, then you\u0026rsquo;re likely using Lambda. Let\u0026rsquo;s explore how to effectively monitor and manage Lambda quotas.\nWhile it may not be necessary to monitor all Lambda quotas, understanding them is crucial during the design phase and when selecting services. For example, consider the synchronous payload quota, representing the maximum size of incoming synchronous invocation requests or outgoing responses. While you may not actively monitor this quota, it\u0026rsquo;s essential to be aware of its limitations, especially if your requests or responses may exceed 6MB.\nNow, let\u0026rsquo;s focus on two critical quotas: Concurrent Execution and Function and layer storage.\nConcurrent Execution # As mentioned earlier in the Using AWS Service Quotas to check quotas and request history section, we\u0026rsquo;ve already discussed what Concurrent Execution is and how to request a quota increase.\nSo, how do we know when it\u0026rsquo;s time to make that request?\nWhat we didn\u0026rsquo;t cover previously is that if Concurrent Execution exceeds the limit, you won\u0026rsquo;t be able to run any more lambdas, potentially heavily impacting your production environment.\nTo monitor this, we\u0026rsquo;ll create a CloudWatch alarm.\nIn the AWS console, navigate to CloudWatch and go to All Alarms. Click on Create Alarm and proceed to specify the metric and conditions. Under the Browse tab, select Lambda and then Across all functions. Choose ConcurrentExecutions as the metric. Rember to select the correct region when selecting metric. Now, set the statistic to Maximum, and the period to 1 minute.\nUnder Conditions, select Greater and set the threshold value to 800. Given that the AWS default value is 1000, setting the threshold at 800 ensures there\u0026rsquo;s a sufficient gap between current quotas and maximum usage to accommodate failover.\nFunction and layer storage # The Function and Layer Storage Lambda quota refers to the amount of storage available for deployment packages and layer archives in the current Region. The AWS default quota is 75 gigabytes. If you reach this limit, you won\u0026rsquo;t be able to create any new lambdas or deploy updates.\nSince this is not a metric, we\u0026rsquo;ll use the AWS SDK to monitor the quota.\nYou Retrieve details about your account\u0026rsquo;s limits and usage in a specific Region using GetAccountSettingsCommand LambdaClient Operation.\nimport { LambdaClient, GetAccountSettingsCommand, GetAccountSettingsCommandOutput, AccountLimit, AccountUsage, } from \u0026#34;@aws-sdk/client-lambda\u0026#34;; export const getAccountSettings = async () =\u0026gt; { const config = {}; const client = new LambdaClient(config); const input = {}; const command = new GetAccountSettingsCommand(input); const accountSettings = await client.send(command); return accountSettings; }; Here how the response looks like:\n{ AccountLimit: { TotalCodeSize: Number(\u0026#34;long\u0026#34;), CodeSizeUnzipped: Number(\u0026#34;long\u0026#34;), CodeSizeZipped: Number(\u0026#34;long\u0026#34;), ConcurrentExecutions: Number(\u0026#34;int\u0026#34;), UnreservedConcurrentExecutions: Number(\u0026#34;int\u0026#34;), } AccountUsage: { TotalCodeSize: Number(\u0026#34;long\u0026#34;), FunctionCount: Number(\u0026#34;long\u0026#34;), } } At this point you calculate the usage percentage by dividing:\naccountUsage.TotalCodeSize / accountLimit.TotalCodeSize If the percentage is close to maximum usage, you can send a notification to an SNS topic for actions like sending an email or triggering a lambda to notify via Slack or similar channels. You could even automate the quota increase request as demonstrated in Using AWS Service Quotas to check quotas and request history section.\nI have created a lambda that monitor the storage. You can find the code here.\nConclusion # In this article, we\u0026rsquo;ve explored the six best practices related to the first Reliability pillar question: How do you manage Service Quotas and constraints?\nBeing aware of these best practices and actively monitoring them using AWS service quotas, AWS CloudWatch alarms, and AWS SDK for quota automation is the first step towards ensuring a robust and reliable serverless architecture.\nFinally, we\u0026rsquo;ve used AWS Lambda service quotas as an example to demonstrate both the creation of a CloudWatch alarm and the use of the AWS SDK to manage and monitor quotas.\nIf you have questions or would like to provide feedback, email me at martina.theindiecoder@gmail.com 🚀\nThat\u0026rsquo;s all folks! See you later.\nResources # Manage service quotas and constraints REL01-BP01 REL01-BP02 REL01-BP03 REL01-BP04 REL01-BP05 REL01-BP06 Stack used:\nAWS SDK for Javascript v3 Serverless framework esbuild ","date":"30 October 2023","permalink":"/posts/reliability-pillar-manage-service-quotas-and-constraints/","section":"Posts","summary":"In the previous article of this series, we delved into the Reliability pillar structure, describing the Design Principles and the structure of the best practices.\nIf you missed it or need a recap, you can find it here or access it through the dropdown menu at the beginning of the page.","title":"Reliability pillar: How do you manage Service Quotas and constraints?"},{"content":"","date":"30 October 2023","permalink":"/series/","section":"Series","summary":"","title":"Series"},{"content":"","date":"30 October 2023","permalink":"/tags/sre/","section":"Tags","summary":"","title":"sre"},{"content":"","date":"30 October 2023","permalink":"/categories/sre/","section":"Categories","summary":"","title":"SRE"},{"content":"","date":"30 October 2023","permalink":"/categories/well-architected-framework/","section":"Categories","summary":"","title":"Well-Architected Framework"},{"content":"In the introduction article of this series, I have described the AWS Well-architected Framework structure and how to use it to evaluate your architectures.\nI have also briefly introduced the Reliability Pillar and listed the 13 questions we will examine in this series.\nBefore we get started with the questions, let\u0026rsquo;s delve into the Reliability Pillar structure.\nThe Reliability pillar structure # The Reliability pillar is the set of design principles, best practices and questions related to Reliability.\nDesign Principles # Five are the design principles for reliability in the cloud:\nAutomatically recover from failure\nTest recovery procedures\nScale horizontally to increase aggregate workload availability\nStop guessing capacity\nManage change in automation\nAutomatically recover from failure # The only way you can automatically recover from failure, is by monitoring your system. You have to identify business value metrics and monitor them: in this way, you can act as soon as a threshold is breached. The action has to be automatic. The more advanced automations, the easier it is to be proactive and prevent failures from happening.\nTest recovery procedures # One should regularly tests the recovery procedures and validate them. By using automation, you can simulate different failure scenarios: completely new ones or scenarios that led to failures before. The advantage of testing recovery procedures is that you reduce risk by potentially fixing failures before a real failure scenario occurs.\nScale horizontally to increase aggregate workload availability # You should reduce the impact of a single point of failure by using multiple small resources instead of a large one.\nStop guessing capacity # You should monitor resources utilization and automate their addition or removal to maintain an optimal level of provisioning.\nManage change in automation # Any changes to your infrastructure should be executed via automation. This encompasses changes to the automation process itself, which can then be tracked and subjected to review.\nBest Practices and Questions # Reliability best practices and questions are tightly coupled and grouped by the following areas:\nFoundations\nWorkload architecture\nChange management\nFailure management\nEach question comes with a list of related Best Practices. So, examining and answering a certain question means going through the best practices and understanding if they are established in your workload or not.\nEach best practice has a well-defined structure with the following components:\nDesired outcome: a description of how the workload should behave if the best practice has been established. Common anti-patterns: a list of poor decisions that should be avoided. Benefits of establishing this best practice: a list of reasons why the best practice should be implemented. Level of risk exposed if this best practice is not established: a label that can be low, medium or high. Implementation guidance: a section that describes how to establish the best practice. Conclusions # In this article we delve into the Reliability Pillar structure, describing:\nthe reliability design principles the structure of the best practices we are going to see. This knowledge is fundamental to have before we get started with the questions.\nIn the next article, we are finally going to examine the first question of the Reliability pillar:\nHow do you manage Service Quotas and constraints?\nSee you soon! 👋\nResources # Reliability Pillar Design principles\n","date":"27 September 2023","permalink":"/posts/reliability-pillar-structure/","section":"Posts","summary":"In the introduction article of this series, I have described the AWS Well-architected Framework structure and how to use it to evaluate your architectures.\nI have also briefly introduced the Reliability Pillar and listed the 13 questions we will examine in this series.\nBefore we get started with the questions, let\u0026rsquo;s delve into the Reliability Pillar structure.","title":"Reliability pillar - The structure"},{"content":"If you work with AWS you are likely familiar with the AWS Well-Architected Framework and understand how crucial it is to periodically evaluate your system using this framework to ensure its stability and efficiency.\nFor those who may not be familiar, the AWS Well-Architected Framework provides a set of design principles, best practices and questions that help you to evaluate architectures.\nThe AWS Well-Architected Framework # The set of design principles, best practices and questions is organized in pillars. The AWS Well-Architected Framework is based on six pillars as defined in the documentation:\noperational excellence: The ability to support development and run workloads effectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value\nsecurity: the ability to protect data, systems, and assets to take advantage of cloud technologies to improve your security.\nreliability: the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle.\nperformance efficiency: The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve.\ncost optimization: The ability to run systems to deliver business value at the lowest price point.\nsustainability: The ability to continually improve sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload by maximizing the benefits from the provisioned resources and minimizing the total resources required.\nI mentioned earlier that the framework helps you to evaluate architectures. But how is the evaluation of the architecture done in practice?\nThe evaluation essentially involves a conversation, lasting a couple of hours at mosts, among the team members who designed and built a particular architecture. This discussion is preferably held in front of a whiteboard, with architectural diagrams on hand. To ensure a positive experience and extract the most value from the conversation, it\u0026rsquo;s important to avoid any blame-oriented attitudes during the session.\nFor enterprise projects, it\u0026rsquo;s common that only a subset of the team is involved in designing and building specific services or components of the system, rather than the entire team.\nAWS uses the term Workload to indicate a collection of resources and code that delivers business value, such as a customer-facing application or a backend process. A workload might consist of a subset of resources in a single AWS account or be a collection of multiple resources spanning multiple AWS accounts. When reviewing a workload, it\u0026rsquo;s important to involve only those who designed and built that particular workload.\nThe evaluation isn\u0026rsquo;t a one-time process carried out after the architecture is built; rather, it\u0026rsquo;s an ongoing part of the project\u0026rsquo;s lifecycle. It should begin early in the design phase and occur prior to going live.\nThe purpose of the review is to identify critical issues and areas for improvement, organizing them into a list of action points that can be prioritized based on the project\u0026rsquo;s needs.\nReliability pillar # Let\u0026rsquo;s revisit the definition of reliability: The ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle.\nBut what does that really mean?\nTo keep it simple, a reliable system is a system that can be trusted. A system can be trusted when failures are not common, when the impact of each failure is minimized and the system continues to run despite them. In today\u0026rsquo;s world, reliability is a keystone for the success of any system.\nIn this series I would like to dig deeper into the reliability pillar. We will examine the questions presented by the framework and try to address some of them within a serverless context.\nThe questions are 13 and are grouped by 4 areas:\nFoundations Workload Architecture Change Management Failure Management Foundations # How do you manage Service Quotas and constraints?\nHow do you plan your network topology?\nWorkload Architecture # How do you design your workload service architecture?\nHow do you design interactions in a distributed system to prevent failures?\nHow do you design interactions in a distributed system to mitigate or withstand failures?\nChange Management # How do you monitor workload resources?\nHow do you design your workload to adapt to changes in demand?\nHow do you implement change?\nFailure Management # How do you back up data?\nHow do you use fault isolation to protect your workload?\nHow do you design your workload to withstand component failures?\nHow do you test reliability?\nHow do you plan for disaster recovery (DR)?\nLooking at the number of questions, more than a series, this is going to be a Saga. Stay tuned! 📻 📡\nResources # AWS Well-Architected Framework\nThe review process\nWorkloads\n","date":"27 August 2023","permalink":"/posts/reliability-pillar-series/","section":"Posts","summary":"If you work with AWS you are likely familiar with the AWS Well-Architected Framework and understand how crucial it is to periodically evaluate your system using this framework to ensure its stability and efficiency.\nFor those who may not be familiar, the AWS Well-Architected Framework provides a set of design principles, best practices and questions that help you to evaluate architectures.","title":"Series - The Well-Architected Framework: Reliability pillar"},{"content":"","date":"22 August 2023","permalink":"/tags/cloudformation/","section":"Tags","summary":"","title":"cloudformation"},{"content":"","date":"22 August 2023","permalink":"/categories/cloudformation/","section":"Categories","summary":"","title":"CloudFormation"},{"content":"","date":"22 August 2023","permalink":"/tags/iac/","section":"Tags","summary":"","title":"iac"},{"content":"","date":"22 August 2023","permalink":"/categories/iac/","section":"Categories","summary":"","title":"IaC"},{"content":"Raise your hand if you\u0026rsquo;ve struggled at least once while trying to write CloudFormation templates that can be resusable across different environments 🤚.\nIn this article, I will show you how to use Conditions to create reusable CloudFormation templates.\nit\u0026rsquo;s important to know that you can define conditions at two different levels:\nResource level Property level When you define conditions at the resource level, you can specify whether CloudFormation should create a resource, depending on the environment you\u0026rsquo;ve set.\nWhen you define conditions at the Property level, you can either:\ndefine different values for a specific property based on the environment. decide whether to include or exclude a certain property for your resource, depending on the environment. Conditions at the resource level # If you want to determine whether to create a resource based on the deployment environment, you can utilize the Condition property within the resource definition.\nFor instance, let\u0026rsquo;s assume you want to create an SQS queue in the test environment but not in the production environment.\nThe template definition would appear as follows:\nAWSTemplateFormatVersion: 2010-09-09 Parameters: Environment: Description: Deploy Environment. Type: String AllowedValues: - prod - test Conditions: IsTestEnvironment: !Equals - !Ref Environment - test Resources: Queue: Type: \u0026#39;AWS::SQS::Queue\u0026#39; Condition: IsTestEnvironment Conditions at the property level # Let\u0026rsquo;s assume, in this case instead, that you want to create an SQS queue both in test and production environments but with differing MessageRetentionPeriod values (e.g., 60 seconds for test and 432000 seconds for production).\nThe template definition would appear as follows:\nAWSTemplateFormatVersion: 2010-09-09 Parameters: Environment: Description: Deploy Environment. Type: String AllowedValues: - prod - test Conditions: IsTestEnvironment: !Equals - !Ref Environment - test Resources: Queue: Type: \u0026#39;AWS::SQS::Queue\u0026#39; Properties: MessageRetentionPeriod: !If - IsTestEnvironment - 60 - 432000 Conditions at the property level - Including or Excluding a Property # Suppose you\u0026rsquo;re creating an SQS queue in both test and production environments, but you only want to set the ReceiveMessageWaitTimeSeconds property for test.\nThe template definition would appear as follows:\nAWSTemplateFormatVersion: 2010-09-09 Parameters: Environment: Description: Deploy Environment. Type: String AllowedValues: - prod - test Conditions: IsTestEnvironment: !Equals - !Ref Environment - test Resources: Queue: Type: \u0026#39;AWS::SQS::Queue\u0026#39; Properties: ReceiveMessageWaitTimeSeconds: !If - IsTestEnvironment - 20 - Ref: AWS::NoValue Working with Nested Conditions # In some cases, you may need to consider one or more development environments as well.\nLet\u0026rsquo;s see how the Conditions section would appear when you want to create a resource both in test and develpoment environments but not in production.\nAWSTemplateFormatVersion: 2010-09-09 Parameters: Environment: Description: Deploy Environment. Type: String AllowedValues: - prod - test - dev Conditions: IsTestEnvironment: !Equals - !Ref Environment - test IsDevEnvironment: !Equals - !Ref Environment - dev IsNotProductionEnvironment: !Or - !Condition IsTestEnvironment - !Condition IsDevEnvironment Resources: Queue: Type: \u0026#39;AWS::SQS::Queue\u0026#39; Condition: IsNotProductionEnvironment Conclusion # That\u0026rsquo;all folks! In this article we have seen how to use Conditions to write CloudFormation templates that can be reused across different environment.\nI\u0026rsquo;ve created a GitHub repository where I\u0026rsquo;ve stored the templates we\u0026rsquo;ve seen above in YAML files. You can find instructions in the README.md file on how to create CloudFormation stacks from these templates to test out the Conditions.\nEnjoy it! 🚀\nIf you have questions or would like to provide feedback, email me at martina.theindiecoder@gmail.com.\nResources # Conditions\n","date":"22 August 2023","permalink":"/posts/cloudformation-conditions/","section":"Posts","summary":"Raise your hand if you\u0026rsquo;ve struggled at least once while trying to write CloudFormation templates that can be resusable across different environments 🤚.\nIn this article, I will show you how to use Conditions to create reusable CloudFormation templates.\nit\u0026rsquo;s important to know that you can define conditions at two different levels:","title":"Use Conditions to create reusable CloudFormation templates"},{"content":"","date":"12 August 2023","permalink":"/tags/cloudfront/","section":"Tags","summary":"","title":"cloudFront"},{"content":"","date":"12 August 2023","permalink":"/categories/cloudfront/","section":"Categories","summary":"","title":"CloudFront"},{"content":"","date":"12 August 2023","permalink":"/series/host-a-static-website-on-aws-s3/","section":"Series","summary":"","title":"Host a static website on AWS S3"},{"content":"","date":"12 August 2023","permalink":"/tags/https/","section":"Tags","summary":"","title":"https"},{"content":"","date":"12 August 2023","permalink":"/categories/https/","section":"Categories","summary":"","title":"https"},{"content":"","date":"12 August 2023","permalink":"/tags/s3/","section":"Tags","summary":"","title":"s3"},{"content":"","date":"12 August 2023","permalink":"/categories/s3/","section":"Categories","summary":"","title":"S3"},{"content":"In this article, we will explore how to leverage Amazon CloudFront to serve your S3-hosted website over HTTPS, enhancing security and delivering a seamless user experience.\nThis Article is part 4 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series. You can find it in the dropdown component above.\nGood to know # Amazon CloudFront # Amazon CloudFront is a content delivery network (CDN) offered by AWS. A Content delivery network is a group of servers distributed across various geographic locations, that has the goal of providing fast and secure delivery content. CDNs reduce latency, by placing the content that needs to be delivered to the users as close as possible to them.\nAmazon CloudFront distributes your content using a global network of data centers referred to as edge locations. Whenever a user makes a request for content being served through CloudFront, the request is directed to the edge location with the shortest delay (lowest latency), ensuring optimal performance for content delivery.\nPrerequisites # You have a static website hosted on S3, for which you are using a custom domain (See Part 3).\nCreate an SSL Certificate with AWS Certificate Manager # Firstly, to enable CloudFront to serve content from your website with HTTPS, you have to create an SSL certificate.\nOnce you are logged into the AWS Management Console, search for \u0026ldquo;Certificate Manager\u0026rdquo; in the top bar and click on the first result.\nThe certificate must be requested in US East(N. Virginia) Region (us-east-1). Refer to the documentation for more information. Make sure you are in US East(N. Virginia) Region. You can verify in which region you are in the top bar on the right. In the side menu click on Request Certificate.\nChoose Request a public certificate as Certificate type. Click the Next button. In the domain Names section, insert both the root domain name and subdomain name (e.g., www.example.com). In the Validation method section, Choose DNS validation - reccomended. In order to issue a certificate, AWS Certificate Manager needs to verify that you are the owner or that you control the domain names in your certificate request. AWS reccomends using DNS validation. To pass the validation, you need to add a CNAME record in the Route 53 hosted zone of your domain, one for each domain name you added in the previous section. We will see how to add CNAME records soon.\nIn the Key Algorithm section, choose RSA 2048. Scroll to the bottom and click the Request button.\nOnce you clickß the Request button, you will be redirected to the List Certificates page. At the top, you should see a blue pop-up message that says Further action is needed to complete validation and approval of certificate. The message is generic and does not specify what further action is required. It\u0026rsquo;s actually the addition of the CNAME records needed for the validation.\nLuckly, ACM provides us with a smooth solution. Click the View certificate button in the banner and scroll down to the Domains section. Here, click the Create records in Route 53 button. Select all the rows and click the Create records button. After clicking the Create records button, you should see the result of the creation in a banner at the top of the page. If the creation was successful, you should see something like the picture below. It may take some time for Amazon to issue the certificate. When the certificate is issued, you should see something like the image below. You may have noticed that the Renewal eligibility is inegibile. Don\u0026rsquo;t worry about it; ACM certificates are ineligible for renewal if they aren\u0026rsquo;t associated with any other AWS service.\nNow that we have the certificate, let\u0026rsquo;s proceed to setting up CloudFront.\nCreate a CloudFront Distribution # Navigate to Amazon CloudFront in the AWS Management Console. In the Distributions view, click the Create Distribution button. In the Origin Settings section, select the S3 bucket hosting your website. The wizard will display a warning message reccommending the use of the S3 endpoint rather than the bucket endpoint. Let\u0026rsquo;s trust the wizard and click the Use website endpoint button. Keep all the pre-selected options in the Origin Settings section unless you have specific needs for your website. In the Default cache behavior section, keep all the pre-selected options, making sure that the Viewer Protocol Policy is Redirect HTTP to HTTPS. Again, if you have other needs for your website, feel free to select the options you prefer. The settings section # In the Settings section, there are a few more details to address.\nSelect price class # Your choice here depends on your circumstance. In most cases, you\u0026rsquo;ll want to avoid excessive costs and you likely know the primary location of your users. For cost-effectiveness, I would suggest choosing a lower price class. Personally, I often choose Use only North America and Europe class. If budget isn\u0026rsquo;t a constraint and efficiency is your priority, opt for the Use all edge locations option.\nConfigure Alternate Domain Names (CNAMEs) # Include both your domain name and root domain name here.\nCustom SSL Certificate # Simply select the certificate you created earlier from the dropdown menu.\nkeep all the preselected options as they are, unless your requirements differ. Scroll to the bottom and click the Create distribution button. By clicking the Create distribution button, you will be redirect to the new distribution dashboard. Under the General tab, you can see the status of your distribution creation. Deployment typically takes 15 to 20 minutes. Once completed, the status will change to deployed. Edit Alias records to route traffic to CloudFront distribution # In Part 3 you created alias records to route traffic to your S3 website. With the CloudFront distribution now in place, our goal is to redirect traffic to the distribution. Let\u0026rsquo;s go to Amazon Route 53 dashboard. In the Hosted Zones view, select the zone associated with your domain. If you recall, we have two A records—one for the domain and one for the root domain. Choose the first one, and a side menu will appear on the right. Click on the Edit record button.\nYou need to update the Route traffic to section to Alias to CloudFront distribution. CUse the search input to select the distribution created in the previous step. Repeat the same process for the subdomain A record.\nNow, all that\u0026rsquo;s left is to wait for the DNS changes to propagate. Access your website using the custom domain over HTTPS (e.g., https://www.example.com).\nCongratulations 🚀🎉! You now have a secure and high-performing static website hosted on S3, complete with a custom domain.\nConclusion # In this article, we explored how to integrate Amazon CloudFront with your Amazon S3-hosted website, enabling HTTPS connections and enhancing overall performance.\nThis marks the final article in the \u0026ldquo;Host a Static Website on AWS S3\u0026rdquo; series. I hope I\u0026rsquo;ve managed to streamline the process of hosting a static website using AWS S3.\nThis Article is part 4 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series. You can find it in the dropdown component below.\nIf you have questions or would like to provide feedback, email me at martina.theindiecoder@gmail.com.\nResources # Request public certificate\nIneligible certificate\nCNAMEs and HTTPS requirements\nDNS validation\nAmazon CloudFront introduction\nWorking with distributions\nWebsite hosting - CloudFront Walkthrough\nCloudFront price class\n","date":"12 August 2023","permalink":"/posts/use-amazon-cloudfront-to-serve-https-requests-for-your-s3-website/","section":"Posts","summary":"In this article, we will explore how to leverage Amazon CloudFront to serve your S3-hosted website over HTTPS, enhancing security and delivering a seamless user experience.\nThis Article is part 4 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series. You can find it in the dropdown component above.","title":"Use Amazon CloudFront to serve HTTPS for your S3-hosted website"},{"content":"","date":"11 August 2023","permalink":"/tags/hosting/","section":"Tags","summary":"","title":"hosting"},{"content":"","date":"11 August 2023","permalink":"/categories/hosting/","section":"Categories","summary":"","title":"hosting"},{"content":"","date":"11 August 2023","permalink":"/tags/route53/","section":"Tags","summary":"","title":"route53"},{"content":"","date":"11 August 2023","permalink":"/categories/route53/","section":"Categories","summary":"","title":"Route53"},{"content":"In this article, I will show you how to use a custom domain for your Amazon S3 static website.\nThis Article is part 3 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series. You can find it in the dropdown component above.\nPrerequisite # You have a domain registered with Route 53 (See Part: 1).\nYou should also have a static website uploaded to an S3 bucket that has web static endpoint enabled, and its name matches the domain name (See Part 2).\nIf you haven\u0026rsquo;t followed Part 2 but you are reading this article because you want to use a custom domain name for your S3-hosted website, make sure that the bucket name exactly matches the domain you choose. For example, if you registered acme.com domain, then the bucket name should be acme.com. So now that you have a domain registered and your website on S3, it\u0026rsquo;s time to put pieces together.\nCreate a subdomain bucket # After signing in to the AWS Management Console, search for \u0026ldquo;S3\u0026rdquo; in the top bar and go to S3 service dashboard. Here, navigate to Buckets and click the Create bucket button. In the General configuration section, you need to enter the bucket name and choose the region where you want to create the bucket.\nInsert bucket Name # The bucket name for the subdomain bucket should be: www.your-domain\nFor example, if your domain is acme.com, then the bucket name would be www.acme.com\nChoose the region # Once again, in the AWS context, a region is a physical location where AWS data centers are located. There are 32 regions available to choose from, and you should select a region that is geographically close to your website\u0026rsquo;s users to reduce both costs and latency. Choose the same that you select for the website hosting bucket.\nOnce you have entered the bucket name and chosen the region, leave all the other options as they are, scroll down, and press the Create bucket button.\nEnable website redirect for subdomain bucket # After clicking on the Create bucket button, you will be redirected to the Buckets page, where all your buckets are listed. Find the bucket you have just created and click on it.\nHere you\u0026rsquo;ll see the general dashboard for the bucket. Go to Properties.\nScroll down to the end of the page to the tab with the Static website hosting option. Click the edit button, and in the new view, check Enable option.\nSelect Redirect requests for an object as Hosting Type.\nInstert the name of the domain in the Host Name field.\nChoose http as Protocol.\nClick the Save changes button. Configuring Amazon Route 53 to route traffic to your S3 website # Navigate to the Amazon Route 53 service and goto Hosted zones. You should see the one that Amazon created for you when you registered your domain. The hosted zone\u0026rsquo;s name matches your domain. Click on it.\nBy clicking on the hosted zone, you will see a two records created for you by Route 53 at the moment of the domain registration. Click the Create record button. Here you should see Quick create record view.\nWe want to create 2 records:\none for the root domain (acme.com) one for the subdomain (www.acme.com) Create an alias record to route traffic to root domain # Since we are creating the record for the root domain, leave the record name field empty. For the record type, select the preselected A - Routes traffic to an IPv4 address and some AWS resources option.\nEnable the Alias switch.\nRoute traffic to section will show up. Click the Choose endpoint dropdown and select Alias to S3 website endpoint.\nClick the Choose region dropdown and select the region of your bucket, in my case, it\u0026rsquo;s Europe(Stockholm) which corresponds to eu-north-1.\nClick into the Enter S3 endpoint input field: the S3 website endpoint of your website should appear. Select that endpoint.\nChoose Simple routing as Routing Policy.\nDisable Evaluate target health option.\nIf you\u0026rsquo;ve followed all the instructions above, you should see something like the example below.\nClick the Add another record button.\nCreate an alias record to route traffic to www subdomain. # In record name field add www as the subdomain.\nPopulate all the fields with the same information you used for the root domain record.\nClick the Create Records button.\nAnd that\u0026rsquo;s it 🚀! You are now redirecting traffic to my S3-hosted website 🎉.\nIn the next part of the series we will see how to use Amazon CloudFront to serve HTTPS requests for an S3 website.\nConclusion # This Article is part 3 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series. You can find it in the dropdown component below.\nIf you have questions or would like to provide feedback, email me at martina.theindiecoder@gmail.com.\nResources # Website hosting domain walkthrough\nRouting to S3 bucket\nHow Route 53 chooses records\nRoute 53 Routing Policy\n","date":"11 August 2023","permalink":"/posts/how-to-use-a-custom-domain-for-your-aws-s3-static-website/","section":"Posts","summary":"In this article, I will show you how to use a custom domain for your Amazon S3 static website.\nThis Article is part 3 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series. You can find it in the dropdown component above.\nPrerequisite # You have a domain registered with Route 53 (See Part: 1).","title":"Use a custom domain for you Amazon S3 static website"},{"content":"Amazon S3, which stands for Simple Storage Service, is an object storage service which, offers several features including the ability to host static websites. Today, I am going to provide you a step-by-step guide to deploy your website on S3.\nThis Article is part 2 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series. You can find it in the dropdown component above.\nGood to know # S3 is an object storage service provided by AWS where you can store and organize your data in buckets. S3 allows you to configure a bucket as a static website, with an endpoint being the Amazon S3 web endpoint for your bucket. The format of an S3 web endpoint depends on the region where the bucket was created and can be one of the following:\ns3-website dash (-) Region:\nhttp://{your-bucket-name}.s3-website-{your-region}.amazonaws.com s3-website dot (.) Region:\nhttp://{your-bucket-name}.s3-website.{your-region}.amazonaws.com As you might have noticed, the website endpoint formats shown above use HTTP because S3 website endpoints do not support HTTPS. While this might sound disappointing, don\u0026rsquo;t worry; it\u0026rsquo;s possible to use HTTPS instead of the HTTP protocol.\nYou can find a guide to achieve that in the part 4 of this series. In this article we will focus on enabling the bucket to store a static website.\nPrerequisites # You need to have an AWS account.\nStep 1: create a bucket # After signing in to the AWS Management Console, search for \u0026ldquo;S3\u0026rdquo; in the top bar and navigate to S3 service dashboard. Here, go to Buckets and click on Create bucket button. Under the General configuration section, you need to enter the chosen name for the bucket and choose the region where you want to create the bucket.\nEnter bucket Name # At the beginning of this article, I showed you the possible formats an S3 website endpoint. Let\u0026rsquo;s review them again:\ns3-website dash (-) Region:\nhttp://{your-bucket-name}.s3-website-{your-region}.amazonaws.com s3-website dot (.) Region:\nhttp://{your-bucket-name}.s3-website.{your-region}.amazonaws.com The bucket name you choose will be part of the endpoint for your website. Therefore, select a bucket name that makes sense in the context of your website, especially if you do not plan to use a custom domain.\nIf you want to configure a custom domain for your static website, the bucket name must exactly match the domain name you choose. For example, if you registered acme.com domain, then the bucket name should be acme.com. S3 has specific naming rules that you can find here\nChoose the region # In the AWS context, a region is a physical location where AWS data centers are located. There are 32 regions available to choose from, and you should select a region that is geographically close to your website\u0026rsquo;s users to reduce both costs and latency.\nOnce you have entered a bucket name and chosen a region, leave al the other options as they are, scroll down, and click the Create bucket button.\nStep 2: Enable Static web static hosting # After clicking the Create bucket button, you will be redirected to the Buckets page, where all your buckets are listed. Find the bucket you have just created and click on it.\nHere you will see the general dashboard for the bucket. Go to Properties. Scroll down to the tab with the Static website hosting option. Click on the edit button, and in the new view, check Enable option. Keep the preselected Host a static website as the Hosting Type.\nSpecify the home page or default page of the website in the Index document input, for example index.html You can also specify the path for an error page if you choose to do so.\nScroll down to the bottom of the page and click the Save changes button. If you go back to Static website hosting tab under Properties, you can see that S3 has generated a website endpoint for your bucket. Step 3: Upload your website # Now it\u0026rsquo;s time to upload your website to the bucket. Click the Upload button. Here, you can drag and drop all files and folders of your website, or add them separately by clicking the Add files and Add folder buttons.\nAs you can see in the picture below, I have just uploaded a simple index.html file. Once you are done, click the Upload button at the bottom of the page. S3 will redirect you to the upload status page. Click the Close button. S3 will redirect you to your bucket dashboard.\nIf you try to reach your website now, you will get encounter 403 Forbidden Error. To make the website available, you need to set up permissions.\nStep 4: Set permissions # In your bucket dashboard, go to Permissions tab. Two things must be done:\nDisable \u0026ldquo;block all public access\u0026rdquo; Attach a bucket policy Disable \u0026ldquo;block all public access\u0026rdquo; # In the Block public access section, uncheck the Block all public access option. Scroll down and click the Save changes button. S3 will display a pop-up warning you that the objects will be public. You need to have them public if you want people to access your website, so don\u0026rsquo;t be scared and enter confirm in the input field and click the Confirm button. Attach a bucket policy # The last thing remaining to do is to add a bucket policy to allow users to access your website files stored in your bucket. Under the Permissions tab, in the bucket policy section, click the Edit button. Copy the following snippet and paste in the policy section. Remember to change Bucket-name with your actual bucket name.\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;PublicReadGetObject\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Principal\u0026#34;: \u0026#34;*\u0026#34;, \u0026#34;Action\u0026#34;: [ \u0026#34;s3:GetObject\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;arn:aws:s3:::Bucket-Name/*\u0026#34; ] } ] } Click the Save change button.\nAnd we are done! 🚀\nIf you try to access your website now, you should be able to reach it.\nConclusion # This post aims to show you how to host a static website on AWS S3. I hope it helps you.\nThis Article is part 1 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series. You can find it in the dropdown component below.\nIf you have questions or would like to provide feedback, email me at martina.theindiecoder@gmail.com.\nResources # Website endpoints\nS3 website region endpoints\nCreating S3 bucket\nEnable Website hosting\n","date":"10 August 2023","permalink":"/posts/how-to-deploy-a-static-website-on-aws-s3/","section":"Posts","summary":"Amazon S3, which stands for Simple Storage Service, is an object storage service which, offers several features including the ability to host static websites. Today, I am going to provide you a step-by-step guide to deploy your website on S3.\nThis Article is part 2 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series.","title":"Deploy a static website on AWS S3"},{"content":"","date":"9 August 2023","permalink":"/tags/dns/","section":"Tags","summary":"","title":"DNS"},{"content":"Amazon Route 53 is a highly available and scalable Domain Name System service offered by AWS. Key features of Amazon Route 53 include domain registration, which allows you to register available domain names or transfer existing domain names.\nIn this article, I will show you how to register an available domain with Amazon Route 53. This Article is part 1 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series. You can find it in the dropdown component above.\nPrerequisites # You need to have an AWS account.\nSearch for an available domain # Once signed in to AWS Management Console, search for \u0026ldquo;Route 53\u0026rdquo; in the top bar and click on the first result. This will take you to the Route 53 dashboard. In the dashboard, go to the \u0026ldquo;Register domain\u0026rdquo; section and enter the domain name you wish to register. Click on the Check button. Register a New Domain # When clicking on the Check button, Route 53 will check the availability of the domain. If the domain is not avaialble, you should see an info badge in the Search result section. Otherwise, you will see the domain labeled as an exact match and the price per year.\nIn both the cases, whether your preferred name is already taken or not, Route 53 will suggest 10 alternative available options. Select the domain you want to register. You will see the selected domains and the subtotal on the right side. You can select up to 5 domains. Fill in Contact information # After selecting an available domain, you\u0026rsquo;ll need to fill in contact information. When you register a domain name, information related to that domain is added to a WHOIS database. WHOIS databases store information of all domains registerd around the world. The stored information includes:\nRegistrant contact: the actual owner of the domain, considered the highest authority for the domain. Administrative contact: the admin of the domain. with full access rights to the domain name. Technical contact: the contact in charge of handling any technical issues related to your domain. The information you are entering in this section, will be applied to all the domains you selected in the previous step. Registrant contact # Provide accurate registrant contact details, including the registrant\u0026rsquo;s type, name, email, phone number and address. Admin contact # In this section, you will see a switch that, if checked, will set Administrative contact the same as registrant contact. The switch is checked by default, but if needed, you can uncheck it and set personalized information.\nTech contact # The same applies to the technical contact as for the administrative contact.\nPrivacy protection # Decide whether you want to enable privacy protection (WHOIS privacy) for your domain. This feature shields your personal information from being publicly visible in the domain\u0026rsquo;s WHOIS records. If you don\u0026rsquo;t know what WHOIS is, read here: https://en.wikipedia.org/wiki/WHOIS Click on the Next button, which will bring you to Review and Submit view.\nReview and Submit # Double-check all the entered information, read and check the box to agree to the Amazon Route 53 Domain Name Registration End User Agreement. Proceed to make the payment for domain registration, by clicking the Submit button. Complete Domain Verification # If you specified an email address for the registrant contact that has never been used to register a domain with Route 53, you might be asked to verify that your email address is valid. Amazon sends a verification email either from noreply@registrar.amazon.com or noreply@domainnameverification.net depending on if the domain was registered by Amazon Registrar or Gandi, their Registrar Associate.\nYou have 14 days to verify your email addres. After that the domain(s) you have registered will be suspended and they will be unavailable on the internet. Follow the instructions provided in the email to complete the verification process.\nYou can follow the status of your request(s) by going to Domains \u0026gt; Requests. When the process is completed, the status of the request will go from In progress to Successful and you will receive a confirmation email from route53-dev-admin@amazon.com. Route 53 will also create a hosted zone for the domain.The hosted zone and domain will have the same name. A hosted zone is a container for DNS records. Read more about hosted zones here.\nCongratulations 🎉! Your domain name is registered.\nOnce your domain is registered and verified, you can manage it through the Route 53 dashboard. This includes updating DNS records, configuring subdomains, and renewing your domain registration.\nConclusion # Amazon Route 53 is a highly available and scalable Domain Name System service offered by AWS. Today we have seen how easy it is to register a domain name with this Amazon service. I hope it was helpful.\nThis Article is part 1 of the \u0026ldquo;Host a static website on AWS S3\u0026rdquo; series. You can find it in the dropdown component below.\nIf you have questions or would like to provide feedback, email me at martina.theindiecoder@gmail.com.\nResources # Domain Register\n","date":"9 August 2023","permalink":"/posts/how-to-register-a-domain-with-route53/","section":"Posts","summary":"Amazon Route 53 is a highly available and scalable Domain Name System service offered by AWS. Key features of Amazon Route 53 include domain registration, which allows you to register available domain names or transfer existing domain names.\nIn this article, I will show you how to register an available domain with Amazon Route 53.","title":"Register a domain with Amazon Route 53"},{"content":"Hosting a static website on AWS S3 is quite easy. You upload your website to an S3 bucket, enable the static website hosting option and voila, your website is up and running in less than 5 minutes.\nThe truth is, when you make your website live, in many cases, you might want use a domain name for it instead of Amazon S3 web endpoints and definitely use HTTPS instead of HTTP.\nTo host a website on AWS S3 and have all the aforementioned elements in place, there is a risk of getting lost in numerous details and AWS documentation pages.\nWith this series, I am going to try to streamline the process by condensimg all the required information into 4 articles, along with 1 special article about costs analysis.\nI hope this series will be helpful. Enjoy it! 🚀\nIf you have questions or would like to provide feedback, email me at martina.theindiecoder@gmail.com.\n","date":"8 August 2023","permalink":"/posts/how-to-host-a-static-website-on-aws-s3/","section":"Posts","summary":"Hosting a static website on AWS S3 is quite easy. You upload your website to an S3 bucket, enable the static website hosting option and voila, your website is up and running in less than 5 minutes.\nThe truth is, when you make your website live, in many cases, you might want use a domain name for it instead of Amazon S3 web endpoints and definitely use HTTPS instead of HTTP.","title":"Series - Host a static website on AWS S3"},{"content":"","date":"9 July 2023","permalink":"/tags/elasticsearch/","section":"Tags","summary":"","title":"Elasticsearch"},{"content":"","date":"9 July 2023","permalink":"/categories/elasticsearch/","section":"Categories","summary":"","title":"Elasticsearch"},{"content":"In this post I am going to show you how easy it is to install and run Elasticsearch on your local machine. How to achieve this is really well explained in the Elastic documentation. However, I would like to show you how to do it using the interface instead of the command line.\nStep 1: Install Docker # If you don\u0026rsquo;t have Docker installed, you have to install it. You can download Docker Desktop from here.\nWhen you open the application for the first time, Docker will prompt you to choose between using reccomended setttings or customizing them. For our purpose, choosing the reccomended settings is enough (refer to the picture below).\nconfiguration preference Step 2: Adjust Docker memory size # To run the Elasticsearch container without any issues, you need to allocate at least 4GB of memory. If you are using the macOS version of Docker Desktop, follow these steps:\nClick on the settings icon in the top bar Go to Resources \u0026gt; Advanced docker settings window If you have installed version 4.x.x of Docker, the memory is already set to 4GB, but it is always good to double-check.\nStep 3: Pull Elasticsearch and Kibana images # Now it\u0026rsquo;s time to pull elasticsearch and kibana images from Docker Hub. In the search bar at the top, search for elasticsearch. docker search bar You will see both the elasticsearch and kibana images. Pull elasticsearch image, and do the same for kibana. elasticsearch and kibana images Step 4: Start Containers for the images # Under the Images tab, you will find the images that you pulled in the previous step. First, run elasticsearch container. Under Actions click on Run. A popup will show up. Click on optional settings and provide the following information:\nContainer name Host ports Set discovery.type environemt variable with the value set to single node optional settings elasticsearch Now do the same for kibana. You only need to add a name and the port. optional settings kibana You can see both containers up and running under Containers tab.\nStep 5: Setting up kibana # To complete the setup, we need to perform the following steps:\nCreate a new enrollment token Reset the password for the elastic user. create new enrollment token # To generate a new enrollment token, go to Containers \u0026gt; click on elasticsearch container and in the terminal run:\nbin/elasticsearch-create-enrollment-token --scope kibana enrollment-token reset elastic user password # In the terminal of elasticsearch container, run the following command:\nbin/elasticsearch-reset-password -u elastic You should see a result similar to this: reset password Type y and you will see the new password. reset password result Once we have the token and password, go to Containers \u0026gt; click on kibana container and go to Logs tab. Click on the link you find there. It should look something like this:\nhttp://0.0.0.0:5601/?code=000000 Paste the enrollment token you created earlier. kibana get started At this point you can log in as the elastic user with the password you just reset. kibana login And you\u0026rsquo;re done! 🚀 elasticsearch and kibana up and running on your local machine.\nYou can test it out using the kibana console at Management \u0026gt; Dev Tools.\nWhen you\u0026rsquo;re finished you can stop the containers and close Docker.\nIf you want to restart elasticsearch, simply start the elasticsearch container first and when it is up, start kibana.\nGo to:\nhttp://0.0.0.0:5601 and log in again.\nConclusions # This post aims to show you how to run Elasticsearch locally using Docker Desktop interface. I hope it helps you.\nResources # Elastic documentation\n","date":"9 July 2023","permalink":"/posts/run-elasticearch-locally/","section":"Posts","summary":"In this post I am going to show you how easy it is to install and run Elasticsearch on your local machine. How to achieve this is really well explained in the Elastic documentation. However, I would like to show you how to do it using the interface instead of the command line.","title":"Run Elasticsearch locally"},{"content":"","date":"9 July 2023","permalink":"/categories/testing/","section":"Categories","summary":"","title":"testing"}]