Aws

Sometimes you need to ensure that things are always a certain way when you deploy AWS EC2 instances. This could be things like making sure your servers are always joined to a domain when being deployed, or making sure you run an Ansible playbook every hour. The point of the AWS EC2 SSM State Manager service is to define a consistent state for your EC2 instances. This post will use a fictional use case where I have a an EC2 instance or instances that are checking every thirty minutes to see if they should use a new image for their Apache website. The instance will check against the EC2 Simple Systems Manager Parameter Store, which we’ve discussed in a previous post, and will download the image from the S3 location retrieved from that parameter. ...

Amazon Web Services uses Systems Manager Documents to define actions that should be taken on your instances. This could be a wide variety of actions including updating the operating system, copying files such as logs to another destination or re-configuring your applications. These documents are written in Javascript Object Notation (JSON) and are stored within AWS for use with theother Simple Systems Manager (SSM) services such as the Automation Service or Run command. ...

Generally speaking, when you deploy infrastructure through code, or run deployment scripts you’ll need to have a certain amount of configuration data. Much of your code will have install routines but what about the configuration information that is specific to your environment? Things such as license keys, service accounts, passwords, or connection strings are commonly needed when connecting multiple services together. So how do you code that exactly? Do you pass the strings in at runtime as a parameter and then hope to remember those each time you execute code? Do you bake those strings into the code and then realize that you’ve got sensitive information stored in your deployment scripts? ...

Deploying security patches to servers is almost as much fun as managing backup jobs. But everyone has to do it, including companies that have moved their infrastructure to AWS. As we’ve learned with previous posts, Amazon EC2 Systems Manager allows us to use some native AWS tools for management of our EC2 instances, and patch management is no exception. EC2 Systems Manager allows you to do patch compliance where you can set a baseline and then based on a defined maintenance window a scheduled scan and deployment can be initiated on those EC2 instances. This assumes that you’ve already installed the SSM Agent and setup the basic IAM permissions for the instances to communicate with the Systems Manager service. The details can be found in the previous post. ...

In a previous post we covered the different capabilities and basic setup of EC2 Systems Manager, including the IAM roles that needed to be created and the installation of the SSM Agent. In this post we’ll focus on running some commands through the EC2 Systems Manager Console. We’ve already got an Amazon Linux instance deployed within our VPC. I’ve placed this instance in a public facing subnet and it is a member of a security group that allows HTTP traffic over port 80. ...

We love Amazon EC2 instances because of how easy they are to deploy and we have a huge catalog of templates (AMIs) to choose from which really speeds up our provisioning. But once those instances are up and running it would be really nice to have some methods of managing those instances. Luckily, Amazon has developed several capabilities to help manage Amazon EC2 instances after they’ve been deployed. These capabilities are used to execute scripts, manage patches and kick off automation routines within an EC2 instance, directly from the AWS console. ...

AWS is taking the virtualization world by storm. Workloads that used to get spun up on vSphere are now being deployed in AWS in many cases. But what if you’ve got workloads in vSphere that need to be moved? Sure, it probably makes sense to build new servers in AWS and decommission the old ones but sometimes it’s OK to lift and shift. Amazon has a service that can help with this process called the AWS Server Migration Service. ...

Amazon’s S3 is a cost effective way to store file but many organizations are used to mapping NFS shares to machines for file storage purposes. Amazon Storage Gateways are a good way to cache or store files on an NFS mount and then back them up to an S3 bucket. This post goes through the setup of an AWS Storage Gateway in an EC2 instance for caching files and storing them in an S3 bucket. This same solution (and a similar but different process) can be used to mount block devices through iSCSI or setup a Tape Gateway for backup products. ...

Packer is a free tool from Hashicorp that allows you to build new images. Keeping base vSphere templates up to date is not too difficult of a task for many, but as we add things like AWS accounts and regions, it’s pretty easy to have sprawl to deal with. We’d like to make sure that an image in our vSphere datacenter looks the same as an image in our public clouds. ...

Many cloud initiatives require having a portal for users to choose which workloads can be deployed. Think of this as a supermarket full of servers, networks, databases, or all of the above. There are product offerings from VMware, Cisco, RightScale and Redhat, used for these deployment methodologies. If you’re an AWS customer though, you’ve got your own catalog available from the native AWS tools called the “Service Catalog” service. This service enables you to deploy and publish CloudFormation templates for your users so that they don’t have to know how RDS, or EC2 instances work. They can select from the catalog and deploy anything you can build in an Amazon CFT. Think of the possibilities. ...