Ever since mobile phone devices became much more than just phones to make calls, they have become an increasing problem as it pertains to self-productivity. In fact, some of these applications are designed to take advantage of our increasingly short attention spans and keep us hooked (i.e: TikTok, Youtube Shorts, etc).

I came across a built-in feature with Apple iPhone that has me so excited I just had to share.

Do you find yourself distracted at times during your day? Do you happen to have an addiction to YouTube or other video sites? Do you happen to check up on Facebook or other social media notifications a bit much?

If you have an iPhone, this solution is for you!

Screen Time (how to setup)

The “Screen Time” feature is available in your iPhone settings.

Once you access the “Screen Time” settings page, you can follow these steps to being:

You’ll be greeted with a page that hosts some metrics that reveal your general screen time activities. At the bottom, you’ll also observe some additional options you can use to restrict Screen Time based on certain conditions.

Downtime

This is my favorite setting — as it allows you to control availability to your applications on a scheduled basis:

As shown above, we can enable “scheduled” to increase our productivty during certain periods of the day.

As an example, a typical workday consists of a time range across most of our daylight hours on weekdays.

• You can specifically target individual days to have certain schedules
• You can disable the speed bump to access your App’s on targeted days

Always Allowed

You can use this setting to specify applications that you don’t want blocked. Think critical needs such as communications, MFA Apps, etc.

Closing Thoughts

This is just an example of how you could use this feature to help increase your productivity during the day. Some considerations:

• The Apps are only “speed bumped” meaning it prompts you that your “limit” has been reached for App access but allows you to override if you like.
• There are other Apps on the App Store that provide this feature, but I don’t think they are any better than this built-in feature.

You should try and respect the limits you set as much as possible.

This article will briefly discuss how to update an item in a DynamoDB table on AWS.

Sample data (dictionary)

Here is our sample data based off of an old EBS public snapshot (I have censored the relevant identifiable information):

import boto3

snapshot_details_pull = {
    'Description': 'Copied for DestinationAmi ami-00000000000000000 from SourceAmi ami-11111111111111111 for SourceSnapshot snap-aabbccddeeffgghhi. Task created on X.',
    'Encrypted': False, 
    'OwnerId': '999999999999', 
    'Progress': '100%', 
    'SnapshotId': 'snap-aabbccddeeffgghhi', 
    'StartTime': datetime.datetime(2017, 1, 01, 00, 00, tzinfo=tzutc()),
    'State': 'completed', 
    'VolumeId': 'vol-ffffffff', 
    'VolumeSize': 10, 
    'StorageTier': 'standard' 
}

# Setup the DynamoDB connection
session = boto3.session.Session() #Use the profile_name parameter if needed
resource = session.resource('dynamodb') #Use resource - not the client here
table = resource.Table('<insert your table name here') #A table must already exist

Put an item

In order to “put” an item into a DynamoDB table, there are a few per-requisites we’ll need to consider as it pertains to the data types of each key/value pair.

If we attempt to “put” an item now, we will encounter the following error:

TypeError: Unsupported type “<class ‘datetime.datetime’>” for value…

We will need to update the value of the “StartTime” key to an “iso format” using the following snippet in your Python interpreter for a quick conversion:

snapshot_details_pull['StartTime'] = snapshot_details_pull['StartTime'].isoformat()

Next, this dictionary does not have the “partition key” resident in its key/value pairs. In this case, consider the “parition key” of this DynamoDB to be a key pair value of “id” followed by an a string value that should be unique.

In DynamoDB terminology, there are a few considerations to take in as far as the value type identifiers are concerned.

S = string
N= integer
B=bytes
SS=list
NS=number set (list)
BS=binary set (list)
M=map (dictionary)
L= “attribute list” (dictionary of a list of dictionaries)
NULL=boolean (true/false literal)
BOOL=boolean (true/false literal)

Let’s add the “id” partition key to the dictionary:

snapshot_details_pull['id'] = 2 #Integer value

As a test, we attempt to add the item into the database table as an integer value and receive the following “ValidationException” error:

Type mismatch for key id expected: S actual: N

Add the value as a string instead to counter this error:

snapshot_details_pull['id'] = '2' #String value

