Forem: Mihaly Balassy

Amazon Bedrock – Consistent Anthropic FM pricing across regions

Mihaly Balassy — Thu, 04 Jul 2024 15:40:32 +0000

AWS typically offers varying prices for each service across its global regions. However, if we look at Amazon Bedrock Anthropic On-Demand and Batch prices we see a different pattern. They are consistent across regions. The primary variation lies in the model versions available in each region. As new regions are continuously added to Amazon Bedrock, it’s a good idea to look at what each region offers.

Amazon Bedrock is available in 13 AWS regions:

US East (N. Virginia)
US West (Oregon)
Asia Pacific (Tokyo)
Asia Pacific (Singapore – limited access)
Asia Pacific (Sydney)
Asia Pacific (Mumbai)
Canada (Central)
Europe (London)
Europe (Frankfurt)
Europe (Paris)
Europe (Ireland – limited access)
South America (São Paulo)
AWS GovCloud (US-West)

💡 Note: Due to limited access in Ireland, Singapore and GovCloud, these regions are excluded from my analysis, leaving us with 10 regions for comparison.

Anthropic uses "Haiku" for its smallest model, "Sonnet" for the mid-range option, and "Opus" for its top-tier model.

On June 21, 2024, Anthropic introduced Claude 3.5 Sonnet, claiming it can match or exceed OpenAI's GPT-4o or Google's Gemini across numerous tasks. This new model is exclusively available through the Anthropic API, Amazon Bedrock, and Google Cloud's Vertex AI. Since this is a new model, it is currently only available from us-east-1 at the time of this blog post.

When it comes to Amazon Bedrock, the rule of thumb you've come to know about AWS pricing and service availability no longer applies. If you are based in Europe, you have learned that the region with the most services is Ireland (eu-west-1) and that the cheapest option is usually Stockholm (eu-north-1).
With Bedrock, this all changes; the region that offer the most Anthropic FM's for Europe is Frankfurt (eu-central-1). If you're developing with Generative AI in Europe, Frankfurt is now your best choice.
In the US, your rule of thumb remains the same, with us-east-1 being the region that provides the most functionality, but there is a catch: the highest-end model, Claude 3 Opus is only available in Oregon.

Amazon Bedrock's on-demand and batch pricing is consistent across regions (e.g., you pay the same for Claude 3 Haiku in Oregon and Canada). In fact, Claude Sonnet 3 and 3.5 cost the same. This uniform pricing strategy underscores AWS's commitment to making advanced Generative AI models accessible and affordable for developers.

Provisioned Throughput pricing

When we look at the provisioned throughput pricing, we see fewer choices. We are limited to Claude Instant and Claude 2.0/2.1 models and with only 4 regions. Frankfurt is right behind the top US regions in terms of prices, with Tokyo being the most expensive.

Summary

AWS demonstrates its strong commitment to Generative AI through multiple actions. It offers competitive pricing for Anthropic's foundation models, continually expands Bedrock's availability to new regions, and promptly makes the latest foundation models accessible to its users.

These efforts highlight AWS's dedication to advancing and supporting Generative AI, providing developers with the latest tools at affordable prices.

Free and easy DIY digital business card

Mihaly Balassy — Mon, 29 Jan 2024 13:04:39 +0000

Recently, I wanted to order a new business card for myself and while Googling I came across dozens of startups that produce digital business cards. After checking out several offers, I realized that the most important thing these companies lack is reliability. If you give someone a physical business card, you can be sure that they will know your information for a long time (unless they lose it 🤫). There’s no guarantee that these startups will still be around in 5 or 10 years, or that they won’t raise their fees. That is why I created the serverless-business-card.

I saw a video on YouTube about how to make your business card smart with a simple NFC sticker. The problem is that while you can program a vCard into a sticker, iOS devices don’t support them yet. The only way to get an iPhone to read an NFC vCard is to host the vCard file on the web. Then it hit me. 🤯 Why not host the vCard on AWS using only free tier resources. 😎

The obvious solution was Lambda and Lambda Function URLs since they are completely free. Plus, you can be sure that AWS will still be around in 5 or 10 years, so your digital business card will still be running.
Also, it’s very easy to update your information if something changes, you don’t have to buy a new one. Which is good for the environment too! 👍 🌎

During development I ran into issues that required creating extra policies to make it work. Since I wanted to make it as simple as possible for everyone to use it I created a CloudFormation template that creates all the resources for you.
And when you no longer need it, CloudFormation can delete all the used resources. But why would you do that when it’s completely free. 🤑🤑🤑

The code is written in Node.js 18.x and produces a v. 3.0 vCard. You might ask why not v. 4.0 and the answer is simple. Apple doesn’t support it and I wanted to make it as compatible as possible.
The other problem I faced is that according to the vCard specifications you can link an image URL as your photo, but Apple devices don’t support that either. The photo should be Base64 encoded in your vCard.
That is why CloudFormation creates an S3 bucket where you can store your photo (avatar.jpeg) and the Lambda function will convert it to Base64 and include it in your card.

Not just Apple, AWS has some weird things too. For example, when you create a FunctionURL for your Lambda function, this URL is not defined in your Lambda environment variable. To get the FunctionURL, you need to grant the GetFunctionUrlConfig role to read your function URL. Since a vCard allows you to define the source of the vCard where you can always get the latest version, I had to create a policy and attach it to the Lambda role to include the FunctionURL in the vCard.

The other issue I faced is that while you can include your Lambda code in CloudFormation, it creates an index.js file instead of an index.mjs which is required for Node.js 18.x. There is a solution to include the code in an S3 bucket and CloudFormation will retrieve the code from there, but then you are stuck with the region where your S3 bucket is. So I created two CloudFormation templates. 😀
If you want the easiest installation and don’t want to change your region, use the default template. This will run in US East (N. Virginia). If you want to host your business card in another region, use the template-with-code.yaml instead, but you will need to rename index.js to index.mjs for the code to work.

All the source code is available on GitHub under the Apache 2.0 license. See the GitHub page for detailed installation information.
Use template.yaml if you don’t want the simplest installation.
If you want to specify the region in which the resources are created, use the template-with-code.yaml stack instead and rename the index.js source file to index.mjs.

I hope this little code is as useful as it was fun to write it. 👨‍💻

Please give a star to the project's GitHub page if you found this useful. Thank you. 🙏🙏🙏

Bringing together Hungarian technology conferences

Mihaly Balassy — Mon, 20 Mar 2023 10:57:17 +0000

As an AWS Community Builder, I realized that in small countries like Hungary, it’s a challenge to find local AWS events. Most of them are organized by local companies and tailored to their customer base. For someone who is new to AWS or who wants to learn about new technologies, it can be a struggle to find these events because they most likely don’t know that one of the sessions is about AWS. While these events are usually open to everyone, I wanted to find a way to overcome this obstacle.

I was looking for a solution that was open source and that anyone could contribute to it. While discussing this issue with María Encinar (EMEA Community Programs Manager - AWS), it turned out that other European countries are facing similar problems and there is also a trend on these conference websites. She recommended me this GitHub repository. 🙏
As far as I could track it down it all started with Android Study Group, which created a GitHub Page for Android conferences. Spain, Portugal, Italy and even Canada soon followed. I realized right away that I am on the right track. The source code is open source, hosted on GitHub and anyone can contribute to it with a simple Pull request. This was a great foundation, but I knew I wanted more. 🏋️‍♂️

Hungarian translation

The main problem we face here in Hungary is that while there are a lot of events happening here, some are primarily in English. For someone who is just starting with AWS, this could be an extra challenge that they might not take. That is why my first improvement was to translate the interface into Hungarian. I didn’t want to exclude English speakers as well, so I made the interface bilingual. This way everyone can feel comfortable on the website.

The other improvement I made is that I clearly highlighted the language of the conference. This way I can help people who prefer content in their native language. 🇭🇺

Deployment on AWS

I cannot ignore the fact that I am an AWS Community Builder, so it was a no-brainer that I would implement this on AWS. Registering a domain and setting it up on Route 53 was the first step. Then I looked at the possibilities of hosting. The site is written in Jeklly and each page is generated separately. Using GitHub Actions, I can regenerate the static pages every time there is a new commit.
Hosting a static website on AWS isn’t rocket science. S3 static file hosting is a cheap and easy way. I just needed to find a way how to publish my files to S3. Jake Jarvis created a GitHub Action that can sync your files to S3. All you have to do is to create the appropriate IAM permissions and your files will be pushed to the S3 bucket of your choice. From there, AWS will do the rest. I have created a CloudFront distribution to get HTTPS and fast access from Hungary. Currently, there is no AWS region in Hungary, but there is an edge location in Budapest, so serving the site from there gives fast access to Hungarian users. 🔥🔥🔥

The outcome

The result is techconf.hu, a community-curated list of tech conferences around Hungary. I sincerely hope that this project will benefit the Hungarian AWS community, and perhaps other countries facing similar issues will follow. Happy Conferencing!

Restricting AWS Lambda Function URLs to CloudFront

Mihaly Balassy — Tue, 07 Mar 2023 19:44:15 +0000

AWS Lambda Function URLs are a great thing that fits seamlessly into AWS’s serverless vision. Combined with S3 static hosting and CloudFront, it is the ideal platform for high performance website hosting without the hassle of managing a complex underline infrastructure.

The basics: S3 static website hosting

Hosting your static website has never been easier. With Amazon S3 static hosting, you can serve your static pages by simply uploading it to an S3 bucket and enabling public access (be sure to name your bucket as your domain name). You can find a lot of articles on the web that explain how to set up S3 static hosting, which is why I am not going to go into any further details here.

But there are limitations: S3 static hosting doesn’t support HTTPS, the de-facto-minimum for website hosting. To use HTTPS, you need to set up Amazon CloudFront. This comes with a lot of extra features like GeoIP restrictions, caching and a free SSL certificate. Not to mention, you can finally disable your S3 public access (which could be a security risk) and give limited access to CloudFront only (with a bucket policy).

Pro tip: Give CloudFront ListBucket permissions in your S3 bucket policy, otherwise the client will not receive HTTP status codes, including a 404 when trying to access non-existent content:

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::roadtoaws.com",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/AAAAAAAAAAAAA"
                }
            }
        },
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::roadtoaws.com/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/AAAAAAAAAAAAA"
                }
            }
        }
    ]
}

Because of the caching involved with CloudFront, this is not ideal for development. You either have to test your code locally or without HTTPS enabled. This is the main reason why I would still like to see HTTPS support in S3 in the future. 🔮

Make it dynamic

Static websites are a thing of the past. You will most likely need some kind of dynamic content. While there are a lot of services that provide functionality, like E-mail sending, Comments, that you could include in your static code to make it dynamic, you’d most likely have to write your own code. This is where Lambda Function URLs come in handy. With a simple Lambda function, you can execute code or use other AWS resources that you can invoke with a simple HTTP request in your browser. But how do you restrict it to a specific IP, domain, or CloudFront? 🤔

AWS recommends authenticating through IAM, and while this is really a secure way, it makes development challenging. The first thing you see is CORS where you can set your origin to a domain. Unfortunately, this didn’t work for me the way I wanted it to. This doesn’t restrict your Lambda from being called from any IP. You can also set an X-Custom header here, but that doesn’t really limit external access.

Then you look for matching IAM permissions that you can attach to Lambda functions. In the available Policies you can find InvokeFunctionUrl where you can add an IP address to limit the invocation to a specific IP. This sounds great! You create a policy and attach it to your Lambda Role. Unfortunately, this does not restrict your Lambda access either.

So what was my solution? 🙋🙋🙋

1. Restrict in code

The first obvious solution is to check the source IP with your Lambda function. Here is a sample code in Node.js (you can find a similar code for other languages online):

const ipAddress = event.identity.sourceIP;

if (ipAddress === '52.84.106.111') {
  const error = {
      statusCode: 403,
      body: JSON.stringify('Access denied'),
  };

  return error;
} else {
  const hello = {
      statusCode: 200,
      body: JSON.stringify('Hello World!'),
  };

  return hello;
}

While this obviously works, you’re adding extra code to a Lambda function that’s primary role is to do something else. Not to mention that this will increase the runtime and the resources used by Lambda. Most importantly, how can you be sure that the IP you get in the sourceIP variable is really the IP the client comes from.

My biggest concern with this solution was that I not only wanted to restrict my functions to one specific IP but to the whole CloudFront distribution – so that I can be sure that it is called from one of my static pages –. With this method, it would be a hassle to maintain an up-to-date list of all CloudFront servers. 📝📝

2. reCAPTCHA

Yes, you heard it right, Google reCAPTCHA. This may sound strange at first, but this is the solution I have implemented in my work and provides the solutions to the above challenges.

Embeding the reCAPTCHA code in your static web pages is a good idea. In fact, Google recommends that you include the code in all of your pages – not just the ones that you need it, such as form validations – because that way the algorithm can more effectively detect fraudulent use. Within the lambda function, I can now validate whether or not the user really invoked my Lambda function URL from my static web page. Here is the code I use to verify the reCAPTCHA request:

const gRecaptchaResponse = event.queryStringParameters["g-recaptcha-response"];

    var verificationUrl = "https://www.google.com/recaptcha/api/siteverify?secret=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&response=" + gRecaptchaResponse;
    const recaptchaResult = await getRequest(verificationUrl);

    if (false == recaptchaResult.success || 0.5 > recaptchaResult.score) {
      return error;
    }

In conclusion

S3 static website hosting is the easiest way to start with your serverless journey. While there are obstacles ahead you can always find a serverless solution. 🏆

Operational best practices for AWS Well-Architected Framework

Mihaly Balassy — Wed, 06 Apr 2022 18:24:43 +0000

In a traditional hosting environment, you have to guess infrastructure needs, usually couldn’t afford to test at scale, could not justify experiments, sometimes have a fear of change, and could easily face with an architecture that was frozen in time. By migrating to the cloud you can overcome these issues, but how do you know that the practices you follow leverages these advantages.
The AWS Well-Architected Framework provides design principles that ensure that your cloud environment is built efficiently, securely and is high-performing and resilient. 👌

The AWS Well-Architected Framework consists of six pillars:

⚙️ Operational excellence
🔒 Security
⛓️ Reliability
🚀 Performance efficiency
💸 Cost optimization
🌳 Sustainability

AWS not only provides training and documentation on the AWS Well-Architected Framework but also provides the tools you can use to monitor your cloud infrastructure.

In this blog post, I will present a method on how to test your cloud environment against the Security and Reliability pillars of the AWS Well-Architected Framework.

🔒 The Security pillar focuses on the ability to protect information, systems, and assets while delivering business value through risk assessments and migration strategies.
⛓️ The Reliability pillar focuses on the ability to recover from failures and meet demand in foundations, workload architecture, change, and failure management.

Setup

AWS Systems Manager is the go-to place to gain operational insights into AWS. Here on the Quick Setup page, we can select Conformance Packs. But let’s not run so far ahead since we need to prepare our environment first. Without that the tests will fail with a not so useful error message. 🤷‍♂️

To prepare our environment we have to enable Config Recording. We can enable this by going to AWS Config and selecting 1-click setup. This will record all resources (excluding global resources) set an AWS Config role and create an S3 bucket. If you would like to fine-tune which resources you would like to record, select or create a specific role or choose a specific S3 bucket select Get started instead. Once recording is enabled we can go back to Systems Manager.

In the Conformance Packs configuration screen, we can select if we would like to check for operational best practices for the AWS Well-Architected Framework Reliability or Security pillars or both. We can schedule when to run the configuration and select our region. Once the pack is deployed the tests usually take a couple of minutes to run. ⏲️

Results

AWS Config will show the results grouped by AWS services.

Clicking on an issue shows a detailed explanation.

Pricing

Pricing is based on the number of conformance pack evaluations. While AWS currently doesn’t show how many evaluations are in each pillar it’s hard to get the exact number without running it. It would be nice if AWS would have fixed pricing for Operational Best Practices conformance packs. AWS Config has a pricing example on their website that shows a total config bill.

Summary

The AWS Well-Architected Framework is a great and unique feature of AWS that differentiates itself from other cloud providers and I don’t see why it’s not yet included in the AWS Free Tier. Having a healthy cloud environment is good both for AWS and for the customer. 👍

Installing AWS CLI on Apple silicon

Mihaly Balassy — Wed, 16 Feb 2022 10:45:26 +0000

You’ve just received you’re shiny new Mac with an Apple silicon processor – like the M1 – and would like to install the AWS CLI. As usual, you download the latest GUI installer from AWS but it prompts for Rosetta. Does this mean that the latest version only supports Intel processors? 🤔

Apple made the transition from Intel to Mac relatively easy for end-users. Rosetta 2 does a wonderful job for applications compiled exclusively for x86-64-based processors to be translated for execution on Apple silicon. Since Apple silicon has been out for a while many developers provide Apple silicon compiled binaries. In fact, there are fewer major companies that don’t provide an Apple silicon version of their app. This is why some people, including myself – never install Rosetta. In this way, I can guarantee that all my apps are optimized for the new processor.

The AWS documentation says that there are three ways to install the CLI on the Mac:

GUI Installer
Command line installer – All users
Command line – Current user

The sad news is that all of these methods use the same macOS pkg file. This installer in this file is not yet optimized for Apple silicon but the included binaries are. This means that you have to install Rosetta just to install an Apple silicon app. Strange, indeed. 🙃 Thankfully there’s another solution that the official documentation doesn’t mention, Brew.

Homebrew is the missing package manager for macOS. You probably already use it if you would like to install apps like wget or mc. Installation is simple and straightforward, just run the following command in your terminal.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Next run these two commands to add Brew to your PATH:

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile eval "$(/opt/homebrew/bin/brew shellenv)"

The only downside I see with Brew is it sends data to Google. It does warn you about this but doesn’t tell you how to turn it off. While Homebrew maintainers say these analytics help them decide on future features and prioritize current work – and recommends them to keep it on – I am still not a fan of personal data collection, even if it’s anonymous. To turn this off simply run the following command:

brew analytics off

Now that Brew is installed you can easily install the AWS CLI by executing the following command:

brew install awscli

Voilà, the AWS CLI is now installed without Rosetta. 🤘

⚠️ I should note that this workaround was needed at the time of writing this article and AWS will probably fix the installer, but until then just use Brew.

Running WordPress on AWS – the cheap and easy way

Mihaly Balassy — Thu, 22 Jul 2021 19:05:29 +0000

You probably heard a lot of good things about AWS and would like to start (or move) your WordPress site there, but you find it difficult to choose the right service and pricing model for it – AWS has over 200 services to choose from with different pricing models. You’re at the right place, this is the article for you! Let’s get started! 🏁

Advantages

What are the advantages of moving to AWS?

First, it has a global footprint! A large hosting provider has only about 2-3 locations where you can host your website. (Small ones have only one). And not only that, you have to decide this during signup so you are stuck with that location for the rest of your life. On the other hand, AWS has dozens of locations (called regions) to choose from and you aren’t stuck with any of them. You can have a WordPress site in Tokyo and another one in Singapore. This is good for a number of reasons: getting closer to your clients (thus they can access your site faster) plus compliance with local regulations.

The other advantage compared to hosting providers is security. AWS is built with security in mind and you can expect that if your WordPress site is set up correctly it will be reliably running. Other users will not impact your websites performance.

AWS can adapt to your current needs and you can easily add or remove resources when needed. You only pay for the resources you consume.

Lastly, you will get a free static IP for each website compared to shared hosting where you share the same IP with others. This is excellent for eCommerce websites.

Intro

The service I will guide you through is called Amazon Lightsail. It has a simplified user interface compared to other AWS services and has fixed monthly pricing. The focus of this article is on how we can have a reliable website up and running but with the cheapest option available. We will use Let’s Encrypt’s free SSL certificate compared to Lightsail CDN which is currently free for the first year (up to 50GB) but costs $2.50 USD/month later. Not to mention that if your visitors increase you may be charged $35 USD/mo. This is why we will only use services that have a fixed fee even if your visitor numbers increase. 💰

Setting up an AWS account

If you don’t already have an AWS account you can create one by visiting the AWS website and clicking in the “Create an AWS Account” button on the top right corner. You will be asked to provide your Email address, password, username, personal information including your phone number and your credit card information. Your card will only be charged for the services you use. It is a good idea to secure your account right after creation. Read my First things to set on a newly created AWS account post on how to enable Multi-Factor Authentication on your account.

