gene_wood's questions

The DynamoDB On Demand Free Tier documentation describes the free tier as including

• 25 GB of data storage
• 2.5 million stream read requests from DynamoDB Streams
• 1 GB of data transfer out, aggregated across AWS services

Since this includes no read or write requests, is there any way to actually use DynamoDB on demand (use as in read or write to the DB) in the free tier?

Does the free tier include some read and write requests and the documentation doesn't mention them?

Is the least you can spend on DynamoDB On-Demand $1.50 ($1.25 + $0.25) per month if you actually want to read and write to your DB?

Note : This is distinct from the DynamoDB Provisioned Free Tier which works differently and appears to have a free tier that you can actually use.

The AWS documentation on ElasticSearch access control talks about how to grant access to the ES domains subresources while preventing changes to the domain's configuration by creating an ES domain resource policy and setting the resource to the ES domain ARN followed by /*. For example

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:*"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

In this example, test-user is granted rights to perform actions on the ES domain subresources but not the ES domain configuration itself.

When provisioning an AWS ES Domain using CloudFormation, one can set the resource policy with the AccessPolicies property. There is no CloudFormation resource like AWS::Elasticsearch::DomainAccessPolicy unfortunately and it appears that the only way to set a resource policy on an ES domain is with this property.

How can one take advantage of the types of policies recommended in the access control docs if there's now way to know the ES Domain ARN to use in the Resource field, since the ES domain hasn't yet been created at the point where the access policy is defined?

I've tried referencing the DomainArn attribute of the ES domain in the resource field of the Access Policy, but understandably that doesn't work since it creates circular dependency.

The only solution I've thought of so far is to just wait until AWS updates CloudFormation to include a AWS::Elasticsearch::DomainAccessPolicy resource type.

There are a number of AWS accounts which I don't control. I've had the account owners deploy an IAM Role, TrustingSecurityAuditor, into their accounts which grants the right to assume the TrustingSecurityAuditor role to a different IAM role in my AWS account, TrustedSecurityAuditor. (Docs on delegating access)

This works great and allows me and my security team to provide security auditing services to these other account holders in the company. To do this we spin up an ec2 instance with the TrustedSecurityAuditor IAM role and our code requests temporary credentials from each of the accounts using STS by doing an AssumeRole to each account's TrustingSecurityAuditor role.

Now I want to create an additional service running on a different ec2 instance in my account which can not only assume the role of these "Trusting" accounts, but also do other things in my account, like access my account's DynamoDB to store information.

If I apply the TrustedSecurityAuditor role to the instance I don't have the local permissions I need (like DynamoDB access).

I can't apply multiple IAM roles to an instance (unless I'm mistaken).

When I attempt to create a new role, MyNewService, with DynamoDB access that can AssumeRole to the TrustedSecurityAuditor role in hopes of then using those STS credentials to do a second AssumeRole to the TrustingSecurityAuditor role in the foreign account I encounter this problem :

I'm able to AssumeRole from the MyNewService role to the TrustedSecurityAuditor role, but when I do the second AssumeRole to the TrustingSecurityAuditor role AWS returns the error

User: arn:aws:sts::123456789012:assumed-role/TrustedSecurityAuditor/MyNewService is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789012:role/TrustingSecurityAuditor

The reason for this is that the "user" attempting the AssumeRole is

arn:aws:sts::123456789012:assumed-role/TrustedSecurityAuditor/MyNewService

not

arn:aws:sts::123456789012:assumed-role/TrustedSecurityAuditor

What this implies is that you can not chain your AssumeRoles because the ARN that a call originates from, when it comes from an assumed role is not the assumed role alone, but the assumed role with the assumer's rolename stuck on the end.

One solution which I'm reluctant to use is that I could just add the permissions I need, for example the ability to use DynamoDB to the TrustedSecurityAuditor role. The reason I'm reluctant is that I only need this permission on the MyNewService instance, not on my original instance which only does security auditing and has no need to access DynamoDB.

Any suggestions how to accomplish what I'm looking for?

The AWS Documentation on Amazon Resource Names says

Some services let you specify a path for the resource name. For example, in Amazon S3, the resource identifier is an object name that can include slashes (/) to form a path. Similarly, IAM user names and group names can include paths.

This can be seen with the iam:CreateGroup call as an example.

What services other than S3 and IAM allow you to specify a path for a created resource?

Currently we use F5 Big-IP LTMs (IP load balancers) in our environment for load balancing. We have an existing process for making changes to LTM configs and pushing them out. I'm trying to figure out the best way to accommodate a new need of our environment.

This is our current method for making changes to our LTM configs (to create new VIPs or add or remove nodes for example) :

• Connect to a server where we maintain copies of our LTM configs
• check out a copy of the config from RCS version control
• vi the config file and make the change on this server
• diff the new config against the previous in version control
• paste this diff into a change control ticket in our ticketing system
• have a fellow network engineer buddy check the diff and sign off on it
• scp the new config file out to our secondary LTM server
• run a "bigpipe verify load /tmp/bigip.conf" to verify the new conf
• copy the staged bigip.conf over the live one in /config/bigip.conf
• run a "bigpipe load"
• tech logs into the web interface to confirm it looks good
• synchronize from our seconary LTM to our primary LTM by running "bigpipe config sync" on our secondary

We want to grant other teams the "Operator" permission to enable and disable nodes in a VIP pool. Doing so writes the changed node state into the config file.

How can we allow other teams to use iControl or the web interface to administratively enable and disable nodes, while maintaining our ability to version control and review config changes before deploying them while not overwriting the node states that have been set on the live production LTMs?