Finally, we’ll commit our dictionary to the DynamoDB table:

response = table.put_item(Item=snapshot_details_pull)
response['ResponseMetadata']['HTTPStatusCode']
200

We can optionally check the “ResponseMetadata” field values to verify that our submission was successful (HTTP response code of 200 indicates a success).

Additionally, we can perform a “get_item” lookup on the table (may vary depending on your table’s “KeySchema”.

table.get_item(Key={'OwnerId':'99999999999','snapshot_id':'snap-aabbccddeeffgghhi'})

Update an item

Let’s also quickly explore updating this same item.

tab.eupdate_item(
    Key={'OwnerId':'99999999999','snapshot_id':'snap-aabbccddeeffgghhi'},
    UpdateExpression='SET VolumeSize = :val1',
    ExpressionAttributeValues={
        ':val1': 20
    }

In this case, we are quickly updating the VolumeSize of this specific snapshot item from 10 to 20.

References

https://boto3.amazonaws.com/v1/documentation/api/latest/guide/dynamodb.html#:~:text=Once%20you%20have%20a%20DynamoDB.Table%20resource%20you%20can,25%20%2C%20%27account_type%27%20%3A%20%27standard_user%27%20%2C%20%7D%20%29

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.html#Query.FilterExpression

Create a repository

Create a new repository by clicking on the “New” button under the “repositories” section in the drop-down under your profile username at the top right of the screen.

Setup SSH access

Proceed to setup SSH access by performing the following steps in order:

1. Generate a new local SSH key on your system.

• Use the “ssh-keygen” command to generate a keypair. In this example, we will be using the commonly used combination of RSA and a number of bits size of 4096.
• Save the file under your users /home directory and within the hidden “.ssh” folder within the users home directory. In this case, we’re naming the new keypair “github_rsa_key” as a demonstration.

2. Add the public key that was generated to your GitHub profile.

• First, you will need to get the public key output by using the “cat” command against your new public key file.

• Next, navigate to your “Settings” page of your account and click on “SSH and GPG keys”.

• Click “New SSH key” and paste in the contents of your public key that you retrieved from the “cat” command above.

3. After the key is successfully added from the last step, return to the terminal and test accessibility using the following command:

• ssh -T git@github.com -i ~/.ssh/github_rsa_key

• You can additionally verify that the appropriate “github.com” is being added by performing a “whois” lookup on the IP address noted from the SSH output above. In this case, 140.82.112.3.
• The net range that belongs to GitHub,Inc at this point in time is 140.82.112.0/20 for which this IP address falls within.

Push code setup

When you’re ready to push code up to your own repository, you may encounter an unexpected HTTP 403 error response. In this case, you just need some slight updates to your git config file located in your locally cloned directory’s hidden “.git” folder.

• Change the remote origin.url to be the SSH equivalent which can be acquired straight from the UI during the process of attempting to “git clone” the repository.

• Next — update your local SSH config file to account for the connections to the github.com domain by referencing the private key file you created earlier. (~/.ssh/config)

Finally, make your changes, commit and push and you should see a success!

“What are you doing!?” my colleague asked me over the phone as I was in a sweaty panic.

“I accidentally disconnected the wrong fiber cable for a brief moment… I plugged it back in quickly once I realized I had disconnected the wrong port!” I said nervously. The loud fans of servers surrounding me probably drowned out a part of my answer I thought as I anxiously awaited his reply.

“It’s okay man… that’s why we have redundant links… just be more careful next time!” my colleague replied in a cheerful manner with a follow up chuckle.

I let out a huge sigh of relief and thanked him.

We hung up the phone and I cleaned up, this time being more careful to disconnect the correct cable.

It’s these types of situations that may arise during your career as an IT professional. Whether it is disconnecting the wrong cable like in my case, or whether it is running a small test that ends up causing a brief production outage, it is critical that you have the correct mindset to overcome.

Here are a few brief tips that can help you recover from an honest mistake.

1. Stay calm

It is very easy to quickly go into panic mode the moment you realize you’ve made a mistake. Realizing that this is a normal response to such an incident is perfectly normal! But you need to also recognize that while your stomach has that tingly something is wrong feeling, you need to be careful not to let it overtake you. Take a long, deep breath and tell yourself that things can be fixed and it will be okay. Trust me, the long deep breath really helps calm you down a little bit.

2. Communicate the issue

If you understand what you have done to cause the problem, you may be able to quickly fix the issue up front. In my case, I responded somewhat in a panic and reconnected the cable right away.

I don’t recommend this approach because you won’t be able to always fix the problem right away in such an incident. Instead, contact your colleages and let them know what happened. This is important because you may have just triggered a ton of different alerts that have them on a hunt to track down the sudden outage. Meanwhile, you’re sitting there in a sweaty panic wondering what you’re going to do and probably quite embarrassed and ashamed as well.

More often than not, your team is there to help you out! They will be glad and probably relieved to at least understand what caused the sudden alarm and they can begin assisting you in fixing the issue as soon as possible! You should never try and be a one man hero.

3. Be honest

This is a really important one. You should NEVER lie to your team and you should NEVER try and hide what you’ve done. You may get away with it, but you are setting yourself up for a dangerous precedent. Most systems are logged and in most cases, your actions can be tracked down in due time through correlation efforts. It is better to confess up front and set your team down the road to fixing the issue rather than hiding it. In my opinion, lying and hiding the mistakes you’ve made is practically a terminating offense. You can potentially never be trusted again if you’re found out. Do NOT be that person!

4. Be quick

The moment you realize you’ve made a mistake, be quick about following through with fixing it! Do not sit around and think about what you should have or could have done to cause it right then. Time is of the essence here and it is critical that you do the right thing and stay calm, communicate, and confess to the mistake. Most businesses depend on production to remain online and every second is potential to cause financial loss to the companies bottom line. If the outage is long enough, the results could be catastrophic to the business.

5. Learn from your mistake

After the issue has been resolved, take a moment to reassess what the timeline of events were that caused this in the first place. You will quickly realize and understand what you need to do in the future to avoid it! Some tips to further learn and understand is to document the incident, generally in the form of a post-mortem. PagerDuty provides a very great explanation of what a post-mortem is and how you may go about conducting one.

Learn, react, and adapt. You will carry forth wisdom and experience that you can then confidently carry on your shoulders with the knowledge and understanding of how to avoid it in the future. And yes, you should avoid it in the future! Making the same mistakes over and over is certainly a doomed path. Be very sure to learn from your mistake!

Summary

We all make mistakes, it is practically human nature! On a long enough timeline, we are all bound to slip up every once in awhile. That is normal! It is important to accept this and be forthcoming with your mistake if you’ve caused an outage rather than sit on it and try and hide it or fix it on your own. You may be wasting your colleagues time as they desperately respond to alarms while you already possess the knowledge to fix the issue.

Stay focused, be honest, and work with your team to fix the outage in a timely manner. The business is depending on you to be the caretakers of their systems so treat them with respect and do not try and be slick by cleaning up and sweeping things under the rug. Things are bound to come back at you even harder than if you would have just come out and confessed straight away.

Overview

In this post, we will review how to setup the AWS EKS service on your AWS account. This will be created in a single AWS region but you can reuse the material we go over here on a per region basis. We will be working with the CloudFormation service which will help us build and maintain the cluster itself as well as the networking infrastructure required to logically contain our resources. Finally, we will build the control plane within the same template and run it all as one single stack.

The EKS IAM Role

First and foremost, we are required to create a new IAM role that will allow the EKS service to assume role to your AWS account to help manage the associated resources.

Resources:
  EKSIAMRole:
    Type: 'AWS::IAM::Role'
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - eks.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      RoleName: !Ref EKSIAMRoleName
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
        - arn:aws:iam::aws:policy/AmazonEKSServicePolicy

Briefly going over the above template extract, we are creating a new IAM “role” resource and allowing the EKS service to use the role. Additionally we have attached two (existing) managed IAM policies that are required for the EKS service to properly manage the upcoming cluster. A managed policy is a built-in policy already available within AWS.

The EKS network infrastructure

Next, we are required to build the EKS network infrastructure that the EKS cluster will reside in. This should be created next in-line and a fully configured template for this is already available on the official AWS documentation website. We will link it here for good measure.

https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2019-10-08/amazon-eks-vpc-private-subnets.yaml

The three things you are normally required to make a note of as a result of the network build are the following:

• VPC ID
• SecurityGroup
• Subnet IDs

These values will be required when it comes time to generate the actual EKS cluster.

In our case though, we will be skipping even the need to collect those details as we will just be referencing all of this in the CloudFormation template. Just note that the template is built in such a way that the order of operations is to create the IAM role and the network infrastructure before finally creating the EKS cluster itself.

EKS Cluster: Control Plane

Creating the control plane piece of this is probably the easiest part. Why? Because it is just the culmination of the previous resources as we noted in the last section. Since we’re using a CloudFormation template though, we are going to let the template do all of the work for us in specifying the associated subnets, security group, and IAM role we want to use for the cluster creation.It’s annoying to have to write those values down somewhere for later as the official documentation suggests.

We will simply append the following to our template:

EKSCluster:
  Type: AWS::EKS::Cluster
  Properties:
    Name: !Ref EKSClusterName
    RoleArn:
      "Fn::GetAtt": ["EKSIAMRole", "Arn"]
    ResourcesVpcConfig:
      SecurityGroupIds:
      - !Ref ControlPlaneSecurityGroup
      SubnetIds:
      - !Ref PublicSubnet01
      - !Ref PublicSubnet02
      - !Ref PrivateSubnet01
      - !Ref PrivateSubnet02
  DependsOn: [EKSIAMRole, PublicSubnet01, PublicSubnet02, PrivateSubnet01, PrivateSubnet02, ControlPlaneSecurityGroup]

At this point, we now have a full and complete Cloudformation template to build the IAM Role, the network infrastructure, and the master node/control plane for our EKS cluster. Next up is the worker nodes.

Control Plane template (final):

Here is our final CloudFormation template to build the IAM Role, the network infrastructure, and the control plane for our new EKS cluster. Remember this is a combination of our IAM Role template, the EKS Cluster template, and the AWS provided network template.

---
AWSTemplateFormatVersion: '2010-09-09'

Parameters:

  EKSIAMRoleName:
    Type: String
    Description: The name of the IAM role for the EKS service to assume.

  EKSClusterName:
    Type: String
    Description: The desired name of your AWS EKS Cluster.
    
  VpcBlock:
    Type: String
    Default: 192.168.0.0/16
    Description: The CIDR range for the VPC. This should be a valid private (RFC 1918) CIDR range.

  PublicSubnet01Block:
    Type: String
    Default: 192.168.0.0/18
    Description: CidrBlock for public subnet 01 within the VPC

  PublicSubnet02Block:
    Type: String
    Default: 192.168.64.0/18
    Description: CidrBlock for public subnet 02 within the VPC

  PrivateSubnet01Block:
    Type: String
    Default: 192.168.128.0/18
    Description: CidrBlock for private subnet 01 within the VPC

  PrivateSubnet02Block:
    Type: String
    Default: 192.168.192.0/18
    Description: CidrBlock for private subnet 02 within the VPC

Metadata:
  AWS::CloudFormation::Interface:
  ParameterGroups:
    -
      Label:
        default: "Worker Network Configuration"
      Parameters:
        - VpcBlock
        - PublicSubnet01Block
        - PublicSubnet02Block
        - PrivateSubnet01Block
        - PrivateSubnet02Block

Resources:
  EKSIAMRole:
    Type: 'AWS::IAM::Role'
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
          Principal:
            Service:
              - eks.amazonaws.com
          Action:
            - 'sts:AssumeRole'
      RoleName: !Ref EKSIAMRoleName
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
        - arn:aws:iam::aws:policy/AmazonEKSServicePolicy

  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock:  !Ref VpcBlock
      EnableDnsSupport: true
      EnableDnsHostnames: true
    Tags:
    - Key: Name
      Value: !Sub '${AWS::StackName}-VPC'

  InternetGateway:
    Type: "AWS::EC2::InternetGateway"
    VPCGatewayAttachment:
    Type: "AWS::EC2::VPCGatewayAttachment"
    Properties:
      InternetGatewayId: !Ref InternetGateway
      VpcId: !Ref VPC

  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
    Tags:
    - Key: Name
      Value: Public Subnets
    - Key: Network
      Value: Public

  PrivateRouteTable01:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
    Tags:
    - Key: Name
      Value: Private Subnet AZ1
    - Key: Network
      Value: Private01

  PrivateRouteTable02:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
    Tags:
    - Key: Name
      Value: Private Subnet AZ2
    - Key: Network
      Value: Private02

  PublicRoute:
    DependsOn: VPCGatewayAttachment
    Type: AWS::EC2::Route
      Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  PrivateRoute01:
    DependsOn:
    - VPCGatewayAttachment
    - NatGateway01
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref PrivateRouteTable01
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId: !Ref NatGateway01

  PrivateRoute02:
    DependsOn:
    - VPCGatewayAttachment
    - NatGateway02
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref PrivateRouteTable02
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId: !Ref NatGateway02

  NatGateway01:
    DependsOn:
    - NatGatewayEIP1
    - PublicSubnet01
    - VPCGatewayAttachment
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt 'NatGatewayEIP1.AllocationId'
      SubnetId: !Ref PublicSubnet01
    Tags:
    - Key: Name
      Value: !Sub '${AWS::StackName}-NatGatewayAZ1'

  NatGateway02:
    DependsOn:
    - NatGatewayEIP2
    - PublicSubnet02
    - VPCGatewayAttachment
    Type: AWS::EC2::NatGateway
    Properties:
    AllocationId: !GetAtt 'NatGatewayEIP2.AllocationId'
    SubnetId: !Ref PublicSubnet02
    Tags:
    - Key: Name
      Value: !Sub '${AWS::StackName}-NatGatewayAZ2'

  NatGatewayEIP1:
    DependsOn:
    - VPCGatewayAttachment
    Type: 'AWS::EC2::EIP'
    Properties:
      Domain: vpc

  NatGatewayEIP2:
    DependsOn:
    - VPCGatewayAttachment
    Type: 'AWS::EC2::EIP'
    Properties:
      Domain: vpc

  PublicSubnet01:
    Type: AWS::EC2::Subnet
    Metadata:
      Comment: Subnet 01
    Properties:
      AvailabilityZone:
        Fn::Select:
        - '0'
        - Fn::GetAZs:
          Ref: AWS::Region
        CidrBlock:
          Ref: PublicSubnet01Block
        VpcId:
          Ref: VPC
    Tags:
    - Key: Name
      Value: !Sub "${AWS::StackName}-PublicSubnet01"

  PublicSubnet02:
    Type: AWS::EC2::Subnet
    Metadata:
      Comment: Subnet 02
    Properties:
      AvailabilityZone:
        Fn::Select:
        - '1'
        - Fn::GetAZs:
          Ref: AWS::Region
        CidrBlock:
          Ref: PublicSubnet02Block
        VpcId:
          Ref: VPC
    Tags:
    - Key: Name
      Value: !Sub "${AWS::StackName}-PublicSubnet02"

  PrivateSubnet01:
    Type: AWS::EC2::Subnet
    Metadata:
      Comment: Subnet 03
    Properties:
      AvailabilityZone:
        Fn::Select:
        - '0'
        - Fn::GetAZs:
          Ref: AWS::Region
        CidrBlock:
          Ref: PrivateSubnet01Block
        VpcId:
          Ref: VPC
    Tags:
    - Key: Name
      Value: !Sub "${AWS::StackName}-PrivateSubnet01"
    - Key: "kubernetes.io/role/internal-elb"
      Value: 1

  PrivateSubnet02:
    Type: AWS::EC2::Subnet
    Metadata:
      Comment: Private Subnet 02
    Properties:
      AvailabilityZone:
        Fn::Select:
        - '1'
        - Fn::GetAZs:
          Ref: AWS::Region
        CidrBlock:
          Ref: PrivateSubnet02Block
        VpcId:
          Ref: VPC
    Tags:
    - Key: Name
      Value: !Sub "${AWS::StackName}-PrivateSubnet02"
    - Key: "kubernetes.io/role/internal-elb"
      Value: 1

  PublicSubnet01RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet01
      RouteTableId: !Ref PublicRouteTable

  PublicSubnet02RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet02
      RouteTableId: !Ref PublicRouteTable

  PrivateSubnet01RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnet01
      RouteTableId: !Ref PrivateRouteTable01

  PrivateSubnet02RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnet02
      RouteTableId: !Ref PrivateRouteTable02

  ControlPlaneSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Cluster communication with worker nodes
      VpcId: !Ref VPC

  EKSCluster:
    Type: AWS::EKS::Cluster
    Properties:
      Name: !Ref EKSClusterName
      RoleArn:
        "Fn::GetAtt": ["EKSIAMRole", "Arn"]
        ResourcesVpcConfig:
          SecurityGroupIds:
          - !Ref ControlPlaneSecurityGroup
          SubnetIds:
          - !Ref PublicSubnet01
          - !Ref PublicSubnet02
          - !Ref PrivateSubnet01
          - !Ref PrivateSubnet02
    DependsOn: [EKSIAMRole, PublicSubnet01, PublicSubnet02, PrivateSubnet01, PrivateSubnet02, ControlPlaneSecurityGroup]

Outputs:
  SubnetIds:
    Description: Subnets IDs in the VPC
    Value: !Join [ ",", [ !Ref PublicSubnet01, !Ref PublicSubnet02, !Ref PrivateSubnet01, !Ref PrivateSubnet02 ] ]

  SecurityGroups:
    Description: Security group for the cluster control plane communication with worker nodes
    Value: !Join [ ",", [ !Ref ControlPlaneSecurityGroup ] ]

  VpcId:
    Description: The VPC Id
    Value: !Ref VPC

EKS Cluster: Worker nodes

Before we have a fully working cluster, we obviously need to create the actual worker nodes! This is required to be a separate template because the creation of these nodes has the pre-requisite of the cluster actually existing first! While technically we could leverage the “DependsOn” attribute that we’ve been using, you must remember that you may also wish to update the stack at a later date and you don’t want to mess with the foundations of your cluster as we’ve created above if you can avoid it.

The worker node template that AWS has built is pretty straight forward and I would recommend leveraging it as a separate stack. Here’s the link to that YAML file:

https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2019-10-08/amazon-eks-nodegroup.yaml

We will go over deploying this template as well after we’ve stood up our Control Plane stack.

Deploying your CloudFormation template(s)

A quick reminder on how to deploy your template within your AWS account. The following steps apply:

1. Login to your AWS account and select the appropriate region you will be working out of at the top right.
2. On the services search bar, type “cloudformation” and select the CloudFormation service.
3. Leave the default “template is ready” selected and then click “Upload a template file” to select your YAML file.

4. Fill in the required fields on the next page and leave the defaults for the ones that are populated if desired.

5. Proceed to create the stack and ensure that you specify and agree to the fact that it will create IAM resources on the account.

6. Once the stack has completed, you should see a “CREATE_COMPLETE” status for the newly deployed stack.

7. You can browse to the EKS service to see your newly deployed resources for the control plane.

Now it’s time to deploy that worker stack that we talked about earlier.

One step we need to do with the worker node template is create an EC2 key pair that we will need to specify on the template creation page. This key will allow you to be able to SSH into your worker nodes for troubleshooting purposes. AWS currently does not support creating a key pair with CloudFormation so it has to be done elsewhere. In this case, we will create a key pair through the AWS console. Follow the steps below to do so:

• Browse to the EC2 service
• Select “Key Pairs”

• Select “Create Key Pair” and provide the key pair with a name.

At this point, you can follow the same steps as before but this time you can reference the S3 link in the stack creation page.

Step through the fields in the template, this time you will need to specify a name for the node group as well as select the associated VPC and subnets for the worker group.

Create the stack in the same manner as before and at the end, you will have two CloudFormation stacks. One for the control plane and one of the worker nodes.

Enjoy! Next time we will go over how to authenticate to your new cluster!

References:

https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html

Overview

This page will serve as a brief introduction to AWS GuardDuty. You will find the reference links to the official documentation at the bottom of this page as well as my public Github.

I want to briefly go over some of the basic settings you can configure on your AWS account(s). Specifically, I want to go over how you can manage your accounts GuardDuty configuration with automation and management tools. In this post, we will specifically go over the AWS command line interface as well as AWS CloudFormation.

We will skip the introduction of what AWS GuardDuty is in this particular posting.

Getting Started with the AWS CLI

Pre-requisites:

• Have administrative access to your AWS account
• Have the AWS CLI installed on your local machine. (https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)

One you have the AWS CLI configured on your local machine with the appropriate administrative access, it’s time to dive into the configuration.

Type “aws guardduty help” to see the list of commands available. Note that with AWS commands, each layer has a set of help commands so if you have additional questions about a specific parameter simply add the “help” argument at the end. For example, in this case, we will need to create a detector.

Type the following command:

aws guardduty create-detector --enable

If you wanted to understand the details of the above command, you can simply add help at the end.

Note: You can only have one detector enabled on your account at a time per region.

If you log back into your AWS account console, you will see that GuardDuty has now been enabled. You can generate sample findings with the following command:

aws guardduty create-sample-findings --detector-id <your detector id here>

Note: You will receive your detector-id from our previous “create-detector” command. If you lost that information, you can retrieve the detector-id again via the the command

aws guardduty list-detectors

You may have noticed we just accepted the default settings for the detector when creating it via the above command. We can update the detector to change the publishing frequency to say 15 minutes for example via the following command:

aws guardduty update-detector --finding-publishing-frequency FIFTEEN_MINUTES

The command line provides a useful and quick method of generating a new GuardDuty detector. But that’s really all it provides, you have to manually provision and maintain this configuration overtime. Most organizations are moving towards Infrastructure as code, and you can manage GuardDuty as well through this method. We’re going to go over a useful tool that can provide more organization around what you deploy within AWS in relation to AWS GuardDuty.

Deploy GuardDuty with CloudFormation

AWS provides a service called CloudFormation. This service provides the administrator with the ability to deploy “stacks” of resources all at once or in steps. The most useful thing about deploying with CloudFormation is that everything will be maintained through the stack including updates to the stack as well as deleting the stack. You can delete your entire stack with a few simple clicks. You can also specify which resources you may wish to retain.

In relation to GuardDuty, we can produce a detector similar to what we provided via the command line above with a very quick template. We will be using the YAML format here as it is more constructive and easy to work with and allows for comments to be written inline.

The above is a very basic deployment of the GuardDuty detector. We can validate the enablement of the service through the command line via the command “aws guardduty list-detectors”. This will return a list of detectors (only a single detector is allowed per AWS Region at this point in time). From here, you can leverage the command line to pull back addintional configuration details on the detector via the command

aws guardduty get-detector --detector-id <your detector id here>

Manage the event flow

What good is a GuardDuty detector if you don’t manage your event structure as well?

We’ll make a quick update to our CloudFormation template to setup a process flow to send events to an SNS topic so that we can get notified of any findings our newly created detector detects.

Setup Overview

The following CloudFormation template will create the following setup with the only pre-requsite being an existing SQS Standard Queue.

• Creates an SNS Topic along with an access policy for that topic to allow for events.amazonaws.com to publish to the topic.
• Creates a CloudWatch event rule that contains an event pattern to match events from aws.guardduty.
• Sets up a target for the CloudWatch event rule to point to our previously mentioned SNS topic.
• Finally, it subscribes our existing SQS queue to the topic so that it will receive event messages anytime GuardDuty detections are detected.

You can test this CloudFormation sample template by following these steps:

1. Login to your AWS Account and navigate to the GuardDuty service
2. Click on Settings and then click on Generate Sample Findings

3. Navigate over to your SQS Queue within the SQS service.

4. Monitor the queue for inbound messages within the next few minutes after having clicked on the sample findings generation button.

Final Thoughts

This is a brief configuration you can leverage when setting up your GuardDuty environment. You can subscribe any number of emails or endpoints to your SNS Topic so that your applications or monitoring solutions can be notified of GuardDuty findings.

You may also wish to rope in the detector creation into the above template to wrap it all up as one CloudFormation stack which also works.

There are additional configuration settings we can setup with GuardDuty that we can go over in more detail next time.

Experiment to your hearts content!

References:

• Intelligent Threat Detection - Amazon GuardDuty - AWS
• Provision Infrastructure as Code - AWS CloudFormation - AWS
• dhammond22222/cloudformation_templates