AWS For Admins For Dummies book cover

AWS For Admins For Dummies

By: John Paul Mueller Published: 10-31-2016

Easily get your head in the Cloud with Amazon Web Services

With Amazon Web Services (AWS), you can do everything from backing up your personal hard drive to creating a full-fledged IT department in the Cloud. And while major corporations like Adobe and Netflix have turned to AWS for their Cloud computing needs, it isn't just for private companies. Amazon Web Services For Dummies is the singular resource that shows real people with real businesses how to use on-demand IT resources to help their companies grow.

If you're like most people just getting their feet wet with this service, your first question is likely to be, "How do I get started with AWS?" This book answers that question—and a multitude more—in language you can understand and shows you how to put this Cloud computing service to work for you right away. AWS is immense and, naturally, intimidating, but with the help of this book, you'll peel back its many layers in no time!

  • Provides overviews that explain what tasks the services perform and how they relate to each other
  • Offers specific paths to follow in order to obtain a particular installation result
  • Gets you started without making a huge investment
  • Reduces the risk of failure by ensuring you understand available options as part of the configuration and usage process

Stop wasting time and resources on hardware and software that's quickly outdated. Get started with AWS today!

Articles From AWS For Admins For Dummies

page 1
page 2
page 3
page 4
38 results
38 results
AWS For Admins For Dummies Cheat Sheet

Cheat Sheet / Updated 04-20-2022

Amazon Web Services (AWS) started out small, but has become a vast collection of cloud services that businesses can use to support any activity without having to invest in an IT infrastructure.

View Cheat Sheet
Elastic Beanstalk (EB) Features for AWS

Article / Updated 02-01-2017

EB enables developers to create applications that run anywhere on any device, yet don't suffer from problems of reliability and scalability that can occur when using a company-owned host. A focus of EB for use with AWS (Amazon Web Services) is to easily be able to upload, configure, and manage applications of all sorts. An application isn't useful unless people can access it with ease and make it perform whatever tasks it's designed to perform in the most seamless manner possible. Achieving these goals requires that the hosting platform support various programming methodologies on a variety of platforms so that developers can use the tools most suited to a particular need. When working with AWS, you currently can create web applications (in the easiest-to-access form that's currently available) using these languages (with more to follow): Java .NET PHP Node.js Python Ruby Go Docker The applications run in managed containers for the language you choose. A managed container is one in which the host manages application resources and ensures that the application can't easily crash the system. The container acts as a shield between the application you're working with and every other application that the system hosts. Developers may create the applications, but administrators must manage them. To make administrators as efficient as possible, a host must support a number of platforms. Matching the language (to meet developer needs) with a platform (to meet administrator needs) on a host can prove difficult, but EB is up to the task because it provides support for these web application platforms: Apache Nginx Passenger IIS In looking through the EB documentation, you may initially get the idea that this service is designed to meet developer needs — to simplify application deployment and management in a way that allows a developer more time to code. However, administrators need more time, too. The management features provided by EB address the needs of administrator and developer alike. This chapter focuses almost entirely on the administrator view of EB. The three cornerstones of EB application are the following: Deployment: Getting the application onto the server so that someone can use it Management: Configuring the application as people find problems using it Scaling: Providing a good application experience for everyone by ensuring that the application runs fast, reliably, and without any security issues As part of this whole picture, EB also relies on application health monitoring through Amazon CloudWatch. The Amazon CloudWatch service provides the means for determining when application health issues require the host to make changes in the application environment, such as by using autoscaling to make sure that the application has enough resources to run properly.

View Article
How to Create an EBS Volume for AWS

Article / Updated 02-01-2017

