With OpsWorks, AWS enables us to deploy full application stacks in the Cloud while retaining control over the details of the deployment. There are no constraints on what we can tell our EC2 instances to do, provided that we can either reuse, extend or replace AWS’s cookbooks.
The OpsWorks premise is quite simple: take empty EC2 instances, write down some instructions for them to follow in order to have your application up and running. Do you need an HTTP server? Teach your instance to install and configure it. Maybe what you need is a MySQL one? Teach it to become a database server.
Those instructions are Chef recipes and writing them is the tricky part. Luckily, the people at AWS have gone through the hassle of writing common recipes that will help you get started. But, before we get to that, let’s take a look at the structural foundations of OpsWorks: Stacks, Layers, Instances and Apps.
IAM Roles are great to manage access to Resources across the different AWS’s Services while avoiding credential sharing and potential security issues. Let’s see how to leverage AWS Identity and Access Management to solve common problems.
IAM Roles in a nutshell
Basically, IAM is a web service that enables AWS’s customers to manage users and their permissions within the Amazon cloud. Using IAM we can define who can access which resource in EC2, RDS, S3 and all the other AWS services. In addition, IAM lets us define a set of temporary permissions that are not attached or do not belong to users or groups. These permissions are called Roles and can be assumed by applications or AWS services to enable programmatic access to defined resources.
Roles are defined by at least two policies: The first one specifies who can assume the role (trusted entity) and the other one defines the actions allowed over the resource involved. » Read more: Practical AWS: Resource management using IAM Roles
At the upcoming Mobile World Congress that will take place in Barcelona from the 24th to the 27th this February, the Amazon Web Services Mobile mobile team will be having job interviews with the idea of hiring developers for their offices in Seattle.
They are looking for different kinds of profiles to enroll the AWS Mobile team which will develop the services that support the developer ecosystem than builds mobile applications for iOS, Android, Kindle and the mobile web.
Software Development Engineers
Business Development Managers
Technical Program Managers
Software Development Managers/Directors
Those interested in applying for a job will need to meet the following minimum requirements:
- Bachelor’s Degree in Computer Science or related field
- 6+ years professional experience in software development
- Computer Science fundamentals in object-oriented design, data structures, and complexity analysis
- Proficiency in at least one object-oriented programming language such as Java or C++
SES is the AWS’s service that allows us to send transactional email and it’s the recommended method to send email from EC2 instances. Until recently, the service was only present in the North Virgina region, us-east-1, but that has changed now thanks to the creation of two new endpoints located in eu-west-1 and us-west-2. In this post we are commenting on the details that need to be kept in mind should we plan on migrating to one of the new regions. As a bonus, we are explaining how to generate SES SMTP credentials for any IAM user.
With the introduction of the new zones, we can now choose between the old one in N. Virgina, a new one on Oregon and the one that we care the most about: Ireland.
With CloudWatch we can track and monitor a lot of metrics across many AWS’s products and set alarms when certain conditions are met. When these alarms are triggered, they can notify us or automate actions such as shrinking or increasing an AutoScaling Group capacity. CloudWatch knows a lot about our EC2 instances’ at the hardware level but it lacks the software’s point of view. In this post we will explain how to use CloudWatch to monitor important resources it can’t monitor by default.
How standard monitoring works in EC2
When it comes to monitoring EC2 instances, we have to keep in mind that an instance in the cloud is not an actual single computer, but a virtual machine running alongside some siblings on a bigger host, which runs the virtualization solution, or hypervisor. Specifically, AWS uses a customized version of Xen Hypervisor.
CloudWatch relies on the information provided by this hypervisor, which can only see the most hardware-sided part of the instance’s status, including CPU usage (but not load), total memory size (but not memory usage), number of I/O operations on the hard disks (but not it’s partition layout and space usage) and network traffic (but not the processes generating it).
While this can be seen as a shortcoming on the hypervisor’s part, it’s actually very convenient in terms of security and performance, otherwise the hypervisor would be an all-seeing eye, with more powers than the root user itself.