A significant selling point for AWS is the ability to go global in minutes. To better understand what that means, this article is going to break down Amazon’s existing global infrastructure for AWS. To start, let’s look at the world; on any globe, we group countries into continents, and that is where the AWS footprint starts: Regions. Each Region is a physical location in the world comprised multiple Availability Zones.
IAM Access Keys - Does the user really require them? I have very strong feelings when it comes to IAM Access Keys which I can sum up rather quickly - never - ever - provide Access Keys to your users - end of story.
Let me explain why I take this stance - in my experience 99% of the time the user doesn’t actually require them. Sure you have power users within the organization who want to interact with AWS via the CLI or maybe a script or two (more on that later), but in my experience the vast majority of AWS users interact with the platform via the AWS Management Console and these users do not need keys.
In a recent blog article, I talked about Going Serverless in 2018, so I figured I follow that article with a high-level overview of Lambda.
When I mention this strategy during a training session or maybe during a customer visit I often get this following question: “What the heck is a Lambda function?!”
I understand why I get this question so often. In the majority of cases when an organization decides to start using AWS for their computing needs they begin by ‘Lifting and Shifting’ a workload to the Amazon platform - while this approach is an entirely valid strategy it doesn’t mean your work is finished.
What is a Virtual Private Cloud (VPC) Whenever I describe AWS services to organizations just starting on their AWS journey, I like to take an approach I use when learning new things myself: relate new concepts to material of which I’m already intimately knowledgeable.
One of the core components almost every AWS service relies on is the Virtual Private Cloud (VPC). I like to visualize a VPC as a network switch inside a large office building; every piece of your network infrastructure must connect to the switch to communicate with one another.
I know it’s the season to set resolutions for the year, but I’m suggesting we do something a bit different this go around. I’m not telling you to forget about your health-related goals - let’s chat in March - what I’m suggesting is adopting a Serverless first approach in 2018.
Exactly what do I mean when I say Serverless first? It’s pretty simple really - we avoid adding additional Operating Systems at all costs!
Increased flexibility - sometimes referred to as ‘elasticity’ - is one of the major reasons organizations decide to leverage the AWS Platform. Elasticity is the flexibility to use only the resources you require, with the ability to scale out and in as needed, where needed. But what happens when a workload grows beyond its provisioned resources? Sometimes an application will grow to need more RAM or processing power, and simply adding more nodes isn’t a viable solution.
There are quite a few decisions you need to make when you’re first getting started on the Amazon Web Services (AWS) platform. One of those decisions that are often overlooked in the thrill of getting started is AWS Account Strategy.
There are two options when it comes to deciding on an AWS Account Strategy: - A single AWS account - Multiple AWS accounts
In this article, I’ll outline both options and why I almost exclusively use a Multi-Account strategy over the single AWS account option.
Often, I find myself looking for general information about the AWS services and resources deployed within my AWS account. For example, I regularly want to know if there are any public S3 buckets in my account, or how many EBS volumes have been provisioned. I know I can get this information in some different ways. I could run a AWS CLI command on my laptop, I could create a custom script, or I could just log into the AWS Management Console.
Amazon EC2 System Manager (SSM) is an agent-based solution that allows you to remotely manage and collect inventory data from EC2 instances as well as on-premise Windows and Linux systems.
Outside of managing long-running EC2 instances, you can also use SSM to manage your Amazon Machine Images (AMI). Think of an AMI as a gold-image, it’s a pre-built server image that you can use as part of an auto-scaling solution, reference in a CloudFormation template or when manually deploying an instance via the CLI or through the Management console.
How often do you take EBS snapshots? EBS volumes are automatically replicated across multiple servers in the Availability Zone (AZ) where they were deployed, but for data durability you also need timely snapshots of your EBS volumes.
While it’s possible to manually create snapshots of your EBS volumes, a better, more reliable solution is to leverage AWS Lambda to automate the process.
AWS Lambda is available in a number of different languages, supports scheduling (think cron) and can also be invoked automatically from AWS events.