Before you can use an Elastic Block Store (EBS) volume for Amazon Web Services (AWS), you must create it. EBS volumes can take on many different characteristics. The following steps describe how to create a simple volume that you can use with EC2. Sign into AWS using your administrator account. Navigate to the EC2 Console. You see the page shown. Notice the Navigation pane on the left, which contains options for performing various EC2-related tasks. The Resources area of the main pane tells you the statistics for your EC2 setup, which currently includes just the one security group. Choose a EC2 setup region from the Region drop-down list at the top of the page. The example uses the Oregon region. Select Volumes in the Navigation pane. The EC2 Console shows that you don't currently have any volumes defined. Click Create Volume. You see the Create Volume dialog box, shown in the following figure. Notice that you can choose a volume type and size, but not the Input/output Operations Per Second (IOPS) or the throughput, which are available only with certain volume types. The Availability Zone field contains the location of the storage, which must match your EC2 setup. The Snapshot ID field contains the name of an S3 storage location to use for incremental backups of your EBS data. You can also choose to encrypt sensitive data, but doing so places some limits on how you can use EBS. For example, you can't use encryption with all EC2 instance types. Click Create. AWS creates a new volume for you and displays statistics about it, as shown. The new volume lacks any sort of backup. The next step configures a snapshot that AWS uses to perform incremental backups of the EBS data, reducing the risk of lost data. Choose Actions→ Create Snapshot. You see the Create Snapshot dialog box. Notice that AWS fills in the Volume field for you and determines the need for encryption based on the volume settings. Type EBS.Backup in the Name field, type Test Backup in the Description field, and then click Create. You see a dialog box telling you that AWS has started the snapshot. Click Close. The volume is ready to use. When you finish this example, you can delete the volume you created by selecting its entry in the list and choosing Actions →Delete Volume. In a real-world setup, you can attach this volume to any EC2 instance or detach it when it's no longer needed.

View Article
Elastic Block Store (EBS) Volume Types for AWS

Article / Updated 02-01-2017

Just as there isn't one kind of hard drive, there isn't one kind of EBS volume. Amazon Web Services (AWS) currently provides access to both Solid-State Drive (SSD) and Hard Disk Drive (HDD) volumes. SSD provides high-speed access, while HDD provides lower-cost access of a more traditional hard drive. Amazon further subdivides the two technologies into two types each (listed in order of speed): EBS Provisioned IOPS SSD: Provides high-speed data access that you commonly need for data-intensive applications that rely on moderately-sized databases. EBS General Purpose SSD: Creates a medium-high-speed environment for low-latency applications. Amazon suggests this kind of volume for your boot drive. However, whether you actually need this amount of speed for your setup depends on the kinds of applications you plan to run. Throughput Optimized HDD: Defines a high-speed hard drive environment, which can't compete with even a standard SSD. However, this volume type will work with most common applications and Amazon suggests using it for big data or data warehouse applications. This is probably the best option to choose when money is an issue and you don't really need the performance that SSD provides. Cold HDD: Provides the lowest-speed option that Amazon supports. You use this volume type for data you access less often than data you place on the other volume types (think data you use once a week, rather than once every day). This isn't an archive option; it's more like a low-speed option for items you don't need constantly, such as a picture database. As you move toward higher-speed products, you also pay a higher price. For example, at the time of writing, a Cold HDD volume costs only $0.025/GB/month, but an EBS Provisioned SSD volume costs $0.125/GB/month. You can find price and speed comparison details online. The table provided contains some interesting statistics. For example, all the volume types top out at 16TB and support a maximum throughput per instance of 800MB/s.

View Article
How to Include Inline Policies in AWS with EC2

Article / Updated 02-01-2017

In general, you want to avoid using inline policies in AWS (Amazon Web Services) when configuring Elastic Compute Cloud (EC2) because they're hard to manage and you must go to the individual entities, such as groups, to make any required changes. In addition, the inline policies have a tendency to hide, making troubleshooting problems with your setup just that much harder. However, you may encounter situations in which an inline policy offers the only way to set security properly. The following steps help you create inline policies as needed. (This procedure uses an example group named EC2Users, but it works with any entity that supports inline policies.) Select the Groups, Users, or Roles entry in the Navigation pane. Open the entity you want to work with by clicking its entry in the Object Type page. Select the Permissions tab of the entity's Summary page. You see areas for both managed policies and inline polices, as shown. Click Inline Policies. If this is your first inline policy, you see a message saying "There are no inline policies to show. To create one, click here." Click the Click Here button. You see a Set Permissions page containing two options: Policy Generator: Displays a wizard that lets you easily create a policy for use with your entity. Among the methods for creating an inline policy, this is the easiest. Custom Policy: Displays an editor in which you manually type a policy using the appropriate syntax and grammar. This is the more flexible of the two options for creating an inline policy. Select a permission generation option and then click the Select button next to that entry. The example assumes that you want to use the Policy Generator option. You see the Edit Permissions page, shown here. This interface enables you to allow or deny actions against a specific AWS service and, optionally, a specific resource associated with that service. Configure the permission using the various permission entries and then click Add Statement to add the statement to the policy. Click Next Step. You see the Review Policy page. Because you define the policy using a series of individual permissions, you probably don't need to edit the policy. Click Validate Policy. If the changes you made work as intended, you see a This Policy Is Valid success message at the top of the page. Always validate your policy before you create it. Click Apply Policy. You see the policy added to the Inline Policies area of the Permissions tab of the entity's Summary page. In addition, the Inline Policies area now includes a button to create more policies, such as the Create Group Policy entry for groups. To interact with an existing inline policy, use the links in the Actions column of the policy list. Here's an overview of the actions you can perform on an inline policy: Show Policy: Displays the code used to create the policy. Edit Policy: Lets you edit the code used to create a policy using the Review Policy page. Remove Policy: Deletes the inline policy so that it no longer affects the entity. The deletion is final, so you must make that sure you actually want to delete the policy. Simulate Policy: Demonstrates the effect of the policy on the entity. You can set up various configurations and testing criteria so that you know that the inline policy works as expected.