Amazon Lightsail

Log in to your AWS account and let’s jump into Amazon Lightsail. In the top bar type lightsail and select the Lightsail service or click on this link to start it directly. If this is your first time you will be asked to select your language. Select it, and click on the Let’s get started button. You will immediately notice that Lightsail has a much more friendlier interface. 🤝

Setting up WordPress

Let’s start by creating an Instance. Lightsail will automatically take you to the instance setup with a Welcome message to start your instance. Later you can create it under the Instances tab, with the Create instance button.

Creating an instance

On the select your instance location you choose the location based on the parameters I outlined before. The good thing about Amazon Lightsail, compared to other AWS services, is that the prices are the same in all regions. (This is not true for other AWS services.) You can freely choose a region and the prices won’t change. I will select the Frankfurt region due to GDPR.

Next, we select the instance image. Since this article is about WordPress, we will select WordPress.

Now here comes the tricky part, that you may have missed if you haven’t read this article. 🤠
You should always select Enable Automatic Snapshots. AWS doesn’t guarantee you that your instance won’t fail, and if it fails your data might be lost. This is why we enable automatic snapshots so we can recover our data easily in case of an emergency. 🦺

Select a pricing option. Choose the option that meets your needs and fits your budget.

Identify your instance with a friendly name. This is just for display purposes; it has no effect on the instance, but you cannot change it later.

Click on Create instance. Please wait a couple of minutes while your instance is being created in the background. After the instance has been created it will show the state “Running” on your Instances tab. Your WordPress site is now up and running, but there are a couple of important things we should set before going on a coffee break. ☕

Attaching a static IP

Click on the instance name and select the Networking tab. Select Create static IP. Name your static IP and click Create. You may ask why this is important when there is already an IP address associated with your instance. The problem is that this IP is from a dynamic pool. This means when you restart your instance your IP address will change, and we don’t want this. By attaching a free static IP, our IP address will stay the same all the time.

Set up DNS

Now it’s time to connect your domain with this IP address. If you don’t have a domain yet and you're Canadian, I suggest registering a .ca domain because country code-specific endings are always favorable; but if you would like to stick with AWS, you can use Route 53 for that.

Point your domain name to the static IP we created earlier. This can be done by updating your A record with this IP.

If everything is set up correctly by entering your domain name in your browser a fresh new WordPress site will appear. 🎉🎉🎉

Setting up SSL

Having an SSL certificate is mandatory nowadays and there are several ways to achieve this. I will be showing how to set up Let’s Encrypt, which is a free SSL certificate authority. For this, I have created a simple script that does the heavy work for you. You can find this script on GitHub. To set up SSL first log into your instance via SSH. This is done by selecting the Connect tab on your instance and clicking on the Connect using SSH button. You will be directed to a terminal window but don’t worry we won’t spend much time here. 😀

A new popup will appear with a terminal. We will paste a simple script in the terminal or you can type it manually. Whichever you prefer.

To paste the script you will find a clipboard icon on the bottom right corner of the window. Click on it and paste the following script in it, then click on the terminal and enter CONTROL + SHIFT + V (or COMMAND + V if you are on a Mac).

wget -O - https://raw.githubusercontent.com/suhajda3/lightsail-ssl/main/lightsail-ssl.sh | sudo bash

The script will ask for your domain name and email address. If everything is set up correctly the script will update your system, set up Let’s Encrypt, and will auto-renew it every 90 days, plus it will display your WordPress credentials. Everything we need. 😎

You can run this script any time you would like to update your system.

📝 Make note of your username and password because we will need this later.

Type exit to log out of the terminal and close the window.

Securing your instance (optional)

Since we don’t need terminal access to the instance all the time, it is a good idea to disable SSH access. To do this, head over to the Networking tab and click on the trash icon next to the SSH row. Be sure that HTTP and HTTPS are still there because without them we couldn’t access our site. When you would like to run the script again or get terminal access, add the SSH rule again. 🔒

Finalizing your WordPress install

Our WordPress instance is now set up correctly. Log in to your WordPress site by adding /wp-login.php to the end of your URL. Here you can log into your site with the credentials that the script displayed before.