View Article
How to Create Customer-Managed Policies in AWS

Article / Updated 02-01-2017

When you initially create your AWS (Amazon Web Services) account, only one AWS-managed policy is in place: AdministratorAccess. However, after you create the first user and log in to AWS using your new administrator account, you can access a large number of AWS-managed policies. Whenever possible, you should use the AWS-managed policies to ensure that the policy receives automatic updates that reflect changes in AWS functionality. When using a customer-managed policy, you must perform any required updates manually. The following steps get you started using customer-managed policies. Sign in to AWS using your administrator account. Navigate to the IAM Management Console. Select Policies in the Navigation pane. You see the Welcome to Managed Policies page. Click Get Started. You see a list of available AWS-managed policies, as shown. Each of the policy names starts with the word Amazon (to show that it's an AWS-managed policy), followed by the service name (EC2 in the figure), optionally followed by the target of the permission (such as ContainerRegistry), and ending with the kind of permission granted (such as FullAccess). When creating your own customer-managed policies, it's good to follow the same practice to make the names easier to use and consistent with their AWS-managed counterparts. Note that the policy list tells you the number of entities attached to a policy so that you know whether a policy is actually in use. You can also see the policy creation time and the time someone last edited it. The symbol on the left side of the policy shows the policy type, which is a stylized cube for AWS-managed policies. Before you create a customer-managed policy, make certain no AWS-managed policy exists that serves the same purpose. Using the AWS-managed policy is simpler, less error prone, and provides automatic updates as needed. Click Create Policy. You see the Create Policy page, shown. AWS provides three options for creating a new policy (in order of complexity): Copy an AWS Managed Policy: An AWS-managed policy acts as a starting point. You then make changes required to customize the policy for your needs. Because this option helps ensure that you create a usable policy and requires the least work, you should use it whenever possible. This example assumes that you copy an existing AWS-managed policy because you follow this route most often. Policy Generator: Relies on a wizardlike interface to either allow or deny actions against an AWS service. You can assign the permission to specific resources (in some cases) using an Amazon Resource Name, ARN, or to all resources (using an *, asterisk). (The discussion describes how to create and use ARNs.) A policy can contain multiple permissions, each of which appears as a statement within the policy. After you define policies, the wizard shows you the policy document, which you can edit manually if desired. The wizard uses the policy document to generate the policy. This is the best option to use when you need a single policy to cover multiple services. Create Your Own Policy: Defines a policy completely by hand. All you see is the policy document page, which you must fill in manually using appropriate syntax and grammar. The discussion tells you more about how to create a policy completely manually. You use this option only when necessary because the time involved in creating the document is substantial and the potential for error is high. Click Copy an AWS-Managed Policy. You see a listing of AWS-managed policies. Click Select next to the AWS-Managed policy that you want to use as the basis for your customer-managed policy. The example uses the AmazonEC2FullAccess policy as a starting point, but the same steps apply to modifying other policies. You see the Review Policy page shown. Starting with a policy that has too many rights and removing the rights you don't want is significantly easier than starting with a policy that has too few rights and adding the rights you need. Adding rights entails typing new entries into the policy document, which requires a detailed knowledge of policies. Removing rights means highlighting the right statements you don't want and deleting them. Type a new name in the Policy Name field. The example uses MyCompanyEC2FullAccessNoCloudWatch as the policy name. Modify the Description field as needed to define the changes made. The example adds that the policy doesn't allow access to CloudWatch. Modify the Policy Document field as needed to reflect policy changes. The example removes the following policy section from the document: { "Effect": "Allow", "Action": "cloudwatch:*", "Resource": "*" }, Make certain that you add and remove commas between policies as needed, or the policy won't work as expected. Click Validate Policy. If the changes you made work as intended, you see a This Policy Is Valid success message at the top of the page. Always validate your policy before you create it. Click Create Policy. You see a success message on the Policies page, plus a new entry for your policy, as shown. Note that your policy doesn't include a policy type icon. The lack of an icon makes the policy easier to find in the list.

View Article
Define AWS Permissions and Policies

Article / Updated 02-01-2017

Sometimes it's hard to figure out the whole idea behind permissions and policies in AWS (Amazon Web Services). To begin with, a permission defines the following: Who can access a resource What actions individuals or groups can perform with the resource Every user starts with no permissions at all. In other words, a user can't do anything, not even view security settings or use access keys to interact with a resource. This is a good practice because it means that you can't inadvertently create a user with administrator rights simply because you forget to assign the user specific permissions. Of course, assigning every user every permission required to perform what amounts to the same tasks is time consuming and error prone. A policy is a package of permissions that applies to a certain group of people. AWS comes with only the AdministratorAccess policy configured, so if you want to use other policies, you must define them yourself. Fortunately, policies come in several forms to make them easier to work with. The following list describes the policy types and describes how you use them: Managed: Stand-alone policies that you can attach to users and groups, but not to resources. A managed policy affects identities only. When creating a managed policy, you use a centralized management page to create, edit, monitor, roll back, and delegate policies. You have access to two kinds of managed policies. AWS-Managed: A policy that AWS creates and manages for you. These policies tend to support obvious needs that most organizations have. The reasons to use AWS managed policies are that they're simple to implement and they automatically change to compensate for changes to AWS functionality. Customer-Managed: A policy that you create and manage. Use these policies to support any special organizational requirements. The main reason to use a policy of this type is to gain flexibility that the AWS-managed option doesn't provide. Inline: Embedded policies that you create and attach to users, groups, or resources on an individual basis (without using a centralized manager). AWS views identity policies (those used for users and groups) differently from resource policies as described in the following list: Embedded User, Group, or Role: An identity policy that you embed directly into a user, group, or role. You use an identity policy to define the actions that an entity can perform. For example, a user can have permission to run instances of EC2. In some cases, in addition to defining what action a user can take, the policy can also define the specific resource with which the user can work. This additional level of control is a resource-level permission, one that defines both the action and the specific resource. Resource: One or more permissions that determine who can access the resource and what actions they can perform with it. You can add resource-based permissions to Amazon S3 buckets, Amazon Glacier vaults, Amazon SNS topics, Amazon SQS queues, and AWS Key Management Service encryption keys. Unlike policies created for identities, resource-based permissions are unmanaged (inline only).

View Article
How to Create an AWS Administrator User

Step by Step / Updated 02-01-2017

Creating the Administrators group is the first step in ensuring that your AWS (Amazon Web Services) account remains safe. The next step is to create an account for yourself and assign it to the Administrators group so that you have full access to the administrative features of your AWS account. The following steps describe how to perform this task.

View Step by Step
How to Create the AWS Administrators Group

Step by Step / Updated 02-01-2017

Before you can create an Administrator user in AWS (Amazon Web Services), you must provide a group for it. Every user who can perform administrative tasks is part of the Administrators group. The following steps describe how to perform this task.

View Step by Step
Configure Root Access in AWS

Article / Updated 02-01-2017

When you initially create your AWS (Amazon Web Services) account, Amazon assigns an identity to the account name and password that you provide as the root user. The root user has unrestricted access to all the AWS resources. As you might imagine, this makes the root user account dangerous, because anyone who gains access to it can also access everything your AWS account supports. Because root user access is so dangerous, Amazon recommends that you use it only to create your first administrative user and then lock the root user access so that no one can use it. The root user never goes away; you simply make it nonfunctional unless you really do need it at some point. To begin this process, you must access the IAM Console. You may see a sign-in page for your account when you aren't already signed into AWS. Provide your credentials as needed. After you sign in to your account, the page shown ihere appears. Now that you have access to the IAM Console, you can perform the tasks required to create an administrator account and assign it privileges.

View Article
page 1
page 2
page 3
page 4