Before you leave we should change one last thing. Add your Email address in case you lose your password. On the top right corner select Edit Profile and change your Email address then click Update Profile at the bottom of the page. Next click on Settings, General on the left side and change the Administration Email Address as well.

Your WordPress site is now up and running. Congratulations! 😌 🥳

What is AWS Infinidash?

Mihaly Balassy — Mon, 12 Jul 2021 21:25:08 +0000

As of today, AWS offers over 200 products and services with its own, unique name and functionality. Getting familiar with them is not an easy task and most AWS professionals only keep up to date with them in their respective fields. For example, if you are managing containers there are currently 17 ways to run them on AWS. This means 17 different services with their own and different pricing models.

On June 30, 2021, Joe Nash raised the question on Twitter about what happens if a small and dedicated group of developers start tweeting about a made-up AWS product. Would it appear in job specifications within a week? He suggested the word Infinidash but was open to other suggestions. He made it clear that “the intended joke here was that AWS product brands are completely impenetrable and indistinguishable from eachother (sic), let alone reality, and not “lol recruiters””.

// Detect dark theme var iframe = document.getElementById('tweet-1410178986978775040-952'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1410178986978775040&theme=dark" }

The name, Infinidash was so apt that it rapidly became a hit on Twitter and soon other people started using it. People started making videos describing the service that may sound real for the general public but clearly sounds fake for professionals.

Hand-on AWS even updated the original AWS certification diagram, highlighting Infinidash as the highest level of professional certification available for AWS.

// Detect dark theme var iframe = document.getElementById('tweet-1410696636590825473-591'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1410696636590825473&theme=dark" }

Soon AWS employees saw the potential in this hype and started to tweet about AWS Infinidash, including Jeff Barr Chief Evangelist for the Amazon Web Services.

// Detect dark theme var iframe = document.getElementById('tweet-1411063383302934531-165'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1411063383302934531&theme=dark" }

Only two days have passed since Joe’s original tweet and even Werner Vogels CTO of Amazon jumped on board:

// Detect dark theme var iframe = document.getElementById('tweet-1410943935124447237-894'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1410943935124447237&theme=dark" }

As of the writing of this article, the Infinidash movement is only at its beginning and eventually will expand beyond Twitter. While I don’t completely agree with Joe’s take on AWS services I clearly find the movement interesting. I believe that AWS also saw an opportunity in this and we will be hearing more about AWS Infinidash in the near future. I am curious to see what comes out of this and what AWS does with such a unique and apt name.

Sources

AWS Infinidash logo by David Cuthbert
Originally published at Road to AWS

VSCode and Docker container management

Mihaly Balassy — Fri, 18 Jun 2021 09:24:12 +0000

Using containers for development is not a new thing. Almost everybody uses it because of its ease of handling software dependencies. But the time will come when you will have so many containers that it's getting harder and harder to manage them. VSCode does have a great Docker plugin where you can see your containers, images, registries, networks, and volumes but its functionality is limited. The same applies to Docker Desktop. It's easy to stop or delete a container but what about such a simple thing as renaming it. You can of course do it in the command line but some functions, such as deleting takes multiple lines of code. That's why I started searching for another solution. And I found it! It's called Portainer. 👋

About Portainer

Portainer is a universal container management tool. It works with Kubernetes, Docker, Docker Swarm, and Azure ACI. And it's open-source. 👍
Portainer handles the easy tasks as easy as the more complex ones. While this article is mainly focused on Docker, Portainer can handle much more advanced tasks like Kubernetes clusters.

Installation

Getting Portainer up and running is as easy as starting a new container. Simply create a named volume for your data and run the container.
docker volume create portainer_data

Linux:
docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce
Windows:
docker run -d -p 8000:8000 -p 9000:9000 --name portainer --restart=always -v \\.\pipe\docker_engine:\\.pipe\docker_engine -v portainer_data:/data portainer/portainer-ce

Once it's up and running you can access the web interface at: http://localhost:9000/

Setup the admin user and connect to Docker.

And you're done! It's that simple. 🎉

Start exploring

Start exploring Portainer. The interface is simple and easy to use. Check your volume locations or your network IPs without using additional Docker containers.

Have fun using Portainer! 